Automatiser TIA Portal avec une API REST : le guide pour les constructeurs de machines

Une machine de plus, le même travail à refaire

Un constructeur de machines livre souvent plusieurs équipements proches. Le châssis change, quelques options s’ajoutent, certains capteurs disparaissent, mais une grande partie du programme automate reste la même.

Pour chaque variante, il faut pourtant vérifier les appareils, adapter les variables, mettre à jour les blocs, compiler et contrôler le projet. Quand ces informations existent déjà dans un configurateur ou un outil interne, les recopier à la main dans TIA Portal prend du temps et multiplie les occasions d’erreur.

C’est là qu’une interface d’automatisation devient utile. T-IA Connect propose notamment une API REST pour relier des outils externes à TIA Portal. Encore faut-il savoir ce qu’on automatise, et ce qu’on ne lui demande pas de faire.

Pour replacer cette passerelle dans une architecture industrielle plus large, consultez aussi notre guide sur l’intégration logicielle en automatisation, du capteur au cloud.

Automatiser l’ingénierie, pas piloter directement l’automate

Une API qui communique avec TIA Portal agit sur l’environnement d’ingénierie : elle peut découvrir les instances disponibles, travailler avec un projet et lancer des opérations prises en charge.

Ce n’est pas, par défaut, une API de supervision qui remplace les protocoles de communication avec un automate en production. La distinction compte : préparer ou contrôler un projet TIA Portal et envoyer des commandes à une machine en fonctionnement sont deux tâches différentes, avec des risques différents.

Pour un constructeur, l’objectif peut être de réduire les étapes répétitives entre une configuration commerciale et un projet d’automatisme. L’outil métier décrit la variante ; l’intégration prépare ou vérifie le projet correspondant ; l’ingénieur garde la main sur le résultat.

La voie Siemens : TIA Portal Openness

Siemens présente TIA Portal Openness comme son interface intégrée pour automatiser les tâches d’ingénierie depuis des applications externes. C’est une base solide pour créer ses propres outils.

Cette voie convient bien à une application déjà construite autour de l’environnement Siemens. Elle demande toutefois de gérer le lien avec TIA Portal, les versions installées, l’état du projet et les erreurs possibles. Une opération qui prend du temps doit aussi être suivie jusqu’à son résultat final.

Notre article consacré à l’API TIA Openness détaille ses possibilités, ses contraintes et son intégration avec C# et .NET.

Quand l’outil qui doit lancer l’opération est écrit dans un autre langage ou fait partie d’un système plus large, il faut construire le raccordement autour d’Openness. Une API REST offre une autre forme d’interface : des requêtes HTTP et des données JSON.

Pourquoi choisir une API REST ?

La plupart des outils de gestion savent envoyer une requête HTTP. Un script PowerShell utilisant `Invoke-RestMethod`, une application web interne ou un service de configuration peut donc appeler une API REST sans intégrer directement tous les détails de TIA Portal.

Le principe est simple : le client envoie une requête à une adresse connue, reçoit une réponse structurée, puis vérifie le résultat. L’API ne supprime pas la logique d’ingénierie ; elle fournit un moyen plus standard de l’orchestrer.

Un parcours d’automatisation, étape par étape

1. Découvrir les instances disponibles. Avant d’ouvrir un projet, l’outil doit savoir quelle instance TIA Portal il va utiliser. Avec T-IA Connect, GET /api/instances permet de consulter les instances exposées par le serveur. Il faut sélectionner l’identifiant exact fourni par la découverte, plutôt que deviner un port ou choisir un projet au hasard.

CODE

$baseUri = 'http://localhost:9000'

if ([string]::IsNullOrWhiteSpace($env:TIA_CONNECT_API_KEY)) {
    throw 'Configurez la clé API par votre mécanisme local sécurisé.'
}

$headers = @{ 'X-API-KEY' = $env:TIA_CONNECT_API_KEY }

$discovery = Invoke-RestMethod -Method Get -Uri "$baseUri/api/instances" -Headers $headers

if ($discovery.success -ne $true -or $discovery.response.success -ne $true) {
    throw 'La découverte des instances a échoué.'
}

$discovery.response.data | Select-Object instanceId, isActive, state, selectable

La clé API ne doit pas être inscrite dans le script ni dans un dépôt. L’accès au serveur doit être limité aux postes et aux personnes qui en ont besoin.

2. Choisir le projet voulu. Une fois la bonne instance identifiée, l’intégration peut sélectionner cette instance puis ouvrir un projet dont le chemin a été validé. Le fichier se trouve sur le poste qui héberge TIA Portal : le client REST ne doit pas supposer que son propre disque est celui de l’ingénieur.

3. Attendre la fin des opérations. Certaines commandes prennent du temps et répondent d’abord qu’un travail a été accepté. Cette réponse n’indique pas que l’opération est terminée. Il faut suivre le travail jusqu’à son état final et traiter les erreurs au lieu de relancer aveuglément la même action.

4. Relire le résultat. Après une modification ou une compilation, vérifiez l’état du projet et relisez les données concernées. Une réponse HTTP réussie ne suffit pas toujours à prouver que le travail d’ingénierie attendu a été effectué.

5. Valider sur une copie. Avant de connecter une intégration à un flux réel, commencez par une copie de projet. Faites confirmer les changements par un automaticien et gardez une étape de validation avant toute opération qui modifie un projet important.

Pour conserver un historique exploitable avant et après ces modifications, notre guide explique aussi comment versionner ses projets TIA Portal avec Git.

Les limites à connaître

Une API REST ne rend pas toutes les opérations compatibles avec toutes les versions de TIA Portal. L’intégration doit vérifier ce que permettent la version installée et les endpoints disponibles.

Il faut aussi penser aux autres utilisateurs. Si plusieurs clients partagent le même serveur, la sélection d’une instance est commune à l’application et aux clients REST. Une séquence « sélectionner un projet, puis le modifier » doit donc être coordonnée ; il ne faut pas lancer en parallèle des opérations qui supposent des projets différents.

Enfin, une API ne décide pas quelles modifications sont acceptables. Les règles de validation, les sauvegardes et l’accord de l’ingénieur restent des choix de conception de votre processus.

L’alternative : relier TIA Portal avec T-IA Connect

T-IA Connect expose une interface REST autour de TIA Portal Openness. Elle permet à un outil externe de découvrir les instances et d’appeler les opérations disponibles, tout en conservant une interface et des mécanismes de suivi des travaux.

Pour un constructeur, cela peut servir de base à un utilitaire interne : récupérer une configuration de machine, guider l’ingénieur vers le bon projet, préparer une série de vérifications et rendre le résultat consultable dans un outil déjà utilisé par l’équipe.

Le but n’est pas de transformer chaque projet en automatisme sans contrôle. Il s’agit de supprimer les recopies répétitives et de rendre les étapes plus faciles à répéter et à vérifier. TIA Portal reste au centre de l’ingénierie ; l’API fournit un lien avec le reste de vos outils.

En résumé

TIA Portal Openness permet à des applications externes d’interagir avec l’environnement d’ingénierie Siemens.
Une API REST offre une interface HTTP/JSON pratique pour relier plusieurs types d’outils.
Une opération acceptée doit être suivie jusqu’à son résultat, puis vérifiée par une relecture.
La sélection du projet, les versions TIA Portal et la validation humaine restent des points importants.
T-IA Connect fournit une passerelle REST pour intégrer ces opérations dans un processus d’ingénierie.

Et vous, quelles tâches répétitives aimeriez-vous relier à vos projets TIA Portal ?