1 Motivation and Challenges

Realization of Industrie 4.0 concepts drive manufacturing companies to the implementation of central, real-time use of data [1]. For this reason, they need to use information from different information systems (IS) and an increasing number of devices necessary for handling and processing the huge amount of data [2]. The real-time use of data is a key enabler for companies to join collaborative networks [3, 4]. However, establishing a central data pool is associated with extensive effort within the company [3]. This is, because data is often not available in sufficient quality or even not accessible neither inside nor outside the company. Previous approaches like centralized ERP or PLM systems did not adequately meet all existing requirements in practice. In addition, they struggle to meet new requirements introduced through machine learning and cognitive system approaches. Therefore, new approaches have been developed to facilitate an integration layer for the companies’ information sources. Concepts such as SOA or MISE [4] require a total rebuild of a companies’ IS architecture [5]: the integration is a challenge due to heterogeneous data, differing system models and unclear responsibilities inside the companies [6]. For that reason, especially small or medium sized manufacturing companies dread to implement such concepts. In particular, companies are missing an approach on how to measure the effort for implementation and how to deduce decisions to take.

Recent publications suggest a platform based approach as a future IS architecture for manufacturing companies [5, 7, 8]. In such an architecture, existing IS remain mostly untouched and a new platform-layer is implemented on top of them. A model explicitly addressing manufacturing companies is the Internet of Production (IoP) [8]. Those models are well described concerning the future IS architecture layout, but they are missing concrete descriptions on how companies should implement them: what decisions they should take, and what functionality they should implement in which layer. To increase their practical value, the process of IS function integration decisions will be explained in this paper, addressing the research question: How can architecture decisions regarding the integration of IS functionalities into the IoP be structured, systematically made and necessary changes planned accordingly?

2 Fundamentals

2.1 Internet of Production Reference Architecture

The approach of the IoP enables companies to quickly initiate data-based decisions and change processes, thus enabling the company to be part of a collaborative network. The reference architecture describes the aggregated product life cycle from development to the use of a product (Fig. 1). The horizontal layers represent the collected data, the assisting systems and the applications that support the developer, the manufacturer and the customer in each period. The central Middleware+ layer receives heterogeneous raw data from different sources or distributed systems and creates Smart Data based on various algorithms. This data with a high content of information provides the basis for the digital shadow, which describes a digital real time reflection of the reality. Users can have access to the data models via apps and software-based agents can use the smart data for automatic decision-making. By sending back the data to the middleware and application software, it is possible to achieve continuous synchronization, which ensures consistency and avoids conflicting data sets. The IoP is described in more detail in [8, 9], the single layers are described in more detail in Sect. 3.

Fig. 1.
figure 1

Internet of production reference architecture [8]

Full size image

2.2 IS Integration

An IS is an aggregation of socio-technical subsystems with the purpose of supporting management and operational decision making as well as providing means of information and communication [10, 11]. Methods of IS integration management can be utilized to achieve the goal of a consistent IS architecture [12]. Therefore four integration objects can be classified: IT strategy, IT organization, IT landscape and stakeholders [12, 13]. For the basic paths it can be distinguished between horizontal (across different divisions, but on one architecture level) and vertical integration (within one division, but over different architecture levels) [14].

Nowadays most IS architectures involve three different layers: data layer, processing layer and presentation layer [15]. Common integration technologies are the use of middleware and the Enterprise Application Integration (EAI) concept. Middleware offers standard interfaces for data exchange, but lacks in flexibility in a business process oriented integration. EAI offers a separation from business process logic and interface programming in a way that development and maintenance efforts are low [13].

Main drivers of effort for IS integration can be subdivided in: Complexity of the IS project [12], legal guidelines [13], quality guidelines on the basis of certain attributes such as functionality, reliability, usability, efficiency, maintainability and portability of an IS integration and erroneous planning and conception of an IS integration. These categories may overlap partly, for e.g. the portability affects the complexity as well as the quality guidelines of an IS project. Effort can be displayed in seven requirements, which are speed of integration, minimization of integration expenses, minimization of integration risks, potential for synergies, technology innovation, protection of investment, and minimization of archiving effort [13].

2.3 IS Architecture Decisions Today

Transformation towards vertical and horizontal integration, in order to realize a consistent data processing is a key topic in the context of Industrie 4.0 [16] and the collaboration within manufacturing networks [3]. The respective IS architecture decisions nowadays are influenced by the concepts of service-oriented architectures (SOA) and micro services. Even though a modular design of the architecture leads, due to uncoupling and reuse, to less IT complexity, a complete implementation of SOA in manufacturing companies is not feasible [9]. As described, the IoP represents a clear target architecture for manufacturing companies to fulfill the corresponding requirements. This paper will outline the path of transforming towards an IoP architecture and provide a method to systematically conduct related decision.

3 Mapping of IS Functionalities Within the IoP Layers

The high structural complexity of collaborative networks and the related IS architecture can be managed by pre-structuring reference models [17]. Still, on the company level the transformation towards and adaptation of this pre-structuring model, the IoP, must be managed with low effort and high velocity. A function-based approach taking into account a defined set of effort drivers will enable companies to do so.

For the integration of IS functionalities, the functional blocks need to be separated from the process or use case [18] and based on the users’ requirements further detailed into functional modules, so these modules can be located to the current IS architecture layers [2, 19]. To derive a detailed description of the IoP layer for this purpose, existing IS architecture layer models have been analyzed (see Fig. 2). The aspects of the different models with different focus have been combined with the specific aspects of the IoP to enable the goal of a quickly initiating change processes. The result is the following description of the IoP layer:

Fig. 2.
figure 2

(based on [20,21,22,23,24,25])

Analysis of existing IS layer models

Full size image

  • Raw data contains data storage functionalities including the databases of the core IS, collection of sensor data, machine data and asset data.

  • Application Software contains the functionalities regarding data generation and transformation within core IS, connectivity of physical assets to core IS and functionalities regarding data based control of assets.

  • Middleware+ contains all functionalities regarding the communication and routing of data between the different layer and core IS, including the scheduling of communication, modeling of communication channels, data defect detection (regarding data format), transformation of data in further processable format and asset management of data sources.

  • Analytics contains all logical functions processing data of at least two separate data sources or two separate core IS. This includes a logical data defect detection, historical analysis, formation of performance indicators, prognosis and simulations.

  • Digital Shadow combines analyzed data to case-specific sets of information containing all relevant information. Thus, the layer contains the respective data models, storage of the aggregated information and access management of agents to the information.

  • Agents autonomously combine information. This layer contains business decision rules and connects information objects of different layer.

  • Decision Support represents the user interface to the decision maker. It contains the data entry point for information searches, the mapping of information to business processes and all visualization functionalities.

Additionally to the layer descriptions, general decision rules are necessary:

  • Adaptation of core IS shall be minimized to only configurations. Extensive specific adjustments or fast and close to the customer developments are implemented in different IoP layers. Exceptions are changes requiring secure and safe development (e.g. regulatory changes).

  • Data processing and storage that can be performed within the same core IS should remain within this IS.

  • Sensors preprocessing the data shall be directly connected to the middleware+ layer. Basic sensors should remain connected to a core IS or raw database.

4 Assessment of Integration Measures

In this research, integration refers to adapting a part of the IS architecture to enable new functions (see Sect. 3). This can be done through programming of new functionality, development of interfaces between IS, or introduction of new software. Doing so, integration costs are incurred at four integration dimensions. In these dimensions, integration costs can arise both as a one-off expense and as running costs, such as license costs. However, this article focuses on the one-off costs.

In the technical dimension, development costs depend on the properties of the existing IS. Interfaces must be adapted to link data sources, and effort depends on the degree of standardization of the IS to be connected. Proprietary interfaces require more effort than standardized interfaces such as OPC-UA. If the interface has to be capable of real-time operation, technical outlay for fail-safe operation is created by means of redundant systems. In programming, the effort depends on the basis on which new functions are implemented. If the development environment of the digital platform is used, which enables e.g. visual scripting, development is less complex than when implementing proprietary development without the use of frameworks. In the simplest case, functionality can be implemented by just configuring an IS.

From an organizational point of view, effort can range from a simple task assignment to an employee, to a reorganization, depending on the scope of the change. An effort driver is the required adjustment speed. If fast adaptations are often required, an IT of two speeds should be introduced. Process adaptations are often directly linked to the integration of new functions, which in turn generate effort through training and learning in the reorganization of departments. Also the necessary reorganization of the data responsibility due to the connection of several data sources has to be considered.

The process perspective on integration refers primarily to the adaptation of business processes due to new functionality in the IS. As described above, integration costs arise through organizational adjustments, but also by preparing and planning the adapted process and configuring the IS. It must be defined which functionality is used in which sequence and this must also be agreed with the people responsible. To set the process alive, users have to be trained to work with new functionalities or new tools introduced.

An effort not to be underestimated is caused by data integration. Depending on the use case, adjustments of the data structure, data quality or data standardization may be necessary: If the data structure has to be adapted, data models may have to be adapted in several IS. Data quality can be changed by technical and organizational measures, for example by installing new sensors or by appointing employees to maintain the data. In order to implement data standardization, data must be harmonized or even translated so that it can be used across systems.

The concrete integration efforts cannot be evaluated generally, but the effort depends on the concrete use cases to be implemented. All of the above dimensions must be taken into account in the evaluation, as well as all development phases from requirements analysis and design to implementation, testing, commissioning and the necessary change management.

5 New Approach on Architecture Decisions

The core objective is to integrate functionalities into a central platform, still using standardized core IS and no longer to implement everything in individual systems or focus on in-house developments. The whole decision process applies to adding new functionalities into the IoP but also transforming the current IS architecture to an IoP-like architecture. The following seven steps describe the application of the approach:

  1. 1.

    Create a detailed description of the use case/process to be implemented

  2. 2.

    Gather internal objectives that the integration needs to match based on company and IT strategy

  3. 3.

    Detail the use case into functional blocks and further into functional modules

  4. 4.

    Compare needed functionalities with existing functionalities

  5. 5.

    Derive possible technical integration scenarios regarding all additional functionalities and interfaces within the IoP (based on Sect. 3)

  6. 6.

    Quantify the integration efforts for each relevant scenario (based on Sect. 4)

  7. 7.

    Decide on integration scenario.

6 Case Study: Weight Prediction for Product Development

An electric car company develops a small and light electric city car. The company has only been founded three years ago. As a start-up, it facilitates agile development methods unlike in traditional OEMs with conventional development processes. Still, decision makers in the company need to have real-time transparency on the development status - in case of the examined company: especially on the car’s weight. Therefore, the company needs to summarize and visualize the data from the IS within the development cycle of the IoP, including data from suppliers throughout the collaborative supply chain. One specific goal is to forecast the weight change during development phase. The development of an app to enable the desired transparency is only on part of the companies’ IT strategy to implement the IoP infrastructure.

The necessary functionality for this case ranges from data modelling to aggregate the needed data, evaluation and prognosis of the weight status, to visualization of the CAD data. Parts of the required functionality exist, e.g. visualization in the PDM system. However, there is no cross-system evaluation. Therefore, the company had several integration scenarios: (1) Development of a specific adaptation of the PDM system, (2) integration of the function into the existing IoT platform, and (3) implementation of an in-house development. Since scenario 3 requires significantly more effort in development, because it is not based on any existing technology, two options remain. The company evaluated the development costs for programming the PDM in comparison to the cost to implement interfaces to the IoT platform and build an app on its basis. Therefore, they detailed their requirements and compared it to the existing functionality: e.g. the PDM system is capable of storing the data in the correct structure, in the IoT platform, apps can be built on basis of existing templates. Taking in account the strategy of the company to build more such apps in future, the one-off cost of implementing an interface between IoT platform and PDM can be rated lower. Hence, the company has opted for scenario 2.

7 Summary

After summarizing the state of the art concerning IS integration and IS architecture decisions, this paper introduces a method on how to map IS functionalities into the IoP. It gives an overview of integration measures to be taken into consideration, and introduces an approach on how to decide on IS architecture changes. Still there is further work to be done: Especially the monetary calculation of implementation costs has not been covered in this paper, but will be part of future research. The work has so far focused on the manufacturing industry, though other industry sectors such as logistics and service providers suffer similar challenges. Thus, the concepts in this paper should be transferred to other industries.