The QNX OS for Automotive Safety was recently granted ISO 26262 certification. So why is that such a big deal? Allow me to explain.
When it comes to being hard to pronounce, ISO 26262 takes the cake among international safety standards. If you don’t believe me, just try to say “ISO 26262” ten times quickly, in any language.
You know what else is hard? Achieving compliance with ISO 26262. QNX Software Systems has just received its first ISO 26262 certificate from TUV Rheinland, so I can make that claim with a strong measure of confidence!
ISO 26262 is a new functional safety standard developed specifically for passenger vehicles. Published in 2011, it is based on the grand-daddy of functional safety standards, IEC 61508. Since its introduction, ISO 26262 has grabbed a lot of attention in the automotive industry. Why? Because rapid advancements in technology are presenting new safety challenges. The sophisticated hardware and software technologies now making their way into passenger vehicles may enable cool features, but they also stretch the concept of safety beyond mechanical parts. ISO 26262 is specifically developed to address the safety requirements of these electric and electronic components.
Due diligence
The ISO 26262 standard describes how safety functions must be addressed throughout the entire software lifecycle. This approach ensures that safety isn’t treated as an afterthought during final testing, but as a matter of due diligence in every stage of development. Apart from following functional safety processes, the software maker must continually ask questions such as these:
These questions would sound familiar to any experienced safety engineer, but they might not be top of mind for many designers. Safety design imposes an extra dimension to a project that must be budgeted for, right from the start. In addition to the discipline and effort needed to develop any safety product, the ISO 26262 standard demands that you prove your product is safe.
Constructing the argument that the product complies with the standard, such as through building a safety case, is far from trivial. For instance, using methods like Goal Structuring Notation can help make a strong argument by giving some reason to the sea of documentation that serves as evidence for your safety claim. But it takes skill to wield the power of GSN to produce an effective, well-structured safety case.
In short, achieving ISO 26262 certification is a huge undertaking. But then, so is the importance of the ultimate goal: safer cars.
Again, for an inkling of how tough it is to get certified, just keep repeating the name of the standard without screwing up...
Recommended reading
QNX Unveils New OS for Automotive Safety
Architectures for ISO 26262 systems with multiple ASIL requirements (whitepaper)
Protecting Software Components from Interference in an ISO 26262 System (whitepaper)
Ten Truths about Building Safe Embedded Software Systems (whitepaper)
You know what else is hard? Achieving compliance with ISO 26262. QNX Software Systems has just received its first ISO 26262 certificate from TUV Rheinland, so I can make that claim with a strong measure of confidence!
 |
The certificate. |
Due diligence
The ISO 26262 standard describes how safety functions must be addressed throughout the entire software lifecycle. This approach ensures that safety isn’t treated as an afterthought during final testing, but as a matter of due diligence in every stage of development. Apart from following functional safety processes, the software maker must continually ask questions such as these:
- In what ways could my software fail?
- If it does fail, how could it affect the safety of the overall system?
- How can I mitigate the risk of failure?
These questions would sound familiar to any experienced safety engineer, but they might not be top of mind for many designers. Safety design imposes an extra dimension to a project that must be budgeted for, right from the start. In addition to the discipline and effort needed to develop any safety product, the ISO 26262 standard demands that you prove your product is safe.
Constructing the argument that the product complies with the standard, such as through building a safety case, is far from trivial. For instance, using methods like Goal Structuring Notation can help make a strong argument by giving some reason to the sea of documentation that serves as evidence for your safety claim. But it takes skill to wield the power of GSN to produce an effective, well-structured safety case.
In short, achieving ISO 26262 certification is a huge undertaking. But then, so is the importance of the ultimate goal: safer cars.
Again, for an inkling of how tough it is to get certified, just keep repeating the name of the standard without screwing up...
Recommended reading
QNX Unveils New OS for Automotive Safety
Architectures for ISO 26262 systems with multiple ASIL requirements (whitepaper)
Protecting Software Components from Interference in an ISO 26262 System (whitepaper)
Ten Truths about Building Safe Embedded Software Systems (whitepaper)
