Keywords

1 Introduction

Engineering industrial, recently also cyber-physical, production systems, e.g., long-running and safety-critical systems for assembling automotive parts or for producing metal, is the business of multi-disciplinary production system engineering (PSE) companies [3, 18]. In parallel engineering, the disciplines develop their engineering artifacts, such as plans, models, software code, or machine configurations, independently, but have to consider dependencies between the engineering disciplines in order to build a common system. A key success factor is the capability to exchange selected data in the engineering artifacts with related domain experts efficiently and in a timely manner to reduce rework due to inconsistencies.

We illustrate the engineering data exchange (EDEx) process with a use case from simulation in PSE, as simulation is a major consumer of engineering data for assessing the safety and business risks of a production system before system construction. Goal of the simulation engineer is to design simulation systems that allow exploring dynamic properties of the designed production system, such as throughput or the physical feasibility of production steps. Therefore, the simulation engineer requires input data from several engineering data providers on key parameters of system parts, such as the rotation speed, torque, control signals, or power consumption of a motor, as foundation for calculating and analyzing the movement of work pieces and robots over time.

In the traditional EDEx process [1, 5], domain experts communicate their engineering artifacts from point to point, typically in the form of spreadsheet tables, pdf or XML files. Unfortunately, in the traditional EDEx process, Lüder et al. [12] identified the following major challenges.

Ch1. Unclear Data Requirements of and Benefits for Stakeholders. For potential data providers, it is often not clearly defined which project participants require what kind of data at what point in time in the project. Even if general dependencies between stakeholders are known, the specific relations between engineering artifacts and their content within an engineering project can change during the project execution.

Ch2. Heterogeneous Engineering Data is Hard to Integrate for Sharing. Due to strongly practical and historical reasons, engineering tools are typically specific to one discipline and not designed for use with other disciplines. While the disciplines share some common concepts, such as the concept of a device or a signal, these concepts are not consistently modeled, making data integration for sharing error prone and hard to automate. Consequently, sharing engineering artifacts takes high effort for consuming domain experts and, thus, hinders comprehensive automated processing.

In this paper, we introduce a process for efficient data logistics to exchange engineering data in order to address these challenges and to automate data logistics for improving the value and for reducing the risks of EDEx. We investigate the following research questions (RQs) based on Design Science research methodology [19].

RQ1. What are main elements of an effective and efficient engineering data exchange (EDEx) process in Multi-Disciplinary Engineering? To address this research question, Sect. 2 summarizes related work on approaches for data exchange in multi-disciplinary production systems engineering (PSE). Section 3.1 discusses EDEx process requirements collected in workshops at a large PSE company. Section 3.2 proposes steps for an EDEx process that addresses these requirements. For designing the EDEx process, we adapt the Multi-Model Dashboard approach [5] from constraint evaluation to EDEx and replace the design requirement of an initial common concept model, which may not be available, with direct links between consumer and provider data elements.

RQ2. What are main information system mechanisms that enable engineering data exchange for Multi-Disciplinary Engineering? To address this research question, Sect. 3.3 derives requirements for effective and efficient EDEx information system (EDExIS) mechanisms. Section 4 reports on an evaluation of the effectiveness and effort of the proposed EDEx process with EDExIS mechanisms in a feasibility case study with requirements and data from real-world use cases with domain experts at a large PSE company. Section 5 discusses the findings and limitations. Section 6 concludes and proposes future research work. From the research, we expect the following contributions for the information systems engineering (ISE) community. The use cases and EDEx process give ISE researchers insight into the PSE domain, the foundation for Industry 4.0 applications. The EDEx process contributes capabilities for designing and investigating agile processes and information systems in PSE, a foundation for conducting engineering projects for cyber-physical production systems economically.

2 Related Work

This section summarizes related work on data exchange in production systems engineering, information system (IS) engineering, and software engineering.

2.1 Data Logistics in Production Systems Engineering

Due to the inherent dependencies between the local models in the Production Systems Engineering (PSE) process, e.g., the impact of electro-magnetic fields from electrical wiring on communication quality, domain knowledge is required both on the customer and the provider data models to interpret the data content [3]. Therefore, it is necessary to move from delivering engineering artifacts to engineering data exchange (EDEx).

Furthermore, the migration towards cyber-physical systems is a complex task due to challenges, such as heterogeneous tools and data formats as well as diverging views on artifacts and their versioning. Therefore, an extensive solution, covering technical, operational, and human dimensions, is required [7]. Optimizing the available engineering data is a possible quick impact that can be achieved by integrating EDEx [17] based on the machine understandable representation of knowledge.

Lüder et al. [12] introduced an architecture for engineering data logistics, based on AutomationML (IEC 62714) [18], an open, XML-based format for the exchange of engineering data. The proposed architecture allows exchanging data between discipline-specific data models with varying hierarchical key systems. While this approach is useful in an AutomationML environment, it does not consider how to negotiate the EDEx between many data consumers and providers.

The Multi-Model Dashboard (MMD) [5] process guides the systematic definition, monitoring, and evaluation of PSE parameters and constraints. While we can build on the MMD strengths as foundation for the EDEx research in this paper, the MMD approach also requires significant adaptation for our context, since it does not consider the provision of data to consumers, and because well-defined common concepts in PSE are hard to implement in practice if several disciplines cooperate with each other, with no discipline clearly leading.

2.2 Data Exchange Contributions from Information Systems and Software Engineering

Methods from business process management provide useful approaches, such as UML class diagrams [6] or BPMN [13], for EDEx definition by characterizing the involved stakeholders, systems and, to some extent, data types and their relationships. However, these methods are generic and need to be adapted for new contexts, also in the case of heterogeneous engineering data integration [15]. In specialized domains, e.g., medicine or engineering, approaches need to be adapted to optimize data exchange according to domain-specific requirements [10, 14].

Semantic Web technologies are recognized for facilitating data exchange across applications and organizations in the web and have proposed engineering data integration approaches following the interchange standardization approach [17]. However, the manifold types of dependencies in PSE data models are different from typical Semantic Web requirements [11] and the Semantic Web technology stack is, therefore, currently seldom used in engineering environments.

Software engineering design patterns [9] encapsulate best practices of software system design for commonly occurring problems, in our case data and tool integration. In the context of this work, we build on design patterns, such as message passing and publish-subscribe, to support the loose coupling of engineering work groups and tools.

3 Design of the Engineering Data Exchange Process and Information System

This section introduces requirements, use cases, and main elements for an Engineering Data Exchange (EDEx) process and derives mechanisms of an EDExIS.

3.1 Requirements for an Engineering Data Exchange Process

Following the design science cycle in [19], we set up an initial problem investigation with workshops [2], outlining the context and problem space of research, and deriving the following requirements addressing the challenges introduced in Sect. 1. A more detailed description can be found in [4].

Cap1. Engineering Data Representation. This capability concerns the representation of candidates for and specifics of typical engineering data structures, such as tree hierarchies of the functions of a production system, lists of objects, and objects and their attributes and relationships, both for data consumers and data providers.

Cap2. Semantic Link Knowledge Representation. This capability concerns the representation of candidates for and specifics for semantic links for data integration between selected consumer and provider data elements.

Cap3. Process Data Representation. This capability concerns the representation of meta-data on the EDEx process, e.g., who provided what data when, versions of data elements, data quality and validity (e.g., valid, invalid data).

Cap4. Consumer- and Benefit-Driven EDex Planning. This capability emphasizes on planning EDEx guided by business benefits coming from data consumer use cases to ensure the prioritization of EDEx with high benefits. This is an economic improvement to the traditional process, which focuses on the cost for set up and operation. This capability implies the requirement for providing an overview on stakeholders interested in requested or provided data as foundation for a data logistics marketplace.

3.2 Use Cases for Evaluation

From workshops at a large PSE company with 28 domain experts, who come from four different domains of expertise, and 6 researchers, we identified two illustrative EDEx consumer use cases (UCs) as foundation for the EDEx process design and evaluation. The engineering of a typical industrial production system (PS), such as automotive assembly, requires at least the collaboration of, and EDEx between, the plant planner (PP), who plans the layout of the PS, the mechanical engineer (ME), the electrical engineer (EE), and the robot programmer (RP).

UC Sim. Data Exchange for Production System Simulation. In a typical advanced engineering environment, a simulation engineer (SimE) designs and runs simulation models to check the engineering results and to optimize production system parameters, such as safety risks, production throughput, and energy consumption. The design of the simulation models depends on the input of several other domain experts. The PP, ME, EE, and RP may provide configuration parameters of motors and conveyors in a transport system and requirements of production processes, such as process duration (s), and production resource parameters, such as length (m), mass (kg), or power consumption (kW). The manual synchronization of these data typically requires additional effort, tends to be error prone, and induces avoidable project risks.

UC PM. Engineering Project Monitoring. The project manager (PM) wants to use the input from data providers to the SimE to assess project progress by analyzing the completeness and quality of the data with respect to the project phase and planned deliverables. Missing or inconsistent data may make sense in an early design phase, but may pose a major risk closer to a later design milestone and may require action by the PM. Unfortunately, the PM does not understand the various input engineering artifacts.

3.3 Engineering Data Exchange Process Design

To address the required capabilities in Sect. 3.1 and the use cases in Sect. 3.2, we introduce the main elements of an engineering data exchange (EDEx) process, design according to [19]. The EDEx process extends the Multi-Model Dashboard process [5] to multi-disciplinary engineering work groups in a PSE project. The EDEx process is independent of a concrete implementation technology.

Fig. 1.
figure 1

Data Exchange process architecture with definition/negotiation and operation phases, based on [4].

Full size image

Process Architecture. Figure 1 gives an overview on the EDEx definition and operation phases. The EDEx operation phase assumes an agreement between data consumers and data providers on the data model and concepts for EDEx.

EDEx Roles are the data consumer, the data provider, and the EDEx curator. The data consumer requests data according to her local consumer data model from providers to improve her business processes. The data provider has engineering artifacts that contain relevant data for a consumer. A domain expert may be both consumer and provider. The EDEx curator has background knowledge on the PSE business and relevant data models of all domain experts to mediate between consumers and data providers. The EDEx curator has the capability to link the local data models of consumers and providers with appropriate link definitions, such as mathematical formulae.

EDEx Definition Phase. The EDEx definition phase consists of three main steps to identify feasible and beneficial candidate instances for data exchange. At the end of this phase, the EDEx roles come to agreements on which data sets they plan to exchange as foundation for the technical design and implementation in a suitable EDEx environment. Figures 2 and 3 illustrate selected cases of the EDEx processes.

D1. Consumer Data Definition and Prioritization. Consumer candidates have to define their data requests. The EDEx curator validates with the consumer the definition of requested data and estimates the likely benefit of providing the data to focus on the most relevant EDEx instances first. This step results in a set of data model elements in the local consumer data view, with a semantic description understandable both to the EDEx curator and prospective providers based on the modelling concepts and vocabulary of the EDEx curator (see Fig. 3, tag D1). Note that this step is iterative to allow consumers adding data elements.

D2. Provider Data Definition and Cost Estimation. A provider can react to consumer data requests by agreeing to publish data that is semantically equivalent to the requested consumer data. Outcome of this activity is a set of data model elements in the local provider data view, with a semantic description understandable both to the EDEx curator and prospective providers based on the modelling concepts and vocabulary of the provider (see Fig. 3 for examples). The EDEx curator has to elicit the likely cost for data extraction and transformation into a format that is suitable for EDEx, such as AutomationML. The goal of this step is to give feedback to the provider whether the data is of sufficient quality and reasonable cost to continue setting up the EDEx (see Fig. 3, tag D2).

D3. Consumer-Provider Mediation and Semantic Link Definition. For each promising consumer data request, the EDEx curator tries to find a set of providers that would allow providing the requested data. In typical cases, the data elements may come from several providers in a variety of data formats (see Fig. 2). For each pair of requested and provided data items, the EDEx curator establishes a formal semantic link, i.e., a formula that specifies how to calculate the consumer data value from published provider data instances. More advanced semantic relationships [11] include string operations, mathematical calculations, and parameterized function calls to semantic transformation algorithms (see Fig. 4). Outcome of this step is a set of consumer data, semantically linked to a set of provider data as foundation for designing the EDEx operation, supported by an EDExIS.

Fig. 2.
figure 2

Engineering data exchange definition/negotiation and operation for a customer data set, based on [4, 5] (tags in green circles refer to EDEx process steps in Fig. 1). (Color figure online)

Full size image

EDEx Operation Phase. The EDEx definition phase provides the foundation for conducting the exchange of data instances (see Figs. 2 and 3).

O1. Data Provision and Validation. The provider extracts the data elements as agreed in the EDEx definition phase from their local engineering artifacts. Then the provider transforms the extracted data into a data model and format that the team workspace can import (see Fig. 2, tag O1). The provider and the EDEx curator agree on a procedure to validate the data from extraction to input to team workspace to ensure that only correctly transformed data is imported. The EDEx curator imports valid data into the team workspace.

O2. Semantic Data Transformation and Validation. A transformation mechanism in the team workspace propagates the imported data along the semantic links to fill in or update consumer data sets (see Fig. 2, tag O2). The EDEx curator checks the correctness of the transformation of imported provider to consumer data.

O3. Data selection and Delivery. The consumer selects data instances by providing the team workspace with the type of and information to select the requested data instances, such as data identifiers or selection conditions, similar to a SQL query to a database. The team workspace delivers the result data to the consumer (see Fig. 2, tag O3).

Fig. 3.
figure 3

EDEx definition/negotiation and operation overview table, based on MMD in [4, 5] (tags in green circles refer to EDEx process steps in Fig. 1). (Color figure online)

Full size image

3.4 Illustrating Use Cases

Figure 2 illustrates an overview on the roles, engineering artifacts, and exchanged data for the EDEx definition/negotiation and operation processes (see Fig. 1) for one consumer data set, in this case device parameters collected for the SimE. The data providers and data consumers, such as the PP, ME, EE, and SimE, operate in private workspaces. The team workspace contains shared data views as foundation for preparing and operating the EDEx processes.

Parameter Exchange for Production System Simulation. In this use case, the SimE requires a set of parameters to configure the simulation for a device (see Fig. 2, lower right-hand part, red bar), such as a robot or conveyer. The SimE requests the set of parameters from providers, such as the PP, ME, EE, and RP, who may agree and publish their local engineering data corresponding to a consumer request (see Fig. 2, left-hand part). Then the EDEx curator links the set of parameters requested by the SimE with the set of parameters published by the PP, ME, EE, and RP (see Fig. 2, middle part) to enable the EDEx operation.

During the EDEx operation phase, the team workspace receives updates of provider data instances in engineering artifacts from the private workspaces of the PP, ME, EE, and RP (see Fig. 2, left-hand side for the ME and EE) and transforms this input data according to the semantic links into output data for delivery to the SimE (see Fig. 2, right-hand side, and example output data in Fig. 2, right-hand upper part). The SimE can be notified as soon as relevant data for a requested data set is available or changed.

Production System Engineering Project Monitoring. The PM can benefit from the EDEx for simple and advanced analyses. A simple analysis could be to subscribe to the same data sets as the SimE and analyze at specific points in the project for which data elements data is expected but missing.

Figure 3 shows a snapshot of the EDEx overview table during operation: data instances coming from the providers have been processed according to the linking formulae to fill in data instances for consumers (tags O1, O2, O3). For consumers, the EDEx overview (tag D1) shows the status of the data elements as requested, agreed for provision, or subscribed for delivery. The EDEx overview table (tag D3) shows the status of linked data elements. For a requested data element, there may be several providers. Therefore, the EDEx overview table (see Fig. 3) indicates the cost of providing a data element and the engineering process phase. For example, \({EE \ldots \textit{Signal1}}\) could be obtained from \({PP\ldots \textit{Signal1}}\) at lower cost.

3.5 Engineering Data Exchange Information System Design

This section describes the main architectural components of mechanisms of an EDex information system (EDExIS) to address the requirements for capabilities of the EDex process described in Sect. 3.1 and the use cases described in Sect. 3.2. The design of these mechanisms is likely to vary depending on the application context.

Fig. 4.
figure 4

Semantic link definition on consumer and provider data models, based on [4].

Full size image

EDEx Management and Overview. For managing the EDEx process, the EDExIS has to provide a mechanism providing the capabilities of the EDEx overview table illustrated in Fig. 3, including EDEx definition functions to request, agree on providing, publishing, and subscribing to data elements (see EDEx process steps D1 to D3), as well as setting relevant attributes of and searching the table for understanding the status of the EDEx definition in the project team.

EDEx Data Definition Languages. For EDEx definition, the EDExIS has to process the languages for the specification of consumer and provider data sets, and the language for semantic link definition specifying (a) the dependencies between consumer and provider data sets and (b) the transformation of imported provider data into consumer data.

Figure 4 illustrates examples of semantic link definitions between consumer and provider data models. In the simplest case, the output value is just an identical copy of an input instance value (see Fig. 4, formula DL1, assuming matching IDs for concepts welding cell, conveyor, etc.). Simple cases require scaling and/or shifting the input values, e.g., to adjust for different scales of units, such as m, cm, or mm, or s and ms (see Fig. 4, formula DL2). More advanced links may require more complex formulae including custom functions or combining the instance values from several data elements (see Fig. 4, formula DL3). A link formula can involve one or more providers and data elements as data sources and can encapsulate capabilities for string operations, advanced algorithms, and access to external knowledge, e.g., web services.

EDEx Operation Capabilities. For conducting the EDEx operation steps, the EDExIS has to be able (a) to import and validate provider data, (b) to store imported data versions including their metadata for processing, (c) to analyze the data and semantic links in order to correctly propagate the provider data to consumer data structures, and (d) to select and export consumer data.

4 Evaluation

This section reports on the evaluation of the engineering data exchange (EDEx) process and requirements (a) in an initial feasibility case study [16] with 19 domain experts at a large production systems engineering (PSE) company. The project coordinators for each domain were the same as in the initial workshop, a systems integrator for metallurgic production systems, and (b) in a cost/benefit comparison of the EDEx definition and operation processes to the traditional process of point-to-point exchange of engineering artifacts between domain experts, closing an iteration of the design cycle [19].

4.1 Feasibility Study

Goal of the feasibility study is to evaluate the basic concepts of the EDEx process with domain experts by following the steps of the EDEx process description (see Sect. 3.3 and Fig. 2). Based on the use cases introduced in Sect. 3.2, we designed prototypes of selected user interface elements, such as the overview table, specification, linking, and retrieval as mock-up artifacts. We collected data on the usability and usefulness of the EDEx process based on the Technology Acceptance Model uestionnaire [1, 8].

Further, we developed technology prototypes of the IS capabilities to explore the feasibility of designing the EDExIS concepts with available technologies, including AutomationML for data specification (see [12]), an Excel dialect for the specification of dependency links, Java code for transformations, and BaseX as data storage. We conducted and discussed the EDEx steps in a workshop with domain experts representing the roles data provider (PP, ME, EE, RP in the use cases), data consumer (SimE, PM), and EDEx curator.

Overall, the domain experts found the EDEx process feasible, useful, and usable for basic cases that make up most of the data exchange use cases in their typical project context, assuming that the EDExIS provides effective tool support to automate the data transformation, storage, and selection tasks. The domain experts provided improvement suggestions for the user interfaces, and for describing the data transformation and linking formulae in their context. Further, the domain experts noted that more complex cases may take considerable effort to design and automate.

4.2 Cost/Benefit Considerations

To evaluate the costs and benefits of the EDEx process via a team workspace in comparison to the traditional manual process based EDEx, we elicited needs and estimates from domain experts, who are responsible for engineering and project management of large-scale metallurgic production system projects.

Table 1 presents an overview of the findings for of the EDEx process steps in the use case Parameter exchange for production system simulation by comparing the effectiveness, i.e., correctness of results for a task, and the effort of a stakeholder conducting a task. We applied a 5-point Likert scale (++, +, o, -, –), where “++” indicates very positive effects, and “–” very negative effects. Positive effects refer to high effectiveness of the investigated approaches and to low effort for implementation and application.

Table 1. Effectiveness and effort of manual and EDEx processes, based on [4].
Full size table

Regarding effectiveness, the EDEx process was found effective to very effective by the interviewed stakeholders, both providers and consumers, because they were able to exchange data elements in a traceable and validated way. In the traditional manual approach, the data consumers had to define, procure, transform, and validate the required data for each new delivery with significant effort and prone to errors. However, the application of the EDEx process requires additional effort, especially during the EDEx steps definition (D2) and linking (D3), in particular for providers and for the new role of the EDEx curator.

On the upside, the results of the linking step (D3) significantly improve the representation of shared knowledge in the engineering team, regarding an overview on the dependencies between the engineering roles on data element level. Domain experts and the PM can always get a current overview on the status of data deliveries and can identify missing engineering data and unfulfilled consumer requests.

5 Discussion

This section discusses results of the research questions introduced in Sect. 1.

RQ1. What are main elements of an effective and efficient engineering data exchange (EDEx) process in multi-disciplinary engineering? Section 3.3 introduced as main elements EDEx roles, process steps, and data structures. The new role of the EDEx curator mediates between data consumers and providers. In the feasibility study, a domain expert filling this role informally was identified. The EDEx data structures represent the necessary knowledge on engineering data, semantic links between consumer and provider data, and the status on the EDEx process as foundation for effective EDEx for the use cases and according to the required capabilities for EDEx in multi-disciplinary engineering. The EDEx process facilitates efficient EDEx (a) by considering the benefits of EDEx for consumers and the cost for providers to focus first on the data sets with the best cost-benefit balance and (b) by automating the EDEx operation with support by the EDExIS.

As potential drawbacks of the process, domain experts noted the need to convince data providers to take over the task and extra effort of extracting requested data from their engineering artifacts. For this task, specific tool support, adapted to the project context, will be required as well as appropriate compensation for the extra effort.

RQ2. What are main information system mechanisms that enable engineering data exchange for multi-disciplinary engineering? The EDExIS mechanisms for management and overview, data definition languages, and operation capabilities addressed the requirements for EDEx capabilities in Sect. 3.1 on a conceptual level. These mechanisms facilitate efficient round-trip engineering. The design of an operational EDExIS will have considerable impact on the efficiency of the EDEx process in the application context and needs further investigation.

Limitations. As all empirical studies the presented research has some limitations that require further investigation.

Feasibility Study. We evaluated the EDEx process with focus on specific use cases in cooperation with domain experts in a typical large company regarding the PSE of production systems that can be seen as representative for systems engineering enterprises with project business using a heterogeneous tool landscape. The evaluation results are based on observations from a limited sample of projects, stakeholder roles, and data models. To overcome these limitations, we plan a more detailed investigation in a wider variety of domains and application contexts.

The Expressiveness of Data Specification and Linking Languages, used in the evaluated prototype, can be considered as a limitation. The prototype is able to address an initial set of simple data types, while industrial scenarios showed more complex value ranges and aggregated ranges. While the evaluation worked well with data provided in tables, the evaluation of advanced data structures such as trees or graphs remains open.

6 Conclusion and Future Work

Digitalization in production system engineering (PSE) [18] aims at enabling flexible production towards the Industry 4.0 vision and at shortening the engineering phase of production systems. This results in an increase of parallel PSE, where the involved disciplines have to exchange updates for synchronization due to dependency constraints between the engineering disciplines.

We introduced and investigated PSE use cases and the engineering data exchange (EDEx) process to provide domain experts in PSE with an approach to define and efficiently exchange agreed sets of data elements between heterogeneous local engineering models as foundation for agile and traceable PSE.

Ch1. Unclear Data Requirements of and Benefits for Stakeholders. The EDEx definition phase results in a network of stakeholders linked via data they exchange. This network can grow iteratively, going beyond a one-time process analysis. Therefore, the EDExIS facilitates frequent synchronization between work groups to reduce the risk of divergent local designs, rework, and delays.

Ch2. Heterogeneous Engineering Data is Hard to Integrate for Sharing. Semantic linking allowed the integration of heterogeneous data in the evaluated use cases. The semantic linking enables seamless traceability in the EDEx process that, for the first time, gives all stakeholders the opportunity to know and analyze which role provided or received which kind of engineering data. Further, the EDEx semantic linking improves the representation of shared knowledge in a machine-readable way, a prerequisite for introducing Industry 4.0 applications.

Future Work. The EDEx meta-data will enable consumers and researchers to conduct advanced analyses, such as data validity and consistency, and symptoms for security risks. During the use of EDEx, the complexity of links may grow considerably with the number of data elements, consumers, and providers, which will require research on scalability of EDEx. However, centralizing knowledge in the EDExIS will require research on threats to the integrity of collected knowledge and of industrial espionage.