InitRech 2015/2016, sujet 26
Summary
Contiki is a dynamic operating system, write on C, based on event-driven kernel that can also handle multi-threading. It respond to different issues encounter in microcontroller sensors such as energy consumption, memory consumption, speed and multiple services. It is designed for tiny networked sensors distributed on large scale which application can be in military use, earth sensing (air pollution monitoring, earthquake detection) or industrial monitoring. Wireless sensor network are composed by a lots of independent devices. For a matter of cost, these devices are not complex. They have to be small, cheap, low energy consumer but also reliable to send data over the network like piece of code. These devices will be smaller and cheaper but regardless of energy consumption. To extend sensor network size, sensors have to be more lightweight and autonomous.
In case of bugs, you have to be able to upload your patched code in all the network, for each node. This is a heavy process that consume a lot of energy at each node. Contiki can load and unload services at runtime and don’t need the entire operating system image. Sensor devices use different sensors, specific to their use. The only part shared by all sensors is the CPU. Contiki provide a multiplatform OS with the desire to unify wireless sensors. (Most of microcontroller don’t care about memory protection.) Multithread is convenient but it’s consume lots of memory: for each thread his own stack, pre-allocated and over provisioned. Contiki proposed event-driven systems. This way processes can use the same stack without locked resources. However, this type of kernel is complex, hard to manage and can be unresponsive in case of heavy task (like cryptographic which monopolize the CPU). So Contiki implement preemptive multithreading
Contiki is not the first OS dedicated to portable tiny sensors but this article compare his benefits to existing OS. Some programmers have made the choice of virtual machine on microcontroller in order to reduce the OS code size. On the other hand, Contiki’s programmers have made the choice to create Contiki as a native OS and not a virtual machine, because even if a VM code is smaller and easier to transport, the energy saved at first is consumed by the interpretation on the VM then. And unlike VM, Native OS allow easily low level tasks. Also, simpler OS exists. With only one scripting language you can program the sensor, but it’s not portable nor resource constraining.
Contiki is made of a kernel, libraries, a programm loader and some processes which can be an application or a service used by multiple applications. The kernel is a lightweight event scheduler that can support asynchronous and synchronous events. Asynchronous events can be dispatched to the process with a delay, however synchronous events immediately scheduled the process. A polling mechanism is setup to deal with hardware requests processes and everything is done with a single shared stack. All processes run under the same right level. A process can be outstrip only by interruption and not by an another process. To maintain real-time execution, interruption are never disable. Nevertheless, the kernel doesn't provide a power save mode but the scheduler give the size of his events list to some applications, that can save energy on specific system parts. Unlike processes, services are managed by a service layer, independent of the kernel that list installed and running services. Through a stub library, an application contact the service layer that provides the service ID for the application requests. Both processes and services can be dynamically loaded and replaced. While the kernel provide basic features, libraries implement the rest of the system. Programms can load static libraries that are parts of the core, load run-time libraries, call services implementing specific libraries.
