Introduction aux Systèmes Temps Réel

TL;DR

Un système temps réel doit garantir des réponses dans des délais stricts, pas seulement rapides. Sa performance est mesurée par sa capacité à respecter ces échéances, crucial pour la sécurité et la fiabilité. Ces systèmes sont partout, des voitures aux applications industrielles, et LabVIEW est un outil puissant pour les développer.

1. The Mental Model

Imaginez une chaîne de montage où chaque robot doit effectuer sa tâche précisément au bon moment. Si un robot est en retard, même d'une fraction de seconde, toute la chaîne est compromise. Un système temps réel fonctionne de la même manière : la ponctualité est reine.

2. The Core Material

Un système temps réel (STR) est un système informatique qui doit produire une réponse correcte non seulement en termes de valeur logique, mais aussi dans un délai imparti. La justesse de la réponse est liée au respect de son échéance temporelle.

Il existe plusieurs types de STR, classés selon la gravité des conséquences en cas de non-respect des délais :

• Temps Réel Dur (Hard Real-Time) : Le non-respect d'une échéance entraîne une défaillance critique, souvent catastrophique (ex: systèmes de contrôle de vol, systèmes médicaux de support vital). Le respect des délais est absolument impératif.
• Temps Réel Souple (Soft Real-Time) : Le non-respect d'une échéance dégrade les performances mais n'entraîne pas de défaillance majeure (ex: lecture vidéo, jeux en ligne). La réponse tardive est moins utile, mais pas désastreuse.
• Temps Réel Firme (Firm Real-Time) : À mi-chemin entre le dur et le souple. Une réponse tardive est inutile, mais ne provoque pas de catastrophe (ex: contrôle de robots industriels où un retard peut causer des rebuts, mais pas de danger immédiat).

Caractéristiques Clés des STR :

Photo by TBD Traveller on Pexels

1. Prévisibilité (Predictability) : La capacité de garantir que le système agira dans un certain laps de temps, même dans le pire des cas. Ce n'est pas seulement la rapidité, c'est la connaissance du temps maximal d'exécution.
2. Déterminisme (Determinism) : Pour une même entrée, le système doit toujours produire la même sortie dans le même laps de temps.
3. Réactivité (Responsiveness) : La capacité à répondre rapidement aux événements externes.

Composants d'un STR :

Photo by Diana Draginova on Pexels

Un STR typique comprend :
* Matériel (Hardware) : Microcontrôleurs, processeurs temps réel, E/S (entrées/sorties) dédiées.
* Système d'Exploitation Temps Réel (RTOS - Real-Time Operating System) : Un OS conçu pour la prévisibilité et le déterminisme, gérant la planification des tâches avec des priorités et garantissant des temps de réponse (ex: VxWorks, QNX, NI LabVIEW RT).
* Applications (Applications) : Le code spécifique à la tâche, souvent développé avec des outils comme LabVIEW.

Pourquoi LabVIEW pour le Temps Réel ?

Photo by Daniil Komov on Pexels

LabVIEW, avec ses extensions Real-Time (RT), est particulièrement adapté aux STR pour plusieurs raisons :
* Programmation Graphique : Simplifie la visualisation des flux de données et la logique parallèle, ce qui est essentiel pour les systèmes réactifs.
* Matériel Intégré : S'intègre parfaitement avec les contrôleurs NI CompactRIO, PXI, et les cartes d'acquisition de données, souvent équipés de processeurs temps réel dédiés.
* RTOS Intégré : Les contrôleurs RT de NI exécutent un système d'exploitation temps réel sous-jacent (souvent Phar Lap ETS ou NI Linux Real-Time), gérant les priorités et la planification des tâches de manière déterministe.
* Priorités des Tâches : LabVIEW permet d'assigner des priorités différentes à des boucles ou des fonctions spécifiques, garantissant que les tâches critiques sont exécutées à temps.

Voici un diagramme simple illustrant la structure de base d'un système temps réel avec LabVIEW :

graph TD
    A["Capteurs & Actuateurs (I/O)"] --> B["Contrôleur Temps Réel (RT Target)"];
    B --> C["Système d'Exploitation Temps Réel (RTOS)"];
    C --> D["Application LabVIEW RT"];
    D --> E["Tâches Critiques (Haute Priorité)"];
    D --> F["Tâches Non Critiques (Basse Priorité)"];
    E --> G["Respect des Délais Stricts (Ex: Contrôle Moteur)"];
    F --> H["Flexibilité des Délais (Ex: Interface Utilisateur)"];

3. Worked Example

Imaginons que vous concevez un système pour contrôler la température d'un four industriel. Ce système doit maintenir la température à une valeur précise (par exemple, 200°C) avec une tolérance très faible. Si la température dépasse ou descend trop, cela peut endommager le produit ou même causer un accident. C'est un cas de temps réel dur ou ferme.

Votre système LabVIEW sur une cible RT (comme un CompactRIO) pourrait ressembler à ceci :

1. Acquisition de Température (Tâche Critique) : Une boucle LabVIEW lit la valeur d'un capteur de température toutes les 100 ms. Cette boucle a une haute priorité car la donnée est essentielle et urgente.
2. Algorithme de Contrôle PID (Tâche Critique) : Une autre boucle LabVIEW, également avec une haute priorité, prend la température lue, la compare à la consigne (200°C), et calcule l'ajustement nécessaire pour l'élément chauffant (par exemple, via un algorithme PID). Cette tâche s'exécute aussi toutes les 100 ms.
3. Commande de l'Élément Chauffant (Tâche Critique) : Le résultat de l'algorithme PID est envoyé à un actionneur (relais, variateur de puissance) pour ajuster le chauffage. Cette tâche est également à haute priorité et synchronisée.
4. Affichage sur IHM (Tâche Non Critique) : Une troisième boucle, exécutée à une basse priorité (par exemple, toutes les secondes), envoie la température actuelle et l'état du système à une interface utilisateur graphique (IHM) sur un ordinateur hôte. Un retard ici est acceptable car l'affichage n'impacte pas le contrôle direct.

Sur une cible LabVIEW RT, vous configureriez les propriétés d'exécution de vos boucles "Timed Loops" ou de vos VIs pour leur assigner les priorités et les intervalles d'exécution nécessaires, garantissant que les tâches de contrôle de température préemptent toujours les tâches d'affichage.

4. Key Takeaways

• Un système temps réel (STR) doit fournir une réponse correcte dans un délai garanti, pas seulement rapidement.
• Les STR sont classés en dur, ferme ou souple selon les conséquences d'un délai manqué.
• La prévisibilité, le déterminisme et la réactivité sont les caractéristiques fondamentales des STR.
• LabVIEW, avec ses cibles RT et son OS temps réel intégré, simplifie grandement le développement de STR.
• La gestion des priorités des tâches est cruciale pour garantir que les opérations critiques respectent leurs délais.
• Les applications typiques incluent le contrôle industriel, l'aérospatiale, la robotique et les systèmes embarqués.

Common Mistakes to Avoid:

Photo by KATRIN BOLOVTSOVA on Pexels

• Confondre "rapide" avec "temps réel" : un système rapide peut ne pas être prévisible ou déterministe.
• Négliger l'impact des tâches de basse priorité : elles peuvent consommer des ressources et affecter les tâches critiques si la planification n'est pas gérée.
• Mal estimer les délais : sous-estimer le temps nécessaire à une tâche critique peut mener à des défaillances.
• Ne pas utiliser un RTOS : tenter de construire un STR sans un OS conçu pour le temps réel rend la prévisibilité presque impossible.

5. Now Try It

Créez un projet LabVIEW simple pour une cible RT (même si vous n'avez pas le matériel physique, vous pouvez simuler la cible en ajoutant une "cible RT" dans un projet). Créez deux boucles parallèles : une "boucle de contrôle" avec une priorité élevée qui incrémente une variable toutes les 100 ms, et une "boucle d'affichage" avec une priorité basse qui lit et affiche cette variable toutes les 500 ms. Observez comment la boucle de contrôle maintiendrait sa cadence même si la boucle d'affichage est ralentie. Le succès sera de voir que la variable s'incrémente de 1 à chaque pas dans la boucle de contrôle et que l'affichage est simplement une "capture" de cette valeur à des intervalles moins fréquents.