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

Tim Coote <tim+ietf.org@coote.org> Tue, 30 August 2016 12:23 UTC

Return-Path: <tim+ietf.org@coote.org>
X-Original-To: iotsi@ietfa.amsl.com
Delivered-To: iotsi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434FC12D134 for <iotsi@ietfa.amsl.com>; Tue, 30 Aug 2016 05:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coote.org header.b=f7HLHnzr; dkim=pass (1024-bit key) header.d=coote.org header.b=qkUtgcck
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn3hU_uJulsq for <iotsi@ietfa.amsl.com>; Tue, 30 Aug 2016 05:23:40 -0700 (PDT)
Received: from mercury.coote.org (575185b4.skybroadband.com [87.81.133.180]) by ietfa.amsl.com (Postfix) with ESMTP id 289FC127077 for <iotsi@iab.org>; Tue, 30 Aug 2016 05:23:39 -0700 (PDT)
Received: by mercury.coote.org (Postfix, from userid 1000) id 74E4F16C1267; Tue, 30 Aug 2016 13:23:30 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 74E4F16C1267
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1472559810; bh=MWBuwrAMCvdIU/OZZr3hVSII/wTId1dbqnoukKAlUE4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=f7HLHnzrqydK5Sn+UFJlRh5M7N5V+/BKBE25CmcnKKyj4cgymY0yDZE46flgXBuEc NUArk0HDB8gF5SxqwpKmx0bj7DXQRR0D12Ps3n546XBYc7Q30Uef81KJQR3H3MCd+e Z3XG6xWkfUkYwN5JKaOnNQzlQRFX/p3DODAaQqmo=
X-Original-To: iotsi@iab.org
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mercury.coote.org (Postfix) with ESMTP id 46E0D16C10FE; Tue, 30 Aug 2016 13:23:29 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 46E0D16C10FE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1472559809; bh=MWBuwrAMCvdIU/OZZr3hVSII/wTId1dbqnoukKAlUE4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=qkUtgcckZ4HzGETVc+plCgDM/l4IBUlVTSC6RKEqtT//eGdOYk7gvD2aMzlpVeQft 3/eAOZtQvH47PjHqussWaXwEC4FQB8iYNeMTo5IA0vEul5KAdwW+7ukeitSyOnYKPe XDzF13lyFEUMP6EPRaRu8FNJ8mr5HLnXMYYAZ53c=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Tim Coote <tim+ietf.org@coote.org>
In-Reply-To: <49919A41-7CDA-4515-8509-8A93DD11F97B@coote.org>
Date: Tue, 30 Aug 2016 13:23:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B4581BE-EAB1-4106-8A62-7E2D42426912@coote.org>
References: <CA+9kkMCRY6eRF+FgSAm2yE_HdH3i90WYCwxVCUaWM-Drk3kvgQ@mail.gmail.com> <CACp1KyPDYkKcK0u0XZOMbCMQWtyOuR2nnv4w1HMAMTopMVyZew@mail.gmail.com> <ACC85CBE-A2A8-4813-91B5-F8E6F7D409AD@coote.org> <a574ca33-8053-ba9a-443b-fb15234f5c51@cisco.com> <HE1PR0802MB2475ED419A0DD913BCA2DD15FAEB0@HE1PR0802MB2475.eurprd08.prod.outlook.com> <56171746-364d-ec04-44b9-78068f50e6c1@cisco.com> <49919A41-7CDA-4515-8509-8A93DD11F97B@coote.org>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.2104)
X-Spambayes-Classification: ham; 0.00
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotsi/oQZBZT6yZK8ODcfcqjGFmzElqrQ>
Cc: "iotsi@iab.org" <iotsi@iab.org>, David Janes <davidjanes@davidjanes.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Ted Hardie <ted.ietf@gmail.com>, Internet Architecture Board <iab@iab.org>
Subject: Re: [Iotsi] New IoT effort at schema.org
X-BeenThere: iotsi@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet of Things Semantic Interoperability Workshop <iotsi.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/iotsi>, <mailto:iotsi-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotsi/>
List-Post: <mailto:iotsi@iab.org>
List-Help: <mailto:iotsi-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/iotsi>, <mailto:iotsi-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2016 12:23:42 -0000

> On 23 Aug 2016, at 12:26, Tim Coote <tim+ietf.org@coote.org>; 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