There is more and more convenience and safety in modern cars through driver assistance systems. Several of these systems reduce the possibility of human errors, which still are the leading cause of accidents. Recently, in most situations, self-driving cars can even operate normally. This way, a lot of the responsibility for preventing incidents moves from the driver to the vehicle, thus, to the manufacturers and their suppliers. This means that the functional safety of vehicles has become more critical than ever. For this purpose, all safety-critical systems of a car require to be developed according to ISO 26262, which clarifies mandatory requirements for the development process. This article explains how requirements traceability can aid in fulfilling these requirements successfully and sustainably.

Car accidents caused by a malfunction of a car system, as opposed to a human error, can have very critical consequences for the vehicle's manufacturer. The public image of the brand, as well as the entire company, can adversely affect and damage future sales. In addition to this, manufacturers can be held legally accountable in case of an accident if it could have been prevented by applying their competitors' "usual" techniques. This includes systems that manufacturers have not produced themselves instead of their suppliers. Thus, car manufacturers must require their suppliers to apply state-of-the-art methods to ensure the safety of the systems they buy. They check the fulfillment of this requirement by performing audits, that is, meetings during which the supplier is required to convince the car manufacturer that they carry out the steps necessary to warrant the safety of their products.

Definition of ISO 26262?

ISO 26262 provides a framework and a shared understanding for establishing and assessing the methodology and development processes that the manufacturer follows to develop the technology. It is required to assess what is needed from the car manufacturers and what they need to demand from their suppliers. Different standards provide such a common ground. The most relevant benchmark for the functional safety of cars is ISO 26262.

The ISO 26262 standard recommends specific measures during car systems development on the three hardware, software, and system levels. Of course, new technologies may be made available, and their application can become obligatory after a while and adherence to the standard. ISO 26262 was initially released in 2011 but was updated in December 2018 to adapt to the new state of the art. ISO 26262 needs a general concept for the functional safety of the entire car, which must be realized by a system architecture that is made up of components. Which security measures are required to be undertaken when developing a given part depends on how critical the proper behavior of this component is to the car's safety.

According to the risk of severe accidents, you must assign each component an ASIL (Automotive Safety Integrity Level). Incorrect behavior of an element with the highest ASIL D can lead to life-threatening or even lethal injuries with an increased likelihood and no means for the driver to control the circumstances. Systems are assigned lower ASILs when malfunctions result in less critical injuries, are less likely to happen, or can be controlled more straightforwardly by the driver. The lowest ASIL is A. Systems with even lower risk are not considered safety-critical and do not need to fulfill any special requirements beyond standard quality assurance.

Why can it be challenging to fulfill ISO 26262?

"Fulfilling" the ISO 26262 standard needs suppliers to convince auditors that individual components have the right ASIL and that at least the "highly recommended" points for that ASIL are considered. There is some flexibility when you can convince that something suggested as "highly recommended" is unnecessary because better choices have been implemented or because that recommendation is not applicable for a specific topic.

At the conclusion of a successful audit, auditors must have concluded that the whole development process ensures that you will reach all safety goals. Suppliers need to offer evidence to show that their development process guarantees that. Unfortunately, this can become a very exacting task when the components in question are significantly compounded – and this scenario becomes more and more usual.

An enterprise that develops components produces artifacts (referred to as "work products") like, for example, requirements documents, test documents, or source code. The recommendations held in ISO 26262 define the artifacts you must produce, actions that require to be implemented on them, and properties that these artifacts must possess. Frequently, these recommendations involve many artifacts at once and their relations to each other.

Managing complexity

Their software defines a large portion of many modern car systems; thus, the software development part of the development process tends to produce many artifacts. The software makes it easy to define highly complex behavior. However, it is not so easy to ensure that this behavior is correct.

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

Components are often subdivided into smaller segments on a lower level that realize only a part of the functionality to manage this complexity. This is how developers can concentrate on solving more minor local problems that are easier to understand. This is necessary due to developers can only handle a certain amount of information at once and tend to produce errors when they have to take more into account than they actually can control.

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

Additional great topics on software testing:

Application Security Testing – Security Testing

OWASP Compliance With Parasoft Software

API Testing for Reaching Quality and Coverage

What Is API Testing? 2022 Guide to API Testing

Test Data Management for Continuous Testing Process

What Is Service Virtualization? Tools & Testing Examples Process

What Is Unit Testing? Best Practices

Static Code Analysis Tools Deliver Code Optimization

Why is traceability needed to fulfill ISO 26262?

It is not the high number of development artifacts that is the most significant challenge since the number of relations between them is frequently even more effective. Developers of components need to track which sections of their implementation realize a given safety requirement and which test cases (or other measures) prove that these implementations work.

The relations between requirements on the same and varied levels in the resulting hierarchy are crucial for understanding the system and the means by which its safety is warranted. Therefore, ISO 26262 explicitly states that you must ensure traceability between these development artifacts. Requirements on higher levels of abstraction may include the refinement of subordinated requirements by providing more technical detail to implement them.

Requirement traceability means that developers can trace requirements to other development artifacts needed to fulfill these requirements. As mentioned in the previous section, these development artifacts usually include additional requirements, implementation units, and artifacts describing verification measures and results.

The relevant relations present among these artifacts must be documented somehow to guarantee traceability. These demonstrated relations are called "trace links" or simply "links" or "traces" if the context is clear.

It can also be constructive to ensure traceability in cases not explicitly required by ISO 26262 because you might have to show that you fulfill other recommendations that implicitly need traceability. It isn't enough that the recommended artifacts exist; you also have to be able to find them. For instance, a formal specification of your implementation will not aid much if you cannot produce it during the audit for a given of your performance.

You can also utilize the trace links to perform different types of analysis on your system:

  • You can authenticate that guidelines and modeling rules have been correctly applied by checking whether relations between artifacts exist that are needed or prohibited by these rules.
  • Due to requirements and implementations are usually defined on several levels of abstraction, you also need to ensure that these different levels are consistent. For instance, interdependencies between subcomponents on a lower level imply that such interdependencies must also exist on a higher level.
  • One primary reason for implementing behavior in software is that it is easy to apply changes even long after the vehicle has been manufactured. Impact analysis can showcase in advance which effects changes to the software would have so that possible safety violations because of these changes can be identified and resolved fast.

There are multiple cases where a coverage analysis hinged on the trace links can show that recommendations of the ISO 26262 standard are achieved:

  • You can compute test coverage for source code instead of or in addition to computing test coverage for requirements.
  • You can measure coverage for different tests, e.g., robustness versus resource usage tests.
  • You can examine coverage of your software units and software architecture by design specifications.
  • Software units not linked to requirements might bring in unspecified functionality, which is problematic in safety-critical systems.

Let us say you utilize requirements-based testing. Then you have to ensure that all your requirements are in some way covered by tests, directly or indirectly. High coverage of conditions by tests can be a compelling argument for the quality of your software. Furthermore, you can use traceability information with other techniques to increase effectiveness.

To compute the coverage of your essentials, you require the trace links that represent your requirements hierarchy and the trace links that describe which test cases directly cover requirements. Based on that, you can compute which conditions are indirectly covered. You will likely want to automate this step in some way.

The usefulness of traceability is not limited to the audit. Trace links are essentially a kind of documentation that makes information about relations between artifacts explicit. Developers unaware of implicit connections between artifacts might lead to safety violations.

Such violations are not restricted to programming issues. In ISO 26262, interdependencies ("interference") between components means that they need to be developed in accordance with the highest ASIL of any of those elements. This type of error is especially likely when parts are changed at a later point in time, possibly by other developers. Ignoring such interdependencies calls into question the validity of any efforts to achieve safety.

How to implement traceability?

A trace may be documented by efficiently storing a globally unique identifier (GUID) of one artifact as a unit with or as part of another artifact. For instance, a comment in or above the source code of a C function might hold references to particular parts of test documents that describe the requirements that need to be considered for implementing this function.

But, traceability, in this case, would only be unidirectional. When given the C function, we could quickly identify the text that describes the requirement, but not vice versa. We are also required to uniquely reference the C function within the requirement's text for bidirectional traceability.

But if bidirectional links are implemented as two unidirectional links, they might become inconsistent because of later shifts.

When holding links in the way described above, it can be tough to get a general overview of which links exist among which types of artifacts. But, this might be necessary, for instance, to determine the coverage of requirements or source code by tests. Since a good test coverage can indicate high software quality, such information can benefit an audit.

On the other hand, links can be stored separately as database records or in their files. This makes it more straightforward to get an overview and ensure consistency. On the other hand, when working with one artifact, it is not as obvious which links to other artifacts exist.

Consequently, the developer might overlook relations represented by these links. Also, missing links for (implicitly) existing connections could not be noticed. Both can lead to incorrect decisions hinged on incomplete information.

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

How can we reduce the effort to maintain traceability?

A typical project's sheer number of trace links makes it nearly impossible to handle traceability without automation. This is already a problem when trying to understand the available information, however even more so when keeping it up-to-date and consistent. Ideally, links should be made and updated automatically or with minimal human intervention. To take advantage of traceability, you need to perform different types of analysis on the data (as discussed in the previous section), which can not be done commonly manually. Fortunately, several tools to support these use cases exist, but there is certainly room for improvement, and several projects require custom-made solutions or adaptations of existing ones.

YAKINDU Traceability

Another challenge is that trace links often reside in files of various document formats. The reason is that several different tools need to be used within the project because they only solve one particular issue.

One could reduce the number of tools by applying an integrated solution that addresses as many development process steps as possible to avoid involving that many formats. But, this may mean that you are forced to shape your strategy around that specific tool instead of finding the most refined set of tools as a solution matching your process.

Additionally, this approach carries the danger of a "vendor lock-in," i.e., you might end up in a situation where all your essential information is held in the format of a tool that is unmaintained or for which the provider needs exorbitant licensing costs from you. In such scenarios, another challenge will likely be that your staff have become used to working with that tool and are specialized in it. Meaning it will need time and effort to learn new tools.

Generally, a tool with functionality covering an expansive area can't solve each task to the same extent as one specialized for that particular task. Replacing only one individual device is usually much more straightforward. You can further decrease the threat by using standardized document formats supported by tools from different vendors.

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

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

If you work on safety-critical systems not covered by ISO 26262, other standards or regulations might still need you to make sure traceability. Even if this is not true, you could require it anyway. If your product is ever suspected of having caused an incident, you might be asked for information about how you attempted to prevent this. Traceability would benefit you by showing that you did the best you could.

If you are not developing safety-critical systems, traceability can be helpful. You make traceability by documenting how the development artifacts relate to each other. Ignoring these relations can quickly place errors in any system.

Similar to all kinds of documentation, documenting trace links needs effort. Such effort is not prohibited from initial trace link creation. Keeping them relevant also requires a considerable amount of work. If you are not explicitly needed to ensure traceability, you must choose whether the advantages are worth the costs. It is dependent on which impact errors in your product could have.