KVB

Dans le but de fabriquer, pour la simulation, un dispositif de sécurité ferroviaire, le KVB (Contrôle Automatique de Vitesse, avec un K à la place du C), j'ai du développer les deux logiciels: côté PC (et simulateur) et côté boitier (Arduino).

Pour la partie création (design, impression 3D, électronique, assemblage), je vous revois vers l'article dédié sur mon blog.

Photo de l'assemblage terminé, le boitier est entièrement designé et imprimé en 3D. Je n'utilise plus ce boitier exactement, j'ai réussi à trouver un vrai boitier de KVB.

Photo du "vrai" KVB fonctionnel

L'ancien modèle utilisait un STM32F103C8T6, alias le STM32 le moins cher du marché, qui coûtait 1€60 (avec frais de port !) à l'époque. Cependant, la pandémie de COVID-19 et les pénuries qui ont suivi ont particulièrement touché ST Microelectronics. Les puces ont donc augmenté de prix. Là où une devboard coûte maintenant environ 3€ (avec frais de ports), le prix avait explosé jusqu'à presque 6€/unité, en juillet 2021.

J'ai donc choisi de repartir sur une base bien connue: l'Arduino Mega 2560. Cela m'a permis de réduire le coût de production, et de simplifier le développement.

Partie Arduino

Pour la version "2" projet, j'ai choisi de me compliquer la vie, notamment pour le défi technique: au lieu de simplement envoyer objet JSON sérialisé en série, j'ai choisi de faire un protocole binaire. Cela m'a permis de réduire la taille des messages, et donc de réduire le temps de transmission. Cependant, il n'y a pas que des avantages: le débogage est plus compliqué, le code est plus difficile à écrire, et il faut vraiment faire attention à la synchronisation.

Ce fut une expérience très enrichissante, mais je ne sais pas si le protocole binaire est vraiment nécessaire. Cela dit, je suis très content du résultat, et je suis très fier de mon code.

Le code est disponible sur mon GitHub.

Librairies

J'ai utilisé plusieurs librairies pour ce projet:

• AceTMI et AceSegment pour l'affichage sur les 7 segments, qui utilisent des afficheurs TM1637.
• Bounce2 pour les boutons.

Protocole binaire customisé

Chaque trame est composée de 4 octets:

• Le premier octet est un header, est toujours 0x23. Cela permet de "synchroniser" la communication.
• Le second octet est un octet qui indique quelle est le genre de données (état des lampes, boutons appuyés, etc).
• Le troisième octet est l'octet d'information en sois. Cela signifie qu'on ne transmet qu'un seul octet "utile"
• Le quatrième octet est un checksum, qui permet de vérifier que la trame n'a pas été corrompue pendant la transmission. Ce checksum est simplement la somme des 3 premiers octets.

Si une trame correcte est reçue, on envoie un ACK (0x24) en retour. Si une trame incorrecte est reçue, on ne répond pas. Cela a l'inconvénient de ne pas permettre de savoir si la trame a été reçue correctement, mais surtout: on ne peut que difficilement savoir si le KVB est désynchronisé avec le PC (ou l'inverse !). En théorie, cela ne peut jamais arriver, mais ce n'est pas du tout le cas en pratique.

L'efficacité du protocole est donc de 25%, mais cela ne me dérange pas: le KVB n'a pas besoin de beaucoup de données, et le temps de transmission est très court.

Partie PC

Train Simulator ne fonctionnant que sous Windows, j'ai donc fait le choix d'un développement en C++ et une application console. Le code est disponible sur mon GitHub.

J'ai choisi de découper le code en plusieurs projets (solutions) pour plus de clarté:

• RailDriverLib est une librairie qui permet de communiquer avec Train Simulator. Elle expose l'API de Train Simulator, et permet de communiquer avec le simulateur.
  • RailDriverClient est une application de test pour la librairie RailDriverLib. Elle permet de tester les fonctionnalités de la librairie, et de voir si elle fonctionne correctement.
• KVBProtocolLib est une librairie qui permet de communiquer avec le KVB. Elle expose une API pour communiquer avec le KVB, et permet de communiquer avec le KVB.
• KVBProtocolClient est une application de test pour la librairie KVBProtocolLib. Elle permet de tester la communication avec le KVB.
• KVBClient est l'application principale. Elle utilise les deux librairies pour communiquer avec le KVB et Train Simulator.

J'ai choisi de découper le code en plusieurs projets pour plus de clarté, et pour pouvoir réutiliser les librairies dans d'autres projets, même si je doute que cela arrive un jour. Le code est sous licence Unlicense, donc vous pouvez l'utiliser comme bon vous semble.

Gestion du fichier de configuration

J'ai choisi de stocker la configuration dans un fichier INI: ils sont supportés nativement par Windows, et sont très simples à manipuler. Cependant, ce sont des méthodes "C-style" qui nécessitent de passer un tableau.

Application Qt

Un des avantage conséquent d'un simple protocole en texte est le debug: on peut voir ce qui est envoyé et reçu avec un simple terminal série. Cependant, cela n'est pas possible avec un protocole binaire. J'ai donc choisi de faire une application Qt pour pouvoir voir ce qui est envoyé et reçu.

J'ai utilisé Qt avec les .ui (avec Qt Creator), car je n'ai pas besoin de faire une application très complexe.

Conclusion

Ce projet a été très enrichissant, et m'a permis de découvrir de nouvelles choses. J'ai appris à faire un protocole binaire et à découper un projet en plusieurs parties. J'ai aussi appris à utiliser des librairies tierces (AceTMI/AceSegment), et à faire des applications console en C++ pour Windows. Grâce à Qt, j'ai aussi appris à faire des applications graphiques multi-plateformes.