Automotive functional safety ISO26262

Few days ago, we were participating in a meeting with a few colleagues and going through the Safety manual of a Software vendor who was providing us two ASIL Components, X and Y.  There were several requirements stated in this Safety manual that we had to satisfy. There was one such requirement that stated: “The Integrator shall ensure that the version number for the code of Component X and Component Y that is integrated in the System shall be compatible. These version numbers are hard coded in ROM – Required ASIL level: ASIL B”.  The Software colleague in our meeting immediately jumped in and said "Oh, this is easy, I can do a review in the Integrated SW and check that the version no of X and Y are compatible.” Later, he paused and said, “ Oh… but wait, this is an ASIL B requirement - so that means I cannot check just by a review, the SW needs to check during run time that the version numbers are compatible. If they are not compatible, it needs to trigger a safe state!" Anot...

In this blog post, let us discuss about one of the most common myths that is associated with functional safety. We often hear that ‘nothing’ needs to be done for ASIL-A and a Quality Managed (QM) development of the software is sufficient to achieve ASIL-A compliance. Unfortunately, nothing could be farther from the truth. Let us deep dive a bit to understand what QM means, what ASIL-A means and what difference exists between these two. Knowing the deeper meaning of these terms will help us to see where the boundary of QM stops & where ASIL development starts. As an additional bonus, we have also thrown in the difference between an ASIL-A & ASIL-B development so as to scale up the discussion around this topic.  As mentioned earlier, QM refers to ‘ Quality Managed ’. What this means is that the development process follows a standard and repeatable methodology for the development of the system. An example for such a methodology could be Capability Maturity Model (CMM) or ASPIC...