ISO 26262 Part 11: Systems-on-chips and the intellectual property conundrum
Today’s cars are fully developed electronic systems on wheels, where each part is interrelated and must be designed, optimized and verified simultaneously. As a result, it is important to apply a holistic approach when developing automotive systems.
But when it comes to chips, the whole technological and business landscape is changing, and with ISO 26262’s Part 11 guidelines on applying the standard to semiconductors, the big question is: how is the new regulation going to affect System-on Chip (SoC) intellectual property (IP)?
The whole issue arises in the midst of the rapid push toward autonomous driving. This year, cars capable of Level 3 autonomy begin hitting the streets. Behind the scenes, work is underway to design SoCs for Level 4 and more.
As the automotive industry continues to develop more self-driving technology, automotive electronics will maintain an integral role in enabling these capabilities. Future vehicles will have more integrated infotainment functions, sensor clusters, computer power, vehicle-to-object communication technology (Car-to-X), high bandwidth Ethernet networks and high-definition screens.
And while electronic components improve transmission, government regulations increasingly require automakers to integrate redundant detection and control systems with more cameras, radars and other ADAS features into vehicles to increase safety and reliability.
This is the reason why all electronic circuits need to be verified to ensure the correct hardware and software functionality, expected tolerances of the components, temperature variations, stress-induced failure mechanisms such as electromigration and electrostatic discharge, and a series of other parameters to protect against failures in the field.
In addition, automotive electronic subsystems must simulate each other to ensure that each interconnected subsystem continues to operate as intended for a long period of time. In fact, exhaustive simulations, failure analysis, and performance and reliability analyses are critical to avoid catastrophic safety issues and possible costly withdrawals later down the line.
IP plays an important role in all this by supporting essential communications protocols such as Ethernet, as well as functions that include real-time data, audio and voice processing, sensor fusion, pattern and voice recognition, sound enhancement and connectivity. Automotive ADAS systems are responsible for one of the fastest growing automotive semiconductor sectors, essential for improving the driver experience and overall safety.
Changing IP landscape
Due to the rapid transformation of requirements to support new functions – in-vehicle infotainment, wireless connectivity, incoming ADAS and ML/AI SoCs – the IP landscape has changed as well. Car manufacturers are investing in chip design teams, outsourcing to ASIC design services, or acquiring semiconductor IP straight from IP vendors. hat’s as the whole business landscape is changing, too.
“There’s everything from start-ups to century-old OEMs thinking about doing their own IP and/or their own SoCs to go with that,” says David Fritz, senior autonomous vehicle SoC leader at Mentor, a Siemens Business. “We see the whole gamut. We see companies that are extremely naïve about the complexity, all the way to OEMs who are still thinking that the technology as it was last time they tried this back in 1982.”
In this light, selecting IP poses its own set of difficulties. “One of the things that all of these guys deal with is having evidence that the specifications are being followed,” says Kurt Shuler, vice president of marketing at Arteris IP to Semiengineering.com. “[That’s] both from a process standpoint of how the IP is designed, and then, does the IP meet the technical safety requirements that are being claimed?”
This is why customers have started to look carefully at their different IP providers, since they are increasingly interested to know what kind of chip it is and how it was constructed. “If our customer or prospect has somebody who doesn’t understand functional safety or the specification, and is just going blindly through a checklist, it slows things down,” Shuler says. “So the right subject matter experts must be there.”
How open is enough?
Another critical aspect of the IP conundrum is how openly companies should share diagnostics coverage information during verification. “IP integrators, meanwhile, need to understand the assumptions for using IP, because unless it’s custom, that IP is considered a SEooC [safety element out of context].” These specificities have become critical as automotive OEMs want to know more about what they are purchasing for their systems.
“This goes through the whole food chain and it’s all controlled through ISO 26262, in which they’ve already established all the rules and the documentation,” says John Swanson, Ethernet product line manager for Synopsys IP. “The first automotive chips I worked on, nobody even asked about this stuff. They had to certify the chip, but they didn’t have to certify the IP. That’s obviously changed. You put more and more IP on the chip and it makes sense.”
Still, it’s not clear how any of these designs will be affected by the second edition of the ISO 26262 functional safety standards, which contain Part 11 to precisely address the requirements for semiconductors and IP. However, upon its implementation, companies will turn seriously to training their development departments to be well-informed and familiar with functional safety, and to be able to work with auditors to create SoCs certified complaint for functional safety.
In this line, Gustavo Espinosa, senior principal engineer and lead architect for functional safety at Intel, explains that, “Semiconductor developers must address several key considerations in order to successfully apply Part 11 to their devices. It is clear that Part 11 represents an adaptation of ISO 26262 specifically to semiconductor devices to facilitate the application of the standard’s requirements,” he says.
“This is why we want to address some of these considerations by way of example application of Part 11 to Intel’s products,” ranging from relation of component safety analysis to system analysis, standardizing functional safety support for easing IP integration, dealing with analogue/mixed signal and multi-core components, and dealing practically with DFA.”