Skip to main content

General Idea on Safety Assessment of Safety Critical Systems


  • Hazard VS Risk


Hazard refers to things or actions that may cause harm to the system or its users whereas  risk is a combination of the probability of a hazard to occur and the severity of its impact on the systems, its users and its environment. For each hazard, the risk is assessed and if the risk is not acceptable but can be made tolerable, measures must be introduced to reduce it ALARP

  • Safety Critical Systems


These are the software responsible for operating systems involving a human life. These software are responsible for operating system providing the desired output without posing a threat to a human life involved in the operation. Examples of these systems consists of air crafts flying on auto-pilot, radiation machines such as Therac-25 etc.
Safety Critical System: Therac-25 Radiation Machine


  • Safety Assessment


Ensuring safety for humans involved in a system's operation is of critical importance. This can be done either by testing or by implementing safety standards during the development of safety critical software system. Even after excessive testing of a such critical systems there is still room for faults leading to failure of such systems and eventually to a threat towards the life of the human involved in it. Thus the best way to ensure safety in such systems is to implement safety standards during the development life cycle of such software systems. Following is generalized list of steps that can be taken to conduct safety assessment of a safety critical system:

  1. Identify the nature of your software system e.g. for an automobile software system, the industry implements ISO 26262 standards.
  2. Identify the possible hazards in the system to be developed
  3. Conduct safety assessment of the identified hazards
  4. Update the design of the system to reduce the impact of the safety hazards identified
  5. Implement the updated design
  6. Test the updated design to check for any faults left in the system

Step # 1:

For an air bag system we can apply ISO 26262 standards

Step # 2:

Following are some of the possible hazards associated with an air bag inflation system:
  • Air bag failed to inflate on an impact leading to an injury or a casuality
  • Delay in air bag inflation leading to an injury or even a causality
  • Untimely inflation of an air bag lead to driver's distraction on the road, injury or casuality
To explain further we will be considering the first listed hazard.

Step # 3:

For conducting hazard assessment we are required to extract safety requirements of a system and this can be done by developing a fault tree of a particular hazard in our case its where the air bag fails to inflate on impact. More information on fault trees is accessible here. Following a fault tree for our identified hazard on air bag inflation system:
Fault Tree for Air Bag Failed to I
After designing a fault tree we are required to determine the severity of each of identified hazards and its causes along with the probability of their occurrence. For this part of the step we are to refer to the standard we choose to apply on the system. In case of our example, the severity level of the identified hazard is catastrophic and thus the probability assigned to the hazard is shown in the figure below:
Fault Tree After Assigning Probability Based on Severity Level of the Hazard
Studying the fault tree shows that the emerging nodes from OR gates represent single point of failure. Any of these single point of failure result in a true value can lead to system failure.Thus are required to have our utmost attention to reduce the probability of their occurrence or the impact they might have on the system.

Step # 4:

The next step is to develop from existing design of the systems, a new design the eliminates all single point of failure identified in the system's fault tree. This leads to the reduction in the number of possible hazards and its possible causes making the system safer for the human to use. There are several methods to reduce the impact of software hazard on the human, among these methods we will use the idea of redundancy in the system components to reduce the impact.
System Modified to reduce the probability of a failure to occur or reducing the impact of the system's hazard on its users
In the original design there is a single connection between the crash sensor and the air bag which means that if a crash sensor or an air bag ECU or even an air bag inflation device fails, the air bags won't inflate leading to an injury or a causality. To avoid this we have placed redundant crash sensors, air bag ECUs and air bag inflation devices connected to a voter. In case if any one of these devices fail, the voter will accept an input from the redundant component operational leading to other devices waiting for a response to execute the required operation.

Comments

Popular posts from this blog

Quality Practices in Agile Approaches

Agile Approaches Agile is an umbrella consisting of different methods adopted by the practitioners depending upon the circumstances. In the recent years  Agile has been gaining popularity among software practitioners due to its ability in assisting the development team to deliver the software product in a short amount of time.  Original Agile Approaches Based on the circumstances under which the agile methodologies have been used can be classified into the following 3 categories: Classification of Agile Approaches Agile Methodologies consist of the  original agile methods Hybrid Agile Methodologies consist of a combination of several original agile methodologies e.g. Industrial Extreme Programming merged with practices of Rational Unified Process Miscellaneous category consists of methodologies adopting only certain aspects of the original agile methodologies Extreme Programming, Test Driven/Test First Development, and SCRUM are among the most popular agile met

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The proposed

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of