Verification of Hierarchical Component-Based Designs in FRESCO Tom 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-Time Software 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 a z b

Atomic Components Atomic discrete component Atomic continuous component ab xy y’ = f(x, y) ab xy y = f(x, y).

Operations: Parallel Composition synchronous conjunction of component behaviors same entry locations one component may preempt another (determines exit location) aa || cbbc 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 a g1g2 bc 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 abbcca

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 x left:=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) caab refines abbc + \ b = ca because

Example: A Simple Robot Motor Controller || Motor + || FollowLead + || Motor ++ StraightTurnMoveWait

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 C B2A2 C B2A2 C B1A2 C B2A2 C B1A1 C

Assume-Guarantee: Example Consider reimplementation of robot controller. Prove: C A [Control I A ]||C B [Control I B ]  C A [Control A ]||C B [Control B ] discharged by assume-guarantee: C A [Control I A ]||C B [Control B ]  C A [Control A ]||C B [Control B ] C A [Control A ]||C B [Control I B ]  C A [Control A ]||C B [Control B ] first premise rewritten as: Control I A ||Motor A ||Control B ||Motor B  Control A ||Motor A ||Control B ||Motor B discharged by compositional reasoning: Control I A ||Control B  Control A ||Control B rewritten as: (Control I A + Follow A )\e L \e F ||Control B  (Control A + Follow A )\e L \e F ||Control B

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