# FLINT: Flows for the Internet of Things
## 3 Related Work  
A plethora of both open-source and commercial IoT platforms already exist. An overview of the most common systems is given in Table 1. The architecture of every platform is presented using a simplified notation representing the number of inputs, the number of intermediary processing elements and the number of outputs:  
* N*-N*-1: there can be \(N\) inputs, \(N\) processing elements and only 1 output. This architecture often stores the data inside the platform. * N*-N*-N*/N*N*/X*: there can be \(N\) inputs, \(N\) processing elements and \(N\), \(N*N\), or \(X\) outputs. With  
* N* representing a custom, reusable element, either input, processing or output that can be implemented by the user. * X* representing an element, either input, processing or output offered as is by the platform. Some platforms allow communication between elements inside the deployed system. This is visualized using N*N*. Flows that end with a single N* or X* provide elements that have a single output. Contrarily, flows that employ an N*N* approach provide reusable components for every node that can be integrated in the platform, i.e., every element has multiple inputs and outputs. An N*N* approach is illustrated in Figure 1, where the message can be passed back and forth between Abstractions, Processing elements and elements that provide platform interoperability at the Service Endpoint. Next, the supported directionality of a platform is indicated using the Input/Output (I/O) column. Furthermore, the complexity of the platform is presented in column 'Complexity'. A distinction is made between low, medium and high complexity. A low complexity platform indicates that flows can be created by making use of a GUI. A platform that requires some technological background about the platform and technologies is labeled with medium complexity. A platform that requires in depth knowledge about the platform and the underlying technologies is labeled with high complexity. \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline
**Project** & **Solution** & **License** & **Protocols** & **Usability** & **Interoperability** & **Architecture** & **Language** & **Direction** & **Complexity** \\ \hline \multirow{3}{*}{AWS IoT [1]} & Message broker & Commercial & \multirow{3}{*}{MOTT, HTTP} & Draw flows in a & \multirow{3}{*}{No} & \multirow{3}{*}{N  
Many of these projects aim to provide a user friendly interface to interconnect systems and applications. The open source flow-based editor, _Node-RED_, provides a GUI where modules can be connected to develop a flow [27]. Extra modules are also shared by the _Node-RED_ community. _Node-RED_ runs as a single Node.js instance and focuses on usability and fast prototyping, rather than on scalability and interoperability. Another open source project, _node-wot_, implements the Web of Things (WoT) specification and aims to provide an abstraction between physical things and the current World Wide Web (WWW) [25]. This abstraction makes it possible to access things using web technologies. The W3C Thing Descriptions (TDs) provide semantic interoperability. Devices can be accessed and interconnected using LD concepts. _node-wot_ runs inside a Node.js server and focuses on interoperability and usability, rather than on scalability. INTER-IoT grew out of the objective to design and implement a cross-layer framework to provide interoperability among heterogeneous IoT platforms. [28]. The INTER-IoT Framework provides a Representational State Transfer (REST) API that exposes interactions to any IoT platform. Developers can then access the underlying IoT platforms through a single interface, thereby mainly focusing on interoperability. Finally, _Eclipse Hono_ provides a container based IoT platform. Different networks can be added by means of protocol adapters. Setting up an instance of _Eclipse Hono_ can be done rather quickly using Kubernetes deployment tools. Devices can be added using an HTTP interface.