Creating IP In The Shadow Of ISO 26262

On many levels, designing IP for the automotive sector is similar to targeting aerospace or medical devices — human lives are at risk if something goes wrong, and the list of regulations is significant.

In practice, it can turn an interesting chip design project into a complex and often frustrating checklist exercise. In the case of ISO 26262, that includes a 12-part standard for automotive safety.

“There’s a whole bunch of ISO 26262 processes you’re supposed to follow to achieve the ASIL rating under the standard,” according to Marc Greenberg, director of product marketing at Cadence. “And you’ll have an external auditor.”

Significant work is required to achieve the level of quality that the automotive sector requires, and in most cases a premium is charged for IP of this quality.

“It’s a very different domain from uncertified IP,” said Lee Harrison, director of product marketing in Siemens EDA’s Tessent Division. “IP vendors work hard to make sure IP that could and will be used in an automotive application comes ready, pre-certified, along with the appropriate documentation. It’s often referred to as ‘automotive grade’ or ‘automotive certified.’”

In fact, even the tools used to develop safety-critical electronics need to be assessed and approved.

“As part of your preparations, it’s necessary to have the right certifications for the tools that are involved,” said Frank Schirrmeister, vice president of solutions and business development at Arteris. “You will need to get a TCL (tool confidence level) certification that this tool is safe to use in the context of ISO 26262”

Indeed, as Synopsys explained in a blog: “The standard is very detailed and covers a wide range of topics, making it difficult to fully understand and implement…Meeting the requirements of the standard can be time-consuming and costly, and may require significant changes to existing development processes.”

Despite all that, engineers should not be intimidated. “Nobody is saying you have to start over from scratch,” said Greenberg. “You can re-use a lot of the things you’ve already done, but do it within the ISO framework and in an automotive-safe manner.”

Criteria
There are four criteria to meet for automotive grade, according to Ron DiGiuseppe, automotive IP segment manager for the solutions group at Synopsys. “The first is based on the fact that most of the SoCs going into automotive are going into safety-critical applications. That includes ADAS, powertrain, battery management, and even many of the infotainment IVI, depending on the application. So compliance with ISO 26262 automotive functional safety is a critical development challenge.”

A very similar type of requirement is cybersecurity, under ISO 21434. “In addition, development of the SoC and the IP needs to meet the 15-year expected operational lifetime,” DiGiuseppe explained. “Typically, the SoC’s have to be qualified to meet the AEC-Q 100 long-term liability standards. That’s to make sure the implementation is robust, can meet the temperature profile, and the higher temperature operating rate [to ultimately] meet the long-term reliability criteria.”

Because of the need to implement designs that can respond to possible failures, the fourth criteria isn’t just about design engineering. It requires new approaches to manage the development team. “All of the development teams have to be managed under an automotive-grade quality management system (QMS) so that all of the different developments flows are followed,” DiGiuseppe said.

It’s a system familiar to any engineer who’s worked for a defense contractor. “An automotive-grade QMS ensures that the spec and design reviews occur and that you check in and check out the different revisions of the IP,” DiGiuseppe continued. “The goal is to have traceability from the beginning of the development to the end. The QMS is key to the ability to survive an audit, which is not something that a lot of commercial development needs to do. Development engineers need to implement special practices for every one of these criteria.”

This means that using open source code is frowned upon. “There is some open source, automotive-grade Linux, and it’s primarily used in infotainment,” said DiGiuseppe. “You want to avoid open source; that’s the traditional best practice in industry.”

Training
All of this also equates to additional training for the individual engineer and the team, as well as adding a key position.

“Very commonly, the same companies that do audits will also offer training,” Cadence’s Greenberg said. “Part of the ISO 26262 process is that people need to be trained, and you need to appoint people into positions in your organization to oversee the safety of the development. Safety managers are a requirement under ISO 26262. Otherwise, you’re not going to pass an audit.”

Fig 1: Contents for a typical IP safety package. Source: Siemens EDA

Environmental conditions
Aside from safety — or arguably as part of it — the biggest consideration for automotive design is the environment. “All of the IP is designed using an assumed mission profile,” said DiGiuseppe. “You have to simulate with the knowledge that there are different operating temperatures that can have an effect on timing. The AEC defines four different temperature grades. ADAS, for example, is typically grade 2 temperature, which operates at a maximum ambient heat around the SoC of 105° C. Temperature can go up to grade zero, which is an even higher temperature. Temperature has a big effect, and it drives the whole engineering development flow. It’s part of the spec that you design against. You have to fix that temperature profile early in the development process.”

At the same time, it’s a far cry from a climate-controlled data center. “Vehicles are harsh environments,” Greenberg said. “They have temperature extremes. They have voltage excursions. They may have electrostatic discharge in ways that you didn’t expect to happen. A car could get struck by lightning. It could encounter severe vibration issues. People may run a vehicle for 20 years or more, so you have lifetime issues to consider, as well.”

Lifetime issues also can mean additional engineering overhead. Typically, automotive product support is for 15 years in case there’s a part return failure. Engineering support must be in place that can debug it, so long-term support is another requirement.

Redundancy and safety
As with all electronic components, failures will occur. But engineers need to approach these designs from two angles. “Implement the design as robust as possible to ensure no failures occur,” DiGiuseppe said. “Then, assume that failure will occur, and ask how the system will respond.”

Automotive engineers are compelled by standards to do both. “When we are producing automotive-safe IP, we very commonly will put in additional automotive safety features to bring it up to the safety rating that’s necessary for the application,” said Greenberg. “For example, one of the basic tenets of automotive IP is that if you have an error detection mechanism. Then you need to have an error injection mechanism, where you can create the kind of error that the detector is supposed to detect so you can confirm the detector is working.”

At the same time, fault injection isn’t something companies figure out for themselves in an ad hoc manner.

“In the safety manuals, which are documented by the ISO 26262, there is a set procedure for simulating faults,” said Amit Kumar, director of product management and marketing for Tensilica Vision, radar and lidar DSPs at Cadence. “The automakers and the software developers all follow that, and it keeps on getting upgraded as newer forms come in.”

Although it’s possible to make an automotive-safe system out of non-automotive safe parts, it would require additional techniques, such as redundancy. “Instead of one automotive safe camera, perhaps you have three non-safe cameras and three sets of hardware that are interpreting the results of those cameras and comparing results,” Greenberg said. “If one of them disagrees, then you have an alert to a fault in the system and fall back to the other two.”

Redundancy can be as exacting — and expensive — as including duplicate SoCs. “One of the ways automotive IP and SoC development is different from commercial IP development is that in order to respond to possible failures, you have to implement actual design techniques, such as adding ECC for memories or parity for a data path,” DiGiuseppe explained. “It doesn’t change the functionalities. But it changes the design because, for example, you’re adding new parity logic to ensure that if there is some sort of a change in the data like a fault, it is identified and can be flagged.”

Another possible approach is full redundancy. “For processors, it’s very common to have two processors, with the execution of the software usually staggered by one or two clock cycles, so that there’s a primary processor that’s operating, and if it encounters a failure, the redundant processor can take over,” he said. “One other technique that some automakers use is to actually duplicate the whole SoC. It’s probably the most expensive approach, but is due credit as it is the most complete approach.”

The future is now(ish)
An additional consideration is how forward-thinking you need to be. “With a timeline as long as automotive, you basically are years ahead of what’s going on,” said Arteris’ Schirrmeister. “Preparing your IP for what’s going into production five to seven years later is non-trivial. It just takes very long until you see returns from a royalty perspective, and it also makes it very challenging to predict what the drivers will be at the time.”

Further, when manufacturers are thinking that far out, it can be hard to accurately estimate what materials costs are going to be. And worse, regulations may be revised. Working so far ahead, it’s impossible to predict if Washington or Brussels may change their minds, he said. “You have to bet on the winners. If you take feedback from five systems companies and from five semiconductor companies, you have to make educated calls about which protocol you need to support.”

Fig. 2: Automotive IP checklist. Source: Siemens EDA

And finally, everything needs to be secure. But in such a complex system, seemingly minor changes can substantially impact safety and security.

“The basic tenants of security and safety testing apply when recasting the use of any component that requires customization,” said Chris Clark, automotive systems security architect in Synopsys’ Solutions Group. “This typically is not a major concern for IP, since the level of conformance testing is considerably higher than it is for the software that will be used on the hardware. Nevertheless, the same level of testing rigor should be applied to any component adapted to a new environment. Developers must evaluate the threat analysis and risk assessment results and compare them to the environment they will be going to. These changes could mean substantial IP changes and collateral impact on the technology stack running on said hardware. Reuse of IP is helpful and still requires extensive security testing.”

Conclusion
Despite the complex demands of design IP for the automotive ecosystem, they can be overcome. “Once you’ve done it once or twice, it will become fairly natural to do,” Greenberg said. “Many of the things in ISO 26262, ISO 9001, and so on, are just good design practices. It’s not about trying to make anybody’s life difficult. It’s about making the vehicle safe and following a prescribed process for doing that.”

In fact, the process may remind many engineers of their undergraduate years. “When I went to university, they taught us very methodical ways of designing things,” he said. “And when I got my first engineering job, all the engineers around me said, ‘Oh yeah, don’t do that! ’So following these standards is actually coming back to the kinds of principles they teach in universities. It’s a methodical process for developing a chip in a safe way.”

Additional Reading:
Why Auto Ecosystem Relationships Are Changing
As ecosystem partners bring their unique technologies and expertise to bear, end consumers will be the ones to benefit. But none of this will happen quickly.

ISO 26262 – Law Or Framework?
Collaboration between supplier and customer is key to achieving functional safety goals.

ISO 26262 – Functional Safety
Standard related to the safety of electrical and electronic systems within a car