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