Product development on SW level (part 6 of ISO 26262)

This tutorial video is about software development for electronic systems for road vehicles, especially for the software used in control units in cars. If you are involved in such software development, you should probably know what is different from software development in other areas.

We’re talking here about software in road vehicles. That’s all the software in the various control units, sensors and actuators. Functional safety now means that this software contributes to the safety of the vehicles and does not endanger safety. More specifically, the software must be error-free in keeping with its specification. This is what functional safety and the international standard ISO 26262 is about.

• Checksums for messages or memory areas are an example of this.
• Or simply checks on permissible value ranges when entering a software function.
• Or something more complicated, software that runs on so-called safety microcontrollers and is used to monitor whether the actual application software is still running correctly on another microcontroller.

Such software must then bring the entire system and vehicle into a previously defined safe state when errors are detected.

All of these principles underlie software development for automotive applications as contained in Part 6. We now dive deeper into this Part 6.

I want to explain this: It’s a prerequisite that you develop software according to a suitable, documented process that is accepted and that you use. This process must be compliant with ISO 26262. You must have a suitable software development environment, which is no different from non-automotive applications.

You have to comply with coding and modelling guidelines, for which ISO 26262 lists a number of specific criteria. This is typically implemented in the industry by MISRA rules.

A current question is whether agile software development and functional safety are compatible. Yes, they are, but only if a number of things are taken into account. ISO 26262 requires you to provide certain documentation, especially in connection with the safety case. This does not prevent you from having daily stand-up meetings and continuous integration, both of which are very useful.

As soon as you want to release software that is actually going to be installed in vehicles that drive on the road, you have to proceed with rigorous processes. You can then no longer quickly implement a customer request and deliver software.

Correct software behavior depends not only on the software code itself, but also on the data that controls it. This fact requires that your subject configuration and calibration data to the same development process as the software itself.

Finally, with the various interfaces that exist today within vehicles and towards the outside, it is necessary that the cybersecurity threats are analyzed and addressed according to appropriate standards. 

All of these are topics that you must consider in your development approach.
 

These are self-test and monitoring functions for operating system, basic software, and application software. 

It concerns requirements for the detection, indication and control of faults of safety-related hardware.

Requirements must be written for when and how a safe state can be achieved and maintained in the event of a fault, or at least define how a degraded state can be achieved.

Ask yourself the following questions

• What are the requirements for fault tolerance?
• How often must test algorithms run and how quickly must error reactions be implemented at runtime?

Software development must also contribute to the specification of the interface with the hardware (the “Hardware-Software-Interface”).

The next phase is again very similar to any other software development process, for example in compliance with Automotive SPICE. A software unit design is required, which can also be used as a model for applying model-based development. ISO 26262 also has criteria for guidelines that must apply here.

There is no key lesson to capture at this point from a functional safety perspective.

This summarizes in two statements what goes beyond usual software development.

On the level of the individual software units, verification includes

• ensuring safety mechanisms are implemented,
• that there is no unintended functionality in the code
• and that there are sufficient resources – that is execution time, memory, and throughput of messages.

ISO 26262 requires that test cases be developed using a number of methods and that certain kinds of tests are performed. Depending on the ASIL, there are different expectations in terms of what needs to be done. An aspect specific to functional safety is that code coverage has to be measured in order to justify the fact that testing has been carried out intensively enough.

The next phase concerns all further integration and test levels up to the completely integrated software. The topics are the same as those at the software unit level. Have safety mechanisms been implemented? Is there no unintended software? Are there enough resources? Here too, a methodical approach is necessary for test cases and testing. And the test coverage needs to be measured.

Unlike with Automotive SPICE, there is a separate clause for functional safety, which refers to the fact that the developed embedded software must meet the software safety requirements placed on it on the target hardware in the target environment.

It should be tested in different environments. First, the hardware should be tested with the software in a simulated environment. This is called “hardware-in-the-loop”. Then it should be tested in a network of real electronic control units. And finally, it should be tested in prototype vehicles.

Again, test cases must be specified using methods. Some typical examples of such methods are use case based testing, equivalence class generation, and boundary value analysis.

And finally, of course, the requirements must be tested. And faults should be deliberately introduced to test the safety mechanisms. Do the algorithms really recognize faults and trigger the desired reaction?

This tutorial was an introduction to special requirements affecting the development of software for automotive applications.

Please keep these key lessons in mind.

• With the increasing proportion of software in vehicles and with further steps towards automated driving, the safety of vehicles depends more and more on error-free software.
• Faults in software must also be avoided through systematic development.
• The possibility of faults occurring must be countered by mechanisms for fault tolerance.
• Functional safety requires the software development process to be adapted to the content and requirements of ISO 26262.
• The technical safety requirements from the system level must be detailed down to high-quality safety requirements for software.
• The software architecture must implement all functional requirements and safety mechanisms. It is often not possible to separate the two in vehicle electronics.
• Safety analyses must be performed to understand the dependencies between software components and validate the software design.
• A number of methods have to be used for software integration and tests, and of course the tests have to be carried out successfully before the final software version is released.
• Test coverage must be measured. This is in order to evaluate the completeness of testing and supports the rationale that test goals have been achieved.