# IRONEDGE: Stream Processing Architecture for Edge Applications
## 3 Proposed Architectural Framework  
For Research Question Q1 and to develop an architecture that can be easily adapted to different use cases while remaining comparable, we developed a framework named IRONEDGE. Following the current design practices for distributed processing in \"Smart Infrastructure\" scenarios ([PERSON] et al., 2016; [PERSON] et al., 2016; [PERSON] et al., 2016), we identified the need to split the work over a number of nodes in an Edge Layer. Thus, a number of common capabilities should be present in every node of the Edge Layer. This set of capabilities is combined to define the common data flow in the edge node and generically identified as:  
1. The capability to collect data from Data Sources, the Data Collection;
2. The capability to execute processing over the collected data, the Stream Processing;
3. The capability to store some local state, the Local Storage;
4. The capability to replicate obtained results, an Event Output;
5. The previous capabilities are supported by an interconnecting layer allowing for message passing between components, an Asynchronous Messaging Middleware. Consider Figure 2, which represents the logical architecture of the components offering the listed capabilities, for a single IRONEDGE node. \begin{table}
\begin{tabular}{l l l l l l l} \hline \hline
**Paper** & **Local** & **Orchestration** & **Edge** & **Stream Processing** & **AMM** & **Limited Computing** & \
\begin{tabular}{l} **Intermittent** \\ **Connectivity** \\ \end{tabular} \\ \hline [PERSON] et al. (2019) & No & Yes & No & No & No & No \\ [PERSON] et al. (2010) & No & Yes & No & Yes (MQIT) & No & No \\  & & & & & Yes (Only latency. \\ [PERSON] et al. (2012) & Partially & Yes & Yes (Apache Storm) & No &
\begin{tabular}{l} Offloads to mobile \\ devices) \\ \end{tabular} & No \\ [PERSON] et al. (2010) & Yes & No (Adaptable) & Yes (Apache Flink) & Yes (MQIT/Apache \\  & & & & Kafka) & Partially (only cluster) \\ [PERSON] et al. (2014) & Yes & Yes & No & Yes (Apache Kafka) & Partially (not evaluated) \\ [PERSON] et al. (2015) & No & No & Yes (Apache Storm) & Yes (Apache Kafka) & No \\ [PERSON] et al. (2016) & No & No & Yes (Apache Storm) & Yes (Apache Kafka) & No (performance for cloud scenario) & No \\ [PERSON] et al. (2017) & No & Yes & No & No & Partially (only cluster) & Yes \\ [PERSON] et al. (2016) & No & Yes & No & No & Partially & No \\ \hline \hline \end{tabular}
\end{table} 
Table 1: A summary of papers that were considered in the Related Work Section. Under this framework, each IRONEDGE node is responsible for a variable number of Data Sources and will act as the first layer for the aggregation and processing of data, before transmissions to the second layer. This corresponds to the middle layer (the edge/fog nodes) in Figure 1. Each Data Source may be either some Internet of Things (IoT) device or some other element capable of interfacing with the chosen Data Collection implementation. In the IRONEDGE framework, a single message containing data from a single source is designated as a Data Report. The capabilities offered by the Data Collection component are the first step in the flow of data, allowing for the collection of data from the corresponding Data Sources. The Data Reports are to be delivered to the Stream Processing component. This second component is the central component of any implementation of the framework and is responsible for the extraction of knowledge from the gathered Data Reports. The extracted knowledge resulting from a set of Data Reports is designated as an Event. A generic pipeline for processing Data Reports into Events is presented in Section 3.1. An Event Output component implements the interface in some secondary layer, generally assumed to be a Cloud Layer. This Cloud Layer may offer long-term storage, further enrichment and processing by aggregating Events from multiple IRONEDGE nodes, as well as propagating alerts resulting from the Events.