Keywords

1 Introduction

The digital transformation, that is now widespread in industrial companies, is a mean to increase quality of products and services through a full deployment of ICT (Information Technology Tools). One of digital transformation core concept is digital continuity or digital thread. This rests upon the idea of a channel to capture and share data across the company. There have been many works, theoretical and practical, in the last 30 years, supporting companies to deploy a digital thread through their organization. There are several axes framing digital thread. The focus can be on a PLM (Product Lifecycle Management) aspect, or on a more OM (Operations Management) aspect, depending on the source of the data. Yet the digital thread along these axes was limited by the interoperability between systems. Lately, new proposals addressing interoperability (communication standards, Service Oriented Architecture, Multi Agent Systems) provide solutions to foster digital thread in these existing frames. But they also enable new, more distributed, architecture, that are becoming interesting alternatives.

The present paper intents to question the current divergences between these axes and explore the possibilities for a convergence. Section 2 will describe the digital thread along three identified axis. Section 3 will explore recent proposals that may challenge this axes division. Section 4 will discuss the risen challenges and opportunities.

2 Integration Axis

Digital thread, and its integration, relies on the concept of interoperability. The term “integration” can have several meanings while addressing interoperability questions. This section will clarify this ambiguity but as well define interoperability.

Integration can refer to the concept of interoperability: “interoperability lies in the middle of an ‘integration continuum’ between compatibility and full integration” [1]. Furthermore, [2] proposes three integration axes: vertical, horizontal, and end to end. Vertical integration describes the intelligent cross-linking and digitalization across the different aggregation and hierarchical levels of a value creation module from manufacturing stations via manufacturing cells, lines and factories. Horizontal integration describes the cross-company and company-internal intelligent cross-linking throughout the value chain of a product life cycle and between value chains of adjoining product life cycles. PLM integration describes the intelligent cross-linking and digitalization throughout all phases of a product life cycle: from the raw material acquisition to manufacturing system, product use, and the product end of life. These three integration axes are the subject of the present section.

2.1 Integration Through PLM

“PLM can be broadly defined as a product centric – lifecycle-oriented business model, supported by ICT, in which product data are shared among actors, processes and organizations in the different phases of the product lifecycle for achieving desired performances and sustainability for the product and related services” [3]. It is critical to ensure a data continuity linking the different tools used for product design and manufacturing. For the product development cycle (including design, simulation, manufacturing and assembly), [4, 5] conclude that the two main ways to reach interoperability between the different systems are the use of standard formats, and of ontology models.

Ontologies are explicit specifications of a conceptualization [6]. A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Every knowledge base, knowledge-based system, or knowledge-level agent is committed to some conceptualization, explicitly or implicitly. In a literature review [7] presents several ontology based product models such as PRONTO, PSL, OntoPDM, PROMISE, OntoSTEP. These ontologies can be built from scratch or based on existing standards. [8], makes a proposal for using ontology to enable semantic interoperability between different PLM systems, that does not lead to any technology constraint or tool.

Then, the link between data from the design phase to the actual production is handled by the Product Data Management. “PDM is the system developed to efficiently manage the product-related data and entire data flow for the work process emerging from new product development or existing product modification based on the work of the R&D division. Therefore, in the manufacturing industry, the connection from PDM of product data, that is, of Bill of Material (BOM) data, to ERP is an essential requirement and also the most important problem that needs to be solved” [9]. The link between engineering data and manufacturing data is done through the transformation of the Engineering BOM (EBOM) in the Manufacturing BOM (MBOM) at the ERP level [10].

Predictably the Beginning Of Life (BOL) is the phase with the largest quantity of data, and for which more efforts have been made to reach interoperability. Regarding the latter stage of PLM, Middle and End of Life (MOL, EOL), there are less use cases because of the lack of data. It would be interesting to assess accurately what frameworks now exist for these stages of PLM, and how it can interact with OM.

2.2 Integration for Operation Management

While PLM is product centric, horizontal and vertical integration refer to the architecture of the company. This architecture, although handling product data, is the support of Operations Management: “OM is management of a systemic transformation process to convert a set of inputs into outputs”. It rests on the ERP, as a central pillar, but also embraces other management systems (Supply chain management, customer relationship management., supplier relationship management., knowledge management.) [11].

Fig. 1.
figure 1

Automation pyramid [12]

Full size image

A breakdown in several business layers of the IT system has been proposed in the ISA-95 [12] (Fig. 1) framework: Level 0 and 1 are contained in the machines that compose the industrial system. There the integration issues are the prerogative of the Original Equipment Manufacturer (OEM).

Focusing on the 3 higher levels, (2:SCADA, 3:MES, 4:ERP) [13] proposes a new pyramid more consistent with the current integration questions (Fig. 2). The different machines are part of the field level and may be connected, although using distinct technologies (from legacy PLC to recent NC). The scope of the cell level is the orchestration of the different systems on the field level, in order to achieve the goals set at company level. MES and the human management of operations would occur at cell level; and ERP at company level.

Fig. 2.
figure 2

Revised automation pyramid [13]

Full size image

2.2.1 Integration Across Manufacturing Process (Horizontal)

Discussing the horizontal integration at field level is assessing the interoperability between the different machines. In the framework of [14], it can be achieved by “integration”, “unification”, or “federation”. The integration approach means a standard is used by all the components. The current standard that is broadly spread is OPC UA, although MQTT is an emerging alternative [15]. Yet some systems that share more specific functions can have a more specific standard (AML, PackML). However it is common to see in a shopfloor successive generations of machine [16] that communicate and compute differently. In this case a semantic data model can oversee the communications, providing a translation between any component, suiting [14] definition of unification. Otherwise, interfaces can be set between components to manage semantic translations issues, realizing interoperability through federation. Asset Administrations Shell is an application of this strategy [17]. Notwithstanding these conceptually different approaches, it is usual to mix them to extend the scope of interoperability, to provide bridges between different standards or data models.

For cell level integration, MES solutions are usually unique for a given production system and do not need horizontal interoperability. Regarding company level, ERP interoperability in the context of extended enterprise is a challenge but it does not enter the scope of this paper.

2.2.2 Integration Across Business Layers (Vertical)

Data from machines is used strictly for follow up of production progress but an automated access at a sufficient rate enable more uses, such as monitoring for preventive maintenance [18] or near real time modelling for digital twin [19]. The main prerequisite of these use cases is the deployment horizontal integration with recent standards at field level (OPC UA or else). Regarding interoperability between ERP and MES layers, it is less of a challenge because both MES and ERP (Fig. 2) networks are IP based; there is no issue regarding technical interoperability. Still the question of semantic understanding stands. As a solution for this, MESA formalized a standard, B2MML (Business to Manufacturing Markup Language) that consists of a set of XML schemas written using the World Wide Web Consortium’s XML Schema language (XSD) that implement the data models in the ISA-95 standard.

Vertical and horizontal integration, as well as PLM integration, were built on a partition of high-level processes and organization in distinct layers, to frame tools and methods to be use successively. It was necessary when there was no set of interoperable ICT solutions to manage the workflows throughout a company. Now, the progress of ICT tools and their deployments in industrial companies challenge the idea of integration following numbered steps.

3 Architectures and Distributed Approaches

3.1 Multidimensional Architecture Model

In a recent review of enterprise architecture model, [20] lists IIRA (2015), RAMI 4.0 (2015), IIVRA (2016) SITAM (2016), IBM industrie 4.0 (2017) and LAFSA (2019), that were created in the frame of Industrie 4.0. Amongst these 6 architectures, it is RAMI 4.0 and IIRA, that are the most popular and frequently mentioned. They both are supported by industrial consortia: German Electrical and Electronic Manufacturers’ Association (ZVEI) for RAMI 4.0 and the Industrial Internet Consortium (IIC) for IIRA.

For instance, RAMI (Fig. 3) has three dimensions: business layers, life cycle value stream and hierarchy levels that create a multi-dimensional model allowing detailed partition of the enterprise layers.

Fig. 3.
figure 3

RAMI 4.0 [21]

Full size image

These reference architectures are remarkably different from the ISA95 proposal, and challenge the approach by integration (horizontal, vertical, PLM) because they intent to address all the different dimensions at once, and thus cannot be linearly described.

3.2 Service Oriented Architecture

Similarly, the service-oriented architecture is an architectural approach for software development that allows the recursive aggregation of services into new business processes and application. [22]. SOA takes business applications and breaks them down into individual functions and processes as services. Each existing services can be recomposited, reconstructed, and reused to new applications [23].

SOA addresses the requirements of loosely coupled, standards-based, and protocol independent distributed computing. Business operations running in an SOA comprise a number of invocations of these different components, often in an event-driven or asynchronous fashion that reflects the underlying business process needs. This functionality is provided by the Enterprise Service Bus (ESB) that is an integration platform that utilizes Web services standards to support a wide variety of communications patterns over multiple transport protocols and deliver value-added capabilities for SOA applications [24]. More practically, ESB is a three-party system with service providers on one side, service customers on the other side, and a service broker that orchestrate the exchanges.

Unfortunately, ESB is a solution only for software integration, and does not embrace industrial components. Yet, [25] and [26] offer an experimental extension of the ESB to the manufacturing operations, with a Manufacturing Service Bus (MSB). They explain that the traditional layers hierarchically ordered can be directly linked together with the MSB. Thus, there is more flexibility for the business processes to make interact directly any of its module notwithstanding any hierarchical difference. Other similar proposals based on ESB exist: Line Information System Architecture (LISA) [27] or a service bus gathering PLM, ERP and MES [28].

3.3 Multi Agent Systems in Manufacturing

[29] presents current and future industrials systems as Cyber Physical Production Systems (CPPS). CPPS are composed of industrial Cyber Physical Systems (CPS): collaborating computational entities which are in intensive connection with the surrounding physical world and its on-going processes, providing and using, at the same time, data-accessing and data-processing services available on the Internet. This new distribution of data-accessing and processing among the components of industrial systems challenges again the automation pyramid (Fig. 4): it is now possible to take decisions at a lower level for real time critical events.

To summarize, the latest enterprise architecture reference model are matrices with numerous interdependent partitions to be addressed and integrated. From the ICT perspective, SOA is now a mainstream solution to ensure interoperability in the IT layer of the companies in a heterarchical way (Fig. 4). Then, from the machines point of view, the concept of CPPS considers distributed computation power and new communication protocol ensuring direct interoperability at the lower level. All these approaches are consistent together but divergent compared to the linear and step by step integrations presented earlier.

Fig. 4.
figure 4

Transition from traditional industrial automation pyramid to cross-layer entity-to-entity communication [20]

Full size image

4 Discussion and Conclusion

Digital thread is a key challenge today because numerous software and data sources coexist and there is a high business value to have a consistent set of interoperable solution to capture and use data. Section 2 presented the major guidelines for product data and enterprise systems, namely PLM, and vertical and horizontal integration based on ISA-95 automation pyramid. Lastly Sect.  3 focused on newer approaches that lean on technologies recently available for industrial systems.

Although PLM and automation pyramid have structured industrials companies while ICT tools were not available and integrated, new technologies and concepts are now emerging that does not need so many layers and that provide more distributed abilities.

Firstly, the developments in this paper show a simplification of the issues about vertical integration. Originally, the automation pyramid [12] had five levels. Regarding industrial organizations, the integration effort from OEM has compressed in one “field level” the first 3 (0: sensors and actuators, 1: automation, 2: SCADA) [13]. In the meantime, the broad deployment of SOA in IT-based networks, through ESB, has flattened all hierarchy between software [24]. It then remains only two levels: the Information Technology (IT) layer (IP-based network) and the Operational Technology (OT) layer (Field area networks). Nowadays, the research efforts for vertical integration are thus mainly focusing on the IT/OT interface.

ESB extending to the manufacturing process seems a very promising SOA solution, using multi agent systems. Some experiments have been successful, but their scope is quite small. An interesting research axis would be to assess the scalability and the robustness of this concept at a company size. SOA could support the rising alternative to traditional hierarchical architectures: decentralized networks (Fig. 4) of CPS. These systems have by definition the ability to take decisions autonomously, thus providing indisputably quicker reaction time. The need for near real-time decisions, and for reactive and flexible systems [30] could become the issue that will trigger a reassessment of traditional architectures: “As a result rigid and centralized organizations may become obsolete” [29].

With the emergence of decentralized systems, also comes the possibility to set up local optimizers to deal with disturbances or unforeseen events. Yet the need for a global optimization remains to reach delivery dates and performance goals. To handle both, Dynamic Architectures have been proposed. [31] present a state of the art and the current challenges of hybrid control architectures, that include switching systems between a predictive mode (globally optimized) and a reactive mode (locally and temporarily optimized). These theoretical architectures are very complex; but if they reached a sufficient level of maturity, they could become mainstream thank to their unmatched industrial efficiency.

Lastly, the opposition between PLM integration and OM integration was seeming until the creation of new architecture reference models that support both axes. The link between data from the product (drawings, BOM, …) and from the industrial system (OEE, machines static parameters, …) are theoretically possible but a unified data model would have a very large scope. For instance [32] proposes compatible data models for product and process to link PLM and Equipment (machines) Lifecycle Management in aircraft manufacturing, resulting in an already very complex model.

To conclude, the historical PLM and OM architectures have been both designed and deployed to manage system and tools that were in no way interoperable. The recent technological advances, on software, hardware, and communication protocols, have unlocked new possibilities of integration, that bypass these architectures. The research axis emphasized in this paper are about the scalability of decentralized systems applied to manufacturing systems, SOA and dynamic architectures; and also, about the development of solutions handling both product data and operation management data overpassing the historical lack of awareness between PLM and Operation Management systems.