Système de sécurité maritime

Transcription

RAPPORT DE MISSION EN ENTREPRISE POUR L’OBTENTION DE LA
LICENCE PROFESSIONNELLE
SYSTEMES INFORMATIQUES ET LOGICIELS, OPTION
INFORMATIQUE DISTRIBUEE ET SYSTEMES D'INFORMATION
D’ENTREPRISE
SESSION 2009 - 2010
Systèmes de sécurité maritime
Présenté par Axel BERGER
THALES UNDERWATER SYSTEMS
525 route des Dolines BP 157
06560 Sophia Antipolis
Sous la direction de :
M. Patrice MISTRETTA, responsable entreprise
M. Nhan LE THANH, tuteur IUT
Systèmes de sécurité des biens, des personnes et des installations présents dans une zone maritime sensible
Remerciements
Je commencerai par remercier mon tuteur en entreprise M. Patrice MISTRETTA ainsi que mon tuteur
à l’IUT M. Nhan LE THANH qui m’ont soutenu et aidé durant la totalité de cette année passée en
alternance.
Je souhaite également remercier l’ensemble de l’équipe du projet SECMAR avec laquelle j’ai eu la
chance d’évoluer, pour son accueil, le soutien et les conseils que ses membres m’ont apportés tout
au long de ces douze mois passés avec eux. Ils m’ont permis de m’intégrer facilement et rapidement
chez Thales Underwater Systems ainsi qu’au projet SECMAR, me permettant ainsi d’être à l’aise et de
donner le meilleur de moi-même.
J’espère que le travail que j’ai fourni sera à la hauteur, et que tous garderont, comme moi, un bon
souvenir de mon passage.
Je remercie aussi tout le personnel, enseignant ou non, du département informatique de l’IUT Nice
Côte d’Azur, qui m’a permis, durant cette année d’acquérir le savoir et les compétences nécessaires à
l’obtention de la licence professionnelle SIL IDSE.
Axel BERGER
Page 2
Sommaire
Introduction............................................................................................................................................. 5
Abstract ................................................................................................................................................... 6
1 Présentation de l’entreprise ................................................................................................................. 7
1.1 Le groupe THALES .......................................................................................................................... 7
Historique ........................................................................................................................................ 7
Situation géographique ................................................................................................................... 7
1.2 THALES UNDERWATER SYSTEMS................................................................................................... 8
2 Le projet SECMAR ................................................................................................................................. 9
Présentation .................................................................................................................................... 9
Identification des risques .............................................................................................................. 10
Architecture ................................................................................................................................... 10
Organisation .................................................................................................................................. 11
Planification ................................................................................................................................... 11
3 Environnement de développement ................................................................................................... 12
3.1 Eclipse IDE.................................................................................................................................... 12
Présentation .................................................................................................................................. 12
Utilisation ...................................................................................................................................... 12
3.2 Gestion du code source ............................................................................................................... 13
Subversion ..................................................................................................................................... 13
Subclipse ........................................................................................................................................ 13
4 Réalisation .......................................................................................................................................... 14
4.1 Intégration d’un senseur météo .................................................................................................. 14
MODBUS ........................................................................................................................................ 14
Résumé .......................................................................................................................................... 15
4.2 Création d’un système de distribution de données .................................................................... 16
Problématique ............................................................................................................................... 16
Principe de fonctionnement .......................................................................................................... 16
Mise en œuvre............................................................................................................................... 17
Problèmes rencontrés ................................................................................................................... 21
4.3 Résolution de bug ........................................................................................................................ 21
5 Avancement........................................................................................................................................ 22
Conclusion ............................................................................................................................................. 23
Axel BERGER
Page 3
Glossaire ................................................................................................................................................ 24
Bibliographie.......................................................................................................................................... 26
Axel BERGER
Page 4
Introduction
Ma mission en entreprise, effectuée dans le cadre ma licence professionnelle SIL IDSE en alternance
s’est déroulée chez Thales Underwater Systems (TUS), qui est l’un des leaders mondiaux des
systèmes d’informations critiques sur les marchés de l’aéronautique, de l’espace, de la défense et de
la sécurité. Ce fut pour moi un réel plaisir d’intégrer un établissement de cette envergure et
d’évoluer au sein de l’équipe SECMAR1 (systèmes de sécurité des biens, des personnes et des
installations présents dans une zone maritime sensible).
Le projet étant déjà dans une phase avancée à mon arrivé chez TUS, ma mission principale était au
départ d’identifier les anomalies puis de traiter et déboguer les différents programmes jusqu’alors
développés. Il m’a ensuite été demandé, afin de palier à certains problèmes et également dans un
souci de planning de développer et d’intégrer certains composants du système. Les derniers mois de
ma mission, qui devrait normalement s’étendre jusqu'au mois de décembre, porteront plutôt sur des
aspects systèmes et réseaux puisque je serai en charge de maintenir opérationnelle la plateforme de
référence du système durant sa phase de test.
J’ai choisi d’effectuer mon alternance dans cette entreprise pour différentes raisons : la principale
étant le domaine d’activité de celle-ci car étant relativement curieux, j’ai très vite été séduit par
l’idée d’évoluer dans la section navale d’une multinationale comme Thales. Le fait que le
développement demandé soit en Java m’a également attiré car je connaissais déjà ce langage même
s’il ma fallu me perfectionner pour mener à terme ma mission.
Ce document est organisé de la façon suivante : la première partie présentera mon entreprise
d’accueil, le projet dans lequel j’ai évolué ainsi que les missions qui m’ont été confiées durant cette
année d’apprentissage. La deuxième partie, plus courte, décrira brièvement l’environnement dans
lequel j’ai travaillé (logiciels, langages...). C’est dans la troisième partie que j’exposerai le travail que
j’ai effectué, les problèmes rencontrés ainsi que les solutions que j’ai pu y apporter.
1
Les sigles utilisés tout au long de ce document sont répertoriés et expliqués dans le glossaire. Seront décrit sur
la page courante uniquement ceux dont la compréhension est jugée capitale. Les termes suivis d’un * seront
également classés dans le glossaire.
Axel BERGER
Page 5
Abstract
My mission in business, conducted through my LP SIL IDSE alternately held at Thales Underwater
Systems (TUS), which is a global leader in critical information systems on the aerospace, space,
defense and security. It was a real pleasure for me to integrate a facility of this scale and grow within
the team SECMAR (security systems for goods, people and facilities present in a sensitive maritime
zone).
The project already was in an advanced stage when I came to TUS, my main mission was initially to
identify anomalies and debugging process of the various programs previously developed. Then it was
asked to step to some problems and also for the sake of planning to develop and integrate some
components of the system. The last month of my mission, which should normally be extended until
December, will focus instead on aspects of systems and networks since I'm in charge of maintaining
the operational platform reference system during its testing phase.
I chose to make my internship in that firm for several reasons: the main one being the domain
activity because it is relatively interesting, I was quickly seduced by the idea of change in the naval
section of a multinational like the Thales group. The fact that the development called was in Java also
attracted me because I already knew this language even if I had to improve myself to make it
correctly.
This document is organized as follows: the first part introduces THALES, the project in which I evolved
and the objectives of my internship. The second part briefly describes the technical environment in
which I have worked (software, languages…). In the third part, I detail the work carried out, the
encountered problems as well as the solutions that I proposed.
Axel BERGER
Page 6
1 Présentation de l’entreprise
Le nom de l’entreprise THALES fait référence au mathématicien et philosophe grec de l’école
ionienne, né en 625 et mort en 547 avant Jésus Christ.
1.1 Le groupe THALES
Historique
Les origines de THALES correspondent à la fusion en 1968 de la Compagnie Générale de Télégraphie
sans Fil, pionnier des transmissions hertziennes, créée en 1918, et de Thomson-Brandt, créée en
1893, œuvrant pour la production et le transport de l’électricité. Cette fusion donne ainsi naissance à
Thomson-CSF.
En 1982, suite à une situation financière difficile, la société est nationalisée.
Elle acquiert par la suite, en 1989, les activités d’électronique de défense du groupe Philips et
continuera d’acheter d’autres entreprises afin de se positionner sur le marché international.
En 1996 commence la privatisation de l’entreprise. Peu à peu, elle regroupe les activités
d’électronique spatiale, de défense et de communications militaires d’Alcatel, les activités
d’électronique professionnelle et de défense de Dassault Electronique, ainsi que les activités
satellites d’Aérospatiale.
Thomson-CSF rachète le britannique Racal Electronics en 2000 se propulsant ainsi au rang de
multinationale avant de changer de nom en fin d’année pour devenir THALES.
Depuis, le groupe THALES renforce ses compétences ainsi que son engagement dans les domaines
technologiques et industriels de défense.
Situation géographique
THALES dans le monde
La société est aujourd’hui une multinationale présente sur tous les continents avec une présence
majoritaire en Europe. Cette représentation à l’international permet une proximité avec ses
différents clients et lui permet également d’avoir une forte compétitivité. THALES est actuellement
représenté dans le monde par 335 implantations et plus de 68000 collaborateurs.
THALES en France
La France, siège social de l’entreprise, représente 53% du chiffre d’affaire global de la société.
THALES est à la tête du marché de la défense nationale française. Elle emploie 34300 collaborateurs
sur 70 sites principaux et 7 bassins d’emplois : la Bretagne, l’Ile de France, la région Centre, les Pays
de la Loire, le Sud Ouest, la région Provence-Alpes-Côte-d’Azur et Rhône-Alpes.
Axel BERGER
Page 7
1.2 THALES UNDERWATER SYSTEMS
Thales Underwater Systems est une filiale du groupe Thales. Avec plus de quarante ans d’expérience
en lutte anti-sous-marine, elle s’est imposée comme un leader mondial dans ce domaine. Elle est la
première exportatrice de sonars et de systèmes associés pour les forces navales et aériennes.
Implantée en France, au Royaume Uni et en Australie, elle emploie plus de 2100 personnes dans le
monde et a réalisé un chiffre d’affaire supérieur à 400 millions d’euros en 2005.
Figure 1 : Les différents sites de Thales Underwater Systems
Thales Underwater Systems possède quatre domaines d’activités : la guerre des mines, la lutte antisous-marine, les sous-marins et les services pour la marine.
Thales Underwater Systems conçoit une large gamme de produits pour sous-marins, bâtiments de
surface, navires de lutte contre les mines, avions et hélicoptères. Ce sont par exemple des sonars,
des bouées, des autodirecteurs de torpille, ainsi que tous les services associés (formation,
maintenance, entrainement...).
Figure 2 : Activités de Thales Underwater Systems
Axel BERGER
Page 8
2 Le projet SECMAR
Présentation
SECMAR signifie « systèmes de sécurité des biens, des personnes et des installations présents dans
une zone maritime sensible ».
Ce projet, labellisé en novembre 2007, fédère des moyens de détection sonar, radar et optronique
qui sont étudiés et développés par les industriels et laboratoires de la région PACA, au sein d’une
architecture matérielle et logicielle ouverte, modulaire et générique.
Ces moyens de détection sont connectés au Centre à Terre (CAT) en charge des traitements innovant
de rassemblement et de détection des comportements anormaux.
Le Port Autonome de Marseille (PAM) a été choisi comme site pilote pour une expérimentation
longue durée de six mois.
Figure 3 : Représentation de la zone à protéger
L’image ci-dessus est une représentation de la zone à protéger qui n’est autre que l’ensemble des
quais de déchargement des pétroliers et méthaniers du port de Fos-sur-Mer.
On peut y voir les premières règles de navigation (chenal, zone restreinte) auxquelles viendra
s’ajouter toute la réglementation imposée par le port (zone de mouillage, vitesse...).
C’est ce « code maritime » qui a servit de cadre pour la création des algorithmes de détection des
comportements anormaux.
Axel BERGER
Page 9
Identification des risques
Afin d’établir les procédures de détection, un cabinet d’étude des risques, associé au port de
Marseille a été chargé d’identifier les différents risques encouru sur le site de Fos-sur-Mer.
Figure 4 : Analyse des risques encourus à Fos-sur-Mer
Architecture
A partir de cette étude, une architecture matérielle a été définie afin de pouvoir détecter toute
anomalie et d’y répondre efficacement.
Figure 5 : Architecture du projet SECMAR
Axel BERGER
Page 10
Organisation
Une fois cette architecture arrêtée, différents acteurs des hautes technologies de la région PACA ont
été choisi afin de fournir et de gérer les différents équipements retenus.
Figure 6 : Organisation des partenaires du projet SECMAR
Le schéma ci-dessus présente les acteurs intervenant sur chacun des sous systèmes du projet.
Planification
Un planning a ensuite été définit, dont voici la partie correspondant à mon séjour dans l’entreprise.
2009
Nov.
Déc.
Jan.
Fév.
Mars
Avril
Mai
2010
Juin
Juillet
Aout
Sept.
Oct.
Nov.
Sonar
Acoustique
Electronique
Logiciel
Intégration usine
Installation site
Intégration site
Centre à terre
Logiciel VTS
Logiciel CA
Logiciel SUP/BAM
Electronique
Intégration usine
Installation
Intégration site
Système
Intégration système
Expérimentation
3
1
A
O
U
T
2
0
1
0
Figure 7 : Fragment du planning du projet SECMAR
Axel BERGER
Page 11
3 Environnement de développement
3.1 Eclipse IDE
Présentation
Eclipse IDE est un environnement de développement intégré libre, extensible, universel et
polyvalent, permettant potentiellement de créer des projets de développement mettant en œuvre
n’importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l’aide de la
bibliothèque graphique SWT d’IBM), et ce langage, grâce à des bibliothèques spécifiques, est
également utilisé pour écrire des extensions.
La spécificité d’Eclipse IDE vient de son architecture totalement développée autour de la notion de
plugin (en conformité avec la norme OSGi). Toutes les fonctionnalités supplémentaires développées
dans cet atelier logiciel sont des plugins.
Plusieurs logiciels commerciaux sont basés sur ce logiciel libre, comme par exemple IBM Lotus Notes
8, IBM Symphony ou WebSphere Studio Application Developer.
La base de cet environnement de développement intégré est l’Eclipse Platform, composé de :
-
Platform Runtime démarrant la plateforme et gérant les plugins.
SWT, la bibliothèque graphique de base de l’EDI.
JFace, une bibliothèque graphique de plus haut niveau basée sur SWT.
Eclipse Workbench, la dernière couche graphique permettant de manipuler des
composants, tels que des vues, des éditeurs et des perspectives.
Ces composants de base peuvent être réutilisés pour développer des clients lourds indépendants
d’Eclipse grâce au projet Eclipse RCP.
L’ensemble des outils de développement Java est ensuite ajouté en tant que plugin, regroupés dans
le projet Java Development Tools (JDT).
Utilisation
Bien que très complet, Eclipse reste cependant un logiciel très facile à prendre en main et à utiliser. Il
offre de nombreuses options au programmeur et permet d’automatiser certaines taches comme la
gestion et l’organisation des « import », l’auto-indentation ou la génération de code comme pour les
« getters » et les « setters » par exemple.
La fonction que j’ai le plus apprécié et qui m’a surtout bien rendu service et m’a fait gagner un temps
considérable est le mode « debug » qui permet, sous certaines conditions, de modifier le code durant
son exécution, les modifications étant prise en compte instantanément sans avoir à recompiler ni
même à relancer le programme en cours de modification.
Axel BERGER
Page 12
3.2 Gestion du code source
Le code source du projet étant modifié par plusieurs personnes simultanément, un logiciel de gestion
de version doit être utilisé afin de gérer, contrôler et synchroniser ces modifications.
La solution adoptée par l’équipe de développement est le logiciel Subversion, associé au plugin
Subclipse qui permet sa prise en charge dans Eclipse.
Subversion
Subversion, également appelé SVN, est un système de gestion de versions, distribué sous licence
Apache et BSD. Il a été conçu pour remplacer CVS. Ses auteurs s’appuient volontairement sur les
mêmes concepts (notamment sur le principe du dépôt centralisé et unique) et considèrent que le
modèle de CVS est le bon, et que seule son implémentation est en cause dans l’échec de CVS. Le
projet a été lancé en février 2000 par CollabNet, avec l’embauche par Jim BLANDY de Karl FOGEL, qui
travaillait déjà sur un nouveau gestionnaire de versions.
Subclipse
En ce qui concerne Subclipse, c’est un petit plugin, développé par CollabNet lui aussi, permettant de
contrôler les différentes fonctionnalités de SVN au sein même d’Eclipse.
Synchronisation avec un répertoire.
Soumettre ses modifications au gestionnaire
de version.
Mettre à jour ses fichiers.
Afficher des informations sur les versions.
Ajouter des fichiers au contrôle de versions.
Retirer des fichiers du contrôle de versions.
Figure 8 : SVN sous Eclipse
La figure 2 décrit le menu contextuel de SVN ainsi que les actions possibles sur les fichiers en cours
de développement.
Axel BERGER
Page 13
4 Réalisation
Comme je l’ai expliqué précédemment, une grosse partie de ma mission a consisté a faire du
débogage logiciel mais je ne détaillerai cependant pas cette aspect de mon travail dans ce rapport,
pour la simple raison que cela représente un travail relativement brouillon et décousu de « sens »
(difficile à mettre en forme pour présenter quelque chose de « propre »), j’insisterai plutôt sur
d’autres travaux qui m’ont été confiés comme par exemple la conception et le développement d’un
service de distribution de données (DDS).
4.1 Intégration d’un senseur météo
La première chose qui m’a été demandé de réaliser, afin de me plonger dans le projet et surtout dans
la quantité de lignes de code que j’allais devoir assimiler, fût l’intégration au système d’une station
météo de type girouette-anémomètre.
La première étape que je me suis fixé pour cela a été une période d’investigation, car bien qu’ayant
une bonne connaissance du java, je n’avais encore jamais rien programmé qui ait à interagir avec du
matériel de ce type.
Je me suis donc rendu sur le site du fabricant et j’ai lu et téléchargé à peu près tout ce qui s’y
trouvait. Et parmi tout cela, une « notice », très brève certes, mais dans laquelle figurait un tableau
qui m’a été très utile par la suite. J’ai également appris le renseignement que je cherchais : le
protocole de communication utilisé par l’appareil.
MODBUS
Le langage utilisé par la girouette était donc MODBUS, un protocole de communication utilisé pour
les réseaux d’automates programmables.
Celui-ci fonctionnant sur le mode « master / slave », je décidais de m’orienter sur un développement
client / serveur utilisant des sockets afin de communiquer avec elle.
Il ne me restait donc plus qu’à trouver les détails du protocole afin de pouvoir générer correctement
des trames, et les envoyés a la girouette via mon programme. Et c’est ici qu’intervient le tableau cité
précédemment.
Axel BERGER
Page 14
Figure 9 : Tableau de synthèse des communications avec la girouette
Ce tableau résume donc deux chose, premièrement, la syntaxe des trames à envoyer à la girouette
afin de récupérer les informations météo et deuxièmement, la syntaxe de la trame reçu en réponse.
Résumé
Finalement, la méthode gérant cette station météo peut donc se résumer à cela :
Une tâche chargée d’envoyer une requête à la station afin de récupérer les informations souhaitées.
Celle-ci est exécutée périodiquement grâce à un timer.
socket = new Socket(remote_adrs, remote_port);
byte[] req = new byte[]{0x01, 0x04, 0x00, 0x00, 0x00, 0x0F, 0x85, 0x65} ;
OutputStream out = socket.getOutputStream();
out.write(req, 0, 8);
out.flush();
Exemple d’implémentation de l’envoi d’une requête à la girouette
Une méthode chargée de récupérer les données météo et de les remonter dans le reste du
programme.
byte[] meteo = new byte[33];
InputStream in = socket.getInputStream();
in.read(meteo);
remonterMeteo(new MeteoMsg(meteo));
Exemple de récupération des données météo
Remarque : les deux exemples ci-dessus ne représentent en rien le code réel de l’application qui est
lui relativement plus long et complexe. Ceux-ci sont uniquement destinés à expliciter la logique
utilisée.
Axel BERGER
Page 15
4.2 Création d’un système de distribution de données
Un DDS (Data Distribution Service) est de type middleware, il favorise les interactions entre des
applications à travers un réseau. Les applications disposent d’API leur assurant l’utilisation des
services offerts. Il est basé sur un mécanisme de publication et souscription.
Il m’a été demandé durant ma présence dans l’équipe SECMAR de créer un tel soft afin de remplacer
une solution tiers jusqu’alors utilisé mais devenu beaucoup trop instable et contraignante.
Problématique
La raison d’être d’un DDS est de permettre à n machines,
situées sur un même réseau, de communiquer entre
elles, sous forme d’échanges de données.
Ce type de middleware étant souvent destiné à
l’industrie, il doit prendre en compte de fortes
contraintes de performance et de fiabilité.
Principe de fonctionnement
Un service de distribution de données, fonctionne autour d’un schéma basé sur trois entités
principales :
-
Les domaines, représentés en orange sur la figure 10, peuvent être assimilés à des
canaux de discutions, auxquels vont venir se joindre des participant.
Les participants (encadrés sur la figure 10) sont en fait les machines (ou programmes) qui
souhaitent échanger des données sur le réseau.
Les topics, en pointillé sur la figure 10, sont une description basique des types de
données échangées sur les domaines. Ils facilitent la publication et souscription des
participants aux données souhaitées.
Figure 10 : Principe de fonctionnement d'un DDS
Axel BERGER
Page 16
L’exemple suivant représente une application possible d’un système de DDS au cas de l’IUT Nice Côte
d’Azur.
Figure 11 : Exemple d'utilisation de DDS
Dans celui-ci, trois domaines serait utilisés, pour les notes, les emplois du temps, et les réunions de
l’IUT. Dans le cas du domaine « Notes », chaque participant souhaitant publier / souscrire à des
données doit rejoindre le domaine ; c’est le cas des professeurs, pour le rendu des notes, et du
secrétariat, pour la communication aux étudiants. Une fois le domaine rejoint, le participant
s’abonne à un topic, c'est-à-dire, un sujet qui le concerne (dans notre exemple ce sera des matières
enseignées) ; celui-ci peut maintenant partager et recevoir des données, concernant le topic qu’il
souhaite, sur le domaine joint2.
Mise en œuvre
Concept
Afin de réaliser cet outil, j’ai eu recours à différents concepts essentiels au bon fonctionnement de
l’application :
Premièrement, le multithreading : le multithreading est un mode de programmation qui consiste à
répartir l’exécution de tâches en parallèle (de manière simultanée). Dans notre cas, impossible de
s’en passer. On ne peut effectivement pas imaginer que l’envoi de données ou l’exécution de
traitement soit bloquant (donc plus de réception) pour le reste du programme.
La diffusion multicast : le terme multicast (ou multidiffusion) est utilisé pour désigner une méthode
de diffusion efficace de l’information d’un émetteur vers un groupe de récepteur. L’avantage qui
nous intéresse pour un système de DDS est que dans le cas de nombreux abonnées, l’information
2
Le nombre de domaines / topics n’est évidement pas limité. Chaque participant peut suivre autant de topics
qu’il le souhaite sur autant de domaines voulus.
Axel BERGER
Page 17
n’est envoyée qu’une seul et unique fois, vers l’ensemble des participants, libre à eux ensuite de la
réceptionner ou pas.
Le troisième point essentiel est la notion de synchronisation. Celle-ci consiste à conserver la
cohérence des données dans un environnement multitâches. En effet, les données étant manipulée
par plusieurs entités, il nécessaire de contrôler leurs accès afin d’éviter toutes pertes.
Schéma de fonctionnement
Le système de DDS et donc la mise en œuvre de ces principes est effectuée par trois entités
principales.
Figure 12 : Fonctionnement du DDS
La première est appelée « Manager », c’est elle qui va gérer les domaines, au sens réseau. C'est-àdire qu’elle va contrôler les accès des différents participant aux domaines, leurs communiquer les
informations (adresse ip, port...) afin de les utiliser.
Axel BERGER
Page 18
Voici, pour exemple, la méthode subscribe, appelée par un participant souhaitant joindre un
domaine.
public AxlSniffer subscribe(String pPartition) {
AxlSniffer sniffer;
String[] cnx;
sniffer = mSniffer.get(pPartition);
if (sniffer == null) {
if (!mPartitions.containsKey(pPartition)) {
sniffer = null;
} else {
cnx = mPartitions.get(pPartition).getChannel().split(":");
sniffer = new AxlSniffer(new AxlPartition(pPartition, cnx[0],
Integer.parseInt(cnx[1])));
mSniffer.put(pPartition, sniffer);
sniffer.start();
}
}
return sniffer;
}
Méthode subscribe de la classe Manager
Son rôle est tribal, elle se contente de récupérer les informations de connexion au canal lié à une
partition (à condition qu’elle existe), puis elle renvoi un objet de la classe « Sniffer » lié à la partition.
La seconde gère quant à elle l’écoute de l’activité sur les différent domaines (elle veille si des données
circulent), auquel cas, elle va filtrer les topics selon les choix du participant, afin que celui-ci ne
récupère pas toutes les informations ne l’intéressant pas.
C’est également elle qui va permettre la publication de données dur le réseau au travers d’une
méthode « broadcast ».
Dans le cadre du multithreading, la méthode d’écoute, qui doit fonctionner en permanence, est donc
effectuée parallèlement aux autres. Le mécanisme java utilisé est l’implémentation de l’interface
Runnable qui contrairement à l’autre solution fournit pas java, la classe Thread, permet de résoudre
le problème de l’héritage multiple.
@Override
public void run() {
mRunner.start();
while (true) {
try {
byte[] buff = new byte[AxlParameters.MESSAGE_MAX_SIZE];
DatagramPacket packet = new DatagramPacket(buff, buff.length);
mSocket.receive(packet);
space_free(packet.getLength());
ByteArrayInputStream bis = new ByteArrayInputStream(packet.getData());
ObjectInputStream ois = new ObjectInputStream(bis);
AxlMessageHeader header = (AxlMessageHeader) ois.readObject();
synchronized (checker) {
Axel BERGER
Page 19
checker.checkpacket(header);
}
Tracer.trace(this, “recu “ + header + “ | “ + packet.getLength() + “ octets”);
String topic = header.mTopic;
if (mRunner.getTopicListener().containsKey(topic)) {
Object data = ois.readObject();
AxlAMessage message = new AxlAMessage(header, data);
mRunner.offer(message);
}
} catch (IOException e) {Tracer.exception(this, e);
} catch (ClassNotFoundException e) {Tracer.exception(this, e);}
}
}
Méthode run de la classe Sniffer
La troisième entité s’appelle le Runner, son rôle est de vérifier en permanence l’arrivée de messages
et de déclarer au besoin les actions associées. Afin de ne pas être bloquant pour le reste de
l’application, il est lui aussi exécuté en parallèle aux autres.
Une file d’attente (FIFO)3 est utilisé afin de ne pas déclencher trop de traitement simultanément. Les
messages entrant sont ainsi stockés dans la FIFO et utilisés chacun leur tour.
@Override
public void run() {
AxlAMessage msg;
while (true) {
try {
msg = take();
AxlMessageHeader header = msg.getHeader();
String topic = header.mTopic;
if (mTopicListener.containsKey(topic)) {
Integer code = header.mCode;
switch (code) {
case AxlMessageHeader.MESSAGE :
for (AxlMessageListener l : mTopicListener.get(topic))
l.onReceive(msg);
break;
case AxlMessageHeader.REFILL :
l.onRefill();
break;
case AxlMessageHeader.CLEAR :
l.onClear();
break;
}
3
La classe utilisée est LinkedBlockingQueue, c’est une file dite bloquante, au sens ou si un élément est
demandé mais que la file est vide, la demande sera mise en attente, et l’élément fournit dès son arrivé dans la
FIFO.
Axel BERGER
Page 20
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Méthode run de la classe Runner
Problèmes rencontrés
Le développement de ce système de distribution de données m’a posé plusieurs problèmes.
Premièrement le multithreading, car en effet la programmation répartie n’est pas chose facile, et
notamment lorsqu’il s’agit de débugger d’éventuels problèmes ou comportement anormaux. La
recherche de « bonnes pratiques » sur le web ainsi que d’exemples m’a été d’une grande aide et m’a
probablement évité de nombreuses heures d’impasses.
La synchronisation a également été au cœur de mes soucis car l’intégrité des données ainsi que leur
cohérence sont essentiels dans ce type d’application.
Les autres éléments qui m’ont pris également du temps sont des exigences liés aux performances et
à la fiabilité du système, ainsi que des limitations matérielles impactant la quantité de données
pouvant être transmises dans un message.
4.3 Débogage
Outre la résolution de bug « normaux » liés à la programmation elle-même, j’ai également eu à
travailler sur des problèmes matériels. L’un d’entre eux concernait le module GPS du système ; En
effet, il arrivait que celui fournisse de temps en temps et pour une raison totalement inconnue une
trame erronée, entrainant une mise à jour aberrante des dates systèmes.
La solution mise en place afin de contourner ce problème a été de baser cette mise a jour sur deux
trames consécutives du GPS, effectuant donc la mise à jour si celles-ci étaient cohérentes entre-elles.
private long delta_last = 0;
private void checkGpsDate(byte[] bmsg, int size) {
long date_pc = System.currentTimeMillis();
long date_gps = parseGpsMessage(bmsg, size);
long delta_current = date_pc - date_gps;
if(delta_last == 0) delta_last = delta_current;
else {
if ((date_pc - lastGPSTimeUpdate) > (1000 * 3600))
if (Math.abs(delta_last - delta_current) < 2000) {
mettreAJourDateSnode(date_gps);
lastGPSTimeUpdate = date_pc;
}
}
}
Mise à jour de la fonction de vérification de l’heure GPS
Axel BERGER
Page 21
5 Avancement
A l’heure actuelle, une grande majorité des bugs identifiés sur la partie TUS du projet est corrigé et le
software développé fonctionne correctement.
Le système de distribution de données que j’ai développé a été retravaillé puis intégré au projet ; Il
remplace actuellement l’ancienne solution de DDS.
Au 31 aout 2010, le système devrai normalement être installé son site d’expérimentation et intégré
avec les composants livrés par les autres acteurs du projet, conformément au planning définit et
présenté dans la partie 2 de ce rapport.
La phase d’expérimentation devrai normalement durer jusqu'à décembre 2010, date à laquelle
prendra également fin ma mission chez TUS. Cette phase sera également l’occasion de
démonstration « publique » réservées à la presse spécialisée, notamment dans le cadre du salon
Euronaval.
Axel BERGER
Page 22
Conclusion
Cette année passée en licence professionnelle, la première pour moi en alternance, a été une
expérience très enrichissante, non seulement sur le plan professionnel mais également sur le plan
personnel puisque le fait d’évoluer dans un milieu relativement « expérimental » a modifié mon
point de vue sur la recherche et m’a aussi donné d’avantage confiance en moi.
J’ai pu acquérir durant cette année passée chez Thales Underwater Systems une expérience concrète
du métier de développeur et plus généralement, du monde du travail et de la vie en entreprise.
Cette expérience sur le projet SECMAR m’a également permis de réellement m’apercevoir de l’utilité
du travail en équipe et j’ai pu mettre en évidence tant mes connaissances informatiques que
relationnelles afin de répondre à de nombreux problèmes.
Bien que mon année universitaire se termine ici, le projet SECMAR continu pour moi étant donné que
mon contrat se prolonge encore pendant quelques mois. Ce sera pour moi l’occasion de participer à
la phase d’expérimentation du système, qui est en quelques sortes un premier aboutissement, et qui
nous apportera à tous j’en sûr, une grande satisfaction.
Axel BERGER
Page 23
Glossaire
AIS : Automatic Identification System
API : Application Programming Interface
AUV : Autonomous Underwater Vehicle
BSD : Berkeley Software Distribution
CAT : Centre A Terre
CSF : Compagnie Générale de Télégraphie sans Fil
CVS : Concurrent Versions System
DDS : Data Distribution Service
DOP : Détection OPtronique
DRA : Détection RAdar
DSF : Détection Sous-marine Fixe
EDI / IDE : Un IDE (Environnement de Développement Intégré / Integrated Development Environment)
est un programme regroupant un ensemble d’outils pour le développement de logiciels.
FIFO : First In First Out (premier entré premier sorti)
GPS : Global Positioning System
IBM : International Business Machines Corporation
IDSE : Informatique Distribuée et Systèmes d'information d’Entreprise
IUT : Institut Universitaire de Technologie
ISD : Intervention Support Device
JDT : Java Development Tools
OSGi : Open Services Gateway Initiative
PACA : Provence-Alpes-Côte-D’azur
PAM : Port Autonome de Marseille
SECMAR : Systèmes de sécurité des biens, des personnes et des installations présents dans une zone
maritime sensible.
SIL : Systèmes Informatiques et Logiciels
SNODE : Sensors NODE
Axel BERGER
Page 24
SVN : Diminutif de Subversion
SWT : Standard Widget Toolkit
TUS : Thales Underwater Systems
Axel BERGER
Page 25
Bibliographie
Sites web
THALES
Thales group : http://www.thalesgroup.com
Thales Underwater Systems : http://www.thalesgroup.com/naval/
Pole mer PACA
SECMAR : http://www.polemerpaca.com/fr/domaines-d-activite/securite-et-suretemaritimes/secmar-44.html
Wikipedia
Eclipse : http://fr.wikipedia.org/wiki/Eclipse_(logiciel)
Subversion : http://fr.wikipedia.org/wiki/Subversion_(logiciel)
Axel BERGER
Page 26

Système de sécurité maritime

Transcription

Documents pareils

Pôle de compétitivité OPTITEC Liste des membres du Conseil

Jean BULOT Né en 1939 sur l`Ile d`Arz dans le golfe du Morbihan et

Schéma de synthèse

passeport passeport

Télécharger les présentations

BILLETERIE OK CORRAL 2016 DU 26 MARS AU 6 NOVEMBRE 2016

classement

avenant de prorogation de làccord dèntreprise relatif a lèmploi des

TOILETTAGE - Pattes et griffes

Etat de l`art des BGA plastique - CCT

Thales SESO S.A.S S.A.S. au Capital de 449 024 € SIRET : 399 064

La société du mépris

rapport - Human Rights Watch