Lightning-rod

Stack4Things is a framework for the Internet of Things developed by the Mobile and Distributed Systems Lab (MDSLab), a workshop of the Engineering Department of the University of Messina. Stack4Things is an open-source project that helps manage IoT fleets without worrying about their physical location, network configuration, underlying technology. This is a Cloud oriented horizontal solution (which can be integrated with OpenStack) that provides the virtualisation, personalisation and orchestration of IoT objects. Stack4Things provides an out-of-the-box experience on several of the most popular embedded and mobile systems.

Stack4Things involves two main components: the IoTronic service and the Lightning-rod probe. IoTronic is the Cloud-side service that enables users to manage IoT resources. Lightning-rod is the IoT-side probe that acts as the IoTronic counterpart connecting the device to the Cloud. Both components are implemented in Node.js. Stack4things in its standalone version is only partially integrated with OpenStack (can use the Neutron service as back-end for network management). This version has been implemented mainly for search purposes. A draft web dashboard is also available for the standalone version.

Stack4Things is an IaaS dedicated to the IoT capable of displaying REST API enabling the management of IoT devices named within the framework as ‘board’. The structure of this system is in line with that of the services developed within OpenStack, which can be interfaced for its operation. The architecture of the system focuses on communication between users and IoT nodes. The system is characterised by two entities S4T IoTronic (the Cloud part of the infrastructure) and S4T lightning-rod (IoT side of the infrastructure). This system enables various actions to be carried out to manage IoT devices, such as:

● Board management – recording, deleting, sending commands —

● Plugin – inject custom code pieces to be carried out on the Board

● Services – Enabling to access services installed on a Board

● Virtual Network – organising internal networks between boards

● Web Service – Example http services on the Boards in a secure way with encription e2e

In particular, the system on the board side performs directly on the MPU and interacts with the instruments of the Ordinary Supplement and the board’s services, i.e. it will have access to the sensors and actuators provided by the device via the I/O. Lightning-rod PinS, representing the point of contact between the card and the Cloud, allowing the user to pilot the card even if it is placed behind a very restrictive firewall or a Natting system. Communication is ensured through WAMP. The Cloud side side, which we have said to be Stack4Things’s IoTronic service, is implemented according to OpenStack service standards, in order to provide the possibility of operating one or more remote IoT devices.

The IoT side architecture requires the device to operate as an OO on the BaTHOS MCU, while the MPU side is assumed to have a distribution from OpenWRT (or at least a UNIX-like S.O.). BaTHOS, thanks to the extensions indicated as MCUIO, will be able to display the digital – analogue – I/O pins to the SO operating on the MPU. Communication in the system is managed through several serial buses. In addition, the functionalities provided by the kernel modules related to MCUIO include pin enumerations as well as the export of corresponding I/O handlers as i-nodes of the virtual file-system sysfs. Above sysfs abstraction, which is in line with common recruitments on filesystem UNIX-like, there is a need to mediate access by means of a set of bookshops inspired by MCUIO, namely the sysfs libraries of Stack4Things MCUIO. These bookshops represent the interface with the file-system sysfs MCUIO, which handles requests for reading and writing in terms of competition. This is done at the right level of semantic abstraction, i.e. by blocking and releasing resources based on bookings and in a way that depends on the requirements stemming from the typical behaviour of I/O pins for general use and other specific requirements for sensing and actuating resources. Lightning-rod engine is at the heart of this part of architecture, since it interacts with the cloud through connections to a specific WAMP router through communications on Full-duplex channels that send and receive data from the cloud by performing commands from Cloud users. Communication with the Cloud is ensured by a number of bookshops that implement the client side functionalities of the WAMP protocol (WAMP Stack4Things libraries). In addition, a WebSocket library set (Stack4Things wstunnel library) allows the engine to act as a WebSocket server reverse tunneling by connecting to a specific WebSocket server running on the Cloud. This allows internal services to be directly accessible by external users through the WebSocket tunnel whose incoming traffic is automatically forwarded to the internal daemon (e.g. SSH, HTTP, Telnet) considered. The outgoing traffic is redirected to the WebSocket tunnel and eventually reaches the end user who connects to the WebSocket server running in the Cloud to interact with the card service. The Stack4Things lightning-rod engine also implements a plug-in charger. Customised plugins can be injected from the cloud and executed on the plugin charger to implement specific user-defined commands, possibly including system-wide interactions, e.g. with a package manager or runlevel management subsystem.