Overview of Industrial Internet of Things Architectures

Abstract—Remote monitoring, intelligent analysis, and control of industrial processes have led to the emergence of the Industrial Internet of Things (IIoT) and sparked the Fourth Industrial Revolution. The industrial world in the early stages of adopting IIoT technology and implementing its solutions will face challenges. Therefore, there is a need to address the challenges that arise in this area. Hence, based on various architectural layers and emerging technologies for integrating end-to-end IIoT, researchers have proposed detailed accepted architectures for IIoT. In this article, we will examine three reference architectures for IIoT end systems and provide comparisons between them.

Index Terms— Internet of Things, Industrial Internet of Things, Fourth Industrial Revolution, Reference Architecture Model.

I.    INTRODUCTION

T

 he Internet of Things (IoT) has brought about a revolution in the current century by providing connectivity between billions of devices and enabling access to them from anywhere and at any time. The initial concept of the internet was introduced in 1999 by Kevin Ashton, envisioning it as a connection between people and things and between physical and virtual objects to exchange information for coordinated tasks. In comparison, the Industrial Internet of Things (IIoT) brings further evolution in the production process by merging Information Technology (IT) and operational technology, aiding industries to enhance their operational efficiency. Moreover, the new era of the Fourth Industrial Revolution (Industry 4.0) and IIoT brings about new developments with the integration of cyber-physical systems to foster collaboration among smart devices. Industry 4.0 is utilized across various sectors for self-optimization, improving decision-making through advanced sensors, enhancing production quality, and proactive maintenance to reduce downtime and system failures. Additionally, networking capabilities combine sensing and computing with Cyber-Physical Systems (CPS) to facilitate learning and adaptation, thus easing the integration of CPS and IoT, and IIoT. The integration of Industry 4.0 components marks its peak in the current industrial revolution. The digitization of industrial processes necessitates new technological advancements to address the significant challenges posed by IIoT for end-to-end integration. Various reference architectures such as IIRA and RAMI 4.0 have been proposed for the development of end-to-end systems, including OpenFog RA, encompassing architectural layers from sensors to organizational management features, providing a roadmap for development. Found in various research resources, IIoT architectures address specific challenges in particular industrial or general industrial application cases, while reference architectures provide a general framework for development processes without imposing fixed protocols and standards. essential.

In this article, in the first section, we provide a detailed review of architectures and their specifics. In the subsequent section of the article, we delve into examining the reference architectures of IIoT, including OpenFog and RAMI 4.0, IIRA. Section 3 presents a comparison between the mentioned reference architectures. Section 4 discusses the conclusions drawn and the challenges highlighted. Since one of the widely discussed concepts in the Fourth Industrial Revolution is Industrial Internet of Things (IIoT), we will continue with a review of it.

II.    IIoT Reference Architectures

A reference architecture provides a common framework for developing, decomposing, and analyzing systems in a way that addresses the independent functional requirements of IIoT. Reference architectures are derived from specific technologies and standards. These architectures serve as structural guidelines for various components of a system, including standardized network models for interacting with devices and sensors. Additionally, architectural services provide support for monitoring and managing remote assets and information relevant to software systems supported by the architecture. Experts from various organizations have proposed reference architectures to provide the necessary structure for transforming production processes in industries and enabling IIoT based on existing technologies. Three of the main reference architecture models, including OpenFog RA, RAMI 4.0, and IIRA, are elaborated upon further.

A.    The Reference Architecture Model for the Fourth Industrial (RAMI 4.0)

This reference architecture model has been developed to update the production process and industrial automation in Germany. In Industry 3.0, products are separate from each other, functions are hardware-specific, and system components interact hierarchically. According to RAMI 4.0, product information is part of the network, functions are distributed within the network structure of Industry 4.0, and different partners can communicate with each other without regard to system hierarchy. Figure 1 illustrates how RAMI 4.0 distinguishes itself from Industry 3.0. International standards in electronics, electrical, mechanical, and information technology participate in technology presentation across fields in RAMI 4.0. This architecture is based on service-oriented architecture to provide services between system components through network protocols and to transform complex tasks into simple processes based on technologies and independent products. Figure 2 depicts the three-level model that facilitates interaction among all industrial partners and provides mutual understanding for the next level of RAMI 4.0 RA, enabling them to implement Industry 4.0 in a structured manner.

Fig. 1 – Comparison of the Third and Fourth Industrial Revolutions [2]

Fig. 2 – RAMI 4.0 Architecture Model [3]

1)    Hierarchy Levels

Hierarchy levels on the horizontal axis of the model based on Information Technology standards and IEC 61512 IEC 62264 International control systems. Terms such as stations, workplaces, organizations, and connected worlds on this axis extracted from these standards are used to create a common ground in current areas of factory automation and process industries. There are seven levels as follows:

Product: The final product produced in the industry.

 

Field Device: Hardware devices such as sensors and actuators that collect environmental data.

 

Control Device: Control devices such as programmable logic controllers (PLCs) and distributed control units that read sensor values and send control commands to the system.

 

Station: A place where the system operator monitors industrial activity with access to the system manager and responds to processes and events, such as a SCADA system.

 

Workplace: Data storage, information, and analysis based on historical data are performed in these centers, known as Manufacturing Execution Systems (MES). The MES system assists in executing, monitoring, and tracking all production processes.

 

Organization: This level is used for business organization and profit-making decisions. The system manages all information for resource management, such as production scheduling versus ERP resource planning, cost versus income, and production resource management.

 

Connected World: The system is connected to the Internet to communicate with external industries through the supply chain process.

2)    Value Stream and Lifecycle

The standards for the product lifecycle process used in industrial automation, control, and measurement systems are placed on the horizontal axis of the model. This process illustrates information related to the components of production from the design stage to the final product in RAMI 4.0. The “Prototype” field corresponds to the design and initial production stage, while the “Sample” field relates to the time when the product is produced in its final form.

3)    Architecture Model Layers of RAMI 4.0

In the RAMI 4.0 architecture model, the vertical layers recognized as Collaboration Layers 16 encompass all industrial processes (from physical devices and assets to integration between human, technology, and protocols), along with the functional properties of system components and business processes. RAMI researchers have explained the following architectural layers for the 4.0 model:

Asset: This bottom layer is the foundational layer encompassing all physical components, including devices and peripherals.

Integration: This layer provides information generated by assets to higher layers, offering formatting and control capabilities for assets. It provides RFID, HMI-like IT capabilities for the functional layer and includes elements and actuators.

Communication: This layer is responsible for maintaining communication between networks using standards and protocols and facilitating interaction between the asset and integration layers with higher layers.

Information: This layer preprocesses information for various events, ensuring the accuracy and quality of data received from lower layers, and then presents structured data to the functional and business layers.

Functional: This layer receives data from the asset layer and executes decisions based on data analysis.

Business: This layer includes organizational business models and legal frameworks along with real-time monitoring services using dashboards and user interaction applications.

B.    Industrial Internet Reference Architecture

The International Industrial Consortium (IIC) provides a reference architecture model to support applications and the IIRA framework. It offers various IoT standards for solution development, adapted according to ISO/IEEE/IEC 42010 standards. It can respond to changes in industrial control systems in the following ways:

Local Autonomy Enhancement: It includes providing improved new technologies, computational power, and enhanced sensors to increase data accuracy and aid in the creation of autonomous systems.

System Optimization Improvement: It involves data analysis using machine learning on collected sensor data to provide insights into the implemented system and enhance control systems and optimizations.

The architecture consists of three layers: Edge Layer, Platform Layer, and IIRA Organization Layer. Gateways, devices, sensors, control systems, and various assets are connected via wired and wireless connections to form a proximity network. The Edge Gateway manages and aggregates devices, then sends the relevant data to the Platform Layer through the access network. The Platform Layer performs data transformation, operations, and data analytics, then sends information to the Organization Layer through the service network. In the Organization Layer, users oversee and control domain applications and send control commands to the Platform Layer using control flow processes. The Platform Layer then sends this information back to the Edge Layer to perform the relevant tasks. The provided architecture is illustrated in Figure 3. The IIC indicates the three layers facilitated by IIoT.

Fig. 3- Three-layer IIoT System Architecture Model-IIRA [5]

1)    Functional Domains and Perspectives

This includes two important functional aspects: the functional perspective and the IIRA functional domains within its architecture. The functional perspective provides an overall view of the observations of system components and their structure. The functional domain consists of five distinct domains that constitute the system architecture. Figure 4 illustrates the information. IIRA processes between functional domains are represented by green arrowheads indicating data/information flow, gray/white arrowheads indicate decision flow, and red arrowheads indicate command/request flow.

Fig. 4- Reference Model Domains IIRA [5]

2)    Functional Domains

Control Domain: It includes functions to enable control systems in industries. This domain encompasses sensor and actuator functions that read data from sensors and send control signals to actuators. Additionally, it includes communication functions that facilitate data exchange between system components and technologies using various protocols. The control domain interprets behaviors and system conditions through data modeling on APIs.

Operations Domain: It performs management and operational tasks for the control domain. Additionally, it provides functions for provisioning and deployment to access assets on a large scale and allows for adding, modifying, or deleting assets without regard to the industrial environment.

Information Domain: This functional domain processes and collects data from system components and analyzes data to obtain information about system parameters and system optimization through decision-making stages.

Program Domain: The program domain includes functions to develop logic and rules for optimization at a high level. Also, it includes capabilities to make data related to human interactions UI and API or various applications available for processing.

Business Domain: It includes various functions to support business activities and processes and integrates them within ERP systems. Examples include IIoT business function modules, invoices, ERP, MES and more.

C.    OpenFog Reference Architecture

This architecture assists researchers, developers, designers, and industries in providing the necessary components for Edge Computing. It offers an architecture model based on Fog Computing to address OpenFog and Industrial SaaS, PaaS provisioning through compatibility with various industries, including OpenFog RA. It provides IaaS for smart vehicles, traffic control systems, smart cities, smart buildings, and more. Its goal is to provide security, cognition, agility, low latency, and efficiency. In addition to being based on the eight key pillars of the OpenFog RA, it highlights the general features of the system model for seamless provisioning. The presented viewpoints in this reference architecture are emphasized, while the structural aspects of the layer architectures are shown in the views. The view section contains three perspectives on the reference architecture: Software View, OpenFog RA System View, and Node View. Figure 5 illustrates the model. The bright green vertical layers represent the reference architecture perspective, the bright yellow and bright blue layers indicate node views and software architecture, respectively, and the bright red layers represent the system architecture view.

1)    The pillars of fog computing architecture

The pillars of fog computing architecture are based on the eight foundational pillars of the OpenFog RA architecture. These pillars represent the essential characteristics of systems implemented with fog computing technology and structured architecture. Not limited to OpenFog standards: Security architecture is not limited to specific security mechanisms but encompasses all security mechanisms from hardware to software-based application levels. OpenFog RA privacy and security features include data privacy, anonymity, validation, tracking, trust, and user and device authentication. Provides end-to-end security model. Additionally, OpenFog RA establishes network links between nodes after information verification, followed by authentication processes. Scalability: This model provides features that meet the scalability needs of users for cloud nodes, storage services, and networks based on various OpenFog RA capabilities. Scalability includes the following:

– Scalable Performance: Improve system performance based on application needs by reducing latency in the system.

– Scalable Capacity: Helps increase network, system, application, and user capacity.

– Scalable Reliability: This reliability feature ensures data or processing integrity in case of network errors or high data or processing loads.

– Scalable Security: Includes additional software and hardware security features such as providing access and processing encrypted data when strict security is enforced.

– Scalable Software: Provides additional software components as needed between network nodes and internal system components, such as data storage operations, increasing the scalability of wired and wireless networks, and scaling up computational processes.

Flexibility: This column supports a diverse environment that allows fog nodes and network devices to interact regardless of vendor lock-in effects, mitigating negative impacts on quality and cost and enabling interaction between components regardless of location.

Autonomy: Autonomy structure prevents centralized processing by providing decision-making facilities to node controllers, preventing centralized processing and bringing efficiency in performance, security, and cost. This capability helps nodes to remain active in case of problems by activating the network detection option.

Programmability: Node and system programming implemented in hardware and software layers are provided with the ability to change node functions provided by fog nodes. Optimized security programming provides automatic security patching, along with adaptable infrastructure and multiple tenants.

Trust, Availability, and Serviceability: While trust ensures that cloud nodes and system components operate autonomously under given conditions, availability refers to continuous management and support, including addon access and secure device and addon configuration. Serviceability provides automatic installation, updates, and maintenance of fog nodes, along with support for replaceable hardware components. Agility: This pillar is responsible for managing system changes and providing analytical insights from extensive sensor data to make efficient business decisions.

OpenFog hierarchy: As not all systems are hierarchical, these columns complement RA and traditional hierarchical information for company systems.

Fig. 5- OpenFog Reference Architecture [6]

2)    Perspectives

The perspectives depicted in the vertical green pillars in Figure 5 are as follows:

Performance and Scalability: The performance of systems implemented under fog computing architecture is continuously monitored for quality of service (QoS) and minimal latency. Monitoring node throughput and latency determines the performance of fog computing, which improves by bringing computing closer to the edge. New virtualization and containerization technologies in fog computing improve scalability and node isolation. These technologies can also manage network traffic and resource allocation based on priorities.

Security: Until there is trust between system components, the architecture is not secure. Cloud node hardware is secure with appropriate security measures, ensuring complete data integrity and authenticity from hardware to software levels through encryption and authentication mechanisms. The security perspective also includes threat detection and privacy preservation features.

Management Capability: The management capability perspective provides human-like responsiveness and decision-making using machine learning algorithms. It offers efficient management functions for a wide range of operations compared to traditional IT and operational technology systems. Additionally, it covers all management functions, including alerting systems, operational functions, device and node discovery, and more.

Data, Analytics, and Control: With the increasing generation of data in industries for decision-making analytics, traditional analytic approaches are inadequate for rapidly growing needs. Moreover, with companies moving towards preventative maintenance by monitoring system parameters, meeting stringent requirements seems challenging. Fog computing enables the analysis of data at the edge near the source for specific analytics and sends relevant information to cloud services for business functions and related processing, facilitating the achievement of these goals.

IT Perspective: This perspective emphasizes the need for fog applications to function at every level of the hierarchy and share data with other nodes to optimize value delivery across multiple domains. It brings a business-oriented IT perspective to facilitate seamless interaction and maximize business value in multi-domain environments.

3)    Node Views

The Node View in OpenFog represents the lowest level perspectives used in the architecture. The light-yellow layers in Figure 5 depict the aspects of the node view in the RA architecture. These aspects should be considered before adding a node to the fog computing network.

Node Security: Node security indicates the security requirements both horizontally and vertically, as the system’s security is crucial from the silicon level to the software level. It ensures complete data integrity and confidentiality from hardware to software layers, with encryption and authentication mechanisms.

Node Management: This aspect supports system management processes by enabling management tasks from nodes. These tasks include monitoring and controlling low-level nodes by high-level management systems.

Networking: The networking component allows nodes to communicate with each other based on time-sensitive and time-aware networks and share information across the network.

Accelerators: The accelerators used in fog computing applications improve power and latency in communications depending on the network scenario.

Computations: Cloud nodes execute open-source software at their level for basic computations and interactions with other nodes and system components.

Storage: Although there is a need for data storage before learning or analysis, a reliable storage device is required to ensure data integrity and device health conditions.

Sensors, Actuators, and Controls: These elements are the most fundamental. While some IoT devices at the system level have processing capabilities, others are incapable of processing data. These elements connect to the system either wirelessly or via wired connections.

Protocol Abstraction Layer: This layer is responsible for sensor and actuator communication with the fog node for data analysis. It also ensures interoperability between products from different vendors to optimize data exchange between mutual layers.

4)    System Architecture View

The system architecture view includes several node views for scalable fog implementations. This perspective addresses technical issues for engineers, developers, and system architects. The vertical layer of functionality and scalability, along with some horizontal layers marked with a red border in Figure 5, define the system architecture view. OpenFog RA introduces the following components:

Software Platform Infrastructure: This perspective requires platform elements to ensure personnel and software security against any threat, system protection against the environment, and mechanical support for hardware infrastructure. The implemented system must also comply with compatibility standards and configurations.

Hardware Virtualization and Containers: Hardware virtualization allows sharing multiple entities on a physical device and ensures system security by restricting specific system parts from virtual machines. The use of containers reduces additional costs and provides lightweight mechanisms in the fog computing environment.

5)    Software Architecture View

This perspective encompasses the software architecture view executed on a platform. The platform is formed by combining node perspectives for processing specific scenarios. The software of cloud nodes is separated into three layers, illustrated in bright blue in Figure 5.

Application Services: This layer provides services with the assistance of other layers to be utilized and meet specific needs.

Application Support: This part of the software infrastructure does not perform any new services but supports other applications in executing specific tasks.

Node Management and Software Support: This layer manages node operations and facilitates communication between nodes.

III.    Comparison of Reference Architectural Models

Different organizations have presented various reference architectures for the development and implementation of industrial IoT. While RAMI 4.0 focuses more on the industrial process from production to company level, IIRA is about the industrial process with interconnection between deployed systems. Platform Industrie and IIC are currently collaborating to provide a common reference architecture by combining RAMI 4.0 and IIRA. While RAMI 4.0 establishes hardware-software communication through a gateway, IIRA provides Edge layer for computing and storing data. OpenFog RA is about handling high-volume data generation and processing in industrial applications. The OpenFog reference architecture is designed for vertical integration in industry implementation. Choosing a specific reference architecture depends on the needs of the implemented system.

IV.    Conclusion

Based on the convergence of Information Technology and Industrial Internet of Things (IIoT), since operational processes have coincided, challenges arising from integration must also be addressed with the help of new technologies. While reference architecture models such as OpenFog, RAMI 4.0, and IIRA provide a framework and design guideline, addressing the challenges ahead seems problematic for initial IIoT deployments due to the diverse technologies and industrial applications. Following various IIoT architectures to solve integration challenges seems cumbersome. In this regard, the use of new technologies such as edge/cloud computing, software-defined networks, 5G, machine learning, etc., along with support for reference architectures, services, protocols, and standards, can solve integration challenges. As IIoT, Industrial IoT, Industry 4.0, and IoT overlap in improving production efficiency in industries, challenges in these areas must also be addressed. According to the RAMI 4.0 model of physical and virtual components of an implemented system, they can directly communicate with each other regardless of the hierarchical network. However, the system needs collaboration capability for its components to communicate with each other in IIoT. Due to the exponential growth of heterogeneous technologies, it faces numerous challenges in collaboration, latency, security, privacy, scalability, etc.

References

• Mirani, A.A., Velasco-Hernandez, G., Awasthi, A., and Walsh, J. (2022). “Key Challenges and Emerging Technologies in Industrial IoT Architectures: A Review”, *Sensors*, 22(15), p.5836.
• Moldehn, A. Industrie 4.0—Intelligent Production of Tomorrow. Available online: httpps://dam-mdc.phoenixcontact.comm/asset/156443151564/d90d65eff-0734c9a49d76134aa1061e1/Digital_Tranformation_at_Phoenix_Contact.pdf (accessed on 10 September 2023).
• Adolphs, P., Berlik, S., Dorst, W., Friedrich, J., Gericke, C., Hankel, M., Heidel, R., Hoffmeister, M., Mosch, C., Pichler, R., et al. (2016). “DIN SPEC 91345:2016—Reference Architecture Model Industrie 4.0 (RAMI4.0); Technical Report ICS 03.100.01; 25.040.01; 35.240.50; Platform Industrie 4.0: Berlin, Germany.

• Mantravadi, S., and Møller, C. (2019). “An overview of next-generation manufacturing execution systems: How important is MES for industry 4.0?”. *Procedia manufacturing*, 30, pp.588-595.
• Lin, S.W., Miller, B., Durand, J., Bleakley, G., Chigani, A., Martin, R., Murphy, B., Crawford, M. (2019). “The Industrial Internet Reference Architecture; Technical Report IIC:PUB: G1:V1.07: PB:20150601; Object Management Group: Needham, MA, USA.
• OpenFog Consortium. (2017). “The OpenFog Consortium Reference Architecture: Executive Summary; Technical Report; OpenFog Consortium: Fremont, CA, USA.