Differences and Synergies Between Functional Safety, SOTIF, and Cybersecurity

So how do different safety standards interrelate? Two sentences summarized from articles can describe this relationship: "traditionally speaking, functional safety and cybersecurity have been considered separate fields of knowledge with different professionals responsible for them" Serpanos (2019). However, by analyzing their characteristics and drawing analogies, the conclusion is that they are interdependent: functional safety relies on information safety or cybersecurity, and vice versa. There is no functional safety without cybersecurity. Another note is summarized by Ryan (2018), where he also points out that cybersecurity can be seen as the guard of functional safety. In the past, cybersecurity has received less attention, probably due to an oversight by practitioners in the automotive industry. However, with the rapid growth of smart connected vehicles, cybersecurity concerns have gained increasing attention, placing attention on both functional safety and cybersecurity in a more systematic way.

Next this article dives into how to distinguish between functional safety and cybersecurity by providing a more straightforward conceptual view to understand their links. As shown in Figure 2, cybersecurity focuses on protecting systems and safeguarding products or digital assets of devices from external threats. This extends beyond the central system to encompass aspects of cybersecurity both within and outside the system. Threats can come from personnel or external environments, as illustrated by hackers attempting to manipulate ECU by connecting to the car via WIFI. While functional safety concentrates on preventing hazards from system failures, its primary goal is to protect individuals or the environment from harm caused by such failures. A typical example would be the functional insufficiency of anti-lock braking systems (ABS) at high travelling speeds: a system failure can cause severe harm to people.

To gain a deeper understanding of the link between cybersecurity and vehicle safety, this article introduces another example from automotive safety researchers. The example illustrates that these professionals have discovered the potential to control a vehicle through its computer system remotely and wirelessly. Through tools like GM‘s OnStar and Ford’s Sync, researchers have been able to access the in-vehicle computer system or connect to the entire automobile network via Bluetooth using in-vehicle phones, and even control almost all safety-critical systems such as brakes, locks, and the center console.

This is why practitioners in the automotive industry want to analyze and develop cybersecurity in automotive systems more methodically.  One notable initiative is the European research project "EmbeddedSafeSec" in the field of functional safety and cybersecurity, sponsored by Investitionsbank Berlin and the European Regional Development Fund (EFRD), which is dedicated to researching better implementations of synergy between functional safety and cybersecurity. This article presents some frameworks for synergies in automotive safety and their best practices.

Firstly, how regarding functional safety, standard ISO 26262 encompasses the lifecycle description from system and software levels, as shown in Figure 3 (the synchronized hardware development cycle is not mentioned). The activities at the system level are shown above the dotted line, while those below are at the software level. 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 determine the ASIL level, generating corresponding safety goals used as top-level safety requirements,
• Derive a set of specific technical safety concepts from functional safety concepts, as well as the implementation of functional safety requirements and specifications at hardware and software level.

After establishing technical safety concepts, the lifecycle has been further developed to software level:

• Software safety requirements, the software architectural design, software unit design, and the software implementation are specified,
• Following this, we move to different levels of testing and verifications corresponding to levels mapped on the left-hand side, i.e. unit integrated system and verifications at complete vehicle level,
• The final step involves validating whether the initial safety goals have been achieved.

These procedures help create a typical product development lifecycle for functional safety products. Subsequent processes such as production, operation, and obsolescence have formed a comprehensive iteration.

Safety standard ISO 21434 also introduces a cybersecurity lifecycle, as depicted in Figure 4, which is similar to the functional safety lifecycle. Starting from the CySec goals, it proposes the CySec concepts and then designs for components, followed by iterated lifecycle for production, operation, and obsolescence. Finally, the ultimate goals for CySec have been achieved. To be more specific, the general processes begin with the CySec goals-setting, followed by the CySec concepts, and end with the system software and hardware designs. The exact steps might differ due to the different company structures or even objectives. Here we also mention the designs for system components, sub-components, designs from other different levels, and their integration and verifications. The product development cycle of CySec has been constantly updated through iterations, and even with OTA technology, unlimited remote updates, and rapid iterations of the system can be achieved until it finally meets the expected goals.

There are some general descriptions of cross references between different knowledge fields in functional safety and cybersecurity standards. As stated in ISO 26262, these standards require the establishment and maintenance of effective communication channels between functional safety, cybersecurity, and other functional-safety related domains. The standard ISO 21434 also emphasizes that organizations should identify the fields related to or interact with cybersecurity, they should also establish and maintain the communication channels between fields to determine how cybersecurity fits into current processes and achieve synergy in the exchange of information. This synergy includes sharing processes and the implementation of strategic tools across areas. For more details, please refer to the corresponding chapters, and further information can be found in the notes.

Simultaneously, additional information on the synergy between functional safety and cybersecurity is provided in these standards: the correlation between the development process of functional safety and cybersecurity relies on the organization and the scale of projects. Consequently, there is no existing description of the methods, interactions, or technical materials; the organization is free to choose the method that suits its needs.

The synergistic considerations of functional safety and cybersecurity introduce the concept of co-engineering, which indicates how to approach these two primary factors and their related activity processes holistically (Figure 5). For example, what related activities are eligible in a synergistic way and what activities are not? What activities should be separated? How would the parallel activities relate to each other, or interact? A typical example of the communication between different processes is the series of process interactions during the software development phase in product development, and the corresponding mapping of the functional safety lifecycle to the cybersecurity lifecycle.

Co-engineering aligns with the product development phase of the functional safety lifecycle, especially a set of activities within the software product development phase in the cybersecurity lifecycle, which follows the V-shaped model process: from requirements to design, then progressing to the realization of testing and verification across different levels. Functional safety and cybersecurity standards have both mentioned relevant requirements, which are precisely described in sub-chapters of software unit verification and integration. For instance, the 10.4.1 chapter in ISO 21434 standard mentiones the guidelines for refining cybersecurity requirements and architectural design, and chapter 10.4.2 includes guidelines for integration and verification. Correspondingly, as depicted in Figure 6, in functional safety standard these chapters are mapped to the software part in chapter 6.9, addressing the software unit verification.

The software development phase activities in the product development process have been recorded in Figure 7, which illustrates the functional safety lifecycle activities and their corresponding activities in the product development phase of the cybersecurity lifecycle. For example, the refinement of cybersecurity requirements and architectural design corresponds to the product development at the software level phase in the functional safety lifecycle, derives from the detailed software development requirements (with a focus on the software level), software architectural design, implementation, and verification of the software unit, and the software system testing.

Based on the existing input information regarding the item and the operational environment, co-engineering implements verifications at unit and integration levels, and subsequently, the corresponding guidelines of software integration and verification are outputted.

Here we list the objectives for these co-engineering activities at software verification:

• Provide evidence that the SW unit design satisfies the allocated SW requirements as well as the cybersecurity specification and is suitable for implementation
• Verify that the defined safety measures resulting from safety-oriented analyses are properly implemented
• Provide evidence that the implemented SW unit complies with the unit design and fulfils the allocated SW requirements with the required ASIL
• Provide sufficient evidence that the SW unit contains neither undesired functionalities nor undesired properties regarding functional safety and cybersecurity

Here this article emphasizes the coordination in projects including the sharing of processes and usage strategies in the knowledge field. The requirement descriptions for development verification or testing strategies in different standards share similarities. Sharing the tools for development and testing aims to maximize the efficiency in achieving verification goals.

Whether it is for model or coding rules, there is no need for manual checks to ensure their correct implementation during the development process. Instead, engineers can get efficient help from model checking tools, such as MXAM, to achieve model consistency with specific modeling guidelines. For example, the coding guidelines or rules for modeling mentioned in ISO 26262 or ISO 21434, are now comprehensively covered in 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 guidelines and correct the model automatically, which helps  ensure the traceability of safety requirements in models and ultimately meet the specific functional requirements of ASIL. The cybersecurity of the coding language is also ensured. Figure 11 illustrates the automated model analysis and correction process in MXAM.