Energy Management and Task Scheduling of an Energy
Harvesting, Structural Health Monitoring System
Jamie Steck
Junjie Su
UC San Diego
jlbradle@ucsd.edu
UC San Diego
jusu@ucsd.edu
of the bridge [3]. Due to the need for better
bridge inspection methods and in response
to advances in sensor technology, sensors
networks are being employed to enhance
this two-year inspection requirement. These
sensor networks can measure qualities of a
structure such as strain, temperature, and
seismic activity, and using data processing,
these measurements can indicate possible
failure or need for repair.
Monitoring certain features of a structure
over time and evaluating these features to
determine the health of a structure is
referred to as Structural Health Monitoring
(SHM). Structural Health Monitoring is a
popular area of research in the fields of
embedded
systems
and
structural
engineering and encompasses not only
bridges, but also other structures such as
buildings, aircraft, spacecraft, and oilrigs.
Currently, most deployed SHM systems are
wired, and thus take a significant amount of
time to install and are usually expensive.
Current research, such as the work of
SHiMmer, is working to develop wireless
SHM systems in order to reduce cost, time
of
installation,
and
maintenance
requirements.
Over the years, many methods have been
developed to identify and detect damage in a
structure. One of the most promising
methods for SHM is the integration of smart
materials into the structures and utilization
of these smart materials as sensors and
actuators. For example, due to its chemical
ABSTRACT
Monitoring certain features of a structure
over time and evaluating these features to
determine the health of a structure is
referred to as Structural Health Monitoring
(SHM). SHiMmer, a solar-powered wireless
SHM system, monitors a structure,
processes the results, and transmits the data
to an external device. In this paper, we
examine the components of SHiMmer and
reveal both its capabilities and limitations.
We describe an energy management
simulation that will prove to be important in
SHiMmer’s future. We test the three task
components, integrate the XBee API
operation into the communication task, and
measure the energy consumption for two
tasks.
General Terms
Performance, Experimentation
Keywords
Energy harvesting, embedded
sensors, actuation, Zigbee
systems,
1. INTRODUCTION
Every two years, a team of engineers and
technicians inspects all United States
government-owned bridges in order to
determine the "health" of the structure.
However, as seen in the recent crash of a
bridge in Minneapolis, these inspections do
not always accurately reflect the condition
1
makeup, Lead-Zirconate-Titanate (PZT) can
be used to both generate and sense signals.
Because the electrical impedance of PZT
sensor/actuator is directly related to the
structure's mechanical impedance, this
impedance-based method can use high
frequency vibrations to monitor the
structure's mechanical impedance in order to
detect and locate the damage of a structure.
In addition, lamb waves are a type of elastic
perturbation that can propagate in and reveal
certain characteristics about a solid. The
speed of a lamb wave is dependent on the
frequency of the solid and can be generated
by an Electromagnetic-acoustic transducer
(EMAT) or a smart material such as PZT
transducers.
Some SHM systems only require nodes
to actuate, sense, and transmit data, but for
this project, the sensor node will also
process the data. In order to effectively
control the sensor node, acquire, process,
and transmit the sampled data or results,
the SHM node requires several software
components. While an entire operating
system can be used, such as TinyOS, only
certain OS features are needed to adequately
control the node. Software is needed to turn
the node on and off, communicate with the
external agent (via radio or the like), as well
as monitor the power and current energy
supply. In addition, software should be used
to control the sensors and/or actuators to
acquire the data (through sampling) and then
process the data. Data can either be directly
sent to the external agent or analyzed on the
node itself. Analysis involves storing the
data, transforming the data using a Fourier
transform or the like, and then performing
analysis to determine if damage exists in the
structure.
Some issues to consider when designing
an
SHM
system
include
energy,
maintenance,
installation,
cost,
and
reliability. While it is possible to create a
wired SHM system, a wireless system is
much more attractive due to the difficulties
of installing these systems on structures.
Wireless systems, however, are limited by
power, and thus must conserve energy in
every part of the system. Using batteries
increases the maintenance requirements, and
on a bridge, accessing sensor nodes may be
dangerous and difficult. In addition, it is
essential that an SHM system is reliable and
accurate. Citizens depend on these systems
to provide correct and constant results for
the safety purposes.
This project focuses on SHiMmer, an
area of current research here UCSD. The
rest of this paper is organized as follows:
Section 2 provides the background of
SHiMmer, a relevant energy management
algorithm, and other related work. Section 3
describes the progress made in each of the
three SHiMmer tasks, while section 4
introduces the energy management for
SHiMmer. In section 5, we describe future
work and then conclude the paper in section
6.
2. BACKGROUND
2.1 SHiMmer
[11] describes SHiMmer, a wireless SHM
system that uses solar power, supercapacitors, and on-node data processing.
SHiMmer monitors a structure, processes
the results, and transmits the data to an
external device, such as an Unmanned
Aerial Vehicle (UAV). The SHiMmer
project employs the impedance-based
technique and lamb waves technique
mentioned in the previous section to detect
damage in the structure. Both of these
techniques are non-destructive evaluation
methods that utilize PZTs to actuate and
sense, and both techniques have advantages
and disadvantages. Under observations, the
lamb waves technique is more effective for
thin plates, while the impedance-based
technique is more suitable for detecting
damage near structure joints
and
2
EEPROM (Microchip 25AA256) via the SPI
interface. The DSP is interfaced to 1MB of
SRAM (CY7C1021), a DAC (DAC902),
and two signal conditioning stages
(actuation and sensing). As mentioned
before, the piezoelectric transducers act as
both the sensors and actuators. The DAC
takes the signals from the DSP and
generates the voltage actuation waves to the
PZTs. One PZT produces a vibration that is
sensed by another PZT and then converted
back into voltage. The SRAM stores the
samples generated by the ADC integrated in
the DSP. Also, the DSP controls a
multiplexer that selects a different PZT as
sensor or actuator from a group of 16 PZTs.
In order to provide sufficient energy for
the sensor node to perform and reduce the
maintenance cost, the SHiMmer sensor node
employs an energy harvesting circuit, which
collects solar power and stores it in a
supercapacitor. Compared to other energy
harvesting methods, the solar energy
harvesting is the most efficient. The supercapacitor provides a much higher durability
(up to 20 years) than rechargeable batteries,
and also has slower performance
degradation than batteries.
Currently, the SHiMmer sensor node is
under development and is facing significant
challenges. The energy harvesting system of
the node cannot collect enough energy to
provide the node the ability to function
properly during cloudy days. Because the
solar panel collects energy based on the
sunlight density, it collects very little energy
during cloudy days compared to sunny days.
If the node continues to perform tasks when
the energy stored in the supercapacitor is
low, the system will consume all the energy
and eventually die. Currently, this energy
crisis is the most challenging part of the
SHiMmer sensing platform. Another
challenge involves installing the sensor
nodes properly. Many structures have
different shapes, so it is very challenging to
connections. Therefore, the SHiMmer
project combines these two techniques to
provide a better structural health monitoring
method.
Figure 1. SHiMmer Hardware Design
Figure 2. Current SHiMmer Board
The diagram of the sensor node used by
SHiMmer is shown in Figure 1, and the
actual SHiMmer board is shown in Figure 2.
The tasks for the node are to 1)
communicate with the UAV, 2) control the
piezoelectric transducers to collect data, and
3) perform analysis on the collected data.
The microcontroller (ATMega128L) is
connected to a passive radio trigger circuit,
which wakes up the microcontroller when
the UAV sends a signal. The microcontroller
controls the power for the rest of the
functional units using a CMOS switch
network. Once the microcontroller is woken
up, it communicates with the UAV via the
XBee radio module. Based on the
instruction received from the UAV, the
microcontroller then fetches the instructions
for the DSP (TMS320C2811) stored in the
3
place all the sensor nodes in a location that
can absorb sunlight. When nodes are placed
in shady areas, such as underneath a bridge,
it is imperative that the node can absorb
enough energy to stay alive.
ve. A final
challenge is the implementation of the
algorithms used to process the sampled data
on the DSP. Because of the energy
constraints
highlighted
above,
the
algorithms must be extremely efficient,
using fixed-point
point arithmetic and minimal
lines of code.
Figure 3. Energy Management Design
These algorithms were tested in Mat Lab
using sample solar panel data.
dat The details of
these algorithms and the results are beyond
the scope of this paper,, but can be found
[14].
2.2 Energy Management
[14] describes an energy prediction and
management scheme designed for energy
harvesting and event triggering systems,
such as SHiMmer. The design uses an
energy prediction algorithm combined with
an energy management unit to sc
schedule
tasks such as data actuation and acquisition
(Act/Acq), data processing (Processor
(Processor), and
radio communication (Radio)) according to
the corresponding energy requirements. The
relationship
between
the
energy
management unit and the energy prediction
algorithm is shown in Figure 2.
Readings from the solar panel are taken
every minute and used to estimate the
current voltage (and corresponding energy)
in the supercapacitor. (Because the voltage
in the supercapacitor cannot be measured
directly, it is imperative
erative that the recharge
rate of the supercapacitor is accurately
calculated.) If enough energy is available,
one of the three tasks is executed, and
energy is consumed. If there is not sufficient
energy, however, the EMU uses a prediction
algorithm to estimate
timate how long it should
sleep before checking the energy again. This
prediction algorithm uses past solar panel
data to estimate future readings.
2.3 Other Related Work
[1] presents an overview of design
considerations for Energy Harvesting
Embedded Systems (EHES) at both the
system levell and the software level. One
notable technique mentioned, Maximum
Power Point Tracking (MPPT),
(MPPT) seeks to
maximize the power output by controlling
the level at which power is drawn from the
energy source. MPPT requires that the input
intensity be known, which
ch can be done
either after conversion or by an alternate
method, such as using a light sensor to
estimate solar power. On the software level,
the paper describes the challenges of a
Power Management Policy in an EHES. The
goal of an EHES is to maintain energy
en
neutrality, or only consuming the amount of
energy that is harvested. To do this, the
power of the transducer must be analytically
modeled. With this information, the Power
Management Policy must adapt the
performance and power
ower consumption of the
system. [1] gives background on the
considerations for an EHES at a high level,
energy-aware
aware view. Our project is
essentially putting these considerations into
action. The information regarding the MPPT
confirms the necessity of the second solar
4
panel and the prediction algorithm to
maximize the power output. The power
management policy mentioned is also highly
indicative of the goal of the Energy
Management Policy.
[2] compares two different operating
system approaches designed for embedded
systems as well as presenting OS extensions
that enable effective power management in
energy-restricted systems. First, a generalpurpose, multi-tasking OS can be adapted to
support embedded systems. General-purpose
OSes, however, have high context switching
overhead and do not have built in energymanagement mechanism. For example, eCos
spends about 50% of the code size can be
attributed to communication overhead. A
second approach to embedded system OS
design is an event-driven architecture, which
can be easily modeled as a graph of
components that communicate via events.
TinyOS specifically targets this type of
communication, and when compared to
eCos, requires significantly less memory,
has eight times less OS overhead, and uses
twelve times less power. Despite its
advantages, however, TinyOS does not
provide global system level scheduling and
power management. Possible extensions to
TinyOS include: replacing the FIFO task
scheduler, implementing components in
hardware, allowing some tasks to go to
hardware instead of software, adding event
queues, and adding global power control
mechanisms. While
[2]
provides
an
important contrast between conventional and
event-driven OSes, we did not use TinyOS
for our project. Previous students tried to
port it to the microcontroller with no
success. Instead, we used Free RTOS, an
open source real-time embedded operations
system, further described in section 4.1.
[3] describes SOS, a new operating
system designed for sensor nodes. Due to
the dynamic nature of embedded systems,
specifically sensor nodes, SOS is composed
of a traditional core kernel and loadable
kernel modules. The SOS kernel supports
the ability to insert and remove modules at
run-time, flexible priority scheduling, and
dynamic memory. Modules are binaries that
implement a specific task or function.
Modules can easily be inserted into the
kernel at run-time using a user-friendly API.
Modules not only can communicate via
messages, but can also use faster function
calls to increase the speed and thus reduce
overhead. SOS schedules tasks using
priority queues, sharing the processor
through
cooperative scheduling. [3]
compares SOS to both TinyOS and Mate’.
SOS consumes significantly less energy
when updating code than TinyOS, and
provides greater system flexibility. [3]
presented an attractive option for the OS in
our project. SOS provides a high-level
programming interface for developing
modules and integrating them into the SOS
kernel at run-time; the source code for SOS
is free and available at [4]. It was decided
that SOS is excessive for the minimal needs
of our system, but was considered as a
viable alternative to our choice of Free
RTOS.
[5] presents the Lazy Scheduling
Algorithm (LSA), an algorithm for an
energy-driven scheduling scenario. A
previous work by the authors proves that the
LSA is optimal for a system with energy and
timing constraints. [5], as follows, presents
the implementation of the LSA followed by
some simulations. In the LSA, tasks are
scheduled according to the current energy
capacity of the system, task deadlines, and
the power dissipation of the tasks. A task is
characterized by its arrival time, energy
demand, and deadline and is considered to
be preemptive. The goal of the LSA is to
find an optimal start time for a task by
considering both the task time requirements
and the system energy capacity. In order to
find this optimal start time, the LSA requires
5
knowledge of the power flow for future
times. [5] does not mention how to find this,
but suggests an analysis of past harvested
power. [5] does not take into consideration
dependencies between tasks, which is
essential for the SHM sensor node. Data
cannot be processed until it is collected and
so forth. It is reasonable that this algorithm
could be altered to include dependencies.
For our proposed project, tasks do not have
deadlines; rather, the scheduler tries to
schedule as much as possible in a given time
according to energy capacity.
[6] presents a modeling circuit that
simulates the solar panel. Based on the
modeling circuit, the authors use simplified
parameters extraction procedure to find out
the value of the parameters (IL, I0, Rsh, Rs).
The reason to develop such a modeling
circuit is to find the MPP (maximum power
point) using very small Photovoltaic Cell
(such as those in embedded system). MPP
tracking requires substantial amount of
energy, which is hard to do in embedded
system. The modeling circuit works together
with a lighting pilot cell to achieve MPP,
which’s errors are within 5%. The goal of
this circuit is to keep tracking of the MPP. In
our platform, we do not use MPP tracking
because of the supercapacitor’s voltage
limitation. However, this circuit could be
used to simulate the solar panel behavior
and provide input to our microcontroller
prediction.
Everlast is a wireless sensor node that
utilizes a solar panel and supercapacitor to
power the node. [7] demonstrates the
feasibility of operating on a supercapacitor
recharged by a solar cell to power a sensor
node. It also introduces a PFM (pulse
frequency modulated) regulator and a PFM
controller, which are responsible for
controlling the voltage and current that
charging the supercapacitor in order to
improve the charging efficiency. Although
the
Everlast
sensor
has
different
functionality compared to our sensor,
Everlast uses the solar panel and
supercapacitor for the energy solution,
which is very similar to our sensor node.
Currently, our sensor node’s power circuit
tree is not working properly; however, in the
future, the PFM regulator and controller
could be a solution for our sensor node to
obtain better charging efficiency.
[9] proposes a highly efficient solar
energy harvest technique for embedded
system, namely, the MPPT (Maximum
Power Point Tracking) method. Power
equals the voltage times the current.
Therefore, for certain voltage and current
relationships, there exists a maximum power
point. [9] measures a linear relationship
between the maximum power voltage and
the open circuit voltage of the solar panel.
Utilizing this property, they built a solar
energy harvesting platform to perform the
MPPT. Getting the open circuit voltage from
the pilot cell, the tracker can adjust the
operating voltage to oscillate around the
maximum power voltage point to achieve
maximum power. [9] proposes a highly
efficient solar energy harvest technique,
MPPT. We cannot use MPPT due to the
extra energy consume in tracking MPP, but
can still use the concept to have a better
prediction of the future power.
3. TASK PROGRESS
SHiMmer is designed to perform three
primary tasks: actuation and acquisition,
data processing, and communication. The
progress made in each of these tasks is
described in the sections below.
3.1 Actuation and Acquisition
Actuation and acquisition are the most
crucial tasks for SHiMmer. The entire
purpose of the platform is to actuate and
sense in order to detect damage.
In order to monitor the structure’s
condition, we must first determine what
6
signal should be sent out and what signal
should be received. Per the recommendation
of a structural engineer, a pulse of sine
waves is preferred, because the sine wave
has a very narrow bandwidth and can easily
hit the lamb wave of the structure. Because
the actuation signal travels in all directions
and eventually all signals will bounce back
to the receiving node, the receiving signal
will become a dampened sine wave. The
frequency of the sine wave is chosen based
on which frequency will produce the best
shape at the receiving end. After running
several tests, we found that 32kHz is the
optimal frequency for the sine wave. At this
frequency, the sine wave produces the best
received signal in the testing material.
Currently, the DSP on SHiMmer cannot
read the code in EEPROM due to hardware
issues. Because of this, we decided to use
the DSP development platform, eZdsp,
together with a testing board that includes
the actuation and sensing circuits, to test the
actuation and acquisition. First, we store the
digital value of a sine wave in an array;
every clock cycle, we output one of the
values. After 40 cycles, the digital value
forms a sine wave cycle shape. The DAC
and op-amp circuit on the testing board then
convert the digital signal to analog so that
we can actuate this analog sine wave signal
to the PZTs.
The following diagram is a snap shot that
was taken in the oscilloscope. The green
signal is the actuation sine wave from -10V
to 10V. The blue signal is the receiving
signal at the receiving PZT. The top of the
sine wave has been chopped. This is because
the op-amp circuit’s resistance and
capacitance were designed poorly; the
mismatch of the resistance and capacitance
causes the offset. Ideally, the receiving
signal should be a smooth, dampened sine
wave. Unfortunately, this offset affects the
receiving signal and creates spikes in the
receiving signal.
Figure 4. Actuation and Acquisition
However, this problem can be easily
solved by adjusting the values of the resistor
and capacitor. We might need to double
check the anti-aliasing filter’s resistor and
capacitor’s value in order to make sure the
sensing circuit will perform correctly.
After we are able to successfully actuate
the sine wave into the circuit, we would like
to know how much energy the actuation
consumes. Unfortunately, we cannot isolate
the DSP from the eZdsp platform. The
eZdsp
platform
has
many circuit
components in addition to the actual DSP.
Based on the information from the
datasheet, we know that the DSP consumes
0.2415 J in idle mode and 0.6315 J in
regular operation mode. The maximum
energy consumption of the DSP is 0.91J.
As a result, we can only measure the
energy consumption of the testing board.
We changed some of the DSP code to
actuate continously, and then we measured
the current going into the testing board for
every power supply pin. Lastly, we can
estimate the energy consumption as the sum
of the products of the current and voltage of
every power supply pin. We can calculate
how much energy the testing board
consumes in each sine wave cycle by
dividing the energy by the number of sine
waves. Figure 5 shows the energy
consumption as it depends on the number of
cycles of sine waves.
7
Module. The XBee module uses the IEEE
802.15.4 Zigbee standard protocol and
operates in the ISM 2.4 GHz frequency
band. The radio can transmit to distances up
to 100 meters, assuming line of sight.
Further specifications of the functionality of
this module can be found in [15]. The
diagram of both the XBee and XBee PRO
modules is show in Figure 6. On The
SHiMmer board, only a subset of the
available pins are connected, specifically:
PIN 1 (supply voltage), PIN 2 (UART data
out), PIN 3 (UART data in), PIN 9 (sleep
control line), and PIN 10 (ground).
Figure 5. Energy Consumption per Sine
Wave
Based on this graph, our energy
mangement unit can then determine how
many cycles of sine waves we can actuate
and acquire under different energy
conditions.
Figure 6. XBee and XBee-PRO
Diagrams
3.2 Data Processing
One of the unique features that SHiMmer
has is its ability to do on-node processing.
Currently, we have two data processing
algorithms in the DSP code. The first one
finds the maximum point of the receiving
signals. The other algorithm is the Fast
Fourier Transform (FFT). FFT can
transform the signal from its time domain to
its frequency domain. It is very important to
provide the structural engineers the
receiving signal in both the time and
frequency domain, as their algorithms use
both to detect damage.
We apply the FFT function in the DSP
code by calling the FFT built-in function in
the TI library. When the microcontroller
chooses the FFT algorithm, our DSP code
will select the function and perform the FFT.
The XBee module interfaces with a host
device through a serial port and, thus, can
communicate with the Atmel 128L
microcontroller using SHiMmer UART’s
interface. Figure 7 shows the relationship
between SHiMmer and the XBee module.
Data is sent from the SHiMmer
microcontroller over the DI pin and back
through the DO pin. Because the Clear-toSend and Request-to-Send pins are not
connected on the SHiMmer platform, the
DI06 and DI07 configurations were
disabled, and, thus, hardware flow control
cannot be used. Instead, software flow
control must be implemented in order to
avoid buffer overflow.
3.3 Communication
SHiMmer communicates with external
devices using Maxstream’s XBee OEM RF
8
essential to determining if data is sent
successfully.
In order to make use of the API
operations, the code of the Atmel 128L was
modified to send data to the UART interface
using the specified frame formats. Whenever
data is to be transmitted, the Transmit
Request frame format is used, as shown in
Figure 9. Each API frame needs a start
delimiter, the MSB and LSB of the data
length, the API identifier, the identifierspecific data, and a checksum. If the
checksum fails, the packet will be quietly
dropped. Within the TX Request frame, the
frame ID, destination address, and options
must also be set. Finally, the RF data
contains the preciously defined SHiMmer
packet format, which is interpreted at the
receiving end.
Figure 7. XBee System Flow Diagram
XBee can operate in two modes:
transparent and API. In transparent
operation, the XBee module acts as a serial
line replacement, transmitting only the
UART
data
received
from
the
microcontroller and passing the exact
received data back to the UART; no
additional information is added. Due to the
fact that hardware flow control cannot be
used, it is necessary to use software
techniques when interacting with the XBee
module, such as ensuring that size of the
data sent to the module is smaller than the
size of the DI buffer, as shown in Figure 8.
In addition, there is no way in transparent
operation to check if a packet has been sent
successfully or whether another attempt
should be made.
Figure 9. Transmit Packet Structure
In the same manner, when data is
received from the XBee module, the
interrupt service routine processes the
received packet as either a transmit status
packet or a received packet, which can be
determined by the API identifier. If the
transmit status packet indicates a failure, the
previously sent packet must be resent.
Figure 10 shows the X CTU console
running on a desktop that was used to test
the SHiMmer platform. Initially, the X CTU
receives a packet (API identifier 81) from
SHiMmer, containing the contents “hello”.
Next, the console sends a packet to
SHiMmer with the contents “01” and
subsequently, receives a transmit status
Figure 8. Internal System Flow Diagram
In API mode, however, the XBee module
packages data in a structured interface and
provides the desired functionality for
SHiMmer. Data sent over the DI pin must be
contained in the specified frame, defining
what type of event is to be performed
(transmit, AT command, etc.) Using the API
operations enables SHiMmer to receive the
status of a transmitted packet, which is
9
packet that indicates the packet was sent
successfully.
4. Energy Management
Because SHiMmer operates using energy
harvested from a solar panel and stores
energy in a supercapacitor, a design, such as
that in [14], is needed to efficiently and
optimally to both schedule tasks and
conserve energy. To begin incorporating
these energy management algorithms into
the SHiMmer control, a real time operating
system was needed to provide timing and
communication between the prediction
algorithm and the energy management
algorithm.
4.1 Free RTOS
Figure 10. X CTU Console
Free RTOS, as described in [13], is an
open source operating system designed for
embedded systems. Free RTOS provides the
desired services to be used in the control of
SHiMmer. Specifically, Free RTOS is real
time, and thus can be used for the prediction
and energy management schemes designed
in [14].
Free RTOS is structured as a set of
independent tasks. Each task can operate in
real time, has its own stack, and has no
dependencies on other tasks. Tasks are
scheduled by the real-time scheduler based
on a set priority, operating in their own
context and having no knowledge of the
scheduling or preemption. Free RTOS also
provides several options for inter-task
communication. Queues are the primary
form of communication between both tasks
and interrupt routines and operate in a FIFO
manner. Queues also provide mutual
exclusion between tasks, preventing race
conditions or inaccurate data. Other options
for mutual exclusion and communication are
semaphores and mutexes, which prevent two
tasks from modifying a guarded resource
simultaneously.
Because XBee is a low-power radio
designed for embedded systems, the cost for
communication is relatively low. Transmit
power is 1 mW, and, at 3.3 V, the TX
current is 45 mA, and the RX current is 50
mA. In order to estimate the required energy
to send packets of various sizes, we
measured the time required to send packets
from size 19 bytes to size 119 bytes. For our
tests, we used 2.5 volts, and thus the current
for both sending and receiving measured
around 51 mA. Figure 11 shows the results
of these tests. As expected, there is a
roughly linear relationship between packet
size and energy consumed.
4.2 Simulation
Figure 11. XBee Energy Consumption
10
To begin testing the algorithms described
in [14], we used the AVR STK500
Developer Platform that uses the ATmega
128, the same microcontroller used by
SHiMmer. As seen in Figure 12, an
expansion board was also added to this
platform.
Figure 13. Example Simulation Data
5. FUTURE WORK
There is still significant work to be done
before SHiMmer is deployable. First, we
need a new SHiMmer platform with correct
op-amp resistor and capacitor settings.
Currently, our Zigbee chip, microcontroller,
DSP, and actuation and sensing circuits are
all tested separately. We have to integrate all
the parts into one complete system. The
actuation sine wave is chopped due to the
incorrect resistance and capacitance value. A
new SHiMmer platform will help to resolve
many of these issues.
Second, we will implement additional
data processing algorithms into the DSP
code. Finding the maximum and performing
the FFT is not enough information to
analysis complicated structural conditions.
We will need to measure the energy
consumption of different algorithms so that
our energy management unit can schedule
tasks based on the energy level and needs.
Finally, we need to continue work on the
simulation, pending fixes in the energy
management data. The most challenging part
of this will be inter-task communication and
consistency, but the Free RTOS features are
expected to be sufficient for our needs.
Figure 12. AVR STK500 Developer
Platform
The simulation running on this
microcontroller is still in early stages of
development. Solar panel data collected over
a period of twenty days is stored in an array
in memory. Every minute, the evolutionSP
task retrieves a value from the array to
simulate sampling the solar panel. This
value is then used to estimate the charge of
the supercapacitor, based on experimental
recharge rates that depend on the solar panel
voltage. Tasks were created for task
execution task and prediction task but have
not been combined with the evolutionSP
task yet.
Figure 13 shows the simulation using
solar panel data from two days. Initially, the
supercapacitor voltage is set to 1.8 V but,
after the first day, charges to capacity.
Unfortunately, the exact recharge rates of
the supercapacitor relative to the solar panel
voltage have still not been confirmed and
will likely change in the future. The graph
gives an idea of how the relationship
between the two components changes
depending on the solar panel voltage.
6. CONCLUSION
11
[3] Han, C., Kumar, R., Shea, R., Kohler, E., and
Srivastava, M. 2005. A dynamic operating system
for sensor nodes. In Proceedings of the 3rd
international Conference on Mobile Systems,
Applications, and Services (Seattle, Washington,
June 06 - 08, 2005). MobiSys '05. ACM, New
York, NY, 163-176.
[4] SOS Embedded Operating System,
https://projects.nesl.ucla.edu/public/sos2x/doc/index.html.
[5] Moser C, Brunelli D, Thiele L, Benini L (2006a)
Lazy scheduling for energy-harvesting sensor
nodes. In: Fifth working conference on distributed
and parallel embedded systems, DIPES 2006,
Braga, Portugal, 11–13 October 2006, pp 125–
134.
[6] Dondi, D.; Brunelli, D.; Benini, L.; Pavan, P.;
Bertacchini, A.; Larcher, L., "Photovoltaic cell
modeling for solar energy powered sensor
networks," Advances in Sensors and Interface,
2007. IWASI 2007. 2nd International Workshop
on , vol., no., pp.1-6, 26-27 June 2007.
[7] Simjee, F. and Chou, P. H. 2006. Everlast: longlife, supercapacitor-operated wireless sensor
node. In Proceedings of the 2006 international
Symposium on Low Power Electronics and
Design (Tegernsee, Bavaria, Germany, October
04 - 06, 2006). ISLPED '06. ACM, New York,
NY, 197-202.
[8] Yun Zhong; Jiancheng Zhang; Gengyin Li; Aiguo
Liu, "Research on Energy Efficiency of
Supercapacitor Energy Storage System," Power
System Technology, 2006. PowerCon 2006.
International Conference on , vol., no., pp.1-4,
Oct. 2006.
[9] D. Brunelli, S. Raggini, L. Benini , C. Moser and
L. Thiele, “An efficient solar energy harvester for
wireless sensor nodes.”, Submitted to
International Symposium on Low Power
Electronics in Portland, 27-29 Aug, 2007.
[10] SHiMmer Overview,
http://www.cs.ucsd.edu/~trosing/shm/.
[11] D. Musiani, K. Lin, T. Simunic Rosing, “An
active sensing platform for structural health
monitoring”, IPSN-SPOTS’07.
[12] SHM Article,
http://www.scienceprogress.org/2008/01/catching
-crumbling-infrastructure/.
[13] Free RTOS Documentation and Porting
Instructions, http://www.freertos.org/.
[14] J. Recas, C. Bergonzini, and T. Rosing,
“Management of Solar Harvested Energy in
Actuation-based and Event-triggered Systems.”
[15] XBee RF Module Product Manual,
http://ftp1.digi.com/support/documentation/manu
al_xb_oem-rf-modules_802.15.4_v1.xAx.pdf.
We have examined the many components
of SHiMmer and learned more about both
the capabilities and the limitations of the
platform. We learned how the hardware
works and also how to break it.
We began work on a simulation that will
prove to be important in SHiMmer’s future.
We tested the three task components,
integrated the XBee API operation into the
communication task, and measured the
energy consumption for two of the three
tasks. We will continue to work on
SHiMmer and combine the individual
components.
Acknowledgements
The origin of SHiMmer can be traced
back to Danielle Musiani, who designed the
original platform. Since then, many other
students have contributed to the progress of
SHiMmer, including: Benjamin Lee, Kaisen
Lin, Carlo Bergonzini, and Joaquin Recas.
Most importantly, we would like to thank
the many people who assisted us in this
project. Our advisor, Tajana Rosing,
provided indispensable guidance, and Carlo
Bergonzini and Eric Flynn answered some
pressing questions. Joaquin Recas and David
Mascarenas gave up many hours of their
time to teach us concepts we did not
understand, and we are indebted to them for
their help.
7. REFERENCES
[1] Raghunathan, V. and Chou, P. H. 2006. Design
and power management of energy harvesting
embedded systems. In Proceedings of the 2006
international Symposium on Low Power
Electronics and Design (Tegernsee, Bavaria,
Germany, October 04 - 06, 2006). ISLPED '06.
ACM, New York, NY, 369-374.
[2] Li, S., Sutton, R., and Rabaey, J. 2003. Low
power operating system for heterogeneous
wireless communication system. In Compilers
and Operating Systems For Low Power, L.
Benini, M. Kandemir, and J. Ramanujam, Eds.
Kluwer Academic Publishers, Norwell, MA, 116.
12