FR 3072198 A1 20190412 FR 1701054 A 20171011 Procédé et dispositif électronique d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur une plateforme comprenant un processeur multi-coeurs, programme d'ordinateur et système électronique associés La présente invention concerne un procédé d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur une plateforme comprenant un processeur multi-coeurs ayant plusieurs coeurs distincts, le procédé d'implémentation étant mis en oeuvre par un dispositif électronique d'implémentation. 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'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur une plateforme comprenant un processeur multi-coeurs ayant plusieurs coeurs distincts. L'invention concerne également un système électronique comprenant une mémoire apte à stocker des applications logicielles ; une plateforme apte à exécuter chaque application logicielle, la plateforme comprenant un processeur multi-coeurs ayant plusieurs coeurs distincts ; et un tel dispositif électronique d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur la plateforme. L'invention concerne le domaine de la qualification de plateformes embarquées comportant un ou plusieurs processeurs multi-coeurs, en particulier dans le domaine avionique suivant la norme D0297. L'utilisation de processeurs multi-coeurs 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 multi-coeurs 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 multi-coeurs puisse être maitrisé explicitement et de manière prédictive. Le terme « contention » désigne toute situation dans laquelle au moins une activité menée par au moins un coeur d'un processeur multi-coeurs subit des retards dans son exécution à cause du parallélisme temporel permis par ce processeur multi-coeurs. 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 interne (appelé souvent « interconnect ») reliant les coeurs les uns aux autres, ainsi que les coeurs aux 5 périphériques, qui ne permet pas toujours des transactions simultanées indépendantes 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 10 simultanément. Des appels simultanés à de tels modules logiciels communs provoquent 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 15 tous les coeurs. Lorsque le processeur est en outre un processeur acheté auprès d'un fournisseur, ou processeur COTS (de l'anglais Commercial Off-The-Shen il est généralement impossible d'avoir accès au détail de conception des organes internes d'un tel processeur multi-coeurs, et il est donc très difficile, voire impossible de garantir un comportement 20 déterministe du processeur. Selon un premier type connu d'architecture logicielle pour une plateforme avec processeur multi-coeurs, également appelée architecture SMP (de l'anglais Symetrical Multi-Processing), un unique système d'exploitation décide à chaque instant quel traitement logiciel est exécuté sur quel coeur. 25 Selon un deuxième type connu d'architecture logicielle pour une plateforme avec processeur multi-coeurs, é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. 30 Toutefois, de telles architectures ne sont pas suffisamment intrinsèquement déterministes pour obtenir la qualification de plateformes avec processeurs multi-coeurs, 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'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur une plateforme avec processeur mufti-coeurs, qui permettent de maitriser l'impact de 3 contention(s) lors de l'exécution desdites applications logicielles et de faciliter alors la qualification de la plateforme. A cet effet, l'invention a pour objet un procédé d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur une plateforme 5 comprenant un processeur mufti-coeurs ayant plusieurs coeurs distincts, le procédé d'implémentation étant mis en oeuvre par un dispositif électronique d'implémentation et comprenant l'étape suivante : - commutation entre l'exécution d'un ensemble courant d'application(s) logicielle(s) sur une pluralité de coeurs et l'exécution d'un ensemble suivant d'application(s) 10 logicielle(s) sur la pluralité de coeurs, effectuée de manière synchrone sur ladite pluralité de coeurs, l'étape de commutation synchrone muni-coeurs comportant une ou plusieurs actions parmi un premier groupe d'actions consistant en : + attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de 15 traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) ; et + purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s). Avec le procédé d'implémentation selon l'invention, les coeurs sont synchronisés 20 et l'exécution des applications logicielles est segmentée en zones temporelles (de l'anglais Time Cluster), la commutation synchrone multi-coeurs permettant d'effectuer un partitionnement robuste entre deux zones temporelles successives, notamment au sens de la norme D0297. Suivant d'autres aspects avantageux de l'invention, le procédé d'implémentation 25 comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - l'étape de commutation synchrone muni-coeurs est effectuée de manière synchrone sur tous les coeurs du processeur ; - l'étape de commutation synchrone mufti-coeurs comporte toutes les actions du 30 premier groupe d'actions ; - l'étape de commutation synchrone mufti-coeurs comporte en outre une ou plusieurs actions parmi un deuxième groupe d'actions consistant en : + réinitialisation d'entrée(s)-sortie(s) associée(s) à l'ensemble suivant d'application(s) logicielle(s) ; 35 + sauvegarde du contexte de l'ensemble courant d'application(s) logicielle(s) ; et 4 + restauration du contexte de l'ensemble suivant d'application(s) logicielle(s) ; - le procédé comprend en outre une étape de commutation entre l'exécution d'une première application logicielle et l'exécution d'une deuxième application logicielle sur un 5 même coeur, lors l'exécution d'un ensemble donné d'application(s) logicielle(s) ; - l'étape de commutation sur un même coeur comporte une ou plusieurs actions parmi le groupe consistant en : + attente de la fin de l'exécution de traitement(s) non-interruptible(s) de la première application logicielle ; 10 + purge de(s) ressource(s) mémoire(s) du coeur, dont les cache(s) privé(s) correspondant ; + sauvegarde du contexte de la première application logicielle ; et + restauration du contexte de la deuxième application logicielle ; - la plateforme héberge un unique système d'exploitation pour tous les coeurs 15 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'implémentation tel que défini ci-dessus. L'invention a également pour objet un dispositif électronique d'implémentation d'un 20 partitionnement lors de l'exécution d'applications logicielles sur une plateforme comprenant un processeur multi-coeurs ayant plusieurs coeurs distincts, le dispositif comprenant : - un module de commutation configuré pour commuter entre l'exécution d'un ensemble courant d'application(s) logicielle(s) sur une pluralité de coeurs et l'exécution 25 d'un ensemble suivant d'application(s) logicielle(s) sur la pluralité de coeurs, de manière synchrone sur ladite pluralité de coeurs, le module de commutation étant configuré pour effectuer une ou plusieurs actions parmi un premier groupe d'actions consistant en : + attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de 30 traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) ; et + purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s). L'invention a également pour objet un système électronique comprenant : 35 - une mémoire apte à stocker des applications logicielles ; 5 - une plateforme apte à exécuter chaque application logicielle, la plateforme comprenant un processeur multi-coeurs ayant plusieurs coeurs distincts ; et - un dispositif électronique d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur la plateforme, le dispositif électronique 5 d'implémentation é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 : 10 - la figure 1 est une représentation schématique d'un système électronique selon 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 multi-coeurs ayant plusieurs coeurs distincts, et hébergeant un système d'exploitation ; et un dispositif électronique 15 d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur la plateforme ; - la figure 2 est un organigramme d'un procédé, selon l'invention, d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles sur la plateforme, le procédé étant mis en oeuvre par le dispositif d'implémentation de la figure 1 ; 20 - la figure 3 est une représentation schématique d'implémentation d'un partitionnement avec un processeur quadri-coeur pour une architecture générale ; - la figure 4 est une vue analogue à celle de la figure 3 pour une architecture de type multitraitement symétrique, ou SMP (de l'anglais Symetrical Multi-Processing); - la figure 5 est une vue analogue à celle de la figure 3 pour une architecture de 25 type multitraitement asymétrique, ou AMP (de l'anglais Asymetrical Multi-Processing) ; et - la figure 6 est une vue analogue à celle de la figure 3 avec un processeur bi- coeur pour une architecture mixte en termes de traitement. 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. 6 Le système électronique 10 comprend en outre, selon l'invention, un dispositif électronique 24 d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles 14 sur la plateforme 16. Sur la figure 1, par souci de simplification du dessin, la mémoire 12 a été 5 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'implémentation 24. Néanmoins, l'homme du métier comprendra bien entendu que la mémoire 12 est incluse dans les ressources 18 de la plateforme 16. 10 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 logicielles 14 distinctes, et le dispositif électronique d'implémentation 24 est alors configuré pour implémenter le partitionnement lors de l'exécution de ces applications 15 logicielles 14. 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 des ressources 18 de la plateforme 16. 20 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 plateformes 16 et utilisent les ressources 18 desdites plateformes 16. 25 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 séparée de manière robuste de l'exécution des autres applications logicielles 14, pendant toute leur durée d'exécution. La plateforme 16 est notamment destinée à être embarquée à bord de l'aéronef. 30 La plateforme 16 est, par exemple, une unité de traitement d'informations formée d'une 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 35 multitraitement asymétrique, également appelée architecture AMP (de l'anglais Asymetrical Multi-Processing). 7 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 5 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. 10 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 15 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. 20 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 : - les ressources de type traitement de données (en anglais « processing »). De telles ressources comportent par exemple un ou plusieurs processeurs multi-coeurs ayant 25 chacun plusieurs coeurs distincts ; - les ressources de type mémoire de masse (en anglais « mass memory »); - les ressources de type entrées et sorties ; - les ressources spécifiques au réseau avionique. De telles ressources sont, par exemple, les routeurs de communication d'un réseau ARINC664 ; et 30 - les ressources de type graphique, c'est-à-dire les ressources permettant un affichage. Un écran est un exemple de telles ressources. Dans l'exemple de la figure 1, en termes de ressources de type traitement de données, la plateforme 16 comprend plusieurs processeurs muni-coeurs 26 ayant chacun plusieurs coeurs distincts, et plus particulièrement deux processeurs muni-coeurs 26. En 35 variante, la plateforme 16 comprend un unique processeur multi-coeurs 26 ayant plusieurs coeurs distincts. 8 Dans l'exemple de la figure 1, en termes de ressources de type mémoire de masse, la plateforme 16 comprend une mémoire de masse 28. 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. Le dispositif électronique d'implémentation 24 est configuré pour mettre en oeuvre 10 le partitionnement souhaité lors de l'exécution des applications logicielles 14 sur la plateforme 16 comprenant au moins un processeur multi-coeurs 26. Le dispositif électronique d'implémentation 24 comprend un premier module de commutation 30 configuré pour commuter entre l'exécution d'un ensemble courant d'application(s) logicielle(s) 14 sur une pluralité de coeurs du processeur 26 15 correspondant et l'exécution d'un ensemble suivant d'application(s) logicielle(s) 14 sur la pluralité de coeurs du processeur 26 correspondant, de manière synchrone sur ladite pluralité de coeurs. En complément facultatif, le dispositif électronique d'implémentation 24 comprend un deuxième module de commutation 32 configuré pour commuter entre l'exécution d'une 20 première application logicielle et l'exécution d'une deuxième application logicielle sur un même coeur, lors l'exécution d'un ensemble donné d'application(s) logicielle(s) 14. Comme représenté sous forme de hachures sur la figure 1, le dispositif d'implémentation 24 est, de préférence, apte à être exécuté directement par la plateforme 16 et à utiliser alors ses ressources 18. Le dispositif d'implémentation 24 est alors de 25 préférence hébergé en outre par le système d'exploitation 20. En variante, également visible sur la figure 1, le dispositif d'implémentation 24 est distinct de la plateforme 16, et comprend une unité de traitement d'informations 34 formée par exemple d'un processeur 36 associé à une mémoire 38. Dans l'exemple de la figure 1, que le dispositif d'implémentation 24 soit distinct de 30 la plateforme 16, ou bien hébergé et exécuté par la plateforme 16, le premier module de commutation 30, et en complément facultatif le deuxième module de commutation 32, sont réalisés chacun sous forme d'un logiciel, ou d'une brique logicielle, exécutable par un processeur, tel que le processeur 32 lorsque le dispositif d'implémentation 24 est distinct de la plateforme 16. La mémoire 34 du dispositif d'implémentation 24 est alors apte à 35 stocker un premier logiciel de commutation configuré pour commuter, de manière synchrone sur ladite pluralité de coeurs du processeur 26 correspondant, entre l'exécution 9 de l'ensemble courant d'application(s) logicielle(s) 14 et l'exécution de l'ensemble suivant d'application(s) logicielle(s) 14. En complément facultatif, la mémoire 34 du dispositif d'implémentation 24 est alors apte à stocker un deuxième logiciel de commutation configuré pour commuter, sur un même coeur, entre l'exécution de la première application 5 logicielle et l'exécution de la deuxième application logicielle, lors l'exécution dudit ensemble courant d'application(s) logicielle(s) 14. En variante non représentée, le premier module de commutation 30, et en complément facultatif le deuxième module de commutation 32, sont réalisés chacun sous forme d'un composant logique programmable, tel qu'un FPGA (de l'anglais Field 10 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 d'implémentation 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 15 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 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, 20 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. Le premier module de commutation 30 est alors configuré pour effectuer une ou plusieurs commutations synchrones multi-coeurs 40 sur une pluralité de coeurs d'un 25 processeur mufti-coeurs 26 correspondant. Pour effectuer une commutation synchrone multi-coeurs 40, le premier module de commutation 30 est configuré pour effectuer, de manière synchrone sur la pluralité de coeurs d'un processeur multi-coeurs 26 correspondant, une ou plusieurs actions parmi un premier groupe d'actions consistant en : une attente, synchronisée sur la pluralité de 30 coeurs, de la fin de l'exécution de traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) ; et une purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s). Par ressource mémoire de la pluralité de coeurs, on entend de manière générale tout espace mémoire d'un coeur, qu'il s'agisse d'un cache, d'un registre ou encore d'un 35 espace mémoire de taille plus importante. 10 La purge d'une ressource mémoire est la remise à zéro, ou encore la réinitialisation, de cette ressource mémoire. Le premier module de commutation 30 est de préférence configuré pour effectuer chaque commutation synchrone multi-coeurs 40 sur tous les coeurs du processeur multi- 5 coeurs 26 correspondant. Le cas échéant, le premier module de commutation 30 est configuré pour effectuer la ou les actions précitées du premier groupe d'actions de manière synchrone sur tous les coeurs du processeur multi-coeurs 26 correspondant. L'homme du métier comprendra qu'une commutation synchrone multi-coeurs 40 est déclenchée à un instant déterminé par la plateforme 16, typiquement par 10 configuration, et ce pour la pluralité de coeurs concernée, ce déclenchement étant, en vue du synchronisme précité, effectué en même temps pour ladite pluralité de coeurs, et étant alors simultané ou quasi-simultané. La notion de synchronisme dépend des applications logicielles 14, une durée dédiée à la commutation synchrone, telle que typiquement quelques centaines de micro-secondes, est par exemple définie comme une durée 15 pendant laquelle aucune activité applicative n'est exécutée et les activités de commutation sur les différents coeurs sont en partie séquentielles. En fin de commutation, l'activité applicative est relancée simultanément sur tous les coeurs. Le premier module de commutation 30 est de préférence configuré pour effectuer toutes les actions du premier groupe d'actions, sur la pluralité de coeurs du processeur 20 multi-coeurs 26 correspondant ou de préférence sur tous les coeurs du processeur multi- coeurs 26 correspondant. En complément, le premier module de commutation 30 est configuré pour effectuer en outre une ou plusieurs actions parmi un deuxième groupe d'actions consistant en : une réinitialisation d'entrée(s)-sorties) associée(s) à l'ensemble suivant 25 d'application(s) logicielle(s) ; une sauvegarde du contexte de l'ensemble courant d'application(s) logicielle(s) ; et une restauration du contexte de l'ensemble suivant d'application(s) logicielle(s). Lorsque le premier module de commutation 30 est configuré pour effectuer à la fois les actions du premier groupe d'actions et celles du deuxième groupe d'actions, il est 30 de préférence configurer pour les effectuer dans l'ordre suivant : + attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) 14 ; + purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s) 14 ; 35 + sauvegarde du contexte de l'ensemble courant d'application(s) logicielle(s) 14 ; 11 + réinitialisation d'entrée(s)-sortie(s) associée(s) à l'ensemble suivant d'application(s) logicielle(s) 14 ; et + restauration du contexte de l'ensemble suivant d'application(s) logicielle(s) 14. 5 En complément facultatif, le deuxième module de commutation 32 est, lors de l'exécution d'un ensemble donné d'application(s) logicielle(s) 14, configuré pour commuter entre l'exécution d'une première application logicielle et l'exécution d'une deuxième application logicielle sur un même coeur. Le deuxième module de commutation 32 est alors configuré pour effectuer une commutation interne 42 à un coeur respectif du 10 processeur 26 correspondant. Pour effectuer une commutation interne 42 à un coeur respectif, le deuxième module de commutation 32 est configuré pour effectuer une ou plusieurs actions parmi le groupe consistant en : une attente de la fin de l'exécution de traitement(s) noninterruptible(s) de la première application logicielle ; une sauvegarde du contexte de la 15 première application logicielle ; une purge de(s) ressource(s) mémoire(s) du coeur, dont les cache(s) privé(s) correspondant ; et une restauration du contexte de la deuxième application logicielle. Le deuxième module de commutation 32 est de préférence configuré pour effectuer toutes les actions du groupe d'actions précité sur le coeur respectif du 20 processeur multi-coeurs 26 correspondant. Le fonctionnement du dispositif d'implémentation 24 selon l'invention va désormais être expliqué à l'aide de la figure 2 représentant un organigramme du procédé, selon l'invention, d'implémentation du partitionnement lors de l'exécution d'applications 25 logicielles 14 sur la plateforme 16, le procédé étant mis en oeuvre par le dispositif électronique d'implémentation 24. Lors d'une étape 100, le dispositif d'implémentation 24 met en oeuvre, via son premier module de commutation 32, une commutation synchrone multi-coeurs 40. Cette étape de commutation synchrone multi-coeurs 100 comporte une ou 30 plusieurs actions parmi le premier groupe d'actions consistant en : l'attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) ; et la purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s). Cette étape de commutation synchrone multi-coeurs 100 est effectuée de manière 35 synchrone sur la pluralité concernée de coeurs du processeur multi-coeurs 26 correspondant. 12 Cette étape de commutation synchrone multi-coeurs 100 est de préférence effectuée de manière synchrone sur tous les coeurs du processeur multi-coeurs 26 correspondant. La ou les actions précitées du premier groupe d'actions sont alors effectuées de manière synchrone sur tous les coeurs du processeur multi-coeurs 26 5 correspondant. Chaque étape de commutation synchrone multi-coeurs 100 est déclenchée à un instant déterminé par la plateforme 16, typiquement par configuration, et ce pour la pluralité de coeurs concernée. Chaque étape de commutation synchrone multi-coeurs 100 comporte de 10 préférence toutes les actions du premier groupe d'actions, celles-ci étant alors effectuées sur la pluralité de coeurs du processeur multi-coeurs 26 correspondant ou de préférence sur tous les coeurs du processeur multi-coeurs 26 correspondant. En complément, chaque étape de commutation synchrone multi-coeurs 100 comporte en outre une ou plusieurs actions parmi le deuxième groupe d'actions 15 consistant en : la réinitialisation d'entrée(s)-sortie(s) associée(s) à l'ensemble suivant d'application(s) logicielle(s) ; la sauvegarde du contexte de l'ensemble courant d'application(s) logicielle(s) ; et la restauration du contexte de l'ensemble suivant d'application(s) logicielle(s). En complément facultatif, lors d'une étape suivante 110, le dispositif 20 d'implémentation 24 met en oeuvre, via son deuxième module de commutation 32, une ou plusieurs commutations internes 42 à un coeur respectif du processeur 26 correspondant. Chaque étape de commutation sur un même coeur 110 entre l'exécution d'une première application logicielle et l'exécution d'une deuxième application logicielle sur un même coeur, lors l'exécution d'un ensemble donné d'application(s) logicielle(s), comporte 25 une ou plusieurs actions parmi le groupe consistant en : l'attente de la fin de l'exécution de traitement(s) non-interruptible(s) de la première application logicielle ; la sauvegarde du contexte de la première application logicielle ; la purge de(s) ressource(s) mémoire(s) du coeur, dont les cache(s) privé(s) correspondant ; et la restauration du contexte de la deuxième application logicielle. 30 Chaque étape de commutation sur un même coeur 110 comporte de préférence toutes les actions du groupe d'actions précité sur le coeur respectif du processeur multi- coeurs 26 correspondant. Ainsi, le dispositif d'implémentation 24 et le procédé d'implémentation selon 35 l'invention permettent, via une ou plusieurs commutations synchrones multi-cceurs 40 successives et comme représenté dans l'exemple de la figure 3 avec un processeur 13 quadri-coeur pour une architecture générale, de synchroniser les coeurs du processeur multi-coeurs 26 correspondant et de segmenter le temps d'exécution du processeur multicoeurs 26 en zones temporelles, également notées TC (de l'anglais Time Cluster), une commutation synchrone multi-coeurs 40 étant placée entre deux zones temporelles TC 5 successives. Cette segmentation en zones temporelles TC avec des commutations synchrones multi-coeurs 40 permet alors d'obtenir un partitionnement plus robuste, notamment un partitionnement temporel absolu, lors de l'exécution des applications logicielles 14 sur la plateforme 16. 10 Par partitionnement temporel absolu, on entend une implémentation permettant un isolement entre zones temporelles TC quel que soit le coeur du processeur multi-coeurs 26 correspondant. Par partitionnement spatial absolu, on entend une implémentation permettant un isolement, en termes d'allocations de ressources, notamment de ressources mémoires, 15 entre toutes les partitions installées quel que soit le coeur du processeur multi-coeurs 26 correspondant. Par partition, on entend un espace temporel et spatial alloué à une application logicielle 14 ou à un groupe d'applications logicielles 14 sur un ou plusieurs coeurs. Autrement dit, chaque commutation synchrone multi-coeurs 40 permet alors 20 d'assurer un nettoyage complet de tout le contexte multi-coeurs, c'est-à-dire d'éliminer toute trace d'exécution liée à la zone temporelle TC précédente pour les coeurs concernés, et alors d'offrir un partitionnement absolu, c'est-à-dire n'impliquant aucune contrainte introduisant des dépendances entre applications logicielles 14. Sur les figures 3 à 6, chaque partition est désignée par une référence Pi, où i est 25 un indice entier représentant le numéro de la partition correspondante. Chaque coeur du processeur multi-coeurs 26 de chacun de ces exemples est désigné par une référence Cj, où j est un indice entier compris entre 0 et 3 pour les exemples des figures 3 à 5 avec un processeur quadri-coeur, respectivement compris entre 0 et 1 pour l'exemple de la figure 6 avec un processeur bi-coeur, j représentant le numéro du coeur correspondant. Le cas 30 échéant, Aij désigne une partie d'une application logicielle 14 installée dans une partition d'indice i et sur un coeur d'indice j. Dans l'exemple des figures 3 à 6, chaque zone temporelle TC entre deux commutations synchrones multi-coeurs 40 comporte une ou plusieurs fenêtres temporelles, également notées TW (de l'anglais Time Window). Chaque fenêtre 35 temporelle TW désigne une plage temporelle délimitée par deux évènements successifs permettant de traiter une fin de partition ou une commutation interne 42 à un coeur. Cette 14 notion est utile au système d'exploitation 20 en charge de traiter tous ces évènements de manière éventuellement centralisée, mais ne préjuge pas de l'impact d'un tel évènement sur un coeur qui n'est pas concerné par cet évènement. Sur les figures 3 à 6, la notation MIF (de l'anglais Mlnor Frame) représente une 5 base périodique du temps réel permettant la synchronisation de systèmes d'exploitations 20, notamment sur laquelle sont synchronisés les systèmes d'exploitations 20 des différents coeurs dans le cas de l'architecture AMP. L'homme du métier observera également que le processeur multi-coeurs permet en outre d'offrir un partitionnement entre coeurs 44, également appelé partitionnement 10 inter-coeurs, représenté par les zones remplies de points sur les figures 3 à 6, entre une partition ou application exécutée sur un coeur et une partition ou application exécutée sur un autre coeur. La figure 4 est alors un exemple d'implémentation de partitionnement avec un processeur quadri-coeur pour une architecture de type SMP, la figure 5 étant un exemple 15 similaire d'implémentation de partitionnement avec le processeur quadri-coeur pour une architecture de type AMP. Enfin, la figure 6 est un exemple d'implémentation de partitionnement avec un processeur bi-cceur pour une architecture de type mixte AMP / SMP, avec en outre un fonctionnement en mode mono-cceur sur le seul coeur CO au cours de la zone temporelle repérée par l'accolade MC (pour mono-coeur). 20 De manière analogue à l'exemple de la figure 3, l'homme du métier observera, dans les exemples des figures 4 à 6, que les différentes commutations synchrones multicoeurs 40 offrent un partitionnement temporel absolu entre zones temporelles TC. Dans l'exemple de la figure 4, la zone temporelle SP (de l'anglais Spare) correspond à une zone temporelle libre, pour laquelle aucune partition ou application n'est exécutée. 25 L'homme du métier comprendra que les différentes zones temporelles TC, telles que définies ci-dessus, en particulier la détermination des instants auxquels doivent être effectuées les commutations synchrones multi-coeurs 40 successives, sont définies lors d'une phase de conception préliminaire ou lors d'une phase de préparation de mission, préalablement à la mise en oeuvre du procédé selon l'invention. 30 Lorsque le système électronique 10 est un système électronique avionique embarqué à bord de l'aéronef, cette définition des zones temporelles TC est en outre de préférence faite préalablement au vol de l'aéronef, le procédé d'implémentation selon l'invention étant de préférence mis en oeuvre lors du vol de l'aéronef. L'homme du métier notera également qu'il est en outre possible d'installer 35 plusieurs applications logicielles 14 dans des partitions distinctes à l'intérieur d'une même zone temporelle TC suivant différentes méthodes. Suivant une première méthode, deux 15 partitions sont installées en parallèle sur des coeurs séparés, et bénéficient d'un partitionnement entre coeurs, également appelé partitionnement inter-coeur. Suivant une deuxième méthode, deux partitions sont installées séquentiellement sur un même coeur ou un ensemble de coeurs, et bénéficient dans ce cas d'un partitionnement au travers 5 d'une ou plusieurs commutations internes 42, coeur par coeur, également appelé partitionnement intra-coeur. Une troisième méthode correspond à un mélange des première et deuxième méthodes avec des partitionnements inter-coeur et intra-coeur. Par ailleurs, la commutation interne 42 à un coeur ne peut éliminer toute cause de dépendance entre les applications logicielles 14 précédentes et suivantes d'un point de 10 vue temporel (contention résultant d'une chaine entre application logicielle précédente, autre application logicielle sur un autre coeur, application logicielle suivante). Il en résulte la présence potentielle de gigues (de l'anglais jitter) sur le temps d'exécution d'une application logicielle 14, gigues dépendant de l'activité des autres applications logicielles 14. Il n'y a alors finalement pas de différence, vis-à-vis de l'isolement des applications 15 logicielles 14 au sein d'une même zone temporelle TC, entre deux applications installées sur un même coeur et séparées par une commutation interne 42 et deux applications installées sur deux coeurs différents. En complément facultatif et afin d'améliorer encore la sécurité de fonctionnement de la plateforme 16, le dispositif d'implémentation 24, ou encore un autre dispositif de 20 surveillance, est configuré pour surveiller les temps d'exécution au sein d'une zone temporelle TC lorsque plusieurs applications logicielles 14 indépendantes sont installées. La conséquence d'un dépassement d'un temps d'exécution pouvant menacer la sécurité de fonctionnement, des actions correctives, telles qu'une réinitialisation des applications logicielles 14 concernées ou un arrêt des applications logicielles 14 les moins critiques, 25 sont prévues suite à un déclenchement de cette surveillance. De telles actions correctives visent à restaurer un contexte plus sûr suite à de tels évènements et à décharger le processeur multi-coeurs 26 correspondant, afin de retrouver une situation exempte de contentions exceptionnelles. On conçoit ainsi que le procédé et le dispositif d'implémentation 24 selon 30 l'invention permettent, de par le partitionnement résultant notamment de chaque commutation synchrone multi-coeurs 40, de maitriser l'impact de contention(s) lors de l'exécution REVENDICATIONS1. Procédé d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles (14) sur une plateforme (16) comprenant un processeur multi-coeurs (26) ayant plusieurs coeurs distincts, le procédé d'implémentation étant mis en oeuvre par un dispositif électronique d'implémentation (24) et comprenant l'étape suivante : - commutation (100) entre l'exécution d'un ensemble courant d'application(s) logicielle(s) (14) sur une pluralité de coeurs et l'exécution d'un ensemble suivant d'application(s) logicielle(s) (14) sur la pluralité de coeurs, effectuée de manière synchrone sur ladite pluralité de coeurs, l'étape de commutation synchrone multi-coeurs (100) comportant une ou plusieurs actions parmi un premier groupe d'actions consistant en : + attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de traitement(s) non-interruptible(s) de l'ensemble courant d'application(s) logicielle(s) (14) ; et + purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s) (14). 2. Procédé selon la revendication 1, dans lequel l'étape de commutation synchrone multi-coeurs (100) est effectuée de manière synchrone sur tous les coeurs du processeur (26). 3. Procédé selon la revendication 1 ou 2, dans lequel l'étape de commutation synchrone multi-coeurs (100) comporte toutes les actions du premier groupe d'actions. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de commutation synchrone multi-coeurs (100) comporte en outre une ou plusieurs actions parmi un deuxième groupe d'actions consistant en : + réinitialisation d'entrée(s)-sorties) associée(s) à l'ensemble suivant d'application(s) logicielle(s) (14) ; + sauvegarde du contexte de l'ensemble courant d'application(s) logicielle(s) (14) ; et + restauration du contexte de l'ensemble suivant d'application(s) logicielle(s) (14). 17 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel le procédé comprend en outre l'étape suivante : - commutation (110) entre l'exécution d'une première application logicielle (14) et 5 l'exécution d'une deuxième application logicielle (14) sur un même coeur, lors l'exécution d'un ensemble donné d'application(s) logicielle(s) (14). 6. Procédé selon la revendication 5, dans lequel l'étape de commutation sur un même coeur (110) comporte une ou plusieurs actions parmi le groupe consistant en : 10 + attente de la fin de l'exécution de traitement(s) non-interruptible(s) de la première application logicielle (14) ; + purge de(s) ressource(s) mémoire(s) du coeur, dont les cache(s) privé(s) correspondant ; + sauvegarde du contexte de la première application logicielle (14) ; 15 et + restauration du contexte de la deuxième application logicielle (14). 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel la plateforme (16) héberge un unique système d'exploitation (20) pour tous les coeurs et/ou 20 un système d'exploitation (20) pour chaque coeur. 8. Programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé selon l'une quelconque des revendications précédentes. 9. Dispositif électronique (24) d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles (14) sur une plateforme (16) comprenant un processeur multi-coeurs (26) ayant plusieurs coeurs distincts, le dispositif (24) comprenant : 30 - un module de commutation (30) configuré pour commuter entre l'exécution d'un ensemble courant d'application(s) logicielle(s) (14) sur une pluralité de coeurs et l'exécution d'un ensemble suivant d'application(s) logicielle(s) (14) sur la pluralité de coeurs, de manière synchrone sur ladite pluralité de coeurs, le module de commutation (30) étant configuré pour effectuer une ou plusieurs 35 actions parmi un premier groupe d'actions consistant en : 25 5 18 + attente, synchronisée sur la pluralité de coeurs, de la fin de l'exécution de traitement(s) non-interruPtible(s) de l'ensemble courant d'application(s) logicielle(s) (14) ; et + purge de toute(s) ressource(s) mémoire(s) associée(s) à l'ensemble courant d'application(s) logicielle(s) (14). 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 10 plateforme (16) comprenant un processeur multi-cceurs (26) ayant plusieurs coeurs distincts ; et - un dispositif électronique (24) d'implémentation d'un partitionnement lors de l'exécution d'applications logicielles (14) sur la plateforme (16), le dispositif électronique d'implémentation (24) étant selon la revendication 9. 15