# Digital Transformation of Production Planning and Control in Manufacturing SMEs-The Mold Shop Case
## 3 Method Description  
This chapter presents the proposed solution for the system for Digital Transformation (DT) of the mold production processes. As depicted in Figure 1, the proposed solution consists of two main parts: the backend and the front end. The \"Data Acquisition\" component of the proposed solution is an IoT stack supported by FIWARE components. The main components integrated into the solution are the ORION Context Broker to manage the application context and the IDAS IoT Agent (JSON-MQTT) to mediate between an MQTT-enabled sensor and the context broker. The architecture of the Data Acquisition solution is depicted in Figure 2. The main components are:  
* The MQTT adapter (implementation of the MQTT client protocol) transforms non-MQTT devices into MQTT-enabled devices. It transforms data from arbitrary formats (XML, JSON, binary signals) into MQTT messages. The body of such messages follows a JSON format, and its model is dictated by the IDAS IoT Agent. * MQTT Broker is an essential component for transferring data fast, efficient and reliable from shopfloor (connected IoT devices) towards an arbitrary number of client devices. * An IDAS IoT Agent configured to serve as a proxy between the MQTT protocol (supported by the mosquito MQTT broker) and the NGSI protocol (supported by the ORION context broker). Figure 1: System architecture. * ORION Context broker supporting the NGSI standard. * The context listener component is a client of Context Broker which uses the NGSI protocol to access context-related information and provide them towards the main backed application through its dedicated ESB. In the backend system, the major layer is the business layer (represented in blue in Figure 2) which consists of the following services/components:  
* _Enterprise Service Bus (ESB)_: The communication channel for data transfer from the \"Data Acquisition\" (see Figure 1) system towards the \"Business Layer\". (implemented using Apache's Camel and Active MQ)
* _MES/ERP Interface_: A generic Interface to communicate with MES/ERP systems. The solution provides an API for production schedule creation and management. The API is implemented through a set of Rest Services exchanging JSON formatted data. * _Data Services_: This component provides the API for accessing the data managed by the backend system. Again, these services/API are implemented as Rest services (JSON) and are utilized to develop the \"apps\" in the Frontend layer. * _Notification & Alerts Service_: This module provides the Frontend layer with simple and complex events generated by the CEP component. The CEP component is precond to fire complex events from the IoT data that each third-party application (in our case the Front-End apps) can be registered to receive and act upon. * _Complex Event Processing (CEP)_: This component is connected to the ESB to retrieve events from sensors and combined with historical information from the \"Data Access Layer\" generates alerts and notifications. The generated events are preconfigured through a rule-based system and upon their creation are propagated to the registered services through the HTTP protocol as JSON messages. * _Data Analytics_: This component is a group of services that produce high-level information from the low-level shop floor and production data like business KPIs. The other two layers, namely the \"Data Access Layer\" and \"Persistence Layer\" their roles are to make sure that data are securely stored and efficiently retrieved from the physical storage (RDBMS system). The front end consists of the following apps:  
* _Shopfloor Operator Support App_: This app (see Figure 3) is used to guide an Operator to perform a \"task\". Upon reaching a workstation, he scans his badge, and a list of \"products\" and corresponding \"machines\" are presented to select and start/finish a process.