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

Looking for a basic understanding of what you need to address safety requirements when developing software components? Here you can find a corresponding video along with a whitepaper for download.

Back to Functional safety

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.

Your free whitepaper

A quick summary of product development at the software level? Our free whitepaper contains all the important information, including helpful illustrations, on the sixth part of ISO 26262 – ideal for anyone new to the topic of process improvements for safety-critical systems.

However, we’re not talking about whether the specification itself – for that software in the vehicle – is sufficiently safe. This is another topic called safety of the intended functionality, or SOTIF. An example of such an inadequate specification is when a vehicle manufacturer sells automated driving and suggests to the driver that he can read the newspaper while driving, but that the software, according to the specification, cannot distinguish a trailer standing on the road from a clear road with a blue sky. Then the software can be correct in terms of functional safety, but not in terms of its actual function.

So, when it comes to everything that needs to be considered when developing safety-relevant software, you have to apply part 6 of ISO 26262.

In nine lessons, you will learn what you have to do additionally or differently in the individual phases of software development.

Image   Structure of ISO 26262:2018
ISO 26262:2018 Part 6 – Product development at the software level

Road safety not only depends on compliance with traffic regulations, but that the vehicles themselves pose a risk to human life if they behave incorrectly. For example, if a car accelerates incorrectly without someone actuating the accelerator pedal. The more modern the vehicles become, and the more progress is made towards automated driving, the more software in the vehicles determines their behavior. The safety of vehicles, be they cars, trucks or motorcycles, is increasingly dependent on error-free software.

With increasing proportions of software in vehicles and with further steps towards automated driving, the safety of vehicles depends more and more on error-free software.

This conclusion justifies that software development for automotive use must be different from software development for other applications. It’s simply unacceptable if software does not respond to a driver’s braking request simply because it’s busy cleaning up memory.

Which strategy leads to error-free software? 

Let me start of by explaining that software, unlike electronic components or memory areas, cannot fail randomly. If software doesn’t do what it’s supposed to do, it’s a systematic fault by definition.

Examples of systematic software faults

  • Not all of the prescribed tests have been successfully completed, and yet the software has been released.
  • The allotted time for an algorithm to detect a dangerous traffic situation was calculated as too long, so that a collision occurring beforehand is inevitable.
  • The state transitions of a control unit are incompletely specified, so that it’s left to chance during programming what the software does.

To prevent all of these things from happening, software must be developed using an up-to-date and sophisticated process.

Software faults must be avoided through systematic development. Errors must be prevented.

Prevention is good, but prevention is no guarantee that a situation will not occur that wasn’t thought about.

The occurrence of faults must be countered by mechanisms for fault tolerance.

Mechanisms for fault tolerance

  • 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.

We're here to help

Let us know how we can reach you.

General topics

Within the entire safety lifecycle, which we already know from the previous white papers and videos, software development is integrated in parallel with hardware development as a separate discipline within the system level.

For software development, the reference model is defined in ISO 26262. It is a V-model, almost identical to that defined in Automotive SPICE. The focus here will be on adaptations specifically for automotive functional safety.

In terms of functional safety, software development is based on the technical safety concept with its technical safety requirements for the software, shown above in the top left corner. The developed software then flows into “system and item integration and testing”. We are now concentrating on actual software development.

Functional safety requires the software development process to be adapted to the requirements of ISO 26262.

The next two clauses of ISO 26262 require analysis from you to ensure your hardware is suitable for the corresponding ASIL.

First of all, you must demonstrate that the hardware has sufficient mechanisms for detecting and controlling random hardware failures. Safety mechanisms must be effective at certain percentages.

Then you have to demonstrate that the probability of failure is low enough. Evidence must be provided of low enough safety goal violation rates due to random hardware failures.

Both clauses contain automotive-specific metrics and methods that you have to implement, but I will explain them in a separate video/white paper.

SINCE 2008

We’re proud that we have been one of the pioneers of functional safety since 2008 and that this has given us the opportunity to leverage our experience in developing the ISO 26262 safety standard.

Functional safety in automotive electronics? We’re the experts!


We have a wealth of experience in functional safety according to ISO 26262, having conducted over 700 projects with more than 100 clients worldwide.

Functional safety in automotive electronics? We’re the experts!


To date, we have trained more than 100 specialists under the TÜV Rheinland Functional Safety (Automotive) certification scheme.

Functional safety in automotive electronics? We’re the experts!

18 Experts

We already have 18 experts certified under the TÜV Rheinland Functional Safety (Automotive) scheme, or privately approved as official trainers.

Functional safety in automotive electronics? We’re the experts!

+250 YEARS

If we add up the experience of our experts in the field of functional safety, it comes to no less than 250 years.

Functional safety in automotive electronics? We’re the experts!

Classic manual

Who wrote the classic manual on Functional Safety in Practice, or Functional Safety Essentials? We did.

Functional safety in automotive electronics? We’re the experts!

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.

Software safety requirements

Technical safety requirements must be detailed down to quality software safety requirements in order to be implemented in the software.

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”).

Software architecture

The software architecture must implement all functional requirements as well as safety mechanisms.

What this points to is the intended functionality and the software safety requirements. In electronic control units, the actual functionality and its safety features are mixed and often cannot be separated.

The ISO 26262 requirements largely overlap with the Automotive SPICE process on software architecture, which is why I would like to add only one aspect from the point of view of functional safety.

You have to carry out so-called safety analyses, in which you understand dependencies between failures. If you want to implement individual parts of the software with different ASILs, you must have good arguments as to why software implemented with weaker criteria, that is, “more error prone” software, does not endanger more critical software which was developed with more rigor. This is called “freedom from interference”.

The analyses must consider runtime behavior, memory areas and message traffic.

Ultimately, all the analyses are about securing the software design.

Safety analyses must be performed to understand the dependencies between software components and to validate the software design.

Unit design and implementation

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.

Unit verification

We now leave the left design side of the V-Modell and look at the right side for integration and testing.

From the point of view of functional safety, I see two things that I would like to highlight as major differences for software development in the automotive sector.

Software integration and tests must be specified using a certain methodology and carried out successfully.

Test coverage must be measured to understand the completeness of tests and to support the rationale for having achieved test goals.

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.

Software integration und verification

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.

Test of the embedded software

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.
  • Improving your processes to keep them up to date with the latest safety standards – also so you can develop and sell reliable, available, maintainable and functional products
  • Designing and rolling out safety management systems
  • Conducting safety audits to confirm that your safety management fulfils relevant requirements
  • Knowing for certain if a supplier really can provide you with the right components
  • Building the capability to assess the functional safety of electronic systems and components 
  • Building the capability to provide staff training on all aspects of functional safety

Download Whitepaper