Plattform für Wasser, Gas und Wärme
Mit dem Brett auf der Welle tanzen – eins sein mit der Natur, dem Wasser, dem Körper. Surfende finden dieses Gefühl nicht nur an den Küsten des Atlantiks oder Pazifiks, sondern auch in der Schweiz, zum Beispiel auf der Flusswelle in der Reuss in Bremgarten. Stürzt das Wasser über zwei unter der Wasseroberfläche liegende Wehre, wird dieses stark beschleunigt und formt die Welle. Dafür ist ein minimaler Wasserpegel nötig, wie es oft nach Regen der Fall ist.
Viel Regen führt aber nicht nur zu idealen Surfbedingungen, sondern oft auch zu einer Überschreitung der Kapazitäten der Abwasserentsorgung. Die Einträge durch die dadurch nötige Mischwasserentlastung in Gewässer sind unsichtbar, unvermeidbar und gesetzlich zulässig. Sie erhöhen jedoch temporär die Keimbelastung im Wasser, was in der Vergangenheit vereinzelt zu Krankheitsfällen bei Surfenden führte. Die Problematik wurde medial wie auch politisch aufgegriffen – und die Idee nach einem Echtzeit-Informationssystem rund um die Wasserqualität kam auf.
Die nötigen Daten dafür existieren heutzutage punktuell, je nach Anlage und Verband isoliert und in verschiedenen Prozessleitsystemen (PLS) und Formaten: Pegelstände, Entlastungsmengen, Zeitpunkte, Entfernungen, Betriebszustände etc. Ein Echtzeit-Informationssystem würde aber voraussetzen, dass die relevanten Daten kontinuierlich erfasst, zusammengeführt und miteinander in Beziehung gesetzt werden. Ähnliche Anforderungen bestehen für Betriebsdatenauswertungen und Kostenberechnungen, bei dynamischer Netzbewirtschaftung oder generell für Gewässermonitoring. Für diese Fragestellungen braucht es einen Datenstandard und eine offene Schnittstelle.
Der Plant Data Access (PDA) ist ein konkreter Vorschlag für die standardisierte, systemunabhängige Datenschnittstelle für Trinkwasser- und Abwasserdaten.
Je nach Prozessleitsystem liegen Messdaten in herstellerspezifischen (proprietären) Formaten in verschiedenen Datenbanken vor. Die Struktur der Daten, beispielsweise hinsichtlich Aufzeichnungsdauer, Auflösung, zeitlicher Rasterung, Objektbezeichnung oder Metadaten, kann für jedes System variieren. Der Transfer aus den meist isolierten Netzwerken geschieht manuell, teilweise per Datenträger oder über temporäre Ablagen. Wenn Daten unvollständig sind, Metadaten fehlen oder Zeitraster nicht passen, beginnt der Prozess wieder von vorne. Das führt zu Verzögerungen, unnötigen Schnittstellenaufwänden und verhindert, dass sich Fachpersonen auf die eigentliche Analyse, Optimierung oder den Betrieb konzentrierenkönnen.
Dieser Situation wirkt der neue Ansatz in Form der PDA-Schnittstelle entgegen. Sie basiert auf dem heute weltweit verbreiteten Webstandard REST-API (s. «Was ist eine API?»).
Die Daten können damit über einen öffentlich erreichbaren Endpunkt (Webadresse) abgefragt werden. Über die Schnittstelle können sowohl aktuelle als auch historische Daten abgerufen werden, sofern der Nutzer dazu berechtigt ist. Damit wird der Zugang zu Daten vereinheitlicht, die für viele Akteure relevant sind. API ermöglichen die technische Trennung zwischen dem PLS und dem Zugriff auf die Daten. Dadurch ist es möglich, Daten unabhängig von der Struktur der Datenbank einheitlich abzurufen.
Eine API (Application Programming Interface) ist eine standardisierte Schnittstelle, die es Systemen ermöglicht, miteinander zu kommunizieren und Daten auszutauschen.
Der Zugriff auf eine solche API erfolgt über eine Internetadresse (URL). Die API stellt sicher, dass Daten und Metadaten stets in einem einheitlichen und klar definierten Format abgefragt und bereitgestellt werden. Man kann sich die Struktur dieser URL wie die Pfade zu Ordnern und Dateien auf einem Computer vorstellen. In diesem System entspricht jede Datei einer Messreihe. Da auch Ordner sichtbar sind, ist es möglich, bestimmte Objekte aufzulisten oder nach Eigenschaften zu filtern. Noch anschaulicher: Eine API ist wie eine Servicekraft im Restaurant – als Gast spricht man nicht direkt mit der Küche (dem PLS), sondern mit der Servicekraft (API), die dann die Bestellung überbringt und ausliefert.
Eine API ermöglicht einen einheitlichen Zugang zu sämtlichen Systemen, auch wenn diese technisch unterschiedlich aufgebaut sind. Beispielsweise ist die Nummerierung des Anlagenkennzeichnungssystem (AKS) je nach Anlage unterschiedlich und eine übergeordnete Angleichung nahezu unmöglich. PDA kann als Grundlagesystem für die Standardisierung der Objektidentifikation dienen. Die API definiert den Übermittlungsstandard, während die technische Umsetzung weiterhin bei den jeweiligen Datenvermittlern verbleibt. Eine API stellt ausschliesslich Rohdaten bereit und enthält keine Benutzeroberfläche. Somit bildet sie die technische Basis für Anwendungen, Auswertungen und weiterführende Services, ist jedoch kein Endnutzer-Produkt.
In den letzten Monaten wurde ein Architekturansatz entwickelt, der den Datentransport und die Datenbereitstellung vom dateibasierten Vorgehen hin zu einer standardisierten Web-API überführt (Fig. 1). Grundlage ist eine definierte OpenAPI-Spezifikation1, nachfolgend PDA genannt.
Die Schnittstelle unterstützt Lesezugriffe und, sofern explizit freigegeben, auch Schreibzugriffe. Die Berechtigungen werden nutzerspezifisch und pro Datenpunkt vergeben. Als zusätzliche Sicherheitsstufe sind Schreibzugriffe im Konzept nur möglich, wenn der jeweilige Datenpunkt anlageseitig freigeschaltet ist. Schreibzugriffe werden zusätzlich anlageseitig protokolliert.
Kernelement des Designs ist die Trennung zwischen der internen Datenerfassung in einer Anlage und der externen Datennutzung (Fig. 1). Dabei werden drei Rollen unterschieden:
Eine Anlage ist Datenanbieterin. Die Daten entstehen im Prozessleitsystem und liegen lokal als aktuelle Werte und Archivdaten vor. Welche Messreihen verfügbar sind und ob sie extern genutzt werden dürfen, bleibt eine Entscheidung der Datenanbieterin.
Der Datenvermittler stellt den standardisierten API-Zugang gemäss PDA bereit und übernimmt die Zugriffskontrolle. Technisch wird der Datenvermittler so angebunden, dass die Anlage die Verbindung von innen nach aussen oder via VPN aufbaut. Damit sind keine eingehenden Verbindungen aus dem Internet direkt auf das Leitsystem erforderlich. Die Details, wie Daten intern aus dem jeweiligen Leitsystem gelesen werden, bleiben dabei beim Systemlieferanten und werden nicht offengelegt.
Datennutzende greifen über die API des Datenvermittlers auf die freigegebenen Daten zu. Typische Nutzende sind Betriebsdaten- und Wartungssysteme, Ingenieurbüros, Forschungseinrichtungen, Behörden sowie Anwendungen für die Information der Öffentlichkeit.
Dieses Rollenmodell erlaubt es, die PDA-Spezifikation branchenweit einheitlich zu halten, während unterschiedliche Leitsysteme und Anlagen ihre interne Datenstruktur nicht ändern müssen. Der Leitsystemlieferant kann seine systemspezifische Anbindung an die eigenen Daten-Archivierungssysteme und unterschiedliche Variablenmodelle eigenständig umsetzen und lediglich die normierte PDA-Sicht nach aussen bereitstellen. Damit reduziert sich der Integrationsaufwand für Datennutzende deutlich, weil nicht pro Anlage ein neues Datenformat verstanden und implementiert werden muss.
Der Berechtigungs-, Freigabe- and Abfrageprozess zwischen den drei Rollen ist in Figur 2 dargestellt. Damit ist der Freigabeprozess für den Datenanbieter stets nachvollziehbar. Zur Legitimation der Datennutzung ist ein klarer, nachvollziehbarer Freigabeprozess vorgesehen. Figur 2 zeigt diesen Ablauf zwischen Datennutzer (A), Datenanbieter (C) und Datenvermittler (B) in drei Schritten. Zuerst stellt der Datennutzende eine Berechtigungsanfrage für eine konkrete Anlage und reicht dazu ein unterzeichnetes Dokument ein. Danach erfolgt die Validierung und Freischaltung: Der Datenvermittler prüft Signatur und Gültigkeitsdauer und ergänzt den Datennutzer bei erfolgreicher Prüfung in die Liste der für diese Anlage zugelassenen Nutzer. Nach erfolgter Autorisierung kann der Datennutzer über den Datenvermittler Prozessdaten abfragen. Der Datenvermittler leitet die Anfrage an den Datenanbieter weiter und liefert die Antwort zurück.
Perspektivisch soll dieser Ablauf als digitaler Anfrage- und Freigabeprozess umgesetzt werden. Datennutzende sollen sich selbst registrieren und Zugriffsanfragen direkt an den Datenanbieter stellen können. Die Entscheidung über Annahme, Umfang, Laufzeit und Widerruf liegt beim Datenanbieter. Freigaben und Zugriffe werden dabei nachvollziehbar dokumentiert und protokolliert. Im aktuellen Prototyp werden diese Schritte noch manuell durch die Akteure in den jeweiligen Rollen durchgeführt.
Als Referenzimplementierung wird ein Datenvermittler unter dem Namen «Plant Data Access» durch Chestonag Automation AG betrieben. Dieser wurde in der Pilotphase gemeinsam mit HunzikerBetatech AG als Datennutzerin auf konkrete Anforderungen aus Planung und Auswertung hin entwickelt und erprobt. Die Erfahrungen aus dem Pilot fliessen in die Weiterentwicklung der Spezifikation ein. Ziel ist eine offene, frei nutzbare Spezifikation, sodass weitere Datenvermittler, insbesondere weitere Leitsystemlieferanten, ihre Version von PDA implementieren und betreiben können.
Der hier vorgestellte Standard gewährleistet einen guten Datenschutz und hohe Sicherheit. Zudem ermöglicht er jedem Datenanbieter, die Kontrolle über die eigenen Daten zu behalten. Jeder Datennutzer muss deshalb eindeutig identifiziert und entsprechend seiner Zugriffsberechtigungen autorisiert werden können. Die Funktionsweise einer API ermöglicht die automatische Protokollierung von Zugriffen. Im konkreten Fall geschieht dies durch den jeweiligen Datenvermittler (Fig. 2). PDA ermöglicht es den Datenanbietern, genau zu definieren, welche Datenpunkte veröffentlicht werden und welche Nutzer das Einverständnis erhalten, Daten abzufragen. Die Zugriffsberechtigungen können auf Anlagenebene sowie für Lesen und Schreiben getrennt und zusätzlich zeitlich begrenzt werden.
Darüber hinaus ist es wichtig zu betonen, dass jeder Datenvermittler und jeder Datenanbieter nur den Zugang zur Schnittstelle nach aussen bereitstellt. Das heisst, wie genau die Daten intern abgefragt werden, bleibt den Datenvermittlern oder Datenanbietern überlassen. Auch die dahinterliegende PLS-Architektur bleibt geheim.
Die API bietet einen einfachen und einheitlichen Zugang zu Anlagedaten verschiedener Datenanbieter. Für die Branche bedeutet dies: Die Daten sind vergleichbar und können ohne zusätzlichen technischen Aufwand genutzt werden.
Für ARA-Betreiber steht bei einer standardisierten Prozessdatenschnittstelle ein zuverlässiger und wiederholbarer Zugang zu Daten für interne und externe Zwecke im Vordergrund. Ein einheitliches Format für Zeitreihen und Metadaten reduziert Rückfragen und wiederholte Abstimmungen bei Datenanfragen, weil Zeitraum, Auflösung, Einheiten und Bezeichnungen konsistenter bereitgestellt werden können. Dadurch lassen sich Auswertungen für die Betriebsoptimierung, Simulationen oder Vergleichsstudien schneller und mit weniger Abstimmungsaufwand umsetzen. Die Daten bleiben unter der Kontrolle des Betreibers, der bestimmt, wer auf welche Daten Zugriff hat.
Für die Cybersicherheit ist es entscheidend, dass keine eingehenden Verbindungen aus externen Netzen in das Datenanbieter-Netzwerk erforderlich sind. Im vorgesehenen API-Ansatz baut die Anlage die Verbindung von innen nach aussen auf, während Authentisierung, Berechtigung und Protokollierung zentral über den Datenvermittler erfolgen (Fig. 2). Dadurch bleiben Datenzugriffe kontrollierbar und nachvollziehbar, und es werden keine internen Details des Prozessleitsystems gegenüber Datennutzern offengelegt.
Da die Daten in einem einheitlichen Format bereitgestellt werden, lassen sich Analyse- und Auswertungssysteme deutlich einfacher anbinden. Unterschiedliche Softwarelösungen können unabhängig vom technischen Aufbau der jeweiligen Anlage interoperabel genutzt werden. Ausserdem können die Daten direkt über gängige Programmiersprachen abgefragt werden. Nutzer müssen sich deutlich weniger damit beschäftigen, wie Daten auf einer bestimmten ARA strukturiert sind.
Auf eine vertiefte Darstellung aktueller KI-Systeme wird hier bewusst verzichtet. Die Schnittstelle bietet jedoch einfach zugängliche Datenpools, die auch Möglichkeiten zum Training von KI-Systemen bieten. Ferner könnte ein entsprechend trainiertes System die Steuervariable über diese Schnittstelle wieder an die ARA zurückliefern.
In den nächsten Schritten soll aus dem heutigen Ansatz ein branchenweit tragfähiges, herstellerunabhängiges Werkzeug entstehen. Im Fokus steht, dass Datenpunkte, Zeitreihen und Metadaten so beschrieben sind, dass sie zwischen Anlagen vergleichbar werden, ohne dass Betreiber ihre interne Leitsystemwelt umbauen müssen. Parallel soll der Weg für weitere Implementierungen geöffnet werden, damit auch andere Datenvermittler, insbesondere andere Leitsystemlieferanten, PDA übernehmen und eigene Plattformen betreiben können.
Langfristig entsteht so eine gemeinsame Basis für wiederverwendbare Anwendungen: von Betriebsoptimierung und Simulation über Forschung und Vergleichsstudien bis zu übergeordnetem Gewässermonitoring und transparenter Kommunikation.
Die Spezifikation liegt in einer ersten Version vor und wird aktuell im Rahmen von Pilotierungen weiter präzisiert. Rückmeldungen aus Betrieb, Planung, Forschung, Behörden, Drittanwendungen und von weiteren Leitsystemlieferanten sind ausdrücklich erwünscht, damit die Anforderungen praxistauglich abgedeckt werden und die Standardisierung breit getragen werden kann.
Für interessierte Nutzergruppen besteht die Möglichkeit, einen Testzugang zu erhalten, um Anwendungsfälle zu prüfen und Rückmeldungen in die Standardisierung einzubringen.
https://plant-data-access.chestonag.ch/api/v1/docs
«AQUA & GAS» gibt es auch als E-Paper. Abonnenten, SVGW- und/oder VSA-Mitglieder haben Zugang zu allen Ausgaben von A&G.
Den «Wasserspiegel» gibt es auch als E-Paper. Im SVGW-Shop sind sämtliche bisher erschienenen Ausgaben frei zugänglich.
Kommentare (0)