Application de l'analyse du temps d'exécution la plus défavorable à la conception des tâches Rtos

Dans le domaine des systèmes d'exploitation en temps réel (RTOS), la compréhension et l'application de l'analyse WCET ne sont pas seulement un exercice académique, mais une exigence fondamentale pour assurer la fiabilité, la sécurité et la prévisibilité du système. Le pire temps d'exécution des cas est généralement utilisé dans des systèmes en temps réel fiables, où la compréhension du comportement le plus mauvais des logiciels est importante pour la fiabilité ou le comportement fonctionnel correct.

Pour les développeurs travaillant sur des applications critiques pour la sécurité telles que les systèmes de contrôle automobile, avionique, dispositifs médicaux et l'automatisation industrielle, l'analyse WCET fournit la certitude mathématique nécessaire pour garantir que les tâches seront accomplies dans les délais impartis. Un système informatique qui contrôle le comportement d'un moteur dans un véhicule pourrait devoir répondre aux entrées dans un délai précis, et si le temps d'exécution du logiciel le plus défavorable peut être déterminé, le concepteur du système peut utiliser cette option avec d'autres techniques telles que l'analyse de la schedulité pour s'assurer que le système réagit assez rapidement.

Ce guide complet explore les principes, les méthodologies et les applications pratiques de l'analyse WCET dans la conception des tâches RTOS, fournissant aux ingénieurs de systèmes embarqués les connaissances nécessaires pour construire des systèmes robustes et prévisibles en temps réel.

Comprendre l'analyse du temps d'exécution des pires cas

L'analyse WCET représente une approche systématique pour déterminer le temps maximal absolu de fixation sur l'exécution d'un morceau de code dans toutes les conditions possibles. Contrairement aux temps d'exécution moyens ou typiques, WCET se concentre sur la durée maximale possible, compte tenu des scénarios les plus exigeants qui pourraient se produire pendant le fonctionnement du système.

L'importance fondamentale de la WCET

Le WCET dépend à la fois du flux du programme, comme les itérations de boucles et les appels de fonctions, et des facteurs matériels, tels que les caches et les pipelines. Cette double dépendance fait de l'analyse WCET une discipline complexe mais essentielle.

Contrôler la complexité du flux avec les branches conditionnelles et les boucles imbriquées
Caractéristiques de l'architecture matérielle telles que les pipelines d'instruction et la prévision des branches
Effets de hiérarchie de mémoire, y compris les succès et les ratés de cache
Gestion des interruptions et changement de contexte
La dispute de ressources dans des environnements multicore
Décisions relatives à la planification du système d'exploitation et préemption des tâches

Les estimations du WCET devraient être à la fois sûres (aucune sous-estimation n'est permise) et serrées (aussi peu que possible surestimations), ce qui crée une tension fondamentale dans l'analyse du WCET : les estimations doivent être suffisamment prudentes pour garantir la sécurité, mais suffisamment serrées pour être pratiquement utiles pour la conception du système et l'allocation des ressources.

WCET dans les systèmes critiques de sécurité

Bien que le WCET soit potentiellement applicable à de nombreux systèmes en temps réel, en pratique, l'assurance du WCET est principalement utilisée par des systèmes en temps réel qui sont liés à une fiabilité ou une sécurité élevée.

Le DO-178C établit un besoin d'analyse de la WCET, en la mettant en évidence dans le §6.3 (Examens et analyses de logiciels), le §6.3.4 (Examens et analyses de code source) et le §11.20 (Résumé des réalisations de logiciels). De même, les directives DO-178C pour l'aérospatiale et la norme ISO 26262 pour l'automobile exigent toutes deux des estimations de la WCET de votre application et de ses sous-programmes critiques comme preuve à l'appui de votre argument de certification.

L'industrie automobile a connu une croissance explosive de la complexité des logiciels, avec des véhicules modernes contenant des millions de lignes de code contrôlant tout, de la gestion des moteurs aux systèmes avancés d'assistance au conducteur.

Les fondements théoriques et les défis

Le problème de trouver WCET par analyse est équivalent au problème d'arrêt et n'est donc pas soluble dans le général, mais heureusement, pour le type de systèmes que les ingénieurs veulent généralement trouver WCET pour, le logiciel est généralement bien structuré, se terminera toujours et est analyzable.

La plupart des méthodes de recherche d'un WCET comportent des approximations (généralement un arrondi vers le haut en cas d'incertitudes) et donc, dans la pratique, le WCET exact lui-même est souvent considéré comme introuvable. Au lieu de cela, différentes techniques de recherche du WCET produisent des estimations pour le WCET. Ces estimations sont généralement pessimistes, ce qui signifie que l'estimation du WCET est connue pour être plus élevée que la véritable WCET (ce qui est habituellement ce qui est désiré).

Ce pessimisme inhérent sert de marge de sécurité, mais beaucoup de travail sur l'analyse WCET consiste à réduire le pessimisme en analyse de sorte que la valeur estimée soit suffisamment faible pour être utile au concepteur du système.

Méthodes d'analyse WCET

Au fil des décennies, les chercheurs et les praticiens ont élaboré plusieurs approches distinctes de l'analyse de l'ETCOC, chacune ayant ses propres forces, limites et cas d'utilisation appropriés.

Techniques d'analyse statique

Un outil d'analyse statique WCET tente d'estimer WCET en examinant le logiciel informatique sans l'exécuter directement sur le matériel. Les outils d'analyse statique fonctionnent à un niveau élevé pour déterminer la structure de la tâche d'un programme, travaillant soit sur un morceau de code source ou démonté exécutable binaire.

L'analyse statique de l'estimation WCET a été développée comme alternative à l'estimation basée sur la mesure. L'avantage principal de l'analyse statique est qu'il n'est pas nécessaire de prendre des mesures à partir d'une cible réelle, minimisant les coûts et l'effort.

L'estimation statique de l'analyse nécessite un modèle précis des caractéristiques de la synchronisation du processeur, qui comprend le comportement des pipelines, caches, mémoire, bus, et toute autre caractéristique du matériel examiné qui peut affecter le temps d'exécution des instructions de la machine.

Le processus d'analyse statique comporte généralement plusieurs éléments clés :

Analyse du flux de contrôle:[ Construire un graphique de flux de contrôle qui représente tous les chemins d'exécution possibles à travers le programme
Analyse de la valeur:[ Détermination des valeurs possibles de variables pour résoudre les branches et les limites de boucle dépendantes des données
Analyse du son des boucles:[ Détermination des nombres maximaux d'itération pour toutes les boucles du programme
Analyse de temps de faible niveau:[ Modélisation du comportement du pipeline du processeur, des effets de cache et des modèles d'accès à la mémoire
Analyse de la trajectoire:[ Identifier le chemin d'exécution le plus long à travers le programme en utilisant des techniques telles que la programmation linéaire entière

Cependant, l'analyse statique souffre de deux faiblesses clés : elle est pessimiste car elle identifie le WCET pathologique – le plus théoriquement possible.

Analyse basée sur la mesure

Depuis les premiers jours de l'informatique intégrée, les développeurs de logiciels intégrés ont soit utilisé: des mesures de bout en bout du code, par exemple effectué en réglant une broche d'entrée/sortie sur le périphérique à haut au début de la tâche, et à bas à la fin de la tâche et en utilisant un analyseur logique pour mesurer la plus longue largeur d'impulsion, ou en mesurant à l'intérieur du logiciel lui-même en utilisant l'horloge de processeur ou le compte d'instruction.

L'analyse WCET basée sur la mesure consiste à exécuter le programme sur le matériel cible réel avec différents scénarios d'entrée et à enregistrer les temps d'exécution observés. L'approche est pragmatique et reflète le comportement réel du matériel, mais elle est livré avec des limitations importantes.

L'analyse basée sur la mesure ne peut pas identifier facilement WCET car, en général, seul un sous-ensemble des exécutions est exercé, ce qui peut ne pas contenir le pire scénario. Pour diverses raisons, l'utilisation de l'analyse basée sur la mesure tend à être l'approche plus pratique, et donc l'approche utilisée pour de nombreux systèmes passés et présents. En raison du grand nombre de chemins possibles à travers le code, qui pourraient être pris, il y a toujours la crainte que vous ne manquiez un long délai d'exécution.

Par conséquent, dans la pratique, l'optimisme d'une approche fondée sur la mesure est réduit en ajoutant une « marge de sécurité », par exemple, en ajoutant 20 % au plus long délai d'exécution observé.

Approches d'analyse hybride

L'analyse hybride WCET combine les forces de deux méthodologies couramment utilisées. Les approches hybrides sont apparues comme un terrain intermédiaire puissant, essayant de tirer parti des avantages des techniques statiques et des techniques basées sur la mesure tout en atténuant leurs faiblesses respectives.

Les outils WCET hybrides visent à combiner les meilleures caractéristiques des outils WCET d'analyse statique et de mesure tout en évitant leurs pièges en utilisant des tests sur cible pour mesurer le temps d'exécution de courtes sous-voies entre les points de décision du code et en combinant les mesures et les informations de l'analyse de chemin pour calculer les temps d'exécution les plus défavorables de manière à saisir la variation de temps d'exécution sur les chemins individuels en raison des effets matériels.

L'analyse hybride vise à fournir une valeur entre le WCET trop pessimiste de l'analyse statique et les valeurs optimistes de la mesure pure. La méthodologie hybride comprend généralement:

Code d'instrumentation pour mesurer les temps d'exécution des blocs de base ou des petits segments de code
Exécuter le code instrumenté sur le matériel cible avec des entrées de test représentatives
Effectuer une analyse statique du débit de commande pour identifier tous les chemins d'exécution possibles
Combiner les données de chronométrage mesurées et les informations de trajectoire pour calculer les estimations globales du WCET
Comptabiliser les chemins non observés par extrapolation conservatrice

Les temps d'exécution sont déterminés à partir de mesures réelles, en abordant le premier problème avec les outils WCET statiques : aucune dépendance sur les modèles de processeur. Ceci est particulièrement précieux pour les processeurs modernes complexes où des modèles de chronométrage précis sont difficiles ou impossibles à créer.

Application de l'analyse WCET à la conception des tâches RTOS

L'intégration de l'analyse WCET dans la conception des tâches RTOS est l'endroit où la théorie rencontre la pratique. Comprendre comment appliquer efficacement les principes WCET peut signifier la différence entre un système fiable et certifié et celui qui subit des défaillances de temps imprévisibles dans le domaine.

Exigences fondamentales et calendrier de la RTOS

Une tâche est un morceau de code qui doit être exécuté dans un seul thread d'exécution. Une tâche délivre une séquence de tâches au processeur qui sont en attente et exécutées. Le temps passé par le travail activement en utilisant les ressources du processeur est son temps d'exécution.

Les exigences du système de haut niveau spécifieront les délais de réponse maximum pour une tâche, connue sous le nom de délai. Le pire temps d'exécution est le temps maximum nécessaire pour exécuter une tâche sur une plateforme matérielle spécifique. Dans la conception RTOS, le respect de ces délais n'est pas facultatif.

Dans la conception de certains systèmes, le WCET est souvent utilisé comme entrée dans l'analyse de l'échéancier, bien qu'il soit beaucoup plus courant d'utiliser le WCET dans les systèmes critiques pour s'assurer que les budgets de calendrier préaffectés dans un système de répartition comme ARINC 653 ne sont pas violés.

Calendrier des tâches et WCET

Les progrès récents dans le domaine de l'interprétation abstraite ont conduit à la mise au point d'outils d'analyse statique des programmes qui déterminent efficacement les limites supérieures du temps d'exécution des pires cas (TEMP) des extraits de code pour effectuer une analyse globale de la schedulité afin de garantir que toutes les contraintes de temps seront respectées.

La relation entre WCET et l'horaire est bidirectionnelle. Les valeurs WCET informent les décisions d'horaire, tandis que les politiques d'horaire affectent le temps d'exécution réel des tâches par des facteurs tels que :

Préemption en hauteur:[ La commutation de contexte ajoute du temps à l'exécution des tâches
Pollution de cache:[ La préemption peut causer des pannes de cache lorsqu'une tâche reprend
Inversion de priorité:[ Les tâches de priorité inférieure peuvent bloquer les tâches de priorité supérieure
Constatation de ressources:[ Plusieurs tâches se disputent des ressources partagées
Latence intermittente:[ Temps nécessaire pour répondre aux interruptions et les gérer

L'analyse WCET fait généralement référence au temps d'exécution d'un seul thread, tâche ou processus. Cependant, sur le matériel moderne, en particulier multi-core, d'autres tâches du système auront un impact sur le WCET d'une tâche donnée s'ils partagent le cache, les lignes de mémoire et d'autres fonctionnalités matérielles.

WCET Analyse des noyaux RTOS

Dans les systèmes complexes avec des systèmes d'exploitation en temps réel (RTOS), les propriétés de timing du système sont décidées par les applications et RTOS. Traditionnellement, l'analyse WCET traite principalement des programmes d'application, alors qu'il est crucial de savoir si RTOS se comporte également de manière prévisible en temps opportun.

Le noyau RTOS contribue lui-même au calendrier global du système par l'intermédiaire de divers services et opérations:

Création et suppression de tâches
Changement de contexte entre les tâches
Opérations de sémaphore et de mutex
Gestion de la file d'attente des messages
Services de minuterie
Manipulation interrompue
Répartition et distribution de la mémoire

Chacun de ces services du noyau a son propre WCET, qui doit être pris en compte lors de l'analyse des tâches de niveau application. Comprendre le comportement de timing des primitives RTOS est essentiel pour une analyse précise du timing au niveau du système.

Priorité des tâches et affectation des ressources

L'analyse de la WCET influe directement sur la façon dont les tâches sont classées par ordre de priorité et sur la façon dont les ressources du système sont allouées.

Attribuer des priorités appropriées aux tâches en fonction de leurs délais et délais d'exécution
Alloquer suffisamment de tranches de temps CPU dans des systèmes à répartition dans le temps
Déterminer les ensembles de tâches réalisables qui peuvent être programmés sans violation des délais
Optimiser l'utilisation des ressources tout en maintenant les garanties de calendrier
Recenser les goulets d'étranglement et les problèmes de performance potentiels au début de la phase de conception

Les algorithmes de planification de la date limite la plus précoce (EDF) et de l'analyse monotonique de taux (RMA) reposent tous deux sur les valeurs de WCET pour déterminer la schedulabilité.

Mise en oeuvre de l'analyse WCET dans la pratique

Pour passer de la compréhension théorique à la mise en oeuvre pratique, il faut une planification minutieuse, une sélection appropriée des outils et une méthodologie systématique.

Identification des tâches critiques à analyser

Toutes les tâches d'un RTOS ne nécessitent pas le même niveau d'analyse de la chronologie. La première étape de la mise en oeuvre pratique du WCET consiste à déterminer quelles tâches sont vraiment critiques et justifient une analyse détaillée.

Fonctions critiques de sécurité :[ Tâches dont l'échec pourrait causer des dommages aux personnes ou aux biens
Tâches à temps réel:[ Tâches avec délais non négociables lorsque toute violation constitue une défaillance du système
Tâches à haute fréquence: Tâches qui exécutent fréquemment et consomment des ressources importantes du CPU
Tâches sur le chemin critique: Tâches qui affectent directement le temps de réponse du système aux événements externes
Tâches avec des marges de timing serrées:[ Tâches où la différence entre WCET et la date limite est faible

Pour chaque tâche critique identifiée, documentez ses exigences en matière de calendrier, y compris la période, la date limite et toute dépendance à l'égard d'autres tâches ou ressources.

Sélection des outils d'analyse WCET

Le choix des outils d'analyse WCET dépend de plusieurs facteurs, dont le matériel cible, le langage de programmation, les exigences de certification et les contraintes budgétaires.

L'information requise pour l'estimation de la WCET, comme les cibles de branche calculées et les limites de boucle, est déterminée par l'analyse statique. L'outil AiT d'AbsInt est largement utilisé dans les industries aérospatiale et automobile pour l'analyse statique de la WCET.

L'outil unique d'analyse de synchronisation hybride de Rapita s'appelle RapiTime et est identifié par la FAA comme « un exemple d'outil mature » pour l'analyse dynamique de synchronisation. RapiTime représente l'approche d'analyse hybride et est particulièrement utile pour les plateformes matérielles complexes.

Parmi les autres outils notables, mentionnons :

Bound-T: Outil d'analyse statique WCET prenant en charge divers processeurs embarqués
Chronos: Outil d'analyse de WCET académique avec support pour plusieurs architectures
OTAWA: Cadre de référence pour l'analyse WCET
SymTA/S: Outil d'analyse et d'optimisation des chronométrages au niveau du système

Lors de l'évaluation des outils, il faut tenir compte de facteurs tels que les processeurs assistés, la précision de l'analyse, la facilité d'utilisation, l'intégration aux flux de travail de développement existants et la disponibilité de trousses de qualification aux fins de certification.

Préparation du code pour l'analyse WCET

La structure du code a une incidence importante sur la faisabilité et l'exactitude de l'analyse WCET.

Éviter les boucles non délimitées:[ Toutes les boucles doivent avoir des nombres d'itérations maximales déterminables statiquement
Minimiser le comportement dynamique : Réduire ou éliminer l'attribution dynamique de la mémoire, les pointeurs de fonction et la récursion
Simplifier le débit de contrôle: Les ramifications complexes et les conditions imbriquées augmentent la difficulté d'analyse
Fermetures de temps de documents:[ Fournit des annotations pour les limites de boucle et les contraintes de chemin d'exécution
Code de modulation: Découpez de grandes fonctions en unités plus petites et analyzables
Éviter les optimisations du compilateur qui obscurcissent le timing: Certaines optimisations rendent l'analyse du timing plus difficile

L'analyse WCET exige que les limites supérieures pour les numéros d'itération de toutes les boucles soient connues. aiT détermine le nombre d'itérations de boucles par analyse de boucles. Ceci est possible pour de nombreuses boucles se produisant dans des applications typiques.

Effectuer une analyse de WCET statique

Le flux de travail de l'analyse statique suit généralement ces étapes :

Étape 1: Construire et préparer l'exécutable[
Compiler le code avec les paramètres appropriés du compilateur, généralement en désactivant les optimisations agressives qui compliquent l'analyse de la chronologie.

Étape 2: Fournir des informations sur le flux
Annoter le code avec des faits de flux tels que les limites de boucle, les chemins invraisemblables et les fréquences d'exécution.

Étape 3: Configurer le modèle matériel
Définit le modèle de chronométrage pour le processeur cible, y compris la configuration du cache, les caractéristiques du pipeline et le chronométrage de la mémoire.

Étape 4: Analyse de l'exécution
Exécuter l'outil d'analyse de la WCET sur l'exécutable préparé. L'outil effectuera l'analyse de l'écoulement de contrôle, l'analyse du moment et l'analyse du chemin pour calculer les estimations de la WCET.

Étape 5: Examiner les résultats[
Examiner les résultats de l'analyse, y compris la valeur WCET calculée, le chemin critique à travers le code, et tout avertissement ou erreur. Vérifier que les résultats sont raisonnables et étudier toute constatation inattendue.

Étape 6: Iterate and Refine
D'après les résultats de l'analyse, raffiner la structure du code, ajouter des annotations manquantes ou ajuster les modèles matériels au besoin.

Réalisation d'une analyse fondée sur la mesure

Pour l'analyse de la TECO fondée sur la mesure, le processus diffère considérablement :

Étape 1: Code d'instrument
Ajouter des instruments pour saisir les informations de chronométrage pendant l'exécution.Cela peut impliquer l'insertion de lectures d'horodatage aux points clés du code ou l'utilisation de capacités de traçage matériel.

Étape 2: Développer des cas d'essai
Créer une suite complète de tests conçue pour exercer les chemins d'exécution les plus mauvais cas. Cela nécessite une compréhension approfondie du code et une considération attentive des combinaisons d'entrée qui conduisent à un temps d'exécution maximum.

Étape 3: Exécuter sur le matériel cible
Déployer le code instrumenté sur le matériel cible réel avec les cas de test développés. Recueillir des mesures de timing pour tous les chemins exécutés.

Étape 4: Analyser les mesures[
Processus des données de chronométrage recueillies pour identifier le plus long délai d'exécution observé.

Étape 5: Appliquer la marge de sécurité[
Ajouter une marge de sécurité appropriée au plus long délai observé pour tenir compte des scénarios les plus défavorables non observés. La marge devrait être justifiée en fonction de la couverture des essais et de la criticité du système.

Étape 6: Valider la couverture[
Vérifier que les cas de test ont permis une couverture adéquate des chemins d'exécution et des états matériels.

Mise en œuvre de l'analyse hybride

Les approches hybrides utilisent des tests en ligne pour mesurer le temps d'exécution des sous-chemins courts entre les points de décision du code, soutenir l'analyse hors ligne avec les informations obtenues lors des tests, comme le nombre d'itérations de boucles, et les fréquences d'exécution pour construire un modèle de structure de code globale et déterminer quelles combinaisons de sous-chemins forment des chemins complets et réalisables à travers le code, et les informations de mesure et d'analyse de chemin sont combinées pour calculer les temps d'exécution les plus défavorables.

Le flux de travail d'approche hybride combine des éléments d'analyse statique et d'analyse basée sur la mesure :

Code instrumental à granularité fine (blocs de base ou petits segments de code)
Exécuter le code instrumenté avec des entrées d'essai représentatives
Collecter des mesures de temps pour chaque segment de code
Effectuer une analyse statique du débit de commande pour identifier tous les chemins possibles
Combiner les temps de segment mesurés selon le débit de commande pour calculer les temps de parcours
Identifier le chemin le plus long possible dans le cadre du programme

Cette approche est particulièrement efficace pour le matériel complexe où la modélisation statique est difficile, mais les approches basées uniquement sur la mesure sont insuffisantes pour la certification de sécurité.

Sujets avancés dans l'analyse WCET

À mesure que les systèmes embarqués deviennent plus complexes, l'analyse WCET doit évoluer pour relever les nouveaux défis posés par les architectures matérielles modernes et les paradigmes logiciels.

Défis multicœurs et multiprocesseurs

Lors de l'analyse WCET sur des systèmes multicore, l'approche hybride est la seule méthode efficace pour générer des mesures de temps utiles. Cela dit, l'approche hybride conventionnelle de l'analyse monocore ne répond pas à elle seule à l'estimation WCET multicore, car elle ne tient pas compte des interférences dues à la dispute pour des ressources partagées et d'autres idiosyncrasies matérielles.

Les techniques d'estimation statiques des WCET ne peuvent pas tenir compte de toutes les sources d'interférence possibles; et même si elles le pouvaient, elles seraient extrêmement complexes et coûteuses à exécuter.

Les processeurs multicore introduisent plusieurs sources d'interférences temporelles :

Constatation de cache partagée: Plusieurs cœurs se disputent pour des niveaux de cache partagés
Concorde de bus mémoire: Accès simultanés à la mémoire de différents cœurs
Protocole de cohérence: Trafic de cohérence de cache entre les carottes
Arbitrage des ressources partagées:[ Accès aux périphériques partagés et aux E/S
Communication inter-cœur: Passage de message et synchronisation des frais généraux

Pour relever ces défis, il faut des techniques d'analyse spécialisées qui peuvent limiter l'interférence des tâches de cogestion, notamment le multiplexage temps-division des ressources partagées, le cloisonnement statique des ressources et les méthodes d'analyse WCET interférence-concept.

Complexité de l'analyse de cache

L'analyse de cache classe les accès à la mémoire principale. L'analyse de notre outil est basée sur des techniques qui traitent l'analyse des caches avec la stratégie de remplacement LRU (Least Recently Used).

Le comportement cache représente l'une des sources les plus importantes de variabilité de la synchronisation dans les processeurs modernes. Un coup de cache peut prendre quelques cycles, tandis qu'un manque de cache peut prendre des centaines de cycles.

Classer chaque accès à la mémoire comme toujours hit, toujours-miss, ou incertain
Modélisation des politiques de remplacement du cache (LRU, FIFO, pseudo-LRU, etc.)
Analyse des conflits de cache entre différents accès à la mémoire
Comptabilisation de la pollution de cache par interruption et préemption
Gestion des hiérarchies de cache multi-niveaux

Pour les systèmes critiques en matière de sécurité, des approches prudentes, comme le cloisonnement du cache ou le verrouillage du cache, peuvent être utilisées pour rendre le moment plus prévisible, même au prix de la performance moyenne du cas.

Effets de prévision des pipelines et des succursales

À l'analyse de faible niveau, l'analyse statique de la WCET est compliquée par la présence de caractéristiques architecturales qui améliorent la performance moyenne du processeur : caches d'instruction/données, pipelines de prévision de branche et d'instruction, par exemple. Il est possible, mais de plus en plus difficile, de déterminer des limites de WCET serrées si ces caractéristiques architecturales modernes sont prises en compte dans le modèle de chronométrage utilisé par l'analyse.

Les processeurs modernes utilisent des techniques sophistiquées pour améliorer la performance moyenne, mais ces caractéristiques compliquent l'analyse des temps :

Plateaux d'instruction:[ Instructions multiples à différents stades d'exécution simultanément
Prédiction de la branche:[ Exécution spéculative basée sur les résultats prévus de la branche
Exécution hors ordre:[ Instructions exécutées dans un ordre différent de celui de l'ordre du programme
Exécution spécifique:[ Exécuter des instructions avant de savoir s'il est nécessaire de les exécuter
Exécution supercalaire:[ Instructions multiples émises par cycle

L'analyse de ces caractéristiques nécessite des modèles de processeurs détaillés et des algorithmes d'analyse sophistiqués. Dans certains cas, la complexité devient si grande que des processeurs plus simples et plus prévisibles sont choisis pour des applications critiques en matière de sécurité.

Interruptions de manipulation et préemption

Dans les environnements RTOS, les tâches peuvent être interrompues par des tâches prioritaires ou des routines de service (RSR).

Préemption directe : Temps passé à économiser et à restaurer le contexte
Durée de la préemption liée à la cache (DCRP): Des caches manquants supplémentaires après la reprise en raison de la pollution du cache
Pipeline rinçage des frais généraux:[ Effacement du pipeline d'instructions pendant le changement de contexte
Pollution par les prédicteurs de la TLB et de la branche: Perte de la traduction état tampon et de la prévision de la branche

La prise en compte de la préemption dans l'analyse WCET exige de comprendre le nombre maximal de préemptions qui peuvent se produire pendant l'exécution des tâches et les frais généraux associés à chaque préemption.

Analyse probabiliste de la WCET

Pour les systèmes où les limites de WCET déterministes sont trop pessimistes ou impossibles à obtenir, l'analyse probabiliste de WCET (pWCET) offre une approche alternative.

Cette approche est particulièrement pertinente pour les systèmes dotés de caractéristiques matérielles randomisées ou qui traitent d'architectures extrêmement complexes. La distribution pWCET permet aux concepteurs de systèmes de prendre des décisions basées sur le risque concernant les marges de synchronisation et l'allocation des ressources.

Toutefois, les approches probabilistes exigent un examen attentif des probabilités de défaillance acceptables et peuvent être confrontées à des difficultés de certification pour les applications de sécurité les plus critiques.

Intégration avec les flux de travail de développement

Pour que l'analyse WCET soit vraiment efficace, elle doit être intégrée au cycle de vie global du développement logiciel plutôt qu'être considérée comme une activité ponctuelle à la fin du développement.

Intégration de la phase de conception précoce

Les considérations relatives aux WCET devraient influer sur les décisions relatives à l'architecture des systèmes dès les premières phases de conception :

Établir des budgets-cadres pour les principales fonctions du système pendant l ' analyse des besoins
Sélectionnez des plateformes matérielles avec une prévisibilité de temps à l'esprit
Architecture logicielle de conception pour faciliter l'analyse WCET
Attribuer des marges de temps pour chaque tâche en fonction des estimations préliminaires
Identifier les goulets d'étranglement éventuels avant une mise en œuvre détaillée

L'intégration précoce permet de régler les problèmes de calendrier lorsqu'ils sont les moins coûteux à résoudre, plutôt que de découvrir des problèmes en retard dans le développement lorsque les options sont limitées.

Intégration continue et analyse automatisée

Les pratiques modernes de développement mettent l'accent sur l'intégration continue et les tests automatisés. L'analyse WCET peut et devrait faire partie de ce flux de travail automatisé :

Intégrer les outils d'analyse WCET dans le système de construction
Lancer automatiquement l'analyse de la synchronisation sur chaque code commit ou construction nocturne
Suivre les tendances de la WCET au fil du temps pour détecter les régressions temporelles
Générer des alertes lorsque les estimations du WCET dépassent les budgets alloués
Tenir à jour une base de données des résultats de la WCET pour l'analyse historique

L'automatisation permet de s'assurer que l'analyse des délais demeure à jour à mesure que le code évolue et aide à attraper les problèmes de calendrier tôt avant qu'ils ne deviennent des problèmes critiques.

Documentation et traçabilité

Pour les systèmes critiques en matière de sécurité soumis à certification, une documentation complète de l'analyse WCET est essentielle:

Méthodologie et outils utilisés pour l'analyse des documents
Consigner toutes les hypothèses et annotations faites au cours de l'analyse
Maintenir la traçabilité entre les exigences, le code et les résultats de l'analyse de la date
Validation et vérification des estimations du WCET
Justification des marges de sécurité et des hypothèses prudentes

Cette documentation sert à plusieurs fins : appuyer les arguments en matière de certification, permettre la maintenance future et fournir la preuve d'une diligence raisonnable dans l'élaboration du système.

Validation et vérification des estimations du WCET

L'obtention d'une estimation du TECO n'est qu'une partie du défi, en ce sens que la validation de l'estimation est correcte et suffisante est tout aussi importante.

Stratégies d'essai et de simulation

La validation des estimations de l'ETCO implique généralement plusieurs approches complémentaires:

Essais de résistance:[ Exécuter le système dans des conditions de charge maximale pour observer le comportement de timing réel
Essais de fond:[ Essai avec valeurs d'entrée aux extrêmes des plages valides
Injection par défaut: Introduire des défauts pour vérifier le comportement du système dans des conditions d'erreur
Simulation de la ligne de conduite: Essai avec des stimuli externes réalistes et un timing
Analyse statistique:[ Analyser les mesures de temps pour vérifier qu'elles se situent dans les limites prévues

L'objectif est de gagner en confiance que les estimations du WCET sont à la fois sûres (pas sous-estimées) et raisonnablement serrées (pas trop pessimistes).

Comparaison des méthodes d'analyse

À l'avenir, il est probable que les systèmes critiques de sécurité doivent être analysés à l'aide d'approches statiques et de méthodes de mesure.

Lorsque différentes méthodes produisent des estimations de l'ETCOC sensiblement différentes, il est nécessaire de faire des recherches pour comprendre la source de l'écart, ce qui pourrait révéler :

Erreurs dans les modèles de chronométrage du matériel utilisés par l'analyse statique
Couverture insuffisante des essais dans l'analyse fondée sur la mesure
Hypothèses trop prudentes en analyse statique
Voies non observées dans les pires cas dans l ' analyse fondée sur la mesure

Surveillance et vérification des temps d'exécution

Pour les systèmes déployés, la surveillance des temps d'exécution peut fournir une vérification continue que les hypothèses de calendrier demeurent valides :

Mettre en place des moniteurs de temps qui permettent de suivre les temps d'exécution réels des tâches
Défauts de calendrier des registres pour la post-analyse
Utilisez des chronomètres de veille pour détecter les tâches qui dépassent le temps alloué
Collecte de statistiques sur le calendrier pour l'analyse des tendances à long terme
Mettre en œuvre des stratégies gracieuses de dégradation lorsque des violations de calendrier se produisent

La surveillance des temps d'exécution sert de filet de sécurité final, en captant les problèmes de temps qui ont échappé à l'analyse et aux essais.

Stratégies d'optimisation pour la réduction des TOC

Lorsque l'analyse WCET révèle que les tâches dépassent leurs budgets de temps, l'optimisation devient nécessaire. Cependant, l'optimisation pour les performances les plus défavorables diffère de l'optimisation pour les performances moyennes.

Optimisations du niveau de code

Plusieurs techniques de niveau de code peuvent réduire les WCET :

Déroulement de boucle:[ Réduisez les frais généraux de boucle en exécutant plusieurs itérations par cycle de boucle
Fonction en ligne :[ Éliminer les frais généraux d'appel de fonction pour les petites fonctions, souvent appelées
Réduction de la branchement:[ Minimiser les branches conditionnelles qui causent des décrochages de pipelines
Optimisation de la structure des données: Disposer les données pour améliorer la localisation du cache
Améliorations angrithmiques: Remplacer les algorithmes par une meilleure complexité dans le pire des cas

Lors de l'application des optimisations, il est crucial de re-exécuter l'analyse WCET pour vérifier que les changements améliorent réellement le timing du pire cas. Certaines optimisations qui améliorent la performance moyenne peuvent en fait aggraver le comportement du pire cas.

Considérations relatives à l'optimisation des compilateurs

Les optimisations de compilateur présentent une épée à double tranchant pour l'analyse WCET. Bien qu'elles puissent améliorer les performances, elles peuvent également rendre l'analyse de synchronisation plus difficile et introduire la variabilité de la synchronisation.

Pour les systèmes critiques en matière de sécurité, il convient d'examiner:

Utilisation de niveaux d'optimisation modérés qui équilibrent performance et analyzabilité
Désactivation des optimisations qui introduisent une variabilité significative du moment
Utilisation de compilateurs qualifiés avec un comportement d'optimisation documenté
Vérifier que les optimisations ne violent pas les hypothèses de temps

Optimisations du niveau du matériel

La configuration du matériel peut avoir un impact significatif sur WCET :

Cache verrouillable: Verrouillez le code critique et les données dans le cache pour éliminer les erreurs de cache
Mémoire de bloc-notes:[ Utiliser la mémoire explicitement gérée au lieu des caches
Disabling spéculative features: Éteignez la prévision de branche et l'exécution spéculative
Modèles d'accès à la mémoire:[ Disposer la mémoire pour minimiser les conflits d'accès
Choix du processeur:[ Choisissez des processeurs ayant des caractéristiques de synchronisation plus prévisibles

Ces approches au niveau du matériel commercial permettent de faire des affaires avec des résultats moyens pour améliorer la prévisibilité du calendrier et des limites plus strictes de l'ECM.

Études de cas et applications du monde réel

Comprendre comment l'analyse WCET est appliquée dans les systèmes du monde réel fournit des informations précieuses sur les défis pratiques et les solutions.

Contrôle du moteur automobile

Les unités de commande du moteur automobile moderne (ECU) doivent exécuter des algorithmes de commande complexes dans des délais très serrés.

Contrôle du temps d'injection de carburant (temps dur en temps réel, délais de sous-milisième)
Contrôle du calendrier d'allumage (temps dur en temps réel, délais de sous-milisième)
Acquisition et filtrage de données de capteurs (périodique, à l'échelle milliseconde)
Surveillance diagnostique (en temps réel, délais assouplis)

L'analyse WCET de ces systèmes doit tenir compte des entrées de capteurs à commande intermittente, des algorithmes de contrôle complexes et de la nécessité d'une certification selon la norme ISO 26262. Des méthodes d'analyse hybride sont souvent utilisées, combinant validation basée sur la mesure et analyse statique pour la certification.

Contrôle de vol avionique

Les systèmes de contrôle de vol des aéronefs représentent certaines des applications les plus exigeantes pour l'analyse de WCET. Ces systèmes doivent satisfaire aux exigences de certification DO-178C et fonctionner avec une fiabilité extrêmement élevée.

Les défis à relever sont les suivants :

Plusieurs canaux redondants nécessitant un chronométrage synchronisé
Algorithmes complexes de fusion de capteurs
Mécanismes de détection et de récupération des défaillances
Horaire divisé avec isolement temporel strict

Les outils d'analyse statiques WCET comme l'aiT sont couramment utilisés en avionique, fournissant les limites déterministes nécessaires à la certification. L'analyse doit tenir compte de tous les modes de défaillance possibles et de leurs implications temporelles.

Contrôle des matériels médicaux

Les appareils médicaux tels que les pompes à insuline, les stimulateurs cardiaques et les ventilateurs ont des exigences de temps critiques pour la vie.

L'analyse WCET des instruments médicaux doit tenir compte:

La sécurité des patients est la préoccupation primordiale
Exigences réglementaires (FDA, CEI 62304)
Fonctionnement alimenté par batterie avec contraintes énergétiques
Comportement sûr des défaillances dans toutes les conditions

L'analyse doit démontrer que toutes les fonctions critiques en matière de sécurité peuvent être remplies dans les délais, même dans les pires conditions, y compris les variations de tension de la batterie et les défaillances du capteur.

Tendances et orientations de la recherche

L'analyse WCET continue d'évoluer en réponse aux nouvelles architectures matérielles, aux paradigmes logiciels et aux exigences d'application.

L'apprentissage automatique et l'IA dans l'analyse WCET

Une extension de la méthodologie hybride est proposée, qui met en œuvre un modèle de prévision utilisant le Machine Learning (ML).Cette nouvelle approche évalue le WCET sur les petites entités du code, les blocs hybrides, en fonction des fonctionnalités logicielles et matérielles.

Les approches d'apprentissage automatique sont prometteuses pour améliorer la précision de l'estimation de la TOC et réduire l'effort d'analyse.

Cependant, l'application du ML aux systèmes critiques en matière de sécurité soulève des questions sur l'explication, la certification et la confiance dans les prévisions.

Architectures prédictibles pour le calendrier

Au lieu d'analyser le matériel imprévisible complexe, une autre approche consiste à concevoir du matériel spécialement pour la prévisibilité du moment.

Politiques de remplacement du cache prévisible
Ressources partagées multidimensionnées
Comportement des pipelines encombrés
Élimination de l'exécution spéculative

Des projets comme l'architecture PRET (Precision Timed) et le processeur T-CREST démontrent cette approche. Bien que ces processeurs puissent sacrifier la performance moyenne des cas, ils offrent des limites WCET beaucoup plus serrées et une analyse plus simple.

Analyse du calendrier de composition

À mesure que les systèmes deviennent plus grands et plus complexes, les analyser de façon monolithique devient peu pratique. L'analyse de la composition du temps brise le système en composants, analyse chaque composant indépendamment, puis compose les résultats.

Cette approche permet:

Réutilisation des résultats de l'analyse chronologique dans les projets
Développement indépendant et certification des composants
Scalabilité aux systèmes très grands
Analyse différentielle lorsque les composantes changent

Les recherches se poursuivent sur l'élaboration de cadres d'analyse de composition solides qui fournissent des garanties de calendrier au niveau du système à partir des analyses au niveau des composantes.

Meilleures pratiques et recommandations

Sur la base de décennies de recherche et d'expérience industrielle, plusieurs pratiques exemplaires ont été mises en place pour une analyse efficace de la TOC dans le cadre du développement de la RTOS.

Conception pour l'analyse

La façon la plus efficace d'atteindre des limites WCET serrées est de concevoir des logiciels avec une analyzabilité en tête dès le début:

Utiliser un flux de commande simple et structuré
Éviter ou minimiser le comportement dynamique
Documenter les décisions de conception pertinentes en fonction du moment
Choisir des algorithmes avec une bonne complexité dans le pire des cas
Conception pour l'essai et l'observation

Le code difficile à analyser a souvent de mauvaises caractéristiques de chronométrage dans le pire des cas. La conception de l'analyzabilité améliore généralement les deux.

Maintenir les budgets de calendrier

Établir et maintenir des budgets de calendrier tout au long du développement :

Attribuer les budgets de calendrier aux principaux systèmes
Suivre les résultats réels du WCET par rapport aux budgets en continu
Escalat lorsque les budgets risquent d'être dépassés
Marge de réserve pour les modifications en retard et les corrections de bugs
Examiner et mettre à jour les budgets au fur et à mesure que les besoins évoluent

Le calendrier des budgets permet d'alerter rapidement les problèmes et de prévenir les crises de dernière minute.

Investir dans la formation et l'expertise

L'analyse de la TECO exige des connaissances et des compétences spécialisées.

Former les développeurs à des principes de programmation en temps réel
Développer l'expertise interne en matière d'outils et de méthodes d'analyse des délais
Participation à des experts en analyse chronologique pour des projets complexes
Participer à la recherche et à l'élaboration de normes
Partager les connaissances et les enseignements tirés des projets

L'investissement dans l'expertise est bénéfique grâce à un développement plus efficace et à des systèmes de meilleure qualité.

Équilibre Sécurité et praticabilité

Bien que la sécurité soit primordiale, une analyse trop prudente du moment peut conduire à des systèmes surapprovisionnés et coûteux.

Utiliser des méthodes d'analyse appropriées pour le niveau de criticité
Appliquer une analyse plus rigoureuse aux fonctions les plus critiques
Accepter des marges raisonnables plutôt que des limites absolues dans le pire des cas
Considérer des approches probabilistes où les limites déterministes sont peu pratiques
Utiliser la défense en profondeur avec plusieurs couches de protection de temps

L'objectif est de mettre en place des systèmes sûrs et économiquement viables.

Conclusion

L'analyse des délais d'exécution des pires cas représente une discipline critique dans le développement de systèmes d'exploitation en temps réel et d'applications intégrées critiques pour la sécurité.

Si l'on veut appliquer avec succès l'analyse WCET à la conception des tâches RTOS, il faut comprendre les fondements théoriques, choisir les méthodes d'analyse appropriées, utiliser des outils appropriés et intégrer l'analyse des moments tout au long du cycle de vie du développement.

Pour les organisations qui développent des systèmes en temps réel, investir dans des capacités d'analyse WCET n'est pas facultatif.Il est essentiel de fournir des systèmes fiables et certifiés qui répondent à leurs exigences de temps dans toutes les conditions.

Le domaine continue d'évoluer avec de nouvelles techniques d'analyse, des outils plus sophistiqués et du matériel conçu pour la prévisibilité du moment. Rester à jour avec ces développements et les appliquer de façon appropriée permettra la prochaine génération de systèmes sûrs et fiables en temps réel.

Ressources supplémentaires

Pour ceux qui cherchent à approfondir leur compréhension de l'analyse WCET et de son application au développement RTOS, de nombreuses ressources sont disponibles:

Recherche académique:[ L'Atelier international sur l'analyse du temps d'exécution des pires cas (atelier de la CET) publie chaque année des recherches de pointe
Normes industrielles:[ DO-178C pour l'avionique et ISO 26262 pour l'automobile fournissent des indications sur les exigences en matière d'analyse du moment
Tool Vendeurs: Des entreprises comme AbsInt, Rapita Systems et LDRA offrent une documentation et une formation complètes pour leurs outils d'analyse WCET
Communautés en ligne: Les forums et les listes de diffusion consacrées aux systèmes en temps réel offrent l'occasion d'apprendre des praticiens
Organisations professionnelles:[ Les groupes d'intérêt spéciaux de l'IEEE et de l'ACM se concentrent sur les systèmes en temps réel et l'informatique intégrée

Pour plus d'information sur le développement de systèmes en temps réel et l'ingénierie de logiciels embarqués, visitez la communauté Des systèmes embarqués.Vous trouverez d'autres renseignements sur le développement de logiciels critiques en matière de sécurité au Safety Critical Systems Club. Le ARTIST Network of Excellence fournit des ressources considérables sur la conception et l'analyse de systèmes embarqués.

En combinant les connaissances théoriques et l'expérience pratique et en tirant parti de l'écosystème croissant d'outils et de ressources, les développeurs peuvent maîtriser l'analyse WCET et l'appliquer efficacement pour créer des systèmes robustes et fiables en temps réel qui répondent aux exigences exigeantes des applications critiques pour la sécurité d'aujourd'hui.