Description Architecturale du systme

Le Consortium INDECT

AGH Universit des Sciences et Technologies, Cracovie, Pologne

Universit Technologique de Gdansk, GUT, Pologne

InnoTec DATA GmbH & Co. KG, INNOTEC, Allemagne

IP Grenoble (Ensimag), INP, France

MSWiA Quartier gnral de police (Police Polonaise), GHP, Pologne

Moviquity, MOVIQUITY, Espagne

Technologie de production et systme dinformation, PSI, Allemagne

Service de police dIreland du Nord, PSNI, Royaume-Uni

Universit Technologique de Poznan, PUT, Pologne

Universit Carlos III de Madrid, UC3M, Espagne

Universit technique de Sofia, TU-SOFIA, Bulgarie

Universit de Wuppertal, BUW, Allemagne

Universit de York, UoY, Grande - Bretagne

Universit Technique dOstrava, VSB, Rpublique Tchque

Universit Technique de Kosice, TUKE, Slovaquie

X-Art Pro Division G.m.b.H., X-art, Autriche

Universit Technique de Vienne, FHTW, Autriche

INFORMATIONS CONCERNANT LE DOCUMENT

Numro de contrat 218086

Nom de publication

Description Architecturale du systme

Numro de publication

2.2

Editeur(s)

Grzegorz Sobanski, PUT

Auteur(s)

Grzegorz Sobanski, PUT Pawe Lubarski, PUT Mikoaj Sobczak, PUT

Chargs de rvision

Plamen Vichev, Universit Technique de Sofia Zulema Rosborough, Services de Police dIreland du Nord Nikolai Stoianov, Universit Technique de Sofia

Niveau de dissmination

publique

Date contractuelle de publication

31/10/2010

Date de publication

31/10/2010

Statut de publication

final

Mots-cls

Architecture, intgration, modle du systme, communication, nuds

Contenu
Informations du document Sommaire excutif Introduction Structure logique Vue densemble du systme Types de nuds

Sous-systme de communication Ide Gnrale Connecter les segments sans IP Communication entre les modules

Modle de communication Echantillon des cas de communication Tracer un objet mobile Demande dinformation concernant les appareils tracs Scurit

Environnement de programmation Nuds capteurs (F2) Nuds de traitement (F3, F4) Application pour les utilisateurs finaux (F5, F6)

Nuds Physiques UAV (drones) Composants Aronefs propulsion Systmes embarqus Cardan stabilis Capteurs usage gnral Systme de puissance Sous-systme de communication des UAV Segment terrestre de lUVA Salle de commande Commande distance des nuds Serveur responsable des oprations de tous les nuds Traceurs GSM-GPS Traceurs mobiles Capteurs multifonction

Interfaces et protocoles de communication Communication entre lUAV et le serveur WP2 Flux vido de lUAV UAV et tlmtrie des charges utiles UAV et planification des missions Communication entre les capteurs multifonction et les serveurs Communication entre les traceurs mobiles et les capteurs multi-usages Communication entre les traceurs GSM-GPS et le serveur WP2 Communication entre le serveur WP2 et le portail WP6

Intgration Scnarios Oprations de surveillance UAV Oprations Hors ligne UAV Planification de missions UAV Reconnaissance de plaques dimmatriculation Tracer par GPS-GSM Types de donnes Position Temps Vitesse Point de passage UAV Mission de lUAV Objet trac Donnes des vhicules Donnes fournies Flux vido Description des objets Evnements

Travaux Futurs Conclusion

Sommaire Excutif
Dans ce document nous dcrivons une structure logique et une architecture du systme

dvelopp. Lobjectif du systme est de supporter les activits des officiers de police et dautres services publics. Son but est de raliser lintgration de nombreux moyens qui peuvent surveiller les objets mobiles. Des moyens existants et un qui sera dvelopp par la suite seront utiliss ces fins. Physiquement, le systme est divis en nuds qui communiquent entre eux. Nous avons catgoris ces nuds de faon logique pour une meilleure orientation. Chaque nud peut raliser une ou plusieurs fonctions de la liste suivante : fournir une communication, rassembler des donnes, effectuer des oprations sur les donnes, prsenter les donnes aux utilisateurs. Dans la Section 1, nous donnons une description dtaille des fonctions et des relations existante entre ces fonctions. Le deuxime point important est le rseau qui cre une connexion entre les nuds. Nous pouvons tablir une distinction entre trois types de connexion. Premirement, un rseau de cble bande passante large et temps de latence court, utilis comme rseau pivot afin de connecter des lieux distants et de fournir un moyen de communication distance. De plus, un lien sans fil large bande passante, longue distance peut tre utilis pour tendre le rseau pivot aux lieux distants, ou un rseau cbl nest pas disponible. Enfin, un rseau sans fil courte distance sera utilis pour connecter les nuds mobiles. Vous pouvez trouver une description plus dtaille et une technologie suggre dans la Section 2. La Section 3 fourni un modle de communication selon lequel est construit le reste du systme. Selon les scnarios, deux modles peuvent tre utiliss. Premirement, un flux TCP qui est largement utilis sur Internet. Il est ralis pour appuyer la communication entre deux nuds qui peuvent ainsi avoir un rseau de connexion durant la dure ncessaire de la communication. Ce systme est souvent utilis pour les grandes quantits de donnes comme une vido en temps rel ou des images prises de camras. Le second modle est bas sur le message. Quand un nud veut communiquer avec un autre, celuici prpare un message qui contient lui-mme un paquet de donnes que dautres nuds peuvent comprendre et sur lesquels ils peuvent agir en termes de communication. Ce message peut ensuite tre propag sur le rseau dans une base de donnes ou sous dautres formes. Cela permet la communication avec un point distant qui ne se connecte quoccasionnellement sur le rseau. Un message peut tre stock sur un point daccs avant dtre transfrer un nud mobile via le rseau sans fil. De la mme faon, un message dun nud mobile peut tre transfrer sur le rseau permanent ou vers dautre nuds mobiles. Un tel message peut tre transfrer longtemps aprs que le nud originel ait clos sa connexion au point daccs. Afin de dvelopper des modules de faon fiable et cohrente, les pr-requis et recommandations pour lenvironnement de programmation sont regroup dans la Section 4. Les nuds de processus (serveurs) sont requis afin de supporter en mme temps les environnements Microsoft Windows et Linux. Lusage final des applications doit supporter lenvironnement Microsoft Windows. Les plateformes C# et .NET sont recommandes. La Section 5 spcifie les plus hauts niveaux de pr-requis pour tous les nuds du systme. Les nuds suivant ont t prsents : UAV, UAV segment terrestre, salle de commande, commande mobile, serveurs et de nombreux capteurs.

UAV est un systme autonome qui peut accepter des missions et les raliser sans de plus ample supervision. Il peut lui-mme tre divis en diffrents sous-modules dvelopps en coopration. En partant de la cellule, cela doit supporter tout le poids et la puissance requise, des ordinateurs connects aux capteurs et systme de communication. UAV segment terrestre est directement en interaction avec lUAV, permettant lutilisateur de contrler lUAV. La salle de commande et la commande mobile sont des points dentre pour lutilisateur qui permettent de maintenir et de profiter des avantages du systme. Il contient un mur daffichage qui prsente une vue gnrale de la situation afin de commander des officiers et dautres personnes sous-contrle. Les consoles des oprateurs permettent dentre des donnes dinformation dans le systme, contrler tous les nuds et de leur envoyer des commandes. Il est aussi possible denregistrer des requtes pour contrler ce qui saffiche sur le mur daffichage. Les nuds serveurs sont responsables de stocker les donnes collectes dans le systme et de permettre leur consultation hors ligne dans le futur. Les nuds serveurs assistent aussi les requtes en cours entre depuis les salles de commande. La liste des capteurs inclut un systme de reprage mobile dappareils et des capteurs multi-usage. Ce reprage peut tre ralis en se basant sur diffrents systmes de localisation. La premire solution et dutiliser un rcepteur GPS pour acqurir la position actuelle et de la transfrer via un systme de communication sans fil. Pour cette communication, un rseau GPRS ou un systme pour les courtes distances peut tre utilis. La deuxime solution est dutiliser un systme sans fil courte distance quadrill pour la localisation et la communication avec le systme. Un capteur multi-usage peut tre quip avec plus dappareils afin dobtenir un plus large spectre de donnes. On peut prendre comme exemple des camras pour dtecter les objets dintrt et fournir une vido en temps rel, des capteurs de temprature, des capteurs biochimiques pour dtecter des contaminations, et bien dautres possibilits. La Section 7 dcrit un dtail technique des donnes qui peuvent tre acceptes comme entres des nuds ou disponibles comme sorties. La conclusion du document est apporte Section 8 avec un sommaire du travail futur qui sera ralis sur le point T2.1.

Introduction

Le point T2.1 dans le paquet de travail WP2 concerne la vue densemble trs importante de systme tant dvelopp dans ce paquet. Le but principal du WP2 est de fournir aux officiers de police un systme prototype pour collecter, traiter et afficher des informations concernant lobservation de divers objets mobiles. Afin de remplir entirement cet objectif, trois modules interconnects doivent tre construits. Premirement, un systme multimodal pour le positionnement et le reprage dobjets ayant la capacit de se mouvoir est requis. Des appareils spciaux et des algorithmes de gestion spatiale sont requis pour dtecter avec prcision des objets. Le second est un drone de patrouille arienne autonome utilis comme plateforme dobservation. Enfin, le dernier lment est une infrastructure de rseaux sans fil utile afin de raliser les deux buts principaux du projet. Tout cela, interconnect, forme un systme intgr centr sur un rseau. Ce systme qui constitue une des sous-systmes noyau du projet INDECT reprsente les yeux et oreilles du projet entier. Il appuie dautres paquets de travail avec diffrentes donnes pouvant tre utilises plus en dtail. Cest pour cela que le sous-systme WP2 est en parfaite adquation avec lide de Systme intelligent dinformation, appuyant lobservation, la recherche et la dtection pour la scurit des citoyens en milieu urbain .

Structure Logique

Vue densemble du systme

Lobjectif du systme est de supporter les actions des officiers de police et dautres services publiques grce des techniques et outils dobservation de nombreux objets mobiles. Ce but est ralis en intgrant un large spectre dappareils dj utiliss et de nouveaux appareils raliss qui peuvent surveiller les objets mobiles en crant un systme htrogne centr sur le rseau reli de nombreux nuds.

Schma 1 : vue densemble du systme Le systme INDECT consistera en de nombreux modules qui peuvent raliser de nombreuses fonctions. A cause de cela, pour la ralisation effective les prsents objectifs, le systme est dvelopp comme un systme partitionn sensible aux vnements extrieurs. Chaque nud du systme peut tre vu comme un composant indpendant effectuant ses fonctions et communicant avec les autres nuds propos des vnements passs. Cette approche assurera que le systme soit modulaire, ouvert et volutif. Ainsi, de plus ample dveloppements du systme et lajout de nouveaux nuds peut tre ralis trs facilement. Cela assure que le systme soit robuste et cela amliore le partage des

informations. Le partage dinformations renforce ses qualits et aide btir des situations pour les officiers de police. Par le partage des situations avec dautres utilisateurs finaux, Ils pourront collaborer plus facilement et cela aura pour impact damlior lefficacit de leur travail.

Types de nuds
Du point de vue de linfrastructure, les nuds dans le systme peuvent tre diviss en groupes, et cela selon leur fonctions : F1 nuds qui assure la capacit de communication du systme (routeurs). F2 nuds qui collectent des informations grce leurs capteurs. F3 nuds qui traitent les informations, inclus : dtection des vnements, dtection de liens entre les vnements, etc. F4 nuds rpondant aux requtes et tches des utilisateurs, collectes sous demande les informations dautres nuds, prparent les donnes pour leur affichage, etc. F5 nuds affichant des donnes aux utilisateurs (clients passifs). F6 nuds permettant lutilisateur dinterroger le systme pour des informations spcifiques. Bien sur, chaque nud du systme peut effectuer plusieurs fonctions en mme temps. Par exemple, un nud peut collecter des informations et en mme temps les (pr)traiter, rechercher des vnements Certaines fonctions seront combines plus souvent que dautres. Les combinaisons les plus communes sont : -collecter et traiter des donnes (F2, F3). -traiter des donnes et des tches envoyes par lutilisateur (F3, F4). Ces nuds peuvent tre vus comme des serveurs dans une conception typique de serveur-client. -afficher les vnements et points dentre pour les utilisateurs (F5, F6). Ces nuds peuvent tre vus comme des clients dans une conception typique de server-client. Chaque nud ncessite une voie pour communiquer avec les autres nuds. Donc, logiquement, on pourrait dire que chaque nud peut agir comme un F1. A un niveau plus lev, on peut distinguer les nuds suivants : -Nuds de communication qui compose le rseau maill et linfrastructure de communication -Dtecteurs : -camras -dtecteurs sans fil de surveillance -autres -serveurs, qui collectent les donnes depuis les dtecteurs et le partagent avec les clients

(utilisateurs) -applications utilisateurs qui agissent comme des points dentre du systme.

Figure 2 : Structure de coopration entre les nuds La Figure 2 montre un flux gnral de donnes entre diffrents types de nuds. Il est important de se souvenir que plusieurs fonctions logiques peuvent tre ralises par un nud physique.

Sous-systme de communication

Ide Gnrale
Crer un systme distribu a soulign la partie rseau du systme qui est le noyau de nimporte quel systme centr sur un rseau. Il est crucial pour un travail efficace que chaque nud du systme puisse communiquer avec les autres.

Figure 3 : rseau La Figure 3 prsente une vue gnrale de la disposition du rseau. Il est vident que ce rseau doit tre htrogne pour tre capable de connecter diffrents nuds qui sont disperss dans diffrentes zones et avec diffrentes capacits de communication. On peut diviser les connections disponibles en plusieurs groupes : -Un pivot rapide et puissant un rseau filaire large bande passante (10Mbps+, ventuellement 10Gbps entre les nuds les plus importants), voire les deux, ou utiliser des rseaux existant tels quInternet qui possdent dj des systmes de scurit. -un pivot sans fil une connexion longue porte large bande passante point par point aux stations distantes (potentiellement utiliser la technologie WiMAX). -Un lien local sans fil montre les distances, petite ou large bande passante entre les nuds proches. Le but de la connexion au pivot est de construire un rseau stable qui connecte tous les nuds statiques en un mme systme. Ces nuds peuvent alors agir comme des points de distribution pour les nuds utilisant des connexions sans fil locales. Parce que le cot de construction et dexploitation des connexions du pivot peut tre lev, il est naturel de placer de tels nuds dans une zone et dutiliser des connexions sans fil moins cher pour relier les nuds proches au rseau. En se basant sur la connexion, on peut diviser les nuds en quatre classes :

-nuds pivots qui composent le rseau pivot (permettant seulement F1). -nuds connects directement au pivot. Ils sont toujours (checs inclus) connects au rseau. -nuds statiques connects grce un lien local aux nuds pivots ou dautres nuds statiques. Ils creront un rseau maill qui peut couvrir une vaste zone avec seulement une simple connexion sans fil. -nuds mobiles qui se connectent avec un lien local aux autres nuds. Ces nuds peuvent tre diviss en deux groupes : -les nuds qui peuvent tre connects au rseau sur une longue priode. -les nuds qui initialise une courte connexion pour envoyer des donnes mais qui restent dconnects le reste du temps. En tte de ces connexions physiques, un rseau IP sera dvelopp. Cela permettra lutilisation de standards et dalgorithmes et protocoles connus. Chaque nud peut ds lors tre associ une unique adresse IP et tous les nuds peuvent alors initialiser une connexion TCP ou UDP vers des nuds ayant un accs avec une IP.

Connecter les segments sans IP

Malheureusement, tous les nuds ne peuvent pas supporter lIP. Il y en aura donc incapable de supporter les connexions IP, en particulier ceux qui restent dconnects et qui se connectent au rseau pour envoyer ou recevoir de courtes salves de donnes. Pour de tels nuds, des points daccs (AP) doivent tre dvelopps pour permettre le transfert de donnes depuis et vers eux. Dans de tels cas, le nud qui agira comme un point daccs possdera une adresse IP et sera disponible pour dautres nuds dans le rseau. Si un nud veut envoyer des donnes des nuds dconnects, il devra contacter lAP et lui laisser le message qui sera transfr ds que possible. Il pourrait exister plusieurs AP pour les mmes modules dconnects. Dans un tel cas, ils doivent se synchroniser avec leurs messages en attente, de sorte que ce ne soit pas applicable pour chaque AP connect ce nud. Il doit toujours obtenir les messages en attente. On peut donner comme exemples des tels liens : -communications radios manuelles courtes et longues distances. -communication Bluetooth locale. -communication SMS dans le rseau cellulaire. De telles connections seront surement utilises dans le systme INDECT.

Communication entre les modules

La Communication entre les modules dans le Work Package 2sous systme sera assure selon le modle reprsent dans la figure 4. Les serveurs sont le cur du systme rseau centr et sont connects au rseau pivot de communication-fibre, cbles, connexion sans fil ou lensemble des moyens de communication runis. Les serveurs peuvent communiquer entre eux ou avec les autres nuds du systme directement ou indirectement dans le but de collecter tout les informations requises pour tre sauvegarder dans la base de donnes. Cest le seule partie du systme ayant accs la base de donnes. Par exemple les modules traceurs GSM/GPS communiquent avec les serveurs directement pour le rseau GSM et les UAV (drones) communiquent via un rseau UAV terrestre et des capteurs multifonction. Les serveurs interprtent aussi les requtes envoyes depuis la salle de commande, tant que cest une application du WP2, du portail INDECT ou tout autre application autorises. Ces requtes sont alors prsentes aux utilisateurs. Parce que le systme est centr sur un rseau, les information nest pas obliger de passer par les serveurs ou la base de donnes. Les UAV peuvent demander des capteurs multifonctions quelles sont les conditions mto dans une certaines zones, comme la vitesse du vent, pour ajuster leur vitesse et leur vitesse de vol. Le traceur mobile peut tre dploy sous une voiture suspecte, fournissant ainsi aux UAV des informations sur la position du vhicule. Cette information sera aussi directement envoye la salle de contrle. Les officiers de police pourront alors demander une vido en direct du vhicule via les UAV. Cette vido pourrait tre envoye via le segment terrestre du rseau UAV ou sil est hors de porte, par le capteur multifonction le plus proche vers le serveur et la salle de commande. Cest lide du systme centr sur un rseau o tous les composants sont intgrs. Cette approche sera utilise dans le systme WP2.

Figure 4 : communication entre les modules dans le systme WP2

Modle de Communication
La communication entre les nuds peuvent gnralement peut gnralement tre ralises sur la base de deux modles : lun quon peut appeler flux constant , lautre quon peut appeler gr par messages . Dans le modle flux constant , les nuds ouvrent des connections (cad. TCP) entre eux et change de long flux de donnes. Ce type de systme est commun sur Internet. Les clients ouvrent une connexion sur le serveur et changent un flux double sens de donnes. Cela fonctionne bien quand le rseau est stable, et que la connexion peut rester ouverte pendant le temps que ncessite lopration et que les serveurs transmettent le message. Plus le temps le serveur require de temps pour prparer sa rponse, plus le rseau est instable, et plus de problmes sont prvoir dans le modle. Le plus souvent, quand la connexion est interrompue, lensemble de la procdure doit tre relanc, incluant la collecte des donnes par le serveur. Dans un modle gr par messages , lensemble des communications entre les nuds est effectue par messages. Les nuds peuvent senvoyer des flux de donnes mais par messages. Chaque requte client, rponse du serveur, etc. est envoy sous forme de message (un peu comme un email ou une lettre). Avec un tel modle, les oprations prcdentes peuvent tre vues de cette faon : -le client prpare un message dcrivant sa requte. -le message est envoy au serveur. -le serveur reoit le message, le traite, et prpare une rponse sous forme dun autre message. -le serveur envoie la rponse au client. -le client lit le message de rponse sa requte. Il est important de noter que cet ensemble dopration est asynchrone. Le transfert de message peut traverser plusieurs connexions entre ces deux nuds, si les listes dattente denvoie de message peuvent rsister au dconnections temporaires, indisponibilits de certains nuds etc. De plus, les messages nont pas tre transmis directement aux nuds concerns. Ils peuvent tre mis en attente, et suivis par des nuds intermdiaires. Ce modle est trs utile dans des systmes distribus, o les nuds peuvent tre dconnects pendant de longue priodes ou disponible par des rseaux trs htrognes. Quand on prend en compte les nuds qui se connectent au rseau pour de courts transferts de donnes, on remarque les faiblesses du modle flux constant pour de telles oprations. Dans le cas dun systme gr par message, les points daccs peuvent mettre en files dattente les messages pour tre envoys des nuds actuellement dconnects, et les envoie donc quand celui-ci est connect. Cela est vrai aussi pour les messages envoy par les nuds : ils peuvent tre mis en files dattente par les points daccs et envoy longtemps aprs la dconnexion du nud. Dans un systme gr par message on

dfini : Routeur de messages : un lieu abstrait, point central des changes de messages. Les crateurs de messages les place dans un routeur. Cest le composant responsable des envoie de messages aux diffrents destinataires. Un routeur est responsable du traitement des messages et den scuriser laccs. Il peut optionnellement garder en mmoires des messages pour quils ne soient pas perdus. Abonnement : Les nuds intresss par la rception dinformations spcifique peuvent envoyer une requte au routeur pour les obtenir. Par exemple, le serveur peut demander toute les informations concernant la position des appareils tracs. Lorsquun nud traceur placera un message dans le routeur, celui-ci sera automatiquement envoy au serveur. Modes de messages : Un message peut tre trait de diffrentes faon, comme envoy un contenu tout ceux qui le demande. Il peut tre mis en attente ou supprim lorsquaucune requte nest prsente pour de telles informations. Il peut tre supprim aprs envoie ou garder en mmoire pour de future abonnements.

Echantillons des cas de communication Tracer un objet mobile

1. Le traceur obtient sa position partir dun capteur GPS (F2). 2. Le traceur dcide sil doit envoyer sa position au serveur (F3). 3. Il crit et met en attente un nouveau message. 4. Quand il atteint un lieu ou la communication est possible, il envoie les messages en attente un point daccs. 5. Quand le point daccs rceptionne le message, il le fait suivre aux nuds de destination(F1). (a) Optionnellement, le point daccs peut lenvoyer un routeur ou attendre quun nud demande lenvoie de ce message. 6. Un nud de traitement (serveur) reoit le message et agit en consquence (le garde en mmoire, informe le client, etc.) (F3).

Demande dinformation concernant les appareils tracs

1.Lapplication client envoie un message au serveur demandant de sabonner aux informations dun appareil trac. 2.Les serveurs peut ensuite envoys les requtes dabonnement aux nuds concerns pour rpondre du mieux possible la demande du client (F4).

3.A chaque fois que le serveur reoit des informations, il envoie un message au client (F4). 4.Le client reoit les informations et les prsente aux utilisateurs sous forme dune carte par exemple (F5, F6).

Scurit
Parce que les nuds font circuler des donnes sensibles, tout ce qui transite par le rseau doit tre crypt. Les protocoles dencryptage connus et largement utilises doivent tre utiliss ici pour rduire le risque quune personne sans autorisation accde aux donnes. Le second problme est lauthentification. Comme plusieurs nuds oprent distance, le systme doit tre immunis contre des tentatives dusurpation didentit de nuds par dautres. Une infrastructure PKI devrait tre utilise pour identifier chaque nud dans le systme.

Environnement de programmation
A cause de la nature htrogne du systme, un grand nombre de langage de programmation et denvironnement seront utilises. Dans ce paragraphe, nous avons runis un ensemble de rgles suivre.

Nuds capteurs (F2)

Lenvironnement dpend normment de lappareil utilis.

Nuds de traitement (F3, F4)

-doivent fonctionner sous les environnements MS Windows et Linux. - dans certains cas ils devront fonctionner seulement avec un des systmes.

-doivent tre dvelopps en .NET, de prfrence en C#. -Mono project sera utilis pour les lancer sur Linux et les autres systmes Unix.

-Si ces applications fonctionnent sur des systmes embarqus, elles doivent tre dveloppes sous dautre environnements (ANSI, C, C++ ).

-Si les performances sont insuffisantes, et quune version en C++ semble fonctionner plus rapidement, un langage non manag.

Un environnement manag fournit un environnement Runtime pour des applications qui traitent dorganisation de mmoire. Les environnements moderne inclue .NET, Java, Python, Ruby et dautres.

Application pour les utilisateurs finaux (F5, F6)

-doivent fonctionner sous MS Windows (XP ou plus rcent). -commode utiliss avec dautres systme (Linux ou Mac), mais non requis. -doivent tre dvelopps en .NET, de prfrence en C#.

Nuds Physiques
Dans le cadre dINDECT, des nuds seront conus et tests avec des prototypes : 1. UAV, drone pour une surveillance arienne 2. Segment terrestre pour les UAV, une base pour les oprations et le contrle des drones. 3. Salle de commande, un centre pour commander, collecter et prsenter les informations de tous les nuds du systme WP2. 4. Nuds de commande mobile, permet des fonctions similaire aux fonctions de la salle de commande. 5. Serveur, responsable de toutes les oprations des nuds, peut tre distribu. 6. Traceur GPS/GSM, appareil capable de tracer la position dun vhicule et de rapporter sa position. 7. Traceur mobile, un appareil se dplaant dans un rseau quadrill. 8. Capteurs multifonction, un nud capable de se connecter diffrents capteurs et appareil pour crer un rseau quadrill.

Tous les nuds sont dcrit plus en dtails dans la figure 5 qui montre lagencement des nuds dans une vue gnrale du systme.

Figure 5 : vue gnrale des nuds

UAV (drones)
Ralise (F2) et ventuellement (F3).

Composants
Les composants principaux dun UAV sont : -aronef propulsion -systme embarqu avec pilote automatique -cardans stabiliss avec capteurs visuels -capteurs de diffrentes fonction (ex : chimique) -systme de communication Pour les oprations entre les composants internes, rfrez-vous la figure 6.

Le segment terrestre pour les UAV est requis pour cela (5.2).

Figure 6 : Composant dun UAV

Aronef propulsion
Ce composant consiste en : -hlices ou rotors -moteur (lectrique ou essence) -source dnergie du moteur (batterie ou essence) -gnrateur lectrique pour moteur essence -aronef avec moteurs actionneurs

Les facteurs principaux influant sur la conception de lUAV est la vitesse maximum et lendurance.

Figure 7 : Dessin technique de laronef

Systmes embarqus
Les systmes embarqus ont comme fonction de permettre le vol autonome de lUAV : 1. control des moteurs et actionneurs 2. control du vol 3. navigation

4. maintien de la trajectoire et du statut de la mission Les systmes embarqus peuvent aussi : Traiter des donnes de capteurs (incluant des algorithmes avancs de traitement visuel) Archiver les donnes (de faon limite) Compresser les donnes avant de les envoyer au segment terrestre.

LUAV Burzyck est quip de 3 ordinateurs : Un ordinateur de control de vol. Cest un ordinateur en temps rel bas sur la technologie ARM. Il est responsable du control des moteurs et actionneurs, du vol et des capteurs (En combinant les donnes de diffrents capteurs, il dtermine ltat actuel de lenvironnement et de laronef). Il sera conu et construit par PUT.

Figure 8 : visualisation de laronef

Figure 9 : diagramme cinmatique des cardans -lordinateur de performance utilise des architectures systme x86. Ils sont responsables des la navigation, de la mission et du traitement des donnes visuelles. -Le module dencodage video est un ordinateur conu pour compresser les flux vido. Les systmes embarqus communiquent entre eux via des routeurs Can ou des cbles Ethernet. Le premier protocole garantie une rponse rapide, le second une large bandepassante. Ces deux technologies sont utilises dans le but den tirer le plus grand potentiel. Larchitecture est base sur le passage de message entre les ordinateurs et les capteurs. Cette approche est trs ouverte et permet de remplacer facilement les diffrents modules, damlior les composants ou dajouter de nouveaux modules.

Cardan Stabilis
Le cardan est une des parties les plus importantes sur les UAV. Il est responsable du mouvement des capteurs visuels et de la stabilisation de limage (rduire les vibrations). Le principal compromis architectural trouver pour le cadran est la taille des capteurs embarqus et la le degr de libert du cadra. Plus le degr de libert est lev, plus la taille des capteurs doit tre rduite. La gamme de capteur pour le cadran incluse : Camras optiques Camras nocturne (proche de linfrarouge) Camras thermique (infrarouge) Tlmtres laser

Des cardans optiques et thermiques seront construits pour lUAV Burzyck. Cependant, nimporte quel constructeur peu construire un cardan, tant que le support et le systme de communication sont compatibles. Les cardans on 2 degrs de libert : le roulis et laxe de tangage. Ils sont reprsents sur la figure 9. Le cardan une masse de 650g.

Capteurs usage gnral

Un UAV peut avoir un support de capteurs usage gnral permettant dinstaller des capteurs fabriquer par un fabriquant extrieur. Ce type de systme doit avoir une interface publi (pices dtaches et logiciels).

Systme de puissance
Un UAV est quip du centre de gestion dnergie qui mesure la consommation de tout le systme et lnergie disponible. Il peut teindre certains systmes ou composants de lUAV ce qui permet un usage intelligent de lnergie disponible. Il est trs utile en cas de disfonctionnement les composants peuvent tre teint dans les cas durgence. Cela permet aussi de calculer le temps restant pour les oprations de lUAV (dans diffrents nuds).

Sous-systme de communication des UAV

Selon la dfinition de la section 1.2, lUAV peut tre un nud (F1, F2, F3, F4). Le systme de communication UAV possde 3 liaisons principales : UAV Segment terrestre LUAV rassemble de grandes quantits de donnes particulirement des donnes visuelles. Ce lien exige une communication large bande-passante. Bien sr lUAV peut effectuer une mission sans communication, mais cela est rare dans des applications civiles. Le segment terrestre envoie les donnes au systme centr sur le rseau UAV UAV La communication (F1) peut tre faite de 2 faons - la retransmission de donnes par large bande-passante haut dbit ou la retransmission de courte bande-passante. l'heure actuelle nous supposons, qu'il n'y aura aucune retransmission haut dbit. UAV - Nud terrestre La communication (F1) permet UAV d'tendre ses capacits de perception. Il peut tre aussi utilis pour tendre les capacits de communication du systme. Les donnes haut dbit de lUAV peuvent tre reues par des utilisateurs autoriss sur terre. Les capteurs terrestres peuvent envoyer des donnes restreintes/faibles UAV.

Figure 10 : Le systme de communication de lUAV

Segment terrestre de lUVA

Ralise : F5, F6

Figure 11 : Larchitecture du segment moulu Le segment terrestre est une partie du systme qui permet aux UAV de fonctionner partir de la Terre. Cela pourrait tre mobile (mont sur un vhicule ou port par le personnel). Ceux-ci sont les principales fonctions du segment terrestre : 1. Planifier les missions de lUAV ou transmettre les missions provenant de la Chambre de Commande lUAV. 2. Communiquer avec lUAV - le segment terrestre est le point principal de communication.

3. Direction de lUAVs sur missions : (a) Obtenir un flux vido en temps rel et la tlmtrie (b) Afficher les paramtres de mission (c) Contrler les paramtres de mission 4. Aider lUAV dcoller et se poser- la plupart des UAVs ont besoin dun dcollage spcialis et dun quipement datterrissage spcialis. Le segment terrestre pourrait tre mobile ou stationnaire. Le segment terrestre stationnaire est intgr la Chambre de commande et est un module de logiciel. La version mobile du segment terrestre consiste en :

Un traqueur d'antenne avec un systme de communication. Le design propos d'un systme de traqueur est montr sur la figure 12. Un ordinateur solide avec un logiciel d'oprateur. Un systme d'atterrissage visuel - un systme novateur qui utilise des images de camras embarques pour tracer lUAV et le site datterrissage.

Cet quipement est port dans un sac dos spcialement conu cet effet. Il permet 2 personnes de porter lUAV et le segment terrestre. Le traqueur d'antenne et le systme d'atterrissage visuel seront dvelopps par WP2. Le segment moulu doit aussi pouvoir faire des fonctions de maintenance incluant : 1. Maintenance de vhicules Par exemple nettoyage, rechargement, remplacement des parties. 2. Mise jour de logiciel et de matriel dans les vhicules. Ceci n'est pas exig pendant l'opration standard.

Figure 13 : Ide gnrale de la Chambre de Commande

Salle de Commande
Ralise les fonctions : F5, F6. Un centre pour commander la direction, runir et afficher les informations de tous les nuds de WP2. Il doit fournir : 1. Console (s) d'oprateur 2. Affichage mural pour une vue d'ensemble de la situation L'ide gnrale de la Chambre de Commande est prsente la Figure 13. La chambre contient les consoles de quelques oprateurs, des affichages muraux multiples et d'autres dispositifs d'impression/communication. La console d'oprateur devrait fournir :

1. Aperu des oprations du systme : (a) Statut gnral du systme (oprationnel, problmes, teint) (b) statut des nuds incluant : i. tat des serveurs, dpistage de performance, ii. tat des nuds dconnects - la dernire communication vue, la suivante attendue. (c) Liste des requtes. 2. Direction des nuds : (a) un module pour chaque sorte de nud sera fourni permettant : i. De contrler le comportement de ces nuds, spcifique chaque nud, ii. Denvoyer des ordres aux nuds loigns, iii. De runir les renseignements provenant des nuds. (b) Enregistrer de nouveaux nuds au systme, (c) Dsinscrire des nuds enlevs (nuds dclasss, nuds compromis, etc.) 3. Prsentation de la situation tactique : (a) Carte avec une position et un tat de tous les nuds, i. Possible avec un prsent prvu et des positions futures. (b) Alertes sur les vnements dcouverts dans le systme (les exemples sont incluent, mais ils ne sont pas limits au : mouvement des objets, sorties/entres des zones, dcouverte des objets), (c) Rsum des oprations conduites. Chaque oprateur est quip dune application avance pour l'assistance de commande qui permet dinspecter la situation tactique. Ce logiciel peut tre spcialis pour correspondre aux besoins de chaque oprateur. Il est possible de crer son propre environnement de travail, qui comprend toutes les informations ncessaires en temps rel. Il permet aussi de combiner diffrentes couches et objets sur une mme visualisation. Il est entirement intgr avec le systme central de rseau prsent dans ce livrable. Ceci permet de collecter et danalyser une grande quantit de donnes venant de diffrents types de nuds. Qui plus est, deux oprateurs peuvent travailler ensemble sur un cas et interagir l'un avec l'autre.

Figure 14 : Architecture de lapplication du bureau Un systme dautorisation pour les utilisateurs devrait permettre divers niveaux daccs. Par exemple, un utilisateur avec un mot de passe aura un accs plus restreint quun utilisateur avec une carte daccs. Gnralement, on rfrera une carte daccs.

Commande distance des nuds

Ralise la fonction : F6, et plus rarement : F5. Cette commande distance devrait permettre une capacit accrue de la salle de commande. Cependant, cela doit tre optimis pour laffichage dinformations et le contrle de nuds spcifiques comme demand par un oprateur spcifique (ou une opration). Laffichage de la situation tactique devrait tre rduite pour nafficher que les informations importantes et cela afin daccroitre la lisibilit. Un aperu du systme peut tre transfrer sur le module de commande distance si ncessaire ou plus pratique.

Serveur responsable des oprations de tous les nuds

Ralise les fonctions : F3, F4. Le server est dfini comme une infrastructure requise pour que les logiciels fonctionnent avec une performance optimale et une grande disponibilit. Le serveur devrait : 1. Etre capable de gr un usage CPU de tout les logiciel en traitement ncessaire pour collecter et traiter les informations de tous les nuds. 2. Navoir aucun point dchec les units CPU, les disques, lnergie, la connexion avec le rseau devront tre en surnombre.

3. Etre scuris (composants requis dfinis aprs)

Les logiciels du serveur devront permettre la capacit de : 1. Accepter les connections et messages de tous les nuds du systme 2. Dlivrer ces messages aux modules responsables des nuds qui devraient : (a) Stocker tout/la majorit des informations reues (b) Dtecter loccurrence dvnements requtes des utilisateurs (c) Rapporter ces vnements aux utilisateurs sous forme dalertes 3. Rpondre aux requtes des clients sur ltat actuel des nuds, les dernires informations reues et lhistorique des rceptions.

Le serveur WP2 est dvelopp autour dune architecture Return dveloppe par PUT. Return est une application du serveur utilisant un cadre de programmation .NET et fonctionnant sur diffrentes plateforme Windows et Linux. Lutilisation de Return permet une modularit et un dveloppement facile du serveur. Bas sur une architecture cadre, le serveur WP2 est divis en plusieurs modules. Chaque module est responsable dune partie des fonctionnalits du serveur. Les modules changes des messages lorsque des donnes ou des traitements raliss par dautres modules sont ncessaires. Le serveur Return fournit toutes les infrastructures ncessaires pour le passage des messages, les mcanismes de scurit et de communication bass sur des messages avec les autres nuds. Optionnellement, dautres modules peuvent fournir leur propre mthode de communication si ncessaire. Les fonctions des serveurs sont partages dans les diffrents modules. Le systme central de Return est LightBus un routeur de haute performance dont la tche

et de permettre la communication entre les diffrents modules. Toute communication entre les nuds est base sur des messages et des modles de publication et dabonnement. Chaque module fonctionne indpendamment des autres, utilisant ses propres processus et ressources. Ils demandent au routeur de collecter les messages qui les intressent. Quand un module a de nouvelles donnes ou des rsultats dun traitement, il les publie comme message pour le routeur. Le routeur dlivre alors ces messages aux modules stant abonns ces donnes.

Ce modle de communication permet plus dindpendance entre les modules. Cela donne deux avantages de la plus haute importance. Premirement, aucune ressource ne lance de code dautres modules. Cela accroit grandement la fiabilit des modules, rduit les problmes de concurrence daccs aux variables et donnes et permet des tests plus simplement. Ensuite, les modules sont dcoupls, parce quils ne communiquent pas directement mais avec laide du routeur. Les modules publient des donnes quils produisent et sabonnent dautres flux. Les publicateurs et abonns nont pas tre en relation. La figure 16 prsente cette ide sous forme graphique. Les fonctionnalits du serveur sont rparties dans les modules suivants : 1. GisProvider GisProvider est un module multifonctions responsable de laccs de la base de donnes

gographique. Cest un utilitaire qui fourni des donnes GIS aux autres modules et au centre de commande afin dafficher des cartes aux utilisateurs.

2. ObjectProvider ObjectProvider est un module de base extensible pour les modules responsable de la production, du traitement et de la gestion des donnes propos des objets du monde rel. La liste INDECT concernant ces objets inclue, mais nest pas restreinte aux : UAVs, traceurs, units blue force, objets tracs. Ce module est responsable de garder en mmoire les informations sur les objets dans la base de donnes et fournir un accs ses donnes dans le future. Les objets sont identifis par une squence URI. LURI est une structure hirarchique o tout objet est identifi et plac dans une arborescence de tous les objets. Les niveaux hirarchiques et identifiants sont bases sur des squences et spar par le caractre / .

3. IndectWebService Les donnes collectes et traites par les systmes WP2 doivent tre disponibles en dehors du WP2 principalement sur le portail WP6. Les connexions avec le portail seront disponibles via le SOAP WebService. Lexcution de ce Webservice sera dans un module de retour dIndectWebService. Le contrat de linterface est en discussion avec le WP6.

4. Stockage Vido Les flux vido des UAVs et ventuellement dautres nuds sont stocks sur des disques dans le serveur. Ce module fourni un accs ces flux par un visionnage hors ligne des contenus par les utilisateurs autoriss. Cela permet un accs aux vidos selon les dates et sources des vidos et un visionnage depuis la Salle de Commande et ventuellement du WP6.

5. Gestionnaires de nuds Chaque nud trac doit tre grer par le serveur. Une liste de nuds tracs avec leur certificat et identification doit tre stocke et tre mise disposition pour que les nuds autoriss fournissent des informations. Une liste de rvocation de certificats doit tre particulirement gre. En plus de cela, la configuration de tous les nuds capteurs multifonctions doit tre accessible pour les utilisateurs ainsi que les diffrentes modifications apportes lexpdition vers dautres nuds lorsque cela est possible.

Traceurs GSM-GPS
Ralise la fonction : F2. Cest un petit appareil muni dun rcepteur GPS pour tracer les objets auxquels il est attach.

Lappareil utilise un module GPS de haute performance avec une antenne omnidirectionnelle qui protge de toute interfrence, incluant les signaux trajectoire multiple. Le module est capable de fonctionner en autonomie dans un mode conomiseur dnergie, par exemple avertir de sa position par priode de temps. Le module de communication GSM est intgr avec un processeur qui excute tout les codes de lappareil. Cela permet une meilleure intgration et rend possible un contrle total de la partie communication et des tches des logiciels. Lantenne intgre est une penta-bande supportant 5 bandes de frquences GSM, ainsi une mise jour vers la 3G sera possible lavenir. Cependant gnralement, la transmission GPRS/EDGE est suffisante tant que la vitesse du flux de donnes reste un avantage sur la 3G ayant une basse consommation dnergie. Optionnellement, le traceur peur utiliser des transmissions SMS au lieu de la GPRS/EDGE quand de telle connexion peuvent tre ralises. Larchitecture GPRS/EDGE est reprsente dans la figure 17. Le but tant que le traceur GPRS/EDGE soit oprationnel aussi longtemps que possible, le module peut fonctionner dans diffrents modes pour conomiser son nergie c'est--dire : 1. Rester en ligne en transmission de donnes continuelle ou priodique par GPRS/EDGE. Les positions de lobjet peuvent tre sauvegardes sur une mmoire interne pour des synchronisations priodiques avec le serveur. Les positions ne sont pas envoyes si lobjet est immobile pour conserver de lnergie et ne pas submerger le server de donnes.

2. Rester en ligne seulement lorsque la position de lobjet est en dehors dune certaine zone appel mode ancre. Ce mode peut amliorer le temps dopration.

3. Dsactiver la radio et se connecter seulement lors dvnements (a) Priodiquement pour rapporter une position, par exemple toute les 6h. (b) Lors du mouvement de lobjet et quil excde un certain seuil prprogramm.

4. Rester hors ligne durant une priode de temps prprogramme. Cela permet datteindre un temps darrt de plusieurs mois.

5. Envoyer un signal GPS dtaill au satellite dans le mode dmarrage, c'est--dire quand le module est attach lobjet trac. Dans les autres modes, seules les donnes les plus importantes sont envoyes automatiquement pour rduire lutilisation de la mmoire du module.

Les modes peuvent tre modifis distance nimporte quand. Tout autre option de configuration comme permettre le transfert de donnes pendant le mouvement de lobjet

sont aussi accessibles distance. Lappareil est muni dun gestionnaire dnergie responsable de charger la batterie, gr son tat et sassurer que le module GSM (le module qui consomme le plus dnergie) soit correctement aliment, mme sous de basse temprature ou les performances de la batterie sont moindres. Les informations sur ltat de la batterie sont priodiquement envoyes au serveur, pouvant ainsi tre gr par un oprateur. Le diagramme darchitecture du traceur GPS/GSM est reprsent dans la figure 18.

Traceurs mobiles
Ralise les fonctions : F2. Cest un petit appareil utilis pour trac les objets. Il doit tre conu pour rendre possible sa petite taille et un long temps dopration sans charger la batterie. Contrairement aux traceurs GPS/GSM, le traceur mobile utilise le rseau maill construit avec plusieurs nuds multifonction pour la communication et lestimation de la position de lappareil. Lappareil possde un transmetteur radio pour transmettre les donnes et recevoir des commandes. Il utilise un sous-systme de communication pour les courtes distances pour

envoyer et recevoir des donnes aux diffrents nuds du rseau maill ou dautres nuds mobiles. Le schma de communication net prsent sur la figure 19. La position du traceur est obtenue en analysant les informations relatives lentre et la sortie de certaines zones. Optionnellement, lappareil peut tre quip dun rcepteur GPS pour obtenir des informations plus prcises sur la localisation de lobjet. Dans ce cas, lappareil aura aussi un acclromtre pour teindre le rcepteur lorsque lobjet est immobile ce qui aura pour consquence de rduire la consommation dnergie et ainsi augmenter le temps de fonctionnement. Larchitecture du traceur mobile et reprsent dans la figure 20.

Capteurs multifonction
Ralise les fonctions : F1, F2 et dautres avec des ajouts. Un nud multifonction. Il est quip avec un sous-systme de communication courte distance pour tablir une connexion avec les autres nuds du systme. Ils sont placs dans les villes. Lun des objectifs de ce nud et la gestion du trafic et la reconnaissance de toutes les plaques dimmatriculation des vhicules en circulation. Ils devraient aussi cooprer avec les nuds voisins le rseau pivot. De cette faon, un set de nuds multifonction cre un rseau, o on peut accder tous les nuds avec un passage de message. Le schma dun tel rseau peut tre vu dans la figure 19. Chaque nud contient la liste des vhicules demands, par exemple les vhicules vols. Le systme de reconnaissance des plaques dimmatriculation fonctionne sous deux modes TOUS ou RECHERCHES. En mode TOUS, le nud rapporte lapparition de chaque vhicule, alors quen mode RECHERCHES le nud reporte lapparition de vhicule sur la liste des vhicules recherchs. De plus, dautres sous-systmes peuvent tre ajouts au nud, incluant : 1. Communication longue distance un nud peut tre connect au rseau pivot, avec une connexion sans fil ou cble bande-passante, fonctionnant dans ce cas comme un point dentre vers le rseau maill. De plus, un tel point dentre est possible et conseill pour la fiabilit du rseau maill. 2. Camras vido pour observer et dtecter diffrents types dobjets. 3. Dtecteurs de son 4. Station mto

Figure 21 : capteur multifonction

Le schma du nud est prsent sur la figure 21. Lunit centrale du capteur multifonction est compos de : Carte Mre responsable de la gestion de lnergie et du routage des paquets de donnes lintrieur du nud. Elle peut possder des extensions capteurs. Module photographique responsable du traitement des images ralis par le capteur. Module de communication un set dappareil sans fil qui permet la communication aussi bien entre les nuds du rseau quavec les objets mobiles.

Interfaces et protocoles de communication

Dans le but dassurer une communication adquate et fiable dans le WP2, une srie dinterfaces et de protocoles de communication ont t dvelopps. La section suivante couvre les diffrentes interfaces en les appareils et le sous-systme WP2 :

UAV <-> Serveur WP2 Rseau : Lien donnes COFDM Logiciel : Interface SI.Log2, Interface SI.Video

Capteurs multifonction <-> Serveur WP2 Rseau : Ethernet/IP Logiciel : Interface SI.1

Traceur mobile <-> capteurs multifonction Rseau : radio courte distance Logiciel : Interface SI.2

Traceur GPS/GSM <-> Serveur WP2 Rseau : GPRS/EDGE/HPSA Logiciel : Interface SI.2

Serveur WP2 <-> Portail WP6 Rseau : Ethernet/IP Logiciel : Interface SI.WS1 SOAP WebService

Puisque ces appareils sont utiliss par les forces de police, seule les informations les plus importantes seront donnes. Les protocoles exacts sont confidentiels pour assurer la suret du procd et sera donn aux personnes autorises sous-requte. Toutes les communications sont encryptes.

Communication entre lUAV et le serveur WP2

Flux vido de lUAV

Le signal vido des camras est compress par un module dencodage vido. Un module commercial tel quutilis actuellement pourrait compresser en format MPEG et MPEG-4. La compression MPEG est mon efficace en termes de bande-passante mais est robuste et ne cause aucun dlai de rception. Parce que un UAV en vol est trs dynamique et que limage change trs rapidement, la plupart des bnfices du MPEG-4 sont perdus. Ainsi, le systme de compression se concentre sur le MPEG. Le dlai dun flux MPEG est a peu prs de 15 ms. La rsolution du signal est de 640x480 ou 704x480 selon la camra.

UAV et tlmtrie des charges utiles

Le protocole de tlmtrie est un protocole sans connexion bas sur des datagrammes UDP. La structure du protocole est base sur le passage de messages. Pour le moment, de tels messages prvoient : Position et tat Ce message est utilis pour obtenir la position et ltat de lUAV, incluant son orientation et sa vitesse. Surfaces de contrle Ce message contient ltat des surfaces de contrle de lUAV, incluant les machines de vitesse, rabats, etc. Statut du cardan Ce message dfini lorientation et mode dopration du cardan. Contrles de base du cardan Ce message tablit les contrles de base du mouvement du cardan. Contrles visuels du cardan Permet le contrle du cardan en mode visuel. Statut du cardan en mode visuel Obtient des messages de statut du systme de traceur visuel. Contrle du cardan en mode traceur mobile Contrle les messages envoys au cardan en mode traceur mobile. Consommation dnergie Ce message est utilis pour obtenir la consommation courante et totale de lUAV. Les informations de ces messages sont disponibles pour loprateur de lUAV.

UAV et planification des missions

Les missions sont dfini dans une structure en arborescence dans laquelle les tches sont soit un objectif concret (ex : voler dun point A un point B) ou une composition de sousobjectifs. Les messages de planification de mission sont dfinis de faon rcursive : un message peut contenir dautre message. Srie dobjectifs Ce message devrait tre utilis pour les objectifs consistant en une suite dobjectifs excuter dans un ordre prcis. Set dobjectifs Ce message devrait tre utilis pour dfinir un objectif consistant en une srie dobjectif dont lordre est dfini par la requte. Lordre peut tre dfini par exemple pour minimiser les distances parcourues. Objectif tat limit Ce message devrait tre utilis pour dfinir un objectif en srie dobjectif effectue dans un ordre dpendant de lapparition dvnements, ventuellement plusieurs fois. Objectif de vol selon une cible Ce message devrait tre utilis pour dfinir un objectif de vol jusqu un point. Objectif de vol selon un segment Ce message devrait tre utilis pour dfinir un objectif de vol le long dun segment. Objectif de patrouille Ce message devrait tre utilis pour que lUAV patrouille autour dune position donne. Objectif de couverture polygonale Ce message devrait tre utilis pour dfinir une zone de couverture visuelle o lUAV fournira des flux vido. Position Ce message devrait tre utilis pour dfinir une position gographique. Altitude Ce message devrait tre utilis pour dfinir une altitude requise. Vitesse Ce message devrait tre utilis pour dfinir une vitesse requise. Transition Ce message devrait tre utilis pour dfinir une transition dans lobjectif tat limit.

Communication entre les capteurs multifonction et les serveurs

Ce protocole est utilis par les capteurs multifonctions pour communiquer entre eux. Le message peut contenir aussi bien des informations de pilotage que des donnes collectes par le systme. Cadre standard Ce cadre englobe tous les autres cardes envoys ou reus par les nuds multifonctions.

Cadre dinformation Ce cadre permet de reprogrammer les nuds dans les airs. Traceur mobile Ce cadre est utilis pour la transmission des donnes depuis des appareils qui tracent les vhicules mobiles. Cadre de reconnaissance de plaque dimmatriculation Ce cadre est utilis pour la communication avec le module de reconnaissance de plaque dimmatriculation. Il peut tre utilis pour report lapparence du vhicule ou excuter des commandes telles que ajouter cette plaque la liste .

Communication entre les traceurs mobiles et les capteurs multi-usages

Ce protocole est utilis pour envoyer et recevoir des messages des traceurs mobiles via le rseau radio courte porte. Balise Ce cadre est envoy priodiquement par une station mre afin dinformer les traceurs porte de quelle station mre il sagit. Requte Ce cadre permet aux traceurs denvoy des informations (sans la requte adquate, les traceurs nmettent aucun cadre). Statut Cadre qui englobe les informations envoyes un traceur.

Communication entre les traceurs GSM-GPS et le serveur WP2

Ce protocole est utilis pour communiquer avec les traceurs GPS/GSM par des rseaux GSM existants (GPRS/EDGE/SMS). Configuration Ce cadre est envoy aux traceurs pour tablir le mode de fonctionnement appropri. Rponse Ce cadre est envoy en rponse la requte de changement de mode de fonctionnement. Echec Ce cadre indique des problmes dans le changement de mode de fonctionnement. Installation Ce cadre contient toutes les donnes en dtails de tous les satellites GPS vue par le systme. Position Ce cadre est envoy par le traceur avec ses positions passes et sa position courante. Statut Ce cadre contient les informations sur les statuts des signaux GPS/GSM et les donnes concernant les stations BTS dtectes par lappareil dans son voisinage. Batterie faible Ce cadre est envoy lorsque la batterie interne est faible.

SIM prpay Ce cadre est envoy quand une carte SIM prpaye est installe dans un traceur GPS/GSM. Mise en mouvement Ce cadre est envoy pour indiquer que lobjet commence se dplacer. Arrt du mouvement Ce cadre est envoy pour indiquer que lobjet arrte de se dplacer.

Communication entre le serveur WP2 et le portail WP6

Ce protocole est utilis pour la communication avec le portail WP6. A lavenir, quand lintgration du projet sera maturit, il y aura un set de messages prvu pour la communication avec le portail Indect. Les messages suivants sont des exemples du protocole qui sera utilis avec le portail Indect. Soumettre des objets pour fournir des donnes propos dobjets GIS du portail WP2. Obtenir des objets pour lister les objets dans une rgion gographique spcifie, avec des critres spcifiques, alors les objets sont visibles depuis le portail.

Intgration
Cette section dcrit les mthodes dintgration entre les systmes du WP2 et ceux du WP. Dans la section suivante, nous entendons par systme externe applications et systmes externes aux WP2.

Scnarios

Oprations de surveillance UAV

Lutilisateur de certains systmes externes trace des vhicules qui lintressent. Il/Elle sait quun UAV opre actuellement dans la mme zone. Le WP2 fournit au systme externe des donnes en temps rel provenant de lUAV et lutilisateur peut par exemple utiliser le portail dvelopp dans le WP6 pour regarder les vidos de lUAV. Informations fournies par le systme WP2 : Vido un flux en temps rel des vidos de lUAV prsenter dans le contrle vido.

Auxiliaire la tlmtrie de lUAV : position, angle du cardan, proprits du cardan, etc.

Entres de lutilisateur : Aucune lOperateur du portail nest pas autoris contrler lUAV cet officier peut communiquer avec loprateur UAV par dautre moyen (ex : tlphone) pour changer les actions de lUAV.

Oprations Hors ligne UAV

Lutilisateur collecte un groupement de donnes prsenter la cour. Il/Elle est intresse dans les donnes concernant une certaine priode de temps ou zone. En utilisant le portail, lutilisateur dtermine si des UAV taient en mission dans cette zone durant cette priode. Sil y a eu des missions, lutilisateur peut accder aux vidos. Entres de lutilisateur : Temps comme dcrit dans le paragraphe Type de donnes . Lieu (type de position comme dans type de donnes ) Cela peut-tre un seul point ou deux dcrivant une zone circulaire entre eux.

Information fournies : Vol des UAV dans cette zone ce moment prcis Chemin suivi par lUAV dcrit comme une liste de point dans le temps avec la position correspondante. Direction du cardan

Planification de missions UAV

Lutilisateur utilise un systme externe. Dans le cas o lutilisateur ou le systme trouverait bnfique le fait de lancer une mission avec des UAVs, un systme externe peut programmer un chemin de point de passage et lenregistrer sur le portail WP2. Le systme peut le mettre ainsi en attente, le suggrer loprateur UAV ou le supprimer, tout dpend des contraintes.

Entres du systme externe : Description de la mission consistant en une liste de point de passage dcrit dans le

paragraphe type de donnes .

Informations fournies : Rsultats si la mission est en attente, accepte ou rejete. Validation si la mission est ralisable en termes techniques (ex : pas de limite de vitesse dpasse). Disponibilit si des UAV sont disponible pour le moment. Rservation informe tout le personnel quune mission est planifie pour le moment cela peut tre une entre ou un flux de travail plus important.

Reconnaissance de plaques dimmatriculation

La station de reconnaissance de plaques minralogiques est situ prs des routes et lis toutes les plaques des vhicules. Il y a deux modes dopration possibles : ENREGISTRER TOUT et ENREGITRER LES DEMANDES. Le premier enregistre toutes les plaques minralogiques alors que le second enregistre seulement les plaques prdfinies par lutilisateur. Entres de lutilisateur : Immatriculation demandes plaques de voitures recherches, dfinies par lutilisateur.

Informations fournies : Numro numro de licence du vhicule. Image photo du vhicule correspondant au numro. Temps heure exacte de la reconnaissance. Couleur (optionnel) la couleur moyenne du vhicule.

Tracer par GPS-GSM

Lappareil traceur GPS-GSM supporte divers modes pour fournir un bon compromis entre la consommation dnergie et la qualit du tracking. Le mode peut tre chang en temps rel afin de saccommoder des diffrentes requtes. Entres de lutilisateur : Frquence frquence laquelle lappareil rapporte sa position.

Frquence de synchronisation frquence laquelle les lots de positions sont envoys au serveur. Informations fournies : Temps heure du rapport de position. Position position de lobjet trac. Prcision prcision de la position courante. Vitesse vitesse de lobjet trac. Niveau de batterie nergie restante dans la batterie. Cellule GSM station de transfert GSM courante (BTS).

Type de donnes Position

Champs : Latitude prsente en degrs dcimaux (52.1235), dpendant des donnes reprsenter. Longitude idem Altitude mtres au dessus de la mer/terre, sera marqu par mtadonnes. Systme de rfrence godsique WGS84

Temps
Ce type dcrit le temps dune faon sans quivoque. Lexcution sera discute plus tard. Ces et dautres type de donnes similaires sont dcrites comme espaces rservs de futures discussions. Autoriser des partenariats dans dautre WPs pour tre conscient de la disponibilit des donnes du WP2. Il faudra inclure la date, lheure, le dcalage par rapport lUTC, probablement un zone dinfo pour le temps.

Vitesse

Ce type de donnes dcrit la vitesse dune faon sans quivoque. Lexcution sera discute plus tard. Pour le moment nous proposons des mtres par seconde.

Point de passage
Chaque point de passage dcrit un point dans la mission o ltat de lUAV change. Il contient les champs suivants : Temps comme dcrit prcdemment Position idem Action dcrit le plan de mission pour ce point de passage, par exemple commencer enregistrer .

UAV
Ce type de donnes dcrit tous les paramtres de lUAV en opration. Champs : Position comme dcrit prcdemment Temps idem Vitesse idem Direction du cardan angle dans lequel la camra regarde Zone Observes zone observes par la camra (position + radius) Mode de stabilisation du cardan mode de stabilisation Proprit de la camra ex. niveau du zoom, ou mode dopration Enregistrement est lenregistrement disponible de lUAV. Action toute action spciale que lUAV effectue. Niveau de la Batterie Mesure du voltage de la batterie principale de lUAV. Type de mission Une brve dfinition de la mission ( partir des objets de la liste prdfinie). Prochain point de passage comme dcrit prcdemment.

Mission de lUAV
Description dtaille de la mission. Cela consiste en une srie de point de passage comme dcrit prcdemment.

Objet trac
Permet un aperu des donnes propos des objets. Une srie de cette entit peut tre mis jour couramment. On peut envoyer une requte au systme par rapport un objet. Paramtres toujours prsents dans laperu : Uri Identificateur de chaine associ lobjet, cl unique. Position dcrit prcdemment. Temps marque temporel du prsent enregistrement. Texte de description entre par lutilisateur. Paramtre optionnels : Vitesse comme dcrit prcdemment. Icne Uri de licne qui peut reprsenter lobjet sur lcran.

Donnes des vhicules

Structure de donnes qui dcrivent le vhicule dtect par le module de reconnaissance de plaque. Champs : Numro numro de licence du vhicule. Image photo du vhicule correspondant au vhicule. Temps lheure exacte de la reconnaissance. Couleur (optionnel) couleur du vhicule.

Donnes fournies
Le WP2 fournit trois types de donnes : flux vido, descriptions des donnes des objets tracs et des vnements.

Flux vido
Le systme dans sons ensemble plusieurs nuds quip de camras vidos. Cela peut tre un UAV ou un module de reconnaissance de plaque. Lobjectif principal est danalyser le flux vido localement et de prendre toute les dcisions automatiquement. Une situation qui require dune prsentation vido loprateur peut survenir. Tous les nuds du systme analysant les donnes vido peuvent aussi les transmettre loprateur distance. LUAV peut produire un flux vido en format MPEG ou MPEG-4. La station de reconnaissance de plaques nenvoie que les images statiques durant son opration. Il est aussi possible de transmettre des flux vido en MPEG ou MPEG-4, cependant cest une caractristique optionnelle. Tout les flux vido peuvent tre stocks et tlchargs ensuite si besoin. Le serveur de stockage vido supporte le MPEG et MPEG-4. On peut donc lutiliser pour le stockage des vidos. Une requte peut contenir la source, qualit et priode de temps dsire.

Description des objets

Quand le systme trace un objet, un aperu est disponible partir du systme. Les services externes peuvent soumettre des requtes selon quatre scnarios : Informations courantes propos des objets identifis par URI en rponse, il peut obtenir un aperu de cet objet. Informations courantes propos des zones dsires (pour dterminer si la zone peut tre rectangulaire ou avoir une forme arbitraire) en rponse il peut obtenir un aperu pour un objet prsent ou se dplace dans la zone. Informations historiques propos des objets identifis par lURI et intervalle de temps en rponse il peut obtenir une liste daperu pour cet objet. Informations historiques propos des objets dune zone et dun intervalle de temps en rponse il peut obtenir une liste daperu des objets prsent dans cette zone ce moment prcis.

LAPI de ce service est en train dtre dtermin en coopration avec les utilisateurs des donnes.

Evnements

Etat de lUAV Cet vnement arrive quand lUAV atteint un certain tat. Les tats possibles sont : Atteindre un point de passage (incluant le dpart et latterrissage). Un capteur a trouv un objet (un certain seuil est atteint).

Batterie faible. Urgence

Etat de format de trame : Position dcrit prcdemment. Temps idem. Description dtat information propos du point atteint.

Reconnaissance de plaques dimmatriculation Cet vnement se passe lorsquun vhicule apparait en fasse de la camra. Cet vnement est dclench par : Apparition de vhicules, en mode TOUT. Apparition des vhicules demands, en mode DEMANDES.

Les donnes standard pour la reconnaissance des donnes sont transmises dans ce cas.

Travaux Futurs
Tches restantes complter dans le plus haut niveau de conception de larchitecture sont : Choix dune plateforme middleware pour la communication base sur des messages. Description dtaille de tous les nuds du systme. Description dtaille de lintgration avec le WP6 pour permettre lexcution. Spcification dtaille des protocoles dencryptage et dautorisation.

Conclusion
Dans ce document, nous avons dcrit une architecture du systme centr sur un rseau ayant t conu dans le WP2 du projet INDECT. La conception prsente est hautement modulaire, stable, ouverte et scurise. Elle est divise en deux parties principales. Premirement, le sous-systme de communication consistant en une infrastructure dhardware et des modles et stratgies de communication. Deuximement, une production construite sur le plus puissant des rseaux pour permettre ces fonctionnalits : UAV, segment central UAV, salle de commande, serveurs, traceurs GPS-GSM, traceurs mobiles et capteur multifonctions. Ces deux parties peuvent avoir des extensions, tre modifies, remplaces indpendamment aussi longtemps quelles sont conforment aux spcifications. Chaque construction du WP2 est modulaire grce cela, de nouveaux nuds peuvent tre ajouts linfrastructure du rseau, la couche de produit, etc. La conception du serveur et du logiciel client inclue la modularit. Le logiciel est conu pour tre facilement tendu avec de nouveaux modules, plugins, pour supporter facilement lajout de nouvelles fonctionnalits et caractristiques.