Brevet FR2958427A1 — publié le 20111007

Procédé d'agencement d'un Ioqiciel d'application sur le matériel informatique d'un équipement réel ou virtuel et architecture de commande de l'équipement comprenant un tel logiciel La présente invention concerne un procédé d'agencement d'un logiciel d'application destiné à fonctionner sur le matériel informatique d'un équipement réel afin qu'il fonctionne comme un équipement au moins partiellement virtuel sur du matériel informatique standard et une architecture de commande des communications pour un matériel informatique standard comprenant un tel logiciel. Particulièrement, la présente invention concerne l'agencement d'un logiciel d'application embarqué sur un matériel informatique hôte pouvant être celui de l'équipement auquel il est destiné, l'équipement étant dit réel dans ce cas et l'agencement prenant alors la forme d'un hébergement. De plus la présente invention concerne aussi l'agencement du logiciel d'application sur un matériel informatique hôte au standard grand public, pouvant par exemple être couplé à un outil de simulation, l'autre équipement dit lato sensu virtuel étant alors dit partiellement virtuel lorsqu'il comporte des cartes d'entrées/sorties standards réelles et/ou virtuelles ou stricto sensu virtuel lorsqu'il comporte uniquement des cartes d'entrées/sorties virtuelles ayant au moins les mêmes fonctions que les cartes d'entrées/sorties réelles et l'agencement prenant alors la forme d'un ré-hébergement. Dans tout ce qui suit, les équipements ou matériels lato sensu virtuel ou stricto sensu virtuel sont regroupés sous la dénomination au moins partiellement virtuel. La présente invention avec son matériel informatique associé forme alors une architecture de commande des communications respectivement de l'équipement réel ou de l'équipement au moins partiellement virtuel. Cet agencement peut servir pour différentes étapes du cycle de vie du logiciel en fournissant un modèle représentatif du comportement de l'équipement, notamment afin de procéder à un test préliminaire à l'installation du logiciel sur l'équipement auquel il est destiné ou à un test après installation de ce logiciel sur ledit équipement, par exemple suite à une réactualisation dudit logiciel, et ce dans son environnement réel ou simulé ou encore à son intégration dans un logiciel d'application destiné à réaliser un simulateur d'environnement. Dans ce qui va suivre, il va être pris comme exemple d'application du logiciel le fonctionnement d'un équipement embarqué à bord d'un véhicule, notamment d'un aéronef. Il est à garder à l'esprit que cela n'est donné que dans un but illustratif et n'a pas un caractère limitatif sur le logiciel qui fait partie de l'architecture de commande des communications objet de la présente invention. La figure 1 montre la composition d'une architecture A de commande des communications d'un équipement destiné à être embarqué à bord d'un véhicule, avantageusement à bord d'un aéronef, cette architecture A étant réalisée selon l'état de la technique. Cette architecture A est composée d'un ensemble logiciel la et d'un ensemble matériel informatique 2a. Cet ensemble logiciel la comprend divers logiciels, à savoir un logiciel applicatif 1 b, un logiciel de gestion 3 des bus numériques et un logiciel de conversion 4 des grandeurs physiques en données brutes au format des bus numériques et/ou des entrées/sorties de type analogique et/ou discret. L'ensemble logiciel la comprend une couche logicielle d'abstraction logiciel-matériel équipementier 5, correspondant à l'ensemble matériel informatique 2a de l'équipement dans lequel l'ensemble logiciel la va être agencé. Cette couche 5 est un utilitaire logiciel qui contrôle les périphériques de l'ensemble matériel informatique 2a pour assurer la communication entre ensemble logiciel la et ensemble matériel informatique 2a. La couche logicielle d'abstraction logiciel-matériel équipementier 5 permet aux logiciels lb, 3 et 4 de l'ensemble logiciel la de fonctionner avec l'ensemble matériel informatique 2a de l'équipement pour lequel le logiciel la est principalement destiné. Ledit ensemble matériel informatique 2a présente une série de cartes d'entrées/sorties 9 avec bus numérique et/ou entrées/sorties de type analogique et/ou discret pour la mise en oeuvre de l'équipement par communication avec l'extérieur de l'architecture A de commande avec leurs pilotes 7a. La communication entre ensemble logiciel la et ensemble matériel informatique 2a s'effectue dans les deux sens selon les flèches Flm et Fml. L'ensemble matériel informatique 2a communique avec l'extérieur de l'architecture A de commande, en entrée selon la flèche FE comme en sortie selon la flèche FS. Au cours du cycle de vie de développement du logiciel, il est courant d'agencer un logiciel d'application en le ré-hébergeant sur des ensembles matériels informatiques autres que celui de son équipement auquel il est destiné, l'ensemble logiciel et son matériel informatique le ré-hébergeant formant alors une autre architecture de commande dite architecture virtuelle par opposition à une architecture réelle quand l'ensemble logiciel est avec l'ensemble matériel de son équipement destiné. Ainsi, l'ensemble logiciel la peut être agencé sur un ensemble matériel informatique 2a autre que celui de son équipement, par exemple celui d'un outil de simulation en tant qu'équipement au moins partiellement virtuel. Ceci permet d'effectuer des simulations représentatives du fonctionnement de l'équipement que l'outil de simulation reproduit. Pour des raisons de coût, il est souvent avantageux que cet outil de simulation accueillant l'équipement au moins partiellement virtuel soit composé d'éléments électroniques d'un standard courant et économique. Ainsi, il est d'une grande importance que cet agencement prenant alors la forme d'un ré- hébergement se fasse rapidement, sans difficulté et soit opéré avec fiabilité tout en étant avantageusement peu coûteux. Le document US 5 551 015 décrit un procédé et un dispositif pour la conversion directe d'un programme dans un code objet fonctionnant sur un équipement dédié dans différents autres équipements munis de leur architecture propre. Pour ces autres équipements, il s'agit de simuler complètement le fonctionnement de l'équipement de destination principale, de manière à faire fonctionner le programme sous sa forme objet, donc sans recompilation. Le document US 6 654 950 décrit un système d'agencement de logiciel. Dans ce document, il s'agit de convertir un code d'un premier langage dans un autre langage de base pouvant être celui d'un outil de simulation. Les procédé et système décrits dans ces documents impliquent des temps de tests longs du fait que les cycles de modification, de test unitaire sur la plateforme de développement, de génération du code embarqué, de chargement dans le calculateur cible, de test sur banc d'intégration peuvent être très longs. Cela augmente le coût de la mise au point lors de l'intégration du logiciel dans l'équipement cible, en provoquant notamment une longue immobilisation du banc de test, une immobilisation de coûteux équipements réels, un coût élevé des simulateurs de plateforme, notamment pour le document US 5 551 015, une indisponibilité des équipements réels et une difficulté d'avoir les équipements dans leur version logicielle de référence, de même que les simulateurs de formation. La simulation d'un équipement, qui cumule des fonctions de commande de l'équipement et une fonction contrôleur de bus, ne peut se faire en utilisant une couche de communication qui se contente d'échanger des données en mémoire partagée. Le problème de la présente invention est de permettre l'agencement d'un logiciel d'application aussi bien sur le matériel informatique de l'équipement auquel il est destiné que sur un équipement autre, cet agencement s'effectuant de manière simple et efficace tout en garantissant une communication sûre et rapide dudit logiciel avec le matériel informatique de l'équipement respectif. A cet effet, l'invention a pour objet un procédé d'agencement d'un ensemble logiciel destiné à un équipement indifféremment soit sur un ensemble matériel informatique dudit équipement, l'équipement et son matériel informatique étant alors dits réels, ou soit sur un ensemble matériel informatique d'un autre équipement, l'autre équipement et son matériel informatique étant alors dits au moins partiellement virtuel, ledit matériel informatique au moins partiellement virtuel étant stricto sensu virtuel lorsqu'il gère des cartes d'entrées/sorties virtuelles et étant lato sensu virtuel lorsqu'il gère, soit des cartes d'entrées/sorties réelles, soit une association de cartes d'entrées/sorties réelles et virtuelles, caractérisé en ce qu'il comprend les étapes suivantes : - une étape de développement dans l'ensemble logiciel d'une couche logicielle d'abstraction logiciel-matériel normalisée, la couche logicielle d'abstraction logiciel-matériel normalisée étant composée d'une bibliothèque de primitives s'interfaçant, d'une part, avec les codes sources de l'ensemble logiciel et, d'autre part, avec l'ensemble matériel informatique réel ou au moins partiellement virtuel, - une étape de développement d'une couche logicielle matériel réel par ensemble matériel informatique réel ou d'une couche logicielle matériel informatique virtuel par ensemble matériel informatique au moins partiellement virtuel, chaque couche logicielle matériel réel ou virtuel d'un ensemble matériel étant apte à communiquer avec la couche logicielle d'abstraction logiciel-matériel normalisée, chaque couche logicielle matériel réel coopérant avec des cartes d'entrées/sorties réelles et chaque couche logicielle matériel virtuel coopérant avec des cartes d'entrées/sorties réelles et/ou virtuelles. Selon des caractéristiques additionnelles de la présente invention : - le procédé consiste en un hébergement de l'ensemble logiciel sur l'ensemble matériel réel de l'équipement réel ou en un ré-hébergement de l'ensemble logiciel sur l'ensemble matériel au moins partiellement virtuel, - le procédé comprend une étape de développement d'une couche logicielle de communication réalisant et gérant les échanges entre lesdites cartes d'entrées/sorties virtuelles, quand celles-ci sont présentes, lesdites cartes pouvant faire partie d'un équipement ou d'un groupe d'équipements au moins partiellement virtuel d'un outil de test ou de simulation, - le procédé comprend la connexion d'un logiciel de perturbation à la couche logicielle matériel virtuel délivrant des indications de perturbations physiques susceptibles d'être rencontrées sur les supports de transmission réels et véhiculés par la couche logicielle de communication, - le procédé comprend une étape de test de la couche logicielle matériel virtuel comprenant les pilotes des cartes d'entrées/sorties réelles et/ou virtuelles et de la couche logicielle de communication en couplant l'ensemble logiciel fonctionnant sur un ensemble matériel informatique au moins partiellement virtuel standard couplé à au moins un outil de simulation en tant qu'équipement au moins partiellement virtuel, - la couche logicielle d'abstraction logiciel-matériel normalisée présente une structure logicielle commune pour être associée indifféremment avec l'ensemble matériel informatique réel ou au moins partiellement virtuel, - le développement de la couche logicielle d'abstraction logiciel-matériel normalisée dans l'ensemble logiciel comprend une étape de récupération des codes sources des programmes d'application de l'ensemble logiciel à agencer, une étape d'adaptation des codes sources applicatifs au compilateur de l'ensemble matériel informatique réel ou au moins partiellement virtuel et une étape de compilation et d'édition des liens dudit ensemble logiciel et de ladite couche logicielle d'abstraction logiciel-matériel normalisée, - le procédé comprend une étape de test de l'ensemble logiciel de l'équipement sur un ensemble matériel informatique au moins partiellement virtuel standard couplé au moins à un outil de test en tant qu'équipement au moins partiellement virtuel, - le procédé comprend l'intégration ou le couplage direct des cartes d'entrées/sorties réelles et/ou virtuelles à la couche logicielle d'abstraction matérielle par l'intermédiaire de la couche logicielle matériel réel ou de la couche logicielle matériel virtuel, - la communication entre ensemble logiciel et ensemble matériel informatique réel ou au moins partiellement virtuel s'effectue suivant un protocole de communication normalisé. L'invention concerne aussi une architecture réelle ou virtuelle de commande avec un ensemble logiciel et un ensemble matériel informatique respectivement réel ou au moins partiellement virtuel, cette architecture réelle ou virtuelle étant respectivement attribuée au fonctionnement d'un équipement auquel elle est destinée dit équipement réel ou d'un équipement autre que cet équipement réel, l'équipement autre étant dit équipement au moins partiellement virtuel, ledit ensemble matériel informatique réel ou au moins partiellement virtuel recevant ledit ensemble logiciel et étant spécifique à l'équipement réel ou virtuel en gérant ledit équipement par l'intermédiaire de cartes d'entrées/sorties réelles avec bus numériques pour le fonctionnement de l'équipement réel ou de cartes d'entrées/sorties réelles et/ou virtuelles pour l'équipement au moins partiellement virtuel, caractérisée en ce qu'elle comprend : - une couche logicielle d'abstraction matériel normalisée, composée d'une bibliothèque de primitives s'interfaçant, d'une part, avec les codes sources de l'ensemble logiciel et, d'autre part, avec l'ensemble matériel informatique réel ou au moins partiellement virtuel, - une couche logicielle matériel réel ou une couche logicielle matériel virtuel respectivement dans l'ensemble matériel informatique réel ou l'ensemble matériel informatique au moins partiellement virtuel, ladite couche logicielle matériel réel ou matériel virtuel formant la partie de l'ensemble matériel informatique réel ou au moins partiellement virtuel s'interfaçant avec la couche logicielle d'abstraction logiciel-matériel normalisée, la couche logicielle matériel réel effectuant respectivement la gérance des cartes d'entrées/sorties réelles avec des bus numériques de l'ensemble matériel informatique réel de l'équipement réel, la couche logicielle matériel virtuel effectuant la gérance des cartes d'entrées/sorties réelles et/ou virtuelles avec des bus numériques de type analogique et/ou de type discret de l'ensemble matériel informatique au moins partiellement virtuel, lesdites cartes virtuelles assurant au moins les mêmes fonctions que les cartes d'entrées/sorties réelles et leurs pilotes associés de l'ensemble matériel informatique réel. Avantageusement, pour une architecture virtuelle destinée pour au moins un outil de simulation en tant qu'équipement au moins partiellement virtuel, son ensemble matériel informatique au moins partiellement virtuel est d'un standard courant et économique, du type PC unitaire ou d'au moins deux PC connectés ensemble, les cartes d'entrées/sorties virtuelles avec leurs pilotes étant, lorsqu'elles sont présentes, intégrées dans ou couplées avec la couche logicielle matériel virtuel, la gérance des cartes d'entrées/sorties virtuelles s'effectuant à travers un réseau de standard économique et courant du type réseau Ethernet ou réseau de signaux analogiques et discrets. Avantageusement, l'architecture virtuelle comprend uniquement des cartes d'entrées/sorties réelles. Avantageusement, l'architecture virtuelle comprend uniquement des cartes d'entrées/sorties virtuelles, une couche logicielle de communication effectuant la réalisation et la gestion des échanges entre les cartes d'entrées/sorties virtuelles. Avantageusement, l'architecture virtuelle comprend une combinaison de cartes d'entrées/sorties réelles et de cartes d'entrées/sorties virtuelles, une couche logicielle de communication effectuant la réalisation et la gestion des échanges entre les cartes d'entrées/sorties virtuelles. L'invention concerne aussi un équipement réel ou au moins partiellement virtuel caractérisé en ce qu'il comprend respectivement une telle architecture réelle ou virtuelle. L'invention concerne aussi un groupe composé de tels équipements réels ou au moins partiellement virtuels caractérisé en ce que les équipements réels ou au moins partiellement virtuels présentent, dans leur ensemble logiciel, une couche logicielle d'abstraction logiciel-matériel normalisée de structure logicielle similaire. Avantageusement, au moins une partie des ensembles matériel informatique réels ou au moins partiellement virtuels sont connectés les uns aux autres, ladite partie formant un équipement réel ou au moins partiellement virtuel combinant les fonctions des équipements réels ou au moins partiellement virtuels le composant. L'invention concerne enfin un véhicule, caractérisé en ce qu'il comprend en son bord un tel équipement réel ou un tel groupe d'équipements réels. Avantageusement, le véhicule est un aéronef. L'effet technique est obtenu essentiellement par le remplacement dans l'architecture de commande des communications de l'équipement de la couche logicielle d'abstraction logiciel-matériel équipementier déjà connue par une couche logicielle d'abstraction logiciel-matériel normalisée. Cette couche peut coopérer indifféremment avec soit une couche logicielle matériel réel, dans le cas où l'ensemble matériel informatique associé est celui correspondant à l'architecture de commande des communications de l'équipement ou une couche matériel virtuel, dans le cas où l'ensemble matériel informatique est celui correspondant à l'architecture de commande des communications d'un outil de simulation dudit équipement. La couche logicielle d'abstraction normalisée et la couche logicielle matériel réel ou virtuel sont intercalées entre ensemble logiciel et ensemble matériel informatique dudit équipement. De plus, avantageusement, l'ajout d'une couche logicielle de communication permet la simulation de l'ensemble logiciel à un stade de développement le plus amont possible et le plus économique possible. L'effet technique obtenu est, tout en respectant la conception d'origine de l'ensemble logiciel, de faciliter grandement l'agencement de l'ensemble logiciel sur l'ensemble matériel réel de l'équipement embarqué en vue de son fonctionnement usuel ou sur un ensemble matériel informatique au moins partiellement virtuel d'un outil de simulation en vue d'essais de simulation dudit équipement. L'invention va maintenant être décrite plus en détail mais de façon non limitative en regard des figures annexées, dans lesquelles : - la figure 1 est un schéma d'une architecture de 30 commande des communications d'un équipement avec ses ensembles logiciel et matériel informatique selon l'état de la technique, - la figure 2 est un schéma d'une architecture dite réelle de commande des communications d'un équipement avec ses ensembles logiciel et matériel informatique selon la présente invention, - la figure 3 est un schéma d'une architecture virtuelle de commande des communications d'un équipement lato sensu virtuel, notamment sous la forme d'un outil de simulation, avec ses ensembles logiciel et matériel informatique selon la présente invention, - la figure 3a est un schéma d'une architecture virtuelle de commande des communications d'un équipement stricto sensu virtuel, notamment sous la forme d'un outil de simulation, avec ses ensembles logiciel et matériel informatique selon la présente invention, - la figure 3b est un schéma d'une architecture virtuelle de commande mixte des communications d'un équipement dit lato sensu virtuel, notamment sous la forme d'un outil de simulation, avec ses ensembles logiciel et matériel informatique selon la présente invention, - la figure 4 montre un plan d'un procédé général de conception et de développement d'un logiciel d'un équipement destiné à être embarqué à bord d'un véhicule, les étapes de ce procédé étant montrées disposées en V, - la figure 5 est un schéma d'un groupe de plusieurs architectures de commande des communications selon la présente invention connectées entre elles en formant un outil de test ou un outil de simulation à architectures de commande multiples. La figure 1 a déjà été détaillée dans la partie introductive de la description de la présente demande. La figure 2 détaille la composition d'une architecture Ar de commande dite réelle, réalisée selon la présente invention, d'un équipement pour lequel le logiciel est principalement dédié, cet équipement étant destiné à être embarqué à bord d'un véhicule, avantageusement un aéronef. Cet équipement de destination première sera dénommé ci-après réel. A cette figure, dans l'ensemble logiciel 1, le logiciel applicatif lb, le logiciel de gestion 3 des bus numériques et le logiciel de conversion 4 des grandeurs physiques en données brutes restent inchangés par rapport à la figure 1. Dans ce qui suit, l'ensemble matériel informatique 2 spécifique d'une architecture réelle Ar sera dénommé ensemble matériel informatique réel 2. La couche logicielle d'abstraction logiciel-matériel équipementier 5 de la figure 1 est remplacée par une couche logicielle d'abstraction logiciel-matériel normalisée 6 présentant une interface logiciel-matériel pouvant être similaire pour toutes les architectures de commande présentant des ensembles matériel informatique différents susceptibles de travailler avec cet ensemble logiciel 1, quand cet ensemble logiciel 1 est agencé sur ces architectures. Par exemple l'ensemble matériel informatique peut être destiné à la commande de l'équipement réel ou d'au moins un équipement autre, dénommé ci-après équipement au moins partiellement virtuel et plus amplement décrit aux figures 3, 3a, 3b. La couche logicielle d'abstraction logiciel-matériel normalisée 6 dépend de l'équipementier et retransmet les services attendus par le logiciel applicatif lb vers le système d'exploitation de l'ensemble matériel informatique réel 2. Ceci est réalisé en interfaçant la couche logicielle d'abstraction logiciel-matériel normalisée 6 avec une couche logicielle de communication de l'ensemble matériel informatique réel 2, dénommée ci-après couche logicielle matériel réel et référencée 7 à la figure 2. La couche logicielle d'abstraction logiciel-matériel normalisée 6 peut différer suivant les équipementiers mais offre à toutes les applications embarquées qui ont été soit développées par le fabricant du véhicule ou soit fournies par les équipementiers dudit fabricant une même interface pour au moins les différentes versions du même équipement, ces versions comprenant différentes variantes de l'équipement réel ou des outils de simulation de cet équipement en tant qu'équipements virtuels. Cette couche logicielle d'abstraction logiciel-matériel normalisée 6 est donc compatible avec les différentes versions du même équipement, ces versions pouvant être réelles ou virtuelles. En variante, il serait judicieux de standardiser une couche logicielle d'abstraction logiciel-matériel normalisée 6 à tous les fabricants d'équipements à embarquer sur un même véhicule ou sur des véhicules similaires, de manière à faciliter l'agencement de l'ensemble logiciel dans une architecture de commande donnée afin de minimiser la partie logicielle à adapter de ladite couche logicielle d'abstraction logiciel-matériel normalisée 6 lors de cet agencement. La couche logicielle matériel réel 7, disposée du côté ensemble matériel réel 2, fournit à la couche logicielle d'abstraction logiciel-matériel normalisée 6 des services lui permettant de faire circuler les informations sur des bus numériques et/ou sur des entrées/sorties de type analogique et/ou discret au travers de cartes d'entrées/sorties dites réelles 9, incluses dans l'ensemble matériel informatique réel 2 de l'architecture réelle Ar dans laquelle l'ensemble logiciel 1 est agencé, auquel cas cet agencement représente un hébergement. En prenant le cas d'un équipement réel embarqué sur un aéronef, il existe plusieurs types de bus numériques de communication spécialisés pour l'aéronautique et représentant des éléments d'un standard sophistiqué et de coût relativement élevé, par exemple Mil-STD-1553, Arinc 429 et Arinc 653, RS485 ou EIA-485 etc.... De même, il existe un grand nombre de signaux circulant sous format analogique (tension, courant, fréquence) ou discrètes etc... Les pilotes des cartes d'entrées/sorties réelles 9, constituent la couche logicielle matériel réel 7, en étant intégrées ou couplées à ladite couche 7. Ainsi, ladite couche 7, en plus de s'interfacer avec la couche logicielle d'abstraction logiciel-matériel normalisée 6, effectue la gérance des cartes d'entrées/sorties 9, ces cartes ayant été, dans l'état de la technique, procédées directement par l'ensemble matériel informatique 2a montré à la figure 1. Les figures 3, 3a, 3b montrent une architecture de commande respective des communications d'un équipement autre que l'équipement réel auquel elle est destinée, cet équipement autre étant dénommé équipement au moins partiellement virtuel comme précédemment mentionné. La figure 3 montre une architecture Apv de commande des communications d'un équipement partiellement virtuel avec une couche logicielle matériel virtuel 10 comprenant uniquement des cartes d'entrées/sorties réelles 9a avec leur pilote associé, ceci pour un ensemble matériel informatique au moins partiellement virtuel 2b, cet équipement étant dénommé lato sensu virtuel. II est à signaler que les cartes d'entrées/sorties réelles 9a d'un tel équipement au moins partiellement virtuel peuvent être sensiblement différentes que les cartes d'entrées/sorties réelles 9 montrées à la figure 2 pour un équipement réel. En effet, ces cartes 9a peuvent présenter d'autres fonctionnalités que celle de commande de l'équipement. Par exemple, ces cartes réelles 9a peuvent comprendre un logiciel de perturbation, logiciel qui sera détaillé ultérieurement et qui est représenté sous la référence 8 aux figures 3, 3a et 3b en étant non intégré aux cartes réelles 9a quand celles-ci sont présentes. La figure 3a montre une architecture Av de commande des communications d'un équipement entièrement virtuel, cet équipement étant alors dénommé stricto sensu virtuel. Cette architecture Av comprend une couche logicielle matériel virtuel 10 comprenant les pilotes des cartes d'entrées/sorties virtuelles 9b, ceci pour un ensemble matériel informatique virtuel 2b. La figure 3b montre une architecture Avm de commande des communications d'un équipement partiellement virtuel, cet équipement étant dénommé lato sensu virtuel. Cette architecture Avm comprend une couche logicielle matériel virtuel 10 comprenant les pilotes des cartes d'entrées/sorties réelles 9a et virtuelles 9b, ceci pour un ensemble matériel informatique au moins partiellement virtuel 2b. En ce qui concerne les figures 3 et 3b, les cartes d'entrées/sorties réelles 9a d'un tel équipement au moins partiellement virtuel montrées à ces figures 3 peuvent sensiblement différer des cartes d'entrées/sorties réelles 9 montrées à la figure 2. Par exemple et sans que cela soit limitatif, ces cartes d'entrées/sorties réelles 9a peuvent comporter d'autres fonctionnalités que les cartes uniquement prévues pour la commande de l'équipement, notamment en incorporant un logiciel de perturbation, ce logiciel étant montré aux figures 3 et 3b non incorporé aux cartes d'entrées/sorties réelles 9a sous la référence 8. De telles cartes d'entrées/sorties réelles pour équipement au moins partiellement virtuel sont en général dénommées cartes standard. Pour les architectures Av, Avm de commande des communications respectivement montrées aux figures 3a et 3b, il est prévu dans l'ensemble matériel informatique 2b une couche logicielle de communication 11 réalisant et gérant les échanges entre les cartes d'entrées/sorties virtuelles 9b, lesdites cartes 9b pouvant faire partie d'un équipement ou d'un groupe d'équipements virtuels d'un outil de test ou de simulation. Pour toutes les figures 3, 3a et 3b, l'architecture correspondant à l'équipement au moins partiellement virtuel est dite, par opposition à l'architecture réelle Ar de commande de l'équipement réel, architecture virtuelle Apv, Av ou Avm. Cette architecture virtuelle Apv, Av ou Avm est composée d'un ensemble logiciel 1 et d'un ensemble matériel informatique autre que celui pour lequel cet ensemble logiciel 1 est destiné, dénommé ci-après par extension ensemble matériel informatique au moins partiellement virtuel 2b. L'agencement prenant la forme d'un ré-hébergement de l'ensemble logiciel 1 dans un ensemble matériel informatique au moins partiellement virtuel 2b d'une architecture virtuelle est réalisé pour entreprendre des tests de simulation sur les logiciels, ces tests prenant place dans certaines étapes du procédé de conception et de développement d'un ensemble logiciel qui seront décrites ultérieurement au regard de la figure 4, l'équipement au moins partiellement virtuel ainsi obtenu s'exécutant alors sous le contrôle d'un outil de simulation. Contrairement à l'hébergement en tant qu'agencement de l'ensemble logiciel dans l'ensemble matériel de l'architecture réelle de commande de l'équipement réel montré à la figure 2, cet ensemble matériel réel étant spécialisé audit équipement réel et de coût relativement élevé, le ré-hébergement en tant qu'agencement de l'ensemble logiciel dans une telle architecture virtuelle de commande des communications d'un équipement au moins partiellement virtuel, par exemple un outil de simulation, peut se faire sur un ensemble matériel informatique au moins partiellement virtuel 2b d'un standard courant, c'est-à-dire composé d'éléments facilement disponibles dans le commerce qui sont regroupés sous l'appellation générale de COTS (commercial off-the-shelf selon un acronyme anglais), par exemple un PC pouvant être sous la forme d'un portable ou au moins deux PC connectés entre eux, ce ou ces PC étant équipés de cartes d'entrées/sorties réelles et/ou virtuelles dans le cas d'une architecture de commande des communications d'un équipement au moins partiellement virtuel. Cela permet de tester et mettre au point le code source sur appareil de la façon dont le ferait un émulateur en phase d'intégration sur porteur de destination ou sur un simulateur de vol donc sans avoir à simuler spécifiquement l'environnement. Dans le cas d'architectures Apv et Avm d'un équipement partiellement virtuel telles que montrées respectivement aux figures 3 et 3b, celles-ci comprennent des cartes d'entrées/sorties réelles 9a standards et leurs pilotes intégrés dans la couche logicielle matériel virtuel 10 de façon similaire à l'architecture de commande des communications d'un équipement réel donné à la figure 2. Cela permet de tester et mettre au point le code source sur appareil de la façon dont le ferait un émulateur en phase d'intégration sur porteur de destination, donc sans avoir à simuler l'environnement. En référence aux figures 3a et 3b, au sein de la couche logicielle de communication 11, les échanges peuvent s'effectuer par l'intermédiaire d'un élément logiciel formant une prise, sous l'appellation anglaise de socket, cet élément constituant une interface logicielle avec le système d'exploitation de l'ensemble matériel informatique au moins partiellement virtuel 2b, ladite interface facilitant l'exploitation d'un service d'un protocole réseau. De tels échanges peuvent aussi se faire par un Service de Distribution de Données, en anglais DDS (Data Distribution Service). Cela permet de faire fonctionner les différents ensembles logiciels agencés en suivant une recompilation et une édition de lien avec la bibliothèque de la couche logicielle-matériel normalisée 6 sur un même PC ou sur un groupe de PC connectés ensemble. Une architecture virtuelle Av d'un équipement stricto sensu virtuel, selon la figure 3a, permet aussi de faire tourner des tests de non régression à une vitesse qui dépend de la puissance du PC hôte, de simuler des pannes sur le réseau virtuel, par exemple des non réponses, des erreurs Manchester, des erreurs de parité, etc d'évaluer les charges bus et de combiner des environnements simulés et réels. Dans le cas d'une architecture virtuelle Apv, Av ou Avm, montrée respectivement aux figures 3, 3a et 3b, il est procédé au remplacement de la couche logicielle matériel réel 7 par une couche logicielle matérielle virtuel 10 associée à des cartes rélles 9a standards comme montré à la figure 3 ou à des cartes d'entrées/sorties virtuelles 9b combinées ou non avec des cartes rélles standards comme montré aux figures 3a et 3b, ces cartes présentant alors leurs pilotes intégrés à ladite couche10, Comme montré aux figures 3a et 3b, il peut être prévu une couche logicielle de communication de l'ensemble matériel informatique au moins partiellement virtuel 2b de cette architecture virtuelle Av ou Avm, cette couche étant dénommée ci-après couche logicielle de communication virtuelle 11 et coopérant avec les cartes d'entrées/sorties virtuelles 9b. Dans le cas d'une architecture stricto sensu virtuelle ladite couche 10, comme montré à la figure 3a, cette architecture Av associée à des cartes virtuelles 9b fournit au moins les mêmes services que la couche logicielle matériel réel 7 et les cartes d'entrées/sorties réelles mais au travers de cartes d'entrées/sorties virtuelles 9b qui remplacent les cartes réelles référencées 9 à la figure 2, lesdites cartes virtuelles 9b étant couplées ou intégrées à ladite couche 10. La couche logicielle matériel virtuel 10 est modulable. Cette couche 10 peut simuler sous une forme virtuelle tous ou en partie les bus suivants: Arinc 429 ou 653, Mil STD 1553B, RS232/422/485. Selon la figure 3a, la couche de communication logicielle 11 peut comprendre un réseau Ethernet ou un réseau de signaux analogiques et discrets, c'est-à-dire un moyen de communication à relativement bas coût. De ce fait, les échanges de l'architecture virtuelle Av, au lieu de se faire sur un coûteux bus numérique, se font sur un réseau classique, par exemple un réseau Ethernet sans adjonction de matériels supplémentaires. Il est aussi possible de regrouper des architectures réelles ou virtuelles afin de former un groupe d'architectures commandant un outil de test comme il sera vu à la figure 5. En se référant aux figures 2, 3, 3a et 3b, pour agencer un ensemble logiciel 1 dans l'ensemble matériel informatique réel ou virtuel 2 ou 2b spécifique de l'architecture réelle Ar ou virtuelle Av, Avm ou Apv, il suffit d'adapter l'ensemble logiciel 1 audit ensemble matériel informatique réel 2 ou au moins partiellement virtuel 2b et notamment à son système d'exploitation, fonctionnant par exemple sous Linux, ainsi qu'à ses compilateurs. Cette action répétitive peut s'automatiser ou en alternative le code source de l'ensemble logiciel 1 peut être adapté pour faciliter cet agencement. Ensuite, il suffit de réaliser le couplage entre la couche logicielle d'abstraction logiciel-matériel normalisée 6 et respectivement la couche logicielle matériel réel 7 ou couche logicielle matériel virtuel 10. Les interfaces des couches logicielles matériel réel 7 et virtuel 10 sont strictement identiques en ce qui concerne leur partie logicielle ou tout autre programme susceptible de s'y connecter. Ainsi, pour utiliser un modèle agencé en mode réel ou virtuel, il suffit de le coupler de manière dynamique à la bonne bibliothèque de l'ensemble logiciel 1. Cela ne nécessite aucune manipulation sur le code du modèle. En référence aux figures 3, 3a et 3b, comme précédemment mentionné, la couche logicielle matériel virtuel 10 peut-être reliée à un logiciel de perturbation 8 qui peut être extérieur à l'ensemble matériel informatique au moins partiellement virtuel 2b et exécuter en plus les services de perturbation proposés par ledit logiciel 8. La couche logicielle matériel virtuel 10 permet de pouvoir 30 tester le logiciel avec des bus numériques réels avant même que l'équipement réel soit disponible et de pouvoir tester le logiciel d'application dans le même environnement que l'équipement réel d'où une similarité de définition des tests. Le système d'exploitation de l'ensemble matériel informatique standard 2b d'une architecture virtuelle peut, de préférence, fonctionner sous OS LINUX mais il est aussi possible d'utiliser un autre système d'exploitation. La couche logicielle matériel virtuel 10 permet, en outre, d'utiliser la même interface, c'est à dire le même outil de simulation en tant qu'équipement au moins partiellement virtuel, afin de tester des systèmes entièrement agencés sous forme de ré-hébergements et d'utiliser les mêmes cartes pour tous les outils fonctionnant sous le même système d'exploitation par exemple Linux/Unix (U-TEST®). La figure 4 montre un plan d'un procédé général de conception et de développement d'un ensemble logiciel pour un équipement réel destiné à être embarqué à bord d'un véhicule afin d'assurer le fonctionnement dudit équipement réel dans le véhicule, les étapes de ce procédé étant montrées disposées en forme de V et le véhicule étant un aéronef. La première étape de conception et de développement du logiciel est constituée par des simulations d'étude indiquée par la référence Set, montrée à la partie supérieure d'une des branches du V. Pendant cette étape, avant le démarrage du processus de conception et de développement, il est procédé à de tests exploratoires et des évaluations des futures interfaces homme/machines par l'élaboration de modèles d'équipement qui sont aujourd'hui rarement réutilisés à un stade ultérieur du procédé. Les étapes suivantes concernent la spécification Spe, la conception Con et la réalisation Rea du logiciel. A chacune de ces étapes, les techniques actuelles permettent de réaliser une maquette numérique de l'ensemble logiciel. L'invention permet d'y ajouter des modèles représentatifs de la communication entre ensembles logiciels et équipements réels auquel le logiciel est principalement destiné, ce qui permet, en utilisant les mêmes outils de test et de développement, de mettre au point un système complet au plus tôt, en mode itératif, y compris les composants gérant le réseau de bord. L'étape suivante est une étape de tests unitaires Tun servant à la vérification du logiciel avec, entre autres, un test des échanges de données avec le reste du système. Le but de ces tests unitaires est de vérifier que les traitements ou la gestion des bus numériques effectués par l'équipement le cas échéant sont conformes aux exigences de conception. L'invention permettant la connexion d'un équipement au moins partiellement virtuel sur un banc d'intégration ou directement sur un véhicule, permet de réaliser des tests unitaires sans que les temps de génération et de chargement du logiciel embarqué ne constituent un obstacle lors de cette étape de test unitaire Tun. L'invention permet de procéder à des tests unitaires en mode de mise au point, regroupés sous l'appellation mode débogage, ceci dans un environnement réel, par exemple sur un banc d'intégration. Les étapes suivantes sont sur la seconde branche du V en partant de sa base et commencent par l'étape de qualification Qua. Lors de cette étape, avec le logiciel agencé dans un calculateur différent du calculateur de l'équipement réel auquel il est destiné, il est procédé à la mise au point et à la vérification de la couverture des tests de qualification. Dans ce cas, l'équipement au moins partiellement virtuel possède des cartes d'entrées/sorties standards représentatives de l'équipement réel. L'utilisation d'un matériel informatique de standard courant, par exemple un PC permet de passer l'étape du procédé de qualification afin de vérifier le taux de couverture de ces tests, voire, en tout simulé, de vérifier hors banc et à vitesse accélérée, le taux de couverture des tests de qualification. La validation de ces tests peut se faire sans l'immobilisation coûteuse d'une plateforme banc et il peut être même possible d'interfacer une fonction à un banc d'intégration avant même que l'équipement réel soit physiquement disponible. L'étape suivante est l'étape d'intégration Int, pour laquelle il est utilisé le même outil de test que sur le banc d'essai logiciel pour passer les tests pendant la phase de développement. A ce stade, il peut aussi être procédé à la mise au point en mode débogage de la communication avec le logiciel de l'équipement réel en développement, en utilisant par exemple un ensemble matériel informatique de standard courant faisant office d'ensemble matériel informatique au moins partiellement virtuel. L'étape suivante est l'étape de test de production Tpr. II est procédé à la mise au point, hors site de production, des procédures de tests séries, sur un système entièrement simulé, représentatif de l'équipement réel du véhicule cible, par exemple de l'avionique cible dans le cas d'un aéronef. Cette étape de test de production Tpr est suivie d'une étape d'essais Ess, par exemple d'essais sol et vol pour un équipement réel embarqué dans un aéronef. Cette étape d'essais Ess permet la mise au point et l'intégration sur les premiers porteurs. A la fin de ces étapes du procédé général de conception et de développement d'un logiciel d'application pour un équipement réel destiné à être embarqué à bord d'un véhicule, une fois l'étape Ess finalisée, il peut être procédé à l'élaboration d'un simulateur d'entraînement lors d'une étape Sen, étape qui ne fait pas à proprement partie du procédé de conception et de développement précédemment mentionné. A ce stade, le ré-hébergement conformément à l'invention du logiciel réel des équipements constituant le système embarqué, permet de le simuler de façon réaliste en utilisant la version la plus à jour du logiciel embarqué. Après l'étape de procédé de test de production Tpr, il peut aussi être élaboré un support client Sup lors de l'étape référencée Sup. Ce support client Sup permet de mettre au point les outils de maintenance et de former le personnel du client avant la mise en service d'un nouveau système. Dans le cas d'un changement d'équipement réel, notamment du fait d'un changement de fournisseur ou d'une réactualisation de l'ensemble logiciel, il est utile de procéder selon les étapes suivantes : - récupération des codes sources des programmes d'application de l'ensemble logiciel à ré-héberger, - adaptation des codes sources applicatifs au compilateur d'un ensemble matériel informatique standard, - compilation et édition de liens entre logiciel source d'application et la couche logicielle d'abstraction matérielle normalisée, - test de l'ensemble logiciel sur ledit ensemble matériel informatique équipé de cartes d'entrées/sorties standards réelles, - avantageusement, un développement de la couche logicielle matériel virtuel apte à être équipée de cartes d'entrées/sorties virtuelles à la place du matériel informatique hôte de test, avantageusement de standard courant. L'avant dernière étape précédemment mentionnée peut soit être le but de l'agencement dans le cas d'une mise au point de l'ensemble logiciel dans un environnement réel et, dans ce cas, la dernière étape précédemment mentionnée est superflue, soit une étape à la première validation de la couche logicielle d'abstraction logiciel-matériel normalisée par le passage des tests de qualification sur un ensemble logiciel agencé prenant la forme d'un ré-hébergement. Il est à noter que dans ce procédé, du fait de l'utilisation d'une couche logicielle d'abstraction logiciel-matériel normalisée 6 avec soit une couche logicielle matériel réel 7 ou une couche logicielle matériel virtuel 10, comme montré aux figures 2 ou 3, 3a, 3b, il n'est pas nécessaire de convertir un code source écrit dans un langage en un autre langage, ni de traduire un code objet sur une autre plateforme, ni de créer une plateforme matérielle virtuelle s'interfaçant avec les ensembles logiciel et matériel mais de créer une nouvelle architecture d'application pour ré-héberger les logiciels d'application sur un ensemble matériel, avantageusement d'un standard courant. Ainsi, lors d'une réactualisation de l'ensemble logiciel, l'interface entre les couches selon la présente invention permet la récupération de la dernière version de l'ensemble logiciel embarqué par son simple agencement prenant la forme d'un ré- hébergement et, éventuellement, la réalisation d'une simulation représentative de cette dernière version. Lors d'une simulation, il peut être utilisé le même outil de test que pour le banc de l'étape d'intégration. Ceci est obtenu en remplaçant les cartes de test réelles par les cartes virtuelles simulées par la couche logicielle matériel virtuel, l'outil de test s'interfaçant alors sur les bus virtuels au lieu des bus réels. Dans le cas d'un changement des applications ou des cartes d'entrées/sorties, il est utile de procéder selon les étapes suivantes : - une étape de test de la couche logicielle matériel virtuel en la liant à un outil de test, - une étape de compilation et d'édition de lien dudit ensemble logiciel avec ladite couche logicielle d'abstraction logiciel-matériel normalisée et ladite couche logicielle matériel virtuel pour exécution sur l'ensemble matériel informatique au moins partiellement virtuel sans cartes entrées/sorties. Différentes options sont possibles: un couplage d'équipements réels ou un couplage d'équipements virtuels et, éventuellement, un couplage d'équipements réels et virtuels. Comme il a été précédemment mentionné en regard de la figure 3a, la couche logicielle matériel virtuel 10 peut avantageusement être associée à une couche logicielle de communication 11 d'un réseau Ethernet. Cependant, il est aussi possible d'utiliser toute couche de communication standardisée qu'elle s'appuie directement sur une interface de communication physique, par exemple un bus IEEE 1394, autrement connu sous le nom de firewire mis au point afin de fournir un système d'interconnexion permettant de faire circuler des données à haute vitesse en temps réel, ou même qu'elle s'appuie sur une couche logicielle, par exemple un logiciel de Service de Distribution de Données aussi connu sous l'abréviation DDS. En se référant aux figures 2, 3, 3a et 3b, l'utilisation d'une couche logicielle d'abstraction logiciel-matériel normalisée 6 avec soit une couche logicielle matériel virtuel 10 ou une couche logicielle matériel réel 7 permet de conserver les mêmes interfaces logiciel-matériel lors de toutes les étapes de développement montrées à la figure 4. Ainsi, il peut être utilisé le même outil de test pour tester des bus réels à toutes ces étapes de développement. Une fois un ensemble logiciel agencé, il est possible de passer aisément d'une utilisation en mode simulation matérielle à une utilisation virtuelle et inversement. Un groupe comprenant plusieurs architectures de commande d'un équipement réel ou virtuel, ce dernier étant souvent sous forme d'un outil de simulation en tant qu'équipement au moins partiellement virtuel, est montré à la figure 5. Il est à noter qu'un tel groupe peut consister de plusieurs architectures réelles, de plusieurs architectures virtuelles ou d'un mélange d'architectures réelles et virtuelles. Ce groupe peut former un outil de test ou de simulation comprenant une architecture principale de commande des communications Ap avec un ensemble logiciel de test ou de simulation et un ensemble matériel informatique au moins partiellement virtuel 2b standard, comprenant une couche logicielle matériel virtuel 10 et ses cartes entrées/sorties associées 9Ap ainsi qu'une couche de communication 1 1, ces deux couches ayant été précédemment décrites. Cette architecture Ap communique par son ensemble matériel informatique au moins partiellement virtuel 2b avec plusieurs architectures auxiliaires Al à A5 de composition similaire. Ceci a été rendu possible du fait qu'en général, les architectures possèdent une grande similarité, notamment par l'utilisation de la couche logicielle d'abstraction logiciel-matériel normalisée 6, comme montrée aux figures 2 et 3, dont la bibliothèque n'est pas à développer à nouveau complètement quand associée à un nouvel ensemble mais seulement à compléter. A la figure 5, seule l'architecture Al des architectures auxiliaires Al à A5 est détaillée mais cette architecture Al est représentative de toutes les autres architectures A2 à A5. Cette architecture Al comprend un ensemble logiciel lA1, une couche logicielle d'abstraction logiciel-matériel normalisée 61, une couche logicielle matériel virtuel 101 dans un ensemble matériel informatique 2A1, cette couche pouvant aussi être une couche logicielle matériel réel comme montré à la figure 2, avec ses cartes réelles et/ou virtuelles 9A1 associées. L'architecture Al comprend une couche logicielle de communication référencée 111. Les diverses architectures Al à A5 communiquent entre elles par un mécanisme d'échange en mémoire, par exemple Linux, et sont reliées par au moins une entrée/sortie selon les flèches FE et FS à l'ensemble matériel informatique au moins partiellement virtuel 2b de l'architecture principale Ap. Il est possible de former ainsi des groupes d'architectures réelles ou virtuelles, aussi bien toutes réelles que virtuelles ou à base d'une combinaison d'architectures réelles avec des architectures virtuelles pour, par exemple, créer des erreurs de protocole dès la conception du système. Cette possibilité de combinaison permet, par exemple, de faire tourner un ensemble logiciel sous débogage sur un PC tout en l'interfaçant avec un équipement réel sur banc ou sur le véhicule sur lequel il doit être embarqué. Les échanges entre ensembles matériel informatique des architectures peuvent se faire avantageusement sur des supports de transmissions simulés et peu coûteux, et non sous la forme de données fonctionnelles échangées par mémoire partagée. Il est à noter que la présente invention n'est pas limitée à un équipement embarqué à bord d'un aéronef mais que cet équipement peut l'être à bord de tout véhicule, notamment d'un véhicule automobile, l'équipement pouvant être alors un contrôle moteur, un équipement de sécurité du véhicule du type ABS, ARS ou autres ou un équipement faisant partie du BSI ou Boîtier de Servitude Intelligent, ledit BSI étant organisé autour d'un microprocesseur et gérant un certain nombre d'équipements électriques du véhicule. REVENDICATIONS1. Procédé d'agencement sur au moins un ensemble matériel informatique (2 ; 2b, 2A1), d'au moins un logiciel applicatif (lb) destiné à un équipement de bord pour aéronef ; dans lequel, pour qu'indifféremment ledit ensemble matériel informatique (2) soit réel pour l'hébergement d'un équipement de bord pour aéronef réel, ou ledit ensemble matériel informatique (2b, 2A1) soit au moins partiellement virtuel pour le ré-hébergement d'un autre équipement de bord pour aéronef au moins partiellement virtuel ; ledit ensemble matériel informatique (2 ; 2b, 2A1) comportant un système d'exploitation, un code source, un compilateur et au moins une carte d'entrées/sorties (9a ; 9b), ledit ensemble matériel informatique au moins partiellement virtuel (2b) étant dit stricto sensu virtuel lorsqu'il est associé à des cartes d'entrées/sorties virtuelles (9a) et étant dit lato sensu virtuel lorsqu'il est associé, soit à au moins une carte d'entrées/sorties réelle (9a), soit à au moins une carte d'entrées/sorties réelle associée à au moins une carte d'entrées/sorties virtuelle (9b) ; ledit agencement comprend les étapes suivantes une étape d'agencement d'un ensemble logiciel (1) qui comprend ledit logiciel applicatif (lb) et une couche logicielle d'abstraction logiciel-matériel normalisée (6), la couche logicielle d'abstraction logiciel-matériel normalisée (6) étant composée d'une bibliothèque de primitives d'interface à structure logicielle commune pouvant être associée d'une part, avec des codes sources de l'ensemble logiciel (1) et d'autre part, indifféremment avec au moins un ensemble matériel informatique réel (2) ou au moins un ensemble matériel informatique au moins partiellement virtuel (2b),une étape d'interfaçage avec ladite couche logicielle d'abstraction logiciel-matériel normalisée (6) commune, d'une couche logicielle matériel-réel (7) par ensemble matériel informatique réel (2 ; 2A1) ou d'une couche logicielle matériel informatique virtuel (10) par ensemble matériel informatique au moins partiellement virtuel (2b ; 2A1), chaque couche logicielle matériel-réel (7) ou couche logicielle matériel informatique virtuel (10) d'un ensemble matériel informatique (2 ; 2b, 2A1) hôte étant apte à communiquer avec la couche logicielle 10 d'abstraction logiciel-matériel normalisée (6), pour que chaque couche logicielle matériel-réel (7) puisse coopérer avec une ou des cartes d'entrées/sorties réelles (9) et chaque couche logicielle matériel-virtuel (10) puisse coopérer avec une ou des cartes d'entrée /sorties réelles (9a) et/ou virtuelles (9b) ;et 15 une étape d'agencement d'au moins deux couches logicielles de communication (11) entre des ensembles logiciels (1), par recompilation et édition de liens avec la bibliothèque de la couche logicielle-matériel normalisée (6) sur chaque ensemble matériel informatique au moins partiellement virtuel 20 (2b, 2A1) ; chaque couche logicielle de communication (11) comportant un élément logiciel intermédiaire d'échanges formant prise d'interface logicielle du système d'exploitation de son ensemble matériel informatique au moins partiellement virtuel (2b, 2A1) avec un service de protocole réseau de 25 communication avec d'autres ensembles logiciels (1). Procédé d'agencement selon la revendication caractérisé en ce qu'il agence un hébergement de plusieurs ensembles logiciel (1) sur des ensembles matériels informatiques réels (2) d'équipements réels. 30 3. Procédé d'agencement selon la revendication 1,caractérisé en ce qu'il agence un ré-hébergement de plusieurs ensembles logiciels (1) sur des ensembles matériels informatiques au moins partiellement virtuels (2b, 2A1), et en ce que l'étape d'agencement des couches logicielles de communication (Il) réalise et gère des échanges entre des cartes d'entrées/sorties virtuelles (9b) ensembles matériels informatiques au moins partiellement virtuels (2b, 2A1), ces cartes d'entrées/sorties virtuelles (9b) pouvant faire partie d'un groupe d'équipements de bord pour aéronef au moins partiellement virtuels d'un outil de test ou de simulation. 4. Procédé d'agencement selon la revendication 3, caractérisé par la connexion d'un logiciel de perturbation (8) à la couche logicielle matériel informatique virtuel (10) délivrant des indications de perturbations physiques susceptibles d'être rencontrées sur des ensembles matériel informatique réels (2a) et véhiculés par une couche logicielle de communication (11). 5. Procédé d'agencement selon la revendication 1, caractérisé en ce qu'il comprend une étape de test de la couche logicielle matériel-virtuel (10) comprenant des pilotes de cartes d'entrées/sorties réelles (9a) et/ou virtuelles (9b) et de la couche logicielle de communication (11) en couplant l'ensemble logiciel (1) fonctionnant sur un ensemble matériel informatique au moins partiellement virtuel (2b, 2A1) couplé à au moins un outil de simulation en tant qu'équipement au moins partiellement virtuel. 6. Procédé d'agencement selon l'une des revendications 1 à 5, caractérisé en ce que la couche logicielle d'abstraction logiciel-matériel normalisée (6) présente une structure logiciellecommune pour être associée indifféremment avec plusieurs ensembles matériel informatique réel (2) ou au moins partiellement virtuel (2b). 7. Procédé .d'agencement- selon l'une des revendications 1 à 6, caractérisé en ce que l'agencement de la couche logicielle d'abstraction logiciel-matériel normalisée (6) dans l'ensemble logiciel (1) comprend : une récupération des codes sources 10 applicatifs (lb) de l'ensemble logiciel (1) à agencer, une adaptation des codes sources de ces de logiciels applicatifs (lb) à un compilateur de l'ensemble matériel informatique réel (2) ou d'un ensemble matériel informatique au moins partiellement virtuel (2b, 2A1), 15 une compilation et édition des liens dudit ensemble logiciel (1) et de ladite couche logicielle d'abstraction logiciel matériel normalisée (6). logiciels 8. Procédé revendications 1 à 7, d'agencement selon l'une des: 20 caractérisé en ce qu'il comprend une étape de test de l'ensemble logiciel (1) de l'équipement sur un ensemble matériel informatique au moins partiellement virtuel (2b) standard couplé au moins a un outil de test en tant qu'équipement au moins partiellement virtuel: 25 9. Procédé d'agencement selon l'une des revendications 1 à 8, caractérisé par l'intégration ou le couplage direct de plusieurs cartes d'entrées/sorties réelles (9 ou 9a) et/ou plusieurs cartes d'entrées/sorties virtuelles (9b) à la couche logicielled'abstraction matérielle (6) par l'intermédiaire de la couche logicielle matériel-réel (7) ou de la couche logicielle matériel-virtuel (10). 10. Procédé d'agencement selon l'une des revendications 1 à 9, caractérisé en ce que la communication entre ensemble logiciel (1) et ensemble matériel informatique réel (2) ou au moins partiellement virtuel (2b) s'effectue suivant un protocole de communication normalisé. 10 11. Architecture réelle (Ar) ou virtuelle (Apv, Av ou Avm) de commande avec un ensemble logiciel (1) et un ensemble matériel informatique respectivement réel (2) ou au moins partiellement virtuel (2b), cette architecture réelle (Ar) ou virtuelle (Apv, Av ou Avm) étant respectivement attribuée au 15 fonctionnement d'un équipement auquel elle est destinée dit équipement réel ou d'un équipement autre que cet équipement réel, l'équipement autre étant dit équipement au moins partiellement virtuel, ledit ensemble matériel informatique réel (2) ou au moins partiellement virtuel (2b) recevant ledit 20 ensemble logiciel (1) et étant spécifique à l'équipement réel ou virtuel en gérant ledit équipement par l'intermédiaire de cartes d'entrées/sorties (9) réelles avec bus numériques pour le fonctionnement de l'équipement réel ou de cartes d'entrées/sorties réelles (9a) et/ou virtuelles (9b) pour 25 l'équipement au moins partiellement virtuel, caractérisée en ce qu'elle comprend : - une couche logicielle d'abstraction matériel normalisée (6), composée d'une bibliothèque de primitives s'interfaçant, d'une part, avec les codes sources de l'ensemble logiciel (1) et,d'autre part, avec l'ensemble matériel informatique réel (2) ou au moins partiellement virtuel (2b), une couche logicielle matériel-réel (7) ou une couche logicielle matériel-virtuel (10) respectivement dans l'ensemble matériel informatique réel (2) ou l'ensemble matériel informatique au moins partiellement virtuel (2b), ladite couche logicielle matériel-réel (7) ou matériel virtuel (10) formant la partie de l'ensemble matériel informatique réel (2) ou au moins partiellement virtuel (2b) s'interfaçant avec la couche logicielle d'abstraction logiciel-matériel normalisée (6), la couche logicielle matériel-réel (7) effectuant respectivement la gérance des cartes d'entrées/sorties réelles (9) avec des bus numériques de l'ensemble matériel informatique réel (2) de l'équipement réel, la couche logicielle matériel-virtuel (10) effectuant la gérance des cartes d'entrées/sorties réelles (9a) et/ou virtuelles (9b) avec des bus numériques de type analogique et/ou de type discret de l'ensemble matériel informatique au moins partiellement virtuel (2b), lesdites cartes virtuelles (9b) assurant au moins les mêmes fonctions que les cartes d'entrées/sorties réelles (9) et leurs pilotes associés de l'ensemble matériel informatique réel (2). 12. Architecture virtuelle (Apv, Av ou Avm) selon la revendication 11, cette architecture virtuelle (Apv, Av ou Avm) étant destinée pour au moins un outil de simulation en tant qu'équipement au moins partiellement virtuel, caractérisée en ce que son ensemble matériel informatique au moins partiellement virtuel (2b) est d'un standard courant et économique, du type PC unitaire ou d'au moins deux PC connectés ensemble, les cartes d'entrées/sorties virtuelles (9b) avec leurs pilotes étant, lorsqu'elles sont présentes, intégrées dans ou couplées avec la couche logicielle matériel-virtuel (10),la gérance des cartes d'entrées/sorties virtuelles (9b) s'effectuant a travers un réseau de standard économique et courant du type réseau Ethernet ou réseau de signaux analogiques et discrets. 13. Architecture virtuelle (Apv, Av ou Avm) selon la revendication 12, caractérisée en ce qu'elle comprend uniquement des cartes d'entrées/sorties réelles (9a). 14. Architecture virtuelle (Apv, Av ou Avm) selon la 10 revendication 12, caractérisée en ce qu'elle comprend uniquement des cartes d'entrées/sorties virtuelles (9b), une couche logicielle de communication (11) effectuant la réalisation et la gestion des échanges entre les cartes d'entrées/sorties virtuelles (9b). 15 15. Architecture virtuelle (Apv, Av ou Avm) selon revendication 12, caractérisée en ce qu'elle comprend une combinaison de cartes d'entrées/sorties réelles (9a) et de cartes d'entrées/sorties virtuelles (9b), une couche logicielle de communication (1 1) 20 effectuant la réalisation et la gestion des échanges entre les cartes d'entrées/sorties virtuelles (9b). 16. Equipement réel ou au moins partiellement virtuel caractérisé en ce qu'il comprend respectivement une 25 architecture réelle (Ar) ou virtuelle (Apv, Av ou Avm) selon l'une des revendications 11 à 15.. Groupe composé d'équipements réels ou au moins partiellement virtuels selon la revendication 16, caractérisé en ce que les équipements réels ou au moins partiellement virtuels présentent, dans leur ensemble logiciel (1), une couche logicielle d'abstraction logiciel-matériel normalisée (6) de conception similaire. 18. Groupe d'équipements réels ou moins partiellement virtuels selon la revendication 17, caractérisé en ce qu'au moins une partie des ensembles 10 matériel informatique réels (2) ou au moins partiellement virtuels (2b) sont connectés les uns aux autres, ladite partie formant un équipement réel ou au moins partiellement virtuel combinant les fonctions des équipements réels ou au moins partiellement virtuels le composant. 15 19. Véhicule, caractérisé en ce qu'il comprend en son bord un équipement ou un groupe d'équipements selon l'une des revendications 16 à 18. 20. Véhicule selon la revendication précédente, 20 caractérisé en ce qu'il est un aéronef.