Brevet FR3084500A1 — publié le 20200131

Procédé et dispositif électronique d'installation d'applications logicielles avioniques sur une plateforme comprenant un processeur multicceurs, programme d'ordinateur et système électronique associés La présente invention concerne un procédé d'installation d'applications logicielles avioniques sur une plateforme destinée à être embarquée à bord d'un aéronef, la plateforme comprenant un processeur multicoeurs ayant une pluralité de coeurs distincts, le procédé d'installation étant mis en oeuvre par un dispositif électronique d'installation. L'invention concerne également un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un tel procédé. L'invention concerne également un dispositif électronique d'installation d'applications logicielles avioniques sur une plateforme destinée à être embarquée à bord d'un aéronef, la plateforme comprenant un processeur multicoeurs ayant une pluralité de coeurs distincts. L'invention concerne également un système électronique comprenant une mémoire apte à stocker des applications logicielles avioniques ; une plateforme apte à exécuter chaque application logicielle avionique, la plateforme comprenant un processeur multicoeurs ayant une pluralité de coeurs distincts ; et un tel dispositif électronique d'installation d'applications logicielles avioniques sur la plateforme. L'invention concerne le domaine de la qualification de plateformes embarquées comportant un ou plusieurs processeurs multicoeurs, en particulier dans le domaine avionique suivant la norme 00297. L'utilisation de processeurs multicceurs apporte une difficulté importante pour la qualification des plateformes. En effet, l'exécution simultanée de plusieurs applications logicielles sur un même processeur multicoeurs s'accompagne de risques de contentions à cause du partage de ressources communes (bus, mémoire) aux différents coeurs, sans que le comportement du processeur multicceurs puisse être facilement maitrisé. Le terme « contention » désigne toute situation dans laquelle au moins une activité menée par au moins un coeur d'un processeur multicceurs subit des retards dans son exécution à cause du parallélisme temporel permis par ce processeur multicceurs. L'origine des contentions est généralement l'usage de ressources communes du processeur ou du système d'exploitation, également appelé OS (de l'anglais Operating 2 System) aboutissant à des attentes générant ces retards. L'effet d'une contention est alors un retard sur l'exécution d'une application logicielle hébergée sur un coeur. Un premier exemple de contention est le bus (appelé souvent « interconnect ») reliant les coeurs les uns aux autres qui ne permet pas toujours des transactions 5 simultanées entre coeurs ou entre les coeurs et les périphériques, tels que certaines mémoires cache intégrées ou la mémoire externe. Un autre exemple de contention est l'usage de modules logiciels communs de l'OS installés sur un des coeurs et appelés par l'ensemble de coeurs, potentiellement simultanément. Des appels simultanés à de tels modules logiciels communs provoquent 10 un arbitrage et une mise en attente de certaines demandes afin de sérialiser les traitements logiciels sur le coeur où le module logiciel commun est installé. Un autre exemple de contention est une interruption momentanée de tous les coeurs sur évènement particulier sur un des coeurs afin de gérer un statut cohérent entre tous les coeurs. 15 Lorsque le processeur est en outre un processeur acheté auprès d'un fournisseur, ou processeur COTS (de l'anglais Commercial Off-The-Shelt), il est généralement impossible d'avoir accès au détail de conception des organes internes d'un tel processeur multicoeurs, et il est donc très difficile, voire impossible de garantir un comportement déterministe du processeur. 20 Selon un premier type connu d'architecture logicielle pour une plateforme avec processeur multicoeurs, également appelée architecture SMP (de l'anglais Symetrical Multi-Processing), un système d'exploitation décide à chaque instant quel traitement logiciel est exécuté sur quel coeur. Selon un deuxième type connu d'architecture logicielle pour une plateforme avec 25 processeur multicoeurs, également appelée architecture AMP (de l'anglais Asymetrical Multi-Processing), chaque coeur séquence l'exécution d'un ensemble d'applications logicielles, de manière indépendante d'un coeur à l'autre, avec un système d'exploitation par coeur. Toutefois, de telles architectures ne sont pas suffisamment robustes pour obtenir 30 la qualification de plateforrnes avec processeurs multicceurs, en particulier dans le domaine avionique suivant la norme D0297. Le but de l'invention est alors de proposer un procédé et un dispositif d'installation d'applications logicielles avioniques sur une plateforme avec processeur(s) multicoeurs, qui permettent de limiter les risques de contention lors de l'exécution desdites applications logicielles et de faciliter alors la qualification de la plateforme. 3 A cet effet, l'invention a pour objet un procédé d'installation d'applications logicielles avioniques sur une plateforme destinée à être embarquée à bord d'un aéronef, la plateforme comprenant un processeur multicoeurs ayant une pluralité de coeurs distincts, chaque application logicielle avionique comportant un ou plusieurs traitements 5 logiciels à exécuter au cours d'une période temporelle prédéfinie, la période temporelle prédéfinie comportant une ou plusieurs zones temporelles successives, le procédé d'installation étant mis en oeuvre par un dispositif électronique d'installation et comprenant l'étape suivante : - la détermination d'un plan d'installation des traitements logiciels selon au moins 10 une règle parmi une première règle d'installation et une deuxième règle d'installation, le plan d'installation définissant, pour chaque traitement logiciel, au moins un coeur et au moins une zone temporelle associés audit traitement logiciel, + la première règle d'installation consistant à prédéterminer une liste de combinaisons autorisées de niveaux de criticité pour des applications destinées à être 15 exécutées au cours d'une même zone temporelle sur la plateforme, + la deuxième règle d'installation consistant à interdire l'installation d'application(s) logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur multicoeurs. Avec le procédé d'installation selon l'invention, le respect de la première règle 20 d'installation et/ou de la deuxième règle d'installation pour déterminer le plan d'installation des traitements logiciels permet de limiter les risques de contention. En effet, avec la première règle d'installation consistant à prédéterminer une liste de combinaisons autorisées de niveaux de criticité pour des applications destinées à être exécutées au cours d'une même zone temporelle, l'installation des applications logicielles 25 avioniques sur la plateforme est optimisée en fonction de probabilités de défaillance, afin de réduire ces risques de contention. De même, la deuxième règle d'installation consistant à interdire l'installation d'application(s) logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur multicoeurs permet de créer un sanctuaire pour ces applications critiques 30 en cas de contention extrême. Le bon fonctionnement au sein du sanctuaire est, par exemple, encore amélioré par la détection de contention(s), et le cas échéant à titre de correctif en réponse cette détection de contention(s), l'arrêt progressif des applications les moins critiques sur le ou les autres coeurs. 4 Suivant d'autres aspects avantageux de l'invention, le procédé d'installation comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - pour la première règle d'installation, la probabilité que deux applications 5 logicielles ayant un même niveau de criticité donné soient défaillantes est considérée sensiblement égale à la probabilité qu'une application logicielle ayant un niveau de criticité supérieur d'une unité audit niveau de criticité donné soit défaillante ; - pour la deuxième règle d'installation, chaque application logicielle critique a un niveau de criticité correspondant à un niveau DAL défini selon la norme DO-178 révision 10 B et suivante(s), ou selon la norme ARP4754, le niveau de criticité étant de préférence égal au niveau DAL A ou au niveau DAL B, les niveaux DAL A et DAL B étant de préférence encore considérés comme les plus critiques ; 15 - lors de l'étape de détermination, le plan d'installation est déterminé selon les première et deuxième règles d'installation ; - lors de l'étape de détermination, le plan d'installation est déterminé en outre selon une troisième règle d'installation dépendant d'un temps d'exécution de pire cas du traitement logiciel respectif, ledit temps d'exécution de pire cas étant augmenté d'une 20 majoration associée à la plateforme, pour la quatrième règle d'installation, la majoration du temps d'exécution de pire cas dépendant de préférence d'un taux de contention maximal prédéfini, associé à la plateforme ; - lors de l'étape de détermination, le plan d'installation est déterminé en outre 25 selon une quatrième règle d'installation consistant à prendre en compte une marge temporelle supplémentaire pour chaque application logicielle critique, chaque application logicielle critique ayant de préférence un niveau de criticité correspondant à un niveau DAL défini selon la norme DO-178 révision B et suivante(s), ou selon la norme ARP4754, 30 le niveau de criticité étant de préférence égal au niveau DAL A ou au niveau DAL B, les niveaux DAL A et DAL B étant de préférence encore considérés comme les plus critiques ; - le procédé comprend en outre une étape de test du plan d'installation déterminé, 35 effectuée après l'étape de détermination, l'étape de test comportant une mise en oeuvre 5 simultanée d'une ou plusieurs applications logicielles avioniques et d'une ou plusieurs applications de test, au moins une application de test étant de préférence représentative de contention(s) d'intensité supérieure ou égale à un seuil de contention prédéfini ; et 5 - la plateforme héberge un unique système d'exploitation pour tous les coeurs et/ou un système d'exploitation pour chaque coeur. L'invention a également pour objet un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé d'installation tel que défini ci-dessus. 10 L'invention a également pour objet un dispositif électronique d'installation d'applications logicielles avioniques sur une plateforme destinée à être embarquée à bord d'un aéronef, la plateforme comprenant un processeur multicceurs ayant une pluralité de coeurs distincts, chaque application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter au cours d'une période temporelle prédéfinie, la période 15 temporelle prédéfinie comportant une ou plusieurs zones temporelles successives, le dispositif comprenant un module de détermination configuré pour déterminer un plan d'installation des traitements logiciels selon au moins une règle parmi une première règle d'installation et une deuxième règle d'installation, le plan d'installation définissant, pour chaque traitement logiciel, au moins un coeur et au moins une zone temporelle 20 associés audit traitement logiciel, + la première règle d'installation consistant à prédéterminer une liste de combinaisons autorisées de niveaux de criticité pour des applications destinées à être exécutées au cours d'une même zone temporelle sur la plateforme, + la deuxième règle d'installation consistant à interdire l'installation d'application(s) 25 logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur multicceurs. L'invention a également pour objet un système électronique comprenant : - une mémoire apte à stocker des applications logicielles avioniques ; - une plateforme apte à exécuter chaque application logicielle avionique, la 30 plateforme comprenant un processeur multicceurs ayant une pluralité de coeurs distincts ; et - un dispositif électronique d'installation des applications logicielles avioniques sur la plateforme, le dispositif électronique d'installation étant tel que défini ci-dessus. 6 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 : - la figure 1 est une représentation schématique d'un système électronique selon 5 l'invention, comprenant une mémoire apte à stocker des applications logicielles ; une plateforme apte à exécuter chaque application logicielle, la plateforme comportant des ressources, notamment au moins un processeur multicoeurs ayant plusieurs coeurs distincts, et hébergeant un système d'exploitation ; et un dispositif électronique d'installation d'applications logicielles avioniques sur la plateforme, chaque application 10 logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter au cours d'une période temporelle prédéfinie ; - la figure 2 est un organigramme d'un procédé, selon l'invention, d'installation d'applications logicielles avioniques sur la plateforme, le procédé étant mis en oeuvre par le dispositif d'installation de la figure 1 ; 15 - la figure 3 est une représentation schématique d'une installation d'applications logicielles avioniques sur la plateforme, équipée d'un processeur quadricceur ; - la figure 4 est une représentation schématique illustrant une règle d'installation dépendant d'un temps d'exécution de pire cas (WCET) du traitement logiciel respectif, ledit temps d'exécution de pire cas (WCET) étant augmenté d'une majoration associée à 20 la plateforme, et une autre règle d'installation consistant à interdire l'installation d'application(s) logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur multicceurs, chaque application logicielle critique ayant par exemple un niveau de criticité correspondant à un niveau DAL ; et - la figure 5 est une représentation schématique illustrant un test du plan 25 d'installation déterminé, avec la mise en oeuvre simultanée d'une application logicielle avionique sur un coeur et d'applications de test sur les trois autres coeurs du processeur quadricceur de la plateforme de la figure 3. Sur la figure 1, un système électronique 10, notamment un système électronique 30 avionique destiné à être embarqué à bord d'un aéronef, comprend une mémoire 12 apte à stocker des applications logicielles 14, une plateforme 16 apte à exécuter chaque application logicielle 14, la plateforme 16 comportant des ressources 18 et hébergeant au moins un système d'exploitation 20, la plateforme 16 étant reliée d'autres systèmes électroniques 22, tels que d'autres systèmes électroniques avioniques de l'aéronef. 35 Le système électronique 10 comprend en outre, selon l'invention, un dispositif électronique 24 d'installation d'applications logicielles avioniques 14 sur la plateforme 16. 7 Sur la figure 1, par souci de simplification du dessin, la mémoire 12 a été représentée à l'extérieur du rectangle symbolisant les ressources 18, ceci afin de faire apparaitre de manière distincte la couche logicielle correspondant aux applications logicielles 14, ainsi que le cas échéant au dispositif d'installation 24. Néanmoins, l'homme 5 du métier comprendra bien entendu que la mémoire 12 est incluse dans les ressources 18 de la plateforme 16. L'aéronef est de préférence un avion. En variante, l'aéronef est un hélicoptère, ou encore un drone piloté à distance par un pilote. Dans l'exemple de la figure 1, la mémoire 12 est apte à stocker trois applications 10 logicielles 14 distinctes, et le dispositif électronique d'installation 24 est alors configuré pour installer ces applications logicielles avioniques 14 sur la plateforme 16. Chaque application logicielle 14 est destinée à être exécutée par la plateforme 16 et alors conçue pour émettre un ou plusieurs appels à destination du système d'exploitation 20 hébergé par la plateforme 16 et est également configurée pour utiliser 15 des ressources 18 de la plateforme 16. Lorsque le système électronique 10 est un système électronique avionique embarqué à bord de l'aéronef, chaque application logicielle 14 est également appelée fonction avionique. Les applications logicielles 14 remplissent par exemple différentes fonctions pour l'accomplissement d'un vol, et sont par exemple installées sur différentes 20 plateformes 16 et utilisent les ressources 18 desdites plateformes 16. Chaque application logicielle avionique 14 comporte un ou plusieurs traitements logiciels à exécuter au cours d'une période temporelle prédéfinie, par exemple notée MIF (de l'anglais Miner Frame) à la figure 3, la période temporelle prédéfinie MIF comportant une ou plusieurs zones temporelles successives, également notées TC (de l'anglais Time 25 Cluster). Un traitement logiciel désigne un ensemble d'opérations sur des données de l'application logicielle avionique 14 permettant de réaliser des parties d'une fonction avionique, telles qu'une acquisition ou une émission de données, des calculs mathématiques, des traitements logiques, une manipulation de données. 30 Chaque traitement logiciel est également appelé processus, ou encore processus logiciel. Un traitement logiciel est par exemple un processus au sens de la norme ARINC 653. De telles fonctions étant critiques, comme par exemple le système de freinage ou le système de gestion du vol, l'exécution de chaque application logicielle 14 doit être 35 séparée de manière robuste de l'exécution des autres applications logicielles 14, pendant 8 toute leur durée d'exécution, et l'installation des applications logicielles 14 doit alors être effectuée en conséquence par le dispositif électronique d'installation 24. La plateforme 16 est notamment destinée à être embarquée à bord de l'aéronef. La plateforme 16 est, par exemple, une unité de traitement d'informations formée d'une 5 ou plusieurs mémoires associées à un ou plusieurs processeurs. L'invention est applicable à différents types d'architectures logicielles, notamment à une architecture dite de multitraitement symétrique, également appelée architecture SMP (de l'anglais Symetrical Multi-Processing), ou encore à une architecture dite de multitraitement asymétrique, également appelée architecture AMP (de l'anglais 10 Asymetrical Multi-Processing). Une architecture SMP désigne plus précisément une architecture logicielle où le système d'exploitation 20 décide à chaque instant quel processus est exécuté sur quel coeur de processeur. Dans le cas de l'architecture SMP, la plateforme 16 comprend par exemple un 15 seul système d'exploitation 20, et une seule partition est active à un instant temporel donné. Pour l'architecture SMP, la plateforme 16 héberge alors un unique système d'exploitation 20 pour tous les coeurs. Dans le cas de l'architecture SMP, l'installation d'applications logicielles 14 est, par exemple, faite en parallèle sur plusieurs coeurs. 20 Une architecture AMP désigne plus précisément une architecture logicielle où chaque coeur séquence un ensemble d'applications logicielles de manière indépendante des autres coeurs. Dans le cas de l'architecture AMP, la plateforme 16 comprend par exemple une pluralité de systèmes d'exploitation 20, en hébergeant un système d'exploitation 20 pour 25 chaque coeur, permettant alors d'activer des partitions différentes à un instant temporel donné. Dans le cas de l'architecture AMP, l'installation d'applications logicielles 14 est, par exemple, faite de manière séquentielle sur un seul coeur indépendamment des autres coeurs. 30 Les ressources 18 de la plateforme 16 sont des éléments physiques ou logiques propres à être mis à disposition de la ou des applications logicielles 14. Les ressources 18 sont, par exemple, réparties en les catégories suivantes : ressources de type traitement de données (en anglais « processing »), telles qu'un ou plusieurs processeurs ; les ressources de type mémoire ; les ressources de type entrées 35 et sorties ; ressources spécifiques au réseau avionique, telles que des routeurs de communication d'un réseau ARINC664 ; les ressources de type graphique, c'est-à-dire 9 permettant un affichage de données ; et ressources de type mémoire de masse (en anglais « mass memory »). Le système d'exploitation 20 est, par exemple, un système d'exploitation conforme à la norme ARINC 653, ou un système d'exploitation POSIX, ou encore un hyperviseur, 5 ou encore un middleware. L'homme du métier comprendra alors que le système d'exploitation 20 s'entend au sens large, et est, de manière plus générale, un ensemble d'au moins un logiciel de base, conçu pour offrir des services de différents types à chaque application 14. En complément facultatif, le dispositif électronique d'installation 24 est configuré 10 pour installer les applications logicielles avioniques 14 sur la plateforme 16 et comprend un module de détermination 30 configuré pour déterminer un plan d'installation des traitements logiciels selon au moins une règle parmi une première règle d'installation et une deuxième règle d'installation, le plan d'installation définissant, pour chaque traitement logiciel, au moins un coeur et au moins une zone temporelle TC associés audit traitement 15 logiciel. Le dispositif électronique d'installation 24 comprend un module d'installation 32 configuré pour installer les applications logicielles avioniques 14 sur la plateforme 16, selon le plan d'installation déterminé par le module de détermination 30. En complément facultatif, le dispositif électronique d'installation 24 comprend un 20 module de test 34 configuré pour tester le plan d'installation déterminé par le module de détermination 30, le module de test 34 étant adapté pour mettre en oeuvre simultanément une ou plusieurs applications logicielles avioniques et une ou plusieurs applications de test. Chaque application de test est de préférence représentative de contention(s) d'intensité supérieure ou égal à un seuil de contention prédéfini. 25 Le dispositif d'installation 24 est de préférence distinct de la plateforme 16, et comprend une unité de traitement d'informations 40 formée par exemple d'un processeur 42 associé à une mémoire 44. En variante, comme représenté sous forme de hachures sur la figure 1, le dispositif d'installation 24 est, par exemple, apte à être, au moins partiellement, de 30 préférence pour le module de détermination 30 et/ou le module d'installation 32, exécuté directement par la plateforme 16 et à utiliser alors ses ressources 18. Le dispositif d'installation 24 est alors de préférence hébergé en outre par le système d'exploitation 20. Dans l'exemple de la figure 1, que le dispositif d'installation 24 soit distinct de la plateforme 16, ou bien hébergé et exécuté par la plateforme 16, le module de 35 détermination 30, le module d'installation 32, et en complément facultatif le module de test 34, sont réalisés chacun sous forme d'un logiciel, ou d'une brique logicielle, exécutable 10 par un processeur, tel que le processeur 42 lorsque le dispositif d'installation 24 est distinct de la plateforme 16. La mémoire 44 du dispositif d'installation 24 est alors apte à stocker un logiciel de détermination du plan d'installation des traitements logiciels selon au moins une règle parmi la première règle d'installation et la deuxième règle 5 d'installation, et un logiciel d'installation des applications logicielles avioniques 14 sur la plateforme 16. En complément facultatif, la mémoire 44 du dispositif d'installation 24 est apte à stocker un logiciel de test du plan d'installation déterminé par le logiciel de détermination, le logiciel de test étant adapté pour mettre en oeuvre simultanément une ou plusieurs applications logicielles avioniques et une ou plusieurs applications de test. 10 En variante non représentée, le module de détermination 30, le module d'installation 32, et en complément facultatif le module de test 34, 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 lntegrated Circuit). 15 Lorsque le dispositif d'installation 24 est réalisé sous forme d'un ou plusieurs logiciels, c'est-à-dire en 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 adapté à mémoriser des instructions électroniques et capable d'être couplé à un bus d'un système informatique. A titre 20 d'exemple, le support lisible est une disquette ou disque souple, (de la dénomination anglaise Floppy disk), un disque optique, un CD-ROM, 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 25 instructions logicielles. Le module de détermination 30 est configuré pour déterminer le plan d'installation des traitements logiciels selon au moins une règle parmi la première règle d'installation et la deuxième règle d'installation. Le module de détermination 30 est de préférence configuré pour déterminer le 30 plan d'installation des traitements logiciels selon les première et deuxième règles d'installation à la fois. La première règle d'installation consiste à prédéterminer une liste de combinaisons autorisées de niveaux de criticité pour des applications destinées à être exécutées au cours d'une même zone temporelle TC sur la plateforme 16. 35 Chaque application logicielle avionique 14 a par exemple un niveau de criticité correspondant à un niveau DAL défini selon la norme DO-178 révision B et suivante(s), 11 ou selon la norme ARP4754. Le niveau DAL A est le niveau de criticité le plus élevé, et le niveau DAL D est le niveau de criticité le plus faible, selon l'ordonnancement suivant : DAL A > DAL B > DAL C > DAL D. Une application logicielle avionique 14 est dite critique lorsque son niveau de 5 criticité est supérieur ou égal à un seuil prédéfini, par exemple au niveau DAL B. Autrement dit, chaque application logicielle critique a un niveau de criticité de préférence égal au niveau DAL A ou au niveau DAL B, les niveaux DAL A et DAL B étant de préférence encore considérés comme les plus critiques. Dans l'exemple de la figure 4, le processeur multicoeur est un processeur 10 quadricoeur, et la partition 1 est associée à un premier coeur noté CO, la partition 2 étant associée à un deuxième coeur noté C1, la partition 3 est associée à un troisième coeur noté C2 et la partition 4 à un quatrième coeur noté C3. Dans l'exemple de la figure 4 où le troisième coeur C2 et le quatrième coeur C3 sont réservés aux applications logicielles avioniques 14 ayant un niveau de criticité égal à 15 DAL C ou à DAL D, une liste de combinaisons autorisées selon la première règle d'installation est indiquée à titre d'exemple ci-après. Dans cet exemple de la figure 4, la plateforme absorbe toute situation anormale venant d'applications pour 2 coeurs. En conséquence, les combinaisons à 3 coeurs sont toutes autorisées si elles respectent la ou les règles d'installation autres que la première 20 règle d'installation. Des restrictions apparaissent pour des configurations à 4 coeurs ou plus. Dans cet exemple, le principe suivant d'association des applications est mis en oeuvre : - la probabilité que deux applications logicielles ayant un même niveau de criticité donné soient défaillantes est de préférence considérée sensiblement égale à la 25 probabilité qu'une application logicielle ayant un niveau de criticité supérieur d'une unité audit niveau de criticité donné soit défaillante, ce qui est par exemple exprimé par B*B = A, C*C = B ou D*D = C ; et - l'association de deux applications ayant un niveau de criticité différent est équivalent à une application logicielle ayant un niveau de criticité supérieur d'une unité à 30 l'application de plus basse criticité, ce qui est par exemple exprimé par D*C = C, ou D*B = C, où chaque lettre A, B, C et D désigne respectivement le niveau de criticité DAL A, DAL B, DAL C et DAL D de l'application considérée. Selon la première règle d'installation, pour une application d'un niveau de criticité 35 donné, il faut alors que la combinaison des autres applications soit au pire de même 12 niveau de criticité, ce qui traduit l'élimination du risque que les autres applications soient défaillantes avec une probabilité inacceptable. Dans cet exemple à 4 coeurs, les combinaisons suivantes sont alors interdites : A/D/D/D car (D*D)*D = C REVENDICATIONS1. Procédé d'installation d'applications logicielles avioniques (14) sur une plateforme (16) destinée à être embarquée à bord d'un aéronef, la plateforme (16) comprenant un processeur multicceurs ayant une pluralité de coeurs distincts, chaque application logicielle avionique (14) comportant un ou plusieurs traitements logiciels à exécuter au cours d'une période temporelle prédéfinie (MIF), la période temporelle prédéfinie (MI F) comportant une ou plusieurs zones temporelles successives (TC), le procédé d'installation étant mis en oeuvre par un dispositif électronique d'installation (24) et comprenant l'étape suivante : - la détermination (100) d'un plan d'installation des traitements logiciels selon au moins une règle parmi une première régie d'installation et une deuxième règle d'installation, le plan d'installation définissant, pour chaque traitement logiciel, au moins un coeur et au moins une zone temporelle (TC) associés audit traitement logiciel, + la première règle d'installation, consistant à prédéterminer une liste de combinaisons autorisées de niveaux de criticité pour des applications destinées à être exécutées au cours d'une même zone temporelle sur la plateforme (16), + la deuxième règle d'installation consistant à interdire l'installation d'application(s) logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur rnulticoeurs. 2. Procédé selon la revendication 1, dans lequel, pour la première règle d'installation, la probabilité que deux applications logicielles ayant un même niveau de criticité donné soient défaillantes est considérée sensiblement égaie à la probabilité qu'une application logicielle ayant un niveau de criticité supérieur d'une unité audit niveau de criticité donné soit défaillante. 3. Procédé selon la revendication 1 ou 2, dans lequel, pour la deuxième règle d'installation, chaque application logicielle critique a un niveau de criticité correspondant à un niveau DAL défini selon la norme DO-178 révision B, ou selon la norme ARP4754, le niveau de criticité étant de préférence égal au niveau DAL A ou au niveau DAL les niveaux DAL A et DAL B étant de préférence ncore considérés comme les plus critiques. 19 4. Procédé selon l'une quelconque des revendications précédentes., dans lequel, lors de l'étape de détermination (100), le plan d'installation est déterminé selon les première et deuxième règles d'installation. 5 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel, lors de l'étape de détermination (100), le plan d'installation est déterminé en outre selon une troisième règle d'installation dépendant d'un temps d'exécution de pire cas (WCET_i) du traitement logiciel respectif, ledit temps d'exécution de pire cas (VVCET_i) étant augmenté d'une majoration (Maj-i) associée à la plateforrne (16), 10 pour la troisième règle d'installation, la majoration (Maj-i) du temps d'exécution de pire cas (WCET_i) dépendant de préférence d'un taux de contention maximal prédéfini, associé à la plateforme (16). 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel, 15 lors de l'étape de détermination (100), le plan d'installation est déterminé en outre selon une quatrième règle d'installation consistant à prendre en compte une marge temporelle supplémentaire (Mrg-i) pour chaque application logicielle critique, chaque application logicielle critique ayant de préférence un niveau de criticité correspondant à un niveau DAL défini selon la norme DO-178 révision B, ou selon la 20 norme ARP4754, le niveau de criticité étant de préférence égal au niveau DAL A ou au niveau DAL les niveaux DAL A et DAL B étant de préférence encore considérés comme les plus critiques. 25 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel le procédé comprend en outre une étape de test du pian d'installation déterminé, effectuée après l'étape de détermination (100), l'étape de test (110) comportant une mise en oeuvre simultanée d'une ou plusieurs applications logicielles avioniques (14) et d'une 30 ou plusieurs applications de test, au moins une application de test étant de préférence représentative de contention(s) d'intensité supérieure ou égaie à un seuil de contention prédéfini. 8. Programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles 35 sont exécutées par un ordinateur, mettent en oeuvre un procédé selon l'une quelconque des revendications précédentes. 20 9. Dispositif électronique (24) d'installation d'applications logicielles avioniques (14) sur une plateforme (16) destinée à être embarquée à bord d'un aéronef, la plateforme (16) comprenant un processeur multicceurs ayant une pluralité de coeurs 5 distincts, chaque application logicielle avionique comportant un ou plusieurs traitements logiciels à exécuter au cours d'une période temporelle prédéfinie (MIF), la période temporelle prédéfinie (MIF) comportant une ou plusieurs zones temporelles successives (TC), le dispositif (24) comprenant un module de détermination (3D) configure pour 10 déterminer un plan d'installation des traitements logiciels selon au moins une règle parmi une première règle d'installation et une deuxième règle d'installation, le plan d'installation définissant, pour chaque traitement logiciel, au moins un coeur et au moins une zone temporelle (TC) associés audit traitement logiciel, + la première règle d'installation consistant à prédéterminer une liste de 15 combinaisons autorisées de niveaux de criticité pour des applications destinées à être exécutées au cours d'une même zone temporelle sur la plateforme (16), + la deuxième règle d'installation consistant à interdire l'installation d'application(s) logicielle(s) critique(s) sur un ou plusieurs coeurs de la pluralité de coeurs du processeur multicceurs. 10. Système électronique (10) comprenant : - une mémoire (12) apte à stocker des applications logicielles (14) ; - une plateforme (16) apte à exécuter chaque application logicielle (14), la plateforme (16) comprenant un processeur multicceurs ayant une pluralité de coeurs 25 distincts ; et - un dispositif électronique (24) d'installation des applications logicielles avioniques (14) sur la plateforme (16), le dispositif électronique d'installation (24) étant selon la revendication 9.