# When Operation Technology Meets Information Technology: Challenges and Opportunities
## 4 A typical Use Case
### 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:  
* AAS Registry;
* AAS Web Interface;
* AAS for OPC UA;
* OPC UA server;
* Industrial-grade networked cameras. 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 \(\times\) 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\(\times\) GbE (1\(\times\) 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. Figure 2: Asset Administration Shell Software Architecture applied to OT scenarios. The IT and OT worlds are isolated from each other with AAS and the OPC UA server as the gateway between the two. In the OT, a physical representation of the case study is depicted, in which packages flow from left to right, from the two belts to the singular one. Synchronization is required to ensure the correct behavior of the conveyor. 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:  
1. As a prerequisite, the AAS representing the OPC UA server must be registered at the AAS Registry. 2. 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. 3. The BaSyx framework accesses the AAS Registry and performs a lookup of the AAS representing the OPC UA server. 4. The BaSyx framework accesses the AAS representing the OPC UA server. 5. The AAS now requests the new configuration of cameras from the OPC UA server. 6. 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. 7. 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.