1 / 42

Programme

Programme. Introduction What is High Integrity Software? Reliable Programming in Standard Languages Coffee Standards Overview DO178B and the Lockheed C130J Lunch Def Stan 00-55 and SHOLIS ITSEC, Common Criteria and Mondex Tea Compiler and Run-time Issues Conclusions. Aerospace.

ipo
Download Presentation

Programme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Programme • Introduction • What is High Integrity Software? • Reliable Programming in Standard Languages • Coffee • Standards Overview • DO178B and the Lockheed C130J • Lunch • Def Stan 00-55 and SHOLIS • ITSEC, Common Criteria and Mondex • Tea • Compiler and Run-time Issues • Conclusions

  2. Aerospace Standards Standards Rail Defence Nuclear Automotive

  3. Examples of (Safety-related) Standards more on these later • RTCA DO-178B (civil avionics) • Def Stan 00-55/56 (UK military) • IEC 61508 (generic ‘programmable systems’) • CENELEC 50128 (railway industry) • IEC 601 (medical equipment) • IEC 880 (nuclear power control) • MISRA (automotive industry) • Vary in their power to mandate or recommend

  4. Security Standards • Itsec • “Orange book” • Common Criteria • More on these later

  5. Defence Standards

  6. Rail Standards

  7. Other Standards

  8. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/RTOS etc. • Validation, verification and testing (VVT) • Accumulation of evidence – safety case

  9. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/RTOS etc. • Validation, verification and testing (VVT) • Accumulation of evidence – safety case

  10. Hazard/risk Analysis • Identification of hazards and their causes • Hazards have : • An estimated probability of occurrence • An associated severity • ‘Risk’ is combined probability and severity • ‘Risk regions’ can be identified: • Intolerable • ALARP – as low as reasonably possible • Broadly acceptable • ‘Safety’ is freedom from unacceptable risk

  11. Hazard/risk Analysis: Techniques • Various formalised techniques exist: • HAZOP (hazard and operability) • Failure modes and effects analysis • Fault tree analysis • A hazard log will be used to detail identified hazards and state steps being taken to mitigate them. • Different HAs: • Preliminary HA (PHA) • Design HA (DHA)

  12. Hazard Identification: HAZOP • A systematic, creative examination of a design • Performed by a multi-disciplinary team • Inspect each component in turn • Consider the design intention • Apply a list of guide words • Derive plausible deviations from the design intention

  13. Consequence Analysis • Purpose • To determine the intermediate conditions and final consequences arising from the identified hazards • Approach • A diagrammatic representation is recommended • Ideally quantitative estimate of probabilities • Techniques • Cause consequence diagrams • Event trees

  14. Event Trees Server Extinguisher Alarm Result IgnitionExtinguisher worksNo Incident Extinguisher fails Alarm soundsMinor Fire Alarm failsMajor Fire

  15. Causal Analysis • Purpose • To determine credible combinations or sequences of causal factors which can lead to the hazards • Approach • A diagrammatic representation is recommended • Ideally quantitative estimate of probabilities • Techniques • Failure Modes and Effects Analysis (FMEA) • Fault Tree Analysis (FTA)

  16. Accident Severity Categories Catastrophic multiple deaths Critical a single death; and/or multiple severe injuries or severe occupational illnesses Marginal a single severe injury or occupational illness; and/or multiple minor injuries or minor occupational illnesses Negligible at most a single minor injury or minor occupational illness

  17. Probability Ranges Frequent likely to be continually experienced Probable likely to occur often Occasional likely to occur several times Remote likely to occur some time Improbable unlikely, but may exceptionally occur Incredible extremely unlikely that the event will occur at all

  18. What Is Risk ? Severity Risk Catastrophic Intolerable Tolerable Negligible Minor Probability Frequent Incredible

  19. How Is Risk Regulated?ALARP ALARP = As Low As Reasonably Practicable

  20. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/RTOS etc. • Validation, verification and testing (VVT) • Accumulation of evidence – safety case

  21. Safety Integrity Levels • System will be assigned a safety integrity level, typically: • 4 – 1 : ‘high’ – ‘low’ • Can be based on probabilistic or MTBF concepts (e.g. 00-55) • DO-178B talks about levels A-E. • Techniques (and costs) will then be determined by the assigned SIL • Partitioning by SIL within system is normal

  22. What Is a SIL? • A general indicator of quality for design/build processes • Applicable to software and hardware • Probability that the system meets its requirements • Probability of systematic failure • Often misunderstood and misused

  23. Safety Integrity Levels (Probabilistic IEC 6 1508)

  24. Development for Different Sils (IEC 6 1508)

  25. IEC 61508: Software Detailed Design • 0 none • 1 structured methodology (CORE, JSD, MASCOT, Yourdon) • 2 + semi-formal methods (function block diagrams, data-flow diagrams, pseudo code) • 3 + formal methods (VDM, Z, CCS, CSP, HOL, OBJ, LOTOS, Petri nets, state transition diagrams) • 4 + formal proof to establish conformance to software requirements specification.

  26. EN 50128: Software Development and Implementation Requirements

  27. Common SIL Myths • “What are the safety requirements for the system?” • “It needs to be SIL4”

  28. Common SIL Myths • “We’ve identified a new hazard, so there are new safety requirements” • “That’s ok, the software’s SIL4 so it won’t do that”

  29. Common SIL Myths • “This software is SIL0 so it’s unsafe” • “The operating system is SIL3 so it must be safe”

  30. What Is a SIL? • Very similar to stars for hotel ratings!

  31. Safety Requirements and Sils • Safety requirements define what we have to demonstrate • SILs define how thorough the demonstration needs to be • SILs apply to specific requirements • Applying a consistent process to a software package is a sensible management approach, but may have little direct relation to safety

  32. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/RTOS etc. • Validation, verification and testing (VVT) • Accumulation of evidence – safety case

  33. Lifecycle Definition • Some standards are lifecycle independent. • Others are explicit that the V-Model is assumed. • QMS will define deliverables: • >ISO9000-3 • There are Version and Configuration Management issues. The V Model Req’ts Spec Spec Test HL Design Test Detailed Design Test Code

  34. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/RTOS etc. • Validation, verification and testing (VVT) • Accumulation of evidence – safety case more later

  35. Safety-related Software Techniques • Common aspects: • Hazard/risk analysis • Safety integrity levels • Lifecycle definition • Formal methods for requirements and design • Modelling, for various purposes • Choice of language/rtos etc • Validation, verification and testing (VVT) • Accumulation of evidence – safety case

  36. Evidence and the Safety Case • A successful safety assessment depends on the inspection of evidence. Example: • Config. Management plan (including environment) • Software verification plan • Software quality assurance plan • Standards for design/coding • Specifications for requirements/design/tests • Software verification results • Software configuration index • Traceability matrix

  37. Resources • Ainsworth, Mike; Estaughffe, Katherine; Simpson, Alan. Safety Cases for Software Intensive Systems. In Aspects of Safety Management, Redmill & Anderson (Eds). Springer 2001. ISBN 1-85233-411-8

  38. Programme • Introduction • What is High Integrity Software? • Reliable Programming in Standard Languages • Coffee • Standards Overview • DO178B and the Lockheed C130J • Lunch • Def Stan 00-55 and SHOLIS • ITSEC, Common Criteria and Mondex • Tea • Compiler and Run-time Issues • Conclusions

  39. Lockheed C130J

  40. A new propulsion system with 29% more thrust and 15% better fuel efficiency. • An all composite six-blade propeller system which is lighter in weight and has fewer moving parts than previous Hercules propellers. • Advanced avionics technology includes Liquid Crystal Display (LCD) instrument readouts for aircraft flight control, operating systems, and navigation. • Two mission computers and two backup bus interface units provide dual redundancy for the Hercules' systems. These computers also provide for an integrated diagnostics system to advise the crew of the status of the aircraft's various systems. C130J Key Features

  41. C130J Software Certification DO-178B/FAA Mission computer Civil C130J RAF lead customer UK MoD IV&V programme Military comparisons

More Related