[go: up one dir, main page]

DE102019211843A1 - Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung - Google Patents

Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung Download PDF

Info

Publication number
DE102019211843A1
DE102019211843A1 DE102019211843.7A DE102019211843A DE102019211843A1 DE 102019211843 A1 DE102019211843 A1 DE 102019211843A1 DE 102019211843 A DE102019211843 A DE 102019211843A DE 102019211843 A1 DE102019211843 A1 DE 102019211843A1
Authority
DE
Germany
Prior art keywords
node
routing path
call
identifier
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019211843.7A
Other languages
English (en)
Inventor
Slawomir Sander
Christopher Schwarzer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KUKA Deutschland GmbH
Original Assignee
KUKA Deutschland GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KUKA Deutschland GmbH filed Critical KUKA Deutschland GmbH
Priority to DE102019211843.7A priority Critical patent/DE102019211843A1/de
Priority to CN202080070124.0A priority patent/CN114556880B/zh
Priority to EP20749875.9A priority patent/EP4010767A1/de
Priority to PCT/EP2020/071506 priority patent/WO2021023614A1/de
Priority to US17/637,166 priority patent/US11799759B2/en
Publication of DE102019211843A1 publication Critical patent/DE102019211843A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/123Evaluation of link metrics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Einrichten einer Kommunikationsverbindung zwischen einem ersten Knoten (11) in einem ersten von wenigstens zwei Netzwerken und einem zweiten Knoten (31) in einem zweiten der wenigstens zwei Netzwerke, wobei wenigstens einer des ersten und des zweiten Knotens (11, 31) eine automatisierbare industrielle Vorrichtung (z.B. Roboter) oder eine automatisierbare industrielle Anlage oder eine Steuerung hierfür ist. Die wenigstens zwei Netzwerke bilden einzeln jeweils einen homogenen Adressraum. Zusammen bilden die wenigstens zwei Netzwerke aber keinen homogenen Adressraum. Das Verfahren weist die folgenden Schritte auf: Senden (101) eines Calls zum Einrichten der Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten, wobei der Call Routingpfad-Informationen (10/20/30/31) aufweist, die den Routingpfad von dem ersten Knoten (11) zu dem zweiten Knoten (31) angeben, wobei die Routingpfad-Informationen (10/20/30/31) wenigstens einen Identifikator (10, 20, 30, 31) eines jeden der auf dem Routingpfad zu traversierenden Netzwerken oder Knoten, jedoch nicht notwendigerweise einen Identifikator des ersten Netzwerks, aufweisen; und Einrichten (102) der Kommunikationsverbindung zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) basierend auf den Routingpfad-Informationen (10/20/30/31). Die Erfindung betrifft ferner ein(e) entsprechende(s) Steuervorrichtung, Computerprogramm und Computerprogrammprodukt.

Description

  • Die vorliegende Erfindung betrifft die Kommunikation, insbesondere das Einrichten einer Kommunikationsverbindung, mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung.
  • Zu automatisierbaren industriellen Vorrichtungen zählen insbesondere autonome Transportvorrichtungen (fahrerlose Transportfahrzeuge, FTF, Englisch: automated guided vehicles, AGV), automatisierbare Bearbeitungsgeräte oder -stationen, stationäre oder mobile Manipulatoren, stationäre oder mobile Manipulatoranordnungen, insbesondere stationäre oder mobile Roboter oder stationäre oder mobile Roboteranordnungen, oder Steuerungen hierfür, oder Kombinationen aus zwei oder mehr von diesen. Zu automatisierbaren industriellen Anlagen zählen insbesondere Anordnungen, die eine oder mehrere automatisierbare industrielle Vorrichtungen, insbesondere eine der oben genannten Vorrichtungen, aufweisen. Zu einer vorliegend in Betracht kommenden Steuerung zählen Steuerungen, die zur Steuerung der oben genannten Vorrichtungen oder Anlagen dienen. Diese können beispielsweise als Computer, Computeranlage, Steuerungskarte oder integrierter Schaltkreis ausgebildet sein.
  • Es ist bekannt, mit einer automatisierbaren industriellen Vorrichtung oder Anlage oder mit deren Steuerung beispielsweise über eine GRPC-Schnittstelle über das Protobuf-Protokoll zu kommunizieren, insbesondere eine solche Vorrichtung, Anlage oder Steuerung anzusprechen bzw. Daten mit dieser auszutauschen. Um aktuell GRPC-Services über Netzwerkgrenzen hinweg ansprechen zu können, ist zumindest ein VPN-Netzwerk (Virtual Private Network) notwendig. Zudem muss innerhalb des VPN jede Komponente eindeutig adressierbar sein.
  • Aufgabe der vorliegenden Erfindung ist es, die Kommunikation bzw. das Einrichten einer Kommunikationsverbindung mit einer automatisierbaren industriellen Vorrichtung oder Anlage oder deren Steuerung zu verbessern.
  • Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Anspruch 14 stellt eine Steuervorrichtung unter Schutz, die zur Durchführung eines hier beschriebenen Verfahren eingerichtet ist. Ansprüche 15 und 16 stellen ein Computerprogramm bzw. ein Computerprogrammprodukt zur Durchführung eines hier beschriebenen Verfahrens unter Schutz. Die Unteransprüche betreffen vorteilhafte Weiterbildungen.
  • Ein erster Aspekt der vorliegenden Erfindung betrifft ein Verfahren zum Einrichten einer Kommunikationsverbindung zwischen einem ersten Knoten in einem ersten von wenigstens zwei Netzwerken und einem zweiten Knoten in einem zweiten der wenigstens zwei Netzwerke, wobei wenigstens einer des ersten und des zweiten Knotens eine automatisierbare industrielle Vorrichtung oder eine automatisierbare industrielle Anlage oder eine Steuerung hierfür ist,
    wobei die wenigstens zwei Netzwerke einzeln jeweils einen homogenen Adressraum bilden,
    wobei die wenigstens zwei Netzwerke zusammen keinen homogenen Adressraum bilden,
    wobei das Verfahren die folgenden Schritte aufweist:
    • Senden eines Calls zum Einrichten der Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten, wobei der Call Routingpfad-Informationen aufweist, die den Routingpfad von dem ersten Knoten zu dem zweiten Knoten angeben, wobei die Routingpfad-Informationen wenigstens einen Identifikator eines jeden der auf dem Routingpfad zu traversierenden Netzwerken oder Knoten, jedoch nicht notwendigerweise einen Identifikator des ersten Netzwerks, aufweisen; und
    • Einrichten der Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten basierend auf den Routingpfad-Informationen.
  • Unter einer Kommunikationsverbindung wird vorliegend insbesondere eine Verbindung verstanden, die einen Datenaustausch in wenigstens einer Richtung, insbesondere in zwei Richtungen, ermöglicht, beispielsweise zum Zwecke eines Steuerns einer automatisierbaren industriellen Vorrichtung oder Anlage, oder um Messwerte bezüglich dieser zu ermitteln. Hierbei ist zu beachten, dass die Steuerung der Vorrichtung oder Anlage nicht notwendigerweise sofort erfolgen muss, sondern für einen späteren Gebrauch abgespeichert werden kann.
  • Ein Netzwerk mit homogenem Adressraum ist beispielsweise das Internet, ein Cloud-Netzwerk, ein lokales Netzwerk oder ein einzelner Device, wie zum Beispiel ein Computer, Laptop, Smartphone etc. Wenn man jedes dieser Netzwerke für sich alleine betrachtet, ist jeder Knoten (jede Komponente) dieses Netzwerks innerhalb des jeweiligen Netzwerks eindeutig adressierbar, daher der Begriff des homogenen Adressraums. Wenn man diese Netzwerke aber zusammen als Gesamtnetzwerk betrachtet, bilden sie im Allgemeinen keinen homogenen Adressraum, d. h. zwei Knoten können innerhalb ihrer jeweiligen Netzwerke eindeutig durch den gleichen Identifikator (beispielsweise eine Zahl) adressierbar sein, nicht aber innerhalb der Kombination ihrer Netzwerke.
  • Im Prinzip könnte dies dadurch gelöst werden, dass jeder Knoten eine global eindeutige Adresse bekommt, oder dass eine Adressenübersetzung stattfindet. Die Erfinder der vorliegenden Erfindung sehen beides als einschränkend und/oder unflexibel und/oder mit großem Aufwand verbunden an. Das erfindungsgemäße Verfahren stellt einen alternativen Ansatz bereit, der insbesondere flexibler und/oder mit weniger Einschränkungen und/oder Aufwand verbunden ist.
  • Die Routingpfad-Informationen geben mittels entsprechender Identifikatoren an, welche Netzwerke oder Knoten auf dem Routingpfad zu traversieren sind. Anhand dieser Routingpfad-Informationen kann also die Kommunikationsverbindung insbesondere in eindeutiger Weise zwischen dem ersten Knoten und dem zweiten Knoten eingerichtet werden.
  • Es ist vorgesehen, dass ein Call typischerweise von dem ersten Knoten ausgeht, und aus diesem Grund müssen die Routingpfad-Informationen nicht notwendigerweise einen Identifikator des ersten Netzwerks aufweisen, weil dieser sozusagen schon von vornherein bekannt ist. Die Routingpfad-Informationen können aber auch einen Identifikator des ersten Netzwerks aufweisen. Dies kann insbesondere dann vorteilhaft sein, wenn der Call beispielsweise von einer übergeordneten Steuerungsvorrichtung ausgeht, es aber beabsichtigt ist, dass im Rahmen dieses Calls eine Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten eingerichtet wird (also nicht zwischen der übergeordneten Steuervorrichtung und einem der Knoten).
  • Um den Call richtig zu routen bzw. um den Routingpfad korrekt festzulegen, kann es unter Umständen ausreichen, wenn die Routingpfad-Informationen nur die Identifikatoren der zu traversierenden Netzwerke enthalten, ohne alternativ oder zusätzlich Identifikatoren der zu traversierenden Knoten in diesen Netzwerken zu enthalten. Gleichwohl ist es aber möglich, zusätzlich oder alternativ die Identifikatoren der zu traversierenden Knoten in den Routing-Informationen anzugeben, insbesondere dann, wenn der Routingpfad innerhalb eines bestimmten Netzwerks über zwei oder mehr Knoten dieses Netzwerks führt. Dies ist aber selbst in einem solchen Fall nicht zwingend, weil innerhalb eines Netzwerks auch entschieden werden kann, über welche Knoten innerhalb dieses Netzwerks der Call geroutet werden soll, ohne dass dies in den Routingpfad-Informationen des Calls festgelegt sein muss.
  • In einer Ausführung weisen die Routingpfad-Informationen einen Identifikator des zweiten Knotens auf.
  • Dies kann insbesondere dann von Vorteil sein, wenn das Netzwerk, in dem sich der zweite Knoten befindet, mehrere Knoten aufweist. Der Call kann dann zuverlässig zum zweiten Knoten geroutet werden. Falls das zweite Netzwerk nur einen Knoten aufweist, nämlich den zweiten Knoten, ist der zweite Knoten in gewisser Weise identisch mit dem zweiten Netzwerk, so dass die Angabe eines Identifikators des zweiten Knotens zusätzlich zu einem Identifikator des zweiten Netzwerks nicht nötig ist. Ebenso kann die Angabe des Identifikators des zweiten Knotens in den Routingpfad-Informationen nicht nötig sein, wenn von vornherein klar ist, beispielsweise aufgrund der Natur des Calls, zu welchem Knoten innerhalb des zweiten Netzwerks dieser geroutet werden soll.
  • Nach einer Ausführung weist der Call ferner einen Verbindungs-Identifikator auf. Ein solcher Verbindungs-Identifikator kann zur Identifizierung der Kommunikationsverbindung dienen, insbesondere um eine bestimmte Kommunikationsverbindung von einer anderen Kommunikationsverbindung zu unterscheiden. Der Verbindungsidentifikator kann in noch zu beschreibender Weise zugeteilt werden.
  • Nach einer Ausführung weist die Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten wenigstens zwei Nachrichten auf, wobei alle Nachrichten dieser Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten diesen Verbindungs-Identifikator aufweisen.
  • Durch die Benutzung des gleichen Verbindungsidentifikators für mehrere Nachrichten, die zu einer bestimmten Kommunikationsverbindung gehören, kann deren Zugehörigkeit zu dieser bestimmten Kommunikationsverbindung leicht erkannt werden, beispielsweise durch auf dem Routingpfad liegende Knoten. Auch können die zwei oder mehr Nachrichten auf diese Weise effizient gruppiert werden. Außerdem hat die Benutzung eines Verbindungsidentifikators noch zu beschreibende Vorteile für das Routing dieser Nachrichten.
  • Nach einer Ausführung wird zumindest ein Teil des Verbindungsidentifikators zufällig generiert oder zugeteilt, insbesondere durch den ersten Knoten. Der zufällig generierte oder zugeteilte Teil des Verbindungsidentifikators kann beispielsweise eine Zahl, ein Buchstabe, eine Zahlen/Buchstaben-Kombination oder ähnliches aufweisen. Nach dieser Ausführung kann ein relativ unkompliziertes Generieren oder Zuteilen des Verbindungsidentifikators stattfinden. Ein anderer Teil des Verbindungsidentifikators kann in anderer Weise generiert oder zugeteilt werden. Beispielsweise könnte dieser Teil basierend auf einer aktuellen Zeit oder einer Identifikation eines Knotens, beispielsweise des ersten Knotens, generiert oder zugeteilt werden. Gleichwohl kann aber auch der gesamte Verbindungsidentifikator zufällig generiert oder zugeteilt werden, also keinen Teil aufweisen, der nicht zufällig generiert oder zugeteilt wurde.
  • Die Erfinder gehen davon aus, dass es -je nach Implementierung - relativ unwahrscheinlich ist, dass es in dem Gesamtnetzwerk gleichzeitig zwei eingerichtete oder einzurichtende Kommunikationsverbindungen gibt, die den gleichen Verbindungsidentifikator aufweisen. Insofern ist zu erwarten, dass es relativ unwahrscheinlich ist, dass es eine „Kollision“ durch zwei Kommunikationsverbindungen mit gleichem Verbindungsidentifikator gibt. Selbst dies wäre unter Umständen kein Problem, wenn die entsprechenden Routingpfade nicht die gleichen Netzwerke und/oder Knoten traversieren.
  • Unter Umständen ist erst dann eine Kollision zu erwarten, wenn die Routingpfade für identische Verbindungsidentifikatoren durch die gleichen Netzwerke bzw. über die gleichen Knoten führen. Entsprechend ist in einer Ausführung vorgesehen, dass im Falle, dass die Verbindungs-Identifikatoren eines ersten und eines zweiten Calls übereinstimmen und insbesondere im Falle, dass die Routingpfade des ersten und zweiten Calls über den gleichen Knoten führen, der zweite Call abgelehnt wird und/oder ein neuer Verbindungs-Identifikator für den zweiten Call generiert oder diesem zugeteilt wird.
  • Gemäß dieser Ausführung kann auf relativ unkomplizierte Weise eine Kollision vermieden werden bzw. eine bereits eingetretene Kollision „aufgelöst“ werden. Nach der Kollisionsvermeidung bzw. -auflösung kann erneut auf die Gefahr einer (weiteren) Kollision geprüft werden. Dieser Vorgang kann sich wiederholen, bis das kollisionsfreie Einrichten der Kommunikationsverbindungen möglich ist.
  • Nach einer Ausführung wird für einen oder den ersten Call in jedem auf dem Routingpfad zwischen dem ersten Knoten und dem zweiten Knoten liegenden Knoten oder einer zugehörigen Speichervorrichtung der zugehörige Verbindungs-Identifikator und ein Knoten-Identifikator eines Vorgängerknotens und ein Knoten-Identifikator eines Nachfolgerknotens gespeichert,
    wobei der Vorgängerknoten ein auf dem Routingpfad liegender Knoten, insbesondere ein auf dem Routingpfad unmittelbar benachbart liegender Knoten, in Richtung des ersten Knotens ist, und
    wobei der Nachfolgerknoten ein auf dem Routingpfad liegender Knoten, insbesondere ein auf dem Routingpfad unmittelbar benachbart liegender Knoten, in Richtung des zweiten Knotens ist.
  • Gemäß dieser Ausführung wird in gewisser Weise in jedem Knoten auf dem Routingpfad ein für diesen Knoten relevanter Teil des Routingpfads hinterlegt, beispielsweise in einer Routing-Tabelle. Insbesondere wenn nur die Knotenidentifikatoren der Nachbarknoten hinterlegt werden, ist der Speicherbedarf für diese Hinterlegung relativ gering. Das Hinterlegen von nicht benachbarten Knotenidentifikatoren ist im Prinzip nicht nötig, gleichwohl aber möglich.
  • Nach einer Ausführung sind die Routingpfad-Informationen und der dazugehörige Verbindungs-Identifikator eines Calls in einer Startnachricht enthalten.
  • Gemäß dieser Ausführung entsteht eine Zuordnung zwischen den Routingpfad-Informationen und dem Verbindungsidentifikator. Durch die Startnachricht können diese an die entsprechenden Knoten übermittelt werden.
  • Nach einer Ausführung weisen auf die Startnachricht folgende Nachrichten dieses Calls den dazugehörigen Verbindungs-Identifikator, nicht aber die Routingpfad-Informationen auf,
    wobei die auf die Startnachricht folgenden Nachrichten vorzugsweise anhand der in den auf dem Routingpfad zwischen dem ersten Knoten und dem zweiten Knoten liegenden Knoten oder der zugehörigen Speichervorrichtung gespeicherten Knoten-Identifikatoren geroutet werden.
  • Weil den auf dem Routingpfad liegenden Knoten die Routingpfad-Informationen bereits in der Startnachricht mitgeteilt wurden (und die Knoten den für sie relevanten Teil, zum Beispiel die Knotenidentifikatoren der Nachbarknoten, wie oben erläutert, abspeichern können, beispielsweise in einer Routing-Tabelle), ist es nicht notwendig, dass auf die Startnachricht folgende Nachrichten auch die Routingpfad-Informationen enthalten. Beim Empfangen einer (nachfolgenden) Nachricht an einem Knoten würde dieser anhand des Verbindungsidentifikators den hinterlegten Knotenidentifikator des Nachbarknotens ermitteln und die Nachricht an diesen weiterleiten.
  • Nach einer Ausführung werden beim Beenden des Calls in den auf dem Routingpfad zwischen dem ersten Knoten und dem zweiten Knoten liegenden Knoten oder der zugehörigen Speichervorrichtung der gespeicherte zugehörige Verbindungs-Identifikator und/oder der gespeicherte Knoten-Identifikator des Vorgängerknotens und/oder der gespeicherte Knoten-Identifikator des Nachfolgerknotens deaktiviert, insbesondere gelöscht.
  • Durch dieses Deaktivieren bzw. Löschen kann Speicherbedarf minimiert werden. Außerdem kann hierdurch sichergestellt werden, dass nicht mehr benötigte Informationen nicht mehr zugänglich sind, was einem verbesserten Datenschutz dienen kann.
  • Nach einer Ausführung ist die Kommunikationsverbindung eine bidirektionale Kommunikationsverbindung.
  • In diesem Zusammenhang wird unter einer bidirektionalen Kommunikationsverbindung insbesondere verstanden, dass Daten in beide Richtungen übermittelt werden können, insbesondere übermittelt werden. Sieht man beispielsweise den Weg vom ersten Knoten zum zweiten Knoten als Hinweg an, so stellt der Weg vom zweiten Knoten zum ersten Knoten den Rückweg dar. In einem Anwendungsbeispiel könnte beispielsweise der erste Knoten eine zentrale Roboterüberwachungsvorrichtung sein und der zweite Knoten ein Roboter. Auf dem Hinweg sendet der erste Knoten beispielsweise eine Anfrage an den zweiten Knoten, um Sensordaten bezüglich dieses zweiten Knotens (Roboter) zu erhalten. Der zweite Knoten ermittelt die Sensordaten und sendet diese auf dem Rückweg zurück an den ersten Knoten.
  • Wenn, wie oben ausgeführt, alle Knoten auf dem Routingpfad eine Zuordnung zwischen einem Verbindungsidentifikator und den Knotenidentifikatoren beider benachbarten Knoten hinterlegt haben, können die Nachrichten bidirektional, also sowohl für den Hinweg als auch für den Rückweg, aufgrund des Verbindungsidentifikators geroutet werden. Auch für eine bidirektionale Kommunikationsverbindung ist es also nicht nötig, dass auf eine Startnachricht folgende Nachrichten Routing-Informationen bezüglich des Routingpfads enthalten, obwohl dies alternativ auch möglich wäre.
  • Nach einer Ausführung weist das Verfahren ferner auf: vor dem Senden des Calls, Senden eines Initial-Calls durch den ersten Knoten, wobei der Initial-Call keine oder nur unvollständige Routingpfad-Informationen aufweist, wobei anhand des Initial-Calls die für den Call benötigten Routingpfad-Informationen ermittelt werden können, insbesondere durch einen von dem ersten Knoten verschiedenen Knoten, insbesondere mithilfe einer Zuordnung zwischen einer in dem Initial-Call enthaltenen Information und den Routingpfad-Informationen.
  • Gemäß dieser Ausführung muss der erste Knoten nicht unbedingt die (vollständigen) Routingpfad-Informationen kennen, die für das Einrichten der Kommunikationsverbindung zwischen dem ersten und dem zweiten Knoten nötig sind. Dennoch kann nach dieser Ausführung die Kommunikationsverbindung eingerichtet werden.
  • Der Initial-Call könnte beispielsweise lediglich eine Art von Dienst (Service) identifizieren, den der erste Knoten durch einen anderen Knoten erbringen lassen soll, wobei dem ersten Knoten nicht unbedingt bekannt ist, welcher andere Knoten diesen Dienst erbringen kann bzw. für das Erbringen dieses Dienstes vorgesehen ist. Anhand des Initial-Calls bzw. der darin enthaltenen Informationen kann aber ermittelt werden, beispielsweise durch einen von dem ersten Knoten verschiedenen Knoten, welcher Knoten den angeforderten Dienst erbringen kann bzw. soll.
  • Diese Ausführung ermöglicht auch eine flexiblere Handhabung bezüglich einer Verteilung von Diensten, insbesondere eine dynamische Verteilung von Diensten, also eine Verteilung von Diensten, die sich im Laufe der Zeit ändern kann, und insbesondere bei der solche Änderungen ohne größeren Aufwand implementiert werden können. So kann beispielsweise eine „Dienstzuordnung“, also eine Zuordnung, welcher Knoten welchen Dienst ausführen kann bzw. soll, in nur einem Knoten (einem dritten Knoten) hinterlegt sein. Wenn sich die Dienstzuordnung ändert oder ändern soll, muss die Dienstzuordnung nur in dem dritten Knoten aktualisiert werden, nicht aber in jedem anderen Knoten, der unter Umständen auf den entsprechenden Dienst zugreifen möchte. So kann ein „Umzug“ von Diensten von einem Knoten zu einem anderen Knoten vorteilhaft implementiert werden, wobei der Aktualisierungsaufwand gering gehalten werden kann.
  • Diese Ausführung ermöglicht auch einen gewissen Grad an Anonymität, d. h. der erste Knoten, der auf einen bestimmten Dienst zugreifen möchte, muss im Rahmen dieser Ausführung nicht erfahren (bzw. erfährt nicht), welcher Knoten den angeforderten Dienst ausführen kann/soll bzw. ausführt.
  • Nach einer Ausführung weist das Verfahren ferner das Zurückweisen eines Calls, insbesondere an einem oder durch einen auf dem Routingpfad zwischen dem ersten Knoten und dem zweiten Knoten liegenden Knoten, insbesondere im Falle, dass der Call oder die Kommunikationsverbindung nicht autorisiert ist, auf.
  • Gemäß dieser Ausführung kann ein Call zurückgewiesen werden, beispielsweise weil der „Zielknoten“ (der zweite Knoten) für einen angeforderten Dienst nicht zur Verfügung steht, beispielsweise weil er die angeforderte Art von Dienst nicht mehr ausführt oder weil er keine freie Kapazität zum Ausführen dieses Dienstes hat. Ebenso kann ein Call zurückgewiesen werden, falls für diesen Call bzw. die Kommunikationsverbindung keine Autorisierung vorliegt. Dies könnte beispielsweise dafür benutzt werden, um firmeninterne Zugangsberechtigungen zu implementieren oder um ausgewählte Dienste Knoten nur dann zur Verfügung zu stellen, nachdem hierfür eine entsprechende Gebühr bezahlt wurde. Eine entsprechende Überprüfung kann durch einen Knoten auf dem Routingpfad durchgeführt werden, beispielsweise durch den zweiten Knoten selbst, oder sogar auch durch den ersten Knoten. Vorteilhafterweise findet die Überprüfung bzw. das Zurückweisen aber an einem zwischen dem ersten und dem zweiten Knoten liegenden Knoten statt, beispielsweise bei einem Knoten innerhalb eines Firmen-Intranets. Dieser könnte zentral für das Überprüfen und Zurückweisen zuständig sein, insbesondere in Bezug auf mehrere zweite Knoten.
  • Nach einer Ausführung ist wenigstens einer des ersten und des zweiten Knotens eine autonome Transportvorrichtung, ein stationärer oder mobiler Manipulator, eine stationäre oder mobile Manipulatoranordnung, insbesondere ein stationärer oder mobiler Roboter oder eine stationäre oder mobile Roboteranordnung, oder eine Steuerung hierfür, oder eine Kombination aus zwei oder mehr von diesen.
  • Zu autonomen Transportvorrichtungen im Rahmen von automatisierbaren industriellen Vorrichtungen oder automatisierbaren industriellen Anlagen zählen insbesondere Transportfahrzeuge, die autonom, beispielsweise innerhalb eines Gebäudes, wie zum Beispiel einer Lagerhalle, oder auch zwischen mehreren Gebäuden/Lagerhallen oder auf einem Werksgelände, Gegenstände transportieren können. Diese könnten in einem einfachen Fall eine Ladeplattform oder einen Behälter/Container aufweisen, um die Gegenstände von einem Ort zu einem anderen Ort zu transportieren, ohne selbst das Be- und/oder Entladen vorzunehmen. Solche Transportfahrzeuge können aber auch mit geeigneten Mitteln zum Be- und/oder Entladen ausgestattet sein, beispielsweise einer Hebeeinrichtung wie bei einem Gabelstapler, einem Greifarm usw.
  • Zu den in Betracht kommenden Manipulatoren, Manipulator-Anordnungen, Roboter-oder Roboter-Anordnungen zählen insbesondere Vorrichtungen, die ein Werkstück bearbeiten oder deren Lage oder Position verändern.
  • Ein zweiter Aspekt der Erfindung betrifft eine Steuervorrichtung für einen Knoten, insbesondere für einen Manipulator, insbesondere für einen Roboter, wobei die Steuervorrichtung zur Durchführung eines der oben beschriebenen Verfahren eingerichtet ist.
  • Ein dritter Aspekt der Erfindung betrifft ein Computerprogramm, das eines der oben beschriebenen Verfahren ausführt, wenn es in einer Steuervorrichtung wie oben beschrieben abläuft.
  • Ein vierter Aspekt der Erfindung betrifft ein Computerprogrammprodukt mit Programmcode, der auf einem maschinenlesbaren Träger gespeichert ist und ein Computerprogramm wie oben beschrieben umfasst.
  • Ein Computerprogrammprodukt kann in einer Ausführung ein, insbesondere nichtflüchtiges, Speichermedium zum Speichern eines Programms bzw. mit einem darauf gespeicherten Programm aufweisen, insbesondere sein, wobei ein Ausführen dieses Programms ein System bzw. eine Steuerung, insbesondere einen Computer, dazu veranlasst, ein hier beschriebenes Verfahren bzw. einen oder mehrere seiner Schritte auszuführen.
  • Weitere Vorteile und Merkmale ergeben sich aus den Unteransprüchen und den Ausführungsbeispielen. Hierzu zeigt, teilweise schematisiert:
    • 1: ein System bzw. eine Netzwerkstruktur nach einem Ausführungsbeispiel der vorliegenden Erfindung;
    • 2: ein System bzw. eine Netzwerkstruktur nach einem weiteren Ausführungsbeispiel der vorliegenden Erfindung; und
    • 3: ein Ablaufdiagramm mit Verfahrensschritten eines erfindungsgemäßen Verfahrens.
  • 1 zeigt ein System bzw. eine Netzwerkstruktur nach einem Ausführungsbeispiel der vorliegenden Erfindung. In 1 sind mehrere Netzwerke jeweils durch gestrichelte Rechtecke dargestellt. Jedes dieser Netzwerke bildet einzeln betrachtet jeweils einen homogenen Adressraum, innerhalb dessen einzelne Knoten, die in 1 durch Rechtecke mit durchgezogenen Linien dargestellt sind, eindeutig adressierbar sind, d. h. eine eindeutige Netzwerkadresse haben. Innerhalb jedes Netzwerkes muss es also eine Absprache der Teilnehmer oder Knoten über die Adressvergabe geben.
  • Die in 1 dargestellten Knoten können im Prinzip miteinander kommunizieren bzw. Daten austauschen. Diese Kommunikation kann beispielsweise drahtgebunden (z. B. Ethernet) oder drahtlos (z. B. Mobilfunk, WLAN) stattfinden. Allerdings kann gemäß 1 nicht jeder dargestellte Knoten mit jedem anderen dargestellten Knoten direkt kommunizieren. In dem Ausführungsbeispiel der 1 sind sämtliche möglichen Direktverbindungen durch durchgezogene Linien dargestellt.
  • Wie bereits erwähnt, findet die vorliegende Erfindung im Zusammenhang mit der Kommunikation zwischen zwei Knoten Anwendung, wobei wenigstens einer dieser Knoten eine automatisierbare industrielle Vorrichtung, Anlage oder Steuerung hierfür ist. Beispiele für diese wurden bereits erwähnt. Im Interesse einer übersichtlichen Beschreibung wird nun im Zusammenhang mit dem Ausführungsbeispiel der 1 angenommen, dass einer der Knoten ein Roboter ist, ohne dass dies als Einschränkung gelten soll. Als konkretes Beispiel kann das in 1 dargestellte Netzwerk K-I das Intranet einer Roboter-Herstellerfirma sein. Das Netzwerk CL-C stellt ein Cloud-Netzwerk dar, das Netzwerk CL-S ein weiteres Cloud-Netzwerk, das Netzwerk C-D ein Kundennetzwerk und das Netzwerk C-T ein weiteres Kundennetzwerk.
  • Der Knoten K im Netzwerk K-I stellt eine Schnittstelle mit Zugang zum Cloud-Netzwerk CL-C dar. Entsprechendes gilt für die Knoten D und T. Die beiden Cloud-Netzwerke sind über die jeweiligen Schnittstellen S und C miteinander verbunden, wobei die Schnittstelle C auch mit den Schnittstellen K, D und T kommunizieren kann. Die übrigen Knoten in den Netzwerken K-I, C-D und C-T können nicht direkt mit der Schnittstelle C kommunizieren, sondern nur über die jeweiligen Schnittstellen K, D und T in ihren jeweiligen Netzwerken.
  • Wir nehmen nun im Sinne eines Beispiels an, dass der Knoten 1 innerhalb des Netzwerks C-T ein Roboter ist. Außerdem nehmen wir an, dass der Knoten 1 in dem Netzwerk K-I einen bestimmten Dienst bereitstellen kann, beispielsweise die Diagnose eines Problems, das bei einem (Kunden-)Roboter auftreten kann, beispielsweise bei dem Roboter 1 im Kundennetzwerk C-T. Ferner nehmen wir an, dass der Knoten 1 im Netzwerk K-I tatsächlich eine Diagnose des Roboters 1 im Kundennetzwerk C-T durchführen soll, beispielsweise im Rahmen einer in festgelegten Zeitabständen wiederkehrenden Überprüfung oder aufgrund einer expliziten Aufforderung hierzu.
  • Um eine Diagnose durchzuführen, muss der Knoten 1 im Netzwerk K-I nun beispielsweise Sensordaten des Roboters 1 im Netzwerk C-T abfragen, d. h. diese müssen angefordert werden und anschließend übermittelt werden. Würde die Adressierung in dem in 1 gezeigten Gesamtnetzwerk 50 nach herkömmlichen Adressierungsmethoden erfolgen, so müssten sämtliche in 1 gezeigte Knoten eindeutig global adressierbar sein. Im gezeigten Beispiel ist dies aber problematisch, weil es nicht nur im Netzwerk C-T, sondern auch beispielsweise in den Netzwerken CD und CL-C einen Knoten mit dem Identifikator „1“ gibt. Nach herkömmlichen Adressierungsmethoden müssten also diesen Knoten zunächst eindeutige Adressen zugewiesen werden.
  • Im Gegensatz dazu ist erfindungsgemäß eine solche eindeutige globale Adressierung nicht nötig. Nach dem vorgestellten erfindungsgemäßen Ausführungsbeispiel dürfen mehrere Teilnetzwerke einen Knoten mit dem gleichen Identifikator, hier beispielsweise „1“, aufweisen und beibehalten. Damit nun der Knoten 1 im Netzwerk K-I Sensordaten des Roboters 1 im Netzwerk C-T abfragen kann, sendet der Knoten 1 im Netzwerk K-I - dieser Knoten wird hier als „erster Knoten“ bezeichnet - einen Call zum Einrichten einer Kommunikationsverbindung zwischen dem ersten Knoten (also sich selbst) und dem Roboter 1 im Netzwerk C-T - hier als „zweiter Knoten“ bezeichnet. Dieser Call enthält Routingpfad-Informationen, die den Routingpfad von dem ersten Knoten zu dem zweiten Knoten angeben. Der Routingpfad führt in diesem Fall über den Knoten K zu dem Knoten C, von dort zu dem Knoten T und dann zu dem zweiten Knoten mit dem Identifikator „1“. Die Routingpfad-Informationen könnten also beispielsweise Identifikatoren dieser zu traversierenden Knoten aufweisen. Allerdings ist die Angabe des Identifikators K nicht nötig, weil aufgrund der anderen angegebenen Identifikatoren, wie zum Beispiel C, es ohnehin klar ist, dass der Routingpfad aus dem Netzwerk K-I herausführt und weil in dem in 1 gezeigten Beispiel die einzige Verbindung, die aus dem Netzwerk K-I herausführt, über den Knoten K führt. Im vorliegenden Beispiel wäre also die Angabe der Identifikatoren C, T und 1 ausreichend, um den Routingpfad von dem ersten Knoten zu dem zweiten Knoten eindeutig anzugeben. In 1 ist dies durch die strichpunktierte Linie mit der Bezeichnung „C/T/1“ dargestellt.
  • Anstelle eines Indikators der zu traversierenden Knoten könnten die Routinginformationen auch Identifikatoren der zu traversierenden Netzwerke aufweisen, im vorliegenden Beispiel die Netzwerke CL-C und C-T, oder eine Mischung aus Identifikatoren der zu traversierenden Netzwerke und Knoten. In diesem Sinne wäre in dem zuletzt genannten Beispiel auch die Angabe des Identifikators „1“ für den zweiten Knoten notwendig, damit der Routingpfad bis zum zweiten Knoten eindeutig angegeben wird.
  • In einer Variante wäre die Angabe des Identifikators dieses zweiten Knotens nicht notwendig, falls beispielsweise in dem Netzwerk C-T standardmäßig immer alle Calls zu dem Roboter mit dem Identifikator 1 geroutet werden.
  • Basierend auf den Routingpfad-Informationen kann dann die Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten eingerichtet werden. Als Payload kann also beispielsweise eine Aufforderung von dem ersten Knoten entlang des Routingpfads zum zweiten Knoten gesendet werden, damit der zweite Knoten Sensordaten an den ersten Knoten übermittelt.
  • 1 deutet durch strichpunktierte Linien weitere Beispiele von Kommunikationsverbindungen an. Diese werden im Folgenden kurz erklärt.
  • Ganz links in 1 sind vier einzelne Knoten 1, 2, 3 und 4 gezeigt, die eigenständige Netzwerke bilden, d. h. deren Netzwerke enthalten nur einen einzigen Knoten. Diese sind an das Cloud-Netzwerk CL-S angebunden, d. h. sie können (nur) mit diesem direkt kommunizieren.
  • Der Routingpfad von dem Knoten 4 zum Knoten S führt direkt von dem Knoten 4 zu dem Knoten S, ohne dass dieser Routingpfad weitere Knoten traversiert. Entsprechend würde es ausreichen, wenn die Routingpfad-Informationen zur Angabe dieses Routingpfads lediglich den Identifikator „S“ enthalten, wie in 1 gezeigt. Links oben in 1 ist eine weitere Kommunikationsverbindung angedeutet, die von einem Knoten mit dem Identifikator „1“ über die Knoten S und C zu einem weiteren Knoten mit dem Identifikator „1“ im Netzwerk CL-C führt. Zur (eindeutigen) Angabe des entsprechenden Routingpfads wäre also die Angabe der Identifikatoren S, C und 1 ausreichend, wie in 1 durch den String „S/C/1“ angedeutet ist. In diesem Beispiel ist die Angabe des Identifikators S vorgesehen, obwohl von dem Knoten 1 links oben in 1 die einzige direkte Verbindung zu dem Knoten S führt. Grund hierfür ist die Tatsache, dass diese Verbindung Netzwerkgrenzen überschreitet.
  • Dagegen ist in einem weiteren in 1 gezeigten Beispiel eines Routingpfads die Angabe der Identifikatoren C und 1 ausreichend, um von dem Knoten mit dem Identifikator „4“ im Kundennetzwerk C-T über den Knoten T zum Knoten C und weiter zum Knoten 1 im Cloud-Netzwerk CL-C zu gelangen. Die Angabe des Identifikators T ist nicht nötig, weil die einzige Verbindung aus dem Kundennetzwerk C-T über den Knoten T führt.
  • Weitere in 1 gezeigte Beispiele von Routingpfaden betreffen das Kundennetzwerk C-D. Innerhalb dieses Netzwerkes C-D befindet sich ein weiteres Kundennetzwerk C-F. Dieses enthält die Knoten F, 1, 2, 3 und 4. Die einzige Verbindung aus dem Kundennetzwerk C-F führt über den Knoten F und von dort über einen nicht durch einen Identifikator gekennzeichneten Knoten zum Knoten D. Das Netzwerk C-F könnte beispielsweise ein Netzwerk innerhalb des Kundennetzwerks C-D sein, wobei alle Mitarbeiter des Unternehmens, dem diese Netzwerke zugeordnet sind, Zugang zu dem Bereich des Netzwerks C-D außerhalb des Netzwerks C-F haben, aber nur manche Mitarbeiter auch Zugang zum Netzwerk C-F haben.
  • Ein Routingpfad vom Knoten 4 zum Knoten 3 im Netzwerk C-F ist ausreichend definiert, indem lediglich der Identifikator „3“ in den entsprechenden Routingpfad-Informationen angegeben wird, wie rechts unten in 1 angedeutet.
  • Der Routingpfad vom Knoten 1 innerhalb des Netzwerks C-F zum Knoten C im Cloud-Netzwerk CL-C führt notwendigerweise über den Knoten F aus dem Netzwerk C-F heraus, von dort über den Knoten D, um das Netzwerk C-D zu verlassen, und von dort zum Knoten C im Cloud-Netzwerk CL-C. Dieser Pfad ist durch die Angabe lediglich des Identifikators „C“ ausreichend definiert, weil es von vornherein klar ist, dass alle Pfade zum Verlassen des Netzwerks C-F und C-D über die Knoten F und D führen müssen. Die Angabe der Identifikatoren F und D ist somit in den entsprechenden Routingpfad-Informationen nicht nötig.
  • Schließlich ist ein letztes Routingpfad-Beispiel in 1 angedeutet, das in gewisser Weise als Umkehrung des unmittelbar vorangegangenen Beispiels angesehen werden kann. Hier soll der Routingpfad von dem Knoten C im Cloud-Netzwerk CL-C über den Knoten D im Kundennetzwerk C-D und den Knoten F im Kundennetzwerk C-F zum Knoten 2 im Netzwerk C-F führen. Anders als im vorangegangenen Beispiel ist nun die Angabe der Identifikatoren D, F und 2 nötig, um den Routingpfad eindeutig zu definieren, beispielsweise durch den String „D/F/2“, wie in 1 angedeutet. Die Angabe lediglich des Identifikators „2“ wäre in diesem Fall nicht für eine eindeutige Identifizierung des Routingpfads ausreichend, weil es ohne die Angabe des Identifikators D, ausgehend vom Knoten C, nicht von vornherein klar ist, dass der Routingpfad ins Netzwerk C-D führen soll.
  • 2 zeigt ein weiteres Beispiel eines Netzwerksystems bzw. Gesamtnetzwerks 50. Das Gesamtnetzwerk 50 weist vier (eigenständige) Teilnetzwerke auf. Diese sind im Interesse einer vereinfachten Darstellung nicht separat eingezeichnet. Ein erstes Netzwerk weist die Knoten 10 bis 13 auf, ein zweites Netzwerk die Knoten 20 und 21, ein drittes Netzwerk die Knoten 30 bis 32 und ein viertes Netzwerk die Knoten 40 und 41.
  • Jedes dieser vier Netzwerke stellt einen homogenen Adressraum dar, damit jeder Knoten innerhalb eines jeden dieser vier Netzwerke eindeutig adressierbar ist. Obwohl alle in 2 gezeigten Knoten auch insgesamt betrachtet unterschiedliche Bezugszeichen zwischen 10 und 41 tragen, bedeutet dies nicht, dass auch das Gesamtnetz 50 einen homogenen Adressraum bildet. Die Bezugszeichen zwischen 10 und 41 sind in 2 also nicht notwendigerweise als Identifikatoren der einzelnen Knoten anzusehen, sondern wurden nur im Interesse einer übersichtlicheren Beschreibung so vergeben, dass zwei Knoten nicht das gleiche Bezugszeichen tragen. Anders verhält es sich mit den Identifikatoren der Knoten, die in 2 nicht dargestellt sind, die den einzelnen Knoten aber analog zu 1 zugewiesen sein können. Es können also auch in 2 zwei verschiedene Knoten in zwei verschiedenen Netzwerken den gleichen Identifikator tragen. Beispielsweise könnten die Knoten 11 und 31 den Identifikator „1“ tragen, die Knoten 12 und 32 den Identifikator „2“ usw. Dennoch werden in der folgenden Beschreibung - wiederum im Interesse der besseren Übersichtlichkeit - die Bezugszeichen der Knoten so behandelt, als wären sie gleichzeitig die Identifikatoren der Knoten.
  • Analog zu 1 sind die direkten Verbindungen (also die, die nicht über weitere Knoten führen müssen) durch durchgezogene Linien bzw. Doppelpfeile dargestellt. Eine direkte Kommunikation ist also zwischen dem Knoten 11 und dem Knoten 10 möglich. Hingegen muss eine Kommunikationsverbindung zwischen dem Knoten 11 und dem Knoten 20 zwangsläufig über den Knoten 10 führen.
  • Es wird nun das Einrichten einer Kommunikationsverbindung anhand eines erfindungsgemäßen Beispiels näher erläutert. Wir nehmen nun an, dass von Knoten 11 ein Call gesendet wird, um eine Kommunikationsverbindung zwischen diesem Knoten 11, der somit als „erster Knoten“ anzusehen ist, und dem Knoten 31, der als „zweiter Knoten“ anzusehen ist, einzurichten. Diese Kommunikationsverbindung führt vom Knoten 11 über die Knoten 10, 20 und 30 zum Knoten 31. Der entsprechende Routingpfad P ist durch einen Pfeil mit gestrichelter Linie veranschaulicht.
  • In einem ersten Schritt sendet der erste Knoten 11 einen Call zum Einrichten der Kommunikationsverbindung mit dem zweiten Knoten 31, beispielsweise um Sensordaten von Knoten 31 zu erfragen. Dieser Call enthält, wie anhand der 1 beschrieben, die nötigen Routingpfad-Informationen, also die Identifikatoren zumindest der Knoten 20 und 30, unter Umständen auch die Identifikatoren des Knotens 10 und/oder des Knotens 31. Im weiteren Verlauf nehmen wir an, dass die Routingpfad-Informationen die (Knoten)-Identifikatoren aller auf dem Routingpfad P liegenden Knoten aufweist, also die Identifikatoren der Knoten 10, 20, 30 und 31, beispielsweise in der Form eines Strings „10/20/30/31“.
  • Basierend auf den in dem Call enthaltenen Routinginformationen leitet der Knoten 10 den Call weiter zum Knoten 20, dieser zum Knoten 30 und dieser schließlich zum zweiten Knoten 31. Somit wurde der Call bis zum zweiten Knoten 31 geroutet, d. h. eine Kommunikationsverbindung zwischen dem ersten Knoten 11 und dem zweiten Knoten 31 eingerichtet.
  • Während zuvor ein besonders einfaches Beispiel eines Einrichtens einer Kommunikationsverbindung zwischen einem ersten und einem zweiten Knoten beschrieben wurde, sind hierzu viele Ausgestaltungsmöglichkeiten und Varianten möglich. Diese werden im Folgenden beschrieben.
  • Variante 1
  • Nachdem der Call wie zuvor beschrieben bis zum Knoten 31 geroutet wurde, kann dieser anhand der Routinginformation erkennen (beispielsweise weil sein Knotenidentifikator der letzte in den Routinginformationen enthaltene Identifikator ist), dass der Call für ihn als Zielknoten bestimmt ist. Der zweite Knoten 31 kann sodann Instruktionen, die in Form einer Payload in dem Call enthalten sein können, ausführen. Enthält der Call beispielsweise die Anweisung, Sensordaten zu erheben und an den ersten Knoten 11 zurückzusenden, kann der zweite Knoten 31 diese Daten erheben und anschließend eine entsprechende Nachricht, die wiederum die Routinginformationen enthält (allerdings in umgekehrter Reihenfolge), auf dem Rückweg des Routingpfades P zurücksenden. Diese Nachricht kann analog zum Call auf dem Hinweg durch die Knoten 30, 20 und 10 weitergegeben werden. Je nach Ausführung ist die Angabe des Knotenidentifikators des ursprünglich ersten Knotens 11 in den Routinginformationen nicht nötig, beispielsweise weil der Knoten 11 der einzige (weitere) Knoten in dem Netzwerk ist, in dem sich der Knoten 10 befindet.
  • Gemäß dem bisher anhand von 2 beschriebenen Ausführungsbeispiel und dessen Weiterentwicklung müsste jede der gesendeten Nachrichten die (kompletten) Routinginformationen für den Routingpfad P enthalten.
  • Variante 2
  • In einer weiteren erfindungsgemäßen Ausgestaltung kann letzteres vermieden werden, um Speicherplatz in den Routingknoten bzw. in mit diesen verbundenen Speichern einzusparen und/oder um das Routen der Nachrichten effizienter zu gestalten. Zu diesem Zweck kann der erste Knoten 11 zunächst eine Startnachricht senden. Diese enthält zusätzlich zu den Routinginformationen, also den Identifikatoren der auf dem Routingpfad P liegenden Knoten, einen Verbindungsidentifikator. Dieser identifiziert die einzurichtende Verbindung, beispielsweise um diese von anderen eingerichteten oder einzurichtenden Kommunikationsverbindungen zu unterscheiden.
  • Die Startnachricht wird nach ihrem Eintreffen beim Knoten 10 verarbeitet. Hierzu werden in einem entsprechenden Speicher unter dem Verbindungsidentifikator die Routingpfad-Informationen gespeichert, beispielsweise in einer Art Routingtabelle. Die Startnachricht wird dann entsprechend an den Knoten 20 weitergeleitet, dort entsprechend verarbeitet und zum Knoten 30 weitergeleitet. Dieser verarbeitet die Startnachricht ebenso und leitet sie schließlich an den Knoten 31 weiter, wo die Startnachricht auch entsprechend verarbeitet wird. Somit sind die Routingpfad-Informationen bei allen betroffenen Knoten hinterlegt, so dass die Routingpfad-Informationen anhand des Verbindungsidentifikators wieder aufgerufen werden können. Dies hat insbesondere den Vorteil, dass weitere Nachrichten, die zu dieser Kommunikationsverbindung gehören, die Routingpfad-Informationen nicht nochmal enthalten müssen. Es genügt also, dass zum Beispiel die Nachricht vom Knoten 31 zum Knoten 11 auf dem Rückweg lediglich den Verbindungsidentifikator aufweist. Die auf dem Routingpfad P liegenden Knoten können dann diese Rücknachricht anhand der hinterlegten Routingpfad-Informationen entsprechend weiterleiten. Das gleiche gilt für weitere Nachrichten, die von dem ersten Routingknoten 11 zum zweiten Routingknoten 31 oder umgekehrt gesendet werden.
  • Variante 3
  • In einer weiteren vorteilhaften Weiterentwicklung werden nicht die gesamten Routingpfad-Informationen bei jedem beteiligten Knoten hinterlegt, sondern nur ein relevanter Teil. Um dies zu illustrieren, nehmen wir an, dass die in der Startnachricht enthaltenen Routinginformationen beispielsweise das Format „10/20/30/31“ haben.
  • Außerdem enthält die Startnachricht einen Verbindungsidentifikator, wie beschrieben. Die Startnachricht wird nun vom ersten Knoten 11 zum Knoten 10 gesendet. Dieser erkennt anhand der Routinginformationen, dass die Startnachricht an den Knoten 20 weitergeleitet werden soll. Der Knoten 10 leitet also die Startnachricht an den Knoten 20 weiter. Zudem hinterlegt der Knoten 10 in seinem oder einem zugeordneten Speicher den Verbindungsidentifikator und, damit verbunden, die Knotenidentifikatoren der Knoten 11 und 20. Den Knotenidentifikator des Knotens 20 kann der Knoten 10 aus den Routinginformationen entnehmen. Den Identifikator des Knotens 11 kann der Knoten 10 aus der Tatsache entnehmen, dass er die Startnachricht von dem Knoten 11 erhalten hat. Weitere Teile der Routinginformationen, insbesondere die Identifikatoren der Knoten 30 und 31, werden in der Routingtabelle im Knoten 10 nicht hinterlegt, weil dieser ohnehin nicht direkt mit diesen Knoten kommunizieren kann.
  • Der Knoten 20 verfährt nach Erhalt der Startnachricht entsprechend und hinterlegt in seiner Routingtabelle unter dem Verbindungsidentifikator den Identifikator des Knotens 30 als Identifikator des Nachbarknotens in Zielrichtung (also zum Zielknoten 31 hin) und zudem den Identifikator des Knotens 10 als Identifikator des Nachbarknotens in Startrichtung (also in Richtung zum Startknoten 11 hin). Außerdem leitet der Knoten 20 die Startnachricht zum Knoten 30 weiter, der entsprechend verfährt und die Startnachricht schließlich zum Knoten 31 weiterleitet. Dieser ist selbst der Zielknoten, so dass dort unter dem Verbindungsidentifkator lediglich der Identifikator des Knotens 30 als Identifikator des Nachbarknotens in Startrichtung hinterlegt werden muss.
  • Weitere im Rahmen dieser nunmehr eingerichteten Kommunikationsverbindungen brauchen dann keine Routingpfad-Informationen mehr enthalten, sondern müssen lediglich den Verbindungsidentifikator angeben. Die beteiligten Knoten können dann anhand der in ihnen hinterlegten Routingtabellen ermitteln, an welche Nachbarknoten die Nachrichten weitergeleitet werden sollen.
  • Variante 4
  • In einer weiteren Ausgestaltung können die in der Startnachricht enthaltenen Routingpfad-Informationen bei dem Weiterleiten zum nächsten Nachbarknoten verkürzt werden. Wenn beispielsweise der Routingpfad, wie oben beschrieben, vom ersten Knoten 11 über die Knoten 10, 20, 30 zum zweiten Knoten 31 führt, könnten die Routingpfad-Informationen im Prinzip durch den String „11/10/20/30/31“ dargestellt werden. Andererseits müssen die Knotenidentifikatoren der Knoten 11 und 10 nicht in der Startnachricht enthalten sein, die vom Knoten 11 zum Knoten 10 gesendet wird. Dem Knoten 10 ist sein Knotenidentifikator ohnehin bekannt, und außerdem erkennt der Knoten 10, dass die Startnachricht von dem Knoten 11 gesendet wurde. Weil die einzige Verbindung, die aus dem Netzwerk, in dem die Knoten 10 und 11 enthalten sind, über den Knoten 10 führt, kann also in diesem Fall die Startnachricht lediglich den String „20/30/31“ als Routingpfad-Information enthalten. Bei dem Weiterleiten der Startnachricht zum Knoten 20 kann der Knoten 10 die Routingpfad-Informationen um den Knotenidentifikator des Knotens 20 verkürzen, so dass dann die zu dem Knoten 20 zu leitende Startnachricht lediglich den String „30/31“ als Routinginformationen aufweist. Knoten 20 erkennt wiederum, dass er die Startnachricht vom Knoten 10 empfangen hat, so dass er diese Information in seiner Routingtabelle hinterlegen kann. Knoten 20 verfährt entsprechend und verkürzt die Routingpfad-Informationen zu „31“ und leitet die Startnachricht mit diesen verkürzten Routingpfad-Informationen an den Knoten 30 weiter. Auch dieser erkennt, dass er die Startnachricht vom Knoten 20 erhalten hat, so dass er diese Information in seiner Routingtabelle vermerken kann. Die von dem Knoten 30 an den Knoten 31 weiterzuleitende Startnachricht kann dann eine „leeren Pfad“ enthalten, weil dem Knoten 31 bekannt ist, dass er die Startnachricht vom Knoten 30 erhalten hat und hierauf nicht explizit anhand der in der Startnachricht enthaltenen Routingpfad-Informationen hingewiesen werden muss.
  • Verbindungsidentifikator
  • Insbesondere weil der oben erwähnte Verbindungsidentifikator gemäß manchen der oben beschriebenen Ausführungsformen für das korrekte Routen der Nachrichten benutzt wird, kommt diesem eine gewisse Bedeutung zu. Aus diesem Grund ist es sinnvoll sicherzustellen, dass für zwei verschiedene Kommunikationsverbindungen nicht der gleiche Verbindungsidentifikator benutzt wird. Dies könnte im Prinzip durch eine globale Absprache in allen beteiligten Netzwerken bewerkstelligt werden, wäre aber unter Umständen schwierig zu implementieren und/oder unflexibel. Obwohl möglich, wäre auch das Zuteilen eines Verbindungsidentifikators beispielsweise basierend auf dem Startknoten und einer Zeitangabe unter Umständen nicht eindeutig, weil zwei verschiedene Knoten in zwei verschiedenen Netzwerken unter Umständen den gleichen Knotenidentifikator tragen und evtl. gleichzeitig einen Call senden. Gemäß einer erfindungsgemäßen Ausführungsform wird ein alternatives Verfahren zur Vergabe von Verbindungsidentifikatoren vorgeschlagen: Die Verbindungsidentifikatoren (oder zumindest ein Teil eines jeden Verbindungsidentifikators) werden zufällig generiert, beispielsweise durch den ersten Knoten selbst. Alternativ könnte der Verbindungsidentifikator auf eine entsprechende Anfrage hin von einem anderen Knoten generiert und dem ersten Knoten bzw. der angestrebten Kommunikationsverbindung zugeteilt werden. Das Einrichten der Kommunikationsverbindung kann dann entsprechend einem der oben beschriebenen Verfahren durchgeführt werden.
  • Mit zufällig generierten Verbindungsidentifikatoren kann es allerdings auch vorkommen, dass zwei angestrebten Kommunikationsverbindungen, beispielsweise ausgehend von zwei verschiedenen Knoten, der gleiche Verbindungsidentifikator zugeteilt wird. Im Ausführungsbeispiel der 2 könnte beispielsweise der Knoten 11 eine Kommunikationsverbindung mit dem Knoten 31 wünschen und generiert hierfür einen Verbindungsidentifikator, beispielsweise „17“. Die Kommunikationsverbindung wird gemäß einem der oben beschriebenen Verfahren eingerichtet. Etwa zur gleichen Zeit, oder zumindest während die Kommunikationsverbindung zwischen dem Knoten 11 und dem Knoten 31 eingerichtet ist oder wird, wünscht beispielsweise der Knoten 41 eine Kommunikationsverbindung mit dem Knoten 32 und möchte hierfür zufällig auch den Verbindungsidentifikator „17“ benutzen. Der Knoten 41 sendet dann seine Startnachricht an den Knoten 40, der sie zum Knoten 20, wie oben beschrieben, weiterleitet. Dabei stellt Knoten 20 fest, dass bereits eine Kommunikationsverbindung mit dem Verbindungsidentifikator „17“ in seiner Routingtabelle existiert. Um eine „Kollision“ zu vermeiden bzw. um sicherzustellen, dass Nachrichten für beide Kommunikationsverbindungen korrekt geroutet werden, weist der Knoten 20 die zweite Startnachricht mit dem Verbindungsidentifikator „17“ zurück. Die von dem Knoten 41 gewünschte Kommunikationsverbindung wird also zunächst nicht weiter eingerichtet. Stattdessen sendet der Knoten 20 eine Nachricht an den Knoten 40 und dieser entsprechend eine Nachricht an den Knoten 41 zurück, um diese Knoten zu benachrichtigen, dass eine Kommunikationsverbindung mit dem Verbindungsidentifikator „17“ bereits existiert. Aufgrund dieser Nachricht generiert der Knoten 41 wiederum zufällig einen neuen Verbindungsidentifikator für die gewünschte Verbindung. Es erfolgt dann ein erneuter Versuch, die gewünschte Kommunikationsverbindung einzurichten, basierend auf dem neuen Verbindungsidentifikator. Je nach Implementierung kann es relativ unwahrscheinlich sein, dass dieser erneute Versuch wieder zurückgewiesen wird. Falls dies jedoch der Fall sein sollte, wiederholt sich dieser Teil des Verfahrens, bis die Kommunikationsverbindung zwischen dem Knoten 41 und dem Knoten 32 kollisionsfrei eingerichtet werden kann.
  • Beenden einer Kommunikationsverbindung
  • Eine Weiterentwicklung, die im Zusammenhang mit allen der oben beschriebenen Verfahren benutzt werden kann, betrifft das Beenden bzw. den Abbau einer eingerichteten Kommunikationsverbindung. Dies wird wiederum anhand der 2 beschrieben, wiederum anhand des Beispiels, nach dem der Knoten 11 Sensordaten von dem Knoten 31 angefordert hatte. Der Abbau der Kommunikationsverbindung zwischen dem ersten Knoten11 und dem zweiten Knoten 31 kann beispielsweise durch eine Finish-Nachricht eingeleitet werden. Diese könnte beispielsweise durch den zweiten Knoten versendet werden, nachdem dieser festgestellt hat, dass er alle angeforderten Sensordaten übermittelt hat, oder durch den ersten Knoten 11, nachdem dieser festgestellt hat, dass keine weiteren Sensordaten von dem Knoten 31 nötig sind.
  • Wir nehmen nun an, dass der zweite Knoten 31 die Finish-Nachricht sendet und dass der Abbau bei dem Knoten 31 anfängt. Die Finish-Nachricht wird wie andere zu der entsprechenden Kommunikationsverbindung gehörende Nachrichten entlang des Routingpfads P gesendet, und zwar in diesem Beispiel vom Knoten 31 über die Knoten 30, 20 und 10 zum Knoten 11. Mit dem Senden der Finish-Nachricht markiert jeder beteiligte Knoten in seiner Routingtabelle die Kommunikationsverbindung bzw. den Verbindungsidentifikator als deaktiviert oder löscht den entsprechenden Eintrag, insbesondere zusammen mit den gespeicherten Knoten-Identifikatoren des Vorgängerknotens und/oder Nachfolgerknotens. Letzteres insbesondere, um Speicherplatz nicht unnötigerweise zu blockieren. In jedem Fall steht der entsprechende Verbindungsidentifikator dann für zukünftige gewünschte Kommunikationsverbindungen zur Verfügung. Somit wird die Wahrscheinlichkeit einer Kollision von Kommunikationsverbindungen mit gleichem Verbindungsidentifikator minimiert.
  • Wenn alternativ die Finish-Nachricht von dem ersten Knoten 11 gesendet wird, erfolgt der Abbau in umgekehrter Reihenfolge. Auch ist es möglich, dass die Finish-Nachricht bzw. der Abbau von einem anderen Knoten ausgeht, beispielsweise dem Knoten 20. Der Abbau der Kommunikationsverbindung pflanzt sich dann, ausgehend vom Knoten 20, in beide Richtungen fort, also in Richtung des ersten Knotens 11 und des zweiten Knotens 31.
  • Initial-Call
  • In einer weiteren Ausgestaltung erfolgt ein zusätzlicher Schritt noch vor dem Senden eines Calls zum Einrichten einer Kommunikationsverbindung. Dies wird wiederum anhand der 2 beschrieben. Als konkretes Anwendungsbeispiel wird nun angenommen, dass der Knoten 11 eine Robotersteuerung darstellt. Die Robotersteuerung 11 möchte nun beispielsweise für einen neuen Fertigungsprozess eine Bahnplanung ausarbeiten lassen. Während dies bei vielen Robotern lokal/intern durchgeführt werden kann, ist es unter Umständen sinnvoll, eine Bahnplanung durch einen anderen Knoten durchführen zu lassen, insbesondere in dem Fall, dass die Bahnplanung sehr rechenintensiv ist und die Robotersteuerung 11 nicht selbst über ausreichende Rechenkapazität verfügt. Knoten 11 könnte nun die Bahnplanung von einem bestimmten Knoten in dem in 2 gezeigten System anfordern, durch einen Call wie oben beschrieben, d. h. unter Angabe der entsprechenden Routingpfad-Informationen. Gemäß der vorliegenden Variante ist dem Knoten 11 aber nicht bekannt, welcher Knoten die Bahnplanung durchführen kann/soll. Entsprechend kann er auch zumindest zunächst keinen Call mit den benötigten Routingpfad-Informationen senden. Stattdessen kann das System so eingerichtet sein, dass beispielsweise im Knoten 10 hinterlegt ist, welcher Knoten auf eine entsprechende Anfrage hin Bahnplanungen durchführen kann/soll. Um eine Bahnplanung anzufordern, sendet der Knoten 11 nun eine entsprechende Nachricht, die vorliegend „Initial-Call“ genannt wird. Dieser Initial-Call wird an Knoten 10 gesendet und wird von diesem aufgrund seines Formats oder Inhalts als Bahnplanungsanfrage erkannt. Der Initial-Call kann beispielsweise den Inhalt „Bahnplanungsservice“ aufweisen.
  • Im Knoten 10 kann nun eine Tabelle hinterlegt sein, die angibt, dass der Knoten 13 im gleichen Netzwerk für Bahnplanungen zuständig ist. Entsprechend wird ein Call generiert und gesendet, der die Routingpfad-Informationen enthält, damit die Kommunikation zwischen dem Knoten 11 und dem Knoten 13 im gleichen Netzwerk eingerichtet werden kann. Hierbei ist zu beachten, dass der Call nicht unbedingt von dem Knoten 11 gesendet wird. Weil er aufgrund der im Knoten 10 hinterlegten Tabelle generiert wird, könnte der Call beispielsweise von dem Knoten 10 gesendet werden. Als Weiterentwicklung muss dem Knoten 11 noch nicht einmal bekannt sein bzw. bekannt werden, dass der Knoten 13 der Zielknoten (oder der zweite Knoten) in der Kommunikationsverbindung ist, weil der Knoten 11 direkt nur mit dem Knoten 10 kommuniziert und es für den Knoten 11 nicht oder nicht unbedingt von Relevanz ist, durch welchen Knoten die Bahnplanung tatsächlich durchgeführt wird.
  • Die zuletzt beschriebene Variante ermöglicht auch beispielsweise einen transparenten Umzug von Diensten. Beispielsweise könnte durch eine Veränderung von Zuständigkeiten der Bahnplanungsdienst, der bis zu einem bestimmten Zeitpunkt durch den Knoten 13 durchgeführt wurde, zu einem anderen Knoten „umgezogen“ worden sein. Dies könnte beispielsweise ein anderer Knoten im gleichen Netzwerk sein, beispielsweise Knoten 12, oder aber ein Knoten in einem anderen Netzwerk, beispielsweise Knoten 31, der beispielsweise zu einem Netzwerk eines anderen Unternehmens gehört. Um diesen Umzug zu implementieren, ist es ausreichend, dass die Tabelle im Knoten 10 aktualisiert wird, so dass unter „Bahnplanungsdienst“ nicht mehr der Knoten 13 vermerkt ist, sondern entsprechend der Knoten 12 bzw. der Knoten 31. Dieser „Umzug“ wird dem Knoten 11, der den Bahnplanungsdienst anfordert, nicht oder nicht unbedingt bekannt. Knoten 11 sendet, wie zuvor beschrieben, einen Initial-Call an den Knoten 10, woraufhin dieser den eigentlichen Call zum Einrichten der Kommunikationsverbindung sendet, die nunmehr nicht mit dem Knoten 13 eingerichtet wird, sondern in dem erwähnten Beispiel mit dem Knoten 12 oder dem Knoten 31. Dies ist insbesondere dann von Vorteil, wenn mehrere Knoten (beispielsweise mehrere Roboter in einem Unternehmen) auf den gleichen Dienst zugreifen wollen. Anstatt in jedem einzelnen Knoten/Roboter etc. neue Pfadinformationen für den umgezogenen Dienst zu hinterlegen, ist eine Aktualisierung bei nur einem Knoten (in dem genannten Beispiel der Knoten 10) ausreichend, um zukünftige Anforderungen für den entsprechenden Dienst korrekt zu routen.
  • Zuqriffsbeschränkungen
  • Eine weitere Ausgestaltung wird wiederum anhand der 2 beschrieben.
  • Gemäß dieser Ausführungsform können Zugriffsmöglichkeiten eingeschränkt werden. Dies ist insbesondere dann von Interesse, wenn die betroffenen Netzwerke nicht alle beispielsweise zu dem gleichen Unternehmen gehören. Beispielsweise kann in dem Knoten 30 der 2 eine Zugriffskontrolle installiert sein, die den Zugriff auf das Netzwerk, dem die Knoten 30, 31 und 32 angehören, kontrolliert. In diesem Beispiel wird jeder Call, der von dem Knoten 20 zu dem Knoten 30 geleitet wird, von letzterem analysiert. Wenn eine entsprechende Autorisierung vorliegt, kann der Call weitergeleitet werden. Andernfalls wird er zurückgewiesen.
  • Eine solche Zugriffskontrolle muss aber nicht unbedingt in einem Knoten installiert sein, der dem zu kontrollierenden Netzwerk angehört. Eine Zugriffskontrolle für das Netzwerk, dem die Knoten 30, 31 und 32 angehören, könnte also beispielsweise auch in dem Knoten 20 installiert sein.
  • Durch die hier vorgestellte Zugriffskontrolle können Netzwerke gegen nicht autorisierte Zugriffe geschützt werden. Auch kann durch eine solche Zugriffskontrolle sichergestellt werden, dass Knoten beispielsweise nur auf solche Dienste Zugriff haben, für die eine entsprechende Gebühr bezahlt wurde.
  • 3 zeigt ein Ablaufdiagramm mit Verfahrensschritten eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens. Nach dem Start 100 des Verfahrens wird in einem Schritt 101 ein Call zum Einrichten einer Kommunikationsverbindung gesendet. Der Call weist Routingpfad-Informationen auf, die den Routingpfad von einem ersten Knoten zu einem zweiten Knoten angeben. In einem weiteren Schritt 102 wird die Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten basierend auf den Routingpfad-Informationen eingerichtet. Danach kann das Verfahren enden (Schritt 103).
  • Weitere Details von Ausführungsformen eines erfindungsgemäßen Verfahrens wurden bereits zuvor beschrieben.
  • Ausführungsformen der vorliegenden Erfindung eignen sich für verschiedene Anwendungen. Als nicht einschränkende Beispiele seien die folgenden Anwendungen genannt.
  • Beispiel 1
  • Ein Benutzer hat eine Benutzerschnittstelle, mit der er eine konkrete Roboternutzerapplikation verwalten kann. Mit der vorliegenden Erfindung kann diese Benutzerschnittstelle im Wesentlichen überall benutzt werden: Direkt angeschlossen an dem Roboter; in einem WLAN-Netzwerk in der Fabrik, in der sich der Roboter befindet; in einem Intranet der Firma, zu der der Roboter gehört; oder über das öffentliche Internet.
  • Je nach Ausführung und abhängig von anderen Faktoren kann der Routingpfad bzw. können die Routingpfad-Informationen dem Benutzer bzw. dem Gerät (Computer, Laptop, Tablet, Smartphone etc.), das der Benutzer als Schnittstelle benutzt, bereits bekannt sein oder nicht. Solche Faktoren können insbesondere der aktuelle „Standort“ des als Schnittstelle benutzten Geräts sein und/oder die (direkte) Anbindung an ein bestimmtes Netzwerk.
  • Falls der Routingpfad bzw. die Routingpfad-Informationen nicht bereits bekannt sind, können diese ermittelt werden. Hierfür kommen mehrere Möglichkeiten in Betracht, die im Übrigen auch bei anderen Beispielen oder Ausführungsformen Anwendung finden können:
    1. (a) Pfad im Dateisystem: Es gibt eine Wurzel im Netzwerk, die von überall direkt adressierbar ist (z.B. ein Knoten im Cloud-Netzwerk des Roboterherstellers) und es gibt eine logische Topologie, z.B.: cloud/kunde/fabrik/roboter
    2. (b) Interaktives Browsing: Der Benutzer durchsucht selbst das Netz ausgehend von seinem lokalen Knoten. Die Interaktion ist dann ähnlich wie in einem Filesystem Browser. Der Benutzer navigiert Schritt für Schritt von einem Knoten zum nächsten (Nachbar-) Knoten und von dort wiederum zum nächsten (Nachbar-) Knoten usw. Wenn der Benutzer schließlich sein Ziel gefunden hat, entspricht der so gefundene Pfad dem gesuchten Routingpfad.
    3. (c) Telefonbuch/Suchdienst: Es gibt direkt erreichbare Dienste, die die Routingpfade speichern und anhand von Zusatzinformationen durchsuchbar machen. Dienste/Roboter können sich an einem solchen Dienst mit beliebiger Information anmelden und auffindbar sein. Z.B. übergibt der Kunde zuerst einem Dienst (beispielsweise auf cloud/kunde1/search) als Suchbegriff einen Roboternamen und bekommt den Routingpfad als Antwort von diesem Dienst.
    4. (d) Domain-Name-System (dies kann dem entsprechen, was in dem Abschnitt „Initial-Call“ beschrieben ist, bzw. hierauf aufbauen): Der Zieldienst/Roboter hat einen abstrakten Namen. Dieser abstrakte Name ist dem Benutzer bekannt. Außerdem wird der abstrakte Name und der zu dem Zieldienst/Roboter führende aktuelle Routingpfad in direkt erreichbaren Diensten hinterlegt. Falls ein Dienst/Roboter „umzieht“, wird die hinterlegte Information aktualisiert. Der Nutzer kann dann anhand des ihm bekannten abstrakten Namen auf den Zieldienst/Roboter zugreifen.
  • Beispiel 2
  • Für eine Kundenapplikation wird ein Roboter eines Kunden mit zusätzlichen Sensoren ausgestattet. Es werden kundenspezifische Dienste entwickelt, die die Sensordaten auslesen und auf dem Roboter laufen. Diese kundenspezifischen Erweiterungsdienste werden auf dem Roboter an das (beispielsweise in 1 gezeigte) Gesamtnetzwerk 50 angebunden und sind damit beispielsweise auch in einem Cloud-Netzwerk verfügbar, ohne dass Änderungen an der Kommunikation von Kunde zu dem Netzwerk des Roboterherstellers notwendig sind.
  • Beispiel 3
  • Das Auslesen von Sensordaten wurde bereits erwähnt. So kann beispielsweise ein Mitarbeiter einer Roboterherstellerfirma über das Intranet dieser Firma im Rahmen einer Kundenbetreuung Sensordaten bezüglich eines Roboters abfragen, der sich in einem anderen Netzwerk befindet. Sensordaten können auch automatisch von dem Kundennetzwerk an das Netzwerk der Roboterherstellerfirma gemeldet werden. Diese Daten können beispielsweise im Kundennetzwerk oder im Netzwerk der Roboterherstellerfirma auf Anomalitäten überprüft werden. Im Falle einer signifikanten Abweichung von vorgegebenen Werten können dann gegebenenfalls zusätzliche Sensordaten angefordert werden, beispielsweise um eine Diagnose eines Problems bezüglich des Roboters zu ermöglichen.
  • Beispiel 4
  • Es wurde bereits beschrieben, dass beispielsweise Bahnplanungsdienste oder andere Dienste, die im Zusammenhang mit einer automatisierbaren industriellen Anlage von Interesse sein könnten, ausgelagert werden können, d. h. nicht direkt durch die oder an der industriellen Anlage erbracht werden. Dadurch kann gegebenenfalls Speicherkapazität und/oder Rechenkapazität an der Anlage bzw. an mehreren Anlagen eingespart werden, was eine kostengünstigere und/oder Ressourcenschonende Herstellung begünstigen kann. Die entsprechenden Dienste können dann zentral, also für mehrere Anlagen, durch einen Knoten beispielsweise in einem anderen Netzwerk erbracht werden. Zudem kann die Bereitstellung dieser Dienste dynamisch auf andere Knoten verlagert werden. Insbesondere, wenn diese Verlagerung „transparent“ durchgeführt wird, ist hierfür unter Umständen nur eine Aktualisierung einer Routentabelle oder ähnliches an einem einzigen Knoten nötig, und nicht an allen Knoten, die den betreffenden Dienst benutzen, wie bereits beschrieben.
  • Obwohl in der vorhergehenden Beschreibung exemplarische Ausführungen erläutert wurden, sei darauf hingewiesen, dass eine Vielzahl von Abwandlungen möglich ist. Außerdem sei darauf hingewiesen, dass es sich bei den exemplarischen Ausführungen lediglich um Beispiele handelt, die den Schutzbereich, die Anwendungen und den Aufbau in keiner Weise einschränken sollen. Vielmehr wird dem Fachmann durch die vorausgehende Beschreibung ein Leitfaden für die Umsetzung von mindestens einer exemplarischen Ausführung gegeben, wobei diverse Änderungen, insbesondere in Hinblick auf die Funktion und Anordnung der beschriebenen Bestandteile, vorgenommen werden können, ohne den Schutzbereich zu verlassen, wie er sich aus den Ansprüchen und diesen äquivalenten Merkmalskombinationen ergibt.
  • Bezugszeichenliste
  • 1-4
    Knoten / Identifikatoren
    C, D, F, K, S, T
    Knoten / Identifikatoren
    K-I
    Netzwerk (Intranet Roboterhersteller)
    CL-C, CL-S
    (Cloud-)Netzwerke
    C-D, C-F, C-T
    (Kunden-)Netzwerke
    10-13
    Knoten
    20-21
    Knoten
    30-32
    Knoten
    40-41
    Knoten
    50
    Gesamtnetzwerk
    100-103
    Verfahrensschritte

Claims (16)

  1. Verfahren zum Einrichten einer Kommunikationsverbindung zwischen einem ersten Knoten (11) in einem ersten von wenigstens zwei Netzwerken und einem zweiten Knoten (31) in einem zweiten der wenigstens zwei Netzwerke, wobei wenigstens einer des ersten und des zweiten Knotens (11, 31) eine automatisierbare industrielle Vorrichtung oder eine automatisierbare industrielle Anlage oder eine Steuerung hierfür ist, wobei die wenigstens zwei Netzwerke einzeln jeweils einen homogenen Adressraum bilden, wobei die wenigstens zwei Netzwerke zusammen keinen homogenen Adressraum bilden, wobei das Verfahren die folgenden Schritte aufweist: Senden (101) eines Calls zum Einrichten der Kommunikationsverbindung zwischen dem ersten Knoten und dem zweiten Knoten, wobei der Call Routingpfad-Informationen (10/20/30/31) aufweist, die den Routingpfad von dem ersten Knoten (11) zu dem zweiten Knoten (31) angeben, wobei die Routingpfad-Informationen (10/20/30/31) wenigstens einen Identifikator (10, 20, 30, 31) eines jeden der auf dem Routingpfad zu traversierenden Netzwerken oder Knoten, jedoch nicht notwendigerweise einen Identifikator des ersten Netzwerks, aufweisen; und Einrichten (102) der Kommunikationsverbindung zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) basierend auf den Routingpfad-Informationen (10/20/30/31).
  2. Verfahren nach Anspruch 1, wobei die Routingpfad-Informationen (10/20/30/31) einen Identifikator des zweiten Knotens (31) aufweisen.
  3. Verfahren nach Anspruch 1 oder 2, wobei der Call ferner einen Verbindungs-Identifikator aufweist.
  4. Verfahren nach Anspruch 3, wobei die Kommunikationsverbindung zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) wenigstens zwei Nachrichten aufweist und wobei alle Nachrichten dieser Kommunikationsverbindung zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) diesen Verbindungs-Identifikator aufweisen.
  5. Verfahren nach Anspruch 4, wobei zumindest ein Teil des VerbindungsIdentifikators zufällig generiert oder zugeteilt wird, insbesondere durch den ersten Knoten (11), und insbesondere wobei im Falle, dass die Verbindungs-Identifikatoren eines ersten und eines zweiten Calls übereinstimmen und insbesondere im Falle, dass die Routingpfade des ersten und zweiten Calls über den gleichen Knoten (20) führen, der zweite Call abgelehnt wird und/oder ein neuer Verbindungs-Identifikator für den zweiten Call generiert oder diesem zugeteilt wird.
  6. Verfahren nach einem der Ansprüche 3 bis 5, wobei für einen oder den ersten Call in jedem auf dem Routingpfad zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) liegenden Knoten oder einer zugehörigen Speichervorrichtung der zugehörige Verbindungs-Identifikator und ein Knoten-Identifikator eines Vorgängerknotens und ein Knoten-Identifikator eines Nachfolgerknotens gespeichert wird, wobei der Vorgängerknoten ein auf dem Routingpfad liegender Knoten, insbesondere ein auf dem Routingpfad unmittelbar benachbart liegender Knoten, in Richtung des ersten Knotens (11) ist, und wobei der Nachfolgerknoten ein auf dem Routingpfad liegender Knoten, insbesondere ein auf dem Routingpfad unmittelbar benachbart liegender Knoten, in Richtung des zweiten Knotens (31) ist.
  7. Verfahren nach einem der Ansprüche 3 bis 6, wobei die Routingpfad-Informationen (10/20/30/31) und der dazugehörige Verbindungs-Identifikator eines Calls in einer Startnachricht enthalten sind.
  8. Verfahren nach Anspruch 7, insbesondere in Abhängigkeit von Anspruch 6, wobei auf die Startnachricht folgende Nachrichten dieses Calls den dazugehörigen Verbindungs-Identifikator, nicht aber die Routingpfad-Informationen (10/20/30/31) aufweisen, wobei die auf die Startnachricht folgenden Nachrichten vorzugsweise anhand der in den auf dem Routingpfad zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) liegenden Knoten oder der zugehörigen Speichervorrichtung gespeicherten Knoten-Identifikatoren geroutet werden.
  9. Verfahren nach Anspruch 6, oder nach einem der Ansprüche 7 bis 8 in direkter oder indirekter Abhängigkeit von Anspruch 6, wobei beim Beenden des Calls in den auf dem Routingpfad zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) liegenden Knoten oder der zugehörigen Speichervorrichtung der gespeicherte zugehörige Verbindungs-Identifikator und/oder der gespeicherte Knoten-Identifikator des Vorgängerknotens und/oder der gespeicherte Knoten-Identifikator des Nachfolgerknotens deaktiviert werden, insbesondere gelöscht werden.
  10. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Kommunikationsverbindung eine bidirektionale Kommunikationsverbindung ist.
  11. Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend: vor dem Senden des Calls, Senden eines Initial-Calls durch den ersten Knoten (11), wobei der Initial-Call keine oder nur unvollständige Routingpfad-Informationen aufweist, wobei anhand des Initial-Calls die für den Call benötigten Routingpfad-Informationen (10/20/30/31) ermittelt werden können, insbesondere durch einen von dem ersten Knoten (11) verschiedenen Knoten, insbesondere mithilfe einer Zuordnung zwischen einer in dem Initial-Call enthaltenen Information und den Routingpfad-Informationen (10/20/30/31).
  12. Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend das Zurückweisen eines Calls, insbesondere an einem oder durch einen auf dem Routingpfad zwischen dem ersten Knoten (11) und dem zweiten Knoten (31) liegenden Knoten, insbesondere im Falle, dass der Call oder die Kommunikationsverbindung nicht autorisiert ist.
  13. Verfahren nach einem der vorhergehenden Ansprüche, wobei wenigstens einer des ersten und des zweiten Knotens (11, 31) eine autonome Transportvorrichtung, ein stationärer oder mobiler Manipulator, eine stationäre oder mobile Manipulatoranordnung, insbesondere ein stationärer oder mobiler Roboter oder eine stationäre oder mobile Roboteranordnung, oder eine Steuerung hierfür, oder eine Kombination aus zwei oder mehr von diesen ist.
  14. Steuervorrichtung für einen Knoten, insbesondere für einen Manipulator, insbesondere für einen Roboter, wobei die Steuervorrichtung zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche eingerichtet ist.
  15. Computerprogramm, das ein Verfahren nach einem der Ansprüche 1 bis 13 ausführt, wenn es in einer Steuervorrichtung nach Anspruch 14 abläuft.
  16. Computerprogrammprodukt mit Programmcode, der auf einem maschinenlesbaren Träger gespeichert ist und ein Computerprogramm nach Anspruch 15 umfasst.
DE102019211843.7A 2019-08-07 2019-08-07 Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung Pending DE102019211843A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102019211843.7A DE102019211843A1 (de) 2019-08-07 2019-08-07 Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung
CN202080070124.0A CN114556880B (zh) 2019-08-07 2020-07-30 与可自动化的工业装置或设备或与其控制器的通信
EP20749875.9A EP4010767A1 (de) 2019-08-07 2020-07-30 Kommunikation mit automatisierbaren industriellen vorrichtungen oder anlagen oder mit deren steuerung
PCT/EP2020/071506 WO2021023614A1 (de) 2019-08-07 2020-07-30 Kommunikation mit automatisierbaren industriellen vorrichtungen oder anlagen oder mit deren steuerung
US17/637,166 US11799759B2 (en) 2019-08-07 2020-07-30 System and method for configuring communication links between nodes in network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019211843.7A DE102019211843A1 (de) 2019-08-07 2019-08-07 Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung

Publications (1)

Publication Number Publication Date
DE102019211843A1 true DE102019211843A1 (de) 2021-02-11

Family

ID=71894827

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019211843.7A Pending DE102019211843A1 (de) 2019-08-07 2019-08-07 Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung

Country Status (5)

Country Link
US (1) US11799759B2 (de)
EP (1) EP4010767A1 (de)
CN (1) CN114556880B (de)
DE (1) DE102019211843A1 (de)
WO (1) WO2021023614A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100061309A1 (en) * 2003-07-14 2010-03-11 Buddhikot Milind M Method and system for mobility across heterogeneous address spaces

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6842430B1 (en) * 1996-10-16 2005-01-11 Koninklijke Philips Electronics N.V. Method for configuring and routing data within a wireless multihop network and a wireless network for implementing the same
US6130881A (en) * 1998-04-20 2000-10-10 Sarnoff Corporation Traffic routing in small wireless data networks
US6449354B1 (en) * 1999-06-08 2002-09-10 Nortel Networks Limited Communication system, article and method of configuring and establishing a connection therein
US6785226B1 (en) * 1999-09-01 2004-08-31 Carriercomm, Inc. System and method for data routing over a network
US7484008B1 (en) * 1999-10-06 2009-01-27 Borgia/Cummins, Llc Apparatus for vehicle internetworks
US20020031131A1 (en) * 2000-02-02 2002-03-14 Yechiam Yemini Method and apparatus for the exchange of data between a dynamically addressed network and a foreign network
US8996705B2 (en) * 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
MXPA04004719A (es) * 2003-05-19 2004-09-06 Eaton Corp Red ad-hoc y metodo de enrutar comunicaciones en una red de comunicaciones.
US20070061041A1 (en) * 2003-09-02 2007-03-15 Zweig Stephen E Mobile robot with wireless location sensing apparatus
JP4571666B2 (ja) * 2004-04-05 2010-10-27 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 無線マルチホップアドホックネットワークにおけるアドレス解決マッピングのための方法、通信デバイスおよびシステム
US7649834B2 (en) * 2004-09-15 2010-01-19 At&T Intellectual Property Ii, L.P. Method and apparatus for determining neighboring routing elements and rerouting traffic in a computer network
US20070019641A1 (en) * 2005-07-22 2007-01-25 Rockwell Automation Technologies, Inc. Execution of industrial automation applications on communication infrastructure devices
US8156232B2 (en) * 2005-09-12 2012-04-10 Rockwell Automation Technologies, Inc. Network communications in an industrial automation environment
US8281385B2 (en) * 2005-09-29 2012-10-02 Rockwell Automation Technologies, Inc. Internet friendly proxy server extending legacy software connectivity
US8175089B2 (en) * 2005-09-30 2012-05-08 Rockwell Automation Technologies, Inc. Extended address space capability for an industrial protocol
US9195233B2 (en) * 2006-02-27 2015-11-24 Perrone Robotics, Inc. General purpose robotics operating system
US7676279B2 (en) * 2006-09-29 2010-03-09 Rockwell Automation Technologies, Inc. Services for industrial control systems
CN1988546A (zh) * 2006-12-15 2007-06-27 华为技术有限公司 获取会话起始协议消息传输路径的方法及系统
WO2009036792A1 (en) * 2007-09-21 2009-03-26 Greenpeak Technologies Compressed source routing
US8396022B1 (en) * 2007-11-07 2013-03-12 Dust Networks, Inc. Source routing bandwidth activation
CN101272395B (zh) * 2008-05-20 2012-07-11 北京交通大学 一种通信网络的层次接入控制方法
CN102057722B (zh) * 2008-06-04 2014-03-05 皇家飞利浦电子股份有限公司 用于无线多跳网络中的节点的网络接口单元以及建立无线多跳网络中节点之间的网络路径的方法
JP5044537B2 (ja) * 2008-12-15 2012-10-10 株式会社日立製作所 トランスポート制御サーバ、ネットワークシステム及び集約パス決定方法
US8000267B2 (en) * 2009-02-24 2011-08-16 Palo Alto Research Center Incorporated Network routing with path identifiers
EP2249541A1 (de) * 2009-05-07 2010-11-10 France Telecom Verteilung von Kommunikationsdatenströmen zwischen zwei Knoten, die über unterschiedliche Netzpfade verknüpft sind
WO2012169855A2 (ko) * 2011-06-09 2012-12-13 엘지전자 주식회사 무선통신 시스템에서 이웃 발견 방법 및 장치
WO2013137884A1 (en) * 2012-03-15 2013-09-19 Schneider Electric Industries Sas Device address management in an automation control system
EP2856720A1 (de) * 2012-05-25 2015-04-08 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und vorrichtung zur konfiguration einer verbindung in einem label-geschalteten kommunikationsnetzwerk
US10904144B2 (en) * 2012-12-27 2021-01-26 Sitting Man, Llc Methods, systems, and computer program products for associating a name with a network path
US9621969B2 (en) * 2013-11-11 2017-04-11 Infinera Corporation Management and control of software defined networking enabled open transport networks
EP3059930B1 (de) * 2015-02-18 2021-01-06 Siemens Aktiengesellschaft Verfahren zur konfiguration eines kommunikationsgeräts eines industriellen automatisierungssystems und kommunikationsgerät
EP3062490B1 (de) * 2015-02-27 2018-07-18 Siemens Aktiengesellschaft Verfahren zur Datenübermittlung innerhalb eines industriellen Automatisierungssystems und Kommunikationsgerät
EP3091714B1 (de) * 2015-05-04 2018-03-21 Siemens Aktiengesellschaft Verfahren zur bereitstellung eines namensdienstes innerhalb eines industriellen automatisierungssystems und kommunikationsgerät
EP3113461B1 (de) * 2015-06-30 2019-03-20 Siemens Aktiengesellschaft Verfahren zum aufbau von kommunikationsverbindungen zu redundant betriebenen steuerungsgeräten eines industriellen automatisierungssystems und steuerungsgerät
EP3320435A1 (de) * 2015-07-09 2018-05-16 Telecom Italia S.p.A. Verfahren und system zur bereitstellung von ict-diensten
EP3136688B1 (de) * 2015-08-31 2021-06-23 Siemens Aktiengesellschaft Verfahren zur bereitstellung eines zugriffs auf gerätekonfigurationsdaten innerhalb eines industriellen automatisierungssystems und web-server-komponente
EP3142334B1 (de) * 2015-09-11 2019-11-06 Siemens Aktiengesellschaft Verfahren zum betrieb von kommunikationsgeräten innerhalb eines industriellen automatisierungssystems
US10355976B2 (en) * 2015-10-26 2019-07-16 Abb Schweiz Ag Methods, nodes and system for establishing independent network paths
US9836512B1 (en) * 2016-05-11 2017-12-05 Acalvio Technologies, Inc. Systems and methods for identifying similar hosts
EP3267636B1 (de) * 2016-07-06 2018-10-31 Siemens Aktiengesellschaft Modulares industrielles automatisierungsgerät und verfahren zur konfiguration eines modularen industriellen automatisierungsgeräts
US10259117B2 (en) * 2016-08-02 2019-04-16 At&T Intellectual Property I, L.P. On-demand robot virtualization
US10122627B2 (en) * 2016-08-31 2018-11-06 Citrix Systems, Inc. Network routing through an overlay network
US10153964B2 (en) * 2016-09-08 2018-12-11 Citrix Systems, Inc. Network routing using dynamic virtual paths in an overlay network
US10412042B2 (en) * 2016-09-21 2019-09-10 Rockwell Automation Technologies, Inc. Topology based internet protocol (IP) addressing
US10646994B2 (en) * 2017-04-25 2020-05-12 At&T Intellectual Property I, L.P. Robot virtualization leveraging Geo analytics and augmented reality
US10733004B2 (en) * 2017-04-26 2020-08-04 At&T Intellectual Property I, L.P. Intelligent service on-demand robot virtualization
EP3462710B1 (de) * 2017-09-29 2020-01-15 Siemens Aktiengesellschaft Verfahren zur bereitstellung eines namensdienstes innerhalb eines industriellen automatisierungssystems und switch
WO2019206427A1 (de) * 2018-04-27 2019-10-31 Siemens Aktiengesellschaft Verfahren zur ermittlung von geräteadressen innerhalb eines kommunikationsnetzes eines industriellen automatisierungssystems, kommunikationsgerät und steuerungseinheit
US10826823B2 (en) * 2018-07-31 2020-11-03 Facebook, Inc. Centralized label-based software defined network
US11770724B2 (en) * 2018-08-03 2023-09-26 Lg Electronics Inc. Mobile terminal for displaying whether QoS is satisfied in wireless communication system
EP3611876A1 (de) * 2018-08-13 2020-02-19 Siemens Aktiengesellschaft Verfahren zur konfiguration, verfahren zur bereitstellung von topologie-informationen, verwendung, gerät, computerprogramm und computerlesbares medium
US20200364173A1 (en) * 2018-09-04 2020-11-19 All Axis Robotics, LLC Universal bridge controller for machine language interpretive collaborative robot and machine interface
EP3621245B1 (de) * 2018-09-05 2022-03-09 Siemens Aktiengesellschaft Verfahren zum automatischen konfigurieren eines routers, verfahren zur automatischen adresskonfiguration, router, computerprogramm und computerlesbares medium
WO2020080913A1 (ko) * 2018-10-19 2020-04-23 엘지전자 주식회사 무선 통신 시스템에서 독립적인 네트워크 슬라이스별로 분리된 데이터 전송을 지원하는 방법
WO2020149718A1 (en) * 2019-01-18 2020-07-23 Lg Electronics Inc. Method and apparatus for access control in wireless communication system
US20200245235A1 (en) * 2019-01-24 2020-07-30 Lg Electronics Inc. Method for selecting non-public network in wireless communication system and apparatus thereof
US20200259896A1 (en) * 2019-02-13 2020-08-13 Telefonaktiebolaget Lm Ericsson (Publ) Industrial Automation with 5G and Beyond
WO2020204536A1 (ko) * 2019-03-29 2020-10-08 엘지전자 주식회사 무선 통신 시스템에서 단말이 네트워크에 접속을 수행하는 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100061309A1 (en) * 2003-07-14 2010-03-11 Buddhikot Milind M Method and system for mobility across heterogeneous address spaces

Also Published As

Publication number Publication date
US20220407797A1 (en) 2022-12-22
EP4010767A1 (de) 2022-06-15
WO2021023614A1 (de) 2021-02-11
CN114556880B (zh) 2024-10-18
US11799759B2 (en) 2023-10-24
CN114556880A (zh) 2022-05-27

Similar Documents

Publication Publication Date Title
DE69118053T2 (de) Automatisiertes Adresserkennungsverfahren für lokale Netzwerke und Gerät dazu
EP3480672B1 (de) Verfahren zum erkennen und anzeigen von operator-zugriffen auf prozessobjekte sowie operator-system
EP3180666A1 (de) Verfahren zur planung der herstellung eines produkts und produktionsmodul mit selbstbeschreibungs-informationen
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
DE10210675A1 (de) Steuerungen, Erweiterungsplatten und Kommunikationseinheiten
EP3499333B1 (de) Fahrerloses transportsystem und verfahren zum betreiben eines fahrerlosen transportsystems
DE102011052384A1 (de) Automatische Annahme, Inspektion, Bestandsverwaltung und Berichterstellung mit Hilfe drahtloser Kommunikation
EP3881079A1 (de) Laborsystem mit zumindest teilweise vernetzten laborgeräten und verfahren zur steuerung eines laborsystems mit zumindest teilweise vernetzten laborgeräten
EP2142460A2 (de) Verfahren zur einstellung einer vielzahl von bedieneinheiten einer aufzugsanlage mit einer vielzahl von stockwerken
DE112017001723T5 (de) Ermöglichen von automatischer sensorerkennung in autonomen vorrichtungen
DE102010063164A1 (de) Verfahren zum Integrieren von mindestens einem Feldgerät in ein Netzwerk der Automatisierungstechnik
EP3598255B1 (de) Anordnung mit operator-servern und mit operator-clients
DE102019211843A1 (de) Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung
DE102010006093A1 (de) Verfahren zum Aufbau oder zur Aktualisierung von Routingtabellen für ein modulares Fördersystem und modulares Fördersystem
EP3652595B1 (de) Verfahren und system zum überwachen einer anlage der automatisierungstechnik
EP2110725B1 (de) System und Verfahren zur Zuordnung eines Gerätenamens
EP4108056A1 (de) Verfahren zur planung und steuerung einer logistischen prozesskette in der agrarwirtschaft
DE102013212181A1 (de) Schweissanlage und Verfahren zum Austauschen von Prozessdaten einer Schweissanlage
EP3552063B1 (de) Verfahren zur automatischen konfiguration von funktionseinheiten eines automatisierungssystems
DE102022120529B4 (de) Verfahren und Einrichtung zum Betrieb einer Vielzahl von IO-Link-Geräten mittels eines IO-Link-Masters
DE102018131119A1 (de) Integration mehrerer Anlagenmodule mit jeweils wenigstens einer prozesstechnischen Einheit zu einer modular aufgebauten Gesamtanlage
DE112019001163T5 (de) Netzwerkadressierungsverfahren, leitstation und bodenstation
DE102018116488A1 (de) Verfahren zum Zwischenlagern von Karosserien sowie Produktionsanlage
DE102017006644A1 (de) System zum Führen mindestens eines Fahrzeugs in einem teilautomatisierten oder autonomen Fahrbetrieb
EP0740806B1 (de) Verfahren zur steuerung eines technischen prozesses nach dem prinzip des endlichen automaten

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012701000

Ipc: H04L0012723000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012723000

Ipc: H04L0045500000