Formal Analysis of Software Architecture Models - …8) Formal Analysis of... · – Components...
Transcript of Formal Analysis of Software Architecture Models - …8) Formal Analysis of... · – Components...
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
Formal Analysis of Software Architecture Models AFRL Safe & Secure Systems & Software Symposium (S5) June 3, 2009 Darren Cofer
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• Vision • Problem • Current approaches • Research directions
Outline
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• Build on success of model checking for software components
• Extend to system level via software architecture models • Goal: Early detection/elimination of bugs
– cheaper to fix in design vs. integration • Hardware analogy…
Vision: “Integrate, then Build”
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
Software architecture model
• Architecture defines interactions between components – Physical interconnect may be abstract or concrete (e.g., bus) – Includes fault-tolerance mechanisms such as redundancy – Actual component behavior abstracted or not specified
• Usually defines interactions with external environment – Sensors – Actuators
• May also specify behavior of execution platform – Scheduling – Software/hardware allocation – Synchrony/asynchrony
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• SysML
• AADL
Modeling languages
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• Complexity – Component models are already large – Naïve approaches won’t scale
• Asynchrony – Aircraft systems are typically distributed – Locally synchronous but globally asynchronous – Asynchronous interactions are more complex to analyze
• interleaving, execution order, variable time delays
• Behavioral interface specification – Components interface to each other and architectural elements
• power, bus, discretes, cabinet – ICDs typically specify signals, messages/formats, connectors – Need to specify component behaviors that characterize their
interactions with the rest of the system
Barriers to analysis of architecture models
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• To analyze system-level properties, we generally need to know about both the architecture and the components – How should we include component behaviors in a formal
analysis of the system model? • Flattening
– Retain exact description of component behavior – Yields one big, hairy model of the whole system
• Abstraction – Replace component with simplified model – This is usually some type of state machine model
Problem
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• AADL – Verimag: aadl2sync
• flattening, quasi-synchronous – SPICES ITEA project: aadl2bip
• abstraction via Behavior annex – TOPCASED => FIACRE => TINA – UIUC: MOMENT2-AADL => Maude
• SysML – state machines – activity diagrams => Petri nets
• others
Current approaches
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
setDesiredSpeedboolean
2
modeuint32
1
setEvent
safetyCondition
cancel
brakePedal
carGear
carSpeed
validinputs
safetyCondition
resumeEvent
mode _logic
onOff
decel
set
accel
resume
safetyCondition
mode
setDesiredSpeed
Delay = 1 Sec
Delay = 1 Sec
validInputsboolean
true_false
8
carSpeeddouble
miles_per_hour
7
carGearuint32
enumerated
6
brakePedalbooleanon_off
5
cancelboolean
true_false
4
accelResumebooleanon_off
3
decelSetbooleanon_off
2
onOffbooleanon_off
1
cruiseThrottledouble
miles_per_hour
1
throttleDelta%_per_step
thottleDelta%_per_second
1.00
isCruiseActive ?
<Init = 0.0>
z
1
StepsPerSec
<U=10.0><L=-10.0>
<U=100.0><L=0.0>
NO THROTTLEdouble
0.0
doublecarSpeed
doublemiles_per_hour
3
desiredSpeeddouble
miles_per_hour
2
modeuint32
enumerated
1
desiredSpeeddouble
miles_per_hour
3
cruiseThrottledouble
percentage
2
modeuint32enumerated
1
[carSpeed ]
[carSpeed ]
SetThrottle
mode
desiredSpeed
carSpeed
cruiseThrottle
SetDesiredSpeed
mode
carSpeed
setDesiredSpeed
desiredSpeed
ModeLogic
onOff
decelSet
accelResume
cancel
brakePedal
carGear
carSpeed
validInputs
mode
setDesiredSpeed
Goto[carSpeed ]
validInputsboolean
true_false
8
carSpeeddouble
miles_per_hour
7
carGearuint32
enumerated
6
brakePedalbooleanon_off
5
cancelboolean
true_false
4
accelResumebooleanon_off
3
decelSetbooleanon_off
2
onOffbooleanon_off
1
cruiseThrottledouble
percentage
3
desiredSpeeddouble
miles_per_hour
2
modeuint32
enumerated
1
isBrakePressed?[brakePosition ]
CruiseController
onOff
decelSet
accelResume
cancel
brakePedal
carGear
carSpeed
validInputs
mode
cruiseThrottle
desiredSpeed
validInputsboolean
true_false
7
carSpeeddouble
miles_per_hour
6
carGearuint32
enumerated
5
cancelboolean
true_false
4
accelResumeboolean
true_false
3
decelSetboolean
true_false
2
onOffboolean
true_false
1
Composition of Subsystems – Tends to be simple – Assume/guarantee reasoning – Well suited for theorem
proving
Typical Model-Based Design – Models are organized in a
hierarchy several (many) levels deep
– Most of the complexity is in the leaf models
– Leaf models can often be verified through model checking
A different approach…
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
• Large Complex Model – 166 Simulink subsystems – 2000+ basic Simulink
blocks – Huge reachable state space – This is bad
• Completely Functional – No internal state – This is good
Control EffectorArrangement
Spoilers (L&R)
V-Tail Rudders (L&R)
Flaps (L&R)
Effector Blender Model
1
Effector Blender
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
WPAFB 08-5183 RBO-08685 8/20/2008
target dynamics
B matrix
previous commands
current surface positions
failure status
preferred surface
positions
Can we use an approach based on compositional reasoning to handle the complexity of this system?
d
p
Wcmdc
ccmd
cmdcWpcmd
cmd
GuBminmn
GuBmn
GuBmin
mn
−
>=
=
=−
<
−
δ
δ
δδδ
δ
If
If
to subject If
for Solve
1
Condition B Matrix By Removing Effectors• on limits• with low effectiveness
=
363534333231
262524232221
161514131211
bbbbbbbbbbbbbbbbbb
Bc
cB availδcB availδ
B
availδ
Check Position & Rate Limits On All Effectors: Limited
?
Scale Solution To Preserve DirectionRemove Limited
Effectors:
#effectors = #effectors - 1
Iterative Solution Loop
cmdδcmdδ
scaleδscaleδ
limδ
limδ
Y
N
pδ
Gu
pW
dW
minδ maxδ
cmdδ limδ
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
Compositional reasoning
External assumptions :P1: In1 < 10P2: In2 > 0P3: In2 < In1
Lemma_A:P2 => Q1
Lemma _B:P1 ^ Q1 => Q2
Q1: Out _A > 0Q2: Out _B < 5
External guarantees :Q2
Lemma_A1:P2 ^ P3 => Q1
Out 11
Subsystem _B
In_B1
In_B2Out_B
Subsystem _A
In_A1
In_A2Out_A
In22
In11
Hybrid verification process • Decompose system property into a set of lemmas corresponding to individual
subsystems • Proof = argument that lemmas imply truth of property + demonstration that lemmas
are true for subsystems • Lemmas are verified by model checker
Counterexample: Q1 FALSE when In2 ≥ In1
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
CerTA FCS: Effector Blender analysis
• (dis-)Proof carried out iteratively, starting with top-level obligations imposed by properties, and propagating through the architecture
• Started with cne_LimitAndScaleVector subsytem, which performs command limiting function
• Lemmas developed and propagated outward until satisfied or counterexamples found
EffectorBlenderEffectorBlender
PreProcessing GenericEffectorBlender PostProcessing
PreProcessingInputs
PreProcessingStateflow
umin umax
NoDelta
cneg_CheckEffectiveness
cneg_Solve
cnegs_Select
cnegs_WhileIterator
cnegsws_LimitAndScale
cne_LimitAndScaleVector
Properties • umin ≤ u ≤ umax • If no failure, surface
commands never exceed static limits • If failure, surface
commands stay within +/- current position • Surface commands
never exceed rate limits
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
Formal analysis of architecture models
• Most current approaches are based on AADL Behavior Annex or SysML State Machines
• This is a useful abstraction for some classes of behaviors… • …but it is not general and does not fit well with model-based
development process for software components • We want an approach that builds on the current success of model
checking SW components • Idea: Follow same approach as the compositional reasoning
example – Property language to define assumptions/guarantees, requirements,
environmental constraints – Decompose requirements and allocate to components and interactions – Verify properties at “leaf nodes” by model checking – May need to generate test cases to verify some properties – Reason about results at system level – May use a combination of theorem proving and model checking
© Copyright 2009 Rockwell Collins, Inc. All right reserved.
Research directions
• Expand domain: architectural analysis – Build on successful analysis of SW at component level – Handle mixed synchronous/asynchronous systems – Tooling to automate lemma generation/propagation – Combination of theorem proving and model checking
• Property-based verification – Common specification language for properties, constraints,
assumptions – Properties drive testing and analysis – Develop assurance arguments to combine evidence and
demonstrate complete coverage • Architectural patterns
– Reusable design patterns that have proven properties – Ex: PALS (for async bounded delay networks), redundancy mgt
• Expand scope of analysis tools – Improvements in decision procedures allow analysis of larger
classes of systems