Comment choisir son OS temps réel

Solutions
Solutions
INFO R M A T I Q U E I N D U S T R I E L L E
Comment choisir son OS
temps réel ?
H
Choisir le système d’exploitation le plus adapté à un projet est une tâche ardue, qui peut facilement retarder la mise sur le
marché du produit. Un mauvais choix pourra avoir des conséquences néfastes à long terme, allant jusqu’à l’échec ou l’abandon du projet. Afin de diminuer au maximum les risques, l’architecte système doit utiliser une approche méthodique et
structurée pour le choix de son système d’exploitation temps réel (RTOS), en prenant en compte plusieurs facteurs. John
Patchin, ingénieur système en chef chez LynuxWorks, présente les principales différences entre les RTOS du marché.
42
Deux manières d’accéder à la mémoire
Modèle “à plat”
traditionnel
Task A
Modèle paginé
Adresse non autorisée
Task B
Task C
Kernel
Notification envoyée à la tâche A
L
a plupart des systèmes d’exploitation temps réel du marché – on les
appelle RTOS, pour Real-Time
Operating Systems – partagent globalement les mêmes fonctionnalités, à tel point
qu’aujourd’hui les aspects de “déterminisme” se trouvent relégués en arrière-plan.
En effet, tous les RTOS modernes proposent
des performances relativement similaires en
termes de déterminisme. Pour cela, leur
noyau contient un “ordonnanceur préemptif”, qui garantit que le temps de réaction à
une interruption n’excède jamais une durée
déterminée. La plupart des RTOS du marché
proposent à l’utilisateur de choisir parmi
255 niveaux de priorité pour chaque tâche.
Dans ces conditions, comment faire pour
choisir le système d’exploitation le mieux
adapté à son application ? Différents
L’essentiel
­aspects méritent d’être
PLes systèmes d’exploitation
considérés, et nous
temps réel aujourd’hui
­allons décrire les prindisponibles sur le marché
cipaux. L’industriel
présentent entre eux
devra par la ensuite
de grandes différences.
­estimer lesquels de ces
PPour choisir le RTOS le mieux
critères sont les plus
adapté à une application,
importants pour son
il faut évaluer ses besoins
application.
en termes d’ouverture, de
Au moment du choix
sécurité et de performances.
entre plusieurs RTOS,
PPour minimiser les risques
il est important de
d’échec du projet, l’industriel
bien considérer l’indoit aussi considérer d’autres
terface de programaspects comme le modèle
mation fournie avec
de licences associé au RTOS,
chaque logiciel (on
ou encore le support
technique offert par l’éditeur.
parle aussi d’API, pour
Application Programming
Process A
Process B
Adresse non autorisée
Système de gestion
de la mémoire
Process C
Erreur
matérielle
Kernel
Certains OS temps réel utilisent un modèle de mémoire dit “à plat” (à gauche sur le schéma). Problème : si une application
accède à une adresse mémoire réservée par une autre application, c’est tout le système qui peut planter. Sans compter
les risques liés à la sécurité des données (une personne mal intentionnée peut arriver à accéder à des données, en ouvrant
une porte dérobée dans une autre application ayant un niveau de sécurité inférieur). Une manière d’assurer une meilleure
protection du système est d’utiliser un modèle de mémoire paginé. Tout accès à un espace mémoire non autorisé génère
une alerte qui est envoyée au noyau du RTOS.
Interface). Cette interface réunit toutes les
­librairies, fonctions, procédures ou classes
mises à disposition par l’OS. Le développeur
doit les maîtriser avant de commencer à programmer s’il veut être sûr que la communication entre les différents composants de
l’application se fera correctement.
API standard ou propriétaire ?
Il existe des API propriétaires tandis que
d’autres sont basées sur des standards.
L’adoption d’une API standard assure que
l’application ne sera pas limitée à un seul
RTOS. Le portage sur un nouveau RTOS
pourra se faire automatiquement, excepté
quelques cas pour lesquels des recompilations mineures seront nécessaires.
Dans l’industrie, le standard industriel qui
définit les API pour systèmes d’exploitation
est référencé sous le code POSIX 1003.132003 PSE53. Il est spécifié et maintenu par
le comité de normalisation IEEE. Employé
dans de nombreux systèmes d’exploitation
aussi bien génériques que temps réel, il est
considéré comme la seule interface de programmation réellement portable (il permet
entre autres la portabilité des applications
entre les systèmes Linux et Unix).
Aujourd’hui, sa renommée est telle qu’il
existe une vaste communauté de développeurs POSIX expérimentés.
Les éditeurs savent combien cet aspect de
portabilité est important pour les clients
­finaux. C’est pourquoi, certains OS avec API
propriétaires se déclarent compatibles
POSIX. Ce n’est souvent qu’un argument
MESURES 835 - mai 2011 - www.mesures.com
commercial, car dans la plupart des cas ces
OS ne supportent qu’une infime partie des
librairies POSIX. Etant donné qu’il s’agit de
fonctions non-natives (on a ajouté une
couche d’abstraction au-dessus de l’OS pour
le rendre compatible), elles ne bénéficient
pas des mêmes performances que les fonctions natives et restent par conséquent très
peu utilisées.
Adressage de la mémoire
Concernant l’accès à la mémoire, les RTOS
modernes se divisent en deux catégories. On
trouve d’abord ceux qui utilisent un adressage “à plat” de la mémoire.Avec ce principe,
toutes les tâches partagent un même espace
mémoire. Dans le cas où une tâche accède à
une adresse mémoire qui ne lui était pas
réservée, l’exécution d’une autre tâche peut
être interrompue, voire corrompue. Les problèmes de ce genre, qui peuvent entraîner
un plantage complet de l’application, sont
relativement difficiles à résoudre car ils
­nécessitent des compétences avancées en
débogage. De plus, avec un modèle de
­mémoire à plat, les variables globales qui
sont définies dans une application peuvent
entrer en conflit avec d’autres variables globales qui porteraient le même nom dans
d’autres applications. Ce problème peut survenir lorsque plusieurs équipes de développeurs travaillent sur un même projet. Un
autre cas typique est lorsque plusieurs applications temps réel tournent sur des matériels
différents et qu’elles doivent être intégrées
sur une seule et même plate-forme.
L’autre modèle d’adressage de la mémoire
est le modèle “paginé”. Supérieur par bien
des aspects au modèle à plat, il permet de
définir des espaces mémoire protégés et de
les réserver pour certaines tâches ou applications. Aujourd’hui, ce modèle est devenu
un critère fondamental pour la robustesse
d’un RTOS : il est au cœur du principe de
“partitionnement spatial” mis en avant par
les éditeurs pour promouvoir leurs solutions.
Grâce à la mémoire paginée, si une tâche
tente d’accéder à une adresse mémoire réservée par une autre application, le système
d’exploitation remonte immédiatement une
erreur. Celle-ci est enregistrée dans un fichier
d’erreur, qui peut être récupéré par le développeur et chargé dans un débogueur afin
de déterminer la cause précise du problème.
Certains RTOS génériques poussent encore
un cran plus loin le concept de la pagination
et offrent un partitionnement temporel en
plus du partitionnement spatial. Le partitionnement temporel implique l’utilisation d’un
second ordonnanceur, en complément de
l’ordonnanceur préemptif évoqué plus haut.
Si l’ordonnanceur préemptif est basé sur le
principe de l’interruption (il réagit à des stimulations extérieures pouvant survenir à
n’importe quel moment), l’ordonnanceur
temporel fonctionne de manière cyclique, à
la manière d’une horloge. Chaque tâche peut
être configurée de manière à s’exécuter pendant une période de temps définie, puis
l’ordonnanceur passe à la tâche suivante (il
peut bien sûr s’agir de groupes de tâches).
Ainsi, en associant ordonnanceur préemptif
et ordonnanceur temporel, on évite qu’une
tâche prioritaire ne s’exécute en boucle sans
jamais laisser le temps aux autres tâches de
démarrer.
➜
Applications
(anciennes et nouvelles)
OS Windows
entièrement
virtualisé
OS Linux
entièrement
virtualisé
Autre OS
entièrement
virtualisé
Applications
temps réel
et de
sécurité
RTOS “invité”
paravirtualisé
Applications
client léger
Interface client
léger
paravirtualisé
Noyau de séparation et hyperviseur
Plate-forme matérielle multicœur
Un même hyperviseur peut supporter à la fois des OS paravirtualisés (non modifés) et des OS entièrement virtualisés,
c’est-à-dire optimisés pour garantir leurs performances temps réel avec un hyperviseur donné.
MESURES 835 - mai
MAi 2011 - www.mesures.com
43
Solutions
Solutions
Partitionnement temporel et partitionnement spatial
Partition 0
Partition 2
Partition 3
Partition N
Middleware
GUI
POSIX
LOGICIEL
APPLICATIF
LOGICIEL SYSTEME
MATÉRIEL
Partition 1
POSIX
Application
Ada
Application
Java
OpenGL
Application
POSIX
Application
ARINC
653
Application
LINUX
POSIX
Bibliothèque
Ada
JVM
X Windows
POSIX
APEX
POSIX
User mode
Supervisor mode
Couche TCP/IP
Noyau de partitionnement et couche TCP/IP
Pilotes
de
périphériques
réseau
Pilotes
du
processeur
Interface
Réseau
Microprocesseur
Pilotes
de
périphériques
statiques
Gestion
de
périphériques
PCI
Plate-forme matérielle
Contrôleur
PCI
Pilotes
de
la carte
CFG
Pilotes
de
périphériques
dynamiques
PCI A
PCI B
Partie optionnelle
Les hyperviseurs modernes permettent d’exécuter simultanément des OS invités très différents les uns des autres. L’exemple ci-dessus montre
un système à N systèmes d’exploitation, associant des OS avioniques (APEX) à des machines virtuelles Java, des tâches développées en Ada
et même des OS Windows et Linux.
➜ Un hyperviseur a pour rôle de faire
­cohabiter plusieurs systèmes d’exploitation
sur une seule plate-forme matérielle. Parfois
appelé “moniteur de machine virtuelle”, son
rôle est de tirer parti de toute la puissance
des processeurs modernes pour réduire l’encombrement, le poids et la consommation
d’un système. Longtemps, l’usage des hyperviseurs est resté réservé aux environnements
de type serveurs, mais on assiste aujourd’hui
à une vraie émergence de la technologie
pour les applications embarquées.
On distingue deux grandes familles d’hyperviseurs, désignées par l’appellation type 1 ou
type 2. La plupart des RTOS du marché disposent aujourd’hui d’hyperviseurs de type 1.
Ceux-ci s’exécutent directement sur le matériel à la manière d’une application bare metal,
c’est-à-dire une application codée en langage
machine et qui tourne sans OS sur le processeur. Un hyperviseur de type 1 démarre sitôt
que la carte est sous tension, et il lance ensuite les différents “OS invités” (ou Guest OS).
Grâce à ce type d’hyperviseur, chaque OS
invité peut être stoppé et redémarré indépendamment, sans gêner l’exécution des autres.
De moins en moins utilisés, les hyperviseurs
de type 2 ressemblent davantage à des applicatifs classiques. Ils s’exécutent au sein d’un
OS hôte. Les hyperviseurs de type 2 permettent également de lancer des OS invités, mais
la latence est forcément plus importante
qu’avec un hyperviseur de type 1 (l’OS hôte
et l’hyperviseur représentent deux couches
d’abstraction successives). Un autre inconvénient tout aussi important est qu’il est
impossible de redémarrer l’OS hôte sans
stopper du même coup tous les OS invités.
La question du support
Même en choisissant le RTOS le plus performant
sur le papier, un industriel qui conçoit une
application temps réel pour la première fois aura
forcément besoin du support technique de
l’éditeur. Il est donc important de se renseigner
sur la présence de cet éditeur dans le pays dans
lequel le projet est réalisé. Sans support
technique, certaines étapes comme l’écriture
des couches de communication peuvent vite
devenir un cauchemar. D’abord car la plupart
des RTOS proposent des interfaces réseau ou
44
USB mais les performances de ces dernières
peuvent varier énormément d’un éditeur à
l’autre (en termes de latence et de bande
passante, principalement). Ensuite car il faut que
le RTOS puisse communiquer avec la partie
matérielle. Il est évident que s’il n’existe pas de
drivers pour la carte ou les composants que l’on
souhaite utiliser, il faudra les développer. D’où
l’importance de choisir un éditeur qui propose
des services d’ingénierie si l’on ne dispose pas
des compétences nécessaires en interne.
Mais revenons au principe de base de l’hypervision. Quel que soit le type d’hyperviseur utilisé, l’industriel cherche, avant tout,
à faire tourner différentes applications dans
autant d’OS invités, autrement dit à effectuer
de la virtualisation. Pourtant, il existe deux
manières différentes d’envisager la
­virtualisation.
Certains RTOS proposent ce que l’on appelle
une “virtualisation complète”, en ce sens
que les OS invités ne savent pas qu’ils s’exécutent au-dessus d’un hyperviseur. Par
conséquent, ils n’ont pas besoin d’être modifiés. L’avantage de la virtualisation ­complète
est donc de faciliter l’intégration : chaque OS
invité est utilisé dans sa version commerciale
et aucun développement spécifique n’est
nécessaire. L’inconvénient est à chercher du
côté des performances, car un OS invité
complètement virtualisé subira forcément
une baisse de ses performances et le système
complet sera moins déterministe.
La seconde méthode de virtualisation est
appelée “paravirtualisation”. Cette dernière
implique de modifier le noyau de chaque
OS afin de le faire interagir avec l’hyperviseur
de manière plus directe et optimisée. Cette
solution apporte de meilleures performances
que la virtualisation complète. On l’utilisera
donc pour les applications temps réel “dur”,
pour lesquelles les OS invités ont besoin de
temps de réponse très courts. Seul inconvénient : cette méthode implique d’avoir accès
au code source de chaque OS invité, ce qui
peut être difficile dans certains cas (si l’on
souhaite faire tourner une application sous
Windows, par exemple).
La plupart des RTOS du commerce sont
­vendus accompagnés d’un environnement
de développement. Ce dernier peut aller
d’un simple débogueur graphique (de type
GNU GDB Insight) à un environnement plus
riche de type Eclipse, en passant par toutes
sortes de logiciels propriétaires. Dans l’idéal,
la suite logicielle fournie avec le RTOS doit
inclure au moins un éditeur de code avec
des fonctions d’aide à la syntaxe, un enregistreur temps réel et un outil de visualisation à haute résolution. Ce dernier permettra
au développeur d’optimiser très finement
l’enchaînement des tâches et des instructions sur le processeur cible. Certains RTOS
sont également livrés avec un débogueur
“post mortem”, très utile pour analyser les
fichiers d’erreur générés après un plantage
de l’application.
En termes d’intégration, il est important de
bien prendre en compte la manière dont le
système cible est intégré dans le réseau de
l’entreprise (laboratoire, service R&D ou
autre). En effet, même si le trafic TCP/IP généré par le RTOS est généralement compatible avec les réseaux standard, il faut penser
aux futures communications entre l’équipement temps réel et son environnement final
d’utilisation. Attention donc à dimensionner
et à configurer correctement ce réseau. On
notera à ce sujet qu’avec les RTOS basés sur
UNIX, la configuration sera plus aisée car les
services informatiques de l’entreprise sont
formés à ce type de communications.
Modèle de licence
Après avoir étudié les caractéristiques techniques des RTOS potentiels pour son application, l’industriel pourra étudier le modèle
de licence pour faire son choix final. Dans ce
domaine, l’aspect primordial, quelle que soit
la taille ou la complexité du projet, est la
flexibilité. Dans une entreprise, il y a toujours une proportion de projets qui ne
voient jamais le jour. C’est la raison pour
laquelle il faut bien étudier le modèle de
­licence d’un éditeur avant de s’engager. En
fonction de l’envergure du projet (le nombre
d’équipements à déployer), l’industriel
s’orientera soit vers un éditeur qui impose
une licence annuelle par poste de développement, soit vers un éditeur qui ­demande
une redevance par runtime effectivement
­déployé (le runtime étant la version compilée
de l’OS). Quoi qu’il en soit, il faut garder à
l’esprit qu’un vrai RTOS n’est pas gratuit :
même si un éditeur met en avant des aspects
d’ouverture ou de gratuité de son logiciel, il
faut étudier l’offre en détails pour déterminer ce qui est gratuit et ce qui ne l’est pas.
L’idéal, bien entendu, étant de trouver un
éditeur avec lequel établir de vraies relations
de partenariat pour son projet.
Pour conclure, si le marché des RTOS
­comporte des offres très disparates, c’est
avant tout parce que les industriels de l’embarqué ont tous des besoins très spécifiques.
La technologie est suffisamment au point
pour satisfaire les industriels qui visent les
performances avant tout. Pour les autres, il
s’agira donc de faire un compromis entre les
caractéristiques techniques (type d’hyperviseur, modèle de mémoire, etc.), la richesse
des outils de développement ainsi que le
modèle économique associé à chaque RTOS.
John Patchin, ingénieur système en chef
chez LynuxWorks
et Frédéric Parisot
Compatibilité et ouverture
On l’aura compris, l’industriel devra avoir
une idée précise de l’architecture de son système et du type d’OS invités qui seront utilisés. Il faudra notamment faire attention au
fait que tous les hyperviseurs ne peuvent pas
faire tourner des OS 64 bits et qu’ils ne sont
pas tous capables de faire tourner des OS
invités sur plusieurs cœurs du processeur.
A noter que certaines applications critiques
imposent d’apporter un haut niveau de
­sécurité dans l’isolation des différents OS
invités. Il existe d’ailleurs une norme, la SKPP
(pour Separation Kernel Protection Profile), qui
garantit la séparation des données ou des
flux d’informations entre les OS invités. Cette
norme est régie par l’alliance américaine
NIAP (United States National Information
Assurance Partnership). Pour le moment, le seul
hyperviseur temps réel de type 1 du marché
à implémenter les recommandations de la
SKPP est LynxSecure de LynuxWorks.
MESURES 835 - mai 2011 - www.mesures.com
MESURES 835 - MAi 2011 - www.mesures.com
45