1 / 16

Incremental Certification

Incremental Certification. Phil Williams – General Dynamics (UK) Ltd Representing the Industrial Avionics Working Group (IAWG). History of IAWG. Initially formed in 1979 IAWG companies support a programme of joint activity led, through P110/ACA/EAP to Eurofighter Typhoon

kera
Download Presentation

Incremental Certification

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. Incremental Certification Phil Williams – General Dynamics (UK) Ltd Representing the Industrial Avionics Working Group (IAWG) 13/09/06

  2. History of IAWG • Initially formed in 1979 • IAWG companies support a programme of joint activity • led, through P110/ACA/EAP to Eurofighter Typhoon • Since then the Companies have continued to work together • Companies represented: • BAE SYSTEMS – (Military Air Solutions and E&IS) • General Dynamics United Kingdom Limited • Selex S&AS • Smiths Aerospace • Westland Helicopters 13/09/06

  3. Modular and Incremental Certification • One of current IAWG work areas is modular and incremental certification techniques for software. • Initially PV study by: • BAE SYSTEMS – (Military Air Solutions and E&IS) • General Dynamics United Kingdom Limited • Smiths Aerospace • Westland Helicopters • LCC study of benefits • Refinement of concepts to ensure credibility • Hawk AJT parallel study • supported by MoD/dstl • University of York • and involving QinetiQ as ISA • Application on industrial scale • Further refinement based on experience • Focus on Modular aspects 13/09/06

  4. Required Cost Relationships for Certification £ £ Change Size & Complexity Change Size & Complexity Cost of Re-Certification is Related to Change Size and Complexity Modular/Incremental Certification – why? Typical Current Cost Relationships for Certification Cost of Re-Certification is Related to System Size and Complexity 13/09/06

  5. Modular Certification – Basic Principles • Apply principles of Object Orientation to the safety case domain • High Cohesion • Low Coupling • Information Hiding • Well-defined interfaces • Align boundaries of safety case ‘modules’ with design boundaries to ‘contain’ change • A change to a design element should then only affect the corresponding safety case module, and not impact the entire safety argument 13/09/06

  6. Hawk Parallel Study • New Mission Computer is IMS using an ASAAC-compliant three-layer stack • Project are developing a traditional ‘monolithic’ safety case • MoD have funded a ‘hot’ research task • Developing a modular safety case for a new system in parallel to monolithic project safety case • Study aims: • Show that a modular safety case can be produced for a representatively sized project • Demonstrate that the proposed benefits can be achieved • Hoped that Hawk project will transition to modular safety case once the research is complete 13/09/06

  7. MSL Design Architecture Safety Case Architecture Application Layer (AL) RTBP OSL 13/09/06

  8. Safety Case Module Interface 13/09/06

  9. Linking Safety Case Modules • When developing the argument for a module, it may be necessary to make a claim to support the argument which is outside the scope of that module • E.g. The OSL argument may need to make a claim about the MSL behaviour to support it’s safety argument • “I know I need the argument supporting the claim to be made, but I’m not going to make it here” 13/09/06

  10. alternative ‘contract’ link Goal : MSL Service MSL service is sufficiently assured Goal : MSL service MSL service is guaranteed MSL OSL Module Goal : MSL service MSL service is guaranteed MSL Module Linking Safety Case Modules traditional ‘away goal’ hard wired link 13/09/06

  11. Linking Safety Case Modules with Contracts • The goal being supported links to the contract, rather than directly to the supporting claim • This provides a ‘buffer’ between the goals in the two modules • If the supporting module changes, only the contract needs to be altered (to identify the new supporting argument) and not the module requiring support • In this way the module is ‘isolated’ from the changes in the supporting module • IAWG have introduced notation extensions to allow the contract to be represented in GSN rather than previously proposed table. • The full expressiveness of GSN notation can be used to reason about the relationship between the goals, including consideration of context compatibility. 13/09/06

  12. IAWG Proposed Solutions • Safety Case Contract Pattern 13/09/06

  13. Arguing Separately About Process 13/09/06

  14. Argument Module Containment • Often unnecessary for all modules to be ‘visible’ to all others • Can aid clarity of module view to limit visibility of some modules • Module containment proposed by IAWG to address these issues The Basics • Every module created must have a containing module declared • Any module can only have one containing module • Containing module defines the scope of the module • A module is not available to be referenced from outside the containing module 13/09/06

  15. Module View with Global Scope 13/09/06

  16. Future Work Areas • Justification of contracts • Assurance • Context compatibility • When to use module containment • Containment of contract justification argument • Design Architecture vs. Safety Case Architecture optimisation • Including legacy architecture • Expanding approach to deal with other dependability properties • e.g. security • Maturing Incremental Certification concepts • Extending beyond software 13/09/06

More Related