Un outil gratuit pour réconcilier les fichiers d’identifiants RFID

Un lot d’identifiants peut être correct en usine et pourtant inutilisable dans un backend de recharge. La valeur figure parfois dans les deux systèmes, mais un fichier la stocke en hexadécimal et l’autre en décimal. Des zéros initiaux peuvent aussi avoir disparu, ou un lecteur peut avoir inversé l’ordre des octets. Sur plusieurs milliers de lignes, un contrôle visuel détecte rarement ces écarts.

Nous avons donc ajouté un espace de réconciliation à la console d’ingénierie ChargeRFID gratuite. Il compare directement dans le navigateur le fichier de production ou de personnalisation avec un export du backend et explique pourquoi chaque ligne correspond ou reste en exception.

Pourquoi les fichiers ne correspondent pas

Deux identifiants peuvent représenter exactement la même valeur tout en ayant un aspect très différent. Un UID de 7 octets peut être fourni sous la forme de quatorze caractères hexadécimaux, d’un long entier décimal, d’une valeur hexadécimale raccourcie sans zéros initiaux ou d’une chaîne dont les octets sont inversés. Une recherche classique dans un tableur considère ces quatre écritures comme distinctes.

Le problème inverse existe aussi : des doublons paraissent valides jusqu’à ce que deux identifiants sollicitent la même ligne du backend. Identifiants de production absents, tokens obsolètes, caractères invalides et longueurs incorrectes créent d’autres types d’échec.

Ce que contrôle l’outil de réconciliation

Chargez ou collez deux fichiers CSV ou TXT : les données émises par la production et les données importées dans le backend. La console reconnaît les séparateurs courants, suggère la colonne d’identifiant probable et prend en charge les identifiants de 4, 7 et 10 octets. Vous pouvez conserver la détection automatique ou définir explicitement une colonne en HEX ou DEC.

Le moteur classe ensuite les rapprochements dans quatre catégories de preuve :

Tout élément qui ne peut pas être associé de façon sûre reste signalé comme manquant, supplémentaire, en double, invalide ou ambigu. Une même ligne du backend ne peut donc pas valider silencieusement plusieurs lignes de production.

Trois exports pour la recette

La console génère trois fichiers CSV. Le rapport d’exceptions sert de liste de travail. La preuve de correspondance conserve les deux numéros de ligne, les deux valeurs d’origine, la méthode utilisée et l’identifiant hexadécimal canonique. L’import corrigé contient les identifiants de production uniques et valides absents du backend, au format HEX ou DEC et dans l’ordre d’octets choisi.

Les enregistrements supplémentaires du backend ne sont pas supprimés automatiquement. Ils restent en exception, car toute suppression doit relever d’une décision explicite de l’exploitant.

Une procédure de recette pratique

Cette procédure est utile avant une première émission, lors d’une migration de plateforme, après un remplacement massif ou chaque fois qu’un CPO, un eMSP et un fabricant doivent partager une même preuve de livraison et d’enregistrement.

Confidentialité et périmètre technique

L’analyse et la comparaison s’exécutent localement dans le navigateur. ChargeRFID ne téléverse ni ne conserve le contenu des fichiers. L’outil réconcilie des données ; il ne se connecte pas à un lecteur physique ou à un backend de recharge et ne remplace pas un essai de bout en bout avec les identifiants finis.

Ouvrez gratuitement l’outil de réconciliation et chargez l’exemple de vérification inclus. Pour un programme de production, vous pouvez demander des échantillons finis ou nous envoyer le contrat de données à valider.