# IRONEDGE: Stream Processing Architecture for Edge Applications
## 6 Conclusions and Future Work  
In this paper, a framework guiding architectural designs for nodes in \"Smart Infrastructure\" scenarios was proposed. The framework identifies a set of components/ functionalities that are common across multiple proposals in the existing literature. This framework is named IRONEDGE. A specific use case, related to monitoring rolling stock in the Ferrovia 4.0 project, was presented. This study case covered two limitations on the edge node: (i) limited computational resources and (ii) periods without network connectivity to the Cloud Layer. Following the proposed framework, two architectures were defined for the case study. Both variations followed a pattern, also presented in recent literature, of combining Kubernetes for orchestration and Apache Kafka for the data distribution with a Stream Processing system (Apache Storm for this study case). Both differ in the integration of IoT sensors that use MQTT for message delivery. K0-WC uses Kafka Connect to pass messages from MQTT to Apache Kafka. K1-NC allows Apache Storm to consume messages directly. As a response to Research Question Q3, the two architectures were compared for different Data Report rates. K1-NC offered, for the available computational resources, both overall lower Event loss and lower processing latency. For the K0-WC scenario, the figures showed an almost stable CPU and memory utilization, with a slight decrease in the CPU utilization when more Events were dropped. For this scenario, the optimal number of messages per second was 2000, since it had a higher processing rate than 1000, even with a loss of 16.306%, while the 4000 case had a loss higher than 50%, at 54.888%. For the K1-NC scenario, the figures showed that the CPU utilization had some variations, but not very significant ones. The optimal scenario was 14,000 since the loss of 1.45% resulted in the processing of 13,797 messages per second, a number larger than the 12,000 previously considered. Considering a maximum of a 1% loss of Events received in less than 120 s, the upper limit was set at 12,000 Data Reports per second. K1-NC should be the chosen variation for the study case, with the disadvantage that the internal communication flow became fragmented, with the responsibility of managing the Data Collection from different Data Sources being delegated to Apache Storm. For future work, the authors will mainly consider the need to extend the evaluation that was carried out over the K1-NC architectural variation. In particular, the reliability of using Kafka Mirrormaker v2 as the Event Output component should be evaluated by introducing randomized network faults in the connection between the Edge Layer and Cloud Layer, as well as the effect on latency resulting from the communication protocols used for connectivity with both the Data Sources and the Cloud Layer. As the Ferrovia 4.0 project used as a study case advances the need to evaluate the proposed implementation with multiple Apache Storm pipelines, supporting different sensor types will also arise. **Author Contributions:** Conceptualization, J.P.V., J.S. and N.D.; methodology, J.P.V. ; software, J.P.V. ; validation, J.P.V., J.S., N.D. and M.P. ; formal analysis, J.P.V., J.S., N.D. and M.P. ; investigation, J.P.V., J.S., N.D. and M.P. ; resources, J.S., N.D. and M.P. ; data curation, J.P.V. ; writing--original draft preparation, J.P.V. ; writing--review and editing, J.P.V., J.S., N.D. and M.P. ; visualization, J.P.V., J.S., N.D. and M.P. ; supervision, J.S., N.D. and M.P. ; funding acquisition, J.S., N.D. and M.P. All authors have read and agreed to the published version of the manuscript. **Funding:** This work was supported by the Ferrovia 4.0 mobilizer project, under the grants LISBOA-01-0247-FEDER-046111 and POCI-01-0247-FEDER-046111 from ANI (National Innovation Agency) and by NOVA LINCS (UIDB/04516/2020), LASIGCE (UIDB/00408/2020) and INESC-ID (UIDB/50021/2020) with financial support from FCT (Fundacao para a Ciencia e a Tecnologia) through national funds.