Tuesday, 7 January 2014

IoT Rules: Event->Action versus State->State

A core difference between the Object Network approach to the IoT and every other that I've seen is in its programming model.

The Event-Action Programming Model

Other rule systems - or programming models within existing languages such as Javascript - are based on the Event-Action approach. This starts with an event, possibly coming from a subscription, such as "light level is now low", "owner is nearly home", "someone has entered the room", "switch has been turned off", "room is too hot", "it's turned night time", and so on. The rule matches such an event, then triggers an action: "turn on the light", "turn on the heating", etc.

This style is very simple and obvious, so does allow non-programmers to create rules quite easily.

However, it is very fine-grained, limited to simple parameters and actions. It very quickly hits a limit for more interesting programming of behaviour.

Having to model every input as a specific event, and every output as a specific action is not just low-level, but also highly prescriptive - your rules say "exactly in this case, you must do this".

In an environment of large numbers of independent but (hopefully) co-operating components, this can be a brittle model.

These approaches compound this because they usually have a central controller that expects all entities around to become slaves. Sometimes that controller is even outside of your own network.

The Object Network Programming Model

The Object Network programming model is more general and broad, and allows each Thing or object in the system to have complete autonomy.

In the Object Net, instead of events you have observed states, which may be complex descriptions of the whole of a Thing's current state, or even the current state of many linked Things, in your house or on the public Internet. Instead of actions you have new states for objects. Those new states may in turn be observed by other Things.

It is also a simple programming model, but a much more powerful one.

Every Thing or object is responsible for its own state, which depends on the state of other Things or objects around it, that it has links to:

When a light decides to observe a switch, it can set its own state to "on" when the switch's state is "on". Several lights could observe that switch state, or another state, and come on at the same time. Or another light can observe the first light and other lights around and set its own light levels to match them, or perhaps match their colours. The heating and lighting can observe the time of day and behave differently to other states of Things they are observing. A heater may refuse to turn on if some other state it is aware of, or rule it is following, is overriding it. A light can scan around to see if there's a light-level sensor that it can react to.

Nothing is run centrally, so Things and objects in the network just interact at their own pace and according to their own rules. Rules and states can be more like intentions than commands, allowing a more loosely-coupled federation of intelligent and interacting Things.

Further, much more context and surrounding state can be taken into account at once in those rules, because the rules have the entire local and global Object Network before them, on which to base their state transitions.

No comments:

Post a Comment