Ouvrir le menu Fermer le menu

Défi des processeurs multicœurs et des WCET

trait de séparation

Processeurs multicœurs et Worst-Case Execution Times (WCET) : pourquoi l'analyse statique est importante

Temps de lecture : 8 minutes

Canaux d'interférence et processeurs multicœurs
Les canaux d'interférence font des calculs WCET une question épineuse

Le défi posé par les processeurs multicœurs et Worst-Case Execution Times (WCET) est depuis longtemps un écueil récurrent pour les développeurs d'applications critiques en temps réel.

Les systèmes temps réel de contrôle en boucle fermée, ce qui ne permet qu'une fenêtre de temps restreinte pour collecter des données, les traiter et mettre à jour le système en conséquence. Si la fenêtre temporelle est manquée, la stabilité du système est dégradée - et cela peut être catastrophique pour les applications critiques.

Par nature, les processeurs mono-cœur ne peuvent pas exécuter plusieurs processus en parallèle en même temps et utilisent un principe de séquencement rapide pour donner l'impression qu'ils le font. Comme l'ont prouvé Liu et Layland dès 1973, il existe une base très solide pour adopter une telle approche. Pour un processeur mon-cœur, les systèmes temps réel multitâches peuvent être assurés de respecter leurs délais tant qu'une marge (capacité) CPU suffisante est disponible.

Le défi des processeurs multicœurs et des Worst-Case Execution Times (WCET)

Les processeurs multicœurs (MCP – Multi-Core Processors) introduisent un niveau de complication supplémentaire par rapport aux processeur mono-cœur (SCP – Single Cor Processors) dans la mesure où ils exécutent véritablement plusieurs processus en parallèle. Contrairement aux applications à processeur unique, la principe consistant à trouver un séquencement de la tâche X sur le cœur Y du processeur de sorte que toutes les tâches respectent leur échéance n'est pas une approche algorithmique efficace.

Exacerbant ce problème, dans les processeurs multicœurs, des interférences matérielles peuvent se produire partout où le matériel est partagé entre les processus. Par exemple, une mémoire hiérarchique entière est souvent partagée, de sorte que des interférences sont possibles à de nombreux endroits. Ces canaux d'interférence provoquent l'étalement de la distribution des temps d'exécution. Au lieu d'un pic serré, la distribution des temps d'exécution s’étale sur une longue période.

En dehors du domaine des applications critique, cette problématique n'a que peu d'importance. Mais là où la sécurité fonctionnelle est primordiale, elle est essentielle.

Le rôle de l'analyse statique

Bien que des outils d'analyse statique existent à cet effet, même pour un processeur monocœur, le calcul d'une valeur définitive de WCET par analyse mathématique n'est pas réalisable soluble dans le cas général. Selon Reinhard Wilhelm et al ., une telle approche nécessitera donc l'application d'approximations qui doivent être correctes, mais pas nécessairement complètes. Le résultat est que de tels outils pécheront nécessairement "du côté sûr", ce qui est mieux que rien, mais dans un environnement où la précision est primordiale, cela ne peut pas être idéal - même sans les aléas supplémentaires introduits par les MCP.

Cependant, il existe depuis longtemps des mécanismes éprouvés pour mesurer les propriétés du code d’un logiciel qui sont indépendants de la plateforme matérielle sur laquelle le code est exécuté. Par exemple, les métriques de Halstead reflètent la mise en œuvre ou l'expression d'algorithmes dans différents langages pour évaluer la taille du module logiciel, la complexité du logiciel et les informations sur le flux de données - et celles-ci peuvent être calculées précisément à partir de l'analyse statique du code source (ci-dessous) en utilisant le Composant TBvision de la suite d'outils LDRA. Une telle approche peut identifier les sections de code qui demandent le plus de temps de traitement, mais ne peut pas fournir de valeurs absolues pour le temps maximum écoulé.

Les mesures de Halstead sont calculées avec précision à l'aide de l’analyse statique


Utilisation de l'analyse statique pour piloter l'analyse dynamique WCET

Il n'y a pas de meilleur moyen de déterminer comment ces informations se traduisent en temps écoulé pour une fonction particulière ou un arbre d'appels qu'en les mesurant dans l'environnement dans lequel elles sont destinées à s'exécuter. Cela peut être mesuré dynamiquement en déployant le composant TBrun de la suite d'outils LDRA.

Pour la plupart, les tests unitaires sont similaires, que les MCP soient utilisés ou non. Cependant, l'analyse temporelle est particulièrement importante dans les systèmes basés sur MCP, en raison de la nécessité de démontrer que les interférences multicœurs ont été traitées de manière adéquate.

La suite d'outils LDRA est capable de mesurer le WCET de manière dynamique, en mesurant tour à tour les performances de chaque cycle complet d’exécution sur un système en cours d'exécution. Cela inclut la capacité de charger un ou plusieurs cœurs, forçant les interférences matérielles à jouer un rôle.

L'approche d'analyse s'appuie sur une technologie de test unitaire éprouvée, qui exerce à plusieurs reprises le code tout en mesurant le temps d’exécution, tout en stressant simultanément le système matériel sur lequel est exécuté le test.

Les graphiques générés montrent la détérioration des temps d'exécution avec des cœurs de processeur sous charge

Processeurs multicœurs et WCET : conclusions

Le défi posé par les processeurs multicœurs et les mesures WCET est depuis longtemps une problématique pour les développeurs d'applications temps réel critiques.

Il ne fait aucun doute qu'une approche empirique de l'analyse WCET par des moyens dynamiques est la meilleure - peut-être la seule - façon de démontrer que les canaux d'interférence ont été suffisamment atténués.

Cependant, l'analyse statique a un rôle clé à jouer pour s'assurer que ces mesures sont vraiment représentatives des pires scénarios en permettant aux mesures de se concentrer sur les chemins d'exécution les plus exigeants à travers le code.

Plus d'informations sur la capacité de la suite d'outils LDRA à prendre en charge les applications critiques utilisant des processeurs multicœurs sont disponibles : contactez-nous

0