70 likes | 157 Views
The Relationship Between the Design and Safety Domains in IAWG Modular Certification Part 2: Completeness of DGRs. DGR Completeness. DGRs are initially established based on ‘engineering judgement’ of similar systems ‘Typical’ functionality and/or services provided by the design element
E N D
The Relationship Between the Design and Safety Domains in IAWG Modular CertificationPart 2: Completeness of DGRs 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 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 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 18/04/07
Standards View on Argument and Evidence • From DEF STAN 00-56 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 18/04/07
Increasing time/effort Risk of undeclared dependencies reduces Scale of Potential Techniques for Assuring Dependency Completeness Lower Integrity/ Assurance Higher Integrity/ Assurance SPARK: coverage is project-dependent, tool is high integrity Understand for Ada: full coverage, tool is low integrity (Partially annotated)SPARK analysis + Understand for Ada (Fully annotated)SPARK analysis + Understand for Ada Code Level Hazard Analysis Manual Requirements Analysis Understand for Ada Formal Methods Non-functional dependencies via checklists/analysis 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 18/04/07