OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [obix] oBIX 2.0 features for constrained environments

I think MQTT is an alternative solution for the integration of building automation and M2M communication compared to oBIX.

Where oBIX follows the design paradigm of using RESTful Web services, MQTT follows an message oriented paradigm using a publish/subscribe mechanism.

As these integration paradigms coexist in state of the art IT systems I don't think it makes sense to think about using both or making them somehow interoperable. In some use cases an oBIX approach might be better and in others a MQTT approach would be more applicable.

For oBIX I think it is good to have an eye on MQTT and see how some problems are solved and which services are standardized within the specification. It might be useful to identify missing features that should be part of oBIX 2.0 and how to deal with the separation of features for constrained sensor networks.

Zitat von "Considine, Toby" <Toby.Considine@unc.edu>:

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

"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
Editor, OASIS EMIX, Energy Interoperation
Finance & Administration IT
University of North Carolina
Chapel Hill, NC

Email: Toby.Considine@ unc.edu<mailto:Toby.Considine@fac.unc.edu>
Phone: (919)962-9073

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<http://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


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

Dipl.-Ing. Markus Jung
Tel. +43 1 58801-18311
Fax +43 1 58801-18391
Institut für Rechnergestützte Automation
Treitlstr. 1-3/4. Stock/E183-1
TU Wien

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]