FR2786290A1 - Systeme de gestion de detections, notamment pour sous-marin - Google Patents
Systeme de gestion de detections, notamment pour sous-marin Download PDFInfo
- Publication number
- FR2786290A1 FR2786290A1 FR9814788A FR9814788A FR2786290A1 FR 2786290 A1 FR2786290 A1 FR 2786290A1 FR 9814788 A FR9814788 A FR 9814788A FR 9814788 A FR9814788 A FR 9814788A FR 2786290 A1 FR2786290 A1 FR 2786290A1
- Authority
- FR
- France
- Prior art keywords
- module
- track
- data
- management
- tracks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
- G01S13/66—Radar-tracking systems; Analogous systems
- G01S13/72—Radar-tracking systems; Analogous systems for two-dimensional tracking, e.g. combination of angle and range tracking, track-while-scan radar
- G01S13/723—Radar-tracking systems; Analogous systems for two-dimensional tracking, e.g. combination of angle and range tracking, track-while-scan radar by using numerical data
Landscapes
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne les systèmes qui permettent de gérer les détections sonars, notamment dans les sous-marins.Elle consiste à gérer les pistes obtenues à partir de plusieurs antennes (105) de manière interactive au moyen d'un logiciel de gestion de base de données (301). Le système comporte un module principal (101) auquel sont reliés un module permettant de faire de la mémorisation historique des données (103) et un module (104) permettant de gérer la base de données des mesures selon un mode question-réponse.Elle permet de faciliter le travail des opérateurs qui cherchent à déterminer une action en réponse à une situation tactique.
Description
La présente invention se rapporte aux systèmes qui permettent de gérer les détections sonars, en particulier dans les bâtiments tels que les sous-marins, afin en particulier de pouvoir apprécier la situation tactique pour en tirer des décisions de manoeuvre.
Le but d'un appareil de détection tel qu'un Sonar ou un radar est de détecter, localiser, classifier, informer. Les 2 premières fonctions permettent d'obtenir des données qui sont ensuite traitées au niveau des deux dernières fonctions, sur lesquelles porte le système objet de l'invention.
Le traitement des signaux permettant d'accomplir ces 2 fonctions consiste essentiellement à créer des ensembles de données appelés"pistes". Une piste est définie comme étant formée d'une suite temporelle d'événements détectés liés entre eux par une continuité des mesures associées. Ces mesures peuvent tre I'azimut, la fréquence, ou encore une bande de fréquence. L'ensemble de ces pistes est présenté aux opérateurs du système Sonar, qui doivent les gérer de manière à pouvoir fournir au responsable d'exploitation :
-une vue claire de la situation tactique locale ;
-les moyens permettant de déterminer ses actions immédiates et futures ;
-les moyens permettant de décider de mettre en oeuvre les équipements, tels que les contre-mesures, dont il dispose.
-une vue claire de la situation tactique locale ;
-les moyens permettant de déterminer ses actions immédiates et futures ;
-les moyens permettant de décider de mettre en oeuvre les équipements, tels que les contre-mesures, dont il dispose.
On définit par ailleurs des"contacts", qui sont des représentations présumées d'un bruiteur, correspondant en général à un ensemble de pistes ; il convient également de gérer ces contacts.
Pour pouvoir gérer ces pistes et ces contacts, l'invention propose un système de gestion de détections sonar, notamment pour sous-marin, principalement caractérisé en ce qu'il comporte un module de traitement pour obtenir des signaux de pistes à partir de signaux provenant de capteurs extérieurs, un module principal recevant ces signaux de pistes et permettant d'effectuer leur gestion, le raboutage automatique à court terme des segments de pistes pouvant former une seule piste, et le contrôle automatique des associations pour assurer la non divergence des tronçons de pistes, un module de mémorisation historique pour gérer l'historique des différents fichiers du module principal et restituer les données de ces fichiers à ce module principal, un module de gestion selon un mode question/réponse de la base de données constituée par ces fichiers, et un module d'interface homme/machine pour présenter aux opérateurs du système les résultats du traitement effectué dans le module principal.
Selon une autre caractéristique, le module de mémorisation historique comprend une mémoire centrale recevant les données par l'intermédiaire d'un module de stockage et les restituant au module principal et au module d'interface homme/machine par l'intermédiaire d'un module de déstockage, un module de purge permettant d'éliminer les données stockées depuis un temps fixé, un module de reconstruction client et un module de reconstruction serveur permettant de reconstruire les archives des utilisateurs à partir des archives stockées dans la mémoire centrale selon un système client-serveur, et de délivrer à l'interface homme/machine les données ainsi reconstruites.
Selon une autre caractéristique, le module de gestion selon un mode de question/réponse est en outre relié à une mémoire organisée en système de gestion de base de données.
D'autres particularités et avantages de l'invention apparaîtront clairement dans la description suivante, faite à titre d'exemple non limitatif en regard des figures annexées qui représentent :
-la figure 1, un schéma synoptique général d'un système selon I'invention ;
-la figure 2, un schéma synoptique du module"HISTO"de la figure 1 ; et
-la figure 3 un schéma synoptique du module"RDBMS"de la figure 1.
-la figure 1, un schéma synoptique général d'un système selon I'invention ;
-la figure 2, un schéma synoptique du module"HISTO"de la figure 1 ; et
-la figure 3 un schéma synoptique du module"RDBMS"de la figure 1.
On a représenté sur la figure 1 un synoptique général d'un système selon l'invention. Ce système est composé d'au moins 3 modules qui coopèrent entre eux :
-un module 101 dit WATCH qui effectue le contrôle automatique des pistes et des contacts. II reçoit les mesures et communique avec 2 autres modules et une interface homme-machine
102 dite"IHM",
-un module 103 dit"HISTO"qui mémorise de manière "historique"les fichiers de mesures et en assure la gestion. II recueille et fournit les données au module WATCH
-un module 104 dit"RDBMS"qui gère la base de données des mesures. Il communique avec le module WATCH selon un mode "questions-réponses"connu en tant que tel dans les systèmes de gestion de bases de données dits"SGBD".
-un module 101 dit WATCH qui effectue le contrôle automatique des pistes et des contacts. II reçoit les mesures et communique avec 2 autres modules et une interface homme-machine
102 dite"IHM",
-un module 103 dit"HISTO"qui mémorise de manière "historique"les fichiers de mesures et en assure la gestion. II recueille et fournit les données au module WATCH
-un module 104 dit"RDBMS"qui gère la base de données des mesures. Il communique avec le module WATCH selon un mode "questions-réponses"connu en tant que tel dans les systèmes de gestion de bases de données dits"SGBD".
Les mesures permettant d'obtenir les pistes proviennent de senseurs divers, par exemple de 4 systèmes d'antennes AC (antenne cylindrique de coque), AF (antennes de flancs), AR (antenne remorquée) et AI (antenne d'interception d'émissions sonar). Les signaux de ces antennes sont ensuite traités dans un module 105 pour fournir les pistes définies plus haut.
Le module WATCH 101 est lui mme formé de 3 sous-modules qui correspondent aux 3 fonctionnalités suivantes :
-un mode 111 de gestion des pistes dit GP ;
-un module 112 de raboutage automatique à court terme dit
RCT ;
-un module 113 de contrôle automatique des associations dit
CAA ;
La gestion des pistes dans le module GP :
-L'analyse des identificateurs de pistes pour en déduire l'apparition de nouvelles pistes et/ou la disparition de pistes existantes ;
-la surveillance des mesures des pistes pour en déduire le changement d'attributs particuliers (par ex. minima et maxima d'azimut)
-I'analyse de la composition des mesures des pistes fusionnées pour en déduire les changements de composition.
-un mode 111 de gestion des pistes dit GP ;
-un module 112 de raboutage automatique à court terme dit
RCT ;
-un module 113 de contrôle automatique des associations dit
CAA ;
La gestion des pistes dans le module GP :
-L'analyse des identificateurs de pistes pour en déduire l'apparition de nouvelles pistes et/ou la disparition de pistes existantes ;
-la surveillance des mesures des pistes pour en déduire le changement d'attributs particuliers (par ex. minima et maxima d'azimut)
-I'analyse de la composition des mesures des pistes fusionnées pour en déduire les changements de composition.
Dans le raboutage automatique à court-terme, on tente, avec une récurrence d'exécution de cette fonction paramètrée, de reconstituer la continuité des pistes affectées de coupures et n'appartenant pas au mme contact, de la manière suivante :
-envoi d'une requte vers le module RDBMS pour connaître la liste des pistes nouvelles non déjà testées et d'âge suffisant ;
-pour chaque piste :
requte RDBMS pour connaître la liste des pistes arrtées n'appartenant pas au mme contact que la piste nouvelle. L'essai de raboutage porte sur les pistes"anciennes", définies comme étant arrtées depuis une durée qui est paramétrée, par rapport au début de la piste nouvelle. La durée des pistes est paramétrée pour tre suffisante.
-envoi d'une requte vers le module RDBMS pour connaître la liste des pistes nouvelles non déjà testées et d'âge suffisant ;
-pour chaque piste :
requte RDBMS pour connaître la liste des pistes arrtées n'appartenant pas au mme contact que la piste nouvelle. L'essai de raboutage porte sur les pistes"anciennes", définies comme étant arrtées depuis une durée qui est paramétrée, par rapport au début de la piste nouvelle. La durée des pistes est paramétrée pour tre suffisante.
-Pour chaque couple de pistes :
extraction dans le module HISTO des mesures des pistes correspondant à la durée paramétrée ;
calcul de la distance entre les vecteurs d'état estimés au point milieu de l'espace séparant les 2 pistes. Si la plus petite distance entre les 2 pistes est inférieure à la valeur, qui est paramétrée, d'un seuil, le couple est identifié comme"candidat"au raboutage.
extraction dans le module HISTO des mesures des pistes correspondant à la durée paramétrée ;
calcul de la distance entre les vecteurs d'état estimés au point milieu de l'espace séparant les 2 pistes. Si la plus petite distance entre les 2 pistes est inférieure à la valeur, qui est paramétrée, d'un seuil, le couple est identifié comme"candidat"au raboutage.
-pour toutes les pistes, si une piste est impliquée dans plusieurs couple, il y a rejet des couples concernés
-pour les couples sélectionnés :
'requte RDBtvtS pour demande de raboutage des 2 pistes ;
envoi d'un message d'alerte à I'IHM indiquant les pistes concernées.
-pour les couples sélectionnés :
'requte RDBtvtS pour demande de raboutage des 2 pistes ;
envoi d'un message d'alerte à I'IHM indiquant les pistes concernées.
La fonction CAA, dont la récurrence d'exécution est paramétrée, réalise le contrôle de la non-divergence des composantes de tous les contacts (une composante est définie comme étant un tronçon de piste associé à ce contact).
Cette fonction commence par une requte RDBMS pour connaître la composition en pistes senseurs de ce contact, avec sélection des pistes qui n'ont pas divergées.
Pour chaque piste provenant d'un serveur de mesures d'origine (AC, AF, AI), on effectue :
-un accès HISTO aux mesures des pistes ;
-le calcul de la distance angulaire par rapport à la piste des senseurs de coque la plus représentative pour chaque composante et la comparaison à un seuil de divergence (qui est paramétré) ;
-si au moins une divergence entre composantes est détectée, on note une"divergence contact" ;
-en cas de divergence sur une piste qui n'est pas déjà modifiée par l'opérateur, on envoie un message d'alerte à I'IHM pour proposer à l'opérateur la désassociation de la piste et du contact (il peut alors modifier à I'aide des organes de saisies tels qu'un clavier, non représenté sur la figure, la composition du contact), et on envoie une donnée à
RDBMS pour marquer cette divergence dans les attributs de la piste.
-un accès HISTO aux mesures des pistes ;
-le calcul de la distance angulaire par rapport à la piste des senseurs de coque la plus représentative pour chaque composante et la comparaison à un seuil de divergence (qui est paramétré) ;
-si au moins une divergence entre composantes est détectée, on note une"divergence contact" ;
-en cas de divergence sur une piste qui n'est pas déjà modifiée par l'opérateur, on envoie un message d'alerte à I'IHM pour proposer à l'opérateur la désassociation de la piste et du contact (il peut alors modifier à I'aide des organes de saisies tels qu'un clavier, non représenté sur la figure, la composition du contact), et on envoie une donnée à
RDBMS pour marquer cette divergence dans les attributs de la piste.
La mme opération est effectuée pour chaque piste provenant d'une antenne remorquée (AR).
Les entrées de module WATCH sont constituées par les mesures pistes obtenues à partir de l'organe de traitement 105.
Les sorties du module WATCH sont dirigées vers l'organe IHM.
Elles sont constituées par les alertes pour reboutage de pistes, et les alertes de divergence des composantes de contact.
Les communications avec le module HISTO correspondent à des demandes de lecture de mesures d'une piste.
Les communications vers le module RDBMS correspondent à :
-des débuts et fins des pistes élémentaires ;
-des demandes d'extraction des informations relatives aux pistes ;
-des changements de valeurs limites d'une piste ;
-des changements d'appartenance d'une piste élémentaire à une piste fusionnée ;
-des mémorisation dans le dossier"contacts" ;
-des indications de divergence de piste ; et
-des demandes de raboutage de 2 pistes.
-des débuts et fins des pistes élémentaires ;
-des demandes d'extraction des informations relatives aux pistes ;
-des changements de valeurs limites d'une piste ;
-des changements d'appartenance d'une piste élémentaire à une piste fusionnée ;
-des mémorisation dans le dossier"contacts" ;
-des indications de divergence de piste ; et
-des demandes de raboutage de 2 pistes.
Le module HISTO, qui est représenté de manière plus détaillée en fig 2, réalise une mise en mémoire de manière historique, et la restitution, des fichiers de mesures, de données brutes et d'événements détectés dits EVD.
II comprend un ensemble de modules correspondant aux fonctionnalités suivantes, organisées autour d'une mémoire centrale 201 :
'stockage des données par un module 202 ;
'lecture des données par un module 203 ;
gestion de la durée des données de mémorisation historique ; par un module de"purge"204 ;
reconstruction des archives des utilisateurs à partir d'un système du type client-serveur dans deux modules 205 et 206.
'stockage des données par un module 202 ;
'lecture des données par un module 203 ;
gestion de la durée des données de mémorisation historique ; par un module de"purge"204 ;
reconstruction des archives des utilisateurs à partir d'un système du type client-serveur dans deux modules 205 et 206.
Un fichier de configuration non représenté permet d'obtenir :
la liste des données (brut, EVD, pistes) à mémoriser en fonction de I'allocation matérielle (antennes AC, AF,...) ;
' la durée de mémorisation historique de chaque type de données ;
'ta liste des données nécessaires à la reconstruction des historiques minimal et total.
la liste des données (brut, EVD, pistes) à mémoriser en fonction de I'allocation matérielle (antennes AC, AF,...) ;
' la durée de mémorisation historique de chaque type de données ;
'ta liste des données nécessaires à la reconstruction des historiques minimal et total.
Le stockage des données est effectué à partir de messages provenant :
'du traitement du signal des antennes AC, AF, et AR pour les données brutes et les événements détectés ;
'du traitement de l'information effectué en aval des informations ci-dessus, des antennes AC, AF, AR et AI pour les pistes ;
du système central pour les données de navigation (fichier
NAV).
'du traitement du signal des antennes AC, AF, et AR pour les données brutes et les événements détectés ;
'du traitement de l'information effectué en aval des informations ci-dessus, des antennes AC, AF, AR et AI pour les pistes ;
du système central pour les données de navigation (fichier
NAV).
Sur réception d'un message activant la fonction"HISTO", une commande est émise qui entraîne :
'ta prise en compte d'un ficher de configuration ;
'ta création des fichiers permanents (brut, EVD, NAV).
'ta prise en compte d'un ficher de configuration ;
'ta création des fichiers permanents (brut, EVD, NAV).
Le module HISTO comporte une fonction de"reconstruction de l'historique". Cette fonction respecte l'ordre chronologique d'arrivée des données. Elle fonctionne selon un mode"client-serveur" :
-la fonction reconstruction"client"205 est disponible chez les "utilisateurs"de données ;
-la fonction reconstruction"serveur"206 est disponible chez les"producteurs"de données (par exemple les chaînes électroniques associées aux antennes).
-la fonction reconstruction"client"205 est disponible chez les "utilisateurs"de données ;
-la fonction reconstruction"serveur"206 est disponible chez les"producteurs"de données (par exemple les chaînes électroniques associées aux antennes).
Les 2 fonctions communiquent par un système requtes/réponses.
A la réception du message"RESTORE", précisant le type de données prioritaires, la fonction de reconstruction du minimum d'historique"client"est activée :
-une requte est adressée à chaque serveur pour lui demander la liste des fichiers de type prioritaire qu'il possède au temps courant :
en réponse à cette requte la partie"reconstruction serveur"effectue l'inventaire des fichiers disponibles,
à la réception de cette réponse, la partie"reconstruction client"effectue pour chacun de ces fichiers :
une copie pour les mesures pistes ;
'une lecture et un envoi des messages IHM pour les données brutes et les EVD ;
une création des fichiers pour les données de navigation à partir des images existantes pour assurer la continuité temporelle (il y a 4 fichiers : le cap porteur, le cap AR et les 2 anti-caps).
-une requte est adressée à chaque serveur pour lui demander la liste des fichiers de type prioritaire qu'il possède au temps courant :
en réponse à cette requte la partie"reconstruction serveur"effectue l'inventaire des fichiers disponibles,
à la réception de cette réponse, la partie"reconstruction client"effectue pour chacun de ces fichiers :
une copie pour les mesures pistes ;
'une lecture et un envoi des messages IHM pour les données brutes et les EVD ;
une création des fichiers pour les données de navigation à partir des images existantes pour assurer la continuité temporelle (il y a 4 fichiers : le cap porteur, le cap AR et les 2 anti-caps).
Ce mécanisme peut tre appliquée à ('historique local ou à l'historique complet.
La gestion des fichiers"mesures pistes"consiste à créer les fichiers les nouvelles pistes, puis à faire la mise à jour.
La gestion des fichiers"données brutes", qui ont une taille fixe, est faite avec un"buffer"tournant. II en est de mme pour les"données navigation".
La gestion des fichiers"EVD", qui ont une taille variable, est faite de manière dite"flip/flop"sur la durée de l'historique.
La gestion de la durée de I'historique consiste à purger automatiquement (avec une récurrence comprise entre 5 et 10 minutes par exemple) tous les fichiers non permanents dans lesquelles aucune écriture n'a été effectuée depuis un temps correspondant à la durée de mémorisation. Celle-ci a été définie dans le fichier de configuration.
Le module RDBMS, qui est représenté de manière plus détaillée en figure 3, réalise la gestion des données pistes.
II comprend les fonctionnalités :
-la gestion automatique des"baptmes"; on entend par baptme l'identification d'un contact par un nombre unique ;
-la gestion automatique des"représentants"; on entend par représentant une piste choisie comme la plus représentative des pistes senseurs attribuées à un contact,
-la gestion des pistes ;
-la gestion des dossiers contacts ;
-la gestion de la durée d'historique ;
La gestion automatique des baptmes comprend les étapes suivantes :
-à chaque demande d'attribution, on répond en attribuant un numéro correspondant au premier numéro libre d'une liste préétablie ; le plus ancien est le premier libéré, selon la règle FIFO ;
-à la libération d'un numéro, celui-ci est marqué comme libre dans la liste, puis il est réinséré en queue de liste ;
-l'information est mémorisée dans le dossier contact.
-la gestion automatique des"baptmes"; on entend par baptme l'identification d'un contact par un nombre unique ;
-la gestion automatique des"représentants"; on entend par représentant une piste choisie comme la plus représentative des pistes senseurs attribuées à un contact,
-la gestion des pistes ;
-la gestion des dossiers contacts ;
-la gestion de la durée d'historique ;
La gestion automatique des baptmes comprend les étapes suivantes :
-à chaque demande d'attribution, on répond en attribuant un numéro correspondant au premier numéro libre d'une liste préétablie ; le plus ancien est le premier libéré, selon la règle FIFO ;
-à la libération d'un numéro, celui-ci est marqué comme libre dans la liste, puis il est réinséré en queue de liste ;
-l'information est mémorisée dans le dossier contact.
Tout contact possède un représentant. La gestion automatique des représentants consiste à assurer l'élection d'une des pistes au rang de représentant. Elle a lieu à la création du contact, si aucun représentant n'est déjà spécifié, ou à la"mort"d'une piste ayant rang de représentant dans un contact comprenant d'autres pistes. La détermination du représentant est faite par classement des pistes selon un ordre de priorité défini par type de piste (manuelles, automatiques, coque ou flûte,...).
Cette information est mémorisée dans l'attribut des pistes du contact.
Une piste est un objet de la base de donnée 301 auquel sont attachés :
-des attributs, modifiables ou non, dont la validité couvre la durée de vie de la piste entière ;
-des attributs variables pendant la vie de la piste ; à chaque tranche temporelle de validité d'une combinaison d'attributs correspond un segment de piste.
-des attributs, modifiables ou non, dont la validité couvre la durée de vie de la piste entière ;
-des attributs variables pendant la vie de la piste ; à chaque tranche temporelle de validité d'une combinaison d'attributs correspond un segment de piste.
La gestion des pistes et segment de pistes :
-leur ouverture : création de la piste ou du segment avec mémorisation de la date de début ;
-leur fermeture : mémorisation de la date de fin ;
-leurs modifications : mise à jour des attributs modifiables (pour les pistes entières), fermeture puis ouverture d'un nouveau segment avec de nouveaux attributs (pour les segments de pistes) ;
-leur destruction : suppression de la piste ou de tous ses segments.
-leur ouverture : création de la piste ou du segment avec mémorisation de la date de début ;
-leur fermeture : mémorisation de la date de fin ;
-leurs modifications : mise à jour des attributs modifiables (pour les pistes entières), fermeture puis ouverture d'un nouveau segment avec de nouveaux attributs (pour les segments de pistes) ;
-leur destruction : suppression de la piste ou de tous ses segments.
On gère 2 types de segments distincts :
-des segments correspondant au temps pendant lequel la piste est liée à une piste fusionnée ;
-des segments correspondant à un intervalle de temps pour une combinaison d'attributs donnée.
-des segments correspondant au temps pendant lequel la piste est liée à une piste fusionnée ;
-des segments correspondant à un intervalle de temps pour une combinaison d'attributs donnée.
Les requtes provenant du module WATCH portent :
-la modification des pistes ;
-la modification des segments de pistes ;
-le raboutage des pistes.
-la modification des pistes ;
-la modification des segments de pistes ;
-le raboutage des pistes.
Les requtes principales concernant les pistes :
-les créations de piste, de premier segment, et le cas échéant de nouveau contact ; dans ce dernier cas, il y a création d'un"dossier" contact et appel des fonctions de gestion automatique des baptmes et des représentants.
-les créations de piste, de premier segment, et le cas échéant de nouveau contact ; dans ce dernier cas, il y a création d'un"dossier" contact et appel des fonctions de gestion automatique des baptmes et des représentants.
-les fermetures de piste, du dernier segment de cette piste et, pour une piste senseur liée à un contact, détermination du fait que le contact comporte d'autres composantes telles que définie plus haut pour, dans l'affirmative appeler la fonction gestion automatique des représentants, et dans la négative libérer le baptme du contact ;
-la modification des attributs correspondants de la piste ;
-le stockage des informations de localisation et, si la piste est liée à un contact, 1'enrichissement du dossier correspondant ;
-la modification de l'attribut correspondant de la piste signalant une divergence.
-la modification des attributs correspondants de la piste ;
-le stockage des informations de localisation et, si la piste est liée à un contact, 1'enrichissement du dossier correspondant ;
-la modification de l'attribut correspondant de la piste signalant une divergence.
Pour les requtes concernant les segments de pistes, les actions faites au temps courant sans modification du passé entraînent la modification du segment (fermeture, ouverture d'un nouveau segment) et celles faites en modifiant le passé entraînent la réorganisation du segment (ouverture, fermeture modification et/ou destruction).
Pour les requtes concernant le raboutage des pistes, la réception d'un message contenant l'identification de la piste nouvelle et de la piste plus ancienne, entraîne la mise en oeuvre des actions suivantes :
-si les 2 pistes sont libres, pas d'action ;
-si une des pistes est libre et n'a jamais été liée à un contact, elle est liée au mme contact que l'autre ;
-si la nouvelle piste a été liée automatiquement à un contact, elle est liée au mme contact que I'ancienne ;
-si la nouvelle piste a été liée manuellement à un contact, ce choix n'est pas modifié.
-si les 2 pistes sont libres, pas d'action ;
-si une des pistes est libre et n'a jamais été liée à un contact, elle est liée au mme contact que l'autre ;
-si la nouvelle piste a été liée automatiquement à un contact, elle est liée au mme contact que I'ancienne ;
-si la nouvelle piste a été liée manuellement à un contact, ce choix n'est pas modifié.
La gestion des dossiers contacts :
-le traitement des requtes de stockage de données dans le dossier ;
-le traitement des localisations, toute localisation est datée et possède un attribut dont les valeurs possibles :
'en essai : stockage provisoire
'attribuée : stockage définitif
assignée : validation vis à vis du système de traitement des informations tactiques à un instant donné, à envoyer.
-le traitement des requtes de stockage de données dans le dossier ;
-le traitement des localisations, toute localisation est datée et possède un attribut dont les valeurs possibles :
'en essai : stockage provisoire
'attribuée : stockage définitif
assignée : validation vis à vis du système de traitement des informations tactiques à un instant donné, à envoyer.
Selon le type de requte, la gestion de la durée d'historique entraîne la mise en oeuvre des actions suivantes :
-purge de tout ou partie des pistes et/ou des contacts ;
-purge des pistes dont la date de fin ou la date de dernière modification est au moins égale à la date courante moins la durée de mémorisation historique.
-purge de tout ou partie des pistes et/ou des contacts ;
-purge des pistes dont la date de fin ou la date de dernière modification est au moins égale à la date courante moins la durée de mémorisation historique.
Si des émissions sonar identifiées, des spectres et/ou des localisations sont alors attachées à ces pistes, et il faut donc en plus :
-pour les localisations, détruire des données ;
-pour les émissions sonar identifiées et les spectres, rechercher le contact auquel la piste est liée à la date de la mesure ; s'il existe, on lie les données à ce contact, sinon on les détruit.
-pour les localisations, détruire des données ;
-pour les émissions sonar identifiées et les spectres, rechercher le contact auquel la piste est liée à la date de la mesure ; s'il existe, on lie les données à ce contact, sinon on les détruit.
Claims (3)
1-Système de gestion de détections sonar, notamment pour sous-marin, caractérisé en ce qu'il comporte un module de traitement (105) pour obtenir des signaux de pistes à partir de signaux provenant de capteurs extérieurs (AC, AF, AR, Al), un module principal (101) recevant ces signaux de pistes et permettant d'effectuer leur gestion (GP), le raboutage automatique à court terme (RCT) des segments de pistes pouvant former une seule piste, et le contrôle automatique des associations (CA) pour assurer la non divergence des tronçons de pistes, un module de mémorisation historique (103) pour gérer I'historique des différents fichiers du module principal et restituer les données de ces fichiers à ce module principal, un module de gestion (104) selon un mode question/réponse de la base de données constituée par ces fichiers, et un module d'interface homme/machine (102) pour présenter aux opérateurs du système les résultats du traitement effectué dans le module principal.
2-Système selon la revendication 1, caractérisé en ce que le module de mémorisation historique (103) comprend une mémoire centrale (201) recevant les données par l'intermédiaire d'un module de stockage (202) et les restituant au module principal (101) et au module d'interface homme/machine (102) par l'intermédiaire d'un module de stockage (203), un module de purge (204) permettant d'éliminer les données stockées depuis un temps fixé, un module de reconstruction client (205) et un module de reconstruction serveur (206) permettant de reconstruire les archives des utilisateurs à partir des archives stockées dans la mémoire centrale (201) selon un système client-serveur, et de délivrer à l'interface homme/machine (102) les données ainsi reconstruites.
3-Système selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le module de gestion selon un mode de question/réponse (104) est en outre relié à une mémoire (301) organisée en système de gestion de base de données.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9814788A FR2786290B1 (fr) | 1998-11-24 | 1998-11-24 | Systeme de gestion de detections, notamment pour sous-marin |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9814788A FR2786290B1 (fr) | 1998-11-24 | 1998-11-24 | Systeme de gestion de detections, notamment pour sous-marin |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2786290A1 true FR2786290A1 (fr) | 2000-05-26 |
| FR2786290B1 FR2786290B1 (fr) | 2001-09-14 |
Family
ID=9533126
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9814788A Expired - Fee Related FR2786290B1 (fr) | 1998-11-24 | 1998-11-24 | Systeme de gestion de detections, notamment pour sous-marin |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2786290B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3167305A4 (fr) * | 2005-04-11 | 2017-05-17 | Raytheon Canada Limited | Systeme de classification pour applications de radar et de sonar |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996003662A2 (fr) * | 1994-07-22 | 1996-02-08 | Maridan Autonomous Underwater Vehicles Aps | Systeme pour operations d'etude sous-marine |
-
1998
- 1998-11-24 FR FR9814788A patent/FR2786290B1/fr not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996003662A2 (fr) * | 1994-07-22 | 1996-02-08 | Maridan Autonomous Underwater Vehicles Aps | Systeme pour operations d'etude sous-marine |
Non-Patent Citations (1)
| Title |
|---|
| T M MANSELL ET AL: "SCIMERS: A SONAR CONTACT INTEGRATED MANOEUVRE EVALUATION AND RECOMMENDATION SYSTEM", OCEANS '97 MTS/IEEE CONFERENCE PROCEEDINGS, vol. 2, 6 October 1997 (1997-10-06) - 9 October 1997 (1997-10-09), pages 1270 - 1276, XP002114024 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3167305A4 (fr) * | 2005-04-11 | 2017-05-17 | Raytheon Canada Limited | Systeme de classification pour applications de radar et de sonar |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2786290B1 (fr) | 2001-09-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0290679B1 (fr) | Dispositif de réception et de traitement de messages d'information routière | |
| FR2949567A1 (fr) | Traitement de donnees multi-cibles pour radars passifs multi-recepteurs en mode sfn ou mfn | |
| WO2015189157A1 (fr) | Procede de suivi d'une partition musicale et procede de modelisation associe | |
| FR2792443A1 (fr) | Actionneurs telecommandes par des emetteurs possedant un numero d'identite | |
| EP2318858B1 (fr) | Amelioration de la localisation d'aeronefs par un radar primaire par exploitation d'un radar secondaire en mode s | |
| US20150063711A1 (en) | Locating objects using images from portable devices | |
| US10613835B2 (en) | Hardware device based software generation | |
| FR2642325A1 (fr) | Dispositif de surveillance de l'allure notamment d'un cheval et systeme de surveillance en comportant application | |
| FR2951553A1 (fr) | Procede de pistage associant un radar passif a d'autres senseurs | |
| CN117784678B (zh) | 抗干扰检测仪的控制方法、设备及产品 | |
| US20190200167A1 (en) | Entity tracking | |
| FR2786290A1 (fr) | Systeme de gestion de detections, notamment pour sous-marin | |
| FR2741956A1 (fr) | Systeme et procede de regulation du nombre de plots a traiter dans un radar | |
| FR3118502A1 (fr) | Procédé de construction et d’entraînement d’un détecteur de la présence d’anomalies dans un signal temporel, dispositifs et procédé associés | |
| CA3162243C (fr) | Procede et systeme d'auto-localisation a partir d'ondes radioelectriques, programme et support de programme correspondants | |
| EP2452204B1 (fr) | Traitement de donnees multi-cibles pour radars passifs multi-statiques et multi-canaux | |
| EP0382592B1 (fr) | Système d'affichage cartographique universel, notamment pour la visualisation, sur un fond de carte approprié d'un objet repéré d'une façon quelconque | |
| EP1664833A1 (fr) | Procede pour detecter la presence ou l'absence d'un terminal mobile sur un chemin | |
| FR3070211A1 (fr) | Procede, mis en œuvre par ordinateur, de reconstruction de la topologie d'un reseau de cables | |
| FR3033420A1 (fr) | Procede de gestion de donnees relatives a une mission d'aeronefs et module de gestion de donnees correspondant | |
| FR2892846A1 (fr) | Procede et dispositif de calcul de mesure de similarite entre une representation d'un segment audio de reference et une representation d'un segment audio a tester et procede et dispositif de suivi d'un locuteur de reference | |
| FR2933775A1 (fr) | Traitement des donnees multi-cibles pour radars passifs multi-canaux. | |
| US20240177030A1 (en) | Identifying unkown decision making factors from communications data | |
| US20240181321A1 (en) | Edge storage architecture for security in wireless sports scoring | |
| US20240078809A1 (en) | Contextual Image Recognition Producing Notifications based on Knowledge Corpus Information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| ST | Notification of lapse |
Effective date: 20180731 |