Chargement...

4) Les types de programmation

4) Les types de programmation

Historiquement, les premières UTL étaient programmées à l’aide d’un langage procédural ou littéral (au sens de la norme CEI 61131-3).

Compréhensible par un esprit informaticien, ce langage exige l’apprentissage d’une syntaxe (ou « grammaire ») rigoureuse. Il a été peu à peu remplacé par les langages graphiques, plus intuitifs, qui consistent à assembler des blocs de régulation et d’automatisme évolués.

Exemple de langage littéral :
Le Colbas (Control Oriented Language for Building Automation Systems) longtemps utilisé par le constructeur Landis et Gyr

Cette succession d’instructions, ici la 33ème tâche de l’application COLBAS, sert à commander l’enregistrement, à intervalles de 15 minutes, de l’entrée de température n°22.

Exemple de langage graphique :
Le SAPIM développé par Staefa Control System pour la gamme AS1000.
Ce langage précurseur dans ce domaine de la programmation des UTL présentait l’avantage d’une grande souplesse, de par la rusticité des blocs unitaires, que l’on pouvait assembler à sa guise pour piloter, dès 1985, toutes sortes d’installations.
Le développeur disposait d’un ensemble de blocs fonctionnels unitaires, dits « blocs SAPIM » :

Exemples de fonction SAPIM :

Ainsi un bloc 5 (F5) permet le pilotage d’un équipement progressif en mode proportionnel. En complément une précision de type 5.1 ou 5.2 permettait de fixer :

  • une loi décroissante adaptée à une action de chauffage (la vanne s’ouvre lorsque la température décroît)

Ou

  • une loi croissante adaptée à une action de refroidissement (la vanne s’ouvre lorsque la température augmente)

Le développeur assemblait ensuite astucieusement les blocs afin de réaliser une application, ici le pilotage d’une centrale de traitement d’air avec son groupe de production d’eau glacée :

La lecture du logigramme se fait « de gauche à droite » et ne nécessite qu’un minimum de connaissances en automatique, la compréhension des blocs (donc une culture en régulation et en automatisme), et un esprit un tant soit peu logique…

Examinons pour exemple l’automatisme de démarrage :

Les blocs SAPIM F16.1/1 et F17.1/1 représentent respectivement des blocs « ET » et « OU ».
« K1 » représente l’état de l’horloge.
Si la position du sélecteur de mode de fonctionnement « 0,1, Aut » est sur « Aut », la valeur 1 est transmise au bloc F16.1/1. Si de plus, « K1 » est à 1 (= état d’occupation effective), le bloc F16.1/1 en fait la synthèse et envoie au bloc F17.1/1 un état 1, qui informe les blocs suivants de la volonté d’enclencher les équipements.

Question

L’examen attentif du logigramme ci-dessus fait apparaître des blocs 6.1 ou 6.2 pour la commande des vannes progressives équipant les batteries de la CTA, ainsi qu’un bloc 9.2 pour piloter le compresseur à un étage. Justifier l’emploi de ces blocs.
Les vannes progressives sont pilotées par des blocs progressifs, de mode de régulation PI (pour proportionnel-intégral).
Le bloc 6.1 présente une loi décroissante adaptée à une action de chauffage (la vanne s’ouvre lorsque la température décroît).
Le bloc 6.2 présente une loi croissante adaptée à une action de refroidissement (la vanne s’ouvre lorsque la température croît).
Le compresseur reçoit un ordre tout-ou-rien du bloc 9.2, donc le compresseur s’enclenche lorsque la température croît.

On s’en rend compte, la simple lecture d’un tel logigramme exige des connaissances de régulation.

L’élaboration du logigramme, en revanche, exige beaucoup de pratique du langage utilisé, car souvent un même objectif peut être atteint par diverses voies, étant donnée la richesse des blocs fonctionnels à disposition. L’expérience fournit alors les solutions les plus élégantes : à la fois compactes dans leur écriture, et économes en ressources de l’UTL.