Contexte du projet
L’application de supervision existante pilotait dix régulateurs de température, des obturateurs, une caméra industrielle, des scripts de procédé et les enregistrements d’essai. Le diagnostic terrain a révélé des données thermiques discontinues, des arrêts silencieux de stockage et un retard d’aperçu, des écritures signalées réussies sans modification de l’équipement, une valeur Ramp Rate affichée avant lecture matérielle et une échelle de température incohérente.
Objectif d’ingénierie
Conserver les intégrations éprouvées tout en isolant les chemins les plus risqués : tracer les écritures, synchroniser les paramètres dans les deux sens, relancer acquisition et stockage, unifier les unités, produire un installateur Release reproductible et définir les essais restant à effectuer sur le matériel client.
Fiabilité de bout en bout du contrôle et des données
La communication série, l’acquisition caméra, la persistance, l’état de l’interface et le packaging ont été traités comme une chaîne observable unique. Chaque modification répond à un mode de panne et à un résultat vérifiable.
- 01
Référence et collecte des preuves
Figer les versions source et installateur, examiner journaux et SQLite, identifier les limites des équipements et distinguer les défauts observés des hypothèses.
- 02
Acquisition série et relecture
Maintenir l’interrogation PV/SP rapide et lire Ramp Rate dans le registre 0x0023 à faible fréquence, un régulateur toutes les trois secondes.
- 03
Commande vérifiée
Valider une écriture uniquement si la réponse Modbus 0x06 correspond exactement à l’esclave, au registre et à la valeur et si le SP cible est relu ; sinon réessayer ou signaler l’échec.
- 04
Reprise de la chaîne caméra
Surveiller séparément l’arrivée des trames et leur stockage, rouvrir l’acquisition après trois secondes d’arrêt et relancer le stockage si des images arrivent sans fichier.
- 05
Cohérence des données et unités
Utiliser une seule chaîne d’unités, supprimer l’ancien écart d’un facteur dix, conserver les horodatages réels et garder des diagnostics consultables.
- 06
Contrôle Release et recette
Construire le package x64, vérifier les dépendances, consigner versions et SHA-256, conserver le retour arrière et fournir la liste de recette matérielle.
Livrables contrôlés
- Correctif source ciblé
- Correctif de 12 fichiers pour la relecture Ramp Rate, les écritures vérifiées, la reprise caméra, le stockage et les unités.
- Installateur de test client
- Version 1.0.3.20260728 pour Windows x64 avec Qt, pilote SQLite, SDK caméra, configuration équipement et VC Runtime.
- Revue d’architecture et de code
- Revue de la structure, des communications, du traitement des données et des risques P0/P1 prioritaires.
- Dossier de build et package
- Sortie Release, inventaire des dépendances, métadonnées, nombre de fichiers et empreintes SHA-256.
- Liste de recette terrain
- Relecture équipement, écritures répétées, endurance caméra, reconnexion, continuité de stockage et unités.
Preuves d’ingénierie
Chaque preuve précise l’artefact, la portée et la limite. Elle ne remplace pas la recette sur le matériel client.
Revue d’architecture
83 fichiers source et en-têtes C++ ; environ 36 200 lignes physiques examinées.La revue a identifié les risques P0/P1 et les responsabilités. Ce n’est pas une certification logicielle.
Diagnostic terrain de la version précédente
Intervalle médian d’environ 125 ms ; 99 % à 130 ms ou moins ; interruptions de 562,921 s et 17,306 s ; 1 486 images sans doublon consécutif.Ces mesures décrivent la panne antérieure, pas l’endurance de la version 1.0.3.
Build Release
Build réussi ; exécutable de 1 727 488 octets ; SHA-256 CB4A11624F97BABC892399DF0975059408AA62CA4502622BBEE84D058D2FD5FD.Il confirme l’artefact reproductible et les vérifications statiques inspectées.
Audit de l’installateur
78 fichiers totalisant 66 292 772 octets ; aucune DLL Qt Debug ; dépendances Qt, SQLite, SDK caméra, VC Runtime et fichiers équipement présents.SHA-256 : 6908988BF48670AC25A9F004BC77070960AE55D19D35AB51212EBDD64B4321A9. Le package n’est pas signé.
État de validation
- Vérifications statiques réussies pour la lecture Ramp Rate, l’écriture avec relecture, les watchdogs d’acquisition et de stockage et la suppression de l’ancienne échelle.
- CTest s’est terminé correctement mais n’a trouvé aucun test ; ce n’est pas une preuve de test fonctionnel.
- ProductVersion, FileVersion, contenu, dépendances et valeurs SHA-256 ont été contrôlés.
- À la date des preuves, la version 1.0.3 n’avait pas été installée ni exécutée sur l’instrument client ; la recette équipement et endurance reste à faire.
Périmètre et limites
Le résultat publié est un installateur Windows de test client accompagné des preuves source, build, package et revue statique. Il n’atteste pas une recette finale sur site, une signature de production, une précision métrologique certifiée, un stockage continu de longue durée ni le fonctionnement avec toute combinaison de régulateurs et de caméras. La recette finale exige la relecture réelle de Ramp Rate, la concordance avec l’afficheur lors d’écritures répétées, au moins deux heures de caméra sans interruption inexpliquée, des essais de déconnexion/reconnexion et la vérification des unités sur l’instrument.