API vs UTR : différences clés et tendances du marché

La convergence entre les automates programmables industriels (API) et les unités terminales distantes (UTR) est relativement récente. En termes de base installée, les API ont depuis longtemps dépassé les UTR et dominent le marché depuis des décennies, devenant pratiquement des produits de base.

Poussés par cette croissance, de nombreux fournisseurs ont amélioré les fonctionnalités des API et, dans certains cas, ont tenté de grignoter le marché des UTR en développant des fonctionnalités similaires pour les API. Au point que certains API sont commercialisés comme des UTR.

D'autre part, les origines et l'histoire de chaque dispositif sont différentes. Pour leur part, les UTR ont suivi de près l'évolution des systèmes SCADA, dont ils sont des composants essentiels.

Les SCADA et UTR ont été introduits pour la première fois dans l'industrie des télécommunications, puis plus tard dans les centrales de production d'énergie dans les années 1950. Le problème qu'ils essayaient de résoudre était la communication de données depuis des instruments de terrain sur de très longues distances.

Les API sont apparus plus tard, au début des années 1970. Les API n'ont devenu possibles qu'une fois que l'informatique personnelle compacte et les microprocesseurs ont atteint un certain stade, où la production en masse était viable. Les API sont allés directement dans le monde de la fabrication industrielle, remplaçant des circuits complexes et inflexibles composés de nombreux relais par un dispositif compact qui pouvait plus facilement s'adapter aux sols de production. Le secteur de la fabrication automobile a été parmi les premiers à bénéficier de l'introduction des API.

Qu'est-ce qu'un API ?

Les API sont essentiellement des ordinateurs conçus pour l'automatisation des processus industriels. Un API se compose d'une unité centrale de traitement (CPU) et d'entrées et sorties. Le CPU est responsable de l'exécution du programme installé par l'utilisateur. Plusieurs types de modules peuvent généralement être intégrés à un API : entrées et sorties numériques et analogiques, communications réseau, adaptateurs de protocole, extensions de bus, entre autres.

Différents langages de programmation peuvent être utilisés pour coder des instructions pour les API, le plus populaire étant le diagramme à contacts (ladder) et le texte structuré. Un diagramme à contacts, parfois appelé logique à contacts, est un langage de programmation visuel qui émule l'ouverture et la fermeture de contacts et relais. Le texte structuré utilise une syntaxe similaire aux langages basés sur C. Il permet des instructions plus complexes que le langage à contacts ; il est donc généralement utilisé dans des applications de contrôle plus complexes.

Chaque API fonctionne en exécutant cycliquement trois tâches de base en séquence : lecture des entrées, exécution du programme et écriture des sorties.

Au début de chaque cycle, l'API doit mettre à jour l'état de toutes les entrées physiques qui y sont connectées, afin que l'état correct soit utilisé. Ensuite, le programme préchargé est exécuté, parcourant les routines principales et les sous-routines. Enfin, les sorties physiques sont mises à jour en fonction des résultats de l'exécution du programme. Cela se fait à chaque cycle d'API, et le temps de cycle est une mesure clé que les programmeurs essaient fréquemment d'optimiser pour augmenter les performances du système.

Qu'est-ce qu'une UTR ?

Les UTR sont des unités de contrôle à base de microprocesseurs conçues pour surveiller et contrôler des dispositifs de terrain. Elles sont utilisées principalement dans les systèmes SCADA, fournissant l'interface entre le contrôle SCADA et les processus physiques ainsi que leurs capteurs et instrumentation. Similaires aux API, les UTR se composent également de CPU et de modules d'entrées/sorties, ainsi que d'options de communication et de traduction de protocole.

La programmation des UTR est généralement beaucoup plus simple que celle des API. La plupart des UTR sont configurées via une interface web, et pas beaucoup plus que cette configuration n'est effectuée. Bien que les UTR modernes soient compatibles, la plupart ne sont pas conçues ou ne prennent pas en charge les boucles de contrôle et la logique complexe. Les temps de cycle sont extrêmement rapides, généralement dans la plage de 1 milliseconde.

Comparaison entre API et UTR

En commençant par la programmabilité, cela peut être vu comme un avantage ou un inconvénient selon la situation. Les UTR, avec leur interface simple, pourraient être considérées comme plus conviviales. D'autre part, cette même interface est inflexible pour un système de contrôle complexe et parfois incompatible avec l'application.

Les UTR sont généralement plus grandes que les API. Une raison en est les fonctionnalités ajoutées qui augmentent la durabilité et la robustesse du dispositif, ce qui prend plus d'espace. La plus importante de ces fonctionnalités est l'armoire, nécessaire pour résister à des conditions environnementales difficiles. Les API sont plus compacts en partie parce qu'ils sont destinés aux industries et usines où l'espace disponible n'est normalement pas abondant.

Les UTR sont, en moyenne, plus chères que les API en raison des exigences de taille et de robustesse. Cela n'est cependant normalement pas un facteur décisif lors du choix d'un type de dispositif. Avec les API conçus pour les environnements industriels et les UTR pour les systèmes extérieurs à longue distance, les considérations de coût viennent avec l'échelle du projet.

Généralement, les UTR sont mieux adaptées à la surveillance à distance, comme dans les industries des services publics et de l'agriculture. Pendant ce temps, les API sont largement utilisés dans toutes les industries et ne seront probablement pas remplacés de sitôt. Même si ces deux dispositifs ont quelques similitudes, ils sont utilisés de manière différente.

Utilisez-vous plus d'UTR ou d'API dans votre travail ? Pourquoi ?