Safety is an end-to-end problem. There is no way to determine whether a system is safe to operate without understanding both the complete functionality of the system and the environment in which it operates. Automotive safety presents additional challenges for verification on top of this.
Although the manufacturer is able to pull all the elements together into a final product for testing and analysis, there may be conflicts that need to be addressed during integration that could have been avoided with greater understanding of how subsystems interact with each other. But automotive systems are complex and the result of a collaboration between many supply-chain partners, none of whom have the visibility into each others’ designs that might reveal potential efficiencies and conflicts before the final integration phase. And there may be hidden assumptions and functions that, unless they are revealed by a test, might compromise safety without being revealed until the vehicle is in production.
Many of the supply-chain partners working on components and subsystems see the possibilities that greater collaboration could present and some of them came together in a panel session organized by Mentor, a Siemens business, at the recent Design Automation Conference (DAC) in Las Vegas to talk through some of the issues.
Mat Blazy-Winning, functional safety director at NXP Semiconductor, says: “To get to safe autonomous systems, the process has to be more collaborative, from the OEMs to the semiconductor suppliers. The problem we are trying to solve – autonomous vehicles that can drive in any environment – is very complex.”
Nir Maor, senior director of technology at Qualcomm, says: “You need to understand goals; the safety mechanisms; the execution plan.”
Blazy-Winning adds: “It’s very challenging in the automotive supply chain. Going from IP providers through ECUs all the way up to the complete vehicle, you need to ensure that when you go from one supplier to the next up the chain, that there is transparency as to what each supplier did.
“There is nowhere in the supply chain that you can verify the complete system: the process has to be distributed. When you’re integrating an IP for safety, there will some safety features implemented and some assumptions made. As we are integrating that IP we need to make sure that the assumptions are met and that the safety concepts of that IP fit into the overall SoC.”
Ghani Kanawati, technical director of functional safety at Arm, says: “We see a need to collaborate but we haven’t figured out how to collaborate yet.”
Kanawati notes the level of detail required for verification has increased. “We used to believe bus-functional models are accurate. Now we need to make sure that those models are really accurate. They have to match as far as possible the real device.”
Yves Renard, functional safety manager at ON Semiconductor notes: “You can do a lot of failure injection simulation during verification but that may be no use to you because your models were not correct. So you may need other methods to catch what is wrong. And you need to use engineering judgment on top of tools.”
Although the OEM might not have visibility into the deep detailed operation of an SoC or the IP inside it, the IP vendor or SoC supplier has the problem of checking safety attributes that are important to the OEM. Kanawati asks: “If I don’t know the use case, how can I test?”
But Kanawati notes there are advantages to greater transparency between supply-chain partners: “If OEMs and tier ones can share more with us we can design a better solution.”
Role for digital-twin technology
At Mentor, Bryan Ramirez, strategic marketing manager, says the move towards digital-twin technology provides a possible solution to the problem of verifying complex systems at the system level for safety. “The industry is making advances on how to analyze safety within sub-domains of a car. But there are many system-level safety implications where a digital twin could more efficiently and accurately analyze and optimize safety across aspects within the car and eventually elements beyond the car that affect autonomous driving.” Those external elements would likely include V2X communications and environmental factors.
Ramirez says the verification will need to take place at several levels of abstraction, pushing into subsystems from the full digital twin. “Moving more to a digital twin implementation is the path we need to go down and we are seeing this with some customers that have been doing this for a while and realize that raising the level of abstraction is the only way to keep pace,” Ramirez adds.
“They are looking for ways of verifying safety at a low level, for something at the IP level, but then wanting to raise the abstraction for that block through higher-level models built upon what was learned during the low level, detailed analysis. This would enable much more efficient SoC and system-level testing. Safety needs to also be looked at from a system level and this is where a full digital twin will be necessary.”
In such a complex environment as the automotive supply chain, collaboration and cooperation will be vital components in making the ability to move from low-level detail to system level will be increasingly important.