IP to SoC Flow Critical for ISO 26262

In thinking about automotive electronics safety standards, such as ISO 26262, it is easy to jump to the conclusion that they are in reference to systems such as autonomous driving, which are entering the marketplace. In reality, functional safety in automotive electronics plays a significant role in many well-established automotive systems, not just exotic emerging applications. ISO 26262 breaks down system failures into categories, known as Automotive Safety Integrity Levels (ASIL). They range from ASIL A to ASIL D, where D denotes failures that can have the highest potential for causing harm or death. Each of these potential failure types has well defined detection and response specifications.

Let’s consider some of the types of failures that might exist and are necessary to manage in today’s cars without fancy self-driving capabilities. Engine management and control fall within this category. Engine failure during critical driving maneuvers, such as crossing busy roads or merging onto a freeway could lead to injury. Likewise, uncommanded acceleration could prove extremely dangerous. More subtle failures such as premature or failed airbag deployment can lead to human injury. The same goes for braking and traction control systems, where erroneous or missed activation can lead to serious consequences. The truth of the matter is that cars now have dozens of systems that use sophisticated electronics to manage their operation – where failures can lead to big problems.

Many of these systems contain SoCs that integrate multiple IPs for processing, data communication, storage, sensor or actuator operation, etc. Designers of these SoCs need to rely on externally developed IP for portions of them. The issue that arises is that ISO 26262 requirements contemplate whether the IP is developed with the final application in mind, so system level consequences of low-level failures can be understood. There is a concept called Safety Element out of Context (SEooC) that enables us to discuss and deal with IP like this.

Synopsys has released a technical paper that discusses how externally developed IP can be properly integrated into automotive systems that must be ISO 26262 compliant. It is still necessary to develop SEooC IP correctly for it to be considered for use in ISO 26262 compliant systems. The paper outlines the extra processes and development steps needed to properly build and document these IPs. Failure modes for the IPs must be identified and methods for verifying correct operation and detecting the failures must be defined.

There is a clear process for SoC developers to use when integrating externally developed IP. At the system level, when a fault is detected the system must be informed to transition into emergency operation or safe state to avoid a hazardous event. Monitoring, detection and response require bidirectional linkage amid the safety requirements between top level and lower level blocks in the system. The safety integration process needs to also consider the safety aspects, when performed with the proper deliverables ensures that danger from failures is minimized.

Synopsys has a keen interest in this because they are a provider of many automotive-grade IP components that are intended for use in ISO 26262 compliant systems. After summarizing the process for developing and integrating IP for these systems, they outline key deliverables that are essential for the process to proceed efficiently. Test cases and test environments are at the top of their list. Part of ISO 26262 is real-time fault injection to test during operation to see if the system can respond to failures. Fault locations and observation points are important deliverables. IP developers also need to document and transmit their SEooC assumptions. In addition to documentation, formal assertion checkers, test benches and test cases need to be provided as part of this. Finally, a full suite of hardware-software integration validation deliverables should be included. This is a broad set of pre and post silicon verification test method documentation and information.

The process is not a simple one, neither for the IP developer or the integrator. The paper is very helpful in identifying areas where attention should be paid in the overall process. This information is useful in determining if IP has adequate collaterals and was designed with the proper consideration for integration into automotive electronic systems. The paper also is useful for helping identify the work needed in taking properly built IP and integrating it into SoCs for automotive systems. The full paper, titled “Aligning Automotive Safety Requirements Between IP and SoCs” is available for download on the Synopsys website.