Analyse av systemsikkerhet

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

2. Program

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Preliminær hasardanalyse - PHA Tor Stålhane IDI / NTNU

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. 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. The PHA table Preventive actions indicates both barriers and tests.

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. Hasardanalyse - HazOp Tor Stålhane IDI / NTNU

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. 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. The HazOp Table – simple This is a simple version – more elaborate versions gives more info and requires more work.

24. Channel/Event Guideword Failure Condition (Hazard Description) Phase Effect of Failure Condition Classification Reference Verification The HazOp Table – advanced

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. 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. 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. New guidewords

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. 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. 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. Ledeord – diskusjon - 1 Spesielle ledeord: • Fordeler: • tilpasset programvaresystemer • raskt å komme i gang • Ulemper: • behøver ikke passe godt til denne applikasjonen

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. 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. 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. 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. FeilMode EffektAnalyse - FMEA Tor Stålhane IDI / NTNU

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. FMEA - 2

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. FeilTreAnalyse - FTA Tor Stålhane IDI / NTNU

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. 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. 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. Elementer i et feiltre • Logiske porter • ELLER-port • OG-port • Betingelsesport – ta hensyn til systemtilstander • Hendelser • Primærhendelse • Sekundærhendelse • Overføringer • Kommentarer

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. Fire breaks out . + Ignition fluid is near the fluid Leakage of flammable fluid Employee is smoking Spark exists Bruk av OG og ELLER-porter

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

49. Wrong code Transponder error Network error Data destroyed Wrong table inserted Changes outside mtns Transport error Decode error Hazard Fault Tree Example -1

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