# IoT Helper: A Lightweight and Extensible Framework for Fast-Prototyping IoT Architectures
## 2 Related Work
Indeed, IIoT [2] differs from IoT in two several respects:  
* The main goal of IIoT is the interconnection of industrial machinery rather than human-to-machine interaction;* IIoT assumes the presence of a structured, centralized network in which most of the nodes--i.e., machines--are fixed and known in advance; therefore, there is little to no focus on extensible network architectures in which peers may freely join and leave;
* IIoT is usually deployed in mission-critical scenarios in which data integrity and preservation are a primary concern. Industry networks [3] are composed of edge nodes, i.e., the peripheral nodes where sensors and actuators are located. Edge nodes are the ones that produce data. In addition to edge nodes, intermediary nodes manage a small portion of the produced data. Typically, such intermediate nodes are specialized in task-specific analyses. Finally, centralized nodes are responsible for collecting and processing the dataset in order to derive useful information from it. Based on where data are processed, it is possible to have three types of network architectures [17]:  
* The first type is the traditional _on-premise_ or _cloud-based_ architecture where data from edges nodes are directly processed and managed in servers, either locally or in the cloud. This category of solutions that is still the most widely adopted suffers from latency problems in real-time applications with very-high volumes of data due to the latency of sending the data to servers [17] and, therefore, might be unsuitable for some scenarios in which data must be processed in real time. * The alternative is _edge computing_, where data are processed and consumed directly in edge nodes. This solves the latency problem but incurs other limitations. In fact, edge nodes suffer from low or limited resources that limit computational power. * A further alternative is _fog computing_ where computational tasks are demanded to intermediary nodes in the network. Edge nodes produce data. Intermediary nodes pre-process and consume data for real-time analysis and then send processed data to the cloud for further analysis or storage. A flexible IIoT framework should not be based on a fixed network architecture, but it should be flexible enough to accommodate for mixed approaches and take advantages or the pros of each of them. In this paper, we concentrate primarily on on-premise and cloud-based scenarios for several reasons. First, these still represent the most frequent case in both IoT and IIoT. Second, edge computing and fog computing impose both higher costs due to the need of more capable embedded systems and higher complexity in coding and debugging. However, the main reason is of a methodological nature. Our study aims at measuring the trade-offs between hardware costs and scalability. In order to measure scalability, we need to be able to assess the capability of the architecture in order to generate data at the edge node and to process them at the servers. In an edge computing scenario, the embedded hardware not only collects data but also needs to process them. Therefore, the overall data collection and processing rate depends on the complexity of edge computations. **Communication Protocols**. Multiple protocols [18] were proposed to address the problem of communicating among modules of an IoT/IIoT application. Broadly speaking, it is possible to group protocols into two main categories, as described below. * _Client-Server_ protocols work in a point-to-point fashion and require direct communication between modules. To provide an example, in order to obtain the reading of a sensor, a client app needs to contact the embedded hardware directly through the network. The main ones are XMPP and CoAP. XMPP (Extensible Messaging and Presence Protocol) is based on the exchange of XML messages. It is widely used in device-to-people communication such as control remote devices. CoAP (Constrained Application Protocol) relies on REST messages.