itrace : information en Temps réel sur le Réseau d Autobus CollEctif

Transcription

1 itrace : information en Temps réel sur le Réseau d Autobus CollEctif Rapport de projet - version finale présenté à M. Robert Bergevin et M. Christian Gagné par Équipe 09 Équipe N œuf matricule nom signature Sébastien Audet Stéphane Caron Hubert Cartier Gabriel Plante David St-Pierre Maxime Tremblay Université Laval 16 avril 2010

2 Historique des versions version date description #0 21 janvier 2010 Création du document #1 5 février 2010 Description du projet: ajout des chapitres 1 et 2 #2 19 février 2010 Besoins et cahier des charges: ajout des chapitres 3 et 4 #3 19 mars 2010 Conceptualisation et analyse de faisabilité: ajout du chapitre 5 #4 16 avril 2010 Étude préliminaire et concept retenu: mise à jour des chapitres 1 à 5, ajout des chapitres 6 et 7

3 Table des matières Table des figures Liste des tableaux v vi 1 Introduction 1 2 Description 2 3 Besoins et objectifs Analyse et résumé des besoins Analyse des objectifs Définition et hiérarchisation des objectifs Cahier des charges Pondération et barèmes des critères Justification du cahier des charges Dispositif embarqué Vitesse de transmission Précision du positionnement Température Coût Consommation d énergie Serveur Nombre de requêtes par seconde Capacité de stockage Fiabilité Coût Consommation Panneaux d affichage Vitesse de réception des données Surface Température Durée de vie i

4 TABLE DES MATIÈRES ii Coût Maison de la qualité Conceptualisation et analyse de faisabilité Diagramme fonctionnel Dispositif embarqué Serveur Traiter les données géographiques Google Maps, Maps API Premier ERSI Canada, ArcGIS - SIG Serveur Rendre disponibles les services pour les appareils mobiles Communications HTTP XML-RPC Gérer les données Microsoft SQL Server MySQL Oracle Stocker les données Dell PowerEdge R CybertronPC Quantum XS1020 1U Rackmount Server Acserva ARSO-2N5510 All Purpose Rackmount Server Gérer le serveur Web Internet Information Services (IIS) Apache nginx (prononcé Engine X) de Igor Sysoev Gérer le serveur Distributions de Linux Microsoft Windows Server 2008 R FreeBSD Concepts de serveurs Concept Concept Concept Panneaux d affichage Types d affichage Afficher les données aux utilisateurs TF-20, de Barco (écran à diodes électroluminescentes) imotion 52 Double Face Portrait, d Infinitus (écran à cristaux liquides standards) Protéger les panneaux d affichage Réception des données à afficher aux utilisateurs Dispositif de réception Dispositif de réception

5 TABLE DES MATIÈRES iii Dispositif de réception Concepts pour les panneaux d affichages Concept Concept Concept Étude préliminaire Concepts retenus Concept Description Dispositif Embarqué : CTM-15x Serveur : Concept Panneau d affichage : Concept Concept Description Dispositif Embarqué : 2000MGP GPS Tracker Serveur : Concept Panneau d affichage : Concept Concept Description Dispositif Embarqué : Digi M Serveur : Concept Panneau d affichage : Concept Synthèse des résultats Matrice de décision Interprétation des résultats Concept retenu Présentation du concept retenu Documentation et spécifications Dispositif embarqué Serveur Panneaux Estimation des coûts Dispositif embarqué Serveur Panneaux Total Bibliographie 51 A Liste des sigles et des acronymes 55

6 TABLE DES MATIÈRES iv B Illustrations 57 C Carcactéristiques détaillées 63

7 Table des figures 3.1 Diagramme de contexte Hiérarchisation des objectifs Maison de la Qualité Diagramme fonctionnel B.1 CTM-15x B.2 DIGI B.3 ET101B B.4 Dell PowerEdge R B.5 CybertronPC Quantum XS1020 1U Rackmount Server B.6 Acserva ARSO-2N5510 All Purpose Rackmount Server B.7 imotion 52 Double Face Portrait B.8 TF B.9 Vue arrière du TF-20 et du dispositif de fixation v

8 Liste des tableaux 4.1 Pondération et barèmes des critères Aspects à considérer en fonction des critères et des contraintes établis aux chapitres 3 et 4 pour le système embarqué Analyse des concepts pour le dispositif embarqué Aspects à considérer en fonction des critères et des contraintes établis aux chapitres 3 et 4 pour le serveur Caractéristiques de IIS Caractéristiques du Serveur Web Apache Analyse des concepts pour le serveur Aspects à considérer pour les panneaux d affichage en fonction des critères et des contraintes établis aux chapitres 3 et Comparaison de différents types d affichage, où les caractéristiques sont évaluées de manière qualitative : faible ( ), moyen(ne) ( ) et élevé(e) ( ). De plus, la colonne Décision indique si la solution est acceptée ou rejetée Caractéristiques du TF-20, de Barco Caractéristiques du imotion 52 Double Face Portrait, l entreprise Infinitus Diverses solutions pour la protection des panneaux d affichage Analyse des concepts pour le serveur Synthèse de l étude préliminaire Matrice de décision Concepts retenus C.1 Caractéristiques de MySQL C.2 Caractéristiques de Oracle C.3 Caractéristiques de nginx C.4 Caractéristiques de Microsoft SQL Server C.5 Caractéristiques de Linux C.6 Caractéristiques de Microsoft Windows Server 2008 R C.7 Caractéristiques de FreeBSD vi

9 Chapitre 1 Introduction Le transport en commun est un pas de plus vers une planète plus verte. Ce type de transport a plusieurs avantages, par exemple l économie d argent pour les usagers 1, la diminution des émissions de gaz à effet de serre et la baisse de la circulation routière pendant les heures de pointe. Le Réseau de transport de la Capitale (RTC) souhaite améliorer les services offerts à ses usagers et augmenter sa clientèle. Le RTC a mandaté l équipe N œuf afin de créer un système qui permet la localisation de son parc d autobus afin de pouvoir donner des estimations réalistes des heures de passage des autobus, en temps réel. Notre mandat est d effectuer une conception préliminaire d un tel projet. Nous avons choisi une solution pour calculer les estimations réalistes des heures de passage des autobus et rendre ces informations disponibles sur des panneaux d affichage aux principaux arrêts et sur les appareils mobiles. La section suivante explique d abord une description de ce que le RTC veut exactement et comment cela pourrait influencer sa clientèle et la qualité de ses services. Ensuite, la méthodologie employée tout au long du projet pour produire les différentes solutions envisageables sera décrite sommairement. Nous avons fait une analyse détaillée de tous les résultats sous plusieurs aspects afin de pouvoir les comparer aisément. Le rapport de recommandation se termine en présentant la solution ayant obtenue la plus haute note, celle qui s impose pour améliorer le service du Réseau de transport de la Capitale. 1 En comparaison avec l achat d une automobile. Celui-ci implique divers frais (en plus du coût de l automobile) tels que l immatriculation, le stationnement, l essence et l entretien, par rapport à l achat d une vignette mensuelle du RTC. 1

10 Chapitre 2 Description Le Réseau de transport de la Capitale (RTC) souhaite avoir à sa disposition un système permettant de faire un suivi en temps réel des autobus de son réseau. C est pourquoi notre équipe a été mandatée par celui-ci afin d effectuer une conception préliminaire de ce projet afin de l en informer de sa faisabilité et d évaluer les coûts. Les utilisateurs pourront accéder aux services par différents moyens, notamment aux arrêts par des panneaux d affichage alimentés au réseau électrique, par le Web et par cellulaires réguliers ou intelligents. Pour chaque trajet et chaque arrêt, le RTC souhaite que les temps de passage estimés pour les deux prochains autobus soient précis à trente secondes près et disponibles par chacun de ces moyens avec un rafraîchissement aux trente secondes. Diverses options intéressantes seront d ailleurs offertes via le Web et téléphones intelligents, notamment des requêtes par arrêt et des cartes géographiques incluant le positionnement des autobus. Pour ce qui est des téléphones conventionnels, une interface texte sera disponible. Le tout se fera à l aide du serveur informatique qui recevra, traitera et conservera l information de positionnement transférée aux trente secondes par un dispositif embarqué branché à la batterie de l autobus. Le serveur devra aussi coordonner le tout en traitant les requêtes des clients, en transmettant les données de positionnement aux panneaux d affichage et en s occupant du positionnement sur les cartes. Globalement, le système permettra au RTC d avoir à sa disposition une meilleure vue d ensemble en temps réel de son réseau. Dans le cas le plus optimiste, le réseau doublera sur dix ans. Cette possibilité de doublement devra être considérée et le système devra être fonctionnel pour une période minimale de dix ans. 2

11 Chapitre 3 Besoins et objectifs 3.1 Analyse et résumé des besoins Tel que mentionné plus haut dans ce document, notre équipe a été mandatée dans le but d effectuer une conception préliminaire d un système permettant la localisation des autobus en temps réel pour le réseau du RTC, notamment en utilisant un dispositif embarqué et un serveur, ainsi qu en fournissant les données de temps de passage obtenues sur une interface Web, sur des interfaces mobiles (cellulaires intelligents et conventionnels) et sur des panneaux à certains arrêts. Afin de se dotter d une vue d ensemble des besoins du client, nous avons produit le diagramme de contexte présenté à la figure 3.1. Ce diagramme réflète les interactions importantes entre les différentes composantes permettant de répondre aux besoins du client. Les demandes d informations qui circulent entre les serveurs informatiques et les interfaces utilisateurs consistent en des temps de passage estimés pour les arrêts, les positions des autobus et des cartes géographiques. Dans la suite de cette section, nous présenterons les objectifs déterminés par notre équipe qui permettront d aboutir à cette fin Analyse des objectifs 1. Dispositif embarqué : (a) Établir la position des autobus du réseau en temps réel ; (b) Transmettre régulièrement les informations de positionnement au serveur ; (c) Alimenter le dispositif ; (d) Limiter le coût des dispositifs pour l ensemble du réseau. 2. Serveurs informatiques : (a) Recevoir les données de positionnement des autobus et les traiter ; i. Estimer, pour chaque trajet, le temps de passage à chaque arrêt pour les deux prochains autobus à trente seconde près. 3

12 CHAPITRE 3. BESOINS ET OBJECTIFS 4 (b) Conserver les données relatives aux déplacements des autobus ; (c) Associer les données de positionnement avec des données géographiques ; i. Positionner les autobus en temps réel sur des cartes ; ii. Sur ces mêmes cartes, associer les temps de passage avec les arrêts et les trajets. (d) Transmettre les données de positionnement aux panneaux d affichage ; (e) Traiter les requêtes réalisées par les clients par l intermédiaire de l interface Web, d un téléphone intelligent ou d un téléphone conventionnel ; (f) Limiter les coûts d implantation des serveurs. 3. Panneaux d affichage : (a) Afficher les données de positionnement aux arrêts importants ; (b) Alimenter les panneaux sur le réseau électrique ; (c) Limiter le coût des panneaux d affichage. 4. Interface Web : (a) Fournir une interface Web pour ordinateur ; i. Afficher les données de positionnement ; ii. Traiter les données pour la visualisation cartographique. (b) Interfaces mobiles ; i. Fournir une interface pour téléphones intelligents ; A. Afficher les données de positionnement ; B. Traiter les données pour la visualisation cartographique. ii. Fournir une interface pour téléphones conventionnels (WAP). 5. Besoins généraux : A. Afficher les données de positionnement dans une interface texte. (a) Prendre en compte un éventuel doublement du réseau ; (b) Assurer une utilisation pour une période minimale de 10 ans ; (c) Limiter les coûts d opération pour une période de 10 ans. 3.2 Définition et hiérarchisation des objectifs Nous présentons ici la hiérarchisation des différents objectifs.

13 CHAPITRE 3. BESOINS ET OBJECTIFS 5 Fig. 3.1 Diagramme de contexte Autobus Informations de position Arrêts principaux Temps de passage estimés Serveurs informatiques Demandes d'informations Informations demandées Interfaces utilisateurs Ordinateurs des utilisateurs Téléphones cellulaires (WAP) Téléphones intelligents Conception préliminaire itrace Implanter un dispositif embarqué dans chaque autobus Mettre sur pied un Serveur informatique Implanter des panneaux d affichage Concevoir une interface Web Concevoir une interface pour téléphones mobiles Établir la position des autobus Recevoir les données et les traiter Estimer le temps de passage à chaque arrêt pour les 2 prochains autobus Afficher les données aux arrêts importants Fournir une interface Web pour ordinateurs Fournir une interface pour téléphones intelligents Transmettre les données au serveur Conserver les données Associer les données avec des données géographiques Alimenter les panneaux d affichages Afficher les données de positionnement Afficher les données de positionnement Alimenter le dispositif Limiter les coûts d'implémentation des serveurs Associer les temps de passage avec les arrêts et les trajets Limiter le coût des panneaux d'affichages Traiter les données pour la visualisation cartographique Traiter les données pour la visualisation cartographique Limiter le coût des dispositifs Transmettre les données de positionnement aux panneaux d'affichages Positionner les autobus sur des cartes Fournir une interface pour téléphones conventionnels (WAP) Traiter les requêtes des différentes interfaces proposées Afficher les données de positionnement dans une interface texte Fig. 3.2 Hiérarchisation des objectifs

14 Chapitre 4 Cahier des charges 4.1 Pondération et barèmes des critères Tab. 4.1 Pondération et barèmes des critères Critères d évaluation Pond. Barème Min Max Dispositif embarqué 35% Vitesse de transmission (kbps) Précision du positionnement (m) 10% V V % Température ( C) 6% Coût($) 6% Consommation d énergie (W) 3% Serveur 35% Nombre de requêtes par seconde (requêtes/s) Capacité de stockage (Go) P P 15 1 Tmax 50 (( ) + ( T min T min 30, 50 T max 150 C C 1000 P P 25 12% Nr Nr % X X )) Suite à la page suivante (T min ), 50(T max )

15 CHAPITRE 4. CAHIER DES CHARGES 7 Tab. 4.1 (suite) Critères d évaluation Pond. Barème Min Max Fiabilité (nombre de disques durs) 6% N 2 0 N Coût($) 6% X X Consommation (W) 3% P P Panneau d affichage 30% Vitesse de réception (kbps) 6% V V Surface (cm 2 ) 8% A A Température ( C) 8% 1 Tmax 50 (( ) + ( T min T min 40, 50 T max )) -40(T min ), 50(T max ) Durée de vie (années) 4% t t Coût($) 4% C C Justification du cahier des charges Dispositif embarqué Le dispositif embarqué, comme son nom l indique, est un système intégré dans les autobus du RTC. Ce dispositif permet de transmettre les coordonnées de positionnement de l autobus. Une pondération de 35% lui est accordé dû à son rôle essentiel au sein du projet Vitesse de transmission Le RTC souhaite avoir, pour chaque arrêt et chaque trajet, un rafraîchissement aux trente secondes du temps de passage des deux prochains autobus. Il est donc impératif que le dispositif embarqué envoie les données au serveur à l intérieur d un délai raisonnable. C est pourquoi nous accordons 10% à ce critère, car il revêt une importance cruciale dans le processus de traitement des données envoyées par les autobus de tout le réseau. Nous estimons qu une

16 CHAPITRE 4. CAHIER DES CHARGES 8 vitesse de transmission d au moins 25kbps est appropriée en raison de la faible quantité de données à envoyer. Une telle vitesse permettrait un délai raisonnable tout en respectant pleinement le délai de transmission limite. Cependant, nous avons jugé que le même pointage devrait être accordé aux valeurs situées entre 25kbps et 50 kbps et que toutes les valeurs au-delà de 1500kbps recevraient un pointage de 1. Ce barème est donc caractérisé par V 50, 1450 où V est la vitesse de transmission du dispositif embarqué au serveur (en kbps) Précision du positionnement La précision du positionnement possède son importance, c est pourquoi nous lui accordons également 10%. La distance entre les arrêts pouvant être relativement courte, une certaine précision minimimale est donc nécessaire. Cependant, une trop grande précision n est pas non plus essentielle dans le cadre du projet. L important, à notre avis, est que l utilisateur et le RTC aient une bonne idée de l emplacement de l autobus en temps réel. Nous estimons donc que le dispositif devrait fournir une précision d au moins 15 mètres. Nous prenons donc P +15 la formule afin de déterminer le barème, où P est la précision (en mètres) du dispositif Température Quoi que le dispositif ne sera pas directement à l extérieur, celui-ci devra avoir une certaine résistance au froid hivernal du Québec, ainsi qu une certaine résistance aux températures les plus chaudes de l été. Nous accordons une certaine importance à ce critère, car si le dispositf est brisé en raison de la température, il devra être remplacé, ce qui engendrerait des coûts et un système non fonctionnel. L équation 1 Tmax 50 (( ) + ( T min 30 )) permet de bien évaluer ce critère où T min et T max sont les températures minimales et maximales supportées (en degrés Celcius). Si le dispositif ne supporte pas 50 C ou -30 C, il sera automatiquement rejeté. Nous jugeons qu un disposif supportant des températures au-delà de 150 C ou au-dessous de -50 C ne devrait pas être considéré comme meilleur étant donné les températures du Québec. L importance de ce critère est établie à 6% Coût Le dispositif sera fabriqué en de très nombreux exemplaires. Nous accordons donc une certaine attention au coût total de chaque dispositif embarqué, puisque le coût total du projet en sera affecté. De plus, le client demande de prendre en considération la possibilité, dans le cas le plus optimiste, d un doublement du réseau. Le barème du coût du dispositif embarqué est défini par C+1000, où C est le coût unitaire d un dispositif (en $). Nous jugeons qu une 1000 importance de 6% devrait être accordée à ce critère Consommation d énergie Le dispositif devra être branché sur la batterie de l autobus. Il doit donc consommer peu d énergie afin de ne pas entraver les autres fonctionnalités de l autobus. Plus la puissance P +25 utilisée sera faible, mieux ce sera. Elle peut donc être associée à la valeur donnée par, où 25

17 CHAPITRE 4. CAHIER DES CHARGES 9 P est la puissance consommée par le système embarqué (en Watts). Ce critère ne devrait pas vraiment constituer un problème, il servira simplement à comparer les différents dispositifs au niveau énergétique, c est pourquoi nous lui accordons moins d importance, c est-à-dire 3% Serveur L information sur le positionnement est envoyée du dispositif embarqué au serveur, qui gère les données Nombre de requêtes par seconde Les données devront être traitées rapidement, car celles-ci arriveront toutes au même moment. Le serveur devra être capable de recevoir, d interpréter et d envoyer toutes les données qui entrent à l intérieur de trente secondes. Le traitement des données étant le rôle principal du serveur, le nombre de requêtes par seconde nous apparaît donc comme le critère le plus important pour le serveur et c est pour cette raison qu une importance relative de 12% lui est accordé. Le barème associé à ce critère est estimé à Nr 2000, où Nr est le nombre 3000 de requêtes par seconde (requêtes/s). Nous jugeons que le nombre de requêtes par seconde maximum se situerait à environ 2000, puisque le RTC, après un doublement du réseau, aurait 1100 autobus et nous prenons pour acquis qu au maximum 900 usagers feraient une requête simultanément. Nous pensons qu un traitement inférieur à 15 secondes, soit la moitié de l intervalle de mise à jour sur les plate-formes de communication usagers-serveurs (panneaux d affichage, interface mobile et interface web), représenterait une vitesse de traitement idéale. Une pondération de 12% est accordée à ce critère Capacité de stockage Une importante quantité de données devra être gérée et stockée. Le RTC possède actuellement 4587 arrêts[1] ; le client requiert qu un doublement du réseau soit supporté par le système, soit quelques 1100 autobus. De plus, les informations émises par les autobus ont une taille estimée de 80 octets. Celles-ci consistent en ces éléments, transmis et/ou calculés à toutes les trente secondes, qui devront également être emmagasinés : Date Heure Données de positionnement (latitude et longitude) Numéro du trajet Numéro de l autobus En tenant compte de ces valeurs, on calcule donc la capacité requise comme ceci : (1100 autobus) (80 octets) (( )périodes de 30s/an) = 86 Go en arrondissant, qu on porte à 100Go afin de parer aux imprévus. Il est raisonnable de penser que le double de cette estimation serait une capacité idéale, permettant clairement une marge de manoeuvre généreuse pour l entreposage des données. En multipliant cette valeur par dix, on obtient les

18 CHAPITRE 4. CAHIER DES CHARGES 10 capacités pour dix ans. Ainsi, une capacité de stockage de 1000 Go équivaut à une note de 0, tandis qu une capacité de 2000 Go représente une note de 1. La note pour le barème de la capacité de stockage est alors donnée par X 1000, où X est la capacité de stockage (en Go) L importance relative de cet élément est 8% Fiabilité Le RTC souhaite conserver ses données pour une période minimale de 10 ans. Une éventuelle perte des données due à des bris matériels est donc à prévoir. C est pourquoi nous avons choisi que ce critère valait la peine d être évalué. Si un serveur permet de mieux prévenir les pertes de données, il doit être considéré comme meilleur. Nous évaluons ce critère par le nombre de disques durs pouvant être brisés (N) sans perte de données, car pour répondre aux besoins du client, l important est que les données restent disponibles. La formule N est donc 2 utilisée, avec des valeurs de N allant de 0 à 2. Nous jugeons qu au-delà de deux, le concept en question ne devrait pas recevoir un résultat plus haut que un, car il est peu probable que trois disques durs brisent en même temps ou qu aucun des disques durs ait pu être remplacé. Une pondération de 6% est accordée à ce critère Coût Les coûts reliés au serveur demeureront assez raisonnables, c est pourquoi nous leur accordons une importance moindre. Le barème du coût du serveur est donné par X où X est le coût du serveur en dollars. La valeur minimale est donc de 5000$ et la valeur maximale de $. Nous accordons une importance de 6% au coût du serveur Consommation Ce critère concerne un aspect écologique, un aspect technique et un aspect économique du système. Il faudrait que le serveur consomme peu d énergie pour éviter le gaspillage d énergie. De plus, une grande proportion de l énergie dépensée par un serveur informatique est consommée en production de chaleur qu on doit alors évacuer, ce qui requiert une fois de plus de l énergie. Les bénéfices d une faible consommation sont donc multiples : un tel serveur est plus écologique, économique et logique. Nous croyons qu un serveur qui consomme au maximum 200 W serait suffisamment efficace tandis qu un serveur qui consomme au maximum 800 W gaspille trop d énergie. Voici la formule qui décrit le mieux les valeurs précédentes : P Cette formule est valide pour le domaine de 200 W à 800 W. L importance relative de cet élément est 3% Panneaux d affichage Les panneaux permettront d afficher les temps de passage aux arrêts importants. Ce volet étant important pour l ensemble du projet, nous lui accordons une importance de 30%.

19 CHAPITRE 4. CAHIER DES CHARGES Vitesse de réception des données Pour que les panneaux affichent des temps réalistes, il faut que ceux-ci aient une bonne réception des données. Idéalement, il faudrait, tout comme pour le dispositif embarqué, que la vitesse de réception soit d environ au moins 25 kbps. Nous accordons donc 6% d importance à ce critère. La formule pour ce barème est caractérisé par V 50, où V est la vitesse de 1450 transmission du serveur aux panneaux en kbps pour le domaine 50 V Surface Les panneaux étant situés aux arrêts pour fournir des données, ces données nécessitent d être facilement lisibles, donc de dimensions suffisantes à une bonne lecture. Nous estimons qu un écran de dimensions de 100 cm par 150 cm serait une surface idéale ( cm 2 ), ce qui veut dire que nous estimons que des dimensions supérieures à celles-ci ne devraient pas être considérées comme meilleures. De plus, nous estimons que 50 cm par 75 cm seraient des dimensions minimales respectables (3 750cm 2 ). Les panneaux devraient permettre aux utilisateurs de lire rapidement l information qu ils recherchent, sinon ceux-ci perdent leur utilité. C est pourquoi nous accordons une certaine importance à ce critère (8%). Le barème de la surface est donné par A , où A est la surface (en cm2 ) Température Les panneaux étant à l extérieur, ils devront être résistants au froid hivernal et aux journées chaudes de l été du Québec. Le fait d avoir des panneaux disfonctionnels en hiver serait une absurdité pour la province, ce pourquoi une certaine importance est donnée à ce critère. De plus, si le panneau est brisé en raison de la température, il devra être remplacé. Cela entraînerait des coûts et l insatisfaction de plusieurs utilisateurs. L équation 1 Tmax 50 (( ) + ( T min 40 )) permet de bien évaluer le critère. Nous jugeons que les panneaux devraient être résistants au moins à -40 C et 50 C. De plus, un panneau supportant des températures au-delà de 250 C ou au-dessous de -200 C ne devrait pas être considéré comme meilleur étant donné les températures du Québec. Nous accordons une importance de 8% à ce critère Durée de vie Nous jugeons important que les panneaux aient une bonne durée de vie, car des réparations et le remplacement engendrent des coûts importants (pour plus de détails, voir la section ). Les panneaux devront être fonctionnels pour une durée de 10 ans, tel qu exprimé par le client. Nous estimons que les panneaux devront être fonctionnels pendant au moins 3 ans et dans le meilleur des cas, 10 ans ou plus. Cette estimation prend en compte l usure normale des écrans et ne tient pas compte des facteurs externes à leur fonctionnement (vandalisme, conditions climatiques extrêmes, etc). Donc, la durée de vie des panneaux peut être traduite par la formule t 3 7 afin de déterminer le barème, où t est le temps (en années) écoulé depuis

20 CHAPITRE 4. CAHIER DES CHARGES 12 la mise en marche du système. L importance de la durée de vie des panneaux est établie à 2% Coût Les dépenses liées à l achat des panneaux constitueront une part importante de coût total lors de la réalisation du projet. Nous fixons une pondération de 2% à ce critère. Évidemment, un coût plus faible donnera une note plus élevée à ce critère. Étant donné que la taille du panneau n est pas fixée à priori, celui-ci peut autant être de dimensions réduites ou imposantes. Nous avons évalué qu un panneau de taille importante pourrait coûter jusqu à dollars, ce qui représentera une note de zéro pour ce barème. Nous avons donc déterminé la formule suivante pour ce barème : C, où C est le coût unitaire d un panneau d affichage (en dollars). 4.3 Maison de la qualité

21 CHAPITRE 4. CAHIER DES CHARGES 13 Dispositif embarqué Serveur Panneaux d'achage Collection des données Utillisation des données Infrastructure Vitesse de transmission Précision du positionnement Serveur Recevoir les données et les traiter Conserver les données Associer les temps de passage avec les arrêts et les trajets Positionner les autobus sur des cartes Estimer les coûts d'implémentation des serveurs Transmettre les données de positionnement aux panneaux d'achages Traiter les requêtes des diérentes interfaces proposées Interface Acher les données de positionnement Web Traiter les données cartographiques Cellulaires Fournir une interface intelligents Acher les données de positionnement Traiter les données cartographiques Cellulaires Fournir une interface WAP Acher les données de positionnement en texte Panneaux Acher les données aux arrêts importants d'achage Alimenter les panneaux d'achages Estimer le coût des panneaux d'achages Dispositif Établir la position des autobus embarqué Transmettre les données au serveur Alimenter le dispositif Estimer le coût des dispositifs V 25 D 15 Température -20 T 50 Coût Consommation d'énergie P 25 Nombre de requêtes par secondes N 2000 Capacité de stockage X 1000 Fiabilité N 2 Coût Consommation d'énergie Vitesse de réception V 25 Surface Température Durée de vie Coût Tmin -30, Tmax 50 1 Fig. 4.1 Maison de la Qualité

22 Chapitre 5 Conceptualisation et analyse de faisabilité 5.1 Diagramme fonctionnel Le diagramme fonctionnel de la figure 5.1 définit le problème dans son ensemble. En fait, celui-ci permet d obtenir graphiquement un résumé complet des fonctions des composantes, donc des sous-problèmes déterminés et à considérer, ainsi que des intrants et des extrants du système. Pour ainsi dire, le diagramme fonctionnel permet de faire les liens entre ces différents éléments d une manière visuelle. Les différentes directions que prennent les flux de données y sont illustrées afin d obtenir une meilleure perception globale. Un tel diagramme s avère très utile pour l analyse de faisabilité. 5.2 Dispositif embarqué Le dispositif embarqué constitue une partie importante du projet, c est pourquoi nous lui avons accordé une pondération de 35%. En effet, celui-ci a un rôle clé : il est responsable d établir la position de l autobus, puis de traiter et transmettre ses données au serveur afin d évaluer le positionnement dans le temps d un autobus en particulier. Ces différents sousproblèmes seront tous traités par un même concept. Évidemment, le dispositif embarqué devra respecter les critères et les objectifs déterminés aux chapitres 3 et 4. Nous présenterons donc ici trois concepts que nous avons jugés dignes d analyse : 1. CTM-15x (EV-DO, CDMA) 1 ; 2. Vehicle GPS Tracker ET101B (GSM) 2 ; MGP GPS Tracker (GPRS, SMS) 3 ; 4. Digi M100 (ORBCOMM connection satellite orbite terrestre basse (LEO)) 4. À noter que chacun des concepts offre des options supplémentaires non demandées par le RTC. Ceci dit, ces options ne seront donc pas considérées lors de l évaluation du concept 14

23 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 15 Diagramme Fonctionnel - Établir la position des autobus en temps réel - Traiter ses données - Transmettre ses données au serveur Dispositif Embarqué Légende Sens des données Sous-Problèmes Serveur - Traiter les données géographiques - Rendre disponibles les services pour les appareils mobiles - Gérer les données - Stocker les données - Gérer le serveur Web - Gérer le serveur Interfaces mobiles Interface Web Panneaux d affichage - Afficher les données - Protéger le panneau d affichage - Recevoir les données Fig. 5.1 Diagramme fonctionnel

24 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 16 Type Critère à considérer Contrainte Aspect physique Consommation d énergie (W) 25W Délai de transmission (kbps) Précision du positionnement (m) Température ( C) 50kbps 15m (T min ) -20 C, 50 C (T max ) Aspect économique Coût ($) Aucun Aspect temporel Aucun Aucun Aspect environnemental Aucun Aucun Tab. 5.1 Aspects à considérer en fonction des critères et des contraintes établis aux chapitres 3 et 4 pour le système embarqué. et seront simplement disponibles si jamais, au cours des années futures, le RTC souhaite améliorer son système. De toute façon, en général, ces options n influent que moindrement sur le coût final. Le tableau 5.1 résume, pour le système embarqué, les sous-problèmes déterminés dans le diagramme fonctionnel (Fig. 5.1) et les aspects à considérer en fonction des critères et des contraintes établis aux chapitres 3 et Modem cellulaire CTM-15x (EV-DO, CDMA) Description : Le premier concept est celui d utiliser le modem cellulaire CTM-15x. Celui-ci, via une option GPS intégrée, peut déterminer l emplacement de l autobus. Le GPS intégré peut rafraîchir la position de l autobus à toutes les deux secondes (délai maximum en mode opératoire régulier). Pour ensuite traiter les données, le modem utilise le logiciel TRANSCOM qui permet, entre autres, de choisir l adresse de destination de transfert des données. La transmission des données peut donc s effectuer, par la suite, du modem au serveur du RTC. Les communications sont facturées à la quantité de données transférée [3][4][5][6]. Afin d effectuer la transmission de données, le CTM-15x utilise le réseau cellulaire EV- DO (Evolution-Data Optimized), qui est en fait une technologie normalisée permettant la transmission de données sans fil. La technologie EV-DO utilise plusieurs techniques, dont le CDMA (Code Division Mutiple Access) et le TDMA (Time Division Multiple Access), afin d optimiser l ensemble du réseau. L EV-DO est présentement utilisé, entre autres, par plusieurs fournisseurs de téléphonie. Le CTM-15x est aussi compatible avec le CDMA standard [7][8][9]. Décision : Ce concept est retenu. Justification : Avec une précision de cinq à huit mètres, un débit maximum de 500mA

25 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 17 à 12V (6W) 1, un excellent délai de transmission grâce à la technologie EV-DO de 300kbps à 500kpbs, une longévité accrue grâce au respect des normes militaires 810F ainsi qu une résistance à la température allant de 30 C à 65 C en mode opératoire et de 40 C à 75 C lorsqu il n est pas en mode opératoire, ce dispositif conviendrait parfaitement aux besoins du client. Le prix pour le CDM-15x est de 1200$. Il est impératif d ajouter les frais d un abonnement mensuel de communication (500MB de données) qui vaut 34,00$/mois ou 4100$ sur une période de 10 ans 2. On obtient donc un prix de 5300$/unité pour 10 ans. Malgré le coût élevé de ce modem cellulaire, nous le retenons tout de même [10]. 2. Vehicle GPS Tracker ET101B Description : Le second concept est celui d utiliser le Vehicle GPS Tracker ET101B afin de déterminer l emplacement de l autobus, via une option GPS intégrée, puis de transférer ces données par le réseau GSM (Global System for Mobile Communications) vers le serveur. Le réseau GSM est le réseau le plus utilisé en ce moment à travers le monde [15]. Ce dispositif, au coût de 190$US, a comme dimensions centimètres. Il fonctionne sur un débit de 110mA à 12V et a une puissance de 1,32W 3. Pour des températures estivales, le GPS prendra une seconde à se connecter et pour des températures hivernales 35 secondes. La précision du positionnement est d au maximum ±10m et ce jusqu à une altitude de pieds. L envoi des données peut se faire aussi souvent qu on le souhaite en programmant le temps désiré en secondes. Sur le réseau GSM, le délai de transfert s avère être entre 70kbps et 284kbps. La transmission et la réception des données se font à l aide d une antenne GPS et d une antenne GSM. Celles-ci doivent être installées soit à l intérieur sur une vitre ou à l extérieur [11][12][13][14][16][17][18]. Décision : Ce concept est rejeté. Justification : Le dispositif n est pas adapté pour le climat du Québec MGP GPS Tracker (GPRS, SMS) Description : Le troisième concept que nous avons analysé est le 2000MGP GPS Tracker. Il s agit d un modem tout-en-un avec un logiciel de contrôle intégré permettant le choix de l adresse de destination pour l envoi des données de positionnement obtenues par technologie GPS. Le 2000MGP est conçu afin de laisser une grande flexibilité d utilisation. Il est à la fois complet, simple et ajustable. Le module de la compagnie Mighty GPS utilise la technologie GPRS (General Packet Radio Service) (et si voulu SMS Short Message Service) afin de transmettre ses données. Le GPRS est une solution dérivée du GSM permettant un plus haut débit de données. La différence principale est que le mode de transfert se fait en paquets plutôt que comme un circuit établi pour toute la durée de la communication [20][21]. 1 P=VI=12 x 0,5= 6W 2 Nous sommes entrés en contact avec Réjean Ouellet, un agent de la compagnie du fournisseur du modem cellulaire CTM-15x. Cette personne ressource nous a confirmé le coût du modem ainsi que les frais mensuels liés à son utilisation. 3 P = VI = 110 x 0,012 = 1,32W

26 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 18 Concept de solution A. phys A. temp A. éco A. enviro Décision CDM-15x (EV-DO, CDMA) Oui N/D Oui N/D Retenu Vehicle GPS Tracker ET101B Non N/D Oui N/D Rejeté 2000MGP GPS Tracker Oui N/D Oui N/D Retenu Digi M100 Oui N/D Oui N/D Retenu Tab. 5.2 Analyse des concepts pour le dispositif embarqué Décision : Ce concept est retenu. Justification : Le 2000MGP ne dépense que 0, 2W en mode d opération et permet une précision de positionnement allant de 1 à 5 mètres. De plus, il ne coûte que 299$US et la compagnie offre des rabais lors de l achat de plusieurs unités. La technologie GPRS permet une délai de transmission d environ 128kbps. La température de fonctionnement du 2000MGP s avère être entre 30 C et 70 C [19][22]. 4. Digi M100 (ORBCOMM connection satellite orbite terrestre basse (LEO)) Description : Le troisième concept que nous avons analysé est le Digi M100 (Fig. B.2). Ce modem satellite intelligent peut générer la position de l autobus par GPS pour ensuite l envoyer par connection satellite (ORBCOMM connection satellite orbite terrestre basse (LEO)) au serveur du RTC. Le transfert de données se faisant via satellite, une meilleure couverture, ainsi qu une meilleure fiabilité du réseau sont disponibles. La compagnie fournissant le modem offre en option un logiciel de développement permettant de personnaliser les applications du modem. Le coût du modem est de seulement 139$US, mais il faut tout de même prendre en compte les frais mensuels comparables aux frais reliés aux forfaits cellulaires pour de faibles transferts de données machine-à-machine. Décision : Ce concept est retenu. Justification : Le Digi M100 consomme 21,6W, envoie les données à 57,6kbps, offre une précision de positionnement de 11 mètres dans le pire des cas et est très bien adapté aux températures du Québec avec une tolérance allant de 40 C à 85 C en mode opératoire. Le côut, mentionné plus haut, est très acceptable [23][24][25]. L analyse des concepts pour le dispositif embarqué, comme on peut le constater à l aide du tableau 5.2, trois concepts pour le système embarqué sont retenus. Il ne reste donc qu à déterminer lequel répondra le mieux aux besoins du client. 5.3 Serveur Le serveur est le cœur du projet. Nous avons attribué 35% de la pondération totale est accordée au serveur de données. Ce dernier est ce qui fait que le projet fonctionne ou

27 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 19 Type Critère à considérer Contrainte Aspect physique Capacité de stockage (Go) 1000Go Nombre de requêtes par seconde 2000 Aspect économique Coût ($) Aucun Aspect temporel Aucun Aucun Aspect environnemental Aucun Aucun Tab. 5.3 Aspects à considérer en fonction des critères et des contraintes établis aux chapitres 3 et 4 pour le serveur. échoue puisqu un mauvais traitement des données rend ces dernières inutilisables. Une fois les données du système embarqué traitées et stockées sur le serveur, nous devons nous assurer que celles-ci soient accessibles rapidement par les différentes interfaces, mais les processeurs disponibles à notre époque sont largement capable de répondre à la demande. L interface Web, l interface mobile (téléphones intelligents et WAP) ainsi que les panneaux d affichage aux principaux arrêts découlent directement du serveur Traiter les données géographiques Les données géographiques doivent être traitées pour être jumelées à des carte, afin d afficher la position des autobus en temps réel. Voici deux solutions qui vont traiter les données géographiques, respectivement, sur les serveurs d une tierce entreprise et sur ceux du RTC : 1. Google Maps (version API Premier), de Google Inc. [58] ; 2. ArcGIS (version Serveur), de ESRI Canada [57] Google Maps, Maps API Premier L utilisation de Google Maps API Premier permet à tout hôte de site Web d incorporer aisément des cartes interactives Google Maps à son site web public ou interne. Cette API permet de suivre des représentations visuelles de tous dispositifs qui envoient des données régulièrement au serveur. Cette application offre plusieurs avantages nécessaires tels que : Intégrez des cartes au contenu sécurisé grâce au protocole https ; Effectuez un suivi de l utilisation au sein de plusieurs domaines ; Contrôlez l affichage des publicités sur les cartes ; Bénéficiez des services et options d assistance aux entreprises ERSI Canada, ArcGIS - SIG Serveur La solution de ERSI Canada inclut une suite logicielle qui facilitent la gestion, l intégration et la visualisation des données sur un serveur propriétaire. Tel que mentionné plus haut, il

28 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ 20 s agit en fait d une solution de type tout-en-un qui agit comme le système de traitement des données et sur le serveur du RTC. Cet ensemble offre plusieurs avantages, tels que : Réduction des coût grâce à la centralisation des données ; Accès au SIG à partir de n importe quel navigateur ; Possibilité de créer des applications personnalisées à l aide de.net ou de Java ; Gestion, intégration, visualisation des données à l aide d interfaces conviviales Rendre disponibles les services pour les appareils mobiles Communications HTTP Les interfaces de programmation (API) destinées aux téléphones intelligents feront des requêtes HTTP par connexion Internet TCP vers le serveur afin d obtenir les données. Il s agit d une option couramment utilisée et compatible avec tous les systèmes d exploitations des téléphones intelligents. Le coût de développement sera également convenable, étant donné que cette solution est répandue XML-RPC XML-RPC permetterait aux utilisateurs (les téléphones intelligents) d invoquer des commandes sur le serveur. Le serveur recevrait ces commandes avec paramètres et renvoierait alors le résultat aux utilisateurs. Les commandes (RPC) sont décrites dans une structure XML elle-même encapsulée dans une communication HTTP Gérer les données La section suivante présente les trois solutions que nous avons identifiées pour gérer les données sur le serveur. Ces solutions sont des systèmes de gestion de base de données, aussi appelés SGBD. Nous ne jugeons pas nécessaire de présenter le stockage sous forme de fichiers, car cette solution est complètement dépassée et parce qu elle ne permet pas d écrire plusieurs informations simultanément. Voici les trois solutions pertinentes : 1. Microsoft SQL Server ; 2. MySQL ; 3. Oracle Microsoft SQL Server 2008 Description : La première solution est d utiliser un SGBD Microsoft SQL Server Le tableau C.4 contient les caractéristiques de cette solution [34]. Décision : La solution est acceptée. Justification : La solution répond à aux besoins du client même si elle est un peu dispendieuse. Le SGBD est aussi seulement compatible avec un système d exploitation de Microsoft, ce qui restreint le choix de système d exploitation.

29 CHAPITRE 5. CONCEPTUALISATION ET ANALYSE DE FAISABILITÉ MySQL Description : La deuxième solution est le SGBD MySQL. Celui-ci est dit open source, il est donc gratuit. Il y a beaucoup de documentation sur Internet et celle-ci est facilement accessible. Lorsqu il est combiné à un serveur Apache et à du PHP il peut être utilisé sur Internet très efficacement. Le tableau C.1 présente les caractéristiques de la solution. [35] Décision : La solution est retenue. Justification : Cette solution à l avantage d être gratuite et de répondre aux principaux besoins du client. MySQL est compatible avec la plupart des systèmes d exploitation sur le marché. Il respecte aussi les contraintes de stockage établies. Il est beaucoup utilisé sur les sites Internet, ce qui pourrait faciliter la distribution des données Oracle Description : La troisième solution trouvée pour le choix du SGBD est Oracle. Ce SGBD est reconnu comme étant l un des plus fiables. La formule pour calculer le nombre de processeurs est la suivante : N f = P, où N est le nombre de coeurs, f le facteur multicoeur et P le nombre de processeurs. Dans notre cas, nous avons choisi principalement des processeurs AMD et Intel, donc le facteur multi-coeur est de 0, 5. Le tableau C.2 présente les différentes caractéristiques de cette solution. [36] Décision : La solution est acceptée. Justification : Le SGBD Oracle répond à tous les besoins du client même si au total il coûte cher Stocker les données Nous avons établi une liste de besoins à respecter dans le cahier des charges afin de trouver la meilleure solution possible au problème posé. La capacité de stockage des données, la fiabilité et le coût du matériel utilisé nous servent de barèmes pour arrêter notre choix. La fiabilité des données est déterminée par la capacité du serveur à utiliser la technologie RAID. Les serveurs proposés ci-dessous supportent tous la technologie RAID 1 permettant d avoir une copie des données au prix du dédoublement des disques durs. La technologie RAID 5 permet d avoir les données séparées sur plusieurs disques durs avec parité tout en tolérant la défaillance d un seul disque dur sans perte de données. RAID 6, supporté par un seul des serveurs, assure la fiabilité des données de la même façon que le RAID 5, mais avec le dédoublement de la parité de chaque donnée. Cette technologie est la plus fiable et tolère la défaillance de deux disques durs avant de perdre des données. RAID 5 et RAID 6 subissent des pertes de performances lors d une défaillance jusqu à ce que le disque dur défaillant soit remplacé. Voici les trois solutions de serveur qui ont été retenues pour combler les besoins identifiés au début de la section : 1. Dell PowerEdge R510 [26] ; 2. CybertronPC Quantum XS1020 1U Rackmount Server [27] ;