Eclipse HIP

Through HIP, localised processing or preperation of data is intended to reduce the connectivity and central processing requirements within IOT - much like the contemporary Fog computing paradigm, but without the need for sophisticated edge computing solutions. 

Base Device messages enable core functionality supports each "thing" in a deployment, with additional roles being configured through Configuration messages, and functionality enabled through Handler messages and files

In the above diagram, we have a very small and simple deployment (left of the dashed line) connected to the Platform on the right. Looking at the dashed line, all communication between the deployment and the platform is via a Coordinator on the deployment side [ CR ] and the Coordinator Link [ CrL ] on the Platform side, alllowing us to isolate other devices from the Internet.

The Orange Flow in the diagram is a command sent by a user to a particular actuator or controller (e.g. turn lights on/off), the blue flow represents data collection and aggregation across the deployment.

[ D ] - these are HIP enabled devices and can have a number of different roles which are described below. 

[ S ] - Sensors -  can be local sensors (e.g. temperature/lighting sensors connected to the GPIOs) or external, third party devices. Handler files are deployed onto the device to integrate with particular sensors and process telemetry data (e.g. read from a GPIO, make a REST call to an Arduino) - the use of handler files is intended to improve integration and interoperability.  

[ C ] - controllers, similar to Sensors, these can be directly connected or external - e.g. relays connected via USB or RF transmitters connected to the device to control lighting and heating/air con. - similar to sensors, the use of handler files is intended to improve integration and interoperability

[ A ] - Aggregators - the device configuration includes details of the MQTT topics to subscribe to (i.e. telemetry data from sensors or output from other aggregators) and publish aggregated output on. Handlers deployed to the device implement the operations to perform on the data (eg. read data from multiple sensors via subscriptions, process it and publish the output on a particular topic). For example, the Sensors connected to the aggregators in the diagram could all be temperature sensors - the first aggregator could compute mean, min and max temperatures for an open plan office, based on the readings from relevant sensors and the next aggregator could calculate the average temperature for a floor/building etc. Telemetry data from sensors can be subscribed to by any number of aggregartors, allowing the same data to be processed in multiple, independent ways.

[ B ] - Delegators (renamed from brokers as they could be easily confused with MQTT brokers) act as intermediaries between the platform and the controllers - so the delegator in the diagram could control all the lighting/heating controls for the open plan office. Delegators also allow multiple controllers to be included into the same command (for example, a "scene setting" command could manage or adjust lighting, blinds and AV equipment in a meeting room during a presentation/video-conference etc,). Delegators also allow other local devices (commanders, not in diagram) to interact with local controllers without having to interact directly with the platform

[ CR ] - Coordinator - essentially this is the edge device for a deployment - single point in and out of the deployment and the only local device which can communicate with the platform. In the event of a failure, this role can be moved to another device without the need for any sort of hot spares etc.

On the platform side, there are three main components, but in a practical implementation, these can be subdivided or combined.

[ CrL ] - Coordinator link - this sits between the core platform and the deployment and coordinates messages between the deployment and the platform (readings from the deployment and commands from the platform etc.)

[ P ] - this is the core Platform functionality and uses a combination of MQTT to communicate with the Coordinator Link and REST service and web-scokets to integration with client facing solutions

[ UI ] - this is any user facing solution.

[ DM ] - this is just a shared data layer used by both the platform and the Coordinator Link. It has no relevance in terms of the protocol, but is included here for completeness

Scalability is achievable through a hierarchical architecture whereby data collected from sensors can be processed and aggregated locally before being transferred to a central (cloud or on-premise) platform. Any device can be assiged the role of an "Aggregator" - allowing it to summarise, aggregate or otherwise process data from relevent sensors or aggregators so that the platform receives a single message with all the relevant readings (if desired) in addition to the processed output data. For example, rather than collecting and processing data from multiple sensors in an open plan office-space, HIP can transmit a single message summarising all the relevant data and store this without the need for further processing. In contrast to this, traditional IOT solutions tend to have a flat structure, whereby each sensor feeds raw data to the platform for subsequent, centralised processing.

Management is supported through the use of Health and Configuration messages. Roles such as "Aggregator" or "Controller" above can be assigned and configured centrally from the central platform UI. The "Health" messages update the central platform with the status of each device - allowing administrators to remove roles for under-provisioned devices based on their CPU or memory utilisation. For example, an Aggregator role could be moved from one device to another under-utilised device automatically from the central platform without the need for direct access to the relevant devices.

In addition to the protocol specification, a partial NodeJS implementation of the protocol is available across a number of GitHub repositories:

Platform: This is the main component within the ecosystem and is responsible for the vast majority of logic and control within HIP - it provides REST APIs for client (UI) solutions as well as websockets notifications and also communicates with the Coordinator-link via REST APIs and MQTT messaging

Device: This is any "Thing" deployed as part of an IOT installation, Any Device can have one or more of the following roles and all communication is via MQTT. 

• Sensor - this is a local sensor (e.g. DHT 22 for temperature and humidity), or a remote device which is not HIP compatible. Invidivual handlers (e.g. JS file or Kura Bundle) can be deployed from the Platform to enable  the Device to integrate with the Sensor and forward readings on a poll or event-driven basis.
• Controller (actuator) - Similar to Sensors, this can be a local or remote actuator and handlers can be deployed from the platform to enable integration. A collection of commands and their parameters are maintained on the Platform and can be pushed to local Commanders to enable local control/integration
• Coordinator - this sits on the edge of a deployment/installation and acts as a single point of contact bwtween the deployment (the Things) and the Platform
• Delegator - Commands from the platform or a local Commander can be routed through one or more Delegators. Different paths/rules etc. can be managed by the Platform and custom handlers deployed on the relevant device
• Aggregator - Multiple Sensors can have their readings forwarded to one or more Aggregators and aggregator handler s can process that data locally before forwarding the output to the Coordinator and/or one or more additional Aggregators. For example, an open plan space in a large office may have a number of lighting/temperature sensors, in addition to uploading the individual readings, these can also be collated by an Aggregator to give a summarised view of the data - e.g. the temperature on the first floor or the ambient light levels on th easterly aspect of the building.

Coordinator-Link: This is an MQTT based solotion which is deployed between the Platform and the deployment (accessed via the Coordinator role on a specified device)

UI: this is a responsive frontend for the solution built in Angular and includes functionality for both administrators and end-users. The UI (and derrived Cordova apps) communicate directly with the Platform

Commander: this is (or will be) a standalone UI which communicates with the local Coordinator rather than the Platofrm in order to monitor associated Sensors and control associated Controllers

To date,  a significant portion of the functionality has been developed  - sensors can push data, via Aggregators and the Coordinator to the Platform and the Coordinator can accept MQTT messages and route them to the relevent controller/actuator. A number of additional components are under development (e.g. "health and status" messages from devices which will simplify the optimisation and role allocation across a deployment. The development of other elements, e.g., particular UI controls for viewing device and sensor status has not begun yet