-
Die vorliegende Erfindung betrifft ein Verfahren zum automatischen Beschreiben eines Geräts in einem vorgegebenen Format. Darüber hinaus betrifft die vorliegende Erfindung auch eine Vorrichtung zum automatischen Beschreiben eines Geräts sowie eine Geräteanordnung mit einem Gerät und einer Applikationseinrichtung, auf der eine Applikation implementiert ist.
-
Mit einer ständig wachsenden Anzahl von loT-Geräten (Internet of Things), z.B. in der Industrie oder im Energiesektor, stellt sich für Anwendungsentwickler die Herausforderung, Schnittstellen zu schaffen und mit einer heterogenen Landschaft verschiedener Geräte und Gerätehersteller mit offenen und proprietären Protokollen zu kommunizieren. Typische Geräte von industriellen Anlagen sind etwa Sensoren, elektromechanische Komponenten, Kommunikationseinheiten und Antriebe. Bekannte Protokolle, mit denen die Kommunikation zwischen diesen Komponenten bewerkstelligt wird, sind etwa HTTP, JSON, Modbus, XML und so weiter.
-
Bei neuen Projekten verursacht der Aufwand für die Implementierung von Protokolladaptern für Geräte einen hohen Implementierungsaufwand und kann das Gesamtziel einer Lösung zunichtemachen. Ein Energiemanagementsystem muss zum Beispiel Messwerte ablesen und Sollwerte an einer Vielzahl von Geräten, wie Batteriespeicher, Wechselrichter, Ladestationen und so weiter senden.
-
Der Web-of-Things-Ansatz (vgl. 1) ermöglicht eine rationalisierte Konnektivität für Anwendungen 2 (Apps) mit verschiedenen Geräten 1 und deren spezifischer gerätegerichteter Konnektivität. Dabei werden die Geräte 1 und ihre Kommunikationsschnittstelle durch sogenannte Dingbeschreibungen 3 (TD: thing description) abstrahiert, die die Eigenschaften, Aktionen und Ereignisse für ein einzelnes Gerät definieren (z.B. Temperaturmessung ablesen, Wirkleistungssollwert einstellen etc.). Die Anwendungen 2 müssen also nicht mehr direkt mit proprietären Formaten 4 beziehungsweise proprietären Protokollen zurechtkommen, sondern sie können auf vorgegebene beziehungsweise standardisierte Protokolle und Formate zurückgreifen.
-
Obwohl ein solcher Ansatz die Konnektivitätsherausforderung für Anwendungsentwickler in Bezug auf die Anwendungen 2 löst, muss jedoch jedes Gerät 1 zunächst in einem geeigneten Format beschrieben werden (Dingbeschreibung). Dies erfordert viel Arbeit, da jeder neue Gerätetyp manuell mit allen vom Hersteller bereitgestellten Konnektivitätsinformationen (z.B. direkt aus dem Handbuch des Herstellers) in ein System eingebunden werden muss.
-
Bei Lösungen ohne einen Web-of-Things-Ansatz müssten die Anwendungsentwickler den Konnektivitätsstack (Verbindungstabelle für Eingangs-und Ausgangsanschlüsse) für jedes Gerät im Projekt manuell implementieren und jedes Gerät anhand des Handbuchs konfigurieren. Mit dem Web-of-Things-Ansatz (insbesondere https://www.w3.org/WoT/) müsste ein Inbetriebnahmetechniker nach wie vor manuell eine Dingbeschreibung 3 aus dem Handbuch des Geräts ausfüllen, die manchmal mehrere hundert Eigenschaften enthält.
-
In der
US 2022 / 0 058 502 A1 ist ein Gateway zur Transformation einer Beschreibung von industrieller Prozessausrüstung in ein semantisch angereichertes und graphenbasiertes Informationsmodell für Automatisierungszwecke offenbart.
-
Die
WO 2019 / 240 743 A1 offenbart ein System zum Management des vollständigen Lebenszyklus eines Feldgeräts, bei dem auf eine verknüpfte Onotologie mit Informationen von relevanten Standards und auf ein Regel-Validierungs-Modell, das die Konformität eines Geräts mit der Ontologie überprüft, zurückgegriffen wird. Dabei wird eine Gerätebeschreibung in ein digitales Modell teilweise auf Grundlage der Ontologie überführt.
-
In der
DE 20 2021 106 310 U1 ist ein computerimplementiertes Prozessmodul für eine modulare Industrieanlage offenbart, welches eine Prozessorchestrierungsschicht umfasst, die durch Interpretation eines Modulbeschreibungspaket in die Lage versetzt wird, das computerimplementierte Prozessmodul in gleicher Weise anzusprechen wie mindestens ein Wirk-Prozessmodul. Das Wirk-Prozessmodul ist dabei dazu ausgebildet, physikalisch auf einen von der modularen Industrieanlage ausgeführten Prozess einzuwirken.
-
Unabhängig vom grammatikalischen Geschlecht eines bestimmten Begriffes sind Personen mit männlicher, weiblicher oder anderer Geschlechteridentität mit umfasst.
-
Die Aufgabe der vorliegenden Erfindung besteht somit darin, das Einbinden eines Geräts in ein komplexes System einfacher zu gestalten.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren und eine Vorrichtung gemäß den unabhängigen Ansprüchen gelöst. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen.
-
Entsprechend der vorliegenden Erfindung wird somit ein (computerimplementiertes) Verfahren zum automatischen Beschreiben eines Geräts in einem vorgegebenen Format bereitgestellt. Wie eingangs erwähnt, kann es sich bei dem Gerät beispielsweise um ein Messgerät (Sensor), ein elektromechanisches Element (z.B. Roboterarm) ein Kommunikationsgerät (z.B. Sender/Empfänger), einen Antrieb (z.B. Elektromotor) und dergleichen handeln. Das Gerät soll insbesondere im Hinblick auf seine Konnektivität (Verbindungsanschlüsse) automatisch beschrieben werden. Das Beschreiben des Geräts erfolgt also nicht manuell, sondern mithilfe eines Automatismus (z.B. implementiert auf einem Computer).
-
Zunächst erfolgt ein Bereitstellen einer Gerätebeschreibung in einem proprietären Format. Die Gerätebeschreibung betrifft physikalische Größen des Geräts, insbesondere betreffend Eingangs-und Ausgangsanschlüsse. Beispielsweise wird entsprechend der Gerätebeschreibung eine aktuelle Temperatur in Grad Celsius mit zwei Bytes dargestellt. In ähnlicher Weise kann entsprechend einem proprietärem Format eine Blindenergie in VAh mit 4 Bytes angegeben werden.
-
Außerdem erfolgt ein Bereitstellen einer Beispielsbeschreibung in dem proprietärem Format zusammen mit einer transformierten Beispielsbeschreibung, die inhaltlich der Beispielsbeschreibung in dem vorgegebenen Format entspricht. Eine Beispielsbeschreibung kann ein beliebiges Beispielgerät betreffen, wie etwa einen Temperatursensor. Für die Beispielsbeschreibung wird wie für die obige Gerätebeschreibung beispielsweise eine Beschreibung (z.B. „Maximalstrom“), eine Einheit (z.B. A), eine Byte-Länge (z.B. 2) und gegebenenfalls weitere Größen, wie Register, Geräteversion und dergleichen bereitgestellt. Zu dieser Beispielsbeschreibung wird eine inhaltsgleiche transformierte Beispielsbeschreibung in dem vorgegebenen Format (z.B. JSON-Format) bereitgestellt. Es werden somit zwei inhaltsgleiche Beispielsbeschreibungen in zwei verschiedenen Formaten (proprietäres Format und vorgegebenes Format) bereitgestellt, aus denen die Formattransformation hervorgeht.
-
In einem weiteren Schritt erfolgt ein Eingeben der Gerätebeschreibung in dem proprietären Format, der Beispielsbeschreibung in dem proprietären Format und der transformierten Beispielsbeschreibung in dem vorgegebenen Format in ein großes Sprachmodell (LLM: Large Language Model). Neben diesen drei Beschreibungen als Eingangsgrößen wird in üblicher Weise auch eine Anweisung in das große Sprachmodell eingegeben, gemäß der die Gerätebeschreibung analog zu den Beispielsbeschreibungen von dem proprietären Format in das vorgegebene Format zu transformieren ist. Gegebenenfalls können auch weitere Anweisungen in das große Sprachmodell eingegeben werden.
-
Es erfolgt ein Ausgeben der Gerätebeschreibung in dem vorgegebenen Format durch das große Sprachmodell. Aufgrund der durch die Beispielsbeschreibungen definierten Formattransformation ist es dem großen Sprachmodell möglich, die Gerätebeschreibung in dem proprietären Format in eine neuartige Gerätebeschreibung in dem vorgegebenen Format zu transformieren. Es ist nicht notwendig, dass das große Sprachmodell eine langwierige Trainingsphase durchläuft. Vielmehr kann durch die Beispieleingabe das große Sprachmodell instantan genutzt werden.
-
In vorteilhafter Weise ergibt sich somit ein benutzerfreundlicher Ansatz, der ein großes Sprachmodell nutzt, um automatisch gültige Dingbeschreibungen direkt aus Anlagenhandbüchern und dergleichen zu generieren. Der vorgeschlagene Ansatz wird den Aufwand für die Inbetriebnahme erheblich reduzieren. Der Hauptvorteil des vorgeschlagenen Ansatzes besteht darin, dass die Anbindung neuer Geräte (z.B. bei der Inbetriebnahme eines Industriebaus) vollständig automatisiert werden kann. Im Vergleich zu herkömmlichen Ansätzen reduziert dies den Aufwand für die Inbetriebnahme eines neuen Standorts drastisch. Mit diesem Ansatz können ungenutzte Potenziale für datengesteuerte Anwendungsfälle, z.B. Energiemanagementsystem, einfach erschlossen werden, um z.B. die Effizienz der Energienutzung zu steigern.
-
In einem Ausführungsbeispiel ist vorgesehen, dass eine Rohgerätebeschreibung automatisch erfasst und aus der Rohgerätebeschreibung die Gerätebeschreibung in dem proprietären Format automatisch extrahiert und bereitgestellt wird. Bei der Rohgerätebeschreibung handelt es sich beispielsweise um eine Bilddatei, die aus einem Handbuch gescannt ist. Das Erfassen der Rohgerätebeschreibung erfolgt hier also (teil-)automatisch z.B. durch einen Scanner.
-
Anschließend wird aus der Rohgerätebeschreibung (z.B. Bilddatei) die aktuelle Gerätebeschreibung in dem proprietären Format z.B. auf Basis von automatischer Texterkennung extrahiert. Dem Bereitstellen der Gerätebeschreibung geht somit ein automatisches Erfassen mit zwei automatischen Schritten voraus, nämlich dem Erfassen der Rohgerätebeschreibung und dem Extrahieren der Gerätebeschreibung daraus. In vorteilhafter Weise kann somit ein hochautomatisierter Erfassungsprozess bereitgestellt werden.
-
Gemäß einem weiteren Ausführungsbeispiel handelt es sich bei dem vorgegebenen Format um ein standardisiertes Format. Das vorgegebene Format, in das die Gerätebeschreibung transformiert wird, ist somit ein standardisiertes Format. Dies bedeutet, dass beispielsweise bei der Inbetriebnahme die Entwickler entsprechender Anwendungen auf standardisierte Formate der Gerätebeschreibungen zurückgreifen können.
-
Bei einem weiteren Ausführungsbeispiel des erfindungsgemäßen Verfahrens enthält die Gerätebeschreibung Anschlussdaten und/oder Verbindungsdaten spezifisch für das Gerät. Wie oben bereits angedeutet wurde, kann die Gerätebeschreibung somit Verbindungsdaten, beispielsweise in Bezug auf Eingabe oder Ausgabe oder in Bezug auf Register, Ports und dergleichen beinhalten. Generell können mit der Gerätebeschreibung alle bekannten physikalischen Größen beschrieben werden.
-
Die Gerätebeschreibung kann gemäß einem weiteren Ausführungsbeispiel aus einem Handbuch durch das große Sprachmodell zum Bereitstellen extrahiert werden. Beispielsweise kann das gesamte Handbuch in einem PDF-Format vorliegen. Unter Umständen wird dann das gesamte Handbuch den großen Sprachmodell zur Verfügung gestellt. Gegebenenfalls erkennt ein geeigneter Extraktionsalgorithmus in dem Handbuch eine Anschlusstabelle, die dann extrahiert und in das vorgegebene Format transformiert wird.
-
Bei einem weiteren Ausführungsbeispiel ist vorgesehen, dass die von dem großen Sprachmodell ausgegebene Gerätebeschreibung in dem vorgegebenen Format in Bezug auf das vorgegebene Format automatisch validiert wird. In diesem Validierungsschritt wird also überprüft, ob das vorgegebene beziehungsweise standardisierte Format in der Gerätebeschreibung auch eingehalten ist. Diese Validierung kann automatisiert mit einem Validierungsalgorithmus erfolgen.
-
Entsprechend einem weiteren Ausführungsbeispiel wird die von dem großen Sprachmodell ausgegebene Gerätebeschreibung in dem vorgegebenen Format in einem Validierungsdialog mit einem Nutzer validiert. Dies bedeutet, dass eine Validierungsschnittstelle vorgesehen sein muss, die es erlaubt, dass der Nutzer die Gerätebeschreibung hinsichtlich des Formats überprüft und gegebenenfalls ergänzt oder ändert. Damit kann sichergestellt werden, dass die automatisch erstellte Gerätebeschreibung in dem vorgegebenen Format auch fehlerfrei ist.
-
In einem weiteren Ausführungsbeispiel ist vorgesehen, dass mindestens eine weitere Beispielsbeschreibung in dem proprietären Format und eine weitere transformierte Beispielsbeschreibung für das Ausgeben der Gerätebeschreibung in dem vorgegebenen Format in das große Sprachmodell eingegeben wird. Dies bedeutet, dass das Sprachmodell für die Formattransformation nicht nur ein einziges Beispiel, sondern mindestens zwei Beispiele erhält. Damit kann die Sicherheit bei der Formattransformation erhöht werden.
-
Gemäß einem anderen Ausführungsbeispiel erfolgt das Ausgeben der Gerätebeschreibung in dem vorgegebenen Format in einem JSON-Format. Das JSON-Format ist ein weit verbreitetes Format für die Beschreibung einer Konnektivität. Damit kann die Dingbeschreibung in einem sehr verbreiteten Format erfolgen, wodurch die Anwendbarkeit des Verfahrens universeller wird.
-
Bei einem weiteren Ausführungsbeispiel ist vorgesehen, dass von einem Nutzer zusätzlich zu der Gerätebeschreibung in dem proprietären Format eine oder mehrere Anweisungen in das große Sprachmodell für das Ausgeben der Gerätebeschreibung in dem vorgegebenen Format eingegeben werden. Es wird also zusätzlich zu der Gerätebeschreibung und den mindestens zwei Beispielbeschreibungen wenigstens eine Nutzeranweisung in das große Sprachmodell eingegeben. Derartige Anweisungen können sich beispielsweise auf den Typ von Parametern beziehen, die in der auszugebenden Gerätebeschreibung vorkommen dürfen. Ebenso kann sich eine Anweisung darauf beziehen, welche Parameter (Namen) nicht verwendet werden dürfen. Darüber hinaus kann sich eine Anweisung auch darauf beziehen, bei Bedarf Parameter wie Maximum oder Minimum einzufügen. Durch derartige Anweisungen wird das große Sprachmodell genau angewiesen, wie die Ausgabe zu erfolgen hat.
-
Es kann somit ein Verfahren zum Kommunizieren einer Applikation beziehungsweise Anwendung mit einem Gerät durch Beschreiben des Geräts in einem vorgegebenen Format gemäß einem Verfahren, wie es oben beschrieben wurde, und kommunizieren der Applikation mit dem Gerät auf der Basis der Gerätebeschreibung in dem vorgegebenen Format bereitgestellt werden. Zwischen einer Anwendung und einem Gerät kann damit eine Kommunikation realisiert werden, die auf einem vorgegebenen Verbindungsprotokoll und nicht auf einem proprietären Verbindungsprotokoll basiert.
-
Bei dem Kommunikationsverfahren kann weiter vorgesehen sein, dass das Kommunizieren der Applikation mit dem Gerät ein Übertragen eines Werts eines Betriebsparameters des Geräts von dem Gerät zu der Applikation und/oder von der Applikation zu dem Gerät beinhaltet. Auf diese Weise können Werte zwischen Applikation und Gerät ausgetauscht werden. Beispielsweise kann eine Applikation einen Messwert von einem Gerät auslesen oder es kann eine Applikation an einem Gerät eine Geräteeinstellung vornehmen.
-
Die oben formulierte Aufgabe kann erfindungsgemäß auch gelöst werden durch eine Vorrichtung zum automatischen Beschreiben eines Geräts in einem vorgegebenen Format, aufweisend eine Speichereinrichtung zum Bereitstellen einer Gerätebeschreibung (die physikalische Größen des Geräts beschreibt) in einem proprietären Format und zum Bereitstellen eine Beispielsbeschreibung in dem proprietären Format zusammen mit einer transformierten Beispielsbeschreibung, die inhaltlich der Beispielsbeschreibung in dem vorgegebenen Format entspricht, eine Prozessoreinrichtung, auf der ein großes Sprachmodell implementiert ist, wobei die Gerätebeschreibung in dem proprietären Format, die Beispielsbeschreibung in dem proprietären Format und die transformierte Beispielsbeschreibung von der Speichereinrichtung in die Prozessoreinrichtung eingebbar ist, und wobei von der Prozessoreinrichtung die Gerätebeschreibung in dem vorgegebenen Format mittels des Großen Sprachmodells ausgebbar ist.
-
Die oben im Zusammenhang mit dem erfindungsgemäßen Verfahren aufgezählten Vorteile und Weiterbildungsmöglichkeiten gelten sinngemäß auch für die erfindungsgemäße Vorrichtung. Dementsprechend können die genannten Verfahrensmerkmale als funktionelle Merkmale entsprechender Mittel beziehungsweise Einrichtungen der Vorrichtung gesehen werden.
-
Des Weiteren kann erfindungsgemäß eine Geräteanordnung bereitgestellt werden mit einem Gerät, einer Applikationseinrichtung, auf der eine Applikation implementiert ist und einer soeben genannten Vorrichtung, mit der das Gerät in dem vorgegebenen Format beschreibbar ist, sodass auf Basis des vorgegebenen Formats eine Kommunikation zwischen der Applikation und dem Gerät ermöglicht ist. Bei der Applikationseinrichtung kann es sich um einen Computer oder eine ähnliche Recheneinrichtung handeln.
-
Die oben genannte Aufgabe wird darüber hinaus durch ein Computerprogrammprodukt mit Programmcodemitteln gelöst, welche eine elektronische Recheneinrichtung dazu veranlassen, wenn die Programmcodemittel von der elektronischen Recheneinrichtung abgearbeitet werden, ein Verfahren nach oben genannter Art durchzuführen. Weiterhin kann ein computerlesbares Speichermedium mit zumindest einem Computerprogrammprodukt nach obiger Art bereitgestellt werden.
-
Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
-
Die vorliegende Erfindung wird nun anhand der beigefügten Zeichnungen näher erläutert, in denen zeigen:
- 1 eine schematische Ansicht eines Web-of-Things-Ansatzes zur Vereinfachung der Konnektivität von Geräten;
- 2 eine schematische Ansicht eines Verfahrensbeispiels gemäß der vorliegenden Erfindung; und
- 3 ein Beispiel eines grafischen User-Interface für die Erstellung einer Gerätebeschreibung in einem vorgegebenen Format.
-
Die nachfolgend näher geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsformen der vorliegenden Erfindung dar.
-
Die nachfolgenden Beispiele basieren auf Beschreibungen mit dem Web-of-Things-Standard (Dingbeschreibungen). Die vorliegende Erfindung kann jedoch auch mit anderen IoT-Konnektivitätsansätzen realisiert werden.
-
Gemäß 2 liegt für das Gerät 1 ein Gerätehandbuch 5 vor. Das Gerätehandbuch 5 kann beispielsweise in einem Tabellenformat, einem PDF-Format, einem HTML-Format oder dergleichen vorliegen. Gegebenenfalls liegt auch nur ein Abschnitt des Gerätehandbuchs 5 in einem entsprechenden Format vor. Nachfolgend wird auch ein derartiger Abschnitt als Gerätehandbuch 5 verstanden.
-
In einem optionalen Schritt des Ausführungsbeispiels von 2 erfolgt die Extraktion 6 einer Verbindungsspezifikation aus dem Gerätehandbuch 5. Es wird also das Gerätehandbuch 5 eines in ein System einzubindendes Geräts 1 (z.B. eine PDF-Datei, eine HTML-Seite, eine Excel-Tabelle) verwendet, um die relevanten Informationen für die Konnektivität des Geräts 1 vorzugsweise in einem Tabellenformat zu extrahieren. Alternativ könnte ein großes Sprachmodell (nachfolgend kurz LLM genannt) verwendet werden, um die gesamte PDF-Datei abzufragen und die entsprechende Tabelle zu finden. Dies erfordert jedoch einen zusätzlichen Aufruf des LLM mit gegebenenfalls einer vorgegebenen Menge an verwendbaren Token/Posten.
-
Die nachfolgende Tabelle 1 zeigt ein Beispiel für eine solche Spezifikation. Die Tabelle 1 kann in dem dargestellten Format in dem Handbuch wiedergegeben sein.
-
Mess- und Zustandsvariablen
-
Tabelle
| Register | Länge | Beschreibung | Format | Einheit | POC1000 | 5ST3COM | 5SL6COM |
| 3072 | 2 | Current temperature | FP32 | °C | x | x | x |
| 3074 | 2 | Average temperature | FP32 | °C | x | x | x |
| 3076 | 2 | Actual current L | FP32 | A | - | - | x |
| 3078 | 2 | Average current L | FP32 | A | - | - | x |
| 3080 | 2 | Maximum current L | FP32 | A | - | - | x |
| 3082 | 2 | L-N voltage | FP32 | V | - | - | x |
| 3084 | 2 | Line frequency | FP32 | Hz | - | - | x |
| 3086 | 2 | Active power {L} | FP32 | W | - | - | x |
| 3088 | 2 | Apparent power {L} | FP32 | VA | - | - | x |
| 3090 | 2 | Total reactive powerQtot {L} | FP32 | V | - | - | x |
| 3092 | 2 | Power factor {L} | FP32 | | - | - | x |
| 3094 | 4 | Imported activeenergy | FP64 | Wh | - | - | x |
| 3098 | 4 | Exported activeenergy | FP64 | Wh | - | - | x |
| 3102 | 4 | Imported reactiveenergy | FP64 | varh | - | - | x |
| 3106 | 4 | Exported reactiveenergy | FP64 | varh | - | - | x |
| 3110 | 1 | Status of the(mounted) | U16 | | - | x | x |
-
Die dargestellte Tabelle kann als Bild oder bereits in einem Tabellenformat vorliegen. Abhängig davon ist eine Umwandlung in ein Tabellenformat notwendig oder nicht. Die Umwandlung in das Tabellenformat kann entweder manuell erfolgen, d.h. durch Kopieren des Inhalts und Formatieren mit einem Tabellenprogramm wie Excel, oder durch automatische Umwandlung der Tabelle mit Hilfe eines LLM (z.B. ChatGPT). Im letzteren Fall konvertiert das LLM eine Texteingabe in ein Tabellenformat. Aus dieser Tabelle können nun die Konnektivitätsinformationen extrahiert werden, die in den folgenden Schritten ausgewertet werden.
-
Aus der Tabelle mit den Konnektivitätsinformationen muss zunächst ein sogenanntes „Prompt“ für das LLM erstellt werden.
-
Aus dem Gerätehandbuch 5 wurde also beispielsweise eine Rohgerätebeschreibung mit den Verbindungsdaten des Geräts 1, beispielsweise als PDF-Datei automatisch erfasst (z.B. durch Scannen). Aus der Rohgerätebeschreibung wird durch den Extraktionsschritt 6 die Gerätebeschreibung mit der Verbindungsspezifikation extrahiert. Letztere liegt damit in einem proprietären Format vor.
-
Nun wird ein Prompt für ein LLM (z.B. ChatGPT erzeugt. Hierzu ist ein Aufbereitungsschritt 7 in 2 vorgesehen. Hierdurch wird ein Teil des Prompts für das LLM 8 generiert, der Informationen des einzubindenden Geräts 1 enthält. Ein weiterer Teil des Prompts besteht aus Trainingsbeispielen 9.
-
Beispielsweise weist ein Standardprompt eine Folge von zwei Trainingsbeispielen mit jeweils gewünschter Ausgabe zu einer jeweils korrespondierenden Eingabe auf. Die Eingabe ist als ein Wörterbuch der Werte einer Zeile der Dokumentationstabelle beziehungsweise Gerätebeschreibung definiert. Es werden keine spezifischen Namen von Spalten verlangt. Wenn der jeweilige Name eine Bedeutung hat, wird er vom LLM korrekt verarbeitet. Die Ausgabe ist beispielsweise eine Eigenschaftsbeschreibung in einem JSON-Format.
-
Der Nutzer hat in dem Aufbereitungsschritt 7 die Möglichkeit, zusätzliche Anweisungen anzugeben, wie z.B. allgemeine Anweisungen (beispielsweise „alle ganzzahligen Variablen sollen als Gleitkommazahlen beschrieben werden“) oder ein zusätzliches Beispiel.
-
In einem weiteren Schritt erfolgt das Aufrufen des LLM 9. Der vorbereitete Prompt einschließlich der Gerätebeschreibung und des einen oder der mehreren Trainingsbeispiele 8 wird dem LLM 9 zugeführt. Gegebenenfalls besteht eine Einschränkung in Bezug auf die maximale Anzahl der Eingabe-Token des LLM 9. Unter Umständen wird der Prompt aufgeteilt, wenn die erforderliche Gerätekonfiguration beziehungsweise Gerätebeschreibung länger ist als die maximal mögliche Tokengröße.
-
Das LLM 9 generiert aus dem Prompt eine vorläufige Dingbeschreibung 3'.
-
In einem optionalen Validierungsschritt 10 wird die generierte vorläufige Dingbeschreibung 3' gegenüber einem Standard (z.B. Web-of-things) validiert, woraus sich eine validierte Dingbeschreibung 3 ergibt. Diese Validierung geschieht, um generell das Format der generierten Dingbeschreibung zu überprüfen. Sollte das LLM 9 relevante Informationen in der Tabelle nicht erkennen, kann zusätzlicher Kontext durch den Nutzer hinzugefügt und mit dem LLM 9 in einem optionalen Validierungsdialog 11 iteriert werden. Aus den beiden optionalen Validierungsschritten 10 und 11 resultiert also die validierte Dingbeschreibung 3. Prinzipiell könnte natürlich auf die Validierung verzichtet werden, wenn das LLM 9 direkt die Dingbeschreibung 3 ausgibt.
-
In einem weiteren optionalen Validierungsschritt könnte die tatsächliche Konnektivität zu einem realen Gerät getestet werden.
-
Die generierte Dingbeschreibung 3 des Geräts 1 kann direkt von der Anwendung 2 für die Schnittstelle zum Gerät 1 verwendet werden. Beispielsweise können so mithilfe der Anwendung 2 Messwerte aus dem Gerät 1 ausgelesen werden. Ebenso können nun mittels der Applikation beziehungsweise Anwendung 2 über die Dingbeschreibung 3 Einstellwerte in das Gerät 1 geschrieben werden.
-
Zum weitergehenden Verständnis des erfindungsgemäßen Ansatzes wird das erfindungsgemäße Verfahren anhand eines Prozesses des Einbindens (onboarding) einer einzelnen Eigenschaft einer neuen Batterie veranschaulicht. Es wird ein Standard-Prompt-Template für ein beliebiges Gerät verwendet. Der nachfolgende Prompt besteht aus einem mehrzeiligen Anweisungsteil, gefolgt von einem „Input“-Teil und einem „Output“-Teil.
-
Die einzigen gültigen Beschreibungen für den Parameter „type“ sind „integer“, „boolean“, „number“ und „string“.
-
Die einzigen gültigen Beschreibungen für den Parameter „modbus:type“ in der Beschreibung von „forms“ sind „integer“, „boolean“, „number“ und „string“.
-
Die einzigen gültigen Bezeichnungen für den Parameter „modbus:entity“ in der Beschreibung von „forms“ sind „coil“, „discreteinput“, „inputregister“ und „holdingregister“.
-
Es ist absolut verboten, einen Parameter ‚enum‘ zu nennen.
-
Die Parameter ‚maximum‘ und ‚minimum‘ können bei Bedarf hinzugefügt werden.
-
Der „Input“-Teil wird aus der Gerätebeschreibung, d.h. der aus dem Gerätehandbuch 5 extrahierten Tabelle erzeugt. Der „Output“-Teil zeigt die Daten des „Input“-Teils in einem transformierten Format, z.B. dem JSON-Format. Das Beispiel mit „Input“-Teil und „Output“-Teil soll dem LLM 9 zeigen, wie die Formattransformation stattfinden soll.
-
Anhand von 3 wird nun aufgezeigt, wie das erfindungsgemäße Verfahren beispielsweise mithilfe einer einfachen Bedienschnittstelle (GUI) genutzt werden kann.
-
In einem ersten Schritt erfolgt das Extrahieren von Konnektivitätsinformationen. Dazu wird in einem Textbereich 12 eine Zeile einer Dokumentationstabelle eines Gerätehandbuchs (beispielsweise aus einer PDF-Datei kopiert) eingefügt. Es handelt sich dabei um eine Rohgerätebeschreibung. Sie wird in eine darunterstehende Tabelle 13 umgewandelt, die ausgewertet werden kann. Diese Tabelle 13 kann als Gerätebeschreibung bezeichnet werden.
-
Durch Anklicken der Schaltfläche 14 „Generate json“ wird die Tabelle 13 in eine geeignete Eingabe für das LLM umgewandelt. Das LLM 8 wird mit dem oben dargestellten Prompt gestartet. Dadurch wird die Dingbeschreibung erstellt. In dem Beispiel von 3 wird als Output beziehungsweise Ausgabe 15 eine JSON-Datei erstellt. Sie ist im unteren Bereich von 3 zu erkennen.
-
Mit der generierten Dingbeschreibung der Batterie gemäß der Ausgabe 15 kann jede Anwendung (z.B. ein Energiemanagementsystem) direkt Messungen empfangen und Sollwerte an das Gerät senden, ohne sich um das zugrundeliegende Verbindungsprotokoll kümmern zu müssen.
-
Bezugszeichenliste
-
- 1
- Gerät
- 2
- Anwendung
- 3
- Dingbeschreibung
- 3'
- vorläufige Dingbeschreibung
- 4
- Format
- 5
- Gerätehandbuch
- 6
- Extraktion
- 7
- Aufbereitung
- 8
- LLM
- 9
- Trainingsbeispiele
- 10
- Validierungsschritt
- 11
- Validierungsdialog
- 12
- Textbereich
- 13
- Tabelle
- 14
- Schaltfläche
- 15
- Ausgabe