Introduction aux Systèmes d’information Temps Réel Notion de temps réel dans les systèmes d’exploitation, et principes de mise en œuvre des systèmes d’exploitations temps réel… Par Gilles Grimaud Université des Sciences et Technologies de Lille http://www.lifl.fr/~grimaud/Cours

Plan Du temps réel … Par rapport à quoi ? Notion de temps réel dur vs temps réel mou Mise en œuvre d’un temps réel mou Les clefs d’un système temps réel dur Maîtrise du temps d’exécution au pire cas Ordonnancement temps réel Linux et le Temps Réel Conclusion

Notion de temps réel … Par rapport à quoi ? Objet : Maîtrise du temps de réponse d’un système d’information, afin de respecter des délais. Exemples : Un jeu d’échec, un pilote automatique d’avion, un système de contrôle des processus d’une usine, … Problèmes : Le temps d’exécution d’un programme n’est pas calculable dans le cas général Le temps de traitement est très intimement lié au matériel, ainsi qu’au temps d’exécution des primitives du système Abstraction et Virtualisation du microprocesseur font fluctuer le temps d’exécution d’un programme Stratégies des solutions : Faire au mieux en fct des circonstances : temps réel mou Maîtriser les temps de réponse : temps réel dur

Notion de temps réel dur vs temps réel mou Un système d’information temps réel doit retourner des réponses en respectant certaines échéances. Un jeu d’échec doit proposer une réponse en un temps fini… Un pilote automatique aussi… 1. Temps réel mou (Soft Real Time) : Les applications temps réel mou ont des contraintes d’échéances, mais elles peuvent « tolérer » des « fluctuations » dans la puissance de calcul qui leur est accordé. L’idéal est l’utilisation d’algorithmes incrémentaux : plus ils ont de temps de calcul, plus ils affinent leurs résultats à échéance (e.g. le jeu d’échec). 2. Temps réel dur (Hard Real Time) : Les applications temps réel dur doivent retourner des réponses pour une échéance fixée à l’avance. Pour cela elles doivent disposer d’une certaine puissance de calcul qui ne doit pas pouvoir être remise en cause. Fournir des outils pour apporter la garantie qu’un traitement aura eu la puissance de calcul suffisante.

Mise en œuvre du temps réel mou Points de départ : Le système dispose d’une puissance de calcul fixe, et d’une liste d’applications avec des échéances et un résultat partiel en cours de construction. Activité du système : Elire une application  accorder du temps de calcul et faire progresser la qualité du résultat qu’elle produit avant son échéance. Politique d’ordonnancement en fonction : des échéances et de la qualité des résultats déjà obtenus. Variation : Les applications peuvent définir une qualité de résultat espérée et une qualité de résultat minimale (service minimum)…

Mise en œuvre du temps réel mou Traitements coopératifs : Appli.1 Appli.2 Appli.3 main() main() main() curRes() curRes() curRes() deadLine deadLine deadLine sat() sat() sat() Ordonnanceur Temps Réel Moue Échantillonnage initial deadline1 deadline2 deadline3

Les clefs d’un système temps réel dur Quatre points critiques pour maîtriser le temps dans une application temps réel dur : Connaître le temps d’exécution des primitives fournies par le système d’exploitation Disposer d’un outil de calcul du temps d’exécution d’un programme Paramétrer le système avec les exigences de l’application temps réel, et obtenir satisfaction Bénéficier d’une stratégie d’ordonnancement idoine

Le temps d’exécution des primitives Eléments clefs pour déterminer le temps d’exécution d’un programme. Difficultés : Primitives en temps d’exécution incertain. E.g. gestionnaire de mémoire virtuelle, systèmes de cache matériel, allocateur de mémoire de bloc, … Calcul du temps d’exécution des primitives « au pire cas » Résultat très pessimiste Proposer des formes simplifiées des primitives du système avec de meilleurs temps de réponse au pire cas. Conclusion : Système temps réel  Système hautes performances.

Calculer le temps d’exécution d’un programme Le calcul du temps d’exécution d’un programme au pire cas (noté WCET) est un raffinement du problème de la terminaison d’un programme. Or ce problème est connu indécidable dans le cas général (cf. Turing). En effet, on ne peut pas toujours prouver la terminaison d’une itération. Pour pouvoir faire ce calcul indécidable il faut : Connaître le temps d’exécution des instructions élémentaires (cf. transparent précédent). Borner les itérations au pire cas : Utiliser des prouveurs de code (trouver les invariants de boucle) Contraindre le langage de programmation Exécuter une interprétation abstraite du code pour extraire de l’information contextuelle du programme.

Calculer le temps d’exécution d’un programme De manière plus pragmatique on comprend que : 1. Le calcul de WCET pour une séquence de n instructions in est  C(in) ,avec C(i) le coup de l’exécution de i 2. Le calcul de WCET d’un si/sinon dépend du coût de chaque branche Csi, Csinon et du résultat de la condition, au pire cas on a : Max(Csi,Csinon) 3. Pour pouvoir calculer le WCET d’un tantque il faut connaître le WCET du corps de la boucle Cboucle, et le multiplier par une borne supérieure constante n du nombre d’itérations (pas de programmes avec des itérations non bornées). On a : n x Cboucle 4. Le WCET d’un appel dépend de la nature de l’appel : pour un appel de procédure il est fct du WCET de la procédure appelée pour un appel de méthode, il est égal au maximum des WCET de chaque surcharge de la méthode appelée pour un appel distant, il est fonction de la QoS du réseau,…

Configuration d’un système RT Trois types de configurations : Procédures à exécuter sans délais en réaction à un événement matériel donné. i.e. Routine d’interruption gérée par le système temps réel, mais retransmise à l’application. Tâche dont la terminaison doit avoir lieu avant une certaine date mais après qu’il lui ait été accordée une certaine puissance de calcul. Activité périodique qui garanti une certaine quantité de calcul à une application RT. Tâche donc la réélection périodique est définie par l’application (définit la puissance de calcul accordé à la tâche RT « de fond »). Dans l’absolu un système temps réel devrait pouvoir « contrôler » que les demandes d’une application sont « compatibles » avec les autres applications présentes dans le système.

Stratégie d’ordonnancement RT Gestion des échéances : 1. Au plus pressé (Earliest Deadline First) : Principe : Élire la tâche active dont la deadline est la plus proche. Pour se convaincre que ça marche : Si cela ne marche pas, ce n’est pas en donnant la main à une autre tâche que la deadline aurait été mieux respectée. Périodique à tôt fixe (Rate monotonic) : Principe : équivalent à l’algorithme du tourniquet, mais en définissant une quantité minimale de temps CPU obtenu périodiquement. Objet : garantir une puissance de calcul constante aux tâches RT. Autres. Beaucoup de variations autour de ces deux stratégies…

Ordonnancement temps réel et contrôle des ressources L’introduction de mécanismes de contrôle de concurrence impacte fortement les systèmes d’informations temps réels. L’apparition de verrous dans des tâches temps réel (dur) impacte plusieurs mécanismes : Le mécanisme de calcul du temps d’exécution d’une procédure : pendant combien de temps l’application sera suspendue ? Le mécanisme d’ordonnancement des tâches : qui doit être élu si une tâche RT est bloquée ? (utilisation du mécanisme d’inversion de priorité ?)

Ordonnancement temps réel et contrôle des ressources Tâche 2 Fin de Tâche 2 Deadline T1 (13 unités de temps) Zone correcte Zone avec deadlock à venir Deadline T2 (dans 8 unités de temps) Dépassement de ressource Impossible Chemin RT possible Tâche 1 Fin de Tâche 1

Handlers d’interruptions matérielles RT et Linux Deux systèmes Linux revendiquent l’appellation RT : RTLinux et RTIA (dérivé de RTLinux) Proposent principalement les interfaces POSIX 1003.13 PSE 51. Se focalisent (pour l’instant) sur les points 1 et 3 de la construction des systèmes temps réels dur. Architecture retenue : Système Temps Réel Système Linux Thread temps réel Thread temps réel Handler temps réel Handler temps réel Handler Linux Appli Linux Appli Linux Thread Linux Handlers d’interruptions matérielles Noyau « temps réel »

Conclusion Eviter les confusions entre : Système RT et Système haute performance Système RT et Système embarqué Système RT et Gestionnaire de pilotes matériels Système RT et QoS Système RT et Micro-noyau Système RT et Exo-noyau Procédures RT et Untrusted Determist Fonctions