Piloter des objets connectés

Un système embarqué est un dispositif informatique intégré à un objet pour lui faire accomplir une tâche. Dans un ventilateur automatique de classe, un capteur mesure la température ; un microcontrôleur lit cette mesure, exécute un programme et commande un actionneur, ici le moteur. Une interface homme-machine peut afficher la température ou permettre à l’utilisateur de changer une consigne. Les rôles doivent rester distincts : le capteur observe une grandeur, le programme prend une décision selon des règles et l’actionneur agit sur le monde physique. L’écran n’est pas le capteur, même s’il montre sa valeur.

Le schéma représente un flux d’information de gauche à droite. La mesure atteint le programme ; celui-ci produit un ordre destiné à l’actionneur. Dans un système réel, le moteur reçoit aussi de l’énergie électrique par un circuit adapté : une flèche de commande ne représente pas cette alimentation. Un capteur peut fournir une valeur imparfaite ou indisponible. La qualité de la mesure, la fréquence de lecture et la sécurité de la commande comptent donc autant que la syntaxe du programme. Pour une activité scolaire, utilise un simulateur ou un matériel prévu par l’enseignant, sans brancher soi-même un moteur sur une source inconnue.

Un objet devient connecté lorsqu’il échange des données avec un autre appareil ou un service par un réseau. Le ventilateur automatique pourrait fonctionner localement sans Internet. Une application distante pourrait ajouter une interface de commande ou un historique, mais cette connexion crée aussi des possibilités de panne et de collecte de données. « Connecté » ne signifie donc pas « intelligent » ni « toujours meilleur ». Pour comprendre un objet, identifie ce qui fonctionne hors ligne, ce qui dépend d’un réseau et ce qui est conservé à distance.

Un programme embarqué peut répéter une boucle : lire le capteur, comparer la valeur à un seuil, commander la sortie, puis attendre avant une nouvelle lecture. Une règle simple pour notre ventilateur est : si la température mesurée est strictement supérieure à 21 °C, activer le moteur ; sinon, l’arrêter. Le mot « strictement » compte : à 21 °C exactement, la condition est fausse. On peut représenter le moteur par 1 lorsqu’il marche et 0 lorsqu’il est arrêté. L’algorithme doit prévoir le cas où aucune mesure valide n’arrive : garder une ancienne valeur sans le dire serait trompeur.

Voici cinq mesures fictives dans l’ordre : 18 °C, 20 °C, 22 °C, 21 °C et 19 °C. Avec la règle précédente, la suite des commandes est 0, 0, 1, 0, 0. La figure montre l’unique instant où la sortie vaut 1. Elle représente la commande produite par la règle, pas une courbe de température ni le mouvement réel du ventilateur. Un moteur peut mettre un peu de temps à démarrer ou s’arrêter ; un dispositif physique a une dynamique que le calcul logique ne montre pas. On vérifie donc séparément la décision du programme et la réponse de l’objet.

Une commande à seuil unique peut basculer souvent si la mesure oscille autour de 21 °C. On peut introduire deux seuils : démarrer au-dessus de 22 °C et arrêter en dessous de 20 °C. Entre les deux, le système conserve son état précédent ; c’est une hystérésis. Cette amélioration demande de mémoriser l’état et de définir son état initial. Elle dépasse la règle simple du premier exercice, mais elle montre qu’un comportement réel ne se résume pas toujours à une seule comparaison. Pour tester, prépare des cas au-dessous, au-dessus et exactement sur les seuils.

Une interface homme-machine, ou IHM, permet à une personne de lire l’état de l’objet et d’envoyer une consigne. Pour notre exemple, elle peut montrer la mesure actuelle, l’état du ventilateur et un bouton de marche manuelle. Ces informations doivent être claires : une mesure en degrés Celsius, un état « marche » ou « arrêt », et une indication si le capteur ne répond plus. Un simple voyant allumé ne suffit pas à distinguer un moteur qui tourne réellement d’un ordre envoyé au moteur. La conception de l’interface commence donc par la question : que sait-on, et que veut-on permettre à l’utilisateur ?

Pour tester un programme, prépare une table d’essais : entrée du capteur, état attendu, état observé. Les cas limites sont particulièrement utiles. Si le seuil est 21 °C, les entrées 20,9 ; 21 ; 21,1 permettent de vérifier la frontière. Une valeur absente, impossible ou incohérente doit mener à un état défini et visible. Le test de logiciel seul ne prouve pas que le moteur est correctement alimenté ni que le capteur est étalonné. Un essai de matériel se fait avec les consignes de sécurité du laboratoire ou de la classe.

Un objet connecté peut aussi être piloté par une application mobile. Une commande distante doit indiquer à quel appareil elle s’adresse et confirmer si l’ordre a été reçu. Si la connexion est coupée, l’objet doit avoir un comportement local défini. Pour un ventilateur scolaire, l’arrêt par défaut peut être raisonnable ; pour d’autres objets, ce choix doit être étudié selon le risque de la fonction. La sécurité d’un programme consiste notamment à prévoir les entrées inattendues, les pannes de communication et les actions que l’utilisateur peut interrompre.

Un objet connecté peut transmettre des mesures, des horaires et des commandes. Ces données peuvent révéler des habitudes, par exemple les heures où un logement est occupé. Il faut demander quelles informations sont nécessaires au service, où elles sont conservées, qui y accède et combien de temps elles restent disponibles. Le fait qu’un objet possède un capteur ne prouve pas qu’il envoie toutes ses mesures à un serveur : vérifie le fonctionnement du modèle précis. De même, une fonction de contrôle à distance exige une connexion, mais certaines automatisations locales peuvent continuer sans elle.

La sécurité dépend aussi des mises à jour du logiciel, des mots de passe, des autorisations d’accès et de la séparation entre comptes. Un appareil laissé avec un mot de passe partagé ou un service non mis à jour peut devenir une porte d’entrée vers d’autres systèmes. Les mises à jour sont utiles lorsqu’elles corrigent des défauts, mais il faut suivre la procédure du fabricant ou de l’établissement pour ne pas interrompre un équipement critique. Dans un contexte scolaire, aucun élève ne doit modifier seul un appareil réel qui commande une fonction de sécurité.

Le numérique embarqué peut apporter du confort, une aide à l’autonomie ou une régulation plus fine. Il consomme aussi des ressources : énergie du matériel, fabrication de composants et éventuelle transmission de données. Dire qu’un objet connecté « économise toujours de l’énergie » serait injustifié ; il faut comparer un scénario d’usage précis. L’enjeu pédagogique est de comprendre le compromis, pas d’acheter un équipement. Un système bien conçu permet aussi de reprendre la main manuellement et de savoir ce qu’il fait lorsque le réseau ne fonctionne plus.