Key Takeaways from How to Avoid Five Common Mistakes in Automotive Functional Safety Webinar

Q: Would you extend the concept of redundancy to the signal flow from sensor to actuator, not just sensing? 

In the redundancy discussion, one questioner sought to clarify that the idea could be extended from sensors to actuators, and even the control elements in between. The short answer is yes! The example was about sensors, but similar examples can be drawn for actuators, controllers or even whole systems.

Q: Is there a widely accepted data dictionary for autonomous driving safety device hardware/software data elements to reduce the risk of miscommunicating information between and among devices?  

Another interesting question was about the existence of a “data dictionary” for common hardware and software elements in autonomous driving. The thinking being that with a standard dictionary for data formats and communication protocols we could cut down on errors caused by misunderstandings between communicating elements. It’s a good idea, but at this time I’m not aware of such a dictionary. I do know however that communication and data protocols must be specified, and the correct specification (and deployment of that specification) is required for safety.

Q: Traditional functional safety standards such as ISO 26262 are based upon concepts such as ALARP and define a set of practices to be performed proportional to the risk or translate into FIT/SPF etc. for hardware. But what about autonomous vehicles? How does ALARP apply, or does it?  

There were some great questions related to autonomous driving and the methods and processes used to validate autonomous systems. The ISO 21448 standard requires an “acceptance criteria” for Safety Of The Intended Function (SOTIF) hazards and then specifies rationale for that criteria. Rationale cited include as low as reasonably practicable (ALARP), globally at least as good (GAMAB) and minimal-endogenous mortality (MEM). All of which are options to define an acceptance criteria. These high-level ideas can be run to ground in the form of specific acceptance criteria and validation targets in autonomous vehicle programs. I believe each rationale has some pros and cons, and that some may be better than others. But maybe a future webinar can address those.

Q: How extensive should the safety case be? If the safety case is almost a regurgitation of the configuration item list is it overkill?

Finally, the question of safety cases came up. It was noted that a safety case, which in ISO 26262 feels like a “tabulated” safety case, may require a more traditional written argument. Some standards including UL 4600, the Standard for Safety for the Evaluation of Autonomous Products propose a written safety case, including a structured argument using methods such as Goal Structuring Notation (GSN).  And we’ve seen several original equipment manufacturers pursue such an argument, and even publish it for public review and comment. I believe the written-argument-plus-GSN safety case, that is the “traditional view” of the safety case, will be essential to real-world autonomy safety. Whether organizing the ideas of ISO 21448, UL 4600, ISO 26262, or all of these and more, a written safety case helps put a massive stream of information into a human-understandable format. And that is an important goal.

Safety cases contain no magic, just as there is no magic to a safety analysis. In either case, the analysis is merely a structured record of the engineer’s best understanding. No more and no less. But the structured record makes it reviewable, makes it understandable, and makes it credible (hopefully) to a wider audience beyond the Safety Engineering team. And that’s an outcome worth the effort, as we try to move the industry forward to an autonomous future.

Watch back the on-demand webinar anytime.