FR 3053140 A1 20171229 FR 1601012 A 20160627 1 ARCHITECTURE DE CALCUL NOTAMMENT POUR UN SYSTEME EMBARQUE AERONAUTIQUE La présente invention concerne une architecture de calcul notamment pour un système embarqué aéronautique. De tels systèmes embarqués aéronautiques peuvent par exemple être des systèmes embarqués dits autonomes, fédérés ou d'avionique modulaire intégré (IMA). D'une façon générale, de telles architectures comportent des moyens à processeur d'exécution d'applications ou applicatifs. Dans l'état de la technique, ces architectures de calcul peuvent donc être considérées comme des architectures dites distribuées, dans lesquelles un élément de calcul est associé à une et une seule application ou applicatif. Dans les générations actuelles d'architectures, on peut donc résumer la situation au fait qu'une fonction correspond à une application qui s'exécute sur un calculateur disposant d'un processeur monocoeur. Les évolutions technologiques conduisent les fabricants de processeurs à utiliser le silicium disponible pour intégrer de plus en plus de fonctions au sein d'une même puce électronique. Cette intégration a été rendue nécessaire car la course à la puissance de ces puces ne pouvait plus être effectuée par une simple augmentation de la fréquence de fonctionnement. Les évolutions technologiques liées notamment à la finesse de gravure des composants ont permis de remplacer la montée en fréquence par une augmentation du nombre de coeurs de calcul, rendant ainsi le composant de plus en plus performant tout en maintenant une consommation maitrisable. Mais, dans les applications envisagées, se pose alors le problème de la certification. En effet, la certification d'un processeur mono ou multi-coeurs demande à démontrer que l'on soit en mesure de maîtriser le déterminisme de l'ensemble des accès réalisés par l'un des coeurs, quelles que soient les applications qui vont s'exécuter sur chacun des autres coeurs disponibles et ce quelle que soit l'architecture interne du processeur. Dans un contexte d'avionique modulaire intégré IMA, la non maîtrise des applications a conduit à considérer que ce déterminisme ne pouvait pas être démontrable et que de ce fait, le calcul d'un pire cas de temps d'exécution (WCET) tel qu'il est 3053140 2 actuellement demandé, ne pouvait pas être effectué sans introduire de fortes contraintes au niveau du fonctionnement interne du processeur multi-coeurs. De plus, la complexité introduite par les architectures actuelles à processeurs conduit à ne pas être en mesure de maîtriser les rémanences pouvant être générées par 5 un coeur réalisant un transfert sur l'exécution en cours et/ou un transfert conduit par les autres coeurs. Tout ceci se traduit par le fait que la certification de telles structures est extrêmement difficile à obtenir et qu'il est difficile voire impossible de déployer ces structures. 10 Le but de l'invention est de proposer des solutions d'architectures de calcul pour y parvenir. A cet effet, l'invention a pour objet une architecture de calcul notamment pour un système embarqué aéronautique autonome, fédéré ou d'avionique modulaire intégré (IMA), comportant des moyens à processeur d'exécution d'applicatifs, caractérisée en ce 15 que les moyens à processeur d'exécution comprennent un processeur multi-coeurs associé à un ordonnanceur de gestion du fonctionnement de ce processeur, permettant de faire exécuter les applicatifs par les coeurs du processeur, d'une façon séquentielle et ségrégée, en respectant des contraintes de partitionnement déterminées en activant un et un seul coeur à la fois. 20 Suivant d'autres caractéristiques de l'architecture selon l'invention, prises seules ou en combinaison : - l'ordonnanceur est adapté pour définir un cycle d'activation des coeurs les uns à la suite des autres ; - le cycle d'activation des coeurs est programmé par coeur dans un fichier de 25 configuration transmis à l'ordonnanceur ; - l'ordonnanceur comporte des moyens de stockage d'informations, pour chaque coeur et chaque applicatif à exécuter, relatives à : - l'instant de démarrage de l'exécution de l'applicatif, et - la durée d'exécution de l'applicatif ; 30 - l'ordonnanceur comporte également des moyens de stockage, pour chaque coeur et chaque applicatif à exécuter, d'informations relatives à un temps d'isolement des coeurs les uns par rapport aux autres ; - les informations sont prédéterminées lors de la conception de l'architecture et sont transmises à l'ordonnanceur via le fichier de configuration ; 35 - l'ordonnanceur comporte des moyens de nettoyage du processeur et du coeur à la fin de l'exécution d'un applicatif ; - 3053140 3 - elle comporte un mécanisme de contrôle externe de type Chien de Garde ; - elle comporte un mécanisme de contrôle externe de type Chien de Garde par coeur du processeur et initialisé par l'ordonnanceur ; - l'ordonnanceur est hébergé et cadencé par l'un des coeurs du processeur. 5 L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés, sur lesquels : - la figure 1 illustre le passage d'une architecture ségrégée monocoeur de l'état de la technique, à une architecture multi-coeurs ségrégée selon l'invention ; 10 - la figure 2 représente un schéma synoptique illustrant une structure de processeur multi-coeurs entrant dans la constitution d'une architecture de calcul selon l'invention ; - la figure 3 représente les différentes informations utilisées par un ordonnanceur entrant dans la constitution d'une architecture de calcul selon l'invention ; et 15 - la figure 4 illustre un cycle d'activation de coeurs. Comme cela a été indiqué précédemment, l'invention se rapporte à une architecture de calcul notamment pour un système embarqué aéronautique. Comme indiqué également précédemment, un tel système peut être un système autonome, fédéré ou d'avionique modulaire intégré (IMA). 20 Dans l'état de la technique, différents équipements, tels que par exemple les équipements désignés par les références 1, 2, 3 et 4 sur cette figure 1, sont associés à des moyens d'entrée et sortie d'informations, tels que les moyens 5, 6, 7 et 8 respectivement. Ces équipements comportent chacun des moyens à processeur d'exécution de 25 fonction. Dans l'état de la technique, chaque équipement comporte alors un processeur monocoeur, désigné par les références 9, 10, 11 et 12 respectivement, mettant en oeuvre chacun une fonction correspondante, désignée par les références 13, 14, 15 et 16 respectivement. 30 Dans l'architecture selon l'invention, on se propose d'utiliser des moyens à processeur d'exécution qui comprennent un processeur multi-coeurs, associé à un ordonnanceur de gestion du fonctionnement de ce processeur. Ceci est illustré sur la figure 1 également, où les équipements sont désignés par la référence générale 20 sur cette figure et sont reliés à des moyens d'entrée/sortie de 35 données 21. 3053140 4 Les différentes fonctions sont toujours désignées par les références 13, 14, 15 et 16. Ces fonctions sont mises en oeuvre par un processeur multi-coeurs, désigné par la référence générale 25, comportant par exemple quatre coeurs 26, 27, 28 et 29. 5 Ceci permet alors de faire exécuter les applicatifs par les coeurs du processeur, d'une façon séquentielle et ségrégée, en respectant des contraintes de partitionnement déterminées en activant un et un seul coeur à la fois. A cet effet, et comme cela est illustré sur la figure 2, où l'on reconnaît le processeur multi-coeurs 25 et les coeurs 26, 27, 28 et 29 de celui-ci, on peut constater que 10 ce processeur multi-coeurs est associé à un ordonnanceur de gestion de son fonctionnement. Cet ordonnanceur est désigné par la référence générale 30 sur cette figure 2 et il est associé à un fichier de configuration désigné par la référence générale 31. En fait et pour résoudre les différents problèmes évoqués précédemment, ce 15 fichier de configuration 31 est établi lors de la conception de l'architecture, pour définir l'exécution des applicatifs par les coeurs du processeur, de façon séquentielle et ségrégée en respectant les contraintes de partitionnement fixées. Comme cela est illustré sur la figure 3, l'ordonnanceur est alors associé à des moyens de stockage de ce fichier d'informations qui comportent, pour chaque coeur et 20 chaque applicatif à exécuter, des informations qui sont relatives à l'instant de démarrage de l'exécution de l'applicatif et la durée d'exécution de l'applicatif. D'autres informations comme par exemple des informations relatives à un temps d'isolement des coeurs les uns par rapport aux autres, peuvent également être envisagées. 25 Ainsi sur cette figure 3, le fichier comporte, pour chaque coeur, l'instant de démarrage par exemple (Demi, la durée d'exécution DE1 et le temps d'isolement Tl, pour l'application affectée. On conçoit alors qu'à partir de ces différentes informations, l'ordonnanceur est adapté pour définir un cycle d'activation des coeurs les uns à la suite des autres, comme 30 cela est illustré sur la figure 4. Ce cycle d'activation est programmé par coeur, dans un fichier de configuration transmis à l'ordonnanceur et qui a donc été par exemple déterminé lors de la conception de l'architecture. L'ordonnanceur comporte également des moyens de nettoyage du processeur et 35 du coeur à la fin de l'exécution d'un applicatif. 3053140 5 Ainsi et comme cela est illustré sur la figure 4, pour chaque coeur, l'ordonnanceur lance plusieurs étapes consistant à : -initialiser le coeur, - lancer l'exécution de l'application, 5 - nettoyer le coeur à la fin de l'application, et - mettre le coeur en sommeil. Bien entendu des mécanismes de contrôle externe peuvent également être mis en oeuvre, tels que par exemple des mécanismes de type Chien de Garde. Un tel mécanisme de type Chien de Garde peut d'ailleurs être mis en oeuvre par 10 coeur du processeur et initialisé par l'ordonnanceur. Cet ordonnanceur peut par exemple être hébergé et cadencé par l'un des coeurs du processeur. Bien entendu d'autres modes de réalisation peuvent être envisagés. On conçoit alors que grâce à une telle architecture, on peut utiliser un processeur 15 multi-coeurs afin de pouvoir, grâce à ses fonctionnalités et grâce à sa puissance de calcul, regrouper en un seul composant, l'ensemble des applications actuellement exécutées sur plusieurs composants monocoeur indépendants. Ce regroupement est bien entendu fait en respectant les exigences et les contraintes notamment au niveau des ségrégations applicatives. 20 Le développement de l'ordonnanceur permet alors un fonctionnement du processeur multi-coeurs en un parmi N, N étant le nombre total de coeurs disponibles. Cette approche autorise à considérer que l'on peut garantir l'indépendance des applicatifs entre eux et des applicatifs vis-à-vis des ressources internes du processeur. Lors de la conception, on détermine l'ensemble du graphe d'exécution en fonction 25 des besoins de chaque applicatif. L'ensemble des coeurs est synchronisé autour d'un seul arbre d'horloge utilisant une horloge de référence ou de synchronisation externe unique. Ainsi l'ensemble des coeurs peut être considéré comme étant synchrone. Au lancement, l'ensemble des coeurs va donc être synchronisé autour de l'horloge 30 mère de l'architecture et chaque coeur, durant sa phase d'initialisation, va se programmer en interne selon l'analyse préalable d'isolement qui a été faite pendant la phase de conception de cette architecture afin que, lors de l'exécution, chaque période de temps pour un coeur soit indépendante de celle des autres coeurs. Ceci permet de ségréger de façon extrêmement sûre l'exécution des applicatifs 35 sur chacun des coeurs. 3053140 6 En effet durant une période de temps donnée, un et un seul coeur est actif et dispose de l'ensemble du processeur, c'est-à-dire que celui-ci se comporte alors comme un processeur monocoeur. L'applicatif se retrouve alors à être exécuté sur un processeur actif alors 5 monocoeur. Une fois l'application terminée, l'ordonnanceur reprend la main et s'assure du nettoyage du processeur et de sa mise en veille. L'utilisation des mécanismes de contrôle par Chien de Garde par exemple permet de contrôler que l'ensemble de l'exécution des applicatifs est correct. 10 On conçoit alors que cette architecture permet de regrouper en un seul composant plusieurs applicatifs qui sont actuellement exécutés ou qui sont à exécuter par plusieurs équipements différents. Cette approche permet d'offrir un meilleur rapport entre performance, puissance dissipée et encombrement car il favorise une approche multi monoprocesseurs, 15 permettant d'offrir une indépendance totale et entière entre chaque applicatif s'exécutant sur chacun des coeurs. Bien entendu d'autres modes de réalisation encore peuvent être envisagés. REVENDICATIONS1.- Architecture de calcul notamment pour un système embarqué aéronautique autonome, fédéré ou d'avionique modulaire intégré (IMA), comportant des moyens (25) à processeur d'exécution d'applicatifs, caractérisée en ce que les moyens à processeur d'exécution comprennent un processeur (25) multi-coeurs (26, 27, 28, 29) associé à un ordonnanceur (30) de gestion du fonctionnement de ce processeur, permettant de faire exécuter les applicatifs par les coeurs du processeur, d'une façon séquentielle et ségrégée, en respectant des contraintes de partitionnement déterminées en activant un et un seul coeur à la fois. 2.- Architecture de calcul selon la revendication 1, caractérisée en ce que l'ordonnanceur (30) est adapté pour définir un cycle d'activation des coeurs (26, 27, 28, 29) les uns à la suite des autres. 3.- Architecture de calcul selon la revendication 2, caractérisée en ce que le cycle d'activation des coeurs (26, 27, 28, 29) est programmé par coeur dans un fichier de configuration (31) transmis à l'ordonnanceur (30). 4.- Architecture de calcul selon l'une quelconque des revendications précédentes, caractérisée en ce que l'ordonnanceur (30) comporte des moyens de stockage d'informations, pour chaque coeur et chaque applicatif à exécuter, relatives a : - l'instant de démarrage de l'exécution de l'applicatif (IDem), et - la durée d'exécution de l'applicatif (DE). 5.- Architecture de calcul selon la revendication 4, caractérisée en ce que l'ordonnanceur (30) comporte également des moyens de stockage, pour chaque coeur et chaque applicatif à exécuter, d'informations relatives à un temps d'isolement (Tl) des coeurs (26, 27, 28, 29) les uns par rapport aux autres. 6.- Architecture de calcul selon les revendications 3 et 4 ou 5, caractérisée en ce que les informations sont prédéterminées lors de la conception de l'architecture et sont transmises à l'ordonnanceur via le fichier de configuration (31). 3053140 8 7.- Architecture de calcul selon l'une quelconque des revendications précédentes, caractérisée en ce que l'ordonnanceur (30) comporte des moyens de nettoyage du processeur (25) et du coeur (26, 27, 28, 29) à la fin de l'exécution d'un applicatif. 5 8.- Architecture de calcul selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comporte un mécanisme de contrôle externe de type Chien de Garde. 9.- Architecture de calcul selon la revendication 8, caractérisée en ce qu'elle 10 comporte un mécanisme de contrôle externe de type Chien de Garde par coeur (26, 27, 28, 29) du processeur (25) et initialisé par l'ordonnanceur (30). 10.- Architecture de calcul selon l'une quelconque des revendications précédentes, caractérisée en ce que l'ordonnanceur (30) est hébergé et cadencé par l'un 15 des coeurs (26, 27, 28, 29) du processeur.