Brevet FR3153168A1 — publié le 20250321

Procédé et dispositif électronique de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique, programme d’ordinateur et système avionique associés Ce procédé de gestion de l’exécution de services logiciels sur une plateforme avionique comportant des ressources pour l’exécution desdits services est mis en œuvre par un dispositif électronique et comprend : - acquisition (110) de données contextuelles pour un groupe de services logiciels à exécuter ; les données contextuelles comportant, pour chaque service logiciel : une quantité maximale de ressources utilisée par ledit service ; une contrainte de fonctionnement dudit service égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service doit être résistant ; - calcul (120), à partir des données contextuelles acquises, d’un contexte pour le groupe de services logiciels ; - lancement (130) de l’exécution de service/s logiciel/s du groupe suivant un jeu de règle/s de répartition des services et en fonction du contexte calculé. Figure pour l'abrégé : Figure 4 Procédé et dispositif électronique de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique, programme d’ordinateur et système avionique associés La présente invention concerne un procédé de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique destinée à être embarquée à bord d’un aéronef, la plateforme avionique comportant des ressources pour l’exécution desdits services logiciels, le procédé étant mis en œuvre par un dispositif électronique de gestion ; ainsi qu’un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettre en œuvre un tel procédé de gestion. L’invention concerne également un tel dispositif électronique de gestion de l’exécution de services logiciels d’application/s logicielle/s ; ainsi qu’un système avionique comprenant une telle plateforme avionique et un tel dispositif électronique de gestion. Les applications logicielles actuelles ne sont plus monolithiques, et sont généralement composées de nombreux composants logiciels, également appelé services logiciels, fonctionnant ensemble pour permettre un fonctionnement correct de l’application logicielle. Chaque service logiciel est généralement encapsulé dans un conteneur formant un fichier exécutable. Les services logiciels sont par exemple des services compatibles avec le système Kubernetes qui est un système en logiciel libre (de l’anglais open-source ) permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications mises en conteneurs, ces conteneurs étant appelés pods dans le système Kubernetes. Le dispositif électronique de gestion, également appelé dispositif électronique d’orchestration ou encore orchestrateur, permet alors de gérer l’exécution des services logiciels sur une plateforme informatique, telle qu’une plateforme avionique. Les orchestrateurs actuels sont généralement destinés à fonctionner dans des centres de données (de l’anglais data-centers ) comportant de multiples serveurs informatiques avec des ressources importantes, où il est possible d’ajouter des services logiciels à la demande, en mettant simplement à jour les ressources nécessaires à l’ensemble des services logiciels. Cependant, de tels orchestrateurs ne sont pas adaptés pour fonctionner correctement dans un environnement où les ressources matérielles sont limitées, notamment lorsque la plateforme est destinée à être embarquée dans un aéronef. Le but de l’invention est alors de proposer un procédé, et un dispositif électronique associé, de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique, permettant de mieux gérer l’exécution des services logiciels avec des ressources limitées et d’améliorer alors le fonctionnement de la plateforme. A cet effet, l’invention a pour objet un procédé de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique destinée à être embarquée à bord d’un aéronef, la plateforme avionique comportant des ressources pour l’exécution desdits services logiciels, le procédé étant mis en œuvre par un dispositif électronique de gestion et comprenant les étapes suivantes : - acquisition de données contextuelles pour un groupe de services logiciels à exécuter sur la plateforme avionique ; les données contextuelles comportant, pour chaque service logiciel : une quantité maximale de ressources utilisée par ledit service ; une contrainte de fonctionnement dudit service égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service doit être résistant ; - calcul, à partir des données contextuelles acquises, d’un contexte pour le groupe de services logiciels ; - lancement de l’exécution d’un ou plusieurs services logiciels du groupe suivant un jeu de règle/s de répartition des services logiciels sur la plateforme et en fonction du contexte calculé. Avec le procédé de gestion selon l’invention, le calcul du contexte à partir des données contextuelles acquises, celles-ci comportant, pour chaque service logiciel, une quantité maximale de ressources allouée au service, une indication selon laquelle le service doit être ou non résistant à une ou plusieurs pannes, et le cas échéant le nombre de panne/s auxquelles il doit être résistant, puis le lancement de l’exécution de service/s logiciel/s du groupe en fonction du contexte calculé et suivant un jeu de règle/s de répartition sur la plateforme des services logiciels, permet de répartir au mieux les ressources de la plateforme entre les services logiciels du groupe lorsque ces ressources sont limitées. En particulier, seulement certains services logiciels sont alors susceptibles d’être exécutés en veillant à ce que la somme des quantités maximales de ressources utilisées par les services exécutés ne dépasse pas la quantité disponible de ressources et/ou en donnant priorité au/x service/s devant résister à une ou plusieurs pannes. Suivant d’autres aspects avantageux de l’invention, le procédé de gestion comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - lors du calcul du contexte, un niveau de priorité est calculé respectivement pour chaque service logiciel, le niveau de priorité étant plus élevé pour un service avec contrainte de fonctionnement égale à résistance à panne/s que pour un service avec contrainte de fonctionnement égale à non-résistance à panne/s ; le niveau de priorité dépendant de préférence du nombre de panne/s auxquelles le service doit être résistant ; le niveau de priorité pour un service devant être résistant à N+1 pannes étant de préférence encore supérieur au niveau de priorité pour un service devant être résistant à N panne/s, N étant un nombre entier supérieur ou égal à 1 ; - le jeu de règle/s de répartition comporte une ou plusieurs règles parmi le groupe consistant en : une première règle selon laquelle l’exécution d’un service de niveau de priorité plus élevé est prioritaire par rapport à celle d’un service de niveau de priorité plus faible ; une deuxième règle selon laquelle la quantité disponible de ressources de la plateforme est supérieure ou égale à la somme des quantités maximales de ressources utilisées par les services logiciels exécutés ; et une troisième règle selon laquelle la quantité de ressources disponible après N panne/s est supérieure à la somme de/s quantité/s maximale/s de ressources utilisées par le/s service/s devant être résistant/s à N panne/s, N étant un nombre entier supérieur ou égal à 1 ; le jeu de règle/s de répartition comportant de préférence toutes les règles parmi le groupe précité ; - le contexte de chaque service logiciel dépend d’une phase de vol de l’aéronef, et dans lequel le procédé comprend en outre, à chaque changement de phase de vol avec mise en œuvre d’une phase de vol subséquente, le calcul d’un contexte subséquent pour la phase de vol subséquente ; le/s service/s logiciel/s exécuté/s lors de la phase de vol subséquente étant fonction du contexte subséquent calculé ; l’exécution du ou des service/s logiciel/s exécuté/s lors de la phase de vol courante et n’étant plus à exécuter lors de la phase subséquente étant alors arrêtée et l’exécution du ou des services logiciels à exécuter nouvellement lors de la phase subséquente étant lancée ; - le niveau de priorité de chaque service logiciel dépend de la phase de vol de l’aéronef, et dans lequel des niveaux subséquents de priorité des services logiciels sont calculés pour la phase de vol subséquente lors du calcul du contexte subséquent ; et le/s service/s logiciel/s exécuté/s lors de la phase de vol subséquente sont alors fonction des niveaux subséquents de priorité calculés ; - le procédé comprend en outre une étape d’arrêt de l’exécution du ou des service/s logiciel/s le/s moins prioritaire/s, si la quantité de ressources disponible est insuffisante pour le lancement de l’exécution d’un nouveau service logiciel ; - le/s service/s logiciel/s le/s moins prioritaire/s sont le/s service/s logiciel/s ayant le/s niveau/x de priorité le/s plus faible/s ; - les données contextuelles comportent en outre, pour chaque service logiciel : si la contrainte de fonctionnement dudit service est égale à non-résistance à panne/s, un taux de disponibilité dudit service ; et les services logiciels sont d’autant moins prioritaires pour leur exécution que leur taux de disponibilité est faible ; - le procédé comprend en outre, avant l’étape d’acquisition, une étape de détermination du groupe de services logiciels à exécuter, comportant la réception d’un nouveau groupe de services logiciels, la vérification du groupe reçu de services logiciels selon un jeu prédéfini de règle/s de vérification, et si le groupe reçu de services logiciels est considéré comme correct lors de cette vérification, alors il forme le groupe de services logiciels à exécuter ; le groupe de services logiciels étant inchangé sinon. L’invention concerne également un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé de gestion, tel que défini ci-dessus. L’invention concerne aussi un dispositif électronique de gestion de l’exécution de services logiciels d’application/s logicielle/s sur une plateforme avionique destinée à être embarquée à bord d’un aéronef, la plateforme avionique comportant des ressources pour l’exécution desdits services logiciels, le dispositif électronique de gestion comprenant : - un module d’acquisition configuré pour acquérir des données contextuelles pour un groupe de services logiciels à exécuter sur la plateforme avionique ; les données contextuelles comportant, pour chaque service logiciel : une quantité maximale de ressources utilisée par ledit service ; une contrainte de fonctionnement dudit service égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service doit être résistant ; - un module de calcul configuré pour calculer, à partir des données contextuelles acquises, un contexte pour le groupe de services logiciels ; - un module de lancement configuré pour lancer l’exécution d’un ou plusieurs services logiciels du groupe suivant un jeu de règle/s de répartition des services logiciels sur la plateforme et en fonction du contexte calculé. L’invention concerne également un système avionique destiné à être embarqué à bord d’un aéronef, comprenant : - une plateforme avionique comportant des ressources pour l’exécution de services logiciels d’application/s logicielle/s ; et - un dispositif électronique de gestion de l’exécution sur ladite plateforme des services logiciels d’application/s logicielle/s, le dispositif électronique de gestion étant tel que défini ci-dessus. Ces caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : FIG. 1 la FIG. 1 est une vue schématique d’un aéronef comprenant une plateforme avionique comportant des ressources pour l’exécution de services logiciels d’application/s logicielle/s ; un coffret électronique formant la plateforme avionique, le coffret comportant une carte fond de panier et plusieurs cartes électroniques connectées à la carte fond de panier ; FIG. 2 la FIG. 2 est une représentation schématique d’une architecture matérielle et logicielle de cartes électroniques du coffret de la FIG. 1 ; et FIG. 3 la FIG. 3 est une représentation schématique d’un dispositif électronique de gestion de l’exécution des services logiciels d’application/s logicielle/s sur la plateforme avionique des figures 1 et 2 ; FIG. 4 la FIG. 4 est un organigramme d’un procédé, selon l’invention, de gestion de l’exécution des services logiciels d’application/s logicielle/s, le procédé étant mis en œuvre par le dispositif électronique de gestion de la FIG. 3 . Dans la description, ainsi que dans les revendications, les termes « /s » ou « /x » suivant le nom d’un objet signifient que cela désigne un ou plusieurs objets de ce nom, et ces termes sont identiques aux termes « /s » ou « (x) », et pourront être remplacés par ceux-ci s’il en est besoin, sans que cela change le contenu de l’invention. À titre d’exemple, l’expression « d’application/s logicielle/s » signifie alors « d’une ou de plusieurs applications logicielles », l’expression « résistance à panne/s » signifie « résistance à une ou plusieurs pannes », et l’expression « au/x service/s » signifie « au service ou aux services ». Sur la FIG. 1 , un aéronef 10 comprend une plateforme avionique 20, formant de manière générale un serveur embarqué de données (de l’anglais on-board data center ), afin d’offrir différents types de services à bord de l’aéronef 10. La plateforme avionique 20 est par exemple configurée pour offrir des services de cockpit pour un équipage de l’aéronef 10 et/ou des services de maintenance pour le sol et/ou des services de divertissement pour les passagers à bord de l’aéronef 10. La plateforme avionique 20 forme, par exemple, un serveur multimédia configuré pour diffuser, via des terminaux de divertissement non représentés, des contenus multimédias aux passagers de l’aéronef 10, en particulier lors du vol (par exemple des films, des émissions de TV, des jeux ou de la musique), et/ou des informations sur le déroulement du vol (altitude, vitesse, position courante, avancement, etc.). En complément facultatif, le serveur multimédia, formé par la plateforme avionique 20, est configuré pour diffuser des informations pratiques concernant par exemple l’aéroport d’arrivée, par exemple via des annonces sous forme sonore et/ou vidéo. Chaque terminal de divertissement est connu en soi, et est relié au serveur multimédia via un réseau local, non représenté, embarqué à bord de l’aéronef 10 respectif. Chaque terminal de divertissement est par exemple fixé ou intégré dans le siège même du passager, ou bien est fixé ou intégré dans le dossier du siège se trouvant devant le siège du passager. Les sièges sont typiquement agencés en rangées au sein de l’aéronef 10. La plateforme avionique 20 comprend au moins une carte électronique de communication 22, un groupe de carte/s électronique/s de calcul 25, au moins une carte d’alimentation électrique 28, les cartes d’alimentation électrique 25 et électroniques de communication 22 et de calcul 25 étant interconnectées entre elles, par exemple via une carte fond de panier 30, comme représenté sur la FIG. 1 . La plateforme avionique 20 est par exemple réalisée sous forme d’un coffret électronique 32 comportant la carte fond de panier 30, une ou plusieurs cartes électroniques de communication 22, une ou plusieurs cartes électroniques de calcul 25 et une ou plusieurs cartes d’alimentation électrique 28. Chaque carte électronique de communication 22, chaque carte électronique de calcul 25, respectivement chaque carte d’alimentation électrique 28, est connectée à la carte fond de panier 30 via un connecteur fond de panier 34 respectif, comme représenté sur la FIG. 1 . Le coffret électronique 32 comporte en outre un boîtier de protection 36 à l’intérieur duquel sont logées la carte fond de panier 30 et la pluralité de cartes électroniques de communication 22 et de calcul 25 et de carte/s d’alimentation électrique 28 ; ainsi que des connecteurs externes 38 agencés en périphérie du boitier 36. Les connecteurs externes 38 sont notamment destinés à permettre la connexion de la plateforme avionique 20 au réseau local, ainsi qu’à un réseau d’alimentation électrique, non représentés et embarqués à bord de l’aéronef 10. Avantageusement, la plateforme avionique 20 comprend plusieurs cartes 22, 25, 28 d’un même type, à savoir plusieurs cartes électroniques de communication 22, plusieurs cartes électroniques de calcul 25 et plusieurs cartes d’alimentation électrique 28. L’homme du métier comprendra alors que le fait d’avoir plusieurs cartes 22, 25, 28 de même type permet d’améliorer la fiabilité et la disponibilité de la plateforme 20, les cartes de même type étant redondantes entre elles. En outre, le fait d’avoir un nombre élevé de cartes 22, 25, 28, en particulier de cartes électroniques de calcul 25, permet de diminuer la « granularité » de chaque carte 22, 25, 28 au sein du coffret électronique 32, et de réduire alors le coût et le besoin en termes de ressources 40 pour effectuer une redondance satisfaisante des cartes 22, 25, 28. Dans l’exemple de la FIG. 1 , la plateforme avionique 20 comprend deux cartes électroniques de communication 22, six cartes électroniques de calcul 25 et une carte d’alimentation électrique 28. En variante, la plateforme avionique 20 comprend deux cartes électroniques de communication 22, six cartes électroniques de calcul 25 et deux cartes d’alimentation électrique 28, afin d’avoir une redondance pour chaque type de carte. Chaque carte électronique de communication 22 est configurée pour communiquer avec un ou plusieurs équipements, non représentés, externes à la plateforme 20. Chaque carte électronique de communication 22 est également appelée carte d’entrée-sortie, et également notée I/O (de l’anglais Input/Output ) à la FIG. 1 . Chaque carte électronique de calcul 25, également notée C à la FIG. 1 , comporte des ressources 40 et est configurée pour l’exécution d’application/s logicielle/s. Les ressources 40, également appelées ressources matérielles, sont des éléments physiques ou logiques propres à être mis à disposition de la ou des applications logicielles. Les ressources 40 sont, par exemple, réparties en les catégories suivantes visibles à la FIG. 2 : - ressources 40A de type CPU (de l’anglais Central Processing Unit ) ; - ressources 40B de type GPU (de l’anglais Graphics Processing Unit ) ; - ressources 40C de type communication réseau, telles que ressource de type Ethernet, notées ETH sur la FIG. 2 , pour communiquer avec le réseau local embarqué d’une part, et avec un réseau de communication externe à l’aéronef 10 d’autre part, - ressources 40D de type mémoire vive, c’est-à-dire de type RAM (de l’anglais Random Access Memory ) ; et - ressources 40E de type mémoire de stockage, c’est-à-dire de type mémoire de masse (de l’anglais mass memory ), telles que ressources SSD (de l’anglais Solid State Drive ). L’homme du métier comprendra que les ressources de type CPU 40A et de type GPU 40B sont des ressources calculatoires, c’est-à-dire aptes à effectuer des opérations de calcul, les ressources de type GPU 40B étant plus dédiées à du calcul graphique et celles de type CPU 40A à du calcul général. L’homme du métier comprendra également que ces ressources de type CPU 40A et de type GPU 40B, ainsi que les autres ressources de type communication réseau 40C, de type mémoire vive 40D et de type mémoire de stockage 40E, sont réalisées sous forme d’au moins un composant électronique intégrable sur une carte de circuit imprimé, et par exemple sous forme d’un circuit intégré, tel qu’un ASIC (de l’anglais Application Specific Integrated Circuit ), ou sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais Field Programmable Gate Array ), ou sous forme d’un microcontrôleur, ou encore sous forme d’un processeur spécifique, tel qu’un processeur spécialisé en traitement du signal ou DSP (de l’anglais Digital Signal Processor ). Le type de composant électronique à utiliser préférentiellement pour réaliser chaque type de ressource parmi les types précités de ressources est connu de l’homme du métier, et n’est alors pas décrite plus en détail. Avantageusement, le groupe de carte/s électronique/s de calcul 25 comporte des ressources 40 de tous les types parmi le groupe précité. Par exemple, chaque carte électronique de calcul 25 comporte des ressources 40 de tous les types parmi le groupe précité. Autrement dit, dans cet exemple, chaque carte électronique de calcul 25 comporte à la fois des ressources 40A de type CPU, des ressources 40B de type GPU, des ressources 40C de type communication réseau, des ressources 40D de type mémoire vive et des ressources 40E de type mémoire de stockage. Le groupe de carte/s électronique/s de calcul 25 comporte plusieurs cartes électroniques de calcul 25, incluant chacune le ou les mêmes types de ressources 40. Avantageusement, les cartes électroniques du groupe de cartes électroniques de calcul 25 sont toutes identiques, c’est-à-dire inclus toutes les mêmes ressources 40A, 40B, 40C, 40D et 40E. Par exemple, chaque carte électronique de calcul 25 comporte en particulier deux ressources 40A de type CPU, une ressource 40B de type GPU, deux ressources 40C de type communication réseau, quatre ressources 40D de type mémoire vive, et deux ressources 40E de type mémoire de stockage. Sur la FIG. 2 , chaque carte électronique de calcul 25 comporte une couche matérielle 42 (de l’anglais hardware ), une couche logicielle de bas niveau 44 (de l’anglais low-level software ), une couche logicielle de niveau médian 46 (de l’anglais middleware ) et une couche logicielle de haut niveau 48 (de l’anglais high-level software ), ces quatre couches 42, 44, 46 et 48 étant superposées. Avantageusement, toutes les cartes électroniques de calcul 25 sont matériellement analogues, voire matériellement identiques, et possèdent alors la même couche matérielle 42. Avantageusement, toutes les cartes électroniques de calcul 25 possèdent les mêmes couches logicielles, c’est-à-dire respectivement la même couche bas niveau 44, la même couche niveau médian 46 et la même couche haut niveau 48. Autrement dit, la couche bas niveau 44 est unique pour le groupe de cartes électroniques de calcul 25, tout en étant stockée distinctement sur chacune des cartes électroniques de calcul 25. De même, la couche niveau médian 46 est unique pour le groupe de cartes électroniques de calcul 25, tout en étant stockée distinctement sur chacune des cartes électroniques de calcul 25. La couche haut niveau 48 est également unique pour le groupe de cartes électroniques de calcul 25, tout en étant stockée distinctement sur chacune des cartes électroniques de calcul 25. Avantageusement encore, ces couches bas niveau 44, niveau médian 46 et haut niveau 48 sont en outre assemblées en un seul et unique cluster logiciel agrégeant l’ensemble de ces ressources logicielles Chaque carte d’alimentation électrique 28, également notée P à la FIG. 1 , est configurée pour convertir une énergie électrique reçue, via un ou plusieurs connecteurs externes 38 respectifs, depuis le réseau d’alimentation électrique embarqué à bord de l’aéronef 10 en une autre énergie électrique délivrée aux cartes électroniques de communication 22 et de calcul 25. L’énergie électrique délivrée aux cartes électroniques 22, 25 est typiquement une énergie électrique continue ou énergie DC (de l’anglais Direct Current ), et chaque carte d’alimentation électrique 28 comporte alors un convertisseur alternatif-continu, ou convertisseur AC-DC (AC de l’anglais Alternative Current ), lorsque l’énergie électrique reçue depuis le réseau d’alimentation électrique embarqué est une énergie électrique alternative, ou bien un convertisseur continu-continu, ou convertisseur DC-DC, lorsque ladite énergie électrique reçue est une énergie continue. La couche matérielle 42 de chaque carte électronique de calcul 25 comporte les ressources 40, et typiquement les ressources 40A de type CPU, les ressources 40B de type GPU, les ressources 40C de type communication réseau, les ressources 40D de type mémoire vive, et les ressources 40E de type mémoire de stockage. La couche logicielle de bas niveau 44 comprend une unité 50 de chargement d’un programme d’amorçage (de l’anglais bootloader ), et une unité 52 de fourniture de services de bas niveau comportant par exemple un noyau (de l’anglais kernel ), tel qu’un noyau Linux, et un ou plusieurs pilotes logiciels (de l’anglais driver ). La couche logicielle de niveau médian 46 comprend un orchestrateur 60, un gestionnaire de conteneurs informatiques 62, un gestionnaire de fichiers 64 et un ensemble 66 de fichiers de configuration, l’orchestrateur 60, également appelé dispositif d’orchestration ou encore dispositif de gestion, étant apte à piloter un ou plusieurs services logiciels 70, dits aussi services logiciels unitaires, c’est-à-dire à gérer l’exécution de tels services logiciels 70. Le gestionnaire de conteneurs informatiques 62 de chaque carte électronique de calcul 25 est notamment configuré pour obtenir une liste des conteneurs informatiques, c’est-à-dire des ressources logicielles, présents sur la carte électronique de calcul 25 respective, afin que l’orchestrateur 60 puisse ensuite piloter leur exécution. En outre, le gestionnaire de conteneurs informatiques 62 de l’une des cartes électroniques de calcul 25 est désigné comme gestionnaire maître parmi les gestionnaires 62 des différentes cartes électroniques de calcul 25, chaque gestionnaire 62 de la ou des autres cartes électroniques de calcul 25 étant alors esclave. Le gestionnaire maître de conteneurs informatiques 62 est alors configuré en outre pour obtenir, via chaque gestionnaire esclave 62, une liste des conteneurs informatiques de chaque autre carte de calcul 25, puis pour générer une liste des conteneurs informatiques de toutes les cartes électroniques calcul 25, c’est-à-dire une liste de l’ensemble des ressources logicielles formant le cluster logiciel décrit précédemment. La couche logicielle de haut niveau 48 comprend lesdits services logiciels 70. Lorsque la plateforme avionique 20 forme un serveur de services de cockpit, les services logiciels 70 correspondent par exemple à un service de système non-avionique de type sac de vol électronique ou EFB (de l’anglais Electronic Flight Bag ), déporté accessible par un pilote au travers d’une simple navigateur web, ou encore à un service agrégeant des données météorologiques pour proposer des trajectoires alternatives moins génératrices de trainées de condensation. Lorsque la plateforme avionique 20 forme un serveur de services de maintenance, les services logiciels 70 correspondent par exemple à un service embarqué de maintenance prédictive, ou à des services de « health monitoring » permettant de détecter des seuils critiques dans le fonctionnement des systèmes avions. Lorsque la plateforme avionique 20 forme un serveur de services de divertissement, c’est-à-dire le serveur multimédia, les services logiciels 70 correspondent par exemple aux services proposés aux passagers de l’aéronef 10 : vidéo à la demande ou VOD (de l’anglais Video On Demand ), audio à la demande ou AOD (de l’anglais Audio On Demand ), jeux, paramètres du vol (altitude, vitesse, etc.) et de son avancement (par exemple à l’aide d’une « moving map »), annonces audio et/ou vidéo de l’équipage, etc. Selon l’invention, le dispositif électronique de gestion 60 comprend un module 80 d’acquisition de données contextuelles pour un groupe de services logiciels 70, un module 82 de calcul d’un contexte à partir des données contextuelles acquises et pour le groupe de services logiciels 70 et un module 84 de lancement de l’exécution de service/s logiciel/s 70 du groupe suivant un jeu de règle/s de répartition et en fonction du contexte calculé. En complément, le dispositif électronique de gestion 60 comprend un module 86 d’arrêt de l’exécution de service/s logiciel/s 70 le/s moins prioritaire/s et/ou un module 88 de détermination du groupe de services logiciels à exécuter, préalablement à l’acquisition de données contextuelles pour ledit groupe. Dans l’exemple de la FIG. 3 représentant le dispositif électronique de gestion 60 de manière générale, le dispositif électronique de gestion 60 comprend une unité de traitement d’informations 90 formée par exemple d’une mémoire 92 et d’un processeur 94. Dans l’exemple de la FIG. 3 , le module d’acquisition 80, le module de calcul 82 et le module de lancement 84, ainsi qu’en complément facultatif le module d’arrêt 86 et le module de détermination 88, sont réalisés chacun sous forme d’un logiciel, ou d’une brique logicielle, exécutable par le processeur 94. La mémoire 92 du dispositif de gestion 60 est alors apte à stocker un logiciel d’acquisition, un logiciel de calcul, et un logiciel de lancement, ainsi qu’en complément facultatif un logiciel d’arrêt et un logiciel de détermination. Le processeur 94 est alors apte à exécuter chacun des logiciels parmi le logiciel d’acquisition, le logiciel de calcul et le logiciel de lancement, ainsi qu’en complément facultatif le logiciel d’arrêt et le logiciel de détermination. En variante non représentée, le module d’acquisition 80, le module de calcul 82 et le module de lancement 84, ainsi qu’en complément facultatif le module d’arrêt 86 et le module de détermination 88, sont réalisés chacun sous forme d’un composant logique programmable, tel qu’un FPGA (de l’anglais Field Programmable Gate Array ), ou encore sous forme d’un circuit intégré dédié, tel qu’un ASIC (de l’anglais Application Specific Integrated Circuit ). Lorsque le dispositif électronique de gestion 60 est réalisé sous forme d’un ou plusieurs logiciels, c’est-à-dire sous forme d’un programme d’ordinateur, il est en outre apte à être enregistré sur un support, non représenté, lisible par ordinateur. Le support lisible par ordinateur est par exemple, un médium apte à mémoriser des 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. Sur le support lisible est alors mémorisé un programme d’ordinateur comprenant des instructions logicielles. Dans l’exemple de la FIG. 2 , l’homme du métier comprendra que le dispositif de gestion 60, également appelé orchestrateur 60, utilise pour sa mise en œuvre des ressources 40 de la carte électronique de calcul 25 sur laquelle il est installé. Dans cet exemple, l’orchestrateur 60 est alors configuré pour acquérir les données contextuelles pour le groupe de services logiciels 70, puis pour calculer le contexte à partir des données contextuelles acquises et pour le groupe de services logiciels 70, et enfin pour lancer l’exécution de service/s logiciel/s 70 du groupe suivant le jeu de règle/s de répartition et en fonction du contexte calculé. En complément, l’orchestrateur 60 est également configuré pour arrêter l’exécution de service/s logiciel/s 70 le/s moins prioritaire/s et/ou pour déterminer le groupe de services logiciels à exécuter, préalablement à l’acquisition de données contextuelles pour ledit groupe. Le module d’acquisition 80 est configuré pour acquérir des données contextuelles pour un groupe de services logiciels 70 à exécuter sur la plateforme avionique 20. Le module d’acquisition 80 est par exemple configuré pour acquérir lesdites données contextuelles à partir d’une première base de données 96, également appelée base de données contextuelles. Les données contextuelles comportent par exemple, pour chaque service logiciel 70 : une quantité maximale de ressources 40 utilisée par ledit service 70 ; une contrainte de fonctionnement dudit service 70 égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service 70 est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service 70 doit être résistant. En complément, les données contextuelles comportent, si la contrainte de fonctionnement d’un service 70 respectif est égale à non-résistance à panne/s, un taux de disponibilité requis pour ledit service 70. Le taux de disponibilité d’un service est généralement exprimé en pourcentage du temps pendant lequel ce service est opérationnel. En complément, les données contextuelles comportent des données plus globales relatives à un état des cartes électroniques de calcul 25, avec par exemple, pour chaque carte de calcul 25, un état en panne ou un état partiellement inutilisable le cas échéant. Lorsqu’une carte de calcul 25 est dans un état normal de fonctionnement, cela n’est pas nécessairement mentionné dans les données contextuelles, étant donné que la carte de calcul 25 respective est alors dans son état nominal. En complément encore, les données contextuelles comportent des données relatives à des conditions opérationnelles propres à l’aéronef 10, telle qu’une indication d’une phase de vol courante de l’aéronef 10, et/ou telle qu’un état de chaque système avionique embarqué à bord de l’aéronef 10, avec notamment, pour chaque système avionique, un état en panne le cas échéant. Là encore, lorsque le système avionique est dans un état normal de fonctionnement, cela n’est pas nécessairement mentionné dans les données contextuelles, étant donné que le système avionique respectif est alors dans son état nominal. Le module de calcul 82 est configuré pour calculer, à partir des données contextuelles acquises, un contexte pour le groupe de services logiciels 70. Le contexte est par exemple une priorisation des services logiciels 70 les uns par rapport aux autres, et le module de calcul 82 est alors configuré pour calculer un niveau de priorité respectivement pour chaque service logiciel 70, ceci à partir des données contextuelles acquises. Le niveau de priorité est par exemple plus élevé pour un service 70 avec contrainte de fonctionnement égale à résistance à panne/s que pour un service 70 avec contrainte de fonctionnement égale à non-résistance à panne/s. Autrement dit, selon cet exemple, le niveau de priorité est plus élevé pour un service devant résister à une ou plusieurs pannes, c’est-à-dire ayant une garantie de résistance à une ou plusieurs pannes, que pour un service ne devant pas résister à une ou plusieurs pannes, c’est-à-dire n’ayant pas de garantie de résistance à une ou plusieurs pannes. En complément de cet exemple, pour un service logiciel 70 avec contrainte de fonctionnement égale à résistance à panne/s, le niveau de priorité dépend en outre du nombre de panne/s auxquelles le service 70 doit être résistant. Avantageusement, le niveau de priorité pour un service 70 devant être résistant à N+1 pannes est supérieur au niveau de priorité pour un service 70 devant être résistant à N panne/s, N étant un nombre entier supérieur ou égal à 1. En complément encore, le module de calcul 82 est configuré pour calculer le niveau de priorité de chaque service logiciel 70 en fonction d’une phase de vol de l’aéronef 10, incluse dans les données contextuelles, et pour calculer alors le niveau de priorité de chaque service logiciel à chaque changement de phase de vol, le niveau de priorité étant susceptible de varier d’une phase de vol à l’autre. Les phases de vols sont typiquement les suivantes : parking (l’aéronef 10 est garé), roulage, décollage, montée, croisière, descente, atterrissage. À titre d’exemple, un service logiciel 70 de chargement d’un plan de vol est indispensable quand l’aéronef 10 est en phase de vol égale à parking, pour que l’aéronef 10 puisse ensuite effectuer le vol, et le niveau de priorité de ce service logiciel 70 est alors plus élevé dans la phase parking que dans les autres phases de vol. Inversement, d’autres services logiciels 70 présentent un niveau de priorité plus élevé pour les phases de vol égales à décollage, montée, croisière, descente et atterrissage, que pour la phase de vol égale à parking. Par exemple, les services de divertissement, également appelés services IFE (de l’anglais In-Flight Entertainment ) ont un niveau de priorité élevé en croisière. Lorsqu’en complément le module de calcul 82 est configuré pour calculer le niveau de priorité de chaque service logiciel 70 en fonction à la fois d’une phase de vol de l’aéronef 10 et une résistance à N panne/s, le niveau de priorité est calculé prioritairement en fonction de la phase de vol, puis secondairement en fonction de la résistance à N panne/s. Selon ce complément, le niveau de priorité de chaque service logiciel 70 est typiquement calculé d’abord suivant différentes plages de valeur (par exemple de 100 en 100) dépendant de la phase de vol formant le contexte ; puis à l’intérieur de chaque plage de valeurs, le niveau de priorité est affiné suivant la résistance à N panne/s requise. En complément encore, lorsque les données contextuelles comportent en outre, pour chaque service logiciel 70 ayant une contrainte de fonctionnement égale à non-résistance à panne/s, un taux respectif de disponibilité dudit service 70, le module de calcul 82 est configuré pour calculer le niveau de priorité de chaque service logiciel 70 en fonction en outre dudit taux de disponibilité. Selon ce complément, le niveau de priorité est par exemple d’autant plus élevé que le taux de disponibilité est élevé. Autrement dit, les services logiciels 70 sont d’autant moins prioritaires pour leur exécution que leur taux de disponibilité est faible. Le module de lancement 84 est configuré pour lancer l’exécution d’un ou plusieurs services logiciels 70 du groupe suivant le jeu de règle/s de répartition des services logiciels 70 sur la plateforme 20 et en fonction du contexte calculé. Le jeu de règle/s de répartition comporte typiquement une ou plusieurs règles parmi le groupe consistant en : - une première règle selon laquelle l’exécution d’un service 70 de niveau de priorité plus élevé est prioritaire par rapport à celle d’un service 70 de niveau de priorité plus faible ; - une deuxième règle selon laquelle la quantité disponible de ressources 40 de la plateforme 20 est supérieure ou égale à la somme des quantités maximales de ressources 40 utilisées par les services logiciels 70 exécutés ; et - une troisième règle selon laquelle la quantité de ressources 40 disponible après N panne/s est supérieure à la somme de/s quantité/s maximale/s de ressources 40 utilisées par le/s service/s 70 devant être résistant/s à N panne/s, N étant un nombre entier supérieur ou égal à 1. Avantageusement, le jeu de règle/s de répartition comporte toutes les règles parmi le groupe précité, c’est-à-dire comporte les première, deuxième et troisième règles. Le module d’arrêt 86 est configuré pour arrêter l’exécution du ou des services logiciels les moins prioritaires si la quantité disponible de ressources 40 est insuffisante pour le lancement de l’exécution d’un nouveau service logiciel 70. Le ou les services logiciels 70 moins prioritaire sont ceux ayant le ou les niveaux de priorité les plus faibles. Pour la répartition des services logiciels parmi les ressources 40 de la plateforme avionique 20, en particulier parmi les ressources 40 des différentes cartes électroniques de calcul 25, le module de lancement 84 est alors par exemple configuré pour lancer l’exécution des services logiciels 70 tant qu’il y a suffisamment de ressources disponibles, et en lançant préférentiellement l’exécution des services logiciels 70 par ordre décroissant des niveaux de priorité, c’est-à-dire en lançant d’abord l’exécution des services logiciels 70 les plus prioritaires. Ensuite, s’il n’y a plus de ressource 40 disponible pour lancer l’exécution d’un nouveau service logiciel 70, alors le module d’arrêt 86 est configuré pour arrêter l’exécution du ou des services logiciels 70 les moins prioritaires, c’est-à-dire par ordre croissant des niveaux de priorité, ceci jusqu’à ce qu’il y ait à nouveau suffisamment de ressources 40 disponibles pour l’exécution du ou des nouveaux services logiciels 70, c’est-à-dire pour récupérer suffisamment de ressources 40 pour pouvoir exécuter le ou les nouveaux services logiciels 70, tout en respectant la hiérarchie de niveaux de priorité entre les nouveaux services logiciels 70 à exécuter et les services logiciels 70 en cours d’exécution. Autrement dit, la nécessité de lancer l’exécution d’un nouveau service logiciel 70 entraîne l’arrêt de l’exécution d’un service logiciel 70 en cours d’exécution seulement si le nouveau service logiciel 70 à exécuter est de niveau de priorité plus élevé que celui du service logiciel 70 en cours d’exécution. En complément facultatif, le module de détermination 88 est configuré pour déterminer le groupe de services logiciels 70 à exécuter, en particulier pour vérifier un nouveau groupe de services logiciels 70 à exécuter avant que les services logiciels 70 dudit nouveau groupe puissent être lancés par le module de lancement 84. Selon ce complément facultatif, le module de détermination 88 est par exemple configuré pour recevoir un nouveau groupe de services logiciels 70, par exemple depuis une deuxième base de données 98, également appelée base de services logiciels ; puis pour vérifier le groupe reçu de services logiciels 70 selon un jeu prédéfini de règle/s de vérification, et enfin pour remplacer le groupe courant de services logiciels 70 par le nouveau groupe reçu de services logiciels 70 s’il est considéré comme correct suite à cette vérification ; le groupe courant de services logiciels 70 étant maintenu sinon, c’est-à-dire si le nouveau groupe reçu est considéré comme incorrect suite à cette vérification. Le module de détermination 88 est typiquement configuré pour vérifier le nouveau groupe reçu de services logiciels 70 à partir d’un ensemble d’exigences. L’ensemble des exigences comporte, pour chaque contexte et chaque service logiciel 70, une exigence de fonctionnement, tel qu’un taux de disponibilité supérieur à un taux minimal prédéfini (par exemple 95 %) pour le contexte considéré. Le contexte dépend typiquement de l’état des ressources 40 et de conditions opérationnelles propres à l’aéronef 10. L’état des ressources est par exemple évalué pour chaque ressource 40 avec une valeur choisie parmi en panne, partiellement inutilisable, et disponible. Les conditions opérationnelles propres à l’aéronef 10 sont définies d’une part par la phase de vol, et d’autre part par l’état des systèmes avioniques, l’état de chaque système avionique ayant typiquement une valeur choisie parmi en panne et opérationnelle. Le contexte est alors par exemple exprimé sous forme d’un triplet incluant un nombre de ressource/s 40 en panne, la phase de vol concernée, et une indication de panne/s éventuelle/s de système avionique. Un contexte défini sous forme du triplet (0, croisière, panne système hydraulique) signifie alors que la plateforme avionique 20 est totalement opérationnelle (aucune ressource 40 en panne), que l’aéronef 10 est en phase de vol égale à croisière, et qu’il y a une panne du système hydraulique. Le module de détermination 88 est alors avantageusement configuré pour effectuer la vérification du nouveau groupe reçu de services logiciels 70 à partir de l’ensemble des exigences et via des modèles statistiques, ou encore via des simulations de type Monte-Carlo. Le fonctionnement de la plateforme avionique 20, et en particulier du dispositif électronique de gestion 60, ou orchestrateur 60, va désormais être expliqué, notamment à l’aide de la FIG. 4 représentant un organigramme du procédé, selon l’invention, de gestion de l’exécution de services logiciels 70, le procédé étant mis en œuvre par le dispositif de gestion 60. Lors d’une étape initiale 100 optionnelle, le dispositif de gestion 60 détermine, via son module de détermination 88, le groupe de services logiciels 70 à exécuter, et en particulier vérifie si un nouveau groupe de services logiciels 70 reçus depuis la deuxième base de données 98 est correct et peut alors remplacer le groupe courant de services logiciels 70. Lors de cette étape de détermination 100, le module de détermination 88 reçoit alors le nouveau groupe de services logiciels 70, puis le vérifie selon le jeu de règle/s de vérification, et le substitue au groupe courant de services logiciels 70 si le nouveau groupe est correct. Inversement, si le nouveau groupe est incorrect au regard du jeu de règle/s de vérification, alors le module de détermination 88 l’écarte et conserve le groupe courant de services logiciels 70. L’homme du métier comprendra que le groupe courant de services logiciels 70 est un groupe prédéfini de services logiciels 70 supposé correct ou bien un groupe de services logiciels 70 déterminé précédemment, c’est-à-dire ayant été précédemment vérifié selon le jeu de règle/s de vérification, puis ayant été considéré comme correct et ayant alors remplacé un précédent groupe de services logiciels 70. Lors de l’étape suivante 110, le dispositif de gestion 60 acquiert, via son module d’acquisition 80, les données contextuelles pour le groupe de services logiciels 70 à exécuter sur la plateforme avionique 20, et par exemple pour le groupe déterminé lors de l’étape optionnelle de détermination 100 précédente. Lors d’une étape subséquente 120 de calcul, le dispositif de gestion 60 calcule, via son module de calcul 84, le contexte pour le groupe de services logiciels 70 à partir des données contextuelles acquises lors de l’étape d’acquisition 110 précédente. Lors de cette étape de calcul 120, le module de calcul 84 calcule typiquement le niveau de priorité pour chaque service logiciel 70, tout d’abord selon que la contrainte de fonctionnement pour ledit service 70 est égale ou non à résistance à panne/s, puis en fonction du nombre N de panne/s auxquelles ledit service 70 doit être résistant lorsque la contrainte de fonctionnement est égale à résistance à panne/s, ou en fonction du taux de disponibilité requis pour ledit service 70 lorsque la contrainte de fonctionnement est égale à non-résistance à panne/s. En complément, le niveau de priorité de chaque service logiciel 70 dépend de la phase de vol de l’aéronef 10, le module de calcul 84 calcule alors le niveau de priorité pour chaque service logiciel 70 en fonction en outre de la phase de vol de l’aéronef 10. À l’issue de l’étape de calcul 120, le dispositif de gestion 60 lance, via son module de lancement 86 et lors d’une étape suivante 130, l’exécution sur la plateforme avionique 20 d’un ou plusieurs services logiciels 70 du groupe, comme représenté par les flèches F1 à la FIG. 3 , ceci en fonction du contexte calculé lors de l’étape de calcul 120 précédente et suivant le jeu de règle/s de répartition. Lors de cette étape de lancement 130, le module de lancement 86 tient typiquement compte d’une ou de plusieurs des premières, deuxième et troisième règles de répartition, et de préférence de chacune des premières, deuxième et troisième règles de répartition, pour définir le ou les services logiciels 70 dont l’exécution est à lancer. Le module de lancement 86 lance par exemple l’exécution des services logiciels 70 du groupe courant tant qu’il y a suffisamment de ressources disponibles, et en ordonnant ces lancements d’exécution depuis les services logiciels 70 les plus prioritaires jusqu’aux services logiciels 70 les moins prioritaires, c’est-à-dire en commençant par les services logiciels 70 ayant les niveaux de priorité les plus élevés, puis en finissant par ceux ayant les niveaux de priorité les plus faibles. À l’issue de l’étape de lancement 130, s’il n’y a plus de ressource 40 disponible pour lancer l’exécution d’un nouveau service logiciel 70, le dispositif de gestion 60 arrête, lors d’une étape suivante 140 et via son module d’arrêt 86, l’exécution d’un ou de plusieurs services logiciels 70, comme représenté par les flèches F2 à la FIG. 3 , avantageusement du ou des services logiciels 70 les moins prioritaires, jusqu’à libérer suffisamment de ressources 40 pour pouvoir exécuter le ou les nouveaux services logiciels 70 devant l’être. Lors de cette étape d’arrêt 140, l’arrêt de l’exécution de service/s logiciel/s 70 est préférentiellement effectué par ordre croissant des niveaux de priorité des services logiciels 70 en cours d’exécution, et en comparant les niveaux de priorité des services logiciels 70 en cours d’exécution avec les niveaux de priorité des nouveaux services logiciels 70 à exécuter, l’exécution d’un service logiciel 70 en cours d’exécution étant arrêtée seulement si le nouveau service logiciel 70 à exécuter est de niveau de priorité plus élevé que celui du service logiciel 70 en cours d’exécution. À l’issue de l’étape d’arrêt 140, le dispositif de gestion 60 retourne à l’étape de détermination 100 si un nouveau groupe de services logiciels 70 a été reçu, ou à l’étape d’acquisition 110 pour acquérir de nouvelles données contextuelles, ou encore à l’étape de calcul 120 pour calculer à nouveau le contexte pour le groupe de services logiciels 70, par exemple en cas de changement de phase de vol. En complément facultatif, le contexte calculé de chaque service logiciel 70 dépend de la phase de vol de l’aéronef 10, et le module de calcul 84 calcule alors le contexte pour le groupe de services logiciels 70 à chaque changement de phase de vol, d’une phase de vol courante à une phase de vol subséquente, et calcule alors un contexte subséquent pour la phase de vol subséquente. Selon ce complément facultatif, le/s service/s logiciel/s 70 exécuté/s lors de la phase de vol subséquente sont alors fonction du contexte subséquent calculé. L’exécution du ou des services logiciels 70 à exécuter nouvellement lors de la phase subséquente est ensuite lancée lors de la prochaine étape de lancement 130. L’exécution du ou des service/s logiciel/s 70 exécuté/s lors de la phase de vol courante et n’étant plus à exécuter lors de la phase subséquente est arrêtée lors de la prochaine étape d’arrêt 140. Le procédé de gestion de l’exécution de services logiciels 70 et le dispositif électronique de gestion 60 selon l’invention permettent alors de répartir au mieux les ressources 40 limitées de la plateforme avionique 20 entre les services logiciels 70, ceci en fonction du contexte calculé à partir des données contextuelles. Ces données contextuelles comportent notamment, pour chaque service logiciel, une quantité maximale de ressources allouée au service, une indication selon laquelle le service doit être ou non résistant à une ou plusieurs pannes, et le cas échéant le nombre de panne/s auxquelles il doit être résistant et/ou un taux de disponibilité requis ; et la répartition de ces ressources 40 limitées privilégie alors les services logiciels 70 devant être les plus résistants aux pannes, et à défaut devant offrir le taux de disponibilité le plus élevé. Avantageusement, la phase de vol de l’aéronef 10 est prise en compte, ce qui permet de définir une résistance à panne/s et/ou un taux de disponibilité pour chaque service logiciel 70 en fonction de la phase de vol, et d’optimiser alors la répartition des ressources également en fonction de la phase de vol. Ce faisant, la priorisation des services logiciels 70 varie d’une phase de vol à l’autre. On conçoit ainsi que le procédé de gestion et le dispositif de gestion 60 selon l’invention permettent de mieux gérer l’exécution des services logiciels 70 avec des ressources 40 limitées, et d’améliorer alors le fonctionnement de la plateforme avionique 20. Procédé de gestion de l’exécution de services logiciels (70) d’application/s logicielle/s sur une plateforme avionique (20) destinée à être embarquée à bord d’un aéronef (10), la plateforme avionique (20) comportant des ressources (40) pour l’exécution desdits services logiciels (70), le procédé étant mis en œuvre par un dispositif électronique de gestion (60) et comprenant les étapes suivantes : - acquisition (110) de données contextuelles pour un groupe de services logiciels (70) à exécuter sur la plateforme avionique (20) ; les données contextuelles comportant, pour chaque service logiciel (70) : une quantité maximale de ressources (40) utilisée par ledit service (70) ; une contrainte de fonctionnement dudit service (70) égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service (70) est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service (70) doit être résistant ; - calcul (120), à partir des données contextuelles acquises, d’un contexte pour le groupe de services logiciels (70) ; - lancement (130) de l’exécution d’un ou plusieurs services logiciels (70) du groupe suivant un jeu de règle/s de répartition des services logiciels (70) sur la plateforme (20) et en fonction du contexte calculé. Procédé selon la revendication 1, dans lequel, lors du calcul (120) du contexte, un niveau de priorité est calculé respectivement pour chaque service logiciel (70), le niveau de priorité étant plus élevé pour un service (70) avec contrainte de fonctionnement égale à résistance à panne/s que pour un service (70) avec contrainte de fonctionnement égale à non-résistance à panne/s ; le niveau de priorité dépendant de préférence du nombre de panne/s auxquelles le service (70) doit être résistant ; le niveau de priorité pour un service (70) devant être résistant à N+1 pannes étant de préférence encore supérieur au niveau de priorité pour un service (70) devant être résistant à N panne/s, N étant un nombre entier supérieur ou égal à 1. Procédé selon la revendication 2, dans lequel le jeu de règle/s de répartition comporte une ou plusieurs règles parmi le groupe consistant en : une première règle selon laquelle l’exécution d’un service (70) de niveau de priorité plus élevé est prioritaire par rapport à celle d’un service (70) de niveau de priorité plus faible ; une deuxième règle selon laquelle la quantité disponible de ressources (40) de la plateforme (20) est supérieure ou égale à la somme des quantités maximales de ressources (40) utilisées par les services logiciels (70) exécutés ; et une troisième règle selon laquelle la quantité de ressources (40) disponible après N panne/s est supérieure à la somme de/s quantité/s maximale/s de ressources (40) utilisées par le/s service/s (70) devant être résistant/s à N panne/s, N étant un nombre entier supérieur ou égal à 1 ; le jeu de règle/s de répartition comportant de préférence toutes les règles parmi le groupe précité. Procédé selon l’une quelconque des revendications précédentes, dans lequel le contexte de chaque service logiciel (70) dépend d’une phase de vol de l’aéronef (10), et dans lequel le procédé comprend en outre, à chaque changement de phase de vol avec mise en œuvre d’une phase de vol subséquente, le calcul (120) d’un contexte subséquent pour la phase de vol subséquente ; le/s service/s logiciel/s (70) exécuté/s lors de la phase de vol subséquente étant fonction du contexte subséquent calculé ; l’exécution du ou des service/s logiciel/s (70) exécuté/s lors de la phase de vol courante et n’étant plus à exécuter lors de la phase subséquente étant alors arrêtée et l’exécution du ou des services logiciels (70) à exécuter nouvellement lors de la phase subséquente étant lancée. Procédé selon les revendications 2 et 4, dans lequel le niveau de priorité de chaque service logiciel (70) dépend de la phase de vol de l’aéronef (10), et dans lequel des niveaux subséquents de priorité des services logiciels (70) sont calculés pour la phase de vol subséquente lors du calcul du contexte subséquent ; et le/s service/s logiciel/s (70) exécuté/s lors de la phase de vol subséquente sont alors fonction des niveaux subséquents de priorité calculés. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre une étape d’arrêt (140) de l’exécution du ou des service/s logiciel/s (70) le/s moins prioritaire/s, si la quantité de ressources (40) disponible est insuffisante pour le lancement de l’exécution d’un nouveau service logiciel (70). Procédé selon les revendications 2 et 6, dans lequel le/s service/s logiciel/s (70) le/s moins prioritaire/s sont le/s service/s logiciel/s (70) ayant le/s niveau/x de priorité le/s plus faible/s. Procédé selon l’une quelconque des revendications précédentes, dans lequel les données contextuelles comportent en outre, pour chaque service logiciel (70) : si la contrainte de fonctionnement dudit service (70) est égale à non-résistance à panne/s, un taux de disponibilité dudit service (70) ; et les services logiciels (70) sont d’autant moins prioritaires pour leur exécution que leur taux de disponibilité est faible. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre, avant l’étape d’acquisition (110), une étape de détermination (100) du groupe de services logiciels (70) à exécuter, comportant la réception d’un nouveau groupe de services logiciels (70), la vérification du groupe reçu de services logiciels (70) selon un jeu prédéfini de règle/s de vérification, et si le groupe reçu de services logiciels (70) est considéré comme correct lors de cette vérification, alors il forme le groupe de services logiciels (70) à exécuter ; le groupe de services logiciels (70) étant inchangé sinon. Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes. Dispositif électronique (60) de gestion de l’exécution de services logiciels (70) d’application/s logicielle/s sur une plateforme avionique (20) destinée à être embarquée à bord d’un aéronef (10), la plateforme avionique (20) comportant des ressources (40) pour l’exécution desdits services logiciels (70), le dispositif électronique de gestion (60) comprenant : - un module d’acquisition (80) configuré pour acquérir des données contextuelles pour un groupe de services logiciels (70) à exécuter sur la plateforme avionique (20) ; les données contextuelles comportant, pour chaque service logiciel (70) : une quantité maximale de ressources (40) utilisée par ledit service (70) ; une contrainte de fonctionnement dudit service (70) égale à résistance à panne/s ou non-résistance à panne/s ; et si la contrainte de fonctionnement dudit service (70) est égale à résistance à panne/s, un nombre de panne/s auxquelles ledit service (70) doit être résistant ; - un module de calcul (82) configuré pour calculer, à partir des données contextuelles acquises, un contexte pour le groupe de services logiciels (70) ; - un module de lancement (84) configuré pour lancer l’exécution d’un ou plusieurs services logiciels (70) du groupe suivant un jeu de règle/s de répartition des services logiciels (70) sur la plateforme (20) et en fonction du contexte calculé. Système avionique destiné à être embarqué à bord d’un aéronef (10), comprenant : - une plateforme avionique (20) comportant des ressources (40) pour l’exécution de services logiciels (70) d’application/s logicielle/s ; et - un dispositif électronique de gestion de l’exécution sur ladite plateforme (20) des services logiciels (70) d’application/s logicielle/s, caractérisé en ce que le dispositif électronique de gestion est selon la revendication précédente.