FR 3144352 A1 20240628 FR 2214319 A 20221222 Dispositif de calcul périphérique embarqué, système électronique d’exécution d’applications logicielles et procédé d’exécution d’applications logicielles associés Ce dispositif de calcul périphérique embarqué à bord d’un aéronef, est configuré pour communiquer avec un ou plusieurs dispositifs électroniques de bord (12, 14) à fonctionnement certifié, et avec au moins un système de calcul distant (8). Il comporte des ressources calculatoires locales, et est configuré pour implémenter : - un module (30) de gestion d’une pluralité d’applications logicielles (APP i ), adaptées pour fournir au moins un paramètre de commande et/ou recevoir au moins une donnée d’au moins un dispositif électronique de bord; - un module (32) d’activation d’exécution d’au moins une desdites applications logicielles stockées, - un module (34) de gestion d’une pile d’exécution, configuré pour déterminer, pour chaque application logicielle à exécuter, une allocation de ressources calculatoires locales et, le cas échéant, exécuter une première partie de ladite application localement, et requérir une exécution distante, par le système de calcul distant (8), d’une deuxième partie de l’application à exécuter. Figure pour l'abrégé : Figure 1 Dispositif de calcul périphérique embarqué, système électronique d’exécution d’applications logicielles et procédé d’exécution d’applications logicielles associés La présente invention concerne un dispositif de calcul périphérique embarqué à bord d’un aéronef, ainsi qu’un système électronique d’exécution d’applications logicielles associé et un procédé d’exécution d’applications logicielles associé. L’invention se situe dans le domaine de l’avionique, et plus particulièrement dans le domaine de l’exécution d’applications logicielles embarquées sur un aéronef. L’invention s’applique pour tout type d’aéronef, avec ou sans pilote à bord, à la fois dans un contexte civil ou militaire. De manière connue, les aéronefs comportent des dispositifs électroniques de bord (ou ordinateurs de bord) à fonctionnement certifié selon une norme de certification avionique. En particulier, toute application logicielle embarquée dans ce type de dispositif doit être conforme et certifiée. Ainsi, les applications logicielles embarquées, qui sont utiles pour la navigation, pour la commande d’équipement embarqués, par exemple des divers capteurs, e.g. caméras optiques ou thermiques, radars etc, sont en nombre restreint, car elles sont coûteuses à développer et à certifier. De plus, les ressources de calcul (e.g. CPU, ROM, RAM) des ordinateurs de bord certifiés sont en général pré-allouées, pour garantir la sécurité et limiter tout risque de piratage ou d’intrusion extérieure. Ainsi, la structure matérielle et logicielle des ordinateurs de bord à fonctionnement certifié est rigide, toute évolution ou modification étant lente et coûteuse. Cependant, le besoin de ressources de calcul, e.g. processeurs et mémoires, pour des opérations aéronautiques est en constante augmentation, des applications logicielles de plus en plus sophistiquées pouvant être avantageusement mises en œuvre. De plus, de nouveaux usages se développement avec l’avènement de nouveaux types d’aéronefs allégés, par exemple des drones ou des aéronefs taxis urbains, permettant notamment l’utilisation des capteurs embarqués pour de nouvelles missions de collecte de données, pour des applications de surveillance, de maintenance etc. Il existe donc un besoin d’augmenter la capacité calculatoire des dispositifs de bord pour permettre d’exécuter des applications logicielles en lien avec ces nouveaux besoins. Des systèmes de déport des exécutions d’applications logicielles au sol, dans des centres de calcul au sol, ont été proposés. Néanmoins, dans la mesure où des commandes d’équipements embarqués et des récupérations de données fournies par de tels équipements sont nécessaires, le déport des applications au sol n’est pas toujours possible, selon les besoins notamment en termes de bande passante et de latence, et, le cas échéant, en termes de fiabilité/intégrité des calculs et de protection de données. Il existe donc un besoin d’exécution d’applications logicielles en lien avec des équipements embarqués dans un aéronef, qui allie l’augmentation des ressources calculatoires disponibles et la fiabilité. A cet effet, l’invention propose, selon un aspect, un dispositif de calcul périphérique embarqué à bord d’un aéronef, comportant une première interface de communication configurée pour communiquer, selon un premier protocole de communication, avec un ou plusieurs dispositifs électroniques de bord à fonctionnement certifié, une deuxième interface de communication radio, configurée pour communiquer, selon un deuxième protocole de communication radio, avec au moins un système de calcul distant situé au sol, le dispositif de calcul périphérique comportant au moins une unité de mémoire électronique et au moins un processeur de calcul, configuré pour implémenter : - un module de gestion d’une pluralité d’applications logicielles, lesdites applications logicielles étant stockées dans ladite mémoire électronique, chaque application logicielle étant adaptée pour fournir au moins un paramètre de commande et/ou recevoir au moins une donnée d’au moins un dispositif électronique de bord à fonctionnement certifié ; - un module d’activation d’exécution d’au moins une desdites applications logicielles stockées, configuré pour recevoir au moins une requête d’exécution d’au moins une application logicielle d’un dispositif externe de commande et/ou pour valider une condition d’activation d’exécution d’au moins une application logicielle, - un module de gestion d’une pile d’exécution, configuré pour déterminer, pour chaque application logicielle à exécuter, une allocation de ressources calculatoires locales dudit dispositif de calcul périphérique pour exécuter tout ou partie de ladite application logicielle à exécuter, et pour lancer l’exécution locale de ladite partie de l’application à exécuter et requérir, dans le cas où une première partie de ladite application est exécutée localement, une exécution distante, par le système de calcul distant, d’une deuxième partie de l’application à exécuter, complémentaire de la première partie. Avantageusement, un tel dispositif de calcul périphérique permet d’augmenter considérablement les ressources de calcul disponibles à bord, tout en gérant l’exécution de la ou des applications logicielles entre les ressources calculatoires locales de bord et des ressources calculatoires distantes. Le dispositif de calcul périphérique embarqué selon l’invention peut également présenter une ou plusieurs des caractéristiques ci-dessous, prises indépendamment ou selon toutes les combinaisons techniquement envisageables. Le module de gestion d’une pile d’exécution met en œuvre, pour la détermination de ressources calculatoires locales allouées par application logicielle à exécuter, au moins un critère parmi : un critère de disponibilité de ressources calculatoires, un critère de connectivité, un critère de protection de données, un critère de priorité. Le dispositif est configuré pour recevoir dynamiquement, d’un dispositif externe de commande, au moins un paramètre d’allocation de ressources calculatoires et/ou de connectivité et/ou un priorité d’exécution. Le dispositif comporte en outre un module de gestion de données et de résultats, configuré pour consolider et mémoriser des résultats obtenus par l’exécution de chaque application logicielle, pour communiquer les résultats au dispositif externe de commande et/ou au système de calcul distant. Le module de gestion d’une pluralité d’applications logicielles est configuré pour télécharger de nouvelles applications logicielles ou une mise à jour d’une application logicielle préalablement mémorisée et/ou de supprimer une application logicielle préalablement mémorisée. Selon un autre aspect, l’invention concerne un système électronique d’exécution d’applications logicielles comprenant un système de calcul embarqué sur un aéronef, et au moins un système de calcul distant situé au sol, le système de calcul embarqué comportant au moins un dispositif électronique de bord à fonctionnement certifié selon une norme de certification avionique, et un dispositif de calcul périphérique tel que brièvement décrit ci-dessus. Le système électronique d’exécution d’applications logicielles peut également présenter une ou plusieurs des caractéristiques ci-dessous, prises indépendamment ou selon toutes les combinaisons techniquement envisageables. Le système de calcul distant comporte en outre un dispositif de supervision comportant une interface homme-machine et étant configuré pour recevoir des signaux d’observabilité dudit dispositif de calcul périphérique, lesdits signaux d’observabilité comprenant des données relatives aux ressources calculatoires locales et des informations relatives à l’exécution d’au moins une desdites applications logicielles, pour calculer un état de fonctionnement dudit dispositif de calcul périphérique et un état d’exécution de ladite au moins une application logicielle à partir des signaux d’observabilité reçus, et pour afficher ledit état de fonctionnement et ledit état d’exécution sur ladite interface homme machine. Le dispositif de calcul périphérique est configuré pour enregistrer, durant une mission de l’aéronef, un ensemble d’informations dans au moins un rapport d’exécution, comprenant des informations d’état et d’exécution du dispositif de calcul périphérique et des dispositifs électroniques de bord à fonctionnement certifié, ainsi que des informations complémentaires comprenant des informations d’environnement et des informations de connectivité, et pour transmettre ledit rapport d’exécution au dispositif de supervision, le dispositif de supervision étant en outre configuré pour exécuter et afficher sur l’interface homme-machine un rejeu des états du dispositif de calcul périphérique et des dispositifs électroniques de bord. Selon un autre aspect, l’invention concerne un procédé d’exécution d’applications logicielles, mis en œuvre dans un système électronique d’exécution d’applications du type décrit ci-dessus, comportant des étapes de : - réception d’une commande d’ajout/suppression d’application logicielle, en provenance d’un dispositif externe de commande, ou d’un système de calcul au sol ou d’un des dispositifs de bord ; -mise à jour d’un stockage des applications logicielles en fonction de ladite commande reçue ; - activation d’exécution d’une ou plusieurs des applications logicielles mémorisées, basée soit sur la réception d’une requête d’exécution d’au moins une application logicielle d’un dispositif externe, soit sur la validation d’une condition d’activation d’exécution et/ou mise en pause ou arrêt d’exécution d’une ou plusieurs applications logicielles sur réception d’une commande ou validation automatique d’une condition d’arrêt . Selon une caractéristique particulière, le procédé comprend en outre une étape de gestion de pile d’applications, mettant en œuvre, pour chaque application logicielle à exécuter, une allocation de ressources calculatoires locales pour exécuter une première partie de l’application logicielle, et, dans le cas où ladite première partie est inférieure à 100%, une étape de transmission de commande d’exécution d’une deuxième partie de ladite application logicielle, complémentaire à la première partie, au système de calcul distant. Selon un autre aspect, l’invention concerne un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un dispositif électronique programmable, mettent en œuvre un procédé d’exécution d’applications logicielles tel que brièvement décrit ci-dessus. D’autres caractéristiques et avantages de l’invention ressortiront de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures annexées, parmi lesquelles : la illustre un système électronique d’exécution d’applications logicielles selon un mode de réalisation ; la illustre un procédé d’exécution d’applications logicielles selon un premier mode de réalisation ; la illustre un procédé d’exécution d’applications logicielles selon un deuxième mode de réalisation. Le système électronique d’exécution d’applications logicielles, embarqués à bord d’un aéronef, trouve des applications dans tout type d’aéronef, et plus particulièrement pour des aéronefs allégés tels que des drones, embarquant des équipements tels que des capteurs images, de type caméra optique, caméra thermique, radar imageur, des capteurs de positionnement (GNSS, centrales inertielles, capteurs anémo-barométriques, balises de radionavigation, triangulation), des systèmes de mesure comme des télémètres, des capteurs et systèmes de surveillance météo, trafic ou terrain, des systèmes de communication radio ou numériques, des antennes radiofréquence (RF) etc. La illustre schématiquement un système 2 qui est un système électronique d’exécution logicielles embarquées. Le système 2 est un système permettant une coopération bord-sol. Le système 2 comporte d’une part un système de calcul embarqué 4, comportant des dispositifs embarqués à bord d’un aéronef 6, et d’autre part, un ou plusieurs systèmes de calcul au sol 8. Le système de calcul embarqué 4 comporte un ensemble 10 de dispositifs électroniques de bord à fonctionnement certifié selon une norme de certification avionique, comprenant au moins un ordinateur de bord 12, et des équipements embarqués 14, e.g. des capteurs, par exemple caméras, radars, actionneur, système de navigation, système de pilotage automatique, commandes de vol, système de géolocalisation, des systèmes de surveillance certifiés (Trafic terrain, météo), des systèmes de communication certifiés (e.g. Radios). Par exemple, les dispositifs de bord à fonctionnement certifié respectent une ou plusieurs des normes suivantes : RTCA DO178B pour le niveau de certification logicielle et RTCA DO160 pour la partie certification matérielle, AEEC Arinc 702A pour le système de gestion de vol (Flight Management System), etc. Dans un mode de réalisation, l’ordinateur de bord 12 est configuré pour mettre en œuvre des applications logicielles certifiées, par exemple des applications d’aide à la navigation, de commande de fonctionnement des capteurs 14 et de réception et de traitement de données issues des capteurs 14. L’ordinateur de bord 12 comporte des ressources matérielles, en particulier une unité de traitement centrale comprenant notamment un ou plusieurs processeurs 15, adaptés pour exécuter des instructions de programme informatique lorsque l’unité de traitement est mise sous tension. L’ordinateur de bord 12 comporte également des unités de stockage d’informations 16, comprenant notamment des unités de mémoire vive (mémoire RAM), des unités de mémoire de type ROM, adaptée à stocker des données et des instructions de code exécutable, une interface de communication 18 et une interface homme-machine 17. De plus, le système de calcul embarqué 4 comporte avantageusement un dispositif de calcul périphérique embarqué 20. Ce dispositif de calcul périphérique 20 permet avantageusement d’augmenter la capacité calculatoire embarquée, de manière plus flexible, permettant des mises à jour logicielles et matérielles plus aisées et moins coûteuses que pour l’ordinateur de bord 12. Le dispositif de calcul périphérique 20 comporte une première interface de communication 22 configurée pour communiquer, selon un premier protocole de communication, avec le ou les dispositifs électroniques de bord à fonctionnement certifié, et notamment avec l’ordinateur de bord 12. En particulier, la première interface de communication 22 est configurée pour communiquer, selon une communication bidirectionnelle, avec l’interface de communication 18 de l’ordinateur de bord 12. Par exemple, la communication entre le dispositif de calcul périphérique 20 et l’ordinateur de bord 12 est une communication filaire. En variante, la communication entre le dispositif de calcul périphérique 20 et l’ordinateur de bord 12 est une communication sans fil, par exemple de type Wifi ou Bluetooth. En outre, le dispositif de calcul périphérique 20 comporte une deuxième interface de communication radio 24, configurée pour communiquer, selon un deuxième protocole de communication radio, avec le ou les systèmes de calcul distant 8 situés au sol. Le deuxième protocole de communication est un protocole de communication radio, par exemple un protocole standard de téléphonie mobile 4G ou 5G, le protocole de communication par satellite SATCOM, le protocole Datalink AOC/ATC (pour « Aeronautical Operation Control »/ « Air Traffic Control »). Selon des variantes, le dispositif de calcul périphérique 20 comprend plusieurs deuxièmes interfaces de communication radio 24, selon plusieurs protocoles de communication radio, permettant de communiquer avec dispositifs externes, par une deuxième interface de communication radio 24A permettant de communiquer avec le système de calcul 8 et une deuxième interface de communication radio 24B permettant de communiquer selon un autre protocole de communication radio, par exemple avec un ou plusieurs dispositifs externes de commande 25, configurés pour envoyer des commandes de mise en œuvre d’applications logicielles par le dispositif de calcul périphérique 20 et de recevoir des données, notamment des données issues de capteurs embarqués, en retour. Un dispositif externe de commande 25 est par exemple une tablette, un ordinateur portable, un téléphone intelligent (ou ordiphone). Un tel dispositif externe de commande 25 est par exemple également embarqué à bord de l’aéronef. Dans un mode de réalisation, un tel dispositif externe de commande 25 est opéré par un opérateur embarqué à bord de l’aéronef, par exemple un pilote de l’aéronef, via une interface homme-machine, e.g. un écran tactile ou tout autre type d’interface homme-machine adéquat (non représenté ici). Ainsi, le dispositif de calcul périphérique 20 est configuré pour communiquer, de manière bidirectionnelle, avec le système de calcul distant 8 et avec au moins un dispositif externe de commande 25. Le dispositif de calcul périphérique 20 comporte en outre une unité de traitement 26, comportant un ou plusieurs processeurs (CPU ou GPU), et au moins une unité de mémoire électronique 28, ces éléments étant adaptés à communiquer via un bus de communication (non représenté). Dans l’exemple de la seule une unité de traitement 26 et une unité de mémoire électronique 28 sont représentées. L’unité de mémoire électronique 28 comporte notamment des mémoires de type RAM, ROM, tout type de mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM). L’ensemble des unité(s) de traitement 26 et unité(s) de mémoire électronique 28 forme les ressources calculatoires locales du dispositif de calcul périphérique 20. De préférence, le dispositif de calcul périphérique 20 est modulaire, plusieurs unités de traitement et de mémoire pouvant être ajoutées, ce qui permet une augmentation dynamique des ressources disponibles, en fonction des besoins. L’augmentation dynamique des ressources disponibles est limitée, en pratique, dans certains modes de réalisation, par la consommation d’énergie électrique et/ou le poids total d’un tel dispositif de calcul périphérique 20. En effet, le poids total peut être limité pour certains types d’aéronefs, par exemple pour des drones, en fonction de la portance aérodynamique du drone, et/ou de sa manœuvrabilité. De même, la consommation d’énergie électrique lorsque le dispositif de calcul périphérique exécute des applications logicielles avec une occupation maximale des ressources calculatoires et de stockage 26, 28, est à prendre en compte, afin d’assurer la réalisation d’une mission prévue, sur une durée de mission prévue. On entend ici par mission un ensemble de tâches à effectuer, par exemple par des capteurs embarqués, en lien avec des indications de vol associées (trajectoires, durées, points de passage etc). L’unité de mémoire électronique 28 est configurée notamment pour mémoriser une bibliothèque d’applications logicielles 35, comportant un nombre d’applications logicielles APP 1 , APP 2 … APP i variable. Chaque application logicielle est mémorisée sous forme de code de programme exécutable. Le terme « application exécutable » est également utilisé pour désigner une telle application logicielle. Par exemple, les applications logicielles sont obtenues par téléchargement (en anglais « Dataloading »), à partir d’un dispositif externe de commande 25 ou à partir d’un système de calcul au sol 8. En variante ou en complément, une application logicielle APP i peut être obtenue à partir d’un support lisible par ordinateur, par exemple un médium apte à mémoriser les instructions électroniques et à être couplé à un bus d’un système informatique (e.g. clé USB, mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique). En outre, l’unité de mémoire électronique 28 est également configurée pour mémoriser des données et résultats 37, notamment des données obtenues des dispositifs électroniques de bord à fonctionnement certifié (par exemple, des images obtenues par des capteurs embarqués, des données de fonctionnement, des données relatives à la trajectoire ou aux performances de l’aéronef), et des résultats obtenus par l’exécution des applications logicielles APP i . Ces données et résultats 37 peuvent être transmis au sol en tant que « signaux d’observabilité », permettant à un opérateur humain ou à un système de surveiller le bon fonctionnement du système global, assurer le débogage, et effectuer des simulations ou du rejeu (en anglais « replay ») de mission. En outre, l’unité de mémoire électronique 28 est configurée pour mémoriser des paramètres utiles pour la mise en œuvre d’un procédé d’exécution d’applications logicielles tel que décrit ci-après, notamment des paramètres relatifs à l’allocation des ressources calculatoires par application logicielle, le cas échéant, un tableau de priorités d’exécution ou un ensemble de règles statiques définissant des priorités d’exécution d’applications logicielles. L’unité de traitement 26 est configurée pour exécuter : - un module 30 de gestion d’une pluralité d’applications logicielles, les applications logicielles étant stockées dans l’unité de mémoire électronique 28, notamment dans une bibliothèque d’applications 35, chaque application logicielle étant adaptée pour fournir au moins un paramètre de commande et/ou recevoir au moins une donnée d’au moins un dispositif électronique de bord à fonctionnement certifié ; - un module 32 d’activation d’exécution d’au moins une desdites applications logicielles stockées, configuré pour recevoir au moins une requête d’exécution d’au moins une application exécutable d’un dispositif externe de commande et/ou pour valider une condition d’activation d’exécution d’au moins une application logicielle, -un module 34 de gestion d’une pile d’exécution, configuré pour déterminer, pour chaque application logicielle à exécuter, une allocation de ressources calculatoires locales 26, 28 du dispositif de calcul périphérique 20 pour exécuter tout ou partie de l’application à exécuter, et pour lancer l’exécution locale de ladite partie de l’application à exécuter et requérir, dans le cas où seule une première partie de ladite application est exécutée localement, une exécution distante, par le système de calcul distant 8, d’une deuxième partie de l’application à exécuter, complémentaire de la première partie ; -un module 36 de gestion de données et résultats, configuré pour consolider et mémoriser les résultats, et communiquer les résultats au dispositif externe de commande et/ou au système de calcul distant. Les modules 30, 32, 34, 36 sont adaptés à coopérer, comme décrit plus en détail ci-après, pour mettre en œuvre un procédé d’exécution d’applications logicielles tel que décrit plus en détail ci-après. Dans un mode de réalisation, les modules 30, 32, 34, 36 sont réalisés sous forme d’instructions logicielles formant un programme d’ordinateur, qui, lorsqu’il est exécuté par un ordinateur, met en œuvre un procédé d’exécution d’applications logicielles selon l’invention. Le programme d’ordinateur comportant des instructions logicielles est en outre apte à être enregistré sur un support non transitoire lisible par ordinateur. Le support lisible par ordinateur est par exemple, un médium apte à mémoriser les instructions électroniques et à être couplé à un bus d’un système informatique. A titre d’exemple, le support lisible est un disque optique, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, tout type de mémoire non-volatile (par exemple EPROM, EEPROM, FLASH, NVRAM), une carte magnétique ou une carte optique. En variante non représentée, les modules 30, 32, 34, 36 sont réalisés chacun sous forme de composants logiques programmables, tels que des FPGA (de l’anglais Field Programmable Gate Array ), des microprocesseurs, des composants GPGPU (de l’anglais General-purpose processing on graphics processing ), ou encore de circuits intégrés dédiés, tels que des ASIC (de l’anglais Application Specific Integrated Circuit ). Le dispositif de calcul périphérique 20 est configuré ainsi pour exécuter localement une première partie des applications à exécuter, et pour déléguer, le cas échéant, une deuxième partie d’exécution au système de calcul distant 8. En effet, dans certains cas de figure, la première partie est égale à 100% de l’application logicielle à exécuter, auquel cas il n’y a pas lieu de déléguer une deuxième partie d’exécution au système de calcul distant. Dans un mode de réalisation, le système de calcul distant 8 comporte un ou plusieurs dispositifs de calcul électroniques interconnectés. En variante, le système de calcul distant 8 comporte ou est connecté à un nuage d’ordinateurs ou « cloud » en anglais. Dans une représentation fonctionnelle, le système de calcul distant 8 comporte une unité de traitement 40, comportant un ou plusieurs processeurs de calcul, une unité de mémoire électronique 42, une interface de communication sol 44, adaptée pour communiquer avec la deuxième interface de communication 24 du dispositif de calcul périphérique embarqué 20, et une interface homme-machine 46. L’unité de traitement 40 est configurée pour exécuter des parties des applications logicielles APPi, par exécution d’une partie correspondante du code exécutable, mémorisée dans l’unité de mémoire électronique 42, sur requête en provenance du dispositif de calcul périphérique 20, à mémoriser des données et résultats de calcul et à transmettre ces résultats de calcul, via l’interface de communication 44, au dispositif de calcul périphérique 20 et/ou à un dispositif externe de commande 25. Selon une variante, le système de calcul distant 8 situé au sol est également configuré pour transmettre des données et résultats de calcul à un autre aéronef 6, par exemple dans le cadre d’une mission impliquant une pluralité d’aéronefs. Avantageusement, une telle gestion de pile d’exécution est dynamique et flexible, et permet de prendre en compte un ou plusieurs critères parmi : un critère de disponibilité des ressources calculatoires, un critère de connectivité, un critère de criticité des données, un critère de priorité, comme expliqué plus en détail ci-après. La est un synoptique des principales étapes d’un procédé d’exécution d’applications logicielles, mis en œuvre dans le système électronique 2 d’exécution d’applications logicielles, dans un premier mode de réalisation. Comme il apparaîtra plus clairement de la description à suivre, le procédé comporte un ensemble d’étapes mises en œuvre par une unité de traitement, comprenant au moins un processeur, d’un dispositif de calcul périphérique embarqué 20. Ces étapes sont exécutées après mise sous tension du dispositif de calcul périphérique. Le procédé comporte une étape 50 d’initialisation, qui est une étape préalable, exécutée dans un temps différé par rapport aux autres étapes du procédé. Lors de l’étape d’initialisation, en particulier, les première et deuxième interfaces de communication sont initialisées, en particulier configurées avec des adresses de communication respectives, de manière à permettre les communications, d’une part avec les dispositifs électroniques de bord 10 à fonctionnement certifié, d’autre part avec les dispositifs externes 25, et avec le système de calcul au sol 8. Alternativement, le dispositif de calcul périphérique exécute l’initialisation des interfaces de communication suite à une requête, par exemple transmise par un opérateur ou par une application externe par l’intermédiaire d’un dispositif externe de commande 25. De plus, à l’étape d’initialisation 50, lors de l’initialisation de la première interface de communication avec les équipements de bord, des premières structures de configuration, e.g. de premières tables de configurations sont reçues d’au moins un ordinateur de bord 12, et mémorisées dans une unité de mémoire électronique locale du dispositif de calcul périphérique. De manière analogue, lors de l’initialisation de la deuxième interface de communication avec le système de calcul distant, des deuxièmes structures de configuration, e.g. de deuxièmes tables de configurations sont reçues d’au moins un système de calcul distant 8, et mémorisées dans une unité de mémoire électronique locale du dispositif de calcul périphérique. Les premières et deuxièmes structures de configuration contiennent notamment des informations de connectivité (e.g. identifiants et adresses de communication). Optionnellement, lors de l’étape d’initialisation, la bibliothèque d’applications logicielles APP i est ré-initialisée. Optionnellement, les données et résultat 37 mémorisés dans l’unité de mémoire du dispositif de calcul périphérique sont effacées lors de l’initialisation 50. Selon des variantes, les applications APP i et/ou les données et résultats mémorisés lors d’une préalable utilisation du dispositif de calcul périphérique sont conservés. En outre, lors de la phase d’initialisation, dans un mode de réalisation, des paramètres utiles pour la mise en œuvre du procédé d’exécution d’applications logicielles sont obtenus et mémorisés. Ces paramètres comportent notamment des paramètres relatifs à l’allocation des ressources par application logicielle, par exemple pour une allocation minimale par application logicielle, une allocation maximale ou une allocation moyenne, et/ou un tableau de priorités d’exécution ou un ensemble de règles statiques définissant des priorités d’exécution d’applications logicielles. Les paramètres d’allocation de ressources contiennent par exemple : une puissance de calcul, par exemple exprimée en fréquence d’horloge du processeur (par ex en GHz), et/ou une capacité de stockage associée, exprimée par exemple en kilo-octets, et/ou un pourcentage de bande passante de première communication avec les dispositifs électroniques de bord à fonctionnement certifié, et/ou un pourcentage de bande passante de deuxième communication avec le système de calcul distant. Dans un mode de réalisation, les paramètres d’allocation de ressources sont regroupés sous forme d’un vecteur de paramètres, contenant une valeur pour chacun des paramètres mentionnés ci-dessous : - P1 : puissance de calcul allouée ; - P2 : capacité de stockage allouée ; - P3 : pourcentage de bande passante de première communication ; - P4 : pourcentage de bande passante de deuxième communication. Dans des variantes, un vecteur comportant seulement une sous-partie des paramètres d’allocation est défini. Dans une autre variante, seul l’un des paramètres mentionnés ci-dessus est utilisé. Le procédé comporte une étape 52 de réception de commande d’ajout/suppression d’application logicielle, en provenance d’un dispositif externe de commande, ou du système de calcul au sol ou d’un des dispositifs de bord. De préférence, une commande de suppression est reçue d’un dispositif de commande externe ou d’un opérateur autorisé, par exemple propriétaire de l’application logicielle à supprimer. Par exemple, une authentification d’opérateur autorisé est mise en œuvre, par un procédé d’authentification, de nombreuses variantes de tels procédés d’authentification étant connues. Selon un mode de réalisation, l’ajout/la mise à jour d’une application est effectué par un opérateur, de préférence un opérateur autorisé, au moyen d’un support de stockage de données (e.g. clé USB). Suite à la réception d’une telle commande, le procédé comporte une étape 54 de gestion des applications, qui effectue une mise à jour de la bibliothèque des applications logicielles en fonction des commandes reçues. L’étape 54 comprend la réception d’une nouvelle application logicielle ou une mise à jour d’une application logicielle préalablement mémorisée, par le moyen d’une liaison filaire ou à télécharger au moyen d’un lien de communication radio, puis la mémorisation des nouvelles applications APP j , et/ou la suppression des applications APP i de la bibliothèque d’applications. Les applications logicielles mémorisées dans la bibliothèque d’applications 35 sont adaptées pour fournir au moins un paramètre de commande et/ou recevoir au moins une donnée d’au moins un dispositif électronique de bord. En complément optionnel, suite à la réception d’une nouvelle application logicielle ou d’une mise à jour d’une application logicielle existante, le procédé met en œuvre des validations d’intégrité et de validité des applications téléchargées, par des méthodes usuelles (authentification, validation de contrôle de redondance cyclique (CRC), etc). Par la suite, le procédé comporte l’activation d’exécution 56 d’une ou plusieurs des applications logicielles stockées, qui deviennent alors des applications logicielles à exécuter. En effet, l’exécution parallèle de plusieurs applications logicielles est gérée. L’activation d’exécution est basée soit sur la réception d’une requête d’exécution d’au moins une application logicielle d’un dispositif externe, soit sur la validation d’une condition d’activation d’exécution. Dans le cas de la validation d’une condition d’activation d’exécution, l’activation est automatique. Par exemple, la condition d’activation d’exécution d’une application logicielle APP i est la fin d’exécution d’une application logicielle APP j ou bien correspond à une diminution du besoin en ressource de l’application logicielle Appj compatible avec son fonctionnement. En outre, des commandes de mise en pause ou d’arrêt d’exécution d’une ou plusieurs applications logicielles peuvent également être reçues (étape 58), leur gestion étant effectuée directement. L’arrêt d’exécution permet de libérer des ressources et donc de redistribuer les ressources disponibles. De même que pour l’exécution, une validation automatique de condition d’arrêt permet également de déclencher l’arrêt ou la mise en pause de l’exécution d’une application. Les étapes 54, 56, 58 sont de préférence exécutées en tâche de fond, sensiblement en parallèle, de manière à constamment prendre en compte la réception de nouvelles applications logicielles ou la mise à jour d’applications logicielles existante, ainsi que les activations d’exécution et les commandes d’arrêt ou pause d’exécution. Le procédé comporte en outre une étape 60 de gestion d’une pile d’exécution des applications logicielles à exécuter. Cette étape est répétée régulièrement, à des intervalles temporels prédéterminés ou sur évènement (par exemple demande de démarrage d’une nouvelle application, évènement qui met fin ou modifie significativement les besoins en ressources calculatoires d’une application). L’étape de gestion 60 met en œuvre pour chaque application à exécuter APP k , une allocation de ressources, en particulier de ressources calculatoires (processeur et mémoire) du dispositif de calcul périphérique, dites ressources locales, pour exécuter tout ou partie de l’application à exécuter APP k . Par exemple, dans un mode de réalisation, une même quantité de ressources locales est allouée à chaque APP k, la quantité étant prédéterminée à l’étape d’initialisation 50. Selon une variante, les ressources sont allouées dynamiquement, par exemple en fonction d’un temps de réponse attendu par application, ce qui permet de définir dynamiquement des priorités d’exécution Selon une alternative, les l’allocation des ressources est effectuée en fonction de priorités, définies dans un tableau de priorités d’exécution préalablement enregistré ou selon un ensemble de règles statiques préalablement programmé. Selon une variante, les priorités sont mises à jour dynamiquement au moyen d’un dispositif de commande externe. Ainsi, le module de gestion met en œuvre également un critère de priorité. Pour chaque application logicielle à exécuter APP k , en fonction des ressources nécessaires à son exécution, il est possible de déterminer, le cas échéant, une première partie de l’application APP k,1 qui est exécutée localement, et une deuxième partie APP k,2 , complémentaire de la première partie, à exécuter par le système de calcul distant au sol. En d’autres termes, des ressources locales et des ressources distantes sont allouées pour l’exécution d’une même application logicielle APP k . Ainsi, un critère de disponibilités de ressources calculatoires est mis en œuvre pour la détermination de l’exécution locale ou distante de chaque application logicielle. De plus, la disponibilité d’une bande passante de communication avec le système de calcul au sol est également prise en considération. Ainsi, un critère de connectivité est pris en compte. En effet, par exemple pour des applications logicielles qui utilisent des données haut débit, par exemple des données vidéo, une bande passante importante est nécessaire pour réaliser un traitement des données par le système de calcul distant situé au sol. De plus, pour un aéronef en déplacement, les conditions de communication selon le deuxième protocole de communication radio peuvent varier en fonction du déplacement, des conditions météorologiques etc. Considérons par exemple un drone de détection et de cartographie d’obstacles tels que des pylônes électriques, et dont la mission consiste à voler au-dessus d’une zone géographique déterminée, détecter les obstacles de type « pylônes », les caractériser (largeur, hauteur), les géo-référencer (i.e. calculer leur position géographique dans un référentiel donné), et en déduire le maillage de câbles électriques qui les relie. La détection peut se faire à l’aide de caméras embarquées dans le drone, dont la résolution, la largeur de champ et la cadence de prises de vues aura un impact direct sur le besoin en ressources : Une séquence vidéo en définition/résolution 4K, grand champ, à 50 images/sec demandera par exemple beaucoup plus de ressources de stockage (RAM/ROM) et de ressources de CPU (ou GPU) pour son traitement, qu’une séquence vidéo basse résolution (480p par exemple), ou de largeur de champ plus faible ou à 25 images/sec. La consommation électrique, et par conséquent l’autonomie du drone, dépendent directement de la sollicitation CPU/RAM/ROM. Dans le cas d’un calcul distribué entre l’application locale APP k,1 , et, l’application à exécuter par le système de calcul distant au sol APP k,2 , la consommation électrique du drone sera également fonction de la bande passante de communication entre le bord et le sol, et de la qualité du réseau, qui conditionne les moyens de communication utilisés et la puissance nécessaire pour alimenter les antennes d’émission et de réception. Si la capacité de calcul (CPU/GPU) et/ou de stockage (RAM/ROM) est suffisante pour traiter une séquence vidéo en 4K (critère 1), et si la consommation électrique est compatible des objectifs de durée de vol du Drone (critère 2), le système pourra choisir de faire effectuer en totalité les calculs de cartographie et de détection et de géo-référencement localement par l’application APP k,1 . Si la capacité de calcul (CPU/GPU) et/ou de stockage (RAM/ROM) est insuffisante pour traiter une séquence vidéo en 4K (critère 1), et si la consommation électrique est compatible des objectifs de durée de vol du drone (critère 2), le système pourra choisir de faire effectuer les calculs de cartographie et de détection et de géo-référencement localement par l’application APP k, 2 1 moyennant l’envoi des images prises localement par la caméra au dispositif sol. Si la capacité de calcul (CPU/GPU) et/ou de stockage (RAM/ROM) est suffisante pour traiter une séquence vidéo en 4K (critère 1), mais que la consommation électrique est incompatible des objectifs de durée de vol du drone (critère 2), le système pourra choisir entre plusieurs solutions : Si la consommation électrique est trop élevée du fait du traitement de la totalité des images à bord (CPU/RAM/ROM), mais que la consommation électrique pour envoyer les images au sol n’est pas trop élevée (per exemple dans le cas où le lien de communication est de bonne qualité), le système pourra choisir de faire effectuer une partie des calculs de cartographie et de détection et de géo-référencement localement par l’application APP k,1 et une autre partie par l’application APP k,2 , moyennant l’envoi d’une partie des images prises localement par la caméra au dispositif sol. Si la consommation électrique n’est pas trop élevée du fait du traitement de la totalité des images à bord (CPU/RAM/ROM), mais que la consommation électrique pour envoyer les images au sol est trop élevée (per exemple dans le cas où le lien de communication est de bonne qualité), le système pourra choisir de faire effectuer la totalité des calculs de cartographie et de détection et de géo-référencement localement par l’application APP k,1 . Il n’y aura pas d’envoi au sol des images. Si la consommation électrique est trop élevée du fait du traitement de la totalité des images à bord (CPU/RAM/ROM), et que la consommation électrique pour envoyer les images au sol est également trop élevée (per exemple dans le cas où le lien de communication est de moins bonne qualité), le système pourra choisir de passer sur une résolution d’images plus faible, ou bien de stocker les images plus longtemps, en attendant de retrouver une bande passante meilleure. Si la capacité de calcul (CPU/GPU) et/ou de stockage (RAM/ROM) est insuffisante pour traiter une séquence vidéo en 4K (critère 1), mais que la consommation électrique est compatible des objectifs de durée de vol du drone (critère 2), le système pourra choisir de faire effectuer la totalité des calculs par l’application APP k,2 , moyennant l’envoi des images prises localement par la caméra au dispositif sol. Enfin si la capacité de calcul (CPU/GPU) et/ou de stockage (RAM/ROM) est insuffisante pour traiter une séquence vidéo en 4K (critère 1), et que la consommation électrique est incompatible des objectifs de durée de vol du drone (critère 2), passer sur une résolution plus faible et réitérer les étapes ci-dessus. S’il n’y a aucune solution, même pour une résolution la plus faible possible, le système pourra désactiver l’application APP k, et enregistrer un message d’erreur à destination du sol. Les première et deuxièmes parties à exécuter respectivement en local/ en distant sont par exemple définies en termes de pourcentage de code à exécuter. Dans certains cas, la première partie est égale à 100% de l’application à exécuter, auquel cas il n’y a pas lieu de déporter une partie de l’exécution au système de calcul au sol. De préférence, les applications logicielles sont codées de manière à être exécutées par parties. Dans un mode de réalisation, tout ou partie de chaque application logicielle est préalablement mémorisé également dans la mémoire électronique 42 du système de calcul distant 8, ce qui facilité la délégation de calculs. Dans un mode de réalisation, un critère de criticité de données est mis en œuvre pour déterminer la deuxième partie APP k,2 , à exécuter au sol, permettant alors d’éviter de transmettre des données ou résultats considérés sensibles ou confidentiels au système de calcul au sol, via la deuxième interface de transmission. De telles données considérées confidentielles, et donc à protéger, sont par exemple des données relatives aux performances de l’aéronef, ou encore des données confidentielles du client propriétaire de l’application à exécuter (e.g. compagnie aérienne, institution, entreprise). En particulièrement, cela permet de limiter toute transmission de données associées à une phase de vol ou de mission critique. Dans le cas où une deuxième partie d’application logicielle est à exécuter par le système de calcul distant, le procédé comporte une requête 62 d’exécution distante, comportant la transmission d’informations associées (e.g. point d’exécution, données à utiliser, résultats intermédiaires). Dans une variante, en l’absence de stockage préalable dans une unité de mémoire électronique du système de calcul distant, le code exécutable formant la deuxième partie APP k,2 , complémentaire de la première partie, à exécuter par le système de calcul distant, est transmise au système de calcul distant lors de l’étape 62. Le système de calcul distant exécute la deuxième partie APP k,2 d’application logicielle (étape 64), et transmet les résultats des calculs au dispositif de calcul périphérique embarqué (étape 66). Le dispositif de calcul périphérique reçoit les résultats à l’étape 68. Dans un mode de réalisation, les résultats sont consolidés à l’étape de consolidation 70. Par exemple, la consolidation comporte la synchronisation temporelle et/ou spatiale des résultats, et/ou une fusion des données, par exemple une fusion des données de capteurs inertiels avec des positions calculées par un traitement logiciel à partir de données de caméras de prise de vue. Suite à cette étape de consolidation 70, les résultats consolidés sont mémorisés et/ou transmis (étape 72) au dispositif externe de commande, initiateur de l’exécution de l’application logicielle. La illustre un deuxième mode de réalisation du procédé d’exécution d’applications mis en œuvre dans le système d’exécution d’applications 2. Dans ce deuxième mode de réalisation du procédé d’exécution d’applications mis en œuvre dans le système d’exécution d’applications 2, un dispositif de supervision, qui est soit un des dispositifs de commande externe, soit le système de calcul distant au sol, met en œuvre une supervision en temps réel du fonctionnement du dispositif de calcul périphérique embarqué. De préférence, le dispositif de supervision fait partie du système de calcul distant au sol et comporte une interface homme machine, permettant l’affichage d’informations à destination d’un opérateur et la réception de commandes de l’opérateur. Dans ce mode de réalisation, outre l’ensemble des étapes décrites précédemment et qui ne sont pas re-décrites ici, le procédé comporte une supervision 80 mise en œuvre par le dispositif de supervision. La supervision 80 est effectuée en continu, le dispositif de supervision comportant une interface homme-machine et étant configuré pour recevoir des signaux d’observabilité du dispositif de calcul périphérique 20. Dans ce mode de réalisation, des signaux d’observabilité du dispositif de calcul périphérique, comprenant des données relatives aux ressources calculatoires locales et des informations relatives à l’exécution d’au moins une des applications logicielles sont transmises au dispositif de supervision. Les signaux d’observabilité incluent notamment les informations relatives à l’utilisation des ressources locales du dispositif de calcul périphérique et de la pile d’applications à exécuter/ en cours d’exécution. Le dispositif de supervision est configuré pour calculer un état de fonctionnement du dispositif de calcul périphérique et un état d’exécution de la ou de chaque application logicielle à partir des signaux d’observabilité reçus. Le dispositif de supervision met alors en œuvre par exemple des affichages sur l’interface homme machine, représentatifs de l’état de fonctionnement du dispositif de calcul périphérique (état des ressources locales, connectivité) et l’état d’exécution des applications, avec optionnellement en plus des données et résultat de ces applications. Ces affichages suivent, dans un mode de réalisation, sensiblement en temps réel, le fonctionnement du dispositif de calcul périphérique. Cela permet à un opérateur de définir des priorités d’exécution en temps réel, permettant de prioriser l’exécution de certaines applications logicielles et de mettre en basse priorité ou en pause d’autres applications logicielles, et/ou de modifier les allocations de ressources en temps réel. Des commandes relatives aux priorités d’exécution des applications logicielles et/ou de modifications de l’allocation de ressources sont alors transmises via le dispositif de supervision au dispositif de calcul périphérique embarqué. Dans un mode de réalisation, la supervision s’étend à l’ensemble des dispositifs de bord, y compris les dispositifs à fonctionnement certifiés, permettant alors une supervision globale de l’utilisation des ressources de bord. En effet, via le dispositif de calcul périphérique embarqué, des données fournies par des capteurs ou dispositifs de bord sont également transmises au dispositif de supervision pour affichage. En complément, dans l’un ou l’autre des modes de réalisation décrits ci-dessus, il est prévu d’enregistrer, par exemple dans des rapports d’exécution (e.g. fichiers, tableaux) ou toute autre structure de données approprié, dans un format adéquat, un ensemble d’informations d’état et d’exécution du dispositif de calcul périphérique et des dispositifs électroniques de bord à fonctionnement certifié, ainsi que des informations complémentaires comprenant des informations d’environnement et des informations de connectivité, sur la durée complète de la mission de l’aéronef. Par exemple l’ensemble d’informations comprend l’ensemble des états de la pile d’exécution, et des ressources calculatoires/matérielles du dispositif de calcul périphérique, par exemple les applications logicielles exécutées, la description des ressources calculatoires allouées, les données et résultats, ainsi que des informations complémentaires telles que : la situation météorologique, la disponibilité des interfaces de communication, la bande passante disponible pour les communications avec le système de calcul au sol, des données de fonctionnement interne des systèmes, la consommation en énergie prise par chaque application, et par les autres systèmes de l’aéronef, le profil de vol. Le ou les rapports d’exécution contenant cet ensemble d’informations sont transmis au dispositif de supervision au sol. Ces rapports d’exécution sont alors utilisables pour réaliser une phase de rejeu ultérieure, exécutée au sol par le dispositif de supervision. Le dispositif de supervision est configuré pour afficher ; en coopération avec des mécanismes de représentation graphique sur l’interface homme-machine, un déroulement complet de la mission (rejeu), en particulier des états successifs du dispositif de calcul périphérique et, optionnellement, des dispositifs électroniques de bord, ce qui permet des opérations de maintenance, de débogage (« debug » en anglais). Entre autres, une telle phase de rejeu permet également des recalculer les paramètres fournis à l’étape d’initialisation 50 tels l’allocation minimale, maximale ou moyenne des ressources du dispositif de calcul périphérique. Grâce au système d’exécution d’applications décrit, les ressources matérielles de bord d’un aéronef (ressources calculatoires, mémoire) sont augmentées de manière dynamique et flexible, et la mise en œuvre d’applications logicielles clientes est alors possible, tout en assurant la sécurité d’exécution. Avantageusement, un aéronef embarquant un dispositif de calcul périphérique tel que décrit est utilisable comme moyen mobile de capture de données, à l’instar des satellites. Avantageusement, l’invention permet de réaliser des calculs à algorithmie complexe, qui ne seraient pas réalisables par des dispositifs de bord certifiés du fait des limitations imposées par les certifications. Avantageusement, la flexibilité introduite par la possibilité de déporter des parties de l’exécution des applications au sol permet de s’adapter aux contraintes de l’aéronef, en particulier les contraintes de poids embarqué et de consommation d’énergie électrique. Dispositif de calcul périphérique embarqué à bord d’un aéronef, comportant une première interface de communication (22) configurée pour communiquer, selon un premier protocole de communication, avec un ou plusieurs dispositifs électroniques de bord (12, 14) à fonctionnement certifié, une deuxième interface de communication radio (24, 24A, 24B), configurée pour communiquer, selon un deuxième protocole de communication radio, avec au moins un système de calcul distant (8) situé au sol, le dispositif de calcul périphérique comportant au moins une unité de mémoire électronique (28) et au moins un processeur de calcul (26) formant des ressources calculatoires locales, caractérisé en ce que le processeur de calcul (26) est configuré pour implémenter : - un module (30) de gestion d’une pluralité d’applications logicielles (APP 1 ,APP 2 ,APP 3 ,APP i ), lesdites applications logicielles étant stockées dans ladite mémoire électronique (26), chaque application logicielle étant adaptée pour fournir au moins un paramètre de commande et/ou recevoir au moins une donnée d’au moins un dispositif électronique de bord (12, 14) à fonctionnement certifié ; - un module (32) d’activation d’exécution d’au moins une desdites applications logicielles stockées, configuré pour recevoir au moins une requête d’exécution d’au moins une application logicielle d’un dispositif externe de commande (25) et/ou pour valider une condition d’activation d’exécution d’au moins une application logicielle, - un module (34) de gestion d’une pile d’exécution, configuré pour déterminer, pour chaque application logicielle à exécuter, d’une allocation de ressources calculatoires locales dudit dispositif de calcul périphérique pour exécuter tout ou partie de ladite application logicielle à exécuter, et pour lancer l’exécution locale de ladite partie de l’application à exécuter et requérir, dans le cas où une première partie de ladite application est exécutée localement, une exécution distante, par le système de calcul distant (8), d’une deuxième partie de l’application à exécuter, complémentaire de la première partie. Dispositif selon la revendication 1, dans lequel ledit module (34) de gestion d’une pile d’exécution met en œuvre, pour la détermination de ressources calculatoires locales allouées par application à exécuter, au moins un critère parmi : un critère de disponibilité de ressources calculatoires, un critère de connectivité, un critère de protection de données, un critère de priorité. Dispositif selon l’une des revendications 1 ou 2, configuré pour recevoir dynamiquement, d’un dispositif externe de commande (25), au moins un paramètre d’allocation de ressources calculatoires et/ou de connectivité et/ou un priorité d’exécution. Dispositif selon l’une des revendications 1 à 3, comportant en outre un module (36) de gestion de données et de résultats, configuré pour consolider et mémoriser des résultats obtenus par l’exécution de chaque application logicielle, pour communiquer les résultats au dispositif externe de commande (25) et/ou au système de calcul distant (8). Dispositif selon l’une des revendications 1 à 4, dans lequel ledit module de gestion (30) d’une pluralité d’applications logicielles est configuré pour télécharger de nouvelles applications logicielles ou une mise à jour d’une application logicielle préalablement mémorisée et/ou de supprimer une application logicielle préalablement mémorisée. Système électronique d’exécution d’applications logicielles comprenant un système de calcul embarqué (4) sur un aéronef (6), et au moins un système de calcul distant (8) situé au sol, le système de calcul embarqué (4) comportant au moins un dispositif électronique de bord (12) à fonctionnement certifié selon une norme de certification avionique, et un dispositif de calcul périphérique (20) conforme aux revendications 1 à 5. Système selon la revendication 6, dans lequel le système de calcul distant comporte en outre un dispositif de supervision, le dispositif de supervision comportant une interface homme-machine et étant configuré pour recevoir des signaux d’observabilité dudit dispositif de calcul périphérique, lesdits signaux d’observabilité comprenant des données relatives aux ressources calculatoires locales et des informations relatives à l’exécution d’au moins une desdites applications logicielles, et pour calculer un état de fonctionnement dudit dispositif de calcul périphérique et un état d’exécution de ladite au moins une application logicielle à partir des signaux d’observabilité reçus et pour afficher ledit état de fonctionnement et ledit état d’exécution sur ladite interface homme machine. Système selon la revendication 7, dans lequel le dispositif de calcul périphérique est configuré pour enregistrer, durant une mission de l’aéronef, un ensemble d’informations dans au moins un rapport d’exécution, comprenant des informations d’état et d’exécution du dispositif de calcul périphérique et des dispositifs électroniques de bord à fonctionnement certifié, ainsi que des informations complémentaires comprenant des informations d’environnement et des informations de connectivité, et pour transmettre ledit rapport d’exécution au dispositif de supervision, le dispositif de supervision étant en outre configuré pour exécuter et afficher sur l’interface homme-machine un rejeu des états du dispositif de calcul périphérique et des dispositifs électroniques de bord. Procédé d’exécution d’applications logicielles mis en œuvre par un système électronique d’exécution d’applications logicielles conformes aux revendications 6 à 8, caractérisé en ce qu’il comporte des étapes de : - réception (52) de commande d’ajout/suppression d’application logicielle, en provenance d’un dispositif externe de commande, ou d’un système de calcul au sol ou d’un des dispositifs de bord ; -mise à jour (54) d’un stockage des applications logicielles en fonction de ladite commande reçue ; - activation d’exécution (56) d’une ou plusieurs des applications logicielles mémorisées, basée soit sur la réception d’une requête d’exécution d’au moins une application logicielle d’un dispositif externe, soit sur la validation d’une condition d’activation d’exécution et/ou mise en pause ou arrêt d’exécution (58) d’une ou plusieurs applications logicielles sur réception d’une commande ou validation automatique d’une condition d’arrêt. Procédé selon la revendication 9, comprenant en outre une étape de gestion (60) de pile d’applications, mettant en œuvre, pour chaque application logicielle à exécuter, une allocation de ressources calculatoires locales pour exécuter une première partie de l’application logicielle, et, dans le cas où ladite première partie est inférieure à 100%, une étape de transmission de commande d’exécution d’une deuxième partie de ladite application logicielle, complémentaire à la première partie, au système de calcul distant. Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un dispositif électronique programmable, mettent en œuvre un procédé d’exécution d’applications logicielles conforme aux revendications 9 à 10.