Functional safety verification builds safer cars

Although the functional verification requirements for automotive devices may be similar to those of mobile SoCs, the functional safety requirements are quite different – and much more critical.

Both functional verification and functional safety verification strategies set out to find systematic faults, caused, for example, by design bugs, so that they can be fixed before the devices are shipped. However, for random faults the goal is quite different – in functional safety verification the goal is to check that a device’s safety mechanisms deal with such faults without allowing hazardous situations to develop.

Automotive safety verification must work with functional verification, and requires new perspectives and approaches. Even if a feature has been implemented perfectly and thoroughly verified to meet its functional specification this does not guarantee that it is safe, because functional verification does not take faulty behavior into account.

Figure 1: IP-level safety verification

Have a look at Figure 1. A typical safety requirement for this IP block could be that 'Port Y1 should never take on value A as long as port Y2 is going through sequence B'. The design logic may be implemented so that this situation is impossible, and any design bugs are found and fixed during functional verification. From a safety verification perspective, however, imagine that a hardware failure causes a stuck-at or random fault to appear in the logic cone of port Y1, causing it to take on value A and so create a hazard.

Designers can’t model these scenarios using traditional functional verification strategies, but must treat them as injected faults to be explored through a functional safety verification strategy. The design’s behaviours must also be verified to check it can diagnose and recover from such scenarios, in ways described in the safety requirements for the block.

Functional safety verification, therefore, is about testing what happens when external events force a design into illegal or unexpected states. Designs may be expected to continue working without a loss of functionality, or with reduced functionality, or to send out diagnostics information. This kind of fault-simulation methodology can be implemented using Synopsys’ Z01X fault simulation solutions, which can model a broad range of relevant faults and evaluate the effectiveness of the design’s safety mechanisms to manage random hardware failures.

This type of ‘what if’ testing is powerful, but faces a particular challenge because it is hard to know how much testing is enough – there’s always another scenario that could be checked. Fortunately, the ISO standards body has applied some intellectual rigour to this issue in its development of the ISO 26262 standard. It defines frameworks for an automotive safety verification methodology based on this type of fault simulation, to assess and eliminate unreasonable risk caused by such faults occurring in the design.

ISO 26262 is an adaptation of IEC61058, which sets out to define requirements and processes with which to verify the safety of electrical and/or electronic systems within automotive systems. ISO 26262 narrows its scope, defining the following issues:

• Automotive safety lifecycles, including management, development, production, operation, service and decommissioning
• Automotive-specific approaches to analysing risk and determining Automotive Safety Integrity Levels (ASILs) for the elements of the system
• An ASIL-based safety requirements specification to avoid unreasonable residual risk
• The necessary validation and confirmation measures
• Requirements for relationships with suppliers