FR 3082020 A1 20191206 FR 1800543 A 20180601 I Procédé de contrôle d'un système à plusieurs coeurs et dispositifs associés La présente invention concerne un procédé de contrôle d'un système comprenant un calculateur comportant une pluralité de coeurs. La présente invention se rapporte également à un produit programme d'ordinateur et un support lisible d'informations associés. Les systèmes temps réel, notamment les calculateurs avioniques civils, sont soumis à des exigences de sûreté très contraignantes. En effet, dans le cas d'un avion, une défaillance pourrait avoir des conséquences catastrophiques sur le vol de l'avion de ligne et ses nombreux passagers. Des normes et régulations spécifiques imposent ainsi des techniques particulières pour assurer le déterminisme temporel de l'exécution des applications. Une caractéristique fondamentale d'un système temps réel est son temps de réponse, qui doit impérativement être inférieur à une valeur prédéterminée. Il convient que le temps d'exécution d'une séquence de tâches logicielles soit déterministe et répétable. Pour des raisons de sûreté, il est considéré ce temps d'exécution dans le pire cas, c'est-à-dire quand divers événements indésirables (internes et externes au système) surviennent. Pour cela, il est connu que minimiser ces effets indésirables consiste à garantir une isolation stricte, dans le temps et dans l'espace mémoire, entre les sous-ensembles fonctionnels du calculateur (typiquement entre applications). Il est alors utilisé des techniques de partitionnement, dans l'espace mémoire à l'aide de virtualisation d'adresses et dans le temps grâce à un ordonnancement statique des partitions. De telles techniques d'isolation sont bien maîtrisées sur les processeurs mono- coeur, y compris en désactivant certaines fonctionnalités défavorables au déterminisme et/ou en prenant des marges temporelles. Ces techniques d'isolation sont également indispensables au concept d'avionique modulaire intégrée qui permet de développer des systèmes à criticité mixtes où des applications fortement critiques (tel que le pilotage automatique en avionique) vont côtoyer des applications moins critiques (comme les systèmes multimédia embarqués en avionique). Pour que ces systèmes (comportant des applications avec différents niveaux de criticité) exploitent avec un niveau de performance acceptable les systèmes multi-coeurs, il convient d'exploiter tous les niveaux de parallélisme disponibles dans le calculateur sous-jacent. Or, le partitionnement robuste introduit par la technique d'isolation précitée limite cet aspect parallèle en séquençant les applications pour linéariser les accès aux 2 ressources logicielles et matérielles partagées. Ce faisant, il est utilisé des fenêtres temporelles découpant le temps d'exécution en intervalles où une seule fonction peut s'exécuter. Si une telle pratique s'adapte parfaitement aux calculateurs mono-coeurs, elle dégrade fortement les performances des calculateurs multi-coeurs. 5 Il existe donc un besoin pour un procédé de contrôle d'un système compatible avec les exigences d'un emploi en temps réel pour la mise en oeuvre d'applications critiques et non critiques qui puisse exploiter les performances des calculateurs multicoeurs. Pour cela, la présente description porte sur un procédé de contrôle d'un système 10 comprenant un calculateur comportant une pluralité de coeurs et des ressources communes à au moins deux coeurs, chaque coeur étant propre à exécuter des tâches, chaque tâche impliquant une pluralité de traitements et un ou plusieurs accès à au moins une ressource commune pendant une période de temps d'exécution prédéfinie, chaque accès induisant une variation d'une grandeur physique relative à la ressource commune, 15 chaque tâche étant critique ou non-critique, le procédé comportant au moins une étape de, pour chaque ressource commune, détermination de la variation du taux de ralentissement d'exécution dans l'exécution de chaque tâche critique en fonction de la valeur de la grandeur physique relative à la ressource commune pendant la période de temps d'exécution prédéfinie, de, pour chaque ressource commune, fixation d'une valeur 20 maximale pendant la période de temps prédéfinie en fonction d'un taux de ralentissement d'exécution prédéterminé et de la variation déterminée, d'exécution de l'ensemble des tâches par le calculateur, l'étape d'exécution comportant la mesure de la grandeur physique pour chaque ressource et l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, la valeur mesurée est supérieure à la valeur maximale fixée. 25 Suivant des modes de réalisation particuliers, le procédé de contrôle comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : - le procédé comporte, en outre, pour chaque ressource commune, une étape d'obtention de la valeur totale de la grandeur physique pour chaque tâche critique 30 exécutée pendant la période de temps prédéfinie. - le procédé comporte, pour chaque ressource commune, pendant la période de temps prédéfinie, une étape de fourniture d'un valeur maximale correspondant à la valeur de la grandeur physique possible pour la ressource commune considérée pour garantir un temps d'exécution maximal prédéfini pour un accès à la ressource 35 commune. 3 - l'étape d'exécution comporte aussi la mesure de la grandeur physique pour chaque tâche critique et l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, l'une au moins des deux conditions suivantes est remplie : une première condition selon laquelle la grandeur physique mesurée est 5 supérieure à la valeur maximale fournie, et une deuxième condition selon laquelle la somme de la grandeur physique mesurée pour chaque tâche critique exécutée est égale à la valeur totale obtenue. - le système est un système temps réel. - le système est un système embarqué, par exemple dans un avion, un satellite ou 10 un véhicule ferroviaire. - les ressources communes appartiennent au groupe constitué des mémoires, des bus de liaison, des antémémoires, des périphériques entrée/sortie, des ports d'accès et des réseaux sur puce. - la grandeur physique est choisie dans le groupe constitué d'un nombre d'accès à 15 la ressource commune, d'une consommation d'énergie, d'une température et d'une quantité de mémoire utilisée. La présente description se rapporte également à un produit programme d'ordinateur comportant un support lisible d'informations, sur lequel est mémorisé un programme d'ordinateur comprenant des instructions de programme, le programme 20 d'ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en oeuvre d'un procédé selon l'une quelconque des revendications précédentes lorsque le programme d'ordinateur est mis en oeuvre sur l'unité de traitement des données. La présente description concerne aussi un support lisible d'informations sur lequel 25 est mémorisé un produit programme d'ordinateur. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l'invention, donnés à titre d'exemple uniquement et en référence aux dessins qui sont : - figure 1, une vue schématique d'un ordinateur permettant la mise en oeuvre d'un 30 procédé de contrôle d'un système : - figure 2, une vue schématique d'un calculateur multi-coeur faisant partie d'un système ; - figure 3, un ordinogramme d'un exemple de mise en oeuvre d'un exemple de procédé de contrôle d'un système ; 35 - figure 4, une représentation schématique d'une manière de mettre en oeuvre une étape du procédé de contrôle de la figure 3; 4 - figure 5, une représentation schématique d'une manière de mettre en oeuvre une autre étape du procédé de contrôle de la figure 3; - figure 6, un graphe représentant l'évolution du temps d'exécution d'une tâche en fonction de la sollicitation d'une ressource ; 5 - figure 7, une représentation schématique d'une manière de mettre en oeuvre une autre étape du procédé de contrôle de la figure 3, et - figure 8, une représentation schématique d'une manière de mettre en oeuvre l'étape schématisée à la figure 7. Un ordinateur 10 et un produit programme d'ordinateur 12 sont représentés à la 10 figure 1. L'interaction du produit programme d'ordinateur 12 avec l'ordinateur 10 permet de mettre en oeuvre un procédé de contrôle d'un système. Plus généralement, l'ordinateur 10 est un calculateur électronique propre à manipuler et/ou transformer des données représentées comme des quantités électroniques ou physiques dans des registres du calculateur et/ou des mémoires en 15 d'autres données similaires correspondant à des données physiques dans des mémoires, des registres ou d'autres types de dispositifs d'affichage, de transmission ou de mémorisation. L'ordinateur 10 comporte un processeur 14 comprenant une unité de traitement de données 16, des mémoires 18 et un lecteur 20 de support d'informations. L'ordinateur 10 20 comprend également des périphériques d'entrée 22 et de sortie 24. Le produit programme d'ordinateur 12 comporte un support lisible d'informations. Un support lisible d'informations est un support lisible par l'ordinateur 10, usuellement par le lecteur 20. Le support lisible d'informations est un médium adapté à mémoriser des instructions électroniques et capable d'être couplé à un bus d'un système 25 informatique. A titre d'exemple, le support lisible d'informations est une disquette ou disque souple (de la dénomination anglaise de « t7oppy disk »), un disque optique, un CD-ROM, un disque magnéto-optique, une mémoire ROM, une mémoire RAM, une mémoire EPROM, une mémoire EEPROM, une carte magnétique ou une carte optique. 30 Sur le support lisible d'informations est mémorisé un programme d'ordinateur comprenant des instructions de programme. Le programme d'ordinateur est chargeable sur l'unité de traitement de données 16 et est adapté pour entraîner la mise en oeuvre du procédé d'optimisation. Le fonctionnement de l'ordinateur 10 en interaction avec le produit programme 35 d'ordinateur 12 est maintenant décrit en référence à un exemple de mise en oeuvre d'un procédé de contrôle d'un système 30. 5 Le système 30 est décrit en référence à la figure 2. Le système 30 est un système temps réel, c'est-à-dire un système ayant des tâches à accomplir dans un intervalle de temps prédéterminé pour assurer la sécurité. Par exemple, le système 30 est un système embarqué, notamment destiné à faire 5 partie d'un avion, d'un satellite ou d'un véhicule ferroviaire. Le système 30 comprend un calculateur 32 comportant une pluralité de coeurs 34, des ressources propres 36 à un coeur 34 et des ressources communes 38, 40, 42, 44 et 46 à au moins deux coeurs 34. Chaque coeur 34 est propre à exécuter des tâches. 10 Par définition, une tâche est un ensemble d'au moins une opération. Chaque tâche est critique ou non-critique. Une tâche est critique dès que l'exécution de cette tâche impacte la sécurité du système 30. Toutes les autres tâches sont non-critiques. Chaque tâche implique une pluralité de traitements et un ou plusieurs accès à au 15 moins une ressource commune 38, 40, 42, 44 et 46 pendant une période de temps d'exécution. Le nombre de tâches est très grand. Par contraste, le nombre de coeurs 34 est restreint, typiquement entre 2 et 12. Dans l'exemple décrit, le système 30 comporte quatre coeurs 34 et les ressources 20 propres 36 à un coeur 34 sont une mémoire cache. Une mémoire cache ou antémémoire est, en informatique, une mémoire qui enregistre temporairement des copies de données provenant d'une source, pour diminuer le temps d'un accès ultérieur (en lecture) d'un matériel informatique (en général, un processeur) à ces données. 25 De manière générale, les ressources communes 38, 40, 42, 44 et 46 appartiennent au groupe constitué des mémoires, des bus de liaison, des antémémoires, des périphériques entrée/sortie, des ports d'accès et des réseaux sur puce. Dans le cas de la figure 2, les ressources communes 38, 40, 42, 44 et 46 sont deux mémoires caches 38 et 40, un bus de liaison 42, une mémoire 44 et un module 30 d'entrée-sortie 46. La première mémoire cache 38 coopère avec la mémoire cache 36 spécifique au premier coeur 34 et avec la mémoire cache 36 spécifique au deuxième coeur 34. La première mémoire cache 38 est ainsi partagée par le premier coeur 34 et le deuxième coeur 34. 35 Similairement, la deuxième mémoire cache 40 coopère avec la mémoire cache 36 spécifique au troisième coeur 34 et avec la mémoire cache 36 spécifique au quatrième 6 coeur 34. La deuxième mémoire cache 40 est ainsi partagée par le troisième coeur 34 et le quatrième coeur 34. Le bus de liaison 42 permet de connecter les deux mémoires cache 38 et 40 avec la mémoire 44 et le module d'entrée-sortie 46 pour que ces ressources communes 5 puissent communiquer entre elles. En fonctionnement du calculateur 32, il existe des cas impliquant des requêtes simultanées par plusieurs coeurs 34 sur une même ressource partagée ou commune 38, 40, 42, 44 et 46. Sur la figure 2, de tels phénomènes sont montrés par des collisions 48 entre trajets. Dans de tels cas aussi appelés « interférences temporelles », un arbitrage 10 est réalisé au niveau matériel pour accorder l'accès à une requête et bloquer les autres jusqu'à la fin de la transaction. Cela implique une variabilité du temps d'exécution des tâches. Le procédé de contrôle du système 30 vise à gérer de telles interférences. Dans l'exemple proposé à la figure 3, le procédé de contrôle comporte une étape 15 de fourniture S50, une étape de calcul S52 et une étape d'exécution S54. Par exemple, les étapes de fourniture S50 et de calcul S52 sont mises en oeuvre hors ligne (c'est-à-dire sans faire fonctionner le calculateur) alors que l'étape d'exécution S54 est mise en oeuvre en ligne (c'est-à-dire en fonctionnement du calculateur). La séparation entre étapes avec et sans fonctionnement du calculateur est matérialisé sur la figure 3 par un trait 56 en 20 pointillés. L'étape de fourniture S50 est mise en oeuvre pour chaque ressource commune. Lors de l'étape de fourniture S50, il est fourni le nombre d'accès maximal possible pour la ressource commune considérée pour garantir un temps d'exécution maximal prédéfini pour un accès à la ressource commune. 25 Comme visible sur la figure 4, pour une ressource commune, l'étape de fourniture S50 prend en compte en entrée la structure du calculateur (indiquée par le rectangle 60), un mécanisme de mesure du temps d'exécution et du nombre d'accès à la ressource commune (indiqué par le rectangle 62) et un solliciteur de ladite ressource commune (indiqué par le rectangle 64) pour obtenir en sortie le nombre d'accès maximal 30 possible pour la ressource commune (indiqué par le rectangle 66). Le solliciteur de la ressource commune aussi appelé sous le terme anglais de « stressing benchmark » permet de multiplier les accès à la ressource commune. Plus précisément, le solliciteur permet une augmentation progressive des accès à la ressource commune. 35 En parallèle, l'augmentation du temps d'exécution d'une opération par la ressource commune (voir rectangle 52) est suivie de sorte qu'il est obtenu le nombre d'accès 7 maximal possible pour la ressource commune considérée pour garantir un temps d'exécution maximal prédéfini pour un accès à la ressource commune. A l'issue de l'étape de fourniture S50, l'ensemble des nombres d'accès maximaux possibles sont connus pour chaque ressource commune. 5 L'étape de calcul S52 est mise en oeuvre pour chaque ressource commune. Comme visible sur la figure 5, pour une ressource commune, l'étape de calcul S52 prend en compte quatre entrées pour obtenir deux sorties. Les quatre entrées sont la structure du calculateur (indiquée par le rectangle 60), un mécanisme de mesure du temps d'exécution et du nombre d'accès à la ressource 10 commune (indiqué par le rectangle 62), un solliciteur de ladite ressource commune (indiqué par le rectangle 64) et les tâches critiques (indiquées par le rectangle 68). Les deux sorties sont le nombre d'accès maximal possible à la ressource commune pour les tâches critiques (voir rectangle 70 sur la figure 5) et le nombre d'accès maximal possible à la ressource commune pour les tâches non-critiques (voir 15 rectangle 72 sur la figure 5). Un exemple de mise en oeuvre de l'étape de calcul S52 est maintenant décrit. L'étape de calcul S52 comporte une étape de détermination, une étape de fixation et une étape d'obtention. Lors de l'étape de détermination S52, il est déterminé la variation du taux de 20 ralentissement d'exécution dans l'exécution de chaque tâche critique en fonction du nombre d'accès à la ressource commune pendant la période de temps d'exécution prédéfinie. Lors de l'étape de fixation, il est fixé un nombre d'accès maximal pendant la période de temps prédéfinie en fonction d'un taux de ralentissement d'exécution 25 prédéterminé et de la variation du nombre d'accès à la ressource commune déterminée. Lors de l'étape d'obtention, il est obtenu le nombre total d'accès à la ressource commune pour chaque tâche critique exécutée pendant la période de temps prédéfinie. Le nombre total d'accès à la ressource commune pour chaque tâche non-critique se déduit par soustraction au nombre d'accès maximal possible pour la ressource commune 30 du nombre total d'accès à la ressource commune pour chaque tâche critique. Le fonctionnement des étapes de détermination, de fixation et d'obtention apparaît plus précisément en étudiant le graphe de la figure 6. L'axe des ordonnées représente dans la fenêtre temporelle courante, le pire temps d'exécution de la tâche critique qui est suivie tandis que l'axe des abscisses représente la sollicitation (c'est-à-dire l'accès dans 35 ce contexte) à la ressource matérielle considérée. La sollicitation est induite par le solliciteur. 8 L'ordonnée à l'origine (matérialisé par un signe de référence 74) correspond au pire temps d'exécution de la tâche critique considérée en supposant que la tâche critique soit la seule à être exécutée. Comme attendu, plus l'accès à la ressource matérielle considérée augmente et plus le pire temps d'exécution de la tâche critique augmente 5 jusqu'à devenir tellement grand que cela correspond à une impossibilité pour la tâche critique de se réaliser. La variation du taux de ralentissement d'exécution dans l'exécution de chaque tâche critique en fonction du nombre d'accès à la ressource commune pendant la période de temps d'exécution prédéfinie est donc la valeur dérivée de la courbe représentée sur la 10 figure 6. En utilisant la courbe représentée sur la figure 6 et compte-tenu de la structure du calculateur et des tâches critiques considérées, les experts savent définir une pente maximale au-delà de laquelle le ralentissement devient trop rapidement asymptotique. Pour le cas de la figure 6, la pente maximale, c'est-à-dire le taux de ralentissement 15 d'exécution maximal, est montrée par le signe de référence 76. Le point 78 correspondant à la pente maximale (c'est-à-dire le point en lequel la tangente à la courbe représentée sur la figure 6 présente la pente maximale) comporte une abscisse 80 et une ordonnée 82. Ladite ordonnée 82 correspond au niveau de ralentissement acceptable des tâches alors que ladite abscisse 80 correspond au budget 20 en termes d'accès disponible pour les tâches non-critiques tout en garantissant un taux de ralentissement acceptable. En répétant l'étape de calcul S52 pour chaque ressource commune, il est obtenu pour chacune un nombre maximal d'accès possible pour chaque type de tâches. Lors de l'étape d'exécution S54, l'ensemble des tâches est mis en oeuvre par le 25 calculateur. L'étape d'exécution S54 comporte la mesure du nombre d'accès à la ressource commune pour chaque ressource et pour chaque tâche non-critique. L'étape d'exécution 854 comporte l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, le nombre d'accès mesuré est supérieur au nombre d'accès 30 maximal fixé pour l'ensemble des tâches non-critiques. Cette manière de mettre en oeuvre l'étape d'exécution S54 est illustrée schématiquement par la figure 7, le signe de référence 84 désignant les tâches non-critiques. Autrement formulé, le calculateur 32 s'assure en temps réel que les tâches non- 35 critiques ne consomment pas au-delà des budgets qui leur sont alloués, suspendant temporairement au besoin les applications les moins critiques. 9 Le procédé de contrôle relâche le principe de partitionnement temporel entre des tâches de criticités différentes, autorisant les tâches moins critiques à être interrompues en cas de mise en danger des tâches critiques. Cela permet une meilleure exploitation du parallélisme en autorisant les tâches non-critiques à s'exécuter en même temps que les 5 tâches critiques. Le procédé de contrôle permet de mieux contrôler le système 30 en évitant l'occurrence d'interférences temporelles. Le procédé de contrôle repose sur une régulation basée sur des budgets qui va surveiller l'utilisation des ressources partagées par les tâches non-critiques en fonction 10 des besoins de la tâche critique, et temporairement interrompre les tâches non-critiques pour assurer le niveau de qualité de service nécessaire aux tâches critiques. Le procédé de contrôle est ainsi une solution de régulation à base de budgétisation des ressources matérielles pour des systèmes temps réel à criticité mixte, c'est-à-dire impliquant l'exécution de tâches critiques et non-critiques. 15 Le procédé de contrôle permet donc une meilleure exploitation des ressources du calculateur à multi-coeurs, et donc une meilleure performance pour les systèmes embarqués critiques à criticité mixte. De plus, il est à noter que la mise en oeuvre du procédé de contrôle est simple, se contentant de compter les accès, ce qui est important du point de vue de la certification 20 du procédé. Cela permet de faire exécuter des tâches en parallèle sans avoir à les réécrire ni les modifier et donc sans avoir à les recertifier. Le processus de développement établi pour les processeurs mono-coeurs peut donc directement être réutilisé en évitant le surcoût important lié au processus de certification. Selon un autre mode de réalisation, l'étape d'exécution S54 prend en compte les 25 tâches critiques (voir rectangle indiqué 68) et le nombre d'accès maximal possible pour la ressource commune (indiqué par le rectangle 66) au lieu des tâches non-critiques (voir rectangle 84) comme dans la figure 8. En outre, l'étape d'exécution S54 prend en compte le nombre d'accès maximal possible à la ressource commune pour les tâches critiques (voir rectangle 70) au lieu du nombre d'accès maximal possible à la ressource commune 30 pour les tâches non-critiques (voir rectangle 72). Dans un tel mode de réalisation, l'étape d'exécution S54 comporte aussi la mesure du nombre d'accès à la ressource pour chaque tâche critique et l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource une première condition ou une deuxième condition est remplie. 35 La première condition est remplie si le nombre d'accès à la ressource mesuré est supérieur au nombre d'accès maximal à la ressource fournie. 10 La deuxième condition est remplie si le nombre d'accès à la ressource mesuré pour chaque tâche critique exécutée est égal au nombre d'accès total obtenu. Un tel mode de réalisation permet de réaliser un autodiagnostic visant à surveiller en temps réel la charge des tâches critiques en termes d'accès à chaque ressource, et de 5 s'assurer ainsi que la charge du système reste sous les niveaux imposés par les autorités de régulation ou les clients. Le procédé décrit ici, qui détermine des budgets en termes de nombre d'accès aux ressources, peut également être étendu à d'autres types de budgets. Par exemple, au lieu du nombre d'accès à la ressource commune, le procédé de 10 contrôle est appliqué pour la consommation d'énergie de la ressource commune. Selon une autre variante, au lieu du nombre d'accès à la ressource commune, le procédé de contrôle est appliqué pour la température de la ressource commune. Selon encore une autre variante, au lieu du nombre d'accès à la ressource commune, le procédé de contrôle est appliqué pour une quantité de mémoire utilisée. 15 Dans tous les cas, REVENDICATIONS1.- Procédé de contrôle d'un système (30) comprenant un calculateur comportant une pluralité de coeurs et des ressources communes à au moins deux coeurs, chaque coeur étant propre à exécuter des tâches, chaque tâche impliquant une pluralité de traitements et un ou plusieurs accès à au moins une ressource commune pendant une période de temps d'exécution prédéfinie, chaque accès induisant une variation d'une grandeur physique relative à la ressource commune, chaque tâche étant critique ou non-critique, le procédé comportant au moins une étape de : - pour chaque ressource commune, détermination de la variation du taux de ralentissement d'exécution dans l'exécution de chaque tâche critique en fonction de la valeur de la grandeur physique relative à la ressource commune pendant la période de temps d'exécution prédéfinie, - pour chaque ressource commune, fixation d'une valeur maximale pendant la période de temps prédéfinie en fonction d'un taux de ralentissement d'exécution prédéterminé et de la variation déterminée, - exécution de l'ensemble des tâches par le calculateur, l'étape d'exécution comportant la mesure de la grandeur physique pour chaque ressource et l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, la valeur mesurée est supérieure à la valeur maximale fixée. 2.- Procédé selon la revendication 1, dans lequel le procédé comporte, en outre, pour chaque ressource commune, une étape d'obtention de la valeur totale de la grandeur physique pour chaque tâche critique exécutée pendant la période de temps prédéfinie. 3.- Procédé selon la revendication 1 ou 2, dans lequel, le procédé comporte, pour chaque ressource commune, pendant la période de temps prédéfinie, une étape de fourniture d'un valeur maximale correspondant à la valeur de la grandeur physique possible pour la ressource commune considérée pour garantir un temps d'exécution maximal prédéfini pour un accès à la ressource commune. 4.- Procédé selon la revendication 3 dans sa dépendance avec la revendication 2, dans laquelle l'étape d'exécution comporte aussi la mesure de la grandeur physique pour chaque tâche critique et l'arrêt de l'exécution des tâches non-critiques dès que, pour une ressource, l'une au moins des deux conditions suivantes est remplie : 12 - une première condition selon laquelle la grandeur physique mesurée est supérieure à la valeur maximale fournie, et - une deuxième condition selon laquelle la somme de la grandeur physique mesurée pour chaque tâche critique exécutée est égale à la valeur totale obtenue. 5 5.- Procédé selon l'une quelconque des revendications 1 à 4, dans lequel le système (30) est un système temps réel. 6.- Procédé selon l'une quelconque des revendications 1 à 5, dans lequel le 10 système (30) est un système embarqué, par exemple dans un avion, un satellite ou un véhicule ferroviaire. 7.- Procédé selon l'une quelconque des revendications 1 à 6, dans lequel les ressources communes appartiennent au groupe constitué des mémoires, des bus de 15 liaison, des antémémoires, des périphériques entrée/sortie, des ports d'accès et des réseaux sur puce. 8.- Procédé selon l'une quelconque des revendications 1 à 7, dans lequel la grandeur physique est choisie dans le groupe constitué d'un nombre d'accès à la 20 ressource commune, d'une consommation d'énergie, d'une température et d'une quantité de mémoire utilisée. 9.- Produit programme d'ordinateur comportant un support lisible d'informations, sur lequel est mémorisé un programme d'ordinateur comprenant des instructions de 25 programme, le programme d'ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en oeuvre d'un procédé selon l'une quelconque des revendications précédentes lorsque le programme d'ordinateur est mis en oeuvre sur l'unité de traitement des données. 30 10.- Support lisible d'informations sur lequel est mémorisé un produit programme d'ordinateur selon la revendication 9.