Bachelorarbeit. im Studiengang Angewandte Informatik. an der Fakultät IV. der Hochschule Hannover. vorgelegt von. David Liebetruth. Matr. Nr.

Transkript

1 Eignung der Complex Event Processing Engine Oracle CEP zur Überwachung von Photovoltaikanlagen Bachelorarbeit im Studiengang Angewandte Informatik an der Fakultät IV der Hochschule Hannover vorgelegt von David Liebetruth Matr. Nr.: Erstprüfer: Zweitprüfer: Prof. Dr. Ralf Bruns Prof. Dr. rer. nat. Jürgen Dunkel Eingereicht am: I

2 EIDESSTATTLICHE ERKLÄRUNG Hiermit erkläre ich an Eides statt, dass ich die eingereichte Bachelorarbeit selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Datum: Unterschrift David Liebetruth II

3 INHALTSVERZEICHNIS ABBILDUNGSVERZEICHNIS...V DANKSAGUNG...VI 1 EINLEITUNG Motivation Ziel der Arbeit Aufbau der Arbeit MACHINE-TO-MACHINE KOMMUNIKATION Grundlagen Anwendungsgebiete COMPLEX EVENT PROCESSING Einführendes Beispiel Grundlegende Begriffe Ereignis Ereignismodell Ereignisregeln Event Processing Agent Event Processing Network STAND DER TECHNIK Complex Event Processing bei M2M Überwachung von Photovoltaikanlagen ORACLE CEP Oracle CEP Architecture Einführung der Oracle CEP Komponenten Event Erstellung und Registrierung Adapter Processor Channel Event Bean Development Environment für Eclipse Oracle Continuous Query Language Hello World Beispiel EREIGNISSE EINER PHOTOVOLTAIKANLAGE Aufbau einer Photovoltaikanlage Maschinenereignisse Ereignismodell Ereignisregeln Kommunikationsereignisse Ereignismodell Ereignisregeln TECHNISCHE UMSETZUNG Event Processing Network für Photovoltaikanlagen Implementierung Implementierung der Oracle CEP Komponenten III

4 7.2.2 Implementierung der Processoren (CQL-Regeln) VERGLEICH VON ORACLE CEP MIT ESPER Grundsätzliches Offenes Problem Regelvergleich SCHLUSSBETRACHTUNG Evaluierung von Oracle CEP Zukunftsaussichten LITERATURVERZEICHNIS ANHANG IV

5 ABBILDUNGSVERZEICHNIS Abbildung 2.1: Grundkonzept einer M2M-Anwendung (angelehnt an [4]) Abbildung 3.1: Abstraktion von Ereignissen über mehrere Ebenen (angelehnt an [11] S. 86) Abbildung 3.2: Aufbau eines Event Processing Agents (angelehnt an [11]) Abbildung 4.1: Schematische Darstellung der Weiterleitung von Betriebsdaten einer Photovoltaikanlage Abbildung 5.1: Softwarestack von Oracle CEP Abbildung 5.2: Creation Wizard Abbildung 5.3: Creation Wizard Abbildung 5.4: Event Type Definition Editor Abbildung 5.5: Assembly File Editor Abbildung 5.6: Configuration File Editor Abbildung 5.7: Manifest Datei Editor Abbildung 5.8: EPN-Editor Abbildung 5.9: EPN HelloWorld-Beispiel Abbildung 5.10: Eclipse-View Server Abbildung 6.1: schematischer Aufbau einer Photovoltaikanlage Abbildung 6.2: Ereignismodell der Maschinenereignisse Abbildung 6.3: IP-basierte Datenkommunikation mittels GPRS [3] Abbildung 6.4: Kommunikationsereignisse bei Verwendung von GSM/GPRS-Netzen Abbildung 7.1: Event Processing Network für Photovoltaikanlagen Abbildung 7.2: Übersicht das EPN zur Photovoltaikanlagenüberwachung im EPN-Editor Abbildung 0.1: Übersicht über den Complex Event Processing Markt in 2011 [2] V

6 DANKSAGUNG Danken möchte ich meiner Freundin Cindy, die mir immer eine große Unterstützung war! VI

7 1 EINLEITUNG 1.1 MOTIVATION Das Auffinden von wichtigen Informationen aus großen Mengen an Daten gewinnt in Zeiten der digitalen Datenerfassung immer mehr an Bedeutung. In sämtlichen Bereichen der Industrie und Technik steigt die Anzahl der digital erfassten Daten (zum Beispiel Sensordaten oder Standortkoordinaten), die ausgewertet bzw. überwacht werden müssen, stetig an. [1] Zusätzlich sind die Anforderungen an die Auswertung von Daten vielfältiger geworden. Oft ist eine sehr schnelle Reaktionsfähigkeit auf bestimmte Situationen seitens der Unternehmen von Nöten, das bedeutet die vorliegenden Informationen müssen kontinuierlich und möglichst direkt zum Zeitpunkt des Auftretens verarbeitet werden. Dabei reicht es meistens jedoch nicht aus, dass bestimmte Daten beispielsweise einfach auf Schwellenwerte überprüft werden, oftmals liegen die Anforderungen auch darin, die Daten miteinander zu vergleichen oder miteinander zu verknüpfen, um einen größeren Informationsgehalt zu erhalten. Anwendungen, die Complex Event Processing einsetzen, sind in der Lage, diese Anforderungen optimal zu erfüllen, indem die Daten in einem kontinuierlichen Strom innerhalb kürzester Zeit (im Bereich von Millisekunden) hinsichtlich der gewünschten Kriterien verarbeitet werden können. Diese besonderen Eigenschaften, die die Complex Event Processing Technologie bietet, in Verbindung mit Machine-to-Machine Kommunikation (Definition siehe Kapitel 0), können eine ideale Ergänzung aus Datenbeschaffung und Datenauswertung ergeben. Das führt zu selbstständig kommunizierenden Maschinen, die in der Lage sind, auftretende Informationen direkt zur Stelle der Auswertung zu senden, welche schnellstmöglich individuell verarbeitet werden können. Eine solche effiziente Datenverarbeitung könnte für die verschiedensten Anwendungsgebiete sinnvoll eingesetzt werden. Dabei gilt es, für die verschiedenen Anforderungen der unterschiedlichen Anwendungsgebiete den jeweils optimalen Weg der Datenverarbeitung zu finden. 7

8 Einleitung 1.2 ZIEL DER ARBEIT Es existieren bereits mehrere Complex Event Processing Engines von verschiedenen Anbietern auf dem Markt 1, die sich möglicherweise in ihren Kozepten und Arbeitsweisen unterscheiden und somit sind manche Engines daher eventuell besser für bestimmten Anwendungen geeignet als andere. [2] In dieser Bachelorarbeit soll die von Oracle Corporation entwickelte Complex Event Processing Engine Oracle CEP vorgestellt und evaluiert werden. Die Darstellung der Funktionsweise und die Bewertung der Engine Oracle CEP wird anhand des Beispiels der Überwachung von Photovoltaikanlagen realisiert. Die Bewertung soll sich einerseits auf die Eignung von Oracle CEP zur Überwachung von Photovoltaikanlagen beziehen, andererseits auf die Eigenschaften und die Funktionsweise der Engine. Da Machine-to-Machine Kommunikation in dem Szenario der Anlagenüberwachung ebenfalls eine wichtige Rolle spielt, wird auch diese Technolgie kurz vorgestellt. Die Überwachung von Photovoltaikanlagen wurde bereits in einer Masterarbeit aus dem Jahr 2011 von Ilja Hellwig (siehe [3]) mit der Complex Event Processing Engine Esper realisiert, sodass ein Vergleich zwischen Esper und Oracle CEP möglich ist, wobei der Fokus besonders auf den Vergleich der implementierten Regeln gelegt werden soll. Das Grundkonzept für die Realisierung der Überwachung von Photovoltaikanlagen wird angelehnt an die genannte Masterarbeit, sowie an die Ergebnisse der Software Architecture Researche Group AUFBAU DER ARBEIT Der erste Abschnitt dieser Arbeit soll dem Leser eine anschauliche Einleitung mit den nötigen Informationen zum Verständnis der verschiedenen Themenbereiche verschaffen. So beschäftigt sich Kapitel 0 mit den Grundlagen der Machine-to-Machine Kommunikation und stellt verschiedene Anwendungsgebiete dieser Technologie vor, während Kapitel 0 das Thema Complex Event Processing einführt. Beide Themenbereiche werden anschließend unter dem Punkt Stand der Technik in Kapitel 4 wieder aufgegriffen. Im Anschluss wird in Kapitel 5 vorgestellt, wobei unter anderem die Realisierung der zuvor eingeführten Begrifflichkeiten von Complex Event Processing aus Kapitel 0 gezeigt wird. 1 Abbildung mit Übersicht über den Complex Event Processing Markt befindet sich im Anhang 2 Informationen zur Software Architecture Researche Group: 8

9 Einleitung Die Umsetzung einer Überwachungssoftware für Photovoltaikanlagen beginnt mit der Ausarbeitung der theoretischen Grundlagen in Kapitel 6, die für die konkrete technische Umsetzung in Kapitel 7 notwendig sind. Zuletzt beschäftigt sich Kapitel 8 mit dem Vergleich der Engines Oracle CEP und Esper, während die Schlussbetrachtung in Kapitel 9 die Evaluierung von Oracle CEP beinhaltet und die möglichen Zukunftsaussichten von Complex Event Processing im Machine-to-Machine- Sektor vorstellt. 9

10 Machine-to-Machine Kommunikation 2 MACHINE-TO-MACHINE KOMMUNIKATION 2.1 GRUNDLAGEN Machine-to-Machine, kurz M2M, steht für einen automatisierten Informationsaustausch zwischen Maschinen. Dabei kommunizieren Maschinen wie zum Beispiel Fahrzeuge, Automaten oder Überwachungssysteme vollkommen selbstständig miteinander und können somit viele Arbeitsabläufe erheblich verbessern und erleichtern. Mögliche Anwendungsgebiete der Technologie werden in Kapitel 2.2 vorgestellt. GRUNDKONZEPT EINER M2M-ANWENDUNG Ein Machine-to-Machine-System besteht grundsätzlich aus folgenden Komponenten: 1. Datenendpunkt (Data End Point = DEP) 2. Kommunikationsnetzwerk (LAN, WLAN, GSM-Mobilfunknetz, RFID und andere) 3. Datenintegrationspunkt (Data Integration Point = DIP) Abbildung 2.1: Grundkonzept einer M2M-Anwendung (angelehnt an [4]) Abbildung 2.1 verdeutlicht das Konzept einer M2M-Anwendung, wobei die Funktions- Endpunkte allgemein für einen Prozess (X) bzw. eine Anwendung (Y) stehen. Unter einem Datenendpunkt (DEP) ist ein Sender, der mit einem Endgerät verbunden ist, zu verstehen. In einem M2M-System kann es eine Vielzahl an DEPs mit deren dazugehörigen Endgeräten geben. Diese senden über ein beliebiges Kommunikationsnetzwerk Informationen an einen Datenintegrationspunkt (DIP), welcher die Informationen bzw. Daten sammelt und für die Auswertung zur Verfügung stellt. Ein DIP kann auf verschiedenste Weisen realisiert werden und kommt in einem typischen M2M-System nur einmal vor. [4] Auf diese Weise vollkommen selbstständig kommunizierende Maschinen bringen zahlreiche neue Möglichkeiten für die verschiedensten Industriezweige mit sich. Durch vermehrte 10

11 Machine-to-Machine Kommunikation Automatisierung können Arbeitsabläufe und Prozesse optimiert und viel schneller erledigt werden oder sogar vollständig automatisiert passieren, womit menschliche Unzulänglichkeiten keine Rolle mehr spielen. Die Übermittlung von Informationen passiert zudem mit einer hohen Geschwindigkeit und steht praktisch an jedem Ort zur Verfügung 3. [5] Damit ist zum Beispiel eine Fernüberwachung und Fernsteuerung von Anlagen über eine zentrale Stelle möglich und Maschinen können in der Lage sein, ihren Wartungsbedarf selbstständig mitzuteilen. Letztendlich kann die M2M-Kommunikation durch effizientere Prozesse sowie schnelle Reaktionsfähigkeiten für verbesserte Qualität bei gleichzeitiger Kostenersparnis sorgen. [6] Offene Fragen gibt es allerdings zurzeit noch bei der Datensicherheit von M2M- Anwendungen. Da unzählige personen- und unternehmensbezogene Informationen übermittelt werden, muss an dieser Stelle ein zuverlässiges Sicherheitssystem für den entsprechenden Datenschutz sorgen. [7] 2.2 ANWENDUNGSGEBIETE Derzeit gibt es bereits zahlreiche Anwendungsgebiete für den M2M-Sektor. Bei einigen Anwendungen ist der Einsatz von M2M offensichtlich, die meisten M2M-Anwendungen agieren jedoch für Außenstehende unauffällig im Hintergrund. [8] Wichtige Anwendungsgebiete sind zum Beispiel die Fernüberwachung, Fernsteuerung und Fernwartung von Maschinen und Anlagen. Es gibt aber auch viele weitere Anwendungsgebiete und Branchen, in denen die M2M-Technologie sinnvoll eingesetzt wird, wie zum Beispiel im Transportwesen, der Sicherheitstechnik, dem Gesundheitswesen oder der Gebäudetechnik. Großes Interesse findet M2M-Kommunikation außerdem beim Einsatz für Versorgungsunternehmen und Verkaufsautomaten, da Warenbestände und Lieferbedarf automatisch geregelt werden können. Im Folgenden werden einige Anwendungsmöglichkeiten näher gezeigt. [6] 3 Bezogen auf das GSM-Mobilfunknetz 11

12 Machine-to-Machine Kommunikation SICHERE AUFZUGSÜBERWACHUNG Im Bereich Gebäude-Management spielt M2M bei Aufzügen und deren Überwachung mittlerweile eine wichtige Rolle. So stellt zum Beispiel die für Telefon- und Gegensprechanlagen bekannte Firma Telegärtner GSM-Module her, mit denen die Belastung eines einzelnen Aufzugs, sowie eventuelle Störungen, individuell dokumentiert werden können. Diese Informationen werden direkt an den beauftragten Wartungsservice übermittelt, der daraufhin Störungen zeitnah beheben und Wartungen optimal planen kann. Zum Beispiel sollte eine Anlage, die häufig mit Höchstbelastung betrieben wird, früher kontrolliert werden als eine, die selten genutzt wird. Dank der Erfassung und Übermittlung solcher Daten ist die Sicherheit von Aufzugsanlagen im Vergleich zu früher deutlich gestiegen und zeigt somit einen positiven Fortschritt, der durch M2M ermöglicht wurde. [8] INTELLIGENTE KAFFEEVOLLAUTOMATEN In der Gastronomie eingesetzte Kaffeevollautomaten stellen ebenfalls ein Anwendungsgebiet von M2M-Kommunikation dar. Es können zum Beispiel Reparaturen, durch automatische Informationsübermittlung von auftretenden Störungen an den Servicetechniker, sofort behoben werden, noch bevor ernsthafter Schaden entstehen kann. Auch die Wartung und Instandhaltung kann auf diese Weise optimiert werden, wobei ein Zähler zusätzlich Informationen über die Anzahl der zubereiteten Getränke bereitstellt. Ein solcher Automat sorgt auch für einen ausreichenden Vorrat an Kaffebohnen, indem er sich nach dem Verbrauch einer bestimmten Menge Kaffeebohnen, automatisch mit dem Lieferanten in Verbindung setzt und eine Bestellung aufgibt. Ebenfalls denkbar wäre zum Beispiel bei einem Gerät mit Touchscreen, eine zentrale Steuerung der Displayinhalte per Mobilfunk, damit jederzeit aktuelle Werbeinformationen und Sonderanbote für den Kunden bereitgestellt werden können. [8] FERNÜBERWACHTE PHOTOVOLTAIKANLAGEN Photovoltaikanlagen, egal ob auf dem Dach oder in einem groß angelegtem Solarpark, benötigen eine kontinuierlich Überwachung, um ständig die maximale Leistungsfähigkeit der Anlage gewährleisten zu können. Dies ist besonders wichtig, damit eine solche Anlage auch rentabel ist und den erwünschten Gewinn erzielen kann. Eine Störung oder gar ein Ausfall 12

13 Machine-to-Machine Kommunikation einer Anlage muss sofort behoben werden und darf nicht beispielsweise über Wochen oder Monate unbemerkt bleiben. Mit Hilfe von M2M-fähigen Geräten ist es möglich, die nötigen Informationen zum Status einer Anlage aus der Ferne auszuwerten. Die Betriebsdaten können über verschiedene Kommunikationsnetzwerke immer aktuell zum Ort der Auswertung gesendet werden. So können zum Beispiel Servicedienstleister als zentrale Stellen fungieren und sich schnell um die Auswertung der Daten verschiedener Anlagen kümmern, ohne die Daten umständlich vor Ort ablesen zu müssen. Anlagenbetreiber können sich die Betriebsdaten ihrer Anlagen beispielsweise bequem mit Hilfe eines Internetportals ansehen, während ein Installateur die Überwachung und Instandhaltung übernimmt 4. 4 Verschiedene Anbieter von Fernüberwachung [Zugriff jeweils am ]:

14 Complex Event Processing 3 COMPLEX EVENT PROCESSING Defintion Complex Event Processing: Complex Event Processing ist eine in der Informatik eingesetzte Technologie zur Erkennung und Analyse von komplexen Ereignissen und deren Verarbeitung nahezu in Echtzeit. 3.1 EINFÜHRENDES BEISPIEL In der Welt, in der wir leben, sind wir einer unglaublich großen Menge an Ereignissen ausgesetzt, welche gleichzeitig, hintereinander oder unberechenbar auftreten. Anfangs können wir daraus eventuell noch keinen Zusammenhang schließen, umso mehr Ereignisse jedoch auftreten, desto besser können wir deren Bedeutung verstehen und ihnen eine Relevanz zuordnen. Es passieren beispielsweise folgende Ereignisse: Ein Haus wird gebaut Ein Lotteriegewinn wird ausgeschüttet Würfel werden geworfen Der Hut ist nur zu Besuch im Gefängnis Bankrott Aus diesen einzelnen Ereignissen kann man keine eindeutigen Rückschlüsse ziehen. Werden sie jedoch gemeinsam betrachtet, lässt sich schnell erkennen, dass es sich hierbei um das Brettspiel Monopoly handelt. (angelehnt an [9] S.7) Unser Gehirn ist es gewohnt, Ereignisse in ihrem Zusammenhang zu interpretieren. Mit Event Processing ist dies nun auch für Softwareanwendungen möglich, solange die Ereignisse technisch erfassbar sind. [9] 14

15 Complex Event Processing 3.2 GRUNDLEGENDE BEGRIFFE In folgendem Abschnitt sollen grundlegende Begriffe eingeführt werden, die für das Verständnis von Complex Event Processing benötigt werden EREIGNIS Unter dem Begriff Ereignis (engl. event) bei Complex Event Processing, ist ein Vorkommnis zu verstehen, welches durch ein Computersystem verarbeitet werden kann. [10] Ereignisse treten in einem Ereignisstrom auf und werden in unterschiedliche Abstraktionsebenen unterschieden. Feingranulare Daten, die meist in großer Menge kontinuierlich und hochfrequenziert erzeugt werden (z.b. Sensordaten), stellen recht einfache Ereignisse dar und haben somit eher einen niedrigen Abstraktionsgrad. Werden die einfachen Ereignisse korreliert und/oder aggregiert, lassen sich daraus komplexe Ereignisse mit einem hohen Abstraktionsgrad gewinnen (siehe Abbildung 3.1). [11], [10] Abbildung 3.1: Abstraktion von Ereignissen über mehrere Ebenen (angelehnt an [11] S. 86) EREIGNISMODELL Ereignismodelle dienen dazu, im System auftretende Ereignisse in einen Zusammenhang zu stellen und somit die Beziehungen und Abhängigkeiten zwischen den einzelnen Ereignistypen formal festzuhalten. Hierbei entsteht in den meisten Fällen, durch Generalisierung und Spezialisierung, eine Ereignishierarchie mit Ober- und Untertypen. Dabei wird zwischen abstrakten Ereignistypen und konkreten Ereignistypen unterschieden, wobei die abstrakten 15

16 Complex Event Processing Ereignistypen ausschließlich der Strukturierung des Modells dienen und nicht instanzierbar sind. Meistens wird dazu ein schwach abgeändertes UML (Unified Modeling Language) Klassendiagramm benutzt. Eine konkrete Entwicklung eines Ereignismodells wird in Kapitel 6 gezeigt. [11] EREIGNISREGELN Das für das System entwickelte Ereignismodell wird in entsprechenden Ereignisregeln abgebildet. Diese verarbeiten die im Ereignisstrom vorkommenden Ereignisse, indem sie Ereignisse aggregieren und miteinander korrelieren und somit ein neues, abgeleitetes Ereignis mit höherem Abstraktionsgrad generieren. Zur Realisierung dienen sogenannte Event Processing Languages (EPL), mit denen sich Ereignismuster (Bedingungsteil) und die darauf folgende Reaktion (Aktionsteil) deklarativ beschreiben lassen. Ein Ereignismuster setzt sich beispielsweise aus einer Reihenfolge definierter Ereignisse zusammen, bei deren Erfüllung eine bestimmte Aktion ausgeführt wird. [11] Das Ereignismuster (A or B) (C or D) ist erfüllt, wenn im Ereignisstrom zuerst Ereignis A oder B gefolgt von ( Operator) einem Ereignis vom Typ C oder D auftritt. In Kapitel Ereignisregeln6.2.2 und werden einige Ereignisregeln vorgestellt EVENT PROCESSING AGENT Die bisher in Kapitel 3.2 erklärten Teilkomponenten bilden zusammen einen Event Processing Agent (EPA). Ein EPA empfängt kontinuierlich über einen Eingangsstrom Ereignisse, welche in die Engine hineingereicht werden. Die Engine erkennt die in den Ereignisregeln festgelegten Muster und führt den dort definierten Aktionsteil aus. Auf diese Weise können zum Beispiel komplexe Ereignisse erzeugt werden, die den EPA über den Ausgangsstrom verlassen können. Abbildung 3.2: Aufbau eines Event Processing Agents (angelehnt an [11]) 16

17 Complex Event Processing EVENT PROCESSING NETWORK Ein Event Processing Network (EPN) umfasst mehrere Event Processing Agents (Kapitel 3.2.4), die miteinander verbunden sind. Die Komplexität eines Systems wird meistens auf mehrere Event Processing Agents aufgeteilt, wobei zum Beispiel anfangs eine einfache Aggregierung bzw. Filterung von Ereignissen vorgenommen wird und der daraus resultierende Ausgangsstrom wiederum als Eingangsstrom des nächsten Event Processing Agents dient (siehe Abbildung 3.2). Somit wird mit der Aufteilung der Ereignisregeln auf die verschiedenen Agents ein übersichtlicheres, besser zu wartendes System geschaffen. 17

18 Stand der Technik 4 STAND DER TECHNIK 4.1 COMPLEX EVENT PROCESSING BEI M2M Der Einsatz von Complex Event Processing im Machine-to-Machine Sektor ist derzeit noch nicht populär, obwohl das Zusammenspiel dieser Technologien, wie schon in der Motivation dieser Arbeit erwähnt, klare Vorteile für Unternehmen bieten kann. Zwar zeigt sich die steigende Bedeutsamkeit von Complex Event Processing darin, dass marktführende Unternehmen, wie zum Beispiel IBM, SAP und Oracle, bereits eigene CEP-Engines anbieten, eine offensichtliche Verbindung zur M2M-Branche kann aber noch nicht erkannt werden. Es gibt jedoch bereits einige Anbieter von Standardsoftware, welche zur Auswertung von Ereignissen auf Complex Event Processing setzt, die von im M2M-Sektor tätigen Unternehmen erworben werden können. Beispielsweise kann sich eine Firma im Logistik-Sektor eine Software zur Standortüberwachung und Routenplanung kaufen 5 und diese auf die besonderen Bedürfnisse anpassen. Zur Auswertung der auftretenden Ereignisse (zum Beispiel GPRS-Daten eines LKWs) wird, bei dem in Fußzeile 5 angegebenem Anbieter, zum Beispiel die Complex Event Processing Engine Drools Fusion 6 eingesetzt. Zudem gibt es aktuell mehrere Forschungsprojekte zum Thema Complex Event Processing in Verbindung mit M2M, die sich zum Beispiel mit intelligenten Automatisierungssystemen beschäftigen. Dies wird in Kapitel 9.2 Zukunftsaussichten genauer beschrieben. 4.2 ÜBERWACHUNG VON PHOTOVOLTAIKANLAGEN Die kontinuierliche Überwachung von Photovoltaikanlagen ist unverzichtbar, um eine maximale Ertragssicherheit über die gesamte Anlagenlaufzeit erreichen zu können. Aktuell werden für eine Überwachung unterschiedliche Verfahren eingesetzt: 5 Möglicher Anbieter Vistracks Inc. [jeweils abgerufen am ]: solutions.aspx, 6 Complex Event Processing Engine Drools Fusion : [abgerufen am ] 18

19 Stand der Technik Bei kleineren Privatanlagen kann die Überwachung durch Selbstablesung erfolgen. Dafür werden die erforderlichen Betriebsdaten zu regelmäßigen Tageszeiten, an im Wechselrichter integrierten Messeinrichtungen, abgelesen und zum Beispiel in einer Excel Tabelle protokolliert und verglichen. Dieses Verfahren ist zwar kostengünstig, dafür aber zeitaufwendig und je nach Anzahl der Ablesungen nur wenig aussagekräftig. Störungen der Anlage können leicht übersehen werden. Komfortabler und auch für größere Photovoltaikanlagen zur Überwachung geeignet sind sogenannte Datenlogger. Diese liegen als separate Einrichtung oder bereits integriert in den Wechselrichtern vor. Ein Datenlogger liest in regelmäßigen Abständen die Anlagendaten über eine Schnittstelle des Wechselrichters aus und legt diese dauerhaft, meist über Jahre, auf einem Speichermedium ab. [12] Abbildung 4.1: Schematische Darstellung der Weiterleitung von Betriebsdaten einer Photovoltaikanlage Die gespeicherten Daten werden anschließend zum Beispiel per WLAN oder GPRS weitergeleitet (wie beispielhaft in Abbildung 4.1 dargestellt). Datenempfänger können portable Anzeigegeräte, Smartphones oder Webportale sein, auf denen die Daten visualisiert werden. Mit Hilfe der detaillierten Visualisierung lassen sich Unregelmäßigkeiten in den zeitlichen Verläufen erkennen und somit Störungen der Anlage zeitnah beheben. Um Störungen automatisiert erkennen zu können, gibt es einerseits Datenlogger mit integrierter Auswertungsfunktion, die Fehlercodes erzeugen, welche dem Benutzer angezeigt werden. [13] Andererseits können die ausgelesenen Daten an einen Server geschickt werden, der diese in einer Datenbank ablegt und für die weitere Auswertung zuständig ist. Die Auswertung an 19

20 Stand der Technik sich erfolgt zurzeit bei den meisten Systemen noch auf konventionelle Art. Das bedeutet die Implementierung der Ereignisverarbeitung erfolgt in selbst geschriebenen Quelltexten und es wird keine CEP Komponente verwendet. [3, p. 74] Eine CEP-Komponente würde an dieser Stelle allerdings viele Vorteile gegenüber einer konventionellen Programmierung bieten. Einerseits ist der Quellcode der Ereignisverarbeitung schwer vom technischen Quellcode zu trennen und liegt fragmentiert in diesem vor, was das System unflexibel und unübersichtlich macht. Änderungen im System sind somit schwer umzusetzen. Auch das Erkennen von komplexen Ereignissen, bei denen zum Beispiel die Messungen mehrerer Wechselrichter miteinander verglichen werden müssen, ist mit Hilfe imperativer und objektorientierter Programmiersprachen nur schwer umzusetzen. Dabei müsste auf zahlreiche geschachtelte ifund switch-anweisungen zurückgegriffen werden, woraus ein kompliziertes, schwer wartbares System entsteht. Anderen Szenarien, die ebenfalls mit einer CEP-Engine einfach zu erkennen sind, wie beispielsweise zeitlich aufeinander folgende Ereignisse, müssten ebenfalls mühsam implementiert werden. Außerdem wird die Reaktionszeit, die eine Ereignisverarbeitung mit CEP bietet, von einer konventionellen Programmierung nicht erreicht. [3] 20

21 Oracle CEP 5 ORACLE CEP 5.1 ORACLE CEP ARCHITECTURE Oracle Complex Event Processing ist ein Java Container (Oracle Event Processing-Container, kurz OEP-Container), der auf das Framework Open Service Gateway initiative (OSGi ) 7 basiert und somit eine leichtgewichtige, modulare Architektur aufweist. Abbildung 5.1 zeigt den Softwarestack von Oracle Complex Event Processing. Auf der untersten Ebene ist die Java Virtual Machine, welche das Fundament darstellt. Die nächste Schicht besteht aus dem Module Framework (OSGi). Dieses ermöglicht Modulen den Import und Export von Java-Klassen zu steuern und ist zudem noch für das Laden und die Versionierung von Klassen zuständig. Das darüberliegende Service Framework (Spring) 8 ist für das Instanziieren von Serviceklassen zuständig. Es löst zudem Abhängigkeiten zwischen den Services und reichert diese, durch Dependency Injection, mit Konfigurationsdaten und Referenzen zu anderen Services an. Die letzte Schicht des Softwarestacks für Oracle Complex Event Processing stellen die Module dar. Es werden zwei Arten von Modulen unterschieden. Zum einen Module, welche für die Server Implementierung zuständig sind und zum anderen welche, die Anwendungen auf einem Server deployen. Die Architektur sieht keine technische Abgrenzung zwischen Server- und Anwendungsmodulen vor. Anwendungsmodule verwenden Dienste, die von Servermodulen angeboten werden, wobei deren Funktionalitäten durch Anwendungsmodule auch erweitert werden können. [14] 7 OSGi: [Zugriff am ] 8 Service Framework Spring : [Zugriff am ] 21

22 Oracle CEP Abbildung 5.1: Softwarestack von Oracle CEP 5.2 EINFÜHRUNG DER ORACLE CEP KOMPONENTEN Im Folgenden werden die wichtigsten Komponenten von Oracle CEP kurz vorgestellt, die anschaulich im Hello World Beispiel in Kapitel 5.4 als konkretes Beispiel verwendet werden EVENT ERSTELLUNG UND REGISTRIERUNG Ereignisse (vgl. Kapitel 3.2.1) werden bei Oracle CEP als Events bezeichnet. Sämtliche Events werden über das Spring Framework basierte Assembly File bei dem OEP-Container registriert. Dabei bietet Oracle CEP die Möglichkeit, Attribute eines Events auf zwei unterschiedliche Weisen zu definieren. Eine Variante sieht das Anlegen eines Events in einer separaten Java Klasse vor. Darin werden die Attribute wie in Java üblich definiert. Dabei muss beachtet werden, dass die dazugehörigen Getters und Setters erstellt werden. Diese Methoden, sowie auch die tostring() Methode, können über die Eclipse IDE komfortabel generiert werden. [15] Anschließend wird im Assembly File, wie in Code 5.1 zu sehen, dem Event durch das Element <wlevs:class> die entsprechende Java Klasse zugewiesen. 1: <wlevs:class>de.hshannover.liebetruth.ba.helloworld.myevents.helloworldevent</wlevs:class> Code 5.1: Zuweisung einer Java Klasse zu einer Komponente im Assembly File Eine andere Variante sieht das Anlegen eines Events ausschließlich in dem in XML verfassten Assembly File vor. Dafür wird, wie in der ersten Variante, zuerst in dem Element eventtype-repository ein neues Element event-type angelegt und diesem das Attribut 22

23 Oracle CEP type-name hinzugefügt. Die Attribute des Events werden nun jedoch nicht über eine separate Java Klasse definiert, sondern direkt in XML. In Code 5.2 wird die Vorgehensweise verdeutlicht. 1: <wlevs:event-type-repository> 2: <wlevs:event-type type-name= HelloWorldEvent > 3: <wlevs:properties type= tuple > 4: <wlevs:property name= message type= String /> 5: <wlevs:property name= id type= int /> 6: </wlevs:properties> 7: </wlevs:event-type> Code 5.2: Definition von Eventattributen im Assembly File ADAPTER Adapter stellen Event Sources (Sender) und Event Sinks (Empfänger) am Anfang sowie am Ende einer Anwendung dar. Sie dienen unter anderem dazu, Eventdaten zu empfangen und für die Weiterverarbeitung vorzubereiten, indem die empfangenen Daten in eine normalisierte Form (Events) übertragen werden. Es stehen mehrere vorgefertigte Adapter zur Verfügung, zum Beispiel für JMS, CSV und HTTP pub-sub. Zusätzlich ist es möglich, eigene Adapter für andere Protokolle zu erstellen, um sämtliche benötigte Daten aus anderen Anwendungen importieren (und exportieren) zu können, aus denen die Events gebildet werden. [16] PROCESSOR Der Processor ist das Kernstück einer OEP-Anwendung, und entspricht einem Event Processing Agent, vgl. Kapitel In einem Processor werden die Regeln einer Anwendung definiert. Im Assembly File wird ein Processor mit dem Element <wlevs:processor> angelegt, welchem ein ID-Attribut zugewiesen wird. Die Abfragen, die der Processor tätigt, sind in einem sogenannten Configuration File (siehe Code 5.13) hinterlegt, der ein Teil eines jeden Processors darstellt. Dieser befindet sich im wlevs Unterordner und kann beliebig benannt werden (Konvention: gleicher Name wie ProcessorID), muss jedoch die Endung.xml besitzen. [9, p. 94] Neben der Definition der Regeln wird im Configuration File den Outputchannels (Downstreamchannels) jeweils eine Regel zugewiesen, deren Output sie weiterleiten (siehe Hello World Beispiel Code 5.13). 23

24 Oracle CEP CHANNEL Channels stellen die Verbindungen zwischen den einzelnen Komponenten dar. Sie sind für die Weiterleitung von Events zuständig. Registriert werden sie, wie alle anderen Oracle CEP Komponenten auch, indem im Assembly File ein <wlevs:channel> Element erstellt wird. Dabei wird jedem Channel ein ID-Attribut zugewiesen. Steht ein Channel mit einem Processor in Verbindung, muss zusätzlich das Attribut event-type angegeben werden. [9, p. 92] Dieser Channel ist dann nur noch in der Lage, Events des angegebenen Typs weiterzuleiten (siehe Code 5.3 Zeile 1). Um Komponenten mit Channels zu verbinden, muss grundsätzlich die Richtung der Weiterleitung definiert werden. Dies geschieht mittels des Elements <wlevs:source>, welches auf eine zurückliegende Komponente verweist, die somit als Quelle fungiert. Zusätzlich können mittels des Elements <wlevs:listener> beliebig viele nachfolgende Komponenten (Downstream Listeners) registriert werden, die den Channel als Quelle nutzen (siehe Code 5.3 Zeile 2). Die Verweise Source und Listener können sowohl in Channels, als auch in anderen Komponenten hinterlegt sein. 1: <wlevs:channel id="helloworldinputchannel" event-type="helloworldevent"> 2: <wlevs:listener ref="helloworldprocessor" /> 3: </wlevs:channel> Code 5.3: Channelerstellung im Assembly File EVENT BEAN Event Beans können, genau wie Adapter, als Event Sources und Event Sinks genutzt werden. Das heißt, sie sind in der Lage Events zu empfangen, diese im Java Code zu verwenden, und an Downstream Listeners zu senden. Der Unterschied zu einem Adapter liegt darin, dass Event Beans innerhalb einer OEP-Anwendung verwendet werden, wobei Adapter den Eingangs- bzw. Ausgangsstrom einer Anwendung darstellen. [9] DEVELOPMENT ENVIRONMENT FÜR ECLIPSE Oracle CEP Development Environment for Eclipse ( kurz: Oracle CEP tools) ist eine Sammlung von Plugins für die Eclipse IDE, die das Entwickeln von Anwendungen mit Oracle CEP unterstützen soll. [16] 24

25 Oracle CEP PROJECT CREATION WIZARD Mit Hilfe des integrierten Project wizards ist es möglich, schnell und komfortabel ein Oracle CEP Projekt zu erstellen (Abbildung 5.3). Zusätzlich stehen vorgefertigte Einführungsbeispiele zur Verfügung (Abbildung 5.2). Abbildung 5.3: Creation Wizard 1 Abbildung 5.2: Creation Wizard 2 GRAPHISCHE EDITOREN In den vorherigen Abschnitten von Kapitel 5.2 wurde gezeigt, wie die einzelnen Komponenten eigenhändig in der entsprechenden Konfigurationsdatei erstellt werden. Oracle CEP bietet dafür zusätztlich auch graphische Editoren an, die dem Entwickler bei der Erstellung von Anwendungen unterstützen und ihm zusätzlich einen besseren visuellen Überblick bieten. Somit ist eine manuelle Bearbeitung der Konfigurationsdateien nicht mehr zwingend notwendig, denn dies kann über die jeweiligen visuellen Oberflächen abgewickelt werden. Die folgenden Abbildungen geben einen Überblick über die wichtigsten angebotenen Editoren. 25

26 Oracle CEP Event Type Definition: Abbildung 5.4: Event Type Definition Editor Assembly File: Abbildung 5.5: Assembly File Editor Configuration File: Abbildung 5.6: Configuration File Editor 26

27 Oracle CEP Manifest.mf: Abbildung 5.7: Manifest Datei Editor INTEGRIERTES SERVER MANAGEMENT Um Oracle CEP-Server komfortabel zu erstellen und zu verwalten, ist ein integriertes Server Management vorhanden. VISUELLE DARSTELLUNG VON EVENT PROCESSING NETWORK (EPN) Oracle CEP Tools bietet eine visuelle Darstellung, die alle Komponenten einer Anwendung und deren Zusammenhänge zeigt. Die Darstellung bietet, neben der Übersichtlichkeit für den Benutzer, auch die Möglichkeit Komponenten direkt über die Oberfläche zu erstellen und miteinander zu verbinden (Abbildung 5.8). Abbildung 5.8: EPN-Editor 27

28 Oracle CEP 5.3 ORACLE CONTINUOUS QUERY LANGUAGE Die in Oracle CEP verwendete deklarative Abfragesprache Oracle Continuous Query Language (Oracle CQL), die im Jahr 2009 zusammen mit der Version Oracle CEP 11g Release 1 eingeführt wurde, stellt eine Erweiterung der häufig verwendeten Abfragesprache von Datenbanken SQL (Structured Query Language) dar. Durch diese Erweiterung ist es möglich, neben Relationen nun auch Streams (Datenströme) zu verarbeiten. [17] Folgendes Beispiel (Code 5.4) zeigt eine sehr einfache Oracle CQL-Abfrage (Query). Die FROM- Klausel in Zeile 2 legt fest, aus welcher Quelle die Input-Events stammen. Bevor der Preis in der SELECT-Klausel (Zeile 1) für den Output selektiert wird, muss die Bedingung in der WHERE- Klausel (Zeile 3) erfüllt sein. In diesem Beispiel-Code sieht man, dass die Vorgehensweise einer (einfachen) Abfrage in Oracle CQL, einer in SQL stark ähnelt. 1: SELECT preis 2: FROM preisinputchannel 3: WHERE name = Erdoel Code 5.4: einfache CQL-Query Begrifflichkeiten, die aus der SQL-Umgebung bekannt sind und in Oracle CQL mit der gleichen Bedeutung verwendet werden, werden hier nicht weiter erläutert. Dazu gehören zum Beispiel: Joins, Views, Aggregationsfunktionen (z.b. count, sum, max, min, avg), HAVING, ORDER BY und GROUP BY. Zusätzlich zu den in SQL verwendeten Sprachelementen, gibt es jedoch durch die erwähnte Erweiterung auch zahlreiche neue, die die Verarbeitung von Events in Streams (Datenströmen) ermöglichen. Im Folgenden sollen einige Grundelemente von Oracle CQL kurz vorgestellt werden, die zum größten Teil auch in Kapitel 7.2 verwendet werden. EINSCHRÄNKUNG VON STREAMS MIT HILFE VON WINDOWS (WINDOW OPERATOREN) In Code 5.4 wurde ein Event im Augenblick seines Auftretens verarbeitet und gegebenenfalls das Ergebnis sofort weitergeleitet. Mit Hilfe eines Window-Operators ist es möglich, den Stream auf verschiedene Weisen einzuschränken. Ist es zum Beispiel erforderlich, den Durchschnittspreis der in den preisinputchannel ankommenden Preis-Events in einer 28

29 Oracle CEP bestimmten Zeitspanne herauszufinden, kann dies mittels des Window-Operators RANGE realisiert werden (Code 5.5). 1: SELECT AVG(preis) 2: FROM preisinputchannel [RANGE 10 MINUTES] Code 5.5: Window Operator RANGE Mit Hilfe des Window-Operators ROW ist es außerdem möglich, eine bestimmte Anzahl von Events festzulegen, deren Durchschnitt gebildet werden soll (Code 5.6). Dabei werden jeweils die zuletzt in den InputChannel ankommenden Events berücksichtigt. Dieses sogenannte Window ist im Gegensatz zu dem Window-Operator RANGE nicht zeitlich begrenzt, sondern solange gültig, bis die angegebene Anzahl durch ein weiteres ankommendes Event überschritten wird. 1: SELECT AVG(preis) 2: FROM preisinputchannel [ROWS 3] Code 5.6: Window Operator ROW Zusätzlich sind Windows in der Lage, Events nach einem bestimmten Attribut zu partitionieren, sodass wie im Code 5.7 verwendeten Beispiel dargestellt, von den jeweils letzten drei Events mit dem bestimmten Attribut name der Durchschnitt gebildet wird. 1: SELECT AVG(preis) 2: FROM preisinputchannel [PARTITION BY name ROWS 3] 3: GROUP BY name Code 5.7: Window Operator ROW mit Partitionierung PATTERN MATCHING Eines der wichtigsten Ziele von Complex Event Processing besteht darin, komplexe Ereignisse zu erkennen (siehe Definition Seite 14). Dazu müssen bestimmte Muster von Ereignissen, sogenannte Pattern, in einem Stream (Ereignisstrom) gefunden werden. Diese Muster können komplexe Bedingungen beinhalten, mit denen beispielsweise bestimmte Eventabfolgen erkannt werden. Diese Mustererkennung wird allgemein Pattern Matching genannt und in Oracle CQL durch den MATCH_RECOGNIZE-Operator realisiert. 29

30 Oracle CEP Im Folgenden ist eine beispielhafte Abfrage, die das Grundgerüst eines MATCH_RECOGNIZE- Operators beinhaltet, zu sehen. 1: SELECT M.preisAnstieg 2: FROM preisinputchannel 3: MATCH_RECOGNIZE ( 4: MEASURES 5: B.preis as preisanstieg 6: PATTERN (A B) 7: DEFINE 8: A as preis < 10.0, 9: B as preis > :) as M Code 5.8: Grundgerüst eines MATCH_RECOGNIZE Operators (angelehnt an [9, p. 199]) Die Pattern-Subklausel in Zeile 6 stellt den Kern eines Pattern Matchings dar, denn sie definiert die Reihenfolge von Events, die erkannt werden soll. Kommen die sogenannten Korrelationsvariablen, die in dem Beispiel A und B genannt wurden, in der angegeben Reihenfolge im Stream vor, matched das Pattern. Die Eigenschaften der Korrelationsvariablen werden in der DEFINE-Subklausel näher bestimmt (Zeile 7-9). Ist eine Korrelationsvariable nicht in der DEFINE-Subklausel näher definiert, gelten alle ankommenden Events als zutreffend. Um zum Beispiel in der SELECT-Klausel auf die Ergebnisse des Pattern Matching zugreifen zu können, muss einerseits dem MATCH_RECOGNIZE-Operator, wie in Zeile 10 zu sehen, ein Alias zugewiesen werden. Andererseits müssen in der MEASURES-Subklausel (Zeile 4-5) die gewünschten Attribute der Korrelationsvariablen angegeben werden. Ähnlich wie in Code 5.7 ist auch hier eine Partitionierung der Events nach einem bestimmten Attribut durch Einfügen einer PARTITION BY-Subklausel über der MEASURES-Subklausel möglich. Um die Pattern-Subklausel genauer zu spezifizieren, können sogenannte Pattern- Quantifikatoren als reguläre Ausdrücke hinter den Korrelationsvariablen definiert werden (einige Beispiele werden in Kapitel 7.2 aufgeführt):? null oder ein Events * null oder mehr Events + ein oder mehr Events OR-Operator () Gruppierung 30

31 Oracle CEP Bei der Benutzung solcher Pattern-Quantifikatoren ist jedoch zu berücksichtigen, dass eine Query entweder versucht, so viele Events wie möglich zu finden (greedy match) oder nach dem erstmaligen Eintreffen der Mindestbedingungen abbricht (reluctant match). Ein reluctant match wird durch das Hinzufügen eines Fragezeichens hinter dem Quantifikator ausgedrückt. Wird dem MATCH_RECOGNIZE-Operator die Subklausel ALL MATCHES hinzugefügt, wird dafür gesorgt, dass nicht nur die maximal zutreffenden Fälle gematched werden (greedy matches), sondern alle möglichen zutreffenden Kombinationen. Wenn Korrelationsvariablengruppen, das bedeutet mehrere aufeinanderfolgende Events, die alle die in der DEFINE-Subklausel festgehaltenen Bedingungen einer Korrelationsvariablen erfüllen, auftauchen, dann können neben den Standard Aggregationsfunktionen (avg, max, min und count) folgende neue Funktionen verwenden werden: First Zugriff auf das erste Event einer Korrelationsvariablengruppe Last Zugriff auf das letzte Event einer Korrelationsvariablengruppe Prev Zugriff auf das letzte Event vor dem Aktuellen (Verwendung nur innerhalb der MEASURES-Subklausel) Die count Aggregation hat in der Verwendung innerhalb des MATCH_RECOGNIZE-Operators eine besondere Bedeutung: Count (*) gibt die Anzahl aller Events des ankommenden Streams an Count (A.*) gibt die Anzahl aller Events der Korrelationsvariablengruppe A an Count (A.p) gibt die Anzahl aller Events der Korrelationsvariablengruppe A an, deren Eigenschaft (p) nicht null ist Oftmals ist auch eine zeitliche Eingrenzung des Pattern Matches sinnvoll oder notwendig. Dafür sind zwei verschiedene Möglichkeiten gegeben, die WITHIN-Subklausel sowie die DURATION-Subklausel, die je nach den Anforderungen des Anwendungsfalles gewählt werden. Die WITHIN-Subklausel überprüft, ob die angegebene Bedingung innerhalb einer bestimmten Zeitspanne erfüllt wird. Es wird festgelegt, dass die Abfrage spätestens nach Ablauf der Zeit beendet wird. Die DURATION-Subklausel überprüft dagegen, ob nach Ablauf einer bestimmten Zeitspanne die angegebenen Bedingungen noch immer erfüllt sind. In 31

32 Oracle CEP Kapitel 7.2 werden diese beiden Subklauseln bei der Erstellung der Oracle CQL-Regeln angewendet. 5.4 HELLO WORLD BEISPIEL Im folgenden Abschnitt sollen die zuvor in Kapitel 5.2Fehler! Verweisquelle konnte nicht gefunden werden. vorgestellten Oracle CEP Komponenten in einem Hello World Beispiel verdeutlicht werden. Wie Abbildung 5.9 zeigt, enthält das Hello World Beispiel fünf Komponenten: helloworldadapter: Erzeugt in regelmäßigen Abständen HelloWorldEvents (HelloWorld- Nachrichten mit Zeitstempel) helloworldinputchannel: Sendet die aus dem helloworldadapter erzeugten HelloWorldEvents als Stream an den Complex Event Processor. helloworldprocessor: Leitet alle hineinkommenden HelloWorldEvents unter Benutzung von CQL weiter. helloworldoutputchannel: Leitet die durch den helloworldprocessor gelaufenen HelloWorldEvents zu der helloworldeventbean. helloworldeventbean: Empfängt HelloWorldEvents und gibt diese auf der Konsole aus. Abbildung 5.9: EPN HelloWorld-Beispiel Mit Hilfe des Project Creation Wizards wird ein neues Oracle CEP Projekt mit Namen HelloWorld erstellt. Im automatisch generierten src-ordner wird ein neues Package, welches den Namen de.hshannover.liebetruth.ba.helloworld.myevents trägt, angelegt. Darin wird die Javaklasse HelloWorldEvent erstellt. Die Klasse enthält als einziges Attribut den String message mit den passenden Gettern und Settern. In dem Assembly File HelloWorld.context.xml, welches im spring-ordner vorliegt, wird anschließend das Event im Event-Repository registriert. 1: <wlevs:event-type-repository> 2: <wlevs:event-type type-name="helloworldevent"> 32

33 Oracle CEP 3: <wlevs:class>de.hshannover.liebetruth.ba.helloworld.events.helloworldevent 4: </wlevs:class> 5: </wlevs:event-type> 6: </wlevs:event-type-repository> Code 5.9: Registrierung des HelloWorldEvents im Assembly File Im nächsten Schritt wird der Adapter erstellt. Dazu wird in dem dafür erstellten Package de.hshannover.liebetruth.ba.helloworld.adapters die Javaklasse HelloWorldAdapter angelegt. Eine Adapterklasse muss, um Referenzen zu den Downstream Listeners zu erhalten, wie in Code 5.10 gezeigt, das Interface Streamsource implementieren. [9] 1: private StreamSender eventsender; 2: 4: public void seteventsender(streamsender sender) { 5: eventsender = sender; 6: } Code 5.10: Implementierung des Interface Streamsource Zudem muss der Adapter das Interface RunnableBean implementieren. In der run() Methode werden HelloWorldEvents in regelmäßigen Zeitabständen generiert und gesendet. Die suspend() Methode dient dazu, den Adapter von außen stoppen zu können. 1: public class HelloWorldAdapter implements StreamSource, RunnableBean{ 2: private StreamSender eventsender; 3: private static final int SLEEP_MILLIS = 1000; 4: 5: private DateFormat dateformat; 6: private boolean suspended; 7: 9: public void seteventsender(streamsender sender) { 10: eventsender = sender; 11: } 13: public void run() { 14: dateformat = DateFormat.getTimeInstance(); 15: suspended = false; 16: while (!issuspended()) { 17: 18: generatehellomessage(); 19: 33

34 Oracle CEP 20: try { 21: synchronized (this) { 22: wait(sleep_millis); 23: } 24: } catch (InterruptedException e) { 25: e.printstacktrace(); 26: } 27: } 28: } 29: 31: public void suspend() throws Exception { 32: suspended = true; 33: } 34: private boolean issuspended() { 35: return suspended; 36: } 37: 38: private void generatehellomessage() { 39: String message = "Aktuelle Uhrzeit: " + dateformat.format(new Date()); 40: HelloWorldEvent event = new HelloWorldEvent(); 41: event.setmessage(message); 42: eventsender.sendinsertevent(event); 43: } 44:} Code 5.11: Quellcode HelloWorldAdapter.java Nach der Implementierung des helloworldadapters, wird über einen Rechtsklick auf das Projekt der EPN Editor geöffnet. Im Editor lässt sich ein neuer Adapter erstellen, dem die eben implementierte Klasse zugewiesen wird. Der helloworldinputchannel lässt sich auf dieselbe Weise anlegen und wird anschließend mit dem Adapter verbunden. Mittels eines Rechtsklicks auf den Channel gelangt man direkt zu dem im Assembly File definierten Channel. An dieser Stelle wird dem Channel der event-type HelloWorldEvent zugewiesen. 1: <wlevs:channel id="helloworldinputchannel" event-type="helloworldevent"/> Code 5.12: Zuweisung des event-types eines Channels im Assembly File Der helloworldprocessor, sowie der helloworldoutputchannel werden ebenfalls über den EPN-Editor erstellt und wie in Abbildung 5.9 dargestellt verbunden. Über einen Rechtsklick auf den Processor wird das entsprechende Configuration File geöffnet und die simple Regel, zusehen in Code 5.13 Zeile 5, implementiert. Zeile dieser Abbildung zeigt die Zuweisung 34

35 Oracle CEP der helloworldrule zu dem helloworldoutputchannel. Somit werden die von der Regel erkannten Outputevents als Stream an den Channel gesendet. 1: <processor> 2: <name>helloworldprocessor</name> 3: <rules> 4: <query id="helloworldrule"> 5: <![CDATA[ select * from helloworldinputchannel ]]> 6: </query> 7: </rules> 8: </processor> 9: 10:<channel> 11: <name>helloworldoutputchannel</name> 12: <selector>helloworldrule</selector> 13:</channel> Code 5.13: Implementierung der Regel und Zuweisung des Channels Im nächsten Schritt wird in dem Package de.hshannover.liebetruth.ba.helloworld.mybeans die Javaklasse helloworldeventbean erstellt (Code 5.14). Die Aufgabe der EventBean ist in diesem Beispiel das Empfangen von HelloWorldEvents und deren Ausgabe auf der Konsole. Dafür muss das Interface StreamSink implementiert werden. Über die Hookmethode oninsertevent() werden HelloWorldEvents empfangen und anschließend ausgegeben. 1: public class HelloWorldBean implements StreamSink { 2: 4: public void oninsertevent(object event) { 5: if (event instanceof HelloWorldEvent) { 6: HelloWorldEvent helloworldevent = (HelloWorldEvent) event; 7: System.out.println("Message: " + helloworldevent.getmessage()); 8: } 9: } 10:} Code 5.14: Erstellung der HelloWorldEventBean Im Assembly File wird die zuvor erstellte Javaklasse als EventBean registriert (vgl. Code 5.15). Den helloworldoutputchannel mit der EventBean zu verknüpfen kann, wie bei den Komponenten zuvor gezeigt, visuell über den EPN-Editor geschehen oder über ein zusätzliches <wlevs:listener> Element beim OutputChannel bzw. ein <wlevs:source> Element bei der EventBean im Assembly File. 35

36 Oracle CEP 1: <wlevs:event-bean id="helloworldeventbean" class="de.hshannover.liebetruth.ba.helloworld.eventbeans.helloworldeventbean"/> Code 5.15: Registrierung der helloworldeventbean im Assembly File Zur Ausführung des HelloWorld-Beispiels, muss das Projekt auf einem Oracle CEP Server deployed werden. Dafür wird komfortabel über die Eclipse-View Server (Abbildung 5.10) ein neuer Oracle CEP Server angelegt. Über das Kontextmenü Add and Remove... des Servers wird das Projekt dem Server zugewiesen und im Anschluss automatisch deployed. Wird der Server gestartet, fährt dieser hoch, lädt das Bundle HelloWorld und HelloWorldEvents werden auf der Konsole ausgegeben. Abbildung 5.10: Eclipse-View Server 36

37 Ereignisse einer Photovoltaikanlage 6 EREIGNISSE EINER PHOTOVOLTAIKANLAGE 6.1 AUFBAU EINER PHOTOVOLTAIKANLAGE Photovoltaikanlagen sind dazu in der Lage, Sonnenenergie in nutzbaren Strom umzuwandeln. Zuständig für die Stromerzeugung sind dabei Photovoltaikmodule, die aus einer Vielzahl von einzelnen, siliziumbasierten Solarzellen bestehen. Die Spannung der einzelnen Photovoltaikmodule addiert sich, wenn diese zu sogenannten Strings in Reihe geschaltet werden, welche dann wiederum parallelgeschaltet werden können. Allerdings ist es auf diese Weise nur möglich, die Sonnenenergie in Gleichstrom umzuwandeln. Da das allgemeine Stromnetz jedoch Wechselstrom benötigt, muss der Gleichstrom zuerst umgewandelt werden. Diese Umwandlung geschieht mit Hilfe eines Wechselrichters, der zusätzlich auch in der Lage ist, die Photovoltaikanlage am optimalen Betriebspunkt zu führen sowie ständig ihre Betriebsdaten zu erfassen und weiterzuleiten. Meistens sind mehrere Photovoltaikmodule mit einem Wechselrichter verbunden, aber größere Anlagen können auch eine Reihe von Wechselrichtern benötigen. Abbildung 6.1 zeigt den vereinfachten Aufbau einer Photovoltaikanlage. [18] [19] Abbildung 6.1: schematischer Aufbau einer Photovoltaikanlage 37

38 Ereignisse einer Photovoltaikanlage 6.2 MASCHINENEREIGNISSE Als Maschinenereignisse werden Ereignisse bezeichnet, die Informationen über einer Maschine liefern. Diese Informationen können je nach Einsatzbereich der Maschine sehr unterschiedlich ausfallen, da zum Beispiel eine Fertigungsanlage völlig andere Aufgaben erfüllt als beispielsweise eine Photovoltaikanlage. Im Allgemeinen können die Informationen jedoch den folgenden vier Kategorien zugeordnet werden: Zählerstände Zustandsinformationen Meldungen Metainformationen Die Maschinenereignisse einer Photovoltaikanlage setzen sich aus den Betriebsdaten zusammen, die der Wechselrichter erfassen und über eine Schnittstelle weiterleiten kann. Je nach Wechselrichtertyp können die erfassten Daten sich geringfügig unterscheiden, bilden aber immer einen Konsens, der folgende Daten beinhaltet: Aktuelle Netzspannung Spannung an den Solarmodulen Gesamte eingespeiste Energiemenge seit Tagesbeginn Momentan eingespeiste Leistung Diese Daten werden kontinuierlich mit Hilfe eines M2M-Systems aus dem Wechselrichter ausgelesen und zur Weiterverarbeitung und Auswertung weitergesendet. [3] EREIGNISMODELL In der Masterarbeit Event-Driven Architecture in M2M-Systemen aus dem Jahr 2011 von Ilja Hellwig wurde bereits ein Maschinenereignismodell für das Szenario einer Auswertung von Photovoltaikanlagen erstellt. Dieses Ereignismodell wird größtenteils auch in dieser Arbeit verwendet und ist in der folgenden Abbildung zu sehen. 38

39 Ereignisse einer Photovoltaikanlage Abbildung 6.2: Ereignismodell der Maschinenereignisse Die Herleitung dieses Modells, sowie die Bedeutung und Funktion der abstrakten Ereignisse ist in der genannten Masterarbeit [3] ausführlich beschrieben und wird daher an dieser Stelle nicht weiter erläutert. Die Erklärung der übrigen Ereignisse erfolgt zusammen mit der Vorstellung der Ereignisregeln 9 im nächsten Abschnitt. 9 Die Implementierung der Ereignisregeln in Oracle CQL erfolgt in Kapitel

40 Ereignisse einer Photovoltaikanlage EREIGNISREGELN Die Verarbeitung der Maschinenereignisse umfasst insgesamt vier Ereignisregeln, die die komplexen Ereignisse LowNetPower-, MissingInverterData-, LowNetVoltage- und StateProblem-Ereignis erzeugen und im Folgenden vorgestellt werden. Diese vier Ereignisregeln basieren auf der Auswertung von InverterMeasurement-Ereignissen. Ein InverterMeasurement-Ereignis beinhaltet dabei die von einem Wechselrichter erfassten Betriebsdaten einer Photovoltaikanlage. LOWNETPOWER-EREIGNIS Ein LowNetPower-Ereignis wird erkannt, wenn die aktuell von einem Wechselrichter gemessene Leistung zu niedrig ist. Um festzustellen, ob tatsächlich eine Störung vorliegt, oder ob eine zu geringe Sonneneinstrahlung (zum Beispiel in der Nacht) zu der Leistungseinbuße geführt hat, werden die Messungen von verschiedenen geographisch naheliegenden Wechselrichtern verglichen. LOWNETVOLTAGE-EREIGNIS Unterschreitet die anliegende Netzspannung eines Wechselrichters plötzlich wiederholt einen festgelegten Schwellenwert, während die generierte Spannung gleichbleibt oder ansteigt, so wird ein LowNetVoltage-Ereignis erkannt. Ursache eines solchen Verhaltens kann beispielsweise eine ausgelöste Sicherung sein, sodass der Wechselrichter in diesem Fall keine Energie einspeisen kann. MISSINGINVERTERDATA-EREIGNISSE MissingInverterData-Ereignisse repräsentieren das Fehlen von Wechselrichtermessungen, obwohl der Wechselrichter in Betrieb sein sollte. Dies wird erkannt, wenn über einen bestimmten Zeitraum InverterMeasurement-Ereignisse eines Wechselrichters ausbleiben, während in der Nähe befindliche Wechselrichter weiterhin Ereignisse liefern. STATEPROBLEM-EREIGNIS Ist ein Wechselrichter in der Lage, eigenständig Fehlfunktionen zu erkennen, dann wird dies innerhalb des Attributs state des InverterMeasurement-Ereignisses festgehalten. 40

41 Ereignisse einer Photovoltaikanlage Dementsprechend wird ein StateProblem-Ereignis erkannt, sobald das Attribut state einen Wert über null aufweist. 6.3 KOMMUNIKATIONSEREIGNISSE Der Kommunikationsweg bei Photovoltaikanlagen stellt einen essentiellen Bestandteil für die Überwachung solcher Anlagen dar. Eine funktionierende Kommunikation sorgt dafür, dass Maschinenereignisse weitergeleitet und verarbeitet werden können. Daher ist eine zusätzliche Auswertung von Kommunikationsereignissen besonders wichtig. [3] Die Kommunikation kann, wie in Kapitel 2.1 bereits erwähnt, über verschiedene Kommunikationsnetzwerke durchgeführt werden. Bei der im Folgenden entwickelten Anwendung zur Überwachung von Photovoltaikanlagen wird das GSM/GPRS-Netz verwendet. GSM/GPRS GPRS (General Packet Radio Service) ermöglicht eine drahtlose Datenübertragung über ein beliebiges GSM-Netz 10. Bei dieser Technologie werden die Daten in kleinen Paketen zerlegt über das Internet Protocol (IP) 11 übermittelt und beim Empfänger wieder zusammengesetzt. In Deutschland verteilt gibt es zahlreiche GSM-Basisstationen, die von verschiedenen Providern betrieben werden, und jeweils einen bestimmten Empfangsradius bieten. Folgende Abbildung 6.3 beschreibt eine IP-basierte Kommunikation über GSM/GPRS. [3] 10 GSM-Netz: [Zugriff am ] 11 Internet Protocol, RFC 791 (Standard), September Updated by RFC

42 Ereignisse einer Photovoltaikanlage Abbildung 6.3: IP-basierte Datenkommunikation mittels GPRS [3] Auf Grund verschiedener Faktoren, wie zum Beispiel eine schlechte Funkverbindung, überlastete GSM-Basisstationen oder sonstige Netzwerkprobleme kann es häufiger zu Verbindungsabbrüchen kommen. Auch typisch sind Wechsel von einer GSM-Basisstation zu einer anderen. Einige dieser Faktoren verursachen jedoch nur eine kurzfristige Unterbrechung der Verbindung, die nach kurzer Zeit selbstständig wiederhergestellt wird. Diese Verhaltensweisen müssen bei der Ereignisverarbeitung durch entsprechende Regeln berücksichtigt werden. [3] EREIGNISMODELL In der Masterarbeit Event-Driven Architecture in M2M-Systemen aus dem Jahr 2011 von Ilja Hellwig wurde bereits ein Kommunikationsereignismodell für das Szenario einer Auswertung von Photovoltaikanlagen erstellt. Dieses Ereignismodell ist sehr gut geeignet, die in Kapitel 6.3 erwähnten Probleme in einem GSM/GPRS-Netz durch entsprechend implementierte Regeln zu lösen und wurde deshalb größtenteils übernommen. Die hier dargestellten Ereignisse werden, bis auf die abstrakten Ereignisse, im nächsten Abschnitt zusammen mit den Ereignisregeln vorgestellt und erläutert. 42

43 Ereignisse einer Photovoltaikanlage Abbildung 6.4: Kommunikationsereignisse bei Verwendung von GSM/GPRS-Netzen EREIGNISREGELN Die folgenden Ereignisregeln zur Erkennung und Verarbeitung der Kommunikationsereignisse basieren auf den vom Wechselrichter zur Verfügung gestellten Ereignissen GPRSConnect und GPRSDisconnect. Ein GPRSConnect-Ereignis steht dabei für eine erfolgreich hergestellte Verbindung zwischen einer Maschine und dem zentralen Knotenpunkt, während ein GPRSDisconnect-Ereignis auftritt, sobald diese Verbindung unterbrochen ist. CONNECTIONPROBLEM-EREIGNIS ConnectionProblem-Ereignisse treten auf, wenn eine Maschine in kurzen Abschnitten wiederholt eine Verbindung aufbaut. Möglicher Grund hierfür kann ein defektes Bauteil oder eine gestörte Stromversorgung sein. MISSINGCONNECTION-EREIGNIS Ein Ereignis des Typs MissingConnection steht für eine unterbrochene Verbindung. Wie in Kapitel 6.3 erwähnt, ist zum Beispiel ein kurzzeitiger Verbindungsabbruch bei Benutzung eines GSM-Netzes nicht ungewöhnlich. Deshalb darf für die Erkennung eines MissingConnection- 43

44 Ereignisse einer Photovoltaikanlage Ereignisses nach Auftreten eines GPRSDisconnect-Ereignisses innerhalb einer bestimmten Zeitspanne kein GPRSConnect-Ereignis der gleichen Maschine auftreten. PROVIDERPROBLEM-EREIGNIS Tritt eine bestimmte Anzahl an MissingConnection-Ereignissen innerhalb einer bestimmten Zeit auf, wird ein ProviderProblem-Ereignis erkannt. Dabei müssen die MissingConnection- Ereignisse den gleichen GSM-Provider aufweisen, das bedeutet die Attribute mnc und mcc der Ereignisse müssen gleich sein. REGIONALPROBLEM-EREIGNIS Tritt eine gewisse Anzahl an MissingConnection-Ereignissen innerhalb einer bestimmten Zeitspanne auf und liegen diese zudem noch regional nah beieinander, ist ein RegionalProblem-Ereignis erkannt. Dies kann auf Funktionsstörungen von GPRS-Netzen hinweisen, die providerübergreifend eintreten können, jedoch örtlich begrenzt werden können. EXISTINGCONNECTION-EREIGNIS Ein ExistingConnection-Ereignis tritt auf, wenn auf ein MissingConnection-Ereignis ein GPRSConnect-Ereignis folgt. Jedoch darf anschließend innerhalb einer gewissen Zeitspanne kein GPRSDisconnect-Ereignis auftreten. 44

45 Technische Umsetzung 7 TECHNISCHE UMSETZUNG 7.1 EVENT PROCESSING NETWORK FÜR PHOTOVOLTAIKANLAGEN Dieser Abschnitt stellt das entworfene Event Processing Network (EPN) für die Verarbeitung sämtlicher Ereignisse einer Photovoltaikanlage vor. Die in Kapitel und 6.3.2vorgestellten Regeln werden auf unterschiedliche Processoren (vgl. Kapitel 5.2.3) aufgeteilt, wobei erneut zwischen Kommunikations- und Maschinenereignissen unterschieden wird. Jedem Processor wird eine Regelmenge zugewiesen wird, der damit eine bestimmte Aufgabenbereich abdeckt, somit wird das Gesamtsystem durch die Verteilung der Komplexität übersichtlicher, verständlicher und wartungsfreundlicher. Die Verarbeitung der Kommunikationsereignisse, zu sehen im roten Kasten in Abbildung 7.1, erfolgt über zwei Processoren, dem GPRSConnection-Processor und dem GPRSNetwork- Processor. Aus den einfachen Ereignissen GPRSDisconnect und GPRSConnect werden zunächst in dem GPRSConnection-Processor die Ereignisse MissingConnection und ConnectionProblem erzeugt, welche nun einen höheren Abstraktiongrad aufweisen. Die so gewonnenen Ereignisse werden anschließend zur Ereignisbehandlung weitergeleitet, zudem werden MissingConnection-Ereignisse zusätzlich in den GPRSNetwork-Processor weitergeleitet. Dieser ist für die Erzeugung der komplexen Ereignisse ProviderProblem, RegionalProblem und ExistingConnection verantwortlich. Die auftretenden Maschinenereignisse (InverterMeasurements) werden vom InverterProblem-Processor empfangen und ausgewertet. Dabei entstehen die komplexen, in Kapitel erklärten Ereignisse LowNetVoltage, LowNetPower, StateProblem und MissingInverterData, die direkt zur Ereignisbehandlung weitergereicht werden. 45

46 Technische Umsetzung Abbildung 7.1: Event Processing Network für Photovoltaikanlagen (Aufgrund des offenen Problems bei der Implementierung der Regeln (beschrieben in Kapitel 8.2), wurden die Ereignisse MissingConnection sowie ExistingProblem nicht in dem GPRSConnection-Processor bzw. dem GPRSNetwork-Processor erkannt und erzeugt, sondern mit Hilfe eines Adapters importiert, wie in Abbildung 7.2 zu sehen ist.) 7.2 IMPLEMENTIERUNG In folgendem Teilabschnitt wird zuerst die Implementierung der benötigten Oracle CEP Komponenten gezeigt, wobei die Realisierung der Processoren danach gesondert behandelt wird IMPLEMENTIERUNG DER ORACLE CEP KOMPONENTEN Zuerst wurden die in Kapitel und vorgestellten Ereignismodelle in Javaklassen abgebildet. Diese wurden anschließlich über das Assemblyfile beim OEP-Container registriert. 1: <wlevs:event-type-repository> 2: <wlevs:event-type type-name="gprsdisconnect"> 3: <wlevs:class>de.hshannover.swa.m2m.cep.eventmodel.gprsdisconnect</wlevs:class> 4: </wlevs:event-type> 5: <wlevs:event-type type-name="gprsconnect"> 6: <wlevs:class>de.hshannover.swa.m2m.cep.eventmodel.gprsconnect</wlevs:class> 7: </wlevs:event-type>... 46