# A Novel Software Architecture Solution with a Focus on Long-Term IoT Device Security Support
## 3 Software Architecture  
This chapter proposes a novel software architecture based on existing software architectures presented in related work. Modern software architecture for the Internet of Things requires compatibility with other devices, operating systems, and the cloud. Modularity and scalability should also be considered to achieve easy upgrade and service process. In today's world, we believe that one of the most important factors should be security. The data collected are not considered public, but due to the network dispersion of the devices, the main focus was to prevent the data from being tempered with rather than viewed. Invalid configuration can render the device unusable. For these reasons, we propose a change in the software architecture to disable device control from the cloud. The device can only be controlled by the service application through the authorised service or device owner. The proposed system architecture is shown in Figure 2. The lowest layer is the physical layer where all the sensors of the device are located. The sensors used on this layer are: temperature, flow sensors and sensors measuring current consumption and nominal voltage. This layer is the first layer that forms the set of sensors needed for the operation of the device and telemetry. The operation and data processing layer was implemented as the first thread of the two-threaded ESP32 microcontroller. Data processing collects and processes the data received from the physical layer and verifies the data integrity according to the expected range. The specified sensor data were used and processed in the device operation algorithm along with the configuration parameters to make the device operational. These two layers must be functional for the device to operate. In the original device model, these two layers were implemented as part of outdated microcontroller that used the serial port as a debugging point, and the device was configured via three buttons using the two-line display LCD. The configuration is now enabled through an additional service and transport layer. Completely independently, the second microcontroller thread is responsible for communicating with the mobile service application and sending telemetry data to the cloud. This thread implements a service and transport layer. The mobile service application can only connect to the device through a direct connection to the service and transport layer. The service and transport layer exposes a WiFi access point in a short period of time after booting the device. Device configuration is set through the mobile service application, as the new device model no longer has a set up interface with the display unit. In addition to setting the parameters, the mobile service application calibrates the flow sensors since the installation parameters affect the actual calculation of the flow sensors. This process is performed by authorised service personnel during device installation. The user role in mobile service application is configured in the cloud application. Simultaneously, the service and transport layer groups the telemetry measurement data and forwards them to the cloud. This process is performed via a local wireless WiFi client (part of the local network at the device installation site) or using a built-in modem with GSM access. To ensure the security of the device installation prior to configuration by the mobile service application, the device acts as a wireless access point to which the mobile service application connects via a security access point. Security access point settings are unique to every device and an authentication QR code is provided in the device manual and on the device casing. Additional security is achieved by activating the access point only at a short time interval when the device has started.