Getting A Handle On Your Automotive SoCs For ISO 26262

When it comes to safety and automotive systems, ISO 26262 is the standard by which system vendors are judged. As with all things the devil is in the details. To be compliant to the standard, design teams must have a well-defined and rigorous design and validation process in place that copiously documents all the requirements of their system. Additionally, they must also be able to prove that all the system requirements were in fact implemented and validated satisfactorily. These requirements are representative of how the system should respond when things are going right.

Because safety is involved, ISO 26262 also compels designers to specify how the system will respond when things are not going right. This creates another set of requirements that describes how the system is to respond to both permanent (bugs) and intermittent faults. As with the design requirements, you must also be able to trace these requirements through implementation and verification.

I’ve been on a lot of software teams and while there are usually good intentions, it seems that it is in the validation stage where things are usually lacking. Perhaps this is because most of the software with which I’ve worked hasn’t been deemed “safety critical”. None the less, it scares the death out of me to think about how rigorous a design team needs to be when working on something like autonomous driving systems. Fortunately, Mentor, a Siemens business, has a tool called ReqTracer that can be used to help design teams get a handle on this problem.

ReqTracer is a tool used to manage and track requirements by providing traceability from requirements and plan documents, through implementation and verification. The tool allows an auditor to select and trace a specific requirement to prove that the requirement was indeed implemented and verified by the design team. The tool however is not just useful for auditors. Design teams are finding that it is a great tool to help them organize and communicate between various functional teams that are working on the system.

As an example, system functional requirements are typically generated from a set of system “use cases”. The resulting functional requirements may impact system hardware, software or both. There may also be functional safety requirements of the system that interact with these functional requirements. Per the ISO 26262 standard, all these requirements must be documented along with implementation and verification plans for each requirement. There are teams of people that work on various parts of the design (e.g. system designers, hardware RTL engineers, hardware implementation engineers, software designers, logic validation engineers and the like). For the system to work, all these people must be in sync with the requirements, implementation and validation plans.

ReqTracer is used to organize a design project by gathering information from a wide variety of sources like office documents, requirements databases, design and simulation databases etc. and then used to draw the lines that connect the proverbial dots between individual requirements, design implementation and validation files and final validation results. Once these relationships have been created, ReqTracer can be used to report on and visualize the development process as it proceeds. Any team member can visualize and trace requirements to actual status of implementation and validation for those requirements. A designer can ask, “What should I work on next?” or a quality team can ask, “What tests have not yet run?” and ReqTracer will be able to highlight those requirements that have been met or not met.

ReqTracer can also be used to manage changes to requirements as the design and implementation process proceeds. Rarely are all requirements known before design starts. Design is usually an iterative process whereby additional items, sometimes called derived requirements, will come out of the design process. There may also be missing requirements that emerge at the last minute before the design is complete. Last-minute changes can be the costliest, as they can have far reaching impacts across the system. All these requirements must also be tracked and traced to ensure that they too have been properly implemented and verified.

The beauty of ReqTracer is that it can be used to visualize the impact on the system for a given requirement change. The tool will let the design team visualize all the work items that will be impacted by a proposed requirement change, leading to a more informed decision-making process before accepting additional requirements. If the new requirement is accepted, ReqTracer will also ensure that no components affected by the change will be forgotten in the last-minute crunch to implement the requirement.

Interestingly, a tool like ReqTracer may be at first thought of as a necessary evil. You really need something like this to be able to work your system through the ISO 26262 process. Upon closer examination though, it turns out the necessary evil may be in fact be more of a big productivity booster for your team. I like tools that give designers more control and visibility over their design processes. Even better are tools that boost your overall team productivity. Having a good understanding of where your project stands, what has been done and what still remains, is key to predictable design schedules. And in the world of ISO 26262, all the better that you can ensure that your design has complete coverage for its requirements. ReqTracer is a unique tool in this regard and is well worth a look if you haven’t already.

Personally, when I get my first autonomous vehicle, I’m going to be really hoping that ReqTracer was used by the design team who put it all together.

See Also:
Mentor ReqTracer datasheet
Whitepaper: Automotive Defect Recall? Trace it to Requirements