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 anMDSDapproach for a structured, automated, and reusable integration ofTSs. The central idea of the approach is aTSindependent 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 ofMDSDin theTSintegration 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 ofTSs;

– conceptualization of an extendible reuse framework specifically tailored to an In- dustry 4.0 integration domain; and

– specification of a methodological approach for the application of the developed integration framework.

• Development contribution in the form of aTSintegration tool that will implement theMDSD integration approach comprising an integration language and a reuse framework. • Application contribution that comprises application of the integration approach on several

use cases and dissemination of analysis results and lessons learned.

The main expected result of this research is easier and simpler integration ofTSswith the aim to improve the response time to production process changes and solve both inter-space and

1.5 thesis structure 11

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 technical space notion 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- levelTS. This will be evaluated on the practical use cases that are presented inChapter 6.

1.5 t h e s i s s t r u c t u r e

Apart from Introduction and Conclusion, the thesis is organized in six chapters.

InChapter 2 we introduce the main terminology and the background behind the research presented in this thesis. The main notions of integration and Model-Driven Software Develop- ment are introduced and explained in detail. In this chapter we also relate main elements of this research to the introduced notions.

In Chapter 3 we present the related work in the fields of schema-based integration and matching, model-driven integration, and ontology alignment which are closely related to the topic of this thesis.

Existing data integration and Extraction, Cleaning, Transforming, Loading (ECTL) tools are presented inChapter 4as they provide us with the insight into current state of the art of the contemporary integration tools. We present the process of choosing tools for the survey, cate- gorizing them, and in the end a set of evaluated characteristics. Each of the tools is evaluated in detail and the results are presented. The overall findings of the survey are given and a generic profile of an integration tool is presented which serves as the role model for the tool we implemented for our approach. Identified best practices and our personal experience in using the tools are also disseminated in this chapter.

InChapter 5we introduce our approach to integration adapter specification. First, we iden- tify the place for our approach in the general integration process. Next, we introduce the integration process supported by the approach. In the same chapter we present the support- ing tool, named AnyMap, and its main modules. Special attention is given to the mapping and expression languages.

Our approach is applied in several use cases of which the two most representative ones are presented inChapter 6. The first example encompasses application of our approach in an industrial context in which sensors are integrated with information systems. In this example we will provide a complete description of the integration process with the some details re- garding the AnyMap tool usage. As the reuse of mappings is often a necessity in industrial integration scenarios, we will showcase the reuse on an example where the intra-space het- erogeneity is introduced by changing a sensor configuration. Second use case concerns model interchange between MetaEdit+ and Visio meta-modeling environments. We will show that our approach can be used in domains where high-level mappings are required and not the low-level serialization-related mappings like it in the first use case. In this chapter, we also analyze our approach and discuss the results in the light of specified hypotheses. Each of the hypotheses is discussed and its confirmation or rejection is presented in detail.

2

In this chapter we present theoretical foundations of our research on model-driven TS in- tegration based on a mapping approach. The approach can be roughly categorized as an model-driven approach to system integration. Therefore, in the following sections we intro- duce the main concepts and notions from the respective domains of system integration and model-driven development. This will establish the theoretical foundation of our work as well as allow easier understanding of the following chapters.

2.1 s y s t e m i n t e g r at i o n

Both in business and industrial domains, integration is one of the main enablers of purposeful and continuous operation. Stand-alone software systems or isolated machines cannot fulfill the requirements of the modern business and industrial processes and the interaction between them is an essential element of the entire system operations. The growing market needs and the advancement of technology require for the new technologies to be constantly applied and the processes to be adapted and changed. This leads to heterogeneous systems in which both new and old software systems and machines need to coexists and communicate. This is most obvious in the industrial environment. Factories are often equipped with expensive machines and companies that bought them want to use them as long as possible in order to justify the investment. It is not rare that these machines are operational for several decades. Introduction of new software and machines in the production process is often required in order to enrich or adapt the process to the current market needs. Therefore, new machines and software need to be integrated both with existing systems and with each other in order to fulfill the information availability and the quality of the production process. To make things even more difficult, in companies there is often a significant investment already in place for a variety of system integration technologies [97]. Therefore, system integrators are not only

presented with an integration problem but are also limited in the tools they are able to use. All of this makes the integration a difficult but an essential element of the system life-cycle which is often considered as one of most important strategic priorities.

The reality today is that the integration process has both technological and organizational impacts on a company. This may lead to different companies having totally different views on integration tailored to fit their preferences and use cases. Consequently, this means that there is no single definition of the system integration notion that will satisfy all possible viewpoints appropriate for all use cases and companies. We found several definitions of the notion but we chose to present the following two that represent the notion of system integration from different perspectives. From a technological perspective, system integration is “the melding of divergent and often incompatible technologies, applications, data, and communications into a uni- form information technology architecture and functional working structure” [149]. In addition to just

technology, the integration of systems involves a complete set of business processes, manage- rial practices, organizational interactions, structural alignments, and knowledge management. Therefore, from a non-technological standpoint, system integration “represents a progressive and iterative cycle of melding technologies, human performance, knowledge, and operational processes together”. In this thesis, we rely on the first definition as we are more focused on the techno- logical aspect of the integration. Moreover, as system integration encompasses both hardware

and software integration, we must note that in this thesis we deal only with the latter one. Even in the case of machines, e. g., sensors and actuators, we look at them as CPSs and only consider their cyber part. Therefore, in the rest of the thesis, unless otherwise stated, we will use the notions of integration and system integration to denote software-level integration.

The effects that system integration may have on organizations are multifold. Integrated systems improve the competitive advantage with a unified and efficient access to the informa- tion [97]. It is much easier to get relevant, coordinated information from a variety of sources.

In effect, the total becomes more than the sum of its parts. Furthermore, the integrated sys- tem facilitates better collaboration of workers regardless of their geographical location, time zone, and location of information. Integration allows information and knowledge to be si- multaneously shared by workers, business partners, and even collaborative competitors [149].

The need to integrate is also driven by new forms of business and partnerships. Groups of companies and workers not only share data and information, but also have exposure to their respective business partners’ operations [149]. In a factory which system is integrated both

internally and externally with the partner systems, partners may have an insight into the pro- duction status of a product of interest. Customers may also be able to see the state of their product while it is being manufactured, packaged, shipped, and delivered. From this, we may see why the integration is considered as one of the main driving factors of the latest industrial revolution.

According to [97,149], there are four kinds of system integration:

• Interconnectivity. Interconnectivity involves making different parts of the system work together. This includes the facilitation of simple data exchange and establishing com- munication between the connected parts of the system. The existing functionality of a system remains the same as this kind of integration only provides data-level integration but not integration at the functional level. This is the most basic kind of integration and all other kinds are built on top of it.

• Interoperability. Interoperability refers to the functional integration of different software systems or machines that allows exploitation of capabilities of all integrated system parts. This is the kind of integration most commonly found in companies. This kind of integration comprises application-level integration. The application-level integration focuses on sharing functionality and business logic instead of pure data sharing like it is the case in data-level integration. It is usually achieved through the use of Application Programming Interfaces (APIs).

• Semantic integration. Semantic consistency emphasizes rationalization of data elements and their meaning. In order to achieve semantic consistency, data from different parts of the integrated system must be handled and understood in a uniform manner across the system. One way of providing accessibility to data and minimizing the potential of errors in human interpretations is through the creation of standard data definitions and formats. In this kind of integration, the presentation-level integration is performed. The presentation-level integration results in an integrated system that provides a unified presentation layer, through which the users can access the functionality of the integrated system. A semantic uniformity is necessary in order to present data from disparate parts of the system in a same way.

• Convergent integration. Convergent integration involves the integration of technology with business processes, knowledge, and human performance. This requires the pres- ence of all three previously introduced integration kinds, but involves factors other than

2.1 system integration 15

technological ones. It is the highest and most sophisticated kind of integration. The busi- ness process integration is present at this level. The business process integration enables non-compromise support for business processes in the enterprise where existing solu- tions take part in distinctive steps of the process.

Our approach, presented inChapter 4, aims to provide integration at the data level as this is the most important issue in theIIoTdomain in which the definition of interconnectivity and interoperability are slightly adapted. Basically, by connecting the devices at the hardware level we are providing interconnectivity within the system. In order to provide interoperability, we must provide an adapter which translates messages sent between connected devices. This way, connected devices are able to operate together and thus provide a meaningful output for the system as a whole. Therefore, our goal is to provide the interoperability by connecting different inputs and outputs of devices being integrated and thus allowing them to provide a common functionality to the end user. Although we have created a common data structure that may facilitate semantic integration, which we have shown in the paper [55], it’s not the

primary goal of our solution. As data-level integration is the prerequisite for all other kinds of integration, our goal is to enable data-level integration in theIIoTdomain by developing an appropriate approach.

In order to apply a certain integration kind, different methods, techniques, patterns, and technologies can be used. These have been developed over the years, ranging from point-to- point integration over enterprise application integration and business process management to service oriented architectures [97]. All of the methods can be roughly classified in the

following four distinct categories [80,97,149]:

• Vertical integration. Vertical integration methods allow integration of system parts based on their functionality and thus creating same-function entities of integrated system parts. As the integration is preformed rather quickly and involves only necessary system parts, these are the cheapest integration methods in the short run. However, since same- function entities are not reusable and adding a new functionality requires creation and integration of a new integration entity, these methods can lead to great expenses over time.

• Star integration. Star integration methods encompass connecting each system part of the system with each of the remaining parts. The cost of using this method can vary based on the number of interfaces that a system part is exporting. This kind of integration pro- vides the greatest degree of flexibility and the reuse of functionality. However, time and costs needed to integrate a new part of the system raises exponentially as the number of integrated parts increases.

• Horizontal integration. Horizontal integration methods use a specialized component for the exchange of messages between the disparate parts of the system. These methods, often comprising the usage of an Enterprise Service Bus (ESB), allow for each system part to be connected to the communication component only once. A communication component, or a bus as it is called, can translate sent messages and deliver them to the appropriate receiver in the system. These are the most flexible methods of integration. With systems integrated using a horizontal integration method, it is possible to com- pletely replace one system part with another one that provides similar functionality but exports different interfaces. Such a substitution is completely transparent for the rest of the integrated system parts. However, the cost of using these methods can be significant as the cost of specifying data transformations and appropriate business logic that drives the integration cannot be avoided.

• Integration based on a common data format. These integration methods are based on an application-independent (or common) data format to which all other data formats are mapped. These methods usually comprise two steps. In the first step, an adapter is used or created to transform original messages to messages that conform to the common data format. Afterward, in the second step, semantic transformations are executed between two common representations of data from different system parts in order to achieve the desired level of integration between them.

Our approach can be classified as an integration approach that uses a common data format to achieve integration between different system parts. We have created a common data struc- ture onto which all other data formats are mapped based on main principles of the Model- Driven Software Development (MDSD). Each technical space, i. e., system part, that is being integrated, is represented in a form of a generic data model. In compliance to theMDSDprin- ciples, each model is considered as a first class entity and all operations are executed on these models. Models are directly used in the process of development of integration adapters at a higher level of abstraction than it is the case when writing adapters manually at the data level. Once the models are created, transformations are written using a graphical Domain-Specific Language (DSL).

All of the aforementioned notions related to the MDSD domain are introduced in the next section.

2.2 m o d e l-driven software engineering

Development of software, regardless of the domain, is a complex task. Increasing number of domains in which the software has been applied increases this complexity as users’ require- ments and needs become more and more demanding and complicated. According to [34],

developers need to fight two kinds of complexity while developing software: (i) essential com- plexity, which is inherent to the problem being solved and which cannot be mitigated, and (ii) accidental complexity, which is not related to the problem but encompasses components, tools, and ideas that are not important or do not need to be used in order to solve the problem. Although the first kind of complexity cannot be mitigated and therefore is a constant factor that directly influences software complexity, the second kind is usually caused by developers and the inappropriate tools or methodologies that are chosen. By using general purpose pro- gramming languages and thinking in terms of programming constructs instead of constructs specific to the problem domain, developers tend to over-think or to over-complicate solutions. By providing a language with domain-specific concepts to developers and domain experts, it is possible to reduce the accidental complexity and therefore increase the quality of software solutions. The Model-Driven Software Engineering (MDSE) methodology and particularly Domain-Specific Languages (DSLs) are considered to be a viable way of reducing the acci- dental complexity by introducing the domain specific elements to the software development process [188].

According to [32],_MDSEis defined as a “methodology for applying the advantages of modeling to

software engineering activities.” This methodology is based on explicit specification of models which are considered as first class artifacts of all software engineering activities. Thus, any software-related artifact is considered to be a model or a component of a larger model.

In this thesis we are concerned with the development activity of the software engineering process. In the context ofMDSE, this activity is centered around developing software systems