Mission 02 · Logiciel & industrie
Self-Beton QR
Lire, valider et tracer des QR codes avant de transmettre les données utiles à un automate industriel.
Contexte industriel
Self-Beton QR est un logiciel local de lecture et de validation de QR codes, installé sur plus de 270 bornes à l’international, principalement en France et au Canada. Il intervient dans un projet financièrement important pour le pôle : une erreur ne se limite pas à l’interface, puisqu’elle peut affecter la préparation du béton.
Le logiciel lit le QR code, vérifie son contenu et sa signature, détecte un éventuel doublon, enregistre le traitement puis communique les informations nécessaires à l’automate industriel.
Flux de traitement
Le journal SQLite local conserve notamment le numéro de commande, la station, la date, la recette, la quantité, la signature et un horodatage. Cette persistance permet d’empêcher le retraitement d’une commande déjà consommée, y compris sans service distant permanent.
Mes responsabilités
J’ai développé intégralement Self-Beton QR pendant mon CDD de juillet–août 2025. Pendant l’alternance, je suis revenu sur mon application pour assurer sa maintenance, la faire évoluer et l’adapter aux conditions réelles de déploiement sur les bornes.
J’ai notamment amélioré la validation des données, le journal local, la gestion des doublons, la communication série et la prise en charge de la nouvelle signature QR. J’ai aussi fait évoluer les outils de configuration et de diagnostic, le scanner permanent, les scripts d’installation en ligne et hors ligne, le service systemd et la documentation technique.
Depuis avril, j’assure aussi l’installation du logiciel et la préparation de certains PC servant d’interface avec les automates. Cette responsabilité relie directement le code, le système Linux et le matériel installé.
Architecture technique
Self-Beton QR est une application Python locale qui associe la lecture de QR codes, la validation cryptographique des données, un journal SQLite et une communication série avec l’automate. Son fonctionnement demande de maîtriser à la fois le code Python, la configuration de la machine, les ports série et les scripts d’installation Linux.
Le projet comprend aussi deux modes de lecture distincts : la production passe principalement par une scanette série, tandis qu’un mode webcam existe pour les tests ou les usages alternatifs. La configuration peut être générée soit en ligne de commande, soit par une interface Tkinter, puis l’application est exécutée durablement par un service systemd sur les postes Linux de borne.
Le fichier requirements.txt fixe NumPy 2.2.6, OpenCV 4.12.0.88, PyCryptodome 3.23.0, pySerial 3.5 et pyzbar 0.1.9. OpenCV et pyzbar couvrent la lecture visuelle, PyCryptodome la vérification cryptographique et pySerial la communication avec le matériel. La version mineure de Python n’est pas verrouillée : le script installe le paquet python3 fourni par Ubuntu, choix pratique pour les postes préparés mais moins reproductible qu’une version d’interpréteur explicitement figée.
Diagrammes issus du code
Les figures suivantes présentent le fonctionnement du logiciel, son installation et les essais réalisés avec le matériel.
Vue d’ensemble du logiciel local, des périphériques de lecture, du journal SQLite et du dialogue avec l’automate industriel.
Cette vue montre que Self-Beton QR ne se limite pas à un simple lecteur de QR code. Il se place au centre d’un environnement mêlant opérateur, matériel de lecture, configuration locale, persistance et protocole automate, ce qui explique pourquoi mes interventions ont porté à la fois sur le code, l’installation et les postes de borne.
Flux complet de lecture, validation, contrôle de doublon, journalisation et émission série.
Le flux réel montre que le logiciel filtre tôt les erreurs, isole clairement les doublons et ne transmet une recette à l’automate qu’après validation. Cette représentation synthétise le cœur de l’application : fiabiliser un parcours court mais critique, où une donnée erronée peut avoir un effet direct sur un équipement industriel.
Pour tester les évolutions avant leur installation sur une borne, je disposais au bureau d’un poste dédié permettant de reproduire une partie de l’environnement Self-Beton. Ce poste servait notamment aux essais de démarrage, de communication, de scan et de comportement hors ligne.
Installation Linux, configuration locale et mise en service sur un PC relié à la scanette et à l’automate.
Cette figure relie le développement à la réalité du terrain. Mon travail sur Self-Beton QR comprend l’installation, la génération de configuration, le service systemd, les tests sur PC de borne et la préparation de machines réellement destinées à communiquer avec un automate.
Contraintes et solutions
| Contrainte | Risque | Solution mise en place |
|---|---|---|
| Absence d’Internet | Installation impossible sur site | Bundle et scripts d’installation hors ligne |
| Ports série variables | Mauvais périphérique utilisé | Configuration et chemins persistants /dev/serial/by-id |
| QR déjà traité | Préparation en double | Journal SQLite et signal automate spécifique |
| Automate indisponible | Perte du dialogue | Heartbeat, lecture de réponse et reconnexion |
Stratégie de test
Le bureau dispose d’un scanner QR miniature, d’un dispositif de test de communication avec l’automate et d’un PC reproduisant la configuration d’une borne. Les tests réalisés couvrent plusieurs niveaux complémentaires.
| Catégorie | Objectif | Matériel ou outil | Résultat attendu |
|---|---|---|---|
| Lecture QR | Vérifier QR valide ou invalide, format, signature, doublon, lecture partielle et répétée. | Scanner QR miniature et QR fictifs. | Accepter uniquement une donnée conforme et non déjà utilisée ; refuser les autres cas sans transmettre une commande incorrecte. |
| Intégration automate | Établir la liaison, envoyer les champs issus du QR, contrôler le format et traiter réponse, coupure et reprise. | Dispositif de test automate, plc_test_cli.py et communication série. | Émettre une trame conforme au code, interpréter la réponse disponible et reprendre après rétablissement. |
| Démarrage et installation | Vérifier session automatique éventuelle, application, services, redémarrage et extinction imprévue. | PC de test sous Ubuntu 24.04.3 Desktop et systemd. | Retrouver un poste fonctionnel après démarrage ou redémarrage. |
| Hors ligne | Installer sans Internet, utiliser les dépendances locales, conserver les informations nécessaires et vérifier la reprise réseau lorsqu’elle existe. | Bundle hors ligne, wheelhouse/paquets et SQLite. | Installer et exécuter l’application sans dépendance à un téléchargement externe. |
| Tests manuels Python | Envoyer plusieurs trames brutes et interpréter les réponses série. | tests/serial_test.py et plc_test_cli.py. | Observer l’envoi, la réponse ou l’absence de réponse sans supposer un code d’acquittement non vérifié. |
Tests manuels et automatisation
tests/serial_test.py est un script de test manuel qui envoie une série de trames et affiche les réponses interprétées. plc_test_cli.py est un outil de diagnostic en ligne de commande pour l’initialisation, les doublons, les trames brutes et les données issues d’un QR code. Ils soutiennent les tests de communication série et d’intégration avec l’automate.
J’ai réalisé de nombreux essais avec le scanner, le dispositif automate et un PC représentatif. Ils couvrent la lecture, les erreurs, les doublons, les coupures, le redémarrage, l’installation et le fonctionnement hors ligne. La validation repose encore sur ces scénarios manuels et sur les outils de diagnostic ; une suite automatisée avec assertions, mocks et fixtures reste à mettre en place.