De nos jour, de plus en plus d’application sont déployées sur des plateformes et qui exigent une garantie de haute disponibilité de service à tout moment y compris lors des phases de mise à jour.
C’est le cas dans le projet VIADUCT dont l’objectif est de mettre à disposition des conducteurs un assistant vocal multimodal et personnalisé dans le contexte de voiture semi-autonome.
Date: 24 juillet 2020
Thème d'innovation: Systèmes Autonomes ⊕
A propos du projet: VIADUCT ⊕
Une application telle qu’un assistant vocal multimodal et personnalisé met en œuvre une combinaison de plusieurs briques logicielles, à savoir de la reconnaissance vocale, du traitement vidéo pour le monitoring du conducteur et de son environnement, ou encore un affichage visuel permettant une interaction tactile le cas échéant. Toutes ces briques logicielles travaillant de concert, il est donc impératif qu’elles soient disponibles en permanence.
De plus, il est possible d’être confronté à une autre contrainte qui est matérielle. En effet, ce type d’application peut-être commun à différents constructeurs, ce qui implique que l’application n’est pas forcément déployée sur la même plateforme (cela dépend des critères de coût, de technologie, de partenariat, etc.). L’application devra être assez indépendante des spécificités matérielles.
Une dernière attention doit également être portée sur la sécurité. Il est évident qu’une mise à jour déployée à distance doit répondre à des exigences de sécurité. N’importe qui ne doit pas pouvoir accéder au machine cible depuis l’extérieur.
La solution envisagée par le CETIC repose sur le edge-computing. Ainsi, les applications et les mises à jours sont mis à disposition au niveau d’une edge station qui est l’intermédiaire entre le véhicule et le cloud (cf figure ci-dessous).
Plus précisément, l’architecture repose sur un cluster de machines connectées à Internet : une EdgeStation. Cette infrastructure permet de stocker les modules à mettre à jour dès qu’ils sont disponibles. Dès qu’un véhicule se connecte à la EdgeStation, la mise à jour est déployée. Cette approche offre l’avantage de minimiser la dépendance à Internet et des services qui y sont associés. En effet, une connexion au réseau n’est indispensable que le temps de récupérer les applications à jour.
En Amont, le développeur héberge sa brique logicielle sur un dépôt Git. Une fois les développements finalisés et validés, il lui suffit de pousser toutes ses modifications sur une branche spécifique ce qui déclenche le processus d’intégration et de déploiement automatiques qui encapsule l’application et l’envoie à la EdgeStation.
L’automatisation des tâches repose sur la mise en œuvre d’une approche intégration continue/déploiement continue (CICD) :
1. Étape d’intégration continue
Cette étape débute par la récupération d’un outil : buildx. Ce nouvel outil fourni par Docker permet en une seule étape de construire une image multi-architecture et de la stocker dans un dépôt. il est possible d’encapsuler l’application en se servant du fichier Dockerfile fourni par le développeur. Pour finir, l’image sera sauvegardée dans un repository Docker privé hébergé dans la EdgeStation.
Il est a noté que le versioning de l’image ne se fera pas dans un format classique du type SemVer, mais plutôt en utilisant la date et l’heure de construction comme référence.
Cette stratégie permet de s’affranchir des spécifications matérielles des cibles potentielles. En effet l’utilisation d’une application conteneurisée ne dépend pas du système d’exploitation de la machine cible mais plutôt d’une application appelée “container engine”. De plus en travaillant avec buildx, le module sera fonctionnel peu importe le type de processeur présent sur l’hôte, qu’il s’agissent, par exemple, d’une architecture ARM ou AMD.
2. Étape de déploiement continu
La stratégie de déploiement de ces modules conteneurisés repose sur un outil d’orchestration : Kubernetes. Sa mécanique de fonctionnement se base sur la notion de ressources. Par exemple une machine du cluster sera un node, un container sera un pod. Il existe énormément de ressources plus ou moins complexes permettant de gérer aussi bien les machines que les applications présentes dans le cluster.
Dans notre cas de figure, la ressource qui a été utilisée est le Daemonset qui a comme particularité de déployer systématiquement une instance de l’application sur des noeuds spécifiques, par exemple des voitures.
Pour résumer, après la création d’un container et le stockage de celui-ci nous entamons la phase de déploiement. Pour ce faire un Daemonset pointant vers nos endpoint sera automatiquement créé et/ou mis à jour dans la EdgeStation. De ce fait, si un véhicule vient se connecter à la EdgeStation il se mettra automatiquement à jour.
Un autre avantage de ce type de déploiement est qu’elle garantit la continuité de service. Lors d’une phase de mise à jour, la nouvelle version déployée cohabite avec l’ancienne. La version obsolète de l’application ne se terminera que lorsque la nouvelle est correctement déployée et opérationnelle.
Cette solution est illustrée grâce à un PoC. L’objectif est de montrer la faisabilité et mettre en place l’infrastructure de cette approche. Pour faciliter la mise en oeuvre, l’application consiste à changer la couleur de led de la cible.
Cette solution a permis de mettre en œuvre de manière assez simple une mise à jour à chaud d’application sur des plateformes potentiellement hétérogènes grâce à l’utilisation de conteneurs et l’orchestration de ces derniers. Cela a permis de montrer également l’intérêt d’une approche edge pour faciliter la mise à jour en rapprochant les application des end point