Download pdf - Exposing Architecture in Hybrid Programs

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




– Approach


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




– Approach


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




– Approach


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