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)

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...

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/