Exemples Concrets de Systèmes Temps Réel

TL;DR

Les systèmes temps réel sont conçus pour garantir des réponses dans des délais stricts, essentiels pour la sécurité et la fonctionnalité. Ils sont partout, des voitures aux usines, et leurs contraintes de temps déterminent leur architecture. Comprendre leurs applications aide à saisir l'importance de la programmation et de l'électronique dédiées.

1. The Mental Model

Imaginez un système qui ne peut pas se permettre de "réfléchir" trop longtemps. Chaque action doit se produire à un moment précis, sans retard imprévu. C'est comme un chef d'orchestre qui doit s'assurer que chaque musicien joue sa note au bon moment, sinon l'harmonie est brisée.

2. The Core Material

Un système temps réel (STR) est un système informatique qui doit répondre à des événements ou des entrées dans des délais prescrits et prévisibles. Ces délais sont souvent très courts, de l'ordre de la milliseconde, voire de la microseconde. L'échec à respecter ces délais est considéré comme une panne du système.

On distingue généralement trois catégories de STR :

2.1. Temps Réel Strict (Hard Real-Time)

Photo by Fotografía creativa on Pexels

Pour ces systèmes, le non-respect d'une échéance (deadline) a des conséquences catastrophiques, comme la perte de vies humaines ou des dommages matériels importants. La prévisibilité est primordiale.

Exemples :
* Systèmes de contrôle de vol d'avion : Les calculs d'altitude, de vitesse et d'angle doivent être effectués et les commandes envoyées aux gouvernes dans des délais très stricts pour maintenir l'avion en vol et réagir aux conditions changeantes. Un retard, même minime, peut entraîner une catastrophe.
* Systèmes de freinage ABS (Anti-lock Braking System) : Le STR doit détecter le blocage imminent d'une roue et relâcher/réappliquer la pression de freinage plusieurs fois par seconde. Si le système réagit trop lentement, la roue se bloque, le véhicule dérape et le contrôle est perdu.
* Contrôle de réacteurs nucléaires : Les systèmes de sécurité qui surveillent la température et la pression doivent réagir instantanément pour éviter une fusion.

2.2. Temps Réel Souple (Soft Real-Time)

Photo by Vitaly Gariev on Pexels

Le non-respect occasionnel d'une échéance est indésirable mais n'entraîne pas de défaillance majeure du système. La qualité du service peut être dégradée, mais le système reste fonctionnel.

Exemples :
* Systèmes de streaming vidéo/audio : Un petit délai ou un court "buffering" peut provoquer un micro-saccade (glitch) ou une pause, ce qui est gênant, mais le flux reprend et le système continue de fonctionner. Ce n'est pas catastrophique.
* Jeux vidéo : Un lag (délai de réponse) occasionnel peut nuire à l'expérience de jeu, mais le jeu ne plante pas nécessairement.
* Systèmes de contrôle de processus industriels non critiques : Par exemple, un système de surveillance de la température dans un entrepôt. Un relevé tardif n'est pas idéal, mais ne cause pas de danger immédiat.

2.3. Temps Réel Ferme (Firm Real-Time)

Photo by Fotografía creativa on Pexels

C'est un intermédiaire entre le strict et le souple. Le non-respect d'une échéance rend le résultat inutile, mais n'entraîne pas une défaillance catastrophique. Les résultats en retard sont souvent jetés.

Exemples :
* Routage de paquets sur un réseau : Si un paquet arrive trop tard, il est considéré comme perdu et un nouveau doit être envoyé. L'ancien n'a plus de valeur.
* Systèmes de trading boursier haute fréquence : Les ordres doivent être exécutés dans des millisecondes pour profiter des fluctuations. Un ordre exécuté trop tard est inutile car le prix a changé.

2.4. La Différence Cruciale

Photo by ISABELLE SU on Pexels

La distinction clé réside dans la gravité des conséquences d'un retard. Pour les STR stricts, la défaillance est impardonnable. Pour les STR souples, elle est tolérable jusqu'à un certain point. Pour les STR fermes, les données tardives sont inutiles.

2.5. Pourquoi LabVIEW est pertinent pour les STR

LabVIEW, avec ses modules temps réel (Real-Time Module), est particulièrement adapté pour le développement de systèmes temps réel, notamment pour l'acquisition de données, le contrôle et la régulation. Il permet de créer des applications qui s'exécutent sur des cibles temps réel dédiées (comme les contrôleurs CompactRIO) avec une déterministe et une fiabilité accrues.

Voici un diagramme Mermaid montrant la hiérarchie des systèmes temps réel selon la criticité :

graph TD
    A["Systèmes Temps Réel (STR)"] --> B["Temps Réel Strict (Hard RT)"];
    A --> C["Temps Réel Ferme (Firm RT)"];
    A --> D["Temps Réel Souple (Soft RT)"];

    B --> B1["Ex: Contrôle de Vol Avion"];
    B --> B2["Ex: ABS Automobile"];
    B --> B3["Ex: Contrôle Réacteur Nucléaire"];

    C --> C1["Ex: Trading Haute Fréquence"];
    C --> C2["Ex: Routage de Paquets"];

    D --> D1["Ex: Streaming Vidéo"];
    D --> D2["Ex: Jeux Vidéo"];
    D --> D3["Ex: Monitoring Non Critique"];

3. Worked Example

Prenons un exemple concret : un système de contrôle de température critique pour un four industriel.

Objectif : Maintenir la température du four à 1000°C ± 5°C. Si la température dépasse 1010°C ou descend en dessous de 990°C, le chauffage doit être coupé ou augmenté immédiatement. Un retard de plus de 100 ms dans la réaction peut endommager le produit ou le four.

Type de STR : C'est un système Temps Réel Strict. Un dépassement ou un sous-dépassement prolongé peut entraîner des pertes financières importantes ou des risques de sécurité.

Implémentation avec LabVIEW (conceptuel) :

1. Acquisition de données : Une sonde de température (thermocouple) est connectée à une carte d'acquisition de données (DAQ) elle-même sur un contrôleur temps réel LabVIEW (par exemple, un cRIO).
2. Boucle de contrôle temps réel : Sur le cRIO, un programme LabVIEW s'exécute dans une boucle déterministe, par exemple toutes les 50 ms.
   • À chaque itération, le programme lit la température de la sonde.
   • Il compare la température mesurée avec la consigne (1000°C) et les seuils critiques (990°C, 1010°C).
   • Si la température est trop basse, il envoie un signal pour augmenter la puissance de chauffe.
   • Si la température est trop élevée, il envoie un signal pour réduire ou couper la puissance.
   • Si la température est dans la plage acceptable, il ajuste finement le chauffage.
3. Sortie : Le contrôleur envoie des signaux numériques ou analogiques à des relais ou des variateurs de puissance pour contrôler les éléments chauffants du four.
4. Interface utilisateur (non temps réel) : Un PC hôte peut se connecter au cRIO pour afficher la température, les alarmes et permettre à un opérateur de modifier la consigne, mais cette interface n'est pas critique pour le respect des délais.

L'utilisation d'un contrôleur temps réel avec LabVIEW garantit que la boucle de lecture, de calcul et de commande s'exécute de manière prévisible toutes les 50 ms, sans interruption due au système d'exploitation généraliste (comme Windows), ce qui est essentiel pour maintenir le four dans les limites de température critiques.

4. Key Takeaways

• Les systèmes temps réel (STR) sont définis par la nécessité de respecter des délais de réponse stricts et prévisibles.
• La criticité des STR se divise en trois catégories : strict (hard), ferme (firm) et souple (soft), selon les conséquences d'un retard.
• Les STR stricts sont essentiels pour la sécurité et évitent les catastrophes en garantissant des réponses à temps.
• Les STR souples peuvent tolérer des retards occasionnels sans défaillance majeure, mais avec une dégradation de la performance.
• Les STR fermes considèrent les résultats en retard comme inutiles, même si le système ne s'effondre pas.
• LabVIEW avec ses modules temps réel est un outil puissant pour développer des STR déterministes.

Common Mistakes to Avoid:
- Confondre un système rapide avec un système temps réel : Un processeur rapide n'est pas forcément temps réel s'il n'offre pas de garanties de prévisibilité.
- Négliger les tests de charge et de coin de cas : Les STR doivent être testés dans toutes les conditions imaginables pour s'assurer qu'ils respectent les délais.
- Sous-estimer la complexité de la gestion des priorités : Dans un STR, toutes les tâches n'ont pas la même importance, et une mauvaise priorisation peut entraîner des retards critiques.
- Utiliser un système d'exploitation non temps réel pour des tâches critiques : Les OS comme Windows ne garantissent pas les délais nécessaires pour les STR stricts.

5. Now Try It

Considérez un système de surveillance des battements cardiaques dans une unité de soins intensifs. Décrivez pourquoi il s'agit d'un STR (et de quelle catégorie), quelles pourraient être les conséquences d'un délai dans l'affichage d'une alarme, et comment LabVIEW pourrait être utilisé pour acquérir et traiter les signaux ECG en temps réel.
Votre succès sera de justifier le type de STR, d'identifier clairement les risques liés aux retards et d'esquisser les fonctions clés que le programme LabVIEW devrait remplir.