Les véhicules virtuels de Google Cloud s'étendent au-delà d'AAOS jusqu'aux plus petits contrôleurs

Google Cloud étend son approche de développement de véhicules virtuels au-delà du cockpit, en ciblant les petits contrôleurs qui obligent les équipes logicielles à attendre le matériel. Son annonce du 20 octobre décrit la connexion d'Android Automotive OS, le système d'exploitation pour véhicules de Google, à des réseaux de véhicules simulés via RemotiveLabs. Les véhicules virtuels de Google Cloud visent à intégrer plus tôt ces systèmes distincts dans les tests d'intégration.

La tension centrale est concrète : tester un tableau de bord indépendamment ne permet pas d'établir qu'il échange les bonnes informations avec le reste d'une voiture. Un véhicule défini par logiciel, dont les fonctions dépendent largement du logiciel, nécessite toujours un comportement coordonné entre ses composants. Google cible l'écart entre les équipes logicielles pouvant déjà tester à distance et celles dont le travail reste lié à des équipements physiques.

AWS a déjà décrit des composants automobiles virtuels interconnectés, offrant un point de comparaison utile pour l'approche de Google. Pour les acheteurs, la question est de savoir dans quelle mesure ces environnements représentent le comportement en production et quels retards de développement ils éliminent réellement. Cette distinction compte davantage que la capacité d'une démonstration à afficher un cockpit virtuel convaincant.

Les véhicules virtuels de Google Cloud étendent l'intégration au-delà du cockpit

L'annonce déplace l'attention de l'exécution d'applications automobiles individuelles vers le test des connexions entre les systèmes du véhicule.

L'architecture de véhicule virtuel de Google combine l'environnement de test virtuel d'Android avec RemotiveTopology, un outil permettant de décrire et d'exécuter des composants de véhicules connectés. L'ambition affichée s'étend de l'informatique de cockpit aux microcontrôleurs, ou MCU, qui sont de petits ordinateurs intégrés aux systèmes de contrôle.

Il s'agit d'une proposition de développement, et non d'une annonce selon laquelle le matériel automobile serait devenu inutile. Elle concerne également l'endroit où les ingénieurs développent et testent les logiciels. Les lecteurs ne doivent pas interpréter le développement dans le cloud comme l'obligation, pour un véhicule en mouvement, de dépendre d'un serveur distant.

Une unité de contrôle électronique, ou ECU, est un ordinateur chargé de fonctions particulières du véhicule. La question essentielle d'intégration est ce qui se produit lorsque ses sorties deviennent les entrées d'un autre composant. Un composant peut se comporter comme ses développeurs l'ont prévu tout en divergeant de l'interprétation qu'une autre équipe donne à un signal partagé.

Prenons l'exemple illustratif d'un changement de mode de conduite. Un cockpit pourrait afficher le mode demandé alors qu'un autre composant continue de signaler l'état précédent. Chaque application pourrait réussir des vérifications isolées, tandis que leur comportement combiné resterait incohérent. Tester l'interaction rend ce désaccord visible.

Cet exemple explique aussi pourquoi un véhicule virtuel nécessite plus que des écrans attrayants. L'artefact utile est un agencement exécutable de logiciels, de connexions, d'entrées et de réponses attendues. Sa valeur dépend des questions d'ingénierie auxquelles cet agencement peut répondre.

Un chef de produit évaluant un tel environnement devrait donc demander ce qui a changé dans le processus de développement. Les équipes peuvent-elles examiner un désaccord d'interface avant l'arrivée des équipements ? Un autre ingénieur peut-il reproduire la défaillance ? Le même scénario peut-il s'exécuter après qu'un fournisseur a mis à jour son logiciel ?

Ces questions transforment une vaste annonce d'infrastructure en une proposition d'ingénierie évaluable. Elles fixent également une limite à l'affirmation. Un environnement qui détecte tôt les erreurs de communication peut être utile sans reproduire chaque propriété physique d'un véhicule de production.

Pour les développeurs, l'opportunité immédiate est un accès plus précoce aux systèmes voisins. Pour les responsables de programme, il s'agit d'obtenir plus tôt des preuves sur les hypothèses d'intégration. Ces avantages nécessitent des représentations utiles des composants participants, et non simplement davantage de capacité cloud disponible.

C'est pourquoi l'accent mis par Google sur les petits contrôleurs est important. Un environnement de développement devient plus pertinent à mesure qu'il atteint les dépendances qui bloquent des tests significatifs. L'élargissement du périmètre n'aide toutefois que si les composants ajoutés représentent un comportement que les ingénieurs doivent réellement examiner.

Les fournisseurs subissent une pression pour fournir plus tôt des comportements testables

Une intégration plus précoce change ce qu'un constructeur automobile attend de ses fournisseurs, y compris le moment où ces informations doivent devenir exploitables.

Dans l'approche décrite par Google, le jalon de développement se déplace vers une contribution exécutable à un environnement partagé. Cette contribution peut contenir un logiciel de production ou une représentation limitée du comportement attendu. Dans les deux cas, son périmètre doit être explicite.

Pour un fournisseur, cela crée un livrable supplémentaire à négocier. Fournir uniquement une description du réseau ne répond pas à toutes les questions sur la réaction d'un composant. Fournir un logiciel exécutable soulève des questions distinctes d'accès, de maintenance et d'utilisations autorisées de ce logiciel.

Le constructeur automobile assume une responsabilité correspondante. Quelqu'un doit décider quelles versions des composants vont ensemble, quelles hypothèses restent provisoires et quelles défaillances empêchent la poursuite du développement. Avancer les tests n'attribue pas automatiquement la responsabilité.

C'est ici que la pression sur les calendriers devient une pression organisationnelle. Un environnement virtuel peut révéler un désaccord avant l'intégration physique, mais les équipes participantes ont toujours besoin d'un processus pour le résoudre. Une question d'interface sans réponse le reste, quel que soit l'endroit où le test s'exécute.

Un critère d'acceptation utile identifierait le comportement qu'une contribution de fournisseur doit prendre en charge. Par exemple, une équipe peut exiger qu'un composant signale une transition d'état et traite une demande rejetée. Cela est plus exploitable que de demander une compatibilité générale avec un véhicule virtuel.

Cette distinction compte aussi pour les petits fournisseurs. Les acheteurs doivent évaluer l'effort nécessaire pour produire et maintenir une contribution virtuelle utile. Sinon, le travail peut être déplacé en amont sans accord clair sur qui le finance ou le maintient à jour.

Les connaissances d'ingénierie existantes doivent également accompagner l'environnement exécutable. Les résultats de test deviennent difficiles à interpréter lorsque les décisions restent dispersées entre messages, documents d'interface et notes de réunion. Une défaillance reproductible nécessite toujours une explication de ce que les équipes participantes attendaient.

Une base de connaissances d'ingénierie interrogeable peut aider les équipes à retrouver ces décisions aux côtés de la documentation technique. Elle répond à un objectif différent de celui de l'environnement de test : préserver le contexte nécessaire pour comprendre et résoudre les résultats.

La pression s'exerce donc sur davantage que les développeurs de logiciels embarqués. Les équipes d'architecture ont besoin de définitions cohérentes, les équipes achats de livrables clairs, et les responsables de programme de jalons liés à des comportements observables. Une stratégie d'intégration virtuelle touche chacune de ces responsabilités.

Pour les acheteurs d'entreprise, cela suggère une méthode d'évaluation concrète. Sélectionnez une dépendance d'intégration existante et retracez ce que chaque participant doit fournir. L'exercice révélera si la plateforme proposée élimine l'attente ou expose simplement plus tôt des accords manquants.

Les deux résultats apportent des informations. Une visibilité plus précoce est utile, mais les acheteurs doivent la distinguer d'une résolution achevée lorsqu'ils évaluent les affirmations d'avancement d'un fournisseur.

Le véhicule en tant que code fait des connexions une partie du logiciel

Le mécanisme dépend de la possibilité de reproduire l'agencement du système, parallèlement au logiciel qui s'exécute en son sein.

Le véhicule en tant que code consiste à exprimer l'architecture électronique d'un véhicule dans des fichiers que les outils peuvent interpréter et exécuter. La description architecturale devient un élément que les ingénieurs peuvent examiner, versionner et réutiliser. Elle fournit une référence commune aux composants participants.

Les concepts de véhicule en tant que code de RemotiveLabs distinguent une description de plateforme d'une instance exécutable. La plateforme décrit les composants disponibles et leurs chemins de communication. Une instance sélectionne la configuration particulière à exécuter.

Cette distinction évite un malentendu important. Décrire une architecture complète ne signifie pas que chaque composant de cette architecture s'exécute dans chaque test. Une configuration ciblée peut répondre à une question plus restreinte, à condition que ses limites restent visibles.

La documentation distingue également les logiciels de production des modèles comportementaux, qui imitent le comportement des composants, et des mocks, qui fournissent des réponses contrôlées par le test. Ces représentations répondent à des objectifs différents. Leur présence devrait influencer la manière dont les ingénieurs interprètent un résultat positif.

Par exemple, un mock peut fournir la réponse précise nécessaire pour tester la gestion des erreurs d'un affichage. Ce résultat indique quelque chose d'utile sur l'affichage. Il en dit moins sur la question de savoir si le contrôleur de production final générera cette réponse dans des conditions équivalentes.

L'avantage analytique vient du suivi de ces distinctions plutôt que de leur dissimulation. Un environnement de test devrait permettre d'identifier ce qui s'est réellement exécuté. Sinon, l'expression « véhicule complet » risque de masquer les différences entre la couverture de l'architecture et la couverture par le logiciel de production.

La cohérence de la configuration constitue une autre contrainte. Les descriptions de plateforme de RemotiveLabs peuvent intégrer des fichiers de réseau automobile existants, y compris les formats ARXML et DBC qui décrivent des informations système ou de communication. Sa documentation exige des noms, paramètres et versions compatibles lors de la combinaison de fichiers pertinents.

Cette exigence mérite attention, car l'importation de fichiers ne réconcilie pas des décisions d'ingénierie contradictoires. Si les équipes fournissent des définitions incompatibles, un environnement automatisé nécessite toujours une résolution. La reproductibilité facilite l'examen du désaccord ; elle ne décide pas quelle définition est correcte.

Pour les véhicules virtuels de Google Cloud, la promesse pratique est une relation vérifiable entre le logiciel et le système qui l'entoure. Une modification logicielle peut être évaluée par rapport à un agencement connu. Une modification de l'architecture peut de même devenir une partie explicite de la revue.

L'intégration continue, la pratique consistant à construire et tester automatiquement les changements, fournit le cadre de cette relation. L'unité de preuve utile devient une révision logicielle testée au sein d'une configuration identifiée. Un résultat détaché de cette configuration est plus difficile à croire.

Cela change la manière dont les équipes devraient discuter de la couverture. Compter les composants connectés est insuffisant. Les acheteurs doivent savoir quelles interactions ont été exercées, quelles implémentations ont participé et quelles hypothèses ont fourni le comportement restant.

La démonstration la plus convaincante montrerait donc un désaccord d'ingénierie devenant reproductible, puis résolu. Cela apprend davantage aux lecteurs qu'une affirmation générale selon laquelle un véhicule entier peut démarrer dans le cloud.

Les tests virtuels AAOS conservent une limite matérielle

Un environnement logiciel fidèle nécessite toujours une limite clairement énoncée autour des comportements dépendants du matériel.

La seiche, l'appareil virtuel configurable d'Android, est un élément établi de cette architecture. La documentation de Google sur les appareils Android virtuels décrit son exécution en local ou à distance et souligne sa fidélité au comportement du framework Android. Elle identifie également des différences liées aux implémentations spécifiques au matériel.

Cette réserve est directement pertinente pour l'annonce. Android Automotive OS, couramment abrégé en AAOS, peut participer à un dispositif de test plus vaste sans rendre équivalente chaque interaction matérielle impliquée. Étendre la portée de l'environnement n'efface pas les distinctions qui existent en son sein.

Une couche d'abstraction matérielle est un logiciel qui relie un système d'exploitation à des fonctions propres à l'appareil. La documentation de Cuttlefish identifie explicitement ce domaine comme une source de différences avec les appareils physiques. Les acheteurs devraient conserver cette réserve lorsqu'ils interprètent des affirmations plus larges sur les véhicules virtuels.

La même prudence s'applique à l'architecture de processeur partagée. Des fondations d'exécution similaires peuvent soutenir une stratégie de développement, mais les acheteurs ont toujours besoin d'éléments probants concernant la cible précise. Une affirmation sur la compatibilité logicielle devrait préciser les logiciels, hypothèses matérielles et comportements comparés.

C'est particulièrement important lorsqu'un titre étend son propos de l'informatique embarquée du cockpit jusqu'au plus petit MCU. Représenter les messages d'un contrôleur diffère de l'exécution de son logiciel de production. Exécuter ce logiciel diffère encore de la reproduction de chacune de ses interactions avec son environnement physique.

Ces distinctions ne remettent pas en cause les tests virtuels. Elles définissent ce qu'établit un résultat. Un résultat au périmètre étroit peut être très utile lorsque ses hypothèses correspondent à la question à laquelle un ingénieur cherche à répondre.

La préoccupation apparaît lorsque le périmètre s'élargit au fil des reformulations. Un test d'interface réussi peut devenir une affirmation d'équivalence complète du système. Une démonstration dans le cloud peut devenir l'affirmation que le travail de validation restant a disparu. Aucune de ces conclusions ne découle automatiquement.

Google et RemotiveLabs font état de cycles d'intégration plus de 10 fois plus rapides lors des premiers engagements clients. L'annonce ne fournit pas assez de détails méthodologiques pour considérer ce chiffre comme une référence générale. Les lecteurs ont besoin de connaître la référence de départ, l'activité mesurée et le travail restant avant de l'appliquer à leurs programmes.

Une évaluation devrait distinguer le temps d'attente écoulé de l'effort d'ingénierie. Éliminer une file d'attente pour accéder à un équipement serait précieux, mais cela mesure autre chose que la réduction du temps d'investigation des défauts. Regrouper ces résultats sous un unique chiffre d'accélération peut masquer le bénéfice réel.

Les acheteurs devraient également se demander si les constats résistent à un changement de cadre de test. Un problème identifié virtuellement apparaît-il dans les conditions physiques attendues ? Le correctif proposé répond-il aux deux contextes ? Ce sont des questions utiles pour évaluer la pertinence sans exiger une équivalence universelle.

Le jugement qui en résulte est plus étroit et plus pratique qu'une affirmation selon laquelle le matériel a été remplacé. Les tests virtuels AAOS peuvent favoriser une intégration plus précoce pendant que les ingénieurs continuent d'établir quelles conclusions franchissent la frontière matérielle.

AWS offre un précédent pour les composants virtuels connectés

L'approche de Google s'inscrit dans un effort existant visant à rendre l'intégration automobile moins dépendante des cibles de développement physiques.

AWS a décrit une architecture connexe le 13 juin 2024, utilisant Panasonic Automotive vSkipGen et ETAS RTA-VRTE StarterKit. Ses cibles virtuelles interconnectées reliaient des environnements fournisseurs afin de soutenir une intégration plus précoce. La configuration publiée traitait également de la collaboration sans obliger les participants à exposer leur code source.

Ce précédent replace l'annonce actuelle dans son contexte. Connecter des composants logiciels automobiles au moyen d'une infrastructure cloud est une orientation établie. La contribution de Google devrait être évaluée à travers son parcours d'intégration particulier, les environnements pris en charge et son utilité pour les équipes d'ingénierie participantes.

La comparaison ne désigne pas de vainqueur. Les documents cités décrivent des dispositifs différents et ne fournissent pas de référence commune. Toute affirmation sur une exhaustivité ou des performances relatives nécessiterait des charges de travail équivalentes et des critères d'évaluation clairement alignés.

Pour les lecteurs qui cherchent à comprendre les véhicules virtuels de Google en termes concurrentiels, la comparaison utile porte sur les dépendances de développement. Quelle approche s'adapte aux composants déjà utilisés par un programme ? Quelles contributions de fournisseurs peuvent participer ? Quel travail reste-t-il avant qu'un test existant puisse être exécuté ?

Les limites de sécurité méritent également de l'attention dans cette comparaison. Les fournisseurs doivent coopérer tout en contrôlant l'accès à leurs travaux. Un acheteur devrait évaluer si le dispositif proposé permet la collaboration requise tout en préservant les frontières convenues entre participants.

Ces questions maintiennent la tension principale au premier plan : des tests partagés plus précoces face à une intégration qui attend les équipements physiques. La concurrence entre fournisseurs cloud apporte du contexte. La décision d'ingénierie dépend de la capacité d'un dispositif particulier à modifier cette dépendance pour un programme réel.

Un acheteur devrait donc éviter de considérer une marque cloud comme un substitut à un plan d'intégration. Les ressources de calcul disponibles ne constituent qu'une partie du dispositif. Les composants, autorisations, responsabilités des tests et configurations reproductibles déterminent si les équipes peuvent utiliser efficacement ces ressources.

La portabilité est une autre question d'évaluation raisonnable, plutôt qu'un avantage établi à présumer. Les équipes devraient identifier quelles descriptions, quels tests et quels modèles elles peuvent réutiliser ailleurs. Elles devraient aussi identifier les dépendances qui devraient être remplacées.

Cela compte parce que les investissements d'ingénierie dépassent la démonstration initiale. Une équipe qui élabore des scénarios utiles voudra les conserver à mesure que les composants évoluent. L'évaluation devrait examiner ce parcours de maintenance avant qu'une grande collection de tests n'en dépende.

Pour la simulation de véhicules sur Google Cloud, l'opportunité concurrentielle réside dans la capacité à étendre plus facilement un flux de développement existant au-delà des frontières du système. Les acheteurs auront besoin d'éléments prouvant cette adéquation. Une comparaison fondée uniquement sur des démonstrations de cockpits virtuels laisserait sans réponse la question centrale de l'intégration.

Le précédent AWS renforce donc la logique de cette catégorie tout en relevant le niveau exigé pour se différencier. L'approche de Google doit montrer où sa combinaison spécifique améliore le travail que les ingénieurs effectuent déjà.

Surveillez la couverture, les résultats mesurés et les exemples reproductibles

Les prochaines preuves devraient révéler ce qui s'exécute, ce qui s'améliore et ce que d'autres équipes peuvent reproduire.

Au cours des prochains mois, le premier signal à surveiller est une couverture plus explicite des composants. Des informations utiles distingueraient les logiciels de production des modèles comportementaux et des substituts contrôlés par les tests. Elles identifieraient également les environnements d'exploitation et les hypothèses de cible concernés.

Ce niveau de détail renforcerait l'argument en faveur des véhicules virtuels Google Cloud en rendant leur périmètre évaluable. De vastes schémas architecturaux sans détails de mise en œuvre correspondants laisseraient l'incertitude centrale sans réponse. Les lecteurs devraient rechercher des éléments sur les composants participants, plutôt que des affirmations plus larges sur l'exhaustivité.

La couverture doit aussi être reliée au travail d'ingénierie réel. Un contrôleur nouvellement pris en charge importe lorsqu'il débloque une interaction pertinente ou supprime une dépendance. Les annonces de prise en charge deviennent plus instructives lorsqu'elles incluent le scénario que les ingénieurs peuvent désormais examiner.

Le signal suivant est celui de résultats clients mesurés avec des limites définies. Une étude de cas utile identifierait le flux de travail initial, l'activité qui a changé et le travail encore requis ensuite. Elle distinguerait l'attente liée aux équipements, l'exécution des tests et l'investigation des défauts.

Un tel reporting aiderait les acheteurs à déterminer si l'accélération annoncée s'applique à leur situation. Un résultat issu d'une activité d'intégration étroitement sélectionnée devrait rester associé à cette activité. Répéter un gain de vitesse sans son périmètre de mesure apporterait peu d'éléments probants.

Les lecteurs devraient également surveiller les résultats qui compliquent le récit initial. Un environnement peut réduire les délais d'accès tout en augmentant la maintenance de configuration. Il peut révéler davantage de défauts plus tôt sans raccourcir immédiatement un programme. Ces résultats aideraient néanmoins à expliquer où l'approche fonctionne.

Le dernier signal est un parcours plus clair entre les exemples publics et une évaluation maintenue. Les exemples de véhicules virtuels de RemotiveLabs offrent un point de départ concret, y compris un exemple lié à Android. Le dépôt distingue son code d'exemple sous licence MIT du logiciel RemotiveLabs sous-jacent.

Cette distinction compte pour toute personne qui prévoit une évaluation. Des exemples publiquement réutilisables n'établissent pas que chaque dépendance requise relève de la même licence. Les acheteurs devraient examiner l'ensemble du dispositif d'exécution et les exigences d'accès avant de supposer une réutilisation sans restriction.

La reproductibilité renforcerait la valeur pratique de l'annonce. Un ingénieur devrait pouvoir identifier la version de l'exemple, comprendre ses hypothèses et reconnaître les questions de production auxquelles il répond. Une démonstration réussie devient plus convaincante lorsqu'une autre équipe peut en expliquer les limites.

Pour les responsables de l'ingénierie, l'action immédiate consiste à choisir une question d'intégration non résolue dans un programme existant. Demandez-vous si l'environnement virtuel proposé peut y répondre avant l'arrivée des équipements requis. Consignez quels composants contiennent des logiciels de production, lesquels utilisent des substituts, et quelles conclusions nécessitent encore une confirmation physique.

Maintenez cette évaluation suffisamment étroite pour produire un résultat interprétable. Comparez l'investigation au processus actuel, y compris l'effort de configuration et de maintenance. Conservez ensemble les révisions logicielles, la configuration, le comportement attendu et le résultat observé. Utilisez ces enregistrements pour décider si l'extension de l'environnement supprimerait une autre dépendance. Les véhicules virtuels Google Cloud seront particulièrement utiles lorsque ces éléments appuieront des décisions d'ingénierie plus précoces. Commencez par l'interaction que votre équipe ne peut actuellement pas tester, puis demandez-vous ce qu'établirait un résultat virtuel crédible.