Analysis of TinyOS wireless sensor network operating system

0 Introduction

A wireless sensor network is a multi-hop self-organizing network system composed of a large number of cheap micro sensor nodes deployed in the monitoring area through wireless communication. Its purpose is to collaboratively sense, collect and process the information of the sensed objects in the network coverage area and send it to the observer. The research on wireless sensor network technology involves the frontier fields of multiple hot disciplines, such as sensor technology, modern network technology, embedded computer technology, wireless communication technology, etc. Since wireless sensor networks have broad application prospects in many fields such as industrial monitoring, environmental testing, medical monitoring, military reconnaissance, etc., they have attracted the attention of industrial, academic and military departments in various countries in the world, and have quickly become one of the hot research topics in the world today.

1 Main features of wireless sensor networks

The hardware of sensor network nodes is generally composed of four units: data acquisition, data processing, data transceiver and power supply. The data acquisition unit collects external data through sensors and converts it into digital signals; the data processing unit is the core module of the node, responsible for coordinating the work of various parts of the node, such as necessary processing and storage of the data collected by the data acquisition unit, and setting the working mode of the data transceiver unit; the data transceiver unit is responsible for wireless data transmission and data interaction with the data processing unit. The above four basic modules together with the corresponding operating system, protocol stack and application program constitute a basic wireless sensor network node. Many network nodes are distributed together to complete the basic functions of the wireless sensor network.

In terms of software design, this system relies on a dedicated embedded real-time operating system to manage and coordinate the work of the hardware parts of the sensor node. The upper layer application and the communication protocols of each layer are centered on energy saving. If necessary, some other network performance indicators can be sacrificed to obtain higher power efficiency. Figure 1 shows the basic composition of a sensor network node.

Traditional wireless network designs are basically designed to meet people's various needs at the same time, such as voice, video, image, etc. Wireless sensor networks are generally designed for a specific need. They are an application-based wireless network. Compared with mobile communication networks, wireless local area networks, and Bluetooth, wireless sensor networks have the following main characteristics:

(1) Limited power energy: In wireless networks, the power supply of each node is limited. Most networks work in unmanned areas or harsh environments that are harmful to the human body. Generally, it is almost difficult to replace the power supply. (2) Limited

computing power: Sensor network nodes all use processors with embedded characteristics, but the processing power of embedded processors makes the computing power of sensor nodes relatively limited.

(3) The number of wireless sensor network nodes is large and the distribution range is wide. The sensor nodes in the network are very dense and huge, sometimes reaching hundreds, thousands, or even more.

(4) Dynamic topology: The topology of the sensor network may change due to factors such as the environment or the exhaustion of node power, which requires the sensor network system to adapt to such changes.

2 TinyOS operating system

Due to the limited resources of wireless sensor network nodes, traditional embedded operating systems are difficult to run and work normally and effectively, especially the contradiction between energy and memory requirements is more prominent. Therefore, a new embedded operating system is needed to meet the basic needs of wireless sensor nodes. The TinyOS operating system is an open source embedded operating system designed by researchers at the University of California, Berkeley, for wireless sensor networks. The TinyOS operating system mainly uses lightweight threads, active message communication, event-driven mode, component programming and other technologies.

The TinyOS operating system initially used assembly and C language. However, after further research and use by researchers, it was found that the C language could not effectively and conveniently support the development of wireless sensor network applications. Therefore, after careful research and design, and on the basis of certain expansion of the C language, the nesC language supporting component programming was proposed. This language can combine componentization, modularization ideas and event-driven execution models. Since the TinyOS operating system and applications based on the TinyOS operating system are all written in the nesC language, before introducing the TinyOS operating system, the nesC language is first introduced.

3 nesC language

TinyOS and the applications running on it can be regarded as a large "executable program", which is composed of many independent and interconnected software components. Figure 2 shows the general program framework of the nesC language. A component in the system generally provides some interfaces (assuming the component name is ComA). The interface can be considered as a declaration of a set of functions implemented by this software component, which is a set of commands and events defined separately. Other components use the functions of this component (ComA) by referencing the same interface declaration, thereby realizing the mutual calling of functions between components. That is, the interface of the component is the channel for realizing the interconnection between components. However, if the functions implemented in the component are not described in its interface, they cannot be used by other components. There are two types of components with different functions in the definition of nesC language: the function functions in the component interface are specifically implemented in the component file of the module, and the relationship between different components is specifically described through the component file called accessories.

The interface in this system generally refers to a set of declared named functions. At the same time, the interface is also the link between different components. The interface of a component is usually bidirectional. This interface is actually a multifunctional interaction channel between the provider component and the user component. The set of function functions of the interface implemented by the provider of the interface is called a command; the set of function functions that the user of the interface needs to implement is called an event.

Components are the basic units of nesC programs. Components can be divided into modules and accessories.

Among them, modules are the logical functional entities of components, mainly including the specific implementation of commands, events, and tasks. In TinyOS, commands are non-blocking, and they will notify related event calls after they are completed. In general, command calls are downward, that is, application components call those components that are closely integrated with hardware, and event calls are just the opposite. The calls of some special basic events must be bound to hardware interrupts. There is also a special type of function in the nesC language called a task. In the TinyOS system, a task is an entity that can be scheduled, similar to the concept of a process or thread in a traditional operating system.

Accessories can usually implement a component specification through a series of other components, which mainly implements the mutual access method between components. Accessories include component lists and connection instructions. The component list defines the components that implement the accessories. Connections can usually link the defined elements (interfaces, commands, events, etc.) together to complete the function calls between components.

4 Working Principles of TinyOS System

In order to adapt to the characteristics of wireless sensor networks, the TinyOS operating system uses four main technologies: component programming, lightweight threads, active message communication, and event-driven models.

4.1 Component Model

The components in the TinyOS operating system have four interrelated parts: a set of command handler handles, a set of event handler handles, an encapsulated private data frame, and a set of simple tasks. Tasks, commands, and event handlers execute in the context of private data frames and switch the state of the frame.

Components in the TinyOS operating system are usually divided into three categories: hardware abstract components, synthetic components, and high-level software components. The hardware abstraction component is used to map the physical hardware into components in the TinyOS operating system. The wireless transmission module is a representative of this component. It can provide commands to manipulate the individual I/O pins connected to the RF transceiver, and send signals to events to notify other components of the sending and receiving of data bits. Figure 3 shows the component structure of the antenna sensor application: the synthetic component can simulate the behavior of high-level hardware. An example of this component is the Radio Byte component in Figure 3, which interacts with the upper-level components in bytes and interacts with the lower-level wireless transmission module components in bits, and finally maps the wireless interface to the UART device interface; high-level software components can complete functions such as control, routing, and data transmission. The active message processing module in Figure 3 is a representative of this component. It can perform the functions of filling the packet buffer before transmission and distributing the received messages to the corresponding tasks.

4.2 Lightweight Threads

In the TinyOS operating system, general lightweight thread tasks (i.e., tasks in the TinyOS operating system) can be scheduled in FIFO mode, and preemption is not allowed between lightweight threads. Once a task is executed, it must be completed and cannot be interrupted by other tasks. The hardware processing thread (i.e., interrupt processing thread) can interrupt the user's lightweight thread and low-priority interrupt processing thread, so it can respond quickly to hardware interrupts.

4.3 Active Message Communication

Active message communication is a high-performance communication model for message communication. The main purpose of using the active message mechanism in wireless sensor networks is to overlap the computing power and communication of wireless sensor nodes. In order to make active messages more suitable for the needs of wireless sensor networks, active messages provide three most basic communication mechanisms, one is message transmission with confirmation, the second is clear message address, and the third is message distribution. In the TinyOS operating system, active message communication is regarded as a system component, which shields various communication hardware in the lower layer, thereby providing a consistent communication primitive for the upper layer, which can facilitate developers to implement high-level communication components with various functions.

In the active communication of TinyOS, when data arrives at the sensor node, it is first cached, and then the data in the cache is distributed to the upper-layer application by active messages. The TinyOS operating system does not support dynamic memory allocation, so each application is required to return an unused message cache after the message it needs is released to receive the next message to come. Because the execution between applications in the TinyOS operating system cannot be preempted, there will be no conflict between multiple unused message caches. Therefore, the active message communication component of the TinyOS operating system only needs to maintain an additional message cache for receiving the next message. If an application needs to store multiple messages at the same time, it needs to statically allocate additional space on its private data frame to save the messages.

In general, since the TinyOS operating system only provides the best-effort message delivery mechanism, the receiver needs to provide confirmation feedback information to the sender to determine whether the transmission is successful. The confirmation message can be generated by the active message communication component, which saves more overhead than generating a confirmation message packet at the application layer, and the feedback time is short.

4.4 Event-driven model

The TinyOS operating system is an event-driven operating system. Therefore, when a task is completed, it can trigger an event, and then the corresponding processing function is automatically called by the TinyOS operating system. Event-driven is divided into hardware event-driven and software event-driven. Hardware event-driven means that a hardware sends an interrupt and then enters the interrupt processing function; while software-driven triggers an event through the signal keyword.

5 Conclusion

Although TinyOS has been widely used and has been quite recognized, it does not mean that TinyOS can be applied to all application scenarios of WSN. In fact, in some occasions, TinyOS does not work well. It also has shortcomings, such as overload, task loss, and decreased communication throughput. The three typical tasks of wireless sensor network nodes are generally sensor acquisition, local data transmission, and forwarding data packets as relay nodes. When the frequency of local tasks is too high, the task queue will soon be full, and the sending or receiving tasks may be lost, resulting in data packet loss; in addition, if the local task runs for too long, the task of sending or receiving data packets will also have to wait for a long time to be processed, which will reduce the communication rate. Therefore, the scheduling strategy of TinyOS may cause problems. The FIFO scheduling mechanism may also cause some important tasks to not be responded to in real time. The solutions to these problems will be discussed in later articles.