Any operating system strives to provide a framework for convenient and easy application software development. Through the use of multitasking and hardware abstractions, an operating system is useful to a programmer because it isolates dependencies from the particular hardware details through the agency of a Hardware Abstraction Layer (HAL).

One of the uses of a real-time OS (RTOS) is to guarantee determinism for real-time performance. It is equipped with facilities which can help the user to meet their application's real-time goals. For the OS to be real time it needs to have a special architecture, especially in the scheduler, a main component of the RTOS.

RTOSes are often classified as either soft real time or hard real time. A hard real-time RTOS is guaranteed to meet the timing requirements, while soft real-time solutions only guarantee these timing deadlines within a range of probability. One of the first design decisions to be made is to answer two questions:

1) Is the system real time or not? (The definition of 'real time' depends on the requirements and absolute time will be a different value for different projects.)

2) If the system is real-time, is it hard real time or soft real time? The answers to these questions will help in the selection of the software architecture. The requirements of the smart sensor wireless sensor network described in Part 1 can be used to help you pin down which alternative you need to deploy.

Shown in Figure 4 below is the typical interaction of the application, the RTOS, the Board Support Package (BSP) and the hardware. The BSP is the collection of drivers that an RTOS would define in order to interface with different hardware. As can be seen, the application can request services from the RTOS, or bypass the RTOS to talk directly to the BSP or hardware.

Depending on how the system is architected some of those links are optional and most RTOS vendors would recommend that it all be done through the RTOS and have the RTOS use its BSP to control the hardware.

Figure 4: Typical Interactions in an embedded design

Concurrency and IPC
A smart sensor design may implement layers through the full range of the seven-layer OSI model. Some layers may not be required for certain applications. For example, the Physical Layer, Data Link Layer and Application Layer must be present for the WSN to function as such. The control of the Physical and Data Link Layers is a parallel activity in the RTOS.

The same can be said for energy control of the smart sensor chip. Adding the networking and transportation layers requires another independent activity. That is why the question of concurrency becomes serious when the networking layer needs to do routing independently from the application layer.

If the smart sensor runs a mesh networking protocol such as Zigbee, and or has a TCP/IP stack in the case of a Zigbee gateway, then the convenience of an RTOS or at least a simple scheduler becomes necessary. With the concurrent execution facilities comes the need for IPC.

Memory Management
Memory management in embedded systems is handled differently depending on speed and capacity restrictions. Another restriction may come from the lack of a Memory Management Unit (MMU) in the smaller embedded CPUs.

This is especially true for smart sensors, where in some cases the CPU is 8-bit and the memory is restricted to several tens of kilobytes. Therefore the usual approach in the RTOS is to use static resource allocation [18]. This means that all buffers are allocated at compile time, thus exposing problems in the design and avoiding unexpected dynamic behavior.

In addition, the RTOS needs to optimize memory usage during resource allocation and during runtime [2]. It seems to me that there is a potential for tools to help the designer of the application to verify the memory offline and during the initial design.

I/O Management
It is hard to come up with an abstraction about all the possible I/O configurations, but there is an opportunity for an RTOS to standardize the reading and control of I/O [2]. Interfaces to common sensors can hide the details in the device drivers' implementation and the RTOS can provide a unified interface for classes of devices to the user.

This means that changing the underlying hardware would not lead to application code changes, but will simply require a new driver which complies with the established interface. The challenge is that the number of possible device driver classes is overwhelming compared to a standard embedded system with just serial and Ethernet interfaces and no sensors attached.

Similarly to how Zigbee classifies types of devices, an RTOS can support classes of drivers. Another issue in handling I/O is buffering, which also can be done by the RTOS and not the application code.

Network Management
A big portion of the RTOS functionality is the support for network protocols. Routing protocols in WSNs are special and can be tailored to the specific needs of the application. The energy conserving approach requires routing to be done efficiently. The same is true for data exchanges between nodes in the network.

Therefore the RTOS needs to have an architecture that supports easy installation of new wireless networking protocols. Handling collisions with special protocols is a subject of ongoing research in the area. Aggregating several packets into one and transferring in one burst is another feature of these protocols [2]. Nano-RK takes the approach of socket-like abstraction for the application, which is a convenient and well-known approach for software developers.