Rapport technique final

Transcription

Rapport technique final
Décision attributive d’aide
ESIEE N° 0603C0128, LUMIPLAN N° 0603C0129, INEREC N° 0603C0130
Agence Nationale de la Recherche
Agence de l’environnement et de la maîtrise de l’énergie
Programme PREDIT Transports Intelligents
Notification du 16 Mai 2007 – Durée 36 mois
INFOMOVILLE
Environnement temps-réel pour l’INFOrmation, l’orientation et la sécurité des voyageurs à handicap sensoriel
(visuel ou auditive) au cours de leurs déplacements dans les transports collectifs, les pôles d’échanges et de façon
plus générale pour la MObilité en VILLE
Nom et Service
Date
Sujet et pages
G. BAUDOIN
ESIEE
1er juillet 2010
12 juillet 2010
14 juillet 2010
15 juillet 2010
-
Établi par :
O. VENARD
ESIEE
11 juillet
12 juillet 2010
14 juillet 2010
-
Coordonné et
approuvé par :
Y. LEMAITRE
N. LORIEUX
6 juillet 2010
9 juillet 2010
G. Baudoin
15 juillet 2010
CLASSIFICATION CONSORTIUM
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
-
Avant-propos et résumé du projet
INFOMOVILLE : pages 8 à 9
introduction, description générale du système :
pages 10 à 19.
Chapitre 7 : localisation : pages 63 à 94.
Intégration générale du document.
Chapitre 3 et annexes N1, N2 : normalisation
information : pages 20 à 24 et 110 à la fin.
Chapitre 4 : intégration du protocole SIRI :
pages 25 à 34.
Chapitre 6 : applications sur smartphones :
pages 53 à 62.
Chapitre 7 : Borne: pages 35 à 52.
Annexes B1 et B 2: pages 95/101 et 102/119
NUMÉRO DOCUMENT / DOCUMENT NUMBER
100712_Infomoville_FinalTechnique.doc
PAGE
Page 1 sur 159
CE DOCUMENT EST LA PROPRIÉTÉ DES MEMBRES DU CONSORTIUM ET NE PEUT ÊTRE COMMUNIQUÉ À UNE TROISIEME PARTIE SANS AUTORISATION ÉCRITE DU CONSORTIUM.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 2 sur 159
Table des matières
AVANT-PROPOS .......................................................................................................................................................8
RÉSUMÉ DU PROJET ..............................................................................................................................................9
1
2
INTRODUCTION ...........................................................................................................................................10
1.1
ENJEUX ET PROBLÉMATIQUE .....................................................................................................................10
1.2
CONTEXTE PARTENARIAT ET DÉMARCHE ADOPTÉE ...................................................................................12
1.3
BIBLIOGRAPHIE DE LA SECTION .................................................................................................................12
DESCRIPTION GÉNÉRALE DU SYSTÈME INFOMOVILLE ...............................................................14
2.1
FONCTIONNALITÉS, ARCHITECTURE ET COMMUNICATION ENTRE ÉLÉMENTS .............................................14
2.1.1
La borne INFOMOVILLE ...................................................................................................................16
2.1.2
Dispositif utilisateur et applications logicielles associées ..................................................................17
2.2
3
TRAVAUX SUR LA NORMALISATION DE L’INFORMATION VOYAGEUR EFFECTUÉS AU
DÉBUT DU PROJET................................................................................................................................................20
4
5
3.1
CONTEXTE ................................................................................................................................................20
3.2
INTERFACE HOMME MACHINE DANS LES TRANSPORTS PUBLICS................................................................21
3.3
APPROCHE MÉTHODOLOGIQUE ..................................................................................................................21
3.4
LE PROJET INFOMOVILLE .....................................................................................................................23
3.5
BILAN DU TRAVAIL DE NORMALISATION AU SEIN DU TC278/WG3/SG3 ...................................................23
3.6
INTÉGRATION DU PROTOCOLE SIRI ....................................................................................................25
4.1
STRUCTURE ET SERVICES SIRI ..................................................................................................................25
4.2
STRUCTURE DU PROTOCOLE UTILISÉ DANS L’APPLICATION RAMPE.........................................................26
4.3
UTILISATION DES SERVICES SIRI POUR L’IMPLÉMENTATION DU PROTOCOLE INFOMOVILLE ................29
4.4
LE SYSTÈME D’INTERFACE SIRI IMPLÉMENTÉ À LYON SUR LE RÉSEAU SYTRAL.....................................30
4.5
CONCLUSION .............................................................................................................................................33
4.6
LA BORNE INFOMOVILLE ........................................................................................................................35
5.1
SPÉCIFICATIONS FONCTIONNELLES DES BORNES........................................................................................36
5.1.1
Principes..............................................................................................................................................36
5.1.1.1
Le Serveur d’Information Voyageur..........................................................................................36
5.1.1.2
Le véhicule.................................................................................................................................37
5.1.1.3
La Borne d’Information Voyageur ............................................................................................37
5.1.1.4
Le mobile ...................................................................................................................................37
5.1.2
Architectures........................................................................................................................................38
5.1.2.1
Architecture principale...............................................................................................................38
5.1.2.2
Architecture logicielle de l’UC InfoMoville..............................................................................39
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 3 sur 159
5.1.2.3
Communication BIV / SAEIV ...................................................................................................40
5.1.2.3.1 SIRI – mode direct ................................................................................................................40
5.1.2.3.2 SIRI – mode retenu ...............................................................................................................40
5.1.2.3.3 Conception du serveur SIRI (Borne).....................................................................................40
5.1.2.4
Communication BIV / Mobile ...................................................................................................42
5.1.2.5
Diagramme des échanges...........................................................................................................42
5.1.2.6
Extensions – Profil Infomoville .................................................................................................43
5.1.3
Échanges avec le Smartphone .............................................................................................................44
5.1.3.1
Déclenchement du carillon.........................................................................................................44
5.1.3.2
Véhicule à l’approche ................................................................................................................44
5.1.3.3
Demande du plan de quartier .....................................................................................................44
5.1.3.4
Demande d’identifiant d’arrêt d’une borne................................................................................45
5.1.3.5
Demande de vérification du status du système: .........................................................................45
5.1.4
Échanges entre les applicatifs de l’UC InfoMoville............................................................................45
5.1.4.1
Voyant et carillon.......................................................................................................................46
5.1.4.2
Annonce sonore .........................................................................................................................46
5.2
SPÉCIFICATIONS MATÉRIELLES DES BORNES ..............................................................................................47
5.2.1
Caractéristiques matérielles................................................................................................................47
5.2.2
Installation des bornes ........................................................................................................................49
5.2.2.1
Installation aux stations de tramway ..........................................................................................50
5.2.2.2
Installation aux arrêts de bus......................................................................................................51
5.3
BILAN EN VUE D’UN DÉPLOIEMENT ...........................................................................................................52
5.4
ANNEXES LIÉES À LA BORNE .....................................................................................................................52
5.5
RÉFÉRENCES POUR LA SECTION .................................................................................................................52
6
ARCHITECTURE LOGICIELLE DE L’APPLICATION EMBARQUÉE DANS LE DISPOSITIF
UTILISATEUR .........................................................................................................................................................53
6.1
OBJECTIFS DU SYSTÈME INFOMOVILLE ................................................................................................54
6.2
ARCHITECTURE SYSTÈME ..........................................................................................................................54
6.2.1
Les Composants du système INFOMOVILLE .....................................................................................54
6.2.1.1
Modules d’interface ...................................................................................................................55
6.2.1.2
Applicatif et File de message .....................................................................................................57
6.2.2
Interface Homme Machine ..................................................................................................................57
6.2.2.1
Fonctions de navigation de l’application ...................................................................................57
6.2.2.2
IHM à destination des personnes ayant une déficience auditive................................................59
6.2.2.3
IHM à destination des personnes ayant une déficience visuelle ................................................60
6.3
7
CONCLUSION .............................................................................................................................................62
LOCALISATION PAR WIFI OU GPS ET GUIDAGE...............................................................................63
7.1
GUIDAGE ...................................................................................................................................................63
7.2
LOCALISATION DE PIÉTONS ÉQUIPÉS DE SMARTPHONES PAR GPS OU PAR CARTOGRAPHIE WIFI ...............63
7.3
QUELQUES RAPPELS GÉNÉRAUX SUR LES PRINCIPES DE LA LOCALISATION ET SUR LA LOCALISATION PAR
CARTOGRAPHIE RADIO .............................................................................................................................................65
7.3.1
Rappel sur la localisation par cartographie Radio WiFi....................................................................66
7.4
EXPÉRIMENTATIONS DE LOCALISATION EFFECTUÉES DANS LE PROJET INFOMOVILLE ..........................68
7.4.1
Logiciel sur smartphone développé pour les tests de localisation ......................................................68
7.4.2
Tests effectués à Lyon en outdoor sur le site de la station « jet d’eau Mendès France) .....................68
7.4.2.1
Description du site « jet d’eau Mendès-France ».......................................................................68
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 4 sur 159
7.4.2.2
Localisation par cartographie WiFi............................................................................................69
7.4.2.2.1 Équipement utilisé.................................................................................................................69
7.4.2.2.2 Couverture radio WiFi du site...............................................................................................70
7.4.2.2.3 Expérimentation ....................................................................................................................71
7.4.2.2.4 Calibration du site .................................................................................................................72
7.4.2.3
Localisation par GPS .................................................................................................................74
7.4.2.4
Résultats des expérimentations ..................................................................................................74
7.4.2.4.1 Résultats pour la localisation par cartographie WiFi ............................................................74
7.4.2.4.2 Résultats des tests de localisation par GPS ...........................................................................80
7.4.3
Tests effectués à l’ESIEE en indoor et en outdoor ..............................................................................83
7.4.3.1
Expérimentation en outdoor à l’ESIEE avec la cartographie WiFi Ekahau...............................83
7.4.3.2
Expérimentation en indoor à l’ESIEE avec la cartographie WiFi Ekahau.................................87
7.4.3.3
Expérimentation en outdoor à l’ESIEE de localisation par GPS ...............................................89
7.4.3.4
Résumé des mesures effectuées à l’ESIEE ................................................................................92
7.4.4
Principaux résultats sur la localisation...............................................................................................92
7.4.4.1
La localisation par GPS : ...........................................................................................................93
7.4.4.2
La localisation par cartographie radio WiFi...............................................................................93
7.4.4.3
La localisation par simple connexion à un point d’accès WiFi : ...............................................93
7.5
8
9
BIBLIOGRAPHIE POUR LA SECTION.............................................................................................................94
ANNEXE B1 : DÉTAIL DES ÉCHANGES AVEC LE SMARTPHONE ..................................................95
8.1
DÉCLENCHEMENT DU CARILLON ...............................................................................................................95
8.2
VÉHICULE À L’APPROCHE..........................................................................................................................96
8.3
DEMANDE DU PLAN DE QUARTIER .............................................................................................................97
8.4
DEMANDE D’IDENTIFIANT D’ARRÊT D’UNE BORNE ....................................................................................99
8.5
DEMANDE DE VÉRIFICATION DU STATUS DU SYSTÈME:............................................................................100
ANNEXE B2 : LES SERVICES SIRI (VERSION 1.0) – PROFIL ILE-DE-FRANCE ..........................102
9.1
CODIFICATION DES IDENTIFIANTS............................................................................................................102
9.2
REQUÊTE D'INFORMATION TEMPS RÉEL AU POINT D'ARRÊT : STOPMONITORINGREQUEST .......................102
9.2.1
Résultat de la requête d'information temps réel au point d'arrêt ......................................................104
9.2.1.1
Attributs temps réel du point d'arrêt.........................................................................................104
9.2.1.2
Description d'un arrêt (ou point d'arrêt indiqué) sur une course ..............................................105
9.2.1.3
Attributs temps réel de la course..............................................................................................106
9.2.1.4
L'arrêt .......................................................................................................................................106
9.2.1.5
Arrêts suivants .........................................................................................................................108
9.2.1.6
FramedVehicleJourneyRef.......................................................................................................110
9.2.1.7
DisruptionGroup (Perturbations) .............................................................................................110
9.2.1.8
JourneyProgressGroup (Localisation du véhicule) ..................................................................110
9.2.1.9
VehicleJourneyInfoGroup........................................................................................................112
9.2.1.10
Structure Location....................................................................................................................112
9.2.1.11
JourneyPatternInfoGroup.........................................................................................................114
9.2.1.12
ServiceInfoGroup.....................................................................................................................114
9.3
REQUÊTE D’INFORMATIONS DE MESSAGERIE ...........................................................................................114
9.3.1.1
Résultat de la requete d’informations de messgarie.................................................................115
9.3.1.2
GeneralMessageDelivery .........................................................................................................115
9.3.1.3
InfoMessage.............................................................................................................................116
9.3.1.4
Content.....................................................................................................................................117
9.4
EN-TÊTES DES RÉPONSES .........................................................................................................................118
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 5 sur 159
9.4.1
9.5
Structure générique des entêtes de réponses .....................................................................................118
CHECKSTATUS ........................................................................................................................................119
9.6
SERVICEDELIVERY ..................................................................................................................................119
9.6.1
Structure des réponses aux services ..................................................................................................120
ANNEXE N1 : PRÉSENTATION À LA PREDIM SUR LES TRAVAUX EFFECTUÉS PAR ESIEE PARIS
DANS LE GROUPE DE NORMALISATION TC278/WG3/SG3 : TRAVELLER INFORMATION FOR
VISUALLY IMPAIRED PEOPLE........................................................................................................................121
10 ANNEXE N2 : SPÉCIFICATION TECHNIQUE EUROPÉENNE CEN/1 TC278/WG3/SG3,
OCTOBRE 2007, PUBLIC TRANSPORT - ROAD VEHICLES, TRAVELLER INFORMATION FOR
VISUALLY IMPAIRED PEOPLE (TI-VIP), VERSION 1.00............................................................................136
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 6 sur 159
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 7 sur 159
Avant-propos
Ce rapport, intitulé « rapport technique final » présente les développements techniques effectués
dans le cadre du projet INFOMOVILLE centré sur le développement de systèmes d’information
temps réel et d’aide à l’orientation plus particulièrement destinés aux personnes ayant un
handicap sensoriel mais dans une logique de conception de systèmes utiles à tous.
La liste des différents rapports du projet INFOMOVILLE est la suivante :
1. M.-F. Dessaigne, SP1 rapport N° 1, Analyse des besoins, sept. 2007.
2. M.-F. Dessaigne, SP1 rapport N° 2, Analyse des besoins des personnes en vue des
spécifications du système futur. septembre 2007.
3. M.-F. Dessaigne, G. Baudoin, O. Venard, M. Garel, SP1 rapport N°3, fiches état de l’art, juin
2008.
4. G. Baudoin, O. Venard, P. Jardin, G. Uzan, J. Dupire, SP1 Rapport N°4 - les technologies
mobilisables.
5. Y. Lemaitre, SP1 Rapport N°5 - Contraintes du marché
6. Y. Lemaitre, SP2 Rapport N°1 – Prospectives d’évolution des SIV
7. S. Meynier, Y. Lemaitre, SP3 - Interactivité multi plateforme : portabilité, réutilisabilité,
adaptation
8. G. Baudoin, O. Venard, Y. Lemaître, Rapport technique final, juil. 2010.
9. M.-F. Dessaigne, Rapport sur l’organisation de l’expérimentation INFOMOVILLE sur site
réel du Sytral / Lyon, mars 2010.
10. M.-F. Dessaigne, Rapport sur l’expérimentation. Partie II : Analyse des données
expérimentation INFOMOVILLE dans les transports urbains Lyonnais, juillet 2010.
Ce document est structuré en 7 sections principales après cet avant-propos et un résumé. Elles
sont complétées par 4 annexes.
La section 1 est une introduction qui précise les enjeux, la problématique, le contexte, les
partenaires et la démarche scientifique adoptée.
La section 2 décrit le système INFOMOVILLE.
La section 3 présente les travaux sur la normalisation de l’information voyageur destinée aux
personnes à déficience visuelle, travaux auxquels nous avons participé au début du projet. Elle
est complétée par les annexes N1 et N2.
Les sections suivantes abordent les différents aspects techniques du projet.
La section 4 est dédiée à l’intégration du protocole SIRI dans INFOMOVILLE.
La section 5 traite de la borne INFOMOVILLE. Elle est complétée par les annexes B1 et B2.
La section 6 présente l’architecture logicielle des applications sur téléphone.
La section 7 est consacrée à la problématique du guidage et de la localisation par GPS ou par
cartographie WiFi.
L’expérimentation et de l’évaluation du système sont présentées dans un rapport séparé.
Remarque générale :
les références bibliographiques sont données chapitre par chapitre.
La liste des publications effectuées pendant le projet est donnée à la fin du document.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 8 sur 159
Résumé du projet
Les transports se caractérisent pour un voyageur à handicap sensoriel par un fort niveau
d’incertitude. Tout voyageur doit gérer une multiplicité d’informations : existence, identification
et localisation des arrêts, lignes, horaires, correspondances, perturbations… La personne aveugle
peut se trouver dans l’ignorance de tout ou partie de ces informations surtout lorsqu’elle se
déplace sur des sites non familiers ou lorsqu’elle est seule. La personne sourde cherche à
multiplier les prises d’informations pour prévenir la survenue d’un danger potentiel ou éviter une
demande de renseignement. Face à ces difficultés, il n’existe pas à l’heure actuelle de systèmes
d’information ni de signalétique appropriés. Or la loi du 11 février 2005 pour l’égalité des droits
et des chances affirme le principe d’accessibilité pour tous, en particulier dans les transports.
Le projet INFOMOVILLE avait pour objectif de développer un environnement temps-réel pour
l’information et l’orientation des voyageurs à handicap sensoriel au cours de leurs déplacements
dans les transports collectifs. Le système utilise un téléphone et un logiciel communiquant avec
des bornes d’informations installées aux points d’arrêt. Ce logiciel doit comporter une interface
homme-machine suffisamment sophistiquée pour permettre d’absorber l’accroissement
d’informations sans augmenter la complexité d’utilisation. Cela constitue un des verrous majeurs
pour ce type de service. Une attention particulière a donc été donc portée à la conception de
l’interface en intégrant dès le début les différents aspects ergonomiques, informatiques et
électroniques ainsi que les potentialités des technologies de communication sans fil et de
localisation.
La technologie WiFi est utilisée à la fois pour la communication entre les dispositifs utilisateurs
et les bornes et pour la localisation. La modélisation des applications pour la mobilité a conduit à
une méthodologie de conception et à une architecture logicielle basée sur une librairie de
composants d’interface homme-machine, de communication et de localisation/guidage. Le
nouveau protocole SIRI (service interface for real time information) dédié aux échanges
d’informations transport est utilisé d’une part entre les bornes et le serveur d’informations
transport multimodal et d’autre part entre les bornes et les téléphones.
L’utilisation de technologies génériques devrait faciliter le déploiement de tels systèmes.
Dans un premier temps, une analyse in-situ des déplacements naturels dans les transports publics
a été réalisée pour 3 populations : sans handicap, à handicap visuel ou auditif. Elle a permis
d’étudier les stratégies de déplacement et de prise d’informations et d’identifier les besoins
spécifiques. Cette analyse et l’évaluation des potentialités des technologies ont abouti aux
spécifications du système à développer.
Les différents prototypes matériels et logiciels (bornes d’information, applications sur téléphones
pour personnes aveugles et personnes sourdes) ont été développés.
Le système a été expérimenté à Lyon en partenariat avec le SYTRAL sur un parcours
multimodal (bus et tramway).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 9 sur 159
1 Introduction
1.1 Enjeux et problématique
Il n’existe pas aujourd’hui sur les lieux de transports publics (réseaux, pôles d’échange) de
système d’information et d’orientation suffisamment performants à destination des personnes à
déficience sensorielle (PDS) visuelle ou auditive. Les transports se caractérisent pour les
personnes à déficience sensorielle PDS par un fort niveau d’incertitude. Les informations
nécessaires aux déplacements sont très nombreuses. Celles strictement liées aux transports n'en
sont qu'une partie, mais dont l'importance est accrue dans certaines phases (localisation, choix
d'itinéraires, attente en arrêt, perturbations). Repérer la présence et l’emplacement d’un point
d’arrêt, connaître les lignes desservies, leurs parcours et horaires, s’informer sur les
perturbations, apercevoir au loin le numéro du véhicule à l’approche dans le cas du bus, voilà
quelques-unes des tâches qu’accomplit souvent machinalement un voyageur. Cette liste de
tâches se trouve démultipliée dans le cas de correspondances multi-modales.Différents Systèmes
d’Information Voyageurs fournissent certaines de ces informations aux usagers, souvent sous
forme visuelle. Elles restent cependant difficilement accessibles aux personnes à déficience
sensorielle PDS et la continuité de l’information n’est pas assurée le long de la chaîne de
déplacements. La personne aveugle ou malvoyante peut se trouver dans l’incertitude ou dans
l’ignorance de tout ou partie de ces informations surtout lorsqu’elle se déplace sur des sites non
familiers ou lorsqu’elle est seule. La personne sourde ou malentendante multiplie les prises
d’informations pour prévenir la survenue d’un danger potentiel ou encore éviter une demande de
renseignement.
Le développement des technologies de l’information et de la communication, des systèmes de
communications mobiles et de localisation, et la miniaturisation des systèmes électroniques pour
des applications à très grande diffusion, rendent aujourd’hui envisageable, techniquement et
économiquement, la réalisation de systèmes et services d’aide à l’autonomie et à la mobilité
urbaine des personnes présentant une déficience sensorielle.
La loi du 11 février 2005 « pour l'égalité des droits et des chances, la participation et la
citoyenneté des personnes handicapées » affirme le principe d'accessibilité pour tous, en
particulier dans les transports. Les travaux du groupe de travail GT7.3 de la normalisation SIRI
(Service Interface for Real Time Information) ont par ailleurs commencé à s’intéresser aux
questions d’accessibilité et aux extensions dédiées aux personnes à mobilité réduite. Dans le
cadre du projet nous avons participé à ces travaux de normalisation avec le soutien de la
PREDIM au niveau français et européen (respectivement BNEVT CN03-GT7 et
TC278/WG3/SG3) sur le thème « Contents of Traveller information for Visual Impaired
People » ; les annes N1 et N2 présentent ces travaux et notre contribution. Enfin les travaux de
normalisation européenne pour la formalisation et la communication (IFOPT, TRANSMODEL,
SIRI) des informations transports facilitent la création de serveurs d’information multimodaux et
la mise à disposition des informations par des interfaces normalisées.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 10 sur 159
Dans ce contexte, le projet INFOMOVILLE avait pour objectif de concevoir, développer et
expérimenter un environnement temps-réel pour l’information et l’orientation des voyageurs à
handicap sensoriel (visuel ou auditif) dans les transports collectifs et les pôles d’échanges.
Il fait suite au projet RAMPE [2, 3, 4, 12, 14, 15] au cours duquel l’équipe a conçu et réalisé un
système interactif d’assistance et d’information auditive destiné aux personnes aveugles et
équipant les points d’arrêt des réseaux de bus. Le projet RAMPE était focalisé sur l’approche
d’un point d’arrêt et sur l’information utile avant l’entrée dans un véhicule. INFOMOVILLE
élargit le champ de RAMPE selon différents points de vue : utilisateurs potentiels (déficience
sensorielle visuelle ou auditive), extension à différents types de transports de surface, ajout
d’informations géographiques en supplément des informations liées aux transports, intégration
de directives de guidage et de potentialité de localisation [13], utilisation du protocole SIRI pour
les échanges d’informations.
Les enjeux scientifiques et techniques du projet concernent :
• L’ergonomie des interfaces homme-machine (IHM) multimodales : l’enjeu est de développer
une interface (auditive, vocale, visuelle, tactile) sophistiquée permettant d’absorber
l’accroissement d’informations sans augmenter la complexité d’utilisation.
• La robustesse de l’application logicielle embarquée dans le dispositif utilisateur de façon à
garantir son utilisabilité dans un environnement perturbé et potentiellement dangereux. Elle
doit prendre en compte les aléas de l’environnement (variation de la qualité de liaison radio,
niveau de bruit environnant, distance à une borne, déplacement du piéton) et les traiter de
façon à ne pas désorienter l’utilisateur.
• La prise en compte dans l’application de l’hétérogénéité des configurations d’infrastructures
et de systèmes d’information voyageurs.
• La gestion de l’information (Synthèse élaboration production) en lien avec les travaux de
normalisation en cours pour l’information transport.
• La portabilité des développements logiciels sur différentes plateformes (PDAs, téléphones
portables, …) et plus généralement l’abstraction des couches matérielles, : découplage des
fonctions logicielles des caractéristiques matérielles du dispositif utilisateur (type de clavier,
d’écran, de réseau sans fil).
• La localisation robuste des utilisateurs et des bornes dans un environnement urbain.
Au niveau international, d’autres projets de système d’assistance à la mobilité des PAM dans les
transports collectifs sont en cours, par exemple [1,5,6,7,8,9,11,16]. Les projets consacrés aux
PSM sont moins nombreux [10]. Pour une étude détaillée, on pourra se rapporter au rapport
d’état de l’art effectué au démarrage du projet [17].
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 11 sur 159
1.2 Contexte partenariat et démarche adoptée
Le projet INFOMOVILLE a été labellisé par l’Agence Nationale de la Recherche dans le cadre
du programme PREDIT sur les transports intelligents. Il a démarré en mai 2007 pour une durée
de trois ans. Il regroupe 4 partenaires : un partenaire académique ESIEE Paris qui coordonne le
projet et apporte son expertise dans le domaine des sciences et technologies de l’information, la
société LUMIPLAN spécialiste des systèmes d’information voyageurs, le cabinet
ERGONOMOS et l’institut d’ergonomie et d’écologie INEREC. La complémentarité du
partenariat permet de considérer dès le début de la conception du système, les différents champs
scientifiques et contraintes : ergonomie, informatique, électronique, intégration de différentes
fonctionnalités. Le projet a été labellisé et est soutenu par le pôle de compétitivité « Advancity ».
La démarche adoptée dans le projet peut se décliner en 5 points :
• Analyse de la chaîne de déplacement de bout en bout : modélisation de la chaîne de
déplacements en zones spatiales et de la diffusion de l’information en niveaux de temporalité.
• Analyse in-situ des déplacements naturels dans les transports publics à partir de laquelle ont
été déduites les spécifications pour la conception du système.
• Analyse des technologies logicielle et matérielle mobilisables
• Développement des prototypes en s’appuyant sur des technologies génériques avec une
attention particulière à l’IHM
• Expérimentation et évaluation in-situ.
Au démarrage du projet, une analyse in-situ des déplacements naturels dans les transports
collectifs (bus, tramway, métro) a été réalisée à Lyon pour 3 populations : sans handicap, à
handicap visuel et à handicap auditif. Elle a permis d’analyser les stratégies de déplacement et de
prise d’informations ainsi que d’identifier les difficultés et les besoins de chaque population.
Cette analyse et l’évaluation des potentialités des technologies ont abouti aux spécifications des
solutions à développer dans INFOMOVILLE. La méthodologie et les résultats de cette analyse
sont décrits dans le rapport [18] et dans [19].
1.3 Bibliographie de la section
[1] M. Banatre, P. Couderc, J. Pauty, M. Becus. “Ubibus: Ubiquitous computing to help blind people in public
transport”. Proc. of the International Symposium on Mobile Human-Computer Interaction, MobileHCI 2004,
vol. 3160, p. 310-314. Glasgow, Scotland. Sept. 2004.
[2] G. Baudoin, O. Venard, G. Uzan, A. Paumier, J. Cesbron, "Le projet RAMPE : Système interactif d'information
auditive pour la mobilité des personnes aveugles dans les transports publics", UBIMOB'05-Mobilité et
Ubiquité, pp. 169-176, Grenoble, France. Juin 2005.
[3] G.Baudoin, O.Venard, G.Uzan, A.Rousseau, Y.Benabou, A.Paumier, J.Cesbron, “ The RAMPE Project:
Interactive, Auditive Information System for the Mobility of Blind People in Public Transports”, Proc. The 5th
international conference on ITS telecommunications, Juin 2005, Brest.
[4] G.Baudoin, O.Venard, G.Uzan, A.Rousseau, Y.Benabou, A.Paumier, J.Cesbron, “How can blinds get
information in Public Transports using PDA? The RAMPE Auditive Man Machine Interface”, Proc. 8th
European conference for the advancement of assistive technology in Europe,AAATE 2005, Sept. 2005, Lille.
[5] U. B. Ceipidor, C. M. Medaglia. “Sesamonet: Mobile Navigation Services for Visually Impaired. Smart
Mobility- Building Trusted Mobile Applications”. Sophia- Antipolis, French Riviera. September 2008.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 12 sur 159
[6] R. Ivanov. “Mobile GPS navigation application, adapted to visually impaired people”. Proc. of the Int.
Association for the Scientific Knowledge conference (IASK 2009), ICT and People with Disabilities. Spain.
June 2009.
[7] C Jacquet, Y. Bellik, R. Farcy, Yolaine Bourda. “Aides électroniques pour le déplacement des personnes nonvoyantes: vue d'ensemble et perspectives”. 16ème Conf. Francophone sur l’Interaction Homme-Machine, IHM
2004. Belgium. Août 2004.
[8] J. M. Loomis, J.R. Marston, Reginald G. Golledge, Roberta L. Klatzky. “Personal Guidance System for People
with Visual Impairment: A Comparison of Spatial Displays for Route Guidance”. Journal of Visual Impairment
and Blindness, April 2005.
[9] H. Ohkubo, M. Furukawa, K. Ito, S. Sasaki. “Remote Infrared Audible Signage System for Visually Impaired
at Railway Station”. 10th International Conference on Mobility and Transport for Elderly and Disabled
Persons, TRANSED 2004. Japon. May 2004.
[10] F. Rambaud, M. Dejeammes. “Pour des systèmes de transports collectifs et d’information accessibles à tous”.
11th International Conference on Mobility and Transport for Elderly and Disabled Persons, TRANSED 2007.
Canada, 2007.
[11] J H Sánchez and C A Oyarzún. “Mobile audio assistance in bus transportation for the blind”. 7th International
Conference on Disability, Virtual Reality and Associated Technologies, ICDVRAT 2008., Portugal. September
2008.
[12] J. Sayah, G. Baudoin, O. Venard, B. El-Hassan, « RAMPE/INFOMOVILLE Application Protocol- Protocole
Point à Multipoint adapté au système RAMPE/INFOMOVILLE- Assistance aux Personnes à Handicap
Sensoriel pour leur Mobilité dans les Transports Publics et en Ville », la conférence SETIT 2009.
[13] J. Sayah, G. Baudoin, O. Venard, B. El Hassan Localization and Guidance in RAMPE/INFOMOVILLE- an
Interactive System of Assistance for Blind Travelers, Proc. of ICADIWT'09, 2nd int. Conference on the
application of digital information and web technologies, Aug. 2009, Londres, Grande Bretagne.
[14] O. Venard, G. Baudoin, G. Uzan, "Experiment and Evaluation of the RAMPE Interactive Auditive Information
System for the Mobility of Blind People in Public Transport", ASSETS 2008, 10th ACM Conference on
Computers and Accessibility, du 13 au 15 Octobre 2008, Halifax, Nova Scotia, Canada.
[15] O. Venard, G. Baudoin, G. Uzan, “Field Experimentation of the RAMPE Interactive Auditive Information
System for the Mobility of Blind People in Public Transport : Final Evaluation”, Proceedings of ITST 2009,
The 9th int. conference on ITS telecommunications, Oct. 2009, Lille France.
[16] G. Whitney. “The Use of Remotely Triggered Talking Sign Systems by Blind and Partially Sighted People”.
Joint Mobility Unit- Royal National Institute for the Blind. London, W1N 6AA. August 1998.
[17] M.-F. Dessaigne, G. Baudoin, O. Venard, M. Garel, Projet INFOMOVILLE, SP1 rapport N°3, fiches état de
l’art, juin 2008.
[18] M.-F. Dessaigne, Projet INFOMOVILLE, SP1 rapport N° I, Analyse des besoins, septembre 2007.
[19] M-F. Dessaigne, G. Baudoin, G. Uzan, O. Venard, « Accéder à l’information Voyageurs quand on a un
handicap sensoriel visuel ou auditif. Et l’ergonomie et le Design dans ce système innovant ? », forum européen
ERGODESIGN, 8-10 juin 2009, Lyon France.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 13 sur 159
2 Description générale du système INFOMOVILLE
Nous commençons par une description générale du système et de ses constituants, puis les
différents constituants sont détaillés séparément.
2.1 Fonctionnalités, architecture et communication entre éléments
Le système INFOMOVILLE [1, 2, 3] permet aux utilisateurs au cours de leurs déplacements de
disposer d’informations spécifiques aux transports et d’informations locales destinées à
l’orientation spatiale dans l’environnement proche. Pour distinguer ces deux catégories, on
parlera de mode transport et de mode guidage.
Le système est capable de gérer les situations complexes telles que les arrêts multi-lignes, les
sites multi-points d'arrêt, ou les correspondances. Il contribue à maintenir la continuité de la
chaine d'information le long de la chaîne de déplacements.
Le système offre quatre fonctionnalités principales qui s’enchaînent de façon naturelle au cours
du temps et au long des différents types et étapes de parcours :
• découverte, localisation et approche d’un point d’arrêt,
• attente au point d’arrêt et consultation d’informations transport, choix d’une ligne,
modification éventuelle d’itinéraire en cas de perturbation.
• cheminent piéton pour une correspondance entre points d’arrêt,
• alerte en cas de messages urgents ou de perturbations.
L’information transport comprend les horaires ou temps d’attente, les lignes desservant un arrêt,
les arrêts sur une ligne, des messages de service ou de perturbation.
L’information locale spatiale comprend les cartes de quartier autour d’un point d’arrêt, la
situation des arrêts de transport dans ce quartier (coordonnées GPS des points d’arrêt). et des
instructions de guidage pour se déplacer pour se déplacer d’un point d’arrêt à un autre au cours
d’une correspondance. Ces instructions de guidage sont essentiellement destinées aux personnes
aveugles ou malvoyantes mais peuvent être utiles à tous.
Le système INFOMOVILLE est constitué de deux parties qui lui sont propres: des équipements
fixes installés aux points d’arrêts (bornes INFOMOVILLE) ou dans les pôles d’échanges et le
dispositif mobile porté par l’utilisateur (un smartphone doté d’une application INFOMOVILLE).
Il s’interface au réseau de transports de surface d’une collectivité dans lequel on peut distinguer
un ensemble de points d’arrêt, les véhicules (bus, tramways), des systèmes d’aide à
l’exploitation et à l’information voyageurs (SAEIV), ainsi qu’un serveur d’information voyageur
multimodal reliés aux SAIEV.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 14 sur 159
Ce serveur d’information voyageur, propose les informations transport au format SIRI : données
théoriques, messagerie, suivi temps réel des heures de passages. du réseau ou des réseaux de
transports, Il regroupe les informations des différents modes de transport. Nous nous sommes
plus particulièrement intéressés aux transports de surface (bus et tramways) compte tenu de leur
complexité d’utilisation pour une personne à handicap sensoriel, mais les principes pourraient
être étendus au métro.
Dans le cas du réseau de bus, les véhicules, équipés d’un système GPS, remontent les
informations de position au serveur SAEIV (système d’aide à l’exploitation et à l’information
voyageurs). Une infrastructure radio spécifique leur permet également d’informer les bornes
d’information voyageur de son arrivée imminente. Cette dernière infrastructure radio n’est pas
disponible dans toutes les villes mais comme elle existe à Lyon, ville dans laquelle nous avons
effectué les expérimentations, nous avons fait en sorte que le système INFOMOVILLE puisse
l’exploiter quand elle est disponible.
Il existe trois types de communications (deux obligatoires et une optionnelle) entre les éléments
du système qui sont directement exploitées par INFOMOVILLE :
• Une communication entre les dispositifs utilisateur et les bornes par une liaison Wifi.
• Une communication entre les bornes et le serveur d’information voyageur par une liaison de
données (ici liaison 3G).
• Une communication directe optionnelle entre les véhicules et les bornes par une liaison radio
spécifiques
Les bornes sont des points d’accès à l’information. L’information locale spatiale est stockée
directement dans les bornes. L’information transport est disponible dans un serveur
d’information multimodal qui est accédé à distance par les bornes à l’aide du nouveau protocole
SIRI [4]. Ce dernier est aussi utilisé pour les échanges d’informations entre les bornes et les
dispositifs utilisateurs.
Les bornes sont équipées de haut-parleurs et d’une lampe flash qui peuvent être activés à
distance par l’utilisateur pour l’aider à s’orienter quand ils s’en rapprochent. Enfin, les
équipements WiFi intégrés dans les bornes peuvent être exploités dans les techniques de
localisation par empreinte (ou cartographie) radio WiFi [5, 6].
La figure 1 illustre l’architecture générale du système et la figure figure 2 résume les
communications entre les différents éléments.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 15 sur 159
figure 1 : Architecture générale du système INFOMOVILLE
figure 2 : Communications entre les éléments du système INFOMOVILLE
2.1.1 La borne INFOMOVILLE
La borne INFOMOVILLE dérive d’une borne d’information voyageur (BIV) classique. Une BIV
classique affiche les prochaines heures de passages des véhicules à un arrêt, ainsi que différents
messages relatifs à la communication à destination des usagers. De façon à pouvoir mettre en
place une expérimentation in-situ dans une collectivité sans avoir à modifier l’infrastructure en
place, nous avons choisi de développer un matériel dédié qui vient se ‘greffer’ sur la BIV, sans
affichage supplémentaire.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 16 sur 159
La borne INFOMOVILLE dispose de fonctionnalités additionnelles par rapport à une BIV
classique :
• Accès internet par une connexion 3G.
• Point d’accès WIFI. La BIV met à disposition un réseau WIFI en y proposant une passerelle
vers sa connexion internet 3G.
• Client SIRI. La BIV interroge sur demande les services web SIRI du serveur d’information
voyageur. Dans notre expérimentation, nous avons utilisé le nouveau serveur e-dylic.du
SYTRAL. Pour permettre cet échange, la récupération des informations théoriques est
réalisée auprès du serveur SYTRAL Titan.
• Serveur SIRI. La BIV met à disposition des mobiles les informations temps réels obtenues, au
même format SIRI, sur service web (SOAP).
• Indication de véhicule à l’approche. Sur réception du signal radio en provenance du véhicule
à l’approche, la BIV crée dynamiquement un message dans un format binaire propriétaire
qu’elle diffuse en mode broadcast (UDP) sur le réseau wifi qu’elle gère.
• Signal de localisation. Sur requête SIRI (General Message) d’un mobile connecté au réseau
WIFI, la borne émet un signal sonore complété par un voyant lumineux.
• Annonce sonore. En complément au système INFOMOVILLE, la borne peut être activée par
une télécommande (celle utilisée pour les eux sonores) pour diffuser sous forme sonore les
informations des prochains passages.
2.1.2 Dispositif utilisateur et applications logicielles associées
Le dispositif utilisateur est un smartphone( portable avec une puissance de calcul suffisante et
des périphériques adaptés comme précisé plus loin) doté d’une application logicielle adaptée au
handicap de la personne. Deux applications ont été développées, adaptée respectivement à un
handicap visuel et à un handicap auditif. Ces applications intègrent les modes transport et
guidage entre deux points d’arrêt ainsi que les fonctionnalités d’alerte et de détection des arrêts. :
Le choix d’un téléphone portable comme plateforme générale de services permet d’une part de
limiter le nombre de dispositifs portés par l’utilisateur et d’autre part de bénéficier de la
diminution des coûts lié à la grande diffusion ce qui ne serait pas le cas pour un matériel
spécifique dont la production en petite série conduit à des coûts souvent élevés.
Ces téléphones doivent disposer d’un circuit de communication sans fil WiFi et de façon
optionnelle d’un récepteur GPS. Pour le projet nous avons choisi de travailler avec des
téléphones fonctionnant sous Windows Mobile de façon à pouvoir réutiliser certains
développements logiciels du projet RAMPE.
Deux interfaces homme-machine sont disponibles [7] :
• L’interface destinée aux personnes à déficience visuelle (on notera IHM_aveugle) s’appuie
sur une synthèse vocale et une interface de commande utilisant les touches du téléphone qui
sont reprogrammées dynamiquement pour une utilisation intuitive.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 17 sur 159
• L’interface destinée aux personnes à déficience auditive (notée IHM_sourd) est
principalement visuelle. Elle utilise l’écran pour l’affichage de texte statique ou animé,
d’images ou de cartes. Le vibreur joue un rôle d’alerte. L’interface de commande exploite les
touches et l’écran du dispositif.
L’IHM_aveugle est une IHM auditive et donc par nature séquentielle. Elle utilise différents
signaux auditifs d’alerte et de feedback et un mode vocal dont un des éléments essentiels est la
navigation par « barillet vocal ». Nous appelons ainsi des listes vocales dont les items sont
répétés en boucles et dans lesquelles l’utilisateur peut sélectionner un item à la volée par appui
sur une touche. Les éléments de début et de fin de boucle étant appuyés par des signaux auditifs
distinctifs. Un silence de 300 ms inclus entre items successifs permet une séparation auditive
naturelle entre éléments et prolonge la durée de décision de choix de l'élément courant.
Les différentes listes vocales sont les suivantes :
• En mode détection d’arrêts : liste des arrêts détectés (noms et directions)
• En mode transport : liste des lignes desservant un arrêt (numéro de ligne, temps d’attente,
direction), Liste des arrêts sur une ligne : à partir du point courant
• En mode guidage : liste des points de départ possibles (noms et directions), liste des
instructions de guidage.
Les messages d’événement tels que les messages d’alerte (annonce de l’arrivée d’un véhicule par
exemple) sont répétés en boucle jusqu’à ce que l’utilisateur les acquitte en appuyant sur une
touche quelconque du téléphone. Il est possible de mettre l’application en mode de veille
silencieuse, l’application restant active aux occurrences de messages d’événements.
L’IHM_sourd est une interface graphique classique (GUI) par nature parallèle utilisant les
composants graphiques (on parle de widget ou window gadget) classiques d’interface (fenêtres
de dialogue, boutons poussoir, boîtes combinées pour afficher des listes dans lesquelles
l’utilisateur peut choisir un item) permettant à l’utilisateur d’interagir avec l’application. Ces
différentes actions effectuées à l’aide de l’écran tactile et d’un stylet génèrent des événements
pour le programme. L’application Infomoville utilise une interface multi-documents, c’est-à-dire
une fenêtre à onglets multiples, l’utilisateur sélectionnant une page en cliquant sur l’onglet avec
le titre de son choix. La figure 3 montrent les principales pages de l’application.
Les messages d’événement très important par exemple pour alerter et informer sur une
information sont générés par une vibration du téléphone et par l’apparition d’une fenêtre de
message textuel sur l’écran. Cette fenêtre reste ouverte jusqu’à ce que l’utilisateur la ferme
volontairement. Le contenu du message étant sauvegardé et accessible pendant une durée
paramétrable.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 18 sur 159
figure 3: Quelques écrans de l'interface pour les personnes à déficience auditive
La modélisation des applications pour la mobilité a conduit à une méthodologie de conception et
une architecture logicielle basée sur une librairie de composants d’interface homme-machine, de
communication et de localisation/guidage.
[1] G. Baudoin, O. Venard, S. Pretorius, “Real Time Information, Communication and Localization Enviromnment
for Improving the Mobility of Travelers with Sensory Disabilities (Visual or Auditory) in Public Transports –
The INFOMOVILLE Project”, TRANSED 2010, 12th international conference on mobility and transport for
elderly and disabled persons, 2-4 juin 2010, Hong-Kong.
[2] S. Pretorius, G. Baudoin, O.Venard, “Real Time Information for Visual and Auditory Impaired Passengers
Utilizing Public Transport – Technical aspects of the INFOMOVILLE project”, Congrès Handicap 2010, 9-11
juin 2010, Paris.
[3] G. Baudoin, O. Venard, “Information, Communication and Localization environment for Travelers with
Sensory Disabilities in Public Transports”, conférence invitée à CHINACOM 2010 , 5th International ICST
Conference on Communications and Networking in China, 25-27 août 2010, Pékin, Chine.
[4] G. Baudoin, O. Venard, M.-F. Dessaigne, G. Uzan et Y. Le Maître, "INFOMOVILLE : environnement temps
réel pour l’information et l’orientation des voyageurs à handicap sensoriel dans les transports collectifs",
Revue Génie Logiciel, GL-IS, N°91, , ISSN :0295-6322, Agence de l’informatique pp. 35-40, décembre 2009.
[5] J. El Sayah, G. Baudoin, O. Venard, B. El Hassan, "Localization and guidance in RAMPE/INFOMOVILLE-an
interactive system of assistance for blind travelers", ICADIWT 2009. 2nd International Conference on the
Applications of Digital Information and Web Technologies. pp. 243-249, London, United Kingdom. du 4 au 6
Août 2009.
[6] J. Sayah, mémoire de thèse de doctorat : contribution à la modélisation et à l’évaluation d’applications nomades
à intelligence répartie – Application à l’assistance aux voyageurs aveugles dans les transports publics et les
pôles d’échanges. Thèse soutenue le 18 décembre 2009, université Paris Est.
[7] M.-F. Dessaigne, Projet INFOMOVILLE. Rapport sur l’organisation de l’expérimentation INFOMOVILLE sur
site réel du Sytral / Lyon, mars 2010.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 19 sur 159
3 Travaux sur la normalisation de l’information
voyageur effectués au début du projet
3.1 Contexte
La génération, la maintenance et la diffusion de l’information dans le domaine des transports est
un champ qui couvre aussi bien les besoins pour l’exploitation que pour l’information voyageur.
Les différents agents et objets d’information intervenant dans un système d’information transport
ont été étudié et normalisé dans la norme européenne ENV12896 TRANSMODEL qui spécifie
le modèle de donnée de référence pour les transports publics.
Un système d’information transport est un système hétérogène qui comprend :
• Un composant « back-office » correspondant au système central gérant la maintenance d’une
base de donnée globale ou répartie, les interfaces de requêtes à cette base de données selon un
format propriétaire ou normalisé, les passerelles permettant d’effectuer la translation entre
une interface normalisée et un accès à un format propriétaire.
• Des composants « front-office » qui englobe aussi bien le système d’information interne à
chaque véhicule dont la finalité peut concerner tant l’exploitation que l’information voyageur,
les systèmes d’information des points d’arrêt (gare, arrêt, …) et les interfaces de diffusion
d’information voyageur (visuelle, auditive, télématique, …)
Figure 4: Intégration des différents composants d’un système d’information transport
L’intégration de l’ensemble des ces composants et de leurs interfaces fontionnelles sont englobés
dans les travaux de normalisation au niveau européen par le TC278 (Road Transport and Traffic
Telematics) WG3 (Public Transport), cette intégration est représentée par la Figure 4 issue des
documents du TC278/WG3.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 20 sur 159
3.2 Interface Homme Machine dans les transports publics
Comme illustrée sur ce synoptique (Figure 4), la spécification des interfaces homme-machine est
elle prise en charge au sein du SG3 du TC278/WG3.
Le projet INFOMOVILLE parce qu’il a vocation à diffuser l’information voyageur à destination
de personnes ayant un handicap sensoriel (visuel ou auditif) se situe clairement pour une partie
de ses travaux dans le champ de compétence du SG3.
Les développements et les résultats du projet PREDIT RAMPE (2004-2007) [1],[2] et leurs
présentations lors du meeting TC278/WG3 en juin 2006 à Paris ont débouché sur l’ouverture
d’un travail de normalisation intitulé «Traveller information for Visually impaired people » dans
le cadre du SG3, ce travail a permit la rédaction et la présentation du champ d’application de ce
projet de norme (scope) lors de la réunion du TC278/WG3 en novembre 2007 [4].
Ce travail de normalisation a bénéficié de la participation active et de la contribution des
partenaires suivants :
• [CZ] : S. Bartak, (consultant APEX), I.Hrouda, (APEX)
• [UK] : N. Knowles, (Kizoom), R.Slevin (MT)
• [FR] : O. Venard (ESIEE), K.Bourée (coordination avec les travaux TRANSMODEL SG4,
IFOPT SG6, SIRI SG7)
• [CH] : W.Meier-Leu, (Weisskopf Engineering AG)
• [SE] : H.Davoody, (MT/ITS division)
• [DE] : R.Zuncker (Siemens)
Il s’est appuyé sur l’expertise apportée par différents projets, conduits à travers l’europe, de
système d’information et d’aide à la mobilité à destination des personnes ayant une déficience
visuelle :
• [CZ] : Tyfloset [7]
• [CH] : PAVIP (Personal Assistant for Visually Impaired People) [8]
• [SE] : FRAM (Flexible Real-time Assistance for Moving) [9]
• [FR] : RAMPE et INFOMOVILLE [10]
3.3 Approche méthodologique
Le travail réalisé dans le cadre de la réalisation du « draft » de document normatif «Traveller
information for visually impaired people (TI-VIP) » s’est inscrit dans une double contrainte :
• D’une part, comme le souligne la Figure 4, un composant de diffusion d’information
voyageur se trouve intégré au sein d’un système d’information complexe composé de
multiples segments opérés par différents acteurs aux finalités tout aussi multiples
(exploitation, information voyageur, …). Les différents composants mettent eux-mêmes en
œuvre des segments technologiques relavant de différents champs techniques (base de
données, protocoles de transmissions, protocoles sessions, …) qui peuvent relever de
différentes instances de normalisation (CEN, ETSI au niveau européen).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 21 sur 159
• D’autre part, être capable d’intégrer différentes classes d’équipement tant côté dispositf
utilisateur que côté infrastructure de diffusion de l’information.
Cette double contrainte a conduit à une approche de structuration en couche protocole de cette
spécification, comme illustré Figure 5.
Figure 5 : Couches protocoles pour la spécification d’information voyageur
Ainsi qu’à définir des niveaux de services qui dépendent à la fois des fonctionnalités du
dispositif utilisateur et de celles de l’infrastructure de diffusion d’information (Figure 6)
Figure 6 : Classes de service
L’approche de spécification selon trois couches illustrée Figure 5 permet de décorréler la nature
des informations, la procédure pour les obtenir et les moyens pour les diffuser. Ces trois couches
correspondent aux fonctionnalités suivantes :
• Nature des informations avec (si cela est pertinent) des contraintes temporelles associées,
cette partie de la spécification est basée sur scénario utilisateur.
• Couche message qui définit la sémantique devant être utilisée pour permettre une interopérabilité et la conformité à des normes existantes : TRANSMODEL, SIRI, TPEG, …
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 22 sur 159
• Hardware ou media physique qui définit la couche de convergence de la couche message avec
les différentes couches physiques pouvant équiper les dispositifs utilisateur permettant de
transmettre ou de diffuser les messages.
Les flèches en pointillé, Figure 5, sont là pour indiquer la prise en compte du fait que certaines
technologies de couche physique peuvent créer des contraintes ou des limites sur les
informations ou les contraintes temporelles attachées.
Ce travail a débouché sur la rédaction du draft de spécification [4].
3.4 Le projet INFOMOVILLE
Les travaux menés dans le cadre du projet INFOMOVILLE ont à la fois profité et contribué aux
travaux de normalisation mené au sein du TC278/WG3/SG3 d’une part en soulignant la
pertinence d’une approche basée sur des scénarios utilisateur notamment par la classification des
informations en terme de temporalité, de zone géographique au cours du déplacement et de
contexte [3], et en prenant en compte l’architecture d’un système d’information destiné à la fois
à l’aide à l’exploitation et à l’information voyageur. Cette prise en compte s’est traduite par
l’intégration du protocole SIRI [4] comme support de messagerie pour la diffusion. Le choix de
cette approche dans le projet INFOMOVILLE a permit de déboucher sur la conception d’un
sous-système d’information destiné aux personnes ayant un handicap sensoriel (visuel ou auditif)
capable de s’intégrer dans le schéma global définit par le TC278/WG3 (Figure 4) et d’exploiter
pour les voyageurs, les informations disponibles au niveau du sytème central d’aide à
l’exploitation.
3.5 Bilan du travail de normalisation au sein du TC278/WG3/SG3
Les résultats du travail réalisé au sein du TC278/WG3/SG3 ont été présenté lors d’une réunion
de la PREDIM le 15 février 2008 [6]. Les principales conclusions, sont qu’en terme normatif la
convergence vers une approche ouverte permettant l’inter-opérabilité est un problème délicat, du
point de vue technique, du fait de l’existant et des enjeux de diverses natures liés au déploiement
de ce type de solution et des structures de décision et de déploiement propre au monde des
transports. L’enjeu de ce travail doit être de construire une spécification qui deviennent un réel
support pour les développements futurs tout en étant capable d’intégrer les développements et
solutions existantes.
[1] G. Baudoin, O. Venard, G. Uzan, A. Rousseau, Y. Benabou, A. Paumier, and J. Cesbron. The rampe project:
Interactive,auditive information system for the mobility of blind people in public transports. In ITST’2005 IEEE, The 5th International Conference on ITS Telecommunications, pages 389–392, Brest, France., du 27 au
29 Juillet 2005.
[2] O. Venard, G. Baudoin, and G. Uzan. Experiment and evaluation of the rampe interactive auditive information
system for the mobility of blind people in public transport. In ASSETS 2008, Proceedings of the 10th ACM
Conference on Computers and Accessibility, pages 271–272, Halifax, Nova Scotia, Canada, du 13 au 15
Octobre 2008.
[3] G. Baudoin, O. Venard, MF. Dessaigne, G. Uzan, and Y. Le Maître. Infomoville : environnement temps-réel
pour l’information et l’orientation des voyageurs à handicap sensoriel dans les transports collectifs. Génie
Logiciel, (91) :35–40, Décembre 2009. Editeur : Agence de l’Informatique
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 23 sur 159
[4] CEN/TS 278181 (1 à 3) SIRI Specification Service interface for real-time information relating to public
transport operations.
[5] CEN/TC278/WG3/SG3. Public Transport - Road Vehicles Traveller information for visually impaired people
(TI-VIP). Version 1.00 (en annexe au présent rapport)
[6] O.Venard. Présentation au PREDIM, « Traveller information for Visually impaired people,
TC278/WG3/SG3 ». 15 fév. 2008 (en annexe au présent rapport)
[7] http://www.apex-jesenice.cz/tyfloset.php?lang=en
[8] http://www.bones.ch/bones/pages/eng/pavip/pavip.html
[9] http://www.transport-research.info/web/projects/project_details.cfm?id=37540
[10] http://www.esiee.fr/~infomove/index.html
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 24 sur 159
4 Intégration du protocole SIRI
SIRI (Service Interface for Real-time Information) est une norme européenne [1],[2] dont
l’objectif est d’offrir des mécanismes de dialogue temps-réel pour l’échange d’information
voyageur. Le protocole implémenté dans l’application de génération précédente (RAMPE)
nécessitait la transmission d’information voyageur temps-réel. Il reposait sur un protocole «
propriétaire » [5]. Le déploiement d’une interface normalisée constitue un enjeu important pour
un projet tel qu’ INFOMOVILLE car il permet d’une part d’ouvrir l’accès au service offert par
la borne d’arrêt du système INFOMOVILLE à d’autre dispositifs utilisateurs et d’autre part il
permet au dispositif utilisateur du système INFOMOVILLE de pouvoir se connecter à d’autre
point d’information que la borne d’arrêt du système INFOMOVILLE.
Le protocole SIRI est aujourd’hui principalement vu comme un outil protocolaire permettant un
dialogue « interne » au système d’information voyageur. Les outils qu’il propose permettent
aussi d’en faire un protocole d’accès aux informations voyageurs pour des équipements
utilisateurs. Les développements menés au sein du projet INFOMOVILLE se proposent donc de
mettre en œuvre les services offerts par ce protocole dans le cadre d’une application utilisateur
d’information voyageur temps-réel.
4.1 Structure et services SIRI
Le protocole SIRI a été élaboré dans le cadre des travaux de normalisation du TC278/WG3/SG7.
Il est basé sur le modèle de données de l’information pour les transports publics
TRANSMODEL (ENV12896) qui fixe un cadre pour l'élaboration de schémas de bases de
données, de spécifications d'échanges de données (messages, interfaces entre applications…),
indépendant de l’implémentation.
SIRI utilise le protocole SOAP pour l’échange de données et utilise donc un canal HTTP pour la
transmission des données, la syntaxe des requêtes et réponses SIRI utilise une syntaxe XML, la
nature des informations disponibles offertes par le protocole SIRI est donc définie dans des
schémas XML.
Le protocole SIRI [2] prévoit deux mécanismes de dialogue basés sur l’échange service WEB :
un mode requête-réponse dans lequel le client exécute une requête puis reçoit une réponse du
serveur et un mode abonnement dans lequel le client a souscrit un abonnement pour un type
d’information et peut les recevoir suivant deux approches sans avoir à effectuer de requête. Les
approches du mode abonnement sont le mode « push » dans lequel le client abonné reçoit
l’information mise à jour et un mode « notification » dans lequel le client ne reçoit que
l’évènement de notification de la mise à jour, il doit ensuite effectuer une requête pour récupérer
l’information.
Le protocole SIRI structure les types de requêtes (services) suivant trois focalisations
principales : une focalisation centrée ligne, une centrée arrêt et une centrée véhicule.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 25 sur 159
• Les services centrés « ligne » sont « Production Timetable » et « Estimated Timetable » qui
correspondent respectivement aux horaires planifiés et recalés pour une ligne.
• Le service centré « véhicule » est « Vehicule Monitoring » qui permet la localisation d’un
vehicule dans sa course
• Les services centrés « arrêt » sont « Stop Timetable », « Stop Monitoring » qui permettent
d’obtenir les informations liées à un arrêt (lignes, arrivées et départs prévus).
A ces trois catégories s’en ajoute une quatriéme centrée sur la gestion des correspondances («
Connection Timetable Delivery » et « Connection Monitoring »).
Le STIF [3] a spécifié un profil pour les premières phases de déploiement qui repose uniquement
sur un protocole requête-réponse et utilise le service « Stop Monitoring », il prévoit aussi
l’utilisation du service, non énuméré ci-dessus, « General Message » qui a pour but d’offrir un
cadre pour l’échange d’information libre ou non déjà spécifiée par un service existant SIRI.
4.2 Structure du protocole utilisé dans l’application RAMPE
Nous nous intéresserons ici à la structure et au type des données développé dans le cadre du
projet RAMPE [5]. En effet dans le cadre de ce projet un effort avait été porté sur la définition et
la spécification des données nécessaires pour être en mesure de fournir de manière efficiente de
l’information voyageur à destination des personnes ayant une déficience visuelle.
Figure 7 : Modélisation de la chaîne de déplacement
Les résultats du projet RAMPE en ce qui concerne la définition et la structuration de
l’information voyageur avaient été de deux types :
• Contextualiser l’information en fonction de l’étape de la chaîne de dépalcement dans laquelle
on se trouve.
• Adoption de la syntaxe XML pour définir la nature des informations, car elle permet par son
système de balisage la validation des informations mises à disposition en chaque nœud du
système d’information et sa structure arborescente permet une configuration efficiente des
informations.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 26 sur 159
Pour mémoire [5], quatre zones géographiques avaient été identifiées (Figure 7) : zone ouverte,
zone d’accès, zone de transfert et zone véhicule. Dans le cas d’un déplacement utilisant le bus,
ce modèle avait permis d’identifier et de gérer trois étapes d’information avant l’entrée dans le
véhicule :
• La détection de la présence d’un arrêt dans l’espace ouvert.
• Le guidage et la canalisation vers l’arrêt dans la zone d’accès
• Les informations transports propres à l’arrêt dans la zone de transfert.
Dans le cas de l’application RAMPE, la détection de la présence d’un arrêt était réalisée par
l’analyse de la structure du SSID diffusé par le point d’accès WiFi embarqué dans le point
d’arrêt dont la structure était la suivante : <Prefix RAMPE><nomArret>/<destination>. D’autres
mécanismes de détection peuvent être spécifiés dans le cas de l’utilisation d’une autre couche
physique, par exemple bluetooth (cela correspond à la notion de couche de convergence abordée
dans la partie portant sur la normalisation). Le guidage à proximité de l’arrêt par la diffusion
d’une balise sonore sur requête de l’utilisateur et les informations transports par téléchargement
d’un fichier XML contenu dans l’unité centrale embarquée dans le point d’arrêt.
La séquence de dialogue correspondant à l’échange de ces informations et mettant en jeu les
acteurs suivants : utilisateur, application embarquée sur le dispositif utilisateur, point d’accès et
serveur d’information embarqués dans le point d’arrêt est représenté Figure 8.
Figure 8 : Séquence du dialogue dans l’application RAMPE
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 27 sur 159
Figure 9 : Pile protocole utilisée par le système d’information RAMPE
La structure du dialogue entre le dispositif utilisateur et la borne d’arrêt mis en œuvre dans
l’application RAMPE met en œuvre plusieurs couches protocoles illustrée Figure 9 et comporte
4 phases :
• Détection des arrêts présents et sélection d’un arrêt d’intérêt. Cette sélection est réalisée par
une association WiFi et négociation DHCP permettant d’insérer le dispositif utilisateur dans
le réseau local de la borne d’arrêt.
• Aide à l’orientation et au guidage. Dans cette phase le dispositif utilisateur envoit à la borne
des trame de commande utilisant le protocole TCP pour que la borne émette une balise sonore
de repérage dans l’espace.
• Téléchargement de la base de donnée utilisant une structure XML « propriétaire » liée à la
borne. Cette requête utilise le protocole HTTP-GET et permet de télécharger l’ensemble des
informations voyageurs théoriques ou actualisées liées à un arrêt : lignes désservies,
composition de ces lignes, correspondances présentes sur ces lignes, horaires de passage à
l’arrêt courant pour l’ensemble des lignes.
• Diffusion par la borne d’arrêt des messages asynchrones ou « urgents » : arrivée d’un
véhicule, message de perturbation, … Cette phase de dialogue utilise le protocole UDP en
mode broadcast.
La structure des données informations voyageurs élaborée lors du projet RAMPE, peut être
définie, par analogie avec les notions utilisées dans SIRI, comme centrée sur l’arrêt. Le schéma
XML correspondant est représenté Figure 10.
Ce fichier XML contient pour chaque arrêt, la liste des lignes habituellement desservies à cet
arrêt ; pour chaque ligne, les horaires de passages à cet arrêt de l’ensemble des courses, la liste
des arrêts ; pour chaque arrêt, la liste des correspondances ainsi qu’un attribut particulier
optionnel : le « squelette » qui indique que cet arrêt à un intérêt particulier en terme de
correspondance ou de service public desservi par exemple. L’ensemble de ces informations est
ensuite utilisé par l’application embarquée afin de permettre à l’utilisateur de naviguer dans ce
flot d’information.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 28 sur 159
Figure 10 : Schéma de données XML des informations voyageurs propre à un arrêt dans
l’application RAMPE
4.3 Utilisation des services SIRI pour l’implémentation du
protocole INFOMOVILLE
L’adoption du protocole SIRI pour réaliser dans le système INFOMOVILLE des services
analogues à ceux proposés par le système RAMPE mais étendu aux personnes ayant une
déficience auditive pose le problème de la projection des services d’une application de ce type
sur les services offerts par le protocole SIRI. Les services offerts par le système INFOMOVILLE
repose d’une part sur le téléchargement des informations de desserte des lignes passant à un arrêt
et d’autre part sur la diffusion d’informations voyageur temps-réel que l’utilisateur ne peut
connaître a priori et dont il ne peut effectuer la requête.
La récupération de l’ensemble des informations de desserte théoriques ou recalées peut utiliser le
service « Stop Monitoring » spécifié dans le profil STIF [3] à partir du moment où l’identifiant
SIRI de l’arrêt physique est connu de l’application. Par contre la diffusion d’informations
temps-réel dont l’existence n’est pas connue par avance ne peut s’inscrire dans un schéma de
requête-réponse, mais seulement d’abonnement qui n’est pour l’instant pas retenu dans le profil
STIF. La connaissance de l’identifiant SIRI de l’arrêt, des informations contextuelles liées à
l’arrêt (carte géo-référencée, coordonnées GPS des différents arrêts présents sur un pôle
d’échange, …) peuvent être définis dans la structure d’une requête « General Message » réalisée
par le dispositif utilisateur lors de la connexion à l’arrêt.
La gestion des messages urgents tel que arrivée d’un véhicule pose un problème particulier dans
le sens où ils reposent sur une communication radio (433MHz) directe entre le véhicule et l’arrêt
dans le cas du bus, ils pourraient s’inscrire dans un schéma utilisant les services offerts par des «
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 29 sur 159
General Message » spécifiques dont la délivrance serait réalisée sur abonnement, celui-ci étant
considéré comme implicite lors de la requête par un dispositif utilisateur de l’identifiant SIRI
d’un arrêt.
L’utilisation du protocole SIRI pour un système comme INFOMOVILLE constitue une étape
importante vers l’interopérabilité des systèmes d’information voyageur, cependant ce type de
service ne prend son sens que s’ils sont aussi capables de gérer de l’information temps-réel.
4.4 Le système d’interface SIRI implémenté à Lyon sur le réseau
SYTRAL
Le profil de la norme SIRI implémenté à Lyon correspond au profil défini dans le document [3]
et publié par le CERTU. Parmi l’ensemble des services spécifiés dans le protocole SIRI, il ne
retient que les services « Stop Monitoring » pour les informations centrées sur l’arrêt et «
General Message » pour les informations de perturbation. Ces deux services sont accessibles en
mode requête/réponse. L’accès aux informations se fait par l’intermédiaire de la plateforme eDylic (e-dynamic lyon information center), cette plateforme réalise l’interface, en ce qui
concerne le projet INFOMOVILLE, avec les systèmes fournisseurs de données Visulys pour le
réseau de bus et SAE Tramway. L’interface avec les systèmes consommateurs de données est
réalisée par NAViTiA qui offre au travers de SIRI une interface vers les services « Stop
Monitoring », « General Message » et «Check Status ».
L’architecture du système d’information INFOMOVILLE est représenté Figure 11.
Figure 11 : Archiecture du système d’information INFOMOVILLE
Dans ce système la borne d’arrêt embarque un serveur SIRI qui s’interface avec le client contenu
dans le dispositif utilisateur et un client SIRI qui s’interface avec NAViTiA. L’application
contenu dans la borne d’arrêt réalise une passerelle entre l’application contenue dans le dispositif
utilisateur et le système NAViTiA en retransmettant les requêtes vers le serveur NAViTiA à
travers un réseau 3G et les réponses vers le client utilisateur à travers un réseau WiFi.
Le système INFOMOVILLE introduit aussi de nouvelles informations à destination de
l’application utilisateur qui n’étaient pas disponibles dans l’application RAMPE : des
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 30 sur 159
informations contextuelles permettant de situer et de connaitre la structure d’un site multimodal,
ainsi que des informations de guidage pour l’aide à la gestion des correspondances. Ces
informations ne sont pas spécifiées par le protocole SIRI et ne sont pas disponible dans le
système e-Dylic dont elles constituent un prolongement dans le cadre de l’application
INFOMOVILLE. L’application INFOMOVILLE utilise le canal « General Message » pour
transmettre ces informations sur requête. Ces informations sont contenues dans la borne d’arrêt
et sont spécifiées par un schéma XML développé dans le cadre du projet INFOMOVILLE
représentée Figure 12.
Figure 12 : Schéma XML des informations contextuelles à un arrêt délivré au travers d’un canal
« General Message ».
Dans le projet INFOMOVILLE, la phase de détection de la présence d’arrêt dans l’espace ouvert
est toujours réalisée par la structure spécifique du SSID dans le cas de l’utilisation d’une
connexion WiFi, par contre l’étape suivante d’aide à l’orientation et au guidage est réalisée à
l’aide d’une requête SIRI utilisant le canal « General Message ». Le téléchargement des
informations voyageurs liées à l’arrêt courant sont récupérée par l’intermédiaire d’une requête «
Stop Monitoring » qui est relayée par le point d’arrêt vers le système NAViTiA, la réponse est
retransmise par le point d’arrêt vers le dispositif utilisateur.
Pour pouvoir réaliser une requête « Stop Monitoring » il faut fournir l’identifiant SIRI de l’arrêt
concerné. La structure de cet identifiant est propre à chaque système d’information, à Lyon, par
exemple il a la structure suivante TITAN:StopPoint:<BP/SP>:xxxx:LOC où BP/SP spécifie la
manière dont l’on veut considérer l’arrêt et xxxx est une valeur numérique unique pour un arrêt.
La notion d’arrêt dans la norme SIRI répond à trois notions :
• StopPlace (SP) : lieu regroupant plusieurs arrêts physiques
• BoardingPlace (BP) : arrêt physique
• StoPOnRoute (SPOR) : arrêt sur une course (ligne).
Un arrêt BP qui correspond à un arrêt physique est donc composé d’autant d’arrêt SPOR que de
ligne desservie. Un arrêt SP regroupe l’ensemble des arrêts physique sur un même site. Cette
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 31 sur 159
représentation est illustrée Figure 13.
Figure 13 : Modèle de représentation des arrêts dans SIRI
La séquence du dialogue entre un dispositif utilisateur et une borne d’arrêt est illustrée Figure
14.
Figure 14 : Séquence du dialogue dans l’application INFOMOVILLE
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 32 sur 159
L’implémentation du système d’information INFOMOVILLE utilise trois requêtes « General
Message » qui sont gérées par le point d’arrêt, la nature de ces requêtes est spécifiée dans la
balise <InfoChannelRef> de la requête « General Message » :
• Identifiant : qui permet à l’application utilisateur de récupérer l’identifiant BP de l’arrêt afin
de pouvoir effectuer la requête « Stop Monitoring »
• Carillon : qui provoque la génération des balises sonores et visuelles permettant l’orientation
et le guidage.
• Plan : qui permet à l’application de récupérer les informations contextuelles (Figure 10).
La récupération des informations transports est réalisée par l’application utilisateur qui effectue
une requête « Stop Monitoring » en utilisant l’identifiant BP ce qui lui permet de récupérer les
données de l’ensemble des lignes passant à cet arrêt. La requête est réalisée en demandant les
deux prochains passages pour l’ensemble des arrêts jusqu’au terminus de la ligne.
L’information « arrivée imminente » d’un véhicule est obtenue à l’arrêt par une communication
radio directe entre le véhicule et l’arrêt, elle n’est donc pas contrôlée par le système
d’information central. C’est la raison pour laquelle, elle est diffusée directement par la borne
d’arrêt vers les dispositifs utilisateurs en utilisant le protocole UDP en mode broadcast.
La structure de la pile protocole utilisée par l’application INFOMOVILLE est représentée Figure
15.
Figure 15 : Pile protocole utlisée par le système d’information INFOMOVILLE
4.5 Conclusion
Le système d’information INFOMOVILLE intègre le protocole SIRI comme support d’échange
de message. L’expérimentation de terrain a montré la pertinence de cette approche qui permet
d’avoir accès aux informations théoriques et recalées.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 33 sur 159
Il a illustré aussi l’importance d’informations contextuelles locales pour un dispositifs d’aide au
déplacement dans les transports publics, des solutions ont été proposées pour intégrer ces
informations dans le cadre du protocole SIRI par l’utilisation du service « General Message ».
[1] CEN/TS 15531 SIRI Specification Service interface for real-time information relating to public transport
operations.
[2] SIRI Handbook & Functional Service Diagrams, Nick Knowles, Kizoom, 2008
[3] STIF. « Normalisation des échanges de données d'information voyageur temps réel, SIRI Profil d'échange pour
l'Île-de-France ». CERTU. fév 2010
(http://www.certu.fr/fr/catalogue/product_info.php?products_id=2508&language=fr)
[4] E-DYLIC, Contrat d’interface général pour la diffusion, 2008, SYTRAL
[5] G. Baudoin, O. Venard, G. Uzan, A. Paumier, and J. Cesbron. Le projet rampe : Système interactif
d’information auditive pour la mobilité des personnes aveugles dans les transports publics. In UBIMOB’05Mobilité et Ubiquité, 2ème Journées Francophones, pages 169–176, Grenoble, France., du 31 Mai au 3 Juin
2005.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 34 sur 159
5 La borne INFOMOVILLE
Cette section constitue le rapport technique final de la borne INFOMOVILLE mise en œuvre
dans le cadre de l’expérimentation du projet INFOMOVILLE.
Liste des abbréviations untilisées dans la section :
Acronyme/Acronym
SIRI
SAE
SIV
BIV
UDP
PDA
Description/Description
Service Interface for Realtime Information
Système d’Aide à l’Exploitation
Système d’Information Voyageur
Borne d’Information Voyageur
User Datagram Protocol
Personal Digital Assistant
L’expérimentation du projet INFOMOVILLE a été conduite sur le réseau de TCL LYON en
collaboration avec le SYTRAL.
Les sites d’expérimentation ont été choisis sur des arrêts de bus et des pôles d’échange bus,
tramway et métro. Ces sites sont équipés de bornes VISULYS Lumiplan : pour les arrêts de bus
le modèle HORUS et pour les arrêts Tramway le modèle MARCUS.
L’installation sur site des équipements INFOMOVILLE s’appuie sur l’infrastructure existante
des bornes VISULYS bus et tramway en place sur le site, notamment pour les parties fixations
mécaniques et pour la source d’alimentation 220 volts.
Afin de proposer un service d’information temps-réel des horaires des prochains passages de
bus, une connexion est assurée avec le serveur d’information TCL de Lyon. Le protocole SIRI a
été retenu pour cette liaison entre le serveur d’horaires TCL et la borne Infomoville. Ce
protocole est une norme européenne pour échanger en temps-réel des informations sur les
horaires de transports en commun, sur la base d’une formalisation des données issue des travaux
TRANSMODEL. L’implémentation SIRI utilisée ici correspond au profil Ile-de-France, profil
retenu pour les projets SIRI en France.
Les fonctions de base de la borne INFOMOVILLE couvrent les aspects suivants :
• La borne est en liaison radio 3G avec le serveur TCL Lyon pour récupérer les données
transports (référentiel théorique et information temps-réel) au format SIRI.
• La borne possède une liaison WIFI pour dialoguer avec le Smartphone qui est le support de
l’information du PMR (sonore pour le non-voyant et visuel pour le mal-entendant).
• La borne possède une fonction sonore pour émettre un son de localisation et éventuellement
diffuser l’information des prochains passages. Le dispositif de localisation est complété par
un voyant pour les personnes mal-entendantes.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 35 sur 159
• À la demande du SYTRAL, la fonction d’affichage de la borne actuelle pour la clientèle n’est
pas modifiée par l’expérimentation INFOMOVILLE. En conséquence la fonction d’affichage
reste sur la borne VISULYS en place et le module INFOMOVILLE ne comporte pas de
fonction d’affichage.
• Pour compléter l’information temps-réel avec l’approche du bus qui existe dans le système
VISULYS (dialogue radio entre le bus et la borne) la borne INFOMOVILLE récupère
l’information présence bus à l’arrêt sur la carte de la borne VISULYS par liaison série.
• Enfin au travers des liaisons radio 3G et WIFI, la borne peut assurer la fonction de routage
des demandes EKAHAU pour la localisation entre le Smartphone et le serveur EKAHAU
distant.
• De manière connexe à l’application INFOMOVILLE et indépendamment du Smartphone, la
borne INFOMOVILLE peut délivrer une information sonore des prochains passages. Cette
diffusion est déclenchée à partir d’une télécommande standard de type feux de carrefour pour
personnes malvoyantes.
5.1 Spécifications fonctionnelles des bornes
5.1.1 Principes
1
Serveur
d’Information
Voyageur
SIRI
3
Borne
d’Information
Voyageur
Radio
2
Véhicule
SIRI et UDP
4
Mobile
Figure 16 : Principe fonctionnel général
5.1.1.1 Le Serveur d’Information Voyageur
Le serveur d’information voyageur, propose les informations du réseau ou des réseaux de
transports, au format SIRI :
• Données théoriques
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 36 sur 159
•
•
Messagerie
Suivi temps réel des heures de passages
5.1.1.2 Le véhicule
Le véhicule, équipé d’un système GPS, remonte ses informations de position au serveur SAEIV.
Une infrastructure radio lui permet également d’informer les BIV de son arrivée imminente.
5.1.1.3 La Borne d’Information Voyageur
La borne d’information voyageur affiche les prochaines heures de passages des véhicules à un
arrêt, ainsi que différents messages relatifs à la communication à destination des usagers.
Le projet Infomoville ne modifie pas l’infrastructure en place, un matériel dédié vient se
‘greffer’ sur la BIV pour cette expérimentation, sans affichage supplémentaire.
La borne INFOMOVILLE apporte les fonctionnalités suivantes :
• Connexion 3G. La BIV est muni d’un accès internet 3G.
• Point d’accès WIFI. La BIV met à disposition un réseau WIFI en y proposant une passerelle
vers sa connexion internet 3G.
• Client SIRI. La BIV interroge sur demande les services web SIRI du serveur SYTRAL edylic. Pour permettre cet échange, la récupération des informations théoriques est réalisée
auprès du serveur SYTRAL Titan.
• Serveur SIRI. La BIV met à disposition des mobiles les informations temps réels obtenues,
au même format SIRI, sur service web (SOAP).
• Véhicule à l’approche. Sur réception du signal radio en provenance du véhicule à
l’approche, la BIV créé dynamiquement un message dans un format binaire propriétaire
qu’elle diffuse en mode broadcast (UDP) sur le réseau wifi qu’elle gère.
• Signal de localisation. Sur requête SIRI (General Message) d’un mobile connecté au réseau
WIFI, la borne émet un signal sonore complété par un voyant lumineux.
• Annonce sonore. La borne diffuse sous forme sonore les informations des prochains
passages.
5.1.1.4 Le mobile
Le mobile, équipé de la technologie WIFI, se connecte au réseau par l’intermédiaire de la BIV
située dans sa zone de portée.
Munit d’une application spécifique, il peut alors interroger les services web de la borne, au
format SIRI via SOAP, et recevoir les informations disponibles à l’arrêt.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 37 sur 159
5.1.2 Architectures
SAEIV
LAN / WAN
3G / EDGE
BIV
LAN
WIFI
Mobile
Figure 17 : Architecture réseau
Un routeur WIFI/3G est utilisé dans la borne afin de fournir un réseau WIFI pour la
communication entre la BIV et le mobile. La fonction 3G du routeur permet quand à elle la
communication entre la BIV et le serveur SIRI Sytral accessible à distance via Internet. La
liaison radio 3G permet également un partage de connexion Internet entre la BIV et le mobile et
autorise ainsi le mobile à interroger le serveur EKAHAU à distance. Le serveur EKAHAU est
situé à l’ESIEE.
5.1.2.1 Architecture principale
WAN-3G
Infrastructure existante
EKAHAU
E-DYLIC
UC
InfoMoville
LAN - WIFI
Véhicule
BIV
VISULYS
PDA
PDA
PDA
RADIO VISULYS
SIRI Web Service/SOAP
RS232
Socket UDP
Routage IP
Figure 18 : Architecture principale
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 38 sur 159
5.1.2.2 Architecture logicielle de l’UC InfoMoville
E-DYLIC
UC InfoMoville
Client Serveur
SIRI
PageEntiere
PDA ou
smartphone
Zone mémoire partagée
BusApproche
BIV VISULYS
TextToSpeech
SIRI Web Service/SOAP
RS232
Socket UDP
Socket TCP
Figure 19 : Architecture logicielle de l’UC InfoMoville
Client Serveur SIRI : Client SIRI qui interroge sur demande les services Web SIRI du serveur
SYTRAL e-dylic et Serveur SIRI qui permet au PDA de récupérer les informations temps réel
obtenues ;
BusApproche : Applicatif qui reçoit l’information de bus à l’approche de la BIV VISULYS sur
un lien RS232 et qui relaie cette information vers les PDAs sur un socket UDP en mode
broadcast ;
PageEntiere : Applicatif qui est chargé par l’applicatif Client Serveur SIRI de déclencher le
carillon et d’allumer le voyant lumineux sur requête d’un PDA, puis d’éteindre le voyant
lumineux. Client Serveur SIRI fournit également les informations temps réel de prochains
passages et la messagerie récupérées sur le serveur SYTRAL e-dylic à l’applicatif PageEntiere à
la demande de ce dernier. La communication entre Client Serveur SIRI et PageEntiere se fait sur
un socket TCP (PageEntiere étant le serveur et Client Serveur SIRI étant le client) dans le
protocole PageEntiere Lumiplan ;
TextToSpeech : Applicatif chargé de la diffusion sonore des informations temps réel de
prochains passages et de la messagerie fournis par l’applicatif PageEntiere au travers d’une zone
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 39 sur 159
mémoire partagée. L’annonce sonore est déclenchée à l’aide d’une télécommande feux de
carrefour.
5.1.2.3 Communication BIV / SAEIV
Les échanges d’informations entre la BIV et le SAEIV sont réalisés au format SIRI. Le format
SIRI propose deux modes de connexion qui influent directement sur l’architecture physique du
réseau de BIV.
5.1.2.3.1 SIRI – mode direct
Le premier mode, direct (question / réponse), conduit la BIV à interroger un fournisseur de
données, le SAEIV, sur les informations à présenter. La BIV, invisible du fournisseur, prend à sa
charge le rafraîchissement de ses informations en interrogeant régulièrement son fournisseur.
SAEIV
LAN / WAN
3G / EDGE
2
1
1
Question
2
Réponse
BIV
Figure 20 : SIRI Mode Requête
5.1.2.3.2 SIRI – mode retenu
Dans l’environnement du projet Infomoville, la BIV se nourrie des informations temps réel du
serveur SITRAL e-dylic. Cet échange sera réalisé par une interrogation (mode requête) de la
BIV au serveur.
5.1.2.3.3 Conception du serveur SIRI (Borne)
Le serveur SIRI est à la fois un fournisseur de service pour le téléphone mobile et un client des
services SIRI proposés par le SYTRAL.
Serveur SIRI existant :
En amont du projet SIRI, LUMIPLAN avait développé un serveur SIRI d’accès aux données de
son propre SAE. La conception de ce serveur est basée sur la réutilisabilité du code pour un
interfaçage aisé sur un SAE différent de celui de LUMIPLAN. Pour se faire, différentes briques
ont été développées.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 40 sur 159
Gestion du protocole SOAP
Briques
Communes
Modèle objet SIRI
Définition des services SIRI
Adaptateurs GeneralMessage
Briques
Spécifiques au
système
d’accès aux
données
Adaptateurs StopMonitoring
….
Figure 21 : Briques du serveur SIRI
Les adaptateurs sont des composants propres un système de récupération des données permettant
la mise en forme des données nécessaires à la constitution d’une réponse à une requête SIRI.
Serveur SIRI Infomoville
Comme nous avons pu le voir précédemment, le serveur SIRI LUMIPLAN a été développé sous
forme de briques applicatives, permettant la réutilisabilité d’un maximum de composants en
fonction des besoins.
Dans le cadre d’Infomoville, l’utilisation du protocole SIRI, nous a permis de réutiliser les
briques communes propres au protocole. Les développements se sont donc portés sur la
définition de nouveaux adaptateurs.
Le principe des adaptateurs pour Infomoville est le suivant :
•
•
•
•
L’adaptateur d’un service SIRI reçoit la demande de composition d’une réponse SIRI
Il utilise la même requête SIRI envoyé par le téléphone pour interroger le Serveur SIRI
Sytral à l’aide de son propre client SIRI.
Il récupère la structure de réponse du serveur SYTRAL et la formate dans la version SIRI
utilisée par le mobile.
Il transmet cette réponse au module de gestion du protocole SOAP pour l’envoyer jusqu’au
mobile.
Dans le cas de l’adaptateur pour le GeneralMessage, la gestion d’« InfoChannel » spécifiques
Infomoville ont été ajoutés (Plan, Identifiant, Carillon) pour permettre une interactivité entre la
borne et le téléphone en marge du protocole SIRI. Dans ces cas, la requête n’est pas transmise au
serveur SIRI Sytral mais est directement traitée par la borne.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 41 sur 159
5.1.2.4 Communication BIV / Mobile
La communication entre la BIV et le mobile s’effectue au travers d’un réseau WIFI. Les
échanges sont réalisés systématiquement au format XML SIRI excepté pour l’extension bus à
l’approche. Toutefois, selon le type des messages échangés, les échanges auront lieu soit :
• au travers de services web SIRI sur protocole SOAP, dans le cas des temps d’attente et
messages du profil IDF ainsi que les extensions (carillon et plan).
• au travers d’un canal UDP, en mode push, dans un format binaire propriétaire non SIRI,
dans le cas de l’extension bus à l’approche.
Les deux diagrammes ci-après décrivent ces deux liens d’échanges.
5.1.2.5 Diagramme des échanges
Figure 22 : Diagramme des échanges SIRI XML/SOAP
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 42 sur 159
Figure 23 : Diagramme des échanges UDP
5.1.2.6 Extensions – Profil Infomoville
Dans le cadre de l’expérimentation Infomoville, quatre autres besoins apparaissent dans les
échanges temps réel entre la BIV et le mobile :
• Communication de l’identifiant d’arrêt (BP : Boarding Place) aux mobiles qui se connectent
• Service de localisation sonore
• Véhicule à l’approche
• Service de plan de quartier.
Le profile Infomoville englobe l’ensemble des descriptions dans le profil Ile De France,
complété par 4 valeurs de la structure InfoChannel :
1. « Perturbation »
2. « Information »
3. « Commercial »
4. « Identifiant »
5. « Carillon »
6. « Approche »
7. « Plan »
InfoChannel « Identifiant » : Ce type info channel permet aux applicatifs clients d’obtenir la
référence de l’arrêt physique utilisable pour interroger le service StopMonitoring.
InfoChannel « Carillon » : Ce service permet aux applicatifs clients de déclencher le carillon de
la borne.
InfoChannel « A l’approche » : Ce type de message permet de signaler aux applicatifs clients
du réseau local, de l’arrivée imminente d’un véhicule.
Ceci s’apparente au mode abonnement de SIRI dans sa phase ‘push’. Toutefois, cette phase sera
implémentée sur un port UDP, lequel sera utilisé pour diffuser en mode ‘broadcast’ l’information
de passage dans un message au format binaire propriétaire non SIRI (cf. §5.1.3.2).
InfoChannel « Plan » : Ce type de message permet aux applicatifs d’obtenir la ou les références
(url) des plans de quartier disponibles à l’arrêt. Le PDA, une fois obtenu les url, peut procéder à
un téléchargement par requête http.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 43 sur 159
5.1.3 Échanges avec le Smartphone
5.1.3.1 Déclenchement du carillon
Le client mobile, émet une demande GeneralMessage en filtrant l’infoChannel « Carillon ».
Le système de carillon consiste à émettre un son audible à moyenne distance et à l’allumage
d’une LED puissante permettant à la fois aux mal-voyants et aux mal-entendants de localiser
l’arrêt sélectionné sur le mobile. La durée de l’activation est paramétrable dans un fichier de
propriétés.
Requête SIRI d’activation du Carillon
Réponse SIRI validant l’activation du Carillon
Boitier
Infomoville
La réponse a pour seule vocation de réaliser un échange SOAP complet.
5.1.3.2 Véhicule à l’approche
Dès l’approche d’un véhicule en station, le message binaire propriétaire « bus à l’approche » est
diffusé, pour la ligne desservie en mode broadcast sur le protocole UDP. Chacun des mobiles du
réseau local en écoute du même port, en sont ainsi alertés.
Exemple : Bus à l’approche pour la ligne 034 en direction de CHARPENNES le 05/03/2007 à
10h26 et 36 secondes (Les caractères « < » et « > » sont mis pour la compréhension de l’exemple
; ils ne font pas partis de la trame et en doivent pas être envoyés).
La ligne est sur 8 caractères en 2x4 et la destination est sur 32 caractères en 2x16 :
<0x02><0037><V><050307102636><996><034 + 5 espaces><CHARPENNES><108><0x0D>
5.1.3.3 Demande du plan de quartier
Le client mobile, émet une demande GeneralMessage en filtrant l’infoChannel « Plan ».
L’option de gestion du plan est utilisée pour permettre à l’utilisateur du téléphone de récupérer
différentes informations de géolocalisation sur le site où se situe la borne.
Requête SIRI de demande
d’informations de géolocalisation de
Réponse SIRI contenant la structure
XML de description du site de la borne.
Boitier
Infomoville
Le mobile peut alors accéder au plan de quartier via l’url précisée dans le contenu de la réponse.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 44 sur 159
5.1.3.4 Demande d’identifiant d’arrêt d’une borne
Le client mobile, émet une demande GeneralMessage en filtrant l’infoChannel « Identifiant ».
Cette fonction permet à l’application mobile de récupérer l’identifiant SIRI de l’arrêt de la borne
correspondant au réseau WIFI sur lequel elle vient de se connecter. Cet identifiant est utilisé
ensuite pour construire les requêtes SIRI de récupération des heures de passages pour l’arrêt.
Requête SIRI de demande
d’identifiant de la borne
Réponse SIRI contenant l’identifiant de
l’arrêt de la borne
Boitier
Infomoville
5.1.3.5 Demande de vérification du status du système:
Le status du serveur Infomoville prend en compte l’état de la connexion avec le serveur
SYTRAL mais aussi avec le soft borne.
La balise “ErrorText” indique la partie du système ayant rencontré un problème. (Dans cet
exemple, la communication entre la borne et le serveur Infomoville).
5.1.4 Échanges entre les applicatifs de l’UC InfoMoville
Les échanges entre les applicatifs Client Serveur SIRI et PageEntiere de l’UC InfoMoville sont
réalisés dans le protocole Lumiplan Page Entière sur un lien socket TCP. La communication est
à l’initiative du Client Serveur SIRI qui se connecte sur le serveur TCP de l’applicatif
PageEntiere.
Différents types de paquets PageEntiere sont échangés :
•
•
•
•
Commande V action A pour allumer le voyant et déclencher le carillon ;
Commande V action E pour éteindre le voyant ;
Commande E pour l’annonce sonore des prochains passages et de la messagerie ;
Commande K action 004 pour déclencher une requête SIRI vers le serveur SYTRAL.
Les paquets PageEntiere seront envoyés avec le champ « Numéro panneau » pour inhiber la
réponse de l’applicatif PageEntiere.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 45 sur 159
5.1.4.1 Voyant et carillon
Figure 24 : Déclenchement du voyant et du carillon
Le carillon est un fichier WAV.
5.1.4.2 Annonce sonore
Figure 25 : Annonce sonore
Les blocs de prochains passages introduis dans la commande E auront le format suivant :
• Prochains passages ligne <Ligne> vers <Destination> dans n minutes puis vers <Destination>
dans n minutes.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 46 sur 159
A la fin de chaque bloc, il y aura une temporisation de 2 secondes par défaut (Sous commande
<ESC>T02 de la commande E).
Les blocs de messages introduits dans la commande E auront les formats suivants :
• Ligne <Ligne> <Message> pour les messages lignes ;
• <Message> : pour les messages généraux.
À la fin de chaque bloc, il y aura une temporisation de 2 secondes par défaut.
5.2 Spécifications matérielles des bornes
5.2.1 Caractéristiques matérielles
La borne INFOMOVILLE se compose de :
• Une carte PC avec un système d’exploitation XP sur disque dur,
• Un routeur WIFI / 3G pour le dialogue avec le Smartphone en WIFI et la liaison 3G avec le
serveur de données TCL,
• Un module sonore ampli, micro, HP, licence TTS et une carte récepteur télécommande pour
la diffusion sonore locale à la borne,
• Un voyant lumineux clignotant,
• Une liaison série RS232 disponible pour dialoguer avec la carte UC de la borne VISULYS,
• Une alimentation 12 volts à partir du 220 volts,
• Un disjoncteur avec un borne de raccordement de l’alimentation 220 volts.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 47 sur 159
La carte UC communique avec un modem 3G, piloté par le système d’exploitation Win XP avec
routage IP activé vers le modem 3G.
La carte UC est reliée par une liaison Ethernet pour se connecter au routeur WIFI.
La carte UC supporte une licence TTS Acapella et une JVM Sun Embedded (compatible J2SE)
avec une centaine de Mo de RAM dispo pour l’application JAVA (AXIS).
La borne INFOMOVILLE est implantée en extérieur. Son coffret est étanche.
L’infrastructure WIFI des bornes ainsi que la liaison 3G sont également utilisées par un module
de localisation par WIFI (logiciel EKAHAU RTLS) implanté sur le Smartphone en liaison avec
un serveur de localisation EKAHAU.
Pour les arrêts de bus, la borne INFOMOVILLE est installée sur le mât qui supporte la borne
VISULYS en place.
Un système de prolongement de mât a été étudié pour positionner la borne INFOMOVILE audessous de la borne VISULYS.
Figure 26 : Détail de la pièce de raccordement au mât
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 48 sur 159
Fig
ure 27 : Détail du montage sur le mât avec la borne VISULYS
5.2.2 Installation des bornes
Dans le cadre de l’expérimentation sur le réseau des transports de LYON, 6 bornes
« Infomoville » ont été installées avec 2 bornes Tramway et 4 bornes Bus.
Une borne « fictive » avec le logiciel de la borne Infomoville est installée dans le local d’accueil
des expérimentateurs pour leur présenter le fonctionnement du système
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 49 sur 159
5.2.2.1 Installation aux stations de tramway
Figure 28 : Station tramway avant installation de la borne Infomoville
Figure 29 : Borne Infomoville installée sur une station de tramway
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 50 sur 159
5.2.2.2 Installation aux arrêts de bus
Figure 30 : Site arrêt de bus avec la borne VISULYS avant installation
Figure 31 : Borne Infomoville installée à un arrêt de bus
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 51 sur 159
5.3 Bilan en vue d’un déploiement
Dans le cadre d’un déploiement de bornes INFOMOVILLE, les contraintes d’installation sont
les suivantes :
• La borne doit mettre en œuvre une liaison haut-débit avec le serveur local d’information SIRI,
• La borne doit être alimentée avec une source permanente,
• La couverture WIFI vis-à-vis des points de correspondance sur le pôle d’échange devra faire
l’objet au préalable de mesures et d’une validation sur site.
5.4 Annexes liées à la borne
Les annexes B1 et B2 présentent en détails certains points techniques des bornes.
5.5 Références pour la section
[1] Profil Siri Ile De France - STIF- V2.1.pdf : Local Agreement SIRI - Ile De France.
[2] Client DRYADE : Client de test mis à disposition de l’ESIEE par DRYADE (Client SOAP SIRI (1.3))
[3] Outils référents pour la nature des requêtes SIRI entre mobile et borne.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 52 sur 159
6 Architecture logicielle de l’application embarquée
dans le dispositif utilisateur
Le système d’information INFOMOVILLE cherche à intégrer dans un seul dispositif utilisateur
(un smartphone) un outils d’information pour l’assistance au déplacement dans les transports
public et un outils d’aide à la localisation et au guidage dans les zones d’échange de transport
public. Les infrastructures matérielles correspondant à ces deux services se superpose dans les
système INFOMOVILLE, même si elles sont représentées Figure 32 et Figure 33 séparement
pour plus de clarté.
Figure 32 Infrastructure du système INFOMOVILLE pour l’aide à la localisation
Figure 33 Infrastructure du système INFOMOVILLE pour l’accès à l’information voyageur
L’application INFOMOVILLE résidente dans le dispositif utilisateur intègre une Interface
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 53 sur 159
Homme Machine dont l’objectif est d’une part de présenter l’information transport ou de
localisation/guidage de manière pertinente et d’autre part d’offrir une interface de dialogue avec
l’utilisateur qui permettra de séquencer l’évolution de la navigation dans l’application.
6.1 Objectifs du système INFOMOVILLE
D’un point de vue technique le système a été conçu pour respecter les contraintes suivantes :
-
Modularité et réutilisabilité. Les différents composants du sytème ont été développé
séparément avec des interfaces clairement définies.
-
Usage. L’utilisation du système ne doit pas être contrainte du fait de la complexité de
chacun des modules.
-
Portabilité. Une attention particulière a été porté afin de permettre la portabilité de
l’application sur différents types de dispositifs utilisateurs. Le prototype a été développé
pour des smartphones équipés d’interface GPS et WiFi sous window-mobile 6.1 et a été
testé sur différents appareils.
-
Evolutivité : L’architecture de l’application doit permettre de pouvoir intégrer de
nouvelles ressources matérielles qui s’avèreraient pertinente pour ce type d’application.
Une approche introduisant une couche d’abstraction matériel doit faciliter l’intégration
de nouveau module dans l’application.
6.2 Architecture système
On peut distinguer les éléments suivants dans le système : le dispositif utilisateur, la station de
base, les communications entre ces deux éléments, la localisation, l’information transport tempsréel et l’interface homme machine. Les différents éléments techniques et les modules
correspodant sont les mêmes pour les différents types de population (déficients visuels,
déficients auditifs et personnes sans déficience sensorielle) mais l’interface homme-machine est
bien sur différente pour chaque situation. L’architecture matérielle générale est représentée
Figure 34.
6.2.1 Les Composants du système INFOMOVILLE
On peut distinguer différents modules dans l’environnement de l’applicatif utilisateur. Tout
d’abord le module de communication sans fil : WiFi dans le cas du dispositif testé lors de
l’expérimentation. Les modules utilisés comme canaux d’entrée-sortie pour l’interface homme
machine : les touches, l’écran tactile, la synthèse vocale, l’écran, le module vibratoire. Les
modules aidant la localisation comme le GPS.
Certains sont associés à une action directe de ou vers l’application comme les touches ou la
synthèse vocale, d’autres comme WiFi sont utilisés pour réaliser et fournir à l’application une
ressource à partir de l’information qu’ils véhiculent (comme dans le cas de l’information
transport) ou de leur participation à l’élaboration d’une information (comme dans le cas de la
localisation par WiFi).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 54 sur 159
Figure 34 Architecture fonctionnelle générale du système INFOMOVILLE
Figure 35 Système INFOMOVILLE correspondant à l’architecture représentée Figure 34.
6.2.1.1 Modules d’interface
Les différentes instances de l’application sont encapuslés dans des modules qui ont pour
principal objectif de créer par une interface normalisée une couche d’abstraction entre
l’application proprement dite et la gestion bas-niveau de ces ressources dont l’interface peut
varier d’un smartphone à l’autre ou d’une librairie à l’autre. Dans la phase actuelle de
développement de l’application embarquée les modules pris en charge sont :
- Clavier : module des gestions des « HOTKEYS », la principale tâche de ce module
consiste à décorréler l’application de l’encodage des touches propres à chaque
smartphone et à créer des évènements claviers propres à l’application pouvant
correspondre à différents types de manipulation des touches existantes sur les
smartphones.
- Synthèse Vocale : L’objectif de ce module est de créer une interface normalisée vers
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 55 sur 159
-
-
-
l’application indépendante de la synthèse utilisée.
Vibrateur : Module gérant l’interface vibratoire utilisée comme interface haptique.
Interface sans fil : dans le cas d’une interface WiFi, ce module gère les différentes
fonctions nécessaires à l’application INFOMOVILLE, détection des points d’arrêts
environnant par analyse des SSID captés, maintenance de la liste des arrêts détectés,
rattachement à un réseau physique lié à un point d’arrêt (connexion WiFi).
Réseau : Ce module permet de gérer de et vers l’application les évènements utilisant une
transmission TCP ou UDP, tel que arrivée imminente d’un véhicule.
SIRI : Ce module est particulièrement complexe, car il réalise une interface de haut
niveau entre les informations nécessaires à l’application, telle que les informations
voyageurs liés à un arrêt, c’est à dire les horaires de passage de l’ensemble des lignes
passant à un arrêt et la manière de les obtenir qui consiste à construire une requête XML
à la transmettre à travers une interface http, à récupérer au travers de cette même
interface la réponse du serveur au format XML, à analyser ce fichier pour en extraire les
informations utiles et construire la structure de donnée qui sera fournie au module
application.
Localisation :
o Sous module GPS : ce module permet d’effectuer une localisation au moyen du
GPS et de calculer une distance par rapport à un point de référence.
o Sous module Ekahau : Ce module permet d’effectuer une localisation au moyen
du système de localisation utilisant les signaux WiFi de l’ensemble des points
d’accès WiFi environnants inclus dans le système de localisation, en effectuant
une requête auprès du serveur de localisation Ekahau. Ce module permet aussi de
calculer une distance par rapport à un point de référence.
Figure 36 Architecture logicielle générique de l’application embarquée
-
Applicatif : L’application proprement dite qui reçoit l’ensemble des flux d’informations
qui proviennent des modules sous forme de message et qui gère l’interface homme
machine en fonction de ces évènements et du déroulement de la navigation par
l’utilisateur
est
elle
aussi
réalisée
sous
forme
d’un
module.
Ce module applicatif est relié aux modules d’interface par une file de message
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 56 sur 159
bidirectionnelle fonctionnant en mode FIFO. Cette architecture générique est illustrée
Figure 36.
6.2.1.2 Applicatif et File de message
La structure du système de messagerie permet aux messages transmis du module applicatif vers
les modules d’interface de n’être interprété que par le module destinataire et d’être ignoré par les
autres. L’applicatif gère lui les messages venant des modules d’interface par le biais du système
de messagerie. La structure de l’exploitation des messages entrants des applicatifs permet de les
répartir vers leurs destinataires. L’application Aulib se distingue sur ce point, car elle permet à
un message entrant d’être exploité par plusieurs sous-modules de traitement.
6.2.2 Interface Homme Machine
L’interface utilisateur a pour ambition d’être intuitive et d’apprentissage aisé. L’IHM (Interface
Homme Machine) pour les personnes ayant une déficience visuelle est audio (synthèse vocale et
sons) et tactile (touches et vibrateurs) alors que celle destinée aux personnes ayant une
déficience auditive est visuelle (texte, image, carte statiques ou animés) et tactile (vibrateur et
écran tactile)
L’application pour les mal-entendants est basée sur une approche GUI (Graphical User
Interface) classique, alors que les particularités d’une interface audio et ses caractéristiques
relativement différentes de celle d’une interface graphique nous ont conduit à créer un
environnement de développement spécifique pour la construction d’une application pilotée par
une interface utilisateur audio. Cet environnement est appelé AuLib dans la suite.
Alors qu’une interface graphique peut piloter efficacement (du point de vue IHM) plusieurs
éléments visuels en parallèle cela s’avère inefficient et impossible pour une interface audio. Cela
principalement du fait de la nature séquentielle et furtives des informations auditives.
L’interface logicielle AuLib prend en compte la nature séquentielle des informations audio. Elle
est pilotée par les données et permet l’ajout ou la supression dynamique de module de traitement
en fonction du contexte de l’application.
L’interface GUI utilise le système de message classique de l’environnement de développement
C++/MFC alors que AuLib implémente une gestion propre des files de messages dédiée pour
une interface utilisateur audio sérielle. Ces deux déclinaisons de l’architecture générique (Figure
36) sont représentées Figure 37 et Figure 38.
6.2.2.1 Fonctions de navigation de l’application
L’objectif principal de l’application embarquée est de fournir à l’utilisateur un moyen efficace de
naviguer dans les informations transports et contextuelles rattachées au site sur lequel il se
trouve en fonction de ses besoins. L’application doit aussi savoir alerter l’utilisateur
d’évènements liés à une modification de l’état du site du point de vue transport, par exemple :
arrivée d’un véhicule ou perturbations.
La structure de l’IHM est donc basée sur un recensement des besoins en information de
l’utilisateur au cours de sa chaîne de déplacement. Dans le cadre du projet INFOMOVILLE,
l’IHM doit être capable de fournir les outils permettant à l’utilisateur de gérer les situations
suivantes :
- Découverte des arrêts.
- Description de l’environnement du site en termes de transport et de topologie.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 57 sur 159
-
Assistance à l’orientation vers le point d’arrêt choisi. Situations des arrêts les uns par
rapport aux autres, afin de permettre une assistance aux correspondances uni-modale ou
multimodale.
- Découverte des lignes desservies à cet arrêt et temps d’attente pour chacune.
- Énumération des stations desservies dans la ligne choisie, ainsi que les horaires de
passage.
- Alertes sur des évènements asynchrones : arrivée d’un véhicule à l’arrêt, perturbation sur
une des lignes de l’arrêt choisi.
Si l’on peut décrire un trajet comme une succession ordonnée de ces différentes phases, la
démarche cognitive des utilisateurs réclame de pouvoir effectuer des transitions entre ces
différents états, soit pour que l’utilisateur puisse revenir sur des choix, soit dans une
préoccupation de confirmation des choix effectués. Chacune des situations énumérées ci-dessus
peut donc être considérée comme un état pour lequel l’application doit savoir fournir les
informations pertinentes.
Figure 37 Architecture logicielle de l’application basée sur la librairie AuLib
Figure 38 Architecture logicielle de l’application basée sur la gestion d’une interface graphique
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 58 sur 159
6.2.2.2 IHM à destination des personnes ayant une déficience auditive
L’IHM pour les personnes ayant une déficience auditive est constituée de cinq onglets entre les
quels l’utilisateur peut circuler à sa guise au moyen de l’écran tactile (Figure 39) :
- Onglet Connexion (Connection tab sur la Figure 38) qui permet à l’utilisateur de
découvrir les arrêts équipés du système d’information et de choisir celui auquel il
souhaite connecter.
- Onglet Info (Data tab sur la Figure 38) qui permet à l’utilisateur de découvrir les lignes
desservies à cet arrêt, d’en choisir une et de consulter la liste des arrêts avals desservis
ainsi que les horaires de passage recalés.
- Onglet Carte (Map tab sur la Figure 38) qui permet à l’utilisateur d’avoir un plan du site
avec la localisation de l’arrêt auquel il est connecté ainsi que la possibilité de localiser les
autres points arrêt du site.
- Onglet Parcours (Direction tab sur la Figure 38) qui permet à l’utilisateur d’obtenir des
indications de parcours pour effectuer des correspondances sur le site. Ces indications de
parcours sont bien sûr adaptées au type de déficience.
- Onglet Message (Urgent Message tab sur la Figure 38) qui permet à l’utilisateur de
consulter les messages asynchrones d’arrivées de véhicule ou de perturbation qu’il a reçu
depuis le début de sa connexion. Un message survenant est de plus affiché à l’aide d’une
fenêtre dynamique accompagnée d’une alerte vibratoire, avant d’être archivé dans
l’onglet Message.
Figure 39 IHM de l’application pour les personnes ayant une déficience auditive
L’existence des onglets est dynamique et dépend de l’état de l’application. Dans l’état initial où
l’application n’est connectée à aucun point d’arrêt, seul l’onglet connexion est présent. Les
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 59 sur 159
onglets Info, Carte et Parcours n’apparaissent que si l’utilisateur s’est connecté à un arrêt.
L’onglet Message quant à lui n’apparait qu’à la première occurrence de message asynchrone.
Cette structure de l’IHM permet à l’utilisateur de focaliser directement sur l’information dont il a
besoin et de modifier en conséquence le contexte d’exécution de l’application.
6.2.2.3 IHM à destination des personnes ayant une déficience visuelle
Dans le cas d’un utilisateur ayant déficience auditive, l’interaction entre l’utilisateur et
l’application au moyen d’une interface graphique est assez intuitive, car en partant d’une
catégorisation efficiente des informations (structure en onglet), elle permet à l’utilisateur de
disposer en parallèle de l’ensemble des choix possibles et circuler de l’un à l’autre à son gré en
fonction de ses préoccupations et interrogations. C’est donc l’utilisateur qui reste maître du
déroulement de l’application.
La gestion d’une interface audio se révèle beaucoup plus contraignante, car du fait de la nature
sérielle et furtive de l’ « affichage » audio, l’utilisateur ne dispose à un moment que d’une vue de
l’application. La structure de l’interface doit donc permettre à l’utilisateur de se faire une
représentation mentale des différentes vues possibles et du moyen permettant de passer d’une
vue à une autre. Le contexte de l’application ou la vue courante doit aussi être non ambigüe afin
de maintenir la synchronisation entre le processus cognitif de l’utilisateur et le contexte de
l’application.
Figure 40 Architecture de navigation de l’IHM audio
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 60 sur 159
C’est donc l’IHM qui doit proposer les transitions possibles entre les différentes vues de
l’application. La navigation dans l’IHM se trouve donc formalisée « naturellement » sous forme
d’un graphe d’état tel que représenté Figure 40. Cette figure fait apparaitre deux contextes
principaux : le contexte transport et le contexte géographique. Le premier correspond à
l’obtention des informations voyageurs, le second à celles concernant les différentes description
topographique du site.
Les transitions entre les différents états se font soit automatiquement soit sur une action
utilisateur sur une des touches du smartphone (Figure 41). La correpondance entre les actions de
la Figure 40 et l’utilisation des touches du smartphone de la Figure 41 est la suivante :
-
Action A : correspond à l’action « Select data »
-
Action C : correspond à l’action « Go back one level »
-
Action D : correspond à l’action « Change Mode »
Figure 41 Utilisation des touches du smartphone dans l’IHM Audio (Module « Key
Notification » Figure 37)
La transition entre le contexte transport et le contexte géographique peut se faire à tout moment
dans le déroulement de l’application.
Ces contraintes particulières d’une IHM audio ont conduit à développer ce que l’on pourrait
appeler une Audio User Interface (AUI) par analogie avec la notion de Graphical User Interface
(GUI). Cette interface permet de configurer dynamiquement une machine d’état dont chacun des
états consomme les messages entrants et envoi éventuellement des messages vers les modules
d’interface (Figure 42). La commutation de contexte peut facilement être réalisée, car les états
ont la propriété de pouvoir être endormi ou de devenir transparent, c'est-à-dire de relayer les
messages vers les étapes de traitement suivant sans les analyser. Les étapes de traitement ont
aussi comme fonctionnalité de pouvoir consommer le message sans le transmettre ou de le
diffuser aux étapes de traitements suivantes.
L’immense intérêt de cette approche est qu’elle permet de projeter presque immédiatement un
graphe tel que représenté Figure 40 sur l’architecture d’implémentation symbolisée Figure 42.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 61 sur 159
Figure 42 Structure d’une application utilisation l’IHM audio AuLib
6.3 Conclusion
Le traitement de deux IHM graphique et audio a permis de spécifier une architecture logicielle
répondant aux deux contraintes. La spécificité de chacune des interfaces est confinée au module
applicatif qui utilise soit un environnement d’exécution graphique, soit un environnement
d’exécution audio qui a été développé spécifiquement dans le cadre de l’exécution du projet
INFOMOVILLE.
Les couches d’abstraction matérielle, réalisées par les modules d’interface restent communes aux
deux types d’IHM, de même que l’environnement de propagation de message entre les modules
d’interface et le module applicatif.
Les propriétés de l’environnement de développement d’interface audio a aussi la propriété de
généricité que l’on recnontre pour les interface graphique et permet de manière analogue de
prototyper de manière efficace des applications basées sur ce type d’interface.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 62 sur 159
7 Localisation par WiFi ou GPS et guidage
7.1 Guidage
Le système RAMPE apportait une assistance à l’approche des points d’arrêt mais ne prenait pas
en compte la notion de correspondance et n’intégrait pas de guidage. Dans le système
INFOMOVILLE, nous avons intégré une fonctionnalité de guidage entre deux points d’arrêt
pour faciliter les correspondances. Cette fonctionnalité est avant tout destinée aux personnes
aveugles même si elle a été incluse dans les deux applications sous des formes différentes.
Le guidage est effectué par segments successifs délimités par des points d’intérêt pour les
utilisateurs et éventuellement la localisation. L’utilisateur peut progresser à sa guise dans les
instructions de guidage correspondant aux différents segments en utilisant une touche de
défilement rapide avec possibilité de retour en arrière. Les instructions de guidage sont énoncées
vocalement pour les personnes aveugles et données sous forme écrites pour les personnes
sourdes. Dans ce dernier cas, elles viennent en complément de la carte de quartier sur laquelle
figurent les positions des différents points d’arrêt.
Si une technique de localisation est activée, la connaissance plus ou moins précise de la position
de l’utilisateur peut être exploitée par l’application. Par exemple, pour l’application destinée aux
personnes sourdes, la position de la personne est affichée sur la carte en plus des points d’arrêt
de départ et de destination ; pour l’application destinée aux personnes aveugles, le premier
segment proposé est celui où se trouve la personne et l’application donne une indication chiffrée
de la distance approximative à un arrêt. L’IHM est la même que la fonction de localisation soit
activée ou non et ceci de façon transparente pour l’utilisateur [1].
7.2 Localisation de piétons équipés de smartphones par GPS ou par
cartographie WiFi
Après l’état de l’art sur les techniques de localisation [2], nous avons retenu trois technologies de
localisation utilisables sur smartphones : la localisation par GPS, la localisation par cartographie
radio WiFi et la localisation par connexion à une cellule WiFi. Ces technologies demandent que
le smartphone intègre respectivement un récepteur GPS et un circuit WiFi, ce qui est le cas de
nombreux smartphones. L’application INFOMOVILLE sur smartphone communique par WIFI
avec les bornes. La technologie WiFi peut donc être utilisée non seulement pour la
communication mais aussi pour la localisation par une technique de cartographie (on dit aussi
empreinte) radio WiFi ou par simple connexion à une cellule Wifi contrôlée par un point
d’accès.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 63 sur 159
Nous avons effectué différents tests pour les deux premières techniques de localisation dont les
performances en précision sont supérieures à la troisième. L’objectif était d’évaluer les
performances possibles en prenant en compte les contraintes imposées par un futur déploiement
en particulier en terme de coût d’installation, de maintenance et d’alimentation électrique des
équipements.
Ces contraintes sont surtout à considérer pour l’approche WiFi. En effet, la technique s’appuie
sur l’utilisation d’une infrastructure de points d’accès WiFi et une phase de calibration préalable
(dont le rôle sera rappelé plus loin). Aussi avons-nous décidé d’utiliser la même infrastructure
WiFi pour la communication avec les bornes et pour la localisation. L’ajout de point d’accès
supplémentaires permettrait de gagner en précision de localisation par la technique de
cartographie WiFi. Mais l’installation d’autres points d’accès en milieu extérieur nécessite
d’avoir accès à des sources d’alimentation électrique et conduit à des travaux et des coûts
additifs peu favorables à un futur déploiement du système. La situation est différentes à
l’intérieur des bâtiments où l’installation de points d’accès supplémentaires est plus facile.
Nous avons évalué les potentialités des deux technologies de localisation utilisées avec des
smartphones seuls (c’est-à-dire sans ajout de dispositifs externes au smartphone comme une
antenne GPS). Nous avons effectué des expérimentations en deux endroits :
• à l’ESIEE situé à Noisy Le Grand en région parisienne, où nous avons effectué des tests en
indoor et en outdoor
• et à Lyon en outdoor sur l’un des sites (autour de la station jet d’eau Mendès France) du
parcours choisi pour l’expérimentation avec les personnes à handicap sensoriel.
Différents paramètres de performance pour les techniques de localisation peuvent être analysés :
•
•
•
•
•
•
•
•
•
Disponibilité en temps et en espace (local ou global GPS).
Portée ou couverture dans le cas des systèmes locaux.
Fonctionnement en intérieur et/ou à l’extérieur.
Précision de localisation, (ex: 3 m dans 95% des cas).
Fiabilité (une alarme en cas d’erreur importante).
Vitesse de fonctionnement.
Nécessité d’installer une infrastructure spécifique.
Coût de l’infrastructure, de son installation et de sa maintenance. Coût des mobiles
Énergie : Autonomie (durée de vie des piles …) des mobiles. Consommation électrique de
l’infrastructure.
• Puissance de calcul nécessaire pour estimer la localisation.
• Système centralisé ou distribué.
• Respect de la vie privée.
Nous avons cherché à évaluer les performances en termes de précision, robustesse, rapidité,
fiabilité et en terme de capacité de fonctionnement indoor et outdoor.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 64 sur 159
Pour des applications comme INFOMOVILLE, la précision visée est de quelques mètres (si
possible moins de 3 m).
La vitesse d’actualisation de l’estimation de position doit être compatible avec la vitesse de
marche d’un piéton et éventuellement suffisamment rapide pour permettre de faire des
traitements statistiques visant à améliorer l’estimation. Une actualisation toutes les 10 s est un
minimum. La fiabilité de la technique doit être telle qu’elle permette de connaître la qualité de
l’estimation de façon à ne pas l’utiliser si sa qualité est insuffisante. Elle doit être robuste au type
de téléphone utilisé, aux conditions climatiques, au type d’environnement urbain.
7.3 Quelques rappels généraux sur les principes de la localisation et
sur la localisation par cartographie radio
Le principe des différentes technologies de localisation a été présenté dans le rapport
INFOMOVILLE sur les technologies mobilisables [2]. Nous redonnons ici très succinctement
quelques grands principes et nous rappelons le principe de la localisation par cartographie WiFi.
Les systèmes de localisation s’appuient sur différents types d’infrastructures ::
• Constellations de satellites (GPS par exemple)
• Infrastructures terrestres (par opposition aux satellites) constituées de balises de référence de
positions connues, qui peuvent :
• être dédiées à la localisation (réseau de balises Bluetooth par exemple)
• s’appuyer sur des réseaux locaux sans fil (Wifi par exemple)
• s’appuyer sur des réseaux de téléphonie cellulaires (GSM par exemple)
• Réseaux de capteurs : infrastructure ad-hoc constituée d’éléments intégrés dans des capteurs.
On peut classer les principes de localisation en trois grands groupes :
• Les méthodes géométriques (triangulation, trilatération …). mesurent des distances, et/ou des
angles. EX : GPS, EGNOS, Galileo.
• Les méthodes d’analyse et de reconnaissance de scènes ou d’empreintes (empreinte ou
cartographie radio). Avec phase de calibrage du site préalable. EX : cartographie WiFi.
• Le méthodes de proximité sans notion de distance : Une cible est localisée en fonction des
nœuds auxquels elle est connectée. Ex : localisation par cellule GSM.
Pour la localisation d’un piéton, les principales techniques envisageables sont les suivantes :
• Récepteurs GPS :
• Les récepteurs GPS actuels utilisent généralement une architecture SIRF Star III qui a
permis d’augmenter sensiblement la sensibilité par rapport à celle des récepteurs
précédents.
• Ils sont utilisables en milieu urbain, principalement en extérieur. La couverture et la
disponibilité sont très bonnes en extérieur.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 65 sur 159
• Le temps d’acquisition des satellites est de l’ordre de la trentaine de secondes. Il peut
être réduit par la technique A-GPS (Assisted GPS).
• Ils sont disponibles dans de nombreux smartphones ou PDA.
• Cartographie (empreinte) radio WiFi :
• Elle peut fonctionner en intérieur et en extérieur
• De nombreux smartphones ou PDA disposent d’un composant WiFi pour la
communication qui peut aussi être utilisé pour la localisation.
• Triangulation Bluetooth :
• Compte-tenu de la portée d’une liaison Bluetooth, cette approche s’applique surtout en
intérieur.
• Pour obtenir une bonne couverture et une bonne précision, le nombre de balises à
installer est important.
• La plupart des téléphones, samrtphones ou PDA intègrent un composant Bluetooth.
• Localisation par cellule GSM ou autre réseau de communication cellulaire :
• La méthode ne demande pas d’installation d’infrastructure spécifique et fonctionne en
indoor et en outdoor. Sa couverture et sa disponibilité sont très bonne.
• Elle est utilisable avec tout téléphone.
• La précision est assez mauvaise et dépend de la taille des cellules GSM (ou autre
réseau).
• Dans le cas du système INFOMOVILLE, nous pouvons considérer la zone couverte par
un point d’accès Wifi installé dans une borne à un point d’arrêt comme cellule WiFi et
utiliser la connexion d’un téléphone à cette cellule comme technique de localisation.
7.3.1 Rappel sur la localisation par cartographie Radio WiFi
La figure 43 illustre le principe de la localisation par cartographie WiFi.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 66 sur 159
figure 43 : Principe de la localisation par Cartographie WiFi
Cette méthode demande, avant toute localisation, d’effectuer une caractérisation du site d’intérêt
pour obtenir son empreinte radio WiFi en chaque point de l’espace. Pour cela, des mesures sont
effectuées en un nombre fini de points et un modèle plus ou moins sophistiqué permet
d’interpoler les valeurs entre les points de mesure. La phase de calibration fournit donc une carte
radio WiFi du site qui pourra ensuite être exploitée pour la localisation.
Une fois cette empreinte (ou carte radio) déterminée, il est possible de localiser un objet en
comparant son empreinte radio locale à celles du site. Le point du site ayant l’empreinte la plus
semblable à celle de l’objet est considéré comme la position de l’objet.
L’empreinte radio est représentée en chaque point de l’espace par un vecteur formé des valeurs
des puissances radios reçues (RSSI Received Signal Stregth Indicator) des différents émetteurs
radios (points d’accès WiFi) présents sur le site accompagnées des adresses MAC des points
d’accès WiFi correspondants.
La phase de calibration demande généralement de faire des mesures en un grand nombre de
points de la zone d’intérêt. La précision de la localisation dépend de la précision avec laquelle a
été mesurée l’empreinte radio, des algorithmes utilisés pour modéliser l’empreinte en dehors des
points de mesure de la phase de calibrage, de la vitesse de déplacement du mobile, de la durée
des mesures, ainsi que du nombre, de la position et de la puissance d’émission des différents
points d’accès WiFi.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 67 sur 159
Le système de la société EKAHAU utilise ce principe [3, 4, 5]. Nous l’avons intégré dans
INFOMOVILLE. Un logiciel (client) tourne sur le smatrtphone. Il mesure les RSSI et les
transmet à un serveur de localisation. Le serveur de localisation contenant la carte radio obtenue
pendant la phase de calibrage est installé sur un PC distant auquel on accède par le réseau
internet (figure 43)par une liaison 3G. Il calcule la position du mobile et la retourne au mobile.
7.4 Expérimentations de localisation effectuées dans le projet
INFOMOVILLE
7.4.1 Logiciel sur smartphone développé pour les tests de localisation
Afin de tester les performances de la localisation par GPS ou cartographie WiFi, nous avons
développé une application, appelée par la suite LocalisationMonitoring. Elle tourne sur
smartphone sous Windows mobile 6 et permet :
• de lancer des demandes de localisation ; à chaque demande deux estimation de localisation
sont effectuées une par GPS (latitude, longitude) et une par cartographie WiFi (coordonnées
X,Y sur un plan du site) ;
• et d’enregistrer dans un fichier les résultats de ces estimations accompagnés d’informations
supplémentaires telles que la date et l’heure de ces estimations ainsi qu’un indicateur de
qualité (respectivement le nombre de satellites vus pour la localisation par GPS et l’indicateur
donné par le logiciel « Ekahau poisitionning engine » pour la cartographie WiF)i.
7.4.2 Tests effectués à Lyon en outdoor sur le site de la station « jet d’eau
Mendès France)
Ces tests ont été effectués lors de la pré-expérimentation technique du projet à Lyon du 24 au 26
février 2010. L’objectif était de valider in-situ certains aspects techniques des prototypes et du
système, en particulier les performances de localisation dans l’environnement urbain réel
entourant les arrêts de transport. On souhaitait pour la localisation par WiFi évaluer les
performances sur les sites de correspondance en utilisant seulement les points d’accès installés
dans les bornes aux points d’arrêt (typiquement 3 points d’arrêt équipés à chaque
correspondance).
Les tests de localisation ont été effectués sur le site de la station Jet d’eau Mendès France.
7.4.2.1 Description du site « jet d’eau Mendès-France »
La figure 44 est une vue satellite du site issue de Google Maps. Cette vue est un peu ancienne
car on n’y voit pas les immeubles récemment construits.
Le site comprend 2 arrêts de tram (T2) face à face séparés par les voies de tram et un arrêt de bus
(53) situé de l’autre côté de l’avenue Berthelot. Un passage piéton à proximité de l’arrêt de bus
permet de traverser l’avenue et peut être utilisé pour une correspondance entre l’arrêt de bus et
l’arrêt de tram. Les dimensions du site correspondent à un rectangle de 70 mètres de long sur 35
mètres de large.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 68 sur 159
Sur la figure 44, on a mis en évidence l’arrêt du bus 53 et les 2 arrêts du tram T2 en les encadrant
par un trait plein noir. On a aussi indiqué par un trait plein noir le trajet piéton pour la
correspondance entre l’arrêt du bus 53 et le tram T2. Enfin les cercle verts (numérotés de #1 à
#3) à côté de chacun de ces points d’arrêt indiquent la position des 3 points d’accès WiFi
installés dans les bornes INFOMOVILLE (à une hauteur d’environ 2m) et utilisés pour la
communication et la loalisation.
figure 44 : Vue satellite du site « Jet d'eau Mendès-France » avec les positions des arrêts de bus
et de tram utilisés
Les photos suivantes représentent différentes vues du site « jet d’eau Mendès-France ». On peut
y apercevoir les arrêts de bus et de tram.
7.4.2.2 Localisation par cartographie WiFi
7.4.2.2.1 Équipement utilisé
Le matériel et les logiciels utilisés sont listés dans le tableau 1.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 69 sur 159
tableau 1 : équipements matériels et logiciels utilisés pour les tests de localisation à “jet d’eau
Mendès France”.
Nombre Type d’équipement Marque Modèle Équipements matériels 1 Routeur WiFi Linksys 2 Routeur WiFi Belkin P6500, 2 Smartphone HTC Touch Cruise 2 PC portable HP 6930p 1 Carte Wi‐Fi PMCI Express D Link DWA 643 Xtreme Équipements logiciels 1 Site Survey Ekahau 4.6 1 Positioning Engine Ekahau 4.6.8 1 Positioning Client Ekahau 4 On peut noter que, lors de la pré-expérimentation, nous n’avions pas encore reçu les modèles de
smartphones qui ont été utilisés pour l’expérimentation finale du système INFOMOVILLE.
Cependant, le HTC touch Cruise est très proche du smartphone qui a été utilisé pour les
personnes aveugles (HTC touch 3G). Par contre, le HTC P6500 est un peu plus ancien et est
assez différent des téléphones choisis pour l’expérimentation.
7.4.2.2.2 Couverture radio WiFi du site
Le logiciel « Ekahau Site Survey » permet de mesurer la couverture radio WiFi d’un site. La
connaissance de cette couverture est importante pour INFOMOVILLE car elle permet d’une part
de prévoir où pourraient survenir des difficultés de communication WiFi (cette communication
est nécessaire pour l’application INFOMOVILLE mais aussi pour la communication liée aux
échanges de localisation) et d’autre part d’interpréter certains résultats de mauvaise localisation.
La figure 45 illustre le niveau de puissance radio WiFi reçue en chaque point du site, plus
précisément le plus fort niveau reçu des points d’accès sélectionnés. On y repère deux lieux avec
une très bonne couverture près de chacune des bornes de tram qui son équipés de points d’accès
WiFi Belkin. On note aussi que la zone de l’arrêt de bus est moins bien couverte (point d’accès
WiFi Linksys). Cette carte de couverture est fournie par le logiciel « Ekahau Site Survey » à la
fin d’une phase de calibrage pendant laquelle on effectue des mesures en un nombre fini de
points du site, le logiciel interpolant ensuite entre ces points.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 70 sur 159
figure 45 : couverture Wifi sur le site « jet d’eau mendès-France »
7.4.2.2.3 Expérimentation
Comme expliqué précédemment, une phase de calibrage préalable du site doit être réalisée avant
de pouvoir mettre en œuvre la localisation d’un smartphone ou d’un autre objet disposant d’un
composant WiFi.
Ce calibrage est effectué à l’aide du logiciel « Ekahau site survey ». Le calibrage fournit une
carte radio qui sera ensuite utilisée par le logiciel « Ekahau Positioning Engine » pour calculer la
position sur le site d’un objet disposant d’un composant WiFi et du logiciel « Ekahau client ».
L’objet (pour nous le smartphone) doit pouvoir communiquer grâce à « Ekahau client » par un
lien wiFi avec « Ekahau Positioning Engine » à qui il envoie les paramètres mesurés et qui en
échange lui retourne une estimation de position.
La calibration du site a été effectuée de manière à couvrir les lieux où il est possible de marcher.
Un site peut être défini à l’aide de rails et/ou de zones ouvertes dans le logiciel Ekahau. Les rails
indiquent les chemins que devraient suivre l’objet (par exemple le trottoir). Les zones ouvertes
indiquent des endroits où il n’est possible de définir de chemins logiques. Dans
l’expérimentation nous avons utilisé des rails uniquement.
Quatre expérimentations ont été effectuées sur ce site à quatre moments différents de la journée
du 26 février 2010
Pour les 4 expérimentations, les mesures ont été relevées en 11 points différents. Ces points sont
représentés par des cercles numérotés sur la figure 46. Le plan de la figure 46 a été utilisé dans
les tests avec le système Ekahau, le point de référence pour les coordonnées X, Y étant situé en
haut et à gauche de la photo satellite.
Dans les trois premières expériences, nous avons fait les tests en chaque point et simultanément
avec les 2 smartphones et un ordinateur portable (voir leurs références dans le tableau 1) ; c’està-dire que nous avons relevé les estimations de position des 2 smartphones et du PC portable,
chacun de ces objets disposant du client logiciel Ekahau permettant de les localiser.
L’enregistrement des mesures a été fait automatiquement sur les 2 smartphones grâce à
l’application LocalisationMonitoring. Il a été fait à la main pour les mesures concernant la
position du PC portable. Ces trois premières expériences ont démarré respectivement à 9h30,
10h07 et 11h30.
L’expérience 4, qui a démarré à 10h30, a été effectuée avec l’outil « Site Survey tracker » du
logiciel « Ekahau Site Survey » sur les 11 points de test du site. Dans ce cas l’objet dont on
estime la position est le PC qui a servi à faire la calibration. On est donc dans une situation
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 71 sur 159
optimale, puisque les antennes et les composants WiFi sont les mêmes pour le calibrage et la
localisation. Les relevés de mesure ont été faits à la main.
Dans le cas de localisation des ordinateurs portables, on a recueilli 3 estimations en chaque
point. Et pour l’expérience 4, pour chacune des 3 mesures successives nous avons tourné de 90°
l’orientation du PC.
Par ailleurs, les expériences 1, 2 et 4 ont utilisé le même calibrage et l’expérience 3 a utilisé un
calibrage « enrichi ».
Enfin, les conditions climatiques pendant cette journée du 26 février étaient mauvaises : ciel très
couvert en particulier.
figure 46 : points de test pour l’évaluation de la précision de localisation
7.4.2.2.4 Calibration du site
La calibration a été réalisée avec le logiciel « Ekahau site Survey » installé sur un PC portable.
Pour ce faire, on a effectué des allers et retours avec le PC portable en marchant à un rythme
régulier et calme le long des chemins indiqués sur la figure 47.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 72 sur 159
figure 47 : calibration du site
La Figure 48 montre une prédiction fournie par le logiciel « Ekahau site survey » de la précision
de localisation correspondant à cette 1ère calibration.
Pour rendre les résultats plus robustes à l’orientation de l’utilisateur en point donné, c’est-à-dire
plus robuste à l’orientation de l’antenne intégrée dans le smartphone, nous avons enrichi la
calibration en effectuant en chacun des 11 points de test, des rotations de 360° sur nous-mêmes.
La Figure 49 montre les trajets de cette nouvelle calibration. La Figure 50 montre l’amélioration
de la couverture de localisation (zone où la localisation devrait être correcte) résultant de cette
calibration « enrichie ».
La 1ère calibration a été utilisée dans les expériences 1, 2, 4 et la calibration enrichie dans
l’expérience 3.
Figure 48 : qualité de la 1ère calibration
Figure 49 : calibration avec des rotations de 360° à chaque point de test
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 73 sur 159
Figure 50 : amélioration de la zone de couverture de localisation avec le calibrage enrichi (1ère
calibration à gauche, calibration enrichie à droite).
7.4.2.3 Localisation par GPS
Pendant les expérimentations de localisation par cartographie WiFi nous avons relevé les
estimations des coordonnées de chacun des 11 points de test, fournies par le récepteur GPS
intégré dans les 2 smartphones. On obtenait donc en chaque point deux estimations de
coordonnées GPS venant de 2 smartphones différents côte à côte.
7.4.2.4 Résultats des expérimentations
Les résultats fournissent une comparaison entre les coordonnées estimées par GPS, les
coordonnées estimées par la cartographie WiFi Ekahau par et les coordonnées de référence (les
coordonnées réelles). Les 11 points de référence sont indiquées par des cercles sur les figures qui
montrent les coordonnées X et Y réelles et estimées en mètres par rapport au point de référence.
7.4.2.4.1 Résultats pour la localisation par cartographie WiFi
Les résultats obtenus diffèrent selon le dispositif utilisé. Pour la localisation par cartographie
WiFi Ekahau cette influence est très importante.
Ainsi le smartphone HTC Touch Cruise donne de très mauvais résultats pour les 3
expérimentations avec Ekahau. Les figure 51,figure 52,figure 53 montrent les résultats de la
localisation du smartphone HTC Touch Cruise par cartographie WiFi Ekahau pour les
expériences 1, 2 et 3. L’antenne ou le circuit WiFi de ce smartphone sont sans doute de moins
bonne qualité que celles des autres dispositifs.
On constate que les estimations de position sont groupées en paquets autour d’un ou deux points
situés sur la gauche de la figure.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 74 sur 159
figure 51 : Résultats de localisation du HTC Touch Cruise expérience 1.
Les fFigure 54,Figure 55,Figure 56 montrent les résultats de la localisation du smartphone HTC
P6500 par cartographie WiFi Ekahau pour les expériences 1, 2 et 3. Les résultats sont un peu
meilleurs qu’avec le HTC Touch Cruise mais restent très insuffisants pour l’application
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 75 sur 159
INFOMOVILLE.
Figure 54: Résultats de localisation du HTC P6500 expérience 1.
Figure 55 : Résultats de localisation du HTC P6500 expérience 2.
Figure 56 : Résultats de localisation du HTC P6500 expérience 3.
Les figure 57,Figure 58,Figure 59,Figure 60,Figure 61,Figure 62,Figure 63 montrent les résultats
de la localisation de l’ordinateur portable par cartographie WiFi pour les expériences 1, 2 et 3.
Pour les expériences 2 et 3 elles détaillent les résultats obtenus selon 3 directions séparées de 90°
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 76 sur 159
et notées a, b et c. Les résultats sont meilleurs qu’avec les 2 smartphones sauf pour la direction b.
Ces mauvais résultats pour la direction b pourraient sans doute être améliorés par une meilleure
phase de calibration. (en faisant plus de mesures dans toutes les directions).
figure 57 : Résultats de localisation du PC expérience 1 pour les 3 directions du PC.
Figure 58 : Résultats de localisation du PC expérience 2 pour la direction a
Figure 59 : Résultats de localisation du PC expérience 2 pour la direction b
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 77 sur 159
Figure 60 : Résultats de localisation du PC expérience 2 pour la direction c
Figure 61 : Résultats de localisation du PC expérience 3 pour la direction a
Figure 62 : Résultats de localisation du PC expérience 3 pour la direction b.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 78 sur 159
Figure 63 : Résultats de localisation du PC expérience 3 pour la direction c.
La figure 64 montre les résultats de la localisation par cartographie WiFi Ekahau de l’ordinateur
portable utilisé pour la calibration pour l’expérience 4. Cette localisation est obtenue avec l’outil
« tracker » du logiciel « Ekahau Site Survey ». Cette expérience correspond aux conditions de
localisation optimales puisque le PC qu’on localise est celui qui a servi à la calibration. Il a donc
le même circuit WiFi et la même antenne. Les résultats sont effectivement meilleurs et donnent
une idée de ce qu’on peut espérer au mieux avec cette technique en utilisant seulement 3 points
d’accès WiFi sur un site comme celui de jet d’eau Mendès–France dont les dimensions sont
d’environ 70 m sur 35 m. On peut constater que la plupart des erreurs sont inférieures à 5 m.
mais quelques unes peuvent aller jusqu’à 20 m. En particulier, le PC peut-être localisé du
mauvais côté de la voie de tram ou de la route (voir la figure 64).
Dans un but de comparaison nous avons montré la photo google maps satellite à côté de la figure
de coordonnées x,y.
figure 64 : Localisation par du PC utilisé pour la calibration (mode tracker de Ekahau Site
Survey). Expérience 4.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 79 sur 159
7.4.2.4.2 Résultats des tests de localisation par GPS
Les PC portables ne comportant pas de récepteurs GPS, nous n’avons fait les tests de localisation
par GPS que pour les 2smartphones.
Les fFigure 65,Figure 66,Figure 67 donnent les résultats pour les 3 expériences faites avec le
HTC Touch Cruise. Les Figure 68,Figure 69,Figure 70 donnent les résultats pour les 3
expériences faites avec le HTC P6500.
.Les résultats diffèrent un peu selon le smartphone et sont un peu meilleurs pour le HTC Touch
Cruise que pour le HTC P6500.
Figure 65 : Résultats de localisation du HTC Touch Cruise par GPS. Expérience 1.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 80 sur 159
Figure 68 : Résultats de localisation du HTC P6500 par GPS. Expérience 1.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 81 sur 159
Sur la Figure 71 nous affichons l’ensemble des résultats de localisation par GPS et par
cartographie WiFi Ekahau pour l’expérience 1.
Figure 71 : Localisation par GPS et cartographie WiFi Ekahau du HTC P6500. Expérience 1.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 82 sur 159
7.4.3 Tests effectués à l’ESIEE en indoor et en outdoor
La mauvaise qualité des résultats obtenus sur le site Jet d’eau Mendès France pour les 2
smartphones nous ont surpris par rapport à ceux que nous avions obtenus en indoor à l’ESIEE
avec un PDA HP iPAQ. Nous avons donc décidé de refaire une série d’expérience à l’ESIEE en
indoor et en outdoor.
7.4.3.1 Expérimentation en outdoor à l’ESIEE avec la cartographie WiFi Ekahau
Nous avons faits les expérimentations en outdoor à côté du gymnase de l’ESIEE. Nous avons
installés des points d’accès WiFi alimentés sur batterie et nous avons testé l’influence de la
hauteur des points d’accès. Pour cela nous avons comparé les résultats lorsque les points d’accès
sont posés par terre et quand ils sont posés sur des escabeaux de 2 mètres de haut. Nous n’avons
pas observé de différence significative entre les 2 positions.
La figure 72 montre le site où on été effectués les tests en outdoor.
figure 72 : site de l’expérimentation outdoor devant le gymnase de l’ESIEE.
Les photos suivantes montrent les 2 types d’installation des points d’accès (sur escabeaux ou au
sol).
Nous avons effectué des tests avec 3 et 5 points d’accès. Les photos montrent la position des
points d’accès dans les 2 cas (les cercles verts).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 83 sur 159
La figure 73 montre les chemins suivis pour le calibrage du site ainsi que l’estimation de la
couverture WiFi effectuée par Ekahau. On aperçoit la position de 5 points d’accès WiFi (les
cercles verts les plus grands).
figure 73 : Calibrage et couverture WiFi du site outdoor de l’ESIEE
À la fin du calibrage avec 5 points d’accès, la précision moyenne de localisation en mode tracker
(avec le PC ayant servi à la localisation) est de 2,78m et elle est meilleure que 4,9 m dans 90%
des cas.
La localisation a été réalisée en définissant des rails et les estimations de positions ont été
effectuées sur des points de mesure (références sur les figures) situés sur ces rails. Les mesures
ont été effectuées en 7 points différents. La figure 74 montre ces points de mesure et un point de
référence en bas à gauche du plan.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 84 sur 159
figure 74 : positions des 7 points utilisés pour les mesure+ point de référence en bas à gauche
La figure 75 montre la qualité du calibrage sur cette zone.
figure 75 : Qualité de la calibration sur la zone de localisation
Les résultats obtenus avec le HTC P6500 sont peu précis et confirment ceux obtenus à Lyon.
La précision moyenne passe de 10,8 m avec 3 points d’accès à 9 m avec 5 points d’accès. Pour
illustrer les résultats on donne dans la figure 76 les positions des points de mesure et des
estimations ainsi qu’un histogramme des précisions de localisation et ceci dans le cas de 3 points
d’accès (schémas du haut et de 5 points d’accès (schéma du bas)).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 85 sur 159
figure 76 : comparaison des résultats en outdoor avec 3 (en haut) ou 5 (en bas) points d’accès
avec la 1er calibration.
Nous avons refait les tests avec un PDA HP iPAQ. La précision de localisation du PDA HP
iPAQ est bien meilleure que celle obtenue avec le smartphone HTC P6500. La précision
moyenne de localisation du PDA HP iPAQ en outdoor est de 3,6 m au lieu de 9 m pour le HTC
P6500. La figure 77 illustre cette comparaison avec une calibration un peu améliorée par rapport
à la précédente.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 86 sur 159
figure 77 : Comparaison des résultats obtenus en outdoor avec le HTC P6500 (en haut) et le HP
iPAQ (en bas) avec la calibration améliorée.
7.4.3.2 Expérimentation en indoor à l’ESIEE avec la cartographie WiFi Ekahau
La figure 78 montre le site (3ème étage du bâtiment 2) où se sont effectués les tests en indoor.
Nous avons effectué des tests avec 5 points d’accès. La figure montre les chemins suivis pour le
calibrage du site (aller et retour) ainsi que l’estimation de la couverture WiFi effectuée par
Ekahau. On aperçoit la position de 5 points d’accès WiFi (les cercles verts les plus grands).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 87 sur 159
figure 78 : Calibrage et couverture WiFi du site indoor de l’ESIEE
Nous avons réalisé les tests avec un PDA HP IPaQ et avec le smartphone HTC P65000.
Les résultats sont très supérieurs avec le HP iPAQ. La précision moyenne de localisation est de
1,9 m avec le HP iPAQ alors qu’elle est de 5,9 m pour le HTC P6500. La figure 79 illustre ces
résultats.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 88 sur 159
figure 79 : histogramme des précisions avec le smartphone HTC P6500 et le PDA HP iPAQ.
La Figure 80 montre la position des estimations et des points de référence superposés sur le plan
de l’étage.
Figure 80 : Localisation ekahau ESIEE avec smartphone P6500 à gauche et PDA iPAQ à droite
7.4.3.3 Expérimentation en outdoor à l’ESIEE de localisation par GPS
Nous avons testé la localisation par GPS en outdoor sur le même site de l’ESIEE pour le HTC
P6500 et le HTC Touch 3G (qui a été utilisé pendant l’expérimentation à Lyon avec les
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 89 sur 159
personnes aveugles), le PDA HP iPAQ n’ayant pas de récepteur GPS il n’a pas été utilisé pour
ces tests. Nous avons fait plusieurs séries de mesures différents jours.
Ces mesures ont été effectuées sur deux jeux de points : celui comprenant 7 points de mesure
utilisé pour les tests du système ekahau et un second jeu formé de 12 points de mesure. La figure
81 illustre ces points de mesure auxquels s’ajoute à chaque fois un point de référence situé en
bas à gauche de la figure. Ce point de référence est le points de coordonnées X,Y nulles.
figure 81 : points de mesure utilisés pour les tests GPS
La figure 82 et la figure 83 illustrent les résultats obtenus en donnant les coordonnées X, Y
ainsi que les histogrammes de précision pour le smartphone HTC P6500 sur les 2 séries de points
de mesure. La figure 84 illustre les résultats obtenus pour le smartphone HTC Touch 3G. Les
points bleus représentés par une croix sont les points de référence (contrôle) et les points rouges
sont les estimations de localisation de ces points par GPS. Les précisions moyennes obtenues
varient un peu d’un jour à l’autre et selon le point de référence entre 6 m et 8 m.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 90 sur 159
figure 82 : Résultats de localisation par GPS, coordonnées X-Y et histogrammes des précisions
pour le HTC P6500 pour l’ensemble de 12 points de mesure.
pour le HTC P6500 pour l’ensemble de 7 points de mesure.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 91 sur 159
pour le HTC Touch 3G.
7.4.3.4 Résumé des mesures effectuées à l’ESIEE
Le tableau 2 résume les résultats obtenus à l’ESIEE en outdoor.
tableau 2 : résumé des résultats obtenus à l’ESIEE en outdoor pour la localisation par
cartographie WiFi Ekahau.
tableau 3 : résumé des résultats obtenus à l’ESIEE en outdoor pour la localisation par GPS.
7.4.4 Principaux résultats sur la localisation
On peut résumer les principaux résultats de la manière suivante.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 92 sur 159
7.4.4.1 La localisation par GPS :
• Le récepteur GPS ne fonctionne correctement qu’à l’extérieur des bâtiments.
• Le temps d’acquisition (des satellites) est parfois long au démarrage
• Sur le site de la station « Jet d’eau Mendès France » à Lyon, la précision est la plupart du
temps meilleure que 10m. Elle est en moyenne de l’ordre de 7 m avec les 2 smartphones HTC
P6500 et HTC Touch Cruise. Sur le site de l’ESIEE elle a été en moyenne de 6 m pour le
smartphone HTC Touch 3G et de 7,5 m pour le HTC P6500.
• La précision varie peu au cours du temps pour des conditions données, mais elle varie
légèrement selon la météo.
• La précision dépend légèrement du type de téléphone utilisé même avec des téléphones de la
même marque.
7.4.4.2 La localisation par cartographie radio WiFi
• La technique fonctionne en indoor et en outdoor. Elle donne des résultats plus précis en
indoor.
• Les stratégies de calibration et de localisation influencent significativement les résultats. Le
nombre de points d’accès joue sur la précision.
• Le rafraichissement des estimations de position transmises par le serveur est assez lent :
toutes les 10 s (lent).
• En outdoor, la précision fluctue au cours du temps pour un point donné et varie selon la
position considérée et le type de dispositif localisé.
• Sur le dite « Jet d’eau Mendès France » à Lyon, avec 3 points d’accès WiFi seulement
installés aux points d’arrêt du site, la précision variait de 2m à plus de 20m selon la
position considérée. Elle était légèrement meilleure avec le HTC P6500 en comparaison
avec le HTC Touch Cruise.
• Sur le site à l’ESIEE, les résultats obtenus avec le PDA HP iPAQ sont très supérieurs à
ceux obtenus avec le HTC P6500 ou le HTC Touch 3G. La précision moyenne en
outdoor pour le premier est de 3,6m au lieu de 9 ou 10 m pour les 2 autres.
• En indoor à l’ESIEE, on retrouve la dépendance des résultats au type de dispositif à localiser.
Elle est de 1,9 m pour le HP iPAQ et de 5,9 m pour le HTC P6500.
En conclusion, les résultats de localisation obtenus par GPS ou par cartographie WiFi Ekahau ne
nous ont pas semblé suffisants pour les intégrer dans l’expérimentation avec les personnes à
déficience sensorielle. Le seul type de localisation que nous avons utilisé est celui décrit cidessous de la localisation par connexion à un point d’accès WiFi.
7.4.4.3 La localisation par simple connexion à un point d’accès WiFi :
Une autre technique de localisation WiFi possible est celle qui consiste à exploiter la connexion
d’un mobile à une borne. La détection d’un point d’arrêt (réception de la balise SSID) permet
une localisation de zone efficace et rapide mais peu précise (quelques dizaine de mètres). Cette
technique a été la seule utilisée lors des tests avec les personnes à déficience sensorielle.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 93 sur 159
7.5 Bibliographie pour la section
[1] M.-F. Dessaigne, Projet INFOMOVILLE. Rapport sur l’organisation de l’expérimentation INFOMOVILLE sur
site réel du Sytral / Lyon, mars 2010.
[2] [4] G. Baudoin, O. Venard, P. Jardin, G. Uzan, J. Dupire, Projet INFOMOVILLE, SP1 Rapport N°4 - les
technologies mobilisables.
[3] Site de la société Ekahau : www.ekahau.com.
[4] [9] P. Kontkanen, P. Myllymäki, T. Roos, H. Tirri, K. Valtonen, H. Wettig, Topics in Probabilistic Location
Estimation in Wireless Networks. Invited paper in Proceedings of the 15th IEEE Symposium on Personal,
Indoor and Mobile Radio Communications, Barcelona, Spain. IEEE Press, 2004.
[5] [23] T.Roos, P.Myllymäki, H.Tirri, P.Misikangas, J.Sievänen, A Probabilistic Approach to WLAN User
Location Estimation. International Journal of Wireless Information Networks, Vol. 9, No. 3, July 2002.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 94 sur 159
8 Annexe B1 : détail des échanges avec le Smartphone
8.1 Déclenchement du carillon
Le client mobile, émet une demande General Message en filtrant l’InfoChannel « Carillon ».
Le système de carillon consiste à émettre un son audible à moyenne distance et à l’allumage d’une LED
puissante permettant à la fois aux mal-voyants et aux mal-entendants de localiser l’arrêt sélectionné sur le
mobile. La durée de l’activation est paramétrable dans un fichier de propriété.
Requête SIRI d’activation du Carillon
Réponse SIRI validant l’activation du
Boitier
Infomoville
Requête :
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<GetGeneralMessage xmlns="http://wsdl.siri.org.uk" xmlns:siri="http://www.siri.org.uk/">
<ServiceRequestInfo
xmlns="">
<siri:RequestTimestamp>2008-06-30T16:05:40.131+02:00</siri:RequestTimestamp>
<siri:MessageIdentifier>GMClient:Test</siri:MessageIdentifier>
</ServiceRequestInfo>
<Request
xmlns="">
<siri:InfoChannelRef>Carillon</siri:InfoChannelRef>
</Request>
</GetGeneralMessage>
</soapenv:Body>
</soapenv:Envelope>
Réponse :
<soapenv:Body>
wsdl:GetGeneralMessageResponse
xmlns:wsdl="http://wsdl.siri.org.uk"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<ServiceDeliveryInfo>
<siri:ResponseTimestamp
xmlns:siri="http://www.siri.org.uk/siri">2010-0305T09:52:46.069+01:00</siri:ResponseTimestamp>
<siri:ProducerRef xmlns:siri="http://www.siri.org.uk/siri">TITAN</siri:ProducerRef>
<siri:ResponseMessageIdentifier
xmlns:siri="http://www.siri.org.uk/siri">1267779166054</siri:ResponseMessageIdentifier>
<siri:RequestMessageRef
xmlns:siri="http://www.siri.org.uk/siri">
GMClient:Test
</siri:RequestMessageRef>
</ServiceDeliveryInfo>
<Answer>
<siri:GeneralMessageDelivery version="1.3" xmlns:siri="http://www.siri.org.uk/siri">
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 95 sur 159
<siri:ResponseTimestamp>2010-03-05T09:52:45.757+01:00</siri:ResponseTimestamp>
<siri:Status>true</siri:Status>
<siri:GeneralMessage formatRef="STIF-IDF">
<siri:RecordedAtTime>2010-03-05T09:52:45.882+01:00</siri:RecordedAtTime>
<siri:ItemIdentifier> GMClient:Test </siri:ItemIdentifier>
<siri:InfoMessageIdentifier>0</siri:InfoMessageIdentifier>
<siri:InfoChannelRef>Carillon</siri:InfoChannelRef>
<siri:Content
xsi:type="siri:IDFGeneralMessageStructure"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<siri:Message>
<siri:MessageType>longMessage</siri:MessageType>
<siri:MessageText>Le carillon est actif</siri:MessageText>
</siri:Message>
</siri:Content>
</siri:GeneralMessage>
</siri:GeneralMessageDelivery>
</Answer>
<AnswerExtension/>
</wsdl:GetGeneralMessageResponse>
</soapenv:Body>
</soapenv:Envelope>
La réponse a pour seule vocation de réaliser un échange SOAP complet.
8.2 Véhicule à l’approche
Dès l’approche d’un véhicule en station, le message binaire propriétaire « bus à l’approche » est diffusé,
pour la ligne desservie en mode broadcast sur le protocole UDP. Chacun des mobiles du réseau local en
écoute du même port, en sont ainsi alertés.
Type de données
Taille
(en octets)
Contenu
Début du bloc
1
STX (Code hexa 0x02)
Longueur du bloc en ascii
(type + date + heure + adresse + données +
check-sum)
4
0019 à 9999
Type de bloc
1
V
Date et heure courante
12
JJMMAAHHMMSS
Adresse du PDA
3
996
Données du bloc
N
Check-sum sur 8 bits en ascii (xor car / car
sur longueur + type + date + heure +
adresse + données)
3
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
Concaténation du nom de la
ligne sur 8 caractères et de la
destination sur 32 caractères
000 à 255 sur 20 + N caractères
(Si la check-sum est remplie de
blancs alors le PDA considère
qu’on travaille sans check-sum)
PAGE
Page 96 sur 159
Fin du bloc
1
Total
CR (Code hexa 0x0D)
25+N
Exemple : Bus à l’approche pour la ligne 034 en direction de CHARPENNES le 05/03/2007 à 10h26 et
36 secondes (Les caractères « < » et « > » sont mis pour la compréhension de l’exemple ; ils ne font pas
partis de la trame et en doivent pas être envoyés).
La ligne est sur 8 caractères en 2x4 et la destination est sur 32 caractères en 2x16
<0x02><0037><V><050307102636><996><034 + 5 espaces><CHARPENNES><108><0x0D>
8.3 Demande du plan de quartier
Le client mobile, émet une demande GeneralMessage en filtrant l’infoChannel « Plan ».
L’option de gestion du plan est utilisée pour permettre à l’utilisateur du téléphone de récupérer différentes
informations de géolocalisation sur le site où se situe la borne.
Requête
SIRI
de
demande
d’informations de géolocalisation de
Réponse SIRI contenant la structure
XML de description du site de la borne.
Boitier
Infomoville
Requête :
<soapenv:Body>
<ServiceRequestInfo
xmlns="">
<Request
xmlns="">
<siri:InfoChannelRef>Plan</siri:InfoChannelRef>
</Request>
</soapenv:Body>
</soapenv:Envelope>
Réponse :
La structure du message retourné par le serveur Infomoville pour l’infochannel « Plan » est le contenu du
fichier xml dans lequel une description de la position géographique de la borne est décrite.
<soapenv:Body>
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 97 sur 159
<wsdl:GetGeneralMessageResponse
<siri:ProducerRef xmlns:siri="http://www.siri.org.uk/siri">TITAN</siri:ProducerRef>
xmlns:siri="http://www.siri.org.uk/siri">GeneralMessageClient:ESIEE:0</siri:RequestMessage
Ref>
<Answer>
<siri:ItemIdentifier>GeneralMessageClient:ESIEE:0</siri:ItemIdentifier>
<siri:InfoChannelRef>Plan</siri:InfoChannelRef>
<siri:Content
<siri:Message>
<siri:MessageText><![CDATA[<?xml version="1.0" encoding="utf-8"?>

<plan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="./plan.xsd">
<url>http://BIVip/plan.jpeg</url>
<ref>
<gps>
<long>8154,99491</long>
<lat>-4825,56509</lat>
</gps>
<scale>string</scale>
</ref>
<arrets>
<arret>
<numLigne>string</numLigne>
<direction>string</direction>
<gps>
<long>6040,27491</long>
<lat>6040,27491</lat>
</gps>
<parcours>
<etape>string</etape>
</parcours>
</arret>
<arret>
<numLigne>string</numLigne>
<direction>string</direction>
<gps>
<long>6040,27491</long>
<lat>6040,27491</lat>
</gps>
<parcours>
</parcours>
</arret>
</arrets>
</plan>]]></siri:MessageText>
</siri:Message>
</siri:Content>
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 98 sur 159
</Answer>
<AnswerExtension/>
</soapenv:Body>
</soapenv:Envelope>
Le mobile peut alors accéder au plan de quartier via l’url précisée dans le contenu de la réponse.
8.4 Demande d’identifiant d’arrêt d’une borne
Le client mobile, émet une demande GeneralMessage en filtrant l’infoChannel « Identifiant ».
Cette fonction permet à l’application mobile de récupérer l’identifiant SIRI de l’arrêt de la borne
correspondant au réseau WIFI sur lequel elle vient de se connecter. Cet identifiant est utilisé ensuite pour
construire les requêtes SIRI de récupération des heures de passages pour l’arrêt.
Requête
SIRI
de
d’identifiant de la borne
demande
Réponse SIRI contenant l’identifiant de
l’arrêt de la borne
Boitier
Infomoville
Requête :
<soapenv:Body>
<ServiceRequestInfo
xmlns="">
<Request
xmlns="">
<siri:InfoChannelRef>Identifiant</siri:InfoChannelRef>
</Request>
</soapenv:Body>
</soapenv:Envelope>
Réponse:
<soapenv:Body>
<wsdl:GetGeneralMessageResponse
<siri:ProducerRef xmlns:siri="http://www.siri.org.uk/siri">KILINE</siri:ProducerRef>
xmlns:siri="http://www.siri.org.uk/siri">GeneralMessageClient:ESIEE:0</siri:RequestMessage
Ref>
<Answer>
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 99 sur 159
<siri:ItemIdentifier>GeneralMessageClient:ESIEE:0</siri:ItemIdentifier>
<siri:InfoChannelRef>Identifiant</siri:InfoChannelRef>
<siri:Content
<siri:Message>
<siri:MessageText> TITAN:StopPoint:SP:512:LOC</siri:MessageText>
</siri:Message>
</siri:Content>
</Answer>
<AnswerExtension/>
</soapenv:Body>
</soapenv:Envelope>
8.5 Demande de vérification du status du système:
Requête :
<soapenv:Body>
<CheckStatus xmlns="http://wsdl.siri.org.uk" xmlns:siri="http://www.siri.org.uk/siri">
<Request xmlns="">
<siri:RequestorRef>ESIEE</siri:RequestorRef>
<siri:MessageIdentifier>CheckStatus:ESIEE:0</siri:MessageIdentifier>
</Request>
<RequestExtension xmlns=""/>
</CheckStatus>
</soapenv:Body>
</soapenv:Envelope>
Réponse :
Le status du serveur Infomoville prend en compte l’état de la connexion avec le serveur SYTRAL mais
aussi avec le soft borne.
Si tout est opérationnel :
<soapenv:Body>
<wsdl:CheckStatusResponse
<CheckStatusAnswerInfo>
xmlns:siri="http://www.siri.org.uk/siri">CheckStatus:ESIEE:0</siri:RequestMessageRef>
</CheckStatusAnswerInfo>
<Answer>
<siri:Status xmlns:siri="http://www.siri.org.uk/siri">true</siri:Status>
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 100 sur 159
</Answer>
<AnswerExtension/>
</wsdl:CheckStatusResponse>
</soapenv:Body>
</soapenv:Envelope>
Si un problème a été détecté :
<soapenv:Body>
<wsdl:CheckStatusResponse
<CheckStatusAnswerInfo>
xmlns:siri="http://www.siri.org.uk/siri">CheckStatus:ESIEE:0</siri:RequestMessageRef>
</CheckStatusAnswerInfo>
<Answer>
<siri:Status xmlns:siri="http://www.siri.org.uk/siri">false</siri:Status>
<siri:ErrorCondition xmlns:siri="http://www.siri.org.uk/siri">
<siri:OtherError>
<siri:ErrorText>Erreur de communication avec la borne</siri:ErrorText>
</siri:OtherError>
</siri:ErrorCondition>
</Answer>
<AnswerExtension/>
</wsdl:CheckStatusResponse>
</soapenv:Body>
</soapenv:Envelope>
La balise “ErrorText” indiquera la partie du système ayant rencontré un problème. (Dans cet exemple, la
communication entre la borne et le serveur Infomoville).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 101 sur 159
9 Annexe B2 : les services SIRI (version 1.0) – Profil
Ile-de-France
Seuls les services listés dans les sous paragraphes suivants seront implémentés. Le mode requête est
privilégié.
Le détail des services SIRI est celui du profile Ile De France.
9.1 Codification des identifiants
Les échanges SIRI avec le serveur e-dylic du SYTRAL imposent de partager un minimum d’informations
‘théoriques’ comme les identifiants des poteaux d’arrêt.
Dans le cadre du projet Infomoville, l’identifiant d’arrêt sera paramétrer dans la borne pour permettre cet
échange temps réel.
[Fournisseur]:[type d'objet]:[typeObjetDétaillé]:[identifiantTechnique ]:LOC
9.2 Requête d'information
StopMonitoringRequest
temps
réel
au
point
d'arrêt :
Ce service permet d’accéder aux informations temps réel sur les heures de passage.
Note : la notion de «niveau de détail », (Detail Level) proposée pour ce service par SIRI n'est pas retenue
pour le profil SIRI en Ile de France.
Requête pour obtenir des informations temps réel sur les heures d'arrivée et de départ à un point d'arrêt.
StopMonitoringRequest
+Structure
Requête permettant d’obtenir les informations
temps réel sur les heures d'arrivée et de départ
à un point d'arrêt
Attributes
Version
1:1
VersionString
Version
Endpoint
Properties
RequestTimestamp
1:1
xsd:dateTime
Date d'émission de la requête
MessageIdentifier
0:1
MessageQualifier
Numéro d'identification du message
PreviewInterval
0:1
PositiveDurationType
Si ce paramètre est présent, il indique que l'on
souhaite recevoir des informations sur tout
départ intervenant dans la durée indiquée
(comptée à partir de l'heure indiquée par le
paramètre suivant: StartTime. Si le paramètre
StartTime n'est pas présent, l'heure courante
sera utilisée).
Topic
1:1
Attention aux terminus où seules les heures
d'arrivée sont significatives: voir la note sur le
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 102 sur 159
filtre StopVisitTypes.
StartTime
0:1
xsd:dateTime
Heure à partir de laquelle doit être compté le
PreviewInterval
MonitoringRef
1:1
Monitoring¬Code
Identifiant du point d'arrêt concerné par la
requête
LineRef
0:1
LineCode
DestinationRef
0:1
StopPointCode
Filtre permettant de n'obtenir que les départs et
arrivées pour une ligne donnée (dont on fournit
l'identifiant)
arrivées ayant une destination donnée
OperatorRef
0:1
OperatorCode
arrivée pour un exploitant donné (dont on
fournit l'identifiant)
Filtre particulièrement utile pour les pôles
d'échange
StopVisitTypes
0:1
all | departures |
arrivals
Indique si l'on souhaite avoir les départs, les
arrivées ou les deux.
Seule la valeur « departures » est obligatoire
(pour tous les arrêts sauf, naturellement, le
dernier du trajet) pour le profil IDF, les autres
sont optionnelles (à préciser pour chaque
implémentation).
Si le champ n’est pas renseigné, la valeur par
défaut est « departures ».
Il faut noter que, pour la gestion des
correspondances, l’heure d’arrivée sera
particulièrement utile …
Si la valeur du filtre est 'arrivals' alors les dates
de début et intervalle de temps seront
basculées sur les heures d'arrivée et non de
départ. Ceci permet entre autre de récupérer
les informations au terminus d’arrivée.
MaximumStopVisits
0:1
xsd:positiveInteger
Nombre maximal d'information de départ ou
d'arrivée que l'on souhaite recevoir. Si aucune
valeur n’est fournie, toutes les informations
disponibles seront remontées.
De plus « 0 » est une valeur interdite pour ce
champ (erreur).
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 103 sur 159
MinimumStopVisitsPerLine
0:1
xsd:positiveInteger
Ce paramètre permet de demander un nombre
de réponses par ligne passant à l'arrêt. Cela
permet d'éviter que pour un arrêt où passent 2
lignes et pour lesquels on a demandé les
quatre prochains passages on a bien quatre
indications mais sur une seule des deux lignes
(les passages sur la seconde ligne intervenant
après).
Dans ce cas, si ce paramètre est fixé à 2 on
obtiendra les deux prochains passages sur
chacune des lignes. Ce paramètre doit donc
être compris comme un nombre souhaité de
passage par ligne et non comme un strict
minimum.
Ce paramètre comme seul filtre donnera donc
strictement le nombre de passages souhaité
(dans la limite des passages disponibles).
Ces passages doivent toutefois rester dans le
PreviewInterval lorsqu'il est combiné avec ce
filtre.
MaximumNumberOfCalls
0:1
+Structure
Structure permettant de préciser si l'on
souhaite obtenir des indications pour les arrêts
suivants.
Onwards
0:1
xsd:positiveInteger
Nombre d'arrêts suivants souhaités. Si le
paramètre est présent et vaut 0, tous les arrêts
seront retournés. Si il n’est pas fourni, seul
l’arrêt demandé sera renseigné.
9.2.1 Résultat de la requête d'information temps réel au point d'arrêt
+Structure
ServiceDelivery
HEADER
:::
1:1
voir
SIRI
Part
ServiceDelivery
2-7.2.1
Voir ServiceDelivery
9.2.1.1 Attributs temps réel du point d'arrêt
StopMonitoringDelivery
+Structure
Contenu d’une réponse pour le service
StopMonitoring
Attributes
version
1:1
VersionString
Numéro de Version du service
Monitoring (valeur paramétrée).
HEADER
:::
:::
xxxServiceDelivery
Voir
SIRI
xxxServiceDelivery.
Payload
Monitored-
0:*
+Structure
Description des passages à l'arrêt
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
Part
Stop
2-7.2.1.1
PAGE
Page 104 sur 159
StopVisit
Note : Il n'y a pas d'ordre de classement
imposé par SIRI dans la liste des passages
(l'ordre retenu sera celui des numéros
d’ordre des points sur trajets).
0:*
MonitoredStopVisitCancellation
+Structure
Indication d'annulation
précédemment signalé
d'un
passage
(Utile uniquement pour les abonnements)
9.2.1.2 Description d'un arrêt (ou point d'arrêt indiqué) sur une course
MonitoredStopVisit
+Structure
Description du passage d'un véhicule à
un arrêt (dans le cadre d'une course)
Log
RecordedAtTime
1:1
xsd:dateTime
Heure à laquelle la donnée a été mise à
jour
Identity
ItemIdentifier
0:1
ItemIdentifier
Identifie
cette
information:
cela
correspond en fait à une identification du
couple arrêt-course, et permettra par la
suite une éventuelle annulation (cas où
l’arrêt n’est plus desservi).
MonitoringCode
Référence du point d'arrêt
MonitoredVehicleJourneyStructure
Description de la course
1:1
StopVisitReference
MonitoringRef
1:1
JourneyInfo
a MonitoredVehicleJourney
1:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 105 sur 159
9.2.1.3 Attributs temps réel de la course
MonitoredVehicleJourney
Vehicle
Journey
Identity
LineRef
0:1
+Structure
LineCode
Identifiant de la ligne
1:1
FramedVehicle
JourneyRef
0:1
+FramedVehicleJourneyRefStructure
Identification de la course
JourneyPatternInfo
:::
0:1
JourneyPatternInfoGroup
Voir JourneyPatternInfoGroup.
VehicleJourneyInfo
:::
0:1
VehicleJourneyInfoGroup
Voir VehicleJourneyInfoGroup
DisruptionGroup
:::
0:1
DisruptionGroup
Voir DisruptionGroup.
JourneyProgressInfo
:::
0:1
JourneyProgressInfoGroup
Voir JourneyProgressGroup.
Calling
Pattern
MonitoredCall
0:1
+Structure
Informations
considéré
OnwardCalls
0:1
+Structure
Informations horaires concernant les arrêts
suivants
OnwardCall
0:*
+Structure
Informations horaires pour l'un des arrêts
suivants
horaires
concernant
l'arrêt
9.2.1.4 L'arrêt
MonitoredCall
Stop
Identity
+Structure
Informations horaires pour l'arrêt.
StopPointRef
0:1
StopPointCode
Identifiant du Point d'arrêt (cet identifiant est à
rapprocher de l’attribut MonitoringRef de la
structure MonitoredStopVisit, mais restreint à ce
cas de point d’arrêt là ou le MonitoringRef peut
aussi, dans le contexte général de SIRI, mais
pas celui du profil Francilien, référencer un
afficheur, par exemple).
Order
0:1
xsd:positiveInte
ger
Numéro d'ordre de l'arrêt sur le trajet
StopPointName
0:1
NLString
Nom du point d'arrêt.
1:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 106 sur 159
Call
Real-time
0:1
VehicleAtStop
xsd:boolean
La Valeur «true » indique que le véhicule est à
l'arrêt
Valeur par défaut : « false »
Call Rail
0:1
PlatformTraversal
xsd:boolean
La valeur « true » permet de signaler le passage
d'un train sans arrêt (et de demander au
voyageur de s'écarter des voies)
Call
Property
DestinationDisplay
0:1
NLString
Destination telle
qu'elle est affichée
sur la girouette du
véhicule à cet arrêt
(ou sur l’afficheur
local).
DisruptionGroup
:::
0:1
DisruptionGroup
Perturbations
Arrival
AimedArrivalTime
0:1
xsd:dateTime
Heure d'arrivée théorique
Ce champ correspond à
l’information de
destination sur la borne.
(un nouveau service provisoire utilise la donnée
d'heure estimée)
Departure
ActualArrivalTime
0:1
xsd:dateTime
Heure d'arrivée effectivement mesurée.
ExpectedArrivalTime
0:1
xsd:dateTime
Heure d'arrivée estimée par les systèmes
fournisseurs
ArrivalStatus
0:1
onTime | early
delayed
cancelled
arrived
noReport
|
|
|
|
Caractérisation de l'horaire d'arrivée attendu (ou
mesuré si le véhicule est à quai)
Valeur par défaut : « onTime »
ArrivalPlatformName
0:1
NLString
Identification ou nom du quai d'arrivée
AimedDepartureTime
1:1
xsd:dateTime
Heure de départ théorique
ActualDepartureTime
0:1
xsd:dateTime
Heure de départ effectivement mesurée.
ExpectedDepartureTime
1:1
xsd:dateTime
Heure de départ estimée par les systèmes
fournisseurs
DepartureStatus
0:1
onTime | early
delayed
cancelled
arrived
noReport
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
|
|
|
|
Caractérisation de l'horaire de départ attendu
(ou mesuré si le véhicule est à quai)
PAGE
Page 107 sur 159
DeparturePlatformName
0:1
NLString
DepartureBoardingActivity
0:1
boarding
noBoarding
passthru
Identification ou nom du quai de départ
|
|
Indique si l'on peut monter dans le véhicule ou si
c'est un passage sans arrêt ou avec montée
interdite
Valeur par défaut : « boarding»
L’indicateur n’est pas
systèmes fournisseurs.
Boarding
qualifiable
AimedHeadwayFrequency
0:1
Fréquence
de
commandée)
ExpectedHeadwayInterval
0:1
Fréquence de passage
systèmes fournisseurs
passage
par
théorique
estimée
par
9.2.1.5 Arrêts suivants
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 108 sur 159
les
(ou
les
OnwardCall
Stop
Identity
0:1
StopPointRef
+Structure
Information sur les arrêts suivants.
StopPointCode
Identifiant du point d'arrêt
1:1
Order
0:1
xsd:positiveInte
ger
Numéro d'ordre de l'arrêt sur le trajet.
StopPointName
0:1
NLString
Nom du point d'arrêt.
xsd:boolean
La Valeur «true » indique que le véhicule est à
l'arrêt
1:1
Progress
0:1
VehicleAtStop
Arrival
Departure
AimedArrivalTime
0:1
xsd:dateTime
Heure d'arrivée théorique (ou commandée)
ExpectedArrival
Time
0:1
xsd:dateTime
Heure d'arrivée estimée par les systèmes
fournisseurs.
ArrivalStatus
0:1
onTime | early
delayed
cancelled
arrived
noReport
|
|
|
|
Caractérisation de l'horaire d'arrivée attendu
ArrivalPlatformName
0:1
NLString
Identification du quai d'arrivée
AimedDeparture
Time
0:1
xsd:dateTime
Heure de départ théorique (ou commandée).
ExpectedDepart
ureTime
0:1
xsd:dateTime
Heure de départ estimée par les systèmes
fournisseurs
DepartureStatus
0:1
onTime | early
delayed
cancelled
arrived
noReport
|
|
|
|
Caractérisation de l'horaire de départ attendu.
Voir Arrival Status
DeparturePlatformName
0:1
NLString
DepartureBoardingActivit
y
0:1
boarding
noBoarding
passthru
Identification du quai de départ.
|
|
Indique si l'on peut monter dans le véhicule ou
si c'est un passage sans arrêt ou avec montée
interdite.
Valeur par défaut : « boarding »
L’indicateur n’est pas qualifiable par les
systèmes fournisseurs.
Progress
Status
AimedHeadWayInterval
0:1
Fréquence de
commandée)
ExpectedHeadwayInterval
0:1
Fréquence de passage
systèmes fournisseurs
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
passage
théorique
estimée
par
(ou
les
PAGE
Page 109 sur 159
9.2.1.6 FramedVehicleJourneyRef
0:1
+Structure
Identification d'un course.
DataFrameRef
0:1
DataFrameQualifier
Contexte d'identification de la course (code du
système fournisseur de la donnée, version du
référentiel de données, etc.).
DatedVehicleJourneyRef
0:1
DatedVehicleJourneyCode
Identifiant de la course lui même.
FramedVehicleJourneyRef
9.2.1.7 DisruptionGroup (Perturbations)
Groupe
d'attribut
perturbations
DisruptionGroup
Situation
SituationRef
0:1
SituationCode
précisant
les
Identifiant (externe) de l'événement qui
est la cause des modifications horaires
indiquées.
Un libellé
perturbation
renseigné.
de description de la
pourra également être
9.2.1.8 JourneyProgressGroup (Localisation du véhicule)
Groupe d'attribut précisant l’avancement
sur le trajet
JourneyProgressGroup
Status
Monitored
0:1
xsd:Boolean
Indique si le véhicule est toujours
localisé (la valeur false indique une
délocalisation du bus).
Valeur par défaut : « true »
Progress
Data
Quality
MonitoringError
0:1
GPS | GPRS | Radio
Si le bus est délocalisé, ce champ
précise la cause de cette délocalisation
InCongestio
n
0:1
xsd:Boolean
Ce champ vaut « true » si le vehicule est
pris dans un embouteillage (ou plus
généralement un incident d’exploitation),
ce champ permet de le signaler.
InPanic
0:1
xsd:Boolean
Indique que l'alarme du véhicule est
activée.
Progress
Data
VehicleLocation
0:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
LocationStructure
Indique la position du véhicule (voir
LocationStructure).
PAGE
Page 110 sur 159
Bearing
0:1
AbsoluteBearingType
Occupancy
0:1
full | seatsAvailable
standingAvailable
Indique l’orientation (cap) du véhicule.
|
Indique le niveau de remplissage du
véhicule.
Dans l’état actuel des choses peu (pour
ne pas dire aucun) le système ne
dispose pas de cette information, mais le
besoin d’en disposer a été remonté lors
des interviews.
Valeur par défaut : « seatsAvailable»
Delay
0:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
DurationType
Indique le niveau de retard du véhicule
(une valeur négative indique une
avance).
PAGE
Page 111 sur 159
9.2.1.9 VehicleJourneyInfoGroup
VehicleJourneyInfoGrou
p
Servic
e Info
:::
0:1
ServiceInfoGroup
Voir ServiceInfoGroup.
Servic
e End
Point
Name
s
OriginRef
0:1
JourneyPlaceCode
Identifiant de l'arrêt de départ de la course.
OriginName
0:1
NLString
Nom de l'arrêt de départ
Via
0:*
+Structure
Description d'un via sur la course
PlaceRef
0:1
JourneyPlaceCode
Identifiant de l'arrêt via
PlaceName
0:1
NLString
Nom du via
Ne correspond pas forcément au nom de
l’arrêt via (nommage de l’itinéraire via)
End
Times
DestinationRef
0:1
JourneyPlaceCode
Identifiant du dernier arrêt de la course.
DestinationName
0:1
NLString
Nom de l'arrêt de destination (si l'identifiant
DestinationRef est fourni, le nom doit l 'être
aussi).
VehicleJourneyName
0:1
NLString
Nom de la course
JourneyNote
0:1
NLString
Texte complémentaire décrivant la course.
HeadwayService
0:1
xsd:boolean
La valeur « true » permet de signaler que la
course est gérée en fréquence (interval), et
que les informations horaires seront
fournies en conséquence…
OriginAimedDepartureTime
0:1
xsd:dateTime
Heure théorique de départ de la course à
son point de départ
DestinationAime
dArrivalTime
0:1
xsd:dateTime
Heure théorique d'arrivée de la course à
son point de départ.
9.2.1.10 Structure Location
0:1
LocationStructure
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
+Structure
Contenu
des
localisation.
informations
de
PAGE
Page 112 sur 159
Attributes
Id
0:1
xsd:NMTOKEN
srsName
0:1
xsd:string
choice
Coordinates
Longitude
–
1:1
LongitudeType
Latitude
–
1:1
LatitudeType
Coordinates
–
1:1
0:1
xsd:string
Precision
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
Distance
Identifiant du point (pour un éventuel
lien avec une base Géospatiale ou un
SIG)
Idenfitiant du référentiel de projection
(conforme EPSG, définit par l’OGC,
et tel qu’utilisé par GML )
Valeur Fixe pour une instance du
logiciel (paramètrable)
La localisation peut-être fournie soit
en WGS 84 soit dans un referentiel
projeté (Lambert 2 étendu, par
exemple)
Ces deux possibilités sont conservées
dans le profil SIRI Ile-de-France.
Longitude à partir du meridien de
Greenwich:.180° (East) à +180°
(West). Degrés décimaux.
Latitude à partir de l’équateur. -90°
(South) à +90° (North). Degrés
décimaux
Coordonnées au format GML en
cohérence avec l’attribut srsName.
Précision du positionnement (en
mètres).
PAGE
Page 113 sur 159
9.2.1.11 JourneyPatternInfoGroup
Groupe d'attribut pour la description des
trajets
JourneyPatternInfoGroup
Journey
Pattern
Info
JourneyPatternRef
0:1
JourneyPatternCode
Identifiant du trajet
VehicleMode
0:1
air | bus | coach |
ferry | metro | rail
|
tram
|
underground
Famille de transport pour ce trajet (il s’agit ici
d’un mode « générique », tous les avions
par exemple seront air, et c’est le
ProductCategory, dans ServiceInfoGroup,
qui donnera plus de précisions, comme :
internationalFlight,
intercontinentalFlight,
domesticScheduledFlight, shuttleFlight …
Valeur par défaut : « bus »
RouteRef
0:1
RouteCode
Identifiant de l'itinéraire suivi.
PublishedLineName
0:1
NLString
Nom de la ligne
DirectionName
0:1
NLString
Nom de la direction du trajet (nom du dernier
arrêt)
9.2.1.12 ServiceInfoGroup
Service
Info
OperatorRef
0:1
OperatorCode
Identifiant de l'exploitant
ProductCategoryRef
0:1
ProductCategoryCode
Mode de transport détaillé (voir
l’énumération complète dans le XSD
SIRI)
(Bus, Métro, Bus Scolaire)
ServiceFeatureRef
0:*
ServiceFeatureCode
Classification du type de service
(accessibilité).
VehicleFeatureRef
0:*
VehicleFeatureCode
Service spécifique disponible dans le
véhicule (plancher bas)..
9.3 Requête d’informations de messagerie
Ce service permet d’accéder aux informations conjoncturelles.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 114 sur 159
GeneralMessageRequest
+Structure
Requête d'accès aux messages
Attributes
Version
1:1
VersionString
Version du service « General Message »
(1.0)
Endpoint
Properties
RequestTimestamp
1:1
xsd:dateTime
Date d'émission de la requête
MessageIdentifier
0:1
MessageQualifier
Numéro d'identification du message
InfoChannel
Ref
0:*
InfoChannelCode
Identifie le canal pour lequel on souhaite
obtenir les messages. Si ce champ n'est pas
présent, la requête concerne tous les
canaux.
Topic
1:1
Dans le cadre du profil IDF, seules les
valeurs suivantes seront utilisées pour
identifier les canaux:
« Perturbation »
« Information »
« Commercial »
Request
Policy
Language
0:1
xml:lang
Langue dans laquelle le message est
demandé.
Dans le cadre du profil IDF, seul le Français
est obligatoire, mais un système pourra
optionnellement proposer d'autres langues
La langue par défaut sera le Français
9.3.1.1 Résultat de la requete d’informations de messgarie
ServiceDelivery
+Structure
See
SIRI
ServiceDelivery
Part
2-7.2.1
HEADER
:::
1:1
See
ServiceDelivery
En-tête générique des réponses
Payload
GeneralMessageDelive
ry
1:*
+Structure
Voir GeneralMessageDelivery.
9.3.1.2 GeneralMessageDelivery
GeneralMessageDelivery
+Structure
Contenu et modification des messages.
Attributes
version
1:1
VersionString
Version du service (valeur fixe)
LEADER
:::
1:1
xxxServiceDelivery
En-tête
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 115 sur 159
Payload
InfoMessag
e
0:*
+Structure
Le message lui-même (voir InfoMessage ci
dessous).
InfoMessag
eCancellatio
n
0:*
+Structure
Structure
d'annulation
d'un
précédent (voir ci dessous).
message
(Utile uniquement pour les abonnements)
9.3.1.3 InfoMessage
InfoMessage
attribute
formatRef
0:1
+Structure
Message d'information.
FormatCode
Identifie le format du contenu (ouvert pour
ce service)
1:1
Dans le cadre du profil IDF, ce champ sera
toujours présent et aura une valeur fixe
« STIF-IDF ».et correspond au transport de
la structure spécifique de message décrite
plus bas.
log
RecordedAtTime
1:1
xsd:dateTime
Heure d'enregistrement du message.
Identity
ItemIdentifier
0:1
ItemIdentifier
Identifiant unique du message SIRI, fourni
par son émetteur (deux réceptions
différentes ne peuvent avoir le même
identifiant)
1:1
traité hors BD dans l'élaboration de la
réponse
Identity
InfoMessageIdentifier
1:1
Identifier
Identifiant InfoMessage (sera utilisé pour
les mises à jour et les abandons de
message: toutes les mises à jour du
message porteront le même InfoMessageIdentifier).
InfoMessageVersion
0:1
xsd:positiveInteger
Version du InfoMessage.(considéré comme
valant 1 si le champ n'est pas présent)
InfoChannelRe
f
0:1
InfoChannel
Canal auquel appartient le message.
Dans le cadre du profil IDF, seules les
valeurs suivantes seront utilisée pour
identifier les canaux:
1:1
« Perturbation »
« Information »
« Commercial »
Currency
ValidUntilTime
0:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
xsd:dateTime
Date et heure jusqu'à laquelle le message
est valide.
PAGE
Page 116 sur 159
Valeur par
d’exploitation
Situation
0:*
SituationRef
SituationCode
défaut :
fin
de
journée
Identifiant (externe) de l'événement rattaché
au message
Un libellé de description de la perturbation
pourra également être renseigné.
Message
Content
1:1
anyType
Le message lui-même (voir ci dessous)
9.3.1.4 Content
Content
+Structure
Contenu du message d’information.
Identity
LineRef
0:*
Identifier
Identifie la ou les lignes concernées par le
message.
Si une ligne est indiquée, le message porte
sur toute la ligne sans restriction.
Identity
NetworkRef
0:*
Identifier
Identifie le ou les réseaux concernés
Si un réseau est indiqué, le message porte
sur toutes les lignes du réseau sans
restriction.
Identity
StopPointRef
0:*
Identifier
Identifie le ou les points d'arrêt concernés
par le message.
Identity
JourneyPattern
0:*
Identifier
Identifie la ou les trajets concernés par le
message.
Si un trajet est indiqué, le message porte sur
tout le trajet sans restriction.
0:*
Identifier
Identifie le ou les itinéraires concernés par le
message.
Si un itinéraire est indiqué, le message porte
sur tout l'itinéraire sans restriction.
Ref
Identity
RouteRef
Cette notion n’existe pas dans le référentiel
TITAN.
LineSection
0:*
+Structure
Identifie la ou les sections de lignes (premier
et dernier arrêt ainsi que leur ligne
d'appartenance) concernée par le message.
Si une section de ligne est indiquée, le
message porte sur tous les arrêts de cette
section, sans restriction. (voir ci dessous).
Cette donnée n’est pas disponible car les
messages sont associés à plusieurs points
d’arrêts dans ce cas.
Message
Message
1:*
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
+Structure
Contient naturellement le message lui-même
PAGE
Page 117 sur 159
(voir ci dessous)
LineSection
+Structure
Sections des lignes concernées par le
message.
Identity
FirstStop
1:1
Identifier
Identifiant du premier arrêt de la section
Identity
LastStop
1:1
Identifier
Identifiant du dernier arrêt de la section.
Identity
LineRef
1:1
Identifier
Identifiant de la ligne.
+Structure
Contenu du message
Message
MessageType
1:1
Long| short
Type du contenu du message
MessageText
0:1
xsd :string
Texte du message
Identifiant d’arrêt ou url pour le profil
Infomoville
9.4 En-têtes des réponses
9.4.1 Structure générique des entêtes de réponses
ProducerResponseEndpoint
log
+Structure
Structure générale des réponses
RequestTimestamp
1:1
xsd:dateTime
Date d’émission de la réponse
ProducerRef
0:1
ParticipantRef
Identifiant du producteur de
l'information
Address
0:1
EndpointAddress
Adresse réseau de l'émetteur (ici
une URL étant donné le choix
d’implémentation
SOAP
recommandé)
Endpoint
Properties
Initialement prévu pour les retours
d'acknowledge (non retenu dans le
profil)
ResponseMessageIden
tifier
0:1
RequestMessageRef
0:1
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
MessageQualifier
Identifiant unique de ce message
Identifiant géré en base
MessageQualifier
Identifiant unique de la requête à
laquelle on répond (champ issu du
MessageIdentifier de la requête)
PAGE
Page 118 sur 159
9.5 CheckStatus
9.6 ServiceDelivery
Entête générique des réponses aux différents services.
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 119 sur 159
9.6.1 Structure des réponses aux services
xxxDelivery
+Structure
Structure générique des réponses aux services
Log
ResponseTimestamp
1:1
xsd:dateTime
Date et heure de production de la réponse
Endpoint
properties
RequestM
essageRef
0:1
MessageQualifier
Référence de la requête
Subscriber
Ref
0:1
ParticipantCode
Identification du souscripteur
Subscripti
onRef
0:1
Status
0:1
Nn
Status
Obligatoire en cas d’abonnement
Identification de la souscription
Obligatoire en cas d’abonnement
xsd:boolean
Indique si la requête a pu être traitée avec succès
ou non.
+Structure
Signalement d’erreur
choice
Choix parmi les codes d’erreur
1:1
ErrorCondi
tion
0:1
+ Error
Fonction non supportée
b AccessNotAllowedError
+Error
Accès refusé
c NoInfoForTopicError
+Error
d AllowedResourceUsageExceededError
+Error
Réponse trop volumineuse
e OtherError
+Error
Autre erreur
ErrorDescripti
on
Description de l’erreur
a CapabilityNotSupportedError
-1:1
Pas de gestion de droits d'accès aux services
Pas d’information pour cette requête
réponse vide si pas d'information
Description
Payload
SubscriptionQualifier
0:1
ValidUntil
0:1
xsd:dateTime
Date de validité maximale de la réponse
ShortestPossibleCycle
0:1
Intervalle minimal de mise à jour de la donnée
{Content Specific to SIRI Functional Service type. See Part 3.}
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 120 sur 159
Annexe N1 : présentation à la PREDIM sur les
travaux effectués par ESIEE Paris dans le groupe de
normalisation TC278/WG3/SG3 : Traveller
information for Visually impaired people
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 121 sur 159
Traveller information for Visually
impaired people
TC278/WG3/SG3
TC278 : Road Transport and Traffic
Telematics
WG3 : Public Transport
SG3 : MMI in public transport
TC278 WG3 SG3 - O.Venard
PREDIM - 15/02/2008
1
WG3 Framework
PREDIM - 15/02/2008
2
Historique
• Motivation : lois sur l’accessibilité à travers
l’europe.
• Introduction
– Juin 2006 : meeting TC278/WG3 à Paris
• Élaboration de l’introduction et du « scope » :
– Nov. 2006 : premier meeting SG 3 à Prague
– Nov. 2007 : 7eme meeting SG3 Paris version1.0
• Démarrage travaux sur le corps de la
spécification technique
PREDIM - 15/02/2008
3
Partenaires
• [CZ] : S. Bartak, (consultant APEX), I.Hrouda,
(APEX)
• [UK] : N. Knowles, (Kizoom), R.Slevin (MT)
• [FR] : O. Venard, K.Bourée (coordination avec
les travaux TRANSMODEL SG4, IFOPT SG6,
SIRI SG7)
• [CH] : W.Meier-Leu, (Weisskopf Engineering
AG)
• [SE] : H.Davoody, (MT/ITS division)
• [DE] : R.Zuncker (Siemens)
PREDIM - 15/02/2008
4
Les projets
• Une approche basée sur l’expertise apportée par
la conduite de projet sur les systèmes d’assistance
à la mobilité
– CZ : Tyfloset
– CH : PAVIP (Personal Assistant for Visually
Impaired People)
– SE : FRAM (Flexible Real-time Assistance for
Moving)
– FR : RAMPE et INFOMOVILLE
PREDIM - 15/02/2008
5
CZ - Tyfloset
PREDIM - 15/02/2008
6
CH - PAVIP
1.Identify car that is approaching (which line? which final stop?)
2.Signal command to halt car & open door
3.Inside the car, ask for name of next stop. Browse through list of
upcoming stops
4.Inside or outside the car: Get information
about the environment
PREDIM - 15/02/2008
7
SE - FRAM
The travel aid will maintain continuous contact through the
infrastructure – GIS database, public traffic information, mobility
services etc – via a standardised interface being developed within
the e-Adept collaboration project (Electronic Assistance for Disabled
and Elderly Pedestrians and Travellers).
• To facilitate information processing
prior to and during the actual journey
•To facilitate planning, ordering,
payment, orientation and navigation thus
enhancing access by the traveller.
PREDIM - 15/02/2008
8
FR - RAMPE
« R - Les Marceaux,
dans 15 minutes »
Synthèse vocale
Interface
de commandes
Informations
communiquées :
Horaires
Parcours
Événements
Événements :
Ligne détournée
Bus à l'approche
Perturbations radio
Liaison radio WIFI
Arrêt bus
–
–
Système actif et interactif d’assistance et
d’information auditive aux voyageurs aveugles,
Installé aux points d’arrêt des transports
collectifs ou dans un pôle d’échanges.
Base de données
Informations
voyageurs
XML
Tour de comm.
Serveur central
Calculateur SIV
Coordonnées
GPS
PREDIM - 15/02/2008
9
Retour utilisateurs
• L’ensemble des projets intégrent une phase
d’évaluation :
– Soit en terme d’expertise auprès d’associations
– Soit en terme d’expérimentation intégrant un
protocole, par exemple RAMPE sur le réseau
SYTRAL en avril 2007
– Soit en terme de déploiement PAVIP à St Gallen ou
Tyfloset sur certains réseaux.
PREDIM - 15/02/2008
10
Exprimentation RAMPE
28
38
~5min
~5min
34
79
~4min
~8min
Grange Blanche
Feuillat-Lacassagne
Parré-Laënnec
11
PREDIM - 15/02/2008
Expérimentation RAMPE
voyants
Etape 1
Etape2
Etape 3
Etape 4
temps global
temps global
temps global
temps global
non voyants
8
101
15
39
171
436
204
228
voyant /
non-voyant
22
4
14
6
PREDIM - 15/02/2008
PDA
141
446
160
205
Télécomman
de
202
426
248
250
12
Approche méthodologique
• It has been proposed to split the specification work in
three (top-down) layers, (figure on the next slide) :
– “Contents of the information” with (if meaningful) time
constraint. This will be based on use-cases.
– “Messaging”, the semantic that have to be used to allow
interoperability and conformance to existing standards,
TRANSMODEL, SIRI, TPEG, …
– “Hardware or physical media”, define how to implement the
above specified messaging system with the different technical
means to provide the travellers information to the end-user.
13
PREDIM - 15/02/2008
Approche méthodologique
• The first layer (Information definition) will be considered for the
draft to be delivered.
Information definition
Messaging
HW1
HW2
HW3
HWn
HWn
• Backward arrows are here to underline that some technological
means could create constraints on the contents information layer.
PREDIM - 15/02/2008
14
Classes de service
• User end:
• Low-cost
Collective
• PT authority end:
Low-cost infrastructure
– Remote control
– Devices with processing
(TTS,…) and some wireless
networking capabilities.
– Devices with high processing
and connectivity capabilities.
Ability to have have
connection to the travellers
information system.
• High-tech
– Broadcasting audio and visual
information on triggering.
– Wireless networking
capability. Local information
database downloadable.
– + real-time information (imply
network connection to the
back-office).
– + Value-added services as
journey planning, contextual
information, …
High level service
Individual
PREDIM - 15/02/2008
15
Structure du document
•
•
•
•
•
•
•
Introduction
Scope
Références normatives
Définition (TRANSMODEL, IFOPT, …)
Cas utilisateurs
Spécifications
Schéma XML de référence - Glossaire
PREDIM - 15/02/2008
16
Introduction
• Harmonisation et intégration dans un seul dispositif
• Information liées au voyage et données spécifiques liées
aux besoins particuliers
• Doit considérer l’ensemble des canaux perceptuels
mobilisables : audio, haptique, tactile
• Les besoins :
– Accessibilité, pertinence, fiabilité, sécurité
• Limites des dispositifs d’information et d’assistance :
– Ne remplace pas les autres formes possibles d’assistance.
PREDIM - 15/02/2008
17
Introduction
• Définit 3 classes de dispositifs.
• La formulation doit être ouverte pour permettre l’emploi
de toute les technologies.
• Doit intégrer une approche ergonomique du
déplacement.
• Les spécifications sont construites à partir de cas
utilisateurs dans la chaîne de déplacement.
• Doit définir les fonctionnalités obligatoires :
– Fonction de guidage vers les points fixes (Balise audio).
– Les dispositifs doivent permettre de piloter les tâches
interactives : commande de porte du véhicule, …
– …
PREDIM - 15/02/2008
18
Introduction
• Support multi-langue
• Acceptabilité par les autres usagers et le
personnel doit être évalué.
• Les éléments définit doivent être conforme au
normes existantes ou en préparation :
– TRANSMODEL(SG4), IFOPT(SG6), SIRI(SG7)
• L’inter-opérabilité entre les régions doit être la
plus grande possible.
PREDIM - 15/02/2008
19
Scope
• Applicable aux autorités organisatrices et opérateurs de
transport.
• Considère les informations dans les transports urbains
pour les personnes aveugles (1ere couche).
• Définit les informations et les fonctions déclanchables en
différents points : zone d’accès, arrêt, quai, véhicule …
– nature et la structure des informations
• Identifie la nature des informations et des contraintes
temporelles en fonction des classes de dispositif
• Pourra identifier des éléments manquants dans les
travaux existants (Transmodel, IFOPT)
PREDIM - 15/02/2008
20
Scope
• Prend en compte le parcours de porte à porte et
identifie les informations nécessaires à chaque
étape :
– Pour les différents types de transport.
– Pour les différentes classes de dispositif.
– Les contraintes
• Définition du glossaire permettant le support
multi-langue.
PREDIM - 15/02/2008
21
Scope
• Définit :
– Les cas utilisateurs.
– La nature des informations selon le mode de transport
et l’étape.
– Les contraintes temps-réel
– Les niveaux de service
– La coexistence avec les autres dispositifs ou fonctions
d’assistance existants.
PREDIM - 15/02/2008
22
Scope
• Ne traite pas :
– Couche message et couche physique
– Les besoins dans les autres champs que les transports
publics.
PREDIM - 15/02/2008
23
TRANSMODEL & IFOPT
PREDIM - 15/02/2008
24
Cas utilisateurs
• Travelling to the access point of PT
• Selection of the desired route/direction and path to the
stop point/platform (boarding point)
• Waiting for the right vehicle at the stop point / platform,
getting on and finding a seat
• Travelling in public transport vehicles to an interchange
or the final destination
• Preparing to alight at an interchange or the final
destination
• Finding the next vehicle or the exit of the station
• Service messages, alternative journeys
PREDIM - 15/02/2008
25
Prochaines étapes
• Requirements on information
• XML Schema and Glossary
PREDIM - 15/02/2008
26
Conclusions
• La convergence vers une approche ouverte et
permettant l’inter-opérabilité est un problème
délicat :
– Du point de vue technique.
– Du fait de l’existant et des enjeux liés à son
déploiement.
– Structure de décision et de déploiement dans le monde
des transports.
• Objectif : Construire une spécification technique
qui ait des chances de devenir une réalité.
PREDIM - 15/02/2008
27
10 Annexe N2 : Spécification technique européenne
CEN/1 TC278/WG3/SG3, octobre 2007, Public
Transport - Road Vehicles, Traveller information
for visually impaired people (TI-VIP), version 1.00
CLEARANCE LEVEL
FORMAT
SIZE
CONFIDENTIEL
CONFIDENTIAL
A4
PAGE
Page 136 sur 159
EUROPEAN TECHNICAL SPECIFICATION
SPECIFICATION TECHNIQUE EUROPÉENNE
EUROPÄISCHE TECHNISCHE SPECIFICATION
October 2007
CEN/TC278/WG3/SG3
1
2
3
English version
4
5
6
Public Transport - Road Vehicles
8
Traveller information for visually impaired people
(TI-VIP)
9
Version 1.00
10
16
This draft European Technical Specification is submitted to CEN members for CEN
enquiry.
It has been drawn up by CEN Technical Committee TC278 Working Group WG3.
CEN members are the national electro technical committees of Austria, Belgium,
Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy,
Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United
Kingdom.
17
CEN
7
11
12
13
14
15
18
19
20
European Committee for Standardisation
Comité européen de Normalisation
Europäisches Komitee für Normung
21
22
23
Central Secretariat: rue de Stassart 35, B-1050 Brussels
© 1998 Copyright reserved to CEN members
Traveler’s information for visually impaired people
Page
2
Revision history
24
Date
2006-11-09
Version
0.00
Description
Praha WG3/SG3 meeting
Scope redaction
2006-12-08
0.00a
2007-04-03
0.01
2007-06-01
2007-06-29
0.02
0.03
Köln WG3 meeting
Scope is shifted to introduction
An additive scope part is
needed
Paris WG3 meeting
A scope part is added
Praha WG3/SG3 meeting
Schaffhausen WG3/SG3
2007-07-18
0.04
2007-07-23
0.05
2007-0730
0.06
2007-08
0.07
2007-10-04
0.08
2007-10-16
0.08rs
2007-10-23
0.09
2007-11-12
0.99
2007-11-25
1.00
Praha
Scope and Introduction
redaction, CEN standard layout
Contents of introduction und
scope changed back to version
0.03 within CEN standard
layout.
Schaffhausen WG3/SG3
Was a no longer followed
version of CZ experts
Includes Review comments to
version 0.06 and CZ
comments to a pre review.
changes mainly to improve
clarity of language
Includes Review comments to
version 0.08
Paris WG3/SG3
English corrections
Minor changes by Stanislav
Bartak
Author/Content provider
Stanislav BARTAK
Nick KNOWLES
Olivier VENARD
Olivier VENARD
Olivier VENARD
Walter Meier (mew)
Haval Davoody
Olivier Venard
Stanislav Barták
Ivan Hrouda
Walter Meier
Oliver Venard
Walter Meier (mew)
Haval Davoody
Olivier Venard
Stanislav Barták
Ivan Hrouda
Roman Zunker
Stanislav Barták
Walter Meier-Leu
Roger Slevin
Walter Meier-Leu
Walter Meier (mew)
Haval Davoody
Olivier Venard
Stanislav Barták
Ivan Hrouda
Kasia Boureé
Jean-Laurent Franchineau
Roger Slevin
Walter Meier-Leu
25
26
27
Foreword
28
29
30
31
32
33
34
The following dates are proposed:
- Latest date by which the existence of the European Standard
has to be announced at national level
(doa) 200X
- Latest date by which the European Standard has to be implemented
at national level by publication of an identical national standard
or by endorsement
(dop) 200X
35
36
Page
- Latest date by which the national standards conflicting
with the European Standard have to be withdrawn
37
38
39
40
Annexes, designated „normative“, are part of the body of the standard.
Annexes, designated „informative“, are given for information only.
3
(dow) 200X
Page
4
Contents
41
Page
42
43
1.
SCOPE.....................................................................................................13
44
2.
NORMATIVE REFERENCES ..................................................................17
2.1
2.2
45
46
47
3.
ABBREVIATIONS AND DEFINITIONS (for illustration only)................20
3.1
3.2
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Normative references for public transport infrastructure characteristics ........ 17
Standards and regulations prepared for European and worldwide levels ....... 18
Abbreviations .................................................................................................. 20
Definitions....................................................................................................... 20
3.2.1
Acoustic Announcement Message ...................................................... 20
3.2.2
Acoustic Announcement System ........................................................ 20
3.2.3
Acoustic Passenger and Driver Information System........................... 20
3.2.4
Automatic Vehicle Monitoring System .............................................. 21
3.2.5
Controller Area Network .................................................................... 21
3.2.6
CAN Open .......................................................................................... 21
3.2.7
Digital Acoustic Announcer................................................................ 21
3.2.8
Integrated Board Information System (IBIS) ...................................... 21
3.2.9
Industrial Ethernet............................................................................... 21
3.2.10
Man Machine Interface ....................................................................... 21
3.2.11
On-board Transmission Bus (OBTB) ................................................. 21
3.2.12
Short Message Service (SMS) ............................................................ 21
3.2.13
Vehicle Board Information and Control System................................. 21
3.2.14
Wi-Fi ................................................................................................... 22
64
4.
USE CASES ............................................................................................23
65
5.
REQUIREMENTS ....................................................................................23
66
6.
XML SCHEMA, KEYWORDS FOR MULTI-LINGUAL SUPPORT ..........23
67
7.
BIBLIOGRAPHY......................................................................................23
Page
5
68
INTRODUCTION
69
Advanced societies try to make life easier for their physically and mentally
70
handicapped citizens so that they can participate in daily life without the help
71
of others as far as their disability allows. Most European countries have
72
adopted or are adopting laws that almost all disabled people must have
73
equality in the accessibility of transport information by specific target dates.
74
Operators will have to meet specific requirements and recommendations by
75
particular deadlines set for each country. It is important to establish a
76
Technical Specification as soon as possible to achieve harmonization and to
77
avoid the development of several incompatible solutions. It must be
78
recognised that Visually Impaired People (VIP) dislike carrying several
79
devices; an integrated multifunctional device is preferable.
80
Passenger information facilities basically provide all the useful information
81
needed along a journey (arrival time, waiting time, changing stop/station, …)
82
but it can also help potential travellers to prepare for their travels and to
83
answer trip optimisation questions. Such trip planning functions identify the
84
origins and destinations of intended PLACE to PLACE trips and propose one
85
or several itineraries. These itineraries should take into account the traveller’s
86
constraints or preferences, such as any disability they have, minimising trip
87
duration, minimising the number of interchanges, cheapest fare, etc. This
88
involves an optimisation process using such parameters. Specific data will be
89
required to meet the needs of the visually impaired person, as the constraints
90
and needs of the VIP may be different from those of people without impaired
91
vision.
92
“Design for all” must consider visually impaired people (VIP) and their specific
93
needs. For these people it is a question of conveying meaning through
94
sounds and speech and touch, since auditory and tactile channels are often
95
their only means of perceiving information.
96
97
6
Particular concerns of VIP are:
i.
Accessibility: To be able to access public transport and visit known and
unfamiliar places by themselves;
98
99
Page
ii.
Relevance: To be able to locate themselves (know precisely where
100
they are) in the environment and to discover nearby stops, stop names,
101
available lines, their next journeys with an indication of departure time
102
and vehicle arrival, …
103
iii.
situation so that their mental “picture” matches with reality;
104
105
Reliability: The system should be able accurately to reflect the current
iv.
Safety and security: To be able to avoid falls and collisions (Safety
106
during boarding and alighting is a special concern), as well as feeling
107
secure in taking a certain path.
108
For VIP, entering an unfamiliar environment or making a new journey is
109
especially difficult. It is important to recognise that improved information
110
systems will not solve all of the challenges and it is important also to make
111
plans for assistance and support services. Standards for best practice within
112
such services may also be helpful.
113
Modern electronic technologies can provide VIP with better information.
114
Services for VIPs should, whenever possible, be an additional or specialized
115
form of MMI from services which are also available for unimpaired travellers.
116
It will be necessary to be clear which aspects are included in each existing
117
Standard or Technical Specification and which are not.
118
We first consider the end-to-end sequence of technologies used to deliver
119
such systems, including information about existing systems, devices,
120
Standards and Technical Specifications. The following classification of
121
devices, together with their communication characteristics, will be used for
122
this TS:
123
1. Different classes of end-user devices offering different levels of services:
124
The present technologies offer many possible solutions with different
125
levels of comfort. Three different classes of devices shall be considered.
126
In this part of the Technical Specification devices of the class a and b
127
(described below) will be considered. The devices of class c will be
128
considered in a subsequent part of the Technical Specification, following
Page
7
129
collaborative work with the International GDF Standards Group to allow
130
the description of geographic paths (for guidance through the pedestrian
131
network) which is expected to be included in the Part 2 of the IFOPT
132
Technical Specification. The devices should be able to communicate with
133
a travel information system if the infrastructure has implemented
134
appropriate interfaces and protocols.
135
a. One way communication device: The VIP is equipped with a simple
136
command transmitter with a small and ergonomic embedded tactile
137
keypad. The command receiver connects either to the on-vehicle
138
device (eg: vehicle controller, which incorporates the necessary
139
passenger information), or to an infrastructure controller, to get an
140
appropriate announcement, typically in the local language, or to trigger
141
some other action.
142
b. Two way communication device with integrated text to speech: The
143
device is equipped with a small and ergonomic tactile keypad, usable
144
for left and right handed people, and equipped to offer an
145
acknowledgement signal (vibration, tone within a given time, etc.) and
146
with a small loudspeaker and/or is able to connect to ear-phones. The
147
audible information is output by the personal device using text to
148
speech (TTS). The device receives the information as structured data
149
(for example XML). The keywords (for example stop, direction, …) are
150
output in the user’s mother tongue whilst the data (for example stop
151
names) are received as text in the local language and output (not
152
translated) by the device in the local language. This system should be
153
able to import the trip information from a travel information system, so
154
that the user gets appropriate current information on request during a
155
journey. It must be able to switch to full information on request. All
156
commands given to the device shall be acknowledged.
157
c. More sophisticated systems which use standard devices such as PDAs
158
or smart phones. Such devices must be equipped with a special MMI
159
for VIP: The keypad shall be tactile, usable for left and right handed
160
people and equipped to offer an acknowledgement signal. (Vibration,
Page
8
161
tone within a given time, etc.) This device should be able to
162
communicate with a centralised travel information system to make an
163
online rerouting in case of problems arising during the trip. It should
164
also be possible to get travel information from the user’s current
165
position
166
stop/station). It should be able to provide absolute or relative
167
positioning. For instance GPS (when far away from a stop and outside)
168
and audible or other indoor navigation functions near the public
169
transport stop points.
to
a
personally-defined
destination
(address
and/or
170
A device of class b must support the functionality of device of class a, and
171
devices of class c must support the functionality of classes a and b.
172
2. The fixed infrastructure objects (ticket machines, passenger information
173
facilities, stops, and some other objects defined in IFOPT) and on-board
174
audio systems provide audible guidance information to the VIP (in which
175
direction the VIP has to walk).
176
3. Communication between the end-user device and the “vehicle control and
177
information system” could allow the user to remotely:
178
a. Stop the doors from closing too early for slowly moving people.
179
b. Request a stop at the next stop point.
180
c. Request line and destination information from the “vehicle control and
181
information system”.
182
d. Inside the vehicle, get information about the next stops and
183
complementary information (for example terminus; “on request”;
184
“change to underground“, "change of tariff zone").
185
4. The near-area wireless communication method between the VIP’s device
186
and the vehicle or infrastructure could range from Short Range Command
187
Radio to Wireless LAN protocols.
188
189
5. Communication between the back office systems and at-stop systems is
not covered.
Page
9
190
6. Communication between the back-office systems and the on-board
191
systems is dependent on the radio network used. The messages used in
192
AVMS (Automatic Vehicle Monitoring Systems) will be used. The work on
193
Standards and Technical Specifications for VIP may identify additional
194
information elements that can usefully be added to the existing messages.
195
The information on-board the vehicle comes from the databases in the on-
196
board computer and the AVMS. Transmission of the data to the passenger
197
information device is achieved by means of the vehicle databus, for
198
example CAN Open, WorldFIP or Industrial Ethernet. The older vehicle
199
databus IBIS, which operates in many countries, can also be used for
200
these purposes.
201
7. The need for an additional interface between the on-board VIP
202
communication device and the on-board computer is dependent on the
203
vehicle databus and the on-board VIP communication device that are
204
used. When the vehicle databus and VIP communication device have the
205
same interface an additional interface is not needed. The same applies to
206
the stop/station passenger information systems. In new vehicles the VIP
207
communication device may be part of the on-board computer or
208
passenger information system, and the same would apply to new
209
stop/station passenger information systems.
210
The Technical Specification should be an open formulation that allows
211
different technologies to be used for specific components, for example near-
212
area Radio, Wi-Fi, Bluetooth, RFID etc, could all be used for near-area
213
wireless communication as long as they meet the requirements. The
214
Specification
215
technologies.
216
There are some aspects for standardisation that are abstract and apply
217
across different layers and use cases. For example:
218
•
should
not
be
constrained
to
specific
implementation
Ergonomic presentation standards for communication with the VIP.
219
There are well known considerations for auditory usability such as
220
pitch, attack, volume of signal, duration, reaction time, the required
221
response time for safety (for example, communication ideally needs to
Page
10
222
happen in less than three seconds). These requirements are
223
independent of specific technologies and are derived from human
224
perceptual psychology. (standards and recommendations have to be
225
enumerated)
226
•
The user functions that should be supported, for example; to help a
227
user to locate a stop; to discover the stop name; to obtain information
228
about next stop; to learn about next departures, to make a request to
229
board the vehicle. Certain of these functions could be mandatory.
230
•
The information content and data elements that need to be
231
transmitted,
232
direction/destination (end of the trip) etc. These correspond to
233
elements already defined in public transport information models, such
234
as TRANSMODEL (Reference Data Model for Public Transport), and
235
SIRI (Service for Real-time Information).. Different formats may be
236
needed to transmit elements in near-area wireless communication, and
237
the work on Standards for VIP may identify additional information
238
elements that can usefully be added to the existing models.
239
Short definition of relevant Technical Specifications and Standards:
240
i.
for
example
the
line
name,
stop
name,
The CEN TS IFOPT model (TSxxxxx Identification of Fixed
241
Objects in Public Transport) provides a detailed semantic model
242
of the fixed public transport objects. The object descriptions in
243
IFOPT can include the location and type of object. The
244
relationship with GDF (Geographic Data Files), a concrete link
245
with location referencing systems and issues related to mobility
246
impairment are scheduled for part 2 of IFOPT. Further topics
247
may be dealt with in a part 3.
248
ii.
The SIRI message set (Service Interface for Real Time
249
Information described in TS15531) can provide real-time data
250
messages to the fixed objects and vehicles that can be
251
transformed into a suitable form for delivery over special delivery
252
systems. These can also be used for delivering changes in
253
schedules.
iii.
254
Page
11
The CEN Transmodel Standard (EN12896 Reference Data
255
Model) provides a conceptual model for defining these
256
information elements across different systems.
257
•
Natural Languages.
258
259
•
262
Standards should consider existing best practices for assisting, training
and guiding VIP
260
261
All systems should be designed for multi-lingual support of different
•
The VIP should be made aware of available travel information systems
in unfamiliar environments.
263
The Technical Specification should set out use cases and scenarios for
264
interaction between visually impaired users and at-stop and on-board
265
systems. These should take into account the differences between transport
266
modes, for example buses, local trains, intercity trains, etc. They should
267
consider the use of training and support services. These use cases should be
268
developed in consultation with organizations for the blind and visually
269
impaired, e.g. European Blind Union.
270
Acceptability and disturbance of other passengers by the information system
271
must be checked and evaluated as is recommended in DIN TR 124.
272
The approach should be system-oriented, expressed in terms of information
273
layers, interfaces and models and allowing alternative implementations.
274
The Technical Specification must allow for inevitable differences in the use of
275
radio frequencies in different countries.
276
It should be an objective to identify the critical interfaces and harmonization of
277
technologies that would allow the same device to be used in as many
278
different regions and countries as possible. This could imply collaboration with
279
ETSI, other CEN or ISO groups. This would enable the VIP to ‘roam’ with a
280
single device in different regions.
281
The capture of the necessary information about the physical environment
282
represents a major practical challenge since there are hundreds of thousands
283
of bus stops in a typical European country and an even larger amount of data
Page
12
284
about the detailed environment and journeys. It will be important to identify
285
sources and processes for capturing and maintaining this data in order to
286
make it economically viable to provide travel information systems with the
287
capabilities needed for VIPs. The advantage of class c devices is that it is
288
able to get information without depending on at-stop devices.
Page
13
289
1. SCOPE
290
This Technical Specification will specify the information needed by blind and
291
visually impaired people (VIP) when they are travelling. This information is
292
primarily intended for users of road-based transport like buses, trolleybuses
293
and trams, but it can also be used for subway, regional and inter-city trains.
294
This Technical Specification aims to define the contents of the information
295
required at an urban or regional level. Its goal is to make consistent
296
information for VIP who are travelling anywhere in Europe. It will define the
297
nature and the structure of the information for Visually Impaired People using
298
public transport to make it familiar, homogeneous and consistent.
299
This Technical Specification is applicable to organisations and operators of
300
facilities for Public Transport and related services, either urban or regional,
301
who want to guarantee “accessibility for all” and comply with local laws and
302
recommendations in that field. This Technical Specification should comply
303
with relevant laws and recommendations throughout European countries. The
304
term Public Transport is used to describe all forms of “collective transport”.
305
This Technical Specification defines the information and remotely controlled
306
functions that should be available for VIPs at stops, platforms, access areas
307
and inside/outside vehicles. The provision and the updating of the available
308
information is undertaken by the Public Transport operators or their partners.
309
It could be linked with existing information and management systems.
310
This Technical Specification identifies the contents of the information, the
311
events, the validity time periods and the information which should be offered
312
by the different classes of end-user devices.
313
This Technical Specification states which information should be provided by
314
each one of the different classes of end-user devices.
315
The “Traveller information for Visual Impaired People” is defined in a three
316
layer top-down framework:
317
318
•
“Contents of the information”: should be in accordance to Standards
and other Technical Specifications (TRANSMODEL, IFOPT, SIRI,
Page
14
319
TPEG, etc.). All information has to be defined (including events for
320
triggering, devices on which the information is presented and validity
321
time periods). This will be based on use-cases.
322
•
“Messaging and Dialogues”: This part of the processing has to comply
323
with existing Standards and Technical Specifications SIRI, TPEG, … to
324
allow interoperability.
325
•
“Hardware or physical media”, defining how to implement the
326
messaging system specified above with different technical solutions to
327
assure delivery of traveller information to the end-user. This could
328
include collaboration with ETSI (layer for radio-communication).
329
The work to develop this Technical Specification may identify additional
330
information elements that need to be added to existing Standards and
331
Technical Specifications.
332
This Technical Specification encompasses only the first upper layer “Contents
333
of the information”.
334
A trip from one location to another location, often described as “door to door”
335
(PLACE to PLACE1), of a VIP involves going through several steps and
336
phases (using various transport modes). This Technical Specification defines
337
the information linked to each step and area crossed during a trip of a VIP. It
338
will also define the information supply-chain for the VIP’s traveller information
339
and the updates needed. It must be based on the elements and objects which
340
are or will be described in TRANSMODEL and/or IFOPT.
341
This Technical Specification will take into account:
342
•
The various transport modes used during a PLACE to PLACE trip.
343
•
The information needed at each step in the PLACE to PLACE trip.
344
•
The different classes of end-user devices.
1
Transmodel: A PLACE is a geographic location of any type. It may be specified as the origin or destination of a
trip
345
•
•
•
352
The constraints on the information layer imposed by the hardware or
Glossary with all reference keywords needed for Multilanguage support
(XML tags).
350
351
The constraints on the information layer imposed by the messaging
physical media layer.
348
349
15
layer.
346
347
Page
This Technical Specification will mainly define:
•
Use-cases for end-users which will demonstrate the information
353
needed (as line number, destination, name of next stop, etc.) and the
354
associated real-time constraints.
355
•
PLACE trip which may depend on the type of transport used.
356
357
•
•
The different kinds of information available (different levels of service)
which depend on the different classes of end-user devices.
360
361
The real-time constraints of the information which depend on its nature
and its usage.
358
359
The nature of the information needed at each step of the PLACE to
•
The relationships between this information framework (intended for VI
362
travellers on public transport), and other information systems for VIP
363
(traffic light, indoor navigation, etc) have to be clarified.
364
365
366
This Technical Specification will not define:
•
The
two
lower
layers
of
the
framework
(Messaging
and
367
Hardware/physical media) that will be considered in another Technical
368
Specification, as
369
o Acoustic Announcement System
370
o Acoustic Passenger and Driver Information System
371
o Automatic Vehicle Monitoring System
Page
16
372
o Digital Acoustic Announcer
373
o Integrated Board Information System (IBIS)
374
o The technical means which are specified for communication
between the information system and the user.
375
376
•
the information needed by VIP in fields other than public transport
377
usage. But it has to take into consideration the developments which
378
are being undertaken to meet other needs of VIP.
379
2. NORMATIVE REFERENCES
380
2.1
381
Page
17
Normative references for public transport infrastructure
characteristics
382
383
EN 12694
Public transport – Road vehicles – Dimensional requirements for
variable electronic external signs
384
EN 12896
Reference Data Model
385
386
387
EN 13149-1
Public Transport Road Vehicle Scheduling and Control Systems –
Part 1 WORLDFIP definition and application rules for On Board
Data Transmission
388
389
EN 13149-2
Public Transport Road Vehicle Scheduling and Control Systems -Part 2: WORLDFIP Cabling Specifications
390
391
392
TS 13149-3
Public Transport Road Vehicle Scheduling and Control Systems On Board Data Transmission between Equipment inside a Vehicle
-- Part 3: WORLDFIP Messages
393
394
395
EN 13149-4
Public Transport-Road Vehicle Scheduling and Control System -Part 4 General application rules for CAN Open transmission
buses
396
397
EN 13149-5,
Public transport-Road Vehicle Scheduling and Control System
– Part 5: CANopen Cabling specification
398
TS 13149-6
Public transport-Road Vehicle Scheduling and Control
System -- Part 6: Messages
400
401
ENV 13998
Road transport and traffic telematics – Public transport
Non-interactive dynamic passenger information on ground
402
403
TS 15504
Public transport - Road vehicles - Visible variable passenger
information devices inside the vehicle
404
405
406
TS 15531-1
Public transport - Service interface for real-time information
relating to public transport operations - Part 1: Context and
framework
407
408
409
410
411
412
TS 15531-2
relating to public transport operations - Part 2: Communications
infrastructure
relating to public transport operations - Part 3: Functional
service interfaces
399
413
414
415
TS 15531-3
–
416
417
2.2
Page
18
Standards and regulations prepared for European and
worldwide levels
Institution / Researchproject
Guideline
year
Affected scope
Trace Research &
Development Center (USA)
Accessible Design of Consumer
Products. Guidelines for the Design
of Consumer Products to increase
their accessibility to people with
disabilities or who are aging
1992
Products general
FACE (Familiarity achieved
through common user
interface elements; EUProject)
Guidelines and Rules for Design of
User Interfaces for Electronic
Home Devices
1994
Telecommunication,
only MMI
EIA / CEMA, EIF (Electronic
Industries Alliance’s /
Consumer Electronics
Manufacturing Association,
Electronic Industries
Foundation; USA)
Resource Guide for Accessible
Design of Consumer Electronics
1996
Electronic Products
Consumer Safety
Institute(NL)
Product Safety Guide for the
Elderly
1999
Products general
(safety)
COST 219 to (COST =
European co-operation in the
fields of scientific and
technical research)
Design Guidelines on Smart Homes
1999
Smart Home
STAKES / COST 219 to
(STAKES = National
Research and Development
Centre for Welfare and
Health Finland
Telecommunications – Guidelines
for Accessibility
1999
Telecommunication
RNIB (Royal National
Institute for the Blind; GB)
Which button? Designing user
interfaces for people with visual
impairments
2000
Products general
(MMI)
418
419
Standard level
Guideline to standard / standard
year
Content
ADA and ABA
Accessibility
Guidelines for
Buildings and
Facilities
Contains scoping and technical
requirements for accessibility to
sites, facilities, buildings, and
elements by individuals with
disabilities.
2004
Guideline for implementation
of ADA. All public buildings,
means of transportation,
telecommunication- and ITservices have to be accessible
for disabled persons.
ISO / IEC .
CEN/CENELEC
JISC (Japan)
Guide 71 'Guidelines for
standardization to address the
needs of older persons and people
with disabilities'.
Adopted by CEN/CENELEC as
Guide 6 and by JISC as JIS Z 8071.
2001
This document guides
standardization committees to
recognize the needing of
elderly and handicapped
people. To be incorporated in
standards.
ISO/TR 22411
(ISO TC 159 WG2)
Ergonomic data and ergonomic
guidelines for the application of the
2006
To relief the adoption of guide
71 which shall be prepared in
Standard level
Guideline to standard / standard
year
ISO/IEC Guide 71 in standards
related to products and ser-vices to
address the needs of older persons
and persons with disabilities.
Page
19
Content
form of a technical report to
serve the standardization
committee with its knowledge.
DIN Fachbericht
124
(Germany)
Products in “Design for All””
(Translation of DIN Fachbericht
124 ‘Barrier free products.
Principle and requests 2001)
2002
Defining of quality requests to
technical products for usage
by people with limited
abilities.
Addressing product designer
and standardization
committees. Almost all
requests are usable in public
transport for components and
infrastructure, although it is
left out by formal reasons.
Foreseen as a basic document
for the development of a
additional document to the
ISO-guide 71 in the new
founded ISO TC 159 WG 2
"Ergonomics for People with
special requirements"
CEN /CENELEC
/ETSI
Guidance document in the field of
safety and usability of products by
people with special needs (e.g.
elderly and disabled)*)
2003
Regulations for safety and
usability of products for
People with special
requirements (Elders and
handicapped). Addressing
standardization committees.
420
421
422
423
424
* Die European Commission has announced that as stipulated in their ordered guidance document, all
relevant product-standards have to be reviewed and changed if necessary.
Page
425
3. ABBREVIATIONS AND DEFINITIONS (for illustration only)
426
The following definitions apply to this Technical Specification:
427
3.1
20
Abbreviations
428
AAM
Acoustic Announcement Message
429
AAS
Acoustic Announcement System
430
APDIS Acoustic Passenger and Driver Information System
431
AVMS Automatic Vehicle Monitoring System
432
CAN
433
GPRS General Pocket Radio Service
434
IBIS
Integrated Board Information System
435
MMI
Man Machine Interface
436
OBTB On-board Transmission Bus
437
SDS
Short Data Service
438
SMS
Short Message Service
439
SRCR Short-Range Command Radio
440
VBICS Vehicle Board Information and Control System
441
VIP
Visually Impaired (Handicapped) Person or People
442
Wi-Fi
Wireless Fidelity
Controller Area Network
443
3.2
Definitions
444
3.2.1 Acoustic Announcement Message
445
446
Acoustic Announcement Message is voice information for passengers or a
driver.
447
3.2.2 Acoustic Announcement System
Computer controlled system which controls acoustic announcement in a
vehicle designed as a part of Vehicle Board Information and Control
System (VBICS). The functions of AAS may be integrated in one device:
Digital Acoustic Announcer DAA.
448
449
450
451
452
453
454
455
456
3.2.3 Acoustic Passenger and Driver Information System
The “Acoustic Passenger and Driver Information System” is created by
electronic devices controlled by the board controller, which by means of
loudspeakers; generate acoustic announcements in one of three
possible audio directions.
Page
21
462
3.2.4 Automatic Vehicle Monitoring System
System equipment on-board the vehicle of road public transportation
(buses, trolleybuses and tramways) and the corresponding equipment
installed on the ground, which are designed for the operation of public
transport (operation aid systems, automatic information systems, fare
collection systems, maintenance aid systems).
463
3.2.5 Controller Area Network
457
458
459
460
461
464
465
466
The CAN data link layer protocol for serial communication as specified in
ISO 11898-1.
3.2.6 CAN Open
467
468
The CAN Open is a CAN-based higher layer protocol. It was developed as a
standardised embedded network with highly flexible configuration capabilities
469
474
3.2.7 Digital Acoustic Announcer
Digital Acoustic Announcer is a part of AAS. DAA is determined to
announce of the stops´ names and messages which are stored in its
digital memory. DAA converts the digital data into an analogue audio
signal. Parts of AAS are also audio power amplifiers when in DAA are
integrated the functions of AAS.
475
3.2.8 Integrated Board Information System (IBIS)
470
471
472
473
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
Integrated on-vehicle information and control system for passengers and
drivers. (Recommendation VDV Germany)
3.2.9 Industrial Ethernet
Industrial Ethernet is the name given to the use of the Ethernet protocol in an
industrial environment, for automation and machine control.
3.2.10 Man Machine Interface
Part of a device which is stipulated for communication between the system of
the device and the user.
3.2.11 On-board Transmission Bus (OBTB)
On-board transmission bus enables the control of the AAS by the board
controller of the Vehicle Board Information and Control System (VBICS).
3.2.12 Short Message Service (SMS)
The Short Message Service (SMS) was originally defined as part of the GSM
series of standards in 1985 as a means of sending "short" (160 characters or
less) messages, most often text messages, to and from GSM mobiles.[
3.2.13 Vehicle Board Information and Control System
Vehicle part of the Automatic Vehicle Monitoring System. VBICS is created by
all devices installed on-board the vehicle which are controlled by the board
computer (controller).
495
496
497
498
Page
22
3.2.14 Wi-Fi
The Wi-Fi is the standard for local wireless nets as specified in the
IEEE 802.11.
499
4. USE CASES
500
The use cases must include triggering.
501
502
5. REQUIREMENTS
503
Content of the Traveller Information for Visually Impaired People
504
505
506
6. XML SCHEMA, KEYWORDS FOR MULTI-LINGUAL
SUPPORT
507
508
509
7. BIBLIOGRAPHY
Page
23

Rapport technique final

Transcription

Documents pareils

FICHE PROJET - Agence Erasmus+ France / Education Formation

Junior Classic Thinsulate Gloves - textil

voir ses utilisations - Consortium provincial francophone

ha10 - CorneilleSima

Thinsulate Gloves - textil

Page 1 of 23 le magazine en ligne du d.day

Information presse

Procès-verbal - Programme de données communautaires