Embed Size (px)
Citation preview
Rapport de Stage 3A
Ingénieur d'études JEE pour le Service Web d'Aide à la Gestion du
Trafic de la future Rocade de Marseille Clément Lucas, Parcours OMIS-I promo 2015
Une œuvre d'art anonyme sur les murs de la Rocade
Durée du 1 Avril au 30 Septembre 2015
Tuteur de Stage : Monsieur Pascal Préa Enseignant-Chercheur
Responsable de parcours OMIS-I : Monsieur François Brucker Enseignant-Chercheur
Remerciements
Je tiens à remercier en premier lieu l'équipe des enseignants en Informatique de l'Ecole Centrale
Marseille, en particuliers Messieurs François Brucker, Pascal Préa et Emmanuel Dauce pour avoir
éveillé mon intérêt et m'avoir donné l'envie de me spécialiser dans ce domaine. Merci de tous les
efforts que vous portez à rendre vos cours passionnants, à la pointe de la technologie et accessibles
par tous les élèves.
Je remercie Philippe Vanden Bossche, ingénieur en développement web, pour sa pédagogie et sa
patience sans limite. Elles ont été un atout sans égal la réussite de toute l'équipe.
Merci aussi à Aude Beaudino pour m'avoir aidé à chaque fois que l'opportunité s'en présentait et
avoir donné de la crédibilité à mes remarques. Son recul, son courage, sa détermination et sa force
de caractère m'ont fortement marqué et inspiré.
Un grand merci pour sa bienveillance et sa disponibilité à mon tuteur de stage David Millien, analyste
fonctionnel et Chef de Projet. Le temps qu'il a consacré pour faciliter mon intégration m'a permis de
mieux comprendre le fonctionnement et les attentes d'une société de service.
Je salue les louanges de Sébastien Minet, architecte, qui a su se rendre disponible pour m'aider à
concevoir et valider mes solutions techniques les plus délicates. J'ai été impressionné par ses
compétences et enjoué par sa façon d'aborder la programmation.
Merci à mes chefs de projets, Laurent Livolsi et Laurent Claudel, pour m'avoir fait confiance et permis
de progresser énormément en me confiant beaucoup de responsabilités tout en me donnant les
moyens et les clés pour les tenir.
Merci à tout le personnel de l'agence Sopra Steria d'Aix-en-Provence qui a fait de mon stage de fin
d'études une grande aventure humaine unique et enrichissante. Merci aussi pour avoir démontré
l'envie de m'intégrer à vos équipes avec une proposition d'embauche au cours du stage.
Milles mercis à Julien Candela et Philippe Mothais, deux stagiaires dont l'amitié et l'amabilité a
ensoleillé mes journées au sein du groupe.
Résumé
Rapport de stage de fin d'études de six mois chez Sopra Steria à Aix-en-Provence d'un élève de l'Ecole
Centrale Marseille promotion 2015.
Intégration d'un groupe projet développant un service web d'aide à la gestion du trafic sur la future
rocade de Marseille pour les opérateurs de la DIRMed (Direction Interdépartementale des Routes de
la Méditerranée) . Le sujet du stage portait sur la réalisation d'un simulateur d'équipement et le
module "Simulation" de l'application visant à la formation des agents.
Participation aux phases de conception, développement, qualification interne et recette usine du
produit.
Abstract
Six-month computer science engineering Internship at Sopra Steria report of a last year Centrale
Marseille's engineering student.
Integration of a project group developing a help desk trafic management web service on the
upcoming ring road of Marseille for the agents of the french road's direction. The Internship's topic
was implementing an equipement simulator together with the "simulation" module of the
application.
Took part in the phases of conception, development, internal qualification and factory acceptance of
the product.
Lexique
Offshore : L’offshore outsourcing ou externalisation offshore concerne une délocalisation des services vers des pays étrangers éloignés. Le plus souvent, ce terme est associé à Maurice, Madagascar ou à l’Inde. Nearshore : Forme d’externalisation des services recourant à des prestataires implantés sur le territoire national ou à des sous-traitants bénéficiant d’une proximité moyenne dans des pays comme la Roumanie, l'Espagne, l’Algérie, la Tunisie et le Maroc. Onshore : L’externalisation onshore consiste à faire travailler des prestataires étrangers sur le site du client. La prestation est facturée aux conditions du pays d’origine, donc à un tarif réduit. ESN : Entreprise de Service du Numérique, remplace le sigle SSII pour les société de services en
ingénierie informatique
SAGT : Application web de Service d'Aide à la Gestion du Trafic
SGM : Service de Gestion et de Maintenance, applicatifs de la DIRMed comprenant la MCIM et le
SAGT
MCIM : Application Web de la DIRMed pour l'information sur les pannes d'équipement et le calcul de
pénalités.
CRM : Client Relationship Management en anglais, gestion de la relation client. Un secteur qui a
beaucoup évolué grâce aux progrès et innovations dans la collection et le traitement de données de
ces dernières années.
SRL2 : Société de réalisation de la Rocade L2.
PPP : Le partenariat public-privé est un mode de financement par lequel une autorité publique fait
appel à des prestataires privés pour financer et gérer un équipement assurant ou contribuant
au service public. Le partenaire privé reçoit en contrepartie un paiement du partenaire public et/ou
des usagers du service qu'il gère.
Groupement d'intérêt économique : Un groupement doté de la personnalité morale qui permet à ses
membres de mettre en commun certaines de leurs activités afin de développer, améliorer ou
accroître les résultats de celles-ci tout en conservant leur individualité.
DIRMed : Direction Interdépartementale des Routes de Méditerranée. Service public responsable de
l'exploitation d'une grande partie du réseau routier dans le sud-est de la France.
PMV : Panneau à message variable. Ces panneaux affichent des messages sur l'autoroute.
TA : Télé-alarme. Une alarme qui est levée par un équipement communiquant avec le SAGT
TE : Télé-alerte, comme une TA mais indiquant necessitant la necessité d'intervention d'un opérateur
DIRMed
ET : Une mesure quantifiable qui représente par une convention préétablie l'état fonctionnel d'un
équipement sur le terrain
TM : Une mesure pas toujours quantifiable représentant ce qu'affiche un équipement.
OPC-UA : Open Platform Communication - Unified Automation. L'évolution du protocole standardisé
de communication entre équipements industriels adapté pour les langages orientés objects et les
applications web
CAS : Central Authentication Service, projet libre et open-source permettant l'authentification à un
service web.
GTC : Gestion des tunnels centralisée
Frontal : Interface pour les SAGT avec les équipements.
RAU : Réseau d'Appels d'Urgences, le nom du frontal
PAU : Poste d'appel d'urgence, les téléphones oranges sur le côté de la route.
JMS : Java messaging Service, permet aux modules du SAGT de communiquer entre eux.
Table des matières
Remerciements ....................................................................................................................................... 3
Résumé .................................................................................................................................................... 4
Abstract ................................................................................................................................................... 4
Lexique .................................................................................................................................................... 5
Table des matières .................................................................................................................................. 7
Introduction ............................................................................................................................................. 9
Partie A : Présentation de Sopra Steria ................................................................................................. 10
1. Identité, Taille ................................................................................................................................ 10
2. La Fusion entre Sopra et Steria ..................................................................................................... 11
3. Activités et offre de Sopra Steria ................................................................................................... 11
a. Sopra Steria Consulting ............................................................................................................. 12
b. Intégration de systèmes ............................................................................................................ 13
c. Edition de solutions métier ........................................................................................................ 13
d. Infrastructure Management ...................................................................................................... 13
e. Busines Process Services ........................................................................................................... 13
4. Quelques Projets emblématiques du groupe ................................................................................ 13
5. Organisation du groupe ................................................................................................................. 14
6. Organisation de l'agence 121 ........................................................................................................ 16
Partie B : Description du Projet et de la mission du stage .................................................................... 18
1. Présentation de la L2 ..................................................................................................................... 18
2. Le financement de la rocade ......................................................................................................... 19
3. Présentation générale du SGM ..................................................................................................... 20
a. Le service de maintenance des équipements ........................................................................... 20
b. Le service de gestion du trafic ................................................................................................... 21
4. Les modules du SAGT .................................................................................................................... 22
5.Récapitulatif des Modules du SAGT ............................................................................................... 22
a. Le module Equipement.............................................................................................................. 22
b. Le module Alarme/Alerte .......................................................................................................... 23
c. Le module données trafic .......................................................................................................... 23
d. Authentification ......................................................................................................................... 24
e. Fiche Evénement ...................................................................................................................... 24
g. Consigne .................................................................................................................................... 24
h. Historique .................................................................................................................................. 25
i. Référentiel .................................................................................................................................. 25
j. Politique d'exploitation .............................................................................................................. 25
La politique d'exploitation permet de paramétrer les actions proposées dans le plan d'action
proposé après validation d'une fiche événement en fonction de conditions sur les attributs de la
fiche validée................................................................................................................................... 25
k. Rejeu et Simulation .................................................................................................................... 25
l. Diffusion d'information .............................................................................................................. 26
m. Conditions d'utilisation de l'application par les opérateurs .................................................... 26
5. Organisation du Projet .................................................................................................................. 27
6. Environnement Technique ............................................................................................................ 28
7. Les ressources................................................................................................................................ 30
Partie C : Réalisations ............................................................................................................................ 32
1. Missions et objectifs du stage ....................................................................................................... 32
2. Le simulateur ................................................................................................................................. 33
a. Modèle des équipements .......................................................................................................... 33
b. Communications SAGT-Equipements en OPC-UA ..................................................................... 33
c. Conception et implémentation du simulateur ......................................................................... 34
3. L'Application de Master Simulation .............................................................................................. 35
a. Présentation générale ............................................................................................................... 35
b. Simulation des équipements ..................................................................................................... 36
c. Paramétrer des retours sur commande .................................................................................... 36
d. Paramétrer des retours sur scénario ......................................................................................... 37
e. Simuler des états de trafic ......................................................................................................... 38
f. Listes d'action ............................................................................................................................ 39
4. Autres Tâches ................................................................................................................................ 43
a. Initialisation du référentiel ........................................................................................................ 43
b. Tests de qualification interne .................................................................................................... 44
c. Correction de bug ...................................................................................................................... 45
Conclusion ............................................................................................................................................. 46
Introduction
Le stage de fin d'études a été l'occasion de mettre en pratique sur le terrain le métier
d'ingénieur d'études dans une société de service, mais aussi une révélation sur l'utilité de mon cursus
et ce qu'un ingénieur Centralien peut apporter dans une entreprise.
Issu d'un parcours d'ingénieur généraliste, spécialisé en informatique et en gestion de projet,
j'ai eu l'occasion d'observer avec intérêt et étonnement les pratiques concrètes en entreprise avec le
recul d'un enseignement sur les bonnes pratiques dans une grande école d'ingénieur portée sur
l'innovation.
Une certaine attirance pour le développement, les solutions élégantes et les bonnes
pratiques m'a fait choisir ce stage. Sopra Steria m'a offert la possibilité de compléter ma formation et
solidifier mes compétences avec un sujet passionnant participant à un projet de transformation du
système d'information de grande envergure dans le domaine du BTP .
Partie A : Présentation de Sopra Steria
1. Identité, Taille
Né de la fusion absorption en 2014 de Stéria par Sopra Group, deux géants des systèmes
d'informations, Sopra Steria est un leader en Europe du marché de la transformation numérique.
C'est une entreprise de service qui propose aux entreprises de sous-traiter leurs activités liées à
l'informatique en général.
L'entreprise compte plus de 37 000 collaborateurs et est présente à travers plus de vingt
pays. Elle est surtout présente et reconnue en Europe. Contrairement à ses principaux concurrents
Atos et CAP Gemini qui sont très internationaux, elle concentre ses activités et réalise la majeure
partie de son chiffre d'affaire en France et en Angleterre.
En effet, Sopra Group est une entreprise française créée en 1968. Malgré la fusion, le siège
social du groupe est resté à Annecy en Savoie où le groupe a vu le jour. D'après son ancien président
Pierre Pasquier, l'entreprise a connu une croissance plutôt lente mais efficace, et a fait preuve d'une
volonté d'exister à toute épreuve qui lui permet d'être présente aujourd'hui dans de top 5 des
entreprises de service du numérique en France tout en étant solide et disposant d'un business plan à
toute épreuve. Nous allons présenter la fusion de son point de vue car elle en est l'initiatrice.
2. La Fusion entre Sopra et Steria
En 2014, Sopra Group saisit l'opportunité d'une croissance très forte et rapide avec la
possibilité d'acquérir Stéria, une grande ESN comparable en taille. En devenant actionnaire de celle-ci
majoritaire à plus de 90%, Sopra prend le risque d'avaler un poisson aussi gros que lui, mais mise sur
la grande complémentarité et les valeurs communes qui existent entre les entités pour réussir cette
fusion absorption.
En effet, les deux entités ont de forts points communs en terme de taille, de poids et
d'image. Un atout majeur pour la fusion est la complémentarité des entités sur le marché, apportant
de nouveaux clients à Sopra mais aussi des nouvelles offres de solutions qui s'articulent bien avec
celles existantes comme l'ingénierie des réseaux.
Il existe aussi une certaine complémentarité géographique pour Sopra avec Steria. Tout
d'abord car Stéria était très présent en Grande-Bretagne alors que Sopra y était presque inexistant,
mais aussi grâce à l'acquisition de nouveaux centres de compétence nearshore et offshore pour y
compter en tout plus de 8000 personnes.
L'augmentation de la taille et du capital de l'entreprise est aussi un atout pour la confiance
des clients sur les capacités de l'entreprise à subsister et à gérer des projets possédant de forts
enjeux sur les plans techniques et financiers.
3. Activités et offre de Sopra Steria
L'entreprise travaille dans des domaines très variés. La majorité des clients faisant appel aux
services de Sopra Steria se trouvent dans le domaine de la finance et duc secteur publique. Les
contrats avec l'état comme pour le projet de la L2 auquel j'ai pu participer ont donc des enjeux
stratégiques important pour l'entreprise.
Répartition des marchés Secteurs stratégiques
Sopra Steria possède une offre de service très complète car elle peut intervenir dans toutes
les étapes de la chaîne de valeur dans le domaine des systèmes d'informations. Le groupe attache
une grande importance à ce que ses offres soient en adéquation avec l'évolution et les innovations
du marché. Il a donc anticipé son ouverture sur le développement futur du big data, du cloud et des
réseaux collaboratifs.
a. Sopra Steria Consulting
L'entreprise possède une filiale nommée Sopra Steria Consulting spécialisée dans le conseil
en management et en technologie. Elle est capable d'accompagner les entreprises afin de les aider à
mettre en place leur vision et leur stratégie liée aux systèmes d'informations, à la politique RH et à la
relation Client gràce au CRM.
Elle est capable de les aider à identifier les pratiques innovantes du marché et de les mettre
en accord avec les besoins d'une entreprise. Puis elle sait accompagner dans la mise en place et le
suivi de ces solutions.
b. Intégration de systèmes
Gestion de l'ensemble du cycle de vie du patrimoine applicatif d'un client depuis son
architecture en passant par sa conception, son développement, son intégration, le testing, et jusqu'à
amélioration continue d'un produit. L'application de développement web que mon projet est chargé
de concevoir fait partie de ces solutions.
c. Edition de solutions métier
Sopra Steria est fier de pouvoir se targuer d'être un éditeur de logiciel reconnu et parmi les
plus développés en France à travers ses filiales Sopra Banking Software, Sopra HR Software et Sopra
Real Estate Software.
d. Infrastructure Management
Accompagnement dans la transformation des infrastructures et intégration de technologies
autour du Cloud, des Datacenter et de l'environnement de travail utilisateur. Notre projet a
notamment été chargé de commander une partie du matériel qui sera intégré chez le client dont un
mur d'image aussi grand qu'un écran de cinéma.
e. Busines Process Services
Sopra Steria possède l'expertise afin d'assurer la délocalisation de chez ses clients des
fonctions Finance, Comptabilité, Ressources Humaines et Achats.
4. Quelques Projets emblématiques du groupe
5. Organisation du groupe
Sopra Steria est une immense entité française de 37000 collaborateurs, on peut donc
s'attendre à ce que la société soit très structurée. C'est bien le cas, et l'organisation de la direction du
groupe est séparée en fonction des entités géographiques par pays et continents, et par secteur
d'activité stratégique comme Aeroline qui passe des contrats avec des sociétés du secteur de
l'aéronautique, ou encore par entité filiale comme Sopra Banking Software. Enfin, il existe aussi de
petites entités indépendantes pour les départements internes comme le juridique, les achats ou les
ressources humaines.
A noter que la nomination d'anciens de Sopra Group à la direction générale suite au
remerciement de François Enaud à ce poste qui était l'ancien président de Steria.
Organigramme de la direction de Sopra Steria
Lors de mon stage, j'ai intégré le département Conseil et intégration indiqué par la
magnifique flèche verte qui malgré sa petite taille sur le schéma représente 57% des activités de
Sopra Steria.
Encore une fois, on peut remarquer que les différentes entités du département sont
séparées par secteur géographique mais aussi par secteurs d'activité stratégique comme la défense,
l'industrie, les banques, les télécoms, l'énergie et les transports.
Les différentes divisions suivent la politique globale de l'entreprise, mais sont en compétition
et il y a très peu de collaboration entre elles. L'agence d'Aix-en-Provence dans laquelle j'ai réalisé
mon stage s'appelle Provence Business Technologies fait partie de la division Sud-est de Sopra Steria,
on l'identifie par le numéro 121.
6. Organisation de l'agence 121
L'agence 121 s'organise en pôles de compétences, et chaque pôle est divisé en plusieurs
groupes projets indépendants gérés par des chefs de projets auxquels on donne carte blanche pour
réaliser le meilleur résultat.
Des commerciaux sont chargés de démarcher et vendre l'expertise de ces pôle afin d'étendre
le portefeuille client et le chiffre d'affaire de l'agence. Les ressources humaines s'occupent du
recrutement et des évolutions au sein de la boîte. Cependant, la répartitions des ressources internes
compétentes sur les projets est décidée par les directeurs de projet de l'agence à la suite d'une
réunion chaque semaine.
La grande majorité des recrutement de la société concerne exclusivement des profils Bac +5,
et très majoritairement des jeunes diplômés. Les compétences en développement Java sont
extrêmement recherchées. Il y a très peu de profils experts avec plus de dix ans d'expérience issu de
chez Sopra, contrairement à la politique qui était en vigueur chez Steria. Cela permet aux jeunes
actifs avec du potentiel de faire leurs armes et monter en responsabilité très rapidement dans le
monde de l'entreprise. Cependant l'ESN sert souvent de tremplin donc il existe un turnover
important et l'entreprise peine à retenir toutes ses ressources compétentes.
La majorité des contrats, environ 70%, concernent de la tierce maintenance applicative au
forfait. Le reste représente des activités de régie, soit des postes d'ingénieurs temporaires chez un
client.
Le chiffre d'affaire de l'agence provient d'une quinzaine de clients dans la région PACA. Le
graphe suivant présente le volume du chiffre d'affaire de chacun dans l'agence. Il date d'avant la
fusion de Sopra avec Steria, il manque donc le projet de la L2 qui a été apporté par l'agence de Stéria
et qui représente 15% du chiffre d'affaire.
La répartition géographique de l'agence 121 se fait entre le bâtiment principal et l'ancien
bâtiment de Steria situés à quelques centaines de mètre l'un de l'autre. Tous les groupes projets de
l'agence 121 sont situés dans le bâtiment principal, sauf celui de la L2 hérité de Steria et le nouveau
pôle pour la française des jeux. Sopra Steria a pour projet de déménager dans un plus grand
bâtiment de la technopôle des milles afin de rassembler tout le monde sous le même toit et intégrer
définitivement tout le personnel de Steria à l'agence.
Partie B : Description du Projet et de la mission du stage
1. Présentation de la L2
La construction d'une rocade à Marseille pour désengorger le trafic de la ville la plus
embouteillée de France en ralliant les autoroutes Nord et Est est un projet vieux comme le monde.
Cela fait plus de 80 ans qu'il est prévu par la ville de Marseille, et son histoire a même été le sujet
principal d'une thèse de doctorat en urbanisme soutenue par Stéphanie Leheis « La ville et sa rocade,
projet d’infrastructure au temps long, le cas de Marseille ».
Plan de la rocade L2
Il s'agit d'une voie rapide urbaine gratuite d'une dizaine de kilomètre qui contourne le
centre-ville. Elle doit permettre de délester le trafic des grands boulevards du centre-ville et sa
livraison est prévue courant 2016.
C'est au cours des années 90 que le projet de construction de la rocade a commencé à se
concrétiser. Une toute petite partie de la route est déclarée d'utilité publique ce qui permet sa
construction. Il a fallu attendre 2010 pour que les plans soient définitifs et que l'entièrement du
tracé soit approuvé d'utilité publique. Cependant l'état a manqué de fonds pour construire la route, il
a donc lancé un appel d'offre pour lancer un groupement d'intérêt économique d'entreprises privées
pouvant financer la route.
2. Le financement de la rocade
Un groupement attributaire dont Bouygues Construction est le mandataire s'est ainsi associé
à l'état formant le premier partenariat public privé pour la construction d'une route en France. Le
budget total alloué est de 620 million d'euro, il est financé au deux tiers par des entités de l'état
incluant Marseille Provence Métropole, le Conseil Général 13 et le département. Le tiers restant sera
financé par les investisseurs du groupement et des prêts.
La SRL2 Société de Réalisation de la Rocade de Marseille est titulaire de ce contrat de
partenariat public privé. La conception et la réalisation lui ont été confiées, et elle sera ensuite
responsable de son entretien et de sa maintenance pendant 30 ans. En tant que responsable des
délais et du budget, elle est la maîtrise d'ouvrage.
Cette dernière a confié au groupement d'intérêt économique GIE Groupement L2
Construction la maîtrise d'œuvre de la conception et la construction de l'Autoroute, son entretien et
sa maintenance.
Le GIE a choisi de faire sous-traiter les prestations de conception-construction d'équipements
fixes d'exploitation (EFE) de la route par Bouygues Energies & Services, Egis Projects et Aximum. Ces
derniers ont mandaté Sopra-Steria pour réaliser les applications de gestion et de maintenance de ces
équipements pour celui qui exploitera la route, la Direction Interdépartementale des Routes DIRMed.
Une clause de transparence répartit uniformément les pénalités en cas de retard à la livraison.
Fort de son expérience dans la conception de services routiers personnalisés, Steria a été
sélectionné par le mandataire du groupement EFE en Avril 2014 pour réaliser les services applicatifs
liés à la gestion et la maintenance du trafic à destination des opérateurs de la DIRMed. En effet,
Steria s'est imposé comme une évidence car ayant déjà réalisé avec succès le logiciel servant à
l'exploitation du tunnel de Toulon, ainsi que 5 services d'aide à la gestion du trafic à travers la France
et la Belgique.
3. Présentation générale du SGM
a. Le service de maintenance des équipements
Les services de gestion et de maintenance développés par Sopra Steria ont pour utilisateur
final les opérateurs de la DIRMed. Ceux-ci sont responsables de l'exploitation et de la maintenance
des routes. Cependant, ils ont déléguer une partie de ces responsabilité, c'est à dire la maintenance
des équipements routiers à des sous-traitants plus qualifiés.
Les premières applications développées d'Avril à Mai 2014 par Steria concernent donc la
gestion et maintenance des équipements assistée par ordinateur avec une solution d'un éditeur de
logiciel indépendant CARL sur toutes les routes de la DIRMed.
Le logiciel est capable de communiquer avec les équipements terrains et d'informer les
responsables équipements d'une panne ou défaillance sur un équipement. Les sous-traitants de la
DIRMed ont alors un certain délai légal pour intervenir, sans quoi ils sont redevables d'une pénalité.
En cas de panne équipement, une alarme est levée, mais les opérateurs DIRMed n'ont pas
besoin d'intervenir sur le terrain pour le réparer. Ils ont cependant besoin de l'information de la
panne pour éventuellement adapter leurs actions, et pour calculer les pénalités de retard que leurs
sous-traitant leurs doivent s'ils sont trop long à réparer les équipements. Voici dont l'objectif
principal de la MCIM qui vient s'interfacer avec la GMAO pour les utilisateurs de la DIRMed et calcule
automatiquement les pénalités.
b. Le service de gestion du trafic
La seconde partie du développement du SGM est le Service d'Aide à la Gestion du Trafic
SAGT. C'est un service sous forme d'application web conçue pour regrouper et facilité la réalisation
de toutes les tâches liées à la gestion des routes effectuées par les opérateurs de la DIRMed et
certains de leurs collaborateurs. Il sera aussi utilisé par exemple avec des permissions restreintes par
des CRS qui restent en place à leurs côtés dans une salle de contrôle afin d'intervenir en cas de
besoin.
Cette application comporte beaucoup plus de fonctionnalités à implémenter et des besoins
métier spécifiques compliqués à mettre en œuvre. L'application est divisée en 12 modules pouvant
fonctionner indépendamment les uns des autres car cela fait partie des exigences clients. L'utilisateur
doit en effet pouvoir "éteindre" un ensemble de fonctionnalité en temps voulu.
4. Les modules du SAGT
Récapitulatif des Modules du SAGT
a. Le module Equipement
Le module équipement permet à un opérateur de naviguer à travers les équipements
connectés avec le SAGT et les piloter. Il pourra ainsi consulter leur état sur le terrain et le manipuler
si besoin pour afficher par exemple un message sur un panneau à message variable PMV ou bien
bouger une caméra, ou encore pour allumer la ventilation d'un tunnel.
Des macro-commandes ont été implémentées permettant à l'utilisateur d'enregistrer au
préalable une suite d'action à réaliser sur des équipements et de suivre et contrôler son exécution
pas à pas. Cela est très utile lorsqu'il faut par exemple envoyer toutes les commandes aux
équipements pour fermer un tunnel lors d'une urgence.
Il est aussi possible d'inhiber ou invalider un équipement, rendant toutes les informations
qu'il fournira caduques aux yeux de l'application. Cela est utile lorsqu'un équipement est défectueux
afin qu'il ne lève pas de fausses alarmes ou alertes.
b. Le module Alarme/Alerte
Ce module permet les gestion des alarmes et alertes. Il est important de faire la distinction
entre une alarme qui concerne en général une panne d'équipement et ne nécessite pas
d'intervention terrain de l'opérateur DIRMed, et une alerte qui correspond à un grave problème
d'exploitation de la route et exige son déplacement immédiat sur les lieux concernés.
Les alarmes peuvent être levées directement par les équipements qui en informent le SAGT
si ceux-ci sont défectueux, ou bien par le SAGT si l'exécution d'un pilotage équipement ne se déroule
pas correctement.
Les alertes sont très rarement levées par les équipements. Elles sont le signe d'un événement
grave nécessitant l'intervention d'un opérateur aussi tôt que possible. Les postes d'appel d'urgence,
téléphones orange sur le côté de la route déclenchent par exemple une alerte lorsque le combiné est
décroché car cela est signe qu'un problème qui pourrait gêner l'exploitation de la route est présent
sur la chaussée.
Cependant dans la majorité des cas, les alertes sont identifiées par le SAGT. Elles peuvent
être levées en fonction d'un paramétrage effectué par l'utilisateur final de l'application. Ce sont des
alertes combinatoires car elles sont déclenchées seulement lorsque certaines conditions combinées
sur le déclanchement de plusieurs alarmes sont présentes.
Par exemple lorsque trois ventilations consécutives ne fonctionnent plus à l'intérieur d'une
tranchée couverte, elle devient inexploitable par les automobilistes car trop dangereuse en cas
d'incendie. Il est donc vital pour la DIRMed de paramétrer une alerte sur l'exploitation d'une
tranchée couverte qui correspond à trois alarmes sur équipements consécutifs de type ventilation
dans une tranchée couverte.
Chaque module est aussi capable de lever des alertes en fonction des problèmes liés à
l'exploitation qu'il est en mesure d'identifier. Lorsqu'une alerte a été identifiée et traitée, l'opérateur
peut l'acquitter.
c. Le module données trafic
Ce module est chargé de recevoir l'immense volume de données des équipements de mesure
trafic sur la route sous forme de trames HMVL, puis de calculer l'état du trafic sur chaque tronçon
avec un algorithme adapté. Il demande au module alarme/alerte de lever des alertes bouchon
lorsque le trafic est bloqué.
d. Authentification
Module qui gère l'implémentation d'un CAS commun à tous les services du SGM afin de
permettre aux utilisateurs de s'identifier et pouvoir accéder à tous les services en ne s'identifiant
qu'une seule fois. Il a été très bien réussi par Julien Candela, un stagiaire qui vient aussi du parcours
informatique à Centrale Marseille.
e. Fiche Evénement
Les événements sont un terme très générique qui permet de désigner quelque chose qui
pourrait influencer sur la gestion du trafic. Ces événement sont prévisibles ou non, et s'ils le sont
donnent lieu à des alertes de rappel lorsqu'ils débutent ou finissent. C'est une des fonctionnalités
que j'ai eu la chance d'implémenter.
Les événements sont identifiés par un seul type, et peuvent être regroupés ensemble s'ils ont
une cause commune qui sera alors l'événement principal du regroupement. Plus concrètement, un
événement de type intempérie météo localisé sur Marseille pourra être l'événement principal d'un
regroupement contenant des événements de type accident, de type mesure de gestion du trafic ou
encore de type incendie.
Lorsqu'une fiche correspondant à un événement est créée et validée par un opérateur, un
plan d'action lui est proposé en fonction des attributs de la fiche et du paramétrage édité dans le
module politique d'exploitation. Ainsi lorsqu'un incendie démarre à l'intérieur d'un tunnel, des
mesures telles qu'appeler les pompiers ou encore déclencher la macro-commande d'ouverture de
toutes le ventilations et fermetures des barrières à l'entrée pourront être proposées.
Il existe une douzaine de type d'événements différents, chacune possédant des attributs
différents qui seront diffusés aux réseaux nationaux et européens de gestion du trafic sous un
format normalisé répondant au doux nom de Datex2.
f. Cartographie
C'est un outil utilisant OpenStreetMap permettant la localisation ainsi que l'identification
facile et très visuelle des équipements, des événements, et des bouchons sur une carte.
g. Consigne
Ce module gère l'attribution d'astreinte à une certaine zone pour un groupe d'utilisateur
responsable d'une portion précise du réseau.
h. Historique
Sert à consulter les données liées au SAGT à une date précise. Cela implique l'audit des
changements dans les tables liées par exemple aux états des équipements ou bien aux actions
menées par l'utilisateur.
i. Référentiel
Utile pour changer le référentiel du SAGT lié à tous ses équipements et ses différents
paramétrages. Le référentiel permet l'import et la suppression des équipements référencés par le
SAGT.
j. Politique d'exploitation
La politique d'exploitation permet de paramétrer les actions proposées dans le plan d'action
proposé après validation d'une fiche événement en fonction de conditions sur les attributs de la fiche
validée.
Il est aussi capable d'afficher des messages automatiques sur un PMV de priorités faibles si
les opérateurs n'ont pas besoin d'afficher d'y afficher d'autres informations plus prioritaires. Il est par
exemple possible de paramétrer l'affichage du message "Rappel : Attachez vos enfants pour leurs
sécurité" du Lundi au Vendredi de 15h30 à 18h aux heures de sortie d'école.
k. Rejeu et Simulation
Le rejeu permet de refaire revivre l'ensemble des opérations qui ont eu lieu sur le SAGT à
partir d'une certaine date. L'opérateur n'est autorisé à effectuer aucune action mais peut observer
les réactions de l'opérateur alors en poste en fonction des données alors reçues par le SAGT qui ont
été conservées par le module historique.
La simulation a pour but de reproduire le comportement des équipements qui
communiquent avec le SAGT en situation réelle. C'est la partie qui m'a été confiée lors du stage. Elle
est utile pour pouvoir tester l'application en dehors du terrain, afin d'appréhender les problèmes qui
pourraient être introduit avec des changements dans le référentiel.
Elle sert aussi à la formation de nouveaux opérateurs qui peuvent se préparer à utiliser le
SAGT dans des conditions réelles. Un scénario peut être préparé à l'avance par le formateur, et
l'élève peut opérer sans crainte qu'aucune de ses erreurs ne puisse avoir des répercussions réelles.
l. Diffusion d'information
Ce module communique les informations collectées dans le SAGT avec l'extérieur. Il glane par
exemple les données des fiches événements et les convertis sous un format uniformisé et normalisé
européen nommé DATEX.
m. Conditions d'utilisation de l'application par les opérateurs
Les opérateurs DIRMed et CRS opèrent dans la salle de contrôle. Chacun possède trois grands
écrans et a une vue directe sur le mur d'image au centre de la pièce. L'écran du milieu permet de
naviguer à travers les menus d'exploitation de la route. L'écran de gauche affiche les alarmes et les
alertes levées, et l'écran de droite affiche la cartographie. Les opérateurs de la DIRMed sont à gauche
de la pièce alors que les CRS sont à droite.
Vue du pupitre d'un opérateur
En raison des conséquences critiques pouvant émerger d'une perte d'accès aux services de
l'application, un accord a été trouvé sur une contrainte de haute disponibilité pour l'application qui
ne peut être indisponible plus de 10 minutes par mois sous peine de fortes pénalités.
5. Organisation du Projet
Le projet suit une méthodologie en V adaptée à l'expérience et aux connaissances de tous les
acteurs. En effet, elle a été préférée à une méthodologie agile à cause du manque de disponibilité du
client et des nombreuses expériences des différents chefs de projets avec cette méthode.
Les étapes du projet
Le projet de réalisation du SAGT se découpe en 5 grandes étapes. Tout d'abord la réponse à
l'appel d'offres qui donne naissance au projet le 4 avril 2014. S'en suit la phase de spécification qui
était prévue pour durer 6 mois mais s'en prolongée jusqu'en août 2015 à cause d'un manque de
disponibilité de la maîtrise d'œuvre et de la grande difficulté à définir le besoin au travers de toutes
les couches intermédiaires entre le prestataire et l'utilisateur final.
La décision a été prise conjointement entre Sopra Steria et ses mandataires de l'EFE de
commencer la phase de développement avant la fin des rédactions des spécifications fonctionnelles.
Cela implique un développement de très réfléchi pour être assez générique et facilement
refactorisable car il aura de fortes chances d'être sujet au changement. Cette phase de
développement se poursuit après la première phase de recette usine car de nouvelles fonctionnalités
ont été mandatées tout au long de la réalisation du projet.
La phase de qualification interne a pour but de tester une première fois indépendamment du
client les fonctionnalités implémentées en suivant les stratégies de tests définies au préalable afin de
vérifier que l'application soit présentable pour de la phase de recette usine.
La première phase de recette usine que se déroule en ce moment en compagnie des
représentants de chaque entité faisant partie du contrat vérifie et valide définitivement les
fonctionnalités développées pour la DIRMed dans un environnement d'intégration. Les clients font
part des derniers écarts aux spéculations perçus afin que ceux-ci soient rapidement corrigés.
6. Environnement Technique
Une contrainte légale imposée par l'état pour le client est l'utilisation exclusive de
technologies open-source pour le développement d'une application web d'aide à la gestion du trafic.
Cela m'a permis de me former à utiliser des technologies de pointe passionnantes comme AngularJS,
Spring Boot et Hibernate.
Environnement Technique
Du côté client, le choix s'est orienté vers HTML5/CSS3 avec des frameworks permettants de
construire une application web dynamique, responsive et mobile-first comme BootStrap et
AngularJS. LESS permet de modifier le code source de bootstrap afin de l'adapter aux besoins de
notre IHM très peu aéré contrairement au design par défaut proposé. Grunt est très utile afin
d'effectuer les tâche répétitives sur les fichiers de côté client comme la minification et la compilation.
Les échanges entre le client et le serveur se font grâce à des objets JSON. Cela combiné aux
fonctionnalités offertes par BootStrap permettra de développer efficacement par la suite une
application mobile pour le client en modifiant très peu le code source de l'application.
Le côté serveur est développé sous le framework Spring Boot, une évolution des dernières
versions de Spring qui s'appuie sur les conventions d'utilisations pour permettre de minimiser les
configurations de bean en xml et leur privilégier les annotations.
L'injection de dépendances très puissante du framework Spring permet d'augmenter
grandement la productivité des développeurs en permettant de séparer clairment le code des
controllers, des services et des repository. Le framework permet aussi de mettre facilement en place
des tests unitaires avec JUnit qui apportent de la confiance dans le code et identifient
immédiatement éventuelle régression et les bouts concernés par icelle. Le responsable technique de
l'application n'a cependant pas souhaité que nous fassions des tests unitaires.
Les controllers Spring MVC 4.0 de l'application servent de véritables points d'entrées et de
sortie du modèle pour les communications entre le client et le serveur.
Fonctionnement d'une architecture MVC
Hibernate a été retenu en tant qu'implémentation de Java Persistence API pour remplir les
fonctions d'outil d''Object Relational Mapping, c'est à dire transformer des objects java communs en
données stockées dans un base relationelle.
Le choix a été fait de partir sur une base de données PostgreSQL, une technologie open-
source dotée d'une énorme communautée particulièrement active en France et adaptée pour de
grands volumes de données.
Nous avons développé l'application sous l'IDE Eclipse et nous avons utilisé Maven afin d'aller
rechercher les dépendances de l'application et pour la builder. Le serveur de Tomcat est utilisé sur
les postes de développement mais l'application est déployée en intégration sous l'héritier de JBoss
WildFly. L'outil de versionning que nous avons utilisé était TortoiseSVN.
J'ai ainsi eu l'immense plaisir de m'autoformer rapidement pour utiliser tous ces outils. Le
secteur du développement web est passionant car il est extrêmement porteur d'innovation et évolue
très vite.
7. Les ressources
Le budget associé au SAGT est d'environ un million d'euro réparti sur un an. Les coûts sont
calculés par les chefs de projets en fonction du salaire et du nombre de jour que passe chaque
ressource sur le projet. Le but principal du chef de projet est d'augmenter son bénéfice, il subit de
fortes pression de la part de la direction pour utiliser ses ressources qui lui sont attribuées avec une
efficacité maximisée.
Le projet a conservé les trois chefs de projets qui ont menés la réponse de Steria à l'appel
d'offre afin de rédiger les spécifications fonctionnelles, maîtriser l'avancement du projet et gérer la
relation avec le client. Mis à part la partie du projet au Maroc, nous avons travaillé tous ensemble
dans un bureau open-space de trente mètre carré.
L'architecte qui a conçu la solution est à plein temps sur le projet. Il est responsable de la
qualité du développement ainsi que de l'évolution de l'environnement technique. Les réunions
hebdomadaires dur l'attribution des ressources sont l'occasion de décision politique sur la priorité de
l'avancement d'un projet par rapport à l'autre. Ainsi, certains développeurs ont été amené à naviguer
très régulièrement entre les projets selon les besoins de l'agence. Cela n'a pas été vraiment en phase
avec la décision des responsables de la répartitions des tâches de concentré la connaissance et la
maîtrise de chaque module en un seul développeur.
Nous avons aussi pu expérimenter la difficulté de travailler avec des collaborateurs au Maroc
éloignés géographiquement. En effet, il est très difficile à cause de la distance de leur faire prendre
part entièrement à la vie du groupe autant qu'à une personne présente toute la journée dans le
bureau de la L2. Skype nous a tout de même permis de communiquer et avancer ensemble.
Des réunions sur la présentation de l'avancement de chaque partie étaient prévues chaque
Lundi matin, mais les délais très courts accompagnés d'une très forte pression sur les résultats ont
vite pris le pas sur elles. J'ai trouvé cela dommage car il n'a existé que très peu d'échanges entre les
développeurs sur ce qu'ils ont réalisés, empêchant bien souvent de prendre connaissance d'une
implémentation réutilisable ou bien encore de se mettre d'accord sur des pratiques communes.
Cependant, nous avons aussi été marqué par l'implication et l'investissement démontré par
chacun des acteurs du projet. De fortes exigences et une culture de la réussite nous ont donc tirés
vers le haut et permis d'apprendre énormément lors de cette expérience enrichissante.
Partie C : Réalisations
1. Missions et objectifs du stage
Etant donné qu'il s'agissait de mon stage de fin d'études et qui plus est d'un stage de pré-
embauche, mon objectif principal était de faire mes preuves en entreprise et mettre en application
les compétences d'ingénieur que l'école Centrale Marseille m'a transmis. Cela a été une très belle
réussite car l'entreprise m'a proposé un contrat d'embauche deux mois avant la fin de mon stage.
J'ai ainsi eu l'occasion de pouvoir m'intégrer à un groupe projet pour réaliser des tâches
intéressantes et endosser des responsabilités sur un projet phare de l'agence. La tâche principale qui
m'a été confiée est le développement du module Simulation, mais on m'a aussi bien réparti au
quotidien sur d'autres tâches en fonction des besoins. J'ai ainsi pu me rendre compte des facilités
d'adaptation et de la versatilité que ma procuré ma formation.
Calendrier des tâches effectuées
Le module simulation se compose de deux parties. La première est le simulateur
d'équipement. Il permet de simuler l'existence est les réactions des équipements sur le terrain. C'est
lui que j'ai réalisé en premier lieu car il a permis de rentrer dans une phase de test des autres
modules de l'application dans l'environnement de simulation. Etant donné qu'il n'est pas encore
possible de s'interfacer avec les frontaux car ils sont en phase de développement comme le SAGT,
l'implémentation du simulateur était indispensable pour tester les fonctionnalités de l'application. En
effet, il a rendu possible le pilotage d'équipement, l'apparition d'alarme et d'alerte simulée sans
adapter leur logique.
La deuxième partie est l'application de Master Simulation. Elle permet à un formateur de
devenir un véritable maître du jeu. Le rendant à la fois metteur en scène et scénariste, cette
application lui permet de simuler des accidents d'exploitation en temps réel et permet de former les
apprentis-opérateurs en dehors de l'environnement réel d'exploitation. Il pourra par exemple
simuler l'apparition d'alarmes sur les équipements et recréer les conditions d'apparitions d'alertes
d'exploitations et observer les réactions des élèves qui subissent ces actions.
2. Le simulateur
a. Modèle des équipements
Pour comprendre comment le simulateur remplace les équipements en conditions normales
d'exploitation, il est important de savoir comment le SAGT communique concrètement avec ces
équipements.
Tout d'abord, intéressons-nous à la représentation d'un équipement au sein du modèle de
données de l'application. Chaque équipement est représenté pour un ensemble d'attributs généraux
comme son identifiant, son libelle, son code et son type. Les différents types sont par exemple les
caméras mobiles, les panneaux à message variables à 2 lignes ou encore les postes d'appels
d'urgence.
Le type d'un équipement est assez précis pour définir totalement tous ses attributs et donc la
façon dont il communiquera avec le SAGT. Ainsi, tous les équipements d'un même type auront un
ensemble d'attribut totalement commun. Ces attributs sont principalement les alarmes que
l'équipement peut déclencher de lui-même, les alertes, mais encore ses états, ses mesures, ses
réglages possibles depuis le SAGT et facultativement ses commandes d'activation des réglages.
Si on récapitule, chaque équipement possède donc un ensemble d'attribut entièrement
identifié par son type. Les équipement communiquent avec le SAGT en OPC-UA, une spécification
standard normalisée gouvernée par la OPC Fundation. Cela permet à tous les équipements de
communiquer de la même manière et permet de s'affranchir d'installer autant de drivers
indépendants qu'il y a d'équipements différents.
b. Communications SAGT-Equipements en OPC-UA
Aux yeux d'OPC-UA, les équipements sont vus comme des petits serveurs mettant à
disposition chacun de leurs attributs (alarmes, alertes, commande, états) sous forme de nœud OPC
qui possède une valeur. Par exemple pour une alarme ou une alerte, la valeur du nœud associé vaut
soit true quand l'alarme est présente soit false quand elle ne l'est pas. Les clients peuvent alors
s'abonner aux changements dans ces nœuds pour s'informer des alarmes/alertes levées par les
équipements.
Mais les équipements ne possèdent pas seulement des alarmes et des alertes comme
attribut. Ils ont aussi des états que les opérateurs extérieurs voudraient être en mesure de contrôler
à la manière du récent hacker de panneau à Lille. Pour changer les valeurs des nœuds, aussi appelés
data points, liés à l'état d'un équipement, un opérateur extérieur est autorisé à écrire la valeur qu'il
souhaite dans le nœud d'un attribut commande associé à cet état, et cette valeur sera transmise
grâce à l'intelligence du serveur OPC propre à l'équipement.
Ainsi lorsqu'on veut par exemple tourner une caméra vers la droite depuis le SAGT, nous
allons décrire la logique qui opère. Tout d'abord, le SAGT écrit la valeur de l'angle de rotation désiré
dans le télé-réglage associé à la rotation vers la droite. Ensuite la caméra interprète la commande et
commence la rotation. Lorsque la rotation est terminée, elle passe alors le nœud de l'état associé à
sa commande à la valeur trente degré. Le SAGT est alors au courant que la rotation a bien été
effectuée car il a souscrit aux changements de ce nœud d'état associé à la commande qu'il a envoyé.
Certains équipements comme les PMV sont plus complexes à piloter. Il interprète et traite en
effet les valeurs des nœuds de ses réglage seulement lorsqu'un nœud spécial appelé TC est passé à la
valeur true. Ainsi, le SAGT écrira ce qu'il voudra afficher sur le panneau dans les réglages associés,
puis écrira en dernier la valeur true sur la TC pour piloter concrètement le panneau. Il pourra en suite
aller vérifier dans les nœuds associés aux états de toutes les commandes que le pilotage s'est bien
effectué.
La première tâche de développement que j'ai réalisée dans l'application a été
l'ordonnancement des commandes pour s'assurer que la TC soit toujours placée en dernier et
permettre des pilotages complexes comme celui-ci. J'ai ensuite conçu et développé le simulateur
grâce à l'aide précieuse de l'architecte du projet. Nous avons implémenté un module de
communication qui s'occupe de centraliser les communications de l'application avec les
équipements.
c. Conception et implémentation du simulateur
En réalité, l'application n'est pas reliée indépendamment à chaque équipement mais à un
serveur OPC intermédiaire appelé frontal qui regroupe des ensembles d'équipement. Il existe par
exemple un frontal GTC qui regroupe tous les équipements des tranchées couvertes, mais encore un
frontal RAU qui regroupe les équipements postes d'appels d'urgence, ou le frontal DAI contenant les
caméra pour la Détection Automatique des Incidents.
Nous avons ensuite utilisé l'api java de l'Opc Fundation pour instancier un serveur OPC au
démarrage de l'application qui contient les nœud des attributs de tous les équipements de
l'application rassemblés par frontal. J'ai implémenté la fonction qui utilise cette api et s'intègre au
driver de communication du SAGT pour aller écrire la valeur voulue sur le nœud demandé. L'api
permet de récupérer le type du nœud du serveur opc afin que je puisse convertir adéquatement la
valeur sous le bon format pour l'envoyer.
Cela a rendu possible la simulation de l'écriture d'une valeur dans une commande d'un
équipement, mais le serveur de simulation des équipements que nous avons démarré ne possède
pas l'intelligence des frontaux. Nous sommes donc en train de demander à un chat d'aller chercher
une balle. Nous avons beau demander à cette caméra de tourner, elle n'en fera rien et son état ne
changera pas.
Afin de pouvoir updater les nœuds des états liés aux commandes nous avons choisi de
souscrire en simulation depuis le module de communication aux changements sur les nœuds des
commandes, chose qu'il ne fera jamais dans les conditions normales d'exploitation.
Un service JMS sur le topic duquel nous avons placé un listener dans notre module
simulation informera alors l'application lorsqu'un changement de valeur dans un noeud commande
sera effectif sur le serveur OPC. Mon module ira ensuite rechercher dans la table des attributs des
équipements l'adresse du datapoint de l'état associé à la commande pour le mettre à jour sur le
serveur avec la nouvelle valeur.
Une dernière manipulation pour la gestion des comptes-rendus lors des actions de pilotage
et le simulateur de frontaux a marqué la fin de développement du simulateur de frontal, et a permis
le démarrage de la phase de test du SAGT.
3. L'Application de Master Simulation
a. Présentation générale
Le master simulation a la main mise sur le déroulement d'une séance de simulation. Cela lui
permet de former des apprentis ou bien de tester des changements dans le référentiel des bases de
données sans risquer des conséquences négatives sur l'environnement réel d'exploitation. C'est une
application à part entière qui n'est accessible que par les profils ayant les droits de master
simulation.
b. Simulation des équipements
La première partie de l'application permet de simuler les valeurs des nœuds de n'importe
quel attribut des équipements sur le serveur OPC. Le SAGT ne peut en temps normal pas écrire
directement une valeur dans un nœud autre qu'une commande, mais le master simulation peut
survoler ces droits et écrire directement dans un état.
Il navigue pour rechercher un équipement puis le sélectionne dans le tableau ci-dessous. Cela
ouvre une popup qui permet d'écrire la valeur que l'on veut dans le nœud correspondant à l'attribut
que l'on souhaite parmi les états, les mesures, les alertes et les alarmes. Pour envoyer une
commande le master peut toujours piloter les équipements de manière habituelle dans le SAGT.
Interface de simulation des équipements
La popup se met automatiquement à jour en fonction des cases sélectionnées par l'utilisation grâce
au data-binding d'AngularJS.
c. Paramétrer des retours sur commande
Cette interface permet de simuler un disfonctionnement sur un équipement. Le but est de
simuler le fait que l'état de l'équipement ne se mette pas à jour avec la bonne valeur lorsque l'élève
du formateur essayera de la commander.
Ainsi, le master navigue à travers les TR possibles. Il en sélectionne une et écrase le retour
attendu par un nouveau retour qu'il paramètre. Ces données sont enregistrées en base grâce à un
controller et un repository.
Du côté serveur, j'ai ajouté une validation en plus qui, lorsqu'on souscrit à un changement de
valeur d'un noeud commande en simulation vérifie que sa réponse n'est pas écrasée avant d'aller
écrire dans l'état associé sur le serveur opc.
Interface de paramétrage des retours commande
d. Paramétrer des retours sur scénario
Comme décrit précédemment, les frontaux sont dotés d'une intelligence propre que leur
permet de réagir à une commande. Certaines commandes appelées scénarios sont capable
d'entraîner non pas un, mais une multitude de changements d'états par frontal. Par exemple le
scénario fermeture du tunnel entraînera l'arrêt des ventilations, l'extinction des éclairages, le
rabaissement des barrières et tout un tas d'actions gérées par le frontal.
Ces scénarios sont inconnus du SAGT, c'est à dire que l'application n'a aucune idée des états
modifiés par la commande scénario et ne sait à priori donc pas vérifier sa bonne exécution. Afin de
palier à ce problème, au lieu d'être associés à un vrai état d'équipement, les scénarios sont liés à un
nœud du frontal faisant le compte rendu de l'exécution du scénario par l'équipement.
Interface de paramétrage des retours scénario
L'interface de paramétrage d'un scénario permet au master simulation connaissant les
changements d'état d'un frontal liés au scénario de paramétrer leur exécution. L'interface que j'ai
implémenté lui donne accès aux scénarios qu'il a déjà paramétré sur le frontal sélectionné au
préalable. Il peut alors les modifier ou en ajouter un nouveau.
Pour paramétrer un scénario, il faut lui choisir un nom et choisir la valeur de l'attribut de
l'équipement du frontal qui le déclenchera sur la partie gauche de la popup. Il est ensuite possible de
paramétrer l'ensembre des retours d'états sur les équipements qui seront effectuer lorsque cette
commande sera envoyée par n'importe qui dans le SAGT.
e. Simuler des états de trafic
Cette interface permet de récupérer des portions de route et leur appliquer des
changements d'état de trafic. En mode d'exploitation normal, des équipements de mesure du trafic
envoient un volume gigantesque de données qui sont traitées par le module gestion trafic sous
forme de trames au format HMVL.
Toutes les 6 secondes, un algorithme lie ces données avec un état de trafic sur le tronçon de
la route contenant les points de mesure du trafic par les équipements. Ces données sont trop
complexes pour être réellement simulées, dont la partie simulation des états trafic contourne le
fonctionnement normal du SAGT qui il outrepasse le mécanisme de calcul des états de trafic sur la
route.
Afin de simuler un état de trafic sur une portion de route dans l'application, j'ai localisé les
portions de routes et je leur ai associé une mesure correspondante dans la table des mesures.
Injection d'états de trafic en simulation
Cette simulation ne permet pas de tester l'algorithme de calcul des états trafic, mais il permet de
vérifier le mécanisme des alertes bouchons qu'il lève lorsqu'on choisit un état de trafic bloqué. Il
permettra aussi à terme de mettre à jour la cartographie en fonction des données rentrées par le
master simulation.
Apparition des alertes bouchons sur les troncons concernés par l'injection de trafic bloqué
f. Listes d'action
Lors d'une formation , un des besoins primordiaux du formateur maître de la simulation est
de pouvoir quitter son poste afin d'aller observer et aider ses apprentis. Il souhaiterait donc pouvoir
programmer des apparitions d'alertes, d'alarmes, des injections d'état trafic et des pilotages
d'équipements au cours du déroulement d'une Simulation tout en restant éloigné son poste.
C'est l'intérêt de la programmation d'une liste d'action. On peut lui ajouter des actions de
type injection d'alarme, d'alerte, pilotage d'équipement ou encore injection d'état trafic. A celles-ci,
on peut ajouter des temporisations ou des contrôles opérateurs. Cela signifie qu'on attendra le
temps de la temporisation avant l'exécution de la prochaine action, ou bien que l'on attendra une
confirmation du master simulation avant de continuer le processus d'exécution.
Dans le menu principal d'affichage des listes d'action, le master peut cliquer sur une liste et
en afficher toutes les actions en bas de l'IHM.
Menu d'affichage des listes d'action
Il est possible d'éditer cette liste ou bien d'en créer une nouvelle à travers l'interface d'édition des
listes d'action.
Interface d'édition des listes d'action
Ici, on ajoute les étapes de la liste d'action une à une dans l'ordre dans lequel ont souhaitera les
exécuter en cochant le type d'action souhaité puis en cliquant sur le bouton ajouter une action. La
popup d'édition de l'étape de la liste d'action dépendra de son type.
Popup édition étape liste d'action de type injection d'alarme
Popup édition étape liste d'action de type pilotage équipement
On ajoute une à une les actions de la liste. Lorsqu'on en sélectionne une dans la liste, il est possible
de paramétrer ses temporisations et contrôles, ainsi que de modifier sa position grâce à une nouvelle
partie de la fenêtre qui s'affiche en bas à gauche.
Sauvegardons cette liste d'action, puis tentons de l'exécuter dans le menu principal
d'affichage des listes d'action. L'utilisateur peut voir le statut des actions qui s'enchaînent ainsi que la
barre de progression de leurs temporisations.
Si l'action exige une confirmation côté master simulation avant de continuer son exécution,
de nouveaux boutons s'updatent en bas de la page. C'est encore une fois toute la magie d'AngularJS
de lier aussi simplement les scopes et les vues.
4. Autres Tâches
a. Initialisation du référentiel
Sopra Stéria est responsable de l'initialisation des données des tables de l'application avec les
données fournies par EFE. J'ai été chargé de la génération des scripts d'insertion dans les bases du
SAGT à partir des données d'un référentiel national du réseau routier et de données sur le futur tracé
de la L2.
Mes tâches étaient de comprendre le fonctionnement de ces tables et ce qu'elles voulaient
dire sans documentation pour adapter leurs données au MDD de notre application. Cela a permis
d'approfondir mes connaissances en SQL et mes compétences avec PgAdmin/PostgreSQL. Ces
problèmes étaient facilement divisibles en petites parties facilement résolubles ce qui rendait la
tâche fastidieuse agréable et satisfaisante. Une requête a été trop fastidieuse à réaliser un SQL et
m'a parmis d'appréhender JDBC avec l'aide d'un collègue.
J'ai ainsi pu importer les données sur les axes gérés par la DIRMed comme par exemple les
bretelles, échangeurs, les communes et les départements. J'ai aussi importé les points de repère sur
la route indispensables pour tester toutes les activités de localisation dans le SAGT.
Exemple de requête SQL pour les échangeurs
b. Tests de qualification interne
J'ai réalisé des tests en qualification interne pendant près d'un mois. Cela m'a donné l'occasion
d'avoir un aperçu encore plus global sur les étapes et le fonctionnement d'un large projet
informatique. J'ai aussi appris à me servir de l'outil d'HP Quality Center. Ce dernier est très utile pour
tester les fonctionnalités de l'application et instaurer une communication efficace entre
développeurs, testeurs et chefs de projets.
c. Correction de bug
La dernière tâche qui m'a été assignée pendant quelques semaines est la correction de bugs
sur l'application. Un chef de projet définit un objectif de correction d'un certain nombre de bug avec
le développeur et l'accent est mis sur la rapidité.
Assez souvent cependant, les bugs s'avéraient être des fonctionnalités entières pas encore
développées. J'ai ainsi pu coder un service qui prévient l'utilisateur de l'arrivée imminente d'un
événement planifié et rappelle tous les jours à la bonne heure la présence d'un chantier qui se répète
quotidiennement.
Cela a été une étape plutôt enrichissante pour moi car j'ai eu l'occasion de toucher à
plusieurs endroits du code de l'application et relire le code de développeurs expérimentés. J'ai le
sentiment que rien que le fait d'avoir relu leur code m'a fait beaucoup progressé et évolué dans ma
manière d'approcher la programmation.
Conclusion
Comblé par tout ce que mon stage ma apporté sur la plan technique et humain, je suis ravi
d'avoir eu le privilège d'apprendre et utiliser professionnellement un ensemble de nouvelles
technologies du web. J'ai été par ailleurs aussi très heureux de parvenir à apporter ma touche
personnelle et vivre un grande aventure au sein d'un groupe projet unique et impressionnant.
Par ailleurs, cela fut aussi l'occasion de découvrir concrètement le milieu des ESN. Ma
curiosité me projette maintenant vers un changement de cap total car je souhaiterais commencer
ma carrière en prenant part à un projet d'entreprenariat centré autour d'un projet innovant à
l'étranger.
