Patché, Linux devient préemptif

T endances
INFORMATI Q U E I N D U S T R I E L L E
OS embarqués :
une mouvance Linux ?

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 systè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” puisque leur temps de réaction avoisine les 10 ms. Dans ce secteur, les solutions Linux
connaissent une vraie croissance et font parler d’elles.
A
vec leurs pérégrinations antarctiques, les manchots du film “La
marche de l’empereur” ont conquis le public et gravi les marches 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 secteur. Les technologies Linux ont régulièrement é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 systèmes d’exploitation temps réels (RTOS) plus
anciens. Un marché qui pesait en 2004 environ un demi milliard de dollars selon le cabinet 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 acceptable dans certains domaines industriels, tels
que les tests et essais avec acquisition de données sensibles. Ou encore le contrôle de process ou les asservissements de matériels,
comme les moteurs pas à pas. Le monde du
MESURES 783 - MARS 2006 - www.mesures.com
transport, qu’il soit terrestre mais aussi et surtout aérien, ne peut non plus faire de compromis sur la qualité du
L’essentiel
logiciel, puisque la sécurité des passagers est en  Grâce à des améliorations
jeu.Tous ces milieux exisuccessives, le système
gent des comportements
d’exploitation Linux se
informatiques sûrs et fiarapproche du temps réel dur.
bles et veulent donc des
La version 2.6 du noyau
comprend la notion de
solutions temps-réel.
préemption. De nombreux
Telle qu’elle est disponiéditeurs proposent des
ble sur Internet, où s’exsolutions Linux incorporant
prime la communauté
des outils de développement
du logiciel libre, la veret parfois des patchs
sion 2.4 de Linux n’offre
d’amélioration.
pas ces garanties de
 Les éditeurs d’OS temps réel
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-
stricts (RTOS) proposent des
solutions adaptées selon les
métiers.
 La volonté de faire tourner
plusieurs systèmes d’exploitation sur le même processeur se fait sentir chez
plusieurs éditeurs.
Différentes techniques sont
étudiées pour y parvenir.
35
Tendances
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. »
Émulation avec Xenomai
Xenomai est un émulateur permettant
de faire migrer facilement des applications de systèmes d’exploitation tempsré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
teur de Montavista. Au centre de ce dispositif
complémentaire proposé par cette société
américaine se trouve l’ordonnanceur ou scheduler 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 notamment que la tâche de plus haute priorité prête
à être exécutée sera bien celle qui sera effectivement 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-
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.
porte la plupart des processeurs 32 bits du
marché comportant une unité de gestion de
la mémoire (MMU). Le noyau est téléchargeable depuis le site www.kernel.org.
Le programmateur finlandais Linus Torvalds
peut donc être fier de son petit Linux, puisqu’il fonctionne désormais avec préemption,
et affiche un temps de latence moyen de 1 à
10 ms. Ce qui peut satisfaire certains utilisateurs : « 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 niveau de criticité n’est pas élevé », expose Philippe
Gauthier, responsable technique pour la so-
Eclipse attire les éditeurs
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 nonproprié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
36
Vers le temps-réel
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 personnalisations », 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’environnement de travail Eclipse ».
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 uniquement sur ce chiffre, qui n’autorise pas vraiment les comparaisons puisque sa détermination 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éveloppeur 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éveloppeurs historiques de Linux. Ce hongrois
se concentre sur l’élimination des goulots
d’étranglement, notamment en ce qui concerne 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é.
MESURES 783 - MARS 2006 - www.mesures.com
Tendances
Un processeur, plusieurs machines virtuelles
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
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-
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.
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 processeurs 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 multicoeurs.
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.
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ésormais différemment selon le métier de l’utilisateur. Elles peuvent être certifiées, selon les
métiers. Ce coup de tampon est primordial
pour certains utilisateurs.
Avionique. Particulièrement friand de solutions de RTOS pour des raisons évidentes de
sécurité, le secteur de l’avionique est chouchouté par les éditeurs. La norme Arinc 653
impose de stricts critères de fonctionnement
du système d’exploitation, comme le partitionnement spatial et temporel de l’OS (voir
en encadré). Très présent sur ce marché,
l’Américain Green Hills propose Integrity178 B, un OS par exemple utilisé sur l’Airbus 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
tiques », selon Stelian Pop. Celui-ci se com- plate-forme dédiée à l’aéronautique nommée
pose de deux grandes parties : d’un côté un IMA (Integrated Modular Avionics). La société
patch qui ajoute au noyau Linux une couche FSMLabs a récemment emboîté le pas : elle
d’abstraction, de l’autre des outils de déve- annonçait en janvier une version Arinc 653
loppement. L’Inria a par exemple utilisé cet du système d’exploitation RTLinux.
OS pour certains projets, comme le pilotage Automobile. Dans le secteur de l’automode robot. À l’école polytechnique de Milan, bile, le standard dominant s’appelle OSEK. Il
il a également été mis en œuvre pour du est promu par un consortium d’industriels
“motion control”.
qui réunissait à l’origine essentiellement des
Fondateur de la société UXP, Robert Jay dé- sociétés allemandes, avec bon nombre de
clare également « utiliser les performances constructeurs automobiles. Aujourd’hui, les
temps réel dur de RTAI dans des applications constructeurs français ont également rejoint
d’automatismes, avec quelques patches en plus. le mouvement. À l’origine de la création de
Mais les projets de supervision se satisfont d’un ce standard, il y a la volonté « d’avoir une counoyau Linux 2.6 ». UXP est d’ailleurs un che entre le noyau et l’application utilisateur qui
pionnier dans le domaine du Linux, puis- soit commune », détaille Frédéric Maraval, resque « cela fait plus de dix ans que nous le mettons ponsable du département outils de dévelopen œuvre dans nos applications, comme dans notre pement pour la société I.S.I.T. En appliquant
atelier d’automatismes Alograf », poursuit les restrictions suivantes : « peu de ressources,
Robert Jay. L’entrepreneur a choisi Linux des contraintes temps-réel, une production de masse
« car il est appréhendable par une majorité de gens. avec un faible coût ». Parmi les différents OS
Et l’absence de licence permet de démocratiser un respectant cette norme, I.S.I.T distribue
peu le temps réel ».
OSEKturbo. Ce système édité par Metrowerks
Pourtant cette solution n’est pas forcément (aujourd’hui propriété de Freescale) cible
un réflexe pour les gens de l’automatisme. des processeurs 8, 16 ou 32 bits. De même,
«L’industriel a horreur du vide et ne veut pas avoir Accelerated Technology propose également une
pour référent une communauté d’utilisateurs sur le version OSEK de son noyau Nucleus.
web. Il est essentiel que le client ait devant lui une L’interface OSEK est disponible chez
personne physiquement responsable», estime Elie Wind River avec OsekWorks.
Gasnier, responsable marketing de Ecrin Industrie. Pour l’industrie et le contrôle de
Systems. Cette société propose également process, les éditeurs ont sorti des versions
MESURES 783 - MARS 2006 - www.mesures.com
37
Tendances
L’OS divisé, pour mieux régenter
Fin de cette tâche
et reprise de la tâche 1
Début de la tâche
plus prioritaire
Fin de la routine
d'interruption ISR
Niveau de priorité
Arrivée d'une tâche
de priorité supérieure
Début de la routine
d'interruption ISR
La notion de préemption est primordiale dans les systèmes temps-réel. C’est la capacité d’un processeur à 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
Le mécanisme de préemption
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
Tache 2
sécurité et sont donc
hypercritiques,
ISR
Tache 1
Tache 1
d’autres sont
Temps de réponse
d’incidence plus faible.
du processus
Temps
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.
Niveau de priorité
interruption
1- Partitionnement temporel
B2
B1
A1
A1
Fenêtre réservée à
l'appli 1
Tâche A2
A2
A3
B3
Fenêtre réservée à
l'appli 2
Temps
Fenêtre réservée à
l'appli 3
APPLI 1
APPLI 2
APPLI 3
2- Partitionnement spatial
RTOS
Hardware
38
appli 1
nommées “61508”, qui certifient une sécurité 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 compagnie 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 applications sont disponibles. Leur empreinte mémoire est très faible, ce qui permet
d’implémenter ces OS sur de petits processeurs. Micriµm possède par exemple un
noyau temps-réel baptisé OS II, distribué par
Neomore en France. « Cet OS n’occupe que quelques 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’exploitation pour le temps réel est large et couvre
la plupart des besoins. Cependant, les éditeurs ont bien saisi qu’ils ne pouvaient se
couper du monde Linux tant celui-ci s’annonce important pour les années à venir.
C’est pourquoi nombre d’entre eux proposent 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 articulé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, responsable 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 pourrait encore citer la compagnie allemande Sysgo
qui propose ElinOS. Sysgo va même un peu
MESURES 783 - MARS 2006 - www.mesures.com
Tendances
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
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 applications 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 logicielle avec la rigueur du temps réel ». Des partitions OSEK, Posix sont aussi au programme.
Les différents sous-ensembles sont séparés.
PikeOS est également certifiable avec les standards 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 planchent 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 éditeurs. Car il est possible de développer des
solutions “maison” de systèmes d’exploitation. 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 équipement embarqué sur deux est implémenté avec un
RTOS “maison” ». Selon lui, cela peut s’expliquer 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 engendre aussi un coût même s’il est moins visible et
que la solution est dépendante du personnel qui possède la compétence spécifique. » L’ajout d’un debugger 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’éditeur Enea s’est récemment greffé au projet et contribue à 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
Temps de latence moyen
Linux
Linux préemptif (2.6)
Linux Preempt_RT
RTLinux
RTAI
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
en développement
stable mais propriétaire
stable, évolutions chaotiques
stable
Les temps de latence indiqués donnent surtout un ordre de grandeur, ce temps dépendant du processeur et de sa charge de travail.
MESURES 783 - MARS 2006 - www.mesures.com
Source : Stelian Pop, Openwide
39