DE102021204757A1

DE102021204757A1 - Verwaltung von Laufzeitcontainern für ein industrielles Automatisierungssystem

Info

Publication number: DE102021204757A1
Application number: DE102021204757.2A
Authority: DE
Inventors: Thomas Holm; Jan Jenke; Nikolai Falke
Original assignee: Wago Verwaltungs GmbH
Current assignee: Wago Verwaltungs GmbH
Priority date: 2021-05-11
Filing date: 2021-05-11
Publication date: 2022-11-17
Also published as: WO2022238482A1; US20240077856A1; CN117296044A; EP4338050A1

Abstract

Ein Verfahren in einem industriellen Automatisierungssystem, umfassend: Senden eines Eingabedatensatzes 210 von einer industriellen Steuerungsvorrichtung 300 an einen Containermanager 100, wobei der Eingabedatensatz 210 mindestens Eingabe-Metadaten umfasst; Bestimmen, durch den Containermanager 100 und basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers 400 zum Verarbeiten von Eingabedaten; Erzeugen von Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers 400; Erzeugen eines Ausgabedatensatzes 220 durch den Containermanager 100, wobei der Ausgabedatensatz 220 mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes 220 von dem Containermanager 100 an die industrielle Steuerungsvorrichtung 300.

Description

1. Technisches Gebiet
Die Erfindung betrifft allgemein das Gebiet der industriellen Automatisierungstechnik und insbesondere Verfahren und Techniken zur dynamischen Verwaltung von Laufzeitcontainern für den Betrieb eines industriellen Automatisierungssystems.
2. Hintergrund
Im Bereich der allgemeinen Informationstechnologie (IT) sind bereits Techniken bekannt, um Applikationen schnell und unabhängig von der darunterliegenden Hardwareinfrastruktur zu entwickeln. Beispielsweise dienen Ansätze wie „Continuous Deployment“ dazu, komplexe Softwareprojekte in weitverteilten Rechnerinfrastrukturen zu verwalten. Unterstützt werden diese Ansätze typischerweise durch in sog. „Container“ gekapselte Softwareapplikationen. Diese virtualisieren im Gegensatz zu virtuellen Maschinen das Betriebssystem anstelle der Hardware und ermöglichen dadurch Software portierbar und effizient zu gestalten. Eine Technologie, die dabei oft zum Einsatz kommt, ist z.B. die Docker-Technologie, welche primär auf die Virtualisierung mit Linux ausgerichtet ist.
In einem anderen technischen Gebiet, nämlich der industriellen Automatisierungstechnik (AT), werden diese Ansätze bislang kaum verwendet. Andererseits werden im Zuge der vierten industriellen Revolution und der alles durchdringenden Digitalisierung auch in der industriellen Automatisierungstechnik zunehmend Cloud-Lösungen zur Analyse, Verwaltung und teils sogar zur Steuerung der Komponenten von Automatisierungsumgebungen eingesetzt. Hierbei werden üblicherweise von industriellen Steuerungsvorrichtungen zur Laufzeit Daten erzeugt und an ein oder mehrere Cloud-Systeme gesendet. Bei einer industriellen Steuerungsvorrichtung kann es sich beispielsweise um eine speicherprogrammierbare Steuerung (SPS) handeln. Eine solche Vorrichtung ist typischerweise mit einem oder mehreren Sensoren und/oder Aktoren kommunikativ verbunden und realisiert Aufgaben im Kontext der Automatisierungstechnik. Ein Cloud-System kann im Rahmen der Erfindung allgemein ein von der Steuerungsvorrichtung entferntes Computersystem umfassen. Als Beispiele seien die WAGO Cloud, Microsoft Azure, Amazon AWS („Amazon Web Services“), die SAP Cloud oder die IBM Cloud genannt. Innerhalb des Cloud-Systems werden die empfangenen Daten üblicherweise gespeichert, ausgewertet und/oder Benutzern für beliebige Endgeräte aufbereitet zur Verfügung gestellt.
Beispielsweise ist aus EP 3 249 481 B1 ein System zur Ausführung eines geschlossenen Regelkreises auf Daten für Cloud-basierte Anwendungen bekannt. Darin wird beschrieben, wie eine Industriesteuerung mit einem Cloud-Umfeld interagiert und einen geschlossenen Regelkreis bildet, um komplexe Berechnungen in einer Cloud durchzuführen, ohne die Industriesteuerung zu belasten. Dies wird dadurch erreicht, dass in der Steuerung sog. Cloud-Variablen erzeugt werden, die von einem Cloud-Agenten in der Steuerung zur Bearbeitung in der Cloud weitergeleitet werden. Die EP 3 249 481 B1 betrachtet hierbei die Verarbeitungslogik auf der Industriesteuerung und die Cloud-Anwendung jedoch jeweils als monolithische Komponenten, die kaum Einfluss aufeinander haben.
Der vorliegenden Erfindung liegt deshalb das Problem zugrunde, Verfahren bereitzustellen, die es einer industriellen Steuerungsvorrichtung erlauben, flexibler auf externe Ressourcen zuzugreifen.
3. Zusammenfassung der Erfindung
Dieses Problem wird durch die Gegenstände der unabhängigen Patentansprüche gelöst, wobei die Unteransprüche bevorzugte Weiterbildungen betreffen.
So betrifft Anspruch 1 ein Verfahren in einem industriellen Automatisierungssystem. Eine industrielle Steuerungsvorrichtung sendet einen Eingabedatensatz an einen Containermanager, wobei der Eingabedatensatz mindestens (oder auch nur) Eingabe-Metadaten umfasst. Der Containermanager bestimmt basierend auf den Eingabe-Metadaten einen Laufzeitcontainer zum Verarbeiten von Eingabedaten aus der industriellen Steuerungsvorrichtung. Es werden Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers erzeugt. Der Containermanager erzeugt einen Ausgabedatensatz, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst. Der Containermanager sendet den Ausgabedatensatz an die industrielle Steuerungsvorrichtung.
In einer besonders schlichten Implementierung können die zu verarbeitenden Eingabedaten direkt im Eingabedatensatz von der industriellen Steuerungsvorrichtung an den Containermanager gesendet werden, welcher diese dann an den Laufzeitcontainer senden kann. In dieser Ausführungsform kann jedoch der Datentausch über den Containermanager einen Flaschenhals bezüglich der Datenübermittlung darstellen, wodurch sich der Kommunikationsaufwand erhöhen kann. Es ist deshalb alternativ vorgesehen, dass der Containermanager an die industrielle Steuerungsvorrichtung eine Adresse des Laufzeitcontainers senden kann. Optional kann dem Laufzeitcontainer eine Adresse der industriellen Steuerungsvorrichtung mitgeteilt werden. Diese kann in den Metadaten der Steuerungsvorrichtung enthalten sein oder alternativ durch den Containermanager bestimmt werden. Die Eingabedaten können dann von der industriellen Steuerungsvorrichtung direkt an den Laufzeitcontainer übermittelt werden (d.h. ohne Beteiligung des Containermanagers) und optional kann eine Adresse der Steuerungsvorrichtung übermittelt werden.
Auch für die Kommunikation von Ausgabedaten sind zwei Möglichkeiten vorgesehen. In einer schlichten Implementierung kann der Laufzeitcontainer die erzeugten Ausgabedaten an den Containermanager senden, welcher diese wiederum in dem Ausgabedatensatz an die industrielle Steuerungsvorrichtung sendet. Hierbei ergeben sich dieselben Nachteile bezüglich des Containermanagers als Flaschenhals wie bereits auf der Eingabeseite beschrieben. Alternativ ist es deshalb vorgesehen, dass der Laufzeitcontainer die Ausgabedaten direkt an eine Adresse der Steuerungsvorrichtung senden kann. Die Adresse kann entweder direkt aus dem Steuerungsprogramm oder durch den Containermanager bekannt sein.
Selbstverständlich können beide oben beschriebene Ansätze auch gemischt werden, d.h. die Kommunikation der Eingabedaten kann über den Containermanager stattfinden, wobei die Ausgabedaten direkt übertragen werden, und umgekehrt.
Die Erfindung behandelt somit ein Verfahren und Vorrichtungen, in denen eine industrielle Steuerungsvorrichtung, insbesondere ein Funktionsbaustein davon, beispielsweise aus einer IEC-Programmierung, bevorzugt IEC 61131, derart eingerichtet ist, um auf externe Ressourcen zuzugreifen.
Im Allgemeinen umfassen Ausführungsbeispiele der Erfindung das Orchestrieren, d.h. Starten, Konfigurieren, Überwachen und/oder Stoppen von in Containern gekapselten (Software-)Applikationen aus einer Industriesteuerung heraus, vorzugsweise durch die Steuerungslogik des auf der Industriesteuerung befindlichen Echtzeitsystems. Die in einem Container gekapselte (Software-)Applikation kann dabei abweichend auch auf einer anderen Hardwareinfrastruktur ausgeführt werden (zum Beispiel in einer Cloud).
Durch die Möglichkeit, in Containern gekapselte (Software-)Applikationen aus dem PLC-Programm der industriellen Steuerungsvorrichtung heraus zu starten, zu überwachen und/oder zu stoppen, werden die Systeme (IT und AT) weiter miteinander vereint. Des Weiteren sind Softwarekomponenten durch Nutzung von Container-Technologien dynamisch aus dem PLC-Programm hinzuladbar, abschaltbar und/oder entfernbar. Letzteres ermöglicht eine konsequente Ausnutzung des Speichers. Außerdem bietet die Auslagerung von in Containern gekapselten Softwareapplikationen eine Brücke zwischen Softwarekomponenten, die in unterschiedlichen Programmiersprachen und Softwareplattformen umgesetzt wurden.
Ebenfalls wird ein Verfahren, welches von einem Containermanager in einem industriellen Automatisierungssystem durchgeführt wird, bereitgestellt. Dieses Verfahren umfasst: Empfangen eines Eingabedatensatzes von einer industriellen Steuerungsvorrichtung, wobei der Eingabedatensatz mindestens Eingabe-Metadaten umfasst; Bestimmen, basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers zum Verarbeiten von Eingabedaten; Erzeugen eines Ausgabedatensatzes, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes an die industrielle Steuerungsvorrichtung.
Ein entsprechendes Verfahren, welches von einer industriellen Steuerungsvorrichtung in einem industriellen Automatisierungssystem durchgeführt wird, umfasst: Senden eines Eingabedatensatzes an einen Containermanager, wobei der Eingabedatensatz mindestens Eingabe-Metadaten umfasst, wobei die Eingabe-Metadaten es dem Containermanager erlauben, einen Laufzeitcontainer zum Erzeugen von Ausgabedaten auf Basis von Eingabedaten zu bestimmen; Empfangen eines Ausgabedatensatzes von dem Containermanager, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst.
In einem weiteren Aspekt der Erfindung können die Eingabe-Metadaten einen Containertyp umfassen. Anhand des Containertyps kann der Entwickler des Laufzeitprogrammes auf der industriellen Steuerungsvorrichtung definieren, welche Funktionalität in einen Container ausgelagert werden soll.
Die Eingabe-Metadaten können auch einen Eingabe-Identifizierer, beispielsweise einen Zeitstempel, umfassen, wobei der Ausgabedatensatz Ausgabe-Metadaten umfasst und wobei die Ausgabe-Metadaten denselben Eingabe-Identifizierer wie die zugehörigen Eingabe-Metadaten umfassen. Dies dient dazu, die durch den Container erzeugten Ausgabedaten den ursprünglichen Eingabedaten zuzuordnen (beispielsweise durch einen Zeitstempel). Hierdurch wird eine Synchronisation trotz der asynchronen Arbeitsweise ermöglicht.
Ferner können die Eingabe-Metadaten eine Rücksendeadresse, einen Container-Identifizierer und/oder eine Policy umfassen. Eine Policy kann definieren, unter welchen Voraussetzungen ein neuer Container gestartet, ein bestehender Container neu gestartet, gestoppt und/oder entfernt werden soll, und ermöglicht der Steuerungsvorrichtung bzw. deren Programmierer eine weitreichende Kontrolle über die Container.
Wenn der Ausgabedatensatz Ausgabe-Metadaten umfasst, können diese auch einen Status umfassen.
Das Bestimmen eines Laufzeitcontainers zum Verarbeiten der Eingabedaten kann ein Starten eines neuen Laufzeitcontainers oder ein Auswählen eines bereits laufenden Laufzeitcontainers umfassen.
Ferner kann das Bestimmen eines Laufzeitcontainers zum Verarbeiten der Eingabedaten auf einer momentanen Auslastung von Verarbeitungsressourcen zum Betrieb von Laufzeitcontainern basieren.
Die Erfindung stellt ferner ein System in seiner Gesamtheit und die oben genannten Vorrichtungen bereit, jeweils mit Mitteln zur Ausführung der hier beschriebenen Verfahren. Außerdem wird ein Computerprogramm bereitgestellt mit Anweisungen zum Implementieren der hier beschriebenen Verfahren.
Figurenliste
Im Folgenden werden bevorzugte Ausführungsbeispiele der vorliegenden Erfindung unter Bezugnahme auf die begleitenden Figuren erläutert:

1: Eine schematische Darstellung einer Systemumgebung für eine erste Ausführungsform der Erfindung.
2: Eine schematische Darstellung einer Systemumgebung für eine zweite Ausführungsform der Erfindung.

5. Detaillierte Beschreibung bevorzugter Ausführungsformen
Im Folgenden werden gegenwärtig bevorzugte Ausführungsbeispiele eines erfindungsgemäßen Verfahrens zum Betrieb eines industriellen Automatisierungssystems genauer erläutert.
In 1 und 2 sind zwei beispielhafte Ausführungsformen eines Automatisierungssystems gezeigt. In beiden Ausführungsformen umfasst das System eine industrielle Steuerungsvorrichtung 300, bei der es sich beispielsweise um eine speicherprogrammierbare Steuerung (SPS) handeln kann. Eine solche Vorrichtung 300 ist typischerweise mit einem oder mehreren Sensoren und/oder Aktoren kommunikativ verbunden und realisiert Aufgaben im Kontext der Automatisierungstechnik. Aus den Sensordaten kann hierbei ein Eingangsprozessabbild 310 erstellt und durch eine entsprechende Verarbeitung ein Ausgangsprozessabbild 330 erzeugt werden.
Innerhalb der Steuerungslogik der Industriesteuerung 300 wird ein Funktionsbaustein (siehe den Baustein „FUB“ in 1) 320 für die Kommunikation mit dem Containermanager 100 konfiguriert. Über den Baustein 320 können Daten aus der Steuerungslogik ausgewählt und in einem vorgegebenen Format als Eingabedatensatz 210 (siehe das „Inputpaket Typ 1“ in 1 und das „Inputpaket“ in 2) an den Containermanager 100 weitergeleitet werden.
Solche Inputpakete 210 umfassen in beiden Ausführungsformen (1 und 2) zumindest Eingabe-Metadaten. Diese Eingabe-Metadaten können umfassen:

- Einen ausgewählten Containertyp, welcher die Art des Containers angibt, der die gewünschte Funktionalität (z.B. spezifischer Algorithmus) bereitstellen soll. Der Containertyp kann entweder durch den Funktionsbaustein 300 vorgegeben sein oder im Fall eines generischen Funktionsbausteins 300 durch den Benutzer spezifiziert werden. Beispiele für Container-Typen können sein: Anomalie-Erkennungsalgorithmen, Vorhersage-Funktionen, Verfahren zur Phasenanalyse der Leistungsaufnahme zyklischer/periodischer Prozesse, Neuronale Netze, Trend/Drifterkennung, Dashboards, Daten-Logger und/oder Programme anderer Firmen in einem definierten Container.
- Einen eindeutigen Eingabe-Identifizierer (siehe „Input ID“ in 2), um der Ausgabe das Inputpaket und den Funktionsbaustein im späteren Verlauf zuordnen zu können.
- Eine Rücksendeadresse (sofern erforderlich).
- Einen Container-Identifizierer (siehe „Container ID“ in 1 und 2; optional und je nach konkreter Umsetzung).
- Eine optionale Policy mit einer oder mehreren Variablen. Solche Policies können unter anderem definieren, unter welchen Voraussetzungen ein neuer Container gestartet wird, ein bestehender Container neu gestartet, gestoppt und/oder entfernt wird.

Beispiel 1: Sobald über einen definierten Zeitraum keine Daten mehr an den Container gesendet werden, wird dieser beendet.
Beispiel 2: Sobald über einen definierten Zeitraum keine Daten mehr an den Container gesendet werden, wird dieser entfernt.
Beispiel 3: Der Container wird nie beendet und gelöscht, außer durch einen expliziten Befehl.
Beispiel 4: Der Container kann von mehreren FUBs verwendet werden + Kombinationen mit Beispiel 1-3.
Beispiel 5: Der Container kann nur von einem FUB verwendet werden + Kombinationen mit Beispiel 1-3.
Es versteht sich, dass in alternativen Ausführungsformen auch nur Teilmengen der obigen Daten als Metadaten Verwendung finden können.
In der Ausführungsform nach 2 umfasst das Inputpaket 210 ferner auch die eigentlichen Eingabedaten aus der Steuerungslogik (nachfolgend auch als „Inputdaten“ bezeichnet), d.h. denjenigen Daten, die verarbeitet werden sollen. In der Ausführungsform nach 1 werden die Eingabedaten hingegen separat von der Steuerungsvorrichtung 300 an den entsprechenden Container 400 gesendet (siehe das „Inputpaket Typ 2“ 215 in 1).
Nachfolgend wird eine beispielhafte Realisierung der Datenkommunikation im JSON-Format beschrieben:

 Erste Verbindung zum Containermanager:
       Json
       Topic: ContainerManager
       Payload: {'returnAddress' : '...' , 'containerType' : '...' ,

       policy: '...'', 'containerConfig': '... ', 'projectID': '...'

       }

Mitteilung vom Containermanager an FUB - Dauerhafte Subscription des FUB, um Statusänderungen mitzubekommen. Containermanager liefert dauerhaft Statusinformation, sodass der FUB Handlungen ableiten kann, wenn keine Statusinformationen mehr kommen:

       Topic: 'PfcId1/InstanzId1'
       Payload: {'time': '...', ''containerstatus' : '...',
       'inputAddress' : "... ', 'outputAddress' : '...' ,
       }

Daten vom FUB:

       Topic: "..."
       Payload: {
       'data': [{'time': '2020-06-29T09:09:54.874Z', 'value1':
       1.2, 'value2': 1.4, ...., 'xyz' : [221, 213, 213]}],
       'OutputAddress' : '...',
       'sourcelD': '...'
       }

Daten vom Modell:

       Topic: 'PfcId1/InstanzIdl/output'
       Payload: {
       'data': [{'time': '2020-06-29T09:09:54.874Z',
       'result1':1.23, 'result2':2.34}],}

Die Aufgabe des Containermanagers 100 besteht darin, die verfügbaren Container 400 unter Berücksichtigung der verfügbaren Ressourcen zu verwalten und die eingehenden Inputpakete 210 an die Container 400 weiterzuleiten. Wenn der Containermanager 100 einen neuen Input 210 empfängt, entscheidet er anhand des Containertyps, der Policy und/oder der Container ID, ob ein Container 400 gestartet wird. Wenn für den angeforderten Containertyp noch kein Container existiert, wird typischerweise ein Container dieses Typs gestartet. Sofern ein Container bereits existiert und die Policy die Verwendung eines „geteilten“ Containers zulässt, kann dieser verwendet werden. Durch eine ContainerID kann spezifiziert werden, dass genau ein Container mit dieser ContainerID verwendet wird. Existiert dieser bereits, wird dieser verwendet, andernfalls wir ein neuer Container mit dieser ContainerID gestartet. Weitere Regeln sind je nach Anwendungsfall anpassbar.

In der Ausführungsform nach 2 werden die lnputdaten an den entsprechenden Container 400 weitergeleitet. Die Zuordnung der Datenpakete erfolgt vorzugsweise nach dem Containertyp sowie der Container ID.

In der Ausführungsform nach 2 geben die Container 400 ihre Ergebnisse an den Containermanager 100 zurück und diese werden vom Containermanager 100 in Ausgabedatensätze 220 (siehe das „Outputpaket“ in 2) eingefügt. Ein Ausgabedatensatz 220 kann hierbei die Input ID und/oder den Status des entsprechenden Containers umfassen. Alternativ dazu kann der Container 400 die Ausgabedaten auch direkt an die industrielle Steuerungsvorrichtung 300 senden (siehe das „Outputpaket Typ 2“ 225 in 1). Der oben erwähnte Status kann beispielsweise Fehler durch unpassende Inputdaten oder Programmabstürze anzeigen. Denkbar ist auch ein Status, der anzeigt, dass sich der Container noch in der Initialisierung befindet oder die Rechenlast anzeigt.

In beiden Ausführungsformen sendet der Containermanager 100 die Outputpakete 220 an die passende(n) Rücksendeadresse(n), welche im Inputpaket 210 angegeben wurden.

Im Folgenden kann der Funktionsbaustein 320 diese Daten der Steuerungslogik der Industriesteuerung 300 zur Verfügung stellen, sodass die Daten dort verarbeitet werden.

Um eine besonders effiziente Verteilung der Auslastung zu ermöglichen, kann der Containermanager 100 Container 400, insbesondere zustandslose Container, auf die ihm zur Verfügung stehende Hardware verteilen, sodass diese parallel verwendet werden können. Hierfür kann der Containermanager 100 die Last der eingehenden Inputpakete 210 identifizieren und bei Bedarf einen weiteren (identischen) Container 400 starten. Hierdurch wird die Last auf mehrere Container 400 verteilt.

Der Containermanager 100 kann auch dafür verantwortlich sein, nicht mehr benötigte Container 400 zu beenden und/oder zu entfernen, bzw. wenn erforderlich, keine neuen Container 400 zu erstellen und Anfragen aus den Funktionsbausteinen 320 abzulehnen, beispielsweise wenn die Hardware zu stark ausgelastet ist, um weitere Container zu betreiben. Hierbei kann der Containermanager 100 die Policies, die in den Inputpaketen 210 enthalten sind, berücksichtigen.

Ferner können noch weitere Funktionalitäten zum direkten Ansprechen des Containermanagers 100 über zusätzliche Funktionsbausteine 320 ermöglicht werden, beispielsweise den Containerstart, Containerupdate, Löschen sowie Beenden des Containers und/oder eine Übersicht der aktuellen Containerstatus.

Zusammenfassend stellt die Erfindung in einer bevorzugten Ausführungsform Funktionsbausteine 320 bereit, die vom (IEC-)Programmierer ausgewählt werden können und mit einer SW/HW-Ressource verarbeitet werden. Alles weitere wird durch den Containermanager 100 erledigt. Der Containermanager 100 verwaltet die SW/HW-Ressourcen und wählt anhand der in den Funktionsbausteinen 320 hinterlegten Metadaten, welche SW/HW-Ressourcen für die im Funktionsbaustein 320 erforderlichen Funktionen erforderlich sind. Diese SW/HW-Ressourcen können sich sowohl in einer Cloud oder in einem Automatisierungsnetz oder in einem normalen IT-Cluster befinden.

Nachfolgend werden beispielhafte Einsatzszenarien erläutert:

Anomalie-Erkennung: Ein Anomalie-Erkennungsalgorithmus kann rechenintensiv und in einer speziellen Programmiersprache implementiert sein, sodass dieser in einem Container abseits der Industriesteuerung betrieben werden soll. Die Eingabedaten könnten in diesem Beispiel Temperaturen und/oder Vibration sein. Diese Daten werden von dem Anomalie-Erkennungsalgorithmus bewertet und die Bewertung wird an die Industriesteuerung gesendet. Hierbei kann ein Funktionsbaustein in gewohnter Weise genutzt werden, denn idealerweise stellt der Containermanager im Hintergrund die Anomalie-Erkennung in einem Container bereit. Der Funktionsbaustein kommuniziert im Folgenden mit dem Anomalie-Erkennungscontainer und gibt die Ergebnisse in das Steuerungsprogramm weiter.

Einbindung einer dritten Partei: Durch den Containermanager kann ein Container bereitgestellt werden, der direkt die Daten des Funktionsbausteins empfängt und die Ergebnisse an diesen sendet, beispielsweise ein Container mit einer Low-Code Entwicklungsumgebung, wie beispielsweise ein Node-RED-Container.

Dashboard: Durch den Containermanager kann ein Dashboard-Container bereitgestellt werden, der direkt die Daten des Funktionsbausteins empfängt und visualisiert. Hierdurch wird ein Einblick in die Prozessdaten ohne bzw. mit minimalem Aufwand ermöglicht.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

EP 3249481 B1 [0004]

Claims

Ein Verfahren in einem industriellen Automatisierungssystem, umfassend: Senden eines Eingabedatensatzes (210) von einer industriellen Steuerungsvorrichtung (300) an einen Containermanager (100), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst; Bestimmen, durch den Containermanager (100) und basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers (400) zum Verarbeiten von Eingabedaten; Erzeugen von Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers (400); Erzeugen eines Ausgabedatensatzes (220) durch den Containermanager (100), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes (220) von dem Containermanager (100) an die industrielle Steuerungsvorrichtung (300).
Ein Verfahren, welches von einem Containermanager (100) in einem industriellen Automatisierungssystem durchgeführt wird und umfasst: Empfangen eines Eingabedatensatzes (210) von einer industriellen Steuerungsvorrichtung (300), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst; Bestimmen, basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers (400) zum Verarbeiten von Eingabedaten; Erzeugen eines Ausgabedatensatzes (220), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes (220) an die industrielle Steuerungsvorrichtung (300).
Ein Verfahren, welches von einer industriellen Steuerungsvorrichtung (300) in einem industriellen Automatisierungssystem durchgeführt wird und umfasst: Senden eines Eingabedatensatzes (210) an einen Containermanager (100), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst, wobei die Eingabe-Metadaten es dem Containermanager (100) erlauben, einen Laufzeitcontainer (400) zum Erzeugen von Ausgabedaten auf Basis von Eingabedaten zu bestimmen; Empfangen eines Ausgabedatensatzes (220) von dem Containermanager (100), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe-Metadaten einen Containertyp umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe-Metadaten einen Eingabe-Identifizierer, insbesondere einen Zeitstempel, umfassen, wobei der Ausgabedatensatz (220) Ausgabe-Metadaten umfasst und wobei die Ausgabe-Metadaten denselben Eingabe-Identifizierer wie die zugehörigen Eingabe-Metadaten umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe-Metadaten eine Rücksendeadresse umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe-Metadaten einen Container-Identifizierer umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe-Metadaten eine Policy umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche, wobei der Ausgabedatensatz (220) Ausgabe-Metadaten umfasst und die Ausgabe-Metadaten einen Status umfassen.
Das Verfahren nach einem der vorstehenden Ansprüche wobei das Bestimmen eines Laufzeitcontainers (400) zum Verarbeiten der Eingabedaten umfasst: Starten eines neuen Laufzeitcontainers (400); oder Auswählen eines bereits laufenden Laufzeitcontainers (400).
Das Verfahren nach einem der vorstehenden Ansprüche wobei das Bestimmen eines Laufzeitcontainers (400) zum Verarbeiten der Eingabedaten ferner auf einer momentanen Auslastung von Verarbeitungsressourcen zum Betrieb von Laufzeitcontainern (400) basiert.
Ein System oder eine Vorrichtung, umfassend Mittel zur Ausführung eines Verfahrens nach einem der Ansprüche 1-11.
Ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, ein Verfahren nach einem der Ansprüche 1-11 auszuführen.