La Grosse Annexe

Image86

Description architecturale du système INDECT

 Attention !

Ce document, issu d’INDECT et traduit par Anonymous peut s’avérer particulièrement laborieux à la lecture : très technique, les systèmes y sont décrits dans des détails qui paraitront abscons aux néophytes. Néanmoins, nous avons tenu à publier cette version française inédite pour ceux qui souhaitent et peuvent en comprendre les détails, pour ceux qui désirent en savoir plus sur le cœur de ce sujet très particulier.

Document original en anglais ici : http://www.indect-project.eu/files/deliverables/public/deliverable-2.2/view

Contenu

Informations du document

Sommaire exécutif

Introduction

Structure logique

Vue d’ensemble du système

Types de nœuds

Sous-système de communication

Idée Générale

Connecter les segments sans IP

Communication entre les modules

Modèle de communication

Echantillon des cas de communication

  • Tracer un objet mobile
  • Demande d’information concernant les appareils tracés

Sécurité

Environnement de programmation

Nœuds  capteurs (F2)

Nœuds de traitement (F3, F4)

Application pour les utilisateurs finaux (F5, F6)

Nœuds Physiques

UAV (drones)

  • Composants
  • Aéronefs à propulsion
  • Systèmes embarqués
  • Cardan stabilisé
  • Capteurs à usage général
  • Système de puissance
  • Sous-système de communication des UAV

Segment terrestre de l’UAV

Salle de commande

Commande à distance des nœuds

Serveur – responsable des opérations de tous les nœuds

Traceurs GSM-GPS

Traceurs  mobiles

Capteurs multifonction

Interfaces et protocoles de communication

Communication entre l’UAV et le serveur WP2

  • Flux vidéo de l’UAV
  • UAV et télémétrie des charges utiles
  • UAV et planification des missions

Communication entre les capteurs multifonctions 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

Intégration

Scénarios

  • Opérations de surveillance UAV
  • Opérations Hors ligne UAV
  • Planification de missions UAV
  • Reconnaissance de plaques d’immatriculation
  • Tracer par  GPS-GSM

Types de données

  • Position
  • Temps
  • Vitesse
  • Point de passage
  • UAV
  • Mission de l’UAV
  • Objet tracé
  • Données des véhicules

Données fournies

  • Flux vidéo
  • Description des objets
  • Evénements

Travaux Futurs

Conclusion

 

Sommaire exécutif

Dans ce document nous décrivons une structure logique et une architecture du système développé.

L’objectif du système est de supporter les activités des officiers de police et d’autres services publics. Son but est de réaliser l’intégration de nombreux moyens qui peuvent surveiller les objets mobiles. Des moyens existants et un qui sera développé par la suite seront utilisés à ces fins.

Physiquement, le système est divisé en nœuds qui communiquent entre eux. Nous avons catégorisé ces nœuds de façon logique pour une meilleure orientation. Chaque nœud peut réaliser une ou plusieurs fonctions de la liste suivante : fournir une communication, rassembler des données,  effectuer des opérations sur les données, présenter les données aux utilisateurs. Dans la Section 1, nous donnons une description détaillée des fonctions et des relations existante entre ces fonctions.

Le deuxième point important est le réseau qui crée une connexion entre les nœuds. Nous pouvons établir une distinction entre trois types de connexion. Premièrement, un réseau de câble à bande passante large et à temps de latence court, utilisé  comme réseau 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 réseau pivot aux lieux distants, ou un réseau câblé n’est pas disponible. Enfin, un réseau sans fil courte distance sera utilisé pour connecter les nœuds mobiles.

Vous pouvez trouver une description plus détaillée et une technologie suggérée dans la Section 2.

La Section 3 fourni un modèle de communication selon lequel est construit le reste du système. Selon les scénarios, deux modèles peuvent être utilisés. Premièrement, un flux TCP qui est largement utilisé sur Internet. Il est réalisé pour appuyer la communication entre deux nœuds qui peuvent ainsi avoir un réseau de connexion durant la durée nécessaire de la communication. Ce système est souvent utilisé pour les grandes quantités de données comme une vidéo en temps réel ou des images prises de caméras. Le second modèle est basé sur le message. Quand un nœud veut communiquer avec un autre, celui-ci prépare un message qui contient lui-même un paquet de données que d’autres nœuds peuvent comprendre et sur lesquels ils peuvent agir en termes de communication. Ce message peut ensuite être propagé sur le réseau dans une base de données ou sous d’autres formes. Cela permet la communication avec un point distant qui ne se connecte qu’occasionnellement sur le réseau. Un message peut être stocké sur un point d’accès avant d’être transférer à un nœud mobile via le réseau sans fil. De la même façon, un message d’un nœud mobile peut être transférer sur le réseau permanent ou vers d’autre nœuds mobiles. Un tel message peut être transférer longtemps après que le nœud originel ait clos sa connexion au point d’accès.

Afin de développer des modules de façon fiable et cohérente, les pré-requis et recommandations pour l’environnement de programmation sont regroupé dans la Section 4. Les nœuds de processus (serveurs) sont requis afin de supporter en même temps les environnements Microsoft Windows et Linux. L’usage final des applications doit supporter l’environnement Microsoft Windows. Les plateformes C# et .NET sont recommandées. La Section 5 spécifie les plus hauts niveaux de pré-requis pour tous les nœuds du système. Les nœuds suivant ont été présentés : UAV, UAV segment terrestre, salle de commande, commande mobile, serveurs et de nombreux capteurs.

UAV est un système autonome qui peut accepter des missions et les réaliser sans de plus ample supervision. Il peut lui-même être divisé en différents sous-modules développés  en coopération. En partant de l’a cellule, cela doit supporter tout le poids et la puissance requise, des ordinateurs connectés aux capteurs et système de communication. L’UAV segment terrestre est directement en interaction avec l’UAV, permettant à l’utilisateur de contrôler l’UAV.

La salle de commande et la commande mobile sont des points d’entrée pour l’utilisateur qui permettent de maintenir et de profiter des avantages du système. Il contient un mur d’affichage qui présente une vue générale de la situation afin de commander des officiers et d’autres personnes sous-contrôle. Les consoles des opérateurs permettent d’entrer des données d’information dans le système, contrôler tous les nœuds et de leur envoyer des commandes. Il est aussi possible d’enregistrer des requêtes pour contrôler ce qui s’affiche sur le mur d’affichage.

Les nœuds serveurs sont responsables de stocker les données collectées dans le système et de permettre leur consultation hors ligne dans le futur. Les nœuds serveurs assistent aussi les requêtes en cours entrées depuis les salles de commande.

La liste des capteurs inclut un système de repérage mobile d’appareils et des capteurs multi-usages. Ce repérage peut être réalisé en se basant sur différents systèmes de localisation. La première solution et d’utiliser un récepteur GPS pour acquérir la position actuelle et de la transférer via un système de communication sans fil. Pour cette communication, un réseau GPRS ou un système pour les courtes distances peut être utilisé. La deuxième solution est d’utiliser un système sans fil courte distance quadrillé pour la localisation et la communication avec le système.

Un capteur multi-usage peut être équipé avec plus d’appareils afin d’obtenir un plus large spectre de données. On peut prendre comme exemple des caméras pour détecter les objets d’intérêt et fournir une vidéo en temps réel, des capteurs de température, des capteurs biochimiques pour détecter des contaminations, et bien d’autres possibilités.

La Section 7 décrit un détail technique des données qui peuvent être acceptées comme entrées des nœuds ou disponibles comme sorties.

La conclusion du document est apportée Section 8 avec un sommaire du travail futur qui sera réalisé sur le point T2.1.

 

Introduction

Le point T2.1 dans le paquet de travail WP2 concerne la vue d’ensemble très importante de système étant développé dans ce paquet. Le but principal du WP2 est de fournir aux officiers de police un système prototype pour collecter, traiter et afficher des informations concernant l’observation de divers objets mobiles.

Afin de remplir entièrement cet objectif, trois modules interconnectés doivent être construits.

Premièrement, un système multinodal pour le positionnement et le repérage d’objets ayant la capacité de se mouvoir est requis. Des appareils spéciaux et des algorithmes de gestion spatiale sont requis pour détecter avec précision des objets. Le second est un drone de patrouille aérienne autonome utilisé comme plateforme d’observation. Enfin, le dernier élément est une infrastructure de réseaux sans fil utile afin de réaliser les deux buts principaux du projet.

Tout cela, interconnecté, forme un système intégré centré sur un réseau. Ce système qui constitue un des sous-systèmes noyau du projet INDECT représente les yeux et oreilles du projet entier. Il appuie d’autres paquets de travail avec différentes données pouvant être utilisées plus en détail. C’est pour cela que le sous-système WP2 est en parfaite adéquation avec l’idée de « Système intelligent d’information, appuyant l’observation, la recherche et la détection pour la sécurité des citoyens en milieu urbain ».

 

Structure logique

Image88Vue d’ensemble du système :

L’objectif du système est de supporter les actions des officiers de police et d’autres services publiques grâce à des techniques et outils d’observation de nombreux objets mobiles. Ce but est réalisé en intégrant un large spectre d’appareils déjà utilisés et de nouveaux appareils réalisés qui peuvent surveiller les objets mobiles en créant un système hétérogène centré sur le réseau relié à de nombreux nœuds.

Le système INDECT consistera en de nombreux modules qui peuvent réaliser de nombreuses fonctions.A cause de cela, pour la réalisation effective les présents objectifs, le système est développé comme un système partitionné sensible aux événements extérieurs.

Chaque nœud du système peut être vu comme un composant indépendant effectuant ses fonctions et communicant avec les autres nœuds à propos des événements passés. Cette approche assurera que le système soit modulaire, ouvert et évolutif. Ainsi, de plus ample développements du système et l’ajout de nouveaux nœuds peut être réalisé très facilement. Cela assure que le système soit robuste et cela améliore le partage des informations. Le partage d’informations renforce ses qualités et aide à bâtir des situations pour les officiers de police. Par le partage des situations avec d’autres utilisateurs finaux, Ils pourront collaborer plus facilement et cela aura pour impact d’amélioré l’efficacité de leur travail.

Type de noeuds :

Du point de vue de l’infrastructure, les nœuds dans le système peuvent être divisés en groupes, et cela selon leur fonctions :

F1 nœuds qui assurent la capacité de communication du système (routeurs).

F2 nœuds qui collectent des informations grâce à leurs capteurs.

F3 nœuds qui traitent les informations, inclus : détection des événements, détection de liens entre les événements, etc.

F4 nœuds répondant aux requêtes et tâches des utilisateurs, collectes sous demande les informations d’autres nœuds, préparent les données pour leur affichage, etc.

F5 nœuds affichant des données aux utilisateurs (clients passifs).

F6 nœuds permettant à l’utilisateur d’interroger le système pour des informations spécifiques.

Bien sûr, chaque nœud du système peut effectuer plusieurs fonctions en même temps. Par exemple, un nœud peut collecter des informations et en même temps les (pré)traiter, rechercher des événements… Certaines fonctions seront combinées plus souvent que d’autres. Les combinaisons les plus communes sont :

  • collecter et traiter des données (F2, F3).
  • traiter des données et des tâches envoyées par l’utilisateur (F3, F4). Ces nœuds peuvent être vus comme des serveurs dans une conception typique de serveur-client.
  • afficher les événements et points d’entrée pour les utilisateurs (F5, F6). Ces nœuds peuvent être vus comme des clients dans une conception typique de server-client.

Chaque nœud nécessite une voie pour communiquer avec les autres nœuds. Donc, logiquement, on pourrait dire que chaque nœud peut agir comme un F1.

A un niveau plus élevé, on peut distinguer les nœuds suivants :

  • Nœuds de communication qui composent le réseau maillé et l’infrastructure de communication
  • Détecteurs :
  • caméras
  • détecteurs sans fil de surveillance
  • autres
  • serveurs, qui collectent les données depuis les détecteurs et le partagent avec les clients (utilisateurs)
  • applications « utilisateurs » qui agissent comme des points d’entrée du système.

 

Sous-système de communication

Idée générale :

Créer un système distribué a souligné la partie réseau du système qui est le noyau de n’importe quel système centré sur un réseau. Il est crucial pour un travail efficace que chaque nœud du système puisse communiquer avec les autres. Image90

 

La Figure 3 présente une vue générale de la disposition du réseau. Il est évident que ce réseau doit être hétérogène pour être capable de connecter différents nœuds qui sont dispersés dans différentes zones et avec différentes capacités de communication. On peut diviser les connections disponibles en plusieurs groupes :

-Un pivot rapide et puissant – un réseau filaire à large bande passante (10Mbps+, éventuellement 10Gbps entre les nœuds les plus importants), voire les deux, ou utiliser des réseaux existant tels qu’Internet qui possèdent déjà des systèmes de sécurité.

-un pivot sans fil – une connexion longue portée à 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 nœuds proches.

Le but de la connexion au pivot est de construire un réseau stable qui connecte tous les nœuds statiques en un même système. Ces nœuds peuvent alors agir comme des points de distribution pour les nœuds utilisant des connexions sans fil locales. Parce que le coût de construction et d’exploitation des connexions du pivot peut être élevé, il est naturel de placer de tels nœuds dans une zone et d’utiliser des connexions sans fil moins cher pour relier les nœuds proches au réseau.

En se basant sur la connexion, on peut diviser les nœuds en quatre classes :

nœuds pivots qui composent le réseau pivot (permettant seulement F1).

  • nœuds connectés directement au pivot. Ils sont toujours (échecs inclus) connectés au réseau.
  • nœuds statiques connectés grâce à un lien local aux nœuds pivots ou d’autres nœuds statiques. Ils créeront un réseau maillé qui peut couvrir une vaste zone avec seulement une simple connexion sans fil.
  • nœuds mobiles qui se connectent avec un lien local aux autres nœuds. Ces nœuds peuvent être divisés en deux groupes :
  1. les nœuds qui peuvent être connectés au réseau sur une longue période.
  2. les nœuds qui initialisent une courte connexion pour envoyer des données mais qui restent déconnectés le reste du temps.

En tête de ces connexions physiques, un réseau IP sera développé. Cela permettra l’utilisation de standards et d’algorithmes et protocoles connus. Chaque nœud peut dès lors être associé à une unique adresse IP et tous les nœuds peuvent alors initialiser une connexion TCP ou UDP vers des nœuds ayant un accès avec une IP.

  • Abonnement : les nœuds intéressés par la réception d’informations spécifiques peuvent envoyer une requête au routeur pour les obtenir. Par exemple, le serveur peut demander toute les informations concernant la position des appareils tracés. Lorsqu’un nœud traceur placera un message dans le routeur, celui-ci sera automatiquement envoyé au serveur.
  • Modes de messages : un message peut être traité de différentes façons, comme envoyer un contenu à tout ceux qui le demandent. Il peut être mis en attente ou supprimé lorsqu’aucune requête n’est présente pour de telles informations. Il peut être supprimé après envoi ou gardé en mémoire pour de futurs abonnements.

Modèles de communication

Echantillons des cas de communication :

  • Tracer un objet mobile

1.          Le traceur obtient sa position à partir d’un capteur GPS (F2).

2.          Le traceur décide s’il doit envoyer sa position au serveur (F3).

3.          Il écrit et met en attente un nouveau message.

4.          Quand il atteint un lieu où la communication est possible, il envoie les messages en attente à un point d’accès.

5.          Quand le point d’accès réceptionne le message, il le fait suivre aux nœuds de destination (F1).

(a) Optionnellement, le point d’accès peut l’envoyer à un routeur ou attendre qu’un nœud demande l’envoi de ce message.

6. Un nœud de traitement (serveur) reçoit le message et agit en conséquence (le garde en mémoire, informe le client, etc.) (F3).

 

  • Demande d’information concernant les appareils tracés

1.          L’application client envoie un message au serveur demandant de s’abonner aux informations d’un appareil tracé.

2.          Les serveurs peut ensuite envoyés les requêtes d’abonnement aux nœuds concernés pour répondre du mieux possible à la demande du client (F4).

3.          A chaque fois que le serveur reçoit des informations, il envoie un message au client (F4).

4. Le client reçoit les informations et les présente aux utilisateurs sous forme d’une carte par exemple (F5, F6).

Sécurité

Parce que les nœuds font circuler des données sensibles, tout ce qui transite par le réseau doit être crypté. Les protocoles d’encryptage connus et largement utilisées doivent être utilisés ici pour réduire le risque qu’une personne sans autorisation accède aux données.

Le second problème est l’authentification. Comme plusieurs nœuds opèrent à distance, le système doit être immunisé contre des tentatives d’usurpation d’identité de nœuds par d’autres. Une infrastructure PKI devrait être utilisée pour identifier chaque nœud dans le système.

 

Environnement de programmation

A cause de la nature hétérogène du système, un grand nombre de langage de programmation et d’environnement seront utilisées. Dans ce paragraphe, nous avons réunis un ensemble de règles à suivre.

  • Nœuds  capteurs (F2)

L’environnement dépend énormément de l’appareil utilisé.

  • Nœuds de traitement (F3, F4)

-doivent fonctionner sous les environnements MS Windows et Linux.

– dans certains cas ils devront fonctionner seulement avec un des systèmes.

-doivent être développés en .NET, de préférence en C#.

-Mono project sera utilisé pour les lancer sur Linux et les autres systèmes Unix.

-Si ces applications fonctionnent sur des systèmes embarqués, elles doivent être développées sous d’autre environnements (ANSI, C, C++ …).

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

Un environnement managé fournit un environnement Runtime pour des applications qui traitent d’organisation de mémoire. Les environnements moderne inclue .NET, Java, Python, Ruby et d’autres.

  • Application pour les utilisateurs finaux (F5, F6)

-doivent fonctionner sous MS Windows (XP ou plus récent).

-commode utilisés avec d’autres système (Linux ou Mac), mais non requis.

-doivent être développés en .NET, de préférence en C#.

 

La Figure 3 présente une vue générale de la disposition du réseau. Il est évident que ce réseau doit être hétérogène pour être capable de connecter différents nœuds qui sont dispersés dans différentes zones et avec différentes capacités de communication. On peut diviser les connections disponibles en plusieurs groupes :

-Un pivot rapide et puissant – un réseau filaire à large bande passante (10Mbps+, éventuellement 10Gbps entre les nœuds les plus importants), voire les deux, ou utiliser des réseaux existant tels qu’Internet qui possèdent déjà des systèmes de sécurité.

-un pivot sans fil – une connexion longue portée à 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 nœuds proches.

Le but de la connexion au pivot est de construire un réseau stable qui connecte tous les nœuds statiques en un même système. Ces nœuds peuvent alors agir comme des points de distribution pour les nœuds utilisant des connexions sans fil locales. Parce que le coût de construction et d’exploitation des connexions du pivot peut être élevé, il est naturel de placer de tels nœuds dans une zone et d’utiliser des connexions sans fil moins cher pour relier les nœuds proches au réseau.

En se basant sur la connexion, on peut diviser les nœuds en quatre classes :

– nœuds pivots qui composent le réseau pivot (permettant seulement F1).

– nœuds connectés directement au pivot. Ils sont toujours (échecs inclus) connectés au réseau.

– nœuds statiques connectés grâce à un lien local aux nœuds pivots ou d’autres nœuds statiques. Ils créeront un réseau maillé qui peut couvrir une vaste zone avec seulement une simple connexion sans fil.

– nœuds mobiles qui se connectent avec un lien local aux autres nœuds. Ces nœuds peuvent être divisés en deux groupes :

– les nœuds qui peuvent être connectés au réseau sur une longue période.

– les nœuds qui initialisent une courte connexion pour envoyer des données mais qui restent déconnectés le reste du temps.

En tête de ces connexions physiques, un réseau IP sera développé. Cela permettra l’utilisation de standards et d’algorithmes et protocoles connus. Chaque nœud peut dès lors être associé à une unique adresse IP et tous les nœuds peuvent alors initialiser une connexion TCP ou UDP vers des nœuds ayant un accès avec une IP.

 

  • Connecter les segments sans IP

 

Malheureusement, tous les nœuds ne peuvent pas supporter l’IP. Il y en aura donc qui seront incapable de supporter les connexions IP, en particulier ceux qui restent déconnectés et qui se connectent au réseau pour envoyer ou recevoir de courtes salves de données.

Pour de tels nœuds, des points d’accès (AP) doivent être développés pour permettre le transfert de données depuis et vers eux. Dans de tels cas, le nœud qui agira comme un point d’accès possèdera une adresse IP et sera disponible pour d’autres nœuds dans le réseau. Si un nœud veut envoyer des données à des nœuds déconnectés, il devra contacter l’AP et lui laisser le message qui sera transféré dès que possible.

Il pourrait exister plusieurs AP pour les mêmes modules déconnectés. 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 nœud. Il doit toujours obtenir les messages en attente.

On peut donner comme exemples  :

– communications radios manuelles courtes et longues distances.

– communication Bluetooth locale.

– communication SMS dans le réseau cellulaire.

De telles connections seront surement utilisées dans le système INDECT.

 

  • Communication entre les modules

La communication entre les nœuds peuvent généralement peut généralement être réalisées sur la base de deux modèles : l’un qu’on peut appeler « à flux constant », l’autre qu’on peut appeler « géré par messages ».

Dans le modèle « à flux constant », les nœuds ouvrent des connections (cad. TCP) entre eux et échange de long flux de données. Ce type de système est commun sur Internet. Les clients ouvrent une connexion sur le serveur et échangent un flux à double sens de données. Cela fonctionne bien quand le réseau est stable, et que la connexion peut rester ouverte pendant le temps que nécessite l’opération et que les serveurs transmettent le message. Plus le temps le serveur requière de temps pour préparer sa réponse, plus le réseau est instable, et plus de problèmes sont à prévoir dans le modèle. Le plus souvent, quand la connexion est interrompue, l’ensemble de la procédure doit être relancé, incluant la collecte des données par le serveur.

Dans un modèle « géré par messages », l’ensemble des communications entre les nœuds est effectuée par messages. Les nœuds peuvent s’envoyer des flux de données mais par messages. Chaque requête client, réponse du serveur, etc. est envoyé sous forme de message (un peu comme un email ou une lettre). Avec un tel modèle, les opérations précédentes peuvent être vues de cette façon :

-le client prépare un message décrivant sa requête.

-le message est envoyé au serveur.

-le serveur reçoit le message, le traite, et prépare une réponse sous forme d’un autre message.

-le serveur envoie la réponse au client.

-le client lit le message de réponse à sa requête.

Il est important de noter que cet ensemble d’opération est asynchrone. Le transfert de message peut traverser plusieurs connexions entre ces deux nœuds, si les listes d’attente d’envoie de message peuvent résister au déconnections temporaires, indisponibilités de certains nœuds etc. De plus, les messages n’ont pas à être transmis directement aux nœuds concernés. Ils peuvent être mis en attente, et suivis par des nœuds intermédiaires. Ce modèle est très utile dans des systèmes distribués, où les nœuds peuvent être déconnectés pendant de longue périodes ou disponible par des réseaux très hétérogènes. Quand on prend en compte les nœuds qui se connectent au réseau pour de courts transferts de données, on remarque les faiblesses du modèle à flux constant pour de telles opérations. Dans le cas d’un système géré par message, les points d’accès peuvent mettre en files d’attente les messages pour être envoyés à des nœuds actuellement déconnectés, et les envoie donc quand celui-ci est connecté. Cela est vrai aussi pour les messages envoyé par les nœuds : ils peuvent être mis en files d’attente par les points d’accès et envoyé longtemps après la déconnexion du nœud. Dans un système géré par message on défini :

Routeur de messages : un lieu abstrait, point central des échanges de messages. Les créateurs de messages les place dans un routeur. C’est le composant responsable des envoie de messages aux différents destinataires. Un routeur est responsable du traitement des messages et d’en sécuriser l’accès. Il peut optionnellement garder en mémoires des messages pour qu’ils ne soient pas perdus.

Noeuds physiques

Image91

Dans le cadre d’INDECT, des nœuds seront conçus et testés avec des prototypes :

  • UAV, drone pour une surveillance aérienne,
  • Segment terrestre pour les UAV : une base pour les opérations et le contrôle des drones,
  • Salle de commande : un centre pour commander, collecter et présenter les informations de tous les nœuds du système WP2.
  • Nœuds de commande mobile : permet des fonctions similaire aux fonctions de la salle de commande.
  • Serveur : responsable de toutes les opérations des nœuds, peut être distribué.
  • Traceur GPS/GSM : appareil capable de tracer la position d’un véhicule et de rapporter sa position.
  • Traceur mobile : un appareil se déplaçant dans un réseau quadrillé.
  • Capteurs multifonction : un nœud capable de se connecter à différents capteurs et appareil pour créer un réseau quadrillé.

Tous les nœuds sont décrits plus en détail dans la figure 5 qui montre l’agencement des nœuds dans une vue générale du système.

UAV (drones)

Réalise (F2) et éventuellement (F3).

  •  Composants

Les composants principaux d’un UAV sont :

-aéronef  à propulsion

-système embarqué avec pilote automatique

-cardans stabilisés avec capteurs visuels

-capteurs de différentes fonction (ex : chimique)

-système de communication

Pour les opérations entre les composants internes, référez-vous à la figure 6.

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

Image92

  • Aéronef à propulsion

Ce composant consiste en :

hélices ou rotors ; moteur (électrique ou essence) ; source d’énergie du moteur (batterie ou essence) ; générateur électrique pour moteur essence ; aéronef avec moteurs actionneurs.

Les facteurs principaux influant sur la conception de l’UAV est la vitesse maximum et l’endurance.

Image93Image94

  • Systèmes embarqués

Les systèmes embarqués ont comme fonction de permettre le vol autonome de l’UAV :

1.Contrôle des moteurs et actionneurs

2.Contrôle du vol

3.Navigation

4.Maintien de la trajectoire et du statut de la mission

Les systèmes embarqués peuvent aussi :

– Traiter des données de capteurs (incluant des algorithmes avancés de traitement visuel)

– Archiver les données (de façon limitée)

– Compresser les données avant de les envoyer au segment terrestre.

L’UAV Burzyck est équipé de 3 ordinateurs :

– Un ordinateur de contrôle de vol. C’est un ordinateur en temps réel basé sur la technologie ARM. Il est responsable du contrôle des moteurs et actionneurs, du vol et des capteurs (en combinant les données de différents capteurs, il détermine l’état actuel de l’environnement et de l’aéronef). Il sera conçu et construit par PUT. Image96Image95

– l’ordinateur de performance utilise des architectures système x86. Ils sont responsables des la navigation, de la mission et du traitement des données visuelles.

– Le module d’encodage vidéo est un ordinateur conçu pour compresser les flux vidéo.

Les systèmes embarqués communiquent entre eux via des routeurs Lan ou des câbles Ethernet. Le premier protocole garantit une réponse rapide, le second une large bande-passante. Ces deux technologies sont utilisées dans le but d’en tirer le plus grand potentiel.

L’architecture est basée sur le passage de messages entre les ordinateurs et les capteurs. Cette approche est très ouverte et permet de remplacer facilement les différents modules, d’amélioré les composants ou d’ajouter 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 l’image (réduire les vibrations).

Le principal compromis architectural à trouver pour le cadran est la taille des capteurs embarqués et le degré de liberté du cadran. Plus le degré de liberté est élevé, plus la taille des capteurs doit être réduite. La gamme de capteurs pour le cadran inclus :

– Caméras optiques

– Caméras nocturnes (proche de l’infrarouge)

– Caméras thermiques (infrarouge)

– Télémètres lasers

Des cardans optiques et thermiques seront construits pour l’UAV Burzyck. Cependant, n’importe quel constructeur peu construire un cardan, tant que le support et le système de communication sont compatibles.

Les cardans ont 2 degrés de liberté : le roulis et l’axe de tangage. Ils sont représentés sur la figure 9. Le cardan à une masse de 650g. Image97

  • Capteurs à usage général

Un UAV peut avoir un support de capteurs à usage général permettant d’installer des capteurs fabriqués par un fabriquant extérieur. Ce type de système doit avoir une interface publiée (pièces détachées et logiciels).

  • Système de puissance

Un UAV est équipé du centre de gestion d’énergie qui mesure la consommation de tout le système et l’énergie disponible. Il peut éteindre certains systèmes ou composants de l’UAV ce qui permet un usage intelligent de l’énergie disponible. Il est très utile en cas de dysfonctionnement – les composants peuvent être éteints dans les cas d’urgence. Cela permet aussi de calculer le temps restant pour les opérations de l’UAV (dans différents nœuds).

  • Sous-système de communication des UAV

Selon la définition de la section 1.2, l’UAV peut être un nœud (F1, F2, F3, F4).

Le système de communication UAV possède 3 liaisons principales :

UAV – Segment terrestre L’UAV rassemble de grandes quantités de données – particulièrement des données visuelles. Ce lien exige une communication à large bande-passante. Bien sûr l’UAV peut effectuer une mission sans communication, mais cela est  rare dans des applications civiles. Le segment terrestre envoie les données au système centré sur le réseau

UAV – UAV  La communication (F1) peut être faite de 2 façons – la retransmission de données par large bande-passante à haut débit ou la retransmission de courte bande-passante. À l’heure actuelle nous supposons, qu’il n’y aura aucune retransmission à haut débit.

UAV – Nœud terrestre La communication (F1) permet à UAV d’étendre ses capacités de perception. Il peut être aussi utilisé pour étendre les capacités de communication du système. Les données à haut débit de l’UAV peuvent être reçues par des utilisateurs autorisés sur terre. Les capteurs terrestres peuvent envoyer des données restreintes/faibles à UAV.

Image98

Segment terrestre de l’UVA

Image99

Le segment terrestre est une partie du système qui permet aux UAV de fonctionner à partir de la Terre.

Cela pourrait être mobile (monté sur un véhicule ou porté par le personnel).

Les principales fonctions du segment terrestre sont :

1. Planifier les missions de l’UAV ou transmettre les missions provenant de la Salle de Commande à l’UAV.

2. Communiquer avec l’UAV – le segment terrestre est le point principal de communication.

3. Direction de l’UAVs sur missions :

(a) Obtenir un flux vidéo en temps réel et la télémétrie

(b) Afficher les paramètres de mission

(c) Contrôler les paramètres de mission

4. Aider l’UAV à décoller et à se poser : la plupart des UAVs ont besoin d’un décollage spécialisé et d’un équipement d’atterrissage spécialisé.

Le segment terrestre pourrait être mobile ou stationnaire. Le segment terrestre stationnaire est intégré à la Salle de commande et est un module de logiciel.

La version mobile du segment terrestre consiste en :

• Un traqueur d’antenne avec un système de communication. Le design proposé d’un système de traqueur est montré sur la figure 12.

• Un ordinateur solide avec un logiciel d’opérateur.

• Un système d’atterrissage visuel – un système novateur qui utilise des images de caméras embarquées pour tracer l’UAV et le site d’atterrissage.

Cet équipement est porté dans un sac à dos spécialement conçu à cet effet. Il permet à 2 personnes de porter l’UAV et le segment terrestre. Le traqueur d’antenne et le système d’atterrissage visuel seront développés par WP2.

Le segment moulu doit aussi pouvoir faire des fonctions de maintenance incluant :

1. Maintenance de véhicules – Par exemple nettoyage, rechargement, remplacement des parties.

2. Mise à jour de logiciel et de matériel dans les véhicules.

Ceci n’est pas exigé pendant l’opération standard.

 

Salle de Commande Image100

Réalise les fonctions : F5, F6.

Un centre pour commander la direction, réunir et afficher les informations  de tous les nœuds de WP2. Il doit fournir :

1. Console (s) d’opérateur

2. Affichage mural pour une vue d’ensemble de la situation

L’idée générale de la Chambre de Commande est présentée à la Figure 13. La chambre contient les consoles de quelques opérateurs, des affichages muraux multiples et d’autres dispositifs d’impression/communication.

La console d’opérateur devrait fournir :

1. Aperçu  des opérations du système :

(a) Statut général du système (opérationnel, problèmes, éteint)

(b) statut des nœuds incluant :

i. État des serveurs, dépistage de performance,

ii. État des nœuds déconnectés – la dernière communication vue, la suivante attendue.

(c) Liste des requêtes.

2. Direction des nœuds :

(a) un module pour chaque sorte de nœud sera fourni permettant :

i. De contrôler le comportement de ces nœuds, spécifique à chaque nœud,

ii. D’envoyer des ordres aux nœuds éloignés,

iii. De réunir les renseignements provenant des nœuds.

(b) Enregistrer de nouveaux nœuds au système,

(c) Désinscrire des nœuds enlevés (nœuds déclassés, nœuds compromis, etc.)

3. Présentation de la situation tactique :

(a) Carte avec une position et un état de tous les nœuds,

i. Possible avec un présent prévu et des positions futures.

(b) Alertes sur les événements découverts dans le système (les exemples sont incluent, mais ils ne sont pas limités au : mouvement des objets, sorties/entrées des zones, découverte des objets),

(c) Résumé des opérations conduites.

Chaque opérateur est équipé d’une application avancée pour l’assistance de commande qui permet d’inspecter la situation tactique. Ce logiciel peut être spécialisé pour correspondre aux besoins de chaque opérateur.

Il est possible de créer son propre environnement de travail, qui comprend toutes les informations nécessaires en temps réel. Il permet aussi de combiner différentes couches et objets sur une même visualisation. Il est entièrement intégré avec le système central de réseau  présenté dans ce livrable. Ceci permet de collecter et d’analyser une grande quantité de données venant de différents types de nœuds. Qui plus est, deux opérateurs peuvent travailler ensemble sur un cas et interagir l’un avec l’autre.

Image101

Un système d’autorisation pour les utilisateurs devrait permettre divers niveaux d’accès. Par exemple, un utilisateur avec un mot de passe aura un accès plus restreint qu’un utilisateur avec une carte d’accès. Généralement, on préfèrera une carte d’accès

Commande à distance des nœuds

Réalise 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 l’affichage d’informations et le contrôle de nœuds spécifiques comme demandé par un opérateur spécifique (ou une opération). L’affichage de la situation tactique devrait être réduite pour n’afficher que les informations importantes et cela afin d’accroitre la lisibilité.

Un aperçu du système peut être transférer sur le module de commande à distance si nécessaire ou plus pratique.

Serveur – responsable des opérations de tous les nœuds

Réalise les fonctions : F3, F4.

Le server est défini comme une infrastructure requise pour que les logiciels fonctionnent avec une performance optimale et une grande disponibilité.

Le serveur devrait :

1. Etre capable de gérer un usage CPU de tout les logiciel en traitement nécessaire pour collecter et traiter les informations de tous les nœuds.

2. N’avoir aucun point d’échec – les unités CPU, les disques, l’énergie, la connexion avec le réseau devront être en surnombre.

3. Etre sécurisé (composants requis définis après)

Les logiciels du serveur devront être en capacité de :

1. Accepter les connections et messages de tous les nœuds du système

2. Délivrer ces messages aux modules responsables des nœuds qui devraient :

(a).Stocker tout/la majorité des informations reçues,

(b).Détecter l’occurrence d’événements requêtes des utilisateurs,

(c).Rapporter ces événements aux utilisateurs sous forme d’alertes.

3. Répondre aux requêtes des clients sur l’état actuel des nœuds, les dernières informations reçues et l’historique des réceptions. Image102

Le serveur WP2 est développé autour d’une architecture Return développée par PUT. Return est une application du serveur utilisant un cadre de programmation .NET et fonctionnant sur différentes plateforme – Windows et Linux. L’utilisation de Return permet une modularité et un développement facile du serveur. Basé sur une architecture cadre, le serveur WP2 est divisé en plusieurs modules. Chaque module est responsable d’une partie des fonctionnalités du serveur. Les modules échanges des messages lorsque des données ou des traitements réalisés par d’autres modules sont nécessaires.

Le serveur Return fournit toutes les infrastructures nécessaires pour le passage des messages, les mécanismes de sécurité et de communication – basés sur des messages – avec les autres nœuds. Optionnellement, d’autres modules peuvent fournir leur propre méthode de communication si nécessaire. Les fonctions des serveurs sont partagées dans les différents modules.

Le système central de Return est LightBus – un routeur de haute performance dont la tâche et de permettre la communication entre les différents modules. Toute communication entre les nœuds est basée sur des messages et des modèles de publication et d’abonnement. Chaque module fonctionne indépendamment des autres, utilisant ses propres processus et ressources. Ils demandent au routeur de collecter les messages qui les intéressent. Quand un module a de nouvelles données ou des résultats d’un traitement, il les publie comme message pour le routeur.

Le routeur délivre alors ces messages aux modules s’étant abonnés à ces données.

Image103

Ce modèle de communication permet plus d’indépendance entre les modules. Cela donne deux avantages de la plus haute importance. Premièrement, aucune ressource ne lance de code d’autres modules. Cela accroit grandement la fiabilité des modules, réduit les problèmes de concurrence d’accès aux variables et données et permet des tests plus simplement.  Ensuite, les modules sont découplés, parce qu’ils ne communiquent pas directement mais avec l’aide du routeur. Les modules publient des données qu’ils produisent et s’abonnent à d’autres flux. Les publicateurs et abonnés n’ont pas à être en relation. La figure 16 présente cette idée sous forme graphique.

Les fonctionnalités du serveur sont réparties dans les modules suivants :

1.          GisProvider

GisProvider est un module multifonction responsable de l’accès de la base de données géographique. C’est un utilitaire qui fourni des données GIS aux autres modules et au centre de commande afin d’afficher 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 données à propos des objets du monde réel. La liste INDECT concernant ces objets inclus : UAVs, traceurs, unités blue force,  objets tracés. ( non exhaustif)

Ce module est responsable de garder en mémoire les informations sur les objets dans la base de données et fournir un accès à ses données dans le futur.

Les objets sont identifiés par une séquence URI. L’URI est une structure hiérarchique où tout objet est identifié et placé dans une arborescence de tous les objets. Les niveaux hiérarchiques et identifiants sont basés sur des séquences et séparés par le caractère « / ».

3. IndectWebService

Les données collectées et traitées par les systèmes WP2 doivent être disponibles en dehors du WP2 – principalement sur le portail WP6. Les connexions avec le portail seront disponibles via le SOAP WebService. L’exécution de ce Webservice sera dans un module de retour d’IndectWebService. Le contrat de l’interface est en discussion avec le WP6.

4. Stockage Vidéo

Les flux vidéo des UAVs et éventuellement d’autres nœuds sont stockés sur des disques dans le serveur. Ce module fourni un accès à ces flux par un visionnage hors ligne des contenus par les utilisateurs autorisés. Cela permet un accès aux vidéos selon les dates et sources des vidéos et un visionnage depuis la Salle de Commande et éventuellement du WP6.

5. Gestionnaires de nœuds

Chaque nœud tracé doit être géré par le serveur. Une liste de nœuds tracés avec leur certificat et identification doit être stockée et être mise à disposition pour que les nœuds autorisés fournissent des informations. Une liste de révocation de certificats doit être particulièrement gérée. En plus de cela, la configuration de tous les nœuds à capteurs multifonctions doit être accessible pour les utilisateurs ainsi que les différentes modifications apportées à l’expédition vers d’autres nœuds lorsque cela est possible.

Traceurs GSM-GPS

C’est un petit appareil muni d’un récepteur GPS pour tracer les objets auxquels il est attaché.

L’appareil utilise un module GPS de haute performance avec une antenne omnidirectionnelle qui protège de toute interférence, incluant les signaux à trajectoire multiple. Le module est capable de fonctionner en autonomie dans un mode économiseur d’énergie, par exemple avertir de sa position par période de temps.

Le module de communication GSM est intégré avec un processeur qui exécute tout les codes de l’appareil. Cela permet une meilleure intégration et rend possible un contrôle total de la partie communication et des tâches des logiciels. L’antenne intégrée est une penta-bande supportant 5 bandes de fréquences GSM, ainsi une mise à jour vers la 3G sera possible à l’avenir. Cependant, généralement, la transmission GPRS/EDGE est suffisante tant que la vitesse du flux de données reste un avantage sur la 3G – ayant une basse consommation d’énergie. Optionnellement, le traceur peut utiliser des transmissions SMS au lieu de la GPRS/EDGE quand de telles connexions peuvent être réalisées. L’architecture GPRS/EDGE est représentée dans la figure 17. Le but étant que le traceur GPRS/EDGE soit opérationnel aussi longtemps que possible, le module peut fonctionner dans différents modes pour économiser son énergie c’est-à-dire : Image104

1.          Rester en ligne en transmission de données continuelle ou périodique par GPRS/EDGE. Les positions de l’objet peuvent être sauvegardées sur une mémoire interne pour des synchronisations périodiques avec le serveur. Les positions ne sont pas envoyées si l’objet est immobile pour conserver de l’énergie et ne pas submerger le server de données.

2.          Rester en ligne seulement lorsque la position de l’objet est en dehors d’une certaine zone – appelé mode ancre. Ce mode peut améliorer le temps d’opération.

3. Désactiver la radio et se connecter seulement lors d’événements

(a) Périodiquement pour rapporter une position, par exemple toute les 6h.

(b) Lors du mouvement de l’objet et qu’il excède un certain seuil préprogrammé.

4. Rester hors ligne durant une période de temps préprogrammée. Cela permet d’atteindre un temps d’arrêt de plusieurs mois.

5. Envoyer un signal GPS détaillé au satellite dans le mode démarrage, c’est-à-dire quand le module est attaché à l’objet tracé. Dans les autres modes, seules les données les plus importantes sont envoyées automatiquement pour réduire l’utilisation de la mémoire du module. Image105

Les modes peuvent être modifiés à distance n’importe quand. Tout autre option de configuration comme permettre le transfert de données pendant le mouvement de l’objet sont aussi accessibles à distance.

L’appareil est muni d’un gestionnaire d’énergie responsable de charger la batterie, gérer son état et s’assurer que le module GSM (le module qui consomme le plus d’énergie) soit correctement alimenté, même sous de basses températures où les performances de la batterie sont moindres. Les informations sur l’état de la batterie sont périodiquement envoyées au serveur, pouvant ainsi être géré par un opérateur. Le diagramme d’architecture du traceur GPS/GSM est représenté dans la figure 18. Image106

 

Traceurs  mobiles Image107

Réalise les fonctions : F2.

C’est un petit appareil utilisé pour tracer les objets. Il doit être conçu pour rendre possible sa petite taille et un long temps d’opération sans charger la batterie.

Contrairement aux traceurs GPS/GSM, le traceur mobile utilise le réseau maillé construit avec plusieurs nœuds multifonction pour la communication et l’estimation de la position de l’appareil.

L’appareil possède un transmetteur radio pour transmettre les données et recevoir des commandes. Il utilise un sous-système de communication pour les  courtes distances pour envoyer et recevoir des données aux différents nœuds du réseau maillé ou d’autres nœuds mobiles. Le schéma de communication net présenté sur la figure 19.

La position du traceur est obtenue en analysant les informations relatives à l’entrée et la sortie de certaines zones. Optionnellement, l’appareil peut être équipé d’un récepteur GPS  pour obtenir des informations plus précises sur la localisation de l’objet. Dans ce cas, l’appareil aura aussi un accéléromètre pour éteindre le récepteur lorsque l’objet est immobile ce qui aura pour conséquence de réduire la consommation d’énergie et ainsi augmenter le temps de fonctionnement.

L’architecture du traceur mobile et représenté dans la figure 20.

 

Capteurs multifonction

Réalise les fonctions : F1, F2 et d’autres avec des ajouts.

Un nœud multifonction. Il est équipé avec un sous-système de communication à courte distance pour établir une connexion avec les autres nœuds du système. Ils sont placés dans les villes. L’un des objectifs de ce nœud et la gestion du trafic et la reconnaissance de toutes les plaques d’immatriculation des véhicules en circulation. Ils devraient aussi coopérer avec les nœuds voisins le réseau pivot. De cette façon, un set de nœuds multifonction crée un réseau, où on peut accéder à tous les nœuds avec un passage de message. Le schéma d’un tel réseau peut être vu dans la figure 19. Chaque nœud contient la liste des véhicules demandés, par exemple les véhicules volés. Le système de reconnaissance des plaques d’immatriculation fonctionne sous deux modes TOUS ou RECHERCHES. En mode TOUS, le nœud rapporte l’apparition de chaque véhicule, alors qu’en mode RECHERCHES le nœud reporte l’apparition de véhicule sur la liste des véhicules recherchés.  De plus, d’autres sous-systèmes peuvent être ajoutés au nœud, incluant :

1.Communication longue distance – un nœud peut être connecté au réseau pivot, avec une connexion sans fil ou câblée à bande-passante, fonctionnant dans ce cas comme un point d’entrée vers le réseau maillé. De plus, un tel point d’entrée est possible et conseillé pour la fiabilité du réseau maillé.

2.Caméras vidéo pour observer et détecter différents types d’objets.

3.Détecteurs de son

4.Station météo Image108

 

Le schéma du nœud est présenté sur la figure 21. L’unité centrale du capteur multifonction est composé de :

– Carte Mère : responsable de la gestion de l’énergie et du routage des paquets de données à l’intérieur du nœud. Elle peut posséder des extensions capteurs.

– Module photographique : responsable du traitement des images réalisé par le capteur.

– Module de communication : un set d’appareil sans fil qui permet la communication aussi bien entre les nœuds du réseau qu’avec les objets mobiles.

 

Interfaces et protocoles de communication :

Dans le but d’assurer une communication adéquate et fiable dans le WP2, une série d’interfaces et de protocoles de communication ont été développés. La section suivante couvre les différentes interfaces en les appareils et le sous-système WP2 :

 

UAV <-> Serveur WP2

Réseau : Lien données COFDM

Logiciel : Interface SI.Log2, Interface SI.Video

 

Capteurs multifonction <-> Serveur WP2

Réseau : Ethernet/IP

Logiciel : Interface SI.1

 

Traceur mobile <-> capteurs multifonction

Réseau : radio courte distance

Logiciel : Interface SI.2

 

Traceur GPS/GSM <-> Serveur WP2

Réseau : GPRS/EDGE/HPSA

Logiciel : Interface SI.2

 

Serveur WP2  <-> Portail WP6

Réseau : Ethernet/IP

Logiciel : Interface SI.WS1 SOAP WebService

 

Puisque ces appareils sont utilisés par les forces de police, seule les informations les plus importantes seront données. Les protocoles exacts sont confidentiels pour assurer la sureté du procédé et sera donné aux personnes autorisées sous-requête. Toutes les communications sont encryptées.

 

Communication entre l’UAV et le serveur WP2

  • Flux vidéo de l’UAV

Le signal vidéo des caméras est compressé par un module d’encodage vidéo. Un module commercial tel qu’utilisé actuellement pourrait compresser en format MPEG et MPEG-4. La compression MPEG est moins efficace en terme de bande-passante mais est robuste et ne cause aucun délai de réception. Parce qu’un UAV en vol est très dynamique et que l’image change très rapidement, la plupart des bénéfices du MPEG-4 sont perdus. Ainsi, le système de compression se concentre sur le MPEG. Le délai d’un flux MPEG est à peu près de 15 ms. La résolution du signal est de 640×480 ou 704×480, selon la caméra.

 

  • UAV et télémétrie des charges utiles

Le protocole de télémétrie est un protocole sans connexion basé sur des datagrammes UDP. La structure du protocole est basée sur le passage de messages. Pour le moment, de tels messages prévoient :

Position et état : ce message est utilisé pour obtenir la position et l’état de l’UAV, incluant son orientation et sa vitesse.

Surfaces de contrôle : ce message contient l’état des surfaces de contrôle de l’UAV, incluant les machines de vitesse, rabats, etc.

Statut du cardan : ce message défini l’orientation et mode d’opération du cardan.

Contrôles de base du cardan : ce message établit les contrôles de base du mouvement du cardan.

Contrôles visuels du cardan : permet le contrôle du cardan en mode visuel.

Statut du cardan en mode visuel : obtient des messages de statut du système de traceur visuel.

Contrôle du cardan en mode traceur mobile : contrôle les messages envoyés au cardan en mode traceur mobile.

Consommation d’énergie : ce message est utilisé pour obtenir la consommation courante et totale de l’UAV.

Les informations de ces messages sont disponibles pour l’opérateur de l’UAV.

 

  • UAV et planification des missions

Les missions sont définies dans une structure en arborescence dans laquelle les tâches sont un objectif concret (ex : voler d’un point A à un point B) ou une composition de sous-objectifs. Les messages de planification de mission sont définis de façon récursive : un message peut contenir d’autre messages.

Série d’objectifs : ce message devrait être utilisé pour les objectifs consistant en une suite d’objectifs à exécuter dans un ordre précis.

Set d’objectifs : ce message devrait être utilisé pour définir un objectif consistant en une série d’objectif dont l’ordre est défini par la requête. L’ordre peut être défini par exemple pour minimiser les distances parcourues.

Objectif à état limité : ce message devrait être utilisé pour définir un objectif en série d’objectif effectuée dans un ordre dépendant de l’apparition d’événements, éventuellement plusieurs fois.

Objectif de vol selon une cible : ce message devrait être utilisé pour définir un objectif de vol jusqu’à un point.

Objectif de vol selon un segment : ce message devrait être utilisé pour définir un objectif de vol le long d’un segment.

Objectif de patrouille Ce message devrait être utilisé pour que l’UAV patrouille autour d’une position donnée.

Objectif de couverture polygonale Ce message devrait être utilisé pour définir une zone de couverture visuelle où l’UAV fournira des flux vidéo.

Position Ce message devrait être utilisé pour définir une position géographique.

Altitude Ce message devrait être utilisé pour définir une altitude requise.

Vitesse Ce message devrait être utilisé pour définir une vitesse requise.

Transition Ce message devrait être utilisé pour définir une transition dans l’objectif à é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 données collectées par le système.

Cadre standard Ce cadre englobe tous les autres cardes envoyés ou reçus par les nœuds multifonctions.

Cadre d’information Ce cadre permet de reprogrammer les nœuds dans les airs.

Traceur mobile Ce cadre est utilisé pour la transmission des données depuis des appareils qui tracent les véhicules mobiles.

Cadre de reconnaissance de plaque d’immatriculation Ce cadre est utilisé pour la communication avec le module de reconnaissance de plaque d’immatriculation. Il peut être utilisé pour reporté l’apparence du véhicule ou exécuter 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 réseau radio à courte portée.

Balise Ce cadre est envoyé périodiquement par une station mère afin d’informer les traceurs à portée de quelle station mère il s’agit.

Requête Ce cadre permet aux traceurs d’envoyé des informations (sans la requête adéquate, les traceurs n’émettent aucun cadre).

Statut Cadre qui englobe les informations envoyées 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 réseaux GSM existants (GPRS/EDGE/SMS).

Configuration Ce cadre est envoyé aux traceurs pour établir le mode de fonctionnement approprié.

Réponse Ce cadre est envoyé en réponse à la requête de changement de mode de fonctionnement.

Echec Ce cadre indique des problèmes dans le changement de mode de fonctionnement.

Installation Ce cadre contient toutes les données en détails de tous les satellites GPS vue par le système.

Position Ce cadre est envoyé par le traceur avec ses positions passées et sa position courante.

Statut Ce cadre contient les informations sur les statuts des signaux GPS/GSM et les données concernant les stations BTS détectées par l’appareil dans son voisinage.

Batterie faible Ce cadre est envoyé lorsque la batterie interne est faible.

SIM prépayé : Ce cadre est envoyé quand une carte SIM prépayée est installée dans un traceur GPS/GSM.

Mise en mouvement : Ce cadre est envoyé pour indiquer que l’objet commence à se déplacer.

Arrêt du mouvement : Ce cadre est envoyé pour indiquer que l’objet arrête de se déplacer.

 

Communication entre le serveur WP2 et le portail WP6

Ce protocole est utilisé pour la communication avec le portail WP6. A l’avenir, quand l’intégration du projet sera à maturité, il y aura un set de messages prévu 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 données à propos d’objets GIS du portail WP2.

Obtenir des objets pour lister les objets dans une région géographique spécifiée, avec des critères spécifiques, alors les objets sont visibles depuis le portail.

 

Intégration

Cette section décrit les méthodes d’intégration entre les systèmes du WP2 et ceux du WP. Dans la section suivante, nous entendons par système externe applications et systèmes externes aux WP2.

 

Scénarios

 

  • Opérations de surveillance UAV

L’utilisateur de certains systèmes externes trace des véhicules qui l’intéressent. Il/Elle sait qu’un UAV opère actuellement dans la même zone. Le WP2 fournit au système externe des données en temps réel provenant de l’UAV et l’utilisateur peut par exemple utiliser le portail développé dans le WP6 pour regarder les vidéos de l’UAV.

Informations fournies par le système WP2 :

  • Vidéo un flux en temps réel des vidéos de l’UAV présenter dans le contrôle vidéo.
  • Auxiliaire la télémétrie de l’UAV : position, angle du cardan, propriétés du cardan, etc.

Entrées de l’utilisateur : Aucune l’Operateur du portail n’est pas autorisé à contrôler l’UAV – cet officier peut communiquer avec l’opérateur UAV par d’autre moyen (ex : téléphone) pour changer les actions de l’UAV.

 

  • Opérations Hors ligne UAV

L’utilisateur collecte un groupement de données à présenter à la cour. Il/Elle est intéressée dans les données concernant une certaine période de temps ou zone. En utilisant le portail, l’utilisateur détermine si des UAV étaient en mission dans cette zone durant cette période. S’il y a eu des missions, l’utilisateur peut accéder aux vidéos.

Entrées de l’utilisateur :

  • Temps comme décrit dans le paragraphe « Type de données ».
  • Lieu (type de position comme dans « type de données ») Cela peut-être un seul point ou deux décrivant une zone circulaire entre eux.

Information fournies :

  • Vol des UAV dans cette zone à ce moment précis
  • Chemin suivi par l’UAV décrit comme une liste de point dans le temps avec la position correspondante.
  • Direction du cardan

 

  • Planification de missions UAV

L’utilisateur utilise un système externe. Dans le cas où l’utilisateur ou le système trouverait bénéfique le fait de lancer une mission avec des UAVs, un système externe peut programmer un chemin de point de passage et l’enregistrer sur le portail WP2. Le système peut le mettre ainsi en attente, le suggérer à l’opérateur UAV ou le supprimer, tout dépend des contraintes.

Entrées du système externe : Description de la mission consistant en une liste de point de passage décrit dans le paragraphe « type de données ».

Informations fournies :

  • Résultats : si la mission est en attente, acceptée ou rejetée.
  • Validation : si la mission est réalisable en terme techniques (ex : pas de limite de vitesse dépassée).
  • Disponibilité : si des UAV sont disponibles pour le moment.
  • Réservation : informe tout le personnel qu’une mission est planifiée pour le moment – cela peut être une entrée ou un flux de travail plus important.

 

  • Reconnaissance de plaques d’immatriculation

La station de reconnaissance de plaques minéralogiques est située près des routes et lit toutes les plaques des véhicules. Il y a deux modes d’opérations possibles : ENREGISTRER TOUT et ENREGITRER LES DEMANDES. Le premier enregistre toutes les plaques minéralogiques alors que le second enregistre seulement les plaques prédéfinies par l’utilisateur.

Entrées de l’utilisateur : Immatriculation demandées plaques de voitures recherchées, définies par l’utilisateur.

Informations fournies :

  • Numéro : numéro de licence du véhicule.
  • Image : photo du véhicule correspondant au numéro.
  • Temps : heure exacte de la reconnaissance.
  • Couleur (optionnel) : la couleur du véhicule.

 

  • Tracer par GPS-GSM

L’appareil traceur GPS-GSM supporte divers modes pour fournir un bon compromis entre la consommation d’énergie et la qualité du tracking. Le mode peut être changé en temps réel afin de s’accommoder aux différentes requêtes.

Entrées de l’utilisateur :

  • Fréquence : fréquence à laquelle l’appareil rapporte sa position.
  • Fréquence de synchronisation  : fréquence à laquelle les lots de positions sont envoyés au serveur.

Informations fournies :

  • Temps : heure du rapport de position.
  • Position : position de l’objet tracé.
  • Précision : précision de la position courante.
  • Vitesse : vitesse de l’objet tracé.
  • Niveau de batterie : énergie restante dans la batterie.
  • Cellule GSM : station de transfert GSM courante (BTS).

 

  • Type de données

Position

Champs : Latitude présentée en degrés décimaux (52.1235°), dépendant des données à représenter. Longitude idem ; Altitude mètres au dessus de la mer/terre, sera marqué par métadonnées. Système de référence géodésique WGS84.

 

Temps

Ce type décrit le temps d’une façon sans équivoque. L’exécution sera discutée plus tard.

Ce type de données similaires est décrit comme espaces réservés à de futures discussions. Autoriser des partenariats dans d’autre WPs pour être conscient de la disponibilité des données du WP2.Il faudra inclure la date, l’heure, le décalage par rapport à l’UTC, probablement un zone d’info pour le temps.

 

Vitesse

Ce type de données décrit la vitesse d’une façon sans équivoque. L’exécution sera discutée plus tard.

Pour le moment nous proposons des mètres par seconde.

 

Point de passage

Chaque point de passage décrit un point dans la mission où l’état de l’UAV change. Il contient les champs suivants :

Temps comme décrit précédemment

Position idem

Action décrit le plan de mission pour ce point de passage, par exemple « commencer à enregistrer ».

 

UAV

Ce type de données décrit tous les paramètres de l’UAV en opération.

Champs :

Position comme décrit précédemment

Temps idem

Vitesse idem

Direction du cardan angle dans lequel la caméra regarde

Zone Observées zone observes par la caméra (position + radius)

Mode de stabilisation du cardan mode de stabilisation

Propriété de la caméra ex. niveau du zoom, ou mode d’opération

Enregistrement est l’enregistrement disponible de l’UAV.

Action toute action spéciale que l’UAV effectue.

Niveau de la Batterie Mesure du voltage de la batterie principale de l’UAV.

Type de mission Une brève définition de la mission (à partir des objets de la liste prédéfinie).

Prochain point de passage comme décrit précédemment.

 

Mission de l’UAV

Description détaillée de la mission. Cela consiste en une série de point de passage comme décrit précédemment.

 

Objet tracé

Permet un aperçu des données à propos des objets. Une série de cette entité peut être mis à jour couramment. On peut envoyer une requête au système par rapport à un objet.

Paramètres toujours présents dans l’aperçu :

Uri Identificateur de chaine associé à l’objet, clé unique.

Position décrit précédemment.

Temps marque temporel du présent enregistrement.

Texte de description entrée par l’utilisateur.

Paramètre optionnels :

Vitesse comme décrit précédemment.

Icône Uri de l’icône qui peut représenter l’objet sur l’écran.

 

Données des véhicules

Structure de données qui décrivent le véhicule détecté par le module de reconnaissance de plaque.

Champs :

Numéro numéro de licence du véhicule.

Image photo du véhicule correspondant au véhicule.

Temps l’heure exacte de la reconnaissance.

Couleur (optionnel) couleur du véhicule.

 

Données fournies

Le WP2 fournit trois types de données : flux vidéo, descriptions des données des objets tracés et des événements.

 

Flux vidéo

Le système dans son ensemble à plusieurs nœuds équipé de caméras vidéos. Cela peut être un UAV ou un module de reconnaissance de plaque. L’objectif principal est d’analyser le flux vidéo localement et de prendre toute les décisions automatiquement. Une situation qui requière d’une présentation vidéo à l’opérateur peut  survenir. Tous les nœuds du système analysant les données vidéo peuvent aussi les transmettre à l’opérateur à distance. L’UAV peut produire un flux vidéo en format MPEG ou MPEG-4. La station de reconnaissance de plaques n’envoie que les images statiques durant son opération. Il est aussi possible de transmettre des flux vidéo en MPEG ou MPEG-4, cependant c’est une caractéristique optionnelle. Tout les flux vidéo peuvent être stockés et téléchargés ensuite si besoin. Le serveur de stockage vidéo supporte le MPEG et MPEG-4. On peut donc l’utiliser pour le stockage des vidéos. Une requête peut contenir la source, qualité et période de temps désirée.

 

Description des objets

Quand le système trace un objet, un aperçu est disponible à partir du système. Les services externes peuvent soumettre des requêtes selon quatre scénarios :

– Informations courantes à propos des objets identifiés par URI – en réponse, il peut obtenir un aperçu de cet objet.

– Informations courantes à propos des zones désirées (pour déterminer si la zone peut être rectangulaire ou avoir une forme arbitraire) – en réponse il peut obtenir un aperçu pour un objet présent ou se déplace dans la zone.

– Informations historiques à propos des objets identifiés par l’URI et intervalle de temps – en réponse il peut obtenir une liste d’aperçu pour cet objet.

– Informations historiques à propos des objets d’une zone et d’un intervalle de temps – en réponse il peut obtenir une liste d’aperçu des objets présent dans cette zone à ce moment précis.

L’API de ce service est en train d’être déterminé en coopération avec les utilisateurs des données.

 

Evénements

Etat de l’UAV

Cet événement arrive quand l’UAV atteint un certain état. Les états possibles sont :

–             Atteindre un point de passage (incluant le départ et l’atterrissage).

–             Un capteur a trouvé un objet (un certain seuil est atteint).

–             Batterie faible.

–             Urgence

Etat de format de trame :

Position décrit précédemment.

Temps idem.

Description d’état information à propos du point atteint.

Reconnaissance de plaques d’immatriculation

Cet événement se passe lorsqu’un véhicule apparait en fasse de la caméra. Cet événement est déclenché par :

– Apparition de véhicules, en mode TOUT.

– Apparition des véhicules demandés, en mode DEMANDES.

Les données standard pour la reconnaissance des données sont transmises dans ce cas.

 

Travaux futurs

Les tâches restantes à compléter dans le plus haut niveau de conception de l’architecture sont :

  • Choix d’une plateforme middleware pour la communication basée sur des messages.
  • Description détaillée de tous les nœuds du système.
  • Description détaillée de l’intégration avec le WP6 pour permettre l’exécution.
  • Spécification détaillée des protocoles d’encryptage et d’autorisation.

 

Conclusion

Dans ce document, nous avons décrit une architecture du système, centrée sur un réseau ayant été conçu dans le WP2 du projet INDECT. La conception présentée est hautement modulaire, stable, ouverte et sécurisée. Elle est divisée en deux parties principales. Premièrement, le sous-système de communication consistant en une infrastructure d’hardwares et des modèles et stratégies de communication. Deuxièmement, une production construite sur le plus puissant des réseaux pour permettre ces fonctionnalités : UAV, segment central UAV, salle de commande, serveurs, traceurs GPS-GSM, traceurs mobiles et capteur multifonctions. Ces deux parties peuvent avoir des extensions, être modifiées, remplacées indépendamment aussi longtemps qu’elles  sont conformes aux spécifications.

Chaque construction du WP2 est modulaire – grâce à cela, de nouveaux nœuds peuvent être ajoutés à l’infrastructure du réseau, à la couche de produit, etc. La conception du serveur et du logiciel client inclus la modularité. Le logiciel est conçu pour être facilement étendu avec de nouveaux modules, plugins, pour supporter facilement l’ajout de nouvelles fonctionnalités et  caractéristiques.

 

 

 

Une réflexion au sujet de « La Grosse Annexe »

  1. Ping : Joyeux Anniversaire VoX ! |

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s