Verfahren zur automatischen Anpassung der internen Konfigura tion einer externen Netzwerkschnittstelle, Computerprogramm- produkt und Vorrichtung

Die vorliegende Erfindung betrifft ein Verfahren, ein Compu- terprogrammprodukt sowie ein System ... in einem industriellen AutomatisierungsSystem.

Industrielle AutomatisierungsSysteme umfassen üblicherweise eine Vielzahl von über ein industrielles Kommunikationsnetz miteinander vernetzten Automatisierungsgeräten und dienen im Rahmen einer Fertigungs- oder Prozessautomatisierung zur Steuerung oder Regelung von Anlagen, Maschinen bzw. Geräten. Aufgrund zeitkritischer Rahmenbedingungen in industriellen AutomatisierungsSystemen werden zur Kommunikation zwischen Automatisierungsgeräten überwiegend Echtzeit-Kommunika- tionsprotokolle, wie PROFINET, PROFIBUS, Real-Time-Ethernet oder Time-Sensitive Networking (TSN) und OPC UA, verwendet. Insbesondere können Steuerungsdienste bzw. -anwendungen auto matisiert und auslastungsabhängig auf aktuell verfügbare Ser ver oder virtuelle Maschinen eines industriellen Automatisie rungssystems verteilt werden.

Unterbrechungen von KommunikationsVerbindungen zwischen Rech nereinheiten eines industriellen AutomatisierungsSystems oder Automatisierungsgeräten können zu einer unerwünschten oder unnötigen Wiederholung einer Übermittlung einer Dienstanfor derung führen. Außerdem können nicht oder nicht vollständig übermittelte Nachrichten beispielsweise einen Übergang oder Verbleib eines industriellen AutomatisierungsSystems in einen sicheren Betriebszustand verhindern. In Ethernet-basierten Kommunikationsnetzen können Probleme entstehen, wenn Netzressourcen für eine Übermittlung von Da tenströmen oder von Datenrahmen mit Echtzeitanforderungen konkurrierend für eine Übermittlung von Datenrahmen mit gro ßem Nutzdateninhalt ohne spezielle Dienstgüteanforderungen beansprucht werden. Dies kann schließlich dazu führen, dass Datenströme oder Datenrahmen mit Echtzeitanforderungen nicht entsprechend einer angeforderten bzw. benötigten Dienstgüte übermittelt werden.

Mit der Industrial Edge können beispielsweise automatisie rungstechnische Anwender einfach und modular die von ihnen gewünschten Funktionalitäten für ihre Automatisierung in Form sogenannter Apps (Applikationen) installieren, aktualisieren und erweitern. Einerseits profitieren Anwendern von zentrali sierter und einfach skalierbarer Verwaltung auch vieler In dustrial Edge-Geräte, andererseits vom Markt, der ebenfalls Drittanbieter dieser Apps umfasst. Ein wesentlicher weiterer Aspekt ist der Wunsch der Automatisierungsanwender, Applika tionen unterschiedlicher Anbieter möglichst ohne zusätzlichen Integrationsaufwand einfach installieren und sofort in Be trieb nehmen zu können.

Anwender von, mittels Containervirtualisierung oder ver gleichbaren Virtualisierungskonzepten realisierten, Steue- rungsanwendungen für industrielle AutomatisierungsSysteme er warten weiterhin eine möglichst unkomplizierte Integration derartiger Anwendungen in ihre bestehende Infrastruktur. Je nach Netzwerkanbindung und verwendeter Ablaufsteuerungsumge- bung treffen beispielsweise OPC UA Server auf höchst unter schiedliche anwenderseitige Konfigurationen, die durch Ent wickler von Steuerungsanwendungen bei automatisierten Konfi- gurationsverfahren für die Steuerungsanwendungen berücksich- tigt werden müssen. Bei der Netzwerkanbindung stellen anwen derseitig knappe IP-Adress- und TCP-Portnummernbereiche be sondere Herausforderungen im Rahmen der Integration von Steu- erungsanwendungen in eine bestehende Infrastruktur dar. Außerdem muss der automatisierungstechnische Anwender die an deren Anteile seiner Automatisierungsapplikation mit den Ser vern über die konkreten NetzwerkadressierungsInformationen verknüpfen .

Mit der Verwendung der (Industrial) Edge Technologie funktio niert die optimale Datennutzung in der Anwendung, beispiels weise in einer Industriellen Anlage, einfacher, flexibler und sicherer . Das Erfassen und Verarbeiten von Daten erfolgt de zentral, direkt und abgesichert an dem jeweiligen Edge-Gerät, für Verwaltung, und Bereitstellung von Software sowie deren Aktualisierungen steht ein zentrales System zur Verfügung.

Das (Industrial) Edge Management System ist die zentrale Inf rastruktur, mit der alle verbundenen Edge-Geräte jeder Art verwaltet werden. Anstatt Software-Aktualisierungen und Feh lerkorrekturen (z. B. Security-Patches) auf jedes Edge-Gerät einzeln aufspielen zu müssen, wird alles zentral von einem System aus gesteuert, das je nach Bedarf vor Ort oder auch in der Cloud installiert sein kann.

Auf den Edge-Geräten kann zum Erzeugen und Verwalten von so genannten Containern beispielsweise die bekannte Software „Docker" verwendet werden, die dank Containervirtualisierung zahlreiche Vorteile aufweist, wie geringer Ressourcenbedarf, schnelle Bereitstellung und eine einfache Handhabung für den Benutzer . Neue Applikationen können in beliebigen Hochspra chen entwickelt werden (nicht abschließend C/C++, Java, Py thon, Node.js, ...) und dann als sogenanntes Docker-Image vir- tualisiert werden und dann skalierbar auf allen Edge Geräten ablauffähig sind. Benötigt wird dafür eine passende Laufzeitumgebung (runtime environment), die zur Laufzeit der Computerprogramme die ver fügbaren und festgelegten Voraussetzungen des LaufzeitSystems (runtime System) definiert. Dieses ist durch die elementaren Bestandteile der Programmiersprache, wie beispielsweise das Verhalten von Sprachkonstrukten, und weitere Funktionen, wie Typprüfung, Debugging, Codegenerierung und -Optimierung, de finiert. Zur Laufzeitumgebung gehören weitere Module wie eine Laufzeitbibliothek, Standardbibliotheken, ProgrammierSchnitt stellen, Laufzeitvariablen sowie auf Hard- und Softwarekompo- nenten über Betriebssystemfunktionen.

Ein Vorteil bei der Verwendung von Industrial Edge besteht für Kunden darin, dass die eingesetzten Container eine vor teilhafte Modularisierung von Automatisierungs-Applikationen liefern, samt deren einheitlicher Verpackung, Transport, In stallation und Aktualisierung. Zudem minimieren Container die inzwischen nur noch schwer handhabbaren Abhängigkeiten zwi schen Anwendungen, Hilfsbibliotheken und dem Betriebssystem, ganz ohne den riesigen Mehrbedarf an Ressourcen der traditio nellen Virtuellen Maschinen (VMs).

Der Einsatz containerisierter Automatisierungs-Applikationen in einer Industrial Edge in der industriellen Produktion weicht dabei in manchen Belangen vom Container-Einsatz in ei ner herkömmlichen Datacenter/Cloud-Umgebung ab, wie insbeson dere deren Vernetzung. So werden Industrial Edge Geräte oft mals an mehrere, strikt voneinander getrennte Netzwerke ange bunden, wie beispielsweise Fabrik- und davon separate Maschi nen/Zellen-Netzwerke . Je nach verwendeter (Industrie PC-) Ge rätehardware wird der industrielle Anwender mit, in verwir render Weise variierenden, Hardware-BeZeichnern im Betriebs system eines Industrial Edge Gerätes konfrontiert, die zudem nicht einmal mit den auf dem Gehäuse eingravierten Beschrif tungen übereinstimmen.

Figur 1 illustriert ein solches Beispiel, mit drei Industrial Edge Geräten IE1, IE2, IE3, welche auf unterschiedlicher Hardware basieren, wobei zwei der Geräte IE1 und IE2 jeweils zwei Schnittstellen mit den (identischen) Bezeichnern XI, X2 aufweisen zum Anschluss beispielsweise an ein Fabriknetz FN einerseits, und ein Maschinennetz MN andererseits. Dabei sind die Bezeichner der jeweiligen Schnittstellen XI und X2 in dem ersten Industrial Edge Gerät IE1 hinterlegt mit den Adressen „ens30" und „ens31", beim zweiten Gerät IE2 mit den Adressen „ex8f5b" und „usb325". Das dritte Gerät IE3 weist sowieso nur eine Schnittstelle mit der Bezeichnung XI auf mit der Adresse „ep0s3" .

Oftmals benutzen industrielle Anwender containerisierte Ap plikationen, die einen direkten Data Link Layer-Zugang („Lay- er 2-Zugang" beispielsweise zum Maschinennetz) benötigen, um Automatisierungsgeräte mit den heute im industriellen Umfeld gängigen Kommunikations-Protokollen wie PROFINET anzuspre chen. Tatsächlich gehören zur Basisausstattung der Industrial Edge mehrere solche Schicht 2 / Layer 2 / Data Link Layer- Applikationen, beispielsweise eine Verzeichnis Applikation, die sogenannte „Inventory App" für Automatisierungsgeräte.

Mit dieser Applikation können Geräteinformationen gescannt,

BeStandsInformationen für andere Systeme und Tools bereitge stellt und der Handlungsbedarf zur Gewährleistung der Geräte verfügbarkeit bestimmt werden.

Die Container derartiger Layer 2-Applikationen können dabei mit den heute verfügbaren virtuellen Netzwerkelementen der Betriebssysteme innerhalb einer Industrial Edge mit dem oder den Automatisierungsnetzen geeignet verbunden werden, bei- spielsweise mit Hilfe von virtuellen Bridges, virtuellen Ethernet-Habeln und MACVLAN-Schnittstellen bei Linux.

Dabei sind heute verschiedene Konfigurationen bekannt, um den gewünschten Layer 2-Zugang zu erzielen, insbesondere:

(1) per MACVLAN und alternativ

(2) per Bridge, der eine Geräte-Netzwerkschnittsteile zuge ordnet („enslaved") wird, sowie Virtual Ethernet (VETH)- Verkabelungen zu den einzelnen Geräten.

Hierbei ist insbesondere die Konfiguration (2) für den Ein satz in der Industrial Edge interessant, zugleich soll es aber weiterhin möglich sein, bei (Kunden-) Bedarf auch die alternative Konfiguration (1) anzubieten. Setzt ein Kunde al lerdings keinerlei Schicht 2 / Layer 2-Applikationen ein, dann soll auch keine der Konfigurationen in einer Industrial Edge aktiviert sein.

Eine Bridge ist ein Gerät, das zwei Datalink / Layer 2- Segmente (z. B. Ethernet) miteinander verbindet. Datenpakete, sogenannte Frames zwischen den beiden Segmenten werden basie rend auf den Layer 2-Adressen (d. h. MAC-Adressen) weiterge leitet. Eine Bridge kann sowohl als physisches Gerät oder komplett in Software implementiert werden.

Mit MACVLAN können mehrere Layer 2- (also in dem obigen Bei spiel: Ethernet-MAC-) Adressen auf einer einzigen physikali schen Schnittstelle konfiguriert werden, Sub-Schnittstellen (auch als Slave-Geräte bezeichnet) einer übergeordneten, phy sischen Ethernet-Schnittstelle (auch als Master-Gerät be zeichnet) konfiguriert, jede mit ihrer eigenen eindeutigen (zufällig generierten) MAC-Adresse und folglich ihrer eigenen IP-Adresse . Anwendungen, VMs und Container können sich dann an eine bestimmte Sub-Schnittstelle binden, um sich direkt mit dem physischen Netzwerk zu verbinden, wobei sie ihre ei gene MAC- und IP-Adresse verwenden.

Nachteilig ist bei der oben beschriebenen Konstellation, dass sich insbesondere bei der Konfiguration (2) mit einer Bridge die interne Netzwerkstruktur insofern verändert, als die für die Einbindung in die externen Fabrik-, FN und Maschinennetz werke, MN mit den korrekten (IP-) Adressen, IPAdrl, IPAdr2 zu konfigurierenden Netzwerkschnittstellen ändern. Dies ist in der Figur 2 illustriert.

In dem Industrial Edge Gerät IE, 100 sind zwei Container 160, 161, mit jeweils einem zugehörigen IP-Stack, IPstu, und einer Applikation, cntr installiert. Es existiert ein weiterer zentraler IP-Stack, 140, der über eine Bridge, brl, mit den Containern 161, 160 über Layer 2, IPstu verbunden ist und auf der anderen Seite mittels einer zweiten Bridge, brm, mit den jeweiligen Geräteschnittstellen lila und 111b, des Industrial Edge Gerätes, welche mit der Bezeichnung XI und X2 von Facto- ry Netz FN beziehungsweise dem Maschinennetzwerk MN bekannt sind.

Konkret darf in der Konfiguration (2) mit einer Bridge nicht mehr wie zuvor, die Hardware-Schnittstelle, hier lila, 111b mit den Werten IPAdr 1 „ens30" bzw. „ens31", zu einem Automa tisierungsnetz IP-technisch konfiguriert werden, sondern es muss stattdessen die interne virtuelle Bridge brm, 112 IP- technisch mit der Adresse IPAdr2 konfiguriert werden.

Das vorgenannte Problem wird heute manuell mit Hilfe von Ex perten gelöst. Diese Experten konfigurieren nach Kundenanfor derung die Systeme entsprechend erstmalig oder als Service später im Betrieb bei geänderten Anforderungen. Technische Werkzeuge zur Unterstützung fehlen weitgehend. Heute bekannte Netzwerk-Werkzeuge wie beispielsweise „netma- nager" (https://en.in.wikipedia.org/wiki/NetworkManager) im Linux-Umfeld sowie gängige Netzwerk-Konfigurationsoberflächen sind Schnittstellen-orientiert und bieten keine Abstraktionen an. Insbesondere sind sie nicht explizit darauf ausgelegt, dem Anwender beim Konfigurieren der quasi-statischen Anteile der virtuellen geräte-internen Netzwerke zu helfen, sondern erwarten vom Anwender das notwendige Fachwissen, insbesondere die IP-Konfiguration eigenständig korrekt vorzunehmen zu kön nen, und gleichzeitig zu wohlmeinende Netzwerk-Werkzeuge da von abhalten, konflikterzeugende Einstellungen unerwünscht vorzunehmen .

Im Cluster- und Container-Umfeld bietet das Programm „multus" (https://github.com/intel/multus-cni, ein sogenanntes Contai ner Network Interface, CNI-Plugin für die Netzwerkkonfigura tion in Container-Systemen) zwar eine Abstraktion in Form von Netzwerknamen anstatt von Schnittstellennamen, jedoch muss der IT-Experte auch hier für jeden Knoten einzeln die konkre te system-spezifische Abbildung dem CNI-Plugin per Konfigura tionsdatei mitteilen.

„Multus" bietet damit eine technische Lösung für die Problem stellung an, Container anhand logischer Netzschnittstellenna men auf die konkreten Schnittstellen abzubilden.

Die Attraktivität der Industrial Edge-Plattform steigt, wenn eine Konfiguration von Schnittstellen, nicht in Abhängigkeit von IT-Experten mit fehlendem oder zumindest mangelhaftem Verständnis für die Hintergründe der Automatisierungstechnik sondern optimalerweise automatisiert erfolgen könnte.

Es ist Aufgabe der Erfindung, in der beschriebenen Umgebung des (Industrial) Edge eine Unterstützung und Automatisierung anzubieten für die eigenständige Anpassung der IP- Konfiguration an wechselnde virtuelle Netzwerktopologien. Die Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen des Patentanspruch 1.

Die Aufgabe wird weiterhin gelöst durch ein Computerprogramm- produkt mit den Merkmalen des Patentanspruchs 7.

Zuletzt wird die Aufgabe gelöst mittels einer Vorrichtung, gemäß den Merkmalen des unabhängigen Patentanspruchs 8.

Vorteilhafte Aus- und Weiterbildungen sind durch die Unteran sprüche angegeben.

Das erfindungsgemäße Verfahren zur automatischen Anpassung der internen Konfiguration einer externen Netzwerkschnitt stellen an einem Gerät, wobei das Gerät einen internen, gerä- tezugehörigen, ersten Kommunikations-Stack umfasst, und Dienstkomponenten, die jeweils durch eine in eine AblaufSteu erungsumgebung ladbare und dort ausführbare Ablaufsteuerungs- komponente gekapselt sind und über einen eigenen, zweiten Kommunikations-Stack verfügen, wobei der erste Kommunikations-Stack und der zumindest zweite Kommunikations-Stack über interne virtuelle Netzwerke mit den Netzwerkschnittstellen (HNIF) verbunden sind, umfasst folgende Schritte:

- Ermitteln von Topologie-Informationen über interne virtuel le Netzwerke (IVN) und die Netzwerkschnittstellen (HNIF), wo bei die Topologie-Informationen auch Informationen über die zugrundeliegende Netz-Technologie enthält,

- Ermitteln, ob die Netzwerkschnittstelle (HNIFa, HINFb) di rekt mit dem internen gerätezugehörigen Kommunikations-Stack (HIP) verbunden ist, ansonsten

- Ermitteln eines Weges einer Verbindung von Netzwerkschnitt stelle (HNIFa, HINFb) zu dem internen gerätezugehörigen Kom munikations-Stack (HIP) in dem internen virtuellen Netzwerk

(IVN), und - Überschreiben der Konfiguration anhand der ermittelten To pologie-Information und Netz-Technologie Information.

Ablaufsteuerungskomponenten sind insbesondere Software- Container, die jeweils von anderen Software-Containern oder Container-Gruppen isoliert innerhalb der Ablaufsteuerungsum gebung auf einem Host-Betriebssystem einer Server-Einrichtung ablaufen . Grundsätzlich können für die Ablaufsteuerungskompo nenten auch alternative Micro-Virtualisierungskonzepte, wie Snaps, verwendet werden.

Die Ablaufsteuerungsumgebung kann beispielsweise eine Docker Engine oder einen Snap Core umfassen, die auf einer Server- Einrichtung abläuft. Vorteilhafterweise nutzen die Software- Container jeweils gemeinsam mit anderen auf der jeweiligen Server-Einrichtung ablaufenden Software-Containern einen Kernel des Host-BetriebsSystems der Server-Einrichtung. Spei cherabbilder für die Software-Container können beispielsweise aus einem durch eine Vielzahl von Nutzern lesend bzw. schrei bend zugreifbaren Speicher- und Bereitstellungssystem abgeru fen werden.

Die Realisierung des erfindungsgemäßen Verfahrens wird als (Logische) „Zwischenschicht" vorgeschlagen, die die für den Anwender sichtbaren Netzwerkparameter aus dessen Anwender sicht anhand der Edge-internen virtuellen Netzwerktopologie auf die jeweils zutreffenden konkreten Netzwerkschnittstellen umsetzt .

Die Figur 3 zeigt einen beispielhaften Aufbau eines neuarti gen Industrial Edge Gerätes IE, 100 umfassend die beanspruch te Vorrichtung, der sogenannte „Translator Manager" XAM, 131. Es ist dabei angenommen, dass dieses Gerät sowohl in Hardware als auch in Software als sogenanntes „virtuelles" Geräte aus gebildet sein kann.

Das Industrial Edge Gerät IE, 100 verfügt über zumindest ei ne, typischerweise aber mehrere physikalische Netzwerk schnittstellen HNIFa, HNIFb, lila, 111b zur Umgebung. Die physikalischen Netzwerkschnittstellen sind mit separaten (Au tomatisierungs-) Netzwerken verbunden, wie beispielsweise den Fabrik- oder Maschinennetzwerken AN 110a, 110b, über die auch weitere, an das Maschinennetzwerk AN angeschlossene Geräte, 121b, beispielsweise zur Bearbeitung von Werkstücken ange steuert werden können. Industrial Edge-intern sind die Netz werkschnittstellen HNIFa, HNIFb über virtuelle interne Netz werke IVNa, IVNb sowohl mit dem Kommunikations-IP-Stack, HIP, 140 des Industrial Edge Gerätes selbst verbunden, als auch mit den einzelnen IP-Stacks CIP, 141 von den gespeicherten Containern, CTR, die einen direkten Schicht / Layer 2-Zugang erfordern . Der Anwender entscheidet hierbei, in welchem Um fang den Schicht/Layer 2 -Containern Zugang zu welchen der Automatisierungsnetze AN, 110a, 110b gegeben wird. Diese An wenderwahl entscheidet darüber, ob und in welcher Form die IVN 112a, 112b konkret ausgestaltet sind: die einzelnen Schritte des Ablaufs werden auch in der Figur 4 exemplarisch dargestellt .

Ohne Schicht/Layer 2-Zugang wird zur Optimierung der System performance die jeweilige Netzwerkschnittstelle HNIFa, HNIFb direkt einem Host IP-Stack des Gerätes, HIP zugeordnet und muss IP-technisch konfiguriert werden. Diese Möglichkeit ist in der Figur 2 so direkt nicht abgebildet. Wir nennen diesen Fall für die weitere Erklärung auch Konfiguration (0). Dies entspricht in der Figur 4 dem linken Baumsegment, 900. Mit Schicht / Layer 2-Zugang in Form von MACVLAN, der oben genannten Konfiguration (1), muss aufgrund technischer Rand bedingungen in der Funktion von MACVLAN-Schnittstellen eine zusätzliche MACVLAN-Schnittstelle für den Host eingerichtet und IP-technisch konfiguriert werden, dies entspricht in der Figur 4 dem mittleren Baumsegment, 901.

Mit Schicht / Layer 2-Zugang in Form einer virtuellen Bridge, der oben genannten Konfiguration (2), wird stattdessen die Netzwerkschnittstelle HNIF dem Host IP-Stack, HIP sozusagen entzogen und der virtuellen Bridge „untergeordnet" (in Linux- Terminologie „enslaved"). Die IP-Konfiguration für den Zugang zum jeweiligen Maschinennetzwerk AN muss nun anstatt bei der Netzwerkschnittstelle HNIFa, HNIFb an der virtuellen Bridge erfolgen . Dies entspricht in der Figur 4 dem rechten Baumseg ment, 902.

Ein Translator Manager, XAM, 131 erfasst die für ihn relevan ten Informationen über die physikalischen Netzwerkschnitt stellen HNIFa, HNIFb und die vorliegenden internen virtuellen Netzwerke IVNa, IVNb über einen Network Topology Detector, NTD, 130. Dieser Schritt wird für alle 3 Ausführungsformen durchgeführt, 910.

Diese kann technisch beispielsweise (aber nicht ausschließ lich) in Form des Linux RTNETLINK API

(https://man7.org/linux/man-pages/man7/rtnetlink.7.html), ausgeführt sein, über das die Informationen über die Netz werkschnittstellen und deren (netz-topologischen) Beziehungen abfragbar sind.

Der Translator Manager XAM, 131 ermittelt nun auf Basis der Topologie, ob eine Netzwerkschnittstelle HNIF(a, b) direkt am Host IP-Stack HIP angeschlossen ist; das entspricht der oben beschriebenen Konfiguration (0). In diesem Fall vermerkt er, dass die Netzwerkschnittstelle HNIF(a, b) direkt IP-technisch konfiguriert werden muss, Schritt 920. Dies entspricht dem bereits bekannten, in der Besehreibungseinleitung beschriebe nen Verfahren.

Andernfalls sucht der Translator Manager XAM einen (oder ggf. mehrere) Pfad (e), die von der Netzwerkschnittstelle HNIF(a, b) über virtuelle Bridges oder MACVLAN führen:

Der Translator Manager XAM schlägt in den Topologie- Informationen nach, ob die Netzwerkschnittstelle HNIF(a, b) ein oder mehrere MACVLANs assoziiert hat (Konfiguration (1)): ist ein solches MACVLAN mit dem Host IP-Stack HIP verbunden, wird es in einer Datenbank, 122, als IP-technisch zu konfigu rieren (also IP-Adresse(en) und eventuell IP-Routen und eine DHCP-Client-Identifikation) , und der Netzwerkschnittstelle HNIF bzw. dem Maschinennetzwerk AN logisch zugeordnet mar kiert, Schritt 921.

Der Translator Manager XAM schlägt in den Topologie- Informationen nach, ob die Netzwerkschnittstelle HNIF(a, b) mit einer Bridge assoziiert ist (Konfiguration (2)): wenn ja, prüft der Translator Manager XAM, ob die Bridge mit dem Host IP-Stack HIP assoziiert ist und markiert die Bridge dann in einer Datenbank, 122, als IP-technisch zu konfigurieren und die Netzwerkschnittstelle HNIF bzw. das Maschinennetzwerk AN logisch zugeordnet, Schritt 922.

Der Translator Manager XAM verfolgt die mit der vorgenannten Bridge per Virtuellem Ethernet (VETH) verbundenen weiteren Bridges (unter Beachtung möglicher Zyklen) und wiederholt dort die Prüfung, ob weitere Bridges IP-technisch zu konfigu rieren und der Netzwerkschnittstelle HNIF(a, b) bzw. dem Ma schinennetzwerk AN logisch zugeordnet sind, Schritt 923. Der Translator Manager, XAM, 131 steuert nun den oder die Address-Auto-Configurator , AAC, 150, derart an, dass diese je nach Systemkonfiguration anstatt einer Netzwerkschnittstelle HNIFa, HNIFb nun die logisch zugeordnete Netzwerkschnittstel le, beispielsweise eine Bridge, IVNa, IP-technisch konfigu rieren, Schritt 930.

Über die „ursprüngliche" IP-Konfiguration des Network Address Configurators NAC, 120, gibt beispielsweise ein Anwender 121, oder das Industrial Edge Management System, IEMS, 666, eine (statische) IP-Konfiguration für die Netzwerkschnittstelle HNIF (a, b), lila, 111b für den Betrieb des Industrial Edge- Gerätes IE, 100 in den Automatisierungsnetzen AN, 110a, 110b, vor. Der Translator Manager, XAM übernimmt diese Informatio nen vom Network Address Configurator, NAC und steuert anstatt des Network Address Configurator, NAC nun den Address Auto- Configuration AAC entsprechend.

Alternativ kann der Translator Manager, XAM auch den Network Address Configurator NAC so ansteuern und dessen IP- Konfiguration derart ändern, dass anstatt der Netzwerk schnittstelle HNIF je nach Systemkonfiguration stattdessen die virtuellen Bridges mit den gewünschten statischen IP- Adressen konfiguriert werden oder DHCP (das Dynamic Host Con- figuration Protocol, RFC2131) bei diesen aktiviert wird.

Das vorstehend beschriebene Verfahren befreit den industriel len Anwender in vorteilhafter Weise davon, sich tiefergehen des IT-Wissen über die unterschiedlichen Namen von Netzwerk- Schnittstellen und das Edge-interne virtuelle Netzwerk aneig nen zu müssen.

Bei der Installation und Deinstallation von Schicht / Layer 2-Applikationen installiert oder deinstalliert, die die vir tuelle Netzwerk-Topologie in der Edge verändern. Das beschriebene Verfahren kann mit dem vorgenannten Stand der Technik derart integriert werden, dass die heute für An wender aus der Automatisierungstechnik fehlende Schnittstel- len-Abstraktion den existierenden Werkzeugen nachgerüstet wird. Dieses kann im Fall des „networkmanager" beispielsweise über dessen dbus-Schnittstelle dynamisch zur Laufzeit erfol gen.