Anwendung eines Cyber-Physical Systems für intelligentes ...jleimer/pub/bachelor-thesis.pdf ·...

Fakultät für

Informatik

Verfasser der Bachelorarbeit:

Johannes Leimer

Drosselstraße 6 ½

86343 Königsbrunn

Telefon:+49 8231 31548

[email protected]

Fakultät für Informatik

Telefon: +49 821 5586-3450

Fax: +49 821 5586-3499

Bachelorarbeit

Studienrichtung

Informatik

Johannes Leimer Anwendung eines Cyber-Physical Systems für intelligentes Energiemanagement

Prüfer: Prof. Dr. Thorsten Schöler

Abgabe der Arbeit am: 21.05.2012

© 2012 Johannes Leimer

Diese Arbeit mit dem Titel

»Anwendung eines Cyber-Physical Systems für intelligentes Energiemanagement«

von Johannes Leimer steht unter einer

Creative Commons Namensnennung-Nicht-kommerziell-Weitergabe unter gleichenBedingungen 3.0 Deutschland Lizenz (CC BY-NC-SA).

http://creativecommons.org/licenses/by-nc-sa/3.0/de/

Sämtliche, in der Arbeit beschriebene und auf dem beigelegten Datenträgervorhandene, Ergebnisse dieser Arbeit in Form von Quelltexten, Software undKonzeptentwürfen stehen unter einer GNU General Public License Version 3.

http://www.gnu.de/documents/gpl.de.html

Die LaTeX-Vorlage beruht auf einem Inhalt unterhttp://f.macke.it/MasterarbeitZIP.

http://creativecommons.org/licenses/by-nc-sa/3.0/de/

http://www.gnu.de/documents/gpl.de.html

http://f.macke.it/MasterarbeitZIP

Zusammenfassung

Diese Bachelorarbeit beschäftigt sich mit den aktuellen Problemen der Stromversor-ger und untersucht mögliche Ansätze auf Basis von Cyber-Physical Systems.

Im Zuge der Zusammenfassung des aktuellen Stands der Technik wird dazu näher aufdie Ansätze der Cyber-Physical Systems und der semantischen Modelle eingegangen.Als objekt-funktionale Plattform für Cyber-Physical Systems wird dabei »SMAS«genauer beschrieben, da es im weiteren Verlauf der Arbeit zum Einsatz kommt. Au-ßerdem werden die Schwierigkeiten der verteilten Energie-Erzeugung und die darausresultierende Notwendigkeit mehr Informationen über das Stromnetz zu erfassen,erläutert.

Anschließend werden Anforderungen für eine mögliche Lösung zusammengetragenund daraus eine Architektur mit einem semantischen Modell abgeleitet. Um das kon-zipierte System unter möglichst realen Bedingungen zu testen, wird ein Hardware-Prototyp erstellt. Nach einer exemplarischen Implementierung wird die Anwendungim Hinblick auf die Anforderungen evaluiert.

Als Ergebnis dieser Arbeit werden erste Basis-Komponenten für die Anwendung ei-nes Cyber-Physical Systems für intelligentes Energiemanagement vorhanden sein.

Abstract

This bachelor thesis is concerned with the current problems of electricity distributorsand examines possible approaches on the basis of Cyber-Physical Systems.

Within the framework of the synopsis of the current state of the art, basic approa-ches of Cyber-Physical Systems and semantic models will be discussed. As object-functional platform for Cyber-Physical Systems this thesis will introduce SMASbecause it will be employed in the following course of this work. Furthermore, thetroubles of distributed energy-production and the thereout necessity for gatheringmore information about the power grid will be explained.

Subsequently, requirements for a possible solution will be compiled and an archi-tecture will consequently be derived with the help of a semantic model. To test thedesigned system under near-realistic conditions a hardware prototype will be crea-ted. After an exemplary implementation, the system will be evaluated with regardto the before mentioned requirements.

As a result of this work first base-components for the usage of Cyber-Physical Sys-tems for smart energy management will be available.

Inhaltsverzeichnis

Inhaltsverzeichnis

Abkürzungsverzeichnis IV

Abbildungsverzeichnis V

Tabellenverzeichnis VI

Verzeichnis der Listings VII

1 Einleitung und Umfeld 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Voraussetzungen zum Verständnis der Arbeit . . . . . . . . . . . . . 31.5 Typographische Konventionen . . . . . . . . . . . . . . . . . . . . . . 3

2 Stand der Technik 42.1 Situation der Überwachung von Transformator-Stationen . . . . . . 42.2 Cyber-Physical Systems . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 CPS am Beispiel der Modellstadt Mannheim . . . . . . . . . 82.3 SMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Kryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.5 Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . 132.3.6 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.7 Pluginmanagement . . . . . . . . . . . . . . . . . . . . . . . . 162.3.8 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Semantische Modelle für Sensor-Netzwerke . . . . . . . . . . . . . . . 20

2.5.1 SENSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.2 Sensor Model Language . . . . . . . . . . . . . . . . . . . . . 212.5.3 Building Information Model . . . . . . . . . . . . . . . . . . . 21

I

Inhaltsverzeichnis

3 Aufgabenstellung und Anforderungen 243.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Mögliche Herausforderungen . . . . . . . . . . . . . . . . . . 27

4 Beschreibung der Arbeit 284.1 Konzept und Architektur . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 Semantisches Modell . . . . . . . . . . . . . . . . . . . . . . . 294.1.2 XML-Beschreibung von Modbus-Geräten . . . . . . . . . . . 314.1.3 Aufteilung und Komponenten . . . . . . . . . . . . . . . . . . 324.1.4 Kommunikation zwischen den Nodes . . . . . . . . . . . . . . 34

4.1.4.1 Registrierung von Geräten . . . . . . . . . . . . . . 344.1.4.2 Suche eines Gerätes . . . . . . . . . . . . . . . . . . 354.1.4.3 Daten auslesen . . . . . . . . . . . . . . . . . . . . . 364.1.4.4 Aktionen ausführen . . . . . . . . . . . . . . . . . . 36

4.2 Erstellung eines Hardware-Prototypen . . . . . . . . . . . . . . . . . 374.2.1 Vorhandene Apparaturen . . . . . . . . . . . . . . . . . . . . 374.2.2 Entwurf der Schaltung . . . . . . . . . . . . . . . . . . . . . . 39

4.2.2.1 Design und Planung des Schaltungsaufbaus . . . . . 394.2.2.2 Absicherung gegen hohe Ströme . . . . . . . . . . . 40

4.2.3 Anfertigung des Prototypen . . . . . . . . . . . . . . . . . . . 414.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Arbeitsumgebung und Vorgehen . . . . . . . . . . . . . . . . 434.3.2 Semantisches Modell . . . . . . . . . . . . . . . . . . . . . . . 434.3.3 Modbus Daten-Modell . . . . . . . . . . . . . . . . . . . . . . 444.3.4 Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.5 Semantic Matcher Service . . . . . . . . . . . . . . . . . . . . 454.3.6 Modbus Service . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.7 Registrierung der Modbus-Geräte . . . . . . . . . . . . . . . . 484.3.8 Starten des Systems . . . . . . . . . . . . . . . . . . . . . . . 494.3.9 Testbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Ergebnisse der Arbeit 545.1 Semantisches Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 XML Beschreibung für Modbus-Geräte . . . . . . . . . . . . . . . . . 545.3 Hardware-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

II

Inhaltsverzeichnis

5.5 Evaluierungsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Fazit und kritische Bewertung 576.1 Selbsteinschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Ausblick und weitere Verwendung . . . . . . . . . . . . . . . . . . . . 576.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Literaturverzeichnis 59

Eidesstattliche Erklärung 63

III

Abkürzungsverzeichnis

Abkürzungsverzeichnis

BIM . . . . . . . . . . . . . . . . Building Information ModelCPS . . . . . . . . . . . . . . . . Cyber-Physical SystemIDL . . . . . . . . . . . . . . . . Interface Definition LanguageJVM . . . . . . . . . . . . . . . Java Virtual MachineOPC . . . . . . . . . . . . . . . Object Linking and Embedding for Process ControlP2P . . . . . . . . . . . . . . . . Peer-to-Peer

IV

Abbildungsverzeichnis

Abbildungsverzeichnis

2.1 Anbindung von Leitwarten, Kraftwerken und Transformator-Stationen 52.2 Paradigmen-Wechsel in der Energieversorgung . . . . . . . . . . . . . 62.3 Die Stufe der CPS innerhalb der Evolution eingebetteter Systeme zum

Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Systemmodell der Modellstadt Mannheim . . . . . . . . . . . . . . . 92.5 SMAS Plattformübersicht . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Übersicht der Nodekomponenten . . . . . . . . . . . . . . . . . . . . 152.7 Übersicht des Pluginmanagements . . . . . . . . . . . . . . . . . . . 162.8 Ablauf eines Service Requests . . . . . . . . . . . . . . . . . . . . . . 182.9 Modbus-TCP und RTU Pakete . . . . . . . . . . . . . . . . . . . . . 192.10 Die SENSO Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . 202.11 Mit SensorML repräsentierbare Wetterstation . . . . . . . . . . . . . 222.12 Sensoren-Model im BIM . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Verbindung der semantischen mit der syntaktischen Kompontente inSENSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Semantische Komponente des Modells . . . . . . . . . . . . . . . . . 304.3 Modbus Komponente des Modells . . . . . . . . . . . . . . . . . . . . 304.4 Grobe Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5 Kommunikation zwischen den Nodes . . . . . . . . . . . . . . . . . . 354.6 PULS® MiniLine™ ML30.100 . . . . . . . . . . . . . . . . . . . . . . 384.7 Schneider Electric® PowerLogic™ PM210 . . . . . . . . . . . . . . . 384.8 Schneider Electric® PowerLogic™ EGX100 . . . . . . . . . . . . . . . 384.9 Schneider Electric® Advantys STB™ NIP2212 . . . . . . . . . . . . . 394.10 Schneider Electric® Advantys STB™ PDT3100 . . . . . . . . . . . . 394.11 Schneider Electric® Advantys STB™ DDO3415 . . . . . . . . . . . . 394.12 Verdrahtungs-Plan des Prototyps . . . . . . . . . . . . . . . . . . . . 404.13 Erstellungs-Schritte des Prototyps . . . . . . . . . . . . . . . . . . . 424.14 Aufbau mit Verdrahtung . . . . . . . . . . . . . . . . . . . . . . . . . 424.15 FileNotFoundException beim Start der Anwendung . . . . . . . . . . 504.16 Stromverbrauch einer 450 Watt 5.1 Surround-Anlage . . . . . . . . . 524.17 Fehlverhalten des PowerVisualizerPlugins . . . . . . . . . . . . . . . 53

V

Tabellenverzeichnis

Tabellenverzeichnis

2.1 Bedeutung der Modbus Speicherbereiche . . . . . . . . . . . . . . . . 19

VI

Verzeichnis der Listings

Verzeichnis der Listings

2.1 AddressBookEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 SMAS-Nachricht als Case-Klasse . . . . . . . . . . . . . . . . . . . . 122.3 Zugriffskontext auf Konfigurationen . . . . . . . . . . . . . . . . . . 142.4 Beispielkonfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Plugin Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Registrieren und Abfragen eines Service . . . . . . . . . . . . . . . . 17

4.1 Beispiel XML für Schneider Electric® PowerLogic™ PM210 . . . . . 314.2 Beispiel XML der Ortszuordnung . . . . . . . . . . . . . . . . . . . . 324.3 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 ModbusAnalogSensor . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5 ModbusDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.6 Case-Klassen der Suchanfragen . . . . . . . . . . . . . . . . . . . . . 454.7 Lifecycle-Methoden des Semantic Matcher Plugins . . . . . . . . . . 464.8 Datenstruktur des SemanticMatcherPlugins . . . . . . . . . . . . . . 464.9 Datenstruktur des SemanticMatcherPlugins . . . . . . . . . . . . . . 464.10 Abfrage eines Modbus-Geräts im Zuge eines Data Requests . . . . . 474.11 Registrierung von Modbus-Geräten . . . . . . . . . . . . . . . . . . . 494.12 Befehle für den System-Start . . . . . . . . . . . . . . . . . . . . . . 504.13 SpoofedNode zur Steigerung der Testbarkeit . . . . . . . . . . . . . . 51

VII

1 Einleitung und Umfeld


1.1 Motivation

Das verheerende Reaktor-Unglück in Fukushima am 11.03.2011 stellte mit zwei To-desopfern und hunderttausenden von Zwangsumsiedlungen nicht nur für Japans Ge-sellschaft und Wirtschaft eine Katastrophe dar1, sondern führte weltweit zu einemUmdenken in der Frage der Energiegewinnung. Der auf eine längere Zeitspanne aus-gelegte Energiewandel wurde mit politischem Nachdruck in Deutschland eingefordertund fokusiert dabei die Chancen der erneuerbaren Energien.

Gefördert von staatlichen Subventionen enstanden infolgedessen zahlreiche Klein-Kraftwerke sowohl in privaten Haushalten als auch bei Unternehmen. Die HochschuleAugsburg hat beispielsweise auf den Dächern zweier Gebäude Photovoltaikanlageninstalliert, um einen Beitrag für die Energiewende zu leisten. Die klassische Rolleder Verbraucher »verschwimmt« demnach mit der Rolle des Erzeugers, da diese nunebenfalls Strom in das Netz einspeisen.

Bisher ist das Versorgungsnetz allerdings weitgehend auf die konventionelle Strom-verteilung2 ausgerichtet, welche von einem klaren Erzeuger-Verbraucher-Verhältnisausgeht. Die vielen Kleinsterzeuger setzen dieses Verhältnis außer Kraft und ver-ursachen einen bidirektionalen Stromfluss, welcher die Stabilität des Stromnetzesnegativ beeinflusst. Zurückzuführen ist dieser Umstand auf physikalische Proble-me, wie beispielsweise Strom-Rückflüsse, die eine verteilte Stromerzeugung mit sichbringt3.

Um diese Herausforderung bewältigen zu können, muss das heutige Stromnetz in-telligent auf die Vielzahl von Erzeugern reagieren. Laut [Khan, 2008] können Pro-bleme, wie beispielsweise Spannungs- oder Frequenzschwankungen, gelöst werden,wenn entsprechende Daten vorliegen. Folglich kann ein »intelligentes Stromnetz«auf Basis ausgewerteter Daten Aktionen ableiten, um reibungslosen Betrieb zu ge-währleisten.

1Vgl. [Witte, 2011]2Es wird von einer unidirektionalen Stromrichtung gesprochen3Vgl. [Dondi u. a., 2002]

1


Diese Arbeit soll vor allem die softwaretechnischen Aspekte der Informationsgewin-nung behandeln. Der Ansatz von [Kienzle, 2012] zielt dabei auf die bisher unzugäng-lichen Messdaten aus Transformator-Stationen, welche mit einem Fernzugriff ausge-stattet werden sollen. Diesbezüglich soll das von Rico Lieback entwickelte Multi-Agenten-System als Basis dienen.

1.2 Ziel der Arbeit

Das Ziel dieser Arbeit eine Softwarelösung für die Informationsbeschaffung im Ener-giesektor zu konzipieren, beinhaltet mehrere Aspekte. Für eine leichtere Bearbeitungist daher die Zielformulierung in vier Unterpunkte aufgeteilt.

• SMAS als CPS erweiternSMAS ist derzeit nur eine Kommunikationsplattform und soll sich durch eineErweiterung zu einem Cyber-Physical System (CPS) entwickeln. Dazu sindweitere Module notwendig, die eine Kommunikation, insbesondere zur Steue-rung und Überwachung, von Hardware-Komponenten anbieten.

• Herstellen eines Hardware-PrototypenUm den Hardware-Durchgriff zu demonstrieren und zu testen ist ein Ver-suchsaufbau unverzichtbar. Dabei sollten Standardkomponenten verwendet wer-den, wodurch eine gute Kompatibilität gewährleistet werden kann.

• Anwendung des CPS für die Steuerung des PrototypsMit den entwickelten Modulen für SMAS soll der Hardware-Prototyp betrie-ben werden. Exemplarisch soll der grafisch aufbereitete Energiebedarf einesVerbrauchers mit dem System dargestellt und eine Steuerung des selben er-möglicht werden.

• Strukturierung und Abstraktion von GerätenDa keine vollständige Standardisierung der Schnittstellen von Mess- und Steue-rungsgeräten existiert, folgt jeder Hersteller seinem eigenem Schema. Aus die-sem Grunde ist es sinnvoll eine strukturierte und abstrakte Beschreibung derGeräte zu entwerfen.

1.3 Aufbau der Arbeit

In Kapitel 2 wird die aktuelle Situation der Tansformatorstationen beschrieben undeine kurze Einführung in die Thematik der CPS gegeben. Außerdem ist neben einer

2


Erläuterung der Konzepte von SMAS auch eine Kurzfassung des Modbus Protokollsund ein Überblick der semantischen Modelle für Sensor-Netzwerke enthalten.

Das Kapitel 3 untersucht die Aufgabenstellung und die daraus resultierenden An-forderungen und geht auf mögliche Herausforderungen ein.

Nachfolgend stellt Kapitel 4 das ausgearbeitete Konzept, sowie die Erstellung einesHardware Prototypen vor. Des Weiteren ist die exemplarische Implementierung undeine Evaluation in Form von Leistungstests beschrieben.

Abschließend fassen die Kapitel 5 und 6 die Ergebnisse dieser Arbeit zusammen undgeben ein Fazit einschließlich kritischer Bewertung.

1.4 Voraussetzungen zum Verständnis der Arbeit

Um den Inhalt dieser Arbeit vollständig nachvollziehen zu können sollte der Le-ser bereits über grundlegende Kenntnisse im Bereich der Software-Agenten undSoftware-Architektur verfügen. Darüber hinaus ist ein gewisses Maß an Verständnisfür verteilte Anwendungen und Softwareprogrammierung hilfreich. Ungebräuchliche-re Sprachfunktionen von Scala werden bei Verwendung an geeigneter Stelle erläutert,wobei sich die Syntax von Scala an Java, C# und der ML Sprachfamilie orientiert4.

1.5 Typographische Konventionen

In dieser Arbeit werden für ein besseres Verständnis typographische Konventionenfestgelegt. Fachbegriffe werden kursiv gesetzt. Soll ein Wort eine besondere Betonungerhalten wird dieses fett geschrieben.

Sourcecode kann als einzeiliges Codefragment in Proportionalschrift oder inForm von Listings vorliegen, wobei Klassennamen ebenfalls in Proportional-

schrift gedruckt werden.

Wörtliche Zitate und Metaphern werden in »doppelte Anführungszeichen« gestelltund sonstige Hervorhebungen fettgedruckt.

Abkürzungen werden bei erster Nennung kurz erläutert und können im Abkürzungs-verzeichnis auf Seite nachgeschlagen werden.

4Vgl. [Odersky u. a., 2008]

3

2 Stand der Technik

2 Stand der Technik

Dieses Kapitel soll einen Überblick über den aktuellen Stand der Technik für diein dieser Bachelorarbeit relevaten Themengebiete geben. Der erste Absatz erläutertdie derzeitige Lage und die technische Ausrüstung von Transformator-Stationen inDeutschland. Anschließend wird der aktuelle Forschungsstand der CPS gezeigt undanhand von Beispielen aus dem e-energy Bereich konkretisiert. Die letzten Abschnit-te befassen sich mit dem Modbus-Protokoll und semantischen Modellen.

2.1 Situation der Überwachung vonTransformator-Stationen

In einem Fachgespräch mit Markus Kienzle von der Frey Ingeniuere GmbH, erläu-terte [Kienzle, 2012] die Situation der Leitwarten anhand von Abbildung 2.1. Dieursprüngliche Form ist mit schwarzer Farbe dargestellt und zeigt die anfänglicheAuffassung des Stromnetzes. Man ging davon aus, dass der Strom von Kraftwer-ken (im Bild als »G« dargestellt) produziert und über Umspannwerke (mit »UW«gekennzeichnet) und Transformator-Stationen (als leerers Quadrat dargestellt) zuden Verbrauchen übertragen wird. Es kann also von einer Stromrichtung (in Ab-bildung 2.1 mit schwarzen Pfeilen gekennzeichnet) vom Erzeuger zum Verbrauchergesprochen werden.

Die heutige Situation entspricht allerdings nicht mehr diesem Schema. Es gibt zahl-reiche Photovoltaik-Anlagen, Blockheizkraftwerke und weitere Energiequellen, so-wohl in privaten Haushalten als auch in Unternehmen5. Das hat zur Folge, dass dasklassische und klare Verhältnis zwischen Verbraucher und Erzeuger zunehmend un-deutlicher wird, da die Abnehmer selbst zu Produzenten werden. Diese Entwicklungist auf Abbildung 2.1 mit weiteren »G«s und Pfeilen in roter Farbe gekennzeichnet.

Derzeit kommunizieren die Umspannwerke über das allgemeine Übertragungsproto-koll »IEC 60870-5-104« mit den Leitwarten6. Ob auch Unterverteiler im 20 kV bzw.

5Vgl. [BR, 2012]6Vgl. [Kienzle, 2012]

4

2 Stand der Technik

Abbildung 2.1: Anbindung von Leitwarten, Kraftwerken und Transformator-Stationen [Kienzle, 2012]

5

2 Stand der Technik

Abbildung 2.2: Paradigmen-Wechsel in der Energieversorgung [Kießling, 2009]

10 kV Bereich integriert sind, lies Markus Kienzle allerdings offen. Eine Überwa-chung von Transformator-Stationen findet aktuell nicht statt, wodurch ein Bereichentsteht, zu dem keine Aussagen getroffen werden können.

Beispielsweise ist es schwierig zuverlässige Aussagen über den Zustand des Gesamt-netzes zu treffen, ohne dabei auf die Messdaten aus den Transformator-Stationenzugreifen zu können. Laut [Dondi u. a., 2002] ist in diesem Kontext das Prinzip derKleinsterzeuger besonders problematisch, da sie zur Entstehungzeit des Stromnetzesnicht berücksichtigt wurden (siehe Abbildung 2.2). Dennoch werden immer mehrKleinsterzeuger in das Stromnetz integriert, die in ihrer Dopplerolle als Verbrau-cher und Erzeuger das Netz besonders belasten7. Die ursprüngliche, unidirektionaleFlussrichtung wird dadurch bidirektional, was beispielsweise durch Strom-Rückfluss-Effekte8 erheblichen Schaden an Generatoren verursachen kann9.

2.2 Cyber-Physical Systems

Cyber-Physical Systems sind Systeme, die Computing und physikalische Prozessemiteinander verbinden. Embedded Computer und Netzwerke überwachen und steu-ern diese Prozesse, wobei normalerweise Rückmeldungen der physikalischen Vorgän-ge die Berechnungen beeinflussen und umgekehrt10.

7Vgl. [Pepermans u. a., 2005]8Strom fließt immer von hoher Spannung zu niedrigerer Spannung, was dem normalen Verhältnisvon Generator zu Verbraucher entspricht. Liegt allerdings bei einem Verbraucher eine erhöhteSpannung vor, beispielsweise durch eine Photovoltaik-Anlage, kann das zu einem gegenläufi-gen Stromfluss führen. Dieser Effekt wird Reverse Power Flow (zu Deutsch: Strom-Rückfluss)genannt [Wikipedia, 2012a].

9Vgl. [Pepermans u. a., 2005]10Vgl. [Lee, 2008]

6

2 Stand der Technik

Abbildung 2.3: Die Stufe der CPS innerhalb der Evolution eingebetteter Systemezum Internet der Dinge [Broy u. a., 2012]

In der Regel setzen sich CPS aus mehreren vernetzten Komponenten zusammen, diezum Teil wiederum als CPS bezeichnet werden können. Sie kommunizieren selbst-ständig miteinander und koordinieren sich, um ihre Aufgaben zu erfüllen. Eine sol-che Architektur enspricht dem Prinzip »Teile und Herrsche«, da die Komplexität desSystems in kleinere Einzelprobleme zerlegt wird und so die einzelnen Komponentendetaillierter auf ihren Zuständigkeitsbereich eingehen können11.

CPS sind nach [Broy u. a., 2012] eine Weiterentwicklung von vernetzten eingebet-teten Systemen und die Schlüsseltechnologie für die Umsetzung des »Internets derDinge« (siehe Abbildung 2.3). [Broy u. a., 2012] geht noch weiter und bezeichnet CPSals »enabling technology«, die unzählige innovative Anwendungen ermöglicht.

Aus diesem Grund bestehen sie zumeist aus mobilen und eingebetten Geräten, wieRFIDs, Sensorknoten und Smartphones12. Sie kombinieren computertechnische undphysikalische Aspekte mit einem breiten Spektrum an Kommunikations-Schnitt-stellen. Diese Vernetzung bildet allerdings Abhängigkeiten zwischen den Kompo-nenten und der Umwelt, wodurch das Gesamtsystem durch äußerliche, meist uner-wartete Einflüsse, beeinträchtigt werden kann13.

11Vgl. [Lee, 2008]12Vgl. [Fraunhofer-Gesellschaft, 2012]13Vgl. [Lee, 2008]

7

2 Stand der Technik

Eine der Hauptanforderungen an CPS ist jedoch die Robustheit gegenüber unvor-hersehbaren Veränderungen, sowie eine Anpassung an ausfallende Subsysteme. EinCPS fordert für die Einhaltung der Vorgaben folglich von allen seiner Komponenteneine hohe Verlässlichkeit und ein vorhersagbares Verhalten14.

Zum Beispiel sieht [Lee, 2008] die Möglichkeit mit Hilfe von CPSs verteilte Kleinst-kraftwerke mit dem Stromnetz zu verbinden, spricht aber gleichzeitig die bereits inAbschnitt 2.1 erwähnten Probleme an und fügt ihnen noch Sicherheitsbedenken hin-zu. Diese Vision wurde bereits von Pilotprojekten aus der Wirtschaft aufgegriffen,wovon die Modellstadt Mannheim als Beispiel in Abschnitt 2.2.1 vorgestellt wird.

2.2.1 CPS am Beispiel der Modellstadt Mannheim

Das Projekt »Modellstadt Mannheim«, eines der sechs bundesweit laufenden »E-Energy-Projekte«, wird seit 2008 von einem Konsortium aus Energie-Versorgern,Kommunikations-Anbietern und Instituten durchgeführt. »Im Rahmen von E-Energywird [. . . ] ein repräsentativer Großversuch mit neuen Methoden zur Verbesserung derEnergieeffizienz, der Netzqualität und der Integration erneuerbarer und dezentralerEnergien im städtischen Verteilnetz durchgeführt.«15 Angestrebt ist dabei eine Ver-netzung von spartenübergreifenden Verbrauchskomponenten (Strom, Wärme, Gas,Wasser) mittels einer Breitband-Powerline-Infrastruktur16.

Ein konkretes Ziel des Projekts ist die Entwicklung eines Smart Grids. Es sollenErzeuger, Lasten und Betriebsmittel im Verteilnetz gesteuert werden und damit un-ter anderem die Versorgungssicherheit in dezentralen Netzstrukturen gewährleistetwerden. Auf Basis dieser Infrastruktur wird eine Optimierung der Energieversorungerreicht. Durch die Einbindung der »Prosumer«17 in das Netzwerk, kann der Ver-brauch des Stroms nahe an dessen Erzeugungsort stattfinden. Infolgedessen ist esmöglich hohe Transportverluste zwischen den Teilnehmern zu vermeiden und somitdie Effizienz zu steigern18.

Für die Koordination von Erzeugern, Prosumern und Verbrauchern kommen dieKonzepte der CPS zum Einsatz. Auf Abbildung 2.4 ist neben dem Vernetzungsa-spekt die Aufteilung von Agentenrollen19 dargestellt. Die zentrale Stelle auf seiten

14Vgl. [Lee, 2008]15Vgl. [Kießling, 2012]16Breitband-Powerline bezeichnet die Datenübertragung über ein Niederspannungsnetz (bis

1000 Volt) mit Datenraten bis 50 MBit/s.17Ein Verbraucher (eng. für Consumer), der gleichzeitig Erzeuger (eng. für Producer) ist, wird

»Prosumer« genannt.18Vgl. [Kießling, 2009]19Ein Agent handelt im Namen von Benutzern mit verschiedenen Zielen und Beweggründen [Woold-

ridge, 2009].

8

2 Stand der Technik

Abbildung 2.4: Systemmodell der Modellstadt Mannheim [Kießling, 2009]

9

2 Stand der Technik

des Verbrauchers ist der »Energiebutler«. Er verwaltet und überwacht die haus-interene Einrichtung und versucht, im Sinne des Eigentümers, am Markt (siehe»Marktmoderator«) kostengünstig Ressourcen zu beschaffen20. Dazu kommuniziertder Energiebutler mit anderen Agenten innerhalb einer Netzzelle, wodurch eine ge-wisse Lokalität erreicht wird. Des Weiteren entsteht aus den autonom handelndenAgenten ein intelligentes und kooperatives Kollektiv – die vollständige Ausprägungeines Cyber-Physical Systems.

Als Grundlage für die Implementierung könnte beispielsweise SMAS als objekt-funktionale Plattform für CPS dienen und wird daher im Abschnitt 2.3 näher be-trachtet.

2.3 SMAS

Die Plattform für CPS von Rico Lieback wurde im Wintersemester 2011/2012 imRahmen einer Bachelorarbeit an der Hochschule Augsburg entworfen [Lieback, 2012]und aktuell im Zuge eines Masterprojekts weiterentwickelt. In den folgenden Ab-schnitten werden die für diese Arbeit relevanten Aspekte der Plattform näher be-trachtet und entsprechende Fachbegriffe eingeführt.

2.3.1 Architektur

SMAS orchestriert die Ansätze klassischer Agentensysteme wie Cougaar und JADEzu einem best of und folgt dabei dem »Keep It Small and Simple«-Prinzip. Bei derKonzeption wurde besonderer Wert auf Dezentalität und Erweiterbarkeit gelegt.Beispielsweise ist es möglich, den Unterbau der Kommunikationsschnittstelle ohnegroßen Aufwand durch eine eigene Implementierung zu ersetzen.

Der grundlegende Aufbau der Plattform kann aus Abbildung 2.5 entnommen werdenund setzt sich aus mehreren aufeinander aufbauenden Schichten zusammen. DieKommunikation wird in der aktuellen Version von Akka21 übernommen und miteiner Kommunikations- und Naming-API gekapselt.

Der Node sowie das Pluginmanagement bauen auf diesen Basiskomponenten auf.Jeder Node kann aus mehreren Plugins zusammenstellt werden, welche das Verhaltendes Nodes bestimmen. »Die Plugins realisieren mit Hilfe aller ihnen zur Verfügungstehender Fassaden und Dienste die eigentliche Intelligenz der einzelnen Nodes unddamit des Nutzersystems.« [Lieback, 2012]

20Vgl. [Kießling, 2009]21siehe http://www.akka.io

10

http://www.akka.io

2 Stand der Technik

Abbildung 2.5: SMAS Plattformübersicht [Lieback, 2012]

Ein Zusammenschluss von Nodes und ihren Plugins entsteht durch eine Zugehö-rigkeit zu einem Holon22. Er gruppiert seine Mitglieder zu einem »Ganzen« undrepräsentiert sie gegenüber anderen Holonen, was aus dem Konzept der »CougaarsCommunities« hervorgeht23.

2.3.2 Naming

In der Naming-Komponente ist im Wesentlichen mit dem AddressBookEntry ei-ne systemweit eindeutige Adressierung gekapselt. Jeder Node erhält bei seiner In-stanzierung einen solchen AddressBookEntry, welcher aus einer kryptographischerzeugten Id, dem Hostnamen, auf dem sich der Node befindet, und einem Portbesteht (siehe Listing 2.1). Außerdem ist der Öffentliche Schlüssel für eine abhör-sichere Kommunikation enthalten. Mit diesem Prinzip ermöglicht das SMAS allenNodes direkt untereinander zu kommunizieren, wodurch jegliche Vermittlung überzentrale Instanzen obsolet wird und somit von einer Peer-to-Peer-Kommunikation(P2P) ohne Flaschenhälse profitiert werden kann24.

22Holon (von griech. hólos »ganzes Seiendes«) bedeutet Ganzes, das Teil eines anderen Ganzenist[Koestler, 1976].

23Vgl. [Lieback, 2012]24Vgl. [Lieback, 2012]

11

2 Stand der Technik

Listing 2.1: AddressBookEntry [Lieback, 2012]

1 trait AddressBookEntry extends Serializable

2 {

3 def getId: String

4 def getPort: Int

5 def getHost: String

6 def getPublicKey: PublicKey

7 def isComplete: Boolean

8 def isInternal: Boolean

9 }

2.3.3 Kommunikation

Die Kommunikation des SMAS basiert, wie bereits in Abschnitt 2.3.1 angesprochen,auf dem Framework »Akka« und wird ausschließlich als Kommunikationsabstraktionin Form von P2P verwendet. Für Nutzersysteme ist die Übertragung durch Akkatransparent gekapselt und wird daher nicht näher beschrieben.

Eigene Nachrichten müssen von BaseMessage abgeleitet werden und sollten dieForm einer Standard case-Klasse haben. Der Vorteil, der bereits im Sprachumfangvon Scala enthaltenen Funktion, ist unter Anderem die automatische Generierungvon equals und hashCode, sowie eine Unterstützung über Pattern-Matching25.Ein Beispiel für eine Nachricht kann aus Listing 2.2 entnommen werden.

Listing 2.2: SMAS-Nachricht als Case-Klasse

1 sealed case class MyMessage(payload: Integer) extends BaseMessage

Die Kommunikationsschicht realisiert durch Verwendung der Kryptographiekompo-nente (siehe Abschnitt 2.3.4) eine transparente und sichere Nachrichtenübermitt-lung, deren Aktivierung über eine Konfigurationsoption gesteuert werden kann.

2.3.4 Kryptographie

Die Kryptographiekomponente von SMAS kann beliebige Byte-Streams sowohl si-gnieren, als auch verschlüsseln, was die kryptographischen Prinzipien der Integritätund Authentizität zur Verfügung stellt. Mit dem asynchronen Verschlüsselungsver-fahren RSA wird über den privaten Schlüssel eines Nodes die zusendende Nachricht

25Pattern-Matching ist zwar ähnlich des switch-case Konstrukts aus Java, aber deutlich mäch-tiger. Es können beispielsweise die Variablen einer case-Klasse direkt entnommen und in lokaleVariablen, welche nicht spezifiziert werden müsen, geschrieben werden.

12

2 Stand der Technik

signiert bzw. mit dem öffentlichen Schlüssel des Empfängers chiffriert. [Lieback, 2012]stellt, mit Hilfe dieser Technologie, in späteren Versionen von SMAS einen sicherenDatenspeicher in Aussicht.

Außerdem ist die Generierung von eindeutigen Ids, welche für die Erstellung derAddressBookEntries für einen Node benötigt wird, in dieser Komponente ange-siedelt. Bei der Erzeugung der Identifizierungen kommt die Java-interne Random-Klasse als Eingabefunktion für den SHA-256 zum Einsatz. Der so erzeugte Hash wirdabschließend mit dem Klassennamen des anfordernden Nodes konkateniert und er-gibt so eine eindeutige Kennung26.

Zu beachten ist bei einem asynchronen Verschlüsselungsverfahren der Schlüsselaus-tausch und das Vertrauen in die übertragenen Schlüssel. SMAS greift daher, für einemöglichst einfache Kommunikation, auf den First Trust-Mechanismus zurück, wel-cher keine zentrale Zertifizierungs- und Validierungsstelle benötigt. Es wird »beimersten Kontakt mit einem Kommunikationspartner Vertrauen zu ihm und seinemSchlüssel aufgebaut«27. Sollte bei einem späteren Kontakt ein abweichender Schlüs-sel verwendet werden, ist diese Nachricht im Sinne von First Trust nicht valide undwird verworfen.

2.3.5 Konfigurationsmanagement

Der ConfigurationManager ist die zentrale Einheit des Konfigurationsmanage-ment und orientiert sich am Property-System von Java. Für einen schnellen Zugriffist er daher mit dem Singleton Pattern28 implementiert und ermöglicht es auch vonaußerhalb der SMAS-Klassen auf Konfigurationen zuzugreifen.

Die Konfigurationsdateien sind per Konvention unter dem ./config Verzeichnisangesiedelt und werden bei dem ersten Zugriff auf den ConfigurationManager

geladen. Bei diesem Vorgang werden alle Dateien in allen Unterverzeichnissen mit derEndung .cfg geparst und dem globalen Konfigurationsverzeichnis hinzugefügt.

Der Zugriff auf Einstellungen erfolgt über die Methode getConfig(String) in-nerhalb des ConfigurationManagers. Zu beachten ist in der Kontext bei demAufruf der Methode. Innerhalb eines Plugins enthält String-Übergabeparameternicht, wie bei Java-Properties üblich, den vollqualifizierten Klassennamen und denEinstellungsnamen, sondern ausschließlich Letzteren. Dieses Verhalten ist auf eine

26Vgl. [Lieback, 2012]27Vgl. [Lieback, 2012]28Das Singleton Pattern fordert eine einzelne Instanz einer Klasse, welche bei weiteren Instan-

zierungsversuchen zurückgegeben wird. Damit wird die Leistung erhöht, da kein zustätzlicherSpeicher allokiert werden muss, und ermöglicht die Verwendung des gleichen Objekts in dergesamten Anwendung.

13

2 Stand der Technik

Wrapper-Methode29 in der SmasPlugin-Klasse zurückzuführen, welche den vollenNamen der Plugin-Klasse voranstellt. Außerhalb der Plugin-Umgebung ist die De-finition von Konfigurationsnamen keinerlei nennenswerten Beschränkungen unter-worfen.

Listing 2.3: Zugriffskontext auf Konfigurationen

1 package de.hsaugsburg.smas.plugin

2 class TestPlugin extends SmasPlugin {

3 val pluginConfig = getConfig("testConfig") // => "plugin"

4 val plainConfig = ConfigurationManager().getProperty("testConfig")

// => "plain"

5 }

Listing 2.4: Beispielkonfigurationen

1 de.hsaugsburg.smas.plugin.testConfig = plugin

2 testConfig = plain

Eine Verdeutlichung dieses Verhaltens ist in Listing 2.3 zu finden. Es werden die ver-schiedenen Kontexte des Zugriffs auf die Methoden des ConfigurationManagergenutzt, um auf die in Listing 2.4 definierten Konfigurationsoptionen zuzugreifen.

2.3.6 Node

Ein Node ist ein Container, der Zugriff auf alle wichtigen Systemfunktionen be-reitstellt und verantwortlich für die indirekt Abwicklung des Lifecycle aller seinerPlugins. Er kapselt unter anderem die grundlegenden Schnittstellen, wie beispiels-weise die Kommunikation oder das Holonmanagement.

Er besitzt einen eigenen Lebenszyklus, der indirekt auch auf die enthaltenen Plug-ins angewandt wird. Derzeit beinhaltet der Lebenszyklus eines Nodes nur die zweiZustände »gestartet« und »gestoppt«, jedoch ist eine Erweiterung in naher Zukunftgeplant30.

Seine Hauptaufgabe, neben dem Vermitteln zwischen den einzelnen Komponen-ten, ist das Empfangen, Validieren und Zustellen von Nachrichten. Dazu bedienter sich unter anderem der Kryptographiekomponente (siehe Abschnitt 2.3.4) und

29Eine Wrapper-Methode umgibt seine zugrundeliegende Methode und stellt meistens eine, aufeinen Anwendungsfall angepasste, Vereinfachung bereit. In der Regel resultiert diese Maßnah-me in einzeiligen Methoden, die notwendige Parameter manipulieren, aus bestehenden Datenableiten, oder Standard-Werte übergeben.

30Vgl. [Lieback, 2012]

14

2 Stand der Technik

Abbildung 2.6: Übersicht der Nodekomponenten [Lieback, 2012]

15

2 Stand der Technik

Abbildung 2.7: Übersicht des Pluginmanagements [Lieback, 2012]

des PluginManagers (siehe Abschnitt 2.3.7. Außerdem versendet er die Nachrich-ten, welche von Plugins in Auftrag gegeben wurden.

2.3.7 Pluginmanagement

Wie bereits in Abschnitt 2.3.6 angesprochen verwaltet ein Node seine Plugins mitHilfe des PluginManagers (siehe Abbildung 2.7). Normalerweise werden die in-stallierten Plugins bereits beim Start einer Node in Form einer XML-Datei festge-legt und ebenfalls gestartet. Es ist aufgrund der thread-sicheren Implementierungmöglich auch während des laufenden Betriebs Plugins zu registrieren oder zu de-registrieren31. Dies ermöglicht beispielsweise die Umsetzung von reaktiven Agentenauf Basis der Subsumption-Architektur32.

Empfängt ein Node eine Nachricht, reicht er sie nach erfolgreicher Verifikation, anden PluginManager weiter, welcher sie den Plugins zustellt. Dabei wird nachPlugins gesucht, die auf Basis einer Namenskonvention, eine passende Methode be-reitstellen. Soll ein Plugin beispielsweise die Nachricht Hello behandeln, muss eineöffentliche Methode namens handleHello(msg: Hello) bereitgestellt werden,wobei mehrere Plugins dieselbe Nachricht bearbeiten können. Die so ermitteltenPlugin-Methoden werden von dem Node anschließend über einen Thread-Pool33 par-allel ausgeführt34.

Außerdem steht eine Option innerhalb eines AddressBookEntries für node-interne Kommunikation zur Verfügung. Es kann über einen PluginRequest ein,nur für diesen Node eindeutiger, AddressBookEntry abgerufen werden (siehe Lis-ting 2.5). Der Austausch untereinander, erfolgt transparent, zu dem bereits bekann-ten Verfahren. Im Node wird eine interne Nachricht lediglich innerhalb der eigenen

31Vgl. [Lieback, 2012]32Vgl. [Schöler, 2011]33Ein Thread-Pool ist eine Sammlung mehrerer Threads, die Aufgaben nebenläufig abarbeiten.34Vgl. [Lieback, 2012]

16

2 Stand der Technik

Plugins übermittelt und ist somit für Außenstehende nicht sichtbar. »Mit der Mög-lichkeit der internen Kommunikation lassen sich beispielsweise alle Funktionalitäteneines Blackboard-Agenten über ein entsprechendes Plugin umsetzten [. . . ]«35.

Listing 2.5: Plugin Request [Lieback, 2012]

1 val pingPlugin = node ? ("PingPlugin", RequestType.PluginRequest)

2.3.8 Dienste

Dienste sind ein oder mehrere Plugins, die zusammen eine Funktionalität bereit-stellen. Dieser wird über eine RegisterService Nachricht an den zuständigenHolonManager (siehe Listing 2.6 Zeile 1) publiziert und ist damit öffentlich ein-sehbar. Eine Abfrage ist dagegen wie in Zeile 2 zu implementieren.

Listing 2.6: Registrieren und Abfragen eines Service [Lieback, 2012]

1 node ! RegisterService("PongService", me, manager)

2 val pongService = node ? ("PongService", RequestType.ServiceRequest)

Die Nachrichten werden wie bereits erwähnt an den eigenen HolonManager über-mittelt und von diesem bearbeitet. Dienst-Registrierungen werden in einem lokalenVerzeichnis gespeichert und nicht weiter verarbeitet. Dienst-Anfragen hingegen wer-den, wenn sie nicht mit Hilfe des eigenen Verzeichnisses beantwortet werden können,an alle gekannten HolonManager weitergeleitet. Durch die Rückmeldungen der an-deren Holone kann ein HolonManager sowohl das eigene Verzeichnis ergänzen, alsauch zukünftige Anfragen nach dem gesuchten Dienst direkt abhandeln (siehe Ab-bildung 2.8. Ist die Anfrage allerdings zu keinem Ergebnis gekommen, wird nachAblauf eines Timeouts eine leere zurückgegeben. Dieses Vorgehen fördert, nebeneiner niedrigen Netzwerklast, die Dezentralität von Diensten36.

2.3.9 Zusammenfassung

Zusammenfassend lässt sich sagen, dass SMAS aufgrund seiner dezentralen Architek-tur eine solide und erweiterbare Basis für die Entwicklung eines CPSs ist. Außerdemkann über seine Kryptographie-Komponente (siehe Abschnitt 2.3.4) eine transpa-rente und kryptographisch gesicherte Kommunikation aktiviert werden. Überdiesist mit der Nutzung von Scala, nicht nur eine JVM-Kompatibilität, sondern auch

35[Lieback, 2012] [sic]36Vgl. [Lieback, 2012]

17

2 Stand der Technik

Abbildung 2.8: Ablauf eines Service Requests [Lieback, 2012]

eine einfache Implementierung von Nutzersystemen gegeben. Des Weiteren ist esdurch das Convention over Configuration-Konzept möglich, ohne aufwendige Kon-figurationen und Einarbeitung, eine lauffähige Anwendung zu erstellen.

Zu beachten ist das Fehlen einer Unterstützung von wissensbasierter Verarbeitung.Es ist derzeit nicht möglich beispielsweise mit Hilfe von Ontologien und ReasonernWissen abzuleiten.

Auch ein kostengünstiger Einsatz in kommerziellen Produkten ist nicht ausgeschlos-sen, da SMAS als Open-Source-Software unter der GPLv3 Lizenz weiterentwickeltwird. Zu beachten ist allerdings die Pflicht der Rückführung von Modifikationen indas Projekt.

2.4 Modbus

Im Allgemeinen ist Modbus ein Protokoll auf der Ebene der Anwendungsschicht (imSinne des ISO/OSI Schichtenmodells) für die Kommunikation zwischen Geräten imBereich der industriellen Netzwerke. Es ist zustandslos und basiert auf Transaktio-nen, welche aus einer Anfrage des Masters und einer Antwort des Slaves bestehen.Im herkömmlichen Client-Server-Schema ist der Master der Client, und der Slaveder Server. Zudem ist Modbus ein offenes und freie lizensiertes Protokoll, wodurchder kostenlose Einsatz selbst in kommerziellen Produkten gestattet ist.

18

2 Stand der Technik

Abbildung 2.9: Modbus-TCP und RTU Pakete [Simply Modbus, 2012]

Tabelle 2.1: Bedeutung der Modbus Speicherbereiche [Modbus IDA, 2006]

Bereich Datentyp Lese-/Schreibrechte FunktionscodeDigitaler Eingang Einzelnes Bit Nur Lesen 02Digitaler Ausgang Einzelnes Bit Lesen und Schreiben 01Analoger Eingang 16-Bit Wort Nur Lesen 04Analoger Ausgang 16-Bit Wort Lesen und Schreiben 06

Bei der Übertragung von Modbuspaketen werden drei verschiedene Betriebsartenunterschieden, deren Einsatz abhängig vom verwendeten Übertragunsmedium ist:Modbus ASCII,Modbus RTU undModbus TCP. Im ASCII Modus wird für Menschenlesbarer ASCII-Code übertragen, ist dadurch aber langsamer als RTU, bei dem dieDaten in binärer Form gesendet werden. Sowohl ASCII als auch RTU sind über dieseriellen Schnittstelle EIA-232 und EIA-485 zu betreiben.

Modbus TCP hingegen ist ein Ethernet-Protokoll und kapselt eine Modbus RTU-Paket in ein TCP/IP Frame (siehe Abbildung 2.9. Im Jahre 2007 erfolge eine welt-weite Normierung im Zuge der IEC 61158 Norm und ist als echtzeitfähiger Ethernet-Feldbus in der Norm IEC 61784-2 aufgeführt37.

Die Modbus Spezifikation unterscheidet zwischen digitalen und analogen Ein- undAusgängen und teilt damit den interenen Speicher eines Geräts in vier Bereicheauf. Jeder Speicherblock ist wiederum in sogenannte Register unterteilt, die einzelneDaten abgrenzen. Infolgedessen existiert für jeden Bereich ein Funktionscode (sie-he Tabelle 2.1), der in einer Anfrage zusätzlich zur Adressnummer des jeweiligenRegisters übertragen wird.

Für den Abruf des Zustands eines digitalen Eingangs, der von Register Nummer1337 repräsentiert wird, ist eine Nachricht mit Funktions-Code 02 zu schicken. DerSlave liest anschließend den entsprechenden Speicher-Inhalt und sendet ihn an denMaster. Darüber hinaus ist es durch weiterführende Funktions-Codes möglich ineiner Anfrage große Mengen zusammenhängender Register auf einmal auszulesen.

37Vgl. [Wikipedia, 2012b]

19

2 Stand der Technik

Abbildung 2.10: Die SENSO Ontologien [Ryashentseva, 2010]

Das Modbus-Protokoll ist damit von Hardware-Komponenten einfach umzusetzenund erreicht eine Protokoll-Effizienz von 60 %38.

2.5 Semantische Modelle für Sensor-Netzwerke

»[. . . ] effective orchestration of software and physical processes requiressemantic models that reflect properties of interest in both.« [Lee, 2008]

Ein Cyber-Physical Systems benötigt Informationen über seine Umwelt und dieMöglichkeit sie zu beeinflussen (siehe Abschnitt 2.2). Infolgedessen werden im Zu-sammenhang mit Cyber-Physical Systems oft auch semantische Modelle und Sensor-Netzwerke thematisiert. Eine semantische Auszeichnung von Sensoren und Aktorenwurde bereits von mehreren Projekten untersucht. Daraus entstanden unter anderemSENSO und SensorML, die in den folgenden Abschnitten betrachtet werden. Nebenden beiden semantischen Modellen wird auch das Gebäude-Informations-Modell von[Weiss, 2011] beschrieben.

2.5.1 SENSO

Die SENSO Middleware ist von [Ryashentseva, 2010] entwickelt worden und basiertauf einer dreiteiligen Ontologie und bietet weitaus mehr als nur ein semantischesModell für Sensoren. Sie abstrahiert den gesamten Prozess der Suche und ermög-licht den Zugriff auf Messwerte, wobei keinerlei domänenspezifische Abhängigkeitenentstehen.

Eine semantische Ordnung entsteht, wie in Abbildung 2.10 dargestellt, durch dasZusammenspiel dreier Ontologien. Während die »Device«-Ontologie unter ande-rem Informationen über Geräte-Hersteller, Modell oder Position enthält, ist die

38Vgl. [HMS Industrial Networks GmbH, 2012]

20

2 Stand der Technik

»Service«-Ontologie für eine Abstrahierung der Geräte zu Diensten zuständig. In der»Parameter«-Ontologie sind abschließend noch die Ein- und Ausgaben der Dienstespezifiziert.

Interessant ist der Ansatz, die exakte Spezifikation von Geräten in eine semanti-schen und syntaktischen Teil zu zerlegen. Die Zuordnung findet über einen Identifierin der Device-Ontologie statt und entlastet so das Modell, da weiterführende Infor-mationen nicht gespeichert werden müssen. Auf der syntaktischen Seite wird mitdem gleichen Identifier der Hardware-Zugriff in Interface Definition Language (IDL)beschrieben39.

Ein entscheidender Nachteil ist allerdings die fehlende Verfügbarkeit einer detaillier-ten Dokumentation, womit eine Integration in diese Arbeit nur auf konzeptionellerEbene erfolgen kann.

2.5.2 Sensor Model Language

SensorML wurde von [Botts u. Robin, 2007] entworfen und besteht aus einem XML-Schema für die Beschreibung von Sensoren und Messungsprozessen. Dabei geht Sen-sorML mitunter auf Problemstellungen der Sensor-Suche, Temporal-Bedingungenund autonomer Sensor Netzwerke ein und stellt Lösungsmöglichkeiten zur Verfü-gung. Die XML-Beschreibung basiert auf GML, SWE-Common und IC:ISM, welchealle von dem Open Geospatial Consortium entwickelt wurden.

Eine der Kernkomponenten ist die Definition von Sensoren. Sie enthält, wie beiSENSO, ausführliche Metadaten über beispielsweise Position, Ein- und Ausgabe-Parameter und Klassifizierung. Allerdings sind die Informationen deutlich detail-lierter, da unter anderem Abstände relativ zu anderen Sensoren angegeben werdenkönnen. Demzufolge ist die in Abbildung 2.11 gezeigte Wetterstation vollständig mitSensorML modellierbar.

Im Hinblick auf die Evolution hin zum »Internet der Dinge« ist SensorML ande-ren Modellen einen Schritt voraus, denn es folgt dem »Objekt-Assoziation-Objekt«-Konzept des Semantic Web40.

2.5.3 Building Information Model

Das Building Information Model (BIM) von [Weiss, 2011] wurde ursprünglich fürdie Modellierung von Gebäuden und deren Einrichtungen entworfen, bietet sich aber

39Vgl. [Ryashentseva, 2010]40Vgl. [Botts u. Robin, 2007]

21

2 Stand der Technik

Abbildung 2.11: Mit SensorML repräsentierbare Wetterstation [Botts u. Robin,2007]

Abbildung 2.12: Sensoren-Model im BIM [Weiss, 2011]

aufgrund der Positions-Beschreibung und Sensor-Abstraktion ebenfalls als semanti-sches Modell an.

Als grundlegender Unterschied zu SENSO und SensorML ist die Umsetzung alsJava-Klassen-Hierarchie zu erwähnen. [Weiss, 2011] kam zum Schluss, dass keinesder von ihm analysierten BIMs für eine Implementierung in Frage kam.

Besonders herauszustellen sind die Relationen von »Equipment« bzw. »Sensor« zu»Location« (siehe Abbildung 2.12). Die Zuordnung des direkten Standorts erfolgtüber »location«, während die gemessenen Locations über »locationsMeasured« re-ferenziert werden. Dadurch kann beispielsweise ein Temperatur-Messgerät in einerEingangshalle mit Empore modelliert werden. Installiert ist das Gerät an der Hal-lenwand, erfasst allerdings die Temperatur sowohl für den Gang auf der Empore alsauch für den Eingangsbereich.

22

2 Stand der Technik

Der größte Nachteil des BIMs, im Hinblick auf die Aufgabenstellung dieser Arbeit,ist die fehlende Integration einer abstrakten Beschreibung, wie auf Hardwarekom-ponenten zugegriffen werden kann.

23

3 Aufgabenstellung und Anforderungen


Dieses Kapitel beschäftigt sich mit der Aufgabenstellung der Arbeit und erläutert dieAnforderungen, welche aus den verschiedenen Interessensgruppen hervorgehen.

3.1 Aufgabenstellung

Das Ziel dieser Arbeit ist die Realisierung eines Cyber-Physical Systems auf Basisvon SMAS, welches in der Lage ist Daten aus Standard-Hardware von Transformator-Stationen zu erfassen.

Dazu soll eine Anforderungsanalyse durchgeführt werden, welche die Anforderungenaller Stakeholder fixiert und auswertet. Auf Basis der Analyse sind die notwendigenSchritte abzuleiten und eventuelle Risiken zu identifizieren.

Im Anschluss soll mit den gesammelten Anforderungen ein Architektur-Konzepterarbeitet und vorgestellt werden. Ein Prototyp in Form einer beispielhaften Im-plementierung ist als Nachweis der Machbarkeit zu realisieren, wobei der Hardware-Zugriff anhand realer Geräte demonstriert werden soll. Abschließend soll anhand derAnforderungen eine Evaluation des Systems erfolgen.

3.2 Anforderungsanalyse

Für eine vollständige Erfassung möglicher Anforderungen werden zunächst die Sta-keholder und ihre Ziele vorgestellt. Anschließend werden daraus die Anforderungenabgeleitetet und kurz erläutert, sowie potentielle Unwägbarkeiten beschrieben.

3.2.1 Stakeholder

Die Stakeholder sind im Speziellen die folgenden Firmen, Personen und Systeme:

• Frey IngenieureDie »Frey Ingenieure GmbH« mit Hauptsitz in Martinszell ist auf Anlagenbau,Automation und Prozesstechnik spezialisiert und wird durch Markus Kienzlevertreten. Ihr Ziel ist es, die Transformator-Stationen in der »Modellregion

24


Allgäu« mit einem aus der Ferne ablesbaren technischen Lösung auszustatten.Sie soll unter 1.000 Euro kosten und auch in abgelegenen Gebieten einsatzfä-hig sein. Des Weiteren erfordert der Einsatz in den Stationen eine Modbus-Kompatibilität.

• ModbusModbus ist ein Kommunikationsprotokoll für industrielle Anlagen, welches aufeiner Client-Server-Architektur basiert (siehe Abschnitt 2.4). Außerdem ist esein offenes Protokoll, das sich in den vergangenen Jahren zu einem De-Facto-Standard entwickelt hat. Es ermöglicht über einfache Nachrichten Schreibe-und Lesezugriff auf Speicherregister von Mess- und Regelsystemen.

• SMASDie SMAS-Plattform von Rico Lieback ist plugin-basiert und beeinflusst durchseine Architektur die Konzeption in Richtung einer service-orientierten Struk-tur. Die einzelnen Nodes stellen Dienste zur Verfügung und können dem ent-sprechend von Nutzern des Systems gefunden werden. SMAS soll durch dieseArbeit ergänzende Module für den Hardware-Schnittstellen erhalten.

• Hochschule AugsburgIn den kommenden Jahren werden an der Hochschule Augsburg mehrere Pro-jektgruppen an der Automatisierung einer Modell-Fertigungsanlage arbeiten.Die Geräte der Anlage – Förderbänder, Produktionsmaschinen und Hochre-gallager – kommunizieren über Object Linking and Embedding for ProcessControl (OPC) und Profinet.

3.2.2 Anforderungen

Aus der Zusammenführung aller Interessen der oben genannten Stakeholder ergebensich die folgenden Anforderungen:

• DezentralitätDie einzelnen Subsysteme sollen möglichst nah an den zu überwachendenKomponenten angesiedelt werden. Diese Dezentralität erhöht die Ausfallsicher-heit und verringert die Gefahr eines System-Zusammenbruchs, da auf zentraleStrukturen, auch Single-Point-of-Failure41 genannt, verzichtet wird.

• SkalierbarkeitDas System soll eine steigende oder sinkende Anzahl an Teilnehmern bedie-nen können, ohne dabei Leistungseinbußen hinnehmen zu müssen. Außerdem

41Als Single-Point-of-Failure bezeichnet man eine Komponente, deren Ausfall den Verlust der Funk-tionsfähigkeit des gesamten Systems nach sich zieht [Dooley, 2002].

25


soll der Verwaltungsaufwand auch bei großen Anzahlen von Knoten möglichstgering und effizient gehalten werden.

• ModularitätEinzelne Komponenten des Systems sollen austauschbar und deaktivierbarsein, was über eine möglichst lose Kopplung der Komponenten erreicht werdenkann. Dies ermöglicht ein hohes Maß an Erweiterbarkeit und Wartbarkeit, wo-durch das System auch an zukünftige Anforderungen und Problemstellungenangepasst werden kann.

• Modbus-KompatibilitätDa für den reibungslosen Betrieb in Transformator-Stationen eine Modbus-Kompatibilität42 zwingend erforderlich ist, muss das System entsprechendeSchnittstellen einplanen und bereitstellen.

• OPC-Kompatibilität (optional)Ein Einsatz in weiteren Projekten erfordert zusätzlich eine Anbindung anOPC-konforme Server. Da diese Anforderung in der aktuellen Aufgabenstel-lung nicht zwingend erforderlich ist, soll sie zwar während der Planung berück-sichtigt, aber nicht explizit implementiert werden.

• Einfache SchnittstellenDurch schlanke und einfache Kommunikations-Schnittstellen wird die Gesamt-Architektur des Sytems stark vereinfacht und die Einarbeitungs-Zeit verkürzt.Beispielsweise sollten in Nachrichten nur die zwingend erforderlichen Informa-tionen enthalten sein.

• Semantische ZuordnungUm eine schlüssige Zuordnung von Geräten auch für Software realisieren zukönnen, ist ein semantisches Konzept notwendig (siehe Abschnitt 2.5). Es sollein softwarebasiertes Reasoning auf dem System ermöglichen, um so Sensorenund Aktoren effizient ausfindig zu machen.

• Hardware-AbstraktionFür einen protokoll-unabhängigen Zugriff auf Sensoren und Aktoren, sollendiese transparent und ohne spezielles Wissen über die einzelne Hardware selbstbeschrieben werden.

• Einheitliche Beschreibung von GerätenAuf dem Markt befinden sich viele Geräte, die zwar mit Modbus kommuni-zieren können, aber unterschiedliche strukturierte Daten bereitstellen. JedesGerät benötigt eine spezielle Beschreibung, in der spezifiziert werden muss,welche Bedeutung welchem Register zuzuordnen ist. Individuelle Definitionen,

42Vgl. [Kienzle, 2012]

26


wie zum Beispiel Skalierungsregister oder Multi-Wort Werte, sollen unterstütztwerden.

3.2.3 Mögliche Herausforderungen

Im Folgenden soll auf die möglichen Herausforderungen und kritischen Abschnit-te eingegangen werden, die während der Planung, Umsetzung und Evaluation derAnforderungen auftreten können.

• ArchitekturDie Erstellung einer System-Architektur, welche den vielseitigen und komple-xen Anforderungen gerecht wird, ist voraussichtlich relativ aufwendig. Bei-spielsweise die Skalierbarkeit und Modularität sind nicht zu unterschätzendeFaktoren.

• Beschreibung der GeräteAufgrund der Vielfalt der verfügbaren Geräte und deren individuellen Auf-baus kann die Erstellung eines Beschreibungsdokumentes sehr komplex undim schlechtesten Fall im Rahmen der Bachelorarbeit nicht realisierbar sein.

• TestbarkeitDas Testen des Systems kann in zwei Hinsichten stark behindert werden. ZumEinen ist SMAS eine junge Plattform und kann, aufgrund von fehlenden Funk-tionen oder Mocks43, ein isoliertes Testen von Plugins oder das korrekte Sendenvon Nachrichten erschweren. Zum Anderen ist durch die Abhängigkeit des Sys-tems von Hardware-Komponenten ein automatisierter Integrations-Test nureingeschränkt möglich.

• Sematisches KonzeptDie in Abschnitt 2.5 beschriebenen Modelle sind nicht direkt mit den Anfor-derungen an das zu erstellende System vereinbar. Das Gebäude-Informations-Modell von [Weiss, 2011] beinhaltet beispielsweise keine nähere technische Be-schreibung des Hardware-Zugriffs, während SENSO eine Lösung für dieses Pro-blem vorstellt, aufgrund fehlender Details jedoch nicht nicht umsetzbar ist.

43Ein Mock ist eine Attrappe, die als Platzhalter für echte Objekte innerhalb von Tests verwendetwird. Dadurch kann ein Testobjekt weitgehend isoliert werden [Freeman u. a., 2004].

27

4 Beschreibung der Arbeit


Zu Beginn dieses Kapitels wird das grundlegende Konzept und die Architektur des zuerstellenden Systems vorgestellt. Daraufhin befasst sich Abschnitt 4.2 mit der Kon-zeption und Herstellung eines Hardware-Prototypen, gefolgt von der Beschreibungder exemplarischen Implementierung in Abschnitt 4.3. Abschließend wird anhandeiner Steuerung einer Musik-Anlage das erstelle System evaluiert.

4.1 Konzept und Architektur

Wie bereits in Abschnitt 2.3.1 erwähnt, impliziert SMAS durch seine Struktur be-reits eine service-orientierte Architektur. Dieses Paradigma soll auch hier zum Tra-gen kommen, indem alle Komponenten ihre Funktionalitäten in Form von Dienstenbereitstellen.

Die Anforderungen aus Abschnitt 3.2.2 implizieren eine notwendige Unterstützungmehrerer Protokolle, wie beispielsweise Modbus oder OPC. Unter der Annahme,dass für jedes Protokoll nur ein Node existiert oder jeder Node einen gleichwertigenDienst anbieten kann, würde bereits SMAS mit seiner Dienste-Architektur ausrei-chen. Da alle Nodes, die einen »Modbus-Service« (siehe Abschnitt 4.1.3) zur Verfü-gung stellen, die gleiche Funktionalität bieten, kann ein beliebiger Node abgerufenund verwendet werden.

Sobald eine direkte Abhängigkeit des dienstleistenden Node zu einem Gerät entstehtist diese Hypothese allerdings nicht mehr haltbar. Es ist folglich wichtig festzuhalten,auf welche Hardware-Komponente ein bestimmter Dienst einen Zugriff bereitstellenkann.

Aus diesem Grund wird in Abschnitt 4.1.3 der Semantic Matcher Service beschrie-ben, welcher als Registrierungsstelle dienen soll. Er fungiert außerdem als MatchMaker, indem er Clients, die Sensoren suchen, mit den Nodes, welche die gesuchtenSensoren verwalten, zusammenführt. Für die Datenhaltung der registrierten Geräteund deren Eigenschaften bieten sich semantische Modelle (siehe Abschnitt 2.5) an.

Diese Themantiken werden in den nachfolgenden Abschnitten detaillierter erläutertIn den folgenden Abschnitten wird differenzierter auf die jeweils schon oberflächlichangesprochenen Punkte eingegangen.

28


Abbildung 4.1: Verbindung der semantischen mit der syntaktischen Kompontentein SENSO [Ryashentseva, 2010]

4.1.1 Semantisches Modell

Durch ein semantisches Modell kann die Zuordnung von Anfragesteller und passen-den Sensoren bzw. Aktoren, nachfolgend Match-Making genannt, unterstützt wer-den. Der Suchende soll für das Auffinden eines Gerätes möglichst wenig Informatio-nen benötigen, was eine effiziente Kommunikation sicherstellt.

Bei SENSO übernimmt diese Aufgabe ein Reasoner, der mit Hilfe einer Ontologiezur Laufzeit verschiedene Informationen aus dem System ableiten kann44. Aller-dings besitzt SMAS, wie bereits in Abschnitt 2.3.9 erwähnt, noch keine direkteUnterstützung wissensbasierter Verfahren. Als Ersatz kommt deshalb eine semanti-sche Objekthierachie zum Einsatz. Dieser Ausgangspunkt ist zwar nicht so mächtigwie eine Ontologie, bietet jedoch ausreichend Möglichkeiten für ein einfaches Match-Making.

Die Beschreibung der Hardwareadressierung auf einem möglichst abstrakten Niveauist ein weiterer Aspekt des zu erstellenden Modells. [Ryashentseva, 2010] beschreibtdie Trennung der Informationen in eine »semantische Beschreibung« und »syntakti-sche Beschreibung«. Der semantische Teil referenziert dabei jeweils über ein Attributeine individuelle syntaktische Definition in IDL (siehe Abbildung 4.1).

Dieses Konzept kommt auch im erarbeiteten Modell zum Einsatz. Das in Abbil-dung 4.2 dargestellte Objektnetz ist die semantische Beschreibung, während Abbil-dung 4.3 den Zugriff auf Modbus-Komponenten zeigt.44Vgl. [Ryashentseva, 2010]

29


Abbildung 4.2: Semantische Komponente des Modells

Abbildung 4.3: Modbus Komponente des Modells

30


Die Klasse Device ist ein allgemeines Konzept für Aktoren und Sensoren, um einebessere Typsicherheit zu gewährleisten und Relationen wie measures nur einmaldefinieren zu müssen. Die Zuordnung der Geräte zu Positionen ist angelehnt an dasBIM von [Weiss, 2011] (siehe Abschnitt 2.5.3). Diese beiden Relationen wurden inden semantischen Teil des Modells übernommen.

Unterhalb von Device wird zwischen Actor und Sensor unterschieden. Aktorenwerden einem ActorType zugeordnet, während Sensoren eine Unit referenzieren.Die semantische Bedeutung wird dabei über die entsprechende Enumeration reali-siert, welche aber letztlich nur einfache String-Repräsenationen sind.

In der untersten Ebene erfolgt eine weitere Aufteilung in digitale und analoge Geräte.Eine weitere Implementierung kann diese Klassen nutzen um spezifischere Aktorenund Sensoren zu beschreiben.

4.1.2 XML-Beschreibung von Modbus-Geräten

Bevor eine Nutzung innerhalb des Systems möglich ist, müssen die Geräte spezifiziertund eingelesen werden. Solche statischen Daten werden beispielsweise in SensorML(siehe Abschnitt 2.5.2) in XML-Dateien abgelegt. Dadurch ist eine standardisierteStruktur der Geräte-Beschreibung gegeben, welche in weiteren Applikationen wie-derverwendet werden kann. Wie bereits in Abbildung 4.1 zu sehen ist, verwendetauch Ryashentseva [2010] eine syntaktische Beschreibung. Es liegt also nahe, eben-falls eine XML-basierte Spezifikation der Geräte zu verwenden.

Daher wurde ein, sich an Abbildung 4.3 orientierendes, XML-Schema wurde fürModbus-Geräte erstellt, welches statische Register-Spezifikationen umfasst. Syste-mabhängige Informationen wie IP-Adressen oder Standorte wurden ausgelassen, umdie Wiederverwendarkeit zu bewahren. Listing 4.1 zeigt exemplarisch für das PM210(siehe Abschnitt 4.2.1) eine Ausprägung der Geräte-Beschreibung. Dort ist ein zu-sammengesetztes Register aus einem Multiwort-Register und einem Skalierungregis-ter definiert.

Listing 4.1: Beispiel XML für Schneider Electric® PowerLogic™ PM210

1 <?xml version="1.0" encoding="utf-8"?>

2 <specification [...]>

3 <device id="PM210">

4 <capabilities>

5 <capability>

6 <sensor unit="kwh">

7 <multiwordregister>

8 <register nr="3999" msg="4" format="Int" />


31


10 </multiwordregister>

11 <scale powerof="10">


13 </scale>

14 </sensor>

15 </capability>

16 [...]

17 </capabilities>

18 </device>

19 </specification>

Das beschriebene Gerät ist allein mit dieser XML-Beschreibung noch nicht einsatz-fähig. Es fehlen, wie bereits erwähnt, konkrete Daten für den Zugriff und die Stand-ortbeschreibung. Diese Lücken füllt eine weitere XML-Datei. In ihr ist jedes Gerätmit IP-Adresse, Port und Modbus-Slave-Id annotiert. Außerdem können der Instal-lationsort und die gemessenen Orte der Datei entnommen werden. Ein Beispiel istin Listing 4.2 vorgestellt.

Listing 4.2: Beispiel XML der Ortszuordnung

1 <?xml version="1.0" encoding="utf-8"?>

2 <devices>

3 <device id="PM210" host="192.168.0.100" port="502" slaveId="1">

4 <installed>

5 <location type="room" name="M.1.00"/>

6 </installed>

7 <measures>




11 </measures>

12 </device>

13 <device id="DDO3415" host="192.168.0.20" port="502" slaveId="1">

14 ...

15 </device>

16 </devices>

4.1.3 Aufteilung und Komponenten

Die Architektur liegen unter anderem die Forderungen nach Skalierbarkeit und Mo-dularität zu Grunde, da deren nachträgliche Einarbeitung unverhältnismäßig vieleRessourcen benötigen würde. Im Allgemeinen betrachtet teilt sich die Struktur invier grundlegende Komponenten:

32


• Semantic Matcher ServiceDieser Dienst ist für die Bearbeitung von Sensor- und Aktoranfragen verant-wortlich. Im Hintergrund befindet sich das semantische Modell aus 4.1.1, wel-ches die Suche nach Geräten abstrahiert. Außerdem agiert der Service als Re-gistrierungsstelle für neue Sensoren, wodurch eine nachträgliche Integrationvon weiteren Geräten möglich ist.

Denkbar ist zudem die Unterteilung des Dienstes in zwei kleinere Kompo-nenten: die unabhängige Verwaltung des semantischen Modells und die Ver-waltung der Registrierung mit einer Abfragemöglichkeit. Der Service für dasModell kann durch die Trennung weitere Aufgaben übernehmen, die nicht di-rekt mit dem Sensor-Matching zusammenhängen. Bei der Implementierung inAbschnitt 4.3 sind die beiden Teilgebiete zugunsten der Vereinfachung zusam-mengefasst.

• Modbus ServiceDieser Dienst ermöglicht den direkten Zugriff auf Modbus-Hardware durch dieIntegration der Modbus-TCP-Schnittstelle. Intern arbeitet der Service mit ei-ner Modbus-Bibliothek, welche eine Abstraktion des Modbus-TCP-Protokoll-stacks bereitstellt. Infogedessen besteht die Aufgabe des Services nur noch dar-in eine Umsetzung der Anfragen auf die entsprechenden Bibliotheksfunktionendurchzuführen. Dieses Vorgehen schließt jedoch eine eigenständige Implemen-tierung des Modbus-Protokolls nicht aus.

• OPC ServiceDer OPC Service ist analog zum Modbus Service für OPC-Geräte zuständig.Er integriert ebenfalls eine Bibliothek und ist deshalb nur für die Umsetzungder Anfragen auf OPC-Befehle verantwortlich.

• ClientEin Client ist ebenfalls Teil der Architektur. Er stellt Suchanfragen für Ge-räte und sendet über den Modbus Service bzw. OPC Service Befehle an diegefundene Hardware.

In Abbildung 4.4 sind die definierten Nodes und deren Plugins skizziert. Außer-dem ist dort der in Abschnitt 4.2 beschriebene Hardware-Prototyp zu sehen. Dieserist einem Node zugeordnet, der wiederum einen Modbus-Service bereitstellt. Ausrein technischer Sicht ist diese Zuordnung nicht existent, da die Kommunikationmit Modbus-Geräten über das Netzwerk läuft. Es wäre also jedem Teilnehmer imNetzwerk möglich, selbst die Zugriffe durchzuführen. Dies ist aber im Sinne derAufgabentrennung nicht sinnvoll.

33


Abbildung 4.4: Grobe Architektur

Die oben beschriebenen Dienste werden von SMAS-Plugins realisiert. Sie enthaltenjeweils die notwendige Programmlogik, um auf Nachrichten zu reagieren und dieangeforderten Aktionen durchzuführen.

4.1.4 Kommunikation zwischen den Nodes

Die Verständigung der Komponenten ist über asynchrone Nachrichten realisiert underfolgt über sieben verschiedene Nachrichten: Register, Registered, Lookup-Sensor, LookupActor, DeviceInformation, DataRequest, Data, Action-Request und ActionPerformed.

Grundsätzlich basiert die Interaktion auf Anfragen und deren Antworten. Abhängig-keiten zwischen Nachrichten ergeben sich aus den notwendigen Parametern, wodurches nicht möglich ist, eine Nachricht vor dem Erhalt aller benötigen Informationenzu erstellen. Abbildung 4.5 zeigt die normale Reihenfolge der Nachrichten, in derimmer alle relevanten Daten zur Verfügung stehen.

In den folgenden drei Unterabschnitten sind die drei typischen Anwendungsfälleaufgezeigt und beschrieben.

4.1.4.1 Registrierung von Geräten

Die Grundlage für spätere Suchen stellen registrierte Geräte dar. Sie werden von derDeviceRegistration erfasst und sind damit abrufbar. Die relevanten Nachrichten zurBekanntmachung eines Gerätes sind:

34


Abbildung 4.5: Kommunikation zwischen den Nodes

• Register(Device)

Ein Service registeriert ein Gerät, das an einem Standort installiert ist. Außer-dem sind die gemessenen Orte implizit inbegriffen (siehe Relation measures

in Abbildung 4.2). Diese Nachricht wird an die DeviceRegistration gesendetund von ihr verarbeitet.

• Registered(Register)

Wenn ein Gerät erfolgreich in das Modell integriert wurde, bestätigt die Devi-ceRegistration diesen Vorgang. Eine Zuordnung von Anfrage und Bestätigungist durch die enthaltene Original-Nachricht möglich.

4.1.4.2 Suche eines Gerätes

Nachdem die Geräte in das Modell aufgenommen worden sind, können sie gesuchtund gefunden werden. Durch zwei verschiedene Suchanfragen ist bereits eine Vorse-lektion getroffen, indem entweder nach Sensoren oder Aktoren unterschieden wordenist. Dies vereinfacht sowohl die Suche innerhalb des Modells, als auch die Verwen-dung der empfangenen Daten.

• LookupSensor(Unit, Location)

Mit dieser Anfrage wird ein Sensor angefordert, welcher die entsprechende Ein-heit messen kann und den gewünschten Standort erfasst. Beispielsweise erhältman mit der Nachricht LookupSensor(Unit.Ampere, Room(M2.01))

alle Sensoren, die für Raum M2.01 die Stromstärke messen können.

35


• LookupActor(Action, Location)

Analog zu LookupSensor signalisiert diese Nachricht eine Suchanfrage fürAktoren.

• DeviceInformation(Device, AddressBookEntry, Lookup)

Nachdem der Semantic Matcher Service einen Lookup erhält, sucht er in derinternen Objekt-Hierarchie nach einem passenden Gerät. Ist eine Zuordnungmöglich, antwortet der Dienst mit einer DeviceInformation-Nachricht.Hat die Suche mehrere Übereinstimmungen ergeben, wird für jedes Gerät eineeinzelne Antwort verschickt. Wie bei Registered ist für eine leichte Zuord-nung die Ausgangsanfrage enthalten.

4.1.4.3 Daten auslesen

Informationen können sowohl bei Sensoren als auch Aktoren abgefragt werden. Füreine Daten-Anfrage muss diese direkt an den, in DeviceInformation mitgelie-ferten, AdressBookEntry gesendet werden. Die dabei involvierten Nachrichtensind:

• DataRequest(Device)

Der einzige Parameter ist das zu verwendende Gerät, da darin alle benötigtenInformationen für die ausführende Instanz enthalten sind.

• Data(Long, Double, DataRequest)

Als Antwort eines DataRequests erhält die anfragende Stelle ein Datenpaketmit einem Zeitstempel, dem angeforderten Wert und der Originalanfrage.

4.1.4.4 Aktionen ausführen

Mit einem Aktor kann aktiv in die Umwelt eingegriffen werden. Dazu wird, wie beiden Sensoren, ein Befehl an ein zuvor ermitteltes Gerät gesendet:

• ActionRequest(Device, Action)

Neben dem Gerät ist die gewünschte Aktion als Parameter zu übermitteln.Beispielsweise kann mit Action.on ein Aktor für einen Lichtschalter ange-wiesen werden, das Licht einzuschalten.

• ActionPerformed(Long, ActionRequest)

Eine ausgeführte Aktion wird hiermit bestätigt. Der aktuelle Zeitstempel zumAusführungszeitpunkt, die Aktion und die Ursprungsanfrage sind darin ent-halten.

36


4.2 Erstellung eines Hardware-Prototypen

Eines der Hauptziele des Arbeit ist die Herstellung eines Aufbaus für Demonstrati-onszwecke. Dazu wurden von der Firma Frey Ingenieure GmbH die in Abschnitt 4.2.1aufgeführten Geräte zur Verfügung gestellt. Der Bau des Prototypen wurde zuerstgeplant und nach Rücksprache mit Elektromeister Heinrich Leimer in die Tat um-gesetzt.

Während zunächst nur angedacht war Messungen durchzuführen, erschien es imweiteren Projektverlauf sinnvoll eine Steuerungsmöglichkeit hinzuzufügen, sodassder überwachte Stromkreis beeinflusst werden kann.

4.2.1 Vorhandene Apparaturen

Im folgenden Abschnitt werden die vorhandenen Geräte näher vorgestellt und jeweilsmit einer Abbildung veranschaulicht.

• PULS® MiniLine™ ML30.100 (siehe Abbildung 4.6)Die Stromversorgung der weiteren Geräte wird von einem ML30.100 24 VGleichstrom Netzteil übernommen45. Es benötigt 230 V Wechelstrom Versor-gungsspannung und hat eine maximale Leistungsaufnahme von 30 W.

• Schneider Electric® PowerLogic™ PM210 (siehe Abbildung 4.7)Das PM21046 ist ein Drehstrom-Messgerät für große Anlagen, die zwischen100 A und 500 A benötigen, aber bis zu 32767 A messen kann. Aufgrund dieserGrößenordnung kommt es auch in Transformator-Stationen zum Einsatz. Daes deshalb nicht innerhalb klassischer Steuereinheiten zum Einsatz kommt, isteine 230 V Wechselstrom-Versorgung für den Betrieb nötig.

Neben der Fähigkeit den aktuellen Strombedarf in Ampere zu messen, kannbeispielsweise auch die Netzspannung oder der bereits verbrauchte Strom inKilowattstunden ausgelesen werden. Als Kommunikationsprotokoll steht Mod-bus RTU zur Verfügung und wird über eine RS-485 Schnittstelle übertragen.

• Schneider Electric® PowerLogic™ EGX100 (siehe Abbildung 4.8)Eine Umsetzung von Modbus-RTU über RS-485 auf Modbus-TCP über Ether-net übernimmt das EGX10047. Dafür benötigt es lediglich 24 V Gleichstromund eine IP-Adresse. Konfiguriert wird die Protokollbrücke über ein Web-Interface. Dort können unter anderem die Netzwerkeinstellungen, RS-485 Pa-rameter und die Modbus-RTU Gerätenummern vergeben werden.

45Vgl. [PULS, 2012]46Vgl. [Schneider Electric, 2008b]47Vgl. [Schneider Electric, 2009c]

37


• Schneider Electric® Advantys STB™ NIP2212 (siehe Abbildung 4.9)Das NIP2212 kann, wie das EGX100, ebenfalls als Protokollbrücke bezeich-net werden. Allerdings ist es Teil der Advantys STB™ Produkt-Reihe vonSchneider Electric®, die einen modularen Insel-Aufbau bietet, wodurch weite-re Bauteile mühelos angeschlossenen werden können. Intern arbeitet die Inselmit Modbus-RTU und RS-485, wobei nach außen Modbus-TCP über Ethernetverfügbar ist. Die Stromversorgung für das NIP2212 wird durch ein externes24 V Netzteil übernommen, während die zusätzlichen Module von einem indas Gateway integrierten 5 V Gleichstrom-Netzteil versorgt werden.

• Schneider Electric® Advantys STB™ PDT3100 (siehe Abbildung 4.10)In der Advantys STB™ Serie sind für die einzelnen E/A-Module einer Insel se-parate Stromverteiler vorgesehen. Diese Aufgabe übernimmt das PDT3100 füralle nachfolgenden Module bei 24 V Gleichstrom. Dabei ist die Anordnung derPDT-Module bezüglich der anderen Bauteile zu beachten, denn Module, dienicht mit 230 V arbeiten, dürfen nicht in die Versorgungsstrecke eines PDT3100eingebaut werden. In diesem Fall wäre eine andere PDT-Komponente erforder-lich.

• Schneider Electric® Advantys STB™ DDO3415 (siehe Abbildung 4.11)Das digitale Ausgangs-Modul DDO3415 kann die vom PDT3100 erhaltenen24 V auf vier unabhängige Ausgänge schalten, nutzt für sich selbst aber den5 V Inselstrom. Der Status der einzelnen Ports ist über ein Modbus-Registersowohl les- als auch schreibbar. Die genaue Bedeutung der einzelnen Bits unddie weiteren Register sind in 48 zu finden.

Abbildung 4.6: PULS®

MiniLine™ ML30.100[PULS, 2012]

Abbildung 4.7:Schneider Electric®

PowerLogic™ PM210[Schneider Electric,2008a]

Abbildung 4.8:Schneider Electric®

PowerLogic™ EGX100[Schneider Electric,2009c]

48Vgl. [Schneider Electric, 2009b]

38


Abbildung 4.9:Schneider Electric® Ad-vantys STB™ NIP2212[Schneider Electric,2008c]

Abbildung 4.10:Schneider Electric® Ad-vantys STB™ PDT3100[Schneider Electric,2009a]

Abbildung 4.11:Schneider Electric® Ad-vantys STB™ DDO3415Schneider Electric[2009a]

4.2.2 Entwurf der Schaltung

Im folgendem Abschnitten werden die Konzeption und Planung des Hardware-Pr-totypen näher beschrieben. Darin enthalten sind das grundlegende Layout des Auf-baus sowie der letztendliche Verdrahtungsplan. Außerdem ist in Abschnitt 4.2.2.2der Schutz der Geräte vor hohen Strömen erläutert.

4.2.2.1 Design und Planung des Schaltungsaufbaus

Die Konzeption des Hardware-Prototypen hat neben einem platzsparendem Layoutdes Aufbaus die Sicherheit der Bauteile und der Benutzer zum Ziel.

Dazu sollen auf einer, in der Mitte einer Grund-Platte angebrachten, Hutschienedas EGX100 und das ML30.100 angebracht und bündig mit dem PM210 befestigtwerden. Um von oben und unten Drähte an die Geräte anschließen zu können, sollein Kabelkanal in Form eines »U« die Geräte umranden und die Verdrahtungenaufnehmen.

Mit Hilfe eines Klemmenblocks oberhalb des Kabelkanals sollen Null-Leiter, Phaseund Schutz-Leiter zentral verteilt werden können, womit die Voraussetzung für eineneinzelnen Strom-Anschluss für den gesamten Prototypen geschaffen wird.

Ein Anschluss von Verbrauchern soll über eine Schutzkontakt-Steckdose erfolgen,welche in den Messkreis des PM210 eingeschleift ist. Außerdem soll der Stromkreisder Steckdose über ein Relais, welches von einem DDO3415 gesteuert werden soll,

39


Abbildung 4.12: Verdrahtungs-Plan des Prototyps

unterbrochen werden können. Dabei soll die gesamte Insel des DDO3415 ebenfallsauf einer Hutschiene montiert werden.

Um bei der Verwendung des Prototypen einen unbeabsichtigten Kontakt mit span-nungsführenden Komponenten zu vermeiden, soll der RJ-45 Anschluss des EGX100auf eine Netzwerkdose geschaltet werden.

Unter der Berücksichtigung aller Kriterien und den Installations-Handbüchern wur-de ein Verdrahtungs-Plan erstellt (siehe Abbildung 4.12).

4.2.2.2 Absicherung gegen hohe Ströme

Prinzipiell ist das PM210 für große Industrieanlagen konzipiert und wird laut In-stallationsanleitung49 über einen Stromwandler (z. B. 100 A auf 5 A) mit dem zumessenden Stromkreis gekoppelt. Dieser wirkt wie ein Transformator für Spannung,nur setzt er den Strom auf die spezifizierte Größe um. Im Messstromkreis fließen so-mit maximal 5 A, wodurch das Messgerät nicht für höhere Ströme ausgelegt werdenmuss.

49Vgl. [Schneider Electric, 2008a]

40


Innerhalb des Versuchsaufbaus sind Ströme mit 100 A (ca. 23 kW bei 230 V Netz-spannung) bei ∼24 Cent pro kWh50 nicht nur teuer, sondern hochgradig lebensge-fährlich. Bei 230 V Netzspannung sind in der Laborsituation allerdings keine Strömegrößer als 5 A zu erwarten, was einer elektrischen Leistung von 1.150 Watt ent-spräche. Die angeschlossene Nachttischlampe mit einer 60 W Glühbirne ist damitweit unter der möglichen Maximallast. Diese Gegebenheit ermöglicht es auf einenStromwandler zu verzichten, wodurch das PM210 direkt an den Nutzstromkreis an-geschlossen werden kann.

Dadurch ist das Messgerät jedoch nicht mehr vor hohen Einschaltströmen undeventuellen Kurzschlüssen geschützt. Daher muss trotz des niedrigen erwartetenStroms ein Schutz des Messgerätes gegen Beschädigung sichergestellt werden. Da-zu ist vor dem Messgerät ein 5 A Präzisions-Sicherungsautomat von SCHURTER®

eingeschleift.

4.2.3 Anfertigung des Prototypen

Die Zusammenstellung und Befestigung des Prototypen auf einer Trägerplatte verliefin drei Arbeitsschritten:

1. Befestigen der Hutschienen, Kabelkanäle, Aufputzsteckdose und der Aufputz-leerdose für die Netzwerkdose auf der Grundplatte.

2. Fixieren des Klemmenblocks und der Apparaturen auf den Hutschienen mitAbschlussklemmen (siehe Abbildung 4.13a). Das PM210 erhielt einen Metall-rahmen, der von Martin Leimer entworfen und gefertigt wurde, für dessenBefestigung.

3. Verdrahten der Geräte mit Litzen und Einschleifen der Sicherung in den Strom-kreis (siehe Abbildung 4.13b). Die Einzeldrähte der Litzen wurden mit Ade-rendhülsen vor mechanischer Beschädigung durch Klemm-Schrauben geschütztund ermöglichen einen sicheren Anschluss.

Eine Fotographie des fertiggestellten Hardware-Prototyps ist in Abbildung 4.14 zusehen, wobei dort auch die Steuerungsgeräte aufgebaut und angeschlossen sind.

50Vgl. [Mühlenhoff, 2011]

41


(a) Prototyp ohne Verdrahtung (b) Prototyp mit Verdrahtung

Abbildung 4.13: Erstellungs-Schritte des Prototyps

Abbildung 4.14: Prototyp mit Steuerungserweiterung in Betrieb

42


4.3 Implementierung

Im Folgenden wird, neben der Arbeitsumgebung, die exemplarische Implementierungder in Abschnitt 4.1 vorgestellten Architektur erläutert. Zur Veranschlaulichung derErklärung einzelner Komponenten werden Code-Listings verwendet, die für bessereLesbarkeit eine andere Formatierung verwenden, als der tatsächliche Source-Code.

4.3.1 Arbeitsumgebung und Vorgehen

Während der Programmierung richtete sich die Arbeitsweise und die Code-Gestal-tung nach den Prinzipien der SMAS-Entwicklung, wodurch eine gewisse Konsistenzinnerhalb der Entwicklung entstand.

Als Versions-Verwaltung kam Git zum Einsatz und mit Maven wurde die Abhängig-keits-Vewaltung betrieben. Außerdem wurde versucht »Clean Code«51 zu erstellen,was sich in Form von schnell und einfach zu lesendem Code manifestiert. Dadurchist in den meisten Fällen eine zusätzliche Dokumentation nicht mehr notwendig undbeschleunigt damit die Entwicklung erheblich.

Des Weiteren ist genau so viel Programm-Code geschrieben worden, dass die ge-forderten Komponenten ihre Aufgaben erfüllen können. Dieses Prinzip wird auchWalking Skeleton genannt und fördert eine schnelle Entwicklung von Anwendungen,da kaum überflüssiger Code entsteht.

4.3.2 Semantisches Modell

Zunächst wurde das Modell aus Abschnitt 4.1.1 implementiert, indem einfache Klas-sen bzw. Traits52 verwendet wurden.

Da alle Klassen ausschließlich Daten bereitstellen sollen, ist nur an wenigen Stellenzusätzliche Programm-Logik notwendig. In allgemeineren Klassen, die die höchstenHierarchie-Stufen repräsentieren, ist jedoch eine Implementierung von hashCode()und equals(Any) essentiell, um deren Instanzen in Maps verwenden zu können(siehe Listing 4.3).

Außerdem muss die Implementierung des Modells serialisierbar sein, um eine Über-mittlung mit Hilfe von SMAS zu ermöglichen. Infolgedessen sind sowohl Deviceals auch Location von Serializable abgeleitet, während alle anderen Klassendiese Fähigkeit von ihnen erben.

51Vgl. [Martin, 2008]52Ein Trait in Scala verhält sich ähnlich wie abstrakte Klassen in Java, erlaubt jedoch Mehrfach-

vererbung.

43


Listing 4.3: Device1 trait Device extends Serializable {

2 val id = CryptoEngine.generateUniqueName

3 val measures = new ListBuffer[Location]()

4 var installedAt: Location = null

5

6 override def hashCode(): Int = id.hashCode()

7

8 override def equals(obj: Any): Boolean = {

9 obj match {

10 case device: Device => id.equals(device.id)

11 case _ => false

12 }

13 }

14 }

Es wurde bewusst auf die Sichtbarkeits-Modifikatoren verzichtet, um den Source-Code nicht unnötig mit Gettern und Settern zu belasten. Außerdem sind mit List-Buffern initialisierte Variablen als val53 definiert und unterbinden durch diese Vor-belegung das Auftreten einer NullPointerException.

4.3.3 Modbus Daten-Modell

Unterhalb der semantischen Objekt-Hierarchie ist die Domäne der Modbus-Geräteanzusiedeln (siehe Abbildung 4.3 in Abschnitt 4.1.1). Dabei wird eine neue Struk-tur aus ModbusDevice, ModbusCapability und deren Kindklassen erstellt, diean geeigneter Stelle mit dem semantischen Modell verknüpft werden (siehe Lis-ting 4.4.

Listing 4.4: ModbusAnalogSensor1 class ModbusAnalogSensor extends AnalogSensor with ModbusAnalog

Durch die daraus resultierende Eigenständigkeit erfordert die erneute Aufnahmedes Serializable-Traits in die Ableitungshierarchie (siehe Listing 4.5. Wichtigist dabei die Auflösung der bidirektionalen Verbindung zwischen ModbusDevice

und ModbusCapability, da diese während der Serialisierung in einer Endlos-Schleife enden würde. Dazu ist die Variable capabilities mit der Annotation@transient versehen, wordurch sie bei dem Serialisierungs-Prozess nicht weiterbeachtet wird.53val ist das Scala-Äquivalent zu Javas final

44


Listing 4.5: ModbusDevice

1 class ModbusDevice extends Serializable {

2 var deviceModelName = ""

3 var host = ""

4 var port = 0

5 var slaveId = 0

6 @transient var capabilities = Set[ModbusCapability]()

7 }

4.3.4 Nachrichten

Die Nachrichten sind wie von [Lieback, 2012] empfohlen als case-Klassen realisiertund folgen der Spezifikation aus Abschnitt 4.1.4. Für eine korrekte Integration inSMAS muss jede Nachricht von BaseMessage aus dem Paket de.hsaugsburg.smas.communication ableiten. In Listing 4.6 sind zur Veranschaulichung dieNachrichten-Definitionen der Geräte-Suche abgedruckt.

Listing 4.6: Case-Klassen der Suchanfragen

1 sealed class Lookup(val location: Location) extends BaseMessage

2

3 sealed case class LookupSensor(unit: MyUnit.Value, override val

location: Location) extends Lookup(location)

4

5 sealed case class LookupActor(actorType: ActorType.Value, override val

location: Location) extends Lookup(location)

6

7 sealed case class DeviceInformation(device: Device, address:

AddressBookEntry, lookup: Lookup) extends BaseMessage

4.3.5 Semantic Matcher Service

Das SemanticMatcherPlugin ist von SmasPlugin abgeleitet und gliedert sichdamit in das Plugin-System von SMAS ein. Die Lifecycle-Methoden onStart() undonStop() registrieren bzw. deregistrieren sich selbst als »SemanticMatcherService«am HolonManger (siehe Listing 4.7).

45


Listing 4.7: Lifecycle-Methoden des Semantic Matcher Plugins

1 val SERVICE_NAME = "SemanticMatcherService"

2 def onStart: Boolean = {

3 node.getManager ! RegisterService(SERVICE_NAME, node.getAddress)

4 log.info("{} registered", SERVICE_NAME)

5 true

6 }

7 def onStop: Boolean = {

8 node.getManager ! UnRegisterService(SERVICE_NAME, node.getAddress)

9 log.info("{} unregistered", SERVICE_NAME)

10 true

11 }

Die Hauptaufgabe des Plugins ist die Verwaltung des semantische Modells ausAbschnitt 4.1.1. Dazu speichert er bei dem Empfang von RegisterDevice inSchlüssel-Werte-Paaren ab. Dieses Vorgehen ist bereits aus NoSQL-Datenbankenbekannt und resultiert in einer hohen Geschwindigkeit, da sich die Datenstrukturbereits an den Abfragen orientiert. Die dafür genutzten Tabellen sind Listing 4.8 zuentnehmen.

Listing 4.8: Datenstruktur des SemanticMatcherPlugins1 val unitToSensors = new HashMap[MyUnit.Value, ListBuffer[Sensor]]()

2 val actorTypeToActors = new HashMap[ActorType.Value, ListBuffer[Actor

]]()

3 val locationToDevices = new HashMap[Location, ListBuffer[Device]]()

4 val deviceToAddress = new HashMap[Device, AddressBookEntry]()

Empfängt das SemanticMatcherPlugin zum Beispiel eine LookupSensor-Nach-richt, ist nur die Schnittmenge aus zwei Listen zu bilden, die aus der bereits vorge-stellten Daten-Struktur entnommen werden können (siehe Listing 4.9). Anschließendwerden die darin enthaltenen Sensoren über DeviceInformation-Nachrichten anden Client übermittelt.

Listing 4.9: Datenstruktur des SemanticMatcherPlugins1 def handleLookupSensor(msg: LookupSensor) {

2 val devicesForLocation = locationToDevices.getOrElse(msg.location,

new ListBuffer[Device]())

3 val sensorsMeasuringThisUnit = unitToSensors.getOrElse(msg.unit, new

ListBuffer[Sensor])

4 devicesForLocation.intersect(sensorsMeasuringThisUnit).foreach( {

5 sensor => sendDeviceInformation(sensor, msg)

6 })

7 }

46


4.3.6 Modbus Service

Dieses Plugin ist bezüglich der SMAS-Integration ähnlich dem SemanticMatcher

Plugin. Über die Lifecycle-Callbacks wird der »ModbusService« publiziert bzw.entfernt.

Die weitere Implementierung stützt sich bei der Ausführung von Modbus-Anfragenauf das jamod-Framework54. Die Integration ist sehr rudimentär gehalten, da vieleFunktionen der Bibliothek für die geplanten Zwecke nicht sinnvoll nutzbar wären.

Das ModbusPlugin ist zudem zustandslos, was besonders bei einem hohen Nach-richten-Aufkommen zum Tragen kommt. Diese Thread-Sicherheit wird durch dieNachrichten-Struktur aus den Abschnitten 4.1.4.3 und 4.1.4.4 ermöglicht, da sämt-liche Informationen zur Ausführung der Anfrage in der Nachricht enthalten sind.

Ein Beispiel für die Behandlung eines DataRequests für einen analogen Sensor istin Listing 4.10 zu sehen. Über Pattern-Matching wird device auf ModbusAnaloggecastet, um so eine Typsicherheit zu erreichen.

Anschließend wird eine TCP-Verbindung aufgebaut und das entsprechende Registerüber die Methode readRegister(Register, Int, TCPMasterConnection)

ausgelesen.

Falls ein Skalierungs-Register eingetragen ist, wird dieses ebenfalls abgefragt undentsprechend der spezifizierten Berechnungsvorschrift berücksichtigt. Abschließendwird die TCP-Verbindung getrennt und eine Data-Nachricht an den Client gesen-det.

Listing 4.10: Abfrage eines Modbus-Geräts im Zuge eines Data Requests

1 def handleDataRequest(msg: DataRequest) {

2 msg.device match {

3 [...]

4 case sensor: ModbusAnalogSensor =>

5 log.debug("data requested from {} @ {}", sensor.device.

deviceModelName, sensor.installedAt.name)

6 val connection = getEstablishedConnectionToDevice(sensor.device)

7 var value = readRegister(sensor.register, sensor.device.slaveId,

connection).toDouble

8

9 if (sensor.scale != null) {

10 val scale = readRegister(sensor.scale.register, sensor.device.

slaveId, connection)

11 value = value * (math.pow(sensor.scale.powerOf, scale))

12 }

54siehe http://jamod.sourceforge.net/

47

http://jamod.sourceforge.net/


13 connection.close()

14 msg.sender ! Data(System.currentTimeMillis(), value, msg)

15 }

16 }

17

18 def getEstablishedConnectionToDevice(device: ModbusDevice):

TCPMasterConnection = {

19 val address = InetAddress.getByName(device.host)

20 val con = new TCPMasterConnection(address)

21 con.setPort(device.port)

22 con.connect()

23 con

24 }

25

26 def readSingleRegister(register: SingleRegister, slaveId: Int,

connection: TCPMasterConnection): Short = {

27 val request = getReadRequestForMessageId(register.functionCode,

register.nr)

28 request.setUnitID(slaveId)

29

30 val trans = new ModbusTCPTransaction(connection)

31 trans.setRequest(request)

32 trans.execute()

33

34 val result = getInputRegisterOfResponse(trans.getResponse)

35 result.getValue.toShort

36 }

4.3.7 Registrierung der Modbus-Geräte

Da das ModbusPlugin keine weiteren Informationen benötigt, kann die Regis-trierung in einem eigenständigen Plugin erfolgen. Diese Aufgabe übernimmt dasModbusDeviceInitializerPlugin. Vollständig autark ist es dennoch nicht,denn aufgrund der Zuordnung eines Device zu einem AddressBookEntry imSemanticMatcherPlugin muss derselbe Node ebenfalls ein ModbusPlugin ent-halten.

Die vollständige Registrierung von Geräten ist dabei in drei Arbeitsschritte aufge-teilt (siehe Listing 4.11). Zunächst werden alle Geräte-Spezifikationen (siehe Lis-ting 4.1 in Abschnitt 4.1.2) im Verzeichnis /config/modbus/devices/ über denSpecificationReader eingelesen. Der Pfad ist einstellbar, muss aber nicht ex-plizit konfiguriert werden.

48


Listing 4.11: Registrierung von Modbus-Geräten

1 val matcherServices = node ?? RequestForService("

SemanticMatcherService")

2

3 val specs = SpecificationReader.readSpecs()

4 val semanticDevices = LocationLinker.linkToLocations(

deviceLocationFile, specs)

5

6 semanticDevices.foreach(device =>

7 {

8 log.info("registering {} @ {}", device.id, device.installedAt.name)

9 matcherServices.head ! RegisterDevice(device)

10 })

Anschließend werden mit Hilfe des Location-Linkers die standortbezogenen Meta-Informationen (siehe Listing 4.2 in Abschnitt 4.1.2) ergänzt und dadurch die Para-meter der Device-Instanzen vervollständigt.

Im letzten Schritt werden alle eingelesenen Modbus-Geräte in einer Schleife an einemzuvor abgerufenen SemanticMatcherService registriert. Damit ist die Aufgabedes Plugins abgeschlossen, denn die Antwort des Dienstes (Registered) wird der-zeit nicht verarbeitet.

4.3.8 Starten des Systems

Mit Scala stehen aufgrund seiner Byte-Code-Kompatibilität mit der Java VirtualMachine (JVM) alle von Java unterstützten Betriebssysteme zur Verfügung55, womitdie in Abschnitt 3.2.2 geforderte Plattform-Unabhängigkeit gegeben ist.

Folglich ist eine Ausführung der Anwendung grundsätzlich über den Befehl java-jar <datei> möglich, endet aber aufgrund eines Fehlers innerhalb von SMAS ineiner FileNotFoundException (siehe Abbildung 4.15. Dieses Problem ist durchdas Entpacken des Archivs möglich zu umgehen.

Die Reihenfolge der einzelnen Befehle, um das System zu starten, kann Listing 4.12entnommen werden. Es werden zwei Nodes mit den entsprechenden Diensten gestar-tet, wobei nach einer Pause von zwei Sekunden das ModbusDeviceInitializerPlugin beginnt die Modbus-Geräte zu registrieren.

55Vgl. [Odersky u. a., 2008]

49


Abbildung 4.15: FileNotFoundException beim Start der Anwendung

Listing 4.12: Befehle für den System-Start

1 $> unzip smas-physical-1.0-jar-with-dependencies.jar

2 $> java de.hsaugsburg.smas.launch.Launcher SemanticMatcherService &

3 $> java de.hsaugsburg.smas.launch.Launcher ModbusService &

Hinweis: Für eine funktionsfähige Umgebung müssen die IP-Adressen der Geräteund der Computer in den Konfigurationsdateien angepasst werden.

Im Anschluss können Anwendungen gestartet werden, die auf Basis des Systemsweitere Funktionen bereitstellen. Während der Evaluation (siehe Abschnitt 4.4) wirdbeispielsweise das PowerVisualizerPlugin genutzt, um den Stromverbrauch ineinem Diagramm darzustellen.

4.3.9 Testbarkeit

Das Testen von Komponenten ist ein elementarer Bestandteil der Software-Entwick-lung. Dazu wurden Unit und Integrations-Tests implementiert, um die ordnungsge-mäße Funktion der Anwendung zu verifizieren.

Dieses Vorgehen stellte sich im Verlauf der Programmierung als nicht trivial heraus,da durch die starke Hardware-Abhängigkeit des Systems ein isoliertes Testen derFunktionen nur schwer umzusetzen war. Eine Simulations-Mock hätte das Problemzwar auf der einen Seite lösen können, wäre jedoch bzgl. Aufwand und Komplexitätim Rahmen dieser Arbeit nicht vertretbar gewesen. Stattdessen wurde der Fokus aufIntegrations-Tests gesetzt, die einzelne Funktionen des Systems testen.

Außerdem gibt es in SMAS noch keine Möglichkeit Nachrichten zwischen Plugins undanderen Nodes während Testfällen abzufangen. Um dennoch auf die Kommunikationzugreifen zu können, wurde ein SpoofedNode (siehe Listing 4.13) entwickelt, deralle verschickten Nachrichten in einer Liste speichert.

50


Listing 4.13: SpoofedNode zur Steigerung der Testbarkeit

1 class SpoofedNode extends BlankSmasNode {

2 val messages = ListBuffer[BaseMessage]()

3

4 def getLastMessage: BaseMessage = messages.last

5

6 override def ??(request: Requests): List[AddressBookEntry] = {

7 List(getAddress)

8 }

9

10 override def !(msg: BaseMessage) {

11 msg.sender(getAddress)

12 messages += msg

13 }

14 }

Konkret realisiert ist diese Funktionalität durch das Überschreiben der !- und ??-Methoden mit Dummies. Der SpoofedNode routet damit die gesamte Kommuni-kation über sich selbst und kann in Testfällen als rudimentärer Mock für SMASverwendet werden. Eine direkte Integration dieses Konzepts in SMAS ist in naherZukunft angestrebt.

4.4 Evaluierung

Im Zuge der Evaluation des Systems wurde das PowerVisualizerPlugin ent-wickelt. Es nutzt den SemanticMatcherService für die Geräte-Suche und führt nachErhalt der Metainformationen selbstständig Aktionen durch.

Dazu zählt die grafische Visualisierung des aktuellen Stromverbrauchs mit Hilfe vonJFreeChart56. Um das Diagramm fortlaufend mit neuen Daten zu aktualisieren wirdein java.util.Timer verwendet, der in einem einstellbaren Intervall das PM210(siehe Abschnitt 4.2.1) ausliest. Nach dem Empfang der Informationen werden siein einer MilliDynamicTimeSeriesCollection57 gespeichert, wodurch sich dasDiagramm selbstständig aktualisiert. Notwendig ist die Erweiterung der normalenDynamicTimeSeriesCollection, um mehrere Datensätze pro Sekunde zu re-präsentieren.

Über einen konfigurierbaren Schwellenwert, erfolgt bei Überschreitung ein automa-tisches Abschalten des Stromkreises anhand des DDO3415 (siehe Abschnitt 4.2.1).

56siehe: http://www.jfree.org/jfreechart/57Vgl. [Gherardi, 2011]

51

http://www.jfree.org/jfreechart/


Abbildung 4.16: Stromverbrauch einer 450 Watt 5.1 Surround-Anlage

Der Befehl zum Trennen der Stromversorgung kann aber auch manuell über zweiButtons gegeben werden.

In Abbildung 4.16 ist der Stromverbrauch anhand der Musik-Wiedergabe einer 5.1Surround-Anlage dargestellt. Sobald durch eine höhere Lautstärke der Verbrauchüber den Grenzwert steigt, wird die Anlage fünf Sekunden lang abgeschaltet. An-schließend ist deutlich der höhere Einschaltstrom zu sehen, welcher erneut denSchwellwert übersteigt. Durch ein Anheben des Grenzwertes kann die Musik mithöherer Lautstärke wiedergegeben werden, was im Diagramm als größere Amplitu-de zu erkennen ist.

Gestartet werden kann die Visualisierung durch die Integration in den Launcher

wie bereits in Abschnitt 4.3.8 erläutert. Der Parameter lautet PowerVisualizer.

Während der Entwicklung des PowerVisualizerPlugin wurde auch eine erhöhteAbfrage-Frequenz getestet. Es war nicht möglich 20 Statusabfragen pro Sekunde zuerhalten und gleichzeitig auf Überschreitungen der Schwellwerte zu reagieren (sieheAbbildung 4.17). Die Befehle wurden zwar an das Steuergerät gesendet, jedoch nichtsofort ausgeführt. Aber als das PowerVisualizerPlugin gestoppt wurde, beganndas Gerät zu arbeiten. Bei einer Aufteilung in zwei Nodes für den Modbus-Servicekonnte der Anwendungsfall allerdings korrekt ausgeführt werden, wodurch die Suchenach einem Engpass im ModbusPlugin begonnen werden sollte.

Zusammenfassend kann festegehalten werden, dass das System eine abstraktes Ver-wenden von Sensoren und Aktoren ermöglicht und damit die Anwendung als CPS

52


Abbildung 4.17: Fehlverhalten des PowerVisualizerPlugins

für die Steuerung des Hardware-Prototypen verwendet werden kann. Außerdem istdamit die geforderte Modbus-Kompatibilität gegeben.

53

5 Ergebnisse der Arbeit


In diesem vorletzten Kapitel werden die Ergebnisse der Arbeit zusammengetragenund kurz reflektiert. Darunter fallen die erstellten Artefakt, die Implementierung desSystems und dessen Evaluation.

5.1 Semantisches Modell

Als Erstes ist dabei die Klassen-Hierarchie aus Abschnitt 4.1.1 zu erwähnen. Mit ih-rer Untersützung können Sensoren und Aktoren unabhängig von ihren Schnittstellenund physikalischen Eigenschaften beschrieben und abgerufen werden. Eine abstrakteZugriffsbeschreibung kann innerhalb des Modells durch Ableitung der entsprechen-den Klassen repräsentiert werden, wodurch eine gute Erweiterbarkeit gegeben ist.

Im Laufe der Arbeit entwickelte sich aufgrund der verfügbaren Hardware ein Mo-dell für die Beschreibung von Modbus-Geräten, die als Ergänzung »unterhalb« dessemantischen Netzes angefügt ist.

Außerdem kann das gesamte Modell in binärer Form transportiert werden, da alleKlassen serialiserbar sind. Damit ist ein reibungsloser Austausch zwischen Nodesbzw. Diensten sichergestellt.

5.2 XML Beschreibung für Modbus-Geräte

Um eine Wiederverwendbarkeit von Modbus-Geräte-Beschreibungen zu ermöglichenwurden in Abschnitt 4.1.2 zwei XML-Dateien eingeführt, welche zwischen statischenund platformspezifischen Informationen unterscheiden.

Die Register-Definitionen von Modbus-Geräten unterliegen kaum äußeren Einflüssenund können folglich ohne tiefgreifende Änderungen in weiteren Projekten wiederver-wendet werden. In der zweiten XML-Datei können spezifische Plattform-Informatio-nen angegeben werden, die mittels eines selbst bestimmten Identifiers »verbunden«werden.

54


5.3 Hardware-Prototyp

Ein weiteres Ergebnis dieser Arbeit ist der im Zuge von Abschnitt 4.2 konzipierte undhergestellte Hardware-Prototyp. Er schafft als Versuchsobjekt die Voraussetzungenfür vollständige Integrationstests und bietet Raum für weitere Ergänzungen undIdeen.

Außerdem ist der fest-installierte Teil der Hardware gut für Demonstrations-Zweckeim Hinblick auf Projekt-Präsentationen geeignet. Sollte zukünftig auch die Steuer-ungs-Einheit mit den anderen Komponenten dauerhaft verbunden werden, ist eineÜbertragung des gesamten Aufbaus auf eine größere Platte unausweichlich.

5.4 Implementierung

Während der Implementierung wurde die Dienste-Architektur und das semantischeModell mit dessen XML-Repräsentation für Modbus-Geräte in der Programmier-sprache Scala geschrieben. Es entstand ein einsatzfähgiges System, welches in Ab-schnitt 4.4 im Hinblick auf seine Funktionalitäten evaluiert wurde.

Aufgrund der Tatsache, dass ausschließlich Klassen und Methoden programmiertwurden, welche für die Erfüllung der Anforderungen notwendig sind, ergab sich eineschlanke Codebasis. Des Weiteren wurde durch die Einhaltung der »Clean Code«-Richlinien die Verständlichkeit des Source-Codes gesteigert, sodass eine Einarbei-tung in das System erheblich beschleunigt werden kann.

Mit der Abgleichung der Entwicklungs-Prozesse mit SMAS entstand im Zuge der Im-plementierung ein Maven-Projekt, welches eine Abhängigkeit zu smas-core bein-haltet. Außerdem wurde der gleiche Paket-Namensraum verwendet, um eine spätereWeiterführung als SMAS-Modul zu erleichtern.

5.5 Evaluierungsergebnisse

Aus der Evaluation geht hervor, dass das System weitestgehend den Anforderungenaus Abschnitt 3.2.2 entspricht. Lediglich die Skalierbarkeit konnte nicht zufrieden-stellend überprüft werden, da für eine fundierte Aussage die vorhandenen Hardware-Geräte nicht ausreichten.

Während der Untersuchung wurden unerwartete Effekte registriert, sobald etwa 20Statusabfragen pro Sekunde verschickt wurden. Bei einer Erweiterung des Testfeldesauf zwei ModbusServices verlief alles normal, wodurch die Vermutung nahe liegt,

55


dass das ModbusPlugin der Flaschenhals ist. Für konkrete Maßnahmen muss abereine tiefergehende Analyse des Problems erfolgen.

56

6 Fazit und kritische Bewertung


Zuletzt soll dieses Kapitel neben einem Ausblick und einer Selbsteinschätzung desSystems ein Fazit ziehen und damit die Arbeit abschließen.

6.1 Selbsteinschätzung

Das grobe Ziel dieser Arbeit war, ausgehend von einer hohen Abstraktions-Ebene,einen Hardware-Zugriff auf Messdaten und Schaltkreise zu realisieren. Dieses Zielkann als erreicht angesehen werden, lässt aber noch Raum für Verbesserungen.

Durch die Orientierung an anderen Modellen konnten zwar einige Apsekte in daseigene Konzept übernommen werden, wobei für einen produktiven Einsatz

jedoch für einen produktiven Einsatz noch nicht geeignet. Semantische Bedeutun-gen von Meta-Daten werden wie in vielen anderen Modellen über einen trivialenString-Vergleich abgeleitet. Infolgedessen würde sich bei einer Weiterentwicklung ei-ne Evaluierung von Ontologien anbieten. Für den derzeitigen Anwendungs-Fall istdas Modell allerdings ausreichend komplex und flexibel.

Eigentlich als Nebenprodukt des semantischen Modells entstand, im Zuge der Ausar-beitung des Konzepts, eine Abstraktion von Modbus-Hardware. Aufgrund der hohenKomplexität der verschiedenen Geräte deckt die Objekt-Hierarchie sicherlich nichtalle Anwendungsfälle ab, konnte jedoch das erst später hinzugekommene DDO3415problemlos aufnehmen.

6.2 Ausblick und weitere Verwendung

Eine Anwendung des Modells oder seiner Konzepte ist im Zuge des Master-Projekts»CPS goes Industry« an der Hochschule Augsburg denkbar. Dort wird derzeit aneiner Ontologie für Fertigungsanlagen gearbeitet, bei der die Ergebnisse dieser Arbeitmit einfließen können.

Außerdem kann die Modbus-Abstraktion und die Geräte-Definitionen in einem Pilot-Projekt der Frey Ingenieur Gesellschaft mbH genutzt werden. Dadurch könnten dieMess- und Steuer-Geräte in Transformator-Stationen die Grundlage für einen Smart

57


Grid schaffen. In dieser Hinsicht ist auch SMAS als Kommunikations-Plattform nichtauszuschließen.

Des Weiteren beinhaltet der Hardware-Prototyp aktuell weder einen analogen Aktornoch einen digitalen Sensor. Eine Erweiterung des Aufbaus könnte in Form einesProjekts oder einer weiteren Abschluss-Arbeit durchgeführt werden.

[Lieback, 2012] schreibt von dem konkreten Anwendungsfall eines autonomen Was-serfahrzeugs auf Basis von Standard-Komponenten. Durch den Einsatz von SMASzur selbstständigen Steuerung des Fahrzeugs könnte das gesamte System aus dieserArbeit integriert werden.

Im Zuge der Tests des PowerVisualizerPlugins wurde ein Zusammenhang vonBass-Anteilen in Musik und den daraus resultierenden Strom-Messungen bemerkt.Eventuell könnte daraus ein lautstärke-unabhängiger Energie-Verbrauchs-Faktor füreinen Musiktitel berechnet werden.

6.3 Fazit

Rückblickend war die Erstellung dieser Arbeit sehr spannend, aber auch forderndund in manchen Situationen zermürbend. Jedoch relativierten sich die Rückschläge,als die gesetzten Meilensteine, wie beispielsweise der Erste in Echtzeit über dasSystem ausgelesene Wert, erreicht wurden.

Außerdem sind mit dieser Arbeit Ergebnisse entstanden, welche in weiteren Projek-ten verwendet werden können. Besonders erwähnenswert ist dabei der Fortschritt fürdie Entwicklung des autonomen Wasserfahrzeugs, da viele Konzepte übernommenwerden können.

Die tiefergehende Recherche zu semantischen Modellen und Cyber-Physical Systemswar eine sehr willkommene Wissenserweiterung und wird mit Sicherheit in zukünf-tigen Arbeiten wieder zum Einsatz kommen.

58

Literaturverzeichnis


[Botts u. Robin 2007] Botts, M. ; Robin, A.: OpenGIS sensor model language (Sen-sorML) implementation specification. In: OpenGIS Implementation SpecificationOGC (2007), S. 07–000 2.5.2, 40, 2.11

[BR 2012] Rundschau vom 15.01.2012 um 18:45 Uhr. Januar 2012. – BayerischerRundfunk 5

[Broy u. a. 2012] Broy, Manfred ; Geisberger, Eva ; Cengarle, María V. ; Keil,Patrick ; Niehaus, Jürgen ; Thiel, Christian ; Thönnißen-Fries, Hans-Jürgen:Cyber-Physical Systems: Innovationsmotor für Mobilität, Gesundheit, Energie undProduktion. Berlin : Springer, 2012 (acatech BEZIEHT POSITION 8). http:

//www.springer.com/computer/book/978-3-642-27566-1 2.3, 2.2

[Dondi u. a. 2002] Dondi, P. ; Bayoumi, D. ; Haederli, C. ; Julian, D. ; Suter,M.: Network integration of distributed power generation. In: Journal of PowerSources 106 (2002), Nr. 1, S. 1–9 3, 2.1

[Dooley 2002] Dooley, K.: Designing large-scale LANs. O’Reilly Media, 2002 41

[Fraunhofer-Gesellschaft 2012] Fraunhofer-Gesellschaft: Cyber Phy-sical Systems - Fraunhofer-Institut für Sichere Informationstechnolo-gie. http://www.sit.fraunhofer.de/de/kompetenzfelder/

cyber-physical-systems.html. Version: 2012 12

[Freeman u. a. 2004] Freeman, Steve ; Mackinnon, Tim ; Pryce, Nat ; Walnes,Joe: Mock roles, not objects. In: Companion to the 19th annual ACM SIGPLANconference on Object-oriented programming systems, languages, and applications.New York and NY and USA : ACM, 2004 (OOPSLA ’04). – ISBN 1–58113–833–4,S. 236–246 43

[Gherardi 2011] Gherardi, Luca: java - JFreeChart: DynamicTimeSeries withperiod of n milliseconds - Stack Overflow. http://stackoverflow.com/a/

6864036/1217292. Version: 2011 57

[HMS Industrial Networks GmbH 2012] HMS Industrial Networks GmbH:Modbus-TCP - HMS Industrial Networks GmbH. http://www.anybus.de/

technologie/modbustcp.shtml. Version: 2012 38

59

http://www.springer.com/computer/book/978-3-642-27566-1

http://www.springer.com/computer/book/978-3-642-27566-1

http://www.sit.fraunhofer.de/de/kompetenzfelder/cyber-physical-systems.html

http://www.sit.fraunhofer.de/de/kompetenzfelder/cyber-physical-systems.html

http://stackoverflow.com/a/6864036/1217292

http://stackoverflow.com/a/6864036/1217292

http://www.anybus.de/technologie/modbustcp.shtml

http://www.anybus.de/technologie/modbustcp.shtml


[Khan 2008] Khan, U.N.: Impact of distributed generation on electrical powernetwork. In: Wroclav University of Technology, Wroclav, Poland (2008) 1.1

[Kießling 2009] Kießling, A.: E-Energy-Projekt Modellstadt Mannheim. http://e-energy.de/documents/EE_Moma_20091022_ak.pdf. Version: 2009 2.2,18, 2.4, 20

[Kießling 2012] Kießling, A.: E-Energy: Modellstadt Mannheim. http://

e-energy.de/de/modellstadt_mannheim.php. Version: 2012 15

[Kienzle 2012] Kienzle, Makus: Persönliche Mitteilung von Markus Kienzle imFachgespräch v. 01.03.2012. März 2012 1.1, 2.1, 6, 2.1, 42

[Koestler 1976] Koestler, Arthur: The Ghost in the Machine. London and UK :Hutchinson & Co Ltd, 1976. – ISBN 0091271304 22

[Lee 2008] Lee, Edward A.: Cyber Physical Systems: Design Challenges. In: Interna-tional Symposium on Object/Component/Service-Oriented Real-Time DistributedComputing (ISORC), 2008. – Invited Paper 10, 11, 13, 2.2, 14, 2.5

[Lieback 2012] Lieback, Rico: Objekt-funktionale Plattform für Cyber-Physical Sys-tems, Hochschule Augsburg, Diplomarbeit, 2012 2.3, 2.3.1, 2.5, 23, 24, 2.1, 2.3.4,26, 27, 30, 2.6, 2.7, 31, 34, 2.5, 2.6, 35, 36, 2.8, 4.3.4, 6.2

[Martin 2008] Martin, R.C.: Clean Code: A Handbook of Agile Software Crafts-manship. Pearson Education, 2008 http://books.google.de/books?id=

_i6bDeoCQzsC. – ISBN 9780136083252 51

[Mühlenhoff 2011] Mühlenhoff, Jörg: Kosten und Preise für Strom / Agentur fürErneuerbare Energien e.V. 2011. – Forschungsbericht 50

[Modbus IDA 2006] Modbus IDA: MODBUS Messaging on TCP/IP Imple-mentation Guide, Oktober 2006. http://www.modbus.org/docs/Modbus_

Messaging_Implementation_Guide_V1_0b.pdf 2.1

[Odersky u. a. 2008] Odersky, M. ; Spoon, L. ; Venners, B.: Programming inScala. Artima Inc, 2008 4, 55

[Pepermans u. a. 2005] Pepermans, G. ; Driesen, J. ; Haeseldonckx, D. ; Bel-mans, R. ; D’haeseleer, W.: Distributed generation: definition, benefits andissues. In: Energy policy 33 (2005), Nr. 6, S. 787–798 7, 9

[PULS 2012] PULS: PULS Power Supplies – MiniLine ML30.100. http:

//www.pulspower.com/index.php?reqNav=product&objectId=31.Version: 2012 45, 4.6

60

http://e-energy.de/documents/EE_Moma_20091022_ak.pdf

http://e-energy.de/documents/EE_Moma_20091022_ak.pdf

http://e-energy.de/de/modellstadt_mannheim.php

http://e-energy.de/de/modellstadt_mannheim.php

http://books.google.de/books?id=_i6bDeoCQzsC

http://books.google.de/books?id=_i6bDeoCQzsC

http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

http://www.pulspower.com/index.php?reqNav=product&objectId=31

http://www.pulspower.com/index.php?reqNav=product&objectId=31


[Ryashentseva 2010] Ryashentseva, O.: Semantic Sensor Discovery and Sensor Da-ta Provisioning, Ludwig-Maximilians-Universität München, Diplomarbeit, 20102.10, 2.5.1, 39, 4.1, 4.1.1, 44, 4.1.2

[Schneider Electric 2008a] Schneider Electric: PowerLogic Power Meter210 Installation Guide, Dezember 2008. http://www.powerlogic.com/

literature/63230-510-201A1%20PM210%20Install.pdf 4.7, 49

[Schneider Electric 2008b] Schneider Electric: PowerLogic Power Meter210 Reference Manual, Dezember 2008. http://www.powerlogic.com/

literature/63230-510-205.pdf 46

[Schneider Electric 2008c] Schneider Electric: Product Environmen-tal Profile STB NIP 2212 Advantys Ethernet Network Interface Modu-leProduit STB NIP 2212 Advantys Ethernet Network Interface Modu-le. http://www.global-download.schneider-electric.com/

85257578007E5C8A/all/E1DC92096481D14E88257578006EC67C/

$File/envpep080803en.zip. Version: 2008 4.9

[Schneider Electric 2009a] Schneider Electric: Advantys STB distributed I/Osolution - Digital I/O modules: Selection guide. 2009 4.10, 4.11

[Schneider Electric 2009b] Schneider Electric: Advantys STB: Standard-Ethernet Modbus TCP/IP-NIM Applikationshandbuch. (2009). http://www.global-download.schneider-electric.com/852575A6007E5FD3/

all/38D0004C0D4F71A38525763300566E49/$File/31003690k01000.

pdf 48

[Schneider Electric 2009c] Schneider Electric: PowerLogic™ Ethernet Gate-way EGX100: User’s Guide. http://www.powerlogic.com/literature/

63230-319-204A2.pdf. Version: 2009 47, 4.8

[Schöler 2011] Schöler, Thorsten: Softwareagenten – Vorlesung.http://www.hs-augsburg.de/fakultaet/informatik/studium/

wahlpflichtveranstaltung/softwareagenten/index.html.Version: 2011 32

[Simply Modbus 2012] Simply Modbus: Simply Modbus - Data CommunicationTest Software - Modbus ASCII vs RTU. http://www.simplymodbus.ca/

TCP.htm. Version: 2012 2.9

[Weiss 2011] Weiss, Andreas: Integration von Ereignisverarbeitungs und OPC-Infrastrukturen, Hochschule Augsburg, IBM Deutschland GmbH, Diplomarbeit,2011 2.5, 2.5.3, 2.12, 3.2.3, 4.1.1

61

http://www.powerlogic.com/literature/63230-510-201A1%20PM210%20Install.pdf

http://www.powerlogic.com/literature/63230-510-201A1%20PM210%20Install.pdf

http://www.powerlogic.com/literature/63230-510-205.pdf

http://www.powerlogic.com/literature/63230-510-205.pdf

http://www.global-download.schneider-electric.com/85257578007E5C8A/all/E1DC92096481D14E88257578006EC67C/$File/envpep080803en.zip



http://www.global-download.schneider-electric.com/852575A6007E5FD3/all/38D0004C0D4F71A38525763300566E49/$File/31003690k01000.pdf




http://www.powerlogic.com/literature/63230-319-204A2.pdf

http://www.powerlogic.com/literature/63230-319-204A2.pdf

http://www.hs-augsburg.de/fakultaet/informatik/studium/wahlpflichtveranstaltung/softwareagenten/index.html

http://www.hs-augsburg.de/fakultaet/informatik/studium/wahlpflichtveranstaltung/softwareagenten/index.html

http://www.simplymodbus.ca/TCP.htm

http://www.simplymodbus.ca/TCP.htm


[Wikipedia 2012a] Wikipedia: Backfeeding - Wikipedia, the free encyclopedia.http://en.wikipedia.org/wiki/Backfeeding. Version: 2012 8

[Wikipedia 2012b] Wikipedia: Modbus - Wikipedia. http://de.wikipedia.

org/wiki/Modbus. Version: 2012 37

[Witte 2011] Witte, Jens: Tote Arbeiter in havariertemAKW gefunden. http://www.spiegel.de/panorama/

fukushima-tote-arbeiter-in-havariertem-akw-gefunden-a-754722.

html. Version: 2011 1

[Wooldridge 2009] Wooldridge, Michael: An introduction to multiagent systems.2. Hoboken and NJ : John Wiley & Sons, 2009. – ISBN 0470519460 19

62

http://en.wikipedia.org/wiki/Backfeeding

http://de.wikipedia.org/wiki/Modbus

http://de.wikipedia.org/wiki/Modbus

http://www.spiegel.de/panorama/fukushima-tote-arbeiter-in-havariertem-akw-gefunden-a-754722.html



Eidesstattliche Erklärung

Eidesstattliche Erklärung

Ich, Johannes Leimer, Matrikel-Nr. 917177, versichere hiermit, dass ich meine Ba-chelorarbeit mit dem Thema

Anwendung eines Cyber-Physical Systems für intelligentes Energiemana-gement

selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittelbenutzt habe, wobei ich alle wörtlichen und sinngemäßen Zitate als solche gekenn-zeichnet habe. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegtund auch nicht veröffentlicht.

Mir ist bekannt, dass ich meine Bachelorarbeit zusammen mit dieser Erklärungfristgemäß nach Vergabe des Themas in dreifacher Ausfertigung und gebunden imPrüfungsamt der Hochschule Augsburg abzugeben oder spätestens mit dem Post-stempel des Tages, an dem die Frist abläuft, zu senden habe.

Augsburg, den 21. Mai 2012

Johannes Leimer

63

Anwendung eines Cyber-Physical Systems für intelligentes ...jleimer/pub/bachelor-thesis.pdf ·...

Documents

Transcript of Anwendung eines Cyber-Physical Systems für intelligentes ...jleimer/pub/bachelor-thesis.pdf ·...