Skip to main content


Showing posts with the label Safety Software

ISO26262 Part 6, Clause 5 for Dummies - Part 1

If you are a SW Safety Engineer or a SW Engineer with practical hands-on experience in doing Safety activities, the Part-6 of the ISO26262 will be “Easy Peasy”. But if you are a Safety Engineer who never worked on SW but are asked to perform SW Safety Activities, then the Part-6 is surely “Tricky Dricky”!! This article is targeted towards Safety Engineers who are unfamiliar with SW. We have taken a specific set of requirements from Clause 5 of Part 6 and attempted to simplify it. This is Part 1 of Clause 5, and we will do another Part-2 for the same clause. Requirement 5.4.2 states the following:  5.4.2 The criteria that shall be considered when selecting a design, modelling or programming language are:  a) an unambiguous and comprehensible definition; EXAMPLE Unambiguous definition of syntax and semantics or restriction to configuration of the development environment.  b) suitability for specifying and managing safety requirements according to ISO 26262-8:2018 Clause 6, if modelling i

How to achieve FTT by design

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

A framework to control Systematic failures

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

A Handy Checklist for Safety Software Architecture

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

8 Steps for a best-practice Software Safety Analysis

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