Change Management for Functional Safety

By now we’re pretty familiar with the requirements ISO 26262 places on development for automotive safety. The process, procedures and metrics you will apply to meet various automotive safety integrity levels (ASIL). You need to train organizations. In fact you should establish a safety culture across the whole company or line of business to do it right. These days following ISO 26262 is as much about following the spirit of the standard as well as the letter. But – what do you do about change management for functional safety?

Design under ISO 26262

You need to have well established quality management systems such as the Capability Maturity Model for Integration. These aren’t about software tools, though tools may play a supporting role. They’re much more about the whole product development process. And then there’s what you do in the product design to isolate areas that may be susceptible to single point failures. And what you’re going to do to detect and mitigate such failures. Then you’ll run FMEDA analysis to make sure your safety mitigation techniques will actually deliver. You’ll document the whole thing in a safety manual and development interface agreement to ensure integrators will use your product within agreed bounds.

A process to make changes

Phew. You release and ship the product with ISO 26262 requirements all tied up in a bow. Time to celebrate, right? Well – no. Suppose for the sake of argument that what you released is an IP, perhaps targeted for ASIL-D-compliant systems, the highest level of safety compliance. In the normal course of events after release, customers will report bugs and enhancement requests. Things you need to change or extend in your product. What does ISO 26262 have to say about managing these changes?

Any changes in a well-defined quality management system require use of configuration management. In section 8, the ISO standard is quite succinct about what must be achieved in such a system:

• Ensure that the work products, and the principles and general conditions of their creation, can be uniquely identified and reproduced in a controlled manner at any time.
• Ensure that the relations and differences between earlier and current versions can be traced.

Why so brief? Because the automotive industry already has a well-established standard for quality management systems – IATF 16949. No need to reinvent that wheel and indeed there are already linkages between the two standards.

Synopsys application of ISO 26262 and IATF 16949

Synopsys has authored a white paper on how they apply these standards to automotive-grade DesignWare IP development. Under IATF 16949, this starts with an Impact Analysis, per requested change. This will assess not only what product features will be impacted but also what stakeholders will be impacted by the change (I assume this applies through the supply chain). The analysis also looks at what previously made assumptions may need to change and how those change can ripple through the process.

Analysis then drills deeper to quantify the impact of the change, root-cause analysis on what led to the need for this change, dependency considerations and any impact on assumptions of use (AoU). Building on these considerations you create a project plan identifying responsibilities for everyone  involved in implementation. Along with bi-directional traceability requirements to track those changes against the original objective(s).

Once impact analysis is completed, then implementation, verification and validation of the plan can start. Again with a lot of process and checkpoint requirements. And finally, there is a confirmation step, per change request tying back each implementation, verification and validation phase to the original request and impact analysis. At which point you can accept, reject or delay the change.

Double phew! We shouldn’t be surprised that this level of effort comes with tracking post-release change requests to an ASIL-D product (for example)  Nice job by Synopsys on documenting the detail. You can read the white paper HERE.

Also Read:

What Might the “1nm Node” Look Like?

EDA Tool Support for GAA Process Designs

Synopsys Enhances Chips and Systems with New Silicon Lifecycle Management Platform