DE102019132173A1

DE102019132173A1 - Verfahren zur Konfiguration zur Übertragung von Daten von einem Feldgerät

Info

Publication number: DE102019132173A1
Application number: DE102019132173.5A
Authority: DE
Inventors: Stefan Robl; Holger Eberhard; Stefan Kempf; Marco Bezzon
Original assignee: Endress and Hauser Conducta GmbH and Co KG
Current assignee: Endress and Hauser Conducta GmbH and Co KG
Priority date: 2019-11-27
Filing date: 2019-11-27
Publication date: 2021-05-27
Also published as: CN112866001B; US11689614B2; CN112866001A; US20210176306A1

Abstract

Die Erfindung offenbart ein Verfahren zur schrittweisen Konfiguration zur Übertragung von Daten (ND) von einem Feldgerät (FG) zu zumindest einem Zielsystem (C), umfassend die Schritte: Erstellen einer Konfiguration (K), umfassend mindestens einer Subkonfiguration für das Feldgerät (FG) und einer Subkonfiguration für das Zielsystem (C); Senden der Konfiguration (K) vom Feldgerät (FG) an das Zielsystem (C); und Senden der Daten (ND) vom Feldgerät (FG) an das Zielsystem (C), wobei die Daten (ND) basierend auf der Subkonfiguration des Feldgeräts (FG) im Feldgerät (FG) weitergeleitet, verarbeitet, gespeichert oder verworfen werden, und wobei die Daten (ND) basierend auf der Subkonfiguration des Zielsystems (C) im Zielsystem verarbeitet oder gespeichert werden.

Description

Die Erfindung betrifft ein Verfahren zur schrittweisen Konfiguration der Übertragung von Daten von einem Feldgerät zu zumindest einem Zielsystem.
Ein Feldgerät ist eine technische Einrichtung im Bereich der Automatisierungstechnik, die mit einem Produktionsprozess in direkter Beziehung steht. „Feld“ bezeichnet in der Automatisierungstechnik den Bereich außerhalb von Schaltschränken bzw. Leitwarten. Feldgeräte können somit sowohl Aktoren (Stellglieder, Ventile etc.) als auch Sensoren oder Messumformer in der Fabrik- und Prozessautomation sein.
Feldgeräte aus dem Bereich der Prozessautomatisierung kommunizieren über sogenannte Plant Networks (z.B. die Feldbusse HART, PROFIBUS, PROFINET etc.) mit einem Prozessleitsystem. Möchte ein Anwender die Feldgeräte mit weiteren informationsverarbeitenden Systemen (z.B. Datenbankserver, Cloud-Dienste etc.) verbinden, kann dies heute mittels „Edge Devices“ durchgeführt werden, welche spezifisch für die verschiedenen Plant Network-Typen angeboten werden. Diese Systeme lesen die gewünschten Daten über das Plant Network aus den Feldgeräten und übertragen diese in ein davon getrenntes weiteres Datennetzwerk zum vorgesehenen Zielsystem. Ein Edge-Gerät ist ein Gerät, das einen Einstiegspunkt in das Plant Network bietet. Beispiele hierfür sind Router, Routing-Switches oder spezielle Zugangseinrichtungen, etwa über das Intranet. Edge-Geräte bieten unter Umständen auch Verbindungen zu Carrier- und Service Provider-Netzwerken. Edge-Geräte können zwischen einer Art von Netzwerkprotokoll und einer anderen übersetzen.
Als Alternative zu Edge-Devices sieht die Namur Open Architecture ein OPC/UA-Gateway vor, welches das Konzept der Datendiode mittels OPC/UA-Security-Mechanismen realisiert und das Informationsmodell aus einem vom Gerätehersteller bereitgestelltem FDI-Package erzeugt. Dieses Gateway kann als Softwarekomponente im Prozessleitsystem oder als getrennter Connectivity-Server realisiert werden. Auf diese Weise kann unabhängig vom konkreten Plant Network in generischer Form auf die Daten der Feldgeräte zugegriffen werden. Um jedoch die Daten an ein weiteres informationsverarbeitendes System weiterleiten zu können, muss ein zusätzlicher Kommunikationsknoten (z.B. Gateway) zwischen dem genannten OPC/UA-Gateway und dem Zielsystem vermitteln.
In beiden Ausführungsformen existiert das Problem, dass die vermittelnden Systeme (Edge Device bzw. Gateway) eine anwendungsspezifische Konfiguration erfordern, die Information darüber enthält, welche Daten, in welcher Form und in welcher Frequenz von welchem Feldgerät benötigt werden und an welches Zielsystem zu transportieren sind.
Insbesondere Edge Devices sind in der Regel proprietäre, d.h. geschlossene Systeme, die über keine offene Datenschnittstelle verfügen, welche einem Gateway eines Drittanbieters Zugriff auf die benötigten Daten ermöglichen würden.
Selbst wenn der Zugriff auf die Daten möglich ist, müssen im Anlagensystem des Anwenders anwendungsspezifische Einstellungen getroffen werden, damit die benötigten Daten das Zielsystem erreichen können. Ändert sich die Zusammensetzung der vom Zielsystem benötigten Daten im Laufe der Zeit (z.B. durch Konfigurationsänderungen), erfordert dies einen Eingriff in das Anlagensystem des Anwenders, was in der Praxis aufgrund des manuellen Eingriffs des Anwenders an zentraler Stelle wenig praxistauglich ist.
Der manuelle Eingriff erfordert auch, dass der Anwender mit den einzelnen Systemen gut vertraut sein muss, um eine korrekte Konfiguration zu erzielen. Dies erfordert ein hohes Maß an fachlichem Wissen des Anwenders über das Gesamtsystem, welches aus vielen Einzelkomponenten unterschiedlichster Hersteller bestehen kann.
Der Erfindung liegt die Aufgabe zugrunde, die Verbindung zwischen Feldgeräten und übergeordneten informationsverarbeitendem Zielsystemen so zu gestalten, dass ein hohes Maß an Flexibilität gegenüber der zugrunde liegenden Kommunikationsinfrastruktur gewährleistet ist und gleichzeitig der für den Anwender anfallende Konfigurationsaufwand minimiert wird.
Die Aufgabe wird gelöst durch ein Verfahren, umfassend die Schritte: Erstellen einer Konfiguration, umfassend mindestens einer Subkonfiguration für das Feldgerät und einer Subkonfiguration für das Zielsystem; Senden der Konfiguration vom Feldgerät an das Zielsystem; und Senden der Daten vom Feldgerät an das Zielsystem, wobei die Daten basierend auf der Subkonfiguration des Feldgeräts im Feldgerät weitergeleitet, verarbeitet, gespeichert oder verworfen werden, und wobei die Daten basierend auf der Subkonfiguration des Zielsystems im Zielsystem verarbeitet oder gespeichert werden.
Durch das oben dargelegte Verfahren ist es möglich, dass ein Feldgerätehersteller z.B. über eine Cloud-Infrastruktur (im Sinne des Verfahrens ein „Zielsystem“, siehe unten) in die Lage versetzt wird, einem Anwender „Cloud-Apps“ anzubieten, die auf die Daten der verwendeten Feldgeräte zurückgreifen können. Dabei wird eine dedizierte, also manuelle, Konfiguration aller an der Datenübertragung beteiligten Kommunikationsknoten vermieden.
Die Art (Datenformat) und Qualität (z.B. Auflösung, Abtastfrequenz) der vom Feldgerät zur Verfügung gestellten Daten entspricht nicht notwendigerweise den Anforderungen des Zielsystems, also beispielsweise einer Cloud-Anwendung. Durch das Verfahren ergibt sich eine flexible Möglichkeit an den beteiligten Kommunikationsknoten die erforderlichen Datenanpassungen ohne explizites Softwareupdate oder manuellen Eingriff selbständig durchführen können.
Die Kommunikation ist dabei so ausgestaltet, dass eine ungewollte Manipulation eines Feldgeräts von außen zuverlässig verhindert und dadurch ein negativer Einfluss auf die innere Anlagensicherheit ausgeschlossen wird. Gleichzeitig ist das Verfahren jedoch für den Anwender so transparent strukturiert, dass dieser ohne tiefgehende Security-Analysen bereits auf „den ersten Blick“ ein klares Verständnis über die Eigenschaften der Kommunikationsverbindung erhalten kann.
Grundsätzlich sind ein oder mehrere Zielsysteme möglich, d.h. das Feldgerät kann auch gleichzeitig oder nacheinander an verschieden Zielsysteme Daten übertragen. Dabei spaltet sich der Datenfluss potentiell an jeder Stelle, an der Daten an eine weitere Stelle weitergereicht werden, auf. Es entsteht somit potentiell ein ganzer Datenflussbaum.
Eine Ausgestaltung sieht vor, dass auf dem Datenpfad zwischen Feldgerät und Zielsystem ein oder mehrere Zwischensysteme zwischengeschaltet sind, diese jeweils die sie betreffende Subkonfiguration der an sie übermittelten Konfiguration berücksichtigen und die empfangen Daten basierend auf ihrer Subkonfiguration weiterleiten, verarbeiten, speichern oder verwerfen.
Eine Ausgestaltung sieht vor, dass die Subkonfiguration für das Feldgerät so ausgestaltet ist, dass dadurch die Daten im Feldgerät so weitergeleitet, verarbeitet, gespeichert oder verworfen werden, dass ein im Datenfluss nachfolgendes Zwischensystem in der Lage ist, mit diesen Daten umgehen zu können.
Eine Ausgestaltung sieht vor, dass die Subkonfiguration für das Zwischensystem so ausgestaltet ist, dass dadurch die Daten im Zwischensystem so weitergeleitet, verarbeitet, gespeichert oder verworfen werden, dass ein im Datenfluss nachfolgendes weiteres Zwischensystem oder das Zielsystem in der Lage ist mit diesen Daten umgehen zu können.
Eine Ausgestaltung sieht vor, dass die jeweilige Subkonfiguration des aussendenden Systems aus der an das darauffolgende Zwischensystem weitergereichten Konfiguration entfernt wird. Somit entfernt jede Quelle von Daten die weitergereichte Konfiguration um seine eigene Subkonfiguration. Insbesondere im Falle von mehreren Zielsystemen ist es so, dass alle Subkonfigurationen und Daten, die nicht den jeweiligen Folgezweig im Kommunikationsfluss betreffen, entfernt werden.
Eine Ausgestaltung sieht vor, dass die Konfiguration und die Daten in einem Containerformat gesendet werden.
Eine Ausgestaltung sieht vor, dass die Konfiguration zyklisch gesendet wird.
Eine Ausgestaltung sieht vor, dass die Daten, insbesondere basierend auf der jeweiligen Subkonfiguration, durch das zumindest eine Zwischensystem geändert werden. In einer Ausgestaltung kann die Subkonfiguration des Feldgeräts dieses bereits anweisen, die Daten vor Aussendung zu verändern. Effektiv kann jede Subkonfiguration eine Datenverarbeitung im jeweiligen System bzw. Zwischensystem anweisen.
Eine Ausgestaltung sieht vor, dass die Subkonfiguration jeweilige Informationen bezüglich Zieladresse, Abtastintervall, Kommunikationsparameter, insbesondere Einwahlknoten, Schnittstellengeschwindigkeiten und/oder Datenformate, Zeitstempel, Softwarefragmente, insbesondere Skripte und/oder Programmmodule, Seriennummer und/oder Namen des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystems, oder einer Programmierschnittstelle des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystems umfasst.
Eine Ausgestaltung sieht vor, dass es sich bei den Daten um Informationen bezüglich des Status und/oder Systeminformationen des Feldgeräts, von am Feldgerät angeschlossenen Systemen, insbesondere Sensoren, und/oder des Zwischensystems, und/oder um Prozesswerte, insbesondere Messwerte von am Feldgerät angeschlossenen Systemen, insbesondere Sensoren, handelt.
Eine Ausgestaltung sieht vor, dass das Zielsystem als zumindest ein System zum Cloud Computing und/oder Speichern der Daten ausgestaltet ist.
In einer Ausgestaltung ist das Zielsystem ein Datenlogger, eine Anzeige, eine SPS (die so Ihr Programm und die sie steuernden Daten erhält) oder ein weiteres Feldgerät, insbesondere ein Aktor, etwa ein Steuerventil, welches durch die transportierten Nutzdaten gesteuert wird.
Wie oben bereits erläutert, kann es sein, dass das Zielsystem der einzige Verbindungspartner des Feldgeräts ist. Die Konfiguration beschreibt dann die Subkonfiguration des Feldgeräts und des Zielsystems zugleich; eine manuelle Einzelkonfiguration der beiden Systeme entfällt.
Eine Ausgestaltung sieht vor, dass die Konfiguration verschlüsselt, und/oder mit einer Signatur versehen und/oder mit einer Prüfsumme versehen wird.
Eine Ausgestaltung sieht vor, dass das Senden der Daten und der Konfiguration ausschließlich unidirektional erfolgt.
Eine Ausgestaltung sieht vor, dass die Subkonfiguration des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystem am Feldgerät erstellt wird.
Eine Ausgestaltung sieht vor, dass die Subkonfiguration des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystems mittels einer Mobile App, Web-App, Webanwendung, Progressive Web App oder einer Anwendungssoftware für ein Mobilgerät oder einen Personal Computer erstellt wird.
Die Aufgabe wird weiter gelöst durch ein Feldgerät, das geeignet ist, die Schritte des oben beschriebenen Verfahrens auszuführen.
In einer Ausgestaltung ist das Feldgerät ein Messumformer. Im Allgemeinen ist Messumformer ein Gerät, das eine Eingangsgröße entsprechend einer festen Beziehung in eine Ausgangsgröße umformt. Häufig wird auch der englische Begriff Transmitter verwendet. Hier ist beispielsweise das Produkt „Liquiline M CM42“ oder der 4-Kanal-Messumformer „Liquiline CM444“ der Anmelderin zu nennen, als ein Beispiel für einen Messumformer für pH-/Redox-, Leitfähigkeits-Sauerstoffmessungen oder anderen in Anwendungen der Prozessautomatisierung.
Eine Ausgestaltung sieht vor, dass das Senden der Daten und der Konfiguration ausschließlich unidirektional erfolgt in der Richtung von Feldgerät zu Zielsystem und/oder dem oder den Zwischensystem/Zwischensystemen. Das Feldgerät wirkt an seinem Datenausgang somit als Datendiode.
In einer Ausgestaltung umfasst das Feldgerät einen Rückkanal, der eine Datenverbindung zum Feldgerät vom Zielgerät und/oder dem oder den Zwischensystem/Zwischensystemen freigibt.
In einer Ausgestaltung umfasst der Rückkanal einen, insbesondere mechanischen und/oder elektrischen Schalter, der den Rückkanal schließt.
Eine Ausgestaltung sieht vor, dass das Feldgerät eine Erweiterungskomponente, umfasst, wobei die Erweiterungskomponente zumindest eine Datenverarbeitungseinheit, einen Speicher und eine Kommunikationsschnittstelle zu einem darauffolgenden Zwischensystem und/oder zu dem Zielsystem umfasst.
Eine Ausgestaltung sieht vor, dass die Erweiterungskomponente ein Einsteckmodul in das Feldgerät ist.
Eine Ausgestaltung sieht vor, dass das Feldgerät zumindest zwei Zwischensysteme umfasst und diese hierarchisch aufgebaut sind. Ausgehend vom Feldgerät kann sich ein beliebig komplexer Verzweigungsbaum im Kommunikationsfluss ergeben: Jeder Knoten, d.h. jedes Zwischensystem, kann wiederum die Daten an einen oder mehrere andere(n) Knoten (Zwischensysteme) weitergeben.
Die Aufgabe wird weiter gelöst durch ein Computerprogrammprodukt, umfassend Befehle, die bewirken, dass das Feldgerät wie oben beschrieben die Verfahrensschritte wie oben beschrieben ausführt.
Die Aufgabe wird weiter gelöst durch ein computerlesbares Medium, auf dem das Computerprogramm wie oben beschrieben gespeichert ist.
Mittels der vorliegenden Anmeldung ist es somit möglich, ein Feldgerät an übergeordnete informationsverarbeitende Systeme anzubinden. Die Datenübertragung erfolgt dabei beispielsweise unidirektional vorwärtsgerichtet und kann über eine beliebige Anzahl von Kommunikationsknoten erfolgen. Die Datenübertragung erfolgt etwa in Form eines schrittweise weitergegebenen Containerformat-Datenpakets, welches von jedem Kommunikationsknoten modifiziert und mit weiteren Nutzdaten angereichert werden kann. Das Containerformat-Datenpaket enthält ausgehend vom ersten Kommunikationsknoten die Konfiguration, welche den kompletten Kommunikationspfad konfiguriert. Dadurch kann die Datenkommunikation von einem einzigen Ausgangspunkt vollständig konfiguriert werden, ohne dass der Anwender die einzelnen Kommunikationsknoten an sich kontaktieren und dediziert konfigurieren muss.
Dies wird anhand der nachfolgenden Figuren näherer erläutert.

1a/b zeigt eine Übersicht über das beanspruchte Verfahren in zwei Varianten.
2 zeigt eine Übersicht mit einer Ausgestaltung im Feldgerät.
3 zeigt eine Übersicht des Feldgeräts mit einer Erweiterungskomponente.
4 zeigt eine Übersicht über den Verlauf der Daten.

Die 1a/b zeigen zunächst eine Übersicht über das Verfahren. Das Verfahren dient der Konfiguration der Übertragung von Daten von einem Feldgerät FG zu einem Zielsystem. Es können zwischen dem Feldgerät FG und dem Zielgerät ein oder mehrere Zwischensysteme vorhanden sein, diese sind mit „I“, also 11, 12, 13 etc. bezeichnet. Ebenso können mehre Zielsystems vorhanden sein, diese sind mit „C“, also C1 und C2 bezeichnet.
Im Beispiel ist das Feldgerät FG als Messumformer ausgestaltet. An das Feldgerät FG angeschlossen sind ein oder mehrere Sensoren S. Der Sensor S umfasst zumindest ein Sensorelement zum Erfassen einer Messgröße der Prozessautomatisierung. Bei dem Sensor S handelt es sich dann etwa um einen pH-Sensor, auch als ISFET, im Allgemeinen einen ionenselektiven Sensor, einen Sensor zur Messung des Redoxpotentials, von der Absorption von elektromagnetischen Wellen im Medium, beispielsweise mit Wellenlängen im UV-, IR-, und/oder sichtbaren Bereich, des Sauerstoffs, der Leitfähigkeit, der Trübung, der Konzentration von nicht-metallischen Werkstoffen oder der Temperatur mit der jeweils entsprechenden Messgröße.
Der Messumformer FG ist mit dem Sensor S über eine Schnittstelle verbunden. Über die Schnittstelle werden beispielswese von der Messgröße abhängige Werte übertragen.
Der Messumformer FG ist mit einer übergeordneten Einheit, etwa einem Leitsystem PLS, über ein Kabel verbunden. Dies ist mit dem Bezugszeichen „Db“ in 2 dargestellt. Die Schnittstelle zwischen Sensor S und Messumformer FG ist etwa als galvanisch getrennte, insbesondere als induktive Schnittstelle ausgestaltet. Die mechanische Steckverbindung der Schnittstelle ist hermetisch dicht, so dass von außen keine Flüssigkeit, etwa das zu messende Medium, Luft oder Staub eindringen kann.
Es können auch mehrere Sensoren S an einen Messumformer FG angeschlossen werden. Es können gleiche oder unterschiedliche Sensoren angeschlossen werden. An den Messumformer FG können beispielsweise bis zu acht Sensoren angeschlossen werden.
Über die angesprochene Schnittstelle werden Daten (bidirektional) und Energie (unidirektional, d.h. vom Messumformer FG zum Sensor S) gesendet bzw. übertragen. Die Anordnung wird überwiegend in der Prozessautomatisierung angewendet.
Der Messumformer FG wandelt die Daten dazu in ein für das Leitsystem PLS verständliches Datenformat, etwa in einem entsprechenden Bus wie HART, Profibus PA, Profibus DP, Foundation Fieldbus, Modbus RS485 oder auch ein Ethernet basierter Feldbus wie EtherNet/IP, Profinet oder Modbus/TCP und/oder über 4..20 mA. Diese Daten werden dann an das Leitsystem PLS weitergeleitet. Gegebenenfalls kann dies mit einem Webserver kombiniert werden, d.h. diese können parallel zueinander betrieben werden.
Bei den zu übertragenden Daten, diese sind auch als Nutzdaten ND bezeichnet, handelt es sich um Information bezüglich des Status und/oder Systeminformationen des Feldgeräts FG, von am Feldgerät FG angeschlossenen Systemen, insbesondere Sensoren S, und/oder des Zwischensystems I, und/oder um Prozesswerte, insbesondere Messwerte von am Feldgerät FG angeschlossenen Systemen, insbesondere Sensoren S.
In 1a ist das Feldgerät FG mit einem ersten Zielsystem C1 und parallel mit einem zweiten Zielsystem C2 verbunden. Ebenso kann nur ein Zielsystem C1 an das Feldgerät angeschlossen sein. In 1b ist das Feldgerät FG über mehrere Zwischensysteme I mit einem ersten Zielsystem C1 und dieses ist mit einem zweiten Zielsystem C2 verbunden.
Ein oder mehrere Zwischensysteme I können sich auf einer Erweiterungskomponente E befinden, siehe 3. Die Erweiterungskomponente E kann als eigenständiges Bauteil oder als Teil des Feldgeräts ausgestaltet sein, siehe unten. Die Zwischensysteme können als Softwaremodule ausgestaltet sein und/oder Hardwarebauteile umfassen, siehe unten. Bei dem Zwischenmodul I kann es sich um ein Bauteil im Innern des Feldgeräts FG handeln. Ebenso kann das Zwischenmodul I ein beliebiger Computer im Netzwerk sein, wobei davon potentiell beliebig viele hintereinandergeschaltet sind.
1b zeigt eine Ausgestaltung mit drei in Reihe geschalteten Zwischensystemen 11, 12 und 13. Dabei handelt es sich beispielsweise bei 11 um einen Microkontroller oder ein System-on-a-Chip einem darauf laufenden Betriebssystem und entsprechenden Anwendungen. Bei 12 handelt es sich um ein (Software-)Modul zur Datenaufbereitung wie etwa zur Weiterleitung, Verarbeitung oder Speicherung. Bei 13 handelt es sich um ein Modul zur Kommunikation, etwa ein Drahtlosmodule wie ein LTE-Modem, WIFI-Router etc. oder aber ein drahtgebundenes Modul wie eine Ethernet-Modul. 3 zeigt eine Ausgestaltung der 1b mit fünf Zwischensystemen 11, 12, 13, 14 und 15. 11 kann wie oben als Microkontroller oder ein System-on-a-Chip einem darauf laufenden Betriebssystem und entsprechenden Anwendungen ausgestaltet sein.
Bei 12 handelt es sich um einen Speicher, der entweder lediglich die Daten ND speichert und/oder auf dem das Betriebssystem für 11 abgelegt ist. Bei 13 kann es sich um ein erstes Kommunikationsmodul, etwa ein LTE-Modem, GPRS, ein Modul für ein Long Range Wide Area Network etc. handelt. Bei 14 kann es sich um ein paralleles Kommunikationsmodule für WIFI handelt. Bei 15 kann es sich um eine RS232-Schnittstelle handeln. Die genannten Zwischensysteme 11-15 befinden sich auf der Erweiterungskomponente E. Die Erweiterungskomponente E ist etwa als Einschubkarte in das Feldgerät FG ausgestaltet.
Wie bereits erwähnt können die Zwischensysteme I aber auch als separate Systeme, etwa verschiedene Computer im Netzwerk, ausgestaltet sein.
Das Zielsystem ist beispielsweise ein System zum Cloud Computing und/oder Speichern der Daten ausgestaltet. Es können also im Zielsystem Verrechnungen mit den Daten durchgeführt werden. In der angesprochenen Ausgestaltung kann es sich bei dem Zielsystem als ein System zum Speicher der Daten handeln, etwa über eine Festplatte, Server, SD-Karte, USB-Datenträger etc. Im Allgemeinen handelt es sich bei dem Zielsystem um ein System, das außerhalb des Feldgeräts Daten speichert und/oder verarbeitet. Ebenso kann das Zielsystem ein weiteres Feldgerät, etwa ein Sensor oder Aktor (z.B. ein Stellglied, Ventil, ...) sein.
2 zeigt den schematischen Aufbau einer Kommunikationsverbindung vom Feldgerät FG zu einem Zielsystem C1. Das Feldgerät FG ist mittels einer (äußeren) Datenverbindung Do, z.B. über Ethernet, WLAN, LTE o.a. mit einem informationsverarbeitenden Zielsystem C1 verbunden. Hierzu wird innerhalb des Feldgeräts FG eine Datenverbindung Di („innere Datenverbindung“) über ein Kommunikationsmodul 11 realisiert. Das Kommunikationsmodul 11 erhält seine Daten über die innere Datenverbindung Di, welche mit dem Basismodul BM verbunden ist. Das Kommunikationsmodul ist hier als erstes Zwischensystem 11 ausgestaltet und kann sich direkt im Feldgerät, davon abgesetzt, oder im Feldgerät aber auf einer anderen Hardwarebaugruppe befinden. Das Basismodul BM des Feldgerät ist beispielsweise als Microkontroller ausgestaltet. Das Basismodul BM ist das erste Glied in der Kette der Konfiguration K und bildet die ursprüngliche Datenquelle.
Die Datenverbindung Di ist dabei unidirektional gerichtet, d.h. es besteht physisch nur eine vom Basismodul BM zum ersten Zwischensysteme 11 transferierende Datenleitung. Ein Rückkanal, selbst zum Zwecke einer potentiellen Fehlerkorrektur existiert zunächst nicht. Dadurch kann eine Beeinflussung des Basismoduls BM durch äußere Manipulation mittels des Zwischensystems 11, z.B. durch einen externen Angreifer garantiert ausgeschlossen werden. Selbst wenn also das Zwischensysteme 11 kompromittiert wäre, kann eine Beeinflussung des korrekten Betriebs des Basismoduls BM ausgeschlossen werden. Das mit dem Feldgerät FG über den Feldbus Db verbundene Prozessleitsystem PLS kann also selbst in diesem Fall vollkommen unbeeinträchtigt zuverlässig weiterarbeiten.
Wie erwähnt können das Basismodul BM und das bzw. die Zwischensysteme 11, 12, 13 in Form separater Hardwarebaugruppen innerhalb des Feldgeräts FG realisiert sein, beide Funktionsmodule können jedoch auch in Form einer integrierten Hardwareschaltung auf einer Platine realisiert sein. Entscheidend hierbei ist immer, dass das Basismodule und (zumindest das erste) Zwischensystem 11 datentechnisch nur über die zuvor genannte eine (serielle) Datenleitung ohne Rückkanal miteinander verbunden sind.
Lediglich optional ist ein (temporär) zuschaltbarer Rückkanal in einer Ausgestaltung vorgesehen, der einen Datentransfer von der Außenwelt in das Feldgerät erlaubt. Die Zuschaltung könnte in Form einer Steckbrücke, eines Hardwareschalters oder eines elektronischen Schalters (Transistor, Digitalgatter, Relais, ...) oder einer Reihenschaltung der genannten Varianten ermöglicht werden. Der Rückkanal kann z.B. zur Vereinfachung von Servicemaßnahmen gewünscht sein, ist jedoch für das grundsätzliche Funktionieren des Verfahrens nicht erforderlich. Siehe dazu die 3, wo durch automatisches (Bezugszeichen „a“) und/oder manuelles (Bezugszeichen „m“) Schließen ein oder mehrerer Schalter ein Rückkanal öffenbar ist.
Damit am Zielsystem (hier: Cloud-Dienst C2) die benötigten Daten bereitgestellt werden können, muss im Basismodul BM eine Konfiguration KBM hinterlegt sein, damit dieses periodisch die dort referenzierten Daten über die innere Datenverbindung Di emittiert werden. Jede Konfiguration im Sinne dieser Anmeldung ist mit dem jeweils vorangestellten Bezugszeichen „K“ bezeichnet. Die Konfiguration KBM ist eine Subkonfiguration.
Jeder weitere Kommunikationsknoten benötigt in der Regel seinerseits eigene Konfigurationsinformationen, also weitere Subkonfigurationen, damit die Weiterleitung der Daten erfolgen kann. Im Beispiel in 2 muss das Zwischensystem 11 mit der Subkonfiguration KI1 die Zieladresse vom Zielsystem C1, das zu verwendende Datenformat, die beim Zielsystem C1 zu verwendende API, das Abtastintervall etc. kennen. Diese benötigten Informationen sind in der Subkonfiguration KI1 enthalten, die das Zwischensystem 11 erhalten muss. Auf gleiche Weise umfasst das Zielsystem C1 eine Subkonfiguration KC1 und das Zielsystem C2 eine Subkonfiguration KC2.
Damit der Anwender mit jedem Kommunikationsknoten eine separate Verbindung zur Zuweisung der Konfiguration durchführen muss, sieht das hier beschriebene Verfahren den Transport aller im Kommunikationsweg erforderlichen Subkonfigurationen zusammen mit den Nutzdaten ND, ausgehend vom Basismodul BM vor.
Für jeden Kommunikationskoten wird somit eine Subkonfiguration erstellt.
Zum Transport der Daten wird ein Container-Datenformat, wie z.B. DER oder XML, verwendet und dadurch ein Container-Datenpaket CDP gebildet (siehe dazu 4). Das Container-Datenformat kann eine beliebige Anzahl unterschiedlicher Daten integrieren. Ein Container-Datenformat legt eine Datenstruktur fest, mit der einzelne Datenströme verschiedener Formate zu einem Datenstrom, hier dem Container-Datenpaket CDP, zusammengeführt werden.
Alle Subkonfigurationen bilden zusammen eine Konfiguration. Die Konfiguration bildet neben den Nutzdaten das Container-Datenpaket CDP.
Das Container-Datenpaket CDP wird vom Anwender entweder über die Vor-Ort-Bedienmöglichkeit des Feldgeräts FG erzeugt oder über eine Datenschnittstelle (Feldbus Db, über das Feldgerät oder anderweitig bereitgestellter Webserver o.ä.) oder ein Speichermedium (z.B. SD-Karte) in das Feldgerät FG übertragen, siehe auch unten. Ein Container-Datenpaket CDP kann auch bereits in einer Ausgestaltung (z.B. als Bestandteil der Firmware) im Basismodul BM vorhanden sein.
Das Container-Datenpaket CDP ist in 4 durchnummeriert von CDP1 bis CDP4, je nach Stellung im Datenverlauf.
Das Basismodul BM entnimmt dem Container-Datenpaket CDP die Konfiguration KBM, wodurch das Basismodul BM aus der Vielzahl der im Basismodul BM entstehenden Daten diejenigen verpacken und im Container-Datenpaket CDP als Nutzdatenbestandteil ND integrieren kann, die dann für die Anwendung relevant sind. Das Basismodul BM emittiert das nun so modifizierte Container-Datenpaket CDP periodisch über die einzige Datenverbindung Di an das erste Zwischensystem 11. Wesentlich hierbei ist, dass die Daten ND und die Konfiguration im gleichen Datenpaket transportiert werden. Das Container-Datenpaket CDP ist durch Prüfsummen gesichert, damit der Empfänger erkennen kann, ob das Container-Datenpaket CDP fehlerfrei ist. Da die Kommunikation unidirektional erfolgt, ist eine Neuübertragung um Fehlerfall nicht möglich, das Paket wird vom Empfänger verworfen und dieser wartet auf das nächste zyklisch eintreffende Paket.
Das Zwischensystem 11 entnimmt dem Container-Datenpaket CDP die für dieses bestimmte Subkonfiguration KI1, modifiziert oder reichert die im Container-Datenpaket CDP enthaltenen Nutzdaten an. In 4 ist dies dargestellt dadurch, dass aus den Nutzdaten mit dem Bezugszeichen ND1 Nutzdaten mit dem Bezugszeichen ND2 werden. Das modifizierte Container-Datenpaket CDP wird dann weiter an das Zielsystem C1 geschickt. Der Vorgang wiederholt sich für eine beliebige Anzahl von Kommunikationsknoten, bis das Container-Datenpaket CDP schließlich das Zielsystem (im Beispiel C2) erreicht hat.
Durch das beschriebene Verfahren ist die vorwärts gerichtete Datenkommunikation in der Lage, den kompletten Kommunikationsweg bzw. die hierfür erforderlichen Kommunikationsknoten (im Beispiel in 4 über das Basismodul BM, das Zwischensystem 11 und den Zielsystemen C1 und C2) ohne manuellen Eingriff vollautomatisch zu konfigurieren. Der schrittweise Weitertransport des Container-Datenpaket CDPs zwischen den Kommunikationsknoten konfiguriert schließlich die vollständige Route vollautomatisch, die Nutzdaten werden an den erforderlichen Stellen transformiert und erreichen so ihr Ziel.
In den Konfigurationsdaten K können, wie oben bereits kurz angesprochen, sich beliebige Metainformationen befinden. Beispiele sind Adressinformationen, Kommunikationsparameter (Einwahlknoten, Schnittstellengeschwindigkeiten, Datenformate) aber auch Softwarefragmente (Skripte, Module o.ä.) die vom jeweiligen Kommunikationsknoten benötigt und ausgeführt werden. Auf diese Weise ist eine hochflexible Transformation der zu übertragenen Nutzdaten möglich, sodass die Daten über vielfältigste Datenschnittstellen transportiert werden können. Weitere Beispiele für Metainformationen sind Zeitstempel, Seriennummern/Namen der beteiligten Kommunikationsknoten. Verwendet ein Zwischen- oder Zielsystem zur Kommunikation beispielsweise eine REST-API (engl. Representational State Transfer Application Programming Interface), können die Metainformationen die zu verwendende REST-Syntax (engl. Representational State Transfer Application) beinhalten.
Die im Container-Datenpaket CDP enthaltenen Informationen können optional durch Verschlüsselungs- und Signaturverfahren vor dem unberechtigten Auslesen Dritter geschützt bzw. die Veränderung des Container-Datenpakets CDP durch Angreifer verhindert werden. So kann beispielsweise das Basismodul BM die Nutzdaten ND digital signieren, und jeder Kommunikationsknoten, insbesondere das Zielsystem C2 am Ende, kann prüfen, ob die Daten unverfälscht sind. Auf die gleiche Art lassen sich die Daten auch Ende-zu-Ende verschlüsseln.
Wie beschrieben entsteht das initiale Container-Datenpaket CDP durch eine Konfiguration über die Vor-Ort-Bedienmöglichkeiten des Feldgeräts FG oder über eine externe Datenquelle (etwa eine SD-Karte). Weiter ist es für den Anwender möglich über eine Mobile App, Web-App, Webanwendung oder Progressive Web App das Container-Datenpaket CDP zu erstellen. Dies kann auf einem Mobilgerät oder einem Personal Computer erfolgen. Ebenso kann das Erstellen über eine Webseite erfolgen, beispielsweise von einem Webserver bereitgestellt.
Der Anwender erstellt das Container-Datenpaket CDP mit Hilfe einer komfortabel gestalteten Oberfläche und konfiguriert beispielsweise die Art der zu visualisierenden Daten und die zu verwendende Datenaufbereitungsart. Die Oberfläche ist beispielsweise eine Cloud-Anwendung. Sind alle Einstellungen getroffen, wird das in 4 als „CDP1“ bezeichnete Container-Datenpaket erstellt, welches durch den Anwender in das Feldgerät FG geladen wird. Dieser Datentransport kann über das vorhandene Prozessleitsystem und den verwendeten Feldbus, einen im Feldgerät FG integrierten Webserver, eine drahtlose Verbindung oder ein Datenspeicher-Medium (z.B. SD-Karte) erfolgen. Zusätzlich ist in diesem Fall denkbar, dass der Anwender nur für die Zeitdauer des Datentransports den zuvor beschriebenen Rückkanal temporär öffnet, sodass das Container-Datenpaket CDP direkt von der oben beschriebenen Oberfläche in das Feldgerät FG gelangen kann.
Nachdem das Container-Datenpaket CDP von der Oberfläche, also etwa der Cloud-Anwendung, in das Feldgerät FG geladen wurde, beginnt der zuvor beschriebene vorwärts gerichtete Kommunikationsablauf, bei dem das Container-Datenpaket CDP den kompletten Kommunikationspfad schrittweise konfiguriert und das Container-Datenpaket CDP durch die Kommunikationsknoten schrittweise mit den Nutzdaten ND angereichert wird.
Für den Anwender ergibt sich dadurch eine sehr komfortable Art der Konfiguration des gesamten Datenkommunikationswegs bei gleichzeitig maximierter Sicherheit gegenüber böswilliger Manipulation durch Dritte.
Der Datenkommunikationsweg ist zwar ausschließlich vorwärtsgerichtet, jedoch nicht eindimensional. Es ist ohne weiteres denkbar, dass an einzelnen Kommunikationsknoten ein mehrfaches Abzweigen des Datenflusses an multiple andere Kommunikationsknoten erfolgt. So könnten beispielsweise mehrere voneinander getrennte Zielsysteme gleichzeitig von einem Feldgerät FG Daten erhalten. Beispielsweise können Daten an einen Cloud Computing Dienst gesendet werden, welche dort auch weiterverarbeitet werden. Gleichzeitig könnte eine Kopie der Daten auf einem Speichermedium hinterlegt werden.
Bezugszeichenliste

BM: Basismodul
C1..n: Zielsystem
CDP: Containerdatenpaket
Di: innere Datenverbindung
Db: Busverbindung
Do: äußere Datenverbindung
E: Erweiterungskomponente
FG: Feldgerät
I1.. n: Zwischensystem
Kx: Konfiguration von x
ND1..x: Nutzdaten
PLS: Prozessleitsystem
S: Sensor
a: automatisch/ gesteuert
m: manuell

Claims

Verfahren zur schrittweisen Konfiguration zur Übertragung von Daten (ND) von einem Feldgerät (FG) zu zumindest einem Zielsystem (C), umfassend die Schritte: - Erstellen einer Konfiguration (K), umfassend mindestens einer Subkonfiguration für das Feldgerät (FG) und einer Subkonfiguration für das Zielsystem (C), - Senden der Konfiguration (K) vom Feldgerät (FG) an das Zielsystem (C), und - Senden der Daten (ND) vom Feldgerät (FG) an das Zielsystem (C), wobei die Daten (ND) basierend auf der Subkonfiguration des Feldgeräts (FG) im Feldgerät (FG) weitergeleitet, verarbeitet, gespeichert oder verworfen werden, und wobei die Daten (ND) basierend auf der Subkonfiguration des Zielsystems (C) im Zielsystem verarbeitet oder gespeichert werden.
Verfahren nach Anspruch 1, wobei auf dem Datenpfad zwischen Feldgerät (FG) und Zielsystem (C) ein oder mehrere Zwischensysteme (I) zwischengeschaltet sind, diese jeweils die sie betreffende Subkonfiguration der an sie übermittelten Konfiguration (K) berücksichtigen und die empfangen Daten (ND) basierend auf ihrer Subkonfiguration weiterleiten, verarbeiten, speichern oder verwerfen.
Verfahren nach Anspruch 2, wobei die Subkonfiguration für das Feldgerät (FG) so ausgestaltet ist, dass dadurch die Daten (ND) im Feldgerät (FG) so weitergeleitet, verarbeitet, gespeichert oder verworfen werden, dass ein im Datenfluss nachfolgendes Zwischensystem (I) in der Lage ist, mit diesen Daten (ND) umgehen zu können.
Verfahren nach einem der Ansprüche 2 oder 3, wobei die Subkonfiguration für das Zwischensystem (I) so ausgestaltet ist, dass dadurch die Daten im Zwischensystem (I) so weitergeleitet, verarbeitet, gespeichert oder verworfen werden, dass ein im Datenfluss nachfolgendes weiteres Zwischensystem (I) oder das Zielsystem (C) in der Lage ist mit diesen Daten umgehen zu können.
Verfahren nach einem der vorherigen Ansprüche, wobei die jeweilige Subkonfiguration des aussendenden Systems aus der an das darauffolgende Zwischensystem (I) weitergereichten Konfiguration entfernt wird.
Verfahren nach einem der vorherigen Ansprüche, wobei die Konfiguration (K) und die Daten (ND) in einem Containerformat (CDP) gesendet werden.
Verfahren nach einem der vorherigen Ansprüche, wobei die Konfiguration (K) zyklisch gesendet wird.
Verfahren nach einem der vorherigen Ansprüche, wobei die Daten (ND), insbesondere basierend auf der jeweiligen Subkonfiguration, durch das zumindest eine Zwischensystem (I) geändert werden.
Verfahren nach einem der vorherigen Ansprüche, wobei die Subkonfiguration jeweilige Informationen bezüglich Zieladresse, Abtastintervall, Kommunikationsparameter, insbesondere Einwahlknoten, Schnittstellengeschwindigkeiten und/oder Datenformate, Zeitstempel, Softwarefragmente, insbesondere Skripte und/oder Programmmodule, Seriennummer und/oder Namen des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystems, oder einer Programmierschnittstelle des Feldgeräts, des zumindest einen Zwischensystems und/oder des Zielsystems umfasst.
Verfahren nach einem der vorherigen Ansprüche, wobei es sich bei den Daten (ND) um Informationen bezüglich des Status und/oder Systeminformationen des Feldgeräts, von am Feldgerät angeschlossenen Systemen, insbesondere Sensoren, und/oder des Zwischensystems, und/oder um Prozesswerte, insbesondere Messwerte von am Feldgerät angeschlossenen Systemen, insbesondere Sensoren, handelt.
Verfahren nach einem der vorherigen Ansprüche, wobei das Zielsystem (C) als zumindest ein System zum Cloud Computing und/oder Speichern der Daten ausgestaltet ist.
Verfahren nach einem der vorherigen Ansprüche, wobei die Konfiguration (K) verschlüsselt, und/oder mit einer Signatur versehen und/oder mit einer Prüfsumme versehen wird.
Verfahren nach einem der vorherigen Ansprüche, wobei das Senden der Daten (ND) und der Konfiguration (K) ausschließlich unidirektional erfolgt.
Verfahren nach einem der vorherigen Ansprüche, wobei die Subkonfiguration des Feldgeräts (FG), des zumindest einen Zwischensystems (I) und/oder des Zielsystem (C) am Feldgerät erstellt wird.
Verfahren nach einem der vorherigen Ansprüche, wobei die Subkonfiguration des Feldgeräts (FG), des zumindest einen Zwischensystems (I) und/oder des Zielsystems (C) mittels einer Mobile App, Web-App, Webanwendung, Progressive Web App oder einer Anwendungssoftware für ein Mobilgerät oder einen Personal Computer erstellt wird.
Feldgerät (FG), das geeignet ist, die Schritte des Verfahrens nach zumindest einem der vorherigen Ansprüche auszuführen.
Feldgerät (FG) nach Anspruch 16, wobei das Feldgerät (FG) eine Erweiterungskomponente (E) umfasst, wobei die Erweiterungskomponente (E) zumindest eine Datenverarbeitungseinheit, einen Speicher und eine Kommunikationsschnittstelle zu einem darauffolgenden Zwischensystem (I) und/oder zu dem Zielsystem (C) umfasst.
Feldgerät (FG) nach einem der vorherigen Ansprüche, wobei das Feldgerät (FG) zumindest zwei Zwischensysteme (I) umfasst und diese hierarchisch aufgebaut sind.
Computerprogrammprodukt, umfassend Befehle, die bewirken, dass die das Feldgerät (FG) nach zumindest einem der Ansprüche 16 bis 18 die Verfahrensschritte nach zumindest einem der Ansprüche 1 bis 15 ausführt.
Computerlesbares Medium, auf dem das Computerprogramm nach dem vorherigen Anspruch gespeichert ist.