TrafficInfraTech Magazine Linking People Places & Progress
Software Safety Analysis & Assessment
Rail accidents are more severe than other transportation system and jeopardize the safety of passengers, staff members, national assists and society. When an undesired event occurs, a rigorous investigation must be conducted to identify as many lessons as possible so as to prevent a recurrence of the event in the future. Unfortunately, incidents due to safety related software systems are not being investigated and documented separately with sufficient rigor to identify and disseminate important lessons arising from them.
Safety analysis (hardware/software) is performed to determine whether the level of risk associated with a system has been reduced to a tolerable level. This process involves the identification of hazards and their associated accident sequences, the calculation of safety targets for each hazard and the subsequent assessment of the system to determine whether the safety targets have been met. Moreover, safety of a software-intensive safety critical system has bearing on how the computer and other external elements will use it. Also, all safety critical function are neither equally dangerous nor do they have an equal probability to occur. Therefore, an independent safety analysis for various safety critical software modules should be carried out on the basis of their operational profile (or safety profile).
Originally, operational profile approach was developed for guiding test planning by assigning test cases to different operations in accordance with their probabilities of occurrence. A reliability driven testing is also beneficial for test planning, automatic test case generation and test case allocation. It has been observed that the approach is well suited for safety analysis as quantified the system on the basis of their criticality (safety profile).
Operational profile based software safety analysis
Metro rail system are more software intensive than the mainline railway. Moreover, all the subsystems are not equally software intensive nor do they create equal amount of safety risk. In order to analyze the safety of these subsystems, an operational profile based safety analysis is carried out. OPBS ensures that the all the possible hazards has been identified in all scenarios. For this, a user profile, system mode profile, functional profile and operational profile of each sub-system need to be developed before doing any safety analysis such as PHA, SHA, etc. In other words, first develop the operational profile of a subsystems (say rolling stock), then proceed for its safety analysis. Operational profile of any subsystem (say, rolling stock) can be derived through brainstorming or by means of earlier project data. To begin with any safety analysis, operational must be known. Operational profile development involves one or more of the five steps as shown in figure above.
One of the most vital activities of safety management is the development of Hazard Log where all the identified system hazards are logged. Since, the subsystems of metro rail are more software intensive, software hazard log need to be developed besides system hazard log. The purpose of the software hazard log is to consolidate all software related hazards into a single document. This will help to monitor the status of all software hazards (open, close, transfer etc.) as well as facilitates to control the future anticipated hazard. Moreover, another key objective of this software hazard log is to serve as a key input for software safety case which is discussed below.
Software Safety Case Development
Safety Case is developed to demonstrate that a system is acceptably safe to operate. Safety Case is required for all safety critical systems whether it is new or modified system. The purpose of a Safety Case is to present a clear, comprehensive and defensible argument with supportive evidences that the system will be safe throughout its life. Irrespective of the safety critical system, three categories of safety case should be developed:
• Generic Product Safety Case (GPSC): for independent of application
• Generic Application Safety Case (GASC): for a class of application
• Specific Application Safety Case (SASC): for a specific application/ installation
• Software Safety Case (SSC): additional requirement for software intensive system (recommended)
A safety case shall be submitted by the manufacturer and assessed by an independent third party safety assessor before the safety authorities approve it for commissioning. Generic product safety case will present the safety case for a generic product that can be used for different safety related applications. For example, a level crossing system of railway can control variety of way side equipment’s such as light, bell, and gate crossing without specifying the details of each. the Specific application safety case presents the safety properties of a particular combination of products in a given application i.e. a specific application is used for only one particular installation. In the context of level crossing predictor, this could be safety case for unidirectional, bidirectional, single track, or multi track level crossing system.
For systems containing software, a software safety case should be developed separately if the software directly or indirectly controls the safety functions of safety critical systems. Safety critical systems are more software intensive and therefore a safety argument must consider claims that the contribution of the software to the safety of the system is acceptable. The software safety case shall present comprehensive justification that the software will satisfy the safety aspects of the system as specified in the software requirements specification. To develop the software safety case, two key inputs are: supportive evidences and high level arguments. Supportive evidence such as requirements analysis, design used, test conducted etc. provides the fundamental information from which safety can be concluded. The high level argument sets out the principles on which the design is based and reasons why the design should satisfy the safety requirements. Moreover, it also explains of how the available evidence can be reasonably interpreted as acceptable safe through traceability with the safety requirements. Apart from supportive evidences and high level arguments, software hazard log information can also be used to finalize the software safety. This will help to finalize the software safety case in entirety with the safety justification and supporting evidences such as additional design control, testing reports, validation reports etc. Finally, a software safety case report is generated that summarizes all the key components of the software safety case, relevant references of related safety cases.