OPIL - The Architecture
The OPIL framework consists of several software components that can be grouped into three main groups: the generic components, the interfaces, and the case-specific ones.
Generic components: this group contains the components responsible for management of the whole logistic process. They can be successfully used regardless of the actual scope of the use case
Interfaces: this group contains both the OPIL middleware, which is essential for the communication between the components of the framework, and the interfaces connecting the framework to other systems e.g. the Legacy HW nodes or ROS components
- Case-specific components: these provide functionalities required by concrete applications. The casespecific components may be adapted and used in different scenarios if they fit the requirements. Although reusing the existing software is strongly recommended, new components can be developed and integrated by third-parties, as long as they are connected to the messaging middleware of OPIL. The core, obligatory element of each OPIL deployment is the middleware. This is necessary to provide communication capabilities for the heterogeneous components of the framework
Layer 1 (IoT Nodes Layer): Agent nodes of layer 1 are the components of the architecture that interact with the physical world. For instance, they can interact by sensing, e.g., Sensor Agent node, by acting, e.g., Robotic Agent nodes, or by interfacing with humans, e.g., Human Agent nodes. The OPIL modules of which these nodes are made of, can interact with layer 3 by exchanging messages with Layer 2 and they either directly operate on these messages or translate them to an appropriate format for internal use through their Communication/Messaging submodules.
Layer 2 (Cyber Physical Middleware layer): IoT nodes at layer 1 can talk to each other and with the other components of the OPIL, as well as with Enterprise Applications, by means of the Cyber Physical Middleware layer provided by layer 2. This communication is enabled by specific modules of this layer such as the Pub/Sub Context Broker or the Enterprise Service Bus (ESB), depending on the cases, through the network infrastructure. For example, in the case of Layer 1, Communication/Messaging sub-modules are tasked with translating toward the L4MS OPIL Info  L4MS -- Logistics for Manufacturing SMEs Page 5/9 layer 2 Pub/Sub Context Broker which has the goal of dispatching information to the other OPIL actors involved by the specific scenario. On the other hand, Layer 3 can also interact with Layer 1 throw Pub/Sub Context Broker or be integrated with Enterprise applications through the ESB component of Layer 2.
Layer 3 (Software Systems layer): pure software applications interact with the layer 1 IoT nodes, as well as with Enterprise Applications, by means of message exchange via the Cyber Physical Middleware (Layer 2). The intermediate layer, i.e., layer 2, in the OPIL architecture has a twofold role, it decouples world-interacting components from pure software components from enterprise applications and it allows for components interoperability. Indeed, with reference to the OPIL architecture, orange blocks are the OPIL “lingua franca” which enable the different components to talk each other (also referred as “the glue”). Indeed by means of the OPIL “lingua franca” the blue blocks in the OPIL architecture and the case-specific components, can talk to each other and can be composed into full-fledged logistic system in a manufacturing environment.
OPIL Demos on L4MS Youtube