Nowadays, one of the biggest challenges facing the automotive industry is the transition from hardware-based to software-defined vehicles. As software becomes the focus of development in the automotive industry, an increasing number of OEMs and suppliers are gradually transforming into software companies. Cars are evolving from a mere means of transport to computers with mobility: four-wheeled computers.
Differences and Synergies Between Functional Safety, SOTIF, and Cybersecurity
The rapid development of intelligent connected vehicles has led to the continued emergence of new technologies, including software updates remotely via over-the-air (OTA) technology or integration with personal digital devices. The wide implementation of these new technologies in smart connected vehicles places additional demands on the information security (or cybersecurity) of the complete vehicle. The state-of-the-art in this area is documented in ISO 21434, an industry standard entitled “Road vehicles – Cybersecurity engineering."
Currently, most OEMs and component suppliers adopt engineering processes to ensure the safety of the electric/electronic (E/E) systems in their vehicles. This means they consider the development processes for functional safety and the safety of the intended functionality (a.k.a. SOTIF) outlined in the international standards ISO 26262 and ISO 21448 respectively.
For practitioners, it is crucial to comprehend the relationship between current safety and cybersecurity standards, and it is equally important to understand how to achieve coordination between the different life cycles they provide. As an example, how can we achieve the safety, cybersecurity and finally the software quality in a model-based development process, particularly when using tool chains based on Simulink or TargetLink? These questions are examined in the following sections.
First, we will remind ourselves of the essential safety and cybersecurity standards for the automotive domain. Currently, we have three base standards:
- ISO 26262:2018 ‘Road vehicles – Functional safety’ addresses possible hazards caused by malfunctioning behaviour of safety-related in-vehicle E/E systems. It defines an automotive-specific risk-based approach that determines and maps risks through the use of Automotive Safety Integrity Levels (ASILs). [ISO 26262, ISO DTS 5083]
- ISO 21448:2022 ‘Road vehicles – Safety of the intended functionality’ addresses unreasonable risks due to hazards resulting from functional insufficiencies of the intended functionality by providing a general argumentation framework and guidance on measures to ensure the SOTIF. The idea is to reduce the impact of known potentially harmful scenarios as well as to reduce the amount of unknown hazardous scenarios to a minimum. [ISO 21448, ISO DTS 5083]
- ISO/SAE 21434:2021’Road vehicles – Cybersecurity engineering’ focuses on the risks represented by unauthorized actions, including those by active adversaries. This requires the use of additional engineering activities and technical mechanisms that can nevertheless also affect safety. This standard describes the cybersecurity activities, including those for a secure development process, with a special focus on risk management. [ISO/SAE 21434, ISO DTS 5083]
Holistic Safety
To successfully address the challenges related to software defined vehicles, it is not sufficient to address the above mentioned domains – functional safety, SOTIF, and cybersecurity – in isolation. Rather, we need to adopt a holistic safety approach. Holistic safety can be defined as the ability of a system to provide a service or function regarding the attributes safety and cybersecurity (Fig. 1). Unfortunately, there is no holistic safety standard for the automotive industry yet[1].
Safety vs Cybersecurity
So how are safety and cybersecurity related? Two quotes from the literature illustrate their interdependencies:
“Security and safety have been traditionally considered as different disciplines addressed by different professionals. However, a close look at their characteristics and their analogies leads to the conclusion that they are actually interdependent. Specifically […] safety requires system security […]”. [Ser19]
Furthermore, it turned out that “you can’t have safety without security”. Rather “we can think of security as a safeguard that ensures our safety”. [Rya18]
The relationship between safety and cybersecurity is also depicted in Fig. 2. There, however, from a different perspective. As shown in Fig. 2, cybersecurity focuses on protecting the system at hand from external threats. Safety on the other hand focusses on preventing or mitigating hazards that originate in the system. These hazards can be caused by the intended functionality or by malfunctioning behaviour of the system.
In the age of hardware-based vehicles, less attention was paid to cybersecurity. However, with the rapid growth of software-defined vehicles, cybersecurity concerns become increasingly important, so both safety and cybersecurity are being considered more systematically.
Safety and Cybersecurity Co-Engineering
Let’s have a closer look on how to co-engineer an automotive E/E system that needs to meet both stringent safety and cybersecurity requirements. To do so, we’ll initially dive into the proposed life cycles for functional safety as per ISO 26262 and for cybersecurity according to ISO/SAE 21448 in order to better understand their similarities and differences. Then, we’ll discuss a possible integration of these life cycles.
The functional safety standard ISO 26262 encompasses the life cycle at system and software levels, as shown in Fig. 3 (the synchronized hardware development cycle is omitted for brevity). The activities are visualized using the V model. Activities at the system level are shown above the dotted line, while those below are at the software level activities.
The left-hand side of the V encompasses specification, design, and implementation activities for the system and the software.
At the system level, starting with the hazard analysis and risk assessment (HARA) practitioners identify and evaluate the potential hazards and associated risks from the functional safety perspective. Then, they determine the ASIL level, generating corresponding safety goals used as top-level safety requirements.
The safety goals are then broken down in a two-stage process, first into a set of functional safety requirements and then into technical safety requirements. The results are documented in the functional and technical safety concepts respectively.
After establishing the technical safety concept, the life cycle continues at the software level. Here, software safety requirements are defined. Then, the software architectural design, the software unit design, and the software implementation are conducted.
Following this, we move to the right-hand side of the V which includes the necessary integration, verification, and validation (V & V) activities.
The basic idea here is to integrate the software and the system in a step-by-step fashion and to safeguard each step on the left side of the V with a corresponding V & V activity.
Once the development is completed, the life cycle continues with production and operation.
The international standard ISO/SAE 21434 introduces a cybersecurity (CySec) life cycle, as depicted in Fig. 4. This life cycle shares some conceptional similarities with the functional safety life cycle discussed before.
On the left-hand side of the V, an initial threat analysis and risk assessment (TARA) leads lo high-level cybersecurity goals which are refined into a cybersecurity concept at the system (item) level. This concept informs the lower level designs at the component and sub-component levels.
Please note that the refinement steps here are more generic in nature in comparison to the functional safety life cycle. The exact steps might differ due to the different company structures or system characteristics.
The right-hand side of the V, comprises the usual integration, verification, and validation activities. A successful cybersecurity validation is followed by production and operation activities.
The cybersecurity life cycle is more iterative in nature. As indicated in the upper left part of Fig. 4, the above mentioned concept, product development, production, and operation activities are conducted in cyles. The maintenance of the software using OTA updates becomes an integral part of the life cycle. One of the reasons for this is to ensure the necessary cybersecurity throughout the entire product life cycle.
So far we have two distinct life cycles, one for functional safety and a second for cybersecurity. The two standards themselves merely point out the need to coordinate security and cybersecurity activities and provide only some general guidance on how to do so.
ISO 26262 requires to establish and maintain effective communication channels between functional safety, cybersecurity, and other related domains. ISO 21434 emphasizes that organizations should identify the fields that relate to or interact with cybersecurity. The standard also calls for the establishment and maintenance of communication channels between these fields to determine how cybersecurity fits into current processes and to achieve synergies in the exchange of information.
However, both standards lack more detailed descriptions of processes, methods, and tools for safety and cybersecurity co-engineering.
Therefore, the practical alignment of the two life cycles remains an area of ongoing research.
One notable initiative in this respect is the research project "EmbeddedSafeSec”.[2] The project’s goal was to develop a process model and an integrated methodology to ensure safety and security when developing critical embedded systems [EmbeddedSafeSec].
To achieve this, the safety and cybersecurity life cycles were structured into related activities in such a way that they could be at least partially combined into activity pairs and could be jointly processed as part of a co-engineering process (Fig. 5).
Fig. 6 illustrates this rather complex mapping of functional safety and cybersecurity activities for the software development and Fig. 7 further zooms into the software unit integration activity.
The upper part of Fig. 7 depicts the different clauses in ISO 26262 and ISO/SAE 21434 that could be mapped to an activity pair for software unit verification. The lower part lists the input and output work products as well as the objectives of this activity pair.
Application Example: Modeling and Coding Guideline Checking
Automotive companies frequently employ model-based development (MBD) methods in their software development, especially for application-level software design. To support these methods, modeling tools such as Simulink and TargetLink are being utilized.
As part of a MBD approach the software unit design could be described by executable implementation models in TargetLink and the subsequent implementation into C code is automated by means of code generation.
Both, ISO 26262 and ISO/SAE 21434 require the application of modeling and coding guidelines to avoid potential adverse effects of certain features of the modeling/coding languages on the safety and cybersecurity respectively. For the C language, such guidelines can be based on the MISRA C or CERT C guidelines.
When using MBD a significant subset of these guidelines can be checked and enforced at the implementation model level already, i.e. by applying corresponding modeling guideline checks.
In a safety & cybersecurity co-engineering approach, as part of the unit verification step companies would employ a common set of modeling guidelines to address both functional safety and cybersecurity concerns.
Such a guideline set could e.g. contain checks to ensure consistent inputs (data type and scaling) as well as consistent data ranges for arithmetic operations (Fig. 8)
When using TargetLink with integer arithmetic for example, the data type of the outputs and the scaling of the intermediate variables must be sufficient to avoid overflow. Integrated within target blocks, in principle, the saturation limit block is utilized to avoid overflow and underflow. This is accomplished by implementing the data type with sufficient bit length for the output and saving intermediate results to avoid saturation constraints in integer arithmetic via the integer overflow option.
A guideline set for safety & cybersecurity co-engineering would also contain a modeling guideline check to detect unintended direct comparisons of floating point data types for equality (Fig. 9). Such a check would e.g. flag the example in the lower left part of Fig. 9 such that it can be replaced by the improved modeling shown in the lower right part of the figure.
When defining the data type as "double" within the "chart" diagram in a Simulink model, it is not permissible to specify the relational operation as an equivalence comparison. The suggested method is to provide the difference and to ensure that it is within the scale of tolerance.
To ensure the efficiency of the software development process, modeling and coding guidelines checks should be automated as much as possible. Engineers can get efficient help from guideline checking tools, such as MXAM, to achieve compliance with modeling guidelines to facilitate safety and cybersecurity. For example, the guidelines mentioned in ISO 26262 or ISO/SAE 21434, are now comprehensively covered by the guideline library of MXAM. In addition, the guidelines for functional safety and best practices from top industry players have also been integrated into MXAM to help engineers check and correct their models automatically. MXAM can also provide reports for specific given guideline sets and correct guideline violations in an automated fashion. Figure 10 illustrates the automated model analysis and correction process in MXAM.
Conclusion
You can’t have safety without cybersecurity. The traditional separation between the disciplines of safety (incl. functional safety and SOTIF) needs to be replaced by a holistic safety approach that includes that incorporates safety & cybersecurity co-engineering. Such a co-engineering approach requires comprehensive collaboration throughout the life cycle and systematic considerations. Powerful tool support can help to achieve synergies.
-------------------------------
[1] The emerging technical specification ISO TS 5083:2024 „Road vehicles – Safety for automated driving systems – Design, verification and validation” adopts a more holistic safety approach [ISO DTS 5083]. However due to its narrower focus on automated driving systems this document is not a base standard as the ones discussed above.
[2] The project EmbeddedSafeSec (01.03.2021 – 31.12.2022) was funded as part of the Investitionsbank Berlin (IBB) program for the promotion of research, innovation and technology (ProFIT) and by the European Regional Development Fund (ERDF).
References
- [ISO 26262] ISO 26262 ‘Road vehicles – Functional safety’. International standard, 2nd edition, ISO 2018
- [ISO/SAE 21434] ISO/SAE 21434 ‘Road vehicles – Cybersecurity engineering’. International standard, ISO/SAE 2021
- [ISO 21448] ISO 21448 ‘Road vehicles – Safety of the intended functionality’. International standard, ISO 2022
- [ISO DTS 5083] ISO DTS 5083 ‘Road vehicles – Safety for automated driving systems – Design, verification and validation’. Technical Specification (Draft), ISO 2024
- [Ser19] Serpanos: There Is No Safety Without Security and Dependability.
IEEE Computer 52(6), June 2019, pp. 78 – 81 - [Rya18] A. Ryan: There is no safety without security. 2018 www.tessentembeddedanalytics.com/no-safety-without-security/
- [EmbeddedSafeSec] EmbeddedSafeSec Research Project. 2021-2022 https://embeddedsafesec.zesys.de/en/
