In the context of ISO 26262, ‘safety case’ is a progressively assembled set of safety arguments to demonstrate an item’s achievement of functional safety. This plays a pivotal role in a project manager’s decision to release a safety-related item for production and subsequent public use.
Nearly all of these safety arguments are work products generated by carefully performing safety activities called out by the safety plan. As we are aware, the core responsibility of a safety manager is to maintain an item’s safety plan and closely monitor the progress of associated safety activities against an agreed timeline.
This sounds straight-forward, doesn’t it? From a management perspective, it does. But, as always, the devil is in the implementation details. In this post, I want to draw focus to the most influential one – traceability.
It is simply impossible to verify and validate safe functionality of an item in the absence of ‘traces’ between relevant requirements, design specifications, analyses and test reports. Without good traceability, a request for change can have a catastrophic effect on even the most experienced and skilled product development teams. Moreover, these links are essential for logical narration of the “safety story” of a particular item to either a functional safety assessor or an appropriate release authority.
ISO 26262 places significant emphasis on traceability, both directly and indirectly, numerous times throughout the safety lifecycle.
That being said, ‘traceability’ is not an alien concept in the automotive product development sphere. The standard merely adds more specificity to an existing “best practice” for purposes of achieving and proving functional safety.
Over the last several years, we have addressed several questions along the following lines:
- How are safety requirements at different sub-phases of development related to one another?
- How should safety analyses be linked to appropriate architectural elements?
- Which safety test phases are suitable and sufficient to verify a particular level of safety requirements or design?
Per my earlier statement, answers to these questions are available within the standard. With patient and thorough examination, they can be unearthed. However, wouldn’t it be valuable to have a pictorial illustration of relationships between key work products in the safety case? I call this the Traceability Schema…
Figure 1 and Corresponding Color Key
Click to view Traceability Schema
- Grey – Function, Malfunction, Hazard
- Orange – Requirement Specification
- Blue – Design Specification
- Green – Part 5 and Part 6 Testing
- Red – Safety Analysis (qualitative and quantitative)
- Black – Item Integration and Testing
- Purple – Safety Validation
Many project lifecycle management tools allow authorized users (presumably safety managers) to build custom relationships between safety artifacts within a given project. Once the work products are linked, the tools are then capable of evaluating and reporting the levels of coverage for various traces in real-time. This not only empowers the safety manager with the ability to closely monitor the progression of the safety case but also enables effective communication between appropriate project engineers as they perform relevant tests, analyses or requirement refinements.
Traceability can singularly make or break an ISO 26262 safety case.
I encourage safety managers and safety engineers to formulate a strategy in advance for handling the convoluted yet important relationships between work products in a safety case. I hope the Traceability Schema in Figure 1. serves as a useful starting point for exploring organization-specific and project-specific strategies for enforcing sufficient traceability.
