Brevet FR3096491A1 — publié le 20201127

Description Titre de l'invention : gestion d'accès à une ressource partagée PAR une pluralité de coeurS D'UN PROCESSEUR MULTIcoeur Domaine technique [0001] La présente invention concerne la gestion d'accès à une ressource partagée par une pluralité de coeurs d'un processeur multicoeur dans un composant électronique de type SoC (« System on Chip » en terminologie anglo-saxonne). La présente invention s'applique plus particulièrement dans le domaine de l'avionique, dans le cadre de calculateurs incluant au moins un tel processeur multicceur. Technique antérieure [0002] Les composants électroniques de type SoC (« System on Chip » en terminologie anglo-saxonne) sont des circuits intégrés qui combinent différents composants usuels des ordinateurs, tels que de la mémoire et un ou plusieurs processeurs, sur un même substrat. Alors qu'une carte mère traditionnelle héberge et interconnecte un ensemble de composants électroniques implémentant des fonctionnalités respectives, les composants électroniques de type SoC intègrent toutes ces fonctionnalités dans un seul circuit intégré. Les composants électroniques de type SoC sont de plus en plus utilisés, notamment dans le domaine des calculateurs en avionique, pour le gain de place et de consommation énergétique qu'ils procurent. [0003] Certains composants électroniques de type SoC intègrent un ou plusieurs processeurs multicceur (« multicore processor » en terminologie anglo-saxonne), de manière à pouvoir paralléliser des exécutions d'applications. Plusieurs applications peuvent partager un même coeur, mais à tout instant, au maximum une application est exécutée sur chaque coeur. D'autre part, plusieurs applications peuvent s'exécuter simultanément, chacune sur un coeur du composant électronique de type SoC considéré, ces applications partageant une ressource dudit composant électronique de type SoC. [0004] La Fig. lA illustre schématiquement un agencement de composant électronique de type SoC basé sur une architecture multicceur incluant un dispositif d'interconnexion CI (« Core Interconnect » en terminologie anglo-saxonne) 110, tel qu'un bus ou un réseau, interconnectant une pluralité de coeurs CP1 101, CP2 102, CP3 103, CP4 104, ainsi qu'au moins une ressource partagée SR (« Shared Resource » en terminologie anglo-saxonne) 120. Une telle ressource partagée SR est par exemple, mais non exclusivement, une mémoire vive RAM (« Random Access Memory » en terminologie anglo-saxonne) de type dynamique, plus particulièrement de type SDRAM (« Synchronous Dynamic RAM » en terminologie anglo-saxonne). Une telle ressource partagée SR est, selon un autre exemple, une interface d'entrée-sortie interfaçant un 2 périphérique partagé (tel qu'un capteur) ou une interface de communication (telle qu'une interface filaire ou sans-fil). Plusieurs ressources partagées peuvent ainsi être interconnectées grâce au dispositif d'interconnexion Cl 110 et subir des tentatives d'accès concurrentes par les différents coeurs CP1 101, CP2 102, CP3 103, CP4 104. [0005] La technique usuelle d'exécution en parallèle d'applications dans des contextes multicoeur consiste à affecter une ou plusieurs applications à chaque coeur, et d'attribuer des tranches de temps d'exécution et un ou plusieurs espaces mémoire à chaque application ou à chaque partition d'application (lorsque 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 les coeurs de processeur), on pourra se référer au standard ARINC 653. [0006] La Fig. 1B illustre schématiquement une décomposition temporelle (temps t) d'utilisation des coeurs CP1 101, CP2 102, CP3 103, CP4 104. [0007] Sur la durée considérée sur la Fig. 1B, le coeur CP1 101 est utilisé de la manière suivante : une période 181 d'exécution d'une première application, suivie d'une période d'inutilisation du coeur CP1 101, suivie d'une autre période 181 d'exécution de la première application, suivie d'une autre période d' inutilisation du coeur CP1 101, suivie enfin d'encore une autre période 181 d'exécution de la première application. [0008] Sur la durée considérée, le coeur CP2 102 est utilisé de la manière suivante : une période 171 d'exécution d'une seconde application, suivie d'une période 172 d'exécution d'une troisième application, suivie d'une période 173 d'exécution d'une quatrième application, suivie d'une autre période 171 d'exécution de la seconde application, suivie enfin d'une autre période 172 d'exécution de la troisième application. [0009] Sur la durée considérée, le coeur CP3 103 est utilisé de la manière suivante : une période 161 d'exécution d'une cinquième application, suivie d'une période 162 d'exécution d'une sixième application, suivie d'une autre période 161 d'exécution de la cinquième application, suivie d'une autre période 162 d'exécution de la sixième application, suivie enfin d'une autre période 161 d'exécution de la cinquième application. [0010] Sur la durée considérée, le coeur CP4 104 est utilisé de la manière suivante : une période 151 d'exécution d'une septième application, suivie d'une période 152 d'exécution d'une huitième application, suivie d'une période d'inutilisation du coeur CP4 104, suivie d'une autre période 151 d'exécution de la septième application, suivie d'une autre période 152 d'exécution de la huitième application, suivie d'une autre période d'inutilisation du coeur CP4 104, suivie enfin d'encore une autre période 151 d'exécution de la septième application. [0011] 11 apparait ainsi que les ressources des coeurs sont partagées dans le temps selon des cadencements indépendants. Il résulte de cette approche que plusieurs applications 3 peuvent entrer en concurrence pour accéder à la ressource partagée SR 120. Une ou plusieurs applications (et donc un ou plusieurs coeurs respectifs) peuvent ainsi être bloquées par une saturation de la ressource partagée SR 120 par l'application (et donc le coeur correspondant) auquel l'accès à la ressource partagée a été accordé (« eranted » en terminologie anglo-saxonne). Ces conflits d'accès à la ressource partagée SR 120 entraînent des temps d'exécution des applications très variables (ralentissement des applications bloquées), ce qui pose un problème de perte de ségrégation entre les applications par déni de service DoS (« Deny of Service » en terminologie anglo-saxonne). Au moins certaines des applications exécutées par la plateforme sont considérées comme étant de « non confiance », c'est-à-dire qu'elles peuvent avoir des comportements agressifs, qu'ils soient volontaires ou pas, pour accéder à la ressource partagée SR 120, ce qui amplifie le problème de perte de ségrégation entre les applications. Or la ségrégation entre applications, particulièrement en cc qui concerne les calculateurs en avionique, rend possible une certification incrémentale, l'objectif industriel étant alors une réduction des coûts d'intégration lorsqu'un code source modifié d'une ou plusieurs application doit être intégré. 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, volume, poids, consommation d'énergie et fiabilité. Exposé de l'invention [0012] Un objet de la présente invention est de proposer un composant électronique incluant une architecture multicoeur comportant plusieurs coeurs et une ressource partagée, les coeurs étant destinés à exécuter en parallèle des applications susceptibles de tenter d'accéder de manière concurrente à la ressource partagée, le composant électronique comportant en outre : au moins un agent notificateur en charge de générer des événements relatifs à des tentatives d'accès à la ressource partagée par les coeurs ; un gestionnaire d'événements en charge de compter indépendamment pour chaque coeur lesdits événements par fenêtres temporelles, dites premières fenêtres temporelles, et de déclencher une alarme lorsque le nombre de tentatives d'accès comptées pour un coeur dépasse, pendant une dite première fenêtre temporelle, un seuil prédéfini représentatif d'un quota d'accès à la ressource partagée attribué audit coeur ou à chaque application exécutée sur ledit coeur ; et au moins un agent d'application de politique en charge, après une ou plusieurs alarmes déclenchées par le gestionnaire d'événements pendant une fenêtre temporelle, dite seconde fenêtre temporelle, d'empêcher temporairement le coeur ayant entraîné la ou les alarmes d'accéder à la ressource partagée. [0013] Ainsi, chaque coeur (ou l'application exécutée sur ledit coeur) est empêché d'accéder à la ressource partagée quand le quota qui lui est attribué est dépassé. Cela permet alors de limiter l'empiètement de l'application qui s'exécutait sur ledit coeur sur les quotas attribués aux autres coeurs. La ségrégation entre applications est ainsi assurée, ce qui rend possible une certification incrémentale des applications. [0014] Dans un mode de réalisation particulier, le composant électronique comporte un dit agent notificateur dans un contrôleur de la ressource partagée, qui envoie au gestionnaire d'événements un événement notifiant chaque tentative d'accès à la ressource partagée, l'événement indiquant au moins l'identité du coeur ayant émis la requête d'accès à la ressource partagée. [0015] Dans un mode de réalisation particulier, la ressource partagée est une mémoire de type dynamique, en particulier de type SDRAM. [0016] Dans un mode de réalisation particulier, chaque événement notifiant d'une tentative d'accès à la ressource partagée indique en outre si l'accès concerne une page mémoire déjà ouverte, et si l'accès concerne une lecture mémoire ou une écriture mémoire. [0017] Dans un mode de réalisation particulier, le quota d'accès à la ressource partagée attribué à chaque coeur, ou à chaque application exécutée sur ledit coeur, est défini pour des événements du type écriture mémoire avec ouverture de nouvelle page mémoire. [0018] Dans un mode de réalisation particulier, un dit agent d'application de politique est inclus chaque coeur et, lorsque ledit coeur a entraîné la ou les alarmes pendant une dite seconde fenêtre temporelle, ledit agent d'application de politique est en charge d'empêcher temporairement ledit coeur d'accéder à la ressource partagée. [0019] Dans un mode de réalisation particulier, pour empêcher temporairement ledit coeur d'accéder à la ressource partagée, ledit agent d'application de politique génère une interruption suspendant l'exécution de l'application alors en cours d'exécution sur ledit coeur. [0020] Dans un mode de réalisation particulier, un dit coeur est empêché d'accéder à la ressource partagée suite à la survenue d'une ou plusieurs alarmes jusqu'à expiration de la seconde fenêtre temporelle pendant laquelle ladite ou lesdites alarmes ont été déclenchées. [0021] Dans un mode de réalisation particulier, un dit coeur est empêché d'accéder à la ressource partagée suite à la survenue d'une ou plusieurs alarmes jusqu'à expiration d'une durée prédéfinie tant que ledit coeur ne commute pas sur une autre application, ou jusqu'à ce que ledit coeur commute sur une autre application. [0022] Un autre objet de la présente invention est de proposer un aéronef comportant un composant électronique tel que susmentionné, dans l'un quelconque de ses modes de réalisation. [0023] Un autre objet de la présente invention est de proposer un procédé implémenté par un composant électronique incluant une architecture multicoeur comportant plusieurs coeurs et une ressource partagée, les coeurs exécutant en parallèle des applications susceptibles de tenter d'accéder de manière concurrente à la ressource partagée, le procédé comportant les étapes suivantes : générer des événements relatifs à des tentatives d'accès à la ressource partagée par les coeurs ; compter indépendamment pour chaque coeur lesdits événements par fenêtres temporelles, dites premières fenêtres temporelles, et déclencher une alarme lorsque le nombre de tentatives d'accès comptées pour un coeur dépasse, pendant une dite première fenêtre temporelle, un seuil prédéfini représentatif d'un quota d'accès à la ressource partagée attribué audit coeur ou à chaque application exécutée sur ledit coeur ; et après une ou plusieurs alarmes déclenchées par le gestionnaire d'événements pendant une fenêtre temporelle, dite seconde fenêtre temporelle, empêcher temporairement le coeur ayant entraîné la ou les alarmes d'accéder à la ressource partagée. Brève description des dessins [0024] Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, appa- raî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 : [0025] [fig.I A] illustre schématiquement un agencement de composant électronique de type SoC basé sur une architecture rnulticoeur, selon l'état de la technique ; [0026] [fig.113] illustre schématiquement une décomposition temporelle d'utilisation des coeurs de l'architecture multicoeur ; [0027] [fig.2] montre une vue de dessus d'un aéronef comportant des équipements infor- matiques munis d'au moins un composant électronique de type SoC basé sur une architecture multicceur [0028] [fig.3A] illustre schématiquement un agencement logique de surveillance et de contrôle d'accès à une ressource partagée par les coeurs de l'architecture rnulticoeur ; [0029] W8.313_1 illustre schématiquement l'agencement logique de surveillance et de contrôle d'accès à une ressource partagée par les coeurs de l'architecture rnulticoeur, dans un mode de réalisation particulier ; [0030] [fig.3C] illustre schématiquement un agencement logique de surveillance et de contrôle d'accès à la ressource partagée par les coeurs de l'architecture multicoeur, dans un autre mode de réalisation particulier ; [0031] [fig.4] illustre schématiquement un agencement particulier d'un gestionnaire d'événements pour la surveillance et le contrôle d'accès à la ressource partagée par les coeurs de l'architecture multicceur ; [0032] [fig.5A] illustre schématiquement un organigramme d'un algorithme de surveillance et de contrôle d'accès à la ressource partagée par les coeurs de l'architecture multicceur ; et [0033] [fig.5B] illustre schématiquement un organigramme d'un autre algorithme de sur- 6 vcillance et de contrôle d'accès à la ressource partagée par les coeurs de l'architecture multicoeur, complémentaire à l'algorithme de la Fig. 5A dans un mode de réalisation particulier. [0034] EXPOSE DETAILLE DE MODES DE REALISATION [0035] La Fig. 2 montre une vue de dessus d'un aéronef 200 comportant des équipements informatiques munis d'au moins un composant électronique 201 de type SoC basé sur une architecture multieoeur telle qu'introduite en relation avec les Figs. lA et 1B. Les coeurs CP1 101, CP2 102, CP3 103, CP4 104 de l'architecture multicoeur exécutent donc des applications qui peuvent se trouver en situation d'effectuer des tentatives d'accès concurrentes à la ressource partagée SR 120. L'architecture multieoeur peut comporter une quantité différente de coeurs que celle schématiquement illustrée sur la Fig. 1A. [0036] Un mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, CP2 102, CP3 103, CP4 104 est détaillé par la suite. Grâce à ce mécanisme, même si une ou plusieurs applications ont un comportement agressif vis-à-vis de l'accès à la ressource partagée SR 120, la ségrégation entre applications est assurée. Un comportement agressif est défini comme un ensemble de sollicitations d'accès à la ressource partagée SR 120 qui empêche une ou plusieurs autres applications exécutées en parallèle (sur d'autres coeurs) d'accéder à la ressource partagée SR 120 pendant des périodes temporelles de durée supérieure à un seuil prédéfini. [0037] Dans un mode de réalisation particulier, la ressource partagée SR 120 est une mémoire de type dynamique, préférentiellement de type SDRAM. En effet, une telle ressource partagée forme typiquement le plan mémoire principal du composant électronique 201 de type SoC. Elle constitue une ressource parmi les plus critiques du composant électronique 201 de type SoC, car le plan mémoire principal supporte aussi bien les chargements (« fetching » en terminologie anglo-saxonne) d'instructions de code exécutable, que les accès des applications vis-à-vis de leurs données applicatives. Toute lenteur excessive sur les accès à la mémoire est source de perturbation potentielle du temps d'exécution d'applications concurrentes (notion de « Worst Case Execution Time », en terminologie anglo-saxonne). Les accès au plan mémoire principal du composant électronique 201 de type SoC, et d'une manière plus générale les accès mémoire, doivent être surveillés et contrôlés de manière adéquate pour assurer la ségrégation entre applications et limiter l'impact, sur toute application, des accès mémoire sollicités par une autre application concurrente. Comme détaillé plus loin, certains accès à la ressource partagée SR 120 peuvent avoir plus d'impact que d'autres et méritent d'être plus particulièrement surveillés et contrôlés. C'est le cas des changements de page lors des écritures mémoires, notamment pour les mémoires de type dynamique (e.g. SDRAM). 7 [0038] Les accès par chaque coeur à la ressource partagée SR 120 sont surveillés et contrôlés indépendamment des autres coeurs. Comme il ne peut y avoir au maximum qu'une seule application qui est exécutée sur chacun des coeurs CP1 101, CP2 102, CP3 103, CP4 104, surveiller les tentatives d'accès à la ressource partagée SR 120 par chaque coeur revient à surveiller indépendamment chaque application exécutée au sein du composant électronique 201 de type SoC. [0039] La surveillance des accès à la ressource partagée SR 120 est effectuée par fenêtres temporelles (périodes d'observation) successives. Les accès à la ressource partagée SR 120 par chacun des coeurs CP1 101, CP2 102, CP3 103, CP4 104 sont comptés pendant ces fenêtres temporelles et sont comparés avec un gabarit définissant un quota d'accès, au moins pour un ou plusieurs types d'accès prédéfinis, à la ressource partagée SR 120. Le gabarit sert à répartir la bande passante d'accès à la ressource partagée SR 120 entre les différents coeurs CP1 101, CP2 102, CP3 103, CP4 104. [0040] Comme détaillé ci-après, pour plus de souplesse dans l'interprétation des com- portements des applications vis-à-vis de la ressource partagée SR 120, la surveillance peut être effectuée de manière hiérarchique. [0041] La Fig. 3A illustre schématiquement un agencement logique de surveillance et de contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, CP2 102, CP3 103, CP4 104, dans un mode de réalisation particulier. [0042] Le composant électronique 201 de type SoC comporte un gestionnaire d'événements EM (« Event Manager » en terminologie anglo-saxonne) 300. Le gestionnaire d'événements EM 300 est en charge de collecter des événements reçus en provenance d'au moins un agent notificateur NA (« Notifying Agents » en terminologie anglo-saxonne). [0043] Selon un mode de réalisation particulier, chaque coeur CP1 101, CP2 102, CP3 103, CP4 104 inclut un tel agent notificateur NA qui envoie des événements au gestionnaire d'événements EM 300 en fonction des activités du coeur concerné. Ce sont respectivement les agents notificateurs NA1 301, NA2 302, NA3 303, NA4 304 sur la Fig. 3A. Chaque agent notificateur NA est alors apte à envoyer au gestionnaire d'événements EM 300 notamment un événement notifiant de chaque tentative d'accès à la ressource partagée SR 120 par le coeur dans lequel est inclus ledit agent notificateur NA. [0044] Selon un autre mode de réalisation, un tel agent notificateur NA est inclus dans un contrôleur de ressource partagée SRC (« Shared Resource Controller » en terminologie anglo-saxonne) 320 en charge de contrôler la ressource partagée SR 120. C'est l'agent notificateur NA5 305 sur la Fig. 3A, qui peut être le seul agent notificateur NA dont a besoin le gestionnaire d'événements EM 300 dans le cadre du mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, 8 CP2 102, CP3 103, CP4 104. L'agent notificatcur NA du contrôleur de ressource partagée SRC 320 envoie un événement notifiant chaque tentative (requête) d'accès à la ressource partagée SR 120, l'événement indiquant au moins l'identité du coeur ayant émis la requête d'accès à la ressource partagée SR 120. Lorsque la ressource partagée SR 120 est une mémoire de type dynamique (e.g. SDRAM), chaque événement notifiant d'une tentative (requête) d'accès à la ressource partagée SR 120 indique préférentiellement en outre si l'accès concerne une page mémoire déjà ouverte, et si l'accès concerne une lecture ou une écriture. En effet, les écritures en mémoire ont plus d'impact sur le temps d'accès mémoire que les lectures. En effet, en cas de lecture mémoire, le coeur concerné doit typiquement attendre que l'acquisition des informations à partir de la mémoire soit réalisée, et par conséquent, le coeur en question est bridé en termes de lectures requises auprès dc la mémoire. Par contre, un coeur peut lancer une série d'écritures en mémoire sans être bridé temporellement comme en lecture, les instructions d'écriture étant alors typiquement empilées par le contrôleur de ressource partagée SRC 320 sans que le coeur concerné n'ait à attendre que l'exécution d'une écriture soit réalisée avant d'en ordonner une autre. De plus, accéder à une page mémoire qui n'est pas déjà ouverte (c'est-à-dire effectuer un changement de page mémoire) a un impact significatif sur le temps d'accès mémoire, ce qui pénalise d'autant plus les tentatives d'accès mémoire par une ou plusieurs autres applications exécutées en parallèle dans l'architecture multicoeur. Des changements de page sur écriture sont ainsi des accès mémoire parmi les plus pénalisants en termes de temps d'accès mémoire. Comme décrit plus loin, il est donc souhaitable de surveiller particulièrement ces types d'accès mémoire. Dans un mode de réalisation particulier, chaque événement indique préférentiellement en outre l'adresse mémoire concernée, ce qui permet de restreindre la surveillance à des zones sous cohérence mémoire. [0045] Le gestionnaire d'événements EM 300 filtre donc les événements reçus en provenance des différents agents notificateurs NA, de sorte à identifier, parmi tous les événements reçus, ceux qui concernent la surveillance et le contrôle d'accès à la ressource partagée SR 120. Il se peut en effet que le gestionnaire d'événements EM 300 reçoive des événements de bien d'autres types que ceux relatifs à la surveillance et au contrôle d'accès à la ressource partagée SR 120. [0046] Le gestionnaire d'événements EM 300 effectue alors des comptages des événements qui concernent la surveillance et le contrôle d'accès à la ressource partagée SR 120. Les comptages sont effectués sur une base de fenêtres temporelles (périodes d'observation) successives, comme déjà mentionné. Au passage d'une fenêtre temporelle à une fenêtre temporelle suivante, les comptages reprennent à zéro. Si les comptages montrent un excès de tentatives d'accès, ou d'un certain type d'accès, à la ressource partagée SR 120 de la part d'un coeur (ou d'une application exécutée sur ledit 9 coeur) par rapport à un gabarit préétabli, le gestionnaire d'événements EM 300 génère une alarme. La survenue d'une ou plusieurs alarmes dans un intervalle de temps donné (qui peut être indépendant de la durée de la fenêtre temporelle susmentionnée), pour un même coeur, entraîne une sanction. La sanction consiste à empêcher temporairement l'application, qui a généré un comportement trop agressif vis-à-vis de l'accès à la ressource partagée SR 120, d'accéder à la ressource partagée SR 120. [0047] Les gabarits (profils) sont définis, par mesure, sur des bancs d'essai (« benchmark » en terminologie anglo-saxonne) représentatifs des différents types d'applications destinées à être embarquées dans le composant électronique 201 de type SoC. Ces bancs d'essai s'appuient par exemple sur des générateurs automatiques de code GAC, tels que fournis dans la suite SCADE (marque déposée) de la société Esterel Technologies (marque déposée), et/ou sur des portions de système d'exploitation embarqué et/ou de libraires standards (par exemple, la librairie « merncopy »). Ces bancs d'essai permettent de définir des comportements acceptables d'accès à la ressource partagée SR 120, en fonction d'une bande passante attribuée à un coeur (et donc aux applications exécutées sur ce coeur) pour accéder à la ressource partagée SR 120. Chaque gabarit définit alors un ou plusieurs seuils de comptage d'événements d'accès à la ressource partagée SR 120, au-delà desquels, sur une fenêtre temporelle (période d'observation) de durée prédéterminée, le comportement de l'application considérée est jugé trop agressif vis-à-vis de la ressource partagée SR 120, du fait d'un impact trop important sur des applications concurrentes en termes de latence d'accès à la ressource partagée SR 120. Autrement dit, chaque gabarit définit un quota d'accès, par fenêtre temporelle, à la ressource partagée. A chaque coeur est donc associé un gabarit prédéfini qui est représentatif d'un quota d'accès à la ressource partagée SR 120, par fenêtre temporelle, pour ledit coeur. Une autre approche est de définir le gabarit par application. Ainsi, lorsqu'un coeur commute d'une application à une autre, il en informe le gestionnaire d'événements EM 300 afin de basculer du gabarit de l'application dont l'exécution cesse vers le gabarit de l'application dont l'exécution prend place. Lorsque le coeur (ou l'application) en question dépasse ce quota, une alarme est générée par le gestionnaire d'événements EM 300. Un seuil peut être ainsi fixé pour chaque type d'événements relatifs à la surveillance des accès à la ressource partagée SR 120 ou pour un ensemble de types d'événements relatifs à la surveillance des accès à la ressource partagée SR 120. [0048] La durée des fenêtres temporelles (périodes d'observation) et la définition des gabarits (quotas) doivent être suffisantes pour qu'une application ne soit pas significativement impactée en performance tant qu'elle n'est pas significativement pénalisante pour les applications exécutées en parallèle, et que ces autres applications puissent bénéficier du service escompté de la ressource partagée SR 120, comme défini par les quotas qui sont respectivement attribués aux coeurs CP1 101, CP2 102, CP3 103, CP4 104. [0049] Chaque alarme générée par le gestionnaire d'événements EM 300 est transmise à un agent d'application de politique PEA (« Pol icy Enforcement Agent » en terminologie anglo-saxonne), inclus préférentiellement dans le coeur qui a entraîné l'alarme en question. Ainsi, chaque coeur CP1 101, CP2 102, CP3 103, CP4 104 inclut préférentiellement un tel agent d'application de politique PEA, de sorte à ce que la sanction soit appliquée au plus près de l'application concernée. Ce sont respectivement les agents d'application de politique PEA1 311, PEA2 312, PEA3 313, PEA4 314 sur la Fig. 3A. [0050] Lorsqu'une alarme est reçue du gestionnaire d'événements EM 300, l'agent d'application de politique PEA en question génère préférentiellement une interruption qui préempte l'application en cours d'exécution sur le coeur concerné et qui suspend temporairement, de manière contrôlée, l'exécution de ladite application. Les autres applications s'exécutant au même moment sur les autres coeurs ne sont alors pas lésées par le comportement trop agressif vis-à-vis de l'accès à la ressource partagée SR 120 de l'application qui a généré l'alarme. Dans un mode de réalisation particulier, l'agent d'application de politique PEA en question n'applique pas de sanction à chaque alarme reçue, mais l'agent d'application de politique PEA en question applique son propre mécanisme de surveillance des accès à la ressource partagée SR 120, dont les alarmes reçues du gestionnaire d'événements EM 300 sont un type d'événements d'entrée parmi d'autres. Par exemple, plutôt que d'autoriser 5 changements de page en écriture d'une mémoire de type dynamique (e.g. SDRAM) par période de 10 microsecondes avant d'appliquer une sanction, il est ainsi possible d'autoriser 3 changements de page en écriture par période de 10 ps au sein du gestionnaire d'événements EM 300 avant de générer une alarme et, au niveau de l'agent d'application de politique PEA, d'autoriser 2 alarmes en provenance du gestionnaire d'événements EM 300 par activation de partition (« partition activation » en terminologie anglo-saxonne) avant d'appliquer la sanction. Une application peut ainsi demander une fois 5 changements de page sans être sanctionnée, mais dépasser répétitivement 3 changements de page par fenêtre temporelle de 10 microsecondes au sein d'une activation de partition entraîne la sanction. [0051] Dans une variante de réalisation, un agent d'application de politique PEA est inclus dans le contrôleur de ressource partagée SRC 320 au lieu qu'un tel agent d'application de politique PEA soit inclus dans chaque coeur. Lorsqu'une alarme est reçue du gestionnaire d'événements EM 300, l'agent d'application de politique PEA en question retarde, pendant un temps prédéterminé, tout accès à la ressource partagée SR 120 en provenance du coeur qui a généré l'alarme (par exemple, en baissant son niveau de priorité d'accès par rapport aux autres coeurs). Les autres applications s'exécutant au 11 même moment sur les autres coeurs ne sont alors pas lésées par le comportement trop agressif vis-à-vis de l'accès à la ressource partagée SR 120 de l'application qui a généré l'alarme. Dans un mode de réalisation particulier, l'agent d'application de politique PEA en question n'applique pas de sanction à chaque alarme reçue, comme déjà présenté ci-dessus. [0052] Suspendre l'exécution d'une application grâce à un agent d'application de politique PEA inclus dans le coeur concerné évite que ladite application ne continue de solliciter l'accès à la ressource partagée SR 120, et est donc plus performant que d'inclure, à la place, un agent d'application de politique PEA dans le contrôleur de ressource partagée SRC 320. [0053] Dans un mode de réalisation particulier, le gestionnaire d'événements EM 300 fait partie d'une unité, appelée EPU (« Event Proccss Unit » en terminologie anglo-saxonne), d'un composant électronique de type SoC dans la famille QoriQ (marque déposée) des produits de la société NXP (marque déposée). Dans ce cadre, des événements « Dchug » sont formalisés, qui peuvent servir de support pour permettre de générer des événements à destination du gestionnaire d'événements EM 300 et pour permettre au gestionnaire d'événements EM 300 de générer des alarmes. [0054] Dans le mode de réalisation de la Fig. 3B s'appuyant sur l'agencement de la Fig. 3A, chaque coeur CP1 101, CP2 102, CP3 103, CP4 104 comporte un agent d'application de politique PEA. Le gestionnaire d'événements EM 300 reçoit divers événements en provenance des coeurs CP1 101, CP2 102, CP3 103, CP4 104 et du contrôleur de ressource partagée SRC 320. Lorsque les événements montrent que le coeur (et donc l'application en cours (l'exécution) a un comportement jugé trop agressif vis-à-vis de l'accès à la ressource partagée SR 120, le gestionnaire d'événements EM 300 envoie une alarme à l'agent d'application de politique PEA1 311, PEA2 312, PEA3 313, PEA4 314 inclus dans le coeur CP1 101, CP2 102, CP3 103, CP4 104 en question. L'agent d'application de politique PEA en question empêche alors temporairement l'accès à la ressource partagée SR 120 pour l'application en question. En variante, comme déjà discuté, l'agent d'application de politique PEA en question dispose de son propre niveau de surveillance d'accès à la ressource partagée SR 120 et n'applique pas une sanction à chaque alarme reçue. [0055] Dans le mode de réalisation alternatif de la Fig. 3C, le composant électronique 201 de type SoC comporte un seul agent d'application de politique PEA 315 implémenté dans le contrôleur de ressource partagée SRC 320. Le gestionnaire d'événements EM 300 reçoit divers événements en provenance des coeurs CP1 101, CP2 102, CP3 103, CP4 104 et du contrôleur de ressource partagée SRC 320. Lorsque les événements montrent qu'application a eu un comportement jugé trop agressif vis-à-vis de l'accès à la ressource partagée SR 120, le gestionnaire d'événements EM 300 envoie une alarme 12 à l'agent d'application de politique PEA 315. L'agent d'application de politique PEA 315 rejette alors temporairement toute tentative d'accès à la ressource partagée SR 120 pour le coeur en question (et donc l'application en question). En variante, comme déjà discuté, l'agent d'application dc politique PEA en question dispose de son propre niveau de surveillance d'accès à la ressource partagée SR 120 ct n'applique pas une sanction à chaque alarme reçue. [0056] La Fig. 4 illustre schématiquement un agencement particulier du gestionnaire d'événements EM 300 pour la surveillance et le contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, CP2 102, CP3 103, CP4 104. [0057] Le gestionnaire d'événements EM 300 comporte un sélecteur d'événements ES (« Event Selector » en terminologie anglo-saxonne) 402 en charge de recevoir en entrée les différents événements 401 qui sont adressés par les agents notificateurs NA au gestionnaire d'événements EM 300. Le sélecteur d'événements ES 402 est en outre en charge de recevoir en entrée des événements 412, 413 internes au gestionnaire d'événements EM 300, comme détaillé ci-après. [0058] Le gestionnaire d'événements EM 300 comporte en outre une unité de séquencement et de combinaison S&CU (« Sequencing & Combining Unit » en terminologie anglo-saxonne) 404 en charge de filtrer les événements 403 reçus et propagés par le sélecteur d'événements ES 402. L'unité de séquencement et de combinaison S&CU 404 compare les événements 403 avec des conditions prédéfinies, afin de détecter les événements dont les types concernent effectivement la surveillance et le contrôle d'accès à la ressource partagée SR 120. Lorsqu'une correspondance est trouvée, l'unité de séquencement et de combinaison S&CU 404 envoie une information 405 représentative de ladite correspondance à un ensemble de compteurs C 411 du gestionnaire d'événements EM 300. [0059] L'ensemble de compteurs C 411 comporte ainsi des compteurs d'événements en charge de compter les événements notifiés par l'unité de séquencement et de combinaison S&CU 404. Il existe typiquement un compteur par type d'événement et par coeur. [0060] Parmi l'ensemble de compteurs C 411, le gestionnaire d'événements EM 300 comporte en outre des compteurs qui ne comptent pas les événements notifiés par l'unité de séquencement et de combinaison S&CU 404, mais qui comptent des cycles de temps pour définir les fenêtres temporelles (périodes d'observation) utilisées par le gestionnaire d'événements EM 300 dans le cadre de la surveillance des accès à la ressource partagée SR 120. Lorsqu'un compteur de temps atteint une période prédéfinie (nombre de cycles de temps successifs), ledit compteur de temps envoie au sélecteur d'événements ES 402 un événement de fin de période 412 et se remet à zéro. Cet événement de fin de période 412 est transmis par le sélecteur d'événements ES 402 13 à l'unité de séquencement et de combinaison S&CU 404, qui le relaie sous forme d'un événement périodique 406 à une unité d'action AU (« Action Unit » en terminologie anglo-saxonne) 408 du gestionnaire d'événements EM 300. L'unité d'action AU 408 envoie alors une instruction de remise à zéro de chaque compteur d'événements qui est affilié à l'événement de fin de période 412 en question. [0061] Lorsqu'un compteur d'événements dépasse un seuil prédéfini, une alarme est dé- clenchée pour notifier d'une détection de comportement trop agressif d'une application vis-à-vis de l'accès à la ressource partagée SR 120. Pour cc faire, ledit compteur d'événements transmet au sélecteur d'événements ES 402 un événement correspondant 413, qui inclut une identification du coeur CP1 101, CP2 102, CP3 103, CP4 104 auquel ledit compteur est associé. Cet événement de dépassement de seuil 413 est transmis par le sélecteur d'événements ES 402 à l'unité de séquencement et de combinaison S&CU 404, qui le relaie sous forme d'un événement d'alarme 407 à l'unité d'action AU 408. L'unité d'action AU 408 génère une alarme correspondante 409, que l'unité d'action AU 408 transmet à l'agent d'application de politique PEA concerné. [0062] La Fig. 5A illustre schématiquement un organigramme d'un algorithme de sur- veillance et de contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, CP2 102, CP3 103, CP4 104. L'algorithme de la Fig. 5A est implémenté par le gestionnaire d'événements EM 300, indépendamment pour chaque coeur CP1 101, CP2 102, CP3 103, CP4 104. [0063] Dans une étape 501, le gestionnaire d'événements EM 300 détecte un début de période d'observation (fenêtre temporelle). Dans le contexte de la Fig. 4, ce début de période d'observation correspond à la mise à zéro des compteurs de temps. Par exemple, la durée de la période d'observation (fenêtre temporelle) est de 10 microsecondes. La durée des périodes d'observation (fenêtres temporelles) successives est choisie en fonction des caractéristiques temps-réel des applications concurrentes pour lesquelles la ségrégation est recherchée. A titre d'exemple, si toutes les applications ont des temps de réponse proche de 1 seconde, alors la durée de la fenêtre peut être allongée, par exemple à 50 rnillisecondes. A l'opposé, si certaines de ces applications ont des temps de réponse très courts, par exemple de l'ordre de 1 milliseconde, alors la durée des périodes d'observation (fenêtres temporelles) successives est raccourcie, par exemple à 10 microsecondes. A noter que la durée des périodes d'observation (fenêtres temporelles) peut différer d'un coeur à l'autre. Les fenêtres temporelles (périodes d'observation) pour les différents coeurs peuvent être synchrones ou déphasées. La solution déphasée peut induire une meilleure utilisation des ressources du composant électronique 201 de type SoC. [0064] Dans une étape 502, le gestionnaire d'événements EM 300 compte des événements, de types prédéfinis qui sont relatifs à la surveillance et au contrôle d'accès à la 14 ressource partagée SR 120, survenant pendant la période d'observation. Dans le contexte de la Fig. 4, à la survenue d'un nouvel événement pertinent pour la surveillance d'accès à la ressource partagée SR 120, le gestionnaire d'événements EM 300 incrémente au moins un compteur correspondant parmi l'ensemble de compteurs C 411. Comme déjà mentionné, lorsque la ressource partagée SR 120 est une mémoire notamment de type dynamique (e.g. SDRAM), le gestionnaire d'événements EM 300 compte les changements de page mémoire en écriture mémoire. En effet, les applications produisant beaucoup de lectures mémoire se ralentissent d'elles-mêmes et sont donc peu pénalisantes pour les applications concurrentes. D'autres critères de surveillance d'accès à la ressource partagée SR 120 peuvent être utilisés, et déclencher également une alarme sur dépassement d'un quota prédéfini (seuil correspondant), comme par exemple la surveillance d'un nombre total d'accès à la ressource partagée SR 120 requis par le coeur (ou l'application) en question pendant la période d'observation, éventuellement filtrés par adresse mémoire, afin de restreindre la surveillance à des zones sous cohérence mémoire. [0065] Dans une étape 503, le gestionnaire d'événements EM 300 compare le comptage desdits événements sur la période d'observation par rapport à des seuils respectifs prédéfinis en fonction du quota d'accès à la ressource partagée SR 120 défini par le gabarit associé au coeur considéré ou à l'application considérée. [0066] Dans une étape 504, le gestionnaire d'événements EM 300 vérifie si, pour chaque type d'événement compté, le seuil prédéfini correspondant, dans le gabarit applicable à la période d'observation en cours, est dépassé ou pas. Si le seuil prédéfini est dépassé pour au moins un type d'événement, une étape 507 est effectuée ; sinon, une étape 505 est effectuée. [0067] Dans l'étape 505, le gestionnaire d'événements EM 300 vérifie si la période d'observation a pris fin ou pas. Si la période d'observation a pris fin, une étape 506 est effectuée ; sinon, l'étape 502 est répétée pour continuer de compter les éventuels événements prédéfinis qui sont relatifs à la surveillance et au contrôle d'accès à la ressource partagée SR 120 et qui surviennent pendant la période d'observation. [0068] Dans l'étape 506, le gestionnaire d'événements EM 300 effectue une remise à zéro du comptage. Dans le contexte de la Fig. 4, cela correspond à la remise à zéro des compteurs d'événements suite à la réception par l'unité d'action AU 408 d'un événement périodique marquant la fin d'une fenêtre temporelle (période d'observation) correspondante. Ainsi, tant que le coeur considéré, ou l'application considérée, ne dépasse pas son quota d'accès à la ressource partagée SR 120, le coeur en question ne subit pas de sanction et le mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 est transparent pour ledit coeur. Ensuite, l'étape 501 est répétée, avec une nouvelle période d'observation. [0069] Dans l'étape 507, le gestionnaire d'événements EM 300 envoie une alarme à l'agent d'application de politique PEA concerné. Dans le contexte de la Fig. 3B, l'agent d'application de politique PEA est celui du coeur sur lequel est exécutée l'application qui a déclenché l'alarme (i.c., le coeur pour lequel l'algorithme de la Fig. 5A est exécuté). Dans le contexte de la Fig. 3B, l'agent d'application de politique PEA est celui du contrôleur de ressource partagée SRC 320 et l'alarme envoyée indique à quel coeur s'applique ladite alarme. Ensuite, l'étape 506 est effectuée, dans laquelle le comptage est remis à zéro et suspendu jusqu'à cc qu'une nouvelle période d'observation débute. [0070] Comme déjà indiqué, l'agent d'application de politique PEA en question peut appliquer une sanction à l'application qui a déclenché l'alarme après réception d'une ou plusieurs alarmes dans un laps de temps prédéfini. Lorsque l'agent d'application de politique PEA en question applique une sanction sur réception de chaque alarme reçue du gestionnaire d'événements EM 300 et que les agents d'application de politique PEA sont inclus dans les coeurs, l'agent d'application de politique PEA concerné génère préférentiellement une interruption qui entraîne la suspension de l'exécution de l'application concernée. L'application en question subit ainsi une interruption peu après avoir dépassé le quota d'accès qui lui est attribué, le décalage temporel venant notamment d'une latence introduite par les traitements relatifs du gestionnaire d'événements EM 300 et par une insertion d'une instruction d'interruption dans un pipeline d'instructions du coeur concerné). On peut noter que, dans des cas de commutation de contexte (« context switching » en terminologie anglo-saxonne) en fin de partition, l'interruption n'est pas prise en compte. Cela laisse possible l'exécution d'une autre application par le même coeur malgré la sanction. Cette autre application ne subit alors pas la sanction à la place de l'application à laquelle la sanction est supposée s'appliquer. [0071] La sanction consiste à empêcher temporairement le coeur concerné d'accéder à la ressource partagée SR 120. La sanction peut être levée à l'issue de la période d'observation en cours. En variante, la sanction peut être appliquée pendant une durée prédéfinie, tant que le coeur concerné ne commute pas sur une autre application, ou la sanction peut être appliquée jusqu'à ce que le coeur commute sur une autre application. [0072] Préférentiellement, l'application de la sanction est transparente pour les autres coeurs. Par exemple, les coeurs ne partagent pas de canaux d'un contrôleur d'interruption et/ou les instructions du code d'interruption relatif à la sanction n'accèdent pas à des ressources critiques ou à temps de réaction élevé. [0073] La Fig. 5B illustre schématiquement un organigramme d'un algorithme de sur- veillance et de contrôle d'accès à la ressource partagée SR 120 par les coeurs CP1 101, CP2 102, CP3 103, CP4 104. L'algorithme de la Fig. 5B est implémenté par chaque 16 agent d'application de politique PEA, lorsque plusieurs alarmes doivent être reçues avant de pénaliser l'application concernée. [0074] Dans une étape 551, l'agent d'application de politique PEA détecte un début de période d'observation (fenêtre temporelle). Cette période d'observation peut être différente et indépendante de la période d'observation (fenêtre temporelle) utilisée dans l'algorithme de la Fig. 5A par le gestionnaire d'événements EM 300. Par exemple, la période d'observation utilisée par l'agent d'application de politique PEA dure le temps d'une activation de partition. A noter que la durée des périodes d'observation (fenêtres temporelles) peut différer d'un agent d'application de politique PEA à l'autre. Ainsi, il est possible d'adapter la durée de la période d'observation à chaque partition lors des commutations de contexte. La période d'observation de la Fig. 5B peut donc aussi être identique à celle de la Fig. 5A, ce qui est aisément réalisable en propageant les événements périodiques 406, par l'unité d'action AU 408, à chaque agent d'application de politique PEA. [0075] Dans une étape 552, l'agent d'application de politique PEA compte des événements prédéfinis qui sont relatifs à la surveillance et au contrôle d'accès à la ressource partagée SR 120, survenant pendant la période d'observation. Les alarmes notifiées par le gestionnaire d'événements EM 300 est un type d'événements, du point de vue de l'agent d'application de politique PEA. L'agent d'application de politique PEA dispose donc de ses propres compteurs, à la manière du gestionnaire d'événements EM 300. Comme déjà expliqué, cela permet de ne pas appliquer de sanction lorsqu'une alarme est déclenchée de manière marginale. [0076] Dans une étape 553, l'agent d'application de politique PEA compare le comptage desdits événements sur la période d'observation par rapport à des seuils respectifs prédéfinis en fonction du quota d'accès à' la ressource partagée SR 120 défini par le gabarit associé au coeur considéré ou à l'application considérée. [0077] Dans une étape 554, l'agent d'application de politique PEA vérifie si, pour chaque type d'événement relatif à la surveillance et au contrôle d'accès à la ressource partagée SR 120, le seuil prédéfini correspondant est dépassé ou pas. Si le seuil prédéfini est dépassé pour au moins un type d'événement, une étape 557 est effectuée ; sinon, une étape 555 est effectuée. [0078] Dans l'étape 555, l'agent d'application de politique PEA vérifie si la période d'observation a pris fin ou pas. Si la période d'observation a pris fin, une étape 556 est effectuée ; sinon, l'étape 552 est répétée pour continuer de compter les éventuels événements prédéfinis qui sont relatifs à la surveillance et au contrôle d'accès à la ressource partagée SR 120 et qui surviennent pendant la période d'observation. [0079] Dans l'étape 556, l'agent d'application de politique PEA effectue une remise à zéro du comptage. Ensuite, l'étape 551 est répétée, avec une nouvelle période 17 d'observation. [0080] Dans l'étape 557, l'agent d'application de politique PEA empêche temporairement le coeur concerne d'accéder à la ressource partagée SR 120. Lorsque l'agent d'application de politique PEA est inclus dans un des coeurs, ledit agent d'application de politique PEA génère préférentiellement une interruption qui entraîne la suspension de l'exécution de l'application en cours sur ledit coeur. Lorsque l'agent d'application de politique PEA est inclus dans le contrôleur de ressource partagée SRC 320, ledit agent d'application de politique PEA rejette temporairement toute tentative d'accès à la ressource partagée SRC 320 venant du coeur concerné. Ensuite, l'étape 556 est effectuée, dans laquelle le comptage est remis à zéro et suspendu jusqu'à ce qu'une nouvelle période d'observation débute. [0081] La sanction consiste à empêcher temporairement le coeur concerné d'accéder à la ressource partagée SR 120. La sanction peut être levée à l'issue de la période d'observation (fenêtre temporelle) en cours. En variante, la sanction peut être appliquée pendant une durée prédéfinic, tant que le coeur concerné ne commute pas sur une autre application, ou la sanction peut être appliquée jusqu'à ce que le coeur commute sur une autre application. L'application sanctionnée peut ainsi attendre d'autant plus longtemps qu'elle a consommé le quota rapidement. [0082] A noter que le mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 décrit ci-dessus peut être couplé à un ou plusieurs autres mécanismes de régulation dans le composant électronique 201 de type SoC. Par exemple, les composants électroniques référencés TIOxx dans la famille QorIQ (marque déposée) des produits de la société NXP (marque déposée) permettent de définir une limite au nombre de requêtes qu'un coeur peut s'octroyer à un instant. Il est alors possible de définir un compromis entre seuils de comptage et durée des périodes d'observation. Le mécanisme de régulation est particulièrement adapté à réguler les lectures mémoire. Par conséquent, les accès à la ressource partagée SR 120 qui sont de type lecture mémoire sont avantageusement surveillés grâce à ce mécanisme de régulation et les accès à la ressource partagée SR 120 qui sont de type écriture mémoire sont avantageusement surveillés par le mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 décrit ci-dessus. Il est ainsi possible de diminuer la latence de la sanction pour les accès à la ressource partagée SR 120 qui sont de type écriture mémoire, sans pénaliser les accès à la ressource partagée SR 120 qui sont de type lecture mémoire. [0083] A noter que le mécanisme de surveillance et de contrôle d'accès à la ressource partagée SR 120 peut aussi reconnaitre des événements indicateurs de réduction de gêne, comme par exemple un ensemble d'opérations de lecture mémoire, et sur seuil prédéfini, avant écoulement de la fenêtre temporelle (période d'observation) 18 considérée, commander une remise à zéro du comptage associé au coeur concerné. Il est ainsi possible d'abaisser un budget d'écriture avec changement de page, ou d'allonger la durée de fenêtre temporelle (période d'observation) applicable sans pénaliser les applications ayant un profil connu non agressif, tout en continuant à pénaliser des applications qui ont un taux de sollicitation atypique de la ressource partagée SR 120. [0084] A noter aussi que, lorsque chaque coeur inclut un agent d'application de politique PEA, le déclenchement des sanctions (par exemple sous interruption) peut entraîner une collecte par l'agent d'application de politique PEA concerné de statistiques aidant à la calibration des quotas : temps total passé en sanction ; plus rapide exhaustion du quota ; identification de code applicatif sanctionné... 19 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSComposant électronique (201) incluant une architecture multicoeur comportant plusieurs coeurs (101, 102, 103, 104) et une ressource partagée (120), les coeurs (101, 102, 103, 104) étant destinés à exécuter en parallèle des applications susceptibles de tenter d'accéder de manière concurrente à la ressource partagée (120), caractérisé en cc que le composant électronique (201) comporte en outre : - au moins un agent notificatcur (301, 302, 303, 304, 305) en charge de générer des événements relatifs à des tentatives d'accès à la ressource partagée (120) par les coeurs (101, 102, 103, 104) ; - un gestionnaire d'événements (300) en charge de compter (502) indépendamment pour chaque coeur (101, 102, 103, 104) lesdits événements par fenêtres temporelles, dites premières fenêtres temporelles, et de déclencher une alarme (507) lorsque le nombre de tentatives d'accès comptées pour un coeur (101) dépasse, pendant une dite première fenêtre temporelle, un seuil prédéfini représentatif d'un quota d'accès à la ressource partagée (120) attribué audit coeur (101) ou à chaque application exécutée sur ledit coeur (101) ; et - au moins un agent d'application de politique (311, 312, 313, 314, 315), en charge, après une ou plusieurs alarmes déclenchées par le gestionnaire d'événements (300) pendant une fenêtre temporelle, dite seconde fenêtre temporelle, d'empêcher temporairement (557) le coeur (101) ayant entraîné la ou les allumes d'accéder à la ressource partagée (120). Composant électronique (201) selon la revendication 1, dans lequel le composant électronique (201) comporte un dit agent notificateur (305) dans un contrôleur de la ressource partagée (320), qui envoie au gestionnaire d'événements (300) un événement notifiant chaque tentative d'accès à la ressource partagée (120), l'événement indiquant au moins l'identité du coeur (101) ayant émis la requête d'accès à la ressource partagée (120). Composant électronique (201) selon la revendication 2, dans lequel la ressource partagée (120) est. une mémoire de type dynamique, en particulier de type SDRAM. Composant électronique (201) selon la revendication 3, dans lequel chaque événement notifiant d'une tentative d'accès à la ressource partagée (120) indique en outre si l'accès concerne une page mémoire 20 [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] déjà ouverte, et si l'accès concerne une lecture mémoire ou une écriture mémoire. Composant électronique (201) selon la revendication 4, dans lequel le quota d'accès à la ressource partagée attribué à chaque coeur (101, 102, 103, 104), ou à chaque application exécutée sur ledit coeur (101, 102, 103, 104), est défini pour des événements du type écriture mémoire avec ouverture de nouvelle page mémoire. Composant électronique (201) selon l'une quelconque des revendications 1 à 5, dans lequel un dit agent d'application de politique (311, 312, 313, 314) est inclus chaque coeur et, lorsque ledit coeur (101, 102, 103, 104) a entraîné la ou les alarmes pendant une dite seconde fenêtre temporelle, ledit agent d'application de politique (311, 312, 313, 314) est en charge d'empêcher temporairement ledit coeur (101, 102. 101 104) d'accéder à la ressource partagée (120). Composant électronique (201) selon la revendication 6, dans lequel, pour empêcher temporairement ledit coeur (101, 102, 103, 104) d'accéder à la ressource partagée (120), ledit agent d'application de politique (311, 312, 313, 314) génère une interruption suspendant l'exécution de l'application alors en cours d'exécution sur ledit coeur (101, 102, 103, 104). Composant électronique (201) selon l'une quelconque des revendications 1 à 7, dans lequel un dit coeur (101) est empêché d'accéder à la ressource partagée (120) suite à la survenue d'une ou plusieurs alarmes jusqu'à expiration de la seconde fenêtre temporelle pendant laquelle ladite ou lesdites alarmes ont été déclenchées. Composant électronique (201) selon l'une quelconque des revendications 1 à 7, dans lequel un dit coeur (101) est empêché d'accéder à la ressource partagée (120) suite à la survenue d'une ou plusieurs alarmes jusqu'à expiration d'une durée prédéfinie tant que ledit coeur (101) ne commute pas sur une autre application, ou jusqu'à ce que ledit coeur (101) commute sur une autre application. Aéronef (200) comportant un composant électronique (201) selon l'une quelconque des revendications 1 à 9. Procédé implémenté par un composant électronique (201) incluant une architecture multicceur comportant plusieurs coeurs (101, 102, 103, 104) et une ressource partagée (120), les coeurs (101, 102, 103, 104) exécutant en parallèle des applications susceptibles de tenter d'accéder de manière concurrente à la ressource partagée (120), caractérisé en ce 21 que le procédé comporte les étapes suivantes : - générer des événements relatifs à des tentatives d'accès à la ressource partagée (120) par les coeurs (101. 102, 103, 104) ; - compter (502) indépendamment pour chaque coeur (101, 102, 103, 104) lesdits événements par fenêtres temporelles, dites premières fenêtres temporelles, et déclencher (507) une alarme lorsque le nombre de tentatives d'accès comptées pour un coeur (101) dépasse, pendant une dite première fenêtre temporelle, un seuil prédéfini représentatif d'un quota d'accès à la ressource partagée (120) attribué audit coeur (101) ou à chaque application exécutée sur ledit coeur (101) ; et - après une ou plusieurs alarmes déclenchées par le gestionnaire d'événements pendant une fenêtre temporelle, dite seconde fenêtre temporelle, empêcher (557) temporairement le coeur (101) ayant entraîné la ou les alarmes d'accéder à la ressource partagée (120).