Re: data streams

Hello Mangus,
>From a device connectivity point of view the Oxford Flood Network is not a mesh. We have and hierarchy of devices, gateways and brokers.
>From a data streaming point of view the Oxford Flood Network is a mesh of device data streams (both sensors and gateways can generate streams) and transforms (entities that subscribe to one or more data streams and can generate one or more output data streams).

I will look into the relevant IETF work so I can better reference this architecture.

All the best,

Edoardo


From: Magnus Olsson <magnus.olsson@ericsson.com<mailto:magnus.olsson@ericsson.com>>
Organization: Ericsson AB
Date: Wednesday, 3 June 2015 09:26
To: Edoardo Pignotti <edoardo.pignotti@nominet.org.uk<mailto:edoardo.pignotti@nominet.org.uk>>, "public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>" <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
Subject: Re: data streams

Edoardo,

Great if it works I have no practical experience myself using the pub-sub for IoT data but understand that there is standards work (in IETF) that could be possible to reference. What is the Oxford flood network, sounds like an Iot mesh?

Br magnus

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

MAGNUS OLSSON

Ericsson AB
Group Function Technology
Mobilvägen 1
22362 Lund, Sweden
SMS/MMS +46 706 756814
magnus.olsson@ericsson.com<mailto:magnus.olsson@ericsson.com>
www.ericsson.com<http://www.ericsson.com>


[Ericsson]



This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
On 2015-06-03 10:19, Edoardo Pignotti wrote:
Hello,
I also agree that streams would be a very useful thing to support in the WoT framework.
I am in favour of a pub-sub broker model. In the oxford flood network we thought very hard how to manage data streams and we went for a pub-sub model.
I would be more than happy to discuss this further in the context of our case-study.

All the best,

Edoardo


From: Magnus Olsson <magnus.olsson@ericsson.com<mailto:magnus.olsson@ericsson.com>>
Organization: Ericsson AB
Date: Wednesday, 3 June 2015 09:04
To: "public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>" <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
Subject: Re: data streams
Resent-From: <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>
Resent-Date: Wednesday, 3 June 2015 09:05

Dave,    (and woters)

Streams sounds like a very useful thing to support :-)

- For the multiple sinks, why not use a pub sub broker as the identified source of the stream that way any number of sinks can attach to that pub-source. Seems to me that setting a proxy output value to point to a single output is a limitation that might result in someone creating an upstream proxy to split to multiple sinks.

Any thing should be able to redirect any aspect of their source (defined by its meta description) to a nearby pub-sub proxy service. Still that could be an "on device" (localhost) broker, a home broker, a service provider broker or a public broker etc.

It seems reasonable to me to have use case such as one part of the stream for the snapshot, another for the live view a third for data analysis, a fourth for a remote tele medicine, a fifth for a emergency monitoring function etc.

- Even discrete value type of sensors could be handled as a stream if only given long enough time to observe

- (Not convinced myself) but perhaps any data points should be allowed to be retrieved as a stream with sometime only a single value being sent before the connection is being terminated.

- If there is a possibility to "cascade" (or chaining) the streamed data points then it might open up for a "network of" data stream functions that could apply smartness to the stream such as adding timestamps (simple sensors do not have timestamps, but sometimes have sample rates), compression, average, de-noising, composite streams.


Thanks!

Br magnus

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

MAGNUS OLSSON

Ericsson AB
Group Function Technology
Mobilvägen 1
22362 Lund, Sweden
SMS/MMS +46 706 756814
magnus.olsson@ericsson.com<mailto:magnus.olsson@ericsson.com>
www.ericsson.com<http://www.ericsson.com>


[Ericsson]



This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
On 2015-06-03 09:16, Dave Raggett wrote:
I am interested in enabling the Web of Things Framework to handle data streams.

Some sensors produces streams of data as a function of time. Data streams can carry one or more data channels where each channel is a single number or a vector.

An example would be an electrocardiography (ECG) sensor which is used to produce a waveform of the heart's activity over a time period of up to a few seconds (see attached image). In a hospital the sensor and display are connected together with electrical leads.

In the Web of Things, the sensor and the display are both modelled as "things". In place of leads, we set the sensor's output property to the display. The display could be an object in a web page script that displays the waveform using the HTML CANVAS element, or it could be a remote service, e.g. a device that acts as an oscilloscope. The display could have properties that control its behaviour, e.g. how many seconds of data to show. It could also have actions, e.g. to freeze the display to allow a waveform to be studied in more detail.

Script developers ony need to know the object model for the sensor and display. The details of the underlying protocols are dealt with automatically by the server platform. For this to work, we need a standard way to describe data streams as part of the data model for "things".

For a simple thing property, e.g. the state of a light switch, setting the value of the property on the proxy results in the server sending a message to update the physical state of the switch. For streams, the semantics is slightly different. Setting the value of the proxy's' output directs the data stream to the designated object.

This model assumes that a stream can only be sent to a single data sink.  If you want to have multiple sinks, you will need to use a "thing" that acts as splitter. In principle, the thing acting as the sensor could do this, e.g. providing one output for a data logger, and another for a display.

p.s. I am planning on implementing this as part of the NodeJS server project on GitHub. By the way, there are several examples of how to create an ECG monitor with Arduino’s if you want to build your own.

—
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>


[cid:part6.03040104.00020909@ericsson.com]