Plateforme pour l’eau, le gaz et la chaleur
Danser sur la vague avec sa planche - ne faire qu'un avec la nature, l'eau, son corps. Les surfeurs ne retrouvent pas seulement cette sensation sur les côtes de l'Atlantique ou du Pacifique, mais aussi en Suisse, par exemple sur la vague de la rivière Reuss à Bremgarten. Lorsque l'eau se précipite sur deux barrages situés sous la surface de l'eau, elle est fortement accélérée et forme la vague. Pour cela, un niveau d'eau minimal est nécessaire, comme c'est souvent le cas après la pluie.
Les pluies abondantes ne créent pas seulement des conditions idéales pour le surf, elles entraînent aussi souvent un dépassement des capacités d'évacuation des eaux usées. Les apports dus à la décharge d'eau mixte ainsi nécessaire dans les cours d'eau sont invisibles, inévitables et autorisés par la loi. Ils augmentent toutefois temporairement la charge bactérienne dans l'eau, ce qui a provoqué par le passé des cas isolés de maladie chez les surfeurs. La problématique a été reprise par les médias et les politiques - et l'idée d'un système d'information en temps réel sur la qualité de l'eau a vu le jour.
Les données nécessaires à cet effet existent aujourd'hui ponctuellement, de manière isolée selon les installations et les associations, et dans différents systèmes numériques de contrôle-commande (SNCC) et formats: Niveaux, débits de décharge, moments, distances, états effectifs, etc. Un système d'information en temps réel supposerait toutefois que les données pertinentes soient saisies en continu, rassemblées et mises en relation les unes avec les autres. Des exigences similaires existent pour l'évaluation des données d'exploitation et le calcul des coûts, pour la gestion dynamique des réseaux ou, plus généralement, pour le monitoring des cours d'eau. Pour ces questions, il faut un standard de données et une interface ouverte.
Le Plant Data Access (PDA) est une proposition concrète d'interface de données standardisée et indépendante du système pour les données d'eau potable et d'eaux usées.
Selon le système de contrôle-commande, les données de mesure sont disponibles dans des formats spécifiques au fabricant (propriétaires) dans différentes bases de données. La structure des données, par exemple en ce qui concerne la durée d'enregistrement, la résolution, le tramage temporel, la désignation des objets ou les métadonnées, peut varier pour chaque système. Le transfert à partir des réseaux généralement isolés se fait manuellement, parfois par support de données ou via des dépôts temporaires. Si les données sont incomplètes, s'il manque des métadonnées ou si les grilles temporelles ne sont pas adaptées, le processus recommence depuis le début. Cela entraîne des retards, des interfaces inutiles et empêche les spécialistes de se concentrer sur l'analyse, l'optimisation ou l'exploitation proprement dites.
La nouvelle approche sous la forme de l'interface PDA permet de remédier à cette situation. Elle est basée sur la norme web REST-API, aujourd'hui répandue dans le monde entier (voir la section «Qu'est-ce qu'une API?» ci-dessous).
Les données peuvent ainsi être consultées via un point final (adresse web) accessible au public. Les données actuelles et historiques peuvent être consultées via l'interface, pour autant que l'utilisateur y soit autorisé. Cela permet d'uniformiser l'accès aux données qui sont pertinentes pour de nombreux acteurs. Les API permettent une séparation technique entre le SNCC et l'accès aux données. Il est ainsi possible de consulter les données de manière uniforme, indépendamment de la structure de la base de données.
Une API (Application Programming Interface) est une interface standardisée qui permet aux systèmes de communiquer entre eux et d'échanger des données.
L'accès à une telle API se fait via une adresse Internet (URL). L'API garantit que les données et les métadonnées sont toujours interrogées et mises à disposition dans un format uniforme et clairement défini. On peut s'imaginer la structure de cette URL comme les chemins d'accès aux dossiers et aux fichiers sur un ordinateur. Dans ce système, chaque fichier correspond à une série de mesures. Comme les dossiers sont également visibles, il est possible de lister certains objets ou de les filtrer en fonction de leurs propriétés. De manière encore plus claire, une API est comme un serveur dans un restaurant - en tant que client, on ne s'adresse pas directement à la cuisine (le système de contrôle-commande), mais au serveur (API), qui transmet et livre ensuite la commande.
Une API permet un accès uniforme à tous les systèmes, même si leur structure technique est différente. Par exemple, la numérotation du système d'identification des installations varie d'une installation à l'autre, ce qui rend presque impossible une harmonisation au niveau supérieur. Le PDA peut servir de système de base pour la standardisation de l'identification des objets. L'API définit la norme de transmission, tandis que la mise en œuvre technique reste du ressort des différents intermédiaires de données. Une API met exclusivement à disposition des données brutes et ne contient aucune interface utilisateur. Elle constitue donc la base technique d'applications, d'évaluations et de services avancés, mais n'est pas un produit pour l'utilisateur final.
Au cours des derniers mois, une approche architecturale a été développée, qui fait passer le transport et la mise à disposition des données d'une approche basée sur les fichiers à une API Web standardisée (fig. 1). La base est une spécification OpenAPI définie (https://www.openapis.org), appelée ci-après PDA.
L'interface supporte les accès en lecture et, si cela est explicitement autorisé, également les accès en écriture. Les autorisations sont attribuées spécifiquement à l'utilisateur et par point de données. Comme niveau de sécurité supplémentaire, les accès en écriture ne sont possibles dans le concept que si le point de données correspondant est autorisé côté installation. Les accès en écriture sont en outre consignés côté installation.
L'élément central du design est la séparation entre la saisie interne des données dans une installation et l'utilisation externe des données (fig. 1). On distingue trois rôles:
Une installation est fournisseur de données. Les données sont créées dans le système de contrôle des processus et sont disponibles localement en tant que valeurs actuelles et données d'archives. C'est le fournisseur de données qui décide quelles séries de mesures sont disponibles et si elles peuvent être utilisées en externe.
L'intermédiaire de données met à disposition l'accès API standardisé selon PDA et se charge du contrôle d'accès. Sur le plan technique, l'intermédiaire de données est connecté de telle sorte que l'installation établit la connexion de l'intérieur vers l'extérieur ou via VPN. Ainsi, aucune connexion entrante depuis Internet n'est nécessaire directement sur le système de contrôle. Les détails sur la manière dont les données sont lues en interne à partir du système de gestion concerné restent chez le fournisseur du système et ne sont pas divulgués.
Les utilisateurs de données accèdent aux données libérées via l'API de l'intermédiaire de données. Les utilisateurs typiques sont les systèmes de données d'exploitation et de maintenance, les bureaux d'ingénieurs, les instituts de recherche, les autorités ainsi que les applications destinées à l'information du public.
Ce modèle de rôle permet de maintenir une spécification PDA uniforme dans l'ensemble du secteur, tandis que les différents systèmes de contrôle et installations ne doivent pas modifier leur structure de données interne. Le fournisseur du système de contrôle peut mettre en œuvre de manière autonome sa connexion spécifique au système avec ses propres systèmes d'archivage de données et différents modèles de variables et ne mettre à disposition que la vue PDA normalisée vers l'extérieur. Cela réduit considérablement les efforts d'intégration pour les utilisateurs de données, car il n'est pas nécessaire de comprendre et d'implémenter un nouveau format de données pour chaque installation.
Le processus d'autorisation, de validation et de consultation entre les trois rôles est représenté à la figure 2. Ainsi, le processus d'autorisation est toujours compréhensible pour le fournisseur de données. Un processus de validation clair et compréhensible est prévu pour légitimer l'utilisation des données. La figure 2 illustre ce processus en trois étapes entre l'utilisateur de données (A), le fournisseur de données (C) et l'intermédiaire de données (B). Tout d'abord, l'utilisateur de données fait une demande d'autorisation pour une installation concrète et remet à cet effet un document signé. Ensuite, la validation et l'autorisation ont lieu : l'intermédiaire de données vérifie la signature et la durée de validité et, en cas de contrôle positif, ajoute l'utilisateur de données à la liste des utilisateurs autorisés pour cette installation. Une fois l'autorisation obtenue, l'utilisateur de données peut demander des données de processus via l'intermédiaire de données. L'intermédiaire de données transmet la demande au fournisseur de données et lui renvoie la réponse.
En perspective, ce processus doit être mis en œuvre sous la forme d'un processus numérique de demande et de validation. Les utilisateurs de données doivent pouvoir s'enregistrer eux-mêmes et envoyer des demandes d'accès directement au fournisseur de données. La décision concernant l'acceptation, l'étendue, la durée et la révocation revient au fournisseur de données. Les validations et les accès sont documentés et consignés de manière compréhensible. Dans le prototype actuel, ces étapes sont encore effectuées manuellement par les acteurs dans leurs rôles respectifs.
Un intermédiaire de données, appelé "Plant Data Access", est exploité par Chestonag Automation AG en tant qu'implémentation de référence. Celui-ci a été développé et testé durant la phase pilote en collaboration avec HunzikerBetatech AG en tant qu'utilisateur de données, en fonction des exigences concrètes de la planification et de l'évaluation. Les expériences tirées du pilote sont prises en compte dans le développement de la spécification. L'objectif est une spécification ouverte, librement utilisable, de sorte que d'autres intermédiaires de données, notamment d'autres fournisseurs de systèmes pilotes, puissent implémenter et exploiter leur version de PDA.
Â
Le standard présenté ici garantit une bonne protection des données et une sécurité élevée. Elle permet en outre à chaque fournisseur de données de garder le contrôle de ses propres données. Chaque utilisateur de données doit donc pouvoir être clairement identifié et autorisé en fonction de ses droits d'accès. Le fonctionnement d'une API permet de consigner automatiquement les accès. Dans le cas concret, cela est effectué par l'intermédiaire de données concerné (fig. 2). PDA permet aux fournisseurs de données de définir précisément quels points de données sont publiés et quels utilisateurs sont autorisés à consulter les données. Les autorisations d'accès peuvent être séparées au niveau de l'installation ainsi que pour la lecture et l'écriture et peuvent en outre être limitées dans le temps.
En outre, il est important de souligner que chaque intermédiaire de données et chaque fournisseur de données ne fournit que l'accès à l'interface vers l'extérieur. Cela signifie que la manière exacte dont les données sont consultées en interne est laissée à l'appréciation des intermédiaires de données ou des fournisseurs de données. L'architecture SNCC sous-jacente reste également secrète.
L'API offre un accès simple et uniforme aux données de placement de différents fournisseurs de données. Pour le secteur, cela signifie: Les données sont comparables et peuvent être utilisées sans effort technique supplémentaire.
Pour les exploitants des STEP, la priorité d'une interface de données de processus standardisée est un accès fiable et reproductible aux données à des fins internes et externes. Un format uniforme pour les séries temporelles et les métadonnées réduit les demandes de précisions et les rapprochements répétés lors des demandes de données, car la période, la résolution, les unités et les désignations peuvent être mises à disposition de manière plus cohérente. Les évaluations pour l'optimisation de l'exploitation, les simulations ou les études comparatives peuvent ainsi être réalisées plus rapidement et avec moins d'efforts de concertation. Les données restent sous le contrôle de l'exploitant, qui détermine qui a accès à quelles données.
Pour la cybersécurité, il est essentiel qu'aucune connexion entrante ne soit requise dans le réseau du fournisseur de données à partir de réseaux externes. Dans l'approche API prévue, l'installation établit la connexion de l'intérieur vers l'extérieur, tandis que l'authentification, l'autorisation et la journalisation sont effectuées de manière centralisée par l'intermédiaire du fournisseur de données (fig. 2). Ainsi, les accès aux données restent contrôlables et traçables, et aucun détail interne au système de contrôle des processus n'est divulgué aux utilisateurs de données.
Les données étant mises à disposition dans un format uniforme, les systèmes d'analyse et d'évaluation peuvent être connectés beaucoup plus facilement. Différentes solutions logicielles peuvent être utilisées de manière interopérable, indépendamment de la structure technique de chaque installation. En outre, les données peuvent être consultées directement à l'aide de langages de programmation courants. Les utilisateurs doivent nettement moins se préoccuper de la manière dont les données sont structurées sur une STEP donnée.
C'est volontairement que nous renonçons ici à une présentation approfondie des systèmes d'IA actuels. L'interface offre cependant des pools de données facilement accessibles, qui offrent également des possibilités d'entraînement de systèmes d'IA. De plus, un système entraîné en conséquence pourrait renvoyer la variable de commande à la STEP via cette interface.
Les prochaines étapes consisteront à transformer l'approche actuelle en un outil indépendant des fabricants et viable pour l'ensemble du secteur. L'accent sera mis sur la description des points de données, des séries temporelles et des métadonnées de manière à ce qu'ils puissent être comparés entre les installations sans que les exploitants ne soient obligés de modifier l'environnement interne de leur système de contrôle. Parallèlement, il s'agit d'ouvrir la voie à d'autres implémentations, afin que d'autres intermédiaires de données, notamment d'autres fournisseurs de systèmes de contrôle, puissent reprendre le PDA et exploiter leurs propres plates-formes.
A long terme, il en résultera une base commune pour des applications réutilisables: de l'optimisation de l'exploitation et de la simulation au monitoring supérieur des cours d'eau et à la communication transparente, en passant par la recherche et les études comparatives.
La spécification existe dans une première version et est actuellement précisée dans le cadre de tests pilotes. Les réactions de l'exploitation, de la planification, de la recherche, des autorités, d'applications tierces et d'autres fournisseurs de systèmes de guidage sont expressément souhaitées afin que les exigences soient couvertes de manière pratique et que la standardisation puisse être largement soutenue.
Pour les groupes d'utilisateurs intéressés, il est possible d'obtenir un accès test pour examiner des cas d'utilisation et apporter des commentaires à la standardisation.
https://plant-data-access.chestonag.ch/api/v1/docs
Avec l'abonnement en ligne, lisez le E-paper «AQUA & GAS» sur l'ordinateur, au téléphone et sur la tablette.
Avec l'abonnement en ligne, lisez le E-paper «Wasserspiegel» sur l'ordinateur, au téléphone et sur la tablette.
Kommentare (0)