Modern cyber-physical systems interact closely with continuous physical processes like kinematic movement. Software component frameworks do not provide an explicit way to represent or reason about these processes. Meanwhile, hybrid program models have been successful in proving critical properties of discrete-continuous systems. These programs deal with diverse aspects of a cyber-physical system such as controller decisions, component communication protocols, and mechanical dynamics, requiring several programs to address the variation. However, currently these aspects are often intertwined in mostly monolithic hybrid programs, which are difficult to understand, change, and organize. These issues can be addressed by component-based engineering, making hybrid modeling more practical. This paper lays the foundation for using architectural models to provide component-based benefits to developing hybrid pro- grams. We build formal architectural abstractions of hy- brid programs and formulas, enabling analysis of hybrid programs at the component level, reusing parts of hybrid programs, and automatic transformation from views into hybrid programs and formulas. Our approach is evaluated in the context of a robotic collision avoidance case study.

1. 1
Architectural Abstractions
for Hybrid Programs
Ivan Ruchkin
Bradley Schmerl
David Garlan
18th
International Symposium on
Component-Based Software Engineering
Montreal, Canada
May 5, 2015

2. 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. 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. 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. 5
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
Hybrid system models:
● Hybrid automata, hybrid
programs
● Pros: strong formal
foundations for explicit
continuity
● Cons: limited support for
information hiding, higher-
level representation

6. 6
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
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. 7
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collision avoidance

8. 8
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collision avoidance

9. 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. 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 arbitrary
value to variable x
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

11. 11
Background: differential dynamic logic (DDL) [1]
[1] A. Platzer. Logical Analysis of Hybrid Systems: Proving Theorems for Complex Dynamics. 2010.
● Example: “robot never drives back”
C∀ x > C → [Robot] (x > C)

12. 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 possible
executions of A
F holds after at least
one execution of A
● Can be verified semi-automatically with a
theorem prover
[1] A. Platzer. Logical Analysis of Hybrid Systems: Proving Theorems for Complex Dynamics. 2010.

13. 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. 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. 15

16. 16
Robot's trajectory: arcs

17. 17
Robot's trajectory: arcs
Robot-obstacle interaction

18. 18
Robot's trajectory: arcs
Fragmentation of concerns and
components.
● Difficult to derive and reuse
variants
● No restriction of information
flow, implicit “errors”
Robot-obstacle interaction

19. 19
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collision avoidance

20. 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. 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 1
HPA 2
HP actor (HPA) – a component of a hybrid program.

22. 22
Composers
Steps:
● {HPA} → HPA → HP
Example: sequential composer
SeqC(a,b)::== (a.Ctrl ; b.Ctrl; {a.Phys, b.Phys})*
HP
HPA 1
HPA 2
compose
Composer
Composer – an algorithm to aggregate actors into a HP.

23. 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 2
transform
HPA 3 HPA 4
HP Connector (HPC) – a representation of actor interaction.

24. 24
Immediate precise sensing conn. (IPSC)
xr
,b
v
xo
xs

25. 25
Immediate precise sensing conn. (IPSC)
?|xr – xs| > v2/b
Robot
xr
,v,b Obstacle
xs
xoIPSC
xr
,b
v
xo
xs

26. 26
Immediate precise sensing conn. (IPSC)
?|xr – xs| > v2/b
Robot
xr
,v,b Obstacle
xs
xo
?|xr – xo| > v2/b
Robot
xr
,v,b Obstacle
IPSC.Transform
IPSC
xr
,b
v
xo
xs

27. 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 2
generate
Composer
HP
View
HPC
HP View – an architectural representation of a HP.

28. 28
Architectural Types
Example: types of robot physics: grid / line / arc / spiral
HPA 1 HPA 2
generate
Composer
HP
View
HPC
Type B
Type A
Type C
Architectural type – a partially specified HPA, HPC, or Composer.

29. 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. 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. 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. 32
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collision avoidance

33. 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. 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. 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. 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.

37. 39
Variable and constant declaration
Initial conditions and assumptions
Obstacle control
Robot control
Dynamics (both robot and obstacle)
Desired property

38. 40
Intersection tactic
x
v
a, xr
y
vo
ao
yo
xint
, yint
yo
,vo
,ao
?
Image credit: pxleyes.com

39. 41
Architecture-Based Model Integration
Control
Model
Base CPS Architecture
Hardware
Model
Arch. View X Arch. View Y
Control
Arch.
Hardware
Arch.
model-to-architectural-view relations
architectural -view-to-base-arch. relations
Mx
XR My
YR
X
BAR
Y
BAR
Bhave et al., View Consistency in Architectures for Cyber-Physical Systems, ICCPS 2011.

40. 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

41. 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.