## 4 System Implementation
### Production Administration Shell  
PAS takes inspiration from the design of the RAMI 4.0 AS (the similarity in representation can also be observed in Figure 6). Simply put, it represents a wrapping component that embodies, organizes, and exposes, in a standardized manner, the CPS functionality towards the overall production execution environment (refer to Figure 4 for architectural details). The goal of the PAS is to provide an easy-to-use tool which helps with transforming typically ad-hoc developed (legacy) manufacturing cells into interoperable, service-based I4.0 CPSs for distributed production environments. PAS embodies a dedicated OPC UA server (extension of the MILO Project, serving both the MESS core and third party OPC UA clients) and an HTTP server/client interface, which is capable of providing the same functionality and services defined for the MESS Core but specified/customized for the local intelligence and complexity of the single CPS. The PAS embodies a _Device Communication Layer_ (DCL) to communicate with the physical devices, which is responsible for sending task execution requests, receiving reports on task execution statuses, sending special (maintenance) service requests to the devices (in order to query or cancel active tasks), as well as collecting the device variables' current values. Sending executable and maintenance tasks, as well as receiving inherent reports and variable updates from the CPS physical layer, can occur through different channels (HTTP or TCP), whereas intensive (Big Data) physical signal variables can be sent over UDP or MQTT, both to internal components or to external, cloud-based services for analytical purposes. As previously mentioned, the CPS Twinning layer of the MESS is able to generate a standardized OPC UA-equivalent transformation of the CPS information model. This is the core feature of the PAS too (details on the interfaces between the MESS Core, the CPS Twinning/PAS, and the low-level CPS communications can be found in Figure 7.  
OPC UA was not chosen (although capable) for the intensive, low-level communications between the PAS and the CPS physical layer, due to the following reasons: first of all, the OPC UA is a complex information modeling technology to be deployed, and not just a communication and transport protocol; this can possibly result in communication stack overload and so response time issues at low-level, especially in resource-limited devices; in  
Figure 6: Production Administration Shell for CPS modeling and functionalities. other words, OPC UA is not (primarily) intended for IoT bottom-up big data publishing (as also reported in [54]). To this end, the MQTT lightweight publish/subscribe messaging transport technology was selected for bottom-up data interoperability, even considering the possibility of pairing this technology with OPC UA in a publisher-subscriber model, eventually. Alternatively, the PAS has also built-in UDP data exchange interface. Task execution requests can occur in two different modes, according to the specific device capabilities. By default, this layer handles task queues for the devices and dispatches tasks one-by-one. If a device is natively able to handle execution queues or to process more than one task at a time (what can be called _flooded_ task execution), this setting can be omitted. The PAS also contains a built-in planner and a device controller, which provide the same realization of the OPC UA and HTTP interfaces proper of the MESS core but with the main goals to transform the high-level command tasks into low level, device-specific ones, and to control the execution of this new task graph. The types of CPS utilized in this work comprise a variety of elements: single robot arms (1), production assembly line (2), Automated Guided Vehicle (AGV) fleet, with and without robot arms (3, 5), collaborative robots (4) and human operated components, such as the warehouse and a digital work assistance system (6).