Automotive functional safety

Software Safety Analysis (SSA) is a kind-of-a verification activity that is performed on the Software to prove that it achieves all the Safety goals and provides the required Independence and freedom from interference.  Quite often we have seen that it is not clear for Software teams on how to do this analysis and which parts of the Software should they set their focus on. Also, in many cases, the activity is started towards the fag end of the project nearly when the safety software development has been completed, treating it more as a paper work to be completed.                             In this article, we present an 8-step method for performing a meaningful analysis. Before applying the method, here are some aspects to keep in mind: Basis and stage of the analysis SSA must be performed during the Architecture stage, based on the static and dynamic aspects of the Architecture. This provides the opportunity to correct weaknesses at an early stage of the software development. Stati

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. S

Designing Software for Safety is an extremely complicated task, and the ISO 26262 Standard specifies several processes, methods and work products for the same. For a Software Architect who is new to Safety, this information is overwhelming.  Image courtesy: Shutterstock Here we present an overview on what are the responsibilities of a "Safety" Software Architect and how they are different from that of a typical embedded software architect. The Safety Software Architect also has some additional tasks: Decomposes the SW Safety Requirements with respect to ASIL tailoring Performs the Software Safety Analysis and Dependent Failure Analysis Support the Software Tool qualification process for tools used for SW development Support the qualification of Software components if necessary Every responsibility stated above is a complex task in itself and has several dependencies that must be taken care of. In our upcoming posts, we will cover some of these in greater detail. Meanwhile, he

"Lets get the Implementation done, and go out to an agency like XYZ, find out about the paper work and get our work certified" This is a language we have heard being spoken several times. MYTH 1: Functional Safety is just "paper work"! Fact: Functional Safety is the discipline of designing Safety into every stage of the product life cycle starting right at the concept phase For some one who has just started with functional safety, and refers the standard, this can be overwhelming: The 2nd edition of ISO26262 has 12 Parts 37 Clauses > 100 Work products! Here is a mindmap of the different work products needed (those starting with x.5.x) Why do we need so many work products? This is because Functional Safety is designed into - every phase of the product life cycle - processes as well as technical methods - every stage of every phase In other words, the Standard spans the entire breadth and width of how a safety-relevant product is built, right from concept till

Myth 1: No Safety was implemented before ISO 26262   Fact: Automotive Systems have always had Safety measures and mechanisms in place Cars have been around for a century and ISO26262 for not even a decade! Cars have always had several safety features such as brakes, airbag, seat belts, tire pressure monitoring etc. But its not that just these features were implemented and nothing additional was done for Safety before the standard was published. Way back in the 1960s, Federal Motor Vehicle Safety and Regulatory standards such as FMVSS were introduced. This standard and its equivalents specified rules to avoid crashes, and contain impact during a crash. Additionally, Independent organizations like IIHS in the US evaluated several aspects of safety such as crashworthiness and crash avoidance and gave ratings to promote safety considerations in cars. These led to specifying requirements for Safety for components, System and design features.  Automakers have always been interested in the to