itrace Conception d un réseau de transport en temps réel à Québec présenté à Robert Bergevin et Christian Gagné par Équipe 11 Tacos Engineering

Transcription

1 itrace Conception d un réseau de transport en temps réel à Québec présenté à Robert Bergevin et Christian Gagné par Équipe 11 Tacos Engineering matricule nom signature Éric Bernard Khadija Chaabouni Olivier Dufour Francis Gagnon Daniel Garceau Jonathan Grenier Université Laval 16 avril 2010

2 Historique des versions version date description 28 janvier 2010 Création du document 0 5 février 2010 Élaboration de l introduction et de la description 1 19 février 2010 Élaboration des besoins, des objectifs et du cahier de charges 2 19 mars 2010 Conceptualisation finale 16 avril 2010 Étude préliminaire et concept retenu

3 Table des matières Table des figures Liste des tableaux v vi 1 Introduction 1 2 Description 2 3 Besoins et Objectifs Besoin Module de positionnement Serveur informatique Interface Web Interfaces mobiles Panneaux d affichage Objectifs Transmettre la position de chaque autobus tout le long de son trajet, à une centrale de traitement Traiter et gérer les informations reçues en temps réel Choisir un panneau d affichage pratique et adapté au contexte Créer une interface web Rendre disponible l information aux interfaces mobiles Diagramme des objectifs Cahier de charges Critères, pondérations et barèmes Justification du cahier de charges Module de positionement Période de transmission des données Durabilité Précision Coût Consommation i

4 TABLE DES MATIÈRES ii Volume Température de fonctionnement minimale Température de fonctionnement maximale Serveur Coût Durabilité Vitesse de fonctionnement Nombre de connexions simultanées Capacité de stockage Fiabilité Panneaux d affichage Coût du panneau Dimensions Résistance à la chaleur Résistance au froid Communication avec le serveur Interface Web Navigateur Coût de l implantation Taux de rafraîchissement Quantité maximale de parcours visibles en temps réelle Différence entre la position réelle et virtuelle Interface mobile Vitesse d accès aux données Accès aux bases de données du serveur Coût Taille de l application Recevoir les informations du serveur Affichage pour les écrans mobiles Conceptualisation et analyse de faisabilité Diagramme fonctionel Conceptualisation liée au module de positionnement Définition des aspects liés à la localisation et transmission des données Unité embarqué Oktabox V Owasys Owa22A Condor Tableau Synthèse Conceptualisation liée au serveur Définition des aspects liés à la gestion des données Sun SPARC Enterprise T5440 Server Dell PowerEdge 2950 III Server Dell PowerEgde R900 Server

5 TABLE DES MATIÈRES iii Définition des aspects liés au stockage des données Dell PowerVault MD3000i Network Storage Array Sun Storage 7410 System Sun Storage J4500 Array Conceptualisation liée au panneau d affichage Définition des aspects liés au choix du panneau L AlphaEclipse série 2600 d Adaptative Le GS4600 de Suntronic LED display Screen-P18.75 de VISS Synthèse du choix du panneau Définition des aspects liés aux communications avec le serveur Panneau relié à un ordinateur Panneau indépendant Synthèse des communications du panneau avec le serveur Conceptualisation liée à l interface web Définition des aspects liés au choix de l API internet graphique Microsoft Bing Maps APIs Google Maps APIs OpenStreetMaps Tableau Synthèse Conceptualisation liée à l interface mobile Définitions des aspects du téléphone standard Language WML Language Perl Language PHP Tableau Synthèse Définitions des aspects des téléphones intelligents Développer une application mobile avec Bing Maps Web Services Google Maps Mobile avec Transit Mapquest pour mobiles Tableau synthèse Étude préliminaire Concept de solution Localisation et transmission des données : Owasys Owa22A Gestion des données : Sun SPARC Enterprise T Stockage des données : Sun Storage J4500 Array Choix du panneau : AlphaEclipse Communication des panneaux avec le serveur : panneaux reliés à des ordinateurs API Internet graphique : Google Maps APIs Interface téléphones standards : WML

6 TABLE DES MATIÈRES iv Interface téléphones intelligents : Bing Maps Web Services Concept de solution Localisation et transmission des données : Owasys Owa22A Gestion des données : Dell PowerEdge 2950 III Stockage des données : Dell PowerVault MD3000i Network Storage Array Choix d un panneau : Suntronic GS Communication des panneaux avec le serveur : panneaux reliés à des ordinateurs API Internet graphique : Google Maps APIs Interface téléphones standards : PHP Interface téléphones intelligents : Maps Mobile avec Transit Concept de solution Localisation et transmission des données : Comatis Condor Gestion des données : Dell PowerEdge R Stockage des données : Sun Storage 7410 System Choix d un panneau : Suntronic GS Communication des panneaux avec le serveur : panneaux indépendant API Internet graphique : Bing Maps APIs Interface téléphones standards : Perl Interface téléphones intelligents : Mapquest Synthèse de l étude préliminaire Concept retenu Matrice de décision Description du concept final Volet du module de positionnement Volet serveur Volet panneaux d affichage Volet interface web Volet Interface mobile standard Volet interface mobiles intelligents Annexe A 58 Bibliographie 63

7 Table des figures 3.1 Hiérarchisation des objectifs Maison de qualités Diagramme fonctionel de itrace Application multi-tier Comparaison de la taille des informations téléchargées entre Google Maps 2-3 et Bing Maps Schématisation de notre concept retenu Schéma du fonctionnement d Owasys Owa22A Fonctionnement de Condor Infrastucture de Condor Tableau sur les caractéristiques d oktabox V Tableau sur les caractéristiques du Condor Tableau sur les caractéristiques du système embarqué Owasys Owa22A Suite tableau sur les caractéristiques du système embarqué Owasys Owa22A 62 v

8 Liste des tableaux 4.1 Cahier de charges de itrace Suite du cahier de charges Aspects à considérer pour le module Tableau synthèse du module de positionnement Aspects à considérer pour le serveur Aspects à considérer pour le serveur Aspects à considérer pour le panneau Tableau synthèse du choix du panneau Aspects à considérer pour les communications du panneau Tableau synthèse des communications du panneau avec le serveur Aspects à considérer pour l interface web Tableau synthèse de l interface web Aspects à considérer pour l interface mobile Tableau synthèse de l interface mobile Aspects à considérer pour les téléphones intelligents Tableau synthèse de l interface pour les mobiles intelligents Sommaire des concepts globaux retenus Synthèse de l étude préliminaire Matrice de décision vi

9 Chapitre 1 Introduction Beaucoup de gens choisissent d utiliser le transport en commun, que ce soit par conviction, par commodité ou par nécessité. Dans les villes où la population n est pas suffisante pour justifier la construction d un métro, on opte très souvent pour un réseau d autobus. Ne nécessitant que relativement peu d investissement au niveau des infrastructures et des véhicules, un tel service est un bon compromis favorisant le désengorgement des routes. À Québec, le réseau d autobus RTC (Réseau de Transport de la Capitale) cherche à se servir des nouvelles technologies afin d offrir aux usagers des informations sur le réseau en temps réel. La firme d ingénieur Tacos Engineering a été mandatée par le RTC pour effectuer une conception préliminaire du projet. Le rapport qui suit dresse donc un portrait exhaustif des besoins et objectifs du projet, un cahier des charges, la présentation de quelques solutions, une étude sur la faisabilité du projet ainsi que le concept que nous avons retenus. 1

10 Chapitre 2 Description Afin de toujours améliorer la qualité de ses services, le Réseau de transport de la Capitale, a demandé à une équipe d ingénieurs de développer un système faisant le suivit de ses véhicules en temps réel(itrace). L équipe d ingénieurs a comme mandat de conceptualiser un système qui devra être durable pour un minimum de dix ans et qui satisfera les exigences du clients. Le projet comporte trois objectifs principaux. Le premier est de développer une infrastructure qui fera le suivi des autobus dans le réseau, soit des dispositifs relatifs au positionnement. Ces derniers seront présent dans chaque autobus du RTC et seront alimentés par la batterie de celle-ci. Il a été spécifié que ces dispositifs doivent communiquer les informations à chaque trente secondes ou moins. Il est également question de fournir aux utilisateurs des services du RTC des informations concernant le positionnement des autobus en temps réél sur leurs parcours, les heures de passages aux arrêts estimés (calculées par les serveurs du RTC), etc., via plusieurs plateformes. Les utilisateurs peuvent accèder à ces informations en faisant des requêtes (en fournissant le numero de l arrêt et la ligne d autobus) sur leur ordinateur personnel via une interface web (qui devra fournir une carte géographique sur demande et y afficher les autobus et les arrêts relatifs à la requête du client), sur leur téléphone intelligent via des applications tierces développées à l aide d un API fourni par l équipe (doit fournir un affichage riche en informations avec cartes géographiques comme pour l interface web), sur leur téléphone cellulaire classique doté d un naviguateur WAP (interface web légère et exclusivement textuelle) et à partir de panneaux d affichage à différents arrêts. Ces derniers devront afficher au minimum les deux prochains autobus qui y passeront, avec les temps de passages estimés à trente secondes près et rafraîchis au même temps. Ils seront alimentés sur le réseau électrique d Hydro-Québec. Les informations recueillies par les dispositifs doivent être centralisées et archivées sur un serveur informatique. Ce même serveur doit traiter les requêtes des utilisateurs et fournir de l information aux panneaux d affichages. Finalement, nous allons devoir faire un estimé des coûts de production et de maintenance. Le mandat de l équipe n est que de faire une conception préliminaire pour en estimer la faisabilité et l envergure. 2

11 Chapitre 3 Besoins et Objectifs 3.1 Besoin Module de positionnement Connaître le positionnement en temps réel de chaque autobus à un taux de rafraichissement de 30 secondes maximum Alimenter par la batterie de l autobus Communiquer directement avec les serveurs Serveur informatique Recevoir, manipuler et stocker les données de positionnement des autobus Positionner l autobus géographiquement sur une carte Connaître chaque trajet et chaque arrêt de chaque parcours Transmettre les informations demandées aux applications clientes Interface Web Acquérir le temps de passage estimé par le serveur Proposer aux usagers de l information par arrêt et par parcours Suivre les autobus en temps réel sur une carte Interfaces mobiles Accessible par navigateur web pour les WAP Fournir une interface sans navigateur pour les téléphones intelligents 3

12 CHAPITRE 3. BESOINS ET OBJECTIFS Panneaux d affichage Recevoir, afficher et rafraichir les informations des serveurs aux 30 secondes maximum Afficher au moins les deux prochains temps de passage des autobus de chaque parcours 3.2 Objectifs L anlyse des besoins a permis de dégager cinq objectifs principaux pour ce projet. Ces derniers permettront d aiguiller la réalisation d une solution adaptée. La figure 3.1 présente la hiérarchisation des objectifs Transmettre la position de chaque autobus tout le long de son trajet, à une centrale de traitement Acquérir la position de l autobus avec une grande précision Raffraîchir la position aux 30 secondes maximum Adapter la consommation électrique à la batterie de l autobus Fonctionner aux températures extrêmes Maximiser la durée de vie du système embarqué Minimiser le coût de chaque système embarqué Traiter et gérer les informations reçues en temps réel Communiquer les données aux interfaces clientes Stocker les données Eviter les engorgements Archiver les données et l assurer durant 10 ans Sécuriser les serveurs des intrusions tierces et des pertes de données Prévoir une copie de sûreté Choisir un panneau d affichage pratique et adapté au contexte Avoir une communication fluide avec les serveurs Choisir une taille adaptée du panneau d affichage Résister aux températures extrèmes du Québec Créer une interface web Utiliser une cartographie adaptée Prévoir un module de recherhce d informations par arrêt et par parcourt Assurer la convivialité de l affichage

13 CHAPITRE 3. BESOINS ET OBJECTIFS Rendre disponible l information aux interfaces mobiles Développer une interface pour le navigateur web des téléphones cellulaires standards Développer un API pour les téléphones intelligents Diagramme des objectifs Fig. 3.1 Hiérarchisation des objectifs

14 Chapitre 4 Cahier de charges 4.1 Critères, pondérations et barèmes Fig. 4.1 Maison de qualités 6

15 CHAPITRE 4. CAHIER DE CHARGES 7 Tab. 4.1 Cahier de charges de itrace Critères Pond. Barème Min. Max Module de positionnement 30% Période de s transmission des données Durabilité 6% D(x) = ans Précision 7% P (x) = 1 x - 10m Coût 10% C(x) = 1 x $ Consommation 4% V (x) = 1 x Volume 3% L h l cm Température de C fonctionnement minimale Température de C - fonctionnement maximale 4.2.2Serveur 35% C Coût 7% $ Durabilité ans Vitesse de fonctionnement 10%.28 ln(x 9) 10GHz Nombre de connexions simultanées C Capacité de 8% 150To stockage Fiabilité 10% 0.8 x Panneaux d affichage 10% Coût d un panneau 5% x Dimensions 5% Largeur(cm) Longueur(cm) Résistance à la C - chaleur Résistance au C froid Communications s avec le serveur... suite à la page suivante...

16 CHAPITRE 4. CAHIER DE CHARGES 8 Tab. 4.1 Suite du cahier de charges Critères Pond. Barème Min. Max Interface Web 15% Fonctionelle sur 6% ln(x 2) 3 10 ln8 plusieurs navigateurs Coût de l implantation 3% 50000$ x Taux de rafraîchissement s Quantité maximale de parcours vi- sibles x Erreur dans la 6% 50 position réelle de l autobus 4.2.5Interface mobile 10% Vitesse d accès secondes aux données Accès aux bases de données du serveur Coût 4% 1 x $ x Taille de l application 2% , 5Mo 72, Recevoir les informations du serveur Affichage pour les écrans mobiles 4% x 2 900

17 CHAPITRE 4. CAHIER DE CHARGES Justification du cahier de charges Module de positionement Nous avons attribué 30% des points aux critères concernant le module de positionnement. Pour le fonctionnement du projet en temps réel, le système embarqué doit obtenir la position de l autobus et la transmettre en un laps de temps raisonnable aux serveurs. Le développement du projet est étroitement lié à son bon fonctionnement Période de transmission des données Il est très important que la transmission des données s effectue pour toute la période d activité de l autobus pendant la journée. Il est d autant plus important que durant cette période, le module envoie constamment et régulièrement les renseignements sur la position de l autobus en temps réel. Pour optimiser au maximum le système en temps réel, il faudrait alors obtenir l information sur les autobus à toutes les secondes pour avoir un système idéale. Cependant, il n est pas évident de rafraichir aussi rapidement les données, un temps de rafraichissement maximum de 30 secondes est idéale et un temps plus long serait très insatisfaisant Durabilité L objectif principal du critère de durabilité est d amortir le budget à long terme. Puisque, les composantes matérielles du sytème embarqué ont une durée de vie dépassant la décennie, nous fixons à 10 ans l espérance de vie minimale de l unité de positionnement. L équation qui permet de comparer les concepts pour ce critère est D(x) = 1 10 où la variable x représente x la durée de vie du produit Précision Dans certains parcours mis à une certaine échelle, les arrêts sont adjacents l un à l autre. Cette proximité des arrêts exige une exactitude de la position de l autobus, afin d exploiter au mieux les informations et de les communiquer le plus judicieusement aux interfaces clientes. L équation P (x) = 1 x permet d otenir la valeur du critère. La variable x représente la 10 précision de l autobus à un mètre près, nous voulons que cette précision ne dépasse pas les 10 m Coût La technologie utilisée, pour positionner l autobus et transmettre l information, a une forte influence sur le coût du module de positionnement. Et vu le nombre d autobus qui constitue la flotte du RTC, le coût de chaque système embarqué déterminera en grande partie le budget du projet. En conséquence, une solution offrant un coût inférieur à une autre aura l avantage sur cette dernière. L équation C(x) = 1 x montre que le prix maximum

18 CHAPITRE 4. CAHIER DE CHARGES 10 alloué à chaque module de positionnement ne peut accèder 1000$ par unité soit $ pour toute la flotte d autobus du RTC et que les frais de transmission de données sur 10 ans ne doivent pas excèder $ Consommation Les autobus moderne comporte maintenant beaucoup de composantes électroniques à l intérieur comme à l extérieur de l autobus. Que ce soit pour afficher le numéro de parcours ou le prochain arrêt sur des panneaux d affichage, toutes ces composantes demandent une alimentation constante en courant. Afin de ne pas consommer toute l énergie de la batterie des autobus, il est indispensable que le module de positionnement consomme très peu d énergie pour éviter les pannes ou tout autre ennuie de ce genre. La contrainte utilisée, sera que le système embarqué ne doit consommer qu entre 8V olts et 14V olts de tension nominale Volume Il y a déjà énormément de composante sur le tableau de bord des autobus du réseau de transport, il y a donc un espace restreint pour y implanter le module de positionnement. Afin de ne pas encombrer les passagers ou le conducteur, le volume maximal du module de positionnement est de 6750 cm 3 ce qui lui vaudrait une note de 0 et le volume idéale serait de 2250 cm 3 pour obtenir une note de Température de fonctionnement minimale Les conditions hivernales au Québec sont un facteur important lors de la conception du module de positionnement, puisque celles-ci sont très rude le système doit pouvoir résister aux intempéries de toutes sortes. Comme la température peut descendre sous les zéro, il faut absolument que le module fonctionne jusqu à une température de fonctionnement minimale d au plus -25 C Température de fonctionnement maximale Il faut tout autant penser à une température maximale, même si au Québec les températures n atteignent pas des sommets. Comme le système sera positionné près du moteur de l autobus, en plus d être dans un environnement fermé, celui-ci pourrait venir à surchauffer. C est pourquoi le module de positionnement doit absolument fonctionner jusqu à une température de fonctionnement maximale d au moins 50 C Serveur 35% des points du barème d évaluation iront aux serveurs. Le fait que les serveurs sont utilisés dans presque chaque facette de ce projet explique l importance de cette attribution.

19 CHAPITRE 4. CAHIER DE CHARGES Coût Le prix du serveur est très élevé à l achat, mais nécessaire et comparable au coût du système embarqué des autobus. Un prix inférieur à $ obtient 1 et un prix supérieur à $ obtient Durabilité Comme toutes les autres parties du projet, le serveur doit être en fonction le plus longtemps possible. Il est donc nécessaire de s assurer que tout ce que nous allons utilisé aura une durée de vie minimum de 10 ans. Une durée de vie de moins de 10 ans aura une note nulle et une durée de plus de 20 ans aura une note parfaite Vitesse de fonctionnement Puisque le serveur doit être capable de traiter un très grand nombre de demandes par les clients, les administrateurs et les interfaces en simultané, le serveur doit avoir une très bonne vitesse d exécution. Selon ce que nous avons évalué, une vitesse inférieur à 10GHz mérite une note nulle et une vitesse supérieur à 20GHz mérite une note parfaite Nombre de connexions simultanées On compte plusieurs centaines d autobus et on calcule que chaque autobus va émettre en même temps. Le serveur doit donc gérer une très grande quantité de connexions simultanément. Pour notre design, un nombre de connexions simultanés inférieur à 1100 obtient une note de 0 et supérieur à ce nombre obtient une note parfaite Capacité de stockage La donnée émise par chaque autobus est d environ 40 octets. En tenant compte que chaque autobus transmet environ 2000 fois par jour, on aura besoin d environ 15 To par année pour le stockage à ce jour et une possibilité de 30 To par année. Il nous faut donc un serveur ayant une capacité d au moins 150 To. Une capacité de stockage inférieur à 150 To obtient une note de 0, tandis qu une capacité supérieur à 300 To obtient une note parfaite Fiabilité La fiabilité d un serveur est surtout l uptime. L uptime d un serveur désigne le temps depuis lequel il tourne sans interruption(arrêt ou redémarrage). Nous considèrerons 1 mois comme un temps raisonnable entree 2 interruptions, c est-à-dire 720 heures. Nous devons aussi tenir compte du nombre de défaillances que le serveur peut supporter sans mener à une interruption. La formule utilisé sera donc 0.8 x +0.1y. x sera donc le nombre d heure depuis 744 la dernière interruption et y le nombre de défaillances supportées. Selon cette équation, un système dont l uptime sera de 30 jours vaudra 0, chaque 5 jours supplémentaires ajoutera 0.1

20 CHAPITRE 4. CAHIER DE CHARGES 12 et chacune des défaillances supportées ajoutera 0.1 jusqu à concurrence de 4. Ce critère est un facteur important, donc il vaut 10% Panneaux d affichage 10% des points du barème d évaluation iront aux panneaux d affichage. Le fait que les panneaux ne seront installés qu à quelques arrêts explique le faible pourcentage attribué à cette portion du projet Coût du panneau Bien qu il n y aura pas de panneau à chaque arrêt, le prix de ce dernier est quand même à considérer. L équation suivante (x étant le prix du panneau) décidera de la valeur d un 2000 concept :. Nous estimons que 2000$ est un prix résonnable x Dimensions Il faut que les informations affichées sur le panneau soient assez visibles pour être lue d une certaine distance. Nous estimons que la taille d un caractère devrait être de 5cm 2. Pour l information d un trajet, il faudra afficher le numéro de l autobus, sa direction (indiquée par une flèche) ainsi que l estimation du temps d attente, 15 caractères suffiront. Le panneau devra afficher plusieurs trajets en même temps pour être utile, nous avons fixé ce nombre à 10 parcours avec 2 autobus par parcours. Cela fait un total de 750cm 2. L équation suivante décidera de la valeur d un concept : Largeur(cm) Longueur(cm) Résistance à la chaleur Il peut faire assez chaud à Québec pendant l été, le record s établissant à 35,6 C en juillet 1953[1]. Comme les panneaux seront installés à l extérieur, il faudra qu ils puissent fonctionner à cette température. En se gardant une marge de manoeuvre, nous établissons la température minimum de fonctionnement à 40 C. Un concept qui respectera cette exigence se verra attribuer la note de 1. Le concept sera rejeté s il ne fonctionne pas à cette température Résistance au froid La température la plus froide rescencée à Québec est de C, en février 1962[1]. Il faudra que les panneux puissent fonctionner à cette température. Avec une marge de sécurité, nous établissons la température maximum de fonctionnement à -40 C. Un concept qui respectera cette exigence se verra attribuer la note de 1. Le concept sera rejeté s il ne fonctionne pas à cette température.

21 CHAPITRE 4. CAHIER DE CHARGES Communication avec le serveur Les panneaux devront effectuer des requêtes au serveur à intervalle de 30 secondes. Si un concept respecte cette condition, il se verra attribuer la note de 1. Dans le cas contraire, la note sera Interface Web Navigateur Il est évident que l interface web doit être supportée sur au moins trois navigateurs, c est-à-dire, Internet Explorer pour Windows, Safari pour MacOS X et Mozilla Firefox pour Linux (Windows et Mac OS aussi). Par contre, de plus en plus de surfeurs utilisent Google Chrome ou Opera (souvent mobile pour les PDAs). Il serait nécessaire que l interface soit aussi supportée par ces navigateurs Internet (nous avons attribué une note d environ 0.5 au support de 5 navigateurs). Il existe d autres navigateurs mais ils ne sont que très peu utilisé. Si possible, mais cela ne serait qu accessoire, les navigateurs Internet des principales consoles de jeux vidéo tel la Sony Playstation 3, la Nintendo Wii ou la Microsoft Xbox 600 pourraient être supportée. Voilà pourquoi nous avons attribué une notre de 1 au support de 10 navigateurs. Il est futile de développer une interface web pour plus de 10 navigateurs Coût de l implantation Si nous faisons le choix d utiliser Microsoft Live Maps qui est déjà utilisé pour Trajecto, les couts d implantations ne seront pas très élevé (pas plus de $). Par contre, si nous voulons acheter un API d une autre compagnie ou bien créer notre propre API, les coûts d implantations seront beaucoup plus élevés Taux de rafraîchissement Le taux de rafraichissement de la carte doit être de 30 secondes ou moins. Cela dépend de la fréquence d envoi des positions dans chaque système embarqué. Il peut être intéressant de faire un taux de rafraichissement inférieur à 30 secondes mais il faut tout de même minimiser les transferts de données. Un taux de rafraîchissement inférieur à 5 secondes serait futile, beaucoup trop énergivore pour les systèmes embarqués et saturerait les communications entre le serveur et le client Quantité maximale de parcours visibles en temps réelle Il est primordial d avoir la possibilité de pouvoir afficher un minimum de 5 parcours en temps réel sur les cartes géographiques. Cela permet d afficher tous les autobus pour les utilisateurs désirant 2, 3 ou 4 transferts. Les autobus virtuelles sur la carte doivent pouvoir se déplacer pour simuler la réalité. Plus le nombre de parcours visibles augmentent, plus l utilisateur voit en temps réelle ces possibilités de parcours donc plus l objectif d assurer la

22 CHAPITRE 4. CAHIER DE CHARGES 14 convivialité de l affichage est atteint. Cette contrainte de 5 parcours est primordiale pour offrir plusieurs choix aux clients Différence entre la position réelle et virtuelle Il est évident qu une différence de plus de 50 m entre la position virtuelle de l autobus et la position réelle de cette dernière pourrait nuire au client du RTC. Un client tardif pourrait, par exemple, regarder un certain autobus en temps réelle sur un ordinateur portable et estimer être capable de la prendre mais que cette dernière soit déjà passée. Voilà pourquoi la note de 0 à été attribué a une erreur supérieure à 50 m. Idéalement, pour offrir un meilleur service aux clients du RTC, l erreur devrait tourner aux alentours du 25 m (nous avons attribué une note de 0,5 à cette erreur). En considérant la vitesse de déplacement moyenne des autobus, une erreur inférieure à 5 m serait futile Interface mobile Vitesse d accès aux données Puisqu il s agit d une information en temps réel, il est important que le temps nécessaire pour une requête soit aussi cours que possible, pour assurer que les informations arriveront à temps. L information doit donc être envoyé au client dans un délai d au plus 30 secondes afin que cette information soit juste et utile pour le client. Toute page qui prend plus de 30 secondes sera automatiquement rejeté alors qu une page prenant moins de 30 secondes obtiendra une meilleur note Accès aux bases de données du serveur La page internet créée devra avoir accès aux base de données du serveur du RTC car elle doit pouvoir afficher les informations nécessaires provenant du serveur. Ainsi, tout concept ne pouvant accéder aux informations des base de données du serveur sera automatiquement rejeté Coût Pour obtenir des cartes géographiques sur des interfaces mobiles il faut se procurer un API compatible avec les systèmes de transport en temps réel. Certaines compagnies offrent ce genre d application moyennant des frais d utilisation, tandis que d autres offre gratuitement l API. Il est possible de trouver un compromis entre une sous-traitance avec une compagnie ou la programmation des cartes pour un affichage mobile avec des API gratuits, le budget maximum sera de 10000$. Nous considérons cependant qu il faut diviser se budget en 2 parties, soit pour les téléphones standards et les téléphones intelligents. Il y aura donc 7000$ pour les téléphones intelligents et 3000$ pour les téléphones standards et la note attribuée selon le budget total respectera la formule 1 x Si nous devons considérer les coûts

23 CHAPITRE 4. CAHIER DE CHARGES 15 indépendamment, pour les téléphones standards le barème sera 1 x intelligents le barème sera 1 x et pour les téléphones Taille de l application Comme il y a un espace restreint sur la mémoire des téléphones portable, on doit absolument établir une contrainte maximale pour ce qui est de la taille de l application qui servira aux mobiles d obtenir les informations sur les trajets en temps réels. Avec les applications qui existes déjà on peut déterminer qu une taille maximale pour une application de système en temps réel sera de 8,5 Mo, toute application excédant cette quantité d information se vera attribuer une note de 0 et une note la note sera donnée selon le barème x2 72, Recevoir les informations du serveur Pour optimiser l efficacité et la rapidité liée à un système en temps réel, il doit obligatoirement avoir une communication directe entre les mobiles et le serveur. De ce fait, on peut assurer que l information demandée par le client sera précise et répondra à ses besoins de façon rapide. S il y a une communication entre le mobile et le serveur on attribuera un note de 1, sinon une note de Affichage pour les écrans mobiles Puisque les cartes géographiques sont composées sur des écrans d ordinateurs pour des interfaces web, il faut que les cartes envoyées sur les interfaces mobiles soit d une taille appropriée pour les écrans réduit des mobiles. Il faudra donc choisir un format de fichier adéquat pour une lecture facile par les utilisateurs sur leurs mobiles, sinon la contrainte ne sera pas respectée et le projet rejeté.

24 Chapitre 5 Conceptualisation et analyse de faisabilité 5.1 Diagramme fonctionel Dans ce chapitre, nous observerons différentes solutions ou concepts pour chaque sousproblème. Pour réellement atteindre les objectifs demandés par le RTC et comprendre le problème global d itrace, il faut bien le diviser en sous-problème. Les sous-problèmes de notre problème global sont élaborés dans le diagramme fonctionnel d itrace ci-après à la page. On voit les principales catégories d itrace, c est-à-dire le Module de Positionnement, le Serveur, l interface Web, le Panneau d affichage et les interfaces mobiles. A l intérieur des grands aspects, il y a les sous-problèmes. Le module de positionnement doit pouvoir localiser les autobus ainsi que transmettre des données. Le serveur doit gérer les données et doit pouvoir stocker des données. Dans les clients ont retrouve l interface web, les panneaux d affichages ainsi que les interfaces mobiles. L interface web ne contient qu un sous-problème : un API cartographique d information en temps réel. Pour ce qui est du panneau d affichage, nous faisons face à deux problèmes : communiquer avec le serveur et afficher les informations sur un écran. Finalement, pour les interfaces mobiles, nous avons le problème des téléphones standards et les téléphones intelligents. Les sortants des trois interfaces clients (web, panneau et téléphone) sont des informations sur le temps de passages des autobus. 16

25 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 17 Fig. 5.1 Diagramme fonctionel de itrace

26 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Conceptualisation liée au module de positionnement Définition des aspects liés à la localisation et transmission des données Dans le projet itrace, le module de positionnement constitue la base du système en temps réel, puisque c est ce qui envoie l information désirée par les usagés du RTC. De ce fait, le système de localisation installé dans les autobus devra répondre aux exigences mentionnées par le client dans les objectifs et satisfaire les contraintes du cahier des charges (4.2.1). Le module doit envoyer de l information en un temps bien précis, s assurer que l information envoyée est précise, il doit être composé de matériaux durables et ne pas encombrer trop d espace dans l autobus. Le module de positionnement doit donc être intégré d un système de géolocalisation précis et rapide pour envoyer de l information à toutes les 30 secondes. De plus, il devra convertir adéquatement la source d alimentation fournie par la batterie de l autobus pour assurer un bon fonctionnement et il doit pouvoir résister aux écarts de température de l environnement québécois. Différents concepts seront évalués : Unité embarqué Oktabox V5 Owasys Owa22A Condor Les aspects à considérer pour le module sont dans le tableau 5.1 à la page 18 Tab. 5.1 Aspects à considérer pour le module Type Critères à considérer Contraintes Durabilité 10ans Aspects physiques Précision 10m Consommation 8V x 14V Volume 6750cm 3 Aspects économiques Coût $ Aspects temporels Période de transmission 30sec Aspects environnementaux Température maximale 50 C Température minimale 25 C Unité embarqué Oktabox V5 Caractéristiques [5] Voir le tableau 8.4. L unité embarqué Oktabox V5 peut être utilisé pour diverses applications, comme la géolocalisation de véhicules léger et poids lourds, et la mesure et la remontée de capteurs vers une interface web. Ce système embarqué dispose d un récepteur GPS de haute sensibilité et utilise un modem GSM/GPRS ou GPS/EDGE de classe 10, ce qui apporte une connectivité TCP-IP longue portée et permet l envoie des

27 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 19 données aux 30 secondes. Cette unité se compose d un microprocesseur 32 bits cadencé à 150 Mhz et d un coprocesseur de gestion de périphériques. Décision Ce concept est rejeté Justification Etant donné que des algorithmes de la technologie brevetée d Oktanet, assurent l envoi et la réception de données techniques ou de configuration entre l unité embarquée et le serveur Oktanet. L utilisation de ce dernier contraint le projet à traiter avec un seul fournisseur Owasys Owa22A Caractéristiques [6] Voir les tableaux 8.6 et 8.7. Le système embarqué Owasys Owa22A dispose d un récepteur GPS et d une connexion au serveur distant via un GPRS. Le principe de fonctionnement de l unité embarquée est illustré par la figure 8.1. Ce boitier est programmable sous linux, ainsi, on pourra apporter des modifications pour s adapter aux mieux aux besoins du RTC. La position de l autobus est transmise aux 30 secondes. Et, en cas de perte de la connexion GPRS avec le serveur, dûe à une zone non couverte par l opérateur de téléphonie, le système permet d enregistrer le trajet effectué par l autobus et de le transmettre dès la récupération du réseau. Par conséquent, le RTC dispose d un historique complet de ses autobus. Cette unité permet de fournir une précision de 4m CEP,[7] cela signifie que l erreur entre la position mesurée et la position réelle est inférieure à 4m dans 50% des cas. Le boîtier supporte les températures extrêmes, ainsi il fonctionne entre [-25 C,+60 C]. De plus, le temps moyen entre deux pannes du système (MTBF) n est pas moins de heures soit une durée de vie d au moins 10 ans. Le coût de ce boitier est d environ 650$/Unité et il est garanti durant 24 mois. Néanmoins, il faut prévoir des charges additionnelles comme un forfait pour la transmission de données entre l autobus et le serveur et ce forfait est de 1000$ par mois. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Condor Caractéristiques [8] Voir tableau 8.5. Condor est une infrastructure de radio transmission multi cellules dédiée au transfert de données en temps réel entre des points fixes ou mobiles et un serveur. Elle est constituée d un RFU (Radio Front-end Unit), d un LCU (Location and Communication Unit) et d un CCU (Coputing and Communication Unit). Comme le montre la figure 8.2. RFU C est des station d émission et de réceptions installées en points hauts, qui prennent en charge la transmission de données bidirectionnelle entre les autobus et le serveur et entre les points fixes comme les panneaux d affichage et le serveur. Elles

28 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 20 peuvent être installées de 50 à 100 Km l une de l autre car les faisceaux hertziens numériques» FH1G4 1 permettent de déployer des réseaux de communication privés sur des grandes distances. Les frais de ces stations sont d environ $. Les portées radio peuvent être étendues par la mise en oeuvre de procédures de routage automatique des paquets de données ou par relayages multiples. Alors, la ville de Québec qui a une superficie de 455Km 2, n a besoin que d un réseau constitué de 10 antennes relais vu que la distance entre ces derniers peut varier de 50 à 100 Km. LCU C est un système embarqué dans l autobus, qui se positionne grâce au GPS avec une précision de 2.5m et assure la transmission des données aux 30 secondes entre le véhicule et le serveur. La figure 8.3 schématise le fonctionnement du système. CCU C est une unité de calculateurs installés en liaison avec les panneaux d affichages. La transmission de données par radio est réalisée grâce à un modem intégré aux LCU et CCU, comme le modem FFSK, GMSK ou FSK4L. Pour ce fait, les calculateurs CCU et LCU sont raccordé sur un émetteur-récepteur de type» PMR 2. Comme exemple de performances mesurées sur un réseau PMR : Pour 100, 200 ou 800 véhicules, le cycle de collecte d états de mobiles est respectivement 7, 14 ou 56s. La réactivité de l affichage aux points d arrêt est de 2.5 sec. Le boîtier de Condor résiste aux températures extrêmes, en fonctionnant entre [-40 C,+60 C]. Le coût de ce modèle embarqué est approximé à 800$ l unité. Mais, des frais pour les antennes relais sont à prévoir, pour assurer la couverture de toute la ville de québec. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Tableau Synthèse Voir le tableau 5.2 à la page 21 1 c est des faisceaux hertziens économiques fonctionnant dans les bandes de fréquences 1.4 GHz qui permettent d interconnecter facilement les différents frontaux RFU et le serveur RDC avec des frais d exploitation particulièrement réduits. Soit pour un espacement entre canaux de 75KHz, les frais de licence sont de 450$ annuelle par bond de 50Km. 2 Les réseaux PMR sont largement utilisés par les services de sécurité publique, des secours et les transports publics etc. Ce sont des réseaux privés qui présentent un haut niveau de sécurité, tant en termes de confidentialité qu en termes de qualité de service. Ils sont basés sur des technologies analogiques (MPT 1327, APCO 16...) et basculent aujourd hui de plus en plus vers le numérique (TETRA, APCO 25..).

29 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 21 Tab. 5.2 Tableau synthèse du module de positionnement Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Oktabox Oui Non Oui - Rejeté V5 Owasys Oui Oui Oui - Retenu Owa22A Condor Oui Oui mais Oui - Retenu 5.3 Conceptualisation liée au serveur Dans le projet itrace, le serveur est à la base du traitement et de la sauvegarde des données. Le serveur qui sera utilisé devra répondre aux exigences mentionnées par le client dans les objectif et satisfaire les contraintes du cahier des charges (4.2.2). Le serveur doit être capable de supporter plusieurs connexions simultanées, de stocker les données, de faire tous les traitements de données et d être sécuritaire. De plus le serveur sera divisé en 2, un pour le stockage et l autre pour la réception et le traitement des données Définition des aspects liés à la gestion des données Le serveur doit donc pouvoir recevoir un grand nombre de données à la fois tout en pouvant exécuter toutes les demandes des clients sans être saturé. l uptime du serveur doit aussi être le plus long possible pour être certain que le serveur est en fonction durant toute la période où les autobus sont en fonction. Différent serveur seront évalués : Sun SPARC Enterprise T5440 Server Dell PowerEdge 2950 III Server Dell PowerEgde R900 Server Tab. 5.3 Aspects à considérer pour le serveur Type Critères à considérer Contraintes Durabilité 10ans Aspects physiques Nombre de connexion simultanées 1100 Fiabilité - Aspects économiques Coût $ Aspects temporels Vitesse de fonctionnement 10GHz Aspects environnementaux - -

30 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Sun SPARC Enterprise T5440 Server Caractéristiques [15] Le serveur Sun SPARC enterprise T5440 est un serveur de 2 processeurs UltraSPARC T2 Plus (possibilité de 4) qui possède chacun 8 coeurs de 1.2GHz (ou de 1.4GHz) chacun. C est un serveux avec beaucoup de rededoncance (RAID 0 ou 1) et il est facile de réparation. Il possède *** connexions. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Dell PowerEdge 2950 III Server Caractéristiques [16] Le serveur Dell Power Egde 2950 est un serveur de 2 processeurs à 2 coeurs (possibilité de 4) Intel Xeon série 5200 jusqu à 3,0 GHz (possibilité de la série 5400 jusqu à 3.33 GHz). Sa mémoire vive maximale est de 8 DIMMs de 8 Go pour un total de 64 Go de RAM. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Dell PowerEgde R900 Server Caractéristiques [17] Le serveur Dell Power Egde R900 est un serveur d un processeur à 6 coeurs Intel Xeon série 7400 de 2.13 GHz (possibilité de 2.4 et de 2.66GHz). Sa mémoire vive maximale est de 32 DIMMs de 8Go pour un total de 256 Go de RAM. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Définition des aspects liés au stockage des données Le serveur de stockage doit avoir un espace d entreposage d au moins 150 To pour pouvoir sauvegarder les données que le serveur aura traité et reçu et avoir une durée de vie d au moins 10 ans. Dell PowerVault MD3000i Network Storage Array Sun Storage 7410 System Sun Storage J4500 Array Les aspects à considérer pour le module sont dans le tableau 5.1 à la page 18

31 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 23 Tab. 5.4 Aspects à considérer pour le serveur Type Critères à considérer Contraintes Aspects physiques Durabilité 10ans Capacité 150T o Aspects économiques Coût $ Aspects temporels - - Aspects environnementaux Dell PowerVault MD3000i Network Storage Array Caractéristiques [18] Le Dell PowerVault MD3000i Network Storage Array a une capacité qui n est pas fixe. On peut ajouté de l espace de stockage à volonté. Chaque disque dure a une capacité allant de 500 Go à 2 To. Vu nos besoins élevé de stockage, nous utiliserons ceux de 2To. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Sun Storage 7410 System Caractéristiques [19] Le Sun Storage 7410 a une capacité de 288 To et est beaucoup plus rapide et facile d utilisation. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges Sun Storage J4500 Array Caractéristiques [20] Le Sun Storage J4500 Array est un serveur de stockage qui n a pas de capacité fixe. Celle-ci est variable et offre le plus grande densité offerte. Décision Ce concept est retenu. Justification Ce modèle rempli les critères du cahier des charges.

32 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Conceptualisation liée au panneau d affichage Bien qu ils ne seront pas à chaque arrêt, les panneaux d affichage sont une partie importante du projet itrace. Ils permettront au usagers des terminus les plus achalandés de savoir quand passera le prochain autobus. Pour ce faire, nous avons besoin de deux choses ; la première est un écran sur lequel ont affichera les diverses informations, et la deuxième étant un moyen de communiquer avec le serveur pour avoir quelque chose à afficher. Les panneaux devront respecter les critères de la section ainsi que les objectif de la section Pour ce qui est de l écran en tant que tel, il devra être de dimension suffisante pour afficher plusieurs informations en même temps, la surface d affichage requise a été établit à 750cm Il devra aussi être en mesure de résister aux températures parfois extrême de Québec(de -40 C à 40 C) , car plusieurs seront à l extérieur. Finalement le prix de ces derniers devront être résonnable Voici les concepts proposés : AlphaEclipse Suntronic GS P Au niveau de la communication avec le serveur, les panneaux doivent être en mesure de rafraîchir les information sur le passage des autobus à tous les 30 secondes. Pour ce faire, il faudra qu ils communiquent avec les serveurs du RTC en passant par internet. Deux concepts sont présentés : Panneau relié à un ordinateur Panneau indépendant Définition des aspects liés au choix du panneau Les aspects à considérer pour cette section sont dans le tableau 5.5. Tab. 5.5 Aspects à considérer pour le panneau Type Critère à considérer Contrainte Aspect physique Dimension 750cm 2 Aspect économique Coût - Aspect temporel Aucun critère - Aspect environnemental Température L AlphaEclipse série 2600 d Adaptative Caractéristiques : Les produits AlphaEclipse sont des panneaux d affichage LED à usage extérieur de la compagnie Adaptative. Ce model présente tout les qualitées recherchées[9][10] ; affichage multi-ligne, bonne dimension d écran(la taille du modèle de base est de 40cm par 160cm), température de fonctionnement allant de -40 C à 55 C. Décision : Ce concept est retenu. Justification : Ce concept répond à tous les critères.

33 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Le GS4600 de Suntronic Caractéristiques : Les modèles GS4600 de la compagnie Suntronic[11] sont des écrans ACL à usage extérieur. Il peuvent fonctionner à des températures allant de -40 C à 50 C et résiste à l humidité, la pluie et la poussière. La taille des écrans est aussi très bonne(environ 100cm par 57cm). Décision : Ce concept est retenue. Justification : Ce concept répond à tous les critères LED display Screen-P18.75 de VISS Caractéristiques :Le P18-75 est un écran LED fabriqué par la compagnie VISS. Parmis ses caratéristiques principales[12] ont note une bonne dimension d écran(60cm par 60cm), une température de fonctionnement allant de -35 C à 55 C et un affichage de 16.7 million de couleurs. Bien que la température minimale de l écran soit trop élevée, il serait possible de trouver un moyen pour chauffer le panneau et ainsi permettre l utilisation de ce concept. Décision : Ce concept est rejeté Justification : La température de fonctionnement minimale est trop élevée, mais il serait possible de réchauffer l écran Synthèse du choix du panneau Tab. 5.6 Tableau synthèse du choix du panneau Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Alpha Oui Oui - Oui Retenu Eclipse 2600 GS4600 Oui Non - Oui Retenu P18.75 Oui Oui - Non, mais Rejeté Définition des aspects liés aux communications avec le serveur Les aspects à considérer pour cette section sont dans le tableau Panneau relié à un ordinateur Caractéristiques : Une des solutions pour relier le panneau aux serveurs est de le connecter avec un ordinateur. De cette façon, un programme sur l ordinateur se chargerait de demander / recevoir les données du serveur et les transmetterait au panneau avec un

34 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 26 Tab. 5.7 Aspects à considérer pour les communications du panneau Type Critère à considérer Contrainte Aspect physique Sécurité - Aspect économique Coût - Aspect temporel Périodicité des comm. 30s Aspect environnemental Aucun critère - cable ethernet (ou une connection sans fil pour certain modèle). La taille de l ordinateur n est pas vraiment un problème, car l application nécessaire ne nécessiterait pas beaucoup de puissance : on pourra donc prendre un très petit modèle. Avec la portée des réseaux sans-fils d aujourd hui et le fait que les cables ethernet sont très abordables, l ordinateur pourrait être dans un bâtiment en périphérie du panneau. Cela éliminera ainsi les contraintes au niveau de la température de fonctionnement de l ordinateur. Décision : Ce concept est retenu. Justification : Ce concept répond à tous les critères Panneau indépendant Caractéristiques : L autre solution pour communiquer avec le serveur est de transformer les panneaux en mini-ordinateurs, de sorte qu ils puissent se charger eux-mêmes des requêtes d information. On devra ajouter plusieurs composantes à l écran tel qu un processeur, de la mémoire, une carte réseau, etc. afin que l écran soit une unité indépendante. Il faudrait aussi être certain que chaque élément puissent fonctionner au température ambiante de Québec. Il faut bien noter la hausse du prix et du temps de production que cette solution entraînerait. Décision : Ce concept est retenu. Justification : Ce concept répond à tous les critères Synthèse des communications du panneau avec le serveur Tab. 5.8 Tableau synthèse des communications du panneau avec le serveur Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Ordinateur Oui Oui Oui - Retenu Indépendant Oui Oui Oui - Retenu

35 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Conceptualisation liée à l interface web Définition des aspects liés au choix de l API internet graphique L interface web sera certainement le moyen le plus utilisé par les clients du RTC pour accéder aux informations en temps réelle. Comme mentionné dans la section objectif et les contraintes du cahier de charges (4.2.4), il doit être possible de voir de l information de divers point de vue, c est-à-dire par arrêt et par parcours. L interface doit être intuitive et ces informations doivent se retrouver sur une carte. L interface Web doit donc avoir une banque de donnée vectorielle contenant des cartes géographiques couvrant la ville de Québec en entier et doit être simple. La carte doit offrir la possibilité d afficher des couches d informations supplémentaire. Ces couches permettront bien sûr de voir les autobus et les temps de passages. Actuellement, il existe plusieurs APIs de banque de donnée de carte sur Internet. Les 3 concepts s offrant à nous sont les deux APIs les plus répandu sur internet et l alternative Open source : Microsoft Bing Maps APIs Google Maps APIs OpenStreetMaps Ces trois sous-concepts offrent beaucoup de possibilités et de versatilités. Ils utilisent des interfaces différentes et des informations vectorielles de fournisseurs différents. Les possibilités seront élaborées ci-après. Les aspects à considérer dans l interface web sont dans le tableau 5.9 à la page 27 Tab. 5.9 Aspects à considérer pour l interface web Type Critères à considérer Contraintes Fonctionelle sur plusieurs navigateurs 3 x 10 Aspects physiques Quantité maximale de parcours visibles 5 Erreur dans la position réelle de l autobus 50m Aspects économiques Coût de l implantation 50000$ Aspects temporels Taux de rafraîchissement 30s Aspects environnementaux Microsoft Bing Maps APIs Caractéristiques Comme on peut l observer dans la datasheet de Bing Maps [2], Le "Software Devlopment Kit" de Microsoft Bing Maps offre 4 possibilités d APIs : AJAX, Silverlight, Bing Maps Web Services et MapPoint Web Service. Les "Web Services" de Microsoft Bing Maps offrent seulement une possibilité d afficher des cartes statiques ou déplaçables avec la possibilité de faire une recherche de position. Par contre, cet API implique qu il doit se retrouver dans une page XML et n inclus aucune interface graphique. Tout doit être créé en

36 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 28 entier. Dans notre cas, les APIs les plus appropriés seraient AJAX ou Silverlight. AJAX est multiplateforme, il est donc supporté par les navigateurs suivants : IE6, IE7, IE8, Firefox 2, Firefox 3, Safari 2 et Safari 3. Silverlight à été créé par Microsoft mais il est aussi supporté par Firefox et Safari. Microsoft Silverlight est jeune, il faut donc installé des modules complémentaires sur Mac OS et n est pas supporté sur Linux. Par contre, les APIs AJAX et Silverlight ne sont pas supporté par le téléphone intelligent. Voilà pourquoi il faudra utiliser un API à part pour ces appareils. AJAX ainsi que Silverlight supportent des «couches de tuiles» supplémentaires, qu il faut, bien sûr, programmé à part. L ajout de polygones ou de punaises supplémentaires est supporté autant par AJAX que par Silverlight. Par contre, AJAX donne la possibilité de cacher ces polygones ou ces punaises quand le client demande une vue plus éloignée ou plus rapprochée de la carte. Cela permet de ne pas surcharger la carte et de voir en tout temps les noms de rues ou autres informations géographiques. Présentement, les techniciens du RTC connaisse bien Microsoft Bing Maps utilisant AJAX puisque il l utilise déjà pour Trajecto. Ainsi la banque de donnée d arrêts, de terminus et de parcours à déjà été implanté dans Bing Maps. Cela réduirait de grandement le temps de d implentation et de programmation de l interface web. Trajecto utilise présentement le banque de donnée NAVTEQ pour les information géographiques de la ville de Québec. Décision : Retenu. Justifications Microsoft Bing Maps programmé en AJAX est fonctionnelle sur les 3 navigateurs principaux ainsi que plusieurs versions de ces navigateurs. L ajout de couches supplémentaires, de punaises, de polygones est possible et est optimisé en AJAX. La programmation en AJAX permettra de ne pas surcharger les cartes, comme expliqué ci-dessus. Le cout d implantation ne sera pas très élevé puisque les techniciens du RTC on développé de l expérience avec cet outil. Cela permettra également de réduire le temps d implantation. Pour ce qui est du taux de rafraichissement et l erreur dans la position réelle de l autobus, l AJAX permet de chargé seulement l objet en question dans une page. Ainsi le transfert de données entre le serveur et le client sera plus rapide. Cela réduit l erreur et nous permet aussi de réduire le taux de rafraichissement si désiré Google Maps APIs Caractéristiques Comme nous pouvons le lire sur le FAQ de Google Maps API [3], le Google Maps APIs inclue, en fait, 4 APIs : Google Maps Javascript API, Google Maps API for Flash, Google Static Maps API et Mapplets API. Le Mapplets API est supporté par les téléphones mobiles intelligents comme le téléphone Windows Mobile ou le Apple IPhone. Cela nous permet de réutiliser notre travail pour ces téléphones. De plus, la programmation en flash nous permetterait le support de certaines consoles (comme la Playstation 3). Google Maps Javascript API est celui qui est le plus compatible. Il est supporté par IE 6 ou plus récent, Firefox 2 ou plus récent, Safari 3.1 ou plus récent et aussi Google Chrome. Il

37 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 29 permet la programmation en AJAX également pour optimiser le transfert de donné. Par contre, présentement, le techniciens du RTC on travaillé avec Microsoft et devront apprendre un nouvel API en entier. Décision : Retenu. Justifications Ce modèle rempli tous les critères du cahier des charges OpenStreetMaps Caractéristiques OpenSteetMaps est l alternative open source pour Google Maps et Microsoft Bing Maps. Il est donc gratuit. Google Maps et Bing Maps utilisent des données géographiques provenant de deux compagnies principalement, c est-à-dire NAVTEQ et TeleAtlas. Ainsi Google Maps et Microsoft Bing Maps s affichent gratuit mais certaines données géographiques sont payantes. OpenStreetMaps est entièrement gratuit et peut-être modifié à volonté par n importe qui. Par contre, étant incomplet, il faut parfois ajouter de l information géographique manquant en faisant de l acquisition GPS et en le rajoutant à la communauté OpenStreetMaps. Il faut alors utiliser un éditeur de cartes OpenStreetMaps tel que PotLatch (flash et disponible online sur le site web [4]) ou JOSM en java. Pour ajouter une carte OpenStreetMaps sur son propre site web, deux alternatives principales existent : Web Maps API de CloudMade et OpenLayers, tous deux en JavaScript. C est deux alternatives permettent de faire de la superposition de couches. Par contre, il semble difficile de rajouter une couche d information non fixe (qui se déplace). Il n y a pas de documentation sur ce sujet. Étant Open Source, cela est possible, par programmation, mais beaucoup plus long et ardu. De plus, cette fonction n étant pas officiellement supportée, le temps de rafraîchissement ne serait pas optimisé. Les deux alternatives étant en JavaScript. Il est supporté par tous les navigateurs principaux incluant IE, Firefox, Safari et Chrome. Décision : Rejeté. Justifications L interface Web sera principalement utilisée pour visionner les autobus virtuellement. Il faut absolument pouvoir ajouter une couche qui se déplace sur notre carte et cela est beaucoup plus difficile a développé avec ce concept Tableau Synthèse 5.6 Conceptualisation liée à l interface mobile L interface mobile sera surtout utilisée par les personnes qui veulent accéder aux informations en temps réel sans avoir accès à un ordinateur. Les informations accessible à partir de

38 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 30 Tab Tableau synthèse de l interface web Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Microsoft oui, mais oui oui - retenu Bing Maps APIs Google oui oui oui,mais - retenu Maps APIs Open Street Maps non oui non - rejeté l interface mobile varie selon le type de téléphone mobile utilisé. Les téléphones intelligents utiliseront un API pour avoir accès à l information tandis que les téléphones standard auront seulement accès à une page web simple comme stipulé dans les objectifs (3.2.5) et dans le cahier des charges(4.2.5). L API devra montrer une carte géographique comme l interface web tandis que l interface pour téléphones standards doit afficher seulement l information minimale nécessaire Définitions des aspects du téléphone standard L interface mobile standard doit être reliée à la base de données du serveur qui contient les informations nécessaires pour traiter les requêtes du client. Afin de répondre aux différents critères, l interface doit fournir des informations standards. Plusieurs concepts sont disponibles afin d obtenir une interface fonctionnelle. Principalement, la page WAP créée peut être développée en différents languages de programmation comme : WML Perl PHP Tab Aspects à considérer pour l interface mobile Type Critères à considérer Contraintes Aspects physiques Accès aux base de données du serveur Obligatoire Vitesse d accès des données du serveur 30s Aspects économiques Coût de développement 3000$ Aspects temporels - - Aspects environnementaux - -

39 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Language WML Caractéristiques Le language WML (Wireless Markup Language) est un language de programmation permettant de créer des pages internets en WAP (Wireless Application Protocol). Ce type de page est nécessaire afin d avoir une page lisible sur les téléphones standards qui ne sont pas compatible avec les pages internets ordinaires. Une page écrite en WML est supportée par plusieurs browers. La vitesse d accès des données dépend de la vitesse de la connexion de chaque téléphone, mais pour les téléphones les plus lents, qui ont une vitesse d approximativement 3 Ko/s, nous pouvons supposer que, vu que l information contenue dans la page est surement sous 90 Ko (il s agit seulement d informations concernant le numéro de trajet, le numéro d arrêt et le temps, ce qui prend très peu d espace), le temps d attente sera donc sous 30 secondes. Vu la simplicité d un tel programme, nous pouvons supposé que le coût de création de celui-ci ne dépassera pas les 3000 $. Décision : Retenu. Justification Ce language de programmation rempli les critères du cahier des charges Language Perl Caractéristiques Le language Perl est un language de programmation qui à différentes utilités. L une d entre elles est de pouvoir créer des pages en WML. Le language Perl permet de créer des pages dynamiques en WAP. Une page dynamique est une page qui facilite l interaction avec l utilisateur. En effet, une page dynamique permet un accès plus rapide vers les bases de données du serveur, car la page est contenue directement sur le serveur et créer une sortie en WML. Vu l accès direct au données du serveur, la réponse de celui-ci sera plus rapide. Le coût d implantation sera toutefois très semblable puisque le travail à effectuer n est pas simplifié significativement, le coût ne sera donc probablement pas supérieur à 3000 $. Décision : Retenu. Justification Ce language de programmation rempli les critères du cahier des charges Language PHP Caractéristiques Le language PHP est un language de programmation semblable au language Perl, mais il a été créé spécifiquement pour faire des pages Web, ce qui signifie que le language est mieux adapté pour la création de page Web. Ce language permet de créer des pages dynamiques qui augmente la rapidité de la page créée. La vitesse d une telle page serait très semblable à une page écrite en Perl, vu la similitude de la page ainsi créée. Toutefois, le language étant spécialisé dans la création de page web, le coût d implantation sera moins

40 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 32 élevé. En effet, ce language spécialisé facilite la création d une page web, ce qui permettrait de réduire les coûts de création. Décision : Retenu. Justification Ce language de programmation rempli les critères du cahier des charges Tableau Synthèse Tab Tableau synthèse de l interface mobile Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Nouvelle Oui Oui - - Retenu interface Bing Maps Oui Oui - - Retenu Web Services Définitions des aspects des téléphones intelligents Bien que l interface mobile pour les téléphones intelligents n est pas le moyen le plus courant pour les utilisateurs du RTC afin d obtenir les informations qu ils désirent, celui-ci est en plein développement et bientôt il sera nécessaire d avoir une interface impeccable en raison de la demande croissante à venir. Dans la section objectif et dans les contraintes du cahier des charges (4.2.5) on explique que l interface devra contenir des cartes interactives, un interface facile d utilisation et surtout intuitive, avec toutes les informations disponibles sur l interface web mais d une taille réduite. Certains concepts ont du potentiel pour satisfaire les aspects du tableau 5.13 à la page 33 : Développer une application mobile avec Bing Maps Web Services Google Maps Mobile avec Transit Mapquest pour mobile Développer une application mobile avec Bing Maps Web Services Bing Maps Services[13] offre la possibilité de développer un API pour les téléphones mobiles intelligents. Bing Maps permet aux mobiles d accéder à leur base de références de géolocalisation, ainsi il est possible depuis l application mobile d envoyer des requêtes directement au serveurs pour obtenir des cartes et générer des routes. Il y a différentes options pour relier le téléphone à Bing Maps, soit la connexion s effectue directement entre le mobile et Bing Maps, soit on utilise un serveur pour recevoir et traiter les demande entre le mobile

41 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 33 Tab Aspects à considérer pour les téléphones intelligents Type Critères à considérer Contraintes Recevoir les informations du serveur Obligatoire Aspects physiques Taille de l application 8, 5M o Affichage pour les écrans de mobile Obligatoire Aspects économiques Coût 7000$ Aspects temporels - - Aspects environnementaux - - et Bing Maps, tel que présenté dans la figure 5.2. Cette dernière méthode est plus complexe, mais puisque nous développons déjà un serveurs dans le projet, plusieurs bénéfices pourraient en être tirés. Cette méthode permet de traiter la demande du mobile et d envoyer le minimum d information requise pour le mobile, de ce fait, cela diminue de façon significative la quantité de données envoyées au mobile et permet une plus grande rapidité d exécution de l application. Il est à noté aussi que Bing Maps utilise des fichiers XML, de cette manière, les cartes sont automatiquement ajustées à la taille de n importe quel écran de portable, ce qui est très avantageux. Fig. 5.2 Application multi-tier Décision : Retenu. Justification Bing Maps satisfait bien le cahier des charges, puisque nous cherchions une solution qui offre une communication directe avec le serveur. De plus, le RTC utilise déjà Trajecto qui est généré par Bing Maps, il serait donc facile d adaptation pour les utilisateurs si on utilise le même programme pour la géolocalisation. Cette solution offre aussi une grande rapidité et une taille réduite des informations envoyées en raison de la communication avec le serveur. Ces raisons permettent de retenir cette solution.

42 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ Google Maps Mobile avec Transit Google Maps offre gratuitement à toute entreprise le désirant, la possibilité d ajouter un programme de partenariat pour ajouter les Transit sur les cartes de Google Maps. En fait, Google Maps est gratuit et ne fait que consister en un ensemble de cartes géographiques, il est cependant possible d ajouter sur une autre couche des cartes web des Transit, tel que des parcours d autobus en temps réel. Ce partenariat aussi est gratuit pour les entreprises, il y a par contre beaucoup de programmation à effectuer pour rendre d abord les cartes compatibles à tout système d exploitation. Il est intéressant aussi de mentionner qu avec les téléphones intelligents qui sont muni d un GPS, on augment grandement la vitesse de rafraîchissement des donnés puisque l application positionne automatiquement l endroit du cellulaire sur une carte, obtenant ainsi rapidement toutes les arrêts et parcours les plus proches. Google Maps offre aussi la possibilité à un réseau de transport de se connecter avec son serveur pour afficher les Transit, ou parcours de ses autobus en temps réel, ce qui s avère une grande réussite à Bruxelles pour le partenariat entre Google Maps et la STIB[14]. Décision : Retenu. Justification Google Maps avec Transit serait une bonne solution, puisque c est un service offert gratuitement, il convient tout autant au reste du cahier des charges et des contraintes, puisque l on peut effectuer une connexion avec le serveur l application et le téléphone. Aussi, Google Maps permet déjà à tous les téléphones intelligents et iphone une application pour consulter ses cartes routières, même si les cartes sont en HTP et HTTP, des formats habituels de page web, aucune programmation n est donc nécessaire pour que les cartes s affiche bien sur les écrans de mobiles Mapquest pour mobiles Mapquest est le fournisseur avec la plus grande diversité d API disponible pour créer des applications web utilisant sa banque de cartes géographiques. Comme les API sont disponibles dans 6 encodages différents soit JavaScript, AS3, FUJAX, Java, C++, and.net, il est donc plus facile de trouver un moyen simple de créer l application désiré. De plus, ces API sont offert gratuitement, mais si l on veut des données géographiques de meilleure qualité, une version Prenium payante est disponible avec ActionScript3.0, plutôt que la version gratuite actuelle des cartes de Mapquest avec ActionScript2.0. D un autre coté, si l on veut une application mobile qui offre un système en temps réel, il faut utiliser une version beta qui se relie au serveur du système de transport, ce qui réduit la fiabilité, la vitesse et la durabilité d une telle application. Sinon, les cartes sont disponible en format XML, ce qui s accorde parfaitement aux écrans de tous les téléphones mobiles. Décision : Retenu.

43 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 35 Justification Tous les aspects du concept sont quasiment satisfaits avec Mapquest, il n y a qu au niveau de la connexion avec le serveur qu il y a une certain restriction. Afin de relier le serveur du RTC avec l API, il faudrait utiliser une version beta de Mapquest qui est en plein développement de la gestion des trajets en temps réel, cela empêche d assurer la durabilité et la fiabilité de Mapquest sur les téléphones mobiles. La meilleure solution serait d attendre une version complète, bien que la version beta est viable Tableau synthèse Tab Tableau synthèse de l interface pour les mobiles intelligents Concept Aspects Aspects Aspects Aspects Décision physiques économiques temporels environnementaux Bing Maps oui oui - - retenu Web Services Google oui oui - - retenu Maps Transit Mapquest oui, mais oui - - retenu pour mobiles

44 Chapitre 6 Étude préliminaire Nous élaborerons dans le prochain chapitre différentes solutions globales, soit trois concepts globaux, selon les concepts qui ont été retenu dans la conceptualisation. Cela consiste à expliquer les différentes propriétés relatives à chaque partie d un concept, afin de pouvoir évaluer quelle serait la solution optimale pour notre projet. Le tableau 6.1 divise les concepts selon les idées retenues précédemment dans la conceptualisation. 36

45 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 37 Localisation et transmission des données Gestion des données Stockage des données Tab. 6.1 Sommaire des concepts globaux retenus Concept 1 Concept 2 Concept 3 Module de Positionnement Owasys Owasys Comatis Owa22A Owa22A Condor Serveur Sun Dell Dell SPAQRC PowerEdge 2950 PowerEdge Enterprise III R900 T Sun Storage J4500 Array Dell PowerVault MD3000i Network Storage Array Sun Storage 7410 System Panneau Choix du panneau Suntronic Suntronic AlphaEclipse GS4600 GS Communication au serveur Relié a un Relié a un Panneau ordinateur ordinateur indépendant Interface Web API Internet graphique Google Google Bing Maps Maps APIs Maps APIs APIs Interface Téléphones Interface téléphones standards WML PHP Perl Interface téléphones intelligents Google Bing Maps Maps Mobile Web Services avec Transit Mapquest

46 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Concept de solution 1 Voici la première idée de solution qui sera évaluée et annotée selon des concepts aléatoirement choisis. Pour voir tous les sous-concepts en général, se référer au concept global 1 du tableau 6.1 à la page Localisation et transmission des données : Owasys Owa22A Coût Le coût unitaire du système est de 650$ et il est garantit pendant 24 mois soit une certitude d exploitation d au moins 2 ans. La flotte du RTC est constituée de 529 autobus, donc le coût total des systèmes embarqués à acquérir est de $. Toutefois, il faut prévoir le coût d un forfait téléphonique. Pour la technologie GPRS, la facturation ne se fait plus à la communication, mais au poids de données échangées. Ce forfait est d environ 1000$/mois. Pour une exploitation à l année, l abonnement revient à $/an. Un appel d offre pourrait être soumis pour avoir le meilleur rapport qualité prix avec un des opérateurs de téléphonie de la ville de Québec. Pour une exploitation sur 10ans, le coût de cette solution est de $. Ce critère est évalué avec la formule 1 x, ce qui donne un rendement de Précision La précision permet de minimiser la différence entre la position réelle et la position virtuelle du bus. Ce système offre une précision de 4m. Nous obtenons une côte de 0.6 selon la formule 1 x. 10 Durabilité Le temps moyen entre deux pannes de cette unité est d au moins heures, ce qui assure un fonctionnement d au moins 10ans. De plus, l unité embarquée est garantit durant deux ans. Ce qui assure 12 ans de fontionnement si un problème de manufacture advient dans les deux premières années d oprération. Ce critère est évalué avec la formule D(x) = 1 10, ce qui donne un rendement de x consommation L Owasys Owa22A a une consommation de 8 à 40 Volts selon les besoins. Ce qu il lui vaut, selon la formule 1 x 8, une note de 1. 6 Volume Le volume du système doit lui permettre d être intégré dans l autobus, sans encombrement. Le boîtier de l unité embarqué fait 168mm de Largeur, 35mm d hauteur et 55.25mm de longueur. Ce critère est évalué à l aide de l équation h l L + 1, ce qui donne un rendement de Gestion des données : Sun SPARC Enterprise T5440 Fiabilité C est un serveur très sécuritaire et qui peut supporter un disque dur hors-fonction et continuer de fonctionner à pleine capacité. Ce qui lui vaut une note de 0.64, puisqu il on a estimé une période de trois semaines entre chaque interruption du système.

47 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 39 Coût Pour être le plus économique possible, seulement $ serait nécessaire à l acquisition de ce serveur. On ajoutera 5 000$ pour l entretien de ce serveur. Vitesse de fonctionnement Avec ses deux 8-core de 1.4 GHz, il est plus que suffisant et répond très bien à notre critère de 10GHz. Une note de lui sera attribué Stockage des données : Sun Storage J4500 Array Capacité La capacité peut être variable, mais puisque nous voulons pouvoir stocker les données pendant 10 ans et en supposant que les autobus double, nous aurons besoin de deux de ces serveurs pour un total de 312 To. Supérieur à 300 To, la note accordé est 1. Coût Le coût de ces 2 serveurs est d environ $ installés. On ajoutera 5 000$ pour l entretien de ce serveur. Si on additionne le prix du serveur de gestion et du serveur de stockage, nous obtenons $, ce qui donne une note de Choix du panneau : AlphaEclipse 2600 Pour le choix du panneau d affichage de cette solution globale, nous avons choisit l AlphaEclipse Coût du panneau La série de panneaux AlphaEclipse 2600 sont des écrans LED. Comme cette technologie est relativement nouvelle, les prix sont encore assez élevés. Un écran de base de la série coûte environ 4000$. À l aide de la formule du critère du coût du panneau , 2000 on obtient :. Il en résulte une note de 33% pour le coût de ce panneau, pour un poid final de 1,66% dans le choix de l écran. Dimensions 40cm * 160cm À l aide de la formule du critère de la dimension du panneau , on obtient : 1. Il en résulte une note de 89,5% pour le coût de ce panneau, pour un poid final de 4,48% dans le choix de l écran. Résistance à la chaleur Les écrans de la série AlphaEclipse 2600 peuvent fonctionner à des températures allant jusqu à 55 C. Il n y a donc aucun problème en ce qui concerne les besoins en résistance à la chaleur de cet écran ; besoins énumérés à la section Résistance au froid Les écrans de la série AlphaEclipse 2600 peuvent fonctionner à des températures allant jusqu à -40 C. Il n y a donc aucun problème en ce qui concerne les besoins en résistance au froid de cet écran ; besoins énumérés à la section Au final, l AlphaEclipse 2600 récolte une note de 6,14% sur une possibilité de 10%.

48 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Communication des panneaux avec le serveur : panneaux reliés à des ordinateurs Pour ce concept global, nous avons choisi d utiliser des panneaux reliés à des ordinateurs pour effectuer les communications avec les serveurs du RTC. Cela implique que des ordinateurs situés à proximité(moins de 100 mètres) iront chercher les informations sur les serveurs en passant par l internet Pour ce faire, il faudra d abord un ordinateur. Comme la tâche à réaliser(recevoir des données d un serveur) est très simle et peu coûteuse au niveau de l utilisation du processeur central, on pourra utiliser de très petits ordinateurs ayant des prix modestes. Ensuite, on a besoin d un endroit pour entreposer l ordinateur. Comme le RTC a clairement spécifié que ces panneaux ne seraient situés qu aux arrêts importants, on pourra mettre les ordinateurs dans les bâtiments avoisinants. Il faudra peut-être ajouter un montant pour la location d un espace pour l ordinateur si la compagnie ne possède pas de droits au niveau de l immobilier à proximité. Comme l ordinateur sera de très petite taille, le prix de cette location devrait être minime. Puis, il faut relier l ordinateur à internet. Pour ce faire, nous avons choisi d utiliser des réseaux sans-fils, car des fils pourraient être emcombrant au niveau de l espace physique. Enfin, il faut transmettre les données aux panneaux. Là encore nous avons choisi le sans-fil, car les deux panneaux (voir [9] et [11]) retenus l acceptent. En conclusion, cette solution est utilisable pour le projet API Internet graphique : Google Maps APIs Fonctionelle sur plusieurs navigateurs Google Maps API en AJAX est plus compatible que Bing Maps car il est supporté par Google Chrome. Ainsi ce concept offre des caractéristiques techniques intéressantes. De plus, Google Maps a été programmé pour plusieurs plateformes incluant Blackberry, iphone et Windows Mobile. Il serait aussi possible d ajouter le support d autres navigateurs grâce Google Maps APIs for Adobe Flash. Sachant que le Navigateur de la Console Sony Playstation 3 et la console Nintendo Wii supporte le Flash, il serait facile de faire fonctionner itrace sur ces navigateurs. Cela donne donc 6 navigateurs. La note de 2 1 sera appliquée selon notre barème 3 ln8 ln(x 2). En appliquant la pondération, cela nous donne un résultat de 4 %. Erreur dans la position réelle de l autobus Dans le cas de l interface web, l erreur dans la position réelle de l autobus ne peut être influencée que par la vitesse des transferts d informations entre le serveur et la carte géographique. En effet, si l interface est lente et n optimise pas les échanges d informations, les autobus sur la carte virtuelle seront en retard par rapport à la réalité. Ainsi la connexion Internet de l utilisateur joue un rôle dans ce critère mais aussi la sorte d API utilisé. On sait qu AJAX (pour Asynchronous JavaScript and XML) est une technique de développement WEB qui permet d insérer une application dans une page XML. Cette application reçoit les informations du serveur et l affiche sans avoir à recharger la Page XML

49 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 41 en entier. Ainsi, le transfert d informations est optimisé. On peut dire que c est la même chose pour le Flash : un bon exemple serait YouTube qui charge les vidéos indépendamment de la page web. Un autre facteur influençant l erreur entre la position réelle et virtuelle de l autobus est la taille de l information téléchargée par l API graphique. On peut voir sur le graphique des tests de performance 6.1 de la page 41 que les informations de Bing Maps sont beaucoup plus volumineuses que Google Maps. Fig. 6.1 Comparaison de la taille des informations téléchargées entre Google Maps 2-3 et Bing Maps En calculant que l autobus circule en moyenne à 50 km/h on peut dire qu en approximant que 50 ko (pour Google Maps) prend une seconde à se rendre au client le l erreur maximale sera de : max = 50km/1h = 50km/3600s = 14m (6.1) Cela nous donne une note de 0,72 avec notre barème x et une pondération de 4,32 %. Coût de l implantation Le cout d implantation serait élevé pour ce sous-concept puisque il faudrait engager du personnel ou former le personnel déjà présent pour programmer une interface avec Google Maps. De plus, certaines portions des territoires sont protégées et payantes. Le coût d implantation de l interface web avec Google Maps pourrait monter dans les $ en comptant les dépenses pour le personnel. En appliquant notre barême de x la note franc13 nous donne une pondération de 1 %.

50 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Interface téléphones standards : WML Le concept retenu pour les téléphones standards dans cette solution globale est le langauge WML. Vitesse d accès aux données La vitesse du language WML dépend de la taille de la page créée uniquement. En supposant que la page contienne le moins d informations possibles, c est-à-dire seulement la demande du trajet, de l arrêt et la réponse, la taille des informations envoyées et reçues serait d au plus 30 Ko. Si l on prend comme exemple une connexion internet lente d environ 3 Ko/s, le temps total d attente serait d environ 10 secondes. Toutefois, il faut au minimum deux pages différentes, une pour demander l information au client et l autre pour lui afficher la réponse. La première page ne contient pas l information de la réponse, mais la deuxième page contient la totalité de l information. Ce qui signifie que l on rajoute une page avec les 2/3 de l information environ, ce qui signifie un total de 50 Ko et donc un temps d attente d au plus 17 secondes. Selon le barème du cahier des charges ( ), x2 + 1, la 900 note obtenue est de 0,679 sur 1. Coût Le language WML est un language non spécialisé, c est-à-dire qu il possède plusieurs utilités différentes, mais puisque seule la création d une page WAP nous intéresse, seule cette utilité sera utilisée. La page WAP étant relativement simple, nous pouvons considérer qu il faudra au plus trois semaines de travail pour un programmeur ou encore une seule semaine pour une équipe de programmeurs. Le coût pour ce travail peut donc être estimé à environ 1500 $ Interface téléphones intelligents : Bing Maps Web Services Le premier concept retenue dans une solution globale avec une interface pour des téléphones intelligents est Bing Maps Web Services. Taille de l application Le développement d une application avec Bing Maps Web Services ne génère pas un programme très volumineux. Plusieurs exemples de codes réalisés par microsoft sont disponibles sur internet[13], ce qui permet d avoir une application de petite taille qui n occupera pas tout l espace mémoire des téléphones des clients, puisque le code est déjà bien optimisé. La taille de l application avec Bing Maps Web Services est d environ 3 MB, les cartes géographiques en XML occupent la plus grande partie de la mémoire. Mais en se référant au barème concernant se critère x2 + 1, on obtient une note de 0,875 sur 1, 72,25 ce qui est très bien pour une application de se genre. Coût L utilisation de Bing Maps Web Services est gratuite, il faut tout d abord se créer un compte sur Bing Maps et ainsi on peut obtenir gratuitement les clés nécessaires à la programmation d un API pour les mobiles intelligents. De plus, des exemples de codes sont aussi

51 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 43 disponibles ce qui diminue grandement le coût de conception de l application. En considérant seulement les coûts pour la manoeuvre, le développement de cette application s estime à 2000$ et il n aura pas besoin de mises-à-jour. 6.2 Concept de solution 2 Voici la deuxième idée de solution qui sera évaluée et annotée selon des concepts aléatoirement choisis. Pour voir tous les sous-concepts en général, se référer au concept global 2 du tableau 6.1 à la page Localisation et transmission des données : Owasys Owa22A Coût Le coût unitaire du système est de 650$ et il est garantit pendant 24 mois soit une certitude d exploitation d au moins 2 ans. La flotte du RTC est constituée de 529 autobus, donc le coût total des systèmes embarqués à acquérir est de $. Toutefois, il faut prévoir le coût d un forfait téléphonique. Pour la technologie GPRS, la facturation ne se fait plus à la communication, mais au poids de données échangées. Ce forfait est d environ 1000$/mois. Pour une exploitation à l année, l abonnement revient à $/an. Un appel d offre pourrait être soumis pour avoir le meilleur rapport qualité prix avec un des opérateurs de téléphonie de la ville de Québec. Pour une exploitation sur 10ans, le coût de cette solution est de $. Ce critère est évalué avec la formule 1 x, ce qui donne un rendement de Précision La précision permet de minimiser la différence entre la position réelle et la position virtuelle du bus. Ce système offre une précision de 4m. Nous obtenons une côte de 0.6 selon la formule 1 x. 10 Durabilité Le temps moyen entre deux pannes de cette unité est d au moins heures, ce qui assure un fonctionnement d au moins 10ans. De plus, l unité embarquée est garantit durant deux ans. Ce qui assure 12 ans de fontionnement si un problème de manufacture advient dans les deux premières années d oprération. Ce critère est évalué avec la formule D(x) = 1 10, ce qui donne un rendement de x consommation L Owasys Owa22A a une consommation de 8 à 40 Volts selon les besoins. Ce qu il lui vaut, selon la formule 1 x 8, une note de 1. 6 Volume Le volume du système doit lui permettre d être intégré dans l autobus, sans encombrement. Le boîtier de l unité embarqué fait 168mm de Largeur, 35mm d hauteur et 55.25mm de longueur. Ce critère est évalué à l aide de l équation h l L + 1, ce qui donne un rendement de 0.99.

52 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Gestion des données : Dell PowerEdge 2950 III Fiabilité Il fait partie de la catégorie de serveurs la plus sécuritaire que Dell a jamais conçu, soit les PowerEdge. Ce serveur est très tolérant aux erreurs de disque, il reste parfaitement fonctionnel même avec deux disques durs défaillants. Il reste en fonction en moyenne quatre semaines, ce qui lui vaut une note de Coût Ce serveur coûte environ $, quoiqu il a beaucoup d options qui peuvent faire varier le prix. On ajoutera 4 000$ pour l entretien de ce serveur. Vitesse de fonctionnement C est un serveur qui a un grand nombre d options pour satisfaire nos besoins et contraintes. Tout dépendamment de la puissance et du budget, le serveur peut avoir une vitesse allant de 12 GHz à plus de 26 GHz. Nous prendrons le processeur avec deux quad-core 2.66 GHz. Une note de lui sera attribuée Stockage des données : Dell PowerVault MD3000i Network Storage Array Capacité La capacité de ce serveur est très variable puisque nous pouvons ajouter des disques durs de 2 To à volonté. Pour atteindre la capacité voulue, il nous faudrait 150 de ces disques. De cette manière on atteint exactement 300 To, la note de 1 lui sera attribué. Coût Le coût de ce serveur, qui est en option du serveur de gestion précédemment mentionné, est de $ pour une capacité de 300 To. On ajoutera 5 000$ pour l entretien de ce serveur. Si on additionne le prix du serveur de gestion et du serveur de stockage, nous obtenons $, ce qui équivaut à une note de Choix d un panneau : Suntronic GS4600 Pour le choix du panneau d affichage de cette solution globale, nous avons choisi le Suntronic GS4600. Coût 2000$ Le modèle GS4600 de Suntronic est un écran ACL. La technoliogie est disponnible depuis un bon moment et À l aide de la formule du critère du coût du panneau , 2000 on obtient :. Il en résulte une note de 50% pour le coût de ce panneau, pour un poid final de 2,5% dans le choix de l écran. Dimensions 100cm * 57cm À l aide de la formule du critère de la dimension du panneau , on obtient : 1. Il en résulte une note de 88,4% pour le coût de ce panneau, pour un poid final de 4,42% dans le choix de l écran.

53 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 45 Résistance à la chaleur Le GS 4600 de la compagnie Suntronic peut fonctionner à des températures allant jusqu à 50 C. Il n y a donc aucun problème en ce qui concerne les besoins en résistance à la chaleur de cet écran ; besoins énumérés à la section Résistance au froid Le GS 4600 de la compagnie Suntronic peut fonctionner à des températures allant jusqu à -40 C. Il n y a donc aucun problème en ce qui concerne les besoins en résistance au froid de cet écran ; besoins énumérés à la section Au final, l écran Suntronic GS4600 récolte une note de 6,94% sur une possibilité de 10% Communication des panneaux avec le serveur : panneaux reliés à des ordinateurs Ce concept global utilise des panneaux reliés à des ordinateurs pour effectuer les communications avec les serveurs. Cela à déjà été discuté dans le concept global API Internet graphique : Google Maps APIs Fonctionelle sur plusieurs navigateurs Voir le sous-concept Google Maps APIs du concept global 1. Dans ce concept-ci, le nombre de navigateurs augmenterait, puisque l interface de téléphones intelligents choisi est Google Maps Mobile avec Transit. Google Maps Mobile à été programmé sur 4 platformes principales : Symbian OS (Nokia), Windows Mobile, IPhone OS X et Blackberry OS. Chaque OS ayant chacun leur propre navigateur, cela nous donnerait un résultat de 10 navigateurs supportés. La note de 1 sera appliquée selon notre barème 1 ln8 ln(x 2). En appliquant la pondération, cela nous donne un résultat de 6 %. Erreur dans la position réelle de l autobus du concept global 1. Voir le sous-concept Google Maps APIs Coût de l implantation Voir le sous-concept Google Maps APIs du concept global 1. Le cout d implantation global d itrace serait certainement diminuée, puisque dans ce concept global le même API est utilisé dans l interface mobile. Cela nous donne un cout d implantation approximatif d environ $. Avec le barème, cela nous donne une note de 0,38 et une pondération de 1,14 % Interface téléphones standards : PHP Le concept retenu pour les téléphones standards dans cette solution globale est le langauge PHP.

54 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 46 Vitesse d accès aux données La vitesse du language PHP dépend de la taille des informations utilisées. Toutefois, ce language permet la création de pages dynamiques qui facilitent l accès aux informations du serveur. En considérant la taille des informations envoyées et reçues qui est d environ 30 Ko et en considérant également le fait qu il s agit d une page dynamique (ce qui signifie une seule page qui change selon la requête), nous pouvons supposer que le délai d attente des téléphones les plus lents (3 Ko/s) sera d environ 10 secondes. Selon le cahier des charges ( ), x2 + 1, la note donnée sera de 0,889 sur Coût Le langage PHP est un language spécialisé en programmation web. Le fait que ce langauge soit spécialisé signifie qu il simplifie la création de pages webs. Nous pouvons donc supposer que le temps nécessaire à la création en utilisant ce language est d environ une semaine et demie pour un programmeur seul, ce qui revient à environ 750 $ Interface téléphones intelligents : Maps Mobile avec Transit Le deuxième concept retenue dans une solution globale avec une interface pour des téléphones intelligents est Google Maps Mobile avec Transit. Taille de l application Le format des cartes et le code utilisé pour programmer l API avec Transit n est vraiment pas volumineux, de cette façon on obtient une application d une taille très avantageuse pour les téléphones mobiles qui n occupera pas toute la mémoire. Pour une application de base avec seulement les cartes et les trajets, la taille sera de 1,5 Mo. Ce qui est bien avec les cartes de Google Maps c est que leur format est en JSON et XML, ce qui permet d améliorer la performance de chargement des cartes et ainsi réduire considérablement la taille de l application. Si l on se réfère au barème x2 +1, on obtient une 72,25 note de 0,969. Ce qui est important de mentionner, c est que Google offre plusieurs options quant à la demande des utilisateurs pour améliorer la qualité des API. Alors, si on le désire, on peut rajouter la requête du client par demande vocale, ou bien la localisation directe de l utilisateur sur une carte, ou encore indiquer l itinéraire à pied jusqu au prochain arrêt et bien d autres. Si l on rajoute seulement les 3 options précédentes, on obtient une application d une taille de 3 Mo, ce qui respecte toujours les critères du cahier des charges. Coût Toutes les informations sont disponibles sur internet pour créer des Transit et ainsi un API avec les cartes de Google Maps. De plus tous les outils que recommande Google Maps sont en «open source» et les codes de programmation sont aussi gratuits ce qui réduit considérablement le coût d implantation. Il faut considérer le coût de la manoeuvre qui programmera l API, ainsi que le coût pour effectuer des mises-à-jour du programme, selon l évolution possible des besoins des clients. Ainsi, on considère par exemple le coût si l on veut rendre la position du l utilisateur disponible, avec ou sans GPS, comme fonction dans l application. Ce qui revient à un total d environ 2200$.

55 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Concept de solution 3 Voici la dernière idée de solution qui sera évaluée et annotée selon des concepts aléatoirement choisis. Pour voir tous les sous-concepts en général, se référer au concept global 3 du tableau 6.1 à la page Localisation et transmission des données : Comatis Condor Coût Le coût unitaire du système embarqué est de 800$. La flotte d autobus du RTC compte à ce jour 529 autobus. Soit un total de 529 unités embarquées à acquérir et un coût de $. Le coût unitaire des antennes RFU est d environ $, il faut pévoir les frais d installation pour les dix antennes qui sont estimés à $. De plus, il faut ajouter la licence annuelle pour chaque antenne qui est de 450$. Le coût total d implantation et exploitation de ce système sur 10 ans est de $. Nous obtenons une côte de 0.18 selon la formule 1 x Précision Une précision élevée permet de réduire l erreur entre la position réelle et la position virtuelle de chaque autobus. Ce système permet de localiser l autobus à 2.5m près. Selon la formule de la précision 1 x, nous obtenons une côte de Durabilité Le système embarqué Condor a une durée de vie estimée à 10 ans au minimum, ce qui rempli le critère minimal du cahier des charges. consommation L unité embarquée a une consommation de 8 à 14Volts selon les besoins du client, ce critère est évalué avec l équation 1 x 8 ce qui donne un rendement de 1. 6 Volume Le boîtier Condor fait 120mm de Largeur, 130mm de hauteur et 95mm de longueur. Ce critère est évalué à l aide de l équation h l L + 1, ce qui donne un rendement de Gestion des données : Dell PowerEdge R900 Fiabilité Ce serveur a un système de sécurité avancé, incluant les standards de l industrie Trusted Platform Module (TPM), un port USB barré et un détecteur d intrusion pour protéger des données critiques. Il peut aussi supporter une défaillance de disque dur à la fois sans panne. Puisqu il y a plusieurs dispositifs de sécurité, ce serveur peut rester en fonction durant six semaines, ce qui lui vaut une note de 0.9. Coût Le prix de ce serveur est d environ $, tout dépendant des besoins de l entreprise, puisque le serveur a énormément d options. On ajoutera 2 000$ pour l entretien de ce serveur.

56 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 48 Vitesse de fonctionnement La vitesse de fontionnement doit être de plus de 10 GHz, ce qui nous donne le choix de plus de huit différentes forces du serveur, pouvant atteindre 32 GHz. Celui qui a été retenu pour notre projet à une vitesse de 19.2 GHz, ce qui lui donne un note de Stockage des données : Sun Storage 7410 System Capacité Il a une capacité de 287 To, ce qui est suffisant pour le départ, mais peut devenir un problème si le nombre d autobus double. Ce qui lui donne une note de Coût Le coût est beaucoup plus élevé que nous l aurions cru, environ $. On ajoutera 5 000$ pour l entretien de ce serveur. Si on additionne le prix du serveur de gestion et du serveur de stockage, nous obtenons $ pour l optention de ces serveurs, ce qui donne une note de Choix d un panneau : Suntronic GS4600 Ce concept global utilise le GS4600 de la compagnie Suntronic, modèle déjà évalué à la section Il obtient donc une note de 6,94% Communication des panneaux avec le serveur : panneaux indépendant Pour ce concept global, nous avons choisit d utiliser des panneaux indépendants. Avec ce choix, les panneaux iront chercher eux-mêmes les informations sur les trajets d autobus qu ils désservent. Il faut donc les transformer en mini-ordinateurs, créer un module de communication Pour ce faire, nous devront ajouter les éléments suivants aux écrans choisis ; microprocesseur, mémoire vive, disque dur, périphérique de communication réseau, etc. De plus les panneaux devront être liés en permanence avec le système central afin de pouvoir afficher les informations sur les autobus. Le gros avantage est que les panneaux pourront être situés n importe où. Au niveau des inconvénient de ce mode de communication, on retrouve notamment le fait qu il faut que toutes les nouvelles composantes s adaptent à l écran. Il faudra effectuer beaucoup de modifications à l écran pour qu il puisse fonctionner avec ces pièces supplémentaires, ce qui nécessitera du temps et de l argent. Comme il y aura plusieurs panneaux, un module de communication ayant un prix élevé influencera beaucoup le coût du projet. En conclusion, cette solution est utilisable pour le projet, mais elle augmente grandement le temps de développement et le prix du projet.

57 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE API Internet graphique : Bing Maps APIs Fonctionelle sur plusieurs navigateurs Microsoft Bing Maps en AJAX est officiellement supporté pas les 3 navigateurs principaux, c est-à-dire MS IE, Mouilla Firefox et Apple Safari. Microsoft a fait une tentative de distribution pour Windows Mobile, mais cette version à été abandonnée. Rien n assure que notre interface fonctionnera sur les consoles de jeux vidéo. Cela nous donne donc 3 navigateurs. En appliquant notre barème 1 ln(x 2), cela ln8 nous donne une note de 0 et une pondération de 0 % pour ce critère. Erreur dans la position réelle de l autobus Comme expliqué au sous-concept Google Maps de la page 40, la taille des informations téléchargées par l interface graphique peut augmenter l erreur de la position virtuelle de l autobus. Comme nous pouvons le voir sur le graphique 6.1, la taille des informations totales téléchargées par Bing Maps est de 250 ko. En approximant que 250 ko prend environ 3 secondes à se rendre au client et que l autobus se déplace en moyenne à 50 km/h on peut dire que : max = (50km 3s)/1h = (50km 3s)/3600s = 42m (6.2) Cela nous donne, avec notre barème x ,une note 0,16 et une pondération de 0,96 %. Coût de l implantation En prenant en considération que les techniciens du RTC connaissent déjà Microsoft Bing Maps et que la plupart des sections payantes de Bing Maps ont déjà été achetées, cela diminue grandement les frais d implantations. Le cout d implantation pour Microsoft Bing Maps pourrait monter dans les $. Cela nous donne une note de 0,5 en suivant notre barème. En appliquant la pondération x de 3 %, cela nous donne un pourcentage de 1,5 % Interface téléphones standards : Perl Le concept retenu pour les téléphones standards dans cette solution globale est le langauge Perl. Vitesse d accès aux données La vitesse du language Perl dépend du volume des informations envoyées et reçues. Ce language permet la création de pages dynamiques qui permettent un accès aux informations du serveur plus rapide. En considérant la taille des informations nécessaires qui est d environ 30 Ko et puisqu il s agit d une page dynamique qui permet de créer une page qui se met à jour pour envoyer la réponse plutôt que d avoir à créer deux pages différentes. Nous pouvons déduire que le délai d attente pour les téléphones standards les plus lents qui ont une vitesse d environ 3 Ko/s sera d environ 10 secondes. Selon le cahier des charges ( ), x2 + 1, la note pour ce critère sera de 0,889 sur

58 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE 50 Coût Le language Perl n est pas un language spécialisé, toutefois pour ce concept seule la partie qui permet de créer des pages webs est analysée. La page voulue contient peu d informations. De plus, cette page ne contient que des informations de base, ce qui la rend très simple. En considérant ces informations, nous pouvons considérer que la charge de travail correspond au plus à trois semaines de travail, ce qui signifie un coût d environ 1500 $ Interface téléphones intelligents : Mapquest Le troisième concept retenue dans une solution globale avec une interface pour des téléphones intelligents est Mapquest 4 Mobile Il faut préciser que pour réaliser une communication avec un serveur et offrir un service de localisation en temps réel, cette application n est disponible qu en version beta. Taille de l application Comme il y a plusieurs lacunes dans le code de programmation d une version beta, le code est plus lourd à compiler et il n est pas encore optimisé de façon à offrir un programme de petite taille pour les utilisateurs. La taille d une application avec Mapquest est de 4,2 Mo puisqu il y a encore beaucoup de code qui n est pas otimisé, on respecte tout de même le cahier des charges et selon le barème x2 + 1 on obtient une note 72,25 de 0,756 pour cette application. Coût Mapquest offre gratuitement des exemples de codes pour la programmation d un API, on propose cependant d utiliser des logiciels payant pour concevoir le programme. Heureusement, il y a des alternatives de programmes disponibles en «open source» qui vont pouvoir effectuer la même tâche. Pour ce qui est du coût d implantation, on peut l évaluer à 2000$ Il faut cependant considérer que c est une version beta. De ce fait, il faut aussi évaluer le coût d entretien qui implique des testeurs, des reprogrammeurs et éventuellement la mise en marcher d une version officielle de l application, ce qui s estime à 3500$.

59 CHAPITRE 6. ÉTUDE PRÉLIMINAIRE Synthèse de l étude préliminaire Tab. 6.2 Synthèse de l étude préliminaire Unités Concept 1 Concept 2 Concept 3 Module de Positionnement Durabilité ans Précision m Coût $ Consommation Volts Volume cm Serveur Coût $ Vitesse de fonctionnements GHz Capacité de stockage To Fiabilité x(h) x = 504 x = 672 x = 1008 y(déf.) y = 1 y = 2 y = 1 Panneau Coût $ Dimension cm Interface Web Fonctionnelle sur plusieurs navigateurs navig Coût de l implantation $ Erreur de la position réelle de l autobus m Interface Téléphones Vitesse d accès aux données s Coût $ Taille de l application Mo 3 1,5 4,2

60 Chapitre 7 Concept retenu 7.1 Matrice de décision Cet ultime chapitre est consacré à l analyse de la solution évaluée comme étant la meilleure. Après avoir appliqué notre barème ainsi que la pondération attribuée à chaque critère, nous avons additionné les pourcentages dans la matrice de décision 7.1. Après analyse, nous retiendrons le concept global 2 qui a obtenu la note de 73,5 %. Le premier et le troisième concept on reçu la note de 63,74 % et 52,96 % respectivement. Les sous-concepts retenus sont : Owasys Owa22A Dell PowerEdge 2950 III Dell PowerVault MD3000i Network Storage Array Suntronic GS4600 Panneau relié a un ordinateur Google Maps APIs PHP Google Maps Mobile avec Transit 52

61 CHAPITRE 7. CONCEPT RETENU 53 Tab. 7.1 Matrice de décision pond. Concept 1 Concept 2 Concept 3 Module de Positionnement 30% 17.47% 17.47% 14.02% Durabilité 6% 1% 1% 0% Précision 7% 4,2% 4,2% 5,25% Coût 10% 5,3% 5,3% 1,8% Consommation 4% 4% 4% 4% Volume 3% 2,97% 2,97% 2,97% Serveur 35% 23.72% 29.68% 23.29% Coût 7% 2,1% 5,46% 0,49% Vitesse de fonctionnements 10% 7,22% 7,02% 6,50% Capacité de stockage 8% 8% 8% 7.30% Fiabilité 10% 6,4% 9,2% 9% Panneau 10% 6,16% 6,92% 6,92% Coût 5% 1,68% 2,5% 2,5% Dimension 5% 4,48% 4,42% 4,42% Interface Web 15% 9,32% 11,46% 2,46% Fonctionnelle sur plusieurs navigateurs 6% 4% 6% 0% Coût de l implantation 3% 1% 1,14% 1,5% Erreur de la position réelle de l autobus 6% 4,32% 4,32% 0,96% Interface Téléphones 10% 7,07% 8,32% 6,27% Vitesse d accès aux données 4% 2,72% 3,56% 3,56% Coût 4% 2,6% 2,82% 1,2% Taille de l application 2% 1,75% 1,94% 1,51% Total 100% 63,74% 73,85% 52,96%

62 CHAPITRE 7. CONCEPT RETENU Description du concept final Volet du module de positionnement Le concept final utilise le système embarqué Owasys Owa22A. Ce dernier fusionne les technologies GPS et GPRS. D un côté, le GPS permet de localiser les autobus avec une précision de 4m, cette caractéristique réduit l erreur entre la position réelle et virtuelle offrant plus de clarté aux cartes géographiques de l API internet, ainsi que l erreur sur le temps réel de passage de l autobus. De l autre, le GPRS transmet les données aux serveurs, à une fréquence de 30 secondes via le réseau de l opérateur téléphonique. En outre, l unité embarquée de Cartocom s alimente grâce à la batterie d autobus avec un faible ratio de consommation. Cette spécification limite les contraintes sur la batterie du véhicule. De plus, ce système fonctionne aux températures extrêmes du Québec soit une température minimale de -25 C. Le coût de ce produit est très abordable et les frais de communication sont supportables à long terme Volet serveur Les utilisateurs du RTC pourront compter sur un serveur très performant pour la gestion de leurs requêtes grâce au Dell PowerEdge 2950 III. Le Dell PowerVault MD3000i Network Storage Array est un serveur de stockage en option sur le serveur de gestion mentionné précédemment. Le serveur de stockage est un serveur de type array, ce qui veut dire que la capacité de stockage dépend du nombre de disques durs employés. Puisque chaque disque dur utilisé dans le Dell PowerVault MD3000i Network Storage Array est de 2To, il n est pas nécessaire d acheter 150 de ces disques durs au lancement du projet. Le RTC pourrait acheter une petite quantité de ces disques au lancement et en acheter d autres lorsque le besoin ce ferait sentir. La sécurité de ces serveurs est excellente, ce qui permet au RTC d être en confiance avec l intégrité des données gérées Volet panneaux d affichage Afin de pouvoir remplir le ses fonctions, le panneau d affichage à besoin de deux composantes : un écran et un dispositif pour communiquer avec les serveurs du RTC. La solution finale comprend d abord l écran GS4600 de la compagnie Suntronic. Le modèle GS4600 est un écran à cristaux liquides ayant une surface d affichage d environ 5700cm 2 (100cm / 57 cm). Il est très bien adapté au climat de Québec ; sa température de fonctionnement va de -40 C jusqu à 50 C. Il est aussi imperméable, résiste à la poussière et peut effectuer des communications sans-fil[11]. Ce modèle possède donc toutes les caractéristiques nécessaire pour être utilisé dans le projet Au niveau de la communication avec les serveurs, nous avons choisit de relier l écran à internet par l intermédiaire d un mini-ordinateur et d un réseau sans-fil(le GS4600 supportant ce mode de transmission de données). L ordinateur se chargera d effectuer les requêtes d informations et les transmettra directement au panneau. La machine sera située relativement

63 CHAPITRE 7. CONCEPT RETENU 55 près de l écran, c est-à-dire à l intérieur des limites du réseau sans-fil utilisé. Les opérations nécessaires au fonctionnement du panneau(demander de l information aux serveurs et renvoyer ces données à l écran) sont très peu exigeantes au niveau matériel. Le choix des mini-ordinateurs ne pose donc pas de problème ; n importe quel ordinateur fera l affaire. C est d ailleur pourquoi nous ne suggérons pas de modèle. Tous les éléments seront alimentés par le réseau électrique de la ville de Québec Volet interface web Pour que les clients du RTC puissent visualiser les choix d autobus s offrant à eux, leur position et leur temps de passages, il faut diffuser ces informations sur le web. Notre choix d API Internet graphique est Google Maps API en AJAX. Le cout d implantation est évalué à $ pour la programmation et le maintient. Google Maps en AJAX est un contrôle Java optimisant les transferts de données et permettant d insérer des objets mobiles. Ainsi une couche affichant un icone représentant les autobus du ou des parcours sélectionnés sera ajouté aux cartes de la ville de Québec. Dans la page ou à l intérieur de l API Google Maps, un contrôle supplémentaire pourra être ajouté pour sélectionner les parcours désirés. Ainsi, il sera possible pour l utilisateur d afficher 5 parcours à la fois, ce qui est absolument nécessaire dans le cas ou les transferts sont multiples pour se déplacer en ville. Le taux de rafraîchissement du contrôle AJAX sera synchronisé au module de positionnement des autobus, c est-à-dire, aux 30 secondes. Cette page web sera supportée sur les quatre navigateurs principaux : Internet Explorer, Mozilla Firefox, Apple Safari et Google Chrome. De plus en utilisant Google Maps Mobile avec Transit, cette page XML pourra être redirigée sur l application mobile à la détection d un navigateur de téléphone intelligent grâce aux informations UAProf (User Agent Profile), c est-à-dire les informations donnant le nom du navigateur mobile, la version du navigateur mobile ainsi que système d exploitation mobile. Il pourra être possible d utiliser Google Maps en Flash par après pour ajouter le support de la Nintendo Wii ou de la Sony Playstation Volet Interface mobile standard Comme tous languages permettant une sortie WAP, la vitesse de la page internet créée par une page codée en language PHP dépend de la quantité d informations envoyées et reçues. Le language PHP est un language côté serveur, ce qui signifie que la page est codée sur le serveur et qu elle possède un accès direct aux informations contenues sur celui-ci. Cette caractéristique permet de minimiser la quantité d informations nécessaires à envoyer et à recevoir puisque lorsqu une demande est faite au serveur, il n est pas nécessaire de renvoyer les informations déjà envoyées. Autrement dit, ces nouvelles informations peuvent se rajouter à la page en cours qui est dynamique. Ensuite, le language PHP est un language spécialisé en page web. En effet, le language PHP possède plusieurs fonctionnalités qui lui sont propre et qui permettent la facilité de création des pages internets. Cette spécialisation facilite la création et l implantation de la page internet, ce qui permet de réduire les coûts relatifs à ces aspects.

64 CHAPITRE 7. CONCEPT RETENU 56 L utilisation d un language spécialisé qui permet la création de pages internets dynamiques augmente l efficacité de la page et la simplicité de la création Volet interface mobiles intelligents Pour développer un API d un système de transport en temps réel disponible sur les mobiles intelligents, on peut utiliser les cartes de Google Maps. Pour obtenir des informations selon les trajets des différents autobus, Google offre la possibilité de rajouter des couches sur ces cartes avec Transit. Cette application gratuite de Google permet de superposer des couches différentes en même temps sur les cartes pour obtenir les informations nécessaires sur les trajets en temps réel. Tous les outils sont disponibles sur leur site internet[21] pour créer les différentes routes avec Transit, ainsi qu un programme de partenariat entre Google et les entreprises pour permettre une liaison à un serveur. Une fois que Transit fonctionne, un peut appliquer pour une demande de partenariat avec Google, ce qui permettra une liaison au serveur qui pourra traiter les demandes des utilisateurs, sélectionner les Transit à afficher sur la carte et puis les renvoyer aux clients. Il est a noté que lors de la programmation des différents Transit, c est-à-dire des multiples parcours d autobus en temps réel, nous pourrons nous référer à l API internet graphique qui utilise déjà toutes les coordonnées des autobus. Ce qui permettra de sauver un temps énorme quand à la localisation géographique de chaque autobus pour créer un Transit. Ainsi nous obtiendront une application de localisation en temps réel des autobus du RTC pour les téléphones intelligents. Il faut finalement considérer le vieillissement de cette application. Les diverses applications d aujourd hui offrent beaucoup de fonctionnalités et la notre est plutôt de base. Mais cela n est pas un problème, parce qu avec Google Maps Mobile on peut facilement mettre à jour notre application pour satisfaire les utilisateurs désirent une application plus complète. Il y a plusieurs exemples de ce qu on peut ajouter, on pourrait reprogrammer l application de sorte à permettre une localisation instantanée du client et ainsi lui donner les directions vers l arrêt le plus près. Ou encore permettre la requête vocale et bien d autres pour que l application puisse répondre aux besoins changeants des utilisateurs.

65 CHAPITRE 7. CONCEPT RETENU 57 Fig. 7.1 Schématisation de notre concept retenu