systeme - KOBRA - Universität Kassel

Transcrição

Entwurf und Betrieb von Regelungs- und
Monitoringsystemen für dezentrale Energiesysteme auf
der Basis von verteilten Embedded Systems
Dissertation zur Erlangung des akademischen Grades eines Doktors
der Ingenieurwissenschaften (Dr.-Ing.) im Fachbereich
Elektrotechnik/Informatik der Universität Kassel
vorgelegt von
Dipl.-Biol. Rainer Becker
Eingereicht im
November 2008
Datum der Disputation 20.01.2009
1. Gutachter
2. Gutachter
Prof. Dr.-Ing. Jürgen Schmid
Prof. Dr.-Ing. Birgit Vogel-Heuser
3
Erklärung
Hiermit versichere ich, dass ich die vorliegende Dissertation selbständig und ohne unerlaubte
Hilfe angefertigt und andere als die in der Dissertation angegebenen Hilfsmittel nicht benutzt
habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder unveröffentlichten
Schriften entnommen sind, habe ich als solche kenntlich gemacht. Kein Teil dieser Arbeit ist in
einem anderen Promotions- oder Habilitationsverfahren verwendet worden.
Kassel, 25. November 2008
4
5
Noch sind wir zwar keine gefährdete Art, aber es ist nicht so, dass wir nicht oft genug versucht
hätten, eine zu werden.
Douglas Adams (Die Letzten ihrer Art)
Auf welche Irrwege werden noch heut die jungen Leute durch die neue Mode gelockt, alles
durchs Mikroskop zu betrachten.
Feodor Lösch (Amöbenruhr, 1874)
A distributed system is one in which the failure of a computer you didn’t even know existed can
render your own computer unusable.
Leslie Lamport (Subject: distribution (Email message to DEC SRC bulletin board, 1987))
Inhaltsverzeichnis
1 Einleitung
13
2 Stand der Technik und Motivation
2.1 Monitoringsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Motivation zur Entwicklung verteilter Monitoringsysteme mit vernetzten
Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Verteilte Regelungssysteme für dezentrale Energiesysteme . . . . . . . . . . .
2.2.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Motivation zur Entwicklung verteilter Regelungssysteme mit vernetzten
Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Gemeinsamkeiten der Regelungs- und Monitoringsysteme . . . . . . . . . . .
17
. 17
. 17
. 19
. 20
. 20
. 20
. 21
3 Embedded Systems
23
3.1 Prozessorarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Verteilte Systeme
4.1 Definition für Verteilte Systeme . . . . . . . . . . . .
4.2 Grundsätzliche Anforderungen an Verteilte Systeme .
4.3 Verteilte Regelungssysteme . . . . . . . . . . . . . .
4.4 Anforderungen an verteilte Regelungssysteme . . . .
4.5 Unterschiedliche Strukturen von Regelungssystemen
4.6 Vorteile verteilter Regelungssysteme . . . . . . . . .
4.6.1 Maskierung von Komplexität . . . . . . . . .
4.6.2 Handling von Kommunikationsausfällen . . .
4.6.3 Lokale Lösungen von lokalen Problemen . .
4.6.4 Zusammenarbeit von Regler und Komponente
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
30
30
31
33
33
34
34
34
5 Anwendungsbeispiele für Verteilte Systeme
5.1 Verteilte Regelungssysteme . . . . . . . . . . . . . . . . . . .
5.1.1 Innovationsmotor Klimapolitik . . . . . . . . . . . . .
5.1.2 Erzeugungsmanagement von EEG- und KWK-Anlagen
5.1.3 Zeitliche Lastverschiebung durch dynamische Tarife .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
39
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
8
5.2
Verteilte Monitoringsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Energieverbrauchs-Monitoring im gewerblichen Bereich . . . . . . . . . 40
5.2.2 Smart-Metering-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Genormte Kommunikation
6.1 Bedeutung normierter Kommunikation . . . . . . . . . . . . .
6.2 Kommunikation in der elektrischen Energieversorgungstechnik
6.3 Kommunikation in der Automatisierungstechnik . . . . . . . .
6.3.1 OLE for Process Control (OPC) . . . . . . . . . . . .
6.3.2 OPC Unified Architecture (OPC UA) . . . . . . . . .
6.4 Kommunikationsprobleme durch unzureichende Normung . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Stand der Internet-Technik für Verteilte Systeme
7.1 Lokale Vernetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Very High Data Rate Digital Subscriber Line (VDSL) . . . . . . . . . .
7.1.3 Powerline Communication (PLC) . . . . . . . . . . . . . . . . . . . .
7.1.4 Wireless Local Area Network (WLAN) . . . . . . . . . . . . . . . . .
7.1.5 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Drahtgebundene Internetzugänge . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Digital Subscriber Line (DSL) . . . . . . . . . . . . . . . . . . . . . .
7.2.2 Internet per TV-Kabel . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3 Analog-Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.4 Integrated Services Digital Network (ISDN) . . . . . . . . . . . . . . .
7.2.5 Nutzung bereits vorhandener Internetzugänge . . . . . . . . . . . . . .
7.3 Drahtlose Internetzugänge . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Global System for Mobile Communications (GSM) . . . . . . . . . . .
7.3.2 Universal Mobile Telecommunication System (UMTS) . . . . . . . . .
7.3.3 Worldwide Interoperability for Microwave Access (WiMAX) . . . . . .
7.4 Technische Probleme bei der Internet-Nutzung . . . . . . . . . . . . . . . . . .
7.4.1 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . .
7.4.2 Wechselnde IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.3 Verbindungsabbrüche bei Einwahlverbindungen . . . . . . . . . . . . .
7.5 Netzwerkdienste für Verteilte Systeme . . . . . . . . . . . . . . . . . . . . . .
7.5.1 Zuweisung von IP-Adressen mittels Dynamic Host Configuration
Protocol (DHCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2 Domain Name System (DNS) . . . . . . . . . . . . . . . . . . . . . .
7.5.3 Zeitsynchronisation mit dem Network Time Protocol (NTP) . . . . . .
7.5.4 Sicherheitsupdates . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.5 Fernwartung mit der Secure Shell (SSH) . . . . . . . . . . . . . . . . .
7.5.6 rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Überwachung von Verteilten Systemen . . . . . . . . . . . . . . . . . . . . . .
7.6.1 Smokeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
45
45
45
47
48
48
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
52
52
52
53
54
54
54
55
55
57
58
58
58
62
63
63
63
68
69
70
.
.
.
.
.
.
.
.
70
71
72
73
74
79
80
80
INHALTSVERZEICHNIS
7.6.2
7.6.3
9
Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Sonderlösungen für per GSM vernetzte Systeme . . . . . . . . . . . . . . 82
8 Sicherheitsaspekte bei der Internet-Nutzung
8.1 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . . . .
8.2 Secure Socket Layer (SSL) und Transport Layer Security (TLS) . . . .
8.3 Secure Shell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Sicherheitsaspekte bei Netzwerkstrukturen . . . . . . . . . . . . . . . .
8.6 Sicherheitstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.1 Rechtliche Schwierigkeiten bei der Nutzung von Sicherheitstools
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
87
91
92
92
94
99
100
9 Online-Visualisierung mit Java-Applets und XML-RPC
9.1 Visualisierungs-Client-Software . . . . . . . . . . .
9.2 Server-Software für die Visualisierung . . . . . . . .
9.3 Ablauf des Visualisierungsprozesses . . . . . . . . .
9.4 Grafische Erstellung von Online-Visualisierungen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
105
106
108
111
10 Visualisierung auf Mobiltelefonen mit WAP
10.1 WAP 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Infrastruktur zur Auslieferung von WAP-Dokumenten . . . . . . . . . . . . . . .
10.3 WAP 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
115
117
118
11 Simulation verteilter Regelungssysteme
11.1 Virtualisierungstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Simulation mit User-mode Linux und ColSim . . . . . . . . . . . . . . . . . . .
11.2.1 User-mode Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.2 Installation eines Debian-User-mode Linux auf einem Debian-LinuxHost-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.3 Simulationsumgebung ColSim . . . . . . . . . . . . . . . . . . . . . . .
11.2.4 Netzwerkstruktur der Simulationsumgebung . . . . . . . . . . . . . . . .
11.2.5 Zeitskala – Realtime oder Jahressimulation . . . . . . . . . . . . . . . .
11.2.6 Anwendungsbeispiel Reglerentwicklung für eine thermische Solaranlage
121
123
125
125
12 Betriebssysteminstallation
12.1 Betriebssystem-Images . . . . . . . . . . . . . . . . . . . . .
12.1.1 Blockweises Kopieren des gesamten Massenspeichers .
12.1.2 Dateibasiertes Kopieren eines Massenspeichers . . . .
12.2 Klonen eines laufenden Systems . . . . . . . . . . . . . . . .
12.3 Nutzung von Paketmanagern zur Softwareinstallation . . . . .
139
139
140
140
142
143
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
127
127
135
136
13 Konfigurations- und Parametriersoftware
145
13.1 Konfiguration und Parametrierung in der industriellen Prozess- und Fertigungsautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
INHALTSVERZEICHNIS
10
13.1.1 Electronic Device Description Language (EDDL) .
13.1.2 Field Device Tool (FDT) . . . . . . . . . . . . . .
13.2 Softwareinstallation . . . . . . . . . . . . . . . . . . . . .
13.2.1 Grafisches Userinterface zur Systemparametrierung
13.2.2 Automatische Hardwareerkennung für Messtechnik
13.2.3 Automatisierte Softwareinstallation . . . . . . . .
14 Hardware-Anforderungen an Verteilte Systeme
14.1 Speichermedien . . . . . . . . . . . . . . . . . . . . .
14.1.1 Festplatten . . . . . . . . . . . . . . . . . . . .
14.1.2 Speichermedien aus Flash-Bausteinen . . . . .
14.1.3 Maßnahmen zur Erhöhung der Betriebsstabilität
14.2 Datensicherheit . . . . . . . . . . . . . . . . . . . . .
14.3 Stabilisierung der Spannungsversorgung . . . . . . . .
14.4 Watchdog . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
146
146
147
150
151
.
.
.
.
.
.
.
155
155
155
156
157
158
159
160
15 Evaluation
161
15.1 Verteiltes Monitoringsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
15.1.1 Projekte Wärmepumpen im Gebäudebestand und Wärmepumpen-Effizienz161
15.1.2 Kommunikationsinfrastruktur . . . . . . . . . . . . . . . . . . . . . . . 162
15.1.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
15.1.4 Betriebssystemanpassung . . . . . . . . . . . . . . . . . . . . . . . . . . 174
15.1.5 Softwareinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
15.1.6 Probebetrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
15.1.7 Prozessliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
15.1.8 Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
15.1.9 Messdatenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
15.1.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
15.2 Verteiltes Regelungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.2.1 Power Flow and Power Quality Management System (PoMS) . . . . . . . 187
15.2.2 Erstellung von Fahrplänen . . . . . . . . . . . . . . . . . . . . . . . . . 187
15.2.3 Infrastruktur des verteilten Regelungssystems . . . . . . . . . . . . . . . 188
15.2.4 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
15.2.5 Software der Power Interface Boxes . . . . . . . . . . . . . . . . . . . . 196
15.2.6 Aufgaben der PoMS Central Unit (PCU) . . . . . . . . . . . . . . . . . . 197
15.2.7 Aufgaben der Power Interface Boxes (PIBs) . . . . . . . . . . . . . . . . 197
15.2.8 Mechanismen zur Überwachung des PoMS . . . . . . . . . . . . . . . . 198
15.2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
16 Zusammenfassung und Ausblick
201
16.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
16.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
INHALTSVERZEICHNIS
11
17 Danksagung
205
Abbildungsverzeichnis
206
Tabellenverzeichnis
210
Literaturverzeichnis
211
12
INHALTSVERZEICHNIS
Kapitel 1
Einleitung
Wir leben heute in einer Welt, in der Kommunikation zwischen technischen Systemen eine
zunehmend bedeutende Rolle spielt. Unser alltägliches Leben wird an vielen Stellen dadurch
erleichtert, dass eine große Anzahl dieser Systeme reibungslos zusammenarbeiten. Dabei gewinnen sogenannte verteilte Systeme – d. h. Rechner, die per Netzwerk miteinander in Verbindung
stehen – immer mehr an Bedeutung. Sie begegnen uns z. B., wenn wir von untereinander vernetzten Verkehrsampeln im städtischen Straßenverkehr geleitet werden oder wenn miteinander
vernetzte Kleinrechner in der Gebäudeleittechnik dafür sorgen, dass alle technischen Systeme
eines Gebäudes (Heizung, Kühlung, Lüftung, etc.) sinnvoll zusammenarbeiten.
Mit steigender Rechenleistung und fallenden Kosten für Hardware wird es immer interessanter,
nicht nur handelsübliche PCs und Server miteinander zu vernetzen, sondern alle Arten von
Geräten mit netzwerkfähiger Computertechnik auszustatten. Leistungsschwache eigenständig
arbeitende Mikrocontroller zur Gerätesteuerung werden durch leistungsstarke netzwerkfähige
Embedded Systems ersetzt.
Für die Zuverlässigkeit dieser Systeme ist dabei entscheidend, mit welcher Software und
unter welchen Randbedingungen sie betrieben werden. Verteilte Systeme, die auf intensiver
Kommunikation basieren, müssen beim Ausfall von Kommunikationskanälen zumindest einen
Notbetrieb aufrecht erhalten können. Das gelingt jedoch nur, wenn die einzelnen Knoten eines
verteilten Systems ausreichend Systemressourcen haben, um auch eigenständig zu funktionieren.
Oftmals sind verteilte Systeme aber so strukturiert, dass die dezentralen sehr leistungsschwachen
Knoten durch einen leistungsstarken zentralen Server gesteuert werden. Solche Systeme können
bei Kommunikationsausfall nicht weiter funktionieren.
In dieser Arbeit stehen deshalb vergleichsweise leistungsstarke Embedded Systems im Mittelpunkt der Betrachtung, die eigenständig sinnvoll arbeiten können.
Während der letzten Jahre haben Internet-Technologien – insbesondere die für die Kommunikation im Internet genutzten Kommunikationsprotokolle – proprietäre Kommunikationssysteme
und -protokolle an vielen Stellen abgelöst und zu einer Standardisierung geführt. Daher
13
14
KAPITEL 1. EINLEITUNG
werden in dieser Arbeit ausschließlich Kommunikationsmittel behandelt, die standardmäßig
Transmission Control Protocol/Internet Protocol (TCP/IP) benutzen.
Diese Familie von Netzwerkprotokollen hat den großen Vorteil, dass sie mit ganz verschiedenen Medien (Ethernet, Mobilfunk, Wireless LAN, . . . ) funktioniert und dabei Transparenz
gewährleistet, d. h. dass es für das Format und die Behandlung der übertragenen Daten völlig
unerheblich ist, welches Transportmedium genutzt wird.
Die Administration von verteilten Monitoring- und Regelungssystemen mit vielen Knoten ist
eine große Herausforderung. Sie setzt die Entwicklung und Nutzung spezieller Softwaretools
zur weitgehend automatisierten Überprüfung der Funktionalität der Systeme voraus. Dazu
gehören sowohl die Kontrolle der Mess- und Regelungsprozesse als auch die Überprüfung der
Kommunikationsverbindungen. Automatisch erstellte und per Email versandte Reports über die
Systemzustände können dabei die Arbeit erleichtern. Die Visualisierung von Messdaten und
Regelungsprozessen mittels Internet- und Mobilfunktechnologien vereinfacht die Funktionskontrolle und Fehlerbehebung beim Betrieb der Systeme.
Spezielle Software zur Funktionskontrolle und Visualisierung der Betriebszustände wurde im
Rahmen dieser Arbeit entwickelt und soll hier diskutiert werden.
Immer häufiger nutzen verteilte Systeme die Internet-Technologie nicht nur im lokalen Netzwerk, sondern auch zur direkten Kommunikation ihrer Knoten untereinander über das Internet.
Dadurch entsteht die Notwendigkeit, diese Systeme möglichst gut vor Angriffen aus dem
Internet zu schützen und Softwarefehler, die Sicherheitslücken verursachen, schnell zu beheben.
Die Untersuchung von Sicherheitssoftware und Netzwerktechnologien stellt einen weiteren Teil
dieser Arbeit dar.
Da Regelungs- und Kommunikationssoftware auf den verschiedenen Knoten eines Systems
störungsfrei zusammenarbeiten müssen, ist die Entwicklung von verteilten Regelungssystemen
eine sehr komplexe Aufgabe. Zum Zeitpunkt der Softwareentwicklung stehen die Embedded
Systems sowie die zu regelnde Hardware oft noch nicht zur Verfügung.
In dieser Arbeit wird gezeigt, wie mit Hilfe von virtuellen Maschinen, virtuellen Netzwerken
und Software zur Anlagensimulation eine Entwicklungsumgebung geschaffen wird, in der die
Kommunikations- und Regelungssoftware für verteilte Systeme schon entwickelt und getestet
werden kann, bevor die echte Hardware zum Einsatz kommt.
Das Installieren von verteilten Monitoring- und Regelungssystemen mit vielen Knoten ist nur
dann ohne allzu großen Aufwand möglich, wenn sie mit Installationssoftware weitgehend automatisiert erfolgen kann. Derartige Software ermöglicht das komfortable Installieren sowohl der
Betriebssysteme als auch der Applikationssoftware auf den Embedded Systems des verteilten
Systems. Sie enthält auch Funktionen für die Parametrierung der Applikationssoftware mit Hilfe
von grafischen Benutzeroberflächen.
In dieser Arbeit werden verschiedene Ansätze zur automatisierten Softwareinstallation von
verteilten Monitoring- und Regelungssystemen mit vielen Knoten und zur Parametrierung von
Messsoftware diskutiert.
15
Zahlreiche praktische Aspekte beim Aufbau und Betrieb von verteilten Systemen aus Embedded
Systems werden am Beispiel von zwei großen verteilten Monitoringsystemen zur Messung
der Energieeffizienz von Wärmepumpen und am Beispiel eines verteilten Regelungssystems
zum Betrieb eines Niederspannungsnetzes behandelt. Die hier vorliegende Arbeit wurde im
Zusammenhang mit der Planung, Entwicklung und Realisierung dieser drei Projekte erstellt.
16
KAPITEL 1. EINLEITUNG
Kapitel 2
Stand der Technik und Motivation
2.1 Monitoringsysteme
2.1.1 Stand der Technik
Zum langfristigen Monitoring von dezentralen Energiesystemen werden heute in den meisten
Fällen handelsübliche Datenlogger oder PC-basierte Lösungen eingesetzt. Die beiden Technologien unterscheiden sich in ihren grundlegenden Konzepten und weisen deshalb auch ganz unterschiedliche Eigenschaften auf. Im Folgenden werden Vor- und Nachteile der beiden Messystemtypen beschrieben
Datenlogger
Klassische Datenlogger arbeiten in den meisten Fällen sehr zuverlässig und wartungsarm.
Mit Hilfe von entsprechender Parametrierungs- und Auslesesoftware können sie auch von
Nicht-IT-Fachkräften eingerichtet und betrieben werden. Sie arbeiten aufgrund ihrer Ausstattung
mit stromsparenden Mikrocontrollern sehr energieeffizient. Die Nutzung von leistungsschwachen Mikrocontrollern bewirkt jedoch auch, dass die Geräte hinsichtlich Erweiterbarkeit und
Programmierung wenig flexibel sind.
Datenlogger lassen sich meist gar nicht oder nur mit Messmodulen erweitern, die vom gleichen
Hersteller produziert wurden. Z. B. ist eine Erweiterung der Messtechnik mit Messgeräten,
die auf der Basis von standardisierten Industrie-Bussystemen arbeiten, nicht möglich. Die zu
messenden Signale müssen für die Messung mit dem Datenlogger entsprechend konditioniert
werden, da diese Geräte in den meisten Fällen nur Standard-Industriesignale loggen können.
Viele Datenlogger können einfache Auswertungsfunktionen durchführen, wie z. B. das
Skalieren der Messwerte einzelner Messkanäle. Für diesen Zweck gibt es oftmals einfache
Programmierwerkzeuge oder auch Programmiersprachen, mit denen derartige Aufgaben gelöst
17
18
KAPITEL 2. STAND DER TECHNIK UND MOTIVATION
werden können. Die Logger sind jedoch nicht frei programmierbar, so dass vom Hersteller nicht
vorgesehene Zusatzfunktionen auch nicht implementiert werden können.
Der Datenabruf erfolgt bei den meisten Datenloggern mit Hilfe von Einwahlverbindungen. Dabei werden entweder Analogmodems oder GSM-Modems genutzt. Meist wird der Datenlogger
einmal täglich angerufen, um die seit dem letzten Anruf aufgelaufenen Daten abzurufen. Die
Technologie der Einwahlverbindungen hat mehrere Nachteile. Da Einwahlverbindungen über
die Verbindungszeit und nicht über das transferierte Datenvolumen abgerechnet werden, ist es
finanziell nicht sinnvoll, über längere Zeiträume Online-Daten von Datenloggern abzurufen. Ein
weiter Nachteil der Einwahlverbindungen ist, dass die Abrufprozesse mehrerer Datenlogger
nicht parallel laufen können. Da der Datenabruf für jeden Datenlogger eine gewisse Zeit
beansprucht und die Logger sequentiell abgearbeitet werden müssen, ist die Anzahl der pro
Telefonleitung und Tag abrufbaren Datenlogger und damit auch die Skalierbarkeit des gesamten
Messsystems begrenzt.
In den letzten Jahren wurden auch Datenlogger entwickelt, bei denen der Datenabruf über
das Internet erfolgt. Diese Geräte sind meist mit einem Ethernet-Interface (siehe Abschnitt
7.1.1) zum Betrieb an einem DSL-Router oder mit einem GPRS-Modem (siehe Abschnitt
7.3.1) ausgestattet. Mit dieser Internettechnologie ist ein zeitgleicher Abruf der Daten von sehr
vielen Datenloggern möglich, so dass es beim Datenabruf keine Skalierungsprobleme gibt.
Eine Online-Visualisierung der Messdaten ist mit diesen Geräten nur dann möglich, wenn der
Hersteller die Funktionalität softwaretechnisch unterstützt.
Die internetfähigen Datenlogger sind oftmals softwaretechnisch nur unzureichend für eine sichere Kommunikations vorbereitet, da sie nur unverschlüsselte Kommunikationsprotokolle, wie
z. B. das File Transfer Protocol (FTP), nutzen und damit leicht angreifbar sind.
PC-basierte Messtechnik für Monitoringsysteme
Wenn Messaufgaben durchgeführt werden sollen, die mit den von Datenloggern zur Verfügung
gestellten Funktionalitäten nicht zu bewerkstelligen sind, werden oftmals PC-basierte Lösungen
genutzt. Die Hardware solcher Systeme ist nicht selten deutlich preiswerter als Datenlogger. Im
Gegensatz zu den Loggern gibt es PC-basierte Messsysteme meist nicht fertig konfiguriert zu
kaufen. Sie müssen von Fachkräften eingerichtet und betrieben werden.
Die große Vorteil der PC-basierten Lösungen ist ihre Flexibilität. Da PCs frei programmierbar
sind und hinsichtlich ihrer Schnittstellen stark erweitert werden können, gibt es kaum Messaufgaben, die mit PC-basierten Messystemen nicht bewerkstelligt werden können. Der PC als
“Universalwerkzeug” ist jedoch für die meisten Messtätigkeiten völlig überdimensioniert und
damit alles andere als energieeffizient.
2.1. MONITORINGSYSTEME
19
Mit PCs lassen sich alle Varianten von Kommunikationsverbindungen für den Datenabruf
realisieren. Auch verschlüsselte Verbindungen über das Internet sind damit völlig problemlos
möglich.
PC-basierte Messsysteme sind im Vergleich zu Datenloggern meist deutlich anfälliger für
Störungen und Ausfälle. Dementsprechend ist der Wartungsaufwand für sie auch erheblich
größer.
In Tabelle 2.1 sind die Vor- und Nachteile von Datenloggern und PC-basierten Messsystemen
zusammengefasst.
Datenlogger Datenlogger
PC mit
klassisch
internetfähig Messtechnik
Konfiguration durch Laien
ja
ja
nein
flexible Anbindung von Messtechnik
nein
nein
ja
Online-Datenabruf
nein
nein
ja
frei programmierbar
nein
nein
ja
Kommunikation per Internet
nein
ja
ja
verschlüsselte Kommunikation
nein
nein
ja
wartungsarm
ja
ja
nein
preisgünstige Hardware
nein
nein
ja
energieeffizient
ja
ja
nein
Tabelle 2.1: Stand der Technik bei Monitoringsystemen für verteilte Energiesysteme
2.1.2 Motivation zur Entwicklung verteilter Monitoringsysteme mit vernetzten Embedded Systems
Sowohl Datenlogger als auch PC-basierte Messsysteme stellen keine Ideallösung für komplexe
Messprojekte dar, da beiden Technologien notwendige Eigenschaften und Funktionalitäten fehlen. Die Nutzung von vernetzten Embedded Systems ermöglicht die Entwicklung eines Messsystems, das die positiven Eigenschaften der Datenlogger und der PC-basierten Messsysteme in
sich vereint. Das Ergebnis ist ein bedienungsfreundliches, flexibel erweiterbares Messsystem aus
preiswerten Komponenten, das energieeffizient arbeitet und sicher über das Internet kommunizieren kann.
20
2.2 Verteilte Regelungssysteme für dezentrale Energiesysteme
2.2.1 Stand der Technik
Dezentrale Energiesysteme, wie z. B. Blockheizkraftwerke, sind sehr häufig mit einer eigenen
Regelungshardware ausgestattet. Die Regler können entweder gar nicht mit der Außenwelt
kommunizieren, oder aber sie kommunizieren über eine exklusiv für sie zur Verfügung gestellte
Infrastruktur, wie z. B. eine eigene Telefonleitung. Befinden sich mehrere Energiesysteme an
einem Ort, so wird nicht selten zu jedem einzelnen Gerät eine Telefonleitung gelegt. Dadurch
entstehen unnötig hohe Kommunikationskosten.
Die Kommunikationsinterfaces werden von den Betreibern, Wartungsfirmen und Herstellern
zur Fernwartung genutzt. Dabei kommen proprietäre Kommunikationsprotokolle zum Einsatz,
die oft nur von der hersteller-eigenen Kommunikationssoftware beherrscht werden. Eine
Interoperabilität mit Produkten anderer Hersteller wird dadurch unterbunden.
Ein weiteres Problem der dezentralen Energiesysteme ist die mangelnde Abstimmung der verschiedenen Regelungssysteme aufeinander. Es gibt bisher kaum Kommunikationsnormen, die
für eine Kommunikation zwischen den Reglern verschiedener Energiesysteme genutzt werden
könnten. In Folge dessen müssen die Regler weitgehend ohne Informationen von anderen Systemen arbeiten. Eine Optimierung des Gesamtsystems ist damit kaum möglich. Bei Änderungen,
z. B. durch Hinzufügen oder Entfernen von Teilsystemen, müssen alle Regler neu von Hand
parametriert werden. Es ergibt sich ein sehr unflexibles Gesamtsystem.
2.2.2 Motivation zur Entwicklung verteilter Regelungssysteme mit vernetzten Embedded Systems
Zur energetischen und monetären Effizienzsteigerung von dezentralen Energiesystemen aus
mehreren Einzelsystemen ist es notwendig, dass die Komponenten untereinander kommunizieren und Kommunikationsmedien gemeinsam nutzen. Die Regelungskomponenten heutigen
dezentralen Energiesystemen sind dafür meist nicht ausgelegt. Sie können durch Netzwerkfähige
Embedded Systems ersetzt oder ergänzt werden, die Regelung und Kommunikation übernehmen.
Zur Vernetzung der Teilsysteme und zur Schaffung einer übergreifenden Kommunikationsinfrastruktur mit Fernwartungsfunktionen bieten sich Internet-Technik an, da sie preiswert ist und
sich bei ähnlichen Problemstellungen vielfach bewährt hat. Lokale Netzwerke ermöglichen die
Kommunikation der Emgbedded Systems untereinander. Mit Hilfe eines Internetzugangs können für die Regelung notwendige Zusatzinformationen, wie z. B. Wetterdaten bezogen werden.
Außerdem kann über diesen Zugang eine Fernwartung des Gesamtsystems und der einzelnen
Komponenten realisert werden. Dabei ist der Zugriff auf die Systeme im Gegensatz zu Einwahllösungen jederzeit möglich.
2.3. GEMEINSAMKEITEN DER REGELUNGS- UND MONITORINGSYSTEME
21
2.3 Gemeinsamkeiten zwischen verteilten Regelungs- und
Monitoringsystemen
Verteilte Regelungs- und Monitoringsysteme müssen hardware- und softwaretechnisch flexibel
an die jeweiligen Projektanforderungen anpassbar sein. Sie sollen dabei energieeffizient und zuverlässig im Feld arbeiten. Netzwerkfähige Embedded Systems können diesen Anforderungen
gerecht werden. Sowohl Regelungs- als auch Monitoringsysteme sollten jederzeit per Internet
erreichbar sein. Dadurch ergeben sich auch ganz ähnliche Anforderungen an die kommunikationstechnische Anbindung der Systeme. Auch die damit verbundenen Anforderungen an die
informationstechnische Sicherheit der Systeme gleichen sich.
22
Kapitel 3
Embedded Systems
Eingebettete Systeme (Embedded Systems) sind Computersysteme, die als Teile größerer
Geräte oder Anlagen regelungsund steuerungstechnische Aufgaben übernehmen. Klassische
Beispiele sind die Motorsteuergeräte von Automobilen oder die Regler von Waschmaschinen.
Zur Interaktion mit Nutzern sind Embedded Systems nicht mit der klassischen Peripherie eines
Personalcomputers (Tastatur, Maus, Bildschirm, etc.) ausgestattet. Stattdessen verfügen sie
über eine für die Aufgabenstellung speziell zugeschnittene Peripherie (z. B. LC-Display und
Drucktasten eines Videorecorders). Viele Embedded Systems funktionieren völlig autark und
interagieren gar nicht mit Nutzern.
Personalcomputer sind so ausgelegt, dass sie sich für eine große Anzahl verschiedener Aufgaben eignen und oftmals für die Aufgaben, die sie verrichten, völlig überdimensioniert sind.
Embedded Systems hingegen sind Bestandteile anderer Geräte und erfüllen im Allgemeinen
nur begrenzte Aufgaben, für die sie speziell entwickelt wurden. Diese Hardware kann passend
für die benötigte Leistung zugeschnitten werden. Dabei wird ein besonderes Augenmerk auf
den Stromverbrauch gerichtet. Für Embedded Systems ist deshalb eine große Anzahl von
speziell auf geringen Stromverbrauch optimierten Prozessoren verfügbar. Diese beherrschen
z. B. verschiedene Schlafmodi, um den Stromverbrauch in Betriebspausen rapide zu senken.
Außerdem arbeiten sie oft mit niedrigen Taktfrequenzen, wodurch verringerte Betriebsspannungen ermöglicht werden. Der geringere Energiebedarf hat außerdem zur Folge, dass die Systeme
ohne Lüfter betrieben werden können, da weniger Abwärme entsteht. Durch den Verzicht auf
Lüfter werden die Geräte zudem leiser und auch deutlich zuverlässiger, da Lüfterausfälle ein
häufig auftretendes Problem sind.
Die Anforderungen hinsichtlich ihrer Zuverlässigkeit sind an Embedded Systems sehr viel höher
als an handelsübliche Personalcomputer.
Während man PCs im Falle eines Absturzes einfach per Druck auf den Resetknopf wiederbelebt,
ist die Notwendigkeit eines manuellen Eingriffs für Embedded Systems oft nicht hinnehmbar.
23
24
KAPITEL 3. EMBEDDED SYSTEMS
Embedded Systems müssen in der Regel wartungsfrei und ohne Nutzerinteraktion über lange
Zeiträume zuverlässig funktionieren. Ihre Gesamtlebensdauer ist im Allgemeinen auch wesentlich höher als die von PCs. Um die notwendige Zuverlässigkeit zu erzielen, wird spezielle Hardware eingesetzt, die bestimmte Fehlerarten selbständig beheben und kritische Systemzustände
erkennen kann. Als Beispiele seien hier Speicherbausteine, die per Error-correcting Code (ECC)
1-bit-Fehler automatisch korrigieren können, und Watchdogschaltungen, die bei Systemstillstand
automatisch einen Reset auslösen, genannt.
Ein anderer maßgeblicher Faktor für die Zuverlässigkeit der Systeme ist die verwendete Software. Siehe dazu Abschnitt 3.2.
3.1 Prozessorarchitekturen
Der Prozessor ist die zentrale Einheit eines jeden Computers. In Personalcomputern findet
man meist Prozessoren, die mit der so genannten x86-Architektur arbeiten. x86 bezeichnet
den Befehlssatz, der von der Firma Intel [133] für die Prozessoren der 8086/8088 Reihe
entwickelt wurde. Bei anderen Geräten finden oft Prozessoren mit abweichenden Architekturen
Verwendung.
In Embedded Systems werden meist spezielle stromsparende Prozessoren eingesetzt, da
hohe Stromverbräuche oft nicht akzeptabel sind. Lange Zeit beherrschten Systeme mit
x86-Architektur den Markt. Mit der zunehmenden Verbreitung von ARM-Prozessoren [12] bei
Mobiltelefonen und PDAs wird der Marktanteil der ARM-Systeme unter den Embedded Systems
immer größer. Besonders die Modelle der ARM7- und ARM9-Serien sind sehr erfolgreich. Die
Firma ARM stellt selbst keine Prozessoren her, sondern verkauft nur Prozessor-Designs, die
dann von weiteren Firmen umgesetzt werden. So gibt es z. B. Prozessoren mit ARM9-Design
von Philips [182], Atmel [16] und vielen anderen Firmen.
Neben ARM und x86 sind noch zahlreiche andere Prozessorarchitekturen anzutreffen. Recht verbreitet sind z. B. die von IBM [108] und Motorola [160] entwickelten PowerPC-Prozessoren. Die
MIPS-Architektur [157] ist oft in Netzwerkgeräten (z. B. Routern, NAS) anzutreffen.
3.2 Betriebssysteme
Die DIN 4430 definiert ein Betriebssystem als
die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der
Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechensystems bilden
und insbesondere die Abwicklung von Programmen steuern und überwachen.
Computersysteme bestehen aus einer großen Anzahl von Komponenten (Prozessor, Speicher,
Festplatten, Ein-/Ausgabeschnittstellen (IO), Bussysteme, Peripherie, . . . ). Die Koordination
3.2. BETRIEBSSYSTEME
25
all dieser Komponenten ist Aufgabe des Betriebssystems. Damit beim Zugriff von Anwendungsprogrammen auf die Hardware des Rechners keine Konflikte entstehen, unterbindet
das Betriebssystem einen direkten Zugriff auf die Hardware und stellt stattdessen definierte
Schnittstellen für den Zugriff auf die Hardwarekomponenten zur Verfügung. Es steht als
vermittelnde Schicht zwischen der Hardware des Rechners und den Systemdiensten und
Anwendungsprogrammen (siehe dazu Abbildung 3.1). Das Betriebssystem verwaltet alle zur
Verfügung stehenden Ressourcen. Die Verwaltung der auf dem System laufenden Prozesse
ist ebenfalls seine Aufgabe. Dabei weist es den einzelnen Prozessen auch die zur Verfügung
stehende Rechenzeit zu.
Applikationen
(Webbrowser, Textverarbeitung, etc.)
Anwendungsschicht
Systemdienste
(Druckdienst, Soundsystem, etc.)
Betriebssystem
Systemschicht
Computer− und Netzwerk−Hardware
(Prozessor, RAM, IO, etc.)
Abbildung 3.1: Schichten in einem Computersystem
Embedded Systems decken ein sehr breit gefächertes Leistungsspektrum ab. Für sehr einfache
Anwendungen, wie z. B. die Steuerung von Haushaltsgeräten, reichen preisgünstige Mikrocontroller aus (im Reiskocher z. B. 4-Bit-Mikrocontroller). Auf diesen Systemen wenig komplexen
Systemen läuft nur eine einzige recht einfache Applikation. Dafür wird kein Betriebssystem
benötigt. Je komplexer die Aufgabe des Embedded Systems wird, um so leistungsstärker muss
seine Hardware sein und um so mehr Aufgaben müssen parallel abgearbeitet werden. Dazu
werden dann entsprechende Betriebssysteme benötigt.
26
Für Systeme mit vielen Nutzerinteraktionen (z. B. in Navigationssystemen für PKWs) werden
vielfach spezielle Embedded-Versionen von Standard-Betriebssystemen eingesetzt, z. B. Embedded Windows CE oder Embedded Windows XP der Firma Microsoft [156].
Häufig müssen Embedded Systems Echtzeitanforderungen erfüllen. Echtzeitbetrieb wird in der
DIN 4430 (dort Realzeitbetrieb genannt) definiert als:
“Ein Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten
ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich
zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.”
Laut [145] und [232] wird von Echtzeitsystemen im Allgemeinen Rechtzeitigkeit, Gleichzeitigkeit und Verfügbarkeit gefordert:
Rechtzeitigkeit: Die Forderung nach Rechtzeitigkeit der Datenverarbeitung bedeutet, dass Eingabedaten rechtzeitig abgerufen werden müssen und dass die aus Eingabedaten ermittelten
Ausgabedaten rechtzeitig verfügbar sein müssen. [145]
Gleichzeitigkeit: Dies bedeutet, die Rechtzeitigkeit muss für mehrere Aktionen gleichzeitig gewährleistet sein. [232]
Verfügbarkeit: Echtzeitsysteme müssen unterbrechungsfrei betriebsbereit sein, da es sonst zu
Verletzungen von Zeitbedingungen kommen kann. [232]
Die Anforderungen an die Rechtzeitigkeit lassen sich noch in weiche und harte Echtzeit einteilen.
Weiche Echtzeitanforderungen bedeuten, dass Zeitfenster im Regelfall einzuhalten sind, eine Verletzung dieser aber in Ausnahmefällen tolerabel ist.
Beispiel: Für eine Videoübertragung reicht weiche Echtzeit aus. Überschreitungen der Zeitfenster führen zum Ruckeln der Bildübertragung. Der Prozess der Übertragung läuft jedoch weiter.
Bei harten Echtzeitanforderungen muss das vollständige Ergebnis auf jeden Fall im definierten
Zeitfenster vorliegen.
Beispiel: Die Motorsteuerung eines Autos arbeitet mit harten Echtzeitanforderungen. Ein
Überschreiten der Zeitfenster führt zum Stottern oder Ausgehen des Motors und kann deshalb
nicht toleriert werden.
Während sich weiche Echtzeitanforderungen auch mit Standardbetriebssystemen erreichen
lassen, benötigt man für harte Echtzeitanforderungen Betriebssystemerweiterungen wie z. B.
RTLinux der Firma FSMLabs [88] oder spezielle Realtime-Betriebssysteme wie z. B. VxWorks
von Windriver [226].
3.2. BETRIEBSSYSTEME
27
Angesichts des Kostendrucks bei Embedded Systems haben sich in den letzten Jahren zunehmend Open-Source-Betriebssysteme wie Linux oder das Ressourcen sparende Ecos [65]
etabliert. Im Folgenden sollen Linux-Systeme genauer betrachtet werden, da die komplette in
dieser Arbeit beschriebene Software unter Linux arbeitet.
Zentrales Element eines jeden Linux-Systems ist der Kernel. Die jeweils aktuelle Kernel-Version
kann unter [139] heruntergeladen werden. Der Großteil der Programme eines Linux-Systems
besteht aus freier Software, die von der Free Software Foundation [87] im Rahmen des GNUProjekts [89] entwickelt wurde.
Es gibt nicht das Linux, sondern sehr viele verschiedene Linux-Varianten, die als Distributionen bezeichnet werden. Die zur Zeit bekanntesten und erfolgreichsten Distributionen sind SUSE
[171], Red Hat [187], Debian [50] und das auf Debian basierende Ubuntu [212].
28
Kapitel 4
Verteilte Systeme
4.1 Definition für Verteilte Systeme
“Wir definieren ein verteiltes System als System, in dem sich Hardware- oder Softwarekomponenten auf vernetzten Computern befinden und nur über den Austausch von Nachrichten
kommunizieren und ihre Aktionen koordinieren.” [46]
Aus der obigen Definition ergeben sich nach [46] einige Systemeigenschaften:
Nebenläufigkeit: beschreibt die Eigenschaft, dass Aktionen kausal voneinander unabhängig
sind und somit unabhängig von einander ausgeführt werden können. [181]
In einem Computernetzwerk laufen im Regelfall verschiedene Programme auf verschiedenen Rechnern parallel und unabhängig voneinander. Dabei können im Bedarfsfall Ressourcen gemeinsam genutzt werden (z. B. Dateien oder Webseiten). Das funktioniert aber nur,
wenn nebenläufige Programme, die gemeinsame Ressourcen nutzen, koordiniert werden.
Fehlen einer globalen Uhr: Programme können im Netzwerk ihre Aktionen nur durch den
Austausch von Nachrichten koordinieren. Da die Genauigkeit, mit der Computer ihre Uhren im Netzwerk synchronisieren können, begrenzt ist, können Timingprobleme bei der
Koordination der Programme auftreten.
Unabhängige Ausfälle: In einem Netzwerk können sowohl einzelne Computer als auch die
Netzwerktechnik ausfallen. Die einzelnen Knoten des Netzwerks müssen auch im Falle
einer zeitweisen Isolation weiter funktionieren.
4.2 Grundsätzliche Anforderungen an Verteilte Systeme
Verteilte Systeme werden für deutlich andere Anwendungsfälle genutzt als Einzelrechner. Daher sind auch die Anforderungen an die Systeme deutlich andere. Für einen sinnvollen Betrieb
müssen verteilte Systeme nach [181] unter anderem folgende Anforderungen erfüllen:
29
30
KAPITEL 4. VERTEILTE SYSTEME
Transparenz: Mit Transparenz ist in diesem Zusammenhang gemeint, dass die Verteiltheit des
Systems verborgen bleibt und damit ein Teil der Komplexität des Systems für den Anwender und den Programmierer nicht sichtbar ist.
Skalierbarkeit: “Ein System, dass als skalierbar bezeichnet wird, bleibt auch dann effektiv,
wenn die Anzahl der Ressourcen und die Anzahl der Benutzer wesentlich steigt.” [46]
Wie stark ein verteiltes System wachsen kann, hängt dabei von vielen Faktoren ab. Ein
Ausbau kann eventuell dadurch erleichtert werden, dass innerhalb des verteilten Systems
Hierarchieebenen eingefügt werden und Subsysteme mit eigenen Netzwerken gebildet
werden.
Offenheit: Verteilte Systeme können sowohl im Bereich der Software als auch der Hardware heterogene Komponenten enthalten. Es ist außerdem oftmals notwendig, die Systeme
mit neuen Diensten und Komponenten zu erweitern. Um eine Kommunikation zwischen
unterschiedlichen Systemen zu ermöglichen, ist es notwendig, die Kommunikation über
standardisierte Schnittstellen und Protokolle abzuwickeln.
Sicherheit: “Mit zunehmender Verbreitung von verteilten Systemen und dem Anstieg der Bedeutung der Systeme bzw. der verarbeiteten Daten steigen die Anforderungen an die Sicherheit
in diesen Systemen im Bezug auf Datenschutz, Zugriffsschutz, Authentizität, usw.” [181]
4.3 Verteilte Regelungssysteme
Verteilte Regelungssysteme sind verteilte Systeme im Sinne der Informatik. Zusätzlich sind sie
dadurch gekennzeichnet, dass jede größere zu regelnde Komponente des Systems eine eigene
Regelungshardware hat. Dafür werden meist Embedded Systems verwendet, die über irgendeine
Form von Netzwerk miteinander kommunizieren können.
Beispiel:
Für verteilte Regelungssysteme ist die Regelungstechnik in modernen Automobilen ein Beispiel.
Dort können die Steuergeräte für die verschiedenen Systeme des Autos (Motor, Bremssystem,
etc.), welches typische Embedded Systems sind, durch einen Datenbus (z. B. FLEXRAY [85]
oder CAN [39]), der eine Form von Netzwerk darstellt, miteinander kommunizieren.
Die Aktionen der verschiedenen Regelungssysteme werden mittels Nachrichtenaustausch über
das Netzwerk koordiniert. Dadurch erlangen die verschiedenen Embedded Systems Informationen aus anderen Teilsystemen, die für die Regelung notwendig sind.
4.4 Anforderungen an verteilte Regelungssysteme
Zusätzlich zu den Anforderungen an verteilte Systeme müssen verteilte Regelungssysteme noch
weiteren Anforderungen genügen, die sich aus der Art und Weise ihrer Nutzung ergeben.
4.5. UNTERSCHIEDLICHE STRUKTUREN VON REGELUNGSSYSTEMEN
31
Verfügbarkeit: Verteilte Regelungssysteme müssen sehr zuverlässig und wartungsarm arbeiten.
Im Anwendungsfall von dezentralen Energiesystemen können sehr hohe Kosten entstehen,
wenn z. B. zum Austausch der Hardware weite Strecken zurückgelegt werden müssen.
Häufige Ausfälle von Hard- und Software sind deshalb auf keinen Fall hinnehmbar.
Verwaltbarkeit: Die Verwaltung eines verteilten Regelungssystems gestaltet sich immer aufwändiger als die eines zentral organisierten. So ist schon allein die Anzahl der Rechner, an
denen Wartungsarbeiten wie z. B. Softwareupdates für die IT-Sicherheit durchgeführt werden müssen, bei verteilten Systemen größer. Wie umfangreich der Verwaltungsaufwand für
ein verteiltes System ist, hängt stark von der Art des Systems ab. Werden für alle Knoten
die gleiche Hardware, das gleiche Betriebssystem und die gleiche Softwarebasis verwendet, können viele Verwaltungsprozesse automatisiert werden. Bei verteilten Systemen mit
extrem heterogener Hard- und Software müssen die einzelnen Knoten zu einem großen Teil
individuell gepflegt werden. Wegen des zu großen Wartungsaufwandes machen derartige
Systeme bei größeren Knotenzahlen keinen Sinn.
Anpassungsfähigkeit: Die Anforderungen an verteilte Regelungssysteme können sich während
des Zeitraums ihres Betriebes verändern. Daher ist es dringend notwendig, dass im laufenden Betrieb Softwareänderungen und Updates durchgeführt werden können, um neuen
Anforderungen gerecht zu werden. Ein weiterer wichtiger Faktor für die Anpassungsfähigkeit eines verteilten Systems ist der Umfang des zu betreibenden Aufwandes, um
dem System neue Knoten hinzuzufügen oder alte Knoten zu entfernen. Dieser Aufwand
kann stark minimiert werden, wenn Technologien zur automatischen Erkennung neuer
Komponenten und deren Integration in das Netzwerk eingesetzt werden.
4.5 Strukturunterschiede zwischen zentralistisch organisierten und verteilten Regelungssystemen
Zentralistisch organisierte Regelungssysteme (siehe Abb. 4.1) sind dadurch charakterisiert, dass
es nur eine einzige Regelungshardware gibt. Jede zu regelnde Komponente dieser Systeme wird
direkt von einem zentralen Regler angesteuert.
Versagt jedoch der zentrale Regler oder wird die Verbindung zwischen dem Regler und den
zu regelnden Komponenten unterbrochen, führt das unweigerlich zu einem Totalausfall des
Systems, da die zu regelnden Komponenten keinerlei dezentrale Intelligenz besitzen.
Vorteilhaft bei zentralistisch organisierten Regelungssystemen ist ein geringerer Wartungsaufwand als bei verteilten Systemen.
32
zentraler Server mit
zentralem Regler
zu regelnde
Geräte
Abbildung 4.1: Struktur eines Regelungssystems mit zentraler Regelungsinstanz
Verteilte Regelungssysteme können in ganz verschiedenen Strukturen organisiert sein. Allen
gemeinsam ist, dass für ihre zu regelnden Komponenten jeweils eine eigene Regelungshardware existiert. Diese führt die Regelung durch. Die verteilten Regler können mit Hilfe eines
Netzwerks Nachrichten untereinander austauschen und damit die für die Regelung notwendigen
Informationen erlangen. Neben Strukturen mit gleichberechtigten Reglern (siehe z. B. Abb. 4.2)
existieren auch Regelungsnetzwerke mit zusätzlichen zentralen Instanzen (siehe z. B. Abb. 4.3),
die übergeordnete Aufgaben, wie z. B. Optimierungsrechnungen, bewerkstelligen.
Verteilte Regelungssysteme können auch aus Reglern in verschiedenen Hierarchieebenen aufgebaut sein, die sich je nach Ebene mehr um übergeordnete oder lokale Regelungsaspekte kümmern.
dezentrale Regler
zu regelnde
Geräte
Abbildung 4.2: Struktur eines Regelungssystems mit verteilten Reglern
4.6. VORTEILE VERTEILTER REGELUNGSSYSTEME
33
zentraler Server
dezentrale Regler
zu regelnde
Geräte
Abbildung 4.3: Struktur eines Regelungssystems mit verteilten Reglern und einer zentralen Instanz
4.6 Vorteile verteilter Regelungssysteme
4.6.1 Maskierung von Komplexität
Ein komplexes Regelungssystem kann mit der Regelung verschiedenster Komponenten betraut
sein. Alle Komponenten besitzen verschiedene Eigenschaften und liefern ganz verschiedene
Informationen, aufgrund derer die Regelung stattfinden muss. Dabei ist es schwierig, alle
Informationen bis ins Detail auszuwerten und trotzdem nicht den Blick auf das Gesamtsystem
zu verlieren. Zur Lösung dieses Problems bietet sich die Nutzung einer hierarchischen Struktur
an. Dabei wird das Regelungssystem in lokale Regler für die einzelnen Komponenten aufgeteilt.
Diese Regler tauschen entweder untereinander oder auch mit einem zusätzlichen zentralen
Regler, der die übergeordnete Regelung durchführt, nur die Informationen aus, die für die
Regelung des Gesamtsystems notwendig sind. Nur lokal benötigte Informationen werden dabei
auch nur von den lokalen Reglern verarbeitet.
Bsp.: Ein Dieselgenerator, der Teil eines verteilten Regelungssytems aus verschiedenen Stromerzeugern und -verbrauchern ist, hat keinen Treibstoff mehr oder sein Motor ist defekt. Für die
übergreifende Regelung des Gesamtsystems reicht die Information “Gerät ist nicht verfügbar“
aus. Für den Generator als Subsystem hingegen ist die Ausfallursache wichtig, da die Entscheidung, welche Maßnahmen einzuleiten sind, davon abhängt.
34
4.6.2 Handling von Kommunikationsausfällen
Kommunikationsausfälle sind bei zentralistisch organisierten Regelungssystemen mit räumlich
voneinander getrennten Komponenten sehr folgenreich. Die verteilt platzierten Geräte können
beim Ausfall der Kommunikationsmittel überhaupt nicht mehr geregelt werden. Im Gegensatz
dazu kann ein verteiltes Regelungssystem mit Reglern für jede einzelne Komponente einen
Kommunikationsausfall teilweise kompensieren, indem ein Notprogramm, das auf lokal verfügbaren Informationen basiert, ausgeführt wird.
Bsp.: Bei dem im Abschnitt 15.2 beschriebenen Power Flow and Power Quality Management System werden die dezentralen Komponenten mit Hilfe von vernetzten Embedded Systems angesteuert. Dazu bekommen die dezentralen Embedded Systems von einem zentralen Server generierte
Fahrpläne übermittelt, mit deren Hilfe sie die Regelung durchführen. Bei einem Kommunikationsausfall kann der zentrale Server keine Fahrplankorrekturen mehr übermittlen. Der gerade
aktuelle Fahrplan kann aber trotzdem weiter abgearbeitet werden. Sollte nach Ablauf des Fahrplans immer noch keine Kommunikation möglich sein, schaltet der dezentrale Regler auf einen
Default-Fahrplan um, mit dem ein Notbetrieb durchgeführt wird, bis die Kommunikation wieder
hergestellt ist.
4.6.3 Lokale Lösungen von lokalen Problemen
In einem verteilten Regelungssystem können viele Regelungsaufgaben, die nicht die Regelung
des Gesamtsystems betreffen, lokal erledigt werden. Beim Auftreten von Fehlfunktionen
betreiben die Regler der Komponenten selbständig Fehleranalysen und generieren Fehlerreports,
die dann automatisch an Wartungspersonal verschickt werden. Die Regler können außerdem
entscheiden, ob ein Notbetrieb ihrer Komponenten möglich und sinnvoll ist.
Bsp.: Der dezentrale Regler eines Blockheizkraftwerks (BHKW) kann Drehzahlschwankungen
des Motors feststellen. Schon bei geringen Schwankungen schickt der Regler frühzeitig eine
Warnmeldung an Wartungspersonal. Durch rechtzeitige Wartung kann ein Totalausfall oftmals
unterbunden werden. Erfolgt keine Wartung, entscheidet der Regler aufgrund des Ausmaßes der
Drehzahlschwankungen über den Zeitpunkt der automatischen Abschaltung des BHKW.
4.6.4 Optimale Zusammenarbeit von Regler und zu regelnder
Komponente
Bei verteilten Regelungssystemen sollten Regler und zu regelnde Komponenten von einer
Firma hergestellt werden. In dem Fall kann der Hersteller bei der Reglerentwicklung auf sein
gesamtes Wissen über die zu regelnde Komponente zurückgreifen. Damit ist es möglich, die
Regelungsalgorithmen optimal an die zu regelnde Komponente anzupassen. Auch Schutzfunktionen können einfach implementiert werden, die im Falle einer Fehlbedienung der Komponente
diese vor einer Selbstzerstörung bewahren (Bsp.: Unterbinden von häufigen Start-Stopp-Zyklen
4.6. VORTEILE VERTEILTER REGELUNGSSYSTEME
35
bei Diesel-Generatoren). Durch seine Systemkenntnis ist der Hersteller befähigt, die Regelung
um Algorithmen zur Erkennung von Fehlfunktionen zu erweitern.
Bsp.: Der Hersteller eines Blockheizkraftwerks kennt alle Details der Abgasreinigung seines
Gerätes. Der von ihm mitgelieferte Regler kann anhand der Motorabgastemperatur auf den Zustand des Rußfilters schließen und einen Rußabbrand einleiten, wenn die Abgastemperatur zu
sehr ansteigt.
36
Kapitel 5
Anwendungsbeispiele für verteilte
Monitoring- und Regelungssysteme im
Energiesektor
5.1 Verteilte Regelungssysteme
5.1.1 Innovationsmotor Klimapolitik
Die Europäische Union hat sich im Rahmen der im Kyoto-Protokoll [144] definierten Ziele
verpflichtet, bis zum Jahr 2012 in ihren Mitgliedsländern eine CO2 -Reduktion von 8 % unter
das Niveau von 1990 zu erreichen [93]. Daraus ergeben sich für die einzelnen Mitgliedsländer
rechtsverbindliche Reduktionsziele. Deutschland hat sich verpflichtet, seinen CO2 -Ausstoß um
21 % zu senken.
Zur Umsetzung der CO2 -Reduktionsziele wurde von der EU der sogenannte European Strategic
Energy Technology Plan (SET PLAN) entwickelt [195]. Dieser sieht für das Jahr 2020 vor, dass
20 % der gesamten Primärenergie aus erneuerbaren Energiequellen (EEG) stammen soll. Dabei
wird aufgrund der technologischen Ausprägungen der größte Anteil auf die Erzeugung von
Elektroenergie entfallen.
Neben dem Ausbau der Nutzung regenerativer Energiequellen soll zum Erreichen der Klimaziele
auch die Effizienz der Nutzung konventioneller Energieträger gesteigert werden. Dazu hat z. B.
die deutsche Bundesregierung Ende 2007 in ihrem Energie- und Klimaprogramm (siehe [35])
beschlossen, den Anteil der Stromerzeugung durch Kraft-Wärme-Kopplung (KWK) von derzeit
rund 12 % bis zum Jahr 2020 auf 25 % zu verdoppeln.
Für das Jahr 2020 erwarten die Autoren der VDE-Studie “Smart Distribution 2020 – Virtuelle
Kraftwerke in Verteilungsnetzen“ [32] für die Stromerzeugung durch regenerative Energien und
die Kraft-Wärme-Kopplung einen Anteil von 50 %. Bis 2030 wird sogar eine Steigerung auf
75 % vorausgesagt.
37
38
KAPITEL 5. ANWENDUNGSBEISPIELE FÜR VERTEILTE SYSTEME
Die im Jahresmittel von EEG- und KWK-Anlagen erzeugte Leistung ist viel geringer als ihre maximal erreichbare Leistung (Peak-Leistung). Um mit diesen Anlagen einen entsprechend hohen
Anteil an der gesamten Stromerzeugung zu erzielen, müssen sie also stark ausgebaut werden.
Daraus ergibt sich das Problem, dass zu Schwachlastzeiten (z. B. in der Nacht oder am Wochenende) bei gleichzeitig starkem Wind und hoher KWK-Stromerzeugung ein Energieüberschuss
entsteht. Zum Abbau dieses Energieüberschusses bieten sich u. a. die beiden folgenden Strategien an:
1. Erzeugungsmanagement der EEG-/KWK-Anlagen, d. h. Anpassung der Erzeugung an den
Bedarf
2. Lastverschiebung durch dynamische Tarife
Technische Lösungen für die Umsetzung dieser Strategien gibt es bisher nur vereinzelt für große
Erzeuger und Verbraucher. Um die Klimaziele zu erreichen und gleichzeitig die Netzstabilität zu gewährleisten, werden aber in Zukunft auch Lösungen für kleine Erzeuger (z. B. private
Photovoltaik-Anlagen) und kleine Verbraucher (z. B. Haushalte) notwendig sein. Zum jetzigen
Zeitpunkt kann man schon voraussagen, dass die zukünftigen Energiemanagementsysteme mit
dezentraler Intelligenz arbeiten werden. Außerdem werden sie untereinander und mit zentralen
Informationsquellen vernetzt sein, d. h. sie werden als verteilte Regelungssysteme arbeiten.
5.1.2 Erzeugungsmanagement von EEG- und KWK-Anlagen
Für einen sicheren und zuverlässigen Netzbetrieb müssen die Betreiber von Übertragungsnetzen
Systemdienstleistungen wie Frequenzstabilität, Spannungsqualität und Blindleistungsregelung
erbringen. Prinzipiell können auch EEG- und KWK-Anlagen solche Dienste leisten. Die
bisherige Förderpolitik, die rein auf die Quantität der Stromerzeugung durch EEG und KWK
abzielt, sieht jedoch ein Erbringen von Systemdienstleistungen durch diese Anlagen nicht vor.
Mit wachsendem Anteil von EEG- und KWK-Anlagen bei der Stromerzeugung steigt also
die Notwendigkeit, für diese Systeme ein Erzeugungsmanagement zu implementieren, um sie
an den Systemdienstleistungen für die Stromnetze zu beteiligen. Dazu ist es notwendig, die
Systeme entweder direkt zu regeln oder über Anreizsysteme zu beeinflussen.
Zur Regelung der EEG- und KWK-Anlagen können verschiedene Technologien zum Einsatz
kommen. Ein Beispiel sind die heute schon vereinzelt realisierten sogenannten virtuellen Kraftwerke. Sie fassen große Anzahlen von dezentralen Stromversorgungseinheiten kleiner Leistung
mit Hilfe von Kommunikationsnetzen zu großen Erzeugern zusammen. Die Verfügbarkeit
von virtuellen Kraftwerken ist im Vergleich zu einzelnen großen Kraftwerken sogar deutlich
höher, da der Ausfall einzelner Teileinheiten kaum ins Gewicht fällt. Beim Handel mit der
erzeugten elektrischen Energie können virtuelle Kraftwerke wie konventionelle Kraftwerke am
Markt agieren. Sie erzielen für ihren Strom bessere Preise als voneinander unabhängige kleine
Erzeugungseinheiten.
5.1. VERTEILTE REGELUNGSSYSTEME
39
Eine bisher kaum praktizierte Möglichkeit zur Einflussnahme auf verteilte Erzeuger sind
Anreizsysteme mit je nach Energiebedarf wechselnden Einspeisevergütungen. In [32] wird
dazu vorgeschlagen, die Einspeisevergütung für EEG- und KWK-Anlagen an den Preisen
der Leipziger Strombörse European Energy Exchange (EEX) zu orientieren. Dadurch wäre
die Einspeisung zu Zeiten hohen Bedarfs deutlich lukrativer als zu Schwachlastzeiten. Ein
verstärkter Betrieb der Anlagen zu Starklastzeiten wäre die Folge.
Durch Aufschläge auf die EEX-Preise könnten mit diesem Modell die gleichen Renditen wie
bei den heutigen Tarifmodellen erzielt werden, so dass für die Betreiber der Anlagen keine
Nachteile entstünden. Die Aufschläge könnten in zyklisch wiederkehrenden Schwachlastzeiten
(z. B. von ein Uhr bis fünf Uhr nachts) ausgesetzt werden, um Erzeugungsspitzen zu vermeiden.
Sowohl das Betreiben von virtuellen Kraftwerken als auch die Nutzung von variablen Tarifsystemen funktionieren nur, wenn die Erzeugungseinheiten über Kommunikationsschnittstellen
verfügen, über die sie mit Informationen (Fahrpläne, Tarifinformationen, etc. ) versorgt werden,
die für den Betrieb notwendig sind. Diese Kommunikationsschnittstellen können für weitere
Aufgaben, z. B. Fernwartungsfunktionen, genutzt werden. Da die Besitzer und Betreiber der
Anlagen oft nur sehr wenig über die technischen Hintergründe der Anlagen wissen, sind
für einen kostengünstigen Betrieb solche Fernwartungsfunktionen sehr hilfreich. Durch ein
ständiges Erfassen der Betriebsdaten mittels verteilter Monitoringsysteme lassen sich belastbare
Aussagen über den Zustand der Anlagen treffen. Dadurch können notwendige Wartungs- und
Reparaturarbeiten frühzeitig eingeleitet und größere Schäden vermieden werden. Der Betrieb
der Anlagen wird durch das Monitoring kostengünstiger.
5.1.3 Zeitliche Lastverschiebung durch dynamische Tarife
Durch den zunehmenden Anteil von EEG- und KWK-Erzeugern treten stärkere Schwankungen
bei der Stromproduktion auf. Die Betreiber der Übertragungsnetze müssen diese Fluktuationen
ausgleichen. Das geschieht im Allgemeinen mit regelbaren Kraftwerken. Der Betrieb solcher
Kraftwerke ist aufwändig und energetisch nicht sinnvoll, da sie einen hohen Primärenergiebedarf
haben. Das Vorhalten von großen Regelenergiereservern ist außerdem volkswirtschaftlich nicht
vertretbar, da die dafür eingesetzten Kraftwerke nur kurzeitig genutzt werden und für die
sonstige Produktion nicht zur Verfügung stehen.
Zur Anpassung der Lasten an die jeweilige Erzeugungssituation ist deshalb eine Flexibilisierung
der Verbrauchssituation anzustreben.
Es ist zu aufwändig, die Lasten der meisten gewerblichen und erst recht der Haushaltskunden
durch eine zentrale Instanz (z. B. die Leitwarte eines Stromversorgers) schalten zu lassen [32].
40
Lastverschiebungen können anstelle von direktem Ansteuern der Lasten auch durch dynamischen Tarife erreicht werden. Dabei ändern sich die Strompreise in Abhängigkeit von Angebot
und Nachfrage. Der Handlungsanreiz für den Kunden besteht darin, Kosten zu sparen, indem er
Teile seiner Verbräuche in Zeiten geringer Strompreise verlegt. Ein automatisiertes Auswerten
der Tarifsignale durch Energiemanagementsysteme erzielt dabei die größten Ersparnisse.
Die Einführung von variablen Tarifen wird von der EU in einer Endenergieeffizienzrichtlinie
[80] forciert. Diese Richtlinie wird zurzeit auch in nationales Recht umgesetzt. So heißt es
im Paragraph 40 der Beschlussempfehlung zum Entwurf eines Gesetzes zur Öffnung des
Messwesens bei Strom und Gas für den Wettbewerb vom 04.06.2008 [36] :
”Energieversorgungsunternehmen haben, soweit technisch machbar und wirtschaftlich zumutbar, bis zum 30. Dezember 2010 für Letztverbraucher von Elektrizität einen Tarif anzubieten,
der einen Anreiz zur Energieeinsparung oder Steuerung des Energieverbrauchs setzt. Tarife im
Sinne von Satz 1 sind insbesondere lastvariable und tageszeitabhängige Tarife“.
Dynamische Tarife führen nur dann zu Lastverschiebungen, wenn die Preis-Spreizung zwischen
den verschiedenen Tarifstufen ausreichend groß und damit ein echter Anreiz zur Verschiebung
gegeben ist [86]. Das lässt sich seitens der Stromversorger wirtschaftlich sehr wahrscheinlich nur
dann realisieren, wenn die Grundgebühren angehoben werden [32].
5.2 Verteilte Monitoringsysteme
5.2.1 Energieverbrauchs-Monitoring im gewerblichen Bereich
Steigende Energiepreise und ein wachsendes Umweltbewußtsein machen es auch im gewerblichen Bereich immer mehr erforderlich, Daten über Energieverbräuche zu sammeln, um damit zu
ermitteln, welche Verbraucher wieviel Energie konsumieren. Nur wenn detaillierte Verbrauchsdaten vorliegen, ist es möglich Ineffizienzen aufzudecken und Energieverbräuche zu senken. Das
Sammeln von Verbrauchsdaten geschieht dabei oftmals mit verteilten Monitoringsystemen, die
Messdaten lokal aufnehmen und per Internet an zentrale Server übermitteln. Auf den zentralen
Servern analysiert eine Energy Data Management-Software (EDM-Software) die Messdaten.
Diese Software beinhaltet eine Fülle von Funktionen, wie z. B. Messdatenplausibilisierung,
Trendanalyse, Generieren von Reports und Visualisierung.
Als Anwendungsbeispiel für die Nutzung verteilter Monitoringsysteme soll hier der Einzelhandel angeführt werden. Die drei größten Einzelhandelsunternehmen der Welt, Wal-Mart Stores
Inc., Tesco Plc. und Carrefour, führen mittlerweile ein Energiemonitoring ihrer Filialen durch.
Tesco Plc. z. B. setzt in allen seinen britischen Filialen, die unter den Namen Tesco und Asda betrieben werden, Monitoringsysteme der belgischen Firma EnergyICT N.V. [73] für das Erfassen
von Verbrauchsdaten ein. In den Filialen befinden sich dazu handelsübliche Messgeräte, die die
Verbräuche messen. Datenkonzentratoren von EnergyICT lesen die Messgeräte per Impulszäh-
5.2. VERTEILTE MONITORINGSYSTEME
41
ler oder per Feldbus (z. B. M-Bus) aus und aggregieren die Messwerte. Zur Datenübertragung an
die zentralen Auswertungsserver wählen sich die Datenkonzentratoren über das Mobilfunknetz
in das Internet ein. Die Datenübertragung erfolgt dann verschlüsselt per Hypertext Transfer Protokoll (HTTP).
5.2.2 Smart-Metering-Systeme
Die im Abschnitt 5.1.1 genannten Klimaziele sollen nicht allein durch Fortschritte bei der
Energieerzeugung erreicht werden. Zusätzlich dazu hat die Europäische Union das Ziel gesetzt,
den Energieverbrauch in ihren Mitgliedsländern nachhaltig zu verringern. Dazu werden den
Mitgliedsstaaten durch die Richtlinie 2006/32/EG über Endenergieeffizienz und Energiedienstleistungen vom 05. April 2006 (EDL-RL) [80] Energie-Sparziele vorgegeben. Die Staaten sollen
innerhalb von neun Jahren nach Inkrafttreten der Richtlinie Energieeinsparungen von neun
Prozent im Vergleich zum durchschnittlichen Endenergieverbrauch der Jahre 2001 bis 2005
erreichen. Das soll im Wesentlichen durch Energiedienstleistungen und andere Energieeffizienzmaßnahmen auf der Nachfrageseite geschehen.
Zur Erhöhung der Energieeffizienz beim Endkunden fordert die Richtlinie:
“Soweit es technisch machbar, finanziell vertretbar und im Vergleich zu den potenziellen Energieeinsparungen angemessen ist, stellen die Mitgliedstaaten sicher, dass alle Endkunden in den
Bereichen Strom, Erdgas, Fernheizung und/oder -kühlung und Warmbrauchwasser individuelle
Zähler zu wettbewerbsorientierten Preisen erhalten, die den tatsächlichen Energieverbrauch
des Endkunden und die tatsächliche Nutzungszeit widerspiegeln.”
Bei der Umsetzung der Richtlinie in nationales Recht im Jahr 2008 soll definiert werden, welche
Informationen die Zähler liefern müssen. Als sicher kann gelten, dass die im Elektrizitätsbereich
bisher meist anzutreffenden “Ferraris”-Zähler den neuen Anforderungen nicht gerecht werden.
Dadurch wird zwangsläufig eine Umstellung auf elektronische Zähler notwendig. Um für die
Kunden mehr Transparenz hinsichtlich ihres Energieverbrauchs zu schaffen, sollen monatliche
Rechnungen oder zumindest monatlich Informationen über den Energieverbrauch erstellt
werden. Das ist jedoch nur möglich, wenn die Zähler in irgendeiner Form informationstechnisch
vernetzt sind und die Verbrauchswerte zu einer zentralen Instanz übermitteln können – sogenanntes smart metering.
Für den Endkunden steigt die Transparenz seiner Verbräuche mit der zeitlichen Auflösung der
zur Verfügung stehenden Verbrauchswerte. Je höher die Auflösung, desto mehr kann der Energiekunde über sein Verbrauchsverhalten erfahren und desto nachhaltiger wird er sein Verhalten
ändern, um Energie einzusparen. Da monatliche Verbrauchsinformationen dem Verbraucher
kaum ausreichende Grundlagen für eine Verbrauchsanalyse liefern, bleibt zu hoffen, dass sich
smart metering-Systeme durchsetzen werden, die Schnittstellen für lokale Feedback-Systeme
besitzen oder zumindest per Internet zeitlich hoch aufgelöste Daten bieten.
42
Ein Beispiel für ein smart metering-System mit einem lokalen Feedback-System ist die vom
Fraunhofer ISE im Rahmen eines Forschungsprojekts für den Strom-, Erdgas- und Telekommunikationsanbieter EWE [81] entwickelte EWE-Box. Sie ist ein Embedded System, das per
M-Bus Messgeräte für Strom und Gas ausliest. Die Messdaten werden per DSL über eine
VPN-Verbindung an einen zentralen Datenabrufserver übermittelt. Zusätzlich stellt das System
die Verbrauchsdaten einem per Funkschnittstelle (Zigbee) angebundenen mobilen Display (siehe
Abb. 5.1) zur Verfügung. Das Display stellt die Daten sowohl zeitlich hoch aufgelöst (minütlich)
als auch kumuliert (z. B. als Tageswerte) dar. Dabei werden nicht nur die Verbräuche, sondern
auch die damit verbundenen Kosten und die CO2 -Emissionen dargestellt.
Abbildung 5.1: Display des vom Fraunhofer ISE entwickelten smart-metering-Systems
EWE-Box
Für eine flächendeckende Einführung von smart metering-Systemen sollten möglichst folgende
Anforderungen erfüllt werden:
• Die Systeme sollten mit offenen Schnittstellen und Standards arbeiten. Dadurch werden
proprietäre Strukturen vermieden, die zwangsläufig zu einer Herstellerbindung führen würden.
• Eine Interoperabilität zwischen Teilsystemen verschiedenen Hersteller von smart metering-Technologie sollte gegeben sein.
5.2. VERTEILTE MONITORINGSYSTEME
43
• Es sollte eine logische und gerätetechnische Trennung zwischen Messeinrichtungen und
Kommunikationsinfrastruktur vorliegen. Im Normalfall ist Messtechnik deutlich langlebiger als Kommunikationstechnik. Durch eine Trennung dieser Teilsysteme können alte
Messeinrichtungen mit neuen Kommunikationssystemen kombiniert werden.
• Die Systeme müssen skalierbar sein, d. h. ein Betrieb von sehr vielen Einheiten muss
problemlos möglich sein.
Laut Bolder [28] gab es Mitte 2006 in Europa kein einziges smart metering-System, das die
oben genannten Anforderungen erfüllt. Zur Zeit gibt es in Deutschland mehrere miteinander
kooperierende Arbeitsgruppen und Gremien, die um eine Standardisierung von smart meteringSystemen bemüht sind:
1. Multi-Utility-Communication (MUC)
2. Smart Metering Initiative Querverbund (SMIQ)
3. Open Metering Communication (OMC)
Multi-Utility-Communication (MUC)
Die MUC-Gruppe besteht seit Anfang 2007. Sie wurde vom Verband der Netzbetreiber e. V.
(VDN) [216] beim Bundesverband der Energie- und Wasserwirtschaft e. V. (BDEW) [19] initiiert. Ziel der Gruppe ist die Erstellung eines herstellerübergreifenden Standards für die Kommunikation von Gas-, Wasser- und Wärmemengenzählern. Die Spezifikation deckt den gesamten
Bereich der Kommunikation vom Messgerät bis zum Endsystem ab. Kernstück ist dabei der sogenannte MUC-Controller, der als ein eigenständiges Gerät Messdaten drahtgebunden oder per
Funktechnologie von den Zählern abruft und dann per Internet sowohl den Kunden als auch den
Versorgungsunternehmen zur Verfügung stellen soll.
Smart Metering Initiative Querverbund (SMIQ)
Den Stadtwerken, die die SMIQ bilden, geht es im wesentlichen um die Mehrspartenfähigkeit
der neuen Technik. Sie wollen zusammen mit der MUC-Gruppe Mindestanforderungen festlegen
und den Herstellern für die Weiterentwicklung ihrer Systeme vermitteln.
Open Metering Communication (OMC)
OMC ist ein Zusammenschluss von Messgeräteherstellern, die in den beiden BranchenDachverbänden Bundesvereinigung der Firmen im Gas- und Wasserfach e.V. (figawa) und Zentralverband Elektrotechnik und Elektronikindustrie e.V. (ZVEI) [243] organisiert sind. Ziel der
Gruppe ist es, die Anforderungen der Anwender mit Hilfe von möglichst schon bestehenden
Standards zu erfüllen und in Produktspezifikationen umzusetzen. Besonderes Augenmerk wird
dabei auf die Spezifikation der Kommunikationsschnittstellen für den Nahbereich gelegt. Außerdem beschäftigt sich die Gruppe mit dem Transport der Daten von den Liegenschaften zu den
Marktteilnehmern.
44
Kapitel 6
Kommunikationsnormen und -protokolle
für verteilte Regelungssysteme
6.1 Bedeutung normierter Kommunikation
Verteilte Regelungssysteme können nur dann funktionieren, wenn die einzelnen Regler der Teilsysteme miteinander kommunizieren können. Dazu ist grundsätzlich zunächst ein Kommunikationsmedium notwendig. Die einzelnen Geräte benötigen für eine sinnvolle Kommunikation
darüber hinaus ein gemeinsames Kommunikationsprotokoll, d. h. sie müssen eine Art gemeinsame Sprache “sprechen”. Während Geräte eines einzelnen Herstellers unter Einsatz seiner proprietären Protokolle sinnvoll zusammenarbeiten können, ist für eine Interoperabilität zwischen
Produkten verschiedener Hersteller eine normierte Kommunikation notwendig.
6.2 Kommunikation in der elektrischen Energieversorgungstechnik
In der elektrischen Energietechnik finden sehr viele verschiedene Bussysteme und Protokolle
Anwendung. Für die Kommunikation in Schaltanlagen werden z. B. neben Profibus [183],
Modbus [158], Distributed Network Protocol DNP [59] auch komplett proprietäre Systeme
verwendet. Dadurch wird eine Interoperabilität zwischen Geräten verschiedener Hersteller
erschwert oder sogar ganz unmöglich.
Mit der seit dem Jahr 2005 verfügbaren Normenreihe IEC61850 versucht die International
Electrotechnical Commission (IEC) [111] eine Standardisierung der gesamten Kommunikation
in Schaltanlagen durchzusetzen [194]. Die Wichtigkeit dieses Vorhabens zeigt sich schon
allein durch die am Standardisierungsprozess beteiligten Firmen. Bei der Normung arbeiten
sowohl Stromversorgungsunternehmen, z. B. die Firmen EDF [67], EON [74], RWE [188],
ENEL [72], als auch Technologie-Konzerne wie z. B. ABB [1], Alstom [6] und Siemens [196] mit.
45
46
KAPITEL 6. GENORMTE KOMMUNIKATION
Die Normung soll den freien Einsatz von Komponenten unterschiedlicher Hersteller von Leitund Schutztechnik ermöglichen. Durch Modularität und einheitliche Schnittstellen sind Wettbewerbsverbesserungen und Vereinfachungen bei Erweiterungen und Umbauten von Anlagen zu
erwarten. Dadurch sind Kostenersparnisse zu erzielen.
Bei Investitionen in neue Anlagen entfallen bis zu 30% der Investitionskosten auf das Engineering [97]. Die Vereinfachung des Engineering-Prozesses ist deshalb ein weiteres Ziel der
Normung. Es soll z. B. ermöglicht werden, Parametriersoftware unabhängig vom Hersteller der
zu parametrierenden Anlagen zu nutzen. Zur Realisierung diese Ziels definiert die IEC 61850 ein
objektorientiertes Datenmodell, das über die reine Kommunikation weit hinausgeht. Die im Teil
6 der Norm definierte Substation Configuration Description Language (SCL) ermöglicht eine
vollständige Beschreibung von Schaltanlagen auf der Basis von XML. Sie wird während des
Engineering-Prozesses genutzt, um neue Anlagen zu planen. Später dient sie der Konfiguration
und Inbetriebnahme. Auch im laufenden Betrieb kann sie genutzt werden, um Informationen
über die Anlagen zu erlangen, ohne einen direkten Zugriff auf diese zu haben.
Informationen über Systeme und Komponenten werden immer komplexer. Mit steigender
Komplexität wird es notwendig, Informationen direkt aus den Systemen auslesen zu können.
Dazu braucht man sogenannte Metadaten. Das sind Daten, die die aus den Geräten auslesbaren
Informationen beschreiben. Ein Beispiel für eine solche Information ist die Einheit eines
Messwertes. Kann die Einheit direkt aus dem entsprechenden Gerät ausgelesen werden, wird
verhindert, dass ein Gerät Messwerte in Prozent abspeichert und ein auslesendes Gerät die
Messwerte als Absolutwerte interpretiert. Zu den benötigten Metadaten gehören eindeutige
Benennungen, Formatbeschreibungen, SI-Einheiten, Skalierungen etc. In der IEC 61850 wird
deshalb mit mehrfach hierarchischen Datenmodellen gearbeitet. Diese werden in den Teilen
7-1 bis 7-4 der Norm definiert, die außerdem auch die dazugehörigen Kommunikationsdienste
festlegt. Die Metadaten können sowohl während des Betriebs aus den Schaltanlagen ausgelesen
werden, als auch aus den Systembeschreibungen entnommen werden, die in der Substation
Configuration Description Language vorliegen.
Eine sehr wichtige Eigenschaft der IEC 61850-Normenreihe ist die schon in [97] geforderte
strenge Trennung zwischen abstrakten Methoden zum Informationsaustausch und den Abbildungen (Mappings) dieser abstrakten Methoden auf verschiedene Anwendungsprotokolle. Durch
diese Vorgehensweise kann die Normenreihe bei Bedarf um weitere Kommunikationsstacks
erweitert werden, ohne Änderungen an den abstrakten Methoden zum Informationsaustausch
vornehmen zu müssen. Wie sinnvoll die Trennung ist, zeigte sich schon mit der Erweiterung
der IEC 61850 um die IEC 61400-25-4 zur Kommunikation mit Windenergie-Anlagen. Um
mit diesen Anlagen kommunizieren zu können, erwiesen sich die bis dahin verfügbaren
Mappings der abstrakten Kommunikationsmethoden auf Webservices und die Manufacturing
Message Specification MMS als nicht ausreichend. Zusätzlich wurden deshalb Mappings für
OPC XML DA, IEC 60870-5-101 und das Distributed Network Protocol (DNP) 3.0 definiert.
6.3. KOMMUNIKATION IN DER AUTOMATISIERUNGSTECHNIK
47
Eine andere Erweiterung der IEC 61850-Normenreihe – zur Zeit noch in der Entwicklung
– ist die IEC 61850-7-420 (siehe [57]). Dieser Teil der Norm befasst sich mit verteilten
Erzeugern wie z. B. Photovoltaikanlagen und Blockheizkraftwerken. Beim Betrieb von Smart
Grids werden verteilte Erzeuger eine wichtige Rolle spielen. Smart Grids sind Stromnetze, die
durch den Einsatz von Kommunikationstechnik, Sensorik und verteilten Regelungssystemen
energieeffizienter, zuverlässiger und sicherer arbeiten sollen, als dies bei den heutigen Netzen möglich ist. Eine zunehmende Durchdringung der Niederspannungsnetze mit verteilten
Erzeugern und die daraus resultierenden bidirektionalen Energieflüsse müssen zwangsläufig
zu einer Umstellung der elektrischen Verteilnetze hin zu Smart Grids führen. Interessant in
diesem Zusammenhang sind auch Bestrebungen der Deutschen Gesellschaft für Solarenergie
e. V. [54], die Batteriekapazitäten von an das Stromnetz angeschlossenen Elektrofahrzeugen,
sog. plug-in-cars, zum Ausgleich von Netzschwankungen zu nutzen. Dazu soll auch die IEC
61850-7-420 genutzt werden [198].
Für die Zukunft sind Erweiterungen der IEC 61850 geplant, um die Kommunikation für weitere
Bereiche der elektrischen Energieversorgung zu standardisieren. Zur Zeit wird die Edition
2 der IEC 61850 von den Normungsgremien bearbeitet [102]. Mit dieser Edition werden
Erweiterungen für Power Quality, IT-Security und ein Internet-basiertes System zur Erfassung
von Fehlermeldungen erwartet. Ein durchgängiges Datenmodell für alle Anwendungen wird es
sicher nie geben, so dass die Normungsgremien auch in Zukunft Erweiterungen der Normenreihe
durchführen müssen.
Ob sich die IEC 61850 für alle Kommunikations-Ebenen durchsetzen wird, ist fraglich, da es
Konkurrenz durch bereits etablierte andere Normen gibt. Innerhalb von Netzleitstellen wird z. B.
per IEC 61970 und IEC 61968 kommuniziert. Für die Kommunikation zwischen Leitstellen
kommt oft die IEC 60870-6 (auch als TASE.2 oder ICCP bekannt) zum Einsatz. Ein Nachteil
dieser Normen ist jedoch, dass sie unterschiedliche Datenmodelle nutzen [63]. Eine durchgängige Anwendung der IEC 61850 wäre deshalb wünschenswert.
6.3 Kommunikation in Automatisierungstechnik mit OLE for
Process Control
In der Automatisierungstechnik gibt es eine große Anzahl standardisierter Kommunikationslösungen. Dabei steht laut [193] sowohl bei den Feldbussen als auch bei Lösungen, die auf Ethernet
basieren, die Standardisierung der unteren Schichten des ISO/OSI-Schichtenmodells im Vordergrund. Die oberen Schichten werden hingegen meistens vernachlässigt. Es gibt folglich sehr viele
verschiedenen Konzepte, mit denen die Kodierung der zu übertragenden Daten realisiert wird.
Bei den Feldbussen existieren jedoch auch Gemeinsamkeiten. Die meisten von ihnen übertragen
die Datentypen Bit, Integer und Floating-Point sowie Arrays, die aus den Datentypen gebildet
werden. Da kaum komplexere Datentypen als diese vorkommen, ist eine Realisierung von Gateways zwischen verschiedenen Feldbussen möglich. Sie ist jedoch sehr kostenintensiv.
48
6.3.1 OLE for Process Control (OPC)
Um aus Regler-, Sensorik- und Aktorikbausteinen verschiedener Hersteller ein gemeinsames
Netzwerk realisieren zu können, wurde 1996 von der OPC Task Force, einem Zusammenschluss
verschiedener großer Firmen aus der Automatisierungsindustrie, OLE for Process Control (OPC)
[172] entwickelt [173]. OLE steht dabei für die von Microsoft [156] entwickelte Object Linking
and Embedding-Technologie, die einen Datenaustausch zwischen verschiedenen Applikationen
ermöglicht. Sie wird eingesetzt, um Dokumente aus verschiedenen Datentypen zu realisieren.
OPC stellt eine einheitliche Schnittstelle zwischen Windows-Applikationen und der Regelungsund Messhardware dar. Um OPC nutzen zu können, müssen die Hardware-Hersteller für ihre
Hardware sogenannte OPC-Server implementieren. Die Windows-Applikationen fungieren
dann als OPC-Clients.
Ein großer Nachteil von OPC ist seine Bindung an das (Distributed) Component Object Model
(COM/DCOM). Dabei handelt es sich um ein objektorientiertes System für Remote Procedure
Calls. Diese werden genutzt, um Funktionen auf anderen Rechnern aufzurufen und damit deren
Funktionalität zu nutzen. COM/DCOM ist nur für die Betriebssysteme der Firma Microsoft
[156] verfügbar. Für Entwickler von OPC-Software gibt es keinen Zugang zu den Softwarequellen von COM/DCOM. Sie sind damit Fehlern in der COM/DCOM-Sofware ausgeliefert.
Aufgrund der Bindung an COM/DCOM gibt es nur relativ wenige OPC-Implementationen für
andere Betriebssysteme. Für Linux-Betriebssysteme vertreibt die Firma Matrikon Inc. [150]
OPC-Software. Die Nutzung dieser Software ist jedoch sehr kompliziert und kostspielig. Für
die in dieser Arbeit betrachteten Regelungs- und Monitoringsysteme auf Linux-Basis kam die
Nutzung von OPC deshalb nicht in Betracht, zumal für die verwendete Sensorik und Aktorik
auch keine OPC-Server für Linux verfügbar sind.
6.3.2 OPC Unified Architecture (OPC UA)
Kurz nach der Herausgabe einer ersten Spezifikation wurde die OPC-Foundation [172] gegründet, die seitdem die Pflege und Weiterentwicklung des Standards betreibt. Um die Bindung
von OPC an Betriebssysteme von Microsoft und die damit verbundenen Probleme zu lösen,
wurde im Herbst 2006 eine neue Spezifikation, die OPC Unified Architecture (OPC UA)
verabschiedet. OPC-UA verwendet statt COM/DCOM einen eigenen Kommunikationsstack.
Bei der Konzeption des Stacks wurde auf Skalierbarkeit und Portabilität geachtet, so dass
OPC-UA z. B. auch auf Embedded Systems einsetzbar ist. Die Datenübertragung im Netzwerk
kann mit zwei unterschiedlichen Protokollen auf TCP-Basis erfolgen. Das erste Protokoll
ist ein binäres Protokoll, mit dem Daten sehr effizient und ressourcenschonend übertragen
werden können. Insbesondere für den Einsatz auf Embedded Systems ist das sehr wichtig. Das
zweite Protokoll arbeitet mit dem XML-basierten Simple Object Access Protocol (SOAP) als
Webservice. Für Webservices gibt es eine große Anzahl von Softwaretools. Sie werden auch von
vielen Programmiersprachen (z. B. Java und .net) sehr gut unterstützt.
6.4. KOMMUNIKATIONSPROBLEME DURCH UNZUREICHENDE NORMUNG
49
Mit seiner guten Skalierbarkeit und offenen Architektur ist OPC UA ein interessanter Standard
für den Betrieb von dezentralen Energiesystemen. Besonders die Möglichkeit zum Einsatz auf
Embedded Systems mit ganz unterschiedlichen Betriebssystemen und Systemarchitekturen lässt
einen Einsatz im Bereich der Energiesysteme sinnvoll erscheinen. Auch die Verfügbarkeit von
Entwicklungstools, z. B. direkt durch die OPC-Foundation, und die Unterstützung zahlreicher
Programmiersprachen kann sicher zur Verbreitung von OPC UA beitragen.
6.4 Probleme bei der Kommunikation durch unzureichende
Normung
Die Normung von Kommunikation erleichtert heute in vielen Bereichen die Interoperation
zwischen ganz verschiedenen technischen Systemen. Leider gibt es jedoch auch Bereiche, in
denen bisher gar keine oder nur eine sehr unzureichende Normung stattgefunden hat.
Ein Beispiel für Geräte mit unzureichenden Kommunikationsinterfaces sind Blockheizkraftwerke (BHKWs) für Privathaushalte oder das Kleingewerbe. Derartige Geräte verfügen meist über
eine vom Hersteller entwickelte Regelung, die nur wenig Möglichkeiten zur Kommunikation
mit z. B. Energiemanagementsystemen bietet. Die Schnittstellenausstattung beschränkt sich in
den meisten Fällen auf Relaiskontakte oder einfache Industrieschnittstellen wie z. B. ein 010V-Interface). Damit können nur die einfachsten regelungstechnischen Aufgaben durchgeführt
werden. Selbst die rudimentären Schnittstellen gehören nicht unbedingt zur Serienausstattung
der Geräte, so dass sie bei Bedarf kostspielig nachgerüstet werden müssen. Sollen BHKWs
dieser Kategorie durch eine übergreifende externe Regelung angesprochen werden, bedeutet das
immer, dass eine speziell für den Gerätetyp zugeschnittene Treibersoftware entwickelt werden
muss.
Ein weiteres Problem der Nutzung genormter Kommunikation stellen schlecht spezifizierte
Normen und schlechte Implementationen der in den Normen festgeschriebenen Standards dar.
Der in den europäischen Normen EN13757-2 und EN13757-3 beschriebene M-Bus (siehe auch
Abschnitt 15.1.3) ist ein anschauliches Beispiel für solche Probleme. Diese Normen sind an
verschiedenen Stellen nicht eindeutig definiert, so dass man bei verschiedenen Herstellern von
M-Bus-Geräten sich widersprechende Implementationen der Norm findet. Das führt dazu, dass
Auslesesoftware, die eigentlich universell für alle M-Bus-Geräte funktionieren sollte, manche
Geräte nicht auslesen kann. Einige M-Bus-Geräte verhalten sich aber auch ganz offensichtlich
nicht konform zu den Normen. Die im Abschnitt 15.1.3 gezeigten F96-Wärmemengenzähler
der Firma ELSTER Messtechnik GmbH [71] wechseln z. B. mitten im Betrieb ohne ersichtlichen Grund die Übertragungsrate. Dem Hersteller ist dieses Verhalten der Zähler bekannt.
Er unternimmt aber keine Anstalten, daran etwas zu ändern, da der Datenratenwechsel nur
bei sehr häufigem Auslesen der Zähler auftritt, was bei den allermeisten Anwendungen nicht
der Fall ist. Dennoch ist das Verhalten der Zähler nicht normkonform. Für das im Abschnitt
15.1 beschriebene verteilte Monitoringsystem musste deshalb die Auslesesoftware um eine
50
Resetfunktion für die F96-Wärmemengenzähler erweitert werden, damit ein zuverlässiges
Auslesen der Geräte gewährleistet werden kann.
Um Konkurrenzprodukte inkompatibel zu machen und damit das eigenen Software- und
Hardware-“Ökosystem” vor Mitbewerbern zu schützen, wandeln manche Hersteller bewusst
Kommunikationsprotokolle geringfügig ab. Der M-Bus wurde z. B. von den Firmen Texas Instruments Inc. [206] und Techem AG [205] sowie der Universität Paderborn [213] entwickelt.
Dennoch be- und vertreibt die Techem AG Auslesesysteme, die ein etwas abgewandeltes Protokoll nutzen, um Mitbewerbern das Auslesen von Techem-Messtechnik zu erschweren. Dadurch
können Techem-Kunden nicht so leicht zu einem anderen Dienstleister wechseln.
Kapitel 7
Stand der Internet-Technik für Verteilte
Systeme
In der Gebäuderegelung, der Automatisierungstechnik und allgemein im Bereich räumlich
verteilter Installationen gibt es zahlreiche Bussysteme und Übertragungsprotokolle für die
Kommunikation zwischen verschiedenen Anlagenteilen (z. B.: EIB [69], LON [148][62],
BACNET [18]. Der große Vorteil dieser Bussysteme und Übertragungsprotokolle ist, dass ihnen
die technisch mögliche Übertragungsbandbreite exklusiv für ihre Zwecke zur Verfügung steht.
Dem stehen jedoch große Nachteile hinsichtlich der Wirtschaftlichkeit und der Interoperabilität
zwischen Produkten verschiedener Hersteller gegenüber.
In den letzten Jahren ist ein Trend hin zur Verwendung standardisierter Internet-Technologie
zu beobachten. Die entsprechenden Geräte werden in sehr großen Stückzahlen gefertigt und
sind deshalb sehr preiswert. Zur Datenübertragung werden die Protokolle der TCP/IP-Familie
(siehe [46]) genutzt. Es existiert eine große Anzahl von Kommunikationsmedien, die TCP/IP
transportieren können.
Die Internet-Technologie ermöglicht auch die Kommunikation zwischen Regelungssystemen,
die sich an weit voneinander entfernten Orten befinden. Dazu müssen die jeweiligen lokalen
Netzwerke der Regelungssysteme an das Internet angebunden sein. Oftmals können für andere
Zwecke eingerichtete Internetzugänge mitgenutzt werden. Ist kein entsprechender Anschluss
vorhanden, gibt es verschiedene weitere Möglichkeiten einer Internetanbindung.
Internetzugänge mit hohen Bandbreiten können per (A)DSL (Asymmetric Digital Subscriber
Line) oder mit Modems für das TV-Kabel realisiert werden. In beiden Fällen wird das jeweilige
LAN (LAN = Local Area Network) über einen Router an das entsprechende Modem angebunden.
Internet-Zugänge via Satellit kommen nicht in Frage, weil der Uplink in den meisten Fällen
nicht über den Satelliten geht, sondern über ein Analog-Modem oder ISDN (Integrated Services
Digital Network) realisiert werden muss. Die dabei verfügbaren Bandbreiten sind nicht ausreichend. Außerdem funktionieren Satelliten-Internetzugänge oft nur mit proprietärer Software,
die nur für Betriebssysteme der Microsoft-Windows-Familie zur Verfügung steht.
51
52
KAPITEL 7. STAND DER INTERNET-TECHNIK FÜR VERTEILTE SYSTEME
Internetzugänge über das TV-Kabel sind in vielen Regionen nicht erhältlich und auch (A)DSL
ist in ländlichen Gebieten oft nicht verfügbar. Sind (A)DSL- und TV-Kabelmodem-Zugang nicht
möglich, können nur noch schmalbandige Zugänge realisiert werden. In Zukunft wird in ländlichen Gebieten eventuell WiMAX zur Verfügung stehen.
7.1 Lokale Vernetzung
7.1.1 Ethernet
Für die lokale Vernetzung wird der Netzwerkstandard Ethernet (IEEE802.3, siehe [112])
genutzt. Dabei werden alle Geräte des LAN (Local Area Network = Lokales Netzwerk) über
Patchkabel mit einem Switch verbunden. Dieser vermittelt die Datenpakete dann zwischen den
angeschlossenen Geräten. Dazu wird jeweils zwischen den beiden Kommunikationspartnern
eine exklusive Verbindung aufgebaut, die im Normalfall abhörsicher gegenüber den anderen
an dem Switch angeschlossenen Geräten ist (Ausnahmen siehe Abschnitt 8.5). Die exklusive
Verbindung stellt den beiden Kommunikationspartnern unabhängig vom sonstigen Datenverkehr
auf dem Switch auch die maximal mögliche Bandbreite zur Verfügung. Aktuelle Switches
arbeiten mit Datenraten zwischen 100 Mbit und 1 Gbit.
Zunehmende Verbreitung finden in letzter Zeit verschiedenen Varianten von Industrial Ethernet.
Dabei handelt es sich um Anpassungen für industrielle Umgebungsbedingungen (staub- und
wasserdichte Steckverbinder, Befestigung auf DIN-Tragschienen, redundante Auslegung, Echtzeitfähigkeiten, . . . ). Laut Ahlers [3] gibt es zur Zeit 26 verschiedene Varianten von Industrial
Ethernet.
Interessant sind in diesem Zusammenhang die Webseiten der EtherCAT Technology Group [78]
und der Ethernet Powerlink Standardization Group [79].
7.1.2 Very High Data Rate Digital Subscriber Line (VDSL)
Wenn kein Ethernet verfügbar ist, können vorhandene Zweidraht-Leitungen über VDSL-Modems
genutzt werden. Diese verbinden zwei Ethernet-Netzwerksegmente transparent miteinander, so
dass sie für die Software wie ein einzelnes Netzsegment erscheinen. VDSL-Produkte gibt es z. B.
von der Firma Allied Telesis [5].
7.1.3 Powerline Communication (PLC)
Powerline Communication ist eine Technologie, für die es sehr viele verschiedene Umsetzungen
und Anwendungsbereiche gibt. Bei der lokalen Vernetzung in einem LAN (Local Area Network)
kommen dabei meist Geräte zum Einsatz, die entweder den Standard Homeplug (AV) der HomePlug Powerline Alliance [104] oder den Standard Digital Home Specification der Universal
7.1. LOKALE VERNETZUNG
53
Powerline Association (UPA) [214] unterstützen. In Deutschland sind meist Geräte anzutreffen,
die Homeplug (AV) unterstützen, z. B. Produkte der Firmen Devolo [53], D-Link [58] und
Linksys [147].
Die Integration in ein lokales Netzwerk erfolgt meist durch eine Wandlung von PLC zu
Ethernet, so dass Powerline-Strecken transparent in ein Ethernet integriert werden können.
Dabei werden Datenraten von 1 Mbit bis zu 200 Mbit erreicht. Mit zunehmender Entfernung
zwischen zwei PLC-Knoten nimmt die Datenrate allerdings stark ab. Erwähnenswert ist noch,
dass eine PLC-Übertragung zwischen zwei Netzwerk-Knoten, die mit verschiedenen Phasen des
Stromnetzes verbunden sind, nur dann erfolgen kann, wenn spezielle Überträger zwischen den
Phasen vorhanden sind. Das ist bei älteren Gebäuden nicht der Fall, so dass dort die Nutzung
von PLC problematisch werden kann.
Für die Datenübertragung mit PLC werden Frequenzen im Bereich zwischen 1 MHz und
30 MHz genutzt. Im gleicher Frequenzbereich arbeiten auch verschiedene Funkdienste (z. B.
Kurzwellenrundfunk, Amateurfunk). Die von Powerline-Geräten erzeugten Störungen waren
deshalb schon Gegenstand zahlreicher Gerichtsverfahren (z. B. [91]).
Die Firmen Infineon Technologies AG [131], Intel Corporation [133], Panasonic Corporation
[179], Texas Instruments Inc. [206] und fünf weitere kleine Firmen haben im April 2008 zusammen das HomeGrid Forum [103] gegründet. Ziel dieser Vereinigung ist die Schaffung eines
einheitlichen Standards für die häusliche Vernetzung. Als Medien für die Vernetzung sollen Telefonleitungen, TV-Kabel und auch Stromnetze genutzt werden. Dazu sollen die bisher verfügbaren Technologien zusammengeführt und in einem einzigen Standard vereint werden.
7.1.4 Wireless Local Area Network (WLAN)
Bei der lokalen Vernetzung können auch drahtlose Netzwerke (WLAN = Wireless Local Area
Network) nach IEEE 802.11 [113] zum Einsatz kommen. Dabei sind jedoch einige Sicherheitsaspekte zu beachten. Datenverkehr in unverschlüsselten drahtlosen Netzwerken kann sehr leicht
abgehört werden. Außerdem können Unbefugte ohne größeren Aufwand in solche Netzwerke
eindringen. Um Vertraulichkeit, Integrität und Authentisierung im WLAN zu gewährleisten,
wurde in der IEEE802.11 das Verschlüsselungsprotokoll WEP (Wireless Equivalent Privacy)
festgeschrieben. Die Verwendung dieses Protokolls bietet zwar mehr Sicherheit als gar keine
Verschlüsselung, stellt aber keinen hinreichenden Schutz mehr dar. Aufgrund von Schwachstellen im Protokoll muss WEP seit Mitte 2001 als vollständig kompromittiert angesehen werden
(siehe [47]). Im Internet sind zudem zahlreiche Tools zum einfachen Einbrechen in die mit
WEP arbeitenden WLANs zum Download erhältlich (z. B. Airsnort [4]). Als Reaktion auf die
Sicherheitslücken von WEP wurde Ende 2002 von der Hersteller-Vereinigung Wi-Fi-Alliance
[223] das zur IEEE802.11 abwärtskompatible WPA (Wi-Fi Protected Access) entwickelt.
Auch bei WPA sind mittlerweile einige Sicherheitslücken aufgetreten. Der Sicherheitslevel ist
aber dennoch deutlich höher als bei WEP. Mitte Juni 2004 wurde mit dem neuen Standard
IEEE802.11i das nochmals verbesserte Sicherheitssystem WPA2 eingeführt.
54
Da WPA2-fähige Hardware nur bedingt verfügbar ist und vermutlich auch WPA2 in Zukunft
Sicherheitslücken zeigen wird, muss bei der Verwendung von drahtlosen Netzwerken über
zusätzliche Sicherheitsmechanismen, z. B. ein VPN (Virtual Private Network, siehe Abschnitt
8.1) nachgedacht werden. Bei sicherheitskritischen Regelungssystemen sollte man besser
von der Verwendung drahtloser Netzwerke absehen. Sie sind zusätzlich zu den bekannten
Sicherheitslücken auch noch anfällig gegen hochfrequente Störimpulse, so dass die notwendige
Betriebssicherheit nicht gewährleistet werden kann.
7.1.5 Bluetooth
Bluetooth [26] – benannt nach dem Wikingerkönig Harald Blauzahn – ist ein von den Firmen
Ericsson [76], Nokia [169], IBM [108], Toshiba [210] und Intel [133] entwickelter Industriestandard nach IEEE802.15 [114]. Die Technologie arbeitet im gleichen Frequenzbereich wie WLAN.
Es handelt sich um eine Funktechnik, mit der personal area networks (PAN) aufgebaut werden
können. Bluetooth wird meist genutzt, um Geräte im Nahbereich drahtlos zu verbinden. Beispiele dafür sind die Sprachübertragung zwischen einem Mobiltelefon und dem per Bluetooth daran
angebundenen Headset. Aber auch TCP/IP-Verbindungen sind möglich. Die verwendeten Sendeleistungen können bei Bluetooth je nach Geräteklasse geringer als bei WLAN sein, so dass auch
nur geringere Reichweiten erzielt werden können. Außerdem sind die verfügbaren Übertragungsbandbreiten deutlich geringer als bei WLAN (Bluetooth bis zu 2.1 Mbit/s, WLAN >100 Mbit/s).
Ein weiterer Nachteil von Bluetooth ist der im Vergleich zu WLAN deutlich schlechtere Sicherheitslevel. In [101] wird beschrieben, dass viele Bluetooth-Geräte bei verschlüsselten Verbindungen eine Schlüssel-Länge von nur 56 Bit erzwingen, was für kritische Daten aus Sicherheitsgründen nicht akzeptabel ist. Ohne zusätzliche Sicherheitsmechanismen wie z. B. Virtual Privat
Networks (siehe Abschnitt 8.1) ist Bluetooth damit für verteilte Regelungssysteme nicht geeignet.
7.2 Drahtgebundene Internetzugänge
7.2.1 Digital Subscriber Line (DSL)
Die drei Buchstaben DSL stehen für Digital Subscriber Line, was soviel bedeutet wie digitale Teilnehmeranschlussleitung. Es handelt sich dabei um ein Verfahren, mit dem über
Kupfer-Doppeladern herkömmlicher Telefonleitungen hohe Datenraten übertragen werden.
Dabei werden die zu übertragenden Bit-Informationen mit einem als Discrete Multitone (DMT)
bezeichneten Verfahren auf bis zu 255 Trägerfrequenzen codiert. Der serielle Datenstrom
wird dazu jeweils in eine definierte Anzahl von Bits zusammengefasst und auf komplexen
Subsymbolen abgebildet, die dann parallel gesendet werden.
7.2. DRAHTGEBUNDENE INTERNETZUGÄNGE
55
Die in Deutschland überwiegend anzutreffende DSL-Variante ist ADSL (Asymmetric Digital
Subscriber Line) oder – je nach Anbieter – eine der Varianten ADSL2 und ADSL2+. Bei diesen
Verfahren sind die erreichbaren Bandbreiten für Up- und Downstream unterschiedlich. Dabei ist
der Upstream meist um den Faktor zehn langsamer als der Downstream. Mit ADSL2+ lassen
sich Übertragungsbandbreiten von bis zu 25 Mbit im Downstream erreichen. Für die Datenübertragung zwischen den Knoten eines verteilten Reglernetzwerks sind die erzielbaren Bandbreiten
ausreichend. Sollen jedoch parallel dazu auch Serverdienste für Visualisierungszwecke mit
mehreren Clients über den DSL-Zugang abgewickelt werden, kann es beim Upstream zu
Engpässen kommen. In diesem Fall muss gewährleistet werden, dass die Datenübertragung für
den Regelungsprozess Vorrang hat. Das kann z. B. über die Quality-of-Service-Funktionen eines
Routers oder durch eine Beschränkung der Nutzerzahl des Webservers geschehen.
In einigen Städten Deutschlands ist mittlerweile das deutlich schnellere VDSL2 verfügbar. Damit
sind theoretisch Datenübertragungsraten von bis zu 100Mbit in beide Richtungen möglich. Da
die zulässigen Leitungslängen bei VDSL2 deutlich kürzer sind als bei ADSL2+, ist der Ausbau
der Infrastruktur jedoch sehr aufwändig, so dass sehr wahrscheinlich noch viel Zeit bis zu einer
flächendeckenden Verfügbarkeit vergehen wird.
7.2.2 Internet per TV-Kabel
Für den Internet-Zugang per TV-Kabel gilt Ähnliches wie für den Zugang per DSL. In den meisten Fällen ist die maximale Upstream-Bandbreite deutlich geringer als die des Downstreams.
Damit ergibt sich auch die gleiche Bandbreitenproblematik für den Upstream. Internet-Zugänge
über das TV-Kabel sind deutlich seltener anzutreffen als Zugänge per DSL. Die Standardisierung
der Technologie ist noch nicht weit fortgeschritten. Es werden Systeme verschiedener Hersteller
(z. B. Motorola Inc. [160], Zenith Electronics Corporation [241], International Business Machines Corp. IBM [108]) eingesetzt, die zueinander nicht kompatibel sind.
7.2.3 Analog-Modems
Analog-Modems nutzen als Übertragungsmedium eine Telefonleitung. Die dabei erzielbaren Datenraten hängen von der Art der Verbindung ab. Es gibt prinzipiell zwei verschiedene Möglichkeiten zur Nutzung analoger Modems:
• Zugriff auf den Einwahlknoten eines Internetproviders
• Punkt zu Punkt-Verbindung zwischen zwei Modems
Nutzung von Einwahlknoten eines Internetproviders
Die besondere Infrastruktur der Internetprovider erlaubt für den Datentransfer vom Provider zum
eingewählten Modem eine maximale Übertragungsbandbreite von 56000 bps. Beim Upload hingegen werden nur 33600 bps erreicht. Die maximal erreichbare Bandbreite für den Download
56
ist ein eher theoretischer Wert, der aufgrund der physikalischen Beschaffenheit der Telefonleitungen nur sehr selten erreicht wird. In der Praxis werden meist nur Bandbreiten von ca. 40000
bis 45000 bps erzielt. Nach dem Aushandeln der möglichen Übertragungsbandbreite zwischen
Einwahlknoten und einwählendem Modem wird die eigentliche Verbindung per PPP (Point to
Point Protocol) aufgebaut. Dabei bekommt der einwählende Rechner vom Einwahlknoten eine IP-Adresse zugeteilt. Die IP-Adresse ändert sich in den allermeisten Fällen bei jeder neuen
Einwahl. Soll der eingewählte Rechner aus dem Internet erreichbar und eindeutig identifizierbar
sein, müssen die im Abschnitt 7.4.2 beschriebenen Techniken angewandt werden.
Punkt zu Punkt-Verbindung zwischen zwei Modems
Bei einer Punkt zu Punkt-Verbindung zwischen zwei Analog-Modems beträgt die maximal erzielbare Übertragungsbandbreite 33600 bps. Diese Geschwindigkeit wird sowohl beim Upload
als auch beim Download erreicht. Beim Aufbau einer solchen Verbindung fungiert ein Rechner
als Einwahlserver. Der andere Rechner baut eine Verbindung zu diesem Rechner auf. Die Konfiguration des Einwahlservers ist unter Linux mit Bordmitteln recht einfach zu bewerkstelligen:
1. Zunächst wird das Programm mgetty installiert. Dieses Programm sorgt dafür, dass das
angewählte Modem den Anruf entgegen nimmt und mit dem einwählenden Modem die
Übertragungsmodalitäten verhandelt. Wichtig bei der Installation von mgetty ist, dass die
ausgewählte Version die Funktion AutoPPP unterstützt. Das ist nicht bei allen verfügbaren
Installationspaketen für mgetty der Fall.
2. mgetty wird einer seriellen Schnittstelle zugewiesen. Das geschieht unter Linux in der
Datei /etc/inittab (Bsp.: siehe Abbildung 7.1).
ppp0:2345:respawn:/sbin/mgetty -D ttyS0
Abbildung 7.1: Zeile aus der Datei /etc/inittab zur Konfiguration von mgetty für die erste serielle
Schnittstelle /dev/ttyS0
3. Die Konfigurationsdateien in den Verzeichnissen /etc/ppp und /etc/mgetty müssen für
eingehende Verbindungen konfiguriert werden. In /etc/ppp/options werden die Hostnamen für den Einwahlserver und den einwählenden Rechner eingetragen. (Bsp.: siehe Abbildung 7.2). In der Datei /etc/ppp/pap-secrets werden die Logins der einwahlberechtigten
Nutzer mit zugehörigem Passwort hinterlegt.
4. In der Datei /etc/hosts werden den Hostnamen des Einwahlservers und des einwählenden
Rechners die IP-Adressen zugewiesen, die die Rechner für die PPP-Verbindung benutzen.
5. Benutzernamen und Passwörter für den Einwahlzugang werde in /etc/ppp/pap-secrets
abgelegt (siehe Abb. 7.3).
7.2. DRAHTGEBUNDENE INTERNETZUGÄNGE
57
pppserver:pppclient
Abbildung 7.2: In der Datei /etc/ppp/options werden die Hostnamen für Einwahlserver und einwählenden Rechner im Format <hostname Einwahlserver>:<hostname einwählender Rechner> festgelegt.
#user
remote
server
*
secret
caller
addrs
*
Abbildung 7.3: In der Datei /etc/ppp/pap-secrets werden die Logins (z. B. remote) und Passwörter (z. B. caller) der zur PPP-Einwahl berechtigten Nutzer hinterlegt.
Die Linux-Kernel für Embedded Systems sind so konfiguriert, dass darin nur notwendige
Funktionen enthalten sind. Das führt manchmal dazu, dass die benötigten Treiber für PPPVerbindungen nicht vorhanden sind. In einem solchen Fall muss der Linux-Kernel aus den
Kernel-Sourcen, die von [139] bezogen werden können, neu kompiliert werden oder zumindest müssen die entsprechenden Kernelmodule kompiliert und geladen werden. Dabei müssen
folgenden Optionen aktiviert werden:
• PPP allgemein
• PPP für serielle Schnittstellen
Zusätzlich kann noch eine Option für die Datenkompression bei der Übertragung aktiviert werden.
7.2.4 Integrated Services Digital Network (ISDN)
Bei ISDN handelt es sich um ein System für die digitale Übertragung von Sprache und Daten
über eine herkömmliche Kupfer-Telefonleitung. Die Technik wurde entwickelt, um eine bessere Sprachqualität und höhere Datenübertragungsraten zu ermöglichen, als dies beim klassischen
analogen Telefonnetz PSTN (Public Switched Telephone Network) technisch machbar ist. Pro
Kanal wird eine Bandbreite von 64 kbit/s erreicht. Durch die Bündelung von zwei Kanälen kann
eine Gesamtbandbreite von 128 kbit/s erzielt werden. Für die Datenübertragung ist ISDN seit der
Verfügbarkeit von DSL (Digital Subscribe Line) weitgehend uninteressant geworden, da DSL
wesentlich höhere Bandbreiten bietet, z. B. 1 Mbit/s beim günstigsten DSL-Anschluss der Firma T-Com [203], und im Gegensatz zu ISDN nicht nach dem teuren Zeittakt abgerechnet wird.
Die Nutzung von ISDN kann dann sinnvoll sein, wenn schon ein ISDN-Zugang und die dafür
notwendige Infrastruktur vorhanden sind und nur sehr kleine Datenmengen übertragen werden
sollen. Außerdem kann ISDN eine Alternative zu DSL darstellen, wenn DSL nicht verfügbar ist
und eine Telekommunikationsfirma deshalb eine ISDN-Flatrate anbietet.
58
7.2.5 Nutzung bereits vorhandener Internetzugänge
Um Kosten zu sparen, bietet sich für die Realisation verteilter Monitoring- und Regelungssysteme die Nutzung bereits vorhandener Kommunikations-Infrastruktur an. Dabei ist jedoch
Folgendes zu beachten:
Werden Kommunikationskanäle durch verschiedene Nutzer gleichzeitig genutzt, sollte sichergestellt werden, dass die zur Verfügung stehende Bandbreite für die zeitgleiche Nutzung durch
alle Nutzer ausreicht. Soll z. B. ein bereits vorhandener DSL-Zugang mitgenutzt werden, um
bandbreitenaufwändige Visualisierungsprozesse für mehrere gleichzeitig zugreifende Nutzer
anzubieten, ist die für Uploads zur Verfügung stehende Bandbreite mit hoher Wahrscheinlichkeit
nicht ausreichend. Der gelegentliche Upload von Messdaten wäre problemlos möglich. Qualitativ hochwertige Internet-Router bieten oft die Möglichkeit, verschiedene Dienste zu priorisieren
und ihnen damit höhere Bandbreiten und kürzere Antwortzeiten zu ermöglichen. Man spricht
dabei von Dienstgüte oder auch Quality of Service (QoS).
Ein weiterer wichtiger Punkt bei der Mitnutzung von bereits vorhandenen Internet-Zugängen
ist die Art der zur Verfügung stehenden IP-Adressen. Sind nur private IP-Adressen (siehe
Abschnitt 7.4.1) erhältlich, müssen alle mit der NAT (Network Adress Translation) in Zusammenhang stehenden Probleme gelöst werden, um aus dem Internet Zugriff auf die Rechner zu
bekommen. Diese Probleme treten mit “echten” IP-Adressen nicht auf.
Ist das Netzwerk, welches mitgenutzt werden soll, durch eine Firewall (siehe Abschnitt 8.4)
geschützt, muss geklärt werden, ob die Ports für die benötigten Netzwerkdienste geöffnet sind
(z. B. Port 22 für die Secure Shell SSH oder Port 80 für den World Wide Web-Zugang).
7.3 Drahtlose Internetzugänge
7.3.1 Global System for Mobile Communications (GSM)
Für abgelegene Standorte, an denen drahtgebundene Internetzugänge nicht verfügbar sind, bietet
sich die Nutzung der Mobilfunknetze zur Datenübertragung an. Die in Europa verfügbaren
Mobilfunknetze arbeiten mit dem Global System for Mobile communications (GSM). Diese
Technik wird weltweit in ca. 200 Ländern genutzt und ist damit der am weitesten verbreitete
Mobilfunk-Standard.
Für eine zuverlässige Datenübertragung in Mobilfunknetzen muss eine Mindestsignalstärke am
Antenneneingang des GSM-Modems garantiert werden. Diese liegt laut [209] zwischen -77 dBm
und -53 dBm (1 dBm entspricht dabei 1 mW). Problematisch dabei ist, dass Signalstärken stark
schwanken können, z. B. in Abhängigkeit von bestimmten Wetterbedingungen. Deshalb muss
bei der Installation von Antennen darauf geachtet werden, dass Standorte mit möglichst ho-
7.3. DRAHTLOSE INTERNETZUGÄNGE
59
hen Signalstärken ausgewählt werden. GSM-Modems können die aktuelle Signalstärke messen.
Der gemessene Wert kann dann per AT-Befehl ausgelesen werden. Der AT-Befehlssatz wurde
von der mittlerweile aufgelösten Firma Hayes Communications zur Parametrierung von Modems entwickelt. AT steht dabei für attention. Für GSM-Geräte wurde der AT-Befehlssatz um
GSM-spezifische Befehle erweitert. Siehe dazu [197]. Ein Beispiel für die Kommunikation zum
Abfragen der Signalstärke ist in Abb. 7.4 dargestellt.
AT+CPIN=1234
OK
AT+CSQ
+CSQ: 19,99
Abbildung 7.4: Kommunikation eines Rechners mit einem GSM-Modem zur Abfrage der vom
GSM-Modem gemessenen Signalstärke am Antenneneingang
Zunächst muss das Modem im Mobilfunknetz angemeldet werden. Das geschieht durch Eingabe
der PIN mit dem Befehl AT+CPIN=<pin> wobei <pin> für die persönliche Identifikationsnummer der GSM-SIM-Karte steht. Danach wird der Befehl zur Abfrage der Signalstärke
AT+CSQ an das Modem gesendet. Das Modem gibt daraufhin zwei durch ein Komma getrennte
ganzzahlige Werte zurück. Der erste Werte ist die Received Signal Strength Indication (RSSI)).
Der zweite Wert wird als bit error rate (ber) bezeichnet. Die ber ist für die Ermittlung der
Signalstärke uninteressant. Die RSSI wird nach Tabelle 7.1 in eine Signalstärke in dBm umgerechnet.
In Mobilfunknetzen werden für Mobiltelefone und Modems meist Antennen genutzt, die in der
horizontalen Ebene in alle Richtungen eine gleichförmige Abstrahlcharakteristik aufweisen.
Solche Antennen werden auch als Rundstrahler bezeichnet. Ihr großer Vorteil ist, dass sie im
mobilen Betrieb nicht auf den nächsten Mobilfunkumsetzer ausgerichtet werden müssen. Durch
die Rundstrahlcharakteristik ist der erzielbare Antennengewinn jedoch sehr gering. Dieser liegt
meist im Bereich zwischen 0 dB und 3 dB. Bei abgelegenen Standorten kann es vorkommen,
dass die mit Rundstrahlern erzielbaren Signalstärken nicht ausreichen, um eine zuverlässige
RSSI
Signalstärke
0
-113 dBm oder geringer
1
-111 dBm
2. . . 30
-109 dBm . . . -53 dBm
31
-51 dBm oder höher
99
unbekannt oder nicht feststellbar
Tabelle 7.1: Umrechnung der vom GSM-Modem gemessenen Signalstärke von RSSI in dBm
60
Erreichbarkeit der Mobilfunkknoten zu gewährleisten. In diesem Fall können Richtantennen
eingesetzt werden. Sie haben meist Antennengewinne zwischen 9 dB (z. B. Flächenantenne)
und 12 dB (z. B. Yagi-Antenne). Richtantennen müssen auf den nächsten Mobilfunkumsetzer
ausgerichtet werden, da sonst aufgrund der Richtcharakteristik die Feldstärken so gering sind,
dass gar keine Kommunikation stattfinden kann. Beim Ausrichten der Antenne ist darauf zu
achten, dass wirklich ein Mobilfunkumsetzer angepeilt wird und nicht andere Objekte, die die
Strahlung des Mobilfunkumsetzers und der Antenne lediglich reflektieren. Im Prinzip kann
zwar auch mit Reflexionen gearbeitet werden, jedoch sind reflektierende Objekte manchmal
nicht dauerhaft vorhanden (z. B. ein temporär aufgestellter Baukran), so dass beim Verlust des
reflektierenden Objekts die Antenne neu ausgerichtet werden muss.
Beim Datentransport per GSM können prinzipiell zwei verschiedene Übertragungstechniken zum
Einsatz kommen. Es handelt sich dabei um das leitungsvermittelte High Speed Circuit Switched Data (HSCD) und den paketorientierten, verbindungslosen General Packet Radio Service
(GPRS). HSCD wird aufgrund der leitungsvermittelten Technik immer zeitbasiert abgerechnet
und konnte sich deshalb auf dem Mark nicht durchsetzen. Beim paketorientierten GPRS wird
auf Basis des übertragenen Datenvolumens abgerechnet, so dass die Systeme immer online sein
können, ohne dadurch hohe Kosten zu verursachen.
Zur Nutzung von GPRS muss dem mobilen Endgerät der Access Point Name (APN) mitgeteilt
werden. Das geschieht mit einem AT-Befehl. Soll z. B. der Web-Accesspoint des Mobilfunkanbieters Vodafone [219] genutzt werden, geschieht das mit dem folgenden Befehl:
AT+CGDCONT=1,"IP","web.vodafone.de"
Anschließend wird das Modem ebenfalls per AT-Befehl in den GPRS-Modus umgeschaltet:
AT+CGATT=1
Nun kann – ebenfalls per AT-Befehl – die Einwahlnummer des Providers angewählt werden:
ATDT*99***1#
Um die recht bescheidenen Bandbreiten bei der mobilen Datenübertragung zu erhöhen, wurde
Enhanced Data Rates for GSM Evolution (EDGE) entwickelt. Bei EDGE wird ein zusätzliches
Modulationsverfahren eingeführt. Die Technik ist abwärtskompatibel zum bisherigen GSM-Netz,
so dass vorhandene Komponenten nicht gestört werden. Die GPRS-Variante von EDGE heißt
Enhanced GPRS (E-GPRS). Nicht alle Mobilfunkanbieter stellen ihre Netze auf EDGE um.
Bisher wird es in Deutschland nur von T-Mobile [204] und Vodafone [219] angeboten und das
auch noch nicht flächendeckend.
Sowohl bei GPRS als auch bei E-GPRS können durch Kanalbündelung höhere Datenraten
erzielt werden. Dazu gibt es die so genannten Multislot-Klassen. Sie definieren die Anzahl
der bündelbaren Kanäle sowie die Anzahl der in Sende- und Empfangsrichtung maximal
7.3. DRAHTLOSE INTERNETZUGÄNGE
61
nutzbaren Kanäle . Eine entsprechende Übersichtstabelle der Multislot-Klassen ist in Tabelle 7.2
dargestellt.
Multislot-Klasse
1
2
3
4
5
6
7
8
9
10
11
12
maximale
maximale
maximale Kanäle
Empfangskanäle Sendekanäle
(gesamt)
1
1
2
2
1
3
2
2
3
3
1
4
2
2
4
3
2
4
3
3
4
4
1
5
3
2
5
4
2
5
4
3
5
4
4
5
Tabelle 7.2: GPRS Multislot-Klassen (Quelle: Elektronik-Kompendium [70])
Nicht jedes GPRS-Endgerät beherrscht alle Multislot-Klassen. So verfügt z. B. das GSM/GPRSModem MC35i Terminal der Siemens AG [196] nur über die Multislot-Klassen 1, 2, 4 und 8. Das
bedeutet, dass maximal vier Downloadkanäle gebündelt werden können. Eine Bündelung von
Upload-Kanälen ist nicht möglich.
GSM/GPRS-Modems arbeiten nicht automatisch im Multislot-Betrieb, sondern sie müssen per
AT-Befehl vom Rechner mitgeteilt bekommen, welche Multislot-Klasse genutzt werden soll.
Das MC35i Terminal wird z. B. mit dem Befehl
AT\^SGCONF=,8
angewiesen, die Multislot-Klasse 8 zu nutzen.
Jedes GSM/GPRS-Modem beinhaltet eine Form von Mikrocontroller oder Kleinstrechner. Die
Wahrscheinlichkeit, dass ein solches Gerät softwaretechnisch abstürzt und damit nicht mehr korrekt funktioniert, steigt mit der Laufzeit des Gerätes. Deshalb ist es empfehlenswert, GSM/GPRSModems in regelmäßigen Abständen zurückzusetzen. Das kann entweder durch ein definiertes
Abschalten der Betriebsspannung (z. B. per Zeitschaltuhr) geschehen oder, falls nicht möglich,
kann ein Reset per Software erfolgen. Dieser wird durch folgenden AT-Befehl eingeleitet:
AT+CFUN=1,1
Bei GSM/GPRS-Verbindungen werden fast immer so genannte private IP-Adressen von den
Providern vergeben. Es ergeben sich dadurch die im Abschnitt 7.4.1 näher beschriebenen
62
Probleme, durch die ein Verbindungsaufbau aus dem Internet zum GSM/GPRS-Endgerät sehr
erschwert wird. Zusätzlich zu den in 7.4.1 beschriebenen Lösungsansätzen bieten manche
Mobilfunkprovider Lösungen an, bei denen die mobilen Endgeräte in einem virtuellen Subnetz
versammelt werden, welches dann über ein virtual private network (VPN) (siehe Abschnitt 8.1)
an das Kundennetz angebunden wird. Ein Beispiel für eine solche Lösung ist Corporate Data
Access (CDA) von Vodafone [219]. Derartige Lösungen lohnen sich aber meist nur dann, wenn
eine größere Anzahl von mobilen Endgeräten erreichbar sein soll. Der administrative Aufwand
zur Einrichtung und zum Betrieb einer solchen Lösung ist recht groß.
Zahlreiche Informationen zum Thema GSM sind auf der Website der GSM Association [95]
verfügbar. Informationen zum Thema Sicherheit in Mobilfunknetzen können dem Artikel [31]
entnommen werden.
7.3.2 Universal Mobile Telecommunication System (UMTS)
Das Universal Mobile Telecommunication System (UMTS) ist ein Mobilfunkstandard der so
genannten dritten Generation (3G). Die per UMTS erzielbaren Übertragungsbandbreiten sind
deutlich höher als bei GSM. Damit ist UMTS für Multimedia-Inhalte und die Übertragung von
großen Datenmengen prädestiniert. Leider gibt es zum jetzigen Zeitpunkt kaum UMTS-fähige
Endgeräte, die sich für den Betrieb an einem Embedded Systems eignen. Die auf dem Markt
verfügbaren Mobiltelefone mit UMTS-Modem eignen sich in der Regel nicht für den Dauerbetrieb. Auch viele der Laptop-Karten mit PCMCIA/Cardbus-Interface haben Stabilitätsprobleme.
Außerdem können sie praktisch nicht verwendet werden, weil die meisten Embedded Systems
nicht über einen PCMCIA/Cardbus-Steckplatz verfügen. Die Marktsituation wird sich sicherlich
in den nächsten Jahren ändern. So hat z. B. die Firma Wavecom [221] UMTS-Einsteckmodule
zur Integration auf Platinen angekündigt. Diese Module werden über eine USB- oder/und eine
RS232-Schnittstelle verfügen, so dass sie an die allermeisten Embedded Systems angeschlossen
werden können. Um die volle Bandbreite einer UMTS-Verbindung nutzen zu können, sollte
möglichst eine Rechneranbindung per USB erfolgen, da die Übertragungsgeschwindigkeit der
RS232 nicht ausreichend ist, um die komplette Bandbreite der UMTS-Verbindung zu nutzen.
Eine Möglichkeit zur Anbindung von Embedded Systems an das Internet per UMTS ist die
Nutzung von UMTS-Routern, die mit den Embedded Systems per Ethernet kommunizieren.
Derartige Geräte gibt es z. B. von Linksys [147] und Digi International [55].
Wie bei GSM werden auch bei UMTS von den Mobilfunkprovidern so genannte private IPAdressen vergeben. Die damit verbundenen Probleme für ein verteiltes Regelungs- oder Monitoringsystem können wie bei GSM gelöst werden.
7.4. TECHNISCHE PROBLEME BEI DER INTERNET-NUTZUNG
63
7.3.3 Worldwide Interoperability for Microwave Access (WiMAX)
Worldwide Interoperability for Microwave Access (WiMAX) ist eine andere Bezeichnung für
den Industrie-Standard IEEE 802.16 [115]. Mit dieser Technik sollen breitbandige Zugänge
zum Internet via Funknetz angeboten werden. Im Dezember 2006 wurden in Deutschland von
der Bundesnetzagentur [34] die für den Betrieb von WiMAX-Netzen benötigten Frequenzen
an die drei Firmen DBD [48], Inquam Broadband [132] und Clearwire [43] versteigert. Mit
der Nutzung der Frequenzen ist für die Firmen die Auflage verbunden, bis 2009 insgesamt 15
Prozent und bis 2011 insgesamt 25 Prozent aller Gemeinden in ihrem Versorgungsgebiet mit Internetanschlüssen zu versorgen. WiMAX ist besonders gut für die Erschließung ländlicher Räume
geeignet, in denen kein DSL verfügbar ist, da die Kosten der benötigten WiMAX-Infrastruktur
deutlich geringer als die der DSL-Installationen sind.
Hardware für den WiMAX-Betrieb wird schon sehr bald von vielen Herstellern verfügbar sein
(siehe [224]). Der Trend geht dabei zur Integration mehrerer Funkdienste in einen Chipsatz.
Dazu schreibt z. B. die österreichische Zeitung Der Standard [52] am 17. April 2007 in ihrer
Web-Ausgabe:
“Intel will mit Hilfe einer neuen Chipentwicklung die Kommunikation mit mobilen Geräten vereinfachen. Der neue Chipsatz soll alle verfügbaren Funkstandards und Sendefrequenzen wie
UMTS, WLAN, WiMAX oder Ultra-Breitband unterstützen und mit weniger Antennen auskommen.”
7.4 Technische Probleme bei der Nutzung von InternetTechnologie
7.4.1 Network Address Translation (NAT)
Die Entwickler des Internet waren der Meinung, dass die Zahl der durch 4 Byte darstellbaren
Internetadressen in der aktuellen Internet-Protocol-Version 4 (IPv4) [117] auf unabsehbare Zeit ausreichen würde. Immerhin wären bei vollständiger Auslastung dieses Systems
2554 = 4.228.250.625 Einzeladressen verfügbar.
Mit der rasanten Entwicklung des Internets zeigt sich jedoch schon heute ein Mangel an
Internetadressen. Eine Lösung dieses Problems soll mit der Internet-Protocol-Version 6 (IPv6)
[124] erreicht werden. Sie ist technisch bereits realisiert. Ihre Einführung findet jedoch sehr
zögerlich statt, obwohl mit IPv6 sprichwörtlich jedem Grashalm auf der Erde eine IP-Adresse
zugewiesen werden könnte.
Mit der zunehmenden Knappheit von IP-Adressen entstand die Notwendigkeit, Rechnern einen
Zugang zum Internet zu ermögliche, ohne ihnen eine “öffentliche” IP-Adresse zuzuweisen.
64
Dazu wurde die Network Address Translation (NAT) erfunden. Bei der Network Address
Translation bekommen alle Rechner eines Netzwerkes sogenannte “private” IP-Adressen aus
einem der dafür vorgesehen IP-Adressbereiche (siehe Tabelle 7.3). Die drei entsprechenden
Adressbereiche wurden von der Internet Engineering Task Force IETF [116] im Request
For Comments RFC1918 [121] festgelegt. Sie können beliebig oft vergeben werden, da ihre
Internetzugriffe nur über Rechner mit “öffentlichen” IP-Adressen stattfinden.
Das Netzwerk mit den “privaten” IP-Adressen wird über einen NAT-Router an das Internet
angebunden. Dieser Router verwaltet eine Liste, in der allen Rechnern des Netzwerkes mit
“privaten” IPs, die einen direkten Internetzugriff benötigen, eine “öffentliche” IP zugewiesen
wird. Will einer dieser Rechner auf das Internet zugreifen, so tut er das über den NAT-Router.
Dabei übersetzt der Router die Anfragen von der “privaten” IP in Anfragen der in seiner Liste
zugewiesenen “öffentlichen” IP (siehe Abb. 7.5). Auch ein Zugriff vom Internet auf den Rechner
mit der “privaten” IP ist möglich. Da nicht immer alle Rechner eines Netzwerks Zugriff zum
Internet benötigen oder der Zugriff über einen Proxy (siehe Abschnitt 8.4) realisiert werden
kann, sind nur wenige “öffentliche” IPs erforderlich.
Name
IP Adressbereich
Anzahl der IPs
24-bit block
10.0.0.0-10.255.255.255
16,777,215
20-bit block 172.16.0.0-172.31.255.255
1,048,576
16-bit block 192.168.0.0-192.168.255.255
65,535
Netze
1 Klasse A
16 Klasse B
256 Klasse C
Tabelle 7.3: die in RFC1918 festgelegten IP-Bereiche für “private” IPs
Der Nachteil des Verfahrens ist, dass jeder Rechner, der direkten Internetzugriff haben soll,
neben seiner “privaten” IP auch eine “öffentliche” IP benötigt, da immer nur eine 1:1 Zuordnung
zwischen “privaten” und “öffentlichen” IPs möglich ist.
Um dieses Problem zu umgehen, wurde die Network Address Port Translation (NAPT)
entwickelt. Wenn von NAT gesprochen wird, ist in den meisten Fällen NAPT gemeint. Bei
diesem Verfahren werden neben den IP-Adressen auch die Port-Nummern vom NAT-Router
umgeschrieben. Dadurch ist es möglich, die Internetzugriffe aller Rechner eines Netzwerks mit
“privaten IPs” auf eine einzige “öffentliche” IP-Adresse zu mappen (siehe Abb. 7.6).
NAPT wird manchmal auch als Port Translation PAT oder IP Masquerading bezeichnet.
Die Einrichtung eines LINUX-Rechners für NAPT ist unter [141] beschrieben. Der große Nachteil der NAPT besteht darin, dass zwar aus dem Subnetz Verbindungen ins Internet aufgebaut
werden können, aber nicht umgekehrt, da die Adressen mehrfach vergeben sein können. Für
Serverdienste ist aber gerade die Erreichbarkeit aus dem Internet unerlässlich.
65
192.168.0.3
89.110.146.76
192.168.0.2
192.168.0.1
Abbildung 7.5: Ein Rechner mit “privater” IP (192.168.0.1) bekommt per Network Address
Translation unter der “öffentlichen” IP 89.110.146.76 Zugang zum Internet. Die
anderen Rechner des Netzwerks haben keinen Internetzugriff.
192.168.0.3:5000
89.110.146.76:5000
89.110.146.76:5001
192.168.0.2:5000
89.110.146.76:5002
192.168.0.1:5000
Abbildung 7.6: Alle Rechner eines Netzes mit “privaten” IPs bekommen per Network Address
Port Translation über eine “öffentliche” IP Zugang zum Internet.
66
Mit Hilfskonstruktionen ist es dennoch möglich, Verbindungen zu Rechnern mit “privaten” IPAdressen aufzubauen. Im Wesentlichen lässt sich eine solche Verbindung mit zwei verschiedenen
Mechanismen bewerkstelligen:
• Port-Forwarding
• NAT-Traversal
Port-Forwarding
Das Internet ist ein Transportmedium, über das ganz unterschiedliche Dienste abgewickelt
werden können. Um die verschiedenen Dienste unterscheiden und adressieren zu können,
werden so genannte Ports verwendet. Jedem standardisierten Dienst ist ein Port zugewiesen.
Der Dienst World Wide Web (WWW) arbeitet z. B. auf Port 80. Insgesamt stehen 65536 Ports zur
Verfügung. Die ersten 1024 sind für privilegierte Dienste wie WWW reserviert.
Wenn ein Client-Rechner Anfragen an einen bestimmten Dienst auf einem anderen Rechner
(Server) stellen will, schickt er die Anfrage an die IP-Adresse und den entsprechenden Port des
Rechners, auf dem der Dienst läuft. Der Rechner, der die Anfrage erhält, ermittelt anhand des
Ports, auf dem die Anfrage einläuft, welcher Dienst angefragt wird und leitet die Anfrage an das
entsprechende Programm weiter.
Wenn der Server nur eine “private” IP-Adresse besitzt, dann ist ein direkter Zugriff aus dem Internet auf diesen nicht möglich. Um den Server zu erreichen, ist ein so genannter Router notwendig.
Dieser ist gleichzeitig aus dem Internet und aus dem Subnetz mit privaten IP-Adressen, in dem
der Server steht, erreichbar. Der Router besitzt die Fähigkeit, Anfragen, die ihn erreichen, auf
einen anderen Rechner weiterzuleiten. Welcher Dienst angefragt wird, erkennt der Router dabei
an der Port-Nummer. Der Router kann so konfiguriert werden, dass er Anfragen an verschiedene
Ports auch an verschiedene Rechner weiterleiten kann. Bekommt der Router z. B. eine Anfrage auf Port 80 (WWW), leitet er diese an einen vorher im Router eingetragenen Rechner mit
Web-Server weiter (siehe Abb. 7.7). Bekommt er eine Anfrage auf Port 22, wird diese an einen
Rechner weitergeleitet, auf dem ein SSH-Server läuft. Die Fähigkeit eines Routers, Anfragen an
einen seiner Ports zu einem anderen Rechner weiterzuleiten, nennt man Port-Forwarding. Eine
besondere Spielart des Port-Forwardings ist die Port-Redirection, bei der der Router Anfragen
an einen Port zu einem anderen Port weiterleitet.
NAT-Traversal
Der Mechanismus des Port-Forwardings funktioniert nur, wenn man Zugriff auf den entsprechenden NAT-Router hat und selbst das Port-Forwarding einrichten kann. Bei Einwahlverbindungen
ins Internet per GSM (siehe Abschnitt 7.3.1) werden dem einwählenden Rechner oft “private”
IP-Adressen zugeteilt. In diesem Fall besteht jedoch keinerlei Zugriff auf den NAT-Router,
so dass Port-Forwarding nicht funktioniert. Ein direkter Verbindungsaufbau zum Rechner mit
67
A:
Rechner mit "echter" IP
WWW−Anfrage, PORT 80
Client
Rechner mit "privater" IP
WWW−Server
B:
WWW−Anfrage, PORT 80
WWW−Server
SSH−Anfrage, PORT 22
Client
Router mit
Port Forwarding
SSH−Server
Abbildung 7.7: Zugriff von einem Client-Rechner auf einen Server ohne (A) und mit (B) PortForwarding
der privaten IP ist somit nicht realisierbar. Verbindungen können nur dann zustande kommen,
wenn der Rechner mit der “privaten” IP-Adresse selbständig eine Verbindung ins Internet zu
einem Server mit einer “echten” IP-Adresse aufbaut. Dieser Server reicht dann entweder die
Verbindung an andere anfragende Rechner weiter (Simple Traversal of UDP over NATs STUN)
oder transferiert direkt alle Daten für den Rechner mit “privater” IP-Adresse weiter (Traversal
Using Relay NAT TURN).
Eine Sonderlösung kann auch die Nutzung von VPN-Technologie, wie z. B. openVPN oder
Hamachi (siehe Abschnitt 8.1) sein.
Detailliertere Information zum Thema Network-Address-Translation und NAT-Traversal finden
sich unter:
• RFC 1579: Firewall Friendly FTP [120]
• RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations [125]
• RFC 2709: Security Model with Tunnel-mode IPsec for NAT Domains [126]
• RFC 2993: Architectural Implications of NAT [127]
68
• RFC 3027: Protocol Complications with the IP Network Address Translator (NAT) [128]
• RFC 3235: NAT-Friendly Application Design Guidelines [129]
7.4.2 Wechselnde IP-Adressen
Bei Einwahlverbindungen (z. B. per DSL oder per Telefon-Modem) wird dem einwählenden
Rechner eine IP-Adresse zugeteilt. Bei den meisten Einwahlverbindungen findet nach einer
gewissen Zeit eine Zwangstrennung der Verbindung statt (bei DSL oft alle 24 h). Im Zuge der
Neueinwahl wird dem einwählenden Rechner dann auch wieder eine IP-Adresse zugewiesen.
Diese ist meist nicht mit der IP der letzten Einwahl identisch. Mit einer neuen IP ändert sich
dann auch noch der Eintrag im Domain Name System (DNS) (siehe Abschnitt 7.5.2). Soll
jetzt auf einem Rechner mit Einwahlverbindung ein Serverdienst betrieben werden, ergibt sich
das Problem, diesen Rechner im Internet zu finden, da weder die IP noch der Hostname aus
dem DNS bekannt sind. Die Lösung des Problems besteht in der Nutzung eines dynamischen
Domain-Name-Systems. DynDNS ist eine spezielle Form des DNS (siehe Abschnitt 7.5.2).
Im Internet gibt es ca. 100 Anbieter für derartige Dienstleistungen. Der bekannteste und
softwaretechnisch am besten unterstützte Dienst ist DynDNS von Dynamic Network Services
Inc. [61].
In Abb. 7.8 wird ein Verbindungsaufbau unter Nutzung von DynDNS beschrieben. Zunächst wird
dem Einwahlrechner vom Einwahlserver eine IP-Adresse zugewiesen (1). Ein auf dem Einwahlrechner laufendes Programm registriert jede Änderung der IP-Adresse und teilt die jeweils neue
Adresse dem DynDNS-Server mit (2). Der DynDNS-Server hat für den Einwahlrechner einen festen Hostnamen (Fully Qualified Name (FQN)), der einmalig per Hand über ein Web-Formular
eingetragen werden muss. Diesem festen Namen wird jetzt die neue IP-Adresse zugeordnet. Will
jetzt ein Client die Serverdienste des Einwahlrechners nutzen, fragt er im DNS die IP-Adresse
des Einwahlrechners ab. Diese Anfrage wird automatisch an den DynDNS-Server weitergeleitet
(3). Er antwortet mit der aktuellen IP-Adresse des Einwahlservers. Jetzt kann der Client eine
direkte Verbindung zum Serverdienst des Einwahlrechners aufbauen (4), da ihm die IP-Adresse
bekannt ist.
Der große Nachteil von dynamischen Domain-Name-Systemen ist die Abhängigkeit von den
DNS-Servern der Anbieter. Beim Ausfall des Servers und einem Wechsel der IP-Adresse des eingewählten Rechners ist dieser nicht mehr zu erreichen. Eine einfach Lösung dieser Problematik
besteht darin, dass der eingewählte Rechner in festen Zeitintervallen Emails mit seiner eigenen
IP-Adresse an eine Service-Emailadresse verschickt, so dass die jeweils aktuelle IP im Notfall
auch ohne DynDNS zugänglich ist. Befindet sich zwischen Rechner und Internet ein NAT-Router
(NAT = Network Address Translation, siehe Abschnitt 7.4.1), kennt der Rechner die IP-Adresse,
über die er aus dem Internet erreicht werden kann, gar nicht. Er kann sie aber ermitteln, indem
er einen Webserver wie z. B. den von MyIp [164] abfragt, der eine html-Datei (html=Hypertext
Markup Language) zurückliefert, in der die IP des abfragenden Rechners enthalten ist. Ein einfaches Shell-Skript, das alle 24 Stunden eine Email mit der IP-Adresse des eigenen Rechners
verschickt, ist in Abb. 7.9 dargestellt.
69
1
Einwahl−Server
2
DynDNS−Server
Einwahlrechner
3
4
Client
Abbildung 7.8: Verbindungsaufbau von einem Client zum Einwahlrechner unter Nutzung von
DynDNS (1 - IP-Zuweisung, 2 - DynDNS-Update, 3 - DNS-Abfrage, 4 - Verbindungsaufbau)
7.4.3 Verbindungsabbrüche bei Einwahlverbindungen
Bei Einwahlverbindungen per Telefonmodem, Integrated Services Digital Network (ISDN),
Global System for Mobile Communications (GSM) oder Digital Subscriber Line (DSL) ist die
Verbindungsdauer oft durch den Internetprovider begrenzt, so dass nach einer bestimmten Zeit
die Verbindung automatisch abgebaut wird. Es besteht dann keine Möglichkeit, über das Internet
eine Verbindung zu dem vormals eingewählten Computer aufzubauen. Wenn ein Computer
für andere Rechner Serverdienste anbieten soll, ist meist eine permanente Internetanbindung
notwendig. Das bedeutet, dass bei Einwahlverbindungen sofort nach deren Abbau durch den
Internetprovider eine erneute Einwahl stattfinden muss, um eine möglichst hohe Verfügbarkeit
zu gewährleisten. Bei DSL-Verbindungen beherrscht die Verbindungssoftware meist von Haus
aus eine direkte Neueinwahl. Auch handelsübliche Internet-Router können meist für einen
sofortigen Wiederaufbau der Verbindung konfiguriert werden.
Komplizierter ist die Situation bei Verbindungen per Telefonmodem oder GSM. Für diese
beiden Techniken sind kaum Router verfügbar, die es ermöglichen, Serverdienste anzubieten,
da kein Routing vom Internet zu einem an den Router angeschlossenen Rechner stattfindet.
Sollen Serverdienste angeboten werden, muss der Rechner das Modem direkt selbst ansteuern.
70
#!/bin/bash
while true
//ewige Wiederholung
do
echo "hole IP-Adresse"
# hole die Datei index.html vom Webserver
wget http://www.myip.dk/
echo "verschicke IP"
# wandele index.html in Text um und
# verschicke ihn per Email an
# [email protected]
html2text -nobs index.html | \\
mail -s "IP" [email protected]
# lösche index.html, damit am nächsten
# Tag wieder Platz für die Datei ist
rm index.html
# warte 24 Stunden
echo "schlafe..."
sleep 24h
done
Abbildung 7.9: Skript zum Ermitteln der IP-Adresse eines Rechners und anschließenden Versenden dieser Adresse per Email
Die dafür erhältliche Software ist in den meisten Fällen nicht in der Lage, selbständig eine
abgebrochene Internetverbindung wieder aufzubauen.
Für das Betriebssystem Linux wurde im Rahmen dieser Arbeit das Programm ppp0-checker entwickelt. Es fragt ständig den Status der Internetverbindung mit Hilfe von Kommandozeilentools
für die Internet-Einwahl und die Netzwerkkonfiguration ab. Bei Verbindungsabbrüchen führt es
sofort eine neue Einwahl durch.
7.5 Netzwerkdienste für Verteilte Systeme
7.5.1 Zuweisung von IP-Adressen mittels Dynamic Host Configuration
Protocol (DHCP)
Das Dynamic Host Configuration Protocol dient dazu, auf einfache Weise die Netzwerkzugänge
von Rechnern in einem lokalen Netzwerk zu konfigurieren. Die dazu benötigten Parameter sind
z. B. die IP-Adresse, die Netzmaske, die IP-Adresse des Gateways und die IP-Adresse des Servers für den Domain Name Service (siehe dazu 7.5.2). Die zu konfigurierenden Client-Rechner
können alle diese Parameter von einem DHCP-Server abfragen, so dass eine Konfiguration per
Hand komplett entfällt.
7.5. NETZWERKDIENSTE FÜR VERTEILTE SYSTEME
71
Eine Nutzung von DHCP ermöglicht die dynamische Aufnahme von zusätzlichen Knoten in ein
Netzwerk und ist damit auch die Grundlage für viele Plug-and-Play-Systeme.
Jedes Netzwerk-Gerät besitzt eine sogenannte Media Access Control address (MAC address),
über die es eindeutig identifiziert werden kann. Diese Adressen können zur Erkennung von
Geräten genutzt werden, so dass der DHCP-Server ihnen eine feste IP-Adresse zuweisen kann.
DHCP ermöglicht außerdem eine große Flexibilität bei der Bildung von Netzwerken. Durch
eine entsprechende IP-Vergabe können Subnetze gebildet oder auch Netzwerke zusammengelegt
werden. Außerdem sorgt DHCP dafür, dass keine IP-Adressen doppelt vergeben werden, was
bei statischer IP-Vergabe leicht passiert und eine nicht zu unterschätzende Fehlerquelle darstellt.
Das DHCP bringt aber auch Nachteile mit sich. Fällt der DHCP-Server aus, sind nach einiger
Zeit (nach Ablauf der sog. lease time) die von ihm vergebenen IP-Adressen nicht mehr gültig
und die per DHCP konfigurierten Rechner haben keine IP-Adresse mehr. Sie sind damit nicht
mehr erreichbar. Ist der DHCP-Server dann irgendwann wieder verfügbar, sollten die Clients
theoretisch wieder bei ihm anfragen, neue IP-Adressen erhalten und wieder erreichbar sein. Die
Praxis zeigt aber, dass sich nicht jede DHCP-Client-Software zuverlässig so verhält. Infolge
dessen sind manche Rechner dauerhaft nicht mehr zu erreichen. Die Ausfallwahrscheinlichkeit
eines per DHCP konfigurierten Netzwerks ist deshalb deutlich höher als die eines Netzwerks
mit statisch vergebenen IP-Adressen.
Eine ausführliche Beschreibung des DHCP ist im Request for Comments RFC2131 [122] zu
finden.
7.5.2 Domain Name System (DNS)
Das DNS stellt eine Art Telefonbuch des Internets dar. Seine Hauptaufgabe ist die Übersetzung
der von Menschen einfach lesbaren Hostnamen (z. B. rainerbecker.org) in IP-Adressen (z. B.
89.110.146.76), die dann von Netzwerkgeräten verarbeitet werden können. Die Nutzung von
Hostnamen in Verbindung mit dem DNS hat den Vorteil, dass man die entsprechende Maschine
immer erreicht, auch wenn sich ihre IP-Adresse verändert hat. Außerdem stellt das DNS
Informationen darüber zur Verfügung, welcher Rechner in einem Netzwerk (genauer: in einer
Domain) für den Empfang und die Auslieferung von Emails zuständig ist.
Das DNS ist für verteilte Monitoring- und Regelungssysteme besonders in seiner Ausprägung
DynDNS (siehe Abschnitt 7.4.2) von großer Bedeutung, weil es eine Möglichkeit bietet, Rechner
mit wechselnden IP-Adressen im Internet aufzufinden.
Das DNS ist ausführlich in den requests for comment 1034 [118] und 1035 [119] beschrieben.
72
7.5.3 Zeitsynchronisation mit dem Network Time Protocol (NTP)
Bei verteilten Systemen ist es oft notwendig, die Systemuhren der einzelnen Rechner untereinander zu synchronisieren und dafür zu sorgen, dass sie korrekte Uhrzeiten haben. Besonders
wichtig ist das bei verteilten Regelungssystemen, die zu bestimmten Tageszeiten synchron
bestimmte Aktionen durchführen sollen. Zeitabweichungen können bei solchen Systemen fatale
Folgen haben. Auch für die Messdatenerfassung sind exakt gehenden Systemuhren notwendig,
um Datensätze verschiedener Systeme zueinander in Relation setzen zu können.
Zur Synchronisation von Rechneruhren werden im allgemeinen Zeitserver genutzt, die über
eine exakt gehende Uhr verfügen. Bei den Zeitservern ptbtime1.ptb.de und ptbtime2.ptb.de der
Physikalisch Technischen Bundesanstalt (PTB) [184] ist das z. B. eine Atomuhr. Zeitserver
können aber auch Signale von Zeitsignalsendern, z. B. dem DCF77-Sender (siehe [49]) der
PTB, oder Signale von Satelliten des Global Positioning System (GPS) nutzen, die über exakt
funktionierende Uhren verfügen.
Für die Synchronisation eines Rechners im Feld mit einem Zeitserver kann das Network Time
Protocol (NTP) genutzt werden.
Im Gegensatz zu handelsüblichen Personalcomputern verfügen Embedded Systems oft nicht
über einen Batteriepuffer für die Echtzeituhr. Das führt dazu, dass nach einer Spannungsunterbrechung die Systemuhr mit einer festgelegten Startzeit (z. B. 1.1.1980, 00:00 Uhr) losläuft. Soll
die Systemuhr nun auf die aktuelle Zeit eingestellt werden, muss also ein sehr großer Zeitsprung
stattfinden. Mess-Software reagiert aber oft sehr empfindlich auf derartige Zeitsprünge, so dass
diese Software sicherheitshalber erst nach dem Stellen der Systemuhr gestartet werden sollte.
Das Stellen der Systemuhr wiederum funktioniert erst dann, wenn eine Netzwerkverbindung zu
einem Timeserver verfügbar ist, was z. B. beim Aufbau einer PPP-Verbindung per GPRS über
ein Mobilfunknetz nicht sofort nach dem Systemstart gewährleistet ist.
In der Praxis hat sich für die Zeitsynchronisation unter Linux die Nutzung der Softwarepakete
ntpdate und ntp-simple bewährt. Ein Linux-System baut während des Bootvorgangs alle Netzwerkverbindungen auf. Ein anschließend ausgeführtes Skript nutzt den Befehl ifconfig, um festzustellen, ob das Netzwerk-Interface für eine Verbindung zum Zeitserver (z. B. ppp0 für eine
Mobilfunkverbindung) vorhanden ist. Ist das nicht der Fall, wird in regelmäßigen Abständen erneut überprüft, ob das Netzwerk verfügbar ist. Wenn das der Fall ist, wird ntpdate gestartet. Es
gleicht die Zeit mit einem im Konfigurationsfile festgelegten Zeitserver per ntp ab. Nach dem Abgleich wird ntp-simple gestartet. Dieses Programm läuft dauerhaft im Hintergrund und korrigiert
regelmäßig die geringfügigen Abweichungen zwischen der Systemuhr und der vom Zeitserver
zur Verfügung gestellten Zeitinformation. Durch die Regelmäßigkeit der Korrektur wird gewährleistet, dass nur noch sehr kleine Zeitsprünge (<1 Sekunde) stattfinden, welche unproblematisch
für Mess-Software sind. Sobald ntp-simple läuft, kann die Mess-Software gestartet werden.
73
7.5.4 Sicherheitsupdates
Praktisch jede Software hat Fehler. Softwarefehler stellen insbesondere bei vernetzten Computersystemen eine beträchtliche Gefahr dar. Pufferüberläufe und ähnliche Sicherheitslücken
können von Angreifern genutzt werden, um über das Internet ein Computersystem unter
ihre Kontrolle zu bringen. Damit solche Angriffe möglichst zuverlässig unterbunden werden,
müssen neu gefundene Sicherheitslücken im Betriebssystem und in Anwendungsprogrammen sofort geschlossen werden. Dazu müssen anfällige und fehlerhafte Programme durch
korrigierte Versionen ersetzt werden. Die aktuellen Versionen können im Prinzip von jedem
Datenträger aus eingespielt werden. Bei verteilten Embedded Systems bietet sich ein Update
über das Netzwerk an. Bei vielen Linux-Distributionen gibt es zu diesem Zweck spezielle
Server mit gepatchten Softwarepaketen, von denen die jeweils aktuellsten Programmversionen bezogen werden können. Bei der Linux-Distribution Debian z. B. erfüllt der Server
http://security.debian.org diese Funktion. Weitere Infos zur Sicherheit von Debian
sind unter [51]) zu finden.
Server mit fehlerbereinigten Softwarepaketen decken einen Großteil der aufgetretenen Sicherheitslücken ab, jedoch nicht immer sofort alle. Es ist deshalb sinnvoll, regelmäßig Websites zum
Thema Sicherheitslücken zu lesen und entsprechende Mailinglisten zu abonnieren.
Seit 2001 gibt es beim Bundesamt für Sicherheit in der Informationstechnik [29] das Computer
Emergency Response Team für Bundesbehörden (CERT Bund). Beim Warn- und Informationsdienst (WID) des CERT Bund [30] können zwei Mailinglisten zu den Themen “Aktuelle
Warnungen zu Computer-Viren, Würmern und anderen Schadprogrammen“ und ”Aktuelle
Informationen zu Sicherheitslücken und Schwachstellen in IT-Systemen“ abonniert werden.
Bei großen Netzwerken mit softwaretechnisch nicht identischen Rechnern ist der Aufwand für
tägliche Sicherheitsupdates von Hand beträchtlich. Ein automatisiertes Einspielen aller verfügbaren Sicherheitsupdates ist aber kaum realisierbar, da bei deren Installation oft Nutzereingaben erforderlich sind. Es gibt zwar oft Default-Werte für die entsprechenden Angaben. Leider
sind diese nicht immer passend und können im Extremfall dazu führen, dass der Rechner nicht
mehr per Netzwerk erreichbar ist. Um das Update-Problem für verteilte System, die auf DebianLinux basieren, zu lösen, wurde im Rahmen der im Abschnitt 15.1 beschriebenen MonitoringProjekte das Tool updatecheck entwickelt. Dieses Tool fragt im 24-Stunden-Rhythmus den Debian-Updateserver http://security.debian.org ab und gleicht die Liste der Sicherheitsupdates für die ganze Distribution mit der Liste der auf dem jeweiligen Rechner installierten
Softwarepakete ab. Nur wenn Sicherheitsupdates für die auf dem Rechner installierte Software
vorliegen, verschickt das Tool eine Email (siehe Abb. 7.10) mit der Liste der zu aktualisierenden
Softwarepakete an eine vorher in einem Config-File angegebene Email-Adresse. Updatecheck
läuft dann auf allen Rechnern eines verteilten Systems, so dass der Administrator per Email
immer zeitnah über anstehende Sicherheitsupdates informiert ist.
74
Subject:
From:
Date:
To:
UPDATES AVAILABLE: wp-eff-4-24813a
root <[email protected]>
13:39
[email protected]
libisc11
libdns22
libisccc0
libisccfg1
libbind9-0
liblwres9
bind9-host
dnsutils
file
libmagic1
libkrb53
Abbildung 7.10: vom Tool updatecheck generierte Email mit einer Liste von Programmpaketen,
für die Sicherheitsupdates zur Verfügung stehen
7.5.5 Fernwartung mit der Secure Shell (SSH)
In verteilten Systemen können die Rechner räumlich und netzwerktechnisch weit voneinander
entfernt sein. Das kann dazu führen, dass der Netzwerkverkehr zwischen den Knoten des
verteilten Systems auch durch ungeschützte Netze läuft. Die Nutzung derartiger Netze birgt
immer die Gefahr in sich, dass Unbefugte den Netzwerkverkehr mitschreiben (“sniffen”) und
nach unverschlüsselt übertragenen Logins und Passwörtern suchen, mit denen sie sich dann
Zugriff auf die Systeme verschaffen können.
Viele Netzwerkdienste übertragen auch heute noch Logins und Passwörter im Klartext. Dazu
zählen das oft zur Übertragung von Dateien genutzte File Transfer Protocol FTP und auch der
Telnet-Dienst. Diese Dienste sind aus sicherheitstechnischen Gründen nicht vertretbar, werden
jedoch trotzdem oft genutzt, da die Clients für diese Dienste zum Lieferumfang der Betriebssysteme der Firma Microsoft [156] gehören. Clients mit verschlüsselter Datenübertragung für
Dienste gleicher Funktion werden von Microsoft hingegen nicht mitgeliefert.
Die Gefahr des Diebstahls von Zugangsdaten kann nur umgangen werden, indem der Netzwerkverkehr in irgend einer Form verschlüsselt wird. Eine in der Nutzung sehr komfortable, aber
bei der Installation sehr aufwändige Variante der Verschlüsselung sind Virtual Private Networks
(Siehe dazu Abschnitt 8.1).
Mit wesentlich weniger Aufwand ist die Anwendung der Secure Shell (SSH) verbunden. SSH
kann dabei verschiedene Funktionen übernehmen:
75
1. Fernadministration eines Rechners über das Netzwerk
2. “Tunneln” von Netzwerkdiensten über eine verschlüsselte Verbindung
3. Dateitransfer per Secure Copy (SCP)
1. Fernadministration
Eine Shell ist ein Interpreter für Kommandozeilen-Befehle, der es ermöglicht, Programme zu
starten und Standardoperationen auf einem System durchzuführen (z. B. Dateien kopieren, Verzeichnisse löschen, . . . ).
SSH stellt eine solche Shell über eine gesicherte Netzwerkverbindung zur Verfügung, so dass
auch aus der Ferne mit der Shell gearbeitet werden kann. Damit ist SSH ein effizientes Werkzeug
zur Fernadministration. Da Linux ein Betriebssystem der UNIX-Familie ist und UNIX entwickelt
wurde, als an grafische Benutzeroberflächen noch nicht zu denken war, kann man über eine Shell
ein komplettes Linux-System mit Befehlen in der Kommandozeile administrieren.
2. Tunneln
Von manchen Netzwerkdiensten gibt es keine sicherheitstechnisch zuverlässige Implementation.
Ein Beispiel dafür ist der VNC-Dienst, der zur Fernsteuerung von Rechnern über das Netzwerk
genutzt wird. Ein vom Autor auf einem Rechner mit Microsoft Windows XP Professional
Betriebssystem installierter VNC-Server der Firma RealVNC Ltd. [186], der zum Zeitpunkt
des Einsatzes die neuste Softwareversion hatte, wurde innerhalb der ersten 24 Betriebsstunden
“geknackt”. Das komplette System war damit kompromittiert.
Ist man auf die Nutzung eines solch unsicheren Dienstes angewiesen, kann die notwendige
Sicherheit durch ein Virtual Private Network oder über das “Tunneln” der Netzwerk-Ports durch
eine SSH-Verbindung erreicht werden. In der Grafik 7.11, Teilbild B ist die Funktion eines
solchen Tunnels dargestellt.
Das Teilbild A zeigt eine VNC-Verbindung ohne SSH-Tunnel. Der VNC-Client baut von seinem
Port 5900 eine direkte Verbindung per Internet zum Port 5900 des VNC-Servers auf (in der
Abbildung als rote Linie dargestellt). Die Kommunikation verläuft unverschlüsselt, so dass die
Zugangsdaten auf der Verbindungsstrecke zwischen den beiden Rechnern durch eine Analyse
des Netzwerkverkehrs einfach ermittelt werden könnten. Um eine derartige Verbindung zu
realisieren, muss die VNC-Serversoftware direkt aus dem Internet erreichbar sein. Das kann
dazu führen, dass Sicherheitslücken in der Implementation der Software genutzt werden können,
um einen unbefugten Zugriff auf den Server zu erlangen.
Im Teilbild B der Abbildung 7.11 wird ein SSH-Tunnel genutzt. Dabei baut der VNC-Client keine
direkte Verbindung zum VNC-Server auf, sondern verbindet sich mit dem VNC-Serverport (Port
5900) des lokalen Rechners. Auf diesem Port “lauscht” die SSH-Software und reicht alle eingehenden Daten über eine verschlüsselte Verbindung (ausgehend von Port 22 des Client-Rechners,
76
dargestellt als grüne Linie) weiter an den SSH-Serverprozess des Servers (auf Port 22). Der SSHServer-Prozess des Servers seinerseits reicht die Daten über eine lokale Verbindung an den Port
5900 des VNC-Serverprozesses weiter. Bei diesem Prozess laufen alle ungesicherten Verbindungen jeweils nur lokal auf einem Rechner ab, so dass sie nicht abgehört werden können.
3. Secure Copy (SCP)
SCP kann dazu genutzt werden, einzelne Dateien, einzelne Verzeichnisse oder auch ganze
Verzeichnisstrukturen über das Netzwerk auf einen entfernten Rechner zu kopieren. Zu den
meisten SSH-Programmpaketen gehört auch ein SCP-Client. SSH-Server beherrschen immer
auch SCP.
Im Gegensatz zum häufig für Dateitransfers genutzten File Transfer Protocol (FTP) wird bei
SCP nur ein einzelner Port (Port 22) benötigt. Beim FTP hingegen wird neben einem Port für
die Kontrollverbindung für jede zu übertragende Datei eine neue Socket-Verbindung auf einem
neuen Port geöffnet. Sollen sehr viele Dateien kopiert werden, kann es passieren, dass nicht
ausreichend viele Sockets zur Verfügung stehen. Dann bricht die Übertragung der Dateien plötzlich ab. SCP hingegen überträgt auch sehr viele Dateien und sehr tiefe Verzeichnisstrukturen
zuverlässig ohne Abbrüche.
Ein weiterer Vorteil von SCP besteht in der Möglichkeit, die Daten zur Übertragung zu komprimieren. So lässt sich die zur Verfügung stehende Bandbreite optimal nutzen und das Übertragungsvolumen minimieren.
Authentifikationsmechanismen bei der Nutzung von SSH
SSH besitzt verschiedene Sicherheitsmechanismen für die Authentifikation von Rechnern und
Nutzern, um sogenannte Man-in-the-Middle-Attacken zu unterbinden, bei denen die Kommunikation auf dem Weg zwischen zwei Rechnern von einem weiteren Rechner abgefangen und
manipuliert wird.
Die Authentifikation des Rechners, mit dem kommuniziert werden soll, erfolgt mit Hilfe von
sogenannten hostkeys. Bei der Installation einer SSH-Serversoftware wird der hostkey für diesen
Rechner per Zufallsprinzip erzeugt. Verbindet sich ein SSH-Client mit einem SSH-Server, wird
zunächst der hostkey zum Client übertragen und dort überprüft. Dabei gibt es drei mögliche
Szenarien:
1. Der hostkey ist unbekannt:
Der Nutzer wird gefragt, ob der hostkey akzeptiert werden soll. Stimmt der Nutzer zu,
wird der hostkey zusammen mit dem Hostnamen oder der IP-Adresse des Kommunikationspartners dauerhaft lokal gespeichert. Unter Linux erfolgt z. B. der Eintrag im homeVerzeichnis des Nutzers und zwar im Verzeichnis .ssh in der Datei known_hosts. Danach
wird die Nutzerauthentifikation durchgeführt.
A:
Client
VNC
B:
Server
Port
Port
5900
5900
Client
VNC
77
VNC
Server
Port
Port
5900
5900
5900
5900
SSH
VNC
SSH
22
22
verschlüsselte sichere Verbindung
unverschlüsselte unsichere Verbindung
Abbildung 7.11: Teilbild A: unsichere VNC-Verbindung über das Internet
Teilbild B: Eine VNC-Verbindung wird über eine SSH-Verbindung sicher durch
das Internet getunnelt.
78
2. Der hostkey ist bekannt und stimmt mit dem für den Kommunikationspartner lokal gespeicherten Schlüssel überein:
Der Verbindungsaufbau wird mit der Nutzerauthentifikation fortgesetzt.
3. Der hostkey stimmt nicht mit dem für den Kommunikationspartner gespeicherten Schlüssel
überein:
Der Verbindungsaufbau wird mit einer Warnmeldung abgebrochen.
Neben der Nutzerauthentifikation per Login und Passwort bietet SSH noch die Möglichkeit der
Verwendung von Schlüsselpaaren. Diese bestehen aus einem privaten und einem öffentlichen
Schlüssel. Sie werden unter Linux z. B. mit dem Programm ssh-keygen erzeugt. Soll die
Authentifikation mittels Schlüsselpaar bewerkstelligt werden, muss auf dem Rechner, zu
dem die Verbindung aufgebaut werden soll, der öffentliche Schlüssel hinterlegt werden. In
einem challenge-response-Verfahren weist sich der Client gegenüber dem Server aus. Dabei
verschlüsselt der Server Nachrichten mit dem öffentlichen Schlüssel des Clients, die nur der
Client mit seinem privaten Schlüssel wieder entschlüsseln kann.
Lässt man nur die Authentifikation mittels Schlüsselpaaren zu, ergibt sich dadurch ein Sicherheitsvorteil. Sogenannte Wörterbuchattacken, bei denen die Inhalte ganzer Wörterbücher
als Login/Passwort-Kombinationen per Skript automatisch durchprobiert werden, können bei
diesem Verfahren komplett unterbunden werden.
Bei der Authentifikation mit Schlüsselpaaren werden diese meist mit einer Art Passwort, der sogenannten Passphrase geschützt. Es können jedoch auch Schlüsselpaare ohne Passphrase erzeugt
werden. Das ermöglicht die Automatisierung von Prozessen, welche die SSH für die Verbindung
zwischen zwei Rechnern nutzen.
Implementationen von SSH
SSH ist für alle gängigen Betriebssysteme verfügbar. Für Linux gibt es z. B. das Paket OpenSSH
[175], für Microsoft Windows z. B. die Programme putty [92] und WinSCP [227]. Für die Verwendung auf Embedded Systems stehen spezielle Versionen mit verringertem Funktionsumfang
wie z. B. DropBear [14] zur Verfügung.
Viele Netzwerkdienste, die eigentlich unverschlüsselt arbeiten, können auch in einem Modus
betrieben werden, in dem sie SSH zur gesicherten Datenübertragung benutzen. Beispiele
dafür sind das Tool rsync zum Abgleich von Datenbeständen verschiedener Rechner und das
Versionsverwaltungssystem subversion.
SSH ist eine Client-Server-Applikation, d. h. eine SSH-Verbindung kann nur von einem SSHClient zu einem SSH-Server aufgebaut werden. Der SSH-Server “lauscht” dazu auf Port 22
(Portzuweisungen erfolgen durch die Internet Assigned Numbers Authority (IANA) [107].).
79
7.5.6 rsync
Das Tool rsync dient zum Abgleich von Dateien, Verzeichnissen oder ganzen Verzeichnisbäumen
zwischen verschiedenen Rechnern. Es ist unter [189] als Quellcode verfügbar. Dort gibt es auch
fertige Installationspakete für zahlreiche Betriebssysteme. Bei den meisten Linux-Distributionen
gehört rsync zum Standard-Installationsumfang.
Die große Stärke dieses Tools besteht darin, dass bei Unterschieden zwischen zwei Dateien
nicht die komplette aktuellere Version übertragen werden muss, sondern nur die wirklich unterschiedlichen Teile über das Netzwerk transportiert werden. Damit ist es möglich, in kürzeren
Zeitintervallen Messdaten von einem Messrechner mit einem zentralen Server abzugleichen,
ohne dadurch signifikant mehr Datenverkehr zu erzeugen als beim einmaligen Kopieren eines
fertigen Tagesdatensatzes. Bei Internetverbindungen mit hohen Kosten für das Transfervolumen
(z. B. Verbindungen per GPRS) wird dadurch häufiges Abgleichen überhaupt erst bezahlbar.
rsync kann als eigenständiges Programm im Client-Server-Betrieb genutzt werden. Dazu muss
auf einem System ein rsync-Serverprozess laufen. Der Datentransfer erfolgt dann auf Port
873. Für Embedded Systems, die per Internet vernetzt sind, ist diese Betriebsart jedoch eher
ungeeignet, weil dazu auf beiden Seiten der entsprechende Port verfügbar sein muss. Dazu
ist oftmals eine Umkonfiguration der Firewalls notwendig und es können außerdem auch
Sicherheitsrisiken bei der Authentifizierung entstehen.
Für verteilte Monitoring- und Regelungssysteme bietet sich die Nutzung von rsync zusammen
mit der im Abschnitt 7.5.5 beschriebenen Secure Shell SSH an. Die Kommunikation zwischen
zwei Rechnern, deren Datenbestände synchronisiert werden sollen, erfolgt dann über eine verschlüsselte Verbindung auf Port 22, dem SSH-Standardport. Außer dem Einspielen der Installationspakete von rsync und SSH sind keine weiteren Konfigurationsarbeiten notwendig.
Da rsync ein Kommandozeilen-Tool ist, lässt es sich sehr gut automatisiert betreiben, indem es
z. B. aus Shell-Skripten heraus aufgerufen wird. Prinzipiell wird rsync immer mit dem Befehl
rsync <Quelle> <Ziel>
aufgerufen. Über zusätzliche Parameter kann das Verhalten von rsync hinsichtlich der Behandlung von symbolischen Links, Dateiattributen, Zeitstempeln, etc. beeinflusst werden. Folgendes
Beispiel soll das verdeutlichen. Der Aufruf
rsync -e ssh -a -z messrechner:/home/data /Messdaten
bewirkt, dass alle Dateien aus dem Verzeichnis /home/data, die auf dem Rechner messrechner
liegen, in das Verzeichnis Messdaten auf dem abfragenden Rechner kopiert werden. Durch den
Schalter -e ssh wird die Verbindung über eine Secure Shell abgewickelt. Der Schalter -a steht für
80
archive mode und bewirkt eine Beibehaltung von symbolischen Links, Dateiattributen, Schreibrechten usw. Um das Transfervolumen über das Netzwerk zu minimieren, kann mit -z eine Datenkompression für die Übertragung per Netzwerk eingeschaltet werden.
7.6 Überwachung von Verteilten Systemen
Beim Betrieb von verteilten Monitoring- und Regelungssystemen muss der Zustand der einzelnen Rechner möglichst automatisch überprüft werden, um Ausfälle schnell zu registrieren und
die Ausfallzeiten damit zu minimieren. Entsprechend der zur Verfügung stehenden NetzwerkBandbreite und Leistungsfähigkeit der verteilten Rechner können dazu ganz verschiedene Tools
zum Einsatz kommen. Bei leistungsstarken Systemen und schnellen Internet-Verbindungen, deren Datenvolumina nicht begrenzt sind, können verteilte Systeme komfortabel mit Tools wie
Smokeping und Nagios kontrolliert werden.
7.6.1 Smokeping
Abbildung 7.12: Screenshot vom Webinterface der Überwachungssoftware Smokeping
Die Qualität der Internetverbindung zwischen dem Überwachungsrechner und
einem zu überwachenden Server wird über einen Zeitraum von 3 h dargestellt.
7.6. ÜBERWACHUNG VON VERTEILTEN SYSTEMEN
81
Zur Überwachung der generellen Erreichbarkeit eines Rechners werden oftmals ICMP Echo
Requests (ICMP = Internet Control Message Protocol) – auch Ping-Pakete genannt – eingesetzt, die der angefragte Rechner jeweils mit einem ICMP Echo Reply beantwortet. Dieser
Mechanismus wird von der Software Smokeping genutzt, um die Verfügbarkeit und die Güte
von Internetverbindungen zu messen. Zu diesem Zweck schickt Smokeping in regelmäßigen
Zeitabständen jeweils 20 ICMP Echo Requests, zählt die mit einem ICMP Echo Reply beantworteten Pakete und misst die Zeit zwischen Anfrage und Antwort. Die dabei ermittelten Daten
werden grafisch aufbereitet und per Webserver zur Verfügung gestellt. Zusätzlich können bei
der Feststellung eines kompletten Verbindungsausfalls automatisch Emails an Wartungspersonal
verschickt werden.
In Abb. 7.12 ist ein von Smokeping generierter Report für einen Zeitraum von drei Stunden abgebildet. Die durchschnittliche Laufzeit der ICMP-Pakete betrug ca. 120 ms. Über die Farbgebung
wird im Diagramm die Anzahl der beantworteten ICMP Echo Requests kodiert. Im Normalfall
gehen keine Pakete verloren, was durch die Farbe Grün dargestellt wird. Die Farbe Rot deutet
auf einen Verlust aller verschickten ICMP-Pakete hin. Solche Paketverluste können mit einem
Abbruch und Wiederaufbau der PPPoE-Verbindung des DSL-Zugangs, über den der überwachte
Rechner an das Internet angebunden ist, erklärt werden.
7.6.2 Nagios
Abbildung 7.13: Screenshot vom Webinterface der Monitoring-Software Nagios
82
Nagios [165] ist eine Open-Source-Monitoring-Software, die zur Überwachung von Rechnern
und Netzwerken dient. Es überprüft die Verfügbarkeit von Netzwerkdiensten (z. B. HTTP, SSH,
PING) auf entfernten Rechnern über das Netzwerk. Beim Ausfall der Dienste werden per Email
oder SMS Warnmeldungen verschickt. Neben den automatisch verschickten Warnmeldungen
bietet Nagios auch noch ein Web-Interface (siehe Abb. 7.13), das die Zustände der überwachten
Rechner und die überwachten Dienste auf diesen Rechnern darstellt. Der Betrieb von Nagios ist
aber nur bei größeren Netzwerken sinnvoll, da die Einrichtung der Software sehr komplex und
zeitintensiv ist.
7.6.3 Sonderlösungen für per GSM vernetzte Systeme
Bei verteilten Systemen, die per GSM (siehe Abschnitt 7.3.1) vernetzt sind, besteht die Notwendigkeit, sehr sparsam mit dem übertragenen Datenvolumen umzugehen, da sonst sehr schnell
erhebliche Kosten entstehen. Tools wie das in Abschnitt 7.6.2 beschriebene Nagios sind nicht
mit dem Ziel entwickelt worden, sparsam mit dem Transfervolumen umzugehen, so dass sie für
die Überwachung von GSM-basierten Systemen eher ungeeignet sind. Außerdem fehlen ihnen
für die Überwachung der GSM-Funktionalität einige notwendige Funktionen.
Wenn die im Abschnitt 7.6.1 beschriebenen ICMP-Pakete häufig verschickt werden, können
schnell mehrere Megabyte an Transfervolumen entstehen. Bei GSM-Verbindungen, die nach
Daten-Transfervolumina abgerechnet werden, muss die Anzahl der Anfragen stark begrenzt werden. Sinnvoll ist z. B. das “Anpingen” aller verteilten Rechner in einem 24 h-Intervall. Dabei kann
eine jeweils definierte Anzahl von Paketen geschickt werden. Anschließend wird ausgewertet,
wie viele dieser Pakete beantwortet wurden und welche Laufzeiten dabei auftraten. Rückschlüsse auf die Verbindungsqualität werden damit möglich.
mobil-rda033
mobil-rda034
mobil-rda035
mobil-rda036
mobil-rda048
(5
(5
(5
(5
(5
tries,timeout:100s)
tries,timeout:100s)
tries,timeout:100s)
tries,timeout:100s)
tries,timeout:100s)
0% percent!
100.00% percent!
100.00% percent!
100.00% percent!
60.00% percent!
Abbildung 7.14: Auszug aus einem automatisch generierten Report über die Erreichbarkeit von
per GSM vernetzten Systemen
Dialcounter überwacht kostenträchtige Mobilfunk-Verbindungsaufbauten
GSM-Verbindungen haben nur eine begrenzte Lebensdauer, da die Mobilfunkprovider im
Normalfall mindestens alle 24 h die Verbindung abbauen. Beim Verbindungsaufbau müssen
zwischen dem mobilen System und der Basisstation Informationen ausgetauscht werden (Authentifikation, IP-Adressen, Gateway, DNS-Server, . . . ). Das bei diesem Informationsaustausch
83
anfallende Datenvolumen ist kostenpflichtig. Solange nur alle 24 h eine Neueinwahl stattfinden
muss, ist das unproblematisch. Es kann jedoch passieren, dass durch technische Probleme beim
Betrieb der mobilen Station deutlich häufiger Neueinwahlen durchgeführt werden. Z. B. fanden
bei einem Monitoringsystem für eine Wärmepumpe durch Probleme bei der Spannungsversorgung über einen längeren Zeitraum ständig Neueinwahlen in ca. 15minütigen Intervallen statt.
Das dabei angefallene Transfervolumen verursachte innerhalb eines Monats Kosten in Höhe von
ca. 1.200 e.
Um ungewollt häufige Einwahlen eines mobilen Systems frühzeitig registrieren zu können und
damit das Entstehen solch hoher Kosten zu verhindern, wurde für das im Kapitel 15.1 beschriebene Monitoringsystem die Software DialCounter entwickelt. Sie wird auf dem System installiert,
welches sich per GSM ins Internet einwählt, und zählt alle Einwahlversuche und erfolgreichen
Einwahlen. Die nicht erfolgreichen Versuche müssen mitgezählt werden, da – je nach Fehlerursache – auch bei diesen Versuchen ein Datentransfervolumen anfallen kann. DialCounter loggt
die Anzahl der Einwahlversuche lokal in einem File mit. Eine Mess-Software auf dem System
kann den Inhalt dieses Files über einen zusätzlichen Messkanal ebenfalls mitloggen. Anhand der
Messdatensätze lässt sich die zeitliche Verteilung der Einwahlen nachvollziehen. Mit Hilfe dieser Verteilung kann die Fehleranalyse stark vereinfacht werden.
Das vom DialCounter erzeugte File oder die Messdatenfiles werden regelmäßig von einem zentralen Server abgerufen. Auf diesem Rechner läuft eine zusätzliche Software, die die Dateien
analysiert. Sie verschickt bei einem zu schnellen Ansteigen der Anzahl der Einwahlen bzw. Einwahlversuche eine Alarm-Email an das Wartungspersonal. Diese Email-Funktionalität wurde
bewusst nicht in DialCounter integriert, da zum Versand von Emails auf jedem mobilen Knoten
eine Email-Software laufen müsste. Das würde unnötig Systemressourcen beanspruchen.
Kontrolle des übertragenen Datenvolumens
Verträge zur Datenübertragung über Mobilfunknetze beinhalten in der monatlichen Grundgebühr oftmals ein Freivolumen an zu übertragenden Daten. Wird dieses überschritten, fallen pro
übertragene Datenmenge zusätzliche Gebühren an. Die Abrechnung erfolgt überlicherweise
in 10KB-Blöcken. In der Regel wird ein Vertrag gewählt, bei dem das Freivolumen dem
erwarteten Transfervolumen angepasst ist. Die übertragene Datenmenge sollte während des
Betriebs in regelmäßigen Intervallen überprüft werden (z. B. alle 24 h), um Überschreitungen
des Freivolumens zu vermeiden.
Bei der Nutzung des Betriebssystems Linux kann der Inhalt der Datei /proc/net/dev oder
die Ausgabe des Tools ifconfig genutzt werden, um das bisher angefallene Transfervolumen
einer Internetverbindung zu ermitteln. ifconfig dient normalerweise dazu, Netzwerkinterfaces
zu konfigurieren (z. B. Einstellung von IP-Adresse, Gateway, etc.). Ruft man ifconfig ohne
zusätzliche Parameter auf, wird die aktuelle Konfiguration der Netzwerkinterfaces ausgegeben.
In der Abbildung 7.15 ist die Ausgabe von ifconfig für das Netzwerk-Device ppp0 eines
Embedded Systems dargestellt. Der Name ppp0 für das Device kommt dadurch zustande,
84
dass Netzwerkverbindungen per GSM über das Point-to-Point Protocol (PPP) abgewickelt
werden. In der letzten Zeile der Ausgabe wird hinter RX bytes die Anzahl der empfangenen
und hinter TX bytes die Zahl der gesendeten Bytes angegeben. Mittels einfacher Shell-Skripten
kann die Ausgabe von ifconfig gefiltert werden, so dass nur noch die RX- und TX-Volumina
ausgegeben werden. Diese können dann von einer ohnehin vorhandenen Mess-Software als
weiterer Messkanal mitgeloggt werden. Ein zentraler Server, der die Messdaten von vielen
per GSM angebundenen Systemen abruft, kann die Daten hinsichtlich der Transfervolumina
überprüfen und bei drohender Überschreitung von Freikontingenten per Email einen Alarm
auslösen.
ppp0
Link encap:Point-to-Point Protocol
inet addr:192.168.36.20 P-t-P:192.168.254.254
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1200 Metric:1
RX packets:17271 errors:0 dropped:0 overruns:0 frame:0
TX packets:17402 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1669221 (1.5 MiB) TX bytes:1763408 (1.6 MiB)
Abbildung 7.15: Ausgabe von ifconfig für eine PPP-Verbindung per GSM
In der Abbildung 7.16 ist die Verteilung des übertragenen Datenvolumens für eines der im Kapitel 15.1 beschriebenen Messsysteme innerhalb eines Tages dargestellt. Die blaue Kurve stellt
das gesendete Datenvolumen, die schwarze das empfangene Datenvolumen dar. Der kontinuierliche Anstieg beider Kurven über den Tag entsteht durch die Synchronisation der Systemzeiten
der Embedded Systems mit einem Zeitserver (siehe Abschnitt 7.5.3) sowie durch ICMP-EchoRequests zur Kontrolle der GSM-Verbindung. In der Abbildung ist um ca. 00:30 Uhr ein sprunghafter Anstieg der gesendeten Datenmenge zu verzeichnen. Zu dieser Zeit hat der Abrufrechner
das Messdatenfile des Vortages abgerufen. Die kleinen Anstiege beider Kurven um ca. 14:00 Uhr
entstehen durch die Überprüfung der Funktion des Messsystems mittels Fernwartung.
85
Abbildung 7.16: Verteilung des innerhalb von 24 h von einem Messsystem per GSM übertragenen Datenvolumens
86
Kapitel 8
Sicherheitsaspekte bei der Nutzung von
Internet-Technologie
Grundsätzlich muss die Übertragung von Daten über das Internet als unsicher gelten. Da kein
Einfluss darauf genommen werden kann, über welche Zwischenstationen Daten von einem Rechner durch das Internet zu einem anderen Rechner gelangen, muss davon ausgegangen werden,
dass die Daten unterwegs abgehört und/oder verfälscht werden können. Es gibt deshalb zahlreiche Technologien, mit denen die unsichere Übertragung per Internet abgesichert werden kann.
Neben den Gefahren bei der Datenübertragung stellen Angriffe aus dem Internet auf Rechner
mit Internetzugang ein sehr großes Gefahrenpotential dar. Diesen Gefahren kann mit entsprechenden Sicherheitstechnologien wie Virtual Private Networks, Firewalls, verschlüsselten
Netzwerkdiensten und sicheren Netzwerkstrukturen begegnet werden.
“Sicherheit ist kein Zustand, sondern ein Prozess.” (Wau Holland, CCC [100], † 29. Juli 2001).
Sicherheitsmechanismen funktionieren nur dann zuverlässig, wenn sie stetig überprüft und der
aktuellen Bedrohungslage angepasst werden. Diese Aufgabe kann mit Hilfe von Sicherheitstools
stark vereinfacht werden.
8.1 Virtual Private Network (VPN)
Eine der sicherlich elegantesten Varianten zur Absicherung von Datenverkehr über das Internet
ist die Verwendung von Virtual Private Networks (VPNs). VPNs verbinden Rechner oder lokale
Netzwerke so miteinander, dass diese scheinbar Mitglieder eines gemeinsamen Netzwerks
sind (siehe Abb. 8.1). Dazu wird zwischen den Rechnern/Netzwerken eine verschlüsselte und
damit abgesicherte Verbindung aufgebaut, über die Kommunikation auf allen Ports transparent
weitergeleitet wird. Die Rechner, die ein VPN nutzen, arbeiten wie in einem lokalen Netzwerk,
in dem sie untereinander ohne Einschränkungen kommunizieren können. VPNs bieten sich
87
88
KAPITEL 8. SICHERHEITSASPEKTE BEI DER INTERNET-NUTZUNG
immer dann an, wenn die Rechner mehr als einen Dienst zur Kommunikation benutzen. Je
größer die Anzahl der Dienste ist, desto größer wird ohne ein VPN der Aufwand, sie alle gegen
Abhören und Einbrüche abzusichern. Bei mehreren Diensten lohnt sich deshalb sehr schnell ein
VPN.
lokales Netzwerk
ungesicherte Internetverbindung
VPN−Tunnel
VPN−Router
VPN−Router
Abbildung 8.1: Zwei lokale Netzwerke werden per VPN-Tunnel über das Internet verbunden.
Grundsätzlich sind zur Erstellung eines VPNs drei Dinge notwendig:
Ausreichende Bandbreite: Durch die Verschlüsselung des VPNs entsteht zusätzlich zum Datenverkehr ein Overhead, der im Vergleich mit einer unverschlüsselten Verbindung zu mehr
Bandbreitenbedarf führt. Eine DSL-Verbindung ist für ein VPN auf alle Fälle ausreichend.
Je nach Anwendung funktionieren VPNs auch über Mobilfunkverbindungen recht gut.
Verschlüsselung: Die Kommunikation innerhalb des VPN kann unverschlüsselt ablaufen. Es
muss deshalb dafür gesorgt werden, dass die Daten, die durch den VPN-Tunnel fließen,
auf dem Weg durch das unsichere Internet keinesfalls abgehört werden können. Eine starke
Verschlüsselung ist deshalb unabdingbar.
Zertifikate (digitale Ausweise): Damit nicht unbefugt auf ein per VPN gesichertes Netzwerk
zugegriffen werden kann, müssen sich Clients beim VPN-Zugangsrechner authentifizieren.
Die einfachste Lösung stellen dabei Passwörter dar. Sicherer sind jedoch Zertifikate, da sie
8.1. VIRTUAL PRIVATE NETWORK (VPN)
89
in beide Richtungen funktionieren. Der Client legitimiert sich beim VPN-Zugangsrechner
und umgekehrt.
Es gibt zahlreiche VPN-Technologien. Die gebräuchlichsten sind:
1. IP Security (IPSec)
IPSec ist im kommerziellen Bereich eine der am häufigsten anzutreffenden VPN-Varianten.
Zahlreiche Hardwarekomponenten wie z. B. VPN-Router sind auf dem Markt verfügbar.
Alle in großem Maßstab eingesetzten Betriebssysteme (Windows XP, Windows2000, aktuelle
Microsoft-Serverbetriebssysteme, Linux, Mac OS X, etc.) unterstützen IPSec von Haus aus. Es
gibt sehr viele verschiedene Implementationen von IPSec und gleichzeitig eine Vielzahl von
anzupassenden Parametern. Damit ist eine problemlose Interoperabilität zwischen verschiedenen IPSec-Stacks kaum möglich. Die Sicherheitsexperten Bruce Schneier und Niels Ferguson
schreiben in ihrem Paper A Cryptographic Evaluation of IPsec [191] dazu:
“IPSec is too complex to be secure.”
Ein weiteres Problem bei der Nutzung dieser Technologie ist der Wechsel von IP-Adressen des
IPSec-Servers bei Einwahlverbindungen. Oft entstehen dadurch Verbindungsabbrüche.
2. OpenVPN
OpenVPN [177] ist eine plattformübergreifende Technik, die es für alle wichtigen Betriebssysteme gibt. Sie bietet sich deshalb auch für mit Linux arbeitende Embedded Systems an. Im Gegensatz zu IPSec funktioniert sie auch bei wechselnden IP-Adressen. Dazu ist allerdings die Nutzung
eines dynamischen DNS-Dienstes notwendig (siehe Abschnitt 7.4.2). Die Basistechnologien von
OpenVPN sind Secure Socket Layer (SSL) und Transport Layer Security (TLS) (siehe Abschnitt
8.2). SSL wird z. B. bei der verschlüsselten Übertragung von Webseiten genutzt. TLS ist der
Nachfolger von SSL. Die von OpenVPN genutzte OpenSSL-Bibliothek [176] ist sehr gut auf
Sicherheitslücken untersucht worden. OpenVPN bietet ähnlich viele Parameter wie IPSec. Die
meisten davon werden jedoch auf Standardwerte gesetzt, so dass sich die Konfiguration deutlich
einfacher gestaltet als bei IPSec.
3. Point-to-Point Tunneling Protocol (PPTP)
PPTP ist seit der Einführung von Windows 98 OSR 2 Bestandteil aller Mitglieder der Microsoft
Windows-Familie. Es ist deshalb sehr stark verbreitet. Mittlerweile gibt es für alle wichtigen Betriebssysteme PPTP-Clients. Für Linux ist PPTP erst seit der Kernel-Version 2.6.14 verfügbar,
da Teile der Verschlüsselung (Microsoft Point-to-Point Encryption MPPE) lange irrtümlich als
patentgeschützt galten.
90
Anfänglich enthielt die PPTP-Implementierung der Firma Microsoft [156] sicherheitskritische
Fehler (siehe [192]), die aber mittlerweile behoben sind. Ein Schwachpunkt blieb jedoch
erhalten: Die Stärke der Verschlüsselung von PPTP hängt direkt von der Länge des gewählten
Passworts ab.
Ein weiterer Nachteil von PPTP ist die Notwendigkeit von zwei Socket-Verbindungen auf unterschiedlichen Ports. Dadurch wird die Konfiguration von Firewalls für PPTP erschwert.
4. Hamachi
Hamachi ist eine der am einfachsten zu konfigurierenden VPN-Varianten und deshalb bei privaten Anwendern sehr beliebt. Es ist jedoch nur für die Microsoft Windows-Betriebssystemfamilie,
für Mac OS X und für Linux verfügbar. VPN-Router und andere Netzwerk-Hardware, die Hamachi beherrschen, existieren nicht. Ein dedizierter VPN-Server wird im Gegensatz zu anderen
VPN-Varianten nicht benötigt, da die entsprechenden Leistungen sowie die Authentifikation von
Servern des Hamachi-Anbieters Applied Networking [98] bereitgestellt werden. Wegen der Abhängigkeit von den Servern dieser Firma verbietet sich eine Nutzung von Hamachi für professionelle Anwendungen. Außerdem kann nicht nachvollzogen werden, wie die Hamachi-Software
funktioniert, da sie nicht quelloffen ist. Es kann deshalb nicht garantiert werden, dass der Anbieter keinen Einblick in die per VPN übertragenen Daten hat.
Bewertung
In Tabelle 8.1 sind die Eigenschaften der verschiedenen VPN-Varianten zusammengefasst.
Open Source
Bestandteil des Betriebssystems
Komplexität der Konfiguration
Interoperabilität verschiedener
Implementationen
Von Servern Dritter abhängig
Aufwand der Firewall-Konfiguration
Sicherheit
IPSec
ja
ja
hoch
OpenVPN
ja
ja
mittel
PPTP
ja
ja
mittel
Hamachi
nein
nein
gering
gering
nein
mittel
groß
hoch
nein
gering
groß
mittel
nein
groß
mittel
ja
gering
gering
Tabelle 8.1: VPN-Varianten und ihre Eigenschaften
IPSec bietet sich dann an, wenn auf beiden Seiten der Verbindung gleiche Betriebssysteme
arbeiten oder IPSec-fähige Netzwerkhardware des gleichen Herstellers verwendet wird. Da
diese Hardware jedoch zusätzliche Kosten verursacht, empfiehlt es sich eher OpenVPN zu
nutzen.
8.2. SECURE SOCKET LAYER (SSL) UND TRANSPORT LAYER SECURITY (TLS)
91
OpenVPN kann ohne Zusatzhardware direkt auf einem Embedded System ausgeführt werden.
Es funktioniert auch bei wechselnden IP-Adressen, die bei den für verteilte Regelungssysteme
oft genutzten DSL- und GSM-Verbindungen häufig vorkommen.
PPTP ist zwar einfach einzurichten, kann aber beim Einsatz einiger Firewalls Probleme bereiten
und hat bei unachtsamer Konfiguration Sicherheitslücken. Es besitzt keine wesentlichen Vorteile,
die für seine Verwendung sprechen.
Hamachi scheidet für einen Einsatz in verteilten Regelungssystemen wegen der Abhängigkeit
von fremden Servern aus.
8.2 Secure Socket Layer (SSL) und Transport Layer Security
(TLS)
SSL wurde ursprünglich von der Firma Netscape [167] für den sicheren Transport von Daten
durch das Internet entwickelt. 1996 wurde SSL an die Internet Engineering Task Force IETF
[116] übergeben. Das Ergebnis der Standardisierung wurde 1999 unter dem Namen Transport
Layer Security (TLS) veröffentlicht (siehe dazu auch RFC2246 [123]). SSL und TLS sind in
großen Teilen identisch. TLS ist etwas sicherer als SSL, da es mit stärkerer Verschlüsselung arbeitet. Die Sicherheit wird bei SSL und TLS durch die Nutzung dreier verschiedener Mechanismen
gewährleistet:
Privatheit der Verbindung: Mittels symmetrischer Verschlüsselungsverfahren wird sichergestellt, dass der Klartext der übertragenen Daten nur den beiden Kommunikationspartnern
zugänglich ist.
Zuverlässigkeit der Verbindung: Durch den Einsatz von Message Authentifikation Codes
(MACs), einer Art Fingerprint-Verfahren, wird sichergestellt, dass die übertragenen Daten auf dem Übertragungsweg nicht modifiziert wurden.
Authentifikation: Die Nutzung von Zertifikaten stellt sicher, dass der jeweilige Kommunikationspartner auch derjenige ist, mit dem kommuniziert werden soll.
SSL und TLS bauen sichere Verbindungen zwischen zwei Sockets auf. Sie stellen den Anwendungen, die sie nutzen wollen, bestimmte Netzwerk-Funktionen zur Verfügung. Von zahlreichen
Protokollen zur Datenübertragung im Internet gibt es Versionen, die SSL oder TLS zur Absicherung benutzen, z. B. https zur Übertragung von HTML-Dokumenten und smtps zur Übertragung
von Emails. Außerdem ist SSL/TLS die Basistechnologie des im Abschnitt 8.1 beschriebenen
OpenVPN.
92
8.3 Secure Shell (SSH)
Die Secure Shell stellt weitere Mechanismen zur gesicherten Datenübertragung zur Verfügung.
Diese wurden im Abschnitt 7.5.5 detailliert beschrieben.
8.4 Firewalls
Firewalls dienen dazu, den Datenverkehr zwischen zwei Netzwerken (z. B. dem Internet
und einem privaten Netzwerk hinter einem DSL-Zugang) zu kontrollieren. Dabei sind die
beiden Netzwerke im typischen Fall unterschiedlich vertrauenswürdig, so dass unbefugte
Zugriffe vom weniger vertrauenswürdigen Netz in das vertrauenswürdigere unterbunden
werden müssen. Rechner eines verteilten Netzwerks, die über das Internet kommunizieren,
müssen auf alle Fälle durch Firewalls vor unbefugtem Zugriff aus dem Internet geschützt werden.
Es gibt ganz verschiedene Arten von Firewalls, von denen einige nachfolgend beschrieben werden sollen.
Einfache Paketfilter: Die Funktionsweise eines einfachen Paketfilters ähnelt der eines Routers.
Er betrachtet jeweils einzelne IP-Pakete und entscheidet, wie mit dem entsprechenden Paket verfahren werden soll. Dazu analysiert der einfache Paketfilter die Inhalte der Header
des entsprechenden IP-Pakets. Anhand eines Regelwerks wird dann entschieden, wie mit
dem Paket weiter verfahren wird. Es gibt drei Möglichkeiten, wie ein Paket behandelt werden kann:
• Das Paket wird angenommen und an den Empfänger weitergeleitet.
• Das Paket wird angenommen und verworfen. Das erscheint dem Absender des Pakets
so, als ob das Paket nie angekommen wäre.
• Das Paket wird abgelehnt. Es wird eine Fehlermeldung an den Absender geschickt.
Bei der Erstellung des Regelwerks für einen einfachen Paketfilter ist Vorsicht geboten. Der
Filter sollte zunächst so konfiguriert werden, dass jeglicher Datenverkehr durch die Firewall unterbunden wird. Danach wird der Filter so umkonfiguriert, dass nur Datenverkehr
für wirklich benötigte Dienste die Firewall passieren können.
Bsp.: Ein Regelungssystem soll aus dem Internet per Secure Shell (siehe Abschnitt 7.5.5)
erreichbar sein. Andere Netzwerk-Dienste sollen außen vor bleiben. Das Regelwerk des
Paketfilters muss dann so gestaltet sein, dass Anfragen für das Regelungssystem auf Port
22 (dem Port des SSH-Servers) durchgeleitet werden und auch Antworten des Regelungssystems wieder passieren dürfen. Alle anderen Pakete werden verworfen.
8.4. FIREWALLS
93
Zustandsorientierte Paketfilter arbeiten ebenfalls mit einem Regelwerk. Sie betrachten aber
nicht einzelne Pakete, sondern orientieren sich an Verbindungen. Dazu stellt die Firewall
dynamische Tabellen mit den aktuell bestehenden Verbindungen auf. Nach dem Aufbau
einer Verbindung werden alle weiteren Pakete dieser Verbindung automatisch zugelassen.
Bsp.: Rechner A will ein Dokument vom Webserver des Rechners B abfragen. Dazu baut
Rechner A eine Verbindung zu Rechner B auf und fordert das Dokument an. Die Firewall
lässt automatisch zu, dass Rechner B das angeforderte Dokument an Rechner A sendet.
Die Firewall würde aber einen Verbindungsaufbau von Rechner B zu Rechner A unterbinden.
Durch die Möglichkeit einer Bewertung von Verbindungen ist die Erstellung von Regelwerken für zustandsorientierte Paketfilter sehr viel einfacher zu bewerkstelligen als für
einfache Paketfilter. Außerdem entsteht durch zustandsorientierte Paketfilter zusätzliche
Sicherheit.
Der große Nachteil beider Arten von konventionellen Paketfiltern ist ihre Unfähigkeit, bösartige Inhalte im Datenstrom (z. B. Viren) zu erkennen. Deshalb wurden spezielle Paketfilter entwickelt, die sich nicht nur die Header der Pakete, sondern auch deren Inhalte anschauen (Inspection oder auch deep Inspection). Die Erkennung einer bösartigen Verwendung von Protokollen ist jedoch sehr aufwändig, da praktisch jede mögliche Abweichung
einzeln durch den Paketfilter abgefangen werden muss.
Application-Layer-Firewall (Proxy): Proxies filtern auf der Basis von Applikationsprotokollen. Der Proxy implementiert dazu das Applikationsprotokoll und kann deshalb seine korrekte Verwendung überprüfen. Abweichungen vom Applikationsprotokoll werden nicht
zugelassen. Der Proxy funktioniert dabei als eine Art man in the middle. Anfragen eines
Clients gehen nicht, wie in Abb. 8.2, Teilbild A, direkt an einen Server, sondern werden
an den Proxy gerichtet (Teilbild B). Der Proxy prüft die Anfrage auf Korrektheit und stellt
selbst eine inhaltsgleiche Anfrage an den Server. Die Antwort des Servers wird dann vom
Proxy ebenfalls auf Korrektheit geprüft und dann an den Client weitergeleitet. Eine direkte
Kommunikation zwischen Client und Server findet nicht statt.
Während Paketfilter universell funktionieren, muss für jedes Applikations-Protokoll ein
eigener Proxy implementiert werden, was sich sehr aufwändig gestalten kann. Bei sehr
komplexen Protokollen ist die Implementierung eines Proxies manchmal gar nicht möglich. Außerdem ist die Protokollanalyse sehr rechenintensiv, so dass es sehr schwierig sein
kann, eine ausreichend schnelle Verarbeitung der Datenströme durch einen Proxy zu gewährleisten.
Viele Hardware-Router besitzen heute Firewall-Funktionalität (Paketfilter). Dabei wird die
in Abschnitt 7.4.1 beschriebene Network Address Translation oft auch von der Firewall
durchgeführt. Generell empfiehlt es sich, die Firewall immer auf einer von den zu schützenden
Rechnern unabhängigen Hardware zu betreiben. Das kann ein Hardware-Router, eine separate
Hardware-Firewall oder auch ein dedizierter Rechner mit Firewall-Software sein.
94
A:
Anfrage
Antwort
Client
Web−Server
B:
"man in the middle"
Client
Anfrage
Anfrage
Antwort
Antwort
Proxy
Web−Server
Abbildung 8.2: A: Direkte Kommunikation zwischen Client und Webserver
B: Nutzung eines Proxies zur Kommunikation zwischen Client und Webserver
So genannte personal Firewalls sind zwar besser als gar keine Firewall, stellen aber keine
Alternative zu einer dedizierten Firewall dar, da sie, zumindest für abgehende Verbindungen,
recht leicht zu umgehen sind.
8.5 Sicherheitsaspekte bei Netzwerkstrukturen
Die Entwicklung von Betriebssystemen und Anwendungsprogrammen ohne Sicherheitslücken
ist praktisch nicht möglich. Oftmals werden diese Lücken erst entdeckt, wenn die Software
schon längere Zeit im Einsatz ist. Bei vielen Systemen kann die Software im laufenden Betrieb
aktualisiert werden (siehe dazu auch Abschnitt 7.5.4), um Sicherheitslücken zu schließen.
Bei großen Netzwerken mit vielen Rechnern ist das jedoch mit sehr viel Aufwand verbunden. Außerdem besteht immer die Gefahr, durch Updates die Funktionalität der Systeme zu
beeinträchtigen. Aus diesen Gründen werden bei Produktivsystemen (z. B. bei Rechnern in
der Leitwarte eines Stromversorgers) Sicherheitsupdates oft gar nicht oder nur in sehr großen
Zeitintervallen (z. B. einmal im Jahr) eingespielt.
Je nach genutzter Speichertechnologie ist es bei Embedded Systems im laufenden Betrieb oft
gar nicht möglich, Teile der Software auszutauschen, um Sicherheitslücken zu schließen. Die
dafür notwendigen Ausfallzeiten und der erforderliche Arbeits- und Zeitaufwand für Updates
haben häufig zur Folge, dass gar keine Updates eingespielt werden.
8.5. SICHERHEITSASPEKTE BEI NETZWERKSTRUKTUREN
95
Neben der installierten Software hat die Netzwerkstruktur, über die Rechner mit dem Internet
verbunden sind, einen maßgeblichen Einfluss darauf, wie leicht sie angegriffen werden können.
Im Folgenden sollen beispielhaft einige Netzwerkstrukturen unter dem Aspekt der Sicherheit
betrachtet werden.
Direkter Internetzugriff
Eine direkte Verbindung mit dem Internet (siehe Abb. 8.3) stellt den sicherheitstechnisch
ungünstigsten Fall dar. Bei einer solchen Netzwerkstruktur sind alle Rechner Angriffen aus
dem Internet direkt ausgesetzt. Sie müssen deshalb fortwährend softwaretechnisch aktualisiert
werden. Die Anzahl der vom Internet aus sichtbaren Dienste muss möglichst gering gehalten
werden. Je mehr Dienste sichtbar sind, um so mehr mögliche Sicherheitslücken in diesen
Diensten können genutzt werden, um das System anzugreifen. Alle Dienste sollten daher per
Secure Socket Layer (SSL) genutzt oder per Secure Shell (SSH) abgesichert werden. Zusätzlich
ist die Nutzung einer lokalen Firewall sehr zu empfehlen.
Abbildung 8.3: Rechner mit direktem Zugang zum Internet
Die Kommunikation zwischen den direkt mit dem Internet verbundenen Rechnern muss auf
alle Fälle verschlüsselt abgewickelt werden. Bei unverschlüsselter Kommunikation wäre es sehr
einfach, die Zugangsdaten zu den Rechnern aus dem Datenstrom herauszulesen, so dass die
Systeme komplett kompromittiert wären. Die Systemressourcen der Rechner eines verteilten
Systems müssen so ausgelegt sein, dass diese Rechner neben ihren eigentlichen Aufgaben auch
noch die Firewall-Funktionalität und die Verschlüsselung bewältigen können.
Mit Rechnern, die nicht updatefähig sind, darf eine solche Infrastruktur nicht genutzt werden, da
sie viel zu leicht angreifbar wären.
96
Absichern von Rechnern mit Firewall-Routern
Bei verteilten Netzwerken aus Embedded Systems ist es sinnvoll, Sicherheitsaufgaben möglichst
nicht von den Kleinrechnern, sondern von dedizierten Geräten wie z. B. Firewall-Routern
durchführen zu lassen.
Bei einer Netzwerkstruktur mit Firewall-Routern (siehe Abb. 8.4) schotten diese Geräte die
Embedded Systems vor direkten Zugriffen aus dem Internet weitgehend ab. Die Router werden
so konfiguriert, dass sie Anfragen aus dem Netz nur an wirklich notwendige Dienste (wie z. B.
Secure Shell SSH) weiterleiten (vergleiche Port Forwarding, siehe Abschnitt 7.4.1).
Die Kommunikation muss auch bei dieser Netzwerkstruktur aus den schon weiter oben genannten Gründen verschlüsselt erfolgen, so dass entsprechend leistungsstarke Embedded Systems
benötigt werden.
Auch bei einer Netzwerkstruktur mit Firewall-Routern haben alle Embedded Systems direkten
Zugang zum Internet.
Router
mit
Firewall
Abbildung 8.4: Rechner mit Internet-Zugang per Firewall-Router
Bsp.: Einige der im Abschnitt 15.1 beschriebenen Messsysteme sind per DSL an das Internet
angebunden, da an ihren Standorten eine Anbindung per GPRS nicht möglich ist. Die verwendeten Embedded Systems sind nicht leistungsstark genug, um neben ihren Messaufgaben zusätzlich
noch eine Firewall-Funktionalität zu bewerkstelligen. Deshalb kommen Firewall-Router vom Typ
WRT54GS der Firma Linksys [147] zum Einsatz. Aus dem Internet sind die Embedded Systems
nur per Secure Shell auf Port 22 erreichbar. Anfragen auf alle anderen Ports werden durch die
Firewalls der Router abgeblockt.
8.5. SICHERHEITSASPEKTE BEI NETZWERKSTRUKTUREN
97
Virtuelle Netzwerke mit VPN-Routern
Kommen VPN-Router zum Einsatz (VPN = Virtual Private Network, siehe Abschnitt 8.1),
spannen diese zwischen den verteilten Rechnern ein virtuelles Netz auf (siehe Abb. 8.5). Die
Kommunikation zwischen den Routern wird dabei automatisch verschlüsselt abgewickelt.
Daraus ergibt sich der Vorteil, dass die Embedded Systems die zu übertragenden Daten nicht
selber verschlüsseln müssen. Sie können deshalb entsprechend leistungsarm ausgelegt werden.
Die Datenübertragung zwischen den Routern durch das Internet ist bei dieser Struktur sehr
sicher. Ein lokaler Angreifer kann aber den Datenverkehr zwischen Embedded Systems und
Routern leicht abhören, da dieser unverschlüsselt stattfindet. Eine solche Netzwerkstruktur ist
deshalb nur sinnvoll, wenn man einen unbefugten lokalen Zugriff sicher ausschließen kann.
VPN−Router
verschlüsselte Verbindung
unverschlüsselte Verbindung
Abbildung 8.5: Netzwerk aus per VPN verbundenen Rechnern
Da bei einer Netzwerkstruktur mit VPN-Routern keine Netzwerkdienste der Embedded Systems
direkt im Internet sichtbar sind, können die Embedded Systems auch nicht direkt angegriffen
werden. Sie haben allerdings auch keinen direkten Zugriff auf das Internet.
Bei einer Netzwerk-Struktur mit VPN-Routern müssen alle Sicherheitslücken der VPN-Router
sehr schnell geschlossen werden, da ein Einbruch in diese Router aufgrund der unverschlüsselten
Kommunikation zwischen den Embedded Systems gleich das komplette Netzwerk kompromittieren würde.
98
Bsp.: Für ein Photovoltaik-Monitoring-System des Fraunhofer ISE werden UMTS-Router mit
VPN-Funktion genutzt. Die von den Embedded Systems im Feld aufgenommenen Messdaten der
PV-Anlagen werden über einen OpenVPN-Tunnel regelmäßig in die Datenbank eines zentralen
Abrufservers übertragen.
Trusted Network
Befinden sich alle Embedded Systems eines verteilten Systems in einem dedizierten Netzwerk,
kann man von einem trusted network ausgehen (siehe Abb. 8.6). Die Embedded Systems können
in diesem Netzwerk unverschlüsselt kommunizieren, ohne dass Angriffe aus dem Internet zu befürchten sind. Angriffe können nur von innerhalb des Netzes durchgeführt werden. Soll aus dem
Internet ein Zugang zu dem Netzwerk geschaffen werden, kann dies mit einem Zugangsrechner
bewerkstelligt werden. Dieser Rechner führt kein Routing zwischen dem Internet und dem Netz
der Embedded Systems durch. Dadurch kann weder aus dem Internet auf die Embedded Systems,
noch umgekehrt direkt zugegriffen werden. Der Zugangsrechner dient nur als “Sprungbrett”. Ein
Zugriff auf die Embedded Systems kann aus dem Internet nur indirekt erfolgen, indem sich der
Nutzer zunächst auf dem Zugriffsrechner einloggt. Erst von dort aus kann er eine Verbindung zu
den Embedded Systems aufbauen. Der “wunde Punkt” dieser Netzwerkstruktur ist der Zugangsrechner. Alle Sicherheitslücken dieser Maschine müssen schnellstmöglich gepatched werden, da
von ihr aus das Netzwerk der Embedded Systems sehr einfach angegriffen werden kann.
Switch
Zugangsrechner
mit Firewall
Abbildung 8.6: Trusted network hinter einem Zugriffsrechner mit Firewall
Bsp.: Bei dem im Abschnitt 15.2 beschriebenen Power Flow and Power Quality Management
System trennt ein zentraler Server mit zwei Netzwerk-Interfaces das Regelungs-Netzwerk vom
Internet. Ein Zugriff auf die Embedded Systems des Regelungssystems ist nur über diesen Rechner möglich.
8.6. SICHERHEITSTOOLS
99
Angriffe aus dem lokalen Netzwerk
Angriffe aus dem lokalen Netzwerk können bei allen Netzwerkstrukturen stattfinden. Sie können
nur durch einen physikalischen Zugangsschutz unterbunden werden.
Weitere Sicherheitsrisiken ergeben sich durch die gemeinsame Nutzung von lokalen Netzwerken
durch verschiedene Nutzergruppen (z. B. gemeinsame Nutzung eines lokalen Netzwerks
durch Verwaltungsrechner und Produktionsanlagen). Dabei besteht immer die Gefahr, dass die
Mitglieder einer Nutzergruppe die Infrastruktur einer anderen Nutzergruppe angreifen.
Viele Systemadministratoren gehen davon aus, dass lokale Netzwerke auf der Basis von Ethernet, wie in Abschnitt 7.1.1 beschrieben, abhörsicher sind. Netzwerk-Switches bauen zwischen
den Kommunikationspartnern individuelle Verbindungen auf, so dass der Datenverkehr an
anderen Switch-Ports nicht mitgelesen werden kann. Mittels sogenanntem ARP-Spoofing (ARP
= Address Resolution Protocol) lassen sich Datenströme jedoch in lokalen Netzwerken sehr
einfach umleiten und können dann mitgelesen werden [84].
Netzwerk-Switches speichern die Zuordnungen zwischen Switch-Ports und MAC-Adressen
der angeschlossenen Netzwerkgeräte in einem speziellen Speicherbereich. Durch Überfluten
dieses Speichers mit sehr vielen MAC-Adressen schalten viele Switches in einen HUB-Modus
um. Bei diesem Modus werden alle vom Switch empfangenen Datenpakete an allen Ports
ausgegeben. Dadurch kann der komplette Netzwerkverkehr des Switches an einem einzelnen
Port “mitgelesen” werden. Ein Tool zum Überfluten von Switches mit zufälligen MAC-Adressen
ist z. B. macof aus der Netzwerk-Tool-Sammlung dsniff [159].
Für wirklich sicherheitskritische Anwendungen (z. B. die Steuerung von Produktionsrobotern) ist
es deshalb sehr wichtig, dass für sie Netzwerke betrieben werden, die von anderen Netzwerken
physikalisch getrennte sind. Ist das nicht möglich, sollte wenigstens mit Hilfe von Virtuellen
LANs (VLANs) eine logische Trennung der Netze stattfinden.
8.6 Sicherheitstools
Bei der Konfiguration von Netzwerken, Firewalls und Serverdiensten schleichen sich leicht
Fehler ein. Deshalb besteht die Notwendigkeit, Netzwerke und Rechner regelmäßig auf ihre Sicherheit zu überprüfen. Verschiedene Sicherheitstools ermöglichen eine effiziente Überprüfung
der Netzwerksicherheit.
Portscanner wie z. B. nmap [168] dienen dazu, offene Netzwerkports zu entdecken und unnötig
im Netzwerk sichtbare Netzwerkdienste zu finden. Da jeder unnötig sichtbare Netzwerkdienst
ein potentielles Angriffsziel ist, sollten Netzwerke regelmäßig mit Portscannern auf unnötige
Dienste untersucht werden.
100
Mit Vulnerability Scannern wie z. B. nessus [166] lassen sich Rechner weitgehend automatisiert
auf bekannte Sicherheitslücken in Betriebssystemen und Serverdiensten untersuchen.
Netzwerksniffer, wie z. B. Wireshark [228] protokollieren alle Datenpakete mit, die die Netzwerkkarte des Rechners “liest”. Sie ermöglichen damit eine sehr detaillierte Analyse des gesamten Netzwerkverkehrs.
8.6.1 Rechtliche Schwierigkeiten bei der Nutzung von Sicherheitstools
Mit dem 41. Strafrechtsänderungsgesetz zur Bekämpfung der Computerkriminalität (41.
StrÄndG) vom 7. 8. 2007 (siehe Bundesgesetzblatt Jahrgang 2007, Teil I, Nr. 38, Bonn, 10. August 2007 [33]) wurde der 15. Abschnitt des Strafgesetzbuches - Verletzung des persönlichen
Lebens- und Geheimbereichs (§§ 201 - 210) um den § 202c - den sogenannten Hackerparagraphen - erweitert:
§ 202c
Vorbereiten des Ausspähens und Abfangens von Daten
(1) Wer eine Straftat nach § 202a oder § 202b vorbereitet,
indem er
1. Passwörter oder sonstige Sicherungscodes, die
den Zugang zu Daten (§ 202a Abs. 2) ermöglichen,
oder
2. Computerprogramme, deren Zweck die Begehung einer
solchen Tat ist,
herstellt, sich oder einem anderen verschafft, verkauft,
einem anderen überlässt, verbreitet oder sonst zugänglich
macht, wird mit Freiheitsstrafe bis zu einem Jahr oder mit
Geldstrafe bestraft.
(2) § 149 Abs. 2 und 3 gilt entsprechend.
Die Gesetztesänderung war schon im Vorfeld von den beiden Branchenverbänden Bundesverband Informationswirtschaft Telekommunikation und neue Medien e. V. (BITKOM) [25] und
Verband der deutschen Internetwirtschaft e. V. (eco) [64], sowie vom Chaos Computer Club e.
V. (CCC) [40] stark kritisiert worden. So schreibt z. B. der CCC in seiner Pressemitteilung vom
25. September 2006 [41]:
Der Gesetzentwurf wird die Arbeitsgrundlagen von Sicherheitsberatern und Netzwerkexperten
unter Strafe stellen. Bereits der Besitz und die Verbreitung von Werkzeugen zur Netzwerkanalyse und zur Aufdeckung von Sicherheitslöchern in Rechnersystemen sollen strafbar werden. Die
Arbeit der Sicherheitsexperten wäre damit kaum mehr möglich und von ungerechtfertigter Kriminalisierung bedroht.
8.6. SICHERHEITSTOOLS
101
"Dieser Gesetzentwurf wird nicht gegen Computerkriminalität helfen. Stattdessen werden der ITSicherheitsbranche dringend benötigte Werkzeuge zur Aufdeckung von Schwachstellen aus der
Hand geschlagen", sagte CCC-Sprecher Andy Müller-Maguhn. "Die Vorstellungen des Gesetzgebers zeugen von einer ausgeprägten Unkenntnis der technischen Vorgehensweisen. Testangriffe
zum Auffinden von Sicherheitslöchern sind für die IT-Sicherheit wie Crashtests für die Autoindustrie. Niemand käme auf die Idee, Crashtests zu verbieten", kommentierte der CCC-Sprecher.
Verboten werden sollen sogenannte ’Hackertools’ und damit zugleich die öffentliche Diskussion
von Sicherheitslücken. Der allgemein akzeptierte Standard zur Überprüfung der Sicherheit eines
Systems ist es aber, dieses mit Angriffswerkzeugen zu testen (sog. penetration testing), um die
dabei gefundenen Lücken schließen zu können.
Mit der nun rechtskräftigen Gesetzesänderung bewegen sich die Nutzer von “Hackertools” stark
am Rande der Legalität. Dennoch kann auf die Nutzung solcher Tools nicht verzichtet werden,
da eine effiziente Suche nach Sicherheitslücken auf einzelnen Rechnern und in Netzwerken
ohne diese Tools kaum möglich ist.
Eine weitere Folge der Gesetztesänderung ist der komplette Entwicklungsstop oder die Verlagerung der Entwicklung von Securitytools ins Ausland. Die Entwicklung des WLAN-Scanners
KisMAC [142] wurde z. B. aus Deutschland in die Schweiz verlagert [143].
102
Kapitel 9
Online-Visualisierung mit Java-Applets
und XML-RPC
Die Entwicklung und Wartung von verteilten Monitoring- und Regelungssystemen erfordert den
Online-Zugriff auf aktuelle Messdaten. Meist ist das jedoch nur sehr eingeschränkt möglich.
Messdaten liegen bestenfalls in Textform (American Standard Code for Information Interchange
(ASCII)) auf dem Messrechner vor.
Bei Arbeiten an einem Brennstoffzellen-Monitoring-System des Fraunhofer ISE entstand die
Idee, Messdaten online per Internet mit Hilfe von Anlagenschemata zu visualisieren. Durch
eine solche Darstellung kann der Betrachter die Bedeutung der Messwerte einfach und schnell
erfassen und damit einen Überblick über den jeweiligen Systemzustand gewinnen.
Bei der Realisierung einer entsprechenden Visualisierungssoftware sollten verschiedenen Anforderungen erfüllt werden:
1. Visualisierungen von Messdaten sollten auf unterschiedlichen Plattformen, wie z. B. Windows- und Linux-Systemen, funktionieren.
2. Das Betrachten von Online-Visualisierungen sollte ohne großen Installationsaufwand
möglich sein.
3. Die Grafiken der Visualisierungen sollten sich in Abhängigkeit von den Messdaten ändern
können (z. B. Farben in Abhängigkeit von gemessenen Temperaturen).
4. Die Programmierung der Visualisierungen sollte ohne kostenpflichtige Software realisierbar sein.
5. Das System sollte auch in Umgebungen funktionieren, in denen ein Internetzugriff nur mit
Hilfe von Proxies und geschützt durch Firewalls stattfinden kann.
Verschiedene Programmiersprachen wurden auf ihre Eignung bezüglich der o. g. Anforderungen
untersucht. Die Ergebnisse sind in der Tabelle 9.1 zusammengefasst.
103
104
KAPITEL 9. ONLINE-VISUALISIERUNG MIT JAVA-APPLETS UND XML-RPC
JavaApplikation
läuft im Webbrowser
nein
plattformunabhängig
ja
freie Entwicklungstools
ja
Grafik frei programmierbar ja
ohne Installation nutzbar
nein
JavaApplet
ja
ja
ja
ja
ja
JavaScript Flash C/C++Applikation
ja
ja
nein
ja
ja
nein
ja
nein ja
nein
ja
ja
ja
ja
nein
Tabelle 9.1: Programmiersprachen und ihre Eignung für die Online-Visualisierung von Messdaten
Es zeigte sich, dass Webbrowser-basierte Software am besten geeignet ist, um auf verschiedenen
Plattformen eingesetzt zu werden und den Installationsaufwand zu minimieren. Die Anforderungen hinsichtlich der freien Grafikprogrammierung und kostenloser Entwicklungstools werden
am besten von der Programmiersprache Java erfüllt. Die Kommunikation zwischen Java-Applet
im Webbrowser und der Quelle der zu visualisierenden Daten können prinzipiell über jede
Art von Internetverbindung abgewickelt werden. Da die Visualisierungssoftware aber auch in
Umgebungen mit Web-Proxy und Firewall funktionieren soll, muss die Kommunikation auf
Basis des Hypertext Transfer Protocols (HTTP) stattfinden.
Für die Kommunikation per HTTP standen die Entwicklung eines eigenen proprietären Protokolls zur Messdatenübertragung, die Nutzung von XML-Rmote Procedure Calls (XML-RPC)
oder des Simple Object Access Protocol (SOAP) zur Wahl. Die wichtigsten Eigenschaften der
hier genannten möglichen Protokolle sind in Tabelle 9.2 dargestellt.
funktioniert zusammen mit
Proxies und Firewalls
Webserver-Software nutzbar
Softwarebibliotheken vorhanden
Komplexität
Client-Software verfügbar
Funktionalität einfach erweiterbar
Socketverb.
proprietär
HTTP
XML-RPC
proprietär
SOAP
nein
nein
nein
gering
nein
nein
ja
ja
nein
gering
nein
nein
ja
ja
ja
hoch
ja
ja
ja
ja
ja
mittel
ja
ja
Tabelle 9.2: Eignung von Optionen zur Datenübertragung zwischen Visualisierungs-Client und
-Server
Aufgrund des Vorhandenseins von gebrauchsfertigen Softwarebibliotheken für Java-Applets, der
Möglichkeit zur Nutzung von Webserver-Software zur Kommunikationsabwicklung und der im
9.1. VISUALISIERUNGS-CLIENT-SOFTWARE
105
Vergleich zu SOAP geringeren Komplexität wurde XML-RPC für die Messdatenübertragung zwischen Visualisierungssoftware und Datenquelle gewählt. Es wurde ein Programmpaket entwickelt, das aus einer Client- und einer Serversoftware besteht, die per XML-RPC miteinander
kommunizieren. Die Serversoftware stellt die aktuellen Messwerte mit Hilfe eines Webservers
zur Verfügung. In einem Webbrowser wird die Client-Software ausgeführt. Sie ruft die Daten in
regelmäßigen Zeitabständen vom Webserver ab und stellt sie grafisch dar [20].
9.1 Visualisierungs-Client-Software
Zur Realisierung der Client-Software wurde die von der Firma Sun Microsystems [202]
entwickelte Programmiersprache Java [137] eingesetzt. Java geht auf ein Projekt aus dem
Jahr 1991 zur Entwicklung einer einfachen und plattformunabhängigen Sprache für Geräte der
Konsumelektronik zurück. 1996 wurden die Internet-Browser der Firmen Netscape (Netscape)
und Microsoft (Internet Explorer) so gestaltet, dass sie Java-Programme aus dem Netz laden
und im Browser ausführen konnten. Diese Programme, so genannte Applets, haben den Vorteil,
dass sie lokal auf dem Rechner laufen, auf dem der Webbrowser ausgeführt wird [77][149].
Die aufwändigen Berechnungen, die für die grafische Darstellung von Messwerten notwendig
sind, übernimmt somit komplett der Client-Rechner, so dass die Ressourcen des Servers, der die
Messdaten liefert, geschont werden.
Ein weiterer Vorteil der Nutzung von Java-Applets für die Visualisierung ist die Plattformunabhängigkeit dieser Lösung. Java ist für alle gängigen Internet-Browser (Mozilla Firefox
[162], Microsoft Internet Explorer [156], Opera [178], Apple Safari [11]) in Form von Plugins
verfügbar. Voraussetzung für die Visualisierung ist ein installiertes Java Runtime Environment
(JRE). Diese Software gibt es für alle weit verbreiteten Betriebssysteme (Microsoft Windows,
Linux, Apple MacOS, etc.) unter [137] zum Download.
Basis der Visualisierung ist ein Hintergrundbild. Es stellt schematisch die Anlage dar, deren
Messwerte visualisiert werden sollen. Das Hintergrundbild kann mit jedem beliebigen Grafikprogramm erstellt werden. Für die Visualisierung muss es entweder als JPG- oder GIF-Datei
vorliegen.
Bei der Darstellung im Webbrowser wird das Hintergrundbild mit Messwerten und grafischen
Elementen überlagert. Dabei können die überlagernden Elemente wahlweise auch transparent
dargestellt werden, so dass das Hintergrundbild durchscheint.
Mit der Nutzung von Double Buffering wird verhindert, dass die Darstellung im Webbrowser bei
der Aktualisierung von Messwerten flackert. Beim Double Buffering wird der Bildschirminhalt
mit Hilfe von zwei verschiedenen Speicherbereichen gerendert und dargestellt. Während der
erste Speicherbereich auf dem Bildschirm dargestellt wird, werden alle Aktualisierungen
der Messwerte und grafischen Elemente im zweiten Speicherbereich durchgeführt. Ist diese
Aktualisierung abgeschlossen, wird für die Darstellung auf den zweiten Speicherbereich umge-
106
schaltet, usw. Die nächsten Aktualisierungen finden dann im ersten Speicherbereich statt. Sind
sie dort abgeschlossen, wird wieder umgeschaltet, usw. Durch dieses Verfahren finden keine
Aktualisierungen direkt auf dem Bildschirm statt, wodurch ein Flackern des Bildes entstehen
würde, sondern es werden immer nur komplette Speicherinhalte auf den Bildschirm geschrieben.
Ein Screenshot der Online-Visualisierung eines Wärmepumpensystems im Webbrowser Mozilla
Firefox ist in Abb. 9.1 dargestellt. Das Java-Applet mit dem Anlagenschema wird in ein
html-Dokument eingebettet, das neben dem Applet auch noch andere Elemente enthalten
kann. Beim dargestellten Beispiel wird das Java-Applet durch Logos und eine Überschrift im
html-Dokument ergänzt.
9.2 Server-Software für die Visualisierung
Die Serversoftware, die die Messdaten zur Verfügung stellt, wurde in der Programmiersprache
C implementiert. C-Compiler gibt es für viele verschiedene Betriebssysteme und Rechnerarchitekturen, so dass die Software leicht auf neue Zielsysteme portiert werden kann. Ein weiterer
Vorteil von C ist der im Vergleich zu Java sehr geringe Ressourcenverbrauch, wodurch die
Serversoftware auch für Embedded Systems geeignet ist.
Die Datenübertragung zwischen Client-Rechner und Server erfolgt mit dem Hypertext Transfer
Protocol (HTTP). Dieses Protokoll wird im Internet für die Übertragung von Webseiten
genutzt, so dass die Datenübertragung zwischen Server und Visualisierungs-Client auch über
Web-Proxys und durch die meisten Firewalls hindurch funktioniert.
Die Client-Software für die Visualisierung kommuniziert nicht direkt mit der VisualisierungsServer-Software. Die HTTP-Datentransfers werden auf der Server-Seite von einer WebserverSoftware durchgeführt, die die Daten per Common Gateway Interface (CGI) an die
Visualisierungs-Server-Software weitergibt. Das CGI ist eine standardisierte Schnittstelle,
die bei sehr vielen verschiedenen Webserver-Programmen verfügbar ist. Je nach Anwendungsfall können ganz unterschiedliche Webserver-Pakete genutzt werden. Sollen z. B. viele Personen
gleichzeitig Zugriff auf die Visualisierung haben, kommt eine leistungsstarke WebserverSoftware (z. B. das Programm Apache der Apache Software Foundation [10]) auf einem
dedizierten schnellen Server zum Einsatz. Wenn nur wenige Personen gelegentlich auf die Visualisierung zugreifen sollen und nur ein leistungsschwaches Embedded System zum Ausliefern
der Messdaten zur Verfügung steht, wird eine ressourcenschonende Webserver-Software (z. B.
der tiny/turbo/throttling HTTP-Server THTTPD der ACME Laboratories [2]) eingesetzt.
Für die Kommunikation zwischen Server und Visualisierungs-Client werden Extensible Markup
Language Remote Procedure Calls (XML-RPC, Spezifikation siehe [239]) genutzt. Dabei
handelt es sich um eine Kombination aus dem oben schon angeführten HTTP und der Extensible
Markup Language (XML) [238].
9.2. SERVER-SOFTWARE FÜR DIE VISUALISIERUNG
107
Abbildung 9.1: Online-Visualisierung einer Wärmepumpenanlage per Java-Applet im Webbrowser Mozilla Firefox
108
XML-RPC ermöglicht es, über das Netzwerk auf einem entfernten Rechner Methoden aufzurufen
und deren Rückgabewerte zum aufrufenden Rechner zurück zu übertragen. Die Methodenaufrufe und Rückgabewerte können dabei aus komplexen Strukturen mit ganz verschiedenen
Datentypen bestehen.
Um XML-RPC-Funktionalität auch auf Embedded Systems mit stark eingeschränkten
Ressourcen nutzen zu können, wurde für die hier vorgestellte Java-Visualisierung eine XMLRPC-Server-Software in ANSI-C implementiert, die mit Ausnahme von Binärdaten alle in
der XML-RPC-Spezifikation [239] festgeschriebenen Datentypen unterstützt und trotzdem nur
einen Footprint von unter 15 KB hat. Diese Software dient als Visualisierungs-Server-Software.
Sie liest die Messdaten des Messprozesses und gibt sie über die weiter oben beschriebene
CGI-Schnittstelle an den Webserver weiter.
Die XML-RPC-Infrastruktur kann neben der Visualisierung parallel auch für andere Zwecke genutzt werden (z. B. zur Reglerparametrierung, zum Setzen von Stellwerten und zur Fernwartung),
da sie geeignet ist, beliebige Daten an Programme auf dem Serversystem weiterzuleiten.
9.3 Ablauf des Visualisierungsprozesses
Wenn eine Online-Visualisierung im Webbrowser betrachtet werden soll, laufen folgende Prozesse ab (siehe auch Abb. 9.2 ):
1. Nach
der
Eingabe
des
Uniform
Ressource
Locator
(URL)
(Bsp.:
http://www.meinevisualisierung.de) lädt der Webbrowser ein HTML-Dokument vom
Webserver.
2. Im HTML-Dokument ist ein Tag für den Aufruf des Java-Applets enthalten (z. B. <applet code=”meinevisu” archive=”meinevisu.jar” height=”606”
width=”872”></applet></div>). Dieses Applet wird vom Webserver der Maschine
(z. B. einem Embedded System) heruntergeladen, welche die zu visualisierenden Daten
liefern soll.
3. Der Webbrowser startet die Java-Ausführungsumgebung (Java Runtime Environment JRE)
und führt in dieser das Java Applet aus.
4. Das Hintergrundbild für die Visualisierung wird vom Java-Applet auf dem Bildschirm
dargestellt.
5. Das Java-Applet generiert die XML-Daten für einen XML-RPC und schickt die Anfrage
per HTTP an den Webserver des Embedded Systems.
6. Der Webserver erkennt aus der Anfrage, dass er die XML-Daten per CGI an die
Visualisierungs-Server-Software weiterleiten soll und führt diesen Auftrag aus.
9.3. ABLAUF DES VISUALISIERUNGSPROZESSES
109
7. Die Visualisierungs-Server-Software (XML-RPC-CGI) wertet die XML-Daten aus (Parsing), erkennt, dass die Methode zur Abfrage von Messwerten aufgerufen werden soll,
und startet den Abrufprozess.
8. Der Abrufprozess fragt beim Messprozess die entsprechenden Messdaten ab (z. B. per
Socket-Verbindung auf der lokalen Maschine) und übergibt sie an den XML-Generator,
der sie XML-RPC-konform “einpackt” und an den Webserver zurückgibt.
9. Der Webserver schickt die Daten per HTTP zurück zum Java-Applet.
Die Prozesse fünf bis neun werden fortlaufend wiederholt, solange das Java-Applet im Webbrowser läuft. In der Praxis ergeben sich dabei meist Update-Intervalle zwischen zehn Sekunden
und einer Minute.
Visualisierungs−Client
Java−fähiger
Webbrowser
Embedded Linux
System im Feld
Webserver (thttpd)
XML−RPC−CGI
Visualisierungsdaten
Abbildung 9.2: Schema einer Visualisierung der Messdaten eines Embedded Systems mittels JAVA-Applet und XMLRPC
Sollen viele Rechner gleichzeitig die Messdaten visualisieren oder sollen gleichzeitig die Messdaten von mehreren Messrechnern visualisiert werden, empfiehlt es sich, einen leistungsfähigen
Rechner als Webserver zwischen Clients und Messrechner zu schalten (siehe Abb. 9.3).
110
Visualisierungs−Client
Java−fähiger
Webbrowser
Webserver
Embedded Linux
System im Feld
Webserver (Apache)
Prozess−Server
XML−RPC−CGI
Visualisierungsdaten
Embedded Linux
System im Feld
Abbildung 9.3: Schema einer Visualisierung der Messdaten mehrerer Embedded Systems mit
Hilfe eines zentralen Webservers
9.4. GRAFISCHE ERSTELLUNG VON ONLINE-VISUALISIERUNGEN
9.4 Software zur grafischen
Visualisierungen
Erstellung
von
111
Online-
Bei der Online-Visualisierung mit Java-Applets und XML-RPC werden die zu visualisierenden
Messdaten vom Webserver in Form von Label-Wert-Paaren (Bsp.: T_ruecklauf: 13.3) an das
Java-Applet übertragen. Das Label bezeichnet dabei jeweils den Messkanal. Für jeden einzelnen
Messkanal wird ein Parametersatz erzeugt, der in den Java-Code integriert wird. Im Vergleich zu
einer Konfiguration mit einem Config-File können neue grafische Elemente und Anpassungen an
spezielle Visualisierungsaufgaben im Programmcode auf diese Weise schneller realisiert werden.
Da die Konfiguration der Visualisierungen direkt im Java-Code sehr unübersichtlich ist und von
Personen ohne Programmier-Kenntnisse gar nicht bewerkstelligt werden kann, wurde ein grafischer Editor zur Erstellung der Visualisierungen entwickelt. Ein Screenshot des Editor-GUI ist
in Abb.9.4 dargestellt.
Abbildung 9.4: Editor zum Erstellen von Java-Online-Visualisierungen
112
Die Erstellung einer Visualisierung beginnt mit dem Laden des Hintergrundbildes in den Editor.
Das geschieht über den File-Dialog mit der Option Load Image. Das Bild wird daraufhin im
Editor dargestellt.
Für jeden zu visualisierenden Messkanal muss zunächst ein Dataobject erzeugt werden. Im Insert-Menü gibt es dazu die Option Dataobject. Das Objekt wird auf dem Hintergrundbild mit der
Maus positioniert. Jedes Dataobject besteht aus einer Textzeile und einem dazugehörigen Rahmen. Im Properties-Dialog (siehe Abb. 9.4, linkes Fenster) können die Eigenschaften von Text
und Rahmen eingestellt werden. Folgende Parameter können eingestellt werden:
xpos
ypos
width
height
value
sensorlabel
description
unit
sensordatalabel
stringdata
Schriftart
size
Xoff
Yoff
drawable
usefillcolor
wrap
fillcolor
fontcolor
datatype
shapetype
X-Position des Textrahmens
Y-Position des Textrahmens
Breite des Textrahmens
Höhe des Textrahmens
Wert, der beim Start der Visualisierung dargestellt werden soll, bevor
Messdaten vorliegen
Bezeichnung des Messwertes in der Visualisierung (z. B. T_außen)
Beschreibung des Messkanals
Einheit des Messwertes (z. B. m3 )
Bezeichnung des Messkanals
Text, der beim Start der Visualisierung dargestellt werden soll
Drop-Down-Menü für die Schriftartenwahl
Schriftgröße
X-Position des Textes im Textrahmen
Y-Position des Textes im Textrahmen
Schalter legt fest, ob Textrahmen mit einer vom Messwert abhängigen
Füllfarbe hinterlegt wird
Schalter legt fest, ob Textrahmen mit der durch fillcolor definierten
Farbe gefüllt wird
Schalter legt fest, ob Text zwischen Label und Wert umgebrochen wird
Füllfarbe des Textfeldes
Schriftfarbe
Behandlung der Messdaten als String oder Float (Floats werden auf eine
Nachkommastelle gerundet)
Form des Textrahmens (Rechteck oder Polygonzug)
Textrahmen können mit der Maus ausgewählt und verschoben werden. Das gerade ausgewählte
Dataobject wird durch einen gelben Rand gekennzeichnet. Es kann mit dem Properties-Dialog
bearbeitet werden.
Nach dem Beenden des Parametrierens kann die Konfiguration gespeichert werden. Mit der Option Export to Java-Code im File-Menü wird die Konfiguration in den Java-Programmcode der Visualisierung exportiert. Der Programmcode wird dann kompiliert und das kompilierte Programm
9.4. GRAFISCHE ERSTELLUNG VON ONLINE-VISUALISIERUNGEN
113
(die Java-Class-Files) wird in ein jar-Archiv eingepackt. Das jar-Archiv enthält außerdem das
Hintergrundbild für die Visualisierung. Es kann in dieser Form direkt auf einem Webserver abgelegt werden. Ein zusätzlich beim Code-Export vom Editor generiertes html-Dokument, das ein
Tag zum Aufruf des jar-Archivs enthält, kann auch auf dem Webserver hinterlegt werden, um
die Visualisierung gleich zu testen.
114
Kapitel 10
Visualisierung auf Mobiltelefonen mit dem
Wireless Application Protocol (WAP)
Die komfortabelste Zugriffsvariante auf aktuelle Messdaten eines vernetzten Monitoring- oder
Regelungssystems ist sicher die Online-Visualisierung auf einem Computerbildschirm (siehe
Abschnitt 9). Computer stehen jedoch nicht immer und überall zur Verfügung. Bei der Entwicklung eines Regelungssystems einer großen solarthermischen Anlage für ein Studentenwohnheim
im Freiburger Stadtteil Vauban sollte eine Kontrolle des Anlagenverhaltens auch ohne Computer
ermöglicht werden. Es wurde deshalb eine Visualisierung mittels Mobilfunktechnologie entwickelt.
10.1 WAP 1.x
Moderne Mobiltelefone beherrschen die Darstellung von Grafiken und Texten, die mit dem Wireless Application Protocol (WAP) zum Gerät übertragen werden. WAP wurde vom WAP-Forum
[220], welches heute Teil der Open Mobile Alliance [174] ist, entwickelt. Es soll Inhalte aus dem
Internet auch für die Nutzer von Mobiltelefonen zugänglich machen. WAP-Dokumente in den
1.x-Versionen werden in der Wireless Markup Language (WML) erstellt. Diese beruht auf XML
[238]. In Abb. 10.2 wird beispielhaft der WML-Code für die Darstellung des Anlagenverhaltens
der oben erwähnten Solaranlage abgebildet. Auf der linken Seite der Abbildung wird gezeigt,
wie ein Mobiltelefon das Dokument darstellt.
Die Software, die dieses WML-Dokument generiert, ermöglicht jederzeit den Zugriff auf die
Messwerte des Regelungssystems der Solaranlage. Das Dokument wird ca. einmal pro Minute
aktualisiert, so dass stets aktuelle Messdaten abgefragt werden können.
115
116
KAPITEL 10. VISUALISIERUNG AUF MOBILTELEFONEN MIT WAP
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="card1" title="Solaranlage Vauban">

<img src="logo.wbmp" alt="ise-logo"/>

<big>Solaranlage Vauban:</big>
Datum: 09.01.06
Uhrzeit: 14:08:25 UTC
Beladegruppe:
Wärmetauschereingang 8.93°C
Wärmetauscherausgang 7.72°C
Entladegruppe:
Wärmetauschereingang 8.39°C
Wärmetauscherausgang 8.74°C
Speicher:
Temperatur oben: 13.44°C
Temperatur unten: 10.14°C
</card></wml>
Abbildung 10.1: WML-Code der in Abb. 10.2 links dargestellten WAP-Seite
Abbildung 10.2: WAP 1.x-Seiten dargestellt auf einem Mobiltelefon
10.2. INFRASTRUKTUR ZUR AUSLIEFERUNG VON WAP-DOKUMENTEN
117
Bei der Entwicklung musste berücksichtigt werden, dass die erzielbaren Übertragungsbandbreiten in den Mobilfunknetzen deutlich geringer sind als im Internet. Eine weitere Einschränkung
ergibt sich aus den im Vergleich zu Bildschirmen von Personalcomputern sehr viel kleineren
Displays von Mobiltelefonen.
10.2 Infrastruktur zur Auslieferung von WAP-Dokumenten
WAP-Seiten werden wie normale Internetseiten auf herkömmlichen Webservern (z. B. apache
[10] oder Microsoft Internet Information Server [156]) im Internet abgelegt. Der Weg der
Daten vom Webserver zum Mobiltelefon wird in Abb. 10.3 beschrieben. Die Daten werden
zunächst in Form von WML-Dateien per Hypertext Transfer Protocol (http) über das Internet
zum WAP-Gateway des Mobilfunk-Providers übertragen. Der WAP-Gateway übersetzt die
Daten dann in eine komprimierte Form, die so genannte Wireless Markup Language Compiled
(WMLC), die mit wesentlich geringeren Übertragungsbandbreiten auskommt. In dieser Form
werden die Daten dann an eine Mobilfunk-Basisstation übertragen und von dort mit den
standardisierten Methoden zur Datenübertragung per Mobilfunk (Circuit Switched Data - CSD,
General Packet Radio Service - GPRS, etc.) zum Mobiltelefon gesendet.
Wenn, wie im Kapitel 9 beschrieben, schon ein Online-Visualisierung für eine Anlage realisiert
wurde, kann mit vergleichsweise kleinem Aufwand zusätzlich auch ein Zugang zu den Messdaten per WAP realisiert werden.
1
Webserver
WAP−
Gateway
0
GSM−
Basisstation
Mobil−
telefon
Abbildung 10.3: Übertragungsweg von WAP-Seiten vom Webserver zum Mobiltelefon
118
10.3 WAP 2.x
Im Jahr 2001 wurde von der Open Mobile Alliance [174] die Version 2.0 der WAP-Spezifikation
angekündigt (siehe [13]). Mehr Rechenleistung und größere Displays bei den Mobiltelefonen
sowie größere zur Verfüngung stehende Bandbreiten bei Mobilfunkverbindungen ermöglichten
die Integration zahlreicher neuer Features in den Standard. Während WAP 1.x nur Bilder mit
1 Bit Farbtiefe (schwarz-weiß) im Wireless Application Protocol Bitmap Format (WBMP)
unterstützte, können WAP 2.x-Dokumente auch farbige Bilder in den Dateiformaten Graphics
Interchange Format (GIF), JPG/JPEG (benannt nach der Joint Photographic Experts Group)
und Portable Network Graphics (PNG) enthalten. Grafiken in diesen Formaten lassen sich
mit allen herkömmlichen Bildbearbeitungsprogrammen einfach erzeugen. Außerdem können
Grafikbibliotheken wie z. B. die für viele Programmiersprachen verfügbare GDLIB [146]
genutzt werden, um Daten für die Darstellung auf einem Mobiltelefon grafisch aufzubereiten.
Im Rahmen eines Projekts des Fraunhofer ISE für ein Energieversorgungsunternehmen, bei dem
es um Smart-Metering und Feedbacksysteme ging, wurde die Software WAPplot entwickelt.
Das Programm erzeugt Balkendiagramme, die Verbräuche in Form von Viertelstundenwerten
für jeweils einen Tag darstellen. Die erzeugten JPG-Grafiken sind für die Darstellung auf
Mobiltelefonen optimiert. Sie sind jeweils nur 127 x 127 Punkte groß.
Die in Abb. 10.4 dargestellten Diagramme (links: Darstellung auf einem Mobiltelefon, rechts:
Originalbilder) wurden mit WAPplot erstellt. Sie zeigen für einen Privathaushalt den Stromverbrauch und die elektrische Leistungsaufnahme in Form von Viertelstundenwerten. Abgebildet
ist ein Zeitraum von 24 Stunden.
WAPplot ist ein in C programmiertes Kommandozeilen-Tool. Zu seiner Entwicklung wurde die
weiter oben erwähnte GDLIB [146] genutzt. Bei der Diagrammerstellung wird zunächst ein Hintergrundbild im JPG-Format benötigt. Da die GDLIB Transparenz unterstützt (Alphakanal), kann
das Hintergrundbild mit dem Diagramm so überschrieben werden, dass der Hintergrund durchscheint. Der Programmaufruf von WAPplot erfolgt mit folgender Kommandozeile:
WAPplot <title> <ordinate> <file> <scale> <background> <outfile>
Dabei haben die einzelnen Parameter folgende Bedeutungen:
<title>
<ordinate>
<file>
<scale>
<background>
<outfile>
Titel der Grafik
Beschriftung der Ordinate des Diagramms (z. B. Einheit der Messwerte)
Messdaten-Datei
Skalierung der Messdaten für die Grafik
Hintergrundbild
Name der erzeugten JPG-Datei
10.3. WAP 2.X
119
Abbildung 10.4: links: Diagramm der elektrischen Leistungsaufnahme eines Haushalts aus dem
Stromnetz in Viertelstundenwerten. Die Darstellung erfolgt in Form eines WAP
2.x-Dokuments auf einem Mobiltelefon.
rechts: Für die Darstellung auf einem Mobiltelefon optimierte Diagramme zum
Stromverbrauch und zur Leistungsaufnahme eines Privathaushalts.
WAPplot wird im Normalfall von einem Timer in regelmäßigen Abständen aufgerufen (z. B.
von dem im Kapitel 15.1 beschriebenen Scheduler), um die in der Zwischenzeit seit dem letzten
Aufruf neu gemessenen Daten in die grafische Darstellung zu integrieren.
Weitere interessante Neuerungen bei WAP 2.x sind Push-Dienste, Verschlüsselung und Datenübertragung bis zum Endgerät per Hypertext Transfer Protocol (HTTP). Bei WAP 2.x wird die
Wireless Markup Language (WML) aus WAP 1.x ersetzt durch das Extensible HyperText Markup
Language Mobile Profile (XHTML MP), ein Subset von XHTML, das durch eine Verschmelzung
aus HTML und XML entstanden ist. Durch die Nutzung von XHTML kann parallel Content für
Mobiltelefone und Webbrowser entwickelt werden.
120
Kapitel 11
Simulation verteilter Regelungssysteme
Handelsübliche Rechner sind heute so leistungsfähig, dass eine simultane Simulation von
einem verteilten Regelungssystem und der zu regelnden Anlage problemlos möglich ist. Zur
Simulation eines Netzwerks mit zahlreichen Knoten bietet sich die Nutzung von virtuellen
Maschinen an. Mit Hilfe solcher Software können auf einem einzelnen Rechner gleichzeitig
mehrere Betriebssysteme ausgeführt werden, die alle voll funktionsfähig sind und über ein
virtuelles Netzwerk miteinander kommunizieren können (siehe Abb. 11.1). Mit Hilfe eines
aus virtuellen Maschinen gebildeten Netzwerks lassen sich verteilte Regelungssysteme auf
einem einzigen Rechner simulieren. Dazu müssen die virtuellen Maschinen mit klassischer
Simulationssoftware kombiniert werden, die die zu regelnden Anlagenkomponenten abbildet.
Im Gegensatz zur konventionellen Anlagensimulation, bei der Regelungsalgorithmen und die
Simulation der Anlagenkomponenten in einer geschlossenen Simulationsumgebung ausgeführt
werden, bietet die Simulation mit mehreren virtuellen Maschinen zahlreiche Vorteile:
• Da der Zugriff auf die virtuellen Maschinen sehr einfach ist, können Änderungen der Software schnell durchgeführt und getestet werden.
• Mit Netzwerk-Analysetools, wie z. B. Wireshark [228], kann auf das Netzwerk der virtuellen Maschinen zugegriffen werden. Dadurch ist das Protokollieren und Analysieren des
Datenverkehrs zwischen den virtuellen Maschinen sehr einfach möglich.
• Das Netzwerk der virtuellen Maschinen kann in ein bestehendes Computernetzwerk integriert werden, um dort vorhandene Dienste für das simulierte Regelungsnetzwerk zu
nutzen. So ist es z. B. möglich, bei Echtzeitsimulationen auf im Internet verfügbare Wetterdaten zuzugreifen.
• Eine Übertragung der mit virtuellen Maschinen entwickelten und erprobten Regelungssoftware auf ein echtes Regelungsnetzwerk aus Embedded Systems ist ohne größere Änderungen möglich. Dabei ist auch ein fließender Übergang vom simulierten zu einem komplett
realen Regelungssystem möglich.
121
122
KAPITEL 11. SIMULATION VERTEILTER REGELUNGSSYSTEME
Server für virtuelle Maschinen
Internet
virtuelles Netzwerk
virtuelle Maschine 1
Abbildung 11.1: Mehrere virtuelle Maschinen werden auf einem Rechner ausgeführt. Sie sind
dabei durch ein virtuelles Netzwerk untereinander und mit dem Server verbunden. Über den Server können die virtuellen Maschinen auf das Internet zugreifen.
Abbildung 11.2: Auf einem Rechner mit Ubuntu Linux 7.10 werden mit der Virtualisierungssoftware Virtualbox drei virtuelle Maschinen mit Damn-Small-Linux, Microsoft
Windows XP Professional und OpenSuSe 10.0 Linux gleichzeitig ausgeführt.
11.1. VIRTUALISIERUNGSTECHNIKEN
123
11.1 Virtualisierungstechniken
Mit Virtualisierungstechniken ist es heute möglich, auf einem Computersystem ein oder mehrere
Computersysteme komplett nachzubilden. Dabei muss generell zwischen zwei verschiedenen
Ansätzen unterschieden werden:
• Komplette Emulation des Zielsystems mit Emulatoren
• Teilemulation des Zielsystems mit Virtualisierern
Emulatoren
Ein Emulator ist die komplette Nachbildung einer Architektur durch eine Software, die sämtliche
Hardware inklusive Prozessor, Chipsatz und allem Drumherum in einer Umgebung abbildet, in
der die jeweiligen Betriebssysteme und Applikationen laufen können [242].
Emulatoren kommen dann zum Einsatz, wenn Systeme nachgebildet werden sollen, deren Hardware komplett anders ist als die des Wirtssysstems (z. B. kann ein Apple Rechner mit PowerPCProzessor auf einem x86-kompatiblen System abgebildet werden). Im Emulator müssen dazu
alle Komponenten des zu emulierenden Systems nachgebildet werden. Dieses Vorgehen benötigt
sehr viel Rechenleistung (z. B. für die Übersetzung der Prozessorbefehle) und ist deshalb für
aufwändigere Anwendungen kaum nutzbar, da die erzielbaren Verarbeitungsgeschwindigkeiten
nicht ausreichend für eine Echtzeitsimulation sind. Für die Entwicklung verteilter Regelungssysteme mit Embedded Systems mit Nicht-x86-Prozessoren (z. B. Systeme mit Mips- oder ARMArchitektur) können Emulatoren dennoch ein sinnvolles Entwicklungswerkzeug sein.
Bekannte Beispiele für Open Source Emulatoren sind PearPC [180] (für die Emulation von Systemen mit PowerPC-Architektur), Bochs [27] und Qemu [185].
Virtualisierer
Im Gegensatz zu den Emulatoren wird bei den Virtualisierern auf eine ressourcenhungrige
Hardwareemulation soweit wie möglich verzichtet. Deshalb werden bei den Virtualisierern
Prozessor und Hauptspeicher des Wirtssystems direkt genutzt. Dadurch müssen nur sehr wenige
Komponenten des Systems emuliert werden (z. B. Netzwerkinterfaces und Festplattencontroller). Mit Virtualisierungssoftware können allerdings auch nur Systeme nachgebildet werden, die
die gleiche Hardwarearchitektur haben wie das Wirtssystem.
Bekannte kommerzielle Virtualisierungsprodukte sind Virtual Server von Microsoft [156] und
GSX-Server von VMware [218]. Beide Firmen stellen auch kostenlos nutzbare Versionen ihrer
Software zur Verfügung. In der Open-Source-Szene wurde das sehr leistungsfähige XEN [233]
entwickelt. Es handelt sich dabei um ein Projekt der University of Cambridge (England) [234].
Bei XEN fallen die Leistungsverluste gegenüber einer direkten Installation mit 0,1% bis 5%
[242] sehr gering aus.
124
Im Gegensatz zu vielen Großrechnern, z. B. der Z-Serie von IBM [108], ist die heute am häufigsten anzutreffende x86-Architektur ursprünglich nicht für die Virtualisierung entwickelt worden.
Mittlerweile haben jedoch die beiden größten Prozessorhersteller neue Prozessorerweiterungen
zur Virtualisierung für x86-Systeme vorgestellt, durch die eine effiziente Nutzung der Ressourcen des Wirtssystems möglich wird:
• AMD Virtualization (AMD-V) – auch Pacifica genannt – von Advanced Micro Devices [8]
• Intel Virtualization Technology (Intel VT) – ehemals Vanderpool – von Intel [133]
Die Betriebssystemvirtualisierung ist eine besondere Variante der Virtualisierung. Bei dieser
Technologie wird auf dem Wirtssystem ein einzelner Betriebssystemkern ausgeführt. Die
Gastsysteme nutzen Kernel, Systembibliotheken und Schnittstellen des Wirtssystems mit. Ihre
Daten liegen in Verzeichnissen im Dateisystem des Wirtssystems. Die Gastsysteme sind im
Vergleich zum Wirtssystem deutlich schlanker und brauchen deshalb sehr viel weniger Speicher,
als wenn sie allein auf einem Rechner installiert würden. Auf einem sparsam ausgestatteten
Rechner können somit vergleichsweise viele Betriebssysteme parallel ausgeführt werden.
Das Softwarepaket Virtuozzo [217] der Firma SWsoft arbeitet mit Betriebssystemvirtualisierung.
Es wird häufig bei virtuellen Mietservern – sogenannten VServern – eingesetzt.
Bewertung
Es hängt stark vom Anwendungsfall ab, welches die geeignete Virtualisierungstechnologie
für die Simulation eines verteilten Regelungssystems ist. Für die Simulation von verteilten
Systemen auf der Basis von x86-Prozessoren, die mit dem Betriebssystem Linux arbeiten, hat
sich User Mode Linux [215] bewährt. Diese Software arbeitet als Virtualisierer. Dabei laufen
das Host-System und die Gast-Systeme ausschließlich mit Linux. Die virtuellen Systeme sind
bei dieser Technik sehr performant. Installation und Wartung gestalteten sich im Vergleich zum
weiter oben erwähnten Xen als sehr einfach.
Versuche mit den Emulatoren Bochs und Qemu zeigten im Vergleich zu User Mode Linux
sehr große Performanceeinbußen. Diese sind in der kompletten Hardwarenachbildung der
Emulatoren begründet. Emulatoren sollten möglichst nur genutzt werden, wenn aufgrund
unterschiedlicher Systemarchitekturen von Host-System und Gastsystemen eine Nutzung von
Virtualisierern nicht möglich ist. Wenn keine hardwarenahe Emulation notwendig ist, kann es
zunächst sinnvoll sein, das Regelungssystem mit einem Virtualisierer zu entwickeln und es erst
anschließend auf die Zielplattform zu portieren.
Ein wichtiges Auswahlkriterium ist sicherlich die Hardwareunterstützung des genutzten Virtualisierungssystems. Die verschiedenen Softwarepakete unterscheiden sich z. B. sehr stark in der
Unterstützung von Schnittstellen (z. B. USB).
11.2. SIMULATION MIT USER-MODE LINUX UND COLSIM
125
11.2 Simulation verteilter Regelungssysteme mit User-mode
Linux und ColSim
11.2.1 User-mode Linux
User-mode Linux [215] ist eine spezielle Variante der Virtualisierung. Es handelt sich nicht
um eine Hardware-Virtualisierung, sondern um eine Virtualisierung des Betriebssystems.
User-mode Linux basiert auf einem abgewandelten Linux-Kernel, der als Anwendungsprozess
in einem Standard-Linux-System ausgeführt wird. Da er nur mit den Rechten eines Nutzers ausgeführt wird, hat er keinerlei Einfluss auf die Konfiguration und die Stabilität des Host-Systems.
Seit der Version 2.6 ist User-mode Linux Bestandteil des Linux-Kernels [139] und wird als
solcher kontinuierlich weiterentwickelt. Auch zur Entwicklung neuer Kernel wird es eingesetzt,
da das Debugging eines User-mode Linux-Kernels mit den gleichen Debugging-Tools möglich
ist, die zur Anwendungsentwicklung in der Programmiersprache C genutzt werden. Das
Debugging von nativ laufenden Linux-Kerneln hingegen gestaltet sich deutlich schwieriger.
Die Dateisysteme von User-mode Linux befinden sich in großen Imagedateien, die vom Hostrechner aus als sogenanntes Loop-Device gemountet werden können. Dadurch können Veränderungen am User-mode Linux sehr einfach vorgenommen werden. User-mode Linux kann bei
entsprechender Konfiguration auch auf das Dateisystem des Host-Rechners zugreifen. Ein Austausch von Dateien ist über diese Schnittstelle auch ohne die Nutzung von Netzwerkdiensten im
laufenden Betrieb möglich.
Copy on Write
Wenn mit User-mode Linux gleichzeitig sehr viele virtuelle Maschinen betrieben werden sollen,
wird für die Imagedateien sehr viel Festplattenplatz benötigt. Unterscheiden sich die Systeme
nur marginal, kann die sogenannte Copy on Write-Technologie (COW) genutzt werden, um
Speicherplatz einzusparen.
Ein COW-Festplattenimage besteht aus zwei Dateien. Die erste, schreibgeschützte Datei (Hintergrunddatei) enthält das eigentlich Image. Sollen an diesem Image Änderungen vorgenommen
werden, werden diese in eine zweite Datei (Delta-Datei) geschrieben, die nur die Unterschiede
zur Hintergrunddatei beinhaltet. Eine Einsparung von Festplattenplatz wird erzielt indem mehrere virtuelle Maschinen eine einzige Hintergrunddatei benutzen. Jede Maschine bekommt jedoch
eine eigene Delta-Datei. Backups und Snapshots aller Maschinen können erstellt werden, indem
einmalig die Hintergrunddatei und für jede Maschine einzeln die jeweilige Delta-Datei gespeichert werden.
126
11.2.2 Installation eines Debian-User-mode Linux auf einem DebianLinux-Host-System
Um User-mode Linux-Systeme aufsetzen zu können, müssen auf dem Rechner, auf dem die
virtuellen Maschinen später laufen sollen, folgende Softwarepakete installiert sein:
User-mode-linux:
uml-utilities:
bridge-utils:
debootstrap:
Dieses Paket beinhaltet den User-mode Linux-Kernel.
Tools zur Wartung und zum Betrieb von User-mode Linux-Maschinen
Paket zum Erstellen von Netzwerk-Bridges
Programm zur Installation von Debian-Linux per Netzwerk-Verbindung
von einem Debian-FTP-Server
Zunächst wird ein Image-File erzeugt, in das später das Betriebssystem installiert wird. Mit der
Befehlszeile
dd if=/dev/zero of=root\_fs bs=1 count=1 seek=1G
wird das 1 Gigabyte große File root_fs angelegt und mit Nullen aufgefüllt. Um mit diesem ImageFile arbeiten zu können, muss in ihm ein Dateisystem erzeugt werden. Mit der Befehlszeile
mkfs.ext3 ./root\_fs
lässt sich z. B. ein ext3-Dateisystem anlegen. Damit das Betriebssystem in das Image-File installiert werden kann, muss es zunächst mit
mount -o loop root\_fs ./tmp
gemountet werden. Im Verzeichnis ./tmp wird dann mit debootstrap ein Minimal-Debian-Linux
installiert:
debootstrap --arch i386 sid ./tmp ftp://ftp.debian.org/debian/
Dabei gibt arch die Rechnerarchitektur an, für die das System installiert werden soll. Ist der
Host-Rechner eine X86-Maschine, muss auch das zu installierende User-mode Linux-System
mit diesem Befehlssatz arbeiten. Die zu installierenden Programmpakete werden von einem
Debian-Mirror-Server (z. B. ftp://ftp.debian.org ) heruntergeladen.
Nach der Installation des Basis-Systems müssen die Konfigurationsdateien für das Netzwerk
(/etc/network/interfaces) und eventuell benötigte Konsolen (/etc/inittab) angepasst werden. Sind
diese Arbeiten abgeschlossen, kann das Imagefile mit
umount ./tmp
aus dem Dateisystem des Host-Rechners entfernt werden. Die Konfiguration der virtuellen Maschine ist damit soweit abgeschlossen, dass das System zum ersten Mal gestartet werden kann.
127
11.2.3 Simulationsumgebung ColSim
ColSim [44][229] wurde als eine modulare Simulationsumgebung für die Entwicklung von
Reglern für thermische Energiesysteme – wie z. B. Blockheizkraftwerke – am Fraunhofer ISE
entwickelt. Mit ColSim ist eine Simulation der Energiesysteme inklusive daran angeschlossener
Gebäude möglich. In den letzten Jahren wurde ColSim um Simulationsmodelle für elektrische
Komponenten erweitert, so dass auch eine gemischte Simulation von thermischen und elektrischen Komponenten möglich ist.
Mit ColSim können Jahressimulationen mit einer zeitlichen Auflösung von bis zu wenigen
Sekunden durchgeführt werden. Die Software wurde in ANSI-C entwickelt, um die mit der
Simulationsumgebung entwickelten Regelungsalgorithmen ohne große Änderungen direkt auf
Regelungssystemen einsetzen zu können.
Für die Parametrierung der Simulationsumgebung wird eine abgewandelte Variante des VektorZeichenprogramms xfig [235] genutzt (siehe Abb. 11.8 oben rechts.). Konfigurationsänderungen
können aber auch direkt im ASCII-Konfigurationsfile der Simulationsumgebung vorgenommen
werden. Der eigentliche Simulator ist komplett ohne grafische Oberfläche lauffähig. Konfigurationsdateien für ColSim können auch per Skript ohne grafische Parametrierung erstellt werden.
11.2.4 Netzwerkstruktur für eine Simulationsumgebung mit User-mode
Linux und ColSim
Für die kombinierte Simulation verteilter Regelungssysteme und energietechnischer Anlagen
mit Hilfe von virtuellen Maschinen und einer Simulationssoftware ist eine komplexe Netzwerkstruktur notwendig. Ein Beispiel für eine solche Struktur ist in Abbildung 11.3 dargestellt. Die
einzelnen Teile der Abbildung werden in den folgenden Abschnitten erklärt:
Kommunikation zwischen virtuellen Maschinen, Hostrechner und Internet
Virtuelle Maschinen und daraus gebildete Netzwerke bieten die Möglichkeit, Software für
verteilte Systeme praxisnah zu entwickeln. Dazu muss die Netzwerkstruktur, mit der ein
reales verteiltes System arbeiten soll, mit virtuellen Netzwerken nachgebildet werden. Für die
Entwicklung von verteilten Regelungssystemen, die für ihren Regelungsprozess Informationen
von Internetdiensten benötigen, muss das Entwicklungs-Netzwerk mit virtuellen Maschinen
einen Internetzugang ermöglichen.
Die Entwicklung von Netzwerkprotokollen und Kommunikationssoftware kann dadurch erleichtert werden, dass Netzwerktools, wie z. B. der Protokollanalysator Wireshark [228] zur
Protokollanalyse genutzt werden. Dazu muss der komplette Netzwerkverkehr für die Tools
zugänglich gemacht werden.
Host−Rechner
Netzwerk−
Analyse−
Tool
Virtuelle Maschine 1
B
C
A
virtuelles Netzwerk 2
API für
Sensoren / Aktoren
Regler
Kommunikations−
Software
B
C
A
API für
Sensoren / Aktoren
Regler
Kommunikations−
Software
Anlagensimulator
Socket−Interface für
Sensoren / Aktoren
B
C
A
API für
Sensoren / Aktoren
Kommunikation
innerhalb der
virtuellen Maschine
Kommunikation
zwischen virtuellen
Maschinen
Kommunikation
zwischen virtuellen
Maschinen und
Simulationssoftware
Internet −
Kommunikation
Regler
Kommunikations−
Software
Datenquelle
Abbildung 11.3: Struktur für Simulationen eines verteilten Regelungssystems mit virtuellen Maschinen
Netzwerk Bridge
Virt. Net. / Host
Internet
129
Wie im Abschnitt 8.5 beschrieben, bieten Netzwerkswitches im Allgemeinen keine Zugriffsmöglichkeit, um den kompletten Datenverkehr eines Netzwerks zu sniffen (Ausnahme: managed
switches mit einen dedizierten Port für solche Zwecke). Auch virtuelle Switches bieten im
Standardbetrieb nicht die Möglichkeit zum Abhören des kompletten Datenverkehrs.
User-mode Linux bringt die Software uml_switch mit, die die Funktion eines virtuellen Switches
übernimmt. Zu Analysezwecken bietet uml_switch auch eine Betriebsart als Netzwerk-Hub
an. Bei Netzwerk-Hubs ist im Gegensatz zu Netzwerk-Switches der komplette Datenverkehr
an jedem Port sichtbar. Um uml_switch im Hub-Modus zu starten, muss es mit dem Schalter
-hub aufgerufen werden. Die komplette Kommunikation zwischen Host-Rechner und virtuellen
Maschinen sowie der virtuellen Maschinen untereinander wird über uml_switch im Hub-Modus
abgewickelt. Das entsprechende Netzwerk ist in Abb. 11.3 als virtuelles Netzwerk 2 dargestellt.
Für die Internet-Anbindung kann es sinnvoll sein, neben dem Netzwerk für die Kommunikation
zwischen virtuellen Maschinen und Host-Rechner noch ein weiteres Netzwerk einzurichten. Das
hat den Vorteil, dass in diesem Netzwerk mit per DHCP (siehe Abschnitt 7.5.1) zugewiesenen,
wechselnden IP-Adressen gearbeitet werden kann. Die virtuellen Maschinen können sich
untereinander auch noch mit statisch vergebenen IPs im virtuellen Netzwerk 2 erreichen. In Abb.
11.3 ist das Netzwerk für den Internet-Zugang mit virtuelles Netzwerk 3 gekennzeichnet.
Für die Internet-Anbindung des virtuellen Netzwerks gibt es mehrere Möglichkeiten. Eine der
Varianten ist die im Abschnitt 7.4.1 beschriebene Network Address Port Translation (NAPT).
Bei dieser Technik hat jede der virtuellen Maschinen Internetzugriff. Dazu werden sie mit
privaten IP-Adressen versehen, die beim Internet-Zugriff auf eine einzelne echte IP gemapped
werden. Nachteil dieses Verfahrens ist, dass ein Zugriff aus dem Internet auf die virtuellen
Maschinen nur sehr schwer möglich ist, so dass kaum Serverdienste durch die virtuellen
Maschinen zur Verfügung gestellt werden können. Nur mit Hilfe von Port-Forwarding oder Tunnelkonstruktionen ist ein direkter Zugriff vom Internet auf einzelne virtuelle Maschinen möglich.
Um für die virtuellen Maschinen einen vollwertigen Internetzugang zu realisieren, mit dem
auch Serverdienste ohne Hilfskonstruktionen möglich sind, bietet sich die Einrichtung einer
Netzwerk-Bridge zwischen dem Host-Netzwerk und dem virtuellen Netzwerk der virtuellen
Maschinen an (siehe Abb. 11.4). Eine Netzwerk-Bridge verknüpft zwei physikalisch getrennte
Netzwerksegmente logisch miteinander, so dass sie als ein Netzwerk mit einem gemeinsamen
IP-Space fungieren. Der Host-Rechner ist über sein Hardware-Netzwerkinterface eth0 an das
Internet angebunden. Mit den virtuellen Maschinen kommuniziert er über das virtuelle Netzwerkinterface tap0. TAP-Devices werden durch ein Linux-Kernelmodul bereitgestellt und emulieren
Ethernet-Geräte. Ihre Ethernet-Frames werden auf Device-Files /dev/tap<Nummer> umgeleitet,
auf die dann entsprechende Anwendungsprogramme, z. B. User-mode Linux, zugreifen können.
130
Wenn die beiden Netzwerkdevices eth0 und tap0 mittels einer Bridge zusammengefasst sind,
werden alle Daten, die an einem Netzwerkdevice auflaufen, an das jeweils andere Netzwerkdevice übertragen. Die Bridge wird dadurch für den Datenverkehr transparent. Alle virtuellen
Maschinen haben vollen Zugriff auf das Netzwerk, an das der Host-Rechner angeschlossen ist.
Sie können z. B. per DHCP “echte” IP-Adressen beziehen und Serverdienste gegenüber dem
Internet anbieten.
virtuelle Maschinen
Internet
Netzwerk Bridge
virtueller Switch
Host Netzwerk− virtuelles Netzwerk−
Interface tap0
Interface eth0
Abbildung 11.4: Internetzugriff für virtuelle Maschinen mittels einer Netzwerk-Bridge zur
Ethernet-Karte des Host-Rechners
Anbindung der virtuellen Maschinen an die Simulationssoftware
Um verteilte Regelungssysteme mit ColSim entwickeln zu können, muss ColSim die zu
regelnden Komponenten der einzelnen Anlagenteile simulieren. Dazu könnte man auf jeder
der virtuellen User-mode Linux-Maschinen eine ColSim-Instanz ausführen, auf die dann die
Regelungssoftware, die auf der virtuellen Maschine läuft, direkten zugreifen könnte. Das ist
jedoch wenig sinnvoll, da die zu regelnden Anlagenkomponenten thermisch und elektrisch oft
aneinander gekoppelt sind. Eine solche Koppelung lässt sich mit voneinander unabhängigen
Simulationumgebungen nicht abbilden. Die Anlagenkomponenten müssen folglich in einer einzigen Simulationsumgebung simuliert werden. Daraus ergibt sich jedoch die Aufgabenstellung,
für die Regelungssoftware, die auf den virtuellen Maschinen läuft, eine Zugriffsmöglichkeit auf
die zu regelnden Komponenten in der Anlagensimulation zu schaffen.
Die flexibelste Variante zur Anbindung von Regelungssoftware auf virtuellen Maschinen an
einen Anlagensimulator ist die Nutzung der Netzwerk-Konnektivität zwischen den virtuellen
Maschinen und dem Host-Rechner. Dazu wird wie in Abb. 11.5 vorgegangen. Alle Anlagenkomponenten in der Simulationsumgebung werden um ein Socket-Interface erweitert, über das
Messwerte abgefragt und Stellwerte gesetzt werden können. In die Regelungssoftware auf den
virtuellen Maschinen wird ein Software-Modul eingebunden, das mit den Socket-Interfaces
131
im Anlagensimulator kommuniziert. Für die Entwicklung der Regelungssoftware stellt das
Softwaremodul ein Application Programming Interface (API) zur Verfügung, über das auf die
Systemkomponenten in der Simulationssoftware zugegriffen werden kann.
Anlagensimulator
Socket−
Interface
zu regelnde
Komponente
Virtuelle Maschine
Aktor−API mit
Socket−Client
B
C
A
Regler
Abbildung 11.5: Anbindung von Regelungssoftware auf einer virtuellen Maschine an die Simulationssoftware
Soll die Regelungssoftware später für eine “echte” Anlage genutzt werden, kann dies ohne Änderungen an den Regelungsalgorithmen geschehen. Nur das Software-Modul für den
Simulatorzugriff muss gegen ein Modul für den Zugriff auf echte Hardware ausgetauscht werden.
Für die Socket-Kommunikation zwischen Anlagensimulator und virtuellen Maschinen wird ein
gesondertes virtuelles Netzwerk eingerichtet. Dadurch kann der Netzwerkverkehr von und zum
Anlagensimulator einfach von sonstigen Netzwerkaktivitäten unterschieden werden. In Abb.
11.3 wird das entsprechende Netzwerk als virtuelles Netzwerk 1 bezeichnet.
Netzwerk-Setup des Host-Rechners
Die Netzwerkkonfiguration der virtuellen Maschinen, die für die Simulation von verteilten
Regelungssystemen benötigt werden, geschieht durch den Host-Rechner, auf dem die User-mode
Linux-Maschinen ausgeführt werden. Die dazu notwendigen Netzwerkkomponenten werden mit
Ausnahme der Netzwerkkarte des Host-Rechners komplett virtualisiert.
In Abb. 11.6 ist ein Shell-Skript zur Netzwerkkonfiguration des Host-Rechners dargestellt.
Zunächst wird das Ethernet-Interface eth0 des Host-Rechners in den sogenannten promiscuous
mode versetzt. Im non-promiscuous mode wertet eine Netzwerkkarte nur für ihre NetzwerkAdresse bestimmte Pakete aus. Im promiscuous mode hingegen werden alle Pakete ausgewertet.
Für den Betrieb einer Bridge ist dieser Modus notwendig, da sie alle Pakete aus einem Teilnetzwerk in das jeweils andere Teilnetzwerk übertragen soll.
Mit dem Tool brctl aus dem Programm-Paket bridge-utils wird die Netzwerk-Bridge uml-bridge
angelegt und ihr Verhalten konfiguriert (Minimieren von Latenzen, Abschalten des Spanning
Tree Protocol (STP) zur Vermeidung von redundanten Netzwerkpfaden, etc.).
132
#!/bin/bash
#Internet-Anbindung über Bridge uml-bridge
#eth0 in den promiscuous mode
ifconfig eth0 0.0.0.0 promisc up
# bridge anlegen
brctl addbr uml-bridge
# bridge forward delay abschalten
brctl setfd uml-bridge 0
# hello-funktion abschalten
brctl sethello uml-bridge 0
# spanning tree protocol abschalten
brctl stp uml-bridge off
# bridge aktivieren
ifconfig uml-bridge 0.0.0.0
up
# eth0 des hostrechners an bridge binden
brctl addif uml-bridge eth0
#switch für Zugriff auf bridge einrichten
uml_switch -hub -tap tap0 -unix /tmp/umlswitch0 &
ifconfig tap0 0.0.0.0 promisc up
#switch an die bridge binden
brctl addif uml-bridge tap0
#ip-Adresse für bridge beziehen
dhclient uml-bridge
#switch für Kommunikation VM-Simulator
ifconfig tap1 10.0.1.1 netmask 255.255.255.0
#switch für Kommunikation VM-VM
ifconfig tap2 10.0.2.1 netmask 255.255.255.0
Abbildung 11.6: Shell-Skript zur Netzwerk-Konfiguration zum Betrieb von virtuellen Usermode Linux-Maschinen
133
Das virtuelle Netzwerkinterface tap0 wird ebenfalls in den promiscuous mode umgeschaltet.
Dann werden die beiden Interfaces eth0 und tap0 an die Bridge gebunden. Danach bezieht die
Bridge vom DHCP-Server eine IP-Adresse. Neben der Bridge-Funktion fungiert uml_bridge
auch als Netzwerkinterface für den Host-Rechner.
Am Ende des Skripts werden für die beiden weiteren Netzwerke der Simulationsumgebung noch
virtuelle Switches angelegt und dem Host-Rechner IP-Adressen aus den Netzwerken zugewiesen.
Systemstart von User-mode Linux-Maschinen
Der Start der virtuellen Maschinen erfolgt mit Hilfe von Shell-Skripten (siehe Abb. 11.7). Mit
diesen Skripten werden Kommandozeilenparameter an den User-mode Linux-Kernel übergeben,
die das Systemverhalten beeinflussen.
Mit dem Parameter mem wird festgelegt, wieviel Arbeitsspeicher der virtuellen Maschine zur
Verfügung gestellt wird. Das Imagefile, in dem das Dateisystem der virtuellen Maschine liegt,
wird mit dem Parameter ubd0s spezifiziert.
Mit umid kann man jeder virtuellen Maschine einen Namen geben. Der Name wird im
Kommandozeilentool uml_mconsole genutzt, um auf die virtuelle Maschine zuzugreifen. Die
uml_mconsole ist eine Wartungskonsole, mit der virtuelle Maschinen angehalten, neu gestartet
und zurückgesetzt werden können. Außerdem können mit dem Tool Änderungen an der
virtuellen Hardware vorgenommen werden (z. B. Hinzufügen zusätzlicher Netzwerkinterfaces).
Wie schon im Abschnitt 11.2.4 beschrieben, werden die virtuellen Maschinen und der HostRechner mit virtuellen Switches untereinander vernetzt. Die Zuordnung von virtuellen Switches
und virtuellen Netzwerkkarten der virtuellen Maschinen erfolgt beim Start der virtuellen Maschinen. Mit eth0=daemon„unix,/tmp/umlswitch0 wird im Startskript z. B. dem ersten Netzwerkinterface eth0 der Switch mit dem Namen umlswitch0 zugewiesen.
#!/bin/bash
linux mem=64M ubd0s=root_fs umid=emb1 \\
eth0=daemon,,unix,/tmp/umlswitch0 \\
eth1=daemon,,unix,/tmp/umlswitch1 \\
eth2=daemon,,unix,/tmp/umlswitch2
Abbildung 11.7: Shell-Skript zum Start einer virtuellen User-mode Linux-Maschine mit drei
Netzwerkinterfaces
134
Zugriff auf virtuelle Maschinen mittels Secure Shell (SSH) und Xnest
Auf virtuelle Linux-Maschinen mit Netzwerkfunktionalität kann mit Hilfe der im Abschnitt
7.5.5 beschriebenen Secure Shell zugegriffen werden. Dazu muss auf den Maschinen eine
SSH-Serversoftware ausgeführt werden. Mit Hilfe von SSH können alle KommandozeilenOperationen, die zur Wartung der Systeme und zur Softwareentwicklung notwendig sind,
durchgeführt werden.
Grafische Bildschirmausgaben werden bei Linux-Systemen im Allgemeinen mit Hilfe des
X-Window-Systems realisiert. Dazu stellt ein sogenannter X-Server die Grundfunktionalität für
das Zeichnen und Bewegen von Fenstern sowie die Interaktion mit Eingabegeräten wie z. B.
Tastatur und Maus zur Verfügung. Unter Linux verwenden zur Zeit die meisten Distributionen
die X-Server-Software der X.Org Foundation [240] oder des XFree86 Project, Inc. [236].
Das X-Window-System ist netzwerkfähig, so dass Programme auf einem Rechner ausgeführt
werden können und die grafische Ausgabe der Programme von den X-Servern anderer Rechner
bewerkstelligt werden kann. Diese Funktionalität ist sehr vorteilhaft, wenn man grafische
Programme auf virtuellen Maschinen ausführen will. Das ist z. B. der Fall, wenn mit einem
grafischen Editor direkt auf einer virtuellen Maschine Programmcode geändert werden soll.
Auch wenn die hier beschriebene Entwicklungsumgebung primär für die Entwicklung von Software für Embedded Systems gedacht ist, ist bei den Entwicklungsarbeiten anstelle von einzelnen
grafischen Anwendungsfenstern manchmal eine komplette Desktop-Umgebung für die virtuellen Embedded Systems wünschenswert. Da die virtuellen Maschinen mangels Grafik-Hardware
keine eigenen X-Server betreiben können, müssen die X-Server der virtuellen Maschinen als Anwendung auf der Hostmaschine laufen. Dazu kann der X-Server Xnest genutzt werden, der als
Applikation auf der grafischen Oberfläche des Host-Rechners läuft (Dokumentation unter [237]).
Zusammen mit Xnest kann man gleichzeitig auch eine Terminal-Emulation (z. B. xterm) starten:
Xnest :1 \& xterm -display :1
Der virtuellen Maschine wird dann im Terminalfenster “erlaubt”, Grafiken in das Xnest-Fenster
auszugeben. Dazu wird der Befehl xhost <IP-Adresse> im Terminalfenster eingegeben. Per
Secure Shell wird im Anschluss auf der virtuellen Maschine die Umgebungsvariable für die
Grafikausgabe export DISPLAY=<Host-IP>:1 auf den Xnest-Server des Hosts eingestellt. Nach
dem Start eines Window-Managers (z. B. Windowmaker [225]) auf der virtuellen Maschine
kann im Xnest-Fenster eine komplette grafische Oberfläche genutzt werden.
In Abb. 11.8 sind drei Xnest-Fenster mit drei Instanzen des Window-Managers Windowmaker
abgebildet, die auf unterschiedlichen virtuellen Maschinen ausgeführt werden.
Andere Möglichkeiten zur Nutzung von grafischen Oberflächen für die Bedienung der virtuellen
Maschinen sind VNC (z. B. RealVNC [186]) und NoMachine [170].
135
Abbildung 11.8: Screenshot: Simulationsumgebung ColSim (oben rechts) und drei Windowmaker-Sessions, die auf drei verschiedenen mit Usermode-Linux realisierten virtuellen Maschinen ausgeführt werden
11.2.5 Zeitskala – Realtime oder Jahressimulation
ColSim wurde als Tool zur Entwicklung von Regelungsalgorithmen geschrieben. Die Güte von
Regelungsalgorithmen lässt sich sehr gut anhand energetischer Betrachtungen von Jahressimulationen abschätzen. Sogar komplexe Energiesysteme lassen sich mit ColSim sehr viel schneller
als in Echtzeit simulieren. Zur Entwicklung und Evaluation von Kommunikationsprotokollen ist
es jedoch meist nicht sinnvoll, schneller als in Echtzeit zu simulieren. Für das Zusammenspiel
mit Reglern in virtuellen Maschinen wurde ColSim deshalb um ein Zeitsynchronisationssystem
erweitert, das ein Abbremsen von ColSim auf Echtzeit ermöglicht. Dabei rechnet ColSim immer
den nächsten Simulationsschritt und wartet nach dem Beenden der Berechnungen, bis der im
Simulationsschritt schon abgebildete Zeitpunkt erreicht ist.
136
11.2.6 Anwendungsbeispiel Reglerentwicklung für eine thermische Solaranlage
Das Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit förderte in den Jahren
1993 bis 2002 mit seinem Solarthermie-2000-Programm solarthermische Demonstrationsanlagen. Eine dieser Anlagen wurde im Studentendorf Vauban in Freiburg im Breisgau errichtet. Sie
verfügt über eine Kollektorfläche von 143 m2 und ein Puffervolumen von 6 m3 . Zweck dieser
Anlage ist die Brauchwasservorwärmung für ein Studentenwohnheim mit 580 Bewohnern.
Die Nacherwärmung erfolgte zunächst mit herkömmlichen Heizkesseln, später jedoch mit
Fernwärme.
Im Rahmen des vom Bundesministerium für Wirtschaft und Technologie geförderten Projekts
ConCheck wurde die Anlage modernisiert. Der Forschungsgegenstand von ConCheck war die
Entwicklung und Erprobung von Regelungssystemen für die Be- und Entladeseite von großen
solarthermischen Anlagen. Bei der Modernisierung der Solaranlage des Freiburger Studentenwohnheims wurden die Be- und Entladeeinrichtungen für die Solarspeicher durch zwei Kompaktstationen mit integrierten Wärmeübertragern realisiert (siehe Abbildung 11.9).
Abbildung 11.9: Mit Embedded Systems bestückte Kompaktbaugruppen der Solarthermie 2000Anlage im Studentendorf Vauban in Freiburg im Breisgau
137
Die Kompaktstationen sind mit jeweils einem netzwerkfähigen Embedded System bestückt, das
als Regelungseinheit fungiert. Diese Embedded Systems können Temperaturen, Volumenströme
sowie einige andere Größen messen. Außerdem steuern sie alle Aktoren (Pumpen, Mischer, etc.)
an.
Über das Netzwerk des Studentenwohnheims haben die Embedded Systems Zugang zum
Internet. Dieser Zugang wird für Fernwartungszwecke wie z. B. das Aktualisieren der Regelungssoftware oder das Abrufen von Messdaten genutzt. Die Visualisierung des Anlagenzustands
per Webbrowser (siehe Abschnitt 9) und ein WAP-Zugang (siehe Abschnitt 10) wurden ebenfalls
implementiert. [22].
Die Regelungsalgorithmen auf den Embedded Systms wurden zunächst so realisiert, dass die
komplette Regelung aufgrund lokaler Messwerte erfolgte. Bei der Analyse des Betriebs anhand
von Messdaten zeigte sich dann, dass zusätzliche Informationen und Messgrößen aus der
Systemperipherie und dem Internet (z. B. Wetterdaten) für einen optimierten Betrieb relevant
sind. Um die Regelungssoftware um entsprechende Funktionen zu erweitern und zu optimieren,
wurde das komplette thermische System der Solaranlage in ColSim modelliert. Die Embedded
Systems wurden mit Hilfe von virtuellen Maschinen emuliert und – wie im Abschnitt 11.2.4
beschrieben – an ColSim angebunden [23].
Beide Kompaktstationen benötigen für eine effiziente Regelung Informationen über den
Ladezustand des thermischen Speichers. Deshalb wurde ein Speicherregelungsmodul erstellt
und im Simulator getestet. Anhand der Messwerte zweier Temperatursensoren bestimmt es den
Ladezustand des thermischen Speichers. Im Simulator wurde mit Hilfe des virtuellen Netzwerks
ein Kommunikationsmodul für die Regelungssoftware entwickelt, das einen Austausch von
Messdaten und anderen Informationen zwischen den beiden Kompaktstationen ermöglicht.
Anhand von Jahressimulationen konnte anschließend der Regelungsbetrieb einschließlich der
Kommunikationsprozesse getestet und analysiert werden.
Die Simulationsumgebung diente außerdem der Entwicklung von internetbasierten Zusatzfunktionen. Es wurde z. B. ein Softwaremodul programmiert, das Messdaten der Anlage auf Plausibilität überprüft und im Fehlerfall Störungsmeldungen per Email und SMS verschickt.
138
Kapitel 12
Betriebssysteminstallation für Verteilte
Systeme
Bei der Installation von verteilten Systemen mit Embedded Systems muss das Betriebssystem auf
jedes einzelne Embedded System aufgespielt werden. Der Aufwand, dies für jedes System von
Hand zu tun, ist sehr groß. Bei größeren Stückzahlen empfiehlt sich deshalb ein Automatisieren
der Prozesse.
12.1 Betriebssystem-Images
Das Betriebssystem könnte man von standardisierten Installationsmedien auf jedes einzelne
Embedded System des verteilten Systems aufspielen. Dieses wäre jedoch sehr zeitaufwändig,
da ständig Nutzereingaben, wie z. B. Spracheinstellung oder Netzwerkkonfiguration notwendig
wären. Bei den meisten Betriebssystemen ist der Prozess nicht automatisierbar. Eine Ausnahme bilden jedoch Betriebssysteme, bei denen eine Installation mittels Templates stattfinden kann.
Da bei verteilten Systemen die Hardware aller Embedded Systems und das grundsätzliche
Betriebssystem oft bei allen Systemen gleich sind, bietet es sich an, mit Betriebssystem-Images
zu arbeiten.
Um ein Betriebssystem-Image zu erstellen, wird das gewünschte Betriebssystem zunächst auf
einem einzelnen Embedded System installiert. Anschließend folgt die Installation der Software, die später auf allen Embedded Systems vorhanden sein soll. Danach wird der Massenspeicher (Festplatte, CompactFlash oder Ähnliches) aus dem Embedded System ausgebaut und an
einen anderen Rechner angeschlossen. Das geschieht bei CompactFlash z. B. mit einem USBKartenleser (USB = Universal Serial Bus) und bei Festplatten z. B. mit einem USB-to-IDEAdapter (IDE = Integrated Drive Electronics). Auf diesem Rechner sollte dann der Inhalt des
Massenspeichers des Embedded Systems abgelegt werden, um damit später die Massenspeicher
aller anderen Embedded Systems des verteilten Systems zu beschreiben. Für das Kopieren des
Massenspeicherinhalts gibt es verschiedene Ansätze, z. B. das blockweise Kopieren und das dateibasierte Kopieren.
139
140
KAPITEL 12. BETRIEBSSYSTEMINSTALLATION
12.1.1 Blockweises Kopieren des gesamten Massenspeichers
Dieses Verfahren hat den Vorteil, dass mit einem einzigen Befehl und ohne weitere Nutzereingaben der gesamte Kopiervorgang durchgeführt werden kann. Dabei werden auch der Bootloader
und alle Partitionsinformationen kopiert.
Zum blockweisen Kopieren wird das Programm dd unter Linux genutzt. Die Befehlszeile
dd if=/dev/sda of=linux.img
veranlasst das blockweise Auslesen des kompletten Inhalts eines Speichermediums (z. B. einer
CompactFlash-Karte). Die ausgelesenen Daten werden in die Datei linux.img geschrieben.
Die Bezeichnung if steht dabei für input file = Eingabedatei. Unter Linux werden die meisten
Hardwarekomponenten in Form von sogenannten Gerätedateien (device files) angesprochen.
/dev/sda ist die Gerätedatei für einen Massenspeicher. Die Bezeichnung of steht für output file =
Ausgabedatei. Damit wird der Name der Ausgabedatei festgelegt.
Das so erzeugte Betriebssystemimage linux.img kann auch mit einem einzigen Befehl auf einen
anderen Massenspeicher zurückgeschrieben werden. Dazu werden im Vergleich zum Auslesen
nur input file und output file vertauscht.
dd of=/dev/sda if=linux.img
Das blockweise Kopieren von Massenspeichern hat einen großen Nachteil: Der Prozess ist sehr
zeitaufwändig, da der komplette Inhalt des Massenspeichers gelesen werden muss. Das gilt auch,
wenn nur ein kleiner Teil des Massenspeichers beschrieben ist, weil auch ungenutzte Teile des
Massenspeichers “kopiert” werden. Das Zurückschreiben des Images auf einen anderen Massenspeicher dauert sogar noch länger. Zum Kopieren eines 512 MB-Abbildes auf eine CompactFlash-Karte mit einem USB-Kartenleser werden ca. 23 Minuten benötigt. Für das Kopieren
von ganzen Festplatteninhalten ergeben sich daraus Wartezeiten (z. B. >5 Stunden bei einer 20
GB-Festplatte), die bei größeren Anzahlen von zu beschreibenden Massenspeichern sicher nicht
tolerabel sind
12.1.2 Dateibasiertes Kopieren eines Massenspeichers
Im Gegensatz zum blockweisen Kopieren eines Massenspeichers werden beim dateibasierten
Kopieren mehrere Schritte durchgeführt. Zunächst wird die Partitionierung des zu kopierenden
Massenspeichers festgestellt. Das kann unter Linux zum Beispiel mit dem Programm fdisk bewerkstelligt werden. Mit der Befehlszeile
fdisk /dev/sda
wird fdisk für den Massenspeicher sda aufgerufen. Durch das Drücken der Taste p wird die
Partitionstabelle ausgegeben (siehe Abb.: 12.1).
12.1. BETRIEBSSYSTEM-IMAGES
141
The number of cylinders for this disk is set to 9729.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/hdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot
/dev/hdb1
*
/dev/hdb2
Start
1
9637
End
9636
9729
Blocks
77401138+
747022+
Id
83
82
System
Linux
Linux swap/Solaris
Abbildung 12.1: Partitionstabelle einer 80 GB Festplatte mit einer Linux- und einer Linux-SwapPartition
Auf dem Zielmassenspeicher wird danach eine Partitionstabelle erstellt, die aus der gleichen
Anzahl von Partitionen mit den gleichen Partitionstypen besteht. Die Größen der Partitionen
dürfen variieren. Es muss jedoch gewährleistet werden, dass die neuen Partitionen ausreichend
Platz bieten.
Die Inhalte der einzelnen Partitionen des Massenspeichers werden nun in einzelne Verzeichnisse
auf der Festplatte des Rechners kopiert, von dem aus sie hinterher wieder auf die Zielmassenspeicher übertragen werden. Vor dem Kopieren müssen die Partitionen noch mit dem mount-Befehl
in den Dateibaum des Rechners eingebunden werden. Bsp.:
mount /dev/hdb1 /mnt/partition1
Die erste Partition der Festplatte /dev/hdb wird unter /mnt/partition1 in das Dateisystem eingebunden. Danach kann der Kopiervorgang durchgeführt werden. Bsp.:
cp -r -p /mnt/partition1/* /home/nutzer/partition1
Dabei werden alle Dateien aus dem Verzeichnis /mnt/partition1 in das Verzeichnis
/home/nutzer/partition1 kopiert. Wichtig ist dabei, dass mit dem Schalter -r dafür gesorgt wird,
dass die Inhalte aller Verzeichnisse unter /mnt/partition1 mitkopiert werden. Der Schalter -p bewirkt, dass die Zugriffsrechte aller Dateien beim Kopieren erhalten bleiben. Nach dem Beenden
des Kopierens müssen die Partitionen wieder aus dem Dateisystem entfernt werden. Bsp.:
umount /dev/hdb1
Sind alle Daten des Quelldatenträgers in Verzeichnissen gesichert, kann mit der Vorbereitung des
Zieldatenträgers begonnen werden. Zunächst wird, wie schon oben beschrieben, eine Partitions-
142
tabelle angelegt. Das kann auch per Skript erfolgen. Bevor die Partitionen beschrieben werden,
müssen zunächst Dateisysteme angelegt werden. Bsp.:
mkfs.ext3 /dev/hdb1
Mit dem obigen Befehl wird auf der ersten Partition der Festplatte /dev/hdb ein ext3-Dateisystem
angelegt. Sind alle Dateisysteme angelegt worden, können die Partitionen mit mount in das Dateisystem des Rechners eingebunden werden und die Inhalte der Verzeichnisse der Kopien des
Quellmassenspeichers auf die entsprechenden Partitionen kopiert werden. Beim Kopieren mit cp
müssen wieder die Schalter -r und -p gesetzt sein.
Sind alle Kopiervorgänge abgeschlossen, fehlt nur noch die Installation des Bootloaders, ohne
den das Betriebssystem nicht gestartet werden kann. Unter Linux wird der Bootloader GRUB
[94] mit dem Befehl grub-install installiert. Bsp.:
grub --root-directory=<Beispielverzeichnis> /dev/hdb
Dabei gibt <Beispielverzeichnis> in der Befehlszeile den Ort an, an dem die BootloaderKomponenten abgelegt werden sollen.
12.2 Klonen eines laufenden Systems
Sollen Betriebssystem und Software eines bereits fertig installierten Embedded Systems auf ein
zweites System übertragen werden, kann dies auch ohne die Erstellung eines BetriebssystemImages realisiert werden. Dabei werden alle Daten des fertig installierten Systems per Netzwerk
auf das zweite System kopiert. Das funktioniert jedoch nur, wenn das Zielsystem über die
Fähigkeit verfügt, per Netzwerk zu booten. Dazu werden die Mechanismen des von Intel [133]
entwickelten Preboot Execution Environment (PXE) genutzt. Außerdem wird ein Rechner
benötigt, auf dem Serversoftware für die Netzwerk-Dienste Dynamic Host Configuration
Protocol (DHCP, siehe Abschnitt 7.5.1), Trivial File Transfer Protocol (TFTP) und Network
File System (NFS) läuft.
Das Embedded System, auf dem die Software installiert werden soll, wird angeschaltet und folgende Schritte laufen automatisiert ab:
1. Das Zielsystem bekommt vom DHCP-Server eine IP-Adresse zugewiesen. Es erhält zusätzlich die Informationen, unter welcher IP-Adresse der TFTP-Server zu erreichen ist und
welche Datei auf dem TFTP-Server das Network Bootstrap Program (NBP) enthält.
2. Das NBP wird vom TFTP-Server heruntergeladen und ausgeführt.
3. Das NBP bootet einen Linux-Kernel.
4. Der Linux-Kernel bindet das root-Dateisystem per Network File System ein und startet die
benötigten Systemdienste, um von außen auf das System zugreifen zu können.
12.3. NUTZUNG VON PAKETMANAGERN ZUR SOFTWAREINSTALLATION
143
Sind diese Schritte erfolgt, kann das Zielsystem per Netzwerk administriert werden. Nach
dem Einloggen auf dem System wird zuerst die Systemuhr per Network Time Protocol (siehe
Abschnitt 7.5.3) gestellt.
Dann muss der Massenspeicher für die Installation vorbereitet werden. Dazu wird er, wie im
Abschnitt 12.1.2 beschrieben, partitioniert und es werden Dateisysteme angelegt. Danach wird
der Massenspeicher unter /mnt gemountet.
Mit der Befehlszeile
ssh -c blowfish root@<Maschine> tar clf - / | (cd /mnt;tar xf -)
erfolgt das eigentliche Klonen. Die Befehlszeile lässt sich in drei Teile untergliedern:
ssh -c blowfish root@<Maschine> : Dieser Teil der Befehlszeile baut eine Verbindung zu dem
Rechner auf, der als Klonvorlage dient. Über die Verbindung können auf diesem Rechner Befehle ausgeführt werden. Mit -c blowfish wird eine schwache Verschlüsselung für
die Verbindung gewählt. Dadurch entsteht weniger Prozessorlast als bei der Standardverschlüsselung von SSH und das Clonen wird beschleunigt.
tar clf - / : Auf dem Rechner, der als Klonvorlage dienen soll, wird mit tar (tape archive) der
komplette Inhalt des Dateisystems (in der Befehlszeile dargestellt als “/”) in einen Datenstrom verpackt, der per SSH auf das Zielsystem übertragen wird. tar wird mit den Schaltern
c, l und f aufgerufen. c ist die Anweisung zum Erzeugen des Datenstroms. Durch l wird tar
angewiesen, innerhalb des Dateisystems zu bleiben. Dadurch wird ein Kopieren des vom
Linux-Kernel erzeugten /proc-Verzeichnisses unterbunden, was zu Fehlern führen würde.
Der Schalter f bewirkt das Anlegen einer Datei. Der Dateiname “-” bewirkt die Ausgabe
auf der Kommandozeile.
| (cd /mnt; tar xf - ) : Durch “|” (eine sogenannte pipe) wird der per SSH auf das Zielsystem
übertragene Datenstrom an den dritten Teil der Befehlszeile übergeben. Dort wird zunächst mit cd /mnt in das Zielverzeichnis gewechselt. tar xf - wandelt den übertragenen
Datenstrom zurück in Dateien und Verzeichnisse.
Nach dem Beenden des Kopiervorgangs muss jetzt noch der Bootloader auf dem Zielsystem
installiert werden. Die Installation erfolgt wie im Abschnitt 12.1.2 beschrieben.
12.3 Nutzung von Paketmanagern zur Softwareinstallation
Die Administration von verteilten Systemen mit vielen Knoten ist eine komplexe Aufgabe. Bei
derartigen Systemen fallen immer wieder Softwareupdates an, da Sicherheitslücken beseitigt
werden müssen und Regelungs- und Messprogramme aktualisiert werden sollen. Alle damit
verbundenen Arbeiten lassen sich im Prinzip durch das Einspielen der entsprechenden Dateien
144
per Fernadministration durchführen. Dabei kann jedoch sehr schnell der Überblick darüber
verloren gehen, welche Softwareversionen auf welchem Knoten vorhanden sind und welche
Abhängigkeiten bei der Installation aufgelöst werden müssen. Zur Vermeidung solcher Probleme
empfiehlt sich die Nutzung von Paketmanagern, wie z. B. Redhat Package Manager (rpm [187])
oder dpkg und apt (Debian [50]).
Bei der Paketinstallation übernimmt der Paketmanager alle zur Installation notwendigen
Schritte. Er lädt das zu installierende Paket von einem Installationsserver, löst Abhängigkeiten
zu anderen Paketen auf – sorgt also für das Vorhandensein aller zur Installation der Software
benötigten Komponenten – entpackt das Paket, kopiert alle im Paket enthaltenen Dateien auf
die dafür vorgesehen Plätze im System und führt eine erste Konfiguration der Software durch.
Mit Hilfe der im Paket enthaltenen Informationen ist der Paketmanager auch in der Lage, die
Software wieder rückstandsfrei zu deinstallieren. Paketmanager pflegen eine Datenbank, in der
die installierten Pakete mit ihren Versionsnummern katalogisiert werden. Durch ein Abfragen
der Datenbank kann schnell ermittelt werden, welche Software auf einem System installiert ist.
Zu jedem Paketmanager sind entsprechende Developer-Programme erhältlich, mit denen sich
Pakete mit eigener Software einfach erstellen lassen. Diese können dann ebenfalls über einen Installationsserver auf alle Rechner des verteilten Systems verteilt und dort installiert werden. Wird
später eine neuere Version des Pakets auf dem Installationsserver abgelegt, erfolgt im Rahmen
des nächsten Systemupdates der verteilten Systeme das Update auf die neuere Version der Software. Zur Verifizierung der Authentizität der zu installierenden Pakete können diese mit einer
digitalen Signatur versehen werden, die vom Paketmanager ausgewertet wird.
Kapitel 13
Konfigurations- und Parametriersoftware
13.1 Konfiguration und Parametrierung in der industriellen
Prozess- und Fertigungsautomatisierung
In der industriellen Prozess- und Fertigungsautomatisierung muss heute eine große Zahl von
Geräten in Betrieb genommen und im laufenden Betrieb parametriert werden. Das Parametrieren
erfolgt dabei meist über Feldbus-Schnittstellen. Dazu bieten die Hersteller Softwaretools an, die
oft spezifisch für ihre Geräte und die genutzten Feldbusschnittstellen sind. Um die Parametrierung zu erleichtern und nicht für jedes Geräte eine eigene Software einsetzen zu müssen, wurden
verschiedene Technologien entwickelt, die mit Hilfe einer einzigen Software einen Zugriff auf
die Geräte ermöglichen.
13.1.1 Electronic Device Description Language (EDDL)
Die Electronic Device Description Language (EDDL) [66] ist ein in der IEC 61804 beschriebener Standard zur elektronischen Beschreibung von Geräten. Er wird zur Konfiguration und
zum Betrieb der Geräte genutzt. EDDL enstand aus einem Zusammenschluss der jeweiligen
Beschreibungssprachen der HART Communication Foundation [99], der PROFIBUS Nutzerorganisation e.V [183] und der Fieldbus Foundation [83].
EDDL definiert eine eigene speziell für die Gerätebeschreibung zugeschnittene Sprache, deren
Sprachumfang viel kleiner als der einer Standard-Programmiersprache ist. Gerätehersteller erstellen in dieser Sprache für jedes ihrer Geräte jeweils eine textbasierte Beschreibung, die sogenannte Electronic Device Description (EDD). Eine Host-Applikation liest die EDD eines Geräte
und lernt daraus, wie mit diesem Geräte kommuniziert werden kann und welche Informationen zur Verfügung stehen. Der Zugriff auf EDDs ist unabhänig von Betriebssystem und Rechnerplattform, da sie keinen Programmcode enthalten. Stattdessen wird der in ihnen enthaltene
Text von der Hostapplikation interpretiert. Für alle gängigen Betriebssysteme existieren HostApplikationen. Nachteilig ist, dass sich EDDL nur für Geräte von geringer bis mittlerer Komplexität eignet [24].
145
146
KAPITEL 13. KONFIGURATIONS- UND PARAMETRIERSOFTWARE
13.1.2 Field Device Tool (FDT)
FDT ist hervorgegangen aus einem Zusammenschluss von großen Unternehmen der Automatisierungsbranche, die 2003 die FDT Joint Interest Group gegründeten. In 2005 wurde aufgrund
der steigenden Mitgliederzahl der Gruppe und des damit verbundenen Verwaltungsaufwands
die FDT Group [82] als ein Verein nach belgischem Recht gegründet, der die Pflege und
Weiterentwicklung der in der IEC 62453 festgeschriebenen Norm betreibt.
Field Device Tool dient dazu, die Kommunikationsschnittstellen zwischen Feldgeräten und
Leitsystemen zu vereinheitlichen. Die definierten Schnittstellen funktionieren unabhängig vom
Kommunikationsprotokoll und den jeweiligen Softwareumgebungen auf dem Leitsystem und
den Geräten.
Gerätehersteller müssen für ihre Geräte oder Gerätegruppen jeweils eine gerätespezifische
Bedienapplikation, den sogenannten Device Type Manager (DTM) entwickeln. Dieser beinhaltet
alle wichtigen gerätespezifischen Daten und Funktionen. Er enthält Informationen über die
Gerätestruktur, Kommunikations- und interne Abhängigkeiten. Der DTM kann genutzt werden,
um ein Gerät zu konfigurieren, zu bedienen und Geräteparameter abzurufen. Er besitzt dafür
eine grafische Benutzeroberfläche, die je nach Ausprägung sehr unterschiedlich aussehen kann,
da bisher keine Styleguides für die Erstellung existieren. Ein großer Nachteil dieser Technik
ist, dass die meisten Gerätehersteller DTM-Software liefern, die eng an Microsoft-Windows
gebunden ist [24]. Dadurch entsteht eine starke Abhängigkeit von dieser Plattform.
Device Type Manager sind nicht allein lauffähig, sondern benötigen eine sogenannte Frame Application, auch FDT Container genannt. Die FDT Container können zu ganz unterschiedlichen
Zwecken eingesetzt werden (Konfiguration, Bedienung, Werkzeug für das Asset-Management,
etc.). Sie stellen auch alle Funktionen zur Verfügung, die die Kommunikation zwischen dem
Hostsystem und den angeschlossenen Feldbussen ermöglichen.
FDT und EDDL konkurrieren schon einige Jahre miteinander. Ein übergreifender Standard, der
die Vorteile beider bisheriger Standards in sich vereinigt, wäre wünschenswert. Ansätze zur Vereinigung von FDT, EDDL und dem im Abschnitt 6.3.2 vorgestellten OPC UA sind in [24] beschrieben.
13.2 Softwareinstallation für verteilte Regelungs- und Monitoringsysteme für dezentrale Energiesysteme
Die Installation des Betriebssystems kann für eine größere Anzahl identischer Rechner mit den
im Abschnitt 12 beschriebenen Methoden recht einfach bewerkstelligt werden. Zusätzlich zur
Installation des Betriebssystems und der Anwendungssoftware müssen oft Zugangsdaten für die
Telekommunikation, Sensorlisten für Messwerterfassungssysteme und ähnliche Daten parame-
13.2. SOFTWAREINSTALLATION
147
triert werden. Es wäre wünschenswert, die im Abschnitt 13.1 beschriebenen Techniken auch hier
einsetzen zu können. Das ist aber leider nicht möglich, da für die genutzte Sensorik und Aktorik meist keine entsprechenden elektronischen Beschreibungen existieren. Ein weiterer Hinderungsgrund ist, dass die benötigte Software für die in dieser Arbeit beschriebenen Systeme, die
unterschiedliche Linux-Betriebssysteme nutzen, nicht verfügbar ist. Es bleibt zu hoffen, dass die
technische Entwicklung hin zu Software ohne Plattformabhängigkeiten geht, so dass in Zukunft
auch für dezentrale Energiesysteme standardisierte Software zur Konfiguration und zum Betrieb
der Systeme genutzt werden kann.
13.2.1 Grafisches Userinterface zur Systemparametrierung
Damit Parametrierungs-Aufgaben auch von Personen ohne programmiertechnische Fähigkeiten durchgeführt werden können, wurde für die zweite Ausbaustufe des im Abschnitt 15.1
beschriebenen Wärmepumpen-Monitoringsystems eine Parametriersoftware mit grafischer
Oberfläche entwickelt. Für die Entwicklung dieser Software kamen das GTK+ -Toolkit [96] und
die Programmiersprache C zum Einsatz.
Die hier beschriebene Parametriersoftware wurde für Linux-Betriebssysteme entwickelt. Da C
und GTK+ auch für Microsoft Windows-Betriebssysteme verfügbar sind, ist eine Portierung mit
überschaubarem Aufwand möglich. Ein Screenshot des Hauptfensters der Parametrieroberfläche
ist in Abb. 13.1 abgebildet.
Für die Kommunikationsanbindung der Monitoring-Systeme wird GPRS (siehe Abschnitt
7.3.1) genutzt. Zur Einwahl in das Mobilfunknetz muss eine PIN eingegeben werden. Aus der
ebenfalls einzugebenden RDA-Nummer werden die Zugangsdaten zum GSM-Accesspoint des
Mobilfunk-Providers generiert.
Die eingesetzten Monitoringsysteme verfügen über unterschiedliche Ausstattungen an Messtechnik, da verschiedene Wärmepumpensysteme vermessen werden müssen. Aus diesem
Grund muss jedes einzelne Monitoringsystem den angeschlossenen Messgeräten entsprechend
individuell parametriert werden.
Eines der Ziele bei der Softwareentwicklung war es, eine möglichst weitreichende Überprüfung
der Nutzereingaben zur Verhinderung von Fehlparametrierungen zu gewährleisten. Dazu
analysiert die Software die Nutzereingaben und weist den Nutzer auf Fehler und ungültige
Anweisungen hin. In Abb 13.2 sind zwei derartige Fehlermeldungen dargestellt. Die Software
überprüft z. B. die Länge der eingegebenen PIN oder die Gültigkeit von Zugriffs-IDs für
Wärmemengenzähler. Soweit das möglich ist, werden keine Textfelder, sondern Menüs mit
vorgegebenen Optionen genutzt, um nur gültige Eingaben zuzulassen (z. B. nur Typen von
Wärmemengenzählern, die im Projekt auch wirklich genutzt werden).
148
Abbildung 13.1: Hauptfenster der Parametriersoftware für WP-Effizienz-Messsysteme
Abbildung 13.2: Fehlermeldungen der WP-Effizienz-Parametriersoftware bei einer ungültigen
PIN-Eingabe bzw. bei der Eingabe einer falschen ID für einen Wärmemengenzähler
149
Nach Abschluss der Parametrierung bekommt der Nutzer der grafischen Oberfläche eine Zusammenfassung der von ihm getätigten Eingaben in einem Dialogfenster präsentiert (siehe Abb.
13.3). Durch die übersichtliche Darstellung der Zusammenfassung ist eine einfach Kontrolle aller Eingaben möglich. Sind noch Fehler in der Parameterliste vorhanden, kann der Nutzer zum
vorherigen Programmfenster zurückkehren und Korrekturen durchführen. Durch die nochmalige Überprüfung aller Eingaben wird die Wahrscheinlichkeit für Fehler gesenkt. Erst wenn der
Programmnutzer bestätigt, dass die Parameterliste korrekt ist, wird mit dem Generieren der Konfigurationsfiles für das Messsystem begonnen (siehen Abb. 13.4).
Abbildung 13.3: Zusammenfassung aller Eingaben für die Parametrierung eines WP-EffizienzMesssystems
Abbildung 13.4: Ausgabe der WP-Effizienz-Parametriersoftware beim Generieren von Konfigurationsdateien
150
13.2.2 Automatische Hardwareerkennung für Messtechnik
Neben klassischer Messtechnik, bei der keine Informationen über die Konfiguration aus den
Messgeräten ausgelesen werden können, gibt es zunehmend Bussystem-basierte Messwerterfassungssysteme. Bei diesen Systemen ist es von Vorteil, dass die an den Bus angekoppelten
Sensorik- und auch Aktorikbausteine sehr häufig über Identifikationsnummern verfügen,
aus denen sich Rückschlüsse ziehen lassen, um welche Art von Bausteinen es sich handelt.
Durch ein Scannen des Busses nach angeschlossenen Geräeten mit Hilfe der Identifikationsnummern lässt sich im günstigsten Fall die komplette Konfiguration des Messsystems automatisieren.
Ein Beispiel für ein Bussystem mit aussagekräftigen Identifikationsnummern der Bus-Bausteine
ist der OneWire-Bus der Firma Dallas Semiconductors/Maxim [151]. Jeder der Sensorik- und
Aktorik-Bausteine hat eine Identifikationsnummer, über die er beim Auslesen des Bussystems
identifiziert werden kann. Die Identifikationsnummern bestehen aus 16 Stellen. Die ersten
beiden Stellen beinhalten den sogenannten Family Code, über den der Typ des Bausteins identifiziert werden kann. Die weiteren 14 Stellen enthalten eine Seriennummer, die den einzelnen
Baustein identifiziert.
Bsp.: Identifikationsnummer 28E05FCC000000E6 für einen OneWire-Baustein:
28
|{z}
{z
}
|E05F CC000000E6
F amilyCode
Seriennummer
Der Family Code (siehe Tabelle 13.1) sagt aus, dass es sich um einen Temperatursensor vom
Typ DS18B20 handelt. Aus dieser Information kann abgeleitet werden, wie der Baustein
softwaretechnisch angesprochen werden muss. Sind mehrere Temperatursensoren an das
OneWire-Bussystem angeschlossen, lassen sie sich über die Seriennummern zweifelsfrei
voneinander unterscheiden und ansprechen. Die Informationen können dann zum automatischen
Generieren einer Sensorliste für die Messtechnik genutzt werden.
Family Code
Baustein
Funktion
05
DS2405
Single adressable Switch
10
DS1820, DS18S20
Temperature with alarm trips
1D
DS2423
4KB NV RAM memory with external counters
20
D2450
4-Channel A/D converter
28
DS18B20
Adjustble resolution temperature
Tabelle 13.1: Identifikation ausgesuchter OneWire-Bausteine über ihre Family Codes (siehe
[153])
151
13.2.3 Automatisierte Softwareinstallation
Die Software der Knoten des verteilten Monitoring-Systems besteht aus dem Betriebssystem,
den Kommunikationsprogrammen für die GPRS-Kommunikation und der Mess-Software. Für
alle drei Bereiche müssen Konfigurationsdateien erstellt und auf dem Zielsystem installiert
werden.
Konfiguration von Betriebssystem und Kommunikationssoftware
Jeder Knoten im verteilten Monitoringsystem bekommt einen generischen Hostnamen. Diese
Hostnamen ergeben sich aus den jeweils letzten Stellen der IP-Adressen, die den einzelnen SIMKarten des Systems zugeordnet sind. Die Parametriersoftware erfragt diese Nummern (sog. RDANummern) und generiert daraus die verschiedenen Konfigurationsdateien:
1. /etc/hostname: Beim Einloggen auf dem Embedded System und beim Arbeiten mit dem
System wird in der Shell der in /etc/hostname eingetragene Hostname angezeigt. Das erleichtert beim parallelen Arbeiten mit mehreren Systemen den Überblick.
2. pap-secrets: Diese Datei enthält die Zugangsdaten für die GPRS-Einwahl.
3. pppstart: Alle Parameter für die GPRS-Einwahl werden in dieser Datei festgelegt (z. B.
Baudraten, Einwahlverhalten, etc.).
4. dialup.chat: Dieses Einwahlskript ist für die Eingabe der PIN, die Einwahl und die Authentifikation gegenüber dem Mobilfunkprovider zuständig.
Messtechnik-Konfiguration
Da die verwendeten M-Bus-Zähler zum Zeitpunkt der Parametrierung der Messsysteme nicht
zur Verfügung stehen, müssen ihre Daten über die grafische Oberfläche der Parametriersoftware
eingegeben werden.
Ablauf der Parametrierung und Aufspielen der Software auf das Zielsystem
Je nach verwendetem Embedded System werden zwei verschiedene Arten der Softwareinstallation ausgeführt. Bei den im Abschnitt 15.1.3 beschriebenen Embedded Systems werden
CompactFlash-Karten als Massenspeicher verwendet. In diesem Fall wird für die Parametrierung die in Abb. 13.5 dargestellte Infrastruktur genutzt.
152
Cardreader
Parametrier−Software
Parametrier−Rechner
RS232
CompactFlash−Karte
OneWire−Messtechnik
Abbildung 13.5: Infrastruktur für die Softwareinstallation von Wärmepumpen-Monitoringsystemen
Die Parametrierung läuft in folgenden Schritten ab:
1. Einlegen der CompactFlash-Karte des Embedded Systems in den USB-Cardreader des
Parametrierrechners
2. Anschluss von Bus-basierter Messtechnik (z. B. OneWire-Bausteine) an den Parametrierrechner
3. Starten der Parametriersoftware
4. Eingabe aller notwendigen Daten für die Parametrierung
5. Schreiben eines Betriebssystem-Images mit dem im Abschnitt 12.1.1 beschriebenen Verfahren auf die CompactFlash-Karte
6. Hardwareerkennung der Bus-basierten Messtechnik
7. Automatisches Generieren der Konfigurationsdateien für die GPRS-Einwahl und die Messtechnik
8. Kopieren der Konfigurationsdateien auf die CompactFlash-Karte
9. Installation der CompactFlash-Karte in das Embedded System
10. Testlauf des Messsystems im Labor
Der Testlauf des fertig konfigurierten Systems mit angeschlossener Messtechnik ist notwendig,
um das korrekte Zusammenspiel aller Komponenten zu überprüfen. Im Labor können Fehlerkorrekturen sehr viel einfacher vorgenommen werden als später im Feld.
153
Wenn Embedded Systems genutzt werden, die über einen fest eingebauten Massenspeicher verfügen, auf dem schon ein Betriebssystem vorinstalliert ist, können die erstellten Konfigurationsdateien per Netzwerkanbindung (z. B. per FTP oder SCP) vom Parametrierrechner auf das
Embedded System übertragen werden. Dabei müssen auf dem Massenspeicher des Embedded
Systems bestimmte weitere Änderungen vorgenommen werden. Z. B. müssen neue Verzeichnisstrukturen angelegt und an zahlreichen Stellen im System Zugriffsrechte geändert werden.
Die Installation gestaltet sich dadurch insgesamt sehr viel komplexer als bei einem System, bei
dem mit Betriebssystemimages gearbeitet werden kann.
154
Kapitel 14
Hardware-Anforderungen an Verteilte
Systeme
14.1 Speichermedien
Embedded Systems benötigen wie jeder andere Computer auch Speichermedien, die nicht flüchtig sind. Die Anforderungen an die Speicher können bei Embedded Systems jedoch wesentlich
höher sein als bei handelsüblichen Personalcomputern, da sie unter ungünstigen Umgebungsbedingungen über lange Zeiträume wartungsfrei laufen müssen. Prinzipiell muss zwischen zwei
Arten von nicht flüchtigen Speichern unterschieden werden, die bei Embedded Systems Verwendung finden:
• Festplatten
• Speichermedien, die aus Flash-Bausteinen aufgebaut sind.
Je nach Anwendung können beide Varianten oder sogar eine Kombination von beiden geeignet
sein.
14.1.1 Festplatten
Festplatten sind immer dann geeignet, wenn sehr schnelle Speichermedien benötigt werden und
wenn mit sehr vielen Schreib- und Lesezyklen gerechnet werden muss. Ein großes Problem
der Festplatten ist ihre Störanfälligkeit bei hohen Temperaturen. Sollen Festplatten in einem
Embedded System bei hohen Umgebungstemperaturen genutzt werden, müssen geeignete
Kühlmechanismen verwendet werden (z. B. Lüfter, Heatpipes).
Die Lebensdauer von Festplatten hängt sehr stark von ihrer Bauform und dem Anwendungsfeld
ab, für das sie entwickelt wurden. Die längste Lebensdauer haben Server-Festplatten im
3,5-Zoll-Format mit hohen Umdrehungszahlen (z. B. 10000 U/min). Das gilt jedoch nur, wenn
sie ständig laufen und nur selten Starts und Stopps auftreten. Ihr Stromverbrauch und die damit
155
156
KAPITEL 14. HARDWARE-ANFORDERUNGEN AN VERTEILTE SYSTEME
verbundene Abwärme sind außerdem so hoch, dass sie für Embedded Systems kaum geeignet
sind. 2,5-Zoll-Notebookfestplatten haben sich aufgrund ihres sparsamen Stromverbrauchs und
ihrer geringen Wärmeentwicklung besser bewährt. Sie sind auch für eine wesentlich höhere
Anzahl von Start-Stopp-Zyklen ausgelegt, so dass sich durch häufiges Ein- und Ausschalten
des Embedded Systems keine Probleme ergeben. Viele Notebookfestplatten sind nicht für einen
Dauerbetrieb ausgelegt und sollten deshalb auch nicht dafür genutzt werden, da sie sonst nur
geringe Lebensdauern erreichen.
Seit einiger Zeit sind auch Server-Festplatten im 2,5-Zoll-Format verfügbar.
Die Nutzung von Festplatten im Compact Flash II Gehäuse (so genannte Microdrives) ist
sinnvoll, wenn nur gelegentlich Daten gespeichert werden müssen. Diese Festplatten benötigen
sehr wenig Energie, da ihre Platten sich nicht ständig drehen, sondern erst beim Zugriff anlaufen
und kurze Zeit nach dem Zugriff auch wieder stoppen. Die Laufwerke sind jedoch nicht für den
Dauerbetrieb geeignet.
Allgemein sind Festplatten sehr empfindlich gegen starke Magnetfelder und mechanische Beanspruchungen. Bei Arbeitsumgebungen, in denen derartige Belastungen vorkommen, sollten
Speichermedien mit Flash-Speichern genutzt werden.
14.1.2 Speichermedien aus Flash-Bausteinen
Aus Flash-Bausteinen aufgebaute Speichermedien gibt es in ganz verschiedenen Bauformen
(z. B. USB-Stick, Multimedia Card (MMC), Secure Digital Memory Card (SD-Card), Memory
Stick, . . . ). Sehr häufig anzutreffen und für Embedded Systems besonders geeignet ist die
compact flash card (CF-Card). Sie besitzt elektrisch die gleiche Schnittstelle wie StandardFestplatten, nämlich das so genannte Advanced Technology Attachment with Packet Interface
(ATA/ATAPI). Es wurde vom International Committee for Information Technology Standards
[130] erarbeitet. Mit einem mechanischen Adapter können CF-Karten anstelle von Festplatten
in Embedded Systems eingesetzt werden. Sie verhalten sich wie Festplatten und werden
softwaretechnisch vom Betriebssystem auch so angesprochen.
CF-Karten haben den großen Nachteil, dass sie nur eine sehr begrenzte Anzahl von Schreibund Lesezyklen zulassen und dann ausfallen. Je nach Hersteller (z. B. Kingston [140], Sandisk
[190], . . . ) werden Zyklenzahlen zwischen einer Million und fünf Millionen angegeben.
Der Standard der CompactFlash-Association [45] sieht sogar nur 10.000 Zyklen vor. Da oft
auch für einfache Betriebssystemfunktionen, wie z. B. das Schreiben von Log-Files, auf den
Massenspeicher zugegriffen wird, ist diese Zyklenanzahl recht schnell erreicht. Deshalb müssen
Mechanismen entwickelt werden, die die Anzahl der Schreib- und Lesezyklen minimieren. Ein
entscheidender Faktor ist dabei die Wahl des Dateisystems, mit dem die Daten auf der CF-Karte
abgelegt werden. Völlig ungeeignet ist z. B. das beim Betriebssystem Linux sehr häufig genutzte
ext3-Dateisystem, da es bei jedem Lesezugriff auf eine Datei auch schreibend tätig wird und
14.1. SPEICHERMEDIEN
157
damit die Zahl der Schreib- und Lesezyklen unnötig in die Höhe treibt. Viel besser geeignet ist
sein Vorgänger ext2, der bei Leseoperationen wirklich nur liest.
14.1.3 Maßnahmen zur Erhöhung der Betriebsstabilität
Soll ein Embedded System über mehrere Jahre ohne Wartung laufen und ist mit unvorhersehbaren Unterbrechungen der Stromversorgung zu rechnen, sollten Schreibzugriffe auf den
Massenspeicher ganz unterbunden werden. Fehler beim Schreiben des Dateisystems (durch
defekte Speicherzellen oder Stromausfall) könnten sonst dazu führen, dass das System nicht
mehr booten und damit ausfallen würde. Um Schreibzugriffe zu unterbinden, wird die Speicherkarte nur noch im Modus readonly betrieben. Alle Schreibzugriffe, die das Betriebssystem
durchführen will, müssen entweder komplett unterbunden werden, was sehr aufwändig ist,
oder aber in einen Teil des Random Access Memory (RAM = Arbeitsspeicher) umgeleitet
werden. Dazu müssen die Verzeichnisse, in die das Betriebssystem schreiben will, entweder
transparent (d. h. für den schreibenden Prozess nicht als andersartig erkennbar) auf eine so
genannte RAM-Disk abgebildet werden, oder aber es wird ein überlagertes RAM-Dateisystem in
die Verzeichnisse eingehängt. Ein solches Dateisystem ist z. B. Unionfs [7]. Es wird oftmals für
sogenannte LiveCDs genutzt, bei denen ein komplettes Betriebssystem von einer CD oder DVD
gebootet werden kann. Ein anderer Anwendungsbereich sind Kleinrechner mit einer Solid State
Disk SSD (z. B. der EEE-PC der Firma ASUSTeK Computer Inc. [15]). Um bei diesen Rechnern
Schreibzugriffe auf den Massenspeicher zu reduzieren, wird ebenfalls Unionfs eingesetzt.
Unionfs wird als Stackable Unification File System beschrieben. Es sorgt dafür, dass die
Inhalte verschiedener Verzeichnisse als der Inhalt eines einzigen Verzeichnisses erscheinen.
Dabei bleiben die Inhalte physikalisch getrennt. In Abbildung 14.1 wird die Funktionsweise
beschrieben.
Das schreibbare Verzeichnis “Obst” der RAM-Disk wird über das Verzeichnis “Obst” auf der
schreibgeschützten CF-Karte gelegt. (siehe Teilabbildung A). Soll nun die Datei “Apfel” gelesen
werden, wird auf die Originaldatei auf der CF-Karte zugegriffen. Versucht jetzt ein Prozess die
Datei “Apfel” zu verändern und diese Veränderungen abzuspeichern, wird die geänderte Datei
in der RAM-Disk abgelegt (siehe Teilabbildung B). Von jetzt an werden alle Lese- und Schreibzugriffe auf die Datei “Apfel” auf der RAM-Disk ausgeführt, während Lesezugriffe auf nicht
geänderte Dateien (z. B. auf die Datei “Birne”) weiterhin auf die CF-Karte erfolgen. Mit dieser Methode kann das Betriebssystem ohne irgendwelche Modifikationen sämtliche benötigten
Schreibzugriffe ausführen ohne dabei auf die Schreibzugriffe auf die CF-Karte zu schreiben.
Bei einem Stromausfall geht der Inhalt des überlagerten Dateisystems lediglich auf der RAMDisk verloren. Da hier aber für den Betrieb des Embedded Systems unwichtige Dateien des
Betriebssystems (z. B. Logfiles) angelegt wurden, stellt das keinen großen Verlust dar. Auf der
CF-Karte bleibt auf jeden Fall ein bootfähiges Betriebssystem erhalten, das ohne Probleme neu
booten kann. Will man auf dem Embedded System dauerhaft Daten ablegen, muss man zusätzlich zur schreibgeschützten Partition, die das Betriebssystem enthält, noch eine beschreibbare
158
Überlagerung
mit Unionfs
Datei, readonly
Apfel
Datei, geändert
Obst
Obst
Verzeichnis
RAM−Disk
Apfel
Apfel
Birne
Birne
Obst
Obst
A
CF−Karte, readonly
B
Abbildung 14.1: A: Das Verzeichnis “Obst” auf der RAM-Disk wird per Unionfs dem Verzeichnis
“Obst” auf der readonly CompactFlash-Card überlagert.
B: Änderungen an der Datei “Apfel” auf der CompactFlash- Karte werden als
Datei “Apfel” auf der RAM-Disk gespeichert
Datenpartition anlegen. Bei Stromausfall während eines Schreibzugriffs kann es auf dieser Partition zu Datenverlusten kommen. Davon ist aber nie das Betriebssystem selbst betroffen, so dass
das System trotz des möglichen Datenverlusts immer bootfähig bleibt.
14.2 Datensicherheit
Das Anlegen von Sicherheitskopien (Backups) ist eine gute Möglichkeit, um Datenverlusten
durch den Ausfall eines Massenspeichers vorzubeugen. Dazu gibt es verschiedene Möglichkeiten:
Lokale Kopien und Früherkennung von Festplattenschäden
Lokale Kopien von Daten auf dem Embedded System können mit so genannten RAIDs erzeugt
werden. Ein RAID (Redundant Array of Independent (oder Inexpensive) Disks) ist ein System,
bei dem die zu speichernden Daten auf mehrere Festplatten verteilt werden. Dabei ist es je nach
RAID-Level (der Art der RAID-Nutzung) möglich, die Daten einer ausgefallenen Festplatte aus
den anderen am RAID-Verbund beteiligten Festplatten zu rekonstruieren.
14.3. STABILISIERUNG DER SPANNUNGSVERSORGUNG
159
Wenn kein RAID zur Verfügung steht, sollten zumindest Mechanismen zur Früherkennung von
Festplattenschäden genutzt werden. Moderne Festplatten verfügen dazu über Self-Monitoring,
Analysis and Reporting Technology (SMART). Festplatten mit SMART überprüfen sich selbst
auf Anzeichen eines drohenden Ausfalls und geben bei Fehlern entsprechende Fehlermeldungen
aus. Mit Auswertungs-Software (z. B. smartmontools [199] unter Linux) lassen sich frühzeitig
Festplattendefekte ausmachen und entsprechende Fehlermeldungen per Email absetzen, so dass
ein Austausch der Platte möglich ist, bevor Datenverluste entstehen.
Backup über das Netzwerk
Sicherheitskopien auf einer lokalen Festplatte sind besser als gar keine Sicherheitskopien. Eine
wirkliche Datensicherheit ist mit ihnen allerdings nicht zu erreichen, da z. B. durch Blitzschäden sämtliche Festplatten eines Rechners auf einmal zerstört werden können. Sicherheitskopien
sollten deshalb an einem anderen Ort als dem des Rechners aufbewahrt werden. Bei vernetzten
Embedded Systems bietet sich deshalb die Nutzung der Netzwerk-Konnektivität an. Dabei ist es
bedeutend einfacher, Daten von den Netzknoten auf einem zentralen Rechner einzusammeln und
dort ein zentrales Backup für alle Knoten eines verteilten Systems durchzuführen, als Backups
für jedes einzelne Embedded System eines Netzwerks zu implementieren.
14.3 Stabilisierung der Spannungsversorgung
Embedded Systems müssen oftmals unter Bedingungen arbeiten, bei denen eine stabile Spannungsversorgung durch das Stromnetz nicht gewährleistet werden kann. Beschädigungen durch
Spannungsspitzen können mit Überspannungsfiltern zwar vermieden werden, gegen ungewollte
Resets der Embedded Systems durch Spannungsunterbrechungen (black outs) und gegen
Systemabstürze durch Spannungseinbrüche (brown outs) helfen diese Filter allerdings nicht.
Um Resets und Abstürze zu vermeiden, sind entweder ausreichend große Pufferkondensatoren
in den Netzteilen oder unterbrechungsfreie Stromversorgungen (USVs) notwendig. USVs sind
Geräte, die fortwährend mit hoher zeitlicher Auflösung die Netzspannung messen. Bei Einbruch
des Spannungsniveaus stützen sie die Spannung mittels eines eingebauten Akkus über einen
Wechselrichter. Manche USVs können bei einem kompletten Stromausfall die Stromversorgung
eines Embedded Systems mehrere Tage lang bewerkstelligen. Die meisten USVs verfügen über
eine Kommunikationsschnittstelle, über die das Embedded System den Betriebszustand abgefragen kann. Wenn z. B. der Akku einer USV fast leer ist, kann das Embedded System diesen
Zustand frühzeitig erkennen und kontrolliert herunterfahren. Dadurch können Datenverluste
vermieden werden.
Manche Prozessoren für Embedded Systems verfügen über eine brown out detection. Sie sorgt
dafür, dass bei einem Spannungseinbruch ein definierter Reset des Systems durchgeführt wird.
160
14.4 Watchdog
Ein Watchdog (engl, Wachhund) ist ein Mechanismus, der dazu dient, Systemkomponenten oder
Prozesse zu beobachten und im Falle eines Ausfalls entsprechende Maßnahmen einzuleiten.
Watchdogs gibt es als Hardware- oder als Softwarelösung.
Hardware-Watchdogs sollen sicherstellen, dass das Betriebssystem eines Rechners ständig
läuft. Ein Hardware-Watchdog arbeitet meist mit einem Zähler, dessen Stand in regelmäßigen
Zeitabständen automatisch dekrementiert wird. Erreicht der Zählerstand den Wert 0, führt
der Watchdog einen Reset des Gesamtsystems durch. Läuft das Betriebssystem des Rechners
korrekt, wird durch eine Software der Zählerstand des Hardware-Watchdogs regelmäßig
inkrementiert oder auf einen bestimmten Wert gesetzt. Dadurch wird ein Reset des Systems
durch den Hardware-Watchdog unterbunden.
Software-Watchdogs sind Programme, die die Arbeit anderer Programme überwachen und
kontrollieren, ob diese korrekt laufen und Aufgaben innerhalb eines bestimmten Zeitfensters
abarbeiten. Sie dienen dazu, essentielle Prozesse zu überwachen. Außerdem können sie dazu
genutzt werden, kritische Systemzustände, z. B. durch unsauber arbeitende Programme (memory
leak) verursachten Speichermangel, frühzeitig zu erkennen und Gegenmaßnahmen einzuleiten.
Software-Watchdogs können ihrerseits wieder durch Hardware-Watchdogs überwacht werden,
so dass ein mehrstufiges Überwachungssystem entsteht.
Beim Betriebssystem Linux kann der init-Prozess, der nach dem Booten des Systems als erster Prozess gestartet wird, als Software-Watchdog genutzt werden. Programme, die mit der sogenannten respawn-Option in die Datei /etc/inittab eingetragen sind, werden durch init sofort
nach ihrem Absterben erneut gestartet. Der erste Start erfolgt automatisch beim Systemstart. In
Abb. 14.2 ist ein Beispiel für zwei Eintragungen in /etc/inittab dargestellt. Zwei Prozesse werden
hier von init überwacht. ppp0 und ppp1 sind frei gewählte Bezeichnungen für diese Prozesse. Die
Zahl 2 steht jeweils für das Runlevel, in dem die Programme aktiv sein sollen. Eintragungen für
mehrere Runlevel sind möglich. Viele Linux-Systeme laufen im Normalbetrieb im Runlevel 2.
Die Startbefehle für die Prozesse sind /root/soekris/pppstart und /root/soekris/pppsentry .
ppp0:2:respawn:/root/soekris/pppstart
ppp1:2:respawn:/root/soekris/pppsentry
Abbildung 14.2: Eintragung zweier Programme zum Aufbau einer Einwahl-Internetverbindung
als respawn-Prozesse in /etc/inittab
Kapitel 15
Evaluation
In den beiden folgenden Abschnitten soll beschrieben werden, wie die in den vorangehenden
Kapiteln dieser Arbeit erläuterten Konzepte und technischen Lösungsansätze in Form von zwei
Monitoringprojekten für Wärmepumpen und einem Regelungssystem für Energieströme in einem
Niederspannungsnetz umgesetzt wurden. Diese Systeme arbeiten zum Zeitpunkt der Fertigstellung dieser Arbeit schon über ein Jahr und haben ihre Praxistauglichkeit bewiesen. An ihnen
lässt sich gut ablesen, dass es keine technischen Patentrezepte gibt, die sich für alle Einsatzfälle
sinnvoll anwenden lassen. Je nach Randbedingungen müssen immer wieder spezielle technische Lösungen gefunden werden. Die Projekte zeigen aber auch, dass Embedded Systems und
Internet-Technologie als flexible Basis für die Regelung und das Monitoring von dezentralen
Energiesystemen geeignet sind.
15.1 Ein verteiltes Monitoringsystem zur Vermessung von
Wärmepumpen
15.1.1 Projekte Wärmepumpen im Gebäudebestand und WärmepumpenEffizienz
Im Rahmen der Projekte “Wärmepumpen im Gebäudebestand” [231] und “WärmepumpenEffizienz” [230] des Fraunhofer Instituts für Solare Energiesysteme ISE [134] (siehe auch
[38][155]) wurde ein Monitoring von Wärmepumpensystemen in Einfamilienhäusern durchgeführt. Dazu wurde ein verteiltes Montoringsystem mit insgesamt ca. 150 Messstellen in
ganz Deutschland auf der Basis von vernetzten Embedded Systems konzipiert und über einen
Zeitraum von mehr als zwei Jahren erstellt und betrieben. Die geografische Verteilung der
Systeme ist in Abb. 15.1 dargestellt.
Die in den beiden Projekten erhobenen Daten dienten zur Ermittlung der Energieeffizienz von
Wärmepumpensystemen der an den Projekten beteiligten Hersteller. Die Messdaten wurden
dazu in grafischer Form übersichtlich aufbereitet und den Projektpartnern auf Projekt-Webseiten
161
162
KAPITEL 15. EVALUATION
Abbildung 15.1: Geografische Verteilung der Messsysteme aus den Projekten Wärmepumpen im
Gebäudebestand (links) und Wärmepumpen-Effizienz (rechts) in Deutschland
(Quelle: Screenshots der Projekt-Webseiten [231][230] )
zugänglich gemacht. Ein Beispiel für eine grafische Aufbereitung der Messwerte eines Jahres
ist in der Abbildung 15.3 dargestellt.
Einige Messsysteme wurden per DSL an das Internet angebunden, um das Reglerverhalten der
Wärmepumpen in nahezu Echtzeit visualisieren zu können. Dazu wurde die im Kapitel 9 beschriebene Visualisierung mit Java-Applets im Webbrowser genutzt. Ein Screenshot der JavaVisualisierung eines Wärmepumpensystems ist in Abb. 9.1 auf Seite 107 abgebildet.
15.1.2 Kommunikationsinfrastruktur
Die Messdaten der Messsysteme im Feld sollten einmal täglich abgerufen werden. Aufgrund
der hohen Kosten und des großen Einrichtungsaufwandes schied für die Kommunikation die
Nutzung von DSL, ISDN und Telefonmodems für die meisten Messsysteme aus. Stattdessen
wurde die Nutzung von Mobilfunktechnologie für die Datenübertragung beschlossen. Die Wahl
fiel auf das Produkt Corporate Data Access (CDA) der Firma Vodafone [219]. Vodafone konnte
zum Zeitpunkt des Projektstarts als einziger Anbieter die Möglichkeit eines Verbindungsaufbaus
von einem Abfragerechner zu den mobilen Stationen mittels eines per Virtual Private Network
(VPN) angebundenen privaten Subnetzes offerieren. Die Infrastruktur des Abrufprozesses ist in
Abbildung 15.2 dargestellt. Jedes Messsystem baut selbständig eine GPRS-Verbindung (siehe
15.1. VERTEILTES MONITORINGSYSTEM
163
Abschnitt 7.3.1) zum Mobilfunkprovider auf. Beim Verbindungsaufbau werden den Systemen
private IP-Adressen (siehe Abschnitt 7.4.1 und Tabelle 7.3) zugeteilt. Die IPs aller Messsysteme
stammen aus dem Class-C-Subnetz 192.168 36.0/24. Der Rechner, der täglich die Messdaten
von den Messsystemen abholt, wird per Virtual Private Network VPN (siehe Abschnitt 8.1)
an das Subnetz der Messsysteme angebunden. Er kann dadurch per Secure Shell (SSH) (siehe
Abschnitt 7.5.5) direkt auf die Messsysteme zugreifen. Durch diese Infrastruktur wurden
sämtliche Probleme umgangen, die bei der sonst üblichen Network Address Translation (NAT)
(siehe Abschnitt 7.4.1) entstehen.
Mittlerweile bieten auch andere Mobilfunk-Netzbetreiber VPN-Lösungen an. Die Einrichtung
einer solchen Kommunikationslösung ist recht aufwändig und teuer. Sie lohnt sich nur, wenn
eine große Anzahl von Messstellen benötigt wird. Auch GSM-Zugänge mit festen IP-Adressen
sind inzwischen verfügbar. Ein Anbieter ist z. B. die I.T.E.N.O.S GmbH [135], die unter dem
Markennamen White [222] derartige Zugänge vertreibt.
164
Daten−Abrufrechner
VPN−Router
Abrufseite
VPN−Router
Mobilfunk−Anbieter
Netzwerk Mobilfunk−Anbieter
virtuelles Subnetz
Messstellen
VPN
Abbildung 15.2: Infrastruktur des Messdatenabrufs per GSM für im Feld verteilte Messsysteme. Der Abrufrechner wird per Virtual Private Network an das Netzwerk des
Mobilfunkanbieters angebunden.
Abbildung 15.3: Jahresauswertung des Betriebs einer Fluid-Wärmepumpe
165
166
15.1.3 Hardware
Embedded Systems
Die Monitoringprojekte waren für einen Betrieb von insgesamt ca. 150 Messstellen geplant, so
dass die Entwicklung von ressourcenschonender Software sinnvoll war. Diese Software ermöglicht den Einsatz von entsprechend leistungsschwächeren, dafür aber deutlich kostengünstigeren
Embedded Systems. Die Wahl fiel auf das Modell net4501 der Firma Soekris Engineering Inc.
[200]. Die Komponenten dieser Embedded Systems werden nachfolgend beschrieben:
Prozessor: Das Embedded System enthält einen Prozessor vom Typ Elan SC520 der Firma
Advanced Micro Devices AMD [8]. Diese CPU arbeitet mit 133 MHz und hat einen x86kompatiblen Befehlssatz. Die Leistungsaufnahme unter Volllast liegt bei ca. 3 W. Die Rechenleistung entspricht der eines 486er-PC-Prozessors mit 133 MHz. Systeme mit gleicher Rechenleistung, aber Prozessoren anderer Architektur (z. B. ARM9) benötigen deutlich weniger elektrische Leistung, sind dafür aber auch sehr viel teurer (siehe dazu auch
Abschnitt 3.1). Durch die x86-Architektur entfällt bei der Softwareentwicklung auch eine
Crosscompilation für das Zielsystem.
Arbeitsspeicher: Der 64 MB-Arbeitsspeicher (SDRAM) des Rechners ist ausreichend für ein
angepasstes Linux-Betriebssystem, die Mess-Software, die Kommunikationssoftware und
eine 15 MB RAM-Disk für das temporäre Ablegen von Messdaten.
Typische Linux-Installationen auf PCs benutzen eine Swap-Partition auf der Festplatte.
Ist der Bedarf an Arbeitsspeicher größer als der vorhandene Arbeitsspeicher, werden Teile
des Arbeitsspeicherinhalts in die Swap-Partition der Festplatte ausgelagert.
Bei der Linux-Installation für das Messsystem wurde auf eine Swap-Partition verzichtet,
da der verwendete Massenspeicher (eine CompactFlash-Karte) nicht für den Betrieb als
Swap-Medium geeignet ist.
Die verwendete Software ist so ausgelegt, dass mit einem Überlaufen des Arbeitsspeichers
nicht zu rechnen ist. Sollte dieser Zustand dennoch eintreten, sorgt ein Watchdog für einen
Reset des Systems. Das führt zwar zu Verlusten bei den Messdaten, sorgt aber dafür, dass
das System wieder in einen definierten Betriebszustand überführt wird. Ohne Reset könnte
das Verhalten des Systems nicht vorhergesagt werden. Im ungünstigsten Fall könnte der
Rechner sogar komplett stehen bleiben.
Massenspeicher: Als Massenspeicher kommen CompactFlash Type I-Karten der Firma SanDisk [190] mit einer Kapazität von 512 MB zum Einsatz. Ihre Speicherkapazität ist ausreichend groß für das Betriebssystem und die Messdaten von mehreren Monaten Messbetrieb. Festplatten sind für diesen Anwendungsfall nicht geeignet, da nur Microdrives in der
Bauform einer CompactFlash Type II-Karte in das Gehäuse des net4501 integriert werden
können. Microdrives sind jedoch nicht für den Dauerbetrieb ausgelegt.
167
Schnittstellen: Das Embedded System net4501 verfügt über zwei serielle Schnittstellen vom
Typ RS232, die für den Anschluss von Messtechnik und Kommunikationsgeräten genutzt
werden. Die erste Schnittstelle ist direkt an der Geräterückseite über einen 9-poligen SUBD-Stecker zugänglich (siehe Abb. 15.5, Console). Die zweite RS232-Schnittstelle ist nur
als Pfostenleiste im Inneren des Gehäuses zugänglich (siehe Abb. 15.4, COM2). Sie wird
über ein Flachbandkabel nach außen geführt (siehe Abb. 15.5, externer Stecker). Im Messsystem werden beide seriellen Schnittstellen genutzt. An die erste Schnittstelle ist ein
M-Bus-Master angeschlossen, welcher zum Auslesen von Wärmemengenzählern benötigt wird. Die zweite Schnittstelle ist mit einem GSM-Modem verbunden, mit welchem die
Kommunikation zum Abrufrechner bewerkstelligt wird.
Netzwerk: Das Gerät verfügt über drei 10/100 Mbit Ethernet-Ports. Für Installationszwecke
kann der Rechner von der ersten Netzwerkschnittstelle über das Netzwerk booten.
Watchdog: Der Prozessor Elan SC520 verfügt über einen integrierten Hardware-Watchdog (siehe Abschnitt 14.4). Dieser kann mit Hilfe eines Linux-Kerneltreibers bei kritischen Systemzuständen den Rechner zurücksetzen.
Temperaturbereich: Der net4501 ist für einen Temperaturbereich von 0-60 ◦ C spezifiziert.
COM1
Netzwerkschnittstellen
COM2
Ethernet−Transceiver
PCI−Ethernet−Controller
COM2
CPU/Chipsatz
PCI−Slot
RAM
CF−Slot
BIOS
Abbildung 15.4: Innenleben des net4501 der Firma Soekris Engineering Inc. [200]
168
COM2
Netzwerkschnittstellen
COM1
Spannungsversorgung
Abbildung 15.5: Rückseite des net4501 der Firma Soekris Engineering Inc. [200] mit Anschlüssen für Netzwerk (eth0, eth1, eth2), seriellen Schnittstellen (Console und externer Stecker) und Spannungsversorgung (Power)
Anschluss
Eth0
Eth1
Eth2
Console
silberner externer Stecker
Power
Typ
Netzwerkinterface (IP: 10.0.0.100)
Netzwerkinterface (IP: 192.168.127.1)
Netzwerkinterface
serielle Schnittstelle
serielle Schnittstelle
Stromversorgungsbuchse
Verbindung zu
Service-Laptop
COM-Server
M-Bus-Master
GSM-Modem
Netzeil (12V)
Tabelle 15.1: Anschlüsse des net4501 der Firma Soekris Engineering Inc [200] und deren Nutzung
GSM-Modem
Zum Einsatz kommt ein MC35i Terminal der Firma Siemens [196]. Das Gerät wurde deshalb
ausgewählt, weil es eine sehr großen Stabilität im Betrieb aufweist. Die mit diesem Modem
erzielbaren Übertragungsraten sind vergleichsweise gering, da es nur die Multislot-Klasse 4
(siehe Abschnitt 7.2) beherrscht und deshalb für den Datenupload keine Kanalbündelung nutzen
kann.
169
Im Gegensatz zu GSM-Routern, die selbständig GSM-Datenverbindungen aufbauen und aufrecht erhalten können, verfügt das MC35i Terminal nicht über diese Fähigkeiten. Deshalb muss
das Embedded System sämtliche Aktionen im Zusammenhang mit dem Verbindungsaufbau und
dem Aufrechterhalten der Verbindung durchführen. Durch die Nutzung des “dummen” Modems
ergibt sich dafür aber ein Kostenvorteil von ca. 500 Euro pro Messsystem gegenüber der Nutzung
eines GSM-Routers.
COM-Server
Das gewählte Embedded System verfügt nur über zwei serielle Schnittstellen. Für die zwei unterschiedlichen Bus-Systeme der Messtechnik (OneWire-Bus [151] und M-Bus [154]) sowie das
GSM-Modem werden jedoch drei serielle Schnittstellen benötigt. Die Hauptplatine des net4501
verfügt zwar über einen PCI-Steckplatz, in den eine kostengünstige Schnittstellenkarte passen
würde. Das Gehäuse hat jedoch keine Aussparung für die Montage einer solchen Erweiterung.
Deshalb kommt ein sogenannter COM-Server vom Typ NPort DE-211 der Firma Moxa Technologies Inc. [161] zum Einsatz. Dieses Gerät stellt über eine 10 Mbit Netzwerkverbindung per
Socket eine weitere serielle Schnittstelle zur Verfügung. Der Netzwerk-Port des COM-Servers
wird dabei per Netzwerk-Cross-Kabel direkt mit einem der Ethernet-Ports des net4501 verbunden.
Auswahl der Messtechnik
Für das Monitoring der Wärempumpen müssen folgende Messgrößen und abgeleitete Größen
erfasst werden.
• Vorlauf-, Rücklauf- und Differenztemperaturen für verschiedene Wasser- und Solekreise
• Wärmemengen
• Wärmeleistungen
• Lufttemperaturen
• Luftfeuchten
• elektrische Energie
Für die Messung der Wärmemengen, Wärmeleistungen und Temperaturen werden Wärmemengenzähler eingesetzt, da diese Geräte auch bei Stromausfall weiterarbeiten und keine Messdaten
verlieren. Diese Geräte gibt es in verschiedenen Ausführungen mit unterschiedlichen Kommunikationsschnittstellen (siehe Tabelle 15.2). Da mehrere Wärmemengenzähler über eine serielle
Schnittstelle des Embedded Systems ausgelesen werden sollen, kamen nur busfähige Kommunikationstechniken in Frage. Die Impulsausgänge der Wärmemengenzähler scheiden neben der
mangelnden Busfähigkeit auch aus, weil über sie nur Leistung und Energie, aber nicht die ebenfalls benötigten Temperaturen ausgelesen werden können. Für die Messung der Wärmemengen von Sole-Kreisen werden Wärmemengenzähler benötigt, die an die im Vergleich zu Wasser
170
abweichende Wärmekapazität der Sole angepasst sind. Derartige Zähler sind nur mit M-BusSchnittstelle oder Impulsausgang verfügbar, so dass M-Bus die einzige für den Anwendungsfall
geeignete Busvariante ist.
busfähig alle Messgrößen
auslesbar
RS232
nein
ja
RS485
ja
ja
M-Bus
ja
ja
Impulsausgang nein
nein
verfügbar für
Solekreise
nein
nein
ja
ja
Tabelle 15.2: Kommunikationsschnittstellen für Wärmemengenzähler
Die anderen Messgrößen könnten auch per M-Bus erfasst werden. Stromzähler und AnalogDigital-Wandler für die Erfassung von Temperaturen und Luftfeuchten sind erhältlich. Die Geräte sind jedoch so teuer, dass die Technik in den beiden Monitoringprojekten nicht zum Einsatz
kommen konnte und eine kostengünstigere Lösung gefunden werden musste. Eine sehr preisgünstige, aber technisch anspruchsvolle und nur unter sehr eng definierten Randbedingungen
einsetzbare Technik für die Anbindung von Sensoren, ist der OneWire-Bus. Da aufgrund des
Kostendrucks keine andere busfähige Sensorik finanzierbar war, wurde diese Bustechnologie
dennoch eingesetzt. In den beiden folgenden Abschnitten wird die eingesetzte Messtechnik beschrieben.
M-Bus-Messtechnik
Der M-Bus (= Metering Bus, siehe [154]) ist ein in den europäischen Normen EN13757-2 und
EN13757-3 beschriebenes Feldbus-System zur Zählerfernauslesung. In den Messprojekten werden drei verschiedene Typen von M-Bus-Wärmemengenzählern mit integrierten Rechnerwerken
der Firma ELSTER Messtechnik GmbH [71] genutzt. Zum Einsatz kommen die Modelle F4,
F22 und F96.
M-Bus-Geräte lassen sich im Prinzip durch ein Scannen des Busses erkennen. Da die M-BusWärmemengenzähler aber zum Zeitpunkt der Parametrierung des Messsystems nicht zur Verfügung stehen, findet die Konfiguration per Skript und Konfigurationsdatei statt. In Abb. 15.6
ist eine Konfigurationsdatei für einen M-Bus mit 4 Wärmemengenzählern abgebildet. Die erste
Spalte enthält die IDs, über die sich die Wärmemengenzähler über den Bus ansprechen lassen.
Der jeweilige Typ des Wärmemengenzählers ist in der zweiten Spalte angegeben, so dass die
Mess-Software typenspezifische Ausleseroutinen anwenden kann. Das Beispiel stellt die Konfiguration von zwei Wärmemengenzählern vom Typ F96 mit den IDs 1 und 5, einem Zähler vom
Typ F4 mit der ID 2 und einem Zähler vom Typ F22 mit der ID 4 dar.
1
2
4
5
171
F96
F4
F22
F96
Abbildung 15.6: Konfigurationsdatei zur Erstellung einer Sensorliste für ein M-Bus-basiertes
Messsystem mit mehreren Wärmemengenzählern
Messtechnik mit OneWire-Bus
Der OneWire-Bus wurde von der Firma Dallas Semiconductors/Maxim [151] entwickelt. Für
dieses Bussystem ist eine große Zahl von sehr preisgünstigen Sensorik- und Aktorik-Bausteinen
verfügbar. Der Bus besteht aus nur zwei Adern und ist deshalb recht störanfällig. Um die
Störanfälligkeit zu reduzieren, wird die Busverkabelung des Messsystems, wie von Dallas
Semiconductors/Maxim in [152] vorgeschlagen, mit Cat5-Netzwerkkabeln ausgeführt.
Der OneWire-Bus wird mit Hilfe eines Busmasters betrieben. Dieser wird mit Hilfe von zwei
Steckadaptern an die RS232-Schnittstelle des COM-Server angeschlossen Das CAT5-Kabel des
OneWire-Bus wird mit einem RJ45-Stecker an den Busmaster gesteckt.
In beiden Wärmepumpen-Messprojekten werden OneWire-Bausteine zur Messung von Temperaturen, Luftfeuchten, Stromverbräuchen und elektrischen Leistungen genutzt. Für die
Temperaturmessungen und die Feuchtemessungen kommen montagefertige Sensoren von
iButtonLink [109] zum Einsatz. Diese enthalten jeweils einen DS2438-Baustein der Firma
Dallas Semiconductors/Maxim, der Temperaturen messen kann und zusätzlich über einen
Analog-Digital-Wandler verfügt. Der AD-Wandler wird für die Feuchtemessung mit einem
Feuchtesensor HIH-3610 [106] der Firma Honeywell [105] gekoppelt.
Um die elektrischen Energiemengen für den Wärmepumpenbetrieb möglichst kostengünstig zu
erfassen, werden Zähler mit S0-Impulsausgang verwendet. Die Zählung der Impulse erfolgt mit
OneWire-Counterbausteinen vom Typ DS2423. Dazu wurde am Fraunhofer ISE eine Basisplatine
mit vier Counterbausteinen und der dazugehörigen Spannungsversorgung entwickelt.
172
Abbildung 15.7: Schaltkasten mit Embedded System, GSM-Modem und Messtechnik für ein
Wärmepumpen-Monitoring-Projekt
Abbildung 15.8: Schemazeichnung des im Bild 15.7 abgebildeten Schaltkastens
173
174
15.1.4 Betriebssystemanpassung
Bei der Wahl des Betriebssystems gab es zahlreiche Randbedingungen, die beachtet werden
mussten:
Speicherplatz:
Auf der CompactFlash-Karte (CF-Karte) des Embedded Systems stehen nur
250 MB für das Betriebssystem zur Verfügung.
Softwareupdates:
Im laufenden Betrieb muss die Neuinstallation oder das Aktualisieren
von Software auf dem System möglich sein.
Kostenfaktor:
Das Betriebssystem darf aufgrund des Kostendrucks im
Projekt keine zusätzlichen Kosten verursachen.
Support:
Das Betriebssystem soll möglichst weit verbreitet sein, um den Support
einer breiten Usercommunity nutzen zu können.
Fernadministration:
Die komplette Administration des Systems muss über eine langsame
GPRS-Verbindung möglich sein. Betriebssysteme mit aufwändiger
grafischer Oberfläche können deshalb nicht genutzt werden.
Treiberunterstützung:
Für alle essentiellen Hardwarekomponenten des Rechners
müssen Treiber vorhanden sein.
Ausgewählt wurde die weit verbreitete Linux-Distribution Debian [50] in der Version 3.1 Sarge. Debian ist ein Community-Projekt und wird von einer sehr großen Gemeinde Freiwilliger
entwickelt. Die Nutzung des Systems ist kostenlos. Die Debian-eigene Paketverwaltung ist sehr
gut geeignet, im laufenden Betrieb Software zu installieren und Updates durchzuführen. Eigene
Installationspakete für selbst entwickelte Software können ohne großen Aufwand erstellt und in
die Debian-Paketverwaltung integriert werden. Alle zur Administration notwendigen Tools gibt
es in Versionen für die Kommandozeile.
Debian ist die umfangreichste aller bekannten Linux-Distributionen, so dass für die meisten Anwendungen schon fertige Installationspakete zur Verfügung stehen.
Betriebssystem-Kernel
Der zentrale Bestandteil jeder Linux-Installation ist der Betriebssystem-Kernel. Im hier beschriebenen Messsystem kommt ein Linux-Kernel der Version 2.4.27 zum Einsatz, der auf den
Kernel-Sourcen des 2.4.27-3-Kernels der Debian-Distribution basiert. Für das Embedded System net4501 wurden einige Anpassungen der Kernelkonfiguration durchgeführt und der Kernel
aus den Quellen neu kompiliert. Die Version 2.4.27 ist eine zum Zeitpunkt der Erstellung dieser Arbeit schon relativ alte Kernelversion. Sie bietet jedoch den Vorteil sehr großer Stabilität,
geringen Ressourcenverbrauchs und einer guten Verfügbarkeit von Treibern für Zusatzhardware
(Watchdog, Comserver, u. a.).
175
Watchdog-Treiber
Der Linux-Kernel 2.4.27 enthält einen Treiber für den Hardware-Watchdog des im net4501
verbauten Chipsatzes Elan SC520. Bei Tests mit Watchdog-Software, die auf den Kernel-Treiber
zugreift, wurde jedoch festgestellt, dass der Treiber nicht korrekt funktionierte und deshalb bei
einem Systemstillstand auch kein Hardware-Reset durch den Watchdog ausgelöst wurde. Nach
längeren Recherchen im Internet fand sich ein Kernelpatch, der dieses Problem schließlich löste.
Aufgrund des Kostendrucks in den Monitoringprojekten konnten keine gepufferten Netzteile
mit USV-Funktionalität (siehe dazu Abschnitt 14.1) und keine Netzfilter zum Einsatz kommen.
Systemabstürze der Embedded Systems aufgrund von Spannungseinbrüchen müssen daher
durch den Watchdog behoben werden. Er setzt die Systeme in einer solchen Situation zuverlässig
zurück, so dass sie nach kurzer Zeit wieder den Messprozess aufnehmen können. Nicht nur bei
einem kompletten Systemstillstand, sondern auch bei anderen kritischen Systemzuständen, führt
der Watchdog einen Reset des Systems durch.
Läuft der Hauptspeicher des Systems über, kann es in einen Zustand geraten, in dem sein Verhalten nicht mehr vorhersagbar ist. In diesem Fall wird das System durch eine Watchdog-Software
ebenfalls zurückgesetzt.
Für jegliche Kommunikation des Systems über die GPRS-Schnittstelle wird eine Secure Shell
(SSH) (siehe Abschnitt 7.5.5) genutzt. Fällt der SSH-Server aus, führt die Watchdog-Software
gleichfalls einen Reset durch.
Partitionen und Dateisysteme
Die CompactFlash-Karte des Systems wurde in zwei gleich große Partitionen unterteilt. Die
erste Partition enthält das Betriebssystem und wird teilweise mit einem Unionfs (siehe Abschnitt
14.1.2 und Unterüberschrift Massenspeicher-Schutz durch Unionfs in diesem Abschnitt) überlagert, um die Zahl der Schreib- und Lesezyklen auf der CF-Karte zu verringern. Zu diesem
Zweck wurde eine spezielle Version des Unionfs in den Kernel integriert.
Die zweite Partition der CF-Karte enthält die Messsoftware und speichert die während des Messprozesses anfallenden Daten. Die Messdaten werden zunächst in eine RAM-Disk gespeichert,
um auch hier die Schreib- und Lesezugriffe auf die CF-Karte gering zu halten. Einmal täglich
wird der Messdatensatz des vorhergehenden Tages auf die CF-Karte übertragen. Die Daten
werden dabei mit bzip komprimiert, um Speicherplatz zu sparen und das Datentransfervolumen
beim Datenabruf gering zu halten.
Für beide Partitionen wird das ext2-Dateisystem verwendet. Dieses Dateisystem ist der
Vorgänger des heute bei Linuxinstallationen auf Standard-PCs oft verwendeten JournalingDateisystems ext3.
Journaling-Dateisysteme bieten eine höhere Datensicherheit, haben aber den Nachteil, dass sie
im Betrieb deutlich mehr Schreib- und Lesezugriffe durchführen müssen als Dateisysteme ohne
176
Journaling-Funktion. Dieses Verhalten ist bei der Nutzung von Festplatten kein Problem. Da
CF-Karten jedoch nur eine sehr begrenzte Anzahl von Schreib-/Lesezyklen verkraften (siehe
Abschnitt 14.1.2), würde sich die Lebensdauer der Karten durch die Nutzung von ext3 rapide
verkürzen.
Linux-Kernel-Treiber für den COM-Server
COM-Server können auf verschiedene Art genutzt werden. Eine Möglichkeit ist der direkte
Zugriff vom Anwendungsprogramm auf den COM-Server über das Netzwerk. Das bedeutet
aber, dass für jedes Anwendungsprogramm die Netzwerkfunktionalität neu implementiert
werden muss. Geschickter ist die zweite Nutzungsvariante, bei der ein Betriebssystemtreiber
dafür sorgt, dass der COM-Server gegenüber Anwendungsprogrammen transparent als serielle
Schnittstelle des Rechners dargestellt wird. Jede Software, die serielle Standardschnittstellen
nutzen kann, funktioniert dann auch mit dem COM-Server. Ein weiterer Vorteil dieser Variante
ist die bessere Eignung für Anwendungen mit kritischem Timing. Ein Betriebssystemtreiber bekommt dabei eine deutlich höhere Priorität als ein Anwendungsprogramm, wodurch schnellere
Reaktionszeiten erzielt werden.
Die Firma Moxa Technologies Inc. [161] stellt für ihre COM-Server einen Linux-Treiber als
Sourcecode zur Verfügung. Dieser wurde für den verwendeten Linux-Kernel kompiliert und in
das System integriert.
Massenspeicher-Schutz durch Unionfs
Beim Betrieb von Embedded Systems sollte eine stabile Spannungsversorgung gewährleistet
sein. Kann diese aufgrund technischer oder finanzieller Randbedingungen nicht realisiert
werden, empfiehlt sich die Nutzung eines Read Only Memory (ROM). Beim Systemstart wird
der Inhalt des ROM in den Arbeitsspeicher entpackt und ausgeführt. Ein solches Konstrukt
hat den Nachteil, dass im laufenden Betrieb keine dauerhaften Aktualisierungen des Systems
durchgeführt werden können. Bei den hier vorgestellten Wärmepumpen-Monitoringprojekten
sind Aktualisierungen der Systeme im laufenden Betrieb jedoch unumgänglich. Sie können
durch die Nutzung einer anderen Technologie ermöglicht werden. Es handelt sich um das im
Abschnitt 14.1.3 beschriebene Unionfs, das auf ein ext2-Dateisystem aufgesetzt wird.
Da beim ext2-Dateisystem nur die Unterbrechung von Schreiboperationen zu Dateisystemproblemen führt, wurde versucht, möglichst viele Schreiboperationen im Arbeitsspeicher durchzuführen. Viele Systemprozesse der Messrechner führen Schreiboperationen in den Verzeichnissen /var und /tmp auf dem Massenspeicher durch. Diese Schreibzugriffe müssen unbedingt
abgefangen werden. Außerdem sollen die minütlichen Schreiboperationen der Messprozesse
im Arbeitsspeicher stattfinden, um ein "Kaputtschreiben" des Massenspeichers (siehe Abschnitt
14.1.2) zu vermeiden. Diese Ziele sind zu erreichen, indem die entsprechenden Verzeichnisse mit
einem Unionfs überlagert werden. Dazu wird während des Bootprozesses des Systems frühzeitig
das in Abb 15.9 abgebildete Skript ausgeführt.
1:
2:
3:
4:
5:
177
#!/bin/bash
mount -t tmpfs tmpfs -o size=15M /ramfs
mount -t unionfs -o dirs=/ramfs:/var-tmp=ro none /var
rm -rf /tmp
ln -s /var /tmp
Abbildung 15.9: Shellskript zum Anlegen einer RAM-Disk und zum Überlagern von /var mit der
RAM-Disk per Unionfs
Die Ausführung des Skripts gliedert sich in folgende Teilschritte:
Zeile 1:
Der Befehlsinterpreter bash wird ausgeführt.
Zeile 2:
Es wird eine 15 MB große RAM-Disk, sprich ein “Laufwerk” im Arbeitsspeicher des Rechners, erzeugt und am Mountpoint /ramfs des Dateisystems eingehängt.
Alle Dateien, die bei einem Standard-Linux-System im Verzeichnis /var liegen, befinden sich beim Linux für das Messsystem im Verzeichnis /var-tmp.
Dieses Verzeichnis wird mit /ramfs überlagert, so dass alle Schreiboperationen in /ramfs und damit im Arbeitsspeicher durchgeführt werden. Das überlagerte Verzeichnis /var-tmp wird nach /var gemountet. Damit können wieder
alle Dienste auf das Standardverzeichnis /var zugreifen. Bei einem Systemabsturz bleibt der Inhalt von /var-tmp erhalten und nur die Änderungen, die in
/ramfs durchgeführt wurden, gehen verloren.
Zeile 3:
Zeilen 4 und 5:
Um für das Verzeichnis /tmp nicht eine zweite RAM-Disk anlegen zu müssen,
wird das Verzeichnis /var und damit auch /ramfs für die temporären Dateien
“missbraucht”. Dazu wird das alte Verzeichnis /tmp gelöscht und ein Link von
/tmp nach /var angelegt. Alle temporären Dateien der Messprozesse werden
in /tmp und durch den Link damit in /var geschrieben. Da /var durch /ramfs
überlagert wird, werden die files in den Arbeitsspeicher geschrieben.
15.1.5 Softwareinstallation
Die Installation der kompletten Software erfolgt mit Hilfe der im Kapitel 13 beschriebenen Parametriersoftware. Diese wird auf einem Parametrier-PC mit Linux-Betriebssystem ausgeführt. Sie
fragt in einer grafischen Oberfläche vom Nutzer alle zum Betrieb des Messsystems notwendigen
Daten ab, erkennt automatisch die Teile der Messtechnik, die an den Parametrier-PC angeschlossene sind, und erstellt daraus Konfigurationsdateien. Anschließend werden vollautomatisch das
Betriebssystem und alle Konfigurationsdateien auf der CompactFlash-Karte installiert, die als
Massenspeicher des Messsystems dient.
178
15.1.6 Probebetrieb
Nachdem die Softwareinstallation, wie im letzten Abschnitt beschrieben, abgeschlossen ist, wird
die CompactFlash-Karte in das Messsystem eingebaut. Danach wird das Messsystem gestartet
und durchläuft mit der in Abb. 15.10 dargestellten Infrastruktur einen mehrtägigen Test, in dem
die Funktionalität der Messtechnik, die Plausibilität der Messdaten und die Stabilität der GPRSVerbindung überprüft werden. Erst wenn dieser Schritt abgeschlossen ist, wird das Messsystem
bei der zu monitorenden Wärmepumpenanlage installiert.
Compact−Flash−Karte
Embedded System
M−Bus−Messtechnik
OneWire−Messtechnik
GSM−Modem
SIM−Karte
Abbildung 15.10: Infrastruktur für den Testbetrieb von WP-Effizienz-Messsystemen
15.1.7 Prozessliste
Für Embedded Systems gilt der Grundsatz “keep it small, simple”. Zur Schonung der Systemressourcen und Vermeidung unnötiger Komplexität werden nicht benötigte Programme und
Systemdienste gar nicht erst gestartet. Deshalb enthält die Prozessliste des Messsystems (siehe
Abb. 15.11) sehr viel weniger Prozesse als die eines Standard-PCs unter Linux.
Jeder Prozess hat eine eindeutige Process ID (PID), über die er identifiziert und angesprochen
werden kann. Der init-Prozess besitzt immer die PID 1. Er ist der erste Prozess, der vom
Betriebssystemkern (Kernel) nach dem Booten gestartet wird. init startet alle benötigten
Systemdienste und verwaltet die verschiedenen Runlevel, in denen das System betrieben werden
kann. In der Prozessliste wird hinter dem init immer das aktuelle Runlevel in eckigen Klammern
angegeben. init kann außerdem überprüfen, ob von ihm gestartete Prozesse laufen und diese
erneut starten, falls das nicht der Fall sein sollte.
179
PID
1
2
3
4
5
6
281
551
560
632
662
674
758
785
787
788
25676
25687
COMMAND
init [2]
[keventd]
[ksoftirqd_CPU0]
[kswapd]
[bdflush]
[kupdated]
[kcopyd]
/usr/sbin/inetd
/usr/sbin/sshd
/usr/lib/npreal2/driver/npreal2d -t 1
/usr/sbin/watchdog
/bin/bash /etc/init.d/startscheduler.ssc
/usr/sbin/ntpd -p /var/run/ntpd.pid -u 105:104 -g
/Scheduler
/read_mbus /dev/ttyS0
/mux
/bin/sh /root/soekris/pppstart
/usr/sbin/pppd name [email protected]
connect /usr/sbin/chat -v -f /root/soekris/dialup.chat
disconnect /usr/sbin/chat -v -f /root/soekris/dialdown.chat
/dev/ttyS1 defaultroute noauth asyncmap 0 mtu 1200 mru 1299
noipdefault
14754 /bin/sh /root/soekris/pppsentry
Abbildung 15.11: Prozessliste eines Messsystems im Messbetrieb
Alle Prozesse, die in der Prozessliste in eckigen Klammern stehen, sind Kernel-Prozesse.
Die folgenden sonstigen Prozesse werden auf dem Embedded System des Messsystems ausgeführt:
inetd:
Dieser Prozess nimmt Anfragen aus dem Netzwerk entgegen und startet
die dazugehörigen Serverprozesse.
sshd:
Serverprozess der Secure Shell (SSH) (siehe Abschnitt 7.5.5)
npreal2d:
Treibersoftware zur Ansteuerung des MOXA-COM-Servers
watchdog:
Watchdog-Software, die den Hardware-Watchdog des Systems bedient
und diverse Systemzustände überprüft.
startscheduler.ssc:
Startskript für die weiter unten beschriebene Scheduler-Software
ntpd:
Software zur Synchronisation der Systemzeit mit einem Zeitserver
180
Scheduler:
Dieses Programm wurde ursprünglich entwickelt, um zu bestimmten Zeiten andere Programme zu starten oder zu stoppen. Im Messsystem wird
es genutzt, um sämtliche Messprogramme zu starten, deren Verhalten zu
überprüfen und bei einem Absturz schnell wieder neu zu starten, um größere Messdatenausfälle zu verhindern.
read_mbus:
Software zum Auslesen von M-Bus-Wärmemengenzählern
mux:
Mit dieser Software werden OneWire-Bausteine ausgelesen und alle
Messdatenfiles geschrieben.
pppstart:
Software zum Aufbau der Mobilfunk-Datenverbindung
pppd:
Low-Level-Tool zum Aufbau der Punkt-zu-Punkt-Verbindung zum Mobilfunkprovider
pppsentry:
Überwachungsprogramm für die Mobilfunkverbindung
Die Abbildung 15.12 zeigt eine grafische Übersicht der Startreihenfolge der Prozesse auf dem
Embedded System sowie deren Abhängigkeiten.
init
watchdog
sshd
pppstart
pppd
pppsentry
startscheduler.ssc
Scheduler
read_mbus
ntpd
mux
Abbildung 15.12: Startabfolge der Prozesse auf dem Embedded System des Messsystems
181
15.1.8 Systemüberwachung
Email-Reports mit Informationen zur Systemverfügbarkeit
In der Abb. 15.13 ist der Inhalt eines automatisch generierten Reports über die Verfügbarkeit
von Messsystemen im Feld dargestellt. Die einzelnen Spalten enthalten folgende Informationen:
machines:
In dieser Spalte werden die Hostnamen der einzelnen Messsysteme angegeben, unter denen sie identifiziert werden können.
Data:
Mit einem yes wird in dieser Spalte angezeigt, dass für den letzten Messtag Daten vorliegen und somit das Messsystem inklusive Datenübertragung einwandfrei funktioniert. Beim Fehlen der Daten steht in der Spalte
ein no. Liegen Messdaten vor, ist eine weitere Auswertung nicht notwendig. In allen weiteren Spalten, die mit der Erfassung der Messdaten zu tun
haben, steht dann ein %-Zeichen. Beim Fehlen von Messdaten kann anhand von Informationen, die in den weiteren Spalten des Reports stehen,
die Fehlerursache analysiert werden.
Ping:
Wie in den Abschnitten 7.6.1 und 7.6.3 beschrieben, wird einmal täglich die Erreichbarkeit der Messsysteme mittels ICMP Echo Requests
(“Pings”) überprüft. Die Erreichbarkeit wird im Report durch ein yes gekennzeichnet. Werden die ICMP-Pakete nicht beantwortet, wird das mit
einem timeout gekennzeichnet. Dieses ist dann auch eine mögliche Ursache dafür, dass keine Messdaten vorliegen.
rsync:
rsync ist ein für den Abruf der Messdaten notwendiges Programm. Da es
bei den ersten Messsystemen Probleme bei der automatisierten Installation der Software gab und rsync deshalb oft fehlte, wird die Verfügbarkeit
von rsync auf den Messsystemen überprüft. Der Status wird mit yes oder
no dargestellt.
File remote:
Die Verfügbarkeit der Messdatenfiles auf den Messsystemen wird überprüft. Liegen dort keine Messdaten vor, ist der Messprozess gestört.
Wenn es auf den Messsystemen Messdaten gibt, sie aber nicht auf dem
Abrufserver vorliegen, besteht das Problem beim Messdatenabruf. Der
Status wird mit yes oder no dargestellt.
Time ok:
Eine genaue Systemzeit ist eine Voraussetzung für eine korrekte Messwerterfassung. Deshalb werden täglich die Systemzeiten der Messsysteme überprüft. Eine korrekte Systemzeit wird mit yes, eine ungenaue mit
no gekennzeichnet.
182
Scheduler ok:
Der Scheduler ist eine Art Software-Watchdog für die Messprozesse mux
und read_mbus. Bei einem Absterben, z. B. durch Hardwareprobleme der
Messtechnik, werden diese Prozesse vom Scheduler sofort neu gestartet.
Die entsprechende Funktionalität stellt zwar auch der init-Prozess zur
Verfügung. Der Scheduler ist aber dennoch notwendig, weil durch ihn
zusätzlich eine Kontrolle der Systemzeit durchgeführt wird. Läuft der
Scheduler, so wird das mit einem yes gekennzeichnet.
mux ok:
Der zentrale Messprozess mux liest Messwerte aus dem OneWire-Bus
aus (Temperaturen, Feuchten, Impulse von Stromzählern) und schreibt
die täglichen Messdatenfiles. Es wird täglich überprüft, ob dieser Prozess
korrekt arbeitet. Läuft mux, wird das mit einem yes gekennzeichnet.
mbus ok:
Die M-Bus-Zähler für Temperaturen, Volumenströme und Wärmemengen werden vom separaten Messprozess read_mbus ausgelesen.
read_mbus stellt die Messdaten dann mux zur Verfügung. Auch die korrekte Funktion von read_mbus wird täglich überprüft. Läuft read_mbus,
wird das mit einem y gekennzeichnet.
Dials:
Diese Spalte gibt an, wie oft die GPRS-Verbindung in den letzten 24
Stunden neu aufgebaut worden ist. Bei jeder Neueinwahl werden Daten
übertragen, die beim Transfervolumen mitgezählt werden. Durch häufige Neueinwahlen können dabei erhebliche Datenmengen generiert werden. Bei Überschreitung des Inklusiv-Transfervolumens (im Mobilfunkvertrag festgelegt) entstehen dann hohe Kosten. Neueinwahlen können
durch zu geringe Signalstärken des GSM-Netzes, technische Probleme
beim Mobilfunkprovider, aber auch durch ungewollte Resets des Messsystems entstehen. Häufige Neueinwahlen sind immer ein Hinweis auf
ein technisches Problem.
MBsend:
Diese Spalte gibt das Daten-Transfervolumen der letzten 24 Stunden in
Megabyte an. Die Werte sollten für einzelnen Systeme weitgehend konstant bleiben. Bei Wartungsarbeiten können größere Datenmengen als
im Durchschnitt entstehen. Treten Transfervolumina auf, die deutlich
kleiner als der Durchschnitt sind, ist das ein Hinweis auf unvollständige Messdatensätze, die durch Probleme bei der Messtechnik entstehen
können. Liegt keine Information zum übertragenen Datenvolumen vor,
wird das mit einem n/a gekennzeichnet.
|Data|Ping
|no |timeout
|no |timeout
|no |yes
|no |timeout
|rep |yes
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|yes |%
|rsync
|%
|%
|yes
|%
|yes
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|%
|File remote|Time ok|Scheduler ok|mux ok|mbus ok|Dials|MBsend
|%
|%
|%
|%
|%
| 0
| n/a
|%
|%
|%
|%
|%
| 0
| n/a
|yes
|no
|yes
|yes
|y
| 0
| n/a
|%
|%
|%
|%
|%
| 0
| n/a
|yes
|yes
|yes
|yes
|y
| 0
| 0.00
|%
|%
|%
|%
|%
| 0
| 0.60
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.61
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.59
|%
|%
|%
|%
|%
| 0
| 0.45
|%
|%
|%
|%
|%
| 0
| 0.63
|%
|%
|%
|%
|%
| 0
| 0.04
|%
|%
|%
|%
|%
| 0
| 0.60
|%
|%
|%
|%
|%
| 0
| 0.60
|%
|%
|%
|%
|%
| 0
| 0.80
|%
|%
|%
|%
|%
| 0
| 0.39
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.59
|%
|%
|%
|%
|%
| 0
| 0.62
|%
|%
|%
|%
|%
| 0
| 0.61
|%
|%
|%
|%
|%
| 0
| 0.60
|%
|%
|%
|%
|%
| 0
| 0.61
|%
|%
|%
|%
|%
| 0
| 0.61
|%
|%
|%
|%
|%
| 0
| 0.62
183
Abbildung 15.13: Auszug aus einem automatisch generierten Report über die Systemfunktionen und die Erreichbarkeit von per
GSM vernetzten Messsystemen
machines
mobil-rda012
mobil-rda013
mobil-rda017
mobil-rda022
mobil-rda051
mobil-rda001
mobil-rda002
mobil-rda003
mobil-rda004
mobil-rda005
mobil-rda008
mobil-rda009
mobil-rda010
mobil-rda011
mobil-rda014
mobil-rda015
mobil-rda016
mobil-rda019
mobil-rda020
mobil-rda023
mobil-rda024
mobil-rda025
mobil-rda026
mobil-rda028
mobil-rda031
mobil-rda032
mobil-rda033
184
15.1.9 Messdatenformat
Die zeitliche Auflösung der von den Messsystemen im Feld aufgenommenen Messwerte
beträgt eine Minute. Die Messdaten werden in Form von ASCII-Dateien auf dem Messsystem
abgelegt. Dieses Format kann sehr gut sowohl in spezielle Auswertungsprogramme als auch in
Tabellenkalkulations-Software, wie z. B. Microsoft Excel, importiert werden. Zur grafischen
Aufbereitung der Daten, z. B. mit gnuplot [90], ist das Format ebenfalls gut geeignet. Außerdem
bieten ASCII-Dateien den Vorteil, dass sie im Gegensatz zu Binärdateien bei Beschädigungen
immer noch ausgewertet werden können.
Für die Messdatenübertragung zum Abrufrechner werden die Dateien per bzip2 komprimiert,
um das Übertragungsvolumen über das Mobilfunk-Netz zu minimieren.
Jede Datei mit Messdaten besteht aus einem Header (Abb. 15.14), der angibt, welche Messdaten
in welcher Spalte des Files stehen, und den eigentlichen Messdaten. In den ersten beiden
Spalten des Messdatenfiles wird jeweils der Messzeitpunkt für die Zeile mit Messwerten in
zwei verschiedenen Formaten angegeben. In der ersten Spalte wird die Zeit im hhmmss-Format
angegeben, das für “menschliche Leser” gedacht ist. Die zweite Spalte gibt die Zeit in einem
dezimalen 24h-Modus an, der zum Plotten der Daten besser geeignet ist.
#TIME TIME_DEC DS1820_1 DS2423_1_C1 P_1 DS2423_1_C2 P_2
DS2423_2_C1 P_3 DS2423_2_C2 P_4 DS2423_3_C1 P_5 DS2423_3_C2
P_6 DS2423_4_C1 P_7 DS2423_4_C2 P_8 MBUS_Date MBUS_Time
1_t_forward 1_t_backward 1_t_diff 1_flow_l_h 1_power_kW
1_energy_kWh 4_t_forward 4_t_backward 4_t_diff 4_flow_l_h
4_power_kW 4_energy_kWh 5_t_forward 5_t_backward 5_t_diff
5_flow_l_h 5_power_kW 5_energy_kWh 6_t_forward 6_t_backward
6_t_diff 6_flow_l_h 6_power_kW 6_energy_kWh 7_t_forward
7_t_backward 7_t_diff 7_flow_l_h 7_power_kW 7_energy_kWh
8_t_forward 8_t_backward 8_t_diff 8_flow_l_h 8_power_kW
8_energy_kWh kBread kBsend Dialcounter
Abbildung 15.14: Header eines Tages-Messdatenfiles für ein Wärmepumpensystem
Die Messpunkte werden nach den Sensoren, die die Daten liefern benannt. DS1820 bezeichnet
einen OneWire-Temperatursensor. Sensoren mit DS2423 im Namen sind OneWire-Impulszähler,
die dazu genutzt werden, Impulse von Stromzählern aufzunehmen. Dabei werden diese Impulse
gleich in kWh umgerechnet. Zu jedem Impulszähler-Messkanal gehört ein P-Kanal, der die aus
den Impulshäufigkeiten abgeleiteten Leistungen aufnimmt. P-Kanäle sind reine Rechenkanäle.
Alle Messkanäle, deren Bezeichner mit einer Zahl anfangen, speichern Messwerte von Wärmemengenzählern. Die Zahl im Kanalbezeichner gibt dabei jeweils die MBus-ID des Zählers
185
wieder. Jeder Wärmemengenzähler misst eine Vorlauf- und eine Rücklauftemperatur sowie
einen Volumenstrom. Aus diesen Werten berechnet der Wärmemengenzähler außerdem die
Differenz zwischen der Vorlauf- und der Rücklauftemperatur und die aktuelle thermische
Leistung. Außerdem integrieren die Geräte die übertragene Energiemenge auf.
Die Messkanäle kBread, kBsend und Dialcounter dienen der Kontrolle des übertragenen Datenvolumens über das Mobilfunk-Netz. Details dazu sind im Abschnitt 7.6.3 beschrieben.
15.1.10 Zusammenfassung
Das für die beiden Wämepumpen-Monitoringprojekte entwickelte Messsystem vereint die
positiven Eigenschaften der im Abschnitt 2.1 beschriebenen Datenlogger und PC-basierten
Messsysteme in sich. In Tablle 15.7 sind die Eigenschaften dieser Systeme gegenüber gestellt.
Datenlogger
klassisch
Konfiguration durch Laien
ja
flexible Anbindung von
Messtechnik
nein
Online-Datenabruf
nein
frei programmierbar
nein
Internet-Kommunikation
nein
verschlüsselte
Kommunikation
nein
wartungsarm
ja
preisgünstige Hardware
nein
energieeffizient
ja
Datenlogger
PC mit
Wärmepumpeninternetfähig Messtechnik Monitoringsystem
ja
nein
ja
nein
nein
nein
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
nein
ja
ja
nein
ja
nein
ja
ja
ja
ja
Tabelle 15.7: Vergleich von marktüblichen Monitoringsystemen mit dem neu entwickelten Monitoringsystem für Wärmepumpen
Mit der im Abschnitt 13.2 vorgestellten Parametriersoftware können die einzelnen Messsysteme
über eine grafische Benutzeroberfläche konfiguriert und parametriert werden. Die Software
wurde so ausgelegt, dass sie auch von Laien bedient werden kann.
Der Einsatz von Embedded Systems mit Linux-Betriebssystem ermöglicht eine freie Programmierung mit Standard-Programmiersprachen. Dadurch wird auch die flexible Integration neuer
Messtechnik möglich, da die Embedded Systems über zahlreiche Schnittstellen verfügen und
neue Treiber einfach in die vorhandene Messsoftware integriert werden können.
Mit der im Abschnitt 15.1.2 beschriebenen Kommunikationsinfrastruktur werden die Messdaten
per Internet und GPRS übertragen. Die Nutzung eines IPSec-VPNs (siehe Abschnitt 8.1) und
186
den Einsatz der Secure Shell (siehe Abschnitt 7.5.5) für den Datenabruf und die Fernwartung
sorgen für eine abgesicherte, verschlüsselte Kommunikation.
Bei den eingesetzten Embedded Systems handelt es sich um auf dem Markt zu sehr günstigen
Preisen verfügbare Hardware. Die Energieeffizienz der Systeme nicht ganz so gut wie die der
meisten Datenlogger, jedoch erheblich besser als bei PC-basierten Messsystemen.
15.2. VERTEILTES REGELUNGSSYSTEM
187
15.2 Ein verteiltes Regelungssystem für das Management eines Niederspannungsnetzes
15.2.1 Power Flow and Power Quality Management System (PoMS)
DISPOWER [56] war ein von der Europäischen Union gefördertes Projekt zum Thema Distributed Generation with High Penetration of Renewable Energy Sources. Das Projekt lief
vom 01.01.2001 bis zum 31.12.2005. Im Rahmen dieses Projektes wurde in einem Feldversuch in Stutensee-Blankenloch bei Karlsruhe der Prototyp eines Regelungssystems zur
Optimierung von Energieströmen und Power Quality in Niederspannungsnetzen entwickelt. Das
Regelungs-System wird seit dem Projektende in einer geänderten Konfiguration weiter betrieben.
Das als PoMS (Power Flow and Power Quality Management System) bezeichnete System
basiert auf einem verteilten Regelungssystem aus vernetzten Embedded Systems. Es wurde
vom Fraunhofer Institut für Solare Energiesysteme ISE [134] in Zusammenarbeit mit der MVV
Energie AG [163] entwickelt, zu deren Versorgungsgebiet Stutensee-Blankenloch gehört
Ziele des Feldversuches waren eine ökonomische Optimierung des Netzbetriebs aus Sicht
des Netzbetreibers sowie die aktive Kontrolle der Power Quality (PQ). PoMS implementiert
ein aktives Management-System für verteilte Erzeuger, steuerbare Lasten und Speicher in
Niederspannungsnetzen. Siehe auch [75][207][208].
Hauptbestandteile von PoMS sind die PoMS Central Unit (PCU), die Power Interface Boxes
(PIBs) und ein Netzwerk, das diese untereinander verbindet. Hinzu kommt Messtechnik (z. B.
für die Power Quality), die mit Hilfe der PIBs ausgelesen wird.
15.2.2 Erstellung von Fahrplänen
Die verteilten Erzeuger, steuerbaren Lasten und Speicher werden von PoMS mit Hilfe von
24 h-Fahrplänen gesteuert. Diese Fahrpläne arbeiten mit einer zeitlichen Auflösung von
15 Minuten. Sie werden auf der PoMS Central Unit erstellt. In Abb. 15.16 ist im unteren Teilbild
der Tagesfahrplan für ein BHKW (P CHP soll) dargestellt .
Eine wichtige Grundlage für die Erstellung von Fahrplänen für PoMS sind Wetterprognosen.
Für das in Stutensee-Blankenloch betriebene System werden Wetterdaten vom Deutschen Wetterdienst (DWD) [60] bezogen. Der DWD stellt dazu die Prognosen in Form von ASCII-Files
zweimal täglich auf seinem FTP-Server zur Verfügung. Die Wetterdaten dienen als Basis zur
Berechnung von Prognosen für die stochastischen Erzeuger (in Stutensee eine PV-Anlage), für
die elektrischen und thermischen Lasten (siehe Grafik 15.15).
188
ökonom. Randbedingungen
(z.B. Einspeisegesetz)
Erzeugungsprognose für
stochastische Erzeuger
DWD−Wetterdaten
Elektrische Lastprognose
ökonomische Optimierung
Kostenfaktoren
(z.B. Kraftstoff)
Thermische Lastprognose
vorläufiger Fahrplan
Ziel für Optimierung
techn. Randbedingungen
Fahrplan−Evaluierung
Ausgleich von
Vorhersageungenauigkeiten
aktuelle Messdaten
Algorithmus für die
Spannungsstabilisierung
Abbildung 15.15: Informationsfluss bei der Fahrplanerstellung des PoMS-Systems
Mit Hilfe dieser drei Prognosen werden Fahrpläne für die steuerbaren Geräte errechnet. Dabei
werden zahlreiche ökonomische Randbedingungen, wie z. B. die Bestimmungen des Erneuerbare Energien Gesetzes (EEG) [68] oder aktuelle Treibstoffpreise mitberücksichtigt. Außerdem
muss für die Fahrplanerstellung das ökonomische Optimierungskriterium klar definiert sein.
Neben den ökonomischen Randbedingungen gibt es auch noch technische Restriktionen. So dürfen Blockheizkraftwerke z. B. nicht beliebig oft gestartet und angehalten werden. Manchmal ist
der Betrieb der Aggregate aufgrund der Lärmbelästigung für die Anwohner nur zu bestimmten
Tageszeiten gestattet. Die ökonomisch optimierten Fahrpläne müssen deshalb an die technischen
Randbedingungen angepasst werden. Erst danach werden sie an die Regelungseinheiten der
steuerbaren Geräte (die PIBs) übertragen.
Soweit die aktuellen Messwerte den Prognosen entsprechen, arbeiten die PIBs die von der PCU
generierten Fahrpläne ab. Eine zusätzliche Regelungssoftware, der sogenannte Inday Regler,
gleicht mit Hilfe von aktuellen Messwerten die Abweichungen von den Prognosen aus.
15.2.3 Infrastruktur des verteilten Regelungssystems
Die Infrastruktur von PoMS ist in Abb. 15.17 dargestellt. Die lokale Vernetzung des PoMSNetzwerks wurde mit Ethernet (siehe Abschnitt 7.1.1) in der Ausprägung Fast Ethernet (100
Mbit) realisiert.
189
Da die Power Interface Box des Photovoltaik-Felds mehr als 100 m von den übrigen PoMSKomponenten entfernt ist und aus baulichen Gründen kein Ethernet-Kabel verlegt werde konnte,
wurden zur Überbrückung der Distanz zwei VDSL-Modems (siehe Abschnitt 7.1.2) eingesetzt,
die über eine schon vorhandene Zweidraht-Leitung transparent Daten zwischen den beiden
Ethernet-Segmenten übertragen.
Auf drahtlose Übertragungstechniken wie Wireless LAN (siehe Abschnitt 7.1.4) wurde aufgrund
von Sicherheitsbedenken und der für ein Regelungssystem zu hohen Störanfälligkeit verzichtet.
Über ein TV-Kabel-Modem Surfboard von Motorola, Inc. [160] (siehe dazu Abschnitt 7.2.2) hat
die PCU Zugang zum Internet. Als Internet-Provider fungiert die Kabel BW GmbH & Co. KG
[138].
Zwischen PCU und Kabel-Modem befindet sich ein Firewall-Router vom Typ Linksys WRT54GS. (Linksys [147] war früher ein eigenständiges Unternehmen, wurde vor einiger Zeit aber
von Cisco Systems Inc. [42] aufgekauft.) Die Routersoftware beinhaltet einen DynDNS-Client,
der dafür sorgt, dass das Regelungssystem trotz wechselnder IP-Adressen immer aus dem
Internet erreichbar ist (siehe dazu auch Abschnitt 7.4.2). Der Firewall-Router WRT-54GS wurde
gewählt, weil er zum damaligen Zeitpunkt der einzige vom DynDNS-Anbieter Dynamic Network
Services, Inc. [61] zertifizierte Router war.
Die Firewall blockt Zugriffe aus dem Internet auf die PCU mit Ausnahme von zwei Ports
komplett ab. Nur Zugriffe auf den Webserver Apache [10] (Port 80) und den SecureShell-Server
von OpenSSH [175] (Port 22) werden per Port-Forwarding (siehe Abschnitt 7.4.1) an die PCU
weitergeleitet.
190
Abbildung 15.16: Tagesauswertung der elektrischen Energieflüsse des Dispower-FeldtestSystems am Steinweg in Stutensee-Blankenloch
TV−Kabel−Modem
191
Firewall−Router
PCU
VDSL−
Modem
Internet
Monitoring Client
VDSL−
Modem
PIB
Blockheizkraftwerk
PIB
Batteriebank
PIB
Photovoltaik
Ethernet
VDSL
RS485
Internet
Abbildung 15.17: Kommunikations-Infrastruktur des Dispower-Feldversuchs in StutenseeBlankenloch bei Karlsruhe
192
15.2.4 Hardware
PoMS Central Unit
Die PoMS Central Unit ist ein x86-Server aus handelsüblichen Server-Komponenten. Für den
Einsatz in verschmutzten Umgebungen ist das Gehäuse mit Staubfiltern ausgestattet. Mehrere
Lüfter im Gehäuse sorgen auch bei hohen Temperaturen im Serverraum für einen stabilen
Betrieb des Systems.
Die Maschine verfügt über 1 GB Arbeitsspeicher. Er wurde so bemessen, dass im Betrieb
kein Auslagern von Speicherbestandteilen auf die Festplatte – auch als swapping bezeichnet –
notwendig wird. Durch swapping würde der Betrieb des Systems sehr stark verlangsamt.
Die Prototypen-PCU ist mit einer 80 GB IDE-Festplatte ausgestattet. Die Plattengröße ist so
bemessen, dass die gesamte PCU-Software und alle Messdaten über die komplette Laufzeit des
Systems aufgenommen werden können. Bei einem Seriensystem sollte zur Erhöhung der Datenund Betriebssicherheit ein Redundant Array of Independent Disks (RAID) (siehe Abschnitt 14.2)
eingesetzt werden.
Der Prozessor der PCU ist ein mit 3 GHz getakteter Pentium IV von Intel [133]. Das System
hat damit genug Rechenleistung für den PCU-Betrieb und zusätzliche Aufgaben (Webserver,
Backups, etc.).
Die PCU verfügt über zwei Netzwerk-Interfaces. Damit hat sie Zugang zum Internet und zum
Netzwerk des verteilten Regelungssystems von PoMS. Zwischen den beiden Interfaces findet
kein Routing statt, so dass das Regelungsnetzwerk durch die PCU vom Internet abgeschirmt
wird.
Mehr Details zum System sind auch unter [21] zu finden.
Power Interface Box (PIB)
Die Power Interface Box (PIB) (siehe Abb. 15.18) ist ein Embedded System. Sie wurde am
Fraunhofer Institut für Solare Energiesysteme ISE entwickelt. Zentrales Element des Systems
ist ein DIL/NetPC Modul vom Typ ADNP/1520 der Firma SSV Software Systems GmbH [201].
Die Hardware ähnelt sehr stark der des im Abschnitt 15.1.3 beschriebenen Embedded Systems
net4501 der Firma Soekris Engineering Inc. [200]. Zum Startzeitpunkt des Dispower-Projekts
waren keine fertigen Embedded Systems mit entsprechender Hardware am Markt verfügbar, so
dass eine Eigenentwicklung durchgeführt werden musste.
193
Das ADNP/1520-Modul beinhaltet folgende Hardware:
Prozessor:
32-bit ELAN SC520 CPU mit 133 MHz Taktfrequenz
Arbeitsspeicher:
64 MB SDRAM
Massenspeicher:
16 MB FLASH-Speicher
Schnittstellen:
zwei UARTs (Universal Asynchronous Receiver/Transmitters)
vom Typ 16550
Netzwerk:
Fast-Ethernet-Interface (100 Mbit)
Watchdog:
programmierbarer Watchdog-Timer
IO-Pins:
20 frei programmierbare IO-Pins
Massenspeicher-Interface:
IDE-Interface (IDE = Integrated Drive Electronics) zum Anschluss von Festplatten und anderen Laufwerken.
Das ADNP/1520-Board wird in einen DIL-Sockel (DIL = Dual Inline) der Basisplatine
eingesetzt, die am Fraunhofer ISE entwickelt wurde (siehe Abb. 15.19). Diese Basisplatine
enthält einen DC-DC-Spannungswandler der Firma Traco Electronic AG [211]. Mit Hilfe dieses
Wandlers kann die PIB mit Eingangsspannungen zwischen 9 und 36 Volt betrieben werden.
Je nach Bestückungsvariante der Basisplatine können die beiden universal asynchronous
receiver/transmitters als RS232-Schnittstelle, RS485-Schnittstelle oder direkt als OneWireBusmaster (siehe Abschnitt 15.1.3) genutzt werden. RS485 ist ein Zweidraht-Bussystem nach
ANSI TIA/EIA-485 [9], das häufig als Feldbus im industriellen Umfeld eingesetzt wird. Im
PoMS-System wird die RS485-Schnittstelle genutzt, um Power Quality-Messgeräte vom Typ
UMG503 der Firma Janitza Electronics GmbH [136] auszulesen. Eine weitere Anwendung ist
das Ansteuern von Input-Output-Modulen der Firma ICPDAS-EUROPE GmbH[110] (z. B. für
die Steuerung des Blockheizkraftwerks).
Das IDE-Interface des ADNP/1520-Board ist mit einem Compact-Flash-Sockel auf der Basisplatine verbunden. Dieser Sockel ist so dimensioniert, dass er neben normalen CF-Karten auch
Minifestplatten in CF-II Bauform – sog. Microdrives – aufnehmen kann.
Zur Darstellung von Systemzuständen der PIB werden vier der frei programmierbaren IO-Pins
des ADNP/1520-Boards als Ausgänge zur Ansteuerung eines LED-Feldes genutzt. Fünf weitere
Pins werden in Form einer Pfostenleiste aus dem PIB-Gehäuse herausgeführt. Über sie können
z. B. Relais angesteuert (output-Funktionalität) oder Schaltzustände eingelesen werden (inputFunktionalität).
194
Abbildung 15.18: Power Interface Box auf der Basis eines SSV Dilnet PC ADNP1520 [201]
FLASH RAM ADNP/1520−Modul
COM2
CPU/Chipsatz
RS232 −
Transceiver
Spannungswandler
IO−Pins
CF−Slot
COM2
Status−LEDs
COM1
Netzwerk
Abbildung 15.19: Platine der Power Interface Box
195
Zu Visualisierungszwecken wird eine Webserver-Software genutzt. Ein Bildschirm-Snapshot
einer Live-Visualisierung des Regelungssystems im Webbrowser mittels Java-Applets (siehe
Kapitel 9) ist in Abb. 15.20 dargestellt. Der Zugriff auf den Webserver ist nur mit einer gültigen
Login-Passwort-Kombination möglich.
Abbildung 15.20: Online-Visualisierung des Regelungssystems per Java-Applet
196
Der SSH-Server der PCU erfüllt gleich mehrere Funktionen. Er wird zur Fernwartung benötigt,
um Sicherheitspatches einzuspielen und aktualisierte Softwarepakete für das Regelungssystem
aufzuspielen. Backups von Messdaten und Software werden regelmäßig per rsync (siehe Abschnitt 7.5.6) und SSH über das Internet auf einen Server des Fraunhofer ISE übertragen.
15.2.5 Software der Power Interface Boxes
Die PIBs haben einen 16 MB Flash-Speicher als Massenspeicher. Dieser ist in verschiedene
Speicherbereiche aufgeteilt.
Der erste Teil des Flash-Speichers wird als Read Only Memory genutzt und enthält das Betriebssystem in gepackter Form. Beim Booten des Systems wird der Inhalt des Flash-Speichers
in den Arbeitsspeicher der PIB entpackt. Das Betriebssystem wird dann dort ausgeführt.
Änderungen am Inhalt dieses Teiles des Flash-Speichers sind während der Laufzeit nicht
möglich (einzige Ausnahme: Änderungen an der Netzwerkkonfiguration mit einem speziellen
Flasher-Tool). Vorteilhaft an diesem Konstrukt ist, dass Ausfälle der Versorgungsspannung oder
Systemabstürze nie Schäden am Betriebssystem im Flash-Speicher verursachen können. Die
Nicht-Veränderbarkeit ist aber gleichzeitig auch ein großer Nachteil, da im laufenden Betrieb
keine Sicherheitsupdates des Betriebssystems und der dazugehörigen Systemprogramme
durchgeführt werden können. PIBs sollten nur in vertrauenswürdigen Netzwerken betrieben
werden, die vom Internet abgeschottet sind und in denen keine Angriffe von anderen Rechnern
befürchtet werden müssen (siehe dazu Abschnitt 8.5).
Der zweite Teil des Flash-Speichers ist im laufenden Betrieb beschreibbar. In diesem Speichersegment befinden sich die für den Betrieb des PoMS notwendige Software sowie Messdaten.
Um den sehr knapp bemessenen Flash-Speicher effizient zu nutzen, wird das Journaling Flash
File System (JFFS) [17] genutzt, das on-the-fly eine Datenkompression durchführt.
Die PIBs arbeiten mit einem vom Hersteller des Prozessorboards SSV [201] speziell für diese
Hardware entwickelten Linux-Betriebssystem. Da im Flash-Speicher nur sehr wenig Platz
für das Betriebssystem zur Verfügung steht, wurden die beim Desktop-Linux anzutreffenden
Systemprogramme durch das sehr speichereffiziente BusyBox [37] in der Version 0.60.5 ersetzt.
BusyBox wurde speziell für die Nutzung in Embedded Systems entwickelt und vereint fast alle
für den Betrieb eines Linux-Systems notwendigen Betriebssystem-Tools in einem einzigen
multi-call binary.
Aus Speicherplatzmangel kann auf den PIBs kein SSH zur sicheren Kommunikation genutzt
werden. Die Fernadministration erfolgt daher per Telnet. Daten werden per File Transfer Protocol
(FTP) übertragen. Beide Protokolle arbeiten unverschlüsselt, so dass ein Sniffen von Passwörtern
im Netzwerk einfach zu bewerkstelligen wäre. Dies ist ein weiterer Grund, warum die PIBs nur
in einem Trusted Netwerk betrieben werden sollten.
197
15.2.6 Aufgaben der PoMS Central Unit (PCU)
Das PoMS arbeitet mit Fahrplänen zur Regelung der einzelnen Betriebsmittel. Zur Erstellung
der Fahrpläne müssen aufwändige Optimierungsrechnungen durchgeführt werden. Da die PCU,
wie im Abschnitt 15.2.4 beschrieben, ein leistungsfähiger Server ist, werden die Berechnungen
auf dieser Maschine durchgeführt.
Die PCU sammelt in einem zentralen Messprozess alle wichtigen Messdaten (Spannungen,
Leistungen, Power-Quality-Events, etc.) von den PIBs ein. Dazu stellen die PIBs ihre Messdaten in Echtzeit per Netzwerk-Schnittstelle zur Verfügung. Die PCU kumuliert die Daten
dann in einem gemeinsamen Messdatensatz für das komplette PoMS. Die Daten werden
dann in Form von Tagesdatensätzen archiviert. Von den Messdaten wird jede Nacht ein
Backup auf einen Server am Fraunhofer ISE übertragen. Bei der Berechnung der Fahrpläne für
die Betriebsmittel des PoMS fließen historische Messdaten des Systems mit in die Prognosen ein.
Da die PIBs nicht verschlüsselt kommunizieren können und deshalb in einem Trusted Network
betrieben werden, fungiert die PCU als Zugangsrechner zu diesem Netzwerk. Verbindungen
zu den PIBs können aus dem Internet nur aufgebaut werden, indem zunächst ein Login auf die
PCU erfolgt. Von dort aus kann dann auf die PIBs zugegriffen werden.
Für die Erfassung von Messdaten aller am PoMS beteiligten Rechner sind korrekte Systemzeiten
notwendig. Aufgrund der Netzwerkstruktur ist es für die PIBs nicht möglich, auf im Internet
verfügbare Zeitserver zuzugreifen. Die PCU gleicht deshalb ihre Systemzeit mit mehreren im
Internet verfügbaren Zeitservern ab und stellt ihre Systemzeit per Network Time Protocol (siehe
Abschnitt 7.5.3) den PIBs zur Verfügung.
15.2.7 Aufgaben der Power Interface Boxes (PIBs)
Die PIBs erfüllen je nach Einsatzort unterschiedliche Funktionen. Die PIB der Photovoltaikanlage nimmt nur Messdaten auf und stellt sie der PCU zur Verfügung. Für die Steuerung der
Batteriebank und des Blockheizkraftwerks werden zwei weitere PIBs eingesetzt. Diese erfüllen
neben ihren Mess-Aufgaben noch die Funktion von lokalen Reglern. Sie arbeiten dazu von der
PCU generierte Fahrpläne ab. Diese Fahrpläne werden je nach eingegangenen Messdaten und
Wetterprognosen mehrmals täglich aktualisiert.
Bei einem Kommunikationsausfall zwischen einer PIB und der PCU wird von der PIB zunächst
der letzte übertragene Fahrplan abgearbeitet. Danach geht das System in den Notbetrieb über
und steuert nach einem Notfallfahrplan.
198
15.2.8 Mechanismen zur Überwachung des PoMS
Das PoMS wurde so entwickelt, dass es seine Funktion weitgehend wartungsfrei ausüben kann.
Da aber nicht auszuschließen ist, dass beim Betrieb des Systems Probleme auftreten, wurden
zahlreiche Mechanismen zur Kontrolle des PoMS-Betriebs integriert.
PoMS basiert auf der Funktionalität von Netzwerkverbindungen. Deshalb wird das im Abschnitt
7.6.1 beschriebene Smokeping genutzt, um die Erreichbarkeit aller PIBs im lokalen Netz
zu überprüfen. Beim Ausfall einer PIB oder des Netzwerks verschickt die PCU Emails an
Wartungspersonal. Um auch Ausfälle der PCU oder des Internet-Zugangs zu registrieren,
wird auf einem zweiten Server im Internet ein zweites Smokeping-System betrieben, dass die
Verfügbarkeit der PCU überprüft, indem Anfragen an deren SSH-Server gestellt werden.
Checkskripten stellen die Funktion der zahlreichen Prozesse des PoMS sicher. Dazu überprüfen
sie u. a. regelmäßig das Vorhandensein wichtiger Dateien, wie z. B. der Wettervorhersagen des
DWD und der Fahrpläne. Im Fehlerfall werden Emails mit den Beschreibungen der Fehlers
generiert und an Wartungspersonal verschickt.
Mit dem im Abschnitt 7.5.4 beschriebenen Programm updatecheck wird sichergestellt, dass das
Betriebssystem und die Anwendungsprogramme auf der PCU aktuell sind und Sicherheitslücken
möglichst schnell gepatched werden.
15.2.9 Zusammenfassung
Das im Rahmen des DISPOWER-Projekts entwickelte verteilte Regelungssystem POMS zeigt,
dass durch den Einsatz von Embedded Systems und TCP/IP-basierter Kommunikationstechnik
dezentrale Energiesysteme aus Einzelkomponenten sinnvoll miteinander vernetzt werden
können. Das Ergebnis der Vernetzung ist ein Regelungssystem, bei dem die Einzelkomponenten
miteinander und mit einer übergeordneten Regelungskomponente kommunizieren, so dass ein
optimierter Betrieb des Gesamtsystems durchgeführt werden kann.
Die im Abschnitt 15.2.3 beschriebene Kommunikationsinfrastruktur ermöglicht jederzeit den
Abruf von Messdaten und die Fernwartung aller Teilkomponenten des Regelungssystems mit
Hilfe einer einzigen Internet-Verbindung. Exklusive Telekommunikationsanschlüsse für die
einzelnen Teilenergiesysteme sind durch die Vernetzung nicht mehr notwendig.
Die Internet-Verbindung wird außerdem genutzt, um weitere für die Regelung wichtige Informationen, wie z. B. Wetterprognosen, zu erlangen und damit das Regelungsverhalten zu optimieren.
Umfangreiche Funktionen zur Selbstdiagnose des Systems und Email-Services ermöglichen
einen wartungsarmen Betrieb. Mit der im Abschnitt 9 beschriebenen Visualisierung kann der
Zustand des Regelungssystems jederzeit online in anschaulicher Form dargestellt werden.
199
Die Struktur des Systems ist so angelegt, dass Komponenten hinzugefügt oder entfernt werden
können, ohne dass die Regler der einzelnen Teilkomponenten neu programmiert oder parametriert werden müssen. Das System ist dadurch wesentlich flexibler an neue Gegebenheiten anpassbar, als dies mit nicht vernetzten dezentralen Energiesystemen möglich wäre.
200
Kapitel 16
Zusammenfassung und Ausblick
16.1 Zusammenfassung
Die technische Entwicklung der letzten Jahre hat dazu geführt, dass Embedded Systems
für verschiedenste Einsatzzwecke inzwischen zu günstigen Preisen verfügbar sind. Einfache
Systeme werden bereits für unter 100 e angeboten. Diese Preisentwicklung ist zum Teil darauf
zurückzuführen, dass ähnliche Hardware in Mobiltelefonen, Unterhaltungselektronik und
Netzwerk-Appliances zum Einsatz kommt. Diese Geräte werden in sehr großen Stückzahlen
gefertigt. Dadurch werden immer niedrigere Herstellungskosten ermöglicht. Ein Ende der
Entwicklung ist nicht in Sicht, so dass die Preise für Embedded Systems wahrscheinlich weiter
sinken werden. Damit werden sie für immer mehr Einsatzzwecke interessant.
Neben den Preisen für die Hardware sind für die Realisierung verteilter Regelungs- und
Monitoringsysteme auch die Kommunikationskosten ein entscheidender Faktor. Die Preise für
die verschiedenen Arten von Internetzugängen entwickeln sich sehr unterschiedlich und die
Dynamik des Marktes ist recht groß. Da unterschiedliche verteilte Regelungs- und Monitoringsysteme auch sehr unterschiedliche Anforderungen an ihre Kommunikationsmittel stellen, gibt
es kein Patentrezept für ein optimiertes Kommunikationskonzept. In dieser Arbeit wurden die
technischen und finanziellen Bedingungen für den Einsatz verschiedener Kommunikationsmittel
näher untersucht und es wurde analysiert, welche Kommunikationsmittel für welche Anwendung
geeignet sind.
Mit zunehmender Verbreitung von verteilten Regelungssystemen, die über das Internet kommunizieren, gewinnt auch die Sicherheit dieser Systeme an Bedeutung. Im Rahmen dieser Arbeit
wurden verschiedene Sicherheitstechniken hinsichtlich ihrer Eignung für verteilte Regelungsund Monitoringsysteme untersucht und bewertet. Der Einfluss von Netzwerkstrukturen auf die
Sicherheit dieser Systeme wurde exemplarisch diskutiert.
Für die Entwicklung verteilter Regelungs- und Monitoringsysteme wurde ein Simulationstool geschaffen, das mit Hilfe von virtuellen Maschinen und einer Simulationssoftware die
201
202
KAPITEL 16. ZUSAMMENFASSUNG UND AUSBLICK
Simulation komplexer energietechnischer Anlagen inklusive der darin enthaltenen verteilten
Regelungssysteme ermöglicht. Durch dieses Simulatonstool wird die Entwicklung und Optimierung von Regelungs- und Kommunikationssoftware stark vereinfacht. Es ermöglicht die
Entwicklung der Software ohne Zugriff auf die Regelungshardware und bietet zahlreiche Analysewerkzeuge, wie z. B. Datenplotter und Netzwerksniffer, die die Entwicklungsarbeit erleichtern.
Mit steigender Komplexität von Monitoring- und Regelungssystemen steigt auch der Bedarf,
Anlagendaten in einer für den Betrachter intuitiv zu erfassenden Form darzustellen. InternetTechnik kann dazu einen Beitrag leisten. Im Rahmen dieser Arbeit wurde eine Softwarepaket
entwickelt, mit dem Anlagendaten eines vernetzten Monitoring- oder Regelungssystems in
Echtzeit im Webbrowser visualisiert werden können. Ein grafischer Editor erleichtert die
Parametrisierung der Visualisierungssoftware.
Am Beispiel eines verteilten Monitoringsystems für Energieeffizienzmessungen an Wärmpumpen konnte gezeigt werden, wie ein skalierbares verteiltes Monitoringsystem mit mehr als 150
Messstellen in ganz Deutschland effizient aufgebaut und betrieben werden kann. Dafür wurden
verschiedene Methoden zur weitgehend automatisierten Installation und Konfiguration von
Knoten verteilter Systeme analysiert. Die Ergebnisse der Analyse flossen in eine nutzerfreundliche Parametriersoftware ein, mit der die Konfiguration von Internetzugängen und Messtechnik
sowie die Betriebssysteminstallation der Messsysteme durchgeführt wurden.
Verteilte Systeme mit vielen Knoten sind wirtschaftlich nur sinnvoll, wenn der Betrieb und die
Überwachung dieser Systeme fast vollständig automatisiert erfolgen. Es wurde gezeigt, dass
sich mit Hilfe eines selbst entwickelten Softwareframeworks ein verteiltes Monitoringsystem
mit mehr als 150 Knoten so betreiben lässt, dass die Funktion der Messsysteme weitgehend
automatisch überwacht wird. Der Administrator wird dadurch von einem Großteil der Routinearbeiten entbunden. Sein Tätigkeitsschwerpunkt ist das Beheben von Fehlfunktionen, die von
der Überwachungssoftware gemeldet werden.
16.2 Ausblick
Die Zahl der verteilten Monitoring- und Regelungssysteme wird aufgrund fallender Kosten in
den nächsten Jahren stark zunehmen. Die Nutzung solcher Systeme ist mittlerweile für viele
Anwendungsbereiche interessant, für die sie bisher zu teuer waren.
Einen großen Anteil am Zuwachs der verteilten Monitoring- und Regelungssysteme wird der
Energiesektor haben. Zahlreiche Studien, z. B. die eEnergy-Studie [86] und die Smart Distribution 2020-Studie [32], gehen davon aus, dass in Zukunft ein großer Anteil der Stromerzeugung
mit regenerativen Energien und der Kraft-Wärme-Kopplung bestritten wird. Dazu wird es
notwendig sein, die vielen dezentralen Anlagen in Form von verteilten Regelungssystemen zu
koordinieren. Die Koordination wird zu einem großen Teil mittels Kommunikation über das
16.2. AUSBLICK
203
Internet stattfinden. Bis heute ist die Normierung der Kommunikation kleinerer Stromerzeuger
noch nicht weit fortgeschritten. Mit der IEC 61850-7-420 für verteilte Erzeugung gibt es zwar
einen Normierungsansatz. In wie weit sich diese sehr umfangreiche Norm mit ihren komplexen
Datenstrukturen jedoch für die breite Masse der kleineren Stromerzeuger umsetzen lässt, ist bis
jetzt noch nicht abzusehen.
Die Richtlinie 2006/32/EG über Endenergieeffizienz und Energiedienstleistungen [80] schreibt
die zeitnahe Einführung von Smart-Metering-Systemen beim Endkunden vor. Solche Systeme sind nichts anderes als verteilte Monitoring-Systeme. Beim Kunden werden diverse
Verbrauchsdaten (von Strom, Wasser, etc. ) erfasst und mittels Datenkonzentratoren zu den
Versorgungsunternehmen übertragen. Wie die Strukturen der Smart-Metering-Systeme aussehen
werden, ist zunächst noch unklar. Es gibt zahlreiche Interessengruppen, die an der Entwicklung
bzw. dem Betrieb dieser Systeme interessiert sind, z. B. große Energieversorgungsunternehmen,
Stadtwerke, Telekommunikationsfirmen, Hersteller von Telekommunikations- und Messtechnik
etc. Zum jetzigen Zeitpunkt ist noch nicht absehbar, welche Ausstattung solche Systeme haben
werden und welche Zusatzfunktionen und Schnittstellen sie bieten können.
Wie die Strukturen der verteilten Regelungs- und Monitoringsysteme aussehen werden, ist bis
jetzt ebenfalls noch nicht erkennbar. Es zeichnet sich bisher auch noch nicht ab, ob bestimmte
Kommunikationsmedien (z. B. DSL, GSM, Powerline) und Kommunikationsprotokolle eine
Vorrangstellung erringen werden.
Wir erleben zum jetzigen Zeitpunkt, da sich eine Knappheit fossiler Energieträger überdeutlich abzeichnet, kreative, schnell voranschreitende und technisch anspruchsvolle Entwicklungsprozesse, die viele Chancen und Lösungsansätze für eine ressourcenschonende und effiziente
Energienutzung versprechen. Dabei besteht jedoch oftmals die Gefahr, dass aufgrund zeitlichen
Drucks und finanzieller Interessen technische Minimallösungen und proprietäre Systeme realisiert werden. Es bleibt zu hoffen, dass sich offene Standards und Protokolle durchsetzen werden
und damit interoperable und zukunftssichere Systeme entstehen.
204
KAPITEL 16. ZUSAMMENFASSUNG UND AUSBLICK
Kapitel 17
Danksagung
Mein herzlicher Dank gilt
Herrn Prof. Dr. Jürgen Schmid und Frau Prof. Dr. Birgit Vogel-Heuser für die
spontane Bereitschaft, diese Arbeit zu betreuen,
meinen Eltern, die mich über die Studien- und Doktorandenzeit in vielerlei Hinsicht
unterstützt haben,
Herrn Dr. Christof Wittwer, der meine Arbeit begleitet und an vielen Stellen
mitgeprägt hat,
den Mitarbeitern der Arbeitsgruppe “Betriebsführung und Systemregelung” am
Fraunhofer-Institut für Solare Energiesysteme ISE für viele anregende Gespräche
und Diskussionen sowie für das gute Arbeitsklima,
Frau Corinna Storz für die vielfältige Unterstützung,
Herrn Martin Müller und Herrn Dr. Tobias Thiele für gute Hinweise, die bei der
Erstellung dieser Arbeit geholfen haben,
der Free Software Foundation (http://www.fsf.org) und den vielen Autoren der
Open Source Software, die im Rahmen dieser Arbeit genutzt wurden,
und allen, die zum Gelingen dieser Arbeit beigetragen haben.
205
Abbildungsverzeichnis
3.1
Schichten in einem Computersystem . . . . . . . . . . . . . . . . . . . . . . . 25
4.1
4.2
4.3
Struktur eines Regelungssystems mit zentraler Regelungsinstanz . . . . . . . . 32
Struktur eines Regelungssystems mit verteilten Reglern . . . . . . . . . . . . . 32
Struktur eines Regelungssystems mit verteilten Reglern und einer zentralen Instanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1
Display des vom Fraunhofer ISE entwickelten smart-metering-Systems
EWE-Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1
Zeile aus der Datei /etc/inittab zur Konfiguration von mgetty für die erste
serielle Schnittstelle /dev/ttyS0 . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Eintragung von Hostnamen für PPP-Einwahlverbindungen in die Datei
/etc/ppp/options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 In der Datei /etc/ppp/pap-secrets werden die Logins (z. B. remote) und Passwörter (z. B. caller) der zur PPP-Einwahl berechtigten Nutzer hinterlegt. . . .
7.4 Kommunikation eines Rechners mit einem GSM-Modem zur Abfrage der vom
GSM-Modem gemessenen Signalstärke am Antenneneingang . . . . . . . . .
7.5 Ein Rechner mit “privater” IP (192.168.0.1) bekommt per Network Address
Translation unter der “öffentlichen” IP 89.110.146.76 Zugang zum Internet. Die
anderen Rechner des Netzwerks haben keinen Internetzugriff. . . . . . . . . .
7.6 Alle Rechner eines Netzes mit “privaten” IPs bekommen per Network Address
Port Translation über eine “öffentliche” IP Zugang zum Internet. . . . . . . .
7.7 Zugriff von einem Client-Rechner auf einen Server ohne (A) und mit (B) PortForwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 Verbindungsaufbau von einem Client zum Einwahlrechner unter Nutzung von
DynDNS (1 - IP-Zuweisung, 2 - DynDNS-Update, 3 - DNS-Abfrage, 4 - Verbindungsaufbau) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.9 Skript zum Ermitteln der IP-Adresse eines Rechners und anschließenden Versenden dieser Adresse per Email . . . . . . . . . . . . . . . . . . . . . . . .
7.10 vom Tool updatecheck generierte Email mit einer Liste von Programmpaketen,
für die Sicherheitsupdates zur Verfügung stehen . . . . . . . . . . . . . . . .
7.11 Teilbild A: unsichere VNC-Verbindung über das Internet
Teilbild B: Eine VNC-Verbindung wird über eine SSH-Verbindung sicher durch
das Internet getunnelt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
206
. 56
. 57
. 57
. 59
. 65
. 65
. 67
. 69
. 70
. 74
. 77
ABBILDUNGSVERZEICHNIS
7.12 Screenshot vom Webinterface der Überwachungssoftware Smokeping
Die Qualität der Internetverbindung zwischen dem Überwachungsrechner und
einem zu überwachenden Server wird über einen Zeitraum von 3 h dargestellt.
7.13 Screenshot vom Webinterface der Monitoring-Software Nagios . . . . . . . .
7.14 Auszug aus einem automatisch generierten Report über die Erreichbarkeit von
per GSM vernetzten Systemen . . . . . . . . . . . . . . . . . . . . . . . . . .
7.15 Ausgabe von ifconfig für eine PPP-Verbindung per GSM . . . . . . . . . . . .
7.16 Verteilung des innerhalb von 24 h von einem Messsystem per GSM übertragenen Datenvolumens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1
8.2
8.3
8.4
8.5
8.6
9.1
9.2
9.3
9.4
10.1
10.2
10.3
10.4
Zwei lokale Netzwerke werden per VPN-Tunnel über das Internet verbunden. .
A: Direkte Kommunikation zwischen Client und Webserver
B: Nutzung eines Proxies zur Kommunikation zwischen Client und Webserver
Rechner mit direktem Zugang zum Internet . . . . . . . . . . . . . . . . . . .
Rechner mit Internet-Zugang per Firewall-Router . . . . . . . . . . . . . . . .
Netzwerk aus per VPN verbundenen Rechnern . . . . . . . . . . . . . . . . .
Trusted network hinter einem Zugriffsrechner mit Firewall . . . . . . . . . . .
Online-Visualisierung einer Wärmepumpenanlage per Java-Applet im Webbrowser Mozilla Firefox . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schema einer Visualisierung der Messdaten eines Embedded Systems mittels
JAVA-Applet und XMLRPC . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schema einer Visualisierung der Messdaten mehrerer Embedded Systems mit
Hilfe eines zentralen Webservers . . . . . . . . . . . . . . . . . . . . . . . .
Editor zum Erstellen von Java-Online-Visualisierungen . . . . . . . . . . . .
WML-Code einer WAP-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . .
WAP 1.x-Seiten dargestellt auf einem Mobiltelefon . . . . . . . . . . . . . . .
Übertragungsweg von WAP-Seiten vom Webserver zum Mobiltelefon . . . . .
links: Diagramm der elektrischen Leistungsaufnahme eines Haushalts aus dem
Stromnetz in Viertelstundenwerten. Die Darstellung erfolgt in Form eines WAP
2.x-Dokuments auf einem Mobiltelefon.
rechts: Für die Darstellung auf einem Mobiltelefon optimierte Diagramme zum
Stromverbrauch und zur Leistungsaufnahme eines Privathaushalts. . . . . . .
207
. 80
. 81
. 82
. 84
. 85
. 88
.
.
.
.
.
94
95
96
97
98
. 107
. 109
. 110
. 111
. 116
. 116
. 117
. 119
11.1 Mehrere virtuelle Maschinen werden auf einem Rechner ausgeführt. Sie sind
dabei durch ein virtuelles Netzwerk untereinander und mit dem Server verbunden. Über den Server können die virtuellen Maschinen auf das Internet zugreifen.122
11.2 Auf einem Rechner mit Ubuntu Linux 7.10 werden mit der Virtualisierungssoftware Virtualbox drei virtuelle Maschinen mit Damn-Small-Linux, Microsoft
Windows XP Professional und OpenSuSe 10.0 Linux gleichzeitig ausgeführt. . . 122
11.3 Struktur für Simulationen eines verteilten Regelungssystems mit virtuellen Maschinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
208
11.4 Internetzugriff für virtuelle Maschinen mittels einer Netzwerk-Bridge zur
Ethernet-Karte des Host-Rechners . . . . . . . . . . . . . . . . . . . . . . . .
11.5 Anbindung von Regelungssoftware auf einer virtuellen Maschine an die Simulationssoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.6 Shell-Skript zur Netzwerk-Konfiguration zum Betrieb von virtuellen Usermode Linux-Maschinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.7 Shell-Skript zum Start einer virtuellen User-mode Linux-Maschine mit drei
Netzwerkinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.8 Screenshot: Simulationsumgebung ColSim (oben rechts) und drei Windowmaker-Sessions, die auf drei verschiedenen mit Usermode-Linux realisierten virtuellen Maschinen ausgeführt werden . . . . . . . . . . . . . . . . . . . . . . .
11.9 Mit Embedded Systems bestückte Kompaktbaugruppen der Solarthermie 2000Anlage im Studentendorf Vauban in Freiburg im Breisgau . . . . . . . . . . .
. 130
. 131
. 132
. 133
. 135
. 136
12.1 Partitionstabelle einer 80 GB Festplatte mit einer Linux- und einer Linux-SwapPartition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
13.1 Hauptfenster der Parametriersoftware für WP-Effizienz-Messsysteme . . . . .
13.2 Fehlermeldungen der WP-Effizienz-Parametriersoftware bei einer ungültigen
PIN-Eingabe bzw. bei der Eingabe einer falschen ID für einen Wärmemengenzähler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3 Zusammenfassung aller Eingaben für die Parametrierung eines WP-EffizienzMesssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.4 Ausgabe der WP-Effizienz-Parametriersoftware beim Generieren von Konfigurationsdateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5 Infrastruktur für die Softwareinstallation von Wärmepumpen-Monitoringsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 148
. 148
. 149
. 149
. 152
14.1 Die Funktionsweise von Unionfs . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.2 Eintragung zweier Programme zum Aufbau einer Einwahl-Internetverbindung
als respawn-Prozesse in /etc/inittab . . . . . . . . . . . . . . . . . . . . . . . . 160
15.1 Geografische Verteilung der Messsysteme aus den Projekten Wärmepumpen im
Gebäudebestand (links) und Wärmepumpen-Effizienz (rechts) in Deutschland
(Quelle: Screenshots der Projekt-Webseiten [231][230] ) . . . . . . . . . . . .
15.2 Infrastruktur des Messdatenabrufs per GSM für im Feld verteilte Messsysteme.
Der Abrufrechner wird per Virtual Private Network an das Netzwerk des Mobilfunkanbieters angebunden. . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3 Jahresauswertung des Betriebs einer Fluid-Wärmepumpe . . . . . . . . . . .
15.4 Innenleben des net4501 der Firma Soekris Engineering Inc. [200] . . . . . . .
15.5 Rückseite des net4501 der Firma Soekris Engineering Inc. [200] mit Anschlüssen für Netzwerk (eth0, eth1, eth2), seriellen Schnittstellen (Console und externer Stecker) und Spannungsversorgung (Power) . . . . . . . . . . . . . . . .
. 162
. 164
. 165
. 167
. 168
15.6 Konfigurationsdatei zur Erstellung einer Sensorliste für ein M-Bus-basiertes
Messsystem mit mehreren Wärmemengenzählern . . . . . . . . . . . . . . .
15.7 Schaltkasten mit Embedded System, GSM-Modem und Messtechnik für ein
Wärmepumpen-Monitoring-Projekt . . . . . . . . . . . . . . . . . . . . . . .
15.8 Schemazeichnung des im Bild 15.7 abgebildeten Schaltkastens . . . . . . . .
15.9 Shellskript zum Anlegen einer RAM-Disk und zum Überlagern von /var mit der
RAM-Disk per Unionfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.10 Infrastruktur für den Testbetrieb von WP-Effizienz-Messsystemen . . . . . . .
15.11 Prozessliste eines Messsystems im Messbetrieb . . . . . . . . . . . . . . . . .
15.12 Startabfolge der Prozesse auf dem Embedded System des Messsystems . . . .
15.13 Auszug aus einem automatisch generierten Report über die Systemfunktionen
und die Erreichbarkeit von per GSM vernetzten Messsystemen . . . . . . . . .
15.14 Header eines Tages-Messdatenfiles für ein Wärmepumpensystem . . . . . . .
15.15 Informationsfluss bei der Fahrplanerstellung des PoMS-Systems . . . . . . . .
15.16 Tagesauswertung der elektrischen Energieflüsse des Dispower-FeldtestSystems am Steinweg in Stutensee-Blankenloch . . . . . . . . . . . . . . . .
15.17 Kommunikations-Infrastruktur des Dispower-Feldversuchs in StutenseeBlankenloch bei Karlsruhe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.18 Power Interface Box auf der Basis eines SSV Dilnet PC ADNP1520 [201] . . .
15.19 Platine der Power Interface Box . . . . . . . . . . . . . . . . . . . . . . . . .
15.20 Online-Visualisierung des Regelungssystems per Java-Applet . . . . . . . . .
209
. 171
. 172
. 173
.
.
.
.
177
178
179
180
. 183
. 184
. 188
. 190
.
.
.
.
191
194
194
195
Tabellenverzeichnis
2.1
Stand der Technik bei Monitoringsystemen für verteilte Energiesysteme . . . . . 19
7.1
7.2
7.3
Umrechnung der vom GSM-Modem gemessenen Signalstärke von RSSI in dBm . 59
GPRS Multislot-Klassen (Quelle: Elektronik-Kompendium [70]) . . . . . . . . . 61
die in RFC1918 festgelegten IP-Bereiche für “private” IPs . . . . . . . . . . . . 64
8.1
VPN-Varianten und ihre Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . 90
9.1
Programmiersprachen und ihre Eignung für die Online-Visualisierung von Messdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Eignung von Optionen zur Datenübertragung zwischen Visualisierungs-Client
und -Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2
13.1 Identifikation ausgesuchter OneWire-Bausteine über ihre Family Codes (siehe
[153]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
15.1 Anschlüsse des net4501 der Firma Soekris Engineering Inc [200] und deren Nutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
15.2 Kommunikationsschnittstellen für Wärmemengenzähler . . . . . . . . . . . . . . 170
15.7 Vergleich von marktüblichen Monitoringsystemen mit dem neu entwickelten
Monitoringsystem für Wärmepumpen . . . . . . . . . . . . . . . . . . . . . . . 185
210
Literaturverzeichnis
[1] http://www.abb.de.
[2] http://www.acme.com.
[3] E. Ahlers. Industrie-Netze, volume 9. ‘CT Magazin für Computertechnik, Heise Zeitschriften Verlag GmbH & Co. KG, April 2008.
[4] http://airsnort.shmoo.com.
[5] http://www.alliedtelesyn.com.
[6] http://www.alstom.de.
[7] http://www.am-utils.org/project-unionfs.html.
[8] http://www.amd.com.
[9] http://www.ansi.org.
[10] http://www.apache.org.
[11] http://www.apple.com.
[12] http://www.arm.com.
[13] P. Arnby, J. Hjelm, and P. Stark. Wap 2.x architecture - features, services and functions.
Ericsson Review, 2001.
[14] http://matt.ucc.asn.au/dropbear/dropbear.html.
[15] http://www.asus.com.
[16] http://www.atmel.com.
[17] http://developer.axis.com/old/software/jffs/index.html.
[18] http://www.bacnet.org.
[19] http://www.bdew.de.
211
212
LITERATURVERZEICHNIS
[20] R. Becker. Vernetzte Embedded Systems und Visualisierung mit Java. In Tagungsband
zum Internationalen Kolloquium über Anwendungen der Informatik und Mathematik in
Architektur und Bauwesen, 10.-12. Juni 2003, Weimar, Germany. Bauhaus-Universität
Weimar, 2003.
[21] R. Becker, T. Erge, A. Kröger-Vodde, H.-G. Puls, and C. Wittwer. Deliverable D9.2 Prototype of POMS ready for implementation in test sites using standard hardware and
interfaces. www.dispower.org, 2005.
[22] R. Becker and C. Wittwer. Regelung und Monitoring von Solaranlagen mit vernetzten
Embedded Systems. In Tagungsband zum 14. Symposium Thermische Solarenergie, 12.
bis 14. Mai 2004, Kloster Banz, Bad Staffelstein. Ostbayerisches Technologie-TransferInstitut e.V. - Regensburg, 2004.
[23] R. Becker and C. Wittwer. Emulation vernetzter Regelungssysteme für solarthermische
Energieversorgungssysteme. In Tagungsband zum 5. Symposium Thermische Solarenergie, 27. bis 29. April 2005, Kloster Banz, Bad Staffelstein. Ostbayerisches TechnologieTransfer-Institut e.V. - Regensburg, 2005.
[24] K. Bender, D. Großman, and B. Danzer. FDT + EDD + OPC UA = FDD UA, volume 2.
atp Automtisierungstechnische Praxis, Oldenbourg Industrieverlag GmbH, Februar 2007.
[25] http://www.bitkom.de.
[26] http://www.bluetooth.com.
[27] http://bochs.sourceforge.net.
[28] A. Bolder. Smart Metering: Der Zähler als Datenquelle in einem sich verändernden
Markt, volume 9. DVGW energie|wasser-praxis, wvgw Wirtschafts- und Verlagsgesellschaft Gas und Wasser mbh, 2007.
[29] http://www.bsi.de.
[30] http://www.bsi.de/certbund/infodienst/index.htm.
[31] http://www.bsi.de/literat/doc/gsm/gsm.pdf.
[32] B. Buchholz, V. Bühner, H. Frey, W. Glaunsinger, M. Kleimaier, M. Pielke, H. Roman,
J. Schmiesing, J. Stein, Z. Styczynski, and H. Baden. Smart Distribution 2020 – Virtuelle
Kraftwerke in Verteilungsnetzen – technische, regulatorische und kommerzielle Rahmenbedingungen.
[33] http://www.bundesgesetzblatt.de.
[34] http://www.bundesnetzagentur.de.
213
[35] http://www.bundesregierung.de/Content/DE/
Pressemitteilungen/BPA/2007/12/2007-12-05-bundesregierungbeschliesst-energie-und-klimaprogramm.html.
[36] dip21.bundestag.de/dip21/btd/16/094/1609470.pdf.
[37] http://www.busybox.net.
[38] A. Bühring, M. Miara, C. Russ, C. Bichler, and R. Becker. Zwei Feldmessungen neuer
Wärmepumpen gestartet. In Tagungsband zur Deutschen Kälte-Klima-Tagung, 23.-24.
Oktober 2007, Dresden, Germany. Deutscher Kälte- und Klimatechnischer Verein e.V.,
2007.
[39] http://www.can-cia.org/can.
[40] http://www.ccc.de.
[41] http://www.ccc.de/press/releases/2006/20060925/?language=de.
[42] http://www.cisco.com.
[43] http://www.clearwire.com.
[44] http://www.colsim.de.
[45] http://www.compactflash.org.
[46] G. Coulouris, J. Dollimore, and T. Kindberg. Verteilte Systeme - Konzepte und Design.
Addison Wesley, 2002.
[47] http://www.crypto.com/papers/others/rc4_ksaproc.ps.
[48] http://www.dbd-breitband.de.
[49] http://www.dcf77.com.
[50] http://www.debian.org.
[51] http://www.debian.org/security.
[52] http://derstandard.at.
[53] http://www.devolo.com.
[54] http://www.dgs.de.
[55] http://www.digi.com.
[56] http://www.dispower.org.
214
[57] http://www.dispowergen.com/std/der/index.html.
[58] http://www.dlink.com.
[59] http://www.dnp.org.
[60] http://www.dwd.de.
[61] http://www.dyndns.com.
[62] http://www.echelon.com.
[63] M. Eckl. Vorteile der zukünftigen IEC 61850 bereits heute nutzen, volume 13-14. ETZ
Elektrotechnik + Automation, VDE Verlag GmbH, 2002.
[64] http://www.eco.de.
[65] http://ecos.sourceware.org.
[66] http://www.eddl.org.
[67] http://www.edf.fr.
[68] http://www.gesetze-im-internet.de/eeg_2004.
[69] http://www.eiba.de.
[70] http://www.elektronik-kompendium.de.
[71] http://www.elstermesstechnik.com.
[72] http://www.enel.it.
[73] http://www.energyict.com.
[74] http://www.eon.com.
[75] T. Erge, R. Becker, A. Kröger-Vodde, H. Laukamp, M. Thoma, and R. Werner. Deliverable
D9.3 - Report on improved power management in low voltage grids by the application of
the PoMS system. www.dispower.org, 2005.
[76] http://www.ericsson.com.
[77] H. Erlenkötter and V. Reher. Java - HTML, Scripts, Applets und Anwendungen. Rowohlt
Taschenbuch Verlag GmbH, 1999.
[78] http://www.ethercat.org.
[79] http://www.ethernet-powerlink.org.
215
[80] EU:. Richtlinie 2006/32/EG des Europäischen Parlamentes und des Rates vom 5. April
2006 über Endenergieeffizienz und Energiedienstleistungen und zur Aufhebung der Richtlinie 93/76/EWG des Rates. Amtsblatt der Europäischen Union, 2006.
[81] http://www.ewe.de.
[82] http://www.fdtgroup.org.
[83] http://www.fieldbus.org.
[84] S. Fischer, U. Walther, S. Schmidt, and C. Werner. Linux-Netzwerke - Aufbau, Administration, Sicherung. S. 259ff, Nicolaus Millin Verlag GmbH, 2005.
[85] http://www.flexray.com.
[86] O. Franz, M. Wissner, F. Büllingen, C.-I. Gries, C. Cremer, M. Klobasa, F. Sensfuß,
S. Kimpeler, E. Baier, T. Lindner, H. Schäffler, W. Roth, and M. Thoma. Potenziale
der Informations- und Kommunikations-Technologien zur Optimierung der Energieversorgung und des Energieverbrauchs (eEnergy). wikConsult und FhG Verbund Energie,
2006.
[87] http://www.fsf.org.
[88] http://www.fsmlabs.com.
[89] http://www.gnu.org.
[90] http://www.gnuplot.info.
[91] www.golem.de/0607/46614.html.
[92] http://www.chiark.greenend.org.uk/~sgtatham/putty/download.
html.
[93] http://ec.europa.eu/energy/green-paper-energy-supply/doc/
green_paper_energy_supply_de.pdf.
[94] http://www.gnu.org/software/grub.
[95] http://www.gsmworld.com/about/index.shtml.
[96] http://www.gtk.org.
[97] O. Haas. Kommunikation für dezentrale Stromversorgungssysteme. Dissertation, dissertation.de - Verlag im Internet GmbH, 2002.
[98] http://www.hamachi.cc/company.
[99] http://www.hartcomm.org.
216
[100] http://www.heise.de/newsticker/Internet-foerdert-Fluchtvor-Information--/meldung/9442.
[101] http://www.heise.de/security/artikel/42011.
[102] H.-G. Hinzen and R. Heinze. IEC 61850 Erste Praxiserfahrungen bestätigen Zukunftssicherheit, volume 10. ETZ Elektrotechnik + Automation, VDE Verlag GmbH, Oktober
2007.
[103] http://www.homegridforum.org.
[104] http://www.homeplug.org.
[105] http://www.honeywell.com.
[106] http://content.honeywell.com/sensing/prodinfo/
humiditymoisture/009012_2.pdf.
[107] http://www.iana.org/assignments/port-numbers.
[108] http://www.ibm.com.
[109] http://www.ibuttonlink.com.
[110] http://www.icpdas-europe.com.
[111] http://www.iec.ch.
[112] http://www.ieee802.org/3.
[116] http://www.ietf.org.
[117] http://tools.ietf.org/html/791.
217
[130] http://www.incits.org.
[131] http://www.infineon.com.
[132] http://www.inquam-broadband.de.
[133] http://www.intel.com.
[134] http://www.ise.fraunhofer.de.
[135] http://www.itenos.de.
[136] http://www.janitza.de.
[137] http://java.sun.com.
[138] http://www.kabelbw.de.
[139] http://www.kernel.org.
[140] http://www.kingston.com.
[141] O. Kirch and T. Dawson. Linux Network Administrator’s Guide. O’Reilly and Assiciates,
2000.
[142] http://kismac.de.
[143] http://kismac.macpirate.ch.
[144] http://www.bmu.de/klimaschutz/internationale_klimapolitik/
kyoto_protokoll/doc/5802.php.
[145] R. Lauber and P. Göhner. Prozessautomatisierung 1. Springer, 1999.
[146] http://www.libgd.org.
[147] http://www.linksys.com.
218
[148] http://www.lonmark.org.
[149] D. Lous and P. Müller. Java - Der einfache Einstieg in die Internetprogrammierung.
Pearson Education Deutschland GmbH, 2000.
[150] http://www.matrikon.com.
[151] http://www.maxim-ic.com.
[152] MAXIM Application Note 148 - Guidelines for Reliable 1-Wire Networks.
[153] MAXIM Application Note 155 - 1-Wire Software Resource Guide Device Description.
[154] http://www.m-bus.com.
[155] M. Miara, C. Russ, and R. Becker. Wärmepumpen im Feldtest, volume 9. KI - Kälte - Luft
- Klimatechik, Hüthig GmbH, 2007.
[156] http://www.microsoft.com.
[157] http://www.mips.com.
[158] http://www.modbus.org.
[159] http://monkey.org/~dugsong/dsniff.
[160] http://broadband.motorola.com/default.asp.
[161] http://www.moxa.com.
[162] http://www.mozilla.com.
[163] http://www.mvv.de.
[164] http://www.myip.dk.
[165] http://www.nagios.org.
[166] http://www.nessus.org/nessus.
[167] http://www.netscape.com.
[168] http://nmap.org.
[169] http://www.nokia.com.
[170] http://www.nomachine.com.
[171] http://www.novell.com/linux.
[172] http://www.opcfoundation.org.
219
[173] http://www.opcconnect.com/taskrel.php.
[174] http://www.openmobilealliance.org.
[175] http://www.openssh.com.
[176] http://www.openssl.org.
[177] http://www.openvpn.net.
[178] http://www.opera.com.
[179] http://www.panasonic.com.
[180] http://pearpc.sourceforge.net.
[181] T. Peschel-Findeisen. Nebenläufige und Verteilte Systeme. MITP, 2006.
[182] http://www.philips.com.
[183] http://www.profibus.com.
[184] http://www.ptb.de.
[185] http://fabrice.bellard.free.fr/qemu.
[186] http://www.realvnc.com.
[187] http://www.redhat.com.
[188] http://www.rwe.com.
[189] http://rsync.samba.org.
[190] http://www.sandisk.de.
[191] http://www.schneier.com/paper-ipsec.pdf.
[192] http://www.schneier.com/paper-pptpv2.pdf.
[193] K. Schwarz. Mit genormten Webservice-Erweiterungen für die erfolgreiche Normenreihe IEC 61850 gegen die Vielfalt der Protokolle. In Tagungsband zum Internationalen
ETG-Kongress 2007, 23.-24. Oktober 2007, Karlsruhe, Germany. Energietechnische Gesellschaft im VDE (ETG)), 2007.
[194] T. Schäffler. Prozessnahe Kommunikation in Schaltanlagen mit IEC 61850. In Tagungsband zum Internationalen ETG-Kongress 2007, 23.-24. Oktober 2007, Karlsruhe, Germany. Energietechnische Gesellschaft im VDE (ETG), 2007.
220
[195] http://ec.europa.eu/energy/res/setplan/communication_2007_
en.htm.
[196] http://www.siemens.com.
[197] Siemens MC35i Cellular Engine - AT Command Set.
[198] http://www.smartgridvehicle.org.
[199] http://smartmontools.sourceforge.net.
[200] http://www.soekris.com.
[201] http://www.ssv-embedded.de.
[202] http://www.sun.com.
[203] http://www.t-com.de.
[204] http://www.t-mobile.de.
[205] http://www.techem.de.
[206] http://www.texas-instruments.com.
[207] M. C. Thoma. Optimierte Betriebsführung von Niederspannungsnetzen mit einem hohen
Anteil an dezentraler Erzeugung. Dissertation, ETH-Zürich, http://www.eeh.ee.
ethz.ch/psl/publications/phd.html, 2007.
[208] M. C. Thoma, T. Erge, R. Becker, and A. Kröger-Vodde. Active management of electrical networks with a high share of distributed generation. Journal of Distributed Energy
Resources, Volume 3, 2007.
[209] http://www.tixi.de.
[210] http://www.toshiba.com.
[211] http://www.tracopower.com.
[212] http://www.ubuntu.org.
[213] http://www.uni-paderborn.de.
[214] http://www.upaplc.org.
[215] http://user-mode-linux.sourceforge.net.
[216] http://www.vdn-berlin.de.
[217] http://www.virtuozzo.com.
221
[218] http://www.vmware.com.
[219] http://www.vodafone.de.
[220] http://www.wapforum.org.
[221] http://www.wavecom.com.
[222] http://www.white-sim.de.
[223] http://www.wi-fi.org.
[224] http://www.wimax-industry.com.
[225] http://www.windowmaker.info.
[226] http://www.windriver.com.
[227] http://www.winscp.net.
[228] http://www.wireshark.org.
[229] C. Wittwer. ColSim - Simulation von Regelungssystemen in aktiven solarthermischen
Anlagen. Dissertation, Universität Karlsruhe, 1999.
[230] http://wp-effizienz.ise.fraunhofer.de.
[231] http://wp-im-gebaeudebestand.de.
[232] H. Wörn and U. Brinkschulte. Echtzeitsysteme. Springer, 2005.
[233] http://www.xensource.com.
[234] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html.
[235] http://www.xfig.org.
[236] http://www.xfree86.org.
[237] http://www.xfree86.org/4.2.0/Xnest.1.html.
[238] http://www.w3.org/XML.
[239] http://www.xmlrpc.com.
[240] http://www.x.org.
[241] http://www.zenith.com.
222
[242] D. Zimmer. Trau, Schau, Wem - Professionelle Virtualisierungsprodukte im Überblick,
volume 5. IX Magazin für Professionelle Informationstechnik, Heise Zeitschriften Verlag
GmbH & Co. KG, Mai 2006.
[243] http://www.zvei.org.

systeme - KOBRA - Universität Kassel

Transcrição

Documentos relacionados

RAABEIs Homepage Sicherheit

unsere aktuelle Angebots-Übersicht.

1 Allgemeines 2 Emulationen / APIs

FUTRO B100 Thin Client Terminal mit ultra - hardware

EL-ME Datenblatt VIP 800_neu_03.FH10

Sicherheit

Ihr kompetenter Entwicklungsparter für Portfolio für

Leise Unter- haltung

Testen Sie jetzt die Virtuelle Franchise-Messe! Info

ENTWICKLUNG SOFTWARE