FR2819964A1

FR2819964A1 - Procede de selection des applications activables au travers d'un reseau de communication aeronautique civil

Info

Publication number: FR2819964A1
Application number: FR0100877A
Authority: FR
Inventors: Nicolas Rossi
Original assignee: Thomson CSF SA
Current assignee: Thales SA
Priority date: 2001-01-23
Filing date: 2001-01-23
Publication date: 2002-07-26
Anticipated expiration: 2021-01-23
Also published as: US20030139135A1; WO2002060155A1; FR2819964B1; EP1266509A1; US6965771B2

Abstract

On propose, pourune meilleure rentabilité du réseau aéronautique de télécommunicationsATN, de soumettre les demandes de connexions au travers du réseau ATNprovenant d'applications non-ATC, à une validation des adresses demandéesau moyen de deux tables de disponibilités maintenues à jouret placées dans le terminal hébergeant les applications sollicitantles connexions. L'une des tables concerne la disponibilitédes applications locales et sert à renseigner les terminaux distants.L'autre table concerne la disponibilité des applications distanteset sert pour la validation des demandes de connexion émanant des applicationslocales.

Description

PROCEDE DE SELECTION DES APPLICATIONS ACTIVABLES AU TRAVERS D'UN RESEAU DE COMMUNICATION AERONAUTIQUE CIVIL
La présente invention concerne la gestion des communications autres que celles dédiées au contrôle du trafic aérien, échangées entre un aéronef et le sol.

La densification du trafic aérien, le souci permanent de maintenir et même d'accroître la sécurité ainsi que celui d'améliorer la gestion d'un vol conduisent à une demande toujours plus importante d'échanges d'informations entre un aéronef, qu'il soit en vol ou au sol, et des centres au sol. Cette demande qui est encore renforcée par une augmentation rapide des capacités de traitement d'informations des équipements embarqués à bord d'un aéronef se trouve freinée par la capacité limitée d'acheminement d'informations du réseau de radiocommunication utilisé actuellement entre les aéronefs civils et le sol. Pour supprimer ce goulot d'étranglement, l'Organisation de l'Aviation Civile Internationale a prévu, le déploiement d'un nouveau réseau de communication aéronautique civil beaucoup plus performant dit"ATN" (sigle tiré de l'anglo-saxon :"Aeronautical Telecommunication Network") dont elle a défini les grandes lignes par des documents contraignants dits"recommandations".

Le réseau aéronautique de télécommunication ATN, qui est en train d'être mis progressivement en place à la surface du globe, est un réseau de transmission de données numériques à vocation généraliste, dédié à l'acheminement de toutes les informations que des aéronefs sont susceptibles d'échanger avec le sol dans un futur proche. Parmi ces informations, il est habituel de faire la distinction entre celles ressortant de l'activité du contrôle aérien dite"ATC" (sigle tiré de l'anglo-saxon :"Air Traffic Control") pour lesquels la transmission est soumise à une exigence de très grande fiabilité, et les autres dites"non-ATC comme par exemple, celles dites AAC (sigle tiré de l'anglo-saxon :"Aeronautical Administrative Communications") ressortant de l'exploitation commerciale du vol telles que la liste des passagers du vol, la liste du ravitaillement des passagers et de l'équipage, la liste des ventes hors-taxes proposées à bord, etc., celles dites AOC (sigle tiré de l'anglo-saxon : "Airline Operation Control") ressortant de l'exploitation technique de l'aéronef telles que la consommation de l'aéronef

et diverses informations de maintenance et celles dites APC (sigle tiré de l'anglo-saxon :"Aeronautical Public Correspondence") ressortant du confort des passagers telles que le téléphone, les informations passagers, etc. pour lesquelles la fiabilité de la transmission est moins critique.

Les recommandations de l'OACI fixent dans le détail, de manière contraignante, la méthode de gestion des communications au travers du réseau aéronautique de télécommunication ATN, essentiellement, l'adressage, l'établissement, le maintien et l'achèvement d'une communication, et les applications dites"ATC"remplissant des tâches impliquant des échanges d'informations de type ATC au travers du réseau aéronautique ATN. Par contre, elles ne s'intéressent pas aux autres applications dites"non-ATC"remplissant des tâches n'impliquant pas d'échanges d'informations de type ATC au travers du réseau aéronautique

de télécommunication ATN. Ces applications non-ATC sont laissées à l'initiative de chaque intervenant, la seule contrainte étant le respect de la méthode de gestion des communications imposée pour l'établissement, le maintien et l'achèvement d'une communication au travers du réseau aéronautique de télécommunication ATN.

Les applications non-ATC sont donc développées par les intervenants, en pratique les compagnies aériennes, selon leurs besoins propres, sans souci d'uniformisation, autre que celui du respect de la méthode imposée de gestion des communications au sein du réseau aéronautique de télécommunication ATN. De plus, la fiabilité étant moins critique que dans le cas des applications ATC, les applications non-ATC ne sont pas développées avec la même rigueur, notamment méthodologique, que les applications ATC, ce qui joue encore à l'encontre de leur uniformisation.

A l'heure actuelle, les messages des applications non-ATC sont émis sur le réseau aéronautique ATN sans coordination préalable entre le bord d'un aéronef et le sol. Une application"bord", c'est-à-dire gérée depuis le bord d'un aéronef, peut émettre des messages par l'intermédiaire du réseau aéronautique de télécommunication, à destination du sol, soit spontanément, soit sur interrogation depuis le sol. Quel que soit le mode de fonctionnement choisi, il n'y a pas de coordination et les messages sont émis en aveugle sans savoir si le destinataire du message est disponible, la bonne

réception étant constatée par la demande d'un accusé de réception ou par l'exécution de la tâche demandée. Comme une application table sur la disponibilité de son correspondant, ce manque de coordination peut amener une application à multiplier les essais infructueux de transmission, au moins autant de fois que le nombre admis pour décréter la présence d'un problème dans la transmission, alors que toute tentative de transmission était vouée dès l'origine, à un échec du fait d'une absence du destinataire recherché, par exemple, par le fait que l'aéronef ou le centre au sol interrogé n'a jamais disposé ou ne dispose plus momentanément de l'application voulue. En effet, les degrés d'équipement des aéronefs sont très divers et les centres au sol interrogés peuvent être victimes d'indisponibilités passagères prévues ou non, de certaines de leurs applications. Ces vaines tentatives d'appel occupent inutilement les ressources de communication air/sol du réseau aéronautique de télécommunication ATN et peuvent se révéler coûteuses pour les intervenants, le réseau aéronautique de télécommunication étant facturé non seulement au nombre de données effectivement transmises mais également à chaque demande de connexion.

La présente invention a pour but de limiter les coûts liés à l'utilisation du réseau aéronautique de télécommunication et la charge de ce réseau dont les capacités ne seront jamais illimitées, en évitant que les applications non-ATC ne tentent des connexions au travers du réseau aéronautique de télécommunication vouées dès l'origine à un échec, du fait de l'incapacité temporaire ou définitive du destinataire à exécuter la tâche demandée car ne disposant pas, de manière temporaire ou définitive de l'application adéquate.

Elle a pour objet un procédé de sélection des applications activables au travers d'un réseau aéronautique de télécommunication, remarquable en ce qu'il consiste, à pourvoir le terminal de raccordement au réseau aéronautique de télécommunication d'un intervenant à des applications non-ATC, : de deux tables de disponibilité d'applications, l'une locale répertoriant les applications disponibles localement, au niveau du terminal de raccordement de l'intervenant et l'autre distante répertoriant les applications disponibles au niveau des terminaux de raccordement d'un ou plusieurs correspondants

privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant a déjà tenté au préalable, d'entrer en relation avec eux au travers du réseau aéronautique de télécommunication, * des moyens de consultation de la table de disponibilité locale activés par demande d'un terminal de raccordement distant, * des moyens de consultation de la table de disponibilité distante qui sont activés, à chaque tentative faite par une application pour se connecter au travers du réseau aéronautique de télécommunication et qui, soit autorise la connexion si le correspondant demandé est répertorié dans la table de disponibilité distante pour l'application considérée, soit la refuse si le correspondant demandé ne figure pas dans la table de disponibilité distante pour l'application considérée, * des moyens d'interrogation à distance des tables de disponibilité locale des correspondants joignables au travers du réseau aéronautique de télécommunication, 'des moyens de mise à jour de la table de disponibilité locale de l'intervenant opérant par surveillance de la disponibilité des applications possédées par l'intervenant, et . des moyens de mise à jour de la table de disponibilité distante opérant par recopie au moins partielle des tables de disponibilité locale des correspondants en activant les moyens d'interrogation à distance.

Avantageusement, la table de disponibilité locale est réinitialisée à la mise en route du terminal de raccordement considéré.

Avantageusement, la mise à jour de la table de disponibilité locale se fait en fonction des alarmes de dysfonctionnement et des avis de fin de non-disponibilité engendrés par les applications locales non-ATC.

Avantageusement, la mise à jour de la table de disponibilité locale se fait de manière systématique et périodique.

Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal de raccordement considéré, avec un contenu obtenu par recopie à distance des contenus des tables de disponibilité locale de terminaux distants de raccordement au réseau aéronautique de télécommunication listés au préalable.

Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réel et théorique de leurs tables de disponibilité locale.

Avantageusement, les moyens de consultation de la table de disponibilité locale sont sensibles à au moins deux types de requêtes de la part d'un terminal distant, une requête générale sur le contenu global de leur table de disponibilité locale et une requête particulière sur les différences entre les contenus réel de leur table de disponibilité locale et ceux théoriques ou précédemment notifiés.

Avantageusement, la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables de disponibilité locale.

Avantageusement, un terminal de raccordement au réseau aéronautique de télécommunication, en présence d'un changement d'état de disponibilité de l'une de ses applications non-ATC, avertit de ce changement d'état de disponibilité tous les terminaux de raccordement distants référencés dans sa table distante de disponibilité pour mettre en concordance leurs tables de disponibilité distante.

Avantageusement, lorsque le terminal de raccordement au réseau aéronautique de télécommunications renferme un automate à

microprocesseur assurant la gestion des communications sous le contrôle de différents modules logiciels spécialisés appelés en fonction de la nature de la tâche à effectuer : module logiciel CMA pour l'initialisation, maintien et achèvement d'une communication applicative, module logiciel SN-SME pour le maintien et l'achèvement d'une connexion au sein du réseau aéronautique de télécommunication, module logiciel IRDP pour le routage d'une communication, module logiciel Applis ATC pour l'exécution d'applications préchargées ATC et modules logiciels Applis non-ATC pour l'exécution d'applications préchargées non-ATC, les moyens de consultation de la table de disponibilité distante et de mise à jour des tables locale et distante de disponibilité sont constitués dudit automate à microprocesseur opérant sous le contrôle d'un module logiciel spécifique de validation d'appel, qui gère les moyens de consultation et de mise à jour des tables de disponibilités locale et distante, intercepte les demandes de connexion des applications locales non-ATC et vérifie la disponibilité de leur correspondant avant d'autoriser une poursuite de leur traitement.

Avantageusement, le module logiciel de validation des appels surveille la fraîcheur des informations contenues dans les tables de disponibilités locale et distante et procède à leurs mises à jour dès qu'elles atteignent une date de péremption fixée arbitrairement.

D'autres caractéristiques et avantages de l'invention ressortiront de la description ci-après d'un mode de réalisation donné à titre d'exemple.

Cette description sera faite en regard du dessin dans lequel : - une figure 1 schématise le réseau aéronautique de télécommunication ATN, - une figure 2 schématise un premier exemple de routeur embarqué de réseau aéronautique de télécommunication ATN mettant en oeuvre l'invention, et - une figure 3 représente, sous forme d'organigramme, un exemple de méthode de validation d'une adresse d'appel.

Le réseau aéronautique de télécommunication ATN vise à assurer des liaisons numériques sol-bord, fiables et à haut débit pour des échanges

d'informations entre des aéronefs au sol ou en vol et des centres au sol, que ces centres soient affectés à une activité de contrôle aérien, les informations échangées avec les autorités du contrôle aérien étant dites ATC, ou à une activité d'exploitation de l'aéronef ou du vol, les informations échangées avec la ou les compagnies exploitant l'aéronef qui peuvent être très diverses étant dites non-ATC, la distinction entre les deux types d'informations se justifiant par des contraintes de transmission différentes au niveau de la sécurité et de la fiabilité.

Comme toute liaison numérique, le réseau aéronautique de télécommunication ATN permet des échanges d'informations ou dialogues, entre deux tâches ou applications déroulées par des processeurs distants, en général un processeur placé à bord d'un aéronef et un processeur placé au sol. Les applications pouvant dialoguer entre elles par le réseau aéronautique de télécommunication ATN sont dites ATC ou non-ATC selon la nature ATC ou non-ATC des informations qu'elles échangent.

l
Le réseau aéronautique de télécommunication ATN est conçu pour utiliser les différents médias envisageables pour des liaisons air-sol (HF, VHF, radar mode S, UHF par satellite) et pour utiliser au sol des réseaux de transmission de données spécialisés ou non, commutés ou non, par câble ou ondes hertziennes, relayées ou non par satellite, afin de faire parvenir les informations transmises à destination.

Comme représenté à la figure 1, le réseau aéronautique de télécommunication ATN comporte une partie aérienne 1 à bord de chaque aéronef 2 raccordé et une partie terrestre 3.

La partie aérienne 1 se compose de divers équipements émetteurs-récepteurs embarqués sur un aéronef 2 et adaptés aux différents médias utilisables pour les communications air-sol. Ces équipements émetteurs-récepteurs et leurs correspondants au sol constituent des sousréseaux de transmission. Sur la figure 1, est représenté un aéronef 2 avec une partie aérienne 1 de réseau aéronautique de transmission ATN comportant plusieurs émetteurs-récepteurs dont un émetteur-récepteur 10 constituant une tête de sous-réseau de transmission mode VDL 2 opérant en VHF selon un protocole spécifique normalisé, un émetteur-récepteur 11 constituant une tête de sous-réseau de transmission mode HF DL opérant en

HF selon un autre protocole spécifique normalisé, un émetteur-récepteur 12 constituant une tête de sous-réseau de transmission mode S opérant en
UHF en collaboration avec un radar secondaire selon un autre protocole également normalisé et un émetteur-récepteur 13 constituant une tête de sous-réseau de communication AMSS (abréviation de l'anglo-saxon "Aeronautical Mobile Satellite System") mode Satcom data 3 opérant en
UHF avec un relais satellitaire 4, selon encore un autre protocole normalisé.

Ces divers émetteurs-récepteurs 10, 11, 12,13 peuvent présenter des parties communes de sorte que les différents sous-réseaux peuvent ne pas être tous disponibles simultanément. Ils peuvent même ne pas être présents au complet sur un aéronef, cela dépendant du degré d'équipement de l'aéronef considéré. Ils sont gérés à bord d'un aéronef par un automate 14 dit routeur qui, en plus de leur gestion, assure, par manipulation d'une pile mémoire dans laquelle transitent les données à échanger avec le sol, l'initialisation, le maintien et l'achèvement d'une communication sous le contrôle d'un module logiciel dit CMA (abréviation de l'expression anglosaxonne"Context Management Agent"), le routage d'une communication sous le contrôle d'un module logiciel dit IORP (abréviation de l'anglo-saxon "Inter Domain Routing Policy"), l'exécution d'applications préchargées de contrôle aérien comme la communication périodique de la position de l'aéronef au contrôle au sol sous le contrôle d'un module logiciel dit"Applis ATC"et l'exécution d'applications préchargées de gestion de flotte comme le suivi de la consommation de l'aéronef sous le contrôle d'un module logiciel dit"Applis non-ATC".

La partie terrestre du réseau aéronautique de télécommunication ATN se compose de stations sol de routage 5, 6. Ces stations sol de routage 5,6 sont équipées de moyens de communication sol-air, émetteursrécepteurs HF-VHF 7, radar mode S 8, station terrestre de communication par satellite 9, leur permettant de communiquer avec les aéronefs passant dans leurs voisinages selon un ou plusieurs des modes de communication prévus : sous-réseau Satcom Data 3, sous-réseau VDL mode 2, sous-réseau Mode S ou sous-réseau mode HF DL et reliées entre elles et à divers centres au sol 15,16 intéressés par des échanges d'informations avec les aéronefs, par des réseaux de transmission numérique de données spécialisés ou non,

commutés ou non, utilisant le câble ou les ondes hertziennes relayées ou non par satellite.

A l'heure actuelle, les applications non-ATC ne sont pas réglementées et sont développées par les différents intervenants, en pratique les compagnies aériennes, selon leurs besoins propres, sans souci d'uniformisation, autre que celui du respect de la méthode imposée de gestion des communications au sein du réseau aéronautique de télécommunication ATN. Leurs demandes de connexion sont émises sur le réseau aéronautique ATN sans coordination préalable entre le bord d'un aéronef et le sol.

Une application"bord"non-ATC, c'est-à-dire gérée depuis le bord d'un aéronef, peut émettre des messages par l'intermédiaire du réseau aéronautique de télécommunication, à destination du sol, soit spontanément, soit sur interrogation depuis le sol. Quel que soit le mode de fonctionnement choisi, il n'y a pas de coordination et les messages sont émis en aveugle sans savoir si le destinataire du message est disponible, la bonne réception étant constatée par la demande d'un accusé de réception ou par l'exécution de la tâche demandée. Comme une application non-ATC table sur la disponibilité de son correspondant, ce manque de coordination peut amener une application à multiplier les essais infructueux de transmission, au moins autant de fois que le nombre admis pour décréter la présence d'un problème dans la transmission, alors que toute tentative de transmission était vouée dès l'origine, à un échec du fait d'une absence du destinataire recherché, par exemple, par le fait que l'aéronef ou le centre au sol interrogé n'a jamais disposé ou ne dispose plus momentanément de l'application voulue. En effet, les degrés d'équipement des aéronefs sont très divers et les centres au sol interrogés peuvent être victimes d'indisponibilités passagères prévues ou non, de certaines de leurs applications.

Pour une meilleure efficacité du réseau aéronautique de télécommunication ATN, il importe de limiter le plus possible les demandes de connexion infructueuses. L'utilisateur y est encouragé par le mode de facturation qui est basé non seulement sur la quantité d'informations transmises mais également sur un forfait de prise en charge à chaque

demande de connexion. Il importe donc pour un utilisateur de limiter le plus possible les demandes de connexion infructueuses.

Dans ce but, on propose d'équiper un routeur de réseau aéronautique de télécommunication ATN, d'un mécanisme de validation des demandes de connexion opérant au moyen d'une base de données propre au routeur, répertoriant les applications non-ATC disponibles localement et les applications non-ATC disponibles à distance, au niveau des terminaux de raccordement d'un ou plusieurs correspondants privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant considéré a déjà tenté au préalable, d'entrer en relation avec eux au travers du réseau aéronautique de télécommunication, et de moyens de maintien à jour de cette base de données.

La figure 2 illustre, de manière schématique, un exemple d'architecture matérielle et logicielle pour un routeur embarqué de réseau aéronautique de télécommunication ATN permettant d'améliorer le taux des demandes de connexion qui aboutissent par l'utilisation d'un tel mécanisme de validation.

Ce routeur est constitué, comme à l'habitude, d'un calculateur spécialisé avec une unité centrale 20, une mémoire, et différentes interfaces d'entrée-sortie.

La mémoire comporte différentes parties dont, principalement, : - une partie 21 dite pile ATN avec des registres dont la manipulation par l'unité centrale 20 permet la mise en application des protocoles de transmission du réseau ATN aussi bien pour engendrer le flux de données émis du bord vers le sol à partir des informations à transmettre et des informations de service utilisées pour l'établissement, le maintien et la conclusion d'une liaison au sein du réseau ATN, que pour l'extraction des informations contenues dans le flux de données reçues du sol au cours d'une liaison et leurs redirections vers les équipements embarqués concernés, - une partie 22 utilisée pour le stockage de différents modules de programmes, et

- une partie 23 utilisée pour le stockage d'une base de données sur le réseau ATN.

Les interfaces d'entrée-sortie relient le routeur embarqué avec différents équipements de l'aéronef qui sont essentiellement : - les systèmes émetteurs-récepteurs 25, 26,27, 28 de l'aéronef pouvant jouer le rôle de têtes de sous-réseaux de communication air-sol pour le réseau ATN, - les équipements 29 de l'aéronef pouvant être amenés à utiliser le réseau ATN pour échanger des informations avec le sol, et - au moins une interface homme-machine IHM 30 telle que, par exemple, le MCDU ("Multipurpose Control Display Unit"), permettant un dialogue du routeur embarqué avec l'équipage de l'aéronef pour que celui-ci puisse donner ses consignes au routeur et en retirer diverses informations sur l'état des liaisons établies au travers du réseau ATN.

Parmi les modules de programmes stockés dans la partie 22 de la mémoire du routeur et exécutés en temps partagés par son unité centrale 20, on trouve classiquement : - un module logiciel de gestion 31 et de répartition de tâches gérant les activités des différents émetteurs-récepteurs embarqués 25,26, 27,28 pouvant servir de tête de sous- réseau de communication, - un module logiciel CMA 32 chargé de l'initialisation, du maintien et de la coupure d'une liaison, - un module logiciel IDRP 33 chargé plus spécifiquement du routage, - un module logiciel"Applis ATC"34 chargé de l'exécution de tâches relevant du contrôle aérien, et - des modules logiciels"Applis non-ATC"35 chargés de l'exécution de tâches relevant de la gestion du vol et de l'aéronef.

Ces différents modules logiciels ne seront pas détaillés car ils ne font pas partie de l'invention. Ils sont conçus par des spécialistes du génie logicielle en tenant compte à la fois des spécificités des équipements embarqués à bord de l'aéronef, des protocoles normalisés du réseau ATN et

des desiderata des autorités de contrôle du trafic aérien et de la compagnie exploitant l'aéronef.

A l'heure actuelle, une fois qu'un des modules logiciels"Applis non-ATC"35 a déterminé la nécessité d'une liaison avec le sol par l'intermédiaire du réseau ATN, il fait directement appel à la pile de communication ATN pour l'établissement de la liaison. Le message est alors relayé de proche en proche au sein du réseau jusqu'au terminal distant demandé. Le succès de la tentative de connexion dépend de la disponibilité sur le terminal distant de l'application avec laquelle un contact est recherché.

Si l'application est disponible, le message lui est délivré, si elle ne l'est pas, la tentative de connexion est un échec. Dans les deux cas, les ressources du réseau ATN sont mises à contribution, ce qui implique une utilisation systématique des capacités de transmission du réseau ATN et une facturation d'un forfait de connexion indépendamment de la réussite ou de l'échec ultérieur de la tentative de connexion.

Lorsqu'une tentative de connexion échoue, l'application qui en est à l'origine la renouvelle généralement un certain nombre de fois, avant de renoncer. Cela peut conduire, surtout lorsque qu'une application fait appel périodiquement au même correspondant par l'intermédiaire du réseau ATN, à une occupation indue des capacités du réseau ATN et à un surcoût non négligeable pour le propriétaire de l'application, lié à cette utilisation infructueuse du réseau ATN.

Pour limiter les demandes de connexion infructueuses par l'entremise du réseau ATN, on introduit une procédure de validation des appels exécutée à chaque tentative d'émission de message de la part d'un des modules Applis non-ATC pour éliminer les appels voués à un échec certain. Cette procédure de validation d'appel peut être conduite par un module logiciel de validation d'appel 36 ajouté aux autres modules logiciels du routeur.

Pour cette validation, le module logiciel de validation d'appel 36 s'appuie sur deux tables de disponibilité d'applications propres au routeur considéré et stockées dans sa base de données ATN 23, une table de disponibilité locale répertoriant les applications disponibles localement et une table de disponibilité distante répertoriant les applications disponibles au niveau des terminaux de raccordement au réseau ATN, d'un ou plusieurs

correspondants privilégiés retenus, soit parce qu'ils ont été présélectionnés, soit parce qu'il y a déjà eu une tentative récente de connexion avec eux au travers du réseau ATN.

La table de disponibilité locale qui répertorie les adresses des applications disponibles localement, ne sert pas directement au module logiciel de validation d'appel du routeur considéré mais permet aux routeurs des terminaux de raccordement au réseau ATN des correspondants distants d'alimenter leurs tables de disponibilité distante en informations concernant les applications effectivement accessibles au niveau du routeur considéré.

Les adresses qu'elle renferme sont avantageusement accompagnées d'une date de mise à jour renseignant sur la fraîcheur des informations.

La table de disponibilité distante répertorie des adresses d'applications considérées comme effectivement accessibles au niveau de terminaux distants de raccordement au réseau ATN avec, soit une date d'entrée dans la table, soit la date de mise à jour qui les accompagnait lors de leur extraction d'une table de disponibilité locale. Elle est consultée par le module logiciel de validation d'appel 36 à chaque demande de connexion de la part d'une application non-ATC .

Le module logiciel de validation d'appel 36 consulte la table de disponibilité distante pour rechercher dans cette dernière la présence effective de l'adresse d'application distante appelée. S'il trouve cette adresse dans la table de disponibilité distante et qu'elle est accompagnée d'une date de mise à jour ou de prise en compte suffisamment récente, il la valide et l'appel poursuit son cours. Dans le cas contraire, il l'écarte et bloque l'appel avant toute tentative de connexion avec le réseau ATN.

L'organigramme de la figure 3 illustre les principales étapes de ce processus de validation.

En 40, le module logiciel de validation d'appel 36 exécute une boucle d'attente en l'absence de demande de connexion de la part d'une appli non-ATC à bord. Dès qu'il a détecté une demande de connexion, le module logiciel de validation sort de sa boucle d'attente et teste en 41 la présence dans la table de disponibilité distante de l'adresse d'application distante contenue dans la demande de connexion. Si la recherche est vaine, le module invalide la demande de connexion. Si cette recherche est fructueuse, il passe à un deuxième test 42 sur la date de mise à jour

associée à cette adresse dans la table de disponibilité distante. Si la date de mise à jour est trop ancienne, le module invalide la demande de connexion.

Dans le cas contraire, il la valide. Dans tous les cas de rejet de demande de connexion, le module logiciel de validation d'appel 36 peut émettre une alarme d'adresse erronée.

La mise à jour des tables de disponibilité est également une tâche réalisée par le module logiciel de validation d'appel 36, dans le but de s'assurer de la validité des informations contenues dans ses tables de disponibilité locale et distante. Ce module de validation d'appel 36 comporte une application de mise à jour capable d'interroger les tables de disponibilité locales de terminaux distants et de répondre aux demandes de consultation de la table de disponibilité locale par des terminaux distants.

La mise à jour de la table de disponibilité locale est réalisée par réception des alarmes de non disponibilité ainsi que des avis de fin de non disponibilité des applications locales, et par leur report dans la table de disponibilité locale. L'application de mise à jour peut également, procéder, de sa propre initiative à des contrôles périodiques de disponibilité des applications locales et reporter leurs résultats dans la table de disponibilité locale.

En cas d'évolution de ces disponibilités, l'application de mise à jour des tables de disponibilité communique ces changements d'informations apparus dans la table de disponibilité locale qu'elle gère aux terminaux distants des correspondants répertoriés dans la table de disponibilité distante du routeur considéré.

D'autre part, la tâche de mise à jour de la table de disponibilité distante est réalisée par contrôle périodique des dates de validité des informations contenues dans la table de disponibilité distante. Dès que l'une d'entre elles arrive à une date de péremption fixée arbitrairement, l'application de mise à jour des tables de disponibilité entre en contact avec son application homologue dans les terminaux distants concernés pour obtenir de leur part, en retour, les informations contenues dans leurs tables de disponibilité locale.

Une fois en communication avec son homologue du terminal distant, l'application locale de mise à jour des tables de disponibilité peut envoyer deux sortes de requêtes à son homologue : * une requête générale contenant la recopie de sa table de disponibilité locale, si l'identifiant du terminal distant considéré n'apparaît pas dans la table de disponibilité distante ou * une requête particulière contenant la mise à jour des seuls changements récents de sa table de disponibilité locale.

Une application de mise à jour des tables de disponibilité qui reçoit l'une de ces requêtes par l'intermédiaire du réseau ATN introduit dans sa table de disponibilité distante, avec une date de mise à jour ou d'introduction, les renseignements contenus dans la notification du demandeur. En retour, elle y répond en fournissant les mêmes renseignements que ceux reçus du demandeur.

Ainsi, l'échange de ces requêtes entre ces deux entités leur permet de se synchroniser et de mettre à jour leurs tables de disponibilité distante respectives, en fonction des informations contenues dans les tables de disponibilité locales de leur homologue.

Un certain nombre de demandes de mise à jour restent insatisfaites par l'application locale de mise à jour des tables de disponibilité par le fait qu'aucune liaison n'a été établie avec succès au travers du réseau ATN, avec l'application homologue du terminal distant considéré. Ces demandes de mise à jour non satisfaites sont consignées dans un registre par l'application locale de mise à jour des tables de disponibilité. Une fois que plusieurs demandes spécifiques de connexion ont échoué, le terminal distant concerné est considéré comme hors service et tous les appels qui lui sont destinés sont rejetés pour une certaine période de temps.

Les adresses d'appel sont plus strictement contrôlées puisqu'elles sont systématiquement refusées lorsqu'elles ne figurent pas dans la table de disponibilité distante. Par contre le maintien à jour de la table de disponibilité distante pour la mise à jour des informations périmées nécessite davantage de demandes de connexion au travers du réseau ATN puisqu'il s'effectue indépendamment des liaisons établies.

On peut envisager différentes variantes sans sortir du cadre de l'invention.

Ainsi, la table de disponibilité locale peut être conservée entre deux mises en route du terminal de raccordement auquel elle appartient ou être réinitialisée à chaque mise en route de ce terminal de raccordement.

La table de disponibilité distante peut être réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réels et théoriques de leur tables locales de disponibilité.

La table de disponibilité distante peut être effacée à la mise en route du terminal considéré et mise à jour progressivement, en profitant des demandes de connexion provenant d'applications non-ATC locales ou distantes pour interroger les terminaux qui les accueillent sur les contenus de leurs tables locales de disponibilité.

La table de disponibilité distante peut être réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables locales de disponibilité.

Claims

REVENDICATIONS 1. Procédé de sélection des applications activables au travers d'un réseau aéronautique de télécommunication, caractérisé en ce qu'il consiste, à pourvoir le terminal de raccordement au réseau aéronautique de télécommunication d'un intervenant à des applications non-ATC, : . de deux tables de disponibilité d'applications, l'une locale répertoriant les applications disponibles localement, au niveau du terminal de raccordement de l'intervenant et l'autre distante répertoriant les applications disponibles au niveau des terminaux de raccordement d'un ou plusieurs correspondants privilégiés retenus soit parce qu'ils sont présélectionnés, soit parce que l'intervenant a déjà tenté au préalable, d'entrer en relation avec eux au travers du réseau aéronautique de télécommunication, * des moyens de consultation de la table de disponibilité locale activés par demande d'un terminal de raccordement distant, 'des moyens de consultation de la table de disponibilité distante qui sont activés, à chaque tentative faite par une application pour se connecter au travers du réseau aéronautique de télécommunication et qui, soit autorise la connexion si le correspondant distant demandé est répertorié dans la table de disponibilité distante pour l'application considérée, soit la refuse si le correspondant distant demandé ne figure pas dans la table de disponibilité distante pour l'application considérée, 'des moyens d'interrogation à distance des tables de disponibilité locale des correspondants joignables au travers du réseau aéronautique de télécommunication, * des moyens de mise à jour de la table de disponibilité locale de l'intervenant opérant par surveillance de la disponibilité des applications possédées par l'intervenant, et 'des moyens de mise à jour de la table de disponibilité distante opérant par recopie au moins partielle des tables de disponibilité locale des correspondants en activant les moyens d'interrogation à distance.

<Desc/Clms Page number 18>
2. Procédé selon la revendication 1, caractérisé en ce que la table de disponibilité locale est réinitialisée à la mise en route du terminal de raccordement considéré.
3. Procédé selon la revendication 1, caractérisé en ce que la mise à jour de la table de disponibilité locale se fait en fonction des alarmes de non disponibilité et des avis de fin de non-disponibilité engendrés par les applications locales non-ATC.
4. Procédé selon la revendication 1, caractérisé en ce que la mise à jour de la table de disponibilité locale se fait de manière systématique et périodique.
5. Procédé selon la revendication 1, caractérisé en ce que la table de disponibilité distante est réinialisée à la mise en route du terminal de raccordement considéré, avec un contenu obtenu par recopie à distance des contenus des tables de disponibilité locale de terminaux distants de raccordement au réseau aéronautique de télécommunication listés au préalable.
6. Procédé selon la revendication 1, caractérisé en ce que la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, avec un contenu par défaut qui reflète les disponibilités théoriques d'applications distantes non-ATC de terminaux distants listés au préalable et qui est mis à jour en interrogeant les terminaux distants pris en compte sur les différences entre les contenus réels et théoriques de leur tables locales de disponibilité.
7. Procédé selon la revendication 1, caractérisé en ce que les moyens de consultation de la table de disponibilité locale sont sensibles à au moins deux types de requêtes de la part d'un terminal distant, une requête générale sur le contenu global de leur table de disponibilité locale et une requête particulière sur les différences entre les contenus réel et théorique de leur table de disponibilité locale.

<Desc/Clms Page number 19>
8. Procédé selon la revendication 1, caractérisé en ce que la table de disponibilité distante est réinitialisée à la mise en route du terminal considéré, par recopie à distance des contenus des tables de disponibilité locale d'une liste préétablie de terminaux distants et mise à jour en interrogeant périodiquement les terminaux distants sur des contenus de leurs tables locales de disponibilité.
9. Procédé selon la revendication 1, caractérisé en ce qu'un terminal de raccordement au réseau aéronautique de télécommunication, en présence d'un changement d'état de disponibilité de l'une de ses applications non-ATC, avertit de ce changement d'état de disponibilité tous les terminaux distants référencés dans sa table de disponibilité distante pour mettre en concordance leurs tables de disponibilité distantes.
10. Procédé selon la revendication 1, caractérisé en ce que, lorsque le terminal de raccordement au réseau aéronautique de télécommunications renferme un automate à microprocesseur assurant la gestion des communications sous le contrôle de différents modules logiciels spécialisés appelés en fonction de la nature de la tâche à effectuer : module logiciel CMA pour l'initialisation, le maintien et l'achèvement d'une communication applicative, module logiciel SN-SME pour le maintien et l'achèvement d'une connexion au sein du réseau aéronautique de télécommunication, module logiciel IRDP pour le routage d'une communication, module logiciel Applis ATC pour l'exécution d'applications ATC préchargées et modules logiciels Applis non-ATC pour l'exécution d'applications non-ATC, les moyens de consultation de la table distante de disponibilité et de mises à jour des tables locale et distante de disponibilité sont constitués dudit automate à microprocesseur opérant sous le contrôle d'un module logiciel spécifique de validation des appels, qui gère les moyens de consultation et de mise à jour des tables locales et distantes de disponibilité, intercepte les demandes de connexion des applications locales non-ATC et vérifie la disponibilité de leur correspondant avant d'autoriser une poursuite de leur traitement.

<Desc/Clms Page number 20>
11. Procédé selon la revendication 1, caractérisé en ce que le module logiciel de validation des appels surveille la fraîcheur des informations contenues dans les tables locale et distante et procède à leurs mises à jour dès qu'elles atteignent une date de péremption fixée arbitrairement.