Architecture MicroHMI pour Android Automotive
Pendant des années, de nombreux OEM ont construit ces systèmes sur des piles Linux personnalisées.
Elles fonctionnaient, mais leur mise à l'échelle était laborieuse. L'intégration de nouvelles fonctions ou la refonte de l'interface utilisateur impliquait souvent de toucher à l'ensemble du système. Chaque modification nécessitait de longs cycles d'intégration et de validation.
Android Automotive OS (AAOS) a changé cette dynamique.
With its modular structure and mature developer ecosystem, AAOS allows carmakers to design infotainment and cluster systems that can evolve over time, not just be frozen at SOP. It offers over-the-air updates, secure app isolation, access to Google services, and familiar Android tooling.
Mais un logiciel modulaire nécessite toujours une conception modulaire. C'est là qu'intervient l'architecture MicroHMI.
Pourquoi MicroHMI est-il important ?
The automotive HMI used to be a monolith – one codebase, one development flow, one large team. As vehicles move towards software-defined architectures, this approach no longer scales. Dozens of features must be developed, tested, and maintained in parallel by distributed teams and suppliers.
MicroHMI borrows the microservices idea from enterprise IT. Instead of one massive HMI, you create a set of lightweight, self-contained micro-applications, each responsible for a specific function: climate control, media, navigation, settings, or vehicle status.
Chaque module MicroHMI :
- A une responsabilité unique et des limites claires ;
- Communique via des interfaces versionnées ou un bus d'événements ;
- Peut être testé, mis à jour ou remplacé sans toucher au reste ;
- Et s'exécute comme son propre processus ou conteneur.
The benefits are immediate: faster prototyping, easier parallel work, and reduced regression risk. For large OEM programmes, it also improves supplier collaboration – different teams can own separate features while maintaining system consistency through shared APIs.
Nous sommes convaincus que MicroHMI est la solution pour maîtriser la complexité du cockpit.
Android Automotive comme hôte naturel
AAOS prend en charge cette architecture nativement. Chaque fonction peut être empaquetée sous forme d'application ou de service Android indépendant, signé et mis à jour séparément. Le Vehicle HAL expose les signaux provenant du véhicule, et le modèle de permissions robuste d'Android assure la sécurité des modules.
Android Automotive permet également :
- mises à jour OTA pour une amélioration continue ;
- Intégration des Google Automotive Services (Assistant, Maps, Play) ;
- Profils multi-utilisateurs ;
- Abstraction matérielle sur des plateformes telles que Qualcomm SA8155P ou d'autres SoC automobiles.
Pour les OEM, cela signifie un time-to-market plus rapide et une base stable pour l'innovation. Plus besoin de réinventer les frameworks pour l'audio, la navigation ou la connectivité.
De la modularité à l'adaptabilité
Décomposer l'IHM en micro-modules ne représente que la moitié du travail.
La véritable opportunité réside dans la transformation du cockpit adaptatif. Les conducteurs attendent désormais de leur voiture le même comportement conversationnel et contextuel que celui de leurs téléphones et enceintes connectées.
C'est ici que les grands modèles de langage (LLM) entrent en jeu.
Les LLM dans la voiture : le passage des commandes à la conversation
Le contrôle vocal précoce exigeait une formulation stricte : « Appeler John Smith », « Régler la température à vingt-deux degrés. » Les LLM et le traitement moderne du langage naturel (NLP) changent complètement la donne.
Un conducteur peut désormais dire :
« J'ai froid – peux-tu le réchauffer un peu ? »
« Trouver un café sur le chemin. »
« Baisse la musique, puis navigue vers la maison. »
L'assistant analyse l'intention, comprend le contexte et peut enchaîner plusieurs actions. Il ne fait plus de correspondance par mots-clés – ilinterprète le sens.
Dans le cockpit, cela signifie :
- UX conversationnelle : les conducteurs parlent naturellement, et non comme à un ordinateur.
- Comportement contextuel : le système connaît la destination actuelle, la température de l'habitacle et les préférences du conducteur.
- Enchaînement des tâches : une seule énonciation peut contrôler plusieurs fonctions.
Les LLM rendent l'IHM multimodal, en combinant la voix, le toucher et les gestes dans un modèle d'interaction fluide.
Le pipeline multimodal
Pour rendre cela possible, une HMI automobile intègre plusieurs couches d'IA et de logique logicielle.
- Mot d'activation et détection d'activité vocale (VAD) : écoute permanente mais à faible consommation de la phrase d'activation.
- Reconnaissance automatique de la parole (ASR) : convertit la parole en texte.
- Interprétation NLU ou LLM : extrait l'intention, les entités et le contexte.
- Gestionnaire de dialogue : maintient l'état entre les tours.
- Orchestrateur d'actions : associe l'intention à une API MicroHMI (par exemple, Climate.setTemperature(zone, value)).
- Retour d'information : fournit une réponse Text-to-Speech et une mise à jour de l'interface sur l'écran concerné.
Dans cette architecture, les modules MicroHMI agissent comme des exécuteurs d'actions. Le système vocal n'a pas besoin de savoir comment pour ajuster le climat ou jouer de la musique, il appelle simplement l'interface du module approprié.
C'est ce découplage qui rend l'intégration des LLM évolutive. L'assistant IA peut évoluer indépendamment des fonctionnalités HMI sous-jacentes, et inversement.
Équilibrer l'IA entre le cloud et l'edge
Les LLM sont volumineux, mais ils ne doivent pas toujours fonctionner dans le cloud. Pour des raisons de confidentialité et de latence, de nombreux OEM déploient désormais des architectures hybrides :
- Un modèle léger embarqué gère les requêtes courantes et la détection du mot d'activation
- Un modèle cloud traite les requêtes complexes à domaine ouvert lorsque la connectivité le permet
Cette conception garantit que les fonctions critiques restent disponibles hors ligne, tandis que les capacités conversationnelles avancées sont fournies lorsque l'appareil est connecté. Elle offre également aux OEM la flexibilité de se conformer aux lois régionales sur la protection des données telles que le RGPD.
Nos ingénieurs combinent fréquemment cette approche hybride avec la mise en cache du contexte et des seuils de confiance d'intention – le système décide dynamiquement s'il doit exécuter, demander une confirmation ou escalader vers une requête cloud.
Sécurité fonctionnelle et qualité dès la conception
Peu importe le degré d'intelligence d'un assistant, l'environnement automobile exige fiabilité et conformité.
Dans cette optique, nous intégrons la sécurité fonctionnelle et la maturité des processus directement dans le cycle de vie de l'IHM :
- ISO 26262 pour la sécurité fonctionnelle (niveaux ASIL A–D)
- Automotive SPICE pour la capacité des processus
- IEC 61508 et ISO 14971 pour la gestion des risques et les logiciels liés à la sécurité
Le Wavey platform integrates Squish GUI Tester in a Docker-based CI/CD pipeline, ensuring that every code change triggers unit, smoke, and regression tests. GitLab automation validates modules continuously – a practice essential for maintaining quality across distributed teams.
D'ailleurs, explorez le Wavey plateforme et découvrez comment une architecture modulaire, des tests automatisés et l'intégration de l'IA peuvent transformer votre approche de l'UX automobile.
Les tests automatisés ne concernent pas seulement l'efficacité. Il s'agit de confiance. Lorsque l'HMI d'une voiture contrôle des fonctions critiques, la confiance dans chaque version compte autant que l'innovation.
Concevoir pour l'évolutivité et la collaboration
Une architecture MicroHMI permet un véritable développement parallèle. Les équipes de design et d'ingénierie peuvent travailler indépendamment tout en se synchronisant via des contrats partagés.
Par exemple :
- L'équipe UI/UX conçoit le flux visuel d'une tuile de navigation
- L'équipe de développement l'implémente en Qt/QML
- L'équipe QA rédige des scripts Squish qui testent le module de manière isolée
Les trois peuvent fonctionner simultanément. L'intégration continue fusionne leurs résultats en un ensemble testable chaque nuit.
Spyrosoft utilise souvent cette structure dans les programmes de cockpit complexes, permettant à de multiples fournisseurs ou équipes internes de livrer des fonctionnalités sans dépendance constante à la gestion des dépendances.
This modularity also simplifies variant management. The same set of MicroHMIs can be combined differently across model lines – for example, a premium trim might add 3D visualisation via Unity, while an entry version reuses the same base modules without it.
Voix, gestes et tactile : une expérience multimodale
MicroHMI et l'IA débloquent ensemble une interaction véritablement multimodale.
- Le tactile reste idéal pour les tâches visuelles : exploration de cartes, réglages détaillés, navigation multimédia
- La voix prend le relais pendant la conduite, lorsque le regard doit rester sur la route
- Les gestes ajoutent une option naturelle et sans regard pour des actions simples telles que répondre à un appel ou passer une piste
L'IA relie ces modes entre eux. La reconnaissance du contexte évite les conflits – par exemple, le système suspend la saisie gestuelle lorsqu'il détecte une interaction vocale afin d'éviter toute ambiguïté.
Cette interaction crée une expérience plus proche d'une conversation humaine que d'un contrôle informatique. Ce n'est pas seulement une autre fonctionnalité. C'est un pas vers la conception d'interaction cognitive, la voiture s'adaptant au conducteur, et non l'inverse.
Gestion du contexte et personnalisation
Un assistant embarqué efficace mémorise le contexte sur quatre niveaux :
- Session : ce qui a été dit dans cette interaction.
- Utilisateur : préférences et habitudes personnelles.
- Véhicule : état actuel – vitesse, température, itinéraire.
- Application : quel module HMI est actif.
La combinaison de ces niveaux permet des relances naturelles. Un conducteur peut dire : « Naviguer vers le chargeur le plus proche », puis immédiatement, « Éviter les autoroutes », et le système comprend.
Pour préserver la confidentialité, le contexte sensible est stocké localement et synchronisé de manière sélective. Un gestionnaire de dialogue local filtre ce qui est partagé vers le cloud, en anonymisant les identifiants lorsque cela est possible.
L'objectif est clair : rendre la voiture utile sans être intrusive.
Performance et optimisation
La réactivité en temps réel est cruciale. Les LLM et les modèles vocaux doivent s'inscrire dans le budget de latence strict d'un véhicule en mouvement.
Les techniques d'optimisation incluent :
- Quantification et distillation des modèles pour réduire leur taille ;
- Accélération GPU ou NPU sur les SoC automobiles ;
- Pipelines asynchrones pour libérer les threads de l'interface utilisateur ;
- Limitation dynamique pour équilibrer les performances et la consommation d'énergie.
L'objectif est que le système reconnaisse une commande en environ une demi-seconde, afin qu'il soit suffisamment rapide pour paraître instantané, tout en restant suffisamment fiable pour des contextes critiques en matière de sécurité.
Pour garantir cela, nous surveillons la latence et les taux de réussite comme indicateurs clés de l'expérience utilisateur, aux côtés des KPI traditionnels tels que le taux de rafraîchissement ou le temps de démarrage.
Sécurité, sûreté et confiance des utilisateurs
L'intégration de l'IA dans un véhicule soulève naturellement des questions de sécurité et de traitement des données. Spyrosoft conçoit les HMI de manière à respecter dès le départ les réglementations en matière de vie privée et les normes relatives à la distraction du conducteur.
Les bonnes pratiques incluent :
- Traitement audio en local dans la mesure du possible ;
- Exiger une confirmation pour les actions critiques ;
- Fournir des indicateurs visuels clairs lorsque le microphone est actif ;
- Permettre aux utilisateurs de désactiver ou de supprimer des données ;
- Conformité aux lignes directrices de cybersécurité UNECE R155/R156.
Instaurer la confiance implique également de concevoir un comportement transparent. Si le système entend mal, il demande une confirmation. Si une requête semble dangereuse, il la refuse poliment.
Il ne s'agit pas seulement d'une bonne expérience utilisateur. C'est la conformité en action.
De la preuve de concept à la production
Chez Spyrosoft, nous mettons ces idées en pratique avec Wavey, notre cockpit IVI à commande gestuelle développé en interne, basé sur une architecture MicroHMI sous Qt pour Android Automotive.
Each feature – navigation, media, HVAC – exists as a standalone micro-application. Automated Squish tests validate every build in Docker containers. Gesture and voice inputs feed into the same backend APIs, demonstrating the modular design’s flexibility.
Wavey montre avec quelle rapidité un cockpit prêt pour la production peut être assemblé lorsque l'architecture, l'IA et les tests sont alignés. Le résultat est une plateforme IVI et combiné d'instruments automobile prête à être déployée, à la fois fonctionnelle et personnalisable à l'image de la marque.
Pièges courants et comment les éviter
Lors de l'adoption de MicroHMI et d'une interaction basée sur les LLM, les équipes sont souvent confrontées à des défis récurrents :
- Dépendance excessive au cloud : prévoyez toujours des solutions de repli hors ligne.
- Frontières de modules floues : définissez la propriété et les interfaces dès le départ.
- Absence de tests automatisés : chaque module devrait disposer de son propre pipeline CI.
- Ignorer le bruit du monde réel : testez la voix et les gestes dans les conditions réelles de la cabine.
- Protection de la vie privée après coup : intégrez la conception de la protection des données dès le premier sprint.
L'expérience de Spyrosoft sur les projets OEM et Tier-1 montre qu'une discipline architecturale précoce évite des mois de reprise de travail ultérieure.
Perspectives d'avenir
À mesure que les véhicules deviennent véritablement définis par logiciel, le cockpit sera le principal point de contact de l'utilisateur, une fusion de système de sécurité, de hub d'information et de compagnon numérique.
L'architecture MicroHMI fournit la structure.
Les LLM et l'IA fournissent l'intelligence.
Android Automotive fournit l'écosystème.
Ensemble, ils permettent des HMI modulaires, adaptatives et en amélioration continue – des caractéristiques essentielles pour les véhicules de nouvelle génération.
Travailler avec nous
Livrer de tels systèmes exige plus que de la technologie. Cela demande de l'expérience.
Nos équipes allient une expertise approfondie en ingénierie HMI à une compréhension pratique de la sécurité automobile, des tests et de l'intégration de l'IA.
Nos compétences incluent :
- Développement HMI en Qt/QML et C++ ;
- Intégration d'Android Automotive OS ;
- Squish et automatisation CI/CD ;
- Sécurité fonctionnelle (ISO 26262, ASPICE) ;
- Intégration de l'IA / LLM sur l'appareil et dans le cloud ;
- Conception UX multimodale par gestes et voix.
Que vous développiez un nouveau cockpit à partir de zéro ou que vous amélioriez une plateforme existante, nous pouvons vous aider à :
- Définir une architecture MicroHMI évolutive ;
- Intégrer les assistants vocaux et d'IA en toute sécurité ;
- Automatiser les tests et la conformité ;
- Accélérez votre mise sur le marché grâce à nos frameworks prêts à l'emploi.
Parlons de votre prochain cockpit
Les services de développement HMI de Spyrosoft permettent aux OEM et aux équipementiers de rang 1 de concevoir, tester et lancer des systèmes embarqués intelligents et personnalisables à l'image de la marque, conçus pour l'ère du logiciel défini.
Consultez notre solutions HMI ou contactez notre Directeur HMI et discutez de vos idées HMI.
arrow_circle_rightNOUS CONTACTER