Programmer une ventilation régulée et faire communiquer deux objets

Étape 1

Définir un modèle avant de lui faire prendre une décision

La station fictive « AirClasse » affiche une température T en °C et peut demander à une ventilation de fonctionner. Elle sert à étudier un programme, pas à décider de l’aération d’une salle réelle. Les mesures, dates et seuils du cours sont inventés. Dans une installation réelle, la qualité de l’air dépend de plusieurs grandeurs, des capteurs, des consignes locales et d’une décision humaine ; un modèle de classe ne les remplace pas.

Avant toute question, on fixe les hypothèses. Un événement arrive toutes les minutes. La variable T contient une température entière entre 0 et 40 °C seulement si le capteur l’a fournie et si son message est valide. La variable étatVentilation vaut « arrêt » au démarrage. La station connaît deux seuils : haut = 28 °C et bas = 24 °C. Entre eux, elle ne choisit pas un nouvel état : elle garde celui qu’elle avait juste avant.

Le programme reçoit une donnée, calcule une décision et prépare une commande dans un modèle. Il ne branche aucun moteur, ne garantit aucune mesure physique et ne donne pas l’autorisation de manipuler un appareil. Les mots « marche » et « arrêt » désignent ici les deux états simulés de la ventilation.

À retenir. Un algorithme répond à des hypothèses explicites : variables, unité, état initial, événement et domaine des valeurs.

Étape 2

Événement, initialisation et variables : garder ce qui compte

Au démarrage, une seule fois, le programme initialise étatVentilation à « arrêt ». À chaque événement « nouvelle mesure », il reçoit éventuellement T puis compare T aux seuils. Une variable peut donc avoir deux rôles distincts : T change à chaque mesure valide ; étatVentilation conserve une information utile d’un événement au suivant. Cette mémoire n’est pas une température cachée : c’est le dernier état de la décision.

La règle du modèle est la suivante : si T ≥ 28, étatVentilation devient « marche » ; sinon si T ≤ 24, étatVentilation devient « arrêt » ; sinon étatVentilation garde sa valeur. Les deux premiers tests modifient l’état ; le dernier ne fait rien à la variable parce que son ancienne valeur est justement la réponse attendue dans la zone comprise entre 24 et 28 °C.

Une absence de valeur ne devient jamais 0. « Pas de mesure », « message invalide » et « 0 °C mesuré » sont trois situations différentes. Dans ce cours, en cas de valeur absente ou invalide, le traitement affiche « donnée à vérifier », ne fabrique pas de température et transmet l’état connu avec son statut. La conduite matérielle réelle en cas de coupure dépendrait d’exigences de sécurité absentes du modèle.

À retenir. Initialiser une fois, traiter à chaque événement, puis conserver l’état entre deux événements évite de confondre mémoire et nouvelle mesure.

Étape 3

Deux seuils évitent les oscillations inutiles

Avec un seul seuil à 28 °C, une règle trop courte telle que « si T ≥ 28, marche ; sinon, arrêt » perd la mémoire. Après un démarrage à 28 °C, une mesure de 27 °C arrêterait aussitôt la ventilation, puis 28 °C la redémarrerait. De petites variations autour du même seuil produiraient donc des changements répétés d’état. Le problème n’est pas le mot if : c’est le else qui impose « arrêt » alors que le modèle ne le demande pas.

L’hystérésis introduit une zone de conservation. À 28 °C ou plus, on passe à « marche ». À 24 °C ou moins, on passe à « arrêt ». Pour 25, 26 ou 27 °C, l’état précédent est gardé. La largeur de la zone vaut 28 − 24 = 4 °C. Cette valeur est un paramètre fictif choisi pour rendre la trace lisible ; elle ne règle aucune installation réelle.

La table doit toujours indiquer l’état avant la décision et l’état après. Sans la colonne « avant », on ne peut pas justifier une ligne à 26 °C ou 27 °C : la température seule ne suffit pas dans la zone intermédiaire.

Exécuter la trace avec l’abonnement · Me connecter

À retenir. Dans la zone 24 < T < 28, une condition correcte conserve l’état ; un else qui arrête systématiquement détruit cette mémoire.

Étape 4

Répéter le même traitement dans une boucle d’événements

Les neuf lignes de mesure ne demandent pas neuf programmes différents. La boucle d’événements répète : attendre une nouvelle mesure, vérifier qu’elle est présente et valide, appliquer la règle à deux seuils, enregistrer la trace puis préparer l’affichage. Le nombre de répétitions vient des événements reçus, pas d’une supposition que toutes les mesures seront identiques.

On peut représenter la démarche par des phrases ordonnées : au démarrage, mettre étatVentilation à arrêt ; tant qu’un événement de mesure arrive, vérifier le message ; si T ≥ 28, mettre marche ; sinon si T ≤ 24, mettre arrêt ; sinon garder l’état ; enfin afficher T, l’état et le statut de la donnée. La boucle ne transforme pas le mot « tant que » en une machine réelle : elle explique l’ordre des opérations dans le modèle.

Une trace aide à chercher une erreur. Si une ligne à 25 °C après « marche » donne « arrêt », on relit la condition intermédiaire et la valeur de l’état avant. Si T est absente, on ne la compare pas à 24 ou 28. Tester les deux frontières, une valeur entre les seuils et une valeur absente est plus informatif que tester seulement 30 °C.

À retenir. Une boucle réutilise la même règle pour chaque événement, et une trace relie chaque résultat aux données qui l’expliquent.

Étape 5

Faire communiquer deux objets avec un contrat lisible

Dans ce modèle, l’objet 1 est le capteur de la station et l’objet 2 est l’unité de traitement. Le capteur ne décide pas à la place de l’unité : il émet un message de mesure. L’unité lit ce message, applique la règle, puis émet un message de commande vers la ventilation et un état vers l’interface. Cette chaîne relie acquisition, traitement, action et affichage sans les confondre.

Le message de mesure fictif doit nommer son émetteur « capteur-air-01 », son destinataire « unite-traitement-01 », son type « temperature », son unité « °C », sa date, sa valeur et sa validité. L’unité répond par un accusé de réception, noté ack, pour signaler qu’elle a reçu un message précis. En cas de coupure ou d’absence d’ack, le modèle indique « communication à vérifier » : il ne prétend ni avoir reçu une valeur, ni connaître la décision matérielle effectivement exécutée.

Cette liste est un contrat de classe entre deux objets précis, pas un protocole universel d’objets connectés. Elle permet de poser des questions simples : qui a envoyé quoi, à qui, avec quelle unité, à quel moment, et le message a-t-il été accepté ? Des sujets comme chiffrement, réseau radio, adresses internet ou pilotage d’un bâtiment dépassent ce modèle.

À retenir. Un message utile associe une valeur à son origine, son unité, sa date et son statut ; une absence d’information ne devient pas une donnée.

Étape 6

Tester une décision et annoncer sa limite

Un bon jeu d’essais couvre des cas qui pourraient se tromper : 24 °C, 28 °C, une valeur entre les deux avec état avant arrêt, la même valeur avec état avant marche, un message invalide et une coupure sans ack. Les résultats attendus sont écrits avant l’essai. On compare ensuite attendu et observé dans le simulateur, puis on corrige une condition ou une variable si une ligne diffère.

Un contrôle écrit peut vérifier le raisonnement sur une nouvelle trace. Il ne mesure pas la fiabilité d’un capteur, la qualité de l’air, la sécurité d’un câblage, ni la réussite d’un montage. Une grille de réponse ouverte permet de comparer deux programmes et de justifier le rôle de l’état ; elle n’attribue pas automatiquement une note à une rédaction.

Le prochain travail matériel, s’il est retenu par l’enseignant, demanderait un équipement adapté, des règles de sécurité, des mesures réelles et une validation humaine. Ici, la réussite prouvée est plus modeste et précise : lire une trace, corriger une règle qui perd la mémoire et expliquer un échange de données fictif.

À retenir. Tester un modèle aux frontières et aux erreurs de communication vérifie sa logique dans ce périmètre, pas un objet réel.