InitRech 2015/2016, sujet 26 - Historique des versions

Gvillemo : /* Applications */

2016-06-18T18:09:50Z

‎Applications

Gvillemo : /* Main Contribution */

2016-06-18T17:43:34Z

‎Main Contribution

Gvillemo le 18 juin 2016 à 17:38

2016-06-18T17:38:55Z

Gvillemo : Page créée avec « = 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 ... »

2016-06-18T16:26:48Z

Page créée avec « = 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 ... »

Nouvelle page

= 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.

= Main contribution =

= Applications =

← Version précédente		Version du 18 juin 2016 à 18:09
Ligne 26 :		Ligne 26 :

	= Applications =		= 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.

@@ Ligne 22 : / Ligne 22 : @@
 = Main Contribution =
-The purpose of this article is to present the advantages of the Contiki OS designed for sensor network. It introduce 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.
+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.
+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 =

@@ Ligne 1 : / Ligne 1 : @@
 = 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.
+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 provide a multiplatform OS with the desire to unify wireless sensors.
+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 microcontroller don’t care about memory protection.)
+(Most of microcontrollers don’t handle memory protection.)
-Multithread is convenient but it’s consume lots of memory: for each thread his own stack, pre-allocated and over provisioned.
+Multithread is convenient but it consumes 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 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 compare his benefits to existing OS.
+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 programm loader and some processes which can be an application or a service used by multiple applications.
+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 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.
+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 contact the service layer that provides the service ID for the application requests. Both processes and services can be dynamically loaded and replaced.
+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. Programms can load static libraries that are parts of the core, load run-time libraries, call services implementing specific libraries.
+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 =
+= Main Contribution =
 = Applications =