Verfahren zur automatischen Konfiguration eines Automatisie rungsgerätes, Automatisierungsgerät, Computerprogramm und computerlesbares Medium

Die Erfindung betrifft ein Verfahren zur automatischen Konfi guration eines insbesondere industriellen Automatisierungsge rätes. Darüber hinaus betrifft die Erfindung ein Automatisie rungsgerät, ein Computerprogramm und ein computerlesbares Me dium.

Im Bereich von Netzwerken, insbesondere industriellen Netz werken, kommt den Namen der Netzwerkteilnehmer zunehmend eine zentrale Rolle in der Identifikation von Geräten sowie der Identifikation von Funktionen und dergleichen zu. Der Indust- rial-Ethernet-Standard für die Automatisierung - PROFINET - benutzt seit Anbeginn solche Namen zur führenden Identifika tion insbesondere von IO-Geräten ( IO-Devices ) , und nicht etwa IP-Adressen .

Vor allem in demjenigen Fall, dass ein einen Netzwerkteilneh mer darstellendes Gerät ausgetauscht wird, ist es, wenn Namen anstelle von IP-Adressen zur Identifikation herangezogen wer den, besonders wichtig, dass das noch leere Austauschgerät möglichst schnell seinen korrekten, eindeutigen Namen erhält. Dieser Prozess wird insbesondere im Umfeld von PROFINET auch als „taufen" bezeichnet. Im Falle eines Gerätetauschs ist al so eine rasche „Wiedertaufe" wünschenswert bzw. erforderlich.

Eine Möglichkeit, Geräte zu „taufen" besteht in einer soge nannten „topologischen" Taufe, die vom Prinzip her auf der Netzwerk-Verkabelung der Geräte untereinander basiert.

Der Anmelderin ist bekannt, dass in PROFINET eine (quasi- ) zentralisierte Form einer topologischen Taufe umgesetzt ist. Dabei wird im Zuge der Planung einer Automatisierungsapplika tion mit einem Engineering-Werkzeug auch die Netzwerk-Ver- Schaltung der Automatisierungsgeräte erfasst. Aus dieser Ver schaltung der Geräte in Verbindung mit den Gerätenamen be rechnet das Planungswerkzeug eine Liste sogenannter Alias- Namen. Dabei besitzt ein bestimmtes Gerät maximal so viele Alias-Namen, wie es Ethernet-Ports hat. Ein Alias-Name be steht aus einem Portnamen, an den der Gerätename des Nachbarn angefügt wird. Für einen Port mit dem Portnamen „portOOl" und einen Gerätename „io-2.halll.acme.com" beispielsweise würde sich dann „portOOl" plus „io-2.halll.acme.com" als Alias-Name für das an den Port "portOOl" angeschlossene Gerät

„io-3.halll.acme.com" ergeben.

Die einzelnen Geräte erfahren, sobald sie in ein Netzwerk eingebracht worden sind, die Namen ihrer Nachbarn über das Link Layer Discovery Protocol (LLDP) , das insbesondere in IEEE 802.1AB definiert ist. Gemäß der vorgenannten Regel "Port-Name plus Name des Nachbargerätes" kann sich dann jedes noch ungetaufte Gerät seine Alias-Namen berechnen. Die ein zelnen Geräte kennen dabei nicht die Alias-Namen-Liste . Diese ist nur dem zentralen Planungstool bekannt, welches diese be rechnet hat.

Das Planungstool muss die Alias-Namen-Liste in einen PROFINET IO-Controller (IOC) laden. Auf Basis der geladenen Liste ver sucht der IO-Controller dann ständig, noch ungetaufte Geräte anhand ihrer Alias-Namen aufzufinden. Wird eines oder werden mehrere noch ungetaufte Geräte anhand der Alias-Namen gefun den, werden diese mit dem Namen getauft, der zuvor im Pla nungswerkzeug dem jeweiligen Alias-Namen zugewiesen wurde. Im Kontext vom IPv4 werden zudem oftmals weiterhin diverse IPv4- Parameter zugewiesen, beispielsweise IPv4-Adresse, Netzmaske, Default Gateway und dergleichen mehr.

Die in PROFINET vorgesehene topologische Taufe benötigt immer einen ( quasi- ) zentralen IO-Controller, der das Aufspüren un- getaufter Geräte durchführt und diese dann tauft. In der Automatisierungstechnik können Automatisierungsgeräte mit Hilfe des PROFINET „Name of Station" (NoS) funktional be nannt werden, beispielsweise mit einem AKZ- oder KKZ-Namen (AKZ steht dabei für Anlagenkennzeichnungssystem, siehe bei spielswiese DIN6779, und KKZ für Kraftwerk-Kennzeichensystem, siehe beispielsweise VGB-105, VGB-B 106, IEC/DIN EN 61346 bzw. ISO 16952) . Industrielle Anwender sind in ihren Arbeits prozessen darauf eingestellt, Automatisierungsgeräte derge stalt „zu taufen". Speziell für den Gerätetausch existieren Verfahren, um den Name of Station automatisch dem Ersatzgerät nach dessen Anschluss an das Netzwerk ohne weiteren manuellen Eingriff zuzuweisen. Bei der „PROFINET topologische Taufe" sind PROFINET Controller (insbesondere speicherprogrammierba re Steuerungen, SPS) in der Pflicht, den ihnen zugeordneten Automatisierungsgeräten die richtigen Namen zu geben.

Aus der ebenfalls auf die Anmelderin zurückgehenden europäi schen Patentanmeldung Nr. 18188735.7 geht ferner ein Verfah ren zur dezentralen Selbsttaufe unter Zuhilfenahme des Domain Name Systems (DNS, siehe insbesondere RFC 1034 und 1035) her vor .

Im generellen IT-Bereich, insbesondere im Büro-Umfeld, wird oftmals das Dynamic Host Configuration Protocol (DHCP) (siehe Request for Comments (RFC) 2131 „Dynamic Host Configuration Protocol" sowie RFC 3315 „Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" der Internet Engineering Task Force

(IETF)) eingesetzt. Dieses ermöglicht es ebenfalls, einem Ge rät einen „Host-Namen" (Gerätenamen) zuzuweisen. Dabei wird jedoch teilweise als nachteilig erachtet, dass DHCP die Hard- ware-Netzwerk-Adresse (MAC) eines Gerätes als eindeutigen Schlüssel benutzt. Wird ein Gerät ausgetauscht, ändert sich auch die MAC-Adresse, so dass eine automatische Taufe große administrative Aufwände verursachen würde.

Im Bereich der allgemeinen IT hat sich ferner die so genannte Container-Technologie bewährt. Anwendungs-Container stellen in der Regel "abgekapselte" Einheiten dar, die unabhängig voneinander ausgeführt werden können, egal wo sie sich befin den. Ähnlich wie bei virtuellen Maschinen sind Container eine Art Behälter für Anwendungen, in denen diese laufen können. Während virtuelle Maschinen jedoch eine ganze Computerumge bung abbilden, enthalten die Container üblicherweise ledig lich die wichtigen Daten, die für die Ausführung der jeweili gen Anwendung bzw. Anwendungen benötigt werden.

Die Container-Technologien bzw. Containerisierung ermöglichen es insbesondere, eine Software bzw. Anwendung in einem Con tainer zu verpacken, der alles umfasst, was sie zum Laufen braucht, beispielsweise Programmcode, Laufzeit, System-Tools und/oder Systembibliotheken. Die Container-Technologien bzw. Containerisierung erlauben es, Funktionen einfach und bequem modular zu verpacken, zu transportieren und schließlich in den operativen Bereich auszurollen. Klassische Einsatzgebiete von Containern liegen beispielsweise darin Applikationen, et wa eine Datenbank oder einen Web-Front-End, bequem zu verpa cken .

Beispiele für Software für die Container-Virtualisierung/Con- tainerisierung sind etwa „Docker" oder "rkt" (gesprochen "ro cket", siehe etwa https://coreos.com/rkt/sowie

https://www.docker.com bzw. EP 3 267 351 Al zu Docker) . Ein Beispiel für ein Orchestrierungssystem bzw. eine Orchestrie rungs-Software für Container ist durch "Kubernetes" gegeben (siehe etwa https://kubernetes.io/)

Nach Auffassung der Anmelderin hat die Container-Virtuali- sierung auch im Bereich der Automatisierungstechnik ein gro ßes Potential.

Eine wichtige Innovation der klassischen Rechenzentrums-IT (data center IT) ist eine effektive und effiziente Orchest rierung von Software-Containern in Clustern: hierbei sorgt eine Orchestrierungssoftware, wie beispielsweise Googles Ku bernetes dafür, die Arbeitslast in Form von Software-Con tainern auf die verfügbaren Arbeitsknoten zu verteilen. Wei- terhin wird auch die Container- und Knotenverfügbarkeit über prüft und beispielsweise gestörte Container werden automa tisch neu gestartet.

Die Knoten eines Rechenzentrums-Clusters sind dabei weitest gehend austauschbare Arbeiter. Für die Verteilung der Arbeit spielt die (Geräte- ) Identität eines einzelnen Arbeiters/Kno tens zumeist keine Rolle. Im Zusammenhang damit, dass Knoten (Arbeiter) austausch- und ersetzbar sind, wird auch der Aus druck „cattle, not pets" verwendet (siehe beispielsweise http : //cloudscaling . com/blog/cloud-Computing/the-histöry-of- pets-vs-cattle/) .

Im Gegensatz zu (entfernt von einer industriellen Anlage an gesiedelten) Rechenzentrums-Clustern befinden sich Industrial Edge-Geräte gemäß der Definition von „Edge" (siehe beispiels weise https://de.wikipedia.org/wiki/Edge_Computing) als Ge genstück der Cloud in einer Anlage nahe an den (klassischen) Automatisierungsgeräten insbesondere „am Rand" einer Anlage bzw. eines Netzwerkes einer solchen.

Bestimmte Arbeitslasten (Container) können bei automatisie rungstechnischen Aufgaben nicht mehr unbedingt frei im Clus ter beliebigen Arbeitsrechnern zugewiesen werden. Vielmehr müssen die Arbeitslasten bestimmter Anlagen-spezifischer Funktionen eben den zugehörigen Anlagen und beispielsweise zu diesen gehörigen Edge-Geräten zugewiesen werden können.

Einerseits arbeiten Anwender industrieller Automatisierungs technik bereits seit Jahrzehnten mit Anlagenkennzeichnungs systemen (AKZ, KKZ, ...) und sind damit darin geübt, Funktionen eindeutig zu kennzeichnen. Andererseits können Anwender bei Kubernetes beispielsweise Knoten (Arbeiter) und Arbeitslasten (Container) mit sogenannten „Labein" versehen, die eine se lektive Zuordnung von Arbeitslasten zu Arbeitern ermöglichen würde. Das Kubernetes-Orchestrierungssystem beispielsweise erlaubt es, dass Cluster-Nodes , die beispielsweise durch Edge-Geräte gegeben sein können, mit „Labein" versehen werden können. Auf die Label kann dann gezielt beim Zuordnen von funktionsspezifischen Arbeitslasten gefiltert werden, um eine bestimmte Container-Funktion nur einem einzelnen oder auch einem Satz von Nodes/Edges zuzuweisen. Das Zuweisen solcher Label an Nodes/Edges liegt dabei rein im Ausführungsbereich des Anwenders.

Bei der zu erwartenden großen Anzahl von Automatisierungsge räten, beispielsweise Edge-Geräten in industriellen Anlagen geht die Anmelderin davon aus, dass ein manuelles „Labein" rasch unwirtschaftlich und fehleranfällig wird, wenn viele automatisierungstechnische Funktionen vielen Edge-Geräten zu zuweisen sind. Zudem würden Anwender tatsächlich ein doppel tes Labein erfahren: erst aus Sicht der Automatisierungstech- nik, danach aus Sicht der Orchestrierung.

Neben dem Vermeiden doppelter Arbeit sollten Mechanismen zur automatischen ( Selbst- ) Taufe nach einem Gerätetausch auch für die Orchestrierung greifen können, um einen raschen und prob lemlosen Tausch einer defekten Industrial Edge Hardware zu gewährleisten, beispielsweise die dezentrale Selbsttaufe ge mäß der auf die Anmelderin zurückgehenden die europäischen Patentanmeldung Nr. 18188735.7

Ausgehend davon ist es eine Aufgabe der vorliegenden Erfin dung, eine Möglichkeit zu schaffen, Knoten eines Clusters bildenden Automatisierungsgeräten mit geringem Aufwand kon krete Aufgabe zuzuordnen, insbesondere auch für den Fall ei nes Gerätetausches.

Diese Aufgabe wird gelöst durch ein Verfahren zur automati schen Konfiguration eines insbesondere industriellen Automa tisierungsgerätes, umfassend die Schritte

a) ein Automatisierungsgerät, welches geeignet ist, als Kno ten eines Clusters zu fungieren und wenigstens eine Auto matisierungsaufgabe auszuführen, wird bereitgestellt, b) eine Geräte-Management-Einheit überwacht, ob dem Automati sierungsgerät ein Automatisierungs-Kenner zugeordnet wird, c) wenn die Geräte-Management-Einheit eine solche Zuordnung erkannt hat, fragt sie bei einer zentralen Cluster- Management-Einheit an, ob in einer zu dem Cluster gehöri gen Cluster-Zustands-Datenbank mit Beschreibungsobjekten für Knoten des Clusters bereits ein Beschreibungsobjekt existiert, in dem der dem Automatisierungsgerät zugeordne te Automatisierungs-Kenner hinterlegt ist,

d) in dem Fall, dass ein solches Beschreibungsobjekt bereits für einen dem Automatisierungsgerät zugeordneten Knoten- Kenner existiert, wird dieses Beschreibungsobjekt als Be schreibungsobjekt des Automatisierungsgerätes erachtet, und in dem Fall, dass ein solches Beschreibungsobjekt für einen anderen als den dem Automatisierungsgerät zugeordne ten Knoten-Kenner existiert und als inaktiv deklariert ist und in dem Fall, dass noch kein solches Beschreibungsob jekt existiert erzeugt die Geräte-Management-Einheit in der Cluster-Zustands-Datenbank für den dem Automatisie rungsgerät zugeordneten Knoten-Kenner ein Beschreibungsob jekt, in dem der dem Automatisierungsgerät zugeordnete Au tomatisierungs-Kenner hinterlegt ist, oder hinterlegt den dem Automatisierungsgerät zugeordneten Automatisierungs- Kenner in einem in der Cluster-Zustands-Datenbank bereits für einen dem Automatisierungsgerät zugeordneten Knoten- Kenner existierenden Beschreibungsobjekt oder veranlasst die Hinterlegung oder die Erzeugung.

Aus einem „alten" Beschreibungsobjekt mit dem zugeordneten Automatisierungs-Kenner, das als „inaktiv" deklariert ist, wird der Automatisierungs-Kenner bevorzugt entfernt oder das gesamte „inaktive" Beschreibungsobjekt wird entfernt. So kann die Datenbank aktuell gehalten werden.

Für den Fall, dass bereits ein als „aktiv" deklariertes sol ches Beschreibungsobjekt in der Datenbank existiert, unter bleibt die Hinterlegung des Automatisierungs-Kenners bzw. die Erzeugung eines neuen Beschreibungsobjektes mit diesem zweck mäßiger Weise. In zweckmäßiger Ausgestaltung des erfindungs gemäßen Verfahrens ist entsprechend vorgesehen, dass für den Fall, dass die Anfrage, ob in der zu dem Cluster gehörigen Cluster-Zustands-Datenbank bereits ein Beschreibungsobjekt existiert, in dem der dem Automatisierungsgerät zugeordnete Automatisierungs-Kenner hinterlegt ist, ergibt, dass dem so ist und dieses Beschreibungsobjekt als aktiv deklariert ist, die Geräte-Management-Einheit kein Beschreibungsobjekt, in dem der dem Automatisierungsgerät zugeordnete Automatisie rungs-Kenner hinterlegt ist, in der Cluster-Zustands-Daten bank für einen dem Automatisierungsgerät zugeordneten Knoten- Kenner erzeugt, und den dem Automatisierungsgerät zugeordne ten Automatisierungs-Kenner auch nicht in einem in der Clus ter-Zustands-Datenbank bereits für einen dem Automatisie rungsgerät zugeordneten Knoten-Kenner existierenden Beschrei bungsobjekt hinterlegt und die Hinterlegung oder die Erzeu gung auch nicht veranlasst. So kann insbesondere eine „Gerä- te-Dublette" erkannt und eine „Doppelnutzung" eines Automati sierungs-Kenners verhindert und damit verbundene Probleme vermieden werden.

Im Anschluss an die Schritte a) bis d) des erfindungsgemäßen Verfahrens können gängige Orchestrierungsmechanismen, die dem Automatisierungsgerät insbesondere von einem Anwender spezi fisch per Automatisierungs-Kenner zugeordnete Arbeitslasten konkret diesem Gerät zugewiesen werden. Darauf ggf. zweckmä ßiger Weise erfolgende Download- und Deployment-Prozesse kön nen auf die vorbekannte Weise, insbesondere wie in den be kannten Container-Systemen, beispielsweise Docker definiert, ablaufen. Beispielsweise weist das Orchestrierungssystem das Container-System auf einem Arbeitsknoten an, ein ganz be stimmtes Container-Abbild („Container image") von einer vorab konfigurierten Registratur (registry) zu laden und anschlie ßend zur Ausführung zu bringen.

In Weiterbildung ist entsprechend vorgesehen, dass dem Auto matisierungsgerät unter Rückgriff auf das Beschreibungsob jekt, das in Schritt d) als das Beschreibungsobjekt des Auto matisierungsgerätes erachtet wurde oder das in Schritt d) er zeugt wurde oder in dem in Schritt d) der Automatisierungs- Kenner hinterlegt wurde, wenigstens eine Automatisierungs funktion zugeordnet wird. Besonders bevorzugt wird dem Auto matisierungsgerät unter Rückgriff auf das Beschreibungsobjekt wenigstens eine containerisierte Automatisierungsfunktion zu geordnet .

Im Ergebnis wird insbesondere von den Beschreibungsobjekten, die die Automatisierungs-Kenner umfassen, die automatisie rungstechnische Besonderheit abgebildet, dass Automatisie rungsgeräte etwa in einem Produktionsnetz nicht immer belie big untereinander austauschbare Geräte darstellen, sondern diese (auch) automatisierungs- , etwa produktionsspezifische Aufgaben erfüllen müssen, die durch andere Automatisierungs geräte und/oder an anderer Stelle nicht erbracht werden kön nen. Dabei wird dies zuverlässig gewährleistet, ohne dass es eines manuellen Eingriffes, etwa eines manuellen Labeins bzw. einer manuellen Konfiguration durch einen Benutzer bedarf.

Durch die erfindungsgemäße Verwendung von Automatisierungs- Kennern in den Beschreibungsobjekten wird ein besonders ein faches Zuordnen von gerätespezifischen bzw. „ortsabhängigen" Automatisierungs-, etwa Produktionsfunktionen zu dem jeweili gen Automatisierungsgerät anhand etablierter Kennzeichnungs system aus dem Bereich der industriellen Automatisierung, wie AKZ, KKZ , ... möglich.

Der Automatisierungs-Kenner und der Knoten-Kenner eines Gerä tes sind zweckmäßiger Weise voneinander verschiedene, also nicht identische Kenner.

Bei dem Automatisierungs-Kenner handelt es sich bevorzugt um einen Kenner, welcher dem Automatisierungsgerät im Zusammen hang mit einer automatisierungstechnischen Aufgabe gegeben wird bzw. wurde.

Bei dem Knoten-Kenner handelt es sich bevorzugt um einen Ken ner, welcher dem Automatisierungsgerät im Zusammenhang mit seiner Aufgabe bzw. Funktion als Knoten eines Clusters gege ben wird bzw. wurde.

Bei den Beschreibungsobjekten für die Knoten in der Cluster- Zustands-Datenbank handelt es sich insbesondere um Objekte, welche die gewünschten und/oder aktuellen Zustände der Knoten im Cluster beschreiben. In der Regel wird für jeden Knoten ein solches Beschreibungsobjekt in einer Datenbank geführt, welches den gewünschten und/oder aktuellen Zustand des jewei ligen Knotens beschreibt. Ein Beschreibungsobjekt für einen Knoten kann auch als Knoten-Objekt bezeichnet werden. Im Rah men von Kubernetes beispielsweise sind die Beschreibungsob jekte auch als „ressource-obj ects" oder einfach „objects" be zeichnet .

Das erfindungsgemäße Verfahren ist insbesondere geeignet zu gewährleisten, dass ausgetauschten sowie neu hinzugekommenen Automatisierungsgeräten, die als Cluster-Knoten dienen, auto matisch spezifische Aufgaben im Cluster-Verbund bzw. -System zugeordnet werden. Zugehörige Beschreibungsobjekte in einer Cluster-Zustands-Datenbank und die Kenner werden automatisch erzeugt bzw. gepflegt.

Für ein neu hinzugekommen Gerät wird, wenn diesem einen Auto matisierungs-Kenner zugeordnet wurde, der Automatisierungs- Kenner erstmalig in einem Beschreibungsobjekt in der Cluster- Zustands-Datenbank hinterlegt.

Insbesondere für ein Austausch-Gerät kann über die Überprü fung gemäß Schritt c) ermittelt werden, ob das zum „alten", defekten Gerät gehörige Beschreibungsobjekt bereits als „in aktiv" deklariert wurde. Ist dies der Fall, kann der Automa tisierungs-Kenner insbesondere als Label in einem (neuen) Be schreibungsobjekt für das (neue) Gerät hinterlegt werden.

Die Überprüfung, ob bereits ein Beschreibungsobjekt exis tiert, in dem der dem Automatisierungsgerät zugeordnete Auto matisierungs-Kenner hinterlegt ist, kann ergeben, dass ein solches Objekt bereits für den dem Gerät zugeordneten Knoten- Kenner, etwa eine Knoten-ID des Gerätes existiert. Mit ande ren Worten existiert ein Objekt, welches für das Gerät benö tigt wird, bereits. In diesem Falle muss kein neues Objekt mit dem Automatisierungs-Kenner für den bzw. unter dem Kno ten-Kenner erzeugt werden, sondern das bereits in der erfor derlichen Form existierende Objekt kann für das Gerät verwen det werden. In diesem Fall wird daher das Beschreibungsobjekt als Beschreibungsobjekt des Automatisierungsgerätes erachtet. Das Beschreibungsobjekt sollte zweckmäßiger Weise als aktiv deklariert sein.

Mit dem erfindungsgemäßen Verfahren wird darüber hinaus auch der Fall abgedeckt, dass sich der Automatisierungs-Kenner ei nes Gerätes, insbesondere Bestandsgerätes, ändert, also einem Gerät ein neuer, von einem vorherigen Automatisierungs-Kenner verschiedener Automatisierungs-Kenner zugeordnet wird. Auch dies wird von der Geräte-Management-Einheit erkannt und es wird eine entsprechende Aktualisierung angestoßen, dies unter Berücksichtigung der Möglichkeit, dass der neue Automatisie rungs-Kenner bereits vergeben wurde, also ein als aktiv de klariertes Beschreibungsobjekt mit diesem existiert.

Für den Fall, dass das Automatisierungsgerät bereits (wenigs tens einmal) ein Automatisierungs-Kenner zugeordnet wurde (vorheriger Kenner) und dann ein weiterer Automatisierungs- Kenner zugeordnet wird, kann vorgesehen sein, dass die Gerä- te-Management-Einheit, nachdem sie die Zuordnung des weiteren Automatisierungs-Kenners erkannt hat, die zentrale Cluster- Management-Einheit kontaktiert und veranlasst, dass das (vor herige) Beschreibungsobjekt, in dem der vorherige Automati sierungs-Kenner hinterlegt ist, gelöscht wird. So kann die Datenbank „Aufgeräumt" bzw. aktuell gehalten werden.

Bei dem Automatisierungsgerät handelt es sich in besonders bevorzugter Ausführungsform um ein Edge Gerät. Dann wird durch das erfindungsgemäße Verfahren insbesondere eine beson- ders komfortable Erstinbetriebnahme und ein besonders komfor tabler Austausch von Industrial-Edge-Geräten unterstützt. Ei ne manuelle Konfiguration/Datenbankpflege kann entfallen.

Die Geräte-Management-Einheit befindet sich bevorzugt auf dem Automatisierungsgerät .

Bei der zentralen Cluster-Management-Einheit, bei der in Schritt c) angefragt wird, handelt es sich bevorzugt um eine solche, die für das Verteilen von Arbeitslasten auf die Kno ten des Clusters zuständig ist. Man kann auch von einer Clus- ter-Orchestrierungs-Einheit bzw. einer Cluster-Orchestrie- rungs-Software sprechen. Rein beispielhaft für eine solche Orchestrierungs-Software sei Kubernetes genannt.

Die Geräte-Management-Einheit kann die zentrale Cluster- Management-Einheit dafür nutzen, das Beschreibungsobjekt zu erzeugen bzw. den Automatisierung-Kenner in einem solchen zu hinterlegen. Die Geräte-Management-Einheit kann beispielswei se der zentralen Cluster-Management-Einheit den Automatisie rungs-Kenner übergeben und diese dazu veranlassen, diesen in einem existierenden Beschreibungsobjekt zu hinterlegen bzw. ein neues Beschreibungsobjekt mit diesem zu erzeugen.

Die Information darüber, ob ein Beschreibungsobjekt aktiv o- der inaktiv ist, kann prinzipiell aus dem Clustersystem sel ber kommen, etwa direkt von der zentralen Cluster-Management- Einheit, oder auch von einem anderen Überwachungssystem, wel ches insbesondere eine unabhängige Überwachung des Clusters durchführt .

Bei dem zu konfigurierenden Automatisierungsgerät handelt es sich insbesondere um ein Neugerät oder ein Austauschgerät o- der ein Bestandsgerät, dessen Automatisierungs-Kenner sich geändert hat. Eine Änderung eines Automatisierungs-Kenners kann beispielsweise erforderlich sein, wen ein Automatisie rungs-Kenner falsch eingegeben wurde, dieser beispielsweise einen „Buchstabendreher" enthält, und daher zu korrigieren ist. Auch kann es sein, dass ein Automatisierungsgerät funk tional umgewidmet wird, beispielsweise, weil sich heraus stellt, dass es keine ausreichende Leistung besitzt, ohne, dass es aus dem Orchestrierungssystem ausgebucht wird.

Ein Kenner kann auch als Marke bezeichnet werden. Entspre chend können die Automatisierungs- und die Knoten-Kenner auch als Automatisierungs- bzw. die Cluster-Marken bezeichnet wer den .

Die Zuordnung des Automatisierungs-Kenners kann im Rahmen ei ner Taufe des Gerätes erfolgen bzw. eine solche darstellen.

Die Zuordnung eines Kenners zu einem Gerät kann einschließen, dass dem Gerät ein Kenner zugewiesen wird und/oder von dem Gerät ein Kenner empfangen wird und/oder auf dem Gerät ein Kenner gespeichert wird.

Ein Gerät, dem (noch) kein Kenner zugeordnet ist, kann sich durch eine auf dem Gerät gespeicherte, noch leere Kenner-, insbesondere Namensdatei bzw. einen auf dem Gerät gespeicher ten, noch leeren Kenner-, insbesondere Namens-String aus zeichnen. In einem Zustand ohne Kenner befindet sich ein Ge rät beispielsweise, bevor es das erste Mal in einem Netzwerk in Betrieb genommen wurde, etwa im Auslieferungszustand.

Es sei betont, dass die Reihenfolge der Zuordnung von einem Knoten- und einem Automatisierungs-Kenner zu einem Gerät be liebig sei kann. Mit anderen Worten kann beispielsweise erst der Automatisierungs- und dann der Knoten-Kenner zugeordnet werden. Auch ist es möglich, dass die beiden Kenner in dazu umgekehrter Reihenfolge oder auch gleichzeitig zugeordnet werden .

Ein anderer Begriff für einen Cluster ist Computercluster o- der Rechnerverbund. Die Knoten eines Clusters, die etwa durch mehrere insbesondere verbundene Recheneinrichtungen/Rechner gegeben sind, werden auch als Nodes bezeichnet. Ein Automati- sierungsgerät, das dazu ausgebildet und/oder eingerichtet ist, als Knoten eines Clusters betrieben zu werden und we nigstens eine Automatisierungsaufgabe auszuführen, kann bei spielsweise durch eine Recheneinrichtung oder einen Rechner, etwa in Form eines Industrie-PCs gegeben sein, die wenigstens eine Automatisierungsaufgabe zu übernehmen hat.

Eine weitere Ausführungsform des erfindungsgemäßen Verfahrens zeichnet sich dadurch, dass die Geräte-Management-Einheit lo kal einen dem Automatisierungsgerät zugeordneten Knoten- Kenner ermittelt.

Alternativ oder zusätzlich kann vorgesehen sein, dass die Ge- räte-Management-Einheit in Schritt d) das für den dem Automa tisierungsgerät zugeordneten Knoten-Kenner bereits existie rende Beschreibungsobjekt oder das zu erzeugende Beschrei bungsobjekt oder das existierende Beschreibungsobjekt, in dem der Automatisierungs-Kenner zu hinterlegen ist, über einen dem Automatisierungsgerät zugeordneten Knoten-Kenner adres siert. So kann auf besonders geeignete Weise auf ein bzw. das Beschreibungsobjekt, das die gewünschten und aktuellen Zu stände eines Automatisierungsgerätes im Cluster beschreibt, zugegriffen werden.

Eine weitere besonders bevorzugte Ausführungsform zeichnet sich dadurch aus, dass der Automatisierungs-Kenner in dem Be schreibungsobjekt in Form eines oder als Bestandteil eines Labels hinterlegt wird. So können aus dem Stand der Technik an sich vorbekannte Mechanismen, insbesondere die vorbekannte Nutzung von Labein, weiter zum Einsatz kommen.

Bei einem Knoten-Kenner, der dem Gerät zugewiesen wird, han delt es sich bevorzugt um eine Label, insbesondere ein sol ches, das von einem zentralen Cluster-Management-System bzw. der zentralen Cluster-Management-Einheit an die beteiligten Knoten des Clusters zu deren Identifikation vergeben wird. Label, die durch einen Automatisierungs-bzw . Knoten-Kenner gegeben sein oder einen solchen umfassen können, haben bevor zugt die Form Schlüssel=Wert, wobei der Schlüssel beispiels weise die Struktur „Siemens . edge/name" haben und der Wert der (alte oder neue) Automatisierungs-Kenners, etwa FQDN sein kann .

Weiterhin kann vorgesehen sein, dass dem Automatisierungsge rät der Automatisierungs-Kenner von einem weiteren Automati sierungsgerät, insbesondere einer Steuerung zugeordnet wird.

Alternativ oder zusätzlich kann vorsehen sein, dass dem Auto matisierungsgerät der Automatisierungs-Kenner über ein

Selbsttaufe-Verfahren zugeordnet wird, besonders bevorzugt über das in der ebenfalls auf die Anmelderin zurückgehenden europäischen Patentanmeldung Nr. 18188735.7 beschriebene Ver fahren zur dezentralen Selbsttaufe unter Zuhilfenahme des Do main Name Systems (DNS, siehe insbesondere RFC 1034 und

1035) . Das Automatisierungsgerät kann in vorteilhafter Wei terbildung eine Selbsttaufe-Einheit umfassen, welches zur Ab wicklung der die Selbsttaufe, insbesondere gemäß der europäi schen Patentanmeldung Nr. 18188735.7 ausgebildet und/oder eingerichtet ist.

Ferner kann vorgesehen sein, dass dem Automatisierungsgerät der Automatisierungs-Kenner über ein Einrichtungs-Werkzeug zugeordnet wird. Als Beispiel für ein solches Einrichtungs- Werkzeug sei das PROFINET-Primary-Setup-Tool genannt.

Was die Form des Automatisierungs-Kenners angeht, haben sich PQDNs bzw. FQDNs als besonders geeignet erweisen. Entspre chend kann in Weiterbildung vorgesehen sein, dass dem Automa tisierungsgerät ein teilweise oder vollständig qualifizierter Domain Name (Partially oder Fully Qualified Domain Name, PQDN oder FQDN) als Automatisierungs-Kenner zugeordnet wird. Ein nur teilweise qualifizierter Domain Name (PQDN) umfasst im Gegensatz zu einem FQDN nicht den vollen Pfad von Domain La bein bis zur DNS-Wurzel. Der Automatisierungs-Kenner, insbe- sondere -Name ist bevorzugt ein (global) eindeutiger Kenner, insbesondere Name. Es kann sich um einen voll qualifizierten Domain Namen im Sinne von dem RFC 7719 (Request for Comments: 7719 der Internet Engineering Task Force Group (IETF), https://tools.ietf. org/html/rfc7719 ) handeln .

Auch ist es möglich, dass ein Automatisierungs-Kenner einen Name of Station (NoS) umfasst oder durch einen solche gebil det wird. NoS werden beispielswiese im Rahmen von PROFINET, etwa über ein Primary Setup Tool oder eine topologische Tau fe, als Gerätenamen vergeben.

Alternativ oder zusätzlich kann dem Automatisierungsgerät ein Knoten-Kenner von der zentralen Cluster-Management-Einheit zugeordnet werden. Dies entspricht der konventionellen Vorge hensweise .

Es kann beispielsweise sein, dass das Automatisierungsgerät in Schritt a) als Neugerät bereitgestellt wird, und das Auto matisierungsgerät im Rahmen eines Onboarding-Prozesses , ins besondere von der zentralen Cluster-Management-Einheit, in den Cluster aufgenommen wird, und dem Automatisierungsgerät ein Knoten-Kenner im Rahmen des Onboarding-Prozesse oder im Anschluss an diesen der Knoten-Kenner zugewiesen wird.

Dem Automatisierungsgerät kann beispielsweise eine Knoten-ID als Knoten-Kenner zugordnet werden.

Weiterhin kann vorgesehen sein, dass das Automatisierungsge rät im Rahmen seiner Bereitstellung in Schritt a) an ein ins besondere industrielles Automatisierungsnetzwerk angeschlos sen wird. Mehrere Knoten eines Clusters sind bzw. werden in der Regel über ein Netzwerk verbunden.

Gegenstand der Erfindung ist auch ein Automatisierungsgerät, welches geeignet ist, als Knoten eines Clusters zu fungieren und wenigstens eine Automatisierungsaufgabe auszuführen und das zur Durchführung des erfindungsgemäßen Verfahrens ausge bildet und/oder eingerichtet ist.

Bei einem erfindungsgemäßen Automatisierungsgerät und/oder einem Automatisierungsgerät, welches unter Durchführung des erfindungsgemäßen Verfahrens konfiguriert wird, kann es sich beispielsweise um ein (separates) Gerät bzw. eine (separate) Hardware-Komponente handeln, welche ausgebildet und/oder ein gerichtet ist, wenigstens eine Automatisierungsfunktion zu erfüllen. Selbstverständlich ist es auch möglich, dass ein Automatisierungsgerät als "Software-Automatisierungsgerät" vorliegt, etwa in Form einer virtuellen Maschine (VM) oder eines Computerprogrammes bzw. einer Computerprogramm-Samm lung, die auf einer zu dessen/deren Ausführung ausgebildeten Einrichtung, etwa einem PC oder einer anderen Recheneinrich tung oder einem beliebigen anderen Gerät, abgelegt ist. Ein erfindungsgemäßes bzw. zu konfigurierendes Automatisierungs gerät kann auch in ein anderes Gerät integriert sein, dies sowohl in Form von Hardware- als auch Software.

Unter den Begriff Automatisierungsgerät im Sinne der vorlie genden Anmeldung fallen sämtliche der vorgenannten Möglich keiten, insbesondere auch "Soft-Geräte" sowie Geräte, die ei gentlich andere Funktionen ausführen bzw. einem anderen Zweck dienen, aber auch eine Automatisierungs-Funktion übernehmen und als Cluster-Knoten fungieren können. Zum Beispiel ist auch ein konventioneller Rechner bzw. PC oder Industrie- Rechner bzw. -PC, welcher u.a. wenigstens eine Automatisie- rungs-, beispielsweise Steuerfunktion ausführt bzw. über nimmt, und als Knoten eines Clusters dienen kann bzw. dient, ein Automatisierungsgerät im Sinne der vorliegenden Erfin dung .

Das erfindungsgemäße Automatisierungsgerät umfasst bevorzugt eine Geräte-Management-Einheit, die dazu ausgebildet und/oder eingerichtet ist, zu überwachen, ob dem Gerät ein Automati sierungs-Kenner zugeordnet wird, und für den Fall, dass die Zuordnung eines solche erkannt wird, bei einer zentralen Cluster-Management-Einheit anzufragen, ob in einer zu dem Cluster, an welchem das Gerät als Knoten teilnimmt bzw. teil nehmen soll gehörigen Cluster-Zustands-Datenbank mit Be schreibungsobjekten für Knoten des Clusters bereits ein den in Schritt c) zugeordneten Automatisierungs-Kenner umfassen des Beschreibungsobjekt existiert, gegebenenfalls für einen anderen als einen dem Gerät zugeordneten Knoten-Kenner, und in dem Fall, dass noch kein solches Beschreibungsobjekt exis tiert oder in dem Fall, dass ein solches Beschreibungsobjekt existiert, dieses jedoch als inaktiv deklariert ist, ein den Automatisierungs-Kenner umfassendes Beschreibungsobjekt für einen dem Automatisierungsgerät zugeordneten Knoten-Kenner in der Cluster-Zustands-Datenbank zu erzeugen oder den Automati sierungs-Kenner in einem in der Datenbank bereits für einen dem Gerät zugeordneten Knoten-Kenner existierenden Beschrei bungsobjekt zu hinterlegen.

Die Geräte-Management-Einheit kann eine funktionale Einheit darstellen, die beispielsweise durch eine Software-Komponente auf geeigneter Hardware implementiert sein kann. Das gleiche gilt für die zentrale Cluster-Management-Einheit, die eben falls eine funktionale Einheit gegeben sein kann, die etwa durch eine Software (beispielsweise Kubernetes) gegeben ist, die insbesondere auf einer zentralen Hardware läuft, auf die die Knoten zugreifen können.

Eine weitere Ausführungsform des erfindungsgemäßen Automati sierungsgerätes zeichnet sich dadurch aus, dass das Automati sierungsgerät dazu ausgebildet und/oder eingerichtet ist, un ter Rückgriff auf ein in einer zu dem Cluster, an welchem das Gerät als Knoten teilnimmt bzw. teilnehmen soll gehörigen Cluster-Zustands-Datenbank hinterlegten Beschreibungsobjektes wenigstens eine insbesondere containerisierte Automatisie rungsfunktion zugeordnet zu bekommen.

In weiterer vorteilhafter Ausgestaltung weist das erfindungs- gemäße Automatisierungsgerät eine Selbsttaufe-Einheit auf, die dazu ausgebildet und/oder eingerichtet ist, eine Selbst- taufe bzw. ein Selbsttaufe-Verfahren abzuwickeln, insbesonde re das in der ebenfalls auf die Anmelderin zurückgehenden eu ropäischen Patentanmeldung Nr. 18188735.7 beschriebene Ver fahren zur dezentralen Selbsttaufe unter Zuhilfenahme des Do main Name Systems (DNS, siehe insbesondere RFC 1034 und

1035) .

Ein weiterer Gegenstand der vorliegenden Erfindung ist ein Computerprogramm, das Programmcodemittel zur Durchführung der Schritte des erfindungsgemäßen Verfahrens umfasst.

Schließlich ist Gegenstand der Erfindung ein computerlesbares Medium, das Instruktionen umfasst, die, wenn sie auf wenigs tens einem Computer ausgeführt werden, den wenigstens einen Computer veranlassen, die Schritte des erfindungsgemäßen Ver fahrens durchzuführen.

Bei dem computerlesbaren Medium kann es sich beispielsweise um eine CD-ROM oder DVD oder einen USB oder Flash Speicher handeln. Es sei angemerkt, dass unter einem computerlesbaren Medium nicht ausschließlich ein körperliches Medium zu ver stehen sein soll, sondern ein solches beispielswiese auch in Form eines Datenstromes und/oder eines Signals, welches einen Datenstrom repräsentiert, vorliegen kann.

Weitere Merkmale und Vorteile der vorliegenden Erfindung wer den anhand der nachfolgenden Beschreibung erfindungsgemäßer Ausführungsformen unter Bezugnahme auf die beiliegende Zeich nung deutlich. Darin ist

FIG 1 eine rein schematische Teildarstellung eines industri ellen Automatisierungsnetzwerkes mit mehreren, jeweils einen Cluster-Knoten bildenden erfindungsgemäßen Auto matisierungsgeräten; und

FIG 2 eines der Automatisierungsgeräte aus FIG 1 und die

zentrale Cluster-Management-Einheit . Die FIG 1 zeigt eine stark vereinfachte, rein schematische Teildarstellung ein industrielles Automatisierungsnetzwerkes. Konkret sind von dem Automatisierungsnetzwerk vier Automati sierungsgeräte 1 in Form von Industrie-PCs gegeben, die je weils wenigstens eine Automatisierungsfunktion bzw. Automati sierungsaufgabe, konkret für einen in den Figuren nicht wei ter dargestellten industriellen technischen Prozess, vorlie gend einen Produktionsprozess, übernehmen. Die vier Geräte 1 bilden allesamt Bestandteile einer Automatisierungsanlage, die in aus dem Stand der Technik hinlänglich vorbekannter Weise diverse weitere Komponenten, u.a. konventionelle Auto matisierungsgeräte, wie speicherprogrammierbare Steuerungen, IO-Geräte und dergleichen, umfasst, die in der FIG 1 nicht weiter dargestellt sind. Die Wolke deutet an, dass die Geräte 1 verbunden sind, beispielsweise über Ethernet (gemäß IEEE 802.3) . Jedes der vier Geräte 1 stellt ferner ein Edge-Gerät dar, das aus Sicht eines Cluster-Orchestrierungssystems als Arbeitsknoten erscheint, dem Arbeitsaufgaben (in Form von Containern) zugewiesen werden können.

Jedes der vier Geräte 1 fungiert als Knoten eines Clusters 2 und übernimmt bestimmte Arbeitslasten des Clusters 2 in Form von ( Software- ) Containern . Die Arbeitslasten in Form von ( Software- ) Containern schließen die jeweilige wenigstens eine Automatisierungsfunktion bzw. Automatisierungsaufgabe mit ein. Dabei gilt, dass die Arbeitslasten bestimmter Anlagen spezifischer Funktionen bestimmten, zugehörigen Anlagenteilen zugeordnet sind, zu denen jeweils ein bestimmtes Industrial- Edge-Gerät 1 gehört.

Für die Orchestrierung der Arbeitslasten des Clusters 2 dient eine zentrale Cluster-Management-Einheit 3, die nur in der ebenfalls rein schematischen FIG 2 dargestellt ist. Die zent rale Cluster-Management-Einheit 3 ist für das Verteilen von Arbeitslasten auf die Knoten 1 des Clusters 2, also (u.a.) auf die Automatisierungsgeräte 1 zuständig. Die zentrale Cluster-Management-Einheit 3 ist vorliegend eine rein funkti onale Einheit, die bei dem hier beschriebenen Beispiel durch eine Software, konkret Kubernetes gegeben ist. In dieser kön nen Knoten 2 und Arbeitslasten mit Knoten-Kennern/Knoten-IDs 4 (siehe FIG 2) in Form von sogenannten „Labein" versehen werden, die eine selektive Zuordnung von Arbeitslasten zu Ar beitern ermöglichen. Selbstverständlich kann alternativ zu Kubernetes auch andere Orchestrierungs-Software als eine zentrale Cluster-Management-Einheit 3 zum Einsatz kommen.

Die Automatisierungsgeräte 1 können beispielsweise im Rahmen eines von der zentrale Cluster-Management-Einheit 3 abgewi ckelten Onboarding-Prozesses in den Cluster 2 aufgenommen werden. Die Knoten-Kenner 4 können dann im Rahmen des Onboar- ding-Prozesse oder im Anschluss an diesen zugeordnet werden bzw. worden sein.

Auf die zugeordneten Knoten-Kenner bzw. Cluster-Label 4 kann beim Zuordnen von funktionsspezifischen Arbeitslasten gefil tert werden, um eine bestimmte Container-Funktion nur einem einzelnen oder auch einem Satz von Knoten/Nodes/ Industrial Edge Geräten 1 zuzuweisen. Gemäß dem Stand der Technik liegt das Zuweisen solcher Label 4 an Knoten/Nodes/Edge Geräte 1 dabei rein im Ausführungsbereich des Anwenders, hat konkret manuell zu erfolgen.

Jedes der vier Automatisierungsgeräte 1 umfasst weiterhin ei ne Selbsttaufe-Einheit 5, die dazu ausgebildet und/oder ein gerichtet ist, eine dezentralen Selbsttaufe des jeweiligen Gerätes 1 unter Zuhilfenahme des Domain Name Systems abzuwi ckeln, wie sie in der ebenfalls auf die Anmelderin zurückge henden europäischen Patentanmeldung Nr. 18188735.7 beschrie ben ist. Über die Selbsttaufe bzw. das Selbsttaufe-Verfahren wird dem jeweiligen Gerät 1 ein Automatisierungs-Kenner 6 zu geordnet, bei dem es sich beispielsweise um einen vollständig qualifizierten Domain Namen (FQDN) handeln kann.

Alternativ oder zusätzlich dazu, dass das Gerät 1 den Automa tisierungs-Kenner 6 über ein Selbsttaufe-Verfahren erhält, kann auch vorgesehen sein, dass ihm dieser von einem anderen Automatisierungsgerät, etwa einer Steuerung zugewiesen wird, oder dieser über ein Einrichtungs-Werkzeug zugeordnet wird, beispielsweise in Form eines sogenannten Name of Station (NoS) 7. Als Beispiel für ein solches Einrichtungs-Werkzeug sei das PROFINET-Primary-Setup-Tool genannt. In der FIG 2 sind beide Möglichkeiten, die in der Regel Alternativen dar stellen, angedeutet, konkret dadurch, dass sowohl von der Selbsttaufe-Einheit 5 als auch dem NoS 7 jeweils ein gestri chelter Pfeil zu dem den Automatisierungs-Kenner 6 repräsen tierenden Blockelement dargestellt sind.

Bei dem Automatisierungs-Kenner 6 handelt es sich entspre chend um einen Kenner, insbesondere Namen, der dem jeweiligen Gerät 1 anhand bzw. im Rahmen von aus dem Bereich der indust riellen Automatisierungstechnik etablierten Kennzeichensyste me vergeben wurde.

Insbesondere, um etwa bei einer Erstinbetriebnahme eines ei nen Cluster-Knoten darstellenden Automatisierungsgerätes 1 oder einem Austausch eines solchen sicherzustellen, dass ge rätespezifische bzw. „ortsabhängige" Automatisierungs- , etwa Produktionsfunktionen zu dem jeweiligen Automatisierungsgerät 1 anhand der etablierter Kennzeichnungssysteme zugeordnet werden können, weist jedes der Automatisierungsgeräte 1 fer ner eine Geräte-Management-Einheit 8 auf.

Diese überwacht im Anschluss an die Bereitstellung des jewei ligen Gerätes 1, etwa dessen Anschluss an das Automatisie rungsnetzwerk und dessen Einschalten (Schritt a) ) im Betrieb des jeweiligen Gerätes 1, ob diesem ein Automatisierungs- Kenner 6 (Länge ungleich null) zugeordnet wird, der sich von dem Knoten-Kenner 4 unterscheidet (Schritt b) ) . Durch diese Überwachung wird sowohl ein erstmaliges Zuordnen eines Auto matisierungs-Kenners 6 erfasst als auch der Fall, dass sich ein Automatisierungs-Kenner 6 ändert, also bereits zuvor ein Automatisierungs-Kenner 6 zugeordnet wurde und anschließend ein neuer Automatisierungs-Kenner 6 zugeordnet wird. Wenn die Geräte-Management-Einheit 8 eine solche Zuordnung erkannt hat, fragt sie bei der zentralen Cluster-Management- Einheit 3 an, ob in einer zu dem Cluster 2 gehörigen Cluster- Zustands-Datenbank 9 mit Beschreibungsobjekten 10, 11 für

Knoten 1 des Clusters 2 bereits ein Beschreibungsobjekt 10,

11 existiert, in dem der dem Automatisierungsgerät 1 zugeord nete Automatisierungs-Kenner 6 hinterlegt ist (Schritt c) ) .

Zu beachten ist, dass sich bei einem Gerätetausch der Knoten- Kenner 4 vom ursprünglichen (nun defekten Gerät 1) unter scheiden wird.

Bei den Beschreibungsobjekten 10, 11 in der Cluster-Zustands- Datenbank 9 handelt es sich um solche, die die gewünschten und aktuellen Zustände der Knoten 1 im Cluster 2 beschreiben.

In dem Fall, dass ein solches Beschreibungsobjekt 10, 11, al so ein Beschreibungsobjekt 10,11, in welchem der zugeordneten Automatisierungs-Kenner 6 insbesondere in Form eines Labels 12, 13 hinterlegt ist, bereits für den dem Automatisierungs gerät 1 zugeordneten Knoten-Kenner 4 existiert, und dieses Beschreibungsobjekt als aktiv deklariert ist, wird dieses Be schreibungsobjekt 10, 11 als Beschreibungsobjekt 10, 11 des Automatisierungsgerätes 1 erachtet.

In dem Fall, dass noch kein solches Beschreibungsobjekt 10,

11 existiert oder in dem Fall, dass ein solches Beschrei bungsobjekt 10, 11 für einen anderen als den dem Automatisie rungsgerät 1 zugeordneten Knoten-Kenner 4 existiert und als inaktiv deklariert ist, erzeugt die Geräte-Management-Einheit 8 in der Cluster-Zustands-Datenbank 9 für den dem Automati sierungsgerät 1 zugeordneten Knoten-Kenner 4 ein Beschrei bungsobjekt 10, 11, in dem der dem Automatisierungsgerät 1 zugeordnete Automatisierungs-Kenner 6 hinterlegt ist, oder hinterlegt den dem Automatisierungsgerät 1 zugeordneten Auto matisierungs-Kenner 6 in einem in der Cluster-Zustands-Daten bank 9 bereits für den dem Automatisierungsgerät 1 zugeordne- ten Knoten-Kenner 4 existierenden Beschreibungsobjekt 10, 11 oder veranlasst die Hinterlegung oder die Erzeugung.

Die Geräte-Management-Einheit 8 kann beispielsweise der zent ralen Cluster-Management-Einheit 3 den Automatisierungs-Ken ner 6 übergeben und diese dazu veranlassen, diesen in einem existierenden Beschreibungsobjekt 10, 11 zu hinterlegen bzw. ein neues Beschreibungsobjekt 10, 11 mit diesem zu erzeugen (Schritt d) ) .

Der Automatisierungs-Kenner 6 wird dabei in dem Beschrei bungsobjekt 10, 11 als Bestandteil eines Labels 12, 13 hin terlegt. Das bedeutet, das in der Datenbank 9 in dem Objekt 10, 11 hinterlegte Label 12, 13 umfasst den Automatisierungs- Kenner 6 und kann auch als Automatisierungs-Label 12, 13 auf gefasst bzw. bezeichnet werden. Dies gilt sowohl für den Fall, dass ein neues Beschreibungsobjekt 10, 11 erzeugt wird, in dem der Automatisierungs-Kenner 5 hinterlegt ist bzw.

wird, als auch für den Fall dass die Hinterlegung in einem existierenden Beschreibungsobjekt 10, 11 erfolgt.

Bei dem in FIG 2 skizzierten Beispiel existiert bereits ein „altes" Beschreibungsobjekt 10, das als „inaktiv" deklariert ist und ein „altes" Label 12 umfasst, und es wird ein „neues" Beschreibungsobjekt 11 mit „neuem", den Automatisierungs- Kenner 6 umfassenden Label 13 erzeugt.

Für einen solchen Fall, also wenn ein altes als „inaktiv" de klariertes Beschreibungsobjekt 10 gefunden wurde, wird aus diesem bevorzugt das Label 12 entfernt. Auch ist es möglich, das alte, „inaktive" Beschreibungsobjekt 10 vollständig zu entfernen. So wird die Datenbank von Einträgen defekter Gerä te automatisch bereinigt und aktuell gehalten.

Die Label 12, 13 haben bevorzugt die Form Schlüssel=Wert . Der Schlüssel kann beispielsweise die Struktur

„Siemens . edge/name" haben und der Wert des (alten oder neuen) Automatisierungs-Kenners 6, etwa FQDNs . Dabei ermittelt die Geräte-Management-Einheit 8 lokal den dem Automatisierungsgerät 1 zugeordneten Knoten-Kenner 4 und adressiert in Schritt d) das zu erzeugende Beschreibungsob jekt 11 (oder das existierende Beschreibungsobjekt 10), in dem der Automatisierungs-Kenner 6 zu hinterlegen ist, über den dem Automatisierungsgerät 1 zugeordneten, lokal ermittel ten Knoten-Kenner 4. Die lokale Ermittlung des Knoten-Kenners 4 kann beispielsweise erfolgen, indem die Geräte-Management- Einheit 8 diesen lokal abfragt. Dies kann beispielsweise über einen REST- oder RPC-Aufruf über HTTPS erfolgen.

Dem Automatisierungsgerät 1 wird dann unter Rückgriff auf das Beschreibungsobjekt 11, das in Schritt d) erzeugt wurde (bzw. in dem in Schritt d) der Automatisierungs-Kenner 6 hinterlegt wurde) , wenigstens eine containerisierte Automatisierungs funktion zugeordnet, konkret wenigsten eine Arbeitslast in Form einer durch einen Software-Container gegebenen Automati sierungsfunktion .

Nachfolgend können dann vorbekannte Orchestrierungsmechanis men, insbesondere der zentralen Cluster-Management-Einheit 3 (vorliegend Kubernetes) die dem Automatisierungsgerät 1 vom Anwender spezifisch per Automatisierungs-Kenner 6 und somit Label 13 zugeordneten Arbeitslasten in Form von Containern zugewiesen werden und darauf folgende Download- und Deploy- ment-Prozesse wie gewohnt ablaufen.

Im Ergebnis wird die automatisierungstechnische Besonderheit abgebildet, dass Automatisierungsgeräte 1 etwa in einem Pro duktionsnetz nicht immer beliebig untereinander austauschbare Geräte 1 darstellen, sondern diese (auch) automatisierungs- , etwa produktionsspezifische Aufgaben erfüllen müssen, die durch andere Automatisierungsgeräte 1 und/oder an anderer Stelle nicht erbracht werden können. Dabei wird dies zuver lässig gewährleistet, ohne dass es eines manuellen Eingrif fes, etwa eines manuellen Labeins bzw. einer manuellen Konfi guration durch einen Benutzer bedarf. Durch die Geräte-Management-Einheit 8 werden zumindest die folgenden vier Fälle abgedeckt:

1. Neu-Gerät: für ein neues Gerät 1, das zuvor in den Cluster per „onboarding" aufgenommen wurde und dabei einen eigene Knoten-Kenner 4 erhalten hat, wird, nachdem es auch seinen Automatisierungs-Kenner 6 erhalten hat (beispielsweise als NoS 7 oder von der Selbsttaufe-Einheit 5) erstmalig dessen Automatisierungs-Kenner6 in dem Beschreibungsobjekt 11 als bzw. Bestandteil des Automatisierungs-Label 13 hinterlegt.

2. Änderung des Automatisierungs-Kenners 6: hierbei wird das Label 12, 13 im Beschreibungsobjekt 10, 11 aktualisiert (um den dann neuen, geänderten Automatisierungs-Kenner 6) , unter Berücksichtigung des Fehlerfalls, dass der neue Au tomatisierungs-Kenner 6 bereits vergeben wurde.

3. Geräte-Tausch : hierbei wird das „alte" Beschreibungsobjekt 10 des alten, defekten Gerätes 1 anhand des Automatisie rungs-Kenners 6 des Austausch-Geräts 1 ermittelt und ge prüft, ob das zugehörige Beschreibungsobjekt insbesondere von der zentralen Cluster-Management-Einheit 3 bereits als „inaktiv" (also „defekt" bzw. „ausgefallen") markiert wur de. Ist dies der Fall, dann kann der Automatisierungs- Kenner 6 des neuen (Austausch- ) Gerätes 1 als Automatisie rungs-Label 13 im neuen Beschreibungsobjekt 11 hinterlegt werden .

4. Geräte-Dublette : hierbei existiert ein Beschreibungsobjekt 10 („alt") eines bereits vorhandenen Gerätes 1 mit dem Au tomatisierungs-Kenner 6 im Label 12. Zudem ist dieses „al te" Beschreibungsobjekt 10 von der zentralen Cluster- Management-Einheit 3 als „aktiv" („alive") ausgewiesen. In diesem Fall wird der Automatisierungs-Kenner 6 nicht über tragen, also weder vom „alten" Beschreibungsobjekt 10 ent fernt, noch auf das Beschreibungsobjekt der Geräte- Dublette übertragen.

Für den Fall, dass dem Automatisierungsgerät 1 bereits (we nigstens einmal) ein Automatisierungs-Kenner 6 zugeordnet wurde (vorheriger/"alter" Kenner) und dann ein weiterer Auto matisierungs-Kenner 6 zugeordnet wird („neuer" Kenner), kann vorgesehen sein, dass die Geräte-Management-Einheit 8, nach dem sie die Zuordnung des weiteren Automatisierungs-Kenners 6 erkannt hat, die zentrale Cluster-Management-Einheit 3 kon taktiert und veranlasst, dass das (vorherige) Beschreibungs objekt 10, in dem der vorherige Automatisierungs-Kenner 6 insbesondere als Label 12 hinterlegt ist, gelöscht wird. So kann die Datenbank 9 „aufgeräumt" bzw. aktuell gehalten wer den .

Es sei angemerkt, dass für den Fall, dass die Anfrage, ob in der zu dem Cluster 2 gehörigen Cluster-Zustands-Datenbank 9 bereits für einen anderen als den dem Automatisierungsgerät 1 zugeordneten Knoten-Kenner 4 ein Beschreibungsobjekt 10, 11 existiert, in dem der dem Automatisierungsgerät 1 zugeordnete Automatisierungs-Kenner 6 hinterlegt ist, ergibt, dass dem so ist und dieses Beschreibungsobjekt 10, 11 als aktiv dekla riert ist, die Geräte-Management-Einheit 8 kein Beschrei bungsobjekt 10, 11 mit dem Automatisierungs-Kenner 6 in der

Cluster-Zustands-Datenbank 9 für den dem Automatisierungsge rät 1 zugeordneten Knoten-Kenner 4 erzeugt, und den dem Auto matisierungsgerät 1 zugeordneten Automatisierungs-Kenner 6 auch nicht in einem in der Cluster-Zustands-Datenbank 9 be reits für den dem Automatisierungsgerät 1 zugeordneten Kno ten-Kenner 4 existierenden Beschreibungsobjekt 10,11 hinter legt und die Hinterlegung oder die Erzeugung auch nicht ver anlasst. Dies vermeidet zuverlässig eine „Doppelbelegung" bzw. „Doppelnutzung".

Weiterhin sei angemerkt, dass die vier in FIG 1 beispielhaft dargestellten Automatisierungsgeräte 1 allesamt Ausführungs beispiele erfindungsgemäßer Automatisierungsgeräte darstell ten, die ausgebildet und/oder eingerichtet sind, die vorste hend beschriebenen Schritte eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens durchzuführen. Die vorstehend bespielhaft für ein Automatisierungsgerät 1 beschriebenen Ab- laufe gelten gleichermaßen für alle in FIG 1 dargestellten Automatisierungsgeräte 1.

Das industrielle Netzwerk gemäß FIG 1 ist ferner ein Ausfüh- rungsbeispiel eines erfindungsgemäßen Netzwerkes.

Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh rungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge- schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen .