Safety-Critical Systems 2 T Ilkka Herttua

Main topics for spring 2003 Fault tolerance/reliability (III) Hardware/Programmable Logic Controllers (III) Safety-Critical Software (IV) Formal Methods – modelling (IV/V) Verification/Validation and Testing (V) Seminars (VI)

Risk Analysis Risk is a combination of the severity (class) and frequency (probability) of the hazardous event. Classes: - Catastrophic – multiple deaths - Critical – a death or severe injuries - Marginal – a severe injury - Negligible – a minor injury

Hazard probability Probability classes: Frequent Probable Occasional Remote Improbable Incredible

Risk acceptability National/international decision – level of an acceptable loss (ethical, political and economical) Risk Analysis Methods: ALARP – as low as reasonable practical (UK, USA) GAMAB – not greater than before (France)

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

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

Overall safety lifecycle

Development Methods Right Requirements phase complete – linking to hazards - correct – testing & modelling - consistent – semiformal language - unambiguous - better English

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

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

The REVEAL Process

On-going Processes Management –Baselining –Tracing –Change management –Fault management –Use of tools Conflict Management –Identification of conflicts –Negotiation –Recording conflict and outcome for future change management

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

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

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

“How do I manage change?” Stay on track and meet schedule Changes from all users including DOORSNet TM Read-only user submits “Change Proposal” Changes reviewed on-line Changes automatically update module Accepted Rejected Link On Hold In Review

Team Work: DOORS in Intranet/Internet DOORSNet User Read, Comment, Review, Change Request submission View by Browser Over the Web in your Project Data DOORS User

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

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

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

Designing for Safety Faults groups: - requirement/specification errors - random component failures - systematic faults in design (software) Approaches to tackle problems - right system architecture (fault-tolerant) - reliability engineering (component, system) - quality management (designing and producing processes)

Designing for Safety Hierarchical design - simple modules, encapsulated functionality - separated safety kernel – safety critical functions Maintainability - preventative versa corrective maintenance - scheduled maintenance routines for whole lifecycle - easy to find faults and repair – short MTTR mean time to repair Human error - Proper HMI

Safety management Safety culture/policy of the organisation - Task for management ( Tarkets ) Safety planning - Task for safety manager ( How to ) Safety reporting - All personal - Safety log / validation reports

Home assignments 4.18 (tolerable risk) 5.10 (incompleteness within specification) before 25. February to