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
£
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
MSLOSL
Application Layer (AL)
RTBP
Design Architecture Safety Case Architecture
Application3 ArgumentApplication2 Argument
Operating System Layer Argument
Module Support Layer Argument
Architecture Integration Argument
Application Integration Argument
RTBP Argument
Safety Requirements Argument
Application1 Argument
Industrial Avionics Working Group
13/09/06
Safety Case Module Interface
S afe ty C aseM odule Context
Defined
'Away'Goal
'Away'Context
Goals Supported
Goal to beSupported
EvidencePresented
'Away'Solution
'Away'Goal
ContextDefined
Industrial Avionics Working Group
13/09/06
Safety CaseModule Context
Defined
'Away'Goal
'Away'Context
Goals ‘Provided’ / Addressed
ContextDefined
‘Guarantees’
‘Dependencies’
Safety CaseModule Context
Defined
'Away'Goal
'Away'Context
Goals ‘Provided’ / Addressed
GoalsRequired
EvidencePresented
'Away'Solution
'Away'Goal
ContextDefined
‘Guarantees’
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 link
OSL Module
MSL Module
Contract Module
alternative ‘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
Strategy
Argument over all goals providing support
DecompJust
Argument is satified by decomposition over module A and (0..n) of instantiated module {P}
J
A: Goal Requiring Support
Goal 1 in Module A
Module A
Goal in Module {A}
Module {A}
{All inherited context for Goal Requiring Support
in Module {A}}
Inherited Context
Module {A}
{All inherited context for Goal Requiring Support
in Module {A}}
{All inherited context for Goal Requiring Support in Module {A}}
Inherited Context
Module {B}+
{All inherited context, assumptions, justifications, or other arguments which this claim is made in the context of, including lower-level
argument structure which reduces the scope or confidence in
satisfaction of this goal}
B: Providing Support
Argument providing support in module B
Module B
Goal providing support in Module {B}
1..n
Justification
Goal(s) providing support provide a valid solution for the goal requiring support given the inherited contexts on the goals
J
Industrial Avionics Working Group
13/09/06
Arguing Separately About Process
Package4Package3Package2
Safety Requirements
Block 1
Arch Int
AL Int
MSL
OSL RTBP
App. 1
Package7Package6
Package5
Package4Package3Package2
Safety Requirements
Block 1 Product
Arch Int
AL Int
MSL Product
OSL Product RTBPOSL Process
MSL Process
Block 1 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
Package4Package3Package2
Safety Requirements
Block 1
Arch Int
AL Int
MSL
OSL RTBP
App. 1
Safety Requirements
App. 1 Product
Arch Int
AL Int
MSL Product
OSL Product
RTBP
OSL Process
MSL Process
App. 1 Process
Block 1
OSL
MSL
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