DIVAS - Description détaillée de l'architecture logicielle du système complet. Livrable N 3.A.1. Responsable : Samer Ammoun

Transcription

1 DIVAS - Description détaillée de l'architecture logicielle du système complet Livrable N 3.A.1 Date: Mai 2008 Version: 1.0 Partenaires: Auteur: Sujet: Volet: Diffusion: Nombre de pages:14 ARMINES LCPC ESE LCPC SMI INRETS INRIA Samer Ammoun N 3 : Conception d'ens emble et tests A - Description détaillée de l'architecture logicielle Partenaires DIVAS Responsable : Samer Ammoun Acteurs : Nicolas Hautière Vincent le Cam Jean Emmanuel Deschaud Arnaud de La Fortelle Financement: Projet financé par l Agence Nationale de la Recherche

2 Table des matières 1 Introduction 3 2 Serveur de base de données 3 3 Répartition des fonctions entre le serveur opérationnel et la plateforme embarquée Fonctions relatives au serveur opérationnel L estimation de la distance de visibilité géométrique du véhicule L estimation d un indice d adhérence L estimation de la vitesse recommandée La base de données sur le serveur opérationnel Fonctions relatives à la plateforme embarquée La cartographie 1D 12 5 Cas d utilisation 13 6 To-Do-List 14 2

3 1 Introduction Dans ce document, nous proposons une conception de l architecture du système fonctionnel Divas. Ce système a pour fonction principale la mise en œuvre d un dialogue entre l infrastructure routière et les véhicules circulant sur celle-ci. Ce dialogue permet donc d alimenter le véhicule par des informations qui lui permettent de : 1. Prédire des zones de risque sur les routes 2. Avoir des recommandations pour optimiser son profil de conduite Ces recommandations sont issues d une multitude de modules qui fournissent des connaissances sur la route et sur les meilleures manœuvres à effectuer. Pour concevoir un tel système, nous procédons selon deux étapes successives : La production d une base de données lourdes (ou brutes) issues des diverses acquisitions réalisées par les partenaires du projet et regroupées dans un serveur de base de données SB. A partir de cette base de données, nous produisons deux sous ensembles légers de données. Ces nouvelles bases de données sont conçues spécialement pour intégrer respectivement le serveur opérationnel SO communicant du côté de l infrastructure routière et la plateforme embarquée PE sur les véhicules. La figure 1 permet d illustrer notre concept. Dans celle-ci, chaque plateforme embarquée dans le véhicule dialogue avec le serveur opérationnel qui correspond à sa trajectoire. A travers l architecture proposée dans ce document, nous allons tenter de répondre à deux questions essentielles : Selon quels critères, pouvons-nous répartir les fonctions (et par la suite les données) entre le serveur opérationnel et la plateforme embarquée? Comment produire, à partir des données brutes, les bases de données allégées à utiliser lors de la communication? Dans la suite de ce document, nous commencerons par la description de la base de données au niveau du serveur SB. A partir d une analyse fonctionnelle du système, nous répartissons les données et les tâches entre le serveur opérationnel et la plateforme embarquée. Ensuite, nous présenterons un cas d utilisation pour illustrer l architecture choisie à travers un exemple concret. 2 Serveur de base de données Le serveur de base de données est conçu pour collecter les bases de données acquises dans le cadre du projet. Ces données sont classées en deux grandes catégories : Les données de caractérisation des parcours étudiés : ces informations sont le fruit des études et des mesures effectuées sur les deux sites d expérimentation. Ces données sont listées dans le tableau 1. Les informations historiques : ces informations viennent enrichir la connaissance sur les sites d expérimentation en introduisant des données sur l historique du site en termes de pourcentage d accidents, de condition météo, etc. Les données de cette catégorie sont citées dans le tableau 2. 3

4 Données Responsable(s) Format Précision Fréquence Taille/unité de longueur Commentaires Cartographie 1D CG22, CG44, LR Lyon Modèle géométrique 3D Mines Adhérence LCPC(ESAR), MI Marquages LCPC ESE Vitesse maximale légale LR Lyon Vitesse temporaire CG22, CG44, ASF Tab. 1 Les données statiques du serveur de base de données Données Responsable(s) Format Précision Fréquence Taille/unité de longueur Commentaires Trajectoires des véhicules INRETS+ CETE, CAT+INRIA, CETE+ESE VL Trafic INRIA Historique météo et visibilité atmosphérique INRIA+ESE Historique d accidents INRIA+ESE Tab. 2 Les données historiques du serveur de base de données 4

5 Fig. 1 Le dialogue entre les serveurs opérationnels et les plateformes embarquées sur les véhicules Imara propose des ressources informatiques pour héberger ce serveur dans ses locaux. Un accès ftp à distance est fourni aux partenaires pour uploader et downloader les données acquises. La consultation de ce serveur est possible sur ftp.inria.fr : nom d utilisateur : divas mot de passe : Divas Les méthodes et moyens de receuil de données de l infrastructure sont présentés dans le cadre du livrable 1C.1 [1]. Pour le bon déroulement du projet, il est fort recommandé que les données mises sur le serveur soient ouvertes et exploitables par les partenaires en général et par les concepteurs de l architecture et les testeurs en particulier. Dans cet objectif, nous proposons que toutes les données mises sur le serveur soient écrites en langage XML (Extensible Markup Language). Ce langage est un langage informatique de balisage générique qui facilite l échange automatisé de contenus entre systèmes d informations hétérogènes. A titre d exemple, nous présentons une structure de données écrites en XML. La première ligne correspond à la déclaration du document. Elle définit la version ainsi que l encodage (le jeu de caractères) utilisés pour ce document. Chaque noeud du document XML est appelé ELEMENT (comme le nœud SEGMENT). Un élément peut lui même contenir d autres éléments (notion de parent - enfant) 5

6 et ce sans limite. Les éléments peuvent contenir des ATTRIBUTS (comme l ID de l élement SEGMENT) qui doivent toujours être associés à des valeurs écrites entre cotes. La figure 2 permet d illustrer graphiquement la hiérarchie de cette base de données. <?xml version= 1.0 encoding= ISO ?> <DIVAS TYPE= SO > <SEGMENT ID= 456 NIVEAU= 0 > <NOEUD TYPE= début > <LON> </LON> <LAT> </LAT> <VISIBILITE VIS TYPE= GEO > <HAUT HAUTEUR = 2 DISTANCE= 53 ></HAUT> <HAUT HAUTEUR = 2.5 DISTANCE= 55 ></HAUT> <HAUT HAUTEUR = 3 DISTANCE= 56 ></HAUT> </VISIBILITE> </NOEUD> <NOEUD TYPE= fin > <LON> </LON> <LAT> </LAT> <VISIBILITE VIS TYPE= GEO > <TAB VIS HAUTEUR = 2 DISTANCE= 53 ></TAB VIS> <TAB VIS HAUTEUR = 2.5 DISTANCE= 55 ></TAB VIS> <TAB VIS HAUTEUR = 3 DISTANCE= 56 ></TAB VIS> </VISIBILITE> </NOEUD> </SEGMENT> <SEGMENT ID= 457 NIVEAU= 0 > <NOEUD>. </NOEUD> <NOEUD>. </NOEUD> </SEGMENT> </DIVAS> 3 Répartition des fonctions entre le serveur opérationnel et la plateforme embarquée L objectif du projet est de concevoir un dialogue entre l infrastructure et le véhicule dans une relation bénéfique pour les deux parties. D une part, le véhicule est alimenté par un flux de données sur sa trajectoire future. Quand le véhicule reçoit les informations historiques, statiques et dynamiques, il tente de les valider par ses propres observations et d en extraire des recommandations sur son profil de conduite. D autre part, l infrastructure utilise les capteurs embarqués sur les véhicules comme une source d informations supplémentaires pour enrichir sa connaissance 6

7 Fig. 2 Le schéma de l hiérarchie de la base de données dans l exemple précédent sur l environnement (la visibilité atmosphérique et le trafic par exemple). Nous proposons dans ce document de suivre une démarche qui part de l analyse de besoin et des contraintes pour définir les bases de données et la répartition des fonctionnalités. En effet, la répartition de tâches entre le SO et le PE est contrainte par les conditions suivantes : Dans le système DIVAS, la génération des recommandations doit être faite par le véhicule lui même et non pas par les serveurs opérationnels. Le choix pris dans le projet est de ne pas générer des alertes sur bord de route. Ce choix implique que les données calculées sur le serveur opérationnel doivent être complétées, une fois reçues par le véhicule, par les informations des capteurs embarqués et les paramètres spécifiques du véhicule. Grâce à cette étape de validation, le véhicule sera capable d auto-générer des recommandations et des alertes. La requête d informations est toujours initiée par le véhicule. En effet, le véhicule informe l infrastructure de sa position et lui communique en même temps la demande d une information spécifique et certains paramètres nécessaires au calcul de cette requête. En réponse, l infrastructure interroge sa base de données, estime le paramètre demandé et le renvoie au véhicule. La capacité des outils de communication utilisée en termes de débit et de portée. Les capacités de stockage et de calcul des deux entités. En vu de ces contraintes et recommandations, nous proposons de répartir les tâches entre PE et SO de la manière suivante : 7

8 3.1 Fonctions relatives au serveur opérationnel le serveur opérationnel est responsable d estimer les trois paramètres suivantes : 1. Une distance de visibilité géométrique 2. Un indice d adhérence 3. Une vitesse recommandée Ces paramètres sont calculés, suite à une requête de la plateforme embarquée sur le véhicule, à partir de : 1. La base de données sur le serveur opérationnel 2. Les paramètres du véhicule envoyés dans la requête de demande d informations 3. Les données dynamiques : informations météo, heure de la journée, etc. Dans la suite du paragraphe, nous allons détailler les paramètres à estimer par le serveur opérationnel L estimation de la distance de visibilité géométrique du véhicule Ce paramètre est essentiellement calculé à partir du modèle géométrique de l environnement acquis par LaRA3D. Par souci de légèreté et de rapidité de calcul, le serveur opérationnel ne doit pas contenir le modèle géométrique dans sa forme brute. En effet, un calcul préalable (hors ligne) effectué sur le modèle géométrique permet d échantillonner l espace de la route et de produire pour chaque position de véhicule une table de visibilité pour différentes hauteurs du véhicule. Entrées : la position du véhicule : information dynamique envoyée par le PE. la hauteur du conducteur dans le véhicule : information statique envoyé par le PE. un tableau bidimensionnel de distance de visibilité : information calculée, hors ligne, à partir du SB. un indice de visibilité nocturne : information obtenue à partir de l étude sur les marquages au sol. Ce coefficient sert à pondérer la distance de visibilité géométrique en fonction de l heure de la journée. Le schéma bloc présenté sur le figure 3 illustre ce concept L estimation d un indice d adhérence Cet indice d adhérence ne tient pas compte des paramètres du véhicule. Il est calculé en fonction de la qualité de la chaussée et des conditions météo. Entrées : la position du véhicule : information dynamique envoyée par le PE. la fonction d adhérence : obtenue à partir d une étude préalable effectuée sur la chaussée. les conditions météo : information dynamique envoyée par le PE. (Dans le cas des autoroutes, il est envisageable d utiliser des stations météo déjà implantées sur l infrastructure). 8

9 Fig. 3 Le calcul de la distance de visibilité géométrique au niveau du serveur opérationnel un indice de l usure de la chaussée (calculé à partir du trafic (LCPC ESAR)) Dans le cadre du projet, le document 1C.2 [2] étudie en profondeur le problème d adhérence. Le schéma bloc de la figure 4 illustre ce concept. Fig. 4 Le calcul de l indice d adhérence au niveau du serveur opérationnel L estimation de la vitesse recommandée A ce niveau, la vitesse recommandée par le SO ne tient compte que des limitations des vitesses réglementaires et de l intervalle de vitesse optimale obtenu durant les acquisitions par les conducteurs experts. Le résultat de ce module de calcul de la vitesse est utilisé par le véhicule pour générer sa propre vitesse recommandée. Entrées : la position du véhicule : information dynamique envoyée par le PE. la vitesse réglementaire : obtenue à partir des acquisitions VANI et des vitesses temporaires. l intervalle de vitesses admises en fonction de l analyse de l étude de trajectographie : cet intervalle est obtenu à partir de l analyse des trajectoires des conducteurs experts. 9

10 les zones à risques La figure 5 schématise ce concept. La figure 6 regroupe l ensemble des fonctions Fig. 5 Le calcul de la vitesse recommandée au niveau du serveur opérationnel du serveur opérationnel La base de données sur le serveur opérationnel D après l analyse fonctionnelle déjà présentée, nous pouvons déterminer la base de données qui doit exister sur le serveur opérationnel : Table de distance de visibilité géométrique Table de visibilité nocturne Vitesse réglementaire Intervalle de vitesse recommandée Fonction d adhérence Indice d usure de la chaussée Zones à risques Ces données sont produites à partir de la base de données sur le serveur de base de données SB. La figure 7 présente un schéma bloc de la transformation entre des deux bases de données. 3.2 Fonctions relatives à la plateforme embarquée La plateforme embarquée prend l initiative de demander aux serveurs opérationnels des informations qui lui permettent de générer à bord des alertes et des recommandations pour améliorer son profile de conduite. Les paramètres estimés à bord du véhicule sont les suivantes : 1. L estimation de la position du véhicule 2. La mesure de la vitesse du véhicule 3. L estimation de la distance de visibilité atmosphérique 4. L estimation des conditions météo 5. L estimation de la distance de visibilité finale 6. L estimation de l adhérence du véhicule 10

11 Fig. 6 Les fonctions du serveur opérationnel 7. L estimation de la vitesse recommandée Dans la suite, nous allons détailler les méthodes d estimation de ces paramètres. L estimation de la position du véhicule à partir du récepteur GPS embarqué L estimation de la vitesse du véhicule (GPS, odomètre,...) L estimation de la distance de visibilité atmosphérique par vision à partir d une caméra vidéo embarquée sur le véhicule. L estimation des conditions météo par vision à partir d une caméra vidéo embarquée sur le véhicule. L estimation de la distance de visibilité : Ce module doit combiner la distance de visibilité géométrique reçue en provenance du serveur opérationnel et la distance de visibilité atmosphérique obtenue localement à partir du capteur vision. Entrées : la distance de visibilité géométrique (en provenance du SO) la distance de visibilité atmosphérique (estimée à bord du véhicule) 11

12 Fig. 7 La production de la base de données du SO à partir des données sur le SB Le calcul de l adhérence du véhicule Entrées : l indice d adhérence (en provenance du SO) les conditions météo les caractéristiques techniques du véhicule Le calcul de la vitesse recommandée par PE Entrées : la vitesse recommandée par SO l adhérence personnalisée la distance de visibilité le modèle du conducteur La figure 8 représente ces différentes fonctionnalités. 4 La cartographie 1D L ensemble des traitements et des fonctions présents sur le serveur opérationnel et sur la plateforme embarquée sont des fonctions de la position du véhicule. D où la nécessité d adopter un système référentiel spatial. Toutes les données acquises durant le projet doivent être recalées dans ce système référentiel. Ce- 12

13 pendant, l utilisation d une telle base de données n est pas évoquée dans la présentation du projet. D ailleurs, deux solutions se présentent : 1. L utilisation d une base de données cartographique type Navteq, Teleatlas ou toute autre base cartographique disponible dans le cadre du projet. Avantages : - Données structurées et fiables - Disponibilité de solutions logicielles de map matching (type ADASRP) Inconvénients : - Nécessité d une licence d exploitation dans le cadre du projet - Données rigides et fermées 2. La transformation de la base de données VANI en une forme de base de données cartographique. Avantages : - Contrôle total sur les formats des bases de données cartographiques Inconvénients : - Conception et développement d une structure de données et d outils de map matching - Exploitation limitée aux démontrastions du projet Divas Dans les deux cas de figures, l objectif est de créer une base de données cartographique enrichie par les informations acquises dans le cadre du projet. Notons aussi que l adoption d une base de données cartographique doit prendre en compte le fait que le calcul des dangers peut exiger une description fine de la géométrie de la route (description en abcisse curviligne, dévers, largeur de voie, courbure, etc). 5 Cas d utilisation Dans ce paragraphe, nous présentons un cas d utilisation dans le but d illustrer à travers un exemple concret le fonctionnement du système Divas. 1. Avant de commencer son trajet, le conducteur doit définir sa destination. 2. En utilisant cette destination, la plateforme embarquée définit une trajectoire du véhicule. 3. Le véhicule établit une connexion avec le serveur opérationnel le plus proche. 4. Le véhicule envoie des requêtes d informations (adhérence, visibilité et vitesse recommandée) au serveur opérationnel. 5. Le serveur opérationnel communique à fur et à mesure à la plateforme embarquée les paramètres de son chemin. Le SO communique donc au PE les informations relatives au x prochains kilomètres. Le nombre x est fonction de la capacité des outils de communications et de la quantité d informations échangées. 6. Le serveur opérationnel utilise les informations envoyées par le véhicule pour enrichir sa base de données sur les conditions météo par exemple. 13

14 7. Le véhicule anticipe sa trajectoire en calculant à l avance les recommandations pour améliorer son profil de conduite. 8. Bien que la liaison véhicule-conducteur n est pas traité dans le cadre du projet, la présence d un IHM qui communique les alertes et les recommandations au conducteur est primordiale sur le plan fonctionnel. 9. Le véhicule envoie périodiquement des requêtes au serveur pour mettre à jour sa trajectoire, télécharger les informations de sa trajectoire future et enrichir les données sur le serveur opérationnel par les informations des capteurs embarqués sur le véhicule. 10. Durant son parcours, le véhicule communique avec le serveur opérationnel le plus proche. Par conséquent, la communication doit prendre en compte ce handover entre les serveurs opérationnels. 6 To-Do-List 1. La définition, par chaque partenaire, des informations relatives à son domaine dans les deux tableaux 2 et La rédaction, par chaque partenaire, du format de ces données 3. La définition d un format d échange de données. 4. La collecte des données de caractérisation des trajectoires sur le serveur de base. 5. la définition des procédures de transformation des bases de données brutes en des bases de données du serveur opérationnel et de la plateforme embarquée. Références [1] DIVAS - Moyens de recueil des paramètres d infrastructure, N 1C.1, Version 2.1, Mai [2] DIVAS - Modèles d évolution temporelle de l adhérence de la chaussée et de la rétro-réflexion des marquages, N 1C.2, Version 2.1, Mai

15 Fig. 8 Les fonctions de la plateforme embarquée 15