Let's talk about the system safety architecture in the development phase of automotive functional safety systems

We have introduced the system development stage, TSR, security mechanism, TSC, security analysis and other related contents in detail. Today we will talk about the last part of the system development stage, namely the system security architecture:

System architecture role

System architecture related security mechanisms

System security architecture

01

System architecture role

Architecture is an art and is very important in the development of vehicle systems, software and hardware. Especially in model-based system development (MBSE), architecture is one of the core elements of the entire development process.

Generally speaking, system architecture is usually developed using the universal modeling language UML or SysML in related architecture development software, such as Enterprise Architect, Cameo, etc. Unfortunately, most car companies currently do not have a complete system architecture or a simple architecture description based on PowerPoint or other formats.

In the third part of functional safety concept development and the fourth part of system development, the system architecture is required as an input condition. With the help of the system architecture, safety analysis is performed to derive functional safety requirements (FSR) and technical safety requirements (TSR), and the corresponding safety requirements are allocated to the system architecture.

However, during the system development phase, we also need to further develop the functional safety-related content of the system architecture, integrate the architecture-related safety mechanisms into the system architecture, and form a system safety architecture (Safety Architecture). This will outline the core technical framework required to achieve the system's technical safety requirements and provide a basis for the detailed design of subsequent software and hardware architectures.

02

System architecture related security mechanisms

Many friends have always had a question: what specific safety mechanisms should be adopted for different ASIL levels?

This is a good question. Generally speaking, the higher the ASIL level, the higher the number and quality requirements of the safety mechanisms that need to be adopted.

However, ISO 26262 does not, and in fact, there is no way to clarify which safety mechanisms should be adopted for each ASIL level. It only recommends safety mechanisms corresponding to different coverage rates (medium, high, and low) for the hardware part.

The main reasons are:

Although there are some common security mechanisms, the security mechanisms used are different depending on the research object.

It provides more space and options for the diversity of functional safety technology implementation, making it easier for different companies to implement it based on their own technological accumulation and development conditions.

Providing possibilities for technological upgrading. With the development of technology, many new safety mechanisms have been realized or applied in the automotive industry.

If ASIL levels and safety mechanisms are linked one by one and enforced, many car companies may not be able to launch their cars on the market (you know).

Let's first look at what the system architecture looks like without a security mechanism.

The system architecture aims to describe the composition, interaction and constraints of related items. According to the definition of ISO 26262, related items are composed of one or more systems, and a system should include at least one sensor, one control unit and one actuator. Of course, a system can also contain multiple subsystems.

So the simplest system architecture is as follows:

So what system-level security mechanisms can be integrated into the system architecture to form a system security architecture?

Since the simplest system consists of three parts, the system-level and architecture-related security mechanisms must also be related to these three parts and the communication security between them.

Let's take a look at common security mechanisms related to system level and architecture:

sensor

─ Sensor hardware redundancy ─ Independent power supply ─ Multi-channel redundant acquisition ─ Signal quality detection

Control unit

─ Online diagnosis

─ Comparator

─ Majority Voter

Actuator

─ Actuator hardware redundancy

─ Actuator control signal quality detection

communication

─ Redundant sending

─ Information redundancy (CRC)

─ Time monitoring

─ Question and answer mechanism

It should be noted that the main function of the safety mechanism in the system stage is to outline the core technical framework required to achieve system functional safety and to clarify which technical means should be taken to achieve the corresponding safety goals. It will not involve specific implementation details, which will be further clarified in the subsequent software and hardware development stages.

From the above security mechanisms, we can see that although there are many types of security mechanisms, they all come from the following three perspectives:

1

Redundancy: Use the same functional components (multiple hardware) to reduce random hardware failures and increase the reliability of functional safety, such as sensor and actuator redundancy.

2

Multiplicity: Used for fault-closure paths, using multiple shutdown paths or protection devices provides protection against failure of a single device.

3

Diversity: Diversify the design using different types of equipment or software to reduce the possibility of common cause failures.

03

System security architecture design

Now that we understand the security mechanisms related to the system architecture, we will integrate these security mechanisms into the original system architecture and look at the different components of the system. What does the system security architecture look like after integrating the security mechanisms?

3.1 Sensor part

First, we integrate some sensor security mechanisms into the system. It should be noted that the sensor here represents broad input information, which can be specific sensor signals or other types of communication information, such as CAN, SENT, etc.

Sensor hardware redundancy (of course the sensors must be independently powered) is mostly applicable to signals with very high ASIL level requirements, such as ASIL C, D, especially D. Its main purpose is to avoid random failures of sensor hardware and increase the reliability of system input information through signal mutual verification.

The redundant sensor hardware acquisition here can be to use the same two sensors to repeatedly acquire the same signal (for example, a pedal signal), or to use different types of sensors to separately acquire two strongly correlated signals (for example, brake pedal position and pressure information, etc.).

Of course, the sensor inputs redundant information, and in the control unit, multi-channel collection must be performed. In addition to the diagnostic information provided by the sensor itself, its signal validity also needs to be tested, including value valid range detection, online monitoring, test pattern, input comparison, correlation, rationality detection, etc.

3.2 Control Unit

The control unit is the most important part of the entire system. The security mechanism related to the control unit actually determines the system security architecture and system complexity to a large extent.

When it comes to control unit-related safety mechanisms, many people's first reaction is controller software layering, controller hardware redundancy (dual controllers, Dual Core LockStep, etc.), watchdog, program flow monitoring, etc.

Although these are commonly used safety mechanisms for control units, from a system perspective, they are relatively too specific. They are only software or hardware safety mechanisms designed for a certain type of fault and need to be specified based on the system safety architecture.

Next, let’s take a look at the system-level security architecture from a system perspective. The subsequent steps are nothing more than gradually applying specific software and hardware security mechanisms to the system architecture.

Generally speaking, all security mechanisms essentially serve two types of security architectures:

Fail to safe

Fail to operational

3.2.1 Fail to safe

Fail to safe is the most widely used safety architecture in the automotive industry. The most typical application is online monitoring, which divides the entire control unit into two parts: function implementation and online monitoring, which is the so-called 1oo1D type system, as shown in the following figure:

in:

The function implementation part is generally developed according to the normal development process, mainly to achieve the functional requirements of the system, without considering functional safety requirements (that is, all QM).

The monitoring unit is used to meet the requirements related to system functional safety. Its main purpose is to monitor the safety of the functional implementation part and monitor online whether the functional implementation part is running as expected. Once a problem is found, the system will be brought into a safe state, stop providing the original functions of the system or maintain the most necessary functions.

It should be noted that the diversified reproduction of all functions of the non-functional layer of the monitoring unit cannot exist independently of the functional implementation part, and the ASIL level directly determines the hardware and software complexity of the monitoring unit.

For systems with higher ASIL requirements, the monitoring unit software is generally independent of the functional layer. To achieve effective monitoring, the monitoring unit not only needs to diagnose the inputs and outputs related to functional safety in the functional layer, but also needs to monitor the calculation logic related to functional safety, calculate the safe output range of the actuator's key control signals, and compare them with the calculation results of the functional layer, and even require additional hardware monitoring of the controller hardware.