Product development at system level (part 4 of ISO 26262)

The system level follows the concept phase in the lifecycle. 1st-tier suppliers are usually responsible for the system level, while the carmaker is usually responsible for the concept phase. The supplier delivers a system to the carmaker's production line. If necessary, there are several nested systems and various sub-suppliers.

The first aspect is that the system level must be seen as something that needs explicit attention. I have already explained the first insight, namely that the system level must be seen as such and institutionalized. You must have a system engineer to design this level, including error detection and handling mechanisms.

In the video and the whitepaper, you can see the system level reference phase model. ISO 26262 assigns security activities to three clauses.

• The technical safety concept includes the prerequisites for hardware and software development.

• System and item integration and testing integrates and checks the results of the disciplines over several integration levels, up to the complete system.

• Finally, safety validation must provide evidence that the safety goals have actually been achieved in the vehicle, and that the result of the development can be released, produced and installed in vehicles.

Note: This reference phase model groups development topics logically. Of course, I can only integrate what I have already developed. However, the reference phase model should not be understood in such a way that the finished result of hardware and software development has to be completely available before I can start with integration. In practice, it is always the case that several hardware samples and numerous software releases are built and integrated. This means that the reference phase model has to be used iteratively, several times, and it’s only during the very last iteration that all requirements of ISO 26262 have to be met.

I would now like to explain the clauses of the reference phase model individually. Let's start with the technical safety concept.

Technical safety requirements (TSRs) are mainly derived from the functional safety requirements defined by the carmaker, and these must be made available to the Tier 1. The TSRs are safety requirements asking for the implementation of safety mechanisms. Safety mechanisms are used to detect, indicate and control faults. It must be specified which safe state the system has to change to if an error is detected. You also have to think about tolerance times, which depend very much on the specific application and other safety mechanisms. Requirements must be defined to avoid that errors that do not immediately lead to a violation of the safety goals remain permanently in the vehicle, thus posing a future danger. Finally, it may be necessary to define safety requirements for production, operation and service, and decommissioning.

We are looking at the system level here, for which a system architecture must be developed for implementing the functional (in the sense of the actual desired functionality) and the functional safety requirements.

Functional safety requires that safety analyses are carried out. Examples of analysis methods are failure mode and effects analyses, FMEAs, and fault tree analyses, or FTAs. Their aim is to think systematically, based on methods, about the causes of faults and their effects on the violation of safety requirements. Systematic errors must be taken into account – for example errors caused by incorrect software programming – as well as random hardware faults.

Safety requirements must be detailed enough to be specifically assigned to the hardware and software disciplines for implementation.

The system engineer mentioned earlier has the task of ensuring that there is an explicit specification for the interface between hardware and software (the “Hardware-Software-Interface”).

Finally, the quality of safety requirements and the system architecture must be verified.

The safety validation focuses on the question of whether implemented safety measures are adequate for the intended use of the vehicles. For this purpose, the installed systems are subjected to long-term tests under real-life conditions, for example. Do the systems behave as expected? Can drivers cope with how the system reacts to errors? Do the different vehicle configurations work? Summer and winter tests are used here. Overall, evidence must be provided here that the safety goals have been reached and that the item is functionally safe.