Architectural Abstractions for Hybrid Programs

1

Architectural Abstractionsfor Hybrid Programs

Ivan RuchkinBradley Schmerl

David Garlan

18th International Symposium on Component-Based Software Engineering

Montreal, CanadaMay 5, 2015

2

Cyber-Physical Systems

● Cyber-physical systems (CPS) are software systems interacting with complex physical world.

● Many cyber-physical systems are safety critical.

Q: How to effectively design and verify CPS software?

Image credit: traxxas.com, latimes.com, flight.org, expo21xx.com

3

Cyber-Physical Systems

● Cyber-physical systems (CPS) are software systems interacting with complex physical world.

● Many cyber-physical systems are safety critical.

Q: How to effectively design and verify CPS software?

A: Model-driven engineering!

Image credit: traxxas.com, latimes.com, flight.org, expo21xx.com

4

Model-driven engineering for CPS

Software engineering models:

● UML, statecharts, ADLs, process algebras

● Pros: information hiding, composition and reuse

● Cons: limited treatment of continuous processes

5






Hybrid system models:

● Hybrid automata, hybrid programs

● Pros: strong formal foundations for explicit continuity

● Cons: limited support for information hiding, higher-level representation

6






Hybrid system models:

● Hybrid automata, hybrid programs

● Pros: strong formal foundations for explicit continuity

● Cons: limited support for information hiding, higher-level representation

Goal: bring the component-based engineering benefits (maintainability, analysis) to hybrid programs

7

Outline

● Hybrid programs and modularity

● Architectural abstractions for hybrid programs

● Evaluation in robotic collision avoidance

8

Outline




9

Background: hybrid programs (HPs) [1]

Robot ::== (a := *; ? b <= a <= A; { v' = a, x' = v, v >= 0 }

)* x

v

a

[1] A. Platzer. Logical Analysis of Hybrid Systems: Proving Theorems for Complex Dynamics. 2010.

Image credit: icon101.com

10

Background: hybrid programs (HPs) [1]

● A; B – execute A, then B

● A* - execute A zero or more times

● ?P – test P; continue if A holds, abort otherwise

● { x1' := F1 … xn' := Fn & P } – evolve along differential equations within region P

● A U B – execute either A or B

● x := S – assign S to variable x

● x := * - assign an arbitraryvalue to variable x

Robot ::== (a := *; ? b <= a <= A; { v' = a, x' = v, v >= 0 }

)* x

v

a


Image credit: icon101.com

11

Background: differential dynamic logic (DDL) [1]


● Example: “robot never drives back”C ∀ x > C → [Robot] (x > C)

12

Background: differential dynamic logic (DDL) [1]

F ::== F1 ∨ F2 | ¬F | A ~ B | x F | [A]F | <A>F∀

First-order logic

● Example: “robot never drives back”C ∀ x > C → [Robot] (x > C)

● Logical statements over hybrid programs:

F holds after all possibleexecutions of A

F holds after at least one execution of A

● Can be verified semi-automatically with a theorem prover


13

HP modeling

● HP modeling addresses a variety of concerns:

– Tactic: avoid obstacles / pass intersection / arrive at a goal

– Trajectory: grid / lines / arcs / spirals

– Sensing: precise / bounded error / bounded delay

– Desired property: passive safety / passive friendly safety / liveness

14

HP modeling

● HP modeling addresses a variety of concerns:

– Tactic: avoid obstacles / pass intersection / arrive at a goal

– Trajectory: grid / lines / arcs / spirals

– Sensing: precise / bounded error / bounded delay

– Desired property: passive safety / passive friendly safety / liveness

● Multiple independent model variants emerge.

– Each variant addresses a point in variation space

– Pros: incremental complexity, smaller verification burden

Variant 1

Variant 2

Variant 3

System

15

16

Robot's trajectory: arcs

17


Robot-obstacle interaction

18


Fragmentation of concerns and components.

● Difficult to derive and reuse variants

● No restriction of information flow, implicit “errors”

Robot-obstacle interaction

19

Outline




20

Architecture for HP

● Target: represent HPs with architectural constructs to enable:

– Composition and analysis

– Derivation and reuse

● Strategy:

– Once: Give architectural concepts meaning in HP

– For each system: Model HP at architectural level (yellow)

– For each variant: Generate plain HP (green)

HPPart Architectural model*..* 1..1

21

HP Actors

Each actor contains:

● State: variables, constants, and constraints.

● Ports: variables visible to other actors.

● Ctrl: a HP to execute over State U Ports.

● Phys: set of differential equations over State U Ports.

HP

HPA 1HPA 2

HP actor (HPA) – a component of a hybrid program.

22

Composers

Steps:

● {HPA} → HPA → HP

Example: sequential composer

SeqC(a,b)::== (a.Ctrl ; b.Ctrl; {a.Phys, b.Phys})*

HPHPA 1

HPA 2

composeComposer

Composer – an algorithm to aggregate actors into a HP.

23

HP Connectors

Contains:

● Set of roles (e.g., sensing and sensed roles)

● Role-to-port attachment mapping

● Transform: an algorithm to generate a HP without the connector

HPA 1 HPA 2transform

HPA 3 HPA 4

HP Connector (HPC) – a representation of actor interaction.

24

Immediate precise sensing conn. (IPSC)

xr,b

v

xo

xs

25


?|xr – xs| > v2/b

Robotxr,v,b

Obstaclexs

xoIPSC

xr,b

v

xo

xs

26


?|xr – xs| > v2/b

Robotxr,v,b

Obstaclexs

xo

?|xr – xo| > v2/b

Robotxr,v,b Obstacle

IPSC.Transform

IPSC

xr,b

v

xo

xs

27

HP Architectural View

● Contains: {HPA}, {HPC}, Composer

● Represented with a single architectural model

● Amenable to information flow analysis:

– Is information hiding violated?

HPA 1 HPA 2generate

Composer

HP

View

HPC

HP View – an architectural representation of a HP.

28

Architectural Types

Example: types of robot physics: grid / line / arc / spiral

HPA 1 HPA 2

generateComposer

HP

View

HPC

Type B

Type AType C

Architectural type – a partially specified HPA, HPC, or Composer.

29

Architectural DDL Formula

Architectural DDL Formula (ADDL) – a DDL formula over HP views.

Example: “the robot behaves in a way that gives the obstacle an opportunity to stop.”

30

Architectural DDL Formula

Init → [HP View 1] (RobotFar (ObstFar → <HP View 2> Safe))∧

HP View 1: - robot is moving- obstacle (abstract) is moving

HP View 2 :- robot is stopped- obstacle (concrete) is given a chance to stop

Architectural DDL Formula (ADDL) – a DDL formula over HP views.

Example: “the robot behaves in a way that gives the obstacle an opportunity to stop.”

31

HP 1

HP 2

System

Type A Architectural View 1*..* *..*

Architectural View 2

Architectural View 3

ADDL 2

ADDL 1

Design, Reuse Component Analysis

Model-driven engineering with architectural HP

Verification

1..1

Type B

32

Outline




33

Evaluation

● Method: “architecturalized” 15 model variants in an existing case study [2]; observed extent of reuse and errors found by analysis.

[2] S. Mitsch, K. Ghorbal, and A. Platzer. On provably safe obstacle avoidance for autonomous robotic ground vehicles. 2013.

34

Evaluation

● Method: “architecturalized” 15 model variants in an existing case study [2]; observed extent of reuse and errors found by analysis.

● Reuse results:

– Sensing connectors: average 2 connectors per variant.

– Physics types were widely used:

Type Number of times used

Robot 1D line movement 3

Robot 2D grid movement 3

Robot 2D arc movement 5

Obstacle static 7

Obstacle abstract line movement 6

[2] S. Mitsch, K. Ghorbal, and A. Platzer. On provably safe obstacle avoidance for autonomous robotic ground vehicles. 2013.

35

Composition analysis results

● Lack of component separation: robot assigns obstacle's position variable (intent – sensing).Threats: safety, implementability.

● Conflation of variables within HPs: sensing intersection's position vs. obstacle's position.Threats: safety, maintainability.

● Conflation of variables across HPs: different meanings of a variable – direction vs. speed.Threats: safety, implementability, maintainability.

36

Conclusion

● CPS require expressive and maintainable models.

● Hybrid programs are expressive, but have limited modularity.

● Architectural abstractions for HPs improve maintainability and detect implicit modeling errors.

39

Variable and constant declaration

Initial conditions and assumptions

Obstacle control

Robot control

Dynamics (both robot and obstacle)

Desired property

40

Intersection tactic

x

v

a, xr

y

vo

ao

yo

xint

, yint

yo,v

o,a

o ?

Image credit: pxleyes.com

41

Architecture-Based Model Integration

ControlModel

Base CPS Architecture

HardwareModel

Arch. View X Arch. View Y

ControlArch.

HardwareArch.

model-to-architectural-view relations

architectural -view-to-base-arch. relations

MxXR

MyYR

XBAR

YBAR

Bhave et al., View Consistency in Architectures for Cyber-Physical Systems, ICCPS 2011.

42

Why not PL methods?

● Could have introduced language constructs for modules, inheritance, …, but:

● “We don't want to complicate the language!”

– Thrust to simplify and verify the prover core.● Does not support multi-model integration and

consistency checking (broader context of this work)

– Unlike architectural models

43

How is it different from (failed?) AOP?

● I modularize based on interacting entities, not aspects.

● I work from global towards local, separating subprograms

● I do not have quantification (join points): connectors and composers intervene at defined points.

● I do have obliviousness: actors aren't aware of what connector transformation is applied to them.

Documents

Architectural Abstractions for Hybrid Programs