Functional safety standards, including ISO 26262, require software-specific safety analysis. It’s part of the basic package of analysis for any ASIL rated system, alongside system FMEAs, fault trees, and so forth. But the current version of ISO 26262 gives no information on how to do a safety analysis. Practitioners want to know more.
I’ll be presenting on this topic at the upcoming medini analyze User Conference scheduled to be held in Troy, MI on Thursday, October 6th. My goal will be to provide useful advice on how to navigate the complex world of software safety analysis. This is a follow-up presentation, supplementing presentations given in 2015 at the SAE World Congress and last year’s medini analyze User Conference.
Software errors can be broadly categorized into three types. Each type can be addressed with a different analysis framework:
- For programming errors that take on common forms known generally (such as wrong pointers, race conditions, divide-by-zero, etc.) a software mitigation checklist can be used. This provides a global failure mode coverage analysis for common errors. This checklist supplements other software process measures already presumably in place, such as use of MISRA or similar coding standards, static analysis, etc.
- For programming errors that do not fall into these simple categories, a Software FMEA can be employed. This is a means of describing the potential failures of various software modules, and confirming that such failures won’t lead to a hazardous event. I’ll provide many more guidelines, tips, and hints for performing this analysis during the medini analyze User Conference.
- For programming errors that start in the non-ASIL portion of software, and propagate into ASIL portions of software, a Freedom-From-Interference Analysis is recommended. This analysis tells us where and how the safety-related code is protected from non-safety-related bugs. A few practical tips and hints will be shown at the medini analyze User Conference.
