| Re: [m2m-iwg] M2M meta-model |
|
Hi, Benjamin.
A couple quick comments:
Regarding date/time, I think support for a finite set of representations (milliseconds, nanoseconds, and string) is important. The vast majority of system clocks/OS's/languages handle the milliseconds format, nanoseconds will become
very important soon (it may be prove to be essential in smartgrid applications, but envision MQTT used in something like the Large Hadron Collider), and support for ISO 8601 string format makes sense since most business applications use that format.
When I refer to deadbanding, I'm referring to three specific types:
- Value : Suppress updates until the value (in native units) has changed by more than "x"
- Percentage : Suppress updates until the value has changed by more than "y" percent
- Time : Suppress updates until "z" amount of time has elapsed
Regarding aspects, you can think of them like extended attributes in an XML schema or properties in a JSON format. Application/device definable, and we use them as "metadata only".
Best,
Rick
From: m2m-iwg-bounces@xxxxxxxxxxx [m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Benjamin Cabé [bcabe@xxxxxxxxxxxxxxxxxx] Sent: Tuesday, February 28, 2012 8:55 AM To: m2m Industry Working Group Subject: Re: [m2m-iwg] M2M meta-model Hello Rick, and thanks for your feedback!
Some comments inline.
- I would be explicit regarding date and datetime formats and wire formats. Since one of the goals of MQTT was to be efficient in terms of bandwidth, I would explore passing UTC-based long value representations of time on the wire, either nanoseconds since XXX or milliseconds since XXX. If you want the protocol to have a long life and broader applicability, I would support nanoseconds. Maybe have a two-part date format – a byte indicator of type (milliseconds, nanoseconds, or ISO 8601 string) followed by the data
I am not sure all the different possible combinations of wire formats should be made explicit, it can quickly become complex. At least the wire format should be addressed in a separate "model", maybe. While of course the communication protocol(s) that an application
uses is very central, there are many different protocols around, and it might prove difficult and confusing to put too much protocol stuff into the core of the application model.
I agree that it would make sense to agree on a common handful of ways to represent time, since most of the M2M solutions have to deal with timestamped data.
- Since it is now 2012, a “location” data type is a must, with a required latitude/longitude and optional elevation, units, speed, direction
I agree on the principle that 'location' data type is a must. Actually, we may want to have a common way to model structured datatypes in general.
- The history/event policy should include change-based policies (deadbanding). These should include deadbanding by value, percentage of value, and time latency
I am not sure how detailed the deadband description needs to be, especially since it can be difficult to describe in an uniform way deadbands for e.g. numerical values and locations. But still I agree that it is useful to be able to describe deadbands.
- Instead of “commands”, I’d suggest a more modern and broadly applicable term such as “services”, which imply bi-directionality (commands, queries, etc.)
That makes sense. It may be interesting to associate some QoS policies to the services: acknowledge transmission, acknowledge execution, …
- If you’re going to be explicit about numeric types (integral vs floating), I would choose double and long, not double and integer, or at least support long also, as there are many use cases that require it
Agreed.
- I’m not yet convinced that the device should be responsible for its ACL’s – that is a topic that should be discussed in the broader context of security
I don't think that the device should be responsible for its ACLs either. The idea is more to be able to describe logic groups of data, that can then be coupled with access rules. The security model could probably be an add-in to the main data model, in order
not to clutter it with complex notions. Actually I think there are a lot of concepts that could benefit from being modeled, but they should not necessarily be part of the minimal core that
- ACL’s should be applicable not only to data elements, but to all device functionality (data, service, events, device management tasks, etc.)
Yup, and this is why it might be less tedious to deal with them in an external model.
- I’m curious why the protocol binding is at the data element level, and not the device level. That seems odd to me.
Different data groups of a same logical application (i.e. the entity that can be remotely updated/started/uninstalled/…) may be transferred with different protocols (e.g. Heartbeat event sent using MQTT every minute, while system variables are dumped every
day using Protocol Buffers).
- Data/service/event metadata should be extensible, and devices and applications should be allowed to add their own as needed for specific use cases. In ThingWorx, we name these a special type of metadata called “aspects”
This is what I was referring to earlier when I said that we need to have extensible models, more than trying to push too much stuff inside the 'core' model. I'd be interested to learn more about the "aspects" you are talking about ; maybe you could share more
about this?
Regards,
Benjamin—
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On
Behalf Of Benjamin Cabé
Hi all,
As I mentioned during today's call, there's now a wiki page dedicated to M2M meta-model discussions http://wiki.eclipse.org/Machine-to-Machine/M2MIWG/M2M_meta-model . Please review the first version of requirements we've put there ; it is pretty well detailed in terms of data management, but it needs to be refined in terms of device management and ALM… Marco, Kai, (others?) we can discuss the meta-model in more details during a phone call, if needed.
Also, we will provide a first implementation of this meta-model (in Ecore) in Koneki.
Cheers! Benjamin — |