Escolar Documentos
Profissional Documentos
Cultura Documentos
6, AUGUST 2009
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
ECB TCB
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.
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
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 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
Out
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
DIS_ALL_IRQ
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
list
V. PERFORMANCE EVALUTION
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