Fiabilité et Prédictibilité des Systèmes Temps Réel

TL;DR

Les systèmes temps réel doivent non seulement fonctionner correctement, mais aussi le faire dans des délais stricts. La fiabilité assure que le système remplit sa fonction sans défaillance, tandis que la prédictibilité garantit que les actions sont exécutées dans un intervalle de temps connu et délimité. Ces deux concepts sont cruciaux pour la sécurité et l'efficacité des applications critiques, comme celles en LabVIEW.

1. The Mental Model

Imaginez une chaîne de montage robotisée : la fiabilité c'est que le robot place toujours la pièce au bon endroit. La prédictibilité, c'est qu'il le fasse toujours en moins d'une seconde, sans jamais déborder, même si d'autres tâches se déroulent en parallèle.

2. The Core Material

Dans le monde des systèmes temps réel (STR), et particulièrement avec LabVIEW Real-Time, la notion de "juste fonctionner" n'est pas suffisante. Il faut que ça fonctionne à temps, tout le temps.

Fiabilité

La fiabilité mesure la probabilité qu'un système fonctionne sans défaillance pendant une période donnée, sous des conditions spécifiées. En gros, c'est la capacité de votre système à ne pas tomber en panne.
Pour améliorer la fiabilité, on se concentre sur :
* La Robustesse du Code : Gérer les erreurs de manière élégante (par exemple, utiliser des structures d'événements robustes en LabVIEW, des timeouts, des gestionnaires d'erreurs).
* La Redondance : Avoir des composants de secours prêts à prendre le relais en cas de défaillance (matérielle ou logicielle).
* Les Tests Exhaustifs : Soumettre le système à des conditions extrêmes et des scénarios de panne pour identifier et corriger les faiblesses.
* La Surveillance : Mettre en place des mécanismes pour détecter les problèmes en temps réel et alerter l'opérateur ou déclencher des procédures de sécurité.

Prédictibilité

La prédictibilité, c'est la garantie qu'une opération se terminera dans un intervalle de temps défini. Cela ne signifie pas nécessairement que l'opération est rapide, mais qu'elle est toujours bornée dans le temps. Un système non prédictible peut être rapide la plupart du temps, mais occasionnellement très lent, ce qui est inacceptable pour un STR.

Pour atteindre la prédictibilité en LabVIEW Real-Time :
* Planification des Tâches : Utiliser les priorités de thread pour s'assurer que les tâches critiques sont exécutées en premier. LabVIEW Real-Time offre un scheduler déterministe.
* Minimisation des Latences : Éviter les opérations qui peuvent introduire des retards imprévisibles (accès disque non mis en cache, allocations mémoire dynamiques excessives, appels à des fonctions bloquantes).
* Boucles Temporelles (Timed Loops) : En LabVIEW, ces boucles sont l'outil clé pour garantir l'exécution à des intervalles précis et avec des contraintes de temps strictes. Elles permettent de définir une période et un délai maximal.
* Isolation des Ressources : S'assurer que les tâches critiques n'ont pas à se battre pour des ressources partagées avec des tâches moins prioritaires.

Voici un schéma simple qui montre la relation entre ces concepts et comment on les atteint :

graph TD
    A["Objectif: Système Temps Réel Fiable et Prédictible"] --> B("Fiabilité")
    A --> C("Prédictibilité")

    B --> B1("Robustesse du Code (Gestion d'erreurs, LabVIEW)")
    B --> B2("Redondance (Matérielle/Logicielle)")
    B --> B3("Tests Exhaustifs (Scénarios de panne)")
    B --> B4("Surveillance (Détection temps réel)")

    C --> C1("Planification des Tâches (Priorités, Scheduler)")
    C --> C2("Minimisation des Latences (Éviter alloc. dyn.)")
    C --> C3("Boucles Temporelles (LabVIEW Timed Loops)")
    C --> C4("Isolation des Ressources (Pas de conflit)")

    B1 --> D["Code de Qualité"]
    B2 --> D
    B3 --> D
    B4 --> D

    C1 --> E["Exécution Déterministe"]
    C2 --> E
    C3 --> E
    C4 --> E

    D --> F("Comportement Correct")
    E --> G("Respect des Délais")

    F & G --> A

En LabVIEW, les "Timed Loops" sont votre meilleur ami pour la prédictibilité. Elles vous permettent de spécifier une période d'exécution et, crucialement, un "deadline" (délai maximal) pour chaque itération. Si le code à l'intérieur de la boucle dépasse ce deadline, la boucle peut le signaler, vous permettant de diagnostiquer les problèmes de prédictibilité.

Exemple de code (pseudo-LabVIEW pour l'idée) :

// Boucle Temporelle (Timed Loop) configurée pour 10ms
// et un deadline de 9ms.
Timed_Loop(Period = 10ms, Deadline = 9ms, Priority = 100)
{
    // Lire un capteur
    Sensor_Value = Read_Sensor();

    // Effectuer un calcul rapide
    Processed_Value = Perform_Fast_Calculation(Sensor_Value);

    // Écrire la commande sur un actionneur
    Write_To_Actuator(Processed_Value);

    // Si cette section prend plus de 9ms, le deadline est manqué.
    // La Timed Loop peut émettre un avertissement ou une erreur.
}

Systèmes Hard Real-Time vs. Soft Real-Time

Photo by Atlantic Ambience on Pexels

• Hard Real-Time (Temps Réel Strict) : Le non-respect d'un délai est une défaillance catastrophique. Ex: systèmes de contrôle de vol, dispositifs médicaux implantables. Ici, fiabilité et prédictibilité sont absolument critiques.
• Soft Real-Time (Temps Réel Souple) : Le non-respect occasionnel d'un délai est tolérable, mais dégrade la performance. Ex: streaming vidéo, interfaces utilisateur réactives. Une bonne fiabilité est toujours souhaitée, mais la prédictibilité peut être légèrement moins rigoureuse. LabVIEW RT peut être utilisé pour les deux, mais les systèmes Hard RT exigent une conception et une validation beaucoup plus rigoureuses.

3. Worked Example

Imaginons que nous développons un système LabVIEW Real-Time pour contrôler un bras robotique qui doit ramasser et déposer des objets sur une ligne de production. Chaque cycle "ramasser-déposer" doit impérativement être terminé en moins de 100 ms pour maintenir le rythme de la production et éviter d'endommager les objets.

1. Exigence : Cycle complet (détection, prise, déplacement, dépose) < 100 ms.

2. Mise en œuvre LabVIEW RT :

   • Nous créons un VI avec une Timed Loop configurée pour une période de 100 ms.
   • Le "deadline" est également fixé à 95 ms (pour avoir une petite marge).
   • À l'intérieur de la boucle, nous intégrons les VIs de :
     • Lecture du capteur de présence (5 ms).
     • Calcul de la trajectoire du bras (30 ms).
     • Commande des moteurs du bras (40 ms).
     • Vérification de la dépose (10 ms).
   • Total théorique des opérations : 5 + 30 + 40 + 10 = 85 ms. C'est en dessous de notre deadline de 95 ms, ce qui est bon signe.

3. Fiabilité :

   • Nous ajoutons des gestionnaires d'erreurs à chaque sous-VI. Si un capteur tombe en panne ou si le bras rencontre une obstruction, le système déclenche un arrêt d'urgence contrôlé au lieu de continuer et de causer plus de dommages.
   • Des tests sont effectués pour simuler des capteurs défectueux ou des commandes de moteur échouant, afin de vérifier que le système réagit comme prévu.

4. Prédictibilité :

   • Pendant les tests, nous surveillons le nœud de sortie de la Timed Loop, spécifiquement le paramètre "Did Last Iteration Miss Deadline?".
   • Nous constatons que 99,9% des itérations respectent le deadline. Cependant, une fois sur 10 000, le deadline est manqué de quelques millisecondes.
   • Analyse : Après investigation, nous découvrons qu'une opération d'écriture sur le disque (pour loguer des données de diagnostic) se produit occasionnellement à l'intérieur de la Timed Loop, introduisant une latence imprévisible.
   • Correction : Nous déplaçons cette opération de logging vers une boucle séparée, de priorité inférieure, qui s'exécute moins fréquemment ou utilise une mémoire tampon (buffer) pour écrire sur le disque de manière asynchrone et non bloquante.
   • Résultat : Le système respecte désormais le deadline de 95 ms de manière constante, garantissant la prédictibilité requise.

Cet exemple montre comment la fiabilité (gestion d'erreurs) et la prédictibilité (respect du deadline grâce à l'optimisation des tâches) sont interdépendants pour un fonctionnement robuste du système.

4. Key Takeaways

• La fiabilité est la capacité d'un système à fonctionner sans défaillance pendant une période donnée.
• La prédictibilité est la garantie qu'une tâche se terminera dans un délai maximum défini.
• Les Boucles Temporelles (Timed Loops) en LabVIEW Real-Time sont essentielles pour la prédictibilité.
• Un système temps réel strict (hard real-time) ne tolère aucun manquement aux délais.
• Évitez les opérations non déterministes comme les accès disque bruts ou les allocations mémoire dynamiques excessives dans les boucles critiques.
• Une bonne gestion des erreurs et des tests rigoureux sont fondamentaux pour la fiabilité.

Common Mistakes:
- Oublier de surveiller le paramètre "Did Last Iteration Miss Deadline?" des Timed Loops, ce qui masque les problèmes de prédictibilité.
- Mettre des opérations de logging, d'interface utilisateur ou d'accès fichier directs dans des boucles de haute priorité, introduisant des latences imprévisibles.
- Ne pas tester le système sous des charges élevées ou des conditions de défaillance, ce qui compromet la fiabilité.
- Supposer qu'un code "rapide" est automatiquement "prédictible" sans vérifier les contraintes temporelles.

5. Now Try It

Créez un nouveau projet LabVIEW pour un système Real-Time. Dans votre VI principal, mettez une Timed Loop avec une période de 50 ms et un deadline de 45 ms. À l'intérieur de cette boucle, ajoutez :
1. Un VI qui simule une tâche de lecture de capteur (par exemple, une fonction de délai Wait (ms) de 10 ms).
2. Un VI qui simule un traitement de données (une autre Wait (ms) de 20 ms).
3. Un VI qui simule une écriture sur actionneur (encore une Wait (ms) de 10 ms).
4. À côté de ces fonctions, ajoutez un VI Write to Measurement File configuré pour écrire une petite donnée (par exemple, un compteur d'itération) sur le disque à chaque itération.
5. Surveillez la sortie "Did Last Iteration Miss Deadline?" de votre Timed Loop.
6. Question : Que se passe-t-il lorsque le Write to Measurement File est activé dans la Timed Loop ? Combien d'itérations manquent leur deadline ?
7. Correction : Déplacez le Write to Measurement File hors de la Timed Loop, dans une boucle parallèle de priorité inférieure, ou utilisez un File Buffer pour écrire les données périodiquement. Répétez l'observation.

Le succès ressemblera à ceci : votre Timed Loop ne manquera presque jamais son deadline une fois la tâche d'écriture fichier déplacée ou optimisée, démontrant une prédictibilité améliorée.