Vous êtes sur la page 1sur 11

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


Le second point que doivent respecter ces outils concerne le On se pose souvent la question des performances dites temps
besoin de fiabilit et de reproductibilit. En effet pour effectuer des rel de solutions logicielles. On entend ainsi souvent dire
tests sur un systme embarqu, pour mettre au point son param- Windows nest pas un systme dexploitation temps rel. Telle
trage, lutilisateur a besoin dune reproductibilit sans faille des application devra tourner sur QNX ou VxWorks. . Or, il existe bien
conditions dexprimentation, en admettant que les mmes causes des applications sous Windows permettant de faire du traitement
produisent les mmes effets. Lenvironnement mis en place pour de donnes en temps rel. Le terme adapt serait alors plutt
tester la raction dun systme avec un jeu de paramtres doit la vole ou bien en temps continu . Nous dfinirons plus pr-
pouvoir tre reconstitu lidentique pour tre en mesure de tester cisment les notions de temps rel dans le paragraphe 2. Nan-
le mme systme rgl diffremment. moins, notons quil est souvent beaucoup plus ais de prototyper
un systme embarqu sur un systme dexploitation grand public
Une premire tape consistera par exemple en la dfinition de tel que Windows, dot de bonnes performances globales qui
scnarios (dits scnarios thoriques) sur lesquels le systme sera suffiront, dans de nombreux cas, assurer des temps de rponse
cens fonctionner correctement. Ces scnarios dfiniront la plupart adquats (de lordre de la milliseconde, ou de quelques milli-
des conditions relles dans lesquelles on aura prvu de faire voluer secondes), et qui offrent des solutions logicielles de prototypage
le systme (figure 2). plus compltes, des environnements de dveloppements efficaces,
Exemple : dans le domaine automobile, on dfinira les conditions et un choix de drivers ou pilotes matriels plus larges que sur les
climatiques dune exprience, les types de capteurs ou dactionneurs systmes dexploitation spcialiss dans le temps rel.
mis en uvre, le type de vhicule mis en jeu... Enfin, on soriente aussi de plus en plus vers des solutions tout
logiciel , o lon trouve en amont, non pas des donnes relles,
Une fois les scnarios dfinis, il faudra les mettre en uvre. mais provenant de bases de donnes ou bien gnres par simu-
Sil nest pas ais de pouvoir reconstituer de faon rptable des lateur. Cest depuis longtemps le cas dans le domaine de laronau-
conditions dexprimentation donne, il faut pouvoir enregistrer tique, et la simulation prend une part de plus en plus importante
tous les paramtres dentre du systme pour pouvoir les lui dans le secteur automobile par exemple. Lintrt de la simulation
rinjecter volont durant la phase de dveloppement et de mise en amont est de pouvoir construire un systme dterministe, ractif
au point. Dans le cas o lon prototype un systme mettant en jeu et paramtrable. On peut laide dun simulateur gnrer toutes
une boucle de contrle-commande, il faudra avoir recours la simu- sortes de situations et constituer ainsi des scnarios types dans
lation. lesquels le systme dvelopp sera susceptible dvoluer.

1.4 Matriel
2. Notions de temps
De manire tre la fois modulaire, souple et reproductible, un
environnement de prototypage doit tre constitu, autant que
et de temps rel
possible, de matriels standards. Les cots de conception et/ou de
dveloppement dun matriel spcifique sont incomparables avec 2.1 Notion de temps rel mou
ceux dun matriel standard produit en srie et cest sans parler des
dlais de mise en uvre... Dans le cas o aucun matriel standard ou traitement la vole
ne pourrait rpondre au besoin, il sera parfois beaucoup plus avan-
tageux davoir recours la simulation logicielle. On entend souvent quune application ralise une tche donne
en temps rel . Cela signifie souvent que lapplication est suffi-
Enfin, comme nous lavons dit, les structures de recherche et samment performante pour traiter la vole et sans perte dinfor-
dveloppement souhaitent bnficier de toutes les synergies mation toutes les donnes provenant dun ou plusieurs capteurs,
possibles. Elles visent changer non seulement des rsultats, sans atteindre la capacit maximale de calcul quelle a sa dispo-
mais aussi des donnes, des connaissances, des scnarios de sition. Ainsi, toutes les donnes en entre sont prises en compte par
tests, etc. Chaque brique utilise dans la chane de prototypage lacquisition et participent la tche ralise. Dans la plupart des
doit donc, idalement, pouvoir tre stocke, exporte et partage cas, les donnes sont traites suffisamment rapidement pour
entre diffrents centres de dveloppement. 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
Base de scnarios ( partir dune carte Tuner/TV) avec compression logicielle (plus ou
thoriques moins performante selon la puissance du PC...).
Nanmoins, le terme temps rel au sens propre a une autre
Mise en uvre Modlisation
signification. Ainsi, les puristes soutiendront que Windows nest
Base de scnarios rels
pas un systme dexploitation temps rel . Pourtant, il est bel et
Base de scnarios bien possible de visionner un dvd sous Windows...
partir de donnes relles en
simuls
temps rel ou enrigistres

2.2 Notion de temps rel dur


Dveloppements,
ou temps rel dterministe
tests et mise au point
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
Figure 2 Scnarios thoriques, rels et simuls excute dans le pire des cas en une dure connue et borne.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur 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 Fin du traitement
une qualifie de critique , cest--dire dont la boucle de Envoi d'une Envoi d'une T4 reprend et/ou
traitement doit se drouler imprativement dans un intervalle de commande : commande : succde T3
T1 interrompt T4 T1 interrompt T2
temps donn sous peine de dfaillance du systme complet, il Envoi d'une
faudra alors sassurer que les autres tches nauront pas la possi- Arrive d'une image Fin de l'acquisition commande :
bilit de venir perturber la tche critique au point de lempcher de T2 interrompt T4 T3 succde T2 T1 interrompt T4
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 T1 T4 T2 T1 T3 T1 T4
critiques.
t t + 10ms t + 20ms
Exemples
(1) T1 : tche de commande. Priorit 4 (plus haute priorit)
1. Une illustration classique est celle dun contribuable devant payer (2) T2 : tche d'acquisition des images. Priorit 3
ses impts avant le 15 septembre de lanne en cours. Cette situation (3) T3 : tche de traitement des images. Priorit 2
peut tre considre comme un systme temps rel dur : si ledit (4) T4 : tche d'affichage. Priorit 1 (plus faible priorit)
contribuable dpasse cette date, le fonctionnement du systme
devient anormal. Figure 3 Ordonnancement des tches sur un microprocesseur
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 nombre de tches beaucoup plus important (tches systmes
traitement dimages et, en fonction des rsultats, commande la daccs aux fichiers, de gestion de la mmoire, de gestion des
colonne de direction du vhicule. Les commandes doivent tre entres utilisateurs clavier et souris, autres applications, etc.). On
envoyes priode prcise aux actionneurs de la colonne de direction comprend que la conception dune application comprenant plu-
(disons une commande toutes les 10 ms). Sachant que le processeur sieurs capteurs, parfois asynchrones, doit tre trs rigoureuse car
ne peut excuter quune tche la fois, il faut que la tche du calcula- elle est complexe. Seules quelques tches pourront tre conues
teur qui se charge de ces envois de commandes soit prioritaire par pour tre excutes de faon dterministe.
rapport toutes les autres (y compris par rapport la tche dacquisi-
tion des donnes, la tche de traitement des images, la tche daffi- De mme, il faudra aussi concevoir des architectures matrielles
chage des images sur un cran ventuel, etc.). De mme, les tches respectant ces contraintes de temps rel dterministe. Cest parti-
dacquisition dimages et de traitement seront prioritaires par rapport culirement le cas en ce qui concerne les bus de donnes sur les-
la tche daffichage sur cran (cette dernire ntant pas critique dans quels sont connects plusieurs capteurs. Cest le cas du bus CAN
ce contexte). par exemple, o chaque capteur connect au bus se voit affecter un
identifiant, lequel lui dfinit une priorit. Si deux capteurs ou plus
Ainsi, au moment o la tche de commande doit prendre la main,
tentent dmettre une donne sur le bus, seul le capteur dot de
elle est capable dinterrompre et de mettre en attente la tche cou-
lidentifiant de priorit la plus haute pourra mettre sa donne. Les
rante pendant le laps de temps quil lui faut pour envoyer sa
autres capteurs se mettront alors momentanment en attente
commande (disons 0,5 ms), puis rend la main la tche quelle a inter-
jusqu libration du bus, avant de tenter nouveau lmission.
rompu.

Lexcution des tches peut tre schmatise par le diagramme


de la figure 3. 2.3 Architectures logicielles
La tche T1, trs courte, est donc excute toutes les 10 ms en pour le prototypage
interrompant la tche courante, quelle quelle soit (T4 en loccur-
rence), laquelle est elle-mme interrompue par T2 lors de larrive Est-il cependant toujours ncessaire de raliser des systmes
dune image. T2 est suivie par T3 (traitement de limage), puis T4 temps rel dterministes pour le prototypage dapplications embar-
peut reprendre. Le systme est dterministe dans le sens o on est ques ?
sr que la commande est envoye toutes les 10 ms, et o la chane Il faut garder lesprit que, en matire de prototypage, le but est
critique Acquisition Traitement Commande a le temps de de dvelopper le plus rapidement possible un systme qui fonc-
sexcuter (la camra vido peut ici tre considre comme un tionne. On essaie de dmontrer la faisabilit dun systme, et non
capteur synchrone, dlivrant une donne toutes les 40 ms). La de concevoir ds le dbut le systme tel quil sera industrialis.
tche, non critique, daffichage des images utilisera tout ou partie
Le prototypage sert dterminer quels seront les algorithmes
de la puissance de calcul restante sur le processeur.
utiliss dans le systme final et quelles seront les performances
Au niveau des dures dexcution de chaque tche : obtenues, quel cot, laide de quel matriel.
T1 sexcute toujours en 0,5 ms (D1) ; Pour cela, on doit se munir doutils de dveloppement rapide, on
T2 sexcute au mieux en 6 ms (D2) et au pire en 6,5 ms doit se baser sur du matriel standard, si possible rutilisable.
(D2 + D1) ;
Une plate-forme PC peut savrer tre une solution intressante
T3 sexcute au mieux en 6 ms (D3) et au pire en 12,5 ms
dans la plupart des cas :
(D3 + D2 + D1). Nanmoins, dans ce cas, on peut considrer quelle
sexcute squentiellement aprs la tche T2, donc quelle ne peut matriel standard, peu onreux ;
tre interrompue par T2 elle-mme. Ce qui donne une dure dex- diversit des interfaces dentres/sorties (cartes dacquisition
cution maximale de 6,5 ms (D3 + D1) ; PCI, bus RS232, USB, FireWire, CameraLink, solutions de
T4, qui sexcuterait mettons en 30 ms si elle ntait pas communication Ethernet, Wi-Fi) ;
interrompue, utilise donc le reste de la puissance de calcul du pro- solutions de stockage sur disques durs (disques extractibles,
cesseur. Elle na pas le temps de sexcuter entirement chaque systmes RAID pour les dbits importants).
arrive dimage, ce qui fait que certaines images ne seront pas Bien entendu lutilisation dun PC embarqu pose les problmes
affiches. Nanmoins, cela ne nuit pas au fonctionnement du suivants :
systme. encombrement ;
Le cas prsent ici est simple car il ne prsente que quatre tches. puissance dalimentation ncessaire ;
Il est vident quun systme dexploitation complet doit grer un relativement faible rsistance aux chocs.

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

On pourra alors de plus en plus sorienter vers des solutions clavier, ce qui ne sera pas forcment le cas sous dautres systmes
base de PC portables pour les applications ne ncessitant pas luti- dexploitation o linterface graphique se retrouverait entirement
lisation de capacits de stockage trop importantes, ou encore vers gele.
des plates-formes de type PC-104+, ETX, etc. Au final, lexprience montre nanmoins que, moyennant
Nous dtaillerons dans le paragraphe 3 les possibilits des diff- quelques rglages du systme, Windows propose des perfor-
rentes solutions matrielles. 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
2.3.1 Systmes dexploitations ractivit du systme est bonne (jitters faibles, de lordre de la milli-
seconde). De mme, les performances globales en termes de puis-
Ct systmes dexploitations, nous avons alors lembarras du
sance de calcul sont bonnes : les temps de commutation entre les
choix : Windows [2], Linux [3] [4], QNX [5], VxWorks... tudions les
tches sont plus rapides que sur beaucoup dautres systmes
avantages et inconvnients de quelques unes de ces solutions.
dexploitations.
QNX et VxWorks, pour ne citer queux, sont donc des systmes
dexploitations temps rel dterministes tel que nous lavons vu Quid de Linux ? [3]
dans le paragraphe 2.2 : le programmeur peut affecter aux tches Il est beaucoup plus difficile de parler de Linux au sujet des per-
logicielles de son choix les priorits les plus leves ou les plus fai- formances temps rel car il nexiste pas un seul systme Linux :
bles, le gestionnaire des tches du systme dexploitation respec- chaque distribution est diffrente, le systme dexploitation est trs
tera ces choix la lettre. modulaire. Le noyau du systme peut lui-mme tre recompil et
Le principal inconvnient de ces systmes dexploitations rside modifi volont laide de patchs en tous genres.
dans le fait quil nexiste que peu de drivers matriels pour ces OS Les noyaux 2.4 de Linux ntaient pas temps rel et les appels
(Operating System ). Le choix des capteurs et des matriels systmes ntaient pas rentrants (systmes dit non premptifs ).
utiliser est donc plus limit. Nanmoins, certains patchs justement permettaient de corriger tout
ou partie de ces faiblesses. Les nouvelles versions des noyaux Linux
Windows 2000 ou XP, en revanche, nest pas considr (v 2.6) intgrent ces amliorations, de mme quun planificateur de
comme tant un systme temps rel dterministe. Il peut nan- tches plus performant (temps de commutation de tches en O(n))
moins tout fait convenir, dans un grand nombre de cas pour le (voir le site http://www.kernel.org pour de plus amples informa-
prototypage rapide dune application : la plupart des capteurs ou tions).
des cartes dacquisitions pour PC sont fournis avec leurs drivers
pour Windows. Ainsi Linux, tout comme QNX et VxWorks, restent rservs des
programmeurs avertis, en matire de prototypage, et familiers de
Le choix des environnements de dveloppements et des langa- ces systmes dexploitations.
ges de programmation est large. Le dveloppement dinterfaces
graphiques est relativement simple. Pour des applications lgres, destines fonctionner sur des
Windows et le temps rel architectures aux performances limites (systmes enfouis, calcula-
teurs ddis), on utilise souvent des systmes dexploitations bass
Pourquoi Windows (dans ses versions NT, 2000 et XP) nest-il
sur une architecture micronoyau, trs modulaires et adaptables en
pas considr comme un systme temps rel dterministe ? [2]
fonction des ressources disponibles (Linux [4], QNX, VxWorks sont
Il est possible daffecter diffrentes priorits aux diffrentes tches souvent utiliss). Il convient de mentionner aussi les solutions
dune application sous Windows. Nanmoins, les priorits des Windows CE .NET et Windows XP Embedded. Windows CE,
tches logicielles dune application seront toujours infrieures aux contrairement ses grands frres technologie NT (Windows NT,
priorits des routines servant les interruptions matrielles. 2000 et XP), est bas sur un noyau temps rel. Il est largement
Cest--dire quune carte dacquisition recevant une donne va rpandu sur les PDAs (Personal Digital Assistant ) par exemple et
dclencher une interruption matrielle, laquelle va interrompre la Microsoft fournit un environnement de dveloppement complet
tche courante quelle que soit la priorit de celle-ci pour lancer pour cet OS.
lexcution de son ISR (interruption service routine).
De mme, il nest pas possible sous Windows de dfinir un ordre 2.3.2 Langages de programmation
de priorit parmi les diffrentes interruptions matrielles gres.
Celles-ci sont distribues par le systme dexploitation de faon Dans le domaine des langages de programmation utiliser, l
arbitraire. aussi, des choix doivent tre faits. Les langages les plus courants
seront C/C++, Java. Dautres langages spcifiques Windows sont
Cependant, la plupart des services associs ces interruptions aussi rpandus : C# (prononcer C Sharp ) et Visual Basic.
matrielles sont extrmement simples et se contentent de prendre
note de la prsence dune donne pour mettre en attente une tche C/C++ est bien sr le langage le plus courant dans le domaine,
de traitement de la donne en question avec une priorit inf- permettant loptimisation et la gestion fine de la mmoire utilise.
rieure. La tche interrompue initialement peut alors reprendre la Le langage est portable sur un grand nombre de plates-formes
main trs rapidement. (moyennant recompilation) tant quon nutilise pas de librairies sp-
Enfin, il est difficile de savoir exactement sous Windows quelles cifiques (comme par exemple les librairies fournies avec les mat-
sont les applications charges en mmoire, et quelles sont leurs riels dacquisition de donnes ou celles permettant de raliser des
priorits lexcution. Le planificateur des tches de Windows na interfaces graphiques).
pas non plus un comportement toujours dterministe : il donne Le C++, orient objet, permet de concevoir des applications
parfois la main des tches (ou threads ) de priorit infrieure qui complexes modulaires.
nont pas obtenu de temps dexcution depuis un certain temps, C et C++ sont des langages trs courants dans le domaine
mme sil doit bloquer pour cela dautres tches dont les priorits scientifique : de nombreuses librairies sont disponibles dans ce
sont plus importantes. Le but de ceci est principalement de langage, que ce soit pour le traitement dimages, le traitement du
conserver une interface graphique ractive. Ce dernier phnomne, signal, lacquisition de donnes. La plupart des SDK (Software
appel Priority Boost , peut dailleurs tre apprciable dans une Development Kits ) fournis avec les matriels spcifiques (cartes
phase de prototypage : si un algorithme de lapplication fonction- dacquisition de donnes, capteurs, etc.) sont disponibles en C++.
nant en priorit leve est trop gourmand et se met consommer
toute la puissance de calcul, il sera possible dans la plupart des cas Java, de son ct, bien que parfaitement portable sur plusieurs
sous Windows de terminer lapplication laide de la souris ou du plates-formes, possde des inconvnients dans le domaine du

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

dveloppement temps rel embarqu : une application Java la puissance lectrique disponible (prleve sur lalternateur) ne
consomme une quantit de mmoire importante, moins dutiliser dpassera pas 700 ou 800 W dans la plupart des cas (des batteries
des ditions spcifiques telles que J9 ou J2ME (pour Java 2 Micro supplmentaires permettant de faire fonctionner le systme moteur
Edition, plus limite en fonctionnalits), et les compilateurs sont teint sont souvent apprciables, ajoutant ainsi du volume de la mme
moins performants que ceux utiliss en C ou C++ (les fichiers Java faon) ;
tant compils en un code intermdiaire, dit byte code , indpen- dans des cas dutilisations en conditions extrmes (chemins,
dant de la plate-forme sur laquelle on linstalle, et qui sera interprt conduite sportive, situations durgence), des dispositifs damortis-
par la machine virtuelle du systme en phase dexcution). Enfin, le sement de chocs devront tre prvus (silent blocks, mousses, rsines
systme de libration de la mmoire en Java utilise un ramasse de fixation des cartes lectroniques, connecteurs visss).
miettes (Garbage collector ), une tche supplmentaire qui scanne Une configuration base sur un PC industriel en rack 4U peut tre
priodiquement la mmoire alloue pour librer les espaces non adapte ce type de situation. Un PC de bureau peut mme parfois
utiliss. La prsence de tches non contrles par le programmeur faire laffaire. Nous dtaillerons cela par la suite. Cette solution met
peut, dans certains cas, perturber le fonctionnement temps rel disposition de lquipe de projet une importante puissance de calcul,
dune application. une bonne modularit (possibilit dajout de capteurs, dvolutions du
Java propose cependant des alternatives permettant le dve- PC) pour des cots relativement faibles.
loppement dapplications temps rel laide de machines virtuelles 2. En revanche, dans le cas de drones, les contraintes dencombre-
spcifiques. Une spcification pour un langage Java temps rel ment et de poids feront choisir des systmes plus compacts, base
est dveloppe par le Real-Time Java Expert Group (voir par exemple de cartes PC-104, beaucoup plus petites et lgres, rsis-
http://rtsj.dev.java.net). tant bien aux chocs et aux vibrations. La puissance de calcul et les
interfaces dentres/sorties disponibles seront alors beaucoup plus
Visual Basic ou C# enfin, si lon travaille sous Windows, pourront limites.
tre adapts au dveloppement rapide dinterfaces graphiques ou
dapplications simples, mais restent inadapts pour raliser des Les capteurs utiliss sont trs divers suivant les applications. La
applications scientifiques complexes et optimises. 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
En fonction des besoins en performance de lapplication envi- puissance de calcul des processeurs, des capacits de stockage des
sage, on optera pour une solution ou une autre, et il faut gar- donnes de plus en plus importantes (disques durs SCSI rapides,
der lesprit que tous ces langages peuvent communiquer systmes RAID, mmoires flash).
entre eux, soit au sein dune mme application, soit par linter-
Cest grce de tels gains en performance que lon se tourne
mdiaire de librairies partages (.dll ou .so). Nous parlerons
rsolument, ces dernires annes, vers des applications de fusion
aussi dans le paragraphe 3 de collaborations entre diffrents
de donnes, mettant en jeu de multiples capteurs.
logiciels pour raliser une tche complexe.
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. tapes du prototypage
3.2 Capteurs utiliss
3.1 Spcification, choix
Voici quelques exemples de capteurs utiliss en recherche et
et mise en place du matriel dveloppement pour raliser les prototypes des applications de
demain.
Une fois les besoins clairement dfinis et le cahier des charges
rdig et accept, on sera capable de spcifier le matriel dont on Camras vido, analogiques ou numriques (figure 4)
va avoir besoin (capteurs, matriel informatique, alimentations,
Les camras analogiques sont maintenant souvent dotes de
actionneurs).
capteurs CCD et dlivrent un signal analogique qui doit tre chan-
On procdera gnralement (et idalement) de lextrieur vers tillonn sur une carte dacquisition spcifique. Certaines cartes
lintrieur : cest--dire que lon commencera par dterminer les dacquisition sont capables deffectuer une compression en temps
lments dont on aura besoin pour interagir avec lenvironnement rel sur les images acquises, ce qui permet de diminuer les dbits
(capteurs et actionneurs), puis par dfinir les moyens informa- lenregistrement par exemple (compressions jpeg, mpeg, en
tiques qui devront tre mis en place pour acqurir et traiter les ondelettes, etc.).
donnes des capteurs et/ou gnrer et envoyer les commandes. Les camras numriques sont de plus en plus utilises : les bus
Il faudra bien entendu tenir compte dun certain nombre de de donnes numriques tant de plus en plus performants, on peut
contraintes, particulirement importantes dans le cas dapplica- les utiliser pour des acquisitions haute frquence, haute rsolution
tions embarques. Parmi les plus courantes, on trouvera celles-ci : par exemple. Leur connexion et dconnexion peuvent souvent
encombrement ; seffectuer chaud , elles peuvent de mme tre pilotes par
poids ; logiciel (rglages de formats vido, de frquences dacquisition, de
consommation lectrique (fonctionnement sur batteries, ou temps douverture, de gain, douverture, etc.).
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 ; Figure 4 Camras (standard analogique et strovision FireWire)

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
S 8 192 6 Techniques de lIngnieur
________________________________________________________________________________ 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


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

le RAID 6 (Stripping + 2 disques de parit) : ce systme


rserve deux disques au stockage de la parit. Le systme fonc-
PARAMTRES tionne aprs la perte de deux disques. Taux de transfert en criture
mdiocre, taux de transfert en lecture et taux de requtes excel-
lents.
E S Bien sr, il faudra toujours rester vigilant en ce qui concerne
N O
T R lencombrement et la consommation lectrique ncessaire au
R T fonctionnement de ces systmes de stockages sur une machine
I embarque. Les disques durs sont en effet des priphriques
E E consommateurs en nergie, et particulirement au dmarrage du
S S PC (mise en rotation des plateaux).

Figure 9 Schma dune brique fonctionnelle


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

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur 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 Le prototypage dun systme embarqu temps rel est donc un
de raliser un calculateur qui sera capable de raliser lacquisition, projet impliquant autant le matriel que le logiciel. Les perfor-
les traitements et deffectuer les actions qui en rsultent. mances galopantes des PC standards poussent au dveloppement
de systmes de plus en plus complexes, de plus en plus
Leffort portera alors principalement sur loptimisation du sys- intelligents , mettant en jeu de hauts dbits de donnes
tme et des algorithmes, ainsi que sur la fiabilit du portage de provenant de sources diverses. On se tourne de plus en plus vers
ceux-ci. des applications de fusion de donnes.
Suivant les besoins en capacit de calcul de lapplication Face cela, des outils logiciels de plus en plus performants,
raliser, ce calculateur pourra tre ralis base dun processeur ddis au prototypage rapide sont dvelopps, chacun dot de ses
dot dun OS temps rel lger, ou bien, pour des applications plus avantages et de ses inconvnients.
gourmandes, bases de puces spcifiques de mme type que dcri- Il est vident quun seul logiciel ne peut pas rpondre toutes
tes au paragraphe 3.5. les attentes des ingnieurs dveloppement. Il est donc important
Du fait du cot de dveloppement et du temps de portage vers de se tourner vers des logiciels spcialiss cooprant , capables
de tels systmes, il est ncessaire de pousser au maximum la de schanger des donnes et des commandes.
validation des algorithmes sur plate-forme logicielle. La tendance est donc lintgration logicielle de bout en bout,
Pour faciliter ensuite le portage vers un calculateur embarqu, en tirant ventuellement parti de la simulation. Cela permet de se
des projets de standardisation des interfaces ont vu le jour dgager au maximum des contraintes matrielles dun prototype
(exemple : OSEK/VDX http://www.osek-vdx.org). (disponibilit, cot), et de favoriser le tout logiciel, plus modulaire,
permettant le travail collaboratif et la capitalisation des travaux
Des projets de recherche portent sur la conversion de code (C et effectus.
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, Pour des informations complmentaires le lecteur pourra se
de phases de calibration, puis de fabrication en grande srie. 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

Vous aimerez peut-être aussi