428
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
1
:School of Computer Science & Technology, Harbin Institute of Technology, Harbin, China
Email: {haiyingzhou, zdc}@hit.edu.cn
2
:LIMOS Laboratory UMR 6158 CNRS, University of Blaise Pascal, Clermont-Ferrand, France
Email: kun-mean.hou@isima.fr, christophe.devaulx@cust.univ-bpclermont.fr
Abstract—Traditional operating systems for wireless sensor
networks (WSN) are based on either event-driven or
multitask concept. Instead, this paper presents an embedded
real-time operating system, named HEROS ‘Hybrid
Embedded Real-time Operating System’, which is
configurable to run in different modes: event-driven,
multitask or hybrid to adapt to diverse domains of WSN
applications. HEROS adopts a modular and hierarchical
architecture: action (system operation), thread (component)
and event (etask) and provides a predictable and
deterministic scheduling mechanism: ‘non pre-emption
priority based’ scheduling for events and ‘pre-emptive
priority-based’ scheduling for threads. Furthermore, to ease
distributed cooperative application, HEROS adopts LINDA
concept by providing a simplified tuple space and a
lightweight IN/OUT primitive-pair to implement system
communication & synchronization. Currently, HEROS has
been implemented and evaluated in different applications
and on different platforms. The experimentation results
show that HEROS has a small footprint and meets different
real-time application requirements.
Index Terms—real-time multitask, event-driven, tuple and
In/Out, wireless sensor network
I. INTRODUCTION
Real-time operating system plays a key role for
embedded system even more for WSN due to resource
constraints. So designing an energy efficient operating
system dedicated to WSN which meets the requirements
of all the real-time applications is still an open problem
and a challenge.
Due to resource constraints of WSN node and its
diverse application domains, the key features of WSN
operating systems (WSNOS) should be resource-aware
and be configurable to adapt to each situation. Note that
most of traditional embedded RTOSs such as
SDREAM8[1], µC/OS-II[2], VxWorks[3], QNX[4],
pSOS[5], Lynxos[6], RTLinux[7], WinCE.NET[8],
RTX[9] and HyperKernel[10] are unfit for WSN as they
are resource consuming. On the other hand, the event-
driven operating systems are essentially single task
Supported by Doctoral Fund of Youth Scholar of Ministry of Education
of China (No.200802131024), French Program of Cooperation with
China (No.20974WG), and Scientific Research Fund of Returned
Oversea Scholars of Harbin city of China (No.RC2009LX010001).
© 2009 ACADEMY PUBLISHER
JOURNAL OF NETWORKS, VOL. 4, NO.
systems. Consequently, they are not met the requirement
of complex hard real-time applications, e.g. TinyOS[11].
Therefore, our objective is to design a configurable real-
time dedicated WSNOS, which enables to adapt to an
application to minimize resource consuming (memory
footprint and power).
The paper is organized as following: section II
describes HEROS system architecture; section III details
the scheduling mechanism and section IV presents the
system communication & synchronization mechanism;
section V illustrates and discusses HEROS performance.
Finally, we present the conclusion and the ongoing work.
II. SYSTEM ARCHITECTURE
By combining event-driven and multitask concepts,
HEROS adopts component-based multi-level system
architecture: action, thread and event. In HEROS, the
minimal system element is termed as ‘action’ that
responds to the basic system operation, such as ‘read’,
‘write’, ‘schedule’, etc. A thread is a component that
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
etask is similar to event in TinyOS.
A. Event-thread-action structure
Action: is a minimal system executing element, which
contains a set of CPU instructions. In HEROS there are
two classes of action: system action (hardware-dependent)
and function action (hardware-independent). For example
in the case of a WSN application (sensing process), four
types of actions may be considered: ‘read’ operation (data
collection), ‘analyze’ operation (processing), ‘write’
operation (sending results) and coordinate task operation
(thread/event scheduling), see in Figure 1. The basic
actions have been implemented and stored into the action
library. A thread calls an action like calling a function
from library. Since action hides the differences of
hardware devices and provides a uniform calling interface
for components, system designers can thus focus on
application development without care about hardware-
dependent operations.
Thread: is the component which is a light process or
task, and interacts only with other components within the
same etask. Threads share resources within the etask and
JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009
communicate with each other through a shared tuple
space. Threads run in concurrence or in parallel to
perform an etask. Hence, a thread is interruptible and pre-
emptive, so it needs private stack to save its “context”.
Note that sharing resources within the same etask reduces
system overheads and also decreases costs of system
resources.
Etask: represents an independent job having at least
one thread. An etask is interruptible but not pre-emptible
and it is based on event-driven concept. An etask is
activated only after receiving a trigger signal. In HEROS
each etask can be associated with one and only one input
event and n output events (0<n≤Max). In terms of the
regularity of occurrences, etasks are divided into two
classes:
 Periodic etask: typically suitable for regular data
sampling issued from sensors or for monitoring
actuators, which occur under fixed rate.
 Sporadic etasks: typically suitable for strict time-
constraint tasks, which occur sporadically and can
be used to deal with the critical issues.
Architecture: a thread is composed of a set of actions
and a set of components is an etask. The hierarchy
architecture of HEROS is shown in Figure 1.
Figure 1 Hierarchy architecture based on action, thread and etask
An etask can be viewed as a finite state automaton (see
in Figure 2). Once being triggered by an event (signal),
the etask is activated and its threads start to be executed.
Etasks receive/send a signal by calling IN/OUT
primitives via the related tuple. An etask is a set of
threads which operate concurrently and cooperatively.
Threads adopt the same mechanism as etask for inter-
thread communication and synchronization.
Figure 2 Automaton model of Etask/Thread structure
Denoting ℜ is a HEROS instance, ε is an etask, τ is a
thread, α is an action and ς is a signal. The ‘ → ’ symbol
denotes precedence sequential operation and ‘ ∥ ’
represents the concurrent or parallel operation. HEROS
architecture is expressed as follows:
© 2009 ACADEMY PUBLISHER
429
ℜ = {ε i : i = 1,2, , n; ε1 → ε 2  → ε n };
{ }
ε i = τij : j = 1,2,  m i ; τi1 τi 2  τimi ; (1)
{ }
τij = α ijk : k = 1,2,Sij ; α ij1 → α ij2  → α ijSij .
HEROS can be configured to run independently in
event-driven, multitask and hybrid modes. Considering
two extreme-case scenarios: if ℜ has only one etask, i.e.
n=1, HEROS runs in the multitask mode like any
traditional multitask operating system; while if each etask
has only one thread, i.e. ∀mi=1, i∈{1,…, j}, HEROS
operates as a pure event-driven mode like TinyOS.
B. Event-/thread-control Block
HEROS defines two table structures, named as etask
control block (ECB) and thread control block (TCB), to
store etask and thread descriptors, shown in Table I. Each
data structure contains at least an identification flag
(string or number), a priority, a status, and a related tuple
ID. Each structure has a specific attribute to indicate its
affiliation relation: the sub-TCBs list pointer of ECB and
the etask ID of TCB. Each structure also includes a time
value to describe the absolute deadline and the allowable
time-slice. For a thread, the deadline value is used to
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.
TABLE I DATA STRUCTURE OF ETASK/THREAD CONTROL BLOCK
ECB TCB
Etask ID Thread ID
Etask Priority Thread Priority
Etask Status Thread Status
Etask Tuple ID Thread Tuple ID
Related TCB list Related Etask ID
Absolute Deadline Absolute Deadline
Timeslice Timeslice
Start Stack Address (SSP)
Current Stack Address (CSP)
C. Etask/thread states
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’.
It should be noted that, according to the features of the
static pre-configuration and the determinate numbers of
etask (threads), HEROS can combine the predefined
‘terminate’ and ‘sleep’ states into an ‘idle’ state. Thus an
etask or thread enters the ‘idle’ state after it has finished
execution, but the etask resource is not released and the
etask will be activated by the next signal.
430
Figure 3 An event and thread state diagram
III. SYSTEM SCHEDULING
In order to meet the requirements of hard real-time
applications, it is indispensible that the operating system
should produce a predictable schedule. It means that at all
times it should be known which task is going to be
executed. With the etask (thread) system architecture,
HEROS offers two-level dynamic-priority scheduling:
‘non-preemptive-priority’ for etask at high level and
‘preemptive-priority’ for threads at low level.
A. Scheduling Algorithm
Etask scheduling: adopts the priority-based non-
preemptive scheduling and I/O devices are interrupt-
driven. An etask is elected to run according to its priority
and an active etask runs to completion without any pre-
emption. At any instant when an etask terminated, the
etask scheduling is activated to elect the next etask to run.
This scheme is a dynamic-priority scheduling, like
earliest-deadline-first (EDF) algorithm [12]: the etask
with earliest deadline has the highest priority.
Note that etasks are interruptible. When an interrupt
occurs, its ISR stores the message (msg) or signal and
then sends it to the related tuple buffer by calling the
OUT primitive. The corresponding operation will be
reacted only after the active etask has run to completion.
Meanwhile, the OUT primitive updates the attribute
values of the etask, including status, time-slice, and also
revaluates the priorities of all ready events according to
the scheduling scheme.
For a periodic etask, suppose Di, (relative deadline)
equal pi (its period); while for a sporadic etask, the
system allocates a maximum allowable response time (Di)
when the etask occurs. This paper assumes that all etasks
are periodic and independent (a sporadic etask can be
regarded as the first instance of a periodic etask), the
relative deadline of an etask is its period, etasks are pre-
emptible and their preemption time is neglected.
Defining ri,k and di,k are the release or arrival time and
the absolute deadline of kth instance of etask εi; Di is the
relative deadline of etask εi, which equals its period pi; φi
is the phase of etask εi, which equals to ri,1, then
ϕi = ri ,1 , ri , k = ϕi + (k − 1) * pi (2)
d i , k = ri , k + Di = ϕi + k * pi
© 2009 ACADEMY PUBLISHER
JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009
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:
 If a thread (τi0) is the successor thread of an etask εi,
then τi0 has the highest priority within the threads of
the etask εi;
 Each thread has a unique input tuple, in which the
thread reads msg from other threads or etasks.
 If a thread τi,j waits a msg coming from other thread
τi,j-1 on its tuple, τi,j thus has the lower priority than
that of τi,j-1, and so on.
Threads are interruptible and preemptive. A thread
interacts with others via the tuple space by calling the
IN/OUT primitive-pair. When a thread sends a message
or signal to the tuple space, the OUT primitive is called to
change the state of the related tuple from ‘idle’ or
‘suspend’ to ‘ready’. Moreover, the time-slice value of
each item of TCB suspend list is reevaluated in view of
the current timeslot and the deadline value.
A.3 Etaskt-to-thread jump: The following theorem gives
the condition under which a feasible schedule exists
under the EDF scheme.
If a HEROS instance consists of periodic etasks and
meets (3), its etask/thread scheduling scheme can be
predictable. If the execution time of etask is deterministic
and transient, HEROS can be considered as a soft real
time system. But for hard real-time etasks, generally
caused by sporadic etasks, which need to be reacted
within a strict time-constrained deadline, the above-
defined scheduling scheme does not always meet the
requirement if equation (4) cannot be satisfied.
Theorem [EDF Bound][12]: A set of n periodic etasks, each of
whose relative deadline equals its period, can be feasibly scheduled by
EDF if and only if
n
 (e / p ) ≤ 1
i =1
i i
(3)
Where ei is the periodic etaski run time and pi is the
etaski period. Let εs and εp be the sporadic etask and the
active periodic etask respectively, Ds and es be the
relative deadline and the execution time of εs, and ep be
the expected time from the interrupted instant to the
completed instant of εp, where 0<ep≤ei. Then the feasibly
of the sporadic etask εs meets its deadline is that
Ds < e p + es (4)
Note that since the execution time of ISR related to the
sporadic etask εs is very short and deterministic, it is thus
JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009
ignored. If equation (4) is not met, therefore, the etask εs
miss its deadline and then the system enters an
unexpected exceptional status. To ensure in this worst-
case scenario the sporadic etask can be handled with short
response time to meet its deadline, the special etask-to-
thread jump mechanism is proposed: the sporadic etask εs
is treated as the highest priority thread τs of current
periodic etask εp, so that τs can preempt any other active
thread of εp according to the thread scheduling scheme.
The etask-to-thread jump mechanism breaks down the
obstacle between threads and etasks, allowing the threads
of an urgent etask to preempt the CPU resource.
Let Ρ(ε) and Ρ(τ) be the priorities of etasks and threads,
then when an etask-to-thread jump occurs, the priorities
of the threads of the etasks (εs and εp) is:
Ρ(ε ) = Ρ(ε ) + Ρ(τ ) / 10 (5)
Note that HEROS quantifies the priority of etasks and
threads between 0 and 10. Since the sporadic etask has
higher priority than the active etask, that is, Ρεs>Ρεp, then
the threads of εs have higher priority than those of εp, so
that they can preempt the CPU resources.
B. Scheduling program
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
(etask only) and ECB/TCB list sorting according to
priority and etask-to-thread operation (optional), will be
executed when calling IN/OUT primitives. Two global
variables, i.e. current_etask and current_thread, are
defined to indicate current active etask and thread.
Figure 4 System scheduling mechanism
© 2009 ACADEMY PUBLISHER
431
Figure 4 shows that this scheduling scheme is smart
and predictable, and has deterministic execution time
independent of the numbers of etasks (threads). Note that
the top item of ECB ready lists or TCB lists is the one
with the highest priority, which has been elected and
sorted by the rules of the scheduling scheme in the
IN/OUT system primitive-pair.
A HEROS instance composing of a set of etasks
(threads) is presented in Table II and illustrated in Figure
5. The periodic etasks, i.e. ε1 and ε2, are released at time 0,
and the sporadic etask εs occurs at time 3. Since the etask
ε1 has the smallest period, it is the highest priority etask to
start and thus it is elected to run first. At time 3, the etask
εs is released. At this point, consider ep=2, es=1 and Ds=2,
equation (4) does not meet, and the jump function is thus
called to perform an etask-to-thread jump. At time 5*k
and 7*k, the kth instances of ε1 and ε2 are released
respectively.
TABLE II SAMPLE ETASK/THREAD SET FOR THE SCHEDULER
εi ri ei pi τi
ε1 0 2 5 τ11, τ12
ε2 0 3 7 τ21, τ22, τ23
εs 3 1 2 τs
Figure 5 An instance of etask/thread two-level scheduling
IV. SYSTEM COMMUNICATION& SYNCHRONISATION
The interactions between system components are
essential to provide system communication and
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
special data structure called a circular queue or ring
432 JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009

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
TABLE III DATA STRUCTURE OF TUPLE_TABLE
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
functions: data (msg, signal) exchange and transmission
via tuple; update the status and priority of etask/thread,
illuminated in Figure 6 and Figure 7.
Out
Copy Data into tuple buffer
DIS_ALL_IRQ
thread timeslice expires?
Update tuple state and thread / event state
Event
Terminate thread
ENA_ALL_IRQ
Insert thread/event into TCB/ECB ready
list
Update items of TCB/ECB ready list
Figure 6 System primitives-Out()
HEROS is a tuple-based hybrid multi-level system.
Each etask, no matter activated by a signal from timers,
actuators and sensors or from other etasks, must be
The reading tuple operation is allowed for etasks only
if data is available on tuple. An etask or thread reads data
from its related tuple by performing IN operation. IN
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
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
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-
No time system. Moreover, when the calling frequency of
IN/OUT is lower than the system scheduling one, as
generally in most of WSN applications which has low
sampling frequency, the above-mentioned mechanism
return reduces the system workload significantly.
V. PERFORMANCE EVALUTION
HEROS has been ported on ARM7TDMI-S
architecture [17] based processors, including NXP
LPC21xx [18] and Atmel AT91SAM7S series [19]. This
section estimates the memory and power consumption of
HEROS, calculates the execution time of system
primitives, evaluates the system latencies and finally
compares the performances of HEROS with TinyOS ones.

© 2009 ACADEMY PUBLISHER

 JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009 433

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
(48MHz)
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
TABLE V PERFORMANCE EVALUATION OF SYSTEM PRIMITIVES

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

Operations
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).
TABLE VI PERFORMANCE EVALUATION OF SYSTEM LATENCIES

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

Latencies
Min Avg Max Min Avg Max
90 1.873
etask-to-etask switch
Call etask_manager routine to run next ready etask.
latency
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
1
latency : Next running thread of this etask is called in the ‘cold’ start-up mode
2
: 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
Latency
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

© 2009 ACADEMY PUBLISHER

434
D. System latencies
For a real-time operating system, the system
scheduling scheme and the interrupt handling mechanism
are time-critical, so they must be short and deterministic.
Several system latencies are used to evaluate the
performances of HEROS system scheduling and interrupt
handling [21]. Since HEROS adopts action-etask-thread
structure, therefore there are two latencies that can be
used to quantify system scheduling scheme.
− etask-to-etask switch latency: time for switching
etask from one to another. This scheduling operation
is performed in etask_manager. There is no context-
switch in etask-to-etask switch.
− thread-to-thread switch latency: time for switching
thread from one to another. This scheduling
operation is performed in thread_scheduler. There is
one time context-switch in thread-to-thread switch.
Moreover, the interrupt latencies are expected to be
finite and will never exceed a predefined maximum time.
Two latencies are used to rate the performance of the
interrupt handling mechanism:
− Interrupt Response Latency: time elapsed from the
last instruction of the interrupted component to the
first instruction in the IRQ. This value indicates the
system reaction to external interrupts.
− Interrupt Dispatch Latency: time elapsed from the
last instruction in the IRQ to the next thread
scheduled to run. This indicates the time needed to
switch from interrupt mode to user mode.
The evaluation results of system switch latencies and
interrupt latencies are presented in Table VI. The
obtained results show that HEROS has deterministic and
short system switch/interrupt latencies satisfying the
requirements of most of real-time applications. Note that
the latencies of system switch are fixed with no concern
of the numbers of etask (thread).
E. Performance comparison
HEROS has been tested on AT91SAM7S256 (48Mhz
clock frequency) and TinyOS has been tested on
ATmega128 (4MHz clock frequency) [22]. This paper
only compares three system operations: scheduling a task,
context switch and hardware interrupt. The cost of task
scheduling indicates the overhead of the thread scheduler
function. The operation of context switching happens
between the two threads of the same etask (‘warm’ mode).
TABLE VII PERFORMANCE COMPARISON BETWEEN HEROS AND
TINYOS
HEROS TinyOS
(AT91SAM7S256) (ATmega128)
Operations
Cost Time Cost Time
(cycle) (μs) (cycle) (μs)
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)
CODE 3572 1272
DATA 432 48
Table VII presents the overheads of system operations
and the memory consumption between HEROS and
© 2009 ACADEMY PUBLISHER
JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009
TinyOS kernel. Note that in order to support real-time
multitask modes, HEROS has more system overheads
than TinyOS but has similar system cycles for the basic
system operations.
VI. CONCLUSION AND PERSPECTIVE
HEROS is a smart, resource-aware, low-energy and
distributed real-time micro-kernel, adopting the action-
etask-thread component-based multi-level system
architecture. As the result of multi-level structure,
HEROS adopts a two-level scheduling policy: ‘non pre-
emption priority’ scheduling for etasks and ‘preemptive
priority’ scheduling for threads. The scheduling scheme
is predictable and deterministic with respect to the real-
time applications. A unique system interface and a system
primitive-pair, i.e. tuple and IN & OUT, are proposed for
system synchronization and communication. HEROS
integrate the advantages of TinyOS and SDREAM. It can
be running at different modes: event-driven, multi-tasking
and hybrid. The combination of two kernels greatly
extends the application range of HEROS from simple
single-task to multi-task applications.
At present, HEROS has been ported on the LiveNode
hardware platform [23] developed by the University of
Blaise Pascal (France), see in Figure 8. The LiveNode is
a specific WSN node may be used in variety of WSN
applications, including data collection, object tracking,
inter vehicle communication and health care, etc. For the
future work, we plan to further improve HEROS at the
following aspects:
− GUI: Develop a component based graphical user
interface to ease application implementation,
− 6LoWPAN: Port 6LoWPAN embedded with a
dedicated routing protocol (CIVIC) and evaluates its
performance comparing with TinyOS and Contiki
ones.
− Fault-tolerant system: has the ability to continue
normal operation despite the presence of hardware
or software faults (except for physical destruction).
− Low-energy system: Improving the system energy
efficiency by introduce resource and energy aware
metrics in etask and thread scheduling.
− Distributed cooperative system: has the ability of
parallel operations on a set of processors or multi-
cores of one chip (NoC). The LINDA idea makes
HEROS suitable for a distributed system.
Zigbee Antenna
Battery
Arm7
GPS GPS
Antenna
Figure 8 LiveNode hardware platform
JOURNAL OF NETWORKS, VOL. 4, NO. 6, AUGUST 2009
ACKNOWLEDGEMENT
We would like to thank the Conseil Régional
d’Auvergne, French government and EU for their support
of this project (NeT-ADDED, PFCC), to thank the
colleagues of the SMIR and FTCL groups for their helps.
Moreover, we gracefully acknowledge all the anonymous
reviewers for their valuable advices and suggestions,
allowing improving the material of this paper.
REFERENCES
[1] H.Y.Zhou, K.M.Hou and C. de Vaulx, “SDREAM: A
Super-small Distributed REAl-time Microkernel dedicated
to wireless sensors,” Journal of PERVASIVE COMPUT. &
COMM, vol. 4(2), pp.398-410, 2006.
[2] J.J. Labrosse, “MicroC/OS-II, The Real-time Kernel, R &
D Books,” Technical Document; Oct. 1998.
[3] Dedicated Systems Magazine, “VxWorks/x86 5.3.1
evaluation,” http://www.dedicated-systems.com, 2000.
[4] Dedicated Systems Magazine, “QNX4.25 Evaluation
Executive Summary,” http://www.dedicated-systems.com,
2000.
[5] Dedicated Systems Magazine, “PSOS 2.2.6 Evaluation
Executive Summary,” http://www.dedicated-systems.com,
2000.
[6] LynuxWorks Inc., “Lynxos 4.0: the world’s most powerful,
open-standards rtos,” http://www.lynuxworks.com/rtos,
2002.
[7] Victor Yodaiken, “An Introduction to RTLinux,” Technical
Document, New Mexico Institute of Technology, Oct.
1997.
[8] Microsoft Corporation, “Which to choose: Evaluating
Microsoft windows CE.NET and windows XP embedded,”
Technical Report, Microsoft Corporation, 2001.
[9] Dedicated Systems Magazine, “RTX4.2 evaluation execute
Summary,” http://www.dedicated-systems.com, 2000.
[10] Dedicated Systems Magazine, “Hyperkernel4.3 evaluation
execute Summary,” http://www.dedicated-systems.com,
2000.
[11] P. Levis et al., “Tinyos: an operating system for sensor
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,”
Journal of the ACM, vol. 20(1), pp. 46-61,1973.
[13] A.D.Gelernter, “Generative communication in LINDA,”
ACM Transactions on Programming Languages and
Systems, vol.7(1),pp. 80-112,1985.
[14] A.I. Taylor Rowstron, “Bulk Primitives in LINDA run-time
systems,” Ph.D thesis; University of York, Oct. 1996.
[15] E. Yao, “Real-time Multiprocess Kernel: Hierarchical
LINDA,” Proceedings of ICSPAT, 1993.
[16] P.A.Laplante, “Real-time systems design and analysis: an
engineer's handbook,” Wiley & IEEE Press, 3rd ed. 2004.
[17] ARM Ltd., “ARMTDMI-S technical reference manual
(v4),” Technical Document, 2001.
[18] Atmel Ltd., “AT91SAM7S-EK Evaluation Board User
Guide,” Technical Document, 2006.
[19] NXP Ltd., “LPC214x User Manual,” Technical Document,
2005.
[20] IAR Ltd., “ARM IAR Embedded Workbench IDE User
Guide,” Technical Document, 2006.
[21] K. Singh, “Design and Evaluation of an Embedded Real-
time Microkernel,” Master thesis, Faculty of the Virginia
Polytechnic Institute and State University, 2002.
© 2009 ACADEMY PUBLISHER
435
[22] W. Maurer, “The Scientist and Engineer’s Guide to TinyOS
Programming,” Technical Document, http://ttdp.org/tpg/,
2004.
[23] K.M.Hou et al., “LiveNode: LIMOS versatile embedded
wireless sensor node,” Journal of Harbin Institute of
technology, vol(32), pp.139-144, Oct. 2007.
Hai-ying Zhou is associate professor of
computer science at school of computer
science, Harbin Institute of Technology,
China. He was a postdoctoral researcher at
the institute of Cemagref (UR TSCF/UMR
TETIS) and the laboratory of LIMOS
(UMR CNRS 6158) from 2005 to 2007. He
was born in 1975, received his B.E. and
M.E. degrees in Electronic Engineering
from Wuhan university, China in 1997 and 1999, and PH.D. in
Computer Science from university Blaise Pascal, France in
2004. His current research interests are in the areas of
embedded computing, mobile computing, operation system and
wireless sensor networks.
Kun-Mean Hou received his ‘diplôme
d’ingénieur’ in Biomedical Instrument
engineering and M.Sc in Computer science
in 1982, and Ph.D. in computer science in
1984 respectively from University of
Technology of Compiègne, France. He
worked at University of Technology of
Compiègne as associate professor from
1984 to 1987. From1987 to 1989, he has
been working as project leader with IN2. In 1989 he joined
University of Technology of Compiègne as group leader,
involved in research related to real-time parallel computer
architecture dedicated to image and signal processing. Since
1997, he has been professor at the University of Blaise Pascal
(Clermont-Ferrand, France). His current major research interests
are in the areas of pervasive computing, wireless sensor
networks, operating system and SOC/NOC.
Christophe DE Vaulx received his Ph.D.
in computer science from Blaise Pascal
University of Clermont-Ferrand II (France)
in 2003. He did postdoctoral research at the
Computer Science Laboratory (LIMOS) of B.
Pascal University from 2004 to 2005. Now,
he is an associate professor at the
Engineering Sciences Institute (CUST) of
Blaise Pascal University. His current
research areas are fault tolerance and distributed real-time
systems.
De-Cheng Zuo is professor of computer
science at school of computer science,
Harbin Institute of Technology, China. He
was born in 1972, received his B.E. degree in
physics from Jilin university, China in 1994,
M.E. and PH.D. degrees in Computer
Science from Harbin institute of Technology
in 1996 and 2000. His current research
interests are in the areas of include fault-
tolerant computing and mobile computing.