Download - Incremental Certification

Industrial Avionics Working Group

13/09/06

Incremental Certification

Phil Williams – General Dynamics (UK) Ltd

Representing the Industrial Avionics Working Group (IAWG)


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


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


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


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


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


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


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


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”


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


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.


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


13/09/06

Arguing Separately About Process

Package4Package3Package2

Safety Requirements

Block 1

Arch Int

AL Int

MSL

OSL RTBP

App. 1

Package7Package6

Package5


Safety Requirements

Block 1 Product

Arch Int

AL Int

MSL Product

OSL Product RTBPOSL Process

MSL Process

Block 1 Process


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


13/09/06

Module View with Global Scope


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


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

Download - Incremental Certification

Top Related