Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
Architectural Abstractions
for Hybrid Programs
Ivan Ruchkin
Bradley Schmerl
David Garlan
18th
International Symposium on...
2
Cyber-Physical Systems
● Cyber-physical systems (CPS) are software systems
interacting with complex physical world.
● Ma...
3
Cyber-Physical Systems
● Cyber-physical systems (CPS) are software systems
interacting with complex physical world.
● Ma...
4
Model-driven engineering for CPS
Software engineering models:
● UML, statecharts, ADLs, process
algebras
● Pros: informa...
5
Model-driven engineering for CPS
Software engineering models:
● UML, statecharts, ADLs, process
algebras
● Pros: informa...
6
Model-driven engineering for CPS
Software engineering models:
● UML, statecharts, ADLs, process
algebras
● Pros: informa...
7
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collis...
8
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic collis...
9
Background: hybrid programs (HPs) [1]
Robot ::== (
a := *;
? b <= a <= A;
{ v' = a, x' = v, v >= 0 }
)*
x
v
a
[1] A. Pla...
10
Background: hybrid programs (HPs) [1]
● A; B – execute A, then B
● A* - execute A zero or
more times
● ?P – test P; con...
11
Background: differential dynamic logic (DDL) [1]
[1] A. Platzer. Logical Analysis of Hybrid Systems: Proving Theorems f...
12
Background: differential dynamic logic (DDL) [1]
F ::== F1
∨ F2
| ¬F | A ~ B | x F | [A]F | <A>F∀
First-order logic
● E...
13
HP modeling
● HP modeling addresses a variety of concerns:
– Tactic: avoid obstacles / pass intersection / arrive at a ...
14
HP modeling
● HP modeling addresses a variety of concerns:
– Tactic: avoid obstacles / pass intersection / arrive at a ...
15
16
Robot's trajectory: arcs
17
Robot's trajectory: arcs
Robot-obstacle interaction
18
Robot's trajectory: arcs
Fragmentation of concerns and
components.
● Difficult to derive and reuse
variants
● No restri...
19
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic colli...
20
Architecture for HP
● Target: represent HPs with architectural constructs to enable:
– Composition and analysis
– Deriv...
21
HP Actors
Each actor contains:
● State: variables, constants, and constraints.
● Ports: variables visible to other acto...
22
Composers
Steps:
● {HPA} → HPA → HP
Example: sequential composer
SeqC(a,b)::== (a.Ctrl ; b.Ctrl; {a.Phys, b.Phys})*
HP
...
23
HP Connectors
Contains:
● Set of roles (e.g., sensing and sensed roles)
● Role-to-port attachment mapping
● Transform: ...
24
Immediate precise sensing conn. (IPSC)
xr
,b
v
xo
xs
25
Immediate precise sensing conn. (IPSC)
?|xr – xs| > v2/b
Robot
xr
,v,b Obstacle
xs
xoIPSC
xr
,b
v
xo
xs
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 O...
27
HP Architectural View
● Contains: {HPA}, {HPC}, Composer
● Represented with a single architectural model
● Amenable to ...
28
Architectural Types
Example: types of robot physics: grid / line / arc / spiral
HPA 1 HPA 2
generate
Composer
HP
View
H...
29
Architectural DDL Formula
Architectural DDL Formula (ADDL) – a DDL formula over HP views.
Example: “the robot behaves i...
30
Architectural DDL Formula
Init → [HP View 1] (RobotFar (ObstFar → <HP View 2> Safe))∧
HP View 1:
- robot is moving
- ob...
31
HP 1
HP 2
System
Type A Architectural View 1*..* *..*
Architectural View 2
Architectural View 3
ADDL 2
ADDL 1
Design, R...
32
Outline
● Hybrid programs and modularity
● Architectural abstractions for hybrid programs
● Evaluation in robotic colli...
33
Evaluation
● Method: “architecturalized” 15 model variants in an
existing case study [2]; observed extent of reuse and
...
34
Evaluation
● Method: “architecturalized” 15 model variants in an
existing case study [2]; observed extent of reuse and
...
35
Composition analysis results
● Lack of component separation: robot assigns
obstacle's position variable (intent – sensi...
36
Conclusion
● CPS require expressive and maintainable models.
● Hybrid programs are expressive, but have limited
modular...
39
Variable and constant declaration
Initial conditions and assumptions
Obstacle control
Robot control
Dynamics (both robo...
40
Intersection tactic
x
v
a, xr
y
vo
ao
yo
xint
, yint
yo
,vo
,ao
?
Image credit: pxleyes.com
41
Architecture-Based Model Integration
Control
Model
Base CPS Architecture
Hardware
Model
Arch. View X Arch. View Y
Contr...
42
Why not PL methods?
● Could have introduced language constructs for
modules, inheritance, …, but:
● “We don't want to c...
43
How is it different from (failed?) AOP?
● I modularize based on interacting entities, not
aspects.
● I work from global...
Upcoming SlideShare
Loading in …5
×

Architectural Abstractions for Hybrid Programs

822 views

Published on

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.

  • Be the first to comment

Architectural Abstractions for Hybrid Programs

  1. 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. 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. 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. 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. 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. 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. 7 Outline ● Hybrid programs and modularity ● Architectural abstractions for hybrid programs ● Evaluation in robotic collision avoidance
  8. 8. 8 Outline ● Hybrid programs and modularity ● Architectural abstractions for hybrid programs ● Evaluation in robotic collision avoidance
  9. 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. 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. 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. 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. 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. 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. 15
  16. 16. 16 Robot's trajectory: arcs
  17. 17. 17 Robot's trajectory: arcs Robot-obstacle interaction
  18. 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. 19 Outline ● Hybrid programs and modularity ● Architectural abstractions for hybrid programs ● Evaluation in robotic collision avoidance
  20. 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. 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. 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. 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. 24 Immediate precise sensing conn. (IPSC) xr ,b v xo xs
  25. 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. 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. 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. 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. 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. 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. 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. 32 Outline ● Hybrid programs and modularity ● Architectural abstractions for hybrid programs ● Evaluation in robotic collision avoidance
  33. 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. 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. 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. 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. 37. 39 Variable and constant declaration Initial conditions and assumptions Obstacle control Robot control Dynamics (both robot and obstacle) Desired property
  38. 38. 40 Intersection tactic x v a, xr y vo ao yo xint , yint yo ,vo ,ao ? Image credit: pxleyes.com
  39. 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. 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. 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.

×