The Long And Detailed Road To Automotive Compliance

Compliance with automotive safety requirements is slowing down both innovation and participation by a flurry of startups as the whole ecosystem struggles to bring autonomous vehicles to reality.

This is particularly onerous for chipmakers, which face a high bar for IC integrity and reliability. They must meet specifications and be free of design errors. Improper behavior in corner-case scenarios can endanger driver, passengers, and others nearby. Pre-silicon verification alone is not enough. Automotive electronics also must provide functional safely in the field, even in the presence of random errors. The ISO 26262 standard mandates that safety logic must be added and its effectiveness fully understood.

“Even if the designs are correct and safe, trust verification is essential to ensure that no hardware Trojans or other unintended functionality is inserted by any person or tool in any step of the development process,” said Joerg Grosse, product manager for functional safety at OneSpin Solutions. “Also, security must be guaranteed so that no malicious agent can take control of the chips and cause a vehicle to behave in a dangerous way. Assuring IC integrity provides functional correctness, safety, security and trust.”

This is a radical departure for most chip companies. “The idea of autonomous driving creates a whole new world, and it might as well almost be considered a different industry,” observed Rich Collins, product marketing manager for IP Subsystems at Synopsys. “A lot of companies see a potential for huge growth, so they’re jumping in feet first.”

Along with this is the added requirement that safety must be architected into automotive systems from the ground up. “You have to be thinking about it when you have a blank sheet of paper, and really think about all the aspects of it because it touches everything,” Collins said. “It’s not just, ‘Let’s make a block that we stick in the corner and that’s our safety block. You have to think about how it affects memory bits, logic, the booting up of the code on that chip. If there are faults in different parts of the chip, how do we manage those escalations based on a fault that’s in the far right corner of the chip? Does that cause a catastrophic failure so I have to shut down, or can I live with that—those kinds of decisions. It all has to be designed from the ground up. That’s new territory for a lot of semiconductor vendors, so they are desperately reaching out for help.”

From a technical perspective, automotive SoCs have three major requirements: quality, reliability and functional safety. Quality starts with the robustness of the foundry process, which includes such factors as process variation, defect density, electromigration, ESD, aging and thermal fatigue, according Tom Wong, director of marketing, design IP at Cadence. Reliability is related to the lifecycle of the SoC and manifests itself in infant mortality, useful life, aging and wear outs. Functional safety relates to meeting ISO 26262 requirements, including safety goals, safety SoC architecture, safety verification and FMEDA analysis.

“In terms of automotive standards that deserve major attention, we have AEC-Q100 and ISO26262,” said Wong. “AEC-Q100 is a failure mechanism-based stress test qualification for packaged integrated circuits. The most commonly used temperature range for automotive SoCs is Grade 2 (-40ºC to +105ºC ambient), and the more stringent requirement is Grade 1 (-40ºC to +125ºC ambient) as specified in AEC-Q100 standards documents. Chips for infotainment systems, head-up displays and ADAS subsystems such as ACC, AEB, blind-spot detection and lane departure monitoring are typically Grade 2 temperature range. As we begin to move to Level 3 and Level 4 deployment, Grade 1 temperature range will become more prevalent.”

ISO 26262
Functional safety is of the utmost importance in the development of safety-critical automotive systems, especially with the introduction of advanced driver assistance systems (ADAS) and automated driving systems (ADS). ISO 26262, Functional Safety – Road Vehicles specifications emerged in 2011 as the go-to standard for functional safety for automotive systems. ISO 26262:2011 is generally adopted by semiconductor (SoC) and IP vendors as the baseline for automotive functional safety compliance. It is currently available as the draft second edition (ISO 26262:2018) and officially covers semiconductor developments by providing a specific guideline for a proper interpretation of all normative parts. However, for many semiconductor and IP suppliers, the information represented in the first edition of ISO 26262 did not capture the requirements or considerations that are relevant to them in comparison to the needs of OEMs and automotive Tier 1 and Tier 2 suppliers.

Some semiconductor devices and IPs are developed as Safety Element out of Context (SEooC) because the end application is unknown. So assumptions about the final implementation, safety goals and automotive safety integrity level (ASIL) needs are not always clear. While design teams implementing the system can define and assess system-level safety mechanisms and diagnostic coverage, it is not so easy for SoC and IP designers/suppliers, Wong said.

Many concerns from SoC and IP designers/suppliers have centered around transient failures of components, which are topics that were not well addressed in ISO 26262:2011 (First Edition). They are a crucial aspect of FMEDAs. Part 11 in Edition 2 brings enhanced information to support dependent failure analysis (DFA). In addition, appropriate handling of legacy parts developed prior to the release of ISO 26262 can be challenging, because it cannot be proven that the legacy device was designed in a safety environment mitigating the potential for systemic risks. “As a result, the only fallback position is that we can claim that we have shipped millions of these chips, and there were no known failures that would impact safety. We call this ‘proven in use,’ which provides confidence to the downstream customer that this is suitable for use in automotive applications,” he added.

ISO 26262:2018 was released in Jan 2019 by ISO. Digging a bit deeper, ISO 26262 has three important foundation/pillars: people, process and product. To fully adhere to the spirit of the specifications, the ‘people’ part is most important. “The development and demonstration of a safety culture is a basic requirement of ISO 26262,” Wong explained. “This means appointing a safety manager and training the team so they understand the ISO 26262 specifications sufficiently to be able to define safety goals and safety architecture and interact with the auditor in the certification process. This safety culture needs to permeate throughout the organization. Often times, organizations look at this requirement as a check point. Once we get certified, we are done. This is far from the truth. It is a culture shift, and the team must believe that safety is important, and is part of the development process and psyche. There are no shortcuts. Either you believe in the mission, or you should not be doing this at all.”

The process pillar specifies that any design organization needs to have a well-documented process and procedures for design, documentation, bug tracking, project management, etc. This is the foundation to avoid systemic mistakes or errors.

Having a good design process also enables the design team to train new members as the team grows and is also a key component to spread the safety culture, which is part of the ISO 26262 specifications. Beyond design process, ‘product’ is the third leg of ISO 26262. This refers to product qualification, regardless of whether it is a system, an SoC or IP. Each product must go through a rigid quantitative and qualitative analysis based on safety goals, identification of potential failure mechanisms, insertion of safety features to minimize risks, and calculating the hardware FIT rates. Based on detailed and sometimes quite exhaustive collaboration with the auditor, an FMEDA is completed and the product is certified to comply with the relevant level of ASIL readiness and compliance.

But there’s more to automotive designs than the system architecture, the chip design, the physical layout, the process technology and the performance of the end product.

“There are a lot of other variables that require deep knowledge of functional safety and semiconductor reliability, as well as deep commitment from the organization that you are in that this for the long haul,” he said. “If you start thinking about how long you want to keep your car and you want your car to still be safe after 10 to 15 years, then you will begin to appreciate all the hard work that has to be done up front to ensure that happens. Especially when we are about to enter the realm of autonomous driving. Level 2 vehicles have been on the road for more than 5 years now. Level 3 will be deployed/shipping in 2019, and Level 4 is around the corner. So all these functional safety considerations are now center stage. After all, the average life of vehicles on the road is now in excess of 12 years.”

Getting from here to there
Knowing the destination does not always mean the route to get there is clear, and when it comes to applying and having the appropriate standards recognized and accounted for within an engineering team enough to begin designing in compliance, a practical approach is a good place to start.

“You have to look at the organization and their processes to see if they are even capable or have the processes in place to be compliant,” said Joseph Dailey, global director of functional safety at Siemens PLM Software. “There are many standards out there, but the one that really pushed everybody was the ISO 26262. It really made people see they had to have not only a state-of-the-art process capability, but also a state-of-the-art architecture capability.”

Dailey is regularly called in to do that kind of assessment. “As far as the process, when I go into a company, the first thing I do is a gap analysis and say, ‘This is your process. This is where you have issues. These are the recommendations to complete in order to reach compliance.’ Being part of the engineering group, I will take the practical system side away from the standard and say, ‘This is how we could streamline across the process. These are the issues with your tool stream. These are the issues with your process stream.’ Then we work on creating better process solutions for a company. That could be everything from reuse capability to APIs between tools. There’s a lot to that. But we have to meet ISO 26262, which relies on ISO 9001 or a similar QMS (quality management system), and it also refers to other things like configuration management and other standards that you have to know and be aware of them.”

“There are architecture questions, as well. “‘Do you do this workflow? Do you make sure that you do all of your verification and validation not of just the product, but of your workflow? You may have done all of your requirements for the product, but did you verify that it’s in line with all of the checks? Did you sign everything off?’ All of that information has to be provided, because if something happens 10 years down the line and you have to do forensic analysis, how can you prove that you have fixed something if you don’t know what is failing? As part of that, there are some safety analysis issues. Do I have my single-point failure analysis and the metrics there? Do I have my parametric random failure? Diagnostics average? Those numbers have to be there. So there are several pieces of analysis from the hardware side,” Dailey said.

Clearly, there are many different analysis to prove that systems are safe. But the biggest problem the industry has right now is it still looks at single components or single events and doesn’t pull the entire system together, he noted.

This is where the SOTIF (ISO 21448 — Safety of the Intended Functionality) committee has devoted some of its time to really making sure that the system verification and validation is tied in. They are an annex for the STAMP/STPA process, which recently created the J3187 workgroup to create guidelines for the use of the STAMP/STPA process.

Getting up to speed is no small task, he said. But with management commitment, it is possible to have a process up and running in six months in order to start managing a job. “It doesn’t mean all the work is done. It simply means we’ve analyzed the process and we create the planning documents, and there are several levels of documents that have to be created. First, you have to have plans. What is my configuration change management plan? What are my documentation requirements? There are a lot of different plans that have to be put together from the organization side. Once those are in place, then we can start working with teams and projects and get them going. And then we start working on templates, work instructions, guidelines. Then we can bring in an audit house and start to audit the processes in order to get their processes certified,” Dailey added.

Complexity on complexity
Things can get complicated very fast. Kurt Shuler, vice president of marketing at Arteris IP, said it is not uncommon in SOTIF applications to hear, “‘I’m going to do a system and it’s got cameras, and it’s got radars, and the radars have cameras, and there are sensors.’ It’s very complicated. People ask us how to protect against this and that, and how to ensure this thing works and what can be done in the interconnect to help with that. So we get pulled into these really high-level questions. And because an interconnect is configurable IP, and each customer’s design is totally different, we also get pulled into discussions around the process aspect to ISO 26262 when using configurable IP as opposed to a hard macro. These companies are asking us 1,001 questions about that, and it really is difficult. What we generally have to do is agree upfront that we are responsible for a specific part of the specification. And as a safety element out of context, we are responsible for this type of analysis and this kind of stuff; here are our assumptions of use and everything; and we agree on this. Any other insights we give to them is something we do to help them, but it’s not necessarily part of a contract or that’s required. The reason to have that agreement up front is because a lot of these companies are new to automotive, and we have a lot of experience, but we don’t want to be an ISO 26262 consultancy.”

This is where education and a functional safety expert brings much to the table.

All of this just amplifies the sense of strictness around safety that permeates the entire automotive ecosystem. Case in point: Both the car makers and the Tier 1s are very strict on the silicon that needs that goes into automotive modules so the semiconductor vendor is very much on the hook to make sure that their SoC has gone through the rigorous certification bodies to get the stamp that says not just the silicon, but the systems that they use in terms of developing their SoC, the flows and processes all have to be in line because they get audited by the OEM, Synopsys’ Collins said. “It’s a very comprehensive culture of safety that you have to build SoCs. It’s not just a box you can check.”

While an IP provider is a level removed from that, Collins said Synopsys goes through a lot of those similar processes that the SoC vendor does in terms of its safety culture, such as identifying specific people to serve as safety managers with responsibility for the overall safety aspects of the IP going through the certification process. “When we provide that to the end SoC vendor, we’ve already done that. We are trying to ease the pain for that vendor because now, for instance, the processor is already ASIL-D certified because it’s a dual core lockstep, processor, for instance. So they can leverage a lot of what we call FMEDA reports—the failure analysis reports. They can leverage those, and they can leverage our safety documentation in their own documentation. It’s a mechanism for easing the pain of certification for the SoC vendor because the portion we provide is already certified, and it makes it quicker for them to get to market.”

Similarly, Neil Stroud, director of technology strategy for Arm’s Automotive & IoT Line of Business, noted that Arm is committed to delivering IP that supports functional safety designs in automotive applications. As well as innovative capabilities such as the Split-Lock feature showcased in the Cortex-A76AE and Cortex-A65AE cores, Arm follows a stringent systematic development process defined in the ISO 26262 standard. “The combination of these two factors drives confidence for all ‘downstream’ parties as they develop their safety-critical systems.  Support is provided through comprehensive documentation as well as undergoing external assessment and certification.”

Arm is also an active member of the ISO 26262 committee. And when it comes to the emerging ISO/PAS 21448 standard, which will play a fundamental role as the innovation in safety-critical systems accelerates, Stroud said Arm is actively involved in contributing to this developing standard as well as continually appraising how this could impact its product portfolio.

Conclusion
The number of shifts happening in automotive, all at the same time, leaves a lot of newcomers overwhelmed with the number of decisions they need to make. Still, there is much they can borrow from different industries, said Max Odendahl, CEO of Silexica. “One of our customers, which is doing missiles and radar, moved to Tier 1 status and is now doing functional safety there. Everybody started from scratch, but they solved that 20 years ago in avionics.”

Finally, a completely compliant engineering organization is likely to employ functional safety consultants, educate its own engineering team, and make sweeping changes in its processes that document every detail in order to garner a piece of the automotive pie. But it’s a lot of work and time, even if it isn’t always a surprise.

Related Stories
Reliability Becomes The Top Concern In Automotive
Extended lifetimes and advanced-node designs are driving new approaches, but not everything is going smoothly.
How To Build An Automotive Chip
Changing standards, stringent requirements and a mix of expertise make this a tough market to crack.
Safety Critical Design In Automotive
Finding faults at the chip and system level.
The Race To Multi-Domain SoCs
How automotive and AI are altering chip design.
Shedding Pounds In Automotive Electronics
Weight is suddenly a major concern for carmakers, but slimming down has repercussions.