Entwurf und Implementierung eines kabellosen Sensornetzes zur Überwachung von Patienten bei einem Massenanfall von Verletzten

Größe: px
Ab Seite anzeigen:

Download "Entwurf und Implementierung eines kabellosen Sensornetzes zur Überwachung von Patienten bei einem Massenanfall von Verletzten"

Transkript

1 Entwurf und Implementierung eines kabellosen Sensornetzes zur Überwachung von Patienten bei einem Massenanfall von Verletzten Diplomarbeit von cand. inform. Marcel Noe am Institut für Biomedizinische Technik der Fakultät für Elektro- und Informationstechnik Erstgutachter: Zweitgutachter: Betreuender Mitarbeiter: Prof. Dr. Armin Bolz Prof. Dr. Rüdiger Dillmann Dr.-Ing. Marc Jäger Bearbeitungszeit: 01. Mai November 2010

2

3 Eidesstattliche Erklärung Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Diplomarbeit selbständig und ohne unzulässige fremde Hilfsmittel angefertigt habe. Die verwendeten Literaturquellen sind im Literaturverzeichnis vollständig angegeben. Die Arbeit wurde in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde zur Erlangung eines akademischen Grades vorgelegt. Karlsruhe,

4 II

5 Abstract Bei einem Massenanfall von Verletzten (MANV) kommt es oft zu personellen Engpässen, so dass eine ausreichende Überwachung der Patienten nicht gewährleistet ist. Abhilfe kann der am IBT entwickelte Erste-Hilfe-Sensor schaffen, der mit einem neuartigen Verfahren Puls und Atmung eines einzelnen Patienten überwacht. Zur Überwachung mehrerer Patienten muss ein kabelloses Netzwerk aus diesen Sensoren gebildet werden. Entsprechende Netzwerktechnologien existieren zwar, müssen aber in die bestehende Lösung integriert und um eine geeignete Überwachungssoftware ergänzt werden. Dies ist Aufgabe der vorliegenden Arbeit. Hierzu wird zunächst eine Untersuchung aller in Frage kommenden Funktechnologien unter besonderem Augenmerk auf Energieeffizienz und Stabilität vorgenommen. ZigBee stellt sich als bestgeeignetes Protokoll heraus, und es wird entschieden, eine Umsetzung auf Basis eines Moduls des Herstellers Atmel durchzuführen. Bei dessen genauerer Betrachtung werden einige Schwierigkeiten identifiziert beispielsweise das Auftreten von asynchronen Ereignissen, das zum Synchronisationsverlust führen kann. Lösungen für diese Schwierigkeiten werden gefunden und an Überwachungssoftware sowie Erste-Hilfe-Sensor konkret umgesetzt. Zur Gewährleistung einer hohen Flexibilität wird ein komponentenbasierter Ansatz gewählt. Hierdurch wird nicht nur die Austauschbarkeit der einzelnen Komponenten z.b. der eingesetzten Funktechnologie erreicht, sondern auch deren Verteilung über mehrere Rechner ermöglicht. Auf diesem Weg wird sowohl die Skalierbarkeit erhöht als auch eine Grundlage für verbesserte Ausfallsicherheit geschaffen. Die Verbindung der einzelnen Komponenten wird über Corba-Schnittstellen realisiert. Diese sind so gestaltet, dass auch externe Software angebunden werden kann. Exemplarisch gezeigt wird dies am Beispiel einer Weboberfläche. Damit wird gleichzeitig die Verwendung von Mobiltelefonen als Endgeräte zur Patientenüberwachung ermöglicht, ohne dass eine Installation von Software auf diesen Geräten notwendig ist. Darü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 für den erweiterten Erste-Hilfe-Sensor und ist gleichzeitig auch Testumgebung. Bei einer eingehenden Evaluierung des Gesamtsystems wird die Interoperabilität aller Komponenten gezeigt. Außerdem wird die Leistungsaufnahme des ZigBee-Moduls in Abhängigkeit von den Parametern des Energiesparmodus untersucht. Insgesamt zeigt sich, dass Laufzeit, Reichweite und die erreichbare Anzahl an Sensoren für MANV-Szenarien mit hunderten von Verletzten ausreichend sind. III

6

7 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 beschäftigt sich mit dem Entwurf und der Implementierung der Ü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 Überwachung von Patienten mit Hilfe eines induktiven Verfahrens. Dies bietet einige Vorteil gegenüber klassischen EKG-basierten Verfahren. Die eigentliche Funktionsweise des Erste-Hilfe- Sensors ist für die vorliegende Arbeit nicht weiter relevant, lediglich auf den verwendeten Mikrocontroller muss Rücksicht genommen wurden. Bei dieser Arbeit wurde ich von zahlreichen Helfern unterstüzt, bei denen ich mich auf diesem Weg bedanken möchte. Die wichtigste Person bei der Durchführung dieser Arbeit war mein Projektpartner Herr cand. inform Jan Tepelmann, der auf meine Bitten bereit war, die Implementierung der Überwachungssoftware in Form einer Studienarbeit durchzuführen. Er war immer ein wertvoller Diskussionpartner, ohne dessen Hilfe es in der gegebenen Zeit nicht mö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 interdisziplinären Arbeit zu ermutigen. Herr Professor Dr. Rüdiger Dillmann hat sich bereit erklärt, von Seiten der Fakultät für Informatik ein Gutachten durch-

8 zuführen ohne dies wäre ein Durchführen dieser Arbeit gar nicht möglich gewesen. Mein Betreuer, Herr Dr. Marc Jäger hat mir immer wieder mit wertvollen Gesprächen zur Seite gestanden, und mir viele Tipps zur korrekten Durchführung gegeben. Insbesondere hat er mir als Diplomand ein hohes Maß an Vertrauen entgegengebracht, und mir so ermöglicht, das Geplante praktisch umzusetzen. Seine Firma, die Neocor GmbH hat dabei die Kosten für die notwendige Hardware übernommen. Von unschätzbarem Wert während des Studiums war und ist mein langjähriger guter 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 für meine Sorgen und Nö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 während der Diplomarbeit ein wichtiger Diskussionspartner für Hardwarefragen war. Auch meinem Freund Herrn Dipl.-Inform. (FH) Markus Müller möchte ich fü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 weitergeholfen hat, sowie Herrn Dipl.-Ing Stefan Fernsner für die Hilfe beim Erstellen der MANVNode-Platinen. Auch bedanken möchte ich mich bei Frau Dipl.-Phys. Kerstin Grimmel, Herrn Dipl.-Ing Nikolas Lentz und Herrn M. Sc. Firas Salih für zahlreiche anregende und hilfreiche Diskussionen. Von ganzem Herzen bedanken möchte ich mich bei meiner Lebenspartnerin Frau Dipl.- Phys. Jennifer Girrbach sowie meinen Eltern, meinen Geschwistern und meiner Familie und Freunden für den Rückhalt den sie mir in dieser anstrengenden Zeit gegeben haben, und den Mut, den sie mir zusprachen. VI

9 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis Glossar XIV XV XVII XXIX 1. Einleitung Motivation der Arbeit Aufgaben und Ziele der Arbeit Gliederung und Vorgehensweise der Arbeit Grundlagen Grundlagen der kabellosen Übetragung Paketvermittelte Übertragung Frequenzspreizung FHSS: Frequency Hoping Spread Spectrum DSSS: Direct Sequence Spread Spectrum FHSS vs. DSSS Java Programmiersprache Python Corba

10 Inhaltsverzeichnis 3. Stand der Technik Einleitung Kabellose Übertragungsprotokolle DECT GSM/UMTS WLAN IEEE b IEEE g IEEE a Störsicherheit Leistungsaufnahme WPAN: Wireless Personal Area Networks IEEE IEEE : Bluetooth Pairing Reichweite Übertragungsrate Störsicherheit Anzahl Teilnehmer Leistungsaufnahme IEEE : ZigBee Netzstruktur Störsicherheit Verschlüsselung Leistungsaufnahme Bluetooth Low Energy (ehemals Wibree) Weitere Protokolle Diskussion Produkte zur kabellosen Patientenüberwachung Verwandte Projekte zum Einsatz in MANV-Szenarien Analyse Anforderungen an ein kabelloses System zur Überwachung von Patienten 35 VIII

11 Inhaltsverzeichnis 4.2. Der Analog Devices ADuC702X -Mikrocontroller Beschreibung Peripherie Die Atmel-ZigBit-Familie Hardware Firmware Bitcloud SerialNet SerialNet AT-Protokoll Kommunikation mit dem ZigBit-Modul Problemstellung Behandlung asynchron auftretender Ereignisse Behandlung von komplexen Antworten Kombination beider Lösungen Powermanagement Entwurf Gesamtsystem MANVNode Hardware Spannungsversorgung Serielle Schnittstellen JTAG LED-Anzeige Diagnosecodes Firmware Ansteuerung des UARTs Ansteuerung des ZigBit-Modul ZigBee-USB-Stick MANVSuite MANVConnector Threads Repräsentation eines ZigBit-Moduls Synchronisierung der Befehlsübertragung IX

12 Inhaltsverzeichnis Ergebnisse und Ereignisse Praktische Realisierung des Sensornetzes Hardware Anbindung des ZigBit-Moduls an den USB-Port Herstellung und Bestückung der Platine der MANVNode Firmware Verwendete Interrupts Zugriff auf UART MANVConnector Zugriff auf die serielle Schnittstelle Automatische Erkennung des ZigBit-USB-Sticks CORBA-Anbindung Ergebnisse Realisierbarkeit Integrierbarkeit in den Erste-Hilfe-Sensor Interoperabilität aller Komponenten Durchführung Ergebnisse Austauschbarkeit des MANVConnectors Anbindbarkeit an externe Software Durchführung Ergebnisse Leistungsaufnahme des ZigBit-Moduls Leistungsaufnahme im Normalbetrieb Leistungsaufnahme bei Verwendung des Energiesparmodus Sonderfälle Batterielaufzeit Reichweite Reichweite im Freien Reichweite innerhalb geschlossener Räume Maximale Teilnehmerzahl des Netzwerke X

13 Inhaltsverzeichnis 8. Diskussion Zusammenfassung und Ausblick Zusammenfassung Sicherheit des Netzwerkes Aktueller Stand Angriffsszenarien Ausspähen von Patientendaten Aktiver Angriff gegen das Netzwerk Störung des Netzwerkes Abwehrmaßnahmen ZigBee-Verschlüsselung Befehlszähler Schutz auf Anwendungsebene Verbesserung der Reichweite und Störsicherheit Anderer Frequenzbereich Verwendung leistungsstärkerer ZigBee-Module und Antennen Genauere Betrachtung des Bluetooth-Low-Energy-Standards A. Beschreibung der beigelegten Software 123 A.1. MANV-Connector A.1.1. Starten des Connectors A.1.2. Kompilieren des Connectors A.1.3. Verzeichnisstruktur des Quellcodes A Inhalt des Verzeichnises commands/ A Inhalt des Verzeichnises corba/ A Inhalt des Verzeichnisses events/ A Inhalt der Verzeichnises results/ A Inhalt des Verzeichnisses lib/ A Interface eines ZigBit-Knotens A.2. Serial-To-Socket A.3. Firmware A.4. MANV-Web A.5. Platine XI

14 Inhaltsverzeichnis A.6. Simulator A.7. Zigbit Firmware Literaturverzeichnis 136 XII

15 Abbildungsverzeichnis 2.1. Frequenzspreizung mit dem FHSS-Verfahren (Frei nach Farahani) Frequenzspreizung mit dem DSSS-Verfahren (Nach Farahani) ZigBee-Stack (Quelle: Wikipedia) Blockdiagramm des ADuC7026 -Mikrocontrollers (Quelle: Analog Devices) Blockdiagramm des ZigBit-24-A2R-Moduls (Quelle: Atmel) Darstellung des SerialNet-Protokolls als Zustandsautomat Überblick über das Gesamtsystem Schaltplan der MANVNode: Mikrocontroller Schaltplan der MANVNode: ZigBit-Modul Entwurf der Platine der MANVNode Schaltplan der Spannungsversorgung der MANVNode Schaltplan der MANVNode: JTAG Schaltplan der MANVNode: LED-Anzeige und Taster Ablauf der Ansteuerung des ZigBit-Moduls in der ZigBit-Firmware Schaltplan des USB-Sticks Entwurf der Platine des USB-Sticks Datenfluss zwischen den einzelnen Kompnenten des Gesamtsystems Interaktion der einzelnen Threads des MANVConnectors Klassendiagramm der ZigBit-Klassen Klassendiagramm der Ereignisse und Ergebnisse des MANVConnectors Klassendiagramm des MANV-Connectors (Linke Seite) Klassendiagramm des MANV-Connectors (Rechte Seite)

16 Abbildungsverzeichnis Klassendiagramm der Threads des MANVConnectors MANV-USB-Stick Fertig bestückte Platine der MANVNode Komponentendiagramm der CORBA-Schnittstellen. (Quelle: Jan Tepelmann) Diagramm des Aufbaus des Integrationstests Photo des Aufbaus des Integrationstests Screenshot der MANVGui während des Integrationstests Router oder Koordinator im Normalbetrieb Endknoten im Normalbetrieb ohne Energiesparmodus Analyse des Spannungsverlaufs eines Clients im Normalbetrieb Detailaufnahme eines Empfangsmodus-Peaks Aus dem Energiesparmodus erwachter Client Analyse des Spannungsverlaufs eines Clients bei Nutzung des Energiesparmodus Client, der das periodische Aufrufen des Energiesparmodus nutzt Client mit deaktiviertem Empfangsmodus Beitrittsvorgang eines Clients in ein Netzwerk Client, der die Verbindung zum Netzwerk verloren hat XIV

17 Tabellenverzeichnis 3.1. Überschneidungen zwischen ZigBee, WLAN und Bluetooth-Kanälen Übersicht der wichtigsten SerialNet-Befehle Übersicht der SerialNet-Ereignisse Berechnung von I P owersave für exemplarische Werte von t sleep und t awake. 104 A.1. Struktur des Quellcodeverzeichnisses

18

19 Quellcodeverzeichnis Kommunikation mit dem ZigBit Modul Befehle in Warteschlange einreihen Komplexe Antworten behandeln Komplexe Antworten und Asynchrone Ereignisse behandeln Firmware: Ansteuerung des ZigBit Moduls Firmware: Ansteuerung des ZigBit Moduls inkl. Ereignissbehandlung Seriellen Port auf Socket umleiten USB Bus durchsuchen Devicenode lokalisieren ZigBit Modul erkennen

20

21

22

23 Glossar I 2 C Serieller Bus zum Anbinden von Komponenten an Mikrocontroller. 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 Benutzeroberflächen auf Basis von Webseiten unter Einsatz von Javascript und JSON. Algorithmus Eindeutige Handlungsvorschrift bzw. Anweisungsfolge zur Lösung eines Problems. ANT+ Proprietärer Funkstandard für die Datenübertragung im Nahbereich, z.b. für Pulsuhren. ARM RISC-Prozessorarchitektur, die von verschiedene Herstellern in Lizenz gefertigt wird. AT-Befehlssatz Satz von Befehlen, der ursprünglich zur Steuerung von Modems entwickelt wurde. Beacon dt. Leuchtfeuer periodisches Bekanntmachen des Vorhandenseins des Netzwerks. Bit Kleinste Informationseinheit eines Computers, kann die Zustände 1 und 0 annehmen.

24 Glossar BitCloud SDK zur Erstellung von Firmware für die ZigBee-Module der Firma Atmel. Bluetooth Kabelloser Übertragungsstandard für WPANs. Broadcast Datenpaket, das an alle Empfänger im Netzwerk gesendet wird. Browser Siehe Webbrowser. BSD UNIX -artiges Betriebssystem. Bus Verbindung zwischen mehreren Geräten, bei denen alle Geräte an einen gemeinsamen Übertragungsweg angeschlossen sind. Busy-Waiting Warten auf ein Ereignis unter Verschwendung von Prozessorleistung. Byte 8 Bit C Imperative Programmiersprache, insbesonders zur hardwarenahen Entwicklung. C++ Objektorientierte Programmiersprache auf Grundlage von C. Cast Ändern des statischen Datentyps einer Variable auf einen anderen Typ. CD Compact Disc Client Komponente, die einen Dienst nutzt. Corba Hier: Programmiersprachen-unabhängige Middleware. CRC Cyclic Redundancy Check Crossworks Entwicklungsumgebung fü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 für festnetzgebundene Funktelefone. Denial-Of-Service Blockieren eines Dienstes durch Überfluten mit Anfragen oder Ausnutzen eines Softwarefehlers. XXII

25 DRAM DSSS EDR EEPROM EKG Energy Detection FFD FHSS Firmware Flashen Flashspeicher GPIO GPS GUI Hashmap HF Host HTTP I IC Idle Task IEEE Interface Dynamischer RAM, der periodisch aufgefrischt werden muss, um seinen Inhalt zu erhalten. Direct Sequence Spread Spectrum. Enhanced Data Rate Electrically Erasable Programmable Read-Only Memory Elektrokardiogramm Überwachung der Herztätigkeit durch Ableiten elektrischer Signale. Überprüfen, ob ein Frequenzband frei ist, bevor es zur Datenübertragung verwendet wird. Full Function Device Frequency Hoping Spread Spectrum Software, die fest in ein Hardware-Gerät eingebettet ist. Programmieren eines Flashspeichers. Günstigere Variante eines EEPROMS, das zur Massendatenspeicherung verwendet werden kann. General Purpose Input/Output Global Positioning System Ein Satellitennavigationssystem. Graphische Benutzeroberfläche. Datenstruktur, die aus Paaren aus Schlüsseln und Werten besteht. Auch bekannt als assoziatives Array oder Record. Hochfrequenz Computer, der Dienste anbietet. Hypertext Transfer Protocol Protokoll zur Übertragung von Webseiten. Strom. Integrierter Schaltkreis Aufgabe, die immer dann bearbeitet wird, wenn keine anderen Aufgaben anstehen. Institute of Electrical and Electronics Engineers Beschreibung der Schnittstelle eines Objektes über Signaturlisten. XXIII

26 Glossar Interrupt IO-Port ISM-Band ISR Java Javascript JRE JSON JVM kbit Klasse Klasse km Kompilieren LAN LED Linux Low-Dropout Lötstopplack m Unterbrechungsaufforderung. Die Abarbeitung des aktuellen Programmcodes wird sofort beendet, und eine ISR wird ausgeführt. Input/Output-Port Industrial, Scientific and Medical Band Mehrere Frequenzbänder, für deren Benutzung eine allgemeine Betriebserlaubnis ausreicht. Interrupt-Service-Routine Programmiersprache der Firma Sun Microsystems. Skriptsprache, die vor allem in Webbrowsern eingesetzt wird. Java Runtime Environment Javascript-basiertes Datenübertragungsformat von Webservern zu Webbrowsern. Java Virtual Machine Kilobit Abstraktes Modell eines Objektes in der objektorientierten Programmierung. Definiert Methoden und Attribute eines Objektes. Datenstruktur, die Eigenschaften, Attribute und Methoden eines Objektes beschreibt. Kilometer Übersetzen des Quellcodes eines Programms in ausführbaren Binärcode. Local Area Network Leuchtdiode Freies UNIX -artiges Betriebssystem. Spannungsregler, der mit niedriger Differenz zwischen Eingangsund Ausgangsspannung arbeiten kann. Auf Leiterplatten aufgetragene Lackschicht, die die Leiterbahnen schützt. Meter XXIV

27 MAC MacOS Man-in-the-middle MANV MANVNode MANVSuite MBit Mesh-Netzwerk mf MHz Middleware MIPS Monitor MSPS Multicast Multimeter mv mw Nameserver nf Objekt Media Access Control Betriebssystem der Firma Apple Computer. Angriff, bei dem Datenpakete zwischen zwei Kommunikationspartnern durch einen Angreifer abgefangen werden und der Inhalt der Pakete manipuliert wird. Massenanfall von Verletzten Test- und Entwicklungsplatine für den kabellosen Erste-Hilfe- Sensor. Verwaltungssoftware des Sensornetzwerks. Megabit (Voll-)Vermaschtes Netzwerk, meist in Verbindung mit mobilen Ad-Hoc Netzwerken, bei denen einzelne Knoten untereinander spontan Netzwerke bilden. Millifarad Megahertz Softwarelösung zum Zugriff auf von Objekten auf entfernten Rechnern. Million Instructions per Second Gerät zur Überwachung von Vitaldaten von Patienten. Million Samples per Second Datenpaket mit mehreren bestimmten Empfängern. Mehrzweckmessgerät, das unter anderem Strom und Spannung messen kann. Millivolt Milliwatt Softwaredienst, der eine Übersetzung von Namen in Adressen vornimmt. Nanofarad Instanz einer Klasse. Kapselt Daten und Programmcode zum Zugriff dieser Daten in einer gemeinsamen Datenstruktur. Hierdurch wird die konkrete Implementierung hinter eine Schnittstelle versteckt und wird damit austauschbar. XXV

28 Glossar Ohmsches Gesetz OOP Open Source OpenSSL OSI-Modell Oszilloskop PC Peak Peer-to-Peer Piezo-Summer PIN PKW PLA Port Power-Management Prozess Pseudocode U = R I Objektorientierte Programmierung: Programmierung mit Hilfe von Klassen, Objekten und Vererbung. Softwareprodukt, bei dem der Quellcode frei verfügbar ist. Open Source Bibliothek, die viele Verschlüsselungsverfahren implementiert. Generisches Schichtenmodell von Netzwerkprotokollen. Definiert 7 Schichten. Jede Schicht ist greift nur auf die Dienste der direkt darunterliegenden Schicht zu und bietet wiederum Dienste für die darüber liegende Schicht an. Dies ermöglicht einen modularen Aufbau von Netzwerkprotokollen, da die Schichten unabhängig voneinander ausgetauscht werden können. In praktisch eingesetzten Netzwerkprotokollen sind meist nicht alle 7 Schichten implementiert. Messgerät zur optischen Darstellung von zeitlichen Spannungsverläufen. Personal Computer Lokales Maximum (oder je nach Messrichtung auch Minimum) eines Spannungsverlaufs. Verbindungen zwischen zwei oder mehr Teilnehmern, bei denen alle Teilnehmer gleichberechtigt sind. Elektrisches Bauteil, dass einen Summton generiert, sobald man eine Spannung anlegt. Persönliche Identifikationsnummer Personenkraftwagen. Programmierbare logische Anordnung Schnittstelle Energieverwaltung Maßnahmen um Energie zu sparen. Menge von einem oder mehreren Threads inklusive eines dazugehörigen Speicherbereiches. Vereinfachter Quellcode zur einfachen Beschreibung von Algorithmen. XXVI

29 Python R RAM Replay RFD Ringpuffer RISC Router RS-232 RTS Sample Sampling Schicht SDK Serialnet Server Setup Shunt SIG Signatur Skripstprache Socket SPI SRAM Objektorientierte Skriptsprache. Widerstand. Random Access Memory Angriff, bei der legitime Datenpakete abgefangen und zu einem späteren Zeitpunkt wieder ins Netzwerk eingegeben werden. Reduced Function Devices Datenstruktur, die sich selbst überschreibt, wenn sie über ein gewisses Maß gefüllt wurde. Reduced Instruction Set Computer. Netzwerkgerät, das Pakete zwischen Teilnehmern weiterleitet. Übertragungsstandard für serielle Schnittstellen. Ready to Send Siehe Sampling. Umwandlung eines analogen in ein digitales Signal mittels Abtastung. Siehe OSI-Modell. Software Development Kit Firmware für die ZigBee-Module der Herstellers Atmel. Komponente, die einen Dienst anbietet. Aufbau Niederohmiger Widerstand zur Messung von Strömen mit einem Spannungsmessgerät. Special Interest Group Typ und Name einer Methode sowie ihrer Parameter. Programmiersprache, deren Quellcode nicht kompiliert wird. Softwareabstraktion einer Netzwerkverbindung die sich verhält wie ein Dateizugriff. Serieller Bus zum Anbinden von Komponenten an Mikrocontroller. Statischer RAM auf Basis von sogenannten Flip-Flop-Bausteinen. Benötigt im Gegensatz zu DRAM kein periodisches Auffrischen des Inhalts. XXVII

30 Glossar SSL SSP Stack Startup-Code Symbian Thread Timeout TinyOS TLS Token Transceiver Treiber U UART UML Unicast UNIX Secure Socket Layer Secure Simple Pairing Stapel, entweder als Datenstruktur in einer Programmiersprache, Stapelspeicher eines Prozessors oder im Sinne eines Protokollstapels. Programmcode, der die Initialisierung eines Mikrocontrollers durchführt. Betriebssystem für ein Nokia-Handys. Ausführungsstrang eines Programms. Ein Programm kann mehrere Threads haben, die parallel arbeiten. Fehler, der durch das Überschreiten einer Zeitgrenze aufgetreten ist. Open-Source-Betriebssystem für Sensornetzwerke. Transport Layer Security Nachfolger von SSL. Sendeerlaubnis innerhalb eines Netzwerks, die von Teilnehmer zu Teilnehmer gereicht wird. Sende- und Empfangseinheit. Softwareprogramm, das die Ansteuerung eines Hardware-Gerätes übernimmt. Spannung. Universal Asynchronous Receiver Transmitter Unified Modeling Language Graphische Modelierungssprache zum Entwurf von Software. Datenpaket mit einem bestimmten Empfänger. Familie von Mehrbenutzerbetriebssystemen. USB Universal Serial Bus Universelle Schnittstelle, die seit ca an nahezu jedem PC vorhanden ist. Vererbung Virtuelle Maschine VM Mechanismus zur Wiederverwendung von Oberklassenimplementierungen in einer Unterklasse. In Software implementierter, uirtueller Computer. siehe Virtuelle Maschine XXVIII

31 W Webbrowser Webinterface Webserver WEP Windows WLAN WPA WPAN ZC ZED ZigBee ZR Watt Programm zum Anzeigen von Webseiten. Graphische Benutzeroberfläche auf Basis einer Webseite. Software, die Webseiten ausliefert. Wired Equivalent Privacy Nicht mehr zeitgemäßes Verschlüsselungsverfahren für WLAN -Netzwerke. Betriebssystemfamilie der Firma Microsoft. Wireless Local Area Network Wi-Fi Protected Access Neuer Verschlüsselungsstandard für WLAN -Netzwerke. Wireless Personal Area Network ZigBee Coordinator ZigBee End Device Kabelloser Übertragungsstandard für Sensornetzwerke. ZigBee Router XXIX

32

33 1. Einleitung In diesem Kapitel wird zunächst die Arbeit motiviert. Danach werden die Aufgaben und Ziele definiert. Abschliessend wird die Gliederung der folgenden Kapitel erläutert 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 mögen dem Leser zuerst Vorfälle wie die Terroranschläge am 11. September 2001, die Reaktorkatastrophe von Tschernobyl oder spektakulä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 Zugunglück, eine Massenpanik bei einem Konzert oder starke Schneefälle, wie sie im vergangengen Winter aufgetreten sind können den Rettungsdienst einer Region sehr schnell an die Grenzen seiner Leistungsfähigkeit bringen. Beispielhaft seien hier folgende Ereignisse der letzten Jahre und Jahrzehnte genannt: 1980 Oktoberfestattentat: 13 Tote, 211 Verletzte 1988 Flugtagunglück von Ramstein: 70 Tote, 1000 Verletzte 1998 ICE-Katastrophe von Eschede: 101 Tote, 88 Verletzte 2000 Zugunglück von Brühl: 9 Tote, 149 Verletzte

34 1. Einleitung Dazu kommen jedes Jahr ca Verletzte im Straßenverkehr. Im Falle eines Massenanfalls von Verletzten treffen vor Ort viele unterschiedliche Einheiten von Rettungskräften aufeinander. Um die Zusammenarbeit dieser Kräfte überhaupt zu ermöglichen und ein geordnetes Vorgehen zu unterstützen, gibt es klar definierte Abläufe und Verantwortlichkeiten. Zunächst versuchen die Rettungskräfte, die Patienten außerhalb des unmittelbaren Gefahrenbereichs abzulegen. An dieser Ablagestelle werden die Patienten vom Rettungsdienst übernommen, welcher auch bereits lebensrettende Sofortmaßnahmen einleitet und eine Erstversorgung durchführt. Wenn mö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 genügend Ressourcen (sowohl Material als auch Personal) vorhanden sind, um sofort alle Patienten zu versorgen. Daher gilt das Ziel, dass möglichst viele Patienten den Vorfall mit einem möglichst geringen Schaden überstehen. Um eine Zuteilung der vorhandenen Ressourcen gemäß dieses Ziels zu gewährleisten, erfolgt eine Einordnung der Patienten in 4 Kategorien[Weid06]: Grün: Patient ist ansprechbar und kann sich selbstständig vom Unfallort wegbewegen. Gelb: Patient hat Behandlungsbedarf und kann sich nicht mehr selbstständig vom Unfallort entfernen, befindet sich jedoch nicht in akuter Lebensgefahr. Rot: Patient befindet sich in einem akut lebensbedrohlichen Zustand (z.b. Kreislaufstillstand, hoher Blutverlust) und benötigt sofortige medizinische Behandlung. Schwarz: Patient ist verstorben. Obwohl diese Vorgehensweise eine schnelle Versorgung von Schwerverletzten gewährleistet, stellt sich eine Reihe von Problemen: 1. Patienten können in die falsche Gruppe eingeordnet werden. 2. Möglicherweise verschlechtert sich der Zustand eines Patienten nach seiner Einteilung in die Gruppe Gelb rapide, so dass er sofortiger Versorgung bedarf. 2

35 1.2. Aufgaben und Ziele der Arbeit 3. Es besteht ein Konflikt zwischen sorgfältiger Untersuchung und zu wenig zur Verfü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 Überprüfung von Atmung, Puls und Blutdruck erfolgt durch einfache physische Methoden wie Anfassen, Hören und Beobachten. Insbesondere der zweite Punkt obiger Aufzählung könnte mit technischen Mitteln entschieden verbessert werden. Da eine dauerhafte Überwachung nur deswegen nicht erfolgt, weil nicht genügend Personal zur Verfügung steht, könnte dieses durch ein automatisches System ersetzt werden, welches die Patienten überwacht und im Falle einer Zustandsänderung eine Alarmierung durchführt. Zwar gibt es automatische Überwachungssysteme (sogenannte Monitore), die in Krankenhäusern oder Rettungsfahrzeugen zur Patientenüberwachung eingesetzt werden. Allerdings sind diese Systeme für den Einsatz in einem MANV-Szenario ungeeignet, da sie zu groß, zu teuer und zu kompliziert sind Aufgaben und Ziele der Arbeit Ziel dieser Arbeit ist die Entwicklung und prototypische Implementierung eines kabellosen Netzwerkes zur Überwachung von Patienten während eines MANVs. Als Ausgangsbasis hierfür dient der am IBT von Marc Jäger in [Jäg08] entwickelte Erste- Hilfe-Sensor. Hierbei soll der Sensor in die Lage versetzt werden, die Vitaldaten des angeschlossenen Patienten kabellos an eine zentrale Überwachungsstation zu übertragen. Die zu entwickelnde Lösung soll eine große Anzahl von Teilnehmern unterstützen, zugleich aber auch möglichst kostengünstig sein. Darüber hinaus soll sie möglichst stromsparend sein, damit der Erste-Hilfe-Sensor auch längere Zeit über eine kleine Batterie (idealerweise eine Knopfzelle) betrieben werden kann. Parallel zu dieser Arbeit wird von Jan Tepelmann in [Tepe10] eine Steuerrungssoftware ( MANVSuite ) für die Überwachungsstation des Netzwerkes entwickelt. Zu dieser Software soll eine Schnittstelle zur Verfügung gestellt werden, über die zum einen die Vitaldaten ausgeliefert, zum anderen Befehle an die einzelnen Sensoren empfangen werden. Diese Schnittstelle soll netzwerkfähig sein. 3

36 1. Einleitung 1.3. Gliederung und Vorgehensweise der Arbeit Zunächst wird in Kapitel 2 eine kurze Einführung in die Grundlagen, die zum Verständnis dieser Arbeit wichtig sind, gegeben. Dies ist insbesondere deshalb wichtig, da es sich um eine interdisziplinäre Arbeit zwischen Informatik und Elektrotechnik handelt. Im darauf folgenden Kapitel wird der aktuelle Stand der Technik genauerer Betrachtung unterzogen. Hierbei werden zunächst kabellose Netzwerkprotokolle betrachtet und auf ihre Eignung zur Lösung der gestellten Problemstellung untersucht. Hierbei erweist sich das ZigBee-Protokoll als besonders geeignet. Daraufhin erfolgt ein kurzer Überblick über die Marktsituation bei Produkten zur kabellosen Patientenüberwachung. Im Abschluss des Kapitels werden einige verwandte Projekte vorgestellt und auf Ähnlichkeiten und Unterschiede untersucht. Aus dem Stand der Technik werden in Kapitel 4 nun die Anforderungen an die zu entwickelnde Lösung aufgestellt. Anschließend werden die Bauteile vorgestellt, die zur Implementierung der Lösung verwendet werden. Diese werden auf Ihre Eignung untersucht und es werden zu beachtende Eigenheiten herausgearbeitet. Für diese Eigenheiten werden verschiedene Lösungsmöglichkeiten vorgestellt und analysiert, die im späteren Verlauf der Arbeit als Grundlage für Entwurf und Implementierung dienen werden. Der eigentliche Entwurf wird in Kapitel 5 beschrieben. Hier wird als Erstes ein grober Entwurf des Gesamtsystems durchgeführt, in dem zunächst die zentralen Komponenten der Lösung identifiziert werden. Im weiteren Verlauf des Kapitels wird der detailierte Entwurf jeder dieser Komponenten dargestellt, so dass diese implementiert werden können. Bei dem Entwurf wird zwischen Hardware und Software unterschieden. Kapitel 6 behandelt die praktische Umsetzung des theoretischen Entwurfs. Ein Schwerpunkt bildet hier die Beschreibung der praktischen Probleme, die bei der Umsetzung aufgetreten sind, sowie deren Lösung. In Kapitel 7 wird sodann eine genaue Evaluierung der entwickelten Lösung in Hinblick auf Erfüllung der in Kapitel 4 aufgestellten Anforderungen, durchgeführt; die Ergeb- 4

37 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 Vorschläge gemacht, wie die in dieser Arbeit entwickelte Lösung weiter ausgebaut und verbessert werden kann. Abgerundet wird die Arbeit durch einen umfangreichen Anhang, in dem eine Hilfestellung zur Umsetzung der in der Arbeit entwickelten Lösung in ein fertiges Produkt geliefert wird. 5

38

39 2. Grundlagen In diesem Kapitel werden die in späteren Kapitel vorausgesetzten Grundlagen erörtert. Hierzu gehören zum einen die Grundlagen der kabellosen Übertragung, zum anderen eine kurze Beschreibung der Programmiersprachen Java und Python sowie der Corba- Middleware Grundlagen der kabellosen Übetragung Zum besseren Verständnis der in dieser Arbeit beschriebenen kabellosen Übertragungsprotokolle werden in diesem Abschnitt einige Grundbegriffe der kabellosen Übertragung erklärt Paketvermittelte Übertragung Bei der Übertragung von Daten kann grundsätzlich zwischen der Paket- und der Leitungsvermittlung unterschieden werden. Bei der Leitungsvermittlung wird für jeden Kommunikationsvorgang ein eigener Kanal verwendet. Meist wird dieser Kanal zu Beginn der Kommunikation auf- und beim Ende wieder abgebaut. Hierbei wird meist ein fester Weg vorgegeben, den die zu sendenden Daten zwischen zwei Partnern zurücklegen. Über diesen Kanal gesendete Daten kommen beim Empfänger in genau der selben Reihenfolge an, wie sie vom Sender gesendet wurden. Auch steht meist eine garantierte Mindestübertragungsrate zur Verfügung. Diesen Vorteilen steht eine Reihe von Nachteilen gegenüber. Für Aufbau und Betrieb

40 2. Grundlagen der Leitung muss ein gewisser Aufwand betrieben werden. Wenn Übertragungsraten garantiert werden, stehen diese ggf. nicht für andere Anwendungen zur Verfügung. Wird die Kapazität der Leitung nicht ausgeschöpft, so bleiben diese Reserven ungenutzt und verfallen. Anders verhält sich die Paketvermittlung. In diesem Szenario teilen sich alle Teilnehmer eine gemeinsame Leitung. Möchte nun ein Teilnehmer Daten senden, so teilt er sie in kleine Pakete auf und versieht diese mit der Adresse des Empfängers. Nun wird jedes Paket einzeln über die Leitung verschickt. Hierbei passiert es ggf. eine Reihe von Zwischenstationen, die es jeweils zur nächsten Zwischenstation weiterleiten, bis der endgültige Empfänger erreicht ist. Da sich nun viele Empfänger eine Leitung teilen, kann eine deutlich bessere Auslastung erzielt werden. Jedoch können nun keine Garantien mehr über die Reihenfolge, Zuverlässigkeit sowie die einem Teilnehmer zur Verfügung stehende Übertragungsrate gegeben werden. Diese Probleme können jedoch teilweise in höheren Protokollschichten (z.b. durch Nummerierung und Umsortieren der Pakete beim Empfänger) behandelt werden. Bei der kabellosen Datenübertragung teilen sich alle Teilnehmer ein gemeinsames Medium, nämlich die Trägerfrequenzen des verwendeten Funkprotokolls. Eine Vermittlung von einzelnen Leitungen scheidet prinzipbedingt aus, da es nicht möglich ist, einzelne Teilnehmer am Senden auf einer Frequenz zu hindern. Daher bietet sich die Verwendung eines paketvermittelten Übertragungsprotokolls für kabellose Netzwerke besonders an Frequenzspreizung PSD (dbm) PSD (dbm) F 2 MHz 250kHz F Abbildung 2.1.: Frequenzspreizung mit dem FHSS-Verfahren (Frei nach Farahani) 8

41 2.1. Grundlagen der kabellosen Übetragung PSD (dbm) PSD (dbm) 250kHz F 2MHz F Abbildung 2.2.: Frequenzspreizung mit dem DSSS-Verfahren (Nach Farahani) Bei der Verwendung von kabellosen Übertragungsprotokollen kann es zu einer Vielzahl von Störungen kommen. Übliche Störquellen sind andere Protokolle, die im selben Band arbeiten, oder elektrische Geräte, die durch ihre Abstrahlung den Funkverkehr stören 1. Aber auch auf Grund von Mehrwegeausbreitung kann es zu Problemen kommen. Da diese Störungen meist nur auf einzelnen Frequenzen vorliegen, kann mit Hilfe der Frequenzspreizung der Einfluß von Stö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 Störung auf einer einzelnen Frequenz vor, kann das Nutzsignal trotzem noch erfolgreich empfangen werden FHSS: Frequency Hoping Spread Spectrum Bei dem FHSS-Verfahren handelt es sich um die einfachste Möglichkeit, ein Signal zu spreizen. Hierbei wird einfach nach einer bestimmten Zeiteidauer die Sendefrequenz gewechselt, so dass eine Spreizung über den Zeitverlauf erreicht wird. [Tofa05] DSSS: Direct Sequence Spread Spectrum Bei dem DSSS-Verfahren wird das Nutzsignal über einen breiten Frequenzbereich aufgefächert. Hierzu wird das Nutzsignal mit einem Spreizkode multipliziert. Beim Empfang teilt der Empfänger nun das empfangene Signal durch diesen Spreizcode und 1 Insbesondere sind hier Mikrowellengeräte zu nennen, die im 2.4-GHz-Band arbeiten. 9

42 2. Grundlagen erhält so das ursprüngliche Signal. Störungen werden hingegen durch die Operation deutlich erkennbar und können einfach ausgefiltert werden. [Tofa05] [Fara08] FHSS vs. DSSS FHSS besitzt gegenüber DSSS den Vorteil, dass es mit geringerem Aufwand realisiert werden kann. Dies wird jedoch mit einem höheren Aufwand in der Software erkauft: Kommt es auf einer Frequenz zu einer Störung, so geht oft das aktuell gesendete Datenpaket verloren. Dies muss von der Software erkannt werden. Eine erneute Übertragung des verlorenen Paketes ist erforderlich. DSSS ist im Vergleich zu FHSS weniger anfällig gegenüber schmallbandigen Störungen, da diese komplett ausgefiltert werden können, wohingegen es beim FHSS-Verfahren zu Paketverlusten kommen kann. Liegt jedoch eine breitbandige Störung vor, so ist mit FHSS meist noch eine Kommunikation wenn auch mit geringerer Übertragungsrate möglich, wenn diese mit dem DSSS-Verfahren bereits zum Erliegen gekommen ist. Da das DSSS-Verfahren die Gesamtleistung auf ein breites Spektrum auffächert, verursacht es weniger Störungen bei anderen Anwendungen, die im selben Frequenzbereich arbeiten. Fü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 Nachteile besitzt, und dass je nach Anwendung entschieden werden muss, welches Verfahren besser geeignet ist Java Java ist eine von Sun Microsystems entwickelte Technologie zur platformunabhängigen Erstellung von Programmen. Sie besteht aus einer Programmiersprache, die ebenfalls den Namen Java trägt, einem Compiler (javac) sowie der Java-Laufzeitumgebung (Java-Runtime-Environment - JRE). Die Java-Laufzeitumgebung besteht aus einer virtuellen Maschine, die die kompilierten Programme ausführt. Dies bietet den Vorteil, dass bei einem Wechsel der Host-Plattform (also z.b. von Windows auf Linux oder MacOS) bestehende Programme nicht neu übersetzt werden müssen. [Ulle09] 10

43 2.3. Python Programmiersprache Java ist eine statisch typisierte, objektorientierte Programmiersprache. Aufgrund der von C entlehnten Syntax erinnert Java auf den ersten Blick an C++. Bei genauerer Betrachtung unterscheiden sich diese beiden Sprachen jedoch stark. So bietet Java im Gegensatz zu C++ keine Mehrfachvererbung, sondern verwendet sogenannte Interfaces. Java wird mit einer großen Standardbibliothek ausgeliefert, die für sehr viele Standardaufgaben (z.b. Threadverwaltung, Netzwerkkommunikation, GUI -Entwicklung 2 oder typische Datenstrukturen wie Listen und Hashmaps) bereits eine passende Lösung mitbringt. Durch den integrierten Paketmechanismus wird darüber hinaus die übersichtliche Gliederung des Quelltextes in Unterdateien ermöglicht. Aufgrund der statischen Typisierung und der genau definierten Laufzeitumgebung eignet sich Java besonders gut zur Erstellung von zuverlässigen und fehlerarmen Programmen. Werden konsequent Interfaces verwendet und typunsichere Downcasts vermieden, so können die meisten Fehler bereits durch den Compiler erkannt und abgefangen werden. Kann ein solches Programm ohne Fehler und Warnungen kompiliert 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 Schnittstellen (Interfaces) besonders wichtig, da nur so eine korrekte Funktionalität nach dem Zusammensetzen der einzelnen Teile gewährleistet werden kann. Diese Vorgehensweise nennt man auch Design by Contract. Java bietet eine Reihe von Sprachkonstrukte, um Design by Contract zu unterstü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 gehört. Darüber hinaus sind auch fertige Pakete für Windows verfügbar. Python eignet sich daher besonders zum Schreiben von kleinen bis mittelgroßen Skripten 4. [Foun10] 2 GUI: Graphical User Interface, dt. graphische Benutzerschnittstelle. 3 Programmiersprache, bei der Programme nicht kompiliert, d.h. in Maschinencode übersetzt, sondern interpretiert werden. 4 Programme, die nicht kompiliert sondern interpretiert werden. 11

44 2. Grundlagen In dieser Diplomarbeit wird Python für die Interaktion mit dem Betriebssystem eingesetzt, wenn diese Aufgaben in Java entweder gar nicht oder nur sehr schwierig zu lösen wären. Beispiele hierfür sind die automatische Erkennung von USB-Geräten oder der Zugriff auf den seriellen Port. Da Python eine sehr kompakte und verständliche Implementierung von Programmcode zulässt, wurde in dieser Diplomarbeit weitestgehend auf Beispiele in Pseudocode verzichtet, und statt dessen lauffähige Python-Programme zu verwenden. Dies ist nicht nur eindeutiger, sondern bietet gleichzeitig den Vorteil, dass die meisten Programmbeispiele direkt in lauffähige Programme übernommen werden können Corba Corba (Common Object Request Broker Architecture) ist eine objektorientierte Middleware zur Verteilung von Objekten auf verschiedenen Rechnern innerhalb eines Netzwerkes. Das besondere hierbei ist, dass Corba nicht an eine bestimmte Programmiersprache gebunden ist. Die einzelnen Objekte bzw. Komponenten können hierbei in jeder beliebigen Programmiersprache implementiert werden, die eine Corba-Anbindung besitzt. [TavS07] Im Rahmen dieser Diplomarbeit ist diese Programmiersprachenunabhängigkeit sehr wichtig, da bestimmte Teile (z.b. die Graphische Oberfläche für Mobiltelefone oder die Ansteuerung des USB-Sticks) nicht in Java realisiert werden können, und statt dessen auf C++ sowie Python ausgewichen werden muss. 12

45 3. Stand der Technik 3.1. Einleitung In diesem Kapitel wird der Stand der Technik von kabellosen Patientenüberwachungstechnologien untersucht. Hierzu wird zunächst in Abschnitt 3.2 allgemein eine Reihe von potentiell geeigneten Übertragungsprotokollen vorgestellt und jeweils kurz diskutiert, ob und wie gut diese als Basistechnologie für die Lösung der Problemstellung dieser Diplomarbeit geeignet sind. Im darauf folgenden Abschnitt 3.3 wird dann die aktuelle Marktsituation fertiger Produkte, die zur Überwachung von Patienten in einem MANV -Szenario in Frage kommen, vorgestellt und die Eignung dieser Produkte diskutiert. Den Abschluss dieses Kapitels bildet Abschnitt 3.4, in dem kurz auf ähnliche Projekte eingegangen wird, die momentan an anderer Stelle in Arbeit sind Kabellose Übertragungsprotokolle In diesem Abschnitt werden die gängigsten Funkprotokolle kurz vorgestellt. Insbesondere wird erläutert, inwieweit das entsprechende Protokoll als Grundlage für das zu entwickelnde Sensornetz geeignet ist. Kommt diese Untersuchung zu einem positiven Ergebnis, wird eine genauere Betrachtung der Störsicherheit vorgenommen. Hierbei wird insbesondere auf die Störungen durch WLAN - und Bluetooth-Geräte eingegangen, da diese Technologien mittlerweile eine weite Verbreitung in Mobiltelefonen gefunden haben, und somit eine Störung durch die Mobiltelefone der Unfallopfer und Helfer

46 3. Stand der Technik zu erwarten ist. Außerdem ist geplant, ein WLAN -Netzwerk für die Koordination des Überwachungssystems einzusetzen, so dass auch hier auf gegenseitige Störungen geachtet werden muss. Mit Ausnahme von DECT und GSM bzw. UMTS ist diesen Protokollen gemein, dass sie Frequenzen aus dem ISM -Band 1 verwenden DECT Bei DECT ( Digital Enhanced Cordless Telecommunications ) handelt es sich um einen Standard, der vor allem zur Anbindung von Schnurlostelefonen an eine Basisstation gedacht ist 2. In Europa wird ein eigenes Frequenzband im Bereich von 1800 bis 1900 MHz verwendet, in dem 10 Kanäle zur Verfügung stehen. Pro Kanal können maximal 32 kbit Nutzdaten pro Sekunde übertragen werden. Die maximal zulässige Sendeleistung beträgt 250 mw, womit eine Reichweite von ca m in Gebäuden und ca. 300 m im Freien realisiert werden kann. Jede Basisstation kann bis zu 6 Geräte anbinden. Beim Einsatz außerhalb Europas muss bedacht werden, dass die Verwendung der Frequenzen von 1800 bis 1900 MHz hier evtl. nicht zulässig ist. In diesem Fall muss auf das ISM -Band ausgewichen werden, welches mit anderen Anwendungen geteilt werden muss. [ETSI06] DECT bietet eine optionale Verschlü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 Einschränkung auf 6 Teilnehmer ist DECT für den Einsatz als Sensornetz-Protokoll nicht geeignet GSM/UMTS GSM sowie der Nachfolgestandard UMTS bilden die Grundlage der aktuellen Mobilfunktechnologie. Es handelt sich um eine zellenbasierte Technologie, die im Falle von GSM Frequenzen im 900 MHz- und im 1,8 GHz-Band verwendet. Für UMTS stehen 1 Mehrere Frequenzbänder, für deren Benutzung eine allgemeine Betriebserlaubnis ausreicht. 2 Es gibt jedoch auch weitere Anwendungen wie z.b. Babyfon. 14

47 3.2. Kabellose Übertragungsprotokolle insgesamt 19 Bänder im Bereich von 777 MHz bis 2,2 GHz zur Verfügung. Die Kommunikation 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) beträgt. Mit GSM -900 können im Freien bei Sichtkontakt Reichweiten bis zu 35 km erreicht werden. [Benk07] Die Frequenzen für GSM und UMTS sind fest dem jeweiligen Netzbetreiber zugeordnet. Der Preis fü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] WLAN WLAN oder Wi-Fi bezeichnet den heute gängigen Standard eines Funkprotokolls zum Aufbau von kabellosen lokalen Netzwerken. Es gibt mehrere Versionen des Standards, die verbreitetsten sind IEEE a, IEEE b/g und IEEE n. [IEEE07] Es sind zwei Betriebsmodi möglich: Infrastruktur-Modus: Eine zentrale Station ( Access-Point ) dient als Basisstation für alle weitere Stationen. Jede Station, die am Netzwerk teilnimmt, muss hierzu die Signale des Access-Points empfangen kö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 können. Wenn dies nicht der Fall ist, muss weitere Aufwand betrieben werden, um Kollisionen im Netzwerk zu vermeiden (vgl. RTS/CTS in Abschnitt ). Der Infrastruktur-Modus bietet gegenüber dem Ad-Hoc-Modus klare Vorteile: Im Gegensatz zum Ad-hoc-Modus ist es nicht notwendig, dass alle Stationen sich gegenseitig empfangen mü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 Datenübertragungsraten unterstützt. Standardmäßig wird immer die größtmögliche Übertragungsrate gewählt, die störungsfrei verwendet werden 15

48 3. Stand der Technik kann. Je weiter sich die Stationen voneinander entfernen, desto geringer wird die Übertragungsrate, bis schließlich die niedrigste mögliche Übertragungsrate von 1 MBit/sec erreicht ist. Es gibt eine ganze Reihe von Unterstandards, die sich durch zulässige Frequenzen, Übertragungsraten und Sendeleistung unterscheiden. Teilweise ist auch Kanalbündelung vorgesehen. Nicht jeder Standard kann in jedem Land eingesetzt werden, und die meisten Endgeräte unterstützen nur eine Teilmenge dieser Standards. Hier sollen nur die wichtigsten drei Standards erwähnt werden IEEE b Bei IEEE b handelt es sich um den ältesten WLAN -Standard mit praktischer Bedeutung, der bereits 1999 spezifiziert wurde. Dieser Standard wird praktisch von jedem WLAN -fähigen Endgerät unterstützt. Die Kommunikation findet im ISM -Band im Bereich von 2.4 GHz statt. Je nach Land sind Kanäle möglich, die sich jedoch teilweise überlappen. Dies führt dazu, dass maximal 3 Netzwerke in einem Gebiet ohne Störungen gleichzeitig betrieben werden können. Die maximale Sendeleistung beträgt 100 mw. Es sind Übertragungsraten von 5,5 bis 11 MBit/sec (brutto) möglich. Die Nettoübertragungsrate beträgt ca. 50% der Bruttorate; die restliche Übertragungsrate wird für die Koordination des Datenverkehrs benötigt. Es sind Reichweiten bis 40 m (Innen) bzw. 100 m (Im Freien) möglich[kudmk08] IEEE g Der IEEE g-Standard stellt eine Erweiterung des IEEE b-Standards dar. Wesentliche Neuerung ist eine Erhöhung der Bruttodatenrate von 11 auf 54 MBit/sec, von denen netto ca. 40% zur Verfügung stehen. Erwähnenswert ist, dass die beiden Standards interoperabel sind, d.h. ein IEEE b-Gerät kann einem IEEE g Netzwerk beitreten und umgekehrt. Dies ist auch der Grund, weshalb dieser Standard momentan am weitesten verbreitet ist IEEE a Der IEEE a Standard verwendet Frequenzen im 5-GHz-Bereich. Er ist daher inkompatibel zum IEEE b/g Standard. Je nach Frequenzband sind Sendeleistungen zwischen 30 mw und 1000 mw zulässig. Mit dem passenden Frequenzband 16

49 3.2. Kabellose Übertragungsprotokolle sind daher höhere Reichweiten als mit dem IEEE b/g-Standard möglich. Die Bruttodatenrate beträgt bis zu 54 MBit/sec. Ein Vorteil des IEEE a-Standards ist die Kommunikation im 5 GHz Bereich. Aktuell ist dieser Bereich noch wenig genutzt, so dass dort oft ein Betrieb mit weniger Störungen als im 2,4 GHz-Bereich möglich ist. Es ist jedoch zu erwarten, dass sich dies in Zukunft ändern wird Störsicherheit IEEE verwendet den CSMA/CA 3 -Algorithmus zur Kontrolle des Medienzugriffs. Möchte eine Station senden, so muss diese zunächst für einige Zeit lauschen, ob der zu verwendende Kanal auch wirklich frei ist (Energy-Detection). Ist der Kanal belegt, so wartet sie eine zufällige Zeit, bis sie erneut versucht, auf den Kanal zuzugreifen. Wichtig hierbei ist, dass es bei Funkprotokollen nicht möglich ist, eine Kollision zu erkennen 4.um eine bestehende Übertragung abzubrechen, wie es z.b. bei Ethernet der Fall ist. Zur Vermeidung von Kollisionen kann bei IEEE daher zusätzlich zu CSMA/CA eine koordinierte Sendefreigabe eingesetzt werden. Hier kommt RTS/CTS zum Einsatz: Möchte eine Station ein großes Datenpaket senden, so sendet diese zuerst ein RTS-Paket 5 an den Empfänger, welcher dies mit einem CTS-Paket 6 quittiert. Erst wenn das CTS-Paket empfangen wurde, wird mit der Übertragung des eigentlichen Datenpakets begonnen. Für alle andere Stationen im Netzwerk ist nun klar, dass sie bis zur abgeschlossenen Übertragung dieses Paketes nicht auf das Netzwerk zugreifen dürfen. Bei dem Einsatz der in IEEE i definierten Verschlüsselungsverfahren (WEP 7, WPA oder WPA2 ) werden lediglich die Nutzdaten des Paketes verschlüsselt. Die RTS/CTS-Pakete können weiterhin erkannt werden, so dass die Kollisionsvermeidung auch dann funktioniert, wenn die Pakete nicht entschlüsselt werden können (Diese Si- 3 Carrier Sense Multiple Access with Collision Avoidance. dt.: Gemeinsamer Medienzugriff mit Kollisionsvermeidung. 4 Dies liegt an der Tatsache, dass für Senden und Empfangen der selbe Transceiver verwendet wird. Daher kann ein Knoten entweder nur Senden oder nur Empfangen. Für das Feststellen einer Kollision müsste er jedoch beide Operationen gleichzeitig durchführen können. 5 Ready to send 6 Clear to send 7 Die Sicherheit von WEP ist bereits seit einigen Jahren kompromittiert. Es sollte nicht mehr verwendet werden. 17

50 3. Stand der Technik tuation ist z.b. in Mietshäusern oft anzutreffen, wo mehrere unterschiedliche WLAN s auf dem selben Kanal senden). Jedoch geht dies mit einer reduzierten Übertragungsrate für die einzelnen Netzwerke einher. Zusätzlich wird das in Abschnitt beschriebene DSSS-Verfahren eingesetzt, um schmallbandige Störungen auszufiltern. Ein häufiges Problem ist die Störung durch Bluetooth, da Bluetooth und WLAN -Geräte oft aufeinandertreffen (z.b. weil an einem Notebook Bluetooth-Maus und -Tastatur verwendet werden oder weil ein PDA z.b. Schnittstellen für beide Protokolle besitzt). Wie in Abschnitt genauer erläutert, besitzt Bluetooth 79 Kanäle, welche bis zu 1600 mal pro Sekunde gewechselt werden. Problematisch ist nun, dass 22 dieser Kanäle in das IEEE b/g-Frequenzspektrum fallen. Durch den häufigen Kanalwechsel, die geringeren Übertragungsraten sowie die Möglichkeit, den Wechsel auf belegte Kanäle zu vermeiden, ist diese Störung für Bluetooth deutlich unproblematischer als für WLAN. Je nach Implementierung kann dies zu einer deutlichen Reduktion der Übertragungsrate des WLANs führen; außerdem kann die Wartezeit für das erfolgreiche Senden von Paketen deutlich ansteigen. Dies hat die IEEE dazu veranlasst, eine eigene Arbeitsgruppe zu gründen, die sich mit dem Problem der gegenseitigen Störung von WLAN und Bluetooth beschäftigt. Die Ergebnisse dieser Arbeitsgruppe spiegeln sich im Standard IEEE wider Leistungsaufnahme Der Energiebedarf für WLAN ist relativ hoch. Beispielsweise benötigt der vom Hersteller Broadcom als besonders energiesparend bezeichnete Chip BCM4326 bis zu 100 ma zum Empfangen und zwischen 141 und 190 ma zum Senden. [BROA06] WPAN: Wireless Personal Area Networks Als WPANs ( Wireless Personal Area Networks ) werden kabellose Kleinnetzwerke bezeichnet, die dazu dienen, wenige Geräte über kurze Entfernungen (mehrere Meter) miteinander zu verbinden. Sie dienen als Ersatz von Kabelverbindungen zur Anbindung von Peripherie an Computergeräte (z.b. zur Verbindung von Headsets mit Mobiltelefonen oder von Tastatur und Maus mit einem PC ). 18

51 3.2. Kabellose Übertragungsprotokolle IEEE Der IEEE Standard behandelt Wireless Personal Area Networks. Er ist in mehrere Unterstandards aufgeteilt: IEEE : Bluetooth 1.2 IEEE : Interoperabilität zwischen IEEE (WPAN ) und IEEE (WLAN ) IEEE : WPANs mit hohen Datenübertragungsraten (20 MBit/sec und höher) IEEE : WPANs mit niedriger Datenübertragungsraten Für diese Arbeit sind vor allem der Bluetooth- und der ZigBee-Standard interessant IEEE : Bluetooth Bluetooth wurde ursprünglich durch den Mobilfunkhersteller Ericcson als Ersatz für RS-232 -Verbindungen entwickelt. Die Entwicklung des Bluetooth-Standards erfolgt heute unter der Regie der Bluetooth Special Interest Group (Bluetooth SIG). Version 1.1 des Bluetooth-Standard wurde von der IEEE als IEEE übernommen. Nach Veröffentlichen einer weiteren Version IEEE , die dem Bluetooth-1.2 -Standard entspricht, wurde von der IEEE jedoch beschlossen, nicht weiter mit der Bluetooth SIG zu kooperiern, so dass es keine weiteren Versionen des IEEE Standards geben wird. Aktuell ist Version 4.0 des Bluetooth-Standards, wobei jedoch die meisten Geräte nur ältere Standards (typischerweise 2.0 oder 2.1) unterstützen. [SIG10] Die wichtigsten Meilensteine der Bluetooth-Entwicklung können folgendermaßen zusammengefasst werden: Bluetooth 1.1 : Erste Version von praktischer Relevanz. Entspricht IEEE Bluetooth 1.2 : Entspricht IEEE Bringt einige Verbesserungen gegenüber der Version 1.1 wie z.b. schnelleres Finden von Endgeräten (Discovery), 19

52 3. Stand der Technik höhere Störsicherheit durch die Verwendung von AFH 8, Übertragungsraten bis 721 kbit/sec. Bluetooth 2.0 : Einfü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 ) durch Einführung von SSP 10, Verbesserung der Sicherheit durch explizite Aushandlung der Verschlüsselung. Bluetooth 3.0 : Einführung eines Hochgeschwindigkeits-Datenkanals auf Basis von IEEE (vgl ) mit bis zu 24 MBit/sec., verbessertes Powermanagement, Einführung von verbindungslosen Datentelegrammen (Unicasts). Bluetooth 4.0 : Einführung des Blueetooth Low Energy Standards (vgl ) Pairing Bei der Entwicklung von Bluetooth wurde ein besonderes Augenmerk auf Datensicherheit gelegt. Dies liegt daran, dass über Bluetooth in vielen Fällen auf sensible Daten (z.b. der Inhalt von Mobiltelefonen, Telefongespräche die über Headsets geführt werden etc.) zugegriffen werden kann. Bluetooth verwendet hierfür das Konzept des Pairings, also der Paarung. Bevor zwei Bluetooth-Geräte miteinander kommunizieren können, müssen sie gepaart werden. Um dies durchzuführen, muss zunächst die Identität der zu paarenden Geräte bestätigt werden. Hierzu gibt es zwei verschiedene Verfahren: Legacy: Bis Bluetooth 2.0 muss an beiden Geräten eine identische PIN eingegeben 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 Geräten. z.b. kann bei dem Just-Works-Verfahren die PIN komplett ausgelassen werden 11 oder es wird an beiden Geräten eine Nummer angezeigt, deren Gleichheit einfach nur noch bestätigt werden muss. 8 Adaptive frequency hopping spread spectrum 9 Enhanced Data Rate 10 Secure Simple Pairing 11 Die Verbindung erfolgt trotzdem verschlüsselt, allerdings sind nun Man-in-the-middle-Angriffe möglich. 20

53 3.2. Kabellose Übertragungsprotokolle Ist diese Überprüfung erfolgreich, generieren beide Geräte einen kryptographischen Schlüssel und die weitere Kommunikation erfolgt verschlüsselt. Sobald zwei Geräte gepaart wurden, können sie miteinander kommunizieren, ohne eine erneute Paarung durchführen zu müssen. [SIG10] Reichweite Bluetooth definiert drei verschiedene Klassen von Gerä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 überbrücken muss, reicht hier die Verwendung eines Klasse-2-Gerätes. Durch die Einschränkung der Sendeleistung wird nicht nur die Akkulaufzeit der Geräte erhöht, sondern auch die Wahrscheinlichkeit, dass ein Angreifer die gesendeten Daten empfangen kann, verringert. Es bleibt allerdings festzustellen, dass mit Hilfe von geeigneten Antennen die Reichweite von Bluetooth signifikant gesteigert werden kann. So lassen sich mit Hilfe der BlueSniper-Richtantenne selbst mit Klasse-2-Geräten Distanzen von über 800 m überbrücken. [Cheu05] Übertragungsrate Die Übertragungsrate von Bluetooth hängt natürlich von Faktoren wie der Verbindungsqualität und der Entfernung ab. Der Standard definiert folgende maximale Datenübertragungsraten: Bluetooth 1.1 : 721 kbit/sec Bluetooth 2.0 : 3.0 MBit/sec Bluetooth 3.0 : 24 Mbit/sec (über einen IEEE Kanal) 21

54 3. Stand der Technik Störsicherheit Bluetooth verwendet einen Frequenzbereich von 2,402-2,480 GHz. Innerhalb dieses Bereiches werden 79 verschiedene Kanäle definiert. Zur Minimierung von Stö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 verbesserte AFH 12 -Verfahren eingeführt, welches gestörte Kanäle erkennt und deren Verwendung vermeidet. Insbesondere WLAN -Netzwerke und Bluetooth-Netzwerke stören sich gegenseitig. Wie in Abschnitt bereits erläutert, wird WLAN deutlich stärker durch Bluetooth gestört, als dies umgekehrt der Fall ist. Tritt eine Störung auf einem Kanal auf, versucht das AFH -Verfahren die Verwendung dieses Kanals zu vermeiden. Hierdurch sinkt zwar die erreichbare Datenübertragungsrate, eine Kommunikation kann allerdings weiter stattfinden. Es ist festzustellen, dass Bluetooth insbesondere im Vergleich zu WLAN recht robust gegenüber Störungen ist Anzahl Teilnehmer Sobald zwei oder mehr Geräte miteinader verbunden sind, formen diese ein sogenanntes Piconet. In einem Piconet können sich bis zu 255 Geräte befinden, wobei ein Gerä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 dürfen. Pro Piconet kann es nur einen Master geben. Slaves: Slaves bekommen vom Master die Erlaubnis, Daten zu senden. Es können immer nur 7 Slaves gleichzeitig aktiv sein. Aktive Slaves müssen permanent empfangsbereit sein, um die Anforderungen des Masters zu empfangen. Da nur 7 Slaves gleichzeitig aktiv sein dürfen, befinden sich alle übrigen Slaves im sogenannten Parkzustand. Erst wenn ein Slave vom Master explizit dazu aufgefordert 12 Adaptive frequency-hopping spread spectrum 22

55 3.2. Kabellose Übertragungsprotokolle wird, darf er in den aktiven Zustand wechseln. Um die Anzahl der aktiven Geräte in einem Netzwerk zu erhöhen, gibt es die Möglichkeit, ein sogenanntes Scatternet zu bilden. Hierbei handelt es sich um die Verbindung von mehreren Piconets mit jeweils maximal 8 Geräten zu einem größeren Verbund. Hierbei leitet jeweils ein Gerät, das mit jeweils 2 der Piconetze verbunden ist, Pakete vom einen Netz in das andere Netz über. Im Vergeleich zu Piconetzen kann hiermit eine deutlich höhere Anzahl von Geräten unterstützt werden. Durch die Verkettung der Netze kann es jedoch vorkommen, dass einzelne Pakete eine relativ hohe Anzahl von Piconetzen durchqueren müssen, um ihr Ziel zu erreichen Leistungsaufnahme Die genaue Leistungsaufnahme eines Bluetooth-Gerätes hängt von einigen Faktoren ab. Den größten Einfluß hat die Rolle des Gerätes: Die Leistungsaufnahme eines Slaves ist deutlich hö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 beträgt laut [NeBD06] durchschnittlich 56,63 mw, was bei 3,3 V ca 16,6 ma entspricht. Für Klasse- 1-Geräte ist die Leistungsaufnahme noch höher, da alleine die Sendeleistung schon 100 mw beträ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 für ein bestimmtes Zeitintervall nicht erreichbar ist. Befindet sich ein Gerät im Standby-Modus, kann es bis zu 3 Sekunden dauern, bis es wieder sendebereit ist. Da diese Einschränkungen den Betrieb von Geräten mit geringer Energieversorgung praktisch unmöglich machen, wurde von der Bluetooth-SIG ein eigener Standard für diese Geräteklasse mit dem Namen Bluetooth Low Energy verabschiedet (siehe Abschnitt ) IEEE : ZigBee Bei IEEE handelt es sich um einen Standard für zuverlässige, drahtlose Kommunikation mit niedriger Übertragungsrate bei hoher Reichweite, niedriger Leistungsaufnahme und geringem Stückpreis. 23

56 3. Stand der Technik APL (Anwendung) SEC (Security) NWK (Vermittlung) MAC (Sicherung) PHY (Bitübertragung) IEEE ZigBee Abbildung 3.1.: ZigBee-Stack (Quelle: Wikipedia) Eine typische Anwendung hierfür sind drahtlose Sensoren: Zum einen ist eine möglichst hohe Laufzeit gewünscht, da es oft nur schwer möglich ist, Batterien für aufgestellte Sensoren auszutauschen. Wenn die Sensoren dazu noch in einer hohen Stückzahl verteilt werden sollen, sind möglichst geringe Hardwarekosten notwendig. Zu beachten ist, dass ZigBee nicht das selbe ist wie IEEE IEEE 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 um 3 weiter Schichten, namentlich Vermittlungs-, Verschlüsslungs und Anwendungsschicht ergänzt. [Alli07] Es ist möglich, einen IEEE Transceiver ohne den Einsatz von ZigBee zu betreiben. Die Verwendung von ZigBee bietet jedoch den Vorteil, dass alle netzwerkrelevanten Aufgaben wie Routing, Übertragungssicherung und Adressierung von Anwendungen bereits durch den ZigBee-Stack erfolgen und daher nicht vom Entwickler implementiert werden müssen. Die Verwendung von durch die ZigBee-Alliance zer- 24

57 3.2. Kabellose Übertragungsprotokolle tifizierten Modulen bietet zudem den Vorteil der Interoperabilität mit Modulen von anderen Herstellen, sofern diese ZigBee-zertifiziert sind Netzstruktur Bei ZigBee gibt es zwei Klassen von Geräten: FFD: Full Function Devices: Diese Geräte implementieren den vollen ZigBee- Stack. Hierzu ist es notwendig, dass diese immer erreichbar sind; die Verwendung des Energiesparmodus ist nicht möglich. RFD: Reduced Function Devices: Diese Geräte implementieren nur einen Teil des ZigBee-Stacks. Sie müssen nicht immer ereichbar sein und können den Energiesparmodus benutzen. Es ist lediglich die Kommunikation zwischen RFD und FFD sowie zwischen zwei FFDs möglich. Zwei RFDs sind nicht in der Lage, direkt miteinander zu kommunizieren, sondern müssen den Umweg über ein FFD nehmen. Neben den Geräteklassen unterscheiden sich die einzelnen Stationen durch die Rollen, 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 für die Kontrolle des Netzwerks zuständig. In einem Netzwerk kann es immer nur einen Koordinator geben. Der Koordinator beinhaltet immer auch die Funktionalität eines Routers. Die Rolle des Koordinators kann nur von einem FFD übernommen werden. Router (ZR): Router sind in einem Netzwerk für die Weiterleitung von Paketen zuständig. Es kann beliebig viele Router in einem Netzwerk geben. Die Rolle eines Routers kann nur von einem FFD übernommen werden. Endknoten (ZED): Alle Gerä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. Können sich mehrere Router empfangen, so bilden diese automatisch ein vollvermaschtes Netz. 25

58 3. Stand der Technik ZigBee-Kanal WLAN-Kanal Bluetooth-Frequenz ,420 GHz ,439 GHz ,471 GHz Tabelle 3.1.: Überschneidungen zwischen ZigBee, WLAN und Bluetooth-Kanälen Bei der Zustellung von Paketen wird standardmäßig immer der Pfad mit der besten Leitungsqualität gewählt. Durch die geschickte Platzierung von Routern kann ein ZigBee-Netzwerk nahezu beliebig 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 übernehmen, jedoch geschieht dies nicht automatisch und muss in der Anwendungslogik erfolgen Störsicherheit ZigBee verwendet zur Funkübertragung von Paketen den IEEE Standard. Dieser weist große Ähnlichkeiten mit dem IEEE b-Standard (WLAN, vgl. Ab- 26

59 3.2. Kabellose Übertragungsprotokolle schnitt ) auf: Es werden mehrere Kanäle im 2.4-GHz-Band spezifiziert. In Nordamerika stehen 10 weitere Kanäle im 900-MHz-Band zur Verfügung, die allerdings eine reduzierte Datenrate von 40 kbit/sec zulassen. Darüber hinaus gibt es noch einen Kanal im 868-MHz-Band, der allerdings nur in Europa verwendet werden darf, und bei dem auch nur 20 kbit/sec verwendet werden können. Zur Übertragung wird auch bei IEEE Frequenzspreizung nach dem DSSS-Verfahren betrieben. Zum Medienzugriff wird CSMA/CA verwendet. Zusätzlich spezifiziert ZigBee in der Vermittlungsschicht (NWK ) eine Reihe von Fehlerbehandlungsroutinen: So wird jedes empfangene Paket mit der Ausnahme von Broadcasts 13 mit einer Antwort an den Sender quittiert. Erhält der Sender innerhalb einer bestimmten Zeitspanne keine Antwort, so sendet er das verlorene Paket erneut. Darüber hinaus gibt es in jedem Datenpaket eine CRC -Prüfsumme, mit deren Hilfe Übertragungsfehler erkannt werden können. Auch in diesem Fall wird das Paket erneut übertragen. Hierbei sollte jedoch bemerkt werden, dass ein CRC -Verfahren keinen Schutz gegen absichtliche Manipulation bietet. Dies kann mit Hilfe der in Abschnitt beschriebenen kryptographischen Verfahren verhindert werden. Ein ZigBee-Netzwerk kann optional ein sogenanntes Beacon (dt. Leuchtfeuer) verwenden. 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 möglich, einzelnen Stationen einen garantierten Zeitschlitz (GTS) zuzuweisen, in dem niemand anderes senden darf. Dies ist insbesondere für Echtzeitanwendungen interessant. Da zum Zeitpunkt des Versendens des Beacons jedoch alle Stationen empfangsbereit sein müssen, ergeben sich Einschränkungen für die Batterielaufzeit. Die Verwendung von Beacons schützt nicht gegen Störungen durch Nicht-ZigBee-Geräte wie WLANs oder Bluetooth. Da eine Nutzung der Kanäle außerhalb des 2,4-GHz-Bandes nicht in jedem Land gestattet ist, sollen im folgenden nur die 15 Kanäle im 2,4-GHz-Band betrachtet werden: Von den 15 zur Verfügung stehenden ZigBee-Kanälen überschneiden sich 11 Kanä- 13 Rundrufe, also Pakete, die an alle Stationen gleichzeitig verschickt werden. 27

60 3. Stand der Technik le mit den 3 überschneidungsfreien IEEE b-Kanälen (Kanal 1, Kanal 6 und Kanal 11) in Nordamerika. In Europa überschneiden sich sogar 13 ZigBee-Kanäle mit den IEEE b-Kanälen Kanal 1, Kanal 7 und Kanal 13 in Europa. Es ist zu erwarten, dass die Störungen auf den Kanälen im Randbereich der IEEE b-Kanäle am geringsten wenn auch nicht komplett ausgeschlossen sind. Außerdem gibt es auf 4 Kanälen Ü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 Störungen auf einem Kanal zu groß werden. Hierzu wird im EEPROM des ZigBee-Gerätes kein fester Kanal, sondern eine Liste aller erlaubten Kanä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 Kanälen gleichzeitig auftreten. Hierdurch kann es zu einer signifikaten Abnahme der im ZigBee-Netzwerk möglichen Übertragungsrate kommen. Eine mögliche Lösung wäre in diesem Falle, die WLANs auf die WLAN -Kanäle 1, 7 und 13 einzuschränken, so dass für das ZigBee- Netzwerk die ZigBee-Kanäle 15 und 21 zur ungestörten Verwendung zur Verfügung stehen. Alternativ können an Stelle der WLAN -Kanäle 7 und 13 die WLAN -Kanäle 6 und 11 verwendet werden, so dass für das ZigBee-Netzwerk die Kanäle 25 und 26 frei werden. Wenn für das ZigBee-Netzwerk sowieso nur ein Teil der zur Verfügung stehenden Übertragungsrate benutzt wird und auch die WLANs nur teilweise ausgelastet sind, ist zu erwarten, dass durch die Verwendung des CSMA/CA-Verfahrens genügend freie Zeitschlitze gefunden werden können, um selbst bei einer hohen WLAN -Dichte noch erfolgreich senden zu können. Die Störungen durch Bluetooth sind als weniger problematisch zu bewerten. Durch das von Bluetooth verwendeten FHSS-Verfahren besteht selbst im ungünstigsten Fall (Verwendung von sich überschneidenden Kanälen im ZigBee-Netz, volle Ausschöpfung der Übertragungsrate im ZigBee-Netz) nur eine maximale Kollisionswahrscheinlichkeit von ca. 4% (3 von 79 Frequenzsprü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 Übertragung des kollidierten Paketes ein- 28

61 3.2. Kabellose Übertragungsprotokolle fach behandelt werden. Verwendet das Bluetooth-Netzwerk darüber hinaus das AFH - Verfahren, ist es in der Lage die Störung zu erkennen und den betroffenen Kanal im weiteren Verlauf zu meiden. Eine weitere Quelle von Störungen sind Mikrowellenöfen. Diese verwenden typischerweise Frequenzen um die 2540 MHz und können Störungen mit einer Bandbreite von bis zu 80 MHz und einer Signalstärke von bis zu 30 dbm verursachen. Hierdurch ergeben sich mögliche Störungen auf den oberen ZigBee-Kanälen. Da gewöhnliche Mikrowellenöfen für den Haushaltsgebrauch einen Auslastungsgrad (Duty-Cycle) von bis zu 50% haben, ergäbe sich schlimmstenfalls eine Halbierung der zur Verfügung stehenden Übertragungsrate.[Fara08] Die letzte zu erwartende Quelle von Stö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 Störungen mit einer Signalstärke von bis zu 30 dbm zu erwarten. Diese können einfach durch den automatischen Kanalwechsel des ZigBee-Netzwerks umgangen werden Verschlüsselung ZigBee unterstützt 128-Bit-AES-Verschlüsselung. Hiermit können gesendete Nachrichten gegen Manipulation sowie unberechtigte Kenntnisnahme geschützt werden. Aufgrund von Entwurfsfehlern im Standard ist dieser Schutz jedoch nur als rudimentä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 können. Es ist daher sinnvoll, auf höherer Protokollebene weitere Schutzmaßnahmen vorzusehen, um sich erfolgreich gegen Angriffe zu schützen Leistungsaufnahme Zur Bewertung der Leistungsaufnahme eines ZigBee-Netzwerks wird exemplarisch ein ZigBee-Modul vom Typ ATZB-24-A2R der Firma Atmel betrachtet. Diese Modul verfügt über einen Energiesparmodus. In diesem Modus wird lediglich der interne Speicher 29

62 3. Stand der Technik mit Energie versorgt, alle weitere Hardware wird abgeschaltet. In diesem Modus hat das Gerät (laut Hersteller) einen Strombedarf von weniger als 6 µa. Befindet sich das Gerät nicht im Energiesparmodus und ist empfangsbereit, werden 19 ma benötigt; sendet das Gerät sind 18 ma 14 notwendig. Durch den Energiesparmodus lassen sich große Einsparungen erreichen. Allerdings kann dieser nur von RFDs verwendet werden, da FFDs immer empfangsbereit sein müssen. Zur Übertragung von Nachrichten wird in diesem Fall von den RFDs ein Polling-Verfahren verwendet: Der Elternknoten des FFDs (in den meisten Fällen also der nä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 Empfänger gerade im Energiesparmodus befindet Bluetooth Low Energy (ehemals Wibree) Bluetooth Low Energy ist ein neuer Standard für WPANs, der mit dem Bluetooth Standard eingeführt wurde. Er definiert eine Datenü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 frühen Testphase und waren auf dem Markt nicht erhältlich, so dass dieser Standard bei der Auswahl eines geeigneten Funkprotokolls nicht in die engere Betrachtung gezogen werden konnte. Beim späteren Entwurf des Sensornetzwerkes ist daher darauf Rücksicht zu nehmen, dass das Funkprotokoll nach Möglichkeit austauschbar gehalten wird, so dass es später möglich ist, die entworfene Lösung an geänderte Marktbedingungen anzupassen Weitere Protokolle Neben den oben erwähnten Protokollen gibt es viele weitere kabellose Übertragungsprotokolle wie beispielsweise der kommende Wireless-USB-Standard, WiMax, oder Mikrowellen-Richtfunk. Diese Protokolle sind jedoch für die Übertragung mit hohen Datenraten ausgelegt (was in der Regel mit einer dementsprechend hohen Leistungsaufnahme einhergeht), und liegen damit außerhalb des Fokus dieser Arbeit. Ebenfalls 14 Dass für das Senden weniger Energie benötigt wird als für das Empfangen mag auf den ersten Blick kontraintuitiv erscheinen, ist aber durch den Filteraufwand beim Empfangen zu erklären. 30

63 3.3. Produkte zur kabellosen Patientenüberwachung nicht berücksichtigt werden konnte der ANT+-Standard, der sich aktuell vor allem im Bereich von Wellnessgeräten wie z.b. Pulsuhren durchzusetzen scheint. Leider handelt es sich hierbei um eine proprietäre Lösung des Herstellers Dynastream; entsprechende Bauteile sind momentan auf dem deutschen Markt praktisch nicht erhältlich 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 Geräte pro Basisstation beschränkt ist. WLAN ist zwar grundsätzlich für eine solche Aufgabe geeignet, allerdings fällt der Strombedarf mit über 100 ma für den Einsatz im Erste-Hilfe-Sensor zu hoch aus. Von der Leistungsaufnahme prinzipiell möglich wäre der Einsatz von Bluetooth, wobei insbesondere der kommende Bluetooth Low Energy Standard interessant ist. Auch die hohe Störsicherheit wäre ein weiterer Punkt, der für Bluetooth spräche. Problematisch ist jedoch die Einschränkung, dass pro Bluetooth-Piconetz immer nur 7 Slaves aktiv sein können. Dies ist für die Anforderungen dieser Diplomarbeit deutlich zu wenig. Letztendlich erweist sich der ZigBee-Standard als am besten für die gewünschte Anwendung geeignet. Die erreichte Datenrate ist für die Übertragung einiger Messwerte und Alarme mehr als ausreichend. Auch die hohe Störsicherheit, die moderaten Stückkosten sowie die vergleichsweise hohe Reichweite sprechen für diese Lösung. Die beiden entscheidenden Kriterien sind jedoch die Fä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 realisieren. Das Routing wird komplett durch die Firmware der ZigBee-Module übernommen, so dass dieses nicht erst implementiert werden muss. Der Strombedarf der Module ist mit maximal 19 ma so gering, dass eine Versorgung über Batterien ohne weiteres möglich ist. Dieser Strombedarf lässt sich durch die Verwendung des Energiesparmodus weiter senken Produkte zur kabellosen Patientenüberwachung Auf dem Markt ist eine breite Palette an kabellosen Produkten zur Patientenüberwachung vorhanden. Dies davon setzen entweder Bluetooth oder proprietäre Protokolle 31

64 3. Stand der Technik wie Z-Wave zur Funkübertragung ein; ZigBee ist bisher in keinem Medizinprodukt auf dem Markt zu finden: Fast alle dieser Systeme sind im Gegensatz zu den Anforderungen dieser Arbeit dazu konzipiert, lediglich einen einzelnen Patienten zu überwachen. Die Funktechnologie dient hier vor allem dazu, die Anzahl der Kabel zwischen Patient und Monitoren zu reduzieren, um so die Mobilität des Patienten zu erhöhen. Die hohe Teilnehmerzahl von ZigBee bietet für die Überwachung eines einzelnen Patienten keine Vorteile, sondern bedeutet vielmehr einen zusätzlichen Aufwand, so dass Lösungen wie Bluetooth in diesem Fall deutlich praktikabler sind. Besonders häufig sind kabellose EKG-Geräte, Pulsoximeter oder invasive Blutdruckmessgeräte anzutreffen. Ein Beispiel für ein solches Produkt ist der CorBELT der Firma Corscience. Es handelt sich dabei um ein 1-Kanal EKG mit integriertem Beschleunigungssensor in Form eines Brustgurtes. Das System ist in der Lage, eine Vielzahl von Herzproblemen zu erkennen, und eignet sich daher besonders für Patienten mit bekannten Herzerkrankungen. Das System hat einen integrierten Beschleunigungssensor, um Bewegungsartefakte auszufiltern.[kg10] Von diversen Herstellern wie Dräger Medical, Philips, GE und WelchAllyn existiert eine Reihe Bluetooth-basierter Überwachungslösungen. Diese sind allerdings meist weniger als portables Gerät, als viel mehr als stationäre Überwachungslösung im Krankenhaus gedacht. Die Bluetooth-Technik dient hier vor allem dazu, möglichst wenige Kabel zum Patienten zu führen, was den Umgang (z.b. bei der Patientenwäsche oder beim Wenden) erheblich erleichtert. Keine dieser Technologien ist jedoch für den Einsatz in einem MANV -Szenario geeignet Verwandte Projekte zum Einsatz in MANV- Szenarien Neben dieser Arbeit beschäftigen sich mehrere verwandte Projekte ebenfalls mit der Problematik der effizienten Patientenversorgung während eines MANVs. Bei dem Projekt SOGRO MANV 500 (Sofortrettung bei Großschadenslagen mit einem Massenanfall von 500 Verletzten) beschäftigt, man sich insbesondere mit der effizienten Kennzeichnung und Lokalisierung von Patienten. Hierzu wird den Patienten ein 32

65 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 Überwachung ist bei diesem Projekt allerdings derzeit nicht vorgesehen.[sogr10] Eine weiteres Projekt, das sich mit der technischen Unterstützung von Rettungskräften bei einem MANV beschäftigt ist A.L.A.R.M. (Adaptive Lösungsplattform zur Aktiven technischen Unterstützung beim Retten von Menschenleben). Im Moment sind nur recht wenige Informationen zu diesem Projekt verfü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 Lösung geht.[alar10] Ein ähnlicher Ansatz wie in dieser Diplomarbeit wird in dem AID-N ( AID-N: The Advanced 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 basierte Lösung eingesetzt. Leider scheint dieses Projekt seit mehreren Jahren nicht weiter verfolgt zu werden; auf der Webseite sind seit 2007 keine Änderungen mehr vorgenommen worden. Auch wurde hier nicht auf Aspekte der industriellen Fertigung der einzelnen Knoten, d.h. insbesondere Kompaktheit und Kosteneffektivität eingegangen. Insgesamt handelt es sich um eine technisch sehr interessante Arbeit, die jedoch durch ihren anderen Fokus die Anforderungen dieser Diplomarbeit nicht erfüllen kann. 33

66

67 4. Analyse In diesem Kapitel wird eine Analyse der Problemstellung dieser Diplomarbeit vorgenommen. Hierzu werden zunächst die Anforderungen analysiert, die an ein kabelloses System zur Überwachung von Patienten gestellt werden. Danach werden die eingesetzten Hardwarebausteine, konkret der ADuC-Mikrocontroller sowie das ZigBee-Modul der Firma Atmel inklusive der dazugehörigen SerialNet-Firmware vorgestellt und untersucht. Hierbei werden häufig auftretende Probleme aufgezeigt und allgemeine Lösungen erarbeitet. Diese Lösungen werden in den späteren Kapitel als Grundlage für den Entwurf und die Implementierung der fertigen Lösung dienen Anforderungen an ein kabelloses System zur Überwachung von Patienten Nach Betrachtung des Standes der Technik ergeben sich folgende Anforderungen an das zu entwickelnde System: Kompatibilität: Die zu entwickelnde Lösung soll mit dem Erste-Hilfe-Sensor zusammenarbeiten. 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 müssen möglichst zeitnah zugestellt und angezeigt werden. Bei bestehen der Netzwerkverbindung sollen keine Nachrichten verloren gehen.

68 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 möglich sein, neue Befehle zu einem späteren Zeitpunkt hinzuzufügen. Skalierbarkeit: Das System soll sowohl in Anzahl der Sensoren als auch in der rä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 für die Erweiterung der Sensoren sollen möglichst gering sein. Niedriger Strombedarf: Der Strombedarf der einzelnen Sensoren muss so gering sein, dass der Betrieb über eine handliche Batterie über einen längeren Zeitraum möglich ist. Ideal wäre, wenn sich eine Laufzeit von mindestens 12 Stunden mit einer einzelnen Knopfzelle erreichen liesse. Stabilität: Das System soll möglichst unempfindlich gegenüber Störungen sein. Bei einfachen Störungen des Funkverkehrs sollen verlorene Pakete neu Übertragen werden. Schlägt diese Übertragung wiederholt fehl, soll eine Warnmeldung an der Überwachungsstation angezeigt werden. Es soll ebenfalls gewarnt werden, wenn ein Sensor die Netzwerkverbindung verloren hat oder aus anderen Gründen (z.b. leere Batterie) nicht mehr erreichbar ist. Erweiterbarkeit: Das System soll softwareseitig erweiterbar sein. Insbesondere soll es möglich sein, ohne Veränderungen an der Software Schnittstellen (z.b. in Form einer Weboberfläche) zu anderen Systemen hinzuzufügen. Anpassbarkeit: Das System soll an sich verändernde Rahmenbedingungen anpassbar sein. Insbesondere sollen alle technischen Details des Funkprotokolls so gekapselt werden, dass ein Austausch des Funkprotokolls lediglich an einer Stelle des Systems Änderungen erfordert Der Analog Devices ADuC702X -Mikrocontroller Zentrale Komponente des Erste-Hilfe-Sensors, welcher die Grundlage für die Sensoren im zu entwerfenden Netzwerk bildet, ist der ADuC Mikrocontroller. Es handelt 36

69 4.2. Der Analog Devices ADuC702X-Mikrocontroller ADC0 ADC11 MUX 1MSPS 12-BIT ADC 12-BIT DAC 12-BIT DAC DAC0 DAC1 CMP0 TEMP SENSOR ADuC BIT DAC DAC2 CMP1 CMP OUT BANDGAP REF 12-BIT DAC DAC3 V REF XCLKI XCLKO OSC AND PLL PSM PLA ARM7TDMI-BASED MCU WITH ADDITIONAL PERIPHERALS 2k 32 SRAM 31k 16 FLASH/EEPROM GPIO THREE- PHASE PWM PWM0 H PWM0 L PWM1 H PWM1 L PWM2 H PWM2 L RST POR 4 GENERAL PURPOSE TIMERS SERIAL I/O UART, SPI, I 2 C JTAG EXT. MEMORY 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 Übersicht über die Eigenschaften dieser Mikrocontrollerfamilie 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-Kanälen aus. So verfügt das Modell ADuC7026 beispielsweise über 16 A/D-Wandler-Kanäle mit einer Abtastrate von einer Million Samples pro Sekunde bei einer Auflösung von 12 Bit. Damit bietet jeder der 16 Kanäle eine Datenrate, die etwa dem 17fachen einer gewöhnlichen Audio-CD entspricht. Der Mikrocontroller selbst bietet bei einer Frequenz von 41,78 MHz eine maximale Leistung von 41 Millionen Befehlen pro Sekunde (MIPS). Zusätzlich sind auf dem Chip 8 kb SRAM sowie 62 kb Flash-Speicher vorhanden. Bei den Modellen ADuC7026 und ADuC7027 ist zusätzlich ein externer Speicherbus vorhanden, über den bis zu 512kB zusätzlicher SRAM angeschlossen werden kann. Bei 37

70 4. Analyse größerem Speicherbedarf besteht die Möglichkeit, über SPI oder I 2 C weiteren SRAM oder Flash-Speicher anzuschliessen. [Devi07] Peripherie In die Mikrocontroller der ADuC-702X -Familie ist standardmäßig folgende Peripherie integriert: AD-Wandler: Bis zu 16 Kanäle mit einer maximalen Abtastrate von 1 MSPS bei einer Auflösung von 12 Bit. DA-Wandler: Je nach Typ 2, 3 oder vier Kanäle, mit einer Ausgangsspannung zwischen 0 und 2,5 V mit einer Auflö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 Peripheriekomponenten. I 2 C Bus: 2 I 2 C-Schnittstellen zur Anbindung weiterer Peripherie. PLA: 2 Blöcke mit jeweils 8 PLA-Elementen. Timer: 4 Allzwecktimer/Zä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 größten 80 Pins zur Verfügung. Diese Pins sind zudem mehrfach belegt. Daher ist es nicht möglich, die gesamte Peripherie gleichzeitig zu verwenden. Je nach Anforderung ist ggf. die Verwendung eines größeren Modells notwendig Die Atmel-ZigBit-Familie Nachdem die Entscheidung getroffen wurde, ZigBee als Funktechnologie für das Netzwerk zu verwenden, muss nun noch ein geeignetes Hardwarebauteil gefunden werden. 38

71 4.3. Die Atmel-ZigBit-Familie Da die Herstellung von HF 1 -Komponenten eine sehr langwierige und komplexe Aufgabe ist, wurde die Entscheidung getroffen, ein komplett integriertes Modul zu verwenden, bei dem bereits alle HF -Komponenten und Antenne aufgebracht sind. Passende Lösungen waren von den Firmen Digi, Mikrochip, Radicrafts und Atmel verfügbar. Letztendlich wurde die Entscheidung für ein Modul der Firma Atmel getroffen, da diese nicht nur die günstigsten betrachteten Module, sondern mit der Ansteuerung über UART mittels AT-Befehlen auch am einfachsten anzusteuern waren. Der hier verwendete Modultyp soll nachfolgend kurz vorgestellt werden Hardware VCC ( V) IRQ UART USART/SPI I2C JTAG Analog ATmega1281 Micro controller AT86RF230 RF Transceiver Chip Antenna 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 für kurze Reichweiten angeboten. Besonderheit an diesem Modul ist, dass es bereits über zwei integrierte Antennen verfügt, so dass für den Betrieb keine weiteren Bauteile notwendig sind. 1 Hochfrequenz 39

72 4. Analyse Die ZigBit-Module enthalten einen IEEE Transceiver, einen ATmega Mikrocontroller sowie einen 128kB großen Flash-Speicher. Das Modul kann mittels UART, SPI oder I 2 C angesteuert werden. [Atme09] Firmware Bitcloud BitCloud ist ein ZigBee-Pro-zertifizierter Softwarestack von Atmel. Es werden die Module der ZigBit-Familie sowie die RZRAVEN-Evaluationskits unterstü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 unterstützen. Für Anwender, die selbst keine Firmware implementieren möchten, stellt das im folgenden Abschnitt beschriebene SerialNet eine Alternative dar SerialNet SerialNet ist eine BitCloud-basierte Firmware, die von Atmel als fertiges Image 2 angeboten wird. Dieses kann auf dem ZigBit-Modul installiert werden, wodurch die Notwendigkeit der Eigenentwicklung entfällt. SerialNet bietet ein einfaches serielles Interface, das sich mit Hilfe von AT-Befehlen 3 steuern lässt. Der Befehlssatz bietet Zugriff auf fast alle Module des ZigBit-Moduls wie z.b. das Versenden und Empfangen von Daten, das Schalten von IO-Ports eines entfernten ZigBit-Moduls sowie die Konfiguration des Energiesparmodus. Nicht möglich ist derzeit die Verwendung der im ZigBee-Standard definierten AES-Verschlüsselung, so dass eine Datenübertragung derzeit nur unverschlüsselt erfolgen kann. Daher müssen für den produktiven Einsatz weitere Sicherheitsmaßnahmen ergriffen werden. Wie diese aussehen können, ist in Abschnitt 9.2 beschrieben SerialNet AT-Protokoll Das SerialNet AT-Protokoll lässt sich vereinfacht als Zustandsautomat mit 3 Zuständen darstellen (vgl. Abbildung 4.3) 4 : 2 Binäres Speicherabbild, das ohne Anpassung in den Speicher des ZigBit-Moduls programmiert werden kann. 3 Der AT-Befehlssatz war früher zur Steuerung von Modems weit verbreitet. 4 Zur exakten Darstellung müssten weitere Zustände eingeführt werden, die das Bearbeiten von Befehlen im offline-modus repräsentieren. Außerdem wird der Übergang von offline zu online 40

73 4.3. Die Atmel-ZigBit-Familie offline {+wjoin +autonet=1} [OK ERROR] {+wleave} [OK ERRoR] online [Event] {Befehl} {OK ERROR} [Komplexe Rückgabe] [Event] Befehl wird ausgeführt { } 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 verfügbar. Ein Zugriff auf die Konfiguration der Netzwerkparameter wie Netzwerk- und Hardwareadresse ist verfügbar. online: Das Modul ist betriebsbereit, mit einem Netzwerk verbunden und wartet auf Befehle. Befehle zur Kommunnikation mit anderen Knoten stehen zur Verfügung, Befehle zur Kommunikation der Netzwerkparameter sind gesperrt. busy: Das Modul ist mit der Bearbeitung eines Befehls beschäftigt. Es stehen keine Befehle zur Verfügung jedoch können jederzeit Ereignisse empfangen werden. Grundsä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 zusätzlich zum Ergebniscode eine ggf. sogar mehrzeilige Antwort erfolgen. Eine Antwort wird immer durch Ausgabe eines Ergebniscodes beendet. Neben dieser synchronen Befehl-Antwort-Folge können jedoch jederzeit auch asynchrone Events auftreten. Hierauf muss bei der Entwicklung eines Treibers zur Ansteuerung des Moduls besonders geachtet werden. Die wichtigsten SerialNet-Befehle, eigentlich durch ein EVENT JOINED-Ereignis ausgelöst, und müsste daher durch einen Epsilon- Übergang dargestellt werden. Diese Details sind jedoch für das Verständnis der prinzipiellen Funktionsweise des Befehlssatzes unwesentlich. 41

74 4. Analyse Befehl Beschreibung Antwort Anwendbark. ATD Versenden von Daten Einfach online-zustand ATR Entfernten Befehl ausfü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 für ATD Einfach offline-zustand Tabelle 4.1.: Übersicht der wichtigsten SerialNet-Befehle Ereignis Beschreibung Parameter DATA Daten empfangen Adresse, Länge, Daten EVENT:JOINED Netzwerkverbindung hergestellt EVENT:LOST Netzwerkverbindung verloren Tabelle 4.2.: Übersicht der SerialNet-Ereignisse ihre Anwendbarkeit sowie die Art der Antwort sind in Tabelle 4.1 dargestellt. Tabelle 4.2 beinhaltet die wichtigsten SerialNet-Events Kommunikation mit dem ZigBit-Modul Problemstellung Das SerialNet-Protokoll ist grundsätzlich synchron. Ein Programm, das mit einem ZigBit-Modul kommunizieren lässt sich daher am einfachsten nach folgendem Muster aufbauen: 1 def sendebefehl ( befehl ) 42

75 4.4. Kommunikation mit dem ZigBit-Modul 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 dauern 5. Während das Steuerungsprogramm auf die Quittierung des Befehls mit einer Status-Meldung wartet, können asynchrone Ereignisse auftreten. Im oben abgebildeten Programm würde ein solches Ereignis fälschlicherweise als Antwort auf den gesendeten Befehl interpretiert werden. Dies hätte zur Folge, dass nun Steuerungsprogramm und ZigBit-Modul nicht mehr synchron zueinander ( out-of-sync ) sind. 2. Komplexe Rückgabewerte: Bestimmte Befehle der SerialNet-Firmware liefern nicht nur einen einfachen Statuscode, sondern eine komplexe, mehrzeilige Antwort zurück. Bei obigem Programm ergibt sich das Problem, dass dieses bereits nach der ersten Zeile fälschlicherweise davon ausgehen würde, dass die Antwort abgeschlossen wäre, obwohl noch weitere Zeilen folgen können. Auch in diesem Falle wären Steuerungsprogramm und ZigBit-Modul nicht mehr synchron zueinander. 5 Dies tritt insbesondere dann auf, wenn eine synchrone Datenübertragung zu einem entfernten Knoten durchgefü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

76 4. Analyse Behandlung asynchron auftretender Ereignisse Um asynchrone Ereignisse behandeln zu können, müssen diese zunächst erkannt werden. Dies kann mit Hilfe einer Liste aller möglichen Ereignisse und Statuscodes geschehen. In diesem Falle wird so lange von dem ZigBit-Modul gelesen, bis ein Statuscode empfangen wurde. Zwischendurch empfangene Ereignisse können entweder direkt behandelt, oder zunächst in einer Liste zwischengespeichert werden, um sie zu einem späteren Zeitpunkt zu behandeln. Beide Verfahren haben sowohl Vor- als auch Nachteile: Direktes Behandeln von Ereignissen: Dieses Verfahren hat den Vorteil, dass auf empfangene Ereignisse sofort reagiert werden kann; so lässt sich z.b. ein empfangener 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 Verklemmungen (Deadlocks) oder ein Verlust der Synchronisierung auftreten können 6. Dieses Verfahren eignet sich besonders für Systeme, in denen auf eingehende Ereignisse besonders schnell reagiert werden muss. Einreihen von Ereignissen in eine Warteschlange: Diese Verfahren hat den Vorteil, dass es sehr einfach umgesetzt werden kann. Alle Ereignisse, die während der Bearbeitung eines Befehls auftreten, werden zunächst in eine Warteschlange eingereiht. Mit der Abarbeitung der Ereignisse wird so lange gewartet, bis der laufende Befehl abgeschlossen wurde. Während der Abarbeitung der Ereignisse muss dann keine Rücksicht mehr darauf genommen werden, in welchem Zustand sich das ZigBit-Modul befindet, da es sich nach Abarbeitung eines Befehls sicher im betriebsbereiten Zustand befindet 7 Nachteilig ist, dass Ereignisse erst behandelt werden, wenn Befehle komplett abgearbeitet wurden. Bei Ereignissen, zu deren Bearbeitung nicht auf das ZigBit-Modul zugegriffen werden muss, bedeutet dies eine unnötige Verzögerung. Dieses Verfahren eignet sich daher eher für Systeme, in denen deutlich mehr Befehle als Ereignisse auftreten. 6 Eine mögliche Lösung ist die Verwendung einer Warteschlange, in die die zu versendenden Daten eingereiht werden. 7 Ausnahme hiervon ist, der zwischenzeitliche Verlust der Netzwerkverbindung, der natürlich gesondert behandelt werden muss. 44

77 4.4. Kommunikation mit dem ZigBit-Modul Durch die Verwendung von Multithreading kann darüber hinaus eine Kombination aus beiden Verfahren verwenden werden. In diesem Fall wird von einem Thread aus die Bearbeitung der Befehle, inkl. des Befüllens der Ereigniswarteschlange vorgenommen, während von einem anderen Thread aus diese Warteschlange parallel dazu abgearbeitet wird. Das folgende Pseudocode-Programm zeigt exemplarisch das Behandeln von Ereignissen über das Einreihen in Warteschlangen: 1 eventqueue = [] 3 def sendebefehl ( befehl ) 4 # Senden des Befehls 5 serialport. send ( befehl ) 7 # Antwort vom ZigBit - Modul lesen. 8 # ( Blockiert so lange, bis Antwort empfangen wurde ) 9 statusstring = serialport. readline () 11 # Events behandeln 12 while statusstring not in ( OK, ERROR ): 13 eventqueue. append ( statusstring ) 14 statustring = serialport. readline () 16 # Status Code interpretieren 17 if statusstring == OK : 18 return True 20 else : 21 return False 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

78 4. Analyse programm kann beim Parsen des Befehls daher entsprechend Rücksicht darauf genommen werden, ob eine einzeilige oder eine mehrzeilige Antwort erwartet wird. Komplexe 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 Statuscode empfangen wird. Auch hierbei muss natürlich darauf geachtet werden, dass zwischen einzelnen Zeilen einer Antwort Ereignisse auftreten können, die entsprechend der in Abschnitt vorgestellten Lösung behandelt werden müssen. Das folgende Pseudocode-Programm zeigt, wie komplexe Antworten behandelt werden können: 1 def sendebefehl ( befehl ) 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 = 12 while statusstring not in ( OK, ERROR ): 13 statusstring = serialport. readline () 14 complexresult. append ( statusstring ) 16 return statusstring 18 else : 19 ## Antwort vom ZigBit - Modul lesen. 20 ## ( Blockiert so lange, bis Antwort empfangen 21 ## wurde ) 22 statusstring = serialport. readline () 24 ## Antwort interpretieren 25 if statusstring == OK : 26 return True 46

79 4.4. Kommunikation mit dem ZigBit-Modul 28 else : 29 return False Kombination beider Lösungen Kombiniert man die Lösungen aus Abschnitt und Abschnitt 4.4.3, ergibt sich ein weiteres Problem: Bei der Lösung aus Abschnitt wird davon ausgegangen, dass alle gelesenen Zeilen, bei denen es sich nicht um Statuscodes handelt, Ereignisse sind. Diese Annahme ist jedoch hinfällig, sobald komplexe Antworten vom ZigBit Modul empfangen werden. Daher muss hierbei jede Antwort einer genaueren Prüfung unterzogen 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 " 13 def sendebefehl ( befehl ) 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 21 statusstring = serialport. readline () 23 ## Komplexe Antwort wird erwartet 47

80 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 : 30 eventqueue. append ( statusstring ) 31 else : 32 complexresult. append ( statusstring ) 34 statusstring = serialport. readline () 36 ## Ende Erreicht. Nun noch den statuscode anhaengen 37 ## und Ergebnis zurueckliefern 38 complexresult. append ( statusstring ) 39 return complexresult 41 else : 42 ## Antwort vom ZigBit - Modul lesen. 43 ## ( Blockiert so lange, bis Antwort 44 ## empfangen wurde ) 45 statusstring = serialport. readline () 47 # Events behandeln 48 while statusstring not in ( OK, ERROR ): 49 eventqueue. append ( statusstring ) 50 statustring = serialport. readline () 52 # Status Code interpretieren 53 if statusstring == OK : 54 return True 56 else : 57 return False 48

81 4.5. Powermanagement 4.5. Powermanagement Die Spannungsversorgung des Erste-Hilfe-Sensors erfolgt über Batterie. Da der Wechsel der Batterie während eines MANVs umständlich und zeitraubend ist, ist eine möglichst hohe Batterielaufzeit wünschenswert. Am besten wäre hierbei, wenn überhaupt kein Batteriewechsel notwendig wä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 überschreiten darf. Im empfangsbereiten Zustand braucht das ZigBit- Modul laut Datenblatt einen Strom von 19 ma, ist also grundsätzlich zur Erfüllung dieser Anforderung geeignet 8. 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 Datenblatt weniger als 6 µa. Zum Stromsparen wird das Modul periodisch für eine bestimmte Zeit in den Energiesparmodus versetzt. Während dieser Zeit kann das Modul weder von der Steurungssoftware angesprochen werden, noch können Daten vom Netzwerk empfangen werden. Damit in dieser Zeit keine Informationen verloren gehen, werden vom nächstgelegenen 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 über den Befehl AT+WPWR konfiguriert. Die Konfiguration erfolgt in Schritten zu 100 ms. Zum Aufruf des Energiesparmodus bieten sich nun zwei Möglichkeiten: Automatsisches Aufrufen des Energiesparmodus: Hierbei wird über den zweiten Paramter des Befehls AT+WPWR ein Intervall angegeben, in dem der Energiesparmodus periodisch aufgerufen wird. Hierbei erfolgt die Eingabe in Schritten von 10ms. Manuelles Aufrufen des Energiesparmodus: Alternativ zum automatischen Aufrufen kann der Energiesparmodus über den Befehl AT+WSLEEP auch manuell 8 In dieser Betrachtung ist der Strombedarf des Erste-Hilfe-Sensors nicht berücksichtigt. 49

82 4. Analyse aufgerufen werden. Dies kann entweder entweder alternativ zum automatischen Aufrufen oder als Ergänzung verwendet werden. Bei der Verwendung des Energiesparmodus muss sichergestellt werden, dass keine Informationen, die über die UART -Schnittstelle an das Modul gesendet werden, verloren gehen. Hierzu bietet die SerialNet-Firmware die Möglichkeit, über die CTS-Leitung der UART -Schnittstelle ihre Empfangsbereitschaft zu signalisieren. Die Steurungssoftware 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 ü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 Nachrichten 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 Verfügung. 50

83 5. Entwurf In diesem Kapitel wird der Entwurf der zu implementierenden Lösung vorgenommen. Hierzu erfolgt zunächst der Entwurf des Gesamtsystems im Groben. Dieses Gesamtsystem wird in einzelne Komponenten zerlegt, die danach einzeln genauer spezifiziert werden. Hierbei wird zwischen Hard- und Software unterschieden. Ein Teil der Softwarekomponenten wird parallel zu dieser Arbeit in [Tepe10] entworfen und implementiert Gesamtsystem In dieser Arbeit wird ein System zur Patientenüberwachung entworfen. Dieses System besteht aus einer Kombination von Soft- und Hardware. Zwischen den einzelnen Komponenten gibt es klar definierte Schnittstellen. Hierdurch ist gewährleistet, dass die einzelnen Komponenten unabhängig voneinander entworfen und implementiert werden können. Noch nicht implementierte Komponenten können durch Simulatoren ersetzt werden, so dass bereits fertige Komponenten schon getestet werden können, ohne dass das Gesamtsystem komplett fertig gestellt werden muss. Dies gewährleistet ein frühzeitiges Erkennen von Problemen und ermö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 Überwachung der Patienten eingesetzt wird. Dieser wird in [Jäg08] dargestellt. In dieser Arbeit wird dieser

84 5. Entwurf Anwender Server-Anwendung Operator Notarzt MANV-Server MANV-Datenbank Client-Anwendung Ethernet MANV-Gui MANV-Mobile-Gui Wlan Wlan-Access-Point MANV-Connector ZigBee-Netzwerk 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.: Überblick über das Gesamtsystem 52

85 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. Hierfür wird ein fertiges ZigBee-Modul der Firma Atmel verwendet. ZigBee-USB-Stick: Der USB-Stick bildet die Hardwareschnittstelle zwischen Computer 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 Übersetzung zwischen der Hardware des USB-Sticks und der CORBA-Schnittstelle der MANV- Suite vornimmt. Vereinfacht gesprochen handelt es sich um einen Treiber für den ZigBee-USB-Stick. Der MANVConnector kapselt alle hardwarespezifischen Designentscheidungen. Soll später eine andere Funkschnittstelle wie z.b. Bluetooth oder WLAN verwendet werden, so muss lediglich der MANVConnector ausgetauscht werden. MANVServer: Der MANVServer verwaltet alle Informationen über das Sensornetz. Hierzu wird eine relationale Datenbank verwendet. Er sorgt dafür, dass alle Informationen an den entsprechenden Empfänger zugestellt werden. Die Kommunikation zwischen MANVServer und MANVConnector erfolgt über CORBA. Der MANVServer wurde in [Tepe10] entwickelt. Client-Anwendungen: Die Clientanwendungen, also MANVGui und MANVMobileGui bilden die Benutzerschnittstelle des Sensornetzes. Diese wurden ebenfalls in [Tepe10] entwickelt 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 können folgende Zustände generiert werden: 53

86 5. Entwurf ADUC7026 1k DGND DGND AGND VCC 470nF DGND DGND 470nF AGND VDD 1k 100nF 12pF 12pF DGND DGND 470nF 100nF 100nF VDD DGND ADC4 1 ADC5 2 ADC6 3 ADC7 4 ADC8 5 ADC9 6 ADC10 7 GNDREF 8 ACDNEG 9 DAC0/ADC12 10 DAC1/ADC13 11 DAC2/ADC14 12 DAC3/ADC15 13 TMS 14 TDI 15 P0.1/PWM2H/BLE# 16 P2.3/AE 17 P4.6/AD14/PLAO[14] 18 P4.7/AD15/PLAO[15] 19 BM/P0.0/CMPOUT/PLAI[7]/MS2 20 P0.6/T1/MRST/PLAO[3]/AE 21 TCK 22 TDO 23 P0.2/PWM2L/BHE# 24 IOGND 25 IOVDD 26 LVDD 27 P3.0/AD0/PWM0H/PLAI[8] 29 P3.1/AD1/PWM0L/PLAI[9] 30 P3.2/AD2/PWM1H/PLAI[10] 31 P3.3/AD3/PWM1L/PLAI[11] 32 P2.4/PWM0H/MS0 33 P0.3/TRST/A16/ADCBUSY 34 P2.5/PWM0L/MS1 35 P2.6/PWM1H/MS2 36 RST# 37 P3.4/AD4/PWM2H/PLAI[12] 38 P3.5/AD5/PWM2L/PLAI[13] 39 IRQ0/P0.4/PWMTRIP/PLAO[1]/MS1 40 IRQ1/P0.5/ASCBUSY/PLAO[2]/MS0 41 DGND 28 P2.0/SPM9/PLAO[5]/CONVSTART# 42 P0.7/ECLK/XCLK/SPM8/PLAO[4] 43 XCLKO 44 XCLKI 45 P3.6/AD6/PWMTRIP/PLAI[14] 46 P3.7/AD7/PWMSYNC/PLAI[15] 47 P2.7/PWM1L/MS3 48 P2.1/WS#/PWM0H/PLAO[6] 49 P2.2/RS#/PWM0L/PLAO[7] 50 P1.7/SPM7/PLAO[0] 51 P1.6/SPM6/PLAI[6] 52 IOGND 53 IOVDD 54 P4.0/AD8/PLAO[8] 55 P4.1/AD9/PLAO[9] 56 P1.5/SPM5/PLAI[5]/IRQ3 57 P1.4/SPM4/PLAI[4]/IRQ2 58 P1.3/SPM3/PLAI[3] 59 P1.2/SPM2/PLAI[2] 60 P1.1/SPM1/PLAI[1] 61 P1.0/T1/SPM0/PLAI[0] 62 P4.2/AD10/PLAO[10] 63 P4.3/AD11/PLAO[11] 64 P4.4/AD12/PLAO[12] 65 P4.5/AD13/PLAO[13] 66 REFGND 67 VREF 68 DACREF 69 DACGND 70 AGND 71 AGND 72 AVDD 73 AVDD 74 DACVDD 75 ADC11 76 ADC0 77 ADC1 78 ADC2/CMP0 79 ADC3/CMP1 80 U$1 R6 2 1 RESET SERIALDOWNLOAD 3 4 C4 C5 R9 C6 Q1 C7 C8 C10 C11 C12 ZIGBIT_STATUS UART_CTS UART_RTS UART_RXD UART_TXD TRST TDI TMS TCK TDO BUTTON_DOWNLOAD BUTTON_RED BUTTON_YELLOW BUTTON_GREEN LED_BLUE LED_GREEN BUTTON_BLUE LED_RED ZIGBIT_RESET LED_YELLOW PIEZZO ADuC 7026 Abbildung 5.2.: Schaltplan der MANVNode: Mikrocontroller. 54

87 5.2. MANVNode ZigBit UART_RXD UART_TXD UART_RTS UART_CTS S JP1 VDD ZIGBIT_TXD ZIGBIT_RXD ZIGBIT_RTS ZIGBIT_CTS DGND ZIGBIT_RESET DGND SPI-CLK SPI-MISO SPI-MOSI PB5 PB6 PB7 32K-OUT(PG3) RESET DGND CPU-CLK I2C-CLK(PD0) I2C-DATA(PD1) UART-TX UART-RX UART-RTS UART-CTS PD6 PD7 U$3 ZDM-A1281-A2 AGND DGND 470nF PG0 PG1 PG2 DGND DGND DVCC DVCC IRQ6 IRQ PE3 USART0-EXTCLK 40 USART0-TX 39 USART0-RX 38 UART-DTR PG5 AGND AREF 33 BAT(VCC/3,PF0) 32 ADC-IN1(PF1) 31 ADC-IN2(PF2) 30 ADC-IN3(PF3) JTAG-TCK 29 JTAG-TDO JTAG-TDI JTAG-TMS ENABLE_ZIGBEE C9 SJ1 DGND VDD Abbildung 5.3.: Schaltplan der MANVNode: ZigBit-Modul. Grün: Simulation eines Patienten mit gutem Kreislaufzustand. Puls zwischen 60 und 120 Schlägen pro Minute, Atemzü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 Schlägen pro Minute, Atmung zwischen 60 und 80 Zü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

88 R8 SJ1 5. Entwurf ZDM-A1281-A pF nF µF LP2980IM5 100pf ES2D 10µF nF nF 470nF 100nF ADUC7026 Q1 0R7 0 12pF 4 470nF 100nF 1k 3 100k 100k 100k k Abbildung 5.4.: Entwurf der Platine der MANVNode. schen (0 und 2) mit bestehendem akutem Handlungsbedarf. Priorisierte Generierung einer Alarmmeldung. Zur Einstellung und zum Wechsel der Zustände befinden sich 3 Taster an der Platine. Der Zustand wird mit Hilfe von drei farbigen LEDs visualisiert. Zusätzlich kann über einen Piezo-Summer ein Alarm auch akustisch wiedergegeben werden. Durch die Kombination der drei LEDs werden zusätzlich Status- und Fehlerinformationen der Platine während des Initialisierungsvorgangs ausgegeben. 56

89 5.2. MANVNode 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 erläutert Spannungsversorgung power AVDD VCC R5 100 R4 100 VDD VDD POWER1 1 2 C3 10µF PWR C2 10µF DGND AGND DGND GND ES2D D1 1 C1 3 IN ON OUT 5 GND ADP1 LP2980IM pf GND R7 R8 0 0 POWER 1 2 AGND DGND Abbildung 5.5.: Schaltplan der Spannungsversorgung der MANVNode. Um die Platine möglichst vielseitig einsetzen zu können, wurde Wert auf eine möglichst flexible Spannungsversorgung gelegt. Diese soll möglichst robust gegenüber Spannungsschwankungen sein. Kern der Spannungsversorgung ist ein Low-Dropout-Spannungsregler des Typs LP der Firma National Semiconductor. Dieser liefert 57

90 5. Entwurf eine stabile 3,3-V-Spannung bei einem maximalen Strom von 50 ma. Die Eingangsspannung kann zwischen 2,1 V und 16 V variiert werden. Die Spannungsversorgung kann damit z.b. über USB (5 V-Versorgungsspannung), ein externes Netzteil oder eine 9 V-Blockbatterie gespeist werden. Durch die hohe maximale Versorgungsspannung von 9 V sind Schäden durch versehentliches Anschließen eines falschen Netzteils weitestgehend ausgeschlossen. Die Spannungsversorgung ist zusätzlich mit einem 10- mf-kondensator stabilisiert. Zusätzlich wurde die die Spannungsversorgung weiter stabilisiert. Hierzu wurde jeder Spannungseingang aller Bauteile der Platine mit einem 100nF Kondensator gepuffert. Diese sind möglichst nahe an den entsprechenden Versorgungspins angebracht. Kurzzeitige Spannungsabfälle, wie sie z.b. beim Schalten von LEDs, des Piezo-Summers oder des Aufwachens des ZigBee-Moduls aus dem Stromsparmodus auftreten können, werden so zuverlässig abgefangen. Der Schaltplan der Spannungsversorgung der MANVNode findet sich in Abbildung Serielle Schnittstellen Die MANVNode-Platine verfügt über mehrere seriellen Schnittstellen. Im äußeren Bereich der Platine ist eine serielle Schnittstelle (JP1) vorhanden, welche die Standardbelegung des Programmierkabels des ADuC-7026-Evaluationsboards besitzt. Bereits vorhandene Programmierkabel können somit ohne weiteres zur Programmierung des Mikrocontrollers verwendet werden. Zusätzlich besteht die Möglichkeit, auf die serielle Schnittstelle des ZigBit-Moduls zuzugreifen, worüber das Herunterladen von Firmware auf das Modul sowie Einstellung bestimmter Parameter wie der Netzwerkkennung des Gerätes möglich ist. Der Zugriff erfolgt ebenfalls über die Stiftleiste JP1, allerdings müssen hierfür RX- und TX -Leitung des Programmierkabels vertauscht und alle Jumper des Schalters S1 unterbrochen werden JTAG Die MANVNode-Platine verfügt neben der seriellen auch über eine JTAG-Schnittstelle. Die Beschaltung dieser ist in Abbildung 5.6 zu sehen. Diese ermöglich einen Zugriff mit gängigen Programmierwerkzeugen wie z.b. Eclipse, Crossworks oder Kyle µvision. Über die Schnittstelle kann sowohl Programmierung als auch Debugging des ADuC- 58

91 5.2. MANVNode JTAG TCK TDI R3 100k R2 100k R1 TRST 100k VDD TRST TDI TMS TCK TDO JTAG DGND Abbildung 5.6.: Schaltplan der MANVNode: JTAG Mikrocontrollers durchgeführt werden. Ein Zugriff auf das ZigBit Modul ist allerdings nur indirekt möglich 1. Ein Zugriff über JTAG ist nicht vorgesehen LED-Anzeige Die MANVNode-Platine verfügt insgesamt über 6 LEDs, die zur Anzeige des aktuellen Zustands sowie zur Fehlerdiagnose dienen. Die Beschaltung dieser LEDs findet sich in Abbildung Einige Werkzeuge bieten die Möglichkeit, eine Konsolenverbindung über den UART des ADuC Mikrocontrollers zu öffnen, um direkt mit dem ZigBit-Modul zu kommunizieren. 59

92 5. Entwurf user interface BYELLOW BUTTON_YELLOW LED_RED DGND BBLUE BUTTON_BLUE RED LED_YELLOW YELLOW LED_GREEN DGND BGREEN BUTTON_GREEN LED_BLUE PIEZZO 2 GREEN BLUE 1 PIEZZO DGND DGND BRED BUTTON_RED 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 angeschlossen 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 Alarmunterdrückung ( Mute ) besteht. ZIGBIT-STATUS: Diese LED leuchtet, sobald das ZigBit-Modul über das CTS- Signal ( Clear to send ) die Bereitschaft, Daten zu empfangen, signalisiert. 60

93 5.2. MANVNode Diagnosecodes Neben den oben dargestellten einfachen Signalisierungen hat die Firmware der MANV- Node-Platine die Möglichkeit, über die Kombination obiger LEDs Diagnose- und Fehlercodes auszugeben. Hierbei gilt folgende Codierung: GREEN blinkt in 1-Sekunden-Abständen: Der ADuC-7026-Mikrocontroller befindet sich im Bootmodus. Ein Reset des ZigBit-Moduls wurde durchgefü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 initalisiert, auf die Verbindung mit dem Funknetzwerk wird gewartet. YELLOW leuchtet dauerhaft länger als 10 Sekunden und ZIGBIT-STATUS leuchtet dauerhaft: Es kann keine Verbindung mit dem Funknetzwerk aufgebaut werden. YELLOW leuchtet dauerhaft länger als 10 Sekunden und ZIGBIT-STATUS leuchtet nicht: Es liegt eine Funktionsstörung des ZigBit-Moduls vor. ZIGBIT-STATUS leuchtet dauerhaft: Verbindung mit Funknetzwerk wurde verloren oder Powersafe-Modus ist deaktiviert. ZIGBIT-STATUS blinkt im 2-Sekunden-Abstand: Die Platine arbeitet ordnungsgemäß, es besteht eine Verbindung mit dem Funknetzwerk und der Powersafe- Modus ist aktiv Firmware Die Firmware der MANVNode dient dem Entwickeln und Testen eines Treibers für das ZigBit-Modul. Dieser Treiber wird später in den Erste-Hilfe-Sensor integriert werden. Zusätzlich bietet die MANVNode Funktionalität, die zur Simulation des Erste-Hilfe- Sensors gegenüber der MANVSuite dient. Hierzu sollen neben dem ZigBit-Treiber folgende Funktionalitäten integriert werden: Zufallszahlengenerator zum Senden zufälliger Messwerte. 61

94 5. Entwurf Änderung des Zustands des Zufallszahlengenerators über Taster. Ansteuerung von LEDs zur Ausgabe des Zustands des Zufallszahlengenerators. Ansteuerung eines Piezzo-Summers zur Signalisierung von Alarmen Ansteuerung des UARTs Zur Vermeidung von Busy-Waiting 2 soll der Treiber für den UART s als Interrupt- Service-Routine 3 (ISR) realisiert werden. Die Kommunikation zwischen Firmware und UART -Treiber erfolgt ü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 ü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 Ansteuerung des ZigBit-Modul Das ZigBit-Modul ist via UART mit der MANVNode verbunden und wird ü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 können entweder periodisch mittels eines Timer-Interrupts oder als Hauptprogramm in einer Endlosschleife ausgeführt werden. Wichtig hierbei ist die Berü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, ü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 ausgelöste Unterbrechungsanforderung der Software, welche zum sofortigen Aufruf einer entsprechenden Interrupt Service Routine führt. Nach Beendigung dieser Routine wird die Bearbeitung an der Stelle der Unterbrechung fortgesetzt. 62

95 5.2. MANVNode commandbuffer initialisieren Status = OK Status von Sensor lesen Alarm? Ja Alarmnachricht verschicken Nein Statusnachricht verschicken Antwort von Funkmodul lesen Antwort ist Statuscode? Nein Antwort in Commandbuffer legen Ja Commandbuffer abarbeiten Energiesparmodus aufrufen Abbildung 5.8.: Ablauf der Ansteuerung des ZigBit-Moduls in der ZigBit-Firmware. 63

96 5. Entwurf signalisiert wird. Alle anderen Ereignisse können zunächst vernachlässigt werden. Ereignisse, die während des Wartens auf einen Statuscode auftreten, sollen zur späteren Behandlung in einen Ringpuffer zwischengespeichert werden. Die Abarbeitung soll dann nach Empfang des Statuscodes erfolgen. Behandlung komplexer Rückgabewerte: Im aktuellen Entwurf werden von der Firmware der MANVNode keine SerialNet-Befehle verwendet, die eine komplexe Rückgabe haben, so dass dieses Problem eigentlich nicht auftreten sollte. Sollten trotzdem komplexe Rückgaben auftreten, so werden diese wie asynchron auftretende Ereignisse behandelt und in den Befehlspuffer gelegt. Bei der späteren Auswertung des Befehlspuffers werden diese dann einfach verworfen. So bleibt eine Synchronisation mit dem ZigBit-Modul in jedem Fall gewährleistet. Die SerialNet-Firmware bietet die Möglichkeit, den Energiesparmodus entweder manuell oder aber periodisch (mit konfigurierbaren Abständen und Dauer) aufzurufen (vgl. Abschnitt 4.5). Für die MANVNode-Firmware wird der manuelle Aufruf verwendet, da dieser deutlich flexibler und einfacher zu implementieren ist als der automatische Modus: Sobald die Übertragung der Zustandsdaten abgeschlossen ist und alle empfangenen Befehle abgearbeitet wurden, ruft die Firmware über den Befehl AT+WSLEEP den Energiesparmodus auf. Hierdurch ist gewährleistet, dass das ZigBit-Modul nur so lange wie zur Bearbeitung aller Aufgaben notwendig in Betrieb ist. Nachdem das ZigBit-Modul aus dem Energiesparmodus zurückkehrt, wird die Abarbeitung der Ansteuerungsroutine von vorne begonnen. Das Aufwachen aus dem Energiesparmodus wird der MANVNode-Firmware über eine Zustandsänderung des CTS-Registers des UART signalisiert. Zusätzlich wird der AT+WSLEEP Befehl mit dem Statuscode OK quittiert, sobald das ZigBit-Modul wieder betriebsbereit ist. Insgesamt ergibt sich fü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

97 5.3. ZigBee-USB-Stick Dieser Ablauf ist in Abbildung 5.8 als Ablaufdiagramm dargestellt 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. Zusä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. Fü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

98 5. Entwurf U$1 ZDM-A1281-A2 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 umgestellt werden 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]. Abbildung 5.11 beschreibt den Datenfluss zwischen MANVSuite, MANVConnectors und MANVNode: Der MANVServer ist Teil der MANVSuite. Er dient als Vermittlungsstelle zwischen den einzelnen Softwarekomponenten, die mittels Corba an diesen angebunden sind. Eine dieser Komponenten ist der MANVConnector, der in Abschnitt 5.5 genauer beschrieben wird. Dieser greift mittels einer seriellen Schnittstelle (in der 66

99 5.5. MANVConnector MANVSuite MANVServer Corba MANVConnector MANVConnector (Java) TCP/IP - Socketverbindung Serial2Socket (Python) TTY-Verbindung USB-Serial (Linux Kerneltreiber) ZigBee-USB-Stick USB 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 herstellt. Auf diese Weise kommt die Verbindung zwischen MANVSuite und MANVNode zu Stande. 67

100 5. Entwurf MANVConnector new() new() new() resultqueue commandqueue eventqueue new() new() socketwriter socketreader initcorba take() return command readline() writeline() return data new() put(event) getlastresult() corbasender return result take() put(result) return result return event 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

101 5.5. MANVConnector weiterzuleiten. Andererseits empfängt sie Corba-Events vom MANVServer, dekodiert diese und sendet sie in Form von Sensornetz-Befehlen an die zuständigen MANVNodes weiter. Das vollständige UML-Klassendiagramm findet sich in Abbildung Threads Wie aus Abbildung 5.17 zu entnehmen ist, verfügt der MANVConnector neben dem Hauptthread über drei weitere Threads: SocketWriter: Dieser Thread entnimmt Befehle aus der CommandQueue und sendet diese über den ZigBee-USB-Stick an das Sensornetz. Nun blockiert der Thread so lange, bis das Ergebnis des Befehls zur Verfügung steht oder eine bestimmte Zeitgrenze überschritten wurde. Sobald dies der Fall ist, wird der Befehl zusammen mit dem Ergebnis in die ResultQueue eingefügt. SocketReader: Dieser Thread empfängt Daten aus dem Sensornetz. Handelt es sich um ein Ergebnis, so wird dies dem SocketWrite signalisiert, und das Ergebnis zur Abholung zur Verfügung gestellt. Handelt es sich hingegen um ein Ereignis, so wird dieses in die EventQueue eingefügt. CorbaSender: Dieser Thread ist für die Kommunikation mit MANVServer zuständig. Befehle, die vom MANVServer empfangen werden, werden für das Sensornetz aufbereitet und in die CommandQueue eingestellt. Außerdem werden Ereignisse aus der EventQueue entnommen, in Corba-Events übersetzt und an den MANVServer zugestellt. Die Kommunikation der Threads untereinander findet komplett über die oben genannten Warteschlangen statt. Das Zusammenwirken der Threads ist in Abbildung 5.12 dargestellt: Zunä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

102 5. Entwurf Beim Starten der Threads wird sichergestellt, dass diese alle Zugriff auf alle drei Warteschlangen haben. Die konsequente Verwendung der Warteschlangen zur Kommunikation der Threads untereinander löst bereits viele Synchronisierungsprobleme. Grundsätzlich findet Kommunikation zwischen den Threads rein über die Warteschlangen statt. Einzige Ausnahme ist das Abrufen des Ergebnisses eines gesendeten Kommandos Reprä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 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 senddata(data: String): MANVResult senduntilsuccess(data: String): MANVResult togglealertstatus: MANVResult enablealertstatus: MANVResult disablealert: MANVResult mutalert: MANVResult requestmacid: int readonlyzigbit id: int readonlyzigbit(nodeid: int) getnodeid: int getmacid: int senddata(data: String): MANVResult togglealertstatus: void enablealertstatus: void disablealert: void mutealert: void Abbildung 5.13.: Klassendiagramm der ZigBit-Klassen Abbildung 5.13 zeigt die Klassenrepräsentation der ZigBit-Module. Da es nicht immer mö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 können, implementieren beide das Interface izigbit. Eine genauere Beschreibung der Attribute und Methoden der ZigBit-Klassen findet sich in Abschnitt A

103 5.5. MANVConnector Synchronisierung der Befehlsübertragung Bei der Kommunikation mit dem auf dem USB-Stick aufgebrachten ZigBee-Modul stellen sich grundsätzlich die selben Synchronisierungsprobleme wie in der MANVFirmware. Da der MANVConnector jedoch alle Möglichkeiten der Java Virtual Machine nutzen kann, lassen sich diese deutlich einfacher und eleganter lösen. In der MANVFirmware werden hierzu mehrere Ringpuffer verwendet, welche die empfangenen Daten speichern. Dieser Ansatz findet sich auch im MANVConnector wieder. Hierbei werden jedoch an Stelle von Ringpuffern priorisierte Warteschlangen, sogenannte Queues verwendet. Die Command Queue: In dieser Queue werden alle zu sendenden Befehle gespeichert. Die Event Queue: In dieser Queue werden alle empfangenen Ereignisse gespeichert. Die Result Queue: In dieser Queue werden alle bereits gesendeten Befehle zusammen mit dem Resultat, das dieser Befehl hatte, gespeichert. Jedes Element der einzelnen Queues verfügt über eine Priorität; die Queues sorgen dafür, dass der Zugriff nach Priotität sortiert erfolgt. Hierdurch wird sicher gestellt, dass wichtige Ereignisse wie z.b. Alarme bevorzugt ausgeliefert werden. Bei der Befehlsübertragung muss darauf geachtet werden, dass ein Befehl erst dann gesendet werden darf, wenn die Abarbeitung aller vorherigen Befehle erfolgt ist, da sonst die Synchronität mit dem ZigBit-Modul nicht mehr gewährleistet ist. Da innerhalb des MANVConnectors das Senden in einem anderen Thread geschieht als das Empfangen, erfordert dies besondere Maßnahmen: Um die Synchronisation zu gewährleisten, bietet der Thread SocketReader eine Schnittstelle, ü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 Schnittstelle 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 weiteren Befehle senden. Hierdurch wird die geforderte Synchronisierung erreicht. Durch 71

104 5. Entwurf die JVM ist ein korrektes Verhalten des Latches sowie der zur Priorisierung verwendeten Warteschlangen garantiert. Dieser Sachverhalt ist auch nochmal in Abbildung 5.12 dargestellt. Die vom SocketReader gelesenen Ergebnisse und Ereignisse werden selbst wieder durch Objekte repräsentiert Ergebnisse und Ereignisse <<interface>> Comparable compareto(o: object): int MANVCommand command: String result: MANVResult id: int maxid: static int resultlatch: CountDownLatch MANVCommand(command: String, priority: int) getcommand: String getuniqueid: int setresult(result: MANVResult) getresult: MANVResult MANVPrioritized priority: int compareto(o: MANVPrioritized): int compareto(o: object): int MANVEvent raw: String MANVEvent(raw: String) isresult: boolean isimportant: boolean fromstring(raw: String): MANVEvent createcorbamessages: AbstractList<CorbaMessageContainer> tostring: String getraw: String MANVChildJoined source: izigbit MANVChildLost(raw: String) isimportant: boolean createcorbamessages: AbstractList<CorbaMessageContainer> MANVChildLost source: izigbit MANVChildLost(raw: String) isimportant: boolean createcorbamessages: AbstractList<CorbaMessageContainer> MANVResult status: boolean subresult: MANVResult MANVResult(raw: String, subresult: MANVResult) getdata: String isresult: boolean isimportant: boolean iscomposite: boolean getchildlist(commandqueue: BlockingQueue<MANVCommand>): AbstractList<CorbaMessageContainer> getsubresult(result: MANVResult, tostring: String): MANVResult MANVDataReceived source: izigbit data: String MANVDataReceived(raw: String) isimportant: boolean parseraw(raw: String) MANVChildrenList MANVChildrenList(raw: String) iscomposite: boolean getchildlist(commandqueue: BlockingQueue<MANVCommand> addsubresult(result: MANVResult) MANVGsn myraw: String MANVGsn(raw: String) isccomposite: boolean getdata: String addsubresult(result: MANVResult) MANVStatusMessage pulse: short breathing: short alertstatus: HashMap<Integer, Integer> MANVStatusMessage(raw: String) parseraw(raw: String) createcorbamessages: AbstractList<CorbaMessageContainer> 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

105 5.5. MANVConnector MANVStatusMessage: Es wurde eine Satusnachricht von einem Sensor empfangen. Diese beinhaltet neben dem Alarmzustand Werte für Puls- und Atemfrequenz. MANVResult: Allgemeines Ergebnis eines gesendeten Befehls. MANVChildrenList: Enthält eine Liste mit Kindknoten als Ergebnis auf den Befehl AT+WCHILDREN. MANVGsn: Enthält die GSN (Hardwareadresse) eines entfernten Knotens. Eine genauere Beschreibung der Attribute und Methoden dieser Klassen erfolgt in Abschnitt A

106 5. Entwurf result SocketReader eventqueue: BlockingQueue<MANVEvent> lastresult: MANVResult 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 senddata(data: String): MANVResult isenddata(data: String) togglealertstatus: MANVResult disablealert: MANVResult enablealert: MANVResult mutealert: MANVResult itogglealertstatus: void idisablealert: void ienablealert: void imutealert: void <<interface>> Comparable compareto(o: object): int readonlyzigbit id: int readonlyzigbit(nodeid: int) getnodeid: int getmacid: int senddata(data: String): MANVResult togglealertstatus: void enablealertstatus: void disablealert: void mutealert: void MANVPrioritized priority: int compareto(o: MANVPrioritized): int compareto(o: object): int MANVCommand command: String result: MANVResult id: int maxid: static int resultlatch: CountDownLatch MANVCommand(command: String, priority: int) getcommand: String getuniqueid: int setresult(result: MANVResult) getresult: MANVResult MANVEvent raw: String MANVEvent(raw: String) isresult: boolean isimportant: boolean fromstring(raw: String): MANVEvent createcorbamessages: AbstractList<CorbaMessageContainer> tostring: String getraw: String corbamessages result MANVResult status: boolean subresult: MANVResult MANVResult(raw: String, subresult: MANVResult) getdata: String isresult: boolean isimportant: boolean iscomposite: boolean getchildlist(commandqueue: BlockingQueue<MANVCommand>): AbstractList<CorbaMessageContainer> getsubresult(result: MANVResult, tostring: String): MANVResult MANVChildrenList MANVChildrenList(raw: String) iscomposite: boolean getchildlist(commandqueue: BlockingQueue<MANVCommand> addsubresult(result: MANVResult) MANVGsn myraw: String MANVGsn(raw: String) isccomposite: boolean getdata: String addsubresult(result: MANVResult) Abbildung 5.15.: Klassendiagramm des MANV-Connectors (Linke Seite) 74

107 5.5. MANVConnector Thread run: void SocketWriter commandqueue: BlockingQueue<MANVCommand> resultqueue: BlockingQueue<MANVCommand> serialout: PrintWriter reader: SocketReader lastresult: MANVResult SocketWriter(serialOut: PrintWriter, commandqueue: <MANVCommand>, reader: SocketReader) writeline(line: String) run: void commandqueue CorbaSender eventqueue: BlockingQueue<MANVEvent> serverincoming: Incoming CorbaSender(eventQueue: BlockingQueue<MANVEvent>, serverincoming: Incoming) run: void eventqueue result BlockingQueue<MANVEvent> BlockingQueue<MANVCommand> CORBA_Node eventqueue MANVConnector commandqueue: BlockingQueue<MANVCommand> eventqueue: BlockingQueue<MANVEvent> resultqueue: BlockingQueue<MANVCommand> corbasender: CorbaSender commandsimpl: CommandsImpl main(args: String[]): void commandqueue commandsimpl CommandsImpl disablealert(node: CORBA_Node) enablealert(node: CORBA_Node) togglealert(node: CORBA_Node) mute(node: CORBA_Node) 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 senddata(data: String): MANVResult senduntilsuccess(data: String): MANVResult togglealertstatus: MANVResult enablealertstatus: MANVResult disablealert: MANVResult mutalert: MANVResult requestmacid: int source source MANVDataReceived source: izigbit data: String MANVDataReceived(raw: String) isimportant: boolean parseraw(raw: String) MANVChildLost source: izigbit MANVChildLost(raw: String) isimportant: boolean createcorbamessages: AbstractList<CorbaMessageContainer> MANVChildJoined source: izigbit MANVChildLost(raw: String) isimportant: boolean createcorbamessages: AbstractList<CorbaMessageContainer> CorbaMessageContainer send(serverincoming: Incoming) MANVStatusMessage pulse: short breathing: short alertstatus: HashMap<Integer, Integer> MANVStatusMessage(raw: String) parseraw(raw: String) createcorbamessages: AbstractList<CorbaMessageContainer> tostring: String CorbaDataMessageContainer message: CORBA_DataMessage CorbaDataMessageContainer(message: CORBA_DataMessage) send(serverincoming: Incoming) tostring: String CorbaEventMessageContainer message: CORBA_EventMessage send(serverincoming: Incoming) tostring: String) Abbildung 5.16.: Klassendiagramm des MANV-Connectors (Rechte Seite) 75

108 5. Entwurf Thread run: void SocketReader eventqueue: BlockingQueue<MANVEvent> lastresult: MANVResult resultsemaphore: Semaphore serialin: BufferReader SocketReader(serialIn: BufferedReader, eventqueue: BlockingQueue<MANVEvent>) setlastresult(manvresult: result) getlastresult(manvresult: result) run: void SocketWriter commandqueue: BlockingQueue<MANVCommand> resultqueue: BlockingQueue<MANVCommand> serialout: PrintWriter reader: SocketReader lastresult: MANVResult SocketWriter(serialOut: PrintWriter, commandqueue: <MANVCommand>, reader: SocketReader) writeline(line: String) run: void commandqueue CorbaSender eventqueue: BlockingQueue<MANVEvent> serverincoming: Incoming CorbaSender(eventQueue: BlockingQueue<MANVEvent>, serverincoming: Incoming) run: void eventqueue eventqueue BlockingQueue<MANVEvent> BlockingQueue<MANVCommand> eventqueue CorbaMessageContainer send(serverincoming: Incoming) CorbaDataMessageContainer message: CORBA_DataMessage CorbaDataMessageContainer(message: CORBA_DataMessage) send(serverincoming: Incoming) tostring: String CorbaEventMessageContainer message: CORBA_EventMessage send(serverincoming: Incoming) tostring: String) MANVConnector commandqueue: BlockingQueue<MANVCommand> eventqueue: BlockingQueue<MANVEvent> resultqueue: BlockingQueue<MANVCommand> corbasender: CorbaSender commandsimpl: CommandsImpl main(args: String[]): void commandqueue commandsimpl CORBA_Node CommandsImpl disablealert(node: CORBA_Node) enablealert(node: CORBA_Node) togglealert(node: CORBA_Node) mute(node: CORBA_Node) Abbildung 5.17.: Klassendiagramm der Threads des MANVConnectors 76

109 6. Praktische Realisierung des Sensornetzes In diesem Kapitel wird die Implementierung des Sensornetzes, dabei auftretende Probleme sowie deren Lösungen, beschreiben Hardware Nachfolgend wird die praktische Umsetzung der zwei verschiedenen Hardwarekomponenten, also des MANV-USB-Sticks (Abbildung 6.1) und der MANVNode (Abbildung 6.2) beschrieben. In beiden Fällen musste hierzu ein ZigBit-Modul mit einer anderen Hardwarekomponente verbunden werden. Dies kann grundsätzlich entweder ü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 weiterer Peripherie dient. UART war hingegen vor allem als serielle Schnittstellen an PCs verbreitet, und wurde hauptsächlich für die Anbindung von Modems verwendet. Heutzutage wurde diese Schnittstelle weitestgehend von USB verdrängt. Beim Einsatz der SerialNet-Firmware scheidet die Anbindung über SPI jedoch aus, da dies von der Firmware nicht unterstützt wird 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 Verfügung steht, mit deren Hilfe ein UART an

110 6. Praktische Realisierung des Sensornetzes einen USB-Bus angebunden werden kann. Auf Seiten des Betriebssystems präsentiert sich der IC wie ein serieller Port und kann softwareseitig wie ein solcher angesprochen werden. Die Firma Embedded Projects bietet mit der USB-UART-Bridge eine fertige Lösung an, auf der ein entsprechender IC, ein Spannungsregler fü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 aufgelötet. Diese Platine kann nun selbst mit Hilfe einer Stiftleiste huckepack auf die USB-UART-Bridge aufgelötet werden, um die nötige Formstabilität zu erhalten Herstellung und Bestückung der Platine der MANV- Node Auch bei der MANVNode erfolgt eine Anbindung des ZigBit-Moduls über UART. Hierbei muss beachtet werden, dass der UART auch für das Flashen des Microcontrollers benötigt wird. Daher verfügt die Platine über eine Reihe von Jumpern, mit denen das ZigBit-Modul vom UART abgetrennt werden kann. Der ADuC-7026-Mikrocontroller benötigt drei 470 nf-kondensatoren zur Stabilisierung der Stromversorgung. Diese waren in den ersten beiden Versionen der Platine zu weit vom Mikrocontroller entfernt aufgebracht worden, was dazu führte, dass der Mikrocontroller beim Flashvorgang, dazu neigte, spontan abzustürzen. Dieser Fehler konnte durch die Verringerung des Abstandes zwischen Mikrocontroller und Kondensatoren behoben werden Firmware Die Firmware des Erste-Hilfe-Sensors wurde um einen Treiber für das ZigBit-Modul ergänzt. Die Firmware wurde in der Programmiersprache C geschrieben, und setzt direkt auf die Hardware des ADuC auf. Es wurde lediglich die von Rowley Crossworks angebotene Standardbibliothek verwendet, die einige praktische Funktionen wie Stringmanipulation, einen Interrupthandler und einen fertigen Startup-Code bietet. Die Entwicklung von Software für einen Microcontroller zeichnet sich durch die Abwesenheit eines Betriebssystems aus. Ein Großteil der Funktionalität, die man von der Entwicklung von Software für einen gewöhnlichen Mikrocomputer gewohnt ist, ist 78

111 6.2. Firmware Abbildung 6.1.: MANV-USB-Stick. schlichtweg nicht vorhanden. Hier sind insbesondere eine automatische Speicherverwaltung sowie Threads und Prozesse zu erwa hnen. Da der Erste-Hilfe-Sensor viele Aufgaben gleichzeitig erfu llen muss, stellt dies eine ernst zu nehmende Herausforderung dar. Das Problem wurde durch ein Interrupt-getriebenes Programmiermodell gelo st. Zu beachten sind hierbei die sehr beschra nkten Ressourcen des Mikrocontrollers. Insbesondere der Speicher ist mit 16 kb sehr knapp bemessen. 79

l Wireless LAN Eine Option für Firmennetzwerke der Druckereibranche? WLAN Eine Option für Unternehmen? Komponenten eines WLAN-Netzwerks

l Wireless LAN Eine Option für Firmennetzwerke der Druckereibranche? WLAN Eine Option für Unternehmen? Komponenten eines WLAN-Netzwerks l Wireless LAN Eine Option für Firmennetzwerke der Druckereibranche? BU Wuppertal FB E 2005 Jens Heermann Svend Herder Alexander Jacob 1 WLAN Eine Option für Unternehmen? Vorteile durch kabellose Vernetzung

Mehr

Wireless Personal Area Networks Spezielle Techniken der Rechnerkommunikation

Wireless Personal Area Networks Spezielle Techniken der Rechnerkommunikation Humboldt Universität zu Berlin Institut für Informatik Wireless Personal Area Networks Spezielle Techniken der Rechnerkommunikation Jörg Pohle, pohle@informatik.hu-berlin.de Daniel Apelt, apelt@informatik.hu-berlin.de

Mehr

Wireless LAN. nach IEEE 802.11

Wireless LAN. nach IEEE 802.11 Wireless LAN nach IEEE 802.11 Entstanden im Rahmen der Vorlesung LNWN II im Sommersemester 2002 INHALTSVERZEICHNIS 1 WIRELESS LAN NACH DEM IEEE 802.11 STANDARD 3 1.1 IEEE 802.11 3 1.2 IEEE 802.11B 3 1.3

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage 1. HANDLUNGSSCHRITT Wireless Local Area Network kabelloses lokales Netzwerk Aufgabe 14 Vorteile: einfache Installation, bequeme Nutzung durch mobile Geräte (z. B. Notebooks oder Tablet-PCs), geringe Kosten,

Mehr

Genereller Aufbau von Funknetzen. WLAN: IEEE 802.11b. Drahtloses Ethernet. Entwurfsziele für drahtlose Netze (WLAN/WPAN)

Genereller Aufbau von Funknetzen. WLAN: IEEE 802.11b. Drahtloses Ethernet. Entwurfsziele für drahtlose Netze (WLAN/WPAN) L apto p L apto p L apto p Entwurfsziele für drahtlose Netze (WLAN/WPAN) weltweite Funktion möglichst geringe Leistungsaufnahme wegen Batteriebetrieb Betrieb ohne Sondergenehmigungen bzw. Lizenzen möglich

Mehr

ComputeriaUrdorf «Sondertreff»vom30. März2011. Workshop mit WLAN-Zugriff auf das Internet

ComputeriaUrdorf «Sondertreff»vom30. März2011. Workshop mit WLAN-Zugriff auf das Internet ComputeriaUrdorf «Sondertreff»vom30. März2011 Workshop mit WLAN-Zugriff auf das Internet 30. März 2011 Autor: Walter Leuenberger www.computeria-urdorf.ch Was ist ein (Computer-)Netzwerk? Netzwerk-Topologien

Mehr

1. Java Grundbegriffe

1. Java Grundbegriffe 1. Java Grundbegriffe Geschichte von Java Programmieren mit Java Interpretieren vs. Kompilieren Java Byte-Code Jave Virtual Machine Arbeitsmaterialien Allgemeine Informatik 2 SS09 Folie 1.1 Java, eine

Mehr

Computeria Urdorf «Sondertreff» vom 7. November 2012. Workshop. auf das Internet

Computeria Urdorf «Sondertreff» vom 7. November 2012. Workshop. auf das Internet Computeria Urdorf «Sondertreff» vom 7. November 2012 Workshop mit WLAN-Zugriff auf das Internet 7. November 2012 Autor: Walter Leuenberger www.computeria-urdorf.ch Was ist ein (Computer-)Netzwerk? Netzwerk-Topologien

Mehr

Embedded Linux gnublin Board Programmieren Sonstiges. Embedded Linux am Beispiel des Gnublin-Boards

Embedded Linux gnublin Board Programmieren Sonstiges. Embedded Linux am Beispiel des Gnublin-Boards Embedded Linux am Beispiel des Gnublin-Boards Was ist Embedded Linux? Wikipedia Als Embedded Linux bezeichnet man ein eingebettetes System mit einem auf dem Linux-Kernel basierenden Betriebssystem. In

Mehr

R e m o t e A c c e s s. Cyrus Massoumi

R e m o t e A c c e s s. Cyrus Massoumi R e m o t e A c c e s s Präsentation im Seminar Internet-Technologie im Sommersemester 2008 von Cyrus Massoumi I n h a l t Was versteht man unter Remote Access Unsichere Remotezugriffe TELNET Remote Shell

Mehr

Fachbereich Medienproduktion

Fachbereich Medienproduktion Fachbereich Medienproduktion Herzlich willkommen zur Vorlesung im Studienfach: Grundlagen der Informatik I USB Universal serial bus (USB) Serielle Datenübertragung Punkt-zu-Punkt Verbindungen Daten und

Mehr

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise Matthias Hofherr WLAN-Sicherheit Professionelle Absicherung von 802.11-Netzen Heise 5 Bevor man einen genaueren Blick auf die Sicherheitsmechanismen von Netzwerken auf Basis des Standards 802.11 wirft,

Mehr

Always Best Connected: Das ABC der drahtlosen Kommunikation an der Universität Karlsruhe

Always Best Connected: Das ABC der drahtlosen Kommunikation an der Universität Karlsruhe Always Best Connected: Das ABC der drahtlosen Kommunikation an der Universität Karlsruhe Vortrag zum Stadtgeburtstag 2004 der Stadt Karlsruhe Prof. Dr. Hannes Hartenstein und Dipl.-Ing. Willi Fries Universität

Mehr

Diplomarbeit. Konzeption einer Entwicklungsplattform für Embedded Linux auf Basis der ARM9 Technologie. von. Andreas Bießmann. 20.

Diplomarbeit. Konzeption einer Entwicklungsplattform für Embedded Linux auf Basis der ARM9 Technologie. von. Andreas Bießmann. 20. In Zusammenarbeit mit Diplomarbeit Konzeption einer Entwicklungsplattform für Embedded Linux auf Basis der ARM9 Technologie von Andreas Bießmann 20. Januar 2008 Erstprüfer: Zweitprüfer: Firmenbetreuer:

Mehr

MULTINETWORKING MEHR ALS NUR EIN NETZWERK. Oktober 2010

MULTINETWORKING MEHR ALS NUR EIN NETZWERK. Oktober 2010 MULTINETWORKING MEHR ALS NUR EIN NETZWERK. Oktober 2010 1 Seite 1 UNTERNEHMEN SYSTEM- KOMPONENTEN REFERENZEN KONTAKT 2 Seite 2 WAS BEDEUTET MULTINETWORKING? EIN HOHES MASS AN FLEXIBILITÄT. JEDER DENKBARE

Mehr

WLAN Drahtloses Netzwerk

WLAN Drahtloses Netzwerk WLAN Drahtloses Netzwerk Florian Delonge & Jürgen Thau AUGE e.v. 18. Dezember 2004 WLAN (F. Delonge, J. Thau) (1) Wireless LAN, das drahtlose Netzwerk Inhalt: Überblick WLAN Vergleich WLAN / Bluetooth

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

54 Mbit OpenWRT Dual-Radio Outdoor WLAN Basis

54 Mbit OpenWRT Dual-Radio Outdoor WLAN Basis www.ddlx.ch ALLNET ALL0305 54 Mbit OpenWRT Dual-Radio Outdoor WLAN Basis OpenWRT Betriebssystem wetterfestes IP68 Gehäuse 2 Funkmodule mit 2,4 und 5 GHz integrierter Blitzschutz www.allnet.de Der ALLNET

Mehr

Lowestcost Wireless Webserver

Lowestcost Wireless Webserver Lowestcost Wireless Webserver Prof. Alexander Klapproth, Daniel Käslin, Thomas Peter Hochschule für Technik und Architektur Luzern CH-6048 Horw - Schweiz Einführung Die Wireless-Welt ist in immer schnelleren

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Vortrag zur Studienarbeit. Entwicklung eines HITAG 1 Kartenlesers. 21. April 2005

Vortrag zur Studienarbeit. Entwicklung eines HITAG 1 Kartenlesers. 21. April 2005 Vortrag zur Studienarbeit Entwicklung eines HITAG 1 Kartenlesers 21. April 2005 Thimo Eichstädt T. Eichstädt 21. April 2005 Eine kurze Einleitung Durchführung Studienarbeit wurde durchgeführt bei der Firma

Mehr

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen Gliederung 1. Was ist Wireshark? 2. Wie arbeitet Wireshark? 3. User Interface 4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen 1 1. Was

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Netduino Mikroprozessor für.net Entwickler

Netduino Mikroprozessor für.net Entwickler Netduino Mikroprozessor für.net Entwickler Patrick Herting Softwareentwickler BlueTem Software GmbH Blog E-Mail www.wdev.de pher@live.de Ablaufplan - Theorieteil Was ist der Netduino? Welche Modelle gibt

Mehr

Merkmale: Spezifikationen:

Merkmale: Spezifikationen: High-Power Wireless AC1200 Dual-Band Gigabit PoE Access Point zur Deckenmontage Rauchmelderdesign, 300 Mbit/s Wireless N (2,4 GHz) + 867 Mbit/s Wireless AC (5 GHz), WDS, Wireless Client Isolation, 26 dbm

Mehr

Das Bluetooth Handbuch

Das Bluetooth Handbuch Telekommunikation Jörg Franz Wollert Das Bluetooth Handbuch Technologie Software Einsatzfelder Systementwicklung Wettbewerb Mit 213 Abbildungen Franzis Inhalt 1 Bluetooth - Übersicht 15 1.1 Wo steht Bluetooth?

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

Quelle: www.roewaplan.de. Stand April 2002

Quelle: www.roewaplan.de. Stand April 2002 Wireless LAN Quelle: www.roewaplan.de Stand April 2002 LAN / 1 Wireless LAN Ein Überblick RÖWAPLAN Ingenieurbüro - Unternehmensberatung Datennetze und Kommunikationsnetze Inhalt Warum WLAN? Standard Planung

Mehr

Dateiübertragung mit ProComm Plus (Posten 6)

Dateiübertragung mit ProComm Plus (Posten 6) Dateiübertragung mit ProComm Plus (Posten 6) Einleitung Um die Zeit optimal ausnutzen zu können und nicht im wenig Benutzerfreundlichen MS-Dos zu verweilen, wurde der Versuch mit dem Programm ProComm Plus

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Arduino. Die gesteuerte Open Design Revolution. UserCon 2012 15. Januar 2012, MfK /AXL für Hackerspace FFM

Arduino. Die gesteuerte Open Design Revolution. UserCon 2012 15. Januar 2012, MfK /AXL für Hackerspace FFM 1 Arduino Die gesteuerte Open Design Revolution UserCon 2012 15. Januar 2012, MfK /AXL für Hackerspace FFM Illustration mit Genehmigung von JamesProvost.com Übersicht 2 Idee und Motivation Was ist ein

Mehr

S a t S e r v i c e Gesellschaft für Kommunikationssysteme mbh

S a t S e r v i c e Gesellschaft für Kommunikationssysteme mbh sat-nms Universal Network Management and Monitoring & Control System for Multimedia Ground Terminals Enhancement and Hardware Extension SatService GmbH Hardstraße 9 D- 78256 Steißlingen Tel 07738-97003

Mehr

EzUHF JR Modul Handbuch Ergänzung

EzUHF JR Modul Handbuch Ergänzung EzUHF JR Modul Handbuch Ergänzung Jänner 2014 1 Einleitung Glückwunsch zum Kauf Ihres EzUHF 'JR' Sender-Modules. Dieses Handbuch ist eine Ergänzung zu EzUHF Steuerung, Übersicht & Betrieb welches von der

Mehr

WLAN Hintergründe und Betrieb unter Linux

WLAN Hintergründe und Betrieb unter Linux Vortragsreihe der LUG Tübingen 04. Mai 2004 Ulrich Ölmann WLAN Hintergründe und Betrieb unter Linux Gliederung des Vortrags Einleitung IEEE 802.11 Schnittstelle zu Linux Praktische Beispiele Zusammenfassung

Mehr

W-LAN - Sicherheit. Cornelia Mayer Andreas Pollhammer Stefan Schwarz. 31. Jänner 2014 1 / 27

W-LAN - Sicherheit. Cornelia Mayer Andreas Pollhammer Stefan Schwarz. 31. Jänner 2014 1 / 27 Cornelia Mayer Andreas Pollhammer Stefan Schwarz 31. Jänner 2014 1 / 27 Gliederung 1 W-LAN - Sicherheit Angriffe in Hotspots WEP WPA/WPA2 2 / 27 Angriffe in Hotspots Angriffe in Hotspots Angriffsarten:

Mehr

LEDs Stromversorgung WLAN Link/Aktivität LAN Link/Aktivität Link/Aktivität

LEDs Stromversorgung WLAN Link/Aktivität LAN Link/Aktivität Link/Aktivität Wireless 150N Outdoor Range Extender / Access Point Mehrere SSIDs, Wireless Client isolation, Bridge, Repeater, WDS, Passives PoE, integrierte 12dBi-Antenne Part No.: 525497 Merkmale: Bis zu 150 Mbit/s

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Grundlagen Vernetzung am Beispiel WLAN 1 / 6. Aufbau

Grundlagen Vernetzung am Beispiel WLAN 1 / 6. Aufbau Grundlagen Vernetzung am Beispiel WLAN 1 / 6 Peer-to Peer-Netz oder Aufbau Serverlösung: Ein Rechner (Server) übernimmt Aufgaben für alle am Netz angeschlossenen Rechner (Clients) z.b. Daten bereitstellen

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

DC-1394 PCIe. IEEE 1394 FireWire TM PCIe Card. Windows 2000 / 2003 / 2008 Windows XP / Vista / 7

DC-1394 PCIe. IEEE 1394 FireWire TM PCIe Card. Windows 2000 / 2003 / 2008 Windows XP / Vista / 7 DC-1394 PCIe IEEE 1394 FireWire TM PCIe Card Wichtige Information zur Datensicherheit Vor der Installation und bei Änderungen der Konfiguration des DC-1394 PCIe sollte unbedingt eine Datensicherung durchgeführt

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005

Motivation Sicherheit. WLAN Sicherheit. Karl Unterkalmsteiner, Matthias Heimbeck. Universität Salzburg, WAP Präsentation, 2005 Universität Salzburg, WAP Präsentation, 2005 Gliederung 1 WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken Statistische Untersuchen 2 Gliederung WLAN die neue drahtlose Welt Gefahren in WLAN Netzwerken

Mehr

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Roboter programmieren mit NXC für Lego Mindstorms NXT 1. Auflage Roboter programmieren mit NXC für Lego Mindstorms NXT schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Verlag

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Steigerung der Energieeffizienz einer integrierten Heimnetzwerkinfrastruktur

Steigerung der Energieeffizienz einer integrierten Heimnetzwerkinfrastruktur 15. ITG-Fachtagung für Elektronische Medien Steigerung der Energieeffizienz einer integrierten Heimnetzwerkinfrastruktur Armin Wulf, Falk-Moritz Schaefer, Rüdiger Kays Überblick Netzwerktopologie im Smart

Mehr

16. Elektronik-Stammtisch: Logic Analyzer

16. Elektronik-Stammtisch: Logic Analyzer 16. Elektronik-Stammtisch: Logic Analyzer Axel Attraktor e.v. 6. Mai 2013 Axel (Attraktor e.v.) 16. Elektronik-Stammtisch 6. Mai 2013 1 / 40 Was ist ein Logic Analyzer Messgerät für digitale Signale Spannungsverläufe

Mehr

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein:

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: 1. Access Point im Personal Mode (WEP / WPA / WPA2) 1.1 Einleitung Im Folgenden wird die Konfiguration des Access Point Modus gezeigt. Zur Absicherung der Daten werden die verschiedenen Verschlüsselungsalgorithmen

Mehr

HOB Remote Desktop VPN

HOB Remote Desktop VPN HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB Remote Desktop VPN Sicherer Zugang mobiler Anwender und Geschäftspartner

Mehr

InfiniBand Low Level Protocol

InfiniBand Low Level Protocol InfiniBand Low Level Protocol Seminar Ausgewählte Themen in Hardwareentwurf und Optik HWS 08 17.12.2008 Andreas Walter Universität Mannheim Inhalt Motivation InfiniBand Basics Physical Layer IB Verbs IB

Mehr

ZigBeeRouter Jan Gampe, Sebastian Flothow

ZigBeeRouter Jan Gampe, Sebastian Flothow ZigBeeRouter Jan Gampe, Sebastian Flothow 1 Übersicht Ziel Ausgangslage / Hardware Router ZigBee Status Ausblick Fragen dürfen jederzeit gestellt werden 2 Ziel DSL-Router um ZigBee-Hardware erweitern Programmierschnittstelle

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Virtual Access Points Michael Roßberg

Virtual Access Points Michael Roßberg Virtual Access Points Michael Roßberg Übersicht Einleitung Definition und Motivation 802.11 Management Implementierungstechniken Zusammenfassung Quellen Einleitung 802.11 einer der erfolgreichsten Standards

Mehr

Single-Ended -Datenübertragung (Asymmetrische Übertragung)

Single-Ended -Datenübertragung (Asymmetrische Übertragung) Datenübertragung 1 Asymmetrische Datenübertragung ( Single ended ) und symmetrische (differenzielle) Datenübertragung Parallele und serielle Übertragung Anhang Topologien Datenübertragungssysteme: Beispiele

Mehr

WLAN Best Practice. Von der Anforderung bis zum Betrieb in Gebäuden. 26.03.2015. Willi Bartsch. Netze BW GmbH Teamleiter NetzwerkService

WLAN Best Practice. Von der Anforderung bis zum Betrieb in Gebäuden. 26.03.2015. Willi Bartsch. Netze BW GmbH Teamleiter NetzwerkService WLAN Best Practice Von der Anforderung bis zum Betrieb in Gebäuden. 26.03.2015 Willi Bartsch Netze BW GmbH Teamleiter NetzwerkService Ein Unternehmen der EnBW Agenda WLAN Anforderungen Umfeldanalyse Ausblick

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen Rodrigo Nebel Institut für Informatik Lehrstuhl für Rechnernetze und Kommunikationssysteme (Informatik 7) Friedrich-Alexander-Universität

Mehr

Sniffer. Electronic Commerce und Digitale Unterschriften. Proseminar Leiter: Dr. Ulrich Tamm Vortragender: Stefan Raue Datum: 29.06.2004.

Sniffer. Electronic Commerce und Digitale Unterschriften. Proseminar Leiter: Dr. Ulrich Tamm Vortragender: Stefan Raue Datum: 29.06.2004. Sniffer Proseminar: Electronic Commerce und Digitale Unterschriften Proseminar Leiter: Dr. Ulrich Tamm Vortragender: Stefan Raue Datum: 29.06.2004 Gliederung Was sind Sniffer? Einführung Ethernet Grundlagen

Mehr

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1 Telekommunikationsnetze 2 Breitband ISDN Lokale Netze Internet Martin Werner WS 2009/10 Martin Werner, November 09 1 Breitband-ISDN Ziele Flexibler Netzzugang Dynamische Bitratenzuteilung Effiziente Vermittlung

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Whitepaper Einführung in Mesh Netzwerke www.airberry.com

Whitepaper Einführung in Mesh Netzwerke www.airberry.com Stand: 05.06.2012 Mesh Netzwerke existieren seit über 40 Jahren - angefangen als mobile Funklösung für militärische Anwendungen in den USA wurden sie insbesondere seit Anfang 2000 auch für die zivile Vernetzung

Mehr

Informationen zur Firmware Release 4.32 für FPS-WDSL Router

Informationen zur Firmware Release 4.32 für FPS-WDSL Router Informationen zur Firmware Release 4.32 für FPS-WDSL Router Die Firma FPS InformationsSysteme GmbH übernimmt keine Haftung für nicht von der Fa. FPS entwickelte Software. Verwendung von Fremdsoftware geschieht

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Prinzipien der Signalaufbereitung im UMTS Mobilfunk

Prinzipien der Signalaufbereitung im UMTS Mobilfunk Prinzipien der Signalaufbereitung im UMTS Mobilfunk Darko Rozic Lehrstuhl für Messtechnik Universität Wuppertal Einführung Seit der Einführung des Global System for Mobile Communications (GSM) um 1990

Mehr

Mikrocontroller Grundlagen. Markus Koch April 2011

Mikrocontroller Grundlagen. Markus Koch April 2011 Mikrocontroller Grundlagen Markus Koch April 2011 Übersicht Was ist ein Mikrocontroller Aufbau (CPU/RAM/ROM/Takt/Peripherie) Unterschied zum Mikroprozessor Unterschiede der Controllerarten Unterschiede

Mehr

DC-FW400 SE. 3+1 Port IEEE 1394 FireWire TM PCI-Controller

DC-FW400 SE. 3+1 Port IEEE 1394 FireWire TM PCI-Controller DC-FW400 SE 3+1 Port IEEE 1394 FireWire TM PCI-Controller Wichtige Information zur Datensicherheit Vor der Installation und bei Änderungen der Konfiguration des DC-FW400 SE sollte unbedingt eine Datensicherung

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

POB-Technology Dokumentation. POB-Technology Produkte. Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13

POB-Technology Dokumentation. POB-Technology Produkte. Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13 POB-Technology Produkte Deutsche Übersetzung von roboter-teile.de Alle Rechte vorbehalten Seite 1 von 13 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... 2 Einführung...4 POB-EYE... 5 POB-LCD128...

Mehr

Installationsanleitung für den ALL0233

Installationsanleitung für den ALL0233 VORWORT Dieses Dokument beschreibt die Installation des ALLNET Draft N WLAN USB Sticks ALL0233. WICHTIGE SICHERHEITSHINWEISE: Bitte achten Sie aus Sicherheitsgründen bei der Installation und De-Installation

Mehr

Check_MK rail1 - Handbuch

Check_MK rail1 - Handbuch Check_MK rail1 - Handbuch i Check_MK rail1 - Handbuch Check_MK rail1 - Handbuch ii Inhaltsverzeichnis 1 Schnellstart-Anleitung 1 2 Lieferumfang 3 3 Anforderungen an die SD-Karte 4 4 Informationen zur SD-Karte

Mehr

Informationen zur. LCOS Software Release 3.36. für LANCOM Router und Wireless LAN Access Points

Informationen zur. LCOS Software Release 3.36. für LANCOM Router und Wireless LAN Access Points Informationen zur LCOS Software Release 3.36 für LANCOM Router und Wireless LAN Access Points Copyright (c) 2002-2004 LANCOM Systems GmbH, Würselen (Germany) Die LANCOM Systems GmbH übernimmt keine Gewähr

Mehr

Konzept eines WLAN Gateways unter Benutzung von VPN und Zertifikaten

Konzept eines WLAN Gateways unter Benutzung von VPN und Zertifikaten Konzept eines WLAN Gateways unter Benutzung von VPN und Zertifikaten Labor für Kommunikationstechnik und Datensicherheit FH Köln - Campus Gummersbach Mentor: Prof. Karsch Referenten: Daniel Jedecke Manuel

Mehr

Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen?

Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen? Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen? JULIA SCHILLING SSV EMBEDDED SYSTEMS HEISTERBERGALLEE 72 D-30453 HANNOVER WWW.SSV-EMBEDDED.DE Ethernet

Mehr

RACFBroker/z. Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP. RACFBroker/z ist ein Produkt der

RACFBroker/z. Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP. RACFBroker/z ist ein Produkt der RACFBroker/z Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP RACFBroker/z ist ein Produkt der XPS Software GmbH Eching RACFBroker/z XPS Software GmbH Untere Hauptstr. 2

Mehr

Von Bluetooth zu IEEE 802.15.4/Zigbee

Von Bluetooth zu IEEE 802.15.4/Zigbee Standards drahtloser Übertragung: Von Bluetooth zu IEEE 802.15.4/Zigbee Seminar Smart Environments SS04 Michael Bürge 1.Juni 2004 Betreuer: Christian Frank Agenda Einleitung Motivation Drahtlose Datenübertragungsverfahren

Mehr

ATB Ausbildung Technische Berufe Ausbildungszentrum Klybeck

ATB Ausbildung Technische Berufe Ausbildungszentrum Klybeck W-LAN einrichten Access Point Konfiguration Diese Anleitung gilt für den Linksys WAP54G. Übersicht W-LAN einrichten... 1 Access Point Konfiguration... 1 Übersicht... 1 Vorbereitung... 1 Verbindung aufnehmen...

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Praktikum Rechnernetze

Praktikum Rechnernetze Praktikum Rechnernetze Prof. Dr. Uwe Heuert Hochschule Merseburg (FH) 1 Inhaltsverzeichnis Praktikum... 1 Rechnernetze... 1 Inhaltsverzeichnis... 2 Einführung... 4 Versuche... 8 Passwörter... 11 Versuch

Mehr

Einführung zu den Übungen aus Softwareentwicklung 1

Einführung zu den Übungen aus Softwareentwicklung 1 Einführung zu den Übungen aus Softwareentwicklung 1 Dipl.-Ing. Andreas Riener Universität Linz, Institut für Pervasive Computing Altenberger Straße 69, A-4040 Linz riener@pervasive.jku.at SWE 1 // Organisatorisches

Mehr

Das Netzwerk einrichten

Das Netzwerk einrichten Das Netzwerk einrichten Für viele Dienste auf dem ipad wird eine Internet-Verbindung benötigt. Um diese nutzen zu können, müssen Sie je nach Modell des ipads die Verbindung über ein lokales Wi-Fi-Netzwerk

Mehr

WLAN-Hotspots. Medienengineering Teledienste Prüfung Light. Ronald Nitschke Sebastian Ziegel Christian Loclair. www.802.11b. 802.11b.de.ms.de.

WLAN-Hotspots. Medienengineering Teledienste Prüfung Light. Ronald Nitschke Sebastian Ziegel Christian Loclair. www.802.11b. 802.11b.de.ms.de. WLAN-Hotspots Medienengineering Teledienste Prüfung Light Ronald Nitschke Sebastian Ziegel Christian Loclair www.802.11b 802.11b.de.ms.de.ms Überblick IEEE 802.11b/g Roaming Motivation für Hotspots Anbieter

Mehr

Funknetzwerke und Sicherheit in Funknetzwerken. Dipl.-Inf. (FH) Hendrik Busch PING e.v. Revision 8, 31.8.2006

Funknetzwerke und Sicherheit in Funknetzwerken. Dipl.-Inf. (FH) Hendrik Busch PING e.v. Revision 8, 31.8.2006 Funknetzwerke und Sicherheit in Funknetzwerken Dipl.-Inf. (FH) Hendrik Busch PING e.v. Revision 8, 31.8.2006 Was ist Wireless LAN? Viele Namen, eine Technologie Funknetzwerk WLAN Wireless LAN WaveLAN IEEE

Mehr

IP Adressen & Subnetzmasken

IP Adressen & Subnetzmasken IP Adressen & Subnetzmasken Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Wireless-LAN USB Stick

Wireless-LAN USB Stick Wireless-LAN USB Stick 150 Mbps Modell: LW-05 LW-UWD-02 Bedienungsanleitung Quick Guide Bitte lesen Sie diese Anleitung für eine ordnungsgemäße Bedienung sorgfältig durch und heben Sie sie zum Späteren

Mehr

StarterKit Embedded Control SC13 + DK51. From the electronic to the automation

StarterKit Embedded Control SC13 + DK51. From the electronic to the automation SC13 + DK51 From the electronic to the automation 21.10.2005 No. 1 /14 Entwicklungssystem für Embedded Controller Applikationsspezifische Komponenten ergänzen. Ethernet-Anbindungen seriellen Schnittstellen

Mehr

Ubiquiti Nanostation 2, M2 bzw. Bullet 2, 2HP, M2HP für HAMNET Zugang mit Linksys Router WRT54GL

Ubiquiti Nanostation 2, M2 bzw. Bullet 2, 2HP, M2HP für HAMNET Zugang mit Linksys Router WRT54GL Einleitung Die Nanostation bzw. der Bullet aus dem Hause Ubiquiti sind die wohl einfachste Lösung um Zugang zum HAMNET zu erhalten. Direkte Sicht zum Accesspoint (AP) immer vorausgesetzt. Technische Daten

Mehr

SOLUCON GATEWAY WLAN. Artikel-Nr.: 01105505 PRODUKTEIGENSCHAFTEN TECHNISCHE EIGENSCHAFTEN LOGISTISCHE EIGENSCHAFTEN

SOLUCON GATEWAY WLAN. Artikel-Nr.: 01105505 PRODUKTEIGENSCHAFTEN TECHNISCHE EIGENSCHAFTEN LOGISTISCHE EIGENSCHAFTEN SOLUCON GATEWAY WLAN Artikel-Nr.: 01105505 Gateway zur verschlüsselten Kommunikation der per Funk verbundenen -Hardware mit der SOLUCON Plattform über eine kabellose Internetverbindung. Stellt die sichere

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note:

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note: Name: Punkte: Note: Hinweise für das Lösen der Aufgaben: Zeit: 95 min. Name nicht vergessen! Geben Sie alle Blätter ab. Die Reihenfolge der Aufgaben ist unabhängig vom Schwierigkeitsgrad. Erlaubte Hilfsmittel

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 5: 7.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

Ankopplung GSM Interface an FAT2002 (GSM-Option)

Ankopplung GSM Interface an FAT2002 (GSM-Option) Ankopplung GSM Interface an FAT2002 (GSM-Option) ab Firmware-Version 4.24.10.1 Allgemeines Das FAT2002 stellt eine Übermittlung von Meldungen per SMS bereit. Die Meldungen aus der BMZ werden im FAT gemäß

Mehr

Wireless N 300Mbps Access Point

Wireless N 300Mbps Access Point Wireless N 300Mbps Access Point WL0053 Bedienungsanleitung Inhaltsverzeichnis 1.0 Sicherheitshinweise 2.0 Einführung 3.0 Inbetriebnahme 4.0 Netzwerk Konfiguration 5.0 CE Erklärung 1.0 Sicherheitshinweise

Mehr