The Role of Models in Engineering of Cyber-Physical Systems – Challenges and Possibilities

In the ‘classical’ engineering process of embedded systems, models are most commonly used to support the early definition of the system (or parts thereof) or the environment. However, with the move from (complex) embedded systems to cyber-physical systems (CPS), we are experiencing a paradigmshift. In contrast to traditional embedded systems, CPS are driven by three additional dimensions of complexity: The ‘cross’-dimension, with issues like cross-application domains, cross-technologies, crossorganizations, etc; the ‘self’-dimension, with issues like self-monitoring, self-adapting, self-optimizing, etc.; and the ‘live’-dimension, with issues like liveconfiguration, live-update, live-enhancement, etc. Due to the necessary shift from the ‘classical’ development process in dedicated application domains with a clear distinction between Design/Implementation and Maintenance/Operation to the continuous development cycle merging these phases as well as roles like developer/operator/user, also the role of models in CPS requires a rethinking. In this contribution, we sketch how the model-based approach with construction, analysis and synthesis of models has to be adapted to support the engineering of cyber-physical systems, using the domain of smart energy systems for illustration. I. MODEL-BASED ENGINEERING OF EMBEDDED SYSTEMS The use of models as key technology in the engineering of embedded systems has become a best practice in several application domains. [5], for instance, shows – based on interviews of 187 engineers and developers from 14 different countries – that in the automotive domain functional modeling is adopted by 97% of the participants, with more than 95% generating code from these models. More than 40% of the participants use these models for a systematic validation and verification of the functionality under development. Overall, modelbased engineering in these domains can reduce the development effort by 30%. A major driver of this reduction is front-loading of quality assurance by model-based verification and validation, helping to identify up to 60% of the design flaws before the implementation stage. In these aforementioned domains – specifically automotive, areonautics, and automation – the following main categories of models are generally used: • Functional models: These models – often using a notation specific to the domain of application – describe the functionality of the system under development. In embedded systems, generally control-theoretic description techniques like Block Diagrams/Data Flow Diagrams and extensions thereof are used. • Platform models: These models describe the platform the functionality is deployed to – in general describing both the HW elements including control units and buses as well as the accompanying SW stack like middleware or operating systems. • Environment models: These models describe the behavior of (the part of) the environment the system under development is embedded into. In general, physical processes – like the rigid-body mechanics – controlled by the system are described, in rare cases these models 2 also describe users of the system. The use of concise description techniques to explicitly construct these models has become one of the core assets of a model-based development process: By limiting the expressibility – and thus focusing the specification on the relevant aspects – they constructively support the assurance of quality. Furthermore, the use of explicit models enables two further mechanisms: To analyze models w.r.t. their validity or correctness, e.g., by simulating executable models, check for absence of nondeterminism, or verify their conformance [4]. Furthermore, to synthesize new models or complete partial models, e.g., by obtaining test-cases from executable models, or generate deployments of function models including execution schedules to platforms [12]. Due to the mentioned success of model-based development of embedded systems, and the thematic relation between embedded and cyber-physical systems, the application of this development paradigm in the later thematic field is an obvious procedure. However, as argued in Section II, there is a substantial difference between embedded and cyberphysical systems, leading to new dimensions of complexity in the engineering process. Therefore, as sketched in Section III, while the mechanisms of construction, analysis, and synthesis of models form the base of a CPS engineering process, additional aspects must be addressed to make them applicable. II. PRINCIPLE CHARACTERISTICS OF CYBER-PHYSICAL SYSTEM Before sketching how models can be used in the engineering of cyber-physical systems, it is necessary to understand the CPS complexity drivers. Clearly, we think that definitions of CPS like “systems in which computing, broadly construed, interacts with the physical world” as provided in [2] do not focus on the core issues, as they also include “classical” embedded systems. In contrast, [8] stresses that CPS encompasses “embedded systems (...), but also logistics-, coordinationand management-processes Cross -domain -discipline -technology -organization -functional Self -documenting -monitoring -optimizing -healing -adapting Li ve -(re)configuration -(re)deployment -(de)comissioning -update -extension Automation