ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI

RÉPUBLIQUE DU BÉNINMINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ D’ABOMEY-CALAVI

ÉCOLE POLYTECHNIQUED’ABOMEY-CALAVI

DEPARTEMENT DE GENIE INFORMATIQUE ETTELECOMMUNICATIONS

Option: Réseaux Informatique et Internet

MEMOIRE DE FIN DE FORMATIONPOUR L’OBTENTION DU

DIPLOME D’INGENIEUR DE CONCEPTION

Thème :

Conception et Expérimentation d’un Système deGestion Centralisée des Feux Tricolores dans la ville

de Cotonou

Réalisé par :Marie-charbel BABADJIDE

[email protected]

Sous la supervision de :Dr. Wilfrid CODJIA

Jury :Dr. DJOGBE Léopold

Dr. MONTEIRO LéonardDr. Ir. AGBAHUNGBA A. Georges

Dr. Wilfrid CODJIA

Année Académique : 2017-2018

11e Promotion

Sommaire

Remerciements iii

Liste des figures v

Liste des tableaux vi

Liste des sigles et abréviations vii

Résumé 1

Abstract 2

Introduction 3Contexte, justification et problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Analyses et caractéristiques du trafic routier 71.1 La voirie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Services GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Le module GPRS Shiels SIM 900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.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 172.1 Organisation technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Les feux tricolores dans la ville de Cotonou . . . . . . . . . . . . . . . . . . . . . . 172.3 Organisation géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Étude conceptuelle du système de gestion centralisée 273.1 Méthode de conception adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Étude conceptuelle de la plate-forme de gestion centralisée des feux tricolores . . 283.3 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

i

SOMMAIRE SOMMAIRE

3.4 Choix technique de réalisation et de conception du système . . . . . . . . . . . . . 41

4 Résultats et discussion 444.1 Présentation de notre plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliographie 63

Annexe 67

English versionDesign and Experimentation of a Centralized Traffic Light ManagementSystem in the city of Cotonou 73

Introduction 74Context, justification and problematic issues . . . . . . . . . . . . . . . . . . . . . . . . 75Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Road traffic analysis and characteristics 775.1 Roads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 GSM services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.3 The GPRS Shield SIM 900 module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.4 Different control strategies via traffic lights . . . . . . . . . . . . . . . . . . . . . . 805.5 Technical organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6 Traffic lights in the city of Cotonou . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.7 Geographical organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.8 Design methodology adopted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.9 Conceptual study related to the centralized traffic light management platform . . 875.10 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.11 Technical choice of construction and design of the centralized traffic light man-

agement platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.12 Presentation of our platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.13 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

ii

Remerciements

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. Noustenons à témoigner nos sincères gratitudes :

3 au Dr. Wilfrid CODJIA pour avoir accepté d’encadrer ce travail, vos apports, suggestionset 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. GuyALITONOU, 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,pourle 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 travailnotamment AMOUSSOU Kenneth, Brice ATREVY et Ghislain ADIKPETO, je vous dismerci.

iii

Liste des figures

1.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Module GPRS/GSP SIM 900 vue de haut . . . . . . . . . . . . . . . . . . . . . . . 111.3 Module GPRS/GSP SIM 900 vue de bas . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Schéma du fonctionnement des commandes AT . . . . . . . . . . . . . . . . . . . 13

2.1 Topologie du réseau d’accès local de gestion des feux tricolores . . . . . . . . . . 192.2 Emplacement géographique des feux et positionnement du centre de gestion . . 242.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 . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Diagrammes de cas d’utilisation globale de la plate-forme . . . . . . . . . . . . . . 303.3 Diagramme de cas d’utilisation du paquetage ‘’Opération Utilisateur” . . . . . . 313.4 Diagramme de cas d’utilisation du paquetage «Administration» . . . . . . . . . . 333.5 Diagramme de séquence du scénario «s’authentifier» . . . . . . . . . . . . . . . . 363.6 Diagramme de séquence du scénario «Création de compte» . . . . . . . . . . . . . 373.7 Diagramme de séquence du scénario «« Commande d’un feux » . . . . . . . . . . 383.8 Diagramme de classe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.9 Diagramme de classe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Architecture du projet dans Sublim Text . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Extrait du fichier admin.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Extrait du fichier models.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Extrait du fichier setting.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Extrait du fichier views.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6 Contenu du dossier Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7 Contenu du dossier Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.8 Contenu du dossier Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.9 Page d’accueil de la plate-forme de gestion centralisée des feux tricolores . . . . . 514.10 Page de contrôle des états des feux tricolores . . . . . . . . . . . . . . . . . . . . . 524.11 Page de commande des états des feux tricolores de la plate-forme . . . . . . . . . 534.12 Page d’administration de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . 544.13 Schéma du montage réalisé avec Proteus . . . . . . . . . . . . . . . . . . . . . . . . 56

iv

LISTE DES FIGURES LISTE DES FIGURES

5.1 GPRS/GSP module SIM 900 top view [30] . . . . . . . . . . . . . . . . . . . . . . . 795.2 GPRS/GSP module SIM 900 bottom view [30] . . . . . . . . . . . . . . . . . . . . 795.3 Topology of the local access network for traffic light management . . . . . . . . . 835.4 Emplacement géographique des feux et positionnement du centre de gestion . . 855.5 Global use case diagrams of the platform . . . . . . . . . . . . . . . . . . . . . . . 885.6 Scenario sequence diagram «<Account creation» . . . . . . . . . . . . . . . . . . . 895.7 Class diagram: 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.8 Diagramme de classe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.9 Contents of the Migration folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.10 Homepage of the centralized traffic light management platform . . . . . . . . . . 945.11 Page of the traffic light status control section . . . . . . . . . . . . . . . . . . . . . 955.12 Page of the traffic light status control section . . . . . . . . . . . . . . . . . . . . . 965.13 Page d’administration de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . 975.14 Diagrams of the assembly carried out with Proteus . . . . . . . . . . . . . . . . . . 99

v

Liste des tableaux

1.1 Mode de transmission sans fils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Supports physiques du mode de transmission par câble . . . . . . . . . . . . . . . 91.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 . . . . . . . 293.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 . . . . . . . . . . . . . . . . . . 915.2 List of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

vi

Liste des sigles et abréviations

AT : AttentionAPI : Application Programming InterfaceASCII : American Standard Code for Information InterchangeBTS : Base transceiver stationCAD : Computer-aided designCSRF : Cross site request forgeryCRONOS : ContRol Of Networks by Optimization of SwitchoversDST : Direction des Services techniquesETSI : European Telecommunications Standards InstituteGPS : Global Positioning SystemGSM : Global System for Mobile communicationsGMSC : Gateway Mobile Switching CenterGPRS : General Packet Radio ServiceHLR : Home Location RegisterINRETS : Institut National de Recherche sur les Transports et leur Sécurité

LAN : Local Area NetworkME : Mobile EquipementMS : Mobile StationMSC : Mobile Switching CenterMVC : Model View ControllerMVT : Model View TemplateOMG : Object Management GroupPDU : Protocol Description UnitPLMN : Public Land Mobile NetworkPRODYN : PROgrammation DYNamiqueRAID : Redundant Array of Independent DisksRTC : Réseau Téléphonique Commuté

vii

LISTE DES TABLEAUX LISTE DES TABLEAUX

SC : SMS CenterSCATS : Sydney Coordinated Adaptive Traffic SystemSCOOT : Split Cycle Offset Optimization TechniqueSMS : Short Message Service SMSSME : Short message entitySGBD : Systeme de Gestion de Base de DonnéesSMSC : SMS CenterSM-AL : Short Message Application LayerSMSIWMSC : SMS-Interworking MSCSQL : Structured Query LanguageTA : Terminal AdaptateurTE : Terminal EquipementTRANSYT : TRAffic Network StudY ToolUML : Unified Modeling LanguageVMSC : Visite Mobile Switching CenterXSS : Cross site scripting

viii

Résumé.

La gestion du trafic routier est un aspect important dans le développement de toutenation, 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 desobstacles à l’atteinte des objectifs de développement de l’État béninois. Le présenttravail 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éesentre les feux tricolores et un centre de gestion centralisée de ces feux tricolores dansles treize arrondissements de la ville de Cotonou. D’autre part, la conception d’uneplate-forme de gestion centralisée des feux tricolores. Au terme de notre projet, lesrésultats obtenus montrent la faisabilité de la mise en place d’un système de gestioncentralisée efficiente des feux tricolores dans la ville de Cotonou, mais aussi unegestion optimale en termes de coût.

Mots clés : feu tricolore, gestion centralisée, architecture, réseau GSM.

1

Abstract. English version Road traffic management is an important aspect in thedevelopment of any nation, as it contributes to road safety. The city of Cotonou(District of the Littoral) with a population of 679012 inhabitants is the scene of 3234traffic accidents per year with 2390 deaths and health damage. Most of these ac-cidents occur at intersections. The consequences of this situation of insecurity inwhich we live are due to inefficient road traffic management. This creates revenueshortfalls and obstacles to the achievement of Benin’s development objectives. Thepurpose 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 studytherefore consisted on the one hand in proposing a traffic light architecture usingGSM networks as a transport network to carry data flows between traffic lights anda centralized management center for these traffic lights in the thirteen districts of thecity 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 feasibilityof setting up an efficient centralized traffic light management system in the city ofCotonou, but also an optimal management in terms of cost.

Keys words: trafic light, centralized management, architecture, GSM networks.

2

Introduction

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 desparamè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 devie moyen et du taux d’équipements des ménages a permis au plus grand nombre d’accéder audé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éninnous 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 parfoisinjustifiés au niveau des feux à l’exemple de celui du carrefour Cica Toyota à Cotonou ou encorepar la mauvaise programmation tel qu’observé au niveau du carrefour Okpè Oluwa à Cotonouqui occasionne souvent des accidents. Cette difficulté de gestion des feux se manifeste aussi parle phénomène de la congestion de trafic et de mauvaise circulation observés malgré la présencedes feux, dont le dénouement nécessite l’intervention d’un agent de police. Ainsi la difficulté dela gestion des feux tricolores dans le trafic routier représente un problème majeur induisant desproblèmes socio-économiques cruciaux et donc nécessite des recherches de solutions adaptéespouvant ê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 gestionTiendra compte de l’architecture à adopter, des équipements adéquats, de la plate-forme degestion et de la performance du réseau tout en ayant un coût optimal.

3


Contexte, justification et problématique

La ville de Cotonou est la capitale économique du Bénin. Elle dispose d’une densité de 9684,7habitants/ 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. Descentres économiques tels que le marché de Dantokpa, le port autonome, l’aéroport cardinalBernardin 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 accidentspar 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 lescarrefours de la ville. Ces statistiques sont plus amplement détaillées pour le département duLittoral 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 del’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 et4318,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 quatreagents, chacun dans une catégorie, ils font perdre à l’État béninois une somme de 26.611,95FCFA par mois [4]. Au millier de fonctionnaires qui utilisent chaque jour ces différents axesroutiers 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 ducarrefour Cica-toyota et cela sans compter les autres carrefour de Cotonou. La perte du tempset le gaspillage du carburant sont des conséquences des embouteillages directement assuméspar les usagers. D’autres coûts tels que, la hausse des coûts de production, la réduction de laproductivité 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

4


GPS mobiles ou embarqués dans certains véhicules) sur la circulation automobile en 2011 nousmontre que les embouteillages augmentent de façon significative, le stress physiologique desautomobilistes qui y sont coincés. L’augmentation du stress serait selon cette étude, dans lesmilieux de congestion est de 8,7% chez les femmes alors que chez les hommes, elle atteindraitla 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 pressionarté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èneparfois certains automobilistes à se déconcentrer, avec pour conséquence l’augmentation desaccidents [26]. Une étude effectuée à l’Institut Helmholtz Zentrum de Munich en Allemagne en2009 conclut aussi que le trafic routier dense pourrait augmenter fortement le risque de crisecardiaque [25].Cotonou enregistre chaque jour d’innombrables problèmes environnementaux qui menacentl’équilibre écologique et hypothèquent dangereusement la santé des populations du fait desflots d’embouteillage observés sur les axes routiers. La plupart des véhicules qui circulent surles quatre tronçons utilisent des moteurs diesel et à essence qui émettent à leur tour des fuméesnoires appelées polluants comme le dioxyde de carbone, les monoxydes d’azote qui sont desgaz très dangereux pour l’environnement et la santé des populations [7]. En effet, le dioxyded’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 carburantsont autant de facteurs qui contribuent à la pollution atmosphérique» [5]. Ainsi, la congestiongé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 gravessur l’appareil respiratoire. Notons aussi que cette pollution est davantage provoquée par lesgaz d’échappement provenant de la voiture située en première position surtout lorsque celle-cis’arrête et accélère plusieurs fois de suite. L’air à Cotonou est alors chargé de plomb et devientde plus en plus irrespirable à cause des gaz d’échappement [6]. Les embouteillages constituentalors un problème majeur à Cotonou. Plusieurs maladies liées à ce fait sont enregistrées chaquejour 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 auBénin. En ce qui concerne les feux tricolores, il s’agit donc de disposer d’un système de gestionen 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 desfeux tricolores, en s’intéressant spécifiquement à l’aspect de la commande des feux tricolores,

5


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 detransmission et de contrôle adéquat, robuste et flexible, intégrant les normes techniques et lesrécentes technologies en la matière. Le système de gestion centralisé des feux tricolores faitl’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 biendé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 unevisualisation de leur état, avec possibilités de modification de leurs programmations entemps 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.

6

Chapitre 1Analyses 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, lagestion du trafic routier nécessite des infrastructures adaptées (dimensionnement géométriquede la route) et une réglementation appropriée pour les usagers faces à ces infrastructures. Letrafic routier est donc, un phénomène naturellement au sein duquel les interactions entre lesdifférents usagers et leur environnement constituent le cœur du fonctionnement. Ce systèmede 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 perturbationpeut, 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 laroute 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éhiculesde caractéristiques variés (poids lourds/légers) ;

3 complexité : un système est qualifié de complexe lorsqu’un observateur ne peut prévoirson 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

7

Chapitre 1. Analyses et caractéristiques du trafic routier 1.1. La voirie

véhicules étant peu sensibles au changement de l’état du trafic [10], ce qui n’est pas le cas surles 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 etde 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 detransmission 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’agitdes 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.

TABLEAU 1.1 – Mode de transmission sans fils

[11]Type Wifi Wimax ZigBee Bluetooth GSMvitesse 11-

300Mbps70Mb/s 250Kbps 1-

8Mbps9,6kpbs -1Go/s

distance 50m 50km 300-1500m

50m 4 - 20Km

fréquence 2.4GHz-10GHz

10Ghz-66GHz

2.4GHz 2.4GHz 800MHz-2600MHz

Puissancedémis-sion

grande Trèsgrande

Trèsfaible

faible Trèsgrande

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 commesuit dans le tableau 1.2 :Dans ce travail, le réseau GSM pour la transmission, spécialement son service des messagescourts(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-due du territoire béninois, mais spécialement dans la ville de Cotonou. Le coût des travaux de

8

Chapitre 1. Analyses et caractéristiques du trafic routier 1.1. La voirie

TABLEAU 1.2 – Supports physiques du mode de transmission par câble

[41]type Paire torsadée coaxiale Fibre optique

distance 100m 1km 50kmdébit 100Mbit/s 1Gbit/s 1Tbit/scoû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 detransmission 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 desSMS en GSM, un serveur spécial appelé SMS Center (SMSC ou SC) [12], est implémenté et estresponsable du stockage et du transfert. L’appareil responsable de l’envoi ou de la réception deSMS est le SME (Short message entity) [20], le SME peut être situé dans un équipement fixe telqu’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). LeSC 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 leMSC. 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 renvoyerles 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 doitenvoyer 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]. Ceciest illustré par la figure 1.1.

9

Chapitre 1. Analyses et caractéristiques du trafic routier 1.2. Services GSM

FIGURE 1.1 – Architecture physique[29]

1.2 Services GSM

La fonction essentielle du GSM est la communication de phonie, il permet également l’envoi decourts 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 recevoirun message textuel d’au plus 160 caractères (codés à l’aide d’ASCII 7 bits sur 140 octets) entredeux terminaux mobiles GSM. Les messages courts SMS sont spécifiés par l’ETSI (EuropeanTelecommunications Standards Institute). Nous distinguons quatre catégories de service desmessages 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çonsde transmettre un message SMS, soit en mode PDU (Protocol Description Unit) soit en modeTEXT. 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 modulesGSM. 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 suitebinaire. Différents types de codage sont utilisés pour passer du mode PDU en mode TEXT. Leplus 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].

10

Chapitre 1. Analyses et caractéristiques du trafic routier 1.3. Le module GPRS Shiels SIM 900

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, issusde la couche applicative SM-AL (Short Message Application Layer). Son format est défini parla recommandation ETSI 3.40 de GSM et un en-tête doit être ajouté pour préciser l’adresse dedestination 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 leré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 vuede haut

FIGURE 1.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 .

11


FIGURE 1.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 paysdu 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

12


1.3.2 Les commandes AT

À l’avènement des modems, les modems Hayes ont été un standard qui étaient programmésavec un ensemble de commandes Hayes communément appelées les commandes « AT », ATpour dire «Attention». Mais malgré l’augmentation des fabricants de modems, beaucoup ontadhéré, plus ou moins, au standard Hayes. Pour la manipulation d’un modem GSM [8], on abesoin 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 commandede 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 maximaled’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étectiond’erreur, il envoie un message d’erreur sans traiter les commandes pouvant se trouver derrièrela commande ayant occasionné l’erreur [28].

1.3.4 Fonctionnement

La figure 1.4 présente le schéma du fonctionnement des commandes AT.

FIGURE 1.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

13

Chapitre 1. Analyses et caractéristiques du trafic routier 1.4. Différentes stratégies de régulation via les feux de circulation

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.3suivant peuvent être utilisées :

TABLEAU 1.3 – Commandes AT dédiées au service SMS

[28]AT+CSMS Sélection du service de messagerieAT+CPMS Sélection de la zone mémoire pour le stockage des SMSAT+CMGF Sélection du format du SMS (PDU ou TEXT)AT+CSCA Définition de l’adresse du centre de messagerieAT+CSDH Affiche en mode TEXT le paramétrage des SMSAT+CSAS Sauvegarde du paramétrageAT+CRES Restauration du paramétrage par défautAT+CNMI Indication concernant un nouveau SMSAT+CMGL Liste les SMS stockés en mémoireAT+CMGR Lecture d’un SMSAT+CMGS Envoie un SMSAT+CMSS Envoi d’un SMS stocké en mémoire

AT+CMGW Écriture d’un SMSAT+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. Ils’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é, -leflux 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.

14


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 moinssophistiqué en vue de prédire ces états futurs.

Le troisième modeule permet l’optimisation des paramètres des plans de feux qui permettentde minimiser le temps de parcours d’un flux donné, les temps d’attente aux carrefours ou lenombre de voitures dans le réseau.

Chaque stratégie a ses propres variables mesurées, son propre module de prédiction et sonpropre 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 parla philosophie de l’approche (notion de cycle fixe, instants de basculement du vert au rouge, etautres). 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 feuxfixes 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 CycleOffset 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 deplans de feux de circulation, favorisant les transports en commun. Il fournit un plan optimaldu point de vue des durées de feu vert. Le choix de la durée du cycle doit être effectué entre lesdifférents plans disponibles au poste de commande selon la situation du trafic manuellementpar un opérateur lorsqu’il détecte un événement exceptionnel nécessitant une gestion adaptéeau réseau. De la comparaison de SCOOT à l’algorithme antérieur TRANSYT, une économiemoyenne de temps, de 12% a été réalisée aussi sur les retards [15]. Le SCATS , proposé en 1982en Australie par Lowrie [16], a la particularité de coordonner le trafic au niveau de plusieurscarrefours à 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 dedurées des phases de vert de façon explicite. La durée du cycle peut varier d’un cycle à unautre 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

15


feux se basant essentiellement sur les plans de feux fixes. Il permet l’ajustement des durées defeu vert d’un cycle à un autre. Pour recevoir une information, CRONOS utilise un traitementautomatique d’images vidéos. Une solution possible de l’algorithme CRONOS est une solutionsatisfaisant 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 auxlimites de la zone ,un algorithme acyclique sans phase de trafic définie à priori, des mesures detrafic par traitement d’images vidéos pour obtenir de meilleures informations que les bouclesmagné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 zoneet 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 configurationde 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 entemps 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éterminerle cycle et de réadapter constamment sa durée dans le temps et à chaque carrefour. Le calculdes 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 étattoutes les 2 à 5 secondes. Cela permet de définir une séquence optimale de commandes dansle temps pour minimiser le temps d’attente des véhicules circulant dans la zone. La méthodePRODYN peut s’appliquer aussi bien à des carrefours isolés qu’à des carrefours coordonnés. Larégulation d’un réseau de carrefours, s’effectue grâce à un échange convenable d’informationsentre carrefours immédiatement voisins.

16

Chapitre 2Architecture du réseau de gestion des feuxtricolores 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 étudeest subdivisée en deux modules qui sont le module de la conception d’une architecture detransmission de données entre les feux tricolores et le centre de gestion centralisée ainsi que lemodule de la conception d’une plate-forme de gestion centralisée des feux tricolores de notresystè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 parun 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 estcelle 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 lacaté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 villede 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.

17

Chapitre 2. Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou 2.2. Les feux tricolores dans la ville de Cotonou

Les feux tricolores fonctionnant à l’énergie solaire quant à eux sont moins répandus dans laville de Cotonou. Indépendants du courant électrique, ils peuvent réguler le trafic même encas de coupure d’électricité. Cependant, leur fonctionnement peut s’avérer défectueux dans lespé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 tricoloresest 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, uncarrefour) dont 22 fonctionnels avec 1 fonctionnant totalement à l’énergie solaire. En effet lamairie de Cotonou avait pris l’initiative de mettre en place un système d’alternance d’energieavec le solaire au niveau de 5 grands axes de la ville. Cependant le projet n’a pu aboutir fautede permutateur.Les feux tricolores sont programmés au niveau des boites fonctionnelles ou de contrôles enfonction du traffic, les délais d’attente et de circulation sont fixés afin de favoriser le sens de lacirculation ayant le plus d’affluence [3]. Les boîtes fonctionnelles sont des boite électrique doncfonctionnant 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 de5.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 sontassurées par la DST et quelques entreprises privées. Cependant, cette gestion n’est toujours pascentralisé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 ShieldSIM 900 qui se base sur la technologie Arduino pour décodé les données envoyées aux feuxtricolores en vue de l’exécution des commandes. Cette topologie est présentée à la figure 2.1.

18

Chapitre 2. Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou 2.2. Les feux tricolores dans la ville de Cotonou

FIG

UR

E2.

1–

Topo

logi

edu

rése

aud’

accè

slo

cald

ege

stio

nde

sfe

uxtr

icol

ores

19

Chapitre 2. Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou 2.3. Organisation géographique

2.3 Organisation géographique

Les informations obtenues à la direction des services techniques de mairie de Cotonou ontpermis d’avoir une meilleure compréhension de l’étendue de la répartition et de l’état des feuxtricolores 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 nombrede ces axes routiers des feux tricolores, dont certains ne sont plus en état de marche, comme leprésente le tableau 2.1.

TABLEAU 2.1 – Tableau de répartition des feux dans la ville de Cotonou [3]

N° Axe Nombre DénominationCarrefours

État

Cotonou Ouest : 401 Echangeur

Godomey-Carrefour CicaToyota

04 Mènontin(Béninmarché)

Non Fonctionnel

Agla Millena FonctionnelAgla Pylônes Non FonctionnelCica Toyota Fonctionnel

2 Cica Toyota-Étoile rouge

01 Agontinkon Fonctionnel

3 Étoile rouge-PAC

07 Yamadjako Fonctionnel

Prison civile Non FonctionnelUnafrica FonctionnelZongo Rue 117 Non FonctionnelZongo Mos-quée

Fonctionnel (tota-lement solaire)

Trois Banques Non FonctionnelPAC 117 Non Fonctionnel

20


4 Stade MathieuKEREKOU-Zogbo

01 Siège 10e Ar-rondissement

Fonctionnel

5 Zogbo- Maromilitaire

04 Ste Rita Fonctionnel

Okpè Oluwa FonctionnelAvana (Sikè-codji)

Fonctionnel

Maro militaire Fonctionnel6 Gbèdjromèdé

(Collège laRéférence)-Église NotreDame

07 BIBE Non Fonctionnel

Lègba Non FonctionnelDe Souza FonctionnelZinsou FonctionnelLa Gaité FonctionnelCiné Vog FonctionnelÉglise NotreDame

Fonctionnel

7 Lègba- Sogéma 02 Pharmacie lesquatre théra-pies

Non Fonctionnel

SOGEMA Non Fonctionnel8 Cica- Toyota-

Église BonPasteur

01 Mosquée Cadjè-houn

Fonctionnel

9 Trois Banques-Aéroport

06 Centre CultureChinois

Non Fonctionnel

Direction Géné-rale SONACOP

Non Fonctionnel

SONEB FonctionnelPlace de Souve-nir

Non Fonctionnel

Trésor Public Non FonctionnelAgence AirFrance

Fonctionnel

21


10 Hôtel du Port-CIC

02 Hôtel du Port Non Fonctionnel

Hôtel Ibis Non Fonctionnel11 Maro militaire-

Église St Michel02 Diversité Non Fonctionnel

Eglise St Michel Fonctionnel12 Camp Guezo 01 Camp Guezo Non Fonctionnel13 Direction Ré-

gionale Littoral1 de la SBEE

01 Direction Ré-gionale Littoral1 de la SBEE

Non Fonctionnel

14 Pharmacie Jon-quet

01 Pharmacie Jon-quet

Non Fonctionnel

Cotonou Est : 1715 Vieux Pont- SO-

BEBRA04 Cimetière Ap-

kapkaNon Fonctionnel

Stade RenéPLEVEN

Non Fonctionnel

Clinique BONI Non FonctionnelSOBEBRA Fonctionnel

16 Dédokpo-SOBEBRA

02 Dédokpo Fonctionnel

Egile Sacré-Cœur

Fonctionnel

17 EPP Avotrou 01 EPP Avotrou Pas mis en service18 SOBEBRA – Le

Bélier10 DMTP Non Fonctionnel

OPT Pk3 Non FonctionnelEx MABECY Non FonctionnelGBB Non FonctionnelDEGAKON Non FonctionnelEx SBAC Non FonctionnelAbattoir Non FonctionnelBlanchisserieFRANITA

Non Fonctionnel

PharmacieAbattoir

Non Fonctionnel

Le Belier Non Fonctionnel

22


2.3.2 Emplacement géographique des feux tricolores et proposition d’un centrede 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 feuxtricolores de la ville de Cotonou, réalisé dans le cadre du projet Asphaltage par la mairie de laville 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 centrede gestion, nous avons opté pour le siège des services d’éclairages publiques et de signalisationde la Direction des Services Techniques de la mairie de Cotonou. Le support de transmissiondans 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 tempsréel des feux tricolores dans la ville de Cotonou.

23


FIG

UR

E2.

2–

Empl

acem

entg

éogr

aphi

que

des

feux

etpo

siti

onne

men

tdu

cent

rede

gest

ion

Lége

ndes

Feu

tric

olor

e

Cen

tre

dege

stio

nce

ntra

lisée

24


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 constructiondu centre de gestion centralisée.

25


FIG

UR

E2.

3–

Plan

duce

ntre

dege

stio

nce

ntra

lisée

des

feux

tric

olor

esda

nsla

ville

deco

tono

u

26

Chapitre 3Étude conceptuelle du système de gestioncentralisée

3.1 Méthode de conception adoptée

Afin d’atteindre l’objectif poursuivi à travers cette étude, une approche méthodologique deconception appropriée à l’étude a été suivie. Pour cela, nous avons choisi la méthode du cycle enV [37] encore appelée méthode en cascade. Cette méthode de développement des applicationsest illustrée à la figure 3.1.

FIGURE 3.1 – Schéma de la méthode du Cycle en V[37]

27

Chapitre 3. Étude conceptuelle du système de gestion centralisée 3.2. Étude conceptuelle de la plate-forme de gestion centralisée des feux tricolores

Pour chacune des étapes illustrée à la figure 3.1, nous avons mené des activités données quinous 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 lechef division des signalisations lumineuses de la Direction des Services Techniques dela mairie de Cotonou qui nous a permis d’avoir une idée des besoins réels des futursutilisateurs 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é lamodélisation des différentes fonctionnalités et interactions qui seront prises en charge surla plate-forme finale ;

3 Le codage : à travers cette étape, grâce à des outils de développement d’application, nousavons 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éedes feux tricolores

3.2.1 Besoin fonctionnel

Les spécifications fonctionnelles décrivent les fonctions principales de la plate-forme, qui doiventsatisfaire, les besoins dégagés dans l’étude faite après l’entretien effectué avec le chef divisiondes signalisations lumineuses de la DST à savoir :

3 Authentification : Les utilisateurs de la plate-forme doivent s’authentifier à travers unidentifiant 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 deCotonou est donc une plate-forme d’administration à distances des feux tricolores de laville 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’unfeu 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 casde panne.

28

Chapitre 3. Étude conceptuelle du système de gestion centralisée 3.3. Modélisation

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’utilisateurpossède ses droits à utiliser des fonctionnalités données de la plateforme. Le tableau 3.1 donneun récapitulatif des fonctionnalités allouées à chaque profil d’utilisateur.

TABLEAU 3.1 – Récapitulatif des fonctionnalités allouées à chaque profil d’utilisateur

Fonctionnalité Utilisateur AdministrateurGestion des accès Non disponible DisponibleCréation ou modifi-cation des paramé-trages des feux pourun carrefour

Non disponible Disponible

Commande des feuxà distance et chan-gement des program-mations des feux

Disponible Disponible

Contrôle de l’état desfeux

Disponible Disponible

Ainsi donc, tels que présenté au tableau 3.1 le profil administrateur a en plus des droits d’accèsaux fonctionnalités du profil utilisateur, le droit d’accès aux fonctionnalités pouvant modifierla 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 dansl’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 standardpour 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 techniquesorientées objet, depuis la conception jusqu’à la maintenance, la création d’un langage abstraitcompréhensible par l’homme et interprétable par les machines [21], facilitant ainsi la compré-hension des besoins fonctionnels précédemment identifiés.

29


3.3.1 Diagramme de cas d’utilisation

Un cas d’utilisation dans le formalisme UML représente un ensemble de séquences d’actionsré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 lesinteractions 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 laplate-forme. Ainsi, parmis les fonctionnalités de la plate-forme identifiées précédemment, ilest déterminé les fonctionnalités qui correspondent aux besoins de chaque utilisateur. Cetteactivité a permis de concevoir le diagramme de cas d’utilisation globale de toute la plate-formede gestion centralisée des feux tricolores dans la ville de Cotonou. Ce diagramme regroupe lescas d’utilisation en deux paquetages distincts qui illustrent respectivement les interactions desdeux acteurs identifiés. La figure 3.2 illustre ce diagramme.

FIGURE 3.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étaillerchaque paquetage de cas d’utilisation.

30


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 ».

FIGURE 3.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 lacompose.

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 deconnaître l’état des feux en vue d’une maintenance au besoin

31


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 automatiquementaprè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 urgencetelle 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 uneprogrammation 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’utilisationqu’ils induisent.

32


FIGURE 3.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 mieuxles 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éationl’administrateur à la possibilité de lui accorder un profil d’utilisateur parmi les profilsexistants ;

æ Mise à jour d’un compte : ce scénario permet à l’administrateur de mettre à jour lesinformations du compte d’un utilisateur si entre temps des changements s’imposent ;

33


æ Suppression d’un compte : l’administrateur peut procéder à la suppression d’uncompte utilisateur quand cet utilisateur est dénié de ses fonctions ou ne respectepas 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 Description : Ce cas d’utilisation permet à l’administrateur de gérer les carrefours où sontimplantés les feux


3 Scénarios :

æ Création d’un carrefour : ce scénario permet à l’administrateur en cas d’installationde nouveaux feux à un carrefour de la ville, de créer dans la base de données lenouveau carrefour correspondant.

æ Mise a jour d’un carrefour : ce scénario permet à l’administrateur de mettre à jour lesinformations relatives à un carrefour donné.

æ Suppression d’un carrefour : ce scénario permet à l’administrateur de supprimer uncarrefour s’il arrivait que celui-ci se voit retirer ses feux tricolores pour une raison ouune autre

Cas d’utilisation «Gestion des feux»

3 Cas d’utilisation : Gestion des feux


3 Description :Ce cas d’utilisation permet à l’administrateur de gérer les feux


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 feutricolore s’il arrivait que celui-ci se fasse retirer pour une raison ou une autre.

34


Cas d’utilisation gestion des programmations

3 Cas d’utilisation : Gestion des programmations


3 Description : Ce cas d’utilisation permet à l’administrateur de gérer les programmationsdes feux.


3 Scénarios :

æ Création d’une programmation :ce scénario permet à l’administrateur de créer, pourles 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 unemeilleure 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 feuxtricolores, la visualisation schématique du fonctionnement interne de chaque scénario de casd’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 desdiffé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 raisonde simplicité. Il s’agit des scénarios suivants :

3 s’authentifier

3 Création de compte

3 Commande d’un feu

35


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.

FIGURE 3.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 utilisateursde 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.

36


FIGURE 3.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 decompte des utilisateurs de la plate-forme.

37


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.

FIGURE 3.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’unfeux tricolore à la plate-forme.

38


3.3.3 Diagramme de classe

Les spécifications détaillées de la conception ont permis de relever la pertinence de certainesclasses d’objets indispensables à la pertinence des données fonctionnelles de cette plate-formede gestion centralisée des feux tricolores. Les diagrammes de classe présentés de façon morceléerespectivement sur les figures 3.8 et 3.9 nous permettent d’identifier les classes et les différentesassociations qu’elles établissent entre elles pour permettre une souplesse dans la gestion desdifférents feux et de leur programmation au niveau des divers carrefours.

FIGURE 3.8 – Diagramme de classe 1

39


FIG

UR

E3.

9–

Dia

gram

me

decl

asse

2

40

Chapitre 3. Étude conceptuelle du système de gestion centralisée 3.4. Choix technique de réalisation et de conception du système

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 langagepython 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’articulecomplètement autour du modèle logiciel MVT (Model/View/Template) qui est une évolutiondu modèle logiciel MVC (Model/View/Controller, en français : modèle/vue/contrôleur) . Ila pour but de rendre le développement web 2.0 simple et rapide par ses capacités telles quela gestion automatique des comptes utilisateurs et des fonctionnalités d’administration de labase de données. Un système de validation des données entrées par l’utilisateur est égalementdisponible et permet d’afficher des messages d’erreurs automatiques. Le Framework Djangomet aussi à la disposition des développeurs un serveur web léger [33] couplé à SQLite quiest une bibliothèque en langage C qui fournit une base de données légère sur disque qui nenécessite pas de processus serveur distinct et permet d’accéder à la base de données à l’aided’une variante non standard du langage de requête SQL à travers l’interface SQLite3 [36]. Cecipermettant 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 fonctionsqui permettent à des applications de communiquer entre elles et de s’échanger mutuellementdes services ou des données [35]. L’API Twilio est donc une API de service web de téléphoniequi 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éseauGSM.

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 laconception d’application web, de Web Services, d’applications desktop et mobiles. Les langages

41


comme python et HTML peuvent exploiter ce même éditeur, ce qui permet un partage d’outilset une simplicité de création de solutions basées sur plusieurs langages. L’éditeur de texte Su-blime text intègre à part entière le Framework Django, permettant ainsi d’accéder à toutes lestechnologies clés de ce Framework qui simplifient le développement des applications web.

3.4.2.2 Visuel paradigm

Visual Paradigm est en général un éditeur de diagrammes qui propose une suite logicielle com-posée de plusieurs outils. Pour la modélisation de la plate-forme de gestion centralisée, il estuniquement employé Visual Paradigm for UML dans sa version communautaire 15.2.

3.4.2.3 Google Maps

Google Maps est un service de cartographie en ligne, et donc nous a aidé à réaliser la répartitiongéographique des feux tricolores et la localisation du centre de gestion centralisée de notresystème.

3.4.2.4 AutoCAD

AutoCAD ‘computer-aided design’ pour le CAD est un logiciel de disign professionnel qui aideà créer des images 2D et 3D. Ce logiciel nous a aidé à modéliser le plan du centre de gestioncentralisée des feux tricolores.

3.4.3 Environnement de test

3.4.3.1 L’Editeur Arduino 1.0.5

L’éditeur d’Arduino est un logiciel open-source qui rend facile l’édition, la compilation et letransfert de code sur les cartes Arduino. C’est un logiciel multi-plateforme (Windows, Mac OSX, Linux) écrit principalement en Java. Il est utilisable avec tous les modèles de cartes Arduino.

3.4.3.2 La carte Arduino UNO R3 et le module GPRS/GSM SIM 900

Pour une expérimentation, la carte Arduino UNO se présente comme le meilleur choix pourdébutant et convient parfaitement à tous ceux qui veulent faire leurs premiers pas avec unmicrocontrôleur. C’est la carte par excellence pour laquelle de nombreux exemples de montagessont disponibles sur Internet. Elle dispose d’un nombre suffisant de broches d’entrées-sortiespour des projets élémentaires et offre un vaste choix de modules complémentaires (shields)[22] tels que le module GPRS/GSM SIM 900 qui nous a permis d’interconnecter le montage dusystème de feu tricolore conçu,avec la plate-forme. Par contre, la mémoire disponible risqued’être un peu juste pour des gros projets et la carte n’offre pas beaucoup de périphériquesembarqués. Le Tableau 3.2 présente les spécificités techniques de la carte.

42


TABLEAU 3.2 – Spécifications techniques de la carte Arduino UNO

[22]

Microcontrôleur ATmega328PTension de service 5V

Tension d’entrée (recommandée) 7-12VTension d’entrée (limites) 6-20V

E/S numériques 14 (6 sorties commutables en MLI)E/S analogiques 6

Courant continu par E/S 20 mAMémoire Flash 32 KB (ATmega328P) dont 0.5 KB utilisé pour le bootloader

CSRAM 2 KB (ATmega328P)EEPROM 1 KB (ATmega328P)

Fréquence d’horloge 16 MHzDimensions 68.6 mm x 53.4 mm

Poids 25 g

43

Chapitre 4Résultats et discussion

4.1 Présentation de notre plate-forme

4.1.1 Architecture du projet dans Sublime texte

Pour l’implémentation de la plate-forme de gestion centralisée des feux tricolores, nous avonsutilisé l’éditeur Sublime Text pour développer l’application. L’architecture du projet Djangodéployée sous Sublime Text est illustrée à la figure 4.1.

FIGURE 4.1 – Architecture du projet dans Sublim Text

Sous Django, un projet comporte, plusieurs applications, le fichier db.sqlite3 où sont stockés lesdonnées de la base de données et un fichier manage.py qui contient les outils du FrameworkDjango. Cependant, pour notre étude une seule application a été développée dans le cadre denotre projet « trafic_routier » . Il s’agit de l’application «feuxtri_gestion_centralisée» . L’appli-cation « feuxtri_gestion_centralisée» , contient plusieurs dossiers et fichiers organisés suivantl’architecture de développement d’application MVT (Model-View-Template). Cette architecture

44

Chapitre 4. Résultats et discussion 4.1. Présentation de notre plate-forme

de conception nous a permis de séparer les logiques de persistance de données (Model), leslogiques de traitement de données (View) et les logiques de présentation de données aux utilisa-teurs finaux (Template ). Chaque dossier et fichier de l’application « feuxtri_gestion_centralisée»rempli un rôle spécifique dans le fonctionnement de la plate-forme de gestion centralisée denotre système. Afin de conserver la simplicité du présent document nous nous sommes focali-sés sur quelques uns des composants du projet. Il s’agit entre autres des dossiers et fichiers :

3 admin.py

3 models.py

3 Setting.py

3 Views.py

3 Dossier Template

3 Dossier Migration

4.1.2 Dossier feuxtri_gestion_centralisée

4.1.2.1 Fichier admin.py

Le fichier admin.py contient les paramètres qui permettent à Framework Django de prendre encharge l’administration de la base de données. Un aperçu du contenu du fichier admin.py estprésenté à la figure 4.2.

FIGURE 4.2 – Extrait du fichier admin.py

45


4.1.2.2 Fichier models.py

Le fichier models.py contient les classes présentées dans chapitre 3 pour l’architecture de labase de données. Un aperçu du contenu du fichier models.py est présenté à la figure 4.3.

FIGURE 4.3 – Extrait du fichier models.py

46


4.1.2.3 Fichier Setting.py

Le fichier Setting.py contient les paramètres qui assurent à la plate-forme développée un bonfonctionnement. Un aperçu du contenu du fichier Setting.py est présenté à la figure 4.4.

FIGURE 4.4 – Extrait du fichier setting.py

47


4.1.2.4 Fichier Views.py

Le fichier Views.py contient les contrôleurs définis dans le projet. Les contrôleurs, comme défi-nit dans l’architecture MVT servent d’intermédiaire entre la couche de persistance de données(base de données) et les interfaces utilisateurs. Un aperçu du contenu du fichier Views.py estprésenté à la figure 4.5.

FIGURE 4.5 – Extrait du fichier views.py

48


4.1.2.5 Dossier Templates

Le dossier Templates contient des sous-dossiers dans lesquels sont les fichiers dont sont res-ponsables les contrôleurs définis dans le fichier Views.py et qui présentent l’ensemble des vuesou interfaces utilisateurs que ce contrôleur gère. Chaque template est défini par un fichier auformat "*.html". Le contenu du dossier Templates est présenté à la figure 4.6.

FIGURE 4.6 – Contenu du dossier Templates

49


4.1.2.6 Dossier Migrations

Le dossier Migrations a pour rôle principal de contenir les versions de migration de la basede données liée au projet. Les migrations sont la manière par laquelle Django propage desmodifications qui sont apportées à des modèles (ajout d’un champ, suppression d’un modèle,etc.) dans la base de données. Elles sont conçues pour être quasiment automatiques. Un aperçude ce dossier est donné par la figure 4.7.

FIGURE 4.7 – Contenu du dossier Migrations

4.1.3 Présentation des Interfaces

Afin de mieux exploiter les fonctionnalités de la plate-forme de gestion centralisée de ce sys-tème, les utilisateurs peuvent interagir avec différentes interfaces offrant les différents servicesde commandes des feux tricolores. Dans cette section, nous présentons les interfaces et les fonc-tionnalités essentielles de notre plate-forme.

4.1.3.1 Page d’authentification

La page d’authentification permet aux utilisateurs de s’authentifier afin d’avoir accès aux fonc-tionnalités auxquels leurs profils leur permettent d’accéder. Le processus d’authentification né-

50


cessite que l’utilisateur entre un pseudonyme et un mot de passe. Cela est illustré dans la figure4.8.

FIGURE 4.8 – Contenu du dossier Migrations

4.1.3.2 Page d’accueil

La deuxième interface qui accueille un utilisateur après identification sur la plate-forme degestion centralisée de notre système est la "Page d’accueil ". Comme illustrée sur la figure 4.9ci-dessous, cette page fournit l’accès aux différentes rubriques de la plate-forme à savoir : larubrique de contrôle des états des feux tricolores par la sélection d’une zone de regroupementde feux ( un quartier) et la rubrique de commande des feux par la sélection d’un feu tricolorespécifique.

FIGURE 4.9 – Page d’accueil de la plate-forme de gestion centralisée des feux tricolores

51


4.1.3.3 Rubrique de contrôle des état des feux tricolores

L’une des interfaces auquelle donne accès la page d’accueil est la rubrique de contrôle des étatsdes feux qui donne les états des lampes de tous les feux tricolores dans une zone donnée envue de permettre de prompte intervention de maintenance en cas de besoins . La figure 4.10ci-dessous illustre cette rubrique.

FIGURE 4.10 – Page de contrôle des états des feux tricolores

4.1.3.4 Rubrique de commande des feux tricolores de la plate-forme

Une autre interface auquel donne accès la page d’accueil, est la rubrique de commande desfeux. Cette rubrique offre la possibilité en premier lieu, à ce carrefour de connaître l’état desfeux tricolores et de visualisé l’effet de leur programmation, mais en second lieu, de pouvoirles commander. Cela peut être soit le passage au vert d’un feu tricolore du carrefour ou duchangement de sa programmation. Cette rubrique est illustrée à la figure 4.11.

52


FIGURE 4.11 – Page de commande des états des feux tricolores de la plate-forme

53


4.1.3.5 Rubrique d’administration

La rubrique d’administration quand à elle, permet à l’administrateur de pouvoir gérer toutes lesactivités menées sur la plate-forme, à travers des ajouts, des modifications et des suppressionsde carrefours, de feux tricolores, de programmations et d’utilisateurs. Mais encore la gestionde l’API Twilio, responsable de l’envoie des commandes par les messages (SMS) à travers leréseau GSM. La figure 4.12 suivante illustre cette rubrique.

FIGURE 4.12 – Page d’administration de la plate-forme

54


4.1.4 Expérimentation

4.1.4.1 Schéma du montage

La Figure 4.13, réalisée avec le logiciel Proteus, présente le schéma du montage de feux tri-colores réalisé dans le cadre de l’expérimentation de notre système. Pour cette expérimentation,les difficultés,tel l’instabilité et les coupures du courant venu de la SBEE et la défaillance de cer-tain de nos relais dû à ces difficultés précédemment citées, nous ont amené à utilisé le courantde tension 12V en utilisant un convertisseur chargeur. Les composants utilisés pour la réalisa-tion sont listés dans le Tableau 4.1.

TABLEAU 4.1 – Liste des composants

Composant QuantitéArduino Uno 1

Module Shield SIM 900 1Lampes 12V 1W 12

Résistances 12Phototransistor 3Modules relais 12

Régistre 4Convertisseur chargeur 1

55


FIG

UR

E4.

13–

Sché

ma

dum

onta

geré

alis

éav

ecPr

oteu

s

56


4.1.5 Sécurité de la plateforme

L’une des questions importantes qui mérite d’être abordée dans tout projet de conception d’ap-plication de base de donnée est celle de la sécurité. Ainsi, afin d’assurer la sécurité globale de laplateforme de gestion centralisée des feux tricolores, trois points essentiels ont été étudiés. Cespoints sont les suivants :

3 la sécurité des données ;

3 la sécurité au niveau de l’application ;

3 et la sécurité du réseau d’accès au serveur d’application ;

Voyons en quoi les points énumérés ci-dessus sont importants pour garantir la sécurité et l’in-tégrité des données sur la plateforme.

4.1.5.1 Sécurité des données

Les données sauvegardées et traitées, pour les projets d’applications, sont des ressources sen-sibles dont l’intégrité et la disponibilité doivent être garanties à tout prix. Sur la plateforme degestion centralisée des feux tricolores, la sécurité des données utilisées peut être menacée dedeux façons à savoir :

3 par accès au Système de Gestion de Base de Donnée SQLite ;

3 et par la perte de données due au dysfonctionnement des disques de stockage ;

En ce qui concerne le risque d’accès au Système de Gestion de Base de Donnée SQLite, unemultitude de méthodes d’attaque existe. Cependant , le Framework Django offre une protectionintégrée contre la majorité des attaques visqnt la base de donnée tel que [39] :

æ le « Cross site scripting » (XSS) : qui consiste à un intrus d’injecter des scripts clients dansles navigateurs des utilisateurs ;

æ le « Cross site request forgery » (CSRF) : qui consiste à une personne malveillante d’exé-cuter des actions en utilisant les données d’authentification d’un autre utilisateur sansque ce dernier s’en rende compte.Il peut en résulter des modifications et des suppressionsd’enregistrements ;

æ l’injection SQL :qui consiste à ce qu’un utilisateur malveillant soit capable d’exécuter ducode SQL arbitraire sur une base de données ;

æ le détournement de clic (« clickjacking ») : qui consiste à ce qu’un site malveillant intègreun autre site dans un cadre. Cette attaque peut amener un utilisateur à cliquer de manièrenon désirée pour effectuer des actions non volontaires sur le site ciblé ;

57


Outre les risques d’accès au SGBD SQL Server, il y a également le risque de perte de donnéessuite à un dysfonctionnement des disques de stockage du serveur qui héberge notre base dedonnées. Ce type de risque peut être très couteux et fatal si les informations stockées sont vo-lumineuses. Ainsi, afin de limiter le risque de perte de données, nous préconisons les systèmesde stockages RAID(Redundant Array of Independent Disks) dans sa version RAID 2 [38]. Cettetechnologie permet de répartir les données sur plusieurs disques durs afin d’améliorer la sécu-rité et la tolérance aux pannes que peut subir l’ensemble du système de stockage de données.

4.1.5.2 Sécurité de l’application

D’autres sources de menaces peuvent également provenir des interfaces utilisateur de la plate-forme. Parmi les risques de sécurité liés aux utilisateurs, nous avons énuméré :

3 les risques liés aux privilèges accordés aux utilisateurs ;

3 les risques liés aux sources externes des données que traite la plate-forme ;

Les privilèges accordés aux utilisateurs est l’un des facteurs de sécurité les plus difficiles àmaitriser et peuvent devenir une véritable source de menaces quand par exemple un compted’utilisateur est mal utilisé ou a été volé. Pour palier un tant soit peu ce risque, nous avons usédu principe du moindre privilège qui consiste à allouer le moins de privilèges que possible auxutilisateurs courants.Ainsi, pour accéder aux fonctionnalités avancées de la plate-forme, uneauthentification est requise. Sur notre plate-forme, nous avons deux niveaux de profil d’utilisa-teur qui sont le profil Utilisateur et le profil Administrateur.La seconde source de menace est liée aux sources externes des données que traite la plate-forme qui sont multiples du fait de la communication entre la plateforme et les équipementsde contrôle des feux tricolores à travers le réseau GSM. Pour palier un temps soit peu ce risqueaussi, le choix s’est tourné dans un premier temps vers un système qui muni chaque équipe-ment de contrôle des feux tricolores d’un numéro de téléphone de réseau GSM unique et dansun second temps, au niveau de l’application web, vers le rejet de toute information provenantde numéro n’existant pas dans la base de données de cette application.

4.1.5.3 Sécurité du réseau

Pour assurer la sécurité du réseau LAN dans lequel notre application sera déployée, nouscomptons mettre en place un Reverse-Proxy qui constituera un pont entre les réseaux externescomme Internet et notre LAN. Cette mesure permet en effet d’amoindrir les attaques provenantde réseaux externes denses et incontrôlables comme Internet.

58

Chapitre 4. Résultats et discussion 4.2. Discussion

4.2 Discussion

4.2.1 Interprétation des résultats

Avant de pouvoir apprécier les résultats obtenus, il est important de rappeler les étapes del’appoche méthodologique de travail éffectué.Dans un premier temps, une synthèse bibliographique qui a permis essentiellement de nousimprégner des exigences en matière de gestion de trafic routier et des paramètres entrant enjeu en matière de commande d’équipements à travers le réseau GSM. Après cela, une étudedes modes de transmissions et de la répartition des feux tricolores dans la ville de Cotonou,a permis de concevoir un réseau d’accès adapté aux objectifs fixés. Ensuite, une synthèse desmatériels et méthodes qui nous ont permis de concevoir notre plate-forme a été effectuée.La question cruciale à laquelle nous devons répondre à présent est de savoir si les résultatsobtenus sont conformes aux objectifs que nous nous sommes initialement fixés. Rappelons queles objectifs émis au début des travaux sont les suivants :

3 (a) mettre en place un système sécurisé de gestion centralisé des feux tricolores pour unevisualisation de leur état, avec possibilités de modification de leurs programmations entemps réel ;

3 (b) exploiter la technologie des réseaux GSM du territoire béninois comme réseau detransport du système de gestion centralisé des feux tricolores ;

3 (c) proposer une architecture économique, mais efficace par rapport aux exigences fixées ;

Les tests de gestion des feux tricolores réalisés sur les cartes Arduino Uno, ont été concluants.Les actions associées aux différentes commandes sont exécutées dans l’ordre normal. Les don-nées de mise à jour au niveau des feux tricolores sont biens transmises à la plate-forme par lemodule Shield SIM 900 à travers le réreau GSM.Ainsi donc, l’objectif (a) a été pleinement atteint. Les fonctionnalités essentielles ressorties autravers des besoins exprimés par le chef division des signalisations lumineuses ont été implé-mentées sur la plate-forme développée et permettent d’une part, un suivi plus efficient de l’étatdes feux pour leur maintenance rapide et d’autre part une optimisation du trafic à travers lareprogrammation judicieuse des feux tricolores. Qinsi donc, ce système pourrait donc participéà la diminution des risque lié à la santé des population. Ces resultats sont confirmés par Co-rinne BRABAN et Florence BOILLOT, 2003 [23] dans la synthèse de INRETS (Institut Nationalde Recherche sur les Transports et leur Sécurité),’ Les systèmes temps réels de commande defeux en milieu urbain ’. Pour eux, la stratégie de régulation CRONOS qui est un système derégulation temps réel par commande des feux après analyse des informsations fournies pardes capteurs, permet une diminution de 35 à 50% des congestion de trafic avec un gain moyenen fluidité pour un véhicule de 20% sur le temps d’attente et 11% sur son nombre d’arrêts au

59


carrefour. En ce qui concerne l’aspect santé, l’avis partagé par DANSOU Sylvie, de l’AgeenceBéninoise de L’environnement dans "Impact de la pollution atmosphérique sur la santé des po-pulations de Cotonou"[42]. Pour elle ayant analysé les fréauences des véhicules pollueurs etnon pollueurs pour les véhicules à quatre roues et à deux roues de 2001 à 2003, au cours de laphase de sensibilisation du principe pollueur-payeur désormais instauré et dont les taxes fixéesont été intégrées à la loi des finances 2003-2004, remarque que la tendance générale du nombrede véhicules pollueurs est à la baisse d’année en année.

Les objectifs (b)et (c) ont été pleinement atteints aussi, car la communication entre les feuxtricolores et la plate-forme de gestion centralisée du système à été effectuée par le réseau GSMdu territoire sans une grande modification des infrastructures des feux tricolores existants quiauraient occasionné de très grands coûts de réalisation. C’est aussi l’avis des chercheurs LiuBo, Zhang Fusheng,2013 [11], de la ’North China University of Technology’,de Beijing qui onttravaillé sur un système de controle des signaux du trafic routier basé sur une technologie sansfils. Pour eux, le choix d’un support de transmission sans file est primordiale du fait qu’il estplus facile à faire évoluer et à entrenenir. Cela ne nécssite pas de toucher à la structure de lavoie et donc n’interrompe pas le trafic. Tout ceci à un faible coup, mais avec une haute fiabilité.Cependant leur choix s’est porté sur le ZigBee dont la mise en place couterait plus chère quenotre système du fait de la nécéssité de la mise en place au préalable du système d’interconec-tion qui existe déja au niveau du réseau GSM.

Après avoir évalué l’atteinte de nos objectifs, nous pouvons attester que notre système de ges-tion centralisée des feux tricolores peut vraiment aider à l’optimisation du trafic routier. Lesprogrammations des feux qui habituellement se font au niveau des feux tricolores peuvent êtreà présent effectuées depuis le centre de gestion centralisée de notre système, avec plus de rapi-dité et d’efficacité.

4.2.2 Limites et recommandations

À travers la recherche bibliographique que nous avons effectuée au début de nos travaux, noussavons que la gestion centralisée des feux du trafic routier n’implique pas seulement la com-mande à distance des feux tricolores. Une plate-forme de gestion centralisée des feux peut, enplus de la commande à distance des feux, aussi intégrer la vidéosurveillance couplée au radar,une géolocalisation et plus encore , ceci avec un système de feux tricolores intelligent capablede définir la programmation de feux adéquats au trafic à un instant donné et muni d’un sys-tème d’énergie en rédondance ou alternance entre l’énergie conventionnelle et lénergie solaire.Ainsi, nous comprenons que la version actuelle de notre plate-forme peut être encore amélioréeen vue d’une meilleure gestion du trafic.Dans le but d’élargir et d’améliorer les services fournis par notre plate-forme, d’autres étudespourront être effectuées.

60

Conclusion et perspectives

Tout au long de nos travaux, nous nous sommes essentiellement attelés à la conception d’unesolution capable de favoriser la gestion efficiente du trafic routier dans la ville de Cotonou àtravers un système de gestion centralisée des feux tricolores en vue d’impacter positivement lasécurité routière et le bien être des populations. En effet, une étude nous à permis de choisir leréseau GSM à travers son service de message court (SMS) pour la communication entre les feuxtricolores et le centre de gestion de notre système. A partir des besoins fonctionnels expriméspar le chef division des signalisations lumineuses avec qui nous avons étroitement collaboré,nous avons pu modéliser les fonctionnalités essentielles de notre plate-forme. Ensuite les maté-riels et les méthodes de conception que nous avons employés, nous ont permis de traduire lesbesoins recueillis en rubrique de fonctionnalités au niveau de notre plateforme . Cette dernièreintègre :

3 un menu de changement de programmation et de commande des feux tricolores ;

3 un menu de contrôle des états des feux tricolores ;

3 un système d’authentification permettant aux utilisateurs d’accéder aux différentes ru-briques ;

La rubrique de changement de programmation et de commande des feux tricolores développéepermet au besoin de passer au vert un feu tricolore et de modifier aisément les programmations.La rubrique de vérification de l’état de feux tricolores quant à elle, permet de connaître l’état desfeux tricolores de façon générale et celui de leurs lampes de façon spécifique en vue d’effectuerdes maintenances au besoin. L’accès aux fonctionnalités précédemment citées nécessite une au-thentification qui permet à notre plate-forme de déterminer les niveaux et les droits d’accès del’utilisateur. Ainsi les échanges de données, les traitements et instructions envoyées depuis laplate-forme s’effectue au niveau des feux tricolores par le module GPRS/GSM SIM 900 Shielden vue de l’exécution de ces instructions. Notre système étant dynamique et évolutif, l’amélio-ration des services fournis par la plate-forme de gestion centralisée des feux tricolores, exigede futur études qui auront pour objectifs l’intégration de la vidéosurveillance couplé au radar.

61


Nous utiliserons donc un système intelligent de feux tricolores capable de définir la program-mation selon le trafic vu et analysé par les équipements de vidéosurveillance et les radas. Cesystème sera alimenté par des sources d’énergie en rédondance ou alternance entre l’énergieconventionnelle et l’énergie solaire.

62

Bibliographie

[1] Bickel OLOUDE Sécurisation de la ville de Cotonou par ´ vidéosurveillance via la fibre op-tique,Memoire de fin de formation pour l’obtention du diplome d’ingénieur de conceptiongrade master à l’Ecole Polytechnique d’Abomey Calavi,2017, 98 pages.

[2] Bassem Sammoud Contribution à la modélisation et à la commande des feux de signalisation parréseaux de Petri hybrides, In : Thèse préparée au sein du Laboratoire Systèmes et Transportsde l’Université de Technologie de Belfort-Montbéliard et au Laboratoire de Recherche Au-tomatique LARA de l’Ecole Nationale d’Ingénieurs de Tunis,111 pages.

[3] Direction des Services Techniques de la mairie,Fiche technique ;2018.

[4] Offin Lié Rufin Akiyo, Julien Adounkpe, Charles Lambert Babajide, Ikililou Akobi, BenoîtN’bessa L’embouteillage dans Les Grandes villes de L’Afrique de L’Ouest et ses Problèmes : Cas deCotonou au Bénin à la Faculté des Lettres et des Sciences Humaines(FLASH),2015. .

[5] AKOBI, I., Embouteillage au niveau du carrefour Akossombo de Cotonou : causes et conséquences,Mémoire de Licence professionnelle en Gestion des projets, 2014,ESTI-Bénin, 73 pages.

[6] AKIYO, R. L’occupation de la Commune fluvio-lacustre de Sô-Ava : les fondements d’une adaptationoriginale et d’une mise en valeur économique d’un environnement spécifique du sud-Bénin. Thèse deDoctorat Unique en Gestion de l’Environnement,, 2012, FLASH/EDP/UAC, 372 pages.

[7] BOKO M. Pollution de l’environnement et santé publique. Edition revue et corrigée, 2005, 160pages.

[8] Wissem HENI ; Imen Hmaied Mise en place d’une plateforme de télécommande des équipementsélectriques à distance « Smart House »,MÉMOIRE DU PROJET DE FIN D’ÉTUDES pour l’ob-tention de la Licence Appliquée en Sciences et Techniques de l’Information et de Commu-nication à l’Université de Tunis,2011, 69 pages.

[9] Doniec A., Espié S., Mandiau R. et Piechowiak S., Simulation de trafic routier en carrefour :gestion des comportements et des priorités, In International Workshop Logistique & Transport,Hammamet 2006.

63

BIBLIOGRAPHIE BIBLIOGRAPHIE

[10] Yagar S. Corridor control system, Concise Encyclopaedia of Traffic and Transportation Sys-tem, Editor Papageorgiou M., 1991, 79-83.

[11] Liu Bo, Zhang Fusheng Traffic Signal Control System Based on Wireless Technology,Third In-ternational Conference on Intelligent System Design and Engineering Applications, 2013.

[12] Diana-Minodora Ciuraru, Lavinia Hilohi, Antoine Mercier, Xavier Lagrange SMS overLTE : services, architecture and protocols,,https ://hal.archives-ouvertes.fr/hal-00814264, pp7.

[13] Papageorgiou M., Dynamic Modelling, Assignement and route Guidance in Traffic Net-works,Transp. RES. B, Vol. 23, n° 6, pp. 471-495,1990.

[14] Hunt P.B., Robertson R.D., Bretherton R.D. and Royle M.C. The SCOOT on-line traffic signaloptimisation technique,Traffic Engineering and Control, Hemming Group, Limited, 1982, 190-199.

[15] Langlais G., De Soras A. Gestion du trafic par auto-organisation optimale,École des Ingénieursde la Ville de Paris (EIVP), TER 2008.

[16] Lowrie P.R. Scats : The sydney co-ordinated adaptive traffic system-principles, methodology, al-gorithmsProceedings of the IEE International Conference on Road Traffic Signalling, 1982,67-70.

[17] Boillot F., Blosseville J., Lesort J., Motyka V., Papageorgiou M. and Sellam S. Optimal signalcontrol of urban traffic networks, 6th International Conference on Road Traffic Monotoringand Control, London 1992, 75-79.

[18] Henry J.J. The PRODYN Real time Traffic Algorithm,4th IFAC/IFIP/IFORS InternationalConference on Control in Transportation Systems, 1983, 307-311.

[19] Trosby F., Holley K., Harris I. Short Message Service (SMS) – the creation of personal global textmessaging, A John Wiley and Sons, Ltd., Publication,2010.

[20] BENDJAFER HICHAM, MIDOUN ANESSE Système de contrôle par GSM,2017.

[21] Benoit charroux, Aomar Osmani, Yann Thierry-Mieg Sythèse de cours et exercice corrigé ,UML 2 2e édition, collection Synthex.

[22] Narcisse Dimon ASSOGBA Editer et Projeter des Grafcets sur une Architecture Arduino , Me-moire de fin de formation pour l’obtention du diplome d’ingénieur de conception grademaster à l’Ecole Polytechnique d’Abomey Calavi,2017.

[23] Corinne BRABAN Florence BOILLOT, Les systèmes temps réel de commande de feux en milieuurbain, Synthèse INRETS, 2003.

64


[24] Population de Cotonou https://www.populationdata.net/pays/benin/ consultéle 12 Octobre 2018.

[25] les embouteillages dangereux pour la sante cardiaque https://www.maxisciences.

com/trafic/les-embouteillages-dangereux-pour-la-sante-cardiaque_

art1195.html consulté le 04 Août 2018.

[26] Circulation bouchon etude sante embouteillages https://www.autoplus.

fr/actualite/circulation-bouchon-etude-sante-embouteillages-

1441065.html consulté le 10 Août 2018.

[27] Le service de messages courts de GSM (SMS) http://jaaayyy.chez.com/html/

Radiomobiles/stage/SMS.html consulté le 08 Août 2018.

[28] Commandes AT http://www.technologuepro.com/gsm/commande_at.htm

consulté le 20 Aout 2018.

[29] Commandes AT https://dzone.com/articles/connecting-the-connected-

reference-architecture-fo consulté le 20 Décembre 2018.

[30] Guide to SIM900 GSM GPRS Shield with Arduino https://randomnerdtutorials.

com/sim900-gsm-gprs-shield-arduino/ consulté le 7 Septembre 2018.

[31] GSM/GPRS Shield Datasheet http://www.tinyosshop.com/datasheet/GSM%

20Shield%20Datasheet.pdf consulté le 01 Novenbre 2018.

[32] UML https://batteursby.cf/documents/creation-de-diagrammes-uml-

avec-myeclipse-uml-plugin.html consulté le 02 Janvier 2019.

[33] Présentation de django http://apprendre-python.com/page-django-

introduction-python consulté le 03 Janvier 2019.

[34] Utilisation de Twilio pour les fonctionnalités vocales et de SMS https://docs.

microsoft.com/fr-fr/azure/partner-twilio-java-how-to-use-voice-sms

consulté le 04 Novembre 2018.

[35] Interface de programmation : API ou Application Programming Interface https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203559-api-

application-programming-interface-definition-traduction/ consulté le 03Janvier 2019.

[36] sqlite3 — DB-API 2.0 interface for SQLite databases https://docs.python.org/3.4/library/sqlite3.html consulté le 04 Janvier 2019.

65

https://www.populationdata.net/pays/benin/

https://www.maxisciences.com/trafic/les-embouteillages-dangereux-pour-la-sante-cardiaque_art1195.html



https://www.autoplus.fr/actualite/circulation-bouchon-etude-sante-embouteillages-1441065.html



http://jaaayyy.chez.com/html/Radiomobiles/stage/SMS.html

http://jaaayyy.chez.com/html/Radiomobiles/stage/SMS.html

http://www.technologuepro.com/gsm/commande_at.htm

https://dzone.com/articles/connecting-the-connected-reference-architecture-fo

https://dzone.com/articles/connecting-the-connected-reference-architecture-fo

https://randomnerdtutorials.com/sim900-gsm-gprs-shield-arduino/

https://randomnerdtutorials.com/sim900-gsm-gprs-shield-arduino/

http://www.tinyosshop.com/datasheet/GSM%20Shield%20Datasheet.pdf

http://www.tinyosshop.com/datasheet/GSM%20Shield%20Datasheet.pdf

https://batteursby.cf/documents/creation-de-diagrammes-uml-avec-myeclipse-uml-plugin.html

https://batteursby.cf/documents/creation-de-diagrammes-uml-avec-myeclipse-uml-plugin.html

http://apprendre-python.com/page-django-introduction-python

http://apprendre-python.com/page-django-introduction-python

https://docs.microsoft.com/fr-fr/azure/partner-twilio-java-how-to-use-voice-sms

https://docs.microsoft.com/fr-fr/azure/partner-twilio-java-how-to-use-voice-sms

https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203559-api-application-programming-interface-definition-traduction/



https://docs.python.org/3.4/library/sqlite3.html

https://docs.python.org/3.4/library/sqlite3.html


[37] Cycle de vie d’un ligiciel https://www.supinfo.com/articles/single/3210-cycle-vie-logiciel consulté le 15 Octobre 2018.

[38] Redundant Array of Inexpensive Disks https://www.prepressure.com/library/technology/raid consulté le 20 Octobre 2018.

[39] Sécurité au niveau du Framework Django https://docs.djangoproject.com/fr/

2.1/topics/security/ consulté le 12 Octobre 2018.

[40] Ali-Express, New and original Arduino UNO R3 ATMega328p ATMEGA16u2,2017https://ru.aliexpress.com/item/2017-Original-Arduino-UNO-R3-

ATMega328P-Official-genuine/32822270343.html,22 Dévembre 2018.

[41] Supports physiques,Transmission physique http://cpham.perso.univ-pau.fr/

ENSEIGNEMENT/COMMUN/SupportPhysique.pdf,16 Novembre 2018.

[42] Impact de la pollution atmosphérique sur la santé des populations de Co-tonou https://www.sifee.org/static/uploaded/Files/ressources/actes-

des-colloques/bamako/session-8/D_Dansou_comm.pdf,20 Mai 2019.

66

https://www.supinfo.com/articles/single/3210-cycle-vie-logiciel

https://www.supinfo.com/articles/single/3210-cycle-vie-logiciel

https://www.prepressure.com/library/technology/raid

https://www.prepressure.com/library/technology/raid

https://docs.djangoproject.com/fr/2.1/topics/security/

https://docs.djangoproject.com/fr/2.1/topics/security/

https://ru.aliexpress.com/item/2017-Original-Arduino-UNO-R3-ATMega328P-Official-genuine/32822270343.html

https://ru.aliexpress.com/item/2017-Original-Arduino-UNO-R3-ATMega328P-Official-genuine/32822270343.html

http://cpham.perso.univ-pau.fr/ENSEIGNEMENT/COMMUN/SupportPhysique.pdf

http://cpham.perso.univ-pau.fr/ENSEIGNEMENT/COMMUN/SupportPhysique.pdf

https://www.sifee.org/static/uploaded/Files/ressources/actes-des-colloques/bamako/session-8/D_Dansou_comm.pdf

https://www.sifee.org/static/uploaded/Files/ressources/actes-des-colloques/bamako/session-8/D_Dansou_comm.pdf

Annexe

67

Statistiques des accidents de la voie publique des années 2011,2012, 2013, 2014 et 2015

Année : 2011Conflits Accidents Véhicules Tués Blessés graves Blessés légersPL seul 97 97 0 1 8VL seul 142 142 1 19 272R seul 16 16 3 11 4PL/ PL 39 85 1 4 7PL/VL 395 839 6 17 37PL/2R 106 221 15 53 39

PL/Piéton 20 27 5 16 5VL/VL 1026 2242 9 43 131VL/2R 1054 2252 31 453 669

VL/VBH 11 24 0 2 8VL/Piéton 134 172 12 113 74

2R/2R 126 264 8 73 1252R/VBH 6 12 0 3 4

2R/Piéton 39 43 7 39 29Autre 24 51 0 5 10

TOTAL 3235 6483 98 852 1177

Année : 2011Type de route Accidents Véhicules Tués Blessés graves Blessés légers

RNIE 446 921 16 134 177Voirie urbaine 2733 5461 81 711 991

Autres 56 105 1 7 9Total 3235 6487 98 852 1177

Bilan des accidents à Cotonou en 2011

48PL : Poids Lourd49VL : Véhicule Léger502R : 2 Roues51VBH : Véhicule à Bras ou Hippomobile52RNIE : Route Nationale Inter-Etat53RN : Route Nationale

68

Année : 2012Conflits Accidents Véhicules Tués Blessés graves Blessés légersPL seul 94 94 0 4 1VL seul 142 142 1 23 322R seul 46 47 16 26 7

VBH seul 1 1 0 0 1PL/PL 45 102 1 1 0PL/VL 372 798 4 18 35PL/2R 84 176 7 42 38

PL/VBH 2 4 0 0 0PL/Piéton 14 17 4 11 1

VL/VL 890 1962 8 45 131VL/2R 939 1991 16 441 699

VL/VBH 10 25 0 1 5VL/Piéton 126 177 8 97 83

2R/2R 157 320 3 113 1812R/VBH 3 6 0 2 1

2R/Piéton 86 91 10 75 63Autre 20 37 0 6 7

TOTAL 3031 5989 78 905 1285text



Autres 52 90 2 11 11Total 3031 5990 78 905 1285


69

Année : 2013Conflits Accidents Véhicules Tués Blessés graves Blessés légersPL seul 105 105 0 1 5VL seul 152 152 3 22 292R seul 82 82 12 43 31PL/PL 29 72 2 2 8PL/VL 343 735 4 27 17PL/2R 102 222 11 40 66


VL/VBH 5 10 0 1 0VL/Piéton 117 152 11 81 76

2R/2R 216 447 9 148 2422R/VBH 7 14 0 5 4

2R/Piéton 133 137 9 112 112VBH/Piéton 1 1 0 1 0

Autre 32 68 4 9 17TOTAL 3135 6085 91 885 1532



Autres 134 238 4 29 39Total 3135 6085 91 885 1532


70

Année : 2014Conflits Accidents Véhicules Tués Blessés graves Blessés légersPL seul 115 115 0 1 2VL seul 189 189 7 40 402R seul 77 77 11 51 19PL/PL 40 86 1 2 2PL/VL 472 1025 6 27 60PL/2R 93 199 13 56 54


VL/VBH 5 10 0 0 1VL/Piéton 122 157 14 70 85

2R/2R 219 460 8 154 2972R/VBH 13 30 0 10 12

2R/Piéton 127 133 9 144 98Autre 49 97 1 11 22

TOTAL 3432 6634 100 976 1547text



Autres 365 683 11 127 120Total 3432 6634 100 976 1547


71

Année : 2015Conflits Accidents Véhicules Tués Blessés graves Blessés légersPL seul 94 94 2 1 1VL seul 179 179 1 38 592R seul 72 72 9 55 22PL/PL 33 80 0 2 3PL/VL 427 907 2 8 34PL/2R 112 261 21 52 57PL/VBH 2 4 0 0 1PL/Piéton 6 8 0 4 3VL/VL 1027 2235 8 31 129VL/2R 897 1885 15 362 705VL/VBH 5 10 0 1 0VL/Piéton 124 148 16 84 662R/2R 173 354 1 125 1962R/VBH 11 22 1 6 122R/Piéton 134 137 8 132 122Autre 39 71 2 6 16TOTAL 3335 6467 86 907 1429


RNIE 794 1557 25 210 338RN 117 234 2 25 65

Voirie urbaine 2120 4116 50 575 901Piste répertoriée 7 11 1 0 1

Autres 297 549 8 97 124Total 3335 6467 86 907 1429


72

English versionDesign and Experimentation of a

Centralized Traffic Light ManagementSystem in the city of Cotonou

73

Introduction

The development of any nation depends on of its environment’s parameters managements.Since the advent of motor vehicles, road traffic has emerged as one of the most important pa-rameters of development because it is used almost entirely by the population in the exercise oftheir economical activities. The improvement in the average standard of living and the rate ofhousehold equipment has enabled the greatest number of people to travel in private vehicles,leading to increasingly heavy road traffic [2]. However, road infrastructures are designed ac-cording to a demand projected at a certain moment to meet a collective optimum while eachindividual seeks to optimize his or her mobility while meeting his or her own specific criteria.This particularity makes road traffic a difficult phenomenon to analyze and optimize, especiallyin Benin since we have more motorcycles than cars in circulation [2].

The traffic control support infrastructure in Benin is the traffic light, the optimization of whichrepresents a real challenge. This state of affairs is reflected in the sometimes unjustified wait-ing times for traffic lights, such as at the Cica Toyota intersection in Cotonou, or in the poorprogramming observed at the Okpè Oluwa intersection in Cotonou, which often leads to acci-dents. This difficulty in managing fires is also manifested by the phenomenon of traffic conges-tion and poor traffic flow observed despite the presence of fires, the outcome of which requiresthe intervention of a police officer. Thus, the difficulty of managing traffic lights in traffic roadrepresents a major problem leading to crucial socio-economic problems and therefore requiresthe search for appropriate solutions that can be implemented in practice.

For this reason, in this thesis, we have focused on the control and maintenance of traffic lightsthrough a centralized management system. This management system will take into accountthe architecture to be adopted, the appropriate equipment, the management platform and theperformance of the network while with optimal cost.

74

Context, justification and problematic issues

The city of Cotonou is the economic capital of Benin. It has a density of 9684.7 inhabitants/km2.It houses the majority of the Republic’s institutions, state companies, head offices and agenciesof banks and large private companies. Economic centres such as the Dantokpa market, theautonomous port, cardinal Bernardin GANTIN airport... are not only assets, but also majorcontributors to the national budget and Benin’s visibility on the international scene [1].

Despite this, statistics on road accidents in the department of Littoral (Cotonou) over the pe-riod 2011 to 2015 show an average of 3234 accidents per year with 2390 fatalities and healthdamage. It is important to note that the scene of these road accidents in Cotonou is generallythe city’s crossroads. These statistics are more fully detailed for the Littoral department in thetables (contained in Appendix A).

En A study carried out on traffic jams, and their problems in the major cities of West Africa,has shown, with regard to traffic congestion at the Cica-toyota crossroads, the economic andsocio-environmental consequences that they cause if we consider only the case of permanentagents of the State. Economically, by taking four agents by vehicle, each in one of categoriesA, B, C and D, they cost the Beninese State an average of 35,578,824 FCFA per month. If theywere each on a motorcycle, they would cost the Beninese State CFAF 26,611.95 per month [4].In addition to the thousands of civil servants who use these various roads every day to accesstheir workplaces, there are also those in the private sector. The Beninese state therefore losesmillions of CFA francs every day because of the traffic jam at the Cica-toyota crossroads, not tomention the other crossroads in Cotonou [4].

The traffic congestion to which populations are subjected is not without consequences on theirstate of health. According to an American study commissioned by TomTom (a publisher ofroute planning software and a manufacturer of mobile or in-vehicle GPS navigation systems)on car traffic in 2011 shows that traffic jams are significantly increasing, the physiological stressof motorists stuck in them. According to this study, the increase in stress in congested areas is8.7% for women while for men it would reach the worrying increase of 60%. Such high ratesof increase are the cause of several problems such as reduced immune function and increasedblood pressure. Indeed, this physiological stress also influences the behavior of certain users inreturn and would therefore ultimately be at the root of certain diseases, in particular dizziness,shortness of breath as well as muscle and chest pain; this sometimes leads some motorists tolose concentration, with the result that accidents are on the rise [26].

Faced to all these implications of road traffic on the safety of citizens and on development, itis becoming essential to have an efficient road traffic management system in Benin. As far as

75

traffic lights are concerned, it is therefore necessary to have a real-time traffic light managementsystem to control them, to know their functional or non-functional status, and also the trafficsituation at their level. Thus, within the framework of this thesis, it is planned to improveroad traffic management by setting up a centralized traffic light management system, focusingspecifically on the aspect of traffic light control, and to recommend a traffic light architecturefor the city of Cotonou, based on GSM network technology. The recommended architecturemust technically allow an adequate, robust and flexible transmission and control system, in-tegrating technical standards and the latest technologies in this field. The centralized trafficlight management system is the subject of a detailed technical analysis in order to determine itsfeasibility.

Objectives of the project

For any end-of-training project, it is advisable to have well-defined objectives in mind. Theseobjectives are broken down as follows:

3 Set up a secure centralized traffic light management system to visualize their status, withthe possibility of modifying their schedules in real time.

3 Use GSM network technology from Benin as a transport network for the centralized trafficlight management system.

3 Propose an economic architecture (at a reduced cost), but effective in relation to the re-quirements set.

76

Chapter 5Road traffic analysis and characteristics

5.1 Roads

Road traffic is defined as all the complex phenomena resulting from the movement of users ona road network with limited capacity[9]. As the capacity of the road network is limited, in acontext where the scale of traffic is constantly increasing over time, road traffic managementrequires appropriate infrastructure and appropriate regulation for users in relation to this in-frastructure. Road traffic is, therefore, a natural phenomenon in which the interactions betweenthe various users and their environment constitute the core of the operation. This traffic systemhas the following characteristics that explain its difficulties in knowing:

3 Dynamic: Traffic phenomena are highly dynamic, with the number of stakeholders in-cluded in the system varying widely over time. A minor disturbance can, for example, beamplified and turn into congestion;

3 distribution: the traffic phenomena result from the interaction of each road user with hisenvironment;

3 heterogeneity: the road traffic system involves different actors, including heterogeneousdrivers (beginners/experienced), who can use, for example, vehicles with different char-acteristics;

3 complexity: a system is described as complex when an observer cannot predict its behav-ior or evolution or when one of its essential components (the driver) has, for example,unpredictable behavior [2].

5.1.1 Urban roads and highways

Thanks to their multi-lane and/or mainline topologies, highways offer good traffic flow [10],which is not the case on urban roads whose dimensions are smaller than those of motorways,so vehicle speeds depend on traffic density.

77

Chapter 5. Road traffic analysis and characteristics 5.2. GSM services

5.1.2 The intersections

An intersection is the meeting point of several streets, determining entry and exit corridors.The installation of a traffic light system at a crossroads then allows for coordination over timeof the admission of different vehicle flows [2].

5.2 GSM services

The essential function of GSM is voice communication, it also allows the sending of short mes-sages (SMS) and the transmission of data [9].

5.2.1 Short message services (SMS)

The Short Message Service (SMS) allows you to send and receive a text message of up to 160characters (encoded using 7-bit x 140-byte ASCII) between two GSM mobile terminals. ShortSMS messages are specified by ETSI (European Telecommunications Standards Institute). Wedistinguish four categories of service of short messages, namely, person-to-person, person-to-network or application, Internet-to-person and finally machine-to-machine [12]. There are twoways to send an SMS message, either in PDU (Protocol Description Unit) mode or in TEXTmode. TEXT mode allows you to send SMS messages without prior coding at the scanningstage, but it is not supported by most mobile phones and GSM modules. The PDU mode isthe basic mode. It first allows you to code the message to be sent in a sequence of hexadecimalcharacters before transforming it into a binary sequence. Different types of coding are used toswitch from PDU to TEXT mode. The most replied is the one called "7-bit GSM alphabet" whichoffers the maximum number of characters to send (160 characters). For this type of coding, eachcharacter is coded on seven bits [8].

5.3 The GPRS Shield SIM 900 module

GPRS/GSM Shield based on SIMCOM’s SIM900 module, provides a way to use the GSM net-work to receive and send data from two geographically remote locations. With this module,data exchanges can be carried out in three ways, namely [30] :

3 Short Message Service (SMS)

3 Audio

3 GPRS Service

The GPRS/GSM Shield module is compatible with all Arduino cards and can be configuredand controlled by AT command. Figure 5.1 shows the GPRS/GSM SIM 900 module seen fromabove.

78

Chapter 5. Road traffic analysis and characteristics 5.3. The GPRS Shield SIM 900 module

Figure 5.1 – GPRS/GSP module SIM 900 top view [30]

Figure 5.2 shows the GPRS/GSM SIM 900 module seen from below.

Figure 5.2 – GPRS/GSP module SIM 900 bottom view [30]

79

Chapter 5. Road traffic analysis and characteristics 5.4. Different control strategies via traffic lights

5.3.1 AT commands

With the advent of modems, Hayes modems were a standard that were programmed with aset of Hayes commands commonly referred to as "AT", AT commands to say "Attention". Butdespite the increase in modem manufacturers, many have more or less adhered to the Hayesstandard. To operate a GSM modem [8], you need to use a set of Hayes commands.

5.4 Different control strategies via traffic lights

A fire plan of a crossroads is determined by specifying four variables: the length of the cycle,the phase plan, the duration of each phase and finally the offset between the phases. Real-timeregulation strategies are generally based on three modules[13].The first module collects and processes measurements of traffic variables. This therefore in-volves the use of sensors that can be used to measure traffic variables, such as magnetic loopsthat measure the density, flow and number of vehicles in a road section; video cameras can alsoevaluate the length of the queue in front of a traffic light.

The second one generally allows to predict from the measured variables the future values ofthese same or other variables using a more or less sophisticated traffic model to predict thesefuture states.

The third mode allows the optimization of the parameters of the traffic light plans which makeit possible to minimize the travel time of a given flow, the waiting times at intersections or thenumber of cars in the network.

Each strategy has its own measured variables, its own prediction module and its own opti-mization module. The strategies also differ in the resolution approaches used (dynamic pro-gramming, heuristics, neural networks, and others) and even in the philosophy of the approach(notion of a fixed cycle, moments of switching from green to red, and others).

80

Architecture of a traffic light managementnetwork in the city of Cotonou

5.5 Technical organization

The design of the centralized traffic light management system, which is the subject of this study,is subdivided into two modules: the module for the design of a data transmission architecturebetween the traffic lights and the centralized management center, and the module for the designof a centralized management platform for traffic lights in our system.

5.6 Traffic lights in the city of Cotonou

Traffic lights are a major factor in road traffic management, thanks to their ability to manage theorientation of traffic towards a given axis. In Benin, traffic lights are managed by a departmentdepartment technical services of the town hall, which is the electricity, public lighting and lightsignalling department. The division of light signals is the one dealing specifically with trafficlights.

5.6.1 Types of traffic lights in Cotonou

Traffic light management necessarily involves energy management, which explains the catego-rization of traffic lights. Two energy sources are used for traffic lights in Cotonou. These areconventional and solar energy.

Traffic lights run on conventional energy, are the most widespread in the city of Cotonou. Theiradvantage is that they regulate traffic in all weather conditions. However, in the event of apower failure, these traffic lights stop regulating traffic.

Traffic lights powered by solar energy are less widespread in the city of Cotonou. Independent

81

Chapter 5. Road traffic analysis and characteristics 5.6. Traffic lights in the city of Cotonou

of the electrical power, they can regulate traffic even in the event of a power failure. However,their operation may be defective in periods of heavy rainfall.

It is also important to note that for these two types of traffic lights in the city of Cotonou, thereare some traffic lights that have a timer. This new contribution to traffic lights is very useful forusers who can now know their waiting times.

5.6.2 Installation and statistics of traffic lights

The process of installing a fire at a crossroads takes into account several criteria such as thetraffic flow at the crossroads, the strategic location of the crossroads, and the risk of accidentsat the crossroads. The city of Cotonou has 57 traffic light systems (one system, one crossroads),22 of which are functional with one running on solar energy. Traffic lights are programmed atthe functional or control boxes according to the different times of the day, waiting and traffictimes are set in order to favour the most crowded traffic direction [3]. The functional boxesare electrical boxes so they operate entirely with a voltage of 220V. But currently the CotonouCity Hall through an ongoing project, to acquire functional electronic boxes that operate with avoltage of 5.6V.

5.6.3 Traffic light management and maintenance

The proper management of traffic lights is of paramount importance given their major roles inroad traffic management. In Cotonou, fire management and maintenance is carried out by theDST and some private companies. However, this management is still not centralized. Dailypatrols make it possible to check the status of traffic lights.

5.6.4 Topology of the traffic light management network

This topology uses the base stations of the mobile networks to interconnect the traffic lights andthe centralized management center of our system. In addition, the traffic light interconnectionwas carried out using the GPRS/GSM Shield SIM 900 module, which is based on Arduinotechnology to decode the data sent to the traffic lights for order execution. This topology ispresented in the figure 5.3.

82

Chapter 5. Road traffic analysis and characteristics 5.6. Traffic lights in the city of Cotonou

Figu

re5.

3–

Topo

logy

ofth

elo

cala

cces

sne

twor

kfo

rtr

affic

light

man

agem

ent

83

Chapter 5. Road traffic analysis and characteristics 5.7. Geographical organization

5.7 Geographical organization

The information obtained from the Technical Services Department of the Cotonou City Councilprovided a better understanding of the extent of the distribution and condition of traffic lightsin the city of Cotonou.

5.7.1 Geographical location of traffic lights and proposal for a managementcenter in the city of Cotonou

In order to better assess the geographical distribution of traffic lights in Cotonou and to proposean appropriate management center, a cut was made on the traffic lights network of Cotonoucity, carried out as part of the Paving project by the city hall of Cotonou city. Subsequently,the control and command center was connected to all the lights through the BTSs for trafficoptimization. For the location of the management center, we opted for the headquarters ofthe public lighting and signalling services of the Technical Services Department of the CotonouCity Hall. The transmission medium in this network shown in Figure 5.4is the wireless mediumof the mobile network.The control and command center will then allow the real-time monitoring and control of trafficlights in the Cotonou city.

84

Chapter 5. Road traffic analysis and characteristics 5.7. Geographical organization

Figu

re5.

4–

Empl

acem

entg

éogr

aphi

que

des

feux

etpo

siti

onne

men

tdu

cent

rede

gest

ion

Lége

ndes

Feu

tric

olor

e

Cen

tre

dege

stio

nce

ntra

lisée

85

Conceptual study of the centralizedmanagement platform

5.8 Design methodology adopted

In order to achieve the objective pursued through this study, a methodological approach of de-sign appropriate to the study was followed. For this, we chose the V-cycle method [37] alsocalled the cascade method. This method of application development is illustrated in the figure3.1.For each of these steps, we carried out specific activities that enabled us to complete the cen-tralized traffic light management platform.

3 Needs analysis: during this stage, we conducted interviews with the head of the lightsignals division of the Technical Services Department of the Cotonou City Hall, whichgave us an idea of the real needs of future users of the platform;

3 The specification: at this step, the essential functionalities have been validated;

3 Preliminary and detailed design: during this step, we performed the modeling of thedifferent functionalities and interactions that will be supported on the final platform;

3 Coding: through this step, using application development tools, we designed the webplatform for centralized fire management;

3 Tests: they allowed us to ensure that each functional module of the platform meets thepredefined functional specifications

86

Chapter 5. Road traffic analysis and characteristics 5.9. Conceptual study related to the centralized traffic light management platform

5.9 Conceptual study related to the centralized traffic light man-agement platform

5.9.1 Identification of the platform’s actors

Two user profiles are emerging for the use of this centralized management platform. This is anadministrator profile and the user profiles. Each user profile has its own rights to use certainfeatures of the platform.

5.10 Modeling

At this level, we designed the use case diagrams, sequence diagrams and finally a class diagramillustrating the object classes involved in the implementation of the identified use cases. It wasused the UML (Unified Modeling Language) formalism to schematize the different steps of themodeling.

5.10.1 Use case diagram

A use case in UML formalism represents a set of sequences of actions performed by the sys-tem and producing an observable result, interesting for a particular actor. For each actor ithas been identified, the different needs that can lead him to use the platform. Thus from theplatform functionalities previously identified it is determined which functionalities correspondto the needs of each user. This diagram groups the use cases into two distinct packages thatrespectively illustrate the interactions of the two identified actors. The figure 5.5 illustrates thisdiagram.

87

Chapter 5. Road traffic analysis and characteristics 5.10. Modeling

Figure 5.5 – Global use case diagrams of the platform

5.10.2 Sequence diagram

The UML formalism provides us with sequence diagrams to express and detail in an under-standable way the progress of the different steps leading to the realization of each use case.

We will present the sequence diagrams of one scenario for simplicity. This scenario is:

3 Account creation

5.10.2.1 Scenario sequence diagram «<Account creation»

The sequence diagram of the "Account creation" scenario is presented in the figure5.6.

88

Chapter 5. Road traffic analysis and characteristics 5.10. Modeling

Figure 5.6 – Scenario sequence diagram «<Account creation»

5.10.3 Class diagram

The class diagrams presented in a fragmented manner on the figures respectively 5.7 and 5.8allow us to identify the classes and the different associations they establish between them toallow flexibility in the management of the different fires and their programming at the variousintersections.

89

Chapter 5. Road traffic analysis and characteristics 5.11. Technical choice of construction and design of the centralized traffic light management platform

Figure 5.7 – Class diagram: 1

5.11 Technical choice of construction and design of the central-ized traffic light management platform

5.11.1 Technology of realization

For the realization of the project it is mainly used technologies based on the python languageadapted to the Django Framework, including the Twilio API.

5.11.1.1 Sublime text

The Sublime text editor version 3.1 2018 is a complete development tool for the design of webapplications, Web Services, desktop applications. Languages like python and HTML can usethe same editor. It fully integrates the Django Framework.

5.11.1.2 Visual paradigm

For the modeling of the centralized management platform, only Visual Paradigm is used forUML in its version 15.2.

5.11.1.3 Google Maps

Google Maps is an online mapping service, and therefore helped us to achieve the geographicaldistribution of traffic lights and the location of our system’s centralized management center.

5.11.1.4 AutoCAD

This software helped us model the plan for the centralized traffic light management center.

90


5.11.2 Test environment

5.11.2.1 The Arduino Editor 1.0.5.5

The Arduino Editor is an open-source software that makes it easy to edit, compile and transfercode to Arduino cards. It is a multi-platform software (Windows, Mac OS X, Linux) writtenmainly in Java. It can be used with all Arduino card models.

5.11.2.2 The Arduino UNO R3 card and the GPRS/GSM SIM 900 module

Being a standard, the Arduino UNO card is the best choice for beginners and is perfect foranyone who wants to take their first steps with a micro-controller. This is the card par excellencefor which many assembly examples are available on the Internet. It has a sufficient number ofinput-output pins for basic projects and offers a wide choice of additional modules (shields)[22] such as the GPRS/GSM SIM 900 module which allowed us to interconnect the assembly ofthe designed traffic light system with the platform. However, the available memory may be alittle tight for large projects and the card does not offer many embedded devices. The Table 5.1presents the technical specifications of the card.

Table 5.1 – Technical specifications of the Arduino UNO card

[22]

Micro-controller ATmega328POperating voltage 5V

Input voltage (recommended) 7-12VInput voltage (limits) 6-20V

Digital I/O 14 (6 outputs switchable to PWM)Analog I/O 6

Direct current per I/O 20 mAFlash memoryh 32 KB (ATmega328P) , 0.5 KB used for the bootloader

CSRAM 2 KB (ATmega328P)EEPROM 1 KB (ATmega328P)

Clock frequency 16 MHzdimensions 68.6 mm x 53.4 mm

Weight 25 g

91


Figu

re5.

8–

Dia

gram

me

decl

asse

2

92

Results and discussion

5.12 Presentation of our platform

5.12.1 Presentation of Interfaces

In order to better exploit the functionality of the centralized management platform of this sys-tem, users can interact with different interfaces offering different traffic light control services.In this section, we present the interfaces and essential features of our platform.

5.12.1.1 Authentication page

The authentication page allows users to authenticate themselves in order to access the featuresthat their profiles allow them to access. The authentication process requires the user to enter anickname and password. This is illustrated in the figure 5.9.

Figure 5.9 – Contents of the Migration folder

93

Chapter 5. Road traffic analysis and characteristics 5.12. Presentation of our platform

5.12.1.2 Home page

The second interface that hosts a user after identification on our system’s centralized manage-ment platform is the "Home Page". As shown in the figure 5.10 below, this page providesaccess to the different sections of the platform, namely: the section for checking the status oftraffic lights by selecting a traffic light grouping area ( a district) and the section for controllingtraffic lights by selecting a specific traffic light.

Figure 5.10 – Homepage of the centralized traffic light management platform

5.12.1.3 Checking the status of traffic lights

One of the interfaces to which the home page gives access is the traffic light status controlsection which gives the status of the lamps of all traffic lights in a given area in order to allowprompt maintenance intervention in case of needs. The figure 5.11 below illustrated this section.

94


Figure 5.11 – Page of the traffic light status control section

5.12.1.4 Traffic light control panel

Another interface to which the home page gives access is the traffic light control section. Thissection offers the possibility, first, at this crossroads to know the state of the traffic lights andto visualize the effect of their programming, but second, to be able to order them. This can beeither the green light of a traffic light at the crossroads or a change in its programming. Thissection is illustrated in the figure 5.12.

95


Figure 5.12 – Page of the traffic light status control section

96


5.12.1.5 Administration section

The administration section allows the administrator to manage all the activities carried out onthe platform, through additions, modifications and deletions of intersections, traffic lights, pro-gramming and users. But also the management of the Twilio API, responsible for sending com-mands by SMS messages through the GSM network. The figure 5.13 the following illustratesthis section.

Figure 5.13 – Page d’administration de la plate-forme

97


5.12.2 Experimentation

5.12.2.1 Installation diagrams

The Figure 5.14, carried out with the Proteus software, present the diagram of the assemblyof traffic lights carried out as part of the experimentation of our system. For this experiment,difficulties, such as instability and power cuts, the SBEE and the failure of some of our relaysdue to these difficulties, led us to use 12V power using a converter charger. The componentsused for the realization are listed in the Table 5.2.

Table 5.2 – List of components

Component QuantityArduino Uno 1

Module Shield SIM 900 1Lamps 12V 1W 12

Resistors 12Phototransistor 3Relay modules 12

Registry 4Charger converter 1

98


Figu

re5.

14–

Dia

gram

sof

the

asse

mbl

yca

rrie

dou

twit

hPr

oteu

s

99

Chapter 5. Road traffic analysis and characteristics 5.13. Discussion

5.13 Discussion

After evaluating the achievement of our objectives, we can attest that our centralized trafficlight management system can really help optimize traffic flow. The traffic light programmingthat is usually done at the traffic lights can now be done from the centralized managementcentre of our system, with greater speed and efficiency.Through the bibliographic research we conducted at the beginning of our work, we know thatcentralized traffic light management does not only involve remote control of traffic lights. Acentralized traffic light management platform can in addition remote control of traffic lights,can also integrate radar-coupled video surveillance, Geo-location and more, with an intelligenttraffic light system capable of defining the programming of traffic lights suitable for traffic ata given time and equipped with an energy system in redundancy or alternating between con-ventional and solar energy. Thus, we understand that the current version of our platform canbe further improved for better traffic management.In order to expand and improve the services provided by our platform, further studies may becarried out.

100

Conclusion

Throughout our work, we have focused on designing a solution that will promote the efficientmanagement of road traffic in the city of Cotonou through a centralized traffic light manage-ment system with a view to positively impacting road safety and the well-being of the popula-tion. Indeed, a study allowed us to choose the GSM network through its short message service(SMS) for communication between traffic lights and the management centre of our system.Based on the functional needs expressed by the head of the light signal division with whomwe worked closely, we were able to model the essential functionalities of our centralized trafficlight management platform. Then the materials and design methods that we used, allowed usto translate the needs collected into functionalities rubrics at our platform level. The platformthat results from our work integrates:

3 a section for changing the programming and control of traffic lights;

3 a section for checking the status of traffic lights;

3 an authentication system allowing users to access the different sections;

The section for changing the programming and control of traffic lights developed allows youto change a traffic light to green if necessary and to easily modify the programming for trafficlights. The section on checking the status of traffic lights provides information on the statusof traffic lights in general and their lamps in particular, so that maintenance can be carried outif necessary. Access to the above-mentioned functionalities requires authentication that allowsour platform to define the levels and access rights to this platform. Thus, data exchanges andprocessing and instructions sent from the platform are carried out at the traffic lights by theGPRS/GSM SIM 900 Shield module in order to execute the instructions by the traffic lights.As our system is dynamic and scalable, improving it from the services provided by our central-ized traffic light management platform requires future studies that will aim to integrate videosurveillance coupled to radar and more. We will therefore use an intelligent traffic light sys-tem capable of defining the programming according to the traffic seen and analysed by videosurveillance equipment and radars. This system will be powered by energy sources that areredundant or alternate between conventional and solar energy.

101

-

Table des matières

Remerciements iii

Liste des figures v

Liste des tableaux vi

Liste des sigles et abréviations vii

Résumé 1

Abstract 2

Introduction 3Contexte, justification et problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Analyses et caractéristiques du trafic routier 71.1 La voirie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.1 Les routes urbaines et les autoroutes . . . . . . . . . . . . . . . . . . . . . . 71.1.2 Les intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.3 Mode de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.4 Architecture SMS en GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Services GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.1 Les services de messages courts(SMS) . . . . . . . . . . . . . . . . . . . . . 101.2.2 Le format d’un message court . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Le module GPRS Shiels SIM 900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.1 Les caractéristiques du module GPRS/GSM Shield SIM 900 . . . . . . . . 121.3.2 Les commandes AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.3 Principes généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Différentes stratégies de régulation via les feux de circulation . . . . . . . . . . . . 141.4.1 Stratégies prédéterminées ou cycliques . . . . . . . . . . . . . . . . . . . . 151.4.2 Stratégies semi-adaptatives ou acycliques . . . . . . . . . . . . . . . . . . . 15

TABLE DES MATIÈRES TABLE DES MATIÈRES

1.4.3 Stratégies adaptatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Architecture du réseau de gestion des feux tricolores dans la ville de Cotonou 172.1 Organisation technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Les feux tricolores dans la ville de Cotonou . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Les sources d’alimentations des feux tricolores à Cotonou . . . . . . . . . . 172.2.2 Installation et statistique des feux tricolores . . . . . . . . . . . . . . . . . . 182.2.3 Gestion et maintenance des feux tricolores . . . . . . . . . . . . . . . . . . 182.2.4 Topologie du réseau de gestion des feux tricolores . . . . . . . . . . . . . . 18

2.3 Organisation géographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Répartitions et état des feux dans la ville de Cotonou . . . . . . . . . . . . 202.3.2 Emplacement géographique des feux tricolores et proposition d’un centre

de gestion dans la ville de Cotonou . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 Plan du centre de gestion des feux tricolores dans la ville de Cotonou . . . 25

3 Étude conceptuelle du système de gestion centralisée 273.1 Méthode de conception adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Étude conceptuelle de la plate-forme de gestion centralisée des feux tricolores . . 28

3.2.1 Besoin fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Identification des acteurs de la plate-forme . . . . . . . . . . . . . . . . . . 29

3.3 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Choix technique de réalisation et de conception du système . . . . . . . . . . . . . 413.4.1 Technologie de réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.2 Présentation des outils de développement . . . . . . . . . . . . . . . . . . . 413.4.3 Environnement de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Résultats et discussion 444.1 Présentation de notre plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.1 Architecture du projet dans Sublime texte . . . . . . . . . . . . . . . . . . . 444.1.2 Dossier feuxtri_gestion_centralisée . . . . . . . . . . . . . . . . . . . . . . 454.1.3 Présentation des Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.1.4 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.5 Sécurité de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.1 Interprétation des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2 Limites et recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


Bibliographie 63

Annexe 67

English versionDesign and Experimentation of a Centralized Traffic Light Manage-ment System in the city of Cotonou 73

Introduction 74Context, justification and problematic issues . . . . . . . . . . . . . . . . . . . . . . . . 75Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Road traffic analysis and characteristics 775.1 Roads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.1.1 Urban roads and highways . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.1.2 The intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2 GSM services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.1 Short message services (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.3 The GPRS Shield SIM 900 module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.3.1 AT commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4 Different control strategies via traffic lights . . . . . . . . . . . . . . . . . . . . . . 805.5 Technical organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6 Traffic lights in the city of Cotonou . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.6.1 Types of traffic lights in Cotonou . . . . . . . . . . . . . . . . . . . . . . . . 815.6.2 Installation and statistics of traffic lights . . . . . . . . . . . . . . . . . . . . 825.6.3 Traffic light management and maintenance . . . . . . . . . . . . . . . . . . 825.6.4 Topology of the traffic light management network . . . . . . . . . . . . . . 82

5.7 Geographical organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.7.1 Geographical location of traffic lights and proposal for a management cen-

ter in the city of Cotonou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.8 Design methodology adopted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.9 Conceptual study related to the centralized traffic light management platform . . 87

5.9.1 Identification of the platform’s actors . . . . . . . . . . . . . . . . . . . . . 875.10 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.10.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.10.2 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.10.3 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.11 Technical choice of construction and design of the centralized traffic light man-agement platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90


5.11.1 Technology of realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.11.2 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.12 Presentation of our platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.12.1 Presentation of Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.12.2 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.13 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100


Documents

ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI