Compliance standards, especially those that involve relatively new functional safety elements, will likely add additional requirements to the development process. For example, the increasing complexity and abundance of automotive electronic systems led to the creation of a new functional safety standard called ISO 26262. Similar regulations for other industries abound; DO-178B/C for aerospace standards and IEC 60601 for medical standards.
Common to all of these safety standards is a risk-based approach to determine the criticality and potential hazards associated with key system functions. The primary goal of these standards is to prevent the failure of a system or device that could cause injury, harm or death. If a failure is unavoidable, then the system should fail gracefully.
ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the product life cycle. In the past, safety design was considered part of a general requirements activity. But merely identifying and tracing requirements in the software and hardware teams are not enough. The common practice of hardware and software teams working in silos will not guarantee the kind of safety coverage required by ISO 26262.
How can the problem be resolved?
One of the key things missing from the general approach to requirements are the traceability links between phases. Many tools do a great job of requirements management and traceability within a particular phase but provide a poor auditable trail for traceability between phases. The activities of comprehensive and complete life cycle traceability become an auditing afterthought to be finished after the project is completed. This is the result that ISO 26262 tries to avoid through documented attention to the development process, decision making and selection of supporting tools.
Tool qualification depends upon how the tool is used, which in turn determines what impact the tool could have on safety. For example, depending upon its usage, can the tool introduce a hardware defect or software bug into the system? How the tool is used within a tool chain will determine the probability that an error introduced by the tool will be detected.
A confidence level is assigned to a given tool, or a flow within a tool, based upon the probability that it will insert or cause an error, combined with the likelihood that the error will be detected during the development process. The importance of the tool confidence level is that it will determine the cost an organization must invest in tool qualification.
As with other standards, implementing the ISO 26262 process requires iteration through a number of basic steps:
- Determine the existing process and tools, or, “Where are we now?” Review the current embedded hardware and software development processes and tool chains. Understand the application(s) to be developed and assign levels of confidence in terms of safety.
- Gap analysis or, “Where would we like to be?” Perform a gap or impact analysis to identify current challenges and process efficiency improvements– often done using model-based design techniques.
- Training and Instruction. Provide design-for-safety training and instruction to address the previously identified gaps.
- Hands-on deployment support. Apply the knowledge gained in the previous steps to a specific pilot project. This will require assistance in a wide range of areas including requirements traceability, modeling, simulation, code generation, verification, validation, tool qualification and system integration.
Alignment with Best Practices
This holistic approach to functional safety exemplifies several key elements of good system engineering processes: collaboration, traceability, validation and verification (V&V), risk analysis and mitigation, and careful integration within the tool chain.
To learn more about how teams creating products for any safety-critical industry can lower the costs and risks of complying with functional safety standards, CLICK HERE