IoT & Real Time Activities

The world is the totality of facts, not of things.

Ludwig Wittgenstein

As the so-called internet of things (IoT) seems to bring together people, systems and devices, the meaning of real-time activities may have to be reconsidered.

Real Time Representation (Lucy Nicholson)

Fact and Broadcast (Lucy Nicholson)

Things, Facts, Events

To begin with, as illustrated by marketed solutions like SIGFOX, the IoT can be described as a fast and stripped-down communication layer carrying not so much things than facts and associated raw (i.e non symbolic) events. That seems to cut across traditional understandings because the IoT is dedicated to non symbolic devices yet may include symbolic systems, and fast communication may or may not mean real-time. So, when applications network requirements are to be considered, the focus should be on the way events are meant to be registered and processed.

Business Environments Cannot be Frozen

Given that time-frames are set according primary events, real-time activities can be defined as exclusive ongoing events: their start initiates a proprietary time-frame perceived from the outside as being without duration, i.e as if nothing could happen until their completion, with activities targeting the same domain supposed to be frozen.


Contrary to operational timing constraints (left), real-time ones (right) are set against the specific (i.e event driven) time-frames of targeted domain.

That principle can be understood as a generalization of the ACID (Atomicity, Consistency, Isolation, Durability) scheme used to guarantee that database transactions are processed reliably. Along that understanding a real-time business transaction would require that, whatever its actual duration, no change from other transactions would be accepted to its domain representation until the business transaction is completed and its associated outcomes duly committed. Yet, the hitch is that, contrary to systems transactions, there is no way to freeze actual business ones which will continue to be carried out notwithstanding suspended registrations.

Accesses can be fully synchronized within DB systems (single clock), suspended within functional architectures, consolidated within environment.

Accesses can be fully synchronized within DB systems (single clock), suspended within functional architectures, consolidated within environment.

In that case the problem is not so much one of locks on DB as one of dynamic alignment of managed representations with the changing state of affairs in their actual counterpart.

Yoking Systems & Environments

As Einstein famously said, “the only reason for time is so that everything doesn’t happen at once”. Along that reasoning coupling constraints for systems can be analyzed with regard to the way events are notified and registered:

  • Input flows: what happens between changes in environment (aka facts) and their recording by applications (a).
  • Processing: could the application be executed fully based on locally available information, or be contingent on some information managed by systems at domain level (b).
  • Output flows: what happens between actions triggered by applications and the corresponding changes in the environment (c).

How to analyze the coupling between environment and system.

It’s important to remind that real-time activities are not defined in absolute time units: they can be measured in microsecond as well as in aeons, and carried out by light sensors or by snails.

A Simple Decision Routine

Deciding on real-time requirements can therefore follow a straightforward routine:

  • Should changes in relevant external objects, processes, or expectations, be instantly detected at system’s boundaries ? (a)
  • Could the interpretation and processing of associated events be carried out locally, or be contingent on information shared at domain level ? (b)
  • Should subsequent actions on relevant external objects, processes, or expectations be carried out instantly ? (c)

Coupling with the environment must be synchronous and footprint local or locked.

Positive answers to the three questions entail real-time requirements, as will also be the case if access to shared information is necessary.

 What about IoT ?

Strictly speaking, the internet of things is characterized by networked connections between non symbolic things. As it entails asynchronous communication and some symbolic mediation in between, one may assume that the IoT cannot support real-time activities. That assumption can be checked with some business cases given as examples.

Further Readings

External Links


2 Responses to “IoT & Real Time Activities”

  1. jring281 Says:

    You might find it useful to distinguish between real time and synchronized scenarios. The two guitars in a Les Paul recording were not played at the same time but were synchronized. In many applications a deferred time decision space is adequate so long as the factors therein are all adjusted for the time they occurred and that the delay from event time to data availability time is not too great.

  2. caminao Says:

    Right, that distinction is critical.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: