DE102021212607A1 - Verfahren zum Bereitstellen eines Trigger-Tokens - Google Patents

Verfahren zum Bereitstellen eines Trigger-Tokens Download PDF

Info

Publication number
DE102021212607A1
DE102021212607A1 DE102021212607.3A DE102021212607A DE102021212607A1 DE 102021212607 A1 DE102021212607 A1 DE 102021212607A1 DE 102021212607 A DE102021212607 A DE 102021212607A DE 102021212607 A1 DE102021212607 A1 DE 102021212607A1
Authority
DE
Germany
Prior art keywords
token
time
trigger
technical defect
maintenance
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.)
Ceased
Application number
DE102021212607.3A
Other languages
English (en)
Inventor
Tobias HIPP
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.)
Siemens Healthcare GmbH
Original Assignee
Siemens Healthcare 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 Siemens Healthcare GmbH filed Critical Siemens Healthcare GmbH
Priority to DE102021212607.3A priority Critical patent/DE102021212607A1/de
Priority to US18/053,231 priority patent/US20230146785A1/en
Publication of DE102021212607A1 publication Critical patent/DE102021212607A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/279—Recognition of textual entities
    • G06F40/284—Lexical analysis, e.g. tokenisation or collocates

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren zum Bereitstellen von einem Trigger-Token. Dabei korreliert das Trigger-Token mit einer Notwendigkeit einer Wartung eines Systems. Das Verfahren umfasst einen Verfahrensschritt eines Empfangens (REC-1) einer Logdatei des Systems. Dabei umfasst die Logdatei eine Mehrzahl von Ereignis-Beschreibungen. Dabei ist einer Teilmenge der Mehrzahl von Ereignis-Beschreibungen ein Zeitstempel zugeordnet. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Empfangens (REC-2) eines Zeitpunktes eines technischen Defekts des Systems. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Extrahierens (EXT) von Tokens aus der Teilmenge der Ereignis-Beschreibungen basierend auf einer Token-Kategorie. Dabei ist jedes der extrahierten Tokens als Zeichenkette in der Teilmenge von Ereignis-Beschreibung enthalten. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Bestimmens (DET-1) des Trigger-Tokens aus den extrahierten Tokens basierend auf einer Korrelation der den extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defektes des Systems, sodass der dem Trigger-Token zugeordnete Zeitstempel und der Zeitpunkt des technischen Defektes des Systems positiv korreliert sind. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Bereitstellens (PROV-1) des Trigger-Tokens.

Description

  • Die vorliegende Erfindung betrifft ein computerimplementiertes Verfahren zum Bereitstellen von einem Trigger-Token. Die Erfindung betrifft ferner eine computerimplementierte Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems, eine computerimplementierte Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion, ein Bereitstellungssystem, welches ausgebildet ist, das Verfahren auszuführen, eine medizinische Vorrichtung, ein Computerprogrammprodukt und ein computerlesbares Speichermedium.
  • Heutige, computerbasierte Systeme erzeugen typischerweise Logdateien (engl.: Logfile). In einer solchen, von einem System erzeugten Logdatei werden verschiedene Ereignisse das System betreffend dokumentiert. Beispielsweise werden in der Logdatei regelmäßige Statusmeldungen von wenigstens einer Komponente des Systems dokumentiert. Die Komponente wird dabei von dem System umfasst. Mit anderen Worten ist die Komponente Teil bzw. Bestandteil des Systems. Alternativ oder zusätzlich kann in der Logdatei eine Verwendung des Systems dokumentiert werden. Dabei kann dokumentiert werden, dass das System verwendet wurde, wie bzw. mit welchen Parametern es verwendet wurde und/oder ob es bei der Verwendung Auffälligkeiten gab. Typischerweise wird jedes dieser Ereignisse in Form einer Ereignis-Beschreibung und eines der Ereignis-Beschreibung zugeordneten Zeitstempels in der Logdatei dokumentiert.
  • Auf Grund der Komplexität heutiger Systeme und ihrer vielfältigen Verwendung, werden sehr viele derartige Ereignisse in der Logdatei dokumentiert. Aus diesem Grund ist die Logdatei eines Systems typischerweise sehr unübersichtlich. Insbesondere ist die Logdatei unübersichtlich, wenn sie nicht von demselben Programm gelesen bzw.- ausgewertet wird, mit dem sie erzeugt wurde. Außerdem wird auf diese Weise eine sehr große Datenmenge erzeugt, die typischerweise manuell bzw. ohne Hilfe eines Computerprogramms nicht mehr gehandhabt werden kann.
  • Zudem sind die Ereignis-Beschreibungen in einer Logdatei sehr vielfältig und häufig zwischen verschiedenen Systemen oder vor und nach einem Upgrade oder Update des Systems nicht einheitlich.
  • Es ist bekannt, dass insbesondere basierend auf einer Ereignis-Beschreibung einer Statusmeldung ein technischer Defekt des Systems vorhergesagt werden kann. Das Wissen über einen bevorstehenden bzw. erwarteten technischen Defekt kann genutzt werden, um eine Wartung des Systems zu initiieren und durchzuführen, um den technischen Defekt zu vermeiden oder hinauszuzögern.
  • Es ist bekannt, dafür manuell eine oder mehrere Ereignis-Beschreibungen zu definieren, welche in der Logdatei überwacht werden. Aus der Überwachung dieser manuell definierten Ereignis-Beschreibung kann ein erwarteter technischer Defekt abgeleitet werden. Allerdings ist der manuelle Aufwand sehr groß und auf Grund der großen Datenmenge und der Vielfalt der Ereignis-Beschreibungen, werden häufig nicht die geeignetsten bzw. aussagekräftigsten Ereignis-Beschreibungen für die Überwachung definiert. Außerdem sind häufig nicht alle Ereignis-Beschreibungen bekannt, die für eine Vorhersage eines erwarteten technischen Defekt geeignet sind. Diese werden dann typischerweise bei einer manuellen Definition der zu überwachenden Ereignis-Beschreibungen nicht berücksichtigt.
  • Außerdem ist bekannt, Verfahren zur Sprachprozessierung (engl.: Natural Language Processing, Akronym: NLP) auf die Logdatei anzuwenden, um für einen technischen Defekt relevante Ereignis-Beschreibungen zu erkennen und zu überwachen. Dabei werden die Ereignis-Beschreibungen in Worte zerlegt und die einzelnen Worte beispielsweise hinsichtlich ihrer Häufigkeit analysiert. Es ist allerdings bekannt, dass bereits ein einmaliges oder sehr geringes Auftreten einer bestimmten Ereignis-Beschreibung bzw. eines Wortes in einer Ereignis-Beschreibung einen technischen Defekt des Systems vorhersagen kann. Bei einem derart seltenen Auftreten einer aussagekräftigen Ereignis-Beschreibung ist es mittels Methoden des NLPs häufig nicht möglich, die Relevanz der entsprechenden Ereignis-Beschreibung für die Vorhersage eines technischen Defektes zu erkennen. Das bedeutet, dass auch mittels NLPs häufig nicht alle relevanten Ereignis-Beschreibungen berücksichtigt werden. Zudem werden auf Grund der Vielfältigkeit der Ereignis-Beschreibungen typischerweise mittels NLPs eine sehr gro-ße Zahl von Worten aus den Ereignis-Beschreibungen der Logdatei extrahiert. Diese Zahl ist häufig derart groß, dass keine sinnvolle Analyse mehr möglich ist. Insbesondere ist der Rechenaufwand bei diesem Verfahren sehr groß. Somit ist es auch mittels NLPs nur möglich eine eingeschränkte Analyse der Logdateien durchzuführen und es werden nicht alle relevanten Ereignis-Beschreibungen erkannt und berücksichtigt. Außerdem umfassen die Logdateien typischerweise keine Sätze bzw. im herkömmlichen Sinne sinnvolle Wortabfolgen. Aus diesem Grund ist eine Analyse mittels NLPs auch nur eingeschränkt möglich, da NLP typischerweise zum Erkennen von Wortzusammenhängen ausgebildet ist.
  • Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren bereitzustellen, welches es ermöglicht, geeignete Informationen in einer Logdatei eines Systems zu identifizieren, um einen technischen Defekt des Systems vorherzusagen.
  • Die Aufgabe wird gelöst durch ein computerimplementiertes Verfahren zum Bereitstellen von einem Trigger-Token. Die Erfindung betrifft ferner eine computerimplementierte Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems, eine computerimplementierte Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion, ein Bereitstellungssystem, welches ausgebildet ist, das Verfahren auszuführen, eine medizinische Vorrichtung, ein Computerprogrammprodukt und ein computerlesbares Speichermedium gemäß den unabhängigen Ansprüchen. Vorteilhafte Weiterbildungen sind in den abhängigen Ansprüchen und in der folgenden Beschreibung aufgeführt.
  • Nachstehend wird die erfindungsgemäße Lösung der Aufgabe sowohl in Bezug auf die beanspruchten Vorrichtungen als auch in Bezug auf das beanspruchte Verfahren beschrieben. Hierbei erwähnte Merkmale, Vorteile oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen und umgekehrt. Mit anderen Worten können die gegenständlichen Ansprüche (die beispielsweise auf eine Vorrichtung gerichtet sind) auch mit den Merkmalen, die in Zusammenhang mit einem Verfahren beschrieben oder beansprucht sind, weitergebildet sein. Die entsprechenden funktionalen Merkmale des Verfahrens werden dabei durch entsprechende gegenständliche Module ausgebildet.
  • Weiterhin wird die erfindungsgemäße Lösung der Aufgabe sowohl in Bezug auf Verfahren und Vorrichtungen zum Bereitstellen von einem Trigger-Token als auch in Bezug auf Verfahren und Vorrichtungen zum Bereitstellen einer trainierten Funktion beschrieben. Hierbei können Merkmale und alternative Ausführungsformen von Datenstrukturen und/oder Funktionen bei Verfahren und Vorrichtungen zur Bestimmung auf analoge Datenstrukturen und/oder Funktionen bei Verfahren und Vorrichtungen zum Anpassen/Optimieren/Trainieren übertragen werden. Weiterhin können die in Verfahren und Vorrichtungen zum Bereitstellen von einem Trigger-Token verwendeten trainierten Funktionen insbesondere durch Verfahren zum Verwenden der trainierten Funktion trainiert bzw. angepasst worden und/oder bereitgestellt worden sein.
  • Die Erfindung betrifft ein computerimplementiertes Verfahren zum Bereitstellen von einem Trigger-Token. Dabei korreliert das Trigger-Token mit einer Notwendigkeit einer Wartung eines Systems. Das Verfahren umfasst einen Verfahrensschritt eines Empfangens einer Logdatei des Systems. Dabei umfasst die Logdatei eine Mehrzahl von Ereignis-Beschreibungen. Dabei ist einer Teilmenge der Mehrzahl von Ereignis-Beschreibungen ein Zeitstempel zugeordnet. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Empfangens eines technischen Defekts des Systems. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Extrahierens von Tokens aus der Teilmenge der Ereignis-Beschreibungen basierend auf einer Token-Kategorie. Dabei ist jedes der extrahierten Tokens als Zeichenkette in der Teilmenge der Ereignis-Beschreibungen enthalten. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Bestimmens des Trigger-Tokens aus den extrahierten Tokens basierend auf einer Korrelation der den extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defekts des Systems, sodass der dem Trigger-Token zugeordnete Zeitstempel und der Zeitpunkt des technischen Defektes des Systems positiv korreliert sind. Das Verfahren umfasst weiterhin einen Verfahrensschritt eines Bereitstellens des Trigger-Tokens.
  • Das System kann dabei ein medizinisches System, insbesondere ein medizinisches Bildgebungssystem sein. Beispielsweise kann das System ein Computer-Tomographie (Akronym: CT) -System, ein Magnet-Resonanz-Tomographie (Akronym: MRT) -System, ein Röntgensystem, ein Mammographiesystem, ein C-Bogen-System, ein Angiographiesystem, ein Ultraschallsystem etc. sein. Alternativ kann das System beispielsweise ein Labordiagnostiksystem sein.
  • Das System kann insbesondere wenigstens eine Komponente umfassen. Die Komponente kann beispielsweise eine Bedienkomponente oder eine Verfahrkomponente bzw. Positionierkomponente des Systems sein. Die Komponente kann bei einem Röntgensystem, einem CT-System, einem Mammographiesystem, einem C-Bogen-System oder einem Angiographiesystem beispielsweise eine Röntgenröhre oder ein Röntgendetektor sein. Bei einem Ultraschallsystem kann die Komponente beispielsweise eine Ultraschallsonde sein. Bei einem MRT-System kann die Komponente beispielsweise eine Spule sein. Wenn im Folgenden der Ausdruck „System“ verwendet wird, ist davon der Ausdruck „die Komponente des Systems“ umfasst.
  • In dem Verfahrensschritt des Empfangens der Logdatei kann die Logdatei insbesondere direkt von dem System oder von einer Datenbank empfangen werden. Die Datenbank kann dabei auf einem lokalen Server oder einem Cloud-Server hinterlegt sein. Alternativ kann die Logdatei von einem Speichermedium empfangen werden. Mit anderen Worten kann in dem Verfahrensschritt des Empfangens der Logdatei die Logdatei von dem Speichermedium geladen werden.
  • Die Logdatei kann zeichencodiert sein.
  • Die von der Logdatei umfassten Ereignis-Beschreibungen beschreiben jeweils wenigstens ein Ereignis, welches das System betrifft. Insbesondere hat das Ereignis an dem System stattgefunden bzw. wurde von dem System durchgeführt. Die Ereignis-Beschreibungen beschreiben beispielsweise eine Statusmeldung des Systems und/oder eine Verwendung des Systems. Die Verwendung kann dabei beispielsweise durch einen Parameter des Systems bei der Verwendung oder durch ein Zustand des Systems bei der Verwendung und/oder durch ein Ergebnis der Verwendung beschrieben werden.
  • Die Teilmenge der Mehrzahl von Ereignis-Beschreibungen kann insbesondere wenigstens eine Ereignis-Beschreibung umfassen. Vorteilhafterweise umfasst die Teilmenge wenigstens zwei Ereignis-Beschreibungen. Insbesondere kann die Teilmenge der Mehrzahl von Ereignis-Beschreibungen alle Ereignis-Beschreibungen der Mehrzahl von Ereignis-Beschreibungen umfassen. Alternativ kann die Teilmenge der Mehrzahl von Ereignis-Beschreibungen eine beliebige Anzahl von Ereignis-Beschreibungen der Mehrzahl von Ereignis-Beschreibungen umfassen.
  • Jeder Ereignis-Beschreibung der Teilmenge ist ein Zeitstempel zugeordnet. Dabei können die Zeitstempel die verschiedenen Ereignis-Beschreibungen der Teilmenge zugeordnet sind verschieden oder gleich sein.
  • Im Folgenden wird ein einer Ereignis-Beschreibung zugeordneter Zeitstempel auch als Zeitstempel der Ereignis-Beschreibung bezeichnet.
  • Der Zeitstempel einer Ereignis-Beschreibung gibt an, wann die entsprechende Ereignis-Beschreibung in der Logdatei erfasst wurde. Alternativ gibt der Zeitstempel an, wann das die Ereignis-Beschreibung auslösende Ereignis des Systems stattgefunden hat. Der Zeitstempel umfasst dabei ein Datum und eine Uhrzeit. Insbesondere kann der Zeitstempel in einem standardisierten Format sein. Die Zeitstempel der Teilmenge von Ereignis-Beschreibungen werden ebenfalls von der Logdatei umfasst. Die Logdatei umfasst also für die Teilmenge von Ereignis-Beschreibungen jeweils ein Paar aus Ereignis-Beschreibung und zugeordnetem bzw. entsprechendem Zeitstempel.
  • In dem Verfahrensschritt des Empfangens des Zeitpunktes des technischen Defektes des Systems wird der Zeitpunkt direkt von dem System oder von der Datenbank oder von dem Speichermedium zum Bestimmen des Trigger-Tokens empfangen.
  • Der Zeitpunkt gibt an, wann der technische Defekt aufgetreten ist. Insbesondere umfasst der Zeitpunkt ein Datum. Zusätzlich kann der Zeitstempel eine Uhrzeit umfassen. Insbesondere ist der Zeitpunkt in einem standardisierten Format angegeben bzw. ausgebildet.
  • Alternativ kann der Zeitpunkt in Form einer „Restlebensdauer“ des Systems angegeben werden. Die „Restlebensdauer“ gibt dabei ein Zeitintervall bis zu dem technischen Defekt des Systems an. Das Zeitintervall endet mit dem technischen Defekt. Das Zeitintervall kann an einem beliebigen Zeitstempel aus der Logdatei beginnen bzw. starten. Insbesondere kann das Zeitintervall an dem frühesten oder an dem spätesten, von der Logdatei umfassten Zeitstempel beginnen. Das Zeitintervall bzw. die „Restlebensdauer“ kann insbesondere ausgehend von jedem Zeitstempel angegeben werden. Dabei ist das Zeitintervall für verschiedene Zeitstempel verschieden.
  • Der technische Defekt kann insbesondere ein Ausfall des Systems oder der Komponente des Systems sein. Alternativ kann zum Zeitpunkt des technischen Defektes lediglich eine regelmäßige Wartung notwendig sein.
  • In dem Verfahrensschritt des Extrahierens von Tokens aus der Teilmenge von Ereignis-Beschreibungen werden die Tokens basierend auf einer Token-Kategorie extrahiert. Dabei ist jedes Token als Zeichenkette in der Teilmenge von Ereignis-Beschreibungen enthalten.
  • Beim Extrahieren werden die Ereignis-Beschreibungen nach Tokens der Token-Kategorie durchsucht und aus den Ereignis-Beschreibungen separiert. Mit anderen Worten werden beim Extrahieren die Ereignis-Beschreibungen nach Tokens durchsucht, die in die Token-Kategorie fallen. Derart gefundene Tokens werden anschließend aus den Ereignis-Beschreibungen separiert-
  • Insbesondere können die Tokens basierend auf mehr als einer bzw. verschiedenen Token-Kategorien extrahiert werden. Mit anderen Worten kann das Extrahieren der Tokens für verschiedene Token-Kategorien wiederholt werden.
  • Jede Ereignis-Beschreibung der Teilmenge von Ereignis-Beschreibungen ist dabei als Gesamt-Zeichenkette ausgebildet. Jede Zeichenkette oder Gesamt-Zeichenkette umfasst dabei eine Mehrzahl von aneinandergereihten bzw. aufeinanderfolgenden Zeichen. Die extrahierten Tokens sind als Zeichenkette bzw. Teil-Zeichenkette bzw. Unterzeichenkette einer Gesamt-Zeichenkette ausgebildet. Insbesondere ist jedes extrahierte Token ein Teil wenigstens einer Gesamt-Zeichenkette. Dabei umfasst ein Token eine Teilmenge der Zeichen der Gesamt-Zeichenkette wenigstens einer Ereignis-Beschreibung. Mit anderen Worten wird jedes Token von wenigstens einer Gesamt-Zeichenkette umfasst. Eine Zeichenkette oder eine Gesamt-Zeichenkette kann sich dabei beispielsweise aus Buchstaben und/oder Ziffern und/oder Satzzeichen zusammensetzen. Mit anderen Worten kann eine Zeichenkette oder eine Gesamt-Zeichenkette wenigstens einen Buchstaben und/oder wenigstens eine Ziffer und/oder wenigstens ein Satzzeichen umfassen. Die Bezeichnung Buchstabe, Ziffer oder Satzzeichen definiert dabei eine Art eines einzelnen Zeichens der Zeichenkette oder der Gesamt-Zeichenkette. Eine Ziffer ist dabei einstellige Zahl.
  • Der Ausdruck „Extrahieren eines Tokens aus einer Ereignis-Beschreibung“ ist damit gleichbedeutend zu dem Ausdruck „Extrahieren eines Tokens aus einer Gesamt-Zeichenkette einer Ereignis-Beschreibung“. Ein von einer Ereignis-Beschreibung umfasstes Token ist somit auch von der Logdatei umfasst.
  • Die Token-Kategorie kann auf der Art der Zeichen basieren. Insbesondere können dann beim Extrahieren der Tokens die Zeichen der Gesamt-Zeichenketten der Teilmenge von Ereignis-Beschreibungen nach ihrer Art unterteilt werden. Dann umfasst jedes Token Zeichen einer bestimmten Art.
  • Alternativ kann die Token-Kategorie eine bestimmte Kombination von Arten von Zeichen vorgeben. Alternativ oder zusätzlich kann die Token-Kategorie eine bestimmte Anzahl von von einem Token der Token-Kategorie umfassten Zeichen vorgeben. Beispielsweise kann die Token-Kategorie eine feste Abfolge der Art und eine bestimmte Anzahl von Zeichen eines Tokens der Token-Kategorie vorgeben. Beispielsweise kann eine Token-Kategorie „vier Ziffern gefolgt von zwei Buchstaben“ sein bzw. vorgeben. Dann können beim Extrahieren der Tokens diejenigen Zeichenketten als Tokens aus den Gesamt-Zeichenketten extrahiert werden, die genau der festen Abfolge und/oder Anzahl an Zeichen, die durch die Token-Kategorie vorgegeben wird, entsprechen.
  • Jedem der extrahierten Tokens ist dabei der Zeitstempel der Ereignis-Beschreibung zugeordnet, aus der es extrahiert wurde.
  • In dem Verfahrensschritt des Bestimmens des Trigger-Tokens wird das Trigger-Token aus den extrahierten Tokens bestimmt. Dabei kann insbesondere mehr als ein Trigger-Token aus den extrahierten Tokens bestimmt werden.
  • Das Bestimmen des Trigger-Tokens basiert dabei auf einer Korrelation der Zeitstempel, die den extrahierten Tokens zugeordnet sind, und dem Zeitpunkt des technischen Defekts des Systems. Insbesondere ist das Trigger-Token ein extrahiertes Token, dessen zugeordneter Zeitstempel eine positive Korrelation mit dem Zeitpunkt des technischen Defektes aufweist. Ein solches Token wird im Folgenden als „positiv korreliertes Token“ bezeichnet.
  • Eine positive Korrelation kann insbesondere bedeutet, dass das positiv korrelierte Token immer in einem bestimmten Zeitintervall vor dem technischen Defekt des Systems in der Logdatei vorkommt bzw. auftritt. Mit anderen Worten kann das Auftreten des positiv korrelierten Tokens und somit sein Zeitstempel in einem zeitlichen Zusammenhang mit dem Zeitpunkt des technischen Defektes des Systems stehen. Alternativ kann eine positive Korrelation bedeuten, dass das positiv korrelierte Token in der Logdatei in immer kürzeren Zeitabständen bzw. mit zunehmender Frequenz vor dem technischen Defekt des Systems auftritt. Alternativ kann eine positive Korrelation bedeuten, dass das positiv korrelierte Token in der Logdatei in immer längeren Zeitabständen bzw. mit abnehmender Frequenz vor dem technischen Defekt des Systems auftritt.
  • Das Trigger-Token ist dann ein positiv korreliertes Token.
  • In dem Verfahrensschritt des Bereitstellens des Trigger-Tokens kann das Trigger-Token insbesondere gespeichert werden. Beispielsweise kann das Trigger-Token in einer Datenbank gespeichert bzw. hinterlegt werden. Alternativ kann das Trigger-Token einem System, welches das Trigger-Token für eine Analyse von Logdateien von Systemen verwendet, bereitgestellt bzw. auf diesem gespeichert werden.
  • Der Erfinder hat erkannt, dass ein Extrahieren von Tokens aus den Ereignis-Beschreibungen anhand von Token-Kategorien eine Analyse von vielfältigen, nicht standardisierten großen Logdateien bzw. Datenmengen ermöglicht. Der Erfinder hat erkannt, dass die meiste Rechenleistung lediglich einmal zum Bestimmen des Trigger-Tokens notwendig ist. Anschließend können Logdateien lediglich nach diesem Trigger-Token durchsucht bzw. analysiert werden. Der Erfinder hat erkannt, dass ein wie oben beschrieben ausgebildetes Trigger-Token geeignet ist, einen Zeitpunkt eines technischen Defekts eines Systems vorherzusagen. Dabei gehört das Trigger-Token einer Token-Kategorie an und ist positiv mit dem Zeitpunkt des technischen Defektes des Systems korreliert.
  • Nach einem Aspekt der Erfindung ist die Token-Kategorie eine der folgenden Token-Kategorien: eine Buchstabenfolge, eine Zahl und/oder ein Fehlercode.
  • Die Token-Kategorie definiert also eine Zeichenfolge, die das basierend auf der Token-Kategorie extrahierte Token aufweisen soll. Mit anderen Worten definiert die Token-Kategorie die Art der Zeichen, die das basierend auf der Token-Kategorie extrahierte Token aufweisen soll.
  • Ein Token der Token-Kategorie „Buchstabenfolge“ umfasst dabei nur Zeichen der Art „Buchstabe“.
  • Ein Token der Token-Kategorie „Zahl“ umfasst dabei nur Zeichen der Art „Ziffer“. Dabei setzt sich eine Zahl aus einer oder mehreren Ziffern zusammen. Insbesondere kann ein Token der Token-Kategorie „Zahl“ außerdem Leerzeichen und/oder Satzzeichen umfassen. Ein Satzzeichen ist dabei beispielsweise ein Komma oder ein Punkt.
  • Ein Fehlercode ist eine feste Abfolge von Zeichen-Arten. Alternativ oder zusätzlich kann ein Fehlercode eine feste Anzahl von Zeichen umfassen. Beispielsweise kann ein Fehlercode nur Ziffern und Buchstaben, und maximal sechs Zeichen umfassen.
  • Der Erfinder hat erkannt, dass das Extrahieren der Tokens basierend auf der Token-Kategorie effizient, insbesondere hinsichtlich einer benötigten Rechenkapazität, durchgeführt werden kann. Der Erfinder hat erkannt, dass mittels einer zeichenkodierten Logdatei das Extrahieren der Tokens einfach und effizient realisierbar ist. Der Erfinder hat erkannt, dass die Token-Kategorie derart definiert sein kann, dass die basierend auf der Token-Kategorie extrahierten Tokens zur Vorhersage des technischen Defekts des Systems geeignet sind.
  • Nach einem weiteren Aspekt der Erfindung wird die Teilmenge der Ereignis-Beschreibungen zum Extrahieren der Tokens basierend auf einem regulären Ausdruck gefiltert. Dabei basiert der reguläre Ausdruck auf einer Token-Kategorie.
  • Reguläre Ausdrücke sind aus dem Gebiet der theoretischen Informatik bekannt. Reguläre Ausdrücke sind bekannt, als Filterkriterien in der Textsuche verwendet zu werden.
  • Insbesondere kann die Token-Kategorie durch einen regulären Ausdruck beschrieben werden. Der reguläre Ausdruck kann eine Anzahl und/oder eine Art und/oder eine Abfolge der von der Token-Kategorie vorgegebenen Zeichenfolge angeben.
  • Der Erfinder hat erkannt, dass das bekannte Konzept der regulären Ausdrücke zum Extrahieren der Tokens genutzt bzw. angewendet werden kann. Der Erfinder hat erkannt, dass auf diese Weise das Extrahieren der Tokens optimiert durchgeführt werden kann. Der Erfinder hat erkannt, dass dafür im Vergleich zum NLP wesentlich weniger Rechenleitung notwendig ist. Der Erfinder hat erkannt, dass im Vergleich zur manuellen Analyse der Logdateien, mehr Trigger-Tokens bestimmt und berücksichtigt werden können.
  • Nach einem weiteren optionalen Aspekt der Erfindung werden die Ereignis-Beschreibungen der Teilmenge von Ereignis-Beschreibungen vor dem Extrahieren der Tokens standardisiert.
  • Dafür können beispielsweise alle Leerzeichen und/oder alle Satzzeichen aus den Ereignis-Beschreibungen entfernt werden. Alternativ oder zusätzlich können alle Großbuchstaben in Kleinbuchstaben umgewandelt werden. Alternativ oder zusätzlich kann nur eine einzige Art von Zeichen beibehalten werden.
  • Dabei kann das Standardisieren in Abhängigkeit von der Token-Kategorie sein. Für verschiedene Token-Kategorien können die Ereignis-Beschreibungen auf verschiedenen Weisen standardisiert werden. In diesem Fall kann der Verfahrensschritt des Extrahierens für verschiedene Token-Kategorien getrennt durchgeführt werden.
  • Beispielsweise können im Vorfeld eines Extrahierens von Tokens basierend auf einer Token-Kategorie, welche eine Buchstabenfolge definiert, die Ereignis-Beschreibungen derart standardisiert werden, dass alle Großbuchstaben zu Kleinbuchstaben umgewandelt werden und alle Zeichen außer Buchstaben und Leerzeichen gelöscht bzw. entfernt werden.
  • Beispielsweise können im Vorfeld eines Extrahierens von Tokens basierend auf einer Token-Kategorie, welche eine Zahl definiert, die Ereignis-Beschreibungen derart standardisiert werden, dass nur Ziffern, Leerzeichen, Kommata und Punkte beibehalten werden.
  • Der Erfinder hat erkannt, dass durch das Standardisieren im Vorfeld des Extrahierens das Extrahieren beschleunigt und vereinfacht werden kann. Insbesondere können auf diese Weise die Ereignis-Beschreibungen bereits an die Token-Kategorie angepasst werden, basierend auf welcher extrahiert werden soll. Der Erfinder hat erkannt, dass auf diese Weise beispielsweise verhindert werden kann, dass zwei eigentlich identische Tokens nur auf Grund eines Leerzeichens oder unterschiedlicher Groß- und Kleinschreibung für unterschiedlich erachtet werden und deshalb möglicherweise für nicht relevant betrachtet werden.
  • Nach einem weiteren Aspekt der Erfindung umfasst das Verfahren weiterhin einen Verfahrensschritt eines Gruppierens von aus unterschiedlichen Ereignis-Beschreibungen extrahierten identischen Tokens. Dabei basiert das Bestimmen des Trigger-Tokens auf einer Korrelation der den Gruppen von extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defekts des Systems.
  • Ein extrahiertes Token kann aus mehr als einer Ereignis-Beschreibung der Teilmenge von Ereignis-Beschreibungen extrahiert werden. Mit anderen Worten kann dieselbe Abfolge von Zeichen also eine Zeichenkette bzw. Teil-Zeichenkette von mehr als einer Gesamt-Zeichenkette umfasst sein und aus diesen extrahiert werden. Beim Extrahieren der Tokens kann also dasselbe Token bzw. ein identisches Token mehrfach in einer Logdatei extrahiert werden. Jedem dieser Tokens ist dabei der Zeitstempel der Ereignis-Beschreibung zugeordnet, aus der es extrahiert wurde.
  • Beim Gruppieren der identischen Tokens werden identische bzw. gleiche Tokens gruppiert bzw. zusammengefasst, die aus mehr als einer Ereignis-Beschreibung extrahiert wurden. Dabei wird einem derart gruppierten Token die Zeitstempel aller Ereignis-Beschreibungen zugeordnet, aus denen es extrahiert wurde. Einer Gruppe können somit ein oder mehr Zeitstempel zugeordnet sein. Für ein gruppiertes Token kann somit ein zeitlicher Verlauf eines Auftretens des Tokens in der Logdatei analysiert werden. Ein gruppiertes Token ist also ein extrahiertes Token, dem ein oder mehrere Zeitstempel zugeordnet sind.
  • Das Bestimmen des Trigger-Tokens hängt dabei von dem zeitlichen Verlauf bzw. einer Häufigkeit bzw. einer Frequenz des Auftretens des dem Trigger-Token entsprechenden extrahierten Tokens in der Logdatei bzw. in den Ereignis-Beschreibungen ab. Dabei wird der zeitliche Verlauf bzw. die Zeitstempel des extrahierten und wie oben beschrieben gruppierten Tokens mit dem Zeitpunkt des technischen Defekts des Systems korreliert. Das Trigger-Token ist ein extrahiertes Token, für welches eine positive Korrelation der zugeordneten Zeitstempel und dem Zeitpunkt des technischen Defekts vorliegt. Mit anderen Worten ist das Trigger-Token ein extrahiertes Token, dessen zeitlicher Verlauf mit dem Zeitpunkt des technischen Defektes positiv korreliert ist.
  • Dabei kann positiv korreliert beispielsweise bedeuten, dass die Zeitabstände zwischen den Zeitstempeln eines derart gruppierten, extrahierten Tokens mit abnehmenden Zeitabstand zu dem technischen Defekt abnehmen. Mit anderen Worten kann die Häufigkeit des Auftretens des dem Trigger-Token entsprechenden Tokens in der Logdatei bzw. in den Ereignis-Beschreibungen zunehmen, je kürzer der Zeitabstand zu dem Zeitpunkt des technischen Defektes wird. Mit anderen Worten kann die Frequenz des Auftretens des dem Trigger-Token entsprechenden Tokens mit abnehmendem Zeitabstand zu dem Zeitpunkt des technischen Defektes zunehmen. Alternativ können die Zeitabstände zwischen den Zeitstempeln zunehmen bzw. die Häufigkeit und die Frequenz abnehmen.
  • Der Erfinder hat erkannt, dass mit dem oben beschriebenen Verfahren auch ein zeitlicher Verlauf eines Auftretens eines Tokens in der Logdatei analysiert werden kann. Der Erfinder hat erkannt, dass dieser zeitliche Verlauf beim Bestimmen des Trigger-Tokens berücksichtigt werden kann. Der Erfinder hat erkannt, dass der zeitliche Verlauf mit dem Zeitpunkt des technischen Defektes des Systems zum Bestimmen des Trigger-Tokens korreliert werden kann.
  • Nach einem weiteren optionalen Aspekt der Erfindung wird die Korrelation der den Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defektes durch Anwenden einer trainierten Bestimmungsfunktion auf die Zeitstempel bestimmt.
  • Dabei wird die trainierte Bestimmungsfunktion auf den oder die Zeitstempel eines extrahierten Tokens und auf den Zeitpunkt des technischen Defektes angewendet. Dabei bestimmt die trainierte Bestimmungsfunktion für jedes extrahierte Token eine Stärke der Korrelation des oder der zugeordneten Zeitstempel mit dem Zeitpunkt des technischen Defektes des Systems. Eine besonders große Korrelation bzw. eine Korrelationsstärke über einem vordefinierten Schwellwert kann dann als positive Korrelation bezeichnet werden.
  • Insbesondere kann das Trigger-Token als das extrahierte Token bestimmt werden, dessen zugeordnete(r) Zeitstempel nach Anwenden der trainierten Bestimmungsfunktion die stärkste oder einer der stärksten Korrelationen mit dem Zeitpunkt des Ausfalls des Systems aufweisen.
  • In Ausführungen der Erfindung können mehrere Trigger-Tokens bestimmt werden, deren Korrelationsstärke größer als der Schwellwert ist.
  • Die trainierte Bestimmungsfunktion kann, insbesondere wie unten bezüglich einer trainierten Funktion allgemein beschrieben, ausgebildet sein.
  • Der Erfinder hat erkannt, dass die Korrelation mit Hilfe einer trainierten Bestimmungsfunktion besonders einfach bestimmt werden kann. Der Erfinder hat erkannt, dass die trainierte Bestimmungsfunktion in der Lage ist, mit den großen Datenmengen umzugehen. Der Erfinder hat erkannt, dass mit der trainierten Bestimmungsfunktion einfach die Korrelation für alle in Frage kommenden extrahierten Tokens bestimmt werden kann. Der Erfinder hat erkannt, dass eine trainierte Bestimmungsfunktion dazu ausgebildet sein kann, die Korrelation aller extrahierten Tokens mit dem Zeitpunkt des technischen Defektes zu bestimmen. Dabei wird die trainierte Bestimmungsfunktion auf den oder die einem extrahierten Token zugeordneten Zeitstempel angewendet und die Korrelation, insbesondere die Stärke der Korrelation, bestimmt. Dabei ist nicht relevant, um welches Token es sich handelt.
  • Die Erfindung betrifft außerdem eine computerimplementierte Verwendung eines wie oben beschrieben bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems. Die Verwendung umfasst einen Verfahrensschritt eines Empfangens einer Logdatei des Systems. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Bestimmens eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens in der Logdatei. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Initiierens der Wartung des Systems in Abhängigkeit des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Token.
  • Bei der Verwendung des Trigger-Tokens wird das Trigger-Token dazu verwendet, die Logdatei des Systems zu analysieren und eine Notwendigkeit einer Wartung vorherzusagen. Mit anderen Worten wird basierend auf dem Trigger-Token die Logdatei des Systems analysiert und darauf basierend die Notwendigkeit einer Wartung abgeleitet. Mit anderen Worten wird das System basierend auf dem Trigger-Token und der Logdatei überwacht, um gegebenenfalls rechtzeitig eine Wartung zu initiieren bzw. einzuleiten.
  • In dem Verfahrensschritt des Empfangens der Logdatei wird die Logdatei von dem System empfangen. Mit anderen Worten wird die Logdatei von dem System zum Empfangen bereitgestellt. Alternativ kann die Logdatei von einer Datenbank empfangen werden, in der das System die Logdatei hinterlegt bzw. speichert.
  • Die Logdatei umfasst dabei wie oben beschrieben eine Mehrzahl von Ereignis-Beschreibungen. Einer Teilmenge dieser Mehrzahl von Ereignis-Beschreibungen ist dabei ein wie oben beschrieben ausgebildeter Zeitstempel zugeordnet. Mit anderen Worten ist jeder Ereignis-Beschreibung der Teilmenge jeweils ein Zeitstempel zugeordnet.
  • In dem Verfahrensschritt des Bestimmens eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens in der Logdatei wird wenigstens die Teilmenge der von der Logdatei umfassten Ereignis-Beschreibung nach dem Trigger-Token durchsucht.
  • Dabei definiert das Trigger-Token diejenige Zeichenkette, nach welcher die Gesamt-Zeichenketten der Teilmenge von Ereignis-Beschreibungen durchsucht werden. Dabei bildet jede Ereignis-Beschreibung der Teilmenge eine Gesamt-Zeichenkette aus. Mit anderen Worten entspricht jede Ereignis-Beschreibung einer Gesamt-Zeichenkette. Insbesondere kann das Trigger-Token einen regulären Ausdruck definieren, nach welchem die Gesamt-Zeichenketten durchsucht werden.
  • Dabei kann jedes Auftreten des Trigger-Tokens in der Teilmenge der Ereignis-Beschreibungen bestimmt bzw. registriert werden. Insbesondere können die Zeitstempel der Ereignis-Beschreibungen registriert bestimmt werden, die das Trigger-Token umfassen. Dabei kann bestimmt werden, wann das Trigger-Token das erste Mal in der Logdatei bzw. in der Teilmenge der Ereignis-Beschreibungen auftritt bzw. vorkommt. Alternativ oder zusätzlich kann bestimmt werden, wie häufig das Trigger-Token in der Teilmenge der Ereignis-Beschreibungen auftritt bzw. von diesen umfasst ist. Dabei kann außerdem der zeitliche Verlauf des Auftretens des Trigger-Tokens anhand der Zeitstempel der das Trigger-Token umfassenden Ereignis-Beschreibungen bestimmt werden.
  • In dem Verfahrensschritt des Initiierens der Wartung wird dann in Abhängigkeit des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei die Wartung des Systems initiiert.
  • Mit anderen Worten kann die Wartung initiiert werden, wenn das Trigger-Token das erste Mal in der Logdatei auftritt. Alternativ kann die Wartung in Abhängigkeit eine Häufigkeit bzw. eines zeitlichen Verlaufes des Auftretens des Trigger-Tokens in der Logdatei initiiert werden. Beispielsweise kann die Wartung beim fünften oder beim zehnten oder beim zwanzigsten Auftreten des Trigger-Tokens in der Logdatei initiiert werden. Eine beliebige alternative Anzahl von Auftreten als Auslöser ist selbstverständlich denkbar.
  • Die Wartung kann insbesondere in Abhängigkeit der, aus dem Verfahren zum Bereitstellen des Trigger-Tokens bekannten, Korrelation des dem Trigger-Token zugeordneten Zeitstempel und dem Zeitpunkt des technischen Defektes initiiert werden. Mit anderen Worten kann aus der in dem Verfahren bestimmten Korrelation bekannt sein, wann der technische Defekt in Abhängigkeit eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens eintritt.
  • Außerdem kann aus der Korrelation eine Art des technischen Defektes, der durch das Trigger-Token vorhergesagt wird, bekannt sein. Die Art des technischen Defektes kann beispielsweise angeben, welche Komponente ausfallen wird.
  • Dabei kann die Wartung von dem Trigger-Token abhängen. Mit anderen Worten kann für verschiedene Trigger-Tokens in Abhängigkeit ihres jeweiligen Auftretens in der Logdatei verschiedene Wartungen initiiert werden. Wenn beispielsweise das Trigger-Token mit einem technischen Defekt einer Röntgenröhre korreliert, kann eine Wartung der Röntgenröhre initiiert werden. Insbesondere ist die Wartung derart ausgebildet, dass der technische Defekt des Systems verhindert oder der Zeitpunkt des technischen Defektes hinausgezögert wird.
  • Initiieren der Wartung bedeutet dabei, dass die Wartung technisch veranlasst wird. Dafür kann insbesondere eine Benachrichtigung an einen Service-Techniker versendet werden. Alternativ kann das Initiieren die Wartung System-intrinsisch initiiert werden. Mit anderen Worten kann beim Initiieren System intern ein Prozess gestartet werden, der die Wartung automatisiert durchführt. Mit anderen Worten kann beim Initiieren der Wartung ein Programm bzw. ein Wartungsprogramm auf dem System gestartet werden. Insbesondere kann das Wartungsprogramm die Wartung dann durchführen.
  • Der Erfinder hat erkannt, dass das Auftreten des Trigger-Tokens in einer Logdatei analysiert werden kann und in Abhängigkeit davon die Wartung initiiert werden kann. Der Erfinder hat erkannt, dass die Logdatei des Systems effizient und schnell nach dem Trigger-Token durchsucht werden kann. Insbesondere kann dies kontinuierlich, während des laufenden Betriebs des Systems erfolgen. Der Erfinder hat erkannt, dass die Analyse der Logdatei nach dem Trigger-Token in Echtzeit parallel zum Erstellen der Logdatei durch das System erfolgen kann. Auf diese Weise kann sichergestellt werden, dass ein Auslöser für eine Wartung, beispielsweise das erstmalige Auftreten und/oder beispielsweise eine zunehmende oder abnehmende Häufigkeit des Trigger-Tokens rechtzeitig erkannt wird und die Wartung initiiert werden kann. Der Erfinder hat erkannt, dass auf diese Weise eine Notwendigkeit einer Wartung zur Verhinderung oder Verzögerung eines technischen Defektes mit geringem Rechenaufwand erkannt werden kann.
  • Nach einem Aspekt der Erfindung umfasst die Verwendung einen Verfahrensschritt eines automatisierten Durchführens der Wartung.
  • Die Wartung wird dabei automatisch von dem System selbst durchgeführt. Die Wartung kann dabei durch ein auf dem System ausgeführten Programm bzw. Wartungsprogramm durchgeführt werden. Beispielsweise kann die Wartung ein Neustart des Systems oder eine neue Justage einer Komponenten etc. sein.
  • Dabei kann die Wartung durchgeführt werden, bevor der technische Defekt auftritt. Insbesondere kann beim Durchführen der Wartung berücksichtigt werden, ob das System in Benutzung ist. Beispielsweise kann die Wartung automatisch an einem Wochenende oder nachts durchgeführt werden.
  • Der Erfinder hat erkannt, dass in Abhängigkeit des Auftretens des Trigger-Tokens die Wartung des Systems vollautomatisch initiiert und durchgeführt werden kann. Der Erfinder hat erkannt, dass somit weder ein Benutzer des Systems noch ein Service-Techniker notwendig ist, um die Wartung zu initiieren und/oder durchzuführen. Der Erfinder hat erkannt, dass somit das System effizient gewartet werden kann und Stillstandzeiten reduziert oder sogar vermieden werden können. Stillstandzeiten können während eines Wartens auf einen Service-Techniker auftreten. Der Erfinder hat erkannt, dass Leerlaufzeiten des Systems, also Zeiten, in denen das System nicht benutzt wird (beispielsweise nachts oder am Wochenende), für die Wartung genutzt werden können.
  • Nach einem weiteren Aspekt der Erfindung umfasst das System eine Röntgenvorrichtung. Dabei umfasst die Röntgenvorrichtung eine Röntgenröhre. Dabei umfasst der Verfahrensschritt des automatisierten Durchführens der Wartung insbesondere eine automatisierte Justage der Röntgenröhre und/oder ein Umschalten eines Betriebsmodus' eines Fokus` der Röntgenröhre.
  • Die Röntgenvorrichtung kann dabei beispielsweise ein konventionelles Röntgensystem sein. Alternativ kann die Röntgenvorrichtung ein CT-System oder ein C-Bogen-System oder ein Mammographiesystem oder ein Angiographiesystem sein.
  • Die Röntgenröhre kann eine Transmissionsröntgenröhre oder eine Drehanodenröntgenröhre sein. Die Röntgenröhre ist insbesondere dazu ausgebildet, eine Röntgenstrahlung auszusenden.
  • Bei der automatischen Justage der Röntgenröhre kann ein Elektronenstrahl, der zum Erzeugen der Röntgenstrahlung ausgebildet ist, auf ein Target neu fokussiert werden. Um einen Betrieb der Röntgenröhre zu gewährleisten, muss dieser Fokus regelmäßig neujustiert werden. Dieses Neujustieren kann in Abhängigkeit der Häufigkeit oder des erstmaligen Auftretens eines geeigneten Trigger-Tokens in der Logdatei initiiert und automatisiert durchgeführt werden.
  • Außerdem kann eine Röntgenröhre verschieden große Fokusse des Röntgenstrahls auf dem Target aufweisen. Mit anderen Worten kann zwischen verschiedenen Fokussen gewechselt werden. In Abhängigkeit der Häufigkeit oder des erstmaligen Auftretens eines geeigneten Trigger-Tokens kann der Fokus der Röntgenröhre verändert werden. Insbesondere kann der Fokus verändert werden, wenn der aktuelle Fokus aufgrund eines technischen Defektes nicht mehr funktioniert.
  • Der Erfinder hat erkannt, dass in Abhängigkeit des Auftretens also der Häufigkeit oder des erstmaligen Auftretens des Trigger-Tokens in der Logdatei die Funktion der Röntgenröhre sichergestellt werden kann. Der Erfinder hat erkannt, dass die Wartung der Röntgenröhre automatisch bzw. automatisiert durchgeführt werden kann. Insbesondere kann eine Notwendigkeit der Wartung, das Initiieren der Wartung und das Durchführen der Wartung automatisiert, ohne manuelle Unterstützung durchgeführt werden. Der Erfinder hat erkannt, dass die Wartung durch ein Starten eines Wartungsprogramms auf dem System initiiert werden kann und die Wartung selbst automatisiert durch das Wartungsprogramm durchgeführt werden kann. Der Erfinder hat erkannt, dass die Wartung insbesondere ein (Neu-)Justieren der Röntgenröhre und/oder einen Wechsel des Fokus' umfassen kann.
  • Nach einem weiteren Aspekt der Erfindung umfasst die Verwendung weiterhin einen Verfahrensschritt eines Bestimmens eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes in Abhängigkeit des dem Trigger-Token zugeordneten Zeitstempels bei erstmaligem Auftreten des Trigger-Tokens in der Logdatei. Dabei hängt das Initiieren der Wartung von dem dem Trigger-Token zugeordneten Zeitstempel und dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems ab.
  • Insbesondere kann ein Zusammenhang zwischen dem Auftreten des Trigger-Tokens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei aus der Korrelation des oder der dem Trigger-Token zugeordneten Zeitstempel und dem Zeitpunkt des technischen Defektes des Systems bekannt sein. Mit diesem Wissen kann mit der Kenntnis des Auftretens und/oder der Häufigkeit des Trigger-Tokens der voraussichtliche Zeitpunkt des erwarteten technischen Defektes des Systems von dem Auftreten und/oder der Häufigkeit des Trigger-Tokens in der Logdatei abgeleitet werden. Mit anderen Worten kann der voraussichtliche Zeitpunkt des erwarteten technischen Defektes basierend auf dem Auftreten und/oder der Häufigkeit des Trigger-Tokens in der Logdatei extrapoliert werden.
  • Insbesondere kann der voraussichtliche Zeitpunkt des erwarteten technischen Defektes ein Datum und/oder eine Uhrzeit sein, an dem der technische Defekt voraussichtlich eintritt. Alternativ oder zusätzlich kann der Zeitpunkt des technischen Defektes eine Zeitspanne bis zu dem erwarteten technischen Defekt umfassen bzw. angeben. Die Zeitspanne kann eine zeitliche Dauer beispielsweise zwischen dem spätesten Zeitstempel in der Logdatei und dem erwarteten Eintreten des technischen Defektes angeben.
  • Die Wartung kann dann in dem Schritt des Initiierens der Wartung in Abhängigkeit des voraussichtlichen Zeitpunkts des erwarteten technischen Defektes initiiert werden. Dabei kann die Wartung initiiert werden, bevor der erwartete technische Defekt eintritt. Mit anderen Worten kann ein Zeitpunkt, an dem die Wartung durchgeführt wird, zeitlich vor dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes liegen. Die Wartung wird dabei vor oder an dem Zeitpunkt des Durchführens der Wartung initiiert. Insbesondere kann der Zeitpunkt des Initiierens der Wartung innerhalb der Zeitspanne bis zu dem erwarteten technischen Defekt liegen.
  • Der Erfinder hat erkannt, dass in Abhängigkeit des dem Trigger-Token zugeordneten Zeitstempels bzw. den dem Trigger-Token zugeordneten Zeitstempeln der voraussichtliche Zeitpunkt des erwarteten technischen Defektes des System abgeleitet bzw. extrapoliert werden kann. Der Erfinder hat erkannt, dass auf diese Weise eine präventive Wartung des Systems initiiert werden kann, um den technischen Defekt oder sogar einen kompletten Ausfall des Systems zu vermeiden.
  • Nach einem optionalen Aspekt der Erfindung umfasst die Verwendung einen Verfahrensschritt eines Bestimmens einer Art des technischen Defektes in Abhängigkeit von dem Trigger-Token.
  • Mit anderen Worten kann von dem Trigger-Token abgeleitet werden, welcher technische Defekt erwartet wird. Die Art des technischen Defektes bzw. die Art des erwarteten technischen Defektes gibt dabei an, was bzw. welche Komponente des Systems den technischen Defekt verursacht. Dabei können verschiedene mögliche technische Defekte durch verschiedene Trigger-Tokens vorhergesagt werden. Beispielsweise kann ein technischer Defekt der Röntgenröhre durch ein anderes Trigger-Token in der Logdatei vorhergesagt werden als ein technischer Defekt des Röntgendetektors. Außerdem kann beispielsweise ein anderes Trigger-Token einen Ausfall einer Kühlpumpe der Röntgenröhre vorhersagen als einen Ausfall eines Filaments der Röntgenröhre. Mit anderen Worten kann ein Trigger-Token für einen bestimmten technischen Defekt spezifisch sein.
  • In Ausführungen der Erfindung kann ein oder mehr als ein Trigger-Token für einen bestimmten technischen Defekt spezifisch sein.
  • Insbesondere kann dann die initiierte Wartung für die Art des technischen Defektes spezifisch sein. Mit anderen Worten kann mit der Kenntnis der Art des technischen Defektes direkt eine Wartung initiiert werden, die geeignet ist, den spezifischen, erwarteten technischen Defekt zu beheben bzw. zu verhindern.
  • Der Erfinder hat erkannt, dass von dem Trigger-Token abgeleitet werden kann, welcher technische Defekt erwartet wird. Auf diese Weise kann eine angepasste, spezifische Wartung initiiert werden, um den erwarteten technischen Defekt zu verhindern oder zu beheben. Insbesondere kann ein geeignetes Wartungsprogramm gestartet werden. Alternativ kann der Service-Techniker entsprechend informiert werden, um sicherzustellen, dass er die passende Ausrüstung und/oder Ersatzteile für die Wartung dabei hat.
  • Nach einem weiteren Aspekt der Erfindung umfasst die Logdatei das Trigger-Token mehrfach. Dabei ist dem Trigger-Token für jedes Auftreten in der Logdatei ein Zeitstempel zugeordnet. Dabei hängt das Initiieren der Wartung des Systems von einem zeitlichen Verlauf des Auftretens des Trigger-Tokens ab.
  • Dabei ist dem Trigger-Token der Zeitstempel jeder Ereignis-Beschreibung der Logdatei zugeordnet, die das Trigger-Token umfasst. Die zeitlich Abfolge der zugeordneten Zeitstempel beschreibt den zeitlichen Verlauf des Vorkommens bzw. Auftretens des Trigger-Tokens in der Logdatei bzw. in den von der Logdatei umfassten Ereignis-Beschreibungen. Dabei kann beispielsweise die Häufigkeit des Auftretens des Trigger-Tokens mit der Zeit zu- oder abnehmen. Insbesondere kann der zeitliche Verlauf beispielsweise eine Frequenz des Trigger-Tokens in der Logdatei beschreiben. Mit anderen Worten kann der zeitliche Verlauf beschreiben, wie häufig in einem bestimmten Zeitintervall das Trigger-Token in der Logdatei vorkommt bzw. auftritt.
  • Das Initiieren der Wartung kann dann von dem zeitlichen Verlauf des Auftretens des Trigger-Tokens abhängen. Beispielsweise kann basierend auf dem zeitlichen Verlauf extrapoliert werden, wann der technische Defekt erwartungsgemäß eintritt. Mit anderen Worten kann der voraussichtliche Zeitpunkt des erwarteten technischen Defektes basierend auf dem Verlauf extrapoliert werden. Insbesondere kann die Wartung in Abhängigkeit der Frequenz des Auftretens bzw. Vorkommens des Trigger-Tokens in der Logdatei initiiert werden. Mit anderen Worten kann die Wartung initiiert werden, wenn die Frequenz einen bestimmten, vordefinierten Wert unter- oder überschreitet. Insbesondere kann in Abhängigkeit des voraussichtliche Zeitpunktes des erwarteten technischen Defektes die Wartung wie oben beschrieben initiiert werden.
  • Insbesondere kann der Zusammenhang zwischen dem zeitlichen Verlauf des Auftretens des Trigger-Tokens und dem Zeitpunkt des technischen Defektes aus der Korrelation, die in dem Verfahren zum Bestimmen des Trigger-Tokens bestimmt wird, bekannt sein.
  • Der Erfinder hat erkannt, dass die Logdatei auch einen zeitlichen Verlauf des Trigger-Tokens darstellen kann. Der Erfinder hat außerdem erkannt, dass der zeitliche Verlauf genutzt werden kann, um den voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems vorherzusagen und präventiv eine Wartung zu initiieren.
  • Nach einem weiteren Aspekt der Erfindung umfasst die Verwendung einen Verfahrensschritt eines Anwendens einer trainierten Funktion auf die dem Trigger-Token zugeordneten Zeitstempel zur Bestimmung eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems. Die Verwendung umfasst außerdem einen Verfahrensschritt eines Bereitstellens des voraussichtlichen Zeitpunktes des erwarteten technischen Defektes des Systems. Dabei hängt das Initiieren der Wartung von dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems ab.
  • In dem Verfahrensschritt des Anwendens der trainierten Funktion werden mittels der trainierten Funktion basierend auf Eingangsdaten Ausgangsdaten erzeugt.
  • In dieser Anwendung entsprechen die dem Trigger-Token zugeordneten Zeitstempel den Eingangsdaten und der voraussichtliche Zeitpunkt des erwarteten technischen Defektes den Ausgangsdaten.
  • Im Allgemeinen ahmt eine trainierte Funktion kognitive Funktionen nach, die Menschen mit menschlichem Denken verbinden. Insbesondere durch auf Trainingsdaten basierendem Training kann sich die trainierte Funktion an neue Umstände anpassen sowie Muster erkennen und extrapolieren.
  • Im Allgemeinen können Parameter einer trainierten Funktion mittels Trainings angepasst werden. Insbesondere kann dafür ein beaufsichtigtes (supervised) Training, ein halbüberwachtes (semi-supervised) Training, ein unbeaufsichtigtes (unsupervised) Training, ein verstärkendes Lernen (reinforcement learning) und/oder ein aktives Lernen (active learning) verwendet werden. Darüber hinaus kann Repräsentationslernen (ein alternativer Begriff ist „Merkmalslernen“) (representation learning bzw. feature learning) verwendet werden. Insbesondere können die Parameter der trainierten Funktionen durch mehrere Trainingsschritte iterativ angepasst werden.
  • Insbesondere kann eine trainierte Funktion ein neuronales Netzwerk, eine Unterstützungsvektormaschine (support vector machine), einen Zufallsbaum bzw. einen Entscheidungsbaum (decision tree) und/oder ein Bayes'sches Netzwerk umfassen, und/oder die trainierte Funktion kann auf k-Mittel-Clustering (k-means clustering), Q-Learning, genetischen Algorithmen und/oder Assoziationsregeln basieren. Insbesondere kann eine trainierte Funktion eine Kombination aus mehreren unkorrelierten Entscheidungsbäumen bzw. ein Ensemble aus Entscheidungsbäumen (random forest) umfassen. Insbesondere kann die trainierte Funktion mittels XGBoosting (eXtreme Gradient Boosting) bestimmt werden. Insbesondere kann ein neuronales Netzwerk ein tiefes neuronales Netzwerk (deep neural network), ein Faltungs-neuronales Netzwerk (convolutional neural network) oder ein Faltungs-tiefes neuronales Netzwerk (convolutional deep neural network) sein. Darüber hinaus kann ein neuronales Netzwerk ein kontradiktorisches Netzwerk (adversarial network), ein tiefes kontradiktorisches Netzwerk (deep adversarial network) und/oder ein generatives kontradiktorisches Netzwerk (generative adversarial network) sein. Insbesondere kann ein neuronales Netzwerk ein rekurrentes neuronales Netzwerk (recurrent neural network) sein. Insbesondere kann ein rekurrentes neuronales Netzwerk ein Netzwerk mit langem Kurzzeitgedächtnis (long-short-term-memory, LSTM), insbesondere eine Gated Recurrent Unit (GRU), sein. Insbesondere kann eine trainierte Funktion eine Kombination der beschriebenen Ansätze umfassen. Insbesondere werden die hier beschriebenen Ansätze für eine trainierte Funktion Netzwerkarchitektur der trainierten Funktion genannt.
  • Der voraussichtliche Zeitpunkt des erwarteten technischen Defektes gibt wie oben beschrieben an, wann der technische Defekt des Systems vermutlich eintritt. Alternativ kann der voraussichtliche Zeitpunkt des erwarteten technischen Defektes wie oben beschrieben eine Zeitspanne bis zu dem technischen Defekt des Systems angeben.
  • Die dem Trigger-Token zugeordneten Zeitstempel dienen als Eingangsdaten der trainierten Funktion. Die trainierte Funktion ist dazu ausgebildet, basierend auf den Eingangsdaten den voraussichtlichen Zeitpunkt des erwarteten technischen Defektes zu bestimmen. Dieser voraussichtliche Zeitpunkt des erwarteten technischen Defektes wird dann bereitgestellt.
  • In Abhängigkeit des voraussichtlichen Zeitpunktes des erwarteten technischen Defektes kann dann wie oben beschrieben die Wartung initiiert werden. Mit anderen Worten kann ein Zeitpunkt des Initiierens und/oder des Durchführens der Wartung von dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes abhängen.
  • Der Erfinder hat erkannt, dass der voraussichtliche Zeitpunkt des erwarteten technischen Defektes durch Anwenden einer trainierten Funktion bestimmt werden kann. Der Erfinder hat erkannt, dass Regelmäßigkeiten beim Auftreten des Trigger-Tokens in Abhängigkeit einer Notwendigkeit einer Wartung erkannt und genutzt werden können, um den voraussichtlichen Zeitpunkt des erwarteten technischen Defektes mit einer trainierten Funktion vorherzusagen.
  • Nach einem weiteren optionalen Aspekt der Erfindung wird das Initiieren der Wartung an einen Zeitplan eines Service-Technikers angepasst.
  • Insbesondere kann in diesem Ausführungsbeispiel die Wartung zumindest teilweise manuell ausgeführt werden. Insbesondere kann das Initiieren der Wartung eine Benachrichtigung an einen Service-Techniker umfassen. Alternativ kann das Initiieren der Wartung einen Eintrag in einen Zeitplan bzw. Terminplan des Service-Technikers umfassen, wann er die Wartung ausführen soll. Der Zeitplan des Service-Technikers umfasst dabei eine Information, wann der Service-Techniker bereits gebucht bzw. geblockt ist und wann er freie Zeiten hat.
  • Dabei kann in Abhängigkeit eines wie oben beschrieben bestimmten voraussichtlichen Zeitpunktes des erwarteten technischen Defektes und des Zeitplans des Service-Technikers ein optimaler Zeitpunkt bzw. Termin für die Wartung des Systems bestimmt werden. Dieser Termin kann automatisiert in dem Zeitplan des Service-Technikers für das Durchführen der Wartung blockiert werden.
  • Insbesondere kann aus der, wie oben beschrieben ausgebildeten Art des technischen Defektes, bestimmt werden, welche Wartung bzw. welche Art der Wartung durchzuführen ist und wie lang diese dauert. Die Art der Wartung und/oder die Dauer der Wartung können beim Eintragen des Zeitpunktes der Wartung in den Zeitplan des Service-Technikers berücksichtigt werden. Insbesondere kann wenigstens die Art der Wartung auch in den Zeitplan des Service-Technikers eingetragen werden.
  • Insbesondere kann bei dem Eintragen in den Zeitplan des Service-Technikers ein Ort berücksichtigt werden, an dem das System positioniert ist bzw. an dem sich das System befindet. Dabei kann das Berücksichtigen des Ortes umfassen, dass der Zeitpunkt der Wartung derart gewählt wird, dass der Service-Techniker gemäß seines Zeitplanes in der Nähe des Ortes des Systems ist. Dafür umfasst der Zeitplan des Service-Technikers für die geblockten Zeiten eine Information, wo sich der Service-Techniker in diesen Zeiten befindet.
  • Der Erfinder hat erkannt, dass die Verwendung auch zu einer Optimierung des Zeitplanes des Service-Technikers genutzt werden kann. Insbesondere kann auf diese Weise eine Leerlaufzeit und/oder Fahrtzeiten des Service-Technikers reduziert werden. Der Erfinder hat erkannt, dass durch das Eintragen der Art der Wartung sichergestellt werden kann, dass der Service-Techniker alle für die Wartung gegebenenfalls notwendigen Ersatzteile und/oder Werkzeug dabei hat.
  • Die Erfindung betrifft außerdem eine computerimplementierte Verwendung eines wie oben beschrieben bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion. Dabei umfasst die Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen der trainierten Funktion einen Verfahrensschritt eines Empfangens von dem bereitgestellten Trigger-Token zugeordneten Zeitstempeln von einem System. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Empfangens von einem Zeitpunkt eines technischen Defektes des Systems. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Bestimmens eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems durch Anwenden der trainierten Funktion auf die Zeitstempel. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Anpassens mindestens eines Parameters der trainierten Funktion basierend auf einem Vergleich des bestimmten voraussichtlichen Zeitpunktes und des empfangenen Zeitpunktes. Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Bereitstellens der trainierten Funktion.
  • Dabei ist die trainierte Funktion ausgebildet, bei einer computerimplementierten Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung wie oben beschrieben verwendet zu werden.
  • Die trainierte Funktion kann dabei wie oben beschrieben ausgebildet sein. Die trainierte Funktion wird mittels überwachten Lernens (engl.: supervised training) trainiert. Dabei werden durch Anwenden der trainierten Funktion auf Eingangsdaten bestimmte Ausgangsdaten mit einer sogenannten Grundwahrheit (engl.: ground truth) verglichen. Die trainierte Funktion bzw. der wenigstens eine Parameter der trainierten Funktion wird während des Trainings iterativ so angepasst, dass die durch Anwenden der trainierten Funktion bestimmten Ausgangsdaten möglichst gut mit der Grundwahrheit übereinstimmen.
  • In der beschriebenen Verwendung entsprechen die Eingangsdaten den dem Trigger-Token zugeordneten Zeitstempel. Dabei können dem Trigger-Token mehr als ein Zeitstempel zugeordnet sein. Insbesondere ist dem Trigger-Token wie oben beschrieben für jedes Auftreten bzw. Vorkommen in einer Logdatei des Systems ein Zeitstempel zugeordnet. Die Zeitstempel können direkt von dem System empfangen werden. Alternativ können die Zeitstempel von einer Datenbank empfangen werden.
  • Die Ausgangsdaten sind in diesem Fall der durch Anwenden der trainierten Funktion auf die Zeitstempel bestimmte voraussichtliche Zeitpunkt des erwarteten technischen Defektes des Systems.
  • Die Grundwahrheit ist der (tatsächliche) Zeitpunkt des technischen Defektes des Systems, der empfangen wird. Der derart empfangene Zeitpunkt kann dabei mit den Zeitstempeln empfangen werden.
  • Zum Trainieren der trainierten Funktion wird der bestimmte voraussichtliche Zeitpunkt des erwarteten technischen Defektes mit dem empfangenen Zeitpunkt des technischen Defektes verglichen. Dabei wird die trainierte Funktion bzw. ihr wenigstens einer Parameter derart angepasst, dass bei einem erneuten Anwenden der trainierten Funktion auf die Zeitstempel der bestimmte voraussichtliche Zeitpunkt mit dem empfangenen Zeitpunkt besser übereinstimmt.
  • Insbesondere kann das derart ausgebildete Training für eine Vielzahl von Zeitstempeln des Trigger-Tokens von verschiedenen System wiederholt werden und die trainierte Funktion auf diese Weise iterativ angepasst werden.
  • Die trainierte Funktion wird in dem Verfahrensschritt des Bereitstellens derart bereitgestellt, dass sie für eine oben beschriebene Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems verwendet werden kann.
  • Die trainierte Funktion kann für ein bestimmtes Trigger-Token spezifisch sein. Für verschiedene Trigger-Tokens können verschiedene Funktionen wie oben beschrieben trainiert werden.
  • „Trainierte Funktion“ wird in diesem Fall synonym zu „trainierbare Funktion“ verwendet. Insbesondere kann die trainierte Funktion bereits vortrainiert sein. Alternativ oder zusätzlich kann die trainierte Funktion kontinuierlich weiter trainiert werden.
  • Der Erfinder hat erkannt, dass eine Funktion zum Vorhersagen des voraussichtlichen Zeitpunktes des erwarteten technischen Defektes trainiert werden kann. Der Erfinder hat erkannt, dass die Funktion mittels überwachtem Training trainiert werden kann. Der Erfinder hat erkannt, dass die derart trainierte Funktion bei einer Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung angewendet werden kann.
  • Die Erfindung betrifft außerdem ein Bereitstellungssystem zum Bereitstellen von einem Trigger-Token. Dabei korreliert das Trigger-Token mit einer Notwendigkeit einer Wartung eines Systems. Dabei umfasst das System eine Schnittstelle und eine Recheneinheit. Dabei ist die Schnittstelle zum Empfangen einer Logdatei des Systems ausgebildet. Dabei umfasst die Logdatei eine Mehrzahl von Ereignis-Beschreibungen. Dabei ist einer Teilmenge der Mehrzahl von Ereignis-Beschreibungen ein Zeitstempel zugeordnet. Dabei ist die Schnittstelle weiterhin zum Empfangen eines Zeitpunktes eines technischen Defektes des Systems ausgebildet. Dabei ist die Recheneinheit zum Extrahieren von Tokens aus der Teilmenge der Ereignis-Beschreibungen basierend auf einer Token-Kategorie ausgebildet. Dabei ist jedes der extrahierten Tokens als Zeichenkette in der Teilmenge von Ereignis-Beschreibungen enthalten. Dabei ist die Recheneinheit weiterhin zum Bestimmen des Trigger-Tokens aus den extrahierten Tokens basierend auf einer Korrelation der den extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defektes des Systems ausgebildet, sodass der dem Trigger-Token zugeordnete Zeitstempel und der Zeitpunkt des technischen Defektes des Systems positiv korreliert sind. Dabei ist die Schnittstelle weiterhin zum Bereitstellen des Trigger-Tokens ausgebildet.
  • Ein solches Bereitstellungssystem kann insbesondere dazu ausgebildet sein, das zuvor beschriebene Verfahren zum Bereitstellen von einem Trigger-Token und seine Aspekte auszuführen. Das Bereitstellungssystem ist dazu ausgebildet dieses Verfahren und seine Aspekte auszuführen, indem die Schnittstelle und die Recheneinheit ausgebildet sind, die entsprechenden Verfahrensschritte auszuführen.
  • Die Erfindung betrifft weiterhin eine medizinische Vorrichtung, insbesondere eine Röntgenvorrichtung. Die medizinische Vorrichtung umfasst ein oben beschriebenes Bereitstellungssystem.
  • Die Röntgenvorrichtung kann insbesondere ein konventionelles Röntgensystem oder ein CT-System oder ein C-Bogen-System oder ein Mammographiesystem oder ein Angiographiesystem sein. Insbesondere kann die Röntgenvorrichtung wenigstens eine Röntgenröhre und einen Röntgendetektor umfassen.
  • Die Erfindung betrifft optional ein Verwendungssystem zum Verwenden eines mit einem oben beschriebenen Bereitstellungssystem bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems. Das Verwendungssystem umfasst eine Schnittstelle und eine Recheneinheit. Dabei ist die Schnittstelle zum Empfangen einer Logdatei des Systems ausgebildet. Dabei ist die Recheneinheit zum Bestimmen eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens in der Logdatei ausgebildet. Dabei ist die Schnittstelle und/oder die Recheneinheit zum Initiieren der Wartung des Systems in Abhängigkeit der erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens ausgebildet.
  • Ein solches Verwendungssystem kann insbesondere dazu ausgebildet sein, die zuvor beschriebene Verwendung eines mit einem oben beschriebenen Bereitstellungssystem bereitgestellten Trigger-Token zur automatisierten Wartung eines Systems auszuführen. Das Verwendungssystem ist dazu ausgebildet diese Verwendung und seine Aspekte auszuführen, indem die Schnittstelle und die Recheneinheit ausgebildet sind, die entsprechenden Verfahrensschritte auszuführen.
  • Insbesondere kann die oben beschriebene medizinische Vorrichtung alternativ oder zusätzlich zu dem Bereitstellungssystem das Verwendungssystem umfassen.
  • Die Erfindung betrifft optional außerdem ein Trainingssystem zum Verwenden eines mit einem oben beschriebenen Bereitstellungssystem bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion. Dabei ist die trainierte Funktion ausgebildet, bei einer oben beschriebenen computerimplementierten Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung mit einem oben beschriebenen Verwendungssystem angewendet zu werden. Dabei umfasst das Trainingssystem eine Schnittstelle und eine Recheneinheit. Dabei ist die Schnittstelle zum Empfangen von dem bereitgestellten Trigger-Token zugeordneten Zeitstempeln von einem System ausgebildet. Dabei ist die Schnittstelle weiterhin zum Empfangen von einem Zeitpunkt eines technischen Defektes des Systems ausgebildet. Dabei ist die Recheneinheit zum Bestimmen eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems durch Anwenden der trainierten Funktion auf die Zeitstempel ausgebildet. Dabei ist die Recheneinheit weiterhin zum Anpassen mindestens eines Parameters der trainierten Funktion basierend auf einem Vergleich des bestimmten voraussichtlichen Zeitpunktes und des empfangenen Zeitpunktes ausgebildet. Dabei ist die Schnittstelle weiterhin zum Bereitstellen der trainierten Funktion ausgebildet.
  • Ein solches Trainingssystem kann insbesondere dazu ausgebildet sein, die zuvor beschriebene Verwendung eines mit einem oben beschriebenen Bereitstellungssystem bereitgestellten Trigger-Token zum Bereitstellen der trainierten Funktion auszuführen. Das Trainingssystem ist dazu ausgebildet diese Verwendung und seine Aspekte auszuführen, indem die Schnittstelle und die Recheneinheit ausgebildet sind, die entsprechenden Verfahrensschritte auszuführen.
  • Insbesondere kann die oben beschriebene medizinische Vorrichtung alternativ oder zusätzlich zu dem Bereitstellungssystem und/oder dem Verwendungssystem das Trainingssystem umfassen.
  • Die Erfindung betrifft auch ein Computerprogrammprodukt mit einem Computerprogramm sowie ein computerlesbares Medium. Eine weitgehend softwaremäßige Realisierung hat den Vorteil, dass auch schon bisher verwendete Bereitstellungssysteme und/der Verwendungssysteme und/oder Trainingssysteme auf einfache Weise durch ein Software-Update nachgerüstet werden können, um auf die beschriebene Weise zu arbeiten. Ein solches Computerprogrammprodukt kann neben dem Computerprogramm gegebenenfalls zusätzliche Bestandteile wie z. B. eine Dokumentation und/oder zusätzliche Komponenten, sowie Hardware-Komponenten, wie z.B. Hardware-Schlüssel (Dongles etc.) zur Nutzung der Software, umfassen.
  • Insbesondere betrifft die Erfindung auch ein Computerprogrammprodukt mit einem Computerprogramm, welches direkt in einen Speicher einem Bereitstellungssystem und/der Verwendungssysteme und/oder Trainingssysteme ladbar ist, mit Programmabschnitten, um alle Schritte des oben beschriebenen Verfahrens und/oder der beschriebenen Verwendungen und seine Aspekte auszuführen, wenn die Programmabschnitte von dem Bereitstellungssystem und/der Verwendungssysteme und/oder Trainingssysteme ausgeführt werden.
  • Insbesondere betrifft die Erfindung ein computerlesbares Speichermedium, auf welchem von einem Bereitstellungssystem und/der Verwendungssysteme und/oder Trainingssysteme lesbare und ausführbare Programmabschnitte gespeichert sind, um alle Schritte des oben beschriebenen Verfahrens und/oder Verwendungen und seine Aspekte auszuführen, wenn die Programmabschnitte von dem Bereitstellungssystem und/der Verwendungssysteme und/oder Trainingssysteme ausgeführt werden.
  • Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung werden klarer und verständlicher im Zusammenhang mit folgenden Figuren und ihren Beschreibungen. Dabei sollen die Figuren und Beschreibungen die Erfindung und ihre Ausführungsformen in keiner Weise einschränken.
  • In verschiedenen Figuren sind gleiche Komponenten mit korrespondierenden Bezugszeichen versehen. Die Figuren sind in der Regel nicht maßstabsgetreu.
  • Es zeigen
    • 1 ein erstes Ausführungsbeispiel eines computerimplementierten Verfahrens zum Bereitstellen von einem Trigger-Token,
    • 2 ein zweites Ausführungsbeispiel eines computerimplementierten Verfahrens zum Bereitstellen von einem Trigger-Token,
    • 3 ein erstes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems,
    • 4 ein zweites Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems,
    • 5 ein drittes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems,
    • 6 ein viertes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems,
    • 7 ein Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion,
    • 8 ein Bereitstellungssystem zum Bereitstellen von einem Trigger-Token,
    • 9 ein Verwendungssystem zum Verwenden des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems,
    • 10 ein Trainingssystem zur Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion.
  • 1 zeigt ein erstes Ausführungsbeispiel eines computerimplementierten Verfahrens zum Bereitstellen von einem Trigger-Token.
  • In einem Verfahrensschritt eines Empfangens REC-1 einer Logdatei wird eine Logdatei eines Systems empfangen. Die Logdatei umfasst dabei eine Mehrzahl von Ereignis-Beschreibungen. Eine Ereignis-Beschreibung kann durch ein Ereignis des Systems ausgelöst werden. Eine Ereignis-Beschreibung kann beispielsweise eine Statusmeldung des Systems oder einer Komponente des Systems sein. Das auslösende Ereignis kann somit eine Statusabfrage bzw. eine Statusmeldung sein. Alternativ kann eine Ereignis-Beschreibung beispielsweise eine Verwendung des Systems beschreiben. Das auslösende Ereignis kann also eine Verwendung des Systems sein. Beispielsweise kann die Verwendung des Systems durch eine Art der Verwendung und/oder durch eine Einstellung eines (System-)Parameters bei der Verwendung und/oder durch eine Auffälligkeit bei der Verwendung in der Ereignis-Beschreibung beschrieben werden. Einer Teilmenge der Ereignis-Beschreibungen ist ein Zeitstempel zugeordnet. Mit anderen Worten ist jeder Ereignis-Beschreibung der Teilmenge von Ereignis-Beschreibungen ein Zeitstempel zugeordnet. Die Logdatei umfasst somit für die Teilmenge von Ereignis-Beschreibungen jeweils ein Paar aus Ereignis-Beschreibung und zugeordnetem Zeitstempel. Der Zeitstempel gibt an, wann das Ereignis, dass die entsprechende Ereignis-Beschreibung ausgelöst hat, stattgefunden hat. Alternativ kann der Zeitstempel angeben, wann die Ereignis-Beschreibung in die Logdatei eingetragen wurde. Der Zeitstempel gibt ein Datum an. Insbesondere kann der Zeitstempel eine Uhrzeit angeben. Der Zeitstempel kann in einem standardisierten Format angeben sein. Die Logdatei ist zeichencodiert.
  • Das System ist ein medizinisches System, beispielsweise ein medizinisches Bildgebungssystem. Insbesondere kann das System ein Röntgensystem oder ein CT-System oder ein C-Bogen-System oder ein Mammographiesystem oder ein Angiographiesystem oder ein MRT-System oder ein Ultraschallsystem etc. sein. Insbesondere kann also das System eine medizinische Vorrichtung, insbesondere eine Röntgenvorrichtung sein. Die Röntgenvorrichtung ist dabei ein konventionelles Röntgensystem oder ein Mammographiesystem oder ein Angiographiesystem oder ein C-Bogen-System oder ein CT-System.
  • Die Logdatei kann direkt von dem System empfangen werden. Mit anderen Worten kann das System selbst die Logdatei zum Empfangen bereitstellen. Die Logdatei kann alternativ von einer Datenbank empfangen werden. Die Datenbank kann dabei lokal oder in einem Cloud-System empfangen werden. Alternativ kann die Logdatei von einem Speichermedium empfangen bzw. heruntergeladen werden.
  • In einem Verfahrensschritt eines Empfangens REC-2 eines Zeitpunktes eines technischen Defektes des Systems wird der Zeitpunkt, an dem ein technischer Defekt des Systems eingetreten ist, empfangen. Der Zeitpunkt des technischen Defektes kann wie auch die Logdatei von dem System selbst oder von einer Datenbank oder von einem Speichermedium empfangen werden. Der Zeitpunkt des technischen Defektes gibt ein Datum an, an dem ein technischer Defekt des Systems eingetreten ist. Der Zeitpunkt kann außerdem eine Uhrzeit des technischen Defektes angeben. Der technische Defekt kann beispielsweise ein Ausfall des Systems oder einer Komponente des Systems sein. Alternativ kann der technische Defekt auch nur eine notwendige Wartung des Systems oder eine Komponente des Systems beispielsweise aufgrund einer Laufzeit sein.
  • In Ausführungen der Erfindung kann der Zeitpunkt des technischen Defektes auch als Zeitintervall bis zu dem technischen Defekt des Systems angegeben werden. Mit anderen Worten kann der Zeitpunkt des technischen Defektes eine „Restlebensdauer“ des Systems angeben. Mit anderen Worten ist das Zeitintervall die „Restlebensdauer“ des Systems. Das Zeitintervall endet mit dem technischen Defekt des Systems. Das Zeitintervall kann an einem von der Logdatei umfassten Zeitstempel starten. Beispielsweise kann das Zeitintervall an dem frühesten oder an dem spätesten von der Logdatei umfassten Zeitstempel starten.
  • In einem Verfahrensschritt eines Extrahierens EXT von Tokens aus der Teilmenge von Ereignis-Beschreibungen werden Tokens basierend auf einer Token-Kategorie aus den Ereignis-Beschreibungen der Teilmenge extrahiert.
  • Jede Ereignis-Beschreibung bildet jeweils eine Gesamt-Zeichenkette. Die Gesamt-Zeichenkette umfasst wenigstens ein Zeichen. Insbesondere umfasst die Gesamt-Zeichenkette mehrere aneinander gereihte Zeichen. Ein Zeichen kann beispielsweise ein Buchstabe oder eine Ziffer oder ein Satzzeichen oder ein Leerzeichen sein.
  • Ein Buchstabe kann dabei ein beliebiger Buchstabe des Alphabetes von a bis z sein. Eine Ziffer kann dabei eine beliebige einstellige Zahl zwischen 0 und 9 sein. Ein Satzzeichen kann beispielsweise ein Punkt, ein Komma, ein Bindestrich, ein Unterstrich, ein Schrägstricht etc. sein.
  • Ein Token ist ebenfalls eine Zeichenkette, die wenigstens eines der oben genannten Zeichen umfasst. Jedes extrahierte Token ist dabei von wenigstens einer Gesamt-Zeichenkette umfasst. Mit anderen Worten ist jedes extrahierte Token von wenigstens einer Ereignis-Beschreibung umfasst.
  • Jedem extrahierten Token wird dabei der Zeitstempel der Ereignis-Beschreibung zugeordnet, aus der es extrahiert wurde.
  • Vor dem Extrahieren der Tokens können die Gesamt-Zeichenketten der Ereignis-Beschreibungen bearbeitet bzw. standardisiert werden. Beispielsweise können alle Großbuchstaben in Kleinbuchstaben umgewandelt werden. Alternativ oder zusätzlich können nur noch Buchstaben beibehalten werden. Alternativ können nur noch Ziffern beibehalten werden. Alternativ können Ziffern und Satzzeichen beibehalten werden etc. Die Bearbeitung bzw. Standardisierung der Gesamt-Zeichenketten hängt dabei von der Token-Kategorie ab.
  • Die Token-Kategorie gibt insbesondere ein Form der zu extrahierenden Zeichenkette an. Mit anderen Worten gibt die Token-Kategorie an, welche Art von Zeichen die extrahierten Tokens umfassen sollen. Alternativ oder zusätzlich kann die Token-Kategorie angeben, wie viele Zeichen die extrahierten Tokens umfassen sollen. Die Token-Kategorie kann in Ausführungen der Erfindung eine Buchstabenfolge und/oder eine Zahl und/oder ein Fehlercode sein.
  • Eine Buchstabenfolge umfasst wenigstens einen Buchstaben. Insbesondere umfasst eine Buchstabenfolge nur zusammenhängende Buchstaben. Eine Zahl umfasst wenigstens eine Ziffer. Insbesondere kann eine Zahl außerdem Satzzeichen umfassen. Ein Fehlercode kann durch eine bestimmte Zusammensetzung von Zeichen definiert sein. Beispielsweise kann ein Fehlercode dadurch definiert sein, dass er nur Buchstaben und Ziffern und genau sechs Zeichen insgesamt umfasst.
  • Das Extrahieren kann für verschiedene Token-Kategorien durchgeführt werden.
  • Zum Extrahieren der Tokens kann die Teilmenge der Ereignis-Beschreibungen basierend auf einem regulären Ausdruck gefiltert werden. Der reguläre Ausdruck basiert auf der Token-Kategorie. Mit anderen Worten kann der reguläre Ausdruck durch die Token-Kategorie vorgegeben sein. Reguläre Ausdrücke sind insbesondere aus dem Gebiet der theoretischen Informatik bekannt.
  • In einem Verfahrensschritt eines Bestimmens DET-1 des Trigger-Tokens wird das Trigger-Token aus den extrahierten Tokens bestimmt. Mit anderen Worten ist das Trigger-Token einer der extrahierten Tokens. Das Bestimmen DET-1 des Trigger-Tokens basiert auf einer Korrelation zwischen den den extrahierten Tokens zugeordneten Zeitstempeln und dem Zeitpunkt des technischen Defektes des Systems. Mit anderen Worten wird für jedes extrahierte Token eine Korrelation zwischen dem entsprechenden zugeordneten Zeitstempel und dem Zeitpunkt des technischen Defektes des Systems bestimmt. Der Zeitstempel des Tokens, das als Trigger-Token bestimmt wird, ist positiv mit dem Zeitpunkt des technischen Defektes korreliert. Beispielsweise kann „positiv korreliert“ bedeuten, dass das entsprechende Token immer in einem bestimmten Zeitraum vor dem technischen Defekt des Systems vorkommt. Alternativ kann „positiv korreliert“ bedeuten, dass das entsprechende Token in einem bestimmten Zeitraum vor dem technischen Defekt des Systems nie auftritt bzw. vorkommt. Mit anderen Worten bedeutet „positiv korreliert“, dass es einen zeitlichen Zusammenhang zwischen einem Auftreten des positiv korrelierten Tokens in der Logdatei und dem Zeitpunkt des technischen Defektes gibt. Insbesondere kann mehr als ein Trigger-Token bestimmt werden.
  • In Ausführungen der Erfindung kann die Korrelation zwischen wenigstens einem Zeitstempel eines beliebigen extrahierten Tokens und dem Zeitpunkt des technischen Defektes des Systems durch Anwenden einer trainierten Bestimmungsfunktion auf den wenigstens einen Zeitstempel und den Zeitpunkt des technischen Defektes bestimmt werden. Die Bestimmungsfunktion kann dabei insbesondere mit einem der oben beschriebenen Verfahren trainiert bzw. gelernt werden. Die trainierte Bestimmungsfunktion ist dazu ausgebildet, eine Stärke der Korrelation zu bestimmen. Insbesondere kann die Bestimmungsfunktion dazu ausgebildet sein, zu erkennen, ob das Token ein Trigger-Token ist.
  • In einem Verfahrensschritt eines Breitstellens PROV-1 des Trigger-Tokens wird das Trigger-Token für eine Verwendung bereitgestellt. Das Trigger-Token kann insbesondere auf einem Sever, insbesondere in einer Datenbank auf dem Sever, gespeichert werden. Alternativ kann das Trigger-Token auf einem Speichermedium gespeichert und auf diese Weise bereitgestellt werden.
  • 2 zeigt ein zweites Ausführungsbeispiel eines computerimplementierten Verfahrens zum Bereitstellen von einem Trigger-Token.
  • Die Verfahrensschritte des Empfangens REC-1 einer Logdatei, des Empfangens REC-2 eines Zeitpunktes eines technischen Defektes, des Extrahierens EXT von Tokens, des Bestimmens DET-1 des Trigger-Tokens und des Bereitstellens PROV-1 des Trigger-Tokens sind analog zu der Beschreibung zu 1 ausgebildet.
  • Das Verfahren umfasst zusätzlich einen Verfahrensschritt eines Gruppierens GRP von aus unterschiedlichen Ereignis-Beschreibungen extrahierten identischen Tokens. In einer Logdatei kann ein Token mehrfach auftreten bzw. vorkommen. Dabei kommt das Token in mehreren verschiedenen Ereignis-Beschreibungen der Logdatei vor. Mit anderen Worten umfassen mehrere Ereignis-Beschreibungen dasselbe bzw. ein identisches Token. Das bedeutet, dass das Token an mehreren verschiedenen Zeitpunkten in die Logdatei eingetragen wurde. Dem Token können also die Zeitstempel aller Ereignis-Beschreibungen, die das Token umfassen, zugeordnet werden. In dem Verfahrensschritt des Gruppierens GRP werden derartige, mehrfach vorkommende bzw. auftretende Tokens gruppiert. Eine Gruppe eines extrahierten Tokens entspricht somit einem Token, der ein oder mehrfach extrahiert wurde und dem somit ein oder mehr Zeitstempel zugeordnet werden können. Somit kann ein zeitlicher Verlauf des Auftretens eines solchen Tokens in der Logdatei analysiert werden, wenn dem Token mehr als ein Zeitstempel zugeordnet ist.
  • Die Korrelation der Zeitstempel der einzelnen Tokens mit dem Zeitpunkt des technischen Defektes zum Bestimmen des Trigger-Tokens basiert dann auf den den extrahierten Tokens zugeordneten Zeitstempeln. Mit anderen Worten kann für die Zeitstempel jedes Token eine Korrelation zwischen dem oder den zugeordneten Zeitstempeln und dem Zeitpunkt des technischen Defektes des Systems bestimmt werden. Auf diese Weise kann beispielsweise festgestellt werden, ob eine Häufigkeit des Auftretens des entsprechenden Tokens mit abnehmendem zeitlichen Abstand zu dem Zeitpunkt des technischen Defektes zu- oder abnimmt. Mit anderen Worten kann analysiert werden, ob eine Frequenz des Auftretens eines derart gruppierten Tokens in der Logdatei mit abnehmendem zeitlichen Abstand zu dem Zeitpunkt des technischen Defektes zu- oder abnimmt. Die Frequenz beschreibt das Auftreten bzw. Vorkommen des Tokens innerhalb eine bestimmten Zeitintervalls. Eine positive Korrelation kann dann durch eine Zunahme oder eine Abnahme der Frequenz mit abnehmendem zeitlichen Abstand zu dem Zeitpunkt des technischen Defektes des Systems gekennzeichnet sein.
  • Das Trigger-Token ist dann ein Token, dessen Auftreten bzw. Vorkommen in der Logdatei mit dem Zeitpunkt des technischen Defektes korreliert. Beispielsweise kann das Trigger-Token mit zeitlich abnehmendem Abstand zu dem Zeitpunkt des technischen Defektes immer häufiger oder immer seltener in der Logdatei auftreten bzw. vorkommen.
  • 3 zeigt ein erstes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems.
  • Das Trigger-Token wird mit einem Verfahren, welches gemäß den Beschreibungen zu den 1 und 2 ausgebildet ist, bereitgestellt.
  • In einem Verfahrensschritt eines Empfangens REC-3 einer Logdatei, wird die Logdatei des Systems empfangen, das überwacht und dessen Wartung gegebenenfalls initiiert werden soll. Dabei kann die Logdatei direkt von dem System empfangen werden oder von einer Datenbank oder einem Speichermedium übertragen werden. Die Logdatei kann insbesondere in Echtzeit empfangen werden. Mit anderen Worten kann die Logdatei kontinuierlich empfangen und wie im Folgenden beschrieben analysiert bzw. ausgewertet werden und gegebenenfalls zeitnah eine notwendige Wartung initiiert werden. Mit anderen Worten können Änderungen der Logdatei kontinuierlich empfangen werden.
  • Die Logdatei ist dabei wie bezüglich 1 beschrieben ausgebildet. Die Logdatei umfasst also eine Mehrzahl von Ereignis-Beschreibungen. Dabei ist wenigstens einer Teilmenge der Ereignis-Beschreibungen jeweils ein Zeitstempel zugeordnet ist. Die Logdatei umfasst also Paare von Ereignis-Beschreibungen mit zugeordneten Zeitstempeln.
  • In einem Verfahrensschritt eines Bestimmens DET-2 eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens in der Logdatei, wird die Logdatei nach dem Trigger-Token durchsucht und das Auftreten des Trigger-Tokens analysiert. Insbesondere können dafür im Vorfeld die Ereignis-Beschreibungen der Logdatei wie vor dem Extrahieren EXT der Tokens bearbeitet bzw. standardisiert werden, wie bezüglich 1 beschrieben. Insbesondere kann in dem Verfahrensschritt bestimmt werden, wann das Trigger-Token das erste Mal in der Logdatei auftritt. In Abhängigkeit des Trigger-Tokens kann davon abgeleitet werden, wann voraussichtlich der technische Defekt des Systems eintritt. Wenn das Trigger-Token in mehr als einer Ereignis-Beschreibung der Logdatei auftritt bzw. mehr als einmal in der Logdatei bestimmt werden kann, kann die Häufigkeit des Auftretens des Trigger-Tokens analysiert werden. Insbesondere kann die Häufigkeit in Abhängigkeit der Zeit, also die Frequenz des Auftretens des Trigger-Tokens analysiert werden. Dafür werden die Zeitstempel der Ereignis-Beschreibungen ausgewertet, die das Trigger-Token umfassen. In Abhängigkeit der Häufigkeit bzw. der Frequenz des Auftretens des Trigger-Tokens kann dann ein voraussichtlicher Zeitpunkt des erwarteten technischen Defektes bestimmt werden bzw. abgeleitet werden.
  • In Ausführungen der Erfindung kann außerdem von der Art des Trigger-Tokens abgeleitet werden, welcher technische Defekt eintreten wird. Verschiedene technische Defekte des Systems können durch verschiedene Trigger-Tokens gekennzeichnet sein.
  • In einem Verfahrensschritt eines Initiierens INI der Wartung des Systems wird die Wartung in Abhängigkeit des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei initiiert. Das Initiieren INI der Wartung kann dabei beispielsweise ein Starten eines Wartungsprogramms auf dem System umfassen. Alternativ kann das Initiieren INI der Wartung ein Informieren eines Service-Technikers über die Notwendigkeit einer Wartung des Systems umfassen.
  • Die Wartung wird dabei vor dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes initiiert. Mit anderen Worten wird die Wartung derart initiiert, dass der technische Defekt verhindert oder zumindest verzögert werden kann.
  • Durch die Wartung soll eine Funktionsfähigkeit des technischen Systems sichergestellt werden.
  • In Ausführungen der Erfindung kann beim Initiieren INI der Wartung eine Auslastung bzw. eine Nutzung des Systems berücksichtigt werden. Beispielsweise kann die Wartung derart initiiert werden, dass sie am Wochenende oder nachts durchgeführt wird, wenn das System nicht genutzt wird.
  • 4 zeigt ein zweites Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems.
  • Die Verfahrensschritte des Empfangens REC-3 der Logdatei des Systems, des Bestimmens DET-2 des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei und des Initiierens INI der Wartung sind analog zu der Beschreibung des Ausführungsbeispiels in 3 ausgebildet.
  • Die Verwendung des bereitgestellten Trigger-Tokens umfasst weiterhin einen Verfahrensschritt eines automatisierten Durchführen PERF der Wartung. Die Wartung kann somit automatisch initiiert und durchgeführt werden. Das automatische Durchführen PERF der Wartung kann beispielsweise ein Ausführen eines computerimplementierten Wartungsprogramms umfassen.
  • Beispielsweise kann das System eine Röntgenvorrichtung sein. Die Röntgenvorrichtung kann dabei beispielsweise ein konventionelles Röntgensystem oder ein Mammographiesystem oder ein Angiographiesystem oder ein CT-System oder ein C-Bogen-System sein. Eine derartige Röntgenvorrichtung umfasst eine Röntgenröhre. Die Röntgenröhre kann dabei beispielsweise eine Transmissionsröntgenröhre oder eine Drehanoden-Röntgenröhre sein. Zum Erzeugen von Röntgenstrahlung wird ein Elektronenstrahl auf ein Target fokussiert. Beim Abbremsen des Elektronenstrahls an dem Target wird die Röntgenstrahlung erzeugt. Die Elektronen des Elektronenstrahl treten auf Grund des glühelektrischen Effektes aus einer Glühwendel, einem sogenannten Filament, aus und werden anschließend in einem elektrischen Feld beschleunigt. Das automatisierte Durchführen PERF der Wartung kann dann beispielsweise eine automatisierte Justage der Röntgenröhre umfassen. Mit anderen Worten kann das automatisierte Durchführen PERF der Wartung ein Starten eines Wartungsprogramms zur Justage des Elektronenstrahls auf dem Target umfassen. Dabei kann der Fokus des Elektronenstrahls auf dem Target fokussiert bzw. justiert werden. Alternativ oder zusätzlich kann das automatisierte Durchführen PERF der Wartung ein Umschalten eines Betriebsmodus' eines Fokus` der Röntgenröhre umfassen. Der Fokus der Röntgenröhre entspricht dem Punkt, an dem der Elektronenstrahl auf dem Target auftrifft. Typischerweise kann bei einer Röntgenröhre zwischen zwei oder drei Fokusgrößen ausgewählt werden. Die verschiedenen Fokusgrößen werden durch verschiedene Betriebsmodi vorgegeben. Das automatisierte Durchführen PERF der Wartung kann dann ein automatisiertes Umschalten zwischen den Fokusgrößen umfassen. Beispielsweise kann der Betriebsmodus, also die Fokusgröße gewechselt bzw. geändert werden, wenn eine Fokussierung mit einer bestimmten Größe auf Grund technischer Probleme nicht mehr möglich ist. Zum automatisierten Durchführen PERF der Wartung kann also ein Wartungsprogramm ausgeführt werden, welches automatisiert den Betriebsmodus der Röntgenröhre in Bezug auf die Fokusgröße umschaltet. Die beschriebenen Fälle sind als Beispiele zu betrachten. Andere ähnliche automatisierte Wartungen sind denkbar.
  • Insbesondere kann das Wartungsprogramm, das ausgeführt werden soll, in Abhängigkeit des Trigger-Tokens bestimmt werden. Verschiedene Trigger-Tokens können das Ausführen verschiedener Wartungsprogramme initiieren, die anschließend automatisiert ausgeführt werden.
  • 5 zeigt ein drittes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems.
  • Die Verfahrensschritte des Empfangens REC-3 der Logdatei des Systems, des Bestimmens DET-2 des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei und des Initiierens INI der Wartung sind analog zu der Beschreibung des Ausführungsbeispiels in 3 ausgebildet. Der Verfahrensschritt des automatisierten Durchführens PERF der Wartung des Systems kann optional wie gemäß 4 beschrieben, ausgebildet sein.
  • Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Bestimmens DET-3 eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems in Abhängigkeit des dem Trigger-Token zugeordneten Zeitstempels bei erstmaligem Auftreten des Trigger-Tokens in der Logdatei. Insbesondere kann aus der Korrelation, die in dem Verfahren zum Bereitstellen von dem Trigger-Token bestimmt wurde, bekannt sein, wie lang nach dem erstmaligen Auftreten des Trigger-Tokens in der Logdatei der technische Defekt des Systems eintritt. Mit anderen Worten kann ein typischer Wert für einen Zeitabstand zwischen dem dem Trigger-Token beim erstmaligen Auftreten zugeordneten Zeitstempel und dem Zeitpunkt des technischen Defektes bekannt sein. Daraus kann der voraussichtliche Zeitpunkt des erwarteten technischen Defektes des Systems bestimmt werden, wenn das Trigger-Token zum ersten Mal in der Logdatei auftritt.
  • Das Initiieren INI der Wartung hängt dann von dem dem Trigger-Token zugeordneten Zeitstempel und dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems ab. Die Wartung kann in dem Zeitintervall zwischen dem Zeitstempel und dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes initiiert werden. Insbesondere kann die Wartung initiiert und gegebenenfalls auch durchgeführt werden, bevor der technische Defekt eintritt.
  • 6 zeigt ein viertes Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems.
  • Die Verfahrensschritte des Empfangens REC-3 der Logdatei des Systems, des Bestimmens DET-2 des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Tokens in der Logdatei und des Initiierens INI der Wartung sind analog zu der Beschreibung des Ausführungsbeispiels in 3 ausgebildet. Der Verfahrensschritt des automatisierten Durchführens PERF der Wartung des Systems kann optional wie gemäß 4 beschrieben, ausgebildet sein.
  • Die Logdatei kann das Trigger-Token mehrfach umfassen. Dabei wird das Trigger-Token von mehr als einer Ereignis-Beschreibung der Logdatei umfasst. Den Ereignis-Beschreibungen ist dabei jeweils ein Zeitstempel zugeordnet. Die Zeitstempel der Ereignis-Beschreibungen, die das Trigger-Token umfassen, sind auch dem Trigger-Token zugeordnet. Die dem Trigger-Token zugeordneten Zeitstempel beschreiben dann einen zeitlichen Verlauf des Auftretens bzw. Vorkommens des Trigger-Tokens in der Logdatei. Das Initiieren INI der Wartung des Systems hängt in diesem Fall von dem zeitlichen Verlauf, also von den dem Trigger-Token zugeordneten Zeitstempeln, ab.
  • Die Verwendung umfasst einen weiteren Verfahrensschritt eines Anwendens APP einer trainierten Funktion auf die dem Trigger-Token zugeordneten Zeitstempel. Dabei wird ein voraussichtlicher Zeitpunkt eines erwarteten technischen Defektes des Systems bestimmt. Die trainierte Funktion basiert dabei auf einem maschinellen Lernen Algorithmus (engl.: Machine Learning). Die trainierte Funktion ist dazu ausgebildet, aus dem zeitlichen Verlauf der dem Trigger-Token zugeordneten Zeitstempel abzuleiten, wann der technische Defekt voraussichtlich eintritt. Die trainierte Funktion kann wie bezüglich 7 beschrieben trainiert worden sein.
  • Die Verwendung umfasst einen weiteren Verfahrensschritt eines Bereitstellens PROV-2 des voraussichtlichem Zeitpunktes des erwarteten technischen Defektes. Das Initiieren INI der Wartung hängt dann von dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes ab. Dabei wird die Wartung in einem Zeitintervall vor dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes initiiert. Die Wartung kann insbesondere in einem Zeitintervall zwischen dem Zeitstempel der neusten Ereignis-Beschreibung in der Logdatei und dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes initiiert werden. Die Wartung wird dabei derart rechtzeitig initiiert, dass der technische Defekt verhindert oder wenigstens hinausgezögert werden kann.
  • 7 zeigt ein Ausführungsbeispiel einer computerimplementierten Verwendung eines bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion.
  • Das Trigger-Token wird mit einem Verfahren, welches gemäß den Beschreibungen zu den 1 und 2 ausgebildet ist, bereitgestellt.
  • Die trainierte Funktion ist dazu ausgebildet in einer Verwendung gemäß der Beschreibung zu 6 angewendet zu werden.
  • Die Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen der trainierten Funktion umfasst einen Verfahrensschritt eines Empfangens REC-4 von dem bereitgestellten Trigger-Token zugeordneten Zeitstempeln. Dabei sind dem Trigger-Token, wie bezüglich 6 beschrieben, mehr als ein Zeitstempel zugeordnet. Die Zeitstempel wurden basierend auf einer Logdatei eines Systems, wie oben beschrieben, bestimmt. Die Zeitstempel stellen einen zeitlichen Verlauf eines Auftretens bzw. Vorkommens des Trigger-Tokens in der Logdatei des Systems dar. Die Logdatei ist dabei wie bezüglich 1 beschrieben ausgebildet. Die Zeitstempel können in einer standardisierten Form ausgebildet sein. Dabei geben die Zeitstempel ein Datum an. Insbesondere können die Zeitstempel zusätzlich eine Uhrzeit angeben.
  • Die Verwendung umfasst außerdem einen Verfahrensschritt eines Empfangens REC-5 von einem Zeitpunkt eines technischen Defektes des Systems. Der Zeitpunkt gibt ein Datum des technischen Defektes des Systems an. Insbesondere kann der Zeitpunkt zusätzlich eine Uhrzeit des technischen Defektes des Systems angeben. In Ausführungen der Erfindung kann der Zeitpunkt des technischen Defektes auch als Zeitintervall bis zu dem technischen Defekt des Systems angegeben sein. Der technische Defekt definiert also das Ende des Zeitintervalls. Der Anfang des Zeitintervalls kann entweder durch den frühesten oder den spätesten Zeitstempel in der Logdatei definiert sein. Alternativ kann der Anfang des Zeitintervalls beispielsweise durch den Zeitstempel des ersten oder des letzten Auftretens des Trigger-Tokens in der Logdatei definiert sein.
  • Die Verwendung umfasst einen weiteren Verfahrensschritt eines Bestimmens DET-4 eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems durch Anwenden der trainierten Funktion auf die Zeitstempel. Mit anderen Worten dienen die dem Trigger-Token zugeordneten Zeitstempel als Eingangsdaten der trainierten Funktion. Die Ausgangsdaten der trainierten Funktion umfassen den voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems.
  • Die Verwendung umfasst weiterhin einen Verfahrensschritt eines Anpassens ADA mindestens eines Parameters der trainierten Funktion basierend auf einem Vergleich des bestimmten voraussichtlichen Zeitpunktes des erwarteten technischen Defektes und des empfangenen Zeitpunktes des technischen Defektes. Dabei wird der wenigstens eine Parameter derart angepasst, dass bei einem nochmaligen Anwenden der trainierten Funktion auf die Zeitstempel der bestimmte voraussichtliche Zeitpunkt und der empfangene Zeitpunkt besser übereinstimmen. Dieser Schritt wird so lange wiederholt, bis ein Abbruchkriterium erreicht ist. Das Abbruchkriterium kann beispielsweise eine maximale Anzahl an Wiederholungen und/oder ein Unterschreiten einer maximalen Abweichung zwischen dem bestimmten voraussichtlichen Zeitpunkt und dem empfangenen Zeitpunkt sein. Dieser Prozess wird als Lernen bzw. Training der trainierten Funktion bezeichnet.
  • In einem Verfahrensschritt des Bereitstellens PROV-3 der trainierten Funktion wird die derart trainierte Funktion für eine Verwendung bereitgestellt. Insbesondere kann die trainierte Funktion für eine Verwendung gemäß der Beschreibung zu 6 bereitgestellt werden.
  • 8 zeigt ein Bereitstellungssystem BSYS zum Bereitstellen von einem Trigger-Token. 9 zeigt ein Verwendungssystem VSYS zum Verwenden des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems. 10 zeigt ein Trainingssystem TSYS zur Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion.
  • Das dargestellte Bereitstellungssystem BSYS zum Bereitstellen von einem Trigger-Token ist dazu ausgebildet ein erfindungsgemäßes Verfahren zum Bereitstellen von einem Trigger-Token auszuführen. Das Bereitstellungssystem BSYS umfasst eine Bereitstellungs-Schnittstelle BSYS.IF, eine Bereitstellungs-Recheneinheit BSYS.CU und eine Bereitstellungs-Speichereinheit BSYS.MU. Das dargestellte Verwendungssystem VSYS ist dazu ausgebildet, eine erfindungsgemäße Verwendung des bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems auszuführen. Das Verwendungssystem VSYS umfasst eine Verwendungs-Schnittstelle VSYS-IF, eine Verwen-dungs-Recheneinheit VSYS.CU und eine Verwendungs-Speichereinheit VSYS-MU. Das dargestellte Trainingssystem TSYS ist dazu ausgebildet, eine erfindungsgemäße Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion auszuführen. Das Trainingssystem TSYS umfasst eine Trainings-Schnittstelle TSYS-IF, eine Trainings-Recheneinheit TSYS.CU und eine Trainings-Speichereinheit TSYS-MU.
  • Das Bereitstellungssystem BSYS und/oder das Verwendungssystem VSYS und/oder das Trainingssystem TSYS kann insbesondere ein Computer, ein Mikrocontroller oder ein integrierter Schaltkreis (integrated circuit, IC) sein. Alternativ kann das Bereitstellungssystem BSYS und/oder das Verwendungssystem VSYS und/oder das Trainingssystem TSYS ein reales oder virtuelles Computer-Netzwerk sein (eine technische Bezeichnung für ein reales Computer-Netzwerk ist „Cluster“, eine technische Bezeichnung für ein virtuelles Computer-Netzwerk ist „Cloud“). Das Bereitstellungssystem BSYS und/oder das Verwendungssystem VSYS und/oder das Trainingssystem TSYS kann als virtuelles System ausgebildet sein, welches auf einem Computer oder einem realen Computer-Netzwerk oder einem virtuellen Computer-Netzwerk ausgeführt wird (eine technische Bezeichnung ist „Virtualization“) .
  • Die Bereitstellungs-Schnittstelle BSYS.IF und/oder die Verwendungs-Schnittstelle VSYS.IF und/oder die Trainings-Schnittstelle TSYS.IF kann eine Hardware- oder Software-Schnittstelle sein (beispielsweise ein PCI bus, USB oder Firewire). Die Bereitstellungs-Recheneinheit BSYS.CU und/oder die Verwendungs-Recheneinheit VSYS.CU und/oder die Trainings-Recheneinheit TSYS.CU kann Hardware und/oder Software-Bestandteile umfassen, beispielsweise einen Mikroprozessor oder einen sogenannten FPGA (Field Programmable Gate Way). Die Bereitstellungs-Speichereinheit BSYS.MU und/oder die Verwendungs-Speichereinheit VSYS.MU und/oder die Trainings-Speichereinheit TSYS.MU kann als nicht permanent arbeitender Arbeitsspeicher (Random Access Memory, RAM) oder als permanenter Massenspeicher (Festplatte, USB-Stick, SD-Karte, Solid State Disk (SSD)) ausgebildet sein.
  • Die Bereitstellungs-Schnittstelle BSYS.IF und/oder die Verwendungs-Schnittstelle VSYS.IF und/oder die Trainings-Schnittstelle TSYS.IF kann insbesondere eine Mehrzahl an Sub-Schnittstellen umfassen, die unterschiedliche Verfahrensschritte des jeweiligen erfindungsgemäßen Verfahrens bzw. Verwendung ausführen. Mit anderen Worten kann die Bereitstellungs-Schnittstelle BSYS.IF und/oder die Verwendungs-Schnittstelle VSYS.IF und/oder die Trainings-Schnittstelle TSYS.IF als eine Mehrzahl an Bereitstellungs-Schnittstellen BSYS.IF und/oder die Verwendungs-Schnittstellen VSYS.IF und/oder die Trainings-Schnittstellen TSYS.IF ausgebildet sein. Die Bereitstellungs-Recheneinheit BSYS.CU und/oder die Verwendungs-Recheneinheit VSYS.CU und/oder die Trainings-Recheneinheit TSYS.CU kann insbesondere eine Mehrzahl an Sub-Recheneinheiten umfassen, die unterschiedliche Verfahrensschritte des jeweiligen erfindungsgemäßen Verfahrens bzw. Verwendung ausführen. Mit anderen Worten kann die Bereitstellungs-Recheneinheit BSYS.CU und/oder die Verwendungs-Recheneinheit VSYS.CU und/oder die Trainings-Recheneinheit TSYS.CU als eine Mehrzahl an Bereitstellungs-Recheneinheiten BSYS.CU und/oder die Verwendungs-Recheneinheiten VSYS.CU und/oder die Trainings-Recheneinheiten TSYS.CU ausgebildet sein.
  • In Ausführungen der Erfindung kann das Bereitstellungssystem BSYS und/oder das Verwendungssystem VSYS und/oder das Trainingssystem TSYS von einer medizinischen Vorrichtung MV, insbesondere einer Röntgenvorrichtung, umfasst sein. Die Röntgenvorrichtung kann insbesondere ein konventionelles Röntgensystem oder ein CT-System oder ein C-Bogen-System oder ein Mammographiesystem oder ein Angiographiesystem sein. Insbesondere kann die Röntgenvorrichtung wenigstens eine Röntgenröhre und einen Röntgendetektor umfassen.
  • Wo noch nicht explizit geschehen, jedoch sinnvoll und im Sinne der Erfindung, können einzelne Ausführungsbeispiele, einzelne ihrer Teilaspekte oder Merkmale miteinander kombiniert bzw. ausgetauscht werden, ohne den Rahmen der hiesigen Erfindung zu verlassen. Mit Bezug zu einem Ausführungsbeispiel beschriebene Vorteile der Erfindung treffen ohne explizite Nennung, wo übertragbar, auch auf andere Ausführungsbeispiele zu.

Claims (15)

  1. Computerimplementiertes Verfahren zum Bereitstellen von einem Trigger-Token, wobei das Trigger-Token mit einer Notwendigkeit einer Wartung eines Systems korreliert, wobei das Verfahren folgende Schritte umfasst: - Empfangen (REC-1) einer Logdatei des Systems, wobei die Logdatei eine Mehrzahl von Ereignis-Beschreibungen umfasst, wobei einer Teilmenge der Mehrzahl von Ereignis-Beschreibungen ein Zeitstempel zugeordnet ist, - Empfangen (REC-2) eines Zeitpunktes eines technischen Defekts des Systems, - Extrahieren (EXT) von Tokens aus der Teilmenge der Ereignis-Beschreibungen basierend auf einer Token-Kategorie, wobei jedes der extrahierten Tokens als Zeichenkette in der Teilmenge von Ereignis-Beschreibung enthalten ist, - Bestimmen (DET-1) des Trigger-Tokens aus den extrahierten Tokens basierend auf einer Korrelation der den extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defektes des Systems, sodass der dem Trigger-Token zugeordnete Zeitstempel und der Zeitpunkt des technischen Defektes des Systems positiv korreliert sind, - Bereitstellen (PROV-1) des Trigger-Tokens.
  2. Verfahren nach Anspruch 1, wobei die Token-Kategorie eine der folgenden Token-Kategorien ist: - eine Buchstabenfolge, - eine Zahl und/oder - ein Fehlercode.
  3. Verfahren nach einem der vorhergehenden Ansprüche, wobei zum Extrahieren der Tokens die Teilmenge der Ereignis-Beschreibungen basierend auf einem regulären Ausdruck gefiltert wird, wobei der reguläre Ausdruck auf der Token-Kategorie basiert.
  4. Verfahren nach einem der vorhergehenden Ansprüche, weiterhin umfassend: - Gruppieren (GRP) von aus unterschiedlichen Ereignis-Beschreibungen extrahierten identischen Tokens, wobei das Bestimmen (DET-1) des Trigger-Tokens auf einer Korrelation der den Gruppen von extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defekts des Systems basiert.
  5. Computerimplementierte Verwendung eines nach einem der Ansprüche 1 bis 4 bereitgestellten Trigger-Tokens zur automatisierten Wartung eines Systems umfassend folgende Verfahrensschritte: - Empfangen (REC-3) einer Logdatei des Systems, - Bestimmen (DET-2) eines erstmaligen Auftretens und/oder einer Häufigkeit des Trigger-Tokens in der Logdatei, - Initiieren (INI) der Wartung des Systems in Abhängigkeit des erstmaligen Auftretens und/oder der Häufigkeit des Trigger-Token.
  6. Verwendung nach Anspruch 5, weiterhin umfassend folgenden Verfahrensschritt: - automatisiertes Durchführen (PERF) der Wartung.
  7. Verwendung nach Anspruch 6, wobei das System eine Röntgenvorrichtung umfasst, wobei die Röntgenvorrichtung einer Röntgenröhre umfasst, wobei der Verfahrensschritt des automatisierten Durchführens der Wartung insbesondere eine automatisierte Justage der Röntgenröhre und/oder ein Umschalten eines Betriebsmodus` eines Fokus` der Röntgenröhre umfasst.
  8. Verwendung nach einem der Ansprüche 5 bis 7, weiterhin umfassend folgenden Verfahrensschritt: - Bestimmen (DET-3) eines voraussichtlichen Zeitpunkts eines erwarteten technischen Defekts des Systems in Abhängigkeit des dem Trigger-Token zugeordneten Zeitstempels bei erstmaligem Auftreten des Trigger-Tokens in der Logdatei, wobei das Initiieren der Wartung von dem dem Trigger-Token zugeordneten Zeitstempel und dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems abhängt.
  9. Verwendung nach einem der Ansprüche 5 bis 7, wobei die Logdatei das Trigger-Token mehrfach umfasst, wobei dem Trigger-Token für jedes Auftreten in der Logdatei ein Zeitstempel zugeordnet ist, wobei das Initiierens (INI) der Wartung des Systems von einem zeitlichen Verlauf des Auftretens des Trigger-Tokens abhängt.
  10. Verwendung nach Anspruch 9, weiterhin umfassend folgende Verfahrensschritte: - Anwenden (APP) einer trainierten Funktion auf die dem Trigger-Token zugeordneten Zeitstempel zur Bestimmung eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems, - Bereitstellen (PROV-2) des voraussichtlichen Zeitpunktes des erwarteten technischen Defektes des Systems, wobei das Initiieren (INI) der Wartung von dem voraussichtlichen Zeitpunkt des erwarteten technischen Defektes des Systems abhängt.
  11. Computerimplementierte Verwendung eines nach Anspruch 4 bereitgestellten Trigger-Tokens zum Bereitstellen einer trainierten Funktion, wobei die Verwendung des bereitgestellten Trigger-Tokens zum Bereitstellen der trainierten Funktion folgende Verfahrensschritte umfasst: - Empfangen (REC-4) von dem bereitgestellten Trigger-Token zugeordneten Zeitstempeln von einem System, - Empfangen (REC-5) von einem Zeitpunkt eines technischen Defekts des Systems, - Bestimmen (DET-4) eines voraussichtlichen Zeitpunktes eines erwarteten technischen Defektes des Systems durch Anwenden der trainierten Funktion auf die Zeitstempel, - Anpassen (ADA) mindestens eines Parameters der trainierten Funktion basierend auf einem Vergleich des bestimmten voraussichtlichen Zeitpunktes und des empfangenen Zeitpunkts, - Bereitstellen (PROV-3) der trainierten Funktion.
  12. Bereitstellungssystem (BSYS) zum Bereitstellen von einem Trigger-Token, wobei das Trigger-Token mit einer Notwendigkeit einer Wartung eines Systems korreliert, wobei das Bereitstellungssystem (BSYS) eine Schnittstelle (BSYS.IF) und eine Recheneinheit (BSYS.CU) umfasst, wobei die Schnittstelle (BSYS.IF) zum Empfangen (REC-1) einer Logdatei des Bereitstellungssystems (BSYS) ausgebildet ist, wobei die Logdatei eine Mehrzahl von Ereignis-Beschreibungen umfasst, wobei einer Teilmenge der Mehrzahl von Ereignis-Beschreibungen ein Zeitstempel zugeordnet ist, wobei die Schnittstelle (BSYS.IF) weiterhin zum Empfangen (REC-2) eines Zeitpunktes eines technischen Defekts des Systems ausgebildet ist, wobei die Recheneinheit (BSYS.CU) zum Extrahieren (EXT) von Tokens aus der Teilmenge der Ereignis-Beschreibungen basierend auf einer Token-Kategorie ausgebildet ist, wobei jedes der extrahierten Tokens als Zeichenkette in der Teilmenge von Ereignis-Beschreibung enthalten ist, wobei die Recheneinheit (BSYS.CU) weiterhin zum Bestimmen (DET-1) des Trigger-Tokens aus den extrahierten Tokens basierend auf einer Korrelation der den extrahierten Tokens zugeordneten Zeitstempeln mit dem Zeitpunkt des technischen Defektes des Systems ausgebildet ist, sodass der dem Trigger-Token zugeordnete Zeitstempel und der Zeitpunkt des technischen Defektes des Systems positiv korreliert sind, wobei die Schnittstelle (BSYS.IF) weiterhin zum Bereitstellen (PROV-1) des Trigger-Tokens ausgebildet ist.
  13. Medizinische Vorrichtung (MV), insbesondere eine Röntgenvorrichtung, umfassend ein Bereitstellungssystem (BSYS) nach Anspruch 12.
  14. Computerprogrammprodukt mit einem Computerprogramm, welches direkt in einen Speicher (BSYS.CU) eines Bereitstellungssystems (BSYS) ladbar ist, mit Programmabschnitten, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 11 auszuführen, wenn die Programmabschnitte von dem Bereitstellungssystem (BSYS) ausgeführt werden
  15. Computerlesbares Speichermedium, auf welchem von einem Bereitstellungssystem (BSYS) lesbare und ausführbare Programmabschnitte gespeichert sind, um alle Schritte des Verfahrens nach einem der Ansprüche 1 bis 11 auszuführen, wenn die Programmabschnitte von dem Bereitstellungssystem (BSYS) ausgeführt werden.
DE102021212607.3A 2021-11-09 2021-11-09 Verfahren zum Bereitstellen eines Trigger-Tokens Ceased DE102021212607A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102021212607.3A DE102021212607A1 (de) 2021-11-09 2021-11-09 Verfahren zum Bereitstellen eines Trigger-Tokens
US18/053,231 US20230146785A1 (en) 2021-11-09 2022-11-07 Method for provision of a trigger token

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021212607.3A DE102021212607A1 (de) 2021-11-09 2021-11-09 Verfahren zum Bereitstellen eines Trigger-Tokens

Publications (1)

Publication Number Publication Date
DE102021212607A1 true DE102021212607A1 (de) 2023-05-11

Family

ID=86053455

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021212607.3A Ceased DE102021212607A1 (de) 2021-11-09 2021-11-09 Verfahren zum Bereitstellen eines Trigger-Tokens

Country Status (2)

Country Link
US (1) US20230146785A1 (de)
DE (1) DE102021212607A1 (de)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10122953A1 (de) 2000-10-20 2002-05-02 Continental Teves Ag & Co Ohg Verfahren und Vorrichtung zur Behandlung von Störungsereignissen in Kraftfahrzeugkomponenten
DE10154534A1 (de) 2000-11-07 2002-06-27 Fisher Rosemount Systems Inc Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk
DE102010026678A1 (de) 2010-07-09 2012-01-12 Siemens Aktiengesellschaft Überwachungs-und Diagnosesystem für ein Fluidenergiemaschinensystem sowie Fluidenergiemachinensystem
DE102013001926A1 (de) 2013-02-05 2014-08-07 Abb Ag System und ein Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess
WO2016081970A1 (de) 2014-11-25 2016-06-02 S&T Ag Automatisierungssystem und verfahren zu dessen betrieb
DE112013007685T5 (de) 2013-12-16 2016-10-06 Mitsubishi Electric Corporation Vorrichtung zur numerischen Steuerung und Logging-Verfahren

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10122953A1 (de) 2000-10-20 2002-05-02 Continental Teves Ag & Co Ohg Verfahren und Vorrichtung zur Behandlung von Störungsereignissen in Kraftfahrzeugkomponenten
DE10154534A1 (de) 2000-11-07 2002-06-27 Fisher Rosemount Systems Inc Integrierte Alarmanzeige in einem Prozeßsteuerungsnetzwerk
DE102010026678A1 (de) 2010-07-09 2012-01-12 Siemens Aktiengesellschaft Überwachungs-und Diagnosesystem für ein Fluidenergiemaschinensystem sowie Fluidenergiemachinensystem
DE102013001926A1 (de) 2013-02-05 2014-08-07 Abb Ag System und ein Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess
DE112013007685T5 (de) 2013-12-16 2016-10-06 Mitsubishi Electric Corporation Vorrichtung zur numerischen Steuerung und Logging-Verfahren
WO2016081970A1 (de) 2014-11-25 2016-06-02 S&T Ag Automatisierungssystem und verfahren zu dessen betrieb

Also Published As

Publication number Publication date
US20230146785A1 (en) 2023-05-11

Similar Documents

Publication Publication Date Title
DE112012000797B4 (de) Mehrfach-Modellierungsparadigma für eine Vorhersageanalytik
DE102019218138A1 (de) Ein proaktives und automatisiertes System und Verfahren davon zum Reparieren eines suboptimalen Betriebs einer Maschine
DE102005020893A1 (de) System zur adaptiven Bestimmung von Operationseigenschaften einer ausführbaren Anwendung
DE102004015504A1 (de) Verfahren und Vorrichtung zur diagnostischen Wahl eines Wartungskonzepts für ein komplexes System
DE102018133196A1 (de) Bildbasierte wartungsvorhersage und detektion von fehlbedienungen
DE102006002247A1 (de) Verfahren und System zum Aktualisieren von Echtzeitdaten zwischen Intervallen
DE112007003612T5 (de) Alarmanalysesystem und Verfahren zur Statistiken über Alarme von einem Prozesskontrollsystem
DE102010034430A1 (de) Verfahren zur Konfiguration einer Bildgebungsvorrichtung
DE102018107233A1 (de) Verfahren zur automatischen Prozessüberwachung und Prozessdiagnose eines stückbasierten Prozesses (batch-Fertigung), insbesondere eines Spritzgießprozesses und eine den Prozess durchführende Maschine oder ein den Prozess durchführender Maschinenpark
DE102004015503A1 (de) Verfahren und Vorrichtung zum Korrigieren diagnostischer Analysekonzepte in komplexen Systemen
DE102013210719A1 (de) Verfahren und Systeme zum Verwalten von Cache-Speichern
EP3582443B1 (de) Grammatikerkennung
DE102019210562A1 (de) Verfahren und Vorrichtung zum Prüfen von Software
DE102021124256A1 (de) Mobile ki
DE102021212607A1 (de) Verfahren zum Bereitstellen eines Trigger-Tokens
DE102020114046A1 (de) Neuronales Maschinenübersetzungsverfahren, neuronales Maschinenübersetzungssystem, Lernverfahren, Lernsystem und Programm
EP3340250B1 (de) Bauteilidentifikation bei der fehlerbehandlung von medizinischen geräten
EP3812949A1 (de) Konfigurierbarer digitaler zwilling
DE10161655A1 (de) Verfahren und Vorrichtung zur Bereitstellung einer prädiktiven Wartung einer Komponente durch Verwendung von Markov-Übergangswahrscheinlichkeiten
DE102020212318A1 (de) Fallpriorisierung für ein medizinisches System
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
EP3951529A1 (de) Überwachungsvorrichtung und verfahren zur anomaliedetektion
EP3185807B1 (de) Verfahren und system zum betrieb einer aufbereitungsvorrichtung für chirugische instrumente
EP3779619A1 (de) Emergente risiken eines technischen systems
EP3026602A1 (de) Verfahren zum rechnergestützten verarbeiten von anfragen zur analyse von daten in einem datenspeicher

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R003 Refusal decision now final
R011 All appeals rejected, refused or otherwise settled