Identifying and Resolving Consistency Issues between Model Representations

David Garlan and Ivan Ruchkin
Carnegie Mellon University
Pittsburgh, PA, USA
July 2015

Acknowledgements
 Joint work with faculty
 Bruce Krogh (Electrical Engineering)
 Andre Platzer (Computer Science)
 Bradley Schmerl (Software Engineering)
 Dionisio De Niz (Software Engineering Institute)
 Sagar Chaki (Software Engineering Institute)
 … and students
 Ajinkya Bhave (multi-view consistency)
 Akshay Rajhans (semantic verification)
 Ivan Ruchkin (architecture and analyses)
 With funding/support from
 National Science Foundation
 Bosch Corporation
 Toyota Corporation
2

Outline
 Characteristics of cyber-physical systems and the role of models
 Today’s model-based CPS methods have many problems
 Difficult to make trade-offs and ensure consistency/completeness
 Difficult to integrate the different modeling approaches
 Difficult to maintain models over time
 Approach:
 Unified representation through extensions of software architecture and
using architectural views to support heterogeneous modeling and analysis
 Formal approach to checking model consistency via views
 Tools for dependency analysis and coordination, supporting evolution
 Various examples along the way
 Quad-rotors, Smart highways, Real-time systems, Smart homes
3

What is a Cyber-Physical System?
 Many of today’s systems involve complex combinations of
software and physical elements
 Examples:
 Energy-efficient buildings (heating, cooling, power, …)
 Smart electric grid
 Transportation: automotive control, rail control, air traffic control
 Security systems
 These are hard to design and implement -- requires
expertise from many domains
 Control systems, networking, mechanical design, software
applications, etc.
 Effective engineering requires models: state machines, differential
equations, etc.
5

Problems
 Different formalisms and methods within CPS:
 physical dynamics
 control law development
 hardware platform
 software architecture
 Problem 1: Difficult to make tradeoffs across different
engineering dimensions
 Problem 2: Difficult to determine and maintain consistency
and completeness of models
 Problem 3: Difficult to combine multi-disciplinary analyses
10

Example: STARMAC
 Stanford Testbed for Autonomous Rotorcraft for Multi-
Agent Control (http://hybrid.eecs.berkeley.edu/starmac/)
 Four rotors, arranged symmetrically on frame
11

Battery
Ultrasonic Ranger
High Level
Control Processor
Low Level
Control Processor
GPS
Electronics
Interface
Brushless Motors
IMU

Multiple Models
Physical Model

Multiple Models
Physical ModelControl Model

Multiple Models
Software Model

Multiple Models
Software Model
Hardware Model

Is there a unifying representation?
?

What happens when things change?
?

What we would like
 An approach that unifies cyber and physical design
 Allows one to describe the complete system
 Supports tradeoff analysis
 Allows a multiplicity of models and analyses
 Detects inconsistencies and mismatched assumptions
 Can reason about completeness of design models
 Supported by tools
 Allowing automated checking and linkage to legacy
analysis tools
 Enables incremental development
21

Approach
1. Support both cyber and physical elements
through a CPS architectural style
2. Support heterogeneous models and analyses
through views
3. Determine consistency criteria for multiple views
4. Maintain views and models current through
model-view relations
5. Support development through analysis tools
6. Integrate multi-domain analyses using contracts
22

Software Architecture
 Represents a system as a graph of components and
connectors
 Components: computational elements (databases, servers,
etc)
 Connectors: communication pathways (RMI, http, etc)
 Properties: abstract behavior of elements (expected load,
latencies, transaction rates)
 Benefits of software architecture
 Abstraction reduces complexity
 Supports design-time analysis and tradeoffs
 However, does not usually consider physical
modeling, beyond simple sensors and actuators
24

Extended with Physical Elements
 Include physical system as a set of interacting
components with shared variables/coupled
constraints
 Components: Physical elements (mechanical, electrical,
thermal, environmental,…)
 Connectors: Physical interactions (conservation laws,
energy flows, …)
 Behavior: Dynamic behavior of elements (DAEs, LHA,
…)
 Bridging elements link physical elements to cyber
elements
25

Quadrotor (base) Architectural Model
Cyber elements
Bridging elements
Physical elements
26

Behavioral Modeling
 Behaviors are associated with subsets of the
architecture suitable for analysis
 Ex 1: Simulink model focuses on control performance,
abstracts scheduling and communication jitter in
software.
 Ex 2: Software behavior modeling focuses on
communication between position ground station and
position controller, abstracts away physical aspects.
 Leads to need for multiple models
 Tailored to particular behavior/analysis
 Related via a base architectural model through views
27

Models as Architectural Views
Control
Model
Mx
XR My
YR
X
BAR
Y
BAR
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
28

STARMAC Architectural Views
TCP UDP
Model
Arch.
View
Base
Arch.
Hardware (AADL) Software (FSP) Physical (Modelica)

Gnd_Station
QuadRotor
FSP Architecture View
32

Process Algebra View
 Can check, e.g., liveness
 If user tells ground station to move rotor to location A, ground
station will eventually receive a status message from the position
controller that it is at new location
 Allows us to reason about connection over lossy, wireless network
 Retry (TCP) connector allows liveness property to be satisfied
33
Gnd_Station
QuadRotor
TCP UDP

What about Consistency?
 Structural consistency between the base
architecture and a view
 Determines if a view represents a valid abstraction of the
base architecture
 Weak: All elements of a view must be derived (via
encapsulation) from the base architecture
 Special case is communication integrity: Two
components in a view cannot interact unless they can
also interact in the base architecture
 Strong: Every component in the base architecture is
accounted for in the view (possibly within an
encapsulation boundary)
34

Graph Analysis for View Consistency
0
2
13
4 5
6
10
7 8 9
12
13
11
0
1
4
3
5 2
1
3
2
0
4
3
2
1
5
6
7
Physical View
Simulink View
Hardw
BA
0
2
13
4 5
6
10
7 8 9
12
13
11
0
1
4
3
5 2
6
1 0
3
5
4 7
89
2
0
4
3
2
1
5
6
7
Physical View
Simulink View
Hardware View
BA
generation
of component
connectivity graph
Consistency of views analyzed
as graph morphisms1
35

Structural Inconsistency in STARMAC
Weak
Inconsistency

Tools: AcmeStudio
component/connector types
analysis plugins
 Extensible framework for architecture design and analysis
 Adaptation to CPS:
 support for associations between architectural views
 augmenting views with semantic attributes and analysis
 analysis plug-in for system-level verification
37

46
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

47
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 component-based engineering benefits
such as maintainability and analysis to hybrid programs

48
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
[1] A. Platzer. Logical Analysis of Hybrid Systems: Proving Theorems for Complex Dynamics. 2010.
Robot ::== (
a := *;
? b <= a <= A;
{ v' = a, x' = v, v >= 0 }
)*
x
v
a

49
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

50
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

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

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

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

54
Immediate Precise Sensing Conn. (IPSC)
xr,b
v
xo
xs

55
?|xr – xs| > v2/b
Robot
xr,v,b
Obstacle
xs
xoIPSC
xr,b
v
xo
xs

56
?|xr – xs| > v2/b
?|xr – xo| > v2/b
Robot
xr,v,b
Obstacle
xs
xo
Robot
xr,v,b
Obstacle
IPSC.Transform
IPSC
xr,b
v
xo
xs

57
HP Architectural View
● Contains: {HPA}, {HPC}, Composer
● Represented with a single architectural model
● Amenable to information flow analysis:
– Is information hiding violated?
HP View – an architectural representation of a HP.
HPA 1 HPA 2
generate
Composer
HP
View
HPC

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

59
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.”
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

60
Design, Reuse Component Analysis
Model-Driven Engineering with
Architectural HP
Verification
HP 1
HP 2
Type A Architectural View 1*..* *..*
Architectural View 2
Architectural View 3
ADDL 2
ADDL 1
1..1
Type B

61
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.
– Actor physics types are widely used, up to 5-7 times in 15
models
[2] S. Mitsch, K. Ghorbal, and A. Platzer. On provably safe obstacle avoidance for autonomous
robotic ground vehicles. 2013.

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

63
HP Views: Summary
● 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.

Analytic Aspect of Integration
Sensor
Sampling
PID
Controller
Actuator
Controller
Sensor
board
CPU
Actuator
board
System
Bin packing
Analysis
Power
ExecTime
Frequency scaling
Analysis
66

Analytic Aspect of Integration
Sensor
Sampling
PID
Controller
Actuator
Controller
Sensor
board
CPU
Actuator
board
System
Bin packing
Analysis
Power
ExecTime
Frequency scaling
Analysis
 Frequency scaling is applicable only when:
 used after Bin packing
 the system is behaviorally deadline-monotonic
 Otherwise frequency scaling may render the system
unschedulable
67

Analysis Integration Problem
System
Analysis
Analysis
Analysis
 Out-of-order execution
Analysis
Domain 2
Domain 1
68

Analysis Integration Problem
System
Analysis
Analysis
Analysis
 Out-of-order execution
 Invalidation of assumptions
Analysis
Domain 2
Domain 1
69

Analysis Contracts Approach
1. Formalize analysis domains.
2. Specify contracts: dependencies, assumptions, and
guarantees of analyses.
3. Determine correct ordering of analyses
4. Verify assumptions and guarantees of analyses.
71

Running Example
Discharge Charge
Battery Scheduling
Battery
Scheduling
Bin packing Data security
x
Data security
x
72

Running Example
Discharge Charge
Battery Scheduling
Battery domain σbatt
Scheduling domain σsched
x
Data security
x
73

Analysis Contracts
Given a domain σ, analysis contract C is a tuple (I, O, A, G)
 Inputs I ⊆ A ∪ S
 Outputs O ⊆ A ∪ S
 Assumptions A ⊆ Fσ
 Guarantees G ⊆ Fσ
74

Analysis Contracts
Given a domain σ, analysis contract C is a tuple (I, O, A, G)
 Inputs I ⊆ A ∪ S
 Outputs O ⊆ A ∪ S
 Assumptions A ⊆ Fσ
 Guarantees G ⊆ Fσ
Where:
 Fσ ::= {∀|∃} v1..vn • φ | {∀|∃} v1..vn • φ : ψ
 φ is a static predicate formula over A and S
 ψ is an LTL formula over A, S, and R
75

Running Example
Discharge Charge
Battery Scheduling
Scheduling domain σsched
x
Data security
x
76

Assumption Verification
Goal:
∀ t1, t2: Threads • t1 ≠ t2 ∧ CPUBind(t1) = CPUBind(t2) :
G (CanPrmpt(t1, t2) ⇒ Dline(t1) < Dline(t2))
• SMT solver finds solutions for static fragment φ
∀ t1, t:2Threads | t1 ≠ t2 ∧ CPUBind(t1) = CPUBind(t2)
• Model checking property ψ in a behavioral Promela model
for each SMT solution:
• G (CanPrmpt(t1, t2) ⇒ Dline(t1)< Dline(t2))
77

Battery Modeling
Discharge Charge
Battery Scheduling
• Abstraction: circuits
• Selects a scheduler for cell connections
• Oblivious of heat: treats any configuration as
acceptable heat-wise
• Abstraction: geometry
• Simulates heat propagation
• Cannot scale to dynamic scheduling: simulates
only fixed cell configurations
78

Battery Modeling
Discharge Charge
Battery Scheduling
• Abstraction: circuits
• Selects a scheduler for cell connections
• Oblivious of heat: treats any configuration as
acceptable heat-wise
• Abstraction: geometry
• Simulates heat propagation
• Cannot scale to dynamic scheduling: simulates
only fixed cell configurations
• Restrictions on acceptable thermal configurations
• Guarantee: unacceptable ones don't occur
79

Battery Modeling
Discharge Charge
Battery Scheduling
• Selects a battery scheduler
• G: ∀ b: Batteries • G ( ∑ i=0..3 K(b, i)*TN(b, i) ) ≥ 0
• Verified with battery Promela/Spin model
K(b, i)
• Determines K(b, i) via simulation
80

Analysis Contracts: Work in Progress
• New domains are being incorporated:
• Reliability (FMEA)
• Security (sensor trustworthiness)
• Control (secure state estimation)
• Tight integration with multiple views.
• Automated resolution of dependency loops.
82

Analysis Contracts: Summary
• Analysis integration is error-prone
• Incorrect ordering
• Violation of implicit assumptions
• Our solution:
• Contract specification language
• Contract verification algorithm
• Framework implementation
• Effective, extensible, and scalable
83

Conclusion
 CPS requires heterogeneous collections of models to
enable deep semantic analysis
 Leads to problems of consistency, completeness, and
incremental development
 We are exploring the integration of heterogeneous
modeling and analysis through architecture views
 Provides formal criteria for structural and semantic
consistency
 Can be supported by tools that manage dependencies and
support model-view relationships
84

References
 I. Ruchkin, B. Schmerl and D. Garlan. Architectural Abstractions for
Hybrid Programs. In Proc. of the 18th International ACM Sigsoft
Symposium on Component-Based Software Engineering (CBSE 2015),
Montréal, May 2015.
 I. Ruchkin, D. De Niz, S. Chaki, D. Garlan. Contract-Based Integration of
Cyber-Physical Analyses. In Proc. of the 14th International Conference on
Embedded Software, New Delhi, India, October 2014.
 A. Y. Bhave, B.H. Krogh, D. Garlan, and B. Schmerl. View Consistency in
Architectures for Cyber-Physical Systems. In 2011 IEEE/ACM International
Conference on Cyber-Physical Systems (ICCPS), 151-160, 2011.
 A. Rajhans, A.Y. Bhave, I. Ruchkin, B. Krogh, D. Garlan, A. Platzer, and B.
Schmerl. Supporting Heterogeneity in Cyber-Physical Systems
Architectures. In IEEE Transactions on Automatic Control, 2014.
85

 A. Rajhans, S.-W. Cheng, B. Schmerl, D. Garlan, B. Krogh, C. Agbi and
A. Y. Bhave. An Architectural Approach to the Design and Analysis of
Cyber-Physical Systems. In Electronic Communications of the EASST,
Vol. 21: Multi-Paradigm Modeling, 2009.
 A. Y. Bhave, B. Krogh, D. Garlan and B. Schmerl. Multi-domain
Modeling of Cyber-Physical Systems using Architectural Views. In
Proc. of the 1st Analytic Virtual Integration of Cyber-Physical Systems
Workshop, 2010. Co-located with RTSS 2010.
 A. Y. Bhave, D. Garlan, B. Krogh, A. Rajhans and B. Schmerl.
Augmenting Software Architectures with Physical Components. In
Proc. of the Embedded Real Time Software and Systems Conference
(ERTS 2010), May 2010.
 I. Ruchkin, D. De Niz, S. Chaki, D. Garlan. ACTIVE: A Tool for
Integrating Analysis Contracts. In Proc. of the 5th Analytic Virtual
Integration of Cyber-Physical Systems Workshop, 2014. Co-located
with RTSS 2014.
86
References

Identifying and Resolving Consistency Issues between Model Representations

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Identifying and Resolving Consistency Issues between Model Representations

Similar to Identifying and Resolving Consistency Issues between Model Representations (20)

More from Ivan Ruchkin

More from Ivan Ruchkin (20)

Recently uploaded

Recently uploaded (20)

Identifying and Resolving Consistency Issues between Model Representations