Q&A: Prasanth Viswanathan Pillai, Functional Safety Architect at Texas Instruments

As part of Automotive IQ’s Safety and Security Series, the ISO 26262 to Semiconductors conference was held in December 2018 in Germany.

The event tackled the safety challenges of the semiconductor with discussions aimed at sharing the latest updates on ISO 26262 Part 11, improvements of semiconductor usage in safety-critical systems, discovering innovations in highly automated driving that the semiconductor sector can benefit from, and more.

One of the conference's guest speakers was functional safety architect for Texas Instruments, Prasanth Viswanathan Pillai. Here are his thoughts surrounding the issues raised at the conference:

What functional safety challenges still remain for semiconductors?

With increased deployment of semiconductors in automobile and industrial markets, functional safety is becoming a critical dimension of semiconductor design. There are quite a few functional safety challenges associated with developing semiconductors to be used in these markets.

Functional safety standards like ISO 26262 address the ‘what’ aspect of safety requirements – what norms or guidelines are to be adhered to, to ensure functional safety of the application. The ‘how’ part – i.e. how we select the safety mechanisms considering tradeoffs associated with area, power, application MIPS impact, etc.? – to meet these requirements is still subjective. It is the ‘how’ part where semiconductor vendors spend most of their time and effort.

While designing system-on-chips (SoCs), semiconductor manufacturers procure Intellectual Property (IP) from external suppliers or use available IPs. Not all these IPs may adhere to the ISO26262 requirements. This forces the SoC integrator to design an ISO 26262-compliant SoC using non-compliant or partially compliant building blocks.

Another challenge is to ensure that the tools used during semiconductor development have the proper Tool Confidence Level (TCL) classification and adequate qualification performed as per the requirements listed in the standard. Due to the complexity of the tools and algorithms involved and the legacy nature of Electronic Design Automation (EDA) software, there has to be collaboration between EDA vendors and the semiconductor developer to come up with requirements that will allow the qualification criteria to be met.

There are a number of challenges to consider, and it is from these challenges that semiconductor manufacturers are innovating to enable functional safety solutions.

What issue in particular is of interest to you in part 11 of ISO 26262?

ISO26262 Part 11 is the new chapter which was introduced in the 2018 version of the standard. This provides the functional safety requirements from a semiconductor perspective. Topics which are of interest to me in the new part include analysis of dependent failures, fault injection, safety analysis of analog and mixed signal components, etc.

The requirements regarding Dependent Failure Analysis (DFA) for semiconductors were not adequately addressed in the previous version of the standard. As the application complexity increases, semiconductor developers implement safety functions having different criticality, for example the co-existence of safety functions with integrity requirements of ASIL-B and ASIL-D, in the same SoC.

Also, higher functional safety requirements demand redundancy-based implementation – dual-channel systems. Hence, it becomes important to analyze the weakness of such implementations from a dependent failure perspective, such as faults propagating from a lower ASIL logic to a higher ASIL logic, or common faults impacting the redundancy, and make them more robust. Part 11 comprehends the workflow for DFA where it lists possible dependent failure scenarios, its initiators, mitigation measures, and so on.

Fault injection is another key area addressed by Part 11. Given the complexity of the hardware and software constituting the application, exhaustive fault injection is not an option. This part lists the requirements to contain the effort required and, at the same time, perform meaningful fault injection to evaluate the hardware architectural metrics – Single Point Fault Metric, Latent Fault Metric and Probabilistic Metric for Random Hardware Failures. This section gives the requirements for fault injection methods – direct injection, formal methods and emulation-based methods – extent of fault injection to provide confidence in safety mechanisms, requirements with respect to workloads used for fault injection, etc.

The fault models and failure modes in digital logic are relatively straightforward when compared to that in analog and mixed signal components. Part 11 attempts to bridge this gap in analog and mixed signal failure mode analysis by listing the possible failure modes of commonly used analog components, possible safety mechanisms which can be employed for detecting these failure modes, deriving the failure mode distribution and techniques for safety metric computation.

What are the safety challenges associated with highly automated vehicles?

Level 4 and level 5 autonomous driving require the automotive system to take care of the entire driving situation without any human intervention, even in the presence of a semiconductor failure. At the same time, random failures in semiconductor components cannot be avoided. Earlier, reaching a fail-safe state, where the system reaches a safe state on the detection of a failure, was an option. However, with the advent of highly automated vehicles this is no longer acceptable. These systems should continue to operate, with possibly a lower safety integrity, even in the presence of a failure. The system and the components used to build such a system should ensure a seamless switch on detecting a failure such that the overall autonomy is not impacted. The increase in integration of semiconductor components due to the steep increase in processing requirements, along with increase in failure rate of the semiconductor devices with shrinking of technology nodes, makes it more challenging.

The complexity associated with the hardware and software components used in highly automated vehicles is orders of magnitude higher when compared with traditional systems. It may not be practically possible to fully validate the system before productizing. This forces vehicles to have additional system-level mechanisms to take care of the unknowns, such as a combination of camera, radar and LIDAR along with redundancy for each of these (as applicable) used during navigation, thus increasing the cost.

What aspects of the safety challenges go beyond the ISO 26262 model of hazards caused by malfunctioning behavior?

The traditional model of analyzing hazards caused by malfunctioning behavior becomes inadequate to analyze new systems, particularly the ones used in highly autonomous driving.

The new autonomous driving systems employ artificial intelligence to address several requirements like lane detection, pedestrian detection, and so on. These systems can fail even in the absence of hardware or software failure due to a number of reasons, including limitations of the sensors used (e.g. inability of the camera in perceiving the depth information), algorithms employed (e.g. differentiating sign board from pedestrian), misuse of the systems by the drivers (e.g. dangerous driving), impact from environment/surroundings (e.g. weather), etc.

Functional safety analysis should consider these conditions and take measures to mitigate the risk arising from these. ISO PAS 21448 (SOTIF – Safety Of Intended Functionality) elucidates the improved model required to analyze these kind of risks.

Another aspect which is not covered with the traditional hazard and risk analysis model is security. Security vulnerability can lead to ineffective implementation of safety. This is a multi-faceted problem which needs to be looked at from different directions to analyze the potential risks. These include vulnerabilities during boot (ensuring that the firmware used for booting is reliable), message exchange (communication between components inside the car, Vehicle to Vehicle (V2V), Vehicle to Infrastructure (V2I)), firmware upgrade (ensuring that only authentic sources can update the firmware), key management, etc. There is an effort underway by Society of Automotive Engineers (SAE) to address the security challenges for semiconductor devices.

• Prasanth Viswanathan Pillai was a guest speaker at Automotive IQ's ISO 26262 to Semiconductors conference. Don't forget to check out our full list of conferences on a host of key automotive topics on the Events page.