How to write AV scenarios (and some notes about Pegasus)

Interesting topic. How to cover all possible cases for autonomous driving ?

The Foretellix Blog

Summary: There are several approaches for verifying that Autonomous Vehicles are safe enough. The Pegasus project is one interesting, thoughtful attempt to do that (focusing initially on highly automated driving, not AVs). In this post I’ll summarizes a recent Pegasus symposium, and describe what I like about the approach and what is perhaps still missing. I’ll then use an example scenario to talk about spec bugs (and “unexpected bugs” in general), and their implications for verification frameworks.

What’s the right way to verify / certify AVs? And who should decide? These are open questions with no clear answers yet. So any meeting where regulators, AV manufacturers, simulator vendors and other stakeholders try to come up with a common vision for AV verification should be interesting to watch. And the Pegasus symposium (held in Aachen, Germany last November) was just that (though it centered on the simpler case of highly automated…

View original post 3,019 more words

Tool Qualification – what’s difference between ASIL-D qualified SW tool and ASIL-A Qualified SW tool?

ISO26262 concerns just only random hardware faults and systematic fault. SW tool development does not cover hardware, so it means that random hardware faults can be neglected.

In this case, I’d like to ask some questions. What’s difference between ASIL A qualified vs ASIL D qualified? You may answer that more technical methods are required in ASIL D. Right. And what else?

If there is no more differences except technical methods, then I will ask a question again. if all highly recommended methods are applied, then can I say that it is developed according to ASIL D, and it can be ASIL D qualifiable?

And I ask more, how can safety requirements be identified? Strictly speaking, SW safety requirements are only generated from technical safety requirements in the system level, but I don’t think that system level are considered during a SW tool development.

In this case, what should be safety requirements? how safety requirements can be identified?

Assuming that safety requirements are identified, why their ASIL allocation should be ASIL D?

Maybe, a tool vendor engineer would answer that they considered ASIL D to support for supplier’s ASIL D projects. In this case, if you consider ASIL A only and produce a tool. by the way, if you determine that you want to advertise that your tool is ASIL D qualified, then what are differences in the safety requirements aspect? maybe not.

if just technical methods are added for ASIL D, then is it sound that the tool is ASIL D qualified?

I rather recommend that it is useless to tag ASIL A/B/C/D for tool qualifications. No one want that their tool is ASIL B qualified more than ASIL D qualified.

ISO26262, SOTIF, Autonomous Vehicle, Robot