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 |