Système de gestion des subventions des établissements d'acceuils collectif (OMEGA)

Le Client :

La Caisse nationale des allocations familiales (CNAF) forme la branche « famille » de la Sécurité sociale française, qu'elle gère au travers d'un réseau formé par les 123 caisses d'allocations familiales (CAF) réparties sur tout le territoire.

Le Centre National d'Etude et de Développement Informatique (CNEDI) est le centre national gérant l'informatique des CNAF. Il s’agit de sites, extérieurs à la CNAF mais sous sa dépendance directe, qui regroupent les équipes en charge des études, du développement et de la maintenance des applications et autres solutions informatiques de la branche Famille. Il existe huit CNEDI répartis sur tout l’hexagone (souvent leur implantation est le fruit d’une histoire : la succession opportune d’une initiative régionale ou locale, fondue désormais dans la dimension nationale).

Description du projet :

Le système d'information de la CNAF est constitué d'applications régionales et nationales sur des mainframes Bull ou IBM, et d'applications exécutées en local dans les CAF sur des serveurs AIX. Dans un souci de modernisation, la CNAF a mis en place une nouvelle architecture basée sur la technologie J2EE, et a ainsi développé un portail web intranet appelé NIMS (navigateur intranet multi services). Le but à terme est la migration de toutes les applications de la CNAF vers cette plateforme, et de les intégrer dans le portail NIMS.

Dans ce contexte, le projet consiste en la migration de l'application de gestion des dossiers des établissements d'accueil collectif (crèches, jardins d'enfant, foyer de jeunes travailleurs, ...) vers la plateforme J2EE NIMS. Ce projet, appelé OMEGA, est un projet d'envergure nationale, et a donc été découpé en plusieurs phases. La première étant la réalisation d'un prototype permettant de valider divers aspect technique. En plus de la migration vers la plateforme NIMS, la CNAF désire intégrer au sein de son système d'information un système de gestion de ces règles metier (BRMS). Ce prototype constituant un cadre idéal pour d'expérimenter une telle intégration, un des objectifs est donc la mise en place du BRMS IBM Ilog Jrules afin de gérer et d'exécuter les règles métiers liées à l'application OMEGA.

---

Organisation et gestion de projet :

• Référent technique pour les autres membres de l'équipe (3 personnes)
• Outil de gestion de configuration (cvs).

Aspects techniques :

• Conception UML avec Bouml.
• Architecture JAVA, J2EE 1.5.
• Serveur d'application IBM Websphere 7.5.
• Base de donnée DB2 sur AIX.
• Frameworks : Struts, Hibernate, framework interne CNAF (envnims)
• BRMS : IBM ILOG JRules
• Cible : Serveur sous UNIX AIX et client sous windows Xp avec navigateur IE6.

Réalisations :

Conception :

• Réalisation du modèle objet UML à partir des spécifications fonctionnelles.

Serveur :

• Génération du code (JAVA) de la partie modèle objet à partir BOUML.
• Génération du mapping objet/relationnel hibernate.
• Développement des traitements métiers.

BRMS :

• Installation des différents composants du BRMS Jrules (Rule Team Server, Rule Execution server, Rule Studio).
• Intégration des régles métiers au sein du BRMS, et développement des services de décisions correspondants.

Base de données :

• Génération du schéma de la base de donnée DB2 à partir du mapping hibernate.

Client :

• Réalisation de différents écrans JSP/Envnims.

Projet européen BIOMED2 - ARROW

Le Client :

Le LIRIS (Laboratoire d'InfoRmatique en Image et Systèmes d'information) est né à la suite du regroupement de plusieurs laboratoires de recherche lyonnais travaillant dans le domaine des Sciences et Techniques de l'Information et de la Communication. Il est associé au CNRS avec le label UMR 5205. L'institut d'attachement principal est INS2I. L'institut d'attachement secondaire est INSIS. Le LIRIS a également une convention avec l'ISCC du CNRS. Les activités du laboratoire sont regroupées dans deux départements thématiques : "Image" et "Données, Connaissances, Services".

Le département Image regroupe 40 EC (12PR, 28MCF) et 3 CR CNRS répartis en cinq équipes. Ces équipes développent des méthodes d'analyse des données issues de capteurs (2D, 2D+t, 3D), des méthodes permettant une meilleure compréhension et des méthodes de modélisation de données numériques multidimensionnelles. Les thématiques recouvrent donc les domaines de l'analyse d'image, de la modélisation, de la simulation ou encore du rendu. Les modèles de représentation des données sont très variés et vont des grilles régulières issues des capteurs, aux graphes, maillages, modèles géométriques, modèles procéduraux, modèles statistiques ou physique.

Description du projet :

Ce projet a pour but le développement d'un logiciel d'assistance au traitement du cancer par radiothérapie conformationnelle.

La radiothérapie est l’un des principaux modes de traitement du cancer avec la chirurgie et la chimiothérapie, à laquelle elle est d’ailleurs souvent associée. La radiothérapie consiste à utiliser des radiations pour détruire les cellules cancéreuses. Ainsi, de fortes doses de rayons X (des milliers de fois supérieures à celles utilisées en radiographie) sont envoyées, à l’aide d’un accélérateur. En radiothérapie conventionnelle, la préparation du traitement s’effectue à l’aide d’un simulateur. Il s’agit en fait d’un appareil d’imagerie à rayons X de basse énergie. En radiothérapie conformationnelle, la planification du traitement est plus longue et plus complexe. Cette approche de la radiothérapie vise à limiter l’irradiation de zones saines, tout en augmentant la dose délivrée à la zone cancéreuse. Cependant, dans ces deux approches, le patient, les organes et la tumeur sont considérés comme fixes et rigides. Mais dans la réalité, le patient respire et cela induit des mouvements de la tumeur, et les organes peuvent se déformer.

Ce projet consiste à définir des nouveaux modèles permettant d'obtenir une représentation 3D des organes visés ainsi que de la tumeur. Il s'agit ensuite de leur associer un modèle physique, et ainsi de produire des simulations physiquement proche de la réalité, et ceci en temps réel. Couplé à un dispositif de suivi de mouvement externe, ce système permet ainsi de déterminer si la tumeur sort du champ d'irradiation définit par le radiothérapeute, évitant ainsi une irradiation nuisible des tissus sains.

---

Aspects techniques :

• Algorithmique et modèle géométrique (BSpline, surfaces implicites, systèmes de particules)
• Modélisation et reconstruction 3D
• Simulation physiquement réaliste des mouvements et déformations.
• Imagerie médicale
• Développement C/C++.
• API Graphique : OpenGL
• API programmation parallèle MPI
• Cible : cluster linux, station de travail Silicon Graphic (SGI) sous IRIX.

Réalisations :

• Définition d'algorithme de reconstruction 3D à partir d'image médicale (CT scans). Les modèles géométriques cible sont les B-Spline, les surfaces implicites et les systèmes de particules.
• Définition de modèles physiques qui, associés à ces modèles géométriques, permettent de produire des simulations réalistes des organes, et plus généralement des objets déformables.
• Définition d'algorithme parallèle permettant d'accélérer la production de ces simulation.
• Définition d'un modèle de rendu pour les systèmes de particule.
• Développement d'un logiciel(C/C++, OpenGL) mettant en oeuvre les modèles et algorithmes choisis.
• Portage de ce logiciel vers une plateforme de calcul parallèle basée sur un cluster linux et sur l'API MPI.
• Collaboration étroite avec les services cancérologie de l'Hopitâl Christie de Manchester (UK) et de la clinique de Magdeburg (DE).

Publications :

Chapitre dans un livre

• [1] M. Sarfraz, editor. Geometric Modeling: Techniques, Applications, Systems and Tools, chapter Skeletal implicit surface reconstruction and hybrid model for organs’ interactions simulation, by M. Amrani, B. Crespin and B. Shariat. Kluwer Academic Publishers, Dordrecht, Hardbound, ISBN 1-4020-1817-7, December 2003.

Articles dans des revues

• [2] M. Amrani, F. Jaillet, M. Melkemi, and B. Shariat. Simulation of deformable organs with a hybrid approach. Revue Internationale de CFAO et d’Infographie, 16/2001:213–242, 2001.
• [3] M. Amrani, F. Jaillet, and B. Shariat. Deformable objects modeling and animation : Application to organs’ interactions simulations. Journal for geometry and graphics, 4(2):181–188, december 2000.
• [4] Morade Amrani, Fabrice Jaillet, and Behzad Shariat. Tracking of target motion using physically based modelling of organs for radiotherapy. Green journal : Radiotherapy and Oncology, - special issue, june 2003.

Conférences internationales

• [5] M. Amrani, M. Beuve, F. Jaillet, and B. Shariat. Physically based modeling with particle systems. In 10th ISPE international conference on concurrent engineering: research and applications (CE 2003), volume 2, Madeira Island- Portugal, july 2003.
• [6] M. Amrani, B. Crespin, and B. Shariat. Skeletal implicit surface reconstruction from section for flexible body simulation. In IEEE, editor, 2001 IEEE Conference on Information Visualization, London, UK, july 2001.
• [7] M. Amrani, F. Jaillet, S. Pontier, B. Shariat, and D. Vandorpe. Deformable objects modeling and animation : Application to organs’ interactions simulations. In Proceedings of the 9th Int’l Con. on Geometry and Graphics, pages 164–168, Johannesburg, South Africa, july 28-31 2000.
• [8] M. Amrani and B. Shariat. Deformable organs modeling with multi layer particle systems. In IEEE, editor, 2000 IEEE Conference on Information Visualization, pages 351–356, London, UK, july 19-21 2000.
• [9] Christian M ̈ller, Morade Amrani, Michael Beuve, and Behzad Shariat. Modeling of deformable organs with particle systems : Influence of the applied potential. Poster in 9th HCPBM Workshop, October 2003.

Conférences nationales

• [10] M. Amrani. Modélisation et animation d’objets déformables. In Proceedings des 13e journées de l’AFIG, pages 181–190, Grenoble, France, november 29 - december 1 2000.
• [11] M. Amrani and B. Shariat. Modélisation et simulation d’organes déformables. In Journée thématique Coopération analyse d’image et modélisation, pages 77–81, Lyon, June 2001.

Système de gestion dynamique des voies du Pont de Saint-Nazaire

Le Client :

Le Conseil général est la collectivité qui gère les affaires d'un département. Ses représentants, les conseillers généraux, sont élus par les électeurs des cantons. La Loire-Atlantique compte 59 cantons, son Conseil général est donc représenté par autant d'élus.

Description du projet :

Ce projet consiste en la réalisation d'un système informatique permettant le pilotage des équipements et la supervision du trafic sur le pont de Saint-Nazaire. Ce nouveau système permettra entre autre une gestion modulable et dynamique de l'affectation du sens des voies de circulation sur le pont afin de fluidifier le trafic, une innovation au niveau national.

---

En effet, le pont de Saint-Nazaire est un pont français à haubans multi-câbles en éventail qui enjambe l'estuaire de la Loire et relie la ville de Saint-Nazaire (au lieu-dit de Penhoët, via la commune de Montoir-de-Bretagne où le pont prend réellement pied) sur la rive droite au nord, à Saint-Brévin-les-Pins sur la rive gauche au sud. L'ouvrage métallique haubané mesure 720 m et l'ensemble des ouvrages avec les viaducs d'accès représente une longueur totale de 3 356 mètres.

La circulation y est en progression régulière, avec un trafic moyen journalier annuel de 28 500 véhicules (atteignant 34 500 en période d'été), dont 5 % de trafic poids lourds. Le temps de franchissement de l'ouvrage peut monter jusqu'à vingt minutes aux heures de pointe et en période estivale.

Pour faire face à ces situations et accompagner la progression du trafic routier, en tenant compte du caractère très pendulaire de celui-ci, les élus du Conseil général de Loire-Atlantique ont décidé de mettre en place un système unique en France, permettant une « gestion dynamique » de la circulation sur l'ouvrage. Dans la mesure où le profil en travers de l'ouvrage ne permet d'offrir que trois voies de circulation, il s'agit de porter de un à deux le nombre de voies pour le sens de circulation « privilégié », en fonction du volume du trafic, et cela par affectation modulable de la voie centrale.

La voie centrale réversible sera identifiée par l'installation de 22 portiques de signalisation (un tous les 250 mètres.) supportant des feux d'affectation de voies, et un marquage au sol par incrustation dans la chaussée de 1600 plots lumineux rouges permettant de matérialiser la ligne continue lorsqu'ils sont allumés. Une signalisation verticale dynamique lumineuse de rabattement sera mise en place pour faciliter les approches.

Gestion du projet et organisation :

• Définition des spécifications fonctionnelles du système à partir du cahier des charges définit par le client.
• Encadrement en tant que référent technique et fonctionnel pour les autres membre de l'équipe projet (7 personnes).
• Mise en place et gestion de la plateforme de développement.
• Outil de gestion de configuration (Subversion).
• Outil de suivi de bugs (Mantis).
• Installation plateforme d'intégration (serveur Linux CentOS 5)

Aspects techniques :

Le projet était soumis à plusieurs contraintes technique. D'une part, le système ayant pour vocation le pilotage et la supervision d'équipements terrains, une contrainte de communication et de réactivité quasi temps réel s'impose. D'autre part, ce projet, bien qu'étant sous la houlette du conseil général de Loire-Atlantique, il se devait néanmoins de respecter les préconisations du ministère du transport en matière de système d'information (référentiel ACAI), qui implique entre autre que les applications doivent être basé sur une architecture web et sur des frameworks et logiciels opensources.

Dans ce contexte, nous avons opter pour les choix techniques suivants :

• Conception UML avec Rational Rose.
• Architecture J2EE 1.5.
• Serveur d'application Jboss 5.
• Communication avec les frontaux des équipements par le développement de connecteurs JCA 1.5.
• Base de donnée Postgresql 8.3.
• Frameworks : Jboss Seam, Drools, Quartz, Hibernate (EJB3, JPA).
• Client léger Richface, Ajax et SVG pour les synoptiques.
• Cible : Serveur sous Linux CentOS 5 et client sous windows Xp avec navigateur Firefox.

Réalisation :

Conception :

• Réalisation du modèle objet UML à partir des spécifications fonctionnelles.

Serveur métier :

• Génération du code (JAVA) de la partie modèle objet à partir de rational rose. Développement d'un outil en Java permettant de reprendre le code généré par rational rose afin de l'enrichir de code spécifique J2EE, et d'annotations JPA/Hibernate.
• Définition des interfaces avec les systèmes externes basés sur l'architecture JCA 1.5. Ainsi, des interfaces utilisant différents types de protocole ont été mis en place. Une interface avec des équipements basés sur une scrutation de base de données, une interface avec des équipements en MODBUS (API JaMod), une interface avec un système de vidéo surveillance basée sur un protocole socket. L'utilisation de l'architecture JCA permet l'intégration de ces différentes interface directement dans le serveur d'application JBOSS.
• Mise en place d'un moteur de règles basé sur DROOLS afin de synthétiser les informations (alarmes, défauts équipements) remontées du terrain, mais également pour calculer les actions à mettre en oeuvre en réponse aux modification des conditions d'exploitation sur le pont.
• Définition de webservices afin de fournir des systèmes tiers des informations sur l'état de trafic (au format DATEX par exemple).

Réplication :

• Afin d'assurer la continuité de l'exploitation en cas de défaillance d'un PC de contrôle, le système est redondé. Ainsi, un mécanisme de réplication entre les deux systèmes redondants a été développé et mis en place afin de permettre au système passif de reprendre l'exploitation à l'état dans lequel l'a laissé le système actif avant sa défaillance.

Persistance des données :

• Génération automatique du schéma BD à partir des annotations grâce aux outils d'Hibernate.

Client : L'interface client est un client léger qui peut être accédé via un navigateur web.

• Il comporte une interface textuelle permettant l'affichage en temps réél de l'état du trafic sur le pont, réalisé avec le framework richfaces et un système de push pour obtenir les remontées d'informations depuis le serveur.
• En plus d'une interface textuelle permettant l'affichage de différentes informations d'exploitation, des synoptiques réalisé en SVG, et animés également en temps réél, permettent d'avoir une représentation graphique de l'état des équipements sur le pont, ainsi que l'état du trafic sur le pont. Le client permet également le pilotage des équipements, comme par exemple l'affichage d'information à destination des usagers sur les panneaux à messages variables.

Système de supervision des stations de la ligne 14

Le Client :

Le Groupe RATP est le cinquième acteur mondial du transport public. Métro, rail, tramway, bus, la RATP est présente sur tous les modes de mobilité collective. En Ile-de-France, elle exploite, entretient, modernise et développe l’un des réseaux multimodaux les plus denses au monde. Chaque jour, elle transporte plus de 10 millions de personnes. Cette expérience, la RATP et ses filiales l’exportent sur tous les continents. Unis par le sens du service public, les 56 000 hommes et femmes du Groupe partagent un même objectif : permettre aux voyageurs de se déplacer sereinement, rapidement et dans un maximum de confort.

Description du projet :

La ligne 14 du métro de Paris est l'une des seize lignes du réseau métropolitain de Paris et la seule exploitée de manière complètement automatique. La ligne est aussi connue sous son nom de projet : Meteor pour « MÉTro Est-Ouest Rapide ». Initialement, cette ligne reliai la station Saint-Lazare à la station Bibliothèque François Mitterrand.

Des travaux ont été engagé pour prolonger cette ligne jusqu'à la station Olympiades. Dans le cadre de ces travaux, l'installation d'équipements de nouvelle génération a rendu nécessaire une refonte du système de supervision.

Le projet consiste donc en une réécriture compléte, mais iso-fonctionnelle, du système d'information permettant une exploitation centralisée de toutes les stations le long de la ligne. Le système vise la gestion de tous les équipements installés sur la ligne (sécurité, détection incendie, escaliers mécaniques, portes automatiques ...) ainsi que tous les dispositifs d'information aux voyageurs (SAET, interphone, radio, diffusion messages sonore, dispositifs d'affichage, ...).

---

Organisation et gestion de projet :

• Participation à la définition des spécifications fonctionnelles du système à partir du cahier des charges définit par le client.
• Encadrement en tant que référent technique et fonctionnel pour les autres membre de l'équipe projet (5 personnes).
• Outil de gestion de configuration (cvs).
• Outil de suivi de bugs (Mantis).
• Participation à la mise en service du système.

Aspects techniques :

• Conception UML Rational Rose.
• Architecture Client/Serveur.
• Objet distribué (Ilog Server / Corba).
• Serveur : C++/Multithread/Ilog Server/Socket/LibACE
• Communication terrain : Applibus, LibA (spécifique RATP).
• Messagerie X400 (API Isode X400).
• Moteur de règle : ILog Rules pour C++.
• Client : Java/Swing/Ilog Jviews/Ilog Diagrammer.
• Base de donnée : Oracle 9.
• Cible : Serveur Sparc de SUN sous Solaris et clients PC sous windows.

Réalisation :

Conception :

• Réalisation du modèle objet UML à partir des spécifications fonctionnelles.

Serveur métier :

• Génération du code (C++) de la partie modèle objet à partir de rational rose.
• Développement de scripts PERL permettant de reprendre le code généré par rational rose afin de l'enrichir de code spécifique au framework ILOG serveur, ainsi que de certaines parties génériques liées au fonctionnel du système (chargement du référentiel depuis la BD, requêtes SQL).
• Interface avec les équipements : utilisation d'une librairie d'abstraction (LibA) développée par la RATP, basée sur Applibus. Cette librairie fournit une interface de type abonnement/notification pour la réception des états/défauts des équipements, et sur des invocations synchrones pour le contrôle/commande. Utilisation de RPC Ilog pour remonter les états des équipements au serveur métier. Cette interface permet le pilotage de la majeure partie des équipements.
• Moteur de règles : Des états et défauts de synthèses doivent être élaboré à partir des remontées terrain. Une interface basée sur l'api ILOG Rules a donc été développée afin de réaliser ces calculs.
• Interface avec la messagerie X400 de la RATP : développement d'un client de messagerie X400 afin de réceptionner des informations générales à destination des voyageurs. Utilisation de l'API Isode X400.
• Interfaces avec les systèmes SAET (réception des temps de passage afin d'élaborer des temps d'attente à destination des voyageurs), RADIO (réception des demandes de communication des agents), PC-SEC (alerte du pc sécurité). La communication avec ces système se fait par socket TCP (client socket), avec une approche multithread.
• Interface avec les moniteurs de téléaffichage : Affichage des temps d'attentes, ainsi que des messages d'informations à destination des usagers. La comunication avec ces moniteurs se fait par de la socket TCP (serveur socket à laquelle se connecte les moniteurs) avec une gestion multithreadé (un thread par moniteur).
• Interface avec un système de GMAO : basée sur de l'invocation de procédures stockées directement sur la BD de GMAO.
• Interface avec l'IHM d'exploitation (JAVA/SWING) : basée sur le mécanisme de vue/notification ILOG serveur pour la communication serveur vers IHM, et sur l'invocation de RPC Ilog pour la communication IHM vers serveur.

Client :

• Le client est réalisé en java swing et intègre des synoptiques svg grâce à l'api ilog jviews diagrammer. Ce client est connecté au serveur via l'api Ilog server, qui met en oeuvre un mécanisme d'objet distribué (corba), avec un système d'abonnement/notification. Ainsi, chaque client est notifié en temps réel de l'apparition ou disparition d'alarmes, d'appel interphone, ....

Système de supervision des tunnels d'Ile de France

Le Client :

La Direction des Routes d’Ile-de-France(DiRIF) est née le 1er janvier 2007 et a rejoint la Direction Régionale et Interdépartementale de l’Equipement et de l’Aménagement d’Ile-de-France (DRIEAIF) au 1er juillet 2010.

La DiRIF est chargée de gérer les routes nationales et les autoroutes sans péages en Ile-de-France restant sous la responsabilité de l’État, après le transfert d’une partie du réseau routier national aux départements.

Description du projet :

Ce projet consiste en la réalisation du système informatique permettant la gestion de tous ces équipements, d'intégrer les nouvelles normes de sécurité tel que le calcul automatique, et éventuellement l'exécution, de plans d'action en réponse aux évènement (accident, incendie, ...) pouvant perturber le trafic. Ce système est donc un élément central sur lequel s'appuie les opérateurs de sécurité trafic (OST) pour assurer une exploitation sécurisée du réseau des 22 tunnels d'Ile-de-France.

---

Suite aux incendies des tunnels du Mont Blanc (1999), du Gothard (2001) et du Fréjus (2005), l’Etat a décidé de renforcer la sécurité dans les tunnels. Parce que l’enjeu sécurité est sa priorité, l’Etat investit 600 millions d’euros sur 5 années pour la modernisation des tunnels en Ile-de-France. Moderniser 22 tunnels en quelques années, c’est l’objectif que la Direction des Routes d’Ile-de-France, la DIRIF, s’est fixé. Des caméras « intelligentes » tous les 100 mètres, des réseaux de communication doublés, plus de 500 000 mètres carrés de parois protégées pour améliorer la résistance au feu, une ventilation avec un débit de 240 mètres cube d’air par seconde, etc…Au terme de ces travaux, ces tunnels seront parmi les plus modernes d’Europe.

La sécurité des 22 tunnels d’Ile-de-France est aujourd’hui pilotée par 4 PC de sécurité, qui se répartissent la gestion des tunnels. Chaque PC gère ainsi la sécurité de plusieurs tunnels à la fois. Dans le PC, l’opérateur de sécurité trafic a pour mission de surveiller l’ensemble des données qui lui parviennent sur ses ordinateurs de Gestion Technique Centralisée (GTC) : images vidéo, niveaux de pollution, défauts éclairage, etc. Lorsqu’un évènement anormal se présente, c’est à l’opérateur d’évaluer si cela pose un problème de sécurité. Il a également pour mission, en cas de problème grave avéré, de fermer le tunnel, d’actionner la ventilation de désenfumage après avoir localisé l’incendie et de déclencher le dispositif d’évacuation s’il le juge nécessaire. Dans le même temps, il donne l’alerte aux services de secours.

Un système intelligent d’aide à l’exploitation : Aujourd’hui, l’opérateur a à sa disposition des informations essentiellement techniques : défaut d’éclairage, une porte qui s’ouvre, dysfonctionnement des dispositifs de ventilation… Or, elles ne permettent pas toujours d’évaluer rapidement avec précision la gravité d’un incident. Un nouveau système de pilotage de la sécurité sera mis en place pour l’ensemble des tunnels. Il repose sur un système d’aide à l’exploitation, spécialement développé pour la Direction Interdépartementale des routes d’Ile-de-France, qui répond à une approche non plus technique mais « évènementielle ». Cela signifie qu’il a pour fonction de fédérer différentes alarmes remontant du tunnel (par exemple, le début d’un incendie localisé par le système de détection automatique associé à l’ouverture d’une porte de secours), présumant ainsi un évènement alarmant. Une fois que l’opérateur validera l’alarme en qualifiant l’évènement (avec la vidéo par exemple), le système lui proposera un plan d’action : ventilation, fermeture, évacuation… Le système d’aide à l’exploitation permettra à l’OST de filtrer les évènements qui posent un réel problème de sécurité, au détriment des autres, susceptibles de « parasiter » son travail. Les problèmes techniques secondaires sont directement gérés par le « technicien de diagnostic maintenance » spécialisé dans la gestion technique des équipements. Aujourd’hui, dans chaque PC de sécurité, l’opérateur gère simultanément autant de systèmes de pilotage qu’il y a de tunnels à surveiller et donc une multitude d’écrans de contrôle. Le nouveau dispositif sera uniformisé et homogénéisé : chaque opérateur ne pilotera plus qu’un seul système centralisé pour l’ensemble des tunnels qu’il aura à gérer. Il aura devant lui un nombre limité d’écrans spécialisés : un écran pour la détection d’évènements (pour l’ensemble des tunnels), un écran synoptique pour repérer le lieu des évènements et un écran diffusant les images vidéo.

Gestion de projet et organisation :

• Participation à la définition des spécifications fonctionnelles du système à partir du cahier des charges définit par le client.
• Encadrement en tant que référent technique et fonctionnel pour les autres membre de l'équipe projet (3 personnes).
• Outil de gestion de configuration (VSS (visual sourcesafe)).
• Outil de suivi de bugs (Mantis).
• Installation plateforme d'intégration (windows server 2003)

Aspects techniques :

• Conception UML Rational Rose
• Architecture Client/Serveur
• Objet distribué (Ilog Server / Corba)
• Serveur : C++/Multithread/Ilog Server/Xerces xml/Socket
• Communication terrain : OPC, libOPC, serveur OPC PcVue
• Moteur de règle : ILog Rules pour C++
• Client : Java/Swing/Ilog Jviews
• Base de donnée : Oracle 10g RAC
• Cible : Serveur sous Windows Server 2003 et client sous Windows Xp

Réalisation :

Conception :

• Réalisation du modèle objet UML à partir des spécifications fonctionnelles.

Serveur métier :

• Génération du code (C++) de la partie modèle objet à partir de rational rose.
• Développement de scripts PERL permettant de reprendre le code généré par rational rose afin de l'enrichir de code spécifique au framework ILOG serveur, ainsi que de certaines parties génériques liées au fonctionnel du système (chargement du référentiel depuis la BD, requêtes SQL).
• Interface avec les équipements : La communication avec les équipements se fait au travers du protocole OPC. Ainsi, cette interface communique avec un serveur OPC (PCVue). Un mécanisme d'abonnement permet d'être notifié de tous les changements d'état des équipements. La partie pilotage des équipements se fait par la mise à jour de variables de commande dans la base du serveur OPC. Utilisation de RPC Ilog pour remonter les états des équipements au serveur métier. Cette interface permet le pilotage de la majeure partie des équipements.
• Moteur de règle : une interface basée sur l'API Ilog Rules a été développée afin d'implémenter des règles d'exploitation métier. Deux types de règles ont été définis. Des règles d'élaboration et de filtre d'alarmes à partir des états des équipements. Des règles de calcul des plans d'action à mettre en œuvre en réponse à l'apparition ou l'évolution de divers évènements ayant une incidence sur l'exploitation.

Réplication :

• Chacun des 4 PC sont doté de deux serveurs redondant, l'un actif et l'autre passif. Un mécanisme de réplication a été développé afin de permettre au serveur passif de reprendre l'exploitation là où elle s'est arrêté lors de la défaillance du PC actif.
• Les PC sont couplés deux à deux, et ainsi un PC peut reprendre l'exploitation du PC auquel il est associé en cas de défaillance totale de ce dernier. Ainsi, un mécanisme de réplication a également été mis en en place entre les serveurs des PC couplés.

Base de donnée :

• Afin de persister les données produites durant l'exploitation, un système de serialization des objets du système sous forme d'un flux pl/sql a été développé afin d'automatiser les opérations d'écriture en base de donnée.
• Chaque PC est doté de deux instance de sgbd Oracle 10g repliquées entre elles par le système RAC d'Oracle.
• La réplication entre les données de deux PC couplés est réalisé par le biais de procédures stockées et de trigger.

Client :

• Le client est réalisé en java swing, et est connecté au serveur via l'api Ilog server, qui met en oeuvre un mécanisme d'objet distribué (corba), avec un système d'abonnement/notification. Ainsi, chaque client est notifié en temps réel des modifications des conditions d'exploitation, de l'apparation ou disparition d'alarme et d'évènement, ainsi que des plans d'action calculé par le système en réponse à l'état actuel du trafic.

Système de vidéosurveillance du périphérique Parisien

Le Client :

La Direction des Routes d’Ile-de-France(DiRIF) est née le 1er janvier 2007 et a rejoint la Direction Régionale et Interdépartementale de l’Equipement et de l’Aménagement d’Ile-de-France (DRIEAIF) au 1er juillet 2010.

La DiRIF est chargée de gérer les routes nationales et les autoroutes sans péages en Ile-de-France restant sous la responsabilité de l’État, après le transfert d’une partie du réseau routier national aux départements.

Description du projet :

Ce projet consiste en la réalisation d'un système de pilotage d'équipements de vidéosurveillance déployer le long du boulevard périphérique d'Ile-de-France, sur les voies standards mais également en tunnel. Il permet notamment de piloter près de 2000 caméras IP et POSM, 5 murs d'images et des enregistreurs vidéo en réseau. Il offre ainsi aux opérateurs de sécurité du trafic (OST) un outil centralisé leur permettant d'une part une surveillance en temps réel des conditions de trafic, et d'autre part l'analyse des vidéos automatiquement enregistrées lors de la détection d'évènements (accident, incendie, ...) survenus sur le réseau.

---

Aspects techniques :

• Conception UML avec Rational Rose.
• Framework .Net 3.5 (vb.net, c++/cli, .net remoting, asp.net)
• Communication avec les frontaux des équipements par COM/DCOM
• Base de donnée Oracle 9.
• Client riche, ASP.NET, Ajax, ActiveX.
• Cible : Serveur sous Windows server 2003 et client sous windows Xp avec navigateur IE.

Réalisation :

Serveur métier :

• Développement en VB.NET du serveur central chargé des traitements fonctionnels liés à l'exploitation du réseau de vidéo surveillance.
• Interface avec les caméras par le biais d'API COM/DCOM.
• Interface mur d'image : développement en C++/CLI (.NET Pur) de l'interface de pilotage des murs d'image (de marque Planar). La communication avec ces équipements se fait via de la socket TCP.
• Interface avec les IHM : les IHM, clients riche ASP.NET, communique avec le serveur métier via le protocole .NET Remoting.

Réplication :

• Chacun des 4 PC sont doté de deux serveurs redondant, l'un actif et l'autre passif. Un mécanisme de réplication a été développé afin de permettre au serveur passif de reprendre l'exploitation là où elle s'est arrêté lors de la défaillance du PC actif.
• Les PC sont couplés deux à deux, et ainsi un PC peut reprendre l'exploitation du PC auquel il est associé en cas de défaillance totale de ce dernier. Ainsi, un mécanisme de réplication a également été mis en en place entre les serveurs des PC couplés.

Base de donnée :

• Afin de persister les données produites durant l'exploitation, un système de serialization des objets du système sous forme d'un flux pl/sql a été développé afin d'automatiser les opérations d'écriture en base de donnée.
• Chaque PC est doté de deux instance de sgbd Oracle 10g répliquées entre elles. La réplication entre les données est réalisé par le biais de procédures stockées et de trigger.

Logiciel parallèle de détection de défauts sur textile

Le Client :

l’IFTH (Institut Français du Textile et de l'Habillement) offre un ensemble de solutions pour la mise au point de nouveaux produits ou de nouveaux processus pour les différents marchés que sont le transport, la santé, l’habillement ou le bâti. Afin d’accompagner les entreprises dans leur démarche d’innovation, l’Institut a développé un réseau de plates-formes de services pour les industriels du Textile, de l'Habillement et des Textiles Techniques.

Le LIP (Laboratoire de l'Informatique du Parallélisme) est le laboratoire d'informatique de l'ENS Lyon. Il est composé d'enseignants permanents et de chercheurs du CNRS. Les travaux de ce laboratoire sont fortement orienté vers le calcul haute performance. Grâce à la conception d'algorithmique et à différents niveaux, une force importante de la recherche au LIP est de concilier les aspects fondamentaux et les évolutions technologiques. La plupart des équipes participent à des expériences de calcul haute performance et à la validation et au transfert de leurs résultats par le développement de bibliothèques logicielles, de matériel et de plates-formes élaborées (par exemple, des opérateurs arithmétiques, des compilateurs, des boîtes à outils pour le déploiement d'applications client-serveur sur le réseau, des simulateurs de systèmes complexes, des protocoles de réseau haute performance).

Description du projet :

Dans le cadre de sa collaboration avec différents constructeurs automobile, l'IFTH a développé un outil de détection automatique de défauts (bouloches, déchirures, tâches, ...) sur les textiles utilisés par exemples pour la confection des sièges. Avec l'accélération des cadences de production, un besoin fort d'amélioration des performances de cet outil c'est fait ressentir. C'est dans ce contexte que l'IFTH s'est associé au LIP afin de développer une version parallélisé de cet outil.

---

Aspects techniques :

• Algorithmique parallèle
• Imagerie et segmentation d'image
• Développement en langage C
• API de programmation parallèle MPI
• Cible : cluster 12 processeur (Capitan de Matra Cap-Système), station de travail SUN sparc sous unix Solaris

Réalisations :

Analyse et conception :

• Analyse de l'algorithme séquentiel
• Identification des parties de l'algorithme nécessitant d'être optimisé
• Définition d'une version parallélisé de l'algorithme utilisé.

Développement :

• Mise en oeuvre de l'algorithme parallélisé en C avec utilisation de l'API MPI (programmation parallèle par passage de message)
• Déploiement de l'application sur une machine parallèle de type CAPITAN (12 proc., système linux) de Matra
• Validation de l'amélioration des performances