Transcript Safety Case Composition Using Contracts Refinements based

Industrial Avionics Working Group
Run-Time Blue Print module
13/09/06
Industrial Avionics Working Group
RTBP: a distributable set of configuration data
Application Layer
(AL)
RTBP
OSL
MSL
(from plenary presentation)
13/09/06
Industrial Avionics Working Group
RTBP is a bit different from other modules.
•It is static data. The guarantees it provides relate to
properties of that data only.
•The software modules that interpret the data are
responsible for guaranteeing configuration of the system in
line with it.
– This is, on each stack, the GSM, OSL, MSL and device
drivers.
13/09/06
Industrial Avionics Working Group
Path of RTBP Data through a single stack.
Application Layer (AL)
Some RTBP Data passes
through, and some is
interpreted;
OS
OSL
•Blue Print Services
GSM
BP S
RTBP
•Generic System Manager
•Operating System
MSL
Core
•Module Support Layer Core
•Device Driver(s)
DD
13/09/06
Industrial Avionics Working Group
Dependencies between the Stack and RTBP
Each of the modules on each
stack is dependant on the
RTBP
Application Layer (AL)
A1
A2
•Blue Print Services
OS
OSL
GSM
BP S
•Generic System Manager
RTBP
•Operating System
•Module Support Layer Core
MSL
Core
DD
•Device Driver(s)
Plus (red lines) the applications that use the
system after it has been configurated are
dependent on the configuration being correct, so
on the RTBP data being correct.
That would be a lot of contracts!!!!
13/09/06
Industrial Avionics Working Group
More Optimal Approach – No contracts.
•
Rather than declare all these dependencies in the DGRs, we
a) analyse the DGRs in every module to identify them (and “remove” them
from the DGR).
b) Collect them into guarantees that need to be supported by the RTBP
module
c) Create checklists that will provide evidence that can be argued to
support the guarantees.
d) Discard the guarantees (actually keep for traceability)
e) Argue instead that the entire checklists are good and that they have
been applied.
13/09/06
Industrial Avionics Working Group
GSN Goals in RTBP module
•The RTBP is correct; i.e. the configuration matches the master
system configuration diagram (which was the red lines).
•The RTBP is valid; i.e. that it is implementable by the system (which
was all the black lines).
13/09/06
Industrial Avionics Working Group
End of Presentation
13/09/06
Industrial Avionics Working Group
Goal:
OC0_RTBP_Valid
The Hawk OCo Run Time
BluePrint for all stacks are
valid
Con: RTBP_Valid
A valid RTBP is one that
can be used by the SW
without causing
configuration errors.
1..n {s}
Con:
RTBP_Checklist_Instanc
e
The Validity checklist [IAWGAJT-406] is instantiated for each
Hawk stack instance identified in
[TBD_1]
Goal:
RTBP_Stack{S}_Valid
Validity Argument
The Run Time BluePrint for
stack {s} is valid
Strat: RTBP_Valid
Con:
RTBP_Checklists&Rules
Con: RTBP_Fault_Data
This is a transition issue. No Hawk
Fault data has been provided during
the modular safety case process,
when data is available the checklists
will need to be modified to address
fault data completeness and
consistency.
Argue validity by reference
to the expectations of the
Architecture components as
to form and content
Expectations of the architectural
components is collated in the form
of checklists and rules concerning
RTBP content
Goal: RTBP_Complete
Goal:
RTBP_Consistent
The RTBP stack {s} contains
all required types of data
The RTBP stack {s} data
is internally consistent
Con:
RTBP_Completeness
Completeness here means there
are no gaps in the RTBP data
[TBD 2] that would cause the
Arch to fail during configuration.
Strat: RTBP_Complete
Con: RTBP_Elements
A RTBP element is piece of
RTBP data that is made
available as a single entity to
satisfy a particular operation in
the configuration of a system.
Con:
RTBP_Validation_Checkl
ists
Checklist for each RTBP element
type as captured in the "DGR"
process for the Architecture
(OSL & MSL)
Strat:
RTBP_Consistent
Argument completeness by
showing that the collated
expectations of all SW
components for RTBP stack
{s} content are fulfilled
Argument consistency by
showing the RTBP stack
{s} content conforms to the
defined set of rules
1..n {e}
1..n {e}
Goal: RTBP_Element{e} Present
Goal:
RTBP_Element{e}_Consistent
Stack {s} Validity Checklist confirms that
all presence checks applicable for
element {e} type passed or provides a
justification for any checks which have
failed.
Stack {s} Validity Checklist confirms
that all consistency checks passed for
element {e} or provides a justification
for any checks which have failed.
Goal:
OC0_Checklist_Is_Sound
1..n {p}
A RTBP element is piece of
RTBP data that is made
available as a single entity to
satisfy a particular operation in
the configuration of a system.
Con:
RTBP_Validation_Rules
Validation rules for each element
type (including cross correlation) as
captured in the "DGR" process for
the Architecture (OSL & MSL)
RTBP_Consistency_Che
ck{c}
Goal:
RTBP_Present_Check{p}
The check {p} confirms that
element {e} is present or
provides a justification if failed.
1 ..n {c}
The checks listed in the checklist
are complete, consistent and
correct
Con: RTBP_Elements
Goal:
OC0_RTBP_Development_Process
The check {c} confirms that
element {e} is consistent or
provides a justification if failed.
The software development process used for
the Hawk MSC OC0_RTBP is adequate
OC0_RTBP-PROC-Top
Sol:
RTBP_Validity&Corr
ectness_Checklist_
Report
Hawk Validity &
Correctness
Checklist Report
[TBD]
13/09/06
Industrial Avionics Working Group
Con: RTBP_Correct
A correct RTBP is one that faithfully
represents the configurable aspects
of the system (within scope) when
compared to the expectation
expressed in the Hawk MSC OC0
System Design Document (TBD)
Correctness Argument
Con:
RTBP_Data_For_Arch_Com
ponents
Some verification of RTBP data is
required for configuration detail that
is private to the Architecture (such
as identification of Arch processes;
GLI communication VCs)
Con: Design_DataApplication_Processes
Design data for verification of
RTBP includes definition of the
SW processes and end-end
connectivity of data pathes
between application processes
Goal:
OC0_RTBP_Correctly_Repr
esents
The Hawk OC0 Run Time BluePrint
is a correct representation of the
system as designed
Con:
RTBP_Verification_Scope
Scope of RTBP verification argued
about here is limited to aspects of
the configuration that have been
identified by other safety case
modules
Strat:
RTBP_Correct
Argue by reference to
the realtionship between
design data and the
RTBP content
Con: Design_DataFault_Handling
Design data also includes
details of detectable faults
and the required action in the
event of failures
Goal:
RTBP_Verification
The RTBP has been verified
against design data
Con: RTBP_Critical_Element
Strat: RTBP_Correctness
Argue correctness by showing
that each critical element of the
configuration is correcly
represented in the RTBP by
reference to the system
specification.
Critical elements are those RTBP
elements that have been annotated as
safety related during the flow down of
safety requirements (Channels and
faults). Note that the Schedule table/
Processes are implicitly covered by the
channel element checks.
1..n {e}
Goal:
OC0_Checklist_Is_Sound
The checks listed in the checklist
are complete, consistent and
correct
Goal:
OC0_RTBP_Development_Process
The software development process used for
the Hawk MSC OC0_RTBP is adequate
OC0_RTBP-PROC-Top
Con:
RTBP_Verification_C
hecklists
Goal:
OC0_RTBP_Element{e}
Correct
RTBP Critical Element {e} is
correct compared to the system
specification
List of critical elements
identified in the RTBP [TBD3]
Strat: RTBP_Channel/
Fault_Types
A different argument should
be developed for the element
kind - a Channel Type
(onboard, offboard, half
channels) or Fault.
Only one checklist will be performed for
element {e} (i.e. Exclusive OR)
Con:
RTBP_Onboard_Che
cks
List of onboard checks
required for critical element
"virtual channel"
Goal: RTBP_Faults
Goal: RTBP_Half_Channel
Goal: RTBP_Onboard
Goal: RTBP_Offboard
Onboard Checklist confirms that
all checks passed for element
{e} or provides a justification for
any checks which have failed.
Offboard Checklist confirms that
all checks passed for element {e}
or provides a justification for any
checks which have failed.
Half Channel Checklist confirms that
all checks passed for element {e} or
provides a justification for any checks
which have failed.
Con:
RTBP_Offboard_Che
cks
List of offboard checks
required for critical element
"virtual channel"
Con:
RTBP_Half_Channel_
Checks
List of half channel checks
required for critical element
input/output "virtual channels"
Sol:
RTBP_Validity&Corr
ectness_Checklist_
Report
Hawk Validity &
Correctness
Checklist Report
[TBD]
Fault Checklist confirms that all
checks passed for element {e}
or provides a justification for
any checks which have failed.
Goal: Transition_Issue_3
No Hawk Fault data has been
provided. When data is
available checks will need to be
created to address correctness.
13/09/06
Industrial Avionics Working Group
Checklist Sample
Page Pass/Fail
Comment
Checker
Date
N
Area
n
1
LVC
1
2
LVC
3
Full Details of the Check
Summary of
Check
Each LVC in a configuration shall have a corresponding process in the
same configuration.
LVC with a
Process
2
Each LVC in a configuration shall have a corresponding mode, Tx or Rx.
LVC moded
LVC
3
Each LVC in a configuration shall be associated with one GVC in the
same configuration.
LVC connected
4
TC
1
Each TC in a configuration shall have a corresponding mode, Tx or Rx.
TC moded
5
TC
2
Each TC in a configuration shall have a corresponding hardware
interface.
TC to HW
6
TC
3
Each TC in a configuration shall be associated with one GVC in the
same configuration.
TC connected
7
GVC
1
Each GVC in a configuration shall be associated with either only one Tx
LVC or only one Rx TC in the same configuration.
A GVC input
exists
8
GVC
2
Each GVC in a configuration shall be associated with at least one Rx
LVC or Tx TC in the same configuration.
GVC output(s)
exist
9
GVC
3
All GVCs associated with both an Rx LVC and a Rx TC in the
configuration shall not be associated with any Tx TCs in the same
configuration.[1]
Inbound used
data is not
relayed externally
by the OS.
10
GVC
4
Each GVC shall have a meaningful description.
GVC Described
13
LVC
6
The LVC’s associated with a process shall be the same across all
configurations that contain a process with the same application in it.
LVC same for
Process
14
LVC
7
For all LVC’s associated with a process the mode (Tx ot RX) of an LVC
Mode same for
Pass/
Fail
Failure Details / Comments /
References
13/09/06