# IoT Helper: A Lightweight and Extensible Framework for Fast-Prototyping IoT Architectures
## 3 System Architecture  
This section introduces the IoT Helper extensible architecture for monitoring and controlling embedded devices. The flexibility of the approach allows for a very straightforward integration of such devices into _cloud-computing_ architectures easily, but it can also be used in _fog-computing_ or even _edge-computing_ solutions, as discussed in Section 2. Figure 1 shows the core of our proposed architecture. It is composed of the following:  
* An _Embedded System_ that acts as the main controller of sensors and actuators deployed in the solution;
* A _Configuration Module_ that allows users to configure and customize the various sensors and actuators;
* A _Generic Firmware_ to manage operations, also called _commands_ on connected devices;
* A _Message Broker_ module that decouples the embedded system from external processors in order to scale up to large volume of data. At the core of the **Embedded System** is the Arduino module. Indeed, any sensors or actuators can be plugged into an Arduino shield. Moreover, it is possible to re-engineer the shield to customize the hardware to the specific scenario with industrial components. One of the cons of Arduino is the small memory size. Thus, the firmware that runs in the Flash Memory should be minimal. To achieve high extensibility and improve usability, the Embedded System needs to be easily configurable. We model sensors as generic inputs and actuators as generic outputs. The list of the sensors and actuators defines the _interface_ of the embedded system, which can be observed as a _black box_. An external system that wants to communicate with the Embedded System needs to know only its interface without knowing the actual implementation, which might change over time. This approach, well known in other fields such as software engineering, allows for the creation of loosely coupled systems. For example, suppose that we want to collect data from an analog temperature sensor and to control the electrical relay of an air conditioner. The interface of the Embedded System is an analog input temp, and a digital output ac. An external system, such as a mobile application that wants to read the sensor and control the actuator, will send a generic message \"_read input temp_\" or \"_change the output of ac to 1_\" without knowing any details about the physical connections on the embedded system or the actual circuitry of the sensors. As a consequence, we can change how the embedded system physically controls air conditioning from an electrical relay to an infrared actuator, keeping the interface unchanged without changing the user application. The **Configuration Module** describes the inputs and the outputs managed by the embedded system. Each input is represented by the following: (i) the type, i.e., if it is analog or digital; (ii) a unique ID used in the firmware for controlling it; (iii) a description that is useful for documentation and human interpretation; and (iv) the pin(s) where it is connected to the embedded system. Each output is represented in the same manner as the input; however, in addition, since it represents an actuator, we also store information about the allowed values. Table 1 contains a sample configuration. In this example, we have one temperature sensor with the name \"11\". In addition, we have two actuators: a digital LED \(O1\) that can be switched on and off (values 0 or 1); and an analog fan controller \(O2\) that accepts values from 0 (off) to 6 (maximum speed). Figure 1: System architecture. Data collection. The Configuration Module also allows for specifying network parameters in order to connect the Embedded System, typically to a WiFi network. All of the configurations are stored on file on an external SD card. For practical reasons, we provide a desktop application with an easy-to-use user interface in order to specify configuration values.