[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-iwg] Eclipse M2M IWG Topic Space Design Thoughts (James Branigan)
|
James,
Thanks a lot for the suggestions.
I probably should join some of these calls, too, similar to regular STEM conference calls or others.
As mentioned in reply to Benjamin's questions, the UCUM standard is format neutral, so whether XML, CVS, JSON or any other format was used, it is highly advisable, to not just manage the "refrigeration unit", but also the temperature unit appropriately when exchanging such messages.
While UCUM is most widely spread across Healthcare-related M2M and Interoperability, it is certainly not limited to this industry. And examples like this show, other industries also use or consider it:
https://marinemetadata.oceanobservatories.org/references/ucumunits
Or SensorX: http://www.sensorx.net/template.php?subject=ucum
US institutions NOAA, NMFS, SWFSC and ERD offer a useful code converter, thus they prefer UCUM, too:
http://coastwatch.pfeg.noaa.gov/erddap/convert/units.html
There are many more cases, e.g. German Weather Stations and Data Providers, etc.
Unfortunately even Wikipedia is more content-intensive in German. Please excuse the language, important here is the list of standard bodies, that either mandate or at least highly recommend UCUM:
http://de.wikipedia.org/wiki/Unified_Code_for_Units_of_Measure
Another example from Fraunhofer about Smart Home for Care of Elderly people:
http://www.hessen-it.de/mm/mm001/iTEC10_Wichert_Fraunhofer-Allianz-AAL_Selbststaendig_im_Alter.pdf
Coast Watch example shows, that ideally a Unit Code System like UCUM, UDUNITS or others should be named somewhat similar to this:
<value value='1.77' unit='m'>
<translation value='69.7' code='[in_I]'
codeSystem='2.16.840.1.113883.19.6.8' codeSystemName='UCUM'/>
</value>
This Sensor Web Service Call example also recommends UCUM, and I believe it could be of use to this thread:
http://52north.org/communities/sensorweb/ses/0.0.1/index.html
At least in the Location IWG, I also assume, the governing institution OGC or other members like GeoAPI are getting involved with Eclipse IWGs. Sensor Web is probably a good case for M2M, as well.
This page about Ontology http://forge.morfeo-project.org/wiki_en/index.php/Units_of_measurement_ontology
has further examples to represent measurement values
#nokia70 :weight [
:numericalValue "0.130" ;
:measuredIn ucum:kilogram
]
MUO makes sure, to handle the code system, in this case always UCUM, as well.
GE Standards and HL7 guy (previously working on OHF, too) Keith Boone pointed to a handy UCUM for Electronic Messaging resources at LOINC/Regenstrief: http://motorcycleguy.blogspot.dk/search/label/UCUM
It also shows, that other code systems where used (like ISO) should be clearly named to avoid misinterpretation in any case.
Regards,
Werner
> ------------------------------
>
> Message: 3
> Date: Mon, 3 Sep 2012 22:02:00 -0400
> From: James Branigan <jb@xxxxxxxxxx>
> To: rick.bullotta@xxxxxxxxxxxxx, m2m Industry Working Group
> <m2m-iwg@xxxxxxxxxxx>
> Subject: Re: [m2m-iwg] Eclipse M2M IWG Topic Space Design Thoughts
> Message-ID:
> <CAL7OdBB7D=rFv3MRAAAP3Zxe5qMwAX0Gk1skM2cXoHcgkUHY_A@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Rick,
>
> Thanks for the quick feedback. I've thrown some quick thoughts together
> in
> response to your note:
>
> I define my own set of verbs and semantics for the applications that my
> company fields. I'm very strict that they are followed so that we can
> make
> use of the tight semantics in other parts of the network.
>
> The "traditional" HTTP REST semantics are a bit tricky. One of the key
> selling points of MQTT over just using HTTP is the unsolicited report. In
> my systems a READ results in a REPORT. REPORT messages are also produced
> in an unsolicited manner by the source client. An HTTP GET would map to a
> READ with a REPORT payload in response. But if you restrict yourself to
> HTTP, you end up with no verb for the unsolicited report. You can invert
> the client server relationship (ala Modbus), but you get the same problem,
> only with the READ request instead of the unsolicited report. In the end,
> I decided that its important to provide a true representation of the
> interactions and not try to artificially map them to HTTP.
>
> In terms of payload, I use a data model for my systems, which I can render
> in XML, JSON, CSV, etc. By forcing some simple constraints on my
> developers, I can ensure that the transformations are mechanical and don't
> require any hand coding. This approach helps a ton for interop. I agree
> that discovery is a key feature. If you built in discovery in the zeroth
> case, then you get install/uninstall/upgrade of sensors for free. If you
> were to alternately assume apriori knowledge of the configuration, then
> you
> end up having to handle install/uninstall and upgrade individually.
>
> Regards,
>
> James
>
> On Mon, Sep 3, 2012 at 9:44 PM, Rick Bullotta
> <rick.bullotta@xxxxxxxxxxxxx>wrote:
>
> > Good stuff, James.
> >
> > A few questions/comments:
> >
> > Does the current MQTT protocol (and current implementations) support
> many
> > of these verbs? Notably, a demand-based read or write, metadata, and
> list?
> >
> >
> > It may be desirable to also overlay "traditional" (quotes intentional)
> > REST semantics using HTTP methods as an alternative to including the
> Verb
> > in the URI.
> >
> > Obviously some consistent representation of the payload and it's
> semantics
> > would be essential for interoperability and discovery. It would be
> useful
> > to explore those use cases and some examples.
> >
> > Best regards,
> >
> > Rick Bullotta
> > ThingWorx
> >
> >
> >
> > On Sep 3, 2012, at 9:34 PM, "James Branigan" <jb@xxxxxxxxxx> wrote:
> >
> > Hi everyone,
> >
> > I had a todo from one of the previous M2M IWG calls to write-up some of
> my
> > experiences with topic space design. I've based the example topics
> below
> > on our M2M Scenarios that describe a grocery store refrigeration unit.
> >
> > Please let me know if you have any questions.
> >
> > Regards,
> >
> > James
> >
> >
> > *Eclipse M2M IWG Topic Space Design Thoughts*
> >
> > Within an MQTT design space, there are issues related to topic space
> > design. This is not a unique concern for MQTT, in fact HTTP has already
> > been through many of these issues with URL design. One way to think
> about
> > MQTT and HTTP is as follows: The difference between MQTT and HTTP is
> > directional: MQTT is to HTTP as PUSH is to PULL. SOAP and REST both use
> > very different design styles on top of HTTP. Both styles are also
> possible
> > in MQTT topic space design. The following topic space is more aligned
> with
> > a REST style design. It has relatively few verbs and is organized
> around
> > resources, which provide representations for the sensors, actuators and
> > devices.
> >
> >
> > *Simplistic Topic Space Design Template*
> >
> > /{verb}/{route-to-device}/{unique-sensor-actuator-id}
> >
> > Example Topics:
> >
> > A request for the latest temperature value for zone 1 of refrigeration
> > unit 13 at store 123.
> >
> > /READ/store/123/refrigeration-unit/13/zone-1/temperature
> >
> >
> > A report of the latest temperature value for zone 1 of refrigeration
> unit
> > 13 at store 123.
> >
> > /REPORT/store/123/refrigeration-unit/13/zone-1/temperature
> >
> >
> > A request to set the set-point for zone 2 of refrigeration unit 2 at
> store
> > 456.
> >
> > /WRITE/store/456/refrigeration-unit/2/zone-2/temperature-set-point
> >
> >
> > A request for all meta-data for zone 2 of refrigeration unit 2 at store
> > 456.
> >
> > /META/store/456/refrigeration-unit/2/zone-2
> >
> >
> > A request for all sensor and actuator ids for a refrigeration unit 2 at
> > store 456.
> >
> > /LIST/store/456/refrigeration-unit/2
> >
> > One of the first things you notice is that I've added the VERB in all
> caps
> > as the first segment. This is by convention only. Next I have a
> > multi-segment path that provides addressibility to the device in
> question.
> > In these examples that is a refrigeration unit. Finally, I have
> > multi-segment path that provides addressibility to the unique sensor and
> > actuator in question. Multiple paths to the same device is a more
> advanced
> > topic and not shown here. By limiting the verbs in use and defining
> tight
> > semantics, it is possible to construct processes that bridge brokers and
> > provide additional services(proxy servers, data historian, etc).
> >
> >
> > *Payload Format*
> >
> > The payloads are not shown, although I highly recommend something
> > programming language neutral. Please do not directly serialize Java or
> C#
> > objects, you will regret it later. XML can be very heavy-weight for
> > embedded devices to process. I often use CSV or JSON for payloads when
> > dealing with embedded systems. A translation client can be used to
> > rebroadcast after turning XML into CSV/JSON and CSV/JSON back into XML
> if
> > necessary for enterprise integration.
> >
> >
> > *Advanced Topic Space Design*
> >
> > There are many other best practices for multi-reads, multi-write,
> > meta-data update, dynamic sensor and actuator installation/removal, id
> > claiming, admin features(log retrieval, firmware flashing, etc.). These
> > are explicitly left out of this note in order to avoid distracting from
> the
> > most simple operations.
> >
> > As I mentioned above, please let me know if you have any questions or
> > comments.
> >
> > --
> > James Branigan
> > jb@xxxxxxxxxx
> > Partner, Band XI International, LLC
> > http://www.bandxi.com
> > 919 656 4691
> >
> > _______________________________________________
> > m2m-iwg mailing list
> > m2m-iwg@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/m2m-iwg
> >
> >
> > _______________________________________________
> > m2m-iwg mailing list
> > m2m-iwg@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/m2m-iwg
> >
> >
>
>
> --
> James Branigan
> jb@xxxxxxxxxx
> Partner, Band XI International, LLC
> http://www.bandxi.com
> 919 656 4691
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20120903/6b443267/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> m2m-iwg mailing list
> m2m-iwg@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
>
>
> End of m2m-iwg Digest, Vol 11, Issue 3
> **************************************
