Prototypage des applications

temps rel embarques

par Nicolas DU LAC

Directeur Technique, socit INTEMPORA SA

1. Problmatique du prototypage dapplications embarques........ S 8 192-2

1.1 Objectifs recherchs .................................................................................... 2
1.2 Outils mettre en uvre ............................................................................ 2
1.3 Scnarios dexprimentation...................................................................... 3
1.4 Matriel......................................................................................................... 3
1.5 Paris du logiciel............................................................................................ 3
2. Notions de temps et de temps rel..................................................... 3
2.1 Notion de temps rel mou ou traitement la vole ..................... 3
2.2 Notion de temps rel dur ou temps rel dterministe ....................... 3
2.3 Architectures logicielles pour le prototypage ........................................... 4
2.3.1 Systmes dexploitations ................................................................... 5
2.3.2 Langages de programmation ............................................................ 5
3. tapes du prototypage ........................................................................... 6
3.1 Spcification, choix et mise en place du matriel..................................... 6
3.2 Capteurs utiliss .......................................................................................... 6
3.3 Acquisition et enregistrement des donnes.............................................. 8
3.4 Dveloppement des algorithmes ............................................................... 9
3.5 Utilisation de circuits intgrs spcifiques................................................ 10
3.6 Du prototype lindustrialisation............................................................... 11
4. Conclusion et perspectives................................................................... 11
Rfrences bibliographiques ......................................................................... 11

es applications temps rel embarques sont des systmes installs sur des
L plates-formes mobiles (avions, automobiles, plates-formes robotiques
mobiles...) et fournissant ainsi certains services tels que la prsentation dinfor-
mations sur lenvironnement du vhicule (dtection dobstacles, cartographie),
le contrle de tout ou partie de ce vhicule (ractions en cas de danger, pilotes
automatiques) ou encore le relais pour lchange de donnes (satellites de
communications).
Ces applications existent ainsi depuis quelques dizaines dannes (systmes
dinstrumentations dans les avions, les fuses ou les satellites par exemple),
mais nont toutefois pas encore envahi notre quotidien, restant jusqu prsent
cantonnes des systmes de haute technologie. Cela fait relativement peu de
temps que le grand public voit apparatre des produits grand public ainsi
quips : ordinateurs de bord, contrle de la vitesse dune automobile, mtros
sans conducteur.... Il y a fort parier que la dcennie qui va suivre verra ce type
dapplications se multiplier dans notre environnement, notamment dans le
domaine de lassistance la conduite ou encore au niveau des systmes de
scurit.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur S 8 192 1
PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES _________________________________________________________________________________

Ces applications seront de plus en plus complexes, faisant intervenir des

capteurs varis et exigeants (vido, radars, tlmtres laser, capteurs infra-
rouges, centrales inertielles, modules de communications radio...). Elles
devront notamment savoir communiquer, dune part avec des stations fixes de
linfrastructure qui les entoure, et dautre part entre elles (mise jour de
donnes, alertes).
Face la concurrence croissante dans le domaine du dveloppement de
telles applications, les industriels recherchent de plus en plus defficacit. On
vise non seulement la rduction des cots de dveloppement, mais aussi celle
du temps de dveloppement dun prototype fonctionnel, puis le dlai jusqu
industrialisation et commercialisation du produit final.

1. Problmatique
du prototypage
dapplications embarques
1.1 Objectifs recherchs
lheure actuelle, les systmes embarqus tentent dexploiter
au mieux les progrs de llectronique et de linformatique
(figure 1). On dveloppe ainsi des systmes de plus en plus perfor-
mants et exigeants en termes de puissance de calcul embarque,
de dbits de donnes grer, de capacit de stockage et de minia-
turisation.
Les matriels utiliss sont trs divers. Il nest plus rare de voir
des camras vido sur des systmes embarqus, lesquelles seront
souvent associes dautres capteurs complmentaires. On
aboutit de plus en plus de cette faon des systmes capables
dexcuter des algorithmes de fusion de donnes. Les algorithmes
mis en uvre sont ainsi de complexit croissante : un systme
embarqu temps rel est dautant plus difficile dvelopper et
industrialiser. Il est aujourdhui inconcevable de dvelopper un
systme complexe sans passer par plusieurs tapes telles que la
ralisation dun ou plusieurs prototypes et leur mise au point, des
phases de tests exhaustifs, de portage de la plate-forme de proto-
typage vers des plates-formes de prsrie puis de srie...
Face cette multiplication des tapes et donc aussi des cots,
les industriels vont avoir pour objectifs principaux :
la rduction du temps entre la dcision du dveloppement
dun premier prototype et la mise sur le march dun systme
( time to market ) ;
la matrise des cots de recherche et dveloppement : il faut
savoir valuer le plus tt possible la faisabilit dun systme et le
budget ncessaire son dveloppement ;
la recherche ventuelle, mais dsormais assez frquente, de
partenaires de manire mutualiser les cots et mettre en
commun les connaissances ;
la capitalisation des savoirs, permettant autant que possible
de rutiliser les briques existantes et robustes des systmes
prcdents.
1.2 Outils mettre en uvre
Pour toutes ces raisons, il nest plus possible (ou tout au moins
plus raisonnable) denvisager le dveloppement ex nihilo dun
systme embarqu. Les constructeurs, bureaux dtudes ou labo-
ratoires doivent se doter doutils qui leur permettront deffectuer des
dveloppements efficaces et robustes en un minimum de temps.
Camra
stro
Camra ddie
au positionnement latral
HP1 pour radar
courte porte
Laser
HP1 pour radar HP2 pour radar
longue porte courte porte
Radar longue porte
Figure 1 Le projet europen CARSENSE (www.carsense.org)
Quelles sont les spcificits de ces outils ? Quelles sont les
qualits requises ?
Tout dabord, le prototypage ncessite de pouvoir tudier, puis
essayer et tester un nombre important de solutions diffrentes :
essayer diffrents algorithmes, les comparer, les fusionner, essayer
alors diffrentes mthodes de fusion...
Pour cela, un bon outil de dveloppement doit tre souple et
modulaire. La plupart des ateliers logiciels mettent ces qualits en
uvre en proposant des ateliers de programmation graphique :
lutilisateur dispose dune banque de botes fonctionnelles ,
chacune permettant deffectuer une opration bien prcise sur un
type de donnes particulier, quil suffit de connecter entre elles pour
organiser les flux de donnes et les oprations successives qui leur
sont appliques. En bout de chane, une bote de contrle-
commande, de visualisation ou denregistrement permet dexploiter
les donnes traites. Ces logiciels doivent alors pouvoir tre
complts volont de nouvelles botes, apportant de nouvelles
fonctionnalits et de plugins (extensions logicielles) leur permettant
de sadapter aux besoins divers des utilisateurs (banques de fonc-
tions de traitement du signal, de traitement dimages, etc.).
La plupart proposent dailleurs la possibilit de programmer
leurs propres modules via des langages de programmation
standards ou propritaires, puis de les intgrer dans les applica-
tions en dveloppement.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 2 Techniques de lIngnieur
________________________________________________________________________________ PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES
1.3 Scnarios dexprimentation
Le second point que doivent respecter ces outils concerne le
besoin de fiabilit et de reproductibilit. En effet pour effectuer des
tests sur un systme embarqu, pour mettre au point son param-
trage, lutilisateur a besoin dune reproductibilit sans faille des
conditions dexprimentation, en admettant que les mmes causes
produisent les mmes effets. Lenvironnement mis en place pour
tester la raction dun systme avec un jeu de paramtres doit
pouvoir tre reconstitu lidentique pour tre en mesure de tester
le mme systme rgl diffremment.
Une premire tape consistera par exemple en la dfinition de
scnarios (dits scnarios thoriques) sur lesquels le systme sera
cens fonctionner correctement. Ces scnarios dfiniront la plupart
des conditions relles dans lesquelles on aura prvu de faire voluer
le systme (figure 2).
Exemple : dans le domaine automobile, on dfinira les conditions
climatiques dune exprience, les types de capteurs ou dactionneurs
mis en uvre, le type de vhicule mis en jeu...
Une fois les scnarios dfinis, il faudra les mettre en uvre.
Sil nest pas ais de pouvoir reconstituer de faon rptable des
conditions dexprimentation donne, il faut pouvoir enregistrer
tous les paramtres dentre du systme pour pouvoir les lui
rinjecter volont durant la phase de dveloppement et de mise
au point. Dans le cas o lon prototype un systme mettant en jeu
une boucle de contrle-commande, il faudra avoir recours la simu-
lation.
1.4 Matriel
De manire tre la fois modulaire, souple et reproductible, un
environnement de prototypage doit tre constitu, autant que
possible, de matriels standards. Les cots de conception et/ou de
dveloppement dun matriel spcifique sont incomparables avec
ceux dun matriel standard produit en srie et cest sans parler des
dlais de mise en uvre... Dans le cas o aucun matriel standard
ne pourrait rpondre au besoin, il sera parfois beaucoup plus avan-
tageux davoir recours la simulation logicielle.
Enfin, comme nous lavons dit, les structures de recherche et
dveloppement souhaitent bnficier de toutes les synergies
possibles. Elles visent changer non seulement des rsultats,
mais aussi des donnes, des connaissances, des scnarios de
tests, etc. Chaque brique utilise dans la chane de prototypage
doit donc, idalement, pouvoir tre stocke, exporte et partage
entre diffrents centres de dveloppement.
Base de scnarios
thoriques
Mise en uvre Modlisation
Base de scnarios rels
Base de scnarios
partir de donnes relles en
simuls
temps rel ou enrigistres
Dveloppements,
tests et mise au point
Figure 2 Scnarios thoriques, rels et simuls
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
1.5 Paris du logiciel
On se pose souvent la question des performances dites temps
rel de solutions logicielles. On entend ainsi souvent dire
Windows nest pas un systme dexploitation temps rel. Telle
application devra tourner sur QNX ou VxWorks. . Or, il existe bien
des applications sous Windows permettant de faire du traitement
de donnes en temps rel. Le terme adapt serait alors plutt
la vole ou bien en temps continu . Nous dfinirons plus pr-
cisment les notions de temps rel dans le paragraphe 2. Nan-
moins, notons quil est souvent beaucoup plus ais de prototyper
un systme embarqu sur un systme dexploitation grand public
tel que Windows, dot de bonnes performances globales qui
suffiront, dans de nombreux cas, assurer des temps de rponse
adquats (de lordre de la milliseconde, ou de quelques milli-
secondes), et qui offrent des solutions logicielles de prototypage
plus compltes, des environnements de dveloppements efficaces,
et un choix de drivers ou pilotes matriels plus larges que sur les
systmes dexploitation spcialiss dans le temps rel.
Enfin, on soriente aussi de plus en plus vers des solutions tout
logiciel , o lon trouve en amont, non pas des donnes relles,
mais provenant de bases de donnes ou bien gnres par simu-
lateur. Cest depuis longtemps le cas dans le domaine de laronau-
tique, et la simulation prend une part de plus en plus importante
dans le secteur automobile par exemple. Lintrt de la simulation
en amont est de pouvoir construire un systme dterministe, ractif
et paramtrable. On peut laide dun simulateur gnrer toutes
sortes de situations et constituer ainsi des scnarios types dans
lesquels le systme dvelopp sera susceptible dvoluer.
2. Notions de temps
et de temps rel
2.1 Notion de temps rel mou
ou traitement la vole
On entend souvent quune application ralise une tche donne
en temps rel . Cela signifie souvent que lapplication est suffi-
samment performante pour traiter la vole et sans perte dinfor-
mation toutes les donnes provenant dun ou plusieurs capteurs,
sans atteindre la capacit maximale de calcul quelle a sa dispo-
sition. Ainsi, toutes les donnes en entre sont prises en compte par
lacquisition et participent la tche ralise. Dans la plupart des
cas, les donnes sont traites suffisamment rapidement pour
permettre lobtention des rsultats en un temps infrieur la
constante de temps rgissant lvolution du systme peru par les
capteurs. Ceci permet lapplication de ragir aux volutions de
lenvironnement.
Exemple : citons les applications denregistrement de vido sur PC
( partir dune carte Tuner/TV) avec compression logicielle (plus ou
moins performante selon la puissance du PC...).
Nanmoins, le terme temps rel au sens propre a une autre
signification. Ainsi, les puristes soutiendront que Windows nest
pas un systme dexploitation temps rel . Pourtant, il est bel et
bien possible de visionner un dvd sous Windows...
2.2 Notion de temps rel dur
ou temps rel dterministe
Ce quapportent de vritables systmes dexploitations temps
rel se trouve sur le plan du dterminisme. On qualifiera de
temps rel une application qui garantit quune tche donne sera
excute dans le pire des cas en une dure connue et borne.
S 8 192 3
PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES _________________________________________________________________________________
Ceci prend son sens dans le cas o plusieurs tches tournent en
parallle sur un mme processeur. Si parmi ces tches, il en existe
une qualifie de critique , cest--dire dont la boucle de
traitement doit se drouler imprativement dans un intervalle de
temps donn sous peine de dfaillance du systme complet, il
faudra alors sassurer que les autres tches nauront pas la possi-
bilit de venir perturber la tche critique au point de lempcher de
faire son travail dans les temps. Cette dfinition ne prend pas du
tout en compte un quelconque critre de performance pure, il sagit
simplement dune assurance sur le dlai de ralisation des tches
critiques.
Exemples
1. Une illustration classique est celle dun contribuable devant payer
ses impts avant le 15 septembre de lanne en cours. Cette situation
peut tre considre comme un systme temps rel dur : si ledit
contribuable dpasse cette date, le fonctionnement du systme
devient anormal.
2. Prenons le cas (plus srieux) dune application de contrle latral
dune automobile par vision : une ou plusieurs camra(s) se charge(nt)
de lacquisition des images. Un calculateur embarqu ralise le
traitement dimages et, en fonction des rsultats, commande la
colonne de direction du vhicule. Les commandes doivent tre
envoyes priode prcise aux actionneurs de la colonne de direction
(disons une commande toutes les 10 ms). Sachant que le processeur
ne peut excuter quune tche la fois, il faut que la tche du calcula-
teur qui se charge de ces envois de commandes soit prioritaire par
rapport toutes les autres (y compris par rapport la tche dacquisi-
tion des donnes, la tche de traitement des images, la tche daffi-
chage des images sur un cran ventuel, etc.). De mme, les tches
dacquisition dimages et de traitement seront prioritaires par rapport
la tche daffichage sur cran (cette dernire ntant pas critique dans
ce contexte).
Ainsi, au moment o la tche de commande doit prendre la main,
elle est capable dinterrompre et de mettre en attente la tche cou-
rante pendant le laps de temps quil lui faut pour envoyer sa
commande (disons 0,5 ms), puis rend la main la tche quelle a inter-
rompu.
Lexcution des tches peut tre schmatise par le diagramme
de la figure 3.
La tche T1, trs courte, est donc excute toutes les 10 ms en
interrompant la tche courante, quelle quelle soit (T4 en loccur-
rence), laquelle est elle-mme interrompue par T2 lors de larrive
dune image. T2 est suivie par T3 (traitement de limage), puis T4
peut reprendre. Le systme est dterministe dans le sens o on est
sr que la commande est envoye toutes les 10 ms, et o la chane
critique Acquisition Traitement Commande a le temps de
sexcuter (la camra vido peut ici tre considre comme un
capteur synchrone, dlivrant une donne toutes les 40 ms). La
tche, non critique, daffichage des images utilisera tout ou partie
de la puissance de calcul restante sur le processeur.
Au niveau des dures dexcution de chaque tche :
T1 sexcute toujours en 0,5 ms (D1) ;
T2 sexcute au mieux en 6 ms (D2) et au pire en 6,5 ms
(D2 + D1) ;
T3 sexcute au mieux en 6 ms (D3) et au pire en 12,5 ms
(D3 + D2 + D1). Nanmoins, dans ce cas, on peut considrer quelle
sexcute squentiellement aprs la tche T2, donc quelle ne peut
tre interrompue par T2 elle-mme. Ce qui donne une dure dex-
cution maximale de 6,5 ms (D3 + D1) ;
T4, qui sexcuterait mettons en 30 ms si elle ntait pas
interrompue, utilise donc le reste de la puissance de calcul du pro-
cesseur. Elle na pas le temps de sexcuter entirement chaque
arrive dimage, ce qui fait que certaines images ne seront pas
affiches. Nanmoins, cela ne nuit pas au fonctionnement du
systme.
Le cas prsent ici est simple car il ne prsente que quatre tches.
Il est vident quun systme dexploitation complet doit grer un
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 4 Techniques de lIngnieur
Fin du traitement
Envoi d'une Envoi d'une T4 reprend et/ou
commande : commande : succde T3
T1 interrompt T4 T1 interrompt T2
Envoi d'une
Arrive d'une image Fin de l'acquisition commande :
T2 interrompt T4 T3 succde T2 T1 interrompt T4
T1 T4 T2 T1 T3 T1 T4
t t + 10ms t + 20ms
(1) T1 : tche de commande. Priorit 4 (plus haute priorit)
(2) T2 : tche d'acquisition des images. Priorit 3
(3) T3 : tche de traitement des images. Priorit 2
(4) T4 : tche d'affichage. Priorit 1 (plus faible priorit)
Figure 3 Ordonnancement des tches sur un microprocesseur
nombre de tches beaucoup plus important (tches systmes
daccs aux fichiers, de gestion de la mmoire, de gestion des
entres utilisateurs clavier et souris, autres applications, etc.). On
comprend que la conception dune application comprenant plu-
sieurs capteurs, parfois asynchrones, doit tre trs rigoureuse car
elle est complexe. Seules quelques tches pourront tre conues
pour tre excutes de faon dterministe.
De mme, il faudra aussi concevoir des architectures matrielles
respectant ces contraintes de temps rel dterministe. Cest parti-
culirement le cas en ce qui concerne les bus de donnes sur les-
quels sont connects plusieurs capteurs. Cest le cas du bus CAN
par exemple, o chaque capteur connect au bus se voit affecter un
identifiant, lequel lui dfinit une priorit. Si deux capteurs ou plus
tentent dmettre une donne sur le bus, seul le capteur dot de
lidentifiant de priorit la plus haute pourra mettre sa donne. Les
autres capteurs se mettront alors momentanment en attente
jusqu libration du bus, avant de tenter nouveau lmission.
2.3 Architectures logicielles
pour le prototypage
Est-il cependant toujours ncessaire de raliser des systmes
temps rel dterministes pour le prototypage dapplications embar-
ques ?
Il faut garder lesprit que, en matire de prototypage, le but est
de dvelopper le plus rapidement possible un systme qui fonc-
tionne. On essaie de dmontrer la faisabilit dun systme, et non
de concevoir ds le dbut le systme tel quil sera industrialis.
Le prototypage sert dterminer quels seront les algorithmes
utiliss dans le systme final et quelles seront les performances
obtenues, quel cot, laide de quel matriel.
Pour cela, on doit se munir doutils de dveloppement rapide, on
doit se baser sur du matriel standard, si possible rutilisable.
Une plate-forme PC peut savrer tre une solution intressante
dans la plupart des cas :
matriel standard, peu onreux ;
diversit des interfaces dentres/sorties (cartes dacquisition
PCI, bus RS232, USB, FireWire, CameraLink, solutions de
communication Ethernet, Wi-Fi) ;
solutions de stockage sur disques durs (disques extractibles,
systmes RAID pour les dbits importants).
Bien entendu lutilisation dun PC embarqu pose les problmes
suivants :
encombrement ;
puissance dalimentation ncessaire ;
relativement faible rsistance aux chocs.
________________________________________________________________________________ PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES
On pourra alors de plus en plus sorienter vers des solutions
base de PC portables pour les applications ne ncessitant pas luti-
lisation de capacits de stockage trop importantes, ou encore vers
des plates-formes de type PC-104+, ETX, etc.
Nous dtaillerons dans le paragraphe 3 les possibilits des diff-
rentes solutions matrielles.
2.3.1 Systmes dexploitations
Ct systmes dexploitations, nous avons alors lembarras du
choix : Windows [2], Linux [3] [4], QNX [5], VxWorks... tudions les
avantages et inconvnients de quelques unes de ces solutions.
QNX et VxWorks, pour ne citer queux, sont donc des systmes
dexploitations temps rel dterministes tel que nous lavons vu
dans le paragraphe 2.2 : le programmeur peut affecter aux tches
logicielles de son choix les priorits les plus leves ou les plus fai-
bles, le gestionnaire des tches du systme dexploitation respec-
tera ces choix la lettre.
Le principal inconvnient de ces systmes dexploitations rside
dans le fait quil nexiste que peu de drivers matriels pour ces OS
(Operating System ). Le choix des capteurs et des matriels
utiliser est donc plus limit.
Windows 2000 ou XP, en revanche, nest pas considr
comme tant un systme temps rel dterministe. Il peut nan-
moins tout fait convenir, dans un grand nombre de cas pour le
prototypage rapide dune application : la plupart des capteurs ou
des cartes dacquisitions pour PC sont fournis avec leurs drivers
pour Windows.
Le choix des environnements de dveloppements et des langa-
ges de programmation est large. Le dveloppement dinterfaces
graphiques est relativement simple.
Windows et le temps rel
Pourquoi Windows (dans ses versions NT, 2000 et XP) nest-il
pas considr comme un systme temps rel dterministe ? [2]
Il est possible daffecter diffrentes priorits aux diffrentes tches
dune application sous Windows. Nanmoins, les priorits des
tches logicielles dune application seront toujours infrieures aux
priorits des routines servant les interruptions matrielles.
Cest--dire quune carte dacquisition recevant une donne va
dclencher une interruption matrielle, laquelle va interrompre la
tche courante quelle que soit la priorit de celle-ci pour lancer
lexcution de son ISR (interruption service routine).
De mme, il nest pas possible sous Windows de dfinir un ordre
de priorit parmi les diffrentes interruptions matrielles gres.
Celles-ci sont distribues par le systme dexploitation de faon
arbitraire.
Cependant, la plupart des services associs ces interruptions
matrielles sont extrmement simples et se contentent de prendre
note de la prsence dune donne pour mettre en attente une tche
de traitement de la donne en question avec une priorit inf-
rieure. La tche interrompue initialement peut alors reprendre la
main trs rapidement.
Enfin, il est difficile de savoir exactement sous Windows quelles
sont les applications charges en mmoire, et quelles sont leurs
priorits lexcution. Le planificateur des tches de Windows na
pas non plus un comportement toujours dterministe : il donne
parfois la main des tches (ou threads ) de priorit infrieure qui
nont pas obtenu de temps dexcution depuis un certain temps,
mme sil doit bloquer pour cela dautres tches dont les priorits
sont plus importantes. Le but de ceci est principalement de
conserver une interface graphique ractive. Ce dernier phnomne,
appel Priority Boost , peut dailleurs tre apprciable dans une
phase de prototypage : si un algorithme de lapplication fonction-
nant en priorit leve est trop gourmand et se met consommer
toute la puissance de calcul, il sera possible dans la plupart des cas
sous Windows de terminer lapplication laide de la souris ou du
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
clavier, ce qui ne sera pas forcment le cas sous dautres systmes
dexploitation o linterface graphique se retrouverait entirement
gele.
Au final, lexprience montre nanmoins que, moyennant
quelques rglages du systme, Windows propose des perfor-
mances temps rel tout fait correctes tant que la charge pro-
cesseur nest pas trop leve (< 70 % environ) : les tches dont la
priorit est leve sexcutent alors dans leurs dlais impartis et la
ractivit du systme est bonne (jitters faibles, de lordre de la milli-
seconde). De mme, les performances globales en termes de puis-
sance de calcul sont bonnes : les temps de commutation entre les
tches sont plus rapides que sur beaucoup dautres systmes
dexploitations.
Quid de Linux ? [3]
Il est beaucoup plus difficile de parler de Linux au sujet des per-
formances temps rel car il nexiste pas un seul systme Linux :
chaque distribution est diffrente, le systme dexploitation est trs
modulaire. Le noyau du systme peut lui-mme tre recompil et
modifi volont laide de patchs en tous genres.
Les noyaux 2.4 de Linux ntaient pas temps rel et les appels
systmes ntaient pas rentrants (systmes dit non premptifs ).
Nanmoins, certains patchs justement permettaient de corriger tout
ou partie de ces faiblesses. Les nouvelles versions des noyaux Linux
(v 2.6) intgrent ces amliorations, de mme quun planificateur de
tches plus performant (temps de commutation de tches en O(n))
(voir le site http://www.kernel.org pour de plus amples informa-
tions).
Ainsi Linux, tout comme QNX et VxWorks, restent rservs des
programmeurs avertis, en matire de prototypage, et familiers de
ces systmes dexploitations.
Pour des applications lgres, destines fonctionner sur des
architectures aux performances limites (systmes enfouis, calcula-
teurs ddis), on utilise souvent des systmes dexploitations bass
sur une architecture micronoyau, trs modulaires et adaptables en
fonction des ressources disponibles (Linux [4], QNX, VxWorks sont
souvent utiliss). Il convient de mentionner aussi les solutions
Windows CE .NET et Windows XP Embedded. Windows CE,
contrairement ses grands frres technologie NT (Windows NT,
2000 et XP), est bas sur un noyau temps rel. Il est largement
rpandu sur les PDAs (Personal Digital Assistant ) par exemple et
Microsoft fournit un environnement de dveloppement complet
pour cet OS.
2.3.2 Langages de programmation
Dans le domaine des langages de programmation utiliser, l
aussi, des choix doivent tre faits. Les langages les plus courants
seront C/C++, Java. Dautres langages spcifiques Windows sont
aussi rpandus : C# (prononcer C Sharp ) et Visual Basic.
C/C++ est bien sr le langage le plus courant dans le domaine,
permettant loptimisation et la gestion fine de la mmoire utilise.
Le langage est portable sur un grand nombre de plates-formes
(moyennant recompilation) tant quon nutilise pas de librairies sp-
cifiques (comme par exemple les librairies fournies avec les mat-
riels dacquisition de donnes ou celles permettant de raliser des
interfaces graphiques).
Le C++, orient objet, permet de concevoir des applications
complexes modulaires.
C et C++ sont des langages trs courants dans le domaine
scientifique : de nombreuses librairies sont disponibles dans ce
langage, que ce soit pour le traitement dimages, le traitement du
signal, lacquisition de donnes. La plupart des SDK (Software
Development Kits ) fournis avec les matriels spcifiques (cartes
dacquisition de donnes, capteurs, etc.) sont disponibles en C++.
Java, de son ct, bien que parfaitement portable sur plusieurs
plates-formes, possde des inconvnients dans le domaine du
S 8 192 5
PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES _________________________________________________________________________________
dveloppement temps rel embarqu : une application Java
consomme une quantit de mmoire importante, moins dutiliser
des ditions spcifiques telles que J9 ou J2ME (pour Java 2 Micro
Edition, plus limite en fonctionnalits), et les compilateurs sont
moins performants que ceux utiliss en C ou C++ (les fichiers Java
tant compils en un code intermdiaire, dit byte code , indpen-
dant de la plate-forme sur laquelle on linstalle, et qui sera interprt
par la machine virtuelle du systme en phase dexcution). Enfin, le
systme de libration de la mmoire en Java utilise un ramasse
miettes (Garbage collector ), une tche supplmentaire qui scanne
priodiquement la mmoire alloue pour librer les espaces non
utiliss. La prsence de tches non contrles par le programmeur
peut, dans certains cas, perturber le fonctionnement temps rel
dune application.
Java propose cependant des alternatives permettant le dve-
loppement dapplications temps rel laide de machines virtuelles
spcifiques. Une spcification pour un langage Java temps rel
est dveloppe par le Real-Time Java Expert Group (voir
http://rtsj.dev.java.net).
Visual Basic ou C# enfin, si lon travaille sous Windows, pourront
tre adapts au dveloppement rapide dinterfaces graphiques ou
dapplications simples, mais restent inadapts pour raliser des
applications scientifiques complexes et optimises.
En fonction des besoins en performance de lapplication envi-
sage, on optera pour une solution ou une autre, et il faut gar-
der lesprit que tous ces langages peuvent communiquer
entre eux, soit au sein dune mme application, soit par linter-
mdiaire de librairies partages (.dll ou .so). Nous parlerons
aussi dans le paragraphe 3 de collaborations entre diffrents
logiciels pour raliser une tche complexe.
3. tapes du prototypage
3.1 Spcification, choix
et mise en place du matriel
Une fois les besoins clairement dfinis et le cahier des charges
rdig et accept, on sera capable de spcifier le matriel dont on
va avoir besoin (capteurs, matriel informatique, alimentations,
actionneurs).
On procdera gnralement (et idalement) de lextrieur vers
lintrieur : cest--dire que lon commencera par dterminer les
lments dont on aura besoin pour interagir avec lenvironnement
(capteurs et actionneurs), puis par dfinir les moyens informa-
tiques qui devront tre mis en place pour acqurir et traiter les
donnes des capteurs et/ou gnrer et envoyer les commandes.
Il faudra bien entendu tenir compte dun certain nombre de
contraintes, particulirement importantes dans le cas dapplica-
tions embarques. Parmi les plus courantes, on trouvera celles-ci :
encombrement ;
poids ;
consommation lectrique (fonctionnement sur batteries, ou
au mieux sur alternateur) ;
rsistance aux chocs et vibrations.
Exemples
1. Prenons le cas reprsentatif dune application embarquer dans
une automobile :
le systme informatique associ aux convertisseurs de tension
ventuels, et aux diffrents botiers de conditionnement des donnes
capteurs devra souvent tenir dans le coffre du vhicule ;
on pourra embarquer un poids important, le poids nest pas ici
une contrainte ;
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 6 Techniques de lIngnieur
la puissance lectrique disponible (prleve sur lalternateur) ne
dpassera pas 700 ou 800 W dans la plupart des cas (des batteries
supplmentaires permettant de faire fonctionner le systme moteur
teint sont souvent apprciables, ajoutant ainsi du volume de la mme
faon) ;
dans des cas dutilisations en conditions extrmes (chemins,
conduite sportive, situations durgence), des dispositifs damortis-
sement de chocs devront tre prvus (silent blocks, mousses, rsines
de fixation des cartes lectroniques, connecteurs visss).
Une configuration base sur un PC industriel en rack 4U peut tre
adapte ce type de situation. Un PC de bureau peut mme parfois
faire laffaire. Nous dtaillerons cela par la suite. Cette solution met
disposition de lquipe de projet une importante puissance de calcul,
une bonne modularit (possibilit dajout de capteurs, dvolutions du
PC) pour des cots relativement faibles.
2. En revanche, dans le cas de drones, les contraintes dencombre-
ment et de poids feront choisir des systmes plus compacts, base
par exemple de cartes PC-104, beaucoup plus petites et lgres, rsis-
tant bien aux chocs et aux vibrations. La puissance de calcul et les
interfaces dentres/sorties disponibles seront alors beaucoup plus
limites.
Les capteurs utiliss sont trs divers suivant les applications. La
technologie des capteurs volue extrmement rapidement,
exploitant lvolution des dbits disponibles sur les bus de don-
nes rcents, de mme que laugmentation considrable de la
puissance de calcul des processeurs, des capacits de stockage des
donnes de plus en plus importantes (disques durs SCSI rapides,
systmes RAID, mmoires flash).
Cest grce de tels gains en performance que lon se tourne
rsolument, ces dernires annes, vers des applications de fusion
de donnes, mettant en jeu de multiples capteurs.
De mme, de plus en plus dapplications embarques utilisent
de la dtection par vido, entranant le besoin de grer des dbits
de donnes particulirement importants.
3.2 Capteurs utiliss
Voici quelques exemples de capteurs utiliss en recherche et
dveloppement pour raliser les prototypes des applications de
demain.
Camras vido, analogiques ou numriques (figure 4)
Les camras analogiques sont maintenant souvent dotes de
capteurs CCD et dlivrent un signal analogique qui doit tre chan-
tillonn sur une carte dacquisition spcifique. Certaines cartes
dacquisition sont capables deffectuer une compression en temps
rel sur les images acquises, ce qui permet de diminuer les dbits
lenregistrement par exemple (compressions jpeg, mpeg, en
ondelettes, etc.).
Les camras numriques sont de plus en plus utilises : les bus
de donnes numriques tant de plus en plus performants, on peut
les utiliser pour des acquisitions haute frquence, haute rsolution
par exemple. Leur connexion et dconnexion peuvent souvent
seffectuer chaud , elles peuvent de mme tre pilotes par
logiciel (rglages de formats vido, de frquences dacquisition, de
temps douverture, de gain, douverture, etc.).
Figure 4 Camras (standard analogique et strovision FireWire)
________________________________________________________________________________ PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES

Des camras quipes de capteurs CMOS ont aussi fait leur

apparition rcemment. Si la qualit des images dlivres nest pas
encore tout fait au niveau de leurs surs CCD, elles prsentent
face elles certains avantages dterminants tels que la possibilit
dutiliser un capteur vido rponse logarithmique qui permet
daugmenter la dynamique de limage, rduisant ainsi les effets de
surexposition ou, linverse de sous-exposition.

Radars (figure 5)
Le radars embarqus permettent de dtecter des cibles, souvent
mobiles. Ils fonctionnent par effet Doppler et permettent notam-
ment dapporter des renseignements non seulement sur la dis-
tance des cibles, mais aussi sur leur vitesse relative par rapport au
vhicule prototype et donc sur leur vitesse par rapport au sol.
On distingue plusieurs types de radars, lesquels peuvent savrer
complmentaires au sein dune mme application :
Figure 5 Radar Autocruise les radars long range permettent la dtection de cibles
longue distance (plusieurs dizaines de mtres), mais sont trs
directionnels ;
les radars short range serviront la dtection de cibles
proches, mais sur un champ angulaire beaucoup plus large.

Tlmtres lasers (figure 6)

Les tlmtres laser permettent dvaluer la distance au premier
obstacle dans une direction donne ou de tracer un profil de lenvi-
ronnement dans un plan (on utilise alors des tlmtres
balayage). Certains dentre eux accroissent leurs possibilits en
travaillant sur plusieurs plans parallles, par exemple quatre,
simultanment.

Le GPS (figure 7)
Le GPS (Global Positionning System ) est un capteur maintenant
Figure 6 Tlmtre laser IBEO
trs rpandu. Suivant le type de GPS utilis, la localisation sera
plus ou moins prcise :
GPS standard : 20 m ; la localisation est base sur les seu-
les informations reues par les satellites ;
GPS diffrentiel (DGPS) : 1 m ; la localisation est base sur
les informations reues par les satellites en collaboration avec une
station fixe dont la position est connue de faon exacte, et qui
reoit, elle aussi, les mmes signaux provenant des GPS. Lerreur
estime sur la station fixe est envoye au rcepteur GPS mobile
par radio pour soustraction ;
GPS RTK (Real Time Kinematic ) : 1 cm ; le GPS RTK est lui
aussi un GPS diffrentiel. Il est conu pour tirer parti dun second
type de signal mis par les satellites metteurs GPS : appel
carrier phase (par opposition au code phase des GPS clas-
siques). Les rcepteurs GPS RTK sont beaucoup plus onreux que
les GPS classiques.
Figure 7 Satellites GPS
Linfrastructure ne permettant pas toujours davoir recours aux
GPS diffrentiels ou RTK, il est possible de complter le systme de
localisation laide, notamment, de centrales inertielles (gyrosco-
pes, acclromtres) ou dodomtres.

Les centrales inertielles (figure 8)

Constitues dacclromtres et de gyroscopes, les centrales
inertielles permettent de mesurer les dplacements du systme
auquel elles sont fixes. Lintgration de leurs mesures permet de
reconstituer une trajectoire. Nanmoins, limperfection de ces
mesures laisse forcment apparatre une drive au cours du temps.
Elles viennent alors par exemple en complment dune applica-
tion de localisation dote dun GPS de manire permettre des
mesures de trajectoire intermdiaires entre deux top GPS ou sur
les sections doccultation du signal GPS (tunnels, etc.).
La fusion des deux mesures GPS + centrale inertielle permet
Figure 8 Centrale inertielle Crossbow aussi dobtenir des trajectoires plus prcises.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur S 8 192 7
PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES _________________________________________________________________________________

3.3 Acquisition et enregistrement temps ) de faon conserver les informations de synchronisation

des donnes
Pour permettre un prototypage rapide des algorithmes implan-
ter sur le systme, il est capital dtre capable denregistrer les
donnes issues des diffrents capteurs utiliss, de manire
constituer des jeux de scnarios, puis de pouvoir les rejouer
volont, cest--dire les rinjecter dans lapplication de traitement
telles quelles ont t enregistres.
Pour cela, il est ncessaire de dater les donnes de chaque cap-
teur par rapport une seule et mme horloge (ou base de
de ces donnes.
De cette faon, il nest plus ncessaire dembarquer chaque
fois les algorithmes tester dans le vhicule prototype : il est pos-
sible de rutiliser volont ces bases de donnes.
Sur PC, lacquisition peut se faire laide de diffrents bus et de
cartes dacquisition spcifiques. Le tableau 1 rcapitule, par exem-
ple, les bus numriques disponibles les plus standards.
Une fois une donne acquise et date, il faut pouvoir lenregis-
trer sur un priphrique de stockage (en gnral un ou plusieurs
disques durs). (0)

Tableau 1 Les bus de donnes

Bus Dbits Capteurs Commentaires
RS232 115 kbits/s (bauds) GPS, centrales de navigation, tlmtres, Bus standard sur les PC de bureau (1 ou 2 pr-
radars... sents).
Possibilit den ajouter laide de cartes PCI
ddies.
Dbits faibles, bus ancien mais protocole simple :
lectronique simple.
RS422 10 Mbits/s Tlmtres, radars... Similaire au bus RS232 mais les dbits accessibles
sont plus levs.
USB 12 Mbits/s Webcams, priphriques grand public Bus trs rpandu.
divers Utilisation aise (hot plug, dtection automatique
des drivers ).
Les capteurs sont plus compliqus dvelopper ;
lectronique plus complexe que pour le RS232 ou
RS422.
USB 2 480 Mbits/s Camras vido numriques, priphriques Bus rcent.
de stockage Combine des avantages de lUSB avec un dbit
plus important.
FireWire (IEEE1394) 400 Mbits/s Camras vido numriques, priphriques Bus similaire lUSB 2. Plus ancien, moins
de stockage rpandu.
Plutt rserv une utilisation professionnelle.
Na pas perc sur le march grand public.
FireWire b 800 Mbits/s Camras vido numriques haute rsolu- Bus rcent.
(IEEE1394b) 1,6 Gbits/s tion ou haute frquence, priphriques de Similaire au bus FireWire avec dbit plus
stockage important.
CameraLink 1,5 5,44 Gbits/s Camras vido haute rsolution ou haute Bus numrique ddi aux bandes passantes
frquence. leves.
Utilisation professionnelle uniquement.
Ncessite une carte dacquisition spcifique
sur PCI ou PCI-X.
Ethernet 100Base-T 100 Mbits/s Rseaux locaux classiques
Ethernet 1000Base-T 1 Gbits/s Rseaux locaux haut dbit : serveurs
de donnes, streaming vido
FibreChannel 800 Mbits/s
CAN 1 Mbits/s Capteurs automobiles Bus installs dans les automobiles rcentes.
Connexion de tous les capteurs sur une seule
nappe (vitesse, angle volant, jauges, actions
conducteur, etc.).
PCI 130 180 Mo/s Diverses cartes dentres sorties (vido Bus interne au PC.
(33 MHz ou 66 MHz) analogique, cartes dE/S analogiques, Bus standard.
cartes sons, cartes FireWire, extensions Interface un grand nombre de cartes dE/S
diverses...) spcifiques.
PCI 64 bits 500 1 600 Mo/s Acquisition vido, stockage SCSI, transfert
de donnes
PCI-X 1 4 Go/s Acquisition vido, stockage SCSI, transfert Bus rcent.
de donnes Pour applications haut dbit de donnes
(multivido, vido haute rsolution, vido hautes
frquences).
PCI Express 250 Mo/s 8 Go/s Tout type dacquisition trs haut dbit, affi- Bus rcent, destin remplacer les bus PCI
chage, stockage... et AGP.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 8 Techniques de lIngnieur
________________________________________________________________________________ PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES
PARAMTRES
E S
N O
T R
R T
I embarque. Les disques durs sont en effet des priphriques
E E
S S
Figure 9 Schma dune brique fonctionnelle
Suivant les dbits enregistrer, on optera pour des solutions plus
ou moins onreuses, et plus ou moins performantes.
Au niveau des disques
Les performances des disques actuels varient beaucoup dune
technologie une autre :
capacit : la capacit dun disque IDE ou Serial ATA peut
atteindre 400 Go lheure o ce texte est crit. Les disques SCSI,
eux, ont une capacit gnralement plus faible (73 ou 146 Go, bien
que certains atteignent 300 Go) ;
dbit : les dbits en lecture/criture : les disques IDE et Serial
ATA sont capables, pour les meilleurs dentre eux, denregistrer ou
de relire des donnes la vitesse soutenue de 30 60 Mo/s envi-
ron (suivant lavancement de la tte de lecture/criture sur le dis-
que). Les disques SCSI bnficient dune vitesse de rotation
maximale des plateaux plus leve (10 000 ou 15 000 tr/min contre
7 200 tr/min pour les disques IDE), ce qui permet daugmenter
leurs dbits en lecture et criture jusquaux environs de 60 Mo/s de
faon soutenue ;
prix : lavantage va ici aux disques IDE et Serial ATA, les dis-
ques SCSI tant rservs aux applications trs exigeantes.
Au niveau de linterface entre la carte mre et le ou les
disques
linterface IDE peut accepter deux priphriques (disques
durs, lecteurs et graveurs de CD et DVD) dont un matre et un
esclave. Dbit maximal de linterface (Ultra ATA 133) : 133 Mo/s ;
linterface SCSI accepte un grand nombre de priphriques.
Dbit maximal de linterface (SCSI Ultra 320) : 320 Mo/s ;
linterface Serial ATA : il sagit dune interface rcente, mais
destine se dmocratiser. Dbit maximal actuel (SATA 150) :
150 Mo/s.
Les systmes RAID (Redundant Arrays of Inexpensive Disks )
Les systmes RAID sont des systmes de stockage permettant la
collaboration de plusieurs disques durs pour augmenter la bande
passante disponible ainsi que la scurit des donnes en cas de
panne dun disque. Il existe plusieurs types de systmes RAID, per-
mettant soit laugmentation pure des dbits disponibles, soit la
redondance des informations (et ainsi la tolrance face aux pan-
nes). Des compromis entre ces deux solutions existent aussi.
Citons par exemple :
le RAID 0 (Stripping) : le flux est rparti sur les disques for-
mant le systme RAID. Excellente performance en termes de dbit
de donnes, pas de robustesse face aux pannes (si un disque
tombe en panne, les donnes sont perdues) ;
le RAID 1 (Shadowing) : permet de dupliquer intgralement
les donnes. Si le systme possde deux disques, les donnes sur
chacun des deux seront identiques. Bonne robustesse face aux
pannes, performances en lecture lgrement amliores, perfor-
mances en criture identiques un systme comprenant deux fois
moins de disques ;
le RAID 5 (Stripping + parit) : sur X disques, un disque est
rserv la parit, ce qui permet de faire face une panne dun
des disques. Taux de transfert moyens ;
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur
le RAID 6 (Stripping + 2 disques de parit) : ce systme
rserve deux disques au stockage de la parit. Le systme fonc-
tionne aprs la perte de deux disques. Taux de transfert en criture
mdiocre, taux de transfert en lecture et taux de requtes excel-
lents.
Bien sr, il faudra toujours rester vigilant en ce qui concerne
lencombrement et la consommation lectrique ncessaire au
fonctionnement de ces systmes de stockages sur une machine
consommateurs en nergie, et particulirement au dmarrage du
PC (mise en rotation des plateaux).
3.4 Dveloppement des algorithmes
Diffrents algorithmes sont souvent mis en jeu pour obtenir le
rsultat dsir. Ils se prsentent alors sous la forme dune chane
de traitement : dcodage des donnes, filtrage, traitements dima-
ges, fusion de donnes, affichage, commande, etc.
Il est alors apprciable de pouvoir dvelopper ou rutiliser des
briques fonctionnelles, que lon pourra agencer et paramtrer de
faon modulaire. Chaque brique sera dote dun certain nombre
dentres, dun certain nombre de sorties, et sera paramtrable
laide dun certain nombre de proprits (figure 9).
La programmation de chaque brique est alors souvent rserve
des dveloppeurs informatiques : il est toujours ncessaire de
bien matriser le langage de programmation, quel quil soit, pour
dvelopper des fonctionnalits complexes et optimises.
Mais une fois au point, cette brique peut tre utilise par dautres
personnes, y compris non programmeurs, moyennant la lecture de
la documentation associe, des exemples dutilisation et des notes
dapplication.
Il peut alors devenir ncessaire davoir recours des bases de
donnes pour centraliser les briques disponibles et leur documen-
tation... On entre l dans le domaine du knowledge management.
De faon avoir accs un maximum de fonctionnalits et de
bibliothques, il sera important de faire collaborer les logiciels entre
eux. Il est illusoire de penser quun seul logiciel pourra permettre
de raliser simplement toutes les tapes dune chane complexe :
un logiciel sera spcialis dans lacquisition de donnes, un autre
dans le calcul temps rel, un troisime dans le calcul de statistiques
partir de bases de donnes, etc. Il est donc ncessaire de se baser
sur des formats de donnes standards, exploitables par la plupart
des logiciels, lesquels peuvent dailleurs cooprer directement et
dialoguer (par interfaces COM/DCOM sous Windows, par CORBA ou
pipes sous Linux).
Le dveloppement dun procd de traitement des donnes
demande souvent de multiples essais rptitifs. Il faut donc se
doter doutils permettant de rpter un scnario de faon simple et
rapide.
Les scnarios utiliss peuvent provenir de diffrentes sources :
soit de donnes enregistres en campagne sur le terrain,
lesquelles sont ensuite rinjectes dans la chane de traitement ;
soit dune simulation, cest--dire de la reconstitution totale-
ment virtuelle, dune scne ou dun environnement.
Durant la phase de dveloppement ou de choix des algorithmes,
on ne se soucie que relativement peu de loptimisation : une
premire phase consiste trouver une chane de traitement qui
fonctionne, qui calcule les rsultats que lon attend delle. Ensuite
viendra la phase o lon devra faire fonctionner le tout en temps
rel.
Il est donc apprciable dans cette premire phase de pouvoir
injecter au ralenti les donnes (soit par rejeu, soit par simulation)
dans le systme en dveloppement. Cela laissera le temps aux dif-
frents traitements dexcuter leurs calculs sans avoir liminer de
donnes par manque de temps.
S 8 192 9
PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES _________________________________________________________________________________

Dans une seconde phase, on essaiera, partir dune chane de

traitement qui fonctionne, de trouver quels sont les calculs qui ne
Affichage sont pas indispensables, quels sont ceux qui peuvent tre-
optimiss. Le gain en performance que lon peut obtenir est
Bases de souvent consquent.
donnes Enregistrement
synchronises
En ce qui concerne le prototypage dune loi de commande
(figures 10, 11, 12), un simple rejeu de donnes enregistres ne
Algorithmes Contrle d'un suffira pas. On aura en effet besoin de travailler en boucle ferme,
Simulateur systme cest--dire que les rsultats de lalgorithme de commande doivent
prototyper sur
plate-forme logicielle indpendant pouvoir tre envoys au systme, lequel ragira en fonction. On
devra alors soit faire les tests en environnement rel, soit avoir
Pas de contrle-commande (boucle ouverte) : recours la simulation. Le dveloppement dun simulateur peut
- rejeu partir de donnes enregistres - OK ;
savrer trs complexe et onreux suivant le systme simuler, le
- simulation - OK ;
degr de ralisme atteindre. Dun autre ct, la ncessit de faire
- temps virtuel possible - OK.
les tests des algorithmes de commande en conditions relles
prsente aussi des inconvnients :
Figure 10 Prototypage dun systme sans contrle-commande le prototype nest pas toujours en tat de fonctionner ;
et sans avoir recours au matriel spcifique il ne peut tre utilis que par une personne la fois ce qui
limite le travail collaboratif ;
et enfin, un algorithme de contrle-commande dfectueux
peut endommager le systme si toutes les prcautions de scurit
nont pas t prises.
Algorithmes
prototyper sur
De plus, si les performances de calcul logiciel ne sont pas suffi-
plate-forme logicielle Affichage samment bonnes pour faire fonctionner le systme en temps rel,
il est alors impossible de ralentir le temps comme cest le cas
en rejeu de donnes ou en simulation. Il faudra alors passer des
Simulateur Enregistrement solutions plus complexes par utilisation de circuits intgrs spci-
fiques [microcontrleurs, FPGA, DSP (Digital Signal Processor ),
Contrle d'un etc.].
systme Lintrt de se servir doutils de dveloppements briques fonc-
Commandes indpendant tionnelles est alors de permettre la ralisation de deux couches :
une couche haut niveau logicielle qui ralisera le maxi-
Contrle-commande du systme (boucle ferme) :
- rejeu partir de donnes enregistres - NON ;
mum de tches dans la limite de ses capacits de calcul ;
- simulation - OK ; une couche bas niveau , sur circuits intgrs spcifiques
- temps virtuel possible - OK. pour les calculs complexes.

Figure 11 Prototypage dun systme avec contrle-commande 3.5 Utilisation de circuits intgrs
et sans avoir recours au matriel spcifique
spcifiques
Les ASICs (Application Specific Integrated Circuits ) sont des
circuits intgrs dvelopps pour raliser une tche particulire.
Le cot et le temps de dveloppement de tels systmes peuvent
varier normment suivant lapplication que lon souhaite raliser.
ventuels algorithmes Lutilisation de FPGAs (Field Programmable Gate Arrays ) permet
prototyper sur circuits
intgrs
de conserver la possibilit de reprogrammer lapplication sans
changer de circuit intgr.
Un FPGA est constitu de nombreuses cellules logiques iden-
tiques (parfois plusieurs milliers) qui peuvent tre considres
comme autant de composants standards capables de raliser des
oprations simples. Ces cellules sont cbles entre elles par une
Systme Algorithmes matrice de fils et dinterrupteurs. La programmation de lappli-
et capteurs prototyper sur cation consiste assigner, chaque cellule, une tche parmi celles
rels plate-forme logicielle Affichage
disponibles puis fermer intelligemment les interrupteurs de faon
obtenir les fonctions de traitement dsires.
Enregistrement La programmation de telles puces se fait laide de langages
particuliers : les HDL (Hardware Description Languages ) dont le
Contrle d'un plus connu est le VHDL (Very high speed integrated circuit Hard-
systme ware Description Language ). Les performances de lapplication
Commandes indpendant finale dpendront de la qualit de conception du code HDL.
Il faudra aussi concevoir la carte lectronique qui accueillera le
Contrle-commande sans simulateur (boucle ferme) : circuit intgr.
- rejeu partir de donnes enregistres - NON ;
- simulation - NON ; Dans le cas o lon prototype effectivement un systme sur deux
- temps virtuel possible - NON. couches (une couche haut niveau et une couche bas niveau), cette
carte peut tout fait prendre la forme dune carte PCI par exemple.
Les changes de donnes entre les deux couches se feront par
Figure 12 Prototypage dun systme avec contrle-commande, lintermdiaire de ce bus, interne au PC. Dautres modes de
sur matriel embarqu communication sont aussi envisageables : RS232, bus CAN...

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 10 Techniques de lIngnieur
________________________________________________________________________________ PROTOTYPAGE DES APPLICATIONS TEMPS REL EMBARQUES

3.6 Du prototype lindustrialisation 4. Conclusion et perspectives

Une fois le choix des capteurs valids, les algorithmes dve-
lopps et la chane de traitement mise en place et finalise, il sagit
de raliser un calculateur qui sera capable de raliser lacquisition,
les traitements et deffectuer les actions qui en rsultent.
Leffort portera alors principalement sur loptimisation du sys-
tme et des algorithmes, ainsi que sur la fiabilit du portage de
ceux-ci.
Suivant les besoins en capacit de calcul de lapplication
raliser, ce calculateur pourra tre ralis base dun processeur
dot dun OS temps rel lger, ou bien, pour des applications plus
gourmandes, bases de puces spcifiques de mme type que dcri-
tes au paragraphe 3.5.
Du fait du cot de dveloppement et du temps de portage vers
de tels systmes, il est ncessaire de pousser au maximum la
validation des algorithmes sur plate-forme logicielle.
Pour faciliter ensuite le portage vers un calculateur embarqu,
des projets de standardisation des interfaces ont vu le jour
(exemple : OSEK/VDX http://www.osek-vdx.org).
Des projets de recherche portent sur la conversion de code (C et
C++ vers des langages de plus bas niveau tels que VHDL).
La phase de ralisation du calculateur sera encore suivie de son
intgration matrielle sur le systme final, de tests en robustesse,
de phases de calibration, puis de fabrication en grande srie.
Le prototypage dun systme embarqu temps rel est donc un
projet impliquant autant le matriel que le logiciel. Les perfor-
mances galopantes des PC standards poussent au dveloppement
de systmes de plus en plus complexes, de plus en plus
intelligents , mettant en jeu de hauts dbits de donnes
provenant de sources diverses. On se tourne de plus en plus vers
des applications de fusion de donnes.
Face cela, des outils logiciels de plus en plus performants,
ddis au prototypage rapide sont dvelopps, chacun dot de ses
avantages et de ses inconvnients.
Il est vident quun seul logiciel ne peut pas rpondre toutes
les attentes des ingnieurs dveloppement. Il est donc important
de se tourner vers des logiciels spcialiss cooprant , capables
de schanger des donnes et des commandes.
La tendance est donc lintgration logicielle de bout en bout,
en tirant ventuellement parti de la simulation. Cela permet de se
dgager au maximum des contraintes matrielles dun prototype
(disponibilit, cot), et de favoriser le tout logiciel, plus modulaire,
permettant le travail collaboratif et la capitalisation des travaux
effectus.
Pour des informations complmentaires le lecteur pourra se
reporter aux rfrences [1] [10].

Rfrences bibliographiques
[1] STEUX (B.). RTMaps, un environnement [4] YAGHMOUR (K.). Building Embedded Linux [8] National Instruments/Solutions pour le test et
logiciel ddi la conception dapplications Systems. OReilly & Associates. la mesure (www.ni.com)
temps rel. Thse de lcole des Mines de [9] dSpace/Solutions for Control
[5] QNX Realtime Operating System. QNX
Paris soutenue le 20 dcembre 2001. (www.dspace.de)
Software Systems Ltd.
[2] SALOMON (D.A) et RUSSINOVICH (M.E.). [10] Mathworks/diteur des logiciels Matlab et
Inside Microsoft Windows 2000 Third Edi- [6] BARR (M.). Programming Embedded Sys-
Simulink pour le calcul scientifique et la simu-
tion. Microsoft Press. tems in C and C++. OReilly & Associates.
lation (www.mathworks.com)
[3] CESATI (M.) et BOVET (D.P.). Understanding [7] Intempora SA/diteur du logiciel RTMaps pour
the Linux kernel Second Edition. OReilly & le prototypage dapplications multi-capteurs
Associates. et la fusion de donnes (www.intempora.com)

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur S 8 192 11