exposing architecture in hybrid programs
DESCRIPTION
The formalism of hybrid programs is a relatively recent development by Platzer et al. (CSD) that allows holistic reasoning about discrete and continuous behavior within the same model. This makes hybrid modeling and verification, supported by tools like KeYmaera, an attractive method for analyzing cyber-physical systems. However, hybrid programs do not operate architectural concepts, making it difficult to relate them between each other and other kinds of CPS models. My talk introduces architectural annotations for hybrid programs that allow engineers to express the otherwise implicit architectural knowledge. This presentation discusses annotation primitives and their interpretation.TRANSCRIPT
Exposing Architectures inHybrid Programs
Ivan Ruchkin
In collaboration with
Stefan Mitsch,
Jan-David Quesel,
Andre Platzer,
David Garlan,
and others
SSSGNovember 18, 2013
Outline
● Problem: hidden architectural knowledge
● Hybrid programs basics
● Architectural Annotations
– Approach
– Collision avoidance example
2
Outline
● Problem: hidden architectural knowledge
● Hybrid programs basics
● Architectural Annotations
– Approach
– Collision avoidance example
3
Deadlock model
Control model
Physical model
Hybrid model
4
CPS Modeling Ecosystem
?
??
Cyber-Physical System
Deadlock model
Control model
Physical model
Hybrid model
5
Architectural Approach to CPS Modeling
This presentation
Exposing Architecture
● Problem: implicit architectural structures and behavior in hybrid programs.
– Inconsistencies with other models.
– Missed opportunities for verification.
● Goal: create a means to expose architecture in hybrid programs.
● Benefits:
– System level: relate to other models, expose architectural inconsistencies, raise level of abstraction for design.
– Hybrid program level: generate templates, differentiate models, support verification (additional properties, refinement).
6
Outline
● Problem: hidden architectural knowledge
● Hybrid programs basics
● Architectural Annotations
– Approach
– Collision avoidance example
7
Hybrid Programs and Dynamic Logic
● Hybrid systems are systems that exhibit discrete and continuous behavior.
● Hybrid programs (HP) are models for hybrid systems.
8
HP-Robot:((?X; a:= A) ++ (a:=-b);{v' = a, x' = v, v >= 0}
)*
Accelerate
v' = ax' = vv >= 0
Brake
v' = ax ' = vv >= 0
a:= A
a:= -b
X
X
Hybrid Program Operations
● a := X deterministic assignment
● a := * non-deterministic assignment
● if (P) conditional branching
then X else Y
● X ++ Y non-deterministic choice
● X; Y sequential composition
● X* non-deterministic repetition
● {a' = X, b' = Y, … } continuous evolution9
Differential Dynamic Logic
● Consists of:
– FOL over real arithmetic (∃, ∀, ^, ∨, ¬, ⇒).
– Modalities over HP:
● [HP] P: after all runs of HP, P holds.
● <HP> P: exists at least one run of HP, after which P holds.
● Express properties over HP:
– E.g., (X ⇔ x < wall – 50) ⇒ [HP-Robot] (x < wall)
– Canonical form: Pre ⇒[HP] (Prop)
● Use a hybrid prover (KeYmaera) to prove properties.
● Summary: a convenient formal logic to express hybrid system models and their properties.
10
Outline
● Problem: hidden architectural knowledge
● Hybrid programs basics
● Architectural Annotations
– Approach
– Collision avoidance example
11
Hidden Architecture in Hybrid Programs
● What are the “components” of the system?
– E.g., a car and a wall.
● How do the “components” interact?
– E.g., sense each other or interact through forces.
● What assumptions do “components” make of each other and the environment?
– E.g., max speed of obstacles or immediate position sensing.
12
Exposing Architecture
13
Component: robot
Component: obstacle
Connector: robot senses obstacle immediately and precisely
Robot’s property: control algorithm
Obstacle’s property: control algorithm
Robot’s property: physics
Solution: annotations
Approach for Annotations
● For each model operator, unambiguously determine its architectural interpretation if any.
● Allow automatic generation of architectural descriptions for hybrid programs.
● Allow flexibility for the model designer to express architecture
● Redundancy is acceptable.
14
Example: robot collision avoidance
15
Robot Obstacle
• A robot and an obstacle move in a one-dimensional space.• The robot periodically senses the surrounding and may decide to accelerate or brake. • The robot knows the bounds and senses the obstacle’s location.• The obstacle is assumed to have maximum speed.
Safety property: robot does not collide with the obstacle or the bounds.
Example: model structure
16
Constants declarationsVariables declarationsPreconditions->[
(robot control; obstacle control; {differential equations})*
](Property)
Example: constants
17
\functions{ //a.k.a. constantsR b; /* minimum braking power */R A; /* maximum acceleration */R ep; /* time limit for control decisions */ R V; /* maximum obstacle velocity */R xbmin; /* minimum bound */R xbmax; /* maximum bound */
}
Example: constants
18
\functions{ //a.k.a. constants@component(robot) (R b; /* minimum braking power */R A; /* maximum acceleration */R ep; /* time limit for control decisions */ )
@component(obstacle) (R V; /* maximum obstacle velocity */)
@component(global) (R xbmin; /* minimum bound */R xbmax; /* maximum bound */)
}
Example: variables
19
\programVariables {R xr; /* robot position */R vr; /* robot velocity */R ar; /* robot acceleration */R or; /* robot orientation (1=in direction of space, -
1=opposite) */R xo; /* obstacle position */R vo; /* obstacle velocity */R oo; /* obstacle orientation */R t; /* time */
}
Example: variables
20
\programVariables {@component(robot) (R xr; /* robot position */R vr; /* robot velocity */R ar; /* robot acceleration */R or; /* robot orientation (1=in direction of space, -
1=opposite) */)@component(obstacle) (R xo; /* obstacle position */R vo; /* obstacle velocity */R oo; /* obstacle orientation */)@component(global) (R t; /* time */)
}
Example: robot control
21
\programVariables {// … preconditions: robot is inside the bounds, obstacle is far enough away, sensing period and other constants are positive-> \[ (
(ar := -b)/* braking is allowed */++ (
? pred1 /* far enough from maximum bound of navigation space */
& pred2 /* far enough from minimum bound of navigation space */
& pred3 ; /* far enough from the obstacle*/ar := *;?-b <= ar & ar <= A /*accelerate*/
)++ (?vr = 0; ar := 0; or := *; ?or^2 = 1); /* change
direction if stopped*/// ...
Example: robot control
22
\programVariables {// … preconditions: robot is inside the bounds, obstacle is far enough away, sensing period and other constants are positive-> \[ (
@control(robot)((ar := -b)/* braking is allowed */++ (
? pred1 /* far enough from maximum bound of navigation space */
& pred2 /* far enough from minimum bound of navigation space */& pred3 ; /* far enough from the obstacle; uses
obstacle’s position*/ar := *;?-b <= ar & ar <= A /*accelerate within limits*/
)++ (?vr = 0; ar := 0; or := *; ?or^2 = 1); /* change direction
if stopped*/)
//…
Example: continuous evolution
23
{xr' = or*vr, vr' = ar, xo' = oo*vo, t' = 1, /* evolution domain: */vr >= 0, t <= ep, vo >= 0
}
Example: continuous evolution
24
{@physics(robot) (
xr' = or*vr, vr' = ar,
)
@physics(obstacle)(xo' = oo*vo,
)
@physics(global)(t' = 1,
)/* evolution domain: */vr >= 0, t <= ep, vo >= 0
}
Architectural Annotations Summary
● @component(NAME) – introduces a component and associates variables and constants with it.
● @control(NAME) – designates a block of operators/equations as a component’s control block.
– Reads of other components’ variables are interpreted as sensing connectors. Assignments are actuation connectors.
● @physics(NAME) – designates a block of operators/equations as a component’s physics block.
– Reads and assignments of other components’ variables are interpreted as physical interaction connectors.
● global – designates variables/operators as shared variables describing the environment.
– Global variables can ready anywhere, but only be assigned in global physics or control blocks.
25
Behavior Categories
26
Discrete behavior: state changes, algorithms
Continuous behavior: physical processes, analog devices
Control behavior: component’s sensing, planning, and actuation
E.g., a decision to accelerate or brake
E.g., a PID controller
Physics: environment, “rules of the game”
E.g., an elastic collision E.g., movement or an inelastic collision
Architecturalannotations
Hybrid program
Further work
● Causality/directionality of physics connectors.
● Component refinement.
● Flexible syntax for multi-component interaction.
27
Summary
● Hybrid programs are convenient for specification and proving for hybrid systems.
– However, HPs do not expose architectural knowledge.
● Architectural annotations expose architecture to:
– Relate to other models of the system for consistency checking and simulation.
– Assist verification with extra information.
28
References
● A. Platzer, “Logic and Compositional Verification of Hybrid Systems,” in proceedings of LICS’12.
● S. Mitsch, A. Platzer, “Modeling and Verification of Hybrid Systems with Sphinx and KeYmaera,” in proceedings of HSCC’13.
● A. Rajhans, “Multi-Model Heterogeneous Verification of Cyber-Physical Systems,” PhD Thesis, Carnegie Mellon University, 2013.
● A. Bhave, “Multi-View Consistency in Architectures for Cyber-Physical Systems,” PhD Thesis, Carnegie Mellon University, 2011.
29