Energiebewusste Systeme und Methoden

Transcription

Falko Dressler, Jürgen Kleinöder (Hrsg.)
GI/ITG KuVS Fachgespräche
Energiebewusste Systeme
und Methoden
und
Systemsoftware für
Pervasive Computing
11. - 12. Oktober 2005
Erlangen
Friedrich-Alexander-Universität
Erlangen-Nürnberg
TECHNISCHE FAKULTÄT
INSTITUT FÜR INFORMATIK
ARBEITSBERICHTE DES INSTITUTS FÜR INFORMATIK
Band 38 • Nummer 5 • Oktober 2005
Arbeitsberichte des Instituts für Informatik
Friedrich-Alexander-Universität Erlangen Nürnberg
Band 38 • Nummer 5 • Oktober 2005
Falko Dressler, Jürgen Kleinöder (Hrsg.)
Energiebewusste Systeme und
Methoden
und
Systemsoftware für Pervasive
Computing
11. - 12. Oktober 2005
Erlangen
In Zusammenarbeit mit der
GI/ITG-Fachgruppe KuVS
Herausgeber:
T. Brinda, M. Dal Cin, R. German, G. Görz, G. Greiner,
U. Herzog, F. Hofmann, J. Hornegger, S. Jablonski, K. Leeb,
P. Mertens, K. Meyer-Wegener, H. Müller, H. Niemann,
Ch. Pflaum, M. Philippsen, U. Rüde, F. Saglietti,
H. J. Schneider, W. Schröder-Preikschat, M. Stamminger,
H. Stoyan, J. Teich, R. Wanka, H. Wedekind
Die Reihe der Arbeitsberichte des Instituts für Informatik
(ehem. Institut für Mathematische Maschinen und Datenverarbeitung)
der Universität Erlangen-Nürnberg erscheint seit 1967.
Begründet von Prof. Dr. Dr. h. c. mult. Wolfgang Händler
Universität Erlangen-Nürnberg
Institut für Informatik
Martensstr. 3
91058 Erlangen
Tel.:
Fax:
E-Mail:
WWW:
+49.9131.85.28807
+49.9131.85.28781
info@informatik.uni-erlangen.de
http://www.informatik.uni-erlangen.de/
© Universität Erlangen-Nürnberg, Institut für Informatik 2005
Alle Rechte bleiben vorbehalten.
Nachdruck, auch auszugsweise, nur mit Genehmigung der Herausgeber.
ISSN 1611-4205
Herstellung:
Gruner Druck GmbH
Sonnenstr. 23b, 91058 Erlangen, Tel. (09131) 6170-0
iii
Vorwort
Am 11. und 12. Oktober 2005 fanden in Erlangen die beiden GI/ITG KuVS Fachgespräche
„Energiebewusste Systeme und Methoden“ und „Systemsoftware für Pervasive Computing“
statt. Die fachliche und zeitliche Überschneidung beider Fachgespräche wurde als Anlaß für
eine Zusammenlegung beider Veranstaltungen genutzt und von den Teilnehmern positiv
aufgenommen. Insgesamt 20 Teilnehmer aus Universitäten und Industrie waren angemeldet
und es fanden 9 Präsentationen statt. Dieser Bericht enthält die Beschreibungen dieser
Präsentationen. Die Organisatoren hoffen, daß diese Veranstaltung die Zusammenarbeit und
Qualität der Forschung in den betrachteten Fachgebieten verbessern wird.
Erlangen, Oktober 2005
Falko Dressler und Jürgen Kleinöder
Organisation
Lokale Organisation:
o Falko Dressler und Jürgen Kleinöder
Leitungsgremien:
o Energiebewusste Systeme und Methoden: Falko Dressler (Universität ErlangenNürnberg), Christian Becker (Universität Stuttgart), Frank Bellosa (Universität
Karlsruhe) und Timmermann (Universität Rostock)
o Systemsoftware für Pervasive Computing: Christian Becker (Universität Stuttgart),
Michael Beigl (TeCO, Karlsruhe), Kay Römer (ETH Zürich) und Wolfgang SchröderPreikschat (Universität Erlangen-Nürnberg)
iv
Teilnehmer
Becker
Christian
Uni Stuttgart
christian@drbecker.org
Bellose
Frank
Uni Karlsruhe
bellosa@ira.uka.de
Bichler
Daniel
Infineon
daniel.bichler@infineon.com
Dressler
Falko
Uni Erlangen
dressler@informatik.uni-erlangen.de
Dulz
Winfried
Uni Erlangen
dulz@informatik.uni-erlangen.de
Fuchs
Gerhard
Uni Erlangen
gerhard.fuchs@informatik.uni-erlangen.de
German
Reinhard
Uni Erlangen
german@informatik.uni-erlangen.de
Gutiérrez
Javier
Fraunhofer IIS
gut@iis.fraunhofer.de
Hirth
Thomas
Fraunhofer IIS
hirthts@iis.fraunhofer.de
Kleinöder
Jürgen
Uni Erlangen
jk@cs.fau.de
Kunze
Christian
Uni Hamburg
kunze@informatik.uni-hamburg.de
Lucas
Nestor
Fraunhofer IIS
huc@iis.fraunhofer.de
Marron
Pedro José
Uni Stuttgart
marron@informatik.uni-stuttgart.de
Merkel
Andreas
Uni Karlsruhe
merkela@ira.uka.de
Reinhard
Gotzhein
TU Kaiserslautern
gotzhein@informatik.uni-kl.de
Riedel
Till
TecO Karlsruhe
riedel@teco.edu
Ringwald
Matthias
ETH Zürich
mringwal@inf.ethz.ch
Ritter
Hartmut
Freie Univ. Berlin
hritter@inf.fu-berlin.de
Weis
Torben
Uni Stuttgart
torben.weis@gmail.com
Weißel
Andreas
Uni Erlangen
weissel@informatik.uni-erlangen.de
v
Inhaltsverzeichnis
Fachgespräch Energiebewußte Systeme und Methoden
Quantifying Application Performance for Adaptive Power Management ..................................1
Andreas Weissel (Uni Erlangen) und Frank Bellosa (Uni Karlsruhe)
Verteilung der Leistungsaufnahme in Mehrprozessorsystemen..................................................7
Andreas Merkel und Frank Bellosa (Uni Karlsruhe)
RoBM2: Measurement of Battery Capacity in Mobile Robot Systems ......................................13
Nestor Lucas, Cosmin Codrea, Thomas Hirth, Javier Gutierrez (Fraunhofer IIS)
und Falko Dressler (Uni Erlangen)
Modellierung von Sensornetzen mit variabler Sendeleistung ...................................................19
Hartmut Ritter und Jochen Schiller (FU Berlin)
Fachgespräch Systemsoftware für Pervasive Computing
Rapid Prototyping Kontext-bezogener Anwendungen ..............................................................23
Torben Weis (Uni Stuttgart)
Ubiquitous Resources Abstraction using a File System Interface on Sensor Nodes ................34
Till Riedel und Christian Decker (TecO, Uni Karlsruhe)
Unterstützung mobiler Prozesse im Mobile Computing ...........................................................42
Christian Kunze (Uni Hamburg)
Security and Privacy in Pervasive Computing Environments ..................................................48
Daniel Bichler, Guido Stromberg (Infineon) und Mario Huemer (Uni Erlangen)
Monitoring and Debugging of Deployed Sensor Networks ......................................................56
Matthias Ringwald und Kay Römer (ETH Zürich)
vi
Energiebewusste Systeme und Methoden / Systemsoftware für Pervasive Computing
Quantifying Application Performance for
Adaptive Power Management
Andreas Weissel1 and Frank Bellosa2
1
University of Erlangen, Department of Computer Sciences 4, weissel@cs.fau.de
2
University of Karlsruhe, System Architecture Group, bellosa@ira.uka.de
Abstract. The power consumption of a system can be reduced by setting individual devices to low-power operating modes or reducing the
speed of operation, trading energy savings for degraded performance or
quality-of-service. The minimum performance level which is still acceptable for the user depends on the specific operation or application and
has to be accounted for by power management policies. The operating
system monitors performance- and energy-related events in order to give
energy-aware policies a feedback on the effects of power management settings. The challenge of this approach lies in the automatic quantification
of changes in user-perceived performance.
1
Introduction
Power management is recognized as an important issue for battery-powered devices. Hardware components offer low-power operating modes where parts of the
electronics are switched off or the speed of operation is reduced. As these lowpower modes can affect the performance or usability of applications, there exists
a trade-off between energy savings and performance degradation. We argue that
the performance demands and the corresponding trade-off is application- and
user-specific and has to be accounted for by energy-aware policies.
In order to facilitate the implementation of adaptive power management, information about performance degradation of individual applications, the effects
of power management settings, and correlations and dependencies between the
configuration of different devices is necessary.
The operating system can be understood as a mediator between the hardware
components, as it has control over their power dissipation, and the applications
as the originators of hardware activations. Therefore, the OS is the appropriate
entity to monitor performance- and energy-related events and pass this information to adaptive power management policies.
In the next sections, we discuss metrics for application performance and
characteristics of power management configurations of different devices. Our
implementation and preliminary results are presented in sections 4 and 5.
2
Metrics Reflecting Application Performance
For interactive applications, time can be divided into think time (the user is not
waiting for the system to do something) and wait time (the time it takes the
1
2
system to respond to a user-initiated operation). Our approach is based on the
assumption that the wait time determines the performance experienced by the
user. A metric often used is the perception threshold, under which events appear
to happen instantaneously for the user. While values between 50 and 100 ms are
common, the sensitivity to application responsiveness depends on the individual
user and the application and can not be measured directly.
For periodic, non-interactive applications like multimedia players it is important to provide a certain quality-of-service. If deadlines are missed, audio or
video playback can suffer from skips or lost frames.
In [4], the authors discuss approaches to measure interactive system performance. They arrive at the conclusion that user expectations on the performance
greatly vary with the type of the event.
As a consequence, energy-aware policies need additional, application-specific
information about user expectations. In a previous paper, we demonstrated the
feasibility and benefits of application-specific power management of wireless network communication for portable devices [8]. Based on characteristics of the network traffic (the number and size of network packets received and sent, averages
and deviations and the length and proportion of active and inactive periods),
a reliable classification of the currently running application to one of several
application profiles is performed. The user can specify the preferred power management settings of the network card for these profiles.
To facilitate the implementation of adaptive, application-specific power management, we propose an OS-level infrastructure to quantify changes in userperceived performance and to provide a feedback for energy-aware policies or
applications on the effects of power management configurations.
3
3.1
Characteristics of Power Management Configurations
CPU Frequency/Voltage Scaling
CPUs for portable devices usually support several clock frequencies. Lowering
the clock speed causes a linear reduction in energy consumption but also decreases the number of instructions per time. As there is a linear relation between
frequency and supply voltage and the energy required for a workload is proportional to the square of the supply voltage, Dynamic Voltage Scaling can yield a
quadratic decrease in energy consumption [6].
If the speed of execution is dominated by main memory latency (indicated
by a high number of main memory references), the energy efficiency can be
improved by throttling the clock speed of the processor. In this case, there is
only little impact on application performance as the CPU spends most of its
time waiting for the (much slower) main memory [7].
3.2
IEEE 802.11 Power Management
The IEEE 802.11 standard for wireless networking defines two operating modes:
the default idle mode (or “always-on” mode), which leaves the interface fully
powered, and the power-saving mode, which keeps the interface in a low-power
sleep mode except for short periodic “beacons” to synchronize with the base
station. The length of the beacon period can be set to multiples of 100 ms.
The beacon mechanism not only reduces energy consumption but also has
an impact on the round-trip time of communication over the network interface.
As the network interface is kept in low-power (sleep) mode most of the time, receiving data is only possible after synchronizing with the base station. Incoming
traffic is buffered at the access point and signaled in the “traffic indication map”
sent at each beacon. If data is waiting, the client activates the network interface
and polls the data from the access point. After the transmission, the sleep cycle
is established again. If data is buffered at the access point, the client is not aware
of the incoming data for at most one whole beacon period. Thus, additional network delays with an average value of half of the beacon period are introduced
and user-perceived application performance or quality can be affected.
There is a high variation of the effects of wireless network power management
on user-perceived performance depending on the currently running application.
As Anand et al. [1] demonstrate, power management can dramatically increase
the execution time and, as a consequence, the energy consumption of NFS operations. For each file operation, one or more RPCs are issued. The reason for the
slow-down is that only one RPC gets completed during each beacon interval. In
our experiments, we found a beacon period of 100 ms still tolerable for browsing
the web or working over SSH. Playback of audio or video streams works well
with even the highest beacon period as a large amount of data is buffered by the
player.
4
Implementation
We modified a Linux kernel 2.4.19 from www.handhelds.org for the Compaq
iPAQ 3900 series (ARM architecture) to monitor resource consumption and collect information about performance degradation.
To account this information to the task or activity responsible for it, we
apply the abstraction of Resource Containers [3]. While processes and threads
are understood as schedulable entities (and protection domains), for several reasons they not adequately represent resource principals. Dependencies between
processes, e.g. two tasks in a producer-consumer relation, are not correctly considered and the resource consumption of the operating system, e.g. the reception
of network packets, is usually not accounted for. Resource Containers address
these issues by grouping processes according to parent-child and client-server
relationships and account resource consumption also on kernel level.
To measure performance degradation, information on delays is collected for
different power management settings. Wait times are determined by observing
changes to the run-queue of the scheduler. We treat idle times of more than
250 ms as think time. I/O operations which cause the corresponding process to
wait on a resource are also treated as wait time. For instance, we modified the
kernel functions tcp sendmsg() and tcp recvmsg() to record the time between
3
4
sending a packet and receiving the answer for each connection and account this
information to the appropriate resource container.
We are currently extending the infrastructure to account the energy consumption of the two resources CPU and the network interface. The energy consumption of the processor can be determined using information from event counters.
The cpufreq module and the driver for the network card are modified to account
the overhead of switching to another processor frequency or (de)activating IEEE
802.11 power management.
5
Preliminary Results
We tested our modified kernel on an iPAQ 3970 with an Intel PXA 250 CPU
featuring frequency scaling and an expansion pack equipped with a Cisco Aironet
wireless network interface card and an Hitachi Microdrive hard disk. The Intel
XScale architecture supports a number of different clock speeds. In our tests, we
used the two settings 200 and 400 MHz. The wireless network interface was set
to “always-on” or to low-power mode with 100 ms beacons.
As an example for performance-related information, we measured the time it
takes for the web browser dillo to load and display a small HTML page under
different power management configurations. The page contains one image, so two
HTTP requests are necessary. Table 1 shows the average wait times over several
configurations. We can learn from the data that there is only little difference
in wait times across different CPU speeds: the slowdown is less than 5 % when
switching from 400 to 200 MHz. The browser spends most of the time waiting
for data to receive. As a consequence, CPU power management can reduce the
clock speed without degrading application performance. However, with network
power management, there is a significant increase in wait time (more than 40 %).
CPU
speed
200 MHz
400 MHz
802.11 power management
always-on 100 ms beacons
573 ms
553 ms
820 ms
778 ms
Table 1. Wait times of the web browser dillo
Next, we measured the wait time for single keystrokes of an SSH session under
different power management configurations. Again, the wait time is dominated
by the round-trip time of network communication; the impact of lowering the
CPU frequency is negligible. Average wait times are 7 ms for “always-on” and
64 ms for beacon mode.
Finally, we analyzed the resource usage of different multimedia players. We
measured an interval of 780 ms between periodic network transmissions for vlc
and over 3 s for mpg321 playing mp3 files, with deviations of just a few milliseconds. As a consequence, even a large beacon interval of 500 ms has no impact
on the timeliness of receiving stream data.
6
Related Work
There are only few research projects that explicitly consider application performance in the context of power management of multiple devices.
In [2], the authors present an approach to adaptive power management of
multiple I/O devices (a wireless network interface and a hard disk). The OS
exports the current device power mode. Adaptive applications can use this information to choose an appropriate strategy for reading and writing data. In addition to that applications can give so called “ghost hints” to inform power management policies about insufficient power modes supporting a proactive power
management. As an example, a cache manager for an iPAQ handheld is presented. Depending on the power modes of the devices, applications access the
cache on disk or transfer data over the network interface. One drawback of this
approach is the need for applications to be rewritten (to be made adaptive), in
order to issue ghost hints and to react to insufficient power modes.
In [5], a mechanism is presented to automatically classify CPU utilization into
different types of episodes (interactive, producer and consumer) and assigning
deadlines to them. To derive deadlines and classification information the operating systems observes communication between tasks. The X server is modified
to get timing information on user-initiated events.
One approach to implement system-wide power management by unifying resource management policies across different device components is ECOSystem
[9]. With ECOSystem, it is possible to monitor the energy consumed by individual applications for each device. The authors demonstrate how to minimize the
residual energy if a target battery lifetime is defined, achieve proportional energy
use, coordinate scheduling of multiple devices and to minimize the variance in
response time using ECOSystem.
7
Conclusion
Low-power operating modes or devices with different speeds of operation achieve
energy savings at the cost of reduced application performance. The level of performance degradation a user is willing to tolerate depends on the application
and the expectations of the individual user.
As a consequence, policies for power management have to be aware about
user- and application-specific performance demands. The operating system can
provide on-line information on adequate metrics reflecting application performance and resource consumption.
This way, energy-aware policies obtain a feedback on the impact of power
management configurations in order to adapt their decisions according to the
characteristics of the currently active applications.
5
6
References
1. Manish Anand, Edmumd B. Nightingale, and Jason Flinn. Self-tuning wireless network power management. In Proceedings of the 9th Annual International Conference
on Mobile Computing and Networking MobiCom ’03, September 2003.
2. Manish Anand, Edmund B. Nightingale, and Jason Flinn. Ghosts in the machine:
Interfaces for better power management. In Proceedings of the International Conference on Mobile Systems, Applications, and Services MobiSys ’04, June 2004.
3. Gaurav Banga, Peter Druschel, and Jeffrey Mogul. Resource containers: A new
facility for resource management in server systems. In Proceedings of the Third
Symposium on Operating System Design and Implementation OSDI ’99, February
1999.
4. Yasuhiro Endo, Zheng Wang, J. Bradley Chen, and Margo Seltzer. Using latency
to evaluate interactive system performance. In Proceedings of the Second USENIX
Symposium on Operating Systems Design and Implementation OSDI ’96, October
1996.
5. Krisztián Flautner, Steven Reinhardt, and Trevor Mudge. Automatic performance
setting for dynamic voltage scaling. In 7th Annual International Conference On
Mobile Computing and Networking MobiCom ’01, July 2001.
6. M. Weiser, B. Welch, A. Demers, and S. Shenker. Scheduling for reduced cpu
energy. In Proceedings of the First Symposium on Operating System Design and
Implementation OSDI ’94, November 1994.
7. Andreas Weissel and Frank Bellosa. Process cruise control: Event-driven clock scaling for dynamic power management. In Proceedings of the International Conference
on Compilers, Architecture, and Synthesis for Embedded Systems CASES ’02, October 2002.
8. Andreas Weissel, Matthias Faerber, and Frank Bellosa. Application characterization for wireless network power management. In Proceedings of the International
Conference on Architecture of Computing Systems ARCS ’04, January 2004.
9. Heng Zeng, Xiaobo Fan, Carla Ellis, Alvin Lebeck, and Amin Vahdat. Ecosystem: Managing energy as a first class operating system resource. In Proceedings
of the Tenth International Conference on Architectural Support for Programming
Languages and Operating Systems ASPLOS ’02, October 2002.
Verteilung der Leistungsaufnahme in
Mehrprozessorsystemen
Andreas Merkel und Frank Bellosa
Universität Karlsruhe
Fakultät für Informatik
Lehrstuhl Systemarchitektur
76128 Karlsruhe
{merkela, bellosa}@ira.uka.de
Zusammenfassung Das Drosseln von Prozessoren zum Vermeiden des
Überhitzens reduziert die Systemleistung. In Mehrprozessorsystemen bietet sich die Alternative an, heiße“ Tasks auf kühlere Prozessoren zu mi”
grieren, sowie heiße“ und kühle“ Tasks gleichmäßig auf die Prozessoren
”
”
zu verteilen. Unser Ansatz erweitert das Betriebssystem um Komponenten zur Bestimmung der Energiecharakteristik einzelner Tasks, sowie um
einen energiegewahren Scheduler, dessen Ziel es ist, die Leistungsaufnahme der Prozessoren auszugleichen, so dass ein Überhitzen einzelner
Prozessoren zu vermieden wird. Unsere Experimente mit einer Linux–
Implementierung zeigen, dass energiegewahres Scheduling für viele Anwendungszenarien den Systemdurchsatz steigert.
1
Einführung
Mit der steigenden Leistungsaufnahme heutiger Mikroprozessoren ist Wärme zu
einem Problem geworden. Kühlsysteme sind häufig nicht mehr auf die theoretische Maximalleistung des Prozessors ausgelegt, sondern auf eine moderatere
Thermal Design Power“ (TDP). Überschreitet ein Prozessor diese TDP länger”
fristig, droht er zu überhitzen und muss gedrosselt werden, was sich negativ auf
die Systemleistung auswirkt. Jedoch verursachen längst nicht alle Tasks solch
eine hohe Leistungsaufnahme. Die Leistungsaufnahme moderner Mikroprozessoren hängt stark von den ausgeführten Instruktionen und daher von der gerade
laufenden Task ab [1,2]. Heiße Tasks verursachen eine hohe Leistungsaufnahme
und daher hohe Prozessortemperaturen, während die Leistungsaufnahme kühler
Tasks geringer ausfällt, was in einer niedrigeren Prozessortemperatur resultiert.
In einem Mehrprozessorsystem kann der Energieverbrauch der einzelnen Prozessoren daher zu einem gewissen Grad durch eine gezielte Zuordnung von Tasks
zu Prozessoren gesteuert werden. Im Betriebssystem ist der Scheduler dafür
zuständig, den Prozessoren Tasks zuzuweisen. Um unter Berücksichtigung der
beschränkten Fähigkeit der Prozessoren, Wärme abzuführen, eine optimale Systemleistung zu erzielen, muss der Scheduler daher um die Energiecharakteristika
der einzelnen Tasks wissen; er muss energiegewahr sein. Zwei Voraussetzungen
7
8
sind hierfür wesentlich: erstens ein Mechanismus zur Bestimmung der Energiecharakteristika einzelner Tasks und zweitens, darauf aufbauend, eine energiegewahre Schedulingstrategie.
Die in heutigen Prozessoren vorhandenen Ereigniszähler können dazu verwendet werden, den Energieverbrauch des Prozessors abzuschätzen [1]. Wir verwenden diese Zähler, um Energieprofile für die Tasks zu erstellen, die deren
Energieverbrauch beschreiben. Unter Verwendung dieser Profile verfolgen wir
eine energiegewahre Schedulingstrategie mit dem Ziel, die Leistungsaufnahme
aller Prozessoren auszugleichen, um ein Überhitzen einzelner Prozessoren zu
vermeiden.
Dieses Dokument ist weiter wie folgt strukturiert: Abschnitt 2 behandelt verwandte Arbeiten. In Abschnitt 3 stellen wir unseren Mechanismus zur Bestimmung der Energiecharakteristik einzelner Tasks vor. Abschnitt 4 erläutert unsere
energiegewahre Schedulingstrategie. Abschnitt 5 beschreibt Auswertungen unserer Linux–Implementierung des energiegewahren Scheduling unter verschiedenen
Anwendungszenarien. Abschnitt 6 schließlich fasst unsere Ergebnisse zusammen.
2
Verwandte Arbeiten
Ein energiegewahrer Scheduler berücksichtigt die Energiecharakteristika der einzelnen Tasks bei seinen Schedulingentscheidungen. Bisher konzentrieren sich die
Arbeiten zum energiegewahren Scheduling auf Einprozessorsysteme.
Wenn das Betriebssystem darüber informiert ist, welche Tasks für ein Ansteigen der Prozessortemperatur verantwortlich sind, kann es diese Tasks gezielt
drosseln, anstatt durch generelles Drosseln alle Tasks zu bestrafen [3]. Der Scheduler erkennt solche Tasks durch ihre hohe CPU–Aktivität und drosselt sie durch
Ausführen des hlt–Befehls. Wir sind der Ansicht, dass in Mehrprozessorsystemen das Migrieren heißer“ Tasks dem Drosseln vorzuziehen ist. Zudem ist die
”
CPU–Aktivität auf modernen Prozessoren kein ausreichender Indikator mehr für
den Energieverbrauch.
Mit Hilfe von Resourcencontainern [4] kann Energie in verteilten Systemen
verwaltet werden [5]. Jeder Task wird ein Energiecontainer zugeordnet und nur
Tasks mit nichtleeren Energiecontainern dürfen vom Scheduler ausgewählt werden. Da unser Ansatz sich nicht mit der Frage beschäftigt, welche Tasks laufen
dürfen, sondern wo die Tasks laufen dürfen, sind beide Ansätze zueinander kompatibel.
Ein hardwarenäherer Ansatz besteht darin, redundante Ressourcen auf dem
Chip zu halten und bei Temperaturüberschreitungen die Rechenaktivität zu diesen Ressourcen hin zu verlagern [6,7]. Unser Ansatz ist grobkörniger und verlagert Rechenaktivität nicht innerhalb des Chips, sondern auf andere Chips.
Ein anderer, ebenfalls auf Hardwareebene arbeitender Ansatz modifiziert die
Fetch–Policy eines simultan mehrfädigen Prozessors [8]. Anstelle einzelner Tasks,
wie in unserem Ansatz, werden dort die einzelnen Hardwarethreads nach ihrem
Energieverhalten charakterisiert und abhängig von den Temperaturen der einzel-
nen Funktionseinheiten auf dem Chip die Threads bevorzugt, die hauptsächlich
kühle Ressourcen benutzen.
3
Bestimmung der Energiecharakteristika
Zur Bestimmung der Energiecharakteristika einzelner Tasks verwenden wir eine
Energieabschätzung mittels Ereigniszählern [1]. Diese Zähler zählen prozessorinterne Ereignisse. Da diese Ereignisse mit Chip–Aktivität korrelieren, kann jedem
Ereignis ein bestimmter Energiebetrag zugewiesen werden. Durch Gewichten der
Zählerwerte mit Energiebeträgen kann so der Energieverbrauch des Prozessors
bestimmt werden. Die Gewichte können durch Messen des tatsächlichen Energieverbrauchs, z.B. mit einem Multimeter, kalibriert werden.
Unter Verwendung dieser Energieabschätzung erstellen wir ein Energieprofil für jede Task. Dieses Profil beschreibt, wie viel Energie die jeweilige Task
während einer Zeitscheibe verbraucht. Wir berechnen das Energieprofil einer
Task als exponentiellen Durchschnitt des Energieverbrauchs der vergangenen
Zeitscheiben. So passt sich das Energieprofil an, falls sich die Energiecharakteristik einer Task ändert, schwankt jedoch nicht zu abrupt, so dass übereilte
Migrationen vermieden werden.
4
Energiegewahres Scheduling
Ziel des energiegewahren Schedulings ist es, das Überhitzen bzw. das Drosseln einzelner Prozessoren zu vermeiden. Wir verfolgen dazu zwei Strategien,
abhängig von der Anzahl der Tasks im System.
4.1
Energieausgleich
Falls so viele Tasks im System vorhanden sind, dass mehrere Tasks auf einem
Prozessor laufen, kombinieren wir die Tasks so auf den Prozessoren, dass deren Leistungsaufnahme ausgeglichen ist. Auf diese Weise verhindern wir, dass
einzelne Prozessoren aufgrund ihrer zu hohen Leistungsaufnahme überhitzen.
Für den Energieausgleich ziehen wir zwei Maßzahlen heran: Zum einen verwenden wir den Durchschnitt der Energieprofile aller einem Prozessor zugeordneten Tasks, zum anderen berechnen wir einen prozessorspezifischen exponentiellen Durchschnitt des Energieverbrauchs , ähnlich den Task–Energieprofilen,
aber unter Berücksichtigung des Energieverbrauchs aller Tasks, die auf einem
Prozessor laufen. Wir migrieren eine heiße Task von Prozessor A zu Prozessor
B, falls beide Maßzahlen von A größer sind als die von B. Da sich der exponentielle Durchschnitt nur langsam ändert, erzielen wir so eine Hysterese und
vermeiden Ping–Pong–Effekte.
9
10
4.2
Migration heißer Tasks
Für Prozessoren, welche lediglich eine Task ausführen, so dass ein Kombinieren
verschiedener Tasks nicht möglich ist, verfolgen wir eine andere Strategie. Wir
lassen eine heiße“ Task so lange auf einem Prozessor laufen, bis der Prozessor
”
das Temperaturlimit erreicht, ab dem die Drosselung einsetzten würde. Dann
migrieren wir die Task auf einen kühleren Prozessor, wo sie ungedrosselt weiter
laufen kann. Falls auf dem kühlen Prozessor vorher eine kühle“ Task lief, mi”
grieren wir diese im Austausch auf den heißen Prozessor, andernfalls bleibt der
Prozessor im Leerlauf.
5
Auswertung
Wir integrierten den Mechanismus zur Energieabschätzung und zur Bestimmung
der Energieprofile, sowie die beiden oben beschriebenen energiegewahren Schedulingstrategien in den Linux–Kern. Wir führten damit eine Reihe von Auswertungen auf einem achtfach Pentium 4 Xeon Mehrprozessorsystem mit 2,2GHz
pro Prozessor unter Verwendung verschiedener Anwendungszenarien durch. Wegen der auf hohe Anforderungen ausgelegten Kühlung ist in dem System auch
ohne energiegewahres Scheduling kein Drosseln erforderlich. Deswegen legten wir
für unsere Auswertungen ein künstliches Temperaturlimit von 38 fest.
Für ein Szenario bestehend aus 18 Tasks mit Leistungsaufnahmen im Bereich
von 38W bis 61W müssen die Prozessoren ohne energiegewahres Scheduling im
Durchschnitt 15,2% der Zeit gedrosselt werden, um das Temperaturlimit einzuhalten. Mit energiegewahrem Scheduling sinkt dieser Prozentsatz auf 10,2%.
Dem entspricht eine Erhöhung des Durchsatzes um 4,7%, gemessen an der Zahl
der pro Zeiteinheit zu Ende ausgeführten Tasks.
Der Nutzen des energiegewahren Scheduling hängt davon ab, wie unterschiedlich die Energiecharakteristika der einzelnen Tasks sind. Für Szenarien, bei denen alle Tasks die gleiche Leistungsaufnahme aufweisen, bringt energiegewahres
Scheduling keinen Nutzen, da die Leistungsaufnahme der Prozessoren in diesem
Fall ohnehin ausgeglichen ist. Dagegen konnten wir für ein Szenario bestehen
aus jeweils 9 Tasks mit einem Energieverbrauch von 38W und 61W mit einer
Erhöhung des Durchsatzes um 11,7% einen wesentlich größeren Nutzen feststellen als bei dem oben beschriebenen gemischten Szenario.
Den größten Nutzen hat energiegewahres Scheduling jedoch, wenn nicht alle
Prozessoren des Systems ausgelastet sind und daher die Migration heißer Tasks
anwendbar ist. Falls eine heiße Task stets auf einen kühlen Prozessor migriert
werden kann, ist es möglich, komplett auf Drosselung zu verzichten. In unserem
Achtprozessorsystem erhöhte sich der Durchsatz für ein Szenario mit lediglich
einer heißen“ Task um 76%. Je mehr Tasks im System vorhanden sind, de”
sto unwahrscheinlicher wird es, dass ein geeigneter kühler Zielprozessor für eine
Migration vorhanden ist, da die Prozessoren eine gewisse Zeit brauchen, um
abzukühlen. Daher sinkt der Nutzen des energiegewahren Scheduling mit der
Anzahl der Tasks. Für ein Szenario mit acht heißen Tasks ist schließlich kein

Nutzen mehr feststellbar, da hier bald alle Prozessoren heiß sind und gedrosselt
werden müssen.
6
Ergebnisse
In unserer Arbeit haben wir gezeigt, dass es möglich ist, einzelne Tasks durch ihre
Leistungsaufnahme zu charakterisieren und unter Verwendung dieser Charakterisierung durch Schedulingentscheidungen positiv auf die Verteilung des Energieverbrauchs der Prozessoren eines Mehrprozessorsystems einzuwirken. Dadurch
kann ein Überhitzen bzw. Drosseln einzelner Prozessoren vermieden werden, was
zu einer Erhöhung des Systemdurchsatzes führt. Die beiden Hauptbeiträge unserer Arbeit sind daher die Task–Energieprofile als Mittel zur Charakterisierung
einzelner Tasks durch ihre Leistungsaufnahme, sowie das energiegewahre Scheduling zum Ausgleich des Energieverbrauchs der Prozessoren.
Die größte Einschränkung des energiegewahren Scheduling besteht darin,
dass es nur Nutzen bringt, falls Tasks mit unterschiedlicher Leistungsaufnahme vorhanden sind. Da Wärme jedoch in den einzelnen funktionalen Einheiten
des Chips abgegeben wird, können sich selbst Tasks mit gleicher Leistungsaufnahme durch den Ort unterscheiden, an dem sie elektrische Energie in Wärme
umsetzen. Für zukünftige Arbeiten wäre es daher lohnenswert, eine feinergranulare Charakterisierung der Tasks zu untersuchen. So könnte energiegewahres
Scheduling auch auf die Temperaturverteilung innerhalb der Chips einwirken
und die Entstehung von Hot Spots“, besonders heißen Stellen auf einem Chip,
”
vermeiden.
Literatur
1. Bellosa, F., Weissel, A., Waitz, M., Kellner, S.: Event–driven energy accounting for
dynamic thermal management. In: Proceedings of the Workshop on Compilers and
Operating Systems for Low Power (COLP’03). (2003)
2. Isci, C., Martonosi, M.: Runtime power monitoring in high–end processors: Methodology and empirical data. In: Proceedings of the 36th Annual ACM/IEEE
International Symposium on Microarchitecture. (2003)
3. Rohou, E., Smith, M.D.: Dynamically managing processor temperature and power.
In: Proceedings of the 2nd Workshop on Feedback–Directed Optimization. (1999)
4. Banga, G., Druschel, P., Mogul, J.: Resource containers: A new facility for resource management in server systems. In: Proceedings of the Third Symposium on
Operating System Design and Implementation (OSDI’99). (1999)
5. Weissel, A., Bellosa, F.: Dynamic thermal management for distributed systems.
In: Proceedings of the First Workshop on Temperature–Aware Computer Systems
(TACS’04). (2004)
6. Heo, S., Barr, K., Asanovi, K.: Reducing power density through activity migration.
In: Proceedings of the International Symposium on Low Power Electronics and
Design (ISPLED’03). (2003)
7. Skadron, K., Stan, M.R., Huang, W., Velusamy, S., Sankaranarayanan, K., Tarjan,
D.: Temperature–aware microarchitecture. In: Proceedings of the 30th International
Symposium on Computer Architecture (ISCA’03). (2003)
11
12
8. Donald, J., Martonosi, M.: Leveraging simultaneous multithreading for adaptive
thermal control. In: Proceedings of the Second Workshop on Temperature Aware
Computer Systems (TACS’05). (2005)
RoBM2 : Measurement of Battery Capacity in
Mobile Robot Systems
Nestor Lucas1 , Cosmin Codrea1 , Thomas Hirth1 , Javier Gutierrez1 , and Falko
Dressler2
1
2
Fraunhofer IIS
Am Wolfsmantel 33, 91058 Erlangen, Germany
{luc,codreacn,hirthts,gut}@iis.fraunhofer.de
Dept. of Computer Science 7, University of Erlangen-Nuremberg
Martensstr. 3, 91058 Erlangen, Germany
dressler@informatik.uni-erlangen.de
Abstract. With battery driven robot systems performing very sophisticated tasks, increasing demands on the power supply play a critical role.
Operation breakdowns are unpredictable unless the state of the battery
is known, and the overall performance should be adjusted according to
reliable remaining capacity estimations.
This paper addresses many of the issues related to the management and
monitoring of battery packs for mobile robots, whereas an implementation for a particular system is presented.
1
Introduction
Modern robots increase in complexity as new applications, e.g. cameras or navigation modules, are added to the system. These enhancements pose demanding
operation conditions on the battery, emphasizing the importance of this component. Usually batteries represent an unpredictable source of power, whereas
little or no knowledge about their characteristics or state is available. Methodologies to perform estimates of the remaining capacity may not be implemented.
Equipment powered by the battery cannot determine if the battery, in its given
state, is capable of supplying adequate power for an additional load. Even worse,
the batteries may not be used correctly, e.g. due to wrong charging procedures
or inadequate storage conditions at too high temperatures, what may result in
damage or reduced performance. Under these suboptimal conditions it is often
not possible to ensure the proper operation of the robot, this being unacceptable
for security-critical applications.
An intelligent interface between the battery pack and the supplied mobile
robot is introduced here. Previous work on battery management and monitoring
solutions for portable communication devices [1] helps to develop hardware and
algorithms able to cope with the challenges of high-power consumption robots.
A Robertino robot [2] is upgraded with a dedicated Robot Battery Management
and Monitoring module (RoBM2 ), and serves as a flexible framework to test and
develop new routines that provide the robot with reliable remaining capacity
estimates and extend battery life.
13
14
2
The Smart Battery System (SBS) Reference Model
The Smart Battery System (SBS) [3] contains multiple specifications detailing
a complete power system for portable devices. Guidelines are provided for developing compliant products, that share a common interface (the SMBus) and a
set of commands as defined by the Smart Battery Data (SBData) specification.
The System Management bus [4], a specific implementation of a Philips I2 C-bus,
is a two-wire bus used to transport data between low-speed devices. It describes
protocols, device addresses and additional electrical requirements for the SBS.
The following components should always be present:
– Smart Battery: A battery equipped with specialised hardware that provides
present state, calculated and predicted information to the SMBus Host.
– Smart Battery Charger: A battery charger that periodically communicates
with the Smart Battery and adjusts the charging profile in response to the
actual requirements (charging current and charging voltage).
– SMBus Host: A device powered by a Smart Battery. It receives information
about the battery’s present state and capabilities. The SMBus Host will also
receive alarms from the Smart Battery when it detects a problem.
2.1
Limitations and Alternatives
An intelligent power supply as specified by the SBS has many advantages, since
reliable energy and accurate information are available. The major difficulty in
implementing the SBS reference model relies on the fact, that Smart Batteries are
rarely available and the given robot system has to deal with standard battery
packs that offer no information about their status. A Smart Battery System
architecture as proposed in Fig. 1(a) is not feasible in this case.
Fortunately, this drawback does not discard this reference model as an option for standard batteries. The SBS specification itself gives a hint to overcome
this obstacle: ”The electronics need not be inside the Smart Battery if the battery is not removable from the device”. This statement enables the adoption of
the architecture shown in Fig. 1(b). The Smart Battery can be replaced by a
standard battery, if reliable environment measurements (sensors), battery models (stored in a nonvolatile memory) and intelligence (software running on a
microcontroller) are added to the power supply system. These subblocks should
be attached to the SMBus to perform a transparent replacement of the Smart
Battery.
SMBus Hosts are not always available. The microcontroller shown in Fig. 1(b)
implements the intelligence of the proposed battery management and monitoring
system, and can also communicate with the host over a serial interface (in this
case a RS232), building a bridge between the robot-processor and the SMBus.
With this latter step, the SBS specifications are feasible for any battery pack.
15
Host
Smart
Charger
SMBus
Host
Smart
Battery
Standard
Battery
uC
Sensors
EEPROM
SMBus
Interface
SMBus
Interface
SMBus
Interface
Smart
Charger
SMBus
SMBus
(a)
(b)
Fig. 1. (a) Smart Battery System specification. (b) Alternative architecture supporting
standard batteries.
3
RoBM2 Board
It is common to find robots that adopt lead-acid batteries as their power supply.
Despite the low power-density of these cells, they are appreciated due to their
price and robustness. Charging electronics are usually simplified for this chemistry, whereas system complexity is reduced to a minimum at the cost of battery
life and reliability. The work introduced here has improved this scenario with the
implementation of battery management and monitoring resources in compliance
with the SBS guidelines, relying on a Smart Battery Charger and an ATmega16
microcontroller [5].
The RoBM2 board is a flexible platform for the implementation of batterytailored supervision policies, even in the absence of smart power supplies. It
has been conceived to handle batteries (max. 2 packs in series) that match the
requirements of the Robertino platform, ranging from lead-acid, Ni-based to
Li-based chemistries.
All the tasks undertaken by this board can be separated into two major
categories that are explained in more detail in the following subsections.
3.1
Battery Management
A Smart Battery Charger and the battery management software running on the
microcontroller are responsible for an intelligent battery charging procedure.
The Level 2 Smart Battery Charger is a charging circuit that provides the
battery with charging current and charging voltage to match the battery requirements in the presence of an external power supply. This charger must understand
the characteristics of the battery it is charging. The battery management software reads battery charging models from the system EEPROM and programs
the proper charging profile, as a function of the battery chemistry and the full
16
capacity of the battery pack [6]. End-of-charge is determined by various methods
depending on the specific chemistry and environmental conditions.
The RoBM2 is even able to perform pulse-charging besides the more common
galvanostatic charging. The pulse-charge method can reduce long-term damages
of the battery as gas and heat generation are minimised.
3.2
Battery Monitoring
Battery monitoring deals with remaining capacity estimations and the communication with the host over the RS232 interface.
The battery State-of-Charge (SOC) [7] is calculated basically taking into account the difference between the charging and discharging currents (CoulombCounter method). Measurements of voltage, temperature, charging and discharging currents (see Table 1) are made in a continuous loop by a multi-channel
Analog-to-Digital Converter (ADC). The battery monitoring software collects
data from the ADC and battery models from the EEPROM.
Voltage measurements are a good parameter to determine the SOC when no
load is applied, since Open-Circuit-Voltage (OCV) and SOC are correlated [8]
and manufacturer independent, but this is unfortunately not true under load.
The impedance of the battery distorts the voltage measurements during power
consumption and this is why SOC calculations should not rely on those only.
Nevertheless, voltage can be an indicator to know if we are close to the cut-off
point, and the OCV should be employed in combination with Coulomb-Counter
methods to perform accurate remaining capacity estimations.
There are other pieces of information that are as important as the SOC.
Alarms are generated in case critical situations are detected, e.g. damaged batteries, external supply is available or SOC is below a predefined threshold. These
are sent to the host using the serial interface.
Table 1. Measured parameters used by the battery management and monitoring software at the RoBM2 board.
Measurement
Purpose
Battery Voltage
Battery Management
Pack1 Voltage
Battery Monitoring
Pack2 Voltage
Battery Monitoring
Open Circuit Voltage Battery Monitoring
Temperature
Battery Monitoring
Discharge Current
Battery Monitoring
Charge Current
Batt. Man. and Mon.
4
Integration in the Robertino platform
The Robertino platform is the result of a collaboration project, between the
Fraunhofer AIS in Sankt Augustin and the Chair of Computer Science No. VI
at the Technical University of Munich. Briefly, the Robertino platform consists of
a standard industrial PC (PC104) with a Debian GNU/Linux operating system
and an internal communication CAN-Bus.
Figure 2 depicts the PC104 stack, where the main functions are implemented.
In this work the so-called Connector board was replaced with the new smart
RoBM2 board. The original board is only responsible for connecting the battery
packs to the main board and possesses an interruptor for main on/off switching
purposes.
Fig. 2. The RoBM2 board replaces the Connector Board [2] in the PC104 stack.
The new smart RoBM2 has been designed to match the PC104 card size and
accommodates two new connectors for uploading software updates and debugging purposes, as well as the additional RS232 connector for the serial interface.
Thus has been achieved a compact design, which makes it possible to replace
the board in a smart and quickly manner.
5
Conclusions and Future Work
In this paper we have introduced an architecture for battery management and
monitoring systems relying on the Smart Battery System specifications. The
RoBM2 board is a practical implementation of this open standard, and serves as
a universal platform to develop supervision algorithms for any battery chemistry.
This board has been conceived to be part of a Robertino robot, providing the
host periodically with accurate information about the state of the power supply.
17
18
Future work will focus on the development of optimised algorithms for battery
management and monitoring on base of the Robertino platform.
References
1. Spies, P.: Battery Management and Monitoring Module. [Online]. Available:
http://www.iis.fraunhofer.de/ec/power/battery management.pdf (2004)
2. OpenRobertino web site. http://www.openrobertino.org
3. Smart Battery System Implementers Forum web site. http://sbs-forum.org
4. System Management Bus web site. http://smbus.org
5. ATmega16 8-bit RISC Microcontroller web site. http://www.atmel.com
6. Nguyen, T., Bushnell, L.: Advanced Battery Charging Techniques: Pulse-Charging
in Large-Scale Applications - Design of Divide and Conquer Technique for HighCapacity Batteries. UWEE Technical Report Series, Seattle, USA (2003)
7. Microchip Technology Inc.: Optimizing Available Capacity with Smart Battery Algorithms. 11. Entwicklerforum Batterien, Ladekonzepte & Stromversorgungsdesign,
Design&Elektronik, Munich (2004) 33-40
8. Barsukov, Y.: Challenges and solutions in battery fuel gauging. [Online]. Available:
http://focus.ti.com/lit/ml/slyp086/slyp086.pdf
Modellierung von Sensornetzen mit variabler
Sendeleistung
H. Ritter, J. Schiller
Freie Universität Berlin
Takustr. 9
14195 Berlin
Tel.: +49 (0) 30 838 75124, Fax: +49 (0) 30 838 75194
hritter|schiller@inf.fu-berlin.de
1 Energieproblematik
In der Regel verfügen Sensorknoten nur über eine beschränkte Energieressource
(z.B. eine Batterie), so dass sowohl Hardware (Sensoren, Prozessoren,
Kommunikationstechnik)
als
auch
Software
(Betriebssystem,
Kommunikationsprotokolle) hinsichtlich ihres Energieverbrauches optimiert werden
müssen. Ein großes Forschungsgebiet bezüglich des sparsamen Umgangs mit Energie
ist der Bereich der Routingalgorithmen. Die Aufgabe, für Daten Routingpfade zu
finden und aufrecht zu erhalten, ist in Sensornetzen nicht trivial, da den einzelnen
Sensorknoten nur begrenzt Energie zur Verfügung steht, und Ausfälle von Sensoren
zu häufigen und unvorhersagbaren Wechseln in der Netzwerktopologie führen.
2 Lebensdauer eines Sensornetzes
In der Regel werden Sensorknoten in einem Netzwerk nur über eine begrenzte
Energieressource verfügen, die nicht erneuerbar sein wird 1 . Aufgrund dieser
Ressourcenknappheit bei den einzelnen Sensorknoten ist die Lebenszeit des gesamten
Sensornetzes von vornherein beschränkt. Dabei wird folgende Definition verwendet:
Die Lebensdauer eines Netzwerkes ist definiert als die Zeitspanne, die gemessen
wird von Beginn der Netzwerkaktivitäten bis zum ersten Ausfall eines Sensorknotens
aufgrund von Energiemangel.
Um feststellen zu können, mit welchen Designentscheidungen (insbesondere bei
der Wahl des Routingverfahrens, aber auch bei der technischen Ausstattung) man die
Lebenszeit des Netzes positiv beeinflussen kann, ist es nötig, die theoretisch maximal
1
Es gibt derzeit eine Weiterentwicklung von Sensorknoten dahingehend, dass diese mit
Solarzellen ausgestattet werden. Dies würde die Lebenszeit von Sensorknoten deutlich
verlängern und die Energiefrage nicht mehr so stark in den Mittelpunkt stellen. Man muss
aber davon ausgehen, dass die Anwendung von Solarzellen sowie der Austausch von
Batterien in vielen wichtigen Einsatzgebieten nicht möglich sind.
19
20
erreichbare Lebensdauer im Voraus berechnen zu können. Dies ist Gegenstand der
hier beschriebenen Arbeiten.
Die Berechnung der maximal erreichbaren Lebensdauer für ein bestimmtes
Netzwerk erfolgt derzeit in der Regel nicht im Voraus. Fast alle Routing-Ansätze zur
Verringerung des Energieverbrauchs zeigen lediglich über einen Vergleich mit
anderen Routingprotokollen, um wie viel besser jeweils der eigene Ansatz ist. Eine
Aussage, welches Routingprotokoll mit welchen Parametern unter welchen
Anwendungsbedingungen die Lebensdauer eines Sensornetzes maximiert, ist so kaum
möglich. Auch eine Angabe, wie nahe die Lebensdauer an einer theoretisch maximal
erreichbaren Grenze liegt, kann dann nicht erfolgen. Diese Angaben wären aber, im
Sinne einer objektiven Vergleichbarkeit verschiedener Ansätze und einer besseren
Bestimmbarkeit der ausschlaggebenden Parameter für eine deutliche Verlängerung
der Lebensdauer, äußerst wünschenswert.
3 Modellierung
Es existiert ein einfach handhabbares mathematisches Modell zur Bestimmung der
oberen Grenze der Lebenszeit eines Netzwerks. Dieses Modell wurde von [ALO04]
entwickelt und ist experimentell von [RIT05] überprüft worden 2 .
Darauf aufbauend wurde an der Freien Universität Berlin eine Erweiterung des
Modells entwickelt, welches die Anpassung der Sendeenergie eines Sensors an die zu
überwindende Distanz zum Empfängersensor berücksichtigt. Während das Modell
von
[ALO04] von fester Sendeleistung ausgeht, spielt in der neueren Diskussion um
Routingverfahren die Sendeleistung eine stärkere Rolle. Da bei vielen Sensorknoten
der Energieverbrauch für das Übertragen von Daten deutlich größer ist als der
Verbrauch zum Empfangen von Daten, gehen neuere Überlegungen in die Richtung,
die Sendeleistung eines Sensorknotens an die zu überwindende Distanz zum nächsten
Knoten anzupassen. Für kürzere Strecken wird dann weniger Energie benötigt, für
längere entsprechend mehr. Durch das Anpassen der Sendeleistung an die
Erfordernisse kann Energie eingespart und die Lebensdauer des einzelnen
Sensorknoten und damit des gesamten Netzwerkes erhöht werden.
Zusätzlich zu der Regelung der Sendeleistung stellt sich dann die Frage, über
welche Empfängerknoten (vorausgesetzt es gibt mehrere Knoten in Sendereichweite)
ein Sensorknoten wie viele seiner Datenpakete schicken sollte. Für die Lebensdauer
eines einzelnen Sensorknotens wäre es zwar von Vorteil, wenn dieser seine Daten
immer nur zu dem Empfänger schickt, der am dichtesten dran ist und damit den
geringsten Energieverbrauch erfordert. Ein solches Verhalten kann aber für die
Lebensdauer des gesamten Netzwerkes nachteilig sein und diese u. U. extrem
verkürzen. Um die Lebensdauer des Netzwerkes zu maximieren ist vielmehr eine
andere Strategie nötig. Für jeden Knoten muss berechnet werden, wie viele Pakete an
2
Andere mathematische Modelle mit zum Teil ähnlichen Annahmen können zum Beispiel bei
[BHA01] oder [DUA04] nachgelesen werden.
21
welche Empfänger gesendet werden sollen, damit insgesamt die Lebensdauer
maximiert wird.
0-30
30-80
1
e1B
B
80-100
E1
e41
e31
3
e3B
e2B
>100
E3
e43
e32
4
E4
e42
2
E2
Abbildung 1: Basistopologie zur Untersuchung des
Energieverbrauchs
Anhand einer einfachen Basistopologie, die in Abbildung 1 dargestellt ist, wurden
verschiedene Routingverfahren mathematisch, simulativ und experimentell
miteinander verglichen. Dabei ergeben sich bereits bei der einfachen Basistopologie
deutliche Unterschiede, die auch im Experiment nachgemessen werden konnten.
4 Bewertung und Ausblick
Während Modelle wie das eingangs referenzierte [ALO04] auch leicht in einen
Algorithmus umgesetzt werden kann, der lokal auf den Knoten eine
Routingentscheidung herbeiführt, ist die optimale Routingentscheidung im Fall
variabler Sendeleistung nicht ohne globales Wissen möglich. Globales Wissen
bedeutet hier insbesondere die Kenntnis der gesamten Topologie.
In den vorgenommenen Experimenten wurde die optimale Lösung mit
Algorithmen verglichen, die ohne globales Wissen auskommen. Dabei zeigt sich,
dass lokale Algorithmen 80% und mehr der theoretisch möglichen Lebensdauer
erreichen.
Diese Ergebnisse wurden für eine Basistopologie mit fünf Knoten erzielt. Es bleibt
zu untersuchen, wie sich die Abweichungen zwischen Algorithmen mit globalem
Wissen einerseits und lokalem Wissen andererseits mit zunehmender Netzwerkgrösse
entwickeln und ob es möglich und sinnvoll ist, ein Netzwerk näherungsweise aus
Basistopologien zusammengesetzt zu modellieren.
22
Literatur
[ALO04]
[BHA01]
[DUA04]
[RIT05]
J. Alonso, A. Dunkels, Th. Voigt, “Bounds on the Energy
Consumption of Routings in Wireless Sensor Networks”, Proceedings
of the 2nd WiOpt, Modelling and Optimization in Mobile, Ad Hoc and
Wireless Networks, UK, 2004.
M. Bhardwaj, C. Chandrakasan, T. Garnett, „Upper Bounds on the
Lifetime of Sensor Networks”. IEEE International Conference on
Communications, pp. 785-790, 2001.
E. J. Duarte-Melo, M. Liu, A. Misra, “A Modeling Framework for
Computing Lifetime and Information Capacity in Wireless Sensor
Networks”, Proceedings of the 2nd WiOpt, Modeling and
Optimization in Mobile, Ad Hoc and Wireless Networks, UK, 2004.
H. Ritter, Th. Voigt, “Experimental Evaluation of Lifetime Bounds
for Wireless Sensor Networks”, Proceedings of the 2nd European
Workshop on Sensor Networks (EWSN 2005), 2005.
Rapid Prototyping of Context-aware
Applications
Torben Weis
Univerität Stuttgart, Univeritätsstrasse 38, 70569 Stuttgart
torben.weis@informatik.uni-stuttgart.de
Abstract. Prototyping, testing, and debugging of pervasive applications is a challenging endeavor, but adequate tool support can greatly
simplify these tasks. We present a tool chain that tackles this problem
already at the programming language level. Developers prototype applications in a specialized graphical programming language, which provides
simple yet powerful constructs to master common programming tasks of
pervasive computing applications.
1
Introduction
Appliances of a pervasive computing systems are very diverse. Sensor boards
with embedded controllers, smart phones, or PCs are freely programmable. Other
devices only react to a set of hard-wired commands, e.g. a TV reacts to RC5encoded infrared signals. Devices vary in their capabilities. Embedded controllers
on sensor devices run at low speed and have little memory compared to modern
PCs. Due to this diversity, the application developer faces a different programming model for every class of device. The developer has to tailor his application
for every device. This is unfeasible for rapid prototyping as soon as more than
one class of devices is involved. Thus, rapid prototyping requires a programming
model that hides the heterogeneity of the actual environment.
2
The Tool at a Glance
VRDK is a tool for prototyping context-aware applications. Its capabilities reach
from easy automation tasks to complex control applications.
In this section we provide a quick walkthrough that illustrates the basic
features of VRDK. In our example, we want to accomplish two tasks. First, we
want to put the living room in cinema mode when DVD playback starts. Once
the playback stops or is paused, we want to switch the room back to normal.
Second, we want the light to turn on when somebody moves into the living room.
A VRDK script consists of a set of processes, an optional set of functions,
and a set of hardware. For each of these concepts, our tool provides a dedicated
?
The presented work has been funded by DFG Excellence Center 627 ”Nexus” and
Microsoft Research Cambridge
23
24
Fig. 1. Configuring the available components
Fig. 2. Waiting for DVD playback to start
screen. Using the buttons in the upper left corner the user can switch between
these screens. The user starts by dragging in the required hardware from the
tool bar on the left, i.e. the Media Center PC, an intelligent light bulb, and an
embedded sensor board with motion detector. This is shown in Figure 1.
Fig. 3. Processes for handling DVD and light
Then the user switches to the process screen. He creates a new process and
drags in the required commands. Figure 2 shows how the user adds a wait
command to the process. He can achieve this either via drag&drop or via handwriting. The first thing our application has to do is to wait for DVD playback
to start. The user can simply click on the matching event in the wait command
dialog. Then, the user drags in some commands to switch off the light in cinema
mode and to set the volume to a decent level. Finally, our application has to
wait until playback stops and turn the light on again. Our second task is to turn
on the light when someone enters the room. Therefore, the user adds a second
process to the script. The process waits either for a movement or a certain time
to elapse. Upon movement the light is turned on, upon timeout it is turned off.
Figure 3 shows the complete example.
The drawback of this intermediate solution is that both processes interfere.
During DVD playback we don’t want the light to be turned on when someone
moves in the room. To demonstrate inter process communication in VRDK we
want to achieve this by suspending the Light process during DVD playback
(see Figure 4). Therefore the DVD process emits a Suspend signal during DVD
playback and a Reset signal after playback. These signals are connected to
receivers in the Light process. The user can connect emitters and receivers
simply by drawing a line from emitter to receiver. The belt indicates that emitter
and receiver are connected. VRDK shows the connection only when the pen or
mouse hovers over the emitter or receiver to avoid too many lines crossing each
others. The next section discusses the programming model behind VRDK in
greater detail.
25
26
Fig. 4. Combining DVD and light control
3
A Programming Model for Context-aware Applications
All presented approaches have their pros and cons. On one hand, extremely
specialized ones like Topiary or the Jigsaw Puzzle are comparatively easy to
learn but limited to a small set of scenarios. On the other hand, generic solutions
are hard to learn but powerful. The aim of our tool is to find a balance between
both extremes. Our target audience are technically interested users who do not
necessarily master a general purpose programming language. If someone is able
to program a Lego robot, he should be able to use our tool, too. The tool builds
on the following concepts:
–
–
–
–
–
–
–
Components
Events
Commands
Queries
Mathematical expressions
Workflow
Location
In the following sections we want to motivate and discuss this set of concepts
in more detail.
3.1
Components
Ubiquitous applications usually involve a large range of devices and services.
Currently, our tool supports Smartphones, PDAs, Media Center PCs, Browser,
Media Player, Microsoft Agents, Embedded Sensor Boards (ESB) [1], RC5 remote controls, and several toy robots including Lego Mindstorms and an enhanced RoboSapiens. HiFi and TV equipment can be remote controlled via
RC5 IR emitters. A components represents a device or service. The user can
use a component by simply dragging it from a tool bar on the editor window
(see Figure 1). To the user it does not matter how these devices are controlled
and which networking protocols they provide. Thus, our tool offers distribution transparency. Each component introduces a set of events, commands, and
queries. For example, a Media Center PC emits an event when it starts DVD
playback. Furthermore, this component introduces commands for controlling the
Media Center, e.g. to start playback or adjust the volume. Queries can be used
to read the state of the component.
3.2
Events
Events are central to ubiquitous applications [2][3]. Typically, applications spend
most of their time waiting for something to happen in the real world. Developers
should not care about raw sensor data and its routing, aggregation, and interpretation. They are interested in high-level events such as “Alice enters the room”
or “DVD playback stopped”. Components emit these events. Often applications
have to wait for composite events [4], for example “Everbody left the house and
the door is locked”.
Our tool takes this into consideration and features a very powerful but easy
to use wait command (see Figure 2). With a special dialog, the user can select
the events the application should wait for. Additionally, the user can specify a
timeout or time of day. Users can constrain events with expressions, for example
"LivingRoom.People > 3". In this case, the wait command is satisfied when
more than three people are in the living room.
3.3
Commands
Unlike object-oriented languages, VRDK does not break down everything into
objects and methods. If a component offers some functionality, it introduces a
new command. A command provides means to create side-effects, i.e. to control
the components. Each command features a graphical representation and a dialog
to configure the command. For example, the media player component offers
a command for controlling audio/video playback. Thus, the user can program
audio playback using drag&drop and a file dialog to select the audio file. For
non-programmers this is much easier than typing
player.Play("c:\\My Music\\foo\\bar.mp3");
Most people will already fail escaping the string correctly. Commands are
conceptually comparable to calling methods of a component. Using a graphical
representation and configuration dialogs our tool provides a more convenient
user experience.
27
28
3.4
Mathematical Expressions
In some cases users may want to provide a formula instead of a constant when
configuring a command. For example, a programmer could write
player.Play(archive.TopRating(10));
to play the top ten songs in an MP3 archive. In VRDK this is possible,
too, using mathematical expression. Most commands offer a simple dialog where
users can easily enter constants to configure the command (e.g. a MP3 file to
play). Furthermore, users can press the Calc button, which brings up a pocket
calculator style interface. The pocket calculator concept is familiar for most
users. The nice thing about it is that it shields the user from producing syntax
errors. Another benefit is that the calculator interface is equally well usable
with a TabletPC or the remote control of a Media Center PC. In contrast,
textual languages would require a keyboard. The calculator supports expressions
of numeric, boolean, and string types, as well as types provided by components.
For example, the user can query a snapshot from a camera component. The
expression Camera.Snapshot.Resolution queries the resolution of the current
snapshot. Note that all this can be achieved with just a few clicks in the dialog.
The user does not have to type a single character and there is no need to learn
a syntax for expressions.
3.5
Queries
Commands produce side-effects. However, sometimes the user just wants to
query a component. For example, he may want to get a list of his ten most
favorite songs or a camera snapshot. In VRDK commands and queries are two
totally different concepts whereas object-oriented languages map both to methods. The previous sections shows how to use queries in expressions. In contrast,
commands participate in a workflow (see the following section). The rational
between this distinction is that a command is useful by itself. It provokes some
activity. A query by itself is not useful. Its only purpose is to calculate values
that can be used by commands or to control the workflow. In general, expressions
and queries are concepts for advanced users. Many tasks can be solved without
them.
3.6
Workflow
We already discussed that VRDK allows the programmer to wait for events
and to control components with commands. Workflows orchestrate events and
commands. VRDK supports the full range of workflow elements:
– Processes
– Branches (if/then/else)
– Loops
– Select
– Split/Join (parallelism)
A VRDK program consists of one or multiple processes. Each process contains a workflow that is executed in an infinite loop. The workflow determines
for which events the application waits and which commands are executed if an
event occurs. Figure 3 shows how the workflow constructs are displayed in the
editor. Branches and loops are self explanatory. The select statement waits for
any of several alternative events. The split/join construct allows for parallelization inside a process. Combinations of select and split/join together with wait
statements can detect complex composite events.
Users can even program inter-process communication using asynchronous
events. Processes emit signals with the emit command. A signal can be connected
to one or multiple receivers. The workflow on the receiver side can wait for a
signal using the standard wait command. This concept is shown in Figure 4.
3.7
Location
Location is an essential concept in ubiquitous applications. In VRDK the user
arranges devices on a floor plan to tell the tool about the location of a device.
Thus, the user can create a static location model [5][6][3].
The programmer can either hardwire a location in his script or he can handle
location as a parameter. Hardwiring is the straight forward solution to many
simple problems. When you want to play music in the living room, you can
simply instruct the “play” command to use the Media Center PC, which is
located in the living room.
Now imagine you want to write a script that turns on the light in any room
when someone enters the room. Using hardwired location, the user would have
to program one process for every room. This results in duplicated code since
the processes will all contain the same workflow. The only differences are the
hardwired devices.
Fig. 5. A location-dependend process group
VRDK offers a solution to this problem. A user can specify a locationdependend process group. The process group executes one process for every location, for example for every room, floor, or house. All processes of the group share
29
30
the same workflow. This is shown in Figure 5. Creating such a process group is
extremely simple. The user just selects Run in every room in the property dialog of the process. Instead of using location-specific components or services (e.g.
the motion sensor in the living room), the user can use anonymous components.
For process groups, VRDK offers an anonymous instance of every supported
component or service. Upon execution of a process group, VRDK detects which
anonymous components are used and determines via the location model their
location-specific counterparts. In our example, VRDK will find out that the
process group requires one motion sensor and one controllable lamp per room.
Rooms that do not feature the required components do not participate in the
process group.
Fig. 6. Querying the location model with find any
Another way of dealing with location in VRDK is to query the location model
at runtime. Using the find any command the user can search for a certain device
type at some location. Figure 6 uses this to extend the previous example. If
someone enters the room, we search for an MsAgent and let him speak. VRDK
detects that the user queries for this component type and does therefore not
demand such a component for every room. This way, we can still use one process
group even though not every room must feature an MsAgent.
4
Components & Plug-Ins
VRDK has been designed as an open platform for e-home scripting. Therefore,
it builds heavily on the concept of plugins. In fact, the VRDK core does not
support any special device, component or service. This is completely realized
by plug-ins. Since VRDK is developed using C# and .NET, VRDK plug-ins
must reside in a .NET DLL. Currently, VRDK can control Microsoft Media
Center, Smartphones, PDAs, Browsers, Media Player, MS Agents, several robots
(including Lego Mindstorm [7] and RoboSapiens [8], and Embedded Sensors
Boards. Furthermore, we are working on a plug-in wizard that further simplifies
plug-in development.
A plugin can add new components, commands, events, and queries to VRDK.
All components appear in the icon bar on the left side of the screen (see Figure 1).
Once the user drags a component on the location model or hardware view, the
associated commands, events, and queries become available in the editor. This
way, the user has those commands at hand that make sense for his current
scenario. Following the above example, the media player component added a
media command to the icon bar.
As detailed in the following section, VRDK supports a built-in interpreter
and code generation framework. If a plugin adds new components, commands,
and events, it must provide callbacks for the interpreter and extensions for the
code generator. Although plugins must be implemented in .NET, that does by
no way imply that the supported devices must be .NET compatible. Only the
design-time support in VRDK is .NET specific. The runtime can use any possible
technology. This way, the tool is not limited to a fixed set of devices and can be
easily extended.
5
Script Execution
VRDK supports two ways of executing scripts. For rapid prototyping our tool
uses an built-in interpreter that can directly execute a script. Once satisfied with
the result, the user can choose to create source code or an executable.
5.1
Interpreter
The interpreter can be started by clicking on the Run button at the bottom of
the screen. Clicking on the screen again immediately stops the script and turns
off all involved devices. This way, users can quickly and conveniently experiment
with scripts.
The interpreter inspects all processes and workflows and constructs a state
machine for every workflow. A straight forward but inefficient approach is to
execute each VRDK process in a thread inside the interpreter. However, a VRDK
script can utilize many processes and process groups create even more process
instances. Mapping each modeled process to operating system threads turned out
to be highly inefficient. The GUI of the PC was no longer responsive. Therefore,
the interpreter executes all modeled processes in one thread. In a loop it advances
every state machine step by step. This approach yielded better results than
tweaking the operating system scheduler using process priorities.
The VRDK interpreter is able to execute the workflow (via the state machines) and it can evaluate mathematical expression. Furthermore, all event
handling is done by the interpreter. Whenever the interpreter comes across a
31
32
command, query, or event that has been introduced by a plugin, it asks the plugin to execute the command. This way, the interpreter can be easily extended
with plug-ins.
The interpreter uses a centralized approach, i.e. all application-logic is executed on a PC. This means that some devices are accessed remotely. To the
interpreter this does not matter since all communication with the component or
service is managed by the plugin that introduced the component.
5.2
Code Generation
VRDK features a code generation framework. Especially small devices as the
ESB, PDAs, or SmartPhones are not able to handle many concurrent threads.
Therefore, the code generation framework first translates the workflow into state
machines for the above mentioned reasons. The concrete code generator is realized with a plug-in, too. Currently, we support C# and C. New plugins could
support different target languages.
The advantage of code generation is that you do not have to run VRDK in
the background. Furthermore, the resulting implementation does not necessarily
require a PC to execute. The the case of a RoboSapiens extended with a PDA,
VRDK creates code that directly executed on the RoboSapiens’ PDA. Thus, the
RoboSapiens can act autonomously without a wire connection to a PC.
Another advantage of code generation is that we can get rid of the centralized script execution. If several programmable devices are involved, VRDK can
distribute the script across the devices. In the case of distributed code generation, we rely on a middleware that can transport messages between the devices.
In our current settings we are using a publish/subscribe middleware [9] that is
available for .NET and .NET compact framework. Efficiently distributing the
script across the involved devices is very demanding and is subject to ongoing
research. In general, our code generator framework supports two modes. One
is a master-slave mode where one device takes over the roll of the coordinator.
This is useful if a powerful device such as a PC is available. The other mode
is completely de-centralized and is applicable if all devices are restricted with
respect to CPU, RAM, and energy.
6
Conclusions
We have shown that prototyping of pervasive applications can greatly benefit
from a specialized high-level programming language such as VRDK. One major
difference between VRDK and other successful prototyping languages such as
Python is the tight integration of context in the language itself. Programmers
can easily attach functionality to locations, persons, or situations and the tool
figures out how to retrieve the context data from a context server or location
model. Consequently, VRDK developers do not explicitly attach functionality
to a special device. It is up to the generator in our tool chain to decide what
is executed where. Thus, for debugging purposes the tool can decide to execute
all application logic on the developer PC, which greatly simplifies debugging of
the application logic. Without such a generative approach, a centralized debug
version would be a total rewrite of the distributed release version.
Currently, we are working on an advanced 3D-simulator. Testing a pervasive
application often requires several students for event generation, several rooms
to test the influence of location, and expensive equipment. Thus, we want to
simulate context via a 3D-interface similar to popular role playing games. The
developer can then direct virtual persons through 3D-space and he can immediately see how the application logic behaves. A major challenge is to realistically
simulate the imprecision of sensors.
References
1. Scatterweb: The Embedded Sensor Board (2005) http://www.scatterweb.de/ESB.
2. Grimm, R., Anderson, T., Bershad, B., Wetherall, D.: A system architecture for
pervasive computing. In: 9th ACM SIGOPS European Workshop. (2000) 177–182
3. Johanson, B., Fox, A., Winograd, T.: The interactive workspaces project: Experiences with ubiquitous computing rooms. IEEE Pervasive Computing 1 (2002)
67–74
4. Pietzuch, P.R., Shand, B., Beacon, J.: Composite event detection as a generic
middleware extension. IEEE Network (2004) 44–55
5. Becker, C., Dürr, F.: On location models for ubiquitous computing. Personal and
Ubiquitous Computing 9 (2005) 20–31
6. Brumitt, B., S., S.: Topological world modeling using semantic spaces. In: Workshop
on Location Modeling for Ubiquitous Computing. (2001)
7. Lego: Mindstorms. mindstorms.lego.com (2005)
8. Behnke, S., Langner, T., Müller, J., Neub, H., Schreiber, M.: Nimbro rs: A low-cost
autonomous humanoid robot for multi-agent research. In: Methods and Technology
for Empirical Evaluation of Multi-Agent Systems and Multi-robot Teams (MTEE)
located at the 27th German Conference on Artificial Intelligence. (2004)
9. Ulbrich, A., Mühl, G., Weis, T., Geihs, K.: Programming abstractions for contentbased publish/subscribe in object-oriented languages. In: Confederated International Conferences CoopIS, DOA, and ODBASE 2004. Volume 3291 of Lecture
Notes in Computer Science (LNCS)., Larnaca, Cyprus, Springer (2004) 1538–1557
33
34
Ubiquitous Resources Abstraction using a File System
Interface on Sensor Nodes
Till Riedel, Christian Decker
Telecooperation Office (TecO), University of Karlsruhe,
Vincenz-Priessnitz-Str. 1,
76131 Karlsruhe, Germany
{riedel, cdecker}@teco.edu
http://www.teco.edu
Abstract. This paper proposes a file system as an abstraction layer for a
uniform way of accessing any system resource on wireless sensor nodes. Even
functions and libraries are represented and accessed in this uniform way
allowing developers a novel way to design and implement applications. A
lightweight implementation on our Particle Computer platform is described and
performance measurements indicate only a small overhead for a resource
access.
Introduction
In ubiquitous computing environments tiny, networked sensor nodes are embedded in
a variety of objects. Application programs on the nodes utilize many resources such
as different sensors, actuators like LEDs and speakers, memory for data storage and
the wireless communication interface. Other computational functionalities like
algorithms are encapsulated in libraries. Various approaches and even operating
systems, e.g. TinyOS, were developed to ease the development of applications on
wireless sensor nodes. Still, developers struggle with the diversity of different
resources and their particular access methods. We propose a file system, which
provides a uniform name space and access model for all resources. An
implementation on our Particle computer platform [1] proves the feasibility of an
implementation for sensor nodes and performance measurements indicate only a
small overhead when accessing resources through this abstraction layer. The
remainder of the paper is structured as follows: The next section analyses resources
on wireless sensor nodes and describes the design concept of the file system
abstraction layer. In section 3, the implementation of the ParticleFS is presented and
its performance is discussed in detail. In section 4 we show via a couple of examples
how applications programs can utilize the file system abstraction. The paper is then
concluded in section 5.
Analysis and Design
It is important for the design of any abstraction layer that one gets an idea of the
entities which are interfaced. We chose a very broad approach that uniformly handles
all identifiable entities in our system view. These entities are further referred to as
resources. The system should then provide a mechanism to support any kind of
resource abstraction the system designer may choose in a system. In the following
three subsections it will be shown how this approach is accomplished utilizing a file
system as a generic abstraction layer.
Resources
In general two kinds of resources can be identified. Direct resources represent the
hardware components on the platform, like sensors, actuators, memory, and
communication interfaces. On the other side mediated resources abstract functional
units that access other direct or mediated resources for further processing. Accessing
either kind through a uniform interface enables us to abstract from artificial
boundaries like hard- and software, or remote and local resources. Representing
resources as files forms this uniform access abstraction since the functionality can be
accessed through fundamental file operations “read” and ”write”. The file system
maps the generic “read” and “write” operations to the resource-specific
implementation. As a consequence, the developer can add, modify and move device
driver functionality transparently. At the same time an application may be developed
without any knowledge about the underlying system. Inspired by the “/proc” file
system introduced by Plan 9 [2] the notion of resources as files allow us to represent
operating system functionality along with file storage, devices and remote resources
within in a common name space.
Name Space
The abstraction of name spaces provides an intuitive way of addressing any resources.
Hierarchical name spaces prove to be an adequate means to categorize any resources
independent of its internal representation. Textual natural language resource
identifiers specify a path into the name space that uniquely identifies a resource.
Internally this resource can be represented by a fixed size machine-readable address
pointing to an arbitrary implementation of the resource. In a file system new parts of
the name space can be built into the existing hierarchy via the “mount” command.
This enables us to extend the system to react to dynamic settings and reflect a global
context. Every resource access is implicitly sensitive to such changes as “open” binds
resources in an ad hoc manner.
35
36
Ubiquitous Resources Abstraction using a File System Interface on Sensor Nodes
File-based Operations
Stream primitives are a scalable and mininalistic, yet powerful, abstraction for
accessing resources in the file system. The interface to streams consists of a pair of
POSIX-like I/O functions “read” and “write” [3] as well as a state to enforce the
semantics of sequential access. We found that such semantics fit all resources in our
system. Table 1 lists all file-based operations applicable to resources. The interface
represents streams as file descriptors.
Operation
Explanation
size_t read
(int fd, void* buf, size_t n)
Reads n data bytes from the resource
identified by fd to buf; returns number of
bytes or -1 if error occurred
Writes n data bytes from buf to the resource
fd; returns number of bytes or -1 if an error
occurred
Returns a descriptor for the resource; -1 if it is
not valid.
Frees the descriptor for the resource; -1 if it is
not valid.
Returns the type of a resource fd; -1 if fd is
not valid.
Creates a resource in the name space. Type
and function pointers to their specific read and
write operations are given. -1 is returned if the
resource_path already exists.
size_t write
(int fd, void* buf, size_t n)
int open(char* resource_path)
int close(int fd)
int getType(int fd)
int mount (char* resource_path, int type,
(*pFunc) read, (*pFunc) write)
int umount(char* resource_path)
Removes a resource; -1 is returned if it is not
valid.
Table 1. Generic access functions of the file system
Streams may invoke other streams to collect or to pass on data for further processing.
This stacking of streams is extended to a flexible mechanism for selection and
aggregation of data. Streams accessing other streams are equally mounted into the file
system's name space as mediated resource.
37
Implementation
We have implemented a file system based resource abstraction called ParticleFS on
our Smart-Its Particle Computer platform [1]. The tiny wireless Particle sensor nodes
comprise a PIC18f6720 micro controller including 128 KiloBytes (KB) ROM and
4KB RAM. The communication interface utilizes a TR1001 transceiver with the
customized RF protocol especially designed for ad-hoc networking in Ubicomp
environments. The current platform supports various sensors including 2Daccelerometers, light sensors, a microphone, a force sensor and a temperature sensor.
Furthermore the board carries a 4-MBit flash memory component and LEDs and
speaker as actuators. The devices are powered by a single AAA battery lasting for
several days up to months of operation.
In ParticleFS name resolution is done via a flattened tree data structure (see figure 1)
that represents the file system name space. Each tree element consumes only 2 byte of
memory including implicit type information supporting the dispatching to the
resource-specific implementation when the “open” operation is issued. ParticleFS is
currently able to address 213 distinct resources. As a consequence medium size flash
storage, e.g. the external flash memory, can be integrated directly into the addressing
scheme. When accessing this address range of the name space, the flash driver is
transparently invoked and translates stream semantics, i.e. read and write operations,
to sequential page-based file structures on the 4-MBit flash chip. It supports appendonly sequential files that can be used as persistent storage.
Mount Table
Name Space Table
0
/dev
name
type
read*
write*
0
audio
6
readMic
setRate
1
audiovolume
.
calcVol
setRange
3
...
...
1
/light
...
...
2
/audio
n-1
light
n
[free]
3
/usr
4
/file1
5
/subdir
6
7
/file2
Storage Table
/audiolib
8
9
readLight nop
name
/audiovolume
[free]
1
file2.frag
type
1
...
2047
[free]
2048
file2
read*
write*
writeFile
file1
readFile
0
Figure 1: File system tables of the ParticleFS
Figure 1 depicts an exemplary name space. As an example follow the link between
descriptive representation /dev/audio in the name space table to audio driver in the
mount table. The association is created by passing the driver functions to the “mount”
command (refer to Table 1). The driver provides “read” and “write” functionality
38
which are referred as read* and write* pointers in the mount table. Similar, this is
done for all other resources as well as storage files from the storage table. Calling
„open“ on a resource’s path will copy “read“ and “write“ function pointers to a file
descriptor table and instantiate a stream. Calling “read” and “write” on the stream’s
file descriptor will then invoke the resource specific implementation. Other resources
like the communication interface, actuator and arbitrary library functions for data
processing can be integrated in the same way. As a result, ParticleFS implements a
uniform access and representation model for all resources on the Particle wireless
sensor nodes.
Discussion of ParticleFS
Performance becomes a predominant issue for the file system on the resource
restricted devices like Particle Computer. After resolving the name the actual
overhead for using the file system for resource access is basically reduced to a call
indirection for calling read and write functions on file descriptors via a function
pointer. Additional overhead is only generated by passing length and state arguments
to the driver function. We measured a minimum of 100 processor cycles for a file
system resource access on a PIC18 processor. This compares to 26 cycles when
calling a static interface. Both values relate to compiler-generated code reading a one
byte of instantly available sensor data. Detailed measurements on the internal
communication overhead are given in Table 2.
Operation
cycles
Table look up function
Dereferencing state
15 cycles
4 cycles
PIC18F6720
3 µs
0.8 µs
Passing Parameters
10 cycles
2 µs
Function pointer call
26 cycles
5.2 µs
Accessing Parameters
10 cycles
2 µs
Writing the buffer
15 cycles
3 µs
Returning
Overhead of file system read
Overhead of simple Library call
Relative overhead
13 cycles
93 cycles
26 cycles
67 cycles
2.6 µs
18.6 µs
5.2 µs
13.2 µs
Table 2. Call overhead of file system sensor read.
In contrast to asynchronous message passing mechanisms our synchronous approach
has the advantage of being able to manage message buffers easily along with the call
stack. The semantics of synchronous message passing implicate cooperative
scheduling avoiding scheduling overhead. All internal communication cost between
functional units is thus reduced to the call overhead mentioned above.
The sequential access to the page based flash memory translates well to the stream
semantics. When writing data to the flash through a single file system stream the page
allocation and buffering mechanism achieves minimal blocking times. Write overhead
is only generated by the inferior erase strategy that is necessary to keep the file system
consistent. Because no restrictions are made on the number of open files (unlike e.g.
in [4]), buffer extrusion may lead to a maximum amount of internal page
fragmentation and I/O blocking times. A priorization scheme would be nessesary at
this point. Reading the flash, even concurrently, needs no flash buffer or page
allocation and imposes no additional overhead on the application.
Applications on Smart-Its Particles
In this section we describe how to map typical tasks of an application to the file
system API. We chose the example of an interactive command shell implemented on
the Particle Computer as a well-known application generic enough to make use of
most features of the ParticleFS. From this perspective the shell combines resources,
namely commands, which are then accessed in series. Each command of the shell is
implemented as a separate application and may therefore stand for any application
executed in a non-interactive context.
Accessing sensors. The “less /audiolib/audioVolume” command (figure 2) prints the
current light sensor value on the console. “less” does this by opening
“/audiolib/audioVolume” and reading from it and writing the string to the console.
Executable commands. To keep our shell application extensible it is reasonable to
represent all commands like “less” as resources themself. The shell application now
only calls write on the command to pass the command line arguments to the
implementation, which was mounted as the “write” method in the mount table from
figure 1.
Application
Command
Shell
ParticleFS
Reources
less
audio
audioVolume
Direct Resources
Mediated Resources
Hardware
Microphone
Fig. 2. Shell execution of “less /audilolib/audioVolume” on Particle
Browsing and file operations. The standard set of shell commands includes “dir”,
“copy”, “delete”, “write” for listing directories, copy, deletion and writing of files.
The commands allow to interactively inspect the file system and all available
resources on the embedded sensor node and reflect basic file system functionality as
39
40
separate executables. The “dir” command for instance has to call a read on a
directory. Directories are simple resources, which consists of a sequence of names for
every resource that is mounted directly below the inspected directory. These tuples
are parsed and printed.
Standard I/O. Up to now we assumed that we have standard way to return output to
the user by printing it back to the interactive shell. The runtime environments for most
programming languages therefore provide the notion of standard output. To write it
the program simply has to call functions like “printf”. The file system enables us to
support this standard set of I/O functions for any type of resource that was mounted.
In our shell we preset the standard output before executing a new command with the
resource that does the output for us. This might be a serial line type of output, a
display or a wireless network protocol.
Pipeline resources. Selecting or reformatting data for output is normally done by
specifying different selection or transformation criteria that apply to the data. This
may be done by parsing each data set and applying these rules manually in a loop.
However, it is reasonable to have those transformations applied automatically by
some query processor. We can provide a generic way of stream processing on top of
the file system by using pipes. Transformations are applied one after the other by
modifying and passing on the byte streams that are written to the pipe head until they
are finally outputted by the pipe end.
Each transformation is a executable command whose standard output points to the
next command in the pipe. To maintain the pipe structure the shell pushes the file
descriptors of all commands onto a pipe stack. The pipe is started by invoking the first
pipe element which was on top of this stack. On invocation the new top element of the
stack is popped and set as standard output. This way each command will always
passes its buffer on to the next pipe stage. For example “cat /voltage/battery| case
'high' -lt 1200 'ok' -lt 1000 'low' | uniq” can inform the caller of major changes of the
battery voltage as it drops below 1200mV and 1000mV. To do so voltage information
is transformed into context specific data, namely the string 'high' or 'low' with the
command “case” and then duplicates filtered out with “uniq”.
PC
ste;1;33
^C
FTP Gateway
SmartIts Particles
Fig. 3. Reprogramming via FTP using ParticleFS RPCs
Remote access. For the integration in back end systems a telnet style remote access
through the shell on the sensor nodes is most preferable as commonly no other input
method is available. For this purpose the file system functionality is externalized by
an RPC server. A write RPC can then be used to invoke a shell command remotely.
The same RPC interface can be used to access files from a back end system using web
protocols. In this way resources in a sensor node network can be easily integrated in
Unified Resource Identification (URI) scheme via lightweight protocol gateways. A
semantic location scheme can be used to compose the name spaces of all sensor node
on
semantic
level.
An
URI
then
looks
like
ftp://pftp.teco.edu/~facility/poolroom/1.1.1.2.3.4/usr/my_file and addresses the file
“/usr/my_file” on the Particle Computer 1.1.1.2.3.4 located in the poolroom. We use
the ftp protocol for over-the-air programming of SmartIts Particles Computer. This
approach is depicted in figure 3, where a target node is selected and a program image
can be transferred conveniently using a web browser.
Conclusion and Future Work
We believe that file system functionality proves to be a powerful tool to decouple
layers of software and hardware. The hierarchical name space and the standardized
I/O system can be used to express many high level abstractions as system resources,
while keeping the performance penalty for indirectly accessing hardware small. The
file system strives to reduce design time, while maximizing the design space of the
Particle Computer platform. Future work will further extend the file system
abstraction in order to include repetitive processes and event processing.
References
1. Decker, C., Krohn, A., Beigl, M., Zimmer T. The Particle Computer System. Proceedings of
the ACM/IEEE Fourth International Conference on Information Processing in Sensor
Networks (IPSN) 2005, Los Angeles, USA
2. Presotto, D., Trickey, H., Thompson, K., Winterbottom, P. and Pike, R.. The use of Name
Spaces in Plan 9. Operating Systems Review 27, 1999
3. The OpenGroup. IEEE Std 1003.1, 2004 Edition. Available online:
http://www.unix.org/single_unix_specification/ [Accessed: 09/2005]
4. Gay, D. The Matchbox File System. Available online: http://webs.cs.berkeley.edu/
tos/tinyos-1.x/doc/matchbox-design.pdf [Accessed: 09/2005]
41
42
Unterstützung mobiler Prozesse
im Mobile Computing
Christian P. Kunze
Verteilte Systeme und Informationssysteme
Fachbereich Informatik, Universität Hamburg
Vogt-Kölln-Str. 30, D-22527 Hamburg
kunze@informatik.uni-hamburg.de
1 Einleitung
Mobilität ist immer noch einer der wichtigsten Teilbereiche im Pervasive Computing. Die Überwindung der sich aus ihr ergebenden Anforderungen und Einschränkungen ist dabei eine der Aufgaben von Middleware-Systemen des Mobile Computing. Es hat sich gezeigt, dass solche Systeme im Gegensatz zu klassischen verteilten Systemen, meist weniger (Verteilungs-) Transparenz, dafür
aber mehr Ortsbezug sowie ein Bewusstsein über ihre Mobilität (Awareness),
besitzen sollten. Ausgehend von diesem Wissen ist es dann möglich, Anwendungen an die Bedingungen der sich verändernde Umgebung anzupassen
(Adaptability).
Diese Awareness und Adaptability beschränkt sich bei aktuellen Middleware-Ansätzen zur Unterstützung mobiler Anwendungen derzeit in den meisten Fällen jedoch darauf, dass mehr oder weniger monolithisch strukturierte Anwendungen in der Ausführung einzelner, kurzzeitiger Aufgaben unterstützt werden. Um jedoch der Vision des Pervasive Computings näher zu
kommen, sollten Middleware-Systeme in diesem Bereich auch komplexere,
möglichst sogar a priori unbekannte und vor allem langlebige Aufgaben unterstützen können.
Solche komplexen und anwendungsbezogenen Aufgaben können als eine Sequenz von in Beziehung stehenden einfachen Diensten angesehen werden, die in einem Prozess“ zusammengefasst werden. Solche Prozesse wer”
den dann (u.a.) von mobilen Clients im Interesse seines Benutzers verwaltet
und ausgeführt. Dies führt jedoch zu der Konsequenz, dass der mobile Client nun alle Dienste des Prozesses kennen und ausführen können muss. Zudem muss er in der Lage sein, alle Zwischenergebnisse verarbeiten zu können
1
– egal welche Größe oder Relevanz sie für das gewünschte Ergebnis haben.
Die Konsequenz hieraus ist, dass nun die mobilen Geräte zum Flaschenhals
werden und ihre begrenzten Fähigkeiten die Menge der möglichen Prozesse
bestimmen.
Weil die meisten Benutzer und Benutzerinnen jedoch lediglich am Endergebnis bzw. an einigen spezifischen Effekten des Prozesses interessiert sind
(und nicht an irgendwelchen Zwischenergebnissen oder der Art der Ausführung selbst), besteht in Verteilten Umgebungen auch die Möglichkeit, den Kontrollfluss – und mit ihm den ganzen Prozess – an andere Ausführungseinheiten
zu delegieren. In Kombination mit der Möglichkeit von Middleware-Systemen
für das Mobile Computing, Kontextinformationen zu nutzen und untereinander zu kooperieren, kann damit die Integration von langlebigen mobilen Prozessen und deren verteilte Ausführung einen zusätzlichen Nutzen auch im
Bereich des Mobile Computings bringen.
Im weiteren Verlauf dieses Beitrags wird das Projekt Distributed Environment for Mobility-Aware Computing (DEMAC) mit seinen Konzepten und Realisierungsvorschlägen zur Unterstützung mobiler Prozesse im Mobile Computing vorgestellt (Abschnitt 3). Zuvor werden in Abschnitt 2 die im Projekt betrachteten bestehenden Infrastrukturen und Prozessmodelle beschrieben. Abschnitt 4 beschließt den Beitrag mit einer kurzen Zusammenfassung und einem Ausblick.
2
Bestehende Infrastrukturen und Prozessmodelle
Mit dem Ziel, langlebige benutzer-zentrische Prozesse in eine Middleware für
mobile Systeme zu integrieren, müssen Arbeiten zum einen im Bereich des
Mobile Computings und zum anderen im Gebiet der Prozessbeschreibung
und -ausführung betrachtet werden. Bei der Analyse der Middleware-Systeme
soll ergründet werden, ob die bestehenden Ansätze bereits die Integration von
Prozessen unterstützen oder ob sie geeignet sind, um diese erweitert zu werden. Um ein Modell zur Beschreibung mobiler Prozesse zu erhalten, wurden
bestehende Prozessbeschreibungssprachen untersucht.
In diesem Zusammenhang zu betrachtende Middleware-Ansätze sind unter anderen: Nexus [4], als Plattform für kontextbewusste Anwendungen auf
Basis eines föderierten und globalen räumlichen Kontextmodells; das Projekt
m3 [6], welches einen Broker zum Anpassen der Übertragung von Protokollund Nutzdaten bezüglich des aktuellen Kontexts bereitstellt; Gaia [8, 7], als
Meta-Betriebssystem zur Unterstützung der Entwicklung und Ausführung von
mobilen Anwendungen in Ubiquitous Habitats“; RCSM [10], welches eine
”
Middleware für situationsbewusste Software in Pervasive-Computing-Umgebungen darstellt und PCOM [3], als komponentenbasiertes, leichtgewichtiges
und anpassungsfähiges System für verteilte Anwendungen mit explizit for2
43
44
mulierten Abhängigkeiten.
Um schließlich zu einem eigenständigen Prozessmodell zu kommen, müssen zudem unter anderem folgende Prozessbeschreibungssprachen betrachtet
werden: XPDL [5, 9], als eine technologieunabhängige Definitionssprache eines Meta-Modells zum Austausch von Prozessen sowie die Sprache BPEL4WS
[1], als Ergänzung des Web-Service-Protokollstapels, um Prozessbeschreibungen auf Basis des Orchestration-Paradigmas definieren und ausführen zu können. Im Gegensatz dazu basiert das WSCI [2] auf dem Choreography-Paradigma und ist als interne Erweiterung des WSDL-Standards konzipiert, die lediglich die Beteiligung einzelner Dienste aus deren lokaler Sicht an einem Prozess
beschreibt.
3 Prozessintegration in mobile Umgebungen
Die Untersuchung von bestehenden Middleware-Systemen im Bereich des Mobile Computings und von verbreiteten Prozessmodellen (vgl. Abschnitt 2) hat
zum dem im folgenden Abschnitt dargelegten Konzept zur Integration mobiler Prozesse geführt. Wie dieses Konzept im DEMAC-Projekt in eine Systemarchitektur umgesetzt wurde, wird dann im Abschnitt 3.2 beschrieben.
3.1 Konzept zur Integration mobiler Prozesse
Der Austausch und die verteilte Ausführung von Prozessen stellen an eine
zugrunde liegende Systeminfrastruktur Anforderungen, die aus unserer Sicht
von keinem der bestehenden Ansätze ausreichend unterstützt werden. Mobile a priori unbekannte Prozesse, deren Abarbeitung von nicht-funktionalen
Attributen determiniert wird, benötigen ein möglichst allgemeines und generisches Kontextmodell. Dieses muss neben den nicht-funktionalen Parametern
– wie zum Beispiel Quality-of-Service-Parameter oder Ortsangaben – auch eine
Unterstützung zum Auffinden und Einbinden von sehr abstrakt beschriebenen Diensten enthalten. Vor allem dieser Aspekt der nicht ausreichenden Kontextmodelle macht es erforderlich, eine eigene, an die Bedürfnisse der Prozessintegration angepasste Middleware zu konzipieren und zu realisieren (vgl.
Abschnitt 3.2).
Hierbei sollen mobile Systeme über einen möglichst einfachen asynchronen Kommunikationsmechanismus gekoppelt werden. Es wird dabei sowohl
die anwendungs- als auch die ereignisgesteuerte Kommunikation unterstützt.
Die dabei verwendete Adressierung des Transportmechanismus ist unabhängig bezüglich der darunter liegenden Transportprotokolle. Dies ermöglicht
es, dass das tatsächlich verwendete Protokoll gegenüber den Anwendungen
verborgen bzw. gezielt durch Adaptionsstategien festgelegt werden kann. Es
ist damit außerdem möglich, beim Ausfall eines Übertragungskanals (für die
3
Anwendung transparent) auf eine andere Verbindung zum Kommunikationspartner auszuweichen. Weiterhin wird als weitere Basiskomponente ein allgemeines und generisches Kontextmodell benötigt, welches in der Lage ist, neben beliebigen Attributen und Attributhierarchien auch Dienste und Diensthierarchien zu beschreiben. Damit lassen sich Dienstklassen definieren, die semantisch sowie in der Aufrufsyntax äquivalent sind und sich lediglich in der
technologischen Umsetzung unterscheiden. Diese im Kontextmodell inhärente
Abstraktion von Dienstklassen ermöglicht es im Prozessmodell, Dienste sehr
effizient zu beschreiben. Ein Prozessinterpreter umfasst als drittes Basiselement das Prozessmodell und den Prozesslebenszyklus der mobilen Prozesse.
Dieser ist für die Ausführung des mobilen Prozesses und die Einhaltung der
durch nicht-funktionale Aspekte vorgegebenen Rahmenbedingungen verantwortlich. Dazu muss er während der Laufzeit des Prozesses die Ausführung
kontinuierlich an die jeweiligen Kontextbedingungen anpassen und ggf. an
andere Geräte delegieren.
Da die bestehenden Prozessmodelle nicht für den Einsatz in einer mobilen
Umgebung konzipiert wurden, sind sie meistens zwar sehr ausdrucksmächtig, bieten aber kaum die Möglichkeit, ihre Komplexität durch Abstraktionen
zu reduzieren. Zudem sind viele Ansätze nicht technologieunabhängig und
stellen keine Unterstützung zur Formulierung nicht-funktionaler Aspekte bereit. Deshalb soll hier ein geeignetes Prozessmodel konzipiert werden, welches
besser für den Einsatz in einem Middleware-System für mobile Umgebungen geeignet ist. Dieses ist ähnlich wie das XPDL-Modell als technologieunabhängiges Meta-Prozessmodell angelegt. Es umfasst vor allem ein sehr allgemeines und effizientes Verfahren zur Beschreibung der im Prozess enthaltenen
Aktivitäten auf Basis abstrakter Dienstklassen. Zudem wurde die Möglichkeit
geschaffen, nicht-funktionale Parameter zu definieren, die als Rahmenbedingung während der Ausführung gelten. Dies führt dazu, dass auch delegierte
Prozesse noch der Intention des Benutzers bzw. der Benutzerin folgen.
3.2
Architektur des DEMAC-Ansatzes
Die auf Grund der Analyse bestehender Ansätze und Prozessmodelle entwickelte DEMAC-Systemarchitektur integriert mobile Prozesse nahtlos in eine
adaptive Infrastruktur für das Mobile Computing: Sie besteht im Wesentlichen
zzt. aus vier Komponenten – jeweils einer für die Kommunikation mit Pushund mit Pull-Semantik, einer für das Kontext-Management und einer für die
Prozessausführung:
Der Asynchronous Transport Service stellt die Kommunikationsbasis für das
DEMAC-System dar und kapselt als nachrichtenorientierter Transportmechanismus die unterliegenden konkreten Transportprotokolle, wie TCP/IP, Bluetooth oder IrDA. Ein eigenes Adressierungsschema hilft dabei unabhängig
4
45
46
von den Adressen der Transportprotokolle zu sein.
Darauf aufbauend realisiert der Event Service den proaktiven Versand von
Ereignisnachrichten zum Bekannt machen von Attributänderungen innerhalb
und außerhalb der lokalen Infrastruktur.
Der Context Service hat die Aufgabe, jegliche Information über den Kontext des Gerätes zu sammeln und zu verwalten. Dabei wird das lokale Wissen
mit Hilfe des Föderationsprinzips um Wissen über Geräte in der Umgebung
erweitert. Um Dienste und Geräte in der Umgebung finden zu können, ist
ein verteilter Verzeichnisdienst integriert, der seine Daten mittels Peer-to-PeerTechniken erwirbt.
Die Integration mobiler Prozesse in die DEMAC Architektur wird durch
den Process Service realisiert, der zum einen aus der Prozessbeschreibungssprache DPDL (DEMAC Process Description Language) und zum anderen aus einer Ausführungsumgebung für mobile Prozesse besteht. Durch die entwickelte Beschreibungssprache werden neben dem Prozess auch nicht-funktionale
Parameter kompakt beschrieben. Diese stellen Randbedingungen für die verteilte Ausführung dar und berücksichtigen somit die Intentionen des Nutzers
auch außerhalb seines Verantwortungsbereichs.
Die Ausführungsumgebung ist modular aufgebaut und gruppiert sich um
den zentralen Prozessinterpreter. Dieser stützt sich auf einen erweiterten Prozesslebenszyklus, in dem zusätzliche Zustände eingefügt sind, um einen laufenden
mobilen Prozess sicher an andere Geräte übertragen zu können. Dabei werden während der Ausführung und Übertragung stets die nicht-funktionalen
Aspekte des Nutzers berücksichtigt. Die in der Beschreibungssprache abstakt
gehaltenen Aktivitäten werden erst möglichst spät und in einem zweistufigen
Verfahren zu konkreten Diensten aufgelöst und dann ausgeführt (späte Bindung). Damit ist es im Prinzip möglich, Umsetzungen der abstrakten Dienste
in vielen Technologien bereit zu stellen, deren Nutzung dann lediglich durch
die beherrschten Verfahren des einzelnen Geräts eingeschränkt wird.
4 Zusammenfassung und Ausblick
In diesem Papier wird argumentiert und erläutert, dass die explizite Unterstützung von Prozessen im Bereich des Mobile Computings dazu führen kann,
dass die Fähigkeiten von verteilten Anwendungen in mobilen Umgebungen
wesentlich erweitert werden. Dabei werden durch das Zusammenwirken der
Konzepte des Kontexts, der Kollaboration und des Delegierens die Prozesse
selbst (bzw. ihre Ausführung) mobil. Aufbauend auf dem Konzept für derartige Prozesse (bzw. Prozessausführungen) wird eine entsprechend erweiterte
Middleware-Unterstützung vorgeschlagen und gezeigt, wie diese im Rahmen
des Projektes DEMAC umgesetzt wird.
Eine prototypische Implementierung des vorgestellten asynchronen Trans5
47
port-Dienstes und des Event-Dienstes sind innerhalb des DEMAC-Frameworks
zzt. bereits realisiert und in einer heterogenen und stark verteilten Systeminfrastruktur auf ihre Eignung getestet worden. Zudem sind die Prozessbeschreibungssprache DPDL spezifiziert und ein Prozessinterpreter dafür implementiert worden. Die dabei gemachten Erfahrungen haben bisher die Erwartungen
erfüllt; demnächst sollen u.a. diese Konzepte im Rahmen einer exemplarischen
Realisierung und Bewertung typischer Beispielszenarios noch weiter evaluiert
werden.
Literatur
[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller,
D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business process execution language for web services version 1.1. Specification, IBM, BEA Systems, Microsoft, SAP AG,
Siebel Systems, 2003.
[2] A. Arkin, S. Askary, S. Fordin, S. Jekeli, S. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer,
S. Struble, P. Takacsi-Nagy, I. Trickovic, and S. Zimek. Web service choreography interface
(wsci) 1.0. Specification NOTE-wsci-20020808, World Wide Web Consortium, 2002.
[3] C. Becker, M. Handte, G. Schiele, and K. Rothermel. Pcom - a component system for pervasive computing. In PERCOM ’04: Proceedings of the Second IEEE International Conference
on Pervasive Computing and Communications (PerCom’04), pages 67–76, 2004.
[4] F. Dürr, N. Hönle, D. Nicklas, C. Becker, and K. Rothermel. Nexus–a platform for contextaware applications. In J. Roth, editor, 1. Fachgespräch Ortsbezogene Anwendungen und Dienste der GI-Fachgruppe KuVS, 2004.
[5] R. Norin and M. Marin. Workflow process definition interface – xml process definition
language. Specification WFMC-TC-1025, Workflow Management Coalition, 2002.
[6] A. Rakotonirainy, J. Indulska, S. W. Loke, and A. Zaslavsky. Middleware for reactive
components: An integrated use of context, roles and event based coordination. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms, number
2218 in LNCS, pages 77–98. Springer Verlag, 2001.
[7] M. Román, C. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell, and K. Nahrstedt.
Gaia: A middleware platform for active spaces. SIGMOBILE Mob. Comput. Commun. Rev.,
6(4):65–67, 2002.
[8] M. Román, C. K. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell, and K. Nahrstedt.
Gaia: A middleware infrastructure to enable active spaces. IEEE Pervasive Computing,
pages 74–83, 2002.
[9] W. van der Aalst. Patterns and xpdl: A critical evaluation of the xml process definition
language. Technical Report FIT-TR-2003-06, Queensland University of Technology, 2003.
[10] S. S. Yau, D. Huang, H. Gong, and S. Seth. Development and runtime support for
situation-aware application software in ubiquitous computing environments. In Proc.
28th Annual Int’l Computer Software and Application Conference (COMPSAC 2004), pages
452–457, 2004.
6
48
Security and Privacy for Pervasive Computing
Daniel Bichler1 and Guido Stromberg1 and Mario Huemer2
1
2
Infineon Technologies AG, 81739 Munich, Germany
University of Erlangen-Nuremberg, Institute for Electronics Engineering,
91058 Erlangen, Germany
Abstract. Security and privacy are key issues in pervasive network environments. Due to the large number of perceived devices, the mobility of
users, the non-stationary of pervasive computing devices, new demands
on security and privacy for wireless communication are required. In particular, security needs to be guaranteed without confining the usability
of the networked system, and the application in pervasive environments
imply specific requirements on usability as well as certain security demands. These will be assessed and described in this paper, for leading
us to the demand novel key exchange mechanisms.
1
Introduction
The level of security and privacy in pervasive environments depends highly on the
application [1]. Most devices in such applications are small, battery powered, and
they have little computational power so that complex algorithms for encryption
or key exchange are unfeasible [2]. Most commonly used encryption algorithms
are based on public key methods for which the key generation, the coding and
the decoding of the transmitted data is computationally very intensive. Thus it
is not suitable for smart transceivers which are the key components of typical
applications for ambient intelligence systems.
Alternatively, symmetric cryptography methods can be used. These methods
are characterized by the fact that the respective sender and receiver use the
same cryptographic key for encryption and decryption. Both, the sender and
the receiver, must have a copy of the same key. This raises extreme problems
in transferring the key securely. It is not acceptable for humans to enter the
symmetric key into a key pad of each participating device. Diffie and Hellman
proposed in their paper a new algorithm to electronically exchange a symmetric
key between two parties [3]. The vulnerabilities of the so-called Diffie-Hellman
key exchange algorithm are carefully described in [4] and it is therefore not suitable for pervasive computing elements. Additionally, the algorithm to exchange
the symmetric key is very time consuming. Another possibility of using symmetric encryption is to pre-load all devices with secret information. That rises the
initial configuration effort of each device but ensures security and privacy.
Important is to facilitate establishing a ciphered connection between dedicated devices. Conventional key distribution or transport schemes should be
avoided because they are too complex. The intention is to guarantee security
and privacy when interacting with pervasive computing devices. The project
Smart-Its link together devices in our direct surrounding using the context of
proximity [5,6]. Admittedly, they don’t mind the aspect of ciphering the communication between devices. They only use the context of proximity to authenticate
electronic devices. For example, if a credit card and a car key are linked together
then the credit card could only be used when the car key is inside the same context of proximity as the credit card. Consequently, a thief, who has stolen only
the credit card, is not able to use the credit card for paying. The focus in [7,8] is
that electronic devices should mimic the humans behavior of identifying a friend
to find a reliable electronic communication partner. To this end, the respective
devices exchange information through a secure side channel, for example short
range infra red signal, so that they are able to authenticate each other during the
data communication. Herein, the disadvantage is that the user must configure
each participating device before the communication is allowed. This raises the
configuration overhead and is only applicable for seldom usage.
Asokan and Ginzboorg assume that people inside a conference room trust
each other [9]. Before the people exchange private data, they encrypt the wireless
communication with a shared secret. For example, someone writes a pass phrase
on the blackboard and the other people inside the conference room enter this
pass phrase into their laptop. In [10], they provide several levels of security
to facilitate the maintenance of the computational right management in large
buildings. All devices inside a room are electronically assigned to this room using
the IP address of the device. Admittedly, in large buildings it is desired to access
the devices from a centralized workstation. To this end, the user has to login to
the right disposer to verify whether he has the mandatory computational rights
to access the respective devices. That implies additional configuration overhead
during the installation phase and for adding new devices.
The previous explained applications pointed out that the demands on security and privacy in pervasive computing environments could not be achieved
adequately. Recapitulating, the visualized methods are having the downside that
they are either to slow, need to much computational power, require additional
configuration overhead, complicate augmenting the network, or provide weak
security mechanisms.
This paper focuses on scenarios for security and privacy in pervasive computing environments. First of all, Sec. 2 describes several security scenarios for Personal Area Networks (PANs) and for home automation. Sec. 3 describes methods
to reach the requirements of security and privacy. Sec. 4 concludes this paper.
2
Security Scenarios
Due to the high deployment and diversity of pervasive computing devices they
provide a very high spectrum of operational fields with different demands on
security and privacy. First of all, to confine the considerable number of possible
applications we consider two main scenarios:
49
50
1. Personal Area Network (PAN): PANs are used for communication among
electronic devices directly in the surrounding area of a person. This type of
network implies high mobility to the normal used devices in a network.
2. Home Automation: Networked electronic devices (i.e. actuators and sensors)
are integrated in our homes to facilitate regulating different units, for example air conditioning and lighting systems.
2.1
Scenarios for Personal Area Networks (PANs)
Personal networks interconnects various private devices which are always used
for interacting with or collecting private information of the user. They will escort
us in our daily life embedded in our clothes or pockets. This can be useful in
many different applications.
Typical devices used in scenarios for mobile PANs are, for example, a Bluetooth headset and a mobile phone, see Fig. 1. The communication between these
devices may reveal private information to an adversary. The objective in this scenario is to secure the wireless transmission of data and speech in both directions.
Another scenario illustrates the requirements for security and privacy between the communication of a wrist watch and a mobile phone, see Fig. 2. Normally, the mobile phone is placed somewhere in a hand bag or pocket, whereas
the wrist watch is always on your arm. Imagine, you are listening music and
the mobile phone is placed in another room. Suddenly, the display of your wrist
watch changes and indicates that your mobile phone is receiving a phone call.
The special constrains on computing power, size, weight, power supply and
power consumption complicate providing security and privacy in mobile PANs.
An important boundary condition in the presented scenarios is that many devices (e.g. Bluetooth headset) don’t have an interface for user inputs (e.g. key
pad). Thereby, the user is limited to predefined configurations to achieve security and privacy in an easy and user-friendly method. The high mobility of the
participating devices require new methods to guarantee security and privacy on
the way even if they are leaving a secure physical environment.
To guaranty security and privacy in both scenarios the devices must first
authenticate each other before they are allowed to accept messages from each
other. An unauthorized device must be excluded from the network communication. Additionally, the communication between the respective devices must
be encrypted to prevent the wireless communication from being eavesdropped.
Nevertheless, the secure connection establishment between the devices must be
as simple as possible to avoid that the user is overwhelmed.
2.2
Scenarios for Home Automation
An automated home connects all electronic sensors or actuators inside a building to a complete system that can be controlled electronically or manually. To
potentiate home automation to enter our daily life it is necessary to facilitate
installation and extensibility of the home network. The electronic devices, participating in the network, can either be stationary or mobile. Wireless communication enables facile connection establishment between stationary and mobile
devices but an adversary is able to easily eavesdrop or interfere the wireless
communication. To prevent misusage of the networked components security and
privacy methods must be used to restrict the wireless communication to dedicated devices. Therefore, to achieve security and privacy in home automation
the communication between all devices must be encrypted to protect the wireless
communication from being eavesdropped from external devices. Additionally, using authentication methods prevent the communication from being interfered by
a third party.
To reach the objective of security and privacy, the wireless communication
of the networked devices must be automatically restricted to a security domain
to provide an autonomous wireless network inside a specific security domain, see
Fig. 3. For example, in Fig. 3(a), the PDA configures the light bulb and the light
switch in the security domain 1. The PDA is not allowed to communicate with
the devices in the security domain 2. Afterwards, the PDA leaves the security
domain 1 and enters the security domain 2, see Fig. 3(b). Now, without any
additional configuration of the PDA, it can only communicate with the devices
in the security domain 2. Primarily, only devices inside the respective security
domain are allowed to communicate together as well as a human is always allowed
to use the manual control inside a room, for example a light switch to turn the
light on or off, respectively. That means that in this scenario, the user has no
possibility to control devices inside other security domains.
Organizing the previously described, isolated security domains to a hierarchical security structure enables an authenticated user to grant access to different
security domains. For example, several rooms of a building are equipped with
wireless light bulbs and light switches, see Fig. 4. Each human inside a room
is automatically allowed to turn on or off the light only inside this room using
the respective light switch or another electronic device, for example a PDA, see
Fig. 4(a). In contrast, an authorized user or device is allowed to communicate
with devices in other security domains, see Fig. 4(b). For example, a renter of an
apartment is allowed to control all lights inside his apartment, whereas the owner
of the building is allowed to control all devices inside the building excluding the
devices inside the apartment.
3
Solutions
The objective of security and privacy in pervasive computing environments is to
cipher the communication over a wireless connection. The fundamental idea is to
generate a symmetric key out of physical environmental parameters. Therefore,
special sensors are integrated in each device. Inspired by the SMART-ITs project
[6], we want to use an accelerometer to secure the wireless communication in
PANs. For example, shaking the devices together will generate a symmetric key.
Each device generates exactly the same symmetric key by analyzing the data of
51
52
the acceleration while shaking. Afterwards, this symmetric key is used for coding
and for decoding the data.
To secure the communication for home automation we select a physical parameter (e.g. infrared signal, ultraviolet signal, sound pattern) which is unique in
each room. Consequently, all devices inside the same room will measure the same
value of the parameter and will be able to generate exactly the same symmetric
key which is used for coding or decoding of the transmitted data. Thereby, all
devices inside the same room are able to communicate together whereas the communication with devices outside the room is not possible. Admittedly, a powerful
device enables us to build up a hierarchical structure of the security domains
and a complex right management can be achieved. For example, if a user or
device want to communicate with devices in another security domain, first, it
must authenticate to a powerful device which decides to allow or to reject the
communication, respectively.
4
Conclusion
In this paper we have presented scenarios to demonstrate the imperative necessity to develop new methods to guarantee security and privacy in pervasive
computing environments. We have proposed a security concept for PANs and for
home automation. In these concepts we use unique physical environmental parameters for generating a private cryptographic key to cipher the communication
between dedicated devices. The security domains, presented in this paper, facilitate secure connection establishment between devices inside a room. Adding new
devices to the restricted network is done automatically without any interaction
of a user. Obviously, due to many limitations of ambient intelligence network
environments an adversary will always find a way to interfere communication in
these networks [11, 12].
References
1. Stajano, F.: Security for Ubiquitous Computing. John Wiley & Sons, ISBN 0-47084493-0 (2002)
2. am, H., Ozdemir, S., Muthuavinashiappan, D., Nair, P.: Energy-Efficient Security
Protocol for Wireless Sensor Networks. In: Proceedings of the 2003 IEEE VTC
Fall Conference. (2003)
3. Diffie, W., Hellman, M.E.: New directions in cryptography. In: IEEE Transactions
on Information Theory. Volume 22. (1976) 644–654
4. Raymond, J.F., Stiglic, A.: Security issues in the diffie-hellman key agreement
protocol. In: Proceedings of IEEE Trans. on Information Theory. (1998) 1–17
5. Holmquist, L.E., Mattern, F., Schiele, B., Alahuhta, P., Beigl, M., Gellersen, H.W.:
Smart-Its Friends: A Technique for Users to Easily Establish Connections between
Smart Artefacts. In: UBICOMP. (2001)
6. Mattern, F., Kasten, O., Siegemund, F.: The Smart-Its Project. Perceptual Computing and Computer Vision Group (ETH), the Computing Department at Lancaster University (U.K.), TecO (Germany), PLAY (Sweden), and VTT (Finland),
http://www.vs.inf.ethz.ch/res/proj/smartits.html. (2005)
7. Capkun, S., Hubaux, J.P., Buttyan, L.: Mobility Helps Security in Ad Hoc
Networks.
In: Proceedings of 4th ACM Mobile Ad Hoc Networking and
Computing (MobiHoc’03), http://www.sigmobile.org/mobihoc/2003/papers/p46capkun.pdf (2003) 46–56
8. Balfanz, D., Smetters, D.K., Stewart, P., Wong, H.C.: Talking To Strangers:
Authentication in Ad-Hoc Wireless Networks.
In: Symposium on Network and Distributed Systems Security (NDSS) ’02, San Diego, USA,
http://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/balfan.pdf
(2002)
9. Asokan, N., Ginzboorg, P.: Key Agreement in Ad Hoc Networks. In: Computer
Communications, Volume 23. (2000) 1627–1637
10. Pfeifer, T., Micklei, A., Hartenthaler, H.: Internet integrated Building Control:
Leaving the Lab Robust, Scalable and Secure. In: Proceedings of 26th IEEE Workshop on Local Computer Networks, Florida, USA. (2001)
11. Feghhi, J., Feghhi, J., Williams, P.: Digital Certificates: Applied Internet Security.
Addison-Wesley, ISBN 0-201-30980-7 (2000)
12. Schneier, B.: Applied Cryptography, Second Edition: Protocols, Algorithms, and
Source in Code in C. John Wiley & Sons, ISBN 0-471-12845-7 (1996)
53
54
Audio and Data
Bluetooth Headset
Mobile Phone
Fig. 1. Ciphered Communication between BT Headset and Mobile Phone
Notification
Mobile Phone
Wristwatch
Fig. 2. Notification Message from Mobile Phone to Wrist Watch
Security Domain 1
Security Domain 1
Security Domain 2
Security Domain 2
(b)
Fig. 3. Security Domains. (a) Communication of PDA is restricted to Security Domain
1, (b) Communication of PDA is restricted to Security Domain 2
Security Domain 1
55
Security Domain 3
Guest
Security Domain 2
Authorized User
Security Domain 4
Authorized User
(a)
(b)
Fig. 4. Hierarchical Security Domains. (a) A Guest is only allowed to Communicate
with Devices in his Security Domain, (b) an authorized User is allowed to Communicate
with Devices in other Security Domains
56
Monitoring and Debugging of Deployed Sensor
Networks
Matthias Ringwald, Kay Römer
Dept. of Computer Science
ETH Zurich, Switzerland
{mringwal,roemer}@inf.ethz.ch
1
Introduction
As researchers actually start to deploy Wireless Sensor Networks (WSNs) in the
real-world, they are confronted with misbehaviors and problems not detected
or seen during previous simulations or lab tests. Monitoring and debugging a
deployed sensor network is often more difficult and more expensive than earlier
in-house tests as the network might be hard to reach or located in an humanunfriendly environment. Furthermore, as these networks are optimized to fulfill
their task with minimal energy consumption, it is hard to collect enough information to understand and solve such problems. The gathering of exhaustive
information for debugging purposes would require changes to the distributed application thus modifying its behavior and might lead to additional bugs. In this
extended abstract, we present our preliminary work on non-intrusive debugging
of WSNs, which, as we envision, will shorten and simplify the deployment phase
of future WSN applications.
2
Related Work
Although there is a multitude of tools available to simulate or emulate sensor
nodes and sensor networks on various levels, not much is available to aid in
monitoring and debugging of deployed sensor networks.
The Nucleus network management system (NMS) [?] facilitates monitoring
of running WSN applications by providing access to the internal data structures
of TinyOS nesC components over the network. To reduce interference of the
Nucleus system and the WSN application, data is only sent over the network in
response to a user query. In addition to this query approach, unexpected events
are logged to persistent local storage and can be retrieved later from the node
on demand.
In contrast to this single node debugging approach, Sympathy [?] focuses on
the collection of various metrics on the sensor node to detect and identify failures
in the network. The collected metrics are routed by the sensor network itself to
a centralized sink where they are evaluated. Sympathy’s failure detection and
localization is based on the assumption that a continuous data flow exits in a
working network. If less traffic is monitored than expected, a failure is reported.
Sympathy uses the collected metrics to localize the failure following a decision
tree based on previous experience and heuristics.
Both methods require to run additional program code on the sensor node
and create additional network traffic. They are implemented for a specific system
software platform. To minimize the changes and the impact to the sensor nodes,
the concept of a deployment-support network (DSN) [?] has been proposed to
provide the benefits of a wired testbed to a deployed wireless sensor network. An
additional DNS node can be attached to some or all WSN nodes. It then allows to
reprogram and restart the node, measure its battery level and provides access to a
local communication port for single node debugging or network-wide log message
collection. Our approach makes use of an additional DSN that is deployed in the
same area as the deployed WSN, but instead of a direct connection to a node,
we use the radio receiver of the DSN nodes to realize a network-wide distributed
sniffer.
3
Non-Intrusive Monitoring and Debugging of WSNs
In order to gain insight into deployed WSN, we investigate the usefulness of
network-wide observation of exchanged radio communication. We want to provide hardware and software tools which make use of this observation to allow
for non-intrusive monitoring and debugging of sensor networks. In the following
sections, we show how sensor network communication can be observed, decoded
and evaluated without changes to the deployed network.
3.1
Distributed Sniffer
The inherent broadcast characteristic of wireless communication makes it easy to
eavesdrop on exchanged messages in the neighborhood given that a compatible
radio transceiver is available and some basic knowledge about the radio communication such as bit rate, frequency and the packet format is provided. For
our own sensor network, we have this information available. As we do not want
to participate actively in the message exchange, it is sufficient for a sniffer node
to continuously listen to incoming radio messages regardless of the implemented
Medium Access Protocol of the sensor network. If a message is transmitted without collision, we can safely assume that we will receive it as good as a sensor
node at the same location would.
We assume that the DSN nodes are more powerful and can also use more energy then the sensor node to fulfill their observation task. For example, we use our
BTnode rev3 [?] as a DSN node. Its Chipcon CC1000 radio module is also used
on the second generation of the Berkeley Motes (mica2 and mica2dot nodes).
In addition, the BTnode contains a Bluetooth module and 256 KB RAM. The
Bluetooth module provides fast and reliable backbone communication, whereas
the extra memory allows to develop more complex applications and to queue
received packets.
57
58
To observe parts or a complete WSN such as shown in Fig. 1, we add our
deployment-support network (Fig. 2).
Besides knowing hardware configuration parameters such as radio frequency
and data rate, it is necessary to detect its start and end to correctly receive a
packet. Most radio protocols use a start-of-packet symbol that is transmitted
after the preamble. The length of the packet itself is either fixed for a given
application or can be dynamic. For dynamic packet lengths, it is customary that
a length byte is transmitted in the packet header which tells how many bytes will
follow. Knowing the position of this length byte is therefore sufficient to correctly
receive packets with variable lengths. All received packets are forwarded on the
DSN to the monitoring sink. Improvements on this, like filtering, in-network
processing etc, could be future work.
If a node’s transmission can be received by multiple DSN nodes, it is necessary
to distinguish this event from separate transmission of the same packet received
by a single DSN node. We are confident that the time-synchronization of the
DSN is sufficient for this.
Gateway
Fig. 1. Deployed Wireless Sensor Network
Gateway
Fig. 2. WSN with additional deployment-support network
3.2
Packet Decoding
Mere reception of the raw data packets does not provide much insight into the
WSN. The data packets need to be decoded to be useful for both humans or
further automatic processing. Although there are many packet description languages available, most notably ASN.1, we could not find a simple way to decode
binary packets into attribute-value pairs.
Our approach is based on the observation that packet layout is often implemented as nested structures data types (structs) in application developed
in C or nesC. By augmenting these structured data types with additional meta
data, we can extract packet layout from the application code. Using these packet
descriptions, we can decode sniffed messages.
3.3
Data Analysis
After the packet decoding, all relevant information is available for further processing. Here we will start by using {source, destination} pairs in the lowest
layer packets to reconstruct the network topology and present it to the user. If
packet sequence numbers are used, we can count the number of times a packet
is transmitted and spot regions where data is re-transmitted more often than in
other areas. Taking routing packets into account, it should be possible to present
routing paths and collect statistics on route changes due to variable link quality.
The proposed approach will facilitate further data data analysis methods. We
plan to incorporate a rule-base engine to allow the specification of distributed
assertions and tests on the spot.
4
Summary
We have given an overview of our proposed approach to support monitoring
and debugging of deployed wireless sensor networks which differs from existing solutions by its applicability to an already deployed network and its nonintrusiveness. A deployment-support network provides the ability to collect messages of the deployed network itself. Augmented C or nesC code serves as a packet
description to decode theses messages. The obtained data can then be uses to
reconstruct the network topology, to collect packet transmission statistics an,
and to implement distributed assertions.
5
Acknowledgments
The work presented in this paper was supported (in part) by the National Competence Center in Research on Mobile Information and Communication Systems
(NCCR-MICS), a center supported by the Swiss National Science Foundation
under grant number 5005-67322.
59
Arbeitsberichte des Instituts für Informatik 2000 - 2005
In letzter Zeit sind folgende Arbeitsberichte des Instituts für Informatik erschienen:
Band 33
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Weigand, Ulrich:
Zur deskriptiven Komplexität von monadischen Logiken der zweiten Stufe
(Februar 2000)
Lemmen, Frank:
Spezifikationsgesteuertes Monitoring zur Integration der Leistungsbewertung
in den formalen Entwurf von Kommunikationssystemen
(Februar 2000)
Buchacker, Kerstin:
Definition und Auswertung erweiterter Fehlerbäume für die
Zuverlässigkeitsanalyse technischer Systeme
(Juli 2000)
Jahresbericht 2000 der Informatik
(März 2001)
Band 34
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Nr. 5
Nr. 6
Nr. 7
Nr. 8
Nr. 9
Albrecht, Jens:
Anfrageoptimierung in Data-Warehouse-Systemen auf Grundlage des
multidimensionalen Datenmodells
(Januar 2001)
Hodek, Roman:
Synchronisation von Dateibäumen mit Hilfe von Graphtransformationssystemen
(Januar 2001)
Jablonski, Stefan (Hrsg.):
Von der Anwenderanalyse zu ersten Systemkonzepten für Workflow-Management-Lösungen
Bericht des Transferbereichs 21
„Operationales Prozess- und Datenmanagement für Großprojekte im Anlagenbereich“
(Januar 2001)
Meier, Erich:
Administrative Skalierbarkeit verteilter Systeme
(Februar 2001)
Lehner, Wolfgang (Hrsg.):
Advanced Techniques in Personalized Information Delivery
(Februar 2001)
Steckermeier, Martin:
Virtuelle, private Rechner — Eine Software-Architektur für verteilte Anwendungen
(April 2001)
Geier, Martin:
Fragmentierte Objekte für die Implementierung mobiler Agenten
(April 2001)
Günzel, Holger:
Darstellung von Veränderungen im multidimensionalen Datenmodell
(Juni 2001)
Greiner, Stefan:
Modeling and Analysis of Operating Systems Using Extended QN Techniques and Petri Nets
(Juni 2001)
Nr. 10
Nr. 11
Nr. 12
Nr. 13
Nr. 14
Nr. 15
Nr. 16
Nr. 17
Nr. 18
Christ, Volko:
Visualisierung quantitativer Markterfolgsdaten —
Möglichkeiten und Grenzen der automatisierten Erstellung
von Präsentationen im Marktforschungsbereich
(Juni 2001)
Schröder, Michael:
Automatische Objekt- und Threadverteilung in einer virtuellen Maschine
(Juli 2001)
Schamburger, Ralf:
Integrierte Betrachtung von Anwendungen und Systemen zur verteilten Workflow-Bearbeitung
(August 2001)
German, Reinhard; Lüthi, Johannes; Telek, Miklós (Eds.):
Proceedings of the Fifth International Workshop on
Performability Modeling of Computer and Communication Systems,
September 15-16, 2001, Erlangen
(September 2001)
Dalibor, Stefan:
Erstellung von Testplänen für verteilte Systeme durch stochastische Modellierung
(September 2001)
Paulus, Dietrich; Denzler, Joachim (Hrsg.):
Siebter Workshop Farbbildverarbeitung
4. - 5. Oktober 2001, Erlangen
(Oktober 2001)
Volle, Victor:
Verteilte Konfigurationsverwaltung im Kontext des Software Engineering Prozesses
(Oktober 2001)
Rosewitz, Martin:
PBK-Editor — Ein Werkzeug zur Erstellung von WWW-gestützten Produktberatungskomponenten
(Oktober 2001)
(März 2002)
Band 35
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Nr. 5
Nr. 6
Nr. 7
Billing, Gunnar:
Integrierte Hardware- und Softwareplanung flexibler Fertigungssysteme
(März 2002)
Haworth, Brigid:
Structural Coverage Criteria for Testing Object-Oriented Software
(März 2002)
Dörfel, Matthias; Dulz, Winfried; Herzog, Ulrich; Hofmann, Richard; Kerber, Lennard;
Mitschele-Thiel, Andreas; Münzenberger, Ralf; Spitz, Simone; Slomka, Frank:
Methodology and Tools for the Development of Optimized Real-time Systems
with SDL/MSC and VHDL
(September 2002)
Schlesinger, Lutz; Hümmer, Wolfgang; Bauer, Andreas (Hrsg.):
Heterogene Informationssysteme
(September 2002)
Rezk-Salama, Christof:
Volume Rendering Techniques for General Purpose Graphics Hardware
(September 2002)
Hilgers, Ursula:
Dienstgüteunterstützung in Weitverkehrsnetzen
(Dezember 2002)
(April 2003)
Band 36
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Nr. 5
Nr. 6
Nr. 7
Nr. 8
Kókai, Gabriella:
Erfolge und Probleme evolutionärer Algorithmen, induktiver logischer Programmierung
und ihrer Kombination
(Mai 2003)
Horn, Stefan:
Die schemabasierte Modellierung und Steuerung von Projektvorgängen
(Mai 2003)
Kipfer, Peter:
Distribution and Parallelization Strategies for Integrated Simulation, Visualization,
and Rendering Systems
(Mai 2003)
Dreßler, Falko:
Monitoring of Multicast Networks for Time-Synchronous Communication
(Mai 2003)
Gröbner, Matthias:
Ein Modell zur Beschreibung und Lösung von Zeitplanungsproblemen
(August 2003)
Golm, Michael:
The Structure of a Type-Safe Operating System
(August 2003)
Becker, Ulrich:
Verteilung von objektorientierten Anwendungen auf der Basis des Entwurfs-Modells
(September 2003)
Bauer, Andreas:
Datenallokation und Anfrageoptimierung in verteilten, föderierten Data-Warehouse-Systemen
(November 2003)
Band 37
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Nr. 5
Nr. 6
Meyer-Kayser, Joachim:
Automatische Verifikation stochastischer Systeme
(Januar 2004)
Lejmi, Habib:
Verbindung von Electronic Commerce und Logistik über virtuelle B2B-Marktplätze
(Juli 2004)
Bradl, Peter:
Einsatz von System Dynamics in der strategischen Unternehmensplanung – Prototypische Implementierung unter besonderer Berücksichtigung der Erfordernisse von Zu- und Abgangssystemen
(August 2004)
Zinn, Claus:
Understanding Informal Mathematical Discourse
(September 2004)
Rastofer, Uwe:
Modeling Component-Based Embedded Real-Time Systems
(Dezember 2004)
Mohr, Marcus:
Simulation of Bioelectric Fields:
The Forward and Inverse Problem of Electro-encephalographic Source Analysis
(Dezember 2004)
Band 38
Nr. 1
Nr. 2
Nr. 3
Nr. 4
Nr. 5
Vogelgsang, Christian:
The lgf3 (lumigraph framework version 3) Project:
A Versatile Implementation Framework for Image-Based Modeling and Rendering
(Mai 2005)
Schnitzer, Bernd:
Sicherheitsbewertung verteilter komponentenbasierter Programmsysteme
(Juli 2005)
Mertens, Peter; Große-Wilde, Jörn; Wilkens, Ingrid:
Die (Aus-)Wanderung der Softwareproduktion — Eine Zwischenbilanz
(Juli 2005)
Barner, Jörg:
A Lightweight Formal Method for the Prediction of Non-Functional System Properties
(Oktober 2005)
Dressler, Falko; Kleinöder, Jürgen (Hrsg.):
Energiebewusste Systeme und Methoden und Systemsoftware für Pervasive Computing
11. - 12. Oktober 2005, Erlangen
(Oktober 2005)
ISSN 1611-4205

Energiebewusste Systeme und Methoden

Transcription

Similar documents

PDF Version

2009 - Fakultät für Informatik

Abstrakte Verhaltensbeschreibung von CCM

dirichletsche greensche funktion

Die BUCHSTAVIER - Das Dosierte Leben