How to ensure functional safety, according to ISO 26262

In modern cars, driver assistance systems more and more increase both convenience and safety. Many of these systems reduce the possibility of human errors, which still are the main cause of accidents¹. Recently, self-driving cars can in most situations even operate without any direct human control. This way, much of the responsibility for preventing accidents moves from the driver to the car – and, thus, to the manufacturers and their suppliers. This means that the functional safety of cars becomes more important than ever. For this reason, all safety-critical systems of a car need to be developed according to ISO 26262, which defines mandatory requirements for the development process. This article explains how requirements traceability can help to fulfill these requirements successfully and sustainably.

Car accidents that are caused by a malfunction of a car system, as opposed to a human error, can have very severe consequences for the car’s manufacturer. The public image of the brand and even of the whole company can become damaged and adversely affect future sales.

Additionally, manufacturers can be held legally accountable in case of an accident, if it could have been prevented by applying the “usual” techniques that are used by their competitors. This includes systems that have not been produced by the manufacturers themselves, but by their suppliers.

Therefore, car manufacturers must require their suppliers to apply state-of-the-art methods for ensuring the safety of the systems that they buy. They check fulfillment of this requirement by performing audits, i.e., meetings during which the supplier must convince the car manufacturer that they carry out the steps necessary to guarantee the safety of their products.

What is ISO 26262?

ISO 26262 provides is a framework and a common understanding for establishing and assessing the development processes and methodology that the manufacturer follows to develop the technology.
It is needed to assess what is required from the car manufacturers and what they in turn need to require from their suppliers. Such a common ground is provided by different standards. The most relevant standard for the functional safety of cars is ISO 26262.

The ISO 26262 standard recommends specific measures to be taken during the development of car systems on the three levels of hardware, software, and the system as a whole. Of course, new technologies may become available and their application can become mandatory after a while, in addition to adherence to the standard. ISO 26262 was originally released in 2011, but has been updated in December 2018 in order to adapt to the new state of the art.

ISO 26262 requires a general concept for the functional safety of the whole car, which must be realized by a system architecture that consists of components. Which safety measures need to be undertaken when developing a given component, depends on how critical the correct behavior of this component is to the safety of the car.

According to the risk of severe accidents, each component must be assigned an ASIL (Automotive Safety Integrity Level). Incorrect behavior of a component with the highest ASIL D can lead to life-threatening or even lethal injuries with a high probability and no way for the driver to control the situation.

Systems are assigned lower ASILs when malfunctions lead to less severe injuries, are less likely to happen, or can be controlled more easily by the driver. The lowest ASIL is A. Systems with an even lower risk are not considered to be safety-critical and need not fulfill any special requirements beyond usual quality assurance.

Why can it be hard to fulfill ISO 26262?

“Fulfilling” the ISO 26262 standard requires suppliers to convince auditors that each component has the correct ASIL and that at least all the “highly recommended” points for that ASIL are taken into account. There is some flexibility when a convincing case can be made that something suggested as “highly recommended” is not actually necessary, because better alternatives have been implemented or because that recommendation is not applicable for a particular case.

At the end of a successful audit, auditors must have reached the conclusion that the whole development process ensures that all safety goals will be reached. Suppliers need to provide evidence to show that their development process actually guarantees that. Unfortunately, this can become a very challenging task when the components in question are very complex – and this case becomes more and more common.

A company that develops components produces artifacts (called “work products”) like, e.g., requirements documents, source code, or test documents. The recommendations contained in ISO 26262 define the artifacts that must be produced, actions that need to be performed on them, and properties that these artifacts must have in the end. Often, these recommendations involve several artifacts at once and their relations to each other.

The following picture shows a small example of some relations involving an Enterprise Architect model (RainSensing) for the implementation of the control software for a rain sensor. On the one hand, it is related to the software requirement (SW-R 4.2.1.1) that it implements. On the other hand, it is also related to a corresponding test of the modeled functionality and to a Simulink model (RainSensor) that realizes the model on a lower level.

Please note that the example only shows the relations to other artifacts that are directly relevant to the RainSensing artifact. Of course, these other artifacts, in turn, have relations to further artifacts, which may be indirectly relevant to RainSensing.

Managing complexity

A large portion of the behavior of many modern car systems is defined by their software, thus especially the software development part of the development process tends to produce a large number of artifacts. Software makes it easy to define extremely complex behavior. It is not so easy, however, to ensure that this behavior is actually correct.

A higher complexity means that there are more possible states of the system. The system needs to behave correctly in all of them, which means that the correct system behavior in a larger number of situations needs to be specified, i.e., more requirements need to be defined. These requirements must be implemented and tested, which will further increase the number of artifacts that are required for fulfilling ISO 26262, due to the additional complexity.

To manage this complexity, components are often hierarchically subdivided into smaller components on a lower level that realize only a part of the functionality. In this way, developers can concentrate on solving smaller local problems that are easier to understand. This is necessary, because developers can only handle so much information at once and tend to make errors when they have to take more into account than they actually can handle.

For this reason, a hierarchical structure of software components is “strongly recommended” even for ASIL A. Unfortunately, each hierarchical subdivision of components increases the total number of development artifacts that are relevant when verifying the compliance with ISO 26262.

Why is traceability necessary to fulfill ISO 26262?

Usually, a high number of development artifacts is not the biggest problem, since the number of relations between them is often even much larger. Developers of components need to keep track of which parts of their implementation realize a given safety requirement and which test cases (or other measures) verify that these implementations actually work.

Requirements on higher levels of abstraction may need to be refined by subordinated requirements in more technical detail in order to implement them. The relations between requirements on the same as well as on different levels in the resulting hierarchy are essential for understanding the system and the way its safety is guaranteed. Therefore, ISO 26262 explicitly states that requirements traceability between these development artifacts needs to be ensured.

Requirement traceability means that developers are able to trace requirements to other development artifacts that are needed to ensure that these requirements are actually fulfilled. As already mentioned in the previous section, these development artifacts usually include other requirements, implementation units, artifacts that describe verification measures and their results, and more.

In order to guarantee traceability, the relevant relations between these artifacts must be documented somehow. These documented relations are called “trace links”, or simply “links” or “traces” if the context is clear.

The following picture shows an example for some possible trace links between development artifacts related to one particular stakeholder requirement (SH-R 2.1.1). The actual graph is about three times as big. Manual analysis of these links will become exceedingly challenging even with only a few of these top-level requirements.

It can be very helpful to ensure traceability also in cases that are not explicitly required by ISO 26262, because you might have to demonstrate that you fulfill other recommendations that implicitly need traceability. For example, a formal specification of your implementation will not help much, if you cannot produce it during the audit for a given part of your implementation. It isn’t sufficient that the recommended artifacts exist, you also have to be able to find them.

You can also use the trace links to perform different kinds of analysis on your system:

• You can validate that guidelines and modeling rules have been correctly applied by checking whether relations between artifacts exist that are either required or forbidden by these rules.
• Because requirements and implementations are usually defined on several levels of abstraction, you also need to make sure that these different levels are consistent with each other. For example, interdependencies between subcomponents on a lower level imply that such interdependencies must also exist on a higher level.
• One major reason for implementing behavior in software is that it is easy to apply changes even long after the car has been manufactured. An impact analysis can show in advance which effects changes to the software would have, so that possible safety violations due to these changes can be identified and resolved quickly.

There are several cases where a coverage analysis based on the trace links can show that recommendations of the ISO 26262 standard are fulfilled:

• Test coverage can be computed for source code instead of or in addition to computing test coverage for requirements.
• Coverage can be measured for different kinds of tests, e.g., robustness tests versus tests of resource usage.
• You can check for coverage of your software architecture and software units by design specifications.
• Software units that are not linked to requirements might bring in unspecified functionality, which is very problematic in safety-critical systems.

Furthermore, you can use the traceability information in conjunction with other techniques to increase their effectivity. Let’s say you use requirements-based testing. Then you have to make sure that all your requirements are in some way covered by tests, directly or indirectly. A high coverage of requirements by tests can be a compelling argument for the quality of your software.

To compute the coverage of your requirements, you need the trace links that represent your requirements hierarchy and the trace links that define which requirements are directly covered by test cases. Based on that, you can compute which requirements are indirectly covered. You’ll probably want to automate this step in some way.

The usefulness of traceability is not restricted to the audit. Trace links are essentially a type of documentation that makes information about relations between artifacts explicit. Developers being unaware of implicit relations between artifacts might very easily lead to safety violations.

Such violations are not restricted to programming errors: in ISO 26262, interdependencies (“interference”) between components mean that all of them need to be developed according to the highest ASIL of any of those components. Ignoring such interdependencies calls the validity of any efforts to achieve safety into question. This kind of error is especially likely when components are changed at a later point in time, possibly by other developers.

How can we implement traceability?

A trace may be documented by simply storing a globally unique identifier (GUID) of one artifact together with, or as part of, another artifact. For example, a comment in or above the source code of a C function might contain references to specific sections of test documents that describe the requirements which need to be considered by the implementation of this function.

However, traceability in this case would only be unidirectional. That is, when given the C function, we could easily find the text that describes the requirement, but not vice versa. For bidirectional traceability, we also need to uniquely reference the C function within the requirement’s text. However, if bidirectional links are implemented as two unidirectional links, they might become inconsistent due to later changes.

When storing links in the way described above, it can be very hard to get a general overview of which links exist between which types of artifacts. However, this might be necessary, for instance, to determine the coverage of requirements or source code by tests. Since a good test coverage can be an indicator for a high software quality, such information can be very useful in an audit.

Alternatively, links can be stored separately in their own files or as database records. This makes it easier to get an overview and to ensure consistency. On the other hand, however, when working with an individual artifact, it is less obvious which links to other artifacts exist. As a consequence, the developer might overlook relations represented by these links. Also, missing links for (implicitly) existing relations could go unnoticed. Both can lead to wrong decisions based on incomplete information.

A particularly popular way to centrally store traceability information is a requirements traceability matrix. Another blog post specifically addresses the issues with this technique. That article also points out some issues that apply to other manual approaches as well.

How can we reduce the effort for maintaining traceability?

The sheer number of trace links in a typical project makes it nearly impossible to handle traceability without any automation. This is already an issue when trying to understand the available information, but even more so when trying to keep it up-to-date and consistent.

Ideally, links should be created and updated automatically or with minimal human intervention. To really take advantage of traceability, you need to be able to perform different kinds of analysis on the data (as discussed in the previous section), which rarely can be done manually. Fortunately, some tools to support these use cases exist, but there is certainly room for improvement, and many projects require custom-made solutions or adaptations of existing ones.

An additional challenge is that trace links often reside in files of various document formats. The reason is usually that several different tools need to be used within the project, because each of them only solves one particular problem.

The following picture shows an example of a possible set of artifact types, involved in the development of a project, and their possible interrelations. They are arranged (roughly) according to the V model, i.e., with development artifacts on the left-hand side and the corresponding tests on the right-hand side.

The icons indicate the different tools or document formats in which the artifacts are stored. In this example, test specifications and results are stored in XML, Excel, or Word. On the implementation side, Excel, Simulink, Enterprise Architect, and YAKINDU Statechart Tools (Information: YAKINDU Statechart Tools Is Now itemis CREATE) are used for specification and design, while the software itself is written in C. Requirements are stored in IBM DOORS.

To avoid involving that many formats, one could try to reduce the number of tools by applying an integrated solution that addresses as many steps of the development process as possible. However, this may mean that you are forced to shape your process around that particular tool, instead of finding the best set of tools as a solution matching your process.

Furthermore, this approach carries the danger of a “vendor lock-in”, i.e., you might end up in a situation where all your important information is stored in the format of a tool that becomes unmaintained or for which the provider requires exorbitant licensing costs from you. In such cases an additional problem will probably be that your employees have become accustomed to working with that tool and are to some extent specialized in it. This means it will require time and effort for them to learn new tools.

Replacing only one individual tool is usually much easier. You can further decrease risk by using standardized document formats that are supported by tools from different vendors. Generally, a tool with a functionality that covers a very broad area can’t solve each individual task to the same extent as one that is specialized for that particular task.

There are dedicated solutions for managing traceability that can be tailored towards the particular set of tools that you use. They provide means for visualization and analysis of trace links regardless of how these links are stored. This allows you to keep the advantages of using task-specific tools while solving the problem of taking into account several different document formats.

Do I need traceability if I don’t need to fulfill ISO 26262?

If you work on safety-critical systems that are not covered by ISO 26262, other standards or regulations might still require you to ensure traceability. Even if this is not the case, you could need it anyway. If your product is ever suspected to have caused an accident, you might be asked for information about how you tried to prevent this. Traceability would help you to show that you did your best.

If you are not working on safety-critical systems, traceability can still help. You create traceability by documenting how the development artifacts relate to each other. Ignoring these relations can easily introduce errors into any system.

Like all kinds of documentation, documenting trace links requires effort. Such effort is not restricted to initial trace link creation. Keeping them up to date also requires a considerable amount of work. If you are not explicitly required to ensure traceability, you have to decide whether the benefits are worth the costs. It depends on which impact errors in your product could have.

Where can I learn more about requirements traceability?

You can already find a number of blog articles about various traceability topics in our blog, both in German and in English. We often discover new and interesting aspects of traceability when working with our customers to find and implement the right traceability solution for their particular projects. Thus, we will continue to publish more articles in this area.

If you’d like us to tackle any specific traceability-related topic or question in a future blog post, please make your suggestions in the comments section!

¹ In 2021, according to the Federal Statistical Office of Germany (Statistisches Bundesamt), 306,292 traffic accidents with personal injuries in Germany had driver-related causes (Link to www.destatis.de/EN). In the same year, only 3,333 traffic accidents with personal injuries were caused by technical faults (Link to www.destatis.de/EN).