Analyser et tester un éclairage automatique

Étape 1

Du besoin à une exigence vérifiable

L'objet étudié est un éclairage automatique fictif pour un espace scolaire. Le besoin est de rendre une zone visible lorsqu'elle est utilisée. Une solution possible associe un capteur de présence, un capteur de lumière, une carte de commande et une lampe. Le besoin ne décrit pas déjà la solution : une autre organisation peut répondre au même usage.

Une fonction décrit ce que fait le système : détecter une présence, comparer un niveau de lumière, commander l'éclairage. Un constituant est un élément matériel ou logiciel qui assure une fonction. Plusieurs technologies peuvent assurer la même fonction ; dire « capteur » ne suffit donc pas à expliquer ce qui est acquis ou comment il sera utilisé.

Une exigence rend une attente contrôlable. Dans notre modèle, la lampe doit être allumée si une présence est détectée et si la valeur de luminosité est strictement inférieure à 120. Elle doit être éteinte dans tous les autres cas. Le nombre 120 est un seuil fictif de l'exercice, exprimé dans une unité arbitraire du capteur ; ce n'est ni une norme d'éclairage ni une mesure en lux.

Présence vaut 0 ou 1 : c’est l’état « absence ou présence détectée », pas un nombre de personnes. La luminosité est un entier de 0 à 1 000 dans l’unité arbitraire du modèle. À 120, la sortie attendue est éteinte ; à 119 avec une présence, elle devient allumée. Cette différence d’une unité départage < et ≤.

Un objet n'est pas souhaitable parce qu'il est automatique. Il faut comparer le service rendu, la consommation, le coût, la facilité d'entretien et les effets sur les usagers. Un capteur défaillant ou un seuil mal choisi peut rendre le système moins utile. Aucun calcul d'économie réelle n'est déduit ici de la seule simulation.

À retenir. Besoin, exigence, fonction et solution sont liés, mais ne désignent pas la même chose.

Étape 2

Suivre les informations et les conversions d'énergie

La chaîne d'information acquiert des données, les traite et communique une commande. Ici, les deux capteurs acquièrent présence et luminosité. La carte applique la condition logique. Un signal de commande est transmis à l'élément qui distribue l'énergie à la lampe. La sortie informationnelle n'est pas l'énergie nécessaire à l'éclairage.

La chaîne d'énergie reçoit une énergie, la distribue et la convertit pour assurer l'action. Dans notre schéma simplifié, une alimentation fournit l'énergie électrique, un interrupteur commandé permet ou interrompt son passage, et la lampe convertit une partie de cette énergie en lumière, avec des pertes notamment thermiques. L'action utile est d'éclairer la zone.

La flèche d'information entre la carte et l'interrupteur représente une commande. Les flèches d'énergie vers la lampe représentent un transfert d'énergie. Mélanger les deux conduit à croire que le capteur alimente la lampe. Un capteur peut consommer lui-même de l'énergie, mais sa fonction dans cette chaîne est de fournir une donnée.

Un schéma-blocs sélectionne les fonctions pertinentes, pas tous les fils ni toutes les pièces. On peut le compléter avec les entrées, les sorties et la nature des flux. On ne le confond pas avec un schéma électrique de montage. Les protections, tensions et caractéristiques réelles doivent être définies par le professeur ou le responsable du projet avant toute réalisation.

Dans un portail motorisé, un moteur convertit l’énergie électrique en mouvement au lieu de produire l’éclairage. Les fonctions d’acquisition et de traitement restent utiles, mais l’action et les contraintes changent. Une même structure d’analyse aide ainsi à comparer des objets différents ; elle ne remplace pas les protections d’un objet réel.

Agrandir l’image

Redessine les deux chaînes et légende séparément le flux d'information et le flux d'énergie.

À retenir. Le traitement décide d'une commande ; la chaîne d'énergie fournit et convertit l'énergie de l'action.

Étape 3

Traduire et tester une condition logique

L'algorithme s'écrit en langage naturel : lire présence et luminosité ; si présence vaut 1 ET luminosité est inférieure à 120, commander l'allumage ; sinon commander l'extinction ; recommencer à la lecture suivante. Une boucle permet de réexaminer la situation au lieu de garder une décision ancienne lorsque les entrées changent.

ET exige que les deux conditions soient vraies. Avec présence = 1 et luminosité = 80, la sortie est allumée. Avec présence = 0 et luminosité = 80, elle est éteinte. Avec présence = 1 et luminosité = 200, elle est aussi éteinte. Remplacer ET par OU autoriserait un allumage quand une seule condition suffit, ce qui ne respecte pas l'exigence.

Le laboratoire numérique compare trois règles sur les mêmes entrées. La règle attendue utilise ET et < 120. La variante OU peut allumer sans présence ou lorsque la lumière suffit ; la variante ≤ inclut le cas d’égalité que l’exigence exclut. Une sortie correcte sur un cas ne rend pas toute la règle conforme : les cas qui départagent les règles sont particulièrement utiles.

Pour un programme en blocs ou en code, les noms de variables doivent garder le même sens du début à la fin. Un état d'entrée 1 représente ici une présence détectée, pas un nombre de personnes. Les lectures se font à chaque tour de boucle. La sortie doit être définie aussi dans le cas sinon, pour ne pas laisser la lampe dans un ancien état.

Le tableau donne les six prévisions autour du seuil. Avec une présence, 119, 120 et 121 distinguent dessous, égalité et dessus. Sans présence, les trois sorties restent éteintes. Le laboratoire permet de comparer ces prévisions à une règle choisie ; il n’exécute pas un programme libre. Une temporisation demanderait en plus de mémoriser un état et de suivre le temps, absents de ce modèle instantané.

Essayer le modèle avec l’abonnement · Déjà abonné ? Connecte-toi.

À retenir. Teste les cas ordinaires et les frontières ; ET n'a pas le même sens que OU.

Étape 4

Passer du modèle aux essais d'un projet

Le modèle suppose des entrées instantanées et fiables. Un système réel peut subir un délai, une mesure fluctuante, une absence de détection ou une panne. La simulation ne mesure ni la qualité d'un capteur, ni une consommation, ni le confort visuel. On la complète par des essais réels organisés dans l'environnement scolaire adapté.

Un essai compare une sortie attendue à une sortie obtenue dans des conditions précises. Si le modèle allume à (1,119), ce cas respecte l’exigence. Si une autre règle allume à (1,120), l’écart est localisé à la frontière. Le résultat du laboratoire concerne un programme numérique prédéfini ; tester la qualité d’un capteur ou le confort visuel demanderait d’autres observations.

En projet collectif, on répartit des responsabilités telles qu'analyse du besoin, programmation, représentation et tests, sans réserver une fonction à un genre ou à un seul élève. La trace commune doit permettre à chacun d'expliquer la décision et de reprendre un essai. Une présentation finale rend compte du besoin, des choix, des résultats et des améliorations possibles.

Une démarche de maintenance commence par un constat et des hypothèses, pas par le démontage au hasard. Si la lampe ne s'allume jamais dans le modèle, on peut d'abord vérifier les valeurs d'entrée et la condition. Une réparation matérielle, un raccordement électrique ou l'emploi d'outils relève de consignes et d'un encadrement : ce cours ne demande aucune intervention sur une installation domestique.

Une amélioration doit être liée à une difficulté observée. Pour éviter un changement trop fréquent autour d’un seuil, on pourrait étudier une temporisation ou deux seuils distincts ; cela demanderait un autre modèle et de nouveaux tests. La commande instantanée étudiée ici sert à comprendre les conditions logiques. Elle ne mesure ni économie d’énergie ni durée de vie d’un éclairage réel.

À retenir. Un essai numérique valide un comportement du modèle, pas la sécurité ni la performance d'un objet fabriqué.

Étape 5

Lire un journal d’essais et corriger une règle

Le journal ci-dessous vient d’un programme fictif différent de la règle attendue. Il annonce allumée à (1,120), alors que l’exigence donne éteinte. Cette comparaison porte sur des résultats fournis : elle permet de chercher une erreur dans une règle, sans supposer qu’un capteur aurait été mesuré ou qu’un prototype aurait été réalisé.

Le tableau présente les résultats fictifs d’un programme qui n’est pas celui du simulateur du cours. Compare chaque ligne à l’exigence présence = 1 ET luminosité < 120. Trois lignes sont conformes ; à 120, avec une présence, le journal donne allumée alors que l’exigence attend éteinte. Cet écart fait suspecter une comparaison qui inclut l’égalité. Il ne prouve pas une panne de capteur : aucune mesure matérielle n’est disponible.

Remplacer ≤ par < corrige le cas d’égalité dans cette hypothèse. Il reste à contrôler les autres situations : 119 avec présence doit toujours allumer, 121 doit éteindre, et une absence doit aussi éteindre. Une correction utile résout le cas en erreur tout en conservant les comportements déjà attendus.

Une exigence d’usage peut demander autre chose qu’une règle logique, par exemple une commande facile à repérer. Il faut alors un indicateur et un essai adaptés à cette exigence. Dans un projet encadré, prépare qui rédige la règle, qui vérifie le tableau et qui présente les écarts ; chaque membre doit pouvoir expliquer le choix. Le résultat de ce dossier numérique ne certifie ni l’ergonomie, ni la sécurité électrique, ni le travail collectif réel.

À retenir. Une correction se justifie par l’exigence et se contrôle avec le cas en erreur et des cas de non-régression.