OPIL - The Architecture

This platform is meant to enable the development of value added services for the logistics sector in small-scale Industry 4.0 contexts such as those of the manufacturing SMEs. In fact it provides an easy deployable suite of applications for rapid development of complete logistics solutions; these include components for path planning, mapping, navigation and so on.
 
OPIL provides ready connectivity with equipments for optimal material handling on factory floor. These include (but not limited to) mobile robots, AGVs, forklifts, workers and sensors as well as IT infrastructure of the factory such as various warehouse management and ERP (Enterprise Resource Planning) systems. OPIL also provides a ready integration with a state of the art 3D factory simulator (with mobile robots, AGVs, forklifts, workers and sensors) allowing the complete development and testing of logistics solutions virtually, and presenting them to factories before actual implementation; 3D simulator provides support for the estimation of investment and guides the orchestration of the deployment tasks.
 
A messaging system at the heart of OPIL, which is based on the FIWARE open architecture, handles interactions among the several components of platform as well as with the external ones. The open architecture of OPIL supports the usage of open-source frameworks such as ROS (Robot Operating System) for the development of new components, e.g. perception, mobile manipulation, etc.
 

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

Light Blue: network infrastructure; Orange: components able to interact with the middleware (L2); Dark blue: sub-components/functional blocks; Grey: sub-components planned for OPIL v2; White: external components integrated into OPIL v1.0;



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 [767642] 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

 

      

 

 

Share This Post: