Edge computing : le déploiement continu se fait une virée en caisse - compte-rendu du talk de Jordan Afonso à La Duck Conf 2019

L’intérêt de l’IoT n’est plus à prouver, et on rencontre de plus en plus de cas d’usage pertinents des objets connectés. Mais en prenant part à un projet IoT de bout en bout, on prend conscience que beaucoup de problématiques facilement traitées dans des contextes classiques doivent être repensées quand on les applique aux objets connectés.

Dans ce contexte, Jordan Afonso, porteur de l’offre IoT chez OCTO Technology, nous parle de son retour d’expérience chez un constructeur automobile.

Chez ce client, il a contribué à la mise en place d’une « usine à POCs », un laboratoire d’expérimentation et de démonstration pour des cas d’usage de voiture connectée.

Le périmètre de cette mission était double : concevoir et développer des fonctionnalités embarquées d’une part, et déverser les informations collectées sur le cloud pour qu’elles soient exploitées à des fins analytiques par d’autres équipes d’autre part.

Ce contexte a levé des questions intéressantes telles que les conditions de tests et de déploiement quand l’environnement de runtime est une voiture...

La demande était d’identifier et implémenter des cas d’usage en tirant partie des données disponibles, des capacités locales de la voiture (Edge Computing), et des possibilités plus larges offertes par le back-end cloud. L’approche retenue pour implémenter les différents cas d’usage identifiés tient en 5 étapes :

1. collecter des données physiologiques de l’usager,
2. épurer les données,
3. les croiser avec des informations contextuelles (telles que la météo, le cadre sonore, l’agenda de l’usager…),
4. identifier une situation sur la base de ces données (par exemple du stress),
5. appliquer une contre-mesure (par exemple diffuser une musique douce), et enfin renforcer le modèle des contre mesures grâce à une boucle de retour.

Voir la présentation complète sur slideshare.

Architecture fonctionnelle et technique

L’architecture technique de la solution est classique, avec un client, un serveur, et une connectivité limitée entre les 2. La voiture est équipée d’un ordinateur de bord tournant sous Linux. Un logiciel d’acquisition permet de collecter les informations mesurées par différents capteurs disséminés dans la voiture et sur le conducteur (caméra, thermomètre, bracelet connecté…). Les fichiers émis par ce logiciel sont ensuite parsés et les informations qu’ils contiennent sont poussées dans une file MQTT.

Cette file a double emploi :

1. Elle est synchronisée - chaque fois que la connectivité le permet - avec un autre broker MQTT (cette fois ci sur le Cloud),
2. Elle est consommée par des applications locales à la voiture qui exploitent les données avec une faible latence.

Ainsi, un tableau de bord Grafana affiche immédiatement les métriques intéressantes pour le conducteur (température de l’habitacle, rythme cardiaque, flux d’air…). Cela permet d’une part de ne pas déléguer au cloud des traitements qui peuvent facilement être pris en charge sur l’ordinateur de bord, et d’autre part de ne pas reposer sur les incertitudes du réseau pour obtenir des résultats dans un temps déterministe.

Un exemple parlant de cette nécessité de temps de traitement déterministe est la notification du conducteur lorsque les signaux collectés indiquent une situation de danger (franchissement indu d’une ligne, présence d’un véhicule dans l’angle mort…). Reposer sur le réseau pour qualifier le danger et redescendre l’information vers la voiture, puis le conducteur, présente un risque évident.

Avec un traitement local, le système peut réagir en temps réel et le siège conducteur peut, par exemple, vibrer pour signaler un franchissement de ligne.

En parallèle, les données collectées par les capteurs sont systématiquement envoyées vers une base de données froide pour être exploitées dans un second temps.

CI/CD d’une voiture connectée

L’équipe a mis en place un pipeline CI/CD permettant de contrôler la qualité du code, puis de créer une image Docker. L’image créée est ensuite stockée sur un registre, pour enfin être déployée sur les différents environnements. Mais à quoi ressemble ces environnements quand la production est une voiture ?

Le premier environnement dont disposait l’équipe est l’environnement de Développement, une reproduction de la stack logicielle (OS, middleware, software…) qui permet d’exécuter les tests automatisés.

Ensuite l’environnement de recette comprend aussi le back-end Cloud et une voiture de recette, c’est-à-dire une reproduction du hardware nécessaire à la recette, mais sans toute la mécanique d’une vraie voiture.

Et enfin l’environnement de production bénéficie d’une réelle voiture sur laquelle on peut pousser du code.

Le déploiement sur la production, qui reste manuel, nécessitait de repenser la façon classique de pousser du code puisque la voiture ne dispose que d’une connexion 4G, sans IP fixe. C’est donc une solution de pull côté client qui a été mise en place, avec un bastion permettant à la voiture de récupérer le code mis à jour et testé. Cette solution fonctionne parce que la flotte de ce laboratoire d’expérimentation ne dispose que d’une voiture, mais elle ne serait pas viable si il fallait passer à l’échelle : la limitation a été clairement identifiée par l’équipe projet, mais reste acceptable étant donné le contexte.

Exemples de cas d'usages

Un cas d’usage qui a été identifié au cours de ces expérimentations est l’évaluation de l’état de stress du conducteur sur la base d'informations mesurées (rythme cardiaque, bruit ambiant, météo…), et l’application d’une mesure palliative à ce stress (musique douce, baisse de la température, suggestion de pause…).

Un autre cas intéressant est la gestion de la température de l’habitacle, et plus particulièrement  la détection d'un inconfort thermique chez quelqu’un (déterminer qu’il ou elle a trop chaud ou trop froid) sans utiliser de Wearable. Des solutions envisagées sont l’utilisation de caméras, ou encore la pose de capteurs dédiés dans les accoudoirs de l’usager.

Conclusion

Participer à ce projet IoT de l’idée à la livraison a été une expérience très riche en enseignements.

Les conditions particulières liées aux contraintes de connectivité et à la nature mobile de l’environnement de production présentait des défis indéniables, mais avancer de façon pragmatique et conjointement avec le client a permis d’implémenter des cas d’usage concrets accrochés à cette réalité terrain.

Enfin, le socle technique et architectural est robuste et réutilisable dans ce type de contexte.

Lien Youtube