Un environnement d'exécution embarqué partagé permet de déterminer quels modèles restent actifs et lesquels ne s'exécutent que lorsque les conditions d'exploitation l'exigent
Les véhicules utilitaires sont confrontés à un problème de ressources à mesure que leurs capacités d’ AI s se développent : l’exécution en continu de chaque modèle impose des contraintes croissantes sur des ressources de calcul et de mémoire limitées, ce qui rend l’intégration, la validation et l’exploitation de nouvelles fonctions plus difficiles. Le défi architectural consiste à trouver comment prendre en charge davantage de capacités d’ s avec les ressources disponibles à bord du véhicule.
Chaque modèle supplémentaire peut nécessiter des ressources en termes de CPU ou d'accélérateur, de mémoire, de travail d'intégration et de validation. Or, un modèle nécessaire lors d'un événement de diagnostic ou d'un processus de maintenance n'a pas forcément besoin d'être exécuté à chaque trajet. Maintenir ce modèle actif même lorsque sa fonction n'est pas requise entraîne une consommation inutile de ressources d'exécution.
Pour les constructeurs, cela représente un défi de conception qui va bien au-delà de la production initiale. Les véhicules utilitaires ont un cycle de vie très long, et le magazine FleetOwner a indiqué que «les flottes n’ont pas exploité d’équipements aussi anciens depuis plus d’une décennie.» La puissance de calcul et la mémoire installées à la fabrication restent largement fixes, alors que les attentes concernant les logiciels et l’ AI s qui y sont exécutés ne cessent de croître. Les équipes d’ingénierie doivent déterminer comment les nouvelles charges de travail s’intègrent aux fonctions existantes et comment elles seront déployées, mises à jour et surveillées à l’échelle d’une flotte.
Pour les opérateurs et les équipes de maintenance, ces mêmes contraintes se reflètent dans les données. Le stockage, la bande passante et la connectivité limitent le volume de données télémétriques pouvant être transférées vers le cloud, et la collecte de grands volumes de données oblige les équipes à rechercher les événements et les signaux pertinents pour le diagnostic. Le compromis est difficile à éviter : soit tout envoyer vers le cloud et assumer le coût et le bruit, soit envoyer moins de données et risquer de passer à côté d’un événement clé.
Ces deux problèmes conduisent à la même solution: intégrer l’intelligence dans le véhicule et la gérer comme une infrastructure partagée plutôt que comme un ensemble de modèles distincts fonctionnant en permanence. Un environnement d’exécution commun peut gérer un portefeuille de modèles, en allouant les ressources d’exécution en fonction des besoins de chaque fonction.
Séparer le déploiement de l'exécution
L'idée principale consiste à dissocier les notions de « déployé » et de « en cours d'exécution ». Le fait de disposer d'un modèle sur le véhicule et celui de l'exécuter sont deux décisions distinctes. Les modèles déployés occupent toujours de l'espace de stockage, mais leur exécution peut être gérée en fonction des besoins opérationnels.
Cette distinction permet la coexistence de deux catégories d’intelligence en périphérie. L’intelligence persistante englobe les modèles qui doivent rester actifs pour prendre en charge des fonctions continues ou critiques pour la sécurité. Un exemple d’intelligence persistante serait un modèle ADAS de détection d’objets routiers qui traite les images des caméras pendant la conduite afin d’identifier les véhicules, les piétons et les cyclistes dans le but d’éviter les collisions.
L'intelligence à la demande comprend des modèles qui ne s'activent que lorsque le contexte du véhicule ou les conditions d'exploitation l'exigent. Un exemple d'intelligence à la demande serait un modèle d'évaluation de l'état de la batterie qui s'active pendant une session de recharge ou au dépôt afin d'évaluer la dégradation de la batterie et de signaler la nécessité d'une maintenance. Prendre en charge ces deux fonctions sur le même matériel implique qu'un système doit décider ce qui s'exécute, à quel moment et avec quelles ressources, sans perturber les fonctions qui ne peuvent pas être interrompues.
Un environnement d'exécution embarqué partagé peut prendre ces décisions. Il peut gérer le déploiement, l'activation, la désactivation, les versions des modèles, l'accès aux signaux du véhicule, les sorties et la surveillance, tout en allouant le processeur, la mémoire et d'autres ressources en fonction des besoins de chaque fonction.
Ces décisions doivent respecter les exigences propres à chaque fonction, notamment en matière de validation et de disponibilité des ressources. L'exécution à la demande ne supprime pas les tâches d'intégration ou de validation ; elle offre simplement un moyen de gérer les charges de travail qui ne nécessitent pas d'être exécutées simultanément.
Laisser le contexte du véhicule déterminer quand les modèles s'exécutent
Les signaux du véhicule, les événements de diagnostic, le mode de fonctionnement, la localisation géographique, le contexte de service et d'autres résultats du modèle peuvent servir de déclencheurs. Un état du véhicule déclenche une action, la plateforme active un modèle, celui-ci exécute sa tâche, puis la plateforme le désactive une fois la tâche terminée. Le modèle ne consomme des ressources que tant que sa fonction est nécessaire.
Étant donné qu’un modèle activé entre en concurrence avec les fonctions persistantes pour les mêmes ressources, la mise en œuvre de cette approche nécessite une visibilité sur l’utilisation du processeur et de la mémoire vive, sur le stockage, sur l’empreinte du modèle et sur les modèles exécutés simultanément. Les équipes d’ingénierie et d’exploitation ont également besoin d’une visibilité sur l’ensemble du parc : ce qui est installé, ce qui est en cours d’exécution, et si les ressources disponibles peuvent prendre en charge une charge de travail demandée.
Une couche d'orchestration partagée permet de gérer de manière cohérente toute une gamme d'applications, sans qu'il soit nécessaire de disposer d'une architecture distincte pour chacune d'entre elles. Parmi celles-ci figurent le diagnostic à distance, l'analyse des journaux en périphérie, la surveillance de la configuration, les modes « service » ou « atelier », l'évaluation de modèles et les workflows d'ingénierie ciblés, qui présentent chacun des besoins d'exécution spécifiques.
Détecter localement et collecter de manière sélective
La collecte de données sur les véhicules illustre les changements concrets apportés par cette architecture. Dans un flux de travail axé sur l'analyse dans le cloud, les équipes collectent des données, les téléchargent, recherchent des anomalies, identifient les événements significatifs, extraient les signaux pertinents, puis diagnostiquent le problème.
Un flux de travail « intelligent en périphérie » modifie cette séquence : détecter une anomalie localement, déclencher une collecte ciblée, télécharger le contexte pertinent, puis établir un diagnostic. Les décisions concernant les données pertinentes peuvent désormais être prises directement dans le véhicule.
Sonatus’s Fastlane™ Edge en est un exemple concret. Les « Smart Triggers » relient un modèle d’ AI s s’exécutant dans l’environnement d’exécution embarqué du véhicule à Fastlane™ Collector. Un modèle léger de détection d’anomalies ou une fonction mathématique en périphérie permet de surveiller les seuils de comportement du moteur. Lorsqu’il détecte une condition anormale, il déclenche une Fastlane Collector politique qui capture les signaux pertinents du moteur liés à l’événement. La collecte ciblée de données n’a lieu que lorsqu’une anomalie du moteur est détectée.
Cette approche permet d'obtenir des ensembles de données de diagnostic plus pertinents et de réduire les transferts inutiles de données entre les véhicules et le cloud, ainsi que les recherches manuelles dans les journaux. L'amélioration de l'utilisation de la connectivité, de l'espace de stockage ou du temps consacré aux analyses dépend de la qualité de la détection et de la politique de collecte des données.
En fin de compte, cela a pour implication architecturale générale que le déploiement, l’exécution, les ressources et la gestion du cycle de vie doivent être pris en compte de manière globale. Une plateforme peut prendre en charge un éventail croissant de capacités d’ AI s sans pour autant que chaque modèle installé doive fonctionner en continu. L’ AI en périphérie évolue lorsque l’intelligence devient une capacité gérée de la plateforme.