Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

1 Analyse av systemsikkerhet Tor Stålhane IDI / NTNU.

Liknende presentasjoner

Presentasjon om: "1 Analyse av systemsikkerhet Tor Stålhane IDI / NTNU."— Utskrift av presentasjonen:

1 1 Analyse av systemsikkerhet Tor Stålhane IDI / NTNU

2 2 Program TidKommentarer 11:15 – 12:00 Om risiko, pålitelighet, safety og security Preliminær Hasard Analyse (PHA) – generell innføring HazOp – generell innføring FeilModeEffekt Analyse (FMEA) – generell innføring 12:00 – 13:15Lunsj 13:15 – 14:00 FeilTre Analyse (FTA) – generell innføring PHA – eksempel fra EPJ Øving 1: PHA på system for togkontroll 14:15 – 15:00 HazOp – eksempel fra EPJ Øving 2: HazOp på system for togkontroll 15:15 – 16:00 FMEA - eksempel FTA – eksempel Øving 3: FMEA på en komponent i systemet for togkontroll 16:15 – 17:00Oppsummering og diskusjon

3 3 The Happy Scenarios When making scenarios for a new system, all focus tends to be on the success – requirements for the happy scenarios. Our main concern is to Identify hazards Find out how to prevent hazards Convert the prevention strategy into requirements. This means that we have to look beyond the happy scenarios.

4 4 The Dark Side Developers have always be primarily concerned with solving the customer’s problems. What is all too often forgotten is that our solutions can introduce new problems – the dark side of the system, as opposed to the happy scenarios. We will focus on the dark side of systems’ development.

5 5 Reliability and Safety - 1 It is important to keep two concepts separated: Reliability – does the system do what the requirements says it shall do? Safety – will the system refrain from hurting people or destroying equipment and environment? Security – will the system prevent unauthorized access? We will focus on safety and security.

6 6 Reliability and Safety - 2 We can, however, not ignore reliability. The question of reliability is important when we want to insert a barrier against a hazard. We need to know the probability that the Hazard will occur Barrier will work when needed – reliability

7 7 The Safety Perspective We need tools and methods to Identify what can go wrong - hazards Translate the hazards into requirements that will help us to avoid the hazards Develop tests that check that the hazard- avoidance requirements are correctly implemented

8 8 Important Methods - 1 Methods used in hazard analysis should: Be simple so that all types of personnel can participate Be transparent in order to give confidence Allow inclusion of hardware, software and operators

9 9 Important Methods - 2 The method we use must have a process – a way of doing the job. This is important in order to be able to Teach the method Improve the method as we get more experience – process improvement.

10 10 Important methods - 3 PHA and HazOp – what can go wrong and what are the consequences Fault Tree Analyses – how can it go wrong Failure rate budgeting – what will be the reliability requirements for each component Failure Mode and Effect Analysis (FMEA) – what are the consequences of a component failure

11 11 How to identify Hazards - 1 Our ability to identify hazards and the method to be used will depend on the amount of information available at the point of analysis. We will discuss situations where we have: A concept or an idea for a system. A set of stories. A set of use cases, be it diagrams or textual descriptions.

12 12 How to identify Hazards - 2 Irrespective of method we need: Information about the environment – where will the system be used? People with knowledge of and experience with the application domain – the stakeholders.

13 13 How to identify Hazards - 3 All methods for hazard identification is really a structured brainstorming process. The stakeholders supply the knowledge and experience needed. The method supply the structure necessary to use the experience and knowledge available.

14 14 Process results The hazard analysis must give us info that can be used to write Changes and additions to the requirements in order to prevent hazards New tests for the new requirements. Requirements without tests are mostly ignored.

15 15 Preliminær hasardanalyse - PHA Tor Stålhane IDI / NTNU

16 16 The PHA - 1 The preliminary hazard analysis – PHA - has only one structuring device – the PHA table - and should only be used early in the process. This is reflected in the level of detail used in the table. It is important to include both effects of the hazards and the corresponding preventive actions. This is important since we want to identify barriers and tests.

17 17 From Concept to Hazards A concept, as used here, is an idea to a system – somebody saying something like ”We need a system to store and manage all our patient journals”. Somebody says ”Yeah – that’s great, let’s get started!” Our mission is to add the dark side perspective by asking ”How can this create a hazard?”

18 18 The PHA table Preventive actions indicates both barriers and tests. HazardCauseMain effectPreventive action Wrong diagnosis retrieved Wrong diagnosis inserted Kill or hurt patient Double check all patient info inserted ::::

19 19 PHA results At this stage We have no code – not even an architecture. Thus, the preventive actions are at a rather high level – for instance plain text. The tests are just descriptions such as ”Check that A occurs in state B” or ”Check that preventive action C prevents problem D in state E”

20 20 Hasardanalyse - HazOp Tor Stålhane IDI / NTNU

21 21 Process input We can do a HazOp based on one of the following: The functions – functional HazOp. Focus is on “How can this function fail?” The system’s structure – study nodes. Focus is on “How can we get problems at this point in the system?”

22 22 The HazOp The HazOp has two structuring devices – the table and the guide words. This makes it more efficient in identifying hazards. However, it also requires more information – the structure of the system, used to identify the study nodes.

23 23 The HazOp Table – simple Guide word Study node ConsequencesCausesPossible solutions This is a simple version – more elaborate versions gives more info and requires more work.

24 24 The HazOp Table – advanced Channel /Event GuidewordFailure Condition (Hazard Description) PhaseEffect of Failure ConditionClassificat ion ReferenceVerification

25 25 Study Nodes A study node is a point in the system where we want to focus. Usually it is a point where The system interacts with its environment – e.g. use input. Two or more parts of the system exchange information – e.g. a network connection.

26 26 The HazOp Guidewords - 1 The guidewords are used to focus the attention of the participants. The standard guidewords are related to production processes, e.g. none, more, less, as well as. Each guideword is combined with each study node, e.g. “none” and “patient id”

27 27 The HazOp Guidewords - 2 The lack of software-related guidewords can be dealt with in at least two ways: Make new, software related guidewords Give new, software-related meaning to the original guidewords. In addition, add guidewords for timing. The second solution has turned out to be the best one.

28 28 New guidewords

29 29 Standard guidewords - 1 Examples of standard guidewords: Too much Too little Interpretation for a special application: Too much – value above upper limit Too little – value below lower limit

30 30 HazOp med standard ledeord Standard ledeord –Mindre –En del av Tolka ledeord for programvareapplikasjon. I prinsippet ny tolking for hvert nytt system –Ankomst av signal: mindre -> sporadisk –Innhold i signal: mindre -> ufullstendig

31 31 Standard guidewords - 2 The software-related interpretation of the guidewords is done through a set of group discussions. For each guideword GW, the discussion starts with a question: what does this GW mean In our system? For this study node?

32 32 Ledeord – diskusjon - 1 Spesielle ledeord: Fordeler: –tilpasset programvaresystemer –raskt å komme i gang Ulemper: –behøver ikke passe godt til denne applikasjonen

33 33 Ledeord – diskusjon - 2 Tolka ledeord: Fordeler: –vil alltid passe godt til denne applikasjonen –tolkingsprosessen kan gi ny viktig forståelse og input til analyseprosessen. Ulemper: –ekstra jobb før vi kan komme i gang selv om gjenbruk er mulig.

34 34 From Hazards to Requirements The movement from hazards to requirements starts with a question: ”Now that we know what can go wrong, how can we prevent it?” The start of the answer is found in the HazOp table - the failure condition. If we can prevent this condition, we can prevent the problem from occurring.

35 35 Sources of Barriers The output from the analysis indicates the barriers needed. PHA – ”Preventive action” tells us what to do to prevent the hazard - a barrier. HazOp – ”Failure condition” or ”Effect of failure condition” gives us two opportunities for inserting barriers.

36 36 HazOp At this stage, we have specified the Requirements of the subsystems. Algorithms to be used to solve each problem. In object-oriented development we have identified The most important classes Their most important attributes and methods.

37 37 FeilMode EffektAnalyse - FMEA Tor Stålhane IDI / NTNU

38 38 FMEA - 1 FMEA is a method for systematic checking each system component How can the component fail? What are the consequences for the component? What are the consequences for the system? How can we handle the dangerous event?

39 39 FMEA - 2 Klasse / MetodeFeil modus FeileffektHandling eller barriere Alvorlighetsgrad Kredittvurdering av kunde Kredittvur dering er for høy Kundene kan bestille mer enn kreditten deres dekker 1) Manuell kontroll når man setter eller forandrer kreditt vurderingen 2) Implementere en funksjon som mottar kreditt vurdering fra eksterne kilder Høy Kreditt vurdering er for lav Kunden får ikke lov til å bruke sin maksimale kreditt Medium

40 40 FMEA - 3 The FMEA method: Offers a systematic walk-through of one or more system components. Focuses on preventions – barriers - rather than cures and fixes. Produces an easy-to-use list of dangers and ideas on how they can be removed or handled.

41 41 FeilTreAnalyse - FTA Tor Stålhane IDI / NTNU

42 42 Hva er et feiltre Et feiltre er et logisk diagram som illustrerer sammenhengen mellom en uønsket hendelse (hazard) i et system og årsakene til denne hendelsen. Fordelen med feiltrær er at de som foretar analysen blir tvunget til å forstå systemet til bunns. Mange svakheter kan derfor bli avdekket allerede mens man utvikler feiltreet.

43 43 Når skal vi bruke feiltreanalyse - 1 Feiltreanalyse krever mye innsats og bør brukes med omtanke. Derfor bør vi Bruke feiltreanalyse for å analysere viktige feilmoder Ikke bruke feiltreanalyse til å analysere enhver irriterende feilmode

44 44 Når skal vi bruke feiltreanalyse - 2 To mulige formål: Hvor sannsynelig er det at denne feilen inntreffer? Hvordan skal vi fordele ansvaret for påliteligheten i dette systemet?

45 45 Elementer i et feiltre Logiske porter –ELLER-port –OG-port –Betingelsesport – ta hensyn til systemtilstander Hendelser –Primærhendelse –Sekundærhendelse Overføringer Kommentarer

46 46 Utvikle/konstruere feiltrær Spesifiser en uønsket hendelse (hazard) og la denne være topphendelsen i feiltreet. Analyser systemet for å finne de hendelsene som kan være direkte årsak til denne hendelsen og bind de sammen med en logisk port. Gjenta forrige punkt for alle hendelser inntil alle hendelser er dekomponert til primærhendelser.

47 47 Bruk av OG og ELLER-porter Ignition fluid is near the fluid Fire breaks out Leakage of flammable fluid Employee is smoking Spark exists. +

48 48 Betingelsesport Operator pushes wrong switsh when alarm sounds Alarm sounds Operator fails to shutdown system Alarm sounds Operator pushes wrong switch.

49 49 Fault Tree Example -1 Wrong codeNetwork errorData destroyed Wrong table inserted Changes outside mtns Transport errorTransponder error Decode error Hazard

50 50 Fault Tree Example - 2 Wrong table inserted Faulty manual check Wrong table inserted - B Wrong table inserted - A Wrong data inserted Table change while not in maintenance mode HW switch failure SW switch failure Switch SW error Switch stuck Wrong info from switch

51 51 Fault Tree Analysis - 2 Based on a software fault tree we can Compute reliability requirements for a component to set requirements on methods and techniques used during development Identify the need for barriers realized in software, hardware or operational procedures

52 52 Failure Rate Budgeting Failure rate budgeting starts with the Total acceptable system failure rate – e.g. from the assigned SIL number List of identified hazards from the HazOp. Each hazard is assigned to a subsystem or component.

53 53 Tre former for feilbudsjettering Ta utgangspunkt i akseptabel risiko – R. Finn konsekvensen K i av hver enkelt feil. Sannsyneligheten for hver enkelt feil må være mindre enn R /  K i Finn akseptabel feilrate for systemet. Gi tillatt feilrate til hver komponent via feil- budsjettering. Kvalitativ analyse – stort sett bare brukt for å identifisere behov for barrierer.

54 54 Feilbudsjettering Enkel feilbudsjettering, basert på feiltrær der antall hendelser inn til en port er N: For en ELLER-port – gi hver grein et budsjett på / N. For en OG-port – gi hver grein et budsjett på 1/N

55 55 Systemfeil Subsys A Y 2Y 1 Nettverk Subsys B X 1X 2 10 -5 3*10 -6 1.5*10 -6 1.7*10 -3

56 56 Kvalitative ”beregninger” La {Input} være settet av alle input til en port. Da gjelder: For en OG-port: Output = min ({Input}) For en ELLER-port: Output = max({Input}) max(H, L) = H min(H, L) = L

57 57 Systemfeil Subsys A Y 2Y 1 Nettverk Subsys B X 1X 2 L L LHLL

58 58 Iterasjoner Feilbedusjettet vil sette krav til feilraten for hver enkelt komponent. Viss kravene er realiserbare og testbare så er vi ferdig med dette nivået av analysen. Ellers må vi sette inn barrierer på dette eller et høyere nivå i treet.

59 59 Barrierer Barrierer er ekstra funksjoner som settes inn for å Forhindre feil Redusere konsekvensene av en feil Gi alarm viss en feil holder på å inntreffe

60 60 Barrierer - eksempel 10 -6 10 -3 Algoritme Rimlighetssjekk

61 61 HazOp og erfaring Tor Stålhane IDI / NTNU

62 62 The Challenge of HazOp You cannot find hazards that are not present in one or more of the participants’ heads when the process starts The method generates no new knowledge and the results are thus critically dependent on the participants’ knowledge and experience.

63 63 Our Solution More experience will give a better HazOp. This can be achieved through reuse of experience. In order to make this work, we need processes for: Experience harvesting Experience reuse

64 64 Experience Harvesting We need to register experiences related to the application domain. This include: Accidents Near-accidents Unexpected behaviour Malfunctions Other problems

65 65 Experience Reuse - 1 Before performing a HazOp or PHA we should search our data base for experiences related to the application domain and ask: Could this happen here? What would be the consequences? How can we safeguard against this?

66 66 Experience Reuse - 2 The effect of reuse is to augment the experience available during the HazOp or PHA. Instead of only the experience and knowledge of the participants,we can also draw on the experience from earlier systems in the same and in related application domains.

67 67 Experience Reuse - 3 Reuse of a hazard can also imply reuse of Barriers – how did we prevent this from happening last time? Test – how did we check that the barrier worked the last time? Experience can be a major company asset.

68 68 Experience Reuse - 4 If we discover a hazard in a system that has already been analyzed we need to do a Post Mortem Analysis – PMA. We need to find answers to the following questions: Why didn’t we find this hazard during HazOp? How can we improve so that we don’t repeat the mistake?

69 69 Safety case Safety case er en mellomting mellom FMEA, HazOp og FTA, men uten å bruke FTA’s strenge notasjon. Safety case er nyttige for å kunne diskutere hva vi egentlig hevder å kunne oppfylle av sikkerhetskrav, framstilt på en systematisk måte.

70 70 What is a Safety Case A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment This method is a tool for managing safety claims Containing a reasoned argument that a system is or will be safe. Manifested as a collection of data, metadata and logical arguments.

71 71 Safety Case structure Claim Argument A Evidence A1 Argument B Evidence A2 Evidence B1 Claims about a property of the system or a subsystem Arguments linking the evidence to the claim Evidence is used as basis for the safety argument Inference rules for the argument

72 72 Safety case and PHA PHA, accommodates analysis of a project at an early phase, when we have only high level information Safety Case, supports the definition of a safety requirements specification by forcing the developers to argue that the intended system can be trusted

73 73 Combining methods Environment Safety Requirements Safety case PHA and/ or HazOp Customer Requirements

74 74 PHA eksempel Tor Stålhane IDI / NTNU

75 75 Patient Journal Concept Primary Physician Nurse Physician Lab system Patient journal system Top level view – identify system and stakeholders

76 76 From Concept to Hazards - 1 HazardCauseMain effectPreventive action Wrong diagnosis retrieved Wrong diagnosis inserted Kill or hurt patient Double check all patient info inserted Stored diagnosis info corrupted Double store and check Wrong patient id used at insertion or retrieval Redundant patient info required for retrieval ::::

77 77 From Concept to Hazards - 2 The results from the PHA can be used to write Requirements – “ Double store and check”. Implement the necessary mechanisms Tests – “ Redundant patient info required for retrieval”. Test retrieval Inputs to manual procedures – “ Double check all patient info inserted”. Write manual info insertion procedure.

78 78 Øving - PHA Konsept: system for togkontroll Vi ønsker å få info om posisjonene til alle tog slik at vi til en hver tid vet hvor de er. Dette vil vi bruke til å Hindre kollisjoner Gi informasjon til reisende om ankomsttider, forsinkelser osv.

79 79 HazOp eksempel Tor Stålhane IDI / NTNU

80 80 Use Case for Patient Journal Nurse Medication Documents Diagnosis Orders and responses Treatment plan PhysicianPrimary PhysicianLab system

81 81 HazOp for Medication GuidewordStudy nodeConsequencesCausesPossible solutions Too late Medication info input Lack of medication Info arrives too late Physicians must be prompted for medication info Less Wrong medication Lack of info As well asConflicting info Check all medication info for consistency More Extra, possibly outdated info Mediation info must be time stamped.

82 82 Øving HazOp Train Balise Transmitter / receiver Input Position converter Balise table

83 83 Safety Case eksempel Tor Stålhane IDI / NTNU

84 84 Customer Information A business needs a database containing information about their customers and the customers’ credit information. An important requirement for such a system would be ensuring the correctness and validity of customers’ credit information. Any problems concerning this information in a system would seriously impact the company’s ability to operate satisfactorily.

85 85 PHA table Customer info management DangerCausesEffectsBarriers Wrong address inserted Correspondence sent to wrong address Check against name and public info, e.g. “Yellow pages” Update error Database errorTesting Wrong credit info inserted Wrong billing. Can have serious consequences Manual check required Update errorConsistency check Database errorTesting

86 86 Safety Case Credit info DB is sufficiently reliable Credit info must be correct when sending invoice Implementation of credit info consistency check Database Implementation testing Implementation of manual credit info check Insertion and updating credit info is made trustworthy Claim Arguments Evidence

87 87 FMEA eksempel Tor Stålhane IDI / NTNU

88 88 Ordresystem

89 89 FMEA av kreditvurdering Klasse / MetodeFeil modusFeileffektHandling eller barriere Alvorlighetsgrad Kredittvurdering av kunde Kredittvurd ering er for høy Kundene kan bestille mer enn kreditten deres dekker 1) Manuell kontroll når man setter eller forandrer kreditt vurderingen 2) Implementere en funksjon som mottar kreditt vurdering fra eksterne kilder Høy Kreditt vurderi ng er for lav Kunden får ikke lov til å bruke sin maksimale kreditt Medium

90 90 FTA eksempel Tor Stålhane IDI / NTNU

91 91 Train control - top level

92 92 Train control – message content

93 93 Øving FMEA Tor Stålhane IDI / NTNU

94 94 Øving FMEA - 1 Train Balise Transmitter / receiver Input Position converter Balise table

95 95 Øving FMEA - 2 Lag en FMEA for posisjonskonverteringen. Denne enheten har følgende funksjonalitet: Motta balise nummer fra togradioen via optisk fibernett Hent geografisk posisjon fra balisetabellen Vis posisjon til togleder

Laste ned ppt "1 Analyse av systemsikkerhet Tor Stålhane IDI / NTNU."

Liknende presentasjoner

Annonser fra Google