SESA Transportation Working Group

Transcription

1 SESA Transportation Working Group Presentation: Establishment of Software Safety Requirements in a Later Phase of Project Life Cycle

2 Why Software Prevalence of Software in transport systems Functionality and flexibility provides benefits Importance for Safety

3 Summary Safety Requirements What is SIL Why is Software Different Project Experience Approach to SIL What happened to make it go wrong How it was fixed

4 Safety Requirements Safety Requirement A requirement that, once met, contributes to the safety of the system or the evidence of the safety of the system.

5 Safety Requirements Input to design process Can be specified or derived Derivation through RAMS processes (eg Hazard Assessment, FMECA etc) Safety Requirements can be developed later in project life cycle (in fact should be expected if risk management is continuous) Software Safety expressed as Safety Integrity Level (SIL)

6 Safety Integrity Levels (SIL) Defined as one of 5 levels SIL 0 to SIL 4 Establishes a tolerable failure rate that can be used in establishing performance Based on recognised standards: EN 50128/ EN Railway applications - Communication, signalling and processing systems IEC Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or E/E/PES) IEC Functional safety - Safety instrumented systems for the process industry sector

7 Safety Integrity Levels (SIL)

8 Why Is Software Different Based on top level hazard Safety Function SIL set for function, decomposes to system elements Random Hardware fault User fault Software fault Systematic

9 Why Is Software Different Software is different because: Requirements derived Failures are systematic, they arise due to errors during the development process Software often complex with high number of system states Requires robust development process: Increase understanding of software structure and behaviour Eliminate or reduce errors Traceability and demonstration of safety function

10 Safety Function Reliable deliver of safety function Fundamental Systems Engineering Requirement defined Allocated to subsystem (or module) Interfaces Understood Verification through development Validation Start with end in mind

11 Implementing SIL Can be pre approved (COTS) with application conditions and constraints Can be bespoke meaning fully developed Can be Modified Off the Shelf (MOTS)

12 Project Experience My project experience includes: Train Control System (SIL4) Track Infrastructure - Communications (SIL2) Rolling Stock Systems eg Speedo (SIL2)

13 What Has Gone Wrong 1. SIL established for COTS equipment without Safety Rating 2. SIL established late 3. Software could not achieve the required SIL

14 1. SIL Established for COTS Equipment Case of Inconsistent Requirements (where no COTS equipment existed with SIL) Once developed, almost impossible to establish that software addresses safety requirements, traceable through the development

15 2. SIL Established Late SIL derivation late System Development progressed because of contractual pressure As before, development not consistent with SIL requirements aborted work

16 3. Software Could Not be Validated Higher SIL levels require demonstration of independence of software and platform Demonstration when not physically separate is difficult

17 How It Was Fixed COTS Equipment First tried Proven In Use Argument Premise is same software, same application environment and history of proven performance Failed due to interaction with other software (too complex to validate) Permitted under IEC Resolved through reconsidering safety requirement and delivering safety through other (non software) means through coordinating with end user

18 How Was It Fixed 1. Safety Function Hardware fault User fault Software fault

19 How It Was Fixed 2. SIL established late was fixed through rewriting software modules related to safety functions Required demonstration of separation from other functions This was achieved through partitioning the software

20 How It Was Fixed 2.

21 How It Was Fixed 3. Software that could not be validated was resolved by implementing a watchdog Original Software was able to claim a SIL, though less than required Watchdog provided a simple verification of safety also with a SIL less than required Watchdog met requirements for diversity of platform and software Combination provided acceptable SIL

22 How It Was Fixed 3.

23 Good Examples Examples include: Signalling Systems (up to SIL 4) Doors and Brakes on rolling stock Reflect maturity in approach

24 Conclusion If software development commences prior to establishing safety requirements then it may be too late. Derivation of SIL takes time and must be accounted for in the project program. Use of COTS equipment, must ensure that safety requirements are understood before selecting equipment. Little chance of recovery where equipment is not able to support safety requirement

25 Conclusions Therefore, software safety requirements must be established early in the project life cycle Development of System providing for software safety allows: Discretion of structure for delivering safety Testing of feasibility of delivery

26 Questions?