Identifying and Resolving Consistency Issues between Model Representations
-
Upload
ivan-ruchkin -
Category
Software
-
view
90 -
download
0
Transcript of Identifying and Resolving Consistency Issues between Model Representations
![Page 1: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/1.jpg)
David Garlan and Ivan Ruchkin
Carnegie Mellon University Pittsburgh, PA, USA
July 2015
![Page 2: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/2.jpg)
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
![Page 3: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/3.jpg)
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
![Page 4: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/4.jpg)
Cyber-Physical Systems
4
![Page 5: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/5.jpg)
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
![Page 6: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/6.jpg)
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
![Page 7: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/7.jpg)
Example: STARMAC Stanford Testbed for Autonomous Rotorcraft for Multi-
Agent Control (http://hybrid.eecs.berkeley.edu/starmac/)
Four rotors, arranged symmetrically on frame
11
![Page 8: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/8.jpg)
Battery
Ultrasonic Ranger
High Level Control Processor
Low Level Control Processor
GPS
Electronics Interface
Brushless Motors
IMU
![Page 9: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/9.jpg)
Multiple Models
Physical Model
![Page 10: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/10.jpg)
Multiple Models
Physical Model Control Model
![Page 11: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/11.jpg)
Multiple Models
Software Model
Physical Model Control Model
![Page 12: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/12.jpg)
Multiple Models
Software Model
Physical Model Control Model
Hardware Model
![Page 13: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/13.jpg)
Do they represent the system?
![Page 14: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/14.jpg)
Are they consistent?
?
![Page 15: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/15.jpg)
Is there a unifying representation?
?
![Page 16: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/16.jpg)
What happens when things change?
?
![Page 17: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/17.jpg)
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
![Page 18: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/18.jpg)
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
![Page 19: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/19.jpg)
Approach
23
![Page 20: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/20.jpg)
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
![Page 21: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/21.jpg)
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
![Page 22: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/22.jpg)
Quadrotor (base) Architectural Model
Cyber elements
Bridging elements
Physical elements
26
![Page 23: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/23.jpg)
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
![Page 24: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/24.jpg)
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
![Page 25: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/25.jpg)
STARMAC Architectural Views
TCP UDP
Model
Arch. View
Base Arch.
Hardware (AADL) Software (FSP) Physical (Modelica)
![Page 26: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/26.jpg)
Simulink Architecture View
30
![Page 27: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/27.jpg)
Simulink Model
31
![Page 28: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/28.jpg)
Gnd_Station QuadRotor
FSP Architecture View
32
![Page 29: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/29.jpg)
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
![Page 30: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/30.jpg)
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
![Page 31: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/31.jpg)
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
![Page 32: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/32.jpg)
Structural Inconsistency in STARMAC
Weak
Inconsistency
![Page 33: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/33.jpg)
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
![Page 34: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/34.jpg)
Approach
44
![Page 35: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/35.jpg)
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
![Page 36: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/36.jpg)
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
![Page 37: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/37.jpg)
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
![Page 38: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/38.jpg)
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
![Page 39: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/39.jpg)
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
![Page 40: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/40.jpg)
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
![Page 41: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/41.jpg)
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
![Page 42: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/42.jpg)
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
![Page 43: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/43.jpg)
54
Immediate Precise Sensing Conn. (IPSC)
xr,b
v
xo
xs
![Page 44: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/44.jpg)
55
Immediate Precise Sensing Conn. (IPSC)
?|xr – xs| > v2/b
Robot xr,v,b
Obstacle xs xo IPSC
xr,b
v
xo
xs
![Page 45: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/45.jpg)
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
![Page 46: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/46.jpg)
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
![Page 47: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/47.jpg)
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
![Page 48: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/48.jpg)
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
![Page 49: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/49.jpg)
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
![Page 50: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/50.jpg)
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.
![Page 51: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/51.jpg)
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.
![Page 52: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/52.jpg)
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.
![Page 53: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/53.jpg)
Approach
65
![Page 54: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/54.jpg)
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
![Page 55: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/55.jpg)
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
![Page 56: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/56.jpg)
Analysis Integration Problem
System
Analysis
Analysis
Analysis
Out-of-order execution
Analysis
Domain 2
Domain 1
68
![Page 57: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/57.jpg)
Analysis Integration Problem
System
Analysis
Analysis
Analysis
Out-of-order execution Invalidation of assumptions
Analysis
Domain 2
Domain 1
69
![Page 58: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/58.jpg)
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
![Page 59: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/59.jpg)
Running Example
Discharge Charge
Battery Scheduling
Battery
Scheduling
Bin packing Data security
x
Data security
x
72
![Page 60: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/60.jpg)
Running Example
Discharge Charge
Battery Scheduling
Battery domain σbatt
Scheduling domain σsched
Bin packing Data security
x
Data security
x
73
![Page 61: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/61.jpg)
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
![Page 62: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/62.jpg)
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
![Page 63: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/63.jpg)
Running Example
Discharge Charge
Battery Scheduling
Battery domain σbatt
Scheduling domain σsched
Bin packing Data security
x
Data security
x
76
![Page 64: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/64.jpg)
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
![Page 65: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/65.jpg)
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
![Page 66: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/66.jpg)
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
![Page 67: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/67.jpg)
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
![Page 68: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/68.jpg)
Framework Implementation
81
![Page 69: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/69.jpg)
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
![Page 70: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/70.jpg)
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
![Page 71: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/71.jpg)
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
![Page 72: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/72.jpg)
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
![Page 73: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/73.jpg)
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
![Page 74: Identifying and Resolving Consistency Issues between Model Representations](https://reader030.fdocuments.in/reader030/viewer/2022032513/55d1212fbb61eb1a1b8b4575/html5/thumbnails/74.jpg)
The End
87