Un dimanche, en mai dernier, un conducteur qui circulait sur l'autoroute A270 entre Helmond et Eindhoven, aux Pays-Bas, a freiné brutalement en pleine heure de pointe. Le ralentissement soudain qui s'en est suivi a forcé les conducteurs derrière lui à freiner, provoquant ainsi un effet en chaîne appelé onde de choc dans le jargon des experts en simulation du trafic routier. Même si le véhicule de tête a réaccéléré immédiatement après son freinage brutal, cette onde de choc peut immobiliser le trafic et ainsi générer un bouchon car chaque conducteur de la chaîne ralentit afin d'éviter une collision avec le véhicule qui le précède. Pourtant,ce jour-là,aucun embouteillage n'a été observé. Et cela pour une seule raison: 10% à 30% des véhicules présents sur l'autoroute expérimentaient une technologie qui amortit les ondes de choc et assure une fluidification du trafic après des incidents de freinage soudain, en exploitant les informations délivrées par des unités de bord de route (ou RSU, pour Road Side Unit ).Au cœur de cette technologie se trouve une unité embarquée (ou OBU, pour On-Board Unit ), un équipement matériel en cours de développement parTomTom.

Préparation à la conduite coopérative sur l'autoroute A270

Conçue pour le système d'exploitation Android, l'OBU transmet des informations de navigation au conducteur. Le logiciel d'amortissement des ondes de choc installé sur cet équipement utilise une technique appelée «système de conduite coopératif», qui optimise le flux du trafic via l'exploitation conjointe des OBU et des RSU. Les ingénieurs de l'organisme d'innovation TNO ont modélisé le logiciel de l'unité embarquée dans Simulink. Ils ont ensuite développé un processus pour déployer le modèle sur l'OBU Android à l'aide de Simulink Coder.

Les terminauxAndroid installés sur les véhicules test fonctionnent en synergie avec le matériel de surveillance et de contrôle installé sur un tronçon de l'A270 long de 5 kilomètres. Ce matériel se compose de 48 caméras vidéo montées sur des poteaux espacés de 100 mètres (voir figure 1 ) et de 11 passerelles de communications espacées de 500 m. Un ordinateur RSU traite les images des caméras, calcule un profil de vitesse optimale pour les véhicules qui traversent chaque section de l'autoroute, puis transmet ce profil de vitesse aux véhicules par l'intermédiaire de passerelles de communi-cationsWi-Fi.Dès que le RSU détecte le début d'une onde de choc, il recalcule les profils de vitesse afin de ralentir progressivement les véhicules se rapprochant.Les véhicules les plus éloignés de l'incident n'auront pas ou presque pas à réduire leur vitesse.Les véhicules les plus proches, quant à eux, devront ralentir plus fortement,sans toutefois provoquer une onde de choc. Le comportement des véhicules en communication avec le RSU influence le comportement des autres véhicules dans le flux du trafic. Dans ce contexte, il n'est pas nécessaire d'équiper tous les véhicules d'unités embarquées OBU. En réalité, seuls 20 des 68 véhicules qui ont participé au test mené sur l'A270 étaient équipés d'OBU. Parmi eux, 8 disposaient d'un système de régulation de vitesse intelligent (ACC, pour Adaptive Cruise Control ) piloté directement par l'OBU, qui adapte automatiquement la vitesse du véhicule. Dans les 12 autres véhicules, l'OBU affichait la vitesse optimale suggérée (voir figure 2 ) et le conducteur accélérait ou décélérait manuellement.

Figure 1. Expérimentation grandeur nature Les terminaux Android installés sur les véhicules test fonctionnent en synergie avec le matériel de surveillance et de contrôle installé sur un tronçon de l'A270 long de 5 kilomètres. Ce matériel se compose de 48 caméras vidéo montées sur des poteaux espacés de 100 mètres et de 11 passerelles de communications espacées de 500 mètres.

Modélisation du logiciel de l'unité embarquée OBU

Le système de régulation de l'OBU détermine la vitesse du véhicule à l'aide des coordonnées du système GPS intégré et de son accéléromètre. Il traite également les mises à jour du profil de vitesse transmises par le RSU, met à jour l'affichage de l'OBU et génère des messages CAN afin de définir la vitesse ACC lorsque le système tourne en mode automatique. L'intégralité du système de régulation a été modélisée dans Simulink et Stateflow, et des simulations ont été réalisées à partir de données d'entrée issues de précédents tests sur route. Dans les semaines qui ont précédé les tests sur route, le mode externe de Simulink a été utilisé pour vérifier les performances en temps réel des interfaces du système avec le bus CAN, le RSU et l'affichage sur l'ordinateur de bord. Ces simulations ont permis d'analyser et de corriger les algorithmes avant de mener les tests sur route. Elles ont joué un rôle essentiel dans la réussite du projet étant donné que chaque test sur route exigeait la fermeture de l'autoroute aux autres véhicules et la coordination des 68 conducteurs volontaires.

Les opérations consistant à modéliser et simuler le système de régulation de l'OBU se sont avérées relativement simples grâce à l'expérience de l'équipe d'ingénieurs TNO en matière de Model-Based Design . En revanche, ils manquaient d'expérience en ce qui concerne le développement de logiciels pour Android. Basé sur le noyau Linux, le système d'exploitation Android est conçu pour utiliser des applications Java, également appelées Apps. Les données d'entrée et de sortie d'un terminal Android (notamment celles de l'accéléromètre et du GPS) sont accessibles à n'importe quelle application Java installée sur ce terminal. Il n'était pas possible de générer de code Java à partir du modèle Simulink, et ni de générer de code C pour un exécutable autonome et de le déployer directement sur Android.

Réalisation de tests sur route et traitement des résultats

Pour résoudre cette problématique, une nouvelle approche permettant d'exécuter un modèle Simulink surAndroid a été adoptée. Cette approche fait appel au NDK ( Native Development Kit ) d'Android, un ensemble d'outils qui donne la possibilité aux ingénieurs d'implémenter des parties de leurs applications via des langages en code natif de type C et C++. L'interface JNI ( Java Native Interface ) procure l'infrastructure d'échange de données entre les parties Java de l'application et une bibliothèque partagée créée en C ou C++. Une cible pour Simulink Coder, qui génère du code pour une bibliothèque partagée plutôt qu'un exécutable autonome, a par ailleurs été créée. Le code C dans la bibliothèque partagée comprend des fonctions destinées à initialiser le modèle, exécuter un pas de calcul du modèle et fermer le modèle. Le code intègre également des fonctions d'accès aux données d'entrée et de sortie de Java via l'interface JNI et une interface de mode externe pour accéder aux paramètres et aux données lors de l'exécution. Les tableaux Java étant structurés différemment des tableaux C, le code comporte également des fonctions qui transforment les tableaux de Java en C et de C en Java. Enfin, le fichier makefile , qui est un modèle standard pour permettre la compilation d'une cible Android à l'aide du NDK, a été mis à jour.

Figure 3. Effet du système d'amortissement des ondes de choc sur la fluidification du trafic Ces tracés représentent la position des véhicules en fonction du temps dans des conditions normales (à gauche) et avec le système d'amortissement des ondes de choc en action (à droite). La couleur de chaque position du tracé indique la vitesse en km/h du véhicule qui se trouve à la position concernée.

Visualation de la fluidification du trafic

Bien que la simulation ait permis d'éliminer la majeure partie des problèmes liés au système de régulation, les tests sur route ont révélé d'emblée des problèmes relatifs à l'affichage et au traitement des données de profil de vitesse du RSU. Pour résoudre ces problèmes, le modèle Simulink a dû être mis à jour sur le terrain, puis le système a été redéployé. La possibilité de générer du code et de créer une application Android mise à jour d'un simple clic s'est ici avérée particulièrement précieuse: elle a permis d'apporter rapidement les modifications nécessaires et de reprendre les tests sur route dans le laps de temps qui était alloué à l'équipe pour avoir accès à l'autoroute. Consécutivement aux tests sur route, le logiciel Matlab a été utilisé pour effectuer le post-traitement des données recueillies lors des tests,notamment la mesure de la vitesse des véhicules et de la distance entre les véhicules. Des tracés de position des véhicules ont ainsi été générés en fonction du temps (voir figure 3 ). Les tracés ont confirmé ce que les tests avaient démontré: le système amortissait véritablement l'onde de choc et contribuait à fluidifier le trafic. Le tracé de gauche dans la figure 3 illustre les résultats d'un test sur route en l'absence du système d'amortissement des ondes de choc. A une distance de 3900m, le véhicule de tête freine, passant de 85km/h à 45km/h.Cette action crée une onde de choc qui affecte tous les véhicules avec,dans certains cas,une chute de la vitesse au-dessous de 20km/h. Une seconde onde de choc, provoquée par l'accélération des véhicules sortant de la première onde de choc, apparaît également. Le tracé de droite illustre les résultats d'un test mené dans les mêmes conditions, mais avec le système d'amortissement des ondes de choc. L'action de freinage du premier véhicule est exactement la même que dans le test précédent. Dans le cadre de ce test, le RSU a généré un profil de vitesse lors de la détection de la première onde de choc. Les véhicules équipés d'OBU ont réduit leur vitesse à 65km/h 1 500 m après l'onde de choc. Des vides ( représentés par des zones blanches sur le tracé ) sont ainsi apparus dans le flux du trafic.La première onde de choc a été amortie en seulement 30 secondes. Le tracé de droite fait également apparaître une seconde action de freinage des véhicules de tête. Cette fois encore, l'onde de choc a été amortie.La différence entre les deux actions de freinage est que,lors de la première, les véhicules équipés de l'OBU circulaient en mode conseil, tandis que lors de la seconde, ils circulaient en mode automatique.

Figure 2. Tableau d'affichage de l'OBU 20 des 68 véhicules qui ont participé au test mené sur l'A270 étaient équipés d'unités embarquées (OBU). Parmi eux, 8 disposaient d'un système de régulation de vitesse intelligent (ACC) piloté directement par l'OBU, qui adapte automatiquement la vitesse du véhicule. Dans les 12 autres véhicules, l'OBU affichait la vitesse optimale suggérée et le conducteur accélérait ou décélérait manuellement.

Le Model-Based Design et la nouvelle cible Android pour Simulink Coder sont désormais employés afin de développer une version optimisée du système. Cette version prend en compte les données d'entrée des feux de signalisation pour améliorer le flux du trafic dans et entre les villes.

Frank Engels, ingénieur chez TNO (organisme d'innovation) et chez TMC (société de conseils et d'ingénierie) Article adapté par Pascal Coutance