INTRODUCTION
Le Propulseur Numériser l’espace physique propose une solution qui, après déploiement, permettra à l’utilisateur d’observer et d’étudier comment un système Bluetooth basse consommation de localisation en temps réel (BLE RTLS) et Kibana résolvent le problème qui consiste à déterminer automatiquement qui/quoi occupe tel ou tel espace dans l’entreprise et où/comment. Ce document décrit la solution et la manière d’utiliser cette technologie évoluée.
ÉNONCÉ DU PROBLÈME
L’Internet des objets promet beaucoup, mais par-dessus tout, il laisse entrevoir la capacité, pour l’ordinateur, d’observer le monde physique sans aucune intervention de l’être humain. Saisir des données est une tâche fastidieuse et, pour bon nombre d’applications, demander à quelqu’un de le faire pour que l’ordinateur fonctionne plus efficacement s’avère peu pratique, voire irréalisable.
S’il pouvait identifier, situer et analyser les gens, les produits et les lieux par lui-même, peu importe l’endroit, grâce à l’apprentissage machine, l’ordinateur nous aiderait à réduire le volume de déchets, à accroître la productivité, à mettre un terme aux nuisances et à vivre une expérience plus enrichissante.
Grâce à la récente prolifération des articles radio-identifiables, plus précisément ceux respectant les normes RFID BLE et RAIN, il est de plus en plus rentable d’observer les humains occupant un espace au moyen d’un ordinateur recueillant les données transmises par les téléphones intelligents, des articles d’électronique vestimentaire ou d’autres objets comme des étiquettes d’identification par radiofréquence (RFID) peu coûteuses. D’autre part, les infrastructures capables de détecter ces signaux ne cessent de se multiplier. Souvent, il ne manque qu’un logiciel et son intégration pour tout réunir et permettre à l’ordinateur de « numériser » l’espace physique en temps réel.
Bien qu’on trouve sur le marché des produits et des solutions qui « numérisent » un élément ou un autre de l’espace physique dans un but très précis, une myriade d’applications complémentaires demeure sans solution. Une approche pour y remédier consisterait à utiliser un logiciel qui « numérise » tout ce qui peut l’être et procure des interfaces d’application (API) que partageront et exploiteront des logiciels spécifiques.
La Solution type
Nous illustrerons comment les technologies BLE RTLS et Kibana permettent de recueillir et de signaler automatiquement les données sur les activités physiques d’une entreprise.
Aperçu
La Solution type « numérise » n’importe quel espace physique et ses occupants, autant que faire se peut. Elle procure les API avec lesquelles on accède à l’information en temps réel sur qui/quoi se trouve où/comment, ce qui facilite le développement de logiciels d’application spécifiques.
En soi, la solution permet la coexistence de nombreuses applications complémentaires qui, chacune, utiliseront un flux Web standard de données venant des infrastructures physiques partagées. La PME n’aura donc pas à acquérir de vastes connaissances sur le matériel et les logiciels à la base des technologies RTLS, RFID et M2M (communication entre machines), si bien qu’elle pourra se concentrer sur le développement d’applications dans son domaine d’expertise.
Il est facile de configurer le logiciel pour qu’il ingère les données radio en temps réel décodées qui émanent d’une gamme de dispositifs. Les API REST et Socket.io du logiciel permettent d’exploiter les données dans leur contexte. Le logiciel autorise une connexion modulaire aux bases de données et aux plateformes courantes, plus exactement l’intégration d’Elasticsearch et de Kibana. Enfin, il comprend diverses applications Web qui illustrent le potentiel des flux de données et aident l’utilisateur à explorer et à mieux saisir le logiciel.
Le diagramme ci-dessous illustre la structure de la Solution type.
Diagramme de la solution
Description des composants
Le tableau que voici résume les principaux composants employés par la solution.
| Composant | Résumé |
| Émetteurs BLE | Dispositifs Bluetooth basse consommation qui émettent spontanément les paquets publicitaires. Il peut s’agir de téléphones intelligents, d’articles d’électronique vestimentaire, de détecteurs de clés, de balises, d’électroménagers intelligents, etc. (lire BLE as Active RFID) |
| Récepteurs BLE | Passerelles qui captent les paquets publicitaires des dispositifs BLE et, dans la Solution type, les relaient à l’instance du logiciel pour traitement et agrégation (à savoir, Raspberry Pi 3+, Owl-in-One) |
| Plateforme d’infonuagique ATIR | Plateforme permettant aux participants d’accéder à des ressources en nuage par le biais d’une interface Web |
| hlc-server | Logiciel de source ouverte combinant les modules ouverts de la source reelyActive (voir le diagramme plus bas) qui mettront en œuvre la solution. Ingère, traite et agrège les données radio décodées des diverses sources à destination des API à double effet avec lesquelles on observe en temps réel qui/quoi est où et comment. |
| Elasticsearch | Base de données de source ouverte qui emmagasine les données recueillies |
| Kibana | Logiciel de source ouverte permettant de récupérer, visualiser et signaler les données. Lire Kibana integration overview dans reelyActive pour voir comment procéder pour les rapports et les analyses. |
| Interfaces Web | Le serveur hlc et Kibana proposent des interfaces conviviales pour observer, manipuler et signaler les données en temps réel ou enregistrées. |
ÉMONSTRATION DE LA TECHNOLOGIE
Cette partie illustre comment fonctionne le logiciel Hyperlocal Context Server (hlc-server). Recourir à la technologie RTLS est tentant, car elle automatise la collecte des données sur les activités physiques de l’entreprise, ce qui permet de tirer plus facilement les conclusions sans lesquelles celle-ci ne pourra continuer à s’améliorer.
La démonstration indique comment déployer le logiciel RTLS, la base de données et les logiciels d’analyse dans le nuage de l’ATIR.
Déploiement et configuration
Configuration et lancement de l’application
Sur cloud.canarie.ca, ouvrez une séance avec le tableau de bord Morpheus au moyen des justificatifs d’identité fournis par l’ATIR.
- Sélectionnez Provisionnement
- Sélectionnez Applications
- Cliquez le bouton +AJOUTER
- Sélectionner le « blueprint » REELYACTIVE-HLC-ELASTICSEARCH-KIBANA
- Cliquez le bouton PROCHAIN button
- Donnez un PRÉNOM à l’application
- Sélectionnez AWS-Canada comme GROUPE
- Sélectionnez AWS-Canada comme CLOUD PAR DÉFAUT
- Sélectionnez un ENVIRONNEMENT quelconque (n’a aucune incidence sur la Solution type)
- Sélectionnez la partie ubuntu dans l’arborescence
- Actualisez les Options de configuration, en choisissant, au strict minimum, le plan T2 Medium – 2 Core, 4GB Memory (T2 Moyen – 2 cœurs, mémoire 4 Go)
- Actualisez Resource Pool (sélectionnez le bassin de ressources par défaut)
- Actualisez Réseau (sélectionnez une ou l’autre région disponible « az »)
- Actualisez Groupes de sécurité (sélectionnez le groupe de sécurité par défaut) et sélectionnez l’option « Assign EIP » pour l’adresse IP publique
- Actualisez les Options avancées (voir plus bas)
- Vous pourriez aussi saisir n’importe quelle variable environnementale – Environment Variables (lire la documentation sur hlc-server pour les utilisations plus poussées comme les ports sur mesure)
- Sélectionnez Expose Ports
- Choisissez hlc | 3001 | tcp et kibana | 5601 | tcp
- Sous Automatisation, confirmez la sélection du flux reelyActive-hlc-elasticsearch-kibana
- Cliquez le bouton PROCHAIN (une fois la configuration terminée)
- Cliquez le bouton ACHEVÉE après avoir vérifié la configuration de l’application
Notez que l’application, à laquelle vous avez attribué un nom, apparaît dans la liste des applications de la page Provisionnement. Vous verrez une fusée dans la colonne STATUT. Cliquez le nom de l’application pour passer en vue « provisionnement ».
Les propriétés supplémentaires apparaissent à l’écran. Cliquez l’instance reelyActive-hlc-elasticsearch-kibana pour passer en vue « instance ».
D’autres propriétés s’affichent. Une fois le provisionnement terminé, un bouton vert « lecture » remplace l’icône fusée dans la colonne STATUT. Regardez sous EMPLACEMENT, dans la section VMS, vous y verrez l’adresse IP de l’instance.
Vous devrez aussi actualiser le groupe de sécurité du réseau par défaut avec de nouvelles règles qui vous permettront d’accéder à l’application Web HCL et à Kibana par les ports 3001 et 5601, respectivement.
- Sélectionnez le menu Infrastructure
- Sélectionnez l’option Réseau
- Cliquez l’onglet Groupes de sécurité
- Cliquez le Nom du groupe de sécurité du nuage AWS pour modifier les règles
- Cliquez le bouton + Ajouter une règle
- Complétez le formulaire de la manière illustrée ci-dessus pour accéder aux ports TCP 3001 et 5601 (une règle pour chacun)
- Cliquez Sauvegarder les modifications
Dorénavant, vous pourrez pointer le navigateur Web sur l’adresse IP de l’instance, port 3001, pour accéder à l’application HLC. Exemple : 35.182.219.116:3001 (ci-dessus)
Vous devriez voir une page d’accueil similaire à celle-ci sur l’écran. Il est normal que le logiciel ne traite aucune donnée, puisque le système RTLS doit être configuré avant de transmettre des données.
Transmission des données à l’instance de la Solution type
Le logiciel hlc-server attend que les paquets de données (binaires) décodées raddec (RADio DECoding) traversent le port 50001 avec le protocole UDP. Il y a plusieurs façons d’envoyer des raddecs à l’instance. On peut, par exemple, recourir à un dispositif intégré comme Owl-in-One, à un appareil commercial comme un Raspberry Pi ou simplement à un logiciel.
Transmission avec un Owl-in-One
Owl-in-One est un produit reelyActive comprenant un dispositif libre de droits qui exploite un logiciel ouvert Node.js. Suivez ce tutoriel pour configurer l’Owl-in-One afin qu’il expédie les données BLE à l’adresse IP de l’instance de la Solution type. CANARIE a plusieurs dispositifs de ce genre à « louer ». Pour en emprunter un afin d’évaluer le Propulseur, écrivez à DAIR.Admin@canarie.ca.
Transmission avec un Raspberry Pi
Le Raspberry Pi 3 et ses contemporains intègrent une radiobalise BLE et peuvent être configurés pour utiliser le logiciel ouvert de reelyActive. Suivez ce tutoriel. Avec plusieurs lignes de code supplémentaires (voir l’exemple ci-dessous avec le raddec et le protocole UDP), vous pourrez acheminer le flux de raddecs à l’instance de la Solution type.
Transmission avec un logiciel
Vous pouvez produire et transmettre un paquet raddec avec le code Node.js que voici.
const dgram = require(‘dgram’);
const raddec = Buffer.from(‘10001702aabbccddeeff013a0101001bc509408100000b’, ‘hex’);
const client = dgram.createSocket(‘udp4’);
client.send(raddec, 0, raddec.length, 50001, ‘35.182.219.116’); // Set IP address!
Collez ces lignes dans un fichier que vous appellerez forward.js, puis, de la ligne de commande, exécutez node forward. Un raddec sera expédié à l’instance de la Solution type par UDP.
Observation des données dans Kibana
Les données pourront être observées dans Kibana à deux conditions.
- Au moins un paquet de données radio décodées (raddec) a été relayé à l’instance de la Solution type (voir plus haut).
- Kibana est configuré pour qu’on puisse y accéder par le Web (il n’est accessible que sur localhost par défaut).
Configuration de Kibana en vue d’un accès à distance
Pour accéder à Kibana à distance, en modifiant sa configuration comme suit :
- ajouter ssh dans l’instance de la Solution type (par ex., ssh username@35.182.219.116) – on peut aussi se servir de la console Web sur l’onglet Console en vue instance pour cela
- ouvrir le fichier kibana.yml et le modifier avec la commande sudo vi /etc/kibana/kibana.yml
- ajouter host: “0.0.0.0” à la fin du fichier
- sauvegarder le fichier
- relancer Kibana avec la commande sudo systemctl restart kibana.service
À présent, vous devriez pouvoir naviguer sur Kibana par le port 5601 de l’instance de la Solution type (par ex., 35.182.219.116:5601).
Créer un index des raddec dans Kibana
Dans Kibana, cliquez l’icône Discover sur la barre de gauche pour passer à la page « Create index pattern ».
- Tapez raddec dans la fenêtre « index pattern », puis cliquez Next Step pour continuer.
- Sélectionnez timestamp dans le menu déroulant Time Filter et cliquez Create index pattern pour continuer.
- Cliquez de nouveau l’icône Discover et observez les données raddec (s’il le faut, modifiez la plage horaire pour vous assurer qu’il y a des données)
Produire des rapports et visualiser les données avec Kibana
Vous trouverez des exemples de rapport et de visualisation dans les turoriels Kibana Integration Overview.
Conclusion
Pour libérer des ressources en mode Instances, sélectionnez l’instance puis, à partir du bouton du menu ACTIONS, sélectionnez Delete. À l’invite, choisissez Release EIP et cliquez le bouton DELETE.
CONSIDÉRATIONS D’ORDRE TECHNIQUE
This section describes considerations for usage and adaptation of the reference solution.
Cette partie décrit ce dont il faut tenir compte pour utiliser et adapter la solution de référence.
Déploiement
Le logiciel de source ouverte hlc-server peut être déployé sur à peu près n’importe quoi, d’un Raspberry Pi à un serveur d’infonuagique de pointe, car il a été conçu pour être accessible et polyvalent. Une unité centrale de traitement (UCT) adéquate suffira à obtenir une bonne performance jusqu’à un certain débit de données de localisation en temps réel. Au-delà de ce point cependant, il vaut mieux optimiser l’architecture qu’augmenter la capacité de l’UCT. Nous en discutons plus bas, dans les considérations de mise à l’échelle.
Le logiciel d’Elastic peut aussi être déployé sur une autre machine que le hlc-server, ce qui permet d’adapter les ressources à des besoins très différents.
Technologies de rechange
En ce qui concerne l’équipement de localisation en temps réel (dispositifs qui détectent et relaient les paquets radio au logiciel RTLS), les fournisseurs et les technologies ne manquent pas. La technologie RFID active la plus répandue est certainement BLE (Bluetooth basse consommation) et sa contrepartie passive est RAIN RFID. Un appareil BLE disponible dans le commerce comme le Raspberry Pi 3 peut servir de récepteur et relayer les paquets de données au logiciel de source ouverte. Pour la technologie RAIN RFID, on aura besoin du matériel plus complexe que proposent divers fournisseurs.
À notre connaissance, il n’existe pas de solution de rechange au logiciel RTLS générique de source ouverte.
Pour ce qui est des bases de données et des logiciels d’analyse, les solutions de rechange aux logiciels d’Elastic abondent. Dans la plupart des cas, rédiger un programme de connexion (semblable à barnacles-elasticsearch) pour l’intégrer à une autre base de données ne s’avérerait guère compliqué.
Architecture des données
La Solution type produit des données, plus précisément un flot de points représentant qui/quoi se trouve où/comment. Dans une application en temps réel pure (sans stockage de données), la seule chose à prendre en considération serait l’exploitation des données à mesure qu’elles sont produites. Beaucoup d’autres considérations entrent toutefois en jeu dans les applications qui stockent les données.
Où stocker?
Le type de base de données ou de support qui conservera les données historiques aura une incidence sur le coût et la performance au niveau de la récupération et de la manipulation des données en question. L’endroit où se trouvent les ressources informatiques qui entreposent les données pourrait aussi entrer en compte. Des contraintes juridiques ou contractuelles pourraient faire en sorte que les données doivent être gardées dans le pays ou la région où elles ont été engendrées.
Combien de temps?
Un système de localisation en temps réel fonctionnant en permanence crée un volume considérable de données qui, si elles ne sont pas archivées ou détruites au bout d’un certain temps, réduiront la performance du système et entraîneront des coûts supplémentaires assez élevés.
Quoi garder?
Un dispositif BLE RTLS recueillera en temps réel les données sur la localisation de tous les autres dispositifs BLE situés dans l’espace balayé. Quand on veut surveiller des dispositifs précis (les biens marqués) et ignorer les autres (téléphones intelligents, articles d’électronique vestimentaire), dresser une liste blanche d’appareils devrait suffire pour réduire la somme de données conservées, donc les coûts.
Sécurité
La Solution type est conçue pour sa commodité et l’expérimentation, plutôt qu’un déploiement sûr dans un environnement de production. Par défaut, le logiciel acceptera les données entrantes (sous forme de paquets UDP) de n’importe quelle source et donnera accès à l’API sans authentification.
Il revient à l’utilisateur qui le souhaite d’assurer la protection des données qui entrent et qui sortent. Dans le premier cas, la solution la plus simple consiste à activer les règles du pare-feu (par ex., ufw sur Ubuntu) pour n’accepter que les paquets UDP venant d’adresses IP précises. Pour les données sortantes, on pourrait installer et configurer NGINX afin d’exiger une authentification rudimentaire avant d’autoriser l’accès à l’API et aux applications Web.
Réseau
Il n’y aucune considération importante dont il faut tenir compte sur ce plan, outre les pratiques éprouvées recommandées dans l’industrie.
Mise à l’échelle
La Solution type peut être mise à l’échelle dans une mesure restreinte, selon le débit des données et les ressources disponibles (principalement l’UCT). Au-delà d’un certain point, il est plus efficace d’établir une architecture parallèle que d’augmenter la capacité de l’UCT.
Avec une application à débit élevé, il pourrait être plus efficace de lancer plusieurs instances du module barnacles avec le logiciel hlr-server et de répartir la charge entre eux, en fonction des identifiants radio du flux de données entrant. En d’autres termes, plusieurs instances barnacles fonctionneront de façon totalement indépendante pourvu que les données de chaque dispositif RFID soient toujours acheminées vers la même instance.
En ce qui concerne Elasticsearch et Kibana, on recommande d’observer les pratiques exemplaires pour les logiciels d’Elastic avec les applications à fort débit. L’exploitation de ces logiciels sur la même machine que hlc-server, comme on le fait dans la Solution type, n’est possible que jusqu’à une échelle restreinte. Le service Elasticsearch offre une souplesse nettement plus grande, même si un prix s’attache à cela.
Disponibilité
La Solution type n’est pas spécifiquement conçue pour optimiser la disponibilité, mais sa disponibilité demeure grande tant qu’on ne dépasse pas les limites de mise à l’échelle. Quand la disponibilité est un facteur crucial, on préconise le lancement d’instances en parallèle, un peu comme on le décrit à la partie « Mise à l’échelle ».
Interface utilisateur (IU)
Le logiciel hlc-server de la Solution type comprend plusieurs applications Web de source ouverte pouvant servir d’interface. Ces applications sont rédigées en HTML, CSS et vanilla JS (sans cadres) pour une lecture et des modifications/extensions plus faciles. L’utilisateur est encouragé à adapter et à élargir ces applications Web, puis à les partager avec le reste de la collectivité.
La plupart des applications Web en temps réel sont bâties avec beaver.js, ce qui affranchit le développeur des interactions avec l’API WebSocket et lui permet de se concentrer sur l’application proprement dite.
API
Les API qui accompagnent le logiciel hlc-server de la Solution type suffisent dans la majorité des cas. Si on a besoin d’une API différente ou plus importante pour accéder aux données, on recommande de créer une interface barnacles. Pour que l’API ingère les données venant du dispositif RTLS d’une tierce partie, il serait préférable de la créer avec le logiciel barnowl listener.
Les API peuvent aussi être enveloppées avec une couche de sécurité ou d’authentification.
Coût
La Solution type est très exigeante au niveau des entrées et sorties, et la plupart des coûts dérivent du traitement continu des données en temps réel. Outre l’optimisation des spécifications de l’équipement d’infonuagique pour gérer les coûts, une solution de rechange intéressante consisterait à repousser autant que possible le traitement en marge du nuage, pour l’alléger.
On parvient souvent à un bon équilibre périphérie/nuage en exploitant barnowl en marge et barnacles à l’intérieur du nuage. Dans un tel cas, barnowl retient les données une seconde (par défaut), ce qui entraîne une importante compression (sans perte) et atténue les exigences au niveau de la bande passante et du traitement en amont.
Licence d’exploitation
Le logiciel hlc-server de source ouverte utilisé par la Solution type est assorti d’une licence du MIT permissive qui, pour l’utilisateur ou le développeur, se résume à la condition suivante :
Inclure la mention de droit d’auteur et d’autorisation qui précède à toutes les copies intégrales ou importantes du logiciel.
Les versions source ouverte d’Elasticsearch et de Kibana sont assorties d’une licence Apache Version 2.0. Les autres versions de ces produits utilisent la licence d’Elastic.
CODE SOURCE
Le code source du logiciel hlc-server et les logiciels reelyActive sur lesquels il repose est disponible sur le compte GitHub de reelyActive à github.com/reelyactive
Le code des versions source ouverte d’Elasticsearch et de Kibana se trouve sur le compte GitHub d’Elastic à github.com/elastic.
GLOSSAIRE
Terminologie employée dans ce document
| Abréviation | Description |
| IdO | Internet des objets |
| BLE | Bluetooth basse consommation |
| RTLS | Système de localisation en temps réel |
| raddec | RADio DECoding (voir raddec library) |
| API | Interface d’application |