Automotive functional safety ISO26262

For every safety critical system, FTT requirements are specified by the OEM. What we often notice is that SW teams do not know the complete picture of how these timings are fulfilled. They tend to think that if testing proves that the FTT time is met, that is sufficient. Then they start to see that even though the Safety SW or HW of the System has not changed, suddenly FTT time measurements from testing start to change noticeably. In some cases that these measurements exceed the required FTT, and now suddenly the team is left wondering how this happened. " We did not change the Safety SW. Looks like the Non-safety part of the system is causing this change but we do not have control over it " they say. If you look at it from the ISO26262 Part-6 V model perspective, on the left side of the V is the Architecture design and the right side of the V is the Verification and Testing.  The argument of proving that FTT was met via testing is in the right side of the V. However, what we...

The ISO Standard specifies several methods on how to do Safety Software Architecture. These principles are generically stated. But most often these are not clear: - Why are these principles defined? - How do we ensure which principles we have achieved?  - Have we achieved the principle sufficiently?  For e.g., for a principle that states "restricted size of interfaces', why do I need this rule and how restricted should the size be? In this article, we first explain why these principles are needed in the context of Safety, and then propose a set of questions for each principle. These questions aim to act as a checklist to determine if the principle has been sufficiently satisfied. Assuming that most Organizations have well-defined guidelines for software architecture and the lessons learnt and best practices based on the experience from previous projects, these questions are intended to guide the architect or the reviewer of the architecture to think if all possible aspects hav...

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