System und Verfahren zur Fehlererkennung und Fehlerursachen- Analyse in einem Netzwerk von Netzwerkkomponenten

Die Erfindung betrifft ein System und Verfahren zur Fehlerer kennung und Fehlerursachen-Analyse in einem Netzwerk von Netzwerkkomponenten .

Eine Datenverarbeitung von Ereignisdaten (Eventdaten)

und/oder Sensordaten dient beispielsweise dazu, kritische Zu stände oder Fehler in Industrie- oder Fabrikanlagen zu erken nen. Die Komponenten der Anlagen sind vernetzt und übertragen ihre Event- und Sensordaten zu entsprechenden Rechnern, wo die Verarbeitung stattfindet. "Internet of Things" (IoT),

"Web of Systems" (WoS) , "Industrie 4.0" oder "Cyber-Physical Systems" (CPS) sind Begriffe, die diese Thematik umschreiben.

Die Erstellung von modernen automatisierten Anlagen, wie zum Beispiel Produktionszellen in der Automobilindustrie oder in jeder beliebigen anderen Produktionsanlage, basiert auf dem Konzept von cyber-physikalischen Netzwerken (Cyber-Physical Systems) . Ein cyber-physikalisches Netzwerk bezeichnet den Verbund mechanisch-elektronischer Komponenten, aber auch chemischer Elemente mit softwaretechnischen Modulen, die über eine Dateninfrastruktur, wie zum Beispiel das Internet, miteinander kommunizieren und sich durch einen hohen Grad an Komplexität auszeichnet. Die Ausbildung von cyber

physikalischen Netzwerken entsteht aus der Vernetzung

eingebetteter Netzwerkkomponenten durch drahtgebundene oder drahtlose Kommunikationsnetze. Cyber-physikalische Netzwerke decken ein breites Spektrum möglicher Bereiche ab, in denen sie zum Einsatz kommen können. Hierzu gehören

medizintechnische Geräte und Systeme, Verkehrssteuerungs- und Verkehrslogistiksysteme, vernetzte Sicherheits- sowie

Fahrassistenzsysteme im Automobilbereich, industrielle

Prozesssteuerung- und Automatisierungsanlagen in der

Fertigung, Energieversorgungsmanagementsysteme, Infrastruktursysteme für Telekommunikation, und dergleichen mehr .

Große Netzwerke (Netzwerksysteme) dieser Art produzieren gro ße Mengen an Eventnachrichten bzw. Sensordaten über Zustände und Fehler (Events) von einzelnen Komponenten oder Sub- Netzwerken. Alle dieser Nachrichten müssen übertragen und verarbeitet werden. Im Rahmen dieser Erfindung wird als Event ein Ereignis innerhalb eines bestimmten Netzwerks oder einer Domäne bezeichnet. Es ist etwas, das bereits geschehen ist oder als etwas Geschehenes innerhalb eines bestimmten Anwen dungsbereichs (Domäne) betrachtet wird.

Eine Fehlererkennung muss möglichst in Echtzeit erfolgen, um eine schnelle Reaktion darauf zu ermöglichen. Fehlernachrich ten produzieren allerdings häufig mehrere Folgefehler, so dass die tatsächliche Fehlerursache oft nur schwer zu erken nen ist. Auch Folgefehler können wiederum weitere Folgefehler nach sich ziehen, so dass Lawinen von Ereignisketten entste hen. Dabei können mehrere Tera-Bytes an Datenmengen pro Tag anfallen, bei hochkomplexen Systemen auch Peta-Bytes pro Stunde .

Bei einer zentral organisierten und strukturierten Datenver arbeitungslösung muss der Datenverkehr sehr vieler Signal oder Eventdaten durch entsprechend große Übertragungskapazi täten ermöglicht werden, da sonst eine Engstelle entsteht, und zwar im allgemeinen dort, wo die Daten zusammenlaufen, nämlich bei dem Rechner, der die zentrale Event- und Sensor- daten-Verarbeitung bereitstellt .

Zudem muss bei einer zentralistischen Lösung die Datenverar beitung ausreichend Speicher- und Rechenkapazität bereitstel len, um die großen Datenmengen behandeln und verarbeiten zu können, was gleichfalls zu einer Engstelle führt, wenn die Datenmengen sehr groß werden. Auch wenn die Verarbeitung der Sensor- und Eventdaten in einer Cloud-Computing Umgebung stattfindet, so bleibt immer noch die Engstelle bei der Da- tenübertragung . Cloud-Computing (Rechnerwolke oder Datenwol ke) bezeichnet die Bereitstellung einer IT-Infrastruktur wie beispielsweise Speicherplatz, Rechenleistung oder Anwendungs software als Dienstleistung über das Internet. Damit werden IT-Infrastrukturen über ein Rechnernetz zur Verfügung ge stellt, ohne diese auf einem lokalen Rechner zu installieren. Angebot und Nutzung dieser Dienstleistungen erfolgen dabei mittels technischer Schnittstellen und Protokolle, wie bei spielsweise ein Webbrowser.

Allerdings sind die Zugänge in eine Cloud-Infrastruktur nicht für sehr hohe Übertragungsbandbreiten ausgelegt, so dass eine Vorverarbeitung der Daten in Kommunikations- und Industrie netzen sinnvoll ist.

Bisherige Lösungsansätze sind darauf ausgerichtet, das Trans portvolumen und den Verarbeitungsaufwand der Daten zu redu zieren. Eine Möglichkeit besteht in einer Dezentralisierung der Verarbeitung der Sensordaten, bei der die Rechenanforde rungen auf verschiedene Komponenten verteilt werden. Als mög liche Komponenten können Netzwerkknoten, Steuerungskomponen ten oder andere Hardwareeinheiten dienen, die mit dem Daten netz eines Systems wie einer Industrieanlage verbunden sind und über ausreichend freie Speicherkapazität und geeignete Rechnerleistungen verfügen. Jeder dieser Komponenten werden Regeln oder Algorithmen zugeordnet, die die eingehenden Date nobjekte (Statusmeldungen, Warnungen, Fehlermeldungen) verar beiten .

Eine andere Lösung ist der Publikations/Abonnement-Ansatz (Publish/Subscribe) . Hierbei handelt es sich um eine Soft warearchitektur, bei dem der Absender von Informationen, Tex ten, Nachrichten, etc., genannt Publizist (Publisher) , die Nachrichten nicht so programmiert, dass sie direkt an spezi fische Empfänger (Abonnenten) , genannt Subscriber, zu senden sind. Stattdessen werden die Nachrichten in Klassen einge teilt und die Abonnenten (Subscriber) erhalten eine Nachrich te nur dann, wenn sie ein Interesse für die jeweilige Klasse, der die Nachricht zugeordnet worden ist, zuvor geäußert ha ben. Dadurch gelingt es, nicht alle Daten über das Kommunika tionsnetz zu transportieren, sondern den Datentransport auf ein Minimum zu reduzieren im Sinne eines Multicast-Verfahrens anstelle eines Broadcast-Verfahrens . Datenobjekte, die nicht subskribiert sind, werden erst gar nicht verteilt.

Der Begriff „Multicast" bezeichnet in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe und ist daher eine Form der Mehrpunktverbindung. Der Unter schied zum Begriff „Broadcast" besteht darin, dass beim

Broadcast Inhalte verbreitet werden, die sich jeder mit ent sprechend geeigneter Empfangsausrüstung ansehen kann, wohin gegen beim Multicast zuvor eine Anmeldung beim Sender erfor derlich ist.

Eine weitere Lösung besteht in der Verteilung der Sensorda- ten-Verarbeitung auf sogenannte Event Processing Units (EPUs) im Datennetz, wodurch die zentrale Datenverarbeitung der Da tenobjekte aufgelöst wird. Die EPUs werden auf die Netzknoten und Steuerungskomponenten im Netz verteilt. Die Verteilung der Funktionen (Regeln und Algorithmen) erfolgt auf eine Art und Weise, dass der Abstand zwischen den Datenproduzenten und den Datenkonsumenten (EPUs mit Verarbeitungsregeln) minimiert wird. Dabei wird der Abstand in einer passenden Metrik gemes sen, wie beispielsweise mittels sogenannter Hop-Counts (Etap- pen-Zähler) oder der Daten-Transportgeschwindigkeit . Als Hop wird in Rechnernetzen der Weg von einem Netzknoten zum nächs ten bezeichnet. In einem Computernetz werden die binären In formationen in Datenpakete aufgeteilt, die solange von Zwi schenstation zu Zwischenstation weitergereicht werden, bis sie den Adressaten erreicht haben. Der Hop-Count ist die An zahl an Schritten, die ein Paket auf dem Weg vom Absender zum Adressaten zurücklegen muss.

Die EPUs können mittels entsprechender Regeln oder Algorith men die Datenströme filtern, beispielsweise nach Zeit, Wert oder Wertabweichung, den Mittelwert, die Standardabweichung und/oder den Median bilden oder aus unterschiedlichen Signal typen eine höherwertige, inhaltsreichere Information extra hieren, einen sogenannten Event. Jeder Netzknoten kann daher sowohl als Konsument als auch als Produzent von Events auf- treten .

Insgesamt sorgen diese Ansätze zusammen dafür, dass der Da tenverkehr so reduziert wird, dass nur die Segmente des Net zes mit einem Datenverkehr belastet werden, wo sich auch Kon sumenten mit einem Abonnement befinden und die Verarbeitung der Daten schneller erfolgen kann. Diese Ansätze werden auch im Rahmen des "Distributed Complex Event Processing" genutzt. Complex Event-Processing (CEP, deutsch: komplexe Verarbeitung von Ereignissen) ist ein Themenbereich der Informatik, der sich mit der Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Ereignisse (events) befasst. CEP ist ein Sammelbegriff für Methoden, Techniken und Werkzeuge, um Ereignisse zu verarbeiten, während sie auftreten, also konti nuierlich und zeitnah. CEP leitet aus Ereignissen ein höhe res, wertvolles Wissen in Form von sogenannten komplexen Er eignissen ab, d.h. Situationen, die sich nur als Kombination von mehreren Ereignissen erkennen lassen.

Bei CEP geht es somit insbesondere um die Behandlung von Er eignissen, die erst durch das Zusammenwirken mehrerer Ereig nisse auftreten. Um verschiedenartige Datenströme in Echtzeit zu verarbeiten und die Ereignisse zu extrahieren und zu ana lysieren, müssen von derartigen Systemen hohe Datenlasten verkraftet werden. Einsatzgebiete sind beispielsweise die Netzwerküberwachung, die öffentliche Sicherheit, der Kata strophenschutz oder das Energiemanagement.

In der US 2017/118092 Al wird ein adaptives Benachrichti- gungs- und Ticketsystem für ein Telekommunikationsnetz be schrieben. Das System umfasst ein Computergerät und mehrere Netzwerkgeräte, die dem Telekommunikationsnetzwerk zugeordnet sind. Daten werden von einer Vielzahl von vergangenen Netz werkereignissen erzeugt, die der Vielzahl von Netzwerkgeräten zugeordnet sind. Ein Modell wird aus den Daten generiert und dazu verwendet, um neue Netzwerkereignisse zu interpretieren und ein mögliches Alarmereignis anzuzeigen.

Die US 2012/124353 Al beschreibt ein Verfahren zum Verarbei ten von Ereignisströmen, wobei verschiedene Verarbeitungsein heiten Ereignisdaten, die einem Ereignisstrom zugeordnet sind, nach zuvor festgelegten Kriterien und Verfahrensschrit ten verarbeiten.

Allerdings ist die Problematik einer ursächlichen Fehlerex traktion aus einer Flut von Eventdaten wie beispielsweise Fehlerdaten, Folgefehlerdaten, Warnungen, Statusmeldungen, etc. weiterhin ungelöst. Unter einer ursächlichen Fehlerex traktion wird im Rahmen der Erfindung das Herauslösen und Identifizieren von ursächlichen und grundlegenden Fehlern aus Strömen von Fehlermeldungen und Daten, die für ein System von Relevanz sind, bezeichnet.

Die der Erfindung zu Grunde liegende Aufgabe besteht nun da rin, ein System und ein Verfahren anzugeben, das sich durch eine verbesserte Bestimmung und Analyse der ursächlichen Feh ler in einer möglichen Fehlerkette in einem Netzwerk aus Netzwerkkomponenten auszeichnet.

Diese Aufgabe wird hinsichtlich eines Systems durch die

Merkmale des Patentanspruchs 1, und hinsichtlich eines

Verfahrens durch die Merkmale des Patentanspruchs 5

erfindungsgemäß gelöst. Die weiteren Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.

Die Erfindung betrifft gemäß eines ersten Aspekts ein System zur Fehlererkennung und Fehlerursachen-Analyse in einem Netz werk bestehend aus mehreren Netzwerkkomponenten, die mit Softwaremodulen und Kommunikationsschnittstellen versehen sind, und Netzwerkknoten, die mittels Kommunikationsverbin dungen mit den Netzwerkkomponenten verbunden sind, wobei die Netzwerkkomponenten und/oder die Netzwerkknoten ausgebildet sind, Daten zu generieren, die als eine Menge historischer Daten gespeichert werden, und aus dieser Menge von histori schen Daten Eventfolgen bestehend aus einer Abfolge von

Events zu bilden. Das System ist ausgebildet, aus den Event folgen wiederum die Eventfolgen, die mit einem Alarm-Event enden, zu extrahieren, und aus diesen Eventfolgen mit einem Alarm-Event wiederum relevante Events zu extrahieren und dar aus reduzierte Eventfolgen bestehend aus relevanten Events zu konstruieren. Das System ist des Weiteren ausgebildet ist, zu jeder reduzierten Eventfolge einen Automaten zum Erkennen dieser reduzierten Eventfolge zu konstruieren, und die zu je der reduzierten Eventfolge konstruierten Automaten sukzessive zu einem gemeinsamen Automaten für alle reduzierten Eventfol gen zu vereinigen.

Hierdurch wird ein System geschaffen, das sich durch eine deutlich verbesserte Überwachung und Analyse von ursächlichen Fehlern in Ereignisketten (Eventfolgen) auszeichnet und dabei eine Reduzierung von Speicherkapazitäten im Vergleich zu her kömmlichen System ermöglicht, da ein Automat für die Erken nung von reduzierten Eventfolgen ausgebildet wird.

Gemäß einer weiteren Ausgestaltung der Erfindung ist das Sys tem ausgebildet, den gemeinsamen Automaten zu einem determi nistischen Automaten optimieren.

Vorteilhafterweise ist das System ausgebildet, eine Zustands übergangsfunktion des deterministischen Automaten zu zerlegen und in dem Netzwerk zu verteilen.

In einer weiteren Ausgestaltung der Erfindung, ist das System dazu geeignet, ein Publikations/Abonnement-Protokoll an einen oder mehrere Netzwerkknoten zu verteilen.

Gemäß eines zweiten Aspekts betrifft die Erfindung ein Ver fahren zur Fehlererkennung und Fehlerursachen-Analyse in ei nem Netzwerk bestehend aus mehreren Netzwerkkomponenten, die mit Softwaremodulen und Kommunikationsschnittstellen versehen sind, und Netzwerkknoten, die mittels Kommunikationsverbin dungen mit den Netzwerkkomponenten verbunden sind. Die Netz werkkomponenten und/oder Netzwerkknoten generieren Daten, die als eine Menge historischer Daten gespeichert werden, und bilden aus dieser Menge an historischen Daten Eventfolgen be stehend aus einer Abfolge von Events, umfassend:

- Extrahieren derjenigen Eventfolgen aus den Event folgen, die mit einem Alarm-Event enden,

- Extrahieren von relevanten Events aus den Eventfol gen mit einem Alarm-Event und Konstruieren von re duzierten Eventfolgen bestehend aus den relevanten Events, und

- Konstruieren eines Automaten zu jeder reduzierten Eventfolge zum Erkennen dieser reduzierten Event folge,

- wobei die konstruierten Automaten sukzessive zu ei nem gemeinsamen Automaten für alle reduzierten Eventfolgen vereinigt werden.

Gemäß einer weiteren Ausgestaltung des erfindungsgemäßen Ver fahrens wird der gemeinsame Automat zu einem deterministi schen Automaten optimiert wird.

Gemäß einer vorteilhaften Weiterentwicklung des erfindungsge mäßen Verfahrens wird eine Zustandsübergangsfunktion des de terministischen Automaten zerlegt und in dem Netzwerk ver teilt.

In einer weiteren Ausgestaltung des erfindungsgemäßen Verfah rens wird ein Publikations/Abonnement-Protokoll (Pub- lish/Subscribe) an einen oder mehrere Netzwerkknoten ver teilt.

Gemäß einem dritten Aspekt betrifft die Erfindung ein

Computerprogrammprodukt, das einen und/oder mehrere

ausführbare Computercodes enthält zur Ausführung des

Verfahrens nach einer Ausführungsform des Verfahrens des zweiten Aspekts der Erfindung. Gemäß einem vierten Aspekt betrifft die Erfindung ein nicht-flüchtiges computerlesbares Datenspeichermedium, welches ausführbaren Programmcode enthält, der dazu ausgelegt ist wenn er ausgeführt wird, das Verfahren gemäß einer Ausführungsform des zweiten Aspekts der Erfindung auszuführen.

Nachfolgend wird die Erfindung anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert.

Dabei zeigt:

Figur 1 eine Übersichtsdarstellung zur Erläuterung eines erfindungsgemäßen Systems;

Figur 2 ein Ablaufdiagramm zur Erläuterung eines Verfahrens gemäß der Erfindung;

Figur 3 ein Blockdiagramm zur Erläuterung eines nicht- deterministischen endlichen Automaten für eine Eventfolge gemäß eines optionalen

Ausführungsdetails des erfindungsgemäßen Verfahrens ;

Figur 4 ein Blockdiagramm zur Erläuterung eines nicht- deterministischen endlichen Automaten für zwei Eventfolgen gemäß eines optionalen

Ausführungsdetails des erfindungsgemäßen Verfahrens ;

Figur 5 ein Blockdiagramm zur Erläuterung eines

deterministischen endlichen Automaten gemäß eines optionalen Ausführungsdetails des erfindungsgemäßen Verfahrens ;

Figur 6 ein Blockdiagramm zur Erläuterung einer Anordnung einer Zustandsübergangsfunktion in einem Kommunikationsnetz gemäß eines optionalen Ausführungsdetails des erfindungsgemäßen

Verfahrens .

Zusätzliche Merkmale, Aspekte und Vorteile der Erfindung oder ihrer Ausführungsbeispiele werden durch die ausführliche Beschreibung in Verbindung mit den Ansprüchen ersichtlich.

Fig. 1 zeigt ein System 100 zur Fehlererkennung und Fehlerur- sachen-Analyse in einem Netzwerk 200 mit Netzwerkkomponenten 220, 240, 260, ..., N und Netzwerknoten 520, 540, 560 M, die hier nur beispielhaft dargestellt sind. Die Anzahl N der Netzwerkkomponenten 220, 240, 260 und die Anzahl M der Netz werkknoten 520, 540, 560 kann an die jeweilige Anwendung an gepasst werden. Die Komponenten 220, 240, 260 können Sensoren mit Softwaremodulen 300 und Kommunikationsschnittstellen 400 darstellen, oder auch Aktuatoren und Steuergeräte, die je weils Daten generieren, die beispielsweise aufgrund des Zeit verlaufs als Eventfolgen darstellbar sind. Eines oder mehrere dieser Datenpakete können das Auslösen eines Alarms bewirken oder darauf hinweisen, dass ein Alarm ausgelöst werden soll te, der beispielsweise auf das fehlerhafte Verhalten einer Netzwerkkomponente 220, 240, 260 selbst und/oder einer Anlage und/oder einer Einheit, die mit den Netzwerkkomponenten 220, 240, 260 überwacht wird, hinweist.

Eine Anlage oder eine Einheit kann auch einen Raum oder einen Gebäudekomplex oder eine Industrieanlage darstellen, die/der jeweils mit den Komponenten 220, 240 und 260 überwacht wird. So können beispielsweise einige der Netzwerkkomponenten 220, 240, 260 z.B. Temperatursensoren und Rauchmeldesensoren dar stellen, die Räume in einem Gebäude überwachen. Der Netzwerk komponenten 220, 240, 260 sind mittels Kommunikationsverbin dungen 500 mit den Netzwerkknoten 520, 540 und 560 verbunden. Bei den Netzwerkknoten 520, 540, und 560 kann es sich um Rou ter, Steuergeräte und andere Hardwaregeräte handeln, die über die erforderliche Rechnerleistung verfügen. Allerdings können auch die Netzwerkknoten 520, 540 und 560 in einer Weiterent- wicklung der Erfindung selbst Daten generieren, die sie dann an andere Netzwerkknoten 520, 540, 560 weiterleiten.

Die Netzwerkkomponenten 220, 240 und 260 generieren Daten für einen bestimmten Event. Beispielsweise ist das Messen einer Temperatur T zu einem bestimmten Zeitpunkt t _x ein Event E. Wird nun zu einem weiteren Zeitpunkt t _y ein weiterer Tempera turwert T gemessen, so ist dies ein weiterer Event. Die

Events können nun zu Eventfolgen zusammengefasst werden. Im Rahmen dieser Erfindung ist es von Interesse, die Events her auszufinden, die auf einen Fehler eines zu überwachenden Sys tems und/oder eine Anlage, etc., hinweisen.

Fig. 2 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Ver fahrens zur Fehlerursachen-Analyse (Root Cause Analyse) von ursächlichen Fehlern in einer oder mehreren Eventfolgen, wie sie in dem Netzwerk 200 auftreten.

Im Schritt S10 werden aus einer Menge historischer Daten die jenigen Eventfolgen, die mit einem Alarm-Event 'a' enden, extrahiert .

Im Schritt S20 werden aus den Eventfolgen, die mit einem Alarm-Event 'a' enden, die relevanten Events extrahiert und daraus reduzierte Eventfolgen bestehend aus relevanten Events konstruiert. Ein relevanter Event ist ein Event, dem eine Be deutung hinsichtlich eines Hinweises auf einen Fehler

und/oder einen Alarm zugeschrieben wird.

Im Schritt S30 wird zu jeder reduzierten Eventfolge ein spe zieller (oder: fundamentaler) Automat, A _± , 700, der diese re duzierte Eventfolge erkennt, konstruiert.

Im Schritt S40 werden die konstruierten (speziellen, oder fundamentalen) Automaten, Ai _, 700 sukzessive zu einem gemein samen Automaten (aus integrierten fundamentalen Automaten) , gAi, 800 für alle reduzierten Eventfolgen vereinigt. Im Schritt S50 wird dieser gemeinsame Automat, gA _2, 800 opti miert .

Im Schritt S60 wird die Zustandsübergangsfunktion d des ge meinsamen Automaten, gA _2, 800 zerlegt und in dem Netzwerk 200 verteilt .

Im Schritt S70 wird das Publikations/Abonnement-Protokoll (Publish/Subscribe) an die Netzknoten n 540, 560 verteilt.

Im Folgenden werden die Schritte S10 - S70 im Einzelnen be schrieben .

Schritt S10: Extraktion der Eventfolgen aus den histori schen Daten

Eine Eventfolge besteht aus einer Folge von Events, wo bei ein Event von den Netzwerkkomponenten 220, 240, 260 gemessen und/oder generiert wird. Aus der Menge von Eventfolgen werden diejenigen Eventfolgen extrahiert, die mit einem Alarm-Event 'a' enden. Ein Alarmevent 'a' weist auf eine kritische Situation hin, wie beispiels weise eine erhöhte Temperatur oder ein erhöhter Druck. Eine Eventfolge, die mit einem Alarmevent 'a' endet, kann wie folgt beschrieben werden:

SN (ttd =a

mit Zeitpunkten t _±-i < t _± für i = 1, ... , N .

Die repräsentative Menge an historischen Daten für die Aus wahl der Eventfolgen ist vorteilhafterweise groß genug, damit eine realistische zufällige Auswahl von Eventfolgen als Trai ningsdaten zum Beispiel für ein neuronales Netzwerk getroffen werden kann, um eine Häufung von Spezialfällen zu vermeiden. Die nicht ausgewählten repräsentativen Eventfolgen, die nicht in die Fehlerursachen-Analyse (Root Cause Analyse) einflie ßen, können jedoch als Testdaten verwendet werden. Die zufällig ausgewählten Eventfolgen können gemäß folgender, quantitativer Kriterien bestimmt werden: a) Festlegen eines relevantes Zeitfenster DT>0 zur Detekti on eines Events, wobei dieses Zeitfenster entsprechend der jeweiligen Anwendung im Sekunden- bis Stundenbereich liegt. Jeder Event in diesem Zeitfenster wird berück sichtigt :

{d (t _±) | t _{N -} DT < ti < t _N} b) Festlegen der relevanten Anzahl K < N der Events, die einem Alarm vorausgehen sollen. Dies können entsprechend der Anwendung einige wenige bis zu tausenden von Events sein. Jeder Event nach dieser vorgegebenen Anzahl wird dann berücksichtigt: {ei(ti) | N-K < i < N} c) Erste Kombination aus a) und b) : Es werden nur die

letzten Events aus einem Zeitfenster DT berücksich tigt, also höchstens K Events:

{e _±( ti) | tu-DT < ti d t _N und N-K < i < N} d) Zweite Kombination aus a) oder b) : Berücksichtigung

aller Events aus dem Zeitfenster DT, mindestens

aber die letzten K:

{ei | tu-DT < ti d t _N oder N-K < i < N}

Folgende qualitative Kriterien können neben der Zeit und der Anzahl definiert werden, die sich z.B. auf Typ, Herkunft oder Inhalt der Events beziehen, wie beispielsweise:

- Typ des Events

- Typ der Eventquelle

- Herkunft des Events, z.B. aufgeteilt nach realem oder logischem Ort:

- geometrische Daten - Netzwerksegment der Eventquelle

- Subsystem der Anlage

Inhalt des Events: ein Prädikat, das den Wert des Events liest und einen booleschen Wert generiert, wie beispielsweise: e _±( ti).value > Limit

oder

I e _{± (} t _±) . value - Limit | <

Diese Vorauswahl von Events für die Erkennung von Mustern, die zu einem Alarm 'a' führen, ist anwendungsabhängig und er fordert ein jeweiliges spezifisches Expertenwissen, da die Menge der zu betrachtenden Events einerseits nicht zu groß sein sollte, was bei Eventquellen mit einer hochfrequenten Datenerzeugung wie bei der Messung von Umdrehungen bei Turbi nen leicht der Fall sein kann, und andererseits keine Events ausgeschlossen werden sollten, die eventuell einen Hinweis auf einen Alarm geben könnten.

Im Folgenden wird ein einfaches Beispiel für die Erzeugung einer Fehlerursachen-Analyse (Root Cause Analyse) beschrie ben .

Eine Eventfolge 1 besteht aus den Events b -^ c -^ d -^ e -^· g a, und eine Eventfolge aus den Events d

g a, die jeweils zu einem Alarm 'a' führen.

Eine quantitative Analyse der Eventfolgen 1 und 2 wird durch Zählen der Häufigkeit der einzelnen Events a, b, c, d, e, f, g, e in den Eventfolgen durchgeführt. Für die erwähnten Eventfolgen ist dies in der Tabelle 1 dargestellt.

Tabelle 1

Es wird davon ausgegangen, dass eine Häufung identischer Events, z.B. aufgrund fehlender Filterung bei der Event quelle, nicht vorkommt. Falls solche Filter nicht einge setzt werden, könnte eine beispielhafte Eventfolge "d c -^ c -^ c -^ f - g -^ a" durch Zusammenziehen von identi schen Events entsprechend zu "d c ^ f ^ g ^ a" verkürzt werden. Dasselbe gilt, wenn wechselseitiges Wiederholen von identischen Events vorkommt, beispielsweise in der Event folge d ^ c ^ d ^ d ^ c ^ c ^ d ^- a.

Schritt S2 : Extraktion relevanter Events und Konstruktion re duzierter Eventfolgen

Es wird ein Schwellenwert zwischen der minimalen und maxima len Anzahl des Auftretens eines bestimmten Events festgelegt, in diesem Beispiel im Bereich [1, 2] . In diesem Bereich wer den nur diejenigen Events betrachtet, die häufiger als der festgelegte Schwellenwert, z.B. 1,5, _V orkommen. Bei der obi gen Tabelle 1 sind das die Events c, d und g, die jeweils zweimal im betrachteten Bereich auftreten. Die Events b, e und f werden für die Root Cause Analyse nicht weiter berück sichtigt, da sie jeweils nur einmal in den beiden Event folgen auftreten, wie dies in Tabelle 2 dargestellt ist.

Tabelle 2 Der Schwellenwert sollte so definiert sein, dass keine für den Alarm relevante Events ausgeschlossen werden, anderer seits aber eine zu große Anzahl an irrelevanten Events be rücksichtigt werden muss, d.h. der Schwellenwert ist weder zu hoch noch zu niedrig einzustellen.

Die aufgetretenen Eventfolgen werden reduziert, indem die als irrelevant eingestuften Events entfernt werden. Bei der Eventfolge 1 sind dies die Events b und e, und bei der Eventfolge 2 der Event f:

Die Eventfolge 1 wird von b ^ c ^ d ^ e ^ g ^ a reduziert zu c ^ d ^ g ^ a.

Die Eventfolge 2 wird von d c ^ f ^ g ^ a reduziert zu d c ^ g ^ a.

Schritt S30: Konstruktion eines nicht-deterministischen end lichen Automaten, A _± , 700

Zu jeder der reduzierten Eventfolgen wird ein nicht

deterministischer endlicher Automat, A _± , 700, der diese redu zierten Eventfolgen erkennt, konstruiert. Dabei bleiben die irrelevanten Events (hier: b, e, f) unberücksichtigt. In der Figur 3 ist der Automat, A _± , 700 zu der Folge 1 graphisch dargestellt .

Für diesen Schritt S30 wird ein nicht-deterministischer end licher Automat, A _± , 700 gewählt. Der Nicht-Determinismus des Automaten, A _± , 700 ergibt sich durch den Zustand So, da bei diesem Zustand So der Event 'c' sowohl in den Zustand 'so', als auch in den Zustand 'si' übergehen kann. Damit kann eine Folge von Events solange im Zustand So verharren, bis bei ei nem Event 'c' richtigerweise ein zufälliger Übergang in den Zustand 'si' erfolgt. Tritt nun ein Event 'd' ein, so erfolgt ein Übergang in den Zustand 's ₂ ', und bei einem Event 'g' tritt nun der Zustand 'S3' ein, der einen Alarm 'a' auslöst, der bei der richtigen Sequenz c -> d g -> a auftritt. Bei den Zuständen sind nur die definierten Übergänge darge stellt. Die Zustandsübergangsfunktion d für den in Fig. 3 dargestellten Automaten A _± , 700 ist in der folgenden Tabelle 3 dargestellt. Gemäß der Zustandsübergangsfunktion d werden die einzelnen Zustände beim Eintreffen eines neuen Events in einen Folgezustand überführt, wobei gemäß dem vorgesehenen Nicht-Determinismus des Automaten, A _± , 700 dies ein Folgezu stand von mehreren möglichen Folgezuständen ist. Gegebenen falls gibt es keinen Folgezustand, dargestellt durch das Sym bol 0 für die leere Menge.

Tabelle 3

Formal erfolgt die Definition des Automaten, A _± , 700 zu einer reduzierten Eventfolge in folgender Weise: Seien (vi) , i = 1, ... , N die reduzierten Eventfolgen mit (v) = v _{0 ->} vi - ... - v _N _i - v _N = a, und sei V die Menge aller Events, die in den ursprünglichen Eventfolgen Vorkommen, so wird der endliche Automat, A _± , 700 definiert mittels der Zustandsmenge S, der Eingabemenge X, der Zustandsmenge F, des Startzustands So und der Zustandsübergangsfunktion d, die im Folgenden näher er läutert wird. Der Automat, A _± , 700 ist somit bestimmt durch Ai = (S, X, F, s ₀ , d) .

Die Zustandsmenge S:= {E _a }U {s± I i = 0, ... , N} ist die Menge aller Zustände s, d.h. zu jedem in den reduzierten Eventfol- gen auftretenden Event v _± gibt es einen Zustand s _± des Auto maten 700. Dabei wird ein mehrfaches Auftreten von Events in nerhalb der Eventfolgen berücksichtigt, wobei v _± das i-te Auftreten irgendeines Events v darin bezeichnet. Insbesondere bezeichnet s _± denjenigen Zustand, mit dem der Event v _± in den Zustand Si _+i übergeht. Analog bezeichnet s _N denjenigen Zu stand, mit dem Event v _N = a in den Endzustand E _a übergeht.

Die Eingabemenge X := {alUivilvi £ (vi) , i = 0, ..., N - 1} stellt die Menge der Eingabe der relevanten Events v der Eventfolge, unabhängig von dem Kontext, in dem sie auftreten, sowie den Alarm 'a' dar. Der Kontext wird dann durch die Zu standsübergänge dargestellt.

Die Endzustandsmenge F := { E _{a }} stellt die Menge der Endzu stände dar, wenn der Alarm 'a' nach der vorgegebenen Event folge auftritt.

Der Startzustand s ₀ ^: = s ₀ ist der Anfangszustand.

Die Zustandsübergangsfunktion d : S ^c X - 2^ überführt ei nen einzelnen Zustand beim Eintreffen eines neuen Events in einen (oder keinen) von mehreren möglichen Folgezustände, wo- ber 2 dre Potenzmenge der Zustandsmenge S bezerchnet. Ist die leere Menge 0 angegeben, gibt es auch keinen Zustands übergang. Die Zustandsübergangsfunktion d für beliebige Auto maten Ai, 700, kann in einer Tabelle 4 dargestellt werden, die wie folgt aufgebaut ist:

Tabelle 4

Wie aus der Tabelle 4 ersichtlich, wird ein Zustand s± beim Eintreffen von einem Event v± in den Folgezustand ' Sm ' über führt. Eine Ausnahme ist der Zustand 'so', der alle übrigen Events auf sich selbst abbildet.

Bei dem in der Figur 3 dargestellten Automaten, A±, 700 führt der Alarm-Event 'a' in den Endzustand E _a . Allerdings kann dies bei der praktischen Anwendung anders definiert werden, da es häufig wichtig ist, dass vor Erreichen eines kritischen Zustands, also dem Eintreten eines Alarm-Events, eine ent sprechende Warnung erfolgt und damit bereits der Endzustand eingetreten ist, um geeignete Gegenmaßnahmen zu ergreifen.

Insofern kann bei der Verarbeitung der Eventfolge in der Pra xis (Feldeinsatz) der Root Cause Analyse spätestens bei dem Event v _N _i (in Figur 3 der Event 'g') eine Meldung über den möglicherweise direkt bevorstehenden Alarm-Fall generiert werden, und diese kann vorteilhaft mit einer Aktion verbunden werden, die eine Gegenmaßnahme einleitet.

Schritt S40: Integration der nicht-deterministischen endli chen Automaten, A±, 700

Da es eine Menge von Eventfolgen von relevanten Events gibt, wird auch eine entsprechende Menge von Automaten, An, An, ..., An,, 700 entwickelt. Daher wird aus diesen Automaten An,

An,..., A , 700 sukzessive ein gemeinsamer Automat, gAi, 800 zur Erkennung aller Eventfolgen konstruiert. Dazu werden die Startzustände in einem gemeinsamen Startzustand zusammenge fasst, der sich in die verschiedenen Äste 820, 840 der ver schiedenen Eventfolgen nicht-deterministisch verzweigt. Seien also Ai = (Xi, Si, Fi, s _0j _, di) , i £ {1,2} zwei AiS, dann ist der gemeinsame gAi = (X, S, F, s ₀ , d) wie folgt defi niert :

Die Eingabemenge X: = Xi U X2 ist die einfache Vereinigung der relevanten Events.

Die Zustandsmenge S := {s ₀ HJ(Si \ {s _0] _})U(S2 \ {s ₀ 2 } ist die disjunkte Vereinigung der Zustandsmengen ohne die einzelnen Startzustände, aber dafür mit einem neuen gemeinsamen Start zustand SQ.

Die Endzustandsmenge F := F _! UF ₂ ist die disjunkte Vereini gung der Endzustandsmengen, also F := {E _a] _, E _a 2 }

So· ^— S ₀

Dre Zustandsübergangsfunkt on d : S ^c X - 2 rmplementrert die folgenden Zustandsübergänge: i) d ( s ₀ , x) := { s _{0 }} U (di (s _ol , x) \ { s _0i } ) U (5 ₂ (S _C2 , X) \

{s _o2}) , Vx £ X;

Für jeden Event wird der Startzustand auf sich selbst und auf die Folgezustände abgebildet. ii) 5(s,x) := di (s,x) wenn s e Si \ {s _0] _}

5(s,x) := 62 (s,x) wenn s e S2 \ {S ₀ 2}

Die Figur 4 zeigt das Ergebnis dieser Konstruktion eines ge meinsamen Automaten gA _± , 800 für die beiden Eventfolgen c d g ^ a aus dem im Obigen dargestell ten Beispiel.

Schritt S50: Optimierung des gemeinsamen Automaten, gA _± , 800 durch Konstruktion eines minimalen deterministischen endli- chen Automaten, dAi, 900

Es wird zum obigen Automaten, gAi, 800 ein äquivalenter de terministischer minimaler endlicher Automat, dA ₄ = (S, X, F, So, d) , 900 konstruiert. Die im Automaten, gAi, 900 auftre tende Nicht-Determinismen können konstruktiv mit Standardme thoden, z.B. der Potenzmengenkonstruktion, entfernt werden. Die folgende Tabelle 5 zeigt die Zustandsübergangsfunktion d für den integrierten minimalen deterministischen Automaten, dAi, 900 für die beiden Beispielfolgen:

Tabelle 5

Der Zustand 'f' steht für die leere Menge im nicht

deterministischen Fall. Er wird dann erreicht, wenn der Alarm 'a' erkannt wird, ohne dass zuvor eine der vorgegebenen

Eventfolgen durchlaufen wurde, 'f' ist somit ein Indikator dafür, dass die Auswahl der Eventfolgen nicht optimal war bzw. dass es eine andere Eventfolge gibt, die mit einem Alarm endet. Für die beiden Zustände 'f' und 'E _a ' kann 'f' als Fol gezustand definiert werden, da es sich um End- bzw. Fehlerzu stände handelt. In Figur 5 ist ein deterministischer Automat, dAi, 900 dargestellt, der sich durch eine höhere Komplexität gegenüber der nicht-deterministischen Variante auszeichnet. Schritt S60: Zerlegung und Verteilung der Zustandsübergangs funktion des minimalen deterministischen endlichen Automaten, dA±, 900

Die Funktion des Automaten, dAi, 900 ist im Wesentlichen durch die Zustandsübergangsfunktion d: S ^c X - S beschrieben. Die Zustandsübergangsfunktion implementiert die Ursachenana lyse (Root Cause Analyse) , indem alle Events entsprechend der Zustandsübergansfunktion d in Folgezustände übergehen und beim Auftreten von 'E _a ' oder 'f' eine Meldung abgeben.

Bei einem zentralistischen Datenverarbeitungssystem wird die Zustandsübergangsfunktion d in einem Netzwerkknoten 520 im Netzwerk 200 abgelegt und alle Events werden zu diesem Knoten 520 geroutet. Die Zustände nehmen dann gemäß der Zustands übergangsfunktion d ihren jeweiligen Zustand an bis der End oder der Fehlerzustand erreicht ist.

Im Netzwerk 200 werden die Netzwerkknoten 520, 540, 560 iden tifiziert, die am dichtesten bei einer Eventquelle wie einer Netzwerkkomponente 220 liegen. Sei also n _x der Netzwerkknoten 520, in dem der Event x generiert wird bzw. der den kürzesten Weg zu einer Net zwerkkomponenten-Datenquelle (Sensordaten quelle) 220 von x hat.

Sei zudem d: S ^c X - S die Zustandsübergangsfunktion des Au tomaten dAi, dann wird d nach X zerlegt, so dass eine neue Funktion entsteht: d ^G : X - [S - S], d.h. es wird jedem Event xeX eine Zustandsübergangsfunktion d ^G _c ö ^r (x) : S - S, Vx E X mit d' (x) (s) = d (s, x) zugeordnet.

Gemäß dem im Obigen dargestellten Beispiel hat die Funktion ö' _c das folgende in Tabelle 6 dargestellte Aussehen:

Tabelle 6

Dann werden die Funktionen d' _c dem jeweiligen Netzwerkknoten, n _x , 520 zugeordnet. Die Figur 6 zeigt die Zuordnung für ein beispielhaftes Netzwerk 200, das die auftretenden Zustandsän derungen unter den relevanten Netzwerkknoten 520, 540, 560 mittels Multicast-Nachrichten verteilt.

Die Platzierung der d ' _x -Funktonen im Netzwerk 200 kann manu ell erfolgen, wenn das Netz 200 eine gewisse Stabilität auf weist, so dass die Events x stets aus derselben Sensordaten quelle 220 kommen.

Prinzipiell, nicht nur im Fall von Instabilitäten im Netzwerk 200, kann jedoch eine automatische Zuordnung der d' _c - Funktionen vorgenommen werden, die über das Pub- lish/Subscribe-Protokoll erfolgen kann.

Ein Beispiel dafür ist das PADRES Publish/Subscribe System, das beispielsweise beschrieben ist in:

https : //www . researchgate . net/publication/220956222_The_PADRES _Distributed_Publish Subscribe System.

Schritt S70: Funktionen der Netzwerkknoten 520 Die Grundidee besteht darin, dass die Zustände ebenfalls als spezielle Events definiert und mittels des Publikati

ons/Abonnement-Protokolls (Publish-Subscribe) per Multicast an die Abonnenten (Subscriber) verteilt werden. Die Funktio nen d _c , xeX bei den Knoten, n _x , 520, 540, 560 umfassen eine Startsequenz zur Initialisierung der Knoten, n _x , 520, 540,

560 und des in einer Event-Schleife (Loop) gestalteten Proto kolls, das sowohl das Eintreffen von Zustands-Events als auch von Netzwerk-Events verarbeitet.

Das Publish-Subscribe-Protokoll umfasst die folgenden drei Nachrichten : a) Bekanntmachen (advertise) (s,n) : Der Netzwerkknoten, n,

520 macht den Zustand s in einer Broadcast-Nachricht al len anderen Netzwerknoten, n, 540, 560 bekannt. Diese Be kanntmachungs-Nachricht ist die einzige Broadcast- Nachricht in diesem Protokoll. b) Abonnieren (subscribe) (n,s,m): Der Netzwerkknoten, n, 540, 560, wobei n e N, informiert den Knoten, m, 520, dass er den Zustand s von ihm abonniert. Dem sollte eine Bekanntmachungs-Nachricht (n,s) vorausgegangen sein. Die Abonnement-Nachricht ist eine Punkt-zu-Punkt-Nachricht (Point-to-Point) von einem Netzwerkknoten n zu einem an deren Netzwerkknoten m. c) Publizieren (publish) (s,N) : Alle Knoten, n e N, 520. 540, 560 werden mittels einer Multicast-Nachricht über den neuen Zustand s informiert. Die Knoten, n e N, 540, 560 sollten zuvor den Zustand s abonniert haben. Vor dem Sen den einer Publikations-Nachricht sollte lokal ein Zu standsübergang stattgefunden haben.

Das Startverfahren des Knotens, n, 520 kann die folgenden Schritte umfassen: Schritt 1 : Zunächst ist die Menge der Abonnenten einer Zu standsänderung des Knotens n _x die leere Menge: Abos : = 0

Schritt 2 : Für alle s e d _{c (} S ) wird die Broadcast- Nachricht „Bekanntmachung von (s,n _x) " gesendet.

Die Zustandsänderungs funktion d _{c (} S ) ist die Menge der lokal durch d _c produzierten Folgezustände, also die Bild menge von d _c . Diese Zustände werden allen anderen Knoten, n, 540, 560 bekanntgemacht.

Schritt 3 : Für alle eingehenden Nachrichten von Netzwerkkno ten n beim Netzwerkknoten n _x , 520 "Abonniere (n,s,n _x) ": wenn seö _x( S ) verändert sich die Menge der Abonnenten z:

Abos : = Abos U { n }

Der Netzwerkknoten n _x , 520, speichert die Knoten, n, 540, 560, die die vom Netzwerkknoten n _x bekanntgemachten Zu stände abonnieren.

Schritt 4 : Von den Netzwerkknoten n, 540, 560, bei denen die Nachricht "Bekanntmachen (s,n)" eingeht, wird die Nach richt "Abonniere (n _x ,s,n)" an den Netzwerkknoten n _x gesen det. Damit abonnieren diese Netzwerkknoten n den angebote nen Zustands-Event s.

Schritt 5 : Die lokale Zustandsvariable z der Netzwerkkno ten n nimmt den bekanntgemachten Startzustand So ein.

Die einzelne Nachrichteneingänge oder -ausgänge werden gege benenfalls mehrfach ausgeführt, in Abhängigkeit von der zeit lichen Abfolge, in welcher die Netzwerkknoten n, 520, 540,

560 das Startverfahren durchlaufen.

Eine Event-Schleife (Loop) des Knotens, n _x , 520 sieht wie folgt aus: Schritt 1: Wenn eine Nachricht "Publiziere (s,n _x) " bei dem Netzwerkknoten n _x eingeht, dann wird die lokale Zustandsva riable z des Netzwerkknotens n _x auf s gesetzt: z:= s

Schritt 2 : Wenn ein Event x bei dem Netzwerkknoten, n _x,

520 eingeht und z + d _c ( z ) , dann initiiert der Event x einen neuen Zustand: z := d _c ( z );

Der neuen Zustand z wird lokal bei dem Netzwerkknoten, n _x , 520 gespeichert. Dann wird von dem Netzwerkknoten, n _x , 520 eine Multicast-Nachricht an alle Abonnenten gesendet:

"Publiziere (z, Abos)". Damit wird der neue Zustand z an alle Abonnenten (Abos) weitergegeben.

Die Schleife (loop) kann somit wie folgt beschreiben werden: loop

Wenn Nachricht "publish( s, n _x )" eingeht: z := s;

Wenn Event x eingeht und z + d _c ( z ) : sende Multicast- Nachricht "publish( z, Abos )"; end loop

In der Schleife werden eingehende Publikations-Nachrichten mit einem neuen Zustand verarbeitet, indem der publizierte Zustand in die lokale Zustandsvariable z übernommen wird. An sonsten kann eine Zustandsänderung stattfinden, wenn ein Event gelesen wird. Der neue Zustand z wird an die anderen Netzwerkknoten n 540, 560, die die Zustandsänderungen abon niert haben, mittels einer Multicastnachricht weitergegeben. Falls der Event keine Zustandsänderungen zur Folge hat, fin det auch keine Multicastnachricht statt.

Durch die vorliegende Erfindung kann somit eine Fehlerursa- chen-Analyse (Root Cause Analyse) von möglichen ursächlichen Fehlern in Ereignisketten (Eventfolgen) für ein Netzwerk 200 bestehend aus Netzwerkkomponenten 220, 240, 260 und Netzwerk- knoten 520, 540, 560 durchgeführt werden. Aus reduzierten Eventfolgen wird ein deterministischer Automat, dA _± , 900 kon struiert und eine Zustandsübergangsfunktion d des Automaten, dAi, 900 im Netzwerk 200 verteilt. Im Betrieb des Automaten, dAi 900 werden Zustände und Events gleichermaßen als Nach richten definiert und mittels des Publikations/Abonnement- Protokolls (Publish/Subscribe) im Netzwerk 200 verteilt. Da mit können gezielt Nachrichten über Fehlermeldungen in dem Netzwerk 200 weitergeben werden und eine Überlastung des Netzwerks 200 mit einer Datenflut, die keine Relevanz dar stellt, kann vermieden werden.