An inside look at the very complicated automotive safety standard and what you need to know.
I’ve written articles before about ISO 26262 Certification because many SoC design teams are challenged by the barriers they have to overcome to achieve automotive functional safety, especially if they previously enjoyed success in mobility or computing but now want to shift attention to the growing array of electronics used in transportation such as automated driver assistance systems (ADAS).
Even after the articles were published, I continued to hear about the struggles to meet functional safety requirements. So today, I offer the top three reasons to implement resiliency and functional safety measures in hardware rather than software, when the goal is to pass muster for what is known as Automotive Safety Integrity Level (ASIL), especially ASIL B, C and D.
And if you haven’t yet read my previous article about the ABCs of ISO 26262, you can find out more about these requirements.
Through the use of a protected SoC fabric IP, designers can extend fault tolerance and data protection measures to all IP block communications throughout the chip. By doing so, they will have the mechanisms in place for certification through an implementation that offers the least risk. This should be especially helpful for designers who want to enter a market quickly with a competitive, feature-rich device.
Implementing fault tolerance and functional safety in hardware rather than software:
1. Reduces Complexity – Software takes much more effort to develop and maintain than certifiable hardware IP;
2. Improves Quality – Hardware IP is pre-tested and can be pre-certified while future software quality presents risk;
3. Enhanced Control – Semi vendors set a baseline of safety features that must be implemented, which is less risky than low-grade software developed without knowledge, input or feedback.
Fault-tolerance is well understood in the CPU portion of most SoCs. Unfortunately CPU-only safety is not enough because SoCs have become infinitely more complex with multiple subsystems and interfaces.
Designers need end-to-end resilience across the entire SoC to include protection for all subsystems. For that reason, there are some solutions available that enable greater resilience and fault tolerance out-of-the-box. For example, the Synopsys DesignWare ARC EM SEP and ARM Cortex-R5 and Cortex-R7 processors offer enhanced error management for safety-compliant systems such as those in automotive, military, or medical applications.
But the protections here have to extend to the rest of the SoC. One of the best ways of accomplishing this is to use network-on-chip interconnect IP that links to all the other IPs and has the resiliency features built in to withstand faults presented by transient electrical problems, soft errors and even physical damage.
Building a complete system-on-chip using an ARM Cortex-R5 or Synopsys DesignWare ARC EM SEP processor and a protected (NoC) interconnect fabric would enable:
• End-to-End data protection
• Packet transportation protection
• Unit Duplication for ASIL C and D
• Safety Checkers for Fault Detection.
Not every NoC IP can provide these features out of the box. But engineers should request a package of resiliency features that can be integrated in the initial SoC design stages. Early planning for Automotive Safety Integrity Levels (ASIL) will help avert some of the complexity, risk, delay and control issues that could be burdensome in a software implementation.
Companies like Yogitech, S.A., and Mobileye have implemented designs with the NoC features described above and have achieved success in automotive markets. In June, Monica Tang, Arteris’ Manager for Applications Engineering delivered a much more detailed address to DAC about this very same subject, entitled: Accelerating ISO 26262 Automotive Functional Safety Certification Using Protected SoC Fabric IP. A copy of her presentation can be found here to give you an idea of what’s possible when resiliency features are baked in to the hardware.