RE: [obix] oBIX 2.0 features for constrained environments

[Markus Jung <mjung@auto.tuwien.ac.at>]

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
>
> 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<mailto:Toby.Considine@fac.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<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
>
> mjung@auto.tuwien.ac.at<mailto: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



--
Dipl.-Ing. Markus Jung
Projektassistent
mjung@auto.tuwien.ac.at
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