Version actuelle datée du 18 juin 2016 à 18:09

Summary

Contiki is a dynamic operating system, write on C, based on event-driven kernel that can also handle multi-threading. It responds 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 can be used in military applications, earth sensing (air pollution monitoring, earthquake detection) or industrial monitoring. Wireless sensor networks are composed by a lots of independent devices. For a matter of cost, those devices are not complex. They have to be small, cheap, low energy consumers and also reliable to send data, like pieces of code, over the network. Those 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 consumes 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 provides a multiplatform OS with the desire to unify wireless sensors. (Most of microcontrollers don’t handle memory protection.) Multithread is convenient but it consumes lots of memory: for each thread his own stack, pre-allocated and over provisioned. Contiki proposes 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 monopolizes the CPU). So Contiki implements preemptive multithreading

Contiki is not the first OS dedicated to portable tiny sensors but this article compares 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 program 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 disabled. Nevertheless, the kernel doesn't provide a power save mode but the scheduler gives 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 contacts 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. Programs can load static libraries that are parts of the core, load run-time libraries, call services implementing specific libraries. The communication part which is essential to a wireless sensor, is provide as a service. Communication service uses synchronous events and so a single buffer for all communicating processes.

Main Contribution

The purpose of this article is to present the advantages of the Contiki OS designed for sensor network. It introduces a new OS that fit well for extended networks which need to work fast and be reliable. Even if other OS exist, this article try to demonstrate Contiki's programmers have though about the best way to do things in every field. This article tries to show Contiki as the future of every sensor network. It is a lightweight OS, which can provides the same features as any portable OS existing, but with much more energy saving and portability.

Applications

Contiki provides a solution to industrial company to managed their machine park. It can be a sustainable solution to manage machine security or productivity, to save wasted energies, to be more efficient. All this, without rebuild their entire network. Industrial applications are various : animal farm condition care, quality of building strucutre monitoring, product quality and machine security monitoring,... Contiki is a first step to unify sensor networks. In a more and more conected society, we can imagine smart cities, where sensors are disposed everywhere to measure air pollution and radiation levels, forest fire detection, smartphone detection, traffic congestion, ... Wireless sensors are the relay between the environnement and a unit control. But with a unified sensors network, we could receive informations and predictions from anywhere to any connected device.