Towards a Language for Multi-Model CPS Integration Properties Ivan - - PowerPoint PPT Presentation

Towards a Language for Multi-Model CPS Integration Properties

Ivan Ruchkin, Bradley Schmerl, David Garlan Institute for Software Research Carnegie Mellon University

CPS V&V I&F Workshop May 12, 2017

2

Semantic Gaps in CPS Models

Models of Cyber-Physical Systems (CPS)

Diverse engineering disciplines Heterogeneous formalisms Disparate levels of abstraction Partial overlap of referents

3

Semantic Gaps in CPS Models

Models of Cyber-Physical Systems (CPS)

Diverse engineering disciplines Heterogeneous formalisms Disparate levels of abstraction Partial overlap of referents

Challenge: semantic gaps

Difgerences in meaning Implicit overlaps How to express properties

• f both models?

4

System Example

Mission: navigate to the goal

Multiple ways to reach the goal Limited battery capacity Can recharge at power stations

5

System Example

6

System Example

7

System Example

8

System Example

9

System Example

10

System Example

Property: “Robot does not run out of power between charging stations”

11

Relating with architectural views

• A. Bhave, B.H. Krogh, D. Garlan, and B. Schmerl. “View Consistency in Architectures for Cyber-Physical Systems.” In ICCPS 2011.

12

Problem

How do we specify and check properties

• f several CPS models?

Requirements for solution

Expressiveness: mixed-model properties, “natural” syntax Decidability: procedure for automated verifjcation of properties Semantic modularity: models not dependent on each other

13

Our Approach In a Nutshell

14

Our Approach In a Nutshell

15

Our Approach In a Nutshell

First-order quantifcation Linear temporal modalities

16

Integration Property

17

Integration Property

18

Integration Property Language (IPL)

Syntax

Declarative, one formula = one property Scope: one (dynamic) model and n (static) views Combines symbols from views and the model

19

Integration Property Language (IPL)

Syntax

Declarative, one formula = one property Scope: one (dynamic) model and n (static) views Combines symbols from views and the model

Semantics

Gives meaning to formulas allowed by the syntax Reduces subformulas to either view or model semantics Enables a verifjcation algorithm

20

Verifcation of IPL Formulas

IPL verifcation: views, model ⊨ formula

21

Verifcation of IPL Formulas

IPL verifcation: views, model ⊨ formula Model checking: for all traces ω in a model, determine if ω ⊨ model_formula

22

Verifcation of IPL Formulas

IPL verifcation: views, model ⊨ formula

SMT solving: determine all values of variables μ s.t. views, μ ⊨ view_formula(μ)

Model checking: for all traces ω in a model, determine if ω ⊨ model_formula

23

Verifcation of IPL Formulas

IPL verifcation: views, model ⊨ formula

SMT solving: determine all values of variables μ s.t. views, μ ⊨ view_formula(μ)

Model checking: for all traces ω in a model, determine if ω ⊨ model_formula

Y/N

24

Technique: Rigid & Flexible

Flexible terms/formulas – can change with time

E.g., current position of robot curPos Only interpretable at model level

25

Technique: Rigid & Flexible

Flexible terms/formulas – can change with time

E.g., current position of robot curPos Only interpretable at model level

Rigid terms/formulas – cannot change with time

E.g., map of the location map Interpretable at view level (and sometimes at model level)

26

Technique: Rigid & Flexible

Flexible terms/formulas – can change with time

E.g., current position of robot curPos Only interpretable at model level

Rigid terms/formulas – cannot change with time

E.g., map of the location map Interpretable at view level (and sometimes at model level)

Syntactic constraint on interleaving models/views

Contributes to semantic modularity

27

IPL Syntax

Rigid terms

28

IPL Syntax

Rigid terms T erms

29

IPL Syntax

Rigid terms T erms Atomic rigid formulas Atomic formulas

30

IPL Syntax

Rigid terms T erms Atomic rigid formulas Atomic formulas IPL formulas

31

Application of IPL

SMT solver Model checker

Verifjcation algorithm

Encoding of property

32

Requirements Revisited

Expressiveness – provided:

IPL expresses behavioral properties of one model Multiple views give “shallow” semantics of other models

Decidability – guaranteed:

Decision procedure reduces to other decidable problems

Semantic modularity – preserved:

Models are completely oblivious of views & each other Views have no behavioral semantics

33

When IPL Works Well

When models are implicitly related

34

When IPL Works Well

When models are implicitly related When models & views are available

35

When IPL Works Well

When models are implicitly related When models & views are available With behavioral models equivalent to automata

Anything that can be verifjed against a modal formula

36

Limitations

Fundamental: reliant on existing formal methods

Satisfjability solvers Model checkers Theorem provers

37

Limitations

Fundamental: reliant on existing formal methods

Satisfjability solvers Model checkers Theorem provers

Fundamental: reliant on the model-view fwk

Soundness and completeness of model-view abstraction Soundness of view-view mappings Quality of integration with IPL quality of models ≤

38

Limitations

Fundamental: reliant on existing formal methods

Satisfjability solvers Model checkers Theorem provers

Fundamental: reliant on the model-view fwk

Soundness and completeness of model-view abstraction Soundness of view-view mappings Quality of integration with IPL quality of models ≤

Incidental: reliant on linear temporal logic

Other temporal logics possible (e.g., metric, signal, comp. tree) Other models possible

39

What is Next?

More expressive behavioral properties

Integrals, difgerential/difgerence equations Hybrid/probabilistic models

Implementation for IPL

Parser Verifjcation engine

Application to other systems

Expressiveness Compare performance of verifjcation to other approaches Pointers to properties & models welcome!

40

Summary