Certifying the Certifier – OneSpin Talks About the Extra Burden of Proof
By Bryon Moyer, EE Journal
OK, people: it’s time to talk again about how not to hurt or kill people (or other living things) with electronic gadgetry. Or more-than-gadgetry, like cars that have the temerity to drive themselves. There are so many angles from which to approach how all those functions in such machines can be made safe; we take on yet another one today.
This discussion stems from a conversation with OneSpin at this summer’s DAC. Seems like it was just about this time last year that we talked about how EDA and functional safety work together, but, based on some recent certification announcements, this year we have a view from a different stance.
[…]
This discussion stems from a conversation with OneSpin at this summer’s DAC. Seems like it was just about this time last year that we talked about how EDA and functional safety work together, but, based on some recent certification announcements, this year we have a view from a different stance.
Can I Prove that my System is Safe?
With specs like ISO 26262 and DO-254, a big burden goes onto you developers to show that what you’ve created is safe. And that includes proving that the tools you relied on are also deemed safe. So, for EDA companies, there are two important aspects of certification: helping their customers to get certified and getting their own tools certified. The latter, of course, helps with the former.
When we talk about helping you to get certified, that tools-certification thing is only part of the answer. There are elements that you need to prove yourself, and tools can assist with that. Information can also help – like safety kits and safety manuals. The latter specify the safe way to use… some thing. Metrics that prove safety apply only if the safety manual is followed.
