Plotting to rule the IoT via graphs

IoB Insiders Clive Longbottom, analyst at Quocirca, makes the case for using graph databases when dealing with increasingly complex IoT platforms.

At a high level, the IoT is predicated on a reasonably simple set of rules. By using ‘if-then-else’ constructs, the operations of the IoT can be managed quite successfully.

For example, consider a system where a thermistor is monitoring a system with a valve allowing for cooling. A script along these lines is enough to create a simple but effective rule:

IF TEMP>22 THEN open.cooling ELSE do.nothing

The problem then becomes how complex the IoT can make such rules.

Back to our example: that thermistor is constantly monitoring the temperature. The temperature must be maintained between 20°C and 22°C. It is one of ten different thermistors monitoring different parts of the environment. There are both heating and cooling systems in place.

Even at a simple level, the script now becomes something along the lines of:

IF TEMP<20 THEN open.heating ELSE IF TEMP>22 open.cooling ELSE do.nothing

But this, in itself, is too simplistic. There are no loopbacks as to when the heating or cooling should be shut off; no checks to see if the thermistor is malfunctioning through checking the other nine thermistors to see what their readings are.

Tackling complexity

As the complexity of the IoT environment itself builds up, it becomes apparent that simplistic rules engines are ill-suited to the job. Responsiveness to real-time events will suffer; the probability of errors creeping in via poor rules creation and management becomes more of an issue.

Instead, it makes sense to look to a more modern approach of using something like a graph database. Graph databases (as described in this article) are a means of creating a fast mechanism of identifying and using relationships between different objects.

Within the IoT, this can then mean that the thermistors, cooling and heating valves all become ‘nodes’. Each node will have ‘properties’ and the nodes link to each other via ‘edges’, where each edge describes the relationship, and therefore a conduit for actions, between nodes.

So, the thermistor can have properties that define the upper and lower limits of the temperature it is monitoring. The linkage it has to the cooling and heating valves are based on whether the temperature it is measuring is over or below the limits defined in its own properties.

The heating valve node is watching what is happening over the edge. It has its own properties, which tell it how far to open when it observes an under-temperature event on the edge from the thermistor node, and for how long. It can also have properties that tell it whether it should poll other thermistors or not based on whether the data from a single point is deemed sufficient or not.

The cooling valve node can understand that there is little point in it opening if the heating valve node has just completed a cycle of its own: the heating may have overshot its target, but may well become back into target within a short while.

Super nodes

Another node may well be a full centralized monitoring system. Each of the small nodes may well have their own edges that join to this node, or they may be aggregated as more complex systems into a ‘super-node’. For example, a super-node could be defined that includes all the thermistors, heating and cooling valves and any other IoT objects that make up the system under consideration.

Within this super-node, the properties may well define that as long as everything is under control – even if the heating and cooling valves are opening and closing quite often – the central monitoring system does not need to be informed of what is happening, or at best be told that everything is OK. Only when the super-node properties identify that it is no longer within its own limits of operation (or is trending that way) does the central monitoring system need to be informed – which can then take appropriate action via its own properties and edge actions to other nodes.

Via these means, the rules become far more item-specific. IoT administrators can focus on each item and the job that it is meant to carry out, rather than attempting to create end-to-end scripts that become unwieldy.

Read more: IoB Insiders: Planning for the IoT

Pattern-matching approach

The prime benefit of a graph database is that it operates on a pattern-matching basis – it does not care as to how complex or large the node constructs are. It does not have to search through every item to see what it needs to do – it disregards everything that is not related to what it needs, focusing only on what is relevant. Graph databases are therefore ideal for dealing with the real-time nature of IoT environments.

This approach also makes graph databases ideal for dealing with IoT platforms that span across multiple different organizations. Through managing the properties and edges correctly, personal identifiable data (PID) can be put into the ‘not relevant’ area, so that one organization’s IoT system can interrogate and work with another’s without fear of breaking the upcoming GDPR or existing Privacy Shield rules.

Those who want to look at graph databases could consider options such as open source systems such as OhmDB, Titan or Arly. Commercially supported examples come from the likes of Neo4J, Stardog, FactNexus’ GraphBase or IBM’s System G Native Store.

Overall, for those looking to implement an effective IoT platform that is able to scale, start with planning a workable base architecture as laid out in an earlier article, and then plan as to how a graph database can be laid across this to provide the capability to ‘rule’ over it.