Industrial Avionics Working Group 13/09/06 Incremental Certification Phil Williams – General Dynamics (UK) Ltd Representing the Industrial Avionics Working Group (IAWG)

Industrial Avionics Working Group 13/09/06 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

Industrial Avionics Working Group 13/09/06 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

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

Industrial Avionics Working Group 13/09/06 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

Industrial Avionics Working Group 13/09/06 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

Industrial Avionics Working Group 13/09/06 MSL OSL Application Layer (AL) RT BP Design ArchitectureSafety Case Architecture

Industrial Avionics Working Group 13/09/06 Safety Case Module Interface

Industrial Avionics Working Group 13/09/06 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”

Industrial Avionics Working Group 13/09/06 Linking Safety Case Modules MSL Module OSL Module Goal:MSL service MSL service is guaranteed MSL Goal:MSL service MSL service is guaranteed Goal:MSL Service MSL service is sufficiently assured traditional ‘away goal’ hard wired linkalternative ‘contract’ link

Industrial Avionics Working Group 13/09/06 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.

Industrial Avionics Working Group 13/09/06 IAWG Proposed Solutions Safety Case Contract Pattern

Industrial Avionics Working Group 13/09/06 Arguing Separately About Process

Industrial Avionics Working Group 13/09/06 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

Industrial Avionics Working Group 13/09/06 Module View with Global Scope

Industrial Avionics Working Group 13/09/06 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