Développement d’une technologie embarquée de fluidification du trafic pour Android à l’aide de Simulink

Par Frank Engels, TNO, TMC

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 à freiner, provoquant un effet en chaîne ou onde de choc. Même si le véhicule de tête réaccélère immédiatement, une onde de choc peut immobiliser le trafic car chaque conducteur de la chaîne ralentit afin d’éviter une collision avec le véhicule qui le précède.

Ce jour-là cependant, aucun embouteillage n’a été observé. En effet, 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 des unités en bordure de route (RSU) [1].

Au cœur de cette technologie se trouve l’unité embarquée (OBU), un équipement matériel en cours de développement par TomTom. L’OBU, conçue pour le système d’exploitation Android, 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 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™.

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

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 (Figure 1) et de 11 passerelles de communications espacées de 500 mètres.

Figure 1. Caméras le long de l’autoroute A270.
Figure 1. Caméras le long de l’autoroute A270.

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 communications Wifi.

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) 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 (Figure 2) et le conducteur accélérait ou décélérait manuellement [2].

Figure 2. Tableau d’affichage de l’OBU.
Figure 2. Tableau d’affichage de l’OBU.

Modélisation du logiciel de l’unité embarquée (OBU)

Le système de régulation de l’OBU détermine la vitesse actuelle 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.

Nous avons modélisé l’intégralité du système de régulation dans Simulink et Stateflow®, et avons réalisé des simulations à 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, nous avons utilisé le mode externe de Simulink 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 nous ont permis d’analyser et de corriger nos 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.

Génération du code pour la plateforme Android

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, nous manquions 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. Nous ne pouvions pas générer de code Java à partir de notre modèle Simulink, et nous ne pouvions pas non plus générer de code C pour un exécutable autonome et le déployer directement sur Android.

Pour résoudre cette problématique, nous avons adopté une nouvelle approche permettant d’exécuter un modèle Simulink sur Android. 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++.

Nous avons créé une cible pour Simulink Coder, qui génère du code pour une bibliothèque partagée plutôt qu’un exécutable autonome. 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 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, nous avons mis à jour le fichier makefile modèle standard pour permettre la compilation d’une cible Android à l’aide du NDK.

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

Bien que la simulation nous 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, nous avons dû mettre à jour notre modèle Simulink sur le terrain, puis redéployer le système. La possibilité de générer du code et de créer une application Android mise à jour d’un simple clic s’est avérée particulièrement précieuse : elle nous a permis d’apporter rapidement les modifications nécessaires et de reprendre les tests sur route dans le laps de temps pendant lequel nous avions accès à l’autoroute.

Consécutivement aux tests sur route, nous avons utilisé MATLAB® 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. Nous avons généré des tracés de position des véhicules en fonction du temps (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.

Figure 3. Tracés indiquant 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.
Figure 3. Tracés indiquant 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.

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. À 3900 mètres, le véhicule de tête freine, passant de 85 km/h à 45 km/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 20 km/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 [1].

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 à 65 km/h 1500 mètres 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.

Nous utilisons maintenant le Model-Based Design et la nouvelle cible Android pour Simulink Coder 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.

Publié 2012 - 92146v00

Références

[1]   B.D. Netten, T.H.A. van den Broek, I. Passchier et P. Lieverse, « Low Penetration Shockwave Damping with Cooperative Driving Systems », 8e Congrès européen dédié aux systèmes de transport intelligents (ITS) à Lyon (France), du 6 au 9 juin 2011.

[2] T. van den Broek, B. Netten et P. Lieverse, « Results of Cooperative Driving Applications », 8e Congrès international de l’automobile d’Eindhoven (Pays-Bas), les 16 et 17 mai 2011.



View Articles for Related Industries

Start a new search