Qu’est-ce que FOCAS ? L’API native des CNC FANUC

Avril 2026. Sur un banc de test isolé, un serveur expérimental émulant une commande numérique FANUC 31i écoutait les connexions entrantes sur le port TCP 8193. L’objectif était précis : faire dialoguer la bibliothèque cliente officielle de FANUC avec un émulateur sans utiliser les DLL propriétaires du constructeur. Le serveur transmit un paquet de bienvenue rigoureusement conforme au format binaire attendu. La bibliothèque distante analysa la charge utile, valida ses signatures et interrompit la session. Un code d’erreur unique fut consigné dans le journal : -16, correspondant à la constante EW_PROTOCOL.

Cet échec immédiat révèle la nature profonde de FOCAS : il ne s’agit pas d’un protocole réseau générique, mais d’une suite logicielle propriétaire distribuée par FANUC. La bibliothèque cliente intègre ses propres mécanismes d’authentification et de validation interne. Répéter des trames capturées sur le câble s’avère insuffisant. Le même jour, une seconde démarche fut éprouvée : contourner intégralement la bibliothèque pour converser directement en TCP brut. Cette alternative dévoila les rouages véritables du protocole sous-jacent.

FOCAS (FANUC Open CNC API Specifications) constitue l’interface de programmation native permettant d’interroger et de piloter les données internes (CNC et PMC) des contrôleurs FANUC. Référencée sous les dénominations FOCAS1 et FOCAS2, elle opère par liaison Ethernet ou bus optique propriétaire HSSB (High Speed Serial Bus). L’architecture repose sur l’allocation d’un handle de session, canal obligatoire de chaque lecture ou écriture. Contrairement à MTConnect, FOCAS n’est pas un standard ouvert : ses spécifications et bibliothèques font l’objet d’une distribution contrôlée par le constructeur.^[1][2][3]

FOCAS en un coup d’œil

Périmètre et distinctions fondamentales

Confondre FOCAS et MTConnect engendre des erreurs d’architecture préjudiciables en atelier. MTConnect se définit comme un vocabulaire sémantique ouvert, strictement passif et multi-constructeurs. FOCAS incarne à l’opposé une interface propriétaire exclusive à FANUC, autorisant des interactions profondes et des écritures actives. Le premier normalise l’observation globale d’un parc ; le second pénètre au cœur de l’automate. FANUC propose par ailleurs sa suite logicielle MT-LINK i pour la supervision d’atelier en Ethernet et OPC UA ; ce produit s’appuie sur une couche logicielle supérieure et ne remplace nullement l’API FOCAS.^[1][2][6]

FOCAS ne se résume pas à un fichier unique. Si FWLIB32.DLL fournit les points d’entrée génériques, elle requiert impérativement des modules satellites selon la génération de la commande : FWLIB30i, FWLIB0iD, FWLIB0i, FWLIB16W ou FWLIBNCG. Une même application cliente échouera si l’ensemble des bibliothèques correspondant à la version matérielle n’est pas présent dans le répertoire d’exécution. Déclarer une intégration FOCAS fonctionnelle sans spécifier le modèle de CNC et la version logicielle constitue un contresens technique.^[2][3]

La question contractuelle encadre rigoureusement l’usage de FOCAS. La bibliothèque n’appartient pas au domaine public et son intégration dépend des conditions commerciales accordées par FANUC. Les projets industriels doivent intégrer la gestion des licences logicielles et des options d’activation dans leur cadrage budgétaire initial.^[2]

Deux couches de transport, un handle unique

FOCAS offre deux vecteurs physiques : la liaison Ethernet standard et la liaison optique HSSB. L’Ethernet repose sur une socket TCP, généralement affectée au port 8193. HSSB emploie une carte d’interface enfichable assurant un débit déterministe avec une latence quasi nulle. Chaque fonction documentée dans la matrice du constructeur comporte un indicateur d’éligibilité : O (opérationnel sur les deux supports), E (Ethernet exclusivement) ou H (HSSB uniquement).^[1][2]

La communication s’articule autour d’un handle de session. L’appel cnc_allclibhndl3 prend en paramètres l’adresse IP, le port réseau et une temporisation de garde, puis renvoie un identifiant numérique. Les lectures et écritures ultérieures référencent cet identifiant. Lorsque les échanges prennent fin, la ressource doit être explicitement libérée. Tenter d’exécuter des requêtes sur un handle invalidé par une déconnexion intempestive constitue la cause première des blocages logiciels observés sur le terrain.^[3]

Structure binaire des trames sur le réseau

Le format de transmission binaire de FOCAS a été mis en lumière par des initiatives indépendantes de rétro-ingénierie (notamment le projet pyfanuc) et des analyses de paquets industriels. Ces données documentent le comportement effectif du flux réseau sans engager la garantie du constructeur.^[4][5]

Toute trame s’ouvre par un en-tête fixe de 10 octets débutant par la séquence magique A0 A0 A0 A0, suivie du numéro de version, du type de trame et de la longueur des données utiles. L’encodage des entiers s’effectue dans l’ordre gros-boutiste (big-endian) :

En-tête de trame (10 octets) :
[A0 A0 A0 A0] [version:u16] [type:u16] [longueur:u16]

0x0101 / 0x0102  Établissement de session : requête / confirmation
0x0201 / 0x0202  Fermeture de session : requête / confirmation
0x2101 / 0x2102  Échange de données : requête / réponse
0x2103           Trame de rejet observée lors d'erreurs de format

La charge utile d’une requête de données agrège des sous-paquets individuels de 28 octets : une longueur (couramment 0x001C), trois octets de commande hiérarchique et cinq arguments codés sur 32 bits. La réponse valide reprend le code de commande et transmet les données brutes ; en cas d’anomalie, un message d’erreur compact de 14 octets est renvoyé. Cette structure autorise le regroupement de multiples requêtes (statut, programme actif, vitesse réelle et alarmes) dans un même segment TCP.^[4]

Cette granularité explique l’intérêt d’une intégration native : par une liaison unique, le système supervise la géométrie, l’automate et les registres applicatifs avec une précision inaccessible aux protocoles génériques.

Première rupture : une suite d’API, pas un protocole isolé

Considérer FOCAS comme un simple protocole d’échange constitue un piège fréquent. Au sommet de la pile logicielle réside une API en langage C riche de centaines de fonctions : cnc_statinfo, cnc_absolute, cnc_rdprgnum, cnc_exeprgname, cnc_rdopnlsgnl, cnc_rdmacro ou pmc_rdpmcrng. À la base se déploie une couche de transport binaire régie par un assemblage spécifique de bibliothèques dynamiques.^[1][2]

Par conséquent, un code compilé pour une unité 30i-B peut refuser de communiquer avec une baie 0i-F. La matrice fonctionnelle de FANUC consigne explicitement les compatibilités par contrôleur ; le symbole X sanctionne les fonctions non supportées. De nombreux dysfonctionnements attribués à des erreurs réseau résultent en réalité d’un appel API non pris en charge ou d’une incompatibilité de version logicielle.^[1]

Seconde rupture : la responsabilité critique de l’écriture

L’aptitude de FOCAS à modifier les paramètres internes constitue sa puissance majeure et son risque le plus élevé. L’API autorise la réécriture des décalages d’origine, des variables macro, des registres PMC et des paramètres d’asservissement. Une valeur altérée accidentellement peut entraîner une collision mécanique, endommager une broche ou compromettre la sécurité des techniciens en atelier.^[2]

L’accès en écriture exige une gouvernance technique rigoureuse. Les modules émettant des commandes d’écriture doivent résider sur un segment réseau dédié, assortis d’un contrôle d’accès strict, d’une traçabilité des modifications et d’une procédure de restauration validée sur simulateur. Les alertes de sécurité publiées périodiquement par FANUC soulignent l’importance d’isoler hermétiquement ces interfaces.^[7]

Troisième rupture : barrière DLL et stratégies d’implémentation

Revenons au rejet observé sur le banc de test. Pourquoi la bibliothèque officielle a-t-elle renvoyé -16 EW_PROTOCOL face à notre simulateur ? L’analyse réseau démontre que le composant FANUC ouvre deux connexions distinctes et cible des registres précis pour valider la légitimité du contrôleur distant. La simple réplication des paquets applicatifs ne suffit pas à tromper le client natif.

Cette situation établit deux approches d’ingénierie distinctes : employer les bibliothèques officielles fournies par le constructeur ou implémenter un pilote autonome conversant directement sur la socket TCP (à l’instar de pyfanuc). Une implémentation réseau indépendante confère une autonomie appréciable sous Linux et conteneurs logiciels, mais opère sans support officiel et peut révéler des divergences d’un microprogramme à l’autre.^[4][5]

En matière d’intégration, le choix de la bibliothèque d’accès prime sur les simples réglages de ports réseau. Les outils fournis par FANUC garantissent la maintenabilité et la certification des flux ; les pilotes indépendants suppriment les dépendances d’installation mais requièrent une veille rigoureuse face aux évolutions des CNC. Mélanger ces deux démarches sur un même îlot multiplie inutilement les causes d’incidents.

Par ailleurs, les simulateurs tels que NCGuide manifestent des écarts vis-à-vis des armoires réelles. Lors de nos essais, CMD_READ_OPNLSGNL (0x61) produisit une réponse d’erreur E6, CMD_READ_MACRO (0x15) déclencha un rejet 0x2103, et CMD_READ_PMC (0x02) provoqua une réinitialisation de socket. En revanche, le code outil put être extrait au 24e octet de la réponse à CMD_READ_MODAL_AUX (0x22). Ces particularités d’émulateur doivent systématiquement faire l’objet d’une validation physique sur machine réelle.

Arbitrage technique : FOCAS ou MTConnect ?

Les infrastructures performantes combinent judicieusement ces technologies : un adaptateur local exploite FOCAS pour extraire les données fines de l’armoire FANUC, puis les reformate dans le modèle sémantique MTConnect pour alimenter les outils de supervision d’atelier. Cloisonner les fonctions d’écriture et réserver la diffusion d’indicateurs à un bus de lecture garanti sans impact machine constitue le standard de l’industrie.^[8]

Sept préconisations pour le déploiement en production

1. Valider les options matérielles : FOCAS n’est pas actif par défaut sur tous les contrôleurs ; vérifiez la présence de l’option Fast Ethernet et le niveau de version système.
2. Verrouiller le port réseau : Isolez le port TCP 8193 sur un VLAN industriel dédié ; filtrez impérativement les accès en provenance des réseaux de bureautique.
3. Constituer l’assemblage DLL adéquat : Associez précisément la bibliothèque principale FWLIB32 aux bibliothèques secondaires propres à la série CNC installée (32 bits ou 64 bits).
4. Gérer rigoureusement les handles : Conservez les connexions ouvertes pour le scrutation cyclique et gérez proprement les reconnexions automatiques en cas de rupture de socket.
5. Réguler la cadence d’interrogation : Limitez la fréquence des requêtes pour ne pas surcharger l’UC de la commande numérique ; appliquez une temporisation exponentielle lors des erreurs.
6. Ségréguer les droits d’écriture : Restreignez les fonctions d’écriture à des serveurs identifiés, soumis à une authentification forte et des journaux d’audit inaltérables.
7. Analyser systématiquement les codes retour : Surveillez en continu les codes d’erreur renvoyés par la bibliothèque (dont EW_PROTOCOL) afin de détecter les anomalies naissantes.

Conclusion : l’art de maîtriser ses accès en atelier

La valeur de FOCAS réside moins dans le nombre impressionnant de ses fonctions que dans la rigueur imposée à leur exploitation. Un même handle réseau peut relever une cote en temps réel ou altérer l’origine d’un usinage. Définir cette frontière ne relève pas seulement du développement logiciel, mais d’une politique globale de fiabilité industrielle.

Vos systèmes de collecte sur armoires FANUC se cantonnent-ils strictement à la télémétrie passive ? Et pour chaque fonction d’écriture activée, disposez-vous d’un protocole d’arrêt d’urgence et d’une sauvegarde immédiatement opérationnelle ?

Cet article fait partie de notre série sur les protocoles de commande CNC. Pour découvrir les standards de données ouverts, consultez notre guide MTConnect ; pour les liaisons physiques industrielles, reportez-vous à notre dossier technique RS-232 ; les principes de signalisation bas niveau sont analysés dans notre étude sur l’I2C, le SPI et l’UART.