Identifying and Resolving Consistency Issues between Model Representations
-
Upload
ivan-ruchkin -
Category
Software
-
view
94 -
download
0
Transcript of 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
Cyber-Physical Systems
4
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 Model Control Model
Multiple Models
Software Model
Physical Model Control Model
Multiple Models
Software Model
Physical Model Control Model
Hardware Model
Do they represent the system?
Are they consistent?
?
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
Approach
23
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
XRMy
YR
X
BARY
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)
Simulink Architecture View
30
Simulink Model
31
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
61 0
3
5
4 7
89
20
43
2
1
5
6
7
Physical ViewSimulink View
Hardware View
BA0
2
13
4 5
6
10
7 8 9
12
13
11
0
1
4
3
5 2
61 0
3
5
4 7
89
20
43
2
1
5
6
7
Physical ViewSimulink 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
Approach
44
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)
HP Part 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
Immediate Precise Sensing Conn. (IPSC)
?|xr – xs| > v2/b
Robot xr,v,b
Obstacle xs xo IPSC
xr,b
v
xo
xs
56
Immediate Precise Sensing Conn. (IPSC)
?|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.
Approach
65
Analytic Aspect of Integration
Sensor
Sampling PID
Controller Actuator
Controller
Sensor board
CPU Actuator
board
System
Bin packing
Analysis
Po
we
r
Exe
c T
ime
Frequency scaling
Analysis
66
Analytic Aspect of Integration
Sensor
Sampling PID
Controller Actuator
Controller
Sensor board
CPU Actuator
board
System
Bin packing
Analysis
Po
we
r
Exe
c T
ime
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
Bin packing Data security
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..v
n • φ | {∀|∃} v
1..v
n • φ : ψ
φ 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
Battery domain σbatt
Scheduling domain σsched
Bin packing Data security
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
Battery domain σbatt
• 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
Battery domain σbatt
• 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
Battery domain σbatt
• 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
Framework Implementation
81
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
The End
87