FR2950449A1

FR2950449A1 - Simulation en temps reel hautement representative d'un systeme avionique

Info

Publication number: FR2950449A1
Application number: FR0904545A
Authority: FR
Inventors: Nicolas Damiani; Roland Touati; Nicolas Brisset
Original assignee: Eurocopter France SA; Eurocopter SA
Current assignee: Airbus Helicopters SAS
Priority date: 2009-09-23
Filing date: 2009-09-23
Publication date: 2011-03-25
Also published as: US8812284B2; US20110071709A1

Abstract

L'invention concerne la simulation en temps réel hautement représentative, au moins partielle et éventuellement mixte, d'un système avionique (2). Cette simulation prévoit au moins : une étape de translation sous forme de modèle encodé en langage de haut niveau à partir de fichiers formels en langage de marquage, desdites interfaces de communication ; et une autre étape de gestion dynamique des descriptions qui prévoit de regrouper, de mettre à jour et de partager une base de données incorporant pour chaque équipement, l'ensemble des signaux qui transitent par les interfaces d'entrée et / ou sortie. L'invention s'applique notamment à un aéronef (1).

Description

Simulation en temps réel hautement représentative d'un système avionique. Le domaine général de l'invention est l'aéronautique, c'est-à-dire des aéronefs.

Les aéronefs concernés par l'invention sont par exemple des aéronefs à voilure tournante ou des avions. Dans les exemples, ceux-ci sont notamment des hélicoptères conventionnels ou hybrides et / ou des drones de tels aéronefs. Le domaine précis de l'invention est celui des systèmes avioniques d'aéronefs, et plus particulièrement leur simulation. Ces systèmes sont aussi appelés « embarques », même si de nos jours certains de leurs constituants peuvent être situés hors bord. L'invention ne vise pas à produire des simulations de constituants dits « mécaniques » d'un aéronef classique. Mais ces constituants mécaniques peuvent comporter des composants électriques, hydrauliques ou intervenir dans la mécanique de vol. De fait, des informations représentatives et / ou produites par ces constituants sont nécessaires à certaines simulations de systèmes avioniques conformes à l'invention.

A titre d'exemple, les systèmes avioniques concernés par l'invention sont des pilotes automatiques (A/P) et / ou des affichages multifonctions (MFD) et / ou des sous systèmes de gestion du véhicule (VMS). Avec l'invention, on désire obtenir en temps réel des 25 simulations hautement représentatives de ces systèmes avioniques.

Par exemple ces simulations hautement représentatives sont utilisés pour la simulation de systèmes avioniques, pour leur conception et / ou leur spécification et / ou leur modification. Ces simulations sont également utilisables à des fins d'entraînement de pilotage ou d'entretien. Il convient pour ces utilisations notamment, que l'invention assure des niveaux élevés de sécurité, de traçabilité et de maintenabilité. Donc, le niveau de représentativité du système avionique 10 simulé doit être en adéquation avec les niveaux imposés pour sa spécification, voire en vue de certifications de ce système. L'une des difficultés rencontrées avec les simulations de systèmes avioniques est l'éclectisme de leurs constituants (par exemple des équipements), ainsi que celui des formats de données 15 à prendre en compte pour la simulation. Ainsi, la simulation doit représenter fidèlement des fonctions électriques et / ou électroniques et / ou hydrauliques et / ou mécaniques qu'assurent ces constituants variés. Quant au format de données relatives à ces constituants, il 20 peut être de type analogique et / ou discret et / ou binaire et / ou présentées en données structurées. Donc en amont de la simulation, on dispose de divers types de « données au format d'ingénierie » ou « EngineeringData ». Par contre, seule une abstraction numérique de ces données 25 au format d'ingénierie est utilisable pour la simulation. Une telle abstraction numérique doit avoir un format unitaire quel que soit son origine, son unité, ses valeurs et sa fonction. Ce format unitaire d'écriture est baptisé « données au format avionique» ou « RawData ». En synthèse, les données au format d'ingénierie sont ce que « disent » les modèles de pure simulation, ou ce que manipulent en 5 interne les modèles représentatifs d'équipements. Par contre, ces modèles de simulation parlent en données au format avionique. Les données au format avionique sont donc représentatives du système embarqué dans l'aéronef de destination. 10 Pour être homogènes entre elles et compatibles au sein de la situation, les données au format avionique sont conformes au protocole d'échange embarqué, tout en étant représentatives des données réelles. Ceci doit permettre par encodage / décodage de traduire / retrouver les données au format d'ingénierie supposées. 15 Par illustrer la complexité de ces encodages / décodages, divers types de données au format d'ingénierie sont mentionnées. Ainsi, pour une mesure de température c'est-à-dire une information d'ordre physique à intégrer à une simulation génère des données au format d'ingénierie sous forme de signal 20 analogique en Volt. Ces données au format d'ingénierie représentent une température dans une unité de mesure propre à l'instrument qui l'évalue, par exemple en degrés Fahrenheit. Cependant, il peut être nécessaire dans la simulation que les données au format 25 avionique doivent indiquer les valeurs de température en degrés Celsius. Ceci implique une conversion supplémentaire. D'autres données au format d'ingénierie, comme une commande d'alimentation électrique, sont sous forme de signal discret (e.g: marche / tension nominale / mise à la masse), auquel sont couplées des valeurs d'état (0/1). Par ailleurs, selon des protocoles avioniques courants, des données au format d'ingénierie sont sous forme des mots de « n » bits (souvent 32 bits) contenant plusieurs champs, ou sous forme d'un état « nul » (NULL). Ces mots qui servent à décrire des fonctions, leur support physique et les interfaces électrique, sont typiquement véhiculés sur un bus de données standardisé. Egalement, nombre de systèmes avioniques modernes comportent des constituants avec un ou plusieurs calculateurs portant des logiciels. Divers sous-ensembles (e.g : des partitions) sont reliés entre eux par des câblages, des bus de communication et des connecteurs. Les données propres à ces constituants à calculateur(s) sont 15 sous diverses formes de données structurées, définies par leur protocole d'appartenance. On comprend donc que cette hétérogénéité des données (notamment au format d'ingénierie) à transformer en données au format avionique - et inversement à restituer - pose à ce jour de 20 nombreux problèmes techniques. Par ailleurs, pour un système avionique donné, il est courant qu'un calculateur de constituant fonctionne avec un système d'exploitation (en anglais « operating system » ou « OS ») spécifique. On parle « d'OS avionique ». 25 II n'est pas rare que plusieurs OS avioniques, chacun dédié à calculateur spécifique par exemple, coexistent dans un même système avionique.

Ces OS avioniques sont en pratique différents des systèmes d'exploitation (Unix®, Linux®, Windows®) usuellement employés dans les stations de travail qui servent à la programmation et / ou le test et / ou la simulation de systèmes avioniques.

L'abstraction permettant d'obtenir les données (notamment au format avionique) pour la simulation du système avionique, doit évidemment être indépendante d'un tel système d'exploitation. Un autre inconvénient est qu'à l'heure actuelle, les stations de travail utilisées pour les simulations doivent avoir des capacités de traitement et un nombre de processeurs supérieurs à ceux du système avionique à simuler. Encore un inconvénient constaté lors des simulations, est la difficulté d'intégrer les évolutions du système avionique et / ou de ses constituants.

Tandis qu'il serait utile que l'ensemble des acteurs intervenant dans la simulation ou en ayant besoin, puisse à la fois échanger entre eux, voire agir sur des informations utiles à cette simulation, de manière simple, fluide et efficace. Pour les simulations, il est courant que les constituants mécaniques, soient reproduits d'un point de vue géométrique à l'aide d'une maquette. En anglais une telle maquette est appelée par l'expression « mock-up ». Par exemple, on parle de « mockup » pour la simulation physique de l'agencement des commandes d'un poste de pilotage d'aéronef.

Dans le langage avionique courant, « mock-up » désigne un prototype à l'échelle réelle, utilisable dans des conditions relativement représentatives de celles des constituants mécaniques réels de l'aéronef. 2950449 -6- L'une des utilisations de l'invention est également désignée par le terme maquette (« mock-up » en anglais) d'un système avionique. Une telle maquette est une mise en oeuvre sur une plateforme 5 de simulation en temps réel. Elle exécute un procédé selon l'invention. Dans la présente demande, l'invention est d'ailleurs mise en oeuvre sous forme de procédé, de plateforme, de système et d'aéronef. 10 Chacune de ces mises en oeuvre ou formes, présente ses spécificités propres et homogènes. En pratique cependant, le procédé et la plateforme, de même que le système avionique et l'aéronef présentent des points communs. Ceci étant, mentionnons quelques spécificités de l'invention. 15 Tout d'abord, notons que celle-ci est à la jonction entre un banc d'essai de constituants réels (appelé « test bed », « bench rig » ou « test bench » en langue anglaise) et un simulateur d'étude avec exclusivement des modèles numériques. En effet, l'invention permet des fonctionnalités comparables à 20 celles d'un simulateur et d'un banc d'essai, tout en permettant des simulations reconfigurables par ajustement des équipements réels et / ou de modèles purement numériques qui doivent être simulés. De fait, l'invention permet de mélanger des modèles numériques et des sources réelles. On dit alors que la simulation 25 selon l'invention est « mixte ». Pour ceci, la plateforme ne nécessite qu'un seul ordinateur, un seul bus et une même mémoire partagée et des ressources « machine » c'est-à-dire de traitement.

Sur une maquette selon l'invention, les échanges électriques relatifs aux signaux analogiques et / ou discrets sont simulés. Pour les modèles numériques, leur niveau de représentativité est tel qu'ils peuvent être mixés via une carte d'interface aux équipements réels. Plusieurs équipements et / ou constituants (dont partitions) peuvent être simulés. Ceci est différent de ce qu'offrent les simulateurs connus qui ne permettent pas de modéliser de manière sûre et traçable les bus de communication de l'architecture d'un système avionique.

Un exemple simulation selon l'invention est développé pour un système d'exploitation Linux® installé sur un ordinateur personnel (PC) du commerce, par exemple un ordinateur portable. On comprend qu'un tel ordinateur se distingue d'une station de travail dédiée et n'est nécessairement pas pourvu de capacités de traitement et d'un nombre de processeurs supérieurs à celui du système avionique à simuler. A titre d'exemple, un tel ordinateur prévu pour une simulation conforme à l'invention de 30 à 250 constituants (qu'il s'agisse d'équipements et / ou de partitions ou analogues), peut disposer de moins de 10 unités de traitement (ou « CPU », par exemple de type Intel® Double Dual Core en 32 bits) et fonctionner à une fréquence d'horloge de 2 à 3 GHz tout en fournissant des résultats tout à fait satisfaisants. Dans des réalisations exigeantes en ressources, spécialement concernant celles de l'horloge qui cadence la simulation, il est possible d'utiliser des plateformes garantissant un temps réel durci. 2950449 -8- Il s'agit par exemple d'une plateforme iHawk et de son environnement logiciel RedHAWK de Concurrent computer Corporation (voir site Internet : http://www.ccur.com ). Parmi les utilisations possibles de l'invention, on cite 5 notamment la conception, le développement, la vérification, la validation et les recherches de causes de dysfonctionnement, des spécifications, des logiciels embarqués et des équipements réels de systèmes avioniques, ainsi que de leurs interfaces et architectures de communication.

10 Le contexte et les définitions générales de l'invention étant exposées, citons certains documents relatifs à la simulation en temps réel. Le document EP 0 807 882 décrit un interpréteur logiciel pour ordinateur avionique à cartes multiples. Plusieurs jeux 15 d'instructions de programmes sont implémentés sur une station de travail ayant des capacités de traitement et un nombre de processeurs supérieurs à celui de l'avionique. Avec un système d'exploitation tel que UNIX, des tâches en temps réel sont exécutées, tandis que des mémoires caches et des procédures 20 sont partagées. Un jeu d'instructions et de données représentatif de l'avionique est chargé directement sur un système de simulation des mémoires cibles. Un exemple d'avionique concernée est la plateforme embarquée multi fonctions LAMPS MKIII pour hélicoptère anti sous-marins.

25 Le document EP 1 944 663 décrit une simulation de commande pour une turbine à retour dynamique ou pour de l'électronique grand public. Ces simulations sont employées à des fins de test d'acceptation d'équipements physiques ou matériels. Des modèles de véritables programmes sont simulés après une traduction vers l'environnement de destination. Lors de la 2950449 -9- simulation, les données associées au modèle peuvent n'être modifiées qu'en partie. Avant l'exécution de la simulation, les commandes typiquement en langage C et C++ sont modifiées à l'aide d'une interface graphique.

5 Le document US 4 845 665 décrit le développement sur station de travail de programmes pour des interfaces externes, sous forme d'écrans d'affichages. Pour évaluer l'ergonomie d'un programme avant que son code ne soit produit, il est possible d'altérer des interfaces de manière réversible en cours de 10 simulation de ce programme. Les changements observés sont enregistrés sur un disque. Des tables et leurs formats sont simulés. Le document US 5 260 874 décrit un système de test d'émulation de vol pour avion de ligne au sol. On voit un véhicule 15 routier relié à un avion en arrêt d'exploitation par des câbles amovibles, pour vérifier le bon fonctionnement de divers de ses composants vitaux mécaniques et électriques. L'émulation vérifie que ces composants répondent correctement aux sollicitations appliquées par ce système de test.

20 Le document US 5 541 863 décrit un banc de test virtuel à logiciels intégrés, pour l'avionique. Ce banc de test reconfigurable emploie une simulation partielle ainsi que des équipements physiques véritables. Des affichages graphiques à fonctions multiples représentent sous forme de graphiques et de tables les 25 informations pouvant être fournies à un écran de station de travail telle qu'une station DEC sous VMS. Des unités remplaçables en ligne (LRU) sont testées sous forme réelle ou par remplacement sur un banc dit "rack" de son module de simulation. De nombreux changements dans le programme en cours de développement sont 30 rendus apparents. Ce banc permet le test des logiciels embarqués simulés ou sur calculateur embarqué sans simuler de façon 2950449 -10- exhaustive les interfaces physiques des équipements ou modules. On peut tester au choix le fonctionnel de l'équipement simulé ou l'équipement réel. La simulation des équipements restent tronquée à la partie fonctionnelle.

5 Toujours dans le domaine des simulations numériques, appelée aéronef virtuel dans le domaine aéronautique, divers protocoles sont employés. Ces protocoles participent à l'intégration modulaire avionique (en anglais IMA pour « Integrated Modular Avionics » en langue anglaise).

10 L'invention simule des protocoles et permet leur modification en cours de simulation. Par exemple, l'invention simule les protocoles dédiés à l'avionique suivants : ARINC429, ARINC653, MIL-STD-1553B. En outre, des protocoles, normes ou langages du domaine 15 général de l'informatique sont employés dans certains exemples de l'invention. Il s'agit notamment de : RS422, Ethernet, (Langage extensible de Marquage dénommé aussi langage de marquage ou encore « eXtensible Markup Language » en langue Anglaise) XML, C/C++.

20 Tous ces outils, langages, protocoles, normes et systèmes auxquels l'invention fait appel dans certains exemples, sont décrits classiquement dans des publications dont il est aisé de prendre connaissance notamment sur l'Internet. On en trouvera sur l'encyclopédie mutuelle en ligne Wikipedia 25 (http://fr.wikipedia.org ), des descriptifs des documents cités qui peuvent être rapprochés de l'invention. On a déjà vu que la simulation en temps réel de systèmes avioniques pose à l'heure actuelle divers problèmes techniques, 2950449 -11- notamment lorsqu'est requise une haute représentativité du système avionique simulé. Par exemple, tel est le cas lorsque la simulation doit intégrer des flux de données hétérogènes issus d'un radioaltimètre et / ou 5 d'un capteur (e.g. de température) et / ou d'un gyroscope. En d'autres termes, il est actuellement difficile en pratique, voire impossible, d'obtenir une abstraction c'est-à-dire une « translation » ou traduction de ces flux de données hétérogènes, de manière simple.

10 Par exemple, des données au format d'ingénierie en radian devant être traduites dans le protocole avionique en un signal analogue, doit être convertie en une valeur de tension strictement conforme aux tables de conversion spécifiées formellement. De fait, il est notamment ardu avec les simulations actuelles, 15 de représenter fidèlement l'architecture réelle du système avionique et / ou que le système ne soit représenté qu'en partie. Un autre problème rencontré actuellement lors des simulations de système avionique est de disposer de définitions exhaustives et fiables des différents constituants du système 20 avionique que l'on désire simuler. On dit parfois que de telles définitions qui sont représentatives de la réalité sont consistantes. En particulier ceci est vrai pour les interfaces entre ces constituants et / ou leurs sous-ensembles (notamment les partitions de certains équipements). Autrement dit, il est 25 actuellement difficile de disposer de définitions consistantes et exhaustives de l'architecture avionique d'un système à simuler. Un autre problème est qu'il est actuellement ardu voire impossible en pratique de restituer sur une maquette, des données 2950449 -12- suffisamment fiables et aisées à traiter en vue de la qualification (spécification) de l'un au moins des équipements du système avionique. En particulier, ces données de qualification devraient 5 constituer telles quelles un fondement acceptable et reconnu par les autorités compétentes pour une homologation (à l'instar de la qualification incrémentale connue dans le domaine de l'assurance qualité). Encore un autre problème est de disposer d'un 10 environnement de simulation flexible et fiable pour permettre le rendu lisible (en anglais « monitoring ») de toutes les données de la simulation (quelles soient au format d'ingénierie et / ou avionique). Par conséquent, il serait utile de permettre l'analyse de 15 comportement des constituants du système avionique et de leurs interactions, dans un contexte représentatif des conditions opérationnelles réelles. Par exemple une simulation flexible permettrait de prendre en compte les plages de tolérance opérationnelles et / ou afin de 20 définir et / ou d'évaluer des marges de manoeuvres acceptables pour un ou plusieurs constituants système avionique. L'un des problèmes supplémentaires rencontrés à ce jour avec les bancs de test est qu'il est délicat en pratique, d'effectuer des tests d'un système avionique dont les constituants essentiels 25 ne sont pas disponibles et / ou opérationnels. On a vu qu'il serait souhaitable de disposer d'une simulation « mixte ». 2950449 -13- Celle-ci permettrait d'intégrer à la simulation, au fur et à mesure qu'elles sont disponibles, les validations de divers acteurs impliqués dans la production d'un aéronef (notamment les responsables de fonctions et / ou architectes avionique et / ou des 5 responsables d'essais en vol et I ou des services étatiques). Alors, pour chaque évolution de l'avionique à simuler qui est identifiée, il serait possible d'obtenir une parfaite traçabilité / conformité de la simulation correspondante. De plus, il convient que la simulation s'adapte aux objectifs 10 de maintenabilité (autrement dit de pérennité) imposés aux systèmes avioniques. A cette fin, il convient que la simulation puisse être générée à volonté pour prendre en compte chaque évolution requise du système avionique.

15 Par exemple, la plateforme de simulation doit supporter les diverses générations d'outils d'élaboration des systèmes avioniques et / ou être compatible avec des outils employés dans l'élaboration d'ensembles connexes (fonctionnellement liés pour rendre opérationnel l'aéronef). Ceci concerne notamment 20 l'environnement logiciel. L'un des objectifs de l'invention est donc de permettre la conception, la mise au point et la validation exhaustivement en simulation temps réel, et éventuellement avant son existence physique, d'un système avionique partiel ou complet.

25 Une telle simulation devrait non seulement couvrir l'étude et la validation fonctionnelle du système avionique, mais aussi son architecture. 2950449 - 14 - Un autre objectif de l'invention est de mettre au point et de pouvoir disposer de moyens aptes à valider en simulation : L'architecture avionique, c'est à dire les spécifications des interfaces entre les équipements qui vont être embarqués ; et / 5 ou - Les spécifications des interfaces internes à certains de ces équipements ; et / ou Les spécifications des fonctions logicielles qui composent ces équipements, 10 Ainsi, après validation sur la maquette qui forme un outil de test, le système avionique ainsi testé virtuellement, doit pouvoir fonctionner de manière identique à celle de son vol réel, ce qui minimise les problèmes ou défauts ordinairement rencontrés au cours du premier vol ou postérieurement à chaque modification de 15 définition préalablement testée sur un simulateur conventionnel. En effet, le développement et le test de systèmes avioniques deviennent de plus en plus complexes. Ceci a pour cause l'important volume de données à traiter. Ce qui induit des délais et des coûts de développement de plus en 20 plus importants. De plus, les équipements sont d'une complexité de plus en plus élevée. Tel est le cas pour certains équipements permettant d'embarquer plusieurs fonctions (e.g. conformes au protocole ARINC653).

25 De manière similaire, l'évolution des protocoles de communications (e.g. discrets, signaux analogiques, ARINC429, RS422 et Ethernet) entre les équipements d'un système avionique 2950449 -15- à simuler, requièrent une mise à jour majeure des outils de simulations conventionnels. On a vu que les outils actuels de simulation et de test ne permettent pas une couverture de test complète des spécifications 5 pour un système avionique. En effet, ces outils ne restituent pas efficacement les comportements des niveaux les plus bas d'interface et d'échange entre les équipements réels ou leur sous-ensemble. De plus certains équipements ne peuvent être testés 10 complètement par un outil actuel de simulation et de test du type banc pour équipements réels. Par exemple une centrale inertielle possède certains modes de fonctionnement qu'il est difficile de valider sur banc avec des équipements réels. Ainsi par exemple, les outils actuels de simulation de test sur 15 spécifications se limitent aux tests fonctionnels des équipements. En conséquence, ces outils de simulation de test sur spécifications ne permettent pas de représenter et de tester les protocoles et / ou formats d'échanges réels, tels qu'ils seront mis en oeuvre physiquement sur l'aéronef.

20 En synthèse, l'invention vise à permettre la modélisation ou représentation de systèmes avioniques complexes, éventuellement partiels et / ou hybrides, pour effectuer des simulations, tout en atteignant des niveaux de sécurité, traçabilité et maintenabilité inédits.

25 A cet effet, un objet de l'invention est un procédé de simulation en temps réel d'un système avionique destiné à un aéronef. 2950449 -16- Ledit système avionique est prévu pour posséder au moins deux équipements. Au moins l'un de ces équipements comprend au moins deux partitions, un système d'exploitation (OS) avionique installé sur un calculateur et trois interfaces de communication 5 dont une interface pour les échanges entre lesdites partitions, une autre interface pour la communication avec le système d'exploitation (OS) de l'équipement et une interface de communication avec des pilotes de communication entre cet équipement et le système avionique.

10 Selon l'invention, un système d'exploitation de la simulation en temps réel est différent d'au moins un système d'exploitation (OS) avionique installé sur un calculateur d'équipement. Ce procédé effectue, pour disposer lors de la simulation de définitions complètes et consistantes desdites interfaces, au 15 moins : une étape de translation en temps réel, au fur et à mesure de leur fourniture et évolution, de l'ensemble des données au format d'ingénierie relatives au système avionique, en données au format avionique ; et 20 une étape de gestion dynamique qui prévoit de regrouper, de mettre à jour et en partage une base de données incorporant pour chaque équipement, l'ensemble des signaux relatifs aux interfaces de communication, sous forme de données au format avionique.

25 Selon une caractéristique, pour permettre une simulation au moins partielle, ce procédé prévoit que l'étape de translation en données au format avionique est opérée à partir de fichiers formels en langage de marquage informatique ou balisage générique, ces 2950449 -17- données au format avionique définissant l'aéronef de destination réel. Selon une autre caractéristique, pour permettre une simulation d'au moins un constituant dit matériel qui traite des flux 5 d'informations sous forme de valeurs physiques variables, ce procédé prévoit que l'étape de translation encode sous forme de modèle en langage de haut niveau, le comportement physique dudit équipement matériel, en ce qui concerne les accès à son interface. Selon encore une autre caractéristique, pour permettre une 10 simulation d'au moins un constituant ou dispositif de capture qui produit des flux d'informations sous forme de données au format d'ingénierie significatives d'un environnement du système avionique à simuler, ce procédé prévoit que l'étape de translation encode lesdites données d'ingénierie dudit dispositif de 15 capture sous forme de modèle en langage de haut niveau représentatives de paramètres de format de ce dispositif de capture réel. Une caractéristique du procédé prévoit que, pour permettre une simulation d'au moins un constituant ou dispositif de 20 déclenchement qui produit des flux d'informations sous forme de données d'ingénierie destinées à agir sur le système avionique à simuler, ce procédé prévoit que l'étape de translation encode lesdites données d'ingénierie dudit dispositif de déclenchement sous forme de modèle en langage de haut niveau représentatives 25 de paramètres de format de ce dispositif de déclenchement réel. Par exemple, les flux d'informations des constituants d'équipement matériel, de capture et de déclenchement sont de type discrets et / ou analogiques et / ou numériques notamment compatibles avec un protocole tel que ARINC429, ARINC653, MIL- 30 STD-1553B, RS422, Ethernet. 2950449 -18- Suivant une caractéristique du procédé, l'étape de gestion des descriptions prévoit de mémoriser en partage dynamique dans ladite base de données des modèles de l'architecture de communication entre eux et / ou au sein d'un ensemble à jour des 5 équipements du système avionique à simuler. Suivant une autre caractéristique du procédé, l'étape de gestion des descriptions prévoit de générer des documents de spécifications d'interface de pré requis (IRS) à partager dans ladite base de données.

10 Suivant encore une caractéristique du procédé, l'étape de gestion des descriptions prévoit de générer automatiquement en format avionique compatible avec une interprétation et un accès en temps réel lors de la simulation, des données représentatives des interfaces d'équipements.

15 Le procédé prévoit selon une caractéristique de l'étape de gestion des descriptions, qu'à cette étape la base de donnée partagée alimente la simulation suite à une analyse automatique des descriptions d'interfaces opérée lors d'une phase de pré traitement et production de fichiers en code source de l'étape de 20 translation, ladite étape fournissant en retour des services et fonctions significatives d'échanges effectifs au sein du système avionique, à représenter par la simulation. Suivant une réalisation, l'étape de gestion des descriptions qui prévoit de regrouper les signaux d'interface dans la base de 25 données, par transmission réseau, par exemple filaire (LAN, ADSL, etc.) et / ou sans fil (Wifi, WPAN, UHF, IEEE802.15.4, etc.), en amont et / ou durant la simulation, notamment lors d'une phase de branchement réel et / ou virtuel d'un équipement, voire durant des tests du système avionique et / ou essais de l'aéronef de 30 destination. 2950449 -19- Un autre objet de l'invention vise une plateforme apte à mettre en oeuvre le procédé évoqué plus haut, cette plateforme comprenant un ordinateur personnel (PC) avec un système d'exploitation de type Linux®. Cette plateforme comporte un 5 périphérique de branchement d'équipements réels et / ou de modèles analogiques et / ou numériques, pour la transmission de données binaires et / ou discrètes ou analogiques. Selon une réalisation, la plateforme comporte au moins un volume physique de mémoire pour l'enregistrement de données 10 translatées au format avionique et encodées suivant une séquence de bits véritable. Encore un autre objet de l'invention est un système avionique pour un aéronef de destination. Ce système avionique a fait l'objet d'au moins une simulation conforme au procédé évoqué plus haut.

15 Ce système avionique possède au moins deux équipements. Au moins l'un de ces équipements comprend au moins deux partitions, un système d'exploitation (OS) avionique installé sur un calculateur et trois interfaces de communication dont une interface pour les échanges entre lesdites partitions, une autre interface 20 pour la communication avec le système d'exploitation (OS) de l'équipement et une interface de communication avec des pilotes de communication entre cet équipement et le système avionique. Au moins l'un de ces équipements est compatible avec l'un des protocoles : ARINC429, ARINC653, MIL-STD-1553B, RS422, 25 Ethernet. Un dernier objet de l'invention est un aéronef. Cet aéronef comporte au moins un système avionique ayant fait l'objet d'au moins une simulation conforme au procédé évoqué plus haut. 2950449 -20- Dans une réalisation, l'aéronef selon l'invention est un aéronef à voilure tournante. Par exemple, cet aéronef à voilure tournante est un hélicoptère.

5 Dans une mise en oeuvre, cet aéronef est un hélicoptère hybride. Dans une autre réalisation, l'aéronef selon l'invention est un avion. Une réalisation de l'invention prévoit que l'aéronef est un 10 drône. L'invention et ses avantages apparaissent plus en détail dans la description qui suit d'exemples de réalisation donnés à titre illustratif, en référence aux figures annexées. la figure 1 est une vue schématique de l'invention du 15 déroulement et du contexte, en termes de procédé, d'étapes automatisées et / ou manuelles, de phases et de constituants d'installation ; des étapes / phases marquées d'un « M » cerclé étant au moins en partie manuelles, les autres étant automatisées ; - la figure 2 est une vue schématique d'un exemple 20 d'équipement complexe selon l'invention, qui comprend plusieurs partitions ; - la figure 3 est une vue schématique d'élévation longitudinale d'un aéronef à voilure tournante selon l'invention, de type hélicoptère conventionnel, à poste de pilotage habitable, et 25 pourvu d'au moins un système avionique conforme à l'invention ; la figure 4 est une vue schématique en perspective d'élévation longitudinale de dessus et de devant, d'un aéronef 2950449 -21 - conforme à l'invention et du type hélicoptère hybride, sous forme de drone, avec un poste de pilotage hors bord ; - la figure 5 est une vue schématique en perspective d'élévation longitudinale de dessus et de devant, d'un aéronef à 5 voilure tournante selon l'invention et du type avion, à poste de pilotage habitable, et conforme à l'invention ; - la figure 6 est une vue schématique représentative d'un visuel en vue d'architecte conforme à l'invention issue d'une simulation conforme à l'invention ; 10 - la figure 7 est un graphique illustrant une vue d'ensemble des procédures de développement de systèmes avioniques conformes à l'invention ; - la figure 8 est un autre graphique illustrant dans son contexte proche, une procédure de simulation hautement 15 représentative conforme à l'invention ; - la figure 9 est un graphique illustrant le déroulement d'un traitement de données conforme à l'invention avec phases marqués d'un « A » cerclé étant au moins en partie automatisées, les autres étant manuelles ; cette figure est à rapprocher de la figure 6 ; 20 - la figure 10 représente un affichage visuel qui illustre un exemple d'activateur de label conforme à l'invention au sein d'un système avionique hydraulique, est donc à rapprocher de figures 6 et 9 ; et - la figure 11 représente un affichage visuel qui illustre un 25 exemple de fenêtre de vidage (dumping) d'investigation qui s'applique à un équipement hydraulique conforme à l'invention, et à rapprocher de figures 6, 9 et 10. 2950449 -22- Des exemples de réalisations et de mises en oeuvre de l'invention sont maintenant exposés. Sur les figures 3 à 5 notamment, la référence 1 désigne de façon générale, un aéronef. Cet aéronef 1 comporte au moins un 5 système avionique 2, qui on le verra, a été l'objet d'une simulation conforme à l'invention. Sur les figures 3 à 5 sont également représentées trois directions X, Y et Z orthogonales les unes aux autres. En aéronautique, cette direction X correspond généralement à l'axe de 10 roulis de l'aéronef 1. Une autre direction Y dite transversale, correspond aux largeurs ou dimensions latérales des structures décrites. La direction longitudinale X et la direction transversale Y sont parfois dites horizontales, par simplification.

15 Une troisième direction Z est dite d'élévation et correspond aux dimensions en hauteur des structures décrites. Parfois, cette direction d'élévation Z est dite verticale. Sur la figure 3, l'aéronef 1 selon l'invention est un aéronef à voilure tournante. Dans cet exemple, cet aéronef 1 à voilure 20 tournante est un hélicoptère moderne, avec un rotor principal 3 et un rotor 4 de queue anti-couple. Sur la figure 4, l'aéronef 1 est un hélicoptère hybride. Un aéronef 1 de type hélicoptère hybride, est un concept avancé d'aéronef à décollage et à atterrissage verticaux, dont dès 25 exemples de réalisation sont par exemple décrits dans les documents FR 2 916 418, FR 2 916 419 et FR 2 916 420. 2950449 -23- Sur la figure 4, l'aéronef 1 possède un rotor principal 3 et deux rotors latéraux 4, chacun agencé sur une voilure fixe 5, assurant à la fois des fonctions anti-couple et de propulsion. Par ailleurs, on remarque que sur la figure 4, l'exemple d'hélicoptère hybride est sous forme de drone. Ce drone d'aéronef 1 possède un poste de pilotage 6, qui est ici hors-bord, c'est-à-dire qui n'est pas embarqué. Sur ce poste 6 déporté, est installé de manière à pouvoir être actionné par un opérateur de radio-pilotage (non représenté), un 10 dispositif de commande 7 de vol, ici qui agît à distance sur l'orientation de tangage et / ou de roulis du drone d'hélicoptère hybride. Ce poste 6 possède en outre un organe de contrôle de poussée 8 des rotors latéraux 4. On note aussi qu'un système avionique 2 non embarqué est 15 agencé au sein du poste 6 hors bord de la figure 4. Dans cet exemple, le système avionique 2 possède au moins un équipement 9, c'est-à-dire un constituant complexe de ce système 2. Il en va de même des figures 3 et 5, sauf en ce qu'alors, les équipements 9 des systèmes avioniques 2 de ces des aéronefs 1 20 sont embarqués. Par contre, sur les figures 3 et 5, le poste de pilotage 6 est embarque. Sur la figure 5, l'aéronef 1 selon l'invention est un avion. Des réalisations de l'invention non illustrées prévoient que l'aéronef 1 est un drône d'hélicoptère conventionnel ou d'avion, 25 c'est-à-dire chacun pourvu d'un poste de pilotage 6 hors-bord. Dans le domaine de l'invention, et plus généralement pour tous les aéronefs 1, on désigne par système avionique 2 un ensemble permettant la réalisation d'une série de fonctionnalités dans le cadre de spécifications et d'après des données. 2950449 -24- A titre d'exemple, les systèmes avioniques 2 concernés par l'invention peuvent être : des pilotes automatiques (P/A), des aides à la navigation, des simulateurs d'entrainement (voir figure 8), mais aussi divers systèmes 2 embarqués par exemple relatifs à 5 l'alimentation en carburant ou la fourniture de puissance hydraulique de cet aéronef 1. On distingue parmi ces ensembles ceux qui sont de type entièrement matériel comme ses pièces constitutives et composants physiques, de ceux qui sont de type immatériels 10 comme les logiciels et spécifications. De telles pièces et composants sont parfois mixtes au sens où ils comportent à la fois des organes physiques et de codes logiques ou de tables de données. Dans certains systèmes avioniques 2 auquel l'invention 15 s'applique, des constituants sont embarqués comme sur la figure 3. Mais d'autres systèmes avioniques 2 auquel l'invention s'applique sont des composants hors bord, comme sur la figure 4. En se reportant maintenant à la figure 2, on voit qu'au sein d'un aéronef 1 (symboliquement représenté en trait discontinu, en 20 bas à gauche), est agencé un système avionique 2, qui comporte notamment un équipement 9 embarqué conforme au protocole ARINC653. Classiquement, un système avionique 2 comporte plusieurs équipements embarqués, de types divers. En bref, ce protocole ARINC653 est un standard de 25 partitionnement temporel et spatial de ressources informatiques avioniques. Ce protocole ARINC653 définit également des interfaces de programmation et de configuration qui permettent d'assurer l'indépendance de l'application vis-à-vis de logiciels et de matériels 2950449 -25- sous-jacents. Un principe de partitionnement permet la coexistence sur une même plateforme, de fonctions avioniques de niveaux différents, ceci pour permettre des processus de qualification incrémentale de ces fonctions, ainsi qu'un processus de 5 ségrégation des fournisseurs de fonctions. Le protocole ARINC653 définit en outre une interface de programmation (« API » pour « Application Programming Interface) de portabilité pour les logiciels applicatifs avioniques adoptée notamment par des architectures d'Avionique Modulaire intégrée 10 (AMI). Sur la figure 2, le système avionique 2 prend la forme d'un équipement 9 complexe selon l'invention. L'équipement 9 comprend plusieurs partitions 10 et 1 1, un système d'exploitation ou OS avionique 12, installé sur un 15 calculateur 13. Des pilotes 14 sont connectés par une liaison filaire 15 telle qu'une nappe, à un connecteur 16 qui fait office d'interface de communication 17 de l'équipement 9 avec l'extérieur, notamment le reste de l'équipement 9 du système avionique 2.

20 On remarque que cet équipement 9 possède en fait trois types d'interfaces de communication, dont l'interface de communication 17 avec l'extérieur. Cette interface de communication 17 avec l'extérieur permet des dialogues avec d'autres format d'échanges que le protocole ARINC653, 25 notamment : ARINC429 et / ou signaux d'entrée / sortie Discrets et / ou signaux d'entrée / sortie Analogiques et / ou Ethernet et / ou LVDT, etc. On remarque entre chaque liaison 15 et les pilotes 14, un circuit intégré micro-électronique spécialisé 18, dit « Application 2950449 -26- Specific Integrated Circuit » (ASIC). Chaque circuit 18 assure le fonctionnement d'un port externe de type « APEX ». On note également sur la figure 2 que l'équipement 9 possède une pluralité de modules 19. Sur la partition 10, des ports internes 21, également de type « APEX », font partie d'une interface de communication 21 de cette partition 10 avec une autre partition 11, par l'intermédiaire de canaux 23 dits « channels ». Similairement sur la partition 11, des ports internes 21, 10 également de type « APEX », font partie d'une autre interface de communication 24 de cette partition 11 avec les pilotes 14. Par les interfaces de communication 23 et 24, transitent essentiellement des données au format avionique ou « RawData ». On voit qu'au sein de la partition 11, sont installées deux 15 procédures 25. Ces procédures 25 traitent quant à elles des données au format d'ingénierie. Les trois interfaces de communication sont donc, une interface 22 pour les échanges entre lesdites partitions 10-11, une autre interface 26 pour la communication de ces partitions 10-11 20 avec le système ou OS avionique 12 de l'équipement 9, et l'interface de communication 24 avec des pilotes de communication 14 vers le reste du système avionique 2. On a vu que l'invention permet la simulation d'un système avionique 2 d'aéronef 1. Dans l'exemple simulation illustré à la 25 figure 1, l'invention est développée pour fonctionner sur un ordinateur personnel (PC) du commerce schématiquement représenté en 27, par exemple un ordinateur portable. Sur l'ordinateur 27 est installé un système d'exploitation 28 de type 2950449 -27- Linux®, qui est évidemment distinct de l'OS avionique 12 de la figure 2. On comprend qu'un tel ordinateur 27 se distingue d'une station de travail dédiée et n'est ici pas pourvu de capacités de traitement et d'un nombre de processeurs supérieurs à celui du système avionique 2 à simuler. Cet ordinateur 27 est prévu pour simuler de 30 à 250 constituants et dispose de quatre unités de traitement ou « CPU », ici de type Intel® Double Dual Core en 32 bits. La fréquence 10 d'horloge de l'ordinateur 27 est 2,4 GHz. L'ordinateur 27 et son système d'exploitation 28 font partie d'une plateforme 29 qui apte à mettre en oeuvre l'invention. La plateforme 29 de la figure 1 comporte un périphérique 30 de branchement de constituants et / ou d'équipements 9 réels, 15 ainsi qu'un périphérique 31 de branchement modèles analogiques et / ou numériques, pour la transmission de données binaires et / ou discrètes ou analogiques. On voit également que la plateforme 29, et plus précisément son ordinateur 27, est pourvue d'au moins un périphérique de 20 visualisation ou console 32. Ce périphérique 32 est dans l'exemple de la figure 1, un écran d'affichage. Le périphérique 32 est relié à un agencement 33 d'interface de visualisation des informations liées au protocole ARINC429, un agencement 34 de visualisation des informations d'architecte et un agencement 35 de commande 25 des modèles de simulation. Selon cette réalisation, la plateforme 29 comporte également plusieurs volumes physiques 36 de mémoire pour l'enregistrement de données translatées au format avionique. Ces volumes 2950449 -28- physiques 36 sont couplés à des fonctions d'entrée / sortie représentées en 41. Un autre volume de mémoire 37 comporte un environnement de mémoire partagée, sur lequel sont enregistrées des données au 5 format d'ingénierie. Ces données sont issues et / ou destinées à des modèles 38 de comportement physique, à des panneaux de commande virtuelle 39 et à des modèles 40 de constituants ou dispositifs de capture, typiquement des capteurs ou « sensors ». Ces modèles 40 de 10 dispositifs de capture sont couplés à des fonctions d'entrée / sortie également représentées en 41. Ceci permet la mise en oeuvre d'une l'étape dite de translation, d'un procédé selon l'invention. En effet, pour permettre une simulation d'au moins un 15 constituant formant dispositif de capture qui produisent des flux d'informations sous forme de données au format d'ingénierie, significatives d'un environnement du système avionique 2 à simuler, on prévoit que cette étape de translation encode lesdites données d'ingénierie dudit dispositif de capture sous forme de 20 modèle en langage de haut niveau représentatives de paramètres de format de l'équipement de capture réel. Similairement, pour permettre une simulation d'au moins un constituant formant dispositif de déclenchement, par exemple une commande ou un servo-contrôle qui produit des flux d'informations 25 sous forme de données d'ingénierie destinées à agir sur le système avionique à simuler, ce procédé prévoit que l'étape de translation encode lesdites données d'ingénierie dudit dispositif de déclenchement sous forme de modèle en langage de haut niveau 2950449 -29- représentatives de paramètres de format de ce dispositif de déclenchement réel. Par exemple, les flux d'informations des constituants matériel, de capture et de déclenchement sont de type discrets et / 5 ou analogiques et / ou numériques notamment compatibles avec un protocole tel que ARINC429, ARINC653, MIL-STD-1553B, RS422, Ethernet. Ceci étant, on comprend que la figure 1 expose le déroulement et le contexte de l'invention, en termes de procédé, 10 d'étapes automatisées et / ou manuelles, de phases et de constituants d'installation, et par rapport à un cycle de vie 42 de l'aéronef 1 de destination. Ce cycle prévoit des périodes 43, 44 et 45 respectivement de spécification / d'intégration / d'évaluation et qui comprend au 15 moins une simulation opérée sur la plateforme 29. Notons que sur la figure 1, les blocs marqués d'un « M » cerclé nécessitent pour leur exécution, une intervention au moins en partie manuelle. Les autres sont automatisés, à l'exception du bloc représentatif de la période 44 d'intégration, qui est 20 partiellement manuel et automatique. En 46 est représenté un autre volume de mémoire destiné à l'enregistrement de données au format avionique, et en particulier à des spécifications d'interface de pré requis (IRS). Suivant une particularité de l'invention, une étape de gestion 25 de descriptions qui sera mieux décrite plus loin, prévoit de générer des documents de spécifications IRS, à partager une ladite base de données hébergée au sein du volume de mémoire 46. 2950449 -30- Encore un autre volume de mémoire 47 est destiné à l'enregistrement de données au format avionique, et en particulier à des Modèles d'interface Homme-Machine (HMI). Des structure d'entrée / sortie de partitions 48 sont couplées à ce volume 47, lui- 5 même lié au volume 46, via des fonctions d'entrée / sortie également représentées en 41. En amont de la plateforme 29, on voit que la simulation selon l'invention recourt à des bases de données dédiées, qui constituent des ressources.

10 L'une de ces bases de données, désignée en 49 est dédiée aux spécifications interfaces. Ces ressources définissant les spécifications interfaces sont typiquement sous forme de « langage extensible de balisage ». Un tel langage, dans l'exemple celui qui est appelé XML, est 15 un langage informatique de balisage générique qui sert essentiellement à stocker / transférer des données de type texte Unicode structurées en champs arborescents. Ce langage est qualifié d'extensible car il permet à l'utilisateur de définir les balises des éléments. L'utilisateur peut multiplier les espaces de 20 nommage des balises et emprunter les définitions d'autres utilisateurs. En effet, la simulation conforme à l'invention prévoit que pour permettre une simulation au moins partielle, l'étape de translation en données au format avionique est opérée à partir de 25 fichiers formels en langage informatique de balisage générique, ces données au format avionique définissant l'aéronef 1 de destination réel. Dans l'élaboration de la simulation telle qu'elle est illustrée par la figure 1, une première étape 50 prévoit la constitution de la 2950449 - 31 - base de données 49 dédiée à ces spécifications d'interfaces. On voit que cette étape 50 est opérée manuellement. Cette étape 50 implique une analyse des interfaces, notamment en termes de consistance des échanges de données.

5 Ceci aboutit à la création d'un jeu exhaustif de fichiers dans le langage extensible de balisage XML, qui inventorie tous les échanges au sein du système avionique 2, ainsi que toutes les fonctions nécessaires à la gestion de ces échanges. Deux principaux fichiers XML sont à prévoir : 10 un fichier 51 de description de toutes les sorties générées par chaque type d'équipement 9, et indiquant la manière dont les données sont formatées; le fichier 51 regroupe aussi toutes les données définissant les correspondances entre données 15 physiques et électrique ; et un fichier 52 qui décrit tous signaux émis par un type donné d'équipement, ainsi que toutes les occurrences de ces équipements ; Pour chaque signal, l'ensemble des équipements et autres constituants du système avionique 2 à simuler, qui sont à même d'invoquer ce signal sont intégrés au fichier 52. En ce qui concerne les équipements 9 conformes au protocole ARINC 653, il convient de prévoir en outre dans la base 49, deux autres fichiers, à savoir : un fichier 53 descriptif de tous les ports émis ou reçu par chaque partition (e.g. 10, 11) d'un équipement 9 tel que celui de la figure 2 ; et 20 25 2950449 - 32 - un fichier 54 décrivant l'ensemble des canaux (comme le canal 23) émis ou reçu par chacune des partitions (10, 11) de cet équipement 9. A ce stade, intervient une seconde étape préalable, désignée 5 en 55 sur la figure 1. Cette étape 55 a déjà été évoquée, et est l'étape de translation en temps réel. Cette étape de translation 55 est opérée (bloc 56) au fur et à mesure de la fourniture et de évolution du système avionique 2. Ces évolutions fournissent progressivement et ajustent l'ensemble 10 des données au format d'ingénierie relatives au système avionique 2, qui sont alors traduites sous forme d'abstraction, en données au format avionique. Lors de l'étape de translation 55 qui est automatique, les librairies et entêtes de fichiers sont également traduites, et sont 15 générés des composants sous forme de structure C/C++ significatives des définitions nécessaires. Au bloc 56 un partiteur de simulation opère l'investigation suivant le code CREATE SAMPLING PORT, 20 READ SAMPLING MESSAGE, WRITE SAMPLING PORT... Pour l'encodage et le décodage, et vice-versa, sont générées lors de l'étape automatique de translation 55, les fonctions suivant le code: 25 Analog_set_value, analog_get_value, discrete_set_value, discrete_get_value, a429_set_label, a429_get_label, 2950449 -33- a429_set_sdi, a429_get_sdi, a429_set_ssm, a429_get_ssm... Pour compléter l'étape automatique de translation 55 et les fonctions, le code suivant est exécuté 5 Lxxx_yy_get_zzzz et Lxxx_yy_set_zzzz Where Xxx represents label number Yy represents SDI and Zzzz represents encoded field.

10 En pré traitement de la simulation selon l'invention, interviennent suite à l'étape 55 des traductions de sous systèmes, opérées à l'étape 57 représentée à la figure 1. Une base de données 58 est alimentée manuellement, par les apports issus d'un outil dédié aux fonctionnalités de pilotage 15 automatique, sous forme de spécifications. Un générateur 59 est alimenté avec ces spécifications provenant de la base 58, ce générateur 59 étant automatique. Puis, l'étape 57 est à proprement parler exécutée par un traducteur automatique 60 dédié P/A. Les spécifications de la base de données 58 sont alors 20 translatées (traduites automatiquement) vers un format d'environnement de simulation interactif en temps réel, tel que ceux typiquement employés dans les outils de test et / ou les réseaux d'entrainement médiatisés au pilotage. Après l'étape 57 de traduction de sous systèmes de 25 fonctionnalités de pilotage automatique, il est possible que le format d'environnement de simulation interactif en temps réel 2950449 -34- (données au format avionique) soit invoqué par la simulation selon l'invention, opérée par la plateforme 29. Toujours en pré traitement de la simulation selon l'invention, interviennent suite à l'étape 55 des traductions de sous systèmes, 5 opérées à une étape 61 représentée à la figure 1. Pour ce faire, une base de données 62 est alimentée manuellement, par les apports issus d'un outil dédié aux interfaces Homme Machine (HMI), également sous forme de spécifications. Un générateur 63 est alimenté avec ces spécifications provenant 10 de la base 62, ce générateur 63 étant automatique. Puis, l'étape 61 est à proprement parler exécutée par un traducteur automatique 64 dédié HMI. Les spécifications de la base de données 62 sont alors translatées traduites automatiquement.

15 Après l'étape 61 de traduction de sous systèmes de fonctionnalités d'interfaces Homme Machine, il est possible que le les données au format avionique soient invoquées par la simulation selon l'invention, opérée par la plateforme 29. La figure 1 montre enfin une étape 65 de mise à jour 20 automatique quand une nouvelle simulation est intégrée après qu'ait été délivrée une nouvelle version des interfaces des équipements 9 ou des logiciels embarqués dans ces derniers. En se fondant sur un exemple de système avionique possédant (au moins) un constituant hydraulique dont la 25 température est contrôlée durant le fonctionnement (à simuler) de l'aéronef 1, d'autres fonctionnalités de l'inventions sont exposées. 2950449 -35- Sur la figure 6, on voit que la plateforme 29, et plus spécialement son périphérique de visualisation 32, affiche un visuel 66 sous forme de vue d'architecte. Ce visuel 66 illustre un exemple de symbologie appliquée à 5 une interface de pilotage, relativement à une fonction hydraulique embarquée. Le visuel 66 est interactif et permet la sélection de quatre modes. Il s'agit du mode de visualisation des valeurs physiques 10 sélectionné par pointage sur un bouton virtuel 67. En pointant sur un bouton virtuel 68 est sélectionné un mode de visualisation des valeurs électriques. Un mode de visualisation des défauts de valeurs physiques est sélectionné par pointage sur un bouton virtuel 69. En pointant 15 sur un bouton virtuel 70 est sélectionné un mode de visualisation des défauts de valeurs électriques. Sur la figure 6, on voit deux calculateurs 71 à gauche et 72 à droite. Chacun de ces es calculateurs 71 et 72 possède un canal A et un canal B, reliés de manière à permettre des échanges croisés 20 (« cross talk »). Ces calculateurs 71 et 72 fonctionnent en parallèle, de sorte que l'un (71) en charge des acquisitions normales 75 et des productions (VMS) de symbologies 73 pour le pilote et le copilote. Ces symbologies 73 visent notamment la température hydraulique.

25 L'autre calculateur 72, en parallèle reçoit un flux fonctionnel cyclique 74 pendant l'exécution, pour opérer une consolidation de données issue d'une simulation de redondances 77. 2950449 -36- A ces fins, les calculateurs 71 et 72 sont reliés à des capteurs de température 76, l'un pur l'acquisition normale 75 et l'autre pour l'le flux cyclique 74. Une commande 78 de puissance électrique reliée au 5 calculateur 71 possède une mise à la masse 79, et des voies 80 de marche automatique, 81 d'arrêt et 82 de test. Ceci est à rapprocher d'une étape de gestion dynamique qui prévoit de regrouper, de mettre à jour et en partage une base de données incorporant pour chaque équipement, l'ensemble des 10 signaux relatifs aux interfaces de communication, sous forme de données au format avionique En se reportant maintenant à la figure 7 on voit un graphique illustrant une vue d'ensemble des procédures de développement de systèmes avioniques 2 conformes à l'invention.

15 On y montre des espaces de travail 83 à 86. L'espace de travail 83 est local et dédiés acteurs impliqués dans la simulation. Ceci permet d'intégrer à la simulation, au fur et à mesure qu'elles sont disponibles, les validations de ces acteurs impliqués dans la production de l'aéronef 1.

20 De tels acteurs représentés en 87 sont notamment des responsables de fonctions et / ou des architectes avionique et / ou des pilotes d'essais en vol et / ou des services étatiques. Une base de données d'interface 88, comparable à la base 58 regroupe les données au format d'ingénierie propres à 25 l'environnement de simulation interactif en temps réel employé dans les outils de test et / ou les réseaux d'entrainement médiatisés au pilotage. On désigne en 89 un impact de validation. 2950449 -37- La référence 90 désigne une demande vers un acteur 87, de mise à jour d'informations et de distribution. Elle relie l'espace 83 à l'espace 84, où est représenté une autre base de données d'interface 91, de référencement de communication d'interfaces.

5 Pour un référencement 92, la base de données d'interface 91 met à jour en 93 et collecte des données notamment au format avionique. Cette base 91 procède aussi à des évaluations 94 de requêtes de mise à jour, par exemple issues de l'espace de travail 86.

10 Dans l'espace 86 on voit une interface 96 modifiée de référencement issue de la base 91 qui s'applique à une interface de simulation hautement représentative 97, suite à la confirmation officielle 98 d'une requête de mise à jour. Depuis les évaluations 94, des requêtes rejetées de 15 modifications 98 sont signifiées à un utilisateur 99 de la de simulation hautement représentative. Cet utilisateur 99 produit et transmet des besoins 100 de modifications et d'évaluation vers l'interface 96 modifiée de référencement. Des validations locales 101 transitent depuis l'emplacement 20 de l'interface de simulation hautement représentative 97, vers l'utilisateur 99. Dans l'espace de travail 85, on voit une base de données 95 de translation 103 et extraction 103, ainsi qu'une procédure de simulation hautement représentative.

25 La figure 8 montre un graphique illustrant dans son contexte proche, une procédure de simulation hautement représentative. 2950449 -38- Des étapes et / ou phases de pré traitement 104 sont opérées sur une plateforme 29 légère (PC) pourvue d'un affichage 105 de visualisation d'aides au vol simulées. La plateforme 29 pilote des phases et / ou étapes d'entrée / 5 sorties de simulation, avec des modèles 106 simulés de couches de communication d'équipements complexes, une mémoire partagée 107 d'interface translatée en données au format avionique, des services 108 d'encodage / décodage. Sont également prévus des services de visualisation 109 qui 10 interagissent avec un poste 110 de commande de simulation ; La plateforme 29 opère suite aux prétraitements, à l'édition de liens vers des librairies dynamiques, selon l'étape de gestion dynamique désignée en 111. Sur la figure 9 on voit un graphique illustrant le déroulement 15 d'un traitement de données conforme à l'invention. Ce graphique s'inscrit dans le cadre d'un exemple de suivi de température hydraulique dans un système avionique. Des étapes / phases de la colonne 112 à gauche sont opérées au sein des modèles, tandis que les étapes / phases de la 20 colonne 113 de droite sont opérées au sein de mémoires partagées. Des blocs d'étapes / phases 114 à 118 qui sont marqués d'un « A » cerclé, sont au moins en partie automatisées. D'autres blocs 119 à 121 sont d'exécution manuelle. Il en va de même pour le 25 bloc 122. Du fait de la fonction de mesure d'une température hydraulique à laquelle elle se rapporte, cette figure 9 est à 2950449 -39- rapprocher de la figure 6. Le bloc 119 relatif à l'environnement, prévoit des phases de traitement 123 et d'écriture 124. Dans le bloc 121 sont consignées une première partie des données au format d'ingénierie de mémoire partagée. Des 5 températures y sont inscrites en 125 et en 126. Dans le bloc 120 relatif à l'hydraulique, sont prévues trois phases, respectivement 127 de lecture, 128 de traitement et 129 d'écriture. Ces phases aboutissent à la température 126, du bloc 121.

10 Dans le bloc en partie automatisé 115, relatif à un dispositif de capture sous forme de capteur de température, sont prévues des phases manuelle 130 de lecture de la température 126, et automatiques 131 de détermination « analog_set_value » (voir plus haut) et 132 d'écriture « write_message ». La phase 132 alimente 15 une source 136. Le bloc automatisé 116 contient les phases 133 ù 135 propres à un calculateur comparable à celui qui est désigné en 72 sur la figure 6. On y exécute une phase automatique 133 de lecture de message (issu du bloc 114, et en particulier de la source 136 de 20 données au format avionique, avec une valeur de tension en Volts sur un cadran 137). Classiquement ces phases 133 ù 135 exécutent respectivement une lecture de message, un traitement et une écriture de message. Cette écriture 135 de message aboutit dans le bloc 114, pour 25 alimenter un bloc d'échanges croisés 138. Le format des données de ce bloc est avionique. Le bloc automatisé 117 contient les phases 139 ù 141 propres à un calculateur comparable à celui qui est désigné en 71 sur la figure 6. 2950449 -40- On y exécute une phase automatique 139 de lecture de message issu du bloc 114, et en particulier d'une source 142 de données au format avionique). Classiquement ces phases 139 ù 141 exécutent respectivement une lecture de message, un 5 traitement et une écriture de message. Cette écriture 141 de message aboutit dans le bloc 114, pour alimenter un bloc d'échanges croisés 143. Le format des données de ce bloc 143 est avionique. Toujours dans le bloc 114, on voit un bloc 144 de symbolisme, dont les données sont au format 10 avionique. Le bloc de modèles 118 est relatif aux entrées / sorties d'un affichage multi fonction (MFD). Il comporte une phase 145 de lecture de message issu du bloc 144. Il comporte également un phase d'établissement de label 146.

15 Le bloc de données partagées 122 consignées une deuxième partie des données au format d'ingénierie de mémoire partagée. Un paramètre de température y est inscrit en 147. Ce paramètre est transmis au bloc 148, et plus spécialement à sa phase 149. Ce bloc 148 est relatif à un affichage multi 20 fonction (MFD). Il comporte la phase 149 de lecture issue du bloc 147. Il comporte également une phase de visualisation 150. Sur la figure 10 on voit un affichage visuel qui illustre un exemple d'activateur 151 de label, apte à modifier en direct le contenu de labels 152 et 153, par une action bit à bit, 25 conformément à l'invention. Cet activateur 151 permet par un menu déroulant 154, l'affichage de données au format avionique en binaire dont chaque bit peut être modifié indépendamment des autres. 2950449 -41 - Cette figure qui s'applique également à un équipement de type ARINC429 et relatif à une température hydraulique (dont la valeur est ajustée par rapport à une valeur nominale) au sein d'un système avionique 2, est donc à rapprocher de figures 6 et 9.

5 Quant à la figure 11 elle représente un affichage visuel 155 qui illustre un exemple de fenêtre 156 de vidage (dumping) d'investigation. Cette fenêtre présente une sélection opérée par un pointeur 157 de données 158 physiques de modèle hydraulique au format 10 d'ingénierie. Une sélection 159 correspondante de données électriques internes au format avionique, donnent une représentation en temps réel en fonction d'un choix de champs parmi des listes déroulantes 160. Cette figure 11 qui s'applique à un équipement hydraulique, 15 est aussi, à rapprocher de figures 6, 9 et 10. A ce stade, on peut poser pour l'invention, qu'en termes de procédé, pour disposer lors de la simulation de définitions complètes et consistantes des diverses interfaces, on effectue au moins : 20 une étape de translation en temps réel, au fur et à mesure de leur fourniture et évolution, de l'ensemble des données au format d'ingénierie relatives au système avionique 2, en données au format avionique ; et une étape de gestion dynamique qui prévoit de regrouper, 25 de mettre à jour et en partage une base de données incorporant pour chaque équipement 9, l'ensemble des signaux relatifs aux interfaces (10, 11) de communication, sous forme de données au format avionique. 2950449 -42- On a vu que pour permettre une simulation au moins partielle, ce procédé prévoit que l'étape de translation en données au format avionique est opérée à partir de fichiers formels en langage informatique de balisage générique (XML), ces données au 5 format avionique définissant l'aéronef 1 de destination réel. Pour permettre une simulation d'au moins un constituant dit matériel, c'est-à-dire qui traite des flux d'informations sous forme de valeurs physiques variables, ce procédé prévoit que l'étape de translation qui encode sous forme de modèle en langage de haut 10 niveau, le comportement physique dudit constituant matériel, en ce qui concerne les accès à ses interfaces. On se souvient des principaux inconvénients des techniques connues à ce jour. On sait aussi que le développement et le test de systèmes avioniques 2 deviennent de plus en plus complexes à 15 cause de l'important volume de données à traiter à cette fin. Ceci induit des délais et des coûts de développement de plus en plus importants pour les systèmes avioniques 2 nouveaux autant que pour les améliorations ou ajustements de tels systèmes 2.

20 En outre, dans les systèmes avioniques 2 actuels, certains équipements 9 permettent d'intégrer plusieurs fonctions (comme par exemple ceux qui sont conformes au protocole ARINC 653), ce qui en accroit la complexité. Tandis que l'évolution des protocoles (par exemple : discrets, 25 à signaux analogiques, ARINC 429, RS422 et / ou ETHERNET) de communication entre les équipements requiert une mise à jour assez fondamentale notamment en termes de logiciels, des méthodes de simulation, entraînant des surcoûts importants 2950449 -43- Par ailleurs, on a vu que les maquettes actuelles, et encore moins les bancs de test complets, ne permettent pas une couverture de test exhaustive des spécifications d'un système avionique 2.

5 En effet, d'une part quand il s'agit de bancs classiques, ils ne testent pas les niveaux les plus bas d'interface et d'échange entre les équipements réels ou leur sous-ensemble. D'autre part, quand il s'agit de maquettes intégrant de la numérisation, elles ne permettent qu'une couverture de test 10 limitée. Notamment, les maquettes telles que celle qui correspondent sensiblement à l'enseignement du document US 5 541 863, ne permettent en pratique d'opérer une simulation qu'à condition que l'ensemble des équipements 9 (souvent réels, voire modélisés) 15 soient effectivement connectés à la maquette et opérationnels. De fait, en cas de panne de l'un de ces équipements la simulation est immobilisée. De plus certains équipements ne peuvent être testés complètement par un tel banc d'équipements réels.

20 Par exemple une centrale inertielle possède des modes de fonctionnement qu'il est difficile de valider sur banc avec des équipements réels. Ainsi par exemple les systèmes actuels de simulation de test sur spécifications se limitent aux tests fonctionnels des 25 équipements sans tester les protocoles/formats d'échanges réels tels qu'ils seront mis en oeuvre physiquement. L'invention a été développée pour offrir un nouvel outil à même d'être utilisé conjointement avec les divers procédés 2950449 -44- d'homologation, de spécification et de développement, dans le but de réduire les temps de développement et les risques techniques. On souligne encore que l'invention apporte ainsi une assurance de sécurité, de traçabilité et de maintenabilité qui 5 jusqu'à présent était inatteignable. A cette fin, l'invention utilise conjointement avec le procédé de spécification et de développement dans le but de réduire les temps de développement et les risques techniques L'invention permet de valider sur spécification ou en 10 introduisant certains équipements réels dans la boucle un système avionique complet basé sur un environnement de simulation temps réel. L'ensemble des spécifications du système avionique sont écrites dans un formalisme donné pour être mémoriser dans une 15 base de données. Ces spécifications comprennent par exemple : - les protocoles réels et complets d'échange et de communication entre les différents équipements, modules ou partitions dans le cas d'équipements répondant à la norme ARINC 20 653 - les codes sources logiciels des différents modules, partitions ou équipements en langage de haut niveau, issus par exemple de la génération de code fournie par des outils dédiés ou permettant de d'obtenir des codes simulés aux comportements 25 identiques au code embarqué - les spécifications de chaque fonction ou équipement permettant de simuler l'avionique embarquée pour fournir la même 2950449 -45- interface de programmation d'application (API embarquée simulé) que celle qui sera disponible sur le futur matériel embarqué. L'ensemble des données échangées entre les équipements et au sein de chaque équipement A653 sont représentées dans une mémoire partagée de « données électriques ». Un outil de simulation de l'aéronef permet de simuler le comportement physique réel de l'aéronef et de ces systèmes véhicules (système hydraulique, système carburant, moteur, commande de vol etc.) 10 L'ensemble de ces données sont représentées dans une mémoire partagée de « données physiques ». Des modèles senseur permettent de simuler le comportement physique de ces senseurs en réalisant la communication entre « données physiques » et « données électriques » 15 Un outil de simulation temps réel permet de simuler le comportement temps réel du système avionique ainsi défini. Cet outil permet d'intégrer dans une simulation temps réel : - un modèle aéronef 1 et ses systèmes véhicule et moteur - les modèles de capteurs (senseurs) ; 20 - les spécifications d'interfaces du système avionique 2 ; - les codes sources écrits en langage logiciel de haut niveau des différentes parties de logiciel embarqué. Les modèles qui simulent le comportement physique de l'hélicoptère et de ces systèmes génèrent toutes les variables 25 requises par la simulation. Les variables physiques sont transformées en valeur électriques par les modèles senseur pour 2950449 -46- alimenter le système avionique 2. Les valeurs électrique issues de la définition formelle et d'engineering, lorsque la définition formelle n'est pas encore mature, peuvent être mixées dans la simulation permettant une approche pas-à-pas à travers le processus de 5 spécification. Les logiciels du système avionique fournis par les spécialistes sont de préférence développés avec les outils de spécification de haut niveau par exemple pour le pilote automatique et pour les interfaces homme-machine (HMI) offrant 10 une génération de code automatique permettant d'obtenir un comportement de modèle de simulation strictement conforme aux spécifications. Tous les interfaces des équipements et partitions (typiquement ARINC653), incluant les informations détaillés tel que 15 le producteur, le taux de rafraichissement, le codage des labels ARINC429, des tables de conversion électrique des analogiques..., sont formellement décrits dans des fichiers XML (eXtensible Markup Language). L'ensemble complet des fichiers d'interface est géré par un 20 outil dédié qui est considéré comme la base de données d'interface dans où toutes les spécifications d'interface sont référencées : Pour tous les équipements, la définition de tous les signaux d'entrées/ sorties, notamment ARINC429, Discrets, Analogiques, RS422.

25 De plus, pour les équipements 9 au protocole ARINC653 on prévoit des spécifications de type : Channel, Port Apex, Partitions, Modules, Structure des données. Cette base de données est alimentée par les spécialistes des différentes fonctions et les architectes systèmes. 2950449 -47- Les IRS (Interface Requirement Specifications) sont une sortie de cette base de données pour les équipementiers. Cette base de données est transcrite dans une mémoire partagée pour l'émulation du système par l'invention. L'invention 5 analyse l'ensemble complet des fichiers d'interface XML et génère automatiquement tous les éléments de simulation requis : mémoires partagées correspondantes et strictement conformes aux données électriques ; API des système ARINC653 ; 10 - fonctions de conversion permettant d'encoder / décoder les «données électriques » notamment, et utilisés par les composants de la simulation système. Les modèles écrits en langage de haut niveau qui sont issus des générations de codes sources correspondants alimentent la 15 mémoire partagée sans aucune adaptation, par le simple appel aux API simulées elles même strictement conformes au système réel. La mémoire partagée relative aux données électrique, de part sa conformité, peut être directement mise en relation avec un bus d'interface physique permettant de d'introduire des équipements 20 réels dans la simulation. La simulation d'environnement interactif est basée sur un système d'exploitation temps réel standard. Des fonctions assurées par l'invention sont notamment la transcription de toutes les données d'interface dans la mémoire partagée de « données 25 électrique », l'intégration des logiciels écrits en langage de haut niveau dans le « programmateur » de l'environnement de simulation, et la mise à disposition des services de « monitoring » assurant le décodage à la volée (en temps réel) des grandeurs 2950449 -48- électriques et permettant ainsi la visualisation des paramètres internes de la mémoire partagée en grandeur intelligibles « d'engineering ». Sont aussi proposés des services de gestion des tâches 5 d'exécution temps réel sur les différentes unités de traitement (CPU) disponibles et des séquences chronologiques des modèles de simulation pour chacune de ces tâches, ainsi que des services d'encodage/ décodage des signaux d'échange permettant la communication pour tout modèle d'équipement conventionnel 10 Des applicatifs API pour le protocole ARINC653 permettent la communication pour tout modèle d'équipement conforme. La transcription stricte des données d'interface et l'intégration formelle des codes sources issus de génération automatique permettent de reproduire fidèlement dans l'outil de simulation le 15 comportement du système ou d'une partie de celui ci. La visualisation des paramètres systèmes est assurée de différentes façons dépendant de la phase de développement. La visualisation par décodage à la volée des paramètres internes échangés entre les différents composants de la 20 simulation, par accès direct à la mémoire partagée avec l'aide d'interfaces graphiques de l'environnement de simulation. On peut obtenir l'utilisation des formats visuels de l'interface homme-machine pendant la phase de validation de ces interfaces homme-machine.

25 L'environnement évoqué permet aussi de gérer les séquences chronologiques des nombreux modèles de simulation et propose une suite d'outils cohérents pour le test et l'investigation de chaque composant. 2950449 -49- L'ensemble des paramètres d'échanges sont simulés à leur plus bas niveau reproduisant fidèlement la spécification formelle des échanges réels. L'API conforme au protocole ARINC653 permet d'intégrer 5 directement (sans aucune intervention manuelle) les modèles correspondants aux partitions des équipements ARINC653. L'invention n'est néanmoins pas limitée aux modes de réalisation exposés. A l'inverse, elle comprend tous les équivalents des caractéristiques décrites.

Claims

REVENDICATIONS1- Procédé de simulation en temps réel d'un système avionique (2) destiné à un aéronef (1), ledit système (2) étant prévu pour posséder au moins deux équipements (9) ; au moins l'un de ces équipements (9) comprenant au moins deux partitions (10, 11), un système (12) d'exploitation (OS) avionique installé sur un calculateur et trois interfaces de communication dont une interface pour les échanges entre lesdites partitions, une autre interface pour la communication avec le système (12) d'exploitation (OS) de l'équipement et une interface de communication avec des pilotes de communication entre cet équipement (9) et le système avionique (2) ; caractérisé en ce qu'un système d'exploitation (28) de la simulation en temps réel est différent d'au moins un système (12) d'exploitation (OS) avionique installé sur un calculateur (13) d'équipement (9) ; ce procédé effectuant, pour disposer lors de la simulation de définitions complètes et consistantes desdites interfaces, au moins : une étape de translation sous forme de modèle encodé en langage de haut niveau à partir de fichiers formels en langage de marquage, desdites interfaces de communication ;et une étape de gestion dynamique des descriptions qui prévoit de regrouper, de mettre à jour et de partager une base de données incorporant pour chaque équipement, l'ensemble des signaux qui transitent par les interfaces d'entrée et / ou sortie.
2- Procédé de simulation selon la revendication 1, caractérisé en ce que pour permettre une simulation virtuelle au moins partielle, ce procédé prévoit que l'étape de translation sous 2950449 -51 - forme de modèle encodé en langage de haut niveau est opérée à partir de fichiers formels en langage de marquage, eux-mêmes issus de valeurs prédictives de définition formelle et / ou d'ingénierie. 5
3- Procédé de simulation selon la revendication 1 ou 2, caractérisé en ce que pour permettre une simulation d'au moins un constituant matériel d'équipement (9) qui traite des flux d'informations sous forme de valeurs physiques variables, ce procédé prévoit que l'étape de translation encode sous forme de 10 modèle en langage de haut niveau, le comportement physique dudit constituant matériel d'équipement (9).
4- Procédé de simulation selon l'une des revendications 1 à 3, caractérisé en ce que pour permettre une simulation d'au moins un constituant de capture d'équipement (9) qui produit des flux 15 d'informations sous forme de données d'ingénierie significatives d'un environnement du système avionique (2) à simuler, ce procédé prévoit que l'étape de translation encode lesdites données d'ingénierie dudit constituant de capture d'équipement (9) sous forme de modèle en langage de haut niveau représentatives de 20 paramètres de format de ce constituant de capture d'équipement (9).
5- Procédé de simulation selon l'une des revendications 1 à 4, caractérisé en ce que pour permettre une simulation d'au moins un constituant de déclenchement qui produit des flux d'informations 25 sous forme de données d'ingénierie destinées à agir sur le système avionique (2) à simuler, ce procédé prévoit que l'étape de translation encode lesdites données d'ingénierie dudit constituant de déclenchement sous forme de modèle en langage de haut 2950449 -52- niveau représentatives de paramètres de format de ce constituant de déclenchement.
6- Procédé de simulation selon les revendications 3 à 5, caractérisé en ce que les flux d'informations des constituants 5 matériel, de capture et de déclenchement sont de type discrets et / ou analogiques et / ou numériques notamment compatibles avec un protocole tel que ARINC429, ARINC653, MIL-STD-1553B, RS422, Ethernet.
7- Procédé de simulation selon l'une des revendications 1 à 6, 10 caractérisé en ce que l'étape de gestion des descriptions prévoit de partager dans ladite base de données des modèles de l'architecture de communication entre et / ou au sein de l'ensemble à jour des équipements du système avionique (2) à simuler.
8- Procédé de simulation selon l'une des revendications 1 à 7, 15 caractérisé en ce que l'étape de gestion des descriptions prévoit de générer des documents de spécifications de pré requis (IRS) à partager dans ladite base de données.
9- Procédé de simulation selon l'une des revendications 1 à 8, 20 caractérisé en ce que l'étape de gestion des descriptions prévoit de générer automatiquement en format neutre compatible avec une interprétation lors de la simulation virtuelle, des données descriptives des interfaces d'équipements.
10- Procédé de simulation selon l'une des revendications 1 à 25 9, 2950449 -53- caractérisé en ce que ce procédé prévoit lors de l'étape de gestion des descriptions, qu'à cette étape le partage alimente la simulation suite à une analyse automatique des descriptions d'interfaces opérée lors d'une phase de production de fichiers en code source 5 de l'étape de translation, ladite étape le partage fournissant en retour des services et fonctions significatives d'échanges au sein du système avionique, de données requises par la simulation.
11- Procédé de simulation selon l'une des revendications 1 à 10, 10 caractérisé en ce que l'étape de gestion des descriptions qui prévoit de regrouper les signaux d'interface dans la base de données, par transmission réseau, par exemple filaire (LAN, ADSL, etc.) et / ou sans fil (Wifi, WPAN, UHF, IEEE802.15.4, etc.), en amont et / ou durant la simulation, notamment lors d'une phase de 15 branchement réel et / ou virtuel d'un équipement, voire durant des tests du système avionique (2) et / ou essais de l'aéronef (1) de destination.
12- Plateforme de simulation et de mise en oeuvre du procédé selon l'une des revendications 1 à 1 1, 20 caractérisée en ce que cette plateforme possède un ordinateur personnel (PC) avec un système d'exploitation de type Linux® ; cette plateforme comportant un périphérique de branchement d'équipements réels et / ou de modèles analogiques et / ou numériques, pour la transmission de données binaires et / ou 25 discrètes ou analogiques.
13- Plateforme de simulation selon la revendication 12, caractérisée en ce que la plateforme comporte au moins un volume physique de mémoire pour l'enregistrement de données 2950449 -54- d'ingénierie encodées suivant une séquence de bit réel et désignées par « Format de Données Brutes ».
14- Système avionique (2) pour un aéronef (1) de destination ; ce système avionique (2) ayant fait l'objet d'au moins 5 une simulation conforme au procédé selon l'une des revendications 1 à 11, caractérisée en ce que ce système avionique (2) possède au moins deux équipements ; au moins l'un de ces équipements comprenant au moins deux partitions, un système d'exploitation (OS) avionique 10 installé sur un calculateur et trois interfaces de communication dont une interface pour les échanges entre lesdites partitions, une autre interface pour la communication avec le système d'exploitation (OS) de l'équipement et une interface de communication avec des pilotes de communication entre cet 15 équipement et le système avionique.
15- Système avionique (2) selon la revendication 14, caractérisé en ce qu'au moins l'un de ces équipements est compatible avec l'un des protocoles : ARINC429, ARINC653, MILSTD-1553B, RS422, Ethernet. 20
16- Aéronef (1) du type comportant au moins un système avionique (2) selon l'une des revendications 14 ou 15, caractérisé en ce que l'aéronef (1) est un aéronef (1) à voilure tournante.
17- Aéronef (1) selon la revendication 16, 25 caractérisé en ce que l'aéronef (1) à voilure tournante est un hélicoptère.
18- Aéronef (1) selon la revendication 17, 2950449 -55- caractérisé en ce que l'aéronef (1) est cet aéronef (1) est un hélicoptère hybride.
19- Aéronef (1) selon la revendication 16, caractérisé en ce que l'aéronef (1) est un avion. 5
20- Aéronef (1) selon l'une des revendications 16 à 19, caractérisé en ce que l'aéronef (1) est un drône.