1. Safety-Critical Systems T- 79.232 Ilkka Herttua

2. Safety Context Diagram HUMANPROCESS SYSTEM - Hardware - Software - Operating Rules

3. Critical Applications Computer based systems used in avionics, chemical process and nuclear power plants. A failure in the system endangers human lives directly or through environment pollution. Large scale economic influence.

4. Safety Definition Safety: Safety is a property of a system that it will not endanger human life or the environment. Safety-Critical System: A system that is intended to achieve, on its own, the necessary level of safety integrity for the implementation of the required safety functions.

5. Safety Definition Safety integrity: The likelihood of a safety-related system achieving its required safety features under all the stated conditions within a stated operational environment and within a stated period of time. SIL levels 0 to 4. SIL 4 is the highest safety integrity level.

6. Integrity levels Safety Integrity is a measure of the likelihood of the safety system correctly performing its task. Safety Integrity levels: (failures/year) SIL 410E-5 – 10E-4 SIL 310E-4 – 10E-3 SIL 210E-3 – 10E-2 SIL 1 10E-2 – 10E-1

7. Verification and validation Verification is the process of determining that a system or module meets its specification. Validation is the process of determining that a system is appropriate for its purpose.

8. V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis Requirements Model Test Scenarios Software Implementation & Unit Test Software Design Requirements Document Systems Analysis & Design Functional / Architechural - Model Specification Document Knowledge Base * * Configuration controlled Knowledge that is increasing in Understanding until Completion of the System: Requirements Documentation Requirements Traceability Model Data/Parameters Test Definition/Vectors

9. Safety Requirements Requirements are stakeholders (customer) demands – what they want the system to do. Not defining how !!! => specification Safety requirements are defining what the system must do and must not do in order to ensure safety. Both positive and negative functionality.

10. Specification Supplier instructions how to build the system. Derived from the required functionality = Requirements. Requirement R + Domain Knowledge D => Specification S

11. Where do we go wrong? Many system failures are not failures to understand R requirements ; they are mistakes in D domain knowledge –A NYC subway train crashed into the rear end of another train on 5th June 1995. The motorman ran through a red light. The safety system did apply the emergency brakes. However the...signal spacing was set in 1918, when trains were shorter, lighter and slower, and the emergency brake system could not stop the train in time. Are you sure?

12. Requirement Engineering Right Requirements Ways to refine Requirements - complete – linking to hazards (possible dangerous events) - correct – testing & modelling - consistent – semi/formal language - unambiguous – text in real English

13. Requirement Engineering Methods – Reveal (UK) -All necessary included, right structure and understandable wording. Tools – Doors (Telelogic) -Data base and configuration management -History, traceability and linking

14. REVEAL REVEAL is a requirements engineering method (Praxis UK) –independent of particular notations –compatible with different tools The application of scientific principles –the role of domain knowledge in relating requirements to specifications Through a systematic process –what has to be done –what order it should be done in –how it can be done

15. Requirements Management with DOORS Slides provided by Telelogic/ Quality Systems & Software

16. Dynamic Object Oriented Requirements System Effizienz Interfaces Requirements Links Reports Analysis Change Proposal System Filter, Views Multiuser-Databank User Accounts Configuration- management Text Processing Templates, Standards DOORS Capture, Link, Trace, Analyse, Administer

17. Terminology in DOORS One Document, Group of related Information Requirements, Tests, Specifications, Change Requests, etc Consists of numerous Modules Project Module Object Attribute Data of a Module Characteristics of Objects or Links Date of last Change, Priority, Status, Costs,... Relation between two Objects Links

18. Traceability in DOORS User DemandsSystem Requirements Architectural Design Test Plan Follow Customer Ammendments through all the Documentation

19. Traceability - Requirements from Scenarios Goal hierarchy user requirements traceability Two people shall be able to lift the boat onto the roof of the average saloon car. The sailor shall be able to contact the coastguard when the boat is capsized. The sailor shall be able to perform a tacking manoeuvre. To have sailed and survived Ready to sail Sailed Returned home Boat loaded Boat lifted Boat unloaded Boat rigged Boat on car Mast rigged Center-plate rigged Rudder rigged Gibed Boat manoeuvred Tacked Cruised Boat capsized Gone ashore Boat righted Coast guard contacted

20. References TelecommunicationsAT&T, Alcatel, British Telecom, General Dynamics, ITT, L3 Comm, MCI Worldcom, Motorola, Nokia, Nortel, Tellabs Defense/AerospaceBoeing, Jet Propulsion Labs, Lockheed Martin, Raytheon Equipment ManufacturersCadence, Carrier, Cisco Systems, Hewlett Packard, Kodak, Otis Elevator, Pitney Bowes, Xerox AutomotiveBMW, Chrysler Daimler-Benz, Ford, General Motors, Rolls-Royce Financial/InsuranceCiticorp, Experian, Freddie Mac, Mastercard, NASD/NASDAQ/ASE, Nations Bank, Norwest Financial Services, Prudential, State Farm, UNUM, USAA, VISA GovernmentCND, FDA, FAA, MoD, NIMA, NASA, NSA, DISA, IRS, DOD Healthcare/MedicalAbbott Labs, Beckman Instruments, GE Medical, HP Medical, Kaiser Permanente, Siemans Medical Systems IntegratorsBooz Allen, CSC, EDS, IBM, Litton/PRC, Mitre, SAIC, Unisys

21. V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis Requirements Model Test Scenarios Software Implementation & Unit Test Software Design Requirements Document Systems Analysis & Design Functional / Architechural - Model Specification Document Knowledge Base * * Configuration controlled Knowledge that is increasing in Understanding until Completion of the System: Requirements Documentation Requirements Traceability Model Data/Parameters Test Definition/Vectors

22. Developing safety-related systems To achieve safety: - safety requirements - quality management - design / system architecture (RAM) - defined design/manufacture processes - certification and approval processes - known behaviour of the system in all conditions

23. RAM Reliability is the probability of a component or system functioning correctly over a given period of time under a given set of operating conditions. (MTBF mean time between failure.) The availability of a system is the probability that the system will be functioning correctly at any given time. Maintainability: Maintenance is the action taken to retain a system in or return a system to its designed operating condition. (MTTR mean time to repair.)

24. Fault, error and failure A fault is defect within the system. Random faults – hardware components, systematic faults – software/hardware design and manufacture processes. An error is a deviation from the required operation of the system or subsystem. A system failure occurs when the system fails to perform its required function. (Significant, major and minor)

25. Fault management Fault management techniques: Fault avoidance – in entire system design phase Fault removal - before system enters service Fault detection – during service to minimising effects Fault tolerance – operate correctly in the presence of faults

26. Home assignments 1.12 (primary, functional and indirect safety) 2.4 (unavailability) Email by 14 February to herttua@eurolock.org