Contract based design of avionics systems

Contract based design of avionics systems
Erik Herzog, Ph.D., SAAB Technical Fellow
[email protected]
SAAB Aeronautics
Presentation outline
Application of
SPEEDS
SPEEDS
Case
Lessons learned
Way ahead
Sweden & SAAB SE reality
What is SAAB?
What is a SAAB?
Sweden and the Swedes
What about the Swedes?
(some) Good Engineers
Consensus seeking
Conflict avoidance
Not very talkative
We are experts in creating
unresolved issues and
ambiguities!
The SE state of practise as SAAB
A tradition in waterfall-development
A lot of emphasis is placed on requirements
Requirements capture and traceability
We tend to prioritise documentation of requirements over design
The result is documentation (used for communication) which does
not explicitly convey design
Each SE has to create a local mental picture of the design prior
to implementation
Needless to say we spend a lot of time fixing problems found late in
the integration and verification phase
SAAB SE Reality
Substantial dynamics in subsystem properties throughout development
Extensive communication required between systems
and in System/Subsystem relationships
System Properties
Weight
A system will be characterised by a set of
properties
Some will be mandated and stable
Some mandated but unstable
Some not mandated but set early in the
design process
Some not mandated and set late in the
process
Cost
Behaviour
Question: How can we make sure that the complete set of relevant system
properties are identified and managed?
The SPEEDS project
EU 6th Framework Project in
Embedded Systems Development
May 1, 2006 – March 31st,
2010
SAAB’s role is mainly in
Identifying user requirements
Execution of validation projects
www.speeds.eu.com
SPEEDS technology overview
Focus on formalism, interfaces and requirements,
SysML provides an excellent base
Define
The Component (Component Based Engineering)
Requirements (Promises) what the component under development will provide
to the environement
Assumptions made on the environment that must hold in order to fulfill the
promises
Formalise Assumptions and Promises (where required)
Integrate
Form and Evaluate Contracts in order to expose integration problems
Simulate
Hosted simulation
Verify
Apply formal verification methods on contract statements
Assumptions, Promises & Contracts
C1
sensor reading
latency < 2 ms
P11
A11
A21
Quality factor > 0,7
95% of time
Quality factor > 0,8
A12
K1
K2
P12
A21
C2
P21
The Case
Integration of a podded subsystem onto the Gripen aircraft
Pod power supply
Pod cooling
Pod control
Air
Power
Signal inf
Model samples
«block»
Reconnaissance function
1 itsSU_MSS:SU MSS
SPKData:
1
1
MIL_STD_1553B
1 itsSPK39:SPK39
SPKDataMSS:
DataMSS:
MSSData:
SPKDataWES:
DataWES:
DataWES:
«blo ck»
Reconnaissance function
itsSU_WES:SU WES
1
1 itsSU_WES:SU WES
SPKData:
1 itsSU_GES:SU GES
itsSU_HMI:SU HMI
Coll ingAirValveStatus:
1 itsSU_TDP:SU TDP
BusTrafficStatus:
PowerData:
PodConf:
StatusMSS:
HMIData:
PowerStatus:
PowerStatusSPK:
ACTime:
ManEventCreated:
BusTrafficStatus:
WESData:
HMIData:
GESData:
1
i tsSU_MSS:SU MSS
PowerStatus:
1 itsSU_CDL:SU CDL
DestData:
1 itsSU_TAC:SU TAC
TDPData:
DestData:
CDLData:
TACData:
PFDData:
MDMData:
1 itsSU_PFD:SU PFD
FlightData:
LogReport:
Missi onIdentity:
Missi onDataFile:
TestResul t:
1 itsSU_MDM:SU MDM
DestData:
MissionData:
LogReportSPK:
1 itsSU_DSR:SU DSR
MissionDataFileSPK:
TestResul tMSS:
1 i tsSU_RTE:SU RTE
Missi onData:
1 i tsSU_TEM:SU TEM
Adding assumptions and promises
«block»
Reconnaissance function
1 itsSU_MSS:SU MSS
SPKData:
1
MIL_STD_1553B
1 itsSPK39:SPK39
SPKDataMSS:
DataMSS:
MSSData:
SPKDataWES:
DataWES:
DataWES:
«blo ck»
Reconnaissance function
1
1 itsSU_WES:SU WES
1
itsSU_HMI:SU HMI
itsSU_WES:SU WES
SPKData:
1 itsSU_GES:SU GES
Coll ingAirValveStatus:
1 itsSU_TDP:SU TDP
BusTrafficStatus:
PowerData:
PodConf:
StatusMSS:
HMIData:
PowerStatus:
PowerStatusSPK:
DestData:
WESData:
HMIData:
GESData:
1
i tsSU_MSS:SU MSS
PowerStatus:
1 itsSU_CDL:SU CDL
ACTime:
ManEventCreated:
BusTrafficStatus:
1 itsSU_TAC:SU TAC
TDPData:
DestData:
CDLData:
TACData:
PFDData:
MDMData:
1 itsSU_PFD:SU PFD
FlightData:
LogReport:
Missi onDataFile:
TestResul t:
Missi onIdentity:
1 itsSU_MDM:SU MDM
DestData:
MissionData:
LogReportSPK:
1 itsSU_DSR:SU DSR
MissionDataFileSPK:
TestResul tMSS:
1 i tsSU_RTE:SU RTE
Missi onData:
1 i tsSU_TEM:SU TEM
Lessons learned
Natural for engineers to capture assumptions – once the dedicated placeholder is
available
Capturing assumptions (even without contracts) improve communication between
engineers
Traditionally we have a poor track record in capturing the assumptions made
during design
Additional focus on system interfaces
Encourges working on requirements in parallel with design
Allow for engineers to proceed with design instead of waiting for guiding information to
be made available
Results in richer specifications
Focus is on what is important for stakeholders
Expected to be of high value over time
Decreases the distance between requirements and design
Easy to locate impact of updates made
Easy to record status of each contract
What about tool integration, formal methods and simulation?
The case we have worked on is to a large extent a legacy system
built using propritary languages
Difficult to insert new analysis tools in the loop
Costly to take assertions from natural to formal language
We are not sure we understand what we have asserted
formally
And not sure if it is what we really want to assert
Exploitation outlook
SysML intro
A/P editor
Informal contracts
HRC support
Hosted simulation
Formal contracts & analyses
2010
2011
2012
Way ahead
Further introduction of the method within the SAAB group
Method and tool fine tuning
Need to establish a proper integration between DOORS and the
SysML modelling tools
Improve the support of capturing contracts within SysML
Include support for contracts in Activity daigrams
Potential for introduction in SysML version 2
Potential: Assumptions/Promises in activity diagrams
su GES:SU GES
su WES:SU WES
su HMI:SU HMI
su MSS:SU MSS
PowerAllowedOn
sendPowerS
tatus
PowerAllowedOn
AvailablePower
SPK39:SPK39
receivePowerS
tatus
AvailablePower
PowerOnOff
sendPowerOnOff
PowerOnOff
sendSPKI
dentified
Identified
receviveWESD
ata
Identified
AvailablePower
sendAvailable
Power
AvailablePower
[else]
[PowerOnOff = Off AND
PowerAllowedOnMSS = true AND
(AvailablePower = 2 or 5) AND
PowerAllowedOn = true AND
Identified = true AND
FMStatus = NoFailure]
receivePowerO
nReq
PowerOnReq
PowerOnReq
receivepowerR
eqOn
PowerReqOn
PowerReqOn
sendPowerOnOff
PowerOnOff
PowerOnOff
receivePower
Off
PowerOnOff
PowerOnOff
receivePowerOn
sendPower
OnReq
sendPower
ReqOn
receivePowerO
nOff
sendPowerOn
Off
[PowerOnOff = On]
PowerOn
sendPowerOn
PowerOn
receiveAvailableP
ower
Thank you for your attention
Questions?
Contact {erik.herzog, henric.andersson @saabgroup.com}