Re: [Iotsi] New IoT effort at schema.org

[Tim Coote <[e-mail]>]

> On 23 Aug 2016, at 12:26, Tim Coote <[e-mail]> wrote:
> 
> Hullo
> 
> I’ll write up a simple example later today to illustrate the sorts of issues that I’m trying to describe.

Sorry, "Planning Fallacy".

My intention here is to highlight that key aspects of devices do not relate to the obvious AD and DA conversions to and from the real world.  Encoding the simple measurements and controls that a sensor/actuator handles may, IMO, give the impression of a more complete solution than such encoding can handle. The easy answer may just be to note the gap.

Let’s take something to control the environment of the home to keep it comfortable without wasting energy. For simplicity, I’ll just describe one dimension: keeping it warm enough, and ignoring location prediction, etc. Such a system has sensors (thermometers t[1-n]), which may be located in fixed places or be moved around. Let’s call this system Homes.

Some of the h/w thermometers may be composed into what I’d call Synthetic Things (st[1-m]) which measure the temperatures of the living spaces using some integration of the individual hardware components. (e.g. harmonic mean of the reported temperatures within each room).

There will also be at least one actuator to turn on the heating (a[1-n]).

If the designer’s smart, the UI to the state of the system will be maintained in one place and made rendered on a phone or similar. Part of the UI is also the living environment (are the radiators on? Does it feel comfortable, etc). More typically, the UI also extends into wall based thermostats with embedded systems. Such a model often confuses end-users as it tends to give inconsistent information depending on the channel. The attractiveness of this anti-pattern is that the devices can be easily sourced and will work stand-alone.

The digital interface to all actuators and sensors is a low power, high latency, meshed network with 6LoWPAN mapping (PHY1). [this assumes that the application level aspects of most such networks are ignored in favour of enabling device interoperability]

A typical system like this would have one application for controlling the temperature, configured and used by, say, a million homes, with 1.5M users. Configuration would include providing the metadata on device disposition and a model of the home.  The typical commercial model has no direct relationship between makers of t[1-n] and the application that controls the home.

The types of issue that I’m concerned about include:
- standardised approaches to associating t1 - tn with the network, so that the system and the user have the same view as to which is which
- when t2 gets a firmware update, the change to this Configuration Item [in the ITIL sense] is not reported by t2. However, the behaviour of t2 does change.
- when the user introduces tn+1 using an off-the-shelf product from the hardware store, it declares that it’s the same as some recognised thermometer. But it isn’t and behaves oddly.
- introducing tn+1 changes the behaviour of PHY1.
- st1 has to understand how current the values reported to it are and to spot gaps so that it can raise alarms if one of the t’s that it is taking input from has disappeared. Such reports and timeliness need to be consistent across all components that are listening to each t (or st).
- changes in the house change the timings of PHY1, so the expected behaviours of PHY1 need to be codified.
- the vast variation of numbers and timing variations of devices need to be handled consistently and tested for by the application, and the application must have some awareness of to what extent each in-home configuration has been tested.
- calibration variation between physical thermometers, including how they are positioned for measuring a temperature.

hth

Tim