FR 2787269 A1 20000616 FR 9815690 A 19981211 PROCEDE DE MISE EN OEUVRE D'UNE UNITE DE SERVICE DE TRAFIC AIR DESCRIPTION Domaine technique La présente invention concerne un procédé de mise en oeuvre d'une unité de service de trafic air. Etat de la technique antérieure Dans les générations d'avions à venir, un nouvel équipement va voir le jour : l' unité de service de trafic air ou ATSU. Cette unité de service de trafic air, telle que décrite dans le document référencé [1] en fin de description, a pour objet de gérer les liaisons entre certains équipements avions (tels le système de gestion de vol (FMS), l'ordinateur de maintenance central (CMC), le système d'alarmes de vol (FWS)...) et les moyens de communication sol/bord (tels que la communication satellite (SatCom), la liaison données HF (HFDL), le système de présentation et d'adressage de communication système (ACARS)...). La particularité de l'unité de service de trafic air est d'être conçue comme un calculateur classique avec un système d'exploitation, sur lequel s'exécutent des applications. On retrouve ainsi l'architecture classique illustrée sur la figure 1. Le système d'exploitation 10 gère les entrées/sorties 11, l'utilisation des ressources logicielles 12 et matérielles 13, l' enchaînement et le cadencement des applications 14 : Al....An. Les ressources logicielles sont l'équivalent de sous-programmes utilisables par les applications et/ou le système d'exploitation (gestions des communications, bibliothèques,...). Les ressources matérielles comprennent mémoires, bus, registres, processeur, co-processeur... Les applications sont des programmes réalisant chacun une fonctionnalité du système avion, par exemple la communication de liaison données contrôleur/pilote (CPDLC) . La mission de 1'unité de service de trafic air est d'augmenter les capacités opérationnelles de l'avion en automatisant les échanges pilotes/ contrôleurs via l'utilisation de réseaux de communication de données. L'unité de service de trafic air supporte la base- des activités communication et surveillance incluses dans le concept général FANS-CNS/ATM au sein du système ATIMS. Les principales fonctions fournies par l'unité de service de trafic air sont : - la gestion du dialogue équipage/contrôleur (CPDLC/AFN) ; - la surveillance dépendante automatique (ADS) ; - les fonctions d'exploitation de l'avion (AOC), par exemple modification du plan de vol, rapports de maintenance,... ; - l'utilisation du réseau ACARS avant la mise en oeuvre du réseau ATN ; - le routage ACARS. Vis-à-vis des objectifs de sécurité, la classification des fonctions offertes par l'unité de service de trafic air ne nécessite pas d'architecture particulière. Comme illustré sur la figure 2, l'environnement de l'unité de trafic air est constitué de : - un système 20 d'accès au sous-réseau air/sol ACARS ; - des systèmes avioniques 21 tels que : . système de gestion de vol (FMS), . système électronique de vol/gestion d'avion centralisée électronique (EFIS/ ECAM), . ordinateur de maintenance central (CMC), . système d'avertissement en vol (FWS), # imprimante, . unité de commande de disque multi-usage (MDDU) , . horloge ; - des unités d'affichages (MCDU1, MCDU2, MCDU3, ... ) ; - une unité 22 de contrôle de liaison de données et d'affichage. La figure 3 illustre la structure logicielle de l'unité de service de trafic air avec des logiciels indépendants et avec leurs relations de chargement. La figure 4 illustre les fonctions de l'unité de service de trafic air avec leur positionnement pour les applications et pour la plate-forme logicielle. Le calculateur de l'unité de service de trafic air est composé de deux catégories de fonctions : - les fonctions basiques qui assurent le rôle fonctionnel de ce calculateur ; - les fonctions de gestion du système qui n'ont pas d'impact sur le rôle fonctionnel du calculateur. Elles sont chargées de remplir les services classiques de tout calculateur embarqué sur avion (maintenance, surveillance, etc...). Parmi les fonctions basiques on trouve les applications. La terminologie application fait référence à un protocole de communication de liaison de données air/sol et à son intégration à bord. Chaque application possède la compétence nécessaire pour le séquencement des traitements différents requis. Ces applications comprennent : * Les applications de service de trafic aérien ou ATC qui regroupent : - les services de gestion de trafic aérien (ATMS-). Ces applications supportent et initialisent les échanges d'informations bord/sol et sol/bord, les communications de liaison données contrôleur/pilote (CPDLC) et la notification de facilité de trafic aérien (AFN) étant incluses ; - l'application de surveillance (ADS) qui permet en particulier de donner en permanence la position de l'avion ; - les services d'information de vol. Les applications de communication opérationnelles compagnie ou AOC. Lorsque l'unité de service de trafic air est livrée, la compagnie client peut implémenter des applications qui lui appartiennent, qu'elle a développées elle-même ou fait développer par un tiers. Cette possibilité est très intéressante commercialement, ces applications permettant à ladite compagnie d'exploiter pour ses besoins propres certaines données présentes au niveau de l'avion, qui ne concernent pas le fonctionnement proprement dit de l'avion mais son exploitation en tant qu'outil commercial (durée de certaines parties d'un vol, consommation de carburant,..). Ces applications, appelées AOC, ne sont pas connues du fabricant de l'unité de service de trafic air. L'unité de service de trafic air doit pouvoir accueillir de telles applications AOC développées par des tiers à la demande des compagnies aériennes. Les contraintes associées à une telle exigence se traduisent par une structure d'accueil permettant de : - rendre ces différents développements (réalisation, mise au point et support) les plus autonomes possible ; - rendre la plate-forme matérielle transparente pour le logiciel ; - garantir une capacité de traitement à chaque processus (temps unité centrale) ; - garantir la non-perturbation d'une application ATC par une application AOC. Le fabricant de l'unité de service de trafic air doit certifier l'équipement auprès de divers organismes officiels, certifier signifiant : connaître, vérifier et garantir le fonctionnement de l'ensemble dans tous les modes possibles de fonctionnement, y compris des modes dégradés ou lors de défaut de certains de ses éléments. C'est une procédure connue et maîtrisée. La certification a deux fonctions : une fonction purement administrative qui équivaut à une autorisation d'emploi sur avion commercial et surtout une fonction de garantie de sécurité. La certification permet de garantir que le fonctionnement ou le dysfonctionnement d'un équipement n'aura pas de conséquences inacceptables. Le niveau de dysfonctionnement permis varie suivant le rôle fonctionnel de l'équipement dans l'avion : ainsi l'équipement qui gère les liseuses individuelles des passagers n'est pas soumis aux mêmes contraintes qu'un calculateur de commandes de vol. Le document [2] illustre le fait que le logiciel complet d'un équipement de bord est concerné par la certification. On a donc un équipement dont le fonctionnement est certifié (connu, vérifié et garanti) sur lequel on peut exécuter une application AOC inconnue. Manifestement, le nouvel ensemble n'est plus celui qui a été certifié. Pour le certifier il faudrait recommencer une procédure de certification pour l'ensemble fabriqué, enrichi de la (ou des) application(s) AOC. Une telle procédure serait beaucoup trop chère. De plus l'avantage commercial de proposer à une compagnie la possibilité d'implémenter ses propres applications disparaîtrait. Pour minimiser les procédures de certification pour chaque évolution, l'unité de service de trafic air met en oeuvre : - une conception logicielle modulaire ; - un concept de plate-forme centrale ; - des interfaces de haut niveau entre cette plate-forme centrale et les applications ; - une séparation des applications. Afin de concentrer les intégration/validation détaillées et la qualification uniquement sur l'application modifiée/ajoutée, le procédé réduit résulte d'une analyse d'impact de modification lorsqu'un nouveau logiciel (sauf les applications AOC) est ajouté. Une certification initiale de l'unité de service de trafic air couvre, bien sûr, tous les aspects, mais la certification d'une évolution de cette unité de service de trafic air ne doit pas se focaliser sur les nouvelles parties modifiées. L'invention a pour objet, dans le cas spécifique des applications AOC, de ne nécessiter aucune certification, le logiciel de telles applications étant situé au niveau E (niveau minimum de criticité de pannes vis-à-vis de l'avion), et donc de concilier les deux nécessités : certifier l'équipement dans son ensemble (c'est-à-dire applications AOC comprises) et permettre aux compagnies d'implémenter des applications qui leur sont propres. Exposé de l'invention La présente invention concerne un procédé de mise en oeuvre d'une unité de service de trafic air (ATSU) qui gère les liaisons entre certains équipements avion et les moyens de communication sol/bord, et dont le système d'exploitation (OS) gère les entrées/sorties, l'utilisation des ressources logicielles et matérielles, l'enchaînement et le cadencement des applications, qui sont des programmes réalisant des fonctionnalités du système avion, et dans lequel on utilise des mécanismes de découpage de la mémoire, et des mécanismes de découpage de l'unité centrale, ledit procédé étant caractérisé en ce que l'on filtre les appels au système d'exploitation issus d'applications de communication opérationnelle compagnie aérienne ou AOC de manière à interdire auxdites applications de perturber le fonctionnement de ladite unité de service de trafic air. Avantageusement le filtrage est réalisé par la méthode Hook. Ce filtrage ne laisse passer que les appels système autorisés. Dans un mode de réalisation avantageux, un logiciel de contrôle des appels système permet de : - configurer les filtres dont certaines caractéristiques peuvent être fixées par un processus super-utilisateur , de l'unité de service de trafic air ; - filtrer les appels système qui doivent l' être ; - enregistrer dans une zone spécifique les refus d'exécution d'appels système ; - fournir, à la demande du processus superutilisateur de l'unité de service de trafic air, les données stockées sur les rejets d'appels système. Brève description des dessins - La figure 1 illustre la structure de l'unité de service de trafic air ; - la figure 2 illustre l'environnement de l'unité de service de trafic air ; - la figure 3 illustre la structure logicielle de l'unité de service de trafic air ; - la figure 4 illustre les fonctions de l'unité de service de trafic air ; - la figure 5 illustre le procédé de l'invention. Exposé détaillé de modes de réalisation L'invention concerne un procédé de mise en oeuvre de l'unité de service de trafic air (ATSU) qui gère les liaisons entre certains équipements avion et les moyens de communication sol/bord, et dont le système d'exploitation (OS) gère les entrées/sorties, l'utilisation des ressources logicielles et matérielles, l'enchaînement et le cadencement des applications, qui sont des programmes réalisant des fonctionnalités du système avion. L'architecture logicielle de l'unité de service de trafic air est basée sur l' utilisation d'un système d'exploitation temps réel qui gère les traitements. Un sous-ensemble logiciel est appliqué sur chaque traitement. Chaque traitement est protégé des autres traitements par différents mécanismes de protection tels que : * Un découpage de la mémoire Le système d'exploitation utilise une unité de gesti-on de mémoire (MMU) du microprocesseur de telle manière que deux étapes sont nécessaires pour traduire l'adresse logique du code courant en adresse physique : - adresse logique -> adresse linéaire au travers d'un mécanisme de segmentation de l'unité de gestion de mémoire ; - adresse linéaire -> adresse physique au travers d'un mécanisme de pagination de l'unité de gestion de mémoire. Durant chacune de ces étapes l'unité de gestion de mémoire réalise une vérification de protection et interdit un accès illégal. Le système d'exploitation fournit deux types de découpage : - le code utilisateur (non privilégié) ne peut accéder directement le code système d'exploitation ou espace de données. Seul un accès indirect au travers des appels au système d'exploitation est possible ; - le code procédé ne peut accéder un autre code procédé ou espace de données. # Un découpage de l'utilisation de l'unité centrale de traitement. Chaque procédé peut être composé de quatre tâches au maximum. Chaque tâche a une priorité inférieure ou égale à la priorité du procédé dont elle est issue. Le système d'exploitation fournit un relevé de priorité préemptif combiné avec une gestion circulaire par niveau de priorité. Ainsi une tâche de bas niveau ne peut empêcher une tâche de niveau supérieur d'utiliser l'unité centrale et une tâche ne peut monopoliser l'unité centrale indéfiniment au détriment d'une tâche ayant la même priorité. L'invention consiste à filtrer les appels au système d'exploitation issus d'applications de type AOC de manière à interdire auxdites applications de perturber le fonctionnement de l'unité de service de trafic air. Pour comprendre ce mécanisme de filtrage, on va revenir rapidement sur le fonctionnement du système d'exploitation. Lorsqu'une application a besoin d'une ressource logicielle ou matérielle, de communiquer avec une autre application ou même de modifier des paramètres du système d'exploitation, elle doit transiter par le système d'exploitation. De par la conception même du calculateur, de type UNIX par exemple, l'application ne peut pas effectuer ces accès directement : elle effectue des demandes d'accès au système d'exploitation par le biais d'une interruption logicielle paramétrée. Les paramètres définissent le type d'accès souhaité, c'est- à-dire la fonctionnalité appelée. Le fabricant du système d'exploitation a prévu une possibilité appelée méthode HOOK permettant lors d'un appel système de lancer une procédure juste avant le traitement de l'appel par le système d'exploitation. Le document [3] donne deux exemples de tests réalisés sur le logiciel ATSU et qui montrent l'effet du filtrage par la procédure HOOK. Le filtrage des appels est effectué via une procédure dont le principe conduit à créer : - un mécanisme de procédure HOOK dans le traitement du répartiteur des appels systèmes du système d'exploitation ; - un logiciel driver (code développé par le fabricant pour filtrer les appels au système ; le tableau I donné en fin de description à titre d'exemple liste les 266 appels système ainsi que le type de filtrage associé ; le fabricant proposant, en effet, en standard un noyau configurable par l'utilisateur à l'aide de stubs , mécanismes qui simulent des appels réels en n'effectuant aucun traitement). Ce logiciel activé par la procédure HOOK, réalise effectivement le filtrage. Dans la procédure HOOK du répartiteur des appels système, tout appel système active ce répartiteur qui assure le passage dans le contexte du système d'exploitation et réalise l'appel système requis. Ce répartiteur est le point d'entrée dans le système d'exploitation ; c'est donc là que la procédure HOOK d'appel du filtre est disposée. La procédure HOOK est implémentée juste avant la répartition et consiste à permettre l'activation d'un traitement (assimilable à une partie d'un driver ) de contrôle du caractère réalisable de l'appel système. Ce logiciel de contrôle des appels système permet de : - configurer les filtres dont certaines caractéristiques peuvent être fixées par un processus, dit super-utilisateur , de l'unité de service de trafic air ; - filtrer les appels système qui doivent l'être (lettre H dans le tableau I) ; - enregistrer dans une zone spécifique les refus d'exécution d'appels système ; - fournir, à la demande du processus superutilisateur de l'unité de service de trafic air, les données stockées sur les rejets d'appels système. Sachant qu'on ne sait rien du fonctionnement des-applications AOC et qu'on ne peut pas les contrôler, l'invention a pour objet un procédé permettant d'empêcher ces applications de perturber le reste du système. On filtre donc tous les échanges applications AOC système d'exploitation. Comme illustré sur la figure 5, le procédé de l'invention comprend une procédure filtrant, via la méthode HOOK, les appels du système d'exploitation issus des applications AOC et n'autorisant que celles qui n'ont aucune influence sur ce qui est certifié. Chaque appel système possible est analysé et le risque que son utilisation incontrôlée peut faire courir au système global est déterminé individuellement. Chaque appel système se trouve classé dans une des trois catégories : refusé, accepté sous conditions ou accepté. Lors d'un appel système interdit, la procédure HOOK renvoie un message type, ne rien faire ou même mettre fin au processus appelant. Le système d'exploitation possède ainsi un nouveau mécanisme qui permet de mettre en place, au niveau utilisateur, une politique de contrôle des appels système, appel par appel. REFERENCES [1] AIM-FABS The Airbus Interoperable Modular Future Air Navigation System (Salon du Bourget, mai 1997, Aerospatiale) [2] Software Considérations In Airborne Systems And Equipment Certification (DO-178B/ED-12B, RTCA Inc., décembre 1992, pages 28,60, 69 et 71) [3] Essai SAR OSY001 : Agression sur l'operating system (LA-2TO-PTV-SA-01C, Aerospatiale, pages 147-153,1998) TABLEAU I @ N Appel Filtre requis Type Détails Appel ou contrôle de privilège Type d'implémentation 0 aucun interdit H faux 1 reboot 2 fork l'utilisateur appelant doit être Ha uid = =0 root (administrateur) 3 (aucun)b interdit H faux 4 sbrk 5 Isbrk 6 sethostname l'utilisateur appelant doit être root H uid = =0 7 gesthostname l'utilisateur appelant doit être root H uid = =0 8 kill 9 exit 10 getitimer 11 setitimer 12 wait3 13 wait 14 setpriority l'utilisateur appelant doit être root H (uid==0) ou la priorité demandée inférieure (newprio ≤priolim) à la priorité maximale définie pour le processus 15 getpriority 16 getpid 17 getppid 18 sigvec 19 sigblock 20 sigsetlllask 21 sigpause 22 killpg 23read 24iocti 25Iseek 26 write 27 close 28 open 29getrusage 30 (aucun) interdit H faux 31 sync 32 mkdir 33 mknod l'utilisateur appelant doit être root H uid==0 34execve 35 dup2 36 dup 37 pipe N Appel Filtre requis Type Détails ppe ou contrôle de privilège ype d'implémentation 38 stat 39Istat 40fstat 41chdir 42 chmod 43 fchmod 44 link 45 unlink 46 chroot 47 fcntl 48 getdtablesize 49 fsync 50 getpgrp 51 setpgrp 52 readlink 53 access 54 getuid 55 gettimeofday 56 umask 57 settimeofday 58 nndir 59 renanie 60 symlink 61 mount 62 unmount 63 sem~get interdit H faux 64 sem count interdit H faux 65 sem wait interdit H faux 66 sem signal interdit H faux 67 sem nsignal interdit H faux 68 sem reset interdit H faux 69 sem delete interdit H faux 70 smem create Seul l'utilisateur root a le droit de H (uid = =0) créer des mémoires partagées (name in table && mappées sur un espace physique. (uid = =owneruid&& Les autres utilisateurs n'ont accès uniode! =0 (owner(yid qu'à des mémoires dont le nom in group (process) && logique et le mode d'accès sont gmode! =0) Il spécifiés dans une table. Le mode (omode!=0)) d'accès dépend de l'utilisateur, et du ou des groupes auxquels il appartient N Appel Filtre requis Type Détails Appel ou contrôle de privilège Type d'implémentation 71 sem~get Seul l'utilisateur root a le droit de H (uid= =0) Il créer des mémoires partagées. Les (name in table && autres utilisateurs n'ont accès qu'à (uid= =owneruid&& des mémoires dont le nom logique umode!=0 Il (ownergid et le mode d'accès sont spécifiés in group (process) dans une table. Le mode d'accès gmode! =0) # dépend de l'utilisateur, et du ou (omode! =0)) des groupes auxquels il appartient. 72 siiieni-remove l'utilisateur appelant doit être root H uid==0 73 info 74 flock interdit H faux 75 chcdev 76 dr install 77 dr uninstall 78 cdv install 79 cdv uninstall 80 select 81 getpagesize 82 getrlimit 83 setrlimitd 84 bdv install 85 bdv-wiinstall 86setreuid 87 brk 88 chown 89 fchown 90 utimes 91 lockf interdit Se stub lockf 92geteuid 93 getgid 94 getegid 95setregig 96 getgroups 97 setgroups 98 truncate 99 ftruncate 100 mkcontig interdit H faux 101 msgctl destruction interdite si utilisateur H (uid==0) non root (cmd! = IPC - RMID) 102 msgget création interdite si utilisateur non H (uid==0) \1 root ((flag&IPC-CREAT) ~ =0) 103msgrcv 104 msgsnd 105readv N Appel Filtre requis Détails Appel ou contrôle de privilège Type d'implémentation 106 writev ~~~~~~~~~~ 107 socket l'utilisateur appelant doit être root S uid= =0 108 connect l'utilisateur appelant doit être root S uid= =0 109 bind l'utilisateur appelant doit être root S uid==0 110 listen l'utilisateur appelant doit être root S uid==0 111 accept l'utilisateur appelant doit être root S uid==0 112 shutdown l'utilisateur appelant doit être root S uid==0 113 s si86 interdit H faux 114 plock 115 semget création interdite si utilisateur non H (uid==0) root ((tlag&IPÇ CREAT)= ~~ ~ =0) ~~~~~~~~ 116 sentctl destruction interdite si utilisateur H (uid==0) non root (cnid ! = IPC~RMID) 117 semo ~~~~~~~~~~~~ 118 slunctl destruction interdite si utilisateur H (uid==0) autre que root (cmd!=IPC RMID) 119 sliniget création interdite si l'utilisateur H (uid==0) autre que root ((flag&IPC~CREAT)= =0) 120 shmat 121 shiiidt ~~~~~~~~ 122 sigpendin ~ 123 wait id ~~~~~~~~~~~~~~~~~~ ~~~ ~~~~~~~~~~ 124 trace l'utilisateur appelant doit être root h uid==0 125 send l'utilisateur appelant doit être root S uid==0 126 sendto l'utilisateur appelant doit être root S uid==~0 ~ 127 sendmsg l'utilisateur appelant doit être root S uid==0 ~~~~~ 128 recv l'utilisateur appelant doit être root S uid==0 129 recvfrom l'utilisateur appelant doit être root S uid = =0 ~~~~~~ 130 recvmsg l'utilisateur appelant doit être root S uid==0 131 setsockopt l'utilisateur appelant doit être root S uid= =0 132 getsockopt l'utilisateur appelant doit être root S uid = =0 133 getsockname l'utilisateur appelant doit être root S uid==0 134 getpeemaiiie ~ l'utilisateur appelant doit être root S ~uid==0 ~~~~~~ z nfsmount l'utilisateur appelant doit être root S uid==0 ~~~~~~~ 136 vmstart interdit H faux 137 newconsole ~~~~~ 138 st~build on ne peut créer un nouveau H threadcnt thread (bout de programme qui & totalstack≤ s'exécute de manière autonome) pstacklim&& que si le nombre de threads (uid==0# courants du processus est inférieur newpno ≤priolim) à une limite et que la somme des piles de threads existants augmentée de celle du thread à créer est inférieure à une limite et ~~~~~~~~~~~~~ N Appel Filtre requis Type Détails pp ou contrôle de privilège JV d'implémentation que la priorité est inférieure à la priorité maximale donnée pour le processus. Ces limites ne peuvent être spécifiées que par le processus root. 139 st~resume 140 st~stop 141 stjoin 142 st~detach 143 st-exit 144 ~getstid 145 st-setcancel 146 st testcancel 147 st -cancel 148 mutex~enter 149 mutex~exit 150 cv~wait 151 cv~signal 152 cv-broadcas( 153 csem~wait 154 csem signa)~~~~~~~~~~~~~~~~~~~~~~~~ ~ ~~~~~~~~~ 155 sigwait 156 st-seciandle 157 syncli-validate Un processus ne peut posséder H usvnc)icnt≤ plus d'un nombre maximum objets ~~~~~~~~~~~~de synchronisation entre threads. ~~~~~~ 158 synch invalidate 159 setkliaiidle- 160 st~switch 161 st-setabstinier 162 fast-setprio interdit S stub alsys 163 st~prioresume interdit S stub alsys 164 st~stopself interdit S stub alsys 165 syslog interditf 166 vatopa idem 165 ~~~ ~~~~~~~~~~~ 167 statfs ~ ~ 168 fstatfs ~ ~~~~~~~'~ ' ~~~~~~ 169 profil interdit faux 170 vmtopm interdit H faux 171 mkshm interdit S stub pshm 172 sliiiiniap interdit S stub Slifil 173 sluuunma interdit S stub psliiii N Appel Filtre requis Type Détails App ou contrôle de privilège yp d'implémentation 174 mkm interdit S stub msg Illeiitatioii 175 mqsend interdit S stub pmsg 176 mqreceive interdit S stub pmsg 177 mqsetattr interdit S stub pmsg 178 mqgetattr interdit S stub pmsg 179 mqpurge interdit S stub pmsg 180 msgalloc interdit S stub pmsg 181 msgfree interdit S stub pmsg 182 mqputevt interdit S stub pmsg 183 mqgetevt interdit S stub pmsg 184yield 185 setscheduler La politique d'ordonancement et la H (uid==0) # priorité ne peuvent être changée, ((newalg==cur alg)& pour la première, ou augmentée, & (newprio≤priolim)) pour la deuxième, que par l'utilisation root. 186 getscheduler 187 setquantum 188 getquantum 189 mksem interdit S stub binsem 190 semifpost interdit S stub binsem 191 sempost interdit S stub binsem 192 semifwait interdit S stub binsem 193 semwait interdit S stub binsem 194 sigaction 195 sigsuspend 196- sigprocmask 197 ekill interdit H faux 198 memlk interdit S stub memlk 199 memunlk interdit S stub memlk 200 arequest interdit S stub arequest 201 listio interdit S stubarequest 202 (aucun)8 interdit H faux 203 await interdit S stub arequest 204 acancel interdit S stub arequest 205 make event timer interdit S stub evtimer 206 remove event timer interdit S stub evtimer 207 esigpoll interdit H faux 208 times 209 uname 210 getmsg interdit H faux 211 putmsg interdit H faux 212 poli interdit ~ ~ H faux 213 mqmserver interdith H faux 214setsid 215 setpgid N Appel Filtre requis Type Détails N Appel ou contrôle de privilège Type d'implémentation 216 (aucun)' interdit H faux 217 fast~stop interdit H faux 218 fast~stop~th interdit H faux 219 fast~stop~ti interdit H faux 220 fast~resume interdit H faux 221 fast~stop~pi interdit H faux 222 fast~stop~pi~ti interdit H faux 223 fast~switch interdit H faux 224 fast cancel timeout interdit H faux 225 fast-enable~precinp[ioil interdit H faux 226 fast~info~attack interdit H faux 227 fast~sem~get interdit H faux 228 fast~sem~wait interdit H faux 229 fast~sem~signal interdit H faux 230 fast-seiii-delete interdit H faux 231 fast~sem~twait interdit H faux 232 fast~csem~set interdit H faux 233 fast~csem~wait interdit H faux 234 fast-csem-sigiial interdit H faux 235 sigqueue 236 seek~n~read interdit H faux 237 seek~n~write interdit H faux 238 st~name interdit H faux 239 fast~sem~open interdit H faux 240 fast seni close interdit H faux 241 fast-seiii-uiiliiik interdit H faux 242 7ast~sem~markdelete interdit H faux 243 fast sem mmarkdelete interdit H faux 244 shm~open interdit H faux 245 shm~unlink interdit H faux 246 mmap interdit ~ H faux 247 niunniap interdit H faux- 248 mprotect interdit H faux 249 msync interdit H faux 250 clock-gettiiiie 251 clock~settime 252 clock~getres 253 timer~create interdit H faux 254 timer~delete interdit H faux N A el Filtre requis Type Détails ppe ou contrôle de privilège ype d'implémentation 255 timer~getoverrun interdit H faux 256 timer~gettime interdit H faux 257 timer settime interdit H faux 258 fdata~sync 259 (aucune interdit H faux 260 nanosleep 261 socket~pair l'utilisateur appelant doit être root S uid==0 262 nsbrk 263 sigtimedwait ~~~~~~~~~~~~~~~~~~ ~ 264 signotify ~~~~ interdit ~~ ~ ~ H faux 265 name~server interdit H faux 266 adjtime LEXIQUE ACARS Aircraft Communication Addressing and Reporting System ou système de présentation et d'adressage de communication système ADS Automatic dependent Surveillance ou surveillance dépendante automatique AFN ATC (Air Traffic Control) Facility Notification ou notification de facilité de trafic aérien AOC Airline Operational Communication ou communication opérationnelle compagnie aérienne ARINC Aeronautical Radio Incorporated ou norme radio aéronautique ATIMS Air traffic and Information Management System ou système de gestion d'information et de trafic aérien ATM Air traffic Management ou gestion de trafic aérien ATSU Air Traffic Service Unit ou unité de service de trafic air BITE Built in Test Equipment ou équipement de test intégré CMC Central Maintenance Computer ou ordinateur de maintenance central CNS Communication Navigation and Surveillance ou surveillance et navigation de communication CPDLC Controler/Pilot Data Link Communication ou communication de liaison données contrôleur/pilote CPU Central Process Unit ou unité centrale de traitement ECAM Electronic Centralized Aircraft Monitoring ou contrôle avion centralisé électronique EFIS Electronic Flight Instrument System ou système instrument de vol électronique FANS Future Air Navigation System ou système de navigation aérien futur FMS Flight Management System ou système de gestion de vol FWS Flight Warning System ou système d'avertissement de vol HFDL HF Data Link ou liaison de données HF HMI Human Machine Interface ou interface homme-machine MCDU Multipurpose Control and Display Unit ou unité d'affichage et de contrôle multi-usage MDDU Multipurpose Disk Drive Unit ou unité de commande de disque multi-usage OS Operating Systemou système d'exploitation SatCom Satellite Communication ou communication satellite VDR VHF Data Radio ou radio de données VHF REVENDICATION 1. Procédé de mise en oeuvre de l'unité de service de trafic air qui gère les liaisons entre certains équipements avion et les moyens de communication sol/bord, et dont le système d'exploitation gère les entrées/sorties, l'utilisation des ressources logicielles et matérielles, l'enchaînement et le cadencement des applications, dans lequel on utilise des mécanismes de découpage de la mémoire, et des mécanismes de découpage de l'unité centrale, caractérisé en ce que l'on filtre les appels au système d'exploitation issus d'applications de type AOC de manière à interdire auxdites applications de perturber le fonctionnement de ladite unité de service de trafic air. 2. Procédé selon la revendication 1, dans lequel le filtrage est réalisé par la méthode HOOK. 3. Procédé selon la revendication 2, dans lequel le filtrage ne laisse passer que les appels système autorisés. 4. Procédé selon la revendication 1, dans lequel un logiciel de contrôle des appels système permet de : - configurer les filtres dont certaines caractéristiques peuvent être fixées par un processus super-utilisateur , de l'unité de service de trafic air ; - filtrer les appels système qui doivent l'être ; - enregistrer dans une zone spécifique les refus d'exécution d'appels système ; - fournir, à la demande du processus superutilisateur de l'unité de service de trafic air, les données stockées sur les rejets d'appels système.