A Real-Time Kernel for Wireless Sensor Networks ... - CiteSeerX

The 4th IEEE International Workshop on Practical Issues In Building Sensor Network Applications (SenseApp 2009) Zürich, Switzerland; 20-23 October 2009

A Real-Time Kernel for Wireless Sensor Networks Employed in Rescue Scenarios Heiko Will

Kaspar Schleiser Jochen Schiller Institute of Computer Science Computer Systems and Telematics Freie Universität Berlin, Germany {hwill, schleise, schiller}@inf.fu-berlin.de

Abstract—In rescue scenarios, real-time requirements cannot be implemented as an addon to an existing system are one key issue when using wireless sensor networks because they affect every part of a system like timer (WSNs) for tracking and monitoring of rescue forces. If a architecture and routing protocols [2]. node detects an alarm condition, the alarm message must In this paper, we present the FireKernel microkernel be delivered to the base station in time. To guarantee the as an underlying general purpose kernel for real-time timely delivery the whole system architecture has to fulfill WSN applications. Our kernel offers preemptive hard real-time requirements. There are only a few real-time real-time multitasking with priority based scheduling. It architectures which can be used for sensor networks. These architectures are too generic to comply with the other offers minimal resource usage and can be implemented on requirements of a WSN architecture, like RAM usage and small sensor node architectures. We implemented it on energy awareness. a 72 MHz ARM7TDMI and o a 8 MHz TI-MSP430. In this paper, we present FireKernel, a real-time mi- The kernel can easily be adopted to existing WSN cro kernel designed for WSN operating systems with a firmwares because it is transparent to the programmer special focus on hard real-time requirements and strict and has a very simple programming model. Due to the energy management. It offers a preemptive real-time scheduler, mutexes and synchronous message passing for inter- introduction of tickless timers which are not using any process communication (IPC). The scheduler is priority- periodical timer interrupt, the whole system can stay in based and uses no periodical timers. As part of the kernel its deepest low-power mode as long as no calculation we introduce a tickless timer system. We have implemented is being done. This is a major advance in using more and tested the kernel on MSP430 and ARM7TDMI based powerful microcontrollers like 32 bit ARMs for WSN sensor nodes. nodes. We did our evaluation and measurements with realWe discuss the kernel’s architecture, implementation world software on the nodes. The application software and resource usage. Further, we present benchmark results is taken from the FeuerWhere project [1] and is used for interrupt latency and energy consumption of the timer to track fire fighters during emergency operations inside architecture. Index Terms—wireless sensor network, real time scheduling, tickless timer, operating systems, practical experience

buildings. Besides localization and tracking of fire-fighters it monitors vital parameters of the emergency forces and handles alarm cases with strong real-time requirements. The main contribution of this paper is threefold: •

I. I NTRODUCTION

We propose a very fast priority based real-time kernel for WSN nodes with minimal interrupt latency and low scheduling times. We introduce a tickless timer which is very accurate and does not utilize any periodical timer interrupts. We propose a true micro-kernel architecture which has several benefits in system design and interprocess communications.

Sensor networks have made the step out of the laboratories and are used in a wide range of scenarios. • There has been much research on routing protocols and media access layers. Both research areas focus on • energy consumption and reliability as key attributes. In rescue scenarios sensor networks are also on advance. For example WSNs are used to locate fire-fighters [1], monitor The paper is organized as follows: In Chapter II, we vital parameters and transmit them to base stations. Beside reliability and energy consumption, real-time behavior as discuss and compare similar approaches. In Chapter III, a third key feature that is added to the requirements of we give a brief introduction into the domain of real-time WSNs in rescue scenarios. Real-time features normally computing and introduce our system architecture and

978-1-4244-4487-8/09/$25.00 ©2009 IEEE

834

its components. We briefly discuss our implementation details in Chapter IV and give an evaluation of the key features of our systems and present measurements as our experimental results in Chapter V. Finally, we give a conclusion in Chapter VI.

in SensorOS its based on asynchronous message queues. This requires memory allocation and thus can make it difficult to fulfill real-time guarantees. FireKernel’s synchronous message API resembles the one found in QNX [9] and thus works completely without ever allocating memory other than on the stack. Asynchronous II. R ELATED W ORK message queues are available as a library. Additionally, Most freely available real-time operating systems our kernel is specifically designed to allow nodes with a (RTOS) for small microcontrollers such as FreeRTOS completely different architecture to interoperate, like a [3], are able to run on many different devices including ARM7TDMI based board together with another MSP430 wireless sensor nodes (WSN), but their general approach node, all using the same codebase and applications does not exploit the energy-saving capabilities of mod- which enables the setup of a interoperable distributed ern MCUs. These must be utilized in order to allow environment. WSN nodes to have the longest possible runtime, often measured in moths or even years, of battery power. III. F IRE K ERNEL A RCHITECTURE Often OSs follow an event-driven approach. TinyOS This section introduces the architecture of FireKernel. [4] and Contiki [5] are two such examples. It focuses the main parts of the kernel as there are TinyOS is written in its own programming language, scheduling, mutexes and IPC. Due to the limited hardware nesC. It uses only one stack. All operations that take which FireKernel normally runs on, there is no support more than a few hundred microseconds are asynchronous for a memory management unit (MMU) and thus no real and have a call back. Writing of complex computations memory management. But to be able to use dynamic consists of defining event handlers for small parts of the memory there is a simple implementation of malloc logic and can become hard to manage for programmers. if the target systems standard library doesn’t bring its Contiki also uses an event-based kernel, combined with own implementation. To fulfill the energy consumption lightweight cooperative proto-threads sharing a single requirement, we decided to let the main timer unit be stack. These proto-threads can not be preempted, a part of the kernel. lengthy calculation in one proto-thread blocks the CPU until it is finished. Additionally, proto-threads pose certain restrictions on the usage of the C language, i.e. it is not A. Microkernel Paradigm FireKernel is designed as a true microkernel which allowed to use local variables, and thread functions cannot be called from within subroutines. Contiki solves this means that the kernel provides only the absolute necessary partially by offering an addon library which implements features like scheduling, inter-process communication and preemptive context switching. As the core system is synchronization. All other operating system functionality designed around the event driven kernel, it can not including device drivers and system libraries have run in threads. This offers the system designer a level of completely benefit from preemptive multitasking. Energy-aware RTOS kernels offering preemptive multi- flexibility because only parts needed for his application threading using a traditional programming paradigm are have to be used and parts of the system could easily nano-RK [6], Mantis OS [7], and SensorOS [8]. Nano- be exchanged. To keep flexibility and resource usage RK implements a sophisticated resource control model in balance, the operating system designer is free to let and has a tightly integrated and optimized radio network several drivers run in a single task instead of running each stack. While the kernels of nano-RK and Mantis OS driver in a separate task. Using this model, critical drivers offer functionality similar to FireKernel, they are no make direct usage of the microkernel architecture and microkernels in the sense that every system service real time behavior if running in a separate task. Uncritical communicates with other parts only using messages drivers could share a task and have the same behaviour as offered by the system’s IPC functions. That restricts with a common kernel. Another benefit of the microkernel the flexibility of the system as modules cannot easily be architecture is, that all communication has to take place exchanged or even transparently distributed across the utilizing the kernel message API which makes it quite WSN. Also parts of the kernel can’t easily be exchanged simple to design distributed systems. Also stability could with custom functionality which is often needed by increase greatly using a microkernel because deadlocks could easily be solved killing and restarting the blocking specialized WSN architectures. FireKernel’s approach is similar to SensorOS’s, whose drivers, because they run in tasks and not as a kernel main IPC method is also a message passing API, but module. Due to the minimal footprint of a microkernel,

835

for scheduling. So we designed the kernel completely without any timer-tick which will greatly decrease the interrupt load on the target machine and saves a lot of energy. A side effect from this behavior is, that the complexity of the kernel is greatly reduced, too. Due to the requirements of the scenario the scheduler has to be a preemptive real-time scheduler. Unlike in operating systems with a Graphical User Interface (GUI) there is no real need to schedule in time-slices or any other periodic manner because GUI-Systems are using this Figure 1: Kernel interrupt handling and context-switching technique to let the user feel like the operating system is out of an ISR. processing his inputs immediately. The only requirements in embedded real-time systems and their event driven programming model to scheduling are that if a task with debugging is much easier and the possibility of a kernel a higher priority has to be processed, all lower priority failure decreases. processes have to be interrupted at any time and the higher priority task should get the focus and finish in B. Interrupt Handling time. The simplest strategy to achieve this design goal Interrupt handling is a critical part in the design of a by all means is to give every task a unique priority and real-time WSN kernel. Most device drivers on common immediately interrupt lower priority tasks to let the high WSN systems use interrupts directly without calling any priority task run until it ends. Multiple tasks with the kernel API because normally there no real kernel present. same priority level are possible in FireKernel, but they For a preemptively scheduled system, there is the need of have to share their CPU time cooperatively. passing interrupts through the kernel, because the context This simple scheduling assigns all computing power of the running task has to be saved before the execution to the high priority task which leads to the obvious of an ISR as another task can be created or waken up observation that if the task doesn’t finish in time, it inside the ISR. The main goal for our architecture design wouldn’t have finished in time on a single threaded was to achieve the lowest possible interrupt latencies and machine. From this follows that if a lower priority task to provide an API with is close to common sensor net could not finish in time there was a higher priorized task programming models. So no extra knowledge is needed that interrupted the lower priority tasks which leads to to program applications against our kernel and existing the simple conclusion that the overall system load was applications can easily be ported. too high or the priorities were not chosen wisely. The interrupt handling in FireKernel is very straight In our kernel there are only few situations in which a forward an shown in Figure 1. After the occurrence of context switch is needed. For each of those operations an interruption, the microcontroller jumps into the kernel there are two cases were they could appear. The first which does the context saving and then immediately case is, if kernel operations like mutex locking or manual calls the ISR within interrupt context. So the ISR is left creating of high priority tasks are called directly from with the normal return operations for ISRs on the target a low priority thread. In this case the task switch is platform. The return jumps back in the kernel again where done like in a cooperative multitasking environment as a decision is made if a task-switch has to be done or a predictable result to a direct userspace API-call. The not. This decision is done with a minimum of scheduling second case is, if those operations are called out of ISRs. afford and no full scheduler call is needed. After restoring In this case the interrupted task’s status is set to pending the scheduled context the kernel returns immediately into and the high priority task is put to running. This is the the restored context. only case where real preemptive scheduling is needed. Writing an ISR for the FireKernel is as simple as writing it directly in c without having an operating system because no extra line of code is needed and existing code D. The Idle Task could be ported to FireKernel without changing the ISRs. Like in other kernels there is a special idle task in C. The Scheduler We came to the conclusion that for WSN kernels neither time slices nor any periodic timer at all is needed

FireKernel whose only differences to a normal task are that it is created during system boot and that it never ends. The idle task has the lowest priority and normally puts the system in a low-power state if running. Due to

836

the kernel design the idle task and hence the low-power mode is only interrupted by a hardware interrupt and not by a periodic timer. The only logic in the idle task in our two reference systems is to determine which of the available low-power modes of the microcontroller is chosen which depends on the state of some kernel flags regarding the state of the used periphery. These flags can be used by device drivers to prevent the system from switching into low-power mode because on most architectures some modules of the microcontroller are turned off during low-power modes.

OS component Scheduler Thread management IPC Mutex Timer

code size (B) 852 1052 488 444 1232

data size (B) 8 0 0 0 60

Table I: Code sizes of kernel components compiled for 32 bit ARM7TDMI

blocking wait should set a timer and perform a task switch instead of doing a real blocking wait. So if no lower priority task is pending the idle task could be E. Synchronization activated for the amount of time the caller wants to wait. FireKernel offers simple mutexes, binary mutual exOne of the most energy wasting attribute of most kerclusion objects that can be used to synchronize threads. nels is their usage of a timer tick - normally implemented Waiting on a locked mutex uses the scheduler to stop as a repeating timer interval which causes an interrupt the task until the mutex becomes free again. That way it each time it elapses. In the belonging ISR the time is does not cost any cycles other than a context switch to incremented and the new value is checked against a timer the scheduler. No busy-waiting is necessary. data structure to determine if a timer has elapsed. Under normal system load the check ends with a match in the absolute minority of cases. This leads to a system F. Inter-Process Communication which is periodical woken up only to increment a counter In order to make rich applications on a possibly which of course is not used during low-power mode and a distributed sensor network possible, developers need easy checking which consumes a certain amount of computing but powerful inter-process communication (IPC) facilities. power without ending in a match. The optimum to drop In our resource constrained environment, IPC must also energy consumption would be to increment the variable be as lightweight as possible. Memory allocation has to only when it is actually been read and to let the checking be avoided in order to ensure real-time operation. We only occur if it will end in a match. decided to focus on a flexible but simple synchronous In Chapter IV-E we present a timer with both of these message passing framework. This allows a very simple criterias being implemented. Due to theses properties implementation, fully maintaining real-time semantics there are no periodic interrupts and no wasted computing if thread priorities are setup correctly, e.g. low level time. hardware drivers have higher priorities than application software. IV. I MPLEMENTATION As for certain tasks asynchronous message passing is desirable, FireKernel also offers full featured message We have implemented the FireKernel for the Scatterqueues at the cost of lost real-time guarantees. web WSN platforms MSB430-H [10] and MSBA2 [11]. The MSB430-H is equipped with a Texas Instruments MSP430 microcontroller running with 7 MHz and the G. Timers MSBA2 is equipped with a NXP LPC2387 ARM7TDMI As reported, the kernel itself does not make use of any microcontroller running with 72 MHz. All timing evalutimer tick or hardware timer. But for application- and ations have been done on the MSBA2 platform because driver programming it provides a timer architecture. The this is our main development system. Only 5% of the timer API provides the main functionality of setting and code is platform specific. Only the assembly language deleting timers and a wait function. A set timer is directly part used to implement the context switcher differs. The mapped on a hardware timer which is provided by the implementation is very lightweight on both architectures most microcontrollers. So the timer callback routine is as shown in Table: I and Table II. directly called out of the timer interrupt service routine (ISR) which is handled by the kernel. All sanitation which is done before the user space callback is invoked has to A. Scheduler Implementation be done in fixed time to guarantee real-time behavior. As the scheduler is essential to the responsiveness To achieve better performance and to save energy the of a system, our goal was to finish all scheduling in

837

OS component Scheduler Thread management IPC Mutex Timer

code size (B) 540 906 360 308 560

data size (B) 4 0 2 0 22

RUNNING

Thread A calls msg_receive, no message waiting

RECEIVE BLOCKED

Thread B calls msg_send

Table II: Code sizes of kernel components compiled for 16 bit MSP430 RUNNING

Thread A calls msg_send, Thread B is not RECEIVEBLOCKED

SEND BLOCKED

Thread B calls msg_receive

Figure 3: Possible states of Thread A using the message API

actually generating interrupts. In order to remove the need to differentiate between these components, a vectored interrupt controller (VIC) is added to the system. Developers then specify the ISR to be called upon triggering of a hardware interrupt using a simple compiler statement. The VIC then selects the ISR without the need for the guaranteed O(1) time where n represents the number of main CPU to waste cycles on each interrupt for choosing running tasks. The fact that we do not switch context the ISR. One drawback of the usage of this VIC is based on any periodic tick minimizes the overall time the difficulty for the operating system to actually know overhead. about the occurrence of an interrupt. TNKernel [12] for Every priority level out of the 32 possible ones has its example bypasses the VIC and selects interrupt routines own circular linked list containing pointers to pending in software using a switch statement. tasks. If one task issues a context switch, the kernel We chose a different approach shown in Figure 2. advances the circular list pointer of that task’s priority to When defining an ISR for FireKernel, it is done as point to the next waiting task, finds the highest priority like registering the routine with the hardware VIC. To that has pending tasks and selects the first one. Advancing achieve context saving, FireKernel is registered as the the circular list happens in constant time, also does finding main interrupt handler for the microcontroller instead of the next priority, so scheduling is bounded by O(1). a forwarding to the VIC. After saving the interrupted ISRs can set a flag so that the kernel calls the tasks context the kernel jumps to the VIC’s address with scheduler after an ISR has ended only when needed a normal jump operation, after manipulating the saved (See Chapter III-B). return address to point to the instruction just after this jump. The VIC calls the registered ISR for the specific B. Mutex Implementation hardware interrupt, then jumps back to FireKernel’s Each mutex object is also a queue object. Waiting routing. This way the kernel knows about the occurrence tasks allocate their queue entry on the stack and add of an interrupt and can e.g. call the scheduler if a task themselves according to their priority, then they set the switch is necessary, but without the need to chose the thread status to mutex-waiting and issue a context switch. right ISR by itself. Releasing a mutex involves picking the first waiting task and reactivating it. Everything is designed to work without D. Inter-Process Communication any dynamic memory allocation other than on the stack. Synchronous Message Passing has been the preferred choice of IPC in many microkernels like L4 [13] or C. Interrupt Handling QNX [9]. It has less overhead compared to asynchronous A typical microcontroller CPU core has exactly one message passing as it can be implemented without hardware interrupt line, but many different components dynamic memory allocation. Figure 2: The upper part shows the common interrupt handling without a preemptive scheduler. The lower part shows the implementation of our interrupt handling

838

See Figure 3 for an illustration of possible message states. If a thread sends a message to another thread, it blocks until the receiver thread calls the message receive function. If more than one thread tries to send to the same receiver, the messages will get queued according to the sending threads’ priorities. This is done in a similar way as in the mutex implementation. If a receiver calls the message receive function without at least one waiting sender, it will receive block until a message arrives. Listing 1: Simple Message Example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

# include # include # include # include

< s t d i o . h> < k e r n e l . h> < t h r e a d . h>

void b o a r d _ i n i t _ d r i v e r s ( void ) { / / c a l l i n i t i a l i z a t i o n f u n c t i o n s here } v o i d pong ( ) { msg m; while ( 1 ) { m s g _ r e c e i v e (&m) ; / * b l o c k u n t i l msg r e c e i v e * / m. c o n t e n t . v a l u e ++; msg_send (&m, m. s e n d e r _ p i d , t r u e ) ; } } v o i d main ( v o i d ) { board_init_drivers () ;

is set or an active timer is deleted. To minimize the time consumed by this logic we propose the use of a min-queue which gives us an runtime bounded by O(1) for the determination of the next timer and O(log n) for enqueueing of a new timer where n is the number of used timers. For hard real-time requirements an estimation of O(log n) is not enough. So we propose a solution where enqueueing of a new timer could be estimated with O(1) and the determination of the next timer is not needed at all. For our implementation, we make use of the fact that most microcontrollers allow several compare registers for each hardware timer. We assign every running timer to a different hardware register and maintain the unused registers in a queue implemented on a ringbuffer on which every operation, used by our kernel, is bounded by O(1). The only limitation to this approach is that the maximum number of simultaneously used timers is limited to the number of compare registers on the utilized hardware timer. If you are using very short timer intervals (e.g. 1 µs), it is possible that the counter variable will overflow during system runtime. On systems with a tick counter, the counter variable would then normally be a 64 bit variable. This results in having an unpredictable interrupt time of the tick ISR on 32 bit systems because every time the lower 32 bit overflow, there has to be a second addition to the upper part.

/* create a service thread */ i n t p o n g _ p i d = t h r e a d _ c r e a t e ( 3 0 0 0 , PRIORITY_MAIN−1, STACKTEST , pong , " pong " ) ; msg m; m. c o n t e n t . v a l u e = 0 ; / * loop , have our i n c r e m e n t t h e message ’ s payload * / while ( 1 ) { / * send a message * / msg_send (&m, p o n g _ p i d , t r u e ) ; m s g _ r e c e i v e (&m) ; / * b l o c k u n t i l msg r e c e i v e * / p r i n t f ( " Pong a n s w e r e d %i . \ n " , m. c o n t e n t . v a l u e ) ; } }

E. Timer Implementation To achieve the goal of a tickless timer the internal MCU timer has to be used differently to the usage of a common implementation. Instead of letting the timer run to a fixed value (e.g. 1 µs) and then generating an interrupt and resetting the timer, we let the timer run to infinity. This has two major advantages: First, we can read the time value directly out of the hardware register and don’t have to accumulate it to a variable in RAM and second, we can set a compare register directly to the absolute value where a timer elapses. This guarantees that an interrupt is only generated if a timer elapses and its handler has to be computed. One problem related to this approach is that the moment where the timer has to elapse has to be calculated instead of simply putting it into a list. Another problem is that if more than one timer is used simultaneously a logic has to be implemented determining the timer which will elapse first and put its absolute value to the hardware register. This logic has to be run each time a new timer

The actual timer value is not read from a variable like in common implementations. To calculate the actual value on demand, a function call is needed. This function is containing only one word width copy operation as their only line of code. So it would be inlined by most compilers at an appropriate optimization level. The operation is to copy the hardware counter value directly behind the overflow counter, and return them as double length word. On our systems, the commonly used addition is computed in two clock cycles (one for the incrementation and one for the write back to memory) and our implementation also is computed in two clock cycles (one for reading from memory and one for writing into memory). That leads to the observation that our implementation uses less cycles in systems in which the timer count is less often read than incremented which should be the case in every system. The overflow counter is only incremented every four billion times (on 32 bit systems) in both cases and uses the same computation time. So our implementation is an advance in reducing interrupt load and decreasing energy consumption, especially for ultra low power systems.

839

Figure 4: Measured timing behavior. The upper graph is showing the power consumption over time and the lower one is showing if a task is running (low-active). In 1 an interrupt occurs and the microcontroller is leaving the sleep mode and jumps into the task switcher. In 2 the task switching is done and the ISR-Task is being processed. In 3 the scheduler becomes active and schedules to the idle task which is run in 4 and sends the microcontroller to sleep-mode again.

V. E VALUATION

A. Interrupt Latency

Figure 5: Context switching time. The lower line represents the running task, toggling on the forced context switch. The upper line is toggling with the execution of the first c statement of the scheduled task.

B. Scheduling Times The guaranteed maximum scheduling time is the second key feature of a real-time kernel. It characterizes the timespan which is needed from the occurrence of an event that causes a task switch to execution of the first instruction in the scheduled task. For our kernel we have measured the time for a task switch out of an interrupt, which is the more important one, and the time for a task switch out of another task. The first one is measured with 990 ns (or 72 clock cycles) as shown in Figure 4. The task to task switching time is measured with 8.4 µs (or 605 clock cycles) as shown in Figure 5. The second one is much longer because we use the kernel API to force a task switch to a lower priority pending task and the full scheduling routine has to run instead of a minimal one if called out of an interrupt. These values are not really comparable to other published values because of totally different underlying architectures of the target hardware. For example SensorOS [8] has a context switching time of 90 µs on a 8 MHz 16 bit microcontroller which could roughly be estimated to be 10 µs on a 72 MHz system. A summary is shown in Table III

The guaranteed maximum interrupt latency is one of the key attributes of a real-time kernel and should be as small as possible to guarantee immediate reaction to external events. For our kernel, we measured the interrupt latency with an oscilloscope using an IO-pin interrupt source as the trigger and measuring the power consumption over a shunt with probe one and the toggling of an external IO-pin with probe two. With this method we could measure the interrupt latency under real world conditions. Our measured value is including the time the microcontroller needs to wake up from sleep mode and the time the kernel needs to save the context. In Figure 4 we see that the overall interrupt latency is 700 ns on a 72 MHz LPC2387 System regardless of system load. After this time span the first instruction of the ISR is Interrupt latency executed. To be more precise, the first C-instruction of Context switch out of an ISR the ISR is executed. Depending upon the C-compiler used Context switch for building the binary, there may be various assembler IPC delay instructions before this, so the latency could be further reduced by coding the ISR in assembler or declaring Table III: Latencies measured on it as attribute ((naked)). 700 ns equals 72 MHz 50 clock cycles which is the smallest latency in every multitasking-system we have evaluated.

840

cycles 50 72 600 1300

time in µs 0.700 0.990 8.4 18

a LPC2387 running at

R EFERENCES

C. Energy Consumption Using Tickless Timers With tickless timers we introduce two main opportunities to save a huge amount of energy - one direct one and one indirect one. The first one is the direct result of the usage of tickless timer. Every timer tick consumes an amount of energy which is shown in Figure 4. The upper graph shows the power consumption for an ISR which is only incrementing a variable and then returns. After returning the idle-task is scheduled which puts the microcontroller to low-power mode. In low-power mode our LPC2387 is consuming 30 mA of current and in active mode it is 70 mA. Every timer tick ISR forces the microcontroller for 2.880 µs into active-mode which equals 32 nAh of extra current. If we come from a periodically tick every 10 µs we could estimate an extra amount of current of 3.2 mAh per hour which is a huge sum for low-power systems. The indirect power saving effect depends on the microcontroller architecture. On ARM and most other architectures, only external interrupt sources can wake up the microcontroller from deep-sleep mode but not the timer interrupt. Hence using a periodical timer prevents the microcontroller from using deep-sleep mode and consuming much more power than needed over the whole runtime. We have observed in a real world rescue scenario that the microcontroller stayed 95% of the time in lowpower mode and was not waiting for any timer. If we are using the deep-sleep mode - consuming less than 1 mA - instead of the normal low-power mode on our LPC2387 we could save another 27.55 mAh per hour which is a huge sum also for non low-power sensor nodes. This amount would of course decrease on smaller microcontrollers like the MSP430 but on the other hand it actually enables the usage of bigger microcontrollers like an ARM7TDMI for sensor nodes.

[1] “Feuerwhere - tracking firefighters,” 2009. [Online]. Available: http://www.feuerwhere.de [2] A. A. Ahmed, L. A. Latiff, M. Sarijari, and N. Fisal, “Real-time routing in wireless sensor networks,” Distributed Computing Systems Workshops, International Conference on, vol. 0, pp. 114–119, 2008. [3] “The freertos.org project,” 2009. [Online]. Available: http: //www.freertos.org/ [4] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, “Tinyos: An operating system for sensor networks.” Ambient Intelligence, 2005, pp. 115–148. [5] A. Dunkels, B. Grönvall, and T. Voigt, “Contiki - a lightweight and flexible operating system for tiny networked sensors,” 2004. [6] A. Eswaran, A. Rowe, and R. Rajkumar, “Nano-rk: an energyaware resource-centric rtos for sensor networks,” in Real-Time Systems Symposium, 2005. RTSS 2005. 26th IEEE International, 2005, pp. 10 pp.–265. [7] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald, A. Torgerson, and R. Han, “Mantis os: an embedded multithreaded operating system for wireless micro sensor platforms,” Mob. Netw. Appl., vol. 10, no. 4, pp. 563–579, 2005. [8] M. Kuorilehto, T. Alho, M. Hännikäinen, and T. D. Hämäläinen, “Sensoros: A new operating system for time critical wsn applications.” in SAMOS, ser. Lecture Notes in Computer Science, S. Vassiliadis, M. Berekovic, and T. D. Hamalainen, Eds., vol. 4599. Springer, 2007, pp. 431–442. [9] D. C. Sastry and M. Demirci, “The qnx operating system,” Computer, vol. 28, no. 11, pp. 75–77, 1995. [10] M. Baar, E. Köppe, A. Liers, and J. Schiller, “Poster and abstract: The scatterweb msb-430 platform for wireless sensor networks,” in SICS Contiki Hands-On Workshop, Kista, Sweden, 03 2007, p. 3. [Online]. Available: http://cst.mi.fuberlin.de/publications/pdf/2007-Baar2007a-CWS.pdf [11] M. Baar, H. Will, B. Blywis, T. Hillebrandt, A. Liers, G. Wittenburg, and J. Schiller, “The ScatterWeb msb-a2 platform for wireless sensor networks,” Freie Universität Berlin, Takustra¨se 9, 14195 Berlin, Germany, Tech. Rep., 09 2008. [Online]. Available: ftp://ftp.inf.fu-berlin.de/pub/reports/tr-b-0815.pdf [12] Y. Tiomkin, “Tnkernel real-time system,” 2008. [Online]. Available: http://www.tnkernel.com [13] J. Liedtke, “On µ-kernel construction,” in Symposium on Operating System Principles. ACM, 1995.

VI. C ONCLUSION AND F UTURE W ORK This paper presents a tickless real-time kernel with full preemptive multitasking especially designed for usage on WSN nodes. Compared to other systems, FireKernel has a very straight forward programming model due to its real microkernel architecture. Together with the tickless design and the extremely short interrupt latency it is ideally suited for usage in time critical WSN applications such as rescue scenarios. Our future work concentrates on designing and implementing MAC and routing algorithms which will make use of the real-time capabilities and the microkernel architecture to form a full real-time operating system.

841