Diplomarbeit Marcel Noe

Entwurf und Implementierung eines
kabellosen Sensornetzes zur

Überwachung von Patienten
bei einem
Massenanfall von Verletzten
Diplomarbeit
von
cand. inform. Marcel Noe
am Institut für Biomedizinische Technik

der Fakultät für Elektro- und Informationstechnik
Erstgutachter: Prof. Dr. Armin Bolz

Zweitgutachter: Prof. Dr. Rüdiger Dillmann
Betreuender Mitarbeiter: Dr.-Ing. Marc Jäger
Bearbeitungszeit: 01. Mai 2010 – 01. November 2010

Eidesstattliche Erklärung
Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Diplomarbeit selbständig
und ohne unzulässige fremde Hilfsmittel angefertigt habe. Die verwendeten Litera-
turquellen sind im Literaturverzeichnis vollständig angegeben. Die Arbeit wurde in
gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde zur Erlangung eines
akademischen Grades vorgelegt.
Karlsruhe, 31.10.2010
II
Abstract
Bei einem Massenanfall von Verletzten (MANV) kommt es oft zu personellen Engpässen, so
dass eine ausreichende Überwachung der Patienten nicht gewährleistet ist. Abhilfe kann der
am IBT entwickelte Erste-Hilfe-Sensor schaffen, der mit einem neuartigen Verfahren Puls
und Atmung eines einzelnen Patienten überwacht. Zur Überwachung mehrerer Patienten
muss ein kabelloses Netzwerk aus diesen Sensoren gebildet werden. Entsprechende Netzwerk-
technologien existieren zwar, müssen aber in die bestehende Lösung integriert und um eine
geeignete Überwachungssoftware ergänzt werden. Dies ist Aufgabe der vorliegenden Arbeit.
Hierzu wird zunächst eine Untersuchung aller in Frage kommenden Funktechnologien unter
besonderem Augenmerk auf Energieeffizienz und Stabilität vorgenommen. ZigBee stellt sich
als bestgeeignetes Protokoll heraus, und es wird entschieden, eine Umsetzung auf Basis eines
Moduls des Herstellers Atmel durchzuführen. Bei dessen genauerer Betrachtung werden ei-
nige Schwierigkeiten identifiziert – beispielsweise das Auftreten von asynchronen Ereignissen,
das zum Synchronisationsverlust führen kann. Lösungen für diese Schwierigkeiten werden
gefunden und an Überwachungssoftware sowie Erste-Hilfe-Sensor konkret umgesetzt.
Zur Gewährleistung einer hohen Flexibilität wird ein komponentenbasierter Ansatz gewählt.
Hierdurch wird nicht nur die Austauschbarkeit der einzelnen Komponenten – z.B. der ein-
gesetzten Funktechnologie – erreicht, sondern auch deren Verteilung über mehrere Rechner
ermöglicht. Auf diesem Weg wird sowohl die Skalierbarkeit erhöht als auch eine Grundla-
ge für verbesserte Ausfallsicherheit geschaffen. Die Verbindung der einzelnen Komponenten
wird über Corba-Schnittstellen realisiert. Diese sind so gestaltet, dass auch externe Software
angebunden werden kann. Exemplarisch gezeigt wird dies am Beispiel einer Weboberfläche.
Damit wird gleichzeitig die Verwendung von Mobiltelefonen als Endgeräte zur Patienten-
überwachung ermöglicht, ohne dass eine Installation von Software auf diesen Geräten not-
wendig ist. Darüber hinaus wird eine Platine entwickelt, auf der das ZigBee-Modul und der
Mikrocontroller des Erste-Hilfe-Sensors integriert sind. Sie dient als Werkzeug zur Firmware-
Entwicklung für den erweiterten Erste-Hilfe-Sensor und ist gleichzeitig auch Testumgebung.
Bei einer eingehenden Evaluierung des Gesamtsystems wird die Interoperabilität aller Kom-
ponenten gezeigt. Außerdem wird die Leistungsaufnahme des ZigBee-Moduls in Abhängigkeit
von den Parametern des Energiesparmodus untersucht. Insgesamt zeigt sich, dass Laufzeit,
Reichweite und die erreichbare Anzahl an Sensoren für MANV-Szenarien mit hunderten von
Verletzten ausreichend sind.
III
Vorwort
Diese Arbeit entstand in Rahmen des Erste-Hilfe-Sensor -Projektes in Kooperation mit

Herrn Jan Tepelmann, der zur selben Zeit eine Studienarbeit geschrieben hat [Tepe10].
Die Arbeit von Herrn Tepelmann beschäftigt sich mit dem Entwurf und der Implemen-
tierung der Überwachungssoftware des Sensornetzwerkes (MANVSuite), wohingegen
sich die hier vorliegende Arbeit mit dem Entwurf der Hardware und der Interaktion
der einzelnen Komponenten des Sensornetzwerkes befasst.
Der Erste-Hilfe-Sensor verwendet ein neuartiges Verfahren zur Überwachung von Pa-
tienten mit Hilfe eines induktiven Verfahrens. Dies bietet einige Vorteil gegenüber
klassischen EKG-basierten Verfahren. Die eigentliche Funktionsweise des Erste-Hilfe-
Sensors ist für die vorliegende Arbeit nicht weiter relevant, lediglich auf den verwen-
deten Mikrocontroller muss Rücksicht genommen wurden.
Bei dieser Arbeit wurde ich von zahlreichen Helfern unterstüzt, bei denen ich mich
auf diesem Weg bedanken möchte. Die wichtigste Person bei der Durchführung die-
ser Arbeit war mein Projektpartner Herr cand. inform Jan Tepelmann, der auf meine
Bitten bereit war, die Implementierung der Überwachungssoftware in Form einer Stu-
dienarbeit durchzuführen. Er war immer ein wertvoller Diskussionpartner, ohne dessen
Hilfe es in der gegebenen Zeit nicht möglich gewesen, diese Arbeit in der vorliegenden
Form anzufertigen.
Mein besonderer Dank gilt meinen beiden Gutachtern und meinem Betreuer: Herr
Professor Dr. Armin Bolz hat durch seine spannende Vorlesung das Interesse an der
biomedizinischen Technik erst bei mir geweckt, und sich sehr viel Zeit genommen, mich
zu dieser interdisziplinären Arbeit zu ermutigen. Herr Professor Dr. Rüdiger Dillmann
hat sich bereit erklärt, von Seiten der Fakultät für Informatik ein Gutachten durch-
zuführen – ohne dies wäre ein Durchführen dieser Arbeit gar nicht möglich gewesen.
Mein Betreuer, Herr Dr. Marc Jäger hat mir immer wieder mit wertvollen Gesprächen
zur Seite gestanden, und mir viele Tipps zur korrekten Durchführung gegeben. Ins-
besondere hat er mir als Diplomand ein hohes Maß an Vertrauen entgegengebracht,
und mir so ermöglicht, das Geplante praktisch umzusetzen. Seine Firma, die Neocor
GmbH hat dabei die Kosten für die notwendige Hardware übernommen.
Von unschätzbarem Wert während des Studiums war und ist mein langjähriger gu-
ter Freund Herr Juniorprofessor Dr. Christoph Sorge, der sich nicht nur die Zeit zum
Korrekturlesen genommen, sondern mir bereits seit vielen Jahren wertvolle Tipps und
Hilfestellungen zum wissenschaftlichen Arbeiten gegeben hat, und sich immer wieder
Zeit für meine Sorgen und Nöte nimmt. Eine weitere sehr wertvolle Hilfe war Herr
cand. inform. Alexander Neumann, der vor vielen Jahren die Lust auf Mikrocontroller
bei mir geweckt hat, und mir während der Diplomarbeit ein wichtiger Diskussionspart-
ner für Hardwarefragen war. Auch meinem Freund Herrn Dipl.-Inform. (FH) Markus
Müller möchte ich für das Korrekturlesen danken. Sehr herzlich wurde ich von den
Mitarbeitern des IBT aufgenommen. Hierbei bedanke ich mich insbesondere bei Herrn
M.-Eng Daniel Wettach, der mir bei Fragen zum ADuC-Microcontroller immer wei-
tergeholfen hat, sowie Herrn Dipl.-Ing Stefan Fernsner für die Hilfe beim Erstellen der
MANVNode-Platinen. Auch bedanken möchte ich mich bei Frau Dipl.-Phys. Kerstin
Grimmel, Herrn Dipl.-Ing Nikolas Lentz und Herrn M. Sc. Firas Salih für zahlreiche
anregende und hilfreiche Diskussionen.
Von ganzem Herzen bedanken möchte ich mich bei meiner Lebenspartnerin Frau Dipl.-
Phys. Jennifer Girrbach sowie meinen Eltern, meinen Geschwistern und meiner Familie
und Freunden für den Rückhalt den sie mir in dieser anstrengenden Zeit gegeben ha-
ben, und den Mut, den sie mir zusprachen.
VI
Inhaltsverzeichnis
Abbildungsverzeichnis XIV
Tabellenverzeichnis XV
Quellcodeverzeichnis XVII
Glossar XXIX
1. Einleitung 1
1.1. Motivation der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Aufgaben und Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Gliederung und Vorgehensweise der Arbeit . . . . . . . . . . . . . . . . 4
2. Grundlagen 7
2.1. Grundlagen der kabellosen Übetragung . . . . . . . . . . . . . . . . . . 7
2.1.1. Paketvermittelte Übertragung . . . . . . . . . . . . . . . . . . . 7
2.1.2. Frequenzspreizung . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2.1. FHSS: Frequency Hoping Spread Spectrum . . . . . . 9
2.1.2.2. DSSS: Direct Sequence Spread Spectrum . . . . . . . . 9
2.1.2.3. FHSS vs. DSSS . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Corba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Inhaltsverzeichnis
3. Stand der Technik 13

3.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Kabellose Übertragungsprotokolle . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. DECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2. GSM/UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3.1. IEEE 802.11b . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3.2. IEEE-802.11g . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3.3. IEEE 802.11a . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3.4. Störsicherheit . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3.5. Leistungsaufnahme . . . . . . . . . . . . . . . . . . . . 18
3.2.4. WPAN: Wireless Personal Area Networks . . . . . . . . . . . . 18
3.2.4.1. IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4.2. IEEE 802.15.1: Bluetooth . . . . . . . . . . . . . . . . 19
3.2.4.2.1. Pairing . . . . . . . . . . . . . . . . . . . . . 20
3.2.4.2.2. Reichweite . . . . . . . . . . . . . . . . . . . . 21
3.2.4.2.3. Übertragungsrate . . . . . . . . . . . . . . . . 21
3.2.4.2.4. Störsicherheit . . . . . . . . . . . . . . . . . . 22
3.2.4.2.5. Anzahl Teilnehmer . . . . . . . . . . . . . . . 22
3.2.4.2.6. Leistungsaufnahme . . . . . . . . . . . . . . . 23
3.2.4.3. IEEE 802.15.4: ZigBee . . . . . . . . . . . . . . . . . . 23
3.2.4.3.1. Netzstruktur . . . . . . . . . . . . . . . . . . 25
3.2.4.3.2. Störsicherheit . . . . . . . . . . . . . . . . . . 26
3.2.4.3.3. Verschlüsselung . . . . . . . . . . . . . . . . . 29
3.2.4.3.4. Leistungsaufnahme . . . . . . . . . . . . . . . 29
3.2.4.4. Bluetooth Low Energy (ehemals Wibree) . . . . . . . . 30
3.2.5. Weitere Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.6. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Produkte zur kabellosen Patientenüberwachung . . . . . . . . . . . . . 31
3.4. Verwandte Projekte zum Einsatz in MANV-Szenarien . . . . . . . . . . 32
4. Analyse 35
4.1. Anforderungen an ein kabelloses System zur Überwachung von Patienten 35
VIII
Inhaltsverzeichnis
4.2. Der Analog Devices ADuC702X -Mikrocontroller . . . . . . . . . . . . . 36

4.2.1. Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.2. Peripherie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3. Die Atmel-ZigBit-Familie . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2.1. Bitcloud . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2.2. SerialNet . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2.2.1. SerialNet AT-Protokoll . . . . . . . . . . . . . 40
4.4. Kommunikation mit dem ZigBit-Modul . . . . . . . . . . . . . . . . . . 42
4.4.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.2. Behandlung asynchron auftretender Ereignisse . . . . . . . . . . 44
4.4.3. Behandlung von komplexen Antworten . . . . . . . . . . . . . . 45
4.4.4. Kombination beider Lösungen . . . . . . . . . . . . . . . . . . . 47
4.5. Powermanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5. Entwurf 51
5.1. Gesamtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. MANVNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1.1. Spannungsversorgung . . . . . . . . . . . . . . . . . . 57
5.2.1.2. Serielle Schnittstellen . . . . . . . . . . . . . . . . . . . 58
5.2.1.3. JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1.4. LED-Anzeige . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.1.4.1. Diagnosecodes . . . . . . . . . . . . . . . . . 61
5.2.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.2.1. Ansteuerung des UARTs . . . . . . . . . . . . . . . . . 62
5.2.2.2. Ansteuerung des ZigBit-Modul . . . . . . . . . . . . . 62
5.3. ZigBee-USB-Stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4. MANVSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5. MANVConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.1. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.2. Repräsentation eines ZigBit-Moduls . . . . . . . . . . . . . . . . 70
5.5.3. Synchronisierung der Befehlsübertragung . . . . . . . . . . . . . 71
IX
Inhaltsverzeichnis
5.5.4. Ergebnisse und Ereignisse . . . . . . . . . . . . . . . . . . . . . 72
6. Praktische Realisierung des Sensornetzes 77

6.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1.1. Anbindung des ZigBit-Moduls an den USB-Port . . . . . . . . . 77
6.1.2. Herstellung und Bestückung der Platine der MANVNode . . . . 78
6.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2.1. Verwendete Interrupts . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.1.1. Zugriff auf UART . . . . . . . . . . . . . . . . . . . . 81
6.3. MANVConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.1. Zugriff auf die serielle Schnittstelle . . . . . . . . . . . . . . . . 82
6.3.2. Automatische Erkennung des ZigBit-USB-Sticks . . . . . . . . . 86
6.3.3. CORBA-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . 89
7. Ergebnisse 93
7.1. Realisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.1.1. Integrierbarkeit in den Erste-Hilfe-Sensor . . . . . . . . . . . . 93
7.1.2. Interoperabilität aller Komponenten . . . . . . . . . . . . . . . 93
7.1.2.1. Durchführung . . . . . . . . . . . . . . . . . . . . . . . 94
7.1.2.2. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.1.3. Austauschbarkeit des MANVConnectors . . . . . . . . . . . . . 95
7.1.4. Anbindbarkeit an externe Software . . . . . . . . . . . . . . . . 96
7.1.4.1. Durchführung . . . . . . . . . . . . . . . . . . . . . . . 96
7.1.4.2. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.2. Leistungsaufnahme des ZigBit-Moduls . . . . . . . . . . . . . . . . . . 97
7.2.1. Leistungsaufnahme im Normalbetrieb . . . . . . . . . . . . . . . 98
7.2.2. Leistungsaufnahme bei Verwendung des Energiesparmodus. . . . 101
7.2.3. Sonderfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.2.4. Batterielaufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.3. Reichweite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.1. Reichweite im Freien . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3.2. Reichweite innerhalb geschlossener Räume . . . . . . . . . . . . 107
7.4. Maximale Teilnehmerzahl des Netzwerke . . . . . . . . . . . . . . . . . 107
X
Inhaltsverzeichnis
8. Diskussion 109
9. Zusammenfassung und Ausblick 115

9.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.2. Sicherheit des Netzwerkes . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.2.1. Aktueller Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.2.2. Angriffsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . 118
9.2.2.1. Ausspähen von Patientendaten . . . . . . . . . . . . . 118
9.2.2.2. Aktiver Angriff gegen das Netzwerk . . . . . . . . . . . 118
9.2.2.3. Störung des Netzwerkes . . . . . . . . . . . . . . . . . 118
9.2.3. Abwehrmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.2.3.1. ZigBee-Verschlüsselung . . . . . . . . . . . . . . . . . . 119
9.2.3.2. Befehlszähler . . . . . . . . . . . . . . . . . . . . . . . 119
9.2.3.3. Schutz auf Anwendungsebene . . . . . . . . . . . . . . 120
9.3. Verbesserung der Reichweite und Störsicherheit . . . . . . . . . . . . . 120
9.3.1. Anderer Frequenzbereich . . . . . . . . . . . . . . . . . . . . . . 120
9.3.2. Verwendung leistungsstärkerer ZigBee-Module und Antennen . . 121
9.3.3. Genauere Betrachtung des Bluetooth-Low-Energy-Standards . . 121
A. Beschreibung der beigelegten Software 123

A.1. MANV-Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.1.1. Starten des Connectors . . . . . . . . . . . . . . . . . . . . . . . 123
A.1.2. Kompilieren des Connectors . . . . . . . . . . . . . . . . . . . . 123
A.1.3. Verzeichnisstruktur des Quellcodes . . . . . . . . . . . . . . . . 124
A.1.3.1. Inhalt des Verzeichnises commands/ . . . . . . . . . . 124
A.1.3.2. Inhalt des Verzeichnises corba/ . . . . . . . . . . . . . 124
A.1.3.3. Inhalt des Verzeichnisses events/ . . . . . . . . . . . . 125
A.1.3.4. Inhalt der Verzeichnises results/ . . . . . . . . . . . . 126
A.1.3.5. Inhalt des Verzeichnisses lib/ . . . . . . . . . . . . . . 127
A.1.3.5.1. Interface eines ZigBit-Knotens . . . . . . . . . 127
A.2. Serial-To-Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.3. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.4. MANV-Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.5. Platine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
XI
Inhaltsverzeichnis
A.6. Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.7. Zigbit Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Literaturverzeichnis 136
XII
Abbildungsverzeichnis
2.1. Frequenzspreizung mit dem FHSS -Verfahren (Frei nach Farahani) . . . 8

2.2. Frequenzspreizung mit dem DSSS -Verfahren (Nach Farahani) . . . . . 9
3.1. ZigBee-Stack (Quelle: Wikipedia) . . . . . . . . . . . . . . . . . . . . . 24
4.1. Blockdiagramm des ADuC7026 -Mikrocontrollers (Quelle: Analog Devi-

ces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2. Blockdiagramm des ZigBit-24-A2R-Moduls (Quelle: Atmel) . . . . . . . 39
4.3. Darstellung des SerialNet-Protokolls als Zustandsautomat . . . . . . . . 41
5.1. Überblick über das Gesamtsystem . . . . . . . . . . . . . . . . . . . . . 52

5.2. Schaltplan der MANVNode: Mikrocontroller. . . . . . . . . . . . . . . . 54
5.3. Schaltplan der MANVNode: ZigBit-Modul. . . . . . . . . . . . . . . . . 55
5.4. Entwurf der Platine der MANVNode. . . . . . . . . . . . . . . . . . . . 56
5.5. Schaltplan der Spannungsversorgung der MANVNode. . . . . . . . . . . 57
5.6. Schaltplan der MANVNode: JTAG. . . . . . . . . . . . . . . . . . . . . 59
5.7. Schaltplan der MANVNode: LED-Anzeige und Taster. . . . . . . . . . 60
5.8. Ablauf der Ansteuerung des ZigBit-Moduls in der ZigBit-Firmware. . . 63
5.9. Schaltplan des USB-Sticks. . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.10. Entwurf der Platine des USB-Sticks. . . . . . . . . . . . . . . . . . . . 66
5.11. Datenfluss zwischen den einzelnen Kompnenten des Gesamtsystems. . . 67
5.12. Interaktion der einzelnen Threads des MANVConnectors . . . . . . . . 68
5.13. Klassendiagramm der ZigBit-Klassen . . . . . . . . . . . . . . . . . . . 70
5.14. Klassendiagramm der Ereignisse und Ergebnisse des MANVConnectors. 72
5.15. Klassendiagramm des MANV-Connectors (Linke Seite) . . . . . . . . . 74
5.16. Klassendiagramm des MANV-Connectors (Rechte Seite) . . . . . . . . 75
Abbildungsverzeichnis
5.17. Klassendiagramm der Threads des MANVConnectors . . . . . . . . . . 76
6.1. MANV-USB-Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2. Fertig bestückte Platine der MANVNode. . . . . . . . . . . . . . . . . . 80
6.3. Komponentendiagramm der CORBA-Schnittstellen. (Quelle: Jan Te-
pelmann) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.1. Diagramm des Aufbaus des Integrationstests. . . . . . . . . . . . . . . . 94

7.2. Photo des Aufbaus des Integrationstests. . . . . . . . . . . . . . . . . . 95
7.3. Screenshot der MANVGui während des Integrationstests. . . . . . . . . 96
7.4. Router oder Koordinator im Normalbetrieb. . . . . . . . . . . . . . . . 98
7.5. Endknoten im Normalbetrieb ohne Energiesparmodus. . . . . . . . . . 99
7.6. Analyse des Spannungsverlaufs eines Clients im Normalbetrieb. . . . . 99
7.7. Detailaufnahme eines Empfangsmodus-Peaks. . . . . . . . . . . . . . . 100
7.8. Aus dem Energiesparmodus erwachter Client. . . . . . . . . . . . . . . 101
7.9. Analyse des Spannungsverlaufs eines Clients bei Nutzung des Energie-
sparmodus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.10. Client, der das periodische Aufrufen des Energiesparmodus nutzt. . . . 102
7.11. Client mit deaktiviertem Empfangsmodus. . . . . . . . . . . . . . . . . 104
7.12. Beitrittsvorgang eines Clients in ein Netzwerk. . . . . . . . . . . . . . 105
7.13. Client, der die Verbindung zum Netzwerk verloren hat. . . . . . . . . . 105
XIV
Tabellenverzeichnis
3.1. Überschneidungen zwischen ZigBee, WLAN und Bluetooth-Kanälen . . 26
4.1. Übersicht der wichtigsten SerialNet-Befehle . . . . . . . . . . . . . . . 42

4.2. Übersicht der SerialNet-Ereignisse . . . . . . . . . . . . . . . . . . . . . 42
7.1. Berechnung von IP owersave für exemplarische Werte von tsleep und tawake . 104
A.1. Struktur des Quellcodeverzeichnisses . . . . . . . . . . . . . . . . . . . 124

Quellcodeverzeichnis
Kommunikation mit dem ZigBit Modul . . . . . . . . . . . . . . . . . . . . . 42

Befehle in Warteschlange einreihen . . . . . . . . . . . . . . . . . . . . . . . 45
Komplexe Antworten behandeln . . . . . . . . . . . . . . . . . . . . . . . . . 46
Komplexe Antworten und Asynchrone Ereignisse behandeln . . . . . . . . . 47
Firmware: Ansteuerung des ZigBit Moduls . . . . . . . . . . . . . . . . . . . 62

Firmware: Ansteuerung des ZigBit Moduls inkl. Ereignissbehandlung . . . . 64
Seriellen Port auf Socket umleiten . . . . . . . . . . . . . . . . . . . . . . . . 83

USB–Bus durchsuchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Devicenode lokalisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
ZigBit–Modul erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Glossar
I 2C Serieller Bus zum Anbinden von Komponenten an Mikrocon-

troller.
A/D-Wandler Analog-zu-Digital-Wandler.
Access-Point Zentrale Station (Zugangspunkt) eines kabellosen Netzwerks.
ADuC Mikrocontrollerfamilie der Firma Analog Devices auf ARM -
Basis.
AES Advanced Encryption Standard
AFH Adaptive Frequency Hopping
AJAX Technologie zur Realisierung von Benutzeroberflächen auf Basis
von Webseiten unter Einsatz von Javascript und JSON.
Algorithmus Eindeutige Handlungsvorschrift bzw. Anweisungsfolge zur Lö-
sung eines Problems.
ANT+ Proprietärer Funkstandard für die Datenübertragung im Nah-
bereich, z.B. für Pulsuhren.
ARM RISC-Prozessorarchitektur, die von verschiedene Herstellern in
Lizenz gefertigt wird.
AT-Befehlssatz Satz von Befehlen, der ursprünglich zur Steuerung von Modems
entwickelt wurde.
Beacon dt. Leuchtfeuer – periodisches Bekanntmachen des Vorhanden-
seins des Netzwerks.
Bit Kleinste Informationseinheit eines Computers, kann die Zu-
stände 1 und 0 annehmen.
Glossar
BitCloud SDK zur Erstellung von Firmware für die ZigBee-Module der
Firma Atmel.
Bluetooth Kabelloser Übertragungsstandard für WPANs.
Broadcast Datenpaket, das an alle Empfänger im Netzwerk gesendet wird.
Browser Siehe Webbrowser.
BSD UNIX -artiges Betriebssystem.
Bus Verbindung zwischen mehreren Geräten, bei denen alle Geräte
an einen gemeinsamen Übertragungsweg angeschlossen sind.
Busy-Waiting Warten auf ein Ereignis unter Verschwendung von Prozessor-
leistung.
Byte 8 Bit
C Imperative Programmiersprache, insbesonders zur hardwarena-
hen Entwicklung.
C++ Objektorientierte Programmiersprache auf Grundlage von C.
Cast Ändern des statischen Datentyps einer Variable auf einen an-
deren Typ.
CD Compact Disc
Client Komponente, die einen Dienst nutzt.
Corba Hier: Programmiersprachen-unabhängige Middleware.
CRC Cyclic Redundancy Check
Crossworks Entwicklungsumgebung für Mikrocontroller-Firmware.
CSMA/CA Carrier Sense Multiple Access/Collision Avoidance
CTS Clear to Send
DAC Digital zu Analog Wandler.
dB Dezibel
Deadlock Nicht mehr zu behebende Verklemmung von mindestens zwei
Threads.
Debuggen Suchen und Entfernen von Fehlern.
DECT Digital Enhanced Cordless Telecommunications – Standard für
festnetzgebundene Funktelefone.
Denial-Of-Service Blockieren eines Dienstes durch Überfluten mit Anfragen oder
Ausnutzen eines Softwarefehlers.
XXII
DRAM Dynamischer RAM, der periodisch aufgefrischt werden muss,
um seinen Inhalt zu erhalten.
DSSS Direct Sequence Spread Spectrum.
EDR Enhanced Data Rate
EEPROM Electrically Erasable Programmable Read-Only Memory
EKG Elektrokardiogramm – Überwachung der Herztätigkeit durch Ab-
leiten elektrischer Signale.
Energy Detection Überprüfen, ob ein Frequenzband frei ist, bevor es zur Daten-
übertragung verwendet wird.
FFD Full Function Device
FHSS Frequency Hoping Spread Spectrum
Firmware Software, die fest in ein Hardware-Gerät eingebettet ist.
Flashen Programmieren eines Flashspeichers.
Flashspeicher Günstigere Variante eines EEPROMS, das zur Massendaten-
speicherung verwendet werden kann.
GPIO General Purpose Input/Output
GPS Global Positioning System – Ein Satellitennavigationssystem.
GUI Graphische Benutzeroberfläche.
Hashmap Datenstruktur, die aus Paaren aus Schlüsseln und Werten be-
steht. Auch bekannt als assoziatives Array oder Record.
HF Hochfrequenz
Host Computer, der Dienste anbietet.
HTTP Hypertext Transfer Protocol – Protokoll zur Übertragung von
Webseiten.
I Strom.
IC Integrierter Schaltkreis
Idle Task Aufgabe, die immer dann bearbeitet wird, wenn keine anderen
Aufgaben anstehen.
IEEE Institute of Electrical and Electronics Engineers
Interface Beschreibung der Schnittstelle eines Objektes über Signaturlis-
ten.
XXIII
Glossar
Interrupt Unterbrechungsaufforderung. Die Abarbeitung des aktuellen Pro-

grammcodes wird sofort beendet, und eine ISR wird ausge-
führt.
IO-Port Input/Output-Port
ISM-Band Industrial, Scientific and Medical Band – Mehrere Frequenz-
bänder, für deren Benutzung eine allgemeine Betriebserlaubnis
ausreicht.
ISR Interrupt-Service-Routine
Java Programmiersprache der Firma Sun Microsystems.
Javascript Skriptsprache, die vor allem in Webbrowsern eingesetzt wird.
JRE Java Runtime Environment
JSON Javascript-basiertes Datenübertragungsformat von Webservern
zu Webbrowsern.
JVM Java Virtual Machine
kBit Kilobit
Klasse Abstraktes Modell eines Objektes in der objektorientierten Pro-
grammierung. Definiert Methoden und Attribute eines Objek-
tes.
Klasse Datenstruktur, die Eigenschaften, Attribute und Methoden ei-
nes Objektes beschreibt.
km Kilometer
Kompilieren Übersetzen des Quellcodes eines Programms in ausführbaren
Binärcode.
LAN Local Area Network
LED Leuchtdiode
Linux Freies UNIX -artiges Betriebssystem.
Low-Dropout Spannungsregler, der mit niedriger Differenz zwischen Eingangs-
und Ausgangsspannung arbeiten kann.
Lötstopplack Auf Leiterplatten aufgetragene Lackschicht, die die Leiterbah-
nen schützt.
m Meter
XXIV
MAC Media Access Control
MacOS Betriebssystem der Firma Apple Computer.
Man-in-the-middle Angriff, bei dem Datenpakete zwischen zwei Kommunikations-
partnern durch einen Angreifer abgefangen werden und der In-
halt der Pakete manipuliert wird.
MANV Massenanfall von Verletzten
MANVNode Test- und Entwicklungsplatine für den kabellosen Erste-Hilfe-
Sensor.
MANVSuite Verwaltungssoftware des Sensornetzwerks.
MBit Megabit
Mesh-Netzwerk (Voll-)Vermaschtes Netzwerk, meist in Verbindung mit mobilen
Ad-Hoc Netzwerken, bei denen einzelne Knoten untereinander
spontan Netzwerke bilden.
mF Millifarad
MHz Megahertz
Middleware Softwarelösung zum Zugriff auf von Objekten auf entfernten
Rechnern.
MIPS Million Instructions per Second
Monitor Gerät zur Überwachung von Vitaldaten von Patienten.
MSPS Million Samples per Second
Multicast Datenpaket mit mehreren bestimmten Empfängern.
Multimeter Mehrzweckmessgerät, das unter anderem Strom und Spannung
messen kann.
mV Millivolt
mW Milliwatt
Nameserver Softwaredienst, der eine Übersetzung von Namen in Adressen
vornimmt.
nF Nanofarad
Objekt Instanz einer Klasse. Kapselt Daten und Programmcode zum
Zugriff dieser Daten in einer gemeinsamen Datenstruktur. Hier-
durch wird die konkrete Implementierung hinter eine Schnitt-
stelle versteckt und wird damit austauschbar.
XXV
Glossar
Ohmsches Gesetz U =R·I

OOP Objektorientierte Programmierung: Programmierung mit Hilfe
von Klassen, Objekten und Vererbung.
Open Source Softwareprodukt, bei dem der Quellcode frei verfügbar ist.
OpenSSL Open Source Bibliothek, die viele Verschlüsselungsverfahren
implementiert.
OSI-Modell Generisches Schichtenmodell von Netzwerkprotokollen. Defi-
niert 7 Schichten. Jede Schicht ist greift nur auf die Diens-
te der direkt darunterliegenden Schicht zu und bietet wieder-
um Dienste für die darüber liegende Schicht an. Dies ermög-
licht einen modularen Aufbau von Netzwerkprotokollen, da die
Schichten unabhängig voneinander ausgetauscht werden kön-
nen. In praktisch eingesetzten Netzwerkprotokollen sind meist
nicht alle 7 Schichten implementiert.
Oszilloskop Messgerät zur optischen Darstellung von zeitlichen Spannungs-
verläufen.
PC Personal Computer
Peak Lokales Maximum (oder je nach Messrichtung auch Minimum)
eines Spannungsverlaufs.
Peer-to-Peer Verbindungen zwischen zwei oder mehr Teilnehmern, bei denen
alle Teilnehmer gleichberechtigt sind.
Piezo-Summer Elektrisches Bauteil, dass einen Summton generiert, sobald man
eine Spannung anlegt.
PIN Persönliche Identifikationsnummer
PKW Personenkraftwagen.
PLA Programmierbare logische Anordnung
Port Schnittstelle
Power-Management Energieverwaltung – Maßnahmen um Energie zu sparen.
Prozess Menge von einem oder mehreren Threads inklusive eines dazu-
gehörigen Speicherbereiches.
Pseudocode Vereinfachter Quellcode zur einfachen Beschreibung von Algo-
rithmen.
XXVI
Python Objektorientierte Skriptsprache.
R Widerstand.
RAM Random Access Memory
Replay Angriff, bei der legitime Datenpakete abgefangen und zu einem
späteren Zeitpunkt wieder ins Netzwerk eingegeben werden.
RFD Reduced Function Devices
Ringpuffer Datenstruktur, die sich selbst überschreibt, wenn sie über ein
gewisses Maß gefüllt wurde.
RISC Reduced Instruction Set Computer.
Router Netzwerkgerät, das Pakete zwischen Teilnehmern weiterleitet.
RS-232 Übertragungsstandard für serielle Schnittstellen.
RTS Ready to Send
Sample Siehe Sampling.
Sampling Umwandlung eines analogen in ein digitales Signal mittels Ab-
tastung.
Schicht Siehe OSI-Modell.
SDK Software Development Kit
Serialnet Firmware für die ZigBee-Module der Herstellers Atmel.
Server Komponente, die einen Dienst anbietet.
Setup Aufbau
Shunt Niederohmiger Widerstand zur Messung von Strömen mit ei-
nem Spannungsmessgerät.
SIG Special Interest Group
Signatur Typ und Name einer Methode sowie ihrer Parameter.
Skripstprache Programmiersprache, deren Quellcode nicht kompiliert wird.
Socket Softwareabstraktion einer Netzwerkverbindung die sich verhält
wie ein Dateizugriff.
SPI Serieller Bus zum Anbinden von Komponenten an Mikrocon-
troller.
SRAM Statischer RAM auf Basis von sogenannten Flip-Flop-Bausteinen.
Benötigt im Gegensatz zu DRAM kein periodisches Auffrischen
des Inhalts.
XXVII
Glossar
SSL Secure Socket Layer

SSP Secure Simple Pairing
Stack Stapel, entweder als Datenstruktur in einer Programmierspra-
che, Stapelspeicher eines Prozessors oder im Sinne eines Proto-
kollstapels.
Startup-Code Programmcode, der die Initialisierung eines Mikrocontrollers
durchführt.
Symbian Betriebssystem für ein Nokia-Handys.
Thread Ausführungsstrang eines Programms. Ein Programm kann meh-
rere Threads haben, die parallel arbeiten.
Timeout Fehler, der durch das Überschreiten einer Zeitgrenze aufgetre-
ten ist.
TinyOS Open-Source-Betriebssystem für Sensornetzwerke.
TLS Transport Layer Security – Nachfolger von SSL.
Token Sendeerlaubnis innerhalb eines Netzwerks, die von Teilnehmer
zu Teilnehmer gereicht wird.
Transceiver Sende- und Empfangseinheit.
Treiber Softwareprogramm, das die Ansteuerung eines Hardware-Gerätes
übernimmt.
U Spannung.
UART Universal Asynchronous Receiver Transmitter
UML Unified Modeling Language – Graphische Modelierungssprache
zum Entwurf von Software.
Unicast Datenpaket mit einem bestimmten Empfänger.
UNIX Familie von Mehrbenutzerbetriebssystemen.
USB Universal Serial Bus – Universelle Schnittstelle, die seit ca. 2000
an nahezu jedem PC vorhanden ist.
Vererbung Mechanismus zur Wiederverwendung von Oberklassenimple-
mentierungen in einer Unterklasse.
Virtuelle Maschine In Software implementierter, uirtueller Computer.
VM siehe Virtuelle Maschine
XXVIII
W Watt
Webbrowser Programm zum Anzeigen von Webseiten.
Webinterface Graphische Benutzeroberfläche auf Basis einer Webseite.
Webserver Software, die Webseiten ausliefert.
WEP Wired Equivalent Privacy – Nicht mehr zeitgemäßes Verschlüs-
selungsverfahren für WLAN -Netzwerke.
Windows Betriebssystemfamilie der Firma Microsoft.
WLAN Wireless Local Area Network
WPA Wi-Fi Protected Access – Neuer Verschlüsselungsstandard für
WLAN -Netzwerke.
WPAN Wireless Personal Area Network
ZC ZigBee Coordinator
ZED ZigBee End Device
ZigBee Kabelloser Übertragungsstandard für Sensornetzwerke.
ZR ZigBee Router
XXIX
1. Einleitung
In diesem Kapitel wird zunächst die Arbeit motiviert. Danach werden die Aufgaben
und Ziele definiert. Abschliessend wird die Gliederung der folgenden Kapitel erläutert.
1.1. Motivation der Arbeit

Unter dem Begriff Massenanfall von Verletzten“ (MANV) versteht man ein Ereignis,
”
bei dem innerhalb kurzer Zeit eine große Anzahl von Verletzten versorgt werden muss.
Hierbei mögen dem Leser zuerst Vorfälle wie die Terroranschläge am 11. September
2001, die Reaktorkatastrophe von Tschernobyl oder spektakuläre Naturereignisse wie
der Hurrikan Katrina, die Flutkatastrophen der letzten Jahre oder die Erdbeben in
Haiti in den Sinn kommen. Doch bereits Ereignisse geringeren Ausmaßes – wie z.B. ein
Auffahrunfall auf der Autobahn, ein Zugunglück, eine Massenpanik bei einem Konzert
oder starke Schneefälle, wie sie im vergangengen Winter aufgetreten sind – können
den Rettungsdienst einer Region sehr schnell an die Grenzen seiner Leistungsfähigkeit
bringen. Beispielhaft seien hier folgende Ereignisse der letzten Jahre und Jahrzehnte
genannt:
• 1980 — Oktoberfestattentat: 13 Tote, 211 Verletzte
• 1988 — Flugtagunglück von Ramstein: 70 Tote, 1000 Verletzte
• 1998 — ICE-Katastrophe von Eschede: 101 Tote, 88 Verletzte
• 2000 — Zugunglück von Brühl: 9 Tote, 149 Verletzte

1. Einleitung
• Dazu kommen jedes Jahr ca. 400.000 Verletzte im Straßenverkehr.
Im Falle eines Massenanfalls von Verletzten treffen vor Ort viele unterschiedliche Ein-
heiten von Rettungskräften aufeinander. Um die Zusammenarbeit dieser Kräfte über-
haupt zu ermöglichen und ein geordnetes Vorgehen zu unterstützen, gibt es klar defi-
nierte Abläufe und Verantwortlichkeiten. Zunächst versuchen die Rettungskräfte, die
Patienten außerhalb des unmittelbaren Gefahrenbereichs abzulegen. An dieser Abla-
gestelle werden die Patienten vom Rettungsdienst übernommen, welcher auch bereits
lebensrettende Sofortmaßnahmen einleitet und eine Erstversorgung durchführt. Wenn
möglich erfolgt bereits hier eine erste Registrierung der Patienten (Fundort, Name
usw.). Nun werden die Patienten einer Triage, also der Einordnung in verschiedene
Schweregrade, unterzogen, um zu entscheiden, in welcher Reihenfolge diese Patienten
versorgt werden. Diese Einordnung ist notwendig, da meist nicht genügend Ressour-
cen (sowohl Material als auch Personal) vorhanden sind, um sofort alle Patienten zu
versorgen. Daher gilt das Ziel, dass möglichst viele Patienten den Vorfall mit einem
möglichst geringen Schaden überstehen. Um eine Zuteilung der vorhandenen Ressour-
cen gemäß dieses Ziels zu gewährleisten, erfolgt eine Einordnung der Patienten in 4
Kategorien[Weid06]:
• Grün: Patient ist ansprechbar und kann sich selbstständig vom Unfallort wegbe-
wegen.
• Gelb: Patient hat Behandlungsbedarf und kann sich nicht mehr selbstständig
vom Unfallort entfernen, befindet sich jedoch nicht in akuter Lebensgefahr.
• Rot: Patient befindet sich in einem akut lebensbedrohlichen Zustand (z.B. Kreis-
laufstillstand, hoher Blutverlust) und benötigt sofortige medizinische Behand-
lung.
• Schwarz: Patient ist verstorben.
Obwohl diese Vorgehensweise eine schnelle Versorgung von Schwerverletzten gewähr-

leistet, stellt sich eine Reihe von Problemen:
1. Patienten können in die falsche Gruppe eingeordnet werden.
2. Möglicherweise verschlechtert sich der Zustand eines Patienten nach seiner Ein-
teilung in die Gruppe Gelb“ rapide, so dass er sofortiger Versorgung bedarf.
”
2
1.2. Aufgaben und Ziele der Arbeit
3. Es besteht ein Konflikt zwischen sorgfältiger Untersuchung und zu wenig zur

Verfügung stehender Zeit. Hierbei ist zu bemerken, dass die Sichtung immer
noch ohne besondere technische Hilfsmittel stattfindet. Die Patienten werden
mit Hilfe von einfachen Papierkarten markiert, die Überprüfung von Atmung,
Puls und Blutdruck erfolgt durch einfache physische Methoden wie Anfassen,
Hören und Beobachten.
Insbesondere der zweite Punkt obiger Aufzählung könnte mit technischen Mitteln ent-
schieden verbessert werden. Da eine dauerhafte Überwachung nur deswegen nicht er-
folgt, weil nicht genügend Personal zur Verfügung steht, könnte dieses durch ein auto-
matisches System ersetzt werden, welches die Patienten überwacht und im Falle einer
Zustandsänderung eine Alarmierung durchführt. Zwar gibt es automatische Überwa-
chungssysteme (sogenannte Monitore), die in Krankenhäusern oder Rettungsfahrzeu-
gen zur Patientenüberwachung eingesetzt werden. Allerdings sind diese Systeme für
den Einsatz in einem MANV-Szenario ungeeignet, da sie zu groß, zu teuer und zu
kompliziert sind.
1.2. Aufgaben und Ziele der Arbeit

Ziel dieser Arbeit ist die Entwicklung und prototypische Implementierung eines kabel-
losen Netzwerkes zur Überwachung von Patienten während eines MANVs. Als Aus-
gangsbasis hierfür dient der am IBT von Marc Jäger in [Jäg08] entwickelte Erste-
Hilfe-Sensor. Hierbei soll der Sensor in die Lage versetzt werden, die Vitaldaten des
angeschlossenen Patienten kabellos an eine zentrale Überwachungsstation zu übertra-
gen. Die zu entwickelnde Lösung soll eine große Anzahl von Teilnehmern unterstützen,
zugleich aber auch möglichst kostengünstig sein. Darüber hinaus soll sie möglichst
stromsparend sein, damit der Erste-Hilfe-Sensor auch längere Zeit über eine kleine
Batterie (idealerweise eine Knopfzelle) betrieben werden kann.
Parallel zu dieser Arbeit wird von Jan Tepelmann in [Tepe10] eine Steuerrungssoftwa-
re ( MANVSuite“) für die Überwachungsstation des Netzwerkes entwickelt. Zu dieser
”
Software soll eine Schnittstelle zur Verfügung gestellt werden, über die zum einen die
Vitaldaten ausgeliefert, zum anderen Befehle an die einzelnen Sensoren empfangen
werden. Diese Schnittstelle soll netzwerkfähig sein.
3
1. Einleitung
1.3. Gliederung und Vorgehensweise der Arbeit

Zunächst wird in Kapitel 2 eine kurze Einführung in die Grundlagen, die zum Ver-
ständnis dieser Arbeit wichtig sind, gegeben. Dies ist insbesondere deshalb wichtig,
da es sich um eine interdisziplinäre Arbeit zwischen Informatik und Elektrotechnik
handelt.
Im darauf folgenden Kapitel wird der aktuelle Stand der Technik genauerer Betrach-
tung unterzogen. Hierbei werden zunächst kabellose Netzwerkprotokolle betrachtet
und auf ihre Eignung zur Lösung der gestellten Problemstellung untersucht. Hierbei
erweist sich das ZigBee-Protokoll als besonders geeignet. Daraufhin erfolgt ein kurzer
Überblick über die Marktsituation bei Produkten zur kabellosen Patientenüberwa-
chung. Im Abschluss des Kapitels werden einige verwandte Projekte vorgestellt und
auf Ähnlichkeiten und Unterschiede untersucht.
Aus dem Stand der Technik werden in Kapitel 4 nun die Anforderungen an die zu
entwickelnde Lösung aufgestellt. Anschließend werden die Bauteile vorgestellt, die zur
Implementierung der Lösung verwendet werden. Diese werden auf Ihre Eignung un-
tersucht und es werden zu beachtende Eigenheiten herausgearbeitet. Für diese Eigen-
heiten werden verschiedene Lösungsmöglichkeiten vorgestellt und analysiert, die im
späteren Verlauf der Arbeit als Grundlage für Entwurf und Implementierung dienen
werden.
Der eigentliche Entwurf wird in Kapitel 5 beschrieben. Hier wird als Erstes ein gro-
ber Entwurf des Gesamtsystems durchgeführt, in dem zunächst die zentralen Kom-
ponenten der Lösung identifiziert werden. Im weiteren Verlauf des Kapitels wird der
detailierte Entwurf jeder dieser Komponenten dargestellt, so dass diese implementiert
werden können. Bei dem Entwurf wird zwischen Hardware und Software unterschieden.
Kapitel 6 behandelt die praktische Umsetzung des theoretischen Entwurfs. Ein Schwer-
punkt bildet hier die Beschreibung der praktischen Probleme, die bei der Umsetzung
aufgetreten sind, sowie deren Lösung.
In Kapitel 7 wird sodann eine genaue Evaluierung der entwickelten Lösung in Hinblick
auf Erfüllung der in Kapitel 4 aufgestellten Anforderungen, durchgeführt; die Ergeb-
4
1.3. Gliederung und Vorgehensweise der Arbeit
nisse dieser Evaluation werden dann im Kapitel 8 diskutiert.
Abschließend wird der Inhalt dieser Arbeit in Kapitel 9 zusammengefasst, und es

werden im Rahmen eines Ausblicks Vorschläge gemacht, wie die in dieser Arbeit ent-
wickelte Lösung weiter ausgebaut und verbessert werden kann.
Abgerundet wird die Arbeit durch einen umfangreichen Anhang, in dem eine Hilfe-
stellung zur Umsetzung der in der Arbeit entwickelten Lösung in ein fertiges Produkt
geliefert wird.
5
2. Grundlagen
In diesem Kapitel werden die in späteren Kapitel vorausgesetzten Grundlagen erörtert.

Hierzu gehören zum einen die Grundlagen der kabellosen Übertragung, zum anderen
eine kurze Beschreibung der Programmiersprachen Java und Python sowie der Corba-
Middleware.
2.1. Grundlagen der kabellosen Übetragung

Zum besseren Verständnis der in dieser Arbeit beschriebenen kabellosen Übertragungs-
protokolle werden in diesem Abschnitt einige Grundbegriffe der kabellosen Übertra-
gung erklärt.
2.1.1. Paketvermittelte Übertragung

Bei der Übertragung von Daten kann grundsätzlich zwischen der Paket- und der Lei-
tungsvermittlung unterschieden werden. Bei der Leitungsvermittlung wird für jeden
Kommunikationsvorgang ein eigener Kanal verwendet. Meist wird dieser Kanal zu Be-
ginn der Kommunikation auf- und beim Ende wieder abgebaut. Hierbei wird meist
ein fester Weg vorgegeben, den die zu sendenden Daten zwischen zwei Partnern zu-
rücklegen. Über diesen Kanal gesendete Daten kommen beim Empfänger in genau der
selben Reihenfolge an, wie sie vom Sender gesendet wurden. Auch steht meist eine
garantierte Mindestübertragungsrate zur Verfügung.
Diesen Vorteilen steht eine Reihe von Nachteilen gegenüber. Für Aufbau und Betrieb
2. Grundlagen
der Leitung muss ein gewisser Aufwand betrieben werden. Wenn Übertragungsraten
garantiert werden, stehen diese ggf. nicht für andere Anwendungen zur Verfügung.
Wird die Kapazität der Leitung nicht ausgeschöpft, so bleiben diese Reserven unge-
nutzt und verfallen.
Anders verhält sich die Paketvermittlung. In diesem Szenario teilen sich alle Teil-
nehmer eine gemeinsame Leitung. Möchte nun ein Teilnehmer Daten senden, so teilt
er sie in kleine Pakete auf und versieht diese mit der Adresse des Empfängers. Nun
wird jedes Paket einzeln über die Leitung verschickt. Hierbei passiert es ggf. eine Rei-
he von Zwischenstationen, die es jeweils zur nächsten Zwischenstation weiterleiten,
bis der endgültige Empfänger erreicht ist. Da sich nun viele Empfänger eine Leitung
teilen, kann eine deutlich bessere Auslastung erzielt werden. Jedoch können nun keine
Garantien mehr über die Reihenfolge, Zuverlässigkeit sowie die einem Teilnehmer zur
Verfügung stehende Übertragungsrate gegeben werden.
Diese Probleme können jedoch teilweise in höheren Protokollschichten (z.B. durch
Nummerierung und Umsortieren der Pakete beim Empfänger) behandelt werden.
Bei der kabellosen Datenübertragung teilen sich alle Teilnehmer ein gemeinsames Me-
dium, nämlich die Trägerfrequenzen des verwendeten Funkprotokolls. Eine Vermitt-
lung von einzelnen Leitungen scheidet prinzipbedingt aus, da es nicht möglich ist,
einzelne Teilnehmer am Senden auf einer Frequenz zu hindern. Daher bietet sich die
Verwendung eines paketvermittelten Übertragungsprotokolls für kabellose Netzwerke
besonders an.
2.1.2. Frequenzspreizung
PSD (dBm) PSD (dBm)
F F
2 MHz 250kHz
Abbildung 2.1.: Frequenzspreizung mit dem FHSS -Verfahren (Frei nach Farahani)
8
2.1. Grundlagen der kabellosen Übetragung
PSD (dBm) PSD (dBm)
F F
250kHz 2MHz
Abbildung 2.2.: Frequenzspreizung mit dem DSSS -Verfahren (Nach Farahani)
Bei der Verwendung von kabellosen Übertragungsprotokollen kann es zu einer Viel-

zahl von Störungen kommen. Übliche Störquellen sind andere Protokolle, die im selben
Band arbeiten, oder elektrische Geräte, die durch ihre Abstrahlung den Funkverkehr
stören1 . Aber auch auf Grund von Mehrwegeausbreitung kann es zu Problemen kom-
men.
Da diese Störungen meist nur auf einzelnen Frequenzen vorliegen, kann mit Hilfe der
Frequenzspreizung der Einfluß von Störungen reduziert werden. Die Idee ist, nicht mit
hoher Leistung auf einer einzelnen Frequenz zu senden, sondern die Leistung auf einen
breiteren Frequenzbereich zu verteilen. Liegt nun eine Störung auf einer einzelnen
Frequenz vor, kann das Nutzsignal trotzem noch erfolgreich empfangen werden.
2.1.2.1. FHSS: Frequency Hoping Spread Spectrum
Bei dem FHSS-Verfahren handelt es sich um die einfachste Möglichkeit, ein Signal zu
spreizen. Hierbei wird einfach nach einer bestimmten Zeiteidauer die Sendefrequenz
gewechselt, so dass eine Spreizung über den Zeitverlauf erreicht wird. [Tofa05]
2.1.2.2. DSSS: Direct Sequence Spread Spectrum
Bei dem DSSS-Verfahren wird das Nutzsignal über einen breiten Frequenzbereich auf-
gefächert. Hierzu wird das Nutzsignal mit einem Spreizkode multipliziert. Beim Emp-
fang teilt der Empfänger nun das empfangene Signal durch diesen Spreizcode und
1
Insbesondere sind hier Mikrowellengeräte zu nennen, die im 2.4-GHz-Band arbeiten.
9
2. Grundlagen
erhält so das ursprüngliche Signal. Störungen werden hingegen durch die Operation
deutlich erkennbar und können einfach ausgefiltert werden. [Tofa05] [Fara08]
2.1.2.3. FHSS vs. DSSS
FHSS besitzt gegenüber DSSS den Vorteil, dass es mit geringerem Aufwand realisiert
werden kann. Dies wird jedoch mit einem höheren Aufwand in der Software erkauft:
Kommt es auf einer Frequenz zu einer Störung, so geht oft das aktuell gesendete Daten-
paket verloren. Dies muss von der Software erkannt werden. Eine erneute Übertragung
des verlorenen Paketes ist erforderlich.
DSSS ist im Vergleich zu FHSS weniger anfällig gegenüber schmallbandigen Störungen,

da diese komplett ausgefiltert werden können, wohingegen es beim FHSS-Verfahren zu
Paketverlusten kommen kann. Liegt jedoch eine breitbandige Störung vor, so ist mit
FHSS meist noch eine Kommunikation – wenn auch mit geringerer Übertragungsrate –
möglich, wenn diese mit dem DSSS-Verfahren bereits zum Erliegen gekommen ist.
Da das DSSS-Verfahren die Gesamtleistung auf ein breites Spektrum auffächert, verur-
sacht es weniger Störungen bei anderen Anwendungen, die im selben Frequenzbereich
arbeiten. Für diese Anwendungen sieht das Signal aus wie Hintergrundrauschen und
kann einfach ausgefiltert werden.
Abschließend bleibt zu sagen, dass jedes der beiden Verfahren eigene Vor- und Nach-
teile besitzt, und dass je nach Anwendung entschieden werden muss, welches Verfahren
besser geeignet ist.
2.2. Java
Java ist eine von Sun Microsystems entwickelte Technologie zur platformunabhängi-
gen Erstellung von Programmen. Sie besteht aus einer Programmiersprache, die eben-
falls den Namen Java trägt, einem Compiler (javac) sowie der Java-Laufzeitumgebung
(Java-Runtime-Environment - JRE ). Die Java-Laufzeitumgebung besteht aus einer
virtuellen Maschine, die die kompilierten Programme ausführt. Dies bietet den Vor-
teil, dass bei einem Wechsel der Host-Plattform (also z.B. von Windows auf Linux
oder MacOS ) bestehende Programme nicht neu übersetzt werden müssen. [Ulle09]
10
2.3. Python
2.2.1. Programmiersprache
Java ist eine statisch typisierte, objektorientierte Programmiersprache. Aufgrund der
von C entlehnten Syntax erinnert Java auf den ersten Blick an C++. Bei genauerer Be-
trachtung unterscheiden sich diese beiden Sprachen jedoch stark. So bietet Java im Ge-
gensatz zu C++ keine Mehrfachvererbung, sondern verwendet sogenannte Interfaces.
Java wird mit einer großen Standardbibliothek ausgeliefert, die für sehr viele Standard-
aufgaben (z.B. Threadverwaltung, Netzwerkkommunikation, GUI -Entwicklung2 oder
typische Datenstrukturen wie Listen und Hashmaps) bereits eine passende Lösung
mitbringt. Durch den integrierten Paketmechanismus wird darüber hinaus die über-
sichtliche Gliederung des Quelltextes in Unterdateien ermöglicht.
Aufgrund der statischen Typisierung und der genau definierten Laufzeitumgebung
eignet sich Java besonders gut zur Erstellung von zuverlässigen und fehlerarmen Pro-
grammen. Werden konsequent Interfaces verwendet und typunsichere Downcasts ver-
mieden, so können die meisten Fehler bereits durch den Compiler erkannt und ab-
gefangen werden. Kann ein solches Programm ohne Fehler und Warnungen kompi-
liert werden, besteht eine hohe Chance, dass auch Laufzeitfehler vermieden werden.
[Ulle09] Insbsondere wenn mehrere Teilaspekte eines Programms von verschiedenen
Programmierern umgesetzt werden, ist die Verwendung von klar definierten Schnitt-
stellen (Interfaces) besonders wichtig, da nur so eine korrekte Funktionalität nach dem
Zusammensetzen der einzelnen Teile gewährleistet werden kann. Diese Vorgehensweise
nennt man auch Design by Contract. Java bietet eine Reihe von Sprachkonstrukte, um
Design by Contract zu unterstützen. [Elie00]
2.3. Python
Python ist eine moderne, leicht zu erlernende objektorientierte Skriptsprache 3 , die
mittlerweile unter fast jedem UNIX -artigen Betriebssystem wie Linux, MacOS oder
BSD zum Lieferumfang gehört. Darüber hinaus sind auch fertige Pakete für Windows
verfügbar. Python eignet sich daher besonders zum Schreiben von kleinen bis mittel-
großen Skripten4 . [Foun10]
2
GUI: Graphical User Interface, dt. graphische Benutzerschnittstelle.
3
Programmiersprache, bei der Programme nicht kompiliert, d.h. in Maschinencode übersetzt, son-
dern interpretiert werden.
4
Programme, die nicht kompiliert sondern interpretiert werden.
11
2. Grundlagen
In dieser Diplomarbeit wird Python für die Interaktion mit dem Betriebssystem einge-
setzt, wenn diese Aufgaben in Java entweder gar nicht oder nur sehr schwierig zu lösen
wären. Beispiele hierfür sind die automatische Erkennung von USB -Geräten oder der
Zugriff auf den seriellen Port. Da Python eine sehr kompakte und verständliche Imple-
mentierung von Programmcode zulässt, wurde in dieser Diplomarbeit weitestgehend
auf Beispiele in Pseudocode verzichtet, und statt dessen lauffähige Python-Programme
zu verwenden. Dies ist nicht nur eindeutiger, sondern bietet gleichzeitig den Vorteil,
dass die meisten Programmbeispiele direkt in lauffähige Programme übernommen wer-
den können.
2.4. Corba
Corba (Common Object Request Broker Architecture) ist eine objektorientierte Midd-
leware zur Verteilung von Objekten auf verschiedenen Rechnern innerhalb eines Netz-
werkes. Das besondere hierbei ist, dass Corba nicht an eine bestimmte Programmier-
sprache gebunden ist. Die einzelnen Objekte bzw. Komponenten können hierbei in je-
der beliebigen Programmiersprache implementiert werden, die eine Corba-Anbindung
besitzt. [TavS07] Im Rahmen dieser Diplomarbeit ist diese Programmiersprachenu-
nabhängigkeit sehr wichtig, da bestimmte Teile (z.B. die Graphische Oberfläche für
Mobiltelefone oder die Ansteuerung des USB-Sticks) nicht in Java realisiert werden
können, und statt dessen auf C++ sowie Python ausgewichen werden muss.
12
3. Stand der Technik
3.1. Einleitung
In diesem Kapitel wird der Stand der Technik von kabellosen Patientenüberwachungs-
technologien untersucht. Hierzu wird zunächst in Abschnitt 3.2 allgemein eine Reihe
von potentiell geeigneten Übertragungsprotokollen vorgestellt und jeweils kurz disku-
tiert, ob und wie gut diese als Basistechnologie für die Lösung der Problemstellung
dieser Diplomarbeit geeignet sind. Im darauf folgenden Abschnitt 3.3 wird dann die ak-
tuelle Marktsituation fertiger Produkte, die zur Überwachung von Patienten in einem
MANV -Szenario in Frage kommen, vorgestellt und die Eignung dieser Produkte dis-
kutiert. Den Abschluss dieses Kapitels bildet Abschnitt 3.4, in dem kurz auf ähnliche
Projekte eingegangen wird, die momentan an anderer Stelle in Arbeit sind.
3.2. Kabellose Übertragungsprotokolle

In diesem Abschnitt werden die gängigsten Funkprotokolle kurz vorgestellt. Insbeson-
dere wird erläutert, inwieweit das entsprechende Protokoll als Grundlage für das zu
entwickelnde Sensornetz geeignet ist. Kommt diese Untersuchung zu einem positiven
Ergebnis, wird eine genauere Betrachtung der Störsicherheit vorgenommen. Hierbei
wird insbesondere auf die Störungen durch WLAN - und Bluetooth-Geräte eingegan-
gen, da diese Technologien mittlerweile eine weite Verbreitung in Mobiltelefonen gefun-
den haben, und somit eine Störung durch die Mobiltelefone der Unfallopfer und Helfer
zu erwarten ist. Außerdem ist geplant, ein WLAN -Netzwerk für die Koordination
des Überwachungssystems einzusetzen, so dass auch hier auf gegenseitige Störungen
geachtet werden muss.
Mit Ausnahme von DECT und GSM bzw. UMTS ist diesen Protokollen gemein, dass
sie Frequenzen aus dem ISM -Band1 verwenden.
3.2.1. DECT
Bei DECT ( Digital Enhanced Cordless Telecommunications“ ) handelt es sich um
”
einen Standard, der vor allem zur Anbindung von Schnurlostelefonen an eine Basis-
station gedacht ist2 .
In Europa wird ein eigenes Frequenzband im Bereich von 1800 bis 1900 MHz ver-
wendet, in dem 10 Kanäle zur Verfügung stehen. Pro Kanal können maximal 32 kbit
Nutzdaten pro Sekunde übertragen werden. Die maximal zulässige Sendeleistung be-
trägt 250 mW, womit eine Reichweite von ca. 30-50 m in Gebäuden und ca. 300 m im
Freien realisiert werden kann. Jede Basisstation kann bis zu 6 Geräte anbinden.
Beim Einsatz außerhalb Europas muss bedacht werden, dass die Verwendung der Fre-
quenzen von 1800 bis 1900 MHz hier evtl. nicht zulässig ist. In diesem Fall muss auf
das ISM -Band ausgewichen werden, welches mit anderen Anwendungen geteilt werden
muss. [ETSI06]
DECT bietet eine optionale Verschlüsselung der Nutzdaten, welche jedoch im Jahr
2009 gebrochen wurde, so dass DECT mittlerweile als unsicher gelten muss. [LSTW+ 09]
Aufgrund der geringen Nutzdatenmenge sowie der Einschränkung auf 6 Teilnehmer ist
DECT für den Einsatz als Sensornetz-Protokoll nicht geeignet.
3.2.2. GSM/UMTS
GSM sowie der Nachfolgestandard UMTS bilden die Grundlage der aktuellen Mobil-
funktechnologie. Es handelt sich um eine zellenbasierte Technologie, die im Falle von
GSM Frequenzen im 900 MHz- und im 1,8 GHz-Band verwendet. Für UMTS stehen
1
Mehrere Frequenzbänder, für deren Benutzung eine allgemeine Betriebserlaubnis ausreicht.
2
Es gibt jedoch auch weitere Anwendungen wie z.B. Babyfon.
14
insgesamt 19 Bänder im Bereich von 777 MHz bis 2,2 GHz zur Verfügung. Die Kom-
munikation findet zwischen einem Mobiltelefon und einer Basisstation statt, wobei die
maximale Sendeleistung 2 W (im Falle von GSM) bzw. 250 mW (im Falle von UMTS)
beträgt. Mit GSM -900 können im Freien bei Sichtkontakt Reichweiten bis zu 35 km
erreicht werden. [Benk07]
Die Frequenzen für GSM und UMTS sind fest dem jeweiligen Netzbetreiber zuge-
ordnet. Der Preis für einen Frequenzbereich ist sehr hoch. Bei der Versteigerung der
UMTS -Frequenzen im Jahr 2000 wurden Preise von bis zu 8 Milliarden Euro pro
Lizenz erreicht. [Tage00]
3.2.3. WLAN
WLAN oder Wi-Fi bezeichnet den heute gängigen Standard eines Funkprotokolls zum
Aufbau von kabellosen lokalen Netzwerken. Es gibt mehrere Versionen des Standards,
die verbreitetsten sind IEEE 802.11a, IEEE 802.11b/g und IEEE 802.11n. [IEEE07]
Es sind zwei Betriebsmodi möglich:
• Infrastruktur-Modus: Eine zentrale Station ( Access-Point“ ) dient als Basissta-

”
tion für alle weitere Stationen. Jede Station, die am Netzwerk teilnimmt, muss
hierzu die Signale des Access-Points empfangen können.
• Ad-hoc-Modus: Diese Betriebsmodus kommt ohne zentrale Komponente aus. Es

wird eine Peer-to-Peer -Verbindung zwischen allen am Netzwerk teilnehmenden
Stationen aufgebaut. Dieser Modus funktioniert nur dann gut, wenn sich alle
Stationen gegenseitig empfangen können. Wenn dies nicht der Fall ist, muss
weitere Aufwand betrieben werden, um Kollisionen im Netzwerk zu vermeiden
(vgl. RTS/CTS in Abschnitt 3.2.3.4).
Der Infrastruktur-Modus bietet gegenüber dem Ad-Hoc-Modus klare Vorteile: Im Ge-

gensatz zum Ad-hoc-Modus ist es nicht notwendig, dass alle Stationen sich gegensei-
tig empfangen müssen; es reicht aus, wenn der Acces-Point empfangen werden kann.
Hierdurch kann der Datenverkehr im Netzwerk besser koordiniert werden als im Ad-
Hoc-Modus.
Es werden verschiedene Datenübertragungsraten unterstützt. Standardmäßig wird im-

mer die größtmögliche Übertragungsrate gewählt, die störungsfrei verwendet werden
15
kann. Je weiter sich die Stationen voneinander entfernen, desto geringer wird die Über-
tragungsrate, bis schließlich die niedrigste mögliche Übertragungsrate von 1 MBit/sec
erreicht ist.
Es gibt eine ganze Reihe von Unterstandards, die sich durch zulässige Frequenzen,
Übertragungsraten und Sendeleistung unterscheiden. Teilweise ist auch Kanalbünde-
lung vorgesehen. Nicht jeder Standard kann in jedem Land eingesetzt werden, und die
meisten Endgeräte unterstützen nur eine Teilmenge dieser Standards. Hier sollen nur
die wichtigsten drei Standards erwähnt werden.
3.2.3.1. IEEE 802.11b
Bei IEEE 802.11b handelt es sich um den ältesten WLAN -Standard mit praktischer
Bedeutung, der bereits 1999 spezifiziert wurde. Dieser Standard wird praktisch von
jedem WLAN -fähigen Endgerät unterstützt. Die Kommunikation findet im ISM -Band
im Bereich von 2.4 GHz statt. Je nach Land sind 11-14 Kanäle möglich, die sich jedoch
teilweise überlappen. Dies führt dazu, dass maximal 3 Netzwerke in einem Gebiet ohne
Störungen gleichzeitig betrieben werden können. Die maximale Sendeleistung beträgt
100 mW. Es sind Übertragungsraten von 5,5 bis 11 MBit/sec (brutto) möglich. Die
Nettoübertragungsrate beträgt ca. 50% der Bruttorate; die restliche Übertragungsrate
wird für die Koordination des Datenverkehrs benötigt. Es sind Reichweiten bis 40 m
(Innen) bzw. 100 m (Im Freien) möglich[KuDMK08].
3.2.3.2. IEEE-802.11g
Der IEEE-802.11g-Standard stellt eine Erweiterung des IEEE-802.11b-Standards dar.

Wesentliche Neuerung ist eine Erhöhung der Bruttodatenrate von 11 auf 54 MBit/sec,
von denen netto ca. 40% zur Verfügung stehen. Erwähnenswert ist, dass die beiden
Standards interoperabel sind, d.h. ein IEEE-802.11b-Gerät kann einem IEEE 802.11g
Netzwerk beitreten und umgekehrt. Dies ist auch der Grund, weshalb dieser Standard
momentan am weitesten verbreitet ist.
3.2.3.3. IEEE 802.11a
Der IEEE 802.11a Standard verwendet Frequenzen im 5-GHz-Bereich. Er ist daher

inkompatibel zum IEEE 802.11b/g Standard. Je nach Frequenzband sind Sendeleis-
tungen zwischen 30 mW und 1000 mW zulässig. Mit dem passenden Frequenzband
16
sind daher höhere Reichweiten als mit dem IEEE-802.11b/g-Standard möglich. Die
Bruttodatenrate beträgt bis zu 54 MBit/sec. Ein Vorteil des IEEE-802.11a-Standards
ist die Kommunikation im 5 GHz Bereich. Aktuell ist dieser Bereich noch wenig ge-
nutzt, so dass dort oft ein Betrieb mit weniger Störungen als im 2,4 GHz-Bereich
möglich ist. Es ist jedoch zu erwarten, dass sich dies in Zukunft ändern wird.
3.2.3.4. Störsicherheit
IEEE 802.11 verwendet den CSMA/CA3 -Algorithmus zur Kontrolle des Medienzu-
griffs. Möchte eine Station senden, so muss diese zunächst für einige Zeit lauschen,
ob der zu verwendende Kanal auch wirklich frei ist (Energy-Detection). Ist der Kanal
belegt, so wartet sie eine zufällige Zeit, bis sie erneut versucht, auf den Kanal zuzugrei-
fen. Wichtig hierbei ist, dass es bei Funkprotokollen nicht möglich ist, eine Kollision zu
erkennen4 .um eine bestehende Übertragung abzubrechen, wie es z.B. bei Ethernet der
Fall ist. Zur Vermeidung von Kollisionen kann bei IEEE 802.11 daher zusätzlich zu
CSMA/CA eine koordinierte Sendefreigabe eingesetzt werden. Hier kommt RTS/CTS
zum Einsatz: Möchte eine Station ein großes Datenpaket senden, so sendet diese zuerst
ein RTS -Paket5 an den Empfänger, welcher dies mit einem CTS -Paket6 quittiert. Erst
wenn das CTS -Paket empfangen wurde, wird mit der Übertragung des eigentlichen
Datenpakets begonnen. Für alle andere Stationen im Netzwerk ist nun klar, dass sie
bis zur abgeschlossenen Übertragung dieses Paketes nicht auf das Netzwerk zugreifen
dürfen.
Bei dem Einsatz der in IEEE 802.11i definierten Verschlüsselungsverfahren (WEP 7 ,

WPA oder WPA2 ) werden lediglich die Nutzdaten des Paketes verschlüsselt. Die
RTS/CTS -Pakete können weiterhin erkannt werden, so dass die Kollisionsvermeidung
auch dann funktioniert, wenn die Pakete nicht entschlüsselt werden können (Diese Si-
3
Carrier Sense Multiple Access with Collision Avoidance. dt.: Gemeinsamer Medienzugriff mit Kol-
lisionsvermeidung.
4
Dies liegt an der Tatsache, dass für Senden und Empfangen der selbe Transceiver verwendet wird.
Daher kann ein Knoten entweder nur Senden oder nur Empfangen. Für das Feststellen einer
Kollision müsste er jedoch beide Operationen gleichzeitig durchführen können.
5
Ready to send
6
Clear to send
7
Die Sicherheit von WEP ist bereits seit einigen Jahren kompromittiert. Es sollte nicht mehr ver-
wendet werden.
17
tuation ist z.B. in Mietshäusern oft anzutreffen, wo mehrere unterschiedliche WLAN s

auf dem selben Kanal senden). Jedoch geht dies mit einer reduzierten Übertragungs-
rate für die einzelnen Netzwerke einher.
Zusätzlich wird das in Abschnitt 2.1.2.2 beschriebene DSSS -Verfahren eingesetzt, um

schmallbandige Störungen auszufiltern.
Ein häufiges Problem ist die Störung durch Bluetooth, da Bluetooth und WLAN -Geräte
oft aufeinandertreffen (z.B. weil an einem Notebook Bluetooth-Maus und -Tastatur ver-
wendet werden oder weil ein PDA z.B. Schnittstellen für beide Protokolle besitzt). Wie
in Abschnitt 3.2.4.2 genauer erläutert, besitzt Bluetooth 79 Kanäle, welche bis zu 1600
mal pro Sekunde gewechselt werden. Problematisch ist nun, dass 22 dieser Kanäle in
das IEEE 802.11b/g-Frequenzspektrum fallen. Durch den häufigen Kanalwechsel, die
geringeren Übertragungsraten sowie die Möglichkeit, den Wechsel auf belegte Kanä-
le zu vermeiden, ist diese Störung für Bluetooth deutlich unproblematischer als für
WLAN. Je nach Implementierung kann dies zu einer deutlichen Reduktion der Über-
tragungsrate des WLANs führen; außerdem kann die Wartezeit für das erfolgreiche
Senden von Paketen deutlich ansteigen. Dies hat die IEEE dazu veranlasst, eine ei-
gene Arbeitsgruppe zu gründen, die sich mit dem Problem der gegenseitigen Störung
von WLAN und Bluetooth beschäftigt. Die Ergebnisse dieser Arbeitsgruppe spiegeln
sich im Standard IEEE 802.15.2 wider.
3.2.3.5. Leistungsaufnahme
Der Energiebedarf für WLAN ist relativ hoch. Beispielsweise benötigt der vom Herstel-
ler Broadcom als besonders energiesparend bezeichnete Chip BCM4326 bis zu 100 mA
zum Empfangen und zwischen 141 und 190 mA zum Senden. [BROA06].
3.2.4. WPAN: Wireless Personal Area Networks

Als WPANs ( Wireless Personal Area Networks“) werden kabellose Kleinnetzwerke
”
bezeichnet, die dazu dienen, wenige Geräte über kurze Entfernungen (mehrere Me-
ter) miteinander zu verbinden. Sie dienen als Ersatz von Kabelverbindungen zur An-
bindung von Peripherie an Computergeräte (z.B. zur Verbindung von Headsets mit
Mobiltelefonen oder von Tastatur und Maus mit einem PC ).
18
3.2.4.1. IEEE 802.15
Der IEEE 802.15 -Standard behandelt Wireless Personal Area Networks. Er ist in
mehrere Unterstandards aufgeteilt:
• IEEE 802.15.1: Bluetooth 1.2
• IEEE 802.15.2: Interoperabilität zwischen IEEE 802.15 (WPAN ) und IEEE

802.11 (WLAN )
• IEEE 802.15.3: WPANs mit hohen Datenübertragungsraten (20 MBit/sec und

höher)
• IEEE 802.15.4: WPANs mit niedriger Datenübertragungsraten
Für diese Arbeit sind vor allem der Bluetooth- und der ZigBee-Standard interessant.
3.2.4.2. IEEE 802.15.1: Bluetooth
Bluetooth wurde ursprünglich durch den Mobilfunkhersteller Ericcson als Ersatz für
RS-232 -Verbindungen entwickelt. Die Entwicklung des Bluetooth-Standards erfolgt
heute unter der Regie der Bluetooth Special Interest Group (Bluetooth SIG). Versi-
on 1.1 des Bluetooth-Standard wurde von der IEEE als IEEE 802.15.1-2002 über-
nommen. Nach Veröffentlichen einer weiteren Version IEEE 802.15.1-2005, die dem
Bluetooth-1.2 -Standard entspricht, wurde von der IEEE jedoch beschlossen, nicht wei-
ter mit der Bluetooth SIG zu kooperiern, so dass es keine weiteren Versionen des IEEE-
802.15.1 -Standards geben wird. Aktuell ist Version 4.0 des Bluetooth-Standards, wobei
jedoch die meisten Geräte nur ältere Standards (typischerweise 2.0 oder 2.1) unter-
stützen. [SIG10]
Die wichtigsten Meilensteine der Bluetooth-Entwicklung können folgendermaßen zu-

sammengefasst werden:
• Bluetooth 1.1 : Erste Version von praktischer Relevanz. Entspricht IEEE 802.15.1-
2002.
• Bluetooth 1.2 : Entspricht IEEE 802.15.2-2005. Bringt einige Verbesserungen ge-

genüber der Version 1.1 wie z.B. schnelleres Finden von Endgeräten (Discovery),
19
höhere Störsicherheit durch die Verwendung von AFH 8 , Übertragungsraten bis

721 kbit/sec.
• Bluetooth 2.0 : Einführung des EDR 9 -Modus mit bis zu 3,0 MBit/sec (2,1 MBit/-
sec netto).
• Bluetooth 2.1 : Vereinfachung des Pairings (vgl. Abschnitt 3.2.4.2.1) durch Ein-
führung von SSP10 , Verbesserung der Sicherheit durch explizite Aushandlung
der Verschlüsselung.
• Bluetooth 3.0 : Einführung eines Hochgeschwindigkeits-Datenkanals auf Basis
von IEEE 802.11 (vgl. 3.2.3) mit bis zu 24 MBit/sec., verbessertes Powermana-
gement, Einführung von verbindungslosen Datentelegrammen (Unicasts).
• Bluetooth 4.0 : Einführung des Blueetooth Low Energy Standards (vgl. 3.2.4.4).
3.2.4.2.1 Pairing
Bei der Entwicklung von Bluetooth wurde ein besonderes Augenmerk auf Datensi-
cherheit gelegt. Dies liegt daran, dass über Bluetooth in vielen Fällen auf sensible
Daten (z.B. der Inhalt von Mobiltelefonen, Telefongespräche die über Headsets ge-
führt werden etc.) zugegriffen werden kann. Bluetooth verwendet hierfür das Konzept
des Pairings, also der Paarung. Bevor zwei Bluetooth-Geräte miteinander kommuni-
zieren können, müssen sie gepaart werden. Um dies durchzuführen, muss zunächst die
Identität der zu paarenden Geräte bestätigt werden. Hierzu gibt es zwei verschiedene
Verfahren:
• Legacy: Bis Bluetooth 2.0 muss an beiden Geräten eine identische PIN eingege-
ben werden. Die PIN ist beliebig und kann bis zu 16 Byte lang sein.
• Secure Simple Pairing: Bluetooth 2.1 definiert neben der PIN -Eingabe weitere
Verfahren zum Paaren von Geräten. z.B. kann bei dem Just-Works-Verfahren
die PIN komplett ausgelassen werden11 oder es wird an beiden Geräten eine
Nummer angezeigt, deren Gleichheit einfach nur noch bestätigt werden muss.
8
Adaptive frequency hopping spread spectrum
9
Enhanced Data Rate
10
Secure Simple Pairing
11
Die Verbindung erfolgt trotzdem verschlüsselt, allerdings sind nun Man-in-the-middle-Angriffe
möglich.
20
Ist diese Überprüfung erfolgreich, generieren beide Geräte einen kryptographischen

Schlüssel und die weitere Kommunikation erfolgt verschlüsselt. Sobald zwei Geräte
gepaart wurden, können sie miteinander kommunizieren, ohne eine erneute Paarung
durchführen zu müssen. [SIG10]
3.2.4.2.2 Reichweite
Bluetooth definiert drei verschiedene Klassen von Geräten mit jeweils unterschiedlicher
Reichweite:
• Klasse 1: maximale Sendeleistung: 100 mW, Reichweite ca. 100 m
• Klasse 2: maximale Sendeleistung: 2,5 mW, Reichweite ca. 10 m
• Klasse 3: maximale Sendeleistung: 1 mW, Reichweite ca. 1 m
Diese Einteilung dient unter anderem der Datensicherheit. Da z.B. ein Headset in der
Regel nur die Distanz zwischen Kopf und Tasche des Anwenders überbrücken muss,
reicht hier die Verwendung eines Klasse-2-Gerätes. Durch die Einschränkung der Sen-
deleistung wird nicht nur die Akkulaufzeit der Geräte erhöht, sondern auch die Wahr-
scheinlichkeit, dass ein Angreifer die gesendeten Daten empfangen kann, verringert.
Es bleibt allerdings festzustellen, dass mit Hilfe von geeigneten Antennen die Reich-
weite von Bluetooth signifikant gesteigert werden kann. So lassen sich mit Hilfe der
BlueSniper -Richtantenne selbst mit Klasse-2-Geräten Distanzen von über 800 m über-
brücken. [Cheu05]
3.2.4.2.3 Übertragungsrate
Die Übertragungsrate von Bluetooth hängt natürlich von Faktoren wie der Verbin-
dungsqualität und der Entfernung ab. Der Standard definiert folgende maximale Da-
tenübertragungsraten:
• Bluetooth 1.1 : 721 kbit/sec
• Bluetooth 2.0 : 3.0 MBit/sec
• Bluetooth 3.0 : 24 Mbit/sec (über einen IEEE-802.11 -Kanal)
21
3.2.4.2.4 Störsicherheit
Bluetooth verwendet einen Frequenzbereich von 2,402 - 2,480 GHz. Innerhalb dieses
Bereiches werden 79 verschiedene Kanäle definiert. Zur Minimierung von Störungen
wird sogenannts Channel-Hopping verwendet. Hierbei wird der verwendete Kanal bis
zu 1600mal pro Sekunde gewechselt. Mit dem Bluetooth-1.2 -Standard wurde das ver-
besserte AFH 12 -Verfahren eingeführt, welches gestörte Kanäle erkennt und deren Ver-
wendung vermeidet.
Insbesondere WLAN -Netzwerke und Bluetooth-Netzwerke stören sich gegenseitig. Wie

in Abschnitt 3.2.3.4 bereits erläutert, wird WLAN deutlich stärker durch Bluetooth
gestört, als dies umgekehrt der Fall ist. Tritt eine Störung auf einem Kanal auf, ver-
sucht das AFH -Verfahren die Verwendung dieses Kanals zu vermeiden. Hierdurch sinkt
zwar die erreichbare Datenübertragungsrate, eine Kommunikation kann allerdings wei-
ter stattfinden.
Es ist festzustellen, dass Bluetooth – insbesondere im Vergleich zu WLAN – recht ro-
bust gegenüber Störungen ist.
3.2.4.2.5 Anzahl Teilnehmer
Sobald zwei oder mehr Geräte miteinader verbunden sind, formen diese ein sogenanntes
Piconet. In einem Piconet können sich bis zu 255 Geräte befinden, wobei ein Gerät
eine der folgenden beiden Rollen hat:
• Master: Der Master koordiniert die Kommunikation im Netzwerk. Hierzu gibt er

jeweils Zeitslots vor, in denen Daten gesendet werden dürfen. Pro Piconet kann
es nur einen Master geben.
• Slaves: Slaves bekommen vom Master die Erlaubnis, Daten zu senden. Es kön-
nen immer nur 7 Slaves gleichzeitig aktiv sein. Aktive Slaves müssen permanent
empfangsbereit sein, um die Anforderungen des Masters zu empfangen.
Da nur 7 Slaves gleichzeitig aktiv sein dürfen, befinden sich alle übrigen Slaves im so-
genannten Parkzustand“. Erst wenn ein Slave vom Master explizit dazu aufgefordert
”
12
Adaptive frequency-hopping spread spectrum
22
wird, darf er in den aktiven Zustand wechseln.
Um die Anzahl der aktiven Geräte in einem Netzwerk zu erhöhen, gibt es die Möglich-
keit, ein sogenanntes Scatternet zu bilden. Hierbei handelt es sich um die Verbindung
von mehreren Piconets mit jeweils maximal 8 Geräten zu einem größeren Verbund.
Hierbei leitet jeweils ein Gerät, das mit jeweils 2 der Piconetze verbunden ist, Pakete
vom einen Netz in das andere Netz über. Im Vergeleich zu Piconetzen kann hiermit
eine deutlich höhere Anzahl von Geräten unterstützt werden. Durch die Verkettung
der Netze kann es jedoch vorkommen, dass einzelne Pakete eine relativ hohe Anzahl
von Piconetzen durchqueren müssen, um ihr Ziel zu erreichen.
3.2.4.2.6 Leistungsaufnahme
Die genaue Leistungsaufnahme eines Bluetooth-Gerätes hängt von einigen Faktoren

ab. Den größten Einfluß hat die Rolle des Gerätes: Die Leistungsaufnahme eines Sla-
ves ist deutlich höher als die des Masters. Dies liegt daran, dass ein Slave immer
empfangsbereit sein muss, ein Master hingegen nur dann, wenn er Daten von einem
Slave angefordert hat. Die Leistungsaufnahme eines Slaves der Klasse 2 beträgt laut
[NeBD06] durchschnittlich 56,63 mW, was bei 3,3 V ca 16,6 mA entspricht. Für Klasse-
1-Geräte ist die Leistungsaufnahme noch höher, da alleine die Sendeleistung schon
100 mW beträgt. Power-Management in Bluetooth-Netzen ist schwierig. Zwar sind
einige Standby-Modi vorgesehen (Hold, Sniff und Park ), allerdings muss dem Master
erst mitgeteilt werden, dass die entsprechende Station für ein bestimmtes Zeitintervall
nicht erreichbar ist. Befindet sich ein Gerät im Standby-Modus, kann es bis zu 3 Sekun-
den dauern, bis es wieder sendebereit ist. Da diese Einschränkungen den Betrieb von
Geräten mit geringer Energieversorgung praktisch unmöglich machen, wurde von der
Bluetooth-SIG ein eigener Standard für diese Geräteklasse mit dem Namen Bluetooth
”
Low Energy“ verabschiedet (siehe Abschnitt 3.2.4.4).
3.2.4.3. IEEE 802.15.4: ZigBee
Bei IEEE 802.15.4 handelt es sich um einen Standard für zuverlässige, drahtlose Kom-
munikation mit niedriger Übertragungsrate bei hoher Reichweite, niedriger Leistungs-
aufnahme und geringem Stückpreis.
23
APL (Anwendung)
ZigBee
SEC (Security)
NWK (Vermittlung)
MAC (Sicherung)
IEEE 802.15.4
PHY (Bitübertragung)
Abbildung 3.1.: ZigBee-Stack (Quelle: Wikipedia)
Eine typische Anwendung hierfür sind drahtlose Sensoren: Zum einen ist eine möglichst
hohe Laufzeit gewünscht, da es oft nur schwer möglich ist, Batterien für aufgestellte
Sensoren auszutauschen. Wenn die Sensoren dazu noch in einer hohen Stückzahl ver-
teilt werden sollen, sind möglichst geringe Hardwarekosten notwendig.
Zu beachten ist, dass ZigBee nicht das selbe ist wie IEEE 802.15.4.
IEEE 802.15.4 definiert lediglich die unteren beiden Schichten des OSI-Modells, also
die Sicherungs- (MAC ) und die physische Schicht (PHY ).Bei ZigBee handelt es sich
hingegen um einen kompletten Protokollstapel, der die beiden Schichten von IEEE
802.15.4 um 3 weiter Schichten, namentlich Vermittlungs-, Verschlüsslungs und An-
wendungsschicht ergänzt. [Alli07]
Es ist möglich, einen IEEE 802.15.4 -Transceiver ohne den Einsatz von ZigBee zu
betreiben. Die Verwendung von ZigBee bietet jedoch den Vorteil, dass alle netzwer-
krelevanten Aufgaben wie Routing, Übertragungssicherung und Adressierung von An-
wendungen bereits durch den ZigBee-Stack erfolgen und daher nicht vom Entwickler
implementiert werden müssen. Die Verwendung von durch die ZigBee-Alliance zer-
24
tifizierten Modulen bietet zudem den Vorteil der Interoperabilität mit Modulen von
anderen Herstellen, sofern diese ZigBee-zertifiziert sind.
3.2.4.3.1 Netzstruktur
Bei ZigBee gibt es zwei Klassen von Geräten:
• FFD: Full Function Devices: Diese Geräte implementieren den vollen ZigBee-
Stack. Hierzu ist es notwendig, dass diese immer erreichbar sind; die Verwendung
des Energiesparmodus ist nicht möglich.
• RFD: Reduced Function Devices: Diese Geräte implementieren nur einen Teil
des ZigBee-Stacks. Sie müssen nicht immer ereichbar sein und können den Ener-
giesparmodus benutzen.
Es ist lediglich die Kommunikation zwischen RFD und FFD sowie zwischen zwei FFDs
möglich. Zwei RFDs sind nicht in der Lage, direkt miteinander zu kommunizieren, son-
dern müssen den Umweg über ein FFD nehmen.
Neben den Geräteklassen unterscheiden sich die einzelnen Stationen durch die Rol-
len, die sie im Netzwerk einnehmen:
• Koordinator (ZC ): Der Koordinator ist die zentrale Station im Netzwerk. Er

ist der Knoten, der das Netzwerk errichtet hat und ist für die Kontrolle des
Netzwerks zuständig. In einem Netzwerk kann es immer nur einen Koordinator
geben. Der Koordinator beinhaltet immer auch die Funktionalität eines Routers.
Die Rolle des Koordinators kann nur von einem FFD übernommen werden.
• Router (ZR): Router sind in einem Netzwerk für die Weiterleitung von Paketen
zuständig. Es kann beliebig viele Router in einem Netzwerk geben. Die Rolle
eines Routers kann nur von einem FFD übernommen werden.
• Endknoten (ZED): Alle Geräte, die nicht Koordinator oder Router sind, sind
automatisch Endknoten. Diese leiten keine Pakete weiter und sind immer an
einem Router angemeldet. Es handelt sich hierbei immer um RFDs.
Die Topologie des Netzwerks wird von den Knoten automatisch bestimmt. Können
sich mehrere Router empfangen, so bilden diese automatisch ein vollvermaschtes Netz.
25
ZigBee-Kanal WLAN-Kanal Bluetooth-Frequenz

11 1 -
12 1 -
13 1 -
14 1 2,420 GHz
15 - -
16 7 -
17 7 -
18 7 2,439 GHz
19 7 -
20 7 -
21 - -
22 13 -
23 13 -
24 13 2,471 GHz
25 13 -
26 13 -
Tabelle 3.1.: Überschneidungen zwischen ZigBee, WLAN und Bluetooth-Kanälen
Bei der Zustellung von Paketen wird standardmäßig immer der Pfad mit der besten
Leitungsqualität gewählt.
Durch die geschickte Platzierung von Routern kann ein ZigBee-Netzwerk nahezu be-
liebig ausgeweitet werden, wobei durch die automatische Organisation des Netzwerks
ein hohes Maß an Ausfallsicherheit erreicht werden kann (eine entsprechende Anzahl
an Routern vorrausgesetzt). Problematisch ist jedoch der Ausfall des Koordinators.
Prinzipiell kann jeder Router die Aufgabe des Koordinators übernehmen, jedoch ge-
schieht dies nicht automatisch und muss in der Anwendungslogik erfolgen.
3.2.4.3.2 Störsicherheit
ZigBee verwendet zur Funkübertragung von Paketen den IEEE-802.15.4 -Standard.

Dieser weist große Ähnlichkeiten mit dem IEEE-802.11b-Standard (WLAN, vgl. Ab-
26
schnitt 3.2.3.4) auf: Es werden mehrere Kanäle im 2.4-GHz-Band spezifiziert. In Nord-

amerika stehen 10 weitere Kanäle im 900-MHz-Band zur Verfügung, die allerdings eine
reduzierte Datenrate von 40 kBit/sec zulassen. Darüber hinaus gibt es noch einen Ka-
nal im 868-MHz-Band, der allerdings nur in Europa verwendet werden darf, und bei
dem auch nur 20 kBit/sec verwendet werden können. Zur Übertragung wird auch bei
IEEE 802.15.4 Frequenzspreizung nach dem DSSS -Verfahren betrieben. Zum Medi-
enzugriff wird CSMA/CA verwendet.
Zusätzlich spezifiziert ZigBee in der Vermittlungsschicht (NWK ) eine Reihe von Feh-
lerbehandlungsroutinen: So wird jedes empfangene Paket – mit der Ausnahme von
Broadcasts13 – mit einer Antwort an den Sender quittiert. Erhält der Sender inner-
halb einer bestimmten Zeitspanne keine Antwort, so sendet er das verlorene Paket
erneut. Darüber hinaus gibt es in jedem Datenpaket eine CRC -Prüfsumme, mit deren
Hilfe Übertragungsfehler erkannt werden können. Auch in diesem Fall wird das Pa-
ket erneut übertragen. Hierbei sollte jedoch bemerkt werden, dass ein CRC -Verfahren
keinen Schutz gegen absichtliche Manipulation bietet. Dies kann mit Hilfe der in Ab-
schnitt 3.2.4.3.3 beschriebenen kryptographischen Verfahren verhindert werden.
Ein ZigBee-Netzwerk kann optional ein sogenanntes Beacon (dt. Leuchtfeuer) verwen-
den. Hierbei handelt es sich um ein Paket, das periodisch vom Koordinator ausgesendet
wird. Mit Hilfe dieses Pakets wird die Sendezeit in feste Zeitschlitze eingeteilt. Hiermit
ist es möglich, einzelnen Stationen einen garantierten Zeitschlitz (GTS ) zuzuweisen,
in dem niemand anderes senden darf. Dies ist insbesondere für Echtzeitanwendungen
interessant. Da zum Zeitpunkt des Versendens des Beacons jedoch alle Stationen emp-
fangsbereit sein müssen, ergeben sich Einschränkungen für die Batterielaufzeit. Die
Verwendung von Beacons schützt nicht gegen Störungen durch Nicht-ZigBee-Geräte
wie WLANs oder Bluetooth.
Da eine Nutzung der Kanäle außerhalb des 2,4-GHz-Bandes nicht in jedem Land ge-
stattet ist, sollen im folgenden nur die 15 Kanäle im 2,4-GHz-Band betrachtet werden:
Von den 15 zur Verfügung stehenden ZigBee-Kanälen überschneiden sich 11 Kanä-
13
Rundrufe, also Pakete, die an alle Stationen gleichzeitig verschickt werden.
27
le mit den 3 überschneidungsfreien IEEE-802.11b-Kanälen (Kanal 1, Kanal 6 und

Kanal 11) in Nordamerika. In Europa überschneiden sich sogar 13 ZigBee-Kanäle mit
den IEEE-802.11b-Kanälen Kanal 1, Kanal 7 und Kanal 13 in Europa. Es ist zu erwar-
ten, dass die Störungen auf den Kanälen im Randbereich der IEEE-802.11b-Kanäle
am geringsten – wenn auch nicht komplett ausgeschlossen – sind. Außerdem gibt es
auf 4 Kanälen Überschneidungen mit Bluetooth. Der genaue Zusammenhang ist in
Tabelle 3.1 dargestellt.
Ein ZigBee-Netzwerk ist in der Lage, dynamisch den verwendeten Kanal zu wechseln,
sobald die Störungen auf einem Kanal zu groß werden. Hierzu wird im EEPROM des
ZigBee-Gerätes kein fester Kanal, sondern eine Liste aller erlaubten Kanäle eingestellt.
Dies bedeutet, dass bei der richtigen Konfiguration des ZigBee-Netzwerks ein einzelnes
WLAN durch einen einfachen Kanalwechsel umgangen werden kann. Problematisch
wird es jedoch, wenn mehrere WLANs auf mehreren verschiedenen Kanälen gleichzeitig
auftreten. Hierdurch kann es zu einer signifikaten Abnahme der im ZigBee-Netzwerk
möglichen Übertragungsrate kommen. Eine mögliche Lösung wäre in diesem Falle, die
WLANs auf die WLAN -Kanäle 1, 7 und 13 einzuschränken, so dass für das ZigBee-
Netzwerk die ZigBee-Kanäle 15 und 21 zur ungestörten Verwendung zur Verfügung
stehen. Alternativ können an Stelle der WLAN -Kanäle 7 und 13 die WLAN -Kanäle
6 und 11 verwendet werden, so dass für das ZigBee-Netzwerk die Kanäle 25 und 26
frei werden.
Wenn für das ZigBee-Netzwerk sowieso nur ein Teil der zur Verfügung stehenden
Übertragungsrate benutzt wird und auch die WLANs nur teilweise ausgelastet sind,
ist zu erwarten, dass durch die Verwendung des CSMA/CA-Verfahrens genügend freie
Zeitschlitze gefunden werden können, um selbst bei einer hohen WLAN -Dichte noch
erfolgreich senden zu können.
Die Störungen durch Bluetooth sind als weniger problematisch zu bewerten. Durch
das von Bluetooth verwendeten FHSS -Verfahren besteht selbst im ungünstigsten Fall
(Verwendung von sich überschneidenden Kanälen im ZigBee-Netz, volle Ausschöp-
fung der Übertragungsrate im ZigBee-Netz) nur eine maximale Kollisionswahrschein-
lichkeit von ca. 4% (3 von 79 Frequenzsprüngen – unter der Annahme, dass auch das
ZigBee-Netzwerk in dieser Zeit dreimal den Kanal wechselt). Dies kann von der Zig-
Bee-Fehlerbehandlung durch eine erneute Übertragung des kollidierten Paketes ein-
28
fach behandelt werden. Verwendet das Bluetooth-Netzwerk darüber hinaus das AFH -
Verfahren, ist es in der Lage die Störung zu erkennen und den betroffenen Kanal im
weiteren Verlauf zu meiden.
Eine weitere Quelle von Störungen sind Mikrowellenöfen. Diese verwenden typischer-
weise Frequenzen um die 2540 MHz und können Störungen mit einer Bandbreite von
bis zu 80 MHz und einer Signalstärke von bis zu 30 dBm verursachen. Hierdurch
ergeben sich mögliche Störungen auf den oberen ZigBee-Kanälen. Da gewöhnliche Mi-
krowellenöfen für den Haushaltsgebrauch einen Auslastungsgrad (Duty-Cycle) von bis
zu 50% haben, ergäbe sich schlimmstenfalls eine Halbierung der zur Verfügung ste-
henden Übertragungsrate.[Fara08]
Die letzte zu erwartende Quelle von Störungen geht von DECT -Telefonen aus. Da
diese in Europa jedoch nicht im 2,4-GHz- sondern im 1,8-GHz-Band arbeiten, stellt
dies nur außerhalb der EU ein Problem dar. Hierbei sind schmalbandige Störungen
mit einer Signalstärke von bis zu 30 dBm zu erwarten. Diese können einfach durch
den automatischen Kanalwechsel des ZigBee-Netzwerks umgangen werden.
3.2.4.3.3 Verschlüsselung
ZigBee unterstützt 128-Bit-AES -Verschlüsselung. Hiermit können gesendete Nachrich-

ten gegen Manipulation sowie unberechtigte Kenntnisnahme geschützt werden. Auf-
grund von Entwurfsfehlern im Standard ist dieser Schutz jedoch nur als rudimentär
zu bewerten. Beispielsweise ist kein Schutz gegen Replay-Angriffe vorgesehen, so dass
z.B. Befehle abgefangen und beliebig oft wieder in das Netzwerk eingeschleust werden
können. Es ist daher sinnvoll, auf höherer Protokollebene weitere Schutzmaßnahmen
vorzusehen, um sich erfolgreich gegen Angriffe zu schützen.
3.2.4.3.4 Leistungsaufnahme
Zur Bewertung der Leistungsaufnahme eines ZigBee-Netzwerks wird exemplarisch ein

ZigBee-Modul vom Typ ATZB-24-A2R der Firma Atmel betrachtet. Diese Modul ver-
fügt über einen Energiesparmodus. In diesem Modus wird lediglich der interne Speicher
29
mit Energie versorgt, alle weitere Hardware wird abgeschaltet. In diesem Modus hat
das Gerät (laut Hersteller) einen Strombedarf von weniger als 6 µA. Befindet sich das
Gerät nicht im Energiesparmodus und ist empfangsbereit, werden 19 mA benötigt;
sendet das Gerät sind 18 mA14 notwendig.
Durch den Energiesparmodus lassen sich große Einsparungen erreichen. Allerdings
kann dieser nur von RFDs verwendet werden, da FFDs immer empfangsbereit sein
müssen. Zur Übertragung von Nachrichten wird in diesem Fall von den RFDs ein
Polling-Verfahren verwendet: Der Elternknoten des FFDs (in den meisten Fällen also
der nächstgelegene Router) speichert eine an das RFD gesendete Nachricht so lange
zwischen, bis dieses die Nachricht abruft. So ist sichergestellt, dass keine Nachrichten
verloren gehen, wenn sich der Empfänger gerade im Energiesparmodus befindet.
3.2.4.4. Bluetooth Low Energy (ehemals Wibree)
Bluetooth Low Energy ist ein neuer Standard für WPANs, der mit dem Bluetooth-4.0 -
Standard eingeführt wurde. Er definiert eine Datenübertragung mit bis zu 1 MBit/s
(netto 0,26 MBit/s) bei einem Strombedarf, der unter 20 mA liegen soll, wobei laut
Spezifikation eine Reichweite von bis zu 100 m erreicht werden kann. [SIG10]
Zum Zeitpunkt dieser Diplomarbeit befanden sich Funkchips des Bluetooth-Low-Energy-
Standards leider noch in der frühen Testphase und waren auf dem Markt nicht erhält-
lich, so dass dieser Standard bei der Auswahl eines geeigneten Funkprotokolls nicht
in die engere Betrachtung gezogen werden konnte. Beim späteren Entwurf des Sen-
sornetzwerkes ist daher darauf Rücksicht zu nehmen, dass das Funkprotokoll nach
Möglichkeit austauschbar gehalten wird, so dass es später möglich ist, die entworfene
Lösung an geänderte Marktbedingungen anzupassen.
3.2.5. Weitere Protokolle

Neben den oben erwähnten Protokollen gibt es viele weitere kabellose Übertragungs-
protokolle wie beispielsweise der kommende Wireless-USB -Standard, WiMax, oder
Mikrowellen-Richtfunk. Diese Protokolle sind jedoch für die Übertragung mit hohen
Datenraten ausgelegt (was in der Regel mit einer dementsprechend hohen Leistungs-
aufnahme einhergeht), und liegen damit außerhalb des Fokus dieser Arbeit. Ebenfalls
14
Dass für das Senden weniger Energie benötigt wird als für das Empfangen mag auf den ersten Blick
kontraintuitiv erscheinen, ist aber durch den Filteraufwand beim Empfangen zu erklären.
30
3.3. Produkte zur kabellosen Patientenüberwachung
nicht berücksichtigt werden konnte der ANT+-Standard, der sich aktuell vor allem im
Bereich von Wellnessgeräten wie z.B. Pulsuhren durchzusetzen scheint. Leider handelt
es sich hierbei um eine proprietäre Lösung des Herstellers Dynastream; entsprechende
Bauteile sind momentan auf dem deutschen Markt praktisch nicht erhältlich.
3.2.6. Diskussion
Von den oben genannten Standards scheidet GSM/UMTS von vorne herein aufgrund
der hohen Betriebskosten aus. Auch der DECT -Standard kommt nicht in Frage, da
die Teilnehmerzahl auf 6 Geräte pro Basisstation beschränkt ist. WLAN ist zwar
grundsätzlich für eine solche Aufgabe geeignet, allerdings fällt der Strombedarf mit
über 100 mA für den Einsatz im Erste-Hilfe-Sensor zu hoch aus. Von der Leistungs-
aufnahme prinzipiell möglich wäre der Einsatz von Bluetooth, wobei insbesondere der
kommende Bluetooth Low Energy Standard interessant ist. Auch die hohe Störsicher-
heit wäre ein weiterer Punkt, der für Bluetooth spräche. Problematisch ist jedoch die
Einschränkung, dass pro Bluetooth-Piconetz immer nur 7 Slaves aktiv sein können.
Dies ist für die Anforderungen dieser Diplomarbeit deutlich zu wenig.
Letztendlich erweist sich der ZigBee-Standard als am besten für die gewünschte An-
wendung geeignet. Die erreichte Datenrate ist für die Übertragung einiger Messwer-
te und Alarme mehr als ausreichend. Auch die hohe Störsicherheit, die moderaten
Stückkosten sowie die vergleichsweise hohe Reichweite sprechen für diese Lösung. Die
beiden entscheidenden Kriterien sind jedoch die Fähigkeit von ZigBee, dynamische
Mesh-Netzwerke zu bilden sowie die sehr niedrige Leistungsaufname:
Durch die dynamische Vernetzung mit Routern lassen sich auch große Netzwerke rea-
lisieren. Das Routing wird komplett durch die Firmware der ZigBee-Module über-
nommen, so dass dieses nicht erst implementiert werden muss. Der Strombedarf der
Module ist mit maximal 19 mA so gering, dass eine Versorgung über Batterien ohne
weiteres möglich ist. Dieser Strombedarf lässt sich durch die Verwendung des Energie-
sparmodus weiter senken.
3.3. Produkte zur kabellosen Patientenüberwachung

Auf dem Markt ist eine breite Palette an kabellosen Produkten zur Patientenüberwa-
chung vorhanden. Dies davon setzen entweder Bluetooth oder proprietäre Protokolle
31
wie Z-Wave zur Funkübertragung ein; ZigBee ist bisher in keinem Medizinprodukt auf
dem Markt zu finden: Fast alle dieser Systeme sind – im Gegensatz zu den Anforderun-
gen dieser Arbeit – dazu konzipiert, lediglich einen einzelnen Patienten zu überwachen.
Die Funktechnologie dient hier vor allem dazu, die Anzahl der Kabel zwischen Patient
und Monitoren zu reduzieren, um so die Mobilität des Patienten zu erhöhen. Die hohe
Teilnehmerzahl von ZigBee bietet für die Überwachung eines einzelnen Patienten kei-
ne Vorteile, sondern bedeutet vielmehr einen zusätzlichen Aufwand, so dass Lösungen
wie Bluetooth in diesem Fall deutlich praktikabler sind.
Besonders häufig sind kabellose EKG-Geräte, Pulsoximeter oder invasive Blutdruck-

messgeräte anzutreffen. Ein Beispiel für ein solches Produkt ist der CorBELT der
Firma Corscience. Es handelt sich dabei um ein 1-Kanal EKG mit integriertem Be-
schleunigungssensor in Form eines Brustgurtes. Das System ist in der Lage, eine Viel-
zahl von Herzproblemen zu erkennen, und eignet sich daher besonders für Patienten
mit bekannten Herzerkrankungen. Das System hat einen integrierten Beschleunigungs-
sensor, um Bewegungsartefakte auszufiltern.[KG10]
Von diversen Herstellern wie Dräger Medical, Philips, GE und WelchAllyn existiert
eine Reihe Bluetooth-basierter Überwachungslösungen. Diese sind allerdings meist we-
niger als portables Gerät, als viel mehr als stationäre Überwachungslösung im Kran-
kenhaus gedacht. Die Bluetooth-Technik dient hier vor allem dazu, möglichst wenige
Kabel zum Patienten zu führen, was den Umgang (z.B. bei der Patientenwäsche oder
beim Wenden) erheblich erleichtert. Keine dieser Technologien ist jedoch für den Ein-
satz in einem MANV -Szenario geeignet.
3.4. Verwandte Projekte zum Einsatz in MANV-

Szenarien
Neben dieser Arbeit beschäftigen sich mehrere verwandte Projekte ebenfalls mit der
Problematik der effizienten Patientenversorgung während eines MANVs.
Bei dem Projekt SOGRO MANV 500 (Sofortrettung bei Großschadenslagen mit einem
Massenanfall von 500 Verletzten) beschäftigt, man sich insbesondere mit der effizien-
ten Kennzeichnung und Lokalisierung von Patienten. Hierzu wird den Patienten ein
32
3.4. Verwandte Projekte zum Einsatz in MANV-Szenarien
Armband mit integriertem GPS -Peilsender und Datenspeicher angelegt, auf dem dann
die Diagnose digital gespeichert wird. Eine automatische Überwachung ist bei diesem
Projekt allerdings derzeit nicht vorgesehen.[SOGR10]
Eine weiteres Projekt, das sich mit der technischen Unterstützung von Rettungskräften
bei einem MANV beschäftigt ist A.L.A.R.M. (Adaptive Lösungsplattform zur Akti-
ven technischen Unterstützung beim Retten von Menschenleben). Im Moment sind nur
recht wenige Informationen zu diesem Projekt verfügbar; diese deuten jedoch darauf
hin, dass es bei dem Projekt eher um die Schaffung von einheitlichen Prozessen und
Ablaufplanung als um eine konkrete technische Lösung geht.[ALAR10]
Ein ähnlicher Ansatz wie in dieser Diplomarbeit wird in dem AID-N ( AID-N: The Ad-
”
vanced Health and Disaster Aid Network: A Light-Weight Wireless Medical System
for Triage“) verfolgt.[GMSC+ 07]. Bei diesem Ansatz wird intensiv auf die TinyOS -
Plattform aufgebaut, und wird eine IEEE-802.15.4 -basierte Lösung eingesetzt. Leider
scheint dieses Projekt seit mehreren Jahren nicht weiter verfolgt zu werden; auf der
Webseite sind seit 2007 keine Änderungen mehr vorgenommen worden. Auch wurde
hier nicht auf Aspekte der industriellen Fertigung der einzelnen Knoten, d.h. insbe-
sondere Kompaktheit und Kosteneffektivität eingegangen. Insgesamt handelt es sich
um eine technisch sehr interessante Arbeit, die jedoch durch ihren anderen Fokus die
Anforderungen dieser Diplomarbeit nicht erfüllen kann.
33
4. Analyse
In diesem Kapitel wird eine Analyse der Problemstellung dieser Diplomarbeit vorge-
nommen. Hierzu werden zunächst die Anforderungen analysiert, die an ein kabelloses
System zur Überwachung von Patienten gestellt werden. Danach werden die eingesetz-
ten Hardwarebausteine, konkret der ADuC-Mikrocontroller sowie das ZigBee-Modul
der Firma Atmel inklusive der dazugehörigen SerialNet-Firmware vorgestellt und un-
tersucht. Hierbei werden häufig auftretende Probleme aufgezeigt und allgemeine Lö-
sungen erarbeitet. Diese Lösungen werden in den späteren Kapitel als Grundlage für
den Entwurf und die Implementierung der fertigen Lösung dienen.
4.1. Anforderungen an ein kabelloses System zur

Überwachung von Patienten
Nach Betrachtung des Standes der Technik ergeben sich folgende Anforderungen an
das zu entwickelnde System:
• Kompatibilität: Die zu entwickelnde Lösung soll mit dem Erste-Hilfe-Sensor zu-
sammenarbeiten. Hierzu ist es erforderlich, dass der Mikrocontroller des Sensors
in die Lage versetzt wird, mit dem Sensornetzwerk zu kommunizieren.
• Empfangen von Vitaldaten: Das System muss in der Lage sein, Vitaldaten und
Alarme von den Sensoren zu empfangen. Diese müssen möglichst zeitnah zuge-
stellt und angezeigt werden. Bei bestehen der Netzwerkverbindung sollen keine
Nachrichten verloren gehen.
4. Analyse
• Senden von Befehlen: Das System soll in der Lage sein, Befehle an die Sensoren
zu senden. Diese sollen auf die empfangenen Befehle entsprechend reagieren. Es
soll möglich sein, neue Befehle zu einem späteren Zeitpunkt hinzuzufügen.
• Skalierbarkeit: Das System soll sowohl in Anzahl der Sensoren als auch in der
räumlichen Ausdehnung (Reichweite) skalierbar sein. Es sollen sowohl sehr kleine
Netzwerke als auch große Netzwerke mit mehreren hundert Knoten realisierbar
sein.
• Kosteneffizienz: Die Kosten für die Erweiterung der Sensoren sollen möglichst
gering sein.
• Niedriger Strombedarf: Der Strombedarf der einzelnen Sensoren muss so gering
sein, dass der Betrieb über eine handliche Batterie über einen längeren Zeitraum
möglich ist. Ideal wäre, wenn sich eine Laufzeit von mindestens 12 Stunden mit
einer einzelnen Knopfzelle erreichen liesse.
• Stabilität: Das System soll möglichst unempfindlich gegenüber Störungen sein.
Bei einfachen Störungen des Funkverkehrs sollen verlorene Pakete neu Übertra-
gen werden. Schlägt diese Übertragung wiederholt fehl, soll eine Warnmeldung
an der Überwachungsstation angezeigt werden. Es soll ebenfalls gewarnt werden,
wenn ein Sensor die Netzwerkverbindung verloren hat oder aus anderen Gründen
(z.B. leere Batterie) nicht mehr erreichbar ist.
• Erweiterbarkeit: Das System soll softwareseitig erweiterbar sein. Insbesondere
soll es möglich sein, ohne Veränderungen an der Software Schnittstellen (z.B. in
Form einer Weboberfläche) zu anderen Systemen hinzuzufügen.
• Anpassbarkeit: Das System soll an sich verändernde Rahmenbedingungen an-
passbar sein. Insbesondere sollen alle technischen Details des Funkprotokolls so
gekapselt werden, dass ein Austausch des Funkprotokolls lediglich an einer Stelle
des Systems Änderungen erfordert.
4.2. Der Analog Devices ADuC702X -Mikrocontrol-

ler
Zentrale Komponente des Erste-Hilfe-Sensors, welcher die Grundlage für die Sensoren
im zu entwerfenden Netzwerk bildet, ist der ADuC-7022 -Mikrocontroller. Es handelt
36
4.2. Der Analog Devices ADuC702X-Mikrocontroller
ADC0 12-BIT DAC0

DAC
MUX 1MSPS
12-BIT ADC
ADC11 12-BIT DAC1
DAC
TEMP
SENSOR ADuC7026 12-BIT DAC2
CMP0 DAC
CMP1 BANDGAP 12-BIT

REF DAC3
DAC
CMPOUT
VREF
PWM0H
PWM0L
OSC THREE- PWM1H
XCLKI AND PLL ARM7TDMI-BASED MCU WITH PHASE
ADDITIONAL PERIPHERALS PWM PWM1L
XCLKO
PWM2H
2k × 32 SRAM
PSM PLA 31k × 16 FLASH/EEPROM GPIO PWM2L
RST POR 4 GENERAL SERIAL I/O EXT. MEMORY

PURPOSE TIMERS UART, SPI, I2C JTAG
INTERFACE
Abbildung 4.1.: Blockdiagramm des ADuC7026 -Mikrocontrollers (Quelle: Analog Devices)
sich hierbei um einen Vertreter einer ganzen Familie von Mikrocontrollern der Firma
Analog Devices. Es folgt eine kurze Übersicht über die Eigenschaften dieser Mikrocon-
trollerfamilie.
4.2.1. Beschreibung
Mit der ADuC702X -Familie bietet die Firma Analog Devices eine Serie voll integrierter
Mikrocontroller auf Basis der ARM7 -Architektur an. Diese Mikrocontroller zeichnen
sich insbesondere durch ihre hohe Anzahl an A/D-Wandler-Kanälen aus. So verfügt
das Modell ADuC7026 beispielsweise über 16 A/D-Wandler-Kanäle mit einer Abta-
strate von einer Million Samples pro Sekunde bei einer Auflösung von 12 Bit. Damit
bietet jeder der 16 Kanäle eine Datenrate, die etwa dem 17fachen einer gewöhnli-
chen Audio-CD entspricht. Der Mikrocontroller selbst bietet bei einer Frequenz von
41,78 MHz eine maximale Leistung von 41 Millionen Befehlen pro Sekunde (MIPS ).
Zusätzlich sind auf dem Chip 8 kB SRAM sowie 62 kB Flash-Speicher vorhanden.
Bei den Modellen ADuC7026 und ADuC7027 ist zusätzlich ein externer Speicherbus
vorhanden, über den bis zu 512kB zusätzlicher SRAM angeschlossen werden kann. Bei
37
4. Analyse
größerem Speicherbedarf besteht die Möglichkeit, über SPI oder I 2 C weiteren SRAM
oder Flash-Speicher anzuschliessen. [Devi07]
4.2.2. Peripherie
In die Mikrocontroller der ADuC-702X -Familie ist standardmäßig folgende Peripherie
integriert:
• AD-Wandler: Bis zu 16 Kanäle mit einer maximalen Abtastrate von 1 MSPS bei
einer Auflösung von 12 Bit.
• DA-Wandler: Je nach Typ 2, 3 oder vier Kanäle, mit einer Ausgangsspannung

zwischen 0 und 2,5 V mit einer Auflösung von 12 Bit.
• PWM-Generator: Flexibler 3-Phasen Pulsweitenmodulator (PWM ), der bis zu

3 Signalpaare gleichzeitig generieren kann.
• UART-Interface: Serielle Schnittstelle (UART ) mit TTL-Pegel.
• SPI-Bus: Schnittstelle zum Anbinden von bis zu 255 weiteren Peripheriekompo-

nenten.
• I 2 C − Bus: 2 I 2 C-Schnittstellen zur Anbindung weiterer Peripherie.
• PLA: 2 Blöcke mit jeweils 8 PLA-Elementen.
• Timer: 4 Allzwecktimer/Zähler.
Die einzelnen Modelle der ADuC-702X -Familie unterscheiden sich vor allem durch die
Anzahl vorhandener Pins. Bei dem kleinsten Modell ADuC-7019 stehen lediglich 40
Pins, beim größten 80 Pins zur Verfügung. Diese Pins sind zudem mehrfach belegt.
Daher ist es nicht möglich, die gesamte Peripherie gleichzeitig zu verwenden. Je nach
Anforderung ist ggf. die Verwendung eines größeren Modells notwendig.
4.3. Die Atmel-ZigBit-Familie

Nachdem die Entscheidung getroffen wurde, ZigBee als Funktechnologie für das Netz-
werk zu verwenden, muss nun noch ein geeignetes Hardwarebauteil gefunden werden.
38
Da die Herstellung von HF 1 -Komponenten eine sehr langwierige und komplexe Aufga-
be ist, wurde die Entscheidung getroffen, ein komplett integriertes Modul zu verwen-
den, bei dem bereits alle HF -Komponenten und Antenne aufgebracht sind. Passende
Lösungen waren von den Firmen Digi, Mikrochip, Radicrafts und Atmel verfügbar.
Letztendlich wurde die Entscheidung für ein Modul der Firma Atmel getroffen, da
diese nicht nur die günstigsten betrachteten Module, sondern mit der Ansteuerung
über UART mittels AT-Befehlen auch am einfachsten anzusteuern waren. Der hier
verwendete Modultyp soll nachfolgend kurz vorgestellt werden.
4.3.1. Hardware
VCC (1.8 – 3.6V)
IRQ
UART
ATmega1281 AT86RF230
USART/SPI Chip
Micro RF
I2C Antenna
controller Transceiver
JTAG
Analog
GPIO SPI Bus

Abbildung 4.2.: Blockdiagramm des ZigBit-24-A2R-Moduls (Quelle: Atmel)
Atmel bietet unter dem Namen ZigBit eine Palette von ZigBee-Modulen an. Diese
Module sind in der Ansteuerung identisch, unterscheiden sich jedoch vor allem in ihrer
Reichweite. Unter der Bezeichnung ATZB-24-A2R wird ein Modul für kurze Reichwei-
ten angeboten. Besonderheit an diesem Modul ist, dass es bereits über zwei integrierte
Antennen verfügt, so dass für den Betrieb keine weiteren Bauteile notwendig sind.
1
Hochfrequenz
39
4. Analyse
Die ZigBit-Module enthalten einen IEEE 802.15.4-Transceiver, einen ATmega1281 -

Mikrocontroller sowie einen 128kB großen Flash-Speicher. Das Modul kann mittels
UART, SPI oder I 2 C angesteuert werden. [Atme09]
4.3.2. Firmware
4.3.2.1. Bitcloud
BitCloud ist ein ZigBee-Pro-zertifizierter Softwarestack von Atmel. Es werden die Mo-
dule der ZigBit-Familie sowie die RZRAVEN-Evaluationskits unterstützt. BitCloud ist
hierbei keine fertige Firmware, sondern Teil eines Software Development Kits (SDK),
das dazu dient, Anwender beim schnellen und einfachen Entwickeln eigener Firmware
zu unterstützen. Für Anwender, die selbst keine Firmware implementieren möchten,
stellt das im folgenden Abschnitt beschriebene SerialNet eine Alternative dar.
4.3.2.2. SerialNet
SerialNet ist eine BitCloud -basierte Firmware, die von Atmel als fertiges Image2 an-
geboten wird. Dieses kann auf dem ZigBit-Modul installiert werden, wodurch die
Notwendigkeit der Eigenentwicklung entfällt. SerialNet bietet ein einfaches serielles
Interface, das sich mit Hilfe von AT-Befehlen 3 steuern lässt. Der Befehlssatz bietet
Zugriff auf fast alle Module des ZigBit-Moduls wie z.B. das Versenden und Empfan-
gen von Daten, das Schalten von IO-Ports eines entfernten ZigBit-Moduls sowie die
Konfiguration des Energiesparmodus. Nicht möglich ist derzeit die Verwendung der
im ZigBee-Standard definierten AES -Verschlüsselung, so dass eine Datenübertragung
derzeit nur unverschlüsselt erfolgen kann. Daher müssen für den produktiven Einsatz
weitere Sicherheitsmaßnahmen ergriffen werden. Wie diese aussehen können, ist in
Abschnitt 9.2 beschrieben.
4.3.2.2.1 SerialNet AT-Protokoll
Das SerialNet AT-Protokoll lässt sich vereinfacht als Zustandsautomat mit 3 Zustän-
den darstellen (vgl. Abbildung 4.3)4 :
2
Binäres Speicherabbild, das ohne Anpassung in den Speicher des ZigBit-Moduls programmiert
werden kann.
3
Der AT-Befehlssatz war früher zur Steuerung von Modems weit verbreitet.
4
Zur exakten Darstellung müssten weitere Zustände eingeführt werden, die das Bearbeiten von
Befehlen im offline-Modus repräsentieren. Außerdem wird der Übergang von offline zu online
40
{+wjoin|+autonet=1}
[Event] {Befehl} [Event]
[OK|ERROR]
offline Befehl wird
offline online
ausgeführt
{OK|ERROR}
{+wleave}
[Komplexe
[OK|ERRoR]
Rückgabe]
{ } – Befehl
[ ] – Antwort
Abbildung 4.3.: Darstellung des SerialNet-Protokolls als Zustandsautomat
• offline: Es besteht keine Verbindung zu einem ZigBee-Netzwerk. Befehle zur

Kommunikation mit anderen Knoten sind nicht verfügbar. Ein Zugriff auf die
Konfiguration der Netzwerkparameter wie Netzwerk- und Hardwareadresse ist
verfügbar.
• online: Das Modul ist betriebsbereit, mit einem Netzwerk verbunden und war-
tet auf Befehle. Befehle zur Kommunnikation mit anderen Knoten stehen zur
Verfügung, Befehle zur Kommunikation der Netzwerkparameter sind gesperrt.
• busy: Das Modul ist mit der Bearbeitung eines Befehls beschäftigt. Es stehen kei-
ne Befehle zur Verfügung – jedoch können jederzeit Ereignisse empfangen werden.
Grundsätzlich ist das SerialNet-Protokoll synchron: Ein Befehl wird immer mit einem
der beiden Ergebniscodes OK und ERROR beantwortet. Bei einigen Befehlen wie
z.B. AT+WCHILDREN kann zusätzlich zum Ergebniscode eine ggf. sogar mehrzei-
lige Antwort erfolgen. Eine Antwort wird immer durch Ausgabe eines Ergebniscodes
beendet. Neben dieser synchronen Befehl-Antwort-Folge können jedoch jederzeit auch
asynchrone Events auftreten. Hierauf muss bei der Entwicklung eines Treibers zur An-
steuerung des Moduls besonders geachtet werden. Die wichtigsten SerialNet-Befehle,
eigentlich durch ein EVENT JOINED-Ereignis ausgelöst, und müsste daher durch einen Epsilon-
Übergang dargestellt werden. Diese Details sind jedoch für das Verständnis der prinzipiellen Funk-
tionsweise des Befehlssatzes unwesentlich.
41
4. Analyse
Befehl Beschreibung Antwort Anwendbark.

ATD Versenden von Daten Einfach online-Zustand
ATR Entfernten Befehl ausführen Komplex online-Zustand
AT+WCHILDREN Liste aller untergeordneter Nodes Komplex nur auf FFD
AT+WPANID Setzen der PAN-Adresse Einfach offline-Zustand
AT+WCHMASK Setzen der Kanalmaske Einfach offline-Zustand
AT+WLEAVE Netzwerk verlassen Einfach online-Zustand
AT+WJOIN Netzwerk beitreten Einfach offline-Zustand
AT+WAUTONET Netzwerk automatisch beitreten Einfach offline-Zustand
AT+WROLE Rolle im Netzwerk konfigurieren Einfach offline-Zustand
AT+WPWR Powermanagement konfigurieren Einfach offline-Zustand
AT+WSRC Netzwerkadresse konfigurieren Einfach offline-Zustand
AT+GSN Hardwareadresse konfigurieren Einfach offline-Zustand
AT+WWAIT Wartezeit auf Parameter für ATD Einfach offline-Zustand
Tabelle 4.1.: Übersicht der wichtigsten SerialNet-Befehle
Ereignis Beschreibung Parameter

DATA Daten empfangen Adresse, Länge, Daten
EVENT:JOINED Netzwerkverbindung hergestellt —
EVENT:LOST Netzwerkverbindung verloren —
Tabelle 4.2.: Übersicht der SerialNet-Ereignisse
ihre Anwendbarkeit sowie die Art der Antwort sind in Tabelle 4.1 dargestellt. Tabel-
le 4.2 beinhaltet die wichtigsten SerialNet-Events.
4.4. Kommunikation mit dem ZigBit-Modul
4.4.1. Problemstellung
Das SerialNet-Protokoll ist grundsätzlich synchron. Ein Programm, das mit einem
ZigBit-Modul kommunizieren lässt sich daher am einfachsten nach folgendem Muster
aufbauen:
1 def sendeBefehl ( befehl )
42
2 # Senden des Befehls

3 serialPort . send ( befehl )
5 # Antwort vom ZigBit - Modul lesen .

6 # ( Blockiert so lange , bis Antwort empfangen wurde )
7 statusString = serialPort . readLine ()
9 # Antwort interpretieren
10 if statusString == ’ OK ’:
11 return True
13 else :
14 return False
Bei dieser Vorgehensweise ergeben sich jedoch zwei Probleme:
1. Asynchron auftretende Ereignisse: Die Abarbeitung eines SerialNet-Befehls kann

bis zu einer halben Minute dauern5 . Während das Steuerungsprogramm auf die
Quittierung des Befehls mit einer Status-Meldung wartet, können asynchrone
Ereignisse auftreten. Im oben abgebildeten Programm würde ein solches Ereignis
fälschlicherweise als Antwort auf den gesendeten Befehl interpretiert werden.
Dies hätte zur Folge, dass nun Steuerungsprogramm und ZigBit-Modul nicht
mehr synchron zueinander ( out-of-sync“) sind.
”
2. Komplexe Rückgabewerte: Bestimmte Befehle der SerialNet-Firmware liefern
nicht nur einen einfachen Statuscode, sondern eine komplexe, mehrzeilige Ant-
wort zurück. Bei obigem Programm ergibt sich das Problem, dass dieses bereits
nach der ersten Zeile fälschlicherweise davon ausgehen würde, dass die Antwort
abgeschlossen wäre, obwohl noch weitere Zeilen folgen können. Auch in diesem
Falle wären Steuerungsprogramm und ZigBit-Modul nicht mehr synchron zuein-
ander.
5
Dies tritt insbesondere dann auf, wenn eine synchrone Datenübertragung zu einem entfernten Kno-
ten durchgeführt werden soll, der sich selbst gerade im Energiesparmodus befindet. Der sendende
Knoten ist hierbei so lange blockiert, bis entweder der Empfang der Daten quittiert wurde oder
aber ein Timeout aufgetreten ist
43
4. Analyse
4.4.2. Behandlung asynchron auftretender Ereignisse

Um asynchrone Ereignisse behandeln zu können, müssen diese zunächst erkannt wer-
den. Dies kann mit Hilfe einer Liste aller möglichen Ereignisse und Statuscodes gesche-
hen. In diesem Falle wird so lange von dem ZigBit-Modul gelesen, bis ein Statuscode
empfangen wurde. Zwischendurch empfangene Ereignisse können entweder direkt be-
handelt, oder zunächst in einer Liste zwischengespeichert werden, um sie zu einem
späteren Zeitpunkt zu behandeln. Beide Verfahren haben sowohl Vor- als auch Nach-
teile:
• Direktes Behandeln von Ereignissen: Dieses Verfahren hat den Vorteil, dass auf
empfangene Ereignisse sofort reagiert werden kann; so lässt sich z.B. ein empfan-
gener Alarm direkt auf dem Bildschirm darstellen und es muss nicht erst auf die
Beendigung des vorherigen Befehls gewartet werden. Erfordert das behandelte
Ereignis den Zugriff auf das ZigBit-Modul, um z.B. den Empfang einer Nachricht
zu quittieren, so ist besondere Vorsicht erforderlich, da sonst entweder Verklem-
mungen (Deadlocks) oder ein Verlust der Synchronisierung auftreten können6 .
Dieses Verfahren eignet sich besonders für Systeme, in denen auf eingehende
Ereignisse besonders schnell reagiert werden muss.
• Einreihen von Ereignissen in eine Warteschlange: Diese Verfahren hat den Vor-
teil, dass es sehr einfach umgesetzt werden kann. Alle Ereignisse, die während
der Bearbeitung eines Befehls auftreten, werden zunächst in eine Warteschlange
eingereiht. Mit der Abarbeitung der Ereignisse wird so lange gewartet, bis der
laufende Befehl abgeschlossen wurde. Während der Abarbeitung der Ereignisse
muss dann keine Rücksicht mehr darauf genommen werden, in welchem Zustand
sich das ZigBit-Modul befindet, da es sich nach Abarbeitung eines Befehls sicher
im betriebsbereiten Zustand befindet7 Nachteilig ist, dass Ereignisse erst behan-
delt werden, wenn Befehle komplett abgearbeitet wurden. Bei Ereignissen, zu
deren Bearbeitung nicht auf das ZigBit-Modul zugegriffen werden muss, bedeu-
tet dies eine unnötige Verzögerung. Dieses Verfahren eignet sich daher eher für
Systeme, in denen deutlich mehr Befehle als Ereignisse auftreten.
6
Eine mögliche Lösung ist die Verwendung einer Warteschlange, in die die zu versendenden Daten
eingereiht werden.
7
Ausnahme hiervon ist, der zwischenzeitliche Verlust der Netzwerkverbindung, der natürlich geson-
dert behandelt werden muss.
44
Durch die Verwendung von Multithreading kann darüber hinaus eine Kombination aus
beiden Verfahren verwenden werden. In diesem Fall wird von einem Thread aus die
Bearbeitung der Befehle, inkl. des Befüllens der Ereigniswarteschlange vorgenommen,
während von einem anderen Thread aus diese Warteschlange parallel dazu abgearbei-
tet wird.
Das folgende Pseudocode-Programm zeigt exemplarisch das Behandeln von Ereignis-

sen über das Einreihen in Warteschlangen:
1 eventQueue = []

4 # Senden des Befehls
5 serialPort . send ( befehl )
7 # Antwort vom ZigBit - Modul lesen .

8 # ( Blockiert so lange , bis Antwort empfangen wurde )
11 # Events behandeln
12 while statusString not in ( ’ OK ’ , ’ ERROR ’ ):
13 eventQueue . append ( statusString )
14 statusTring = serialPort . readLine ()
16 # Status Code interpretieren

18 return True
20 else :
21 return False
4.4.3. Behandlung von komplexen Antworten

Bei der Behandlung von komplexen Antworten kommt der Umstand zur Hilfe, dass
bereits im Voraus bekannt ist, welche Befehle eine komplexe Antwort erzeugen. Bei
welchen Befehlen dies der Fall ist, kann aus Tabelle 4.1 entnommen werden. Im Steuer-
45
4. Analyse
programm kann beim Parsen des Befehls daher entsprechend Rücksicht darauf genom-
men werden, ob eine einzeilige oder eine mehrzeilige Antwort erwartet wird. Komple-
xe Antworten werden immer mit einem Statuscode beendet, d.h. wenn eine komplexe
Antwort erwartet wird, muss so lange vom ZigBit-Modul gelesen werden, bis ein Sta-
tuscode empfangen wird. Auch hierbei muss natürlich darauf geachtet werden, dass
zwischen einzelnen Zeilen einer Antwort Ereignisse auftreten können, die entsprechend
der in Abschnitt 4.4.2 vorgestellten Lösung behandelt werden müssen. Das folgende
Pseudocode-Programm zeigt, wie komplexe Antworten behandelt werden können:

2 # # Senden des Befehls
3 serialPort . send ( befehl . getCmd ())
5 if befehl . resultIsComplex ():

6 # # Komplexe Antwort wird erwartet
7 # # So lange lesen , bis ein Status - Code empfangen
8 # # wurde
9 complexResult = []
10 statusString = ’ ’

14 complexResult . append ( statusString )
16 return statusString
18 else :
19 # # Antwort vom ZigBit - Modul lesen .
20 # # ( Blockiert so lange , bis Antwort empfangen
21 # # wurde )
24 # # Antwort interpretieren
26 return True
46
28 else :
29 return False
4.4.4. Kombination beider Lösungen

Kombiniert man die Lösungen aus Abschnitt 4.4.2 und Abschnitt 4.4.3, ergibt sich ein
weiteres Problem: Bei der Lösung aus Abschnitt 4.4.2 wird davon ausgegangen, dass
alle gelesenen Zeilen, bei denen es sich nicht um Statuscodes handelt, Ereignisse sind.
Diese Annahme ist jedoch hinfällig, sobald komplexe Antworten vom ZigBit Modul
empfangen werden. Daher muss hierbei jede Antwort einer genaueren Prüfung unter-
zogen werden, ob es sich hierbei um einen Statuscode, ein Event oder eine komplexe
Antwort handelt. Hierbei kann eine einfache Mustererkennung verwendet werden.
1 eventQueue = []
3 def getResultType ( input ):

4 if input in ( ’ OK ’ , ’ ERROR ’ ):
5 return " Status code "
6 elif input [0:4] == ’ DATA ’ or \
7 input [0:11] == ’ EVENT : JOINED ’ or \
8 input [0:10] == ’ EVENT : LOST ’:
9 return " Event "
10 else :
11 return " Complex result "

14 # # Senden des Befehls
15 serialPort . send ( befehl . getCmd ())
17 if befehl . resultIsComplex ():

18 # # Es wird eine komplexe Antwort erwartet
20 # # Von seriellem Port legen

23 # # Komplexe Antwort wird erwartet
47
4. Analyse
24 # # So lange lesen , bis ein Status - Code

25 # # empfangen wurde
26 complexResult = []
28 while getResultType ( statusString ) != ’ Status code ’:

29 if getResultType ( statusString ) == ’ Event ’:
31 else :
36 # # Ende Erreicht . Nun noch den statusCode anhaengen

37 # # und Ergebnis zurueckliefern
39 return complexResult
41 else :
42 # # Antwort vom ZigBit - Modul lesen .
43 # # ( Blockiert so lange , bis Antwort
44 # # empfangen wurde )
47 # Events behandeln
50 statusTring = serialPort . readLine ()
52 # Status Code interpretieren

54 return True
56 else :
57 return False
48
4.5. Powermanagement
4.5. Powermanagement
Die Spannungsversorgung des Erste-Hilfe-Sensors erfolgt über Batterie. Da der Wech-
sel der Batterie während eines MANVs umständlich und zeitraubend ist, ist eine mög-
lichst hohe Batterielaufzeit wünschenswert. Am besten wäre hierbei, wenn überhaupt
kein Batteriewechsel notwendig wäre. Konkret bedeutet dies, dass mit einer Batterie
eine Laufzeit von mindestens 12 Stunden erreichbar sein sollte. Bei einer Laufzeit von
12 Stunden ergibt sich hieraus, dass der Strombedarf des ZigBit-Moduls im Mittel
20 mA nicht überschreiten darf. Im empfangsbereiten Zustand braucht das ZigBit-
Modul laut Datenblatt einen Strom von 19 mA, ist also grundsätzlich zur Erfüllung
dieser Anforderung geeignet8 . Zur Verringerung der Leistungsaufnahme bietet das Zig-
Bit-Modul einen Energiesparmodus, indem lediglich der interne Speicher gehalten und
alle andere Hardware abgeschaltet wird. In diesem Modus braucht das Modul laut Da-
tenblatt weniger als 6 µA.
Zum Stromsparen wird das Modul periodisch für eine bestimmte Zeit in den Energie-
sparmodus versetzt. Während dieser Zeit kann das Modul weder von der Steurungs-
software angesprochen werden, noch können Daten vom Netzwerk empfangen werden.
Damit in dieser Zeit keine Informationen verloren gehen, werden vom nächstgelege-
nen Router alle Nachrichten an dieses Modul zwischengespeichert, bis dieses wieder
im empfangsbereiten Zustand ist. Bei Verwendung der SerialNet-Firmware wird die
Dauer des Verweilens im Energiesparmodus über den Befehl AT+WPWR konfiguriert.
Die Konfiguration erfolgt in Schritten zu 100 ms.
Zum Aufruf des Energiesparmodus bieten sich nun zwei Möglichkeiten:
• Automatsisches Aufrufen des Energiesparmodus: Hierbei wird über den zweiten

Paramter des Befehls AT+WPWR ein Intervall angegeben, in dem der Energie-
sparmodus periodisch aufgerufen wird. Hierbei erfolgt die Eingabe in Schritten
von 10ms.
• Manuelles Aufrufen des Energiesparmodus: Alternativ zum automatischen Auf-

rufen kann der Energiesparmodus über den Befehl AT+WSLEEP auch manuell
8
In dieser Betrachtung ist der Strombedarf des Erste-Hilfe-Sensors nicht berücksichtigt.
49
4. Analyse
aufgerufen werden. Dies kann entweder entweder alternativ zum automatischen

Aufrufen oder als Ergänzung verwendet werden.
Bei der Verwendung des Energiesparmodus muss sichergestellt werden, dass keine In-
formationen, die über die UART -Schnittstelle an das Modul gesendet werden, verloren
gehen. Hierzu bietet die SerialNet-Firmware die Möglichkeit, über die CTS -Leitung
der UART -Schnittstelle ihre Empfangsbereitschaft zu signalisieren. Die Steurungssoft-
ware auf der Gegenseite muss hierzu vor jedem Senden den Zustand der CTS -Leitung
kontrollieren, und darf nur senden, wenn die CTS -Leitung den Zustand 0 hat. Damit
die SerialNet-Firmware diesen Zustand korrekt kommuniziert, muss über den Befehl
AT+IFC die Flusskontrolle aktiviert werden.
Zu beachten ist, dass die Konfiguration des Energiesparmodus bei allen Teilnehmern
des Netzes (also auch auf Routern und Coordinatoren) gleich sein sollte, damit Nach-
richten an Knoten, die sich im Energiesparmodus befinden, auf den Routern lange
genug zwischengespeichert werden. Der eigentliche Energiesparmodus steht allerdings
nur auf Endknoten, also RFDs zur Verfügung.
50
5. Entwurf
In diesem Kapitel wird der Entwurf der zu implementierenden Lösung vorgenommen.

Hierzu erfolgt zunächst der Entwurf des Gesamtsystems im Groben. Dieses Gesamt-
system wird in einzelne Komponenten zerlegt, die danach einzeln genauer spezifiziert
werden. Hierbei wird zwischen Hard- und Software unterschieden. Ein Teil der Softwa-
rekomponenten wird parallel zu dieser Arbeit in [Tepe10] entworfen und implementiert.
5.1. Gesamtsystem
In dieser Arbeit wird ein System zur Patientenüberwachung entworfen. Dieses System
besteht aus einer Kombination von Soft- und Hardware. Zwischen den einzelnen Kom-
ponenten gibt es klar definierte Schnittstellen. Hierdurch ist gewährleistet, dass die
einzelnen Komponenten unabhängig voneinander entworfen und implementiert werden
können. Noch nicht implementierte Komponenten können durch Simulatoren ersetzt
werden, so dass bereits fertige Komponenten schon getestet werden können, ohne dass
das Gesamtsystem komplett fertig gestellt werden muss. Dies gewährleistet ein früh-
zeitiges Erkennen von Problemen und ermöglichst ein entsprechendes Gegensteuern.
Abbildung 5.1 zeigt, welche Komponenten in dem Gesamtsystem existieren und wie
diese zusammenwirken:
• Erste-Hilfe-Sensor : Der eigentliche Sensor, der zur Überwachung der Patienten

eingesetzt wird. Dieser wird in [Jäg08] dargestellt. In dieser Arbeit wird dieser
5. Entwurf
Server-Anwendung
Anwender
Operator Notarzt
MANV-Datenbank
MANV-Server
Ethernet
Client-Anwendung
MANV-Mobile-Gui
Wlan-Access-Point
MANV-Connector
an
Wl
ZigBee-Netzwerk
MANV-Gui
ZigBee-USB-Stick
ZigBee-Router
ZigBee
ZigBee-Router
Erste-Hilfe-Sensor Erste-Hilfe-Sensor Erste-Hilfe-Sensor
Überwachte Personen
Patient Patient Patient
Abbildung 5.1.: Überblick über das Gesamtsystem
52
5.2. MANVNode
Sensor um eine ZigBee-Schnittstelle erweitert. Zur Simulation des erweiterten

Sensors wird eine Testplatine entwickelt, die sogenannte MANVNode.
• ZigBee-Router : Die Router dienen zur Erweiterung der Reichweite des ZigBee-
Netzwerkes. Hierfür wird ein fertiges ZigBee-Modul der Firma Atmel verwendet.
• ZigBee-USB-Stick : Der USB -Stick bildet die Hardwareschnittstelle zwischen Com-

puter und ZigBee-Netzwerk. Das Design basiert auf einem ZigBee-Router, der
um eine USB -Schnittstelle erweitert wird.
• MANVConnector : Der Connector fungiert als Adapter, der eine Übersetzung

zwischen der Hardware des USB-Sticks und der CORBA-Schnittstelle der MANV-
Suite vornimmt. Vereinfacht gesprochen handelt es sich um einen Treiber für den
ZigBee-USB -Stick. Der MANVConnector kapselt alle hardwarespezifischen De-
signentscheidungen. Soll später eine andere Funkschnittstelle wie z.B. Bluetooth
oder WLAN verwendet werden, so muss lediglich der MANVConnector ausge-
tauscht werden.
• MANVServer : Der MANVServer verwaltet alle Informationen über das Sensor-

netz. Hierzu wird eine relationale Datenbank verwendet. Er sorgt dafür, dass alle
Informationen an den entsprechenden Empfänger zugestellt werden. Die Kom-
munikation zwischen MANVServer und MANVConnector erfolgt über CORBA.
Der MANVServer wurde in [Tepe10] entwickelt.
• Client-Anwendungen: Die Clientanwendungen, also MANVGui und MANVMo-

bileGui bilden die Benutzerschnittstelle des Sensornetzes. Diese wurden ebenfalls
in [Tepe10] entwickelt.
5.2. MANVNode
Die MANVNode ist eine Test- und Entwicklungsplatine zum Test der Sensornetzes. Auf
ihr befindet sich ein ADuC-7026-Mikrocontroller der Firma Analog Devices sowie ein
Atmel ZigBit-Funkmodul des Typs ATZB-24-A2. Die Platine dient zur Simulation des
Erste-Hilfe-Sensors. Die Beschaltung dieser Bauteile findet sich in Abbildung 5.2 sowie
Abbildung 5.3. An Stelle einer echten Messung generiert die Platine Messwerte mit
Hilfe eines Zufallszahlen-Generators. Mit diesem Generator können folgende Zustände
generiert werden:
53
5. Entwurf
ADuC 7026
DGND
4 3
R6 VDD
2 1
1k
RESET
C7 C8
Q1 12pF 12pF
TMS
TDO
TCK
TDI
15
23
14
22
37
44
45
U$1 DGND DGND
TDO
XCLKO
TDI
RST#
XCLKI
TMS
TCK
77 62 UART_TXD
ADC0 P1.0/T1/SPM0/PLAI[0]
78 61 UART_RXD
ADC1 P1.1/SPM1/PLAI[1]
79 60 UART_RTS
ADC2/CMP0 P1.2/SPM2/PLAI[2]
80 59 UART_CTS
ADC3/CMP1 P1.3/SPM3/PLAI[3]
1 58
ADC4 P1.4/SPM4/PLAI[4]/IRQ2
2 57
ADC5 P1.5/SPM5/PLAI[5]/IRQ3
3 52
ADC6 P1.6/SPM6/PLAI[6]
4 51
ADC7 P1.7/SPM7/PLAO[0]
5
ADC8
6 42 LED_RED
ADC9 P2.0/SPM9/PLAO[5]/CONVSTART#
7 49 LED_YELLOW
ADC10 P2.1/WS#/PWM0H/PLAO[6]
76 50 LED_GREEN
ADC11 P2.2/RS#/PWM0L/PLAO[7]
10 17 LED_BLUE
DAC0/ADC12 P2.3/AE
11 33
DAC1/ADC13 P2.4/PWM0H/MS0
12 35
DAC2/ADC14 P2.5/PWM0L/MS1
13 36 PIEZZO
DAC3/ADC15 P2.6/PWM1H/MS2
48 ZIGBIT_RESET
P2.7/PWM1L/MS3
8
GNDREF
67 29
REFGND P3.0/AD0/PWM0H/PLAI[8]
470nF 30
P3.1/AD1/PWM0L/PLAI[9]
9 31
ACDNEG P3.2/AD2/PWM1H/PLAI[10]
C10 AGND P3.3/AD3/PWM1L/PLAI[11]
32
69 38
DACREF P3.4/AD4/PWM2H/PLAI[12]
39
P3.5/AD5/PWM2L/PLAI[13]
BUTTON_YELLOW 43 P0.7/ECLK/XCLK/SPM8/PLAO[4] P3.6/AD6/PWMTRIP/PLAI[14]
46
21 47
P0.6/T1/MRST/PLAO[3]/AE P3.7/AD7/PWMSYNC/PLAI[15]
BUTTON_BLUE 41
IRQ1/P0.5/ASCBUSY/PLAO[2]/MS0
40 55
IRQ0/P0.4/PWMTRIP/PLAO[1]/MS1 P4.0/AD8/PLAO[8]
TRST 34 56
P0.3/TRST/A16/ADCBUSY P4.1/AD9/PLAO[9]
BUTTON_GREEN 24 63
P0.2/PWM2L/BHE# P4.2/AD10/PLAO[10]
BUTTON_RED 16 64
20
P0.1/PWM2H/BLE# P4.3/AD11/PLAO[11]
65
ZIGBIT_STATUS
BM/P0.0/CMPOUT/PLAI[7]/MS2 P4.4/AD12/PLAO[12]
66 DGND
P4.5/AD13/PLAO[13]
BUTTON_DOWNLOAD
18
P4.6/AD14/PLAO[14]
19
DGND P4.7/AD15/PLAO[15]
DACGND
DACVDD
IOGND
IOGND
IOVDD
IOVDD
DGND
AGND
AGND
AVDD
AVDD
VREF
LVDD
SERIALDOWNLOAD
R9
1k
ADUC7026
27
28
68
26
54
25
53
70
75
73
74
71
72
1
DGND
2
VCC
C11 C12
100nF 100nF
C6
100nF
VDD
C5
470nF 470nF
DGND
C4
AGND
Abbildung 5.2.: Schaltplan der MANVNode: Mikrocontroller.
54
5.2. MANVNode
ZigBit
1 JP1
1 43
SPI-CLK IRQ6
2 42
2
3
4
SPI-MISO IRQ7
3 41
SPI-MOSI PE3
4 40
ZDM-A1281-A2
PB5 USART0-EXTCLK
VDD
DGND 5 39
PB6 USART0-TX
6 38
PB7 USART0-RX
7 37
32K-OUT(PG3) UART-DTR
ZIGBIT_RESET 8 RESET PG5
36
9 35
U$3
DGND AGND
10 34
CPU-CLK AREF
11 33
I2C-CLK(PD0) BAT(VCC/3,PF0)
S1
ZIGBIT_TXD DGND 12 I2C-DATA(PD1) ADC-IN1(PF1)
32
UART_RXD 1 2 13
UART-TX ADC-IN2(PF2)
31 AGND
UART_TXD 3 4 ZIGBIT_RXD 14 30
ZIGBIT_RTS UART-RX ADC-IN3(PF3)
UART_RTS 5 6 15
UART-RTS JTAG-TCK
29
UART_CTS 7 8 ZIGBIT_CTS 16 28
1
UART-CTS JTAG-TDO
SJ1
17 27
PD6 JTAG-TDI
DGND
DGND
DVCC
DVCC
18 26
PG0
PG1
PG2
PD7 JTAG-TMS
2
19
20
21
22
23
24
25
DGND
2
1
ENABLE_ZIGBEE
470nF
C9
VDD
DGND
Abbildung 5.3.: Schaltplan der MANVNode: ZigBit-Modul.
• Grün: Simulation eines Patienten mit gutem Kreislaufzustand. Puls zwischen

60 und 120 Schlägen pro Minute, Atemzüge pro Minute zwischen 12 und 15.
Periodischer Versand der Meldung Zustand OK“.
”
• Gelb: Simulation eines Patienten mit beginnend kritischem aber noch nicht akut
lebensbedrohlichem Kreislaufzustand. Puls zwischen 120 und 180 Schlägen pro
Minute, Atmung zwischen 60 und 80 Zügen pro Minute (Hyperventilation).
• Rot: Simulation eines Patienten in kritischem Zustand mit Puls zwischen 0 und
10 (entsprechend Kammerflimmern oder Kreislaufstillstand) sowie Atmung zwi-
55
5. Entwurf
4
2
4
2
4
2
4
ZDM-A1281-A2
12pF
470nF
1
3
1
3
1
3
1
3
100k
1JS
100nF
LP2980IM5
100pf 1Q 100k
4 3
12pF
10µF 100k
1 2 3 4 2 1
ES2D
470nF
ADUC7026
7R
100nF
470nF
8R
0
10µF
470nF
0
100
100nF 1k
4 3 2 1 1 2
100
1k
3 4
Abbildung 5.4.: Entwurf der Platine der MANVNode.
schen (0 und 2) mit bestehendem akutem Handlungsbedarf. Priorisierte Gene-

rierung einer Alarmmeldung.
Zur Einstellung und zum Wechsel der Zustände befinden sich 3 Taster an der Plati-
ne. Der Zustand wird mit Hilfe von drei farbigen LEDs visualisiert. Zusätzlich kann
über einen Piezo-Summer ein Alarm auch akustisch wiedergegeben werden. Durch die
Kombination der drei LEDs werden zusätzlich Status- und Fehlerinformationen der
Platine während des Initialisierungsvorgangs ausgegeben.
56
5.2. MANVNode
5.2.1. Hardware
Die MANVNode wird als Platine in SMD-Bausweise realisiert. Das Layout dieser
Platine wurde mit Hilfe des Programms Cadsoft Eagle entworfen. In Abbildung 5.4 ist
der Entwurf dieser Platine zu sehen. Im Folgenden werden die einzelnen Aspekte des
Entwurfs erläutert.
5.2.1.1. Spannungsversorgung
power
VCC
VDD
AVDD
POWER1
R5
1
2
100
R4
100
VDD
DGND
C2
PWR
C3
10µF
10µF
GND
AGND
DGND
ES2D
D1
1
3 ON IN OUT 5
GND
ADP1
2
C1 LP2980IM5
100pf
GND
R7 R8
0 0
AGND
DGND
POWER
1
2
Abbildung 5.5.: Schaltplan der Spannungsversorgung der MANVNode.
Um die Platine möglichst vielseitig einsetzen zu können, wurde Wert auf eine mög-
lichst flexible Spannungsversorgung gelegt. Diese soll möglichst robust gegenüber Span-
nungsschwankungen sein. Kern der Spannungsversorgung ist ein Low-Dropout-Span-
nungsregler des Typs LP2980-3.3 der Firma National Semiconductor. Dieser liefert
57
5. Entwurf
eine stabile 3,3-V-Spannung bei einem maximalen Strom von 50 mA. Die Eingangs-
spannung kann zwischen 2,1 V und 16 V variiert werden. Die Spannungsversorgung
kann damit z.B. über USB (5 V-Versorgungsspannung), ein externes Netzteil oder
eine 9 V-Blockbatterie gespeist werden. Durch die hohe maximale Versorgungsspan-
nung von 9 V sind Schäden durch versehentliches Anschließen eines falschen Netzteils
weitestgehend ausgeschlossen. Die Spannungsversorgung ist zusätzlich mit einem 10-
mF-Kondensator stabilisiert.
Zusätzlich wurde die die Spannungsversorgung weiter stabilisiert. Hierzu wurde jeder
Spannungseingang aller Bauteile der Platine mit einem 100nF Kondensator gepuffert.
Diese sind möglichst nahe an den entsprechenden Versorgungspins angebracht. Kurz-
zeitige Spannungsabfälle, wie sie z.B. beim Schalten von LEDs, des Piezo-Summers
oder des Aufwachens des ZigBee-Moduls aus dem Stromsparmodus auftreten kön-
nen, werden so zuverlässig abgefangen. Der Schaltplan der Spannungsversorgung der
MANVNode findet sich in Abbildung 5.5.
5.2.1.2. Serielle Schnittstellen
Die MANVNode-Platine verfügt über mehrere seriellen Schnittstellen. Im äußeren Be-

reich der Platine ist eine serielle Schnittstelle (JP1) vorhanden, welche die Standard-
belegung des Programmierkabels des ADuC-7026-Evaluationsboards besitzt. Bereits
vorhandene Programmierkabel können somit ohne weiteres zur Programmierung des
Mikrocontrollers verwendet werden. Zusätzlich besteht die Möglichkeit, auf die serielle
Schnittstelle des ZigBit-Moduls zuzugreifen, worüber das Herunterladen von Firmwa-
re auf das Modul sowie Einstellung bestimmter Parameter – wie der Netzwerkkennung
des Gerätes – möglich ist. Der Zugriff erfolgt ebenfalls über die Stiftleiste JP1, aller-
dings müssen hierfür RX- und TX -Leitung des Programmierkabels vertauscht und alle
Jumper des Schalters S1 unterbrochen werden.
5.2.1.3. JTAG
Die MANVNode-Platine verfügt neben der seriellen auch über eine JTAG-Schnittstelle.
Die Beschaltung dieser ist in Abbildung 5.6 zu sehen. Diese ermöglich einen Zugriff
mit gängigen Programmierwerkzeugen wie z.B. Eclipse, Crossworks oder Kyle µVision.
Über die Schnittstelle kann sowohl Programmierung als auch Debugging des ADuC-
58
5.2. MANVNode
JTAG
VDD
TCK R3
100k
TDI R2
100k
R1
TRST
100k
JTAG
1 2
TRST 3 4
TDI 5 6
TMS 7 8
TCK 9 10
11 12
TDO 13 14
15 16
17 18
19 20
DGND
Abbildung 5.6.: Schaltplan der MANVNode: JTAG.
7026-Mikrocontrollers durchgeführt werden. Ein Zugriff auf das ZigBit Modul ist al-
lerdings nur indirekt möglich1 . Ein Zugriff über JTAG ist nicht vorgesehen.
5.2.1.4. LED-Anzeige
Die MANVNode-Platine verfügt insgesamt über 6 LEDs, die zur Anzeige des aktuellen
Zustands sowie zur Fehlerdiagnose dienen. Die Beschaltung dieser LEDs findet sich in
Abbildung 5.7.
1
Einige Werkzeuge bieten die Möglichkeit, eine Konsolenverbindung über den UART des ADuC-
7026-Mikrocontrollers zu öffnen, um direkt mit dem ZigBit-Modul zu kommunizieren.
59
5. Entwurf
BYELLOW
user interface
2
BUTTON_YELLOW
1
LED_RED
DGND RED
BBLUE
2
LED_YELLOW
YELLOW
BUTTON_BLUE
1
LED_GREEN
GREEN
DGND
LED_BLUE
BGREEN
2
BLUE
BUTTON_GREEN PIEZZO 2 1
1
PIEZZO
DGND DGND
BRED
2
BUTTON_RED
1
DGND
Abbildung 5.7.: Schaltplan der MANVNode: LED-Anzeige und Taster.
• PWR: Diese LED befindet sich direkt in der Spannungsversorgung der Platine.
Sie leuchtet, sobald die Platine mit Spannung versorgt wird.
• GREEN, YELLOW, RED: Diese LEDs sind direkt an den Mikrocontroller an-
geschlossen und visualisieren den Zustand des Zufallszahlengenerators entweder
durch dauerhaftes Leuchten (GREEN, YELLOW) oder im Alarmzustand durch
schnelles Blinken (RED).
• BLUE: Diese LED signalisiert, ob eine Alarmunterdrückung ( Mute“) besteht.

”
• ZIGBIT-STATUS: Diese LED leuchtet, sobald das ZigBit-Modul über das CTS-
Signal ( Clear to send“) die Bereitschaft, Daten zu empfangen, signalisiert.
”
60
5.2. MANVNode
5.2.1.4.1 Diagnosecodes
Neben den oben dargestellten einfachen Signalisierungen hat die Firmware der MANV-
Node-Platine die Möglichkeit, über die Kombination obiger LEDs Diagnose- und Feh-
lercodes auszugeben. Hierbei gilt folgende Codierung:
• GREEN blinkt in 1-Sekunden-Abständen: Der ADuC-7026-Mikrocontroller be-

findet sich im Bootmodus. Ein Reset des ZigBit-Moduls wurde durchgeführt und
es wird nun auf Bereitschaft des Moduls gewartet.
• Zweimaliges Blinken von YELLOW: Eine Verbindung mit dem ZigBit-Modul

wurde erfolgreich aufgebaut, es wird nun eine Initialisierung vorgenommen.
• RED, GREEN leuchten gleichzeitig: Das ZigBit-Modul wurde erfolgreich inita-

lisiert, auf die Verbindung mit dem Funknetzwerk wird gewartet.
• YELLOW leuchtet dauerhaft länger als 10 Sekunden und ZIGBIT-STATUS

leuchtet dauerhaft: Es kann keine Verbindung mit dem Funknetzwerk aufgebaut
werden.
• YELLOW leuchtet dauerhaft länger als 10 Sekunden und ZIGBIT-STATUS

leuchtet nicht: Es liegt eine Funktionsstörung des ZigBit-Moduls vor.
• ZIGBIT-STATUS leuchtet dauerhaft: Verbindung mit Funknetzwerk wurde ver-

loren oder Powersafe-Modus ist deaktiviert.
• ZIGBIT-STATUS blinkt im 2-Sekunden-Abstand: Die Platine arbeitet ordnungs-

gemäß, es besteht eine Verbindung mit dem Funknetzwerk und der Powersafe-
Modus ist aktiv.
5.2.2. Firmware
Die Firmware der MANVNode dient dem Entwickeln und Testen eines Treibers für das
ZigBit-Modul. Dieser Treiber wird später in den Erste-Hilfe-Sensor integriert werden.
Zusätzlich bietet die MANVNode Funktionalität, die zur Simulation des Erste-Hilfe-
Sensors gegenüber der MANVSuite dient. Hierzu sollen neben dem ZigBit-Treiber
folgende Funktionalitäten integriert werden:
• Zufallszahlengenerator zum Senden zufälliger Messwerte.
61
5. Entwurf
• Änderung des Zustands des Zufallszahlengenerators über Taster.
• Ansteuerung von LEDs zur Ausgabe des Zustands des Zufallszahlengenerators.
• Ansteuerung eines Piezzo-Summers zur Signalisierung von Alarmen.
5.2.2.1. Ansteuerung des UARTs
Zur Vermeidung von Busy-Waiting 2 soll der Treiber für den UART s als Interrupt-
Service-Routine3 (ISR) realisiert werden. Die Kommunikation zwischen Firmware und
UART -Treiber erfolgt über Ringpuffer: Zu sendende Daten werden von der Firmware
in den Sendepuffer gelegt. Sobald der UART sendebereit ist, soll der UART -Treiber
die zu sendenden Daten zeilenweise aus dem Ringpuffer entnehmen und an den UART
übertragen. Analog dazu funktioniert das Empfangen von Daten: Diese werden vom
UART -Treiber gelesen und zeilenweise in den Empfangspuffer gelegt. Die Firmware
kann diese nun zeilenweise aus dem Puffer lesen. Dies entspricht der Semantik einer
gepufferten, nicht blockierenden Ein-/Ausgabefunktion.
5.2.2.2. Ansteuerung des ZigBit-Modul
Das ZigBit-Modul ist via UART mit der MANVNode verbunden und wird über das
SerialNet-Protokoll angesprochen. Der Ablauf ist hierbei wie folgt:
1 Uebertrage aktuellen Status
2 Werte Antwort aus
3 Arbeite empfangene Befehle ab
4 Aktiviere den Energiesparmodus
Diese Schritte können entweder periodisch mittels eines Timer-Interrupts oder als
Hauptprogramm in einer Endlosschleife ausgeführt werden. Wichtig hierbei ist die Be-
rücksichtigung der in Abschnitt 4.4 beschriebenen Synchronisationsprobleme. Hierbei
soll wie folgt vorgegangen werden:
• Behandlung asynchron auftretender Ereignisse: Hierbei ist vor allem das DA-
TA-Ereignis wichtig, über das der Empfang von Befehlen von der MANVSuite
2
Warten auf ein Ereignis unter Verschwendung von Prozessorleistung.
3
Ein Interrupt ist eine von der Hardware ausgelöste Unterbrechungsanforderung der Software, welche
zum sofortigen Aufruf einer entsprechenden Interrupt Service Routine führt. Nach Beendigung
dieser Routine wird die Bearbeitung an der Stelle der Unterbrechung fortgesetzt.
62
5.2. MANVNode
commandBuffer initialisieren
Status = OK
Status von Sensor lesen
Alarm? Ja Alarmnachricht verschicken
Nein
Statusnachricht verschicken
Antwort von Funkmodul

lesen
Antwort ist Antwort in Commandbuffer

Nein
Statuscode? legen
Ja
Commandbuffer abarbeiten
Energiesparmodus aufrufen
Abbildung 5.8.: Ablauf der Ansteuerung des ZigBit-Moduls in der ZigBit-Firmware.
63
5. Entwurf
signalisiert wird. Alle anderen Ereignisse können zunächst vernachlässigt wer-

den. Ereignisse, die während des Wartens auf einen Statuscode auftreten, sollen
zur späteren Behandlung in einen Ringpuffer zwischengespeichert werden. Die
Abarbeitung soll dann nach Empfang des Statuscodes erfolgen.
• Behandlung komplexer Rückgabewerte: Im aktuellen Entwurf werden von der
Firmware der MANVNode keine SerialNet-Befehle verwendet, die eine komple-
xe Rückgabe haben, so dass dieses Problem eigentlich nicht auftreten sollte.
Sollten trotzdem komplexe Rückgaben auftreten, so werden diese wie asynchron
auftretende Ereignisse behandelt und in den Befehlspuffer gelegt. Bei der spä-
teren Auswertung des Befehlspuffers werden diese dann einfach verworfen. So
bleibt eine Synchronisation mit dem ZigBit-Modul in jedem Fall gewährleistet.
Die SerialNet-Firmware bietet die Möglichkeit, den Energiesparmodus entweder manu-

ell oder aber periodisch (mit konfigurierbaren Abständen und Dauer) aufzurufen (vgl.
Abschnitt 4.5). Für die MANVNode-Firmware wird der manuelle Aufruf verwendet,
da dieser deutlich flexibler und einfacher zu implementieren ist als der automatische
Modus: Sobald die Übertragung der Zustandsdaten abgeschlossen ist und alle empfan-
genen Befehle abgearbeitet wurden, ruft die Firmware über den Befehl AT+WSLEEP
den Energiesparmodus auf. Hierdurch ist gewährleistet, dass das ZigBit-Modul nur
so lange wie zur Bearbeitung aller Aufgaben notwendig in Betrieb ist. Nachdem das
ZigBit-Modul aus dem Energiesparmodus zurückkehrt, wird die Abarbeitung der An-
steuerungsroutine von vorne begonnen. Das Aufwachen aus dem Energiesparmodus
wird der MANVNode-Firmware über eine Zustandsänderung des CTS -Registers des
UART signalisiert. Zusätzlich wird der AT+WSLEEP Befehl mit dem Statuscode OK
quittiert, sobald das ZigBit-Modul wieder betriebsbereit ist.
Insgesamt ergibt sich für die Ansteuerung des ZigBit-Moduls folgender Ablauf:
1 Uebertrage aktuellen Status
2 Wiederhole :
3 Antwort von ZigBit - Modul lesen
4 Falls Antwort != Statusnachricht :
5 Antwort in Befehlspuffer legen
6 bis Antwort == Statusnachricht
7 Arbeite Befehlspuffer ab
8 Aktiviere den Energiesparmodus
64
5.3. ZigBee-USB-Stick
Dieser Ablauf ist in Abbildung 5.8 als Ablaufdiagramm dargestellt.
5.3. ZigBee-USB-Stick
Abbildung 5.9.: Schaltplan des USB-Sticks.
Der ZigBee-USB-Stick ist die Schnittstelle zwischen Sensornetz und Computer. Es

handelt sich um einen USB-Stick, der ein ZigBit-Modul beinhaltet. Zusätzlich sind
zwei weitere Bauteile enthalten, die das ZigBit-Modul mit Strom versorgen sowie eine
Umsetzung der UART -Schnittstelle des ZigBit-Moduls auf USB vornehmen. Für die
Stromversorgung ist es notwendig, die 5 V der USB -Schnittstelle auf die 3 V des Zig-
Bit-Moduls umzusetzen. Der Platinenentwurf des USB -Sticks ist in Abbildung 5.10
abgebildet.
In Verbindung mit einer Stromquelle wie z.B. einer Batterie oder eines USB -Netzteil
dient der ZigBee-USB-Stick gleichzeitig auch als ZigBee-Router. Der Betriebsmodus
65
5. Entwurf
ZDM-A1281-A2
U$1
100nF
4 3 C1
2 1
JP1
Abbildung 5.10.: Entwurf der Platine des USB-Sticks.
kann hierzu einfach mit Hilfe des Befehls AT+WROLE=1 auf den Routerbetrieb um-
gestellt werden.
5.4. MANVSuite
In der vorliegenden Diplomarbeit wird der Java-Treiber (MANVConnector ) entworfen
und implemtiert, der die Schnittstelle zwischen MANV-Suite und ZigBee-USB-Stick
bildet. Entwurf und Implementierung der MANVSuite selbst erfolgt in [Tepe10]. Ab-
bildung 5.11 beschreibt den Datenfluss zwischen MANVSuite, MANVConnectors und
MANVNode: Der MANVServer ist Teil der MANVSuite. Er dient als Vermittlungs-
stelle zwischen den einzelnen Softwarekomponenten, die mittels Corba an diesen ange-
bunden sind. Eine dieser Komponenten ist der MANVConnector, der in Abschnitt 5.5
genauer beschrieben wird. Dieser greift mittels einer seriellen Schnittstelle (in der
66
5.5. MANVConnector
MANVSuite
MANVServer
Corba
MANVConnector
(Java)
MANVConnector
TCP/IP - Socketverbindung
Serial2Socket
(Python)
TTY-Verbindung
USB-Serial
(Linux Kerneltreiber)
USB
ZigBee-USB-Stick
USB-zu-RS232
Wandler (CP2102)
UART-Verbindung
ZigBit-Modul
ZigBee-Verbindung
ZigBit-Modul
MANVNode
UART-Verbindung
ADuC-Microcontroller
Abbildung 5.11.: Datenfluss zwischen den einzelnen Kompnenten des Gesamtsystems.
Abbildung als TTY-Verbindung bezeichnet) auf den in Abschnitt 5.3 beschriebene

ZigBee-USB-Stick zu, welcher wiederum die Verbindung zu dem ZigBee-Netzwerk her-
stellt. Auf diese Weise kommt die Verbindung zwischen MANVSuite und MANVNode
zu Stande.
67
5. Entwurf
MANVConnector
new()
new()
new()
resultQueue commandQueue eventQueue
new()
new()
socketWriter
socketReader
initCORBA
take()
readLine()
return command
writeLine()
return data
put(event)
new()
getLastResult() corbaSender
return result
take()
return event
return result
put(result)
Abbildung 5.12.: Interaktion der einzelnen Threads des MANVConnectors
5.5. MANVConnector
Der MANVConnector hat einerseits die Aufgabe, Daten, die von dem ZigBee-USB-
Connector empfangen wurden, in Corba-Events umzusetzen und an den MANVServer
68
5.5. MANVConnector
weiterzuleiten. Andererseits empfängt sie Corba-Events vom MANVServer, dekodiert

diese und sendet sie in Form von Sensornetz-Befehlen an die zuständigen MANVNodes
weiter. Das vollständige UML-Klassendiagramm findet sich in Abbildung 5.15.
5.5.1. Threads
Wie aus Abbildung 5.17 zu entnehmen ist, verfügt der MANVConnector neben dem
Hauptthread über drei weitere Threads:
• SocketWriter : Dieser Thread entnimmt Befehle aus der CommandQueue und

sendet diese über den ZigBee-USB-Stick an das Sensornetz. Nun blockiert der
Thread so lange, bis das Ergebnis des Befehls zur Verfügung steht oder eine
bestimmte Zeitgrenze überschritten wurde. Sobald dies der Fall ist, wird der
Befehl zusammen mit dem Ergebnis in die ResultQueue eingefügt.
• SocketReader : Dieser Thread empfängt Daten aus dem Sensornetz. Handelt es

sich um ein Ergebnis, so wird dies dem SocketWrite signalisiert, und das Ergebnis
zur Abholung zur Verfügung gestellt. Handelt es sich hingegen um ein Ereignis,
so wird dieses in die EventQueue eingefügt.
• CorbaSender : Dieser Thread ist für die Kommunikation mit MANVServer zu-
ständig. Befehle, die vom MANVServer empfangen werden, werden für das Sen-
sornetz aufbereitet und in die CommandQueue eingestellt. Außerdem werden
Ereignisse aus der EventQueue entnommen, in Corba-Events übersetzt und an
den MANVServer zugestellt.
Die Kommunikation der Threads untereinander findet komplett über die oben genann-
ten Warteschlangen statt. Das Zusammenwirken der Threads ist in Abbildung 5.12
dargestellt:
Zunächst erzeugt der Hauptthread (MANVConnector.main) die drei Warteschlangen.

Dannach werden die beiden Threads SocketWriter und SocketReader erstellt. Dannach
ruft der Hauptthread die CORBA-Initialisierungsroutine auf und startet den Corba-
Sender -Thread.
69
5. Entwurf
Beim Starten der Threads wird sichergestellt, dass diese alle Zugriff auf alle drei Warte-
schlangen haben. Die konsequente Verwendung der Warteschlangen zur Kommunika-
tion der Threads untereinander löst bereits viele Synchronisierungsprobleme. Grund-
sätzlich findet Kommunikation zwischen den Threads rein über die Warteschlangen
statt. Einzige Ausnahme ist das Abrufen des Ergebnisses eines gesendeten Komman-
dos.
5.5.2. Repräsentation eines ZigBit-Moduls

<<Interface>>
iZigBit
getNodeID: int
getMacID: int
sendData(data: String): MANVResult
isendData(data: String)
toggleAlertStatus: MANVResult
disableAlert: MANVResult
enableAlert: MANVResult
muteAlert: MANVResult
itoggleAlertStatus: void
idisableAlert: void
ienableAlert: void
imuteAlert: void
ZigBit readonlyZigBit
zigBitMap: HashMap<Integer, ZigBit> id: int
macMap: HashMap<Integer, Integer> readOnlyZigBit(nodeID: int)
ZigBit(nodeID : int) getNodeID: int
getNodeID: int getMacID: int
getMacID: int sendData(data: String): MANVResult
setCommandQueue(commandQueue: BlockingQueue<MANVCommand>) toggleAlertStatus: void
get(id: int): iZigBit enableAlertStatus: void
getByMacID(macID: int): iZigBit disableAlert: void
discover: iZigBit muteAlert: void
sendUntilSuccess(data: String): MANVResult
enableAlertStatus: MANVResult
mutAlert: MANVResult
requestMacID: int
Abbildung 5.13.: Klassendiagramm der ZigBit-Klassen
Abbildung 5.13 zeigt die Klassenrepräsentation der ZigBit-Module. Da es nicht immer

möglich ist, Daten an einen ZigBit-Knoten zu senden (dies ist z.B. dann der Fall, wenn
es sich um einen Router handelt), gibt es zwei Arten von ZigBit-Knoten: ZigBit und
readonlyZigBit. Um diese trotzdem generisch ansprechen zu können, implementieren
beide das Interface iZigBit. Eine genauere Beschreibung der Attribute und Methoden
der ZigBit-Klassen findet sich in Abschnitt A.1.3.5.1.
70
5.5. MANVConnector
5.5.3. Synchronisierung der Befehlsübertragung

Bei der Kommunikation mit dem auf dem USB-Stick aufgebrachten ZigBee-Modul stel-
len sich grundsätzlich die selben Synchronisierungsprobleme wie in der MANVFirm-
ware. Da der MANVConnector jedoch alle Möglichkeiten der Java Virtual Machine
nutzen kann, lassen sich diese deutlich einfacher und eleganter lösen.
In der MANVFirmware werden hierzu mehrere Ringpuffer verwendet, welche die emp-
fangenen Daten speichern. Dieser Ansatz findet sich auch im MANVConnector wieder.
Hierbei werden jedoch an Stelle von Ringpuffern priorisierte Warteschlangen, soge-
nannte Queues verwendet.
• Die Command Queue: In dieser Queue werden alle zu sendenden Befehle gespei-
chert.
• Die Event Queue: In dieser Queue werden alle empfangenen Ereignisse gespei-
chert.
• Die Result Queue: In dieser Queue werden alle bereits gesendeten Befehle zu-
sammen mit dem Resultat, das dieser Befehl hatte, gespeichert.
Jedes Element der einzelnen Queues verfügt über eine Priorität; die Queues sorgen
dafür, dass der Zugriff nach Priotität sortiert erfolgt. Hierdurch wird sicher gestellt,
dass wichtige Ereignisse wie z.B. Alarme bevorzugt ausgeliefert werden.
Bei der Befehlsübertragung muss darauf geachtet werden, dass ein Befehl erst dann
gesendet werden darf, wenn die Abarbeitung aller vorherigen Befehle erfolgt ist, da
sonst die Synchronität mit dem ZigBit-Modul nicht mehr gewährleistet ist. Da inner-
halb des MANVConnectors das Senden in einem anderen Thread geschieht als das
Empfangen, erfordert dies besondere Maßnahmen:
Um die Synchronisation zu gewährleisten, bietet der Thread SocketReader eine Schnitt-
stelle, über die der SocketSender das Ergebnis des letzten gesendeten Befehls abholen
kann. Diese Schnittstelle verwendet ein sogenanntes Latch, also eine Art von Barriere,
um den abholenden Thread so lange zu blockieren, bis eine Antwort vorliegt. Von dem
SocketSender wird nun verlangt, dass er nach jedem gesendeten Befehl diese Schnitt-
stelle verwendet, um das Ergebnis des gerade gesendeten Befehls abzuholen. Da der
Sender nun so lange, bis das Ergebnis vorliegt, blockiert ist, kann er auch keine wei-
teren Befehle senden. Hierdurch wird die geforderte Synchronisierung erreicht. Durch
71
5. Entwurf
die JVM ist ein korrektes Verhalten des Latches sowie der zur Priorisierung verwende-
ten Warteschlangen garantiert. Dieser Sachverhalt ist auch nochmal in Abbildung 5.12
dargestellt.
Die vom SocketReader gelesenen Ergebnisse und Ereignisse werden selbst wieder durch
Objekte repräsentiert.
5.5.4. Ergebnisse und Ereignisse

<<interface>>
Comparable
compareTo(o: object): int
MANVPrioritized
priority: int
compareTo(o: MANVPrioritized): int MANVChildJoined
source: iZigBit
MANVChildLost(raw: String)
isImportant: boolean
createCorbaMessages: AbstractList<CorbaMessageContainer>
MANVCommand MANVEvent
command: String raw: String
result: MANVResult MANVEvent(raw: String)
id: int isResult: boolean
maxId: static int MANVChildLost
resultLatch: CountDownLatch fromString(raw: String): MANVEvent source: iZigBit
MANVCommand(command: String, priority: int) createCorbaMessages: AbstractList<CorbaMessageContainer> MANVChildLost(raw: String)
getCommand: String toString: String isImportant: boolean
getUniqueId: int getRaw: String createCorbaMessages: AbstractList<CorbaMessageContainer>
setResult(result: MANVResult)
getResult: MANVResult
MANVResult MANVDataReceived
status: boolean source: iZigBit
subResult: MANVResult data: String
MANVResult(raw: String, subResult: MANVResult) MANVDataReceived(raw: String)
getData: String isImportant: boolean
isResult: boolean parseRaw(raw: String)
isComposite: boolean
getChildList(commandQueue: BlockingQueue<MANVCommand>): AbstractList<CorbaMessageContainer>
getSubResult(result: MANVResult, toString: String): MANVResult
MANVChildrenList MANVGsn MANVStatusMessage

MANVChildrenList(raw: String) myRaw: String pulse: short
isComposite: boolean MANVGsn(raw: String) breathing: short
getChildList(commandQueue: BlockingQueue<MANVCommand> isCcomposite: boolean alertStatus: HashMap<Integer, Integer>
addSubResult(result: MANVResult) getData: String MANVStatusMessage(raw: String)
addSubResult(result: MANVResult) parseRaw(raw: String)
toString: String
Abbildung 5.14.: Klassendiagramm der Ereignisse und Ergebnisse des MANVConnectors.
Wie aus Abbildung 5.14 zu entnehmen ist, wird zwischen folgenden Ergebnissen und
Ereignissen unterschieden:
• MANVEvent: Allgemeines Event.
• MANVChildJoined: Ein neuer Sensor hat das Netzwerk betreten.
• MANVChildLost: Ein Sensor hat die Verbindung zum Netzwerk verloren.
• MANVDataReceived: Es wurden Daten von einem Sensor empfangen.
72
5.5. MANVConnector
• MANVStatusMessage: Es wurde eine Satusnachricht von einem Sensor empfan-

gen. Diese beinhaltet neben dem Alarmzustand Werte für Puls- und Atemfre-
quenz.
• MANVResult: Allgemeines Ergebnis eines gesendeten Befehls.
• MANVChildrenList: Enthält eine Liste mit Kindknoten als Ergebnis auf den
Befehl AT+WCHILDREN.
• MANVGsn: Enthält die GSN (Hardwareadresse) eines entfernten Knotens.
Eine genauere Beschreibung der Attribute und Methoden dieser Klassen erfolgt in
Abschnitt A.1.3.3.
73
5. Entwurf
SocketReader
eventQueue: BlockingQueue<MANVEvent>
lastResult: MANVResult
result
resultSemaphore: Semaphore
serialIn: BufferReader
SocketReader(serialIn: BufferedReader, eventQueue: BlockingQueue<MANVEvent>)
setLastResult(MANVResult: result)
getLastResult(MANVResult: result)
run: void
eventQueue
<<Interface>>
iZigBit
getNodeID: int
getMacID: int
isendData(data: String)
enableAlert: MANVResult
muteAlert: MANVResult
itoggleAlertStatus: void
idisableAlert: void
ienableAlert: void
imuteAlert: void
readonlyZigBit
id: int
readOnlyZigBit(nodeID: int)
<<interface>> getNodeID: int
Comparable getMacID: int
compareTo(o: object): int sendData(data: String): MANVResult
toggleAlertStatus: void
enableAlertStatus: void
disableAlert: void
muteAlert: void
MANVPrioritized
priority: int
compareTo(o: MANVPrioritized): int
MANVCommand MANVEvent
command: String raw: String
result: MANVResult MANVEvent(raw: String)
id: int isResult: boolean corbaMessages
maxId: static int isImportant: boolean
resultLatch: CountDownLatch fromString(raw: String): MANVEvent
MANVCommand(command: String, priority: int) createCorbaMessages: AbstractList<CorbaMessageContainer>
getCommand: String toString: String
getUniqueId: int getRaw: String
setResult(result: MANVResult)
getResult: MANVResult
result
MANVResult
status: boolean
subResult: MANVResult
MANVResult(raw: String, subResult: MANVResult)
getData: String
isResult: boolean
isComposite: boolean
getChildList(commandQueue: BlockingQueue<MANVCommand>): AbstractList<CorbaMessageContainer>
getSubResult(result: MANVResult, toString: String): MANVResult
MANVChildrenList MANVGsn
MANVChildrenList(raw: String) myRaw: String
isComposite: boolean MANVGsn(raw: String)
getChildList(commandQueue: BlockingQueue<MANVCommand> isCcomposite: boolean
addSubResult(result: MANVResult) getData: String
addSubResult(result: MANVResult)
Abbildung 5.15.: Klassendiagramm des MANV-Connectors (Linke Seite)
74
5.5. MANVConnector
Thread
run: void
SocketWriter CorbaSender
commandQueue: BlockingQueue<MANVCommand> eventQueue: BlockingQueue<MANVEvent>
resultQueue: BlockingQueue<MANVCommand> serverIncoming: Incoming
serialOut: PrintWriter CorbaSender(eventQueue: BlockingQueue<MANVEvent>, serverIncoming: Incoming)
reader: SocketReader run: void
lastResult: MANVResult
SocketWriter(serialOut: PrintWriter, commandQueue: <MANVCommand>, reader: SocketReader)
writeLine(line: String)
run: void
commandQueue
eventQueue
result
BlockingQueue<MANVEvent> BlockingQueue<MANVCommand> CORBA_Node
eventQueue
MANVConnector CommandsImpl
commandQueue
commandQueue: BlockingQueue<MANVCommand> disableAlert(node: CORBA_Node)
eventQueue: BlockingQueue<MANVEvent> enableAlert(node: CORBA_Node)
resultQueue: BlockingQueue<MANVCommand> toggleAlert(node: CORBA_Node)
commandsImpl
corbaSender: CorbaSender mute(node: CORBA_Node)
commandsImpl: CommandsImpl
main(args: String[]): void
ZigBit
zigBitMap: HashMap<Integer, ZigBit>
macMap: HashMap<Integer, Integer>
ZigBit(nodeID : int)
getNodeID: int
getMacID: int
setCommandQueue(commandQueue: BlockingQueue<MANVCommand>)
get(id: int): iZigBit
getByMacID(macID: int): iZigBit
discover: iZigBit
sendUntilSuccess(data: String): MANVResult
enableAlertStatus: MANVResult
mutAlert: MANVResult
requestMacID: int
source source
MANVDataReceived MANVChildLost MANVChildJoined

source: iZigBit source: iZigBit source: iZigBit
data: String MANVChildLost(raw: String) MANVChildLost(raw: String)
MANVDataReceived(raw: String) isImportant: boolean isImportant: boolean
isImportant: boolean createCorbaMessages: AbstractList<CorbaMessageContainer> createCorbaMessages: AbstractList<CorbaMessageContainer>
parseRaw(raw: String)
CorbaMessageContainer
send(serverIncoming: Incoming)
MANVStatusMessage CorbaDataMessageContainer CorbaEventMessageContainer

pulse: short message: CORBA_DataMessage message: CORBA_EventMessage
breathing: short CorbaDataMessageContainer(message: CORBA_DataMessage) send(serverIncoming: Incoming)
alertStatus: HashMap<Integer, Integer> send(serverIncoming: Incoming) toString: String)
MANVStatusMessage(raw: String) toString: String
parseRaw(raw: String)
toString: String
Abbildung 5.16.: Klassendiagramm des MANV-Connectors (Rechte Seite)
75
Thread
run: void
SocketReader SocketWriter CorbaSender
eventQueue: BlockingQueue<MANVEvent> commandQueue: BlockingQueue<MANVCommand> eventQueue: BlockingQueue<MANVEvent>
lastResult: MANVResult resultQueue: BlockingQueue<MANVCommand> serverIncoming: Incoming
resultSemaphore: Semaphore serialOut: PrintWriter CorbaSender(eventQueue: BlockingQueue<MANVEvent>, serverIncoming: Incoming)
serialIn: BufferReader reader: SocketReader run: void
SocketReader(serialIn: BufferedReader, eventQueue: BlockingQueue<MANVEvent>) lastResult: MANVResult
setLastResult(MANVResult: result) SocketWriter(serialOut: PrintWriter, commandQueue: <MANVCommand>, reader: SocketReader)
getLastResult(MANVResult: result) writeLine(line: String)
run: void run: void
commandQueue
eventQueue
eventQueue BlockingQueue<MANVEvent> BlockingQueue<MANVCommand>
eventQueue
CorbaMessageContainer
MANVConnector CORBA_Node
send(serverIncoming: Incoming) commandQueue
commandQueue: BlockingQueue<MANVCommand>
eventQueue: BlockingQueue<MANVEvent>
resultQueue: BlockingQueue<MANVCommand>
commandsImpl
corbaSender: CorbaSender
commandsImpl: CommandsImpl
main(args: String[]): void CommandsImpl
disableAlert(node: CORBA_Node)
enableAlert(node: CORBA_Node)
toggleAlert(node: CORBA_Node)
CorbaDataMessageContainer CorbaEventMessageContainer mute(node: CORBA_Node)
message: CORBA_DataMessage message: CORBA_EventMessage
CorbaDataMessageContainer(message: CORBA_DataMessage) send(serverIncoming: Incoming)
send(serverIncoming: Incoming) toString: String)
toString: String
Abbildung 5.17.: Klassendiagramm der Threads des MANVConnectors
5. Entwurf
76
6. Praktische Realisierung des
Sensornetzes
In diesem Kapitel wird die Implementierung des Sensornetzes, dabei auftretende Pro-
bleme sowie deren Lösungen, beschreiben.
6.1. Hardware
Nachfolgend wird die praktische Umsetzung der zwei verschiedenen Hardwarekom-
ponenten, also des MANV-USB-Sticks (Abbildung 6.1) und der MANVNode (Abbil-
dung 6.2) beschrieben. In beiden Fällen musste hierzu ein ZigBit-Modul mit einer
anderen Hardwarekomponente verbunden werden. Dies kann grundsätzlich entweder
über SPI oder UART erfolgen. Bei SPI handelt es sich um einen seriellen Bus, der
besonders im Bereich der Mikrocontroller verbreitet ist, und zur Anbindung von wei-
terer Peripherie dient. UART war hingegen vor allem als serielle Schnittstellen an
PCs verbreitet, und wurde hauptsächlich für die Anbindung von Modems verwendet.
Heutzutage wurde diese Schnittstelle weitestgehend von USB verdrängt. Beim Einsatz
der SerialNet-Firmware scheidet die Anbindung über SPI jedoch aus, da dies von der
Firmware nicht unterstützt wird.
6.1.1. Anbindung des ZigBit-Moduls an den USB-Port

Zur Realisierung des USB-Sticks bietet sich die Verwendung des UARTs an, da eine
breite Palette von fertigen ICs zur Verfügung steht, mit deren Hilfe ein UART an
6. Praktische Realisierung des Sensornetzes
einen USB-Bus angebunden werden kann. Auf Seiten des Betriebssystems präsentiert
sich der IC wie ein serieller Port und kann softwareseitig wie ein solcher angespro-
chen werden. Die Firma Embedded Projects bietet mit der USB-UART-Bridge eine
fertige Lösung an, auf der ein entsprechender IC, ein Spannungsregler für 3.3 V-
Versorgungsspannung sowie ein USB-Anschluss bereits integriert sind. Das ZigBit-
Modul wird nun auf die in Abbildung 5.10 dargestellte Platine aufgelötet. Diese Pla-
tine kann nun selbst mit Hilfe einer Stiftleiste huckepack auf die USB-UART-Bridge
aufgelötet werden, um die nötige Formstabilität zu erhalten.
6.1.2. Herstellung und Bestückung der Platine der MANV-

Node
Auch bei der MANVNode erfolgt eine Anbindung des ZigBit-Moduls über UART.
Hierbei muss beachtet werden, dass der UART auch für das Flashen des Microcon-
trollers benötigt wird. Daher verfügt die Platine über eine Reihe von Jumpern, mit
denen das ZigBit-Modul vom UART abgetrennt werden kann.
Der ADuC-7026-Mikrocontroller benötigt drei 470 nF-Kondensatoren zur Stabilisie-

rung der Stromversorgung. Diese waren in den ersten beiden Versionen der Platine
zu weit vom Mikrocontroller entfernt aufgebracht worden, was dazu führte, dass der
Mikrocontroller beim Flashvorgang, dazu neigte, spontan abzustürzen. Dieser Fehler
konnte durch die Verringerung des Abstandes zwischen Mikrocontroller und Konden-
satoren behoben werden.
6.2. Firmware
Die Firmware des Erste-Hilfe-Sensors wurde um einen Treiber für das ZigBit-Modul
ergänzt. Die Firmware wurde in der Programmiersprache C geschrieben, und setzt
direkt auf die Hardware des ADuC auf. Es wurde lediglich die von Rowley Cross-
works angebotene Standardbibliothek verwendet, die einige praktische Funktionen wie
Stringmanipulation, einen Interrupthandler und einen fertigen Startup-Code bietet.
Die Entwicklung von Software für einen Microcontroller zeichnet sich durch die Ab-
wesenheit eines Betriebssystems aus. Ein Großteil der Funktionalität, die man von
der Entwicklung von Software für einen gewöhnlichen Mikrocomputer gewohnt ist, ist
78
6.2. Firmware
Abbildung 6.1.: MANV-USB-Stick.
schlichtweg nicht vorhanden. Hier sind insbesondere eine automatische Speicherver-

waltung sowie Threads und Prozesse zu erwähnen. Da der Erste-Hilfe-Sensor viele
Aufgaben gleichzeitig erfüllen muss, stellt dies eine ernst zu nehmende Herausforde-
rung dar. Das Problem wurde durch ein Interrupt-getriebenes Programmiermodell ge-
löst. Zu beachten sind hierbei die sehr beschränkten Ressourcen des Mikrocontrollers.
Insbesondere der Speicher ist mit 16 kB sehr knapp bemessen.
79
Abbildung 6.2.: Fertig bestückte Platine der MANVNode.
6.2.1. Verwendete Interrupts
Es werden folgende Interrupts verwendet:
Timer0 : Dieser Timer-Interrupt führt die Patientenüberwachung durch. Die einzelnen

Sensoren werden abgefragt, und eine Analyse der empfangenen Daten wird durchge-
führt.
80
6.2. Firmware
Timer1 : Dieser Interrupt führt einige periodische Aufgaben durch. Zunächst werden
die am Sensor vorhandenen Taster abgefragt (Alarm stumm schalten, Alarm manuell
auslösen etc.). Danach wird überprüft, in welchem Zustand der Sensor sich aktuell
befindet, also z.B. ob ein Alarm aufgetreten ist oder ob der Patient sich in einem
guten Zustand befindet. Abhängig hiervon werden nun LEDs und ein angeschlosse-
ner Piezo-Summer geschaltet, um den Zustand nach außen zu signalisieren. Zuletzt
wird noch überprüft, wann zuletzt eine Übertragung des Zustands des Sensors an die
MANVSuite erfolgt ist. Liegt dies länger als ein konfiguriertes Zeitintervall zurück,
so wird eine Übertragung des aktuellen Zustands veranlasst. Ein sinnvolle Länge für
dieses Zeitintervall ist ein Wert von 5-10 s.
6.2.1.1. Zugriff auf UART
Der ADuC verfügt über einen UART-Interrupt, welcher eine Statusänderung des
UARTs signalisiert. Im Register COMIEN0 wird konfiguriert, welche Zustände über
den Interrupt signalisiert werden sollen. Tritt nun einer dieser Zustände auf, so wird
der UART-Interrupt ausgelöst. In der ISR muss nun überprüft werden, welches Er-
eignis zum Auslösen des Interrupts geführt hat. Diese Information ist im Register
COMSTA0 gespeichert. Wichtig ist an dieser Stelle, dass auch mehrere Ereignisse
gleichzeitig auftreten können. Dies muss in der ISR berücksichtigt werden, da sonst
Ereignisse verloren gehen können.
Das eigentliche Senden und Empfangen erfolgt über die beiden Register COMRX und
COMTX. Zum Senden wird hierzu ein einzelnes Zeichen in COMTX gelegt. Nun muss
eine gewisse Zeit gewartet werden, bis das Zeichen gesendet wurde und das nächs-
te Zeichen in COMTX gelegt werden kann. Für das Empfangen wird das Register
COMRX in analoger Weise verwendet. Ob das nächste Zeichen empfangen bzw. ge-
sendet werden kann, kann mit Hilfe der Bits DR ( Data Ready“ - Daten liegen vor)
”
bzw. TEMT ( Transmit Buffer empty“ - Daten können gesendet werden) bestimmt
”
werden.
Die einfachste Methode wäre hierbei, in einer Schleife Busy-Waiting zu betreiben

und so lange zu warten, bis sich eins der beiden Bits verändert. Dies wäre jedoch
sehr aufwendig und würde den Mikrocontroller unnötig lange blockieren. Statt dessen
wird der Zustand der beiden Register nur dann überprüft, wenn ein UART-Interrupt
aufgetreten ist.
81
Zum Senden und Empfangen von Daten werden zwei Ringpuffer verwendet. Möchte ein
Unterprogramm Daten senden, so greift es nicht direkt auf die UART -Schnittstelle zu,
sondern legt diese Daten lediglich in den Sendepuffer. Das eigentliche Senden wird nun
vom UART-Interrupthandler durchgeführt; das Unterprogramm kann weiter arbeiten,
ohne auf das fertige Senden der Daten warten zu müssen.
Das Empfangen von Daten erfolgt analog. Jedesmal, wenn ein Zeichen von der se-
riellen Schnitstelle empfangen wurde, wird dieses in den Empfangspuffer gelegt. Das
Abarbeiten des Empfangspuffers erfolgt nun als Idle-Task : Immer dann, wenn der Mi-
krocontroller gerade keine anderen Aufgaben erfüllen muss, wird der Empfangspuffer
abgearbeitet und eventuell empfangene Befehle werden ausgeführt. Dies kann natürlich
jederzeit durch die Behandlung von Interrupts unterbrochen werden.
6.3. MANVConnector
Die folgenden Abschnitte beschreiben, wie der Zugriff vom MANVConnector auf den
MANV-USB-Stick konkret erfolgt. Der MANV-USB-Stick verhält sich hierbei dem
Betriebssystem gegenüber wie eine serielle Schnittstelle.
6.3.1. Zugriff auf die serielle Schnittstelle

Der Zugriff auf die serielle Schnittstelle mittels Java bringt einige praktische Probleme
mit sich. Der Java-Standard bietet von Haus aus keine Möglichkeit, auf die serielle
Schnittstelle zuzugreifen. Zwar gibt es einzelne Lösungen von Drittanbietern wie z.B.
RxTx oder JavaComm, allerdings sind diese meist plattformabhängig und funktionie-
ren meist nur auf wenigen Betriebssystemen. Da die in dieser Diplomarbeit entworfene
Lösung auf möglichst vielen Betriebssystemen einsetzbar sein soll, wurde entschieden,
den Zugriff auf die serielle Schnittstelle stattdessen in einem austauschbaren Modul zu
kapseln. Der Zugriff auf das Modul erfolgt über eine Socketverbindung, welche in Java
standardmäßig verfügbar ist. Das Modul kann nun in jeder beliebigen Programmier-
sprache implementiert werden. Es ist z.B. möglich, für verschiedene Betriebssysteme
verschiedene Module anzubieten. Für die Zwecke dieser Diplomarbeit wurde beispiel-
haft ein Modul für UNIX in der Programmiersprache Python implementiert, welche
unter vielen UNIX -artigen Betriebssystemen wie Linux, MacOS, BSD und co. bereits
zur Standardinstallation gehört. Lediglich das PySerial -Modul muss nachinstalliert
werden.
82
6.3. MANVConnector
1 # !/ usr / bin / env python - OO

2 # MANV - Sensor - Serial to socket
3 # for Java to ZigBit connector
5 PORT = 4711 # # Port fuer Socketverbindung .

6 import serial , socket , select , sys , SocketServer , time
8 class MA N V S e r i a l T o S o c k e t H a n d l e r ( SocketServer .\
9 BaseRequestHandler ):
11 def handle ( self ):

12 # # Handler - Hook , in den der SocketServer einsteigt
13 print " Connection to socket opened "
14 self . openSerial ()
16 print " Serial connected "

17 self . tunnel ()
19 def openSerial ( self ):

20 # # Serielle Schnittstelle oeffnen .
21 # # Welche das genau ist , wird auf der Kommandozeile
22 # # als Parameter uebergeben .
23 self . serial = serial . Serial ( sys . argv [1] , 38400 ,
24 timeout =1)
26 def shutdown ( self ):

27 # # Socket - Verbidung wird geschlossen -> aufraeumen
28 self . serial . close ()
30 def tunnel ( self ):

31 # # Weiterleiten von Daten :
32 # # Socket -> Serial
33 # # Serial -> Socket
34 end = False
35 print " Entering tunnel mode "
83
37 while not end :

38 # # Select verwenden , um socket und seriellen
39 # # Port ressourcensparend zu ueberwachen .
40 # # Funktioniert leider nur unter UNIX .
41 readylist = select . select (( self . request ,
42 self . serial ) ,
43 () , ())
45 # # Behandeln aller empfangenen Daten

46 for readysocket in readylist [0]:
48 ## Fallunterscheidung zwischen seriellem

49 ## Port und Socket , da hier die
50 ## Semantik unterschiedlich ist .
51 if readysocket == self . serial :
53 # # Daten wurden auf seriellem Port

54 # # empfangen -> auf socket schreiben .
55 data = self . serial . read (1024)
56 self . request . send ( data )
58 elif readysocket == self . request :
60 # # Daten wurden auf Socket empfangen

61 # # -> auf seriellen Port schreiben
62 data = self . request . recv (1024)
64 if data :
65 self . serial . write ( data )
67 else :
68 # # EOF empfangen -> shutdown
69 end = True
71 # # select hat etwas zurueck geliefert , das

72 # # weder Socket noch serieller Port ist
84
6.3. MANVConnector
73 # # -> shutdown
74 else :
75 data = " "
76 end = True
78 # # Daten zu Debuggingzwecken auf Konsole

79 # # ausgeben .
80 print data
82 # # Aufraeumen : Seriellen Port schliessen

83 self . serial . close ()
84 self . request . close ()
85 print " Leaving tunnel mode "
88 class ReusableServer ( SocketServer . TCPServer ):
90 def server_bind ( self ):

91 # # Socket wiederverwendbar machen .
92 # # Wenn man das nicht tut , ist er nach Beenden
93 # # des Programms fuer 5 Minuten nicht ansprechbar .
94 self . socket . setsockopt ( socket . SOL_SOCKET ,
95 socket . SO_REUSEADDR , 1)
96 self . socket . bind ( self . server_address )
98 # # Einstiegspunkt
99 if __name__ == ’ __main__ ’:
100 server = ReusableServer (( ’ localhost ’ , PORT ) ,
101 MANVSerialToSocketHandler )
102 server . serve_forever ()
Für die Überwachung von Socket und seriellem Port wird in diesem Programm der
Systemaufruf select() verwendet. Wird dieser aufgerufen, gibt das Programm so lange
den Prozessor für andere Programme frei, bis Daten empfangen wurden. Sobald dies
der Fall ist, kehrt der select()-Aufruf zurück und liefert eine Liste mit allen Quellen,
von denen Daten empfangen wurden. Diese können nun mit den entsprechenden Auf-
85
rufen von recv() (im Falle von Sockets) bzw. read() (für den seriellen Port) abgeholt
werden. Diese Lösung funktioniert jedoch in dieser Form nur unter UNIX. Unter Win-
dows steht der select()-Aufruf zwar zur Verfügung, jedoch ist es hier nicht möglich,
diesen zur Überwachung des seriellen Ports zu verwenden. Das obige Programm lässt
sich hier jedoch recht einfach durch die Verwendung von Threads anpassen, indem
für jede Richtung (also Seriell → Socket und Socket ← Seriell) jeweils ein eigener
Thread verwendet wird. Alternativ empfiehlt sich eine Implementierung mit Hilfe der
Programmiersprache C++.
6.3.2. Automatische Erkennung des ZigBit-USB-Sticks

Bei der Verwendung von USB -Geräten stellt sich bei vielen Betriebssystemen das Pro-
blem, dass die Benennung bei jedem Einstecken des Gerätes anders sein kann. Dies
kann insbesondere dann auftreten, wenn mehrere gleichartige Geräte am USB-Bus
(z.B. mehrere USB-Serial -Geräte) vorhanden sind. Um nicht nach jedem Einsteck-
vorgang oder Neustart des Betriebssystems die Konfiguration des MANV-Connectors
anpassen zu müssen, wird der Name des USB -Sticks nicht fest konfiguriert, sondern
stattdessen eine automatische Erkennung durchgeführt. Unter Linux stehen mit libusb
und dem /sys-Dateisystem zwei geeignete Werkzeuge zur Verfügung, um diese Erken-
nung durchzuführen.
Zunächst werden mit Hilfe der libusb alle USB-Busse nach dem auf dem ZigBit-USB-
Stick verwendeten IC vom Typ cp210x durchsucht. Dieser hat die Herstellerkennung
0x10C4 und die Produktkennung 0xEA60. Unter Python steht mit python-usb eine
geeignete Schnittstelle zu libusb zur Verfügung.
1 import usb
2 def searchUSB ( self ):
4 # # Durchsuchen alle USB - Busse

5 for bus in usb . busses ():
7 # # Durchsuchen aller Geraete dieses Busses

8 for dev in bus . devices :
10 # # Betrachten der Vendor - ID und der Produkt - ID

11 if dev . idVendor == 0 x10c4 and \
86
6.3. MANVConnector
12 dev . idProduct == 0 xea60 :
14 # # Ein entsprechendes Geraet wurde

15 # # gefunden wir geben dieses
16 # # zurueck
17 return ( bus . dirname , dev . filename )
19 print " No devices found on USB - Bus . "

20 return False
Wenn am USB-Bus kein entsprechendes Gerät gefunden wurde, kann bereits jetzt
die Suche abgebrochen werden. Wird jedoch ein passendes Gerät gefunden, müssen
zunächst alle passenden Device-Nodes 1 im /dev -Verzeichnis gefunden werden. Hierzu
bietet sich eine Suche im /sys-Dateisystem an. Hierfür sind keine externen Module not-
wendig, es können die normalen Dateisystem-Operationen des OS -Moduls verwendet
werden:
1 import os
2 def searchSYS ( self ):
4 # # Suchen aller usb - serial - Geraete ueber / sys

5 devices = []
7 for device in \
8 os . listdir ( ’/ sys / bus / usb - serial / devices ’ ):
9 # # Alle Geraete in Rueckgabe einfuegen
10 devices . append ( device )
12 return devices
1
Unter UNIX verhalten sich Hardwaregeräte grundsätzlich wie Dateien und finden sich daher im
Dateisystem unterhalb des Verzeichnisses /dev als virtuelle Datei wieder. Eine solche Datei wird
als Device-Node bezeichnet.
87
Da an den USB-Bus beliebige USB-Serial -Geräte angeschlossen sein können2 , muss

nun für jedes der angeschlossenen Geräte überprüft werden, ob es sich um einen ZigBit-
USB -Stick handelt. Hierzu wird an das Gerät ein Befehl gesendet, der zur Abfrage der
Versionsnummer der verwendeten Serialnet-Firmware dient. Die Rückgabe wird nun
mit dem erwarteten Wert verglichen. Hierzu wird das python-serial -Modul verwendet:
1 import serial
2 def testDevice ( self , deviceName ):
3 ret = []
5 # # Versuch , eine Verbindung aufzubauen und die

6 # # Versionskennung der Serialnet - Firmware abzufragen .
7 try :
8 ser = serial . Serial ( " / dev /% s " % deviceName , 38400 ,\
9 timeout =3)
10 ser . write ( " ATI \ r \ n " ) # # ATI - Befehl zum Anfragen
11 # # der Versionsnummer
12 out = ser . read (74)
14 # # Wurde ueberhaupt eine Antwort empfangen ?

15 if out :
17 # # Antwort in Bestandteile zerlegen

18 formatedOut = out . split ( " \ r \ n " )
20 # # Hat die Antwort das richtige Format ?

21 if len ( formatedOut ) == 5:
22 vendor = formatedOut [1]
23 name = formatedOut [2]
24 version = formatedOut [3]
25 mac = formatedOut [4]
27 # # Herstellerkennung und Modell ueberprufen
2
Während der Entwicklung was es nicht ungewöhnlich, dass bis zu 3 Geräte angeschlossen waren: Bei
einem handelte es sich um den ZigBit-USB-Stick, zwei weitere dienten zum Flashen und Debuggen
der angeschlossenen Mikrocontroller.
88
6.3. MANVConnector
28 if vendor == ’ ATMEL ’ and name == ’ ZIGBIT ’:
30 # # Ein ZigBit - Modul wurde erkannt

31 return ( vendor , name , version , mac )
32 else :
34 # # Es wurde kein ZigBit - Modul erkannt

35 return False
36 else :
37 # # Antwort hatte falsches Format -> Es
38 # # handelt sich nicht um ein
39 # # ZigBit - Modul
40 return False
42 else :
43 # # Keine Antwort empfangen
44 return False
46 # # Fehler beim Zugriff auf serielle Schnittstelle

47 except serial . SerialException :
48 return False
6.3.3. CORBA-Anbindung
Die CORBA-Anbindung des MANVConnectors an den MANVServer erfolgt über die
in [Tepe10] spezifizierten Interfaces. Diese müssen über den Java Classpath einge-
bunden werden. Dies geschieht über den Parameter -cp auf der Kommandozeile der
JVM bzw. des Java-Compilers. Der Connector schickt über die Server Incoming-
Schnittstelle eingehende Daten und Ereignisse an den MANVServer. Damit der MANV-
Server umgekehrt auch Befehle an den MANVConnector schicken kann, muss dieser
selbst die Connector Commands-Schnittstelle implementieren. Dies geschieht in der
Klasse CommandsImpl 3 .
Die Interfaces der einzelnen Komponenten sind in Abbildung 6.3 dargestellt.
3
Eine genaue Beschreibung der einzelnen Dateien, Klassen und Funktionalitäten findet sich in An-
hang A.
89
A bbildung 4.1: Komponentendiagramm
Abbildung 6.3.: Komponentendiagramm der CORBA-Schnittstellen. (Quelle: Jan Tepelmann)
Zur Lokalisierung der einzelnen CORBA-Schnittstellen dient der Nameserver. Die

Adresse des Nameservers muss im Voraus bekannt sein. Meist läuft dieser auf dem
selben Rechner wie der MANVServer. Die Adresse wird beim Start des MANV-
Connectors als Kommandozeilenparameter –ORBInitRef NameService“ übergeben4 .
”
Die Verbindung zum Nameserver wird nun beim Start des MANVConnectors in der
Methode initCORBA() aufgebaut. Sobald diese hergestellt wird, wird nach der Adres-
se des MANVServers gefragt. Dies geschieht über eine Anfrage nach den Schnitt-
4
Wenn z.B. Nameserver, MANVServer und MANVConnector auf dem selben Rech-
ner laufen, so lautet der entsprechende Parameter: –ORBInitRef NameSer-
”
vice=corbaloc::localhost:1771/NameService“.
90
6.3. MANVConnector
stellen des Servers, also Server Incoming und Server Control. Zuletzt muss sich der
MANVConnector noch beim MANVServer registrieren, damit dieser weiß, an wen
er zu sendende Befehle zustellen muss. Hierzu wird die Methode registerConnector()
der Server Control -Schnittstelle verwendet. Nach diesem Schritt ist die Initialisierung
der CORBA-Anbindung abgeschlossen, und der CorbaSender -Thread, der eingehende
Ereignisse an den MANVServer sendet, kann gestartet werden.
91
7. Ergebnisse
In diesem Kapitel wird die entwickelte Lösung einer ausführlichen Evaluation unterzo-
gen. Die sich hierbei ergebenden Ergebnisse werden lediglich faktisch dargestellt, eine
Bewertung erfolgt an dieser Stelle nicht; diese wird in Kapitel 8 separat vorgenommen.
7.1. Realisierbarkeit
7.1.1. Integrierbarkeit in den Erste-Hilfe-Sensor
Die MANVNode dient – neben ihrer Funktion als Test- und Entwicklungsplatine für
die Firmware zur Ansteuerung der ZigBit-Module – als Nachweis der Integrierbarkeit
der in dieser Arbeit vorgestellten Lösung in den Erste-Hilfe-Sensor. Hierzu wurde beim
Entwurf darauf geachtet, dass neben dem ZigBit-Modul keine weiteren Hardwarebau-
teile notwendig sind, die nicht auf der Platine des Erste-Hilfe-Sensors vorhanden sind.
Darüber hinaus wurde die selbe Mikrocontroller-Architektur verwendet, die auch im
Erste-Hilfe-Sensor zum Einsatz kommt, so dass die entsprechenden Teile der Firmware
1:1 übernommen werden können.
7.1.2. Interoperabilität aller Komponenten

Da MANVSuite und MANVConnector in zwei verschiedenen Arbeiten (vgl. [Tepe10])
entworfen wurden, muss die Interoperabilität zwischen allen Komponenten gezeigt
werden. Hierzu wurde ein umfassender Integrationstest durchgeführt.
7. Ergebnisse
Crosscable
Notebook 1 Notebook 2
ZigBee
ZigBee-USB-Stick ZigBee-Router 1
ZigB
ee
ZigBee-Router 2
Bee
Zig
Zig
Bee
ZigBee-Router 5 ZigBee-Router 3
ZigBee ZigB ee
ee ZigB
MANVNode 1 Zig
ZigBee-Router 4 Be
e
ZigBee
ee
gB
MANVNode 5
Zi
MANVNode 4
MANVNode 2 MANVNode 3
Abbildung 7.1.: Diagramm des Aufbaus des Integrationstests.
7.1.2.1. Durchführung
In einem ersten Test wurde eine MANVNode über den MANV-USB-Stick an den
MANV-Connector angeschlossen und die MANVSuite ausgeführt. Nun wurde gezeigt,
dass sowohl die Übertragung von der MANVNode zur MANVSuite als auch umgekehrt
die Übertragung von Befehlen von der MANVSuite zu der MANVNode funktionieren.
In einem zweiten Test wurde nun obiges Setup durch das Hinzufügen von 4 weiteren
MANVNodes erweitert. Hierzu wurden auch wieder Daten in beide Richtungen über-
tragen. Hierbei wurde insbesondere darauf geachtet, dass sich die einzelnen MANV-
Nodes nicht untereinander stören, sowie dass alle Daten in der MANVSuite korrekt
zugeordnet und dargestellt wurden.
Obiges Setup wurde nun um 5 ZigBee-Router erweitert und alle Tests wurden erneut
durchgeführt.
Im letzten Schritt wurde nun noch die Skalierbarkeit des Systems überprüft. Hierzu
94
7.1. Realisierbarkeit
Abbildung 7.2.: Photo des Aufbaus des Integrationstests.
wurde mit Hilfe zweier Notebooks sowie dem Einsatz von Hardwarevirtualisierung jede
Softwarekomponente auf eine eigene Virtuelle Maschine installiert. Diese wurden nun
abwechselnd über beide Notebooks verteilt, so dass jede Kommunikation zwangsläu-
fig über das Netzwerk stattfinden musste. Nun wurden alle obigen Tests noch einmal
wiederholt. Der genaue Aufbau dieses Versuchs kann dem Diagramm in Abbildung 7.1
entnommen werden.
7.1.2.2. Ergebnisse
Alle Tests konnten erfolgreich durchgeführt werden. Die Interoperabilität aller Kom-
ponenten sowie die Verteilbarkeit über verschiedene Rechner konnte gezeigt werden.
7.1.3. Austauschbarkeit des MANVConnectors

Zur Demonstation der Austauschbarkeit des MANVConnectors wurde in [Tepe10] ein
Simulator für den MANVConnector geschrieben. Dieser implementiert die selbe Corba-
Schnittstelle wie der MANVConnector, führt jedoch keine Kommunikation über das
Netzwerk durch. Stattdessen besitzt der Simulator eine graphische Benutzeroberfläche,
95
7. Ergebnisse
Abbildung 7.3.: Screenshot der MANVGui während des Integrationstests.
über die zum einen Ereignisse von Hand ausgelöst, zum anderen empfangene Befehle in
einem Fenster dargestellt werden können. Die Übertragung von Daten wurde in beide
Richtungen erfolgreich getestet, die Austauschbarkeit des MANVConnectors damit
erfolgreich demonstriert.
7.1.4. Anbindbarkeit an externe Software

Eine zentrale Designentscheidung war die Verwendung einer offenen Corba-Schnittstelle
zur Anbindung von externer Software an die MANVSuite. Dass dies effizient durch-
führbar ist, zeigt der folgende Test.
7.1.4.1. Durchführung
Zum Nachweis der Anbindbarkeit von externer Software über die Corba-Schnittstelle
wurde entschieden, eine Schnittstelle zu einem Webinterface zu implementieren. Das
Webinterface selbst ist eine einfache HTML-Seite, die über Javascript eine graphische
96
7.2. Leistungsaufnahme des ZigBit-Moduls
Benutzeroberfläche für das Sensornetzwerk implementiert. Dieses muss nun zunächst

mit Daten aus dem Sensornetzwerk versorgt werden. Dazu stellt dieses Javascript ein-
mal pro Sekunde eine Verbindung zum Webserver her und holt die Daten im JSON -
Format ab. Befehle, die an das Sensornetzwerk gesendet werden, werden über spezielle
HTTP-GET -Anfragen kodiert. Insgesamt wird diese Vorgehensweise auch als AJAX
bezeichnet und bildet die Grundlage der Web-2.0 -Technologie. Es musste also ein Ad-
apter von Corba zu AJAX realisiert werden. Die Details dieser Implementierung sind
in Anhang A beschrieben.
Darüber hinaus wird in [Tepe10] beschrieben, wie ein Symbian-basiertes Nokia-Mo-
biltelefon an die MANVSuite angebunden wird. Hierzu wurde eine in C++ program-
mierte Lösung eingesetzt.
7.1.4.2. Ergebnisse
Die Anbindung des Webinterfaces an die MANVSuite konnte erfolgreich gezeigt wer-
den. Die Ergebnisse lassen sich ohne weiteres auf andere Schnittstellenformate übertra-
gen. Über die Anbindung des Symbian basierten Mobiltelefons konnte darüber hinaus
gezeigt werden, dass eine solche Anbindung sogar über Plattform- und Programmier-
sprachengrenzen hinweg realisiert werden kann.

Zur Bestimmung der Leistungsaufnahme – umgangssprachlich auch Stromverbrauch
genannt – wurden mehrere Messungen durchgeführt. Da der Strombedarf insbesondere
bei Einsatz des Energiesparmodus sehr stark schwankt, sind herkömmliche Messungen
z.B. über ein Multimeter nicht geeignet. Daher wurde eine indirekte Messung über den
Spannungsabfall an einem Widerstand durchgeführt. Dieser wurde in die Stromversor-
gung des ZigBit-Moduls eingebracht. Der Spannungsabfall über diesem Widerstand
wurde nun sowohl mit einem Oszilloskop als auch mit einem Multimeter gemessen.
Hierzu wurde zunächst die Form des Spannungsverlaufs analysiert. Dann wurden ein-
zelne Messpunkte innerhalb des Spannungsverlaufs ausgewählt, für die nun der Wert
der abfallenden Spannung gemessen wurde. Über das Ohmsche Gesetz konnte nun aus
der abfallenden Spannung die Stromstärke bestimmt werden. Für die einzelnen Mes-
sungen wurde ein Oszilloskop der Marke Tektronix, Modell TDS2002B verwendet. Die
Messungen wurden zusätzlich mit einem Multimeter verifiziert, um Kalibrationsfehler
97
7. Ergebnisse
des Oszilloskops auszuschliessen. Es wurde ein Widerstand mit einem Wert von 20, 1 Ω
verwendet.
7.2.1. Leistungsaufnahme im Normalbetrieb
Abbildung 7.4.: Router oder Koordinator im Normalbetrieb.
Als Normalbetrieb wurde der Zustand angenommen, in dem das ZigBit-Modul ei-
nem ZigBee-Netzwerk beigetreten ist und der Energiesparmodus nicht zur Anwendung
kommt. Bei der Messung wurde schnell klar, dass sich hierbei die Funktionsweise von
eines FFD (also Router und Connector ) drastisch von der eines RFDs (also eines
Clients) unterscheiden. Ein FFD befindet sich immer im Empfangsmodus, d.h. es hat
immer eine maximale Leistungsaufnahme. Die entsprechende Messung ist in Abbil-
dung 7.4 zu erkennen. Hier wurde ein Spannungsabfall von 473 mV gemessen, was bei
dem verwendeten Messwiderstand einem Strom von 23,5 mA oder einer Leistungsauf-
nahme ca. 70 mW entspricht.
Komplett anders ist hingegen das Verhalten eines Clients. Betrachtet man die ent-
sprechende Messung in Abbildung 7.5, ist eine Basislinie von 215 mV mit periodischen
Peaks erkennbar. In Abbildung 7.7 ist eine Detailmessung eines solchen Peaks zu se-
hen. Gut zu erkennen ist zum einen der Betrag des Spannungsabfalls von rund 473 mV
98
Abbildung 7.5.: Endknoten im Normalbetrieb ohne Energiesparmodus.
0
t
215mV
1s
470mV
40ms
Abbildung 7.6.: Analyse des Spannungsverlaufs eines Clients im Normalbetrieb.
sowie einer Dauer von genau 40 ms. Zwischen den Peaks kehrt der Spannungabfall für
genau eine Sekunde auf den Wert der Basislinie, also 215 mV zurück, auf die wieder
ein Peak folgt. Der Wert von 473 mV legt die Vermutung nahe, dass es sich bei den
Peaks um einen periodischen Empfangsvorgang handelt, d.h. das das ZigBit-Modul
jede Sekunde für genau 40 ms empfangsbereit ist. Diese Vermutung konnte durch wei-
99
7. Ergebnisse
Abbildung 7.7.: Detailaufnahme eines Empfangsmodus-Peaks.
tere Tests bestätigt werden. Zur Bestimmung des Strombedarfs eines Clients ergibt
sich daher folgende Rechnung:
tBasislinie · UBasislinie + tP eak · UP eak

UClient = (7.1)
tBasisline + tP eak
UClient
IClient = (7.2)
RShunt
Wobei die einzelnen Formelsymbole folgende Bedeutung haben:

UClient Durchschnittlicher Spannungabfall am Messwiderstand beim Betrieb
des Clients
tBasislinie Dauer der Basislinie
UBasislinie Spannungsabfall der Basislinie
tP eak Dauer eines Peaks
UP eak Spannungsabfall am Messwiderstand während eines Peaks
IClient Strombedarf eines Clients
RShunt Betrag des Messwiderstands
Setzt man nun die gemessenen Werte
100
tBasislinie = 1000 ms, tP eak = 40 ms, UBasislinie = 215 mV, UP eak = 473 mV
in Formel 7.1 ein, folgt für den Spannungsabfall
1000 ms · 215 mV + 40 ms · 470 mV

UClient = = 224, 9 mV
1000 ms + 40 ms
wodurch sich mit einem Widerstand von
RShunt = 20, 1 Ω
ein Wert von 11,19 mA für IClient ergibt. Dies entspricht bei einer Versorgungsspannung
von 3,0 V einer Leistungsaufnahme von ca. 33,6 mW.
7.2.2. Leistungsaufnahme bei Verwendung des Energiesparmo-

dus.
Abbildung 7.8.: Aus dem Energiesparmodus erwachter Client.
101
7. Ergebnisse
Aufwachen aus
Energiesparmodus
0 t
215mV
1s
470mV
40ms
Abbildung 7.9.: Analyse des Spannungsverlaufs eines Clients bei Nutzung des Energiesparmodus.
Abbildung 7.10.: Client, der das periodische Aufrufen des Energiesparmodus nutzt.
Die Verwendung des Energiesparmodus – im Datenblatt auch als Sleepmode, also

Schlafmodus, bezeichnet – ist eine Möglichkeit, den Strombedarf eines als Client kon-
figurierten ZigBit-Moduls weiter zu reduzieren. Wie in Abbildung 7.8 zu sehen ist,
102
sinkt der Strombedarf während des Energiesparmodus auf praktisch 01 . Sobald das
Modul aus dem Energiesparmodus in den Normalbetrieb zurückkehrt, wird sofort ein
Empfangsvorgang gestartet. Bis zum nächsten Aufrufen des Energiesparmodus verhält
sich das Modul wie in Abschnitt 7.2.1 beschrieben. Der Energiesparmodus kann entwe-
der manuell2 oder in einem einstellbaren Intervall periodisch aufgerufen werden. Der
Spannungsabfall während des periodischen Aufrufens ist in Abbildung 7.10 zu sehen.
Bei der Betriebsart des periodischen Aufrufens wird über zwei Parameter, tsleep und
tawake , die Dauer der Schlaf- bzw. Wachphase angegeben. Der Parameter tawake darf
hierbei die Dauer einer Empfangsphase, also 40 ms, nicht unterschreiten. Für tsleep gilt
eine Mindestdauer von 100 ms.
Interessant ist nun die Bestimmung des durchschnittlichen Strombedarfs bei Verwen-
dung des Energiesparmodus in Abhängigkeit von den Parametern tawake und tsleep . In
erster Näherung kann für den Strombedarf im Wachzustand Gleichung 7.2 verwendet
werden3 . Insgesamt ergibt sich der Strombedarf zu:
IClient · tawake
IP owersave = (7.3)
tawake + tsleep
In Tabelle 7.1 ist der Strombedarf für einige exemplarische Werte von tsleep und tawake
aufgeführt.
7.2.3. Sonderfälle
So lange ein Client keinem Netzwerk beigetreten ist befindet er sich dauerhaft im Emp-
fangsmodus. Das selbe Verhalten liegt vor, wenn eine bestehende Netzwerkverbindung
verloren gegangen ist. Wie in Abbildung 7.13 zu sehen ist, steigt der Strombedarf in
diesem Fall dauerhaft auf 23,4 mA an. Dazu kommt, dass keine Nutzung des Energie-
sparmodus möglich ist, so lange keine Verbindung zu einem Netzwerk besteht. Dies
kann eine Steigerung des durchschnittlichen Strombedarfs um mehr als den Faktor
1
Im Datenblatt ist ein Strombedarf von weniger als 6 µA angegeben.
2
z.B. mit dem Befehl AT+WSLEEP bei Verwendung der Serialnet-Firmware.
3
Dies ist eigentlich nicht ganz korrekt. Zur genauen Bestimmung des Strombedarfs müssten die
einzelnen Intervalle eigentlich einzeln betrachtet werden. Allerdings ist der sich hieraus ergebende
Fehler so gering, dass er in der Praxis zu vernachlässigen ist.
103
7. Ergebnisse
tsleep tawake IPowersave

1s 40 ms 0,45 mA
1s 500 ms 5,59 mA
1s 1s 5,59 mA
5s 500 ms 1,02 mA
5s 1s 1,86 mA
10 s 500 ms 0,54 mA
10 s 1s 1,01 mA
Tabelle 7.1.: Berechnung von IP owersave für exemplarische Werte von tsleep und tawake .
Abbildung 7.11.: Client mit deaktiviertem Empfangsmodus.
10 bewirken, was eine entsprechend schnelle Entladung der verwendeten Stromquel-

le bedeutet. Es ist daher wichtig, darauf zu achten, dass alle verwendeten Sensoren
möglichst selten die Verbindung zum Netzwerk verlieren.
7.2.4. Batterielaufzeit
In Abschnitt 4.5 wurde bereits eine grobe Überschlagsrechnung der Batterielaufzeit
Anhand der Werte aus dem Datenblatt vorgenommen. Diese sollen nun mit den oben
104
Abbildung 7.12.: Beitrittsvorgang eines Clients in ein Netzwerk.
Abbildung 7.13.: Client, der die Verbindung zum Netzwerk verloren hat.
gemessenen Werten konkretisiert werden. Als Strombedarf des Erste-Hilfe-Sensors

werden hierzu die in [Baue09] gemessenen Werte von 16,8 mA angenommen. Als Strom-
105
7. Ergebnisse
quelle soll eine Knopfzelle vom Typ CR2032 mit einer Kapazität von 240 mAh dienen4 .
Unter idealen Bedingungen ergibt sich für den Erste-Hilfe-Sensor alleine eine Laufzeit
von 14,3 Stunden.
Ohne Verwendung des Energiesparmodus wurde für den Strombedarf des ZigBit-
Moduls ein mittlerer Strombedarf von 11,2 mA. In Verbindung mit dem Erste-Hilfe-
Sensor ergibt sich ein Gesamtstrombedarf von 28 mA, was einer Laufzeit von 8,5
Stunden entspricht.
Für den Energiesparmoduses in einer 5:1-Konfiguration ergibt sich laut Tabelle 7.1
eine Absenkung des Strombedarfs des ZigBit-Moduls auf 1,86 mA, woraus sich in Ver-
bindung mit dem Erste-Hilfe-Sensor ein Gesamtbedarf von rund 18.7 mA ergibt. Dies
entspricht einer Laufzeit von ca. 12,8 Stunden.
7.3. Reichweite
Zur Bestimmung der Reichweite wurden sowohl innerhalb von Gebäuden als auch im
Freien Messungen durchgeführt. Es wurde schnell klar, dass die Ergebnisse sehr stark
von den Gegebenheiten der Umgebung sowie der Höhe von Sender und Empfänger ab-
hängig sind. Die größte Reichweite ist bei direkter Sichtverbindung sowie einer Höhe
von mindestens 1 m über dem Boden für Sender und Empfänger zu erreichen. Unter-
halb des Senders sollten sich möglichst keine Metalle befinden, als besonders schlecht
hat sich die Positionierung des Senders auf dem Dach eines PKW erwiesen.
7.3.1. Reichweite im Freien

Alle Tests zur Reichweite im Freien wurden auf dem Geländer der Westhochschule der
Universität Karlsruhe (TH) durchgeführt. Hierzu wurde eine MANVNode auf einem
Pfosten in einer Höhe von einem Meter angebracht und auf periodisches Senden bei
maximaler Sendeleistung konfiguriert. Nun wurde ein Notebook mit einem MANV-
USB-Stick so lange von der MANVNode entfernt, bis keine Pakete mehr empfangen
4
Die nachfolgenden Berechnungen gehen von einer Entladung der Batterie unter idealen Bedingun-
gen aus. Nicht berücksichtigt sind daher Verringerungen der Ladung durch die Entnahme zu großer
Ströme. Dies muss in der Stromversorgung des Erste-Hilfe-Sensors entsprechend berücksichtigt
werden.
106
7.4. Maximale Teilnehmerzahl des Netzwerke
wurden. Nun wurde der Abstand wieder so lange verringert, bis wieder 100% der ge-
sendeten Pakete empfangen wurde. Außerdem wurde als Gegenprobe ein Befehl an die
MANVNode gesendet und die Antwort empfangen. Als maximale Reichweite wurde
nun die Entfernung gewertet, bei der gerade noch alle Pakete empfangen, sowie alle
Befehle erfolgreich gesendet werden konnten. Die Entfernung zwischen Notebook und
MANVNode wurden nun mittels GPS vermessen. Als maximale Reichweite ergab sich
hierbei eine Entfernung von etwas über 50 m.
Im nächsten Schritt wurde an die Position des Notebooks ein ZigBee-Router aufgestellt
und die Entfernung zu diesem so lange vergrößert, bis gerade noch alle Pakete empfan-
gen werden konnten. Insgesamt konnte durch die Verwendung von zwei Routern eine
Gesamtreichweite von ca. 180 m erreicht werden, so dass von einer durchschnittlichen
Reichweitenverlängerung von 50-70 m pro Router ausgegangen werden kann.
Deutliche Einschränkungen bei der Reichweite traten auf, sobald sich Hindernisse wie
Container, Häuser oder PKW in der Sichtverbindung zwischen Sender und Empfänger
befanden. Diese ließen sich jedoch durch geschicktes Positionieren der Router sehr gut
umgehen, so dass auch hier hohe Reichweiten erzielbar waren.
7.3.2. Reichweite innerhalb geschlossener Räume

Die Reichweite innerhalb geschlossenere Räume hängt sehr stark von der Beschaffen-
heit dieser ab. Insbesondere Metallkonstruktionen wie Treppengeländer und Stahlträ-
ger in Wänden wirken sich negativ auf die Reichweite aus. Eine generische Aussage
über die Reichweite innerhalb geschlossener Räume ist daher nur sehr schwer zu tref-
fen. Diese hängt meist auch weniger von der Entfernung als von der Anzahl der Wände
zwischen Sender- und Empfänger ab. In diversen Tests hat sich hierbei ergeben, dass
eine Kommunikation durch zwei nicht tragende Wände hindurch gerade noch möglich
ist.
7.4. Maximale Teilnehmerzahl des Netzwerke

Eine praktische Messung der Teilnehmerzahl ist aus Kostengründen in einer Diplom-
arbeit natürlich nicht durchführbar. Daher soll an dieser Stelle eine analytische Be-
trachtung erfolgen. Diese wird in Form einer Worst-Case Abschätzung durchgeführt,
d.h. für alle Parameter werden die schlechtest möglichen Werte angenommen.
107
7. Ergebnisse
Grundsätzlich gilt folgender Zusammenhang:
DatenrateN etzwerk
AnzahlT eilnehmer = (7.4)
DatenrateT eilnehmer
In dem Szenario überträgt jeder Teilnehmer alle 5 Sekunden ein Datenpaket, das den
aktuellen Zustand beinhaltet. Laut [Alli07] hat ein ZigBee-Datenpaket eine maximale
Größe von 128 Byte. Damit ergibt sich für die benötigte Datenrate eines Teilnehmers:
128 Byte 1024 Bit 0, 2 kBit

DatenrateT eilnehmer = = ≈ (7.5)
5s 5s s
Laut [Alli07] gilt: DatenrateN etzwerk = 250 kBit/s. Setzt man diese Werte nun in
Gleichung 7.4 ergibt sich für die maximale Anzahl von Teilnehmern:
250 kBit/s
AnzahlT eilnehmer = = 1250 (7.6)
0, 2 kBit/s
Unter Worst-Case-Bedingungen ergibt sich also eine maximale Anzahl von 1250 Teil-
nehmern.
108
8. Diskussion
In Abschnitt 7 wurde die Leistungsfähigkeit des Funknetzwerkes untersucht. Es wurde

gezeigt, dass sowohl Reichweite als auch Leistungsaufnahme die Anforderungen dieser
Arbeit erfüllen. Auch wurde die Erweiterbarkeit des Netzwerkes durch Router gezeigt.
Darüber hinaus wurde gezeigt, dass eine Verbindung des verwendeten ZigBee-Modul
mit dem ADuC -Mikrocontroller möglich ist, und dass das so entstehende Gesamtsys-
tem in der Lage ist, die zu überwachenden Vitaldaten zuverlässig an die Basistati-
on zu übermitteln. Es wurde ebenfalls gezeigt, dass es möglich ist, Befehle über das
ZigBee-Netzwerk an den Mikrocontroller zu senden. Da der für diese Tests eingesetz-
te ADuC-7026 -Mikrocontroller der selben Familie wie der in dem Erste-Hilfe-Sensor
verwendete Mikrocontroller angehört, können diese Ergebnisse ohne weiteres auf die
Hardware des Erste-Hilfe-Sensors übertragen werden; die Integrierbarkeit in diesen
konnte somit gezeigt werden.
Die durch die Integration des ZigBit-Moduls in den Erste-Hilfe-Senosr erhöhte Leis-
tungsaufnahme, insbesondere bei Lastspitzen (Peaks), muss beachtet werden. Even-
tuell muss hier eine Anpassung der Stromversorgung des Erste-Hilfe-Sensors erfolgen.
Die genaue Analyse auftretender Lastspitzen findet sich in Abschnitt 7.2.1. Insbe-
sondere sollten hierbei auch die Ergebnisse in Abschnitt 7.2.3 beachtet werden, die
auftretende Sonderfälle beschreiben.
Softwareseitig konnte gezeigt werden, dass eine vollständige Kapselung aller hard-
8. Diskussion
warespezifischen Teile in einer austauschbaren Komponente möglich ist. Dies bietet

den Vorteil, dass bei einem Wechsel der Technologie des Sensornetzwerks lediglich der
MANVConnector ausgewechselt werden muss, alle anderen Teile können ohne Ände-
rung weiterverwendet werden.
Durch die in Abschnitt 7.1.4 durchgeführte schnelle Umsetzung eines Adapters zur An-
bindung der MANVSuite an eine Weboberfläche konnte gezeigt werden, dass durch die
hohe Modularität und Einsatz der Komponententechnologie Corba ein hohes Maß an
Flexibilität und Adaptierbarkeit der Gesamtlösung erreicht wird und eine Anbindung
an bestehende Systeme mit geringem Aufwand realisiert werden kann. Eine genauere
Analyse und Evaluation der MANVSuite inkl. der beschriebenen Schnittstellen findet
sich in [Tepe10]. In dieser verwandten Arbeit wird unter anderem gezeigt, wie eine
Anbindung der MANVSuite an ein Mobiltelefon des Herstellers Nokia erfolgen kann.
Als besonders positiv ist die Skalierbarkeit der Gesamtlösung zu bewerten: Zwar muss-
te aus Kostengründen der praktische Skalierbarkeitstest auf 12 Module beschränkt
werden. Durch eine analytische Betrachtung konnte jedoch gezeigt werden, dass das
ZigBee-Netzwerk zumindest theoretisch in der Lage ist, mindestens 1250 Sensoren zu
unterstützen, was selbst für ein sehr großes MANV -Szenario ausreichen würde. Ent-
sprechende praktische Tests müssen vor dem Praxiseinsatz natürlich nachgeholt wer-
den. Auch auf Softwareseite sind keine Lastprobleme zu erwarten, da die die Verbin-
dung der Softwarekomponenten untereinander netzwerkfähig ist; im Extremfall kann
jede Komponente auf einem eigenen Rechner betrieben werden. Hierbei skaliert die
Anforderung an die Hardware mit der Größe des zu verwaltenden Netzwerkes. Im
Prinzip ist jedes linuxfähige Gerät mit mindestens 16 MB Speicher und einer USB-
Schnittstelle, für die eine Implementierung der Java Virtual Machine 1 verfügbar ist,
in der Lage, als Server für das Sensornetzwerk zu dienen. Dies kann z.B. ein Android
basiertes Handy oder ein offener DSL-Router in Verbindung mit dem Betriebssystem
OpenWRT sein. Sollte keine JVM für die Plattform verfügbar sein, besteht sogar
die Möglichkeit, dass nur der in Python geschriebene, hardwarespezifische Teil des
1
Hierbei muss es sich nicht zwangsläufig um die Implementierung von Oracle/Sun handeln. Die
MANVSuite kann z.B. auch mit der JVM des Eclipse-Projektes ausgeführt werden.
110
MANVConnectors auf dem Gerät selbst ausgeführt wird2 . Alle restlichen Teile der
MANVSuite können nachgelagert auf einem Server im Internet ausgeführt werden; die
Verbindung der beiden Teile erfolgt über eine einfache Socketverbindung. Diese Lösung
bietet sich insbesondere für die Überwachung einzelner Patienten als eine Art intelli-
genter Hausnotruf an. Eine nähere Betrachtung dieser Anwendung erfolgt in [NoJa11].
Vom bisherigen Stand der Technik hebt sich die hier vorgestellte Lösung in vielen
Punkten ab:
• Konsequenter Einsatz offener Standards: In der gesamten Arbeit wurde konse-

quent auf den Einsatz offener Standards gesetzt. Bei der Verwendung von ex-
ternen Softwarepaketen wurde darauf geachtet, dass es sich um Open-Source
Produkte handelt. Zur Implementierung wurde keinerlei proprietäre Technologie
eingesetzt.
• Kapselung aller plattformspezifischen Designentscheidungen: Alle Plattformab-

hängigen Designentscheidungen wie die Ansteuerung der ZigBee-Module oder
der physische Zugriff auf die serielle Schnittstelle sind bewusst austauschbar ge-
halten. Hierzu wurden diese in Komponenten gekapselt und die Schnittstelle
zwischen diesen Komponenten wurde standardisiert. Bei Änderung einer dieser
Entscheidungen (z.B. weil ein anderes Funkprotokoll oder ein anderes Betriebs-
system zum Einsatz kommen soll) können diese einfach ausgetauscht werden,
ohne den Rest des Systems anpassen zu müssen.
• Geringe Stückkosten: Bei der Auswahl des Funkprotokolls wurde insbesondere

auch auf den Preis der verfügbaren Hardwaremodule geachtet. Dieser bewegt
sich selbst bei der Einzelabnahme der Module in einem Bereich unter 15 e. Auf
den Einsatz teurer Basisbauteile wie z.B. TinyOS -basierten Sensoren wurde kon-
sequent verzichtet.
• Geringe Leistungsaufnahme ( Strombedarf“): Durch den Einsatz des von ZigBee

”
angebotenen Energiesparmodus konnte der mittlere Strombedarf auf einen Wert
von ca. 1,86 mA gesenkt werden. Dies bedeutet eine Steigerung der Stromauf-
2
Die Implementierung in Python erfolgte lediglich aus Gründen der Einfachheit. Sollte kein Python
verfügbar sein, kann dieser Teil in jeder anderen Programmiersprache, die Socketverbindungen
erlaubt, neu implementiert werden.
111
8. Diskussion
nahme des Erste-Hilfe-Sensors um ca. 10%. Laut der Analyse in Abschnitt 7.2.4
ist selbst mit einer einfachen Knopfzelle eine Laufzeit von über 12 Stunden zu
erreichen, was für einen MANV -Einsatz mehr als ausreichend ist.
• Einfache Implementierbarkeit: Zur Anbindung des ZigBit-Moduls an den Erste-

Hilfe-Sensor sind lediglich vier Signalleitungen notwendig: UART RX, UART TX,
UART CTS 3 sowie eine GPIO 4 -Leitung, die mit dem RESET -Eingan des Zig-
Bit-Moduls verbunden ist (Details zur Implementierung in die Platine können
dem Schaltplan in Abschnitt 5.2 entnommen werden).
• Plattformunabhängigkeit: Durch den Einsatz plattformunabhängiger Program-

miersprachen wie Java und Python sowie durch Virtualisierung5 ist die vorge-
stellte Lösung auf einer breiten Palette von Systemen einsatzfähig.
• Kompaktheit: Die hier vorgestellte Prototyp-Platine besitzt eine Abmessung von

nur 50 mm auf 56 mm und bietet noch viel Potential zur weiteren Optimierung
der Größe (z.B. durch die beidseitige Platzierung von Bauteilen oder Fertigung
in 4-Schicht-Bauweise).
• Anzahl Teilnehmer: Laut der Betrachtung in Abschnitt 7.4 wird eine ausreichend
große Anzahl von Teilnehmern zu unterstützen. Dies reicht selbst für sehr große
MANV -Szenarien gut aus.
In dieser Arbeit nicht betrachtet wurde das Thema Datensicherheit und Verschlüs-
selung, welches alleine bereits umfangreich genug wäre, eine eigene Diplomarbeit zu
rechtfertigen. Ursprünglich war geplant, die hardwareseitige Verschlüsselung der Zig-
Bit-Module einzusetzen. Leider ist diese Funktion jedoch nicht in die SerialNet-Firmware
integriert und es standen auch keine fertig nutzbaren SerialNet-Alternativen zur Ver-
fügung. Daher wäre für die Verwendung der Verschlüsselung eine Neuimplementierung
der ZigBit-Firmware notwendig, was den Rahmen dieser Arbeit sprengen würde. Da-
her beschränkt sich diese Arbeit darauf, in Abschnitt 9.2 eine Analyse des Problems
3
UART RTS sollte auf Seite des ZigBit-Moduls auf GND geführt werden.
4
General Purpose Input/Output: Generische Ein/Ausgabe-Leitung
5
Die Virtualisierung dient dazu, die eingesetzte Software auf einer möglichst großen Palette von
Systemen ausführbar zu machen. Sie soll aber auch den Installationsaufwand für die Software
verringern, der insbesonders durch den eingesetzten Datenbankservern relativ hoch ist. Für den
späteren produktiven Einsatz wäre zu überlegen, diesen Datenbankserver direkt als Bibliothek in
die Software einzubetten. Eine genauere Diskussion dieses Themas findet sich in [Tepe10].
112
und Vorschläge zur Lösung vorzustellen. Diese können dann bei einer späteren Um-
setzung in ein Produkt als Grundlage dienen, die notwendigen Sicherheitsmaßnahmen
zu implementieren.
113
9. Zusammenfassung und Ausblick
9.1. Zusammenfassung
In dieser Arbeit wurde ein kabelloses Sensornetzwerk zur Überwachung von Patien-
ten bei einem Massenanfall von Verletzten (MANV ) entworfen und implementiert. Es
wurden mehrere kabellose Sensornetzprotokolle vorgestellt und es fand eine Tauglich-
keitsprüfung dieser statt. Bereits in diesem Schritt wurde die Entscheidung getroffen,
eine Lösung auf Basis des ZigBee-Protokolles zu implementieren. Hierfür sprachen der
geringste Strombedarf aller verfügbaren Lösungen, die hohe Störsicherheit sowie die
gute Verfügbarkeit passender Hardware auf dem Markt. Es wurde weiterhin festge-
stellt, dass sich die Marktsituation in den kommenden Jahren auf Grund der Einfüh-
rung neuer Standards wie ANT+, Bluetooth Low Energy sowie Wireless USB ändern
könnte, so dass beim späteren Entwurf insbesondere auf die Austauschbarkeit des
Netzwerkprotokolles zu achten ist. Im Anschluss daran wurden verschiedene aktuell
auf dem Markt erhältliche Lösungen zur kabellosen Patientenüberwachung betrach-
tet und mit den Erkenntnissen aus der Analyse der verschiedenen Netzwerkprotokolle
auf ihre Eignung untersucht. Hierbei wurde festgestellt, dass alle betrachteten Lösun-
gen eher für den Einsatz im Krankenhaus gedacht und für den Einsatz während eines
MANVs nicht geeignet sind. Weiterhin wurden verwandte Projekte vorgestellt, die sich
ebenfalls mit der technischen Patientenversorgung während eines MANVs beschäfti-
gen und die Ähnlichkeiten und Unterschiede gezeigt.
Mit den aus der Betrachtung der Stand der Technik gewonnenen Erkenntnissen konnte
nun zur Analyse übergegangen werden. Hier wurde zunächst eine Reihe von Anforde-
rungen erarbeitet, die die zu entwerfende Lösung erfüllen soll. Als besonders wichtig
sind hierbei eine hohe Teilnehmerzahl (mehrere hundert), ein geringer Strombedarf so-
wie eine ausreichend hohe Reichweite zu nennen. Außerdem wurde die für den späteren
Einsatz ausgewählte ZigBee-Hardware der Firma Atmel untersucht, und es wurde ei-
ne Reihe von Eigenheiten im Kommunikationsprotokoll zwischen ZigBee-Modul und
Mikrokontroller entdeckt, für die jeweils eine passende Lösung in allgemeiner Form
vorgestellt wurde. Außerdem wurden kurz die zwei verschiedenen Arten, den Ener-
giesparmodus der Module aufzurufen, erläutert, und der manuelle Aufruf als bessere
Lösung ausgewählt.
Nach der Analyse folgte der Entwurf eines Systems zur Lösung der gestellten Aufgabe.
Dieser erfolgte in 3 Schritten: Zunächst erfolgte der Entwurf des Gesamtsystems im
Groben. In Hinblick auf die in der Analyse gewünschte Austauschbarkeit des Funk-
protokolls wurde entschieden, wichtige Designentscheidungen zu kapseln und so das
System aus einzelnen, austauschbaren Komponenten aufzubauen. Im Groben erfolgte
eine Aufteilung in einer Kontrollsoftware (MANVSuite), einer Test- und Entwurfplati-
ne (MANVNode), dem MANV-USB-Stick, sowie der Schnittstelle zwischen Hard- und
Software (MANVConnector ).
Die MANVSuite wurde in einer zu dieser Diplomarbeit parallel laufenden Studien-

arbeit von Herrn cand. inform Jan Tepelmann genauer entworfen und implementiert
([Tepe10]).
Nach dem groben Entwurf folgt der Entwurf im Feinen. Hierbei wurden Hardware
(MANVNode und USB-Stick ) sowie Software (MANVConnector und Firmware der
MANVNode) getrennt betrachtet.
Auf Grundlage dieses Entwurfs wurde nun eine Implementierung durchgeführt. Bei
der Bestückung der Platine der MANVNode sind einige Probleme mit der Stromver-
sorgung aufgetreten, die jedoch durch eine Änderung des Platinenlayouts behoben
werden konnten. Außerdem waren praktische Probleme, wie die automatische Erken-
nung des MANV-USB-Sticks, sowie der Zugriff auf den seriellen Port mittels Java zu
lösen. In beiden Fällen konnte durch die Kapselung von betriebssystemspezifischem
Code in Python-Skripte Abhilfe geschaffen werden.
116
9.2. Sicherheit des Netzwerkes
Die Implementierung wurde einer Reihe von Tests unterzogen. Ziel hierbei war es,
festzustellen, wie gut die vorgestellte Lösung die in der Analyse aufgestellten Anfor-
derungen erfüllt. Neben Reichweite, Strombedarf und Erweiterbarkeit des Funknetz-
werks wurde hierzu auch die Leistungsfähigkeit der Software in Hinblick auf Anzahl der
Teilnehmer, Austauschbarkeit des MANVConnectors und Interoperabilität zwischen
MANVSuite, MANVConnector und Sensornetzwerk intensiv untersucht. Besondere
Augenmerk lag bei dieser Untersuchung auf der Interoperabilität aller Komponenten,
die durch Integrationgstests und Austausch einzelner Teile gezeigt werden konnte. Au-
ßerdem wurde die Strombedarf der ZigBee-Module sowie deren Reichweite eingehend
untersucht. Eine Betrachtung der Anzahl der Benutzer erfolgte analytisch anhand
des ZigBee-Standards. Durch diese Tests konnte gezeigt werden, dass die Lösung die
anfangs Erhobenen Anforderungen erfüllen kann. Lediglich bei der Datensicherheit
innerhalb des ZigBee-Netzwerkes müssen Einschränkungen hingenommen werden, da
die Firmware des Herstellers Atmel nicht den versprochenen Funktionsumfang bereit
stellt. Dies wird in Abschnitt 9.2 genauer untersucht. Hier werden auch mehrere Vor-
schläge gemacht, wie dieses Problem gelöst werden kann. Die Arbeit wird abgerundet
durch ein umfangreiches Softwarepaket inkl. Quellcode und Dokumentation, die die
zeitnahe Realisierung als Produkt ermöglichen.

Das Thema Sicherheit spielt – gerade für ein medizinisches Netzwerk – eine nicht zu ver-
nachlässigende Rolle. Daher sollen an dieser Stelle einige Anregungen gegeben werden,
wie ein Sicherheitskonzept für das entworfene Netzwerk aussehen könnte.
9.2.1. Aktueller Stand
Grundsätzlich unterstützt ZigBee eine 128-Bit AES -Verschlüsselung. Die SerialNet-

Firmware der in dieser Diplomarbeit eingesetzten ZigBee-Module der Firma Atmel
bietet jedoch in der aktuell vorliegenden Version (1.8.0) keine Möglichkeit, diese Ver-
schlüsselung zu verwenden. Laut Auskunft des E-Mail-Supports der Firma Atmel ist
dieses Feature auch für zukünftige Versionen nicht geplant.
117
9.2.2. Angriffsszenarien
Zur Beurteilung der Gefahrenlage, sowie zur Entwicklung von Abwehrmaßnahmen
erfolgt zunächst eine Betrachtung von möglichen Angriffsszenarien.
9.2.2.1. Ausspähen von Patientendaten
Aktuell werden über das Netzwerk Vitaldaten von Patienten (Puls und Atmung)
pseudonym versendet. Als Pseudonym dient hierbei die Hardware-Adresse des ver-
sendenden ZigBee-Moduls. Passives Mitschneiden der Daten ist so lange kein Pro-
blem, so lange sich keine Zuordnung zwischen der Identität des Patienten und der
Hardware-Adresse des verwendeten Moduls herstellen lässt. Hierfür ist eine direkte
räumliche Nähe zwischen Patient und Angreifer notwendig. Während eines MANV -
Szenarios sollte dies jedoch aktiv durch die Rettungskräften, insbesondere durch die
Absperrung durch die Polizei vor Ort verhindert werden. Sollte es einem Angreifer ge-
lingen, nahe genug an das entsprechende Modul heranzukommen, um eine Zuordnung
vorzunehmen, ist sowieso davon auszugehen, dass er auch in der Lage wäre, Bild oder
Videoaufnahmen des Patienten herzustellen, was im Zweifelsfall eine deutlich größeren
Eingriff in die Privatsphäre darstellen würde.
9.2.2.2. Aktiver Angriff gegen das Netzwerk
Ein größeres Problem als vom passiven Belauschen des Datenverkehrs geht von akti-
ven Angriffen gegen das Netzwerk aus. Innerhalb eines unverschlüsselten Netzwerkes
kann ein Angreifer die Identität eines beliebigen ZigBee-Moduls übernehmen; er hat
somit die Möglichkeit, entweder falsche Vitaldaten oder aber Befehle an die einzel-
ne Sensoren zu versenden. Dies könnte im schlimmsten Falle bedeuten, dass Alarme
im Netzwerk verloren gehen, und somit Patienten zu Schaden kommen. Da selbst bei
aktivierter ZigBee-Verschlüsselung kein Schutz gegenüber Replay-Angriffen besteht,
hätte ein Angreifer weiterhin die Möglichkeit, eine aufgefangene Statusnachricht oder
einen aufgegangen Befehl beliebig oft wieder in das Netzwerk einzubringen und so eine
Störung zu erreichen.
9.2.2.3. Störung des Netzwerkes
Ein Angreifer hat mehrere Möglichkeiten, ein bestehendes Netzwerk empfindlich zu

stören oder sogar jegliche Kommunikation zum Erliegen zu bringen. Im Falle eines
118
unverschlüsselten Netzwerkes kann dies einfach dadurch geschehen, dass der Angreifer
die Identität des Netzwerkkoordinators annimmt, und somit die Statusnachrichten
ins Leere geleitet werden. Eine andere Möglichkeit besteht darin, das Netzwerk mit
Paketen zu überfluten und so den Datenverkehr der anderen Teilnehmer zu blockieren.
Aber auch bei Einsatz von Verschlüsselung ist eine Störung des Netzwerkes möglich.
Hierzu muss ein Angreifer einfach mit sehr großer Sendeleistung auf allen ZigBee-
Frequenzen senden, um diese somit zu blockieren.
9.2.3. Abwehrmaßnahmen
Zur Abwehr der vorgestellten Angriffsszenarien kommen eine Reihe von Abwehrmaß-
nahmen in Betracht. Diese werden im folgenden kurz vorgestellt und auf Ihre Eignung
untersucht.
9.2.3.1. ZigBee-Verschlüsselung
Die verwendeten ZigBee-Module der Firma Atmel unterstützen hardwareseitig die im

ZigBee-Standard definierte 128-Bit-AES -Verschlüsselung. Die Integrität der Nachricht
wird hierbei durch die Bildung einer Prüfsumme sichergestellt. Um die Verschlüsselung
einsetzen zu können, muss die momentan verwendete SerialNet-Firmware gegen eine
eigene Firmware ausgetauscht werden. Atmel stellt hierzu einen ZigBee-Pro-basiertes
SDK zur Verfügung, mit dessen Hilfe eine entsprechende Firmware mit vertretbarem
Aufwand entwickelt werden kann. Hierbei bietet es sich an, einen an die SerialNet-
Firmware angelehnten AT-Befehlssatz zu implementieren, um alle bestehenden Kom-
ponenten wie den MANV-Connector und die Firmware des ADuC-Mikrocontrollers
weiterverwenden zu können.
9.2.3.2. Befehlszähler
Die ZigBee-Verschlüsselung schützt nicht gegen Replay-Angriffe. Eine einfache aber

effektive Methode zur Abwehr solcher Angriffe ist die Verwendung einer Sequenz-
nummer. Hierbei wird jeder Nachricht eine fortlaufende Nummer hinzugefügt. Der
Empfänger führt nun eine Liste, in der für jeden Absender die zuletzt verwendete
Sequenznummer enthalten ist. Nachrichten, die eine niedrigere Sequenznummer ent-
halten, werden verworfen. Diese Methode lässt sich mit geringem Speicheraufwand (
O(N) für den Coordinator, O(1) für einen Endknoten) implementieren. Als Ort der
119
Implementierung bietet sich entweder die Firmware des ADuC-Mikrocontrollers sowie

der MANV-Connector oder aber direkt die ZigBit-Firmware an.
9.2.3.3. Schutz auf Anwendungsebene
Alternativ zur Modifikation der ZigBit-Firmware besteht auch die Möglichkeit, auf An-
wendungsebene zu verschlüsseln. Sowohl für Java (OpenSSL) als auch für den ADuC-
Mikrocontroller (WAKAN-Crypto-Toolkit) sind entsprechende Bibliotheken verfügbar.
Eine Implementierung auf Applikationsebene hätte den Vorteil, dass keine Änderung
an der ZigBit-Firmware notwendig wären und sie daher ggf. einfacher durchzufüh-
ren ist. Von Nachteil ist jedoch, dass diese Lösung keinen Schutz gegen den Beitritt
fremder Teilnehmer in das Netzwerk bietet. Zwar können diese keine Befehle schicken
oder Daten ausspähen, allerdings ist es immer noch möglich, durch die Verwendung
von gefälschten Absenderadressen eine Denial-Of-Service-Angriff gegen das Netzwerk
durchzuführen.
9.3. Verbesserung der Reichweite und Störsicher-

heit
Die in dieser Arbeit eingesetzten ZigBee-Module verfügen über eingebaute Antenne
sowie eine sehr niedrige Sendeleistung von nur 1 mW. Damit einhergehend ist eine
begrenzte Reichweite. Die Störsicherheit dieser Module ist zwar bereits sehr gut, al-
lerdings kann diese weiter erhöht werden. Im Folgenden werden einige Möglichkeiten
vorgestellt, wie diese Ziele zu erreichen sind.
9.3.1. Anderer Frequenzbereich

In dieser Arbeit wurden lediglich ZigBee-Module, die im 2,4 GHz-ISM-Band operieren,
untersucht. Es gibt jedoch auch Module, die das 868- (Europa) bzw. 915-MHz-Band
(USA) nutzen. Diese versprechen eine bessere Durchdringung von Hindernissen und
damit eine bessere Reichweite und Störsicherheit. Diese Verbesserung kommt zum
Preis einer niedrigeren Datenrate (20 bzw. 40 kbit/sec) und ist zudem länderspezifisch.
Inwieweit diese Einschränkungen problematisch sind, wäre gesondert zu evaluieren.
Für den Einsatz in schwierigem Terrain könnte dieser Frequenzbereich jedoch einige
Vorteile bieten.
120
9.3. Verbesserung der Reichweite und Störsicherheit
9.3.2. Verwendung leistungsstärkerer ZigBee-Module und An-

tennen
Für diese Arbeit war der Strombedarf der Module eines der wichtigsten Kriterien.
Daher wurden Module mit der geringsten Leistungsaufnahme und damit auch der
geringsten Sendeleistung für den Entwurf der Hardware verwendet. Neben diesen Mo-
dulen sind auch Varianten mit deutlich höherer Sendeleistung erhältlich. Diese kann
meist sogar noch zusätzlich durch den Einsatz von externen Antennen verbessert wer-
den. Mit der entsprechenden Kombination aus Modul und Antenne lässt sich eine
Sendeleistung erreichen, die mehr als 10mal so hoch ist, wie diejenige der in dieser
Arbeit verwendeten Module. Dies ist insbesondere für den Einsatz in ZigBee-Routern
interessant, da diese einfach mit einer größeren Stromquelle versehen werden können
als die einzelnen Sensoren. Es wäre daher interessant zu evaluieren, wie sich die Ver-
wendung leistungsfähigerer Module sowie größerer Antennen in den Routern auf die
erreichbare Reichweiten des Netzwerkes auswirkt.
9.3.3. Genauere Betrachtung des Bluetooth-Low-Energy -Stan-

dards
Der Bluetooth-Low-Energy-Standard verspricht, eine interessante Alternative zum Zig-
Bee-Standard zu werden. Der einzige Grund, weshalb in dieser Arbeit keine genaue-
re Betrachtung erfolgen konnte, war die Nichtverfügbarkeit entsprechender Hardware
zum Zeitpunkt der Anforderungsanalyse. Bereits im Februar 2010 wurde von der Firma
Nordic Semiconductors unter der Bezeichnung ISP091201 ein entsprechendes Hard-
waremodul angekündigt, das jedoch bis jetzt (Stand: Oktober 2010) nicht auf dem
Markt erhältlich ist. Sobald entsprechende Module verfügbar sind, sollte eine erneute
Evaluation erfolgen. Beim Entwurf der hier vorgestellten Lösung wurde eine spätere
Änderung des Funkprotokolls eingeplant und bei der Implementierung entsprechend
berücksichtigt.
121
A. Beschreibung der beigelegten
Software
In diesem Kapitel wird die beigelegte Software beschrieben. Außerdem wird eine kurze
Erläuterung gegeben, welche Funktionalität wo implementiert ist, und an welcher Stelle
für den produktiven Einsatz ggf. noch Anpassungen erfolgen müssen.
A.1. MANV-Connector
Im Verzeichnis connector“ auf der beigelegten CD befinden sich Quellcode und Bina-
”
ries des MANV-Connectors. Zum Kompilieren und Starten des Connectors wird das
Script start.sh“ verwendet.
”
A.1.1. Starten des Connectors

Zum Starten des Connectors muss das Skript start.sh“ mit dem Parameter start“
” ”
aufgerufen werden. Evtl. müssen in diesem Skript noch Pfade und die IP-Adresse
des MANV-Servers angepasst werden. Dieser Server muss vor dem MANV-Connector
gestartet werden.
A.1.2. Kompilieren des Connectors

Zum Kompilieren der beigelegten Software wird ebenfalls das start.sh“ Skript ver-
”
wendet. Hierzu wird dieses mit dem Parameter build“ aufgerufen. Zum erfolgreichen
”
A. Beschreibung der beigelegten Software
Verzeichnis Beschreibung
commands/ Befehle, die an den USB-Stick gesendet werden.
corba/ Implementierung der CORBA-Schnittstelle.
events/ Ereignisse, die von dem USB-Stick empfangen wurden.
results/ Antworten auf gesendete Befehle.
lib/ Klassen, die thematisch nicht in andere Pakete passen.
Tabelle A.1.: Struktur des Quellcodeverzeichnisses
Kompilieren sind die IDL-Dateien der MANV-Suite von Jan Tepelmann erforderlich,
die auf der CD im Verzeichnis jan“ mitgeliefert werden. Evtl. müssen hierfür die
”
Pfade im start.sh“-Skript angepasst werden.
”
A.1.3. Verzeichnisstruktur des Quellcodes

Die Verzeichnisstruktur des Quellcodes folgt dem Standard für Java-Packages. Der
Quellcode ist auf mehrere Dateien und Unververzeichnisse aufgeteilt und findet sich
im Verzeichnis connector/edu/kit/ibt/manv/connector.
A.1.3.1. Inhalt des Verzeichnises commands/
Innerhalb des commands/ -Verzeichnisses findet sich die Datei MANVCommands.java,

in der die Kasse MANVCommand spezifiziert wird. Objekte dieser Klasse kapseln je-
weils einen SerialNet-AT-Befehl (vergleiche Tabelle 4.1), der an den USB-Stick gesen-
det wird. Dieser Befehl wird als einfacher ASCII-String an den Konstruktor übergeben.
Optional kann bei wichtigen Befehlen noch eine Priorität mitgegeben werden; je höher
diese Priorität ist, desto eher wird dieser Befehl an den USB-Stick gesendet. Wenn der
Befehl abgearbeitet wurde, wird in dem Objekt das Ergebniss der Ausführung gespei-
chert, welches mit der Methode MANVResult.getResult() abgerufen werden kann.
A.1.3.2. Inhalt des Verzeichnises corba/
In dem Verzeichniss corba/ findet sich der Quellcoode der Implementierung der Corba-
Schnittstelle zum MANV -Server. Die einzelnen Dateien haben folgende Funktion:
• CommandsImpl.java: Definiert, wie auf vom Server empfangene Befehle reagiert

werden soll. Leitet empfangene Befehle an das ZigBee-Netzwerk weiter.
124
A.1. MANV-Connector
• MessageContainer.java: Container zur Auslieferung von ZigBee-Nachrichten in

Corba-Nachrichten. Für jeden Nachrichtentyp gibt es eine spezielle Unterklasse
(CorbaDataMessageContainer, CorbaEventMessageContainer ). Der Inhalt der
Container wird von der Methode createCorbaMessages() der Unterklassen von
events/MANVEvent.java konstruiert.
• CobaSender.java: Thread, der empfangene ZigBee-Ereignisse an den MANV-
Server ausliefert. Diese Ereignisse werden aus einer Queue (eventQueue) ent-
nommen und sind bereits in MessageContainer verpackt.
A.1.3.3. Inhalt des Verzeichnisses events/
Im Verzeichnis events/ befinden sich die Klassen, welche Ereignisse repräsentieren,

die von dem ZigBee-Netzwerk empfangen wurden. Alle Ereignis-Klassen sind von der
Klasse MANVEvent abgeleitet und besitzen damit automatisch eine Priorität. Über
diese Priorität kann eingestellt werden, in welcher Reihenfolge empfangene Ereignisse
abgearbeitet werden sollen. So ist es z.B. sinnvoll, dass Ereignisse, welche einen Alarm
darstellen, eine höhere Priorität haben als eine Mitteilung, dass ein neuer Knoten im
Netzwerk vorhanden ist. Nachfolgend eine Übersicht über die Funktion der Methoden
der Klasse MANVEvent:
• isResult(): Gibt zurück, ob es sich bei dem Ereignis um das Ergebnis eines ge-
sendeten Befehls handelt.
• isImportant(): Unterscheidet wichtige von unwichtigen Ereignissen. Nur wichtige
Ereignisse werden über die CORBA-Schnittstelle an den MANV-Server weiter-
geleitet. Unwichtige Ereignisse sind nur für die interne Verarbeitung im MANV-
Connector relevant.
• fromString(): Factory1 -Methode, die aus einem SerialNet-String ein MANV-
Event erstellt. Liefer automatisch eine Instanz einer Unterklasse von MANV-
Event zurück.
• createCorbaMessages(): Bereitet ein MANVEvent für den Transport über die
CORBA-Schnittstelle zum MANV-Server vor. Hierzu werden ein oder mehrere
CorbaEvent-Objekte erstellt, die wiederum in einen passenden CorbaContainer
verpackt werden.
1
Eine Fectory-Methode übernimmt das Erstellen von Objekten.
125
• getRaw(): Liefert den rohen SerialNet-String zurück, auf Basis dessen das MAN-
VEvent-Objekt erzeugt wurde; dies ist vor allem für Debugging-Zwecke inter-
essant.
Von der Klasse MANVEvent sind folgende Unterklassen abgeleitet:
• MANVChildJoined : Eine neue MANVNode ist dem Netzwerk beigetreten.
• MANVChildLost: Eine MANVNode hat die Verbindung zum Netzwerk verloren.
• MANVStatusMessage: Eine Datennachricht, die Statusinformationen (Alarmzu-

stand, Puls, Atmung) enthält, wurde empfangen.
• MANVDataReceived : Eine Datennachricht, die keine Statusinformationen ent-

hält, wurde empfangen.
A.1.3.4. Inhalt der Verzeichnises results/
In dem Verzeichnis results/ befinden sich alle Klassen, die auf gesendete SerialNet-
Befehle empfangene Antworten repräsentieren. Diese sind von der Basisklasse MAN-
VResult abgeleitet, welche wiederum eine Unterklasse von MANVEvent ist. Damit
besitzt diese Klasse alle Eigenschaften und Methoden, die auch die Klasse MANVE-
vent besitzt; insbesondere handelt es sich hierbei selbst wieder um eine Unterklasse von
MANVPrioritized. Zusätzlich zu den von den Oberklassen ererbten Methoden werden
folgende Methoden neu eingeführt:
• getData(): Liefert die von der SerialNet-Firmware empfangenen Daten in String-

form zurück.
• isComposite(): Gibt zurück, ob es sich um eine komplexe Antwort (vgl. Ab-

schnitt 4.4) handelt. In diesem Fall befindet sich in dem Attribut subResult eine
gültige Referenz auf ein Unterergebnis.
• getChildList(): Falls mit dem gesendeten SerialNet-Befehl nach den assoziierten

Kindknoten gefragt wurde, gibt diese Methode eine Liste dieser Kindknoten
zurück.
Neben den beiden Statusinformationen OK und ERROR kann die SerialNet-Firmware

auch kompliziertere Antworten zurückliefern. Diese werden von folgenden Unterklassen
von MANVEvent repräsentiert:
126
A.1. MANV-Connector
• MANVChildrenList: Repräsentiert eine Liste von Kindknoten, die von der SerialNet-
Firmware empfangen wurde.
• MANVGsn: Liefert die Global Subscriber Number (GSN) einer Node zurück.
Entspricht in etwa einer MAC -Adresse.
A.1.3.5. Inhalt des Verzeichnisses lib/
In dem Verzeichnis lib/ finden sich alle die Klassen, welche nicht in obiges Einord-
nungsschema passen. Hierbei handelt es sich insbesondere um Helferklassen, die in
den obigen Klassen verwendet werden:
• iZigBit: Interface für einen entfernten ZigBit-Knoten. Diese werden nochmal

weiter in vollwertige Knoten (ZigBit, im wesentlichen also die MANV-Nodes)
und Knoten, von denen nur Daten empfangen werden können (readonlyZigBit)
unterschieden.
• MANVPrioritized : Allgemeine Oberklasse für priorisierte Entitäten wie z.B.

MANVCommand, MANVEvent oder MANVResult. Diese Entitäten enthalten
sowohl eine numerische Priorität als auch eine compareTo()-Operation, über die
eine Sortierung vorgenommen werden kann.
• SocketReader : Definiert einen Thread, der von dem Socket liest, der die Verbin-
dung zum MANV-USB-Stick beinhaltet. Dieser Thread empfängt Ereignisse und
Ergebnisse, wandelt sie in Instanzen vom Typ MANVEvent und MANVResult
um und sortiert in die Ereigniswarteschlange (eventQueue) ein. Empfangene Er-
gebnisse werden automatisch dem passenden Objekt vom Typ MANVCommand
zugeordnet.
• SocketWriter : Definiert einen Thread, der zu sendende Befehle aus der Befehls-
warteschlange (commandQueue) entnimmt und über die Socketverbindung zum
MANV-USB-Stick an das ZigBee-Netzwerk weiterleitet. Sobald ein Befehl abge-
arbeitet ist, wird er von dem SocketWriter -Thread automatisch in die Ergebnis-
warteschlange (resultQueue) einsortiert.
A.1.3.5.1 Interface eines ZigBit-Knotens
Das Interface eines ZihBit-Knotens definiert folgende Methoden:
127
• getNodeID(): Liefert die logische Adresse (WSRC ) eines Knotens zurück.
• getMacID(): Liefert die Hardware-Adresse (GSN ) eines Knotens zurück.
• sendData(): Sendet Daten an einen Knoten. Blockiert so lange, bis die Bear-
beitung des Befehls abgeschlossen ist. Wird diese Operation auf einem Readon-
lyZigBit wird kein Versand der Daten ausgeführt und statt dessen ein Fehler
zurückgegeben.
• isendData(): Senden von Daten an einen Knoten. Kehrt sofort zurück, ohne auf
die Bearbeitung des Befehls zu warten.
• toggleAlertStatus(): Umschalten des Alarmstatus einer MANV-Node. Keine Funk-

tionalität
• disableAlert(): Deaktivieren des Alarms einer MANV-Node.
• enableAlert(): Aktivieren des Alarms einer MANV-Node.
• muteAlert(): Alarm stummschalten.
• itoggleAlertStatus(), idisableAlertStatus(), ienableAlert(), imuteAlert(): Selbe Funk-

tionalität wie die Versionen ohne i, jedoch ohne Warten auf Abarbeitung (analog
zu sendData() / isendData()).
A.2. Serial-To-Socket
In dem Verzeichnis serial to socket befinden sich eine Reihe von Python-Skripten, die
die Verbindung zwischen MANVConnector und MANV-USB-Stick herstellen. Hierzu
wird zunächst mit Hilfe des Skriptes serial to socket.py eine automatische Suche nach
dem MANV-USB-Sticks (vgl. Abschnitt 6.3.2) durchgeführt. Der Status dieser Suche
wird graphisch ausgegeben. Sobald ein MANV-USB-Stick erfolgreich erkannt wurde,
wird das Skript serial to socket/start.sh gestartet und die Adresse des seriellen Ports
als Parameter übergeben. In diesem Skript wird dann unter anderem das Pythonskript
serial to socket.py“ gestart. Dieses leitet einen angegebenen seriellen Port auf den
”
Netzwerkport 4711 um, über den dann der MANVConnector eine Verbindung zu dem
USB-Stick herstellen kann.
128
A.3. Firmware
A.3. Firmware
In dem Verzeichnis firmware/ befindet sich der Quellcode der Firmware für die MANV-
Node. Diese besteht aus folgenden Dateien:
• main.c: Einstiegspunkt der Firmware. Initialisiert alle Ringpuffer, Interrupts und

die Peripherie des ADuC -Mikrocontrollers. Ruft danach die Hauptscheife des
ZigBit-Treibers auf.
• isr.c: Definition der verwendeten Interrupt-Service-Routinen, also Behandlungs-

routinen für auftretende Interrupts. Ist unter anderem für die Ansteuerung des
UART verantwortlich.
• random.c: Implementierung eines sehr einfachen Pseudozufallszahlengenerators.
• ringpuffer.c: Implementierung der Datenstruktur Ringpuffer“. Diese kann 5 Zei-

”
len von jeweils 80 Zeichen Länge speichern. Werden mehr als 5 Zeilen in die
Datenstruktur gelegt, dann wird das älteste Element überschrieben. Ringpuf-
fer werden unter anderem zur Implementierung des UART -Treibers sowie zur
Zwischenspeicherung von empfangenen Befehlen zur späteren Abarbeitung ver-
wendet.
• uart.c: Beinhaltet die Routinen, die zur Interaktion mit dem als ISR implemen-
tierten Treiber für den UART notwendig sind. Im wesentlichen handelt es sich
um Routinen, die die entsprechenden Ringpuffer befüllen oder auslesen.
• zigbit.c: Beispiel einer Interaktion mit dem ZigBit-Modul. Enthält unter ande-
rem Routinen zur Befehlsverareitung, Extraktion von Rückgabewerten, Initiali-
sierung des ZigBit-Moduls sowie ein Beispiel, wie die Übertragung von Status-
informationen realisiert werden kann.
Bei der Firmware handelt es sich um eine Demonstration, wie die Kommunikation zwi-
schen ADuC -Mikrocontroller und ZigBit-Modul realisiert werden kann. Zur späteren
Verwendung auf dem Erste-Hilfe-Sensor müssen einige Anpassungen vorgenommen
werden. Hierzu wird folgende Vorgehensweise vorgeschlagen:
1. Übernahme der UART -spezifischen Routinen aus isr.c und uart.c.
2. Übernahme der Datenstruktur Ringpuffer aus ringpuffer.c.
129
3. Übernahme der Funktionen extractStatus(), waitForStatus(), isCommand() und

parseCommand() aus der Datei zigbit.c.
4. Anpassung der Funktion initZigBit() aus der Datei zigbit.c: Zu beachten ist
hierbei Zeile 154: Hier wird eine GPIO-Leitung des ADuC Mikrocontrollers da-
zu verwendet, die Resetleitung des ZigBit-Moduls zu betätigen. Dies ist für die
Synchronisierung zwingend erforderlich und muss im Hardwarelayout entspre-
chend berücksichtigt werden. Nach Zeile 154 sollten alle Zeilen mit Zugriff auf
GP2DAT entfernt werden, da diese dazu dienen, die LEDs der MANVNode an-
zusteuern. Diese LEDs sind auf dem Erste-Hilfe-Sensor nicht vorhanden. Die
Aufrufe von sleep() sind zur Synchronisierung zwingend erforderlich und dürfen
nicht entfernt werden.
5. Anpassung der Funktion zigBitLoop() aus der Datei zigbit.c Hier werden aktuell
noch Dummy-Informationen übertragen, die durch einen Zufallszahlengenerator
erzeugt werden. Diese müssen durch die tatsächlich gemessenen Werte des Erste-
Hilfe-Sensors ersetzt werden.
A.4. MANV-Web
Im Verzeichnis manvweb/ befinden sich die Quelldateien des Webinterfaces der MANV-
Suite. Dabei verteilt sich die Funktionalität auf folgende Unterdateien:
• MANVWeb: Einstiegsklasse des Webservers. Stellt die CORBA-Verbindung her

und übergibt dann die Steuerung an die Klasse MANVWebserver.
• MANVWebserver : Implementierung des Webervers. Öffnet einen Serversocket

und wartet auf eingehende Verbindungen. Für jede eingehende Verbindung wird
nun ein neuer Thread gestartet. In diesem Thread wird die Eingabe geparsed
und eine entsprechende Reaktion aufgerufen.
• ToQueries: Adapterklasse zum CORBA-Zugriff auf den MANV-Server.
A.5. Platine
In dem Verzeichnis platine/ befinden sich die Eagle-Dateien, in denen Schaltplan und
Platinenlayout des MANV-USB-Sticks und der MANV-Node spezifiziert sind.
130
A.6. Simulator
A.6. Simulator
In dem Verzeichnis simulator/ befindet sich ein in Python programmierter MANVNo-
de-Simulator. Dieser kann dazu verwendet werden, mit Hilfe eines MANV-USB-Sticks,
MANVNodes zu simulieren. Beim Start des Simulators muss diesem die Adresse des
seriellen Ports, auf dem sich der USB-Stick befindet, übergeben werden. Das Format
ist Betriebssystem spezifisch. Unter Linux wird einfach der Dateiname der entspre-
chenden Device-Node (z.B. /dev/ttyUSB1 ) angegeben, unter Windows der Name des
COM-Ports (z.B. COM1:).
A.7. Zigbit Firmware

In dem Verzeichnis ZigBit-Firmware befindet sich eine aktuelle Kopie der SerialNet-
Firmware inkl. dem zum Programmieren der ZigBit-Module nötigen Bootloader in
einer Version für Windows.
131
Literatur
[ALAR10] ALARM. Adaptive Lösungsplattform zur Aktiven technischen Un-

terstützung beim Retten von Menschenleben, 2010. http://www.
alarm-projekt.de/.
[Alli07] ZigBee Alliance. Latest ZigBee specification including the pro feature
set. Technischer Bericht, ZigBee Alliance, 2007. http://www.zigbee.
org/Products/Overview.aspx.
[Atme09] Atmel. ZigBitTM 2.4 GHz Amplified Wireless Modules Datasheet, 2009.
www.atmel.com/dyn/resources/prod_documents/doc8228.pdf.
[Baue09] Marco Bauer. Konzeption und Entwicklung eines intelligenten, mobi-

len medizinischen Ad-hoc Netzwerks zur Überwachung von Personen bei
Massenanfällen von Verletzten (MANV). Karlsruher Institut für Tech-
nologie (KIT), Institut für Biomedizinische Technik, Karlsruhe. Diplom-
arbeit, 2009.
[Benk07] Thorsten Benkne. Grundlagen des Mobilfunks. J. Schlembach Fachver-

lag, Wilburgstetten. 2007.
[BROA06] BROADCOM. BCM4326 Datasheet, 2006. http://www.datasheetpro.

com/595911_download_BCM4326_datasheet.html.
[Cheu05] Humphrey Cheung. How To: Building a BlueSniper Rifle, 2005. http://
www.tomsguide.com/us/how-to-bluesniper-pt1,review-408.html.
[Devi07] Analog Devices. Precision Analog Microcontroller, 12-Bit Analog

I/O, ARM7TDMI MCU Datasheet, 2007. www.keil.com/dd/docs/
datashts/adi/aduc702x_ds.pdf.
Literatur
[Elie00] Anton Eliens. Principles of object-oriented software development. Inter-

national computer science series. Addison-Wesley, Harlow. 2. Auflage,
2000.
[ETSI06] ETSI. EN 300 175: Digital Enhanced Cordless Telecommunications Stan-

dard, European Telecommunications Standards Institute, 2006.
[Fara08] Shahin Farahani. ZigBee wireless networks and transceiver. Elsevier

Newnes, Amsterdam[u.a.]. 2008.
[Foun10] Python Software Foundation. Python v2.7.1 documentation, 2010.

http://docs.python.org/.
[Gisl08] Drew Gislason. ZigBee Wireless Networking. Elsevier, Amsterdam. 2008.
[GMSC+ 07] Tia Gao, Tammara Massey, Leo Selavo, David Crawford, Bor rong Chen,
Konrad Lorincz, Victor Shnayder, Logan Hauenstein, Foad Dabiri, Ja-
mes Jeng, Arjun Chanmugam, David White, Majid Sarrafzadeh und
Matt Welsh. The Advanced Health and Disaster Aid Network: A Light-
Weight Wireless Medical System for Triage. IEEE Transactions on Bio-
medical Circuits and Systems, Band 1(3), 2007, S. 203–216.
[IEEE06] WPAN Task Group 4 (TG4) IEEE 802.15.4. IEEE SA - 802.15.4-2006 -

IEEE Standard for Local and Metropolitan Area Networks, Institute of
Electrical and Electronics Engineers, 2006.
[IEEE07] WLAN Working Group IEEE 802.11. IEEE Std 802.11TM-2007 - Wi-
reless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, Institute of Electrical and Electronics Engineers, 2007.
http://standards.ieee.org/about/get/802/802.11.html.
[Jäg08] Marc Jäger. Mobiler Handlungsassistent zur laientauglichen Überprü-

fung und Beurteilung von Vitalparametern plötzlich bewussloser Perso-
nen. mbv, Berlin. 2008.
[KG10] Corscience GmbH & Co. KG. Corscience Homepage, 2010. http:
//www.corscience.de/de/medizintechnik/produkte-systeme/
telemedizin/sensoren/event-recorder.html Abegerufen am
1.10.2010.
134
Literatur
[Kook08] John Kooker. Bluetooth, ZigBee, and Wibree: A Comparison of

WPAN Technologies. Technischer Bericht, Univerity of Californica,
San Diego, 2008. http://cseweb.ucsd.edu/classes/fa08/cse237a/
topicresearch/jkooker_tr_report.pdf.
[KRSCS+ 09] C. Kunze, D. Rodriguez, L. Shammas, A. Chandra-Sekaran und B. We-

ber. Nutzung von Sensornetzwerken und mobilen Informationsge-
räten für die Situationserfassung und die Prozessunterstützung bei
Massenanfällen von Verletzten. In Proceedings der 39. Jahrestagung
der Gesellschaft für Informatik (INFORMATIK 2009), Lecture Notes
in Informatics, GI, 2009. http://subs.emis.de/LNI/Proceedings/
Proceedings154/gi-proc-154-104.pdf.
[KuDMK08] Anurag Kumar, D. D. Manjunath und Joy Kuri. Wireless networking.

The Morgan Kaufmann series in networking. Morgan Kaufmann / Else-
vier, Amsterdam. 2008.
[LSTW+ 09] Stefan Lucks, Andreas Schuler, Erik Tews, Ralf-Philipp Weinmann und
Matthias Wenzel. Attacks on the DECT authentication mechanisms.
Cryptology ePrint Archive, Report 2009/078, 2009. http://eprint.
iacr.org/.
[NeBD06] Luca Negri, Jan Beutel und Matthias Dyer. The Power consumption of
Bluetooth Scatternets. In Consumer Communications and Networking
Conference. Computer Engineering and Network Lab, ETH Zuerich, IE-
EE, 2006, S. 519–523.
[NoJa11] Marcel Noe und Marc Jaeger. Neuartiges Erste-Hilfe-Sensor-System auf

ZigBee-Basis zum sicheren Wohnen bis ins hohe Alter. In Proceedings
des 4. Deutschen AAL-Kongresses. VDE, 2011. Bei Fertigstellung dieser
Arbeit noch nicht erschienen.
[SIG10] Bluetooth SIG. Bluetooth Specification 4.0 - Core Standard: Specifi-

cation of the Bluetooth System, 2010. http://www.bluetooth.com/
Specification%20Documents/Core_V40.zip.
[SOGR10] SOGRO. SOGRO Projektwebseite, 10 2010. http://www.sogro.de/.
135
Literatur
[Tage00] Der Tagesspiegel. UMTS-Auktion: Deutsche sind Weltmeister in der

Versteigerung von Mobilfunklizenzen, 2000. Ausgabe vom 14.08.2000.
[TavS07] Andrew S. Tanenbaum und Maarten van Steen. Distributed systems :

principles and paradigms. Pearson, Prentice Hall, Upper Saddle River,
NJ. http://www.gbv.de/dms/ilmenau/toc/515939617.PDF, 2. Aufla-
ge, 2007.
[Tepe10] Jan Tepelmann. Entwicklung und Implementierung einer graphischen

Benutzeroberfläche zur Überwachung von Patienten in einem Senesor-
netz in einem MANV-Szenario (Arbeitstitel). Karlsruher Institut für
Technologie (KIT), Karlsruhe. Studienarbeit, 2010.
[Tofa05] Frank Tofahrn. Spread-Spectrum, das unbekannte Wesen, 2005.

http://www.rc-network.de/magazin/artikel_05/art_05-059/art_
059-01.html.
[Ulle09] Christian Ullenboom. Java ist auch eine Insel : Programmieren mit der
Java Plattform, Standard Edition 6. Galileo Computing. Galileo Press,
Bonn. 8. Auflage, 2009.
[Weid06] Johann Wilhelm Weidringer. Katastrophenmedizin: Leitfaden fuer die

Aerztliche Versorgung im Katastrophenfall. Bundesministerium des In-
ner, Berlin. http://www.gbv.de/dms/ilmenau/toc/514832827weidr.
PDF, 4. Auflage, 2006.
136

Diplomarbeit Marcel Noe

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit Marcel Noe

Hochgeladen von

Copyright:

Verfügbare Formate

Entwurf und Implementierung eines

kabellosen Sensornetzes zur

cand. inform. Marcel Noe

am Institut für Biomedizinische Technik

Erstgutachter: Prof. Dr. Armin Bolz

Bearbeitungszeit: 01. Mai 2010 – 01. November 2010

Diese Arbeit entstand in Rahmen des Erste-Hilfe-Sensor -Projektes in Kooperation mit

3. Stand der Technik 13

4.2. Der Analog Devices ADuC702X -Mikrocontroller . . . . . . . . . . . . . 36

5.5.4. Ergebnisse und Ereignisse . . . . . . . . . . . . . . . . . . . . . 72

6. Praktische Realisierung des Sensornetzes 77

9. Zusammenfassung und Ausblick 115

A. Beschreibung der beigelegten Software 123

A.6. Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

2.1. Frequenzspreizung mit dem FHSS -Verfahren (Frei nach Farahani) . . . 8

3.1. ZigBee-Stack (Quelle: Wikipedia) . . . . . . . . . . . . . . . . . . . . . 24

4.1. Blockdiagramm des ADuC7026 -Mikrocontrollers (Quelle: Analog Devi-

5.1. Überblick über das Gesamtsystem . . . . . . . . . . . . . . . . . . . . . 52

5.17. Klassendiagramm der Threads des MANVConnectors . . . . . . . . . . 76

7.1. Diagramm des Aufbaus des Integrationstests. . . . . . . . . . . . . . . . 94

3.1. Überschneidungen zwischen ZigBee, WLAN und Bluetooth-Kanälen . . 26

4.1. Übersicht der wichtigsten SerialNet-Befehle . . . . . . . . . . . . . . . 42

A.1. Struktur des Quellcodeverzeichnisses . . . . . . . . . . . . . . . . . . . 124

Kommunikation mit dem ZigBit Modul . . . . . . . . . . . . . . . . . . . . . 42

Firmware: Ansteuerung des ZigBit Moduls . . . . . . . . . . . . . . . . . . . 62

Seriellen Port auf Socket umleiten . . . . . . . . . . . . . . . . . . . . . . . . 83

I 2C Serieller Bus zum Anbinden von Komponenten an Mikrocon-

Interrupt Unterbrechungsaufforderung. Die Abarbeitung des aktuellen Pro-

Ohmsches Gesetz U =R·I

SSL Secure Socket Layer

1.1. Motivation der Arbeit

• 1980 — Oktoberfestattentat: 13 Tote, 211 Verletzte

• 1988 — Flugtagunglück von Ramstein: 70 Tote, 1000 Verletzte

• 1998 — ICE-Katastrophe von Eschede: 101 Tote, 88 Verletzte

• 2000 — Zugunglück von Brühl: 9 Tote, 149 Verletzte

• Dazu kommen jedes Jahr ca. 400.000 Verletzte im Straßenverkehr.

• Schwarz: Patient ist verstorben.

Obwohl diese Vorgehensweise eine schnelle Versorgung von Schwerverletzten gewähr-

1. Patienten können in die falsche Gruppe eingeordnet werden.

3. Es besteht ein Konflikt zwischen sorgfältiger Untersuchung und zu wenig zur

1.2. Aufgaben und Ziele der Arbeit

1.3. Gliederung und Vorgehensweise der Arbeit

nisse dieser Evaluation werden dann im Kapitel 8 diskutiert.

Abschließend wird der Inhalt dieser Arbeit in Kapitel 9 zusammengefasst, und es

In diesem Kapitel werden die in späteren Kapitel vorausgesetzten Grundlagen erörtert.

2.1. Grundlagen der kabellosen Übetragung

2.1.1. Paketvermittelte Übertragung

PSD (dBm) PSD (dBm)

PSD (dBm) PSD (dBm)

Abbildung 2.2.: Frequenzspreizung mit dem DSSS -Verfahren (Nach Farahani)

Bei der Verwendung von kabellosen Übertragungsprotokollen kann es zu einer Viel-

2.1.2.1. FHSS: Frequency Hoping Spread Spectrum

2.1.2.2. DSSS: Direct Sequence Spread Spectrum

2.1.2.3. FHSS vs. DSSS

DSSS ist im Vergleich zu FHSS weniger anfällig gegenüber schmallbandigen Störungen,

3.2. Kabellose Übertragungsprotokolle

Es sind zwei Betriebsmodi möglich:

• Infrastruktur-Modus: Eine zentrale Station ( Access-Point“ ) dient als Basissta-

• Ad-hoc-Modus: Diese Betriebsmodus kommt ohne zentrale Komponente aus. Es

Der Infrastruktur-Modus bietet gegenüber dem Ad-Hoc-Modus klare Vorteile: Im Ge-

Es werden verschiedene Datenübertragungsraten unterstützt. Standardmäßig wird im-

3.2.3.1. IEEE 802.11b

Der IEEE-802.11g-Standard stellt eine Erweiterung des IEEE-802.11b-Standards dar.

3.2.3.3. IEEE 802.11a