Industrial Avionics Working Group 18/04/07 The Relationship Between the Design and Safety Domains in IAWG Modular Certification Part 2: Completeness of DGRs

Industrial Avionics Working Group 18/04/07 DGR Completeness DGRs are initially established based on ‘engineering judgement’ of similar systems ‘Typical’ functionality and/or services provided by the design element Completeness in the initial set of guarantees is not a safety issue –If a guarantee is missing, the safety case cannot be composed and new additional guarantees will have to be identified Completeness of the set of dependencies for each guarantee IS key to the safety argument –If a dependency is missing, the system/software cannot fully assure delivery of the guarantee

Industrial Avionics Working Group 18/04/07 DGR Completeness Experience Parallel study – SIL 2 – used a combination of approaches –Manual analysis technique described earlier –Validation techniques used as evidence in the safety argument about completeness Argue that SPARK analysis would have identified any additional dependencies at code level Argue that system testing would have identified any un- documented requirement level dependencies

Industrial Avionics Working Group 18/04/07 DGR Completeness Additional Options Other techniques were considered, but may be modified to support such an argument: –SHARD analysis at the interfaces –Static Analysis tools, e.g. ‘Understand for Ada’ –Various testing methods, but typically too late in the programme –Non-functional properties analysis

Industrial Avionics Working Group 18/04/07 Standards View on Argument and Evidence From DEF STAN issue 3, types of argument: –Deductive, where the conclusion is implicit in the evidence used to support the argument. –Inductive, where the argument is firmly based on the evidence presented, but extrapolates beyond the available evidence. –Judgmental, where expert testimony, or appeal to custom and practice is necessary to support the conclusion. Level of confidence in the completeness of the set of dependencies will vary with assurance requirements

Industrial Avionics Working Group 18/04/07 Scale of Potential Techniques for Assuring Dependency Completeness Lower Integrity/ Assurance Higher Integrity/ Assurance Code Level Hazard Analysis Understand for Ada (Partially annotated) SPARK analysis + Understand for Ada Manual Requirements Analysis Increasing time/effortRisk of undeclared dependencies reduces (Fully annotated) SPARK analysis + Understand for Ada Formal Methods Non-functional dependencies via checklists/analysis SPARK: coverage is project-dependent, tool is high integrity Understand for Ada: full coverage, tool is low integrity

Industrial Avionics Working Group 18/04/07 Ongoing Work on DGRs Currently expressed in ‘natural language’ –Difficult to express them unambiguously –Work ongoing to develop a rigorous notation for expressing DGRs Currently a manual process to determine DGRs, using design information –Could be difficult for COTS components –Could be difficult to establish significant assurance for High Integrity systems –Work ongoing to look at automated ways of Validating DGRs for use in high integrity implementations Generating DGRs when only limited design information is available