Keywords

1 Introduction

As presented by Khedher et al. [1], data exchange between Product Lifecycle Management (PLM) supporting industrial information systems like PDM systems, Enterprise Resource Planning (ERP) systems and MES is a crucial success factor for producing enterprises acting in today’s fast-moving markets. The interconnection of smart devices among each other, but also with the mentioned established information systems, is one of the fundamental ideas of the ongoing efforts within the scope of Industry 4.0. Smart interconnected products enable permanent communication which allows the collection of product data in all lifecycle stages, but especially during its use phase. With appropriate processing, this data can be used to derive useful conclusions that initiate enhancements in production processes, maintenance tasks and future engineering design processes. To benefit from these new opportunities, interaction points between involved information systems and additional data sources have to be defined to grant flawless information exchange.

While the international standard IEC 62264 [2] based on the ISA-95 specification [3] defines models and transactions for the integration of ERP and MES, a similar standard for direct communication between PDM systems and MES is missing. Furthermore, the collected data from production facilities is often used to optimize production processes but is not passed on to the product development department, which leaves a considerable product optimization potential unused. Therefore, this contribution presents a concept for closed-loop information integration within the PLM environment of producing enterprises. The following section gives a brief overview of the utilized methodology and related research activities. Section 3 presents the developed integration concept, followed by the introduction of the ongoing case studies conducted with industry partners. At the end of Sect. 4 the results that were attained so far are stated and discussed. The contribution closes with a conclusion and gives an outlook in Sect. 5.

2 Integration Challenges, Methodology and Related Work

In PLM there are three major perspectives which are considered when defining a products life cycle, i.e., engineering, production and operation [4].Footnote 1

The engineering aspect of a products lifecycle reaches from conceptual designs to a detailed product definition maintained in many different authoring tools. That diversity in tool landscapes and development methods requires a systematic combination of approaches and tools. The complex outcome has to be managed by a PDM system [5]. The definition of a product’s properties nowadays happens predominantly in virtual form and is rarely materialized during engineering using rapid prototyping techniques. The main transition from the virtual product definition to a real product is the scope of the production.

Although production aspects clearly affect a product’s definition and vice versa, the two perspectives are somewhat orthogonal to each other. This becomes particularly obvious if the production system has to be developed like a product itself, with a product lifecycle of its own. Production tasks that have to be managed by or interfaced to a PDM system reach from production system conceptualization over operations planning like NC programming to resource and assembly planning tasks, like warehousing, dimensioning of production lines and production resource allocation. A MES has to be linked to an ERP solution to fulfil all tasks of order processing to meet a physical demand for a product. The materialization of a virtual product definition into many physical products can be perceived similar to instantiations of a class in object-oriented programming [6]. The product instances share all properties, which they inherited from their abstract class – although within the variations that the production process imposes – but they are all independent from each other.

The operation or product use phase is a third perspective which again influences engineering and production and vice versa, but is independent from them as each product instance is operated and maintained differently in a particular environment and context. This is the case for mass produced end consumer items as well as specialized high-tech equipment for industrial applications. Information management for operations is often neglected in PDM environments. For certain products, this management task is outsourced to a dedicated maintenance, repair and overhaul (MRO) system and for a number of other products it is handled by after-sales services of ERP systems. Figure 1 shows the mentioned 3 orthogonal perspectives. The right part of the illustration points out the independence of every product instance concerning all considered perspectives.

Fig. 1.
figure 1

Engineering, production and operation as three orthogonal perspectives on the products lifecycle. As the product is materialized, used and maintained multiple times independently there are multiple instances of each perspective. From [4]

Full size image

If problems occur during the use phase of a product, the customer complaint typically traverses different departments in the organizational structure of the manufacturer before the engineering department is involved. A closer link of product instance data to the PDM system, which is the linchpin for data authored in engineering and production, would offer great opportunities to shorten problem solving intervals, provide accurate maintenance scheduling based on current operational data and to initiate continuous product engineering improvements through downstream insights.

This introduces a challenge for modern PDM systems and also points to the need for a methodology to determine which information has to be collected and fed back into a PDM system [4]. An integrated information feedback loop from production and operations back to a PDM system would be a solution but still leaves problems to be addressed, e.g. how to derive product class indicators and necessary change activities from individualized product instance information.

To date, there are not that many research activities which address a direct integration between PDM systems and manufacturing execution. Khedher et al. [1] present an integration concept using a mediation system based on ontologies and web services to interlink data of both systems. The work in this paper takes another step forward and does not only consider data linking, but also processing of manufacturing and operational data from a product’s use phase to generate useful information that can be fed back to a PDM system. Gerhard [4] delivers important conceptual starting points for the integration concept introduced in this contribution. D’Antonio et al. [7] stated advantages of a PLM-MES integration and conducted a survey among Italian companies to confirm the interest in such an integration.

3 Integration Concept

To overcome the problems of outdated, locally stored product information and to be able to benefit from the available data collected during different lifecycle phases, it seems necessary to define new data exchange channels between involved information systems. The goal of the developed concept is to establish a closed-loop information flow between the involved information systems and to integrate other data sources such as production data of production facilities and sensor data of products in their use phase. The closed-loop information circulation can be divided into 2 parts:

  • Forward direction – The propagation of relevant engineering information from the PDM system to downstream recipient systems

  • Backward direction – The feedback of information from the later product lifecycle phases to the product development department

3.1 Forward Integration

The typical information flow in modern producing enterprises from the PDM level down to the shop floor is described in [8] and depicted in Fig. 2. At the shop floor level, product instantiation takes place and production or assembly resources also impart some information to the manufactured product instance, e.g. the firmware of a control unit. Shop floor production resources report production parameters like production times, amount of produced parts, etc. to the MES. MES forwards relevant information to ERP and creates production performance indicators that help to identify optimization potentials concerning the production process. ERP also generates performance indicators based on feedback from MES, Customer-Relations Management (CRM) tools and other systems. If there are engineering relevant incidents, ERP triggers an engineering change request workflow in PDM [9]. These basic upstream information flows are depicted as blank arrows in Fig. 2.

Fig. 2.
figure 2

Conceptual depiction of the forward integration

Full size image

A widespread problem within industrial applications of these information exchange processes is often data actuality and accuracy. Delays in information propagation lead to outdated information in the downstream processes. As a result, avoidable mistakes occur and cause costly corrective actions. The forward integration idea is to avoid that problem by eliminating some data forwarding processes. Instead, necessary engineering information is directly propagated to the target systems. Up-to-date versions of CAD models, assembly instructions and soft- or firmware iterations can be retrieved from PDM using a direct information channel.

There are several important challenges establishing such direct channels that have to be addressed accordingly:

  • All relevant product information has to be stored in PDM – no separate non-synchronized information storage in downstream information systems is allowed to avoid the usage of outdated information.

  • The provided information must be easily updatable. Therefore, information has to be displayed in electronic form on a screen, no printed hard copy or locally saved document is needed.

  • A feedback system has to be provided to information recipients to report errors or make improvement suggestions.

In general, a modern PDM system provides all necessary technical functionality to tackle the mentioned challenges. The first point has to be anchored in the organizational structures and the work processes of the enterprise. PDM has to be accepted as the central product information repository. All relevant and required information on product class and product instance level has to be managed in PDM. Presentation of the information can be done via thin clients running in a standard web browser on various devices, like computer terminals, handhelds, tablets, smart phones, etc. This ensures low efforts for deployment and roll-out. The possibility to give feedback can be realized via PDM workflows, triggered via the thin client.

3.2 Backward Integration

The main goal of the backward integration is to use data collected during the manufacturing processes and also the operation phase of a product to identify improvement potentials for next generation development projects and maintenance aspects. Figure 3 shows the involved information systems and a product instance.

Fig. 3.
figure 3

Conceptual depiction of the backward integration

Full size image

A data analytics platform is used to generate valuable insights for product development from gathered data of production planning, production and product use (operation). The platform offers a data lake for data storage, analyzes different types of data, and calculates key indicators that are forwarded to PDM. These calculated parameters are referenced to 2 different types of information objects – product class (or product type) and product instance (or product entity). PDM data structures are usually designed to operate with product classes, not with single product instances. Therefore, it is necessary to add product instance data structures in PDM. Figure 4 depicts the mappings between the involved data structures in the data analytics platform and PDM. The different mappings are explained in the following:

  • A: This mapping keeps track of the link between product classes and their instantiations. It can be implemented by creating a snapshot copy of the product’s class valid at the time of production. The identification of production parts can be done by a serial number and brought-in parts can be identified with their respective batch number or serial number. This mapping represents a 1:n mapping from one product class to many instantiations. As the product instance matures, the product class can mature, too. With a new production release, a product class may change. New product instances have to be mapped to the revised class and also can have new and matured properties.

  • B: As the sensors of each product instance are connected to the data analytics platform, their data (e.g. time series) is stored as semi-structured data in a data lake and identified by a hash code. Within the platform, the stored data is mapped to individual structural data elements called assets. Assets represent a physical entity in the virtual space. The asset structure is not as deep and complete as the Bill of Materials (BOM) but it offers enough structure to link streams of sensor data to an appropriate position in a product’s structure.

  • C: This mapping is the actual link from product instances in PDM to its structured asset data collection in the analytics platform. If there is an issue with a product instance, the manufacturer can look up the products individual as-build BOM in PDM and visualize current and historical data from the products sensors and data sources. Ideally, the data collection offers visualizations to support the identification of trends and anomalies.

  • D: To generalize conclusions from product instance data streams to a product class, an aggregation of data sources over all surveyed instances has to be realized. This aggregation can be as simple as showing basic statistics (e.g. mean, variance, distribution parameters) but also advanced like cluster identification, self-learned correlations of product data (e.g. operating hours and bearing temperatures) and sophisticated like pattern recognition for cause and effect analysis. The ability to offer these insights at a scalable level is one of the key arguments of using a data analytics platform.

Fig. 4.
figure 4

Mapping of data structures in the backward integration

Full size image

4 Use Cases

The following subsections give a brief overview of the use cases currently conducted in a research project of the authors together with industry partners to evaluate the feasibility of the introduced concept.

4.1 Forward Integration

A research survey of state-of-the-art solutions found that there is already a tool for the intended concept. Forwarding manufacturing and assembly information of high variance products from PDM to MES or shop floor terminals can be done by Cortona3D and Teamcenter. The software package is also known as “rapid author” and is usually used to derive detailed and visual documentations and publications from CAD data, such as customer manuals, professional maintenance instructions, training material, animated video or HTML for online publication. Being integrated into the Siemens ecosystem of PLM software Cortona3D offers an integration to Teamcenter [10]. The integration allows the import of CAD models from Teamcenter in Cortona3D and the attachment of Cortona3D-based work instructions to a Bill of Processes in Teamcenter manufacturing and production planning modules.

The goal of the use case is to document the extruder assembly process of a 3D FDM printer (shown in Fig. 5), which is produced as demonstration product at the TU Wien Pilot Factory Industry 4.0 [8]. This product can be configured with different options and dimensions, which leads to variant rich assembly processes. Cortona3D is used to build a digital documentation based on the current variant without the need to create new production drawings and assembly instruction. This documentation is visualized using the Teamcenter Active Workspace thin client. The only technical restriction for an end device to use the Active Workspace user interface is an up-to-date web browser. [11]

Fig. 5.
figure 5

Screenshot of an assembly process

Full size image

4.2 Backward Integration

The use case for the backward integration concept is demonstrated by the integration of a machining center located in the TU Wien Pilot Factory. This is an excellent example as it covers aspects of the production and operation phase. The machining center delivers production data for various products, but is also a product itself and is developed and improved continuously based on insights from its utilization. Since the manufacturer of the machining center is partner of the research project, all relevant engineering data of the machining center is accessible for the use case.

Figure 6 illustrates the data and information flow between the machining center, the data analytics platform and the PDM system. The machining center is directly connected to Mindsphere – an industrial data analytics platform developed by Siemens – via Sinumerik interface, using the Manage MyMachines application to link a real-world asset to Mindsphere. Data points are stored in the data lake of the analytics platform. In the backward integration use case, there are two self-programmed applications to generate useful insights. A backend data processing application is doing the analytics, while a frontend visualization application generates graphical representations of the processed outcomes. The visualized information is then linked to the corresponding product instance or product class structures in Teamcenter using a web service developed in the project. The information retrieved from the data analytics platform can be used to trigger engineering change requests or maintenance tasks. One example of such information is the interrelation of bearing temperatures with different operational states of the main spindle. This information can be used for constructive improvements or the determination of optimal maintenance intervals.

Fig. 6.
figure 6

Backward integration use case

Full size image

Mindsphere also allows data exchange with other information systems using the MindConnect library [12]. A next step to realize the backward integration concept to its full extent would be to gather production data from the MES system as well and use it for calculations in Mindsphere, too.

4.3 Results

Both use cases are currently subject of an ongoing research project. While the concepts for both integration directions are defined, the implementation works are still in progress. Currently, the focus is put on the implementation of the backward integration in the environment of the TU Wien Pilot Factory Industry 4.0. Nonetheless, some interim results in terms of experiences made during the implementation works can already be presented here.

Mindsphere seems to be a powerful data analytics platform but has some restrictions:

  • The time interval for collecting data points is limited to a few seconds in Mindsphere. For smaller intervals, an additional edge computing device has to be used.

  • The limited structuring options in Mindsphere do not allow a comprehensive representation of product structures out-of-the-box. E.g. inheritance of parameters is not implemented in the Sinumerik asset type used for direct interconnectivity.

  • Teamcenter is currently not able to manage product instance information out-of-the-box. Although most of the functionalities for product classes can also be applied to product instances, some crucial aspects are missing, e.g. specialized product instance elements and “derived” relations that connect product instance elements with their parent product class elements.

5 Conclusion and Outlook

The research done in the presented project shows that recent PDM systems provide only cumbersome support for managing product instance information. Recording and storing as-build structures of individualized product instances is a valuable basis for engineering changes on complex high-variant products. The sheer amount of data that comes along with product instance management in PDM has also to be addressed appropriately.

There are several challenges concerning information retrieval from raw sensor data of physical products. Different measuring intervals and accuracy complicate data analyses, but the combination of various parameters is necessary to receive meaningful information that enables engineering improvement. Another big factor is the frequency of information feedback. While some propagation is clearly event-based, e.g. machine failures, other processing-intense repetitive tasks, e.g. the comparison of spindle bearing temperatures as a function of parameters like spindle torque, speed, operating mode, etc., using data from all available product instances, have to be limited to a feasible interval.

The technical requirements to realize the forward integration approach presented above are already met by state-of-the-art PDM systems. The biggest challenge here is to create acceptance for PDM as the single central product information repository.