La présente invention concerne une interface entre un système d'arme et au moins une liaison de données tactiques.

On sait qu'une « liaison de données tactiques » (LDT) dans le domaine militaire met en œuvre des standards de liaisons de données, en vue de fournir des moyens de communication via des formes d'ondes ou de liaisons filaires. Des systèmes d'information ou de combat utilisent les liaisons de données tactiques standardisées pour transmettre ou recevoir les données tactiques. En France, les liaisons de données de série J (liaison L1 6, liaison L22) représentent actuellement l'un des standards de référence. Les liaisons de données tactiques sont caractérisées par leurs messages standardisés et par les formats de transmission. Les standards des liaisons de données tactiques sont développés en lien avec des accords de normalisation STANAG (pour « Standardization Agreement » en anglais) appropriés.

Par ailleurs, dans le cadre de la présente invention, la notion de « système d'arme » désigne l'ensemble des dispositifs mécaniques, électroniques et/ou logiciels permettant à des militaires la réalisation d'une mission et la mise en œuvre d'un armement de façon autonome (identification, localisation, désignation d'objectif, préparation de tir, tir, guidage, ...) ou coordonnée à l'aide d'un centre de commandement et de contrôle (« Command & Control (C2) » en anglais). Il peut être fixe ou embarqué sur un engin terrestre, un navire ou un aéronef. Ainsi, un armement est qualifié de système d'arme lorsqu'il intègre différents équipements pour fonctionner (capteurs, dispositifs électroniques, moyens de communication, ...) . L'interfacage d'un système d'arme à une liaison de données tactiques pose différents problèmes liés notamment au nombre et à la complexité des interfaces impliquées, et en particulier :

- un problème fonctionnel. En effet, la définition du standard de liaison de données, définit à la fois le type d'informations échangées et la façon d'utiliser les informations. Ce fonctionnement implique une intersection pouvant être importante entre les fonctions du centre de commandement et contrôle et les fonctions de gestion de la liaison de données. L'interfacage d'un système d'arme nécessite alors plusieurs types de fonctions : des fonctions opérationnelles nécessaires pour faire le lien entre les missions du système et les fonctions d'interface à réaliser, ainsi que des fonctions en communication et liaison de données pour implémenter de façon fiable et performante la liaison. Ces fonctions sont parfois mélangées, créant ainsi des interfaçages systèmes peu adaptés au contexte opérationnel ou des liaisons de données peu fiables ; et

- un problème de gestion de configuration. Le système d'arme et le standard de liaison de données ont leur propre cycle de vie. Cela pose des difficultés d'ingénierie système pour gérer les évolutions des interfaces lors des phases de conceptions et de maintien en conditions opérationnelles. De plus, le standard d'interopérabilité, ainsi que les différents systèmes auxquels il doit se connecter, évoluent lors de la vie du système. Pour ces raisons, l'interfacage du système d'arme nécessite des évolutions régulières.

Les évolutions des systèmes d'arme actuels, sont souvent problématiques, et de nombreux systèmes d'arme sont peu mis à jour et utilisent des versions de liaisons de données différentes pouvant créer certains problèmes d'interopérabilité.

L'interface du système d'arme à la liaison de données tactiques est généralement mise en œuvre par un composant logiciel et matériel. par exemple un composant de type DLP (pour « Data Link Processor » en anglais). Son rôle est de permettre au système d'envoyer et de recevoir des messages de la liaison de données. Plusieurs conceptions de composants DLP existent :

- un logiciel DLP monobloc réalisant toutes les fonctions de liaison de données et disposant d'une interface propriétaire qui peut être complexe afin de gérer les redondances entre les fonctions similaires se trouvant dans le système d'arme et le composant ; et

- une librairie DLP nécessitant de s'interfacer directement ou quasi directement avec le cœur du système d'arme et qui ne permet plus une gestion de configuration du système d'arme séparée de sa liaison de données.

L'un des inconvénients majeurs des solutions usuelles est leur manque de modularité ainsi qu'un mélange des aspects opérationnels et des aspects techniques (transmission de données) . Ces solutions ne permettent pas au systémier (entreprise conceptrice du système d'arme) de se concentrer uniquement sur son cœur de métier, à savoir l'interfaçage opérationnel de son système d'arme.

Deux organisations sont alors possibles :

- soit le systémier réalise entièrement le composant DLP. Il doit alors développer et maintenir la couche de communication (souvent complexe) pour un coût supérieur à ce que proposerait un sous-traitant spécialiste, qui mutualise les coûts sur tous ses clients ;

- soit le systémier achète la solution monobloc, mais n'a plus la maîtrise totale de l'information opérationnelle émise par son système. L'interface avec le système lui est imposée, le composant monobloc interprète et traduit l'information avec des risques d'erreurs ou de difficultés.

Ces solutions monobloc peuvent également être plus difficiles à faire évoluer pour prendre en compte une évolution d'une norme, un changement de comportement opérationnel ou même un changement de moyen de communication.

La présente invention concerne une interface qui a pour objet de remédier à certains des inconvénients précités. L'interface comprend au moins certains des avantages suivants : elle permet au concepteur d'un système d'arme, de faciliter l'intégration et l'évolution des liaisons de données tactiques dans le système d'arme, afin de gagner en évolutivité, tout en gardant la maîtrise du système d'arme, en diminuant les coûts, en conservant la fiabilité de la liaison et en s'appuyant sur les compétences de spécialistes des liaisons de données tactiques.

La présente invention concerne une interface entre un système d'arme et au moins une liaison de données tactiques, ladite interface étant configurée pour être liée d'une part à un réseau du système d'arme et d'autre part à une unité de communication d'une liaison de données tactiques conforme à un standard particulier, ladite interface comprenant un ensemble de gestion de données.

Selon l'invention, ledit ensemble de gestion de données est de type modulaire et comprend un premier module mettant en œuvre au moins une fonction opérationnelle et au moins un second module mettant en œuvre au moins une fonction de communication, lesdits premier et second modules liés ensemble via une liaison dite de transmission, et :

- ladite liaison de transmission présente un standard simplifié directement dérivé du standard de la liaison de transmission de données ;

- ledit premier module est apte à être lié audit réseau du système d'arme et il est configuré :

• pour traduire un message dit système, reçu dudit réseau, en un message dit intermédiaire, avant une transmission par la liaison de transmission audit second module ; • pour traduire un message intermédiaire reçu via la liaison de transmission en au moins un message système, avant une transmission vers ledit réseau ; et

- ledit second module est apte à être lié à l'unité de communication et il est configuré :

• pour coder un message intermédiaire reçu dudit premier module en un message standard de la liaison de données tactiques, avant une transmission vers ladite unité de communication ; et

• pour décoder un message standard reçu et le traduire en un message intermédiaire, avant une transmission audit premier module.

Ainsi, grâce à l'invention, on obtient une interface présentant une architecture modulaire qui sépare la ou les fonctions opérationnelles de la ou des fonctions de communication (ou de transmission de données), comme précisé ci-dessous. Plus particulièrement, le premier module réalise les fonctions opérationnelles. Il conçoit l'information à émettre et aiguille l'information reçue. Le concepteur du système d'arme garde ainsi l'entière maîtrise des messages envoyés, en sous-traitant les fonctions de transmission de données (mises en œuvre par le second module) qui ne font pas partie de son cœur de métier. Cette architecture modulaire et évolutive limite l'impact d'une modification d'une fonction (opérationnelle ou de communication) dans un module sur l'autre module et autorise plus facilement le remplacement complet du second module.

De façon avantageuse, ledit premier module est configuré pour :

- appliquer des premières règles prédéterminées d'émission de message système ;

- réaliser une sélection opérationnelle des informations à transmettre par la liaison de transmission ; - réaliser une vérification d'une cohérence opérationnelle d'un message intermédiaire reçu via la liaison de transmission.

En outre, de façon avantageuse, ledit premier module met en œuvre au moins une règle de traduction en émission et au moins une règle de traduction en réception, la règle de traduction en émission spécifie la correspondance entre des champs d'un message système et des champs d'un message intermédiaire, ainsi que le type de conversion, et la règle de traduction en réception spécifie la correspondance entre des champs d'un message intermédiaire et des champs d'un ou plusieurs messages système.

Par ailleurs, avantageusement, ledit second module est configuré pour :

- appliquer des secondes règles prédéterminées d'émission de message ;

- réaliser une gestion du débit d'émission ;

- réaliser une vérification du formatage de messages reçus de la liaison de données tactiques.

Dans un mode de réalisation préféré, ladite liaison de transmission est déterminée en fonction d'une liaison de données tactiques de l'un des types suivants :

- une liaison L1 6 ;

- une liaison L1 1 ;

- une liaison L22.

En outre, dans un mode de réalisation particulier, l'interface comporte un premier module unique et au moins deux seconds modules, dont chacun est lié audit premier module via une liaison de transmission. Dans un mode de réalisation particulier, la liaison de transmission est une liaison générique multi-protocole. Une telle liaison générique multi- protocole est donc compatible avec l'invention. Par ailleurs, dans une première variante de réalisation, l'interface comporte au moins deux éléments matériels, le premier module étant intégré dans l'un de ces éléments matériels et le second module étant intégré dans l'autre de ces éléments matériels.

En outre, dans une seconde variante de réalisation, l'interface comporte un élément matériel, les premier et second modules étant tous deux intégrés dans cet élérnent matériel.

La présente invention concerne également un système d'arme, qui comporte au moins une interface telle que décrite ci-dessus.

La présente invention concerne, en outre, un procédé d'interfaçage entre un système d'arme et au moins une liaison de données tactiques, pour réaliser une interface entre d'une part un réseau du système d'arme et d'autre part une unité de communication de la liaison de données tactiques conforme à une spécification particulière (standard ou propriétaire).

Selon l'invention, ledit procédé comprend :

- une première étape mise en œuvre dans un premier module réalisant au moins une fonction opérationnelle et apte à être lié audit réseau du système d'arme, la première étape consistant :

• dans un sens sortant du système d'arme, à traduire un message dit système, reçu dudit réseau du système d'arme, en un message dit intermédiaire, avant une transmission par une liaison de transmission à un second module, ladite liaison de transmission présentant un standard simplifié directement dérivé du standard de la liaison de transmission de données ; et

• dans un sens entrant dans le système d'arme, à traduire un message intermédiaire reçu via la liaison de transmission en un message système, avant une transmission vers ledit réseau ; et - une seconde étape mise en œuvre dans le second module réalisant au moins une fonction de communication et apte à être lié à l'unité de communication, la seconde étape consistant :

• dans un sens sortant du système d'arme, à coder un message intermédiaire reçu dudit premier module en un message adapté à l'unité de communication de la liaison de données tactiques, avant une transmission vers ladite unité de communication ; et

• dans un sens entrant dans le système d'arme, à décoder un message standard reçu et à le traduire en un message intermédiaire, avant une transmission audit premier module

Les figures annexées feront bien comprendre comment l'invention peut être réalisée. Sur ces figures, des références identiques désignent des éléments semblables.

La figure 1 est le schéma synoptique d'une interface selon un mode de réalisation préféré de l'invention.

La figure 2 est le schéma synoptique d'un mode de réalisation particulier d'une interface.

L'interface 1 illustrant l'invention et représentée schématiquement sur la figure 1 est destinée à créer une liaison à double sens entre un système d'arme 2 et au moins une liaison de données tactiques 3 représentée schématiquement, qui est conforme à un standard (ou protocole standard) particulier, comme précisé ci-dessous.

Plus précisément, cette interface 1 est configurée pour être liée d'une part à un réseau 4 du système d'arme 2 et d'autre part à une unité de communication 5 apte à communiquer avec la liaison de données tactiques 3, comme illustré par une flèche 6.

L'interface 1 , le réseau 4 et le moyen de communication 5 sont embarqués sur le système d'arme 2. L'interface 1 comprend un ensemble 7 de gestion de données. Selon l'invention, cet ensemble 7 de gestion de données est de type modulaire, et il comporte un premier module 8 et au moins un second module 9 liés ensemble via une liaison 10 dite de transmission.

De plus, selon l'invention :

- la liaison de transmission 1 0 présente un standard simplifié qui est directement dérivé du standard (par exemple liaison L1 6) de la liaison de transmission de données 3. On entend par « directement dérivé » (ou « calqué ») que la liaison de transmission 10 est une liaison simplifiée, basée sur le standard de la liaison de transmission de données 3, dont on a uniquement conservé les caractéristiques nécessaires, comme précisé ci- dessous ;

- le module 8 (par exemple, un module dit « haut ») met en œuvre une ou plusieurs fonctions opérationnelles, il est apte à être lié au réseau 4 du système d'arme 2, comme illustré par une liaison 1 1 , et il comporte une unité de traduction 1 2 configurée :

• pour traduire un message dit système, reçu du réseau 4 (via la liaison 1 1 ), en un message dit intermédiaire, avant une transmission par la liaison de transmission 10 au module 9 ; et

• pour traduire un message intermédiaire reçu via la liaison de transmission 10 en au moins un message système, avant une transmission (via la liaison 1 1 ) vers le réseau 4 ; et

- le module 9 (par exemple, un module dit « bas ») met en œuvre une ou plusieurs fonctions de communication, il est apte à être lié à l'unité de communication 5 comme illustré par une liaison 1 3, et il comporte une unité de codage/décodage 14 configurée :

• pour coder un message intermédiaire reçu du module 8 (via la liaison de transmission 10) en un message standard de la liaison de données tactiques, avant une transmission vers l'unité de communication 5 (via la liaison 1 3) ; et • pour décoder un message standard reçu (via la liaison 1 3) et le traduire en un message intermédiaire, avant une transmission au module 8 (via la liaison de transmission 10).

Chacun des modules 8 et 9 peut être un composant d'un DLP (pour « Data Link Processor » en anglais) .

Dans le cadre de la présente invention :

- le système d'arme 2 représente un ensemble de dispositifs mécaniques, électroniques et/ou logiciels permettant à des militaires la réalisation d'une mission et la mise en œuvre d'un armement. Il peut être fixe ou embarqué sur un engin terrestre, un navire ou un aéronef ;

- le réseau 4 du système d'arme 2 comprend une unité de traitement de données, de calcul et/ou de commande qui met en œuvre des algorithmes usuels pour la commande du système d'arme. Généralement, ce réseau 4 représente le cœur du système d'arme et permet de dialoguer avec toutes les fonctions du système d'arme, par exemple la gestion de la situation tactique, les états des sous systèmes, les commandes armements, ... ;

- l'unité de communication 5 correspond à tout type de moyen de communication usuel permettant de communiquer, par une liaison 6 filaire ou radio par exemple, avec la liaison de données tactiques 3 ;

- une fonction opérationnelle est une fonction réalisée par le système d'arme 2, concernant le fonctionnement et la mise en œuvre du système d'arme 2 ;

- une fonction de communication ou de transmission de données est Une fonction relative à la gestion et à la mise en œuvre d'une transmission de données.

Avec cette architecture de l'interface 1 comprenant deux modules 8 et 9 distincts, on décorrèle les tâches de création du contenu d'un message (mises en œuvre par le module 8) des tâches de formatage et de transmission du message (mises en œuvre par le module 9). On prévoit ainsi, à partir d'une librairie DLP, d'ajouter une interface 1 standardisée et simplifiée entre des fonctions (dans le module 8) ayant un lien fort avec le système d'arme (opérationnel) et des fonctions (dans le module 9) présentant un intérêt uniquement relatif à la liaison de données (technique).

Dans le but de permettre la transmission de toutes les informations possibles par la liaison de données standard (par exemple une liaison L1 6) et éviter des erreurs d'interprétation de la part du module 9, on ne met pas en œuvre de sélection de champs utiles : il y a une correspondance 1 pour 1 entre les messages standards et les messages intermédiaires.

En outre, pour être facile à implémenter et décoder, la liaison de transmission 1 0 (pour les messages intermédiaires) s'affranchit des contraintes de codage du standard. Les informations sont codées en type informatique classique (int, double, char,...) et en unités SI.

La liaison de transmission 1 0 est asynchrone et bidirectionnelle. Elle n'est pas contrainte en débit ou synchronisation d'émission (chaque composant émet une information quand il le souhaite).

L'interface 1 est ainsi configurée pour permettre de transmettre toutes les informations utiles, être facile à intégrer et à faire évoluer.

L'interface 1 permet au concepteur du système d'arme 2 de faciliter l'intégration et l'évolution des liaisons de données tactiques dans le système d'arme 2, afin de gagner en évolutivité, tout en gardant la maîtrise du système d'arme 2, en diminuant les coûts, en conservant la fiabilité de la liaison et en s'appuyant sur les compétences de spécialistes des liaisons de données tactiques.

Le module 8 de l'interface 1 assure donc la traduction entre les messages système et les messages intermédiaires, et inversement. La relation messages système/messages intermédiaires n'est pas bijective. Le module 8 est configuré pour appliquer des premières règles prédéterminées d'émission de message système correspondant à la politique d'émission (quand envoyer un message, quel message envoyer avec quel contenu), en fonction de l'état du système et des messages système reçus.

Par ailleurs, le module 8 comporte une unité de sélection 1 5 qui réalise une sélection opérationnelle des informations à transmettre par la liaison de transmission 10. Cette unité de sélection 1 5 réalise également une synthèse des états du système.

Le module 8 comporte également une unité de vérification 1 6 qui, en réception, vérifie la cohérence opérationnelle d'un message (complétion des données pour être correctement interprétées par le système, cohérence des données du message) et traduit le message en un ou plusieurs messages système. La vérification de la cohérence des données peut consister à vérifier des champs obligatoirement remplis, des champs avec une plage de valeurs autorisées. Ces vérifications peuvent être conditionnelles au remplissage d'un champ (si un champ X est renseigné, alors un champ Y doit également être renseigné).

En outre, le module 8 met en œuvre des règles de traduction en émission et des règles de traduction en réception. Une règle de traduction en émission spécifie la correspondance entre des champs d'un message système et des champs d'un message intermédiaire, ainsi que le type de conversion. En outre, une règle de traduction en réception spécifie la correspondance entre des champs d'un message intermédiaire et des champs d'un ou plusieurs messages système. Plusieurs règles de conversion peuvent être spécifiées en fonction d'un état ou d'une valeur spécifique d'un champ.

Par ailleurs, le module 9 de l'interface 1 traduit donc les messages intermédiaires en messages standard (STANAG), à l'aide de l'unité de codage/décodage 1 4. La relation entre les messages intermédiaires et les messages standard est bijective.

Le module 9 se connecte à l'unité de communication 5 (radio, routeur, ...) en respectant un protocole standard (STANAG, par exemple SIMPLE, JREAP, ... ) ou propriétaire.

Le module 9 comporte une unité de gestion 1 7 qui gère le débit de connexion (type de messages, sous-échantillonnage de messages, gestion des priorités, ... ) . Il applique des règles d'émission de messages qui correspondent à la politique d'émission sélectionnée par l'opérateur. Dans le cas du protocole JREAP (pour « Joint Range Extension Applications Protocol » en anglais), le module 9 simule l'unité de communication en émettant des accusés de réception machine.

Le module 9 comporte également une unité de vérification 1 8 qui, en réception, vérifie le formatage correct des messages.

Dans un mode de réalisation préféré, ladite liaison de transmission

10 est calquée (en étant simplifiée) sur une liaison de données tactiques standard (qui est complexe), de préférence de l'un des types suivants :

- une liaison L1 6 (de série J) ;

- une liaison L1 1 (de série M) ;

- une liaison L22 (de série J) .

Bien entendu, cette liste de liaison de données tactiques possibles n'est pas exclusive.

Dans un mode de réalisation préféré, la liaison de données tactiques considérée est une liaison L1 6. La liaison L1 6 est un standard de liaison de données tactiques de l'OTAN pour l'échange d'informations tactiques entre des unités militaires. Le contenu de sa messagerie et le protocole d'émission sont définis par le STANAG 551 6 pour l'OTAN. Sa mise en œuvre opérationnelle est définie dans le document OTAN ADatP 33 qui est un ensemble de procédures permettant la mise en œuvre d'un réseau de liaisons de données tactiques multi-liaisons et de l'ADatP 1 6 propre à la liaison L1 6.

Pour la création des messages intermédiaires (relatifs au standard L1 6 par exemple), l'interface 1 (et notamment le module 9) tient compte des caractéristiques suivantes :

- valeurs physiques (LSB, ...) : double unité SI ;

- énumérés : « short », codage L1 6 ;

- caractères (TN, VCS, ...) : « char string » ;

- énumérés booléen : « short » (booléen) ;

- énumérés hybride (valeurs physiques avec LSB + énumérés, par exemple « Voice Frequency Channel ») : « short » avec codage L1 6, pas de conversion ; et

- « switch » (énuméré indiquant quel champ est actif) . Tous les champs possibles sont inclus dans le message intermédiaire (énumérés et champs possibles).

Les détails de la composition des messages intermédiaires peuvent changer en fonction des besoins et contraintes du système d'arme. Ainsi, certaines règles ci-dessus peuvent être modifiées. En particulier, on peut prévoir :

- la sélection d'une partie seulement d'un message standard, en enlevant les parties totalement inutiles au système ;

- l'utilisation d'une unité non SI, par exemple pour éviter des doubles conversions inutiles ; et

- l'ajout de contraintes en débit sur la liaison intermédiaire. Cet ajout peut être nécessaire si le débit des messages système est trop important.

L'interface 1 , telle que décrite ci-dessus, présente donc une architecture modulaire qui sépare les fonctions opérationnelles des fonctions de communication (ou transmission). Plus particulièrement, le module 8 réalise les fonctions opérationnelles. Il conçoit l'information à émettre et aiguille l'information reçue. Le concepteur du système d'arme garde ainsi l'entière maîtrise des messages envoyés, en sous-traitant les fonctions de transmission de données (mises en œuvre par le module 9) qui ne font pas partie de son cœur de métier. Cette architecture modulaire et évolutive limite l'impact d'une modification d'une fonction (opérationnelle ou de communication) dans un module 8, 9 sur l'autre module 9, 8, et autorise plus facilement le remplacement complet du module 8 ou 9.

L'interface 1 permet ainsi de :

- faire évoluer facilement le comportement du système d'arme 2 sur la liaison de données tactiques, sans contraintes liées aux aspects de communication ; et

- faire évoluer facilement les standards ou moyens de communication sans impacter le système d'arme 2.

L'interface 1 est par conséquent simple et facile à implémenter. Elle est facilement évolutive afin de suivre les modifications des composants. Elle se concentre sur le contenu du message sans pour autant présenter d'ambiguïtés nécessitant des interprétations du module 9 (transmission de l'information).

Dans un mode de réalisation particulier représenté sur la figure 2, l'interface 1 comporte un module 8 unique et au moins deux modules 9A et 9B, dont chacun est lié audit module 8 via une liaison de transmission 10.

Dans ce cas, on peut utiliser l'interface 1 pour connecter le système d'arme 2 à plusieurs liaisons de données tactiques différentes (via lesdits modules 9A et , 9B) . Le module 8 gère alors plusieurs liaisons de données et traite les messages en fonction des besoins du système d'arme 2 (avec une adaptation en temps réel possible). Les différentes liaisons de transmission 1 0 sont conçues de la même façon et peuvent partager le même moyen de communication.

Par ailleurs, dans une première variante de réalisation (non représentée), l'interface 1 comporte au moins deux éléments matériels. Le module 8 est intégré dans l'un de ces éléments matériels et le module 9 est intégré dans l'autre de ces éléments matériels.

En outre, dans une seconde variante de réalisation (non représentée), l'interface 1 comporte un élément matériel. Les modules 8 et 9 sont tous deux intégrés dans ce même élément matériel.

L'interface logicielle de l'interface 1 n'est pas imposée. Elle peut être réalisée via une connexion réseau classique (UDP, TCP, ...) afin de distribuer les composants logiciels sur différents machines ou bien pour une intégration d'un des composants DLP via des API, ou même une intégration de code source, l'interface étant alors une interface de fonctions logicielles.