Sie sind auf Seite 1von 8


6, AUGUST 2009

A Hybrid Embedded Real-time Operating System

for Wireless Sensor Networks
Hai-ying Zhou1, Kun-mean Hou2, Christophe DE Vaulx2 and De-Cheng Zuo1
:School of Computer Science & Technology, Harbin Institute of Technology, Harbin, China
Email: {haiyingzhou, zdc}
:LIMOS Laboratory UMR 6158 CNRS, University of Blaise Pascal, Clermont-Ferrand, France

Abstract—Traditional operating systems for wireless sensor systems. Consequently, they are not met the requirement
networks (WSN) are based on either event-driven or of complex hard real-time applications, e.g. TinyOS[11].
multitask concept. Instead, this paper presents an embedded Therefore, our objective is to design a configurable real-
real-time operating system, named HEROS ‘Hybrid time dedicated WSNOS, which enables to adapt to an
Embedded Real-time Operating System’, which is
configurable to run in different modes: event-driven,
application to minimize resource consuming (memory
multitask or hybrid to adapt to diverse domains of WSN footprint and power).
applications. HEROS adopts a modular and hierarchical The paper is organized as following: section II
architecture: action (system operation), thread (component) describes HEROS system architecture; section III details
and event (etask) and provides a predictable and the scheduling mechanism and section IV presents the
deterministic scheduling mechanism: ‘non pre-emption system communication & synchronization mechanism;
priority based’ scheduling for events and ‘pre-emptive section V illustrates and discusses HEROS performance.
priority-based’ scheduling for threads. Furthermore, to ease Finally, we present the conclusion and the ongoing work.
distributed cooperative application, HEROS adopts LINDA
concept by providing a simplified tuple space and a
lightweight IN/OUT primitive-pair to implement system II. SYSTEM ARCHITECTURE
communication & synchronization. Currently, HEROS has By combining event-driven and multitask concepts,
been implemented and evaluated in different applications HEROS adopts component-based multi-level system
and on different platforms. The experimentation results
architecture: action, thread and event. In HEROS, the
show that HEROS has a small footprint and meets different
real-time application requirements. minimal system element is termed as ‘action’ that
responds to the basic system operation, such as ‘read’,
Index Terms—real-time multitask, event-driven, tuple and ‘write’, ‘schedule’, etc. A thread is a component that
In/Out, wireless sensor network consists of a set of actions, which represents a specific
task. An event is an etask (event task) which may be
composed at least by one thread. Note that in HEROS
I. INTRODUCTION etask is similar to event in TinyOS.
Real-time operating system plays a key role for A. Event-thread-action structure
embedded system even more for WSN due to resource Action: is a minimal system executing element, which
constraints. So designing an energy efficient operating contains a set of CPU instructions. In HEROS there are
system dedicated to WSN which meets the requirements two classes of action: system action (hardware-dependent)
of all the real-time applications is still an open problem and function action (hardware-independent). For example
and a challenge. in the case of a WSN application (sensing process), four
Due to resource constraints of WSN node and its types of actions may be considered: ‘read’ operation (data
diverse application domains, the key features of WSN collection), ‘analyze’ operation (processing), ‘write’
operating systems (WSNOS) should be resource-aware operation (sending results) and coordinate task operation
and be configurable to adapt to each situation. Note that (thread/event scheduling), see in Figure 1. The basic
most of traditional embedded RTOSs such as actions have been implemented and stored into the action
SDREAM8[1], µC/OS-II[2], VxWorks[3], QNX[4], library. A thread calls an action like calling a function
pSOS[5], Lynxos[6], RTLinux[7], WinCE.NET[8], from library. Since action hides the differences of
RTX[9] and HyperKernel[10] are unfit for WSN as they hardware devices and provides a uniform calling interface
are resource consuming. On the other hand, the event- for components, system designers can thus focus on
driven operating systems are essentially single task application development without care about hardware-
dependent operations.
Supported by Doctoral Fund of Youth Scholar of Ministry of Education Thread: is the component which is a light process or
of China (No.200802131024), French Program of Cooperation with task, and interacts only with other components within the
China (No.20974WG), and Scientific Research Fund of Returned
Oversea Scholars of Harbin city of China (No.RC2009LX010001).
same etask. Threads share resources within the etask and



communicate with each other through a shared tuple ℜ = {ε i : i = 1,2, , n; ε1 → ε 2  → ε n };

space. Threads run in concurrence or in parallel to
perform an etask. Hence, a thread is interruptible and pre-
{ }
ε i = τij : j = 1,2,  m i ; τi1 τi 2  τimi ; (1)

emptive, so it needs private stack to save its “context”. { }

τij = α ijk : k = 1,2,Sij ; α ij1 → α ij2  → α ijSij .
Note that sharing resources within the same etask reduces
system overheads and also decreases costs of system HEROS can be configured to run independently in
resources. event-driven, multitask and hybrid modes. Considering
Etask: represents an independent job having at least two extreme-case scenarios: if ℜ has only one etask, i.e.
one thread. An etask is interruptible but not pre-emptible n=1, HEROS runs in the multitask mode like any
and it is based on event-driven concept. An etask is traditional multitask operating system; while if each etask
activated only after receiving a trigger signal. In HEROS has only one thread, i.e. ∀mi=1, i∈{1,…, j}, HEROS
each etask can be associated with one and only one input operates as a pure event-driven mode like TinyOS.
event and n output events (0<n≤Max). In terms of the
regularity of occurrences, etasks are divided into two B. Event-/thread-control Block
classes: HEROS defines two table structures, named as etask
control block (ECB) and thread control block (TCB), to
 Periodic etask: typically suitable for regular data store etask and thread descriptors, shown in Table I. Each
sampling issued from sensors or for monitoring data structure contains at least an identification flag
actuators, which occur under fixed rate. (string or number), a priority, a status, and a related tuple
 Sporadic etasks: typically suitable for strict time- ID. Each structure has a specific attribute to indicate its
constraint tasks, which occur sporadically and can affiliation relation: the sub-TCBs list pointer of ECB and
be used to deal with the critical issues. the etask ID of TCB. Each structure also includes a time
Architecture: a thread is composed of a set of actions value to describe the absolute deadline and the allowable
and a set of components is an etask. The hierarchy time-slice. For a thread, the deadline value is used to
architecture of HEROS is shown in Figure 1. avoid the deadlock issue. For an etask, its initial time-
slice is set to the maximum allowable response time.
TCBs contain two buffer pointers, i.e. start stack pointer
(SSP) and current stack pointer (CSP). The stack space is
used to store thread context: program counter (PC), status
register(s), general registers and various variables.

Etask ID Thread ID
Figure 1 Hierarchy architecture based on action, thread and etask Etask Priority Thread Priority
Etask Status Thread Status
An etask can be viewed as a finite state automaton (see Etask Tuple ID Thread Tuple ID
in Figure 2). Once being triggered by an event (signal), Related TCB list Related Etask ID
the etask is activated and its threads start to be executed. Absolute Deadline Absolute Deadline
Etasks receive/send a signal by calling IN/OUT Timeslice Timeslice
primitives via the related tuple. An etask is a set of Start Stack Address (SSP)
threads which operate concurrently and cooperatively. Current Stack Address (CSP)
Threads adopt the same mechanism as etask for inter- C. Etask/thread states
thread communication and synchronization.
HEROS manages ECBs (TCBs) and schedules etask
(thread) by keeping track of the states of etasks (threads).
In HEROS, etasks have four operation states: ‘sleep’,
‘ready’, ‘execute’ and ‘terminate’, and threads have one
more state than an etask: ‘suspend’.
A state diagram related to etask and thread states is
shown in Figure 3. The state transition operations
exclusively related to threads are traced in red lines and
explained by gray texts. The unique broken line
represents the state transition from ‘terminate’ to ‘sleep’.
Figure 2 Automaton model of Etask/Thread structure
It should be noted that, according to the features of the
Denoting ℜ is a HEROS instance, ε is an etask, τ is a static pre-configuration and the determinate numbers of
thread, α is an action and ς is a signal. The ‘ → ’ symbol etask (threads), HEROS can combine the predefined
‘terminate’ and ‘sleep’ states into an ‘idle’ state. Thus an
denotes precedence sequential operation and ‘ ∥ ’
etask or thread enters the ‘idle’ state after it has finished
represents the concurrent or parallel operation. HEROS
execution, but the etask resource is not released and the
architecture is expressed as follows:
etask will be activated by the next signal.



Hence, each time a signal is sent to the related tuple

space, the status of the etask changes from ‘idle’ to
‘ready’, the absolute deadline is di,k and the time-slice is
pi. The time-slice value is decremented and is used to
evaluate the etask priority: the smaller the time-slice
value is, the higher the etask priority is.
Thread scheduling: adopts a priority-based pre-
emptive scheduling scheme. Threads are elected to run in
the order of priority and the elected thread can pre-empt
any other lower priority threads at any execution point
outside of system critical section. In HEROS, threads are
static priority scheduling, and their priorities are
predefined at pre-run-time. The allocation scheme of the
priorities of threads is:
Figure 3 An event and thread state diagram
 If a thread (τi0) is the successor thread of an etask εi,
III. SYSTEM SCHEDULING then τi0 has the highest priority within the threads of
the etask εi;
In order to meet the requirements of hard real-time  Each thread has a unique input tuple, in which the
applications, it is indispensible that the operating system thread reads msg from other threads or etasks.
should produce a predictable schedule. It means that at all  If a thread τi,j waits a msg coming from other thread
times it should be known which task is going to be τi,j-1 on its tuple, τi,j thus has the lower priority than
executed. With the etask (thread) system architecture, that of τi,j-1, and so on.
HEROS offers two-level dynamic-priority scheduling:
‘non-preemptive-priority’ for etask at high level and Threads are interruptible and preemptive. A thread
‘preemptive-priority’ for threads at low level. interacts with others via the tuple space by calling the
IN/OUT primitive-pair. When a thread sends a message
A. Scheduling Algorithm or signal to the tuple space, the OUT primitive is called to
Etask scheduling: adopts the priority-based non- change the state of the related tuple from ‘idle’ or
preemptive scheduling and I/O devices are interrupt- ‘suspend’ to ‘ready’. Moreover, the time-slice value of
driven. An etask is elected to run according to its priority each item of TCB suspend list is reevaluated in view of
and an active etask runs to completion without any pre- the current timeslot and the deadline value.
emption. At any instant when an etask terminated, the A.3 Etaskt-to-thread jump: The following theorem gives
etask scheduling is activated to elect the next etask to run. the condition under which a feasible schedule exists
This scheme is a dynamic-priority scheduling, like under the EDF scheme.
earliest-deadline-first (EDF) algorithm [12]: the etask If a HEROS instance consists of periodic etasks and
with earliest deadline has the highest priority. meets (3), its etask/thread scheduling scheme can be
Note that etasks are interruptible. When an interrupt predictable. If the execution time of etask is deterministic
occurs, its ISR stores the message (msg) or signal and and transient, HEROS can be considered as a soft real
then sends it to the related tuple buffer by calling the time system. But for hard real-time etasks, generally
OUT primitive. The corresponding operation will be caused by sporadic etasks, which need to be reacted
reacted only after the active etask has run to completion. within a strict time-constrained deadline, the above-
Meanwhile, the OUT primitive updates the attribute defined scheduling scheme does not always meet the
values of the etask, including status, time-slice, and also requirement if equation (4) cannot be satisfied.
revaluates the priorities of all ready events according to
Theorem [EDF Bound][12]: A set of n periodic etasks, each of
the scheduling scheme. whose relative deadline equals its period, can be feasibly scheduled by
For a periodic etask, suppose Di, (relative deadline) EDF if and only if
equal pi (its period); while for a sporadic etask, the n
system allocates a maximum allowable response time (Di)
when the etask occurs. This paper assumes that all etasks
 (e / p ) ≤ 1
i =1
i i

are periodic and independent (a sporadic etask can be Where ei is the periodic etaski run time and pi is the
regarded as the first instance of a periodic etask), the etaski period. Let εs and εp be the sporadic etask and the
relative deadline of an etask is its period, etasks are pre- active periodic etask respectively, Ds and es be the
emptible and their preemption time is neglected. relative deadline and the execution time of εs, and ep be
Defining ri,k and di,k are the release or arrival time and the expected time from the interrupted instant to the
the absolute deadline of kth instance of etask εi; Di is the completed instant of εp, where 0<ep≤ei. Then the feasibly
relative deadline of etask εi, which equals its period pi; φi of the sporadic etask εs meets its deadline is that
is the phase of etask εi, which equals to ri,1, then
Ds < e p + es (4)
ϕi = ri ,1 , ri , k = ϕi + (k − 1) * pi (2) Note that since the execution time of ISR related to the
d i , k = ri , k + Di = ϕi + k * pi sporadic etask εs is very short and deterministic, it is thus



ignored. If equation (4) is not met, therefore, the etask εs Figure 4 shows that this scheduling scheme is smart
miss its deadline and then the system enters an and predictable, and has deterministic execution time
unexpected exceptional status. To ensure in this worst- independent of the numbers of etasks (threads). Note that
case scenario the sporadic etask can be handled with short the top item of ECB ready lists or TCB lists is the one
response time to meet its deadline, the special etask-to- with the highest priority, which has been elected and
thread jump mechanism is proposed: the sporadic etask εs sorted by the rules of the scheduling scheme in the
is treated as the highest priority thread τs of current IN/OUT system primitive-pair.
periodic etask εp, so that τs can preempt any other active A HEROS instance composing of a set of etasks
thread of εp according to the thread scheduling scheme. (threads) is presented in Table II and illustrated in Figure
The etask-to-thread jump mechanism breaks down the 5. The periodic etasks, i.e. ε1 and ε2, are released at time 0,
obstacle between threads and etasks, allowing the threads and the sporadic etask εs occurs at time 3. Since the etask
of an urgent etask to preempt the CPU resource. ε1 has the smallest period, it is the highest priority etask to
Let Ρ(ε) and Ρ(τ) be the priorities of etasks and threads, start and thus it is elected to run first. At time 3, the etask
then when an etask-to-thread jump occurs, the priorities εs is released. At this point, consider ep=2, es=1 and Ds=2,
of the threads of the etasks (εs and εp) is: equation (4) does not meet, and the jump function is thus
called to perform an etask-to-thread jump. At time 5*k
Ρ(ε ) = Ρ(ε ) + Ρ(τ ) / 10 (5)
and 7*k, the kth instances of ε1 and ε2 are released
Note that HEROS quantifies the priority of etasks and respectively.
threads between 0 and 10. Since the sporadic etask has TABLE II SAMPLE ETASK/THREAD SET FOR THE SCHEDULER
higher priority than the active etask, that is, Ρεs>Ρεp, then
the threads of εs have higher priority than those of εp, so εi ri ei pi τi
that they can preempt the CPU resources. ε1 0 2 5 τ11, τ12
ε2 0 3 7 τ21, τ22, τ23
B. Scheduling program εs 3 1 2 τs
HEROS two-level scheduling program is implemented
by using C language and it has two main parts: the
scheduler function, which implements etask/thread
dispatch, will be called regularly at a fixed-rate by Timer
ISR or when a thread is terminated; the IN/OUT system
primitive-pair, which realizes the priority computation Figure 5 An instance of etask/thread two-level scheduling
(etask only) and ECB/TCB list sorting according to
priority and etask-to-thread operation (optional), will be IV. SYSTEM COMMUNICATION& SYNCHRONISATION
executed when calling IN/OUT primitives. Two global The interactions between system components are
variables, i.e. current_etask and current_thread, are essential to provide system communication and
defined to indicate current active etask and thread. synchronization services. In term of the action-thread-
etask structure, HEROS provides three system
interactions: event-ISR, inter-event and inter-thread.
HEROS employs LINDA concept, i.e. tuple space,
IN/OUT primitive-pair, to enable system interactions and
ease distributed cooperative application [13]. The basic
LINDA primitives of posting and reading tuple are: IN &
OUT [14]. Note that a message delivery in LINDA is
based on content matching, it is thus not space couple.
Moreover, since the IPC (inter-process communication)
in LINDA is asynchronous, it is also not time couple. The
‘tuple’ model may be extended to support multi-CPU and
multi-thread parallel programming model. Therefore,
LINDA is suitable for parallel distributed applications.
The original LINDA concept is not adequate for
distributed hard real-time parallel processing because the
IPC time is increases dramatically and not deterministic,
when the number of processes or processors is important
(more than 100) [15]. To overcome these problems,
HEROS adopts a simplified tuple space and a lightweight
system primitive-pair.
A. HEROS: Tuple space implementation
The tuple space consists of a set of tuples identified by
a key. Each tuple contains a critical resource, that is, a
Figure 4 System scheduling mechanism special data structure called a circular queue or ring



buffer. In the ring buffer, simultaneous input and output associated with a unique tuple. When a message received
of the list are achieved by keeping head and tail indices. from peripheral or etask is occurred, the OUT operation is
Data are loaded at the head and read from the tail. A tuple performed to store data into the related tuple and to
is encapsulated in tuple_table, see in TABLE III . update its status information. Consequently, the OUT
primitive updates the status information of the associate
etask (thread) tuple and the time slice value of system
Typedef struct tuple_table items in the ECB ready list (TCB suspended list), and
{ then resorts the ECB ready list at sort descending
char Tuple-ID; /* tuple identifier: key*/
according to their time slice values or sets a thread into
char tuple_state; /* tuple state: free 0; ready 1*/
char tuple_size; /* ring buffer size*/ the ‘terminate’ state if the thread runs out of allowable
unsigned char* tuple_head; /*writing msg buffer pointer */ block time.
unsigned char* tuple_tail; /*reading msg buffer pointer*/
unsigned long tuple_staadr; /* ring buffer start position*/
unsigned long tuple_endadr; /* ring buffer end position*/
char tuple_msgnum; /* tuple message number */
Instead of matching the entire message content as
classic LINDA concept, only one numeric identifier (KEY)
is used to identify a tuple in HEROS. The numeric
identifier and the type of tuple are statically assigned to
the local, shared or distributed buffer by users. The tuple
ring buffer is mapped into a byte array associated to a
tuple table. The message content may be accessed
immediately when a tuple is available. The runtime of
tuple template matching is short and deterministic in spite
of the numbers of etasks (threads).
In HEROS, all kinds of data exchanges, no matter
interior interactions (between components, i.e. etask and
thread) or exterior interactions (generally with external
peripherals, including sensors, actuator and a variety of
interface devices etc.) have been implemented via tuple.
B. IN/OUT operation Figure 7 System primitives-In()

The IN/OUT primitive-pair contains two main The reading tuple operation is allowed for etasks only
functions: data (msg, signal) exchange and transmission if data is available on tuple. An etask or thread reads data
via tuple; update the status and priority of etask/thread, from its related tuple by performing IN operation. IN
illuminated in Figure 6 and Figure 7. operation copies available data from the tuple to the
application and updates the tuple status. If data is not
available (tuple is free), the IN operation changes thread
state into ‘suspend’ state; initializes the two time
Copy Data into tuple buffer Tuple type?
attributes of TCB item; save the current thread context
into the thread stack and calls a new scheduling.
thread Implementing a system updating within the system
thread timeslice expires?
primitives may ensure a predictable and determinate
system scheduling with no concerning about the number
yes of components, which is the typical feature of hard real-
Update tuple state and thread / event state
Event No time system. Moreover, when the calling frequency of
Terminate thread
IN/OUT is lower than the system scheduling one, as
ENA_ALL_IRQ generally in most of WSN applications which has low
sampling frequency, the above-mentioned mechanism
return reduces the system workload significantly.
Insert thread/event into TCB/ECB ready
HEROS has been ported on ARM7TDMI-S
Update items of TCB/ECB ready list
architecture [17] based processors, including NXP
LPC21xx [18] and Atmel AT91SAM7S series [19]. This
Figure 6 System primitives-Out() section estimates the memory and power consumption of
HEROS, calculates the execution time of system
HEROS is a tuple-based hybrid multi-level system. primitives, evaluates the system latencies and finally
Each etask, no matter activated by a signal from timers, compares the performances of HEROS with TinyOS ones.
actuators and sensors or from other etasks, must be



A. Evaluation platform application) can run 16 hours in the normal mode,

The hardware evaluation platform is an ARM7TDMI- whereas in the low-power mode, the WSN node lifetime
S based 32-bit RISC architecture microcontroller: Atmel can be extended to more than 1 years.
AT91SAM7S256. The software development platform TABLE IV MEMORY AND POWER CONSUMPTION OF HEROS
adopts the IAR system EWARM embedded integrated
Memory Power consumption
development environment and J-Link JTAG simulator consumption (Lithium-Ion battery, 3.6V, 1800mAH)
[20]. The HEROS instance is configured with three etasks Code Data Normal Low-Power
(two active etasks and one daemon etask). The first etask (byte) (byte) Mode Mode
contains three threads and the second one has two threads. AT91SAM7S256 <50mA < 60μA
B. Memory and Power Consumption Chipcon Send <25mA
3572 1272 CC2340 Receive <27mA
Since HEROS is dedicated to strict resource- (ZigBee) Sleep <0.9μA
constrained embedded applications, it consumes tiny
Standby <0.6μA
resources. Table IV presents the memory and power Lifetime > 16 hours > 1 years
consumption of HEROS on ARM7 microcontroller.
HEROS can operate in several modes (event-driven, C. Performance of System Primitives
multi-threading or hybrid), having small footprint The numbers of instruction cycles of IN/OUT system
(<5Kbytes) comparing with most of RTOSs. Since both primitives on AT91SAM7S256 running at 48MHz are
ARM7 microcontroller and ZigBee RF transceiver evaluated, presented in Table V.
support multiple low-power operation modes, when no In the static configurable HEROS system, the
component running or no data transmitting, HEROS can execution time of system primitives is determined and
self-configure associated registers to set MCU or RF bounded between the minimal and maximal time.
transceiver to operate in low-power modes to reduce Moreover, the size of a tuple message is limited and
power consumption. Consequently sleep/wakeup predefined, the execution time of IN/OUT primitives are
technique may be applied in WSN node. In the case of thus predictable. The deterministic and predictable
the evaluation platform, the default power source is a behaviors of system primitives are the key features of a
3.6V (1800mAH) Lithium-Ion battery. The WSN system real-time operating system.
(a real-time continuous data sampling and transmitting

Cost (cycles) Time (μs)(48MHz)

Max Min Max Min
In 149+46n 95 3.101+0.957n 1.977
Operation: Read data from its associate tuple.
Max: data is available, reading n bytes from its related tuple and copying it into the user buffer.
Min: no data is available, calling the thread_scheduler function.
n: is the byte length of receiving data (n>0).
Out 104+32n+ 104+32n+ 2.164+0.666n+ 2.164+0.666n+ Cycleenquen_thread
Cycleenquen_event Cycleenque_thread Cycleenquen_event
Operation: Send data into its related tuple, insert an item into the etask/thread queue and resort the queue.
Max: send data into an etask tuple, and insert the related etask into the etask ready queue.
Min: send data into a thread tuple, and insert the related thread into the thread ready queue.
n: is the byte length of sending data (n>0).

Cost (cycles) Time (μs)(48Mhz)

Min Avg Max Min Avg Max
90 1.873
etask-to-etask switch
Call etask_manager routine to run next ready etask.
The native thread of next etask is called in the ‘cold’ start-up mode
891 (992) 1.8521 (2.062)
thread-to-thread switch Call thread_scheduler routine to run next ready thread of current etask
latency : Next running thread of this etask is called in the ‘cold’ start-up mode
: Next running thread of this etask is called in the ‘warm’ start-up mode
Interrupt Response
29 107 247 0.604 2.227 5.140
32 68 176 0.666 1.415 3.662
There are three possibilities for the interrupt dispatch operations after the ISR has exited:
Interrupt Dispatch Latency − Return back to the interrupted function.
− Call etask_manager to start etask scheduling
− Call thread_scheduler to start thread scheduling



TinyOS kernel. Note that in order to support real-time

D. System latencies
multitask modes, HEROS has more system overheads
For a real-time operating system, the system than TinyOS but has similar system cycles for the basic
scheduling scheme and the interrupt handling mechanism system operations.
are time-critical, so they must be short and deterministic.
Several system latencies are used to evaluate the VI. CONCLUSION AND PERSPECTIVE
performances of HEROS system scheduling and interrupt
handling [21]. Since HEROS adopts action-etask-thread HEROS is a smart, resource-aware, low-energy and
structure, therefore there are two latencies that can be distributed real-time micro-kernel, adopting the action-
used to quantify system scheduling scheme. etask-thread component-based multi-level system
− etask-to-etask switch latency: time for switching architecture. As the result of multi-level structure,
etask from one to another. This scheduling operation HEROS adopts a two-level scheduling policy: ‘non pre-
is performed in etask_manager. There is no context- emption priority’ scheduling for etasks and ‘preemptive
switch in etask-to-etask switch. priority’ scheduling for threads. The scheduling scheme
− thread-to-thread switch latency: time for switching is predictable and deterministic with respect to the real-
thread from one to another. This scheduling time applications. A unique system interface and a system
operation is performed in thread_scheduler. There is primitive-pair, i.e. tuple and IN & OUT, are proposed for
one time context-switch in thread-to-thread switch. system synchronization and communication. HEROS
Moreover, the interrupt latencies are expected to be integrate the advantages of TinyOS and SDREAM. It can
finite and will never exceed a predefined maximum time. be running at different modes: event-driven, multi-tasking
Two latencies are used to rate the performance of the and hybrid. The combination of two kernels greatly
interrupt handling mechanism: extends the application range of HEROS from simple
− Interrupt Response Latency: time elapsed from the single-task to multi-task applications.
last instruction of the interrupted component to the At present, HEROS has been ported on the LiveNode
first instruction in the IRQ. This value indicates the hardware platform [23] developed by the University of
system reaction to external interrupts. Blaise Pascal (France), see in Figure 8. The LiveNode is
− Interrupt Dispatch Latency: time elapsed from the a specific WSN node may be used in variety of WSN
last instruction in the IRQ to the next thread applications, including data collection, object tracking,
scheduled to run. This indicates the time needed to inter vehicle communication and health care, etc. For the
switch from interrupt mode to user mode. future work, we plan to further improve HEROS at the
The evaluation results of system switch latencies and following aspects:
interrupt latencies are presented in Table VI. The − GUI: Develop a component based graphical user
obtained results show that HEROS has deterministic and interface to ease application implementation,
short system switch/interrupt latencies satisfying the − 6LoWPAN: Port 6LoWPAN embedded with a
requirements of most of real-time applications. Note that dedicated routing protocol (CIVIC) and evaluates its
the latencies of system switch are fixed with no concern performance comparing with TinyOS and Contiki
of the numbers of etask (thread). ones.
− Fault-tolerant system: has the ability to continue
E. Performance comparison normal operation despite the presence of hardware
HEROS has been tested on AT91SAM7S256 (48Mhz or software faults (except for physical destruction).
clock frequency) and TinyOS has been tested on − Low-energy system: Improving the system energy
ATmega128 (4MHz clock frequency) [22]. This paper efficiency by introduce resource and energy aware
only compares three system operations: scheduling a task, metrics in etask and thread scheduling.
context switch and hardware interrupt. The cost of task − Distributed cooperative system: has the ability of
scheduling indicates the overhead of the thread scheduler parallel operations on a set of processors or multi-
function. The operation of context switching happens cores of one chip (NoC). The LINDA idea makes
between the two threads of the same etask (‘warm’ mode). HEROS suitable for a distributed system.
Zigbee Antenna
(AT91SAM7S256) (ATmega128) Battery
Cost Time Cost Time
(cycle) (μs) (cycle) (μs) Arm7
Scheduling a task 43 0.895 46 11.5
Context Switch 56 1.165 51 12.75
Hardware Interrupt (hw) 5 0.104 9 2.25
Hardware Interrupt (sw) 61 1.269 71 17.75
OS Size (byte) GPS GPS
CODE 3572 1272 Antenna
DATA 432 48 Figure 8 LiveNode hardware platform
Table VII presents the overheads of system operations
and the memory consumption between HEROS and



ACKNOWLEDGEMENT [22] W. Maurer, “The Scientist and Engineer’s Guide to TinyOS

Programming,” Technical Document,,
We would like to thank the Conseil Régional 2004.
d’Auvergne, French government and EU for their support [23] K.M.Hou et al., “LiveNode: LIMOS versatile embedded
of this project (NeT-ADDED, PFCC), to thank the wireless sensor node,” Journal of Harbin Institute of
colleagues of the SMIR and FTCL groups for their helps. technology, vol(32), pp.139-144, Oct. 2007.
Moreover, we gracefully acknowledge all the anonymous
reviewers for their valuable advices and suggestions,
Hai-ying Zhou is associate professor of
allowing improving the material of this paper.
computer science at school of computer
science, Harbin Institute of Technology,
REFERENCES China. He was a postdoctoral researcher at
[1] H.Y.Zhou, K.M.Hou and C. de Vaulx, “SDREAM: A the institute of Cemagref (UR TSCF/UMR
Super-small Distributed REAl-time Microkernel dedicated TETIS) and the laboratory of LIMOS
to wireless sensors,” Journal of PERVASIVE COMPUT. & (UMR CNRS 6158) from 2005 to 2007. He
COMM, vol. 4(2), pp.398-410, 2006. was born in 1975, received his B.E. and
[2] J.J. Labrosse, “MicroC/OS-II, The Real-time Kernel, R & M.E. degrees in Electronic Engineering
D Books,” Technical Document; Oct. 1998. from Wuhan university, China in 1997 and 1999, and PH.D. in
[3] Dedicated Systems Magazine, “VxWorks/x86 5.3.1 Computer Science from university Blaise Pascal, France in
evaluation,”, 2000. 2004. His current research interests are in the areas of
[4] Dedicated Systems Magazine, “QNX4.25 Evaluation embedded computing, mobile computing, operation system and
Executive Summary,”, wireless sensor networks.
[5] Dedicated Systems Magazine, “PSOS 2.2.6 Evaluation
Executive Summary,”, Kun-Mean Hou received his ‘diplôme
2000. d’ingénieur’ in Biomedical Instrument
[6] LynuxWorks Inc., “Lynxos 4.0: the world’s most powerful, engineering and M.Sc in Computer science
open-standards rtos,”, in 1982, and Ph.D. in computer science in
2002. 1984 respectively from University of
[7] Victor Yodaiken, “An Introduction to RTLinux,” Technical Technology of Compiègne, France. He
Document, New Mexico Institute of Technology, Oct. worked at University of Technology of
1997. Compiègne as associate professor from
[8] Microsoft Corporation, “Which to choose: Evaluating 1984 to 1987. From1987 to 1989, he has
Microsoft windows CE.NET and windows XP embedded,” been working as project leader with IN2. In 1989 he joined
Technical Report, Microsoft Corporation, 2001. University of Technology of Compiègne as group leader,
[9] Dedicated Systems Magazine, “RTX4.2 evaluation execute involved in research related to real-time parallel computer
Summary,”, 2000. architecture dedicated to image and signal processing. Since
[10] Dedicated Systems Magazine, “Hyperkernel4.3 evaluation 1997, he has been professor at the University of Blaise Pascal
execute Summary,”, (Clermont-Ferrand, France). His current major research interests
2000. are in the areas of pervasive computing, wireless sensor
[11] P. Levis et al., “Tinyos: an operating system for sensor networks, operating system and SOC/NOC.
networks,” Ambient Intelligence, pp.115-148, 2005.
[12] C.L Liu and J.W.Layland, “Scheduling Algorithms for
Multiprogramming in a Hard Real-Time Environment,” Christophe DE Vaulx received his Ph.D.
Journal of the ACM, vol. 20(1), pp. 46-61,1973. in computer science from Blaise Pascal
[13] A.D.Gelernter, “Generative communication in LINDA,” University of Clermont-Ferrand II (France)
ACM Transactions on Programming Languages and in 2003. He did postdoctoral research at the
Systems, vol.7(1),pp. 80-112,1985. Computer Science Laboratory (LIMOS) of B.
[14] A.I. Taylor Rowstron, “Bulk Primitives in LINDA run-time Pascal University from 2004 to 2005. Now,
systems,” Ph.D thesis; University of York, Oct. 1996. he is an associate professor at the
[15] E. Yao, “Real-time Multiprocess Kernel: Hierarchical Engineering Sciences Institute (CUST) of
LINDA,” Proceedings of ICSPAT, 1993. Blaise Pascal University. His current
[16] P.A.Laplante, “Real-time systems design and analysis: an research areas are fault tolerance and distributed real-time
engineer's handbook,” Wiley & IEEE Press, 3rd ed. 2004. systems.
[17] ARM Ltd., “ARMTDMI-S technical reference manual
(v4),” Technical Document, 2001.
[18] Atmel Ltd., “AT91SAM7S-EK Evaluation Board User De-Cheng Zuo is professor of computer
Guide,” Technical Document, 2006. science at school of computer science,
[19] NXP Ltd., “LPC214x User Manual,” Technical Document, Harbin Institute of Technology, China. He
2005. was born in 1972, received his B.E. degree in
[20] IAR Ltd., “ARM IAR Embedded Workbench IDE User physics from Jilin university, China in 1994,
Guide,” Technical Document, 2006. M.E. and PH.D. degrees in Computer
[21] K. Singh, “Design and Evaluation of an Embedded Real- Science from Harbin institute of Technology
time Microkernel,” Master thesis, Faculty of the Virginia in 1996 and 2000. His current research
Polytechnic Institute and State University, 2002. interests are in the areas of include fault-
tolerant computing and mobile computing.