What is Eclipse HIP?

Eclipse HIP, or the Hierarchical Internet (of Things) Protocol, is a high-level protocol designed to improve the scalability and interoperability of IOT deployments.

Before getting into details of what HIP is, it's worth looking at some of the issues being addressed:

In a traditional, "flat" IOT architecture (i.e. where each device pushes data directly to the cloud), an increase in the size of the deployment means a similar increase in demand for cloud/platform resources). For example, if you double the number of devices deployed, you will need (roughly) twice the bandwidth and compute resources to process the additional data.

The latest Eclipse IOT developer Survey found that data collection and analytics as the #2 most common concern for respondents when developing IoT solutions. This represents a 50% increase from 2017, and improved data processing has always been the main driver behind the HIP project.

With HIP, Aggregators can be deployed locally, on "standard" devices in order to process data in advance of pushing it to the cloud.

Unlike Fog Computing, within HIP this aggregation can:

  • happen on any "standard" IOT device
  • be "chained" to combine multiple data aggregation tasks/processes and distribute the effort across a number of devices
As a result of this aggregation, an increase in telemetry data does not necessarily require additional compute or storage resources in the cloud.

In a typical IOT deployment, all user interactions with the deployment are carried out via centralised, cloud based tools. If the platform is unavailable for any reason, the deployment is essentially offline and unavailable

HIP introduces the concept of local Commanders, which can interact with defined areas of the deployment with no dependency on the central platform.

While the latest Eclipse IOT developer Survey found that interoperability is becoming less of an issue within IOT (ranking as the 5th biggest concern, down from a steady #2 position in previous years), and an encouraging trend towards consolidation in messaging protocols, this is still an area of difficulty for many people developing or deploying IOT solutions

HIP tackles interoperability through the use of handlers, which allow additional functionality (to integrate with third party hardware/software etc.) to be deployed to any device at any time.

Most IOT devices are responsible for transferring periodic telemetry data and/or occasionally interacting with real-world systems. In reality, each of these devices are capable of much more. Rather than utilising the compute power of the devices, cloud resources are used to provide data processing, user interaction and third party integration etc.

By defining a number of different roles which can be deployed to any device, HIP aims to move much of the IOT workload from the cloud to the deployment

At the core of HIP is the device, an abstract representation of an IoT device. Rather than focusing on the physical device configuration, HIP is concerned about how each device can add value to an IoT deployment. HIP achieves this by defining a number of roles which can be deployed and moved across devices.

  • Sensor- to collect telemetry data
  • Controller- to interact with real-world systems
  • Aggregator- to process telemetry data
  • Delegator- to forward commands to individual or multiple controllers
  • Commander- to allow local interaction with Sensors and Controllers without relying on the cloud platform
  • Coordinator- Edge device responsible for all communications into and out of a deployment



While a number of well established solutions, both within the Eclipse IOT Working group and the wider IOT arena, deal with device configuration and management, HIP takes a slightly different approach to devices and treats them as an abstract container for HIP roles.

In other words, HIP is not particularly concerned with the low-level configuration of a device (e.g. the network configuration, routes to messaging servers/brokers etc.) but rather, how the device is used and how it adds value to a deployment once configured and connected.


Sensors collect data about the real-world environment and pass it on to the platform. This could be data about the temperature in a room, the number of units passing through a production line, the number of available spaces in a public car parking area etc.

What's relevant about sensors, from a HIP perspective, is that they can be used to collect a wide range of datasets which need to be processed in a number of different ways. It's important that the HIP protocol does not restrict the type of data that can be collected, or the ways in which it can be processed.


Controllers interact with real-world systems, for example, heating controls, irrigation systems, industrial equipment etc.

Much like sensors, there's a broad and ever increasing range of systems which need to be controlled as part of an IOT deployment, and again, it's important that HIP does not impose any restrictions on what systems can be integrated with and how they can be controlled.


Aggregators are one of the truly unique concepts within HIP.

Aggregators can be deployed to any device at any time and are used to collate and aggregate data from any number of sensors and/or other aggregators and pass this processed data upstream towards the platform. Aggregators can be chained, or stacked, so that you can distribute the data processing workload across any number of devices as your deployment grows.

As with the sensor and controller roles, HIP needs to be adaptable and to support emerging needs in terms of the types of data being processed and the required output from the aggregation function.


Whereas Aggregators collect and aggregate data from the deployment and pass them up to the Platform, Delegators are responsible for receiving commands from the Platform and passing them on to the relevant Controllers.

Like Aggregators, delegators are designed to be chained together, enabling massive scalability by decomposing the HIP deployment into smaller functional units.

Delegators allow a single command/instruction from the platform to generate multiple commands across any number of Controllers. For example, an emergency situation in a production line could result in a command from the platform instructing every controller on the line to shut down immediately.


Commanders act like local implementations of the cloud platform. In reality, they are actually significantly different from the platform in terms of how they work, but we'll explore this more detail as part of the technical specifications.

Commanders leverage both the Aggregator and Delegator roles in order to provide local access to a defined part of the deployment. For example, a HIP deployment in a smart office building could have a controller deployed within each individual office and open plan area within the building, allowing staff to monitor and control their local working environment.


The coordinator is the edge device for the HIP deployment and all communications between the platform and the deployment pass through it

What's relevant about the Coordinator at this stage is that the role can be deployed on to any standard device.