The designers of operating systems for sensor nodes are often faced with the challenge of finding the right abstractions and lightweight mechanisms that offer a rich enough execution environment, while remaining within the system’s strict resource limitations. My hunt for a good operating system landed me with Contiki developers in a CONET Summer School at Bernitoro Italy. Contiki is a lightweight operating system developed by Adam Dunkel for constrained platforms, such as sensor nodes. Its basic configuration fits in less than 2 KiB of RAM and 40 KiB of ROM, and provides two communication stacks -(IP and Rime) as well as multi threading functionalities. That was the magic that I needed for my security implementation, considering that the sensor node has low memory capacity. Moreover, Contiki has a much easier learning curve for the developer, since it is based on a widely known programming language, C.
Using Contiki as the operating system of the motes offers many advantages. As mentioned before, Contiki’s kernel is event based, which means that the block wait abstraction is not supported, since in the abstraction model: the programs know the core but the cores do not know the program. For this reason, when programming such a system one will have to use a state machine to implement the control flow for high level logic that cannot be expressed as a single event handler.
However, this approach is considered cumbersome and programmers usually have problems with it. In order to counter this shortcoming and simplify the programs, Contiki implements a programming abstraction called protothreads. One has to remember though, that as the name implies, they are merely tools for creating a conditional blocking wait-statement. Protothreads have a low memory overhead and are also stackless, i.e. they all run on the stack and context switching is done by stack rewinding. Since processes in Contiki are nothing more than protothreads it makes sense to take a closer look at this abstraction.
There are a lot of differences between Contiki and the more popular embedded operating systems, such as TinyOS, include the code footprint and also in the underlying architecture, such as scheduling. While the native TCP/IP support offered by Contiki is nice, it requires more resources from the system (and might not be essential for all WSN deployments). Contiki uses a java-based simulator known as Cooja for simulating a network of sensors running the OS. Cooja is flexible in that many parts of the simulator can be easily replaced or extended with additional functionality. Example parts that can be extended include the simulated radio medium, simulated node hardware, and plug-ins for simulated input/output. Cooja is evaluated using four metrics: efficiency, scalability, flexibility and extensibility. The efficiency of the simulation is defined as the running time for simulating a number of nodes running the same software. WSNs have a powerful tool on their hands for thoroughly testing different system ideas before they are to be implemented in practice, thus enabling them to save time and memory. The video shows the workings of Contiki Cooja.
Contiki Cooja TimeLine Sensor Network Activity Visualizer
About the Author
Celestine Iwendi is a Sensor and Electronics Researcher at the University of Aberdeen, UK