Automotive functional safety ISO26262

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