Patché, Linux devient préemptif

MESURES 783 - MARS 2006 - www.mesures.com 35
T
endances
Dans l’informatique embarquée, les niveaux d’exigence n’ont rien à voir avec ceux
de la bureautique. À l’apparition d’une tâche à exécuter, il faut s’assurer qu’elle est
effectivement prise en compte et traitée dans un temps défini à l’avance. C’est là
qu’interviennent les systèmes d’exploitation temps-réel (RTOS) qui assurent que
les tâches seront traitées dans le temps imparti dans 100 % des cas. D’autres sys-
tèmes d’exploitation proposent des solutions qui tendent vers ce critère de qualité,
sans toutefois l’atteindre. Ils sont désignés par l’expression temps-réel “mou” puis-
que leur temps de réaction avoisine les 10 ms. Dans ce secteur, les solutions Linux
connaissent une vraie croissance et font parler d’elles.
Avec leurs pérégrinations antarcti-
ques, les manchots du film “La
marche de l’empereur” ont con-
quis le public et gravi les mar-
ches du box-office. Dans l’informatique, ce
volatile polaire est le totem du monde Linux,
même si à cause d’une erreur de traduction
c’est souvent le pingouin qui y est associé (en
anglais, “penguin” signifie manchot).
Toujours est-il que nombreux sont les acteurs
du monde de l’embarqué à prévoir le succès
de la marche du manchot Linux dans ce sec-
teur. Les technologies Linux ont régulière-
ment été améliorées, ce qui leur ouvre des
débouchés plus larges. Elles lorgnent même
en direction du pré carré des éditeurs de sys-
tèmes d’exploitation temps réels (RTOS) plus
anciens. Un marché qui pesait en 2004 envi-
ron un demi milliard de dollars selon le cabi-
net de consultant
VDC , ce en ne considérant
que les OS temps réels durs, c’est-à-dire ceux
qui garantissent l’exécution d’une tâche dans
un temps prédéfini, quel que soit le cas de
figure ou la charge du processeur.
Nativement, le noyau Linux ne possède pas
de caractéristiques temps-réel. Il n’est pas sûr
qu’il traite une tâche dans le temps imparti et
il se peut même que ce traitement n’aboutisse
jamais. Ce qui n’est bien entendu pas accep-
table dans certains domaines industriels, tels
que les tests et essais avec acquisition de don-
nées sensibles. Ou encore le contrôle de pro-
cess ou les asservissements de matériels,
comme les moteurs pas à pas. Le monde du
transport, qu’il soit terrestre mais aussi et sur-
tout aérien, ne peut non plus faire de com-
promis sur la qualité du
logiciel, puisque la sécu-
rité des passagers est en
jeu. Tous ces milieux exi-
gent des comportements
informatiques sûrs et fia-
bles et veulent donc des
solutions temps-réel.
Telle qu’elle est disponi-
ble sur Internet, où s’ex-
prime la communauté
du logiciel libre, la ver-
sion 2.4 de Linux n’offre
pas ces garanties de
fonctionnement.
Patché, Linux
devient préemptif
« L’éditeur de systèmes
d’exploitation Montavista a
intégré à son offre Linux un
patch préemptif en 1999»
,
expose Abdel Khessam,
responsable des ventes
de Neomore, distribu-
Grâce à des améliorations
successives, le système
d’exploitation Linux se
rapproche du temps réel dur.
La version 2.6 du noyau
comprend la notion de
préemption. De nombreux
éditeurs proposent des
solutions Linux incorporant
des outils de développement
et parfois des patchs
d’amélioration.
Les éditeurs d’OS temps réel
stricts (RTOS) proposent des
solutions adaptées selon les
métiers.
La volonté de faire tourner
plusieurs systèmes d’exploi-
tation sur le même proces-
seur se fait sentir chez
plusieurs éditeurs.
Différentes techniques sont
étudiées pour y parvenir.
L’essentiel
INFORMATIQUE INDUSTRIELLE
OS embarqués :
une mouvance Linux ?

MESURES 783 - MARS 2006 - www.mesures.com
36
T endances
teur de Montavista. Au centre de ce dispositif
complémentaire proposé par cette société
américaine se trouve l’ordonnanceur ou sche-
duler O(1). Ce système met en jeu des niveaux
de priorité, affectés aux tâches à exécuter selon
leur criticité. L’ordonnanceur garantit notam-
ment que la tâche de plus haute priorité prête
à être exécutée sera bien celle qui sera effecti-
vement exécutée. Sans pour autant devenir
déterministe, cette technologie offre de bien
meilleures performances.
Celles-ci sont désormais disponibles pour
tous les utilisateurs, puisque ce patch
préemptif a été intégré dans la version 2.6
de Linux, disponible depuis 2004 et qui sup-
porte la plupart des processeurs 32 bits du
marché comportant une unité de gestion de
la mémoire (MMU). Le noyau est téléchar-
geable depuis le site www.kernel.org.
Le programmateur finlandais Linus Torvalds
peut donc être fier de son petit Linux, puis-
qu’il fonctionne désormais avec préemption,
et affiche un temps de latence moyen de 1 à
10 ms. Ce qui peut satisfaire certains utilisa-
teurs :
« Le niveau de performances fourni par
Linux à l’heure actuelle permet effectivement de
répondre aux besoins de certains industriels dans le
monde de l’embarqué pour des produits dont le ni-
veau de criticité n’est pas élevé »
, expose Philippe
Gauthier, responsable technique pour la so-
ciété de service informatique
Sogeti High Tech.
« Néanmoins, on reste loin des performances des OS
temps réels au sens strict du terme »
, poursuit
l’informaticien.
L’avis est partagé. Consultant pour la société
d’expertise informatique
OpenWide , Stelian
Pop note les avancées apportées par la version
2.6 de Linux, mais estime qu’
« on se trouve dans
des conditions de temps réel mou, avec un respect du
timing prévu dans environ 99 % des cas, mais qui ne
peut être garanti à 100 %. Le risque d’atteindre un
temps de latence infini, et donc qu’une tâche ne s’exé-
cute pas, est toujours présent. »
Vers le temps-réel
Séduisant, mais encore perfectible. Montavista
a récemment apporté une nouvelle pierre à
l’édifice, en annonçant l’été dernier un
temps de latence inférieur à celui que peut
obtenir le premier venu en utilisant le noyau
Linux 2.6.10. Si l’ordre de grandeur de cette
durée donne une idée des performances
d’un OS, il ne faut pas se focaliser unique-
ment sur ce chiffre, qui n’autorise pas vrai-
ment les comparaisons puisque sa détermi-
nation dépend du processeur et de sa charge
de travail. Cependant, l’annonce de
Montavista
évoque
«une réduction du temps de préemption par
un facteur 100 »
, ce qui n’est représente une
avancée considérable et permet à Linux de
se rapprocher des performances des RTOS
au sens strict. Sans toutefois les atteindre.
Pour le temps réel dur, qui garantit que dans
tous les cas de figure la tâche soit exécutée
et ce dans un temps imparti, il faut encore
aller plus loin.
« Les travaux en cours du déve-
loppeur Ingo Molnar portent sur un projet Linux
Preempt_RT qui serait un OS temps réel dur »,
relate Stelian Pop . « J’y travaille avec d’autres » ,
préfère préciser l’intéressé, un des déve-
loppeurs historiques de Linux. Ce hongrois
se concentre sur l’élimination des goulots
d’étranglement, notamment en ce qui con-
cerne la gestion des interruptions. L’objectif
est d’atteindre un temps de latence moyen
d’une dizaine de microsecondes, et que
celui-ci ne dépasse jamais 500 µs. Mais il
faudra attendre un peu avant que ces travaux
n’aboutissent à un Linux temps-réel.
Ou plutôt à un Linux temps réel stable et libre.
Car des solutions “real-time” existent déjà : à
la fin des années 90, un étudiant développait
au sein de l’université du Nouveau-Mexique
RTLinux, un RTOS Linux. Ce produit était
bien Open Source, puisque le code source
était disponible dans le domaine public. Sauf
que l’étudiant en question a par la suite fondé
une société nommée
Fsmlabs , emmenant avec
lui son code pour le faire évoluer de manière
non libre au sein de cette société.
Xenomai est un émulateur permettant
de faire migrer facilement des applica-
tions de systèmes d’exploitation temps-
réel vers un environnement GNU/Linux.
« Il devient donc possible de récupérer
du code source écrit pour VRTX, pSOS+
voire VxWorks et de le faire tourner sur
une plate-forme hôte GNU/Linux », note
l’un des collaborateurs du projet Bruno
Rouchouse. Afin d’émuler le mieux
possible les fonctionnalités des RTOS
classiques, Xenomai repose sur une
déclinaison temps-réel de Linux,
obtenue grâce au projet Adeos. Ce patch
logiciel permet le partage de ressources
matérielles par plusieurs systèmes
d’exploitation concurrents. Adeos
permet ainsi à plusieurs domaines
logiciels organisés par priorité de
fonctionner sur une même plate-forme
matérielle. La couche Adeos permet le
partage des interruptions et des
évenements entre un noyau annexe et le
noyau Linux. Il faut néanmoins adapter
certaines parties du code, « notamment
la gestion des interruptions », tempère
Bruno Rouchouse.
Xenomai dispose pour l’instant de modè-
les implémentant les interfaces de
programmation (API) de VxWorks, Posix
PSE 51, pSOS+, VRTX, RTAI. En plus d’être
un émulateur, Xenomai permet la mise
au point du code source sur une station
Linux avant d’embarquer ce code vers
une carte fonctionnant avec l’un des
RTOS sus-cités.
Émulation avec Xenomai
Accelerated Technology, Enea, Lynuxworks,
Montavista, QNX Software Systems, Wind River
Hormis le fait qu’elles éditent des
systèmes d’exploitation temps réel ou
destinés à l’embarqué, ces sociétés ont
une autre caractéristique commune. Elles
font partie, à des niveaux d’implication
différents, de la fondation Eclipse. Créée
en 2001 sous l’égide d’IBM notamment,
cette communauté open-source a pour
objectif de proposer une plate-forme et
des outils de développement non-
propriétaires. Cela se traduit par un
environnement de développement
intégré (IDE) commun utilisable sur
plusieurs OS. « Du point de vue de
l’utilisateur, la partie édition/contrôle de
l’interface de développement est unique et
disponible sur Internet. Seule l’articulation
avec l’OS est spécifique », précise Luc
Maître, ingénieur systèmes pour
Lynuxworks. Cette interfaçage avec l’OS
peut, lui, être payante. « Ceux qui
utilisent bien le langage Java peuvent
enrichir l’IDE avec leurs propres personna-
lisations », poursuit Luc Maître.
Green Hills n’a néanmoins pas rejoint le
consortium. Pour le responsable du
marketing Chris Smith, « Eclipse n’a pas
été spécifiquement développé pour les
applications embarquées ». Selon lui, l’IDE
Multi de la société va au-delà des
possibilités d’Eclipse. « Dès lors, pourquoi
être membre ? », questionne Chris Smith.
Néanmoins, Green Hills propose « des
plug-ins spécifiques à destination des
clients qui insistent pour utiliser l’environ-
nement de travail Eclipse ».
Eclipse attire les éditeurs

MESURES 783 - MARS 2006 - www.mesures.com 37
T endances
Un groupe de développeurs constitué autour
d’une épine dorsale d’italiens de l’université
polytechnique de Milan a récupéré le projet
initial et les lignes de code, avec l’idée de
poursuivre et améliorer ce projet. Baptisé
RTAI,
« cet OS connaît des évolutions un peu chao-
tiques » , selon Stelian Pop. Celui-ci se com-
pose de deux grandes parties : d’un côté un
patch qui ajoute au noyau Linux une couche
d’abstraction, de l’autre des outils de déve-
loppement. L’Inria a par exemple utilisé cet
OS pour certains projets, comme le pilotage
de robot. À l’école polytechnique de Milan,
il a également été mis en œuvre pour du
“motion control”.
Fondateur de la société
UXP , Robert Jay dé-
clare également
« utiliser les performances
temps réel dur de RTAI dans des applications
d’automatismes, avec quelques patches en plus.
Mais les projets de supervision se satisfont d’un
noyau Linux 2.6 »
. UXP est d’ailleurs un
pionnier dans le domaine du Linux, puis-
que
« cela fait plus de dix ans que nous le mettons
en œuvre dans nos applications, comme dans notre
atelier d’automatismes Alograf »
, poursuit
Robert Jay. L’entrepreneur a choisi Linux
« car il est appréhendable par une majorité de gens.
Et l’absence de licence permet de démocratiser un
peu le temps réel »
.
Pourtant cette solution n’est pas forcément
un réflexe pour les gens de l’automatisme.
«L’industriel a horreur du vide et ne veut pas avoir
pour référent une communauté d’utilisateurs sur le
web. Il est essentiel que le client ait devant lui une
personne physiquement responsable»
, estime Elie
Gasnier, responsable marketing de Ecrin
Systems. Cette société propose également
une offre Linux basée sur le noyau 2.6 pour
les cartes qu’elle distribue.
RTOS : des solutions verticales
adaptées
De leur côté, les éditeurs traditionnels de
RTOS ont affiné leur offre il y a quelques
années, en la verticalisant. Chez nombre
d’entre eux, les solutions se déclinent désor-
mais différemment selon le métier de l’uti-
lisateur. Elles peuvent être certifiées, selon les
métiers. Ce coup de tampon est primordial
pour certains utilisateurs.
Avionique. Particulièrement friand de solu-
tions de RTOS pour des raisons évidentes de
sécurité, le secteur de l’avionique est chou-
chouté par les éditeurs. La norme Arinc 653
impose de stricts critères de fonctionnement
du système d’exploitation, comme le parti-
tionnement spatial et temporel de l’OS (voir
en encadré). Très présent sur ce marché,
l’Américain
Green Hills propose Integrity-
178 B, un OS par exemple utilisé sur l’Air-
bus A380. De même,
Lynuxworks propose une
version de son RTOS Lynx répondant à la
norme DO-178 B, que l’on peut par exemple
retrouver sur des appareils de l’US Air Force.
Le RTOS VxWorks proposé par le leader
WindRiver existe également au sein d’une
plate-forme dédiée à l’aéronautique nommée
IMA (Integrated Modular Avionics). La société
FSMLabs a récemment emboîté le pas : elle
annonçait en janvier une version Arinc 653
du système d’exploitation RTLinux.
Automobile. Dans le secteur de l’automo-
bile, le standard dominant s’appelle OSEK. Il
est promu par un consortium d’industriels
qui réunissait à l’origine essentiellement des
sociétés allemandes, avec bon nombre de
constructeurs automobiles. Aujourd’hui, les
constructeurs français ont également rejoint
le mouvement. À l’origine de la création de
ce standard, il y a la volonté
« d’avoir une cou-
che entre le noyau et l’application utilisateur qui
soit commune »
, détaille Frédéric Maraval, res-
ponsable du département outils de dévelop-
pement pour la société
I.S.I.T. En appliquant
les restrictions suivantes :
« peu de ressources,
des contraintes temps-réel, une production de masse
avec un faible coût »
. Parmi les différents OS
respectant cette norme,
I.S.I.T distribue
OSEKturbo. Ce système édité par
Metrowerks
(aujourd’hui propriété de Freescale) cible
des processeurs 8, 16 ou 32 bits. De même,
Accelerated Technology propose également une
version OSEK de son noyau Nucleus.
L’interface OSEK est disponible chez
Wind River avec OsekWorks.
Industrie. Pour l’industrie et le contrôle de
process, les éditeurs ont sorti des versions
Une utilisation sans
royalties
Une dîme à payer pour chaque
produit construit : utiliser un RTOS
contre un paiement par royalties,
cela peut sembler rigide. D’autant
que ce système impose au client de
fournir une comptabilité de ses
ventes, ce qui n’arrange pas
toujours les industriels qui aiment la
discrétion, comme dans le milieu de
la Défense. Deux bonnes raisons de
trouver d’autres méthodes de
vente. C’est pour cette raison que
les éditeurs proposent à leur clients
de souscrire des abonnements
annuels, d’autres proposent de
payer un droit à développer, valable
pour une ligne de produits, définie
à l’avance. Le code source est
même parfois fourni par l’éditeur.
Dans le domaine de l’avionique, on
partitionne les ressources pour faire
tourner plusieurs applications sur le
même processeur. La virtualisation se
situe encore une étape au-dessus, en
utilisant des machines virtuelles. « Cela
consiste à faire tourner plusieurs
systèmes d’exploitation (OS) sur le même
processeur », déclare Pierre Coulombeau
de la société grenobloise Trango
Systems. Cette entreprise édite la couche
logicielle Trango, qui partage les
ressources du processeur entre les
différents systèmes d’exploitation. Mais
Trango ne fournit pas le RTOS : si
l’application en nécessite un, alors il faudra
se le procurer ailleurs.
À chaque OS est associé une fenêtre
temporelle durant laquelle il peut
s’exprimer. Puisque l’hyperviseur Trango est
destiné au temps-réel, la préemption entre
les systèmes d’exploitation est prévue : un
OS critique prendra la main sur un OS
gérant des applications non critiques.
Pour l’instant, cet hyperviseur logiciel a
surtout trouvé des débouchés dans le
monde des télécoms, certaines
applications nécessitant du temps-réel.
Pierre Coulombeau insiste sur la garantie
de sécurité apportée par Trango : « Dans
des équipements de type télécoms, la
partie qui communique avec l’extérieur
peut être attaquée. Mais cette agression
restera confinée à une machine virtuelle
sans se propager aux autres, pilotées par
des OS différents ».
Occupant un emplacement mémoire
très faible, autour de 15 ko, Trango est
aujourd’hui utilisable avec les proces-
seurs Arm, Mips et bientôt PowerPC.
Parmi les combinaisons possibles, on
peut par exemple faire tourner un
système d’exploitation temps-réel avec
un OS Linux. Le système fonctionne
également avec les processeurs multi-
coeurs.
Si pour l’instant les applications sont
orientées vers le monde des télécoms, la
solution peut être déployée en milieu
industriel ou dans l’automobile.
Un processeur, plusieurs machines virtuelles

MESURES 783 - MARS 2006 - www.mesures.com
38
T endances
nommées “61508”, qui certifient une sécu-
rité fonctionnelle conforme à celle prônée
dans la norme IEC 61508, de la Commission
Électrotechnique Internationale. Dans ce cré-
neau, on peut par exemple retrouver la com-
pagnie suédoise Enea avec son RTOS nommé
OSE. Ou encore
Green Hills , Integrity se dé-
clinant en version 61508, agréée Safety
Integrity Level 3.
Télécommunications. Comme les autres,
ce domaine est particulièrement ciblé par
des distributions spéciales des RTOS proprié-
taires. On y retrouve la plupart des acteurs
déjà cités.
RTOS de poche. Enfin, des solutions spé-
cialement conçues pour les petites applica-
tions sont disponibles. Leur empreinte mé-
moire est très faible, ce qui permet
d’implémenter ces OS sur de petits proces-
seurs.
Micriµm possède par exemple un
noyau temps-réel baptisé OS II, distribué par
Neomore en France. « Cet OS n’occupe que quel-
ques kilo-octets (moins d’une dizaine), si l’on ne
considère que le code et pas les piles protocolaires »
,
précise Abdel Khessam de
Neomore.
« Ne pas se couper de la
communauté Linux »
En somme, la palette des systèmes d’exploi-
tation pour le temps réel est large et couvre
la plupart des besoins. Cependant, les édi-
teurs ont bien saisi qu’ils ne pouvaient se
couper du monde Linux tant celui-ci s’an-
nonce important pour les années à venir.
C’est pourquoi nombre d’entre eux propo-
sent des solutions, plus ou moins récentes,
articulées autour de Linux et destinées au
monde de l’embarqué et de l’industriel.
L’annonce faite à ce sujet par
Wind River en
2003 est hautement symbolique : la société
avait
« étendu son offre en proposant un support aux
clients qui développent des applications embarquées
sous Linux »
. Aujourd’hui, Wind River possède
donc une plate-forme de développement ar-
ticulée autour du noyau Linux 2.6.10.
« C’est
une volonté de notre part de ne pas nous éloigner de la
communauté Linux,
précise Éric Faure, respon-
sable service avant-vente de
Wind River . Nous
ne rajoutons donc pas ou peu de patchs spécifiques ».
La part des activités Linux est loin d’être né-
gligeable dans le chiffre d’affaires de l’éditeur,
puisque selon Éric Faure, elle oscille
« autour
de 10 % »
et est en augmentation.
De même,
Lynuxworks commercialise BlueCat.
« En étant basé sur le noyau 2.6 de Linux, cet OS
atteint des performances de temps-réel mou, avec en
plus des outils de développement adaptés aux besoins
des utilisateurs »
, dépeint Luc Maître. On pour-
rait encore citer la compagnie allemande
Sysgo
qui propose ElinOS.
Sysgo va même un peu
La notion de préemption est primordiale dans les systèmes temps-réel. C’est la capacité d’un proces-
seur à traiter une tâche de haute priorité le plus rapidement possible après son apparition, alors
qu’une tâche de priorité inférieure est en cours de traitement.
Quand arrive une interruption, synchrone ou non (événement extérieur), si celle-ci implique une
tâche de priorité supérieure, une routine d’interruption ISR est lancée. Celle-ci peut durer plus ou
moins longtemps selon la complexité de la tâche en cours. Le travail sur des variables partagées
induit souvent par exemple une durée plus longue de la routine d’interruption. Une fois celle-ci
terminée, le processeur bascule sur sa nouvelle tâche de priorité supérieure. Le temps écoulé entre
l’arrivée de l’interruption et le basculement effectif du processeur sur sa nouvelle tâche est appelé
temps de préemption. Le processeur mène cette nouvelle tâche à bien, à moins qu’une tierce tâche
de priorité encore plus grande n’arrive.
Certains métiers ont
des exigences
particulières. Dans le
monde de l’avionique
par exemple, les
exigences sont très
fortes alors que
cohabitent souvent
plusieurs applications.
Certaines ont trait à la
sécurité et sont donc
hypercritiques,
d’autres sont
d’incidence plus faible.
Avec les évolutions
successives des
capacités de calcul des processeurs, le même processeur peut gérer toutes ces tâches. Afin que
celles-ci ne se perturbent pas mutuellement, la norme Arinc 653 spécifie un partitionnement spatial
et temporel des ressources.
Spatial, car la mémoire est découpée en zones exclusives. Chaque zone ne peut être atteinte que
par une seule application, la seule autorisée à écrire des données dans cette zone. Chacune de ces
zones peut donc être vue comme un ordinateur indépendant.
Temporel, car la base de temps est divisée. Des fenêtres temporelles sont allouées à chaque application.
La succession de ces fenêtres constitue la trame principale, qui se répète. À l’intérieur de chacune des
fenêtres, une seule application tourne. Dans cette fenêtre, plusieurs tâches peuvent être lancées. Selon
leur niveau de priorité, elles se prennent ou se donnent la main, toujours de façon préemptive. Cette
technique permet d’allouer à chaque application un temps minimal d’utilisation du processeur.
L’OS divisé, pour mieux régenter
Tache 1 Tache 1
Tache 2
ISR
Temps
Temps de réponse
du processus
Niveau de priorité
Arrivée d'une tâche de priorité supérieure
Début de la routine d'interruption ISR
Fin de la routine d'interruption ISR
Début de la tâche plus prioritaire
Fin de cette tâche et reprise de la tâche 1
Le mécanisme de préemption
appli 1
Fenêtre réservée à
l'appli 3
Fenêtre réservée à
l'appli 2
Fenêtre réservée à
l'appli 1
interruption
Temps
Niveau de priorité
1- Partitionnement temporel
2- Partitionnement spatial
A1 A1
Tâche A2
APPLI 1 APPLI 2 APPLI 3
B1
B2
A2 A3
B3
RTOS
Hardware

MESURES 783 - MARS 2006 - www.mesures.com 39
T endances
plus loin en proposant un concept intéressant
mêlant systèmes d’exploitation temps-réel et
Linux, nommé PikeOS.
Ce logiciel est à la base un RTOS dur. Sauf
qu’avec ce produit, il est en plus possible de
réaliser un partitionnement des ressources
pour faire tourner sur le processeur à la fois
des applications sensibles avec le RTOS et
d’autres moins critiques. Comme des appli-
cations Linux par exemple. Pour Jose
Almeida, ingénieur d’application chez Sysgo,
« certains souhaitent faire cohabiter Linux et un
RTOS pour combiner une certaine ouverture logi-
cielle avec la rigueur du temps réel ».
Des parti-
tions OSEK, Posix sont aussi au programme.
Les différents sous-ensembles sont séparés.
PikeOS est également certifiable avec les stan-
dards DO-178B, IEC 61508. Sysgo y voit des
débouchés dans le contrôle industriel, ou
pour piloter les multiples processeurs pré-
sents dans une automobile et qui gèrent à la
fois des applications sécuritaires et d’autres
de confort. Cette solution se démarque des
récentes offres en virtualisation (voir enca-
dré) par le fait qu’elle intègre un RTOS, qui
peut d’ailleurs être utilisé seul si tel est le
besoin. À noter que d’autres éditeurs plan-
chent sur ce type de solutions et comptent
bien proposer leurs solutions.
Fait “maison”
Certains décident malgré tout de se passer
de cette valeur ajoutée apportée par les édi-
teurs. Car il est possible de développer des
solutions “maison” de systèmes d’exploita-
tion. Travaillant pour
Accelerated Technology et
par ailleurs auteur de l’ouvrage
« Embedded
Software, the works »
, Colin Walls rapporte que
« certaines études montrent qu’environ un équipe-
ment embarqué sur deux est implémenté avec un
RTOS “maison” ».
Selon lui, cela peut s’expli-
quer par la volonté de contrôler le processus
de A à Z, d’obtenir une adéquation parfaite
du système aux besoins de l’application mais
aussi pour des raisons économiques puisque
l’absence de licence à payer fait passer ce
coût inaperçu.
Mais comme ses concurrents, Colin Walls
rappelle que
« le développement d’un RTOS en-
gendre aussi un coût même s’il est moins visible et
que la solution est dépendante du personnel qui pos-
sède la compétence spécifique. »
L’ajout d’un de-
bugger ou le développement des pilotes
compliquent encore l’affaire.
Car finalement
« le choix du système d’exploitation
n’est qu’un aspect du problème »,
nuance Éric Faure.
L’environnement de développement qui entoure
l’OS est également à prendre en compte :
« boîtes
à outils, formation des collaborateurs, support technique,
service, facilité d’adaptation d’une solution, les partenaires,
tous ces facteurs ont leur importance »
, poursuit Éric
Faure.
Wind River regroupe toutes ces notions sous
le sigle de DSO, Device Software Optimization. Ce
concept
a priori marketing vise à réduire le temps
de mise sur le marché et améliorer la fiabilité des
logiciels. Et le DSO fait des émules, puisque l’édi-
teur
Enea s’est récemment greffé au projet et con-
tribue à l’animation du site internet www.dso.
com. À la une de celui-ci, on peut lire dans un
article sur les logiciels embarqués dans le monde
de la téléphonie mobile
« Linux Calling ! » .
Pierre Hardoin
Les différentes déclinaisons de Linux
Linux Linux préemptif (2.6) Linux Preempt_RT RTLinux RTAI
Temps de latence moyen 1-10 ms 1-10 ms 20-30 µs 5 µs 5 µs
Temps de latence maximal infini infini 100-500 µs 10 µs 10 µs
Etat de la solution stable stable en développement stable mais propriétaire stable, évolutions chaotiques
Les temps de latence indiqués donnent surtout un ordre de grandeur, ce temps dépendant du processeur et de sa charge de travail.
L’évolution de Linux et les marchés visés
Linux, aujourd’hui, ne répond
pas encore à l’ensemble des
besoins du temps réel. On voit
ici que les versions successives
(2.4, 2.6, 3.x etc.) apportent
une amélioration du temps de
réponse.
Le diagramme du bas situe
les besoins “temps réel” des
grands secteurs d’applications.
Montavista
Source : Stelian Pop, Openwide