La décision d'une voiture autonome n'a pas de temps réel : qui la porte ?

Deux questions qui se confondent

Une automobile qui freine a besoin que sa décision tombe avant une échéance physique : la distance se parcourt pendant que le calcul tourne. La voiture est le problème temps réel par excellence, celui où l’enjeu de la deadline n’est pas une qualité de service mais la vie des occupants. De loin, cette industrie paraît parmi les plus aguerries du temps réel critique.

De près, en regardant la pile, un fait central s’impose : le composant qui décide, un réseau de neurones, ne peut pas fournir la garantie temps réel classique, celle d’un WCET WCET Worst-Case Execution Time. Borne supérieure du temps d'exécution d'un morceau de code, établie par une méthode prouvée (analyse statique des chemins, modèle d'exécution, topologie des caches). C'est la garantie temps réel classique : une architecture qui intègre une deadline a besoin d'une borne, pas d'une moyenne. borné. L’article sur la perf système pose une base voisine : un GPU moderne est un budget qu’il faut observer pour comprendre. Ici, la question n’est pas d’observer : c’est de savoir où poser une garantie quand le composant central n’en fournit aucune.

Deux questions se confondent pourtant :

1. Le temps de la décision : la latence, le respect d’une échéance.
2. La valeur de la décision : le comportement sûr, la responsabilité de la conduite.

Un WCET répond à la première. Les règles formelles, l’ ODD ODD Operational Design Domain. Domaine opérant de fonctionnement d'un système : routes, vitesses, météo, trafic, marquage dans lesquels il est conçu pour fonctionner. Toute garantie est relocalisée à l'ODD : le système n'est sûr que dans ce périmètre, et déclenche un repli (MRM) à sa sortie. , les statistiques de flotte répondent à la seconde. Les acteurs de ce dossier ne calculent pas un WCET : ils déplacent la deadline vers une couche qu’ils savent borner, parfois hors du modèle lui-même. La deadline ne se place pas sur le réseau : elle se déplace sur une couche qui, elle, sait être conforme.

Pourquoi le réseau n’a pas, et n’aura pas, de WCET

Ce qu’attend un WCET et ce que le GPU refuse

Un WCET est une borne supérieure du temps d’exécution d’un morceau de code, établie par une méthode formelle : analyse statique des chemins, modèle d’exécution, topologie des caches. L’analyse ne livre pas une moyenne ni un percentile : elle livre une borne. Un système temps réel achète cette borne pour y adosser une deadline : dans le pire cas, la réponse arrive malgré tout.

Le GPU dissout cette promesse par quatre mécanismes concourants.

La divergence de warps. Un noyau exécute des groupes de threads ensemble ; une divergence d’embranchement force l’exécution de chaque branche séparément. Le temps d’un warp devient une fonction des données, et les données du pire cas ne sont pas connues au moment de la compilation.

Des caches dont les états dépendent du contenu. La localité des accès à L1, L2 et mémoire de texture détermine les temps observés. Borner un GPU exigerait d’explorer tous les états de cache atteignables, un espace qui explose avec la charge.

La DRAM partagée. Tous les warps de la puce disputent la même bande passante. La latence d’un warp dépend de ce que font les autres : le pire cas n’est plus une propriété d’un noyau isolé, mais de toute la machine.

L’ordonnanceur opaque. Le matériel planifie les warps sans rien spécifier publiquement. Une analyse devrait savoir quand un noyau peut être préempté et à quels endroits ; sans spécification de l’ordonnanceur, ce point, le plus difficile à borner, reste une boîte noire.

Ces mécanismes sont des propriétés physiques de l’architecture GPU, pas des défauts qu’une révision corrige. La conclusion s’impose : le WCET d’un réseau complet est un problème ouvert, pas une difficulté qu’il suffirait de cocher.

La littérature récente le documente

Le papier Bounding the WCET of a GPU Thread Block (Jeanmougin, Carle, Rochange, ECRTS 2025) démontre une borne sûre pour l’élément le plus simple du GPU, un thread block, sous hypothèses précises (validation Accel-Sim, ~12 % d’écart moyen avec le mesuré). Le résultat est double : une analyse statique réalisable et un périmètre strictement limité, un thread block et non une application complète. La conclusion publiée est explicite : borner un simple bloc est déjà un problème en soi, le cas général reste un problème ouvert.

Le papier Demystifying NVIDIA GPU Internals (Bakita, Anderson, RTAS 2024) attaque par l’autre flanc : certaines analyses temps réel publiées pour les GPU NVIDIA reposent sur des hypothèses incorrectes sur le comportement interne. Nuance importante : dans une même stream CUDA, l’ordre d’exécution reste bien FIFO, garanti par la sémantique officielle. En revanche, entre streams, la préemption est partielle et la superposition d’exécutions ne suit pas un FIFO strict. Ces deux constats posent un enjeu méthodologique que l’industrie, elle, a résolu autrement.

Encadrer la deadline plutôt que la calculer

La stratégie industrielle ne consiste pas à trouver un WCET pour le réseau, mais à ne plus en exiger : la deadline est déplacée sur d’autres couches, proches ou lointaines. NVIDIA place la fonction de sûreté dans du silicium dédié. Mobileye définit des règles formelles de responsabilité. Mercedes obtient une homologation de niveau 3 qui s’appuie sur une manœuvre de repli bornée, pas sur la latence du modèle. Tesla mesure à l’échelle de la flotte. Chacune de ces approches répond à une même question : où placer la garantie quand le modèle ne peut pas être borné ?

Notons au passage une convention à expliciter : les 100 ms régulièrement citées comme cible de perception sont une convention d’ingénierie, non une exigence normée ; aucun texte ISO 26262 ISO 26262 Norme internationale de sécurité fonctionnelle pour l'électronique automobile, « Road vehicles - Functional safety ». Elle couvre le cycle de vie complet d'un composant et introduit les niveaux ASIL. Elle traite des pannes (fautes matérielles aléatoires, fautes systématiques du logiciel), pas de la qualité du comportement du modèle. ni SOTIF SOTIF Safety of the Intended Functionality, norme ISO 21448. Couvre les risques liés à un fonctionnement conforme à la spécification mais dangereux par manque de performance (scénario non vu, mauvais réglage). C'est le pendant comportemental de l'ISO 26262, qui, elle, traite les pannes. ne fixe explicitement cette valeur pour la perception. C’est une tension latente.

NVIDIA : la deadline dans la puce

Chez NVIDIA, la réponse à l’absence de WCET est une architecture : ne pas donner de garantie temporelle au réseau, mais placer la fonction de sûreté dans une île de silicium dédiée, la Functional Safety Island FSI Functional Safety Island. Île de sûreté dédiée dans un SoC : processeurs redondants (type double-cœur verrouillé), rail d'alimentation et horloge indépendants, isolation face au reste de la puce. Elle porte la fonction de sûreté certifiée pendant que le reste du SoC reste non classé. , largement décrite pour le SoC AGX Orin.

La FSI d’AGX Orin regroupe des paires de cœurs Arm Cortex-R52 en configuration lockstep (4× DCLS, ~10 000 MIPS ASIL-D), un rail d’alimentation séparé et une horloge (XTAL) dédiée. Elle est isolée du reste de la puce, sur laquelle tournent les modèles de perception sur GPU. C’est cette île qui est certifiée contre les fautes aléatoires et dont la mission est bornée dans le temps, pendant que le réseau reste sur un territoire qu’aucun WCET ne délimite.

NVIDIA parle de plateformes « ASIL-D ASIL Automotive Safety Integrity Level. Niveau de rigueur exigé d'une fonction automobile par la norme ISO 26262, quatre échelons de A à D, D étant le plus exigeant. Il s'applique à une fonction de sûreté, pas à une puce entière : un SoC peut héberger une île ASIL-D et le reste non classé. capable » pour sa suite de conduite : la plateforme est capable, le niveau de garantie réellement délivré reste à contractualiser par le constructeur. Il faut donc lire avec soin les chiffres : les 1 000 TOPS (INT8) du Thor concernent le calcul de perception, pas la fonction de sûreté, qui vit dans la FSI avec des cœurs centrés sur le suivi de la sécurité, pas sur l’inférence.

Mobileye : la deadline vit dans la règle

Mobileye ne certifie pas non plus le réseau. Sa réponse tient en une idée : fixer des règles formelles qui décident, dans chaque situation, qui est responsable et ce que chaque partie doit faire pour éviter l’accident quand l’autre est en faute. C’est le modèle RSS, Responsibility-Sensitive Safety RSS Responsibility-Sensitive Safety. Modèle de règles formelles (Shalev-Shwartz, 2017) définissant, pour chaque situation, une réponse appropriée et qui « est à blâmer » en cas d'accident. Fournit une propriété logique de la décision, sans toucher à la perception. , formalisé en 2017 dans un article publié (arXiv 1708.06374).

Son idée est de déplacer la deadline de la perception vers la décision : le modèle ne garantit rien sur sa latence, mais les règles RSS encadrent le comportement acceptable. La garantie RSS est un cadre logique sur la responsabilité en cas de collision, pas une garantie temporelle sur le réseau. Sa limite est le miroir de son choix : elle ne dit rien de la perception. Un obstacle invisible reste un accident, quelle que soit la beauté de la règle. Mobileye le reconnaît : la perception reste un enjeu statistique à mesurer (tests de validation massifs), pas un périmètre formalisé. La règle formelle encadre la décision, et c’est précisément ce déplacement qui fait son intérêt : changer de couche pour rester dans un monde où la garantie est définissable.

Mercedes : la deadline dans l’homologation

L’approche la plus avancée en Europe est celle de Mercedes : la garantie ne vient ni de la puce ni de la règle formelle, elle vient de l’homologation d’un système de repli. Mercedes a fait certifier le niveau 3 Drive Pilot dans le cadre du règlement ONU R157, et le principal document technique reste le règlement lui-même (série 00 puis série 01). Le cœur est la manœuvre de repli : si le système ne peut plus conduire, il exécute une Minimal Risk Maneuver MRM Minimal Risk Maneuver. Manœuvre de repli qu'un système de conduite exécute quand le conducteur ne reprend pas la main : s'arrêter sur la voie, rejoindre la bande d'arrêt, décélérer selon un profil réglementé. C'est la procédure de dégradation prévue par conception, une exécution bornée là où le WCET du réseau manque. , une séquence bornée (stop sur la voie, appel d’urgence) qui ramène le véhicule dans un état sûr.

Ces arrêts sont bornés par des valeurs explicites dans le règlement (décélération, temps de réponse), et c’est là que réapparaît la deadline : elle ne porte pas sur la latence du réseau, elle porte sur la MRM, dont le profil est réglementairement fixé. La certification de niveau 3 par la KBA (Allemagne, 9 décembre 2021) est la première au monde pour ce type de système, et la série 01 du règlement élargit le périmètre : jusqu’à 130 km/h sur les tronçons éligibles, une homologation concrète d’abord prononcée à 95 km/h fin 2024, puis une trajectoire vers 130. Les limites de l’approche : très étroit ODD, nécessité de la reprise en main dans un délai, et le pari que la perte du réseau déclenche la MRM avant qu’un danger ne se matérialise.

Tesla : la deadline dans la statistique de flotte

Tesla prend le contre-pied complet : la garantie y est statistique. Au lieu de définir une deadline ou une règle, la firme mesure, à l’échelle de la flotte, la fréquence des interventions humaines par mile en conduite supervisée (rapport trimestriel officiel). Le chiffre célèbre des miles par intervention est à double tranchant : il décrit la moyenne de la flotte, il ne borne rien pour le pire cas d’un conducteur, et il ne dit rien sur une deadline du réseau. Une moyenne flatteuse peut s’accommoder de latences jamais bornées.

Ce qui rend Tesla singulier : l’entreprise en revendique moins que les autres, du moins dans sa communication publique (accès au niveau 3 en Europe limité, progressif, sous autorisations nationales), et elle s’appuie sur un volume d’expérience que personne d’autre n’a, les millions de miles en conditions réelles. La statistique de flotte a une limite structurelle : les interventions humaines ne sont pas étiquetées par danger imminent, et ces données ne se convertissent pas en taux d’accidents. La mesure capture la qualité moyenne, pas la sûreté du pire cas.

Ce que le conducteur vit : la latence n’est pas une abstraction

Tout ce qui précède déplace une garantie à l’intérieur de la pile. Mais la pile a un utilisateur, et cet utilisateur ne raisonne pas en WCET : il raisonne en « la voiture a-t-elle réagi à temps ? ». La question de la deadline n’est pas seulement un problème d’ingénierie temps réel, elle est une expérience vécue, et les constructeurs le savent.

La conduite autonome ne demande pas seulement « une réponse », elle demande une réponse quasi instantanée. Sur autoroute à 130 km/h, le véhicule parcourt environ 36 mètres par seconde : une hésitation de quelques dixièmes de seconde translate le point de décision de plusieurs mètres. La fluidité perçue d’un système de conduite tient dans cette fenêtre. Un temps de réaction humain typique, de la perception à l’action, se situe autour de 200 ms (ordre de grandeur documenté en psychologie cognitive, voir Sources et méthode). Un produit de conduite qui se veut crédible doit donc au moins égaler, puis battre, ce repère : la boucle de décision tourne typiquement à une dizaine à une vingtaine de hertz (disons ~20 Hz, soit une itération toutes les ~50 ms pour le modèle de perception d’un système grand public comme openpilot), un rythme où le réseau doit produire une prédiction à chaque image de caméra sans jamais pouvoir promettre que le pire cas restera sous cette barre.

C’est ici que le déplacement de la deadline devient paradoxal pour le consommateur. Le réseau n’a pas de WCET, donc aucune garantie que l’itération la plus lente restera sous les 50 ms. Pourtant le conducteur attend, lui, une régularité quasi mécanique : la voiture doit freiner « maintenant », pas « dans le pire des cas ». La garantie existe bel et bien pour lui, elle a juste été déplacée ailleurs que sur le réseau, et c’est précisément ce qu’il ne voit pas.

Le paradoxe du quasi-instant : plus c’est fluide, plus la borne est loin

Il y a une tension que les quatre familles ne résolvent pas, elles la contournent. D’un côté, l’attente du marché : un assisteur qui vend de la conduite « sans à-coup », « rassurante », « qui anticipe », sous-entend une réponse bornée dans le temps. De l’autre, l’impossibilité physique de borner le réseau (divergence de warps, caches dépendants des données, DRAM partagée, ordonnanceur opaque). La réponse industrielle n’est pas de réduire l’écart : c’est de le dissimuler sous une couche qui, elle, répond dans le temps.

Prenez le cas de la latence de bout en bout telle que la vit le passager. Le réseau calcule une trajectoire, l’ordonnanceur de la puce laisse passer ou retarde le noyau selon la charge, le reste de la chaîne (planification, contrôle, commande de l’actuateur) ajoute son propre délai. Aucun de ces maillons n’est isolable en pire cas, donc la latence de bout en bout n’est pas une somme de bornes : c’est une distribution. Les constructeurs n’en vendent pas la distribution, ils en vendent le régime permanent, le cas où tout va bien, parce que c’est la seule chose qu’ils peuvent montrer. La deadline, au sens temps réel strict, n’est pas respectée par le réseau : elle est tenue malgré lui, par la couche de repli.

Cela explique un autre comportement de marché : la course aux TOPS et aux annonces de latence. Quand NVIDIA communique 1 000 TOPS INT8 pour le Thor, ou quand un concurrent affiche des temps de traitement d’image flatteurs, ces chiffres ne prouvent rien sur le pire cas. Ils parlent au consommateur et à l’acheteur flotte d’une puissance moyenne, d’une capacité nominale. La borne, elle, ne se trouve pas dans le Thor : elle se trouve dans la FSI, cette île de silicium certifiée qui ne fait pas d’inférence. Le chiffre qui rassure n’est pas celui qui garantit.

L’écart produit / promesse, vu du consommateur

Ce déplacement a une traduction commerciale directe, et elle mérite d’être nommée. Le client qui paie une option de conduite ne achète pas un WCET : il achète la promesse de ne plus avoir à conduire. Or cette promesse n’a pas la même nature selon l’acteur.

Chez Mercedes, la limite est écrite noir sur blanc dans l’homologation : un ODD très étroit (autoroute, conditions dégradées précises), une vitesse d’abord bloquée à 95 km/h fin 2024 puis une trajectoire vers 130 km/h sous R157 série 01. Le client sait, ou devrait savoir, où commence et où finit la garantie : elle porte sur la manœuvre de repli, pas sur la perfection du réseau. C’est la promesse la plus honnête, parce que la plus bornée.

Chez Tesla, la promesse est inverse : un déploiement progressif, une amélioration par mise à jour, et une communication de moins en moins ancrée dans une borne. Le client achète une trajectoire, pas un contrat temporel. La statistique de flotte dit « en moyenne ça marche », jamais « dans le pire cas ça répond ». Entre les deux, le consommateur ne compare pas la même chose : d’un côté une garantie réglementaire étroite, de l’autre une démonstration statistique large. Comprendre que la deadline a été déplacée, et où, c’est précisément ce qui permet de lire ces offres à la même échelle.

La question que le conducteur devrait pouvoir poser n’est pas « à quelle vitesse le réseau pense-t-il », mais « qui répond quand le réseau ne peut plus ». C’est la seule question à laquelle les quatre familles donnent chacune une réponse définie, et c’est la seule qui lie l’architecture de la puce à ce que vit la personne assise derrière le volant.

La deadline se déplace : synthèse

Les quatre familles tracent un même arc : le refus de poser la garantie sur le réseau.

Famille	Couche qui porte la deadline	Nature de la garantie	Faiblesse
NVIDIA (FSI)	Silicium dédié, île de sûreté	Temporelle, fonctionnelle (ASIL-D capable)	Ne couvre pas le réseau lui-même
Mobileye (RSS)	Règles formelles	Responsabilité, logique de la décision	Silencieux sur la perception
Mercedes (MRM)	Homologation ONU R157	Manœuvre de repli bornée	ODD étroit, dépend de la reprise
Tesla (flotte)	Statistique de flotte	Qualité moyenne, pas borne	Aucune borne pire-cas

La réponse à la question initiale (qui garde la deadline de la décision autonome ?) apparaît alors clairement : personne ne la met sur le réseau. Chacun l’a déplacée sur une couche qu’il sait borner. Le WCET n’est pas calculé, il est déplacé, et la conséquence est une zone d’incertitude que chacun assume à sa manière.

Conclusion : la prochaine frontière

Si la deadline ne vit plus dans le modèle, la question qui suit s’impose : comment garantir la perception ? Les quatre familles la traitent par la statistique (tests massifs, flotte), et aucune ne la borne formellement. La prochaine frontière du temps réel automobile n’est peut-être plus l’exécution, mais l’honnêteté des mesures : combien de miles, combien de cas extrêmes, et surtout quelle détection d’une impossibilité de continuer.

Mais cette frontière a un visage grand public. Le conducteur ne lit pas de WCET : il juge si la voiture a freiné à temps, et il achète la promesse de ne plus avoir à juger. Or la garantie qu’il imagine (réponse quasi instantanée, bornée) n’est jamais portée par le réseau. Elle est déplacée, et c’est précisément ce déplacement qui fait tenir l’offre : le client vit la fluidité, l’architecture porte la zone d’incertitude. Comprendre où chacun a remis la deadline, c’est la seule façon de comparer les promesses à la même échelle, entre une homologation étroite et une démonstration statistique.

La voiture saura dire « je ne peux plus conduire » avant de manquer l’échéance : c’est l’aboutissement du déplacement, pas sa disparition. La borne n’a pas été calculée, elle a été confiée à la couche de repli. Reste à savoir si le règlement, et le client, sauront la lire.

Sources et méthode

Faits vérifiés (V)

• ECRTS 2025, Bounding the WCET of a GPU Thread Block (Jeanmougin, Carle, Rochange) : le statut de « problème ouvert » du WCET GPU est la conclusion du papier. drops.dagstuhl.de : LIPIcs, vol. 335, art. 11 (DOI 10.4230/LIPIcs.ECRTS.2025.11). Borne sûre démontrée pour un thread block sous hypothèses (Accel-Sim, ~12 % d’écart moyen vs mesuré).

• RTAS 2024, Demystifying NVIDIA GPU Internals (Bakita, Anderson) : préemption partielle, ordre non-FIFO entre streams, FIFO conservé dans une même stream. cs.unc.edu.

• RSS, arXiv 1708.06374 (Shalev-Shwartz, Shammah, Shashua, Mobileye) : cadre formel de la responsabilité. doi.org/10.48550/arxiv.1708.06374.

• Règlement ONU R157 (séries 00 et 01) : manœuvre de repli MRM, exigences de décélération, comportement de sortie d’ODD. unece.org.

• Première homologation L3 Mercedes Drive Pilot (KBA, Allemagne, 9 décembre 2021) : group.mercedes-benz.com. Extension 95 km/h fin 2024 (source Mercedes), trajectoire vers 130 km/h dans le cadre R157 élargi.

• Functional Safety Island (AGX Orin) : citation verbatim de la doc NVIDIA (DriveOS 7.0.3) : « Availability of ~10K ASIL D MIPS for any of the safety functions » et « 4 x DCLS (Dual Core Lock Step) R52 (ARMv8-R) CPUs », avec un « independent and dedicated XTAL and voltage rail ». developer.nvidia.com : DriveOS 7.0.3, Functional Safety Island.

• Temps de réaction humain ~200 ms : ordre de grandeur documenté en psychologie cognitive pour la perception-à-action (Wikipédia, Reaction time, synthèse des études de temps de réaction simple visuelle). Sert de repère au paragraphe « Ce que le conducteur vit » : un produit de conduite crédible doit au minimum égaler ce délai.

Estimations crédibles (ESTIMATION)

• Les 1 000 TOPS INT8 du Thor et l’argument « ASIL-D capable » : valeurs communiquées par NVIDIA sur la fiche produit officielle. developer.nvidia.com : DRIVE AGX. Le chiffre 2 000 est en FP4, ne pas mélanger les unités.
• Métrique « miles par intervention » de Tesla : valeur publiée par Tesla dans son rapport trimestriel officiel (tesla.com/fsd/safety : Vehicle Safety Report). L’article cite le concept de la métrique (miles entre interventions humaines), pas un chiffre : classée ESTIMATION, car le paramètre « Autopilot plus sûr » déduit de ces données est trompeur sans contrôle des variables (usage principalement autoroutier, pas de groupe de contrôle).

Hypothèses du dossier (HYPOTHÈSE)

• La lecture des quatre familles (puce, règle, homologation, statistique) comme un déplacement unitaire des garanties : grille de lecture proposée par la rédaction, assumée comme telle.
• La convention des 100 ms de latence de perception est une convention de la littérature (projets comme Autoware), non une exigence normée : à étayer contre le corpus ISO 26262 / ISO 21448 avant publication.
• La fréquence de boucle ~20 Hz (~50 ms par itération de perception) pour un système grand public est un ordre de grandeur indicatif (référence openpilot), présenté comme hypothèse : la valeur exacte dépend du produit et n’est pas la conclusion du dossier.