## 5 Discussion of the Case Study--Rwanda
### The Representation of the IoT Domain Model  
This section details the architecture of the proposed connected modules from the device end to the human services visualization. Figure 6 represents the identification of the proposed IoT scenario. The overall figure shows that the user needed to interact with a physical entity in the physical world. In order to allow/control the interaction of humans with the rest of the system, there was an entity called an active artifact that was running software. In the context of this research, an active digital artifact role was played by the Docker manager to harmonize the sensor nodes' operation with their respective containers. A physical entity represented a discrete identifiable entity in the physical environment: building, rooms, as well as any actuation. A virtual entity represented the physical entity in the digital world; in other words, it could be represented as the logical interface to allow physical object interaction. The device provided a medium for interaction between physical entities and virtual entities. It could be attached to the physical entities or placed closer to the physical entities. Resources were software components, either on-device or network resources. Services provided an interface for integrating with the physical entity. It accessed the resources hosted on the device (or the network resources) to obtain information about the physical entity or perform the actuation process upon it. Figure 5: Deployment design of building monitoring IoT system. Figure 7 shows the process of mounting a new sensor node to the existing system. The configuration of a new sensor node consisted of only a few steps. The first step was the process of mounting the new device with its respective driver. The second was to allow the preparation of device updates on the list of available services. The third was to be able to pull the update from the container manager. The last step was to be able to interact by pushing data to the respective entities. Figure 6: Proposed UML representation of the IoT Domain Model. Figure 7: Sequence diagram activity at the sensor node perspective. Due to the publish and subscribe services offered by the MQTT protocol for real-time information sharing between connected devices with the central controllers, the sensor node was able to connect with predefined rules to meet the required configuration. The broker deployed in fog edge with Docker Swarm was able to work in cooperation to ensure that there was no interference. The Docker Swarm could also make sure that every device with its resources was containerized. Every container was assigned its unique identification to allow the restriction to available resources. Figure 8 shows the system views from the end-user perspective. The user interacted with the system by accessing its services through the web application. In the monitoring process, the end-users, such as the fire brigade, called Emergency Response Controller (ERC) in this context, must be authenticated by the system. For the client application (services) to be able to access the data generated by sensors, the services must be subscribed to the broker to allow smooth message queueing and notification sharing using the MQTT protocol. The broker used in the research implementation was EMQ. In the data management process, all generated data from the sensor nodes were saved to another service database subscriber known as the PostgreSQL server. Data could be retrieved from the database server in a different format based on the user context. In this situation, as there was a need for data for research purposes, there was no beautiful user interface built. The data were kept for further use and retrieved in JSON format for preprocessing. For performance monitoring, a combination of different monitoring tools were used--cAdvisor, Prometheus and Grafana. Figure 8 shows only Prometheus to simplify the view.