I just got around to following the links on this. MQTT looks very interesting.
Do we want to include anything on MQTT coexistence?
-
Recommendations for exposing oBIX points to MQTT programmers
-
Recommendations for consuming and interacting with MQTT
tc
"When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us."
-- Alexander Graham Bell
|
Toby Considine
Chair, OASIS oBIX TC
Editor, OASIS EMIX, Energy Interoperation
Finance & Administration IT
University of North Carolina
Chapel Hill, NC
|
|
Email:
Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
http://www.NewDaedalus.com
|
From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org]
On Behalf Of Markus Jung
Sent: Wednesday, July 17, 2013 12:27 AM
To: obix@lists.oasis-open.org
Subject: [obix] oBIX 2.0 features for constrained environments
Beside the vision and features for oBIX 2.0 already circulated on the mailing list I would like to add a few ideas from my side.
It would be nice to have some features regarding using oBIX within constrained devices and wireless sensor networks beside the mentioned more enterprise centric features.
As you might have noticed MQTT (www.mqtt.org) is proposed to become an OASIS standard and has a similar scope like oBIX regarding M2M information exchange. The main difference is that its design paradigm is oriented to publish/subscribe
messaging middlewares whereas oBIX follows the REST paradigm. MQTT has another separate specification for wireless sensor networks (MQTT-S) that specifies an optimized message protocol and further services (discovery, security).
It would be great to have such a scope also in the oBIX 2.0 vision. I don't think it makes sense to have a separate specification for oBIX for constrained environments as the current solution with the different bindings and encodings is more flexible but somehow
to classify which features are addressing the enterprise scope and which features are about the deployment on constrained nodes.
For constrained environments I want to propose the following features:
-) Peer-to-peer / group communication model:
With the CoAP protocol binding it is possible to make a PUT request on an IPv6 multicast address. Think of multiple actuators natively operating IPv6 and oBIX. Using IPv6 multicasting an update on a group of similar oBIX objects adhering to the same contract
can be performed.
Furthermore, if IPv6 multicast addresses are assigned to oBIX objects with Point semantics a peer to peer communication is possible that allows to link directly sensors with actuators. E.g. a sensor detects an update on a bool data point and sends out a write
request on the IPv6 multicast address. All actuators which have a data point also assigned to the multicast state update their state accordingly.
In this way it is possible to build an automation system without requiring a centralized controller avoiding point-to-point unicasts and for integration scenarios with multiple different technologies this mechanism allows a simple data point centric interaction
across different technologies.
-) Discovery / Search
For discovery or search it would be nice to discover all oBIX servers within a local network and to find all servers exposing objects with a certain contract. Technologies like mDNS and DNS-SD could provide a nice solution based on existing technologies.
-) Authorization (Privacy)
A big issue with the Internet of Things and Smart Grid deployments are privacy issues. Access control policies and fine-grained authorization is one part of how to address this problem. Although other technologies like XACML might provide a concrete solution
to implement certain parts of such an authorization infrastructure it would make sense to standardize the authorization request that an oBIX server sends to a policy decision point, defining which information must be provided. A concrete policy structure might
not be in scope of standardization. The nice thing with oBIX is that the oBIX core vocabulary can be reused to classify information assets. oBIX provides a standardized way to query time series with a certain interval. This is quite useful if a policy needs
to be specified that defines which client is allowed to query smart meter time series in a certain resolution.
-) Security
All security related issues are more or less shifted to the transport layer. Due to the different protocol bindings it might make sense to provide a standardized application level security like WS-Security for SOAP that is the same across all the different
transports. This would allow to deal with security only once and not for every different transport.
Dipl.-Ing. Markus Jung
Research Assistant
mjung@auto.tuwien.ac.at
Tel. +43 1 58801-18322
Fax +43 1 58801-18391
Institute of Computer Aided Automation
Treitlstr. 1-3/4. Stock/E183-1
Vienna University of Technology