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


• Vision • Problem • Current approaches • Research directions

Outline


• 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”


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


• SysML

• AADL

Modeling languages


• 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


• 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


• 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


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


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


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…


• 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δ


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


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


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


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

formal analysis of software architecture models - …8) formal analysis of... · – components...

Documents