← Back to My Courses 2023-2024

🔗 Cours connexes:

Temps Réel

PART A: GENERALITIES

Presentation

Le cours “Temps Réel” traite des systèmes informatiques devant réagir à des événements externes dans des contraintes temporelles strictes. Un système temps réel ne doit pas seulement produire des résultats corrects, mais aussi les produire à temps. Ces systèmes sont omniprésents: avionique, automobile, robotique, contrôle industriel, télécommunications. Le cours couvre l’ordonnancement de tâches, les systèmes d’exploitation temps réel (RTOS), et les techniques de conception garantissant le respect des échéances.

Année Académique: 2023-2024
Semestre: 8
Catégorie: Informatique / Systèmes Embarqués

PART B: DESCRIPTIVE PART

Experience Details

Environment and Context

Le cours combinait théorie de l’ordonnancement avec implémentation pratique sur microcontrôleurs et RTOS (FreeRTOS, RTOS embarqués). Nous avons programmé des systèmes multitâches avec contraintes temporelles, analysé leur ordonnançabilité, et mesuré les performances réelles. Les projets incluaient des applications concrètes: acquisition de données périodique, contrôle moteur, communication temps réel.

My Function

Dans ce cours, j’ai été responsable de:

PART C: TECHNICAL PART

Cette section explore les aspects techniques des systèmes temps réel.

Technical Concepts Learned

1. Définitions et Classifications

Système Temps Réel: Système dont la correction dépend non seulement du résultat logique mais aussi du moment où il est produit.

Classification:

Temps Réel Dur (Hard Real-Time): Échéance manquée = catastrophe (crash, perte, danger). Exemples: airbag, pilote automatique d’avion, pacemaker.

Temps Réel Mou (Soft Real-Time): Échéance manquée = dégradation de qualité (acceptable occasionnellement). Exemples: streaming vidéo, jeux vidéo, interface utilisateur.

Temps Réel Ferme (Firm Real-Time): Échéance manquée = résultat inutile mais pas dangereux. Exemples: certains capteurs (échantillon perdu acceptable).

2. Modèle de Tâches Périodiques

Tâche τᵢ caractérisée par:

Tâches périodiques: Activées à t=0, Tᵢ, 2Tᵢ, 3Tᵢ, …

Contrainte: Terminer avant échéance: tᵢ + Dᵢ (souvent Dᵢ = Tᵢ)

Facteur d’utilisation:

U = Σ Cᵢ/Tᵢ

Proportion du processeur utilisée.

Condition nécessaire d’ordonnançabilité:

U ≤ 1

Si U > 1, impossible de respecter toutes les échéances.

3. Ordonnancement à Priorités Fixes

Rate Monotonic (RM): Priorité inversement proportionnelle à la période. Période courte → priorité haute.

Test d’ordonnançabilité (Liu & Layland):

Si U ≤ n(2^(1/n) - 1) alors ordonnançable par RM

Pour n→∞: U ≤ ln(2) ≈ 0.69

Condition suffisante (pas nécessaire).

Test exact (analyse du temps de réponse): Pour chaque tâche τᵢ, calculer temps de réponse Rᵢ:

Rᵢ = Cᵢ + Σⱼ₍ₚᵣᵢₒ>ₚᵣᵢₒᵢ₎ ⌈Rᵢ/Tⱼ⌉ × Cⱼ

Résolution itérative.

Ordonnançable si Rᵢ ≤ Dᵢ pour tout i.

Deadline Monotonic (DM): Si Dᵢ ≠ Tᵢ, priorité selon échéance. Échéance courte → priorité haute.

Optimal pour priorités fixes avec Dᵢ ≤ Tᵢ.

4. Ordonnancement à Priorités Dynamiques

Earliest Deadline First (EDF): À chaque instant, exécuter tâche avec échéance absolue la plus proche.

Optimalité: EDF est optimal pour monoprocesseur. Si un algorithme peut ordonnancer un système, EDF le peut.

Test d’ordonnançabilité:

U ≤ 1

Condition nécessaire ET suffisante pour EDF avec Dᵢ = Tᵢ.

Avantages:

Inconvénients:

5. Tâches Apériodiques et Sporadiques

Tâches apériodiques: Activations irrégulières, souvent sans échéance stricte.

Tâches sporadiques: Activations irrégulières avec intervalle minimum et échéance.

Serveurs: Mécanismes pour intégrer tâches apériodiques dans système périodique.

Polling Server: Tâche périodique réservée pour apériodiques.

Deferrable Server: Capacité préservée si pas utilisée.

Sporadic Server: Compromis performance/simplicité.

6. Synchronisation et Ressources Partagées

Problème: Tâches partagent ressources (variables, périphériques). Accès concurrent → corruption données.

Section critique: Portion de code accédant ressource partagée.

Mécanismes:

Mutex (Mutual Exclusion): Lock/Unlock pour protéger section critique.

Sémaphore: Compteur contrôlant accès.

Inversion de priorité: Tâche haute priorité bloquée par tâche basse priorité.

Exemple classique (Mars Pathfinder): Tâche priorité haute bloquée indéfiniment → reset système.

Solutions:

Priority Inheritance Protocol (PIP): Tâche tenant ressource hérite temporairement priorité de tâche bloquée la plus haute.

Priority Ceiling Protocol (PCP): Ressource a priorité plafond = max des priorités des tâches l’utilisant. Tâche accédant à ressource acquiert temporairement cette priorité.

Évite inversions de priorité multiples et interblocages.

7. Interblocages (Deadlocks)

Conditions de Coffman (4 nécessaires):

  1. Exclusion mutuelle: ressources non partageables
  2. Hold and wait: tâche tient ressources et en attend d’autres
  3. Pas de préemption: ressources non préemptibles
  4. Attente circulaire: cycle dans graphe d’allocation

Prévention: Casser une des 4 conditions.

Exemple: ordre total d’acquisition des ressources (évite cycles).

Détection et récupération: Détecter cycles, puis tuer/redémarrer tâches. Coûteux en temps réel.

Évitement (algorithme du banquier): N’allouer que si état sûr garanti. Overhead élevé, peu utilisé en temps réel.

8. Systèmes d’Exploitation Temps Réel (RTOS)

Caractéristiques:

RTOS populaires:

FreeRTOS:

VxWorks:

QNX:

RT-Linux / Xenomai:

Zephyr:

9. API FreeRTOS (Exemples)

Création de tâche:

xTaskCreate(
    vTaskFunction,      // Pointeur fonction
    "TaskName",         // Nom (debug)
    STACK_SIZE,         // Taille stack
    NULL,               // Paramètres
    PRIORITY,           // Priorité
    &xTaskHandle        // Handle (optionnel)
);

Mutex:

xMutex = xSemaphoreCreateMutex();

xSemaphoreTake(xMutex, portMAX_DELAY);  // Lock
// Section critique
xSemaphoreGive(xMutex);  // Unlock

Sémaphore binaire (signalisation):

xSemaphore = xSemaphoreCreateBinary();

// ISR:
xSemaphoreGiveFromISR(xSemaphore, NULL);

// Tâche:
xSemaphoreTake(xSemaphore, portMAX_DELAY);  // Attend signal

Queues (files FIFO):

xQueue = xQueueCreate(QUEUE_LENGTH, sizeof(DataType));

xQueueSend(xQueue, &data, TIMEOUT);
xQueueReceive(xQueue, &buffer, TIMEOUT);

Délais:

vTaskDelay(pdMS_TO_TICKS(100));  // Délai 100ms

10. Mesure et Validation

WCET (Worst-Case Execution Time): Temps d’exécution maximum.

Méthodes de détermination:

Difficile à déterminer précisément (caches, pipelines, branchements).

Marges de sécurité: Utiliser WCET majoré pour robustesse.

Outils de mesure:

Validation:

11. Conception de Systèmes Temps Réel

Méthodologie:

1. Spécification:

2. Modélisation:

3. Analyse d’ordonnançabilité:

4. Implémentation:

5. Validation:

6. Optimisation:

Patterns de conception:

12. Défis et Bonnes Pratiques

Défis:

Jitter: Variation du délai (problématique pour contrôle, audio). Minimiser par ordonnancement approprié.

Overhead: Changements de contexte, gestion RTOS. Peut être significatif (10-20%).

Multiprocesseur: Ordonnancement plus complexe. Partitionnement de tâches ou migration.

Interruptions: Peuvent perturber ordonnancement. Limiter durée ISR (Interrupt Service Routine).

Bonnes pratiques:

ISR courtes: Minimiser traitement en interruption. Utiliser sémaphore pour débloquer tâche (traitement différé).

Sections critiques courtes: Minimiser temps mutex tenu.

Éviter opérations bloquantes: Pas d’I/O bloquants, pas de malloc (temps variable).

Utiliser ressources déterministes: Allocation statique mémoire, buffers circulaires.

Dimensionnement conservateur: Marges sur WCET, utilisation processeur.

Tests exhaustifs: Valider tous scénarios, conditions limites.

PART D: ANALYTICAL PART

Knowledge and Skills Mobilized

Self Evaluation

Ce cours a été exigeant mais passionnant. Les systèmes temps réel introduisent une dimension (le temps) qui change radicalement la conception par rapport à la programmation classique.

La théorie de l’ordonnancement est mathématiquement rigoureuse. Les tests d’ordonnançabilité (RM, EDF) fournissent des garanties formelles, ce qui est rassurant pour systèmes critiques. Cependant, déterminer le WCET précisément reste un défi.

Le fossé entre RM (simple, utilisé en pratique) et EDF (optimal mais complexe) est intéressant. Le choix dépend du contexte: critique (RM pour prédictibilité) ou haute performance (EDF pour utilisation maximale).

La programmation avec RTOS a été révélatrice. Gérer tâches concurrentes, synchronisation, priorités demande rigueur. Les bugs sont souvent subtils (race conditions, deadlocks) et difficiles à reproduire.

L’inversion de priorité et ses solutions (PIP, PCP) montrent l’importance de comprendre les mécanismes profonds. Un simple mutex mal utilisé peut causer blocages catastrophiques (cf. Mars Pathfinder).

Les mesures temporelles m’ont confronté à la réalité: le WCET théorique et mesuré peuvent différer. Les facteurs matériels (caches, interruptions) compliquent les prédictions.

La conception d’un système temps réel nécessite approche méthodique: spécification claire, analyse formelle, tests exhaustifs. L’improvisation est dangereuse.

My Opinion

Ce cours est indispensable pour ingénieurs en systèmes embarqués, automatique, ou développant applications critiques.

Points forts:

Points à améliorer:

Réflexions personnelles:

Le temps réel n’est pas “faire vite” mais “faire à temps”. Un système rapide en moyenne mais avec variation importante peut être pire qu’un système plus lent mais déterministe.

La garantie d’échéance est plus importante que la performance moyenne. C’est un changement de mentalité par rapport au développement logiciel classique (où on optimise le cas moyen).

Les systèmes temps réel sont omniprésents mais invisibles: ABS dans voitures, pilotes automatiques, contrôleurs industriels, pacemakers. Leur fiabilité est critique car des vies en dépendent.

La certification (aérospatial, médical, automobile) impose processus rigoureux et traçabilité. Le code doit être prouvé correct, pas juste testé. Les méthodes formelles deviennent essentielles.

La complexité croît avec:

Applications professionnelles:

Compétences temps réel applicables dans:

Le marché des systèmes embarqués et temps réel est énorme et croissant (IoT, voitures connectées, Industry 4.0).

L’avenir:

Les compétences en temps réel resteront critiques. Même avec processeurs plus rapides, les applications deviennent plus complexes et exigeantes.

En conclusion, ce cours sur les systèmes temps réel fournit les bases essentielles pour concevoir des systèmes embarqués fiables respectant des contraintes temporelles strictes. C’est un domaine exigeant, combinant théorie (ordonnancement) et pratique (RTOS, Xenomai), crucial dans de nombreux secteurs industriels.

📚 Documents de Cours

📖 Polycopié Xenomai

Guide complet sur Xenomai : installation, APIs temps réel, tâches périodiques, synchronisation et débogage.

📥 Télécharger