Four experts in the discipline of functional safety were gathered together at #56DAC in Vegas earlier in June, hosted at the Mentor booth, so I rested my legs and typed notes as fast as I could. The product areas that I first think about when functional safety (FuSa) comes up are automotive, medical and aerospace, because keeping human life protected in these areas is paramount. Our moderator was Bryan Ramirez from Mentor, and the panelists included:
The big picture is that automotive safety has gone far beyond just braking and ECUs, think ADAS and Autonomous Vehicles. There are now many new entrants in the automotive electronics space, and they certainly need to quickly learn about about safety practices.
Q: What is the state of the industry for tools to help FuSa requirements?
Ghani – we must meet safety requirements, but how do we achieve that at the system level? With autonomous driving how do we know that with the ML algorithms that it will detect obstacles properly? We need to collaborate in the industry in order to make autos safer. Tools are not complete yet, so there’s progress yes, but problems are growing so fast with AV.
Yves- we need to get suppliers all involved, working together on all ICs, sharing information, sharing IP information while keeping secrets. On the digital side we have good tools for safety, however on the AMS side we need better analysis and tools.
Nir – yes, analog is very complicated. FUSa today is like verification 20 years ago, and the tools are lagging. I really don’t want to wait 20 years to get FuSa tools.
Matt – we now have requirements management, system analysis and verification. Aerospace has many years experience for FuSa, so automotive is still catching up to that level. The tooling not mature yet for functional safety EDA tools and methodology.
Q: What about collaboration aspects?
Matt- to reach autonomous vehicles, safe systems requires collaboration across IP, automotive and systems companies in order to meet ISO 26262 requirements. How will we use these methods and apply new tooling?
Nir – We really need government input in order to meet our safety requirements.
Yves – with new process nodes the safety requirements change, so we need to collaborate with the foundries.
Ghani – within EDA we could use IEEE standards and communications to become safer. We already have Design For Man, DFT and now we need Design For Safety.
Q: How can I know when I’ve tested enough to be safe?
Ghani – well, following ISO 26262 for chip or IP is a minimum starting point, but there is no simple recipe on how to ensure safety in a product. There’s no such thing as complete validation. With safety when human life is in the balance the methodology is to do more verification than before, so it’s going to be company specific.
Yves- that’s a very important question, so the answer is to simulate, verify, then stop, but where is your plan? The plan is the starting point. Did I verify my requirements well? Fault injection simulations are required. Engineering judgement on top of simulation and verification is need, yet we need to go even further.
Nir – I agree, we need to first define our safety goals, then cross checking that we met each safety goal, just like when doing verification.
Matt – when do I know that I’ve verified enough? Has all of my IP been verified up to SoC and system level? Proving that the entire system has been validated is our real goal.
Q: Has my OEM supplier adhered to safety standards?
Matt – integrating each IP needs to fulfill all safety concepts. As each level in the design is completed, validation needs to happen.
Nir – I don’t know that users of our chips can validate what we’ve done internally to meet safety standards.
Ghani – design bugs can be either digital or analog, so how do I know that my verification has covered all of the bugs? At ARM with have used Bus Functional Models along with sensor models to mimic actual behaviors, and it must be highly accurate. Most OEMS just run software on a system, so they only need a high level model of our designs.
Q: How well does requirements get fed through the design chain?
Ghani – we don’t know all of the customer use cases, so we have to make assumptions. If tier 1 and OEMs can share more of what they need, then we could make safer IP blocks.
Yves – requirements need to reach the suppliers very early in the process. It’s not easy to define the requirements for safety. If we don’t get requirements soon enough, then our IP cannot meet expectations.
Matt – exchanging requirements between two different levels is a challenge, although there are multiple formats being used IPDF, Excel, etc., so there’s not a consistent method from top to bottom levels.
Yves – with the ISO 26262 standard we now have the same language to talk with all of our vendors.
My Take
They say that it takes a village to raise a child, and so it is with functional safety, because it will take close collaboration between the systems companies creating each new generation of cars and planes along with all of their suppliers: Foundries, EDA vendors, IP providers. At an annual event like DAC we do get to see all of these companies gathered together at one point in time, and having this kind of a panel discussion is one way to build awareness for our functional safety challenges and approaches.
Related Blogs
- Autonomous Driving and Functional Safety
- Help for Automotive and Safety-critical Industries
- Mentor Showcases Digital Twin Demo
Comments
There are no comments yet.
You must register or log in to view/post comments.