The Second International Conference on Sensor Technologies and Applications Anatomy of RTOS and Analyze the Best-Fit for Small, Medium and Large Footprint Embedded Devices in Wireless Sensor Network Ranjan Dasgupta Innovation Lab, Kolkata, Tata Consultancy Services Ltd, India [email protected] Abstract suitable at the time of deploying either in small, A wireless sensor network is characterized as a medium or large footprint wireless embedded devices. massively distributed and deeply embedded system 2. Software Architecture with small medium and large footprint embedded 2.1. WSN Framework devices. The sensor devices and wireless sensor nodes Component based framework [2] is desirable for the are often severely resource constrained. Typical they development of application software for WSN. The are equipped with 8-bit MCU, 100-512KB code components of the framework provide the functionality memory and 4-64KB of RAM. Background / of single sensors, sensor nodes and the whole sensor foreground approach, finite state machine based network. According to these components, applications software design and event-driven programming are classified into sensor applications, node techniques are capable of handling concurrent and applications and network applications. Some of these asynchronous events usually occur in these devices. applications are easy to implement without a RTOS, But network routers and coordinators are often some require a simple scheduler, and some a full- medium and large footprint devices, equipped with fledged RTOS discussed in this paper. 16/32-bit MCU, 640KB–64MB code memory and more 2.2. Sensor Application RAM where real-time operating system is easier to The sensor application contains the entire implement. For a wireless sensor network design measurement and readout of a sensor as well as the choosing and deciding a suitable lightweight real-time local storage of the data. It has full access to the operating system and OS abstractions that provide a hardware and is able to access the operating system rich enough execution environment while staying (OS) directly. Network access is not possible. Smart within the limitations of the constrained devices is a sensors are small footprint embedded devices and their great challenge. This paper presents several RTOS hardware architectures are characterized with the architectures and analyzes the best–fit for sensors and following specifics: other wireless network devices. • Restricted CPU power • Restricted available memory in the order of 1. Introduction 100KB code memory and less than 20KB of The wireless sensor network (WSN), as a key RAM enabling technology for ubiquitous computing, has a • Limited energy supply, mainly provided by wide range of applications, which are deeply batteries or alternative sources such as the embedded in the physical world. Embedded devices sun, vibrations, etc comprising WSN (sensor, sensor node, router, • Dimensions and weight restrictions, which coordinator) elements are generally resource can lead to cooling and CPU usage constrained [1] such as small CPUs, small memory restrictions footprints and limited energy. The limited hardware All these specifics of smart sensors require special resources make special application necessary, which in attention when choosing the RTOS architecture. For turn creates special requirements for real-time sensor application shown in Fig 1, an operating system operating system (RTOS). Therefore choosing the best should implement a low-power task scheduling. A fitted RTOS for WSN hardware is one of the greatest scheduling algorithm could take advantage of challenges to overcome. This paper presents several nonlinear battery effects to reduce energy RTOS architectures, differentiates them in terms of consumption. There are complexity, and figures out which one will be more two or three system software approaches that can satisfy the constraints of such considerations 978-0-7695-3330-8/08 $25.00 © 2008 IEEE 605598 DOI 10.1109/SENSORCOMM.2008.139 Host Middleware Sensor Driver Algorithms Modules Services VM Transmitter Filtering / Pre- Acquisition & processing and Flash Transducer Storage Control Sensor Middleware Management Figure 1 Structure of a sensor application Operating System Sensor Driver • Foreground and background architecture CPU Sensor • Queued architecture Figure 2 Structure of a node application • Simple Scheduler 2.3. Node Application All these functionality of sensor node application Sensor nodes are small to medium footprint require following system software approaches that can embedded devices with wireless communication and meet • networking capabilities. Typical sensor nodes are Finite state machine and event driven equipped with 8/16-bit MCU, 512KB-4MB code architecture memory and more than 128KB of RAM. The node • Reactive deadline driven architecture application contains all application specific tasks and • Virtual machine architecture functions of the middleware to build up and maintain 2.4. Sensor Network Application the network, e.g., routing, looking for nodes, Mostly sensor network application is running on discovering services and self-localization. The medium to large footprint wireless embedded devices different requirements and objectives for WSN can be (e.g. network routers and base station or coordinator) achieved only by using a flexible architecture of the describes the main tasks and provides services of the node software. Therefore node software is divided into entire network. Fig 3 shows the logical view of a three parts according to the main tasks (Fig 2). sensor network application. The nodes can be The operating system handles the device-specific contacted only through services of the middleware tasks. This contains bootup, initialization of the layers. They do not perform any individual tasks. The hardware, scheduling, and memory management as distributed middleware coordinates the cooperation of well as the process management. The OS consists of the services within the network. It is logically located special tailored parts only needed by the specific in the network layer but it exists physically in the application of the node. nodes. All layers together in conjunction with their The second part is the sensor driver. It initializes the configuration compose the sensor network application. sensor hardware and performs the measurements in the All these functionality of sensor network sensor. It encapsulates sensor hardware and provides application require following system software an optimized application-programming interface (API) approaches that meet to the middleware. The host middleware is the superior software layer. Sensor Network Application Its main task is to organize the cooperation of the Distributed Middleware distributed nodes in the network. The middleware management handles four optional components, which can be implemented and exchanged according to Middleware Middleware node’s task. Modules are additional components that increase the functionality of the middleware. Typical Operating Operating modules are routing modules or security modules. System System Algorithms describe the behavior of the modules e.g. Hardware Hardware the behavior of a security module can vary if the encryption algorithm changes. The service component Node A Node B contains the required software to perform local and Figure 3 Structure of a sensor network application cooperative services. This component usually cooperates with other nodes to fulfill its task. Virtual • Preemptive scheduler machines (VM) enable an execution of platform • Layered multithreaded and network stack independent programs. architecture 606599 • Evolvable architecture requirements. This technique is used by Jennic in its 3. RTOS In Small Footprint Embedded application queue implementation. Sensor Device 3.3. The Simple Schedule 3.1. Foreground / Background Architecture A much more flexible way is to use a simple task scheduler, which has the advantage of allowing the This approach [3] is a standard one for software creation of tasks. The term ‘task’ here is equivalent to a implementation in small footprint embedded sensor lightweight process or thread. Tasks allow the software devices and is a good solution when there is no need solution to be divided into independent execution for well separated parallel execution. The foreground / contexts having their own logic. Having their own background architecture consists of two main parts – context is especially beneficial for local encapsulated the foreground comprises the interrupt service routines variables, thus reducing the necessity for global (ISRs) that handle asynchronous external events in a variables. timely fashion, and the background or main is an There are needs to be some forms of inter process infinite loop which repeats the same activities forever communication (IPC) in order to exchange information and uses all remaining CPU cycles to perform the less between tasks, but this is done through the framework time-critical processing. The parallelism is achieved and is not directly controlled by the tasks. The tasks through ISR, when get triggered by a software or can exchange messages, events, signals, etc. through hardware interrupt. The flow of main loop is suspended message queues that the solution needs to provide. when an interrupt occurs and it is being processed by This is a small RTOS with nothing but the basic the ISR. The foreground typically communicates with functionality to achieve parallel software execution in the background