Home

Die Peer-Applikation

1. Abbildung 15 Informationsbasis Die Rolle des Peers besteht nun darin die bin ren Nachrichten des Ger te Controllers auszuwerten und entsprechend in die noch zu definierende Informationsbasis einzutragen Die Datenstruktur besteht bedingt durch das REST Prinzip aus einer Menge von eindeutig adressierbaren Ressourcen Es gilt nun zu definieren wie Knoten als Ressourcen modelliert werden Angelehnt an die MIB Struktur von SNMP w re eine baumartige Struktur denkbar Die Bl tter dieses Baumes w rden dann Ressourcen entsprechen Eine Ressource w re z B der gemessene Temperaturwert eines Sensors Im Folgenden ist ein Beispiel eines solchen Baumes angegeben 32 devices offline OBA5673A61511 present devices offline 0BA5673A61511 lastsample devices offline 0BA5673A6151 I lastvoltagel devices offline 0BA5673A 6151 I astvoltage2 devices offline 0OBA5673A 6151 I lastvoltage3 devices offline 0BA5673A 6151 I lastvoltage4 devices offline EFO4ABC323423 laststatechange devices offline EFO4ABC323423 devices offline EFO4ABC323423 pin1 level devices offline EF044BC323423 pinl state devices offline EFO4ABC323423 pin2 level devices offline EF044BC323423 pin2 state devices offline EF04ABC323423 pin3 level devices offline EF044BC323423 pin3 state devices offline EFO4ABC323423 pin4 level devices offline EF044BC323423 pin4 state devices online 0A9481EF61511 present devices online 0A9481EF61511I lastsample de
2. Peer Applikalien Garne Controller Klikrasentraller Abbildung 6 Knoten in der Gesamtstruktur Die erw hnten Knoten wurden so definiert dass diese einfachste elektronische Aufgaben erf llen k nnen Ausgegangen davon dass jede physikalische Gr e in elektrische Spannungen umgewandelt werden kann sollte die Wahl von AD Wandlern als unbedingt 34 notwendig erachtet werden Zwecks digitaler Ein und Ausgabe von Daten wird ein einfaches elektronisches MOSFET genutzt an dem zus tzlich die angelegte Spannung als High oder Low erfasst werden kann Somit kann man analoge Spannungswerte einlesen digitale Ausgabe mittels des MOSFET Schalters realisieren und zus tzlich noch digitale Eingaben erfassen Die zu implementierende Funktion des Ger tes wird schlussendlich auf Schaltkreisniveau realisiert In diesem Teil werden zur Verf gung stehende Produkte miteinander verglichen um schlussendlich eine geeignete Wahl zu treffen Laut den Architekturentscheidungen sollten diese Ger te busf hig sein und zugleich wenig Kosten verursachen Im Folgenden soll die Wahl der Knoten in Funktion der Busauswahl getroffen werden Bussysteme sind zum Vergleich besser geeignet als die Sensoren oder Aktuatoren selbst weil f r jeden Bus gibt es AD Wandler oder E A Ger te Die Ger te unterscheiden sich haupts chlich durch die Eigenschaften die der Bus mit sich bringt Angesichts der gro en Anzahl von Bussen
3. Inhaltsverzeichnis EINLEITUNG tennis nneispnef helehsiesehhinteinsnsehe 7 RE 7 ZIELB DER DIPLOMARBEID enee 8 AUFBAU DER DIPLOMARBEIT ccccoonnnnnnnnnnnnnnnnnnnnnnrr EEE E EEE EEE EEE EOE EEE EEE EEE EE EEE EEES EE EEES ESENS EE 9 PROBLEMSTELLUNG e a re ereere sesers asaos sasareanna serae asean 10 TECHNISCHE ASPEK E 12 Hohe VerfugbDarkeltci PE DBAS DREGE RER EINE TREE Re 15 EE 18 Flexibilit t und Erweiterboarkett een rra rra EE Ee tae teen tte eee 19 Schnittstelle zum Juieret cece cece eee e eee eee Eee ene Een EEE ECOG GEE Ee ca EE ee ctaa atte enna 19 ZNISAMMENEASSUNG cc 20cetesbtesbtesbiesbiaslebsbebercbsbebecbsbabsbsbsbsbsbcbsbsbsbcbsbsbsbcbsbsbshshsbsbshsbsbsbsbsbsbsbsbubaly 20 ARCHITEKTUR E 21 IKNOTEN E 21 Ver WU Geiser cee cee A PEE NEE EE ELON EE TE es 22 EE 22 DIE PEER APPLIKATION eebe 23 VERNETZUNG VON PEER UND GERATE CONTROLTER une 25 KTTENT APPRETRA ION 003552522254 A is 25 DER VICE ARCHITEKT RE 25 GESAMTARCOTTEKTUR iii aida 26 ANDERE LOSUNGSKONZEPTE bb 27 ee 27 E 28 ENEE 29 INTERNET EE LL EE ELE LE LILLE eee ae 30 YA ana RC AAA ee 3 EE EE 31 TECHNOEOGIEWAH E 33 Lan E 33 EAN a eeT ee 34 RE 35 Vergleichider Busse a As 35 GERATE GONTROLLER UND VERNETZUNG sans 36 e EE 37 MAXIMA CE iS IAEA AAA ARTEAGA 37 Vergleich der Mikrocontroaller Eee eee Ee CLE EEE ena EEE Ect nate essen 38 DIE PEER PLA TTFORM EE 38 ZUSAMMENFASSUNG eg ia e E Ea E E E E S EEEo EE o EE E EE E EE ESEO ETENE ENE 39 ENTWURF DER KOM
4. Knoten sicher an gro e Netzwerke wie z B dem Internet anzubinden Knoten haben als Eigenschaft dass diese relativ wenig Intelligenz besitzen und somit ein Medium brauchen mittels dem sie Daten zum Internet hin und herschicken k nnen Bei SASI wird nicht die Idee verfolgt F higkeiten in den einzelnen Knoten zu integrieren sondern es wird versucht die F higkeiten auszulagern Bei SASI werden diese F higkeiten zum Ger te Controller und zu der Peer Applikation ausgelagert 71 Architektur Konkret handelt es sich bei den verwendeten Knoten um 1W Ger te von Maxim IC Diese Knoten sind einfache integrierte Bauelement die ber einen einfachen Bus kommunizieren Der Ger te Controller ist technisch gesehen ein Mikrocontroller der ber den Bus mit den Knoten kommuniziert und sich um die Administration des Busses k mmert Dieser Ger te Controller hat als weitere Aufgaben die Knoten zu konfigurieren und nach au en hin eine Schnittstelle anzubieten Da es sich beim Ger te Controller um einen Mikrocontroller mit beschr nkter Rechenleistung handelt wird es vorgezogen diesen nicht direkt mit dem Endbenutzer kommunizieren zu lassen Es wird eine weitere Zwischenstufe hinzugenommen die so genannte Peer Applikation PC basiert python Peer Applikation Se Klient i Applikation Peer Applikation Ger te Controller Tini Networked Mikrocontroller Knoten
5. r die Applikation sind w re ein abstraktere Kommunikationsform w nschenswert Die Einf hrung einer weiteren Schicht die diese Umsetzung durchf hrt ist w nschenswert Die Kommunikation die zwischen Ger te Controller und Peer stattfindet ist prinzipiell nur der Austausch von kleineren Nachrichten Eine Liste von Beispielen soll einen kleinen Eindruck vermitteln Einige Beispiel Nachrichten vom Ger te Controller zum Peer e Schalter Y wurde gedr ckt zum Zeitpunkt X e Spannung an Eingang Z ist K Volt e ID Chip mit Seriennummer XXXXXX wurde am Bus angemeldet e ID Chip mit Seriennummer XXXXXX wurde am Bus abgemeldet e Durchschnittliche Temperatur XX Grad Celsius Einige Beispiel Nachrichten vom Peer zum Ger te Controller e Setze Sample Intervall von Sensor X auf Z Sekunden e Schicke mir dein Error Log File e Benutze neue Netzwerkkonfiguration X Diese Beispiele verdeutlichen dass es sich bei der Kommunikation zwischen Ger te Controller und Peer Applikation um kleine Nachrichten handelt Somit w re eine Schicht die Nachrichten versendet und empf ngt sinnvoll Diese Schicht sollte auch von der Paketschicht abstrahieren F r den Nutzer dieser Schicht sollte uninteressant sein wann oder wie Pakete gesendet werden Dies f hrt zu einer vereinfachten Form der Kommunikation f r die Applikation da diese Schicht von Paketen abstrahiert und auch von den Empf ngern siehe Abbildung 13 Beim Senden von Nachrichten sorgt diese Schicht
6. schreiben kann Unter anderem wird dieses Modul auch den vereinfachten Web Server starten der die Anfragen der Klienten beantwortet Eine weitere Rolle dieses Moduls ist die des Ordnens der Pakete nach ihrer Sequenznummer Das Protokoll Modul setzt auf die Netzwerkschicht auf und verwaltet alle Aktionen in Verbindung mit dem definierten Kommunikationsprotokoll Hierzu geh ren der Verbindungsaufbau und das Quittieren von Paketen Das Nachrichten Modul abstrahiert auch hier die Netzwerkschicht und bietet der Applikation einen Strom von eingehenden und ausgehenden Nachrichten an hnlich wie beim Ger te Controller hat dieses Modul auch die Aufgabe Nachrichten zu akkumulieren um diese dann im richtigen Zeitpunkt zu senden Das DASM Modul dient dazu einkommende Pakete zu berpr fen und diese in entsprechende Objekte umzuwandeln Jedes m gliche Paket besitzt eine entsprechende Klasse Das Disassembler Modul versucht die Pakete den entsprechenden Klassen zu zuweisen Hierbei werden auch berpr fungen ber den Sinn der Pakete gemacht Zero length Pakete z B werden verworfen Das Vorgehen des DASM ist im Anhang unter Paket Logik der Peer Applikation genauer spezifiziert Dieses Modul erm glicht das einfache Erweitern der Kommunikation zwischen Ger te Controller und Peer Bei Einf hrung eines neuen Pakettyps muss lediglich das Format dieses Paketes im Programmcode angegeben werden nderung an den Kontrollstrukturen sind somit ni
7. sung die Sensornetzwerke mit gro en Netzwerken wie dem Internet verbindet und dabei auf PC Systeme verzichtet ist vorteilhaft Knoten 1 Gateway iss USEA Ethernet Treiber Kneten n USB2 USB Benutzer Treiber Abbildung 2 Ger teanschluss ber Gateway Den Verzicht auf ein PC System in der Kette vom Sensor bis hin zum Internet erreicht man durchaus auch mit aktuell verf gbaren Mitteln Die Mikrochipindustrie ist dem Wunsch nach Embedded Internet Computing nachgekommen und hat eine gro e Anzahl von solchen Remote Power Switch 14 Mikrochips entwickelt Die gro e Anzahl von Mikrocontrollern auf dem Markt die bereits ber Ethernet Schnittstellen verf gen vereinfachen die Integration der Informationstechnik in allt gliche Gegenst nde Integrierte IP Stacks sind auch keine Seltenheit mehr Diese Entwicklung die prinzipiell dem entspricht was man sich f r Ubiquitous computing erwartet besitzt auch einige Nachteile Besonders im Bereich der Ausfall und Informationssicherheit sind solche eingebettete internetf hige Mikrochips sehr anf llig Die schwache Ausfallsicherheit bei internetf higen Mikrocontrollern ist mit einer positiven Eigenschaft dergleichen verbunden Mit der Gr e und auch relativ beschr nkten Rechenleistung gehen wenig Kosten einher Diese beschr nkte Rechenleistung kann aber dazu ausgenutzt werden um einen Mikrocontroller gezi
8. Das Daemon Modul bildet den Sammelpunkt f r alle Funktionalit ten und Module Der Daemon liest die Konfigurationen und stellt alle anderen Module ein Der Daemon ist sozusagen der Manager der Peer Applikation Das Log Modul bietet einfache Log Funktionalit ten So kann man beispielsweise wichtige Nachrichten speichern oder Debug Nachrichten ausgeben Der Verbosity Level der Applikation entscheidet welche der Nachrichten angezeigt werden Mit dem v Parameter auf der Kommandozeile kann man die Debug Nachrichten einschalten Das MIB Modul kapselt die zentrale Datenstruktur Es handelt sich dabei technisch gesehen um einen Baum der auf assoziativen Arrays basiert Jedem Blatt in diesem Baum wird eine Funktion zugewiesen Wird nun eine Anfrage an eine URI gemacht so wird dieses Blatt im Baum gesucht und anschlie end die dort gespeicherte Funktion aufgerufen Die Funktion erh lt s mtliche Informationen der Anforderung z B GET POST DELETE etc Wie die Funktion nun auf diese Anfragen reagiert ist an den Sinn dieser Ressource gebunden und kann frei implementiert werden 80 Wenn man einen neuen Knoten einf gen m chte so sollte man diesen in Form einer Klasse modellieren Es existiert die abstrakte device Klasse die Basisfunktionalit t eines 1W Ger tes beherbergt Alle implementierten 1W Ger te leiten sich von dieser Klasse ab Man sollte sich beispielsweise die anderen bereits vorhandenen 1W Ger te ansehen um ein
9. Isirwww epfl ch 32 Da das SASI Rahmenwerk davon ausgeht dass es einer sehr gro en Zahl an Sensoren oder Aktuatoren gegen bersteht war eines der Ziele die Kostensenkung Die wenigsten der genannten Projekte unterst tzten diese Annahme als sinnvolles Ziel Ein weiteres Merkmal von SASI sollte die Verf gbarkeit und Kommunikationssicherheit sein Bei genannten Projekten erschien der Trend Knoten drahtlos und gleichzeitig IP f hig zu machen Allerdings schien es nicht klar wie hohe Sicherheitsanspr che in diesen Szenarien realisiert werden Analog zu dem GSN Projekt bietet auch SASI eine API an Durch die Peer Applikation bietet das SASI Rahmenwerk den Klienten eine bequeme Dienst Schnittstelle mit der die Klient Applikation auf die Knoten zugreifen kann Somit l sst sich SASI in die Kategorie der Middleware Projekte einordnen da SASI ohne Klient Applikation keine praktische Anwendbarkeit besitzt 33 Technologiewahl In diesem Kapitel wird auf die Auswahl von Technologien oder Produkten eingegangen Bei der Auswahl der Technologien oder Produkte werden die im letzten Kapitel ermittelten Architekturentscheidungen beriicksichtigt Es sei angemerkt dass die Konzepte von denen SASI Gebrauch macht technologieunabh ngig sind Folgende Auswahl der Technologie dient nur der Realisierung eines Demonstrators um die Funktionsfahigkeit von SASI nachzuweisen Knoten Peer Applikalien Klient Applikalien
10. Keil Compiler kein OOP unterst tzt wurde das Programm klassisch funktional entworfen Weiterhin wurde aus Robustheitsgr nden auf Threading verzichtet Es wurde auch versucht die Anzahl der dynamischen Allokationen zu minimieren um den Raum f r Laufzeitprobleme zu verkleinern Die meisten Datenstrukturen wurden statisch deklariert sofern dies m glich war 78 Grunds tzlich durchl uft das Ger te Controller Programm eine Endlosschleife In dieser Schleife wird den so genannten Modulen der Prozessor zugeteilt Jedes der Module besitzt eine Run Funktion die die n tigen Aufgaben dieses Moduls abarbeiten soll Wichtig hierbei ist dass diese Funktion nicht blockiert Alle Vorg nge m ssen so schnell wie m glich ohne Warten abgearbeitet werden Module sind prinzipiell unabh ngig von einander Im Programm existieren allerdings einige Vernetzungen da verschiedene Netzwerkschichten in verschiedenen Modulen realisiert wurden So hat z B die Netzwerkschicht ein Modul und die Stream Schicht hat ein eigenes Modul jedoch benutzen beide Funktionalit ten des Anderen Es existiert auch hier eine Art Skeleton Modul Bei Erweiterung des Programms wird angeraten dieses Modul zu kopieren und anzupassen Module werden mittels der Mount Funktion in der core c eingef gt Jedes Modul muss eine Dispatcher Funktion implementieren die dazu dient dem Modul ein Kommando zu senden So wird dieser Dispatcher Funktion z B ein INIT Kommando beim S
11. Knoten Sg Knoten Abbildung 20 Gesamtarchitektur Bei der Peer Applikation handelt es sich um ein St ck Software das in der h heren Programmiersprache Python realisiert wurde Somit ist die Peer Applikation h chst portabel und beschr nkt den Benutzer nicht auf eine spezielle Plattform Die Peer Applikation dient dazu die Daten des Ger te Controller zu empfangen und weiter zu verarbeiten Besonderes Augenmerk bei SASI liegt auf der sicheren Kommunikation zwischen Ger te Controller und Peer Applikation Bei der Kommunikation zwischen Peer Applikation und Ger te Controller wird aus Sicherheitsgr nden auf TCP verzichtet Anstelle von TCP kommt ein eigens entwickeltes verbindungsorientiertes Protokoll auf UDP Basis zum Einsatz Nachdem der 12 Peer und der Ger te Controller eine Verbindung etabliert haben wird der Peer ber alle verf gbaren Knoten informiert Von dem Zeitpunkt an werden alle Ereignisse oder Daten der Knoten automatisch an den Peer bermittelt Der Peer kennt somit immer den aktuellen Zustand der Ger te Neben dem Empfang von Daten des Ger te Controller kann der Peer auch die Konfigurationen der Knoten ver ndern Die Peers die zu dem Zeitpunkt verbunden sind werden ber die Konfigurations nderungen in Kenntnis gesetzt Weiterhin besteht die aktive Rolle des Peers darin die empfangenen Daten aufzuarbeiten und diese in Form einer MIB zur Verf gung zu stellen Die MIB ste
12. Teil soll auf die Informationsbasis eingegangen werden Diese Informationsbasis stellt eine Verbindung zwischen Knoten und Klienten her Knoten werden in dieser Informationsbasis publiziert und werden so den Klienten zug nglich gemacht Der Klient kann durch Nutzung der Informationsbasis Knoten manipulieren 51 Informationsbasis In diesem Teil der Diplomarbeit wird die Datenstruktur der Informationsbasis besprochen Die Peer Applikation erh lt laufend Nachrichten bez glich der Knoten Diese Nachrichten enthalten Informationen ber eingetretene Ereignisse oder ber gemessene Werte Die Peer Applikation ben tigt eine entsprechende Datenstruktur in der diese Informationen gespeichert werden k nnen Da diese Datenstruktur dazu genutzt wird Informationen zu speichern und gleichzeitig dazu genutzt wird den Klienten Informationen daraus auszuh ndigen spielt die Informationsbasis eine zentrale Rolle siehe Abbildung 15 Bedingt durch die Architekturentscheidung REST zu nutzen sollte die Datenstruktur aus einer Menge von eindeutig adressierbaren Ressourcen bestehen Angelehnt an das REST Prinzip sollen diverse Aktionen auf den jeweiligen Ressourcen m glich sein Durch Aktionen seitens des Klienten l sst sich die Informationsbasis ver ndern Feer Applikatio Enea Inferior dd ii Pa bas NY REST Aklionct Pee GE UA DS REST Kant Sanel Ve Irnkortac Asplikilion ES
13. Verfeinerung im jeweils darauf folgenden Kapitel 10 Problemstellung Die in der Einleitung angesprochene Entwicklung des Ubiquitous computing und die damit eingef hrten Probleme werden in diesem Teil der Diplomarbeit etwas ausf hrlicher behandelt Bereits heute sind eine Vielzahl von allt glichen Gegenst nden mit Mikroprozessoren ausger stet die die Ger te effektiver oder sogar billiger machen sollen Fr her durch elektronische Schaltungen geregelte Apparaturen wurden mit der Zeit mit ICs optimiert denn weniger Bauteile bedeutet weniger Kosten Solange Moores Gesetz noch G ltigkeit besitzt wird diese Entwicklungsgeschwindigkeit uns weiter mit Hochleistungschips die immer kleiner und billiger werden versorgen So z B berschreitet die Rechenleistung eines modernen Handys die Leistung eines Rechners der 90er Jahre um Weiten Diese Entwicklung f hrt zu immer neuen Applikationsfeldern der Informatik F r Ger te die bisweilen unvernetzt und elektronikfrei ihren Dienst verrichtet haben ergeben sich nun neue M glichkeiten So k nnen z B durch Vernetzung der Gegenst nde neue Gebrauchsmuster entstehen Das Fernsteuern oder intelligente Regeln von bestimmten Apparaturen w ren ohne diese Entwicklung nicht m glich Diese Entwicklung wurde bereits von Marc Weiser im Jahr 1988 erahnt WEISER und ist heute bereits zum Teil Realit t Der von Weiser gepr gte Begriff des Ubiquitous computing schildert genau die Entwick
14. Weitere Details zu diesen Abl ufen wird im Kapitel des Software Entwurfs behandelt Protokoll zwischen Ger te Controller und Peer Applikation PC basiert python Peer Applikation Klient Applikation Peer Applikation Ger te Controller Tini Networked Mikrocontroller Abbildung 11 Kommunikation in der Gesamtstruktur Knoten Knoten ar Knoten 43 In diesem Teilkapitel soll auf den Entwurf eines Protokolls fiir die Kommunikation zwischen Ger te Controller und Peer eingegangen werden siehe Abbildung 11 Zuvor sollte jedoch motiviert werden wieso ein eigenes Protokoll sinnvoll ist Die Wahl der Technologie zwischen Peer und Ger te Controller fiel auf Ethernet mit TCP IP Da die Peers logische Verbindungen mit dem Ger te Controller eingehen liegt TCP als Kommunikationsprotokoll auf der Hand Bedingt durch einige Schwachstellen in TCP die noch etwas vertieft werden sollte sich f r ein alternatives Protokoll entschieden werden Potentielle Schwachstellen in TCP sind beispielsweise durch Havrilla CERT1 nachgewiesen worden Diese Schwachstellen sind protokollbedingt und unabh ngig von der Implementierung Wie in CERT1 gezeigt wurde k nnen dritte Parteien TCP Pakete in die Kommunikation einschleusen Somit k nnten Dritte Einfluss auf die Knoten nehmen so z B das ffnen oder Schlie en von Schaltern Eine we
15. besseres Verst ndnis bez glich der Zusammenh nge zu erlangen Genauere Spezifizierung der Softwarearchitektur und des Kommunikationsablaufs befinden sich im Anhang unter Softwareentw rfe Schlussendlich sei hier auf die Source Codes der jeweiligen Programme verwiesen Diese sind reichlich im Doxygen Stil dokumentiert Softwareentwiirfe Ger te Controller Software Stream module Run Peer module Run Network module Run flushHandier Detect overtiow Comma messages lo net module List of Peers dyn alloc but max peers limit Application logic S 3 E H m e SZ Msg Outbuffer__ packetParser_ Meg Inbuffer Static buffer Parse packets Flushed if overflow and queue to on Allocated j messagebuffer as maximum coming up dahon z Sessionkey IP segA seqB etc S Unacked Packetqueve dyn but maximum Se allowed packets H y E i 3 ij ef Eo al Al 2 183 A SRE a networkAPI networkBasics packetBuffer Es D pips usas u CAMS E ee respond to Handshake sesch pings Validate provide Packets 3 deao packet networkHandler d upper sendBuffer y 44 layers Handles ACKs N Network config bind to y y socket catch packets etc IP initBuffer L Static initbuffer with maximum init limit contains peer infos before handshake is complete parseMessages pPacket 81 82 Peer Software Applicati
16. daf r dass Nachrichten gesammelt und gemeinsam in einem Paket versendet werden 48 Serate Contrel er Feer Applikatio Applikation Apelikatio Cas apasnd wor Cas aprend AT Razrontrer Fr azl arbter Nachrichtenschicht Nachrichtenschicht Kt wv ur xv Fakete Fakse Retoserkachicht Ketzzwerkschicht Ethernet Abbildung 13 Nachrichtenschicht Dieses Konzept vereinfacht die Kommunikation zwischen Peer und Ger te Controller wesentlich Allerdings existieren einige F lle in denen dem Nutzer die Sendung einer Nachricht als dringlich erscheint Aus diesem Grund werden zus tzlich zu dieser Schicht noch virtuelle Kan le eingef hrt Der Nutzer kann beim Senden einer Nachricht angeben welcher Kanal genutzt werden soll Vorgesehen w ren einige Kan le gestuft nach Priorit ten Der Kanal mit der h chsten Priorit t w rde beispielsweise das Senden eines Pakets sofort erzwingen dadurch entst nde keine Verz gerung Dies w re wichtig bei eiligen Meldungen wie z B beim Druck eines Tasters F r alle Kan le die nicht als eilig eingestuft sind sollte man ein automatisches Flush vorsehen Dieses Flush w rde den Puffer der Nachrichten nach einer gewissen Zeit automatisch absenden Somit wird verhindert dass es dazu kommen kann dass Nachrichten ber l ngere Zeitr ume hinweg auf dem Ger te Controller verweilen Hinz
17. dieser Diplomarbeit werden im weiteren Verlauf Sensoren Aktuatoren oder auch h herwertigere Komponenten wie z B Webcams als Knoten bezeichnet Kote 1 Mikrocontraller Ethernet HI Is E Knoten 1 Mikrocontraller Benutzer HI Is Abbildung 1 IP f hige Knoten 13 Das gleiche findet man bei IP RPS und vielen anderen Ger ten siehe Abbildung 1 Die alternative und auch ltere Methode besteht darin einen PC als Gateway zu nutzen Man verbindet die Ger te ber eine gegebene Schnittstelle mit dem PC Die mitgelieferte Software bernimmt dann die Bereitstellung der Daten Verbreitete Schnittstellen f r diesen Zweck sind z B USB FireWire oder die klassische serielle Schnittselle Die beiden genannten Methoden haben Vor und Nachteile auf die im Folgenden eingegangen wird Bei einigen kommerziell verf gbaren Sensornetzwerken ist es durchaus blich einen kompletten PC als Gateway zu nutzen Die Sensordaten werden per USB eingelesen und ber die kommerzielle Software dem Internet angeboten siehe Abbildung 2 In Zusammenhang mit dem Ubiquitous computing jedoch ergeben sich ungewollte Merkmale Das Einrichten eines zentralen Rechners widerspricht dem Aspekt der transparenten Pr senz der Informationstechnologie Weiterhin sind die Kosten f r einen kompletten Rechner ganz und gar nicht verschwindend gering Eine L
18. eine einzige Funktion sein Module k nnen so per Funktionszeiger in den Kern eingebunden werden Der Kern kann so die Module bei Bedarf aufrufen Den Funktionsmodus des Moduls kann per Parameter bergabe bestimmt werden Wichtige Funktionsmodi w ren z B Initialisieren des Moduls oder Modul durchlaufen Wichtige Softwarekomponenten sind e Kern e Netzwerk Modul e Peer Modul e Stream Modul e Persistentes Logging Modul e 1W Modul e Globale modulunabh ngige Funktionen e Kapseln von Mikrocontroller abh ngigen Funktionen Der Kern bildet das Rahmenwerk in dem alle globalen Funktionen zusammengefasst werden und bietet gleichzeitig auch die Schnittstelle zum Einf grn von Modulen an 56 Das Netzwerk Modul wird unter anderen folgende Aufgaben bernehmen e Initialisieren des Netzwerks Binden an IP Adresse e Empfang von Pakten bernehmen e Pr fen der Korrektheit der einkommenden Pakete e Transparentes Abwickeln der Handshakes e Gesendete Pakete bis zum ACK zwischenspeichern e Methoden anbieten um Pakete zu generieren und zu versenden e Die automatische Quittierung von empfangenen Paketen e Das Neukonfigurieren des Netzes durch ein SETUP Paket Das Peer Modul dient dazu alle aktiven logischen Verbindungen zu speichern Dieses Modul enth lt eine Datenstruktur in der alle Daten zu den jeweiligen Peers gespeichert werden Diese Datenstruktur enth lt unter anderen Session Cookies versendete nicht quittierte Pakete die
19. te Controller oder dem Peer platzieren k nnte n tzlich Diese einfache Logik k nnte dann gleich auf dem Ger te Controller oder Peer ausgef hrt werden und somit w rde die st ndige Verbindung des Klienten nicht mehr ben tigt Hierzu w re eine primitive Sprache Vorraussetzung die auf dem Peer in Bytecode umgesetzt w rde und dann Ereignisse seitens des Busses in Aktionen Seitens des Peers umsetzt In der Praxis hat sich gezeigt dass das aktive Pollen des Knoten Busses nachteilig ist Bei einer gro en Anzahl von Knoten kann es dazu kommen dass einige kritische Knoten wie z B Taster nicht schnell genug abgefragt werden um einen Tastendruck zu registrieren Eine L sung hierf r w re es einen anderen Bus zu w hlen in dem die Knoten eigenst ndig Nachrichten an den Master senden k nnen 70 Anhang Benutzer und Entwicklerhandbuch In diesem Teil des Dokumentes wird auf die Benutzung des entwickelten SASI Rahmenwerks eingegangen werden Das Benutzerhandbuch gliedert sich in eine kleine Einf hrung in SASI gefolgt von einer kleinen bersicht ber die Architektur Letztlich wird konkret auf die Aspekte der Installation und Konfiguration eingegangen Im letzteren Teil dieses Handbuches wird auf Entwicklungsdetails eingegangen die den Programmierer mit den n tigen Kenntnissen ausr stet um SASI weiter entwickeln zu k nnen SASI SASI steht f r Secure Attachement of Sensor devices to the Internet und hat zur Aufgabe
20. ten die auf dem Markt zur Verf gung stehen Jedes dieser 1W Ger te unterst tzt andere Funktionalit ten SASI unterst tzt zu diesem Zeitpunkt vier Knoten e Temperatursensor e Eingabe und Ausgabe e I D Buttons e AD Wandler Wenn ein weiteres Ger t unterst tzt werden soll so ist es n tig den Programmcode vom Ger te Controller und der Peer Applikation anzupassen Da die 1W Ger te alle anders ber den Bus angesteuert werden ist es leider nicht m glich eine generische Schnittstelle f r alle Typen zu definieren Prinzipiell kann man jedoch mit den vier unterst tzten Ger ten durch Schaltungen eine Vielzahl von Applikationen entwickeln Da die Schaltung f r den Ger te Controller unwichtig ist muss auch keine Erweiterung hierf r programmiert werden Die Logik der Schaltung ist f r SASI unerheblich da SASI lediglich die Kommunikation zwischen den Knoten und dem Benutzerprogramm regelt Nichts desto trotz wurde vorgesehen weitere 1W Typen einzuprogrammieren Es befindet sich im Ger te Controller Source Tree im Modul onewire einen generellen 1 W Typus der keine Funktionalit t besitzt Dieser Typ hei t m_onewire_skel skel steht f r Skeleton und soll bedeuten dass es lediglich den Rahmen festsetzt Die Funktionsk rper m ssen an den 1W Typ angepasst werden Ger te Controller In diesem Abschnitt soll kurz erl utert werden wie die Architektur des Ger te Controller realisiert wurde Da der verwendete
21. ufiges Konzept ist das so genannte SCADA ICITA1 SCADA steht f r Supervisory Control and Data Acquisition Es handelt sich hierbei um ein Konzept zur Erfassung Steuerung und berwachung von Sensoren und Aktuatoren Es wird haupts chlich zur Steuerung von technischen Prozessen angewandt Es wird in diesem Kontext zur Sprache gebracht da es in dieser Diplomarbeit im weitesten Sinne auch um Erfassung von Daten und Steuerung von Elementen geht Bei SCADA werden Sensoren und Aktuatoren von Remote Terminal Units oder von Programmable Logic Controller verwaltet Diese Einheiten f hren auch eine Aggregation von Daten aus Die Steuerung und Datensammlung wird von so genannten Master Stationen bernommen Bei einer solchen Master Station handelt es sich um einen PC der auch eine Benutzerschnittstelle anbietet 28 Bei SCADA handelt es sich vor allem um ein Konzept und nicht um eine fertige Technologie Es gibt diverse Anbieter die SCADA L sungen anbieten allerdings sind diese oftmals propriet r Somit sind die konkret eingesetzten Mittel oft variabel Beispielsweise ist die Kommunikation zwischen den einzelnen Sensoren und Aktuatoren nicht fest an eine Technologie gebunden wobei aber Ethernet und IP oft in Erscheinung treten Ein Schlagwort bei diesem Konzept ist auch das so genannte Web Scada Hierbei wird das Human Machine Interface ber das WWW zur Verf gung gestellt Auch hier gibt es diverse Anbieter einer solchen Technologi
22. 29 Aktuators Sensors liegt somit in der Hand des Entwicklers Weiterhin wird von Crossbow die Basisstation vertrieben die es erlaubt alle Daten des WSN zu sammeln und an einen Rechner weiterzuleiten Schnittstellen der Basisstation sind z B USB oder Ethernet mit TCP IP Mit GSN einem Opensource Middleware Projekt des LSIR Lab f r Sensornetzwerke kann man dieses WSN inspizieren manipulieren und auswerten Interessant sind auch Versuche jeden dieser Knoten IP f hig zu machen IAB1 Es wird versucht die Knoten nicht ber einen Proxy oder Gateway an das IP Netzwerk anzuschliessen sondern gleich jeden Knoten IP f hig zu machen Allerdings setzen diese Ans tze IPv6 voraus weiterhin sind Sicherheitsaspekte hier offene Fragen wie z B Schutz vor DoS Angriffen oder die Regelung der Zugangskontrolle Prinzipiell ist das Konzept jeden Knoten IP f hig zu machen dem des SASI Rahmenwerks gegenl ufig Eine der Architekturentscheidungen dieser Diplomarbeit bedingt die Intelligenzverlagerung weg von den Knoten hin zu einem Verwalter der in dieser Diplomarbeit Ger te Controller genannt wird Bei diesem Projekt werden ungleich mehr F higkeiten von den Knoten gefordert Dies f hrt zu erheblichen Mehrkosten im Vergleich zu SASI Die Frage ob jeder Knoten nun drahtlos angebunden werden muss h ngt nat rlich vom Applikationsfeld ab INSIGHT INSIGHT steht f r Internet Sensor Integration for Habitat Monitoring INSIGHT Es ist ein
23. Aktion noch Daten mitgesendet werden Solche Aktionen sind e POST Diese Aktion berschreibt eine existierende Ressource mit den mitgeschickten Daten e PUT Diese Aktion erstellt eine noch nicht vorhandene Ressource e DELETE L scht eine existierende Ressource e GET Verlangt den Inhalt einer bestehenden Ressource He Die genannten Aktionen sind keinesfalls zwingend Das REST Prinzip kann nach Belieben angepasst werden Zu beachten gilt dass die REST Aktionen in diesem Rahmenwerk von beiden Seiten erzeugt werden k nnen So kann z B der Klient der Peer Applikation mitteilen dass ein Schalter seinen Zustand ndern soll dies w rde in diesem Fall mittels einer POST Aktion auf die URI des Schalters geschehen Gleicherma en kann die Peer Applikation auch eine REST Aktion an den Klienten richten Ein Beispiel hierf r w re ein eingetretenes Ereignis wie die Bet tigung eines Schalters Da eine solche REST Aktion nicht dem Sinn von POST PUT DELETE oder GET entspricht ist es sinnvoll die NOTIFY Aktion einzuf hren Diese w rde eine nderung bezogen auf eine URI mitteilen Das REST Prinzip ist nicht neu so wird REST bereits erfolgreich in HTTP und SNMP eingesetzt Diese weite Verbreitung und die Einfachheit von REST befriedigt zwei Konzeptionskriterien zugleich n mlich KISS und das Verwenden von verbreiteten Technologien Durch die Zustandslosigkeit der Kommunikation unterst tzt dieses Prinzip auch Ad Hoc Anfragen wie sie i
24. Anzahl der fehlgeschlagenen Zustellungsversuche von Paketen IP Adresse und andere Daten Im Folgenden werden die Aufgaben des Peer Moduls aufgelistet e Das Speichern aller relevanten Informationen bez glich der Peers e Das Ermitteln von Peers die nicht mehr Verbunden sind e Das Speichern von gesendeten Paketen die noch nicht quittiert wurden Das Stream Modul setzt auf der Netzwerkschicht auf Das Modul nimmt Pakete entgegen und f gt enthaltene Nachrichten in eine Nachrichtenwarteschlange ein Gleichzeitig nimmt dieses Modul Nachrichten der Applikation entgegen und schickt diese ber die Netzwerkschicht in Paketen zu den Peers Im Folgenden sind alle Aufgaben dieser Schicht aufgelistet e Entgegennahme von Paketen ber das Netzwerk Modul e Zwischenspeichern einkommender Nachrichten f r sp tere Auswertung e Zwischenspeichern zu sendender Nachrichten f r sp tere Versendung e Realisieren von Kan len mit unterschiedlichen Sendepriorit ten e Automatisches flushen der zu sendenden Nachrichten 57 Das Persistent Log Modul dient zum Speichern von Laufzeitfehlern Es stellt sicher dass auch nach Ausschalten und sp terem wieder Einschalten des Mikrocontrollers der Fehlerspeicher noch vorhanden ist Das Modul greift auf das Dateisystem des Tinis zu und speichert alle Fehler in Dateien Diese Dateien befinden sich im RAM des Tinis und werden durch die Batterie auch bei ausgeschaltetem Tini weiter erhalten Im Folgenden sind noch mal a
25. Diplomarbeit Sichere und verl ssliche Kommunikation zwischen Low Cost Devices und PCs Patric de Waha Mai 2007 Betreuer Prof Dr Paul Moller Dipl Ing Dirk Henrici Fachbereich Informatik AG Integrierte Kommunikationssysteme Universitat Kaiserslautern e Postfach 3049 e 67653 Kaiserslautern Erklarung Hiermit erkl re ich dass ich die vorgelegte Arbeit Sichere und verl ssliche Kommunikation zwischen Low Cost Devices und PCs selbst ndig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel verwendet habe Kaiserslautern 14 05 2007 Abstract Die zunehmende Pr senz intelligenter elektronischer Ger te und vor allem deren Vernetzung stellt uns vor einige neue Herausforderungen Sicherheit und Kosten sind nur einige der ausschlaggebenden Probleme mit denen wir uns konfrontiert sehen Das Anbinden von einfachen Ger ten an gro e Netze vor allem an das Internet wirft Probleme auf die Zuwendung bed rfen So sind z B Kosten und Sicherheit eines der wesentlichen Faktoren die in diesen Szenarien genauerer Untersuchung bed rfen In dieser Diplomarbeit werden Aspekte wie Ausfallsicherheit Kosten und sichere Kommunikation im Kontext des Ubiquitous computing besprochen Anschlie end werden Konzepte vorgeschlagen die diesen Problemen Rechnung tragen Die Funktionsf higkeit der erarbeiteten Methoden und Konzepte wird anhand eines realen Fallbeispiels und eines Demonstrator nachgewiesen
26. Klient i i Applikation Peer i Applikation i Ger te Controller Tini Networked Mikrocontroller Abbildung 14 Peer Applikation in der Gesamtstruktur Knoten Knoten Seet Knoten Der Peer erh lt laufend Informationen seitens des Ger te Controllers Diese Informationen werden in der Informationsbasis des Peers gespeichert Damit ein Klient auf diese Informationsbasis zugreifen kann bedarf es einer entsprechenden Schnittstelle In den Architekturentscheidungen wurde sich bereits daf r ausgesprochen REST als Service Architektur zu verwenden In diesem Teil der Diplomarbeit wird ermittelt wie dieses REST Prinzip konkret als Schnittstelle angeboten werden kann 50 Schnittstellenauswahl Sowohl der Peer als auch der Klient sind PC basierte Systeme dadurch sind auch komplizierte Protokolle verwendbar Da HTTP ein REST basiertes Protokoll ist steht der Schluss nahe HTTP zu nutzen Zwar unterstiitzt HTTP einfache REST Aktionen allerdings fehlt bei HTTP die M glichkeit andere Aktionen auf URIs anzuwenden als die die in der Spezifikation stehen Dies f hrt zu der berlegung dass HTTP lediglich als Transportmedium genutzt wird Die eigentliche REST Aktion wird in einer XML Datei gespeichert Diese XML Datei wird dann mittels eines HTTP Aufrufs an die Empf ngerstelle bermittelt Wenn der Klient nun eine nderung an einem Knoten durchf hren will wird die
27. Klient Applikation eine XML Datei erstellen in der spezifiziert ist welcher Knoten auf welche Weise manipuliert werden soll Diese XML Datei wird nun an die Peer Applikation mittels HTTP bermittelt Wenn nun die Peer Applikation seinen Klienten ein Ereignis mitteilen will wird dieser ebenfalls eine XML Datei erstellen in der eine NOTIFY Aktion spezifiziert ist Diese XML Datei wird dem Klienten dann per HTTP bermittelt Dies bedeutet das beide Parteien ber einen HTTP Server verf gen m ssen der diese Daten empf ngt und auswertet Es wird sich hierbei nicht um einen regul ren HTTP Server handeln sondern nur um einen TCP Socketserver der die n tigsten Operationen beherrscht um die Anfragen verarbeiten zu k nnen Da die Kommunikation zwischen Peer und Klient auf dem REST Prinzip beruht existiert keine aktive Verbindung zwischen beiden Der Peer wei prinzipiell nicht dass Klienten verbunden sind und wei nicht an welche Klienten ein Ereignis durchgereicht werden muss Es ist somit n tig dass der Klient in der Informationsbasis eintr gt an welchen Knoten er interessiert ist dies wird im Folgenden als abonnieren bezeichnet Der Klient kann somit alle oder spezielle Knoten abonnieren Wenn nun f r ein Knoten ein Ereignis eingetreten ist so wird der Peer bei Bedarf ein NOTIFY an alle abonnierten Klienten senden Der Peer findet diese Informationen in seiner Informationsbasis die durch den Klienten hinzugef gt wurden Im folgenden
28. MUNIKATION ssossosesssssssseonsessnsssonsonnessnesssnsonnessnssssnsonnessnesssnsonnessnessene 40 KOMMUNIKATION ZWISCHEN GERATE CONTROLLER UND KNOTEN ccococccoccconncnnononaconncnnonanccancnns 41 PROTOKOLL ZWISCHEN GER TE CONTROLLER UND PEER APPLIKATION cococooconcoconcconncnononanccnnc n 42 Anforderungen an das Kommunikationsprotokoll cccccccccccecccceeece eee cecne eee eenee eee enaeeeecnaeeeeee 44 Datenaustausch zwischen Gerdte Controller und Peer 47 PAT TUATINI I ATEETAN AEAT 48 PEER APPLIKATION UND KLIENT APPLIKATION uuuresunesssnessnnessnnnersnnneennnenennnersnnnensnnnnennnersnnnen 49 Sehnitistellendus WA a e niet soins a eins pn anpassen 50 EI REN EE 51 ENTWURE DER SOFTWARE nn RR RE 54 GERATE CONTROLLER SOFTWARE cccccsssssceecceeesseesseeeeeeeeeseeesseeeeeeeeeeseessseeeeeeeeeeeensssaeeeeeeeeeees 54 NO RE 58 EINSA KE 62 e ENKE ee ee ee ee ee ee ee ee ee ee ee ee ee ee ien 62 EIERE nennen eege 63 VERSUCH EE 65 K i E REN CT D ET 67 AUSBLICK E 69 A EEEE EEEE 70 BENUTZER UND ENTWIKCKLERHANDBUCH cnc nan na rana coran nro nnnccnnnnos 70 KE TT 70 AAV CHUL ERUN EE A eg 71 Installation und Kontfigeuratton rra rra 73 AA AA 2 RT E NS ES A 76 Ger te Controll err a e EE EE EE 77 PEPA eebe Ee IL OLE ie 78 A AS A e 81 Ger te Controller Software 81 Peer SOfIWARE eege 82 Paket Logik des Gerdite Controller onen 83 Paket Logik der Peer Applikoation onen 84 EITERATURVERZERICHN IS una RER 85 ABBIEDUNG
29. SVERZEICHNBS star 87 ABK RZUNGEN a iii 88 Einleitung Ausgangslage Die zunehmende Durchdringung der Informatik im Alltag und in unserem Umfeld wird auch in Zukunft noch zunehmen Mit modernen Chips ist schon heute mehr Rechenleistung in einem 10 Euro teuren Mikrocontroller als in einem PC vor zehn Jahren Dies hat zur Folge dass immer mehr allt gliche Gegenst nde mit Rechenleistung ausgestattet werden Sei es um mehr Funktionalit t zu erreichen oder um die Nutzbarkeit der Gegenst nde zu verbessern Die Gr nde f r die Durchdringung der Informatik im Alltag sind vielseitig Die Vision des Ubiquitous computing ist bereits heute teilweise zur Realit t geworden Kraftfahrzeuge die bereits einige Kilometer Kabel enthalten die mit leistungsf higen Rechnern verbunden sind sind nur die Spitze des Eisbergs Diese scheinbar unvermeidbare Entwicklung wirft aber auch einige Fragen auf Wie garantieren wir Sicherheit vor Ausfall oder Missbrauch durch andere Diese unerw nschten Konsequenzen die mit Ubiquitous computing verbunden sind potenzieren sich indem man diese intelligenten Gegenst nde vernetzt Die Vernetzung dieser Gegenst nde ist ein genauso logischer Schritt wie die Ausstattung der Gegenst nde mit Chips und birgt mindestens genauso viele Probleme Wie kann man sichere Kommunikation mit diesen Gegenst nden garantieren Insbesondere wenn die Gegenst nde mit gro en Netzen wie dem Internet verbunden sind Da diese Ent
30. af r sorgen dass eine berschreitung erkannt wird Aufbau Der Aufbau des Demonstrators der dieses Verhalten simulieren soll spaltet sich in zwei Teile auf Zum einen muss die elektronische Schaltung f r dieses Szenario entwickelt werden und zum anderen muss die Klient Applikation die die Logik implementiert entworfen werden Auf die elektronische Schaltung soll in diesem Teil nicht eingegangen werden sondern auf die Implementierung der Klient Applikation Das SASI Rahmenwerk stellt einem alle Hilfsmittel zur Verf gung um diese Applikation zu realisieren Da es sich bei diesem Szenario um Ereignisse handelt die direkter Behandlung bed rfen muss die Klient Applikation st ndig mit dem Peer verbunden sein Mittels der zur Verf gung gestellten API kann mit Python ein entsprechender Klient in einigen Zeilen realisiert werden Grunds tzlich reduziert sich die Klient Logik auf das Warten von Ereignissen um anschliessend eine Reaktion auf die Ereignisse einzuleiten Die Reaktion in diesem Fall w re das ffnen oder Schlie en eines Schaltelements 64 usr bin python import sys time wclib wclib start localhost 82 wclib programm lock acquire client wclib getClient lt host gt lt port gt client do wclib newRA POST subscribeall lt host port gt def handleNotification pAction if pAction uri temperatur infos lasttemp if float pAction data gt 31 0 print Too hot opening door
31. aket an den Server Dieses gesendete INIT Paket enth lt eine Zufallszahl Der Server erh lt dieses Paket und sendet ein CHALLENGE Paket zur ck in dem ebenfalls eine Zufallszahl enthalten ist Der Hashwert ber diese beiden Zufallszahlen und das geteilte Geheimnis bildet den Session Cookie Um dem Server zu beweisen dass er als Klient einen Anspruch auf Verbindung hat muss der Klient nun ein 45 ACK Paket mit dem Hashwert ber beide Zahlen zur cksenden Dieser Session Cookie muss ab nun mit jedem Paket mitgesendet werden Der Server verwirft jedes Paket das keinen korrekten Session Cookie enth lt Ein Au enstehender ist nun nicht in der Lage mit dem Server zu kommunizieren sofern er nicht ber einen g ltigen Session Cookie verf gt Um den korrekten Session Cookie zu generieren ben tigt der Klient das korrekte Passwort Um jedoch zu vermeiden dass der aktuelle Session Cookie ber das Abfangen von Paketen erfahren werden k nnte wird noch eine weitere Sicherheitsstufe mit eingeplant Jedes Paket das nicht ein INIT oder CHALLENGE Paket ist muss einen Hashwert ber den Session Cookie die Sequenznummer die Daten und das geheime Passwort mit jedem Paket zwecks Integrit tssicherung mitsenden Somit ist es nicht m glich die Pakete von au en zu manipulieren Eine nderung des Inhalts des Paketes w rde der Server an dem nicht passenden Hashwert bemerken Weiterhin wird gefordert dass nur Pakete in aufsteigender Reihenfolge akzep
32. alc Hash wur m Pear IP and Pot WO equal gt Serd ACK for this SEQ ye 5 Send PONG 83 free init slot Insert peer in peerist and send ACK m Hash Valus correct 84 Paket Logik der Peer Applikation Recewe Datagramm Check packet structure version meaning etc Packet 2 Object ok gt DROP Typel ACK amp amp seq expected A 5 ono Hash ete ok el DROP Delete ach seq from Is ACK packet outbufier D Type Challenge Send ACK uC seq 1 Type PING ei Send Pong Seq gt expected Save in butter L v Process Packet 85 Literaturverzeichnis CERT1 TAB1 ICITA1 ICSY1 IETF INET 1 INSIGHT LSIR MAX1 Jeffrey S Havrilla Multiple TCP IP implementations may use statistically predictable initial sequence numbers 2001 http www kb cert org vuls id 49844 11 05 2007 Kary Mayer Wolfgang Fritsche IP Enabled Wireless Sensor Networks and their integration into the Internet International conference on Integrated Internet ad hoc and sensor networks ACM International Conference Proceeding Series Vol 138 2006 L Tan and K Taylor Mobile SCADA with Thin Clients A Web Demonstration Commonwealth Scientific and Industrial Research Organisation 2002 Dirk Henrici Bridging the Gap Between Pervasive Devices and Global Networks in submission 2007 R Stewart Q Xie et al Stream Control Transmission Protocol 2000 h
33. annt ist sollte nicht in Betracht gezogen werden Diese drei Kriterien gelten nur als Richtlinien das strikte Einhalten wird nicht um jeden Preis erw nscht 18 Geringe Kosten Aus der Definition von Ubiquitous computing l sst sich folgern dass der Mensch in Zukunft fter mit intelligenten Ger ten in Ber hrung kommt als es aktuell der Fall ist Die gro e Anzahl der Ger te die mit Mikrochips ausgestattet werden wird noch wesentlich zunehmen Diese Entwicklung bedeutet weitere Kosten ftir den Besitzer dieser Ger te Es sollte durch geeignet gew hlte Konzepte versucht werden die Kosten vor allem im Anschaffungspreis zu senken Auch in Hinsicht auf die Kosten ist das Konzept in dem jedes Ger t ber gro e F higkeiten verf gt z B Web Server unvorteilhaft Komplexe Software wie Webserver und IP Stack erfordern wesentlich mehr Ressourcen z B RAM Rechengeschwindigkeit und vieles mehr Dies schr nkt zum einen die Auswahlmenge geeigneter Mikrochips ein und zum anderen heben sich zus tzlich noch die Kosten pro Chip Verzichtet man in weiten Teilen auf komplexe F higkeiten und berl sst einer anderen Instanz diese Aufgaben so lassen sich die Kosten erheblich senken Im einzelnen m gen die Kostenvorteile nicht so hoch sein allerdings wird dieser Sachverhalt deutlicher bei einer gro en Anzahl an Ger ten so wie es in der Vision von Marc Weiser prophezeit wurde Aus den letzteren berlegungen ergibt sich ein weit
34. as Einf gen und Entfernen des ID iButton Da das Einf gen durch menschliche Hand nicht sehr schnell durchgef hrt wird kam es in einigen Versuchen zur St rung des Busses Dies ist nur insoweit tragisch dass die bereits vorhandenen 1W Ger te f r Sekundenbruchteile vom Bus getrennt wurden Dies wirkt sich jedoch nachteilhaft auf die Konfiguration der 1W Ger te aus Beim Anschlie en eines Temperatursensors z B wird dieser vom Ger te Controller auf eine gewisse Aufl sung programmiert Ist dieser nun gest rt worden kehrt dieser in seine Initialkonfiguration zur ck Fatal ist dass der Ger te Controller diese Zustands nderung nicht wahrnimmt und somit k nftig falsche Daten ausliest Die genannten Probleme die sich im Versuch manifestiert haben sind weniger konzeptioneller als mehr technischer Natur Schaltungen die das Entprellen beim Einf gen bernehmen k nnten dieses Problem beheben 67 Zusammenfassung Das Ziel dieser Diplomarbeit bestand darin ein Rahmenwerk zu entwickeln das auf kosteng nstige und sichere Art und Weise einfache Sensoren oder Aktuatoren mit gro en offenen Netzen wie dem Internet verbindet Im dem ersten Kapitel in dem die Problemstellung klarer spezifiziert wurde haben sich einige Kriterien ergeben die ein sinnvolles Ma daf r sind ob die Zielvorgaben erreicht wurden oder nicht In folgenden soll evaluiert werden inwieweit diese Kriterien erf llt wurden Zu Erinnerung werden noch einmal di
35. chen Verbindung mit dem Ger te Controller befinden sollte nach dem Handshake die Garantie der Auslieferung der Pakete vom Protokoll gew hrleistet werden Ebenfalls sollte eine Sequenzierung der Pakete vorgenommen werden Die Natur der Applikation impliziert dass nur kleine Nachrichtenpakete zur Kommunikation verwendet werden Dies f hrt dazu dass eine Segmentierung seitens des Protokolls nicht erforderlich ist Da die Kommunikation zwischen Ger te Controller und Peer gesichert werden soll wird eine Authentifizierung beider Seiten n tig Zur Reduktion der Komplexit t soll ein geteiltes Geheimnis als ausreichend angesehen werden Nachfolgend alle Protokollkriterien noch einmal aufgelistet e Verwendung von UDP als Ersatzdatentr ger an Stelle von TCP e Sequenzierung der Pakete durch das neue Protokoll e Segmentierung nicht n tig e Geteiltes Geheimnisprinzip e Paketzustellgarantie wird vom Protokoll bernommen e Flusskontrolle nicht notwendig Ausgehend von einem Protokoll entworfen von Henrici ICSY1 lassen sich die eben erw hnten Kriterien implementieren Das von Henrici entwickelte Protokoll basiert wie gew nscht auf UDP Im Folgenden soll n her auf das Protokollschema von Henrici eingegangen werden Bei dem erw hnten Protokoll handelt es sich um ein 4 Wege Handshake mit Sicherung ber Hashfunktionen Beide Parteien verf gen ber den geheimen Schl ssel Die Partei die eine Verbindung aufbauen m chte sendet ein INIT P
36. cht n tig Das LOG Modul bietet analog zum LOG Modul des Ger te Controllers Funktionen zum Ausgeben von Nachrichten oder Debug Meldungen F r weitere Informationen sei auf die Source Codes zu diesem Modul verwiesen Das MIB Modul verwaltet die Informationsbasis MIB steht hier f r Management Information Base Diese baumartige Struktur wird technisch mit assoziativen Arrays realisiert Jeder Zweig ist selbst wieder ein assoziatives Array Die Bl tter dieses Baumes 60 stellen Funktionszeiger dar Bei Anfragen an eines dieser Blatter von seiten des Klienten wird diese Funktion mit den REST Parametern aufgerufen Diese REST Parameter beinhalten die Aktion GET DELETE die URI und optionale Daten Mit diesen Parametern kann die aufzurufende Funktion genau ermitteln was nun zu tun verbleibt Dies hat folgende Vorteile Wenn ein Ger t z B ein Temperatursensor auf dem Bus entdeckt wird so kann die MIB eine Klasse eines Temperatursensors instanziieren und die Daten dieses Sensors in der MIB ver ffentlichen Die Ver ffentlichung geschieht indem den neuen Bl ttern Methoden dieses Objektes zugewiesen werden Anfragen an diese Bl tter werden dann konkret in dem zugeh rigen Objekt verarbeitet Da auch andere Objekte in den Baum hinein geladen werden k nnen stellt dies eine besonders generische Methode dar So k nnen auch sp ter neue 1W Ger te nur durch die Erstellung einer Klasse unterst tzt werden Das MAP Modul dient dazu d
37. d hci resources area bok papers p94 weiser pdf 24 05 2007 Karl Aberer Manfred Hauswirth Ali Salehi Middleware support for the Internet of Things Fachgesprach Drahtlose Sensornetze Universitat Suttgart 2006 ftp ftp informatik uni stuttgart de pub library ncstrl ustuttgart_fi TR 2006 07 TR 2006 07 pdf 25 05 2007 87 Abbildungsverzeichnis Abbildung 1 IP f hige Knoten nennen nenn unse essen 12 Abbildung 2 Ger teanschluss ber Gateway cccccccccccessseeceesenneeeeseneeeeeeneeeesseeeeeeseaeeeeesnteeeeseaas 13 Abbildung 3 Knoten und Ger te Controller oooooooconnnonccnnoncccnononnnoncnnnnnnnnononnnnnonnnnnnncnnonnnnnnnnnnnnnnnnnnrs 23 Abbildung 4 Peer und Ger te Controller 24 Abbildung Se A Ai 27 Abbildung 6 Knoten in der Gesamtstruktur non rnnnan rra nonannss 33 Abbildung 7 1W Master und Slaves cccccccccssccesesneceesssneeeecseneeceeseaeeeeseaeeeesseeeeseseaeeeeeseteeeensaes 36 Abbildung 8 Ger te Controller in der Gesamtestruktur 36 Abbildung 9 Peer Applikation in der OGesamtstruktur 38 Abbildung 10 1W Bus in der Gesamtstruktur cccccccccssscccesenteceesenneeeessseeeeeseteeeeeseaeeeeesnteeeesseaas 41 Abbildung 11 Kommunikation in der Gesamtstruktur 0sssseeeseeeeeeeeeeesseeeessetessrrtesssstesssressssrees 42 Abbildung 12 Paketstruktur nn conan nn r conan nr rr non nn rr nnnn rra rnnannrs 46 Abbildung 13 Nachrichtenschicht ccccccccccssscccesesseeceessneeeeeseneeeeeseneeees
38. den w hrend der Architektur und Entwurfsphase als Richtlinien dienen 21 Architektur Basierend auf den ausgew hlten Konzeptionskriterien soll das Rahmenwerk in diesem Teil des Dokumentes dargestellt werden Trotzdem bleiben noch einige Entscheidungsfragen offen Es wurde noch nicht geklart was genau dieses Rahmenwerk zu leisten im Stande sein soll Da es sich um ein Rahmenwerk handelt und beliebig ausgebaut werden kann soll sich in dieser Diplomarbeit haupts chlich auf die Funktionsfahigkeit der entworfenen Konzepte konzentriert werden Konkrete Leistungsf higkeit in einem bestimmten Applikationsfeld ist nicht das bergeordnete Ziel Dennoch sollte zwecks Demonstration ein konkretes einfaches Anwendungsbeispiel realisiert werden Knoten Die erste Frage die sich stellt ist die der Knoten Was ist ein solcher Knoten und was genau ist er im Stande zu leisten In diesem Rahmen sind solche Knoten die unterste Stufe ansteuerbarer Bauelemente Diese Bauelemente sollen die Schnittstelle zwischen der Elektronik der Anwendung und der realen Welt bilden Da sich Gegenst nde des Alltags anbinden lassen sollten ist eine generische Schnittstelle w nschenswert Aber was ist eine solche generische Schnittstelle Jegliche physikalische Gr e l sst sich mittels entsprechenden elektronischen Schaltungen in elektrische 22 Spannungen umwandeln Mittels eines einfachen AD Wandlers l sst sich nun die zu messende Gr e digital erfass
39. den werden einige Mikrocontroller mit ihren Vor und Nachteilen vorgestellt RCM4000 RabbitCore Der RCM4000 ist ein eingebettetes Netzwerk und Kontrollmodul Dieses Modul verf gt ber 512K Flash und 512K SRAM ber diese Eigenschaften hinaus verf gt dieses Modul ber diverse E A Schnittstellen Entwickelt wird mit einem mitgelieferten C Compiler Preis dieses Moduls liegt bei 56 bei einer Anzahl von 100 St ck MAXIM IC Tini Networked ist der Name eines Mikrocontroller vom Hersteller Maxim IC Dieser Mikrocontroller verf gt ber einen integrierten 1W Master sowie diverse andere E A Schnittstellen Von Maxim IC wird ein fertiges Modul angeboten Dieses Modul verf gt ebenfalls ber 512Kb RAM und 512Kb Flash Der Preis liegt bei 110 f r ein komplettes Modul Allerdings liegt der Preis dieses Mikrocontrollers bei nur 8 bei einer Anzahl von 100 St ck 38 Vergleich der Mikrocontroller Neben den beiden genannten Mikrocontrollern existieren noch eine groBe Anzahl an anderen Produkten Die meisten dieser nicht genannten Mikrocontroller verf gen jedoch nicht ber eine Ethernet Schnittstelle Andere m chtigere Mikrocontroller z B von Freescale besitzen solche F higkeiten allerdings unter anderen Preisbedingungen Da der Tini Networked Mikrocontroller ber einen dedizierten 1W Master verf gt f llt die Wahl auf das Produkt von Maxim IC Der Tini Networked Mikrocontroller ist kompatibel zum klassischen 8051 Mikrocon
40. die auf dem Markt existieren werden hier nur drei bekannte Vertreter vorgestellt CAN Bus CAN steht f r Controller Area Network und bildet einen Bus zur Kommunikation mit Sensoren und Aktuatoren Urspr nglich wurde der CAN Bus von Bosch eingef hrt um die Kabell nge in Automobilen zu reduzieren Der CAN Bus erfreut sich durch seine Ausgereiftheit gro er Verbreitung Dieser Bus benutzt 2 Leitungen f r die Kommunikation und 2 f r die Energieversorgung 12C Bus DC steht f r Inter Integrated Circuit Es handelt sich hierbei um eine Entwicklung von Philips Der I2C Bus kommt zum Einsatz um elektronische Komponenten miteinander zu verbinden Allerdings sind hier kleine bertragungsraten vorausgesetzt Weiterhin kann der I2C Bus nicht ber Distanzen von mehreren Metern kommunizieren Urspr nglich war der I2C Bus dazu entwickelt worden um lokal innerhalb eines Ger tes zu agieren Zur Kommunikation ben tigt der I2C Bus lediglich zwei Dr hte 35 1W Bus Der 1W Bus ist eine propriet re L sung von Maxim IC Dieser Bus dient als Kommunikationsmedium f r 1W Ger te MAX1 die ebenfalls von Maxim IC hergestellt werden Es gibt keinen bestimmten Verwendungszweck f r diesen Bus Genau hier liegt seine St rke Der Bus kann ber eine maximale Distanz von 300 Metern noch mit seinen Ger ten kommunizieren Weiterhin ben tigt dieser Bus lediglich 2 Leitungen Die angeschlossenen 1W Ger te k nnen die ben tigte Energ
41. dig dass das Rahmenwerk so flexibel und erweiterbar ist wie m glich Dadurch dass Anwendungen erst durch den Nutzer entwickelt werden darf das SASI Rahmenwerk nicht einschr nkend auf die M glichkeiten wirken damit der Entwickler alle denkbaren Anwendungen realisieren kann Die Flexibilit t betrifft in erster Linie die unterst tzten Knoten und andererseits die Schnittstelle die der Klient Applikation angeboten wird Beide Aspekte werden im Kapitel der Architektur n her diskutiert Die Erweiterbarkeit betrifft die Unterst tzung von neuen Knotentypen Das Rahmenwerk soll ohne hohen Entwicklungsaufwand um neue Knotentypen erweiterbar sein Schnittstelle zum Internet Die Wahl der Service Architektur und der Schnittstelle hin zur Nutzung des zu entwerfenden Rahmenwerks bildet ein zentraler Punkt der Problemstellung Da das zu entwerfende System ein Rahmenwerk darstellt und nicht eine konkrete Applikation erf llen muss sollte die Schnittstelle m glichst offen und generisch sein Mit offenen und generischen Schnittstellen l sst sich sp ter eine konkrete Applikation mit weniger Aufwand realisieren 20 Die Wahl der Service Architektur sollte ebenfalls eine m glichst einfache und zustandslose sein Die Zustandslosigkeit vereinfacht Ad Hoc Anfragen die in einem Ubiquitous computing Szenario durchaus dem Normalfall entsprechen Konzeptionskriterium f r das Rahmenwerk e Generische einfache und zustandslose Schnittstelle f
42. ds oder TCP SYN floods berlasten und damit funktionsunt chtig machen Ein weiterer m glicher Ansatz f r DoS Angriffe auf diese Ger te wird durch die Komplexit t der Protokolle selbst eingef hrt Komplexe Netzprotokolle wie z B TCP IP oder Ethernet machen besonders low level programmierte Mikrocontroller fehleranf llig Solche Programmfehler k nnten f r DoS Angriffe ausgenutzt werden Dieser Sachverhalt verschlimmert sich dadurch dass bei einer Vielzahl von Ger ten unterschiedlicher Hersteller eine Vielzahl von unterschiedlichen IP Stack Implementierungen existieren jedes mit potentiellen Schwachstellen Durch letztere Argumente ist die berzeugung gereift dass eine direkte Anbindung von Knoten an das Benutzernetz z B Internet vermieden werden sollte Diese Erkenntnis soll f r den Rest der Diplomarbeit vermerkt werden 16 Konzeptionskriterium f r das Rahmenwerk e Keine direkte Anbindung der Knoten an das Internet Das alternative besprochene Konzept das aktuell gerne eingesetzt wird besitzt ebenfalls Schwachstellen Das Benutzen eines PC Systems als Gateway zwischen Knoten und WAN ist ein guter Ansatz um die Knoten zu sch tzen Allerdings entsteht dadurch ein Single point of failure Durch komplexe Betriebssysteme und komplexe Hardware leiden PC basierende Systeme unter einer zu geringen Ausfallsicherheit Optimalerweise w ren 100 Verf gbarkeit das anzustrebende Ziel Aus diesem Wunsch heraus entsteht ein weit
43. e Prinzipiell soll SCADA andere Bed rfnisse als die in der Problemstellung genannten befriedigen Dies erkl rt auch den vermehrten Einsatz von Remote Terminal Units mit denen h here Kosten als die hier tolerierten einhergehen Dennoch kristallisiert sich aus SCADA der Ansatz heraus dass Knoten von Ger te Controllern berwacht und geregelt werden Diese Aufgabe wird in SASI vom Ger te Controller durchgef hrt zwar nicht in Form eines Programmable Logic Controller Mikrochips sondern in Form eines Mikrocontrollers Dies ist nicht die einzige Analogie zwischen SASI und SCADA So ist der Trend hin zu Web SCADA auch ein fester Bestandteil des SASI Rahmenwerks WSN Ungleich dem Vorgehen in dieser Diplomarbeit trifft man h ufig bei Sensor Netzwerken auf das so genannte WSN WSN steht hier f r Wireless Sensor Network Hierbei will man von vornherein Sensoren und Aktuatoren drahtlos anbinden Jeder Knoten in einem solchen WSN besitzt eine Radioeinheit um mit dem drahtlosen Netzwerk zu kommunizieren Die Kommunikation zwischen den einzelnen Knoten ist nicht auf ein Standard festgelegt Allerdings wird gerne auf den ZigBee Standard zur ckgegriffen Solche Produkte werden bereits vertrieben Ein solcher Hersteller ist z B Crossbow Dessen Wireless Measurement System Mica 2 ist ein solcher Knoten der eine generische Schnittstelle zum Sensor Aktuator besitzt z B UART I2C und andere Die Herstellung des http www xbow com
44. e globalen Richtlinien aufgelistet e Hohe Ausfallsicherheit und Verf gbarkeit e Geringe Kosten e Generische Schnittstellen e Flexibilit t und Erweiterbarkeit Das Kriterium der hohen Verf gbarkeit wurde mit diversen Methoden realisiert So wurden z B ausgereifte Technologien Redundanz sichere Protokolle dazu verwendet um die Ausfallsicherheit zu maximieren Das speziell f r diesen Anwendungszweck entwickelte Protokoll benutzt Hashfunktionen um sicherzustellen dass Pakete nicht durch Dritte manipuliert werden Klassische Angriffsverfahren werden mit diesem Protokoll weitgehend verhindert 68 Die Minimierung der Kosten wurde haupts chlich durch die berlegung umgesetzt dass die Intelligenz der Knoten hin zu einer einzigen Komponente verlagert wird Mit dieser berlegung l sst sich auf jedem Knoten eine Ersparnis erzielen die in der Summe betr chtlich ausfallen kann Mit der REST Architektur wurde eine Wahl getroffen die sich bereits in Protokollen wie dem HTTP bewiesen hat Die Wahl einer baumartigen Informationsbasis als Datenstruktur ist sehr kompatibel zur REST Architektur und erm glicht eine st ndige Erweiterbarkeit die zugleich v llige Abw rtskompatibilit t gew hrleistet Der Einsatz von HTTP als Kommunikationsmedium f r die REST Anfragen unterst tzt zus tzlich die Zug nglichkeit dieses Services Die Einspeisung einer REST Anfrage in das Rahmenwerk wurde auf einfachste Weise durch das POSTen einer XML Datei a
45. edoch von der Software nicht registriert w rde da diese den Bus mit der Suche nach neuen Ger ten besetzt Mit diesem Argument sollte die Software den Bus nur nach einem festzulegenden Intervall von einigen Sekunden scannen Dadurch erh ht sich die Wahrscheinlichkeit dass ein Tastendruck festgestellt werden kann 42 Ein weiterer Fall der ber cksichtigt werden muss ist der der Offline Knoten die nicht mehr mit dem Bus verbunden sind Das Ansprechen der Knoten zum Ermitteln ihrer Zust nde kann zu Fehlern f hren Bevor Knoten angesprochen werden sollte sichergestellt werden dass diese auch tats chlich mit dem Bus verbunden sind Eine entsprechende Routine ben tigt nur einige Millisekunden und kann somit vor jedem Zugriff ausgef hrt werden Ein weiterer Aspekt ist der dass Knoten nur dann Daten bermitteln k nnen wenn diese angesprochen werden Somit kann ein Knoten den Master nicht selbstst ndig ber ein Ereignis informieren Im Beispiel eines Tastendrucks w rde ein Master den Tastendruck nicht registrieren es sei denn er w rde gerade zu diesem Moment diesen Knoten abfragen Dies f hrt dazu dass die Software so schnell und so oft wie m glich alle angeschlossenen Knoten abfragen muss Dieses Problem des aktiven Pollens w re im Produktiveinsatz sicher nicht vertretbar Zur Vermeidung des aktiven Pollens ist eine andere Bus Technologie sicher sinnvoller jedoch reicht der 1W Bus f r den Demonstrator dieser Diplomarbeit aus
46. eeaeeesseseeeseseaeeeeeseeesenseaas 48 Abbildung 14 Peer Applikation in der Gesamtstruktur 49 Abbildung 15 Informationsbasis ccccccccccesseceesesneeeeeesneeeeeseneeeeesenaeeeessaeeeesseeeeeeseaeeeesseteeeensnaes 51 Abbildung 16 Ger te Controller in der Gesamtstruktur 0snsesseeeeeeeeeeesseeeesseeesssetetssseesssrtsssreee 54 Abbildung 17 Peer Applikation in der Gesamtstruktur 58 Abbildung 18 BiRest E 61 Abbildung 19 Klient Souree Co de 0 8888882H0u tas 64 Abbildung 20 Gesamtarchitektur cccccecccccceseceesenneeeesesneeeeesenaeeeeseaeeeessaaeeceseeeeeeseaeeeeesaeeeessaas 71 88 Abkurzungen 1W ACK ATM CAN DoS ETH GSN HMI HTTP 10 DC IP ISO JVM KISS LAN MIB NAK NIC OSI PC PLC REST RFC ROM RPS RTU SASI SCADA SNMP SRAM STCP Onewire Technology from Maxim IC Acknowledgement Asynchronous Transfer Mode Controller Area Network Denial Of Service Ethernet Global Sensor Network Human Machine Interface Hypertext Transfer Protocol InternetO Inter Integrated Circuit Internet Protocol Internationale Organisation fiir Normung Java Virtual Machine Keep it Short and Simple Local Area Network Management Information Base Negative Acknowledgement Network Interface Card Open Systems Interconnection Personal Computer Programmable Logic Controller Random Access Memory Representational State Transfer Request for Comment Read Only Memory Remote Power Switc
47. ehe Abbildung 7 5 www maxim ic com 36 Prilsarleilurg Zuale Zonlealle Wed T She SE Tl Thittlasler Ni SS Masse Abbildung 7 1W Master und Slaves Ger te Controller und Vernetzung Peer Applikalien SSC Klient Applikaticn Peer Applikalien Controller Mikrocontroller Abbildung 8 Ger te Controller in der Gesamtstruktur Kncten knotten Kee knaten Nach der Auswahl der Knoten und des Busses steht die Auswahl des Ger te Controllers an erster Stelle siehe Abbildung 8 Aus bereits erw hnten Gr nden sollte es sich beim Ger te Controller um ein einbettbares Ger t handeln Idealerweise ein Mikrocontroller DSP oder FPGA Da die Aufgaben die der Ger te Controller bernehmen soll zu komplex f r FPGAs sind wird auf diese verzichtet Digitale Signalprozessoren sind eher darauf ausgerichtet kontinuierliche Str me von Daten zu verarbeiten Dies ist hier nur grenzwertig der Fall Schlussendlich bleibt noch die Option eines Mikrocontrollers Mikrocontroller erh lt man in einer groen Variationsbreite Somit ist die Chance gegeben dass f r den n tigen Verwendungszweck ein solcher Mikrocontroller existiert Bevor jedoch auf die verf gbaren Mikrocontroller eingegangen werden soll sollte die Kommunikationstechnologie zwischen Peer und Ger te Controller b
48. elt zu berlasten Allein die Komplexit t und Anzahl der Protokolle bedeuten einen nicht unwesentlichen Anteil an Rechenzeit f r einen Mikrocontroller Es ist durchaus m glich einen integrierten Webserver ohne Absicht zu berlasten Bei gleichzeitigem Zugriff mehrerer Nutzer k nnen schnell die Ressourcen aufgebraucht werden und das Ger t kann nicht mehr zuverl ssig genutzt werden Prinzipiell ist die Skalierbarkeit dieser Mikrocontroller doch recht schwach Auch dies wird der Anforderung nach hoher Verf gbarkeit nicht gerecht Verf gbarkeit ist ein wichtiges Merkmal das jedoch in diesem Fall nur beschr nkt gew hrleistet werden kann Ein weiteres Argument das gegen die Konzeption des Embedded Internet Computing spricht ist die der dezentralen Speicherung von Authentifikationsdaten Bei mehreren Ger ten die alle verschiedene Zugangsmechanismen oder verschiedene Authentifikationsdaten besitzen kann es leicht zu einem nicht mehr einfach verwaltbarem Netz kommen Dies ist durchaus realit tsnah Ein Beispiel w re das eines Haushaltes der im Besitz einer IP Kamera ist und zus tzlich noch einen Router besitzt Bereits hier m ssen zwei Ger te konfiguriert werden Die Konfiguration geschieht in der Regel ber integrierte Web Server Somit muss der Nutzer zwei Zugangsinformationen f r zwei Ger te bereithalten Bei einer Allgegenwart von intelligenten Gegenst nden nach Ma des Ubiquitous computing w ren dies dutzende an Aut
49. en Da jegliche zu messende Gr e durch eine entsprechende elektronische Schaltung erfasst werden kann kann man davon ausgehen dass ein AD Wandler eine ausreichende Eingabemethode ist Jeglicher Knoten in diesem Rahmenwerk der irgendeine Funktion erf llt erh lt Eingaben in irgendeiner Form und dr ckt die Zustands nderung durch Ver ndern von Ausgabegr en aus Ein Ausgabekanal in Form eines Schalters ist somit auch eines der wesentlichen F higkeiten eines Knotens Neben diesen beiden einfachen Ein und Ausgabemethoden soll noch ein Identifikationsmodul mit eingeplant werden Es sei angemerkt dass die Einfachheit dieser Knoten das Konzeptionskriterium der Kostenminimierung befriedigen Einfache Schalter oder AD Wandler Bausteine sind in gro en St ckzahlen zu Centpreisen erh ltlich Nachdem nun definiert wurde was Knoten f r Funktionen erf llen m ssen muss die Anbindung dieser Ger te an das Kommunikationsnetz bedacht werden Verwaltung Laut einem der Kriterien sollte es vermieden werden die Knoten direkt an ein IP Netzwerk anzubinden insbesondere dem Internet Somit werden potentielle DoS Angriffe von au en schon von vornherein vermieden Das Nutzen eines Gateway ist somit unumg nglich Laut einem anderen Kriterium sollten PC basierende Systeme als Gateway aus genannten Gr nden vermieden werden Dies f hrt direkt zur Wahl von kleinen Signalprozessoren oder Mikrocontrollern Diese w rden die Rolle bernehmen die Kn
50. en des Peers entgegennehmen kann Es erh lt somit Notifikationen ber Ereignisse der Knoten und kann entsprechend reagieren Dieses Programm ist sehr klein und l sst sich einfach ab ndern um die gew nschte Logik zu realisieren Hiermit sind beliebig komplexe Verhalten m glich Schlussendlich soll noch kurz auf das Map Modul eingegangen werden Dieses Modul ist optional und dient dem Zweck die MIB in eine andere Form zu transformieren Die original MIB ist f r manche Zwecke zu nahe an der Technik So werden z B Knoten mit ihren Seriennummern aufgelistet Beispiel raw devices switches 1A VB05165 Bei diesem Beispiel handelt es sich um ein Knoten mit dem man schalten kann Es ist in der Praxis sinnvoller diesem Knoten einen Namen zu geben Diesem Zweck dient das Map Modul Das Map Modul wandelt also URIs um So kann man die MIB ganz der Zweckm igkeit des Projektes anpassen Die Mapping Regeln werden in der Datei map conf angegeben Die Datei enth lt einige Kommentare die die Regelsyntax verdeutlichen Weiterentwicklung In diesem Teil wird auf die Weiterentwicklung des SASI Rahmenwerks eingegangen Als erstes wird auf den Ger te Controller und die Knoten eingegangen Im weiteren Teil wird die Erweiterung der Peer Applikation erl utert Es ist ratsam den ersten Teil dieses Kapitels zu lesen um die grundlegende Architektur des SASI Rahmenwerks zu verstehen 77 Knoten Es gibt eine gro e Anzahl von 1W Ger
51. er Verbreitung unterliegen und dadurch ausgereifter und g nstiger auf dem Markt erh ltlich sind Die Wahl der Technologie wird auf den n chsten Teil der Diplomarbeit verlagert in dem die Auswahl der Technologie diskutiert wird Klient Applikation Die Klient Applikation ist die Applikation die vom Nutzer eingesetzt wird um eine bestimmte Anwendung zu realisieren Die Klient Applikation wird vom Nutzer entwickelt und benutzt die SASI API zu Realisierung der angestrebten Anwendung Die zur Verf gung gestellte SASI API kapselt die Kommunikation zwischen Peer Applikation und Klient Applikation in einem Modul und ist aktuell f r Python verf gbar Die Kommunikation zwischen Peer Applikation und Klienten ist ma geblich durch die gew hlte Service Architektur gepr gt die im folgenden Teilkapitel diskutiert wird Service Architektur Im Folgenden wird die Service Architektur der Peer Applikation die f r die Kommunikation zwischen Peer Applikation und Klienten ma geblich ist besprochen Eine einfache Service Architektur stellt REST dar REST ist ein zustandsloses Client Server Protokoll in der keine dauerhafte logische Verbindung besteht Eine REST Anfrage enth lt alle notwendigen Information um die Anfrage zu verstehen Eine Anfrage besteht aus einer URI die eindeutig einer Ressource zugeordnet werden kann Zus tzlich zu dieser URI existiert noch der TYP der Aktion die auf die URI angewendet werden soll Optional k nnen zu der angegebenen
52. eres Entwurfskriterium f r das zu planende Rahmenwerk Konzeptionskriterium f r das Rahmenwerk e PC basierendes System als Gateway vermeiden Ein weiterer Punkt der wichtig in Zusammenhang mit Ausfallsicherheit ist ist der der Kommunikation Welche Kommunikationskan le zwischen Knoten und Internet sollten eingesetzt werden Komplexe Netzwerktechnologien beeinflussen die Stabilit t f r einfache Zwecke negativ Die bereits erl uterten Gr nde hierf r werden noch mal kurz in Erinnerung gerufen Hohe Anspr che an die Software von Knoten k nnte vermehrt zu Fehlern im Code f hren Der direkte Zusammenhang von Fehleranzahl und Programmgr e ist erwiesen Mit dieser Erkenntnis ergibt sich ein weiteres Konzeptionskriterium Konzeptionskriterium f r das Rahmenwerk e KISS keep it short and simple Das KISS Prinzip vereinfacht das Auffinden von Fehlern im Rahmenwerk dadurch dass die Zustandsmenge kleiner ist als die komplexerer Systeme und dadurch das Auftreten von Fehlern sich schneller manifestiert und diese somit schneller behoben werden k nnen Besonders den Kommunikationsprotokollen sollte gro e Aufmerksamkeit gewidmet werden Sichere Protokolle sind das R ckgrad f r sichere Kommunikation So sollten nur bew hrte Protokolle und Verfahren zum Einsatz kommen f r die aktuell keine Schwachstellen bekannt sind Dies f hrt zu einem weiteren Konzeptionskriterium 17 Konzeptionskriterium f r das Rahmenwerk e Bew hrte K
53. eres Konzeptionskriterium Konzeptionskriterium f r das Rahmenwerk e Auslagerung der Intelligenz aus den Knoten Um eine weitere Kostensenkung zu erreichen sollte die Wahl der Technologien auf solche fallen die weiter Verbreitung unterliegen Technologien die weit verbreitet sind sind in der Regel durch Massenproduktion kosteng nstiger Weiterhin ist dies auch ein Argument das f r die Ausfallsicherheit gilt verbreitete Technologie ist in der Regel ausgereifter Konzeptionskriterium f r das Rahmenwerk e Technologien nutzen die weiter Verbreitung unterliegen 19 Ein weiterer Gedanke gilt der Kommunikation Je einfacher die Kommunikation der Knoten um so weniger Anforderungen werden an das Kommunikationsmedium gestellt Relativ komplexe Technologien wie ATM oder Ethernet stellen gr ere Anforderungen an das K nnen der Knoten Da Knoten keinen gro en Durchsatz besitzen und auch die Antwortzeiten nicht kritisch sind w re die Wahl einer sehr einfachen Technologie vorteilhaft Auch hier tritt wieder das KISS Prinzip zu Tage je weniger Anspr che wir an die Knoten stellen desto billiger werden auch die Einzelpreise Konzeptionskriterium f r das Rahmenwerk e Einfache Kommunikationstechnologien w hlen Flexibilit t und Erweiterbarkeit Da das SASI Rahmenwerk in erster Linie eine Middleware ist bietet SASI nur Schnittstellen an die zur Kommunikation mit den Knoten genutzt werden k nnen In diesem Fall ist es notwen
54. erks starten Der erste Teil der Peer Applikation der sich im NAT Netzwerk befindet wird sich mit dem sich au erhalb befindlichen Peer Teil verbinden Es besteht nun eine logische Verbindung zwischen dem Peer im NAT Netzwerk und dem Peer Teil der sich au erhalb befindet Die Klient Applikation wird nun Anfragen an den Teil der Peer Applikation richten der sich au erhalb des NAT Netzwerks befindet Dieses Teil wird die Anfragen nun durch die NAT H rde hindurch an die Peer Applikation im NAT Netzwerk durchreichen Das biRest Modul erm glicht es der Klient Applikation REST Aktionen durch die NAT H rde hindurch an die Peer Applikation durchzureichen So lassen sich auch au erhalb des LAN Netzwerks die Knoten nutzen LAN Internet IF Pee Aontzzhrt i y Feer Aap cater Kler btoiksht If L Faer La tas Dies ar ai Kier eck Mi Mal n mn tk Abbildung 18 BiRest Fir weitere technische Details tiber die Peer Applikation sei an das Entwicklerhandbuch im Anhang oder an den Anhang Peer Software verwiesen Auch die Source Codes sind eine gute Informationsquelle diese sind auch in Form von Doxygen Dokumenten verf gbar 62 Einsatz In diesem Kapitel soll die Funktionsf higkeit mittels eines praktischen Fallbeispiels nachgewiesen werden Hierzu wird ein Beispielszenario konstruiert das mittels eines realen Demonstratoraufba
55. erwiesen Ger te Controller Software PC basiert python Peer Applikation FT Klient i i Applikation Peer Applikation Controller Tini Networked Mikrocontroller Knoten Knoten Ve Knoten Abbildung 16 Ger te Controller in der Gesamtstruktur 55 Der Ger te Controller spielt eine zentrale Rolle im gesamten Rahmenwerk siehe Abbildung 16 Im Kapitel der Technologiewahl wurde f r den Ger te Controller der Tini Networked Mikrocontroller von Maxim IC ausgew hlt Die Wahl der Programmiersprache fiel aus genannten Gr nden auf C Neben diesen Entscheidungen wurden auch einige Kriterien an die Software selbst gestellt So sollen statische Speicherzuteilungen den dynamischen vorgezogen werden Weiterhin muss die Software so konzeptioniert sein dass der 1W Bus so oft wie m glich abgefragt werden kann Aktives Warten ist somit nicht erw nscht Um aktives Warten zu vermeiden m ssen alle E A im non blocking Modus betrieben werden Da der KEIL Compiler der hier zur Verwendung kommt nur C unterst tzt sind objektorientierte Entwurfsmethoden nicht m glich Um dennoch ein gewisses Ma an Modularit t zu gew hrleisten werden unterschiedliche Aufgabengebiete in abgeschlossenen Modulen gekapselt Diese Module sollten in einen Hauptkern eingef gt werden Idealerweise sollte die einzige Schnittstelle zwischen dem Kern und den Modulen
56. esprochen werden da dies ein beschr nkender Faktor bei der Auswahl des Mikrocontrollers ist 31 Laut Konzeptionskriterien soll eine direkte Anbindung des Ger te Controller an das Internet vermieden werden Stattdessen soll eine Art Gateway dazwischen geschaltet werden Dieses Gateway wurde Peer genannt Welche Kommunikationstechnologie zwischen Peer und Ger te Controller zum Einsatz kommen soll ist Thema des folgenden Abschnitts Die im Kapitel Problemstellung aufgestellte Liste an Konzeptionskriterien enth lt ein Kriterium bez glich Kommunikationstechnologien Die Kommunikationstechnologie sollte weiter Verbreitung unterliegen und somit Ausgereiftheit und reduzierte Kosten implizieren Die meist eingesetzte Kommunikationstechnologie bei Vernetzung von Rechnern ist Ethernet Durch die weite Verbreitung sind alle Komponenten zum Aufbau einer Ethernet Verbindung kosteng nstig erh ltlich Dieser Sacherverhalt spiegelt sich auch in der Unterst tzung von Ethernet in der Mikrocontroller Welt nieder Mikrocontroller mit der Option Ethernet Treiber anzuschlie en sind weit verbreitet Einige Mikrocontroller unterst tzen Ethernet sogar direkt Optimalerweise w re bei der Wahl des Mikrocontrollers auf native Ethernet Unterst tzung zu achten Die Verwendung von Ethernet als Kommunikationstechnologie erm glicht es auch mehrere Peers gleichzeitig ansprechen zu k nnen Zum Beispiel bei der Wahl von USB w re dies nicht m glich gewesen Im Folgen
57. h angemeldet oder abgemeldet hat Wenn der Fall eintritt dass Karl Heinz sich anmeldet So wird eine REST Aktion an den Peer gerichtet die der Ressource tuerschloss state den Wert 1 zuordnet Das SASI Rahmenwerk setzt dieses um und teilt dem Ger te Controller mit dass der Zustand dieses Knotens ge ndert werden muss Abschnitt 3 Im untersten Abschnitt wird der Main Thread solange warten bis ein Abbruch mittels CTRL C erzwungen wird Das Programm wird in dem Fall beendet Versuch Um den Erfolg der Konzepte und Methoden die in SASI zum Tragen kommen zu demonstrieren m sste sich der Demonstrator gem dem erl uterten Szenario verhalten Wie erwartet verh lt sich der Demonstrator wie es das Szenario voraussetzt Beim Einlegen des ID iButton wird innerhalb weniger Augenblicke dieses Ereignis bis hin zur Klient Applikation durchgereicht Die Klient Applikation wird alle n tigen Schritte unternehmen um die T r zu ffnen Bei Entfernen des ID Button wird die T r wie erwartet verschlossen Allerdings hat sich in diesem Versuchsaufbau auch eine Schwachstelle aufgezeigt Das Scannen des Busses wird nur alle paar Sekunden durchgef hrt Dieses Intervall ist frei w hlbar sollte aber aus bereits behandelten Gr nden nicht zu gering ausfallen Durch dieses Intervall kann es durchaus l nger dauern bis der ID iButton erkannt wird und das Schloss ffnen kann 66 Eine weitere Schwierigkeit ergab sich manchmal durch d
58. h Remote Terminal Unit Secure Attachment of Sensors to the Internet Supervisory Control and Data Acquisition Simple Network Management Protocol Static Random Access Memory Secure TCP TCP UDP URI USB WAN WWW XML 89 Transmission Control Protocol User Datagram Protocol Uniform Resource Identifier Universal Serial Bus Wide Area Network World Wide Web Extensible Markup Language
59. hentifikationsdaten Gew nscht w re eine zentrale Konfigurationsstelle 15 Beide Ans tze die angesprochen wurden besitzen unzufriedenstellende Merkmale Einen PC als Gateway zu nutzen ist zu kostenintensiv und die Alternative der Embedded Internet Computing Ger te besitzt ebenfalls einige nicht zu verachtende Schwachstellen Gesucht wird nach einem Konzept das Vorteile beider Ans tze nutzt und die Schwachstellen versucht zu minimieren Die Ziele sind klar definiert e Hohe Verf gbarkeit e Geringe Kosten e Hohe Flexibilit t und Erweiterbarkeit e Generische Schnittstellen zum Internet Hohe Verf gbarkeit Die Allgegenwart der Informatik macht uns immer abh ngiger von ihrer Funktionsf higkeit Wenn Abl ufe im Alltag davon abh ngen ob Ger te einsatzbereit sind oder nicht so f hrt dies unweigerlich zu hohen Anspr chen an die Softwarequalit t der Ger te Besonders in vernetzten Systemen dr ckt sich Softwarequalit t direkt in Ausfallzeit aus Es wurde bereits auf zwei m gliche Konzeptionen f r die Anbindung von Ger ten an das Internet eingegangen Die direkte Anbindung stellt ein wesentliches Sicherheitsrisiko dar Die relativ beschr nkten Ressourcen der eingesetzten Mikrocontroller sind nicht ausreichend um mehrere Benutzer ad quat zu bedienen Weiterhin sind Angriffe auf solche Ger te verh ltnism ig einfach Durch die beschr nkte Rechenkapazit t kann man den Mikrocontroller schnell durch ICMP floo
60. ht hier f r Management Information Base und ist an das Konzept der MIB von SNMP angelehnt Die MIB spielt eine zentrale Rolle im Peer Diese MIB enth lt alle Informationen der Knoten und bietet ebenfalls die M glichkeit die Konfigurationen der Ger te zu ver ndern Da es sich bei der MIB nur um eine Datenstruktur handelt wird ein Adapter ben tigt Dieser Adapter ist ein Teil der Peer Applikation die die MIB ber diverse Schnittstellen der Au enwelt zur Verf gung stellt Mit Au enwelt ist in diesem Kontext das Internet oder ein IP Netzwerk gemeint Die MIB ist nicht die einzige Analogie zwischen der Peer Applikation und SNMP Das zugrunde liegende Kommunikationskonzept der Peer Applikation basiert auf REST Die MIB kann mittels GET PUT POST oder DELETE manipuliert werden Diese REST Anfragen sind an die Schnittstelle der Adapters zu richten Aktuell unterst tzt dieser Adapter eine Web Schnittstelle Anfragen werden per HTTP an den Webserver des Adapters gerichtet Die Anfrage muss eine XML Datei als POST enthalten die die Anfrage spezifiziert Somit lassen sich Anfragen von einem Klienten direkt an den Adapter richten Um allerdings auch die M glichkeit zu bieten asynchrone Notifikationsmeldungen vom Peer zu erhalten ist auch das umgekehrte Verhalten vorgesehen Ein Klient kann alle oder spezielle Knoten abonnieren Das Abonnieren bedeutet hier dass der Klient ber Ereignisse bez glich des abonnierten Knotens informiert
61. ie baumartige Struktur der Informationsbasis in eine andere abzubilden Dies dient dazu den Klienten eine besondere Sicht auf den Baum anbieten zu k nnen Die Original Sicht auf den Baum ist vor allem technisch und somit f r praktische Anwendungen zu unbequem so sind z B I W Ger te mit ihren Seriennummern abgebildet Durch das Map Modul wird es erm glicht URI Adressen in andere abzubilden Beispiel device OAFFAA0043 online Eine GET Aktion auf diese URI w rde 1 oder 0 zur ckgeben Da diese Adresse f r Klienten nicht besonders aussagekraftig ist kann man diese in eine andere abbilden z B von device OAFFAA0043 online zu tuerschloss online Dies w rde dem Klienten den Knoten unter der Adresse tuerschloss online zug nglich machen Das biRest Modul ist eine Besonderheit die bisher noch nicht angesprochen wurde Es ist m glich den Peer in zwei Teile aufzuspalten Verdeutlicht wird die Notwendigkeit dieses Moduls im folgenden Szenario Seien das Sensornetz der Ger te Controller und die Peer Applikation hinter einem NAT Router befindlich Nun w re es interessant sich vom Internet aus mit der Peer Applikation verbinden zu k nnen Da Anfragen vom Internet aus nicht in das NAT Netzwerk durchdringen k nnen kann ein Klient keine Anfragen an die Peer 61 Applikation richten Mit diesem biRest Modul kann man nun ein Teil der Peer Applikation innerhalb des NAT Netzwerks starten und den zweiten Teil auBerhalb des NAT Netzw
62. ie von der Kommunikationsleitung abzweigen Die bertragungsrate liegt bei nur 16 3 Kbit s Dies scheint recht langsam aber angesichts des Verwendungszwecks ist dies immer noch ausreichend Als weiteren Vorteil dient die hohe Anzahl an verf gbaren 1W Ger ten Diese Ger te erf llen diverse Applikationszwecke Erh ltlich sind z B Schalter AD Wandler Temperatursensoren RAM Module und viele andere Vergleich der Busse Angesichts der genannten Vor und Nachteile von CAN DC und dem 1W Bus f llt die Entscheidung eindeutig auf den 1W Bus Angesichts der nur zwei Leitungen und der parasit ren Strombetreibung der Ger te unterst tzt der 1W Bus zus tzlich noch gro e Distanzweiten Die preiswerten 1W Ger te die genau die gew nschten Zwecke erf llen sind dabei noch ein Grund mehr sich f r dieses Produkt zu entscheiden Betrieben wird der 1W Bus mit einem Master auf einer zweidrahtigen Leitung Die so genannten Slaves stellen die Knoten dar Diese Knoten sind alle parallel geschaltet und werden von einem Master geregelt Slave Ger te d rfen den Bus nie von sich aus nutzen Der Master ist in der Lage den Bus zu scannen oder ein einzelnes Ger t anzusprechen und gegebenenfalls zu programmieren Es ist somit w nschenswert dass der Ger te Controller der zum Einsatz kommt ber einen solchen 1W Master verf gt Alternativ k nnen 1W Master Bausteine ber eine serielle Schnittstelle mit dem Ger te Controller verbunden werden si
63. igkeitser nden sollte auf direkte Anbindung von Mikrocontrollern an das Internet verzichtet werden Die begrenzten Ressourcen k nnen DoS Angriffe beg nstigen Es bedarf somit einem Element das den Mikrocontroller und das Internet miteinander verbindet Da dieses Element nicht nur die Br cke zwischen Mikrocontroller und Internet schlagen wird sondern auch andere Funktionen erf llen wird wird dieses Element im Folgenden Peer Applikation genannt Der Ger te Controller stellt somit nur eine Vorstufe dar er regelt lediglich den Bus und die Knoten Alle Informationen des Ger te Controllers werden dann an die Peer Applikation geschickt wo sie dann dem Nutzer in aufbereiteter Form zur Verf gung gestellt werden 24 Eines der Konzeptionskriterien r t zur Vermeidung von PC basierenden Systemen aus Gr nden der Ausfallssicherheit Dieses Problem kann jedoch vermieden werden indem Redundanz eingef hrt wird Konkret bedeutet dies dass der Ger te Controller zul sst dass mehrere Peers gleichzeitig angemeldet sein k nnen Die Informationen des Ger te Controller werden dann an alle Peers gleichzeitig bermittelt Somit sind mehrere Instanzen von Peers mit allen Informationen versorgt Alle Informationen sind somit von mehreren unabh ngigen Rechnern aus verf gbar Die Einf hrung einer Peer Instanz hat auch den Vorteil dass ein Grossteil der komplizierten Aufgaben vom Ger te Controller in den Peer verlagert werden k nnen Diese Verlagerung v
64. im Protokoll Stack f hren Da keine gro en Durchs tze erwartet werden gen gt dieses Protokoll den Anspr chen vollkommen Da es sich beim Ger te Controller um einen Mikrocontroller mit relativ beschr nkter Speicherausstattung handelt wird an den Ger te Controller die Anforderung der Sequenzierung von Paketen nicht aufrecht erhalten Die Sequenzierung w rde einen zus tzlichen Speicherbedarf bedeuten dem durch die knappen Ressourcen nicht Rechnung getragen werden kann Somit werden Pakete die nicht in der gesendeten Reihenfolge empfangen werden nicht durch den Mikrocontroller geordnet Dies wird nicht zu Problemen f hren da Pakete an den Ger te Controller atomare Kommandos enthalten die nicht ber mehrere Pakete geteilt werden k nnen Unter Ber cksichtigung der festgelegten Anforderungen ergibt sich die in Abbildung 12 angegebene Paketstruktur Proto 2 bytes Proto Version 1 byle Magic Cookie 2 byles Packet Type 1 byte Lerg h 2 byles Sequence 4 bytes Session Key Cookie 20 Bytes Hash Verficalion Value 20 Byles Message Type 2 Byles Netto Message Length 2 Bytes Message data Variable size Abbildung 12 Paketstruktur 47 Datenaustausch zwischen Ger te Controller und Peer In diesem Teil soll kurz auf die ben tigten Konzepte f r die Kommunikation auf Applikationsniveau eingegangen werden Das vorgestellte Protokoll arbeitet bis zur Schicht 5 des ISO OSI Modells Da Pakete als Kommunikationsschnittstelle unhandlich f
65. insatz kommt werden in dieser Diplomarbeit entwickelt und implementiert Im Folgenden wird der Begriff SASI verwendet um auf das zu entwickelnde Rahmenwerk zu beziehen SASI steht f r Secure Attachment of Sensors to the Internet Da sich diese Diplomarbeit mit der praktischen Anwendung von Ubiquitous computing besch ftigt sollen die Resultate dieser Arbeit auch in einem praktischen Anwendungsbeispiel aufgezeigt werden Dies impliziert dass geeignete technische Mittel f r den Demonstrator ausgew hlt werden Auf den ausgew hlten Komponenten werden die Konzepte implementiert und schlussendlich demonstriert Gegen Ende wird auf prinzipielle Vor und Nachteile der erarbeiteten Konzepte eingegangen Abgeschlossen wird mit einem Ausblick auf sinnvolle Erweiterungen des Rahmenwerks Aufbau der Diplomarbeit Die Aufgabenstellung dieser Diplomarbeit gliedert sich folgende Teilgebiete Erfassung und Analyse der Problemstellung Konzeption und Analyse einer geeigneten L sung Wahl der technischen Hilfsmittel zur Realisierung der L sung Entwurf und Implementieren dieser L sung Erfolg am Beispiel eines Demonstrators nachweisen In jedem Kapitel wird eine bersicht angeboten bevor sich den eigentlichen Problemen zugewandt wird Jedes Kapitel versucht Kriterien herauszuarbeiten die die Erkenntnisse des jeweiligen Kapitels festhalten Diese festgelegten und explizit angegebenen Kriterien gelten als Richtlinien f r die weitere
66. ird auf den Anhang Ger te Controller Software verwiesen weiterhin werden tiefere Einblicke im Benutzer und Entwicklerhandbuch angeboten 58 Peer Applikation PC basiert python Klient Applikation Ger te Controller Tini Networked Mikrocontroller Knoten Knoten Abbildung 17 Peer Applikation in der Gesamtstruktur Da der Peer Applikation eine zentrale Rolle zukommt soll in diesem Teil der Entwurf etwas ausf hrlicher dargelegt werden siehe Abbildung 17 Die Peer Applikation bildet die Br cke Knoten zwischen den Daten der Knoten und den Klienten die diese Daten nutzen wollen Wie bereits erw hnt bildet die Informationsbasis das R ckgrad der Peer Applikation Jegliche Daten der Knoten werden in diesen Baum eingetragen Mit der eindeutigen Adresse die ein Zweig oder Blatt dieses Baumes besitzt kann der Klient diese Informationen lesen oder manipulieren Bevor auf die Modellierung dieses Baumes in Python eingegangen wird werden die ermittelten Modulgruppen aufgelistet Es ist sinnvoll die Peer Applikation in folgende Module aufzuteilen e Netzwerk Modul e Protokoll Modul e Stream Modul e DASM Modul e Log Modul e MIB Modul e MAP Modul e biREST Modul 59 Das Netzwerk Modul besitzt hnliche Funktionalit ten wie das Netzwerk Modul beim Ger te Controller Dieses Modul sorgt daf r dass das Programm Pakete vom Netz lesen und
67. iteln dazu entschieden das Rahmenwerk in mehrere Teile aufzuspalten Zum einen werden die Knoten ber einen Bus an den Ger te Controller angeschlossen Dieser Ger te Controller verwaltet den Bus und die Knoten Bei Bedarf k nnen sich ber den Ger te Controller so genannte Peers mit dem Ger te Controller verbinden Die Peer Applikationen k nnen ber den Ger te Controller Informationen ber die Knoten beziehen oder die Konfiguration der Knoten ndern Zwecks Redundanz sollte es erlaubt sein mehrere Peers gleichzeitig mit dem Ger te Controller zu verbinden Die oben erl uterte Struktur wird konkret mit folgenden Produkten und Technologien verwirklicht F r die Knoten kommen 1W Ger te zum Einsatz Gew nscht sind AD Wandler E A Ger te sowie ein Temperatursensor und ein ID Chip Diese vier Funktionalit ten werden von jeweils vier verschiedenen 1W Ger ten bernommen Diese vier Knoten werden ber den 1W Bus mit dem Ger te Controller verbunden Der Ger te Controller wird von einem Mikrocontroller Modul von Maxim IC realisiert Auf diesem Modul kommt der Tini Networked Mikrocontroller zum Einsatz Vorteilhafterweise verf gt dieser bereits ber eine 1W Bus Master Komponente sowie ber eine Ethernet Schnittstelle Aus genannten Gr nden wird eine Ethernet Verbindung zwischen Ger te Controller und Peer System bevorzugt Das so genannte Peer System wird aus Portabilit tsgr nden in der Sprache Python realisiert Um eine m glichs
68. itere Art Angriffe gegen TCP zu starten sind so genannte DoS Angriffe Hierbei ist das Ziel den Server unerreichbar zu machen Ein solcher Angriff ist z B TCP Syn flooding Hierbei wird der Server mit TCP Syn Paketen geflutet F r jedes SYN Paket muss der Server auf seinem TCP Stack entsprechende Eintr ge vorsehen Sind keine Ressourcen mehr verf gbar ist der Server vor bergehend nicht mehr ber das Netz erreichbar Beide Beispiele sollten illustrieren dass TCP prinzipiell nicht geeignet ist um die gew nschte Ausfallsicherheit zu erreichen Eine L sung stellt z B STCP dar INET1 STCP bereinigt die beiden erw hnten Probleme sowie einige andere STCP ist leider nicht verbreitet und l sst sich in diesem Fall nicht einsetzen Anders als STCP ist SCTP IETF bereits auf diversen Plattformen wie z B Linux oder FreeBsd implementiert SCTP l st ebenfalls einige der Schwachstellen von TCP und ber cksichtigt noch weitere Aspekte wie z B Multihoming die allerdings in diesem Rahmen keine Rolle spielen Die Implementierung eines eigenen Protokolls scheint somit unausweichlich Basierend auf UDP soll ein sicheres Kommunikationsprotokoll implementiert werden Die Anspr che an dieses Protokoll sollen im Folgenden motiviert werden 44 Anforderungen an das Kommunikationsprotokoll Die bereits erw hnten Probleme die mit TCP einhergehen sollten in dem neuen Protokoll ber cksichtigt und beseitigt sein Da die Peers sich in einer logis
69. keit des Rahmenwerks beweist 41 Kommunikation zwischen Ger te Controller und Knoten PC basiert python i Peer i Applikation i E Klient l Applikation i Peer i Applikation i Ger te Controller Tini Networked I Mikrocontroller Knoten Knoten Wm Knoten Abbildung 10 1W Bus in der Gesamtstruktur F r die Kommunikation zwischen den Knoten und dem Ger te Controller wurde sich f r den 1W Bus entschieden siehe Abbildung 10 Durch die Wahl dieses Busses wurde das Kommunikationsprotokoll schon implizit definiert Es bleiben jedoch einige prinzipielle Fragen offen Der 1W Bus bietet lediglich die M glichkeit an Bytes zu lesen und zu schreiben Die Verwaltung der Ger te muss durch die Software realisiert werden So muss z B das Suchen nach neu angeschlossenen Ger ten explizit durch die Software angeordnet werden Ebenfalls n tig wird das Ermitteln von Ger ten die den Bus verlassen haben Da sich nach einigen Testl ufen herausgestellt hat dass die Suche nach neuen Ger ten bis zu 300ms dauern kann muss eine L sung diesbez glich gefunden werden Ein Grund wieso lang andauernde Zugriffe auf den Bus vermieden werden m ssen ergibt sich dadurch dass gegebenenfalls nicht festgestellt werden kann ob ein Ereignis stattgefunden hat So k nnte z B innerhalb dieser 300ms Periode ein Taster bet tigt worden sein der j
70. konkretes Projekt in dem Sensoren drahtlos im h uslichen Bereich Informationen nach au en zur Verf gung stellen Es gibt einige Analogien zu SASI In diesem Projekt wurden die bereits erw hnten Komponenten von CrossBow verwendet Diese Knoten bermitteln ihre Daten an die Basisstation wo eine Aufbereitung der Daten stattfindet Die Daten werden dauerhaft gespeichert und k nnen ber eine Web XML Schnittstelle abgefragt werden http gsn sourceforge net 30 Die in dieser Diplomarbeit entwickelte Plattform besitzt ebenfalls diese Form von Schnittstelle Interessant an INSIGHT sind die Kosten die hierbei bei ungef hr 100 pro Knoten liegen wogegen bei SASI diese sich im Bereich von 1 bewegen Auch hier sind die Kosten pro Knoten sehr hoch Die Ausstattung einer Wohnung nach Ma des Ubiquitous computing impliziert erhebliche Kosten Weiterhin bedeutet eine drahtlose Verbindung auch dass die Knoten ber eine eigene Energiequelle verf gen m ssen Dies f hrt dazu dass in jedem Knoten nach einer gewissen Zeit die Bewohner oder ein Dienstleister alle Energiequellen austauschen muss INTERNETO Bei InternetO MIT1 handelt es sich um eine interessante Initiative in der man jegliches Objekt in ein IP f higes Endger t verwandeln will Anders hier ist der grundlegende Gedanke alle b rokratischen H rden zu berwinden und weniger Code zu erzeugen Wenn man Schalter oder Lampen IP f hig machen will muss man den Entw
71. lle Aufgaben aufgelistet e Speichern von Fehlernachrichten im Tini Speicher e Garantieren der Erhaltung des Fehlerpuffers auch bei Absturz oder Abschalten des Mikrocontrollers e Versendung des Fehlerspeichers bei Bedarf zum Peer Das 1W Modul kapselt alle n tigen Funktionen um den 1W Bus zu konfigurieren und zu verwalten Weiterhin wird dieses Modul eine Schnittstelle f r Untermodule anbieten in denen 1W Ger te verschiedenen Typs eingebunden werden k nnen Dieses Modul wird hnlich wie der Kern eine minimale Schnittstelle f r Ger te Module anbieten Diese Ger te Module beinhalten alle Routinen die n tig sind um mit einem speziellem 1W Ger t umgehen zu k nnen Im Folgenden sind noch mal alle Funktionen aufgelistet e Initialisieren des 1W Busses e Scannen des Busses nach neuen Ger ten e Aufsp ren von Offline Ger ten e Das Versenden und Empfangen von Nachrichten bezogen auf 1W Ger te e Das Verwalten von nicht unterst tzten Ger ten e Schnittstelle f r Untermodule anbieten e Den Untermodulen regelm ig den Prozessor zuteilen e Notifikationen ber Online oder Offline Status von Ger ten an alle Peers e Notifikation von Ereignissen an alle Peers Neben der ANSI C Kompatibilit t des Source Codes ist das Kapseln von Tini spezifischen Funktionen wesentlich um die Portabilit t auf andere Mikrocontroller zu unterst tzen F r weitere Informationen bez glich der Realisierung der Software f r den Ger te Controller w
72. lung die sich seit einigen Jahren anzudeuten scheint n mlich Das Durchdringen der Informatik in unserem Alltag auf transparente und unscheinbare Art und Weise 11 Dieser Sachverhalt ist Grund genug sich mit einigen Aspekten des Ubiquitous computing zu beschaftigen Im Rahmen dieser Diplomarbeit stehen die technischen Problemstellungen im Vordergrund soziale oder wirtschaftliche Fragestellungen werden in diesem Dokument nicht behandelt Neben klassischen Anforderungen der Informatik ergeben sich auch ganz neue Aspekte die erst in den letzten Jahren an Bedeutung gewonnen haben Auf diese klassischen und neuen Aspekte soll im weiteren kurz eingegangen werden Laut Marc Weiser WEISER sollte diese Allgegenwart der Informatik transparent fiir den Nutzer sein Der Nutzer sollte sich nicht dariiber bewusst sein ob oder wie die Informatik in dem zu benutzenden Gegenstand zum Tragen kommt Dies f hrt unweigerlich dazu dass eine Ausfallzeit von Null erreicht werden sollte Der durchschnittliche Nutzer der nicht ber IT Kenntnisse verf gt sollte nicht mit technischen Problemen des Gegenstandes in Ber hrung kommen Die Ausfallsicherheit kommt besonders dann zum Tragen wenn die Gegenst nde vernetzt werden Aktueller den je ist das Thema der Privatsph re und Vermeidung von unerlaubtem Zugriff auf vertrauliche Daten von privaten Anwendern In Zeiten in denen Sicherheitsl cken in Rechnern dazu genutzt werden um unerlaubt Malwa
73. m Verwendungsfeld dieses Rahmenwerks durchaus den Normalfall darstellen So kann z B ein Klient eine POST Aktion an die Peer Applikation richten ohne vorher am Peer angemeldet zu sein Gesamtarchitektur Motiviert durch die Konzeptionskriterien wurden die folgenden Architekturentscheidungen ermittelt e Verwenden von sehr einfachen Knoten Schalter AD Wandler e Verwenden eines einfachen Busses zwischen Knoten und Ger te Controller e Der Ger te Controller wird auf Basis eines preisg nstigen Mikrocontrollers realisiert e Die Peer Applikation basiert auf PC Systemen e Redundanz auf Peer Ebene sollte mit eingeplant werden e Kommunikation zwischen Klient und Peer sollte auf dem REST Prinzip basieren e Einfache Netztechnologie zwischen Ger te Controller und Peer 27 In Abbildung 5 sind alle Architekturentscheidungen zu einer gesamten Struktur Klient Applikalien zusammengefasst Peer Applikalien Peer Applikalien Garne Controller q Klikrasontraller Abbildung 5 Architektur knoken Kneten kek knaten Andere L sungskonzepte An dieser Stelle wird auf Projekte eingegangen die hnliche Ziele verfolgen wie die in dieser Diplomarbeit Als erstes wird auf grundlegende Konzepte eingegangen die bereits etabliert sind und durchaus auch in der Industrie Verwendung finden SCADA Ein in der Industrie gel
74. ommunikationsprotokolle Kommunikationsverfahren und Kommunikationsalgorithmen verwenden Ein weiterer Aspekt ist die der Softwareprogrammierung Bisweilen wurde nur ber Ausfallsicherheit in Verbindung mit Technologien oder Konzepten diskutiert Die Rolle die dem Softwareentwurf zukommt ist nicht minder bedeutend Prinzipiell sollte sofern m glich auf fehleranf llige Softwaretechniken verzichtet werden Auch wenn zu diesem Zeitpunkt noch kein Entwurf existiert sollen die wichtigsten Tugenden bereits festgehalten werden Konzeptionskriterium f r das Rahmenwerk e Nebenl ufigkeit dynamische Allokation und unbew hrte Komponenten vermeiden Nebenl ufigkeit f hrt oft zu unerwarteten Folgen Dies liegt nicht an der Nebenl ufigkeit selbst sondern eher an Entwicklungsfehlern durch den Programmierer Ein System das nach allen Regeln der Kunst entworfen wurde wird auch dann korrekt funktionieren wenn es massiv auf Nebenl ufigkeit basiert Dynamische Allokation erh ht die Menge an Zust nden in die ein Programm ger t Laufzeitprobleme sollten von vornherein feststehen und bereits im Entwurf mit ber cksichtigt werden Ein pl tzliches out of memory verkompliziert die Fehlerhandhabung wesentlich Ein fr hes Festlegen auf Speicherzuteilungen ist hier ratsam Es sollen bei der Implementierung der Software nur solche Komponenten eingesetzt werden die sich bew hrt haben Das Nutzen von Komponenten deren Reifegrad nicht bek
75. on Code aus dem Ger te Controller beg nstigt die Stabilit t des Ger te Controller selbst denn weniger Codevolumen bedeutet weniger Fehler Da der Ger te Controller ein eingebettetes Ger t ist mit Laufzeiten von Wochen bis hin zu Monaten oder gar Jahren wirken sich Fehler fatal aus Um jedoch zu vermeiden dass ein PC System Vorrausetzung f r den Betrieb des ganzen Systems ist soll der Ger te Controller auch komplett ohne Peers operativ bleiben und die Knoten weiter verwalten k nnen Die Peer Applikation kann bei Bedarf gestartet und auch wieder beendet werden Somit bedarf es keinem dedizierten PC System um die Funktionsf higkeit der Knoten zu erhalten S einfacher Bus Qna as SS Knaten Controller hnteligen zve rag erra Abbildung 4 Peer und Ger te Controller Die Peer Applikation bildet somit die Br cke zwischen Ger te Controller und Internet siehe Abbildung 4 Im Folgenden wird auf die Service Schnittstelle des Peers eingegangen Diese Schnittstelle definiert wie auf Informationen der Knoten zugegriffen werden kann Eines der Konzeptionskriterien legt fest dass m glichst etablierte Technologien und Methoden verwendet werden sollen 25 Vernetzung von Peer und Ger te Controller Bei der Auswahl der Technologie zur Vernetzung von Peer und Ger te Controller werden die Konzeptionskriterien ber cksichtigt Diese besagen dass nur solche Technologien zum Einsatz kommen sollen die weit
76. on logic un m Zeg EJ 3 3 Zz a 5 o o Runi 2 l Outgoing Messagebuffer OutHandler Incoming Messagebuffer 5 Stores the messages coming 4 Stores messages from Application coming from uC level Be 4 Ve Y Run D E E d Connector Sequencer Buffer Handles the Stores packets _ handshake with seq gt procedure with expected the uC Minas Outgoing packetBuffer Sequencer J L Stores packets Handles the open which are sequencing Dasm class not ACKed procedure H 23 A Decomposes bad stre G Incoming Handler Se SC 8 network to their O Handles ACKs corresponding Send pongs upon Objects Also D ping Packets checks if packets are meaningful BE Receive Socket Daemon Catches and Sends UDP Datagramms to uC Network class Paket Logik des Ger te Controller OROP PACKET Length true ls NT Packet D Init slot free Ink entry exists i gt j DROP PACKET DROF PACKET Calculate Hash of packet Hash equals Dunkel le gt DROP PACKET Note actual time ard save in Peer struct last activty logging i Is ACK Packet Send ACK for this Packet to Peer true Delete Packet rom PEER packetlist Is packet saq lt expected Hande Data packet Is PING Packet true Send challenge x in stat Save peer data 3 Bai D Generale Randoms Humber Caic Sessionk C
77. ontroller nur innerhalb von 10 Minuten nach dem Start konfigurierbar Sollte man nicht innerhalb dieses Zeitfensters eine Konfiguration vorgenommen haben sollte man den Ger te Controller einfach neu starten Nachdem nun der Ger te Controller eingestellt wurde sollte man die neuen Konfigurationsdaten in die sasi conf Datei eintragen Nach dem Start der Peer Applikation wird diese sich sogleich mit dem Ger te Controller verbinden Nachdem die Verbindung erfolgreich war wird die Peer Applikation laufend Informationen erhalten Diese Informationen sind ber den Adapter verf gbar Der Adapter ist ein Modul das in der Peer Applikation integriert ist Es ist jedoch m glich den Adapter auszulagern Es ist m glich die Peer Applikation ohne Adapter zu starten und den Adapter im Standalone Modus zu starten 75 Die Peer Applikation und der Adapter werden ber ein bidirektionales REST miteinander kommunizieren Dieses bidirektionale REST wurde hier so realisiert dass es auch NAT durchqueren kann Es ist somit m glich die Peer Applikation in einem NAT Netzwerk zu betreiben und den Adapter auf einem fernen Rechner au erhalb des NAT Netzwerks zu platzieren Dem Adapter ist es m glich direkt mit dem Peer zu kommunizieren da Peer und Adapter eine Verbindung nach dem Start eingehen Folgende Kommandozeile startet die Peer Applikation ohne Adapter host gt python peer py I Folgende Kommandozeile startet lediglich den Adapter hos
78. oten zu berwachen abzufragen und zu konfigurieren siehe Abbildung 3 Im folgenden wird dieser Mikrocontroller oder Signalprozessor mit Ger te Controller bezeichnet Bevor darauf eingegangen wird wie dieser Ger te Controller mit dem Internet verbunden wird soll die Kommunikation zwischen Knoten und Ger te Controller weiter vertieft werden Vernetzung Da es sich um einfache Knoten handelt ist die n tige Bandbreite des Kommunikationsmediums relativ gering Komplizierte Adressierungsmechanismen sind ebenso berfl ssig wie komplexe Flusskontrolle Angesichts dieser Argumente und 23 Anforderungen scheint ein Bussystem geradezu optimal ftir diesen Zweck Ein einfaches Bussystem gen gt auch unserem Konzeptionskriterium des KISS Prinzips Ein Bussystem stellt in der Regel eine einfachere Technologie dar als es z B eine Computernetzwerktechnologie tut Der Entscheid zu einfachen Knoten und einem ebenso einfachen Bussystem gen gt unserem Konzeptionskriterium der Verlagerung von Intelligenz weg von den Knoten hin zum Ger te Controller siehe Abbildung 3 Der Verzicht auf komplexe Netzwerktechnologie verhindert auch den Einsatz von teureren Treiberbausteinen f r die Knoten einfacher Bus controller S S Knoten Intelligenzwer agerun kee Abbildung 3 Knoten und Ger te Controller Die Peer Applikation Im Folgenden soll auf eine weitere Strukturkomponente eingegangen werden Aus bereits erw hnten Zuverl ss
79. r Servicenutzung Auch in diesem Fall empfiehlt sich Technologien oder Konzepte zu nutzen die weiter Verbreitung unterliegen Dies vereinfacht das sp tere Implementieren einer Applikation die Dienste des Rahmenwerks nutzen soll Werden Standards genutzt die bereits in den meisten Sprachen als Module implementiert sind f hrt dies zu einem vielleicht h herem Nutzungs oder Erfolgsgrad des Rahmenwerks Zusammenfassung Nachfolgend wird noch mal die Problemstellung und die daraus resultierenden Kriterien zusammengefasst Besprochen wurden zwei verbreitete Konzepte Zum einen die Anbindung von Knoten an ein Gateway auf PC Basis zum anderen die direkte Verbindung aller Knoten an das Internet F r beide Konzepte sprechen einige Vor und Nachteile Die Analyse dieser beiden Konzepte hat zu einigen Erkenntnissen gef hrt die in Form von Konzeptionskriterien festgehalten wurden Im Folgenden werden alle Kriterien noch einmal aufgelistet e Keine direkte Anbindung der Knoten an das Internet e PC basierendes System als Gateway vermeiden e KISS keep it short and simple e Bew hrte und schwachstellenlose Kommunikationsprotokolle verwenden e Nebenlaufigkeit und dynamische Allokation vermeiden e Auslagerung der Intelligenz aus den Knoten e Technologien nutzen die weiter Verbreitung unterliegen e Einfache Kommunikationstechnologien w hlen e Generische einfache und zustandslose Schnittstelle f r Servicenutzung Diese Kriterien wer
80. re einzuschleusen stellt sich die Frage ob die Vernetzung von Gegenst nden vor allem mit dem Internet diesem Problem nicht noch weiteren N hrboden liefert Kann es dazu kommen dass Personen unerlaubt Ger te beeinflussen k nnen K nnen fremde Personen an vertrauliche Informationen gelangen Nicht zuletzt spielen in diesem Bereich die Kosten eine wichtige Rolle Inwieweit k nnen allt gliche Gegenst nde zu welchem Preis intelligenter gemacht werden Es bedarf Konzepte die diese Entwicklung zu vergleichsweise geringen Kosten erm glichen Auch wenn die Einzelkosten eines Mikrochips sehr gering sind so k nnen h here Einzelpreise in der Summe doch erheblich sein 12 Technische Aspekte Im Folgenden wird auf konkrete technische Aspekte die in dieser Diplomarbeit als wichtig erachtet werden eingegangen Konzentriert wird sich auf die Ausfallsicherheit Kommunikationssicherheit und Kostenreduktion In diesem Zusammenhang soll kurz auf den aktuellen Stand der Dinge eingegangen werden Wie bereits erw hnt existieren eine gro e Zahl von kosteng nstigen Mikrochips die einem erm glichen Gegenst nde mit Intelligenz auszustatten und zu vernetzen Besonders spezialisierte Mikrocontroller bieten sogar im ROM integrierte IP Stacks an Somit ist es einfach m glich ein Ger t IP f hig zu machen Es ist durchaus blich einfache Ger te wie Webcams IP f hig zu machen und zus tzlich noch einen integrierten Web Server anzubieten In
81. s client do newRA POST tuerschloss state 1 if pAction uri karlheinz infos present if pAction data 1 print Authorized person detected opening doors client do newRA POST tuerschloss state 1 if pAction data 0 print Authorized person gone closing doors client do newRA POST tuerschloss state 0 try while wclib vbailoutcode None wclib programm lock wait 0 1 except wclib proaramm lock release Abbildung 19 Klient Source Code In Abbildung 19 ist das Programm angef hrt um den Demonstrator zu programmieren Das Programm ist in drei Abschnitte aufgeteilt Abschnitt 1 Initialisieren der API f r das SASI Rahmenwerk Dies beinhaltet das Verbinden mit SASI und dem Abonnieren aller Knoten Von nun an werden alle Ereignisse an die Klient Applikation weitergeleitet Abschnitt 2 Die Funktion handleNotification empf ngt alle Notifikationen seitens des Peers Der Parameter pAction ist eine so genannte Rest Aktion und enth lt alle notwendigen Daten um eine Ressource zu identifizieren und um zu spezifizieren was dieser Ressource 65 zugesto en ist Weiterhin enth lt diese Funktion einige Vergleiche um zu berpr fen um welche Ressource es sich handelt Handelt es sich z B um die Ressource karlheinz infos present so ist klar dass dieses Ereignis in Verbindung mit einem ID iButton steht und somit das Datenfeld dar ber Auskunft gibt ob Karl Heinz sic
82. st gt python peer py help Wenn die Peer Applikation immer mit den gleichen Argumenten gestartet wird ist zu empfehlen die sasi conf Datei einzustellen Diese Datei enth lt alle wesentlichen Konfigurationsoptionen die von Peer Applikation ben tigt werden Diese Datei wird bei jedem Start gelesen und als Konfigurationsgrundlage genommen Mit den Kommandozeilenparametern kann man diese Konfigurationsoptionen berschreiben Bevor n her auf die Konfiguration der Peer Applikation eingegangen wird soll noch kurz die Konfiguration des Ger te Controllers erw hnt werden Wie erw hnt geschieht die 74 Konfiguration des Ger te Controller ber den Peer Falls der Ger te Controller noch nicht konfiguriert wurde startet dieser mit einer Initialkonfiguration Diese lautet wie folgt IP Adresse 192 168 2 30 Netzwerk 255 255 255 0 24 Gateway 0 0 0 0 Masterpasswort 12345678 Shared Key gauss Nach dem erstmaligen Start des Ger te Controller ist dieser also unter der genannten Adresse erreichbar Diese Werte k nnen nun mittels der Peer Applikation angepasst werden Mit folgendem Kommandozeilenaufruf wird ein interaktiver Setupmodus gestartet der die n tigen Informationen vom Benutzer abfragt und am Ende an den Ger te Controller bermittelt host gt python peer py x 12345678 Es sei angemerkt dass das Masterpasswort nicht ver nderbar ist sondern fest in das Programm eincodiert ist Weiterhin ist der Ger te C
83. t gt python peer py w Die Adresse an die sich der Adapter bindet wird in der sasi conf Datei spezifiziert Es ist n tig den Adapter vor der Peer Applikation zu starten da sich die Peer Applikation mit dem Adapter verbindet Dies ist unbedingt notwendig da nur die Peer Applikation vom NAT Netzwerk heraus einen Kommunikationskanal etablieren kann umgekehrt kann der Adapter sich nicht mit der Peer Applikation verbinden da Verbindungen am NAT Gateway scheitern wurden Die Peer Applikation enth lt im Verzeichnis contrib zwei Beispielprogramme Zum einen den webclient Hierbei handelt es sich um eine kleine Web Applikation die unter einer gew hnlichen Apache PHP4 Installation l uft Diese Web Applikation verbindet sich mit dem Adapter und erm glicht es einem die MIB zu durchforsten Werte abzufragen oder zu ndern Man sollte diese Applikation nutzen um sich etwas mit der MIB vertraut zu machen Der Nachteil dieser Web Applikation liegt darin dass keine NOTIFY Meldungen des Peers empfangen werden k nnen Dies liegt in der Natur des HTTP Protokolls Die Web Applikation besitzt n mlich keinen HTTP Server an die die Peer Applikation die NOTIFY Meldungen ausliefern k nnte He Das zweite Programm wanclient befindet sich ebenfalls im contrib Verzeichnis Dieses Programm verbindet sich dauerhaft mit dem Adapter Im Gegensatz zur Web Applikation besitzt dieser Klient einen Web Server der die NOTIFY Meldung
84. t generische Schnittstelle zwischen Klient Applikationen und dem Peer zu gew hrleisten wurde sich f r das REST Prinzip entschieden Im folgenden Kapitel wird genauer auf Entwurfsentscheidungen eingegangen Zu diesem Zeitpunkt sind lediglich die Gesamtstruktur definiert und die Technologieauswahl abgeschlossen 40 Entwurf der Kommunikation In diesem Kapitel werden die Entw rfe des gesamten Systems genauer ausgearbeitet Bislang wurden nur grobe Architektur und Technologiefragen behandelt Offen bleibt der Entwurf folgender Teilsysteme e Kommunikation zwischen Ger te Controller und Knoten e Kommunikationsprotokoll zwischen Ger te Controller und Peer Applikation e Softwareentwurf f r den Ger te Controller e Softwareentwurf f r den Peer e Datenstruktur zur Speicherung der Informationen im Peer e Kommunikation von Klienten und Peer e Entwurf eines Demonstrators Zwar wurde REST als Prinzip ftir die Kommunikation zwischen Klienten und Peer bereits festgelegt allerdings handelt es sich bei REST lediglich um ein Prinzip es wird n tig dieses Prinzip in einer konkreten Schnittstelle bereitzustellen Da die Datenstruktur nicht direkt mit der Grobarchitektur zusammenhing wurde bisher noch nicht auf die Datenstruktur f r die Informationsspeicherung eingegangen Diese Struktur wird in diesem Kapitel im Sinne von REST entworfen und definiert Schlussendlich wird ein einfacher Demonstrator entworfen der die Funktionsf hig
85. tart des Ger te Controllers zugesandt Den RUN Aufruf wird ebenfalls ber diese Dispatcher Funktion realisiert Um die Funktionsweise der aktuell implementierten Module zu verstehen sei auf die Dokumentation im Source Code verwiesen Peer Applikation Die Peer Applikation wurde mit objektorientierten Methoden entwickelt und vereinfacht somit dem Entwickler die Erweiterung des Rahmenwerks Die Peer Applikation verf gt ber einige Module und Untermodule Die wichtigsten Module seien hier kurz erw hnt e net e best e mib e daemon e log 79 Das Netzwerkmodul kapselt alle netzwerktechnischen Funktionen wie z B das Binden an den Socket das Lesen der eingehenden Pakete und so weiter Grunds tzlich werden Pakete in Objekte umgewandelt Dies macht es n tig dass f r jeden Typ von Paket eine Definition dieses Typus existieren muss Dies wird mittels des dasm Moduls realisiert Dieses Modul liest die Pakete und versucht eine Klasse zu finden die zu diesem Paket passt Dies macht das Erweitern des Kommunikationsprotokolls erheblich einfacher Es m ssen keine hartcodierten Routinen ge ndert werden sondern nur eine Typdefinition des Paketes angegeben und die Identifikationsnummer eingetragen werden Das biRest Modul kapselt die Kommunikation zwischen Peer Kern und dem Adapter Mit diesem Modul k nnen Peer Kern und Peer Adapter getrennt werden und sogar ber NAT Gateway oder Proxy Server miteinander kommunizieren
86. tiert werden Das Kopieren eines Pakets durch Dritte und das anschlie ende Wiedereinspeisen wird durch den Server bemerkt da die Sequenznummer nicht die Erwartete w re dies sch tzt vor so genannten Replay Angriffen Dieses Protokoll soll nun um die weiteren Anforderungen erweitert werden Hauptschwierigkeit stellt hier die Zustellgarantie dar Um die Komplexit t an den Protokoll Stack nicht unn tig zu erh hen wird die Zustellungsgarantie in vereinfachter Form implementiert Im folgenden Abschnitt werden die genauen Anforderungen an die Zustellgarantie diskutiert Ausgehend von folgenden berlegungen soll das Protokoll nun erweitert werden Jedes gesendete Paket wird vorerst in einer Warteschlange gespeichert Jedes empfangene Datenpaket muss durch ein ACK Paket best tigt werden Ist ein Paket best tigt wird es aus dem Speicher des Senders endg ltig gel scht Nach einer festen Wartefrist wird jedes Paket im Ausgangsspeicher wieder gesendet Nach f nf erfolglosen Zustellungsversuchen wird dies als Verbindungsabbruch gewertet Bei Empfang von Paketen deren Sequenznummer kleiner als die Erwartete ist werden keine NAK Pakete gesendet sondern die Pakete werden umgehend verworfen Die Pakete mit zu hoher Sequenznummer werden zwischengespeichert bis die L cken gef llt werden k nnen Dieses vereinfachte Protokoll reduziert die Anspr che an den Protokoll Stack Komplexe Verhaltensweisen wie bei TCP k nnten leicht zu Fehlern 46
87. tisch abgewickelt Dies unterst tzt das Zero Programming Konzept Die Sensordaten werden aufbereitet und ber einen Web Server zur Verf gung gestellt GSN stellt auch andere Kommunikationsmittel wie Email oder SMS zur Verf gung Besonders herausragend an diesem Projekt ist die absolut unabh ngige Ger teschnittstelle Es Bedarf keinem Programmieraufwand um neue unbekannte Sensoren in dieses Rahmenwerk einzubinden Dies hat den Vorteil dass der Anwender keine nderungen an der Middleware vornehmen muss um neue Sensoren zu unterst tzen Allerdings k nnen Sensoren die diesen Standart nicht erf llen nicht eingesetzt werden SASI Die Herangehensweise in dieser Diplomarbeit besteht darin in dem zu entwickelnden Rahmenwerk SASI ein einfaches Bussystem zu verwenden um Knoten an eine Master Station anzubinden Dieser Bus wird an einen Master angeschlossen der IP F higkeit besitzt Tendenziell l sst sich feststellen dass in den genannten verwandten Projekten versucht wird den einzelnen Knoten selbst mehr F higkeiten zuzuf hren Dies kann von Datenaggregation bis hin zu Wireless F higkeiten reichen Es l sst sich auch feststellen dass so genannte Feldbusse durchaus gerne in Ethernet Netze gebr ckt werden Insgesamt verfestigt sich der Eindruck dass auch f r einfache Sensoren oder Aktuatoren um neueren Konzepten standhalten zu k nnen eine gro e Intelligenz vorausgesetzt wird Stichwort Smart Sensors SH http
88. troller Die Programmierung vom Tini Networked Mikrocontroller kann entweder in Java oder C realisiert werden Von Maxim IC selbst gibt es eine JVM die auf dem Tini Networked lauff hig ist Somit steht einem die ganze M chtigkeit von Java zur Verf gung Um eine maximale Leistung zu garantieren wurde sich jedoch dazu entschieden die Implementierung in C durchzuf hren Ein schneller IP Stack kann Vorteile bei DoS Angriffen bieten Ein Teil des IP Stacks wird bereits durch den Tini ROM zur Verf gung gestellt Die Peer Plattform F r Applikation Sg Klient Applikalien F r Applikation Garig Sortraller Tini Metwarked Klikrasentraller Abbildung 9 Peer Applikation in der Gesamtstruktur Kneten Knoten E Knaten Schlussendlich fehlt noch die Entscheidung auf welcher Plattform die Peer Applikation implementiert wird siehe Abbildung 9 Die Peer Applikation sollte laut Konzeptionskriterium auf einem PC basierten System lauff hig sein Um maximale Portabilit t zu erreichen w re eine Interpreter basierte Sprache von Nutzen In diesem Fall wurde sich f r Python entschieden Python bietet h chste Portabilit t und eine gute Ausstattung bereits implementierter Module ER Zusammenfassung Bevor zu dem Entwurf bergangen wird sollten noch mal alle Konzeptionsideen und ausgew hlte Produkte rekapituliert werden Es wurde sich in den vorherigen Kap
89. ttp tools ietf org rfc rfc2960 txt Tsutsumi Toshiyuki Yamaguchi Suguru Secure TCP Providing Security Functions in TCP Layer 1995 http www isoc org HMP PAPER 144 html paper html 11 05 2007 Murat Demirbas Ken Yian Chow Chieh Shyan Wan Internet Sensor Integration for Habitat Monitoring Proceedings of the 2006 International Symposium on World of Wireless Mobile and Multimedia Networks 2006 Karl Aberer Manfred Hauswirth Ali Salehi A Middleware For Fast And Flexible Sensor Network Deployment Proceedings of the 32nd international conference on Very large data bases Volume 32 pp 1199 1202 2006 Maxim IC Add Control Memory Security and Mixed Signal Functions with a Single Contact 2007 http pdfserv Maxim IC com en an AN3989 pdf 07 05 07 86 MIT1 Sn WEBSCADA WEISER WSN2006 Raffi Krikorian Bringing IP to the leaf node O Reilly Emerging Technology Conference 2003 http ttt media mit edu impact i0oreilly pdf 27 05 07 A Flammini P Ferrari E Sisinni D Marioli A Taroni Sensor interfaces from field bus to Ethernet and Internet Sensors and Actuators A Physical Volume 101 Number 1 2002 A Ekpruke Richard W Wall Low Cost Sensor System for Alarm Reporting http www mre uidaho edu cisr labs comms pubs WEB 20SCADA pdf 24 05 2007 Mark Weiser The Computer for the 21st Century Scientific American Ubicomp Paper 1991 http www cc gatech edu fac Gregory Abow
90. u kommt noch der erzwungene Flush dieser w rde dann gestartet wenn ein berlauf des Nachrichtenpuffers anstehen w rde Zusammenfassung In den letzten Abschnitten wurden die Gr nde f r die Einf hrung eines eigenen Protokolls dargelegt Um die Ausfallsicherheit gegen ber DoS Angriffen zu erh hen wurde auf TCP zugunsten eines eigenen UDP basierten Protokolls verzichtet Dieses neue Protokoll besitzt ein 4 Way Handshake und sichert die Kommunikation ber Hashwertbildung ab Die Hashwerte werden aus den Daten des Pakets und eines geteilten Geheimnisses berechnet Zwecks Identifikation der logischen Verbindung benutzen beide Teilnehmer einen Session Cookie der in der Phase des Handshakes ermittelt wurde Dieses Protokoll ist gegen ber Spoofing und Packet injection durch Dritte gesch tzt und erh ht somit die Sicherheit im 49 Vergleich zu TCP Jedoch muss fiir Sequenzierung und garantierte Zustellung selbst gesorgt werden Um auf dem Applikationsniveau eine bequemere Schnittstelle zur Verf gung zu haben wird eine weitere Schicht eingef hrt Diese Schicht hat zur Aufgabe von den Datenpaketen hin zu Nachrichten zu abstrahieren Die Applikation ist nun unabh ngig von Datenpaketen und deren Gr e Dies hat den Vorteil dass die Schicht automatisch entscheiden kann ob genug Nachrichten angesammelt wurden damit das Versenden eines Pakets sich lohnt Peer Applikation und Klient Applikation Peer i Applikation i l
91. uf den Webserver der Peer Applikation realisiert Die Flexibilit t und einfache Erweiterbarkeit des SASI Rahmenwerks wurde vor allem im Kapitel Einsatz zu Tage gebracht Die Wahl von generischen Knoten erlaubt dem Entwickler alle m glichen Applikationen auf Schaltkreisniveau zu realisieren Die Logik der Schaltkreise kann in der Klient Applikation nach Belieben genutzt werden Das SASI Rahmenwerk agiert als Middleware und bedarf keiner Anpassung an die gew nschte Anwendung Das SASI Rahmenwerk ist somit offen f r jegliche Anforderungen und bietet dem Entwickler eine bequeme Schnittstelle zu den Aktuatoren und Sensoren Diese Schnittstelle vereinfacht dem Entwickler die Realisierung von Anwendungen Die im Kapitel ber die Problemstellung motivierten Kriterien wurden alle erfolgreich umgesetzt das SASI Rahmenwerk bildet eine kosteng nstige Br cke zwischen Knoten und gro en Netzen wie z B dem Internet Schlussendlich wurde der Erfolg der Konzepte und Methoden des SASI Rahmenwerks anhand eines praxisnahen Fallbeispiels mittels eines Demonstrators aufgezeigt 69 Ausblick Aktuell wird in diesem Rahmenwerk die Logik der Applikation im Klienten implementiert Das bedeutet dass fiir den Betrieb einer Applikation die auf Ereignisse auf dem Bus reagiert ein Klient st ndig mit dem Rahmenwerk verbunden sein muss Dies wurde explizit so modelliert allerdings w re eine Option denkbar in der der Klient eine einfache Logik auf dem Ger
92. urfsb rokratismus berwinden so wird bei I0 z B auf Ethernet als Zwischenschicht komplett verzichtet Weniger ist in diesem Kontext mehr da es die Vorrausetzungen an die Chips in den Ger ten verkleinert Bei IO sollen Netzwerkknoten eigenst ndig und nicht auf einen Master angewiesen sein Ein Beispiel eines Schalters der in IO Manier entwickelt wurde besitzt lediglich 3 5kb Codegr sse inklusive TCP IP Stack und Web Server Dieses Konzept besitzt eine gro e Schnittmenge mit dem hier entwickelten SASI Rahmenwerk Zwar geht es bei InternetO nicht um Intelligenzverlagerung sondern um Intelligenzminimierung was in diesem Fall zu den gleichen Zielen f hrt Jedoch sollte ber cksichtigt werden dass eine direkte Anbindung von Ger ten an das Internet nicht von Vorteil aus Sicht der Sicherheit ist Dies wurde bereits mehrmals in den vorangegangenen Kapiteln gezeigt 31 GSN GSN steht f r Global Sensor Network und wurde an der EPFL in Lausanne Schweiz entwickelt Bei GSN handelt es sich um eine generische Middleware Software um Sensoren IP fahig zu machen Es gibt besondere Wrapper die Sensordaten in das GSN einspeisen So k nnen die Daten z B ber ein Serial Interface UDP und viele mehr zu GSN gelangen Sensoren werden in Form von XML Dateien vorkonfiguriert Dabei handelt es sich um so genannte virtuelle Sensoren Die technische Verbindung mit den physikalischen Sensoren wird teilweise mit Hilfe des IEEE 1451 Standards automa
93. us gepr ft werden soll Szenario Ausgehend von der Idee eine automatisierte Zugangsschleuse f r ein Rechenzentrum zu entwerfen wird folgendes Szenario konstruiert Die elektronische T r bleibt st ndig verschlossen Tritt jedoch eine befugte Person an die T r soll diese automatisch ge ffnet und nach Eintritt wieder geschlossen werden Durch die hohen Leistungen heutiger Rechner soll die T r im Fall einer Temperatur berschreitung automatisch zwecks L ftung ge ffnet werden Dies mag nicht besonders realistisch sein wird dennoch zwecks Demonstration so gew nscht Dieses einfache Szenario l sst sich ohne weiteres mit dem SASI Rahmenwerk realisieren Es werden lediglich einfache elektronische Schaltungen ben tigt die das elektronische Schaltelement des Knotens auf eine Ausgangsleistung verst rken die das Schalten eines Relais oder Stellwerks erm glicht 63 Der Zutritt einer befugten Person wird mittels ID iButton von Maxim IC realisiert Diese ID iButtons sind 1W Ger te die eine Seriennummer enthalten Wird die richtige Seriennummer erkannt so wird das Schaltelement zum ffnen der T r angesteuert Auf dem aufgebauten Demonstrator ist das ffnen oder Schlie en der T r durch das Ein und Ausschalten einer gr nen beziehungsweise roten 235V Lampe dargestellt Die Temperatur berschreitung l sst sich einfach mit einem 1W Temperatursensor realisieren Ein regelm ssiges berpr fen der aktuellen Temperatur soll d
94. vices online 0A 948 1EF6151I lasttemperature devices online 0A 9481 EF61511 01 02 2007 15 14 01 devices online 0A 9481 EF61511 01 02 2007 15 15 01 devices online 0A 9481 EF61511 01 02 2007 15 16 01 devices online 049481EF61511 01 02 2007 15 17 01 devices online 0A9481EF61511 01 02 2007 15 14 01 In diesem Beispiel sind drei Knoten vorhanden Zum einen 0B45673461511 der ein Quad AD Wandler Knoten darstellt zum anderen EF044BC323423 ein E A Baustein und 049481EF61511 der ein Temperatursensor darstellt Diese Ressourcen k nnen mittels GET Aktion vom Klient abgefragt werden Jedoch soll das Manipulieren dieser Ressourcen nur dann erlaubt sein wenn dies im Sinne der Ressource ist so sollen z B Messwerte nicht vom Klient ver nderbar sein 33 Der Zugriff auf die Resource devices offline EF04ABC323423 pin3 state mittels GET w rde z B 1 oder 0 ausgeben 1 entspr che logisch High und 0 entspr che logisch Low Den Zustand dieses Schalters k nnte man mittels POST auf diese Ressource ver ndern Ein POST mit 1 als Datum w rde somit den Ausgang auf logisch High umschalten 54 Entwurf der Software Im folgenden Kapitel wird der Entwurf der einzelnen Softwarekomponenten besprochen In erster Linie wird sich an den ermittelten Kriterien orientiert Weiterhin werden in diesem Kapitel lediglich die groben Strukturen der Softwarekomponenten angesprochen Fiir tiefer gehende Erl uterungen sei hier auf das Entwicklerhandbuch im Anhang v
95. wicklung weiter voranschreitet stellt sich nicht zuletzt die Frage der Kosten Wenn einfache Gebrauchsgegenst nde mit Mikroprozessoren ausgestattet werden und diese in gro er Zahl in unserem Umfeld vorhanden sind kann man davon ausgehen dass bedingt durch diese elektronischen Komponenten die Kosten f r die Nutzer steigen Kann man Konzepte erarbeiten die diese Kosten minimieren Gibt es Architekturen die in diesem Zusammenhang besonders vorteilhaft sind Mit einigen dieser Fragen wird sich in dieser Diplomarbeit auseinandergesetzt Das Feld des Ubiquitous computing bedient viele Bereiche der Wissenschaft Von gesellschaftlichen Fragen bis hin zu wirtschaftlichen und nicht zuletzt informationstechnischen Fragen sind noch einige offen Ziele der Diplomarbeit Im vorherigen Abschnitt wurden einige Probleme herausgearbeitet die mit dem Ubiquitous computing verbunden sind Die identifizierten Probleme sollen zum Anlass genommen werden bessere Architekturen und Konzepte die diese Probleme l sen k nnten auszuarbeiten Der Schwerpunkt liegt in der Konzeption eines Rahmenwerks das von den einfachen elektronischen Gegenst nden bis hin zu Internet Applikationen eine Br cke schl gt Dazu ist es n tig die Anforderungen zu ermitteln und zu bewerten Das Ziel ist es eine Konzeption zu erstellen die die identifizierten Anforderungen erf llt Die Kommunikation zwischen den einzelnen Komponenten sowie die Software selbst die zum E
96. wird Hierf r richtet der Peer eine HTTP Anfrage an den Klienten Diese Anfrage muss ebenfalls eine XML Datei als POST enthalten Auch hier dient die XML Datei dazu die REST Anfrage zu pr zisieren 13 Installation und Konfiguration Da es sich beim Ger te Controller um einen Mikrocontroller handelt wird ein spezieller Compiler f r Mikrocontroller ben tigt Zum Entwickeln der Software wurde der Keil Compiler verwendet Die erzeugte Bin rdatei muss mittels MTK2 von Maxim IC ber die serielle Schnittstelle auf den Mikrocontroller geladen werden Der Mikrocontroller bootet nun selbstst ndig Am Ger te Controller sind nun keine weiteren Schritte notwendig Die Konfiguration des Mikrocontrollers geschieht ber die Peer Applikation Bei der Peer Applikation ist die Installation wesentlich einfacher Es reicht die gepackte Peer Applikation zu entpacken und mittels geeigneter Python Installation zu starten Es werden keine speziellen Python Module oder Pakete ben tigt Um die Peer Applikation zu starten reicht folgendes Kommando host gt python peer py Prinzipiell werden von der Peer Applikation Root Rechte ben tigt Dies h ngt damit zusammen dass der Adapter sich an Port 80 bindet Dies l sst sich jedoch umgehen indem man die Portbindungen ndert dazu sp ter mehr Es wird empfohlen sich mit den Kommandozeilenargumenten der Peer Applikation vertraut zu machen Dies l sst sich mit folgendem Kommando durchf hren ho

Die Peer-Applikation

Contents

Download Pdf Manuals

Related Search

Related Contents