Brevet FR3104279A1 — publié le 20210611

L’invention concerne un procédé de gestion d’accès à une ressource partagée dans un système électronique comprenant une unité de contrôle et la ressource partagée, l’unité de contrôle étant destinée à exécuter des applications candidates à un accès à la ressource partagée, le procédé utilisant un calendrier de périodes d’égale durée, chacune attribuée à une seule desdites applications, pour définir une répartition temporelle d’accès à la ressource partagée, et des indices de pénalité associés à chacune desdites applications, le procédé comprenant des étapes pour traiter conditionnellement des requêtes en accès émises par les applications en fonction de leurs indices de pénalités. Ainsi, chaque application est empêchée d’accéder à la ressource partagée quand le quota qui lui est attribué est atteint, ce qui permet de limiter l’empiètement d’une application qui s’exécute, sur les quotas d’accès à la ressource attribués aux autres applications. Figure à publier avec l’abrégé : Fig. 4 GESTION D’ACCES A UNE RESSOURCE PARTAGEE PAR UNE PLURALITE D’APPLICATIONS La présente invention concerne la gestion d’accès à une ressource partagée par une pluralité d’applications. La présente invention s’applique plus particulièrement au domaine de l’avionique, dans le cadre d’accès à une ressource partagée telle qu’une mémoire non-volatile, dans un système avionique présentant des contraintes temporelles importantes. Les systèmes électroniques et informatiques autonomes, encore appelés communément systèmes embarqués, sont conçus pour effectuer des tâches précises. Ils doivent avoir la capacité d’interagir avec leur environnement (capteurs, actionneurs, etc.) et de gérer les ressources disponibles à cet effet (calculateurs, stockage de données, énergie, etc.). De tels systèmes embarqués sont largement utilisés dans les transports, y compris les transports aériens. Les interactions entre les composants matériels et logiciels sont définies en avionique de façon très rigoureuse, de sorte que des contraintes temporelles inhérentes à un système considéré (contraintes dites « temps-réel ») soient respectées et que divers éléments du système puissent opérer leurs fonctions respectives en parallèle. Les systèmes embarqués en avionique utilisent des architectures dans lesquelles un logiciel applicatif peut être décomposé en plusieurs applications, ou en plusieurs partitions logicielles, parallèlement exécutées par une ou plusieurs plateformes. On entend ici par « plateforme » un ensemble de ressources configurées pour l’exécution d’applications logicielles. Une plateforme comprend, par exemple, une ou plusieurs unités de traitement de données, des mémoires volatiles et non-volatiles, des interfaces d’entrées et de sorties, un ou plusieurs contrôleurs d’accès à des ressources partagées, une ou plusieurs interfaces de connexion à des réseaux, des systèmes d’horloges. Une telle décomposition logicielle est mise en œuvre dans des contextes d’architecture IMA (du sigle anglais « Integrated Modular Avionics » et qui signifie « avionique modulaire intégrée »). Lorsque plusieurs applications ou partitions d’applications partagent une même ressource, il convient d’attribuer des périodes de temps d’exécution et typiquement un ou plusieurs espaces de mémoire à chaque application ou à chaque partition d’applications (dans le cas où l’application considérée est décomposée en plusieurs partitions). Dans le domaine de l’avionique, chaque application implémente une fonction avionique. Pour plus de détails sur le partitionnement temporel et spatial de ressources de traitement (telles que le partage de ressources), on pourra se référer au standard ARINC 653. Il apparaît ainsi que les ressources, telles que des ressources de mémoire, sont partagées dans le temps par des applications ou des partitions d’applications selon des cadencements indépendants. Il résulte de cette approche que plusieurs applications ou partitions d’applications peuvent entrer en concurrence pour accéder à une ressource partagée, telle qu’une mémoire non-volatile. Notamment, les plateformes avioniques mettent à disposition différentes technologies de mémoire non-volatile offrant des caractéristiques et propriétés différentes. Ainsi, des technologies offrent des temps d’accès sensiblement identiques en lecture et en écriture, alors que d’autres technologies présentent une dissymétrie importante entre ces deux types d’opérations. De plus, une opération d’effacement peut requérir un temps beaucoup plus important qu’une opération de lecture ou d’écriture, et le rapport des temps d’exécution requis pour l’accomplissement de cet autre type d’opérations peut être supérieur à 1000, par exemple. Des temps d’accès importants à une ressource partagée, telle qu’une ressource de mémoire, au regard d’une unité d’allocation temporelle et/ou de la périodicité d’activation d’une application, sont tels qu’une ou plusieurs applications, ou partitions d’applications, peuvent ainsi être bloquées par une saturation d’accès à cette ressource partagée. Cette situation correspond à un conflit d’accès à la ressource partagée, ce qui entraîne des temps d’exécution des applications ou partitions d’applications très variables (ralentissement des applications bloquées). Une telle situation peut notamment poser un problème de perte de ségrégation entre les applications par déni de service à cause de comportements inéquitables d’applications, dites « de non-confiance », en ce qui concerne l’accès à une ressource partagée, telle qu’une mémoire non-volatile. La ségrégation entre applications est en outre une propriété nécessaire à la réalisation d’une certification incrémentale dans le domaine de l’avionique. La certification incrémentale permet une réduction importante des coûts d’intégration lorsqu’une ou plusieurs applications doivent être ajoutées ou modifiées. A contrario, un défaut de ségrégation entre applications réduit les possibilités d’optimiser l’avionique en termes de coût, de volume, de poids, de consommation d’énergie et de fiabilité. L’invention a pour but de garantir un quota de temps d’accès à chacune des applications d’un système devant pouvoir accéder à une même ressource partagée. A cet effet, l’invention a pour objet un procédé de gestion d’accès à une ressource partagée dans un système électronique, les accès étant réalisés par des applications concurrentes exécutées par le système électronique, le procédé utilisant un calendrier de périodes d’égale durée, chacune des périodes étant attribuée à une seule des applications de sorte à définir un séquencement des accès et à attribuer à chacune des applications un quota d’accès à la ressource partagée, le procédé comprenant des étapes pour : - appliquer une pénalité à toute application parmi les applications, dont un temps d’accès à la ressource partagée excède, pour au moins une période du calendrier attribuée à l’application, le quota attribué à l’application, la pénalité étant dépendante d’une durée de dépassement d’un temps unitaire prédéfini, et, - traiter conditionnellement des requêtes en accès à la ressource partagée de sorte que, lorsqu’une première application peut accéder à la ressource partagée selon la séquence définie par le calendrier, ignorer une requête en accès émise par la première application si une pénalité appliquée à la première application n’est pas apurée et considérer d’autoriser l’accès à la ressource partagée à une seconde application qui suit en séquence la première application, selon le calendrier, et sinon, traiter une éventuelle requête en accès en attente pour la première application si la pénalité est inexistante ou apurée. Ainsi, chaque application est empêchée d’accéder à la ressource partagée quand le quota qui lui est attribué est atteint. Cela permet alors de limiter l’empiètement de l’application qui s’exécute sur les quotas d’accès à la ressource partagée attribués aux autres applications. La ségrégation entre applications est ainsi assurée, ce qui rend possible une certification incrémentale des applications. Selon un mode de réalisation de l’invention, le procédé est implémenté sous la forme d’une liste d’identifiants des applications, dites candidates, les étapes d’application d’une pénalité et de traitement conditionnel des accès comprennent des étapes pour lire de façon répétée la liste d’identifiants des applications candidates et, pour chacune des lectures d’un identifiant de la liste : i) lire l’indice de pénalité associé à l’application candidate et décrémenter l’indice de pénalité associé, sans traitement de la requête en accès, lorsque l’indice de pénalité lu est supérieur à un seuil prédéterminé, ii) lorsque l’indice de pénalité lu est inférieur ou égal au seuil prédéterminé, déterminer la présence d’une éventuelle requête en accès à la ressource partagée par l’application candidate correspondant à l’identifiant lu, iii) en présence d’une requête en accès, traiter la requête en accès, puis éventuellement incrémenter l’indice de pénalité associé à l’application candidate, d’un coefficient indexé sur un temps d’accès à la ressource partagée pour traiter la requête en accès, et, iv) attendre qu’un délai égal à la durée desdites périodes soit écoulé depuis la dernière lecture d’un identifiant de la liste. Selon un mode de réalisation de l’invention, la ressource partagée est une mémoire non volatile. Avantageusement, chacune des requêtes en accès concerne un type d’accès parmi deux types prédéfinis, qui sont la lecture et l’écriture. Selon un mode de réalisation de l’invention, chacune des requêtes en accès concerne un type d’accès parmi trois types prédéfinis, qui sont la lecture, l’écriture, et l’effacement. Avantageusement, le coefficient utilisé pour l’incrémentation de l’indice de pénalité est une valeur prédéfinie selon le type de la requête en accès (lecture, écriture ou effacement). Selon un mode de réalisation de l’invention, le coefficient utilisé pour l’incrémentation de l’indice de pénalité est une valeur correspondant à un temps d’accès mesuré pendant le traitement de la requête en accès à la ressource partagée. L’invention a également pour objet un dispositif gestionnaire d’accès à une ressource partagée dans un système électronique, les accès étant réalisés par des applications concurrentes exécutées par le système électronique, le dispositif implémentant un calendrier de périodes d’égale durée, chacune des périodes étant attribuée à une seule des applications de sorte à définir un séquencement des accès et à attribuer à chacune des applications un quota d’accès à la ressource partagée, le dispositif comprenant une circuiterie électronique configurée pour : - appliquer une pénalité à toute application, parmi les applications, dont un temps d’accès à la ressource partagée excède, pour au moins une période du calendrier attribuée à l’application, le quota attribué à l’application, la pénalité étant dépendante d’une durée de dépassement d’un temps unitaire prédéfini, et, traiter conditionnellement des requêtes en accès à la ressource partagée de sorte que, lorsqu’une première application peut accéder à la ressource partagée selon la séquence définie par le calendrier, ignorer une requête en accès émise par la première application si une pénalité appliquée à la première application n’est pas apurée et considérer d’autoriser l’accès à la ressource partagée à une seconde application qui suit en séquence la première application, selon le calendrier, et sinon, traiter une éventuelle requête d’accès en attente pour la première application si la pénalité est inexistante ou apurée. L’invention a également pour objet un système électronique comprenant une ressource partagée et un dispositif gestionnaire d’accès à la ressource partagée tel que précité. L’invention concerne en outre un système électronique tel que susmentionné et configuré pour implémenter des fonctions avioniques dans lesquelles des accès à au moins une ressource partagée sont gérés par le gestionnaire d’accès à la ressource partagée décrit précédemment. Enfin, l’invention a pour objet un aéronef comprenant au moins un système électronique tel que décrit ci-avant. Les caractéristiques de l’invention mentionnées ci-dessus, ainsi que d’autres, apparaîtront plus clairement à la lecture de la description suivante d’au moins un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : illustre schématiquement un système électronique comprenant une unité de contrôle et une ressource partagée et mettant en œuvre un procédé de gestion d’accès à la ressource partagée selon un mode de réalisation particulier et non limitatif de l’invention ; illustre schématiquement l’unité de contrôle du système déjà représentée sur la Fig. 1A comportant un gestionnaire d’accès à une ressource partagée selon un mode de réalisation particulier et non limitatif de l’invention ; illustre un calendrier de répartition temporelle des accès à une ressource partagée par une pluralité d’applications tel qu’utilisé par le procédé de gestion des accès selon l’invention ; illustre une liste d’identifiants d’applications établie à partir du calendrier de répartition temporelle représenté sur la Fig. 2 ; est un ordinogramme représentant les étapes d’un procédé de gestion d’accès à une ressource partagée, selon un mode de réalisation particulier et non limitatif de l’invention ; est un ordinogramme représentant une variante du procédé de gestion d’accès, selon l’invention, déjà illustré sur la Fig. 4 ; est un ordinogramme représentant une variante du procédé de gestion d’accès, selon l’invention, déjà illustré sur les Figs. 4 et 5 ; et représente un aéronef comprenant un système électronique embarqué comprenant lui-même un gestionnaire d’accès à une ressource partagée, selon un mode de réalisation particulier et non limitatif de l’invention. EXPOSE DETAILLE DE MODES DE REALISATION La Fig. 1A illustre schématiquement un système électronique 100 comprenant une unité de contrôle 110 et une ressource partagée 120 accessible à partir de l’unité de contrôle 110 à travers un bus de connexion 130. Dans la description qui suit, il est considéré et décrit que la ressource partagée est une mémoire, et plus particulièrement une mémoire non volatile. Bien évidemment, l’exemple choisi est non limitatif et la ressource partagée peut être d’un autre type, tel qu’un actionneur, un capteur, un calculateur, par exemple. La mémoire non volatile 120 utilise une technologie de type NOR Flash (une technologie basée sur une structure élémentaire de type NOR, par opposition à la technologie de mémoire Flash de type NAND). Selon des variantes, la mémoire non volatile 120 utilise une technologie nvSRAM (sigle anglais de « non-volatile Static Random-Acess Memory » et qui signifie « mémoire statique non volatile à accès aléatoire »), MRAM (sigle anglais de « Magnetic Random Acess Memory » et qui signifie « mémoire magnétique à accès aléatoire »), FRAM (sigle anglais de « Ferroelectric Random Access Memory » et qui signifie « mémoire ferro-électrique à accès aléatoire ») ou encore eMMC (sigle anglais de « embedded Multimedia Card » et qui signifie « carte multimédia à contrôleur embarqué »). L’unité de contrôle 110 est destinée à exécuter en parallèle des applications ou partitions d’applications A1, A2, A3 et A4 dont les codes exécutables respectifs sont stockés dans une mémoire non volatile 113 (visible sur la FIG. 1B) du système électronique 100 avant exécution. Dans la suite de la description, on nommera indifféremment une application ou une partition d’applications par le terme « application ». L’unité de contrôle 110 comprend un microprocesseur, un module de mémoire non volatile pour le stockage de code exécutable et de données, un module de mémoire vive pour l’exécution du code exécutable et le stockage de données de type variables ou piles, ainsi qu’un ensemble de circuits connexes utiles au fonctionnement de son cœur numérique parmi lesquels une interface d’alimentation en énergie, des ports d’entrées-sorties, de ports d’interruption, des circuits d’horloges, un ou plusieurs circuits de remise à zéro, des circuits de supervision d’alimentation, cette liste étant non exhaustive. La Fig. 1A représente un cas où les applications A1, A2 et A3 sont exécutées parallèlement par l’unité de contrôle 110. En d’autres termes, les applications A1, A2 et A3 sont concurrentes dans le système électronique 100. L’exécution concurrente des applications A1, A2, A3 est telle que les applications A1, A2 et A3 partagent la mémoire non volatile 120 et, par voie de conséquence, le bus de connexion 130 à la mémoire non volatile 120. Les accès exécutés dans la mémoire non volatile 120, par les applications A1, A2, et A3, sont de différents types (par exemple lecture, écriture et effacement). Chaque type d’accès requiert un temps spécifique pour son exécution. Selon l’invention, un accès d’un type donné requiert une génération d’une requête en accès d’un type correspondant. Il est ainsi possible d’identifier chacun des types d’accès à la mémoire par un identifiant de type. Il est ainsi défini qu’un accès en lecture dans la mémoire non volatile 120 est un accès de type 0, un accès en écriture dans la mémoire non volatile 120 est un accès de type 1 et un accès en effacement dans cette même mémoire est un accès de type 2. Lorsque l’une des applications A1, A2 ou A3 réalise un accès d’un quelconque type précité à la mémoire non volatile 120, les autres applications ne peuvent y avoir accès, ce qui peut être préjudiciable à une bonne exécution des tâches respectivement opérées par ces autres applications si la période d’inaccessibilité à la mémoire non volatile 120 venait à se prolonger durablement. Une spécificité des mémoires non volatiles est qu’il existe une disparité sensible en termes de temps d’exécution entre des accès de types différents. On retrouve aussi cette disparité vis-à-vis d’autres types de ressources partagées. Ainsi, une opération d’écriture (ou de type 1) dans une cellule de la mémoire 120 requiert un temps plus long qu’une opération de lecture (ou de type 0) dans la mémoire 120. De façon analogue, une opération d’effacement (ou de type 2) d’une cellule de la mémoire non volatile 120 requiert un temps beaucoup plus long qu’une opération d’écriture ou de lecture dans cette même mémoire. Selon la technologie de mémoire utilisée, le ratio entre le temps d’exécution d’une opération de lecture et d’une opération d’écriture peut être plus ou moins important. La lecture est l’accès qui requiert le moins de temps. Dans la suite de la description et à des fins explicatives, les temps d’accès à la mémoire non volatile 120 sont exprimés en multiples d’un temps unitaire d’accès à la mémoire. Ce temps unitaire d’accès à la mémoire est défini de sorte que chacun des différents types d’accès a une durée égale à ce temps unitaire ou à un multiple de celui-ci. Dans l’exemple qui va suivre, le temps unitaire est le temps maximal requis pour compléter une opération de lecture dans la mémoire non volatile 120 à partir de l’unité de contrôle 110, exécutée par l’une quelconque des applications A1, A2, A3. Toujours selon cet exemple, le temps d’accès maximal en écriture à la mémoire non volatile 120 est le double du temps d’accès en lecture. La durée d’un temps d’accès en écriture est donc égale à 2 temps d’accès unitaires. Le temps d’accès à la mémoire non volatile 120 requis pour un effacement d’une cellule de la mémoire est, toujours selon l’exemple décrit, de 4404 fois le temps de lecture, soit égal à 4404 temps unitaires. Comme détaillé ci-après, la gestion d’accès à une ressource partagée par une pluralité d’applications, selon l’invention, permet d’attribuer des fenêtres temporelles à chaque application grâce à une utilisation astucieuse d’un calendrier. Cela permet d’attribuer à chacune des applications A1, A2 et A3, exécutées parallèlement, un pourcentage de la bande passante disponible pour un accès à la ressource partagée (e.g., la mémoire non-volatile 120 via le bus de connexion 130). Selon le mode de réalisation préféré de l’invention, la gestion des accès à la mémoire non volatile 120 partagée entre les applications A1, A2 et A3 est opérée par un dispositif gestionnaire d’accès, intégré à l’unité de contrôle 110. La Fig. 1B est une représentation schématique de l’unité de contrôle 110 déjà représentée sur la Fig. 1A. L’unité de contrôle 110 comprend un microprocesseur 111, un module de mémoire non volatile 113 comprenant des zones dédiées au stockage des codes exécutables en correspondance des applications A1, A2, A3, A4, et un module de mémoire vive 115. Selon l’exemple qui va être décrit, l’application A4, bien que disponible dans la mémoire non volatile 113 du système électronique 100, n’est pas exécutée par l’unité de contrôle 110 et seules les applications A1, A2 et A3 sont candidates à des accès à la mémoire non volatile 120. Le microprocesseur 111, le module de mémoire non volatile 113 et le module de mémoire vive 115 sont reliés entre eux par un bus d’interconnexion 117. Un gestionnaire d’accès 119 est connecté au bus d’interconnexion 119 et à un bus 121 adapté à la connexion de la mémoire non volatile 120 à l’unité de contrôle 110. Le bus 130 représenté sur la Fig. 1B est connecté au bus 121 interne à l’unité de contrôle 111. Le gestionnaire d’accès à la mémoire non volatile 120 organise un partage de la mémoire non volatile 120 en fonction d’une répartition temporelle astucieusement définie au moyen d’un calendrier comprenant un nombre prédéterminé de périodes d’égale durée, chacune attribuée à l’une seulement des applications A1, A2, A3 parallèlement exécutées par l’unité de contrôle 110 et donc candidate à un accès à la mémoire non volatile 120. Le gestionnaire d’accès 119 comprend une circuiterie électronique, par exemple un microcontrôleur interne, un module de mémoire vive et un ensemble de registres utiles à la mise en œuvre du procédé selon l’invention, ainsi que tous les éléments usuels connexes nécessaires au fonctionnement de ces éléments. La Fig. 2 représente un calendrier 201 comprenant 100 périodes 2001 à 2100 d’égale durée. Chacune des périodes 2001 à 2100 du calendrier 201 est attribuée à une des applications candidates à un accès à la mémoire non volatile 120. L’instanciation du calendrier est telle qu’un parcours des périodes selon leur numérotation incrémentale (soit de gauche à droite sur la Fig. 2) correspond au temps qui passe. Astucieusement, et selon l’invention, chacune des périodes du calendrier a une durée théorique correspondant au temps unitaire susmentionné, soit selon l’exemple décrit, égale au temps d’accès en lecture à la mémoire non volatile 120 depuis le microprocesseur 111 de l’unité de contrôle 110. Avantageusement, les périodes 2001 à 2100 du calendrier 201 sont attribuées aux applications de sorte à répartir au mieux les différentes occurrences d’une même application dans le calendrier. Ainsi, si par exemple une application doit pouvoir bénéficier d’un accès à la ressource partagée 120 pendant un tiers du temps en moyenne, le calendrier 210 est configuré de sorte qu’une période sur trois est attribuée à cette application et un identifiant de cette application est lu une période sur trois quand le calendrier est parcouru selon son sens de lecture. L’attribution des périodes du calendrier aux applications peut être définie par programmation lors de la fabrication du système électronique 100 ou encore lors d’une opération de configuration. La configuration du calendrier peut être figée ou encore modifiable dynamiquement en fonctions de paramètres tels que, par exemple, la nature de fonctions exécutées par les applications dans le système électronique 100 et un coefficient de criticité affecté à chacune de ces fonctions. La méthode d’attribution de périodes du calendrier permettrait une répartition temporelle des accès à la mémoire répartie selon le nombre d’occurrences de chacune des applications dans le calendrier, si tous les accès à la mémoire étaient de durée égale. Or, comme indiqué précédemment et selon le mode de réalisation décrit, la durée d’un accès à la mémoire non volatile 120 diffère d’un type d’accès à un autre. Considérant cette disparité de temps d’accès selon le type d’accès réalisé (lecture, écriture ou effacement), la répartition temporelle réelle entre les applications A1, A2, A3 peut ne pas correspondre à celle définie par le calendrier 201, si chaque période du calendrier correspond à un temps unitaire. Ainsi, si par exemple l’application A1 réalise un accès en lecture pendant la période 2001 du calendrier, et l’application A2 initie un accès en écriture pendant la période 2002 du calendrier, la mémoire non volatile 120 est rendue indisponible jusqu’à la fin de la période 2003 du calendrier (en considérant que la durée d’écriture étant égale à deux temps unitaires, soit deux périodes du calendrier 201). Si l’application A1 veut initier un accès quelconque pendant la période 2003 du calendrier, tel que le calendrier représenté le prévoit, l’application A1 en est empêchée, puisque la mémoire non volatile 120 n’est pas encore disponible (du fait d’une écriture en cours). La répartition temporelle selon le calendrier 201 n’est alors pas respectée. Afin de pallier cette iniquité, la gestion des accès à la mémoire non volatile 120 selon l’invention attribue astucieusement une pénalité à une application, chaque fois que cette application monopolise la mémoire non-volatile 120 plus longtemps que le temps d’accès en correspondance du type d’accès le plus court, soit, selon l’exemple décrit, plus longtemps qu’un temps d’accès unitaire. Un coefficient de pénalité est alors attribué à l’application, ce coefficient de pénalité étant égal au dépassement du temps théorique attribué par le calendrier (soit la durée d’une période du calendrier ou encore le temps unitaire). Selon ce principe, un accès en lecture n’entraîne pas de pénalité, un accès en écriture entraîne une pénalité supplémentaire d’un coefficient égal à 1, et un accès en effacement entraîne une pénalité supplémentaire d’un coefficient égal à 4403. Pour chacune des périodes du calendrier, si une application candidate veut accéder à la mémoire non volatile 120, elle ne peut pas le faire tant que son indice de pénalité est supérieur à un seuil prédéterminé (préférentiellement fixé à 0). Lorsqu’une application est ainsi privée d’un accès à la mémoire non volatile 120, aucun nouvel accès n’est initié pour cette application pendant la période du calendrier en correspondance et son indice de pénalité est décrémenté. L’accès sollicité à la mémoire n’est pas purement et simplement rejeté, mais mémorisé dans une file d’attente d’accès à la mémoire non-volatile 120. La période du calendrier est dans ce cas utilisée au profit d’une autre application dont un accès est en attente de traitement (du fait d’une indisponibilité de la mémoire non volatile 120 déjà monopolisée par un accès). Selon un mode de réalisation de l’invention, chaque application A1, A2 ou A3 candidate à des accès à la mémoire se voit attribuer par le gestionnaire d’accès 119 une zone mémoire tampon (« buffer » en anglais) de type « circulaire » pour le stockage de requêtes en accès à la mémoire non-volatile 120 (c’est-à-dire pour l’implémentation de sa file d’attente d’accès à la mémoire non volatile 120). Ces mémoires tampon circulaires WF A1 , WF A2 et WF A3 sont donc respectivement associées aux applications A1, A2, A3 candidates à un accès à la mémoire non volatile 120. Selon un mode de réalisation de l’invention, les mémoires tampon circulaires sont implémentées dans un module de mémoire vive interne au gestionnaire d’accès 119. Chaque mémoire tampon circulaire dédiée à l’une des applications A1, A2 et A3 (soit chaque liste de requêtes en attente de traitement) est traitée par un module de traitement des requêtes en accès, interne au gestionnaire d’accès 119 selon le principe d’une mémoire FIFO (sigle anglais de « First-In First Out » et qui signifie « premier entré, premier sorti). Selon une variante, une seule mémoire tampon peut être utilisée pour l’ensemble des requêtes en accès de l’ensemble des applications candidates, cette solution étant toutefois plus complexe à mettre en œuvre, puisqu’elle exige un mode de scrutation plus détaillé du contenu de la mémoire tampon circulaire commune. Comme détaillé ci-après, l’implémentation du principe de répartition temporelle selon le calendrier 201 et des indices de pénalité respectivement associés à chacune des applications candidates à des accès à la mémoire non volatile 120 est, dans un mode de réalisation particulier, réalisé grâce à une liste 301 d’identifiants d’applications et à des indices de pénalité, chacun de ces indices étant associé à une application candidate à des accès à la mémoire non volatile 120. Des indices de pénalités CP A1 , CP A2 , CP A3 sont donc respectivement associés aux applications A1, A2 et A3, et sont typiquement implémentés sous forme de variables, c’est-à-dire de valeurs stockées dans des registres internes au gestionnaire d’accès 119. Les valeurs des indices de pénalités CP A1 , CP A2 , CP A3 sont incrémentées ou décrémentées comme détaillé ci-après, sous contrôle du gestionnaire d’accès 119. La Fig. 3 représente la liste 301 d’identifiants d’applications générée à partir du calendrier 201. La liste 301 d’identifiants d’applications constitue une implémentation du calendrier 201 et comprend pour ce faire un nombre d’identifiants 3001 à 3100 égal au nombre de périodes 2001 à 2100 du calendrier 201. Avantageusement, lorsque le calendrier 201 et la liste 301 d’identifiants d’applications comprennent chacun 100 éléments, il est possible d’effectuer une répartition temporelle avec une précision de 1%. Bien évidemment, le calendrier et la liste 301 d’identifiants d’applications peuvent avoir un nombre d’éléments inférieur ou supérieur à 100, mais le nombre d’éléments de la liste 301 d’identifiants d’applications est toujours identique au nombre d’éléments du calendrier (considérant que la liste 301 d’identifiants d’applications contient une copie unique du calendrier 201). Ainsi, si le calendrier 201 comprend 200 périodes, la répartition temporelle des accès peut être définie avec une précision de 0,5 %. La Fig. 4 est un ordinogramme représentant un procédé de gestion des accès à la mémoire non volatile 120, implémenté par le gestionnaire d’accès 119, selon un mode de réalisation de l’invention. Selon ce mode de réalisation, les accès en effacement de la mémoire, bien plus longs que les accès en lecture ou écriture, ne sont traités que lors de moments dédiés à l’effacement, comme par exemple lors d’une phase d’extinction ou de mise en veille du système électronique 100, ou encore à un ou des moments définis selon la disponibilité globale de la ressource en question. Le descriptif illustré par la Fig. 4 ne s’attache alors qu’à la gestion d’accès en lecture et en écriture à la mémoire non volatile 120. Une étape d’initialisation S0 exécute une initialisation complète du système 100 pendant laquelle l’ensemble des circuits est initialisé et au terme de laquelle les applications A1, A2 et A3 commencent à être exécutées par l’unité de contrôle 110. Dans la suite de la description, il est à noter que le gestionnaire d’accès 119 opère des cycles itératifs de lectures successives des éléments de la liste 301 et utilise pour ce faire une indexation grâce à un pointeur interne 3200 (représenté sur la Fig. 3). En d’autres termes, le gestionnaire d’accès 119 utilise le pointeur interne 3200 pour parcourir successivement l’ensemble des éléments de la liste 301 d’identifiants d’applications, puis recommence en début de liste lorsque le dernier élément de la liste 301 d’identifiants d’applications a été lu. On nommera « élément courant », l’élément de la liste indexé à un instant donné par le pointeur interne 3200. En outre, le terme « bénéficiaire » associé à une application qualifie, dans la suite de la description, l’application à laquelle est attribuée la période du calendrier 201 en correspondance de l’élément courant de la liste 301 d’identifiants d’applications. Ainsi, une « application bénéficiaire » désigne une application candidate à un accès à la mémoire non volatile 120, ayant émis une requête en accès à la mémoire non volatile 120, et dont le calendrier 201 précise qu’elle est éligible à un tel accès ou non selon l’indice de pénalité qui lui est attribué. Pendant l’étape d’initialisation S0, le calendrier 201, initialement stocké dans le module de mémoire non volatile 113, est recopié dans une mémoire interne du gestionnaire d’accès 119, générant ainsi la liste 301 d’identifiants d’applications. Une lecture d’un élément de la liste 301 d’identifiants d’applications est réalisée, lors d’une étape S1, par le gestionnaire d’accès 119. A chaque lecture de l’élément courant, le pointeur interne 3200 est incrémenté, de sorte à parcourir la liste 301 d’identifiants d’applications au fil des lectures itératives de l’élément courant. Cette lecture est combinée à une initialisation d’un compteur t de temps écoulé. Le compteur t de temps écoulé est utilisé pour garantir que le prochain élément à lire de la liste 301 d’identifiants d’applications n’est pas lu avant le terme d’un délai égal au temps d’accès unitaire (soit la durée d’une période du calendrier). Ainsi, si une application candidate éligible à un accès à la mémoire non volatile 120 pendant une période donnée du calendrier a émis au moins une requête en accès (i.e., au moins une telle requête en attente dans la file d’attente correspondante), et que son indice de pénalité est nul, la requête en accès est traitée. Cependant, si cette application candidate à un accès, bien qu’étant éligible (à un accès), puisque son identifiant est associé à la période courante du calendrier, n’a pas émis de requête en accès (i.e., pas de telle requête en attente dans la file d’attente correspondante), alors aucun nouveau traitement de requête en accès n’est initié au niveau du gestionnaire d’accès 119 pendant une période d’une durée égale à un temps unitaire (soit une durée d’une période de calendrier). En d’autres termes, la scrutation de la liste 301 d’identifiants d’applications vise ainsi à identifier la prochaine application parmi A1, A2 et A3 qui, selon la séquence définie par le calendrier 201, a émis une requête en accès à la mémoire non volatile 120 et n’est pas ou plus affectée d’une pénalité qui lui était attribuée du fait d’au moins un dépassement de quota antérieur. Lors d’une étape S2, le gestionnaire d’accès 119, ayant identifié quelle est l’application candidate à laquelle est attribuée la période du calendrier pointée par le pointeur interne 3200, lit l’indice de pénalité associé à l’application en question, soit par exemple la valeur de CP A2 , et traite conditionnellement la requête en accès selon que l’indice de pénalité excède le seuil prédéterminé susmentionné ou non. Selon le mode de réalisation préféré de l’invention, ledit seuil prédéterminé est fixé à 0, c’est-à-dire que plus le nombre de cycles de lectures déjà effectués de l’ensemble de la liste 301 d’identifiants d’applications est grand, plus la répartition temporelle d’accès à la mémoire non volatile 120 entre les différentes applications candidates A1, A2 et A3 tend à être équitable. Selon une variante, ledit seuil prédéterminé est supérieur à 0, ce qui implique qu’une inégalité de répartition temporelle est admise dans le partage des accès à la mémoire non volatile 120 par les différentes applications candidates. Selon le contexte, le seuil prédéterminé auquel l’un des indices de pénalité CP A1 , CP A2 et CP A3 est comparé pendant l’étape S2 peut être modifié dynamiquement pour ajuster la contrainte d’équité entre les différentes applications. Lorsque l’indice de pénalité de l’application bénéficiaire est supérieur au seuil prédéterminé, la requête en accès éventuellement dans la file d’attente de l’application bénéficiaire n’est pas traitée et l’indice de pénalité de l’application bénéficiaire est décrémenté lors d’une étape S21. Il est alors considéré d’autoriser l’accès à la mémoire non volatile 120 à une autre application qui la suit en séquence dans la liste 301 d’identifiants d’applications (et donc dans le calendrier 201). Pour ce faire, le procédé revient à l’étape S1 et une lecture du prochain identifiant d’application est exécutée, ainsi que les étapes subséquentes, selon l’identifiant d’application lu et son indice de pénalité. Dans le cas où l’indice de pénalité de l’application bénéficiaire est inférieur ou égal au seuil prédéterminé, le gestionnaire d’accès 119 scrute à l’étape S3 la mémoire tampon circulaire associée à l’application courante (dont un identifiant est pointé et lu dans la liste des identifiants) afin de déterminer si une requête en accès a été émise par l’application associée à l’identifiant pointé dans la liste. Ainsi, si par exemple l’identifiant d’application lu dans la liste 301 d’identifiants d’applications représente l’application A2, alors le gestionnaire d’accès 119 scrute la mémoire tampon WF A2 de requêtes en accès de l’application A2. Si aucune requête en accès à la mémoire non volatile 120 n’est présente dans la mémoire tampon circulaire de l’application (soit dans notre exemple, l’application A2), aucun nouveau traitement de requête n’est initié et le gestionnaire d’accès 119 effectue une lecture du prochain élément (identifiant d’application) de la liste 301 d’identifiants d’applications après qu’un temps égal à un temps d’accès unitaire se soit écoulé depuis la lecture précédemment réalisée lors de l’étape S1. La comparaison entre le compteur t de temps et la valeur minimale de temps d’attente (soit la durée d’un temps d’accès unitaire) est opérée à une étape S8. Dans le cas où une requête en accès au moins est détectée dans ladite mémoire tampon circulaire à l’étape S3, le gestionnaire d’accès 119 initie un traitement de la requête en accès lors d’une étape S5, après avoir vérifié lors d’une étape S4 que la mémoire non volatile 120 est disponible pour ce faire. Il se peut en effet que, du fait d’un accès en cours suite à un traitement initié dans un cycle de lecture précédent, la mémoire non volatile 120 soit encore indisponible pour un nouvel accès. Dans ce cas, il est procédé à l’étape S4 à une attente de la disponibilité de la mémoire non volatile 120. Il apparaît en conséquence que les périodes de traitement des éléments de la liste 301 d’identifiants d’application sont différentes des périodes « théoriques » du calendrier 201, du fait des temps d’accès parfois prolongés au-delà de la durée d’un temps d’accès unitaire. Lors d’une étape S6, et après avoir initié le traitement d’une requête en accès présentée par l’application bénéficiaire, l’indice de pénalité en correspondance de l’application bénéficiaire est conditionnellement incrémenté, par le gestionnaire d’accès 119 selon le type d’accès sollicité parmi les deux types prédéfinis type 0 et type 1 (lecture ou écriture). Par exemple, si la requête en accès nouvellement traitée requiert un accès à la mémoire non volatile 120 d’une durée supérieure à la durée unitaire, l’indice de pénalité de l’application bénéficiaire est incrémenté d’une pénalité dépendant du type d’accès (par exemple une pénalité égale à 1 est appliquée en cas d’accès en écriture). Autrement dit, pour un temps d’accès égal à n temps d’accès unitaires, la pénalité est P = n – 1. En d’autres termes, une application ayant utilisé n temps d’accès unitaires pour compléter un accès devra « passer son tour » pour les n -1 prochaines lectures de la liste d’identifiants 301 pour laquelle cette application apparaît bénéficiaire, ce qui correspond bien à la répartition temporelle des accès à la mémoire non volatile 120 selon le calendrier 201. Dans le cas où la requête en accès n’est pas identifiée comme concernant un accès d’une durée supérieure au temps d’accès unitaire, il s’agit donc d’une requête d’accès en lecture, et aucune pénalité n’est à appliquer. Selon une variante de réalisation de l’invention, le coefficient de pénalité éventuellement appliqué pour une application en cours d’exécution a une valeur mesurée lors du traitement de la requête en accès. Il ne s’agit pas, dans ce cas, d’une valeur fixe prédéfinie mais du temps réellement mesuré pour effectuer l’accès en question. Dans ce cas, le traitement d’une requête initié à l’étape S5 initialise un compteur de temps dédié à une mesure du temps d’accès. Ce compteur de temps est ensuite incrémenté de sorte à contenir une valeur représentative du temps écoulé depuis son initialisation, jusqu’à ce que l’accès en question soit achevé. Cette indication de temps écoulé lors de l’exécution de l’accès est ensuite utilisée pour la définition du coefficient de pénalité à appliquer. Il ressort de l’ordinogramme de la Fig.4 que l’invention permet avantageusement d’établir une répartition moyenne équitable, au fil du temps, entre les applications qui accèdent à la mémoire non volatile 120, quand bien même les accès sont de types différents, c’est-à-dire opérés parfois en lecture et parfois en écriture, et de durées inégales. La Fig. 5 est un ordinogramme représentant un procédé de gestion des accès à la mémoire non volatile 120, implémenté par le gestionnaire d’accès 119, selon une première variante du procédé schématisé sur la Fig.4. Selon cette première variante, les accès en effacement de la mémoire, bien plus longs que les accès en lecture ou écriture sont traités dans les mêmes cycles de lecture itérative de la liste 301 d’identifiants d’applications. L’ensemble des étapes du procédé représenté sur cette Fig. 5 sont similaires à celles du procédé représenté sur la Fig. 4, hormis que le procédé comporte des étapes additionnelles S7 et S71 qui visent à déterminer si, en l’absence de requête d’accès en écriture, la requête en accès à traiter correspond à une requête de type 2, soit dans le cas décrit, une requête en effacement (étape S7). Le cas échéant, l’indice de pénalité de l’application bénéficiaire est modifié en conséquence (étape S71). Le coefficient de pénalité appliqué est alors égal à 4403 si le temps d’accès en effacement est égal à 4404 temps d’accès unitaires. Cette première variante illustre bien le fait qu’une répartition moyenne équitable s’établit progressivement au fil des cycles de lecture de la liste 301 d’identifiants d’applications, puisque, dans le cas d’une requête en effacement, l’accès correspondant peut nécessiter un temps égal à 4404 temps unitaires, alors qu’une lecture de la liste 301 d’identifiants d’applications dans son ensemble requiert 100 temps unitaires lorsque la liste est dimensionnée pour contenir 100 éléments (identifiants d’applications candidates). Selon cette variante, et comme cela est le cas pour le mode de réalisation précédemment décrit pour lequel les accès ne concernent que les types 0 et 1 (lecture et écriture seulement), le coefficient de pénalité éventuellement appliqué pour une application en cours d’exécution a une valeur définie en fonction d’un temps d’accès prédéfini, soit 1 temps unitaire pour un accès de type 1 (écriture) et 4403 temps unitaires pour un accès pour un accès de type 2 (effacement) , ou encore mesuré lors du traitement de la requête en accès (entre le début du traitement de la requête et la fin de l’accès en question). Selon une seconde variante, la gestion des accès à la mémoire non volatile 120 tient compte, pour chacune des lectures de la liste 301 d’identifiants d’applications, d’un indicateur positionné de sorte à indiquer qu’il convient de traiter les requêtes d’accès en effacement, ou, à l’inverse, de ne pas les traiter. Selon cette seconde variante, il est ainsi possible de modifier dynamiquement le déroulement d’un cycle de lecture de la liste 301 d’identifiants d’applications (étapes S1 à S8, en intégrant conditionnellement le déroulement des étapes S7 et, le cas échéant S71). Une telle configuration dynamique peut être avantageuse en fonction des fonctions implémentées par les différentes applications. Par exemple, lorsqu’une nouvelle application est exécutée, et qu’elle implique des contraintes temporelles sévères (application critique), les accès en effacement ne sont pas traités ; dans le cas contraire, si l’exécution de cette application est suspendue, les accès en effacement sont possibles. Selon cette seconde variante, le coefficient de pénalité éventuellement appliqué pour une application en cours d’exécution a une valeur définie en fonction d’un temps d’accès, prédéfini ou encore mesuré lors du traitement de la requête en accès, comme cela est le cas pour les procédés représentés Figs. 4 et 5. Selon des variantes de l’invention, le gestionnaire d’accès 119 est configuré pour traiter successivement des requêtes de type identique d’accès à la mémoire de sorte à opérer des accès par salves (« burst » en anglais) à la mémoire non volatile 120. Par exemple, cinq requêtes en écriture sont traitées continûment de sorte à générer une salve d’accès à la mémoire non volatile 120 correspondant aux accès définis dans les cinq requêtes successives pour une même application et le coefficient de pénalité appliqué est donc multiplié par cinq. La Fig. 6 est un ordinogramme représentant un procédé de gestion des accès à la mémoire non volatile 120, implémenté par le gestionnaire d’accès 119, selon une autre variante. Selon cette variante, le procédé implémenté comprend une étape S22 supplémentaire, qui vise à définir, dans le cas où l’application bénéficiaire, identifiée par la position courante du pointeur interne 3200 dans la liste 301 d’identifiants d’applications, est affectée d’un indice de pénalité supérieur au seuil prédéterminé (selon le test de l’étape S2), et après avoir décrémenté son coefficient de pénalité (à l’étape S21), si il doit être procédé ou non à une attente d’un temps unitaire correspondant à une durée d’une période de calendrier, selon que l’application précédente en séquence était ou non déjà pénalisée. L’indice de pénalité de l’application correspondant à l’identifiant pointé est nommé CP(n) sur la Fig. 6 et l’indice de pénalité de l’application précédemment pointée est nommé CP(n-1) sur cette même figure. Selon cette variante, lorsqu’après avoir attribué un temps unitaire à une application et éventuellement initié le traitement d’une requête (lors de l’itération précédente ou « n-1 » de lecture d’un identifiant d’application dans la liste 301 d’identifiants d’applications), l’application pointée en séquence (itération courante ou « n » de lecture) est pénalisée du fait d’un ou plusieurs dépassements de quota antérieurs, il est considéré d’autoriser l’accès à la mémoire non volatile 120 à une autre application qui la suit en séquence dans la liste 301 d’identifiants d’applications (et donc dans le calendrier 201). Pour ce faire, le temps unitaire est mis à profit de l’application suivante en séquence dans le calendrier (par branchement à l’étape S1), mais si cette application suivante est également pénalisée (test de l’étape S22), alors il est attendu à l’étape S8 la fin d’un temps unitaire (soit la durée d’une période du calendrier) pour initier le traitement d’une prochaine requête en accès. En d’autres termes, si pour une période considérée du calendrier, l’application bénéficiaire n’a pas de pénalité, il est donné suite à une requête en accès de cette application, le cas échéant. Si au contraire, l’application bénéficiaire a une pénalité, son indice de pénalité est décrémenté et le temps unitaire courant est mis à profit de l’application suivante dans le calendrier. Si pour la période suivante, l’application correspondante n’a pas de pénalité, il est donné suite à une éventuelle requête en accès de sa part, mais si au contraire cette application a également une pénalité à purger, il convient d’attendre la fin du temps unitaire, soit la période suivante du calendrier. Le procédé selon l’invention implémenté dans le gestionnaire d’accès 119 est particulièrement adapté lorsque le système électronique 100 est un système avionique. Ainsi, la Fig. 7 représente un aéronef 6 comprenant le système électronique 100 configuré pour implémenter des applications remplissant des fonctions d’avionique, dont la ségrégation spatiale et temporelle est garantie grâce à l’invention. Procédé de gestion d’accès à une ressource partagée (120) exécuté dans un système électronique (100), lesdits accès étant réalisés par des applications (A1, A2, A3) concurrentes exécutées par le système électronique (100), le procédé utilisant un calendrier (201) de périodes (2000, 2001,…, 2100) d’égale durée, chacune des périodes étant attribuée à une seule desdites applications de sorte à définir un séquencement des accès et à attribuer à chacune desdites applications un quota d’accès à la ressource partagée, le procédé comprenant des étapes pour : - appliquer une pénalité à toute application parmi lesdites applications, dont un temps d’accès à la ressource partagée (120) excède, pour au moins une période du calendrier attribuée à ladite application, le quota attribué à ladite application, la pénalité étant dépendante d’une durée de dépassement d’un temps unitaire prédéfini, et, - traiter conditionnellement des requêtes en accès à la ressource partagée de sorte que, lorsqu’une première application peut accéder à la ressource partagée selon la séquence définie par le calendrier, ignorer une requête en accès émise par la première application si une pénalité appliquée à la première application n’est pas apurée et considérer d’autoriser l’accès à la ressource partagée à une seconde application qui suit en séquence ladite première application, selon le calendrier, et sinon, traiter une éventuelle requête en accès en attente pour la première application si la pénalité est inexistante ou apurée. Procédé selon la revendication précédente, le calendrier étant implémenté sous la forme d’une liste (301) d’identifiants desdites applications, dites candidates, les étapes d’application d’une pénalité et de traitement conditionnel des accès comprenant des étapes pour lire (S1) de façon répétée la liste (301) d’identifiants (3001,…, 3100) desdites applications candidates et, pour chacune des lectures d’un identifiant de la liste : i) lire (S2) l’indice de pénalité (CP A1 , CP A2 , CP A3 ) associé à l’application candidate (A1, A2, A3) et décrémenter (S21) l’indice de pénalité associé, sans traitement de la requête en accès, lorsque l’indice de pénalité lu est supérieur à un seuil prédéterminé, ii) lorsque l’indice de pénalité lu est inférieur ou égal au seuil prédéterminé, déterminer (S3) la présence d’une éventuelle requête en accès à la ressource partagée (120) par l’application (A1, A2, A3) candidate correspondant à l’identifiant (3001,…, 3100) lu, iii) en présence d’une requête en accès, traiter la requête en accès (S4, S5) puis éventuellement incrémenter (S6, S61) l’indice de pénalité associé à l’application candidate, d’un coefficient indexé sur un temps d’accès à la ressource partagée pour traiter ladite requête en accès, et, iv) attendre (S8) qu’un délai égal à la durée desdites périodes soit écoulé depuis la dernière lecture d’un identifiant de la liste. Procédé selon la revendication précédente, dans lequel la ressource partagée (120) est une mémoire non volatile. Procédé selon l’une des revendications 2 et 3, dans lequel chacune des requêtes en accès concerne un type d’accès parmi deux types prédéfinis, qui sont lecture et écriture. Procédé selon l’une quelconque des revendications 2 et 3, dans lequel chacune des requêtes en accès concerne un type d’accès parmi trois types prédéfinis, qui sont lecture, écriture, et effacement. Procédé de gestion d’accès à une ressource partagée selon l’une des revendications 4 et 5, dans lequel le coefficient utilisé pour l’incrémentation de l’indice de pénalité est une valeur prédéfinie selon le type de la requête en accès. Procédé de gestion d’accès à une ressource partagée selon l’une quelconque des revendications 2 à 5, dans lequel le coefficient utilisé pour l’incrémentation de l’indice de pénalité est une valeur correspondant à un temps d’accès mesuré pendant le traitement de la requête en accès à la ressource partagée. Dispositif gestionnaire d’accès à une ressource partagée (120) dans un système électronique (100), lesdits accès étant réalisés par des applications (A1, A2, A3) concurrentes exécutées par le système électronique (100), le dispositif implémentant un calendrier (201) de périodes (2000, 2001,…, 2100) d’égale durée, chacune des périodes étant attribuée à une seule desdites applications de sorte à définir un séquencement des accès et à attribuer à chacune desdites applications un quota d’accès à la ressource partagée, le dispositif comprenant une circuiterie électronique configurée pour : - appliquer une pénalité à toute application, parmi lesdites applications, dont un temps d’accès à la ressource partagée (120) excède, pour au moins une période du calendrier attribuée à ladite application, le quota attribué à ladite application, la pénalité étant dépendante d’une durée de dépassement d’un temps unitaire prédéfini, et, - traiter conditionnellement des requêtes en accès à la ressource partagée de sorte que, lorsqu’une première application peut accéder à la ressource partagée selon la séquence définie par le calendrier, ignorer une requête en accès émise par la première application si une pénalité appliquée à la première application n’est pas apurée et considérer d’autoriser l’accès à la ressource partagée à une seconde application qui suit en séquence ladite première application, selon le calendrier, et sinon, traiter une éventuelle requête d’accès en attente pour la première application si la pénalité est inexistante ou apurée. Système électronique (100) comprenant une ressource partagée (120) et un dispositif gestionnaire d’accès (119) à la ressource partagée (120) selon la revendication précédente. Système électronique (100) selon la revendication précédente, configuré pour implémenter des fonctions avioniques dans lesquelles des accès à au moins une ressource partagée sont gérés par le gestionnaire d’accès (119) à la ressource partagée (120) selon la revendication 8. Aéronef (6) comprenant au moins un système électronique (100) selon la revendication 9 ou 10.