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 ASPICE. Since we are dealing with automotive software, the industry practice is to follow the ASPICE model for development. A system developed using ASPICE Level 2 or Level 3 (in Level 2 everything is systematically planned and tracked, in Level 3 there are uniform guidelines for the complete organization. (Source:https://vda-qmc.de/en/software-processes/automotive-spice/)) could be considered as QM.
As per ISO 26262, one of the primary requirements for safety compliance is the achieving of freedom from interference (FFI). FFI needs to be satisfied in 3 aspects namely memory, timing & execution and communication. In order to do this, we need to design various safety mechanisms into our system like memory protection unit, watchdog manager etc. When we add these safety mechanisms on top of the QM system, we get into ASIL systems. When we have taken care of FFI (Including Dependent Failure Analysis (DFA) + Software Safety Analysis) in a QM system, we could claim to have achieved ASIL-A compliance. (Note: This is a bit of an oversimplification to make the concept easily understandable)
Does this mean that for an ASIL-A system we don’t have to take care of anything in the hardware design? The answer is a measured ‘Yes’. We still have to ensure that the hardware design follows a standard process & the HW components used are as per Automotive Electronics Council (AEC) standard (Ex: AEC-Q100). Apart from this, there is nothing specific that needs to be done for meeting ASIL-A. In a way, you could consider ASIL-A to be a purely software related improvement to the existing system where you handle memory, timing & execution and communication related aspects.
The entire thing starts to get interesting once we cross from ASIL-A to ASIL-B and above. The HW metrics (Single Point Fault Metric (SPFM), Latent Point Fault Metric (LPFM) and Failure In Time (FIT)) start coming into the picture and hence additional safety mechanisms will have to be added to the system in order to meet these HW metrics. Due to this, we could define ASIL-B as something like this:
HW and/or SW implementation
As previously mentioned, this is a bit of an oversimplification of the entire ASILs but it clearly outlines the thought stream one should have when trying to reach ASIL-B compliance.
One of the key mistakes that we have seen in our safety discussions with OEMs and as well with development teams is their assumption that ASIL-A doesn’t require anything specific related to safety and process compliance alone is sufficient. This is definitely not the case and additional mechanisms like FFI will have to be put in place to ensure we reach ASIL-A level of compliance.