Remonter les données d'un S7-1500 en base : architecture type

Les données de production dorment dans l'automate. Voici l'architecture qu'on déploie pour les amener proprement jusqu'à PostgreSQL ou SQL Server · et les pièges rencontrés en chemin.

Le point de départ

Le scénario est presque toujours le même : la ligne tourne, l'automate sait tout (cadences, arrêts, défauts, paramètres process), mais ce savoir reste enfermé dans des DB consultées à la volée sur le pupitre. Le directeur de production pilote avec un tableur rempli à la main en fin de poste. L'objectif d'un projet de remontée de données n'est pas « faire de la data » : c'est rendre chaque arrêt, chaque rebut et chaque dérive process visible, horodaté et corrélé à son contexte (lot, recette, opérateur), pour pouvoir agir.

L'architecture d'ensemble

Cinq maillons, chacun remplaçable indépendamment des autres :

1. La collecte : OPC UA d'abord

Le S7-1500 embarque un serveur OPC UA natif : c'est la voie standard, sécurisable (certificats, chiffrement, comptes dédiés) et indépendante de l'éditeur. Côté TIA Portal, trois points font la différence en production :

Deux alternatives selon le contexte : une passerelle middleware quand il faut agréger un parc hétérogène (Siemens + Schneider + machines anciennes en Modbus TCP), ou l'accès direct par protocole propriétaire pour les très hautes cadences. Dans tous les cas, la règle d'or tient : l'automate reste maître de son cycle, la collecte ne doit jamais pouvoir le ralentir.

2. Structurer avant de stocker

Un dump de variables horodatées n'est pas un modèle de données. On définit d'abord les entités métier, puis on mappe les variables automate dessus. Le modèle type qu'on déploie :

L'horodatage se fait au plus près de la source (dans l'automate quand la précision compte), en UTC, et chaque enregistrement porte l'identifiant de lot : c'est ce qui rend la corrélation défaut / lot / recette / opérateur exploitable ensuite, sans reconstruction fragile.

3. Historisation : PostgreSQL ou SQL Server

Les deux font très bien le travail ; le choix suit généralement votre IT (licences, compétences, sauvegardes existantes). Ce qui compte vraiment : un schéma versionné (migrations tracées, jamais de modification manuelle), des tables de mesures partitionnées par période avec des index pensés pour les requêtes temporelles, et une politique de rétention définie dès le départ : par exemple, mesures brutes 6 mois, agrégats horaires 5 ans. Le volume, lui, est rarement un problème : une ligne qui produit un enregistrement par cycle à 10 cycles / minute génère environ 5 millions de lignes par an. Une base correctement indexée ne s'en aperçoit pas.

4. Exposer : API et dashboards

Personne ne consomme la base en direct : une API REST fait l'interface, et dashboards, MES ou exports Excel passent par elle. Les indicateurs se calculent côté serveur, avec une définition écrite et partagée : un TRS dont le mode de calcul varie selon l'écran qui l'affiche fait plus de dégâts que pas de TRS du tout. Les dashboards restent sobres : l'état temps réel de la ligne pour le terrain, les tendances et les pareto de défauts pour les méthodes, et des alertes qui désignent un responsable et une action.

5. La cybersécurité, dès la conception

Le futur règlement machines (UE) 2023/1230 en fait une exigence essentielle, mais c'est déjà une évidence d'architecture : réseau OT segmenté du réseau bureautique (le collecteur traverse un pare-feu, pas l'automate), authentification OPC UA par certificats, comptes de collecte en lecture seule sur les seules variables exposées, et sauvegardes de la base testées. Rien d'exotique : de l'hygiène, posée dès le cahier des charges.

6. Les pièges classiques

Checklist avant de lancer