La semaine dernière, j’étais à l’EclipseCon qui se déroulait à Toulouse. Sponsor Bronze de cette édition Red Hat (mon entreprise) avait un stand. C’est à cette occasion que j’ai participé à un training concernant le protocole CoAP et notamment le standard LWM2M dispensé par Julien Vermillard de chez Sierra Wireless.

Le protocole CoAP

Le protocole CoAP pour Constrained Application Protocol a été défini afin de répondre aux exigences très contraintes de l’internet des objets IoT et de la communication Machine 2 Machine M2M à savoir : faible puissance de calcul, faible consommation en énergie et faible bande passante. Le protocole CoAP est le pendant M2M du protocole HTTP pour le web car on retrouve les mêmes concepts et la même terminologie :

  • Notion de resource via des URI
  • Verbe ou methode identique, GET, POST, DELETE, PUT (au format binaire)
  • Code retour similaire 2.01, 2.03, 4.01, 4.03, 4.04 (au format binaire)

Fonctionnalités

Voici rapidement les principales fonctionalités du protocole (extrait de la RFC 7252) :

  • Protocole RESTful/web-like implementant l’ensemble des contraintes M2M,
  • Basé sur UDP (gestion de confimation, unicast, multicast),
  • Sécurité basé sur le Datagram Transport Layer Security version 1.2 (DTLS),
  • Notion d’URI et Content-type,
  • Message type Observe (mode push)
  • Faible empreinte réseau concernant les headers et metadata (format binaire),
  • Possibilité d’intégration d’un mécanisme de type proxy et cache,
  • Mapping transparent CoAP <–> HTTP.

Nous allons voir maintenant le standard LWM2M.

Le standard LWM2M

Le standard ajoute une couche d’abstraction au protocole CoAP permettant de gérer un certain nombre de problématique de l’Internet des Objets. En effet, les devices qui sont déployés dans le monde physique ont besoin de communiquer avec l’extérieur un certain nombre d’information. Ils (les devices) peuvent être relativement nombreux et nécessitent de pouvoir opérer des actions autres que les fonctionnalités pour lesquelles ils ont été conçus. Par exemple, il doit être possible de vérifier l’état de la batterie, rebooter le système, mettre à jour le firmware ou bien vérifier la valeur de tel ou tel attribut. Le standard s’occupe également de la gestion du parc des objets déployés avec des mécanismes de type :

  • Provisionning des devices,
  • Enregistrement des devices,
  • Management des devices,
  • Notification de changement.

Definitions

LWM2M défini un certain nombre de concepts permettant de gérer l’ensemble de son spectre de compétence. Pour cela il normalise la notion de Client, d’Object et de Resources. Un Client peut être vu comme le device déployé et il possède un certain nombre d’Object, chacun de ces Object regroupe une collection de Resources. Par exemple, un GPS est un Client qui va posséder plusieurs Objects et donc plusieurs Resources. Un Object va regrouper un concept bien précis i.e : la localisation de l’objet (Long, Lat, Alt, Temps, etc) ou bien les informations concernant le device proprement dit (Model number, Serial number, firmware version, battery Level, temps, Memoire etc…). Le serveur LWM2M peut interroger aussi bien en lecture qu’en écriture les Resources de ces Objects, il peut aussi demander l’exécution d’un traitement (reboot, shutdown, etc…). Et grâce à l’utilisation des URI, le serveur peut récupérer l’ensemble des informations de l’Object (/3/0 –> Device) ou bien la valeur d’une Resource bien précise (/3/0/2 –> Serial Number).

L’OMA normalise un certain nombre d’Object avec un ensemble de Resources associées.

Object Name id singleton
Security 0 false
Server 1 false
Access Control 2 false
Device 3 true
Connectivity Monitoring 4 true
Firmware 5 true
Location 6 true
Connectivity Statistics 7 true

**Connectivity Statistics**
Attribut id type R/W/E units
SMS Tx Counter 0 int R
SMS Rx Counter 1 int R
Tx Data 2 int R Kilo-Bytes
Rx Data 3 int R Kilo-Bytes
Max Message Size 4 int R Byte
Average Message Size 5 int R Byte
StartOrReset 5 E

IPSO Alliance propose quant à lui un certain nombre d’Objects de plus haut niveau (GPIO A/N, Illuminance, Temperature, Accelerometre).

IPSO Illuminance (3301)

Attribut id type R/W/E units
Min Measured Value 5601 float R
Max Measured Value 5602 float R
Min Range Value 5603 float R
Max Range Value 5604 float R
Reset Min and Max Measured Values 5605 E
Sensor Value 5606 float R
Sensor Units 5607 string R

Exemple

Nous allons voir maintenant comment developper et utiliser notre le framework Leshan qui est l’implémentation du standard LWM2M de la Fondation Eclipse

Pour cela commencons par la classe GPIOClient. Cette classe contient deux sous-classes interessantes Device qui représente les metadonnées de l’objet réel et la classe GPIO qui represente un broche de sortie de type numerique (ici elle sera simplement simulée).

Voici les captures d’écran du resultat lorsque le device s’enregistre au près du serveur.

Après un read de l’ensemble de la resource

Warning

L’instanciation de la GPIO / IPSO Digital Output se fait pour l’instant que depuis le serveur via une requete CREATE. Cette Fonctionnalité n’est pas encore présente directement depuis le client.

Warning

Les parametres ne sont pas encore bien envoyés lors de la création de l’objet, il est necessaire de les affecter/setter un par un.

juil. 02, 2015 6:48:19 PM org.eclipse.californium.core.network.config.NetworkConfig createStandardWithFile
INFOS: Loading standard properties from file Californium.properties
juil. 02, 2015 6:48:19 PM org.eclipse.californium.core.CoapServer start
INFOS: Starting server
juil. 02, 2015 6:48:19 PM org.eclipse.californium.core.network.CoAPEndpoint start
INFOS: Starting endpoint at /0.0.0.0:0
Registered with id: /rd/FU6hLfHTXZ
Write value state : true
Write value polarity : false
Write value applicationType : Ma nouvelle LED
Read value state : true
Read value state : false
Read value applicationType : Ma nouvelle LED

Warning

Attention, le projet est encore jeune. Certaines fonctionnalités ne sont pas encore implémentées

Conclusion

Le standard LWM2M basé sur le protocole CoAP permet de résoudre un certain nombre de problématique de l’Internet des Objets. Il offre un bon mix entre le monde Web (RESTful) et le monde IoT (objet low-{cpu,battery,bantwith}). En conservant la simplicité du monde Web (Uri, ressource, method HTTP-like, etc…), il abaisse le ticket d’entré de l’internet des objets aux mondes des développeurs venant du Web. La sécurité n’est pas en reste avec l’implémentation de certain mécanisme ou protocole comme le DTLS. La prochaine étape de mon travail sera d’intégrer ce framework dans le projet Camel IoT Labs

Liens Utiles