-
Die Erfindung betrifft eine Zuordnungseinheit und ein Verfahren zur Zuordnung von Objektdaten zu einem Objektidentifikator.
-
Im Stand der Technik sind Objektidentifikatoren als ein mit einer bestimmbaren Identität eines Objekts verknüpftes Merkmal zur eindeutigen Identifizierung des zugrundeliegenden Objekts bekannt.
-
Die zugrundeliegenden Objekte umfassen elektronische und nicht-elektronische Objekte, wie z.B. physische Assets, welche häufig mit einem Objektidentifikator versehen werden. Dieser Objektidentifikator identifiziert das Objekt eindeutig in einem bestimmten Anwendungskontext. Beispiele für physische Assets sind Maschinen, Werkzeuge oder Werkstücke in einer Fabrikanlage, auf denen ein den Objektidentifikator beinhaltender Datenträger aufgebracht ist, etwa in Form von Barcodes, QR-Codes, NFC-Tags, RFID-Tags, etc. Beispiele für elektronische Objekte umfassen elektronische Dokumente, die über einen QR-Code auf einem physischen Medium abrufbar sind.
-
Auf einen Objektidentifikator wird im technischen Sprachgebrauch überwiegend mit dem allgemeinen Begriff »Identifier« oder abkürzend ID Bezug genommen.
-
Im Stand der Technik sind mannigfaltige Ausprägungen von Objektidentifikatoren bekannt. Als Objektidentifikatoren werden meist Nummern oder Codes aus alphanumerischen Zeichen verwendet. Auch sprachliche Objektidentifikatoren, beispielsweise Deskriptoren in einem Computerprogramm oder in einem strukturierten Dokument, sowie Farbcodierungen finden Einsatz als Objektidentifikator.
-
Nach Erfassung eines den Objektidentifikator beinhaltenden Datenträgers mit einer Erfassungseinheit, beispielsweise durch einen Scanner zur Erfassung von Barcodes, QR-Codes, NFC-Tags, RFID-Tags, etc., können dem Objektidentifikator zugrundeliegende Objektdaten aufgerufen und bearbeitet werden. Datensätze dieser Objektdaten können beispielsweise angelegt, verändert oder gelöscht werden.
-
In komplexeren Systemen ist es üblich, die einem Objekt über dessen Objektidentifikator zugeordneten Daten getrennt und teilweise unkoordiniert in unterschiedlichen, verteilten Systemen vorzuhalten, insbesondere in verteilten Cloud Computing Systemen. Derartige verteilte Systeme entstehen derzeit im Bereich der industriellen Automatisierungstechnik, bei Produktions- oder Werkzeugmaschinen, bei Diagnose- oder Serviceunterstützungssystemen. Die verteilten Systeme sollen eine Bedienung und Wartung komplexer Komponenten, Geräte und Systeme, insbesondere industrieller oder medizinischer Anlagen unterstützen.
-
Im Folgenden wird die verteilte Datenhaltung am Beispiel einer in einem industriellen Automatisierungsumfeld arbeitenden Maschine betrachtet. Für die durch einen Objektidentifikator charakterisierte Maschine werden Daten in verteilten Systemen vorgehalten. Zu diesen Daten zählen insbesondere Supportdokumentationsdaten, Betriebsdaten, Belegungszeiten und Konstruktionsdaten, welche in jeweils unterschiedlichen Systemen bzw. Datenbanken vorgehalten werden. Supportdokumentationsdaten sind beispielsweise in einer Service-Datenbank des Maschinenherstellers vorgehalten, Betriebsdaten werden dagegen in der Maschine selbst gespeichert, historische Betriebsdaten wiederum in einem mehrere Maschinen verwaltenden Fertigungssteuerungssystem. Weiterhin können Belegungszeiten der Maschinen in einem übergeordneten Betriebsplanungssystem, Konstruktionsdaten wiederum in einem Engineering-Tool vorgehalten sein.
-
Infolge der getrennten Datenhaltung in unterschiedlichen, verteilten Systemen entsteht somit das Problem, dass die eindeutige Zuordnung des Objekts zu dessen Objektidentifikator verloren geht, da der Objektidentifikator häufig in verschiedenen Zugriffssystemen auf unterschiedlichen Datenbanken jeweils verschieden ist. Ungeachtet der Vorteile einer Datenhaltung in verteilten Systemen haben diese den Nachteil, dass eine Verwendung einheitlicher Objektidentifikatoren nicht praktiziert wird oder sogar technisch unmöglich ist.
-
Auch eine Zusammenführung von in verschiedenen Zugriffssystemen unterschiedlichen Objektidentifikatoren für das selbe Objekt gestaltet sich schwierig, da derzeit bekannte verteilte Systeme – insbesondere im Produktionsumfeld – nicht darauf ausgelegt sind, in einem aus mehreren heterogenen Systemen zusammengesetzten Rechnerverbund einen einheitlichen Zugriff auf mannigfaltige Objektdaten bereitzustellen. Für jede einem Objektidentifikator zugeordnete Funktionalität muss eine spezifische Integrationslösung implementiert werden, was sehr zeit- und ressourcenaufwändig ist und deshalb nur in Ausnahmefällen praktiziert werden kann.
-
Ein weiteres Problem besteht darin, dass zu identifizierende Objekte, z.B. Werkstücke, sehr häufig mit mehreren Objektidentifikatoren, z.B. in Form mehrerer Barcodes, gekennzeichnet sind. Für jeden Objektidentifikator existiert ein separates Abrufsystem zum Zugriff auf bestimmte Daten des Objekts, z.B. Stücklisten für Bestellungen in Logistiksystemen, Arbeitsplänen in Teamcenter, Maschinenstatus in einem weiteren, proprietären System.
-
Diese nachteilige proprietäre Vielfalt beschränkt sich somit nicht auf die datenhaltenden Systeme, sondern entsteht bereits auf der Ebene der Erfassungseinheit zur Erfassung des Barcodes. Im industriellen Umfeld sind proprietäre Erfassungseinheiten zur Zusammenarbeit mit einem Logistiksystem neben weiteren, ebenfalls proprietären Erfassungseinheiten, zur Anbindung an automatische Regalsysteme keine Seltenheit.
-
Die vorliegende Erfindung ist demgegenüber vor die Aufgabe gestellt, Mittel bereitzustellen, welche eine Zuordnung von Objektdaten zu einem Objektidentifikator in einer verteilten bzw. dezentralen Umgebung gewährleistet.
-
Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst.
-
Dabei ist zunächst eine wahlfreie Entgegennahme des Objektidentifikators durch eine Zuordnungseinheit, beispielsweise durch Übertragung des Objektidentifikators von einer Erfassungseinheit, vorgesehen.
-
In einem weiteren Schritt erfolgt eine Publikation einer Anfragenachricht an einen Publikations-/Abonnementdienst bzw. Publish/Subscribe Service. In einem derartigen Publikations-/Abonnementdienst erfolgt eine Nachrichtenverteilung von einem publizierenden Einheit, dem Publisher, an einen oder mehrere abonnierende Einheiten, den Subscribers. Die Einheitensind mit einem Dienst verbunden, welcher als Nachrichtenvermittler zwischen den als Datenquellen und/oder als Datensenke operierenden Einheiten agiert. Auf diesen Dienst wird daher auch als Nachrichtenmakler bzw. Message Broker Bezug genommen. Alle Systemkomponenten, die ein Abonnement auf Anfragenachricht eingerichtet haben, erhalten diese Anfragenachricht. Die Systemkomponenten prüfen dann, ob sie den mit der Anfragenachricht übermittelten Objektidentifikator »auflösen« können, d.h. sie prüfen, ob in ihren system-internen oder system-externen und durch sie zugreifbaren Datenbanken ein Eintrag zu diesem Objektidentifikator besteht.
-
Eine Publikation oder ein Abonnement von Nachrichten in einem Publikations-/Abonnementdienst erfolgt anhand eines Betreffs bzw. Topic. Unter Angabe eines Betreffs teilt ein abonnierender Client mit, an welchen Nachrichten Interesse besteht bzw. welcher Betreff abonniert wird. In der einfachsten Betriebsart muss der Nachrichtenmakler beim Erhalt eines Betreffs von einem publizierenden Client nur prüfen, ob es für den jeweiligen Betreff einen Abonnenten gibt. Falls ja, werden die Daten an den oder die Abonnenten weitergeleitet, andernfalls verworfen.
-
Die erfindungsgemäße Anfragenachricht umfasst ein Token in einem Betreff der Anfragenachricht, mit Anwendung dessen in einem späteren Schritt die Anfragenachricht beantwortende Antwortnachrichten an der Zuordnungseinheit eintreffen. In einem Inhalt bzw. Payload der Anfragenachricht ist der Objektidentifikator enthalten.
-
Um die besagten – also die Anfragenachricht beantwortenden – Antwortnachrichten vom Publikations-/Abonnementdienst übermittelt zu bekommen, erfolgt in einem weiteren Schritt eine Einrichtung eines Abonnements, wobei das Abonnement einen Empfang von Antwortnachrichten umfasst, welche das Token im Betreff enthalten. Ein solches Abonnement wird im Publikations-/Abonnementdienst üblicherweise durch eine mit einer entsprechenden Nachricht an den Nachrichtenmakler gesendete Subscribe-Anforderung eingerichtet.
-
Nach Empfang einer oder mehrere Antwortnachrichten erfolgt eine Entnahme von mit der Antwortnachricht übermittelter Objektdaten aus der Antwortnachricht sowie eine in der Zuordnungseinheit erfolgende Zuordnung der Objektdaten zum Objektidentifikator.
-
Da in Folge des Abonnements Objektdaten durch Antwortnachrichten von verschiedenen Systemen übermittelt werden, bedeutet die erfindungsgemäße Zuordnung der Objektdaten zum Objektidentifikator auch, dass in Folge der Zuordnung auch eine Zuordnung des ursprünglich mit der Anfragenachricht gesendeten Objektidentifikator zu einem oder mehreren Objektidentifikatoren erfolgt, welche mit den Objektdaten einer oder mehrerer Antwortnachrichten übermittelt wurden. In Anwendung des erfindungsgemäßen Verfahrens kann also eine Zuordnung von unterschiedlichen Objektidentifikatoren erstellt werden, unter denen das selbe Objekt in unterschiedlichen, heterogenen Systemen bekannt ist. Auf diese Weise ist im Übrigen auch eine Zuordnung eines ursprünglich nicht eindeutigen Objektidentifikators, welcher mit der Anfragenachricht gesendet wurde, zu einem systemweit eindeutigen Objektidentifikator möglich, welcher mit den Objektdaten einer oder mehrerer Antwortnachrichten übermittelt wurde.
-
Die Erfindung schafft eine Lösung für das Problem, eine Zuordnung von Objektdaten zu einem Objektidentifikator in einer verteilten bzw. dezentralen Umgebung zu gewährleisten, indem erfindungsgemäß ein Publikations-/Abonnementdienst zur Anwendung kommt. Das Verfahren ermöglicht einen einheitlichen Abruf und Zugriff auf Objektdaten, die in heterogenen Systemen in proprietärer Weise gespeichert und verarbeitet werden.
-
In vorteilhafter Weise ermöglicht das erfindungsgemäße Verfahren, getrennte und unkoordinierte Objektdaten aus verschiedenen Backend-Systemen zusammenzuführen und mit Zusatzinformationen anzureichern, ohne Änderungen an den existierenden Backend-Systemen vornehmen zu müssen.
-
In vorteilhafter Weise wird durch die durch Dezentralität des Verfahrens eine erhöhte Toleranz gegen Ausfall einzelner externer Backend-Systeme und interner Komponenten erreicht.
-
Das erfindungsgemäße Verfahren reduziert Anschaffungskosten, da es für unterschiedlichste Anwendungsfälle einsetzbar und wiederverwendbar ist. Lediglich die Systemkomponenten, die den spezifischen Zugriff auf Objektdaten bereitstellen, müssen individuell implementiert werden.
-
Die Aufgabe wird weiterhin durch eine Zuordnungseinheit zur Zuordnung von Objektdaten zu einem Objektidentifikator gelöst.
-
Weitere Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
-
Eine besonders vorteilhafte Ausgestaltung der Erfindung wird durch eine Maßnahme geschaffen, bei der den mit der Antwortnachricht übermittelten Objektdaten ein systemweit eindeutiger Objektidentifikator entnommen wird und die erfindungsgemäßen Schritte der Publikation der Anfragenachricht, optional der Einrichtung eines Abonnements, sowie der Entnahme von mit mindestens einer Antwortnachricht übermittelten Objektdaten unter Hinzufügung dieses eindeutigen Objektidentifikators in einem Inhalt der Anfragenachricht wiederholt werden.
-
In diesem zwei- oder auch mehrstufigen Verfahren wird zunächst in Anwendung des erfindungsgemäßen Verfahrens ein Objektidentifikator verwendet, welcher nicht eindeutig in dem Sinne ist, dass er lediglich einem der eine Antwortnachricht zurücksendenden System bekannt ist. In den Objektdaten dieser Antwortnachricht kann aber ein Datensatz enthalten sein, welcher auch einen systemweit eindeutigen Objektidentifikator enthält. In Folge dessen erfolgt im Rahmen der zweiten Stufe eine Publikation einer zweiten Anfragenachricht an den Publikations-/Abonnementdienst, wobei die zweite Anfragenachricht ein Token in einem Betreff der Anfragenachricht sowie den systemweit eindeutigen Objektidentifikator in einem Inhalt der Anfragenachricht enthält. Da das Token zur Zuordnung einer oder mehrerer auf die Anfrage gesendeter Antwortnachrichten dient, kann für den Zweck der zweiten Anfragenachricht entweder das Token der ersten Anfragenachricht wiederverwendet werden oder auch, seitens der die zweite Anfragenachricht veranlassenden Zuordnungseinheit, ein neues Token definiert werden. Das Token gewährleistet in beiden Fällen einen paarweise eindeutigen Bezug im Publikations-/Abonnementdienst.
-
Im zweiten Fall, bei dem ein neues Token definiert wird, erfolgt erneut eine Einrichtung eines Abonnements im Publikations-/Abonnementdienst, das Abonnement umfassend einen Empfang von Antwortnachrichten, welche das neu definierte Token im Betreff enthalten. Im ersten Fall, bei dem das Token der ersten Anfragenachricht wiederverwendet wird, ist eine erneute Einrichtung eines Abonnements im Publikations-/Abonnementdienst unnötig und daher nur optional.
-
Schließlich erfolgt im Rahmen der zweiten Stufe eine Entnahme von einem oder mehreren übermittelten Objektdaten aus der einen oder mehreren Antwortnachrichten. Anhand der Objektdaten erfolgt erneut eine Zuordnung der Objektdaten zum Objektidentifikator. Diese Zuordnung umfasst auch eine Zuordnung unterschiedlicher Objektidentifikatoren zum systemweit eindeutigen Objektidentifikator.
-
Das zwei- oder auch mehrstufige – also in wiederholter Anwendung des Verfahrens gemäß dieser Ausführungsform – Verfahren schafft einen weiteren Vorteil der mehrstufigen Ausgestaltung der Erfindung. Während in der ersten Stufe eine Anfrage anhand eines ersten Objektidentifikators – welcher einem ersten Objekt bzw. Stammobjekt zugeordnet ist – eingeholt wird, können in der zweiten Stufe vorteilhaft auch Drittobjektdaten für weitere Drittobjekte bezogen werden, welche einen direkten Bezug zum Stammobjekt haben. Die zweite Stufe mit einer Anfrage unter Verwendung des systemweit eindeutigen Objektidentifikators ermöglicht eine Anfrage nach Objektdaten in der Antwortnachricht, in welchen ihrerseits Drittobjektdaten für weitere Drittobjekte enthalten sind, welche einen direkten untergeordneten oder übergeordneten Bezug zum Stammobjekt haben. Dies ist beispielsweise vorteilhaft, wenn zu einer Maschine als Stammobjekt auch deren Komponenten – also untergeordnete Drittobjekte – zugeordnet werden sollen.
-
Die zweite Stufe wird gemäß einer Ausgestaltung wiederholt auch auf untergeordnete Objektdaten angewandt, um Objekthierarchien zuzuordnen, die weitere Drittobjekte mit einem indirekten Bezug zum übergeordneten Stammobjekt enthalten. Im obigen Beispiel kommt eine Zuordnung einer solchen Objekthierarchie dann zum Tragen, wenn zu einer Maschine als Stammobjekt auch deren Komponenten mit einem direkten Bezug sowie weitere Subkomponenten der Komponenten zugeordnet werden sollen. Die Subkomponenten haben zu ihrer jeweiligen Komponente einen direkten, zum Stammobjekt – der Maschine – einen indirekten Bezug.
-
Im Folgenden werden weitere Ausführungsbeispiele und Vorteile der Erfindung anhand der Zeichnung näher erläutert. Dabei zeigt die einzige Figur eine schematische Strukturdarstellung einer Zuordnungseinheit welche zur Durchführung des erfindungsgemäßen Verfahrens Nachrichten im Rahmen eines Publikations-/Abonnementdienst mit anderen Funktionskomponenten austauscht.
-
Die FIG zeigt eine Zuordnungseinheit QU, welche beispielsweise in einer Integrationsschicht INT mit mehreren Funktionskomponenten in drahtloser und/oder drahtgebundener Weise kommuniziert. Die mit einem gestrichelten Kasten dargestellte Integrationsschicht INT ist einerseits in Abgrenzung zu einer – mit einem mit durchgezogener Linie gezeichneten Kasten dargestellten – Backend-Schicht BCK zu sehen, welche vornehmlich aus Rechnersystemen MDB, DDB zur dezentralen Datenhaltung und Datenverarbeitung, etwa im Sinne eines Cloud Computing, besteht. Andererseits ist die Integrationsschicht in Abgrenzung zu einer Erfassungseinheit SCN, etwa einem Barcode-Scanner, zu sehen. Die Erfassungseinheit erfasst einen den Objektidentifikator beinhaltenden Datenträger mit üblichen optischen oder digitalen Erfassungsmittel und übergibt den Objektidentifikator als digitales Datum an eine – nicht dargestellte – erste Schnittstelle der Zuordnungseinheit QU zur Entgegennahme des Objektidentifikators.
-
Im exemplarischen Beispiel der FIG sind neben der Zuordnungseinheit QU weitere Funktionskomponenten, nämlich ein Maschinencontroller MC, ein Dokumentationscontroller DC sowie ein Annotationscontroller AC dargestellt. Der Annotationscontroller AC kommuniziert innerhalb der Integrationsschicht mit einem Rechnersystemen ADB zur Datenhaltung und -verarbeitung, dessen Hauptaufgabe in einer Unterhaltung einer Datenbank zum Austausch von Daten mit dem Annotationscontroller AC dient. Im Gegensatz zu den dezentralen Rechnersystemen MDB, DDB ist der Annotationscontroller AC innerhalb der Integrationsschicht INT angeordnet. Die spezifische Anordnung in der Integrationsschicht INT soll jedoch lediglich zeigen, dass die Anordnung der jeweiligen Rechnersysteme aufgrund der Ubiquität der Datenzugangsmöglichkeiten innerhalb eines Cloud-Computing-Systems weitgehend beliebig ist.
-
Art und Anzahl dieser Funktionskomponenten ist nicht erfindungswesentlich und dient lediglich einer anschaulichen Darstellung eines Ausführungsbeispiels. Der Fachmann wird je nach Einsatzgebiet weitere oder andere Funktionskomponenten wählen.
-
In der Integrationsschicht INT ist weiterhin ein ereignisgesteuerter Publikations-/Abonnementdienst bzw. Publish-/Subscribe Service eingerichtet. Ein zentraler – nicht dargestellter – Nachrichtenmakler oder Message Broker dient als Vermittler von Nachrichten, welche zwischen den Funktionskomponenten innerhalb der Integrationsschicht INT ausgetauscht werden. Der Nachrichtenmakler ist eine Vermittlungsstelle zwischen nahezu allen in der Integrationsschicht INT ausgetauschten – mit einem Pfeil symbolisierten – Nachrichten zu verstehen, so dass die zeichnerische Darstellung einer direkten Pfeilverbindung zwischen zwei oder mehreren Kommunikationspartnern lediglich einer einfacheren Anschauung dient.
-
Der Publikations-/Abonnementdienst wird vorzugweise über das MQTT-Protokoll (Message Queuing Telemetry Transport) oder einer Variante davon bereitgestellt. MQTT ist ein ereignisgesteuertes Publish-Subscribe-Protokoll für einen Nachrichtenaustausch zwischen Funktionskomponenten. Dabei verbinden sich die einzelnen Funktionskomponenten mit dem zentralen Nachrichtenmakler bzw. MQTT-Broker, der als Informationsvermittler zwischen den Funktionskomponenten dient. Eine Funktionskomponente kann bestimmte Informationen über spezielle Nachrichtenkanäle verschicken (Publish) oder abonnieren (Subscribe). Die einzelnen Nachrichtenkanäle werden über einen Betreff bzw. Topic bezeichnet, wobei die Nachrichtenkanäle baumförmig organisiert sein können, entsprechend einer Mehrzahl an strukturierten Betreff-Einträgen. Das Protokoll MQTT ist datenagnostisch, also nicht auf ein bestimmtes Datenformat festgelegt. Es können sowohl Rohdaten einer einzelnen Messgröße als auch komplexe Datenstrukturen übertragen werden.
-
Vorzugsweise verarbeiten die Funktionskomponenten der Integrationsschicht INT die in den unterschiedlichen Backend-Systemen MDB, DDB gespeicherten externen Objektdaten, die einem jeweiligen externen Objektidentifikator zugeordnet sind, auf eine einheitliche Weise, indem sie externe Objektdaten einzelner Backend-Systeme MDB, DDB auslesen und mit Zusatzfunktionalität versehen können, externe Objektdaten einzelner Backend-Systeme MDB, DDB in Objekt-Hierarchien verknüpfen können sowie Werte in externen Objektdatensätze auf dem Backend-System verändern können.
-
Das Ziel der Integration besteht darin, externe Objektidentifikatoren auf eine einheitliche Weise aufzulösen und alle auf das Objekt bezogenen Daten und Informationen in Form normalisierten Objektdaten, beispielsweise bestehend aus vordefinierten Attribut-Werte Paaren, abzubilden. Mögliche Objektdaten umfassen beispielsweise Serviceinformationen zur Maschine, Live-Parameter der Maschine, Betriebsdaten der Maschine sowie die Stammdaten zur Maschine selbst (Typ, Modell, Baujahr, ...).
-
Eine Organisation der Objektdaten in Attribut-Werte Paaren beinhaltet grundlegende und typspezifische Eigenschaften des Objekts, u.a. Objektname, Objekttyp, Links auf Medieninhalte und eine eindeutige Identität, welche durch einen systemweit eindeutigen Objektidentifikator zugeordnet ist. Diese Objektdaten können dann einheitlich zwischen Komponenten der Integrationsschicht INT ausgetauscht und verarbeitet werden. Der besagte systemweit eindeutige Objektidentifikator, ist beispielsweise als UUID (Universally Unique Identifier) gemäß der technischen Anweisung RFC 4122 (»Request for Comment«) der IETF (Internet Engineering Task Force) realisiert.
-
Ein Objektdatensatz umfasst gegebenenfalls einen internen Objektidentifikator, also einen innerhalb der Integrationsschicht INT eindeutigen Objektidentifikator und/oder einen externen Objektidentifikator. Der interne Objektidentifikator ist im Allgemeinen ein systemweit eindeutiger Objektidentifikator. Der externe Objektidentifikator ist ein für bestimmte Funktionskomponenten außerhalb der Integrationsschicht INT gültige Objektidentifikator, welcher im Allgemeinen nicht notwendigerweise eindeutig im Sinne des oben Gesagten ist.
-
Gemäß dem erfindungsgemäßen Verfahren zur Zuordnung von Objektdaten zu einem Objektidentifikator ist zunächst eine Entgegennahme eines Objektidentifikators durch die Zuordnungseinheit QU vorgesehen. Die Zuordnungseinheit QU übernimmt den Objektidentifikator mit einer Nachricht 101 von der Erfassungseinheit SCN über die – nicht dargestellte – erste Schnittstelle der Zuordnungseinheit QU.
-
In einem weiteren Schritt erfolgt seitens einer – nicht dargestellten – zweiten Schnittstelle der Zuordnungseinheit QU eine Publikation einer Anfragenachricht bzw. DISCOVER-Nachricht an einen Publikations-/Abonnementdienst, welcher aufgrund eines bestehenden Abonnements durch den – nicht dargestellten – Nachrichtenmakler unter anderem als Nachricht
201 an den Maschinencontroller MC übermittelt wird. Neben dem Maschinencontroller MC erhalten alle Funktionskomponenten innerhalb der Integrationsschicht, welche ein Abonnement auf DISCOVER-Nachrichten eingerichtet haben eine solche DISCOVER-Nachrichten vom – nicht dargestellten – Nachrichtenmakler zugestellt. Die übrigen, an anderen Funktionskomponenten zugestellten DISCOVER-Nachrichten sind aus Übersichtsgründen nicht dargestellt. Die Anfragenachricht
201 umfasst ein Token in einem Betreff der Anfragenachricht sowie den Objektidentifikator in einem Inhalt der Anfragenachricht, etwa in der Form:
-
Die gezeigte Anfragenachricht bzw. DISCOVER-Nachricht ist gemäß ihrem Betreff eine Publikation, welche mit dem Token »Message Token« für eine paarweise Zuordnung auf eine diese Anfragenachricht beantwortende Antwortnachricht individualisiert ist. Im Inhalt oder Payload der DISCOVER-Nachricht wird der aufzulösende Objektidentifikator mit dem Attribut »extID« und dem Wert »001« übermittelt. Ausweislich des Attributs »extID« handelt es sich hierbei um einen externen Objektidentifikator, also einen innerhalb der Integrationsschicht bzw. systemweit nicht-eindeutigen Objektidentifikator.
-
In einem weiteren Schritt wird durch die Zuordnungseinheit QU ein Abonnement im Publikations-/Abonnementdienst eingerichtet, wobei das Abonnement einen Empfang von Antwortnachrichten, welche das Token im Betreff enthalten. Dieses Abonnement wird entweder explizit eingerichtet, das Abonnement kann aufgrund der zuvor gesendeten Anfragenachricht 201 jedoch auch automatisch durch den Publikations-/Abonnementdienst eingerichtet worden sein.
-
Der Maschinencontroller MC prüft nach Erhalt der Anfragenachricht
201, ob er den mit der Anfragenachricht
201 übermittelten Objektidentifikator »auflösen« kann. Dies bedeutet eine Prüfung, ob in einer system-internen oder system-externen und durch den Maschinencontroller MC zugreifbaren Datenbank ein Eintrag zu diesem Objektidentifikator besteht. Eine im Maschinencontroller gespeicherte Zuordnungstabelle der folgenden Form:
| extID | intID |
| ... | ... |
| ... | ... |
| 001 | UUID_001 |
| ... | ... |
ergibt eine mögliche Zuordnung des übermittelten aufzulösenden Objektidentifikator mit dem Attribut »extID« und dem Wert »001« zu einem systemweit eindeutigen Objektidentifikator mit dem Attribut »intID« und dem Wert »UUID_001«.
-
Die Speicherorganisation der genannten Zuordnungstabelle ist selbstverständlich nicht auf eine Tabelle festgelegt, denkbar sind auch Zuordnung aufgrund von Datenbanken oder in einem Arbeitsspeicher hinterlegte Daten. Dies gilt auch für alle im Folgenden beschriebenen Zuordnungstabellen.
-
Anschließend erfolgt eine Anfrage
210 an das – dem Maschinencontroller MC zugeordnete, jedoch in der Backend-Schicht BCK extern zugreifbare – Rechnersystem MDB, mit der zu dem mit der Anfragenachricht
201 übermittelten Objektidentifikator weitere Objektdaten abgerufen werden, etwa in der Form
query 001
wobei »001« dem Wert des Objektidentifikator mit dem Attribut »extID« entspricht. Auf dem Rechnersystem MDB werden Maschinendaten etwa in der folgenden Form vorgehalten:
| extID | name | model | ... |
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| 001 | M1 | Model_1 | ... |
| ... | ... | ... | ... |
-
Die exemplarischen Maschinendaten umfassen eine Bezeichnung bzw. »name« der Maschine, deren Baureihe bzw. »model« usw.
-
Die zum externen Objektidentifikator mit dem Wert »001« gespeicherte Objektdaten, bestehend aus der oben gezeigten Tabellenzeile mit einer Bezeichnung »M1« und einer Baureihe »Model_1« werden als Antwortnachricht 212 an den Maschinencontroller MC zurückgegeben. Da es sich hierbei um eine proprietäre, also nicht gemäß dem Publikations-/Abonnementdienst strukturierte Antwortnachricht 212, wird auf deren Struktur nicht weiter eingegangen.
-
Der Maschinencontroller MC publiziert nun eine Antwortnachricht
202 bzw. RESOLVE-Nachricht über den Publikations-/Abonnementdienst, welche aufgrund des im Betreff verwendeten Tokens an die Zuordnungseinheit QU vermittelt wird. Im Inhalt der Antwortnachricht
202 werden die Objektdaten zum angefragten Objektidentifikator übermittelt. Mit den Objektdaten wird auch ein interner Objektidentifikator bzw. systemweit eindeutiger Objektidentifikator in der Antwortnachricht
202 wie folgt mitgeliefert:
-
Nach Empfang der einen oder mehreren Antwortnachrichten 202 erfolgt seitens einer – nicht dargestellten – Bearbeitungseinheit der Zuordnungseinheit QU eine Entnahme der mit der Antwortnachricht übermittelten Objektdaten sowie eine Zuordnung der Objektdaten zum Objektidentifikator. Insbesondere kann die Zuordnungseinheit QU auch eine Zuordnung des vormals bekannten externen Objektidentifikators mit dem Wert »001« zum systemweit eindeutigen bzw. internen Objektidentifikator mit dem Wert »UUID_001« vornehmen.
-
Gemäß einer Ausgestaltung der Erfindung ist ein zweistufiges Verfahren zur Auflösung externer bzw. interner Objektidentifikatoren vorgesehen. Die erste Stufe entspricht dabei dem oben beschriebenen Verfahren mit dem Austausch der Nachrichten 201, 202.
-
In einer zweiten Stufe erfolgt eine weitere oder wiederholte mehrfache Auflösung mit dem externen Objektidentifikator und dem internen bzw. systemweit eindeutigen Objektidentifikator der Stammobjektdaten. Diese wiederholte Auflösung liefert zunächst Drittobjektdaten von Drittobjekten, die einen direkten untergeordneten oder übergeordneten Bezug zum Stammobjekt haben, in einer weiteren Wiederholung auch Drittobjektdaten von Drittobjekten, die einen indirekten untergeordneten oder übergeordneten Bezug zum Stammobjekt haben.
-
In einem weiteren Schritt erfolgt seitens der Zuordnungseinheit QU eine Publikation einer Anfragenachricht bzw. DISCOVER-Nachricht an einen Publikations-/Abonnementdienst, welcher aufgrund eines bestehenden Abonnements unter anderem als Anfragenachricht
203 an den Dokumentationscontroller DC und an den Annotationscontroller AC übermittelt wird:
-
In der oben gezeigten Anfragenachricht 203 wird neben dem bereits anfangs bekannten externen Objektidentifikator mit dem Attribut »extID« und dem Wert »001« nunmehr auch der interne bzw. systemweit eindeutige Objektidentifikator mit dem Attribut »intID« und dem Wert »UUID_001« als Gegenstand der Anfrage in einem Inhalt der Anfragenachricht 203 übersandt.
-
Der Dokumentationscontroller DC prüft nach Erhalt der Anfragenachricht
203, ob er den mit der Anfragenachricht
203 übermittelten Objektidentifikator auflösen kann. Im Dokumentationscontroller DC werden Verweise zu Servicedokumenten etwa in der folgenden Form vorgehalten:
| extID | extParentID | intID | intParentID |
| ... | ... | | |
| ... | ... | | |
| D13 | 001 | UUID_003 | UUID_001 |
| D14 | 001 | UUID_004 | UUID_001 |
| ... | ... | | |
-
Dabei werden zum externen Objektidentifikator mit dem Wert »001« Verweise auf zwei externe Objektidentifikatoren mit den Werten »D13« und »D14« vorgehalten, welche Subkomponenten der Maschine mit dem externen Objektidentifikator »001« sind. Die Verweise zum externen Objektidentifikator mit dem Wert »001« stehen in einer Spalte »extParentID«, gemäß der die unmittelbar darüberstehende hierarchische Ebene der Maschine mit dem externen Objektidentifikator mit dem Wert »001« hervorgeht. Auch in dieser Tabelle ist der externe Objektidentifikator mit dem Wert »001« einem internen Objektidentifikator mit dem Wert »UUID_001« zugeordnet, wie aus der Spalte »intParentID« hervorgeht.
-
Zum Bezug weiterer Objektdaten wird eine Anfrage 220 an das – dem Dokumentationscontroller DC zugeordnete, jedoch in der Backend-Schicht BCK extern zugreifbare – externe Rechnersystem DDB gesendet, welches mindestens einen der mit der Anfragenachricht 203 übermittelten Objektidentifikatoren enthält, beispielsweise den externen Objektidentifikator mit dem Attribut »extID« und dem Wert »001«:
query 001
-
Auf dem Rechnersystem DDB werden Verweise auf einen Speicherort von Servicedokumenten etwa in der folgenden Form vorgehalten:
| extID | extParentID | link | ... |
| ... | ... | | |
| ... | ... | | |
| D13 | 001 | http://server1.host1 | ... |
| D14 | 001 | http://server2.host2 | ... |
-
Die exemplarischen Daten umfassen einen Speicherort »link« für Servicedokumente mit einer bestimmten Hostadresse, beispielsweise »http://server1.host1 ...«
-
Die zum externen Objektidentifikator mit dem Wert »001« gespeicherten Speicherortdaten werden als Antwortnachricht 222 an den Dokumentationscontroller DC zurückgegeben. Da es sich hierbei um eine proprietäre, also nicht gemäß dem Publikations-/Abonnementdienst strukturierte Antwortnachricht 222 handelt, wird auf deren Struktur nicht weiter eingegangen.
-
Der Dokumentationscontroller DC publiziert nun eine Antwortnachricht
204 bzw. RESOLVE-Nachricht über den Publikations-/Abonnementdienst, welche aufgrund des im Betreff verwendeten Tokens an die Zuordnungseinheit QU vermittelt wird. Im Inhalt der Antwortnachricht
204 werden die Objektdaten zum angefragten Objektidentifikator übermittelt. Die Objektdaten setzen sich hierbei wie im Folgenden gezeigt aus den im Dokumentationscontroller DC sowie den im Rechnersystem DDB gespeicherten Daten, insbesondere den Speicherort »link« für Servicedokumente, zusammen. Die Antwortnachricht
204 hat z.B. folgende exemplarische Struktur:
-
Auch der Annotationscontroller AC prüft nach Erhalt der Anfragenachricht 203, ob er den mit der Anfragenachricht 203 übermittelten Objektidentifikator auflösen kann.
-
Im Annotationscontroller AC werden Annotationen zu Maschinen wie z.B. Bedienhinweisen durch Verweise auf ein Elternobjekt etwa in der folgenden Form vorgehalten:
| intID | intParentID |
| ... | ... |
| ... | ... |
| UUID_007 | UUID_001 |
| UUID_008 | UUID_001 |
| ... | ... |
-
Dabei werden zum internen Objektidentifikator mit dem Attribut »intParentID« und dem Wert »UUID_001« Verweise auf zwei interne Objektidentifikatoren mit den Werten »UUID_007« und »UUID_008« vorgehalten, welche beide Subkomponenten der Maschine mit dem internen Objektidentifikator »UUID_001« sind. Die Verweise zum internen Objektidentifikator mit dem Wert »UUID_001« stehen in einer Spalte »intParentID«, gemäß der die unmittelbar darüberstehende hierarchische Ebene der Maschine mit dem externen Objektidentifikator mit dem Wert »UUID_001« hervorgeht.
-
Zum Bezug weiterer Objektdaten wird eine Anfrage 230 an das Integrationsschicht-interne Rechnersystem ADB in der Integrationsschicht INT gesendet, welches Objektidentifikatoren der Subkomponenten der angefragten Maschine enthält, beispielsweise die internen Objektidentifikatoren mit dem Attribut »intID« und den Werten »UUID_007« und »UUID_007«:
query
UUID_007
UUID_008
-
Auf dem Rechnersystem ADB werden Annotationen zu den jeweiligen Subkomponenten etwa in der folgenden Form vorgehalten:
| intID | name | ... |
| ... | ... | ... |
| ... | ... | ... |
| UUID_007 | A1 | ... |
| UUID_008 | A2 | ... |
| ... | ... | ... |
-
Die exemplarischen Annotationen umfassen eine exemplarische Zeichenkette mit dem jeweiligen Wert »A1« bzw. »A2«.
-
Die zu den externen Objektidentifikatoren mit den Werten »UUID_007« und »UUID_007« gespeicherten Annotationen werden als Antwortnachricht 232 an den Annotationscontroller AC zurückgegeben. Da es sich hierbei um eine proprietäre, also nicht gemäß dem Publikations-/Abonnementdienst strukturierte Antwortnachricht 232 handelt, wird auf deren Struktur nicht weiter eingegangen.
-
Der Annotationscontroller AC publiziert nun eine Antwortnachricht
205 bzw. RESOLVE-Nachricht über den Publikations-/Abonnementdienst, welche aufgrund des im Betreff verwendeten Tokens an die Zuordnungseinheit QU vermittelt wird. Im Inhalt der Antwortnachricht
205 werden die Objektdaten zum angefragten Objektidentifikator übermittelt. Die Objektdaten setzen sich hierbei wie im Folgenden gezeigt aus den im Annotationscontroller AC sowie den im Rechnersystem ADB gespeicherten Daten zusammen. Die Antwortnachricht
205 hat dann folgende exemplarische Struktur:
-
In den beschriebenen Verfahren liegt die Verantwortung zur Auflösung externer bzw. interner Objektidentifikatoren dezentral verteilt bei den einzelnen Funktionskomponenten, welche die Objektidentifikatoren entweder unter Heranziehung einer externen Backend-Komponente – vgl. das Verfahren zur Ermittlung von Servicedokumenten unter Heranziehung des Backend-Rechnersystems DDB – oder in der Integrationsschicht selbst auflösen – vgl. das Verfahren zur Ermittlung von Annotationen unter Heranziehung des Rechnersystems ADB.
-
Für eine eindeutige Auflösung von Objektidentifikatoren und zur Zuordnung von externen zu internen Objektidentifikatoren ist eine persistente Speicherung der jeweiligen Objektidentifikatoren in den auflösenden Funktionskomponenten in der Integrationsschicht vorteilhaft. Die externen Objektidentifikatoren ermöglichen dabei den Zugriff auf Backend-Systeme.
-
Die zweite Stufe des oben erläuterten zweistufigen Verfahrens kann wiederholt auch auf untergeordnete Drittobjekte angewandt werden, um Objekthierarchien abzurufen, die Drittobjekte mit einem indirekten Bezug zum übergeordneten Stammobjekt enthalten.
-
Die Objektdaten umfassen ggf. einen externen oder internen Objektidentifikator eines direkt über- oder untergeordneten Drittobjekts, wodurch eine Objekthierarchie zugeordnet oder modelliert werden kann.
-
Erfindungsgemäße Ausgestaltungen dieses Verfahrens ermöglichen darüber hinaus eine Anreicherung von externen Objektdaten mit Zusatzinformationen und -funktionalitäten in der Integrationsschicht, ohne hierfür im Backend-System BCK Änderungen vornehmen zu müssen. Beispielsweise können Anmerkungen, Ergänzungen, Kommentare und Notizen zu einem extern gespeicherten Servicedokument ausschließlich intern in der Integrationsschicht INT als dem Servicedokument untergeordnete Objektdaten verwaltet werden.
-
Ein anderes Beispiel sind externe Dokumentationen zu einer Maschine aus unterschiedlichen Quellen (Audio, Videos, PDFs, etc.), die über ein intern verwaltetes Objekt zusammengefasst und den Objektdaten der Maschine zugeordnet werden können.
-
Das erfindungsgemäße Verfahren ist durch die verteilte Systemarchitektur robust gegenüber dem Ausfall oder der temporären Nichterreichbarkeit einzelner externer Backend-Systeme. Der Zugriff auf andere Backend-Systeme bleibt davon unberührt. Durch eine Verteilung der Funktionskomponenten auf einem Rechnercluster und eine Mehrfachauslegung von Komponenten ist das Verfahren darüber hinaus robust gegen den Ausfall interner Komponenten bzw. einzelner interner Rechnerknoten.
-
Die von den Backend-Systemen abgerufenen Objektdaten können darüber hinaus auch in den Komponenten oder Datenbanken in der Integrationsschicht INT zwischengespeichert werden, um die Ausfallsicherheit und die Performanz des Gesamtsystems weiter zu erhöhen.
-
Gemäß einer Ausgestaltung der Erfindung ist weiterhin vorgesehen, Werte in intern und extern gespeicherten Objektdatensätzen verändern zu können, beispielsweise um den Prozess- oder Aufgabenstatus in einem MES bzw. »Manufacturing Execution System« zu aktualisieren. Dazu wird folgendes Verfahren zur Änderung von Objektdaten vorgeschlagen:
Eine interne Funktionskomponente – also beispielsweise die Zuordnungseinheit QU, der Maschinencontroller MC, der Dokumentationscontroller DC oder der Annotationscontroller AC – oder auch eine beliebige andere erste Einheit innerhalb der Integrationsschicht INT, in welcher eine Anforderung für Änderung von Objektdaten ausgelöst wird, publiziert eine Änderungsanforderungsnachricht bzw. UPDATE-Nachricht an den Publikations-/Abonnementdienst. Diese Änderungsanforderungsnachricht umfasst in üblicher Weise einen Objektidentifikator sowie einen in den zugeordneten Objektdaten zu ändernden Datensatz der Objektdaten. Als Objektidentifikator kann dabei ein mit dem oben beschriebenen Verfahren aufgelöster interner Objektidentifikator verwendet werden. Der ändernde Datensatz kann dabei in Attribut-Werte Paaren angegeben sein.
-
In einem zweiten Schritt erfolgt dann ein Empfang der Änderungsanforderungsnachricht durch eine zum Abonnement von Änderungsanforderungsnachrichten eingerichtete zweite Einheit. Eine solche zweite Einheit prüft, ob die gewünschten Änderungen an den betreffenden Objektdaten bzw. dem betreffenden Objekt durchgeführt werden können. Bei positiven Ergebnis der Prüfung wird die Änderung durchgeführt, wobei diese Änderung – wie oben Fall erläutert – eventuell, im Fall extern gespeicherter Daten auf dem der zweiten Einheit zugordneten Backend-System erfolgt, ansonsten intern in der zweiten Einheit selbst. Nach Abschluss der Änderungen erfolgt durch die zweite Einheit eine Publikation einer Bekanntgabenachricht bzw. ADVERTISE-Nachricht an den Publikations-/Abonnementdienst, in der vorzugsweise die vollständig aktualisierten Objektdaten enthalten sind.
-
Gemäß einem optionalen Schritt wird diese Bekanntgabenachricht aufgrund des bestehenden Abonnements empfangen durch die erste Einheit, woraufhin diese eine Prüfung einer Übereinstimmung des zu ändernden Datensatzes mit den in der Bekanntgabenachricht bekanntgegebenen geänderten Objektdaten vornimmt. Die sendende erste Einheit ist optional dafür verantwortlich, bestätigte Änderungen abzugleichen und bei Bedarf durch ein Versenden von ADVERTISE-Nachrichten mit den aktuellen Objektdaten eine dezentrale Synchronisierung aller betroffenen Funktionskomponenten sicherzustellen.
-
Der erfinderische Beitrag liegt zusammenfassend in der Schaffung eines generischen, dezentralen Verfahrens, mit dem sich unterschiedliche einem Objekt zugeordneten Objektidentifikatoren auf einheitliche Weise verarbeiten lassen. Das Verfahren ermöglicht einen einheitlichen Abruf und Zugriff auf Objektdaten, die in heterogenen Backend-Systemen auf spezifische Weise gespeichert und verarbeitet werden.
-
Durch die Anwendung des erfindungsgemäßen Verfahrens ergeben sich folgende Vorteile:
- – Getrennte und unkoordinierte Objektdaten aus verschiedenen Backend-Systemen können zusammengeführt und mit Zusatzinformationen angereichert werden, ohne Änderungen an den existierenden Backend-Systemen vornehmen zu müssen.
- – Erhöhte Toleranz gegen einen Ausfall einzelner externer Backend-Systeme und interner Funktionskomponenten durch Dezentralität des Verfahrens.
- – Das Verfahren reduziert Anschaffungskosten, da es für die unterschiedlichsten Anwendungsfälle einsetzbar und wiederverwendbar ist. Lediglich Funktionskomponenten, welche einen spezifischen Zugriff auf Backend-Systeme bereitstellen, müssen individuell implementiert werden.
- – Proprietäre Komplettzugriffssysteme unterschiedlicher Hersteller für Objekte mit mehreren externen Objektidentifikatoren sind nicht mehr nötig. Der Entwicklungs- und Kostenaufwand für solche Systeme wird deutlich reduziert, weil nur die Anbindungen an Backend-System implementiert werden müssen.
- – Der Zeit- und Ressourcenaufwand zur Realisierung spezifischer Integrationslösungen entfällt.
- – Es können kostengünstige universelle Lesegeräte zur Erfassung verschiedenartiger Objektidentifikator beinhaltenden Datenträger in Form von Barcodes, QR-Codes, etc., eingesetzt werden, z.B. über eine in einer Smartwatch, in einem Smartphone oder in einem Handschuh eingebauten Kamera.
