Chaîne d’information : du capteur à la donnée utilisable

1. Le but. Retrouver la température à partir d’un code, sans transformer un défaut en mesure de zéro.

2. Vérifier avant de convertir. Le domaine autorisé est de 0 à 4 095. La sentinelle FFFF indique un défaut ; 4 096 est hors domaine. Ces deux cas reçoivent un statut invalide.

3. Choisir l’échelle. Le dossier fournit c = 81,9 T, donc T = c/81,9. La forme équivalente T = 50 × c/4 095 permet de voir les deux extrémités : code 0 → 0 °C et code 4 095 → 50 °C.

4. Appliquer au code valide 2 048. Le calcul 50 × 2 048/4 095 donne environ 25,006 °C. C’est bien proche du milieu de la plage, ce qui contrôle l’ordre de grandeur.

5. Distinguer pas et incertitude. Un pas vaut 50/4 095 ≈ 0,01221 °C/code. Il ne remplace pas l’incertitude fictive de 0,3 °C ; afficher de nombreuses décimales ne crée pas de précision physique.

6. Vérifier les autres voies avec leurs propres unités. Pour H, 4 095 donne 100 %HR et le pas vaut 0,02442 %HR/code. Pour E, 1 024 donne environ 500,122 lx, 0 donne 0 lx et le pas vaut 0,48840 lx/code. Ce sont des conversions du banc synthétique, pas des mesures sur un capteur réel.

Erreur à éviter. une erreur de capteur est remplacée par 0 °C et entre dans la moyenne

Pourquoi elle échoue. Valeur physique et état de validité partagent le même nombre. Une panne devient indiscernable d'une mesure réelle à zéro et contamine les calculs.

Comment la reprendre. Transporter un champ de validité ou une erreur explicite. Les agrégations excluent les valeurs invalides et comptent séparément leur fréquence.

La charge utile d'un jeu vaut 3 × 2 = 6 octets. À deux jeux par seconde, la charge utile vaut 12 octets par seconde, soit 720 octets par minute. Ce calcul n'inclut ni en-tête, ni contrôle, ni retransmission. Il suppose aussi que les trois grandeurs sont synchrones et que chaque code a une taille fixe. La prochaine étape ajoute quatre octets de service par trame, portant le trafic brut nominal à 20 octets par seconde avant les couches inférieures. Périodes 2 s,0,5 s,0,1 s ; nombres de jeux 30,120,600. Charges utiles 8 bits : 90,360,1800 octets/min ; 12 bits : 180,720,3600 octets/min. Les pas de température sont 50/255≈0,1961 °C et 50/4095≈0,01221 °C. Seules 2 et 10 Hz satisfont la cadence demandée ; 2 Hz consomme moins de trafic dans ce besoin borné.12 bits affinent le pas sans réduire l’incertitude 0,3 °C ni garantir une meilleure exactitude.

Erreur à éviter. 2 Hz sont interprétés comme une mesure toutes les deux secondes

Pourquoi elle échoue. Fréquence et période ont été confondues. La période est l'inverse de la fréquence : 2 s⁻¹ donnent 0,5 s entre deux jeux. Cette inversion fausse ensuite volume, tampon et latence attendue.

Comment la reprendre. Écrire f = 2 Hz puis T = 1/f = 0,5 s avec les unités. Vérifier qu'en dix secondes vingt jeux sont attendus.

La variante tronquée a neuf octets : refus longueur avant tout index. Le nominal en a dix ;0x11 donne version 1/type 1, la longueur utile est 6. La somme des neuf premiers octets vaut 48, donc 0x30 : elle correspond au contrôle reçu. Les paires 08 00 donnent 2048 chacune ; dans le modèle fourni cela correspond à 25,006 °C,50,012 %HR et 1000,244 lx environ. Le jeu est valide, séquence 1, et son délai de disponibilité vaut 0,20 s sur l’horloge du banc. Ce résultat ne prouve ni identité de l’émetteur ni confidentialité. Le suivi de séquence vient après validation, dans une fenêtre sans rebouclage ; il ne transforme pas un doublon ou retard en nouvelle mesure.

Erreur à éviter. le programme décode trois entiers avant de vérifier que la charge contient bien six octets

Pourquoi elle échoue. La confiance dans le format précède la validation de longueur. Une trame tronquée peut provoquer un dépassement ou mélanger des champs, puis faire passer une structure invalide pour une mesure plausible.

Comment la reprendre. Vérifier taille minimale, champs de structure et longueur effective avant tout décodage de la charge. Tester trame vide, tronquée, version inconnue et contrôle faux.

1. Le but. Distinguer le trafic complet, les données utiles et le temps de transmission. Commencer par le format A : 10 octets par trame, dont 6 utiles, à 2 trames/s.

2. Convertir les octets en bits. Une trame contient 10 × 8 = 80 bits. Le débit brut vaut donc 80 × 2 = 160 bit/s. La multiplication des unités donne bien bits par seconde.

3. Compter seulement la charge utile. Le débit utile vaut 6 × 8 × 2 = 96 bit/s. Le rapport utile/brut est 96/160 = 0,60, soit 60 %. L’en-tête n’a pas disparu : il occupe le reste.

4. Tester le lien et le tampon dans leurs périmètres. Sur 1 000 bit/s, 80 bits occupent idéalement 0,08 s et le trafic A représente 16 % du débit du support. Sans sortie pendant dix secondes, le tampon reçoit 2 × 10 × 10 = 200 octets.

5. Comparer sans changer les hypothèses. À 2 Hz, B demande 224 bit/s, dont 96 utiles : ratio 0,42857, occupation 22,4 % et tampon 280 octets. C demande 128 bit/s : ratio 0,75, occupation 12,8 % et tampon 160 octets, mais son contrat incomplet l’élimine avant classement.

6. Faire varier la cadence. À 4 Hz, débits, occupations et tampons doublent, pas les ratios. Une seule copie supplémentaire pour 2 % des trames multiplie le trafic moyen transmis par 1,02 : A passe de 160 à 163,2 bit/s sans créer davantage de données utiles. Ces calculs applicatifs ne prouvent pas la latence totale.

Erreur à éviter. 10 octets à 2 Hz sont annoncés comme 20 bit/s

Pourquoi elle échoue. Octets et bits ont été confondus. Le facteur huit manque, ce qui sous-estime le débit d'un ordre constant et contamine le calcul de temps d'occupation.

Comment la reprendre. Écrire 10 octets/trame × 8 bits/octet × 2 trames/s et simplifier les unités jusqu'à bit/s.

Toutes les valeurs fournies sont inférieures à 250 ms, et la moyenne est proche de 190 ms. La marge minimale observée vaut 49 ms au point de 201 ms. La revue peut conclure « satisfait pour ces six valeurs synthétiques », pas « garanti ». Elle demande un jeu plus long, des conditions de charge et la contribution de synchronisation pour caractériser une limite. Le maximum reste visible car l'exigence porte sur chaque jeu, tandis que moyenne et incertitude servent à comparer le modèle de latence.

Erreur à éviter. le taux de jeux inutilisables à échéance est calculé par invalides divisés par événements reçus

Pourquoi elle échoue. Ce calcul oublie les jeux jamais reçus et les retards, tandis que les doublons gonflent son dénominateur. Un événement invalide peut aussi être suivi d'une réception valide à temps. Il faut raisonner sur les jeux attendus et leurs échéances.

Comment la reprendre. Comparer les séquences attendues aux jeux valides avant leur échéance. Diviser les jeux inutilisables à temps par les jeux attendus ; conserver séparément événements invalides, doublons, tardifs et absences totales de réception.

A possède la version connue, l’unité attendue, une validité vraie et des temps ordonnés. Son âge vaut 1,20−1,00=0,20 s, sous 0,75 s : la valeur est utilisable dans ce test. B est refusé dès la version 2, sans deviner sa conversion, même si 25 semble plausible. C passe version/unité/validité, mais son âge vaut 2,00−1,00=1,00 s : état dégradé pour donnée ancienne. Sa validation à 1,18 s ne remet pas l’âge à zéro. Les trois décisions citent chacune un critère observable. L’historique peut conserver C avec son âge, jamais le présenter comme mesure courante ; aucun actionneur ni personne réelle n’est impliqué.

Erreur à éviter. le programme réutilise indéfiniment la dernière mesure valide après perte de communication

Pourquoi elle échoue. Aucun âge maximal n'est associé à la valeur. Une donnée ancienne conserve l'apparence d'une mesure actuelle et peut masquer une panne durable.

Comment la reprendre. Calculer l'âge au moment de la décision, comparer à une exigence de fraîcheur et basculer vers l'état dégradé documenté après le seuil.