Les 5 langages de programmation API selon la CEI 61131-3

1.Ce que régit la CEI 61131-3

La CEI 61131-3 est la norme internationale de programmation des automates programmables. Elle ne définit pas seulement des langages, mais aussi les types de données, les types de blocs (fonction, bloc fonctionnel, programme) et le modèle d'exécution.

L'intérêt pratique : programmer selon la norme produit du code qu'un autre programmeur peut lire et comprendre sur un autre automate. Cela ne le rend pas portable au sens du copier-coller – les dialectes des constructeurs diffèrent trop. Mais les concepts sont identiques, et c'est là l'essentiel en pratique.

2.Noms normatifs et noms Siemens

C'est ici que naît la confusion la plus fréquente – y compris dans des articles techniques. La norme définit cinq langages ; Siemens leur donne ses propres noms :

Autre subtilité : le SFC n'est à proprement parler pas un langage de programmation, mais un élément de structuration. À l'intérieur des étapes et des transitions d'un SFC, le code est de nouveau écrit dans l'un des autres langages. En pratique, le SFC est néanmoins compté comme cinquième langage, et la norme le traite dans la même partie.

3.Les cinq langages comparés

3.1.LD – schéma à contacts

Le schéma à contacts reproduit la logique du schéma électrique : des contacts en série forment un ET, en parallèle un OU. Pour un personnel de maintenance issu de l'électrotechnique, c'est le langage dont le seuil d'entrée est le plus bas – un avantage inestimable quand quelqu'un sans compétences en programmation doit suivre un verrouillage la nuit.

La limite apparaît avec l'ampleur et le calcul. Un réseau de vingt contacts et trois branches parallèles est plus large que l'écran une fois imprimé, et la mise à l'échelle d'une valeur analogique devient une chaîne de blocs.

3.2.FBD – schéma par blocs fonctionnels

Le FBD représente les signaux sous forme de blocs à entrées et sorties. Là où le LD met en avant le chemin de courant, le FBD met en avant le flux de données – ce qui convient mieux au traitement analogique, aux régulateurs et à tout ce qui transforme des valeurs plutôt que de commuter.

3.3.IL – liste d'instructions

L'IL est le langage le plus proche de la machine, un assembleur pour automate en somme. Dans la troisième édition de la CEI 61131-3 (2013), l'IL a été classé obsolète (deprecated) ; il n'est plus recommandé pour de nouveaux projets.

Il reste pertinent pour une raison : les installations existantes. Reprendre un programme S5 ou S7 Classic, c'est rencontrer régulièrement de l'IL – souvent sans symbolique. Savoir le lire n'est pas de la nostalgie lors des migrations, c'est du métier.

3.4.ST – texte structuré

Le ST est le langage permettant d'exprimer tout ce qui devient fastidieux en graphique : boucles, distinctions de cas, calculs, traitement de chaînes, blocs de bibliothèque génériques.

// Exemple : mise à l'échelle d'une valeur analogique avec contrôle de plage
FUNCTION FC_ScaleAnalog : REAL
VAR_INPUT
  iRaw        : INT;    // valeur brute 0…27648
  rMin, rMax  : REAL;   // plage cible en unité physique
END_VAR

IF iRaw < 0 THEN
  FC_ScaleAnalog := rMin;          // rupture de fil / sous-dépassement
ELSIF iRaw > 27648 THEN
  FC_ScaleAnalog := rMax;          // dépassement
ELSE
  FC_ScaleAnalog := rMin + (rMax - rMin) * INT_TO_REAL(iRaw) / 27648.0;
END_IF;

La même fonctionnalité en LD serait une chaîne de blocs sur plusieurs réseaux, dont l'intention ne se révèle qu'après examen attentif.

Second avantage, souvent sous-estimé : le ST est du texte. Il se versionne donc utilement dans Git, se relit ligne par ligne en revue de code et se cherche avec des outils ordinaires. Les langages graphiques sont stockés en format binaire – un diff n'y montre au mieux que « bloc modifié ».

3.5.SFC – diagramme fonctionnel en séquence

Le SFC représente les séquences en étapes et transitions. Le gain majeur est la visibilité : l'état courant de l'installation se lit directement en ligne, au lieu d'être reconstitué à partir d'une dizaine de mémentos.

Pour les chaînes séquentielles – procédés discontinus, cycles de nettoyage, changements de mode – c'est l'avantage décisif au dépannage. Pour un simple verrouillage, c'est un surcoût.

4.Quel langage pour quoi : une aide à la décision

Aucun langage n'est le meilleur en tout. En pratique, cette répartition a fait ses preuves :

5.Mélanger est permis – et judicieux

Idée reçue répandue : il faudrait choisir un langage. C'est l'inverse. La norme prévoit explicitement que chaque bloc soit écrit dans le langage adapté à sa tâche.

Un projet typique ressemble alors à ceci :

OB1 (Main)                         → LD, uniquement des appels
  ├── FB_ModeControl               → SFC (modes de marche en chaîne d'étapes)
  ├── FB_ConveyorControl           → ST (logique + temporisation)
  │     └── FC_ScaleAnalog         → ST (calcul)
  ├── FC_SafetyInterlocks          → LD (doit être lisible sans outil)
  └── FB_AlarmHandler              → ST (bloc de bibliothèque)

Seul compte que le choix soit justifié et reste cohérent dans le projet. Cinq langages mélangés au hasard valent moins qu'un seul appliqué avec constance.

6.Conclusion

• La CEI 61131-3 définit cinq langages : LD, FBD, IL, ST et SFC. SCL est le nom Siemens du ST, pas un sixième langage.
• L'IL est obsolète depuis 2013 – savoir le lire oui, en écrire de nouveau non.
• Le ST porte l'essentiel d'un projet moderne, parce qu'il autorise calculs, bibliothèques et gestion de versions.
• Le LD reste pour la logique de sécurité et critique pour la maintenance, car la lisibilité en cas de défaut détermine la durée d'arrêt.
• Mélanger les langages est conforme à la norme et judicieux – tant que le choix est justifié et cohérent.

7.Pour aller plus loin

• Programmation API : 8 bonnes pratiques pour un code propre – comment le choix du langage s'inscrit dans une structure d'ensemble
• Documentation API : ce qu'elle doit contenir et ce qui compte à la remise – quel langage engendre quelle charge documentaire
• Dépannage des programmes API : cerner méthodiquement – pourquoi le SFC accélère le diagnostic