ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATIONS
Option: Réseaux Informatique et Internet
MEMOIRE DE FIN DE FORMATION POUR L’OBTENTION DU
DIPLOME D’INGENIEUR DE CONCEPTION Thème :
Conception et Expérimentation d’un Système de Gestion Centralisée des Feux Tricolores dans la ville
de Cotonou
Réalisé par:
Marie-charbel BABADJIDE charbelchrist@gmail.com
Sous la supervision de : Dr. Wilfrid CODJIA
Jury :
Dr. DJOGBE Léopold Dr. MONTEIRO Léonard Dr. Ir. AGBAHUNGBA A. Georges
Dr. Wilfrid CODJIA
Année Académique : 2017-2018
e
Remerciements iii
Liste des figures v
Liste des tableaux vi
Liste des sigles et abréviations vii
Résumé 1
Abstract 2
Introduction 3
Contexte, justification et problématique . . . 4
Objectifs . . . 6
1 Analyses et caractéristiques du trafic routier 7 1.1 La voirie . . . 7
1.2 Services GSM . . . 10
1.3 Le module GPRS Shiels SIM 900 . . . 11
1.4 Différentes stratégies de régulation via les feux de circulation . . . 14
2 Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou 17 2.1 Organisation technique . . . 17
2.2 Les feux tricolores dans la ville de Cotonou . . . 17
2.3 Organisation géographique . . . 20
3 Étude conceptuelle du système de gestion centralisée 27 3.1 Méthode de conception adoptée . . . 27
3.2 Étude conceptuelle de la plate-forme de gestion centralisée des feux tricolores . . 28
3.3 Modélisation . . . 29
3.4 Choix technique de réalisation et de conception du système . . . 41
4 Résultats et discussion 44 4.1 Présentation de notre plate-forme . . . 44
4.2 Discussion . . . 59
Bibliographie 63
Annexe 67 English version Design and Experimentation of a Centralized Traffic Light Management System in the city of Cotonou 73
Introduction 74 Context, justification and problematic issues . . . 75Objectives . . . 76
5 Road traffic analysis and characteristics 77 5.1 Roads . . . 77
5.2 GSM services . . . 78
5.3 The GPRS Shield SIM 900 module . . . 78
5.4 Different control strategies via traffic lights . . . 80
5.5 Technical organization . . . 81
5.6 Traffic lights in the city of Cotonou . . . 81
5.7 Geographical organization . . . 84
5.8 Design methodology adopted . . . 86
5.9 Conceptual study related to the centralized traffic light management platform . . 87
5.10 Modeling . . . 87
5.11 Technical choice of construction and design of the centralized traffic light man- agement platform . . . 90
5.12 Presentation of our platform . . . 93
5.13 Discussion . . . 100
L’aboutissement de ce projet de fin de formation a été possible grâce aux différentes contri- butions techniques, organisationnelles et financières de plusieurs personnes et structures. Nous tenons à témoigner nos sincères gratitudes :
3 au Dr. Wilfrid CODJIA pour avoir accepté d’encadrer ce travail, vos apports, suggestions et critiques ont été d’un apport très important pour la réalisation de ce mémoire ;
3 au Directeur de l’Ecole Polytechnique d’Abomey Calavi (EPAC) et son Adjoint, Pr. Moha- med M. SOUMANOU, Pr. Clément AHOUANNOU , Pr. Guy ALITONOU, Pr. François- Xavier FIFATIN, pour vos conseils ;
3 au Directeur de l’Ecole Polytechnique d’Abomey Calavi (EPAC) et son Adjoint, Pr. Guy ALITONOU, Pr. François-Xavier FIFATIN, pour vos conseils ;
3 au Dr. Léopold DJOGBE, Chef du département de Génie Informatique et Télécommuni- cations (GIT) de l’EPAC, pour votre accompagnement ;
3 à tous les enseignants du département de GIT, pour la formation reçue ;
3 à M. Bickel OLOUDE, ingénieur, pour votre participation à l’améliorationde ce document ; 3 à M. Eustache ADELAKOUN, chef division des signalisations lumineuses de la DST,pour
le temps consacré à nos entretiens ;
3 à tous les camarades de la dixième promotion de l’EPAC, particulièrement celle de GIT, pour votre fraternité ;
3 à toutes les personnes qui ont contribué de proche ou de loin à la réalisation de ce travail notamment AMOUSSOU Kenneth, Brice ATREVY et Ghislain ADIKPETO, je vous dis merci.
1.1 Architecture physique . . . 10
1.2 Module GPRS/GSP SIM 900 vue de haut . . . 11
1.3 Module GPRS/GSP SIM 900 vue de bas . . . 12
1.4 Schéma du fonctionnement des commandes AT . . . 13
2.1 Topologie du réseau d’accès local de gestion des feux tricolores . . . 19
2.2 Emplacement géographique des feux et positionnement du centre de gestion . . 24
2.3 Plan du centre de gestion centralisée des feux tricolores dans la ville de cotonou . 26 3.1 Schéma de la méthode du Cycle en V . . . 27
3.2 Diagrammes de cas d’utilisation globale de la plate-forme . . . 30
3.3 Diagramme de cas d’utilisation du paquetage ‘’Opération Utilisateur” . . . 31
3.4 Diagramme de cas d’utilisation du paquetage «Administration» . . . 33
3.5 Diagramme de séquence du scénario «s’authentifier» . . . 36
3.6 Diagramme de séquence du scénario «Création de compte» . . . 37
3.7 Diagramme de séquence du scénario «« Commande d’un feux » . . . 38
3.8 Diagramme de classe 1 . . . 39
3.9 Diagramme de classe 2 . . . 40
4.1 Architecture du projet dans Sublim Text . . . 44
4.2 Extrait du fichier admin.py . . . 45
4.3 Extrait du fichier models.py . . . 46
4.4 Extrait du fichier setting.py . . . 47
4.5 Extrait du fichier views.py . . . 48
4.6 Contenu du dossier Templates . . . 49
4.7 Contenu du dossier Migrations . . . 50
4.8 Contenu du dossier Migrations . . . 51
4.9 Page d’accueil de la plate-forme de gestion centralisée des feux tricolores . . . 51
4.10 Page de contrôle des états des feux tricolores . . . 52
4.11 Page de commande des états des feux tricolores de la plate-forme . . . 53
4.12 Page d’administration de la plate-forme . . . 54
4.13 Schéma du montage réalisé avec Proteus . . . 56
5.1 GPRS/GSP module SIM 900 top view [30] . . . 79
5.2 GPRS/GSP module SIM 900 bottom view [30] . . . 79
5.3 Topology of the local access network for traffic light management . . . 83
5.4 Emplacement géographique des feux et positionnement du centre de gestion . . 85
5.5 Global use case diagrams of the platform . . . 88
5.6 Scenario sequence diagram «<Account creation» . . . 89
5.7 Class diagram: 1 . . . 90
5.8 Diagramme de classe 2 . . . 92
5.9 Contents of the Migration folder . . . 93
5.10 Homepage of the centralized traffic light management platform . . . 94
5.11 Page of the traffic light status control section . . . 95
5.12 Page of the traffic light status control section . . . 96
5.13 Page d’administration de la plate-forme . . . 97
5.14 Diagrams of the assembly carried out with Proteus . . . 99
1.1 Mode de transmission sans fils . . . 8
1.2 Supports physiques du mode de transmission par câble . . . 9
1.3 Commandes AT dédiées au service SMS . . . 14
2.1 Tableau de répartition des feux dans la ville de Cotonou . . . 20
3.1 Récapitulatif des fonctionnalités allouées à chaque profil d’utilisateur . . . 29
3.2 Spécifications techniques de la carte Arduino UNO . . . 43
4.1 Liste des composants . . . 55
5.1 Technical specifications of the Arduino UNO card . . . 91
5.2 List of components . . . 98
AT : Attention
API : Application Programming Interface
ASCII : American Standard Code for Information Interchange BTS : Base transceiver station
CAD : Computer-aided design CSRF : Cross site request forgery
CRONOS : ContRol Of Networks by Optimization of Switchovers DST : Direction des Services techniques
ETSI : European Telecommunications Standards Institute GPS : Global Positioning System
GSM : Global System for Mobile communications GMSC : Gateway Mobile Switching Center
GPRS : General Packet Radio Service HLR : Home Location Register
INRETS : Institut National de Recherche sur les Transports et leur Sécurité LAN : Local Area Network
ME : Mobile Equipement
MS : Mobile Station
MSC : Mobile Switching Center MVC : Model View Controller MVT : Model View Template OMG : Object Management Group PDU : Protocol Description Unit PLMN : Public Land Mobile Network PRODYN : PROgrammation DYNamique
RAID : Redundant Array of Independent Disks RTC : Réseau Téléphonique Commuté
SC : SMS Center
SCATS : Sydney Coordinated Adaptive Traffic System SCOOT : Split Cycle Offset Optimization Technique SMS : Short Message Service SMS
SME : Short message entity
SGBD : Systeme de Gestion de Base de Données SMSC : SMS Center
SM-AL : Short Message Application Layer SMSIWMSC : SMS-Interworking MSC
SQL : Structured Query Language
TA : Terminal Adaptateur
TE : Terminal Equipement
TRANSYT : TRAffic Network StudY Tool UML : Unified Modeling Language VMSC : Visite Mobile Switching Center XSS : Cross site scripting
La gestion du trafic routier est un aspect important dans le développement de toute nation, du fait qu’elle participe à la sécurité routière. La ville de Cotonou (Départe- ment du Littoral)avec une population de 679012 habitants est le théâtre de 3234 ac- cidents de circulations par année avec 2390 pertes en vie humaine et dommages sa- nitaires. Ces accidents arrivent majoritairement au niveau des carrefours. Les consé- quences issues de cette situation d’insécurité dans laquelle nous vivons sont dus à une gestion non efficiente du trafic routier. Cela crée des manques à gagner et des obstacles à l’atteinte des objectifs de développement de l’État béninois. Le présent travail a pour but l’amélioration de la gestion des feux tricolores qui sont les ou- tils de gestion du trafic au Bénin plus précisément dans la ville de Cotonou. Notre étude a donc consisté d’une part à proposer une architecture de feux tricolores ex- ploitant les réseaux GSM comme réseau de transport acheminant les flux de données entre les feux tricolores et un centre de gestion centralisée de ces feux tricolores dans les treize arrondissements de la ville de Cotonou. D’autre part, la conception d’une plate-forme de gestion centralisée des feux tricolores. Au terme de notre projet, les résultats obtenus montrent la faisabilité de la mise en place d’un système de gestion centralisée efficiente des feux tricolores dans la ville de Cotonou, mais aussi une gestion optimale en termes de coût.
Mots clés:feu tricolore,gestion centralisée,architecture,réseau GSM.
traffic accidents per year with 2390 deaths and health damage. Most of these ac- cidents occur at intersections. The consequences of this situation of insecurity in which we live are due to inefficient road traffic management. This creates revenue shortfalls and obstacles to the achievement of Benin’s development objectives. The purpose of this work is to improve the management of traffic lights, which are traf- fic management tools in Benin, more specifically in the city of Cotonou. Our study therefore consisted on the one hand in proposing a traffic light architecture using GSM networks as a transport network to carry data flows between traffic lights and a centralized management center for these traffic lights in the thirteen districts of the city of Cotonou. On the other hand, the design of a centralized traffic light manage- ment platform. At the end of our project, the results obtained show the feasibility of setting up an efficient centralized traffic light management system in the city of Cotonou, but also an optimal management in terms of cost.
Keys words: trafic light,centralized management,architecture,GSM networks.
Le développement de toute nation passe par la maîtrise de certains paramètres de son envi- ronnement. Depuis l’avènement des engins à moteur, le trafic routier s’affirme comme l’un des paramètres les plus importants du développement du fait qu’il est utilisé par la quasi totallité de la populations dans l’exercice de leurs activités économiques. L’amélioration du niveau de vie moyen et du taux d’équipements des ménages a permis au plus grand nombre d’accéder au déplacement en véhicules particuliers, induisant une circulation routière de plus en plus dense [2]. Cependant, les infrastructures routières sont dimensionnées selon une demande projetée à un certain instant pour répondre à un optimum collectif alors que chaque individu cherche à optimiser son déplacement tout en satisfaisant des critères qui lui sont propres. Cette particu- larité fait du trafic routier un phénomène difficile à analyser et à optimiser surtout qu’au Bénin nous avons plus de moto que de voiture en circulation [2].
Au Bénin, l’infrastructure d’aide à la régulation du trafic est le feux tricolores dont l’optimisa- tion représente un véritable défi. Cet état de choses se manifeste par les délais d’attente parfois injustifiés au niveau des feux à l’exemple de celui du carrefour Cica Toyota à Cotonou ou encore par la mauvaise programmation tel qu’observé au niveau du carrefour Okpè Oluwa à Cotonou qui occasionne souvent des accidents. Cette difficulté de gestion des feux se manifeste aussi par le phénomène de la congestion de trafic et de mauvaise circulation observés malgré la présence des feux, dont le dénouement nécessite l’intervention d’un agent de police. Ainsi la difficulté de la gestion des feux tricolores dans le trafic routier représente un problème majeur induisant des problèmes socio-économiques cruciaux et donc nécessite des recherches de solutions adaptées pouvant être mises en œuvre en pratique.
En raison de cela, dans ce mémoire, nous nous sommes intéressés à la commande et à la main- tenance des feux tricolores à travers un système de gestion centralisée. Ce système de gestion Tiendra compte de l’architecture à adopter, des équipements adéquats, de la plate-forme de gestion et de la performance du réseau tout en ayant un coût optimal.
Contexte, justification et problématique
La ville de Cotonou est la capitale économique du Bénin. Elle dispose d’une densité de 9684,7 habitants/ km2. Elle abrite la majorité des institutions de la République, des sociétés d’État, des sièges sociaux et agences des banques et des sociétés privées de grandes envergures. Des centres économiques tels que le marché de Dantokpa, le port autonome, l’aéroport cardinal Bernardin GANTIN et autres constituent non seulement des atouts, mais aussi de gros contri- buteurs au budget national et à la visibilité du Bénin sur la scène internationale [1].
Malgré cela, les statistiques des accidents de la voie publique dans le département du Littoral (Cotonou) sur la période de 2011 à 2015 permettent d’observer une moyenne de 3234 accidents par année avec 2390 pertes en vies humaines et dommages sanitaires. Il est important de no- tifier que les lieux de théâtres de ces accidents de la route à Cotonou sont généralement les carrefours de la ville. Ces statistiques sont plus amplement détaillées pour le département du Littoral dans les tableaux (contenus dans l’annexe A) [1].
En Une étude effectuée sur les embouteillages, et leurs problèmes dans les grandes villes de l’Afrique de l’Ouest, a montré en ce qui concerne les congestions de trafic au niveau du car- refour Cica-toyota, les conséquences économiques et socio-environnementales qu’elles occa- sionnent si nous considérons ne serai ce que le cas des agents permanents de L’État. Sur le plan économique, un fonctionnaire de l’État béninois en véhicule fait perdre à l’État en moyenne se- lon qu’il appartient à la catégorie A, B, C et D, respectivement 14979,312 ; 9785,064 ; 6495,768 et 4318,68 FCFA par mois. En prenant quatre agents, chacun dans une catégorie, ils font perdre à l’État béninois une somme de 35.578,824 FCFA en moyenne par mois à l’Etat béninois. Un fonc- tionnaire à moto fait perdre à l’État selon qu’il appartient à la catégorie A, B, C et D respective- ment 11204,1 ; 7318,95 ; 4858,65 et 3230,25 FCFA en moyenne par mois. En prenant aussi quatre agents, chacun dans une catégorie, ils font perdre à l’État béninois une somme de 26.611,95 FCFA par mois [4]. Au millier de fonctionnaires qui utilisent chaque jour ces différents axes routiers pour accéder à leur lieu de travail s’ajoutent aussi ceux du secteur privé. L’État bé- ninois perd donc chaque jour des millions de FCFA à cause de l’embouteillage au niveau du carrefour Cica-toyota et cela sans compter les autres carrefour de Cotonou. La perte du temps et le gaspillage du carburant sont des conséquences des embouteillages directement assumés par les usagers. D’autres coûts tels que, la hausse des coûts de production, la réduction de la productivité et le gaspillage du carburant sont assumés par l’ensemble de la société et nuisent à l’économie dans son ensemble. Cette situation contribue à la baisse de productivité, l’augmen- tation du coût des transports, et le coût équivalent au carbone de la pollution [4].
Les congestions de trafic auxquelles sont soumises les populations ne sont pas sans consé- quence sur leur état de santé. Selon une étude américaine, réalisée à la demande de TomTom ( un éditeur de logiciels de planification d’itinéraires et un fabricant de systèmes de navigation
GPS mobiles ou embarqués dans certains véhicules) sur la circulation automobile en 2011 nous montre que les embouteillages augmentent de façon significative, le stress physiologique des automobilistes qui y sont coincés. L’augmentation du stress serait selon cette étude, dans les milieux de congestion est de 8,7% chez les femmes alors que chez les hommes, elle atteindrait la hausse inquiétante de 60%. De si forts taux d’augmentation sont la cause de plusieurs pro- blèmes telle qu’une réduction de la fonction immunitaire ainsi qu’une élévation de la pression artérielle. En effet, ce stress physiologique influence aussi en retour la conduite de certains usa- gers et serait donc à terme à la base de certaines pathologies notamment les étourdissements, l’essoufflement des usagers ainsi que des douleurs musculaires et thoraciques ; ce qui amène parfois certains automobilistes à se déconcentrer, avec pour conséquence l’augmentation des accidents [26]. Une étude effectuée à l’Institut Helmholtz Zentrum de Munich en Allemagne en 2009 conclut aussi que le trafic routier dense pourrait augmenter fortement le risque de crise cardiaque [25].
Cotonou enregistre chaque jour d’innombrables problèmes environnementaux qui menacent l’équilibre écologique et hypothèquent dangereusement la santé des populations du fait des flots d’embouteillage observés sur les axes routiers. La plupart des véhicules qui circulent sur les quatre tronçons utilisent des moteurs diesel et à essence qui émettent à leur tour des fumées noires appelées polluants comme le dioxyde de carbone, les monoxydes d’azote qui sont des gaz très dangereux pour l’environnement et la santé des populations [7]. En effet, le dioxyde d’azote est un des gaz les plus polluants du trafic routier : sa concentration moyenne à l’in- térieur d’un véhicule est bien supérieure à celle que l’OMS recommande de ne pas dépasser.
«La densité du trafic, l’âge des voitures, leur état technique, mais aussi la qualité du carburant sont autant de facteurs qui contribuent à la pollution atmosphérique» [5]. Ainsi, la congestion génère les pollutions atmosphérique et sonore provenant des émissions de gaz d’échappement, de toutes natures qui constitue des périls environnementaux ayant des répercussions graves sur l’appareil respiratoire. Notons aussi que cette pollution est davantage provoquée par les gaz d’échappement provenant de la voiture située en première position surtout lorsque celle-ci s’arrête et accélère plusieurs fois de suite. L’air à Cotonou est alors chargé de plomb et devient de plus en plus irrespirable à cause des gaz d’échappement [6]. Les embouteillages constituent alors un problème majeur à Cotonou. Plusieurs maladies liées à ce fait sont enregistrées chaque jour dans les services spécialisés du Centre National Hospitalier Universitaire-Hubert Koutou- kou MAGA de Cotonou [4].
Face à toutes ces implications du trafic routier sur la sécurité des citoyens et sur le développe- ment, il devient primordial de disposer d’un système de gestion efficient du trafic routier au Bénin. En ce qui concerne les feux tricolores, il s’agit donc de disposer d’un système de gestion en temps réel des feux permettant de les commander, de connaître leur état fonctionnel ou non, mais aussi de l’état du trafic à leur niveau. Ainsi dans le cadre de ce mémoire il est prévu d’amé- liorer la gestion du trafic routier, par la mise en place d’un système de gestion centralisée des feux tricolores, en s’intéressant spécifiquement à l’aspect de la commande des feux tricolores,
préconiser une architecture de feux tricolores pour la ville de Cotonou, basée sur la technolo- gie des réseaux GSM. L’architecture préconisée doit techniquement permettre un système de transmission et de contrôle adéquat, robuste et flexible, intégrant les normes techniques et les récentes technologies en la matière. Le système de gestion centralisé des feux tricolores fait l’objet d’une analyse technique détaillée en vue de sa faisabilité.
Objectifs
Pour tout projet de fin de formation, il est conseillé d’avoir en point de mire des objectifs bien définis. Ces objectifs sont déclinés comme suit :
3 Mettre en place un système sécurisé de gestion centralisée des feux tricolores pour une visualisation de leur état, avec possibilités de modification de leurs programmations en temps réel.
3 Exploiter la technologie des réseaux GSM du territoire béninois comme réseau de trans- port pour le système de gestion centralisée des feux tricolores.
3 Proposer une architecture économique (à coût réduit), mais efficace par rapport aux exi- gences fixées.
Chapitre 1
Analyses et caractéristiques du trafic routier
1.1 La voirie
Le trafic routier se définit comme l’ensemble des phénomènes complexes qui résulte du dé- placement d’usagers sur un réseau routier à capacité limitée [9]. La capacité du réseau routier étant limitée, dans un conteste ou l’ampleur du trafic ne cesse de grandir au fil du temps, la gestion du trafic routier nécessite des infrastructures adaptées (dimensionnement géométrique de la route) et une réglementation appropriée pour les usagers faces à ces infrastructures. Le trafic routier est donc, un phénomène naturellement au sein duquel les interactions entre les différents usagers et leur environnement constituent le cœur du fonctionnement. Ce système de trafic possède les caractéristiques suivantes qui expliquent ses difficultés à savoir :
3 dynamique : les phénomènes de trafic sont fortement dynamiques, le nombre d’interve- nants inclus dans le système variant largement dans le temps. Une petite perturbation peut, par exemple, être amplifiée et se transformer en congestion ;
3 distribution : les phénomènes de trafic résultent de l’interaction de chaque usager de la route avec son environnement ;
3 hétérogénéité : le système de trafic routier fait intervenir différents acteurs, dont les conduc- teurs hétérogènes (débutants/expérimentés), pouvant utiliser, par exemple, des véhicules de caractéristiques variés (poids lourds/légers) ;
3 complexité : un système est qualifié de complexe lorsqu’un observateur ne peut prévoir son comportement ou son évolution ou qu’un de ses composants essentiels (le conduc- teur) a, par exemple, un comportement imprévisible [2].
1.1.1 Les routes urbaines et les autoroutes
Grâce à leurs topologies multivoies et/ou grandes lignes, les autoroutes offrent une bonne flui- dité du trafic. En effet, elles laissent circuler un grand nombre de véhicules, les vitesses des
véhicules étant peu sensibles au changement de l’état du trafic [10], ce qui n’est pas le cas sur les routes urbaines dont les dimensions sont moins grandes que celles des autoroutes, les vi- tesses de véhicules dépendent donc de la densité du trafic.
1.1.2 Les intersections
Une intersection est le lieu de rencontre de plusieurs rues, déterminant des couloirs d’entrées et de sorties. Les directions des véhicules sont soit des courants directs, soit des directions tournés à gauche, soit des directions tournés à droit. La mise en place d’un système de feux à un carre- four permet alors, une coordination dans le temps de l’admission de différents flux de véhicules [2].
1.1.3 Mode de transmission
La transmission numérique s’effectue de façon générale par deux modes à savoir le mode de transmission sans fils et le mode transmission par câble.
Différentes technologies ont été développées pour le mode de transmission sans fils. Il s’agit des technologies telles que, le Wifi, le Wimax, le ZigBee,le Bluetooth et le GSM dont les caracté- ristiques sont présentées dans le tableau1.1.
TABLEAU1.1 – Mode de transmission sans fils [11]
Type Wifi Wimax ZigBee Bluetooth GSM
vitesse 11- 300Mbps
70Mb/s 250Kbps 1- 8Mbps
9,6 kpbs - 1Go/s
distance 50m 50km 300-
1500m
50m 4 - 20
Km fréquence 2.4GHz-
10GHz
10Ghz- 66GHz
2.4GHz 2.4GHz 800MHz- 2600 MHz Puissance
démis- sion
grande Très grande
Très faible
faible Très grande
Pour le mode de transmission par câble, il s’agit des supports physiques tels que les pairs tor- sadés, les câbles coaxiaux et les fibres optiques dont les caractéristiques se présentent comme suit dans le tableau 1.2 :
Dans ce travail, le réseau GSM pour la transmission, spécialement son service des messages courts(SMS), est sollicité à cause des avantages qu’il offre du point de vue distance de couver- ture, vitesse de transmission, fréquence et puissance d’émission, de sa présence sur toute l’éten-
TABLEAU1.2 – Supports physiques du mode de transmission par câble [41]
type Paire torsadée coaxiale Fibre optique
distance 100m 1km 50km
débit 100Mbit/s 1Gbit/s 1Tbit/s coût Peu coûteuse coûteuse Très coûteuse
génie civil pratiquement nul contrairement au coût très élevé qu’occasionnerait le mode de transmission par câble est aussi une des raisons de ce choix.
1.1.4 Architecture SMS en GSM
Le concept de SMS a été défini en 1984, et normalisé en 1987 au GSM 02.03. En 1996 il fonction- nait au niveau international sur tout nouveau terminal mobile [19]. Pour la transmission des SMS en GSM, un serveur spécial appelé SMS Center (SMSC ou SC) [12], est implémenté et est responsable du stockage et du transfert. L’appareil responsable de l’envoi ou de la réception de SMS est le SME (Short message entity) [20], le SME peut être situé dans un équipement fixe tel qu’une MS(Mobile Station) ou un SC. Bien que le SC n’appartient pas au réseau GSM, physi- quement, il peut être intégré dans la même machine que le MSC (mobile switching center). Le SC se voit attribuer un numéro E.164 dans le plan de numérotation du domaine public du ré- seau mobile (PLMN). La communication entre le SC et le terminal mobile s’effectue à travers le MSC. Le MSC est chargé de la commutation pour tous les appels dans une zone. Le SMS Gate- way MSC (SMS-GMSC) est chargé de transmettre le SMS au MSC de visite (VMSC) et renvoyer les informations d’erreur appropriées s’il y en a. Il informe également le registre de localisa- tion du domicile (HLR) du statut de livraison du Message. Pour atteindre le SC, le PLMN doit envoyer le message du VMSC au MSC où se trouve le SC, appelé SMS-Interworking MSC (SM- SIWMSC). Il peut recevoir le message du PLMN et l’envoyer au SC du destinataire [27]. Ceci est illustré par la figure 1.1.
FIGURE1.1 – Architecture physique [29]
1.2 Services GSM
La fonction essentielle du GSM est la communication de phonie, il permet également l’envoi de courts messages (SMS) et la transmission de données [9].
1.2.1 Les services de messages courts(SMS)
Le service des messages courts (Short Message Service SMS) permet d’émettre et de recevoir un message textuel d’au plus 160 caractères (codés à l’aide d’ASCII 7 bits sur 140 octets) entre deux terminaux mobiles GSM. Les messages courts SMS sont spécifiés par l’ETSI (European Telecommunications Standards Institute). Nous distinguons quatre catégories de service des messages courts à savoir, celui de personne à personne, celui de personne à réseau ou à appli- cation, celui d’Internet à personne et enfin celui de machine à machine [12]. Il y a deux façons de transmettre un message SMS, soit en mode PDU (Protocol Description Unit) soit en mode TEXT. Le mode TEXT permet d’envoyer des SMS sans codage préalable à l’étape de numéri- sation cependant il n’est pas supporté par la plupart des téléphones portables et les modules GSM. Le mode PDU est le mode de base. Il permet dans un premier temps de codifier le mes- sage à envoyer en une suite de caractères hexadécimaux avant de le transformer en une suite binaire. Différents types de codage sont utilisés pour passer du mode PDU en mode TEXT. Le plus répandu est celui nommé « ’7-bits GSM alphabet »’ qui offre le maximum de caractères à envoyer (160 caractères). Pour ce type de codages, chaque caractère est codé sur sept bits [8].
1.2.2 Le format d’un message court
Un message court composé est de 160 caractères codés au maximum par l’ASCII 7 bits, issus de la couche applicative SM-AL (Short Message Application Layer). Son format est défini par la recommandation ETSI 3.40 de GSM et un en-tête doit être ajouté pour préciser l’adresse de destination du message court[27].
1.3 Le module GPRS Shiels SIM 900
Le GPRS/GSM Shield basé sur le module SIM900 de SIMCOM, offre un moyen d’utiliser le réseau GSM pour recevoir et envoyer des données de deux lieux géographiquement éloignés . Avec ce module, les échanges de données peuvent être réalisés de trois manières à savoir [30] :
3 Short Message Service (SMS) 3 Audio
3 Service GPRS
Le module GPRS/GSM Shield est compatible avec toutes les cartes Arduino et peut être confi- guré et contrôlé par commande AT. La figure 1.2 présente le module GPRS/GSM SIM 900 vue de haut
FIGURE1.2 – Module GPRS/GSP SIM 900 vue de haut [30]
La figure 1.3 présente le module GPRS/GSM SIM 900 vue par le bas .
FIGURE1.3 – Module GPRS/GSP SIM 900 vue de bas [30]
1.3.1 Les caractéristiques du module GPRS/GSM Shield SIM 900
Le module GPRS/GSM Shield SIM 900 présente quelques caractéristiques à savoir [31] :
3 Quad-Band 850/900/1800/1900 MHz - fonctionne sur les réseaux GSM dans tous les pays du monde ;
3 GPRS multi-slot classe 10/8 ; 3 Station mobile GPRS classe B ; 3 Conforme à GSM phase 2/2 + ; 3 Classe 4 (2W à 850 / 900MHz) ; 3 Classe 1 (1W @ 1800 / 1900MHz) ;
3 Commande par des commandes GSM 07.07, 07.05 et SIMCOM Enhanced AT Commandes ; 3 Service de messages courts ;
3 Sélection du port de série libre ;
3 Prise en charge de RTC avec Super Cap ;
3 Fonction d’activation / désactivation et réinitialisation prise en charge par l’interface Ar- duino
1.3.2 Les commandes AT
À l’avènement des modems, les modems Hayes ont été un standard qui étaient programmés avec un ensemble de commandes Hayes communément appelées les commandes « AT », AT pour dire «Attention». Mais malgré l’augmentation des fabricants de modems, beaucoup ont adhéré, plus ou moins, au standard Hayes. Pour la manipulation d’un modem GSM [8], on a besoin d’utiliser un ensemble de commandes Hayes.
1.3.3 Principes généraux
Les commandes Hayes commencent toujours par la séquence AT à l’exception de la commande de répétition de la dernière commande (A/). Le caractère back space (08H) permet d’annuler, lors de l’envoi d’une commande le dernier caractère envoyé au modem. La longueur maximale d’une chaîne de commande est de 128 caractères y compris la séquence AT et le retour chariot.
En cas d’excès de caractères, le modem n’exécute pas la commande et renvoie un message d’er- reur. Si le modem détecte une erreur dans la chaîne, il interprète la chaîne jusqu’à la détection d’erreur, il envoie un message d’erreur sans traiter les commandes pouvant se trouver derrière la commande ayant occasionné l’erreur [28].
1.3.4 Fonctionnement
La figure 1.4 présente le schéma du fonctionnement des commandes AT.
FIGURE1.4 – Schéma du fonctionnement des commandes AT [28]
3 ME (Mobile Equipement) : téléphone portable
3 TE (Terminal Equipement) : peut-être un ordinateur ou un microcontrôleur 3 TA (Terminal Adaptateur) : assure la liaison entre le ME et le TE
TA et ME sont regroupés dans un même équipement, à l’exemple d’un téléphone portable stan- dard ou un terminal GSM qui contient dans son boîtier à la fois le TA et le ME. Le TE est un équipement à part, à l’exemple d’un ordinateur qui dispose d’un port série ou un circuit élec- tronique basé sur un microcontrôleur qui implante un port série [28].
1.3.4.1 Commandes dédiées au service SMS
Pour une utilisation standard et une gestion de messagerie, les commandes AT du tableau 1.3 suivant peuvent être utilisées :
TABLEAU1.3 – Commandes AT dédiées au service SMS [28]
AT+CSMS Sélection du service de messagerie
AT+CPMS Sélection de la zone mémoire pour le stockage des SMS AT+CMGF Sélection du format du SMS (PDU ou TEXT)
AT+CSCA Définition de l’adresse du centre de messagerie AT+CSDH Affiche en mode TEXT le paramétrage des SMS
AT+CSAS Sauvegarde du paramétrage
AT+CRES Restauration du paramétrage par défaut AT+CNMI Indication concernant un nouveau SMS AT+CMGL Liste les SMS stockés en mémoire
AT+CMGR Lecture d’un SMS
AT+CMGS Envoie un SMS
AT+CMSS Envoi d’un SMS stocké en mémoire
AT+CMGW Écriture d’un SMS
AT+CMGD Efface un SMS
1.4 Différentes stratégies de régulation via les feux de circula- tion
Un plan de feu d’un carrefour est déterminé par la spécification de quatre variables : la lon- gueur du cycle, le plan de phase, la durée de chaque phase et enfin le décalage entre les phases.
Les stratégies de régulation en temps réel s’appuient généralement sur trois modules[13].
Le premier module permet de collecter et de traiter des mesures des variables du trafic. Il s’agit donc de l’emploi des capteurs pouvant être utilisés pour mesurer les variables du tra- fic comme, par exemple, -les boucles magnétiques qui permettent de mesurer la densité, -le flux et le nombre de véhicules dans un tronçon de route, -les caméras vidéos peuvent, en plus, évaluer la longueur de la file d’attente devant un feu de signalisation.
Le deuxième permet généralement de prédire à partir des variables mesurées les valeurs fu- tures de ces mêmes variables ou d’autres en s’appuyant sur un modèle de trafic plus ou moins sophistiqué en vue de prédire ces états futurs.
Le troisième modeule permet l’optimisation des paramètres des plans de feux qui permettent de minimiser le temps de parcours d’un flux donné, les temps d’attente aux carrefours ou le nombre de voitures dans le réseau.
Chaque stratégie a ses propres variables mesurées, son propre module de prédiction et son propre module d’optimisation. Les stratégies diffèrent aussi par les approches de résolution ex- ploitées (programmation dynamique, heuristiques, réseaux de neurones, et autres) et même par la philosophie de l’approche (notion de cycle fixe, instants de basculement du vert au rouge, et autres). Dans la suite, nous allons étudier ces trois stratégies de régulation : la stratégie prédé- terminée, la stratégie semi-adaptative et la stratégie adaptative [2].
1.4.1 Stratégies prédéterminées ou cycliques
La première stratégie considère pendant une période donnée, les cycles comme fixes. Cepen- dant les durées des cycles peuvent changer d’une période à une autre. Le but des plans de feux fixes est de permettre de mieux répondre à la demande moyenne de la capacité estimée du car- refour. C’est dans cette optique que les deux systèmes de gestion du trafic, SCOOT (Split Cycle Offset Optimization Technique) et SCATS (Sydney Coordinated Adaptive Traffic System), ont émergé au début des années 1980. Le premier développé au Royaume-Uni par Hunt [14] dé- termine au niveau de la régulation, la durée optimale du cycle commune à tous les carrefours.
L’algorithme correspondant élaboré, TRANSYT, qui leur est antérieur, permet la conception de plans de feux de circulation, favorisant les transports en commun. Il fournit un plan optimal du point de vue des durées de feu vert. Le choix de la durée du cycle doit être effectué entre les différents plans disponibles au poste de commande selon la situation du trafic manuellement par un opérateur lorsqu’il détecte un événement exceptionnel nécessitant une gestion adaptée au réseau. De la comparaison de SCOOT à l’algorithme antérieur TRANSYT, une économie moyenne de temps, de 12% a été réalisée aussi sur les retards [15]. Le SCATS , proposé en 1982 en Australie par Lowrie [16], a la particularité de coordonner le trafic au niveau de plusieurs carrefours à la fois.
1.4.2 Stratégies semi-adaptatives ou acycliques
Cette stratégie de régulation ne tient pas compte de la notion de cycles, de décalages ou de durées des phases de vert de façon explicite. La durée du cycle peut varier d’un cycle à un autre en fonction de l’état du trafic. L’algorithme, dit CRONOS (ContRol Of Networks by Op- timization of Switchovers) [17], est un système de régulation en temps réel par commande des
feux se basant essentiellement sur les plans de feux fixes. Il permet l’ajustement des durées de feu vert d’un cycle à un autre. Pour recevoir une information, CRONOS utilise un traitement automatique d’images vidéos. Une solution possible de l’algorithme CRONOS est une solution satisfaisant ces contraintes : la minimisation du retard total sur un carrefour sur une minute, la régulation de zones avec un souci de cohérence en n’utilisant que les mesures de débits aux limites de la zone ,un algorithme acyclique sans phase de trafic définie à priori, des mesures de trafic par traitement d’images vidéos pour obtenir de meilleures informations que les boucles magnétiques, les longueurs des files d’attente étant mesurées directement. CRONOS possède, de plus, trois fonctions principales ; il s’agit de :
3 le module de prévision prédit les futures arrivées de véhicules sur les entrées de la zone et permet au module de simulation de connaître la future demande arrivant dans la zone ; 3 le module de simulation calcule le critère de trafic à optimiser pour chaque configuration
de feux testés ;
3 le module d’optimisation recherche la commutation optimale de tous les feux pour mini- miser le critère de gestion du trafic choisi [2].
1.4.3 Stratégies adaptatives
Cette stratégie de régulation tient compte de l’évolution du trafic au cours du temps et réagit en temps réel. L’une des méthodes élaborées pour ce mode de régulation est PRODYN (PROgram- mation DYNamique) [18]. La particularité de la méthode PRODYN est de ne pas prédéterminer le cycle et de réadapter constamment sa durée dans le temps et à chaque carrefour. Le calcul des paramètres (cycles et phases) est remplacé par un processus de décision visant à détermi- ner s’il faut conserver les feux d’un carrefour dans leur état ou de le changer dans un autre état toutes les 2 à 5 secondes. Cela permet de définir une séquence optimale de commandes dans le temps pour minimiser le temps d’attente des véhicules circulant dans la zone. La méthode PRODYN peut s’appliquer aussi bien à des carrefours isolés qu’à des carrefours coordonnés. La régulation d’un réseau de carrefours, s’effectue grâce à un échange convenable d’informations entre carrefours immédiatement voisins.
Chapitre 2
Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou
2.1 Organisation technique
La conception du système de gestion centralisée des feux tricolores, qui fait objet de cette étude est subdivisée en deux modules qui sont le module de la conception d’une architecture de transmission de données entre les feux tricolores et le centre de gestion centralisée ainsi que le module de la conception d’une plate-forme de gestion centralisée des feux tricolores de notre système.
2.2 Les feux tricolores dans la ville de Cotonou
Les feux tricolores représentent un élément majeur de gestion du trafic routier, grâce à sa capa- cité à gérer l’orientation du trafic vers un axe donné. Au Bénin, les feux tricolores sont gérés par un service de la direction des services techniques de la mairie qui est le service de l’électricité, de l’éclairage public et de signalisation lumineuse. La division des signalisations lumineuse est celle s’occupant spécifiquement des feux tricolores.
2.2.1 Les sources d’alimentations des feux tricolores à Cotonou
La gestion des feux tricolores implique nécessairement la gestion de l’énergie, ce qui explique la catégorisation des feux tricolores. Deux sources d’énergie sont utilisées pour les feux tricolores à Cotonou. Il s’agit de l’énergie conventionnelle et de l’énergie solaire.
Les feux tricolores fonctionnant à l’énergie conventionnelle, sont les plus répandus dans la ville de Cotonou. Ils ont pour avantage de réguler le trafic dans toutes les conditions climatiques.
Cependant en cas de coupure d’électricité ces feux tricolores cessent leur régulation du trafic.
Les feux tricolores fonctionnant à l’énergie solaire quant à eux sont moins répandus dans la ville de Cotonou. Indépendants du courant électrique, ils peuvent réguler le trafic même en cas de coupure d’électricité. Cependant, leur fonctionnement peut s’avérer défectueux dans les périodes de grande pluie.
Il est aussi important de noter que pour ces deux types de feux tricolores dans la ville de Coto- nou, il existe certains feux qui disposent d’une minuterie. Ce nouvel apport aux feux tricolores est très utile pour les usagers qui peuvent désormais connaître leurs délais d’attente.
2.2.2 Installation et statistique des feux tricolores
Le processus d’installation d’un feu à un carrefour tient compte de plusieurs critères tels que, le flux du trafic à ce carrefour, l’emplacement stratégique de ce carrefour, le risque d’accident à ce carrefour. La ville de Cotonou dispose de 57 systèmes de feux tricolores(un système, un carrefour) dont 22 fonctionnels avec 1 fonctionnant totalement à l’énergie solaire. En effet la mairie de Cotonou avait pris l’initiative de mettre en place un système d’alternance d’energie avec le solaire au niveau de 5 grands axes de la ville. Cependant le projet n’a pu aboutir faute de permutateur.
Les feux tricolores sont programmés au niveau des boites fonctionnelles ou de contrôles en fonction du traffic, les délais d’attente et de circulation sont fixés afin de favoriser le sens de la circulation ayant le plus d’affluence [3]. Les boîtes fonctionnelles sont des boite électrique donc fonctionnant entièrement avec une tension de 220V. Mais actuellement la mairie de Cotonou à travers un projet en cours, a acquis des boites électroniques fonctionnelles avec une tension de 5.6V.
2.2.3 Gestion et maintenance des feux tricolores
La bonne gestion des feux tricolores est d’une importance capitale étant donné leurs rôles ma- jeurs dans la gestion du trafic routier. À Cotonou, la gestion et la maintenance des feux sont assurées par la DST et quelques entreprises privées. Cependant, cette gestion n’est toujours pas centralisée. Des patrouilles journalières permettent de vérifier l’état des feux tricolores.
2.2.4 Topologie du réseau de gestion des feux tricolores
La présente topologie exploite les stations de base des réseaux mobiles pour réaliser l’intercon- nexion des feux tricolores et du centre de gestion centralisé de notre système. En outre, l’in- terconnexion au niveau des feux tricolores a été effectuée grâce au module GPRS/GSM Shield SIM 900 qui se base sur la technologie Arduino pour décodé les données envoyées aux feux tricolores en vue de l’exécution des commandes. Cette topologie est présentée à la figure 2.1.
FIGURE2.1–Topologieduréseaud’accèslocaldegestiondesfeuxtricolores
2.3 Organisation géographique
Les informations obtenues à la direction des services techniques de mairie de Cotonou ont permis d’avoir une meilleure compréhension de l’étendue de la répartition et de l’état des feux tricolores dans la ville de Cotonou.
2.3.1 Répartitions et état des feux dans la ville de Cotonou
Dans le souci d’une bonne régulation du trafic, la ville de Cotonou dispose sur un grand nombre de ces axes routiers des feux tricolores, dont certains ne sont plus en état de marche, comme le présente le tableau 2.1.
TABLEAU2.1 – Tableau de répartition des feux dans la ville de Cotonou [3]
N° Axe Nombre Dénomination
Carrefours
État Cotonou Ouest : 40
1 Echangeur Godomey- Carrefour Cica Toyota
04 Mènontin(Bénin
marché)
Non Fonctionnel
Agla Millena Fonctionnel Agla Pylônes Non Fonctionnel Cica Toyota Fonctionnel 2 Cica Toyota-
Étoile rouge
01 Agontinkon Fonctionnel
3 Étoile rouge- PAC
07 Yamadjako Fonctionnel
Prison civile Non Fonctionnel Unafrica Fonctionnel Zongo Rue 117 Non Fonctionnel Zongo Mos-
quée
Fonctionnel (tota- lement solaire) Trois Banques Non Fonctionnel PAC 117 Non Fonctionnel
4 Stade Mathieu KEREKOU- Zogbo
01 Siège 10e Ar-
rondissement
Fonctionnel
5 Zogbo- Maro
militaire
04 Ste Rita Fonctionnel
Okpè Oluwa Fonctionnel Avana (Sikè-
codji)
Fonctionnel Maro militaire Fonctionnel 6 Gbèdjromèdé
(Collège la Référence)- Église Notre Dame
07 BIBE Non Fonctionnel
Lègba Non Fonctionnel
De Souza Fonctionnel
Zinsou Fonctionnel
La Gaité Fonctionnel Ciné Vog Fonctionnel Église Notre
Dame
Fonctionnel
7 Lègba- Sogéma 02 Pharmacie les
quatre théra- pies
Non Fonctionnel
SOGEMA Non Fonctionnel
8 Cica- Toyota- Église Bon Pasteur
01 Mosquée Cadjè-
houn
Fonctionnel
9 Trois Banques- Aéroport
06 Centre Culture
Chinois
Non Fonctionnel Direction Géné-
rale SONACOP
Non Fonctionnel
SONEB Fonctionnel
Place de Souve- nir
Non Fonctionnel Trésor Public Non Fonctionnel
Agence Air
France
Fonctionnel
10 Hôtel du Port- CIC
02 Hôtel du Port Non Fonctionnel Hôtel Ibis Non Fonctionnel 11 Maro militaire-
Église St Michel
02 Diversité Non Fonctionnel
Eglise St Michel Fonctionnel
12 Camp Guezo 01 Camp Guezo Non Fonctionnel
13 Direction Ré- gionale Littoral 1 de la SBEE
01 Direction Ré-
gionale Littoral 1 de la SBEE
Non Fonctionnel
14 Pharmacie Jon- quet
01 Pharmacie Jon-
quet
Non Fonctionnel Cotonou Est : 17
15 Vieux Pont- SO- BEBRA
04 Cimetière Ap-
kapka
Non Fonctionnel
Stade René
PLEVEN
Non Fonctionnel Clinique BONI Non Fonctionnel
SOBEBRA Fonctionnel
16 Dédokpo- SOBEBRA
02 Dédokpo Fonctionnel
Egile Sacré- Cœur
Fonctionnel 17 EPP Avotrou 01 EPP Avotrou Pas mis en service 18 SOBEBRA – Le
Bélier
10 DMTP Non Fonctionnel
OPT Pk3 Non Fonctionnel Ex MABECY Non Fonctionnel
GBB Non Fonctionnel
DEGAKON Non Fonctionnel Ex SBAC Non Fonctionnel Abattoir Non Fonctionnel Blanchisserie
FRANITA
Non Fonctionnel Pharmacie
Abattoir
Non Fonctionnel Le Belier Non Fonctionnel
2.3.2 Emplacement géographique des feux tricolores et proposition d’un centre de gestion dans la ville de Cotonou
En vue de mieux apprécier la répartition géographique des feux tricolores dans la ville de Coto- nou et de proposer un centre de gestion adéquat, une coupe a été effectuée sur le réseau de feux tricolores de la ville de Cotonou, réalisé dans le cadre du projet Asphaltage par la mairie de la ville de Cotonou. Par la suite, le centre de contrôle et de commandements à été connecté à l’en- semble des feux à travers les BTS pour l’optimisation du trafic. Pour l’emplacement du centre de gestion, nous avons opté pour le siège des services d’éclairages publiques et de signalisation de la Direction des Services Techniques de la mairie de Cotonou. Le support de transmission dans ce réseau présenté à la figure 2.2 est le support hertzien du réseau mobile.
Le centre de contrôle et de commandements permettra alors le suivi et la commande en temps réel des feux tricolores dans la ville de Cotonou.
FIGURE2.2–Emplacementgéographiquedesfeuxetpositionnementducentredegestion Légendes Feutricolore Centredegestioncentralisée
2.3.3 Plan du centre de gestion des feux tricolores dans la ville de Cotonou
Dans le souci d’avoir un centre de gestion qui respecte les normes en matière d’espace dispo- nible et surtout d’énergie, il a été proposé une architecture à la figure 2.3 pour la construction du centre de gestion centralisée.
FIGURE2.3–Planducentredegestioncentraliséedesfeuxtricoloresdanslavilledecotonou
Chapitre 3
Étude conceptuelle du système de gestion centralisée
3.1 Méthode de conception adoptée
Afin d’atteindre l’objectif poursuivi à travers cette étude, une approche méthodologique de conception appropriée à l’étude a été suivie. Pour cela, nous avons choisi la méthode du cycle en V [37] encore appelée méthode en cascade. Cette méthode de développement des applications est illustrée à la figure 3.1.
FIGURE3.1 – Schéma de la méthode du Cycle en V [37]
Pour chacune des étapes illustrée à la figure 3.1, nous avons mené des activités données qui nous ont permis d’aboutir à la plate-forme de gestion centralisée des feux tricolores.
3 L’analyse des besoins : au cours de cette étape, nous avons menés des entretiens avec le chef division des signalisations lumineuses de la Direction des Services Techniques de la mairie de Cotonou qui nous a permis d’avoir une idée des besoins réels des futurs utilisateurs de la plate-forme ;
3 La spécification : à cette étape, les fonctionnalités essentielles ont été validées ;
3 La conception préliminaire et détaillée : au cours de cette étape, nous avons effectué la modélisation des différentes fonctionnalités et interactions qui seront prises en charge sur la plate-forme finale ;
3 Le codage : à travers cette étape, grâce à des outils de développement d’application, nous avons conçu la plate-forme web de la gestion centralisée des feux ;
3 Les tests : ils nous ont permis de nous assurer que chaque module fonctionnel de la plate- forme répond aux spécifications fonctionnelles prédéfinies
3.2 Étude conceptuelle de la plate-forme de gestion centralisée des feux tricolores
3.2.1 Besoin fonctionnel
Les spécifications fonctionnelles décrivent les fonctions principales de la plate-forme, qui doivent satisfaire, les besoins dégagés dans l’étude faite après l’entretien effectué avec le chef division des signalisations lumineuses de la DST à savoir :
3 Authentification : Les utilisateurs de la plate-forme doivent s’authentifier à travers un identifiant et un mot de passe, pour pouvoir accéder aux services offerts par la plate- forme
3 Administration : La plate-forme de gestion centralisée des feux tricolores dans la ville de Cotonou est donc une plate-forme d’administration à distances des feux tricolores de la ville de Cotonou. Cette administration se présente sur trois volets.
æ Le premier est l’ajout de nouveaux carrefours, de nouveaux feux tricolores et de nou- velles programmations.
æ Le deuxième est la commande des feux à distance à travers le passage au vert d’un feu spécifique et le changement des programmations au niveau des feux.
æ Le troisième est le contrôle de l’état des feux afin d’en assurer la maintenance en cas
3.2.2 Identification des acteurs de la plate-forme
Deux profils d’utilisateurs se dessinent pour l’utilisation de cette plateforme de gestion centra- lisée. Il s’agit d’un profil administrateur et d’un profil utilisateur. Chaque profil d’utilisateur possède ses droits à utiliser des fonctionnalités données de la plateforme. Le tableau 3.1 donne un récapitulatif des fonctionnalités allouées à chaque profil d’utilisateur.
TABLEAU3.1 – Récapitulatif des fonctionnalités allouées à chaque profil d’utilisateur Fonctionnalité Utilisateur Administrateur
Gestion des accès Non disponible Disponible Création ou modifi-
cation des paramé- trages des feux pour un carrefour
Non disponible Disponible
Commande des feux à distance et chan- gement des program- mations des feux
Disponible Disponible
Contrôle de l’état des feux
Disponible Disponible
Ainsi donc, tels que présenté au tableau 3.1 le profil administrateur a en plus des droits d’accès aux fonctionnalités du profil utilisateur, le droit d’accès aux fonctionnalités pouvant modifier la base de donnée.
3.3 Modélisation
À ce niveau, nous avons conçu les diagrammes de cas d’utilisation, les diagrammes de sé- quences et finalement un diagramme de classes illustrant les classes d’objets intervenant dans l’implémentation des cas d’utilisation identifiés. Il a été utilisé le formalisme UML (Unified Mo- deling Language) pour schématiser les différentes étapes de la modélisation.
UML est une méthode de modélisation orientée objet développée en réponse à l’appel à propo- sitions lancé par l’OMG (Object Management Group) dans le but de définir la notation standard pour la modélisation des applications construites à l’aide d’objets [32]. UML est aussi une no- tation graphique conçue pour représenter, spécifier, construire et documenter les systèmes lo- giciels. Ses deux principaux objectifs sont la modélisation de systèmes utilisant les techniques orientées objet, depuis la conception jusqu’à la maintenance, la création d’un langage abstrait compréhensible par l’homme et interprétable par les machines [21], facilitant ainsi la compré- hension des besoins fonctionnels précédemment identifiés.
3.3.1 Diagramme de cas d’utilisation
Un cas d’utilisation dans le formalisme UML représente un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable, intéressant pour un acteur par- ticulier. Ainsi, un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteur/système et apporte une valeur ajoutée à l’acteur concerné.
Pour chaque acteur il a été identifié, les différents besoins qui peuvent l’amener à utiliser la plate-forme. Ainsi, parmis les fonctionnalités de la plate-forme identifiées précédemment, il est déterminé les fonctionnalités qui correspondent aux besoins de chaque utilisateur. Cette activité a permis de concevoir le diagramme de cas d’utilisation globale de toute la plate-forme de gestion centralisée des feux tricolores dans la ville de Cotonou. Ce diagramme regroupe les cas d’utilisation en deux paquetages distincts qui illustrent respectivement les interactions des deux acteurs identifiés. La figure 3.2 illustre ce diagramme.
FIGURE3.2 – Diagrammes de cas d’utilisation globale de la plate-forme
Afin de mieux comprendre le fonctionnement de la plate-forme, il faut à présent détailler chaque paquetage de cas d’utilisation.
3.3.1.1 Diagramme de cas d’utilisation du paquetage «Opération Utilisateur»
Le paquetage «Opération Utilisateur» regroupe les cas d’utilisations suivants : 3 Consulter l’état des feux tricolores ;
3 Commande des feux tricolores ;
La figure 3.3, illustre les cas d’utilisation du paquetage « ’Opération Utilisateur “’ avec les scé- narios qu’ils impliquent et dont l’acteur principal est l’acteur ‘’Utilisateur ».
FIGURE3.3 – Diagramme de cas d’utilisation du paquetage ‘’Opération Utilisateur”
Pour comprendre le contexte de ce diagramme, nous avons étudié les cas d’utilisation qui la compose.
Cas d’utilisation "Consulté état des feux”
3 Cas d’utilisation : Consulté état des feux 3 Acteur : Utilisateur
3 Description : Ce cas d’utilisation offre à l’Utilisateur la fonctionnalité qui lui permet de connaître l’état des feux en vue d’une maintenance au besoin
3 Pré-condition : l’Utilisateur doit d’abord s’authentifier
3 Scénario : Mise à jour de l’état des feux : l’état des feux se met à jour automatiquement après l’authentification de l’Utilisateur pour lui donner l’accès.
Cas d’utilisation «Commande des feux»
3 Cas d’utilisation : Commande des feux 3 Acteur : Utilisateur
3 Description : Ce cas d’utilisation offre à l’Utilisateur la fonctionnalité qui lui permet d’exer- cer des actions sur les feux tricolores si cela est nécéssaire.
3 Pré-condition : l’Utilisateur doit d’abord s’authentifier 3 Scénarios :
æ Passer un feu au vert : l’Utilisateur peut faire passer le feu au vert lors d’une urgence telle que le passage d’une ambulance ;
æ Changer la programmation des feux : le flux du trafic varie dans le temps en parti- culier les jours de fête. En ces cas de changement, l’Utilisateur peut donc choisir une programmation des feux appropriée.
3.3.1.2 Diagramme de cas d’utilisation du paquetage «Administration»
Le paquetage «Administration» comprend principalement les cas d’utilisation suivant : 3 Gestion des comptes
3 Gestion des carrefours 3 Gestion des feux
3 Gestion des programmations
La figure 3.4 illustre ces cas d’utilisation ainsi que les différents scénarios de cas d’utilisation qu’ils induisent.
FIGURE3.4 – Diagramme de cas d’utilisation du paquetage «Administration»
Nous avons aussi étudié les cas d’utilisation qui composent ce paquetage dans le souci de mieux les comprendre.
Cas d’utilisation «Gestion des comptes»
3 Cas d’utilisation : Gestion des comptes 3 Acteur : Administrateur
3 Description : Ce cas d’utilisation permet à l’administrateur de gérer les comptes des utili- sateurs qui peuvent accéder à la plate-forme de gestion centralisée des feux.
3 Pré-condition : l’administrateur doit d’abord s’authentifier 3 Scénarios :
æ Création d’un compte : ce scénario permet à l’administrateur de créer un compte à tout utilisateur qui doit se connecter à la plate-forme. Aux cours de la création l’administrateur à la possibilité de lui accorder un profil d’utilisateur parmi les profils existants ;
æ Mise à jour d’un compte : ce scénario permet à l’administrateur de mettre à jour les informations du compte d’un utilisateur si entre temps des changements s’imposent ;
æ Suppression d’un compte : l’administrateur peut procéder à la suppression d’un compte utilisateur quand cet utilisateur est dénié de ses fonctions ou ne respecte pas les règles et les conditions d’utilisation de la plate-forme
Cas d’utilisation «Gestion des carrefours»
3 Cas d’utilisation : Gestion des carrefours 3 Acteur : Administrateur
3 Description : Ce cas d’utilisation permet à l’administrateur de gérer les carrefours où sont implantés les feux
3 Pré-condition : l’administrateur doit d’abord s’authentifier 3 Scénarios :
æ Création d’un carrefour : ce scénario permet à l’administrateur en cas d’installation de nouveaux feux à un carrefour de la ville, de créer dans la base de données le nouveau carrefour correspondant.
æ Mise a jour d’un carrefour : ce scénario permet à l’administrateur de mettre à jour les informations relatives à un carrefour donné.
æ Suppression d’un carrefour : ce scénario permet à l’administrateur de supprimer un carrefour s’il arrivait que celui-ci se voit retirer ses feux tricolores pour une raison ou une autre
Cas d’utilisation «Gestion des feux»
3 Cas d’utilisation : Gestion des feux 3 Acteur : Administrateur
3 Description :Ce cas d’utilisation permet à l’administrateur de gérer les feux 3 Pré-condition : l’administrateur doit d’abord s’authentifier
3 Scénarios :
æ Création d’un feu : ce scénario permet à l’administrateur de créer, en cas d’installa- tion dans la ville d’un nouveau feu, son correspondant dans la base de données.
æ Mise à jour d’un feu : ce scénario permet à l’administrateur de mettre à jour les in- formations relatives à un feu tricolore donné.
æ Suppression d’un feu : ce scénario permet à l’administrateur de supprimer un feu
Cas d’utilisation gestion des programmations 3 Cas d’utilisation : Gestion des programmations 3 Acteur : Administrateur
3 Description : Ce cas d’utilisation permet à l’administrateur de gérer les programmations des feux.
3 Pré-condition : l’administrateur doit d’abord s’authentifier 3 Scénarios :
æ Création d’une programmation :ce scénario permet à l’administrateur de créer, pour les feux tricolores la programmation adaptée au flux du trafic d’une période donnée.
æ Mise à jour d’une programmation : ce scénario permet à l’administrateur de mettre à jour les informations relatives à la programmation d’un feu tricolore donné.
æ Suppression d’une programmation : ce scénario permet à l’administrateur de sup- primer la programmation d’un feu tricolore dans le cas où le besoin s’imposerait.
Tous les cas d’utilisation présents dans le diagramme de cas d’utilisation globale ont été dé- taillés. Les scénarios de cas d’utilisation présentés pour chaque cas d’utilisation ont permis une meilleure compréhension du fonctionnement de chacun des modules qui composent la plate- forme.
3.3.2 Diagramme de séquence
En vue d’amorcer la conception détaillée de notre plate-forme de gestion centralisée des feux tricolores, la visualisation schématique du fonctionnement interne de chaque scénario de cas d’utilisation s’avère nécessaire. À cet effet, le formalisme UML met à notre disposition les dia- grammes de séquence pour exprimer et détailler de façon compréhensible le déroulement des différentes étapes permettant d’aboutir à la réalisation de chaque cas d’utilisation.
Ainsi donc, le diagramme de séquence est un diagramme d’interaction UML. Ce type de dia- gramme permet donc de développer en analyse les scénarios d’utilisation de notre plate-forme.
Étant donné que précédemment nous avons énuméré plusieurs scénarios, nous allons présen- ter les diagrammes de séquence d’un scénario par paquetage de cas d’utilisation pour raison de simplicité. Il s’agit des scénarios suivants :
3 s’authentifier
3 Création de compte 3 Commande d’un feu
3.3.2.1 Diagramme de séquence du scénario «s’authentifier»
Le diagramme de séquence du scénario « s’authentifier » est présenté dans la figure 3.5.
FIGURE3.5 – Diagramme de séquence du scénario «s’authentifier»
Ce diagramme de séquence décrit les étapes de connexion et de déconnexion des utilisateurs de la plate-forme.
3.3.2.2 Diagramme de séquence du scénario «Création de compte»
Le diagramme de séquence du scénario « Création de comptes » est présenté dans la figure 3.6.
FIGURE3.6 – Diagramme de séquence du scénario «Création de compte»
Ce diagramme de séquence décrit les étapes successives entrant en jeu dans la création de compte des utilisateurs de la plate-forme.
3.3.2.3 Diagramme de séquence du scénario «Commande d’un feux»
Le diagramme de séquence du scénario « Commande d’un feu » est présenté dans la figure 3.7.
FIGURE3.7 – Diagramme de séquence du scénario «« Commande d’un feux »
Ce diagramme de séquence décrit les étapes successives entrant en jeu dans la commande d’un feux tricolore à la plate-forme.
3.3.3 Diagramme de classe
Les spécifications détaillées de la conception ont permis de relever la pertinence de certaines classes d’objets indispensables à la pertinence des données fonctionnelles de cette plate-forme de gestion centralisée des feux tricolores. Les diagrammes de classe présentés de façon morcelée respectivement sur les figures 3.8 et 3.9 nous permettent d’identifier les classes et les différentes associations qu’elles établissent entre elles pour permettre une souplesse dans la gestion des différents feux et de leur programmation au niveau des divers carrefours.
FIGURE3.8 – Diagramme de classe 1
FIGURE3.9–Diagrammedeclasse2
3.4 Choix technique de réalisation et de conception du système
3.4.1 Technologie de réalisation
Pour la réalisation du projet il est essentiellement utilisé des technologies basées sur le langage python adapté au Framework Django, dont l’Api Twilio.
3.4.1.1 Django
Django est un cadre de développement web source ouverte, en langage Python, qui s’articule complètement autour du modèle logiciel MVT (Model/View/Template) qui est une évolution du modèle logiciel MVC (Model/View/Controller, en français : modèle/vue/contrôleur) . Il a pour but de rendre le développement web 2.0 simple et rapide par ses capacités telles que la gestion automatique des comptes utilisateurs et des fonctionnalités d’administration de la base de données. Un système de validation des données entrées par l’utilisateur est également disponible et permet d’afficher des messages d’erreurs automatiques. Le Framework Django met aussi à la disposition des développeurs un serveur web léger [33] couplé à SQLite qui est une bibliothèque en langage C qui fournit une base de données légère sur disque qui ne nécessite pas de processus serveur distinct et permet d’accéder à la base de données à l’aide d’une variante non standard du langage de requête SQL à travers l’interface SQLite3 [36]. Ceci permettant de développer et tester l’application développée en temps réel sans déploiement.
3.4.1.2 API Twilio
API est l’acronyme d’Application Programming Interface, que l’on traduit en français par in- terface de programmation d’application. L’API peut être résumée à un ensemble de fonctions qui permettent à des applications de communiquer entre elles et de s’échanger mutuellement des services ou des données [35]. L’API Twilio est donc une API de service web de téléphonie qui permet de générer des applications vocales et de SMS.
Ainsi Twilio Voice permet aux applications de passer et de recevoir des appels téléphoniques [34], Twilio SMS leur permet de créer et de recevoir des SMS et Twilio Client permet aux ap- plications d’activer les communications vocales et SMS au moyen de connexions Internet exis- tantes. Cet API a été utilisé afin de rendre possible la connexion de la plate-forme au réseau GSM.
3.4.2 Présentation des outils de développement
3.4.2.1 Sublime text
L’éditeur de texte Sublime text version 3.1 2018 est un outil complet de développement pour la conception d’application web, de Web Services, d’applications desktop et mobiles. Les langages
