Safety-Critical Systems 2 Requirement Engineering T- 79.5303 Spring 2006 Ilkka Herttua.

Slides:



Advertisements
Similar presentations
Risk Management Introduction Risk Management Fundamentals
Advertisements

T Safety Critical Systems (4 cr)
ITIL: Service Transition
Module 3 UNIT I " Copyright 2002, Information Spectrum, Inc. All Rights Reserved." INTRODUCTION TO RCM RCM TERMINOLOGY AND CONCEPTS.
Integrated Messaging and Process Analysis Control Techniques  SEA Inc. Proprietary Data – Please Protect Accordingly 6100 Uptown Blvd., NE, Suite 700,
Safety-Critical Systems 2 T Risk analysis and design for safety Ilkka Herttua.
Safety-Critical Systems 2 Requirement Engineering T Spring 2008 Ilkka Herttua.
Reliability Risk Assessment
1 Solution proposal Exam 19. Mai 2000 No help tools allowed.
SWE Introduction to Software Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance.
1 Risk evaluation Risk treatment. 2 Risk Management Process Risk Management Process.
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
Title slide PIPELINE QRA SEMINAR. PIPELINE RISK ASSESSMENT INTRODUCTION TO RISK IDENTIFICATION 2.
Tony Gould Quality Risk Management. 2 | PQ Workshop, Abu Dhabi | October 2010 Introduction Risk management is not new – we do it informally all the time.
Hazards Analysis & Risks Assessment By Sebastien A. Daleyden Vincent M. Goussen.
©Ian Sommerville 2006Critical Systems Slide 1 Critical Systems Engineering l Processes and techniques for developing critical systems.
Lecture 1.
Testing safety-critical software systems
© SAIC. All rights reserved. NATIONAL SECURITY ENERGY & ENVIRONMENT HEALTH CYBERSECURITY The Potential High Cost of Simple Systems Engineering Errors Jim.
Safety-Critical Systems 2 T Ilkka Herttua.
Telecom and Informatics 1 PSAM6, San Juan, Puerto Rico, USA - June 2002 ALLOCATING SAFETY INTEGRITY LEVELS IN PRACTICE Odd Nordland SINTEF, Trondheim,
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
What is Business Analysis Planning & Monitoring?
Safety-Critical Systems 6 Quality Management and Certification T
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 2.
WHAT IS SYSTEM SAFETY? The field of safety analysis in which systems are evaluated using a number of different techniques to improve safety. There are.
Safety-Critical Systems 6 Certification
Chapter 6 : Software Metrics
Views from different perspectives
Engineering System Design
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems 1.
Essentials of Machine Safety Standards in Perspective.
Safety Critical Systems ITV Model-based Analysis and Design of Embedded Software Techniques and methods for Critical Software Anders P. Ravn Aalborg University.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Telecom and Informatics Odd Nordland, SINTEF Frank Renpenning, SIEMENS 1 PSAM6, San Juan, Puerto Rico, USA - June 2002 RISK ACCEPTABILITY CRITERIA FOR.
Safety-Critical Systems T Ilkka Herttua. Safety Context Diagram HUMANPROCESS SYSTEM - Hardware - Software - Operating Rules.
Assessment of Alternate Methodologies for Establishing Equivalent Satisfaction of the Ec Criterion for Launch Licensing Terry Hardy AST-300/Systems Engineering.
QUALITY RISK MANAGEMENT RASHID MAHMOOD MSc. Analytical Chemistry MS in Total Quality Management Senior Manager Quality Assurance Nabiqasim Group of Industries.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Safety-Critical Systems T Ilkka Herttua. Safety Context Diagram HUMANPROCESS SYSTEM - Hardware - Software - Operating Rules.
Safety Critical Systems 5 Testing T Safety Critical Systems.
1 Safety - definitions Accident - an unanticipated loss of life, injury, or other cost beyond a pre-determined threshhold.  If you expect it, it’s not.
Safety-Critical Systems 5 Testing and V&V T
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
Rules for Supporting Part 803 and Part 806 Decision Making Page 1 Establishing Rules for: Medical Device Reports (803) & Correction and Removal Reports.
6 July 2000CSAM Team1 CERN Safety Alarm Monitoring Invitation to Tender Strategy CERN Safety Alarm System Supervisory Board 3st meeting CSAM project team.
Over View of CENELC Standards for Signalling Applications
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Attributes Availability Reliability Safety Confidentiality Integrity Maintainability Dependability Means Fault Prevention Fault Tolerance Fault Removal.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1. 2 An Introduction to Software Engineering 3 What is software? Computer programs and associated documentation such as requirements, design models and.
Failure Modes and Effects Analysis (FMEA)
Toward a New ATM Software Safety Assessment Methodology dott. Francesca Matarese.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
Introduction to Safety Engineering for Safety-Critical Systems Seo Ryong Koo Dept. of Nuclear and Quantum Engineering KAIST Lab. Seminar.
Functional Safety in industry application
SYSTEM SAFETY AND THE TECHNICAL AUTHOR
Chapter 1- Introduction
Software Requirements
Quality Risk Management
Software testing.
Unit I Module 3 - RCM Terminology and Concepts
Hazards Analysis & Risks Assessment
Presentation transcript:

Safety-Critical Systems 2 Requirement Engineering T Spring 2006 Ilkka Herttua

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

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.

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.

Developing safety-related systems To achieve safety: - safety requirements (avoiding hazards, risks) - quality management (follow up process) - design / system architecture (reliability) - defined design/manufacture processes - certification and approval processes - known behaviour of the system in all conditions

Overall safety lifecycle

Risk Analysis Risk is a combination of the severity (class) and frequency (probability) of the hazardous event. Risk Analysis is a process of evaluating the probability of hazardous events. The Value of life?? Value of life is estimated between 0.75M –2M GBP. USA numbers higher.

Risk Analysis Classes: - Catastrophic – multiple deaths >10 - Critical – a death or severe injuries - Marginal – a severe injury - Insignificant – a minor injury Frequency Categories: Frequent 0,1 events/year Probable0,01 Occasional0,001 Remote0,0001 Improbable0,00001 Incredible0,000001

Hazard Analysis A Hazard is situation in which there is actual or potential danger to people or to environment. Analytical techniques: - Failure modes and effects analysis (FMEA) - Failure modes, effects and criticality analysis (FMECA) - Hazard and operability studies (HAZOP) - Event tree analysis (ETA) - Fault tree analysis (FTA)

Fault Tree Analysis 1 The diagram shows a heater controller for a tank of toxic liquid. The computer controls the heater using a power switch on the basis of information obtained from a temperature sensor. The sensor is connected to the computer via an electronic interface that supplies a binary signal indicating when the liquid is up to its required temperature. The top event of the fault tree is the liquid being heated above its required temperature.

Fault event not fully traced to its source Basic event, input Fault event resulting from other events OR connection

Risk acceptability National/international decision – level of an acceptable loss (ethical, political and economical) Risk Analysis Evaluation: ALARP – as low as reasonable practical (UK, USA) “Societal risk has to be examined when there is a possibility of a catastrophe involving a large number of casualties” GAMAB – Globalement Au Moins Aussi Bon = not greater than before (France) “All new systems must offer a level of risk globally at least as good as the one offered by any equivalent existing system” MEM – minimum endogenous mortality “Hazard due to a new system would not significantly augment the figure of the minimum endogenous mortality for an individual”

Risk acceptability Tolerable hazard rate (THR) – A hazard rate which guarantees that the resulting risk does not exceed a target individual risk SIL 4 = < THR < per hour and per function SIL 3 = < THR < SIL 2 = < THR < SIL 1 =10 -6 < THR < Potential Loss of Life (PLL) expected number of casualties per year SIL = safety integrity level

Current situation / critical systems Based on the data on recent failures of critical systems, the following can be concluded: a)Failures become more and more distributed and often nation-wide (e.g. air traffic control and commercial systems like credit card denial of authorisation) b)The source of failure is more rarely in hardware (physical faults), and more frequently in system design or end-user operation / interaction (software). c)The harm caused by failures is mostly economical, but sometimes health and safety concerns are also involved. d)Failures can impact many different aspects of dependability (dependability = ability to deliver service that can justifiably be trusted).

Examples of computer failures in critical systems

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

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.

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

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 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?

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

Requirement Engineering Tools – Doors (Telelogic) -Data base and configuration management -History, traceability and linking

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

Traceability in DOORS RequirementSpecification 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, Siemens Medical Systems IntegratorsBooz Allen, CSC, EDS, IBM, Litton/PRC, Mitre, SAIC, Unisys

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

Additional home assignments From Neil Storey’s book Safety Critical Computer Systems 1.12 (Please define primary, functional and indirect safety) 2.4 (Please define unavailability) by 1 March to