Proceedings of the 4th Workshop of the MPM4CPS COST Action

COST Action IC1404: Multi-Paradigm Modelling for Cyber-Physical Systems http://www.mpm4cps.eu/ Proceedings of the 4th Workshop of the MPM4CPS COST Action September 15-16, 2016  Gdańsk, Poland Hans Vangheluwe, Vasco Amaral, Holger Giese, Jan Broenink, Bernhard Schätz, Alexander Norta, Paulo Carreira, Miguel Goulão, Antonio Vallecillo, Tanja Mayerhofer (Eds.) Technical Report No. ITI16/01 Departamentos Lenguajes y Ciencias de la Computación Universidad de Málaga Copyright © 2016 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. Editors: Hans Vangheluwe University of Antwerp (Belgium) Vasco Amaral Universidade Nova de Lisboa (Portugal) Holger Giese Hasso-Plattner-Institut für Softwaresystemtechnik GmbH (Germany) Jan Broenink University of Twente (Netherlands) Bernhard Schätz fortiss GmbH (Germany) Alexander Norta Tallinn University of Technology (Estonia) Paulo Carreira Universidade de Lisboa (Portugal) Miguel Goulão Universidade Nova de Lisboa (Portugal) Antonio Vallecillo Universidad de Málaga (Spain) Tanja Mayerhofer TU Wien (Austria) Table of Contents Preface............................................................................ I Papers Model-Driven Technical Space Integration Based on a Mapping Approach . . . . . . . . . . . . . . 1–43 Vladimir Dimitrieski, Slavica Kordi´c, Milan ˇ Celikovi´c, Ivan Lukovi´c Several Issues on Composition of Cyber-Physical Systems Based on Principles of the TwoHemisphereModelling ............................................................. 44–55 Oksana Nikiforova, Nisrine El Marzouki, Nadezda Kunicina, Hans Vangheluwe, Florin Leon, Mauro Iacono, Rima Al-Ali, Priscill Orue Consistency and Uncertainty in the Development of Cyber-Physical Systems . . . . . . . . . . . . 56–61 Antonio Cicchetti Presentations Multi-Paradigm Aspects of Component Ensembles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62–66 Tomas Bures Statistical Approach to Architecture Modes in Smart Cyber Physical Systems .......................................................................... 67–73 Tomas Bures, Petr Hnetynka, Jan Kofron, Rima Al-Ali, Dominik Skoda Ontological Reasoning as an Enabler of Contract-Based Co-Design . . . . . . . . . . . . . . . . . . . . . 74–83 Ken Vanherpen, Joachim Denil, Istvón Dóvid, Paul De Meulenaere, Pieter J. Mosterman, Martin Törngren, Ahsan Qamar, Hans Vangheluwe Verification of Domain-Specific Models with ProMoBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84–89 Bart Meyers Semantic-Aided Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90–94 Željko Vukovi´c, Nikola Milanovi´c OnInteroperabilityofIoTPlatforms................................................. 95–104 Marcin Paprzycki Several Issues for Modelling, Implementation and Control of Cyber-Physical Systems . . . . 105–120 Oksana Nikiforova, Andrejs Romanovs, Nadezhda Kunicina, Anatolijs Zabasta Preface In virtually any area of human activity, Cyber-Physical Systems (CPS) are emerging. CPS are truly complex, designed systems that integrate physical, software and network aspects. To date, no unifying theory and no systematic design methods, techniques and tools exist for such systems. Individual mechanical, electrical, network or software engineering disciplines only offer partial solutions. Multiparadigm Modelling (MPM) proposes to model every part and aspect of a system explicitly, at the most appropriate level(s) of abstraction, using the most appropriate modelling formalism(s). Modelling language engineering, including model transformations, and the study of their semantics, are used to realize MPM. MPM is seen as an effective answer to the challenges of designing CPS. The COST Action IC1404: Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS) aims to promote foundations, techniques and tools for multi-paradigm modelling for cyber-physical systems, and to provide educational resources to both academia and industry. This will be achieved by bringing together and disseminating knowledge and experiments on CPS problems and MPM solutions. This workshop was the fourth workshop held in the context of this COST Action. It was held co-located with the Federated Conference on Computer Science and Information Systems 2016 (FedCSIS) on September 15-16 in Gda´ nsk, Poland. The program comprised presentations of MPM4CPS COST Action members discussing their work on foundations, techniques and applications of MPM4CPS, as well as joint work meetings. These proceedings collect the presentations given at the workshop, as well as selected papers detailing the presented work. Please note that the collected papers represent non peer-reviewed work in progress carried out by the COST Action members in the area of MPM4CPS. The presentations and papers collected in these proceedings cover many different aspects of multiparadigm modelling for cyber-physical systems including, but not limited to – tools and techniques in MPM4CPS including –system architecture modelling, –system integration, –system composition and decomposition, –system verification, – classifications of formalisms and – industrial practices and ecosystems. We would like to thank the presenters and paper authors contributing their work to this COST Action. Furthermore, we would like to thank Maria Ganzha and Marcin Paprzycki for organizing the workshop in Gda´ nsk, as well as the Polish Information Processing Society and the IEEE Poland Section Chapter of the Computer Society for their support. November 2016 I Model-Driven Technical Space Integration Based on a Mapping Approach Vladimir Dimitrieski, Slavica Kordi´c, Milan ˇ Celikovi´c, and Ivan Lukovi´c University of Novi Sad, Faculty of Technical Sciences, Trg Dositeja Obradovi´ca 6, 21000 Novi Sad, Serbia {dimitrieski,slavica,milancel,ivan}@uns.ac.rs Abstract. In this report we propose a research with a goal to create a “smart” integration approach and tools that will alleviate integration problems that currently exist in the domain of Industry 4.0. First, the main building blocks of Industry 4.0 and Cyber-Physical Systems are described. Next, the main motivation and goals behind the proposed research are introduced along with a presentation of possible real-world applications. In addition to the research proposal, we also present a detailed literature analysis on the topics of schema matching, mapping and ontology alignment that are closely related to the domain of data and device integration. Keywords: Integration, Mapping, Model-Driven, Technical Space, Domain Specific Language, Cyber-Physical Systems 1 Introduction In this report we propose a research that aims to provide a solution or at least alleviate integration problems that currently exist in the domain of Industry 4.0. In order to understand these problems and their repercussions, we need to present current manufacturing trends, such as Industry 4.0, and put them into a historical context. Afterward, we present main Industry 4.0 components with the emphasis on manufacture automation and how it relies on the integration of these components. Manufacturing has been the driving factor behind the development of human race since its inception. The manufacture of things for a specific use began with the production of basic necessities and household items well before 4000 B.C. [79]. The end products were simple as well as the manufacturing process that usually utilized basic materials such as wood, stone, or metal. Over the following centuries, the manufacturing process gradually improved and these simple production steps steadily began to develop into better and more complex operations. Although the manufacturing process developed at a more or less steady pace over the course of history, several sudden and significant paradigm changes happened when the whole process was greatly influenced by new inventions. These 1 sudden shifts or improvements of the process are known as “industrial revolutions” (Figure 1). The trigger for the first industrial revolution was the invention of the steam engine by James Watt in 1784. A domination of manual labor was disrupted by the increasing mechanization which generated greater output of the produced goods and increased their quality by mitigating human errors and shortening time needed for products to reach its consumers. The subsequent revolutions were also caused by inventions that allowed even greater degree of automation in the manufacturing process. In the 1870’s, the electrical energy and the introduction of the assembly line paved the way for mass production of goods. In 1969, the first programmable logic controller (PLC) was created and the digitalization began to infiltrate the manufacturing process as well as all other aspects of life. Such a widespread digitalization provided means for better and smarter machines with the aim to slowly decrease human participation in the manufacturing process. However, machines still had to be operated by humans and, as such, were not fully independent and self-adjustable to variations in the manufacturing processes. In the resent years, a new paradigm shift is happening and it is enabled by the advances in digitalization. The shift is dubbed the 4th industrial revolution or Industry 4.0 in short. Industry 4.0 promises to improve operational effectiveness, develop entirely new “smart” services and products, as well as new business models [77]. The term Industry 4.0 (ger. Industrie 4.0), was coined in 2011 when Kagermann et al. promoted ideas on how to strengthen the competitiveness of German manufacturing industry [78]. The term has been later used in “High-Tech Strategy 2020” initiative of the German Government and has become eponym for all high-tech projects to be implemented by the 2020. Fig. 1. Industrial revolutions (source [106]) 2 The term Industry 4.0 has been coined in Germany and its main stakeholders come from this country. Outside of Germany, similar ideas and vision may be found under the names Industrial Internet and Advanced Manufacturing [45,68]. The Industrial Internet, also called Industrial Internet of Things (IIoT), has been introduced by General Electric (GE) [60], and later put under supervision of Industrial Internet Consortium (IIC) where GE was joined by many private companies and academic institutions around the world making the IIoT a global movement. Both Industry 4.0 and IIoT encompass the same vision where machinery, people, and analytic are tightly tied together. However, unlike Industry 4.0 which focuses on manufacturing processes, the IIoT stretches beyond manufacturing and enters the sectors such as energy, transportation, healthcare, and agriculture [26]. A part of the IIoT that only focuses on the manufacturing sector was named Advanced Manufacturing in [89]. 1.1 A Brief Overview of Industry 4.0 The idea of smart products and smart machines in the context of manufacturing is not new. Computer Integrated Manufacturing (CIM) was a vision of 1980’s, where the complex, state-of-the-art computers were introduced in factories with a goal to fully automate the production and solve cost and product quality problems that were very pronounced in the manufacturing process [64,156]. The vision of human-less factories soon was shattered by reality in which CIM systems were extremely complex in planning as well as in construction, operation, and maintenance [164]. The technologies were not yet mature and the humans were overworked. However, the vision of fully automated and computer-centered manufacturing continued to live and evolve through the evolution of technology. The focus started to move away from big, clunky super computers that drive the production, to smart, independent computers embedded into every aspect of the manufacturing process. The basics of the omnipresent technology idea were introduced by Weiser [159] in 1991. He envisioned the world of ubiquitous computers in which computers are “weaved into the fabric of everyday life until they are indistinguishable from it”. Weiser, and later Poslad in [125], stated that one of the main requirements for adoption of ubiquitous computers is that they are context-aware. Context-aware computers are able to provide up-to-date and relevant information about the environment and state they are in. As it often happens with the technology, what was tested in everyday life once it reaches a mature state is introduced in the manufacturing process if it can improve it. Therefore, once the appropriate level of computer maturity was reached, ubiquitous computing slowly emerged as a main element of modern manufacturing process and currently is one of the main enablers of Industry 4.0. Industry 4.0 is driven by the Internet, increasing number of connected devices, and future-oriented technologies for the implementation of smart machines and products. More than ever before, fast development cycles, flexibility, resource efficiency, decentralization of production, and individualization on demand are in the spotlight of the manufacturing [50,90]. Market has changed and companies not only have to be the first to the market with their own product but they 3 Apart from Introduction and Conclusion, the report is organized in three sections. In Section 2 we present a description of the proposed research, while in Section 3 we present possible applications of the proposed research results. The overview of the current state-of-the-art solutions and research work is given in Section 4. The proposed research project will be partially implemented as a part of COST Action IC1404: Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS) 1. Although our focus is just on a small part of the CPS domain, mainly on integration of devices and information systems, we feel that the integration is one of the main enablers of future CPS-based systems. To be more specific, the goals and activities of the proposed research align best with goals and activities of the MPM4CPS Work Group 2 (WG2). The compatibility can be seen as follows: –WG2 - Activity 1: “Investigate current standards and best practices (modelling languages, interfaces for interoperability, processes, ...) used in CPS”, is already addressed in this initial report in Section 4. –WG2 - Activity 2: “Survey state-of-the art on MPM tools and techniques used in different disciplines for CPS development including an efficiency evaluation of MPM tools and techniques on CPS”, is one of the main tasks to be performed as a part of the research project presented in this report. The initial specification of such a tool survey can be seen in Subsection 2.3 and Subsection 4.5. –WG2 - Activity 3: “Investigate requirements for future MPM4CPS modelling tools and techniques” will be performed as a first step in our endeavor to create a “smart” CPS integration approach (technique) and the appropriate tooling support (tool). 2 Description of the Research In this section we propose a research aimed at specifying an approach to technical space (TS) integration with a main goal to mitigate heterogeneity problems that currently exist in the integration domain. Although there are many possibilities and methodologies to choose from, for the specification of the integration approach we plan to follow Model-Driven Software Development (MDSD) principles. MDSD-based approaches are usually centered around a language that is specific to a certain domain of application (Domain Specific Language, DSL). In this research we are focusing on the domain of TS integration. Several well known benefits of MDSD-based and DSL-centric approaches are: (i) better expressiveness of the approach in the given domain which directly leads to a significant increase in productivity [80], (ii) the approach can be learned and used easier by users from the domain [84], and (iii) the approach would offer a possibility for analysis, verification, optimization, parallelization, and transformation in the terms of domain specific constructs [109]. 1http://mpm4cps.eu/ 10 The notions of MDSD and DSLs and their main characteristics are introduced in the Subsection 2.1, while in Subsection 2.2 we provide further argumentation on why the MDSD is a viable choice when developing an integration approach between TSs. In Subsection 2.2 we also present the goals, hypotheses, and expected results of the proposed research. We provide an overview of the research methodology in Subsection 2.3. 2.1 Research Topic and Basic Terminology The main topic of the proposed research is the creation of a framework for the integration of TSs based on the main principles of the MDSD approach. In MDSD, models are considered as the first class entities and they are central artifacts of the software development process. Models are mentally created by the means of mental mapping and reduction in which real world entities are identified, grouped together, generalized, and stripped of properties that are irrelevant for a particular use case. Once a mental model is created, modeling languages are needed to provide the appropriate notation for representing these models. Often, developers of a modeling language create the notation in such a way as to provide domain experts, i. e., modelers, visually and semantically familiar concepts from the domain being modeled. Development of a modeling language requires identification of domain concepts that will be mapped to appropriate language concepts and provided a visual or textual notation. Modeling languages are developed and used according to the MDSD four-level conjecture [15,32]. The levels are defined according to the degree of abstraction they imply, starting from the lowest. At the bottom level (L0), the real world system exists in which the observed physical entities reside. A model of the system is created by the means of an appropriate modeling language, and it resides at the next level (L1). Model contains a virtual representation of the observed system entities with only relevant information about each particular entity. The creation of a modeling language requires that the real system is observed, but instead of focusing on each system entity, different types of entities are identified together with the necessary properties and relationships between them. Specification of entity types, properties, and relationships is called a metamodel which resides at the next level (L2) of MDSD conjecture. To create a model, concrete entities are instantiated according to a type, and properties are populated with values. Therefore, a model can be considered as an instance of a meta-model or in another words, a model conforms to a meta-model. Metamodels also need to be specified by using a language often refereed to as a meta-modeling language. The concepts of such a language do not depend on a particular domain and are defined by the environment in which the metamodels are specified. Meta-modeling language concepts are given in a form of a meta-meta-model, which resides at the top level (L3) of the MDSD conjecture. Therefore, each meta-model must conform to a particular meta-meta-model. As there is no practical benefit in introducing new levels of abstraction above L3, meta-meta-models usually conform to themselves and are specified reflectively using their own concepts. 11 Modeling languages that rely on the domain knowledge and provide concepts close to the target domain are called Domain Specific Modeling Languages (DSML) and can be seen as a subset of a wider term: Domain Specific Languages (DSL) [149]. The advantage of DSMLs in comparison to general purpose modeling languages (GPMLs), such is the Unified Modeling Language (UML) [137], is the closeness to the domain under observation and appropriateness of modeling concepts that are used for the concrete modeling task. By using such a language, a domain expert or a user familiar with the domain is able to specify the solution faster, with less errors, using familiar concepts than it is the case with GPMLs. Once specified, no model can continue to exist unchanged or isolated. Therefore, operations on models aim at changing them and bridging differences between models. Such operations are called model transformations. Analogously to Wirth’s well known equation [161] designed for general purpose programming languages “Algorithms + Data Structures = Programs”, the following equation may be applied in MDSD approaches “Models + Model Transformations = Software” [28]. Model transformations are specified at the level of meta-models but are executed at the model level. This way, a transformation may be specified once, for a combination of source and target meta-models, and then executed multiple times for each source model that conforms to the source meta-models. The output of such a transformation is a model that conforms to a target metamodel. Model transformations are specified by using a transformation language which can also be characterized as a DSL for the domain of model transformations. Therefore the same language development rules apply as for the development of DSMLs. As the MDSD approach to model integration relies on model transformations which are based on the four-level conjecture, integrated TSs have to be represented in a suitable way. TSs only deal with the virtual representation of real world entities and as such most of them may be considered to have three levels presented at the right hand side of Figure 4. Together with the real world system (L0), TSs form the appropriate four-level structure in order for them to be a subject of an MDSD integration approach. At the L1, each TS has a model that represents data of the system entities. Such data conforms to a data schema that corresponds to the meta-model notion. Data schemas are specified Ecore language meta-model model EMF technical space The XML Schema XML schema XML document XML technical space implicit implicit columns and rows CSV document CSV technical space system meta-meta-model meta-model model conforms to conforms to conforms to rep. of Fig. 4. Three-level TS architecture with examples 12 with a schema language which concepts form a meta-meta-model. Both metamodels and meta-meta-models can be implicitly or explicitly defined in a TS. Each three-level TS can be seen as based on a single meta-meta-model and a collection of meta-models [31]. Examples of the frequently used three-level TSs are presented at the left hand side of Figure 4. In the proposed research we will focus only on three-level TSs. 2.2 Research Goals and Expected Results A language for the integration of TSs may be categorized as a DSML for the integration domain. Data originating from the source TS represent a model of the real world device that has sent it. The integration adapters are created at the level of data schemas, i. e., at the level of meta-models, and as such they can be considered as model transformations. Considering all of the aforementioned, we formulate the basic hypothesis of our research: Hypothesis 0 It is possible to solve heterogeneity problems in TS integration by creating appropriate DSMLs and following the principles of MDSD approach. The main goal of the proposed research, derived directly from this hypothesis, is to define a methodological approach and a software solution in which the MDSD principles and DSMLs will be used to overcome heterogeneity issues in order to allow integration of TSs. The derived hypotheses, which lead to the formulation of research approaches whose aim is to corroborate the Hypothesis 0 are given in the rest of this subsection. In order for the proposed DSML to be useful in the real world and be able to overcome heterogeneity issues presented in Subsection 1.2, it must satisfy the following two requirements: 1. provide means to integrate two arbitrary TSs with the language concepts that can be easily understood by users familiar with the TSs being integrated, and 2. provide concepts that are reusable and allow for the process of reuse to be automated as much as possible. The first requirement addresses the problem of inter-space heterogeneity. If the users of such a language understand both the data schema concepts and have a language specifically tailored for the integration domain, they would create adapters easier, faster, and with less effort. Such a language should be understandable by domain experts from any TS domain, just like it is the case with the XML and EMF experts and the integration languages specific to each of these TSs (e. g., XSLT, ATL, ETL, etc.). The development process could be improved even further if the same language would be used for the combination of arbitrary TSs just as GPLs are used. Therefore, such a language must have the benefits of both kinds of languages in order to replace them for the TS integration. 13 In order to create an integration language that is used across various domains and TSs, different data schemas (i. e., meta-models) must be represented in the same way to be used by the language. There are two possible approaches to creating such a representation. First approach comprises developing one or more DSMLs for each of the TSs. Different DSMLs would enable different type of users to model the same system from different viewpoints. Using the developed DSMLs, users can specify data schemas at a higher abstraction level using concepts close to their comprehension of the domain. The benefit of such approach would be better definition of integration semantics as it is more obvious what concepts from TSs are integrated. However, such approach requires a lot of effort to implement a DSML for each TS, or to adapt existing DSMLs to allow for integration language to be used on top of them. Another drawback of such approach is that a right level of DSML abstraction is hard to achieve. If the abstraction is too high, specified transformation would not have all the necessary information in order to be executed on the data level. If the abstraction is too low, the integration language does not differ much from the data schema already present in the technical space. The second approach is closer to the system implementation and is based on representing existing TS meta-models with a common representation that is at the same level of abstraction as the original meta-model. As each meta-model comprises entity types, relationships, and properties, it may be possible to find a common, graph-like representation to which all of meta-models from different TSs could be mapped onto. Such a generic representation of TS meta-models would allow for the same integration language to be used for any combination of TSs. Additionally, as the integration adapters must perform transformations on the original source model, such a generic representation must preserve links to the original data elements that will be used in the integration process. Therefore, the following hypothesis may be introduced: Hypothesis 1 It is possible to represent data schemas (i. e., meta-models) from the three-level technical spaces in a uniform way by using a graph-like representation, while preserving links to original elements. Once the generic representation is provided and the appropriate tools for importing TS meta-models are created, a domain specific integration language may be developed. As it is used to specify relationships between source and target TS in a graphical way, the integration language may be classified as a relationship-based mapping language. Relationship-based mapping systems rely on the specification of high-level relationships between elements (i.e., attributes or sets of attributes) of the source and target TSs. The user starts the mapping design process by providing, usually through a graphical interface, all known attribute correspondences between elements of a source and a target TS. Once such a specification is created, it can be used as an input to other processes such is the generation of adapters and verification of correspondences [10]. Therefore, the next hypothesis of our work is: 14 Hypothesis 2 It is possible to create a relationship-based mapping language that allows the creation of high-level mappings between the uniform data schema representations, from which the data integration adapters can be generated. The second requirement for the integration language, the reuse of language concepts, mainly addresses the problem of intra-space heterogeneity. The integration language and its concepts should be created in such a way to be easily and automatically reused in new integration projects. Reuse also helps in overcoming the inter-space heterogeneity as integration of new technical spaces could be done on the basis of constructs from previously defined adapters. Although both heterogeneity issues are tackled by implementing a reuse framework and it introduces more complexity to the development of a mapping language, it should be possible to achieve greater degree of reuse automation as the industrial context often comprises similar scenarios slightly adapted to some configuration changes. Therefore, the next hypothesis may be introduced: Hypothesis 3 It is possible to create an extensible reuse framework based on the created domain specific integration language that will allow reuse of previously defined integration adapters in the presence of intra-space heterogeneity. After introducing these hypotheses, we may also state that the main goal of this research is to provide an MDSD approach for a structured, automated, and reusable integration of TSs. The central idea of the approach is a TS independent coupling component that, in addition to the domain specific integration language, also allows a systematic reuse of integration knowledge from previous integration projects. The reuse or adaptation of existing integration knowledge to new projects is to be provided via framework in an automated and transparent way. The expected results comprises the following contributions: –Theoretical contributions in the field of model-driven integration of technical spaces. Such contributions will include: •survey on existing integration approaches and software solutions; •application of MDSD in the TS integration domain relying on a generic representation of meta-model structure; •identification of main concepts needed for the implementation of a domain specific language for the integration of TSs; •conceptualization of an extendible reuse framework specifically tailored to an Industry 4.0 integration domain; •specification of a methodological approach for the application of the developed integration framework; and •measurement framework that measures the effort needed to implement an integration adapter in our approach. –Development contribution in the form of a TS integration tool that will implement the MDSD integration approach comprising an integration language and a reuse framework. 15 –Application contribution that comprises application of the integration approach on several use cases and dissemination of evaluation results and lessons learned. The main expected result of this research is easier and simpler integration of TSs with the aim to improve the response time to production process changes and solve both inter-space and intra-space heterogeneity issues. Expected end-users are integration experts and developers from companies that provide hardware and software solutions for smart factories who need to integrate their products into an existing product landscape. Further, as the term technical space is inherently broad, the results of our research could be used by developers who want to provide data interchange between software which data is structured in a form of a three-level TS. This will be evaluated on the practical use cases that are presented in Section 3. 2.3 Research Methodology In this subsection we present the following methodological steps of our research: (i) study existing integration software, (ii) develop the integration approach, and (iii) evaluate the integration approach. Step 1: Study existing integration software During our initial state-of-theart literature study, presented in this report, we have identified various integration software presented in Subsection 4.5. Identified software solutions constituted an initial set of software to be studied. After the initial set was identified, we eliminated solutions that did not fulfill the criteria of being recently updated, currently used, and available for download. After the literature study, we have searched the Internet for phrases: “integration tool”, “schema matching tool”, “schema mapping tool”, “migration tool”, “ectl tool”, and “bridging tool”. This search resulted in several industrial software solutions that were not identified by our literature study. This also allowed us to classify the solutions by relevance (closeness the integration domain and number of search hits) and choose the most relevant ones for our study. This lead to the omission of large number of solutions, especially in the area of Extract, Clean, Transform, Load (ECTL) processes as ECTL is a very generic notion covering wide range of different processes. Most of the omitted software solutions were used in a narrow domain making them marginally important to our general integration approach. The next activity that needs to be preformed as a part of the proposed research is the study of these software solutions. Benefits of such a study are twofold. On the one hand side, as we plan to preform the study prior to the development of our integration approach, we can identify advantages and disadvantages of each solution, good practices, and usage patterns. Further, we may identify main concepts that these solutions use to implement integration adapters and to allow knowledge reuse. We will use the obtained experience and information in the development of our approach. Another benefit of such a study 16 is that it represents a baseline for the evaluation of our approach. Once we develop the approach and the appropriate tooling support, we may compare its concepts, performance, and user experience with the solutions that were studied as a part of this methodology step. The process of evaluating the integration software will be based on a single example which will be implemented in all identified solutions. We will use the example of the integration between sensors, which send CSV data, and information systems, that can receive XML data. The reason of choosing this example is that it is one of our target use cases in which we want to apply our approach. The more detailed description of this use case is given in Subsection 3.2. While implementing the example in each of the tools, a set of the measured characteristics must be defined in advance so as to perform the comparison and draw usable conclusions. Main characteristics that will be recorded are: –number and type of supported technical spaces, –possibility of adding a new technical space, –description of mapping language characteristics, –description of expression language characteristics, –description of knowledge repository characteristics, –reuse granularity and reusable concepts, –description of executable code generation mechanisms, –extension possibility of mapping and transformation mechanisms, –type of the main application domain, –software license type, and –software recentness. Step 2: Develop the integration approach Development of the integration approach will be performed as an iterative process with the following main activities: requirement solicitation, design, construction, testing, debugging, deployment, and maintenance. The requirement will be acquired in three ways: (i) interview with experts in the integration domain, (ii) literature study, and (iii) integration software study. The most important source of functional and non-functional requirement are domain experts. As they are also the end users of the tool, their expectations, previous experiences, and lessons learned are of utmost importance for the whole development process. Further requirements will be a direct result of the state-ofthe-art literature and integration software study. These requirements cover the current trends and practices in the field of system and data integration. Based on the defined requirements, the following system elements are to be designed: (i) the integration approach and its phases, (ii) concepts of mapping and expression languages, (iii) reuse algorithm and its steps, and (iv) architecture of supporting tools. After the design phase, construction, testing, and debugging will be performed in order to produce a working integration tool from the specifications provided in the previous development step. The Java language will be used as it provides widely used frameworks for creating DSMLs (EMF [143], 17 Xtext [51], Sirius [152]). Further, using these frameworks will allow us to deploy the tools as a set of plug-ins in the widely-used Eclipse environment [73]. The maintenance activity is beyond the scope of this research and it is planned for the follow up phases. Step 3: Evaluate the approach The approach will be evaluated on the predefined set of examples and the result of the evaluation will be put into the context of software study results from the Step 1 of this methodology. By applying the approach and appropriate tools on a predefined set of examples, we will test their functionality and domain coverage. This will provide us with the information whether the tool has all the appropriate concepts and functions to be considered for future practical use. Comparison with other tools will allow us to test the efficiency of our approach and the tool in the context of the existing integration software landscape. The evaluation will be performed on two case studies: (i) integration of the sensor and information system in a smart factory and (ii) exchange of models between different meta-modeling environments. In Section 3 we present these examples in more details. Before the evaluation, case studies must be prepared. In order for the evaluation to provide relevant information, real world data will be collected, anonymized, and turned into example data set. Further, in order for the tool performance to be protected from external influences, it will be installed on a clean operating system and tested in a controlled environment. The evaluation will be performed by several integration domain experts in a controlled environment (identical premisses, computers, and the tool setup) with the same amount of given time. After the evaluation is preformed we will disseminate its results and the lessons learned. This will pave the way for future improvements and research directions. 3 Applicability of Research Results As the proposed approach is based on three-level TSs that are used in a large number of integration use cases, a degree of its practical applicability is high. The approach can be used in the industrial context as a building block of the factory automation. We will focus on a particular problem encountered in every factory: the problem of integration between sensor machines and information systems (ISs). Although we choose one example and focus on it, the same conclusions will be valid for the integration between various sensor machines and also between different information systems in the industrial context. In addition to this industrial application, the approach is applicable to many other, non-industrial software integration domains. One of the notable problems is the interchange of models and meta-models between meta-modeling environments. This is a known issue as discussed by Kern et al. in [81, 82]. Although meta-modeling environments have the export and import mechanisms, they usually focus on a small number of serialization formats. This hinders the usability 18 of these tools in practice as migration of models and collaboration within a team are made difficult. We will use our approach to provide these environments with an external model interchange functionality. The same approach could be also applied to many other, non-industrial, use cases. For example, ECTL processes in the domain of databases could be specified using our approach. As these processes aim at gathering data from various data sources formatted in different ways, an ECTL process could be seen as the integration of these various TSs from data sources on one side and relational TSs of a relational database on the other. In addition to ECTL processes, a notable application would be in the ontology alignment process in which the alignments can be specified using a mapping language. In the rest of the section, we introduce two use cases on which we plan to evaluate our approach. 3.1 Model Interchange Between Meta-Modeling Environments Models play an important role in Domain-Specific Modeling [80] and other related development disciplines. Generally, models represent a system in an abstract way, improve the understanding of a system, and facilitate the communication between different stakeholders. The creation of models is the result of a modeling process which is supported by a modeling tool. A special class of these modeling tools are meta-modeling tools. In addition to providing a user with a set of predefined modeling languages, meta-modeling tools provide a mechanism for the specification of new modeling languages. Examples of meta-modeling tools are: MetaEdit+ [80], Eclipse Modeling Framework [143], and Microsoft Visio [67]. An important requirement for modeling tools, including meta-modeling tools, is the interoperability with other tools. In the context of this use case, interoperability is defined as the ability of two or more tools to exchange models or meta-models. Additionally, these exchanged models and meta-models must be usable in the tools they are imported in. Often, tools support a specific task in the development process. Therefore, a successful application of the whole development process depends heavily on the degree of interoperability between the tools used in the process. Besides the cooperation of tools, the evolution of a tool landscape is an important aspect. As the software industry constantly evolves, modeling tools also evolve and the old ones are being replaced by new tools that better fit customer’s needs. In order to avoid the vendor lock-in effect, interoperability between tools is necessary and enables the reuse of existing models between tools from different vendors. Currently, the interoperability between meta-modeling tools is not widely supported [81, 82]. There is no suitable model exchange approach that takes meta-models into consideration. We will address this lack of interoperability between meta-modeling tools and use the proposed approach to provide the exchange of models in consideration of their meta-models. This way we plan to allow an efficient and user-oriented import and export of models in tools 19 Unlike aforementioned surveys on general matching techniques, a survey focusing on XML schema matching is provided by Agreste et al. [2]. The authors significantly extend the scope of published surveys with a description of new techniques particularly tailored for the XML domain. Agreste et al. argue that in order to have a best fit matching technique in the domain of XML, the matching tools should be specialized for that domain and use all of its peculiarities. This way, the matches are found more efficiently, matches are more appropriate to the domain, and the greatest advantage is that the schema element semantics can be identified in a more precise way. They also provide a template, called XML Matcher Template, which proposes the main components and their roles and behaviors in any XML matcher. Agreste et al. also discuss several commercial prototypes designed to identify mappings between XML schemas. These prototypes are then classified by using the degree of correspondence to their XML Matcher template. We have also identified several schema matching approaches not covered by the aforementioned surveys. At the Faculty of Technical Sciences, University of Novi Sad, a tool named Integrated Information Systems Studio (IIS*Studio) is developed with one of its core function being the integration and consolidation of relational database schemas and subschemas. The main purpose of IIS*Studio is information system development which comprises the conceptual database schema design, based on the form type concept [55, 98], and development of appropriate business applications. IIS*Studio comprises three main tools: IIS*Case [97, 101], IIS*UIModeler [19], and IIS*Ree [5]. IIS*Case is the core tool of IIS*Studio and provides the following functionality: 1. conceptual modeling of database schemas, transaction programs, and business applications of an IS [98,122–124], 2. specification of check constraint at the level of a conceptual model [118], 3. automated design of relational database subschemas in the 3rd normal form (3NF) [96,99], 4. automated integration of subschemas into a unified database schema in the 3NF [96,99,100,131–133], 5. automated generation of SQL/DDL code for various database management systems (DBMSs) [4], and 6. automated generation of executable prototypes of business applications. In the case of large systems being developed by the incremental approach, a system is decomposed into several subsystems that are modeled independently and usually by different designers. The process of independent design of subsystems and their database schemas may lead to collisions in expressing the real world constraints and business rules. Therefore, in IIS*Case, the process of system integration is not just a mere unifying of its subsystems. It is based on detecting and resolving all the formal constraint collisions. Lukovi´c, Risti´c et al. [96,99,100,131–133] proved that, at the level of relational data model, it is possible to automatically detect formal collisions of database constraints embedded into different subschemas, where each subschema represents a database 26 schema of a sole IS subsystem. If collisions are detected, at least one subschema is formally not consistent with the current version of a database schema of a whole system. Programs made over inconsistent subschemas do not guarantee logically correct database updates. Therefore, the authors created and embedded into IIS*Case algorithms for detecting formal constraint collisions for the most often used constraint types at the level of relational data model. Besides, they embedded into IIS*Case a number of collision reports that assist designers in their resolving. By this, the database schema integration process based on the approach of a gradual integration of subschemas into a unified database schema is supported by IIS*Case in a large extent. At the abstraction level of platform independent models (PIMs), IIS*UIModeler provides conceptual modeling of common user interface (UI) models, as well as business applications that include specifications of: (i) UI, (ii) structures of transaction programs aimed to execute over a database, and (iii) basic application functionality that includes the following “standard” data operations: read, insert, update, and delete. A PIM of business applications is combined with a selected common UI model and then automatically transformed into the program code. In this way, fully executable application prototypes are generated. IIS*Ree is a model-driven re-engineering tool that provides a set of extractors and model-to-model transformations that extract and transform relational database schemas to a conceptual model based on the form type concept. Once the conceptual model is adapted to new requirements, a set of new model-to-model transformations and code generators is used to generate relational database schema and deployment scripts. Bernstein et al. [25] introduce a solution that aims to bring the schema mapping technique to an industrial environment. They present a prototype of a customizable schema matcher called PROTOtype PLAtform for Schema Matching (PROTOPLASM). PROTOPLASM comprises three layers: (i) an import layer in which the mapped artifacts are transformed into a common internal representation based on XML, (ii) operation layer which comprises concepts needed to build a schema matching strategy, and (iii) a graphical language layer in which the graphical representations of operational concepts are combined into matching strategy scripts which are then executed. Similarly, Raghavan et al. [128] propose a solution, named SchemaMapper, which uses a hyperbolic tree instead of a linear tree representation. In their opinion, the hyperbolic tree contributes to a faster human-performed search for an element that is needed for a matching process. Another difference between PROTOPLASM and SchemaMapper is that the latter uses a tabular mapping representation instead of line-based one, which is traditionally used. While the line-based representation may lead to overcrowded diagrams in the case of large schemas, tabular representation leads to more compact views. A drawback of the SchemaMapper is reflected in the fact that it is focused only on the XML technical space. Alexe et al. [6, 7, 10] propose an approach to schema mapping in the domain of relational database schema integration. Unlike most of the previously listed solutions, that load entire source and target schemas and create high-level 27 mappings between them, Alexe’s approach named “divide-design-merge” allows splitting source and target schemas into smaller parts, creating mappings between these parts, and merging all partial mappings into a whole as the final step. This approach has been supported by three tools that authors have developed. Eirene [13] is a schema mapping design tool that takes as an input a set of data examples provided by the user. In turn, Eirene outputs a schema mapping that “fits” the set of data examples, if such a schema mapping exists. Afterward, a user can interact with the Muse [8] tool to refine and further design schema mappings through the use of data examples. Finally, in the merge phase, a global schema mapping is generated through the correlation of the individual schema mappings by using a MapMerge [9] application. Muse is one of the earliest systems that adopted a different approach to schema-mapping design. This approach uses instance data examples to infer mappings between schemas according to which these data are formatted. In these approaches, schema matching does not rely on a high-level schema mapping language, but on algorithms that analyze instance data to find data constraints or patterns which are often very good indicators of the similarity between the appropriate schema elements. This type of an approach to schema mapping has been also proposed by [7,12,38,63,146,163] In [48], Duchateau and Bellahsene present Yet Another Matcher (YAM). YAM is a self-tuning and extensible matcher factory tool that generates a bestfit schema matching algorithm for a specific integration scenario. Based on the generated matching algorithm schema element matches are then identified and proposed to a user. The self-tuning feature of this approach provides the ability to produce a matcher with appropriate, user-defined, characteristics for a given scenario. The extensible feature enables users of a matching tool to add new similarity measures and thus increase the overall effectiveness of the system. The goal of YAM is to alleviate users of a manual configuration of matcher similarity measures including the thresholds setup and iterative adjustment of these measures. YAM automatically tunes these parameters by relying on the implemented machine learning techniques. Similar techniques were implemented in MatchPlanner [49], which is based on the decision tree while, and eTuner [91] that performs the same job by employing a set of synthetic matching scenarios involving the schema being mapped. For each eTuner synthetic scenario correct matches are known in advance and thus it is possible to evaluate produced mapping configurations. In addition to approaches and tools described in research papers, several patents have been filed concerning schema matching approaches, notations, and systems. Thomas [147] patented a schema matching system based on a tabular representation of schemas and mapping formulas. The proposed system displays instance data beside the appropriate schema elements in order to give the user better contextual understanding of the schema elements. Once the schemas are loaded and represented in a tabular layout, textual formulas can be specified to represent relations between source and target elements. In her second patent, Thomas [148] introduces the notion of a platform independent schema represen28 tation, named conceptual model which is a high level representation of schema understandable to a domain expert. The reminder of the patent is similar to the one presented in [147]. In [140], Seligman patents a semi-automatic schema matching approach based on a linguistic processing of schema elements. Element relations, i. e., matches, are discovered by analyzing element names with a machine learning algorithm that uses both generic and domain thesauri together with the list of frequently used abbreviations. Match probabilities are provided to a user who manually chooses the mappings he deems a best-fit. Patents [69,135], filed by Hobbs and Robertson et al. respectively, propose notations and layout algorithms to be used in matching tools. Both patents propose that mappings are represented as lines with a central (algorithmic) part of the mapping being shaped as a box to allow easier handling and spotting. Hobbs also proposes an algorithm that handles drawing and layout of the mappings used while users create mappings, load previous work, or scroll the schema elements in their views. 4.3 Model-driven integration approaches The Model-Driven Software Development (MDSD) promotes the development of software systems at different levels of abstraction, and Domain Specific Languages (DSLs) play a prominent role to reduce development costs. As one of the most time-consuming and error-prone parts of introducing a new technology or a new functionality to the existing IT landscape is integration, by means of an appropriate DSL software engineers can design a software system that can later be integrated and deployed to a variety of specific platforms using automatic transformations. As the transformations are specified at the level of meta-model, i. e., data schema, transformation rules may be seen as schema matching rules. Therefore, MDSD transformation approaches may be seen as a subset of schema matching and mapping approaches. B¨uttner et al. [29] present a model-driven approach to the data integration between government institutions in Germany. The integration approach is centered around the standardization of messages, interfaces, and models of data that are being exchanged. A compliance with the standards is regulated by a central governing body that governs the specification of meta-models, i. e., data formats, for different sectors in the German government. As different standards exist, integration is essential task that needs to be performed in order for the data to be exchanged. Therefore, integration processes need to be used at th meta-model level to allow transformation of messages and their communication to other German or European institutions. B¨uttner et al. have developed a central repository, named XRepository, that stores all meta-modeling concepts, well-formedness rules, and process and semantic specifications that together form standards. The XGenerator tool is used to produce artifacts that are used in the integration process. These artifacts are usually web service specifications that need to be implemented by software vendors to integrate their solutions with the system. Agt et al. [3], Kutsche et al. [87, 88], and Milanovi´c at al. [111] present a meta-modeling approach to the integration of heterogeneous distributed IT sys29 tems named BIZYCLE. The BIZYCLE integration process is based on multilevel modeling abstractions. The integration scenario is first modeled at the computation independent level, where business aspects of an integration scenario are described. The model is then refined at the platform specific level, where technical interfaces of the systems that should be integrated are described. For each of the supported platforms: SAP, relational and XML databases, web services, XML files, J2EE components, and .NET applications, a specific platform specific model is created. The automation of the integration process is achieved through model extraction, systematic conflict analysis process, and code generation. Reuse is supported at the model-level via BIZYCLE Repository [112], as interface descriptions, transformation rules, and semantic annotations can be stored and shared between projects and users. Wimmer [160] developed a meta-model bridging framework and a graphical DSL that provides bridging of different technical spaces based on data mining techniques. The framework comprises a mapping view and a transformation view. At the mapping view level, a user defines mappings between elements of two meta-models using the provided DSL. Thereby a mapping expresses also a relationship between model elements, i. e., instances of meta-models. In Wimmer’s approach, mappings between meta-model elements are defined with mapping operators which are considered as processing entities encapsulating a certain kind of transformation logic. A set of applied mapping operators, also called a mapping model, defines the mapping from a left hand side (LHS) meta-model to a right hand side (RHS) meta-model. Thus, the mapping model declaratively describes the semantic correspondences on a high-level of abstraction. The transformation view is capable of executing the defined mapping models. During the execution, a mapping operator takes as input elements of the source model and produces as output semantically equivalent elements of the target model. Huh et al [71] developed Marama Torua, a tool supporting high-level specification and implementation of complex mappings of data schemas. Complex mapping relationships are represented in multiple notational forms and users are provided with a semi-automated mapping assistance for large models. Multiple views are implemented in order to ease the process of mapping specifications for all levels of source and target schema complexity. The tool supports creation of mappings between any two technical spaces. However, if the import tool has not been already developed for a certain technical space, a user must develop it manually and map a data schema to a generic tool structure. Marama Torua comprises a set of Eclipse plug-ins allowing close integration with other tools such as schema browsers. There are several DSLs and frameworks that are not directly related to the schema mapping, but fit better to the fields of schema matching and enterprise application integration. Vukovi´c et al. [153, 154] present a language called Semantic-Aided Integration Language (SAIL). This language allows for the matching components to be described, generated, and used in their framework without having to be implemented in a general purpose programming language and are available without having to rebuild the entire application. The 30 aim of the developed matching framework is to automate some of the steps in conflict resolution of the matching process. Interfaces and their elements can be semantically described using ontologies in order to facilitate this automation. Although the approach itself is based on the ontology alignment principles, the SAIL domain specific language is used to specify matching algorithms and follows all the principles of the MDSD methodology. Another domain specific language, named Highway, is developed by Kovanovi´c et al. [85]. Highway is developed as an internal DSL in the Clojure programming language. It may be used for implementing enterprise application integration solutions in a technology independent and functional manner. Highway uses functional programming techniques in order to simplify enterprise application integration development. Sleiman et al. [142] propose a DSL called Guarana and a software tool to design and automatically deploy integration solutions in order to reduce integration costs. Guarana provides a set of domain specific constructors to design integration solutions. It provides an expressive graphical notation for these constructors, which allows a user to visually design an integration solution. Functions and mappings are all displayed on the same diagram thus giving a good overview of the general solution. The Federated USer Exchange (FUSE) approach [157] represents a domainaware approach to user model interoperability. It consists of a manual mapping process and an automatic translation process. Both processes contain two domain aware mechanisms: (i) a canonical user model and (ii) user model mapping transforms, which tailor the processes to specific domains. All mappings are first created with the canonical user model as a target. This model represents a consistent shared user model. The user model mapping transforms are mapping components specifically created and used for mapping between different user models via the canonical model. This approach differs from existing generic approaches because it incorporates domain knowledge in new processes and tools to support complex user model interoperability tasks in multiple overlapping domains. Wischenbart et al. [162] employed a MDSD approach to the integration of data collected from social networks. Although many social networks on the Web allow access via dedicated APIs, the extraction of instance data for further use by applications is often a tedious task. As a result, instance data transformation to Linked Data in the form of Ontology Web Language (OWL), as well as the integration with other data sources are needed. This paper proposes a modeldriven approach to overcome data model heterogeneity by automatically transforming schemas and instance data from JavaScript Object Notation (JSON) to OWL/XML. Authors specify a set of transformations that transform an input model, i. e., the model of JSON messages collected from social network APIs, to the OWL model, i. e., ontology used for representing social network data instances and their semantic. In addition to aforementioned approaches, model-to-model (M2M) transformation languages can be also seen as possible means to integrate different TSs. 31 M2M transformation languages are specified at the level of a meta-model but are executed at the model level. Therefore it is required to extract or use existing meta-models from the integrated TSs. Once meta-models are obtained, transformation rules may be specified with one of the transformation languages. A definition and a classification of M2M transformation languages is given by Mens et al. [108] and the overview of the selected visual transformation languages may be found in our previous paper [39]. The advantage of these languages is that they are supported out of the box with well defined notations and semantics, they are usually declarative, and as we deal with the three layered technical spaces, meta-models already exist or can be easily extracted to a desired environment. However, the disadvantage of these languages is that they may be seen as general purpose mapping languages, and they are not well suited for the domain of integration thus the transformations may be verbose and hard to read and maintain. 4.4 Ontology-based integration approaches What is known as schema mapping or schema matching in database and artificial intelligence domains, in semantic web community it is known under the name Ontology Alignment [52] or Ontology Matching [57]. The task of these approaches is to find groups of elements sharing the same semantics. Majority of the tools presented in Subsection 4.2 can be also applied to the ontology alignment process. Therefore, there is no clear line that separates these approaches and fit them into a single category. For example, although both approaches described in [153,162] may be seen primarily as MDSD approaches, they rely on the use of ontology alignment techniques and principles to find best match candidates. Unlike schema matching approaches that usually comprise techniques for guessing the meaning encoded in the data schemas, ontology matching systems try to exploit knowledge explicitly encoded in ontologies. In their survey [141], Shvaiko et al. focus on the comparison of the following ontology alignment solutions: Naive Ontology Mapping (NOM) [54], Quick Ontology Mapping (QOM) [53], OWL Lite Aligner (OLA) [58], Anchor-PROMPT [117]. Many other ontology alignment solutions are compared in a survey by Ardjani et al. [14]. The ontology alignment is performed according to a strategy or a combination of techniques for calculating similarity measures by using a set of parameters, e. g., weighting parameters and thresholds, and a set of external resources, e. g., thesauri and dictionaries. As a result, a set of semantic links between ontology entities is obtained. In addition to the tool comparison, Ardjani et al. introduce a classification of the ontology approaches based on the similarity measurement methods that are used. The identified methods are as follows: (i) terminological methods that are using terms, strings, and text for comparison, (ii) structural methods, which calculate the similarity by exploiting structural information, (iii) extensional methods, which infer the similarity between two entities, especially concepts or classes, by analyzing their extensions, i.e. their instances, and (iv) semantic methods, which include the methods based on an external thesauri and 32 dictionaries and on deductive techniques that heavily rely on logical models, such as propositional satisfiability or description logic. 4.5 Integration Tools In addition to identifying the state-of-the-art research work on the topics of schema matching, mapping, and integration, our goal is also to identify visual mapping software solutions that are currently used in practice. As the goal of our research is to develop a visual mapping language for the integration domain, a survey on such tools will provide us with valuable information on current integration trends, best practices, and characteristics of an industry-ready solution. We have identified a number of software solutions that follow similar approach to the one we propose as a part of the future research. All the solutions may be categorized into three groups based on their dominant application domain: –General mapping tools: Altova MapForce [104], AnalytiX Mapping Manager [47], Open Mapping Software [134], Vorto [151], Karma [65], Talend Enterprise Data Integration Studio [27], CLIP [127], Schema Mapper [128], Mint Mapping Tool [115], MetaDapper Data Mapping Tool [136], ++Spicy [105], Coma++ [17,42], and Schema Mapper Transformer [138]. –XML mapping tools: Liquid XML Studio (DataMapper component) [145] and Stylus Studio (Data Direct XML converter i XQuery Mapper) [144]. –ECTL tools: Adeptia ETL Tool [1], Informatica ETL Suite [74], Oracle Data Integrator [119], OpenRefine (also known as GoogleRefine) [150], Datastage ETL Tool [72], Microsoft SQL Server Integration Services (SSIS) [110], and Clover ETL Tool [121]. According to the research plan given in Section 2.3, the first step of the future research will be to implement a single example in all of the identified software solutions. By doing this, we will gather a set of tool characteristics and compare them. The result of such a comparison will be disseminated in the future research reports. Such a comparison will also provide us with a possibility to evaluate our tool by comparing its characteristics with the characteristics of the identified software. To our knowledge there are no existing studies that evaluate and compare integration software based on the proposed criteria, taking care of their domain coverage, language complexity, supported functions, reuse ability, availability, and other non-technical characteristics. In [130], Rathinasamy compares only several tools for the domain of asset management. These tools include COMA++ and Altova MapForce. Do et al. [40] compare several matching tools based on the matching algorithm performance. However, these tools are either still in the prototype phase or not maintained any more, which makes the proposed survey even more relevant. A framework aimed at generating test cases for visual mapping system evaluation was developed by Alexe et al. [11]. The framework generates test cases that are used to test if a mapping tool language covers a set of predefined functionality, i. e., basic mapping scenarios, such as copying a value from a source to 33 a target model, constant value generation, horizontal and vertical partitioning, etc. Most of these mapping scenarios come from the domain of database schema integration. A full list and a detailed description of the proposed mapping scenarios may be found in [11]. 5 Conclusion In this report we present issues of inter-space and intra-space heterogeneity that often occur during the integration of different technical spaces in the context of Industry 4.0. These issues hinder the productivity and efficiency of a manufacturing system as they often require custom integration adapters to be developed manually. Such a development process is often time-consuming, error-prone, and costly. In order to solve these issues, we propose a research with goal to provide a model-driven approach to the technical space integration. As technical spaces often have a three-level architecture (data, data schema, and meta-schema levels), we feel that such a problem is well suited for a model-driven integration approach as it is based on the same thee-level conjecture. The proposed research comprises several main phases and should result in the following elements: –a model-driven approach to technical space integration with the formally defined phases and responsibilities; –a formally defined and developed mapping language that is used for a specification of integration adapters in a model-driven way; –a reuse module to improve the speed of adapter development by reusing knowledge from previous projects; and –an appropriate tooling support for the approach. We believe that a model-driven approach and appropriate tools will allow integration experts to overcome the heterogeneity issues in a more efficient and productive way. To evaluate this statement, we specify two main practical use cases: (i) integration of machines and information systems in the context of a smart factory and (ii) integration of (meta-modeling) environments as to provide interoperability mechanism. Use cases are chosen as to provide a diverse and more precise evaluation of the approach. During the state-of-the-art literature survey we have found a plethora of tools and approaches which purpose is to integrate technical spaces. Since a significant number of these research papers are published in the last five years we can conclude that the field of integration and schema mapping is active and growing. As our main focus is on the model-driven techniques in technical space integration, we have invested a lot of effort to find approaches that use this methodology. Although several model-driven integration solutions exist, they are mostly focused on a narrow domain of integration, such as database or XML schema integration. We have not been able to find practically applicable solutions that could be efficiently used to overcome the heterogeneity issues. 34 Due to the practical need and lack of similar solutions, the presented approach to model-driven integration of technical spaces deserves the attention in the form of the proposed research. References 1. Adeptia: Adeptia ETL tool (2016), https://adeptia.com/solutions/ ETL-software-for-data-transformation.html 2. Agreste, S., De Meo, P., Ferrara, E., Ursino, D.: XML matchers: approaches and challenges. Knowledge-Based Systems 66, 190–209 (2014) 3. Agt, H., Bauhoff, G., Cartsburg, M., Kumpe, D., Kutsche, R., Milanovi´c, N.: Metamodeling foundation for software and data integration. In: Information Systems: Modeling, Development, and Integration, Lecture Notes in Business Information Processing, vol. 20, pp. 328–339. Springer, Berlin (2009) 4. Aleksi´c, S.: An SQL Generator of Database Schema Implementation Scripts in IIS*Case Tool. Master Thesis, University of Novi Sad, Novi Sad (2006) 5. Aleksi´c, S.: Methods of Database Schema Transformations in Support of the Information System Reengineering Process. PhD thesis, University of Novi Sad, Novi Sad (2013) 6. Alexe, B.: Interactive and Modular Design of Schema Mappings. Ph.D. thesis, University of California at Santa Cruz, Santa Cruz, CA, USA (2011) 7. Alexe, B., Cate, B.T., Kolaitis, P.G., Tan, W.C.: Characterizing schema mappings via data examples. ACM Transactions on Database Systems (TODS) 36(4), 23 (2011) 8. Alexe, B., Chiticariu, L., Miller, R.J., Tan, W.C.: Muse: Mapping understanding and design by example. In: Data Engineering, 2008. ICDE 2008. IEEE 24th International Conference on. pp. 10–19. IEEE (2008) 9. Alexe, B., Hern´andez, M., Popa, L., Tan, W.C.: MapMerge: correlating independent schema mappings. The VLDB Journal 21(2), 191–211 (Apr 2012) 10. Alexe, B., Tan, W.C.: A New Framework for Designing Schema Mappings. In: Tannen, V., Wong, L., Libkin, L., Fan, W., Tan, W.C., Fourman, M. (eds.) In Search of Elegance in the Theory and Practice of Computation, pp. 56–88. No. 8000 in Lecture Notes in Computer Science, Springer Berlin Heidelberg (2013), dOI: 10.1007/978-3-642-41660-6 4 11. Alexe, B., Tan, W.C., Velegrakis, Y.: STBenchmark: towards a benchmark for mapping systems. Proceedings of the VLDB Endowment 1(1), 230–244 (2008) 12. Alexe, B., Ten Cate, B., Kolaitis, P.G., Tan, W.C.: Designing and refining schema mappings via data examples. In: Proceedings of the 2011 ACM SIGMOD International Conference on Management of data. pp. 133–144. ACM (2011) 13. Alexe, B., Ten Cate, B., Kolaitis, P.G., Tan, W.C.: EIRENE: Interactive design and refinement of schema mappings via data examples. Proceedings of the VLDB Endowment 4(12), 1414–1417 (2011) 14. Ardjani, F., Bouchiha, D., Malki, M.: Ontology-Alignment Techniques: Survey and Analysis. International Journal of Modern Education & Computer Science 7(11) (2015) 15. Atkinson, C., K¨uhne, T.: Model-driven development: a metamodeling foundation. Software, IEEE 20(5), 36–41 (2003) 16. Atzori, L., Iera, A., Morabito, G.: The Internet of Things: A survey. Computer Networks 54(15), 2787–2805 (Oct 2010) 35 131. Risti´c, S.: Research on the Problem of Database Subschema Consolidation. Ph.D. thesis, University of Novi Sad, Novi Sad (2002) 132. Risti´c, S., Lukovi´c, I., Paviˇcevi´c, J., Mogin, P.: Resolving Database Constraint Collisions Using IIS*Case Tool. Journal of information and organizational sciences 31(1), 187–206 (2007) 133. Risti´c, S., Mogin, P., Lukovi´c, I.: Specifying database updates using a subschema. In: Proceedings of the 7th IEEE International Conference on Intelligent Engineering Systems. pp. 203–212. Assiut–Luxor, Egypt (2003) 134. Robert Worden: Improving Data Quality with Open Mapping Tools. White paper, Open Mapping Software Ltd (Feb 2011) 135. Robertson, G.G., Churchill, J.E., Czerwinski, M.P., Panditharadhya, P.S., Bhaskara, U.: Schema mapper (Oct 2012), http://www.google.com/patents/ US8280923 136. Rozsa, R.: MetaDapper (2016), http://www.metadapper.com/ 137. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual. Pearson Higher Education (2004) 138. SchemaMapper: SchemaMapper Transformer (Mar 2016), https://knowledge. safe.com/articles/1136/schemamapper-transformer-tutorial.html 139. Seligman, L., Mork, P., Halevy, A., Smith, K., Carey, M.J., Chen, K., Wolf, C., Madhavan, J., Kannan, A., Burdick, D.: OpenII: an open source information integration toolkit. In: Proceedings of the 2010 ACM SIGMOD International Conference on Management of data. pp. 1057–1060. ACM (2010) 140. Seligman, L.J., Mork, P.D.S., Korb, J.G., Samuel, K.B., Wolf, C.S.: Tools and methods for semi-automatic schema matching (Jan 2008), http://www.google. com/patents/US20080021912 141. Shvaiko, P., Euzenat, J.: A survey of schema-based matching approaches. In: Journal on data semantics IV, pp. 146–171. Springer (2005) 142. Sleiman, H.A., Sult´an, A.W., Frantz, R.Z., Corchuelo, R., others: Towards Automatic Code Generation for EAI Solutions using DSL Tools. In: JISBD. pp. 134–145 (2009) 143. Steinberg, D., Budinsky, F., Merks, E., Paternostro, M.: EMF: eclipse modeling framework. Addison-Wesley, Boston, USA, 2 edn. (2008) 144. Studio XML, S.: XML Data Integration, XML Tools, Web Services and XQuery (2016) 145. Technologies, L.: Liquid XML Studio (2016), https://www. liquid-technologies.com/xml-studio 146. Ten Cate, B., Kolaitis, P.G., Tan, W.C.: Schema mappings and data examples. In: Proceedings of the 16th International Conference on Extending Database Technology. pp. 777–780. ACM (2013) 147. Thomas, S.M.: Schema mapping and data transformation on the basis of layout and content (Jul 2012), http://www.google.com/patents/US8234312 148. Thomas, S.M.: Schema mapping and data transformation on the basis of a conceptual model (Dec 2014), http://www.google.com/patents/US8924415 149. Van Deursen, A., Klint, P., Visser, J.: Domain-Specific Languages: An Annotated Bibliography. Sigplan Notices 35(6), 26–36 (2000) 150. Verborgh, R., De Wilde, M.: Using OpenRefine. Packt Publishing Ltd (2013) 151. Vorto, Eclipse: Eclipse Vorto - IoT Toolset for standardized device descriptions (2016), https://www.eclipse.org/vorto/index.html 152. Vujovi´c, V., Maksimovi´c, M., Periˇsi´c, B.: Sirius: A rapid development of DSM graphical editor. In: 18th International Conference on Intelligent Engineering Systems (INES). pp. 233–238. IEEE, Tihany, Hungary (2014) 42 153. Vukovi´c, e., Milanovi´c, N., Bauhoff, G.: Prototype of a Framework for Ontologyaided semantic conflict resolution in enterprise integration. In: Proceedints of 5th International Conference on Information Society and Technology. Society for Information Systems and Computer Networks, Kopaonik, Serbia (Mar 2015) 154. Vukovi´c, e., Milanovi´c, N., Vaderna, R., Dejanovi´c, I., Milosavljevi´c, G.: SAIL: A Domain-Specific Language for Semantic-Aided Automation of Interface Mapping in Enterprise Integration. In: On the Move to Meaningful Internet Systems: OTM 2015 Workshops. pp. 97–106. Springer (2015) 155. Wahlster, W.: Industry 4.0: From Smart Factories to Smart Products (May 2012) 156. Waldner, J.B.: CIM: principles of computer-integrated manufacturing. John Wiley & Sons (1992) 157. Walsh, E., O’Connor, A., Wade, V.: The FUSE domain-aware approach to user model interoperability: A comparative study. In: Information Reuse and Integration (IRI), 2013 IEEE 14th International Conference on. pp. 554–561. IEEE (2013) 158. Wang, J.T.L., Zhang, K., Jeong, K., Shasha, D.: A system for approximate tree matching. Knowledge and Data Engineering, IEEE Transactions on 6(4), 559–571 (1994) 159. Weiser, M.: The computer for the 21st century. Scientific american 265(3), 94–104 (1991) 160. Wimmer, M.: From mining to mapping and roundtrip transformations–a systematic approach to model-based tool integration. Ph.D. thesis, Vienna University of Technology (2008) 161. Wirth, N.: Algorithms + Data Structures = Programs. Prentice Hall, Englewood Cliffs, N.J., 1st edition edn. (Feb 1976) 162. Wischenbart, M., Mitsch, S., Kapsammer, E., Kusel, A., Lechner, S., Pr¨oll, B., Retschitzegger, W., Sch¨onb¨ock, J., Schwinger, W., Wimmer, M.: Automatic data transformation: breaching the walled gardens of social network platforms. In: Proceedings of the Ninth Asia-Pacific Conference on Conceptual Modelling-Volume 143. pp. 89–98. Australian Computer Society, Inc. (2013) 163. Yan, L.L., Miller, R.J., Haas, L.M., Fagin, R.: Data-driven understanding and refinement of schema mappings. In: ACM SIGMOD Record. vol. 30, pp. 485–496. ACM (2001) 164. Zuehlke, D.: SmartFactory—Towards a factory-of-things. Annual Reviews in Control 34(1), 129–138 (2010) 165. ZVEI: The Reference Architectural Model For industrie 4.0 (RAMI 4.0) (2015) 43 Several Issues on Composition of Cyber-Physical Systems Based on Principles of the Two-Hemisphere Modelling Oksana Nikiforova1, Nisrine El Marzouki1, Nadezda Kunicina1, Hans Vangheluwe2, Florin Leon3, Mauro Iacono4, Rima Al-Ali5, and Priscill Orue6 1Riga Technical University, Latvia {oksana.nikiforova,nisrine.marzouki,nadezda.kunicina}@rtu.lv 2University of Antwerp, Nederlands [email protected] 3Technical University ”Gheorghe Asachi” of Iasi, Romania [email protected] 4Seconda Universita di Napoli, Italy [email protected] 5Charles University in Prague, Czech Republic [email protected] 6University of Malaga, Spain [email protected] Abstract. The two-hemisphere model-driven (2HMD) approach assumes modelling and use of procedural and conceptual knowledge on an equal and related basis. This differentiates 2HMD approach from pure procedural, pure conceptual, and object oriented approaches. The approach may be applied in the context of modelling of a particular business domain as well as in the context of modelling the knowledge about the domain. Cyber-physical systems are heterogeneous systems, which requires multidisciplinary approach to their modelling. Modelling of cyber-physical systems by 2HMD approach gives an opportunity to transparently decompose and analyse system’s components to be provided and components actually provided, and, thus, to identify and fill the gaps between desirable and actual system content. Keywords: Two-hemisphere model-driven approach, cyber-physical systems, system composition 1 Introduction Cyber-Physical Systems (CPS) have never been more central to the corporate strategy today. The features they offer, reliability, performance and robustness are the queen qualities that allow companies to be competitive. To cope with the complexity of the execution of such heterogeneous systems, it is necessary to define an approach to tame its complexity. This approach should be flexible and generic in order to adapt to any type of component of such system and 44 thus, should offer an ability to manage system composition. The Two-hemisphere model driven (2HMD) approach has been successfully applied for domain modelling and software design [1]. One of the most distinguished features of this model is its applicability for both human understanding and automatic transformations [2]. In this paper we illustrate the way how 2HMD approach may be applied to the task of modelling and composition of CPS. The goal of the paper is to show the way how the problem of complex system composition from smaller parts can be solved by using 2HMD approach for modelling of CPS components. From the point of view of 2HMD approach each component of CPS may be considered as a conceptual class, which preforms the particular operations and meet the defined requirements. The requirements are derived from the model that consists of functional and conceptual ”hemispheres”. Thus 2HMD approach is applicable for both modelling of components and modelling of the process of to be supported by that component at the same level of abstraction. Moreover, the 2HMD approach can help to identify conflict situations, where the additional analysis is required for sharing responsibilities between system components. Features of CPS or Cyber-Physical Systems and the necessity to model and decompose them are discussed in Section 2. The essence of the two-hemisphere model driven approach is clarified in Section 3. Application of 2HMD approach for composition and modelling of components of CPS are outlined in Section 4. Conclusions are given in Section 5. 2 Cyber-Physical Systems in the Context of System Composition A cyber-physical system (CPS) is a mechanism controlled or monitored by computer-based algorithms, tightly integrated with Internet and its users. In CPSs, physical and software components are deeply intertwined, each operating on different spatial and temporal scales, exhibiting multiple and distinct behavioral modalities, and interacting with each other in a myriad of ways that change with context [3], [4]. Being CPS inherently complex, any significant analysis is a challenge. The behavior results from the different scales of the effect of the emerging or fundamental phenomena, the different nature of the components, the interactions and the drawbacks of the internal compositions. A comparable domain is System of systems (SoS), in which analysis exploits decomposition (or, equivalently, design exploits composition), and the system additionally exhibits emerging behaviors or features that have to be modeled at a higher level. While both for CPS or SOS an holistic approach is viable for a general understanding of the system from the point of view of an external observer, in order to design or assess in detail its behaviours the heterogeneity of the problems that have to be analyzed require that every aspect and every component, and every scale and every hierarchical subsystem, need a proper model and a proper modelling technique. This is also a natural consequence of the wide set of expertise that has to be involved in the 45 design, the maintenance and the management of a CPS: every professional takes care of a different aspect of a subsystem, using a specialized view on it that privileges his responsibilities and the modus operandi typical of his field. Building up a comprehensive model of the system could then benefit from the application of an approach that allows model composition and use of different modelling approaches together in a coordinated framework, such as multiformalism [5] or multiparadigm [6] modelling. For what is related to the design and the analysis of non functional specifications of system components, some frameworks exist that allow multiformalism modelling for non functional specifications by providing, by means of metamodelling, the ability of designing new modelling languages that can be naturally integrated with existing ones and support modularity and multformalism: e.g., the SIMTHESys approach [7] explores these possibilities and is being extended to include also support for a domain, hybrid systems [8], that includes CPS. The main directions behind this approach aim to decouple whenever possible the state spaces of the various components (with significant results in favourable cases [9]), build natural interactions between models written in different modelling languages, and representing emerging properties of the overall model. Leveraging this experience, it is possible to abstract the main ideas and take inspiration for implementing ideally similar compositional and modular features in modelling approaches that focus on aspects that are different from non functional specification. In this paper we want to discuss the applicability of some of the concepts here presented about non functional specifications to a more abstract modelling domain, specially focusing of the perspective that allows the application of the 2HMD approach. CPS involves transdisciplinary approaches, merging theory of cybernetics, mech-tronics, design and process science [10], [11], [12] The process control is often referred to as embedded systems. In embedded systems the emphasis tends to be more on the computational elements, and less on an intense link between the computational and physical elements. CPS is also similar to the Internet of Things (IoT) sharing the same basic architecture, nevertheless, CPS presents a higher combination and coordination between physical and computational elements [13]. As far as CPS are multidisciplinary heterogeneous systems, its implementations requires the strategy of modelling, decomposition into smaller components and their composition into the whole system. The components of such systems then should be detailed at the same level of abstraction. One of those systems is Ensemble Component-Based Systems [14][15], where components are autonomous and the communication is implicit. Needless to say that emergent systems as an up-and-coming systems introduce new concepts for design [14][16] as well as for whole system development process. Working with such distributed systems require dynamicity and scalability with reserving to the autonomous behavior in each component. This allows designers to have 46 their focus on individual components, and work on developing the links between computational and physical elements for each individual alone. In those terms, [17][18] introduce approaches to capture internal and external uncertainty in the system, and handle it during adaptation process by linking the physical elements in the same abstraction level as computational ones. In [17], the work presented Ordinary Differential Equations (ODE) for physical objects at the process level. The goal is to capture the impact of delays, which are caused by networks or computational parts, on physical elements (i.e. actuators). The method allows to enhance prediction of the real state boundaries of each physical object. While [18] targets the uncertainty caused by sensor readings, where the precision of sensed data is the main concern. The effect of data precision is represented in self-adaptation process, where the authors extend mode-switch logic to involve statistical testing. The extended logic applies hypothesis testing over historical data to evaluate the condition in mode-switching with a certain confidence level. Worth to mention that mode-switch conditions deal with short time prediction as well as the current situation. At the end, both kind of uncertainty is captured explicitly in the architectural view allowing for applying traditional analysis and transformations with a minimum amount of modification on the existing tools. We can discuss the issue of decomposition in the context of multiagent systems also. Sometimes, the complex interactions between the individual agents give rise to an emergent behaviour of the system as a whole, e.g. in modelling social systems, traffic simulations, etc. However, other applications can benefit from system decomposition, e.g. agent-based business process modelling. A tool that is often used in this situation is the visual notation of Role-Activity Diagrams [19]. They contain roles, which describe the behaviour of a set of role instances. Roles have states, similarly to dynamic systems. A business process may contain one or more active instances of the same role. An actor is an agent that enacts a role instance. Activities are the basic building blocks of a role. Carrying out the activities of a role can be interpreted as transferring the process control from a state to another state. An activity may be carried out in isolation or may require coordination with activities in other roles, and in this case it is an interaction. Some studies showed that this class of workflows can be formalized and modelled by a concise set of distinct rules in a generic knowledge-based business agent architecture [20] and can be implemented using both agent-oriented languages, such as Jason, and general-purpose functional languages, such as F# [21]. 3 The Essence of the Two-Hemisphere Model-Driven Approach The variety of modelling capabilities and the ability to express links traceability are decisive assets to manage system’s complexity. The transformation tool takes one model as input and produces a second model as its output. Two hemisphere model driven or 2HMD approach [1] proposes using of business process modelling 47 and concept modelling to represent systems in the platform independent manner and describes how to transform business process models into UML models, shown in Figure 1. Fig. 1. The essence of the two-hemisphere model driven approach. Two-hemisphere model consists of two diagrams - business process diagram and conceptual class diagram. The inclusion of these diagrams is not random, it is not only based on the previously mentioned analogy with the human brain, but also based on that information shown in these diagrams helps to describe the system from different points of view, which is important in system development. Business process modelling, as [22] mentioned, developed as a result of solutions made by Management Science and Computer Science in the 1970s. Besides, nowadays the importance of business process modelling has not decreased. The importance of business process modelling is confirmed by [23] regular researches about importance and usability of these processes. Researches confirm that management of business processes is important and companies pays attention to it. This research also shows, that companies over time learn existing business process modelling notations and methodologies. Thereby one advantage 48 of using two-hemisphere model is no need to make additional models to use it, but user can count on, that business model consisting of elements required by two-hemisphere model in the organization already exists. As the two-hemisphere model serves as a bridge between problem domain and software design phase, business model is understandable to both - business people and developers. The inclusion of concept model in the approach is motivated by principles of object-oriented paradigm and general context of data analysis. Usually, at the beginning of software development data dictionary is created or there is any other agreement about terminology used in software development and documentation. [24] describes conceptual modelling as basis of software development, without which good design cannot be performed. Conceptual models are highlevel software description, which contains concepts. Any kind of things, events and living beings that are important to given problem domain can be considered as concepts. Concepts are described with attributes, but methods shows actions specific to these concepts. Peter Chen’s [25] Entity-Relationship (ER) diagram as mentioned by [26] was used in database design, but later it was also used in software system design as conceptual model. [27] indicates, that nowadays it is topical to use ontology not only in artificial intelligence (robot, agent) systems, but also in to create unified terminology, so that all stakeholders could communicate. [28] shows that ontology represents classes of objects, class relations, attributes and axioms. It provides a basis for choosing to use model that represents problem domain concepts as the other model. Therefore the other diagram of two-hemisphere model is conceptual model, consisting of concepts and its attributes, where model notation is similar to the same in ER diagram. 4 2HMD Approach for Solving the Task of Composition The strategy of 2HMD approach supports gradual model transformation from problem domain models into program components, where problem domain models reflect two fundamental things: system functioning (processes) and structure (concepts and their relations). The two hemisphere model has been marked as input with mapping rules, the class diagram and transformation trace has been received on output (see Figure 2). Transformation trace shows the plan how an element of the two hemisphere model is transformed into the corresponding element of the class diagram, and which parts of the mapping are used for transformation of every part of the two hemisphere model [29]. The model decomposition into small components and composition of them as a whole system is a new research topic for 2HMD approach, originally introduced in [30]. The work is ongoing development and evolution. So, there is still no mature foundation to date for this. Our goal through the research on the composition of CPS is to study existing models of composition approaches by analyzing and identifying 1) what are the elements involved in the composition process, and 2) how the model composition is made in these approaches. The ultimate goal is to arrive at an understanding of what is done for model composition in these approaches. 49 Fig. 2. Strategy for Composition ”Model composition is an operation that combines two or more models into a single one.” [31] ”Model composition in its simplest form refers to the mechanism of combining two models into a new one.” [32] According to this, it can be said that the composition model is a process that takes two or more input models, integrates them through an operation and composition to produce a composite output model. However, this scheme is very abstract. No assumptions about the input models, output, or on the compositing operation is expressed. In practice, each approach must specify these assumptions for its work context. These also include the differences to classify approaches. –Mechanism of composition: melting, replacing the union, weaving etc. Element composition: what are the additional elements involved in the composition. There are two classification axes: the type and formality of these. –Language of composition: The composition of elements need formalisms to express them. These formalisms are very diverse because each approach has its own elements of composition. They can be a weaving language, a metamodel of composition rules, a UML profile for model composition, etc [32]. Despite their diversity, they can usually assess a compositional formalism on two points: the composition that provides abstractions and scalability. The idea of decomposition methodology for classification tasks is to break down a complex classification task into several simpler and more manageable subtasks that are solvable by using existing induction methods, then joining their solutions together in order to solve the original problem. Decomposition methodology can be considered as an effective strategy for changing the representation of a classification problem. Indeed, [33], [34] considers decomposition as the most useful form of transformation of data sets”. 50 This decomposition can be applied using a Multi-model approaches: when tackling the complexity of large software systems, separation of concerns is essential for keeping the development process, the produced models and the code manageable. The separation of concerns can be done in different ways, but the objectives are always the same: being able to identify relatively independent ”parts” [35], [36]. To synthesize, we can define the composition as a model management operation, which generates a single model by the combination of the contents of at least two models. The composition has an impact on three levels: 1. Syntactic level: Expression model compound from input models. 2. Semantics level: Assigning a semantic model compound, depending on the semantics of the associated source models. 3. Methodical level: Using the model compound, derived from the composition process in a software development process. Therefore, the composition process cannot be considered as an atomic operation. Before triggering the composition process itself, it is necessary to identify the links between the elements composing; hence the emergence of the pre-match phase followed by a composition operation that aims at the creation of the model ”global” by combining elements using input patterns of relationships defined in the matching pattern. So considering all these all these criteria it’s clear that making a survey on composition techniques and identify their gaps seems an interesting path to build a new composition models operations based on two hemisphere model approach. In another side we suggest using this taxonomy to create a novel composer framework to resolve composition conficts for a given problem. So now we are also studying the made to take into account the semantic properties of models. If we take the example of two operations in two models that appear with the same signature (name, type, parameters), so to remedy this problem, we must either include a step of reconciliation between the separate designs or strengthen semantics associated with the input metamodel, so that we can implement finer comparison strategies that address the behaviors described by the methods. 5 Conclusion The evolutionary nature of CPS aims at building cross-domain intelligence, in heterogeneous and dynamic contexts [37] [38]. For this reason, CPS decomposition should focus on the interactions between the control logic and the physical systems, contemplating the possibility of limited information, e.g., stability, safety, performance, timeliness, etc. CPS decomposition can be performed according to different criteria, from the CPS itself which is a schema of CPS as systems of systems [39], to a hierarchy of components at the architectural level [40]. The common feature among the different decomposition approaches is how they encapsulate the cyber and physical aspects through an infrastructure. The latter should allow the separation of 51 2.1 On the Tolerance of Inconsistencies The development of CPS is necessarily distributed, thus entailing the need for keeping the resulting system specification consistent throughout the process. However, the lessons learned in practice suggest to relax consistency relations in order to allow a more effective development approach. In particular, in general the system might still be at an embryonic state to establish full consistency between the different aspects it is made up of. Moreover, it can happen that some of the inconsistencies naturally disappear as the result of the development. We propose to relax consistency management by exploiting the notion of inconsistency tolerance, that is the system specification has to be consistent when checked for it, but can be inconsistent otherwise [8, 9]. By using this approach it is possible to establish when a system must be consistent and how such a state needs to be tested. It is worth noting that the terms by which consistency is checked implicitly define how important is to keep consistency between certain aspects of the system specification. We have produced preliminary results towards the support of inconsistency tolerance for the development of CPS: in [10] we have discussed the concept of semantic inconsistency and its tolerance. By going into some more details, checking the consistency at semantic level is needed due to the heterogeneous/cross-disciplinary characteristic of CPS sub-systems. Based on this, we introduced inconsistency tolerance relationships as based on the notion of distance between traces of the properties taken into account. In this respect, inconsistencies are tolerated until their distance is limited to a certain threshold, over which consistency needs to be restored in order to keep system development convergent. Inconsistency tolerance does not only save the efforts of continuously keeping the system in a consistent state, but it also save all the resources required to check the consistency itself: in fact, property measurements might be time-consuming and the (sub-)system development has to be necessarily stopped in the meanwhile. 2.2 On the Support of Uncertainty In general, it might happen that some design decisions cannot be taken due to several factors, notably the early stage of development, unknown details, or more simpler because two or more alternatives appear as equally suitable in a specific system development status. In such cases it is desirable to have modelling features to represent the uncertainties rather than being forced to take a premature decision. Uncertainty can be considered as an aspect orthogonal to inconsistencies. In fact, inconsistencies might have multiple valid resolutions, which however have different impacts on other aspects of the system being developed [10]. This becomes evident for CPS, given the semantic gaps between the various domains involved in the realization. As initial contribution, in [11] we proposed an approach to deal with uncertainty in the development of automotive systems. In particular, starting from a high level architecture of the system, multiple valid lower level configurations can be derived. These configurations however have different impacts on timing performances of the system. In order to avoid imposing a premature decision, often only based on development history experience, we introduced a modelling support for keeping equally good configurations to choose from at later stages of the development. 58 2.3 Further Research and Challenges What discussed so far can be considered as initial steps towards the support of inconsistency tolerance and uncertainty in the development of CPS. As expected, a multitude of problems remain to be solved, as well as open research questions, a selection of which is described in the remaining of the section. The misalignment of development methodologies As a consequence of the growth in complexity of delivered products, companies try to adopt more effective development methodologies. However, on the one hand there might not exist mature enough techniques for tackling a certain industrial problem. For instance, the availability of effective tools is still a major hinder for model-driven engineering adoption in industry [12]. On the other hand, for a number of practical reasons such adoptions are step-wise, that is the various departments progressively make a transition towards a newer approach depending on their specific needs, resources, constraints, and so forth. Different development approaches and tools in general entail different levels of abstraction, formalisms, and so forth. This misalignment is a fundamental challenge in CPS development, since it directly affects the effectiveness of consistency management: the wider is the abstraction and semantic gap between different development approaches and the harder it becomes to create an effective consistency support. Moreover, if those gaps have to be manually closed, consistency is jeopardized due to the tediousness and error-proneness of these tasks [13]. The growth of accidental complexity A well known issue intrinsic of any development methodology is the added complexity due to the use of the methodology itself, know as accidental complexity [14]. When systems become complex, as in the case of CPS, the accidental complexity tends to grow remarkably, especially when trying to achieve reliable analysis and simulations results. Separation of concerns is usually recognized as an effective way to reduce accidental complexity, since it narrows down the problem space to a specific point-of-view of the system. However, this solution often boils down to moving accidental complexity from the design of the various aspects of the system to the consistency mechanisms. As a matter of fact, in general each pair of views requires a dedicated, semantics-aware, consistency management. Therefore, the support becomes quickly intractable with the growth of the number of views. A countermeasure to reduce accidental complexity could be the introduction of a (set of) language(s) acting as common denominator(s) and hence allowing automated translations and information transfers between different system points-of-view. However, the characteristics of such languages are still an open research question. The solution space Both inconsistency tolerance and uncertainty rely on leaving open multiple solution alternatives. For CPS such opportunity has to be kept carefully under control, since the size of the solution space might make the proposed techniques practically unusable. In fact, given the number of variables and possible trade-offs, the number of valid alternatives can become unmanageable, especially when decisions cannot be automated, with the risk of obtaining non convergent (infeasible) design options. 59 Another more practical aspect to be considered is that the development of portions of CPS might be outsourced. In such cases uncertainty is not tolerable, since typically the development is bound to a strict contract. The issues mentioned so far could be alleviated by introducing a more suitable development process. Such a process should be CPS aware in the sense that it should allow to establish priorities among system aspects and hence allow a better management of both inconsistencies and uncertainty. In particular, the design space entailed by uncertainties can be constrained by inconsistency tolerance boundaries, where tighter tolerance boundaries mean reduced uncertainty allowance. Also in this case, the subject is an open research question. 3 Conclusions In this paper we discussed some features that we believe it is necessary to support for improving the development of CPS. In particular, we argue that inconsistency tolerance and uncertainty modelling can make the development process smoother and alleviate some issues in the development of complex, cross-disciplinary systems. Despite the growing maturity of modelling methodologies like MPM, there exist still several open research questions to be tackled. These challenges pertain to both scientific concerns as the tractability of complex problems, as well as to more practical aspects as the technological transfer from research to industry [1]. 4 Acknowledgements The author would like to thank Alessio Bucaioni, Federico Ciccozzi, and Alfonso Pierantonio for the interesting discussions on uncertainty support. Moreover, he would like to thank Dominique Blouin, Istv´ an D´ avid, Eugene Syriani, and Ken Vanherpen for the insightful idea exchanges on the inconsistency tolerance topic during the 2016 CAMPaM workshop. References 1. Vangheluwe, H., Amaral, V.: Memorandum of Understanding for the implementation of a European Concerted Research Action designated as COST Action IC1404: Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS). http://www.cost.eu/COST Actions/ict/IC1404 (2014) 2. Pradhan, S.M., Dubey, A., Gokhale, A., Lehofer, M.: CHARIOT: A Domain Specific Language for Extensible Cyber-physical Systems. In: Proceedings of the Workshop on DomainSpecific Modeling. DSM 2015, New York, NY, USA, ACM (2015) 9–16 3. Sch¨ atz, B., T¨ orngren, M., Bensalem, S., Cengarle, M.V., Pfeifer, H., McDermid, J., Passerone, R., Sangiovanni-Vincentelli, A.: D6.1+2 - Integrated CPS Research Agenda and Recommendations for Action. http://cyphers.eu/sites/default/files/d6.1+2-report.pdf (2015) 4. Ciccozzi, F., Crnkovic, I., Di Ruscio, D., Malavolta, I., Pelliccione, P., Spalazzese, R.: Model-driven engineering: a facilitator for engineering mission-critical IoT systems. IEEE Software (2016) 1–14 60 5. Persson, M., T¨ orngren, M., Qamar, A., Westman, J., Biehl, M., Tripakis, S., Vangheluwe, H., Denil, J.: A characterization of integrated multi-view modeling in the context of embedded and cyber-physical systems. In: Proceedings of the Eleventh ACM International Conference on Embedded Software. EMSOFT ’13, Piscataway, NJ, USA, IEEE Press (2013) 10:1–10:10 6. Mosterman, P.J., Vangheluwe, H.: Computer automated multi-paradigm modeling: An introduction. SIMULATION 80 (2004) 433–450 7. Mossinger, J.: Software in automotive systems. IEEE Software 27 (2010) 92–94 8. Balzer, R.: Tolerating inconsistency. In: 13th International Conference on Software Engineering. (1991) 158–165 9. Finkelstein, A.: A foolish consistency: Technical challenges in consistency management. In Ibrahim, M., K¨ ung, J., Revell, N., eds.: Database and Expert Systems Applications. Volume 1873 of Lecture Notes in Computer Science. Springer Berlin Heidelberg (2000) 1–5 10. D´ avid, I., Syriani, E., Verbrugge, C., Buchs, D., Blouin, D., Cicchetti, A., Vanherpen, K.: Towards inconsistency tolerance by quantification of semantic inconsistencies. In: Procs. of the 1st Int. Workshop on Collaborative Modelling in MDE (COMMitMDE 2016) at MoDELS 2016, Saint Malo (France). CEUR-WS, CEUR Workshop Proceedings (2016) 11. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Mubeen, S., Sj¨ odin, M., Pierantonio, A.: Handling uncertainty in automatically generated implementation models in the automotive domain. In: Procs. of the 42nd Euromicro Conference series on Software Engineering and Advanced Applications (SEAA 2016), Limassol (Cyprus), IEEE Computer Society (2016) 12. Whittle, J., Hutchinson, J., Rouncefield, M., Burden, H., Heldal, R.: Industrial adoption of model-driven engineering: Are the tools really the problem? In: Proceedings of the 16th International Conference on Model-Driven Engineering Languages and Systems - Volume 8107, New York, NY, USA, Springer-Verlag New York, Inc. (2013) 1–17 13. Selic, B., Gullekson, G., McGee, J., Engelberg, I.: Room: an object-oriented methodology for developing real-time systems. In: Computer-Aided Software Engineering, 1992. Proceedings., Fifth International Workshop on, IEEE (1992) 230–240 14. Brooks, Jr., F.P.: No silver bullet. essence and accidents of software engineering. Computer 20 (1987) 10–19 61 http://d3s.mff.cuni.cz CHARLES UNIVERSITY IN PRAGUE )DFXOW\RI0DWKHPDWLFVDQG3K\VLFV Multi-paradigm aspects of component ensembles Tomas Bures [email protected].cuni.cz 2 Context: Software Architectures Software composed of components Large-scale distribution, mobility Runtime evolution of the architecture Software adapts to environment (environmental uncertainty) Software adapts based on health of the system (internal uncertainty) Connections change due to mobility 62 3 System of Interacting Components source: National Science Foundation (nsf.gov) Smart planes for safe air travel Smart buildings Smart vehicles Smart highways Inteligent sensors for cleaner water resources Energy-efficient power grid Smart applicances in energy-efficient homes Robots at work and play Assistive medical devices help patients enjoy independence s Smart navigational devices so parents and children stay connected Many components with different functions Ad-hoc interaction Collaboration in localized groups Principal autonomy 4 Our Approach Dynamic architecture models (ADLs) Components Ensembles – dynamic collaboration groups Architecture is the central hub for MPM; in addition to structure, it: Says how the systems evolves and how its different component collaborate on achieving system’s goals Provides domain knowledge that allow optimizing distributed (e.g. MANET) communication Specifies physical models of data being observed Allows for filtering and prediction Reconfiguration of architecture if data become faulty 63 5 Example Cooperative Adaptive Cruise Control-like system A car follows another, keeps in a safe distance behind it The car in front sends over wireless its position, speed, acceleration The car in the back does dead-reckoning to know whether it should adapt its behavior (i.e switch architecture mode) 6 component Vehicle // leader’s role knowledge: position, velocity, ... state-space-models: [leader.position, leader.velocity]: maxDecTable = {0 -> -6, 35 -> -5, 51 -> -3} maxAccTable = {0 -> 4, 35 ->3, 51 -> 0} process measurePosition(out position): scheduling: periodic( 100ms ) process driveUsingCACC(…): mode-trigger: possible-min (distance(position, leaderPosition)) <= THRESHOLD process computeAccelerationACC(in distance, in velocityDifference, out targetAcc): mode-trigger: possible-min(distance(position, leaderPosition)) > THRESHOLD … ensemble UpdateLeaderPositionAndVelocity membership roles leader: Vehicle follower: Vehicle condition distance(coordinator.position, member.position) ч2 * DESIRED_DISTANCE knowledge exchange coordinator.leaderPosition іĐůŽƐĞƐƚ;coordinator.position, members).position coordinator.leaderVelocity іĐůŽƐĞƐƚ;coordinator.position, members).velocity scheduling periodic( 200ms ) Dynamic cooperation group. Comes to existence when a car in the back reches the car in front. Linear state space model of car’s movement Represented here as tables for lookup of max. deceleration/acceleration based on current velocity. The tables consist of tuples (velocity (in m/s) -> acceleration (in m/s2)) 64 7 Example Robot exploration on a set of islands Dynamically appearing beacons on a set of islands A number of robots deployed on the islands Robots exchange information about beacons they have discovered Each beacon has to be reached and “handled” by a pair of robots in the shortest time 7 7 the shortest tim e 8 component Robot knowledge position // robot’s position beaconPosition // targeted beacon position islandID // island, on which the robot is located beaconPositions // positions of known beacons ensemble BeaconInformationExchange id islandID membership roles source: Robot target: Robot condition source != target knowledge exchange target.beaconPositions = target.beaconPositions.unionWith(source.beaconPositions) communication constraints boundary relay: RobotRelay, replica: Robot relay.islandID == replica.islandID Restricts information exchange to an island only. Reflects the domain knowledge that a robot can’t get from one island to another. 65 9 ensemble ForSingleBeacon id beaconPosition // targeted beacon position membership roles robotsAssignedForBeacon[2]: Robot condition robotsAssignedForBeacon[0].islandID == robotsAssignedForBeacon[1].islandID == islandIDOf(beaconPosition) fitness max(distance(robotsAssignedForBeacon[0].position, beaconPosition), distance(robotsAssignedForBeacon[1].position, beaconPosition)) knowledge exchange robotsAssignedForBeacon[0].beaconPosition = beaconPosition robotsAssignedForBeacon[1].beaconPosition = beaconPosition communication constraints boundary relay: RobotRelay, replica: Robot relay.islandID == replica.islandID optimization smallestRadius > 10m max staleness beaconPostion 30s Provides bounds to communication optimization. Expresses the domain knowledge that (a) in order for a system to work, robot pairs have to be looked up in at least 10 m radius around the beacon (reflects the expected density of robots; (b) robots move so fast that any information about robot’s position older than 30s has no relevancy for the system. Dynamic cooperation group. Comes to existence when a beacon appears. Selects the closest robots. 10 Some References Masrur A., Kit M., DĂƚĢŶĂ V., Bureš T., Hardt W.: Component-Based Design of CyberPhysical Applications with Safety-Critical Requirements, Accepted for publication in Microprocessors and Microsystems, March 2016 Gerostathopoulos I., Škoda D., Plášil F., Bureš T., Knauss A.: Architectural Homeostasis in Self-Adaptive Software-Intensive Cyber-Physical Systems, In Proceedings of ECSA 2016, Istanbul, Turkey, LNCS 9839, Springer, to appear, September 2016 Bureš T., ,ŶĢƚLJŶŬĂ P., <ŽĨƌŽŸ J., Al Ali R., Škoda D.: Statistical Approach to Architecture Modes in Smart Cyber Physical Systems, Proceedings of WICSA 2016, Venice, Italy, IEEE, pp. 168-177, doi: 10.1109/WICSA.2016.33, April 2016 DĂƚĢŶĂ V., Bureš T., Gerostathopoulos I., ,ŶĢƚLJŶŬĂ P.: Model Problem and Testbed for Experiments with Adaptation in Smart Cyber-Physical Systems, In Proceedings of SEAMS 2016, Austin, USA, ACM, doi:10.1145/2897053.2897065, May 2016 Kit M., Plášil F., DĂƚĢŶĂ V., Bureš T., Kovac O.: Employing Domain Knowledge for Optimizing Component Communication, Accepted for publication in Proceedings of the 18th International ACM Sigsoft Symposium on Component-Based Software Engineering, May 2015 Bureš T., Krijt F., Plášil F., ,ŶĢƚLJŶŬĂ P., :ŝƌĄēĞŬ Z.: Towards Intelligent Ensembles, In Proceedings of the 9th European Conference on Software Architecture Workshops (ECSAW 2015). Article No. 17. ACM., September 2015 Al Ali R., Bureš T., Gerostathopoulos I., Keznikl J., Plášil F.: Architecture Adaptation Based on Belief Inaccuracy Estimation, Proceedings of the 11th Working IEEE/IFIP Conference on Software Architecture (WICSA 2014), Sydney, Australia. IEEE, pp. 87-90, April 2014 66 http://d3s.mff.cuni.cz CHARLES UNIVERSITY IN PRAGUE )DFXOW\RI0DWKHPDWLFVDQG3K\VLFV Statistical Approach to Architecture Modes in Smart Cyber Physical Systems Tomas Bures, Petr Hnetynka, Jan Kofron, Rima Al-Ali, Dominik Skoda 2 Context: Cyber-Physical Systems (CPS) Collaborating computational elements controlling physical entities Designed as a network of interacting elements with physical input and output Uncertainty 67   D+%$+$ '+#)AE + 3B@AF $$)'$3%#$"3*+-$-3,","$)3+)5%*+)#$3 )+$&)$)$3*$#)3$*$",. )%"#++#$+ B %$+)%"$$) $"$$) #$$) 74 %$+)+7**$8 ++7%7+7)+ $+%$%%$+)+ )%')+%)* %$ ,$+%$4 %#'%*+%$4 $#$+4 C %$+)%" $" # $+)%" #   %$+)+  %$+)+ ABK93:.+4KAB KAMB ABK93:.+4K9AB:L9AMB: KAMB AB4BA BB  ! ++%+)+ 5$-$*+ +"5%$+)+*%)0*+#**$4%)05 5'57HGEI33B@AE5 "#$+)0(,)#$+*%.)$%. A5 '%.).$%.*%,"*+)+#%-$.+$B@@#* +)%##$***,5 B5 '%.).$%.*"",""0%'$%)"%* .+$D5E*5 C5 $"%*$+'%.).$%.3%)%$%#%) +$A@@#0')*$+5 D5 ++%$%"#'% +.$"%*$+.$%. *%,""%.)+.$%.0A@#5 D 75 0*+#%$+)+%.)$%. Power window system button_up button_down pinch_F cmd_up cmd_down E **,#'+%$*  ."""%.)+$A@@@5  %,)**'%).+#$#,#')%%A@@#*5  %,)**'%).+#$#,#')%%A@@#* ,)$+* "0+.$ $ .+$;@#*3B@@#*<5 "0+.$ $ .+$;@#*3B@@#*<5 /#,#+-+%$+# .+$;@#*3D5E*<5 /#,#+-+%$+# .+$;@#*3D5E*<5  /*A@@3"0+.$ $ .+$;@#*3A#*<5  /*A@@3+-+%$+# .+$;@3DC*3@5DC*<5 %#'%*+%$%+%.)$%.0*+# Control 1 button_up button_down up_out down_out Control 2 pinch_F cmd_up cmd_down up_in down_in CAN button_up button_down up_out down_out ECU 1 ECU 2 pinch_F cmd_up cmd_down up_in down_in button_up button_down pinch_F Power window system Control component Hardware component cmd_up cmd_down F 76 ''""+0%+,))$++%%"%*%$ %7*$$$)$)%"# Control 1 button_up button_down up_out down_out Control 2 pinch_F cmd_up cmd_down up_in down_in CAN button_up button_down up_out down_out ECU 1 ECU 2 pinch_F cmd_up cmd_down up_in down_in button_up button_down pinch_F Power window system Control component Cyber component cmd_up cmd_down G **,#'+%$*  %,)**'%).+#$#,#')%%E@#*5  %,)**'%).+#$#,#')%%B#*5 ,)$+* "0+.$ $ .+$;@#*3EB#*<5 **,#'+%$*  %,)**'%).+#$#,#')%%D@#*5  %,)*D@#*5 "0+.$ $ .+$;@#*3A@#*<5 ,)$+* .$-) %,)*3 %,)*5 #)%,)*A@#*5 "0+.$ $,' .+$;B@@,*3A@#* JA5C#*<5 ''""+0%+,))$++%%"%*%$ %7*$$$)$)%"# Control 1 button_up button_down up_out down_out Control 2 pinch_F cmd_up cmd_down up_in down_in CAN button_up button_down up_out down_out ECU 1 ECU 2 pinch_F cmd_up cmd_down up_in down_in button_up button_down pinch_F Power window system Control component Cyber component cmd_up cmd_down H 77 ''""+0%+,))$++%%"%*%$ %7*$$$)$)%"# %)+%#$*4  %#$%$+)+%$+$*')%')+*%$.+ %#$$$)"!*+"+0+%)*%$%,+  %")*')+%$+.$.+***,#)%# +%+)%#$9*:$.+*%,",)$+ ,$)+*%$+%$* I %$+)+7*%7*$+%%"%0 *%$$+%"%"*%$$4 A@ Real World (RW) Control Engineer HW/SW Engineer Conforms to Transforms Checks satisfaction Holds Represents 5$)'$+"5 $+%"%"*%$$%)%$**+$0$+*$%0)70*"0*+#*5 B@AF5 78 %$+)+7*%7*$+%%"%0 *%$$+%"%"*%$$4 AA P r o p e r t i e s Real World (RW) Control Engineer HW/SW Engineer Ontological World Conforms to Transforms Checks satisfaction Holds Represents 5$)'$+"5 $+%"%"*%$$%)%$**+$0$+*$%0)70*"0*+#*5 B@AF5 %$+)+7*%7*$+%%"%0 *%$$+%"%"*%$$4 AB P r o p e r t i e s Real World (RW) Control Engineer HW/SW Engineer Ontological World Linguistic World Performance Value I (PV I ) Model I [[.]] Model II Performance Value II (PV II ) [[.]] Conforms to Transforms Checks satisfaction Holds Represents 5$)'$+"5 $+%"%"*%$$%)%$**+$0$+*$%0)70*"0*+#*5 B@AF5 79 %$+)+7*%7*$+%%"%0 *%$$+%"%"*%$$4 AC P r o p e r t i e s Real World (RW) Control Engineer HW/SW Engineer Ontological World Linguistic World Prop II =f(PV II ) Prop I =f(PV I ) Performance Value I (PV I ) Model I [[.]] Model II Performance Value II (PV II ) [[.]] Conforms to Transforms Checks satisfaction Holds Represents 5$)'$+"5 $+%"%"*%$$%)%$**+$0$+*$%0)70*"0*+#*5 B@AF5 %$+)+7*%7*$+%%"%0 *A8 %++%$ AD Assumptions Guarantees Max E-E Latency Comp1 = 199 ms Max E-E Latency Comp2 = 1 ms 250 us  Periodicity Comp2  750 us Processor Clock = 1 MHz # instr Comp2 = 1000 200 us  Periodicity Comp1  100 ms # instr Comp1 = 200 Processor Clock = 8 MHz Min interval inputs = 100 ms Max comm time = 50 ms Control Mapping Mapping Hardware 5$)'$+"5 $+%"%"*%$$*$$")%%$+)+7*%7*$5 00 B@AF5 80 %$+)+7*%7*$+%%"%0 *A8 %++%$ AE Assumptions Guarantees Max E-E Latency Comp1 = 199 ms Max E-E Latency Comp2 = 1 ms 250 us  Periodicity Comp2  750 us Processor Clock = 1 MHz # instr Comp2 = 1000 200 us  Periodicity Comp1  100 ms # instr Comp1 = 200 Processor Clock = 8 MHz Min interval inputs = 100 ms Max comm time = 50 ms Reaction Performance Mapping Schedulability Load Cost Safety System SW Architecture HW Architecture Control Mapping Mapping Hardware 5$)'$+"5 $+%"%"*%$$*$$")%%$+)+7*%7*$5 00 B@AF5 %$+)+7*%7*$+%%"%0 *A8 %++%$ AF Assumptions Guarantees Max E-E Latency Comp1 = 199 ms Max E-E Latency Comp2 = 1 ms 250 us  Periodicity Comp2  750 us Processor Clock = 1 MHz # instr Comp2 = 1000 200 us  Periodicity Comp1  100 ms # instr Comp1 = 200 Processor Clock = 8 MHz Min interval inputs = 100 ms Max comm time = 50 ms Reaction Performance Mapping Schedulability Load Cost Safety System SW Architecture HW Architecture Control Mapping Mapping Hardware 5$)'$+"5 $+%"%"*%$$*$$")%%$+)+7*%7*$5 00 B@AF5 81 %$+)+7*%7*$+%%"%0 *B8 )-$+%#$%$+)+* AG Max E-E Latency Control1->2 = 199 ms Min interval inputs = 100 ms # instr SWC1 = 200 Assumptions Guarantees Assumptions Guarantees Max E-E Latency Comp1 = 199 ms Max E-E Latency Comp2 = 1 ms 250 us  Periodicity Comp2  750 us Processor Clock = 1 MHz # instr Comp2 = 1000 200 us  Periodicity Comp1  100 ms # instr Comp1 = 200 Processor Clock = 8 MHz Min interval inputs = 100 ms Max comm time = 50 ms Assumptions Guarantees Max E-E Latency ECU1->2 = 199 ms Min interval inputs = 100 ms WCET 1 = 200 us Clock = 1MHz 200 us  T1  100 ms Reaction Performance Mapping Schedulability Load Cost Safety System SW Architecture HW Architecture Control Mapping Mapping Hardware 5$)'$+"5 $+%"%"*%$$*$$")%%$+)+7*%7*$5 00 B@AF5 %$+)+7*%7*$+%%"%0 *C8 $#$+%+%#$%$+)+* AH Assumptions Guarantees Max E-E Latency Run1 = 199 ms Processor Clock = 1 MHz 200 us  Periodicity Comp1  100 ms # instr Comp1 = 200 Min interval inputs = 100 ms Assumptions 1 Guarantees 1 # instr SWC1 = 200 Max E-E Latency Control1->2 = 199 ms Min interval inputs = 100 ms T1 = 50 ms Assumptions 1 Guarantees 1 Max E-E Latency ECU1->2 = 199 ms Min interval inputs = 100 ms WCET 1 = 200 us Load = 30 % Clock = 1MHz T1 = 50 ms P1 = 1 WRT 1 = 1.3 ms Control Mapping Mapping Hardware Reaction Performance Mapping Schedulability Load Cost Safety System SW Architecture HW Architecture 5$)'$+"5 $+%"%"*%$$*$$")%%$+)+7*%7*$5 00 B@AF5 82  $5$$)'$6!$5-$)'$=,$+.)'5 AI 83 Semantic-aided enterprise application integration Gdaŷsk, 2016 About us Željko Vukoviđ •University of Novi Sad •Faculty of Technical Sciences •Chair of Informatics Nikola Milanoviđ •OPTIMAL SYSTEMS GmbH •Berlin M AL S Y S TEM S G m ity o f No vi Sad zeljko[email protected] 90 Our goal •Automate or semi-automate: •Interface mapping in enterprise application integration •Detection and resolution of semantic conflicts •Enterprise application integration •Persuading into cooperation things that were not originally meant to work together Approach Structural interface models (fields, types) Semantics (Ontologies) Combine (annotate) Map (based on defined criteria) Detect & resolve conflicts Generate integration code Criterion definition: Java, SAIL DSL OWL Java 91 Implementation •Mod of Talend Open Studio www.talend.com/products/talend-open-studio •plenty of connectors available (databases, flat files, web services, …) •can model processes, interaction •extendable •open-source 92 How we relate? •If physical things have a cyber interface, we can integrate them •Fire alarm? 2001:0db8:85a3:0000:0000:8a2e:0370:7334 •Call fire brigade 112 •Cut electrical power 2001:db8:a0b:12f0::1 •Formalisms •Talend, UML, XML, OWL, Java, SAIL DSL 93 Published work •Vukoviđ, Željko, et al. "SAIL: A Domain-Specific Language for Semantic-Aided Automation of Interface Mapping in Enterprise Integration." OTM Confederated International Conferences" On the Move to Meaningful Internet Systems". Springer International Publishing, 2015. •Vukoviđ, Ž., Milanoviđ, N., Vaderna, R., Dejanoviđ, I., Milosavljeviđ, G. and Malbaša, V., Semantic-aided automation of interface mapping in enterprise integration with conflict detection. Information Systems and e-Business Management, pp.1-18.; 2016 94       !"!#  #! ! # "!!#$#$!        #% &! ' !!" !(# " (  )*+$ ,"!  ( " !  +!+ !! ""  !#%-##    95 !(   ./!   &!#'  %#  ! %!# #%#!% 0$#12! 3!  "!  # '   +'  " ! !!!!!+% )!(#% (  "! &4'  #  " !  5#  # $!!"  #0!1"# !  !!"   # 6(0#(1    ! !071(  96  ! 2 (!!&'!(  "!"!( "! !!!+  .!#  !(  !#0# 1  #  # (" "!#6"  "# ! $%&' 97  !  (' )* )+ ')+*  ,, )+)* 8!(! (# !! (# ( !01  !%9#+%,8)5:() ); 3 #  .) "# ! 98  !    !   99  &\EHU3K\VLFDO6\VWHPV&36DUHKHWHURJHQHRXVV\VWHPVZKLFKRIIHU ± UHOLDELOLW\SHUIRUPDQFHDQGUREXVWQHVVWRDOORZFRPSDQLHVWREHFRPSHWLWLYH 7RFRSHZLWKWKHFRPSOH[LW\RIWKHH[HFXWLRQRIVXFKLWLVQHFHVVDU\WR GHILQHDQDSSURDFKWRWDPHLWVFRPSOH[LW\ 7KLVDSSURDFKVKRXOGEHIOH[LEOHDQGJHQHULFLQRUGHUWRDGDSWWRDQ\W\SHRI FRPSRQHQWRIVXFKV\VWHPDQGWKXVVKRXOGRIIHUDQDELOLW\WRPDQDJH V\VWHPLQWHJULW\ 7KH7ZRKHPLVSKHUHPRGHOGULYHQ+0'DSSURDFKKDVEHHQVXFFHVVIXOO\ DSSOLHGIRUGRPDLQPRGHOOLQJDQGVRIWZDUHGHVLJQDQGLVDSSOLFDEOHIRUERWK KXPDQXQGHUVWDQGLQJDQGDXWRPDWLFWUDQVIRUPDWLRQV ± &DQEHDSSOLHGIRUPRGHOOLQJRIVXFKFRPSOH[V\VWHPDV&36ZKHUH FRPSRQHQWVRI&36PD\EHFRQVLGHUHGDVDFRQFHSWXDOFODVVHVZKLFKSUHIRUP WKHSDUWLFXODURSHUDWLRQVDQGPHHWWKHGHILQHGUHTXLUHPHQWV ± 7KHUHTXLUHPHQWVIRUGLIIHUHQWFRPSRQHQWVFDQEHSUHVHQWHGE\VHSDUDWH SURFHVVPRGHOVXQGHUWKHXQLILHGFRQFHSWXDOFODVVPRGHO ± +0'DSSURDFKFDQKHOSWRLGHQWLI\FRQIOLFWVLWXDWLRQVZKHUHWKHDGGLWLRQDO DQDO\VLVLVUHTXLUHGWRVKDUHUHVSRQVLELOLWLHVEHWZHHQV\VWHPFRPSRQHQWV $SSOLFDWLRQRIWKH7ZR+HPLVSKHUH0RGHOIRU 0RGHOOLQJRI&36  7ZRKHPLVSKHUHPRGHOEDVHG WUDQVIRUPDWLRQV  7KHWZRKHPLVSKHUHPRGHOFRQVLVWVRI  3URFHVVGLDJUDPSUHVHQWVVWHSVRIV\VWHPEHKDYLRXURUVFHQDULRDQG GHILQHV - internal processes of the system enclosed by external processes performed by a set of performers. - data flow coming from one process to another, «structurally» defined by a conceptual class, called concept.  &RQFHSWGLDJUDPSUHVHQWVFRQFHSWXDOFODVVHVRIWKHV\VWHPDQGLV VLPLODUWR(5GLDJUDPZLWKRXWUHODWLRQVKLSV  7KHPRGHOFDQKDYHRQHRUPDQ\SURFHVVGLDJUDPVVFHQDULRVDQGRQO\ RQHJHQHUDOIRUWKHZKROHV\VWHPFRQFHSWGLDJUDP 106   7UDQVIRUPDWLRQV DUHEDVHGRQ WKHGLUHFWWUDQVIRUPDWLRQRI JUDSKVZKHUHQRGHVRIRQH JUDSKEHFRPHWKHHGJHVRIWKH RWKHUJUDSKDQGHGJHVRIWKH ILUVWJUDSKEHFRPHWKHQRGHV RIWKHRWKHU 7ZRKHPLVSKHUHPRGHO EDVHG WUDQVIRUPDWLRQV   7KHPHDQLQJRIREMHFWVLQDQ REMHFWRULHQWHGSKLORVRSK\ JLYHVDSRVVLELOLW\WRVKDUH UHVSRQVLELOLWLHVZKHUHWKHGDWD IORZRXWJRLQJIURPWKHLQWHUQDO SURFHVVEHFRPHVWKHRZQHURI WKLVSURFHVVIRUSHUIRUPLQJLWDV DQRSHUDWLRQ 7ZRKHPLVSKHUHPRGHO EDVHG WUDQVIRUPDWLRQV 107  7ZRKHPLVSKHUHPRGHO EDVHG WUDQVIRUPDWLRQV IRU 80/FODVV GLDJUDP   7KHVDPHSULQFLSOHLV XVHG  3URFHVVHVDUH WUDQVIRUPHGLQWR PHVVDJHV  &RQFHSWVKHOSWR GHWHUPLQHVHQGHUV DQGUHFHLYHUV  3HUIRUPHUVDVVLJQHG WRH[WHUQDOSURFHVVHV EHFRPHDFWRUV 7ZRKHPLVSKHUHPRGHOEDVHGWUDQVIRUPDWLRQV IRU80/VHTXHQFHGLDJUDP 108  %UDLQ7RRO WRVXSSRUW 7ZR+HPLVSKHUH 0RGHO 'ULYHQ $SSURDFK 9  $QGUHMV5RPDQRYV'UVFLQJ0%$ DVVRFLDWHSURIHVVRU OHDGLQJUHVHDUFKHU 5LJD 7HFKQLFDO 8QLYHUVLW\ )DFXOW\RI&RPSXWHU6FLHQFH DQG,QIRUPDWLRQ7HFKQRORJ\ ,QIRUPDWLRQ7HFKQRORJ\,QVWLWXWH  'DXJDYJULYDV 6WU RIILFH5LJD/DWYLD &RQWDFWV DQGUHMVURPDQRYV#UWXOY 109  2%-(&7,9(6 7R GHYHORS PHWKRGV IRU QDWXUDOWHFKQRORJLFDO V\VWHPV 176 LQWHJUDWHG PRGHOOLQJ DQG VLPXODWLRQ LQFOXGLQJ UHFRQILJXUDWLRQ RI WKHVH V\VWHPV XQGHU GHJUDGDWLRQ SURFHVV RI WKHLU VWUXFWXUHV 7R GHYHORS PHWKRGV IRU LQIRUPDWLRQ UHSUHVHQWDWLRQ XQGHU FRQGLWLRQV RI G\QDPLFV VWUXFWXUH DQG GDWD XQFHUWDLQW\ 7R GHYHORS PRGHO DQG PHWKRG RI 176 PRQLWRULQJ DQG FRQWURO V\VWHPV G\QDPLF UHFRQILJXUDWLRQ 7R GHYHORS DQ LQQRYDWLYH LQIRUPDWLRQ WHFKQRORJ\ DQG D FRPSOH[ F\EHUSK\VLFDO V\VWHP IRU DQDO\VLV DQG V\QWKHVLV RI DQ LQWHJUDWHG LQWHOOLJHQW SODWIRUP IRU 176 PRQLWRULQJ DQG FRQWURO EDVHG RQ LQWHJUDWLQJ KHWHURJHQHRXV LQIRUPDWLRQ UHFHLYHG IURP VSDFH DQG JURXQGEDVHG VHQVRUV IDFLOLWLHV RWKHU LQGXVWULDO V\VWHPV DQG LQGLYLGXDOV ,1)520,77HFKQRORJ\'HVLJQDQG 'HYHORSPHQW  )XQGDPHQWDOVFLHQWLILFEDVH 110  6WUXFWXUDOPRGHORI,1)520LQWHOOLJHQW WHFKQRORJ\  )UDPHZRUNIRULQWHJUDWHGUHPRWHVHQVLQJDQG PRQLWRULQJ 111  +LJK/HYHO 6\VWHP $UFKLWHFWXUH    'HPRQVWUDWLRQFDVHDQGUHDOWLPHH[SHULPHQWV 0DWFKLQJEHWZHHQVLPXODWLRQUHVXOWVDQG KLVWRULFDOGDWD %DVHGRQWKHZDWHUIORZGLVFKDUJHGDWDDQGDGLJLWDOHOHYDWLRQPRGHO/,6)/22'EDVHGK\GURORJLFDO PRGHOLVEXLOWZKLFKDOORZIRUHFDVWLQJLQXQGDWLRQWHUULWRULHVDORQJWKHULYHUEDVLQ 7R WHVW DQG YDOLGDWH WKH PRGHO WKH IORRG VLPXODWLRQ UHVXOWV KDYH EHHQ FRPSDUHG ZLWK DYDLODEOH KLVWRULFDO GDWD RQ WKH IORRGHG ]RQHV LQ WKH UHVHDUFK DUHD LQ 0DUFK$SULO  7KH ERXQGV RI WKH LQXQGDWLRQ DUHD IURP VLPXODWLRQ H[SHULPHQWV DUH FORVH WR KLVWRULFDO GDWD DQG D IRUHFDVW HUURU LV OHVV WKDW  3HUIRUPHG UHDOWLPH H[SHULPHQWV ZLWK WKH GHYHORSHG PRGHO DOORZHG DFKLHYLQJ DERXW  FRQILGHQFH LQ IORRG IRUHFDVWV UHJDUGLQJ VLJQLILFDQW REMHFWV ZKLFK ZHUH DFWXDOO\ LQXQGDWHG ODWHU RQ 7KH KLJK IRUHFDVW SUHFLVLRQ LV DFKLHYHG WKURXJK FRQWLQXRXV XSGDWLQJ RI LQSXW SDUDPHWHUV DQG DULVLQJ RXW VKRUWWHUP IRUHFDVWV 6DPSOHIORRGLQJIRUHFDVWLQ'DXJDYSLOV 7KH /,6)/22'+3 K\GURORJLFDO PRGHO JHQHUDWHV KRXU IRUHFDVWV RI LQXQGDWLRQ ]RQHV KRXUO\ 7KH UHVXOWV RI IORRG VLPXODWLRQ DUH SUHVHQWHG DV D UDVWHU PDS ZLWK LQIRUPDWLRQ DERXW WKH GHSWK RI ZDWHU LQ WKH IORRGHG WHUULWRU\ ZKLFK DXWRPDWLFDOO\ YHFWRUL]HG WR SURYLGH WKHLU FRPSDWLELOLW\ ZLWK WKH H[WHUQDO *,6 VRIWZDUH DQG VWRUH WKHP LQ WKH GDWDEDVH DV DUFKLYDO LQIRUPDWLRQ DERXW IORRG G\QDPLFV 112  ,1)5206HQVRU:HE  6RFLDODQG6HQVRU'DWD)XVLRQ 7KHWZRSRSXODUGDWDW\SHVVRFLDODQGVHQVRUGDWDDUH LQIDFW PXWXDOO\FRPSHQVDWRU\LQYDULRXVGDWDSURFHVVLQJDQGDQDO\VLV 3DUWLFLSDWRU\FLWL]HQVHQVLQJIRULQVWDQFHHQDEOHVWRFROOHFWSHRSOH VHQVHGGDWDYLDVRFLDOQHWZRUNVHUYLFHVRYHUWKHDUHDVZKHUHSK\VLFDO VHQVRUVDUHXQDYDLODEOH 6LPXOWDQHRXVO\VHQVRUGDWDLVFDSDEOHRIRIIHULQJSUHFLVHFRQWH[W LQIRUPDWLRQOHDGLQJWRHIIHFWLYHDQDO\VLVRIVRFLDOGDWD 2EYLRXVO\WKHSRWHQWLDORIEOHQGLQJVRFLDODQGVHQVRUGDWDLVKLJK QHYHUWKHOHVVWKH\DUHW\SLFDOO\SURFHVVHGVHSDUDWHO\DQGWKHSRWHQWLDO KDVQRWEHHQLQYHVWLJDWHGVXIILFLHQWO\ 113  1DGH]KGD .XQLFLQD SURIHVVRU'UVFLQJOHDGLQJUHVHDUFKHU )DFXOW\RI3RZHUDQG(OHFWULFDO(QJLQHHULQJ ,QVWLWXWHRI,QGXVWULDO(OHFWURQLFV DQG(OHFWULFDO(QJLQHHULQJ .DONX 6WU RIILFH  5LJD /DWYLD &RQWDFWV QDGH]GDNXQLFLQD#UWXOY $QDWROLMV=DEDVWD 'UVFLQJ0%$OHDGLQJUHVHDUFKHU )DFXOW\RI3RZHUDQG(OHFWULFDO(QJLQHHULQJ ,QVWLWXWHRI,QGXVWULDO(OHFWURQLFVDQG(OHFWULFDO (QJLQHHULQJ $]HQHV6WURIILFH 5LJD/DWYLD &RQWDFWV DQDWROLMV]DEDVWD#UWXOY  7KHDSSOLFDWLRQGRPDLQLQFOXGHVRYHUYLHZRISUDFWLFDO LPSOHPHQWDWLRQRI&36LHVPDUWJULGDXWRQRPRXVDXWRPRELOH V\VWHPVDQGSURFHVVFRQWUROV\VWHPV 7KHDSSOLFDWLRQVHFWLRQJLYHVDQLQSXWLQ030&36&267DFWLRQ :*REMHFWLYHVLQSDUWLFXODU ± &ROOHFWWKHUHTXHVWVDQGUHTXLUHPHQWVRIHDFKDSSOLFDWLRQGRPDLQDQG UHZULWHWKHPIURPD&36SHUVSHFWLYHORRNIRU FRPPRQDOLWLHVGLIIHUHQFHV ± $VVHVVWKHVXLWDELOLW\RIGLIIHUHQWDSSOLFDWLRQGRPDLQPRGHOVIURPD&36 SHUVSHFWLYHHJFRPSOHWHQHVVXVDELOLW\LQWHURSHUDELOLW\ZLWKH[LVWLQJ WRROVHWF ± &RPSLOHUHFRPPHQGDWLRQVRQWKHSURSHUXVHRIGLIIHUHQWPRGHOVDQG PHWKRGRORJLHVDQGWKHUHOLDEOHDVVLPLODWLRQRIFXUUHQWDSSOLFDWLRQ GRPDLQPRGHOVLQWKHSHUVSHFWLYHRI&36PRGHOLQJ 7KHH[SHULPHQWDOEDVHRIGLIIHUHQWLQIUDVWUXFWXUHV\VWHPVSURFHVV FRQWUROV\VWHPVDUHOHDGHGWRFUHDWLRQRIQHZ6\VWHPRI6\VWHP EDVHGFRQWUROWRROIRUFLW\LQIUDVWUXFWXUHVHUYLFHV $SSOLFDWLRQV GRPDLQV 114  7KH ,R7 VXSSRUWLQJ QHZ JHQHUDWLRQ RI FRQWURO FRQFHSW LV GHYHORSHG IRU VPDUW FLW\ SDUDGLJP 7KH RIIHUHG XQLILHG ZLUHOHVV GDWD WUDQVPLWWLQJ FRQFHSW LV GHSOR\HG DV FLW\ LQIUDVWUXFWXUH DQG WUDQVSRUW FRQWURO DSSURDFK 7KH GHYHORSHG VROXWLRQ LV FRPSDWLEOH ZLWK ,R7 RQOLQH WUDIILF PDQDJHPHQW V\VWHP DQG QH[W JHQHUDWLRQ RI VPDUW FLW\ FRQWURO V\VWHP :H KDYHSURSRVHGDPDSSLQJRIWKH,(& VWDQGDUG IXQFWLRQDOLWLHVWRD5(67IXODSSURDFK 'XHWRWKHSDWKVUHVHPEOHDIXOO\TXDOLILHGILOHQDPHQRWDWLRQWKH\ FDQEHPDSSHGWRD85/ZKLFKPDNHVWKHGDWDPRGHOVXLWDEOHIRU 5(67WKHUHIRUHD5(6785/FRXOGEHZULWWHQDV KWWSKRVWQDPHGHYLFHQRGHFODVVDWWULEXWH $EVWUDFW  115