Verification of Hierarchical Component-Based Designs
in FRESCOTom Henzinger, Marius Minea, Vinayak Prabhu
Context
• Overall Approach– use component hierarchy to limit complexity– design for verifiability
• Application Domain– primarily embedded systems
• Verification Goals– refinement checking– assume-guarantee reasoning
FRESCO: Formal Real-TimeSoftware Components
• formal: components are mathematical objects that can be analyzed
• real-time: behavior contains discrete and continuous executions over time
• components model software + hardware + environment
• Masaccio: high-level component view• Giotto: processes executing on real-time OS
Components in Masaccio
• Component = interface + behavior• Interface: specifies interaction with other components
– input and output variables + dependence relation– control locations + entry conditions
• Behavior: set of executions– entry (jump | flow)* (a, )– entry (jump | flow)* exit (a, , b)– components are deadlock-free
x
y az
b
Atomic Components
• Atomic discrete component
• Atomic continuous component
a bx y
y’ = f(x, y)
a bx y
y = f(x, y).
Operations: Parallel Composition
• synchronous conjunction of component behaviors• same entry locations• one component may preempt another (determines exit location)
a a||
cb b c
a
Operations: Serial Composition
• disjunction of component behaviors• entry conditions for common entry locations are disjoint• can represent different execution modes of the system
a +
cb
ag1 g2
b c
a g1 g2
Operations: Hiding and Renaming
• Location hiding– makes location internal to a component
– strings together component executions
– typically used with serial composition
• Location renaming• Variable hiding• Variable renaming
a b b c ca
Building Components
• All components can be built from atomic components using the six basic operations
• Example: control of a robot motor, with obstacle sensor
e xleft:=right:=T
obst
obst
left: bool
right: bool
obst: bool
Refinement of Components
• Generalizes trace inclusion• Component A refines component B iff:
– A and B have compatible interfaces(A may have more variables, stronger dependence relation)
– every behavior of A has as prefix a behavior of B (possibly ending in a different exit location)
ca a brefines
a b b c+ \ b =
cabecause
Example: A Simple Robot
MotorController
||
Motor
+||
FollowLead
+||
Motor+ +
Straight Turn Move Wait
Compositionality
• All components operations are compositional:
– A B A + C B + C– A B A || C B || C– A B A \ a B \ a– A B A [a := b] B [a := b]– A B A \ x B \ x– A B A [x := y] B [x := y]
Assume-Guarantee Reasoning
• C[A1,B2] C[A2,B2]
• C[A2,B1] C[A2,B2]
• C[A1,B1] C[A2,B2]
B2A1
CB2A2
C
B2A2
CB1A2
C
B2A2
CB1A1
C
Assume-Guarantee: Example
• Consider reimplementation of robot controller. Prove:CA[ControlIA]||CB[ControlIB]CA[ControlA]||CB[ControlB]
• discharged by assume-guarantee:CA[ControlIA]||CB[ControlB]CA[ControlA]||CB[ControlB]
CA[ControlA]||CB[ControlIB]CA[ControlA]||CB[ControlB]
• first premise rewritten as:ControlIA||MotorA||ControlB||MotorBControlA||MotorA||ControlB||MotorB
• discharged by compositional reasoning:ControlIA||ControlBControlA||ControlB
• rewritten as:
(ControlIA + FollowA)\eL\eF||ControlB (ControlA + FollowA)\eL\eF||ControlB
Assume-Guarantee: Importance
• Assume-guarantee rule for parallel composition: well studied
[Abadi & Lamport, Alur & Henzinger, McMillan]
• For serial composition: only recently [Alur & Grosu ‘00]
• In Masaccio: first combination of the two
• Exploits compositionality and hierarchy of formalism
Ongoing and Future Work
• Related:– rich application interfaces (real-time, QoS) (Luca)– time-triggered implementation of Giotto (Ben, Christoph)
• Compositionality and Assume-Guarantee (w. Vinayak)
– evaluation on examples
• Refinement of Timed Behavior– reduce to refinement of time-abstract quotients– use to show refinement between Masaccio and Giotto
• Exploiting Hierarchy in Verification– reachability analysis without flattening design
