“…We have also identified some limitations, which might be presented as future work, including: (1) resilience to network partitions, as the Redundancy node has no way of finding if there is already a master in the network; (2) most of the nodes still do not support the definition of reasonable margins (e.g., in nodes that deal with timing constrains, a minor delay should be ignored instead of triggering the recover or maintenance action); (3) although its need was identified, no mechanism to synchronize the current system state between different Node-RED instances has been provided, and (4) the capabilities of the DEVICE REGISTRY pattern and device/service discovery are only partial due to the high heterogeneity and lack of standard of IoT systems. Further, current state-of-the-art do not present out-of-the-box solutions for distribution of computational tasks across devices in the heterogeneous IoT system beyond limited (both in scope or supported devices) proofs-of-concept [31], [40], [32], [33], [34], [35], solutions which, if available, would offer foundations for other kinds of fault-tolerance mechanisms beyond the ones presented. Additionally, to be able to validate the correct functioning of our approach, there is the need of a solution that allows one to deliberately provoke failures in the system and report observed behaviours -in cloud computing defined as chaos engineering or fault injection.…”