List of Figures

The work of working group 1 on foundations revealed that the dependencies between the framework targeted in this report and the state-of-the-art report in form of deliverable D1.1 [START_REF] Giese | State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development[END_REF] was much more tight than initially expected. To avoid capturing some content of the stateof-the-art report also in a redundant form in the ontologies of the framework of this report, it was decided instead to include the relevant information in the ontologies and extract it from there automatically for generating the state-of-the-art report. In figure 1.1, the structure of the framework and its elements in form of the different ontologies and its instances is presented.

The first column depicts the framework and its ontologies as presented in this report. This includes the ontology of Cyber-Physical Systems presented in chapter 3, the ontology of Multi-Paradigm Modeling presented in chapter 4 and the combined ontology of Multi-Paradigm Modeling for Cyber-Physical Systems presented in chapter 5.

The Glossary of Terms for Cyber-Physical Systems presented in the report on the State-of-theart on Current Formalisms used in Cyber-Physical Systems Development covered by deliverable D1.1 [START_REF] Giese | State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development[END_REF] is extracted automatically from these ontologies and the contained concepts defining the framework.

Introduction

In the second column, the catalog of modeling languages and tools that is an instance of the MPM4CPS ontology presented in the report on the State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development covered by deliverable D1.1 [START_REF] Giese | State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development[END_REF] is depicted. The catalog of that deliverable will be automatically derived from this instance such that ontology and instances can be kept consistent with only minimal coordination efforts.https://www.sharelatex.com/project/5ae2fed74797f945fcb70b13

In the third column, some examples for CPS employing MPM in form of mega models are depicted that are presented in detail in the Catalog of Megamodel Examples in chapter 6. As shown in the figure, these examples employ the languages and tools listed in the report on the State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development and covered by deliverable D1.1 [START_REF] Giese | State-of-the-art on Current Formalisms used in Cyber-Physical Systems Development[END_REF], and also instantiate the MPM4CPS ontology.

Ontology Development Approach

To define the ontologies of WG1, we have carried out a domain analysis process [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF]. The domain analysis process can be defined as the process of identifying, capturing and organizing domain knowledge about the problem domain with the purpose of making it reusable when creating new systems. A domain is usually defined as an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. In our context, the domains of consideration are the domains of CPS and MPM, and we aim to derive and model the concepts of these domains. Figure 1.2 represents the common structure of domain analysis methods as it has been derived from survey studies on domain analysis methods.

Conventional domain analysis methods consist generally of the activities Domain Scoping and Domain Modeling: Domain Scoping identifies the domains of interest, the stakeholders, and their goals, and defines the scope of the domain. Domain Modeling is the activity for representing the domain, or the domain model. In our study the outputs of the domain modeling process will be the set of ontologies for CPS and MPM as identified by figure 1.1.

The domain model can be represented in different forms such as ontological languages, objectoriented language, algebraic specifications, rules, conceptual models etc. Typically, a domain model is formed through a commonality and variability analysis to concepts in the domain.

A domain model is used as a basis for engineering components intended for use in multiple applications within the domain.

One of the popular approaches for domain modeling is feature modeling. A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate between. A feature model is a model that defines features and their dependencies. Feature models are usually represented in feature diagrams (or tables). A feature diagram is a tree with the root representing a concept (e.g., a software system), and its descendent nodes are features. Relationships between a parent feature and its child features (or sub-features) are categorized as:

• Mandatory -child feature is required.

• Optional -child feature is optional.

• Or -at least one of the sub-features must be selected.

• Alternative (xor) -one of the sub-features must be selected A feature configuration is a set of features which describes a member of an SPL. A feature constraint further restricts the possible selections of features to define configurations. The most common feature constraints are:

• A requires B -The selection of A in a product implies the selection of B. • A excludes B -A and B cannot be part of the same product.

Feature modeling is a domain modeling technique, which is widely used to model the commonality and variability of a particular domain or product family. Another domain modeling technique that is used in software engineering is ontology modeling. A commonly accepted definition of an ontology is "an explicit specification of conceptualization" [START_REF] Gruber | Toward principles for the design of ontologies used for knowledge sharing?[END_REF]. An ontology represents the semantics of concepts and their relationships using some description language. Basic feature modeling is also a concept description technique that focuses on modeling both the commonality and variability. It has been indicated that feature models can be seen as views on ontologies [START_REF] Czarnecki | Feature models are views on ontologies[END_REF].

To develop the WG1 ontologies presented in details in the following chapters, the aforementioned techniques have been used. For the CPS ontology, feature modeling has been used while for the MPM ontology, modeling with the W3C OWL language and its tool Protege has been used.

As outlined in the introduction of Chapter 1 in Figure 1.1, the structure of the framework and its elements are organized in the form of different ontologies providing classes for the covered domains and individuals (instances) for these classes. The ontology presented in this chapter serves in this context as foundation to define an ontology of Cyber-Physical Systems later in Chapter 3 and an ontology of Multi-Paradigm Modeling in Chapter 4. Then, these ontologies together with the one of this chapter are combined to define an ontology of Multi-Paradigm Modeling for Cyber-Physical Systems presented in Chapter 5.

Ontology Overview

The shared ontology defines concepts that do not pertain to the CPS and neither to the MPM domain, but that are still required by one of these domains or both. It is a place to define concepts reusable by all the ontologies developed in this effort. The class provided in this ontology may be refined to provide extend the definitions to more specific domains.

DomainConcept

This class groups all concepts of the MPM4CPS ontology. It is further divided into into subclassed whose names end with DC in order to organize the ontology into sub-domains thus facilitating the navigation across the many concepts of the MPM4CPS ontology. Note that the sub-domain classes are not necessarily disjoints so that a class may belong to several domain concepts.

ParadigmDC (Paradigm Domain Concepts)

This class groups concepts that are related to the paradigm domain.

Paradigm

In the usual sense, a paradigm is a set of concepts, patterns, theories, research methods, postulates, and standards that together constitutes a contribution to a domain.

Subclass of

• ParadigmDC (see section 2.2.1)

• https://en.wikipedia.org/wiki/Paradigm

Principle

A principle is a law or rule that has to be, or usually is to be followed, or can be desirably followed, or is an inevitable consequence of something, such as the laws observed in nature or the way that a system is constructed. The principles of such a system are understood by its users as the essential characteristics of the system, or reflecting system's designed purpose, and the effective operation or use of which would be impossible if any one of the principles was to be ignored.

Subclass of

• ParadigmDC (see section 2.2.1)

ProcessDC (Process Domain Concepts)

This class groups concepts that are related to the development process domain.

Action

This class represents an action performed during an activity.

Subclass of

• ProcessDC (see section 2.2.2)

Activity

This class represents an activity performed during a process.

Subclass of

• ProcessDC (see section 2.2.2)

Process

A process is a sequence of activities executed in order to achieve a result or a goal.

Subclass of

• ProcessDC (see section 2.2.2)

• https://en.wikipedia.org/wiki/Process

Project

Subclass of

• ProcessDC (see section 2.2.2)

RelationDC (Relation Domain Concepts)

This class groups concepts that are related to the relation domain.

Constraint

A limitation or a restriction over a relation.

Subclass of

• RelationDC (see section 2.2.3)

Ontology of Shared Concepts

Relation

Relation or relations may refer to anything that involves communicating with another person, group, society or country.

Subclass of

• RelationDC (see section 2.2.3)

StakeholderDC (Stakeholder Domain Concepts)

This class groups concepts that are related to the stakeholder domain.

Concern

In computer science, a concern is a particular set of information that has an effect on the code of a computer program. A concern can be as general as the details of database interaction or as specific as performing a primitive calculation, depending on the level of conversation between developers and the program being discussed. IBM uses the term concern space to describe the sectioning of conceptual information.

Subclass of

• StakeholderDC (see section 2.2.4)

ConcernedElement

Subclass of

• StakeholderDC (see section 2.2.4)

• ConcernedElement (see section 2.2.4.2)

Organization

Subclass of

• StakeholderDC (see section 2.2.4)

Purpose

The object for which something exists

Subclass of

• StakeholderDC (see section 2.2.4)

Role

A role (also role or social role) is a set of connected behaviours, rights, obligations, beliefs, and norms as conceptualized by people in a social situation. It is an expected or free or continuously changing behaviour and may have a given individual social status or social position. It is vital to both functionalist and interactionist understandings of society.

Subclass of

• StakeholderDC (see section 2.2.4)

Stakeholder

A stakeholder or stakeholders, as defined in its first usage in a 1963 internal memorandum at the Stanford Research Institute, are "those groups without whose support the organization would cease to exist." The theory was later developed and championed by R. Edward Freeman in the 1980s. Since then it has gained wide acceptance in business practice and in theorizing relating to strategic management, corporate governance, business purpose and corporate so-cial responsibility (CSR). A corporate stakeholder can affect or be affected by the actions of a business as a whole.

Subclass of

• ConcernedElement (see section 2.2.4.2)

• StakeholderDC (see section 2.2.4)

ToolProvider

Who provides the product and gives the licenses (e.g. company, university, group, ..)

Subclass of

• Stakeholder (see section 2.2.4.6)

ToolDC (Tool Domain Concepts)

This class groups concepts that are related to the tool domain.

Tool

Set of different tools that are used during system development.

Subclass of

• ToolDC (see section 2.2.5)

Properties

Ontology of Cyber-Physical Systems

State-of-the-art

Cyber-Physical Systems (CPS) are systems that tightly integrate computation with networking and physical processes. Such systems form large networks that communicate with each other and rely on actuators and sensors to monitor and control complex with physical processes, creating complex feedback loops between the physical and the cyber worlds. CPS bring innovation in terms of economic and societal impacts for various kinds of industries, creating entirely new markets and platforms for growth. CPS have growing applications in various domains, including healthcare, transportation, precision agriculture, energy conservation, environmental control, avionics, critical infrastructure control (electric and nuclear power plants, water resources, and communications systems), high confidence medical devices and systems, traffic control and safety, advanced automotive systems, process control, distributed robotics (telepresence, telemedicine), manufacturing, and smart city engineering. The positive economic impact of any one of these applications areas is enormous.

Technically, CPS systems are inherently heterogeneous, typically comprising mechanical, hydraulic, material, electrical, electronic, and computational components. The engineering process of CPS requires distinct disciplines to be employed, resulting in a collection of models that are expressed using correspondingly distinct modelling formalisms.

An important realization is that distinct models need to be weaved together consistently to form a complete representation of a system that enables, among other global aspects, performance analysis, exhaustive simulation and verification, hardware in the loop simulation, determining best overall parameters of the system, prototyping, or implementation. A new framework is required that is able to represent these connections between models and, moreover, enable reasoning about them. No single formalism is able to model all aspects of a system; modelling of a CPS system is inherently multi-paradigm, which calls for a trans-disciplinary approach to be able to conjoin abstractions and models from different worlds. Physically, CPS systems are inherently heterogeneous, typically comprising mechanical, hydraulic, material, electrical, electronic, among others. Those areas correspond to engineering disciplines with their own models and abstractions designed to best capture the dynamics of physical processes (e.g., differential equations, stochastic processes, etc.). Computationally, CPS systems leverage the half-century old knowledge in computer science and software engineering to essentially capture how data is transformed into other useful data, abstracting away from core physical properties occurring in the real world, and particularly the passage of time in physical processes.

The key challenge, as identified a decade ago, is then to provide mathematical and technical foundations to conjoin physical abstractions that describe the dynamics of nature in various engineering domains, as described earlier, with models focusing solely on data transformation. This is necessary to adequately capture and bridge both aspects of a complex, realistic cyber-physical system, and become able to reason and explore system designs collaboratively, allocating responsibilities to software and physical elements, and analyzing trade-offs between them.

Currently, there is a few common design and modelling approaches that allow engineers to handle both aspects of CPS, allowing to bridge the involved disciplines into a shared, common one. Among the existing ones, co-simulation showed that it is possible for computation and physics engineers to cooperate efficiently without enforcing new tools or design methods.

Framework to Relate / Combine Modeling Languages and Techniques

Ontology Overview

After a domain analysis to CPS we have derived the feature model as shown in figure 3.1. The different components of a CPS system can be designed together or separately: in the latter case, the various different components need to be integrated. A CPS has different component types which can be computational or physical. Furthermore, a CPS has a network which can have different configurations and protocols.

Interoperability relates to how well the different components can operate together. Here we can have syntactic or semantic interoperability. Since both are required in CPS, these two features are considered mandatory, rather than alternative. Different components in a CPS can be of the same type or of different types, thereby distinguishing between homogeneous or heterogeneous CPS. The final feature in the feature model presents the various application domains in which CPS can be applied including manufacturing, healthcare, transportation etc.

Ontology Diagram

In this section we describe the metamodel for CPS which represents the concepts and their relations. The metamodel is shown in figure 3

Architecture

The architecture of a CPS represents the gross level structure of the system consisting of cyberphysical components. Current architecture design approaches for CPS seem to be primarily domain-specific and no standard reference architecture has been yet agreed upon. In this line, the development of an ontology for CPS also contributes to the efforts for designing a reference architecture.

A CPS reference architecture defines the generic structure of CPS architectures for particular application domains, laying the foundation for functionality, dependability, and other quality properties. An architecture organizes the functionality and the properties of a system to enable partitioning, verification, and management.

Figure 3.3 presents a layered view of a CPS architecture inspired on the IoT stack that arranges a CPS into successive layers of cohesive modules that share similar concerns. The four layers at the center include device layer, network layer, CPS layer, application layer, and business layer.

The CPS component layer includes the capabilities for the CPS components to undertake sensing and actuation. The network layer provides functionality for networking connectivity and transport capabilities enabling the coordination of components. The Services layer consists of functionality for generic support services (such as data processing or data storage), and specific support capabilities for the particular applications that may already apply a degree of intelligence. The application layer orchestrates the services to provide emergent properties. Then, there are two main cross-cutting concerns. A Security layer captures the security functionality, while the management layer supports capabilities such as device management, traffic and congestion management.

The reference architecture can be used to derive concrete application architectures. A concrete architecture defines the boundaries and constraints for the implementation and is used to analyze risks, balance trade-offs, plan the implementation project and allocate tasks.

Ontology Overview

Domain Concepts

This ontology of cyber-physical systems contains concepts divided into sub-domains as presented in the following subsections.

ApplicationDomainsDC

Various studies have addressed the domains and domain specific applications of CPS.

ArchitectureDC

QualityRequirementsDC

Cyber-Physical Systems revolutionize our interaction with the physical world. Of course, this revolution does not come free. Since even legacy embedded systems require higher standards than general-purpose computing, we need to pay special attention to this next generation physically-aware engineered system requirements if we really want to put our full trust in them. Therefore, we want to clarify the definitions of some common CPS system-level requirements /challenges.

Accuracy

Accuracy refers to the degree of closeness of a system's measured/observed outcome to its actual/calculated one. A highly accurate system should converge to the actual outcome as close as possible. High accuracy especially comes into play for CPS applications where even small imprecisions are likely to cause system failures. For example, a motion-based object tracking system under the presence of imperfect sensor conditions may take untimely control action based on incorrect object position estimation, which in return leads to the system failure.

Subclass of

• Predictability (see section 3.4.3.13)

Adaptability

Adaptability refers to the capability of a system to change its state to survive by adjusting its own configuration in response to different circumstances in the environment. A highly adaptable system should be quickly adaptable to evolving needs/circumstances. Adaptability is one of the key features in the next generation air transportation systems (e.g. NextGen). NextGen's capabilities enhance airspace performance with its computerized air transportation network which enables air vehicles immediately to accommodate themselves to evolving operational environment such as weather conditions, air vehicle routing and other pertinent flight trajectory patterns over satellites, air traffic congestion, and issues related to security.

Subclass of

• Sustainability (see section 3.4.3.21) Framework to Relate / Combine Modeling Languages and Techniques

Availability

Availability refers to the property of a system to be ready for access even when faults occur. A highly available system should isolate malfunctioning portion from itself and continue to operate without it. Malicious cyber-attacks (e.g. denial of service attacks) hinder availability of the system services significantly. For example, in Cyber-Physical Medical Systems, medical data shed light on necessary actions to be taken in a timely manner to save a patient's life. Malicious attacks or system/component failure may cause services providing such data to become unavailable, hence, posing risk on the patient's life.

Subclass of

• Dependability (see section 3.4.3.7)

• Security (see section 3.4.3.20)

Composibility

Composibility refers to the property of several components to be merged within a system and their inter-relationships. A highly composable system should allow recombination of the system components repeatedly to satisfy specific system requirements. Composibility should be examined in different levels (e.g. device composibility, code composibility, service composibility, system composibility). Certainly, system composibility is more challenging, hence the need for well-defined composition methodologies that follow composition properties from the bottom up. Additionally, requirements and evaluations must be composable accordingly. In the future, it will probably be of paramount importance to incrementally add emerging systems to the system of systems (e.g. CPS) with some predictable confidence without degrading the operation of the resulting system.

Subclass of

• Interoperability (see section 3.4.3.11)

Compositonality

Compositionality refers to the property of how well a system can be understood entirely by examining every part of it. A highly compositional system should provide great insight about the whole from derived behaviors of its constituent parts/components. Achieving high compositionality in CPS design is very challenging especially due to the chaotic behavior of constituent physical subsystems. Designing highly compositional CPS involves strong reasoning about the behavior of all constituent cyber and physical subsystems/components and devising cyber-physical methodologies for assembling CPSs from individual cyber and physical components, while requiring precise property taxonomies, formal metrics and standard test benches for their evaluation, and well-defined mathematical models of the overall system and its constituents.

Subclass of

• Predictability (see section 3.4.3.13)

Confidentiality

Confidentiality refers to the property of allowing only the authorized parties to access sensitive information generated within the system. A highly confidential system should employ the most secure methods of protection from unauthorized access, disclosure, or tampering. Data confidentiality is an important issue that needs to be satisfied in most CPS applications. For example, in an emergency management sensor network, attacks targeting confidentiality of data transmitted may degrade effectiveness of an emergency management system. Confidentiality of data transmitted through attacked sensor nodes can be compromised and that can cause data flow in the network to be directed over compromised sensors; critical data to be eavesdropped; or fake node identities to be generated in the network. Further, false/malicious data can be injected into the network over those fake nodes. Therefore, confidentiality of data circulation needs to be retained in a reasonable degree.

Subclass of

• Security (see section 3.4.3.20)

Dependability

Dependability refers to the property of a system to perform required functionalities during its operation without significant degradation in its performance and outcome. Dependability reflects the degree of trust put in the whole system. A highly dependable system should operate properly without intrusion, deliver requested services as specified and not fail during its operation. The words dependability and trustworthiness are often used interchangeably. Assuring dependability before actual system operation is a very difficult task to achieve. For example, timing uncertainties regarding sensor readings and prompt actuation may degrade dependability and lead to unanticipated consequences. Cyber and physical components of the system are inherently interdependent and those underlying components might be dynamically interconnected during system operation, which, in return, renders dependability analysis very difficult. A common language to express dependability related information across constituent systems/underlying components should be introduced in the design stage.

Subclass of

• QualityRequirementsDC (see section 3.4.3)

Efficiency

Efficiency refers to the amount of resources (such as energy, cost, time etc.) the system requires to deliver specified functionalities. A highly efficient system should operate properly under optimum amount of system resources. Efficiency is especially important for energy management in CPS applications. For example, smart buildings can detect the absence of occupants and turn off HVAC (Heating, Ventilation, and Air Conditioning) units to save energy. Further, they can provide automated pre-heating or pre-cooling services based on the occupancy prediction techniques.

Subclass of

• Sustainability (see section 3.4.3.21)

Heterogeneity

Heterogeneity refers to the property of a system to incorporate a set of different types of interacting and interconnected components forming a complex whole. CPSs are inherently heterogeneous due to constituent physical dynamics, computational elements, control logic, and deployment of diverse communication technologies. Therefore, CPSs necessitate heterogeneous composition of all system components. For example, incorporating heterogeneous computing and communication capabilities, future medical devices are likely to be interconnected in increasingly complex open systems with a plug-and-play fashion, which makes a heterogeneous control network and closed loop control of interconnected devices crucial. Configuration of such devices may be highly dynamic depending on patient-specific medical considerations. Enabled by the science and emerging technologies, medical systems of the future are expected to provide situation-aware component autonomy, cooperative coordination, real-time guarantee, and heterogeneous personalized configurations far more capable and complex than today's.

Subclass of

• Interoperability (see section 3.4.3.11)

Integrity

Integrity refers to the property of a system to protect itself or information within it from unauthorized manipulation or modification to preserve correctness of the information. A high integrity system should provide extensive authorization and consistency check mechanisms.

High integrity is one of the important properties of a CPS. CPSs need to be developed with greater assurance by providing integrity check mechanisms on several occasions (such as data integrity of network packets, distinguishing malicious behaviors from the ambient noise, identifying false data injection and compromised sensor/actuator components etc.). Properties of the physical and cyber processes should be well-understood and thus can be utilized to define required integrity assurance.

Subclass of

• Security (see section 3.4.3.20)

Interoperability

Interoperability refers to the ability of the systems/components to work together, exchange information and use this information to provide specified services. A highly interoperable system should provide or accept services conducive to effective communication and interoperation among system components. Performing far-reaching battlefield operations and having more interconnected and potentially joint-service combat systems, Unmanned Air Vehicles (UAVs) call for seamless communication between each other and numerous ground vehicles in operation. The lack of interoperability standards often causes reduction in the effectiveness of complicated and critical missions. Likewise, according to changing needs, dynamic standards should be developed and tested for devices, systems, and processes used in the Smart Grid to ensure and certify the interoperability of those ones being considered for a specific Smart Grid deployment under realistic operating conditions.

Subclass of

• QualityRequirementsDC (see section 3.4.3)

Maintainability

Maintainability refers to the property of a system to be repaired in case a failure occurs. A highly maintainable system should be repaired in a simple and rapid manner at the minimum expenses of supporting resources, and free from causing additional faults during the maintenance process. With the close interaction among the system components (e.g. sensors, actuators, cyber components, and physical components) underlying CPS infrastructure, autonomous predictive /corrective diagnostic mechanisms can be proposed. Continuous monitoring and testing of the infrastructure can be performed through those mechanisms. The outcome of monitoring and testing facilities help finding which units need to be repaired. Some components, which happen to be the source of recurrent failures, can be redesigned or discarded and replaced with the ones with better quality

Subclass of

• Dependability (see section 3.4.3.7)

Predictability

Predictability refers to the degree of foreseeing of a system's state/behavior/functionality either qualitatively or quantitatively. A highly predicable system should guarantee the speci-

Ontology of Cyber-Physical Systems

fied outcome of the system's behavior/functionality to a great extent every moment of time at which it is operating while meeting all system requirements. In Cyber-Physical Medical Systems (CPMS), smart medical devices together with sophisticated control technologies are supposed to be well adapted to the patient's conditions, predict the patient's movements, and change their characteristics based on context awareness within the surrounding environment. Many medical devices perform operations in real-time, satisfying different timing constraints and showing diverse sensitivity to timing uncertainties (e.g. delays, jitters etc.). However, not all components of CPMS are time-predictable. Therefore, in addition to new programming and networking abstractions, new policies of resource allocation and scheduling should be developed to ensure predictable end-to-end timing constraints.

Subclass of

• QualityRequirementsDC (see section 3.4.3)

Reconfigurability

Reconfigurability refers to the property of a system to change its configurations in case of failure or upon inner or outer requests. A highly reconfigurable system should be self-configurable, meaning able to fine-tune itself dynamically and coordinate the operation of its components at finer granularities. CPSs can be regarded as autonomously reconfigurable engineered systems. Remote monitoring and control mechanisms might be necessity in some CPS application scenarios such as international border monitoring, wildfire emergency management, gas pipeline monitoring etc. Operational needs (e.g. security threat level updates, regular code updates, efficient energy management etc.) may change for such scenarios, which calls for significant reconfiguration of sensor/actuator nodes being deployed or the entire network to provide the best possible service and use of resources.

Subclass of

• Sustainability (see section 3.4.3.21)

Reliability

Reliability refers to the degree of correctness which a system provides to perform its function. The certification of system capabilities about how to do things correctly does not mean that they are done correctly. So a highly reliable system makes sure that it does the things right.

Considering the fact that CPSs are expected to operate reliably in open, evolving, and uncertain environments, uncertainty in the knowledge, attribute (e.g. timing), or outcome of a process in the CPS infrastructure makes it necessary to quantify uncertainties during the CPS design stage.

That uncertainty analysis will yield to effective CPS reliability characterization. Besides, accuracy of physical and cyber components, potential errors in design/control flow, cross-domain network connections in an ad-hoc manner limit the CPS reliability.

Subclass of

• QualityRequirementsDC (see section 3.4.3)

Resilience

Resilience refers to the ability of a system to persevere in its operation and delivery of services in an acceptable quality in case the system is exposed to any inner or outer difficulties (e.g. sudden defect, malfunctioning components, rising workload etc.) that do not exceed its endurance limit. A highly resilient system should be self-healing and comprise early detection and fast recovery mechanisms against failures to continue to meet the demands for services. High resilience comes into play in delivering mission-critical services (e.g. automated brake control in vehicular CPS, air and oxygen flow control over an automated medical ventilator etc.). Mission-critical CPS applications are often required to operate even in case of disruptions at any level of the system (e.g. hardware, software, network connections, or the underlying infrastructure). Therefore, designing highly resilient CPS requires thorough understanding of potential failures and disruptions, the resilience properties of the pertinent application, and system evolution due to the dynamically changing nature of the operational environment.

Subclass of

• Sustainability (see section 3.4.3.21)

Robustness

Robustness refers to the ability of a system to keep its stable configuration and withstand any failures. A highly robust system should continue to operate in the presence of any failures without fundamental changes to its original configuration and prevent those failures from hindering or stopping its operation. In addition to failures, the presence of disturbances possibly arising from sensor noises, actuator inaccuracies, faulty communication channels, potential hardware errors or software bugs may degrade overall robustness of CPS. Lack of modeling integrated system dynamics (e.g. actual ambient conditions in which CPSs operate), evolved operational environment, or unforeseen events are other particular non-negligible factors, which might be unavoidable in the run-time, hence the need for robust CPS design.

Subclass of

• Reliability (see section 3.4.3.15)

Safety

Safety refers to the property of a system to not cause any harm, hazard or risk inside or outside of it during its operation. A very safe system should comply with both general and applicationspecific safety regulations to a great extent and deploy safety assurance mechanisms in case something went wrong. For example, among the goals for Smart Manufacturing (SM), pointin-time tracking of sustainable production and real-time management of processes throughout the factory yield to improved safety. Safety of manufacturing plants can be highly optimized through automated process control using embedded control systems and data collection frameworks (including sensors) across the manufacturing enterprise. Smart networked sensors could detect operational failures/anomalies and help prevention of catastrophic incidents due to those failures/anomalies.

Subclass of

• Dependability (see section 3.4.3.7)

Scalability

Scalability refers to the ability of a system to keep functioning well even in case of change in its size/increased workload, and take full advantage of it. The increase in the system throughput should be proportional to the increase in the system resources. A highly scalable system should provide scatter and gather mechanisms for workload balancing and effective communication protocols to improve the performance. Depending on their scale, CPSs may comprise over thousands of embedded computers, sensors, and actuators that must work together effectively. Scalable embedded many-core architectures with a programmable interconnect network can be deployed to deliver increasing compute demand in CPS. Further, a high performance and highly scalable infrastructure is needed to allow the entities of CPS to join and leave the existing network dynamically. In the presence of frequent data dissemination among those entities, dynamic software updates (i.e. changing the computer program in run-time) can help update CPS applications dynamically and use CPS resources more productively.

Ontology of Cyber-Physical Systems

Subclass of

• Interoperability (see section 3.4.3.11)

Security

Security refers to the property of a system to control access to the system resources and protect sensitive information from unauthorized disclosures. A highly secure system should provide protection mechanisms against unauthorized modification of information and unauthorized withholding of resources, and must be free from disclosure of sensitive information to a great extent. CPSs are vulnerable to failures and attacks on both the physical and cyber sides, due to their scalability, complexity, and dynamic nature. Malicious attacks (e.g. eavesdropping, man-in-the-middle, denial-of-service, injecting fake sensor measurements or actuation requests etc.) can be directed to the cyber infrastructure (e.g. data management layer, communication infrastructure, decision making mechanisms etc.) or the physical components with the intent of disrupting the system in operation or stealing sensitive information. Making use of a large-scale network (such as the Internet), adopting insecure communication protocols, heavy use of legacy systems or rapid adoption of commercial off-the-shelf (COTS) technologies are other factors which make CPSs easily exposed to the security threats.

Subclass of

• QualityRequirementsDC (see section 3.4.3)

Sustainability

Sustainability means being capable of enduring without compromising requirements of the system, while renewing the system's resources and using them efficiently. A highly sustainable system is a long lasting system which has self-healing and dynamic tuning capabilities under evolving circumstances. Sustainability from energy perspective is an important part of energy provision and management policies. For example, the Smart Grid facilitates energy distribution, management, and customization from the perspective of customers or service providers by incorporating green sources of energy extracted from the physical environment. However, intermittent energy supply and unknown/ill-defined load characterization hinders the efforts to maintain long-term operation of the Smart Grid. To maintain sustainability, the Smart Grid requires planning and operation under uncertainties, use of real-time performance measurements, dynamic optimization techniques for energy usage, environment-aware duty cycling of computing units, and devising self-contained energy distribution facilities (such as autonomous micro grids).

Subclass of

• QualityRequirementsDC (see section 3.4.3)

SystemDC

Component

Subclass of

• SystemDC (see section 3.4.4)

System

Subclass of

• Component (see section 3.4.4.1)

• SystemDC (see section 3.

State-of-the-art

Developing nowadays complex systems with Multi-Paradigm Modeling requires Global Model Management (GMM) (24; 67) to ensure that the models of different subsystems, of different views and of different domains are properly combined, even though the models might reside at different levels of abstraction. GMM must also ensure that the development activities that operate on the models are properly coordinated such that the models lead to a proper system as a whole, where the different elements and aspects covered by the different models are correctly integrated and are consistent with each other.

A classification of model integration problems and fundamental integration techniques has been introduced in [START_REF] Giese | Model-Based Integration[END_REF]. It highlights the techniques of decomposition and enrichment, which characterize two orthogonal dimensions of development where the system is decomposed into subsystems and domains (horizontal dimension) and into a set of models with increasing level of details (vertical dimension). Another approach to support interoperability among languages and tools is presented in [START_REF] Malavolta | Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies[END_REF]. The approach is general, however it is exemplified on interoperability among architectural languages and tools [START_REF] Malavolta | What Industry Needs from Architectural Languages: A Survey[END_REF]. An approach to extend architectural languages is presented in [START_REF] Di Ruscio | Developing Next Generation ADLs Through MDE Techniques[END_REF]. The technique is based on some operators to integrate models and it is generalized in [START_REF] Di Ruscio | Model-Driven Techniques to Enhance Architectural Languages Interoperability[END_REF]. Model integration requires coordinating all activities operating on the models across these dimensions to ensure their consistency. A model-driven approach to automate the propagation of changes among Architecture Description Languages [START_REF] Malavolta | What Industry Needs from Architectural Languages: A Survey[END_REF] is presented in [START_REF] Eramo | A model-driven approach to automate the propagation of changes among Architecture Description Languages[END_REF]. However, inconsistency management goes beyond simply identifying and resolving inconsistencies, since as pointed out in [START_REF] Finkelstein | Inconsistency Handling in Multiperspective Specifications[END_REF], inconsistencies may need to be tolerated at some stage of the development. Therefore, living with inconsistencies must be manageable and consequently, an approach is required to detect, resolve, but also tolerate inconsistencies for a significant amount of time during development. The work in [START_REF] Wohlrab | Collaborative traceability management: a multiple case study from the perspectives of organization, process, and culture[END_REF] provides empirical evidence of how culture, processes, and organization impact traceability management and collaboration, and principles support practitioners with collaborative traceability management. The work shows that collaboration and traceability management have the potential to be mutually beneficial -when investing in one, also the other one is positively affected.

The development activities for nowadays complex systems and in particular CPSs encompass multiple domains and teams, with each team using a dedicated set of modelling languages, thus requiring their proper integration and management. Using a single "model-it-all" language to cover all domains would certainly lead to large, monolithic languages that become less efficient, not easily customisable for development environments and tools needed by development teams, therefore adding difficulties to the already demanding effort of developing CPS. These considerations lead to Multi-Paradigm Modeling (MPM) [START_REF] Vangheluwe | An introduction to multiparadigm modelling and simulation[END_REF], which advocates the combination of reusable modular modeling languages instead of large monolithic languages. Hence, GMM must support integrating models and modeling languages with appropriate abstractions and modularity, but also coordinating all activities operating on the models and specified as model operations / transformations. The execution of these model operations has to be scalable for being able to handle large models. This requires incrementality, where only the operations impacted by a model change are re-executed, thus avoiding the effort to recompute entire models, as in the case of incremental code compilers.

GMM is also known as modeling-in-the-large, which consists of establishing global relationships (e.g. model operations that generated one model from other models) between macroscopic entities (models and meta models), while ignoring the internal details of these entities [START_REF] Bézivin | Modeling in the Large and Modeling in the Small[END_REF]. Mega modeling (25; 67) has been introduced for the purpose of describing these macroscopic entities and their relations. Nowadays only preliminary approaches exist that provide ad-hoc solutions for fragments of the sketched problem and a solid understanding of the underlying needs including new foundations to address this problem as proposed to be developed by WG1 of MPM4CPS. In particular, the current approaches do at most offer some modularity and/or incrementality for a single aspect as modeling languages or model operations. However, support for handling complex modeling landscapes as a whole in a modular and incremental fashion as required for the large-scale problems that exist in practice is not offered so far.

In the following, we will first look at existing solutions that address the construction and execution of models and modeling languages in Section 4.1.1, model operation sin Section 4.1.2, and mega models in Section 4.1.3.

Models and Modeling Languages: Construction and Execution

The construction of models and modeling languages is addressed in the current approaches in three main ways via (1) linking of models and model elements, (2) model interfaces and (3) meta model composition.

Model / Model Elements Links

Many approaches rely on traceability links between models and/or model elements to capture megamodelling relations/operations. We adopt here the definition proposed by the Center of Excellence for Software Traceability (CoEST): a trace link is "[...] a specified association between a pair of artifacts, one comprising the source artifact and one comprising the target artifact...". The CoEST specialises those links into two dimensions: vertical trace links link [...] artifacts at different levels of abstraction so as to accommodate lifecycle-wide or end-to-end traceability, such as from requirements to code [...]"; while horizontal trace links associate "[.

..] artifacts at the same level of abstraction, such as: (i) traces between all the requirements created by 'Mary', (ii) traces between requirements that are concerned with the performance of the system, or (iii) traces between versions of a particular requirement at different moments in time".

A plethora of approaches have been proposed that make use of trace links for model integration (cf. e.g., (AMW; Epsilon; 68; 109; 87; 129; 31) (MoTE)). The Atlas Model Weaving (AMW) language (AMW) provided one of the first approaches for capturing hierarchical traceability links between models and model elements. The purpose was to support activities such as automated navigation between elements of the linked models. In this approach, a generic core traceability language is made available and optionally extended to provide semantics specific to the metamodels of the models to be linked. Similarly, the Epsilon framework (Epsilon) provides a tool named ModeLink to establish correspondences between models. MegaL Explorer (68) supports relating heterogeneous software development artifacts using predefined relation types, linking elements that do not necessary have to be models or model elements. SmarfEMF ( 109) is another tool for linking models based on annotations of Ecore metamodels to specify simple relations between model elements through correspondence rules for attribute values. Complex relations are specified with ontologies relating the concepts of the linked languages. The whole set of combined models is converted into Prolog facts to support various activities such as navigation, consistency and user guidance when editing models. The CONSYSTENT tool and approach (87) make use of a similar idea. However, graph structures and pattern matching are used to represent the combined models in a common formalism and to identify and manage inconsistencies instead of Prolog facts as in the case of SmartEMF.

There are also a number of approaches, such as ( 129) and [START_REF] Boddy | FUSED: A Tool Integration Framework for Collaborative System Engineering[END_REF], that build on establishing links between models through the use of integration languages developed for a specific set of integrated modeling languages, where the integration language embeds constructs specific to the linked languages. This is also the case for model weaving languages extending the core AMW language. However, AMW has the advantage of capturing the linking domain with a core common language. Other means for linking and integrating models are Triple Graph Grammars (TGG) such as the Model Transformation Engine (MoTE) tool (MoTE), which similarly requires the specification of some sort of integration language (correspondence meta model) specific to the integrated languages. However, an important asset of this approach is that it automatically establishes and manages the traceability links and maintains the consistency of the linked models (model synchronization) in a scalable, incremental manner. Finally, in (128; 126)( 23), an approach is presented to automatically create and maintain traceability links between models in a scalable manner. While the approach focuses on traceability management rather than model integration, compared to integration languages, it relies on link types defined at the model level (and not at the meta model / language level), thus avoiding the need to update the integration language every time a new language must be integrated.

The comparison of these approaches shows that apart from the approach (128; 126)( 23), all approaches suffer from being dependent on the set of integrated languages, thus requiring to better support modularity. Furthermore, only (MoTE)(128; 126)( 23) supports automated management of traceability links.

Interfaces

In addition to links, a few more sophisticated approaches (e.g., (106; 88; 96)) introduce the concept of model interface for specifying how models can be linked. In [START_REF] Langsweirdt | Architecture-Driven Development of Embedded Systems with ACOL[END_REF], the Analysis Constraints Optimization Language (ACOL) is proposed, which has been designed to be pluggable to an Architecture Description Language (ADL). A concept of interface specific to ACOL is included so that constraints can refer to these interfaces to relate to the model elements expected from the ADL. SmartEMF (88; SmartEMF) proposes a more generic concept of model interface to track dependencies between models and metamodels and provide automated compatibility checks. Composite EMF Models (96; Composite EMF Models) introduces export and import interfaces to specify which model elements of a main model (body) should be exposed to other models (i.e. are part of the public API), and which elements of a body model are to be required from an export interface.

However, these approaches are only preliminary and need to be enriched to cover a larger number of model integration use cases such as for example, specifying modification policies of the linked model elements required to ensure the models can be kept consistent. They also lack integration into GMM.

Metamodel Composition

Some approaches (e.g., (Kompren; Kompose; 66; EMF Views) [START_REF] Blouin | Extensible Global Model Management with Meta-model Subsets and Model Synchronization[END_REF]) consider the construction of metamodels for expressing views in terms of other metamodels or language fragments. In [START_REF] Etien | Combining Independent Model Transformations[END_REF], an approach implemented in the Gaspard2 tool (Gaspard2) is presented where meta models are artificially extended for the purpose of combining independent model transformations resulting in an extended transformation for the extended meta models. The work in (60) presents

Ontology of Multi-Paradigm Modeling

operators to compose metamodels while preserving specific properties. In [START_REF] Blouin | Kompren: modeling and generating model slicers[END_REF], the language and tool (Kompren) (Kompren) is proposed to specify and generate slices of metamodels via the selection of classes and properties of an input metamodel. A reduced metamodel is then produced from the input metamodel. However the produced metamodel must be completely regenerated when the input metamodel is changed. Such is the case for the Kompose approach (Kompose), which on the contrary to Kompren, proposes to create compound metamodels, where a set of visible model elements from each combined metamodels is selected, and optionally related. The EMF Views (EMF Views; 50) provides similar approach however without the need to duplicate the meta model elements as opposed to Kompose and Kompren where a new metamodel is created. These virtual view metamodels seem to be usable transparently by tools. Finally, the Global Model Management language (GMM*)1 ( 28) provides means to specify and interpret reusable language subsets as sets of constraints combined to form subsetted meta models. Like for EMF Views, these reduced meta models can to some extent be used transparently by tools.

While each of these approaches provides interesting support for modular modeling languages, their unification into a common formalism, the use of an explicit notion of a model interface and their integration into GMM is lacking, except for subsetted metamodels already integrated within the GMM* language.

The execution of integrated models concerns the evaluation of the well-formedness constraints of each combined model alone, but also of the combined models as a whole. To our knowledge, no approach addresses the incremental checking of well-formedness conditions across the different language fragments of compound models. However, some approaches on incremental constraints evaluation exist. In [START_REF] Blanc | Incremental Detection of Model Inconsistencies Based on Model Operations[END_REF], changes on models are expressed as sequences of atomic model operations to determine which constraint is impacted by the changes, so that only these constraints need to be re-evaluated. In (EMF-IncQuery; 133), a graph-based query language (EMF-IncQuery) relying on incremental pattern matching for improved performance is also proposed. In [START_REF] Egyed | Instant Consistency Checking for the UML[END_REF], an approach is presented for incremental evaluation of constraints based on a scope of model elements referenced by the query and determined during the first query evaluation. This scope is stored into cache and used to determine which queries need to be re-evaluated according for some model changes. In [START_REF] Groher | Incremental Consistency Checking of Dynamic Constraints[END_REF], this approach is extended for the case where the constraints themselves may change besides the constrained models. Finally in [START_REF] Cabot | Incremental Evaluation of OCL Constraints[END_REF], an incremental OCL checker is presented where a simpler OCL expression and reduced context elements set are computed from an OCL constraint and a given structural change event. Evaluating this simpler constraint for the reduced context is sufficient to assert the validity of the initial constraint and requires significantly less computation resources.

Model Operations: Construction and Execution

The construction of model operations is addressed in two ways in the literature. Most approaches combine model operations as model transformations chains (named (1) flow composition), where each chained transformation operates at the granularity of complete models. In order to support reuse and scalability for complex modeling languages, which are defined by composing them from simpler modeling languages, a few approaches have considered specifying model transformations as white boxes. Composed of explicit fine grained operations processing model elements for a given context, these operations are reusable across several model transformations (named (2) context composition).

Flow Composition Approaches

Formal United System Engineering Development (FUSED) ( 31) is an integration language to specify complex relationships between models of different languages. It supports model transformation chains, but only implicitly via execution of tools, without explicit representation of the involved transformations and processed data. On the contrary, there is a plethora of approaches allowing the explicit specification and construction of model transformation chains implementing a data flow paradigm. A popular one is the AtlanMod Mega Model Management (AM3) tool (AM3), for which the Atlas Transformation Language (ATL) (ATL) is used to specify the model transformations. Besides, a type system has been developed [START_REF] Vignaga | Typing artifacts in megamodeling[END_REF], which enables type checking and inference on artifacts related via model transformations. Another similar but less advanced tool is the Epsilon Framework (Epsilon), which provides model transformation chaining via ANT tasks. Wires [START_REF] Rivera | Orchestrating ATL Model Transformations[END_REF] and ATL Flow (ATLFlow) are tools providing graphical languages for the orchestration of ATL model transformations. The Formalism Transformation Graph + Process Model (FTG+PM) formalism [START_REF] Lúcio | FTG+PM: An Integrated Framework for Investigating Model Transformation Chains[END_REF] implemented in the AToMPM (A Tool for Multi-Paradigm Modeling) tool (AToMPM) provides similar functionality. However, it has the advantage of also specifying the complete modeling process in addition to the involved model transformations. This is achieved via activity diagrams coupled with model transformation specifications executed automatically to support the development process. Finally, GMM* (28) also supports model transformation chaining, but through the specification of relations between models of specific metamodels that can be chained. One advantage of this approach is that automated incremental (re-)execution of the specified relations between models is provided in response to received model change events. Incrementality of the execution of the transformations is also made possible by the integration of the MoTE (MoTE) incremental model transformation tool into GMM*.

However, while chaining model transformations offers some degree of modularity of model transformation specifications, apart from GMM*, most approaches suffer from scalability issues for large models, since the used transformation tools do not support incremental execution. In addition, the case where a generated model is modified by hand to add information not expressible with the language of the original model(s) cannot easily be handled by these approaches, since regenerating the model modified by hand will destroy the user-specific information. This need is better supported by context composition approaches.

Context Composition Approaches

A few approaches allow context composition of model operations. In [START_REF] Etien | Combining Independent Model Transformations[END_REF] as mentioned above, independent model transformations are combined, resulting in extended transformations for corresponding extended meta models. In [START_REF] Debreceni | Query-driven Incremental Synchronization of View Models[END_REF], view models are built using contextual composition of model operations (derivation rules) encoded as annotations of queries of the EMF IncQuery (EMF-IncQuery) language. Traceability links between view and source model elements are automatically established and maintained. The use of EMF IncQuery natively provides incremental execution of the derivation rules to synchronize the view model with the source model. Some views may be derived from other views thus allowing flow composition as chains of view models. This approach achieves results similar to TGGs supporting incrementality, however with the drawback of being unidirectional. Similarly, but equpped with bi-directionality, the MoTCoF language (127) allows for both flow-and fine-grained context composition of model transformations. An advantage over [START_REF] Etien | Combining Independent Model Transformations[END_REF] however is that model transformations are used as black boxes without the need to adapt the transformations according to the context.

As can be seen, most approaches only support flow type modularity for model operations with batch execution except for the GMM* language thanks to its integration of MoTE providing incremental execution. This will not scale and lead to information losses in case of partial model information overlap. Only a few approaches allow context modularity, which better supports incremental application where only the impacted operations can be re-applied following a change in order to avoid the cost of re-computing complete transformations. Such is the case of MoTCoF, which theoretically permits incremental execution, but a concrete technical solution is still lacking for it.

Megamodels and other Global Model Management Approaches

Two strands can be identified for GMM. A first one makes use of (1) model integration languages, which are defined for a specific set of integrated modeling languages and tools meaning that the integration language must be updated every time a new language or tool is used. The second strand attempts to solve this problem by making use of (2) mega models providing configurable global model management.

Integration Language and other Approaches

The CyPhy (129) used in the GME modeling tool (GME) and FUSED [START_REF] Boddy | FUSED: A Tool Integration Framework for Collaborative System Engineering[END_REF][START_REF] Fused | FUSED Project Homepage[END_REF] are examples of model integration languages. But as mentioned above, these languages must be adapted as soon as a different set of integrated languages and tools must be used, thus requiring highly skilled developers. Integration languages are therefore not practical.

Open Services for Lifecycle Collaboration (OSLC) (OSLC) provides standards for tool integration through the Web. Many specifications are available for change management, resource previews, linked data, etc. It builds on the W3C linked data standard, which aims at providing best practices for publishing structured data on the Web based on the W3C Resource Description Framework (RDF). RDF is a model for data interchange on the Web where data is represented as graphs. However, OSLC is more services (and tools) oriented and inherits the problems of linked data, which is specific to the Web and therefore does not separate the concerns of data representation and persistence as opposed to Model-Driven Engineering (MDE) where an abstract syntax is used independently of the way the data is stored.

Another approach making use of these standards is [START_REF] Herzig | An Approach to Identifying Inconsistencies in Model-based Systems Engineering[END_REF] and is implemented in a the CON-SYSTENT tool used to identify and resolve inconsistencies across viewpoints due to information overlapping. The information of all models involved during development is captured in a common RDF graph. The approach relies on a human (in parallel, an automated method making use of Bayesian Belief Networks is also under study [START_REF] Herzig | Bayesian Reasoning Over Models[END_REF]) to specify patterns representing semantic equivalence links (semantic connections) across the graph models. Inconsistency patterns based on these semantic connections are continuously checked over the RDF model for potential matches identifying inconsistencies. Means to automatically resolve inconsistencies are under development. However, since the conversion of all models as an RDF graph is required, this approach is not incremental and will not scale for large models.

Mega Models

In this second strand, megamodels serve to capture and manage MDE resources such as modeling languages, model transformations, model correspondences and tools used in modeling environments. There are several mega modeling approaches as already mentioned. AM3 (AM3) is one of the first initiatives where a megamodel is basically a registry for MDE resources. Model transformations are specified with ATL (ATL) and model correspondences with the Atlas Model Weaving (AMW) language [START_REF] Ali | DEECo: An Ecosystem for Cyber-physical Systems[END_REF]. Similarly, FTG+PM [START_REF] Lúcio | FTG+PM: An Integrated Framework for Investigating Model Transformation Chains[END_REF] as well as MegaL Explorer [START_REF] Favre | Modeling the linguistic architecture of software products[END_REF], allow to model the artifacts used in software development environments and their relations from a linguistic point of view. The involved software languages, related technologies and technological spaces can be captured with linguistic relationships between them such as membership, subset, conformance, input, dependency, definition, etc. Operations between entities can also be captured. The artifacts do not need to be represented as models, but each entity of the megamodel can be linked to a Web resource that can be browsed and examined. However, the language seems to be used mostly for visualization providing a better understanding of the developments artifacts but cannot be executed to perform model management. The aforementioned GMM* infrastructure (28) consists of a megamodeling language inspired from (85). Metamodels can be declared, as well as relations between models of these meta models. In particular, synchronization relations can relate models of two different meta models making use of the MoTE TGG engine (MoTE) to transform or synchronize the models. As mentioned earlier, chains of model transformations can be specified and executed incrementally in response to model change events and subsets of modeling languages can be declared. GMM* is experimented within the Kaolin tool (29) making use of complex and rich industrial languages such as AADL and VHDL thus challenging GMM for realistic specifications.

However, most of these mega modeling approaches only cover to a certain degree the core ingredients of specifying MDE resources by means of meta models and model operations with appropriate modularity and incrementality. Only fragments of the problem are solved. Furthermore, all these megamodeling languages are monolithic and as a result, predefined megamodel fragments cannot be easily composed and reused to avoid rebuilding complete megamodel specifications from scratch for new projects. An attempt towards the reuse of megamodel fragments is presented in (90; 89). The work makes use of megamodeling techniques to propose an automated infrastructure to facilitate customization, composition and reuse of the architect's representational resources to meet project-, domain-and organization-specific needs. Among these megamodeling approaches, only FTG+PM, GMM* and (128; 126) address the automated execution of megamodels in response to model changes or modeling events from the tool's user interface. GMM* and (128; 126) provide incremental execution of mega models to some extent by re-evaluating only the relations concerned with the detected model changes.

Multiformalism Modelling Approaches

According to [START_REF] Mosterman | Computer automated multi-paradigm modeling: An introduction[END_REF], multiformalism modeling is one of the three dimensions of the Computer Automated Multi-Paradigm Modeling framework, established to allow the representation, the analysis and the synthesis of intricate knowledge at various levels of abstraction, together with multilevel abstraction and metamodeling. Multiformalism, Multiresolution, Multiscale Modeling (M4) environments may provide [START_REF] Dandashi | Multiformalism, Multiresolution, Multiscale Modeling[END_REF] an important and manageable resource to fulfill the needs for modeling and simulation of modelers that have to deal with complex systems, where complexity derives from heterogeneity of components and relationships, multiple scales, multiple interacting requirements. Besides performance (or verification) oriented issues, multiformalism approaches may also deal with software architecture oriented issues, e.g. by integrating UML as one of the formalisms to assist the development cycle of large, complex software systems [START_REF] Grant | Model oriented software architecture[END_REF]: in general, literature proposes very popular dedicated transformational approaches for computer automated or assisted software generation, that provide a formal framework to support the steps that lead from a formal or semiformal specification to code, but in the rest of this subsection the focus is on performance oriented approaches.

In multiformalism modeling, many formalisms may be used simultaneously in a model. This may or may not exploit compositionality in the modeling approach, as elements of the different formalisms may coexist in the model, or the model may be composed of submodels written in different (single and particular) formalisms, or the different formalisms may be used in different steps of the processing of the model, by means of model transformation or generation. A general introduction to these themes can be found in [START_REF] Marco Gribaudo | An introduction to multiformalism modeling[END_REF].

Metamodeling is an important resource for both performance oriented approaches (105) [START_REF] Vangheluwe | Computer Automated Multi-Paradigm Modelling: Meta-Modelling and Graph Transformation[END_REF] and software oriented transformation based tools, consequently metamodeling-based multiformalism approaches can be considered a peculiar category. Another special category of approaches is constituted by the ones that deal with hybrid systems, that support multiformalisms with both continuous and discrete nature, and are thus capable of modeling natural systems in a better way [START_REF] Zeigler | Interfacing continuous and discrete models for simulation and control[END_REF]. These approaches should be able to describe and solve jointly and coherently differential equation like descriptions and state space-based descriptions, for a same complex system. While the problem has been popular in the 70s and 80s, there is currently a renovated interest in it from the point of view of cyberphysical systems: the interested reader can find specific general multiformalism approaches in ( 140), ( 18) and [START_REF] Barbierato | Simulating Hybrid Systems Within SIMTHESys Multi-formalism Models[END_REF], that also provides an overview of selected previous, classical literature.

Approaches

With reference to multiformalism approaches oriented to performance evaluation, a number of different naive and structured approaches to the problem have been presented in literature (a survey is provided in [START_REF] Balsamo | A Survey on Multi-Formalism Performance Evaluation Tools[END_REF]). In the second group, the approaches have been implemented in a number of different tools, with different backgrounds, such as SHARPE, SMART, DEDS, AToM3, Möbius, OsMoSys and SIMTHESys. These tools also differ in the solution strategy adopted for the evaluation of models, and are designed with different purposes (e.g. some of them are designed to be extensible, some for experimenting new formalism variants, some optimize the solution process). SHARPE [START_REF] Trivedi | SHARPE 2002: Symbolic Hierarchical Automated Reliability and Performance Evaluator[END_REF] supports the composition by submodels of some given different formalisms, solved by different solvers, but based on Markovian approaches. The composition consists in the exchange of probability distributions between submodels. SMART (47)(48)(46) supports the specification and solution, by simulation or approximation, of complex discrete-state systems. DEDS [START_REF] Bause | A Toolbox for Functional and Quantitative Analysis of DEDS[END_REF] provides a common abstract notation in which submodels written in different formalisms are translated. Möbius (125)(49)(53)(56) supports, by states and events superposition, a number of different formalisms (that can be extended by user provided code) and alternative solvers (that can be chosen by the modeler) in a very articulated modeling and solution process.

Other approaches exploit, in different ways, metamodeling too. AToM3 (107; 58) exploits metamodeling to implement model transformations, used to solve models by its solver. OsMoSys (71; 137; 72; 73; 81) and SIMTHESys (14; 16; 94; 93) use metamodeling to let different userdefined formalisms interact by founding them over common metaformalisms and using elements and formalism level inheritance, and to implement different compositional mechanisms: while OsMoSys implements ad-hoc operators for parameters exchange between submodels, and integrates external solvers by means of orchestration and adapters, SIMTHESys privileges the experimentation of user-defined formalisms and embeds into formalism elements the interactions between different formalisms implementing multiformalism by arcs superposition, allowing the automatic synthesis of proper solvers, according to the nature of the involved formalisms (with no claim for their optimality): there is an explicit specification of both syntax and semantics of every formalism element to allow high flexibility in the specification of custom, user defined formalisms. For more details, the reader may refer to [START_REF] Marco Gribaudo | An introduction to multiformalism modeling[END_REF], that provides a more detailed analysis on multiformalism features and implementation, solution processes, purposes, compositional and transformational mechanisms of these approaches.

Solution

Most of the approaches are backed up with state space analysis techniques. Both analyticaland simulation-based methods are applied to perform the analysis, eventually with specific solutions to cope with the state space explosion problem, such as folding, decomposition, product forms solutions. The most common way is to directly generate the whole state space, with (e.g. in Möbius or in [START_REF] Pezze | Constructing multi-formalism state-space analysis tools: Using rules to specify dynamic semantics of models[END_REF]) or without (e.g. in SMART or in some SIMTHESys solvers) an intermediate step of simple translation or more sophisticated transformation towards a specific intermediate representation, or by using partial state spaces exploiting modularity (e.g. in Os-

Framework to Relate / Combine Modeling Languages and Techniques

MoSys or in some SIMTHESys solvers( 21)), or by transformation (e.g. in AToM, or in ( 30)). Noticeable are the approaches that exploit mean field analysis to cope with very large space states (e.g. ( 32) or ( 44)).

Applications

The literature provides a conspicuous number of applications: here some significant examples are provided. The effect of cyber-exploits have on information sharing and task synchronization have been studied in [START_REF] Levis | Multi-formalism modeling for evaluating the effect of cyber exploits[END_REF]; performance evaluation of Service Oriented Architecture have been studied in ( 1) and (95); cardiovascular system and its regulation has been studied, with a hybrid approach, in (? ); interdependencies in electric power systems have been studied in [START_REF] Chiaradonna | On a modeling framework for the analysis of interdependencies in electric power systems[END_REF]; the ERMTS/ETCS European standard for high speed trains has been studied in ( 70); security attacks have been studied in [START_REF] Gribaudo | Exploiting Bayesian Networks for the Analysis of Combined Attack Trees[END_REF]; exceptions aware systems have been studied in [START_REF] Barbierato | Performability Modeling of Exceptions-Aware Systems in Multiformalism Tools[END_REF]; effects of software rejuvenation techniques have been studied in ( 13); NoSQL systems have been studied in [START_REF] Barbierato | Performance evaluation of NoSQL big-data applications using multi-formalism models[END_REF]. Multiformalism has been also applied as an implementation technique to provide higher level tools or formalisms: in (122) a flexible, optimized Repairable Fault Tree modeling and solution approach is presented; a performance oriented model checking example is given in [START_REF] Barbierato | Exploiting multiformalism models for testing and performance evaluation in SIMTHESys[END_REF]; an analysis framework for detecting inconsistencies in high level semantic relationships between models has been developed in [START_REF] Qamar | Analyzing semantic relationships between multiformalism models for inconsistency management[END_REF].

Ontology Overview

This ontology captures the Multi-Paradigm Modeling Domain (MPM). It includes concepts for the related modeling, linguistic and formal sub domains.

Domain Concepts

This ontology of multi-paradigm modeling contains concepts divided into sub-domains as presented in the following subsections.

FormalDC

This class groups domain concepts that are related to the formal aspects of MPM.

Architecture

A system architecture is a conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a

LinguisticDC

This class groups domain concepts related to the linguistic aspects of MPM, such as modeling, programming, formal and even natural languages and their syntax.

AbstractSyntax metamodel

Subclass of

• Syntax (see section 4.3.3.22)

Architecture

A system architecture is a conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.

Subclass of

• FormalSemantics (see section 4.3.3.14)

ArchitectureDescriptionLanguage

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

The system engineering community uses an architecture description language as a language and/or a conceptual model to describe and represent system architectures.

The software engineering community uses an architecture description language as a computer language to create a description of a software architecture. In the case of a so-called technical architecture, the architecture must be communicated to software developers; a functional architecture is communicated to various stakeholders and users. Some ADLs that have been developed are: Acme (developed by CMU), AADL (standardized by the SAE), C2 (developed by UCI), SBC-ADL (developed by National Sun Yat-Sen University), Darwin (developed by Imperial College London), and Wright (developed by CMU).

The up-to-date list of currently existing architectural languages might be found at Up-to-date list of ADLs.

The ISO/IEC/IEEE 42010 document, Systems and software engineering-Architecture description, defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies minimum requirements on ADLs.

The enterprise modeling and engineering community have also developed architecture description languages catered for at the enterprise level. Examples include ArchiMate (now a

TransformationLanguage

A transformation language is a computer language designed to transform some input text in a certain formal language into a modified output text that meets some specific goal.

Subclass of

• Language (see section 4.3.3.16)

ModelingDC

This class groups domain concepts related to the modeling aspects of MPM.

ApplicationMegaModel

A representation of the real models in the CPS development environment.

Subclass of

• Megamodel (see section 4.3.4.6)

ArchitectureDescriptionLanguage

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

The system engineering community uses an architecture description language as a language and/or a conceptual model to describe and represent system architectures.

The software engineering community uses an architecture description language as a computer language to create a description of a software architecture. In the case of a so-called technical architecture, the architecture must be communicated to software developers; a functional architecture is communicated to various stakeholders and users. Some ADLs that have been developed are: Acme (developed by CMU), AADL (standardized by the SAE), C2 (developed by UCI), SBC-ADL (developed by National Sun Yat-Sen University), Darwin (developed by Imperial College London), and Wright (developed by CMU).

The up-to-date list of currently existing architectural languages might be found at Up-to-date list of ADLs.

The ISO/IEC/IEEE 42010 document, Systems and software engineering-Architecture description, defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies minimum requirements on ADLs.

The enterprise modeling and engineering community have also developed architecture description languages catered for at the enterprise level. Examples include ArchiMate (now a standard of The Open Group), DEMO, ABACUS (developed by the University of Technology, Sydney). These languages do not necessarily refer to software components, etc. Most of them, however, refer to an application architecture as the architecture that is communicated to the software engineers.

Most of the writing below refers primarily to the perspective from the software engineering community.

Subclass of

• ModelingLanguage (see section 4.3.4.13)

CapturingOperation

The process of capturing information (e.g from users) into a model.

Subclass of 5 Ontology of Multi-Paradigm Modeling for Cyber-Physical Systems

Introduction

This ontology of MPM for CPS provides cross-cutting concepts between the two domains of CPS and MPM. At the current stage of development, this ontology only contains a limited number of classes related to viewpoints inspired from [START_REF] Broman | Viewpoints, Formalisms, Languages, and Tools for Cyber-physical Systems[END_REF].

Ontology Overview

Domain Concepts

This ontology of multi-paradigm modeling contains concepts divided into sub-domains as presented in the following subsections.

MPM4CPSDC

View

Subclass of

• MPM4CPSDC (see section 5.3.1)

• View (see section 5.3.1.1)

ViewPoint

Subclass of

• MPM4CPSDC (see section 5. An Ensemble-Based Cyber-Physical System (EBCPS) is an emergent system that is distributed, decentralized, dynamic, self-adaptive and scalable. It consists of autonomous components and forms ensembles of them depending on the context in the aim of achieving determined goals (i.e. organizing and decision-making). More specifically, the composition of components changes according to the fact of having the components appear and disappear dynamically, in addition to the unexpected changes in the environment and new requirements. There are many applications in different domains such as Traffic and Transport, Robotics, and Clouds. For instance, an ensemble of vehicle planning for optimal route with considering the road and traffic conditions.

The interest of building such systems was reflected in many European projects such as AS-CENS1 , ALLOW Ensembles2 and FoCAS3 , which are FP7 projects. ASCENS is oriented towards design and verification, while ALLOW Ensembles is more oriented towards performance. More specifically, ASCENS targets formalizing and modeling ensembles of autonomic-service components (SCs) that depend on knowledge units (K). It considers also the expression of selfadaption and provides tools and use cases. ALLOW Ensembles focuses on developing algorithms that improve ensembles utility and system dependability. Both previous projects are involved in FoCAS, which is a platform for communities that care about developing Collective Adaptive Systems (CASś).

As part from ASCENS project, a formalism language was introduced to express the ensembles called Service Component Ensemble Language (SCEL) Figure 6.1. The language allows to define Knowledge, Behaviors, Aggregations, and Policies. It allows the developer to define interfaces with attributes or knowledge for Service Components (SCs) and their behavior using processes. Also, the developer can define the Service Component Ensembles (SCEs) and the conditions or policies to form them. The ensembles are responsible for exchanging knowledge between the components. Each ensemble evaluates the constraints over the interface attributes of the involved components. The support of context-awareness comes from using attributes in the constraint evaluation of forming ensembles. Furthermore, ASCENS provides many tools for modeling (e.g. HELENA, KnowLang, DEECo) and for simulation (e.g. ARGoS, SPL, jDEECo Java, SimSOTA). Additionally, the concepts are

Examples

presented in three use cases in different domains, which are: Clouds, Traffic and Transport, and Robotics.

Dependable Emergent Ensembles of Components (DEECo)

To manifest the new concepts of EBCPS, the Department of Distributed and Dependable Systems (d3s: http://d3s.mff.cuni.cz/) at Charles University in Prague developed an EBCPS toolchain that is used as development environment which merges the concepts of emergent systems with the CPS parts (i.e. physical, computational and network). More specifically, the parts that will be explained here are requirements, design, runtime, self-adaptation, analysis, composition and simulation. Moreover, there are many integrations and transformations between the models. ure ??, which is developed in Epsilon, is used to represent the tree of invariants and assumptions for the system. The tree ends with leaves of two types: 1) processes which are part of a component, 2) or exchange knowledge between components which are ensembles. Simply put, the IRM allows to connect the requirements to the architecture entities directly. Later on, the developer can transform the IRM model to code which is Java for the current represented tool-chain under DEECo specification.

Design and Runtime

Regarding the design and runtime parts [START_REF] Bures | DEECO: An Ensemble-based Component System[END_REF](2) , the team developed a runtime environment which is implemented in java and is known as jDEECo. The developer is able to design systems that respect the DEECo specification (i.e. SCEL specification), which is captured by specific Java annotations provided by jDEECo runtime Figure 6.4. More specifically, the designed system consists of roles, components, and ensembles. Each role has a set of attributes, which represent the knowledge related to this specific role. Furthermore, each component is defined as a set of processes featuring (a) role(s) having by that the role knowledge besides its local knowledge. Having knowledge in the role allows for preserving the encapsulation of the components that features the role and provides a separation in concerns. Hence, each ensemble forms depending on the context and perform knowledge exchange between different components with determined roles. It is worth mentioning that there is another framework that integrates with jDEECo, which is called Intelligent Ensemble framework4 [START_REF] Krijt | Intelligent Ensembles -A Declarative Group Description Language and Java Framework[END_REF]. It provides the developer with Ensemble Definition Language (EDL) that was developed using XText and XPand on Eclipse Modelling Framework. At runtime the formation of the ensemble is optimized by using Z3 SMT solver. Not only is DEECo implemented in java, but also it is implemented in C++ 5 and Scala 6 . Nevertheless, the model operations that we mentioned here (i.e. transformation and integrations) are applied on jDEECo (i.e. java implementation).

Examples

Self-Adaptation

Self-adaptation is done in two methods. The first method is by transforming IRM tree to java code with annotations, then at runtime the annotations are processed by IRM-SA engine which uses SAT solver to make decisions between the different paths. The other method is by using modes and mode-switching annotations that are provided by DEECo. It is possible to associate a mode to a set of processes, thus when a mode-switch happens a different set of processes is activated.

There is a part that is presented as an extension of mode-switch transition logic, which are: 1) ordinary differential equation (ODE) to evaluate the inaccuracy boundaries of physical attribute s(6), 2) statistical testing to use prediction depending on trends of historical dat a [START_REF] Bures | Statistical Approach to Architecture Modes in Smart Cyber Physical Systems[END_REF].

Another essential point that DEECo focuses on is forming ensembles and exchanging knowledge. DEECo manifests those concepts and allows for using conditions that are a representation of context to form ensembles. The conditions are refined by using a Z3 SMT Solve r(103) and fitness, which filter out the less suitable compositions between all possible ones. Regarding exchanging knowledge between components, it could be determined by context constraints or by adding boundaries on gossip protocol that is responsible of spreading informatio n [START_REF] Bures | Gossiping Components for Cyber-Physical Systems[END_REF]. Furthermore, DEECo allows a hierarchical composition for ensemble s (41)(40).

Simulation

Finally, the simulation part targets two domains for vehicles [START_REF] Kit | An Architecture Framework for Experimentations with Self-adaptive Cyber-physical Systems[END_REF] and robots [START_REF] Matena | Model Problem and Testbed for Experiments with Adaptation in Smart Cyber-physical Systems[END_REF]. Concerning vehicles, jDEECo has an integration with MATSim which allows to simulate vehicles and OM-NET++ which simulates the network delays. Regarding the robots case, jDEECo has an integration with ROS which simulates movements of robots. While ROS has in its turn an integration with OMNET++ to simulate network delays and with Stage to simulate sensors and actuators.

To conclude, DEECo development environment provides a toolchain for modeling CPS system with an emergent behavior starting from requirement to runtime and simulation. To get the different views of system developmen,t many transformation and integration operations are involved which supports the idea of multi-paradigm modeling. These are further presented in the developed ontology of DEECo briefly presented below.

Applications

Many applications were introduced using DEECo concepts, which are in Automotive, Robotics, Clouds and Industry domains.

The Automotive example ( 92) is basically to present aspects of requirements, self-adaptation, networking, and simulation. The IRM tree represents finding a free parking and MATSim7 simulates the traffic. The models involved in this example are IRM Model, DEECo Design time Model, DEECo Runtime Model, and MATSim. Furthermore, in (100), the example presents Also, a railroad emergency response service example includes trucks helping damaged trains (e.g. because of low fuel quality) [START_REF] Krijt | Automated Dynamic Formation of Component Ensembles -Taking Advantage of Component Cooperation Locality[END_REF]. The service should take into account the performance and the balance in serving between different clients. In other words, repairing the trains should be fast, but also the trucks should consider the situation in case another farther train was damaged at the same time (i.e. not only going to the closest train). Here, the development starts with defining EDL Files, compiling them, and then generating the DEECo Design time Model. At runtime, the DEECo Runtime Model integrates with Z3 SMT Solver to optimize forming the ensembles. The FireFighter Coordination example is another example that represents the use of IRM-SA model and DEECo (76) (77). The example describes groups of firefighters that have to operate using low-power nodes and without communication guarantees. The work presents selfadaptation using multi-layered architecture, which are: Meta-Adaptation Layer, Adaptation Layer,and Business System. Thus, the example involves IRM-SA model, Self-Adaptation Model, DEECo Runtime Model and DEECo Design time Model.

Examples

Another example related to parking places but with edge cloud usage is presented in ( 42 As for predictability and adaptability, the use case present cleaners that detect the need for charging or cleaning, and the active mode is determined statistically to avoid premature modeswitch [START_REF] Bures | Statistical Approach to Architecture Modes in Smart Cyber Physical Systems[END_REF]. This example involves the statistical mode-switching in Self-Adaptation Model, in The scalability issue was targeted in an example about intelligent production line (IPL) 13 [START_REF] Matena | An Ensemble-Based Approach for Scalable QoS in Highly Dynamic CPS[END_REF]. The example also aims at preserving the safety conditions in the work place with taking into account the scalabe QoS grantees. To put it differently, the robots have safety zone and speed grantees, which change depending on the number of human and robots in the area. The used models are OMNeT++ and INET simulators with DEECo Design Model and DEECo Runtime Model.

The privacy and trust use case describes the exchange of the sensitive data between companies or inside the company itself ( 5),( 4),(3) (i.e. as part of Trust 4.0 project 14 ). More specifically, the system preserves information by preventing physical encounter between different teams, which is done through granting/denying access for the employees depending on the time table and existing people in the room (4). Another example is about production shifts, the foreman role has access only for employees' names in that shift. In case the system detects a possible delay of one of the employees, the system grants the foreman an access to name and phone number of a backup employee. Similarly, the confidentiality levels between companies depends on the context such as encountering incidents. These examples uses the basic concepts of DEECo (i.e. DEECo Design time Model and DEECo Runtime Model) in Scala 15 . It involves

Ontology

The structure of DEECo is described using the ontologies provided by MPM4CPS. This is done by instantiating its classes, so the created set of individuals represents DEECo.

CPS

In this part, the individuals represents the system domain and its parts, in addition to the its requirements.

• ApplicationDomainsDS: BuildingAutomation, IntelligentTransport, RoboticForService, SmartManufacturing

Examples

Figure 6.18: The use case illustrates a production area, which has many halls. For each hall, there is a single foreman who manages the workers.

• Architecture: Generic Architecture

• SystemDC:

SystemPart: regarding the CommunicationProtocol, the short range communication (P2P) is used in most of the use cases (e.g. MANET, gossip protocol, ...).

Component: entities which are modeled in CPS using DEECo are hardware/physical components. For instance, vehicle or cleaner are physical components with a need for representation of physical process dynamics (i.e. differential equations). Additionally, it is possible to model components in the environment such as human.

Development Process

The development process starts with capturing requirements operation in which a human is responsible of defining the IRM-SA model. Afterwards, the IRM tree is transformed to DEECo Design Model, which its instantiation are DEECo Runtime Model and Simulation Models.

The DEECo Runtime Model is integrated with self-Adaptation model. It is possible also to define modes and their transitions in DEECo Design time model. Hence, the logic over transitions are extensible with ODE or statistical reasoning. Similarly, it is possible to define in the DEECo Design Model formation of ensembles by using gossiping boundary and fitness. The boundary defines limits on gossiping protocol and the fitness evaluates the history of forming ensembles and select the best fitting group of components that are involved to form the ensemble.

Finally, DEECo Runtime Model is also integrated with simulation models. For more information, please check the following links: In this part, the views and viewpoints for this system are described as following:

• View: Requirement Designer

• ViewPoint: The concerns in this viewpoint is related to resilience, and involves both roles and ensembles in the system. The designer determines the environmental assumptions to each choice to ensure preserving the required invariants. That makes this viewpoint related to the cyber part of the system (i.e. software).

• View: Component Designer

Examples

• ViewPoint: The concerns in this viewpoint is related to performances, accuracy, robustness and self-adaptation. It involves designing roles, processes and modes, in addition to relations between processes and the assumptions from requirement phase. Also, components contain controllers, sensors, and actuators, which means that this viewpoint is related to physical and cyber parts of the system.

• View: Ensemble Designer

• ViewPoint: The concerns in this viewpoint are related to knowledge exchange, security, optimization, scalability and performances. The designer should determine the roles involved in ensembles, the context constraints and what information to exchange. Additionally, the designer can optimize forming the ensembles by using fitting function and defining a boundary over gossip protocol. The design of ensembles could be also associated to system requirements as it is mentioned in the Requirement Designer view. This makes this viewpoint related to network and cyber (i.e. software) parts of the system.

HPI CPSLab 18

To structure the presentation of this case study according to the efforts for the MPM4CPS project, we will at first in Section 6.2.1 provide an overview about the case study and lab, then in Section 6.2.2 review the technical setting and derive the required needs concerning the CPS ontology, thereafter in Section 6.2.3 we will outline how the models, tools, and tool chain employed in the case study can be captured as multi-paradigm modeling and derive the required needs concerning the MPM ontology, and finally in Section 6.2.4 we discuss how the CPS character of the case study is reflected in its multi-paradigm modeling and the use of the MPM4CPS ontology.

Overview

As outlined in more details from a conceptual point of view in (139), the presented CPSLab 19at the Hasso Plattner Institute (HPI) 20 at the University of Potsdam applied, adapted, and evaluated an existing industrial-strength development methodology from the automotive domain [START_REF] Broekman | Testing Embedded Software[END_REF] (see also Figure 6.21) for the robotic system application domain. We therefore evaluated and adapted a component-based approach using an MDE approach supporting the combination of soft and hard real-time behavior.

The resulting methodology for robotic systems supports several development activities such as modeling, simulation, verification/testing at different stages, prototyping and pre-production. The lab supports tools and related libraries in an integrated tool-chain that reflects physical and cyber aspects of distributed robotics systems.

We consider a robot system as depicted in Figure 6. [START_REF] Bause | A Toolbox for Functional and Quantitative Analysis of DEDS[END_REF], where a single robot has the duty to transport pucks as advised by the overall factory automation. The regular behavior of the robot is to move around, transport pucks, or charge its batteries. The behavior must meet strict constraints, such as preventing complete discharge of the batteries and with a lower priority, ensure to transport pucks as requested. It must also perform reasonably well with respect to some soft goals to minimize energy consumption and maximize throughput. For the evaluation of our research activities, we use our CPSLab robot laboratory consisting of three Robotino robots (see Figure 6.24). The robots can be equipped with several sensors (e.g., laser scanner, infrared (IR) distance sensors, GPS-like indoor navigation systems) as well as different actuators (e.g., servo motors, omnidirectional drive, gripper).

Examples

Model-in-the-Loop

In a second step, the model of the control behavior is combined with a MATLAB/Simulink model of the plant by means of a model-in-the-loop (MiL) simulation as shown in Figure 6.26, which uses the feedback provided by the plant model to evaluate that the control behavior is as expected.

Model-in-the-Loop -CPS Ontology

The model in the loop depicted in Figure 6.26 in contrast, the abstract control algorithm from the cyber domain is combined with the idealized physics as present in the plant model and thus we have a simple cyber-physical setting. Here we cover thus the elements CyberPart and PhysicalPart from the CPS ontology for a particular function.

Rapid Prototyping

As the validity of plant models is often only rather limited when it comes to sophisticated aspects of the physical behavior, as an additional step rapid prototyping as depicted in Figure 6.27 is supported. For smaller control behavior, the model of the control behavior is linked to the real robot such that real sensor values with noise and timing constraints of the environment and platform can be covered. However, specific effects of scheduling, the impact of communication interaction and messages, and memory/computation constraints remain uncovered.

For larger scenarios and for the multi robot scenarios a link to a real hardware setup is not feasible here. Instead we employ a model-in-the-loop (MiL) simulation where a complex environment and the communication between the robots can be explored. While this covers the impact of communication interaction and messages, other aspects like real sensor values with noise, specific effects of scheduling and timing/memory/computation constraints are, however, not covered.

Rapid Prototyping -CPS Ontology

The rapid prototyping against the robot as depicted in Figure 6.27, the abstract control algorithm from the cyber domain is brought together with the real physics of the robot and thus we have clearly a cyber-physical setting.

Our rapid prototyping based on a sophisticated robot simulator, again the abstract control algorithm from the cyber domain is brought together with the physics as present in the sophisticated robot model of the simulator and thus we have clearly a cyber-physical setting.

In both cases we cover thus the elements CyberPart from the CPS ontology for a particular function and the elements PhysicalPart from the CPS ontology for the part of the robot relevant for a particular function that is either simulated or considered directly.

Prototyping Stage

The second stage supported is the prototyping stage where the focus changes from models to their implementation in software or hardware and where besides the individual functions also the system architecture is covered. Due to this refined view, in particular discretization effects of the cyber part that are absent in the abstract mathematical models employed in the former stage now become visible. At this stage, less details are ignore resp. simplified as step by step specific effects of scheduling, the impact of communication interaction and messages, and timing/memory/computation constraints are taken into account.

More Detailed Modeling

To consider the more detailed view outlined, at the prototyping stage the models must be refined such that besides the individual functions also the system architecture is defined. As depicted in Figure 6.28, this is done by first defining components and their communication via port types, messages, interfaces, and data types with AUTOSAR and map the beforehand considered functional parts on them. In this step, we also have to map the functionality extending the existing models and where necessary add custom implementation files. In a second step, we then define the overall architecture using AUTOSAR including besides the components and their communication also task specification and the hardware configuration.

As depicted in Figure 6.29, an important element of this refinement is also real-time constraints, e.g. to guarantee safety constraints. A combination of hard and soft real-time aspects at functional as well as architectural levels must be defined including a mapping to hard and soft real-time task with proper levels for the priorities.

Concerning the verification, we employ code generation at the prototyping stage and try to step by step add more and more details of the software and hardware to the picture in the following steps.

Software in the Loop (SiL)

The software-in-the-loop (SiL) simulation at the prototyping stage as depicted in Figure 6.30 requires that code generation is employed to derive code for the functional models and architectural models. In special cases, also additional manually developed code has to be integrated. Then, the code is executed and run against the available simulation of the robot and its environment. As we still do not always use the real hardware, we still ignore resp. simplify elements such as real sensor values with noise and not by the simulator covered timing constraints of the environment or platform, while specific effects of scheduling, the impact of communication interaction and messages, and by the simulator covered timing constraints of the environment or platform, and timing/memory/computation constraints of the software.

Software in the Loop (SiL) -CPS Ontology

The first form of software in the loop (SiL) executing the software on a desktop computer against a simulator features that the detailed control algorithm from the cyber domain is brought together with the physics as present in the sophisticated robot model of the simulator and thus we have clearly a cyber-physical setting.

The second form of software in the loop (SiL) executing the software on a desktop computer against a remote controlled robot ensures that the detailed control algorithm from the cyber domain is brought together with the physics as present in the remote controlled robot and thus we have clearly a cyber-physical setting.

In both cases we cover thus the elements CyberPart from the CPS ontology for the combination of all function and the elements PhysicalPart from the CPS ontology for the whole robot.

Hardware in the Loop (HiL)

By moving on to the lab itself, we can then also consider a hardware-in-the-loop (HiL) simulation at the prototyping stage as sketched in Figure 6.31, where besides the software that is [START_REF] Broekman | Testing Embedded Software[END_REF] generated or integrated also the specific characteristics of the robot hardware and lab environment and its hardware can be experienced.

As we now employ the real hardware, we no longer ignore resp. simplify elements. Therefore, now real sensor values with noise, specific effects of scheduling, the impact of communication interaction and messages, and timing/memory/computation constraints are all considered.

Hardware in the Loop (HiL) -CPS Ontology

The hardware in the loop (HiL) executing the software on the robot depicted in Figure 6.31 ensures that the detailed control algorithm from the cyber domain is brought together with the physics as present in the robot and thus we have clearly a cyber-physical setting.

Thus we cover the elements CyberPart from the CPS ontology for the combination of all function and the elements PhysicalPart from the CPS ontology for the whole robot.

Pre-Production Stage

In our specific setting and due to our focus on the software development, the system test in the pre-production stage is not really different as we do not produce any system we want to sell later. In a commercial setting the robots in the prototyping, the robots in the lab would likely be equipped with more testing hardware or prototypical hardware, while in our lab only one level exists here.

The outlined methodology and tool chain adjusted from the automotive domain, provides suitable guidance due to the different focus in stages and follows where possible an MDE approach where tools and libraries are integrated such that the models drive the development. Only later the code and configuration data automatically generated from the models are employed to consider more details concerning the verification, simulation, and testing. We put special focus on supporting also hard and soft real-time considerations, which are oftentimes ignored in robotic development scenarios.

MPM

For the MPM ontology introduced in Chapter 4, we will in the following use the details of the different development steps to outline how the development is linked to MPM.

Overview

In Figure 6.32 the tool landscape for developing the aforementioned robot CPS is depicted. It consists of MATLAB/Simulink for modeling and simulation, dSPACE SystemDesk for modeling software architecture, hardware configuration, and task mapping, dSPACE TargetLink for code generation and the FESTO Robotino-Library with the FESTO Robotino©Sim simulator.

Examples

Examples

In the following, we outline to which elements of the MPM ontology of Chapter 4 the elements of the megamodel refer and which megamodel fragements cover the scenarios introduced in the last subsection.

Formalism, Languages, Models, and Tools

• Used Language and Models The added elements for the CPSLab ontology outlined in the text are depicted also in Figure 6.33.

Simulation Stage

In the simulation stage we have two development activities: model test and model-in-the loop.

In the following, we will outline how they can be captured with mega-model fragments consisting of model instances and tool applications.

Model Test

The model test introduced in Figure 6.25, is rather trivial as it only employ a single model of the planned control algorithm plus some auxiliary models for test inputs. Then, as depicted in Figure 6. [START_REF] Bures | DEECO: An Ensemble-based Component System[END_REF]

Examples Model-in-the-Loop

In contrast to model test, model-in-the-loop simulation as introduced in Figure 6.26 employed besides a model of the control algorithm also a model of the plant and uses as depicted in Figure 6.37 simulation to explore how well both fit together. The added MegaModel Fragment CPSLabMiLMMF and its elements for the CPSLab ontology outlined in the text are depicted also in Figure 6.38.

Rapid Prototyping

The rapid prototyping as introduced in Figure 6.27 is supported in two forms. At first rapid prototyping can be done employing a sophisticated simulator for the robot as depicted in Figure 6.39. While not necessary exposing the control algorithm to physical reality as far as captured by the sophisticated model of the robot, the simulator already capture much more details than the plan model while still allow to analyze the behavior much easier then in the case of using the real robot.

The second case depicted in Figure 6.40 connects the abstract control algorithm with the real robot and therefore expose the algorithm to all physical effects. However, analysis might be difficult as running the algorithm against the robot is less easy to analyze then when running it against a simulator. • Employed Tool: MATLAB/Stateflow Simulator, FESTO Robotino©Sim

In Figure 6.41, the added MegaModel Fragment CPSLabRPaMMF and its elements for the CP-SLab ontology outlined in the text are presented.

MegaModel Fragment CPSLabRPbMMF

• MegaModelFragment: CPSLabRPbMMF The added MegaModel Fragment CPSLabRPbMMF and its elements for the CPSLab ontology outlined in the text are depicted also in Figure 6.42.

Simulation Stage -MPM Ontology

Some issues are no yet covered by the MPM ontology and the employed megamodel and megamodel fragments: While the same types of models and tools are employed at several stages and activities as visible in the megamodel depicted in Figure 6.34, the models developed for each of these activities are quite different in the simulation stage. For the model test, only simply MATLAB Simulink models with the standard block set and input signals are usually employed. For the model-in-the-loop simulation, both the model of the control behavior and of the related fragment of the plant are modeled and evaluated using MATLAB/Simulink models with the standard block set. To link the behavior to the FESTO Robotino©Sim Simulator and A second form executes the generated software in contrast on a desktop computer and links it to the robot as depicted in Figure 6.44.

Software in the Loop (SiL) -MPM Ontology

MegaModel Fragment CPSLabSiLaMMF

• MegaModelFragment: CPSLabSiLaMMF • Employed Tool: Execution on a Desktop computer, FESTO Robotino©Sim

Examples

The added MegaModel Fragment CPSLabSiLaMMF and its elements for the CPSLab ontology outlined in the text are depicted also in Figure 6.45. The added MegaModel Fragment CPSLabSiLbMMF and its elements for the CPSLab ontology outlined in the text are depicted also in Figure 6.46.

MegaModel Fragment

Hardware in the Loop (HiL)

Hardware in the Loop (HiL) as introducted in Figure 6.31 in contrast links the generated software such that it can be executed on the robot as depicted in Figure 6.47.

Prototyping -MPM Ontology

Again, the MPM ontology and the employed megamodel and megamodel fragments do not cover all issues: In contrast to the restriction to MATLAB/Simulink during the simulation stage, for the prototyping stage also dSPACE SystemDesk for describing a component-based architecture with AUTOSAR must be considered as well as outlined above and depicted in the megamodel presented in Figure 6.34. For the software-in-the-loop simulation, it is necessary to adjust the functional models to the specific dSPACE TargetLink block set such that the dSPACE TargetLink for code generation can be employed. In addition, dSPACE SystemDesk is employed to define the software architecture, hardware configuration, and task mapping with AUTOSAR. Then, this combination of models is linked via the blocks for the FESTO Robotino-Library and simulated by linking the MATLAB/Simulink and FESTO Robotino©Sim simulators and visualize the outcome with FESTO Robotino©View. In case of the hardware-in-the-loop testing, the same block set for the FESTO Robotino-Library can be reconfigured such that either the compiled software runs on a host computer and controls the Robotino robots remotely or the compiled and linked software runs directly on the Robotino robots.

MPM4CPS

In order to discuss the role of MPM for the development CPS as present in the case study, we refer to the inherent integration needs underlying the development of embedded real-time systems and cyber-physical systems in particular as outlined in [START_REF] Giese | Model-Based Integration[END_REF]. Furthermore, we link these observations to the MPM4CPS ontology as presented in Chapter 5 and further needs to extend it.

Examples

as present in the sophisticated robot model (RobotModel) of the simulator and thus we have clearly a cyber-physical setting. We again often have a multi-formalism setting as the control is discrete, while the sophisticated model of the robot simulation is at least conceptually continuous. Consistency is checked via co-simulation as the simulator for the robot model runs in parallel with the sophisticated robot simulator.

The rapid prototyping against the robot as depicted in Figure 6.40 and in its megamodel fragment, the abstract control algorithm from the cyber domain captured by the Matlab/Simulink model (ControlModel) is brought together with the real physics of the robot and thus we have clearly a cyber-physical setting. Consistency is checked via co-simulation as the simulator for the robot model runs in parallel with the robot. The first form of software in the loop (SiL) executing the software on a desktop computer against a simulator as depicted in Figure 6.43 and in its megamodel fragment features that the detailed control algorithm from the cyber domain captured by the Matlab/Simulink and AUTOSAR SystemDesk models (multiple ControlModels and one SystemModel ) are brought together with the physics as present in the sophisticated robot model of the simulator (RobotModel) and thus we have clearly a cyber-physical setting. We again often have a multiformalism setting as the control is discrete while the sophisticated robot mode is at least conceptually continuous. Consistency is checked via co-simulation as the software for the robot control runs in parallel with the sophisticated robot simulator.

The second form of software in the loop (SiL) executing the software on a desktop computer against a remote controlled robot depicted in Figure 6.44 and in its megamodel fragment ensures that the detailed control algorithm from the cyber domain captured by the Matlab/Simulink model and AUTOSAR SystemDesk models (multiple ControlModels and one Sys-temModel ) are brought together with the physics as present in the remote controlled robot and thus we have clearly a cyber-physical setting. Consistency is checked via co-execution as the software for the robot control runs in parallel with the remote controller robot.

Hardware in the Loop (HiL)

The hardware in the loop (HiL) executing the software on the robot depicted in Figure 6.44 and in its megamodel fragment ensures that the detailed control algorithm from the cyber domain aptured by the Matlab/Simulink model (ControlModel) is brought together with the physics as present in the robot and thus we have clearly a cyber-physical setting. Consistency is checked via executing the software on the robot.

Summary

We have demonstrated that the framework introduced in this report is suitable to capture the needs concerning this case study for CPS in form of the extensions of the CPS ontology discussed in Section 6.2.2, covering the needs concerning this case study for MPM in form of the extensions of the MPM ontology and the catalog discussed in Section 6.2.3, and captures the cyber-physical aspects of the development quite well as outlined in Section 6.2.4.

Summary and Future Work

In These examples instantiate the MPM4CPS ontology and also make use of the catalog of languages and tools.

We developed a CPS ontology such that the catalog of languages can be well classified, developed a MPM ontology such that all needs of the example cases for CPS development approaches are covered, and developed a first MPM4CPS ontology that integrate both based on viewpoints. Furthermore, we developed documentation generators that produce detailed specifications from the ontologies.

As future work, we plan to further enrich the CPS ontology, the MPM ontology, and the MPM4CPS ontology as ongoing community effort. Furthermore, we plan to further develop documentation generators such that they can also produce detailed specifications for development environment examples.

1. 1 1 Introduction

 11 Overview of the structure of the MPM4CPS ontology . . . . . . . . . . . . . . . . . 1.2 Common structure of domain analysis methods (adopted from: (131)) . . . . . . 2.1 Overview of the shared ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Feature Model of a CPS representing common and variant properties . . . . . . . 3.2 Basic concepts of CPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Layered view for CPS architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Overview of the CPS ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Overview of the MPM ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Overview of the MPM4CPS ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Service Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Overview of the models provided by DEECo and their relations . . . . . . . . . . . 6.3 IRM tree for a smart parking senario . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Snippet of jDEECo code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 jDEECo runtime framework architecture . . . . . . . . . . . . . . . . . . . . . . . . 6.6 An example with an EDL specification . . . . . . . . . . . . . . . . . . . . . . . . . .6.7 Framework high-level architecture that supports Ensemble Definition Language (EDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 Membership vs. boundary conditions in ensemble formation . . . . . . . . . . . . 6.9 jDEECo integration with MATSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10 jDEECo integration with ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 Illustration of communication groups; each is associated with an instance of SameDestination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12 Example of two well-chosen emergency groups. . . . . . . . . . . . . . . . . . . . . 6.13 Scanning cars (on the right) are sending a photo stream to the edge cloud server reporting spot availability to the parking cars (on the left) . . . . . . . . . . . . . . 6.14 Sample battery energy level during continuous discharge . . . . . . . . . . . . . . 6.15 A visualization of the the area that cleaners should visit and clean . . . . . . . . . 6.16 Intelligent production line: home, proximity, and outer zones . . . . . . . . . . . . 6.17 Entry for the developer A1 to room W1 is rejected due to the presence of the developer B1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.18 The use case illustrates a production area, which has many halls. For each hall, there is a single foreman who manages the workers. . . . . . . . . . . . . . . . . . 6.19 Models and Tools Transformations and integrations . . . . . . . . . . . . . . . . . 6.20 The example of DEECo represented by OntoGraf using Protoge . . . . . . . . . . . 6.21 Overview of the methodology for modeling, verification, and validation employing simulation and testing (see (33)) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.22 Photo of the lab (see (139)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.23 Structural overview of the employed evaluation scenario (see (139)) . . . . . . . . 6.24 Photo of the employed robots (see (139)) . . . . . . . . . . . . . . . . . . . . . . . . 6.25 Overview of the model test in the simulation stage of (33) . . . . . . . . . . . . . . 6.26 Overview of the model in loop simulation in the simulation stage of (33) . . . . . 6.27 Overview of the rapid prototyping in the simulation stage of (33) . . . . . . . . . . 6.28 Overview of the definition of the software architecture in the prototyping stage of (33) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.29 Overview of the mapping of the architecture to tasks and communication in the prototyping stage of (33) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.30 Overview of software-in-the-loop (sil) simulation in the prototyping stage of (33) 6.31 Overview of hardware-in-the-loop (HiL) testing in the prototyping stage of (33) . 6.32 Tool landscape and its relation to the development methdology . . . . . . . . . . 6.33 All MegaModelFragments of the CPSLabMM MegaModel . . . . . . . . . . . . . . 6.34 Overview over the megamodel fragments of the CPSLab megamodel and how the models are related (dashed arrows) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.35 Model Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.36 Part of the ontology for the MegaModelFragment CPSLabMTMMF covering Model Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.37 Model in the Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.38 Part of the ontology for the MegaModelFragment CPSLabMiLMMF covering Model-in-the-Loop (MiL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.39 Rapid Prototyping (RP) with a detailed robot simulation . . . . . . . . . . . . . . . 6.40 Rapid Prototyping (RP) with a remote controlled robot . . . . . . . . . . . . . . . . 6.41 Part of the ontology for the MegaModelFragment CPSLabRPaMMF covering Rapid Prototyping with Robot Simulation . . . . . . . . . . . . . . . . . . . . . . . . 6.42 Part of the ontology for MegaModelFragment CPSLabRPbMMF covering Rapid Prototyping with Robot Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.43 Software in the Loop (SiL) vs. Desktop + Sim . . . . . . . . . . . . . . . . . . . . . . 6.44 Software in the Loop (SiL) vs. Desktop + Robot . . . . . . . . . . . . . . . . . . . . . 6.45 Part of the ontology for the MegaModelFragment CPSLabSiLaMMF covering Sil with Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.46 Part of the ontology for the MegaModelFragment CPSLabSiLbMMF covering Sil with Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.47 Hardware in the Loop (HiL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.48 Part of the ontology for the MegaModelFragment CPSLabHiLMMF covering Hil .This document reports on the Framework to Relate / Combine Modeling Languages and Techniques of Working Group1 on Foundations of the ICT COST Action IC1404 Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS). It first presents an ontology of Cyber Physical Systems in chapter 3 and then an ontology of Multi-Paradigm Modeling in chapter 4. Then, these ontologies are combined to define an ontology of Multi-Paradigm Modeling for Cyber-Physical Systems presented in chapter 5. Finally, a number of megamodel examples are presented in chapter 6 that instantiate the core ontologies and make use of the catalog of languages and tools individuals.

Figure 1 . 1 :

 11 Figure 1.1: Overview of the structure of the MPM4CPS ontology

Figure 1 . 2 :

 12 Figure 1.2: Common structure of domain analysis methods (adopted from: (131))

Figure 2 .

 2 Figure 2.1 shows an overview of the shared ontology. The details of each concept are provided in the following subsections.

Figure 2 . 1 :

 21 Figure 2.1: Overview of the shared ontology

Figure 3 .

 3 Figure 3.4 shows an overview of the CPS ontology. The details of each concept are provided in the following subsections.

4 . 4 )Figure 3 . 2 :Figure 3 . 3 :Figure 3 . 4 :

 44323334 Figure 3.2: Basic concepts of CPS

Figure 4 .

 4 Figure 4.1 shows an overview of the MPM ontology. The details of each concept are provided in the following subsections.

Figure 4 . 1 :

 41 Figure 4.1: Overview of the MPM ontology

Figure 4 .

 4 Figure 4.1 shows an overview of the MPM4CPS ontology. The details of each concept are provided in the following subsections.

Figure 5 . 1 :

 51 Figure 5.1: Overview of the MPM4CPS ontology

3 . 1 )•

 31 ConcernedElement (see section 2.2.4.2) • ViewPoint (see section 5.3.1.2) • ViewPoint (see section 5.3.1.2) • Formalism (see section 4.3.2.6) Ranges: • Language (see section 4.3.3.16) 5.4.13 hasMegamodelFragment It describes the relation between megamodel and its fragments. Subproperty of: • hasModel (see section 5.4It describes a recursive relation. e.g. MegaModelFragment hasModel xModel ... Subproperty ofIt defines a model operation for a model. Subproperty of: • hasModelRelation (see section 5.4It defines a model relation for a model. Subproperty of: None Domains: • Model (see section 4.3.4.8)

Figure 6 . 1 :

 61 Figure 6.1: Service Component

Figure 6 . 2 :

 62 Figure 6.2: Overview of the models provided by DEECo and their relations

Figure 6 . 3 :

 63 Figure 6.3: IRM tree for a smart parking senario

Figure 6 . 4 :

 64 Figure 6.4: Snippet of jDEECo code

Figure 6 . 5 :Figure 6 . 6 :Figure 6 . 7 :

 656667 Figure 6.5: jDEECo runtime framework architecture

Figure 6 . 8 :

 68 Figure 6.8: Membership vs. boundary conditions in ensemble formation

Figure 6 . 9 :Figure 6 .

 696 Figure 6.9: jDEECo integration with MATSim

Figure 6 .

 6 Figure 6.11: Illustration of communication groups; each is associated with an instance of SameDestination

Figure 6 . 12 :

 612 Figure 6.12: Example of two well-chosen emergency groups.

  ) Figure 6.13. The example describes vehicles that detect parking spots and informs other vehicles about it. The used simulation tool is Veins LTE, which is based on OMNeT++ 8 (i.e. network simulator), INET 9 and SimuLTE 10 (i.e. radio simulators), and SUMO 11 (i.e. road traffic simulator).The main concern is performance model that is presented by Queueing Networks (QN), and it is planned to be integrated with DEECo.

Figure 6 . 13 :

 613 Figure 6.13: Scanning cars (on the right) are sending a photo stream to the edge cloud server reporting spot availability to the parking cars (on the left)

  Design time Model and DEECo Runtime Model. The evaluation of statistical functions was done on STM32F4-DISCOVERY board.

Figure 6 . 14 :

 614 Figure 6.14: Sample battery energy level during continuous discharge

Figure 6 . 15 :

 615 Figure 6.15: A visualization of the the area that cleaners should visit and clean

Figure 6 . 16 :

 616 Figure 6.16: Intelligent production line: home, proximity, and outer zones

Figure 6 . 17 :

 617 Figure 6.17: Entry for the developer A1 to room W1 is rejected due to the presence of the developer B1

2 MPM

 2 In this part, the individuals includes a DEECo megamodel and its fragments defining all model operations supported by DEECo as outlined in Figure6.2 and Figure 6.20. Model operations are of different kinds such as transformation and integrations operations. The first model operation is the capture of requirements followed by a transformation operation from the requirements model into a design model, then by an instantiation operation to create runtime model and simulation model. The runtime model integrates with the self-adaptation model Figure 6.19.Formalism, Models, and Tools• FormalismAutomataBasedFormalism: LTS (Labeled Transition System)

Figure 6 . 19 :Figure 6 . 20 :

 619620 Figure 6.19: Models and Tools Transformations and integrations

Figure 6 .STFigure 6 . 21 :Figure 6 . 22 :

 6621622 Figure 6.23 depicts a structural overview of the robot system. The whole cyber-physical evaluation scenario consists of four different rooms. In the first room, the pucks are packed and dropped for transportation in area A P . A robot R P transports the puck to a second room and drops it within the sorting area A S . Based on the current delivery status, the robot R S chooses

Figure 6 . 27 :

 627 Figure 6.27: Overview of the rapid prototyping in the simulation stage of[START_REF] Broekman | Testing Embedded Software[END_REF]

Figure 6 . 28 :

 628 Figure 6.28: Overview of the definition of the software architecture in the prototyping stage of[START_REF] Broekman | Testing Embedded Software[END_REF]

Figure 6 . 29 :Figure 6 . 30 :

 629630 Figure 6.29: Overview of the mapping of the architecture to tasks and communication in the prototyping stage of[START_REF] Broekman | Testing Embedded Software[END_REF]

Figure 6 . 31 :

 631 Figure 6.31: Overview of hardware-in-the-loop (HiL) testing in the prototyping stage of[START_REF] Broekman | Testing Embedded Software[END_REF]

Figure 6 . 32 :

 632 Figure 6.32: Tool landscape and its relation to the development methdology

Figure 6 . 33 :

 633 Figure 6.33: All MegaModelFragments of the CPSLabMM MegaModel

Figure 6 . 34 :

 634 Figure 6.34: Overview over the megamodel fragments of the CPSLab megamodel and how the models are related (dashed arrows)

Figure 6 . 37 :

 637 Figure 6.37: Model in the Loop

Figure 6 . 38 :Figure 6 . 39 :Figure 6 . 40 :

 638639640 Figure 6.38: Part of the ontology for the MegaModelFragment CPSLabMiLMMF covering Model-in-the-Loop (MiL)

Figure 6 . 41 :

 641 Figure 6.41: Part of the ontology for the MegaModelFragment CPSLabRPaMMF covering Rapid Prototyping with Robot Simulation

Figure 6 . 42 :

 642 Figure 6.42: Part of the ontology for MegaModelFragment CPSLabRPbMMF covering Rapid Prototyping with Robot Execution

Figure 6 . 43 :

 643 Figure 6.43: Software in the Loop (SiL) vs. Desktop + Sim

Figure 6 . 44 :

 644 Figure 6.44: Software in the Loop (SiL) vs. Desktop + Robot

Figure 6 . 45 :

 645 Figure 6.45: Part of the ontology for the MegaModelFragment CPSLabSiLaMMF covering Sil with Simulation

Figure 6 . 46 :Figure 6 . 47 :

 646647 Figure 6.46: Part of the ontology for the MegaModelFragment CPSLabSiLbMMF covering Sil with Execution

  this report on the Framework to Relate / Combine Modeling Languages and Techniques of Working Group1 on Foundations of the ICT COST Action IC1404 Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS), we first presented an ontology of Cyber Physical Systems in Chapter 3 and then an ontology of Multi-Paradigm Modeling in Chapter 4. Then, we presented an MPM4CPS ontology that combine these ontologies to cover Multi-Paradigm Modeling for Cyber Physical Systems presented in Chapter 5. Finally, we presented two examples for CPS development cases and sketched how they fit into our framework and how their megamodels resp. megamodel fragments covering development scenarios look like in Chapter 6.

•

  HybridAutomataBasedFormalism (see section 4.3.2.9)

4.3.2.14 TimedCharacteristic Subclass of

	• BehavioralCharacteristic (see section 4.3.2.2)
	4.3.2.15 UncertaintyCharacteristic
	Subclass of
	• BehavioralCharacteristic (see section 4.3.2.2)

  the model of the control algorithm is simulated by employing the test inputs.

	Model Test -MPM Ontology
	MegaModel Fragment CPSLabMTMMF
	• MegaModelFragment: CPSLabMTMMF
	• Model(s):

ControlModel Tools / Models Operations of CPSLabMiLMMF • ModelOperation: One Shot Simulation • Input Model(s): ControlModel, Input data (entered with MATLAB/Stateflow Simulator) • Output Model(s): Output data (visualized with MATLAB/Stateflow Simulator)

ControlModel Tools / Models Operations of CPSLabRPbMMF

  ControlModel• Output Model(s): Output data (visualized with MATLAB/Stateflow Simulator and/or observed)• Employed Tool: MATLAB/Stateflow Simulator, Remote execution on a Robotino Robot

• Model(s):

• ModelOperation: Rapid Prototyping with Robot Execution • Input Model(s):

Ontology of Cyber-Physical Systems Figure 3.1: Feature Model of a CPS representing common and variant properties

We use * to distinguish this existing language and tool from the generic Global Model Management (GMM) acronym.

http://www.ascens-ist.eu/

http://www.allow-ensembles.eu/

http://www.focas.eu/

http://d3s.mff.cuni.cz/software/deeco/files/seams-2017.zip or http://dx.doi. org/10.4230/DARTS.3.1.6

http://d3s.mff.cuni.cz/projects/components_and_services/deeco/files/CDEECo. zip 52

http://github.com/d3scomp/tcof

https://matsim.org

https://www.omnetpp.org

https://inet.omnetpp.org

http://simulte.com

http://sumo.dlr.de

https://www.valuestreamer.de/en/home/

https://www.palladio-simulator.com/science/palladio_component_model/

Acknowledgements: We thank Sebastian Wätzoldt, Stefan Neumann, Joachim Hänsel, and Falk Benke for their contributions to the lab described in this section and their contribution to the presented content and figures.

http://www.cpslab.de

http://www.hpi.de

system, organized in a way that supports reasoning about the structures and behaviors of the system.

Subclass of

• FormalSemantics (see section 4.3.3.14)

Behavioral

Subclass of

• Architecture (see section 4.3.3.2)

BehavioralConstraintLanguage

Subclass of

• ConstraintLanguage (see section 4.3.3.9)

Centralized

Subclass of

• Deployment (see section 4.3.3.10)

Communication

Communication is the act of conveying intended meanings from one entity or group to another through the use of mutually understood signs and semiotic rules.

Subclass of

• Behavioral (see section 4.3.3.4)

ConstraintLanguage

Subclass of

• FormalLanguage (see section 4.3.3.13)

Deployment

The deployment of a mechanical device, electrical system, computer program, etc., is its assembly or transformation from a packaged form to an operational working state. Deployment implies moving a product from a temporary or development state to a permanent or desired state.

Subclass of

• FormalSemantics (see section 4.3.3.14)

Distributed

Subclass of

• Deployment (see section 4.3.3.10)

FormalLanguage

A formal language is a language whose semantics is formally defined. This formal semantics relates to the formalism(s) the language realizes. A formal language has its abstract syntax formally defined.

Subclass of

• FormalDC (see section 4.3.1)

• Language (see section 4.3.3.16)

• TODO Moussa

FormalSemantics

In programming language theory, semantics is the field concerned with the rigorous mathematical study of the meaning of programming languages. It does so by evaluating the meaning of syntactically legal strings defined by a specific programming language, showing the computation involved. In such a case that the evaluation would be of syntactically illegal strings, the result would be non-computation. Semantics describes the processes a computer follows when executing a program in that specific language. This can be shown by describing the relationship between the input and output of a program, or an explanation of how the program will execute on a certain platform, hence creating a model of computation.

Subclass of

Structural

Structure is an arrangement and organization of interrelated elements in a material object or system, or the object or system so organized.

Subclass of

• Architecture (see section 4.3.3.2)

StructuralConstraintLanguage

Subclass of

• ConstraintLanguage (see section 4.3.3.9)

FormalismDC

This class groups classes related to formalisms

AutomataBasedFormalism

The class of formalisms that are based on automata

Subclass of

• Formalism (see section 4.3.2.6)

BehavioralCharacteristic

Subclass of

• FormalismCharacteristic (see section 4.3.2.7)

ContinuousCharacteristic

Subclass of

• BehavioralCharacteristic (see section 4.3.2.2)

DiscreteCharacteristic

Subclass of

• BehavioralCharacteristic (see section 4.3.2.2)

FlowBasedFormalism

Subclass of

• Formalism (see section 4.3.2.6)

Formalism

Formalisms are mathematical objects consisting of an abstract syntax and a formal semantics. Languages are concrete implementations of formalisms. A language has a concrete syntax, may deviate slightly from the formalism in the semantics that it implements, or may implement multiple semantics (e.g., changing the type of numerical solver in a simulation tool may change the behavior of a model). Also, a language may implement more than one formalisms.

Subclass of

PetriNetBasedFormalism

Petri nets (also known as a place/transition net or P/T net) are formalisms for the description of distributed systems.

Subclass of

• Formalism (see section 4.3.2.6)

StructureCharacteristic

Subclass of

• FormalismCharacteristic (see section 4.3.2.7)

TimedAutomataBasedFormalism

Subclass of standard of The Open Group), DEMO, ABACUS (developed by the University of Technology, Sydney). These languages do not necessarily refer to software components, etc. Most of them, however, refer to an application architecture as the architecture that is communicated to the software engineers.

Most of the writing below refers primarily to the perspective from the software engineering community.

Subclass of

Communication

Communication is the act of conveying intended meanings from one entity or group to another through the use of mutually understood signs and semiotic rules.

Subclass of

Deployment

The deployment of a mechanical device, electrical system, computer program, etc., is its assembly or transformation from a packaged form to an operational working state. Deployment implies moving a product from a temporary or development state to a permanent or desired state.

Subclass of

DomainSpecificLanguage

A domain-specific language (DSL) is a computer language specialized to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains.

Subclass of

• Language (see section 4.3.3.16)

FormalLanguage

A formal language is a language whose semantics is formally defined. This formal semantics relates to the formalism(s) the language realizes. A formal language has its abstract syntax formally defined.

Subclass of

• FormalDC (see section 4.3.1)

• Language (see section 4.3.3.16)

• TODO Moussa

FormalSemantics

In programming language theory, semantics is the field concerned with the rigorous mathematical study of the meaning of programming languages. It does so by evaluating the meaning of syntactically legal strings defined by a specific programming language, showing the computation involved. In such a case that the evaluation would be of syntactically illegal strings, the result would be non-computation. Semantics describes the processes a computer follows when executing a program in that specific language. This can be shown by describing the relationship between the input and output of a program, or an explanation of how the program will execute on a certain platform, hence creating a model of computation.

Subclass of

• FormalDC (see section 4.3.1)

• Semantics (see section 4.3.3.19)

Graphical

Subclass of

• ConcreteSyntax (see section 4.3.3.8)

Language

A language is a concrete realization of a set of formalisms. A language has a set of concrete syntaxes. The language may deviate slightly from the formalisms it realizes in the semantics that it realizes, or may realize multiple semantics.

Subclass of

• LinguisticDC (see section 4.3.3) References •

ModelingLanguage

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

Subclass of

• Language (see section 4.3.3.16)

• ModelingDC (see section 4.3.4)

ProgrammingLanguages

A programming language is a formal computer language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs to control the behavior of a machine or to express algorithms.

Subclass of

• Language (see section 4.3.3.16)

Semantics

Semantics (from Ancient Greek: "significant") is primarily the linguistic, and also philosophical study of meaning in language, programming languages, formal logics, and semiotics. It focuses on the relationship between signifiers-like words, phrases, signs, and symbols-and what they stand for, their denotation.

Subclass of

• LinguisticDC (see section 4.3.3)

Structural

Structure is an arrangement and organization of interrelated elements in a material object or system, or the object or system so organized.

Subclass of

ConfigurationMegaModel

Declares types for the models and relations contained in application megamodel. (language and relation types)

Subclass of

• Megamodel (see section 4.3.4.6)

IntegrationOperation

The process to integrate many models together.

Subclass of

• ModelOperation (see section 4.3.4.10)

Megamodel

A model that contains models and relations between them.

Subclass of

• Model (see section 4.3.4.8)

MegamodelFragment

The fragment is not a complete megamodel, and can't be used alone. It can be reused to take part in another megamodel. (e.g. physical part, view of the system, self-adaptation .... etc.)

Subclass of

• Model (see section 4.3.4.8)

Model

A representation of real artifacts regardless of the metamodeling technical space. e.g. xml file, equations...etc.

Subclass of

• ModelingDC (see section 4.3.4)

ModelConstraint

A restriction over model that is input or output for relation

Subclass of

• ModelingDC (see section 4.3.4)

• Constraint (see section 2.2.3.1)

ModelOperation

It is any kind of transformation from input set of models to output set of models.

Subclass of

• ModelRelation (see section 4.3.4.11)

• Action (see section 2.2.2.1)

ModelRelation

A relation that connects models. • Activity (see section 2.2.2.2)

ModelingLanguage

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

Subclass of

• Language (see section 4.3.3.16)

• ModelingDC (see section 4.3.4)

ModelingParadigm

Subclass of

• ModelingDC (see section 4.3.4)

ModelingTool

Tools to model the system.

Subclass of

• ModelingDC (see section 4.3.4)

• Tool (see section 2.2.5.1)

TracabilityRelation

Subclass of

• ModelOperation (see section 4.3.4.10)

TransformationOperation

The process to transform one model to another.

Subclass of

• ModelOperation (see section 4.3.4.10)

Properties

Properties

hasActions

Subproperty of: None Domains:

• Activity (see section 2.2.2.2) Ranges:

• Action (see section 2.2.2.1)

hasActivities

Subproperty of: None Domains:

• Process (see section 2.2.2.3) Ranges:

• Activity (see section 2.2.2.2)

hasCharacteristic

Subproperty of: None Domains:

• Formalism (see section 4.3.2.6) Ranges:

• FormalismCharacteristic (see section 4.3.2.7)

hasChildFormalism

Subproperty of: None Domains:

• FormalismFamily (see section 4.3.2.8) Ranges:

• Formalism (see section 4.3.2.6)

hasChildLanguage

Subproperty of: None Domains:

• Language (see section 4.3.3.16) Ranges:

• Language (see section 4.3.3.16)

hasConcerns

A concern of stakeholder. Subproperty of: None Domains:

• ConcernedElement (see section 2.2.4.2) Ranges:

• Concern (see section 2.2.4.1)

hasConstraint

A constraint applied on relation. Subproperty of: None Domains:

• Relation (see section 2.2.3.2) Ranges:

• Constraint (see section 2.2.3.1)

hasContext

hasLanguage

The relation defines the formal language for a formalism. It is an inverse of hasFormalism. Subproperty of: None Domains: Ranges:

• ModelRelation (see section 4.3.4.11)

hasNext

Subproperty of: None Domains:

• Action (see section 2.2.2.1) Ranges:

• Action (see section 2.2.2.1)

hasOutput

The model provides results in the following form. Subproperty of:

• isConnecting (see section 5

hasRole

A role of stakeholder Subproperty of: None Domains:

• Stakeholder (see section 2.2.4.6) Ranges:

• exactly 1 Role (see section 2.2.4.5)

hasStakeholders

Subproperty of: None Domains:

• ViewPoint (see section 5.3.1.2) Ranges:

• Stakeholder (see section 2.2.4.6)

hasSubFormalismFamily

Subproperty of: None Domains:

• FormalismFamily (see section 4.3.2.8) Ranges:

• FormalismFamily (see section 4.3.2.8)

hasSystemPart

Subproperty of: None Domains:

• ViewPoint (see section 5.3.1.2) Ranges:

• SystemPart (see section 3.4.4.3)

hasTool

The tool that represent the Language. It is an inverse of isToolFor. Subproperty of: None Domains:

• Language (see section 4.3.3.16) Ranges:

• Tool (see section 2.2.5.1)

hasViewpoint

Subproperty of: None Domains:

• View (see section 5.3.1.1) Ranges:

• ViewPoint (see section 5.3.1.2)

isAppliedTo

A constraint is applied to a some element. (e.g. relation) Subproperty of: None Domains:

• Constraint (see section 2.2.3.1) Ranges: None

isAppliedToModel

Subproperty of:

• isAppliedTo (see section 5.4.30) Domains:

• Constraint (see section 2.2.3.1) Ranges:

• Model (see section 4.3.4.8)

isBasedOnFormalism

The relation defines the formalism for a formal language. It is an inverse of hasLanguage. Subproperty of: None Domains:

• Language (see section 4.3.3.16) Ranges:

• Formalism (see section 4.3.2.6)

isCharacterizedBy

Subproperty of: None Domains:

• ViewPoint (see section 5.3.1.2) Ranges:

• Concern (see section 2.2.4.1)

isConnecting

A relation connects a model. Subproperty of: None Domains:

• ModelOperation (see section 4.3.4.10) Ranges:

• Model (see section 4.3.4.8)

isExtending

This property captures a language extensions. Typically, a language extends another one by adding constructs and possibly refining / overriding some ot the extended language. Subproperty of: None Domains:

• Language (see section 4.3.3.16) Ranges:

• Language (see section 4.3.3.16)

isExtendingFormalism

Subproperty of: None Domains:

• Formalism (see section 4.3.2.6) Ranges:

• Formalism (see section 4.3.2.6)

isPerformedBy

isSpecializing

Subproperty of: None Domains:

• Formalism (see section 4.3.2.6) Ranges:

• Formalism (see section 4.3.2.6)

isSupportedBy

Subproperty of: None Domains:

• ViewPoint (see section 5.3.1.2) Ranges:

• Formalism (see section 4.3.2.6)

isToolFor

The language that is represented by a tool. It is an inverse of hasTool. Subproperty of: None Domains:

• Tool (see section 2.2.5.1) Ranges:

• Language (see section 4.3.3.16) The general idea of our evaluation scenario is the realization of a variable production setting, where robots can transport small pucks (representing goods in a production system) to different locations. The robots must fulfill different requirements, e.g., they must provide basic functionality like moving and avoiding obstacles in hard real-time (reacting on obstacles within a few milliseconds). Further, the robots must achieve high level goals, e.g., energy saving of the battery, short routing to the destination points and optimizing the throughput while transporting the pucks. While basic functionalities, such as obstacle avoidance,must be realized in hard real-time, we use existing libraries to realize higher functionalities such as path planning or creating a map by evaluating measured distance values. The latter can rarely be realized under hard real-time constraints because of insufficient libraries. Furthermore, we run a RTAI Linux operating system on the robot to enable hard real-time execution.

Examples

CPS

In the following, we will use the details of the different development steps to outline how the development is linked to CPS and the concepts of the CPS ontology introduced in Chapter 3.

Simulation Stage

The first step of the development process of Figure 6.21 is a simulation stage that focus on the model development resp. functional development for the employed control laws. At this stage, many details resulting from the physical and cyber parts of the system are ignore resp. simplified such as real sensor values with noise, specific effects of scheduling, the impact of communication interaction and messages, and timing/memory/computation constraints.

Model Test

In a first activity named model test (MT) (see Figure 6.25), a so-called one-way/one-shot simulation with MATLAB/Simulink is supported where the model of the control behavior can be stimulated by inputs to see that they react properly. This provides some confidence that the setup control behavior works as intended.

Model Test -CPS Ontology

In the model test as outlined in Figure 6.25, the abstract control algorithm from the cyber domain for a specific function is confronted with the physics as present in the input data plus expected outcomes relevant for the function and thus we have a very simple cyber-physical setting. Thus we cover the elements CyberPart from the CPS ontology for a particular function.

Model Test

In the model test as outlined in Figure 6.35 and in its megamodel fragment, the abstract control algorithm from the cyber domain captured by the Matlab/Simulink model (ControlModel) for the control is confronted with the physics as present in the input data plus expected outcomes and thus we have a very simple cyber-physical setting. We further often have a multi-formalism setting as the control is discrete while the input is at least conceptually continuous.

Model-in-the-Loop

The model in the loop depicted in Figure 6.37 and in its megamodel fragment in contrast, the abstract control algorithm from the cyber domain captured by the Matlab/Simulink model (ControlModel) is combined with the idealized physics as present in the plant captured by the Matlab/Simulink model (PlantModel) and thus we have a simple cyber-physical setting. We again often have a multi-formalism setting as the control is discrete while the input is at least conceptually continuous.

Rapid Prototyping

Our rapid prototyping based on a sophisticated robot simulator as depicted in Figure 6.39 and in its megamodel fragment, again the abstract control algorithm from the cyber domain captured by the Matlab/Simulink model (ControlModel) is brought together with the physics