Catégorisation des 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, et leur classification dépend de la criticité de ces délais. On distingue principalement les systèmes temps réel stricts, souples et fermes, chacun ayant des exigences et des conséquences différentes en cas de non-respect. Comprendre cette classification est crucial pour la conception et l'évaluation de tout système embarqué ou de contrôle.

1. The Mental Model

Imagine que tu as un emploi du temps très précis. Pour un avion, il faut que tout se passe à la seconde près : c'est strict. Pour regarder un film, un petit délai n'est pas la fin du monde : c'est souple. Pour une machine à café, tu veux ton café rapidement mais ce n'est pas grave s'il prend quelques secondes de plus : c'est ferme.

2. The Core Material

En LabVIEW et en électronique, surtout quand on travaille avec des systèmes embarqués ou de contrôle, la notion de temps réel est fondamentale. Un système temps réel est un système dont l'exactitude des résultats ne dépend pas seulement de la valeur logique de la sortie, mais aussi du moment où cette sortie est produite.

La catégorisation des systèmes temps réel est essentielle car elle dicte les exigences de conception, les choix matériels (FPGA, microcontrôleurs, CPU) et logiciels (OS temps réel - RTOS), et les stratégies de test.

2.1. Systèmes Temps Réel Stricts (Hard Real-Time Systems)

Photo by Fernando Narvaez on Pexels

Ce sont les systèmes où le non-respect d'une contrainte temporelle (deadline) a des conséquences catastrophiques, souvent irréversibles, comme la perte de vies humaines, des dommages matériels importants ou des pertes financières colossales.

• Caractéristiques:
  • Les délais doivent être garantis sous toutes les conditions de charge et d'événements.
  • La prédictibilité est la propriété la plus importante.
  • Utilisation fréquente de RTOS préemptifs et déterministes, ou de boucles de contrôle directes sur matériel dédié (FPGA).
• Exemples: Systèmes de contrôle de vol d'avions, freins ABS, centrales nucléaires, équipements médicaux de maintien de vie.

2.2. Systèmes Temps Réel Fermes (Firm Real-Time Systems)

Photo by Tima Miroshnichenko on Pexels

Dans ces systèmes, le non-respect d'une deadline rend le résultat inutile, mais n'entraîne pas de conséquences catastrophiques. Il y a une dégradation de la qualité du service, mais pas de catastrophe.

• Caractéristiques:
  • Les délais sont importants, mais une violation occasionnelle n'est pas critique.
  • Le résultat est invalide si trop tardif.
  • Un certain niveau de flexibilité peut être toléré, mais la performance globale est essentielle.
• Exemples: Chaînes de production robotisées (un léger retard d'un robot n'est pas catastrophique mais peut perturber la chaîne), systèmes de trading financier haute fréquence (une transaction trop tardive est inutile), certains systèmes de vision par ordinateur.

2.3. Systèmes Temps Réel Souples (Soft Real-Time Systems)

Photo by Fernando Narvaez on Pexels

Ici, le non-respect d'une deadline entraîne une dégradation de la performance ou de la qualité perçue, mais le résultat reste utile et il n'y a pas de conséquences majeures.

• Caractéristiques:
  • Les délais sont souhaitables mais non critiques.
  • Le système peut fonctionner avec des retards occasionnels.
  • La priorité est souvent donnée à d'autres critères comme le débit ou la facilité de développement.
• Exemples: Lecture de vidéo en streaming, jeux vidéo, interfaces utilisateur graphiques, contrôle industriel non critique (surveillance de température sans action immédiate).

Voici un diagramme Mermaid pour visualiser cette hiérarchie:

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

    B -- "Conséquences catastrophiques si délai dépassé" --> E["Ex: Contrôle de vol, ABS"]
    C -- "Résultat inutile si délai dépassé" --> F["Ex: Robot industriel, Trading HFT"]
    D -- "Dégradation de performance si délai dépassé" --> G["Ex: Lecture vidéo, IHM"]

3. Worked Example

Imagine que tu développes un système de contrôle pour un robot industriel qui doit positionner des composants électroniques sur un PCB.

Scénario: Le robot doit prendre un composant, le déplacer et le déposer avec une précision de 0.1 mm et dans un intervalle de 50 ms pour maintenir la cadence de production.

• Analyse:

  • Si le robot dépose le composant en dehors des 50 ms, la chaîne de production est ralentie, la productivité diminue.
  • Si le composant est déposé trop tard, le PCB suivant arrive, et le composant est mal placé ou manqué, ce qui rend le PCB défectueux et coûteux à refaire.
  • Cependant, un simple retard de quelques cycles n'entraîne pas une explosion de l'usine ni un danger de mort.

• Conclusion: Ce système serait classé comme Système Temps Réel Ferme. Le non-respect du délai rend la tâche inutile (composant mal placé ou manqué), et a des conséquences économiques négatives (PCB défectueux, perte de production), mais pas catastrophiques. Tu devrais donc choisir une architecture matérielle et logicielle capable de garantir la plupart des deadlines, avec des mécanismes de récupération pour les rares échecs.

4. Key Takeaways

• Un système temps réel doit produire des résultats corrects dans des délais spécifiques.
• Les systèmes stricts exigent une garantie absolue des délais pour éviter des catastrophes.
• Les systèmes fermes tolèrent peu de retards, car un résultat tardif devient inutile, mais sans conséquences catastrophiques.
• Les systèmes souples peuvent fonctionner avec des retards occasionnels, ce qui affecte la qualité perçue mais pas la fonctionnalité essentielle.
• La classification impacte directement le choix du matériel (FPGA, CPU, RTOS) et les techniques de programmation.
• Un LabVIEW Real-Time (sur cRIO par exemple) est souvent utilisé pour les systèmes stricts et fermes grâce à sa capacité de garantir les délais.
• La prédictibilité est plus importante que la vitesse brute pour les systèmes temps réel stricts.

Common mistakes to avoid:
- Confondre "rapide" avec "temps réel" : un système rapide peut ne pas être prévisible, et donc non temps réel.
- Sous-estimer la criticité des délais pour les systèmes "fermes" : un résultat inutile est souvent aussi mauvais qu'un résultat faux.
- Ne pas prendre en compte la surcharge du système d'exploitation ou du matériel : cela peut compromettre les garanties de délai.
- Ne pas tester les contraintes temporelles sous des conditions de charge maximales ou de "pire cas".

5. Now Try It

Pense à un projet que tu as réalisé ou que tu aimerais réaliser avec LabVIEW et de l'électronique. Décris ce projet en quelques phrases, puis catégorise-le comme étant un système temps réel strict, ferme ou souple.

Explique pourquoi tu as choisi cette catégorie en te basant sur les conséquences du non-respect des délais. Quels seraient les dangers ou les problèmes si les délais n'étaient pas respectés?

• Exemple de succès: "Je contrôle la température d'une serre. Si la température dépasse un seuil pendant plus d'une minute, les plantes peuvent être endommagées, mais ce n'est pas une catastrophe immédiate. C'est un système temps réel ferme, car un retard rend l'action inutile (plantes déjà affectées) et coûteux, mais pas catastrophique."