Analyse, Design und Implementierung einer aspektorientierten Erweiterung der Programmiersprache nesC im Besonderen für das Logging in Sensornetzen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Aufgabenstellung dieser Arbeit
1.3 Überblick über die Arbeit

2 Grundlagen
2.1 Drahtlos verbundene Sensornetze
2.1.1 Motes als Knoten eines Sensornetzes
2.1.2 Anforderungen an Sensornetze
2.1.3 Anwendungsgebiete von Sensornetzen
2.1.4 Weitere Miniaturisierung bis hin zum Smart Dust
2.1.5 Neue Anwendungsgebiete durch Miniaturisierung
2.1.6 Die Sprache nesC und das Betriebssystem TinyOS
2.2 Tools zur Unterstützung des Programmierers
2.2.1 Tools zur Programmprüfung
2.2.2 Logging und Debugging
2.3 Aspektorientierte Programmierung
2.3.1 Überblick über die aspektorientierte Programmierung
Weben von Aspekten bestehend aus Pointcuts und Advices
Crosscutting Concerns und Obliviousness
Nachteile der aspektorientierten Programmierung
2.3.2 Motivation des aspektorientierten Loggings für Sensormotes
2.3.3 Weitere Möglichkeiten für die Anwendung von Aspekten auf Sensormotes

3 Analyse von Logging-Frameworks und aspektorientierten Spracherwei- terungen und deren Implementierungen
3.1 Verwandte Arbeiten
3.2 Logging-Frameworks
3.2.1 Loggingansätze für die PC-Umgebung
3.2.2 Loggingansätze in nesC für die Sensornetzumgebung
3.3 Das Weaving unterschiedlicher Implementierungen aspektorientierter Sprachen
3.3.1 Zeitpunkte des Weavings
3.3.2 Bytecode-Weaving in der AspectJ-Implementierung
3.3.3 Loadtime Weaving und Runtime Weaving
3.3.4 LogicAJ als Beispiel einer Implementierung als Precompiler
3.3.5 Weitere Implementierungen als Precompiler
3.3.6 Einweben von Aspekten ohne Implementierung einer Spracher- weiterung
3.3.7 Schlussfolgerungen für die Erweiterung von nesC
3.4 Sprachdefinition von AspectJ
3.4.1 AspectJ als Vorreiter
3.4.2 Pointcutdeklarationssprache
Aufruf-Pointcuts
Zustandsbasierte Pointcuts
Dynamische Pointcuts
Pointcuts auf Programmcode
3.4.3 Advices
3.4.4 Introductions
3.5 Composition Filters

4 Entwurf der aspektorientierten Sprache für nesC
4.1 Die Sprache nesC
4.1.1 Komponentenbasierter Aufbau von nesC
4.1.2 Als asynchron gekennzeichnete Funktionen
4.1.3 Das Taskkonzept
4.1.4 Quellcode eines nesC-Programmes
4.2 Pointcuts und Advices für nesC
4.2.1 Zusätzliche Sprachkonzepte von nesC führen zu zusätzlichen Join- pointmöglichkeiten
Einfache Funktionspointcuts
Introductions
Command- und Event-Joinpoints
Task-Joinpoints
Änderungen von Konfigurationen
4.2.2 Definition der Pointcutdeklarationssprache für nesC
Allgemein
Pointcuts für private Funktionen
Pointcuts für Events und Commands
Pointcuts für Tasks
Hilfspointcut zur Übernahme von Argumenten
Hilfspointcut zum Einschränken des Einwebens auf bestimm- te Module
Konfigurationsverändernde Anweisungen
4.2.3 Definition der Advicedeklarationssprache
Before, After und Around-Advices
Zugriff auf Variablen und Joinpointinformationen
Benutzung von konfigurationsverändernden Anweisungen .

5 Analyse des Aufbaus des nesC-Compilers und seines Frameworks
5.1 Das Build-Framework um den nesC-Compiler
5.2 Der nesC-Compiler
5.2.1 Aufbau
5.2.2 Lexer
5.2.3 Parser
5.2.4 Markieren der Module anhand der Konfigurationen
5.2.5 Generierung des Ausgabe-C-Codes
5.3 Die Eingabedatei des Parsergenerators yacc

6 Arbeitsweise der Compilererweiterung der aspektorientierten Spracher- weiterung von nesC
6.1 Designentscheidung für eine Implementierung der Spracherweiterung innerhalb des nesC-Compilers
6.2 Die Compilererweiterung für Pointcuts und Advices
6.2.1 Der Weg eines Aspektes
6.2.2 Überblick über die Arbeit der Compilererweiterung
6.3 Die Arbeit der Compilererweiterung für Pointcuts und Advices im Detail
6.3.1 Schritt 1: Laden der Aspekte
6.3.2 Schritt 2: AST-Aufbau für Aspekte
Arbeit des Lexers
Erweiterte und neue Knotentypen für den AST
Arbeit des Parsers
6.3.3 Schritt 3: Verbinden der Pointcuts mit ihren einzuwebenden Ad- vices
6.3.4 Schritt 4: Weben
6.3.5 Schritt 5: Generierung der Ausgabedatei
6.4 Die Compilererweiterung für konfigurationsverändernde Anweisungen
6.5 Die Arbeit der Compilererweiterung für konfigurationsverändernde An- weisungen im Detail
6.5.1 Arbeit des Lexers
6.5.2 Erweiterte und neue Knotentypen für den AST
6.5.3 Arbeit des Parsers
6.5.4 Durchführen der Änderungen der Konfigurationen
6.5.5 Übernahme des Wirings des Aspektes

7 Evaluation der Compilererweiterung
7.1 Zur Evaluation verwendeter Basiscode
7.2 Funktionalität der Aspekte
7.2.1 Logging durch die printf-Bibliothek
7.2.2 Logging durch Ausgabe von Informationen auf die Leds des Motes
7.2.3 Konfigurationsverändernde Anweisungen
7.3 Quellcode der Aspekte
7.3.1 Logging durch die printf-Bibliothek
7.3.2 Logging durch Ausgabe von Informationen auf die Leds des Motes
7.3.3 Konfigurationsverändernde Anweisungen
7.4 Ergebnisse der Evaluation
7.4.1 Einwebhäufigkeit und Anzahl der gewebten Programmzeilen
7.4.2 Laufzeitverhalten der Compilererweiterung
7.4.3 Konfigurationsverändernde Anweisungen

8 Zusammenfassung und Ausblick
8.1 Zusammenstellung der Ergebnisse der Diplomarbeit
8.2 Ausblick

A Installationsanleitung

B Quellcode

Literaturverzeichnis

Quellcodedateiverzeichnis

Abbildungsverzeichnis

Danksagungen

Und Jesus antwortete und sprach zu ihnen: Habt Glauben an Gott! Wahrlich, ich sage euch: Wer zu diesem Berge spräche: Heb dich und wirf dich ins Meer!, und zweifelte nicht in seinem Herzen, sondern glaubte, dass geschehen werde, was er sagt, so wird ’ s ihm geschehen. (Die Bibel an Markus 11,22 und 23) Ich danke Jesus für diese Worte, die er damals am Feigenbaum sprach und die mich durch mein Studium hindurch ermutigt haben, an den Bergen, die vor mir standen, nicht zu verzweifeln, sondern sie durch den Glauben Schaufel für Schaufel ins Meer zu versetzen.

Ich danke meinen Professoren und Dozenten, die dafür gearbeitet haben, immer interessante und verständliche Vorlesungen zu halten. Zu Beginn meines Studiums wusste ich dies nicht zu schätzen. Als ich jedoch einige Vorträge selbst halten musste, merkte ich, wie schwierig es ist, einen interessanten und verständlichen Vortrag zu halten.

Ich danke für diese Diplomarbeit auch ganz besonders Robert Sauter, der mir immer mit gutem Rat zur Seite gestanden hat.

Ich danke meinen Freunden in meiner Gemeinde, die mich an vielen Stellen meines Studiums begleitet haben. Ich danke meiner Familie, ganz besonders meinem Vater, für ihre Unterstützung.

Kapitel 1 Einleitung

In diesem Kapitel wird die aspektorientierte Programmierung für Sensormotes motiviert. Das Ziel der Diplomarbeit, die Entwicklung einer aspektorientierten Spracherweiterung für nesC und die Realisierung derselben, wird definiert. Ein Überblick über die Arbeit wird gegeben.

1.1 Motivation

Sensornetze sind drahtlos verbundene Netze bestehend aus einzelnen Knoten, welche Motes genannt werden. Ein Mote stellt dabei ein Computersystem dar, welches Daten über seine angeschlossenen Sensoren erfasst, verarbeitet und über seine Netzschnitt stelle versendet. Auf den Motes eines Sensornetzes kommen dabei Programme zum Einsatz, welche von einem Entwickler für den Anwendungsfall des Sensornetzes spezifisch erstellt werden. Da Motes über geringe Hardwareressourcen verfügen, müssen diese Programme hochoptimiert kompiliert werden.

Eine der Programmiersprachen, welche für die Bedürfnisse von Sensormotes angepasst sind, ist die Programmiersprache nesC. nesC -Programme sind komponentenbasiert aufgebaut. Implementierungen innerhalb dieser Komponenten sind in C geschrieben. Wegen des komponentenbasierten Aufbaus ist es dem nesC -Compiler möglich, statisch hochoptimierte Programme zu erstellen.

Entwickelte Programme für Sensormotes müssen getestet werden, um ihren feh- lerfreien Ablauf zu garantieren. Anhand von Loggingnachrichten kann der Entwickler feststellen, ob das Programm korrekt arbeitet. Dabei kann die Software eines Motes in drei unterschiedlichen Entwicklungsstufen getestet werden: in der Simulation, im Testbed und im Einsatz des Sensornetzes nach seinem Deployment. Während in der Simulation keine Motehardware benutzt wird, sondern nur in einer simulierten Um- gebung getestet wird, exsistieren im Testbed ein oder mehrere reale Motes, auf denen das Programm zur Ausführung gebracht wird. Diese Motes sind jedoch zusätzlich über eine serielle Schnittstelle verbunden, über die Loggingnachrichten ausgegeben werden können. Wenn sich die Motes des Sensornetzes im Einsatz befinden, fällt jedoch auch diese Verbindung weg.

2 KAPITEL 1. EINLEITUNG

Die aspektorientierte Programmierung ist eine neue Programmierrichtung. Bei dieser befindet sich zusätzlicher Programmcode in sogenannten Aspekten. Dieser Programmcode wird durch entsprechende Definitionen in dem jeweiligen Aspekt in das Hauptprogramm - unter Umständen auch mehrmals - eingewebt, d.h. aus dem Hauptprogramm finden Aufrufe des Aspektprogrammcodes statt.

Für jede der drei Entwicklungsstufen eines Programmes, welches auf Sensormotes zum Einsatz kommt, wird unterschiedlicher Testcode benötigt, um Loggingnachrichten auszugeben. Dieser Testcode muss durch den Entwickler manuell ausgetauscht wer- den, wenn die Stufe gewechselt wird. Die Motivation dieser Diplomarbeit ist es, eine aspektorientierte Sprache zu entwickeln, mit welcher definiert werden kann, wie dieser Testcode austauschbar mittels unterschiedlicher Aspekte eingewebt werden kann. Die aspektorientierte Sprache soll jedoch so allgemein gehalten werden, dass auch beliebige andere Funktionalitäten durch sie implementiert werden können.

1.2 Aufgabenstellung dieser Arbeit

Das Ziel dieser Diplomarbeit ist es, eine aspektorientierte Spracherweiterung für die Anwendung auf Sensormotes zu entwickeln und zu implementieren. Diese soll auf die Sprache nesC aufbauen.

Dafür ist es notwendig, den aktuellen Stand der Forschung von aspektorientier- ten Spracherweiterungen für unterschiedliche Sprachen zu recherchieren und deren Implementierung zu analysieren. Die hier gefundenen Erkenntnisse sollen auf den nesC -Compiler und das Umfeld der Sensornetze übertragen werden. Weiterhin wird das Design von aspektorientierten Sprachen betrachtet. Eine aspektorientierte Sprache für nesC wird definiert werden, die speziell an die Bedürfnisse von nesC angepasst ist. Der experimentelle Teil dieser Diplomarbeit umfasst die Planung und Durchführung einer exemplarischen Implementierung dieser Sprache. Aus dieser exemplarischen Im- plementierung werden Kenntnisse über die aspektorientierte Programmierung in nesC gezogen. Eine anschließende Evaluation zeigt die Vorteile der Realisierung der Spra- cherweiterung für Aspekte.

Als begleitendes Beispiel der aspektorientierten Programmierung wurde das Log- ging gewählt. Die Anwendungsmöglichkeiten der aspektorientierten Sprache sollen jedoch nicht hierauf beschränkt bleiben. Die Vorteile der Aspektorientierung sollen durch die Erweiterung voll nutzbar sein: Es wird gefordert, dass sich die Aspekte schnell ohne Änderungen am Basiscode ein- und ausschalten lassen, so dass Tests schnell durchgeführt werden können. Aspektcode soll bei ausgeschalteten Aspekt rest- los aus dem Binärcode entfernt sein, so dasss CPU-, Speicher- und Energieressourcen beispielsweise durch ein ausgeschaltetes Logging nicht mehr belastet werden.

Die Herausforderungen dieser Diplomarbeit liegen in unterschiedlichen Gebieten. Die Hauptherausforderung liegt darin, die aspektorientierte Sprache für die Programmiersprache nesC zu designen. Dies ist deshalb eine Herausforderung, da nesC im Gegensatz zu anderen Programmiersprachen das speziell auf hohe statische Optimierbarkeit abgestimmte Sprachfeature des Programmaufbaus aus Komponenten besitzt. Eine weitere Herausforderung ist es, eine Spracherweiterung dieser Sprache zu implementieren, mit welcher Aspekte eingewebt werden können.

Für das Design der Sprache und ihre Realisierung als Spracherweiterung sind detallierte Kenntnisse über aspektorientierte Programmierung, das Design anderer aspektorientierter Sprachen, den Aufbau ihrer Implementierungen, das Design von nesC und den Aufbau des nesC -Compilers und seines Frameworks vonnöten. Innerhalb dieser Arbeit werden all diese Kenntnisse erarbeitet werden. Zusätzlich wird auch in die Themengebiete des Loggings und der Sensornetze eingeführt.

1.3 Überblick über die Arbeit

Dieses Kapitel 1 motiviert die aspektorientierte Spracherweiterung für nesC und be- schreibt die Aufgabenstellung. Kapitel 2 führt in die Gebiete der Sensornetze, des Log- gings und der aspektorientierten Programmierung ein. In Kapitel 3 werden zunächst verwandte Arbeiten zu dieser Arbeit im Bereich der Sensornetze vorgestellt. Dann werden Arbeiten und Implementierungen zum Thema Logging und aspektorientier- te Spracherweiterungen verschiedener Sprachen analysiert. Aus diesen werden erste Schlussfolgerungen für eine Realisierung einer aspektorientierten Spracherweiterung für nesC gezogen. Auch wird das Sprachdesign von AspectJ, an welches sich viele aspektorientierte Sprachen anlehnen, vorgestellt. Composition Filters als Alternative zum Standardaspektmodell werden kurz besprochen. Kapitel 4 stellt das Design der Sprache nesC vor. Dann beschäftigt es sich auf der Basis von AspectJ mit dem De- sign der aspektorientierten Sprache für nesC. Dafür werden zunächst mögliche Joint- points in nesC -Programmen gefunden. Dann werden Pointcuts und Advices für nesC definiert. In Kapitel 5 wird der interne Aufbau des Compilers von nesC sowie sein Framework beschrieben. Kapitel 6 beschäftigt sich schließlich mit dem Einweben der Aspekte der aspektorientierten Sprache mit Hilfe einer Compilererweiterung, welche die aspektorientierte Spracherweiterung implementiert. Auch Erkenntnisse, die wäh- rend der Realisierung gezogen werden, werden hier vorgestellt. In Kapitel 7 wird die Implementierung der Spracherweiterung im Hinblick auf das Logging evaluiert. In Ka- pitel 8 werden eine Zusammenfassung, Schlussfolgerungen und ein Ausblick gegeben.

Kapitel 2 Grundlagen

Dieses Kapitel enthält Grundlageninformationen für das Verständnis dieser Di- plomarbeit. Es wird in das Gebiet der Sensornetze eingeführt und deren Anforde- rungen und Anwendungsgebiete beschrieben. Das Konzept der aspektorientier- ten Programmierung wird vorgestellt. Über die Durchführung des Loggings mit Hilfe der aspektorientierten Programmierung und auch der Nutzen auf anderen Anwendungsgebieten wird die aspektorientierte Programmierung für Sensornet- ze weiter motiviert.

2.1 Drahtlos verbundene Sensornetze

2.1.1 Motes als Knoten eines Sensornetzes

Drahtlos verbundene Sensornetze (Wireless Sensor Networks) [30] sind Netze beste- hend aus einzelnen Knoten, welche Motes genannt werden. Das Netz wird mit Hilfe von Funkverbindungen aufgebaut. Ein Mote stellt ein kleines autarkes Computersys- tem dar. Ein Mote besteht - wie Abbildung 2.1 veranschaulicht - aus einer CPU mit nicht-flüchtigem und flüchtigem Speicher für Programm und Daten. Diese CPU hat Zugriff auf einen oder mehrere Sensoren als Eingabegeräte und auf ein Funkinterface, über welches der Mote mit anderen Motes Nachrichten austauschen kann. Zusätz- lich kommt eine Energieversorgung meist in Form einer Batterie hinzu. Von diesem Standardaufbau kann es Abweichungen geben. Beispielsweise ist es möglich, dass ein Mote als ein Gateway für Nachrichten innerhalb des Sensornetzes nach außen dienen soll und deswegen über keine Sensoren verfügt; dafür jedoch meist über ein zweites Netzinterface. Auch gibt es Spezialanwendungen, in welchen Motes über Steuerungs- hardware verfügen oder eine Ausgabehardware verwenden, mit der sie auf ihre Um- welt Einfluss nehmen können. So ist eine Steuerung z.B. von Ventilen durch ein Mote durchführbar oder ein Mote kann selbständig seine Position ändern[66]. Auch kann ei- ne simple Darstellung von Daten über die Ausgabe-Leds von einem Mote durchgeführt werden[1]. Abbildung 2.2 zeigt das Foto eines Motes. Der dargestellte Mote, welcher von Ambient Systems B.V. vertrieben wird, kommt in Sensornetzen zur Verfolgung von Warenströmen im Handel zum Einsatz. Es handelt sich dabei um einen Mote von normaler Größe. Es ist auch möglich, kleinere Motes herzustellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Aufbau eines Motes, eines Knotens im Sensornetz.

Mehrere Motes bauen untereinander ein Netz bestehend aus drahtlosen Verbin-dungen auf. Der Zweck eines solchen Netzes ist es, Daten an unterschiedlichen Orten zu erfassen und über das Netz zur Sammlung und Auswertung an eine Datensenke zu senden. Diese Datensenke ist meist ein Gateway, welches Daten entweder über ein weiteres Netz oder auch direkt beispielsweise an einen PC weiterleitet. Dieser PC stellt meist die Daten für den Benutzer visuell dar und übernimmt auch eine eventuelle Archivierung der Daten. In vielen Fällen werden die Steuerkommandos für das Sen-sornetz manuell in den über das Gateway angeschlossenen PC eingegeben oder aber auf diesem PC automatisch berechnet. In Abbildung 2.3 ist verdeutlicht, welchen ex-emplarischen Weg erfasste Sensordaten durch ein Netz nehmen könnten. Die Daten werden von den Sensoren des linken Motes erfasst, innerhalb dieses Motes verarbeitet und in Form von Funknachrichten über das Netz nach rechts zur Datensenke geleitet. Steuerungskommandos nehmen genau den umgekehrten Weg. Es ist die Aufgabe eines Netzprotokolles, die Nachrichten von Mote zu Mote an das Zielmote zu leiten.

Jedoch gibt es für diese Datenströme Ausnahmen. Manchmal macht es Sinn Daten direkt zu verwerten, um entsprechende Steuerungshardware an den Motes anzuspre-chen, wie oben bereits erwähnt. Dies macht beispielsweise Sinn bei der Anwendung von Sensornetzen in selbstheilenden Minenfeldern [66]. Manchmal können Daten auch direkt im Sensornetz über Leds angezeigt werden, ohne dass eine Datensenke im Sen-sornetz zur Verfügung stehen muss. Leds direkt an den Motes können zum Beispiel zur Unterstützung des Zusammenbaus von Ikea-Möbeln verwendet werden, indem diese dem Heimwerker Anweisungen geben [1].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Ein Mote zusammen mit seinen Batterien.

Foto: Ambient Systems BV

Abgedruckt mit freundlicher Genehmigung.

2.1.2 Anforderungen an Sensornetze

An Sensornetze werden unterschiedliche Anforderungen gestellt. Die Hauptanforde- rung ist, dass Daten möglichst ressourcenschonend erfasst und übertragen werden sol- len. Der Grund hierfür ist zum einen, dass die auf den Motes angebrachten CPUs und auch die anderen Komponenten beispielsweise das Funkinterface keine hohe Leistung bieten, da sie günstig sein müssen. Da Motes in hoher Stückzahl hergestellt werden müssen, wird mit weniger leistungsfähigen Komponenten an den Kosten der Motes gespart. Die Kosten der Motes machen fast die gesamten Kosten eines Sensornetzes aus. Auch machen eine günstige CPU und günstige weitere Komponenten eventu- ell die Anwendung eines Sensornetzes erst wirtschaftlich. Ein anderer Grund für das Schonen von Ressourcen ist, dass nicht viel Energie zur Verfügung steht, da Motes nor- malerweise über Batterien betrieben werden. Sensornetze sollen in ihrer Umwelt meist eine lange Zeit im funktionsfähigen Zustand verweilen. Ein Austauschen der Batterien ist teuer, da Motes häufig in unwegsamem Gelände platziert sind oder sogar gar nicht erreicht werden können. Je weniger Energie ein Mote verbraucht, desto länger werden seine Batterien Energie liefern, desto länger bleibt der Mote einsatzbereit und desto mehr Nutzen bringt das Netz. Es gibt auch Motes, welche mit erneuerbaren Energi- en wie Schwingungen der Umwelt, Solarenergie, Temperatur- und Druckschwankun- gen oder durch die Bewegungsenergie von Flüssigkeiten oder Gasen betrieben werden bzw. deren aufladbare Batterien dadurch neue Energie erhalten. Jedoch sind auch diese Energien nur begrenzt verfügbar, sodass auch hier nicht unbegrenzt Leistung genutzt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Aufbau eines Sensornetzes.

Das Benutzen des Funkinterfaces verbraucht sowohl zum Senden als auch zum Empfangen die meiste Energie. Deshalb sollte dieses Interface möglichst wenig be- nutzt werden. Um dies zu erreichen, ist es wünschenswert, sowohl die Erfassung der Daten wie auch das Versenden und Weiterleiten der Daten anwendungsspezifisch zu gestalten, um nicht unnötig viele Daten erfassen oder versenden zu müssen. Aus ge- nau diesem Grunde wird auf den Motes eines Netzes ein Programm installiert, welches entsprechend der Anwendung spezifisch ist und intelligent die Sensordaten erfasst, vorverarbeitet und versendet oder auch schon verwertet. Einzelne Knoten des Netzes können Nachrichten weiterleiten, wobei es auch sinnvoll sein kann, dass Motes Nach- richten interpretieren und mehrere Nachrichten in einer Nachricht zusammengefasst weiterleiten.

Es ist die Aufgabe eines Programmierers, entsprechende Programme zu schreiben und auch zu testen. Dabei kann ein Mote nicht einzeln gesehen werden, sondern das ganze Netz muss betrachtet werden. Auch ist es nicht praktikabel, Tests nur auf Simu- lationen beruhen zu lassen, da Motes und deren Funkübertragungen Umwelteinflüssen ausgesetzt sind und ein installiertes Netz sich anders verhält als eine Simulation des- selben. Auch kann ein installiertes Netz sich anders verhalten als dasselbe im Testbed. Somit sind neue Tools für den Programmierer zu entwickeln, welche ihn in der Pro- grammierung und in der Observation eines Sensornetzes unterstützen.

Weitere Anforderungen werden an das Netz und seine Protokolle selbst gestellt. Das Netz soll ad hoc aufgebaut werden können. Knoten sollen selbst aufgrund der Analyse von Signalstärken und Laufzeiten ihre Position bestimmen können. Zusätzlich besteht ein solches Netz eventuell aus tausenden von Knoten. Das Netz soll den Ausfall eines Knotens erkennen und selbstständig ausgleichen können. Weiterhin haben Sen- sornetze andere Verkehrsparameter als traditionelle Netze wie das Internet. Nach einer langen, sehr ruhigen Phase können plötzlich sehr viele Nachrichten gesendet werden. Dies ist dann der Fall, wenn ein Sensornetz seine Umgebung observiert und das zu observierende Ereignis, auf welches es programmiert ist, eintritt und von sehr vielen Knoten gleichzeitig erkannt wird. Protokolle müssen diesem Problem gewachsen sein.

Um all diesen Anforderungen zu begegnen, werden neue Konzepte benötigt. Die Implementierungen dieser müssen unter realen Bedingungen im Feld getestet werden. Traditionelle, sich auf PCs beziehende Testmethoden können nicht mehr verwendet werden, da es sich bei Sensornetzen um viele einzelne Motes handelt, die sich zusätz- lich noch voneinander entfernt befinden. Die Anforderungen an die Testumgebung un- terscheiden sich somit rudimentär von den Anforderungen an eine PC-Testumgebung. Es müssen für Entwickler neuartige Tools bereitgestellt werden. Diese Diplomarbeit entwickelt eine aspektorientierte Spracherweiterung, um dem Entwickler Möglichkei- ten an die Hand zu geben, Logging innerhalb eines Sensornetzes komfortabel zu im- plementieren.

2.1.3 Anwendungsgebiete von Sensornetzen

Die Anwendungsgebiete [30, 53, 26] von Sensornetzen sind vielfältig. Dennoch kann man ihre Anwendung darin verallgemeinern, dass immer aus einem bestimmten, von den Sensormotes abgedeckten Gebiet Daten erfasst werden. Drahtlose Sensornetze werden häufig einer drahtgebundenen Variante vorgezogen, da die fehlende Verka- belung Kosten spart und des Weiteren die Installation vereinfacht bzw. manchmal erst möglich macht. So kann in manchen Fällen eine Installation durchgeführt werden, in- dem die einzelnen Sensormotes von einem unbemannten Flugzeug abgeworfen wer- den[49]. Bei einem Abwurf aus einem Flugzeug ist eine Verkabelung nicht möglich.

Um eine Idee von den Anwendungsgebieten zu erlangen, werden im Folgenden ei- nige exemplarische Anwendungsgebiete aufgezeigt. Aus den einzelnen Anwendungs- gebieten sind wiederum nur exemplarische Arbeiten herausgegriffen. In einzelnen Ge- bieten ist die Forschung schon weiter fortgeschritten. In anderen befindet sie sich erst im Anfangsstadium. Um in den weiter fortgeschrittenen Gebieten einen umfassenden Überblick zu erlangen, muss in diesen tiefer recherchiert werden. Da diese Arbeit je- doch keine Recherche über Sensornetz-Anwendungsgebiete darstellt, wird meine Re- cherche nur einem Überblick gerecht.

Sensornetze werden gerne benutzt, um Daten in einem Gelände zu erfassen, bei- spielsweise Temperaturen, Luftfeuchtigkeit, Luftdruck, Erschütterungen, Bewegungen über Infrarotsensoren oder Gasbestandteile. So kann ein Sensornetz in einem wald- brandgefährdeten Gebiet installiert werden und einen Waldbrand entdecken[22]. In dieses Netz können langjährige Erfahrungen über Waldbrände, die schon auf tradi- tionellem Weg gemacht wurden, eingearbeitet werden, sodass Waldbrände sehr früh detektiert werden können, Alarm gegeben wird und entsprechend eine effektive Be- kämpfung stattfinden kann, sodass große kostbare Waldflächen vom Feuer verschont bleiben. Auch kann ein Sensornetz bei dem Anbau von beispielsweise Wein [10] ge- nutzt werden. Hier werden die Arbeiter mit Informationen über die Umgebung der Reben und Trauben versorgt. Beispielsweise ist es denkbar, anhand von bestimmten Faktoren zu bestimmen, wann die Trauben reif sind oder Ungeziefer zu bekämpfen ist. Selbstverständlich sind Sensornetze auch für die Beobachtung aller anderen Nutzpflan- zen oder Zierpflanzen geeignet. Sensornetze lassen sich auch einsetzen, um innerhalb eines Geländes Bewegungen von Fahrzeugen [49] zu beobachten. Hier werden Magnet- felder, welche von vorbeifahrenden Fahrzeugen erzeugt werden, detektiert. Selbstver- ständlich könnten auch andere Typen von Sensoren verwendet werden, um z.B. Perso- nen zu verfolgen. Somit sind Sensornetze für Sicherheitsanwendungen im militärischen und zivilen Bereich interessant.

Auch werden Sensornetze zur Beobachtung von Tieren eingesetzt. Dabei werden sowohl Nutztiere als auch wild lebende Tiere beobachtet. Hier ist es möglich, eine Ge- ländeüberwachung durchzuführen, in welcher Sensoren im Gelände platziert werden. Jedoch ist auch eine direkte Überwachung von Tieren möglich, indem die Sensoren von den Tieren getragen oder sogar geschluckt werden und Daten aus ihrem Magen liefern[44]. Dabei lässt sich anhand der Sensordaten auf die aktuelle Gesundheit des Tieres schließen. Auf dem Great Duck Island wurden Tierbeobachtungen an Vögeln durchgeführt[42], indem Sensormotes in deren Nistplätze installiert wurden. So konn- ten die scheuen Vögel über einen langen Zeitraum beobachtet werden und es war mög- lich, wertvolle Informationen über sie zu sammeln.

Weiterhin lassen sich Sensornetze zur Beobachtung von Warenströmen im Han- del einsetzen, beispielsweise um festzustellen, ob die Kühlkette[28] für verderbliche Waren unterbrochen worden ist. Noch werden in diesem Bereich RFID-Tags verwen- det. RFID-Tags sind Schaltkreise in denen Informationen gespeichert und berührungs- los ausgelesen werden können. Diese Datenspeicherung kann jedoch nur passiv an- gewandt werden. Es wird ein externes Lese- und Schreibgerät benötigt. Der Grund, weshalb in diesem Bereich noch keine Sensornetze eingesetzt werden, sind Kosten- gründe. Sensornetze würden jedoch den großen Vorteil bringen, über längere Distan- zen Informationen senden zu können als die RFID-Tags; und sie würden den noch größeren Vorteil bringen, ein aktives Logging beispielsweise der Temperatur durch- führen zu können. Weiter die Kosten für die Hardware von Motes zu senken, ist als eine Herausforderung an das Design von Sensornetzen zu sehen.

Sensornetze leisten in Katastrophenfällen wertvolle Dienste, indem sie wichtige Informationen über die Unglücksstelle schnell bereit stellen. Beispielsweise können Sensornetze in Tunneln installiert werden[43]. Kommt es zu einem Unfall, so kann das Sensornetz mit Sensormotes, welche sich an den verunglückten Fahrzeugen oder gar an den Fahrzeuginsassen befinden, kommunizieren, um deren Zustand zu erfah- ren und diesen an den Rettungsdienst weiter zu vermitteln, sodass schnell und effektiv geholfen werden kann. Nach Erdbeben [33] oder auch bei steigendem Alter des Bau- werkes ist die Struktur oder das Baumaterial geschädigt. Leider kann dies von außen an einem Gebäude oder auch beispielsweise einer Brücke schlecht erkannt werden. Es kann auf Erschütterungsdetektionen an verschiedenen Stellen des Bauwerkes zur Vor- hersage eines Einsturzes zurückgegriffen werden, welche mit Sensormotes geschehen kann. Kabellose Sensornetze können zur Beobachtung von Vulkanen eingesetzt wer- den, um Eruptionen vorherzusagen[64]. Hierfür werden Infraschall oder Schallwellen- Detektoren an den Motes verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Vision des intelligenten Staubes.

Foto: Peter Menzel

Quelle: http://robotics.eecs.berkeley.edu/~pister/ SmartDust/BlowDust.htm

Abgedruckt mit freundlicher Genehmigung.

Auch zum Überwachen von Patienten in Krankenhäusern[55] können Sensornet- ze genutzt werden. So können Sensoren, die beispielsweise ein EKG erstellen, an den Patienten angebracht werden und so drahtlos und kontinuierlich den Gesundheitszu- stand übermitteln. Auch ist es möglich, mittels Sensornetzen den aktuellen Standort eines Patienten immer abfragbar zu haben. Krankenhäuser sind komplexe Systeme, in welchen unterschiedlichste Untersuchungen für Patienten gemanagt werden müssen. Somit unterstützt ein Sensornetz das Personal, indem es Informationen darüber bereit- stellt, wo sich ein Patient mit seinem Bett gerade befindet. Andere Anwendungsgebiete im Krankenhaus sind zusätzlich denkbar.

Die Einsatzgebiete von Sensornetzen sind vielfältig und werden in den kommenden Jahren in viele Gebiete weiter Einzug halten und auch neue Gebiete erobern.

2.1.4 Weitere Miniaturisierung bis hin zum Smart Dust

Die Einsatzgebiete von Sensornetzen weiten sich noch weiter aus, wenn man auf das noch mögliche Miniaturisierungspotential von Motes schaut. Häufig sollen die Sen- soren von der Umwelt nicht wahrgenommen werden, was ein Grund zur weiteren Miniaturisierung ist. Auch bringt eine weitere Miniaturisierung der Hardware wei- tere Einsparungen bei ihren Kosten und auch weitere Energieeinsparungen. Je wei- ter miniaturisiert wird, desto näher rückt die Vision des intelligenten Staubes (Smart Dust) [29], wie sie das Bild in Abbildung 2.4 veranschaulicht.

2.1.5 Neue Anwendungsgebiete durch Miniaturisierung

Auch wenn heutzutage noch nicht dieser Stand erreicht ist, wurden dennoch schon einige interessante Anwendungsgebiete [29, 48] entdeckt, die sich mit konsequenter Miniaturisierung und kostengünstiger Massenanfertigung erschließen:

Intelligenter Staub kann so noch besser für militärische Zwecke eingesetzt werden oder aber auch, um wieder Daten aus der Umwelt zu sammeln. Diesmal kann der Staub sogar verwendet werden, ohne dass er Einfluss auf seine jeweilige Umgebung hat, wie beispielsweise in einem Windkanal. Da die Motes nunmehr als Staub vorliegen, kön- nen sie fließend mit der Umwelt mitbewegt werden, wie beispielsweise in Sandstür- men oder Meeresströmungen. Ein weiterer Vorteil des Staubes ist, dass die Partikel in großer Anzahl vorliegen. So kann der zu überwachende Bereich immer besser abge- deckt werden. Weiterhin können Gegenstände in Zukunft mit günstigen Sensormotes versehen werden, welche Informationenüber den Gegenstand bereithalten. Ähnlich einem RFID-Tag kann ein etwas leistungsfähigerer Sensormote für einen Diebstahl- schutz sorgen, indem er sich an entsprechenden Stellen meldet, an denen er vorbei getragen wird, wenn der Gegenstand als gestohlen gemeldet ist. Intelligenter Staub eignet sich auch dafür, um an kleinen Tieren oder auch am Menschen angebracht zu werden. So wäre durch das Detektieren der aktuellen Position von Sensormotes, welche an den Fingerkuppen einer Hand angebracht sind, eine Implementierung einer virtu- ellen Tastatur möglich. Durch anbringen von Sensormotes im Gesicht eines Patienten, der unter Sprachstörungen leidet, kann dieser mit Hilfe des Computers mit seiner Um- gebung über Gesichtsausdrücke, welche das Netz der Motes erfasst, kommunizieren.

2.1.6 Die Sprache nesC und das Betriebssystem TinyOS

Um höchstmögliche Energieeffizienz und geringe Hardwarekosten zu gewährleisten, muss das Programm, welches auf den Motes installiert wird, hochoptimiert vorliegen, um so wenig Ressourcen wie möglich zu verbrauchen. Es wird auf dem Mote ein mini males Betriebssystem installiert, welches monolithisch schon zur Compilezeit mit dem auszuführenden Programm verbunden wird. Beides, Betriebssystem und Programm, werden statisch kompiliert, was eine hohe Optimierung der Funktionsaufrufe schon vor dem Aufspielen auf den Mote möglich macht.

Für eine hohe Optimierung der auf den Motes ausgeführten Programme wurde die Programmiersprache nesC und das darin implementierte Betriebssystem TinyOS entwickelt. nesC leistet die oben erwähnte statische Verknüpfung. Ein Binärfile des Programmes statisch verknüpft mit dem Betriebssystem TinyOS wird auf dem Mote zur Ausführung gebracht. Thema dieser Diplomarbeit ist die Entwicklung einer aspektorientierten Spracherweiterung für die Sprache nesC.

2.2 Tools zur Unterstützung des Programmierers

2.2.1 Tools zur Programmprüfung

Entwickler von Anwendungen wünschen sich möglichst mächtige Tools, um ihre Anwendungen einfach, schnell, fehlerfrei und auch laufzeitoptimiert zu programmieren. Leider stoßen schon vorhandene Tools bei Sensormotes an ihre Grenzen:

Zum einen sind geringe Hardwareressourcen auf den Motes vorhanden. Bestehen- de Tools auf PC-Ebene nehmen auf die Hardwareressourcen keine besondere Rück- sicht. Dies ist vor allen Dingen seit der Einführung von Java der Fall. Java ist auf einfache Programmierung und Portierbarkeit hin programmiert, wobei Ressourcenein- bußen in Kauf genommen werden und auch aufgrund der immer leistungsfähigeren Rechnersysteme in Kauf genommen werden können. Auf Tools unter Java und ähnli- chen Sprachen wurde dieser Gedanke übertragen, so dass diese nicht auf Performance optimiert worden sind. Desweiteren kommt auch hinzu, dass diese Tools nicht in nesC implementiert sind, weshalb sie auf die nesC -Plattform portiert werden müssten.

Zum anderen verfügen Sensornetze über einen anderen Aufbau als taditionelle Tools erwarten. Der Sensormote befindet sich nur dann, wenn er sich in einem Test- bed befindet, direkt an einem Ausgabebildschirm, mit welchem er beispielsweise über eine serielle Schnittstelle kommuniziert. Es ist der Wunsch des Programmierers, über die Entfernung hinweg ein laufendes Programm auf einem Mote zu überprüfen. Unter Umständen ist es sogar nötig, das den Mote umgebende Sensornetz als Relay für Log- gingnachrichten zu verwenden. Auf ein solches Szenario sind traditionelle Tools nicht vorbereitet. Mit der Entwicklung eines Tools, welches speziell auf dieses Szenario zu- geschnitten ist, beschäftigt sich die Diplomarbeit „ Entwurf und Implementierung eines effizienten verteilten Logging- und Tracing-Frameworks für TinyOS”[18].

2.2.2 Logging und Debugging

Die oben angesprochenen PC-Tools, die eine Prüfung ermöglichen, sind Tools die das Logging- oder Debuggingkonzept implementieren. Logging und Debugging sind Mög- lichkeiten, eine Anwendung zur Laufzeit bei ihrer Arbeit zu beobachten. Hierbei kann sowohl die aktuelle Position des Programmzeigers innerhalb eines laufenden Program- mes interessant sein oder auch die aktuelle Variablenbelegung im Speicher.

Beim Debugging wird auf Position und Variablenbelegung mit einem separaten Programm von außen her zugegriffen. Das beobachtete Programm kann während der Laufzeit angehalten werden und der Programmierer kann den aktuellen Zustand des Programmes prüfen und auch verändern.

Beim Logging ist es umgekehrt. Hier werden von innen aus dem Programm heraus Nachrichten generiert, die den Programmzustand darstellen. Ein Logging eines Programmes wird wie folgt durchgeführt: Innerhalb des Programmes wird an bestimmten Stellen der Aufruf einer Loggingmethode vom Programmierer eingefügt. Dieser Loggingmethode werden Parameter übergeben, welche die Loggingmethode auf eine beliebige Loggingausgabe heraus schreibt. Die einfachste Loggingmethode ist die einfache Ausgabe der Daten auf die aktuelle Konsole mit der print-Methode des Systems. Jedoch wird meist eine angepasstere Loggingmethode genutzt.

Der Nachteil des Loggings gegenüber dem Debugging ist, dass es an unterschied- lichen Stellen im Programm implementiert werden muss. So macht der Loggingcode den schon vorhandenen Code unübersichtlich. Der Nachteil des Debuggings ist, dass extern von einem anderen Programm auf das zu beobachtende Programm zugegriffen werden muss. Das Setup ist schwieriger. Auch ist die Bedienung komplizierter.

2.3 Aspektorientierte Programmierung

2.3.1 Überblick über die aspektorientierte Programmierung

Weben von Aspekten bestehend aus Pointcuts und Advices

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Ein Aspekt bestehend aus einem Pointcut und einem Advice.

Die aspektorientierte Programmierung [32] ist eine neue Ausrichtung der Pro- grammierung, welche gerade in den letzten Jahren immer mehr Zulauf gefunden hat. Sie wird als eine Weiterentwicklung der objektorientierten Programmierung angese- hen. Der Kerngedanke der aspektorientierten Programmierung ist, dass durch soge- nannte Aspekte neuer Programmcode an bestimmten Programmstellen in ein Basis- programm eingefügt wird.

Der Prozess des Einfügens, welcher auch als Weben oder im Englischen Weaving bezeichnet wird, sieht im Detail wie folgt aus: Zu einem Basisprogramm werden ein oder mehrere Aspekte definiert. Ein Aspekt besteht dabei aus zwei Teilen, wie Abbildung 2.5 verdeutlicht:

- Ein Pointcut definiert die Stellen, an denen der Code eingewebt werden soll.
- Als Advice wird das Stück Code bezeichnet, welches in das Originalprogramm hinein gewoben wird. Dabei kann das Einweben entweder geschehen, indem

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Durch Aspekte wird der Programmcode in den Basiscode ein- gewoben.

der Code des Advices durch einen Methodenaufruf als eine Methode angesprun- gen wird oder indem der Advicecode direkt in das Basisprogramm hineinkopiert wird.

Stellen im Basisprogramm, an denen ein Pointcut möglicherweise greifen könnte, werden als Joinpoints bezeichnet.

Abbildung 2.6 gibt einen Überblick. In ihr finden wir zwei Aspekte, welche jeweils unterschiedliche Pointcuts und Advices beinhalten. Ein Pointcut kann keinen bis belie- big viele Joinpoints im Basisprogramm referenzieren. Dabei kann er keinen bis beliebig viele Advices einweben. Auch können Advices innerhalb der Aspekte existieren, die nicht von einem Pointcut benutzt werden. Die meisten Joinpoints innerhalb des Basis- programmes bleiben ungenutzt. Allerdings können auch an einem Joinpoint mehrere Aspekte eingewoben werden.

Crosscutting Concerns und Obliviousness

- Die aspektorientierte Programmierung löst durch das Einweben von Aspekten das Problem der Crosscutting Concerns. Ein Crosscutting Concern ist eine Programmfunktionalität, welche folgenden Effekt verursacht:

- Der Crosscutting Concern muss an vielen Stellen des Programmes implementiert werden. Ändert sich der Crosscutting Concern, so muss er dementsprechend an vielen Stellen des Programmes gleichzeitig editiert werden. Dies ist nicht nur lästig, sondern es erzeugt auch Fehler, indem Codeteile beispielsweise bei der Änderung vergessen werden. Dieses Problem ist als Scattering benannt.
- Auf der anderen Seite wird der Basiscode durch den Crosscutting Concern unübersichtlich, da an vielen Stellen Codeteile vorhanden sind, welche nicht die Hauptaufgabe des Basiscodes darstellen. Durch eine Unübersichtlichkeit des Basiscodes werden wiederum Fehler bei der Programmierung provoziert. Das Problem dieser Verschmutzung des Basiscodes ist als Tangling benannt.

Dadurch dass die aspektorientierte Programmierung es nun ermöglicht, Crosscut ting Concerns erst durch einen Aspekt in das Programm einzufügen, kann der Cross cutting Concern an nur einer Stelle implementiert werden. Gleichzeitig bleibt der Basiscode sauber und übersichtlich. Diese Trennung ist soweit ausgeprägt, dass es im Basiscode keine Hinweise auf den Crosscutting Concern mehr gibt. Auch ein Hinweis, ob ein Aspekt verarbeitet werden soll, findet man im Basiscode nicht. Diese Eigenschaft der aspektorientierten Programmierung nennt man Obliviousness.

Nachteile der aspektorientierten Programmierung

An dieser Stelle sei jedoch auch auf Nachteile der aspektorientierten Programmierung hingewiesen. Die Kapselung der Objekte, welche als eine der Hauptvorteile der objekt- orientierten Programmierung gesehen wird, wird durch die aspektorientierte Program- mierung aufgehoben. Dies ist so, weil Aspekte in Objekte hinein greifen können und dort Änderungen durchführen. Durch bedachte Programmierung von Aspekten lässt sich dieser Nachteil jedoch zum Vorteil nutzen, wie in unserem Falle des Loggings. Auch entsteht dieser Nachteil des Auflösens der Kapselung nicht in Systemen, die über keine Kapselung verfügen. Ein weiterer Nachteil der aspektorientierten Programmie- rung ist, dass mehrere Aspekte sich eventuell untereinander stören, wenn sie auf den gleichen Codeabschnitt angewandt werden. Weiterhin sieht ein Programmierer dem Basiscode nicht an, dass ein Aspekt wirkt und zerstört bei seiner weiteren Program- mierung eventuell Joinpoints, die die Pointcuts des Aspektes benötigen.

Diese Nachteile sind der Grund dafür, weshalb sich die aspektorientierte Programmierung noch nicht weitgehend durchgesetzt hat. Die Nachteile der aspektorientierten Programmierung zu überwinden, ist Thema der aktuellen Forschung.

2.3.2 Motivation des aspektorientierten Loggings für Sensormotes

Das Logging wird häufig als ein Paradebeispiel eines Crosscutting Concern genannt. Der Loggingcode macht den Basiscode erheblich unübersichtlicher, indem er überall im Programm verteilt angegeben werden muss. Die so verteilten Loggingmethoden können weiterhin schlecht geändert werden. Ein weiterer Nachteil, der sich besonders auf die Sensormotes mit knappen Ressourcen auswirkt, ist, dass es dem Programmie- rer lästig sein wird, für das auszuliefernde Programm alle Loggingnachrichten im Code zu entfernen. Demzufolge wird er wahrscheinlich den Loggingcode im Programm be- lassen. So werden die Loggingnachrichten und Abfragen jedoch durch den Compiler weiterhin in den Code hinein geschrieben. Bei der Ausführung muss nun jedes Mal eine überflüssige Abfrage stattfinden, ob das Logging stattfinden soll oder nicht. Was schwerer wiegt: Es muss Speicherplatz innerhalb des Programmes nutzlos belegt wer- den, um den Loggingcode abzulegen, welcher nie benutzt werden wird. Diese Probleme können mit der aspektorientierten Programmierung gelöst wer- den, indem das Logging in einen Aspekt gekapselt wird. Dieser Aspekt definiert zum einen, wo das Logging eingefügt werden soll und was geloggt wird. Dies wird an einer Stelle in dem zuständigen Aspekt definiert. Der Rest des Programmes bleibt frei von dem Loggingcode. Dies hat anschließend den großen Vorteil, dass das Programm auch vollständig ohne Aspekt kompiliert werden kann, sodass das Logging vollständig aus dem Binärprogramm ausgenommen wird. Dies ermöglicht uns, auf einfache Weise ein Binärprogramm auszuliefern, welches zur Laufzeit keine Ressourcen für das Logging benutzt bzw. blockiert. Weiterhin können mit Hilfe unterschiedlicher Aspekte unter- schiedliche Loggingfunktionen eingewebt werden, je nachdem ob die Ausführung des Programmes simuliert wird, in einem Testbed geschieht oder der Mote, auf welchem das Programm sich befindet, schon im Feld, in dem die Sensordaten zu messen sind, installiert ist.

Das Logging konnte erfolgreich und komfortabel in aspektorientierten Sprachen auf PC-Ebene implementiert werden. Das Buch[36] beschreibt in Kapitel 5 die Im- plementierung eines Loggingaspektes in der Sprache AspectJ. AspectJ verfügt über die Möglichkeit vor, nach oder umschließend um Java -Methoden Aspektcode einzuweben. So kann beispielsweise Loggingcode eingefügt werden, der protokolliert, dass eine Me- thode einer Klasse aufgerufen oder beendet worden ist. AspectJ unterstützt das Ausle- sen der Parameter der Methode über den Aspekt, sodass diese Parameter mit geloggt werden können. Das Kapitel des Buches demonstriert, wie komfortabel ein Logging mit AspectJ implementiert werden kann und welche Codeeinsparungen dadurch gemacht werden können.

2.3.3 Weitere Möglichkeiten für die Anwendung von Aspekten auf Sensormotes

Nicht nur das Logging kann mithilfe von Aspekten gekapselt werden, sondern dies ist auch für viele weitere Funktionalitäten möglich:

Beispielsweise können Aspekte für Tests des Basisprogrammes benutzt werden. Es ist möglich, an bestimmten Stellen im Programm Module durch Mockmodule zu er- setzen. Mockmodule - in Anlehnung an den Begriff des Mockobjektes - sind Module, die eine Kommunikation an einer Schnittstelle des Systems nur simulieren, statt sie real durchzuführen. So können Tests durchgeführt werden, ob Programme auf einzeln betrachteten Motes des Netzes unter bestimmten Bedingungen korrekt arbeiten. Vor allen Dingen die Netzschnittstelle könnte durch Mockmodule ersetzt werden. Mithilfe von Aspekten ist es möglich, dem Programm auf dem Mote ein real nicht vorhande- nes Netz - auch mit Übertragungsstörungen - zu simulieren, damit das Programm getestet werden kann. Mithilfe von Aspekten können auch die gelesenen Sensordaten manipuliert werden. Dies könnte beispielsweise zu Testzwecken genutzt werden, um zu prüfen wie ein Sensornetz bei Eintritt eines Ereignisses arbeitet, ohne dass dieses Ereignis, sei es z.B. ein Waldbrand, tatsächlich provoziert werden muss. Denkbar wäre weiterhin beispielsweise auch die Aufzeichnung der Sensordaten in einem Mote wäh- rend eines Ereignisses wie beispielsweise eines Waldbrandes mithilfe eines Aspektes.

Hierbei müssten keine Änderungen des eigentlichen Basisprogrammes durchgeführt werden. Mithilfe dieser Daten kann dann später zu Testzwecken das Waldbrandereig- nis ohne reales Feuer in einem Motenetz simuliert werden. Hierzu könnten die zuvor von einem Aspekt gesammelten Daten wieder in die Sensordaten mit einem anderen Aspekt zurückgespielt werden. Durch Aspekte können - ohne ein massives Eingreifen in den Code des Basisprogrammes - Erkenntnisse gezogen und Fehler im Basispro- gramm gefunden und korrigiert werden. Da das Basisprogramm unverändert bleibt, wird es später auch mit realen Daten unverändert arbeiten. Eine zusätzliche Fehler- quelle, welche sich auftut, wenn der Simulationscode aus dem Basisprogramm durch den Programmierer wieder von Hand gelöst werden muss, tut sich bei Simulationen mit Aspekten nicht auf.

Auch eine Manipulation oder gänzliche Änderung eines Programmteils für das Pro- duktivsystem ist möglich. So ist eine Manipulation oderänderung des Netzwerkproto- kolles mit Aspekten möglich, wodurch das Netzwerkprotokoll separat vom Hauptpro- gramm betrachtet werden kann. Dies ist beispielsweise wiederum für Tests nützlich, wenn verschiedene mitunter komplizierte Netzwerkprotokolle zur Auswahl stehen und getestet werden sollen.

Ein Profiling von einzelnen Modulen bzw. ihren Funktionen ist mit Aspekten mög- lich. Es ist bekannt, dass das Lesen der Sensormesswerte und vor allen Dingen das Sen- den und Empfangen von Datenpaketen die meiste Energie auf einem Mote verbraucht. Nun können die Module für die Sensoren und die Module für die Netzwerksteuerung überwacht werden. Anhand dieser Aussagen lässt sich wiederum das Lesen der Sens- ordaten oder das Netzwerkprotokoll optimieren. Auch kann der Mote oder auch nur seine Simulation nun darüber Aussagen machen, wie lange seine Batterie noch halten wird.

Zeitkritische Berechnungen können mit Hilfe von Aspekten Überwacht und op timiert werden. Falls die Berechnungen zu lange dauern, kann den entsprechenden Programmteilen der Auftrag gegeben werden, die Komplexität zu reduzieren oder die Berechnung kann seltener gestartet werden. Diese Implementierung ist durch das Eingreifen eines Aspektes in den Schedulermechanismus möglich, welcher bei nesC mit dem Hauptprogramm direkt kompiliert wird.

Weiterhin können auch Sekundäraufgaben durch Aspekte implementiert werden. So ist es beispielsweise möglich, für den Administrator des Sensornetzes einen Aspekt einzuweben, der es ihm ermöglicht, die Leds auf den Motes so zu schalten, dass er be- stimmte Motes im Netz anhand seiner Led-Schaltung finden kann, um beispielsweise an diesen die Batterien auszutauschen. Beliebige andere Sekundäraufgaben können mit Aspekten implementiert werden, sodass das Hauptprogramm seine eigentliche Aufga- be ausführen kann und nicht mit Fremdinformationen überladen wird.

Viele weitere Implementierungen von Aspekten sind denkbar. Demzufolge hat eine aspektorientierte Spracherweiterung von nesC viele Anwendungsgebiete. Die Erschlie- ßung aller dieser Anwendungsgebiete soll jedoch nicht Teil dieser Diplomarbeit sein. Weitere Anstrengungen sollten jedoch an dieser Stelle unternommen werden.

Kapitel 3 Analyse von Logging-Frameworks und aspektorientierten Spracherweiterungen und deren Implementierungen

Um eine aspektorientierte Spracherweiterung zum Durchführen eines Loggings für die Sprache nesC zu entwickeln, wird in diesem Kapitel eine Recherche zu an- deren aspektorientierten Spracherweiterungen und Logging-Frameworks durch- geführt. Dabei wird ein spezielles Augenmerk auf die Implementierung der Spra- cherweiterungen gelegt. Das Sprachdesign von AspectJ wird vorgestellt. Aus die- ser Recherche werden Informationen darüber gezogen, wie für das Design der aspektorientierten Sprache und die Realisierung dieser für nesC vorzugehen ist. Das Kapitel geht auch auf verwandte Arbeiten der Diplomarbeit ein.

3.1 Verwandte Arbeiten

In TinyOS und dem nesC -Compiler ist die Simulationsumgebung TOSSIM [40] inte- griert. Für diese Simulationsumgebung können in den Quellcode Debuggingnachrich- ten eingefügt werden, welche während einer Simulation zur Prüfung des aktuellen Zu- standes des Programmes ausgegeben werden können. Der Vorteil der Debuggingnach- richten ist es, dass diese sich nur für eine Simulation im Code befinden. Wird das Programm für das Aufspielen auf einen Mote kompiliert, so werden diese restlos aus dem Code entfernt. So können allerdings diese Nachrichten nur lokal auf dem PC in einer Simulation erzeugt werden. Die Nachrichten können nicht in einem Testbed oder auf einem deployten Mote im Feld erzeugt werden. Die Debuggingfunktion ist eine Loggingfunktion, welche für eine Simulation eingewebt werden könnte.

TinyOS bringt weiter eine rudimentäre printf-Anweisung mit[60]. Mit dieser An- weisung ist es möglich, Ausgaben auf den seriellen Port zu leiten, während die Ap- plikation auf dem Mote läuft. So können diese Ausgaben über einen an die serielle Schnittstelle angeschlossenen PC gelesen werden und entsprechend ausgegeben werden. Die printf-Anweisung kann jedoch weder in einer Simulation benutzt werden noch kann sie im deployten Zustand des Motes im Feld genutzt werden. Zusätzlich verbleiben diese Anweisungen im kompilierten Binärprogramm, wenn der Programmierer sie nicht für das Deployment entfernt. Somit werden Ressourcen auf dem Mote unnötigerweise verbraucht. Die printf-Anweisung ist eine Loggingfunktion, welche über Aspekte in den Programmcode eingewebt werden könnte.

Marionette [65] ist ein Framework, welches es dem Programmierer ermöglicht, über Remote Procedure Calls (RPC) auf Methoden eines Motes von einem entfernten Client, welcher ein PC ist, zuzugreifen. Zusätzlich sind die Methoden poke und peek imple- mentiert, um Variablen auf dem Mote zu jeder Zeit auszulesen und auch ändern zu können. Dies ist möglich, da es keinerlei Schutz des Speichers auf Sensormotes gibt. Für die Anwendung dieses Frameworks in eigenen Programmen muss der Entwickler keinen eigenen Code schreiben. Der Code wird von Marionette selbständig hinzuge- fügt. Die einzige zusätzliche Arbeit ist es, Funktionen, welche über RPCs aufgerufen werden sollen, mit einer Annotation im nesC -Quellcode zu versehen. Das Framework hat im entfernten Sinn mit meiner Arbeit die Gemeinsamkeit, dass Variablen ausgele- sen werden können, welche in meiner Arbeit durch das Logging ausgelesen werden.

Als ANesC [62, 63] wird eine zukünftige aspektorientierte Erweiterung von nesC bezeichnet, welche momentan im Rahmen einer Doktorarbeit entwickelt wird. Der ver- folgte Ansatz für ANesC führt nicht in Richtung Logging, sondern ist für das Res- sourcenmanagement auf Motes gedacht. Dabei sollen Aspekte definierbar sein, welche Echtzeit-Deadlines oder Speicherüberläufe des Stacks oder Hauptspeichers als Point- cuts unterstützen, sodass entsprechende Fehlerbehandlungsroutinen aufgerufen wer- den können. Die nesC -Plattform selbst unterstützt keine Echtzeit-Deadlines, da ein Task immer so lange läuft, bis er abgeschlossen ist. Dies wird auf diese Weise durch- geführt, um auf ein aufwendiges Task-Scheduling auf dem Mote zu verzichten und Ressourcen zu sparen. Des Weiteren wird kein Überlauf des Stacks auf der Hardware- plattform erkannt. Wenn der verfügbare Speicher zum Allokieren neuer Speicherblöcke nicht mehr ausreicht, wird null als Pointer zurückgegeben, was der Programmierer in- nerhalb des Codes überprüfen müsste. Der Autor möchte nun folgendes Problem exem- plarisch mit einem Aspekt lösen: Viele Anwendungen auf Motes sammeln periodisch Daten und bearbeiten diese dann vor. Hierbei wird nun ein möglichst kontinuierliches Analysieren unter der maximal möglichen Auslastung der CPU gewünscht. Die Senso- ren werden von der CPU angewiesen, in bestimmten Zeitabständen Daten zu liefern. Nun kann es vorkommen, dass die CPU das Analysieren des vorherigen Datenblocks schon beendet hat, bevor neue Daten vorliegen. Der Zeitraum, in welchem die Senso- ren Daten liefern, kann in diesem Fall verkürzt werden oder der Aufwand der Berech- nung für die Analyse muss vergrößert werden, d.h. genauere Berechnungen können durchgeführt werden. Im umgekehrten Fall hat die CPU noch nicht die Berechnung abgeschlossen, während neue Daten von den Sensoren zur Verfügung gestellt werden. In diesem Falle müssen die neuen Daten verworfen werden. Die Sensoren müssen nun angewiesen werden, seltener Daten zu liefern, bzw. das Programm muss Berechnun- gen schneller und ungenauer durchführen. Aspekte der aspektorientierten Spracher- weiterung ANesC sollen nun dafür sorgen, dass Sensordaten exakt an dem Zeitpunkt vorliegen, wo die CPU ihre Aufgabe beendet hat. Dafür muss eine Realtime-Deadline als Pointcut eingewebt werden und dem Aspekt muss Zugriff auf die entsprechenden Parameter gegeben werden, damit dieser diese verändern kann.

Anzumerken ist, dass gerade aus Laufzeitgründen innerhalb von TinyOS auf einen Task-Scheduler verzichtet worden ist, welcher einzelne Tasks unterbrechen kann. Die- ses Feature muss nun in das System neu hinein implementiert werden. Die Deklaration eines Pointcuts für einen Stack- oder Speicher-Überlauf ist weiter sehr simpel geartet und mit den hochanpassbaren Pointcutdeklarationen anderer aspektorientierter Spra- chen nicht vergleichbar. Gleichzeitig ist aber die Implementierung eines Advices für einen solchen Pointcut schwierig, da der Stack vor jeder Allokation geprüft werden muss, was ja eigentlich aufgrund von Ressourceneinsparungsgründen vermieden wer- den sollte.

In der aspektorientierten Spracherweiterung, welche im Rahmen dieser Diplomarbeit entwickelt wird, wird das Hauptaugenmerk auf andere Joinpoints gelegt. Das Design wird auch keine Realtime-Joinpoints beinhalten, sondern sich mit Joinpoints, welche sich statisch im Programm befinden, beschäftigen. Deshalb können beide Arbeiten als orthogonal zueinander betrachtet werden.

3.2 Logging-Frameworks

3.2.1 Loggingansätze für die PC-Umgebung

Mit der steigenden Komplexität von PC-Software nahmen in den vergangenen Jahren auch die Anforderungen an das Logging zu. Mittlerweile reicht das Benutzen einer einfachen Ausgabe für das Protokollieren von Ereignissen in einem Programm bei weitem nicht mehr aus. Verschiedene Wünsche werden an das Logging gestellt:

- Das Logging soll dem Programmierer erlauben, Loggingnachrichten einer Wich- tigkeitsstufe, dem Loglevel, zuzuordnen. Während beispielsweise eine Anwen- dung erstellt wird, sollen Loggingnachrichten auch auf Debugging-Stufe ausge- geben werden. Wenn sich später dann die Anwendung im Produktionsbetrieb befindet, sollen nur noch fatale Fehler ausgegeben werden. Dazwischen soll es Zwischenstufen geben.
- Zusatzinformationen sollen zu den einzelnen Loggingnachrichten hinzugefügt werden, wie beispielsweise ein Zeitstempel oder die Klasse und der Thread, in welchen diese Logging-Nachricht erzeugt worden ist.
- Für eine Ausgabe der Loggingnachrichten sollen unterschiedliche Formate zur Verfügung stehen. Das einfachste Format ist eine simple Textdatei. Für diese sind jedoch auch Limitierungen wie eine maximale Größe der Loggingdatei oder ein maximales Alter der in ihr abgelegten Loggingnachrichten wünschenswert. Auch kann eine Möglichkeit der Archivierung der Loggingdateien in gepackter Form bei einer bestimmten Größe oder einem bestimmten Alter gewünscht wer- den. Weiterhin können Loggingnachrichten in eine XML-Datei zur Weiterver- arbeitung geschrieben werden. Auch eine Versendung der Loggingnachrichten via Email, SMS oder Instant-Messaging im Produktionsbetrieb kann gewünscht werden.
- Das Logging soll konfigurierbar sein. Dies bedeutet, dass es möglich sein soll, ohne große Schwierigkeiten das Ziel der Ausgabe bzw. die Art der Ausgabe zu ändern.

All diese Anforderungen werden mithilfe von Logging-Frameworks erfüllt. Die- se entstammten zunächst der Java -Welt, hielten aber in viele andere Programmier- sprachen mit der Portierung von Log4J Einzug. Log4J [21, 12, 19] ist die bekannteste Logging-Framework-Implementierung. Neben ihr stehen die Java Logging API [46], Simple Log [37] und diverse andere Implementierungen. Zusätzlich gibt es noch Wrap- per, um Logging-APIs zu kapseln, wie das Jakata Commons Logging [17] und ähnliche. Wrapper um Logging-Frameworks bieten die Funktionalität an, dass der Endanwender - auch wenn die Software schon kompiliert ist - noch konfigurieren kann, welches Logging-Framework benutzt werden soll.

Unterschiedliche Logging-Frameworks unterscheiden sich nicht wesentlich voneinander. Ihre Grundfunktionalität ist stets dieselbe, weshalb hier anhand des Vokabulars von Log4J, dem verbreitetesten Framework, die Funktionalität eines LoggingFrameworks beschrieben wird. Das Framework unterteilt sich in drei Teile: dem Logger, dem Formatter und dem Appender:

- Der Logger ist dafür zuständig, die Loggingnachricht selbst entgegenzunehmen. Weiterhin sammelt er Informationen über die Umgebung des Loggingaufrufes und den genauen Zeitpunkt, an welchem dieser getätigt wurde. Dies tut er, in- dem er von den Programmierer des Quellcodes mit den entsprechenden Parame- tern aufgerufen wird. Zu den Parametern gehören der Loglevel der Nachricht, die Nachricht selbst und, sollte eine Exception zu loggen sein, auch diese. Wei- tere Parameter extrahiert der Logger aus der Laufzeitumgebung.
- Der Formatter formatiert die gesammelten Informationen entsprechend seinen Vorgaben. Dies bedeutet meist, diese in einen textbasierten Ausgabestring umzuwandeln. Allerdings ist auch eine Umwandlung nach XML oder HTML oder in irgendein anderes Format sinnvoll.
- Der Appender schließlich sorgt für die Ausgabe der Loggingnachricht. Beispielsweise kann das Logging sowohl in eine Datei geschehen, als auch direkt am Bildschirm ausgegeben werden. Die Nachrichten können auch an andere Dienste wie beispielsweise an eine Email übergeben werden.

Auch ist es möglich, generierte Loggingdateien nach deren Schreiben oder direkt in ihrer Ausgabe mit einem grafischen Logdateibetrachter anzuzeigen. So wird ein komfortables Betrachten des Verhaltens einer Applikation möglich gemacht. Hier sind spezielle Suchfunktionen verfügbar. Dies kann beispielsweise dann genutzt werden, wenn in einem Produktionsumfeld Fehler in der Applikation aufgetreten sind, die nun korrigiert werden müssen, oder wenn bestimmte kritische Applikationen auf Zuverlässigkeit in Echtzeit überwacht werden sollen.

Das Logging-Framework lässt sich so konfigurieren, dass mehrere Formatter und mehrere Appender an den Strom der Logging-Ereignisse geknüpft werden können. Für jedes Logging-Framework wird meist eine Vielzahl an Formattern und Appendern mit- geliefert.

Logging-Frameworks auf PC-Ebene haben jedoch auch diverse Nachteile. Diese Nachteile wirken sich leider ganz besonders auf die Umgebung der Sensornetze aus:

- Der Loggingcode verbleibt auch im ausgelieferten Programm im Binärcode. Da- durch wird der Programmcode größer, auch wenn dieser Code nicht mehr be- nötigt und niemals aufgerufen wird. Dies ist ein erheblicher Nachteil für eine Sensornetzanwendung, da hier an Speicherplatz auf den Motes gespart werden muss. Deshalb sind normale Loggingansätze aus der PC-Welt nicht direkt auf die Moteumgebung übertragbar. Eine Abhilfe kann hier ein C-Ansatz mit Makros schaffen. Hier werden mit einer entsprechenden Makrokonfiguration während des Kompiliervorgangs die Loggingnachrichten übersprungen, sodass für die- se kein Binärcode vom Compiler erzeugt wird. Ein solcher Ansatz wurde auch schon in der Debuggingumgebung TOSSIM von TinyOS genutzt.
- Bevor Informationen an den Logger übergeben werden, müssen zunächst diese Informationen gesammelt werden. Dies bedeutet unter Umständen, dass diver- se Objekte nach Informationen gefragt werden müssen. Auch müssen Strings konkateniert werden. Dies bedeutet, dass in Java String-Kopien angelegt wer- den müssen. Wird hier nicht auf ein geschicktes Konkatenieren geachtet, kann dies zu einem Performanceproblem werden. Es ist sinnvoll, bevor Loggingnach- richten generiert werden, festzustellen, ob diese Loggingnachricht überhaupt ge- braucht wird, d.h., ob der Loglevel niedrig genug für eine Ausgabe ist. Das Tool Just4log [8] löst dieses Problem für die Java -Welt, indem es in den kompilierten Bytecode vor jedem Loggingstatement prüft, ob dieses Logstatement ausgewer- tet werden muss. Ein Makroansatz kann dieses Problem in der C-Welt lösen, indem entsprechende Prüfungen durch das Makro eingefügt werden.
- Der Loggingcode muss von Hand in den Programmcode eingefügt werden. Oft- mals vergessen Programmierer an wichtigen Stellen entsprechenden Logging- code einzufügen. Zusätzlich macht der Loggingcode das eigentliche System un- übersichtlich. Eine Abhilfe kann hier wiederum mit speziellen Tools beispiels- weise für die Programmiersprache Java geschaffen werden, indem der Logging- code erst in den Bytecode eingefügt wird und somit der Quellcode sauber bleibt. LimpidLog [13] verfolgt den Ansatz, dass Klassen zur Laufzeit registriert wer- den können und alles, was in diesen geschieht, nach ihrer Registrierung geloggt wird. Dieses Logging von allen Methodenaufrufen wird auch als Tracing be- zeichnet. Hierbei fallen sehr viele Loggingdaten an. Dem Programmierer wird jedoch ein intensiver Einblick über den aktuellen Zustand des Systems aus der Sicht einer Klasse gegeben. Der TracingClassLoader [56] ist ähnlich. Es ersetzt den Standard-Classloader der virtuellen Maschine von Java durch einen Tracing- Classloader, welcher entsprechend Tracing-Nachrichten beim Laden in den By- tecode einwebt. Pencil [35] verfolgt den Ansatz, den Loggingcode durch den Programmierer nur teilweise in den Sourcecode einfügen zu lassen. Hier platziert der Programmierer nur einen String, welcher aussagt, was geloggt werden soll. Durch Pencil wird eine Abfrage direkt in den Bytecode eingewebt, welche über- prüft, ob der gewünschte Loglevel einer Loggingnachricht überhaupt aktiviert ist, sodass das Sammeln von Informationen für Loggingnachrichten, die nicht ausgegeben werden, unterbunden werden kann. Dies ist ähnlich zum Ansatz von Just4log. In Pencil ist eine Sprache integriert, welche es einem ermöglicht, die gewünschten Loggingstatements inklusive der Variablen, welche eingewebt werden sollen, zu beschreiben. Unter all den beschriebenen Ansätzen ist Pen- cil der komfortabelste, da es Just4Log einschließt und zusätzlich nicht überall Loggingcode wie der TracingClassLoader generiert. Allerdings bleibt das Log- ging im Quellcode weiterhin eingefügt. Ein allgemeinerer und damit flexiblerer Ansatz zum automatischen Einfügen von Logging-Statements ist der schon in Abschnitt 2.3.2 auf Seite 17 beschriebene. Dieser Ansatz benutzt AspectJ zusam- men mit einem beliebigen Logging-Framework. Loggingcode wird nicht in den Basiscode eingefügt. Gleichzeitig aber bleibt das Logging anpassbar.

3.2.2 Loggingansätze in nesC für die Sensornetzumgebung

Zurzeit bestehen noch keine umfangreichen Loggingansätze für den Einsatz auf Sensormotes, obwohl entsprechende Ansätze in der Praxis erforderlich sind. Es existieren zur Zeit nur Ansätze, wie in Abschnitt 3.1 genannt.

Der Grund liegt darin, dass traditionelle Ansätze aus der PC-Umgebung nichtübernommen werden können und neue Ideen entwickelt und implementiert werden müssen. Zum einen muss an den Ressourcen gespart werden, sodass das Logging nicht nur im Produktionsbetrieb deaktiviert werden muss, sondern ganz aus dem Programm- code entfernt werden muss. Weiterhin existieren für Sensornetze drei unterschiedliche Anwendungszenarien für das Logging: Einmal als Simulation, dann im Testbed und drittens im Deployment des Motes. In der verteilten Umgebung kommen weitere An- forderungen hinzu. Loggingnachrichten können nicht direkt ausgegeben werden, son- dern müssen über das Netz verschickt werden und können erst dann zur Ausgabe ge- bracht werden. Auch muss das Logging gleichzeitig auf unterschiedlichen Netzknoten durchgeführt werden und die Nachrichten entsprechend gekennzeichnet werden. Eine Zeitsynchronisation zwischen den einzelnen Motes ist vonnöten, damit Loggingnach- richten einen Zeitstempel des gesamten Netzes und nicht nur einzelner Motes tragen können. Da weiterhin auch die Übertragungsressourcen des Netzes gering sind, sind Ansätze zur komprimierten Übertragung von Nachrichten gefragt.

Die Diplomarbeit „ Entwurf und Implementierung eines effizienten verteilten Log ging- und Tracing-Frameworks für TinyOS”[18], welche zeitgleich mit dieser Arbeit fertig gestellt sein wird, beschäftigt sich mit dem Versenden von Loggingnachrichten innerhalb eines Sensornetzes.

3.3 Das Weaving unterschiedlicher Implementierungen aspektorientierter Sprachen

3.3.1 Zeitpunkte des Weavings

Eines der frühen Papers über aspektorientierte Programmierung[31] nennt die Zeit- punkte, an denen ein Weaving, das Einfügen der Aspekte in den Programmcode des

Basisprogrammes, geschehen kann. Da sich die grundlegende Arbeitsweise von Implementierungen aspektorientierter Spracherweiterungen nicht geändert hat, sind diese Webzeitpunkte auch heute noch aktuell:

- Vor dem Kompilieren durch einen Precompiler in den Sourcecode,
- während der Kompilierung innerhalb des Compilers auf Strukturen, welche innerhalb des Compilers das Programm repräsentieren,
- nach der Kompilierung durch einen Postprozessor in den Bytecode,
- vor dem Start des Programmes in den Bytecode und
- während der Ausführung des Programmes in den Bytecode.

[...]