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

Semantic Gaps in CPS Models Models of Cyber-Physical Systems (CPS) Diverse engineering disciplines Heterogeneous formalisms Disparate levels of abstraction Partial overlap of referents 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 Challenge: semantic gaps Difgerences in meaning Implicit overlaps How to express properties of both models? 3

System Example Mission: navigate to the goal Multiple ways to reach the goal Limited battery capacity Can recharge at power stations 4

System Example 5

System Example 6

System Example 7

System Example 8

System Example 9

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

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

Problem How do we specify and check properties of 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 12

Our Approach In a Nutshell 13

Our Approach In a Nutshell 14

Our Approach In a Nutshell First-order quantifcation Linear temporal modalities 15

Integration Property 16

Integration Property 17

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 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 Semantics Gives meaning to formulas allowed by the syntax Reduces subformulas to either view or model semantics Enables a verifjcation algorithm 19

Verifcation of IPL Formulas IPL verifcation: views, model ⊨ formula 20

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

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 22

Verifcation of IPL Formulas IPL verifcation: views, model ⊨ formula Y/N 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

Technique: Rigid & Flexible Flexible terms/formulas – can change with time E.g., current position of robot curPos Only interpretable at model level 24

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) 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) Syntactic constraint on interleaving models/views Contributes to semantic modularity 26

IPL Syntax Rigid terms 27

IPL Syntax T erms Rigid terms 28

IPL Syntax Atomic rigid Atomic formulas formulas T erms Rigid terms 29

IPL Syntax IPL formulas Atomic rigid Atomic formulas formulas T erms Rigid terms 30

Application of IPL Encoding of property Verifjcation algorithm SMT solver Model checker 31

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 32

When IPL Works Well When models are implicitly related 33

When IPL Works Well When models are implicitly related When models & views are available 34

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 35

Limitations Fundamental: reliant on existing formal methods Satisfjability solvers Model checkers Theorem provers 36

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 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 Incidental: reliant on linear temporal logic Other temporal logics possible (e.g., metric, signal, comp. tree) Other models possible 38

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! 39

Summary 40