Spezifikation - Technische Informatik / Eingebettete Systeme

1
Seminar zum Programmierprojekt (TI) Sommersemester 2007
(Lehrstuhl für Technische Informatik)
Aufgabe A2: Anleitung und Fragen
Einführung in Sensornetze. Der Sensor/Aktor Knoten
BTnode
Sensornetzwerke
Sensornetzwerke bestehen aus einer Menge von Sensorknoten, die über ein Netzwerk verbunden sind. Die einzelnen Sensoren sind meist direkt an die Sensorknoten angeschlossen.
Die möglichen Aufgaben eines Sensorknotens sind u. a.
•
Messen einfacher physikalischer Parameter
•
Speichern der Sensordaten
•
Bearbeiten von Sensordaten
•
Weiterleiten der Sensordaten
Die zunehmende Miniaturisierung von Prozessoren führte zu extrem kleinen, kostengünstigen und autonomen Sensorknoten, die drahtlos miteinander kommunizieren und sich selbständig organisieren. Diese können beispielsweise in großer Zahl und in einem großen Gebiet
ausgebracht werden und überwachen ihre Umgebung solange, bis ihre Energiereserven erschöpft sind. Die Attribute klein, billig, in großer Zahl verfügbar und autonom haben die Idee
unter dem Schlagwort smart dust (intelligenter Staub) bekannt gemacht.
Sensor-Netzwerke können als preiswerte Alternative zu klassischen Sensoranordnungen dienen, wie sie etwa bei Testfahrten der Fahrzeugindustrie eingesetzt werden. Denkbar ist, dass
tausende von Sensorknoten in einem Gebiet von Interesse oder innerhalb eines Objektes platziert werden und Ad-hoc-Netzwerke bilden, die eine Überwachung komplexer physikalischer
Systeme gestatten. Somit würden sich Sensornetze besonders zur Überwachung großer Flächen eignen. Sie werden eingesetzt bei:
•
Militärischen Aufgaben
•
Umweltschutz durch Messung von Schadstoffkonzentrationen in Gewässern
•
Katastrophenschutz (frühzeitige Erkennung von Waldbränden, Lawinen, Tsunamis)
•
Tierbeobachtung mit Hilfe von Bewegungssensoren, oder mit Miniatur-Sendern, welche die Tiere tragen
•
Gebäude- oder Geländesicherung durch Erkennen von Geräuschen
Sensornetze übernehmen hauptsächlich Überwachungs- und Kontrollfunktionen. Falls die
Knoten zusätzlich mit Aktoren ausgestattet sind, können sie auch Steuerungsaufgaben übernehmen.
2
Der verwendete Sensor/Aktorknoten
Eine BTnode ist eine vielseitige, autonome, kabellose Datenübertragungs- und bearbeitungs-Plattform, die in ad-hoc- und Sensor-Netzwerken verwendet wird. Sie wurde an
der ETH Zürich entwickelt und liegt zurzeit in der Version 3.22 vor.
Abbildung 1: Die BTnode v3.22
Die Plattform besteht aus einem Bluetooth-Subsystem, einem Low-Power Funk-Subsystem
(Radio) und einem Mikrokontroller. Dank des Low-Power Radio ist die BTnode kompatibel
zu den Berkeley Mica2 Motes, die ebenfalls als Knoten in drahtlosen ad-hoc Netzwerken verwendet werden. Abbildung 1 zeigt eine BTnode v3.22.
Aufbau der BTnode
Das BTnode-System enthält den Mikrokontroller Atmel ATmega128l. Die neueste Version
beinhaltet ein neues Zeevo ZV4002 Bluetooth-System, welches bis zu 4 unabhängige Piconetze mit je 7 Slaves unterstützt. Zusätzlich wurde ein Chipcon CC1000 Funk-System integriert, was die Kompatibilität zu den „Mica2 Motes“ gewährleistet. Neben einem SRAM Modul gibt es ein 126 KB Flash ROM, sowie ein 4 KB EEPROM. Die Stromversorgung wird
entweder durch einen Gleichstromanschluss gesichert, kann aber auch durch 2 AA Batterien,
welche direkt in das BTnode eingesetzt werden, erfolgen. Die Stromzufuhr sowohl zum
Bluetooth-SXSystem, als auch zum CC1000 kann softwareseitig gesteuert werden. Durch die
sehr kleinen Maße von 58.15x32.5mm aufgesetzt auf einen 2 AA-Batterie-Halter, eignen sich
BTnodes hervorragend für den Einsatz in Sensor- und ad-hoc-Netzwerken. Bei Bedarf können die Funk-Subsysteme unabhängig voneinander oder auch gleichzeitig senden und empfangen, aber auch unabhängig voneinander vollständig ausgeschalten werden, was den Blindleistungs-Verbrauch des Gerätes nennenswert reduziert.
3
Abbildung 2: Aufbau der BTnode
Die technischen Daten des BTnode v3.22 im Überblick:
•
Atmel Atmega 128L (8 MHz @ 8 MIPS) Mikrokontroller
•
64 + 180 KB SRAM, 126 KB FLASH ROM, 4 KB EEPROM
•
Zeevo ZV4002 Bluetooth-Subsystem mit Unterstützung für AFH/SFH Scatternets,
Bluetooth v1.2 kompatibel
•
Chipcon CC1000 Low-Power Funk-Subsystem, ISM Band (433 - 915 MHz)
•
ISP, UART, SPI, I2C, GPIO, ADC Schnittstellen
•
Stromversorgung entweder durch 2 AA Batterien oder Gleichstrom Anschluss von 3,6
bis 5,0 V
•
Größe: 58,15 x 33 mm, aufgesetzt auf einen 2 AA Batterie-Halter
Abbildung 2 gibt einen Überblick über den Aufbau der BTnode.
Die BTnode System-Software ist ein einfaches Betriebssystem, aufgebaut aus interruptgesteuerten low-level Treibern und einem einfachen Dispatcher/Scheduler, um multiple
Threads behandeln zu können. Dieses Betriebssystem ist gut geeignet für Anwendungen
solch kleiner Netzwerkgeräte, die größtenteils aus einfachen Input/Output und Überwachungsanwendungen bestehen. Es gibt hier zwei Programmier-Modelle: Ein sequenzielles
Modell und ein Event-basiertes Model mit kooperativem Multitasking. Es gibt daher auch
verschiedene System-Software für beide Modelle. Das sequenzielle Modell erlaubt zwar die
genaue Kontrolle aller Ressourcen, führt aber zu erhöhtem Aufwand bei der AnwendungsProgrammierung. Dagegen bietet das Event-basierte Modell komfortable Funktionen für das
Ressourcen-Management, jedoch nur eingeschränkten Zugriff auf die Hardware Ressourcen.
Unterstützt werden die opensource BTnut System-Software und die Standard C Programmierung. BTnodes sind TinyOS kompatibel und unterstützen die AVR-GCC Tool Chain unter
Windows/Linux/MacOS/BSD. Nut/OS ist ein bewusst einfach gehaltenes EchtzeitBetriebssystem für kleine eingebettete Systeme die auf dem Atmel ATmega 128 Mikrokontroller basieren. Es stellt die wichtigsten Funktionen des Nut/Net TCP/IP Stacks zur Verfügung:
•
Kooperatives Multithreading
•
Events
4
•
Periodische und One-Shot Timer
•
Dynamische Speicherverwaltung
•
Interruptgesteuertes Stream I/O
Die Eigenschaften des TCP/IP Stacks sind:
•
Basisprotokolle ARP, IP, ICMP, UDP und TCP
•
Benutzerdefinierte Protokolle DHCP, DNS und HTTP
•
Socket API
•
Host, Net und default Routing
•
Interruptgesteuerter Ethernet-Treiber
NUT/OS ist modular aufgebaut, so dass nur die Module im finalen Kernel-Image zu finden
sind, die auch tatsächlich benötigt werden. Dies hat zur Folge, dass das Image des NUT/OS
sehr klein ist. Dies ist wünschenswert, da eingebettete Systeme über eingeschränkte Speicherkapazitäten verfügen. NUT/OS unterstützt kooperatives Multithreading, dadurch wird
das Scheduling vereinfacht. Der aktive Prozess gibt die Kontrolle an die CPU ab, sobald er
z.B. auf Ressourcen warten muss.
BTNUT/OS erweitert das herkömmliche NUT/OS Betriebssystem um BTnode-spezifische
Treiber und einen Bluetooth-Stack. BTNUT/OS besteht aus dem Systemkern, einer Reihe
von Bibliotheken, Include-Dateien und einer API-Dokumentation (Application Programming
Interface).
Der Suchassistent oder "Research Agent"
In Abbildung 3 ist die "Inquiry Prozedur" dargestellt. Bevor ein Bluetooth-Gerät eine Verbindung zu einem anderen Gerät aufbauen kann, muss es zunächst feststellen, ob sich ein BTGerät in seiner Kommunikationsreichweite befindet. Sobald also ein Bluetooth-fähiges Gerät
aktiviert wird, sendet dieses Suchsignale aus, um weitere Netzknoten zu finden. Dieses Gerät
übernimmt hier die Rolle eines Suchassistenten (Research Agent). Dies geschieht mittels der
Inquiry Prozedur (dt. Erkundigung, Anfrage). Der Inquiry Befehl ist die einzige broadcastähnliche Funktion im Bluetooth-Standard, die die Suche nach Bluetooth-Geräten in der Umgebung ermöglicht. Hierbei sendet das Gerät periodisch ID-Pakete aus, die einen so genannten Inquiry Access Code (IAC) enthalten und signalisiert den anderen Stationen damit, dass
nach ihnen gesucht wird. Das ID-Paket enthält keine Informationen über die sendende Quelle, wodurch die Anonymität gewahrt wird.
5
Abbildung 3: Inquiry Prozedur
Die ID-Pakete werden nacheinander auf verschiedenen Frequenzen gesendet. Dabei werden
die Frequenzen 3200-mal in der Sekunde gewechselt, um in kürzester Zeit so viel Frequenzen
wie möglich abzudecken und damit schnell Bluetooth-fähige Geräte zu entdecken. Als Initiator dieser Verbindung übernimmt dieses Gerät die Rolle des Masters.
Die Gegenseite (inquiry scanning device), also der Slave, wechselt die Frequenzen im Vergleich zum Master nur alle 1,28 Sekunden und somit langsamer. Diese unterschiedlichen Geschwindigkeiten im Frequenzwechsel führen dazu, dass sich früher oder später beide Geräte
auf derselben Frequenz befinden. Das Inquiry-scannende Gerät kann sich nicht nur auf einer
festen Frequenz befinden, da durch Interferenzen der Umgebung oder durch andere Sender
im ISM Band (z. B. WLAN) diese Frequenz gestört werden kann.
Auf die Inquiry-Nachricht antwortet der Slave mit einem "Frequency Hopping Synchronisation" Paket. Das Antwortpaket enthält die Informationen wie die Bluetooth MAC-Adresse,
sowie Informationen über den aktuellen Wert der Systemuhr und die Stärke des empfangenen
Inquiry Signals. Die MAC-Adresse ist die eindeutige Kennung des Gerätes und wird für die
Identifizierung der Kommunikationspartner benötigt. Zusätzlich kann man einem Gerät auch
einen Klartextnamen zuweisen.
Nach dem Inquiry erfolgt eine Page-Prozedur, die eine Verbindung zwischen dem Master
und dem Slave aufbaut. Befinden sich zwei Geräte bereits in einem Piconetz, so entfällt die
Inquiry-Prozedur.
Das Dienstangebot des Sensor/Aktorknotens BTnode
6
In unserem System bietet der Sensor/Aktorknoten Dienste an, die vom Mobilen Knoten (MK)
über Bluetooth aufgerufen werden können. Dafür soll der MK eine Verbindung mit dem Aktor/Sensorknoten öffnen und die entsprechende Kennung des Dienstes schicken. Der Knoten
soll in der Lage sein, diese Verbindung zu akzeptieren und die Kennung des Dienstes zu interpretieren. Dieser Prozess kann mit Hilfe der L2CAP-Schicht und des „Serial Port Profils“
von Bluetooth in der BTNode leicht implementiert werden.
L2CAP steht für Logical Link Control and Adaptation Protocol. Dieses Protokoll ist, wie in
der Abbildung 4 gezeigt, im Bluetooth Protokoll-Stack direkt über der HCI-Schnittstelle
(Host Controller Interface) angesiedelt. Es beruht auf dem Konzept von Channels.
Abbildung 4: L2CAP Schicht
Im Gegensatz zu einer Stream-Connection auf der HCI-Ebene, sendet und empfängt die
L2CAP-Schicht Pakete. Diese werden entweder zwischen L2CAP und HCI oder aber direkt
zwischen L2CAP und dem Link Manager ausgetauscht. Das Letztere ist der Fall auf Systemen ohne Host. L2CAP stellt verbindungsorientierte und verbindungslose Dienstleistungen
(Services) für Protokolle höherer Schichten zur Verfügung. Dies ermöglicht den Protokollen
höherer Ebenen Datenpakete (L2CAP Service Data Units, SDU) von bis zu 64 Kilobytes zu
empfangen und zu senden.
L2CAP unterstützt das Multiplexen zwischen den Services und den darüberliegenden Protokollen. Wenn ein Kommunikationskanal eingerichtet wird, wird das Multiplexen zum Routen
zwischen der Verbindungsanfrage und dem korrekten höheren Protokoll benutzt.
Zusammen mit dem L2CAP-Protokoll werden wir unsere Dienste über „Serial Port Profile
(SPP)“ anbieten. Das ist der Standard Operationsmodus in BTNodes. SPP erlaubt Bluetooth
Geräten RS232 (oder ähnliche) serielle Kabelverbindungen zu emulieren. Die von diesem
Profil überdeckten Szenarios zielen auf Legacy-Anwendungen, die Bluetooth als Kabelersatz
verwendet.
Wie in Abbildung 5 gezeigt, wird eine Abfrage von Diensten vom MK gestartet. Zuerst baut
der MK eine Verbindung mit die Sensor-/Aktorknoten auf, und schickt einen String ab. Dieses String soll vom Sensor-/Aktorknoten interpretiert werden als eine Anfrage für Dienste.
Der Sensor-/Aktorknoten antwortet dann mit einem String der alle Dienste beinhaltet. Die
Namen der Dienste sind durch Kommata getrennt (ohne Zwischenraum).
7
BT
Verbindung aufbauen
„SERVICES“
„LAMPE ANSCHALTEN,
LAMPE AUSCHALTEN“
Abbildung 5: Anfordern des Dienstangebots
ACHTUNG: Die Strings, die hier festgelegt werden, müssen mit dem MK abgestimmt werden, da sie vom MK interpretiert werden müssen.
Fragen
1. Was sind Sensornetze und wozu werden sie verwendet?
2. Wie bilden sich die Verbindungen in ad-hoc Netzwerken?
3. Was ist NUT/OS? Welche Erweiterung von NUT/OS führt zur Variante BTNUT/OS?
4. NUT/OS hat mehrere Charakteristika, die in modernen eingebetteten Systemen erwünscht sind. Erklären Sie die in NUT/OS verwendeten folgenden Konzepte:
a. Die NUT/OS hat einen "Small Footprint". Erläutern Sie diesen Begriff.
b. NUT/OS implementiert ein kooperatives Multithread Schema. Was bedeutet das?
Was ist der Unterschied zum "preemptive Multithread"?
c. NUT/OS ist Event-orientiert. Erklären Sie diesen Aspekt!
5. Erklären Sie anhand des Blockschaltbilds den Hardware-Aufbau der BTnodes.
6. Zu welcher BT-Klasse zählt die BTnode?
7. Für welche Anwendungen kann die BTnode eingesetzt werden?
8. Welches Betriebssystem wird für die BTnode verwendet?
9. Über welche Schnittstelle und in welchen Speicher wird das BTnode Programm geladen?
10. Erklären Sie die grundlegende Funktionalität des L2CAP Protokolls
8
Anhang
Literatur und Quellen
[1] http://oss.kernelconcepts.de/nutos/
[2] http://www.btnode.ethz.ch/
[3] http://www.btnode.ethz.ch/static_docs/doxygen/btnut/
[4] http://ethernut.de/en/software/index.html
[5] http://e-collection.ethbib.ethz.ch/ecol-pool/incoll/incoll_869.pdf