ASIL CAPABILITY VS ASIL REALITY

In the modern environment of functional safety and ISO 26262, vendors increasingly advertise their components as “ASIL Capable.”  With no other information this statement has no weight.  Any hardware part or software component can used in any system to any ASIL requirement.  A resistor, microcontroller, bytes of executable code – anything can be incorporated into a design so long as the total design provides the necessary protection from systematic and random failures – and has the evidence to support those claims.

As a concrete example, an “ASIL D capable” electronic control module cannot indicate that module satisfies any arbitrary ASIL D safety requirement.  The microcontroller itself, the circuitry connected to the microcontroller, the processes used to develop software, and even the environment in which the controller is used will all impact the highest ASIL which can be achieved by the controller.

To determine if an “ASIL Capable” controller will satisfy the ASIL requirements for your system, you will need to have access to:

• The assumptions of use that went into the design and design processes for that element. Without knowing the safety functions designed into the module, no statement can be made about the suitability of any function for a particular use or in any particular environment.
• The safety mechanisms associated with all the functions on the module, including any assumptions about FDTI and FHTI built into the design. Are all input/output latencies known?
• The possible dependent failures of the component. Access to the internal design information for the controller and its reports is often required to understand all the possible dependent failure modes.
• Detailed hardware metrics. For a complex component, the hardware evaluation criteria for ISO 26262 requires an understanding of the failure rates associated with each specific combination of controller functions used in support of a safety goal.  PMHF can vary by orders of magnitude for different circuits and collections of circuits on the same control module, even when controlled by a functional-safety microcontroller and software developed to an ASIL D process.
• Software development processes. Many controllers include factory-supplied software. Assurance regarding the development processes, details about the assumptions of use of the software, and information related to the software architecture and software dependent failure analysis are necessary to develop a safety argument.  An ASIL D lockstep microcontroller can only support ASIL D safety goals if software development follows the appropriate processes and guidance for coexistence and freedom from interference.