Open Building Information Exchange (oBIX)

Open Building Information Exchange (oBIX) est un standard OASIS mené par divers industriels dans le domaine du batiment intelligent.

oBIX vise a s'affranchir des protocoles des devices (sensors/actuators/web-services exterieurs/...) en les décrivant en tant qu'objet suivant un Modèle Objet. Ces objet sont décris avec un Encodage et manipulable en tant que web service.

Ce standard se base sur une architecture RESTful qui est indépendante des protocoles pouvant être implémenté de manière sous-jacente (HTTP, SOAP, COAP, ...).

Actuellement la specification en est a la version 1.1, dispo ici: http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf

Modèle Objet

Tel que détaillé en Section 4 de la spécificiation, les objets oBIX respectent un modèle correspondant au type primitif d'objet.

Exemple: Un objet "Int" possède 4 attributs: max, min, unit (= l'unité de la valeur °C, cm, min..), val (= valeur). Et hérite d'un objet de type primitif Obj lui même ayant des attributs, l'un des plus important attribut étant href représentant une URI qui va permettre d'atteindre l'objet.

Par ailleurs, des annotations peuvent être utilisés en plus des attributs pour apporter des informations complémentaires l'objet (ex: avec l'encodage XML, il s'agira de Facets XSD)

Une notion essentielle dans le standard oBIX est le typage de chaque objet décrit dans l'une des section suivantes.

Objet

Les objets oBIX suivent tous le modèle d'objet évoqué en section précédente. Ces derniers peuvent servir à décrire l'état d'une lampe et sont encodés dans une syntaxe particulière décrit ci-après.

Encodage

Le standard oBIX définit plusieurs encodage pour les objets:

• XML, qui est recommandé par la spécification.
• JSON
• EXI (Efficient XML Interchange)

Une description de ces derniers est disponible ici: http://docs.oasis-open.org/obix/obix-encodings/v1.0/csprd02/obix-encodings-v1.0-csprd02.pdf

Dans la suite de cette page wiki, les exemples seront donnés uniquement dans l'encodage XML.

Un exemple d'un objet oBIX encodé en XML pour représenter l'actionneur d'une lampe pourrait être:

<obj href="/uri/to/access/LampActuator">
    <bool name="state" val="off"/>
</obj>

Ici, l'objet "Bool" de type primitif est utilisé pour montrer que l'actionneur de la lampe n'a pas été déclenché; La lampe est donc éteinte.

Type d'objet

Afin de pouvoir avoir des objets oBIX réutilisables et extensible, la norme permet l'usage de types. En effet, les objets de type primitif peuvent être typés dans oBIX par ce qui est nommé des "Contracts" (section 7 spécif.).

Un contract représente le template(<=> squelette) d'un objet Exemple pour le contract obix:Weekday définissant les jours de la semaine:

<enum href="obix:Weekday" range="#Range">
  <list href="#Range" is="obix:Range">
    <obj name="sunday" />
    <obj name="monday" />
    <obj name="tuesday" />
    <obj name="wednesday" />
    <obj name="thursday" />
    <obj name="friday" />
    <obj name="saturday" />
  </list>
</enum>

Ici le contract utilise un autre contract obix:Range. Ce dernier est défini comme suit:

<list href="obix:Range" of="obix:obj"/>

Il ne s'agit en fait que d'un contrat permettant de définir des listes d'objets. Dans le contexte du contract obix:Weekday, ces objets étant des jours de la semaine.

La notion de type recouvre une notion importante dans oBIX qui est l'héritage multiple (Section 7.4). Il est possible de spécifier une liste d'objet dont on hérite, via l'attribut

is="parent1 parent2 etc.."

Il est alors possible de redéfinir les attributs, ces derniers doivent être redéfini de manière cohérente.

De même l'héritage multiple doit être cohérent (pas d'attribut contradictoire dans 2 classes différentes dont on hérite par ex.). On parle alors de Contract Compatibility (section 7.7).

A noter qu'il existe des contracts déjà spécifier (Section 11) ayant pour préfix obix:[...]. Il est également possible de définir ses propres types de contracts avec sa propre syntaxe.

Opérations

Les objets oBIX possèdant une URI peuvent répondre à diverses opérations suivant leur nature, on en distingue 4 différentes:

• READ: Pour lire un objet
• WRITE: Pour changer l'état (= la valeur) d'un objet
• INVOKE: Pour appeler une fonction ayant possiblement des paramètres d'entrée/sortie.
• DELETE: Supprimer un objet

Exemple:

Dans le cadre d'un serveur oBIX implémentant des webservices permettant l'accès aux objets via le protocole HTTP, des opérations HTTP typiques seraient:

• HTTP GET: pour la lecture d'un objet
• HTTP PUT: pour changement d'état d'un objet
• HTTP POST: pour appeler une fonction avec comme paramètre le corps de message de la requete POST.
• HTTP DELETE: pour supprimer un objet.

TODO => watch/alarm/history, modèle client/serveur...

Fonctionnalites

La norme oBIX spécifie des objets fournissant des fonctionnalités particulières. Ces derniers sont décrits ci-dessous:

Watch

Décrit en section 12 en détails, cet objet est comme son nom l'indique un observateur.

L'objet Watch offre la possibilité d'observer d'autres objets oBIX, si on veut par exemple observer la valeur d'un capteur de température (déclaré en en tant qu'objet oBIX!). Une fois observer, il est possible de poller cet observateur pour obtenir la valeur du capteur, ou que l'observateur push la valeur du capteur vers nous. Ces deux cas sont dépendant de l'implementation faites de la norme oBIX.

On peut observer plusieurs objets, mais également annuler l'observation d'un ou plusieurs objets.

History

Décrit en section 14 en détails, l'objet History offre la possibilité d'avoir un historique d'un ou plusieurs objet oBIX.

Dans un premier temps, l'objet History doit être attaché à un objet oBIX (ex: un capteur de T°). Il est alors possible d'interroger l'objet History associé à cet objet pour obtenir les valeurs historiés suivant différents critères (plage de temps, nombre d'entrée, ...).

De plus, il est possible d'avoir des statistiques (moyenne, somme, min, max) des valeurs historiés en interrogeant d'une façon différent l'objet History associé.

Alarm

Décrit en section 15 en détails, l'objet Alarm permet de spécifier une condition sur une valeur d'un objet oBIX pour qu'une alarme soit déclenchée. Exemple: un objet Alarm associé à un objet oBIX "capteur de T°" décrivant qu'une alerte est déclenché si la valeur de la T° est supérieur à 50°.

Une alerte est alors déclenchée si la condition est remplie, ce qui se traduit par le changement de statut de l'objet source (ici, l'attribut "status" du capteur de T°).

Il existe deux types d'objet Alarm, l'un permettant de garder en mémoire que l'alarme a été déclenchée et qu'elle a été acquittée (ie: l'utilisateur a fait savoir qu'il avait pris connaissance de l'alarme) et l'autre ne gardant aucune trace. On parle respectivement d'objet Alarm "Stateful" et "Stateless".

Feeds

L'objet Feed est un objet qui s'utilise en complément d'autres tel que Watch, History, Alarm

Ce dernier permet d'enregistrer un flux d’événements associé à un objet oBIX quelconque (ex: capteur de T°). Pour cela il faut, dans un premier temps associé un objet Feed à un objet oBIX. Puis l'associer à un objet Watch, History ou Alarm.

Dans le cas d'une association avec un objet Watch, cela permettra d'observer tous les changements de valeur qui se sont produits sur l'objet source.

Associé à un objet History, il pourra d'historier toutes les valeurs qui ont variés concernant l'objet source.

Associé à un objet Alarm, l'objet Feed permettra d'enregistrer toutes les alarmes qui ont été déclenchés sur l'objet source.

Exemple d'architecture

L'architecture générale de la norme se base sur du client/serveur. Un exemple d'architecture repris d'un article (http://www.automatedbuildings.com/news/jun08/articles/considine/080539121012obix.htm) qui se veut être purement illustrative:

Exemple d'architecture d'un serveur oBIX

Ici, il s'agit d'une gateway qui fait office de serveur oBIX. Les clients étant extérieur (browser/appli/sources de données) et interrogeant la passerelle. Dans le cadre de source de données (exemple: données de météo), le serveur peut utiliser cette source pour la modéliser en tant qu'objet oBIX d'où la bidirectionnalité.

Le support de persistance est utilisé notamment par les objets History, ce support peut être une base de données par exemple.

Implémentations

Middleware JAVA/OSGi pouvant s’exécuter sur une gateway en tant que serveur oBIX: IoTSyS

Une implem. en C mais qui est ancienne, non complète et non-tenu à jour: https://code.google.com/p/c-obix-tools/