Summary: A Functional Safety Assessment Method for Cooperative Automotive Architecture* Sangeeth Kochanthara, Niels Rood, Arash Khabbaz Saberi, Loek Cleophas, Yanja Dajsuren and Mark van den Brand Eindhoven University of Technology, The Netherlands Abstract The scope of automotive functions has grown from a single vehicle as an entity to multiple vehicles working together as an entity, referred to as cooperative driving. The current automotive safety stan- dard, ISO 26262, is designed for single vehicles. With the increasing number of cooperative driving capable vehicles on the road, it is imperative to systematically assess their architectures’ functional safety. Many methods are proposed to assess architectures with respect to different quality attributes in the software architecture domain, but to the best of our knowledge, functional safety assessment of automotive architectures is not explored in the literature. We present a method leveraging existing soft- ware architecture and safety engineering research, to check whether the functional safety requirements for cooperative driving scenarios are fulfilled in the technical architecture of a vehicle. We apply our method on a real-life academic prototype for a scenario—platooning—and discuss our insights. 1. Introduction Traffic congestion was estimated to cost 305 billion dollars in 2017 to traffic participants in the United States of America alone.1 One potential solution to reduce traffic congestion and related operational costs is cooperative driving. Cooperative driving refers to the collective optimization of the traffic participants’ behavior by sharing information using wireless communication e.g. peer-to-peer networks or via the cloud. It can improve traffic efficiency, reduces cost, and increases comfort [2]. In 2020 alone, 10 million new vehicles with cooperative driving capabilities were projected to hit the roads, and the safety of these vehicles needs urgent attention.2 Most cooperative driving is achieved by determining a vehicle’s behavior for optimal traffic behavior based on information received from other traffic participants. Such optimal behaviors are (partially) achieved using software-controlled steering, acceleration, and braking. Any prob- lem in the software can lead to catastrophic effects to the vehicle and other traffic participants. To avoid this, cooperative driving systems are designed to operate in case of failure or fail safely. The current guidelines to ensure the safety of automotive systems (and their architecture) are provided by ISO 26262 - a product development standard for the automotive domain [3]. The ECSA 2021: 15th European Conference on Software Architecture, 13-17 September 2021 (virtual) * This work is a part of the i-CAVE research programme (14897 P14-18) funded by NWO Use the original publication when citing this work [1] " s.kochanthara@tue.nl (S. Kochanthara) © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) 1 https://www.smartcitiesdive.com/news/gridlock-woes-traffic-congestion-by-the-numbers/519959/ 2 https://bit.ly/volkswagen-includes-nxp-v2x and https://www.sciencedaily.com/releases/2019/05/190519191641.htm standard offers methods from the safety engineering domain to identify safety requirements. Any automotive software architecture that fulfills these requirements is deemed safe-by-design. ISO 26262 neither considers cooperative driving nor prescribes methods for architecture assessment. The standard is designed for single vehicles and does not include a cooperative perspective in which a set of vehicles is seen as a single entity [4]. This can mean that a low-risk safety requirement from a single-vehicle perspective can have catastrophic effects on other cooperating vehicles [2]. To create a functionally safe architecture from a cooperative perspective, existing studies have extended the standard guidelines [5] or presented an architec- ture framework [2]. Yet checking the safety of software architecture of an existing vehicle for cooperative driving, remains an open question. The ISO 26262 standard does not prescribe methods to assess the functional safety of an automotive architecture. Approaches to assess architectures with respect to quality attributes have emerged in the software architecture domain [6]. However, only some methods are designed for operational quality attributes like performance (in contrast to development quality attributes like maintainability) [6]. To the best of our knowledge, none of these methods are designed to assess the operational quality attribute functional safety of automotive systems. This paper presents a method to assess the functional safety of existing automotive architec- ture for cooperative driving, by combining methods from the safety engineering and software architecture domains. Our method has two parts: (𝑖) derive Functional Safety Requirements (FSRs) for cooperative driving scenarios; (𝑖𝑖) check whether the (technical) software architecture fulfills the derived functional safety requirements—a blend of methods [7, 8, 6] adapted from the software architecture domain. Our paper primarily focuses on the design phase (concept development phase in ISO 26262) and validation of the resultant requirements in the software architecture in the final product. We also validated our approach via a case study on an academic prototype. This extended summary of [1] summarizes our approach; refer to [1] for more details. 2. Methodology Our method has two parts: (𝑖) derive FSRs for cooperative driving scenarios, and (𝑖𝑖) check whether the FSRs are fulfilled in the technical software architecture of a vehicle.3 Note that the first part needs only a black box view of individual vehicle functions and their interactions and thus uses the functional architecture view. Derive FSRs for cooperative driving: We extend the traditional method [3] to derive FSRs, to be executed on the entire cooperative system in parallel, rather than on an individual vehicle (see Figure 1). We first outline the traditional method, followed by our prior work on its extension [5] and our new contribution. For the rest of the paper, we use the term vehicular perspective for an individual vehicle as a unit and cooperative perspective for a set of vehicles. Traditionally, FSRs for a vehicular perspective are derived by mapping the safety goals for a vehicle on to the individual components of the vehicle’s functional architecture. This process of mapping—safety analysis—captures information on the malfunctioning of a component that can lead to violation of a safety goal. Safety analysis is performed using a systematic process (like fault tree analysis [9]) that takes two inputs: (𝑖) functional architecture and (𝑖𝑖) safety goals. 3 The technical software architecture includes the system’s runtime model and allocation of software to hardware. Vehicle Safety goals are derived Functional Architecture Scenario Description from hazardous events [3], found by decomposing the item: cooperative system 3 item: individual vehicle 1 2 Our scenario description us- Kochanthara et al.[4] ISO 26262 Contribution Functional Decomposition Functional Decomposition from Vehicular Perspective ing the hazard analysis from Cooperative Perspective System Architect and risk assessment tech- Hazardous events / from cooperative perspective Hazardous events from vehicular perspective nique [3]. This method to Cooperative functional Safety goals Safety goals from vehicular perspective derive FSRs is depicted by architecture from cooperative perspective part 3 and flows 𝑎 and 𝑑 c a b d of Figure 1, with 𝑎 and 𝑑 Safety Analysis as inputs to safety analy- Functional Safety Requirements sis. This method to derive FSRs is the norm in the au- Figure 1: Method to derive FSRs for cooperative driving. Parts 1&2 are our addition. tomotive domain [3]. System architect: external entities creating the cooperative architecture. In the proposed method, we have one item4 per individual vehicle type, and an item for the entire cooperative system of which the vehicles are part. A cooperative system can contain more than one type of vehicle (for example, two vehicles with different functional architectures). In the case of more than one type of vehicle, each type will form an item. For the rest of this section, we consider two items: an individual vehicle (representing all vehicle functional architectures) and the cooperative system. We propose that FSRs for a cooperative system are derived from: (𝑖) safety goals from the vehicular perspective (as in the traditional method), and (𝑖𝑖) safety goals from the cooperative perspective. Our prior work [5] extended the traditional process to derive safety goals for the vehicular perspective to the cooperative perspective (annotated as part 2 in Figure 1) to cover safety goals from both perspectives. This process partitions the scenario description into vehicle- specific and cooperation-specific parts. We apply the traditional safety goal identification steps to the two parts. FSRs from the vehicular perspective are then derived. A cooperative functional architecture is required to derive FSRs, by mapping safety goals to functional architecture components. The cooperative functional architecture should be built using individual vehicle functional components to preserve the mapping between functional architecture of cooperative system and the technical software architecture of individual vehicles. We propose that the cooperative functional architecture be built from (𝑖) the functional archi- tecture of individual vehicles that constitute the cooperative system and (𝑖𝑖) the cooperative scenario description of the interaction between individual vehicles. With these requirements, system architects can create a functional architecture of the cooperative system such that the individual components of the architecture are mapped onto the components of the functional architecture of vehicles. This process is labeled as part 1 in Figure 1; the complete process of deriving FSRs from the cooperative perspective is shown by the labels 1, 2, 𝑏, and 𝑐. We performed a case study on an academic prototype for the cooperative driving scenario, platooning, in which a manually driven vehicle is autonomously followed by a train of vehicles. Application of our method resulted in an additional 9 safety goals and 15 FSRs to the 16 safety goals and 16 FSRs from the traditional ISO 26262 method [1]. 4 Item: “system or combination of systems, to which ISO 26262 is applied, that implements a function or part of a function” [3] Check fulfillment of FSRs: Our method of assessing the fulfillment of FSRs is a blend of techniques adapted mainly from the software architecture domain. With no existing architecture assessment techniques addressing functional safety in the context of automotive systems, our method takes inspiration from traditional architecture assessment techniques like ATAM [6] and uses the safety tactic framework [7, 8] to leverage existing architecture knowledge. Our method to check for the fulfillment of FSRs in the technical software architecture of individual vehicles is organized in two phases. Phase one ensures that it is possible to realize all the FSRs by identifying whether there are conflicting FSRs. Phase two describes a systematic method to check for the fulfillment of FSRs in the technical architecture (see figure 2). In phase one (see Fig- Vehicle Software Architecture ure 2), we check for con- Vehicle Functional Group FSRs based on associated Set of Functional Safety functional architecture component flicting FSRs. Two FSRs Architecture Requirements (FSRs) Phase 1 Out of are conflicting if both Vehicle Technical Set of FSRs for each functional scope Architecture architecture component of them cannot be ful- filled at the same time. Conflicting requirement in yes Resolve Conflicts Comparing every pair of any ? Applicable patterns for specified tactic combinations FSRs for conflicts will No safety tactics lead to a quadratic num- Identify tactics for implementing each FSR Safety Tactics and Patterns ber of comparisons (if 𝑛 Applicable tactics for each FSR from Literature is the number of FSRs, the number of compar- Are tactics Phase 2 from realized for every Technical architecture No in the technical does not fulfill FSRs isons is 𝑛(𝑛 − 1)/2 ≈ architecture? 𝑂(𝑛2 )). We compare Set of FSRs with no tactic from implemented in the technical architecture FSRs that belong to the Yes Associating feasible combinations of tactics in same functional archi- with patterns for each tecture component for Technical architecture fulfills FSRs conflicts. This can re- Set of applicable tactics and patterns for each FSR duce the number of com- Incorporating tactics (and patterns) in the technical architecture parisons up to a factor of Figure 2: Method to check the fulfillment of FSRs in technical architecture 𝑑, where 𝑑 is the number of functional components (i.e., the number of comparisons can be reduced up to 𝑛(𝑛 − 𝑑)/𝑑 ≈ Ω(𝑛2 /𝑑)). The reduction is possible since safety analysis techniques for deriving FSRs ensure that each FSR belongs to only one functional component [9, 3]. FSRs belonging to a component can have conflicts among themselves but not with the FSRs belonging to other components. An FSR may be fulfilled by a safety tactic or a combination of safety tactics. To identify whether an FSR is fulfilled, we propose checking the vehicle technical software architecture for the implementation of safety tactics [8, 7] that can meet the FSR. This is achieved in two steps: (𝑖) identify a set of safety tactics (hereafter referred to as applicable tactics) such that the implementation of each tactic, in itself or in combination with some other tactics in the set, can fulfill the FSR; and (𝑖𝑖) check whether any feasible combination of tactics from the applicable tactics that are present in the vehicle technical architecture meets the FSR. Note that, for an FSR 𝑓𝑖 and its corresponding functional component 𝑐𝑖 , the applicable tactics for 𝑓𝑖 need to be compared with only the safety tactics implementations used in the technical architecture counter part of 𝑐𝑖 and its associated safety mechanisms, since 𝑓𝑖 is only associated with 𝑐𝑖 . Applicable tactics for an FSR can be identified based on the FSR description (by navigation of a tactic hierarchy) [6, 8, 7] or by matching the FSR description to the descriptions of tactics [8]. By the end of this two step process of identifying applicable tactics and checking the technical architecture for them, we will have a list of FSRs that do not have any feasible combination of tactics implemented. The list shows the FSRs that have not been fulfilled by the technical architecture, if any. As a by-product, for each unfulfilled FSR, we will also have a set of applicable tactics such that some feasible combinations from this set can fulfill the FSR. These combinations point to a set of safety patterns since safety patterns are associated with the safety tactics they implement [8]. These applicable safety patterns (and applicable tactics) provide the system architects with a set of possible design decisions to realize the unfulfilled FSRs. In our case study, we checked whether the FSRs (the 31 FSRs as mentioned in Section 2) are fulfilled on an academic prototype capable of cooperative driving using 13 most used safety tactics [8, 1]. We found that the prototype’s technical architecture meets only 6 FSRs [1]. 3. Conclusion This paper investigated whether the architecture of a single vehicle meets the functional safety requirements for cooperative driving. We proposed a method to ensure that an automotive architecture is functionally safe to operate in given scenarios. The proposed method derives FSRs for a cooperative driving scenario and checks whether they are fulfilled in the technical architecture of a vehicle. The method is a combination of methods adapted from the safety engineering and software architecture domains. We showed the usability of our method for a cooperative driving scenario—platooning—on a real-life academic prototype, which resulted in uncovering FSRs that were not fulfilled by its software architecture. Our method is motivated by and reinforces the notion that functional safety should not be an afterthought in the design of automotive architectures, but be used for defining the architecture of the automotive system. References [1] S. Kochanthara, N. Rood, A. Khabbaz Saberi, L. Cleophas, Y. Dajsuren, M. van den Brand, A functional safety assessment method for cooperative automotive architecture, (JSS) (2021). URL: https://authors.elsevier.com/sd/article/S0164-1212(21)00088-1. [2] P. Pelliccione, E. Knauss, S. M. Ågren, R. Heldal, C. Bergenhem, A. Vinel, O. Brunnegård, Beyond connected cars: A systems of systems perspective, (SCP) (2020). [3] ISO, ISO 26262: 2018 - Road vehicles – Functional safety, Standard, International Organization for Standardization, 2018. [4] Y. Dajsuren, M. van den Brand, Automotive Systems and Software Engineering, Springer, 2019. [5] S. Kochanthara, N. Rood, L. Cleophas, Y. Dajsuren, M. van den Brand, Semi-automatic architectural suggestions for the functional safety of cooperative driving systems, in: (ICSA-C), IEEE, 2020. [6] L. Bass, P. Clements, R. Kazman, Software architecture in practice, Addison-Wesley, 2012. [7] W. Wu, T. Kelly, Safety tactics for software architecture design, in: (COMPSAC), IEEE, 2004. [8] C. Preschern, N. Kajtazovic, C. Kreiner, Building a safety architecture pattern system, EuroPLoP ’13, ACM, 2015. [9] W.-S. Lee, D. L. Grosh, F. A. Tillman, C. H. Lie, Fault tree analysis, methods, and applications a review, IEEE transactions on reliability (1985).