1. Introduction
The Industry 4.0 (I4.0) paradigm represents one of the major industrial turning points of the XXI century [
1]. Many challenges are derived from Industry 4.0, from new technology integration to the creation of new service-oriented businesses [
2]. However, we argue that the rise of interconnection between heterogeneous systems in manufacturing Operational Technologies (OT) is the basis for this industrial revolution [
3].
Machines, devices, and production lines compliant with the I4.0 paradigm will be capable of collecting data on their state and behavior and, most of all, communicating with each other in order to achieve levels of coordination and collaboration on a scale that has been unforeseeable to date [
4]. The final goal is to feed simulation models and/or digital twins to investigate operating scenarios and provide decision support or optimization [
5]. Several benefits are expected from this approach, mostly concerning enhanced efficiency and effectiveness of the production process, making it a major contribution in terms of achieving a more sustainable economy and a reduced environmental impact [
6].
However, as usual, there are no free lunches in technology, and pursuing the I4.0 objectives also opens the floor to some major challenges, among which is the opening of OT infrastructure to communicate with Information Technology (IT) infrastructure and the Internet. This is an issue that, to be solved effectively, requires new architectural approaches. To the best of our knowledge, the discussion on the technological enablers and possible solutions to such problems is still very fragmented, often bound to proprietary platforms or only partially addressing the problem.
The goal of this manuscript, in line with the scope of the special issue “State-of-the-Art Future Internet Technology in Italy 2022–2023”, is to report on the lessons learned and the experience gained by taking part in industrial research projects with some manufacturing companies located in the Emilia-Romagna region, which is one of the main manufacturing districts in Italy. The regional government traditionally exploits EU funds, devoting them to regional development and launch programs (
https://fesr.regione.emilia-romagna.it/erdf, accessed on 29 December 2022) with the aim of supporting research projects to study medium- to long-term problems jointly between universities and companies. Moreover, more recently, the national government also funded the creation in Bologna (the capital city of the region) of the Competence Center of Big-Data Innovation and Research Excellence (Bi-Rex) in Industry 4.0 (
https://bi-rex.it/en/home-page-eng/, accessed on 29 December 2022).
In this manuscript, we will present the general architecture of an industrial environment designed to manage the integration of the IT and OT by exploiting the Asset Administration Shell (AAS) [
7]. We will show, in particular, how this technology can act as a gateway to decouple the IT and OT worlds while still allowing them to communicate, thus addressing the challenges previously described. This architecture and the example provided stem from the experience gained in collaborating with manufacturing companies in industrial research projects, in the framework of the programs mentioned above. The high-level discussion of the role of the AAS and the architecture that it may support will be complemented in the last part of the manuscript with a simple use case, which will be used as a proof-of-concept of the described solution. In particular, we will describe and discuss a scenario where multiple cameras require synchronization to achieve an OT goal. This use case gives us the chance to show how the AAS may support the achievement of a complex coordination goal, which starts from the IT but is implemented in the OT.
The manuscript is structured as follows: In the following
Section 1.1, we discuss the open challenges in I4.0 regarding the integration between IT and OT. Consequently, in
Section 3, we review the main technologies that can be used as enablers in the introduction of the I4.0 principles. Then, in
Section 4, we describe the use case considered and explain the role played by the Asset Administration Shell. In
Section 5, we provide some final discussions about the results of this manuscript, compare them with related works available in the literature, and highlight the limitations. Finally, in
Section 6, we conclude by presenting possible future works.
1.1. Open Challenges
Data suggest that the manufacturing sector is one that has obtained the most benefit from the introduction of I4.0 [
8]. Manufacturing benefits from the higher level of automation and the increased flexibility of processes have led to better product and service quality while simultaneously reducing operating costs along the value chain.
While the manufacturing sector is where we can see the most significant impact of the introduction of I4.0, its evolution also poses one of the main challenges: the opening of OT networks to the IT company network and to the Internet in general. This generates a number of novel cyber-security threats to the manufacturing environment, with several examples that have recently made the headlines of newspapers [
9,
10], making it clear that this is a key issue to be addressed.
OT and IT are two distinct but correlated technologies that are critical for the functioning of modern organizations. OT is responsible for the control and automation of physical processes, while IT is responsible for managing and processing data. In this paper, we propose a case study for understanding the relationship between OT and IT, and for presenting OT in the context of modern organizations.
The output of this work consists of three main components: the physical asset, the IT department, and the bridge between the two. The physical asset is the physical machine, system, or infrastructure that is being monitored and controlled. The IT department is the counterpart of the physical asset, presenting the business logic of the company. The bridge between the two is the set of technologies and protocols used to connect the physical and digital worlds, such as OPC UA.
We also highlight the importance of security, as both IT and OT systems are critical infrastructures and need to be protected from unauthorized access and malicious attacks. To ensure security, it is essential to implement robust security measures at all levels of the system—from the physical asset to the digital asset and the bridge between the two [
11].
The main problem is the heterogeneity of the OT networks currently in play. Many of these industry segments were designed several years ago and were not meant to be exposed on the IT network. This requires that OT networks and their interconnections to other networks be protected against the following:
These problems are not particularly difficult to handle. Defense processes and techniques are already well-developed and documented in the literature. However, what is missing is a series of new software architectures and technologies that make it possible to implement the security processes that we already know widely in these new application scenarios (always within the Industry 4.0 paradigm).
2. Related Works
IT and OT have evolved independently over time to solve different problems by employing different system architectures and communication protocols. IT systems were designed to connect applications and share data; as a result, they tend to be open and standards-based. Operational control systems were designed as standalone entities and were not originally intended to be connected or even accessed remotely [
14]. As a result, OT systems tend to be closed and proprietary: OT alone monitors and controls physical devices only where operators are located. If OT can be accessed from different locations and by management, it will improve decision-making, optimize industrial control processes and business flows, lower operating expenses, accelerate business results, and reduce risks. This can be achieved by the integration of IT and OT [
15].
Considering the related works in the literature, the majority of the academic research regarding Eclipse BaSyx for IT/OT integration is tailored to vertical use cases, focusing on the achievement of context-specific objectives. These works include data collection and visualization from existing “off-line” machinery [
16]; resource monitoring in an open, interoperable, and vendor-neutral manner [
17]; real-time control of a production line by shifting analytical capabilities to edge components, avoiding high volume data transfers, and reducing latency [
18]; and robust data exchange between enterprise and control applications in a motor control scenario [
19].
In contrast, [
20] applies Eclipse BaSyx Asset Administration Shells in the context of service robots for intra-logistics tasks such as transportation and order picking. The AAS allows at runtime to command a service robot and to collect individual performance indicators such as kilometers traveled, success rates of task completion, the time needed for tasks, etc. In the end, the authors admit that the AAS of a service robot system can also hold accumulated operational data to support decisions such as maintenance but the idea is not supported by any real simulation.
Considering security-related scenarios, the only relevant related work can be found in [
21], where authors propose a safety and security reference architecture to provide a firm ground for developing safe and secure AAS-based applications in the context of Industry 4.0.
Regarding instead the application of PTP in visual camera synchronization scenarios, [
22] describes a frame synchronization scheme for high-speed networked vision systems. In this work, multiple vision sensor nodes, each comprising a camera and a PC, are connected via Ethernet for data communication and clock synchronization. The clocks of the PCs are synchronized over the network by PTP, while the trigger of each camera’s shutter is locally controlled based on the PC’s clock that is locally provided inside the node and globally synchronized over the network.
3. State of the Art in I4.0
Nowadays, shop floors constitute a very complex environment, mixing a plethora of devices, spanning from natively IoT-enabled [
23] ones to legacy systems. On the one hand, OT systems are built in order to facilitate the automation of production processes for in-plant and near-real-time data gathering, control, and monitoring [
24]. In addition, the OT layer comprises a wide range of protocols that are incompatible with one another and lead to fragmentation, making it difficult to provide a coherent and consolidated view of the assets and processes [
25]. On the other hand, IT networks are primarily used to collect, manipulate, and analyze information to generate insights.
Moreover, the current trend in factory automation verges towards connecting the factory floor to all other enterprise processes. The adoption of cloud platforms [
26] ensures the needed scalability of storage, computation, and cross-domain communication capabilities but also poses a number of novel cyber-security threats to the manufacturing environment [
27].
To handle this heterogeneity, it is very useful to focus on a possible architecture that embraces both worlds: state-of-the-art IT and OT tools and technology. For this reason, the Reference Architecture Model for Industry 4.0 (RAMI 4.0) [
28] defines a reference architectural model to align standards in the context of I4.0. It consists of a three-dimensional coordinate system that describes all the crucial aspects needed for the implementation of Industry 4.0. In RAMI 4.0, a central focus is given to the management of physical assets: the Asset Administration Shell (AAS) constitutes a digital representation of a physical asset and is deemed essential to the implementation of a digital twin for I4.0. It performs the roles of asset, communication, information, and function layers in RAMI 4.0 [
7]. An implementation of the AAS, which is standard compliant, is Eclipse BaSyx, which acts as a middleware and offers a new service-oriented architecture for I4.0 that can fill the gap present in today’s shop floors. The purpose of Basyx is primarily to be open and permit highly interconnected automation systems to share data across several layers of the automation pyramid.
In addition, RAMI 4.0 recommends only the International Electrotechnical Commission (IEC) standard 62541 OPC Unified Architecture (OPC UA) for implementing the communication layer [
29] in order to enable information exchange between the shop floor and the enterprise systems. OPC UA is a platform-independent industrial communication protocol that addresses the need for the Industrial Internet of Things (IIoT) and the Industry 4.0 paradigm for standardized data connectivity and interoperability for both horizontal and vertical data communications. In particular, horizontal integration refers to controller-to-controller or machine-to-machine (M2M) communication, whereas vertical integration refers to communications from sensors/actuators and controllers in the field to IT systems or the cloud and vice versa [
30].
Nevertheless, to enable smooth and efficient operation and fast responses to warnings and failures, the communication should be performed with very low latency [
31]. In this context, ultra-low latency refers to the ability to process and transmit data with minimal delay, typically on the order of microseconds or less. This is essential for enabling real-time decision-making and control in Industry 4.0 applications, such as predictive maintenance, automated production, and remote monitoring and control. For instance, a hybrid ultra-low latency system might incorporate high-speed networks, such as TSN (Time-Sensitive Networks), to ensure fast data transmission, as well as specialized hardware, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), to enable real-time data processing. In addition, the system could incorporate advanced algorithms and machine learning techniques to improve the efficiency and accuracy of data processing and decision-making.
3.1. BaSyx
The BaSyx platform [
32] is the result of the project BaSys 4.0 (
https://www.basys40.de/, accessed on 29 December 2022), which is funded by the German Federal Ministry of Education and Research.
The main benefits of employing BaSyx are as follows:
End-to-end digitization: Realized by providing logic communication objects to all connected devices through the Virtual Automation Bus (VAB), which bridges communication networks by mapping well-defined network operations to network-specific primitives [
33].
Changeable production: Changes in automation processes require developers to adapt Programmable Logic Controller (PLC) programs and require testing of all changes. In addition, every problem that occurs delays the restart of a production line, and is therefore highly expensive. The service-oriented architecture of BaSys, which encapsulates PLC programs as reusable services, acts as an enabler to realize changeable production [
16]. As a result, a change in the production process is not reflected by a change in the PLC programs. Thus, architecture changes in production processes can be virtually tested, reducing downtime to a minimum.
Integrating live process data from assets: Digital twins are complete digital representations of physical assets; therefore, they must reflect the current state of an asset. Eclipse BaSyx connects digital twins to real-world assets with data provider components that communicate through a variety of IoT and IIoT protocols, such as OPC UA, MQTT, and HTTP/REST.
Unified interfaces to assets: Digital twins need to integrate different kinds of assets. Eclipse BaSyx implements bidirectional digital twins, i.e., a digital twin that both represents the current state of an asset and realizes a unified interface to that asset.
Eclipse BaSyx uses the Asset Administration Shell (
https://wiki.eclipse.org/BaSyx_/_Documentation_/_AssetAdministrationShell, accessed on 29 December 2022) (AAS) as the base technology for digital twins. Asset Administration Shells are one main component of Industry 4.0 for providing information exploit abstraction between higher levels and lower ones, hiding the complexity of the assets and creating an interface between the physical and virtual production steps. The AAS is a standardized data model and architecture for the representation and management of industrial assets. It is designed to enable interoperability and data exchange between different automation systems and devices in the industrial Internet of Things (IIoT). The AAS is the digital representation of an asset, where an asset can be anything valuable to an organization—such as a physical device, software component, worker, or product—but also includes the manufacturing process. Each AAS is identified by a unique identifier and composed of a header and a body: the former contains identifying details regarding the asset administration shell and the represented asset, while the latter comprises a certain number of submodels—both static or dynamic—that provide asset-specific information [
34]. Static submodels contain data—e.g., describing offered services and how to reach them—and the physical properties of the represented asset. A static model, for example, describes an OPC UA server that provides live sensor data or access to device control functions. Dynamic submodels contain instead dynamic data, e.g., live-measured sensor data. A dynamic model also may offer callable services; thus, it can provide direct access to manage or even control assets.
Asset Administration Shells must be registered in the Eclipse BaSyx AAS registry [
35]. The registry registers AAS descriptors that contain the AAS identifier and information of both an Asset Administration Shell and its submodels. In addition, it provides an HTTP/REST API that enables AAS to be looked up by other components.
3.2. Ultra-Low Latency
The integration of Internet of Things (IoT) and Cyber-Physical Systems (CPS) with the principles of Industry 4.0 highlights the need for reliable and ultra-low latency communications in future industrial networks. The complex constraints required for ultra-high reliability combined with low latency make this technology very difficult to implement over standard Ethernet. The convergence of IT/OT technologies is bringing a whole world of possibilities for the configuration and management of real-time networks for the automation industry [
36]. The use of ULL (Ultra-Low Latency) technologies is relevant for an issue that is deeply felt at an industrial level: safety systems in modern factories are among the most sensitive industrial cases, and reliable and deterministic communications are the backbone of a safety system. According to the Safety Integrity Levels (SIL) [
37], there are requirements for the response time of safety applications such as medical or aerospace devices, for example, for level 3 (SIL-3). The panorama of ULL technology is quite crowded with proprietary protocols. For instance, industrial Ethernet systems, such as Sercos, PROFINET, and EtherCAT, are widely used in factory production lines. This dispersion of protocols is problematic in terms of duplication and inefficiencies from an industry point of view—that is, the so-called “vendor lock-in” usually creates difficulties in hardware and software interchangeability.
One of the most promising standards is an open suite of protocols called TSN [
38]. The Institute of Electrical and Electronic Engineers (IEEE) with the Time-Sensitive Networking Working Group 802.1 (
https://www.ieee802.org/1/pages/tsn.html, accessed on 29 December 2022) is currently working on improving the reliability and real-time capability of standard Ethernet (IEEE 802.3) [
39]. Despite being based on best-effort packet networks, TSN is capable of providing real-time performance, low-latency synchronization, and the creation of contracts between transmitters and the network to achieve ultra-reliable packet delivery, bounded latency, and zero congestion loss [
40]. The TSN standard set covers a wide range of Quality of Service (QoS) transmission requirements and can be classified into categories [
41]. The most common and useful, from an industrial point of view, are as follows:
Time Synchronization: IEEE 802.1AS Time Synchronization for Time-Sensitive Applications (AS).
Scheduling: IEEE 802.1Qbv Enhancements to Traffic Scheduling: Time-Aware Shaper (TAS).
Control and Orchestration: IEEE 802.1Qca Path Control and Reservation (PCR).
Policing and Redundancy: IEEE 802.1Qci Per-Stream Filtering and Policing (PSFP).
In this work, we will focus on the time synchronization capability between devices. As described, the TSN stack standardizes the time synchronization in the IEEE 802.1AS documents. These documents aim to describe a specific protocol to obtain synchronization called the generic Precision Time Protocol (gPTP).
This protocol is based on PTP (Precision Time Protocol), which is the backbone of the TSN stack. While the task of clock synchronization is usually performed by NTP (Network Time Protocol) in common scenarios (wall-clock time distribution), there are cases in which the performances of NTP are not sufficient [
42], such as the one described in
Section 4.2. The PTP standard spans over three main revisions: IEEE-1588 2008 is the second and most popular one, implemented in the majority of devices present in Italian industries; IEEE-1588 2019 introduces minor modifications over the previous standard. The standards define and classify the implementations using “profiles”, which describe the minimum guaranteed features such as maximum latency or hardware time-stamping. gPTP is the profile required by TSN, specifically described in IEEE-802.1AS. Synchronization protocols require a specific hierarchy to manage wall-clock distribution—that is, more precise machines, such as Atomic-Clock-based ones, are “higher” in the clock hierarchy than less precise ones, as pictured in
Figure 1.
4. A typical Use Case
In this second part of the manuscript, we will focus on the specific problem of integration between the OT and the IT with an emphasis on communication capabilities and services. We believe this to be a very significant problem that can be successfully addressed with the logical approach enabled by the AAS.
The focus will be on the use case of maintenance, which is a very typical problem in manufacturing environments, with scenarios such as the following [
43]:
BM—Breakdown Maintenance -> sudden failure;
TBM—Time-Based Maintenance -> performed on a calendar schedule;
CBM—Condition-based Maintenance -> in advance of the failure.
The pilot implementation described below can be successfully applied to all these situations, as we experienced working with industrial partners on research projects at national and international levels. In particular, we will consider, as an example, the case in which some assets must be configured to share a common time frame, using some sort of time synchronization over the network, which will involve ultra-low latency communications such as TSN. In this case, the problem is twofold:
On one hand, an external entity must orchestrate which communication capability should be active in which asset in order to guarantee the proper service configuration;
On the other hand, an external entity must interact with the assets to perform the actions required to enable and configure the communication capabilities.
4.1. Case Study
In the depicted scenario, a conveyor belt is composed of two convergent lines, each one associated with a subset of visual cameras. Each camera is connected to the industrial physical switch via Ethernet for data communication and for clock synchronization. On the whole, the cameras constitute a vision system that collects images of the packages streaming on the conveyor belt. The information provided by this vision system is then processed by the business logic, taking into account other factors related to the manufacturing plant in order to control the speed of the two lines and the non-uniform distribution of packages on the belts.
Industrial cameras can be used to achieve visual recognition of objects and packages streaming on the conveyor belts—that is, when a package passes through an area, information regarding the speed of the belt can be processed by business logic. In this scenario, the two different belts in an ideal situation should run at the same speed; however, in a real-world situation, the speed depends on various factors such as the performance of the devices, the temperature of the belt, safety checks on the system, etc. In that case, the various cameras and the motors controlling the speed of the belt must be synchronized to recognize the various packages when they run on the conveyor. As pictured in
Figure 2, the speed of the main line and of the other two lines must be continuously adjusted depending on the number of packages detected by the cameras.
With two lines (Line 1 and Line 2) active at the same time, the capacity of the main line may be overloaded. In this case, one of the secondary lines must be adjusted or stopped and then restarted. Without this synchronization, the scenario described is difficult to manage: creating a packet scheduler between desynchronized devices can introduce problems in the management of the line. In our deployment, this goal is achieved by using “smart” cameras and motors connected by TSN. As stated in
Section 3.2, PTP—the protocol employed by the TSN stack to obtain time synchronization—is strictly dependent on a well-defined clock hierarchy. This hierarchy is usually decided using the intrinsic capabilities of the clocks (e.g., the precision or the mean skew) and can be reconfigured by Basyx, transparently to users and administrators. Orchestration can be used to select subsets of devices, creating “isles” of synchronization. This can be useful in the example of the cameras explained before: a camera can be isolated from the others, synchronizing just with its subset of neighbors. This flexibility is required when one of the belts must be repaired, where the shut-down operation for maintenance will isolate the other line and make it the only belt feeding the main one. In that case, the cameras and the motors must be synchronized only between the active devices of the system. The operator can remove the inactive line from PTP synchronization and operate on it.
As described in
Section 3, the AAS provides a common structure for representing the information and behavior of an asset, while OPC UA is a communication protocol that enables secure and reliable data exchange. By using the AAS and OPC UA together, it is possible to support various IIoT applications such as condition monitoring, predictive maintenance, and asset optimization. For instance, an AAS can be used to represent the digital twin of a camera, while OPC UA can be used to collect real-time data from the camera, independently from its model and type. These data gathered through OPC UA can be then processed to obtain information about the condition of the production line in order to predict when maintenance is required. Additionally, the combination of AAS and OPC UA can facilitate the integration of other systems and devices, such as control systems and supervisory systems, allowing for a more comprehensive view of the asset.
4.2. Prototype Enabled by AAS
The abovementioned concept was implemented in a test bed, which is described in
Figure 2. In the test bed, the following components were deployed:
The test bed is hosted on two machines that run the IT and OT sections of the network, respectively. The IT section is implemented on a Server rack PowerEdge R7525 with the following hardware characteristics:
RAM 32 GB;
Dual AMD EPYC 72F3 3.7 GHz, 8C/16T, 256M Cache;
480 GB SSD SATA Read Intensive 6 Gbps;
NIC 2 × 1 Gb Onboard LOM, MLK V2.
The OT section was implemented on a Dell Edge Gateway 3200, running the OPC UA gateway, with the following hardware characteristics:
Dell EMC Edge Gateway 3200, Atom 4C Elkhart Lake, 4G, 64G, Ubuntu, TPM;
DDR4 SO-DIMM socket, 8 GB DDR4;
2× GbE (1× 2.5 GbE).
The line operator, shown in
Figure 2, can use an Android smartphone exploiting the Eclipse BaSyx web app. This web app is exposed only inside the local area network of our industrial partner. As an additional security mechanism, only the MAC address of the operator’s device is enabled to connect to the web server that hosts the AAS registry.
As explained above in
Section 3.1, the implementation of the AAS-related software exploits the Basyx platform, to which we will refer in the following. In
Figure 2, we also highlight the steps that will be functionally performed during the experiment used to prove the effectiveness of the proposed approach. Assuming the system is working properly, a problem arises when one of the two lines must be put under maintenance; in this case, it is necessary to disconnect the visual cameras associated with that belt in order to create a subset of cameras synchronized only with each other. Currently, the task is performed manually by a human operator, who has to physically detach the cameras from the network. This process is time-critical and error-prone; therefore, a mechanism to reconfigure the cameras in an automatic way is needed. The whole process is achieved with the steps explained below:
- ⓵
As a prerequisite, the AAS representing the OPC UA server must be registered at the AAS Registry.
- ⓶
A human operator has to start the maintenance process by accessing the AAS Web Interface. It is important to highlight that this is the only interaction that involves human intervention.
- ⓷
The BaSyx framework accesses the AAS Registry and performs a lookup of the AAS representing the OPC UA server.
- ⓸
The BaSyx framework accesses the AAS representing the OPC UA server.
- ⓹
The AAS now requests the new configuration of cameras from the OPC UA server.
- ⓺
The previous step triggers a recalculation of the PTP hierarchy, which reconfigures the clocks of the cameras, synchronizing only the ones that do not belong to the line put under maintenance.
- ⓻
At the end of the process, the AAS receives images and data only from the synchronized cameras. This information is then exploited by business logic.
For the deployment of this test bed, the first element was the Docker container for the AAS Registry. A screenshot of the AAS Registry is presented in
Figure 3.
The second deployed element was the AAS Web Interface, which is responsible for exposing the list of capabilities of the OT devices—in our case, the cameras exposed by the OPC UA server. To create a contract between the OPC UA server and the system designed, we wrote a class that represents the entities using the official SDK, available on the Basyx repository (
https://github.com/eclipse-basyx/basyx-java-sdk, accessed on 29 December 2022). This class is the gateway between the IT and OT environment and provides the commands and settings to separate cameras into synchronized subsets. The flexibility offered by Basyx can be useful to orchestrate and change the behavior of part of the system, reflecting the customer requirements. A screenshot of the AAS interface and of the modules that are exposed is presented in
Figure 4.
Combining AAS with network protocols such as PTP allows for faster infrastructure-level operation. This behavior is highlighted in
Table 1. These data were collected over five experiments per the number of devices, for each type of intervention. In the tables, we highlight the mean time to perform PTP reconfiguration in our target company before and after the introduction of such automated behavior, together with the related standard deviation. We should also underline that with one or two devices there is no time of synchronization between the cameras as there is no reason to perform the sync. As can be noticed from the data
Table 1, the time taken for human intervention is not negligible. Before the introduction of AAS, the customer was dependent on manual input from humans (i.e., physically disconnecting the devices). These interventions required complex interactions such as identifying the specific physical connection of the devices. Therefore, measures can vary a lot between scenarios, depending on a number of variables not directly related to computers such as cable management (the cumbersome task of identifying the correct cable that must be disconnected, reaching the place in which the devices resides, etc.). In the other case (the automation introduced using AAS), the required time to reconfigure the devices is directly related to the reconfiguration of PTP. The synchronization procedure will trigger a recalculation of the hierarchy, the duration of which depends on the implementations of the protocol [
44]. We can observe that automatism heavily impacts the performance of the procedure. It makes the time to perform the operation almost constant, in contrast to the manual procedure that requires nearly exponential time.
5. Discussion and Limitations of the Study
We argue that this work differs from the current state-of-the-art because it discusses how to use the AAS to integrate OT and IT in an industrial environment, with a simple but effective use case, rather than just using it to implement a specific OT application. In particular, Ref. [
19] describes data conversion between the AAS of a motor and Excel, which is generally used to manage the business-related data of enterprise applications, in order to ensure robust data exchange between enterprise and control applications. Our solution not only enables interoperable data exchange between OT and IT applications but also permits controlling OT devices via IT protocols. Moreover, Ref. [
20] explains how it is possible to apply AAS in the context of service robots: this use case represents a clear example of IT/OT integration; however, no practical implementation is presented nor clear results reported. Likewise, a reference AAS architecture for safety and security is presented in [
21], but only through a conceptual view. Therefore, to the best of our knowledge, the only academic research that presents clear results is [
17]. In the mentioned work, AAS is employed for runtime monitoring of data, reflecting the resource usage and performance of devices and services in Industry 4.0 installations, and results are evaluated in terms of response time. Considering that OT device control is one of the pillars of I4.0, the aforementioned solutions clearly lack this aspect, which is instead addressed in our solution.
Finally, as highlighted in [
45], even though several publications mentioning the synchronization of cameras using PTP are available, in reality, they can be grouped into two main methods:
Synchronization of computers connected to a network using PTP, while the cameras are still synchronized using NTP with the computers. Hence, the synchronization procedure involves the synchronization of multiple computers connected in a network rather than the cameras.
Synchronization through a master–slave architecture, where each camera connects to the computer through a frame grabber card. The clocks of the master computers in the architecture are synchronized using PTP.
In our case study, we exploit the master–slave architecture; however, as an aspect of novelty, we employ cameras provided by our industrial partner, which natively support PTP without the need for an external computer.
The system proposed also has some critical points: one is bonded with the development of the AAS, which requires writing the configuration model of the asset to interact with; so, it cannot be automated. Another possible critical point derives from the difficulty to create the configuration of OPC UA; this task is not automatized yet and relies on the system administrator.
6. Conclusions and Future Works
In this work, we showcase Eclipse BaSyx AAS using a time synchronization scenario in I4.0, in which the main focus concerns IT/OT integration. The contributions of our work are threefold. First of all, by combining Eclipse BaSyx AAS with OPC UA, we enable interoperable communication between the assets of the manufacturing environment, particularly visual cameras. This aspect grants IT/OT integration while maintaining the isolation of two worlds from each other. Secondly, we employ TSN as a mechanism to create different subsets of cameras that are synchronized with each other by need. In the end, we apply the aforementioned concepts and technologies to a real use-case scenario depicted by an industrial partner, where multiple cameras need synchronization to visually recognize packages streaming on a conveyor belt, in which the converging belts may run at different speeds. The proposed solution allows us to achieve a complex coordination goal starting from the IT but implemented in the OT, granting flexibility and reconfigurability of the industrial plant, thanks to the adoption of Eclipse BaSyx AAS, while reducing human intervention to a minimum.
Following considerations about the limitations of the academic works present in the literature, future work will be focused on the application of the proposed architecture to different manufacturing scenarios that require synchronization between devices and/or production machines. Moreover, more experimental tests in different companies will be required to validate the architecture and the results: the main problem is in fact related to the accuracy in the measurements of manual human intervention times, which depend on a number of variables not predictable a priori.