Communication, temps réel et sûreté de fonctionnement

Communication, système d'exploitation temps réel et sûreté

1. Communiquer sur une cible contrainte

   Un objet embarque communique dans des conditions hostiles : peu de signal, batterie faible, interférences, et un utilisateur qui s'éloigne.

   Pourquoi la radio est le premier problème

   La consommation d'une radio est liée à la puissance d'émission : la transmettre plus loin coûte nettement plus que la recevoir. Un appareil sur batterie ne peut donc pas émettre en permanence, et chaque émission est une décision à() — ce n'est pas pas un simple choix technique, c'est un arbitrage énergie contre réactivité.

   La conséquence pratique : la portée et la durée de vie de la batterie ne sont pas deux paramètres indépendants. On ne peut pas avoir les deux au maximum, et le produit doit choisir. Un capteur de température n'a aucun besoin d'émettre en continu, un traceur localisé en a.

   Les trois erreurs réseau coûteuses

   1. échouer silencieusement : un envoi qui échoue sans erreur visible produit un appareil qui paraît fonctionner et ne transmet plus. Sur un capteur, cela se découvre parfois des mois plus tard ;
   2. ne pas gérer la reprise : après une coupure, l'appareil doit revenir à un état cohérent. Un système embarqué n'a pas toujours le droit de redémarrer — et si le redémarrage est possible, il ne suffit pas à tout corriger ;
   3. ignorer la consommation réelle : la mesure du coût réel de chaque opération d'émission se fait au multimètre, jamais à l'estimation. Un facteur trois entre les deux est courant.

   Le protocole, avant la bibliothèque

   Un protocole de communication se définit complètement, y compris ses cas d'erreur : Délai maximal d'attente, nombre de reprises, et ce qui se passe quand la cible ne répond pas. Un protocole qui ne définit pas la fin de l'attente n'est pas un protocole, c'est un script qui fonctionne quand rien ne va mal — et c'est exactement le cas qu'on forget de tester.

2. Le système d'exploitation temps réel

   Un système d'exploitation temps réel fournit ce qu'un programme classique ne trouve pas sur une cible : l'ordonnancement, la synchronisation et la gestion du temps.

   Les deux notions à distinguer

   • une tâche : une unité d'exécution avec sa propre pile, ses priorités et son délai ;
   • un sémaphore : le mécanisme de synchronisation, indispensable dès que deux tâches partagent une ressource.

   Confondre les deux est l'erreur qui produit un blocage généralisé : une tâche qui attend ce qu'elle garde, et qui empêche toutes les autres d'avancer. Le système reste figé, et rien n'indique la cause.

   L'inversion de priorité, et son parade

   Deux mots à connaître parce qu'ils expliquent un défaut qui peut ruiner un système sans le faire planter :

   • l'inversion de priorité : une tâche de priorité haute attend une ressource détenue par une tâche de priorité basse, qui n'est pas schedulée parce que la haute priorité occupe le processeur. Le système gèle sans erreur visible ;
   • le protocole de priorité héritée : la parade. Une tâche qui demande une ressource elevre temporairement la priorité de celle qui la détient, et la rend ensuite. C'est quelques lignes de configuration, et cela supprime une classe entière de blocages.

   La leçon générale : sur un système contraint, les propriétés qui se voient sont les moindres utiles. Un plantage est presque toujours plus facile à diagnostiquer qu'un gel.

   Les deux systèmes présents aujourd'hui

   Zephyr et FreeRTOS couvrent l'essentiel des besoins. Ce sont des choix d'écosystème autant que de technique : ils imposent des conventions, proposent une chaîne d'outils complète et sont organises autour d'eux, et cela pèse autant que les caractéristiques du noyau lui-même. Le choix se justifie par l'équipe et l'outil disponible, autant que par l'excellence technique — la même leçon que le cours sur les frameworks front.

3. Sûreté de fonctionnement et mises à jour

   Un défaut qui redémarre l'appareil est un défaut d'inconfort. Un défaut qui produit un mauvais calcul sans aucun signe est un défaut de sûreté, et il se traite avec une exigence complètement différente.

   Les trois familles de défaillance

   1. les erreurs de conception : le programme fait autre chose que ce qui est prévu. Seutralisent par des tests, des assertions et de la relecture ;
   2. les défaillances de matériel : bit mémoire qui bascule, condensateur qui sèche. Se traitent par de la redondance et de la détection, jamais par l'optimisme ;
   3. les conditions d'emploi : coupure de courant, court-circuit, choc mécanique. Se traitent par une conception qui rend l'échec non dangereux.

   La phrase qui résume le métier : une conception sûre est une conception dont l'échec est détectable et sans conséquence grave. Un système qui plante trois fois par jour dans un environnement contrôlé est plus sûr qu'un système qui continue à produire un résultat faux sans jamais s'arrêter.

   La mise à jour, ou le moment le plus dangereux

   Mettre à jour un appareil déployé, c'est remplacer un composant dont on ne maîtrise plus l'état. Les deux pertes d'alimentation au milieu d'une écriture produisent un appareil inutilisable, et il est parfois à des centaines de kilomètres, sans possibilité d'intervention physique.

   La solution est structurelle et connue : écrire dans la mémoire inactive, vérifier l'image par un contrôle d'intégrité, puis basculer un simple indicateur de démarrage. Le risque résiduel — une coupure pendant le basculement — se traite par un indicateur de démarrage enregistré, qui ramène toujours à une image valide. Un mécanisme de ce type se conçoit au moment du premier programme, pas au moment du premier incident terrain.