Software Safety Assurance for Metro Railways

Modern railway systems are becoming more software intensive than ever before. Majority of safety functions are implemented and/or controlled by computers. Dr Ajeet Kumar Pandey, RAMS Leader, Alstom Transport, explains the software safety assurance model for metro railway.

System Safety is the key driver in the design of systems and must stand upfront before any analysis. It is a planned, disciplined, and systematic approach to preventing or reducing accidents by managing hazards. Transportation systems such as automotive, avionics and railway are considered as safety critical system. Railways cover almost 70-80% of the total transportation industries.

Metro rail system is more software intensive than the mainline railway. System failures due to the software failure are very common and can results unsafe circumstances. A vital issue to perform software safety analysis for any system is to derive its safety profile line with its operational profile. It is important to note that all the subsystems are neither equally safety critical nor do they have equal software control. For example signaling & train control system are more software intensive than track work system. In order to ensure the safety of various subsystems, an operational profile based safety analysis (OPBS) is required. Moreover, software safety cases need to be developed besides generic safety case, to demonstrate that a system is acceptably safe to operate with software environment. It is desirable for all the software intensive safety critical systems (SIL-3 & SIL-4), to have a separate software safety case.

Related works

Reliability, Availability, Maintainability and Safety (RAMS) are the broadly accepted and desirable attributes of the product or systems. Reliability is the probability that a product will operate satisfactorily for a required amount of time under the stated conditions. Availability on the other hand, is the degree to which system/subsystem/components are operational and accessible when required for use. Availability is often looked at because, when a failure does occur, how quickly the system/subsystem can be restored or repaired. Maintainability is the probability that a failed system (or subsystems) can be restored or repaired to a specified condition within the specified time period when the maintenance is performed as per the stated procedures and resources.

Safety is an important constituent on RAMS and must stand upfront before any analysis & design of the system. Safety can be simply defined as freedom from unacceptable risk. It is a system attribute and should be intentionally designed into the system. The open objective of system safety is to identify, analyze, mitigate, eliminate, and document all the hazards across the lifecycle of the systems. Various hazard identification and analysis techniques such as Preliminary Hazard Analysis (PHA), System Hazard Analysis (SHA), Sub-system Hazard Analysis (SSHA), Interface Hazard Analysis (IHA) and Operation and Support Hazard Analysis (OSHA) shall be used across the system development. All the identified Hazards, their effects, and mitigations are systematically documented into the Hazard Log for future reference and actions. Unfortunately, most of the hazard analysis techniques are hardware oriented and not fitting well for analyzing the hazards of software intensive systems.

Many commercial and government agencies have developed generic as well as industry specific standards to specify and implement safety into the product or systems. Apart from these, many countries have produced their own industry specific standards in-line with the existing international standards.

Deriving software safety requirements

Software is extensively used to control or monitor the railway systems such as signaling & train control system (STC), rolling stock (RST), telecommunication systems (COM), and automatic fare collection systems (AFC). These systems are directly or indirectly related to safety. The system/subsystem requirements specification may be either safety related or not related to safety. Safety requirements need to be recorded separately as safety requirements specification. Furthermore, these safety requirements may be grouped as safety functional requirements and safety integrity requirements.

Because the software has uncertainty in itself and difficulty in evaluation due to the invisibility, sophisticated and independent software safety analysis is required to perform for each safety critical systems. As more reliance is placed on these systems, it is essential to ensure their operational safety. The first and foremost important activity of safety management is to gather safety requirements. Inadequate or ambiguous requirements are the key to most of safety-related software errors.

There are evidences that more errors occur during the requirements and design stages than during coding. Also, industries have agreed that it is cost effective to fix requirements errors in the early development process. The most critical challenge is to identify the requirements that can influence the system safety directly or indirectly. There are standards devoted to system safety practices, such as MIL-STD-882, IEC 61508, EN 50129, ISO 26262, EN 50129 etc. But unfortunately no standards have emphasized on the derivation of safety related software requirements separately. SSR can by derived from the given generic list of requirements. Safety requirements may be either safety related or safety critical and can be mapped to hazard causal factor one-toone, one-to-many, or many-to-one.

Collecting safety requirements is the first and vital activity of safety management. It is important to mention here that SSRs shall be derived from five sources: SRS, analysis of system functionalities, causal factor analysis of earlier mishaps and issues with hazard control implementations. A separate hazard log shall be developed to populate all the software related hazards. Traceability shall be made available from this hazard log to the software safety case.