Calcul Charge Cpu Systeme Temps Reel

Estimez rapidement la charge processeur d’un système temps réel à partir du temps d’exécution des tâches, de leur période, du nombre de cœurs et des surcharges d’interruption. Cette calculatrice aide à juger la marge de sécurité avant déploiement embarqué, industriel ou logiciel critique.

Calculateur interactif

Modèle basé sur l’utilisation totale U = somme(Ci / Ti), ajustée par surcharge, marge de sécurité et nombre de cœurs.

Guide expert du calcul de charge CPU pour un système temps réel

Le calcul de charge CPU système temps réel est une étape centrale dans la conception de logiciels embarqués, d’automatismes industriels, de systèmes robotisés, de plateformes avioniques et de tout environnement où une tâche doit finir avant une échéance déterminée. Contrairement à un simple serveur web ou à un ordinateur de bureau, un système temps réel ne se contente pas d’obtenir de bonnes performances moyennes. Il doit respecter une garantie temporelle explicite. En pratique, cela signifie qu’il faut non seulement mesurer l’utilisation processeur, mais aussi comprendre comment chaque tâche consomme du temps CPU à l’intérieur de sa période et comment les interruptions, le noyau, les pilotes et la variabilité du matériel réduisent la marge réelle.

La formule la plus connue repose sur l’utilisation de chaque tâche périodique. Si une tâche i exécute un calcul de durée Ci pendant une période Ti, alors son utilisation vaut Ui = Ci / Ti. La charge CPU totale est la somme des Ui pour toutes les tâches. Dans un cas simple, si trois tâches utilisent respectivement 30 %, 25 % et 16 % du temps processeur, la charge totale brute est de 71 %. Cette valeur sert de base à l’analyse d’ordonnançabilité. Cependant, dans un projet réel, il faut ensuite ajouter la surcharge du système, les interruptions, les context switches, les protections mémoire, les accès DMA et une marge de sécurité destinée à absorber les pics, les futures évolutions logicielles et l’incertitude de mesure du WCET.

Pourquoi la charge CPU ne suffit pas à elle seule

Une erreur fréquente consiste à croire qu’un processeur chargé à 60 % est nécessairement sûr. Ce n’est vrai ni en ordonnancement préemptif, ni en architecture multicœur, ni en système critique. Deux plateformes affichant 60 % d’utilisation moyenne peuvent avoir des comportements radicalement différents. L’une peut respecter toutes les deadlines parce que les tâches sont bien harmonisées et les priorités bien choisies. L’autre peut manquer une échéance importante parce qu’une tâche très courte mais très fréquente bloque périodiquement une tâche de contrôle avec une deadline serrée. Autrement dit, le pourcentage global est indispensable, mais il doit être lu avec la structure des périodes, les priorités, la latence d’interruption et la dispersion temporelle.

Pour cette raison, les ingénieurs temps réel s’appuient souvent sur trois niveaux d’analyse :

• Charge brute : somme des Ci / Ti, utile pour un premier filtre rapide.
• Charge ajustée : ajout de la surcharge noyau, des interruptions et d’une marge de sécurité.
• Ordonnançabilité : comparaison à une borne théorique ou à une analyse de réponse temporelle plus détaillée.

Les politiques d’ordonnancement les plus courantes

Dans un système monoprocesseur idéal composé de tâches périodiques indépendantes et préemptives, deux cadres théoriques sont souvent évoqués :

1. EDF, Earliest Deadline First : si les hypothèses théoriques sont respectées, un ensemble de tâches peut être ordonnancé tant que la charge totale n’excède pas 100 %.
2. RMS, Rate Monotonic Scheduling : priorité fixe basée sur la période, avec une borne de sûreté plus conservatrice. Pour n tâches, une borne classique vaut n(2^(1/n) – 1).

Pour trois tâches, la borne RMS théorique est proche de 77,98 %. Cette valeur ne signifie pas qu’au-delà tout est impossible, mais qu’en dessous on dispose d’une garantie mathématique plus simple. Au-dessus, il faut généralement une analyse plus fine du temps de réponse. C’est précisément pour cette raison que beaucoup d’équipes imposent en exploitation une cible pratique comprise entre 60 % et 75 % selon la criticité, même si la théorie autorise parfois davantage.

Nombre de tâches périodiques	Borne RMS théorique maximale	Valeur en pourcentage	Lecture pratique
1	1,0000	100,00 %	Une tâche unique est théoriquement ordonnançable jusqu’à saturation complète.
2	0,8284	82,84 %	Bon repère pour deux boucles périodiques principales.
3	0,7798	77,98 %	Cas courant pour contrôle, communication et supervision.
5	0,7435	74,35 %	La borne baisse à mesure que le nombre de tâches augmente.
10	0,7177	71,77 %	On se rapproche progressivement de la limite asymptotique.
Infini	ln(2)	69,31 %	Référence classique pour un grand nombre de tâches.

Comment interpréter le calculateur ci-dessus

Le calculateur prend trois tâches périodiques et estime la charge totale. Il effectue ensuite quatre traitements :

• Calcul de la charge brute à partir de chaque ratio Ci / Ti.
• Ajout d’une surcharge en pourcentage pour représenter l’ordonnanceur, les interruptions et le coût d’infrastructure.
• Ajout d’une marge de sécurité pour refléter l’incertitude ou l’évolution future.
• Division par le nombre de cœurs afin d’obtenir une occupation moyenne par cœur, utile comme indicateur de capacité globale.

Il faut toutefois rester vigilant sur le multicœur. La division par le nombre de cœurs donne une vision de capacité moyenne, mais elle ne remplace pas une analyse d’affinité ou de partitionnement. Une tâche critique attachée au cœur 0 peut rater sa deadline même si la moyenne globale par cœur reste faible. Dans les systèmes durcis, on vérifie donc à la fois la vue globale et la vue locale, cœur par cœur, file d’interruptions par file d’interruptions.

Les sources d’erreur les plus fréquentes dans le calcul de charge CPU

Un calcul apparemment propre peut devenir trompeur si les données d’entrée sont mauvaises. Voici les pièges les plus courants :

• Mesure moyenne au lieu du pire cas : utiliser un temps d’exécution moyen sous-estime fortement le risque temps réel.
• Périodes supposées stables : certaines tâches sont pseudo-périodiques, événementielles ou bursty.
• Interruptions oubliées : capteurs, réseau, stockage, watchdog et drivers ont un coût non négligeable.
• Effets cache et mémoire : un code stable en laboratoire peut ralentir en présence de contention mémoire ou d’accès DMA.
• Variation de fréquence CPU : DVFS, thermal throttling ou modes basse consommation modifient la capacité effective.
• Jitter d’activation : des arrivées irrégulières de tâches augmentent les recouvrements et les pics de latence.

Bon réflexe d’ingénierie : dans un système critique, on ne se limite pas à un unique pourcentage de charge. On ajoute un budget explicite pour les interruptions, on trace les temps de réponse, on teste sous charge maximale et on conserve une réserve opérationnelle documentée.

Repères opérationnels pour les marges de sécurité

Les valeurs ci-dessous ne remplacent pas une preuve d’ordonnançabilité, mais elles représentent des repères réalistes fréquemment utilisés dans les études de capacité.

Niveau de criticité	Charge cible souvent visée	Marge recommandée	Commentaire pratique
Prototype laboratoire	70 % à 85 %	10 % à 15 %	Acceptable pour validation initiale, sous réserve de tests de stress.
Produit industriel standard	60 % à 75 %	15 % à 25 %	Compromis classique entre coût matériel et robustesse opérationnelle.
Système critique ou certifiable	40 % à 65 %	25 % à 40 %	La réserve sert à absorber les cas extrêmes et à faciliter l’argumentaire de sûreté.
Plateforme multicœur avec forte contention mémoire	50 % à 70 %	20 % à 35 %	La capacité théorique est souvent amputée par les interférences de bus et de cache.

Méthode pas à pas pour calculer correctement la charge CPU temps réel

1. Inventoriez les tâches : boucle de contrôle, acquisition, traitement signal, communication, journalisation, diagnostic, interface machine.
2. Mesurez ou estimez le WCET : utilisez des tests de pire cas, pas seulement des moyennes.
3. Définissez les périodes et deadlines : une tâche de 1 ms n’a pas le même impact qu’une tâche de 100 ms.
4. Calculez chaque Ui : divisez le WCET par la période.
5. Sommez toutes les utilisations : obtenez la charge CPU brute.
6. Ajoutez les surcharges : interruptions, ordonnanceur, latence d’E/S, synchronisation.
7. Ajoutez une marge : croissance fonctionnelle, bruit de mesure, scénarios anormaux.
8. Comparez au seuil choisi : EDF, RMS ou seuil conservateur interne.
9. Validez dynamiquement : effectuez des campagnes de test avec traces temporelles.
10. Réitérez : un budget temps réel est un document vivant, pas un calcul unique.

Exemple concret

Supposons un contrôleur avec trois tâches : une acquisition capteur de 3 ms toutes les 10 ms, un calcul de régulation de 5 ms toutes les 20 ms, et une télémétrie de 8 ms toutes les 50 ms. La charge brute vaut 3/10 + 5/20 + 8/50 = 0,30 + 0,25 + 0,16 = 0,71, soit 71 %. Si l’on ajoute 8 % de surcharge système et 15 % de marge de sécurité, on obtient environ 87,33 %. Sur deux cœurs, la moyenne descend à 43,67 % par cœur, mais cette lecture doit être confirmée par la répartition réelle des tâches. En monoprocesseur RMS, 71 % reste sous la borne asymptotique de 69,31 % seulement si le nombre de tâches est très grand ; pour trois tâches, la borne théorique est de 77,98 %, donc l’ensemble peut encore être jugé acceptable comme premier filtre. En revanche, si des interruptions réseau imprévues ajoutent 10 % réels, la marge devient faible et une optimisation ou un changement d’architecture peut s’imposer.

Mesure, validation et observabilité

Les meilleures équipes ne s’arrêtent jamais au tableur. Elles combinent le calcul théorique avec des mesures sur cible. Cela inclut des traces d’ordonnancement, des compteurs de performance, des chronogrammes GPIO, des logs d’interruptions et parfois des sondes matérielles. Le NIST publie régulièrement des ressources utiles sur les systèmes cyber-physiques, la synchronisation temporelle et la robustesse de l’infrastructure numérique. Pour les applications spatiales et embarquées exigeantes, la NASA met à disposition des documents techniques sur les architectures logicielles et la fiabilité des systèmes embarqués. Côté fondements académiques, l’University of Michigan EECS et d’autres départements d’ingénierie publient de nombreux supports sur l’ordonnancement temps réel, l’analyse de charge et la prévisibilité multicœur.

La validation pratique doit se faire dans des conditions réalistes : température haute, tension basse si applicable, charge réseau maximale, mémoire fragmentée, périphériques actifs et mode de fonctionnement nominal complet. Une plateforme qui semble stable dans un scénario de démonstration peut se dégrader fortement quand les files d’E/S se remplissent, quand la télémétrie passe en mode intensif ou quand plusieurs IRQ arrivent en rafale. La qualité d’un calcul de charge CPU tient donc autant au modèle qu’à la discipline de mesure sur le terrain.

Que faire si la charge est trop élevée ?

Quand la charge ajustée devient trop proche du seuil admissible, plusieurs stratégies sont possibles :

• Réduire le WCET par optimisation algorithmique, vectorisation, réduction des copies mémoire ou amélioration cache.
• Allonger la période des tâches non critiques afin de libérer du budget CPU.
• Découpler acquisition, traitement et communication pour mieux lisser les pics.
• Déplacer certaines fonctions vers un coprocesseur, un FPGA ou un accélérateur dédié.
• Répartir proprement les tâches sur plusieurs cœurs avec affinité maîtrisée.
• Supprimer les logs excessifs, les allocations dynamiques et les sections critiques longues.
• Revoir la politique d’ordonnancement, les priorités et les mécanismes de synchronisation.

Conclusion

Le calcul de charge CPU d’un système temps réel est à la fois simple dans sa formule de base et exigeant dans son interprétation. Oui, la somme des Ci / Ti est le point de départ incontournable. Mais une décision d’ingénierie sérieuse nécessite aussi l’intégration de la surcharge d’exécution, d’une marge de sécurité, du modèle d’ordonnancement, de la topologie multicœur et des preuves expérimentales. Utilisez le calculateur de cette page comme un excellent filtre de premier niveau : il permet d’identifier rapidement les architectures surchargées, de discuter les budgets CPU et de communiquer clairement l’état de capacité. Pour un système réellement critique, complétez toujours ce résultat par une analyse de réponse temporelle, des traces sur cible et une politique formelle de validation.