IdO Numériser l’espace physique

Introduction

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

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.

Description des composants

Le tableau que voici résume les principaux composants employés par la solution.

Dé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

1. Allez sur cloud.canarie.ca et connectez-vous au tableau de bord Morpheus avec les informations d’identification qui vous ont été fournies par la DAIR.

2. Allez dans Provisionnement>Catalogue et sélectionnez la tuile d’application reelyActive et cliquez sur ORDER.

3. Remplissez le formulaire de configuration. Dans le premier champ, saisissez un nom d’instance unique pour votre application, puis complétez le formulaire à l’aide des options déroulantes.

Observez que l’application, avec le nom choisi, a été ajoutée à la page Provisioning/Apps. Le STATUS sera une fusée pendant le provisionnement.

4. Cliquez sur le nom de l’application pour accéder à la vue de provisionnement.

La vue de l’approvisionnement énumère des propriétés supplémentaires.

5. Cliquez sur l’instance reelyActive_test pour afficher l’instance.

La vue de l’instance énumérera des propriétés supplémentaires. Une fois le provisionnement terminé, l’ÉTAT affichera un bouton de lecture vert.

6. Veillez à noter la colonne ADDRESS(ES), qui devrait afficher l’adresse IP attribuée à l’instance.

Vous devrez également mettre à jour votre groupe de sécurité réseau par défaut avec trois nouvelles règles :

• pour autoriser l’accès à l’application Web HCL sur le port 3001,
• pour autoriser l’accès à Kibana sur le port 5601 et
• pour autoriser l’accès à partir de votre machine locale via le port 22.

Regardez cette vidéo pour un rappel sur l’ajout de règles de groupe de sécurité :

Ajout d’une règle de groupe de sécurité

1. Allez sur Infrastructure>Réseau.

3. Cliquez sur l’onglet Groupes de sécurité.

4. Cliquez sur le nom du groupe de sécurité pour le cloud AWS afin de modifier les règles.

5. Cliquez sur le bouton + Ajouter une règle

6. Remplissez le formulaire de règle comme décrit dans la vidéo ci-dessus.

N’oubliez pas que vous devez ouvrir l’accès aux ports TCP 3001, 5601 et 22 (une règle pour chacun).

7. Cliquez sur Enregistrer 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.

1. Au moins un paquet de données radio décodées (raddec) a été relayé à l’instance de la Solution type (voir plus haut).
2. 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