L’IRT Saint Exupéry a fait des systèmes embarqués critiques l’une de ces spécialités. Dans un premier article, nous vous avons expliqué en quoi les activités de recherche dans le domaine du logiciel sont primordiales, spécifiquement dans le secteur de l’aéronautique et du spatial.
Nous continuons notre série de contenus dédiés à ce thème de recherche en évoquant l’importance de l’analyse des temporelles systèmes. C’est également l’occasion de mettre en lumière les travaux réalisés par l’IRT Saint Exupéry ces dix dernières années sur ce sujet.
Plus vite…
La performance et la complexité des plateformes de traitement évoluent de façon conjointe à celle des logiciels qu’elles exécutent. Le processus a même une tendance naturelle à s’amplifier puisque tout incrément de performance est immédiatement exploité pour ajouter de nouvelles capacités fonctionnelles qui vont finalement requérir de nouvelles capacités de traitement…
Jusqu’à une période récente, l’augmentation régulière de la fréquence d’horloge des processeurs a constitué un levier majeur d’amélioration des performances. Ce modèle, particulièrement avantageux pour les développeurs, offrait des gains de performance presque « gratuits » puisqu’il suffisait de porter une application sur un nouveau matériel pour bénéficier de performances accrues.
Mais ce modèle a désormais atteint ses limites.
Ces limites sont physiques. Elles sont déterminées notamment par la capacité de dissiper la chaleur produite par des transistors toujours plus rapides, petits et nombreux sur une même surface de silicium. Afin de surmonter ces contraintes et continuer à améliorer les vitesses de traitement, l’approche repose désormais sur l’utilisation d’unités de traitement très sophistiquées, leur multiplication ainsi que leur spécialisation.
L’illustration ci-dessous montre très clairement cette évolution : si la courbe du nombre de transistors suit encore une trajectoire exponentielle, la courbe de la fréquence a atteint une asymptote depuis le milieu des années 2000 ; elle est désormais « relayée » par le nombre de cœurs qui, lui, ne cesse de croitre.
(extrait de https://www.karlrupp.net/2018/02/42-years-of-microprocessor-trend-data/ )
Si cette évolution a transformé le marché il y a déjà plus d’une décennie, elle soulève encore de nombreux défis dans le domaine des systèmes temps-réel critiques. En effet, dans le marché « grand public » qui, in fine, pilote le marché des microprocesseurs, la priorité est « l’expérience utilisateur », c’est-à-dire la performance perçue par l’utilisateur. Dans ce contexte, respecter les échéances dans 99% du temps est suffisant pour l’utilisateur.
L’objectif est rempli même si ces mêmes échéances de temps sont violées ; le résultat obtenu est acceptable d’un point de vue économique. Réduire les 1% de cas hors spécification nécessiterait probablement un effort trop important pour un bénéfice économique très réduit.
Spécificité du secteur aéronautique et spatial :
En revanche, cette approche est incompatible avec les exigences du monde du temps-réel critique. Dans ce domaine, le non-respect d’une échéance est considéré comme une défaillance pouvant avoir des conséquences potentiellement catastrophiques.
Plus vite, mais à temps…
Le comportement d’un système embarqué temps-réel est par définition lié à l’écoulement du temps physique. Par exemple, il doit réaliser des mesures de position à de intervalles de temps précis pour estimer une vitesse ou une accélération ou produire la commande d’un actionneur de freinage ou de direction pour éviter une collision. Parfois, la contrainte temporelle peut être plus subtile et relever de considération plus abstraites, comme la préservation de la relation de causalité. Dans tous les cas, maîtriser le temps ne signifie pas simplement « aller plus vite », mais garantir et démontrer que les actions se déroulent au « bon moment ».
En général, les systèmes temps-réel sont classifiés selon les conséquences d’une violation d’échéance sur le service. Pour un système temps réel dit « hard real-time », tout retard dans la délivrance du service constitue une défaillance, qui peut se révéler catastrophique selon le contexte (songez au dispositif de déclenchement d’un air-bag, à un système de freinage d’urgence de train ou au contrôle d’allumage d’un moteur automobile…). A l’inverse, dans un système « soft real-time », le non-respect d’une échéance entraîne un service dégradé, dont la valeur décroît continûment avec le retard.
Dans tous les cas, le temps est une préoccupation essentielle dans le développement d’un système temps réel. Il faut délivrer le service rapidement pour assurer la performance fonctionnelle du système (par exemple, la stabilité d’un asservissement, le déploiement à temps d’un air bag) et le fournir au moment prévu. Les deux objectifs sont liés mais distincts.
À première vue, respecter des échéances temporelles et aller le plus vite possible semblent des objectifs convergents. Il est ainsi courant d’associer le terme « temps-réel » à l’idée de « rapidité ». Or, être « temps-réel » signifie avant tout répondre à des contraintes temporelles fortes et strictes, quelle que soit la magnitude de ces échéances, qu’elles soient de l’ordre de la microseconde, de la seconde ou de la minute. Il faut en outre montrer voire démontrer qu’elles le sont bien dans toutes les situations opérationnelles.
En pratique, les concepteurs de puces électroniques sont confrontés à deux exigences techniquement contradictoires : il faut calculer vite, ce qui implique la mise en oeuvre de mécanismes matériels complexes et difficiles à maitriser, et il faut calculer à temps, ce qui – au contraire – signifie utiliser des mécanismes simples et prédictibles. En d’autres termes, calculer vite signifie accroître le parallélisme, accroitre la complexité des structures d’exécution et, finalement, augmenter la difficulté à montrer que l’on va tenir les échéances.
Pendant longtemps, une approche très conservatrice a été privilégiée : le parallélisme était limité au strict minimum et, lorsqu’il était introduit, le niveau de concurrence restait faible. Or cette position n’est plus tenable aujourd’hui pour deux raisons principales. Tout d’abord, les plateformes d’exécution « simples » se font rares. La tendance est clairement à intégrer de plus en plus de cœurs voire de logiques programmables sur une même puce (voir par ex. l’architecture du composant VERSAL de Xilinx dans la figure ci-après). Ensuite, la complexité croissante des applications, y compris critiques, augmente constamment de sorte qu’elles exigent sans cesse l’exploitation de nouvelles capacités de calcul. On peut penser aux systèmes d’aide à la conduite dans le secteur automobile, par exemple.
Pires-temps d’exécution et analyse d’interférences
Un système temps-réel est ainsi soumis à des contraintes temporelles strictes, telles que les temps de réponse, les débits, la fraîcheur des données. Garantir et prouver que ces contraintes sont bien respectées est un sujet complexe, mobilisant des expertises en informatique théorique et en ingénierie du matériel et du logiciel.
Au cours des quinze dernières années, cette complexité s’est accrue significativement avec l’émergence de plateformes de calcul intégrant diverses formes de parallélisme matériel : coeurs de traitement multiples et hybrides, accélérateurs matériels (unités SIMD, GPUs, accélérateurs IA), etc.
Les pratiques de développement, de vérification, de validation, et de certification (par ex. CAST 32 ou AMC 20-189 dans le domaine aéronautique) ont dû évoluer pour maintenir la capacité à garantir la satisfaction des contraintes temporelles.
Prenons en exemple le sujet de l’analyse des pires temps d’exécution (ou WCET pour Worst-Case Execution Times). Autrefois, des méthodes simples et empiriques, comme la technique du high water mark (consistant à mesurer le temps d’exécution maximal mesuré sur un jeu de tests), étaient largement utilisés. Aujourd’hui, on recourt à des approches bien plus sophistiquées, telles que l’approche d’interprétation abstraite ou la statistique des événements rares.
La conformité du temps de réponse d’un système ainsi que son délai doivent être garantis dès la conception et être vérifiés avec autant de rigueur que les résultats produits par le système. Lorsque le système est totalement ou partiellement implémenté dans un logiciel, démontrer ses « propriétés temps réel » revient à estimer les pires-temps d’exécution des composants logiciels (ou WCET pour Worst-Case Execution Times) réalisés. Le WCET représente ainsi la borne supérieure des temps d’exécution de la fonction observables en opération.
Sur des architectures matérielles simples où le temps d’exécution d’une instruction dépend uniquement de l’instruction elle-même et non de l’état du processeur au moment de l’exécution, l’estimation du WCET est conceptuellement simple. Il suffit de rechercher le chemin d’exécution dont la durée totale, calculée comme la somme des durées de chaque instruction, est maximale.
Cependant, cette tâche n’est pas facile à réaliser pour des logiciels complexes puisque tous les chemins d’exécution doivent être considérés. Heureusement cela peut être largement automatisé. La difficulté s’accroît davantage sur des architectures plus complexes où le temps d’exécution d’une instruction varie en fonction du contexte d’exécution. Cette dépendance entre le temps d’exécution et l’état du processeur provient de plusieurs sources, la plupart étant liées aux fonctionnalités introduites dans les processeurs afin d’améliorer les temps moyens d’exécution des logiciels. Parmi elles, on peut citer les mécanismes de prédiction de branchement, d’exécution spéculative ou encore les caches.
Avec tous les mécanismes de microarchitecture subtils et complexes implémentés dans les processeurs haut de gamme, l’estimation des WCET avec le niveau de confiance requis par les systèmes critiques devient un défi majeur. Mais les difficultés ne s’arrêtent pas là. Si l’on considère non plus une unité de traitement unique, ou cœur, mais des plateformes de traitement composées de plusieurs de ces unités, les problèmes se multiplient.
Chacune de ces unités peut exécuter un logiciel distinct sur des ressources matérielles privées (pipeline, mémoire, etc.) mais elles partagent généralement une partie des ressources matérielles. Ce partage engendre des phénomènes de contention et, plus largement, de dépendances de diverses natures, sources d’interférences temporelles.
Pourquoi la prise en compte de ces interférences est un défi majeur pour l’analyse temporelle ?
- L’identification des sources d’interférences : il est nécessaire de recenser toutes les manières possibles dont l’exécution d’un code sur un cœur peut affecter le temps d’exécution d’un autre code sur un autre cœur. Assurer l’exhaustivité de cette analyse est un défi en raison de la sophistication des architectures et, parfois, du manque de documentation.
- L’estimation des effets des interférences : une fois identifiées, il faut évaluer et borner les interférences en évitant des estimations trop pessimistes.
- La combinaison des résultats : les résultats de l’analyse WCET « en isolation » doivent être combinés à ceux de l’analyse d’interférences pour obtenir une estimation du WCET « en situation de contention ».
Une partie significative des travaux réalisés par l’équipe CSEC de l’IRT Saint Exupéry a porté et porte encore aujourd’hui sur l’analyse temporelles des systèmes afin de garantir, notamment, la tenue des échéances.
Au fil des ans et des projets, nous avons abordé de nombreuses dimensions du problème :
- Micro-architecturale, avec des travaux sur la mise en œuvre de microarchitectures facilitant les analyses temporelles (travaux sur l’architecture RiscV FlexPret développée par Berkeley), sur l’analyse d’interférences (travaux sur l’outil et l’approche PhyLog de l’ONERA), etc.
- Logicielle, avec des travaux sur l’analyse de pire-temps d’exécution (WCET pour Worst-Case Execution Times) selon des techniques d’interprétation abstraite (avec l’IRIT sur l’outil OTAWA) et empiriques (avec l’ONERA et RocqStat), travaux avec Asterios Technologies et Rapita System sur l’instrumentation du code, sur la mise en œuvre de langages synchrones (Lustre et ForeC, avec l’INRIA).
- Système avec des travaux sur la mise en œuvre du modèle synchrone d’Asterios à l’échelle d’un système distribué.
- Réseau, avec des travaux sur l’analyse et la configuration de réseaux de communication basés sur la technologie TSN (Time Sentitive Network).
In fine, tous ces travaux convergent vers un seul et unique but : permettre la réalisation de fonctions de plus en plus complexes en exploitant au mieux des capacités de traitement croissantes et assurant les propriétés temporelles requises pour nous nos systèmes.
Vous souhaitez aller plus loin
W.-T. Sun, E. Jenn, et H. Cassé, « Construisez votre propre analyseur statique WCET : le cas du processeur automobile AURIX TC275 », présenté lors du 10e Congrès Européen sur les Logiciels et Systèmes Temps Réel Embarqués (ERTS 2020), Toulouse, France, janvier 2020.
https://hal.science/hal-02507130v1/document
G. Brau, E. Jenn, E. Courty, K. Delmas, et F. Boniol, « Une méthode pour l’analyse des interférences utilisant le langage de modélisation PHYLOG », présenté lors du 12e Congrès Européen sur les Logiciels et Systèmes Temps Réel Embarqués (ERTS 2024), Toulouse, France, juin 2024.
https://hal.science/hal-04653727/document
Damien Chabrol, Jean Guyomarc’H, Fabien Siron, Guillaume Phavorin, Sam Thompson, et al., « Séparation des préoccupations fonctionnelles et des interférences temporelles pour une conformité efficace à la norme AMC 20-193 », présenté lors du Congrès Européen sur les Logiciels et Systèmes Temps Réel Embarqués (ERTS 2024), Toulouse, France, juin 2024.
https://hal.science/hal-04649192v1/file/ERTS24-paper%20final.pdf
Pour retrouver tous nos articles dédiés à ce sujet :
- Article 1 : « Vers des systèmes logiciels et matériels plus sûrs«
- Article 2 : « L’analyse temporelle des systèmes embarqués »
- Article 3 : « De la multitude à l’harmonie : programmation pour les nouvelles plateformes«