#### 6.1.5 Application in Microsoft Azure Cloud  
One of the main objectives of the work was the implementation of a cloud application, which could be used to monitor discrete-event production system--to monitor the values of selected variables, to visualize the data appropriately, to process them efficiently and, if necessary, to intervene in the system. At the beginning, it was necessary to determine what should be in the cloud application. The **functional requirements** were then determined:  
* Display of read values and action buttons in a dashboard;
* Communication with Node-RED using the MQTT protocol;
* Display of the number of manufactured (final) products handed over for dispatch;
* Displaying the number of semi-finished products (pieces of raw material) that have entered production;
* Displaying the number of semi-finished products/finished products that are currently on the conveyors (or in the system as such);
* Graphical representation of the current temperature in the production hall;
* Simple processing of the current temperature values in the production hall in order to raise an alarm if the temperature rises above a certain value;
* Possibility of emergency intervention in the system-suspension and start-up of the production line. The characteristics defined above are intended to describe what the application system (cloud application) being created will be able to accomplish. However, it is necessary to identify a second set of requirements that will not address the functionalities of the application. These will be the so-called qualitative, i.e., **non-functional requirements**:  
* The cloud application should have a simple and intuitive user interface;
* Individual displayed variables should be part of a suitable object model, assuming appropriate use of Microsoft Azure cloud components;
* The application should allow for easy extensibility by displaying additional variables, or the possibility of adding additional production lines, each with its own panel;
* In terms of language internationalisation, the application should use English. After the design, it was necessary to move on to the actual implementation. The most effective way is to use PaaS (Platform as a Service) services, i.e., to use ready developer tools to create your own cloud applications. The original plan was to bundle together multiple PaaS services, such as Azure IoT Hub for monitoring and connecting devices [31], Power Bl for data visualisation [32], Azure Stream Analytics for data analytics [33], and Azure Functions for event callbacks [34], for example. During the course of the work, it was determined that the most effective solution would be to use the relatively new comprehensive aPaaS (application Platform as a Service) service **Azure IoT Central**[35], which combines the aforementioned functionalities. Microsoft Azure IoT Central is used to connect and manage devices on a large scale and provides reliable data for business statistics, so it can be classified as an enterprise resource planning (ERP) system. It incorporates multiple PaaS services to create easily configurable, comprehensive and secure IoT solutions. A web-based user interface allows you to quickly connect devices, monitor device status, create rules, and manage millions of devices and their data throughout their lifecycle [35]. Azure IoT Central works similarly to Azure IoT Hub based on device twins, with each device based on a template. **Device template** is a so-called blueprint that defines the characteristics and behaviour of a device type. We then connect these devices to our application. For example, we can define the telemetry that a device sends so that IoT Central can create visualisations that use the right physical units and data types. The device template we created is called **template-factoryio**. It contains the device models that we define for integration with our application. Each model has a unique ID and we also implement capabilities or semantic type for each model.