Protocole LSV2 : Le langage télégramme natif d’Heidenhain

Examinez une session TNC connectée au niveau de la trame brute, et il ne reste presque rien : un champ de longueur codé sur quatre octets, une commande ASCII de quatre caractères et la charge utile associée. Aucun document JSON complexe, aucune arborescence XML verbeuse, aucun en-tête HTTP standard. Lorsque l’on pénètre dans l’univers de communication des commandes numériques Heidenhain, cette architecture épurée et efficace correspond au protocole LSV2.

Sa sobriété peut tromper. LSV2 est un protocole de télégrammes binaire basé sur TCP, conçu pour les commandes Heidenhain TNC afin d’assurer le transfert bidirectionnel de programmes d’usinage, la surveillance des états de fonctionnement, la lecture des coordonnées d’axes et l’interrogation de la mémoire de l’automate (PLC). Heidenhain n’a jamais diffusé de spécification publique ouverte. La compréhension de son fonctionnement s’est construite par analyse de paquets, étude des codes d’erreur et observation logicielle d’utilitaires tels que TNCremo. Ce dossier technique détaille ce protocole avec une rigueur d’ingénierie.^[1][2]

LSV2 en un coup d’œil

Périmètre et rôle fonctionnel de LSV2

LSV2 constitue le protocole de liaison de base reliant les commandes Heidenhain aux infrastructures d’atelier. Lorsqu’un poste de programmation utilise TNCremo pour téléverser un programme pièce, lister une arborescence de disques ou relever l’état de la machine, il émet des télégrammes LSV2 à travers une socket TCP. Dans les ateliers, on confond fréquemment LSV2 et « Heidenhain DNC ». Il convient de bien distinguer ces concepts : DNC désigne une gamme d’outils et une architecture applicative, tandis que LSV2 est le protocole de transport binaire qui achemine les requêtes.^[1][6]

De même, assimiler LSV2 à MTConnect constitue une erreur méthodologique. MTConnect est un dictionnaire standardisé ouvert, purement passif, reposant sur XML/JSON et les requêtes HTTP REST. LSV2 est à l’inverse un protocole propriétaire avec état, conçu pour Heidenhain, disposant de fonctions de transfert de fichiers et d’écriture active. MTConnect harmonise les indicateurs à l’échelle de l’usine ; LSV2 pénètre directement dans les registres internes du système.^[1]

En-tête de huit octets et commandes à quatre caractères

La structure des messages LSV2 se distingue par sa compacité. Chaque télégramme s’ouvre par un en-tête fixe de huit octets : un entier 32 bits gros-boutiste (big-endian) précisant la longueur de la charge utile, suivi d’une commande ASCII de quatre caractères. Cette longueur exclut systématiquement les quatre octets de commande. Les commandes adoptent une syntaxe mnémotechnique constante : A_LG, R_RI, S_RI, T_OK ou T_ER.^[2]

Requête :  [len:u32 BE] [A_LG] [identifiant utilisateur + 0x00]
Réponse :  [len:u32 BE] [T_OK] [données optionnelles]

Requête :  [len:u32 BE] [R_RI] [sous-identifiant:u16 BE]
Réponse :  [len:u32 BE] [S_RI] [données d'état renvoyées]

La phase d’ouverture de session propose deux modalités : A_LG accepte un nom d’utilisateur sans mot de passe, tandis que P_LG requiert une authentification par mot de passe. Dans les environnements d’émulation avec TNCremoNT, on rencontre fréquemment des chaînes de test comme PASSWORD ou REMOTE ; ces valeurs ne constituent pas des mécanismes de protection adaptés à la production réelle. Une connexion valide renvoie T_OK ; un rejet renvoie T_ER avec un code numérique d’erreur.^[1][2]

Pour le transfert de fichiers, LSV2 prend en charge deux modes : ASCII et binaire. Le mode binaire s’active en adjoignant l’octet 0x01 immédiatement après le nom de fichier. Ce paramètre est essentiel : transférer des fichiers binaires sous les conventions ASCII altère l’intégrité des données dans la commande. Les chemins doivent également respecter les spécifications internes d’Heidenhain (par exemple TNC:\nc_prog\) ; l’envoi de chemins locaux Windows ou Linux provoque un échec immédiat.^[2]

La gestion des anomalies est segmentée par plages numériques. Selon la cartographie établie par pyLSV2, les codes 0 à 19 correspondent aux pannes de transmission et de liaison, les codes 20 à 99 couvrent les erreurs de syntaxe et de télégramme, et la plage 100 à 200 traite des incidents de transfert par blocs. À la réception de T_ER, consigner le code numérique précis est indispensable pour distinguer une rupture de communication d’un verrouillage de fichier ou d’un refus d’accès.^[3]

La commande R_RI : extraction des indicateurs en cours

Plutôt que d’émettre un flux continu indiscriminé, LSV2 extrait les indicateurs d’état au moyen de la commande R_RI (Read Running Info). L’application cliente transmet un sous-identifiant codé sur 16 bits en big-endian, auquel la commande numérique répond par un télégramme S_RI. Quatre sous-identifiants s’avèrent prépondérants pour la supervision :^[1][2]

Le sous-identifiant 25 impose une mise à l’échelle précise : la valeur brute 10000 correspond à 100 %. Le système exprime les réglages des potentiomètres au centième de pour cent. Exploiter ces entiers sans conversion fausse les indicateurs d’un facteur 100. Les bibliothèques appliquent des logiques différentes : certaines normalisent la donnée en flottant unitaire (1.0), d’autres la restituent en pourcentage (100.0). Ce format d’échange doit être clairement établi dès la conception du système d’acquisition.^[2]

Le sous-identifiant 24 présente également une particularité : le texte du chemin débute après le 4e octet, et plusieurs sous-programmes appelés peuvent être séparés par des caractères nuls (0x00). Même si le programme principal apparaît en premier, l’ordre d’affichage dépend des versions logicielles. L’interpréteur client doit gérer ces délimiteurs sans interrompre le traitement.^[2]

Rôles de session : niveaux de privilèges

L’autorisation sous LSV2 dépasse le simple statut d’ouverture de socket. Lors de l’initialisation, le client sélectionne un rôle qui restreint le périmètre des télégrammes acceptés. pyLSV2 recense notamment les rôles INSPECT, FILE, DNC, MONITOR, DIAGNOSTICS, PLCDEBUG, SCOPE et DATA. Le rôle INSPECT permet d’interroger les coordonnées et états ; FILE contrôle les fichiers ; DNC suit l’exécution du programme ; et PLCDEBUG donne accès à la mémoire de l’automate.^[3]

Ces rôles constituent de véritables compartiments de sécurité. Un serveur d’acquisition doit exclusivement demander INSPECT ou MONITOR. Attribuer le rôle PLCDEBUG à un processus de surveillance expose inutilement des capacités d’écriture sensibles. La configuration des rôles relève ainsi d’une politique de sécurité industrielle rigoureuse.^[3]

Première rupture : protocole dépouillé, documentation réservée

La légèreté de l’en-tête de huit octets conduit souvent à sous-estimer la complexité de LSV2. La réelle difficulté réside dans les règles non publiées : identifier quel sous-identifiant interroger, vérifier la compatibilité des commandes selon les générations et analyser les codes retour constructeur. Heidenhain ne fournissant pas de spécification publique ouverte, les projets communautaires ont comblé ce manque par rétro-ingénierie empirique.^[1][2]

Pour un usage industriel, il convient de distinguer l’apprentissage du protocole et son exploitation en production. Distribuée sous licence MIT, la bibliothèque pyLSV2 mentionne explicitement dans son README une mise en garde déconseillant son utilisation directe sur machine en production. Les évolutions de micrologiciels peuvent en effet modifier les comportements attendus.^[1]

Seconde rupture : la double barrière d’autorisation

L’accès aux données fait intervenir deux niveaux de contrôle distincts. Le premier est le rôle validé lors de la négociation initiale. Le second, déterminant, correspond aux options logicielles souscrites sur la commande numérique. Plus précisément, l’exécution des requêtes d’état avancées exige l’activation matérielle de l’option DNC Option 18 (via la clé SIK). En l’absence de cette licence, la commande valide la session mais rejette les télégrammes d’état avec des erreurs de droits.^[6]

L’absence d’Option 18 ne condamne pas pour autant l’acquisition : il demeure envisageable d’extraire les variables de fonctionnement en interrogeant directement les registres ou mémoires de l’automate (PLC). Bien que cette méthode réclame la connaissance précise de la table des variables configurée par le fabricant de la machine, elle offre une alternative fonctionnelle sur les équipements anciens sans engager l’achat d’options onéreuses. Distinguer la liaison réseau de l’autorisation d’extraction constitue une leçon essentielle de l’intégration Heidenhain.^[6]

Troisième rupture : diversité des générations et des ports

Considérer LSV2 comme un protocole uniforme ignore les différences majeures entre générations. Des unités iTNC 530, TNC 640, TNC7, CNCpilot 640 jusqu’à MillPlus IT, le support des commandes, les temporisations et les exigences de sécurité varient sensiblement. Les modèles récents encapsulent les flux dans des tunnels SSH chiffrés (port 22), tandis que les anciennes baies utilisent directement le port TCP 19000.^[1][5]

Les suites logicielles constructeur introduisent en outre leurs propres ports. Sur certaines configurations DNC de TNC640, des profils orientés vers le port 19003 ont été observés, alors que le protocole LSV2 de base écoutait sur 19000. Le port 19003 correspond à la couche d’interface COM logicielle et ne constitue pas une norme de remplacement universelle. Il convient de ne pas généraliser ces valeurs.

La gestion de fichiers montre des disparités analogues : un système acceptera le transfert transparent tandis qu’un autre imposera des restrictions d’accès par mot de passe. Indiquer qu’une solution « supporte LSV2 » demeure incomplet sans spécifier la famille de commande et la version de logiciel installée.

Matrice comparative : LSV2, DNC COM et MTConnect

Le choix technique doit refléter la fonction requise. Si l’objectif consiste à téléverser des programmes d’usinage, MTConnect ne convient pas. À l’opposé, si le projet vise seulement l’acquisition d’indicateurs de disponibilité, ouvrir l’accès d’écriture de LSV2 crée une vulnérabilité inutile face à un bus de données passif.

Sept recommandations pour le déploiement opérationnel

1. Autoriser l’accès externe sur la CNC : L’ouverture de session sera systématiquement refusée sans validation explicite des accès et des mots de passe sur le pupitre TNC.
2. Valider le port et l’encapsulation : Tenter initialement la liaison sur TCP 19000 ; sur les armoires TNC640 ou TNC7 récentes, intégrer le tunneling SSH sur le port 22.
3. Sélectionner le rôle le plus restrictif : Réserver INSPECT ou MONITOR à la télémétrie ; cantonner FILE aux transferts de fichiers ; isoler formellement PLCDEBUG.
4. Contrôler la disponibilité d’Option 18 : Vérifier l’état de la licence SIK ; en cas d’absence, orienter l’acquisition vers les adresses de mémoires PLC.
5. Centraliser les accès en session unique : La multiplication des connexions concurrentes déstabilise les anciennes commandes ; fédérer les requêtes via un serveur concentrateur unique.
6. Documenter la conversion des échelles : Définir formellement la règle de calcul du potentiomètre (10000 = 100 %) pour prévenir les erreurs de visualisation.
7. Tracer précisément les anomalies : Consigner l’ensemble des réponses T_ER et leurs codes numériques afin de dissocier les coupures de liaison des conflits de droits.

Conclusion : la simplicité de trame masque une architecture exigeante

Si la trame de base de LSV2 tient en huit octets, son exploitation rigoureuse exige de maîtriser les rôles applicatifs, les autorisations logicielles, les disparités matérielles et les codes d’erreur. Déclarer maîtriser le protocole sur la seule vue d’un en-tête compact revient à observer la serrure d’une porte sans connaître le bâtiment qu’elle protège.

Quel rôle vos applications de supervision sollicitent-elles actuellement sur vos commandes TNC ? Et sur vos machines dépourvues de l’Option 18, votre accès via l’automate constitue-t-il une architecture pérenne ou une mesure d’attente ?

Cet article constitue le troisième volet de notre série sur les protocoles de commande CNC. Pour approfondir les transmissions séries industrielles, découvrez notre guide technique RS-232 ; les principes de signalisation bas niveau sont analysés dans notre étude sur l’I2C, le SPI et l’UART.