Reference Models for Digital Manufacturing Platforms

Abstract

This paper presents an integrated reference model for digital manufacturing platforms, based on cutting edge reference models for the Industrial Internet of Things (IIoT) systems. Digital manufacturing platforms use IIoT systems in combination with other added-value services to support manufacturing processes at different levels (e.g., design, engineering, operations planning, and execution). Digital manufacturing platforms form complex multi-sided ecosystems, involving different stakeholders ranging from supply chain collaborators to Information Technology (IT) providers. This research analyses prominent reference models for IIoT systems to align the definitions they contain and determine to what extent they are complementary and applicable to digital manufacturing platforms. Based on this analysis, the Industrial Internet Integrated Reference Model (I3RM) for digital manufacturing platforms is presented, together with general recommendations that can be applied to the architectural definition of any digital manufacturing platform.

1. Introduction

There is a strong demand for new system architectures able to address the requirements emerging from globally interconnected manufacturing structures [1]. The high demand for high demands of variability, efficient supply chain, and optimized energy consumption [2] and the rapid growth of the industrial Internet and cyber-physical technologies have led to the development of several new paradigms for manufacturing in recent years. Industry 4.0 (I4.0) is expected to generate new business models, as well as increase the efficiency of manufacturing processes [3]. I4.0 proposes making use of relevant disruptive technologies that enable autonomous communications among multiple industrial devices distributed throughout a factory and on the Internet [4]. Examples of these new paradigms include smart manufacturing, cyber-physical production systems, I4.0, cloud manufacturing, and social manufacturing [5].

The digital economy, defined by fundamental changes in the characteristics of information, computing, and communications, is now the preeminent driver of economic growth, social change, and sharing economy [6,7]. In the digital economy, platform models have strongly proliferated over the past years, reducing transaction costs and facilitating exchanges that otherwise would not have occurred [8]. Digital platforms facilitate transactions between organizations and provide services and/or products on the top of technological building blocks used as a foundation to deal with competitive pressures [9,10]. In light of this, digital manufacturing platforms enable the provision of services associated with collecting, storing, processing and delivering data. These data are either describing the manufactured products or are related to the manufacturing processes and assets that make manufacturing happen (material, machine, enterprises, value networks, and—not to forget—factory workers) [11].

Digital Manufacturing was coined as one of the core strategies of the European Manufacture vision and strategic agenda towards the knowledge based production [12]. Currently, the rise of digital platforms for manufacturing is a reality as they play a key role in supporting collaborative manufacturing, service, analysis, and forecasting processes in business networks. Moreover, they provide flexibility to enterprises by fast and simple orchestration of services and applications [13].

From an economic viewpoint, digital platforms are restructuring ever-more parts of the global economy. In many cases, they have disrupted the existing organization of economic activity by resetting entry barriers, changing the logic of value creation and value capture, repackaging work, and/or often repositioning power in the economic and network system [14].

From a commercial viewpoint, reference [15] states that competition in the platform economy will be fierce, especially as companies from adjacent sectors extend beyond their traditional markets. Moreover, it is also highlighted that digital platforms disrupt and dominate markets to create communities of enormous scale, offering new forms of innovation and value creation and this requires the definition of appropriate business and commercial models focused on digital manufacturing platforms’ value proposition. Based on this, it seems that the creation of digitally enabled platforms for manufacturing will continue to evolve over the following years, which indicates that reference models will be necessary to facilitate this evolution providing reference approaches to locate use cases in an appropriate way saving time and costs.

Reference models, such as the Reference Architecture Model for Industry 4.0 (RAMI 4.0) 1, provide a solution-neutral reference architectural model for applications that make use of Internet of Things (IoT), big data analytics, and other technologies advancements in manufacturing processes, what is known as smart manufacturing, intelligent manufacturing, or simply Industry 4.0. Reference models represent a common structure and language to describe and specify system architectures and, therefore, are beneficial to promote common understanding and system interoperability. In the architectural definition of a digital manufacturing platform, the alignment to these reference models is positive because they provide a framework for the standardization of relevant technical systems, from development, through integration, to operation. Thus, the liaison with reference models provides the right orientation to system architecture definitions and fosters component orchestration, collaboration with relevant organizations, and internationalization.

The main objective of this paper is to analyze the different cutting edge reference models to identify synergies and complementarities. The analysis is then used to develop an integrated reference model that combines features of the different models under analysis to support the architectural definition of digital manufacturing platforms from practical use cases. This integrated reference model is also based on the results obtained through a benchmarking performed where it is evinced that there is not a unifying and integrating reference model that covers all use cases. Moreover, it is worth mentioning that the driving force for the definition of the Industrial Internet Integrated Reference Model (I3RM) is the real need detected in the ‘Zero Defect Manufacturing Platform’ (ZDMP) project, a research project funded by the H2020 Framework Programme of the European Commission. The main objective of this project is to develop the European zero-defect reference platform and to do so, it has been identified that a broader reference model is necessary because the alignment analysis evinced that the current ones do not provide enough reference information for the platform, i.e. the project needs a reference model to create the particular model of ZDMP [16].

The number of digital manufacturing platforms seeking to improve production efficiency or to generate new revenue models for solution providers has grown in recent years, and given the potential benefits of I4.0, it is expected to continue experiencing rapid growth in years to come. The results of this paper can be applied to facilitate the development and interoperability of both commercial and research-oriented solutions in this expanding field.

Bearing this in mind, the approach taken in this document first aligns the definitions included in the different reference models. The method used for the alignment is based on the analysis and comparison of the definitions contained in each reference model, which is a common approach towards reference model alignment. This is the method used by the different alignment reports referenced in this research work and, consequently, the same method is used to perform the alignment of reference models when there is no existing information about the alignment degree available. The comparison method is based on analyzing and then studying the correspondence of the life cycles, layers, levels and functions, and components of each of the reference models. Moreover, for each of the aforementioned factors to be compared, a three-element comparison scale has been defined: (i) complementary; (ii) similar; and (iii) not similar. The motivation for this analysis is to, afterwards, derive a set of recommendations and an adequate reference architectural model to guide the definition, implementation, and validation of any digital manufacturing platform use case. Besides this, the comparison offers valuable information to take advantage of the synergies, correspondences, and divergences of the studied reference models to have a deeper understating and facilitate their usage.

2. State of the Art

Reference models for I4.0 is a novel research field that requires special attention in new Internet and cyber-physical paradigms for manufacturing. For the most part, reference models for I4.0 are based on the Computer Integrated Manufacturing Open System Architecture (CIMOSA) [17] and the ISA 95 standard [18], at least to some extent.

CIMOSA is an event-driven approach to model enterprise processes in an integrated computerized framework [17]. ISA 95 is an architectural model to facilitate the integration of the enterprise functions and control systems. It provides a hierarchical structure of the manufacturing systems from production processes to a higher level, i.e. business logistics [18].

The Reference Model for Industrie 4.0 (RAMI 4.0) [19] is a unified architectural reference model that provides a collective understanding for I4.0 standards. It can be regarded as a tool to map I4.0 concepts and use cases. In RAMI 4.0, I4.0 components are defined in their structure and functions. The model provides an orientation for plotting the requirements of use cases in order to define and further develop I4.0 concepts and products. RAMI 4.0 is based on the Smart Grid Architecture Model (SGAM) [20], a model developed for purposes of communication in networks of renewable energy sources [21], which seems suitable for I4.0 applications as well.

The National Institute of Standards and Technology (NIST) promotes the Smart Manufacturing vision [22] as a fully integrated, collaborative manufacturing system able to cope with the challenges for quality, efficiency, and personalization that manufacturing companies are facing today. Through the adoption of NIST Smart Manufacturing standards, small-to-medium sized companies can implement this vision, benefitting from public documentation, reference software implementations, and conformance testing.

China’s National Intelligent Manufacturing System Architecture (IMSA) [23] is the response of the State Council of the People’s Republic of China to foster the standardization works that will guide the upgrade of Chinese manufacturing towards intelligent manufacturing. Developed by the Ministry of Industry and Information technology of China (MIIT) and the Standardization Administration of China (SAC) [24], and presented in the Made in China 2025 document, the intelligent manufacturing concept involves the integration of new information technology, new materials, numerical control tools, novel equipment, and machinery as key areas to support the development of the Chinese economy.

IMSA is basically a guideline for the construction of standards to facilitate the interconnection of manufacturing processes since this interconnection and interoperability are regarded as the key drivers to materialize the intelligent manufacturing concept.

The Industrial Internet Reference Architecture (IIRA) for Industrial Internet of Things (IIoT) Systems [25] was first published in 2015 by the Industrial Internet Consortium (IIC) Task group. Consortium members include systems and software architects, and business and security experts in different IIoT application domains, mainly Energy, Healthcare, Manufacturing, Public Domain, and Transportation. The reference architecture enables IIoT system architects to design their own systems using a common vocabulary, a standard-based architecture framework, and reference architecture. These follow the ISO 42010 System and software engineering architecture standard [26], where the architecture of software systems is described, analyzed, and defined to solve specific concerns from the viewpoint of different stakeholders.

Similar to IIRA, the IEEE Standard for a Reference Architecture for Smart City (RASC) [27] is another reference architecture for IoT systems based on ISO 42010 in the domain of smart cities. Likewise, IBM Industry 4.0 Reference Architecture presents a three-layered distributed architecture that takes into account the requirements for autonomy and self-sufficiency of each production site and balances the workload between the edge, the plant, and the enterprise [28].

Reference [5] performs a critical review of some of the previous reference architectures for smart manufacturing. They point out that neither RAMI4.0 nor IIRA addresses micro-services and their role in transitioning from the automation pyramid to a cyber-physical system-based ‘automation network’. The IBM and NIST architectures are mainly associated with macro-services (i.e. large software applications), and they do not specify how loosely-coupled micro-services can be composed, shared, and utilized on-demand and throughout value networks of collaborating and competing enterprises. The authors also consider that RAMI4.0 is focused on how smart objects communicate, and not on how they interact in an autonomous and adaptive fashion to enable plug-and-produce work. The last two analyzed aspects are related to the fact that mechanisms for dynamic and decentralized mapping of smart objects onto micro-services are not clearly specified by any of the reference architectures and none address human-machine symbiosis.

Reference [29] presents a comparative analysis of IIRA and RAMI 4.0 with regards to the two key technological pillars for I4.0: cloud computing and big data.

Reference [30] develops an architecture proposal based on RAMI 4.0 to provide the functionalities that allow the guidance of the products in productive systems using a mechanism similar to the Domain Name System (DNS) used on the Internet. In this sense, the architecture allows for choosing the equipment that will execute a given operation through the communication between equipment and products during the manufacturing processes. The functionalities of this architecture are modelled using production flow schema, and their dynamic behaviours are verified and validated by Petri net models. In addition, the architecture is used in a modular production system to verify the appropriateness of RAMI 4.0 as a support for the definition of architectures for I4.0.

Reference [1] also compares IIRA and RAMI 4.0 with each other and the latter with the Open Connectivity Unified Architecture (OPC UA) [31], a service-oriented architecture candidate to the standardization of IoT based manufacturing platforms. They also propose a preliminary architecture of a prototype smart factory related to virtualized and connected services from RAMI 4.0 and IIRA layers in the case of a cloud-deployed manufacturing environment. Authors conclude that the combination of IIC and RAMI 4.0 architectural guidelines may find relevant coexistence in end-to-end and complementary IIoT solutions.

Reference [8] develops an archetypal and real-world and large scale global use case of smart appliance management that consists of more than 12,000 ice cream machines connected worldwide. The architectural aspects of the solution described by [8] are aligned with the RAMI 4.0 guidelines. The authors explain that their solution nicely fits the RAMI 4.0 layers vertical dimension. Moreover, the relevance of the RAMI 4.0 life cycle and value stream direction is demonstrated by the fact that their solution exploits RAMI4.0 type/instance approach. However, smart appliances only partially follow the RAMI 4.0 hierarchy levels direction in relation to communication.

In the literature, there are only a few case studies that follow the RAMI architecture, and the ones found require efforts in different aspects to reach the level of practical implementation [30]. Moreover, some of the studies analyzed [5] identified issues that are not currently addressed in RAMI 4.0. For this reason, it is important to extend and complement RAMI 4.0 with other contributions to provide practitioners with a completely integrated reference model to support the architectural definition of digital manufacturing platforms.

3. Reference Models Alignment

3.1. Reference Model for Industrie 4.0 (RAMI 4.0)

RAMI 4.0 is based on a three-dimensional coordinate system consisting of the Layers, Life Cycle & Value Stream, and Hierarchy Levels dimensions, which is represented below in Figure 1. This structure can be used to systematically organize and further develop I4.0 concepts and technologies.

RAMI 4.0 regards any technical asset of the factory as an entity that can be represented in the digital world to conform an I4.0 component (a component of the manufacturing system that can interact with other components or systems through well-known digital interfaces). In addition to this three-layered reference model, RAMI 4.0 also provides specifications for the administration shell, which is the part of the I4.0 component that includes all the relevant information for representing the asset and its technical functionality. Thus, I4.0 components interact with each other through service-oriented architecture-based interfaces provided by the administration shell, which can be regarded as a standardized digital representation of the asset.

Due to the importance that the RAMI 4.0 definitions have in this analysis, the three dimensions are briefly introduced as follows.

3.1.1. Layers

RAMI 4.0 Layers represent the different Information Technology (IT) management layers of I4.0 project implementation, organized in a vertical axis. Each layer gathers different manageable parts of the system (e.g., data maps, communications, hardware), provides services to the upper layer, and orchestrates services from bottom layers. The different layers defined are:

• Business layer: maps the business model, the overall process, and the rules that the system has to follow. The business model layer ensures the integrity of the functions in the value stream. It also provides the regulatory and legal framework conditions. The business layer orchestrates the services of the functional layer and receives events that inform of the progress of the business process.
• Functional layer: provides the runtime and modelling environment for the services that support the business layer. Remote access and horizontal integration take place in the functional layer, except for processes that are only relevant for lower layers (e.g., reading diagnosis data) or that are not relevant to permanent functional or horizontal integration (e.g., maintenance).
• Information layer: contains the data services that enable the ingestion, use, and maintenance of the data used, generated, or modified by the technical functionalities of the assets. This includes data persistence, provisioning, integration, and integrity. It receives events from the physical asset via lower level layers and applies the adequate processing and transformation to support the functional layer services.
• Communication layer: provides uniform communication and data formats that allow the access of information and provides interfaces to access the functions of an asset from other assets.
• Integration layer: represents the transition from the physical world to the information world. The integration layer contains a representation of the properties and process-related functions of an asset and reports events from the physical world. The integration layer includes asset documentation, software and firmware, or Human-Machine Interfaces (HMI).
• Asset layer: represents reality, i.e. the physical instance of the asset which is represented by all other layers.

3.1.2. Life Cycle and Value Stream

The second axis in the RAMI 4.0 reference model represents the life cycle of products and systems and is taken from the IEC 62890 standard [32]. The product life-cycle model first introduces a differentiation between product type and product instance. A product type is characterized by a unique product identifier, all the documentation associated with the product (development documents, manufacturing and test descriptions, technical documentation, etc.), and the required certificates. This definition of product type is valid for either hardware and software products, or software or hardware parts of products that bundle both hardware and software. A product instance, on the other hand, is an individual instantiation of a product type. A product instance is characterized by a unique instance identifier, such as a serial number or ordering number.

From this fundamental differentiation between type and instance, the product life-cycle is divided into phases that detail the life cycle of both product type and product instance. Hence, all activities that concern the development, maintenance, and service of a product type, refer to the product type. In a similar fashion, all activities regarding the production, maintenance, and servicing of a specific product instance refer to the product instance.

In the context of RAMI 4.0, the generic life-cycle model of a product type starts with the development phase, in which the product type is developed and tested in the targeted system environment. The development phase includes activities, such as product type design, sales ramp-up, testing, or piloting, and ends with the delivery release of the product type, when the product is released for sale. The operational businesses of the product type finishes with the end of product sales, typically when the product is to be obsoleted. During the product sales (and typically for an extended period thereafter), the product type is under the maintenance phase, where configuration management and after-sales support activities take place. Configuration management comprises all activities related to the management of the different versions and revisions of the product type. Depending on the service level agreements, one or several versions of the product type will have independent after-sales support phases. The sum of these phases is called the product life-cycle, where the term cycle refers to the fact that there is a recurring sequence of the different phases in the context of a particular product type.

The product instance generic life time model starts with the production phase when the instancing of the product type begins. After the product instance is sold, the product instance enters the use phase, which starts with the product commissioning, installation, or activation, and ends with the decommissioning, de-installation or with an irreparable defect. Each product instance has a life time that comprises the production and use phases, i.e. starts with production and ends with the start of disassembling or disposal of the instance. The product life time is independent and can be significantly longer than the life-cycle of the product type.

3.1.3. Hierarchy Levels

The third axis of the RAMI 4.0 reference model is the hierarchical representation of the different functional levels of the factory, based on the IEC 62264 [33] and IEC 61512 standards. For a uniform consideration covering different manufacturing system architectures, the different functional levels that are included in the RAMI 4.0 hierarchy levels do not match, on a one-to-one basis, the hierarchical levels in the aforementioned standards. The relationship between the RAMI 4.0 hierarchy levels and the IEC standard organizational models is described below:

• Connected World: Describes the relationship between an asset or combination of assets and another asset or combination of assets at a different installation or company. This level is introduced in RAMI 4.0.
• Enterprise: Any business organization, initiative, venture, or undertaking with a defined mission. An enterprise is a collection of one or more sites. It is responsible for determining what products will be manufactured, at which sites and, in general, how they will be manufactured.
• Site: A site is a physical, geographical, or logical grouping determined by the enterprise. The main production capability usually identifies a site, and generally, they have well-defined manufacturing capabilities. Planning and scheduling normally involve sites. This level is not included in the RAMI 4.0 hierarchy level, but it is described here to better describe lower levels.
• Area: A physical, geographical, or logical grouping determined by the site. Areas generally have well-defined capabilities and capacities. Areas may contain one or more of the lower-level hierarchical level elements. As with sites, this level is omitted in the RAMI 4.0 hierarchical levels, but it is introduced to clarify the description of the levels below.
• Work Centres: Depending on the manufacturing system organizational model (discrete, batch, continuous), areas are organized in high level manufacturing elements (e.g., production line, storage zone, process cell). In RAMI 4.0, all of these higher-level elements are unified into the work centre concept to ensure a consistent application across different organizational models. Thus, work centres represent the highest level element that performs manufacturing functions and is regarded in production planning and scheduling. Work centres have well-defined manufacturing capabilities and throughput capacities. A work centre groups one or several work units. According to the standard, some examples are Bottling Line, or Assembly Line.
• Work Units or Station: Represent lower level elements that perform manufacturing functions and are regarded in production planning and scheduling. Some examples are work cells for discrete manufacturing processes, or process units for batch manufacturing processes. Work units have well-defined manufacturing capabilities and capacities and are composed of lower level equipment units that are not regarded in production planning and scheduling.
• Control Device: Represents the logical control of field devices.
• Field Device: Represents a device installed at the field level, which interacts physically with the manufacturing process and the products (e.g., a sensor).
• Product: Describes the product to be manufactured.

3.1.4. Administration Shell Specifications

The German Federal Ministry of Economic Affairs and Energy [34] provides specifications for the exchange of information with the administration shell. The Open Platform Communications Unified Architecture (OPC UA) is the core communication standard for I4.0 compliant communications. Both client/server and publish/subscribe communication patterns are supported, as highlighted in [34]. Figure 2 shows the I4.0 communication protocol stack.

The administration shell also defines the data models for the exchange of information between partners in the value chain. The specification defines the structure of the administration data models. The main components and standards used are:

• Concept: ISO 13584 [35] Industrial automation systems and integration standard is the basis for the conceptual definition of the asset and its parts.
• Design: AutomationML [36] (a standard-based mark-up language to exchange design data) and the corresponding mapping to OPC UA [37] is used to share product engineering data, particularly during the product type development phase.
• Production: OPC UA Information models are used to exchange production operations data during the product instance Production and Usage phases.
• Serialization: Both eXtensible Markup Language (XML) and JavaScript Object Notation (JSON) schemas are derived from the models described above.
• Mapping: Resource Description Framework (RDF) is used to map this information and enable the exchange of information using semantic technologies.

Regarding information access control, the specifications define an Attribute Based and Role Based Access (ABAC) model for access control to information. ABAC allows establishing different access policies for different user roles for the different elements of the information model of an administration shell.

Additionally, the specification defines a package file format, the Asset Administration Shell Package (AASX), to exchange the full or partial structure of the administration shell.

3.2. Smart Manufacturing Ecosystem

The Advanced Manufacturing Series (AMS) of standards by NIST provide different specifications for Smart Manufacturing Systems (SMS), and they are described below. In addition to the specifications in the AMS series, the National Institute of Standards and Technology [38] describes the standard landscape for SMSs. The document contains a detailed description of the characteristics and enabling technologies of SMS, and a comprehensive list of standards and standardization activities relevant for SMS, from three different perspectives (Figure 3):

• Product Lifecycle Management (Product): Includes six phases for the product development lifecycle (design, process planning, production engineering, manufacturing, use and service, end-of-life, and recycling). This perspective is equivalent to the RAMI 4.0 Life Cycle and Value stream dimension.
• Production System Lifecycle (Production): Defines five phases in the lifecycle of production equipment: design, build, commission, operation and maintenance, and decommission and recycling. This perspective is also equivalent to the RAMI 4.0 Life Cycle & Value Chain, from the point of view of the manufacturing equipment provider.
• Business Cycle for Supply Chain Management (Business): This perspective regards the plan-source-make-deliver-return phases of the Supply-Chain Operations Reference model (SCOR). This perspective can also be mapped to the Life Cycle and Value stream of the RAMI 4.0 model in collaborative use cases.

Alignment to RAMI 4.0

Regarding the AMS Series, Part 1–Reference Architecture for Smart Manufacturing [39] provides a modelling framework for specifying the architecture of both collaborative production systems and the software systems that supports them. The Reference Architecture for Smart Manufacturing Part 1 contains functional models to identify production activities–from product design to production–and descriptions of information flows between them. The different activities depict the life-cycle of products and can be aligned to the IEC 62890 product life-cycle model Instance Production phase described above. Distribution, maintenance and dispatching are out of the scope of the reference architecture, and product design is not expanded in the document, so the entire reference model can be regarded as a detailed description of the activities and data workflows within the instance production phase.

NIST Software Requirements Specification to Distribute Manufacturing Data [22] defines general functional and non-functional requirements for the distribution of manufacturing data across an enterprise. The document covers Volatile Data Streams (VDS) and Query-able Data Repository (QDR) applications for internal and external data access to manufacturing data. VDS applications are based on the MTConnect HTTP protocol [40], whereas QDR applications should use an HTTPS client-server REST-compliant communication and therefore, there are significant differences between AMS-2 and the I4.0 connectivity whitepaper.

NIST Guide to Industrial Wireless Systems Deployments [41] aims to provide a framework for integrated manufacturing design and analysis. The objective is to facilitate the integration and exchange of information between the product design and the product manufacturing phases, focusing on big data analytics and (deep) machine learning algorithms rooted in cloud services. The framework defines a four-layer model which can be mapped to the RAMI 4.0 layers. The framework consists of the following layers:

• Manufacturing System Layer: Represents the physical system and can be mapped to the RAMI 4.0 asset layer.
• Model Ecosystem Layer: This layer contains the modelling environment and runtime for the digital models of the manufacturing layer. It can be mapped to the RAMI 4.0 Integration layer, Communication layer and to some extent to the Information layer.
• Transformation Layer: This layer collects the digital model data and applies model-transformations processes to adapt the data for the cloud services. These functionalities are located in the information layer of the RAMI 4.0 model.
• Cloud Layer: This layer includes third-party Big Data analytics services, implementing the functional and business functions of the RAMI 4.0 model.

Finally, AMS 300-4 Guide to Industrial Wireless System Deployments [42] and AMS 300-6 Securing the Digital Threat for Smart Manufacturing [43] provide additional guidelines for the configuration of wireless networks and block chain-based product data traceability. Figure 4 shows the alignment between the RAMI 4.0 reference model and the Smart Manufacturing Ecosystem and AMS 300 specifications.

3.3. Smart Manufacturing Standardization Reference Model

The IMSA provides a three-dimensional system architecture reference model, which is very similar to the RAMI 4.0 model. It consists of three dimensions: lifecycle, system hierarchy, and Intelligent Functions. The lifecycle dimensions describe value creation stages, system hierarchy represents the organizational levels of manufacturing activities, and Intelligent Functions represent high-level functionalities provided by ICT technologies.

Alignment to RAMI 4.0

The German Federal Ministry of Economic Affairs and Energy [44] provides a description of the IMSA Reference model dimensions and element-to-element alignment to RAMI 4.0. The main conclusion from this document is the high level of alignment between both specifications: the three dimensions in both reference models are almost equivalent in scope, and the different elements in each dimension can be mapped almost one by one from one reference model to the other. Figure 5 summarizes the results of the mapping, using the same structure, symbols, and legends as Figure 4.

3.4. Industrial Internet Consortium Reference Model

In the case of IIRA, as shown in Figure 6, the following viewpoints are defined:

3.4.1. Business Viewpoint

This viewpoint identifies the different stakeholders of the digital manufacturing platform (manufacturers, and other prominent stakeholders, like manufacturing equipment providers, software developers, or service providers). More precisely, the definitions of the different elements of IIRA’s business viewpoint are:

• Stakeholders: Actors in each organization with a major stake in the business and a strong influence in its direction. Stakeholders are the main drivers of the conception and development of the system.
• Vision: Future (to-be) state of the organization.
• Values: Rationale, narrative description of why the vision has merit for the stakeholders, as well as for the users of the resulting system.
• Key Objectives: Quantifiable high-level business and technical outcomes of the system results in the context of delivering the values.
• Fundamental Capabilities: High-level specification of the ability of the system to complete specific business tasks, characterized by quantifiable attributes to measure the success of the system.

3.4.2. Usage Viewpoint

The usage viewpoint describes how the system realizes the fundamental capabilities identified in the business viewpoint, through their decomposition into tasks (units of work) and activities (how the system is used) between different system components. This viewpoint addresses the concerns of expected system usage, typically represented as sequences of activities involving human or logical users. The main elements of the usage viewpoint are:

• Task: Basic unit of work, such as the invocation of an operation, a transfer of data, or an action of a party, carried out by a party assuming a role.
• Functional Map: Map of the functions or functional components of the task.
• Implementation Map: Map of the implementation component the task relies on for its execution.
• Role: Set of capacities assumed by an entity to initiate, participate in the execution of, or consume the outcome of a task.
• Party: Agent (human or automated) that has interest and responsibility in the execution of a task. An agent executes a task assuming a role with the right capacities for the execution of the task.
• Activity: Specified coordination of tasks (and possibly other activities) required to use or operate the system, consisted of the following elements:

  -

  Trigger: Conditions that initiate an activity, optionally associated with a role responsible for initiating or enabling the execution.

  -

  Workflow: Organization of tasks (sequential, parallel, conditional, iterative).

  -

  Effect: Difference in the state of the system after the successful completion of an activity.

  -

  Constraints: Characteristics that must be preserved during the execution of the activity.

This way, the usage viewpoint captures the description of the technical details and the step by step analysis of the different use cases. In the definition of the workflow of the activities, the different components of the system and the exchange of information between them are identified.

3.4.3. Functional Viewpoint

The functional viewpoint decomposes a typical IIoT System into functional parts, to describe the system structure and interrelations, interfaces, and interactions between its functional components, as well as with external systems. Thus, the functional viewpoint establishes five functional domains (industrial control, operations, information, application, and business), five system characteristics (safety, security, resilience, reliability, privacy, and scalability), and four crosscutting functions (connectivity, distributed data management, industrial analytics, and intelligent and resilient control), described as:

• Functional Domains: Decomposition of the distinct functionalities of a distributed industrial control system into physical domains:

  -

  Control Domain: Functions performed by industrial control systems, mainly reading sensor data (sense) and control through actuators (actuation).

  -

  Operations Domain: Functions for management, monitoring and optimization of control domain functionalities (prognostics, optimization, monitoring and diagnostics, deployment, and management).

  -

  Information Domain: System modelling, data collection, persistence, transformation, and analysis.

  -

  Application Domain: Application of logic and rules to realize specific business functionalities, User Interfaces (UIs), and Application Programming Interfaces (APIs) to expose functionalities for humans and external applications.

  -

  Business Domain: Functions to enable end-to-end operations of the IIoT system, including those supporting business processes, also integrating with traditional specific functions. Examples include Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), or Manufacturing Execution System (MES).

• Crosscutting Functions: Functionalities that enable the Industrial Internet that need to be provided to enable the functional domains:

  -

  Connectivity: Functionalities enabling information sharing and collaborative manufacturing.

  -

  Distributed Data Management: Coordination of data management tasks across system components.

  -

  Industrial Analytics: Application of analytics on the data collected from industrial assets.

• System Characteristics: System properties emerging from the interactions between system parts:

  -

  Trustworthiness: Coordination and integration of different functions implemented in the different system components to guarantee overall system safety, security, resilience, reliability, and privacy.

  -

  Scalability: Functions to enable or facilitate the efficient deployment of large-scale instances of the system.

The functional viewpoint is also concerned with the distribution of functional domains across distributed computational resources in different deployment patterns. Considerations on the use of technologies, such as cloud computing, containerization, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Services (SaaS) to distribute the different functional domains, are also part of the functional viewpoint.

3.4.4. Implementation Viewpoint

The implementation viewpoint deals with the technologies needed to implement functional components, communication schemes, and procedures involved during their lifecycle. The implementation viewpoint defines three patterns for a coherent IIoT System implementation: three-tier architecture pattern, gateway-mediated edge connectivity and management architecture pattern, and the layered databus pattern.

The three-tier architecture pattern divides the system into three tiers (edge, platform, and enterprise) and three networks (proximity, access, and service). The edge tier collects data from sensors, actuators, devices, control systems, or any asset in the proximity of the physical system, which are collectively called the edge nodes. For this purpose, the edge tier uses the proximity network. The access network enables connectivity between the edge tier and the platform tier. The platform tier consolidates operation processes, performs data analytics, and transformation functions with respect to data flows.

It also offers management functions on edge nodes and dispatches control messages from the enterprise tier to the edge tier. The service network enables connectivity between the services in the platform tier, as well as between platform and enterprise tiers. The enterprise tier implements domain-specific applications, decision support systems, and provides user interfaces to end-users. It implements the rules and control logic of the system, and issues control commands to the platform and edge tiers.

The gateway-mediated edge connectivity and management pattern and the layered databus pattern are more specific instances or variations of the three-tier architectural patterns that deal with connectivity solutions to interconnect the different tiers in specific network topologies, supported by the connectivity framework [45].

3.4.5. Alignment to RAMI 4.0

The Industrial Internet Consortium [46] presents an alignment of IIRA and RAMI 4.0 reference models. As shown in Figure 7, the IIRA Usage and implementation Viewpoints are complementary to RAMI 4.0, since there is no counterpart element in the RAMI 4.0 reference model. The IIRA business viewpoint is complementary to the RAMI 4.0 Lifecycle dimension since it contains additional definitions useful to better describe the concerns of the different actors and organizations involved in the product life cycle from a business point of view.

The layer dimension is similar to the functional domains of the Functional Viewpoint, but RAMI 4.0 is more specific to manufacturing and, therefore, better suited to applications for the manufacturing sector. The cross-cutting functions and system characteristics of IIRA are, in that sense, complementary to the layer dimension. Connectivity is the only divergence found between both reference models, although there are some similarities between the protocol stacks defined in the IIC connectivity framework for the manufacturing domain and the I4.0 connectivity whitepaper of Platform Industry 4.0.

4. Industrial Internet Integrated Reference Model

Based on the alignment above, it is possible to represent the different elements of the reference models together and assess to what extent they are relevant for the specific use cases of a digital manufacturing platform.

Table 1. Reference Model Benchmarking.

	Products			Projects
FEATURES	Siemens MindSphere	PTC ThingWorx	GE Predix	ZDMP	vf-OS	CREMA
BUSINESS
Stakeholders	✓	✓	✓	✓	✓	✓
Vision	✓	✓	✓	✓	✓	✓
Values	✓	✓	✓	✓	✓	✓
Key Objectives (ISO 22400)	✓	✓	✓	✓	✓	(✓)
Fundamental capabilities	✓	✓	✓	✓	✓	✓
USAGE
NIST PERSPECTIVES
Business	✓	(✓)	(✓)	(✓)	✓	✓
Product	✓	✓	✓	✓	✓	✓
Production	✓	(✓)	(✓)	✓	✓	(✓)
IIRA USE CASE DESCRIPTIONS
RAMI 4.0 dimensions
Layers
Business	✓	✓	✓	✓	✓	✓
Functional	✓	✓	✓	✓	✓	✓
Information	✓	✓	✓	✓	✓	✓
Communication	✓	✓	✓	✓	✓	✓
Integration	✓	✓	✓	✓	✓	✓
Asset	✓	✓	✓	✓	✓	✓
Life Cycle & Value stream (IEC 6289)
Type (Development)	✓	(✓)	(✓)	(✓)	✓	(✓)
Type (Maintenance/Usage)	✓	(✓)	(✓)	✓	✓	(✓)
Instance (Production)	✓	✓	✓	✓	✓	✓
Instance (Maintenance/Usage)	✓	✓	✓	✓	✓	(✓)
Hierarchy Levels (IEC 62264)
Product	✓	✓	✓	✓	🗶	🗶
Field Device	✓	✓	✓	✓	(✓)	🗶
Control Device	✓	✓	✓	✓	(✓)	🗶
Station	✓	✓	✓	✓	(✓)	🗶
Work Centers	✓	✓	✓	✓	✓	🗶
Enterprise	✓	✓	✓	✓	✓	(✓)
Connected World	✓	✓	✓	✓	✓	✓
AMS 300-5 layers
Cloud	✓	✓	✓	✓	✓	✓
Transformation	✓	✓	✓	✓	✓	✓
Model Ecosystem	✓	✓	✓	✓	✓	✓
Manufacturing System	✓	✓	✓	✓	✓	✓
IMSA
Layers
New Business Patterns	✓	✓	✓	✓	✓	✓
Information Fusion	✓	✓	✓	✓	✓	✓
Interconnection	✓	✓	✓	✓	✓	✓
System integration	✓	✓	✓	✓	✓	✓
Resource Elements	✓	✓	✓	✓	✓	✓
LifeCycle
Design	✓	(✓)	(✓)	(✓)	✓	(✓)
Manufacture & Logistics	✓	✓	✓	✓	✓	✓
Market	(✓)	(✓)	(✓)	(✓)	(✓)	(✓)
Service	✓	✓	✓	✓	✓	(✓)
Intelligent Functions
Product	✓	✓	✓	✓	🗶	🗶
Equipment	✓	✓	✓	✓	(✓)	🗶
Control	✓	✓	✓	✓	(✓)	🗶
Factory	✓	✓	✓	✓	✓	🗶
Enterprise	✓	✓	✓	✓	✓	(✓)
Cooperation	✓	✓	✓	✓	✓	✓
FUNCTIONAL
I4.0 Components	🗶	🗶	🗶	✓	✓	(✓)
Deployment functions	✓	✓	✓	✓	✓	✓
Cross-cutting functions	✓	✓	✓	✓	✓	✓
IMPLEMENTATION
Three tier architecture pattern	(✓)	(✓)	(✓)	(✓)	(✓)	(✓)
Four tier architecture pattern	✓	✓	✓	✓	✓	✓
Connectivity	✓	✓	✓	✓	✓	✓
Cybersecurity	✓	✓	✓	✓	✓	✓
Deployment	✓	✓	✓	✓	✓	✓

highlights the relevance of the definitions in the different reference models for both commercial Industrial IoT platforms and related research projects (✓—relevant, (✓)—relevant to some extent, 🗶—out of scope). Other commercial platforms and projects have been considered in the analysis, but only six relevant ones are included in the table below for the sake of presentation. The benchmarking clearly shows that in most cases, definitions of different reference models are relevant (at least to some extent) and, therefore, it is convenient to use an integrated reference model which, based on the synergies and complementarities found in the alignment, provides a systematic approach to reinforce them.

This section presents a reference model for digital manufacturing platforms use cases: the Industrial Internet Integrated Reference Model (I3RM), which integrates features of IIRA, NIST, and RAMI 4.0 reference models and architectural patterns, to facilitate the definition of the system architecture of digital manufacturing platforms. Each of the analyzed reference models is suitable depending on the purpose for which it is used. The I3RM is a broader proposal as it integrates all the views of the current models and new ones that are necessary for current detected needs of digital manufacturing platforms. These requirements have been recognized in the ZDMP project, whose main objective is to develop the zero defects reference platform to offer companies all the necessary apps to meet their manufacturing technology needs, digitize the factory, and evolve to manufacturing excellence for a competitive advantage. After the reference models alignment, it is evinced that the studied ones do not provide enough reference information for the ZDMP platform.

Basically, the proposal is to use IIRA’s viewpoints (business, usage, functional, and implementation) as a framework to define the system architecture using a top-bottom approach. Features of NIST and RAMI 4.0 are introduced in the different viewpoints, as depicted in Figure 8. At the implementation viewpoint, the proposed architectural pattern extends the IIoT architectural pattern proposed by IIRA. The following sections describe in detail the extended integrated model.

4.1. Business Viewpoint

The business viewpoint allows for identifying the business concerns of the different users of the system, in a quantitative way, through Key Performance Indicators (KPIs), such as business value, expected return of investments, or maintenance costs. The business viewpoint conforms a value driven model that identifies the main stakeholders and their business vision, values, and objectives in the establishment of the system, taking into account business and regulatory aspects.

It is clear that the definitions of IIRA’s business viewpoint are generic enough to define digital manufacturing platforms from a business perspective since manufacturing is only one of many different use cases for IIRA. To make it more specific, one recommendation is to use standard definitions of KPIs for manufacturing operations, as specified in ISO 22400 [47]. This standard specifies KPIs used in manufacturing operations management. The definition of KPIs with this standard facilitates the evaluation and validation of use cases in different manufacturing scenarios.

The output of the business viewpoint is a business definition of the use case describing the main stakeholders, their vision and values, standard key objectives, and fundamental capabilities.

4.2. Usage Viewpoint

The recommendation is to use IIRAs usage viewpoint use case description definitions to identify the different parties, actors, and workflows involved in the different use cases, then use NIST perspectives to represent the different use cases in the RAMI 4.0 dimensions.

In collaborative use cases, RAMI 4.0 dimensions are useful to identify the interfaces that are needed between systems to implement the different data workflows. However, the same use case may be mapped to the RAMI 4.0 dimensions in different ways, depending on the perspective of the user. For instance, imagine a use case where a provider of manufacturing equipment wants to collaborate with customers to implement predictive maintenance using condition monitoring. Considering the RAMI 4.0 hierarchy level dimension, the use case can be mapped to the product level from the perspective of the machine provider and to the station level from the perspective of the machine user. One approach is to map the use case to the RAMI 4.0 model for every stakeholder, or for every user, but this approach does not scale well in complex supply networks. On the other hand, NIST perspectives (production, product, business) allow the mapping of use cases to different dimensions in a comprehensive manner with a limited number of perspectives.

The output of the usage viewpoint is a definition of the different parties, roles, and activities (tasks and workflows) in the system and the corresponding mapping between tasks and functional and implementation components. In combination with NIST perspectives and RAMI 4.0 dimensions, these components are, in turn, mapped to the corresponding RAMI 4.0 layers, product lifecycle phases, and hierarchy levels.

4.3. Functional Viewpoint

Concerning the definition of the functional components of a digital manufacturing platform, once the usage viewpoint is completed, the different components and workflows are identified and mapped to the RAMI 4.0 hierarchical level dimensions representing the different organizational levels, the functional viewpoint has enough context information to define the deployment functions and other cross-cutting functions (connectivity, analytics, trustworthiness, and data management) needed in the system. Concerning connectivity, since IIR’s functional domains overlap with the RAMI 4.0 hierarchical levels, authors recommend using the latter because there is a direct relationship between the RAMI 4.0 hierarchical levels and the different functional levels in a secure industrial network, as defined in cyber-security standards like the International Electrotechnical Commission [48], and, therefore, the mapping to RAMI 4.0 ensures that connections between components use secure conduits between levels in a consistent manner. Figure 9 provides an example of how to represent information flows between different parties in the RAMI 4.0 hierarchical level dimension.

In the example, there are two different kinds of parties, humans and assets. Humans are represented together with their corresponding user roles (named App_1_n, n = 1, 2, 3 in the figure). Each asset (or group of assets) is associated to an Asset Administration Shell (AAS), which comprises the digital representation of the asset to conform an I4.0 component (A1, A2, and A3 in the figure).

Regarding data management, it is also recommended to use RAMI 4.0 administration shell meta-models to capture the information that needs to be exchanged between manufacturing assets. It is recommended to use Unified Modelling Language (UML) class diagrams to represent the data elements that need to be exchanged between the different assets and the description of the service interfaces that should be used.

It is also recommended to use UML class models and UML sequence diagrams to define the formats and structure of the information messages between the different assets. This way, the functional viewpoint will collect all the requirements to interconnect the different manufacturing assets involved in the use case.

The output of the functional viewpoint is a complete functional specification describing the interfaces between the different components and between components and assets, including data model definitions and data management and security requirements and mapping of tasks to functional components and implementation components.

4.4. Implementation Viewpoint

The implementation viewpoint should provide details on how the AAS will be deployed to the computing infrastructure. The Platform Industrie 4.0 [49] describes different deployment patterns that can be used in a consistent IIoT System from different views: physical proximity, distribution, virtualization, and lifecycle:

• Proximity: Physical proximity of the asset to the AAS.
• Asset-Based: AAS hosted in asset’s runtime environment.
• Edge/Fog Based: AAS hosted in a computing environment in the local IT infrastructure of the enterprise.
• Cloud Based: AAS hosted in cloud infrastructure.
• Distribution: Distribution of AAS data elements and services across different runtime environments.
• Centralized AAS: A 1 to 1 relationship between asset and AAS and unique entry point (e.g., URL) for the AAS.
• Distributed AAS with Loose Coupling: Information for an asset under the same AAS and multiple entry points for the AAS, distributed based on the different organizations that need access to the different data elements.
• Distributed AAS with Aggregating Node: An aggregating AAS provides a single access point to access all the information of the asset, collecting information from other lower level AAS distributed among collaborators.
• Virtualization: Virtualization of the runtime environment of the asset.
• Operating System: No virtualization.
• Hypervisor Deployment: Runtime environment in virtual machines managed by a hypervisor.
• Container: Container-based runtime environment (e.g., Docker).

The implementation viewpoint needs to take into consideration the different trade-offs among these deployment patterns, also considering the IIRAs architectural patterns for a consistent IIoT system and the specific requirements of the use case. It is also important that the implementation is described in a format that effectively captures the selected deployment patterns. In this sense, one recommendation is to use a multi-layered approach to describe the implementation and selected patterns for the different system components, such as the C4 model [50]. The C4 model comprises four different levels of abstractions to visually communicate the system architecture: context, containers, components, and code.

The first level of abstraction, context, shows a high-level description of the system being described, focusing on the user, user roles, and interactions with the systems. As indicated above, it is recommended to use the three-tier architectural pattern as a reference, but also to take into account the functional viewpoints to better describe the proximity network and the interactions between different hierarchical levels. In this sense, it is important to highlight that the three-tier-architecture pattern in IIRA (edge tier, platform tier, enterprise tier) might be insufficient to determine the system boundaries between different stakeholders in collaborative scenarios. In this sense, the RAMI 4.0 hierarchical level dimension is very convenient due to the differentiation between the Enterprise and Connected World levels. The three-tier architecture pattern is, on the other hand, very convenient for describing a consistent IIoT system architecture and deployment pattern. For this reason, the three-tier architecture pattern is extended with a four tier, collaboration tier, to highlight the boundaries between the different private (cloud) systems in a collaboration network.

Figure 10 illustrates the mapping of a digital manufacturing platform, the Zero Defect Manufacturing Platform (ZDMP), to the proposed four tier architecture pattern. The ZDMP platform provides a marketplace and Software Development Kit (SDK) to develop applications to realize the zero-defects manufacturing paradigm in manufacturing companies [51]. The ecosystem is supported with a portal and engagement hub to promote the collaboration between stakeholders (mainly software developers and manufacturing companies). This is an example of a digital manufacturing platform with collaboration features that cannot be mapped into IIRA’s three-tier architectural pattern. The figure shows how the high-level building blocks of ZDMP are mapped to the four tier architecture pattern. The new collaboration tier is convenient for providing an abstracted view of the system that is common to many collaborative use cases, but with a margin for variations to capture specificities.

The container abstraction level further decomposes the system into separately runnable/deployable units. This level of abstraction will capture the different deployment patterns that have been selected for both the AAS as well as for the decomposition of the digital manufacturing platform building blocks into components. At this level of abstraction, it is possible to identify the different data and control flows between containers and, therefore, the requirements and interdependencies between physical and virtual connections at the container boundaries. This effectively provides means for the dynamic and decentralized mapping of smart objects onto micro-services.

The component abstraction level identifies the major structural building blocks of each container, that is, the inner structure and main components within each container. This level is a refinement of the functionality, describing to greater detail how the different functionalities are implemented. Finally, the optional code abstraction level provides additional UML class diagrams and meta-models to describe the inner code and data structures of each component.

5. Conclusions

This paper presents an analysis of different cutting edge reference models and architectural reference models for digital manufacturing platforms. They provide, in many cases, complementary views on digital manufacturing platforms, and, in general, it is rather straightforward to align the definitions they contain.

The RAMI 4.0 reference model contains the specifications of the administration shell, which can be regarded as a standardized digital representation of a manufacturing asset providing interfaces to interact with it. The analysis showed that the level of maturity of RAMI 4.0 is the most advanced among the different reference models under analysis. Besides this, there are several alignment reports available between the RAMI 4.0 and other reference models, which make it easier to extrapolate any mapping to RAMI 4.0 to the other reference models. Therefore, RAMI 4.0 has been selected as the reference model for analysis, and the different alignment reports have been used to complete the analysis.

It is important to note that the alignment between the RAMI 4.0 and the Smart Manufacturing Ecosystem from NIST has been specifically developed as part of this research work. The main divergence between the different reference models is found in the standardized protocol stacks and data formats to exchange data. This is an important aspect which has to be taken into consideration in the design of any digital manufacturing platform, concerning inter-platform communication and IIoT data acquisition. In this sense, it is recommended that system components, mainly IIoT data acquisition and data transformation, incorporate technologies to deal with high levels of diversity in edge communications networks.

Based on this alignment, and in order to give response to the need of a more complete and integrated reference model for the design and implementation of the ZDMP Platform, the paper presents the Industrial Internet Integrated Reference Model (I3RM) and non-binding recommendations to align the global architecture definition, functional specifications, and technical specifications of digital manufacturing platform use cases to the guidelines and examples promoted by the different reference models under analysis. The recommendations provide a standard framework to structure the technical information generated in the use case, to support the design, implementation and validation of the system. Following these recommendations, interoperability will be guaranteed with state-of-the-art digital manufacturing standards and solutions.

The paper also presents an extension of the three-tier architecture pattern. The different functional blocks of a digital manufacturing platform have been mapped to the RAMI 4.0 reference model to find out to what extent they are covered in this reference model. The main conclusion is that aspects regarding software development, application marketplaces, collaboration between developers, and collaboration between developers and users, are innovative aspects and it is necessary to extend the three-tier system architecture to better understand the requirements they imply. The three-tier global architectural pattern of IIRA has been extended with a new tier, named collaboration, to address this aspect. It is worth mentioning that this study involves some limitations. One limitation is related to the analysis coverage as the reference models alignment study only involves the cutting edge reference models for IIoT systems. However, there are other reference models such as IBM Industry 4.0 Reference Architecture that have not been included in the analysis. Further research could be focused on the alignment analysis of other reference models. Another limitation is related to the constraint of the analysis according to the specific dimensions of the studied reference models. Future research lines could be addressed to define a meta-reference model to map the reference model together with additional dimensions, such as social and sustainability. Finally, future research could be addressed to validate the benchmarking performed with a set of experts using a survey or Delphi study to assess the appropriateness of the current version of the benchmarking results.