2. InfoQ: Je t'ai brièvement présenté, est-ce que tu peux nous en dire un peu plus sur toi ?
Benjamin: Oui effectivement, je travaille chez Sierra Wireless, on fait du M2M, M2M pour Machine To Machine, et mon job, c'est de travailler sur tous les projets (M2M). Il se trouve qu'on fait ça en Open Source, les briques qui vont permettre de faciliter la création de solutions Machine To Machine. Je travaille chez Sierra depuis environ 7 ans, et depuis 2 ans maintenant, on a lancé une initiative chez Eclipse où on travaille à mettre en place tous les projets qui vont permettre de faciliter le développement de solutions M2M. C'est donc dans ce cadre-là que j'interviens.
Benjamin: Les deux termes sont similaires, mais M2M c'est un terme qui est là depuis plusieurs années, plusieurs décennies en fait. Toutes les technologies qui permettent de connecter des objets les uns aux autres soit de manière filaire soit sans fil. Par objet, historiquement, ça va être les ordinateurs, des "good old computers" (bons vieux ordinateurs), mais à vrai dire, de plus en plus maintenant, ce sont les objets de la vie courante. Connecter les voitures, connecter les systèmes d'alarme. Et donc, le Machine to Machine, c'est toutes les technologies qui vont permettre de faire ça, tous les protocoles qui vont être derrière, tous les outils qui vont permettre de développer ces solutions là, dans une optique idéalement de faire l'internet of things, c'est à dire que tous les objets de la vie courante, la plupart des analystes se mettent d'accord sur le fait qu'il y aura plusieurs dizaines de milliards d'objets connectés d'ici 2020, 2030, 2050, tous ces objets-là, voitures, capteurs de températures en tous genres. Une fois qu'on a réussi à les connecter, une fois que le machine to machine a été bien fait on va dire, on a un énorme réseau internet où tous ces objets-là sont des ressources sur lesquels on peut récupérer des valeurs, on peut agir sur ces objets, un peu comme dans le web où on va faire des GET et des POST. Donc c'est ça le M2M, si toutes les briques sont là pour connecter les machines correctement, et bien on connecte non seulement les machines qui elles-mêmes communiquent, mais aussi les objets de la vie courante qui ne sont parfois pas capables d'eux-mêmes de communiquer et d'atteindre Internet on va dire.
Benjamin: En gros, on a non seulement Koneki et Mihini mais on a en fait trois projets à l'heure actuelle, et niveau M2M, l'angle d'attaque qu'on a est de dire, il faut pour faciliter la connexion de ces machines, il faut de meilleurs outils pour développer les solutions qui vont permettre de connecter les objets, il faut des frameworks. Coté outil, c'est plutôt le cadre du projet Koneki, ensuite, il faut des frameworks, pour permettre de développer des solutions qui vont permettre de collecter des valeurs de température, connecter des télés, des objets, les faire communiquer en écrivant le code métier, et ensuite, il y a l'aspect protocole. On va faire en sorte de pouvoir communiquer en utilisant des protocoles qui vont économiser de la bande passante, dès qu'il s'agit de faire du wireless. Donc le challenge …, faire du machine to machine, comme je le disais plus tôt, ce n’est pas nouveau, connecter des systèmes d'alarme à internet, c'est quelque chose qui existe depuis quelques années, presque une petite décennie. Mais comment les rendre interopérables, c'est ça le challenge. Ce que je veux, c'est pouvoir arriver à connecter ma solution d'alarme, qui peut être, utilise un certain protocole de télécommunication, certains SDK peut-être propriétaires, pour peut-être parfois la programmer. Je veux connecter ça à mon frigo, à ma voiture, ainsi de suite. Pour ça, il faut des protocoles ouverts, des frameworks ouverts. Pour travailler sur le futur, avoir de nouveaux protocoles, que idéalement, un maximum de gens vont adopter, notamment, parce qu'ils seront ouverts. Il y a aussi un historique d'objets qu'on doit quand même permettre d'adresser et de connecter. Ces protocoles là, il faut arriver à les gérer aussi, c'est un peu ça le challenge.
Benjamin: Il y a plusieurs protocoles sur lesquels on essaye d'avancer, j'ai mentionné plutôt le nom du projet Paho, dans lequel un protocole qui a beaucoup le vent en poupe est MQTT, pour MQ Telemetry Transport. C'est en fait un protocole très simple pour faire du pub/sub, publier sur des topics, être en mesure d'être notifié lorsqu’un message arrive sur certains topics, et donc ce protocole-là a été inventé il y a 13 ans, 10-15 ans. Il devient de plus en plus populaire, il est en train d'être standardisé à l'OASIS, et il a pour but de faire en sorte que ce soit simple de connecter, de faire communiquer des objets, avec vraiment un simple protocole de messaging. Donc, ça fait partie des protocoles qu'on essaye de creuser. Ensuite, comme tu le faisais remarquer sur l'aspect Web of Things, ce dont il est de plus en plus question, c'est de faire en sorte que tous ces devices, qui sont parfois, un frigo, une voiture, des équipements embarqués très contraints, qui ont peu de mémoire, peu de ressources, puissent quand même se comporter peu ou prou comme des ressources internet, exposées, être visibles sur internet avec un paradigme REST. L'un des protocoles qui est en train d'être pas mal investigué chez Eclipse et que la plupart des organismes de standardisation autour de M2M regardent aussi, c'est un protocole qui s'appelle COAP, pour Constraint Application Protocol. C'est en fait le modèle HTTP REST au dessus d'UDP. Ca veut dire être mesure, sans avoir tout le surcout des headers HTTP et tout ce que peut amener HTTP, d'essayer d'avoir quand même le modèle de ressources, le modèle de mise en cache, le modèle de proxy, que peut amener HTTP, mais sur UDP. C’est-à-dire sur quelque chose de beaucoup plus léger à implémenter, y compris sur des micros contrôleurs, parfois très contraints. Donc voilà les grandes lignes côté protocoles.
Benjamin: Oui, tout à fait, parmi les technos qu'on propose, on héberge chez Eclipse des serveurs libres, ouverts et gratuits qui permettent d'évaluer les technos que l'on propose, en fait sur http:/m2m.eclipse.org, on trouve non seulement des infos sur tous les projets que j'ai évoqué plus tôt mais aussi des brokers, des serveurs pour faire vraiment communiquer ces objets. Et effectivement, ensuite, via des API REST, il est possible pour une appli Android, une appli iPhone, de venir consommer les données exposées par ces objets. En fait quand on dit Internet of Things, conceptuellement, tous ces objets sont capables de communiquer les uns avec les autres, mais en pratique, il y a toujours des passerelles pour atteindre un objet via un autre et souvent le via c'est un serveur à un moment donné. Et ce serveur, c'est le point central sur lequel on va pouvoir gérer toute une flotte d'équipements, remonter les données métiers, pour ensuite effectivement via des API REST faire des applications métiers, avoir des dashboard (panneaux de contrôle), avoir des applis avec de jolies interfaces. Et aussi faire ce qu'on appelle le device management, c’est-à-dire être en mesure de gérer les équipements eux même, être en mesure de mettre à jour leur software embarqué, d'être en mesure de les redémarrer, de savoir s'ils ont des problèmes de batterie. Donc pour ça aussi, à un moment donné, il faut que l'équipement se connecte à un serveur à intervalle régulier, ça fait aussi partie des technos que l'on propose dans le cadre de l'initiative.
Benjamin: Voilà c'est ça et être en mesure dès qu'un device pour une raison ou pour une autre doit être reconfiguré, on est en mesure de l'atteindre et de le manipuler à distance pour venir changer ses paramètres de connexions et venir faire ce genre de choses.
9. InfoQ: Ok, et quel est le langage utilisé, tu évoquais un framework, comment ça se passe ?
Benjamin: Le projet Mihini a pour but d'être un framework embarqué pour faciliter le développement d'applications M2M, ou Internet Of Things. C'est que c'est un framework qui vient se placer au-dessus de Linux, pour amener une abstraction pour tout ce dont on peut avoir besoin lorsque l'on fait du M2M, manipuler les entrées sorties du système, manipuler le port série, les GPIO (Entrées/Sorties pour un usage général), le GPS, ce genre de choses. Donc avoir des APIs au-dessus de ça, donc manipuler la connexion avec le serveur, sachant que dès qu'il s'agit de faire du wireless, peut être que la communication va pas toujours être très stable, il faut un certain nombre d'API pour être sûr que quand on veut communiquer, on a pas soit même en tant que développeur d'application à gérer toute la complexité de réessayer quand la communication a échoué, etc … donc c'est ce genre d'API que Mihini propose. Et ce framework là, on le propose aux gens comme point d'entrée principal pour programmer leurs applis. Il s'agit utiliser le langage de programmation Lua, ou "Loua" si on le prononce à la brésilienne puisque ça a été inventé au Brésil dans les années 90. C'est un langage de scripting, les gens qui sont familiers avec World Of Warcraft ou qui ont déjà essayé d'étendre la UI de World Of Warcraft ont peut-être eu l'occasion de manipuler Lua. C'est vraiment un langage de script qui a pour but d'être simple à apprendre, simple à interfacer avec C aussi. Quand on parle embarqué, on a souvent C qui est pas loin derrière, donc c'est aussi une des raisons qui fait qu'on préconise l'utilisation de Lua et donc voilà. Avec ce langage de script et en utilisant les API de Mihini, on va pouvoir lire des valeurs sur les GPIO, récupérer la position GPS, consolider ces valeurs-là, possiblement, et les pousser sur un serveur. Donc l'application Lua va être écrite en utilisant, même si le langage est facile à apprendre, on va quand même pouvoir bénéficier de toute la puissance de Koneki pour avoir un IDE pour Lua, content assist (aide contextuelle), débugger, tout ce qu'il faut pour pouvoir facilement débugger et développer. Donc puisque lorsqu'on fait du M2M, souvent, on va écrire l'application sur son PC et la faire tourner sur un équipement distant. Dans le cadre du tutorial qu'on avait à EclipseCON, on jouait avec des Raspberry Pi. On pense que c'est une cible intéressante pour expérimenter autour du M2M. Avec le Raspberry Pi, il faut pouvoir déployer le script, le faire tourner à distance, possiblement le débugger, donc voilà, le pourquoi avoir des outils, c'est pas seulement avoir des frameworks.
Benjamin: C'est exactement l'idée. Pour ceux qui sont familiers avec Eclipse et qui ont peut être déjà utilisé le Remote System Explorer, l'idée c'est que vraiment on configure, une fois qu'on connait l'adresse IP de l'équipement distant, qu'on sait que c'est un équipement Mihini ready, on va pouvoir se mettre depuis Eclipse à écrire des scripts, les débugger, etc …
Benjamin: Pour compléter un peu sur l'aspect Lua, on a voulu initialement se focaliser sur Lua parce que faire du M2M, dans l'idée c'est facile, je sais ce que je veux faire avec les valeurs que je vais récupérer de mes capteurs, je veux les consolider, je veux les envoyer sur un serveur, j'ai pas besoin d'être un programmeur pour ça, j'ai pas envie d'apprendre un langage particulier. Donc on a initialement mis le focus sur Lua. Effectivement, il y a quand même beaucoup de développeurs qui sont des développeurs Java, il y a une offre existante OSGi pour le monde de l'embarqué donc dans Mihini, on commence à regarder de ce côté-là. Le framework lui-même permet d'avoir potentiellement des bindings pour des langages différents. On a à l'heure actuelle en plus de l'API Lua une API C, et on est en train de regarder pour proposer une API Java et en l'occurrence qui rentre bien dans le moule OSGi. Une API où il y a vraiment des services qui vont permettre de manipuler les services de Mihini. Sachant que l'on veut de plus en plus regarder Java. Il y a un léger problème avec Java, c'est potentiellement les aspects licence, quand on veut travailler dans un mode où ce que l'on veut proposer, c'est une stack full Open Source, Java dans le monde embarqué, c'est pas toujours évident de trouver de bonnes implémentations ouvertes. C'est peut être parfois un peu plus gros de faire tourner une JVM que de faire tourner un runtime Lua ou C minimal mais clairement, on est en train de regarder. On a d'ailleurs un nouveau projet qui arrive chez Eclipse, je pense qu'il va pas mal faire parler de lui. C'est un projet qui s'appelle Concierge, une implémentation de OSGi, la version r3 OSGi, mais une version qui va être rafraichie à l'occasion du basculement chez Eclipse. Donc c'est une implémentation qui tourne sur des JVM d'il y a quelques années, sur un profile Java 1.4. C'est une implémentation qui a une empreinte mémoire très très faible. Donc à condition d'arriver à se procurer une JVM, on est capable d'avoir un runtime OSGi sans trop d'overhead. Donc clairement l'arrivée de Concierge et le fait que Mihini de toute façon est un framework qui est ouvert à tous les langages, et bien clairement, on va regarder Java de plus en plus.
Benjamin: A l'heure actuelle, avec Mihini, pour donner un ordre d'idée, au tutorial aujourd'hui à EclipseCON France, on faisait tourner ça sur un Raspberry Pi. Un Raspberry Pi, c'est quasiment un ordinateur de bureau, on a quelques centaines de mégas de RAM, on pourrait faire tourner Java, c'est pas le problème. Mihini, ce qu'on cible à l'heure actuelle, c'est d'être capable de tourner avec deux mégas de Flash, deux mégas de RAM. Donc c'est quand même un autre ordre de grandeur. On sait aussi que si en 2020, on parle de 50 millions d'objets connectés, certains des objets que l'on va vouloir connecter sont plutôt dans l'ordre du micro contrôleur, donc là on parle vraiment de quelques centaines de kilos de RAM, quelques centaines de kilos de flash, donc il est peut être assez peu probable d'arriver à faire tourner Java donc c'est pour ça aussi que ça va être important d'être d'accord sur les protocoles. Puisque peut-être c'est pas toujours une problématique de langage et d'implémentation, du moment qu'on sait comment on peut adresser l'objet, comment on peut communiquer avec lui, bah peut être que parfois ce seront des objets qui ont une stack en assembleur, ou une stack en code micro contrôleur X ou Y.
13. InfoQ: D'accord, donc, on va être dans un environnement, un écosystème multi-langages.
Benjamin: Oui, c'est multi-langages, multi-protocoles, on ne peut pas y couper. Il y a des développeurs embarqués qui ont l'habitude de contrôler leur équipement dans leur usine avec du code en C, ils veulent pouvoir mettre à profit et capitaliser sur ce code en C. D'autres vont faire du Java. De la même façon, ces usines qui sont déjà monitorées, ou ces voitures ou ces systèmes d'Home Automation (Domotique), si ils communiquent déjà avec le protocole X ou Y, les technos qu'on amène doivent non seulement proposer des alternatives à ces protocoles, à ces frameworks vieillissants, mais aussi permettre de bridger l'existant. D'ailleurs, un autre projet qui arrive chez Eclipse, aussi coté M2M, c'est un projet qui s'appelle Eclipse … ou qui s'appellera quand il sera crée, Eclipse Ponte. Le project lead (chef de projet) est un italien, donc Ponte, bridge, l'idée est d'avoir une techno coté serveur en Node.js. Pour arriver à dire, on va avoir plein de sous réseaux, d'équipements qui causent avec le protocole X, le protocole Y. Donc comment les bridger, donc l'idée est de venir avec une infrastructure web, extensible, avec un mécanisme de plug-ins. Finalement, on va pouvoir venir dire, la traduction du protocole X vers le protocole Y, c'est comme ça que ça doit se passer. Donc si on a ces plug-ins là installés dans l'instance du serveur Ponte, on va être en mesure de bridger des objets parlant des protocoles X vers le protocole Y. C'est quelque chose qu'on est obligés de faire parce qu'il en existe déjà des objets qui sont ce qu'ils sont et on va pas les changer.
Benjamin: Une fois de plus, Lua sur l'embarqué nous permet de tourner avec une empreinte mémoire flash et RAM assez faible et tout en permettant d'interfacer vraiment avec du C ce qui est quand même quelque chose d'important dès qu'on fait du M2M, parce que des librairies existantes en C pour contrôler des capteurs de température dans une usine, et bien il est fort probable qu'il en existe déjà. Donc, voilà, si on peut proposer non seulement un framework qui a une empreinte mémoire faible et en plus permet de s'interfacer facilement avec du C, c'est surement plus intéressant. Ca n'interdit pas le fait de proposer coté embarqué des APIs Javascript par dessus le framework Mihini pour les personnes que ça pourrait intéresser.
Benjamin: Oui complètement, et c'est là aussi qu'on fait surement le pont, voilà cette idée de venir connecter son réveil, c'est le même genre d'idée que la plupart des personnes qui jouent avec ce dont on entend de plus en plus parler, Open Hardware, Arduino, c'est vraiment, voilà, la possibilité de bricoler, en en tout cas d'être en mesure de hacker des objets de la vie de tous les jours. Et oui, s'il y a un moyen de s'interfacer avec ton réveil, fort probablement, il sera possible peut-être en utilisant d'abord un Arduino en tant que micro contrôleur vraiment facile à programmer avec aussi un large écosystème de librairies disponibles, peut-être de tutoriaux sur comment hacker le réveil, etc … On va être en mesure de casser une première barrière qui va nous permettre de communiquer vraiment de manière élégante avec l'objet et une fois qu'on a atteint ce premier seuil, l'Arduino expose entre autres interfaces un port série, et donc on va pouvoir venir utiliser les APIs séries de Mihini pour dire, je voudrais récupérer telle valeur ou je voudrais envoyer telle instruction qui va dire au réveil, je suis sous la douche, plus besoin de sonner. Donc oui, clairement, on va mettre à profit l'écosystème Open Hardware et l'écosystème qu'on amène plus sur la partie connectivité avec ce que l'on fait chez m2m.eclipse.org, je pense que tu pourrais arriver à faire ce projet.
16. InfoQ: Ok, et bien écoutes, je suis rassuré. Et bien c'était Benjamin Cabé et je te remercie.
Benjamin: Merci Cédric