Choi­sir un sys­tème d’ex­ploi­ta­tion pour une ap­pli­ca­tion em­bar­quée

Plu­sieurs cri­tères tech­niques et éco­no­miques pèsent dans la balance lors­qu’il s’agit de choi­sir entre un OS haut de gamme de type Li­nux/Win­dows, un sys­tème d’ex­ploi­ta­tion temps réel, un OS libre ou un noyau dé­ve­lop­pé sur me­sure en in­terne.

Electronique S - - La Une -

De nos jours, il est rare de trou­ver un sys­tème em­bar­qué dé­pour­vu de sys­tème d’ex­ploi­ta­tion (OS). Seul le type d’ap­pa­reil le plus simple peut être cons­truit ef­fi­ca­ce­ment sans un type de noyau quel­conque. Tou­te­fois, cette pos­si­bi­li­té ne doit pas être écar­tée. La gamme com­plète d’ap­pa­reils em­bar­qués peut être re­pré­sen­tée par un gra­phique de la com­plexi­té du pro­ces­seur (gé­né­ra­le­ment la lar­geur du bus de don­nées) par rap­port à la com­plexi­té du lo­gi­ciel ( voir fi­gure page sui­vante). Elle peut être gros­siè­re­ment di­vi­sée en quatre qua­drants. La par­tie su­pé­rieure droite (lo­gi­ciels com­plexes exé­cu­tés sur un pro­ces­seur haut de gamme) re­pré­sente le champ tra­di­tion­nel des sys­tèmes d’ex­ploi­ta­tion temps réel ( RTOS) et d’autres sys­tèmes d’ex­ploi­ta­tion. Sur un pro­ces­seur moins puis­sant, il peut être utile de dé­ployer un noyau de base si le lo­gi­ciel est re­la­ti­ve­ment com­plexe. Par­fois, un pro­ces­seur puis­sant est em­ployé pour exé­cu­ter un lo­gi­ciel re­la­ti­ve­ment simple, lorsque la per­for­mance du pro­ces­seur est né­ces­saire pour ac­cé­lé­rer la vi­tesse d’exé­cu­tion. Dans ce cas, l’uti­li­sa­tion d’un noyau n’est pas stric­te­ment obli­ga­toire, mais peut être une approche pru­dente car elle ac­croît l’évo­lu­ti­vi­té de l’ar­chi­tec­ture lo­gi­cielle et per­met ul­té­rieu­re­ment de prendre en charge une aug­men­ta­tion de la com­plexi­té. Ce n’est vé­ri­ta­ble­ment que lors­qu’un lo­gi­ciel simple est exé­cu­té sur un ap­pa­reil bas de gamme qu’il est pos­sible de se pas­ser d’un noyau quel­conque. Après avoir conclu qu’un OS est né­ces­saire pour un pro­jet, reste la ques­tion du choix. Gé­né­ra­le­ment, quatre op­tions sont pos­sibles: op­ter pour un sys­tème d’ex­ploi­ta­tion haut de gamme (tel que Li­nux ou une va­riante em­bar­quée de Win­dows), choi­sir un sys­tème d’ex­ploi­ta­tion temps réel, pour le­quel un large choix est dis­po­nible, dé­ployer l’un des sys­tèmes d’ex­ploi­ta­tion libres ai­sé­ment ac­ces­sibles ou mettre en oeuvre un noyau en in­terne.

Sys­tèmes d’ex­ploi­ta­tion com­mer­ciaux

Le mar­ché foi­sonne de bons sys­tèmes d’ex­ploi­ta­tion. Ces pro­duits pré­sentent un cer­tain nombre d’avan­tages et d’in­con­vé­nients par rap­port aux autres al­ter­na­tives. De nom­breux pro­duits RTOS com­mer­ciaux sont dis­po­nibles, la plu­part pro­ve­nant de four­nis­seurs à la ré­pu­ta­tion bien éta­blie. Tou­te­fois cet as­pect doit être soi­gneu­se­ment éva­lué. La taille de l’en­tre­prise, la ma­tu­ri­té du pro­duit et la base d’uti­li­sa­teurs consti­tuent des fac­teurs clés. L’une des prin­ci­pales exi­gences est la dis­po­ni­bi­li­té du sup­port tech­nique. Dans le pro­ces­sus de sé­lec­tion d’un RTOS, l’ache­teur et le ven­deur prennent un en­ga­ge­ment à long terme. La ca­pa­ci­té de mi­gra­tion fu­ture vers un nou­veau pro­ces­seur consti­tue l’un des as­pects es­sen­tiels de la re­la­tion. Vous pou­vez faire confiance à un four­nis­seur RTOS de re­nom pour prendre en charge de nou­veaux ap­pa­reils en res­pec­tant les échéances de votre pro­jet. Leur pro­duit est pro­ba­ble­ment con­çu pour sim­pli­fier le pro­ces­sus de por­tage. Une bonne do­cu­men­ta­tion est es­sen­tielle et peut être exi­gée d’un four­nis­seur de RTOS com­mer­cial. Il n’y a au­cune rai­son pour ne pas de­man­der à voir un échan­tillon des ma­nuels. Au­tre­fois, l’ex­pé­di­tion dans le monde en­tier de ma­nuels im­pri­més au­rait été cer­tai­ne­ment dif­fi­cile. Au­jourd’hui, l’en­voi d’un fi­chier PDF est une at­tente re­la­ti­ve­ment fa­cile à sa­tis­faire. Le code source est dis­po­nible pour de nom­breux OS com­mer­ciaux, par­fois gra­tui­te­ment ou moyen­nant des frais spé­ci­fiques. Il est pré­fé­rable de s’as­su­rer que le code est li­sible car le code source peut ra­pi­de­ment de­ve­nir in­com­pré­hen­sible pour un no­vice. Aus­si, ce code doit être suf­fi­sam­ment com­men­té. Il n’est pas cen­sé rem­pla­cer une so­lide do­cu­men­ta­tion, mais s’avère un com­plé­ment utile. Le dé­ve­lop­pe­ment d’une ap­pli­ca­tion pa­ral­lé­li­sée ( mul­ti­thread) com­porte de nom­breux dé­fis, l’un d’eux étant le dé­bo­gage. Dis­po­ser d’un type quel­conque de dé­bo­gueur com­pa­tible avec le RTOS peut s’avé­rer très utile. La prise en charge de point d’ar­rêt glo­bal (où le pro­ces­seur est mo­men­ta­né­ment in­ter­rom­pu) est re­com­man­dée. Le mode exé­cu­tion (où seule la tâche en cours est ar­rê­tée) peut être éga­le­ment utile dans d’autres cas. Il est rare qu’une ap­pli­ca­tion em­bar­quée se contente d’un simple noyau pa­ral­lé­li­sé. D’autres com­po­sants lo­gi­ciels sont gé­né­ra­le­ment né­ces­saires. Un OS com­mer­cial est sus­cep­tible d’en comp­ter un large éven­tail, no­tam­ment des pro­to­coles de com­mu­ni­ca­tion qui doivent être en­tiè­re­ment va­li-

dés, des sys­tèmes de fi­chiers (y com­pris flash) et un mo­dule gra­phique pour fa­ci­li­ter la concep­tion de l’in­ter­face uti­li­sa­teur. L’un des dé­fis propres au dé­ve­lop­pe­ment d’ap­pli­ca­tions em­bar­quées est le tra­vail re­la­tif à l’ex­ploi­ta­tion des pé­ri­phé­riques du ma­té­riel. Avec un OS, ce der­nier im­plique le dé­ve­lop­pe­ment de pi­lotes spé­ci­fiques. Un OS com­mer­cial dis­po­se­ra pro­ba­ble­ment d’une vaste gamme de pi­lotes pour les pé­ri­phé­riques les plus stan­dards et per­met­tra le dé­ve­lop­pe­ment de pi­lotes per­son­na­li­sés. En termes tech­niques, chaque sys­tème em­bar­qué est dif­fé­rent. Le pro­ces­seur, la mé­moire et les pé­ri­phé­riques va­rient tous d’un ap­pa­reil à l’autre. Les sys­tèmes dif­fèrent éga­le­ment en fonc­tion du mar­ché vi­sé, du prix fi­nal de l’équi­pe­ment, ain­si que des vo­lumes pro­duits. Ces dif­fé­rences ont une in­ci­dence sur les op­tions de li­cence de l’OS. Dans cer­tains cas, le paie­ment de droits de re­pro­duc­tion (quelques eu­ros par un ap­pa­reil) est rai­son­nable. Dans d’autres cas, no­tam­ment lorsque des vo­lumes très im­por­tants sont pré­vus, un mo­dèle sans re­de­vance de re­co­pie peut être idéal. L’une des ob­jec­tions cou­ram­ment avan­cées contre l’uti­li­sa­tion d’un OS com­mer­cial est le manque de connais­sance in­terne du dé­ve­lop­peur quant à ses fonc­tions. Ce qui peut être vrai, mais est-ce réel­le­ment im­por­tant? Si l’OS se com­porte con­for­mé­ment à la do­cu­men­ta­tion, pour­quoi im­porte-t-il de sa­voir exac­te­ment com­ment il par­vient au ré­sul­tat? Il est lé­gi­time de pen­ser que, dans la me­sure où l’ex­ploi­ta­tion d’un OS exige une cer­taine spé­cia­li­sa­tion, la plu­part des équipes de déve- lop­pe­ment de lo­gi­ciels em­bar­qués n’ont pas les moyens de main­te­nir une telle ex­per­tise. Si le code source est dis­po­nible, il ap­porte une ga­ran­tie au cas où le fonc­tion­ne­ment in­terne de l’OS de­vrait être vé­ri­fié. Les ache­teurs de sys­tèmes d’ex­ploi­ta­tion, comme toute per­sonne ache­tant un pro­duit, ne veulent pas dé­pendre d’un seul four­nis­seur, même si ce der­nier ac­cueille­rait fa­vo­ra­ble­ment cette éven­tua­li­té. Avec les OS com­mer­ciaux, l’une des prin­ci­pales dif­fé­rences entre les di­verses op­tions est l’in­ter­face de pro­gram­ma­tion, l’API. En réa­li­té, ces der­nières va­rient peu. Un por­tage ul­té­rieur, si un chan­ge­ment de four­nis­seur d’OS s’avé­rait né­ces­saire, ne re­pré­sen­te­ra donc pro­ba­ble­ment pas un pro­blème ma­jeur. Le res­pect des normes, bien sûr, en­gendre pour le moins un cer­tain de­gré d’au­to­no­mie vis-à-vis du four- nis­seur. Dans ce cas, l’API POSIX consti­tue pro­ba­ble­ment la meilleure op­tion. Une autre ob­jec­tion cou­rante aux OS com­mer­ciaux est leur nombre ex­ces­sif de fonc­tion­na­li­tés, car ils doivent ré­pondre aux be­soins d’une im­por­tante base de clients. Bien que ce­la soit vrai, le coût des fonc­tion­na­li­tés est lar­ge­ment amor­ti et n’a donc pas d’im­pact réel sur un client don­né. Il est éga­le­ment pro­bable qu’un OS soit pro­po­sé sous la forme d’un en­semble de com­po­sants, dont bon nombre sont op­tion­nels. À l’ori­gine des RTOS com­mer­ciaux, les pro­duits n’étaient qu’un as­sem­blage mo­no­li­thique de blocs de code. Face à l’aug­men­ta­tion du nombre de fonc­tion­na­li­tés dis­po­nibles, la no­tion de confi­gu­ra­bi­li­té est ap­pa­rue. Un OS en­tiè­re­ment confi­gu­rable per­met d’in­té­grer uni­que­ment les

fonc­tion­na­li­tés re­quises dans l’image exé­cu­table fi­nale.

Sys­tèmes d’ex­ploi­ta­tion libres

Dans ce contexte, les OS gra­tuits ou « libres » n’in­cluent pas vrai­ment Li­nux, car la plu­part des dé­ve­lop­peurs de sys­tèmes em­bar­qués sont sus­cep­tibles d’in­ves­tir dans l’achat d’une dis­tri­bu­tion prise en charge et in­té­grée de Li­nux. Ces dis­tri­bu­tions ne sont donc pas réel­le­ment gra­tuites. Cette sec­tion tient compte des RTOS plus com­pacts et plus fa­ci­le­ment té­lé­char­geables, et qui sont par­ti­cu­liè­re­ment pri­sés. L’in­té­rêt ma­jeur ici est clai­re­ment l’ab­sence de coûts ini­tiaux, mais aus­si après le dé­ploie­ment, car il n’y a au­cun frais de li­cence à pré­voir. Les OS libres ont tou­jours ten­dance à in­clure le code source. Ce der­nier est cer­tai­ne­ment utile à titre de ré­fé­rence, car la do­cu­men­ta­tion peut être li­mi­tée et l’as­sis­tance dif­fi­cile à ob­te­nir. Il consti­tue éga­le­ment une exi­gence pour la confi­gu­ra­tion et le por­tage vers un nou­vel en­vi­ron­ne­ment ma­té­riel, ce qui, bien sûr, in­combe à l’uti­li­sa­teur. Comme pour de nom­breux types de lo­gi­ciels pris en charge par l’uti­li­sa­teur, les RTOS libres at­tirent sou­vent une forte clien­tèle, ce qui se tra­duit par une com­mu­nau­té en ligne dy­na­mique au­près de la­quelle l’as­sis­tance est dis­po­nible gra­tui­te­ment. Bien que cet as­pect soit par­ti­cu­liè­re­ment at­trayant et utile, l’une des pré­oc­cu­pa­tions est leur lon­gé­vi­té. Les lo­gi­ciels em­bar­qués ont ten­dance à suivre les tech­no­lo­gies ou pro­duits à la mode. Que se passe-t-il si le RTOS que vous avez choi­si de­vient ob­so­lète ? En outre, le type de sou­tien de la com­mu­nau­té est gé­né­ra­le­ment axé sur la ver­sion ac­tuelle du lo­gi­ciel. Si votre pro­duit uti­lise une ver­sion an­té­rieure, vous au­rez peu­têtre des dif­fi­cul­tés à trou­ver de l’aide pour ré­soudre des pro­blèmes. Le dé­ploie­ment d’un OS sur un équi­pe­ment em­bar­qué est un en­ga­ge­ment à long terme. La ques­tion d’un sup­port à long terme est donc pri­mor­diale. Pour un OS libre, pou­vez-vous comp­ter sur la pré­sence de la com­mu­nau­té à long terme? Aus­si, la do­cu­men­ta­tion estelle à la hau­teur étant don­né qu’elle peut sou­vent ap­por­ter des so­lu­tions ? Le dé­ve­lop­pe­ment d’un code pa­ral­lé­li­sé est une tâche com­plexe et l’uti­li­sa­tion d’ou­tils de dé­bo­gage adé­quats s’im­pose. Si un OS libre est pri­sé, un tel ou­til peut avoir été dé­ve­lop­pé par un tiers, mais la ques­tion de l’as­sis­tance de­meure. Les lo­gi­ciels libres re­pré­sentent un dé­fi psy­cho­lo­gique. Dans la me­sure où le code source est im­mé­dia­te­ment dis­po­nible et que les dé­ve­lop­peurs le per­çoivent comme n’ayant au­cune va­leur mo­né­taire, la ten­ta­tion de l’« amé­lio­rer » est grande. Cette amé­lio­ra­tion peut prendre la forme d’ajus­te­ments mi­neurs vi­sant à ac­croître l’ef­fi­ca­ci­té du code ou d’ajouts de nou­velles fonc­tion­na­li­tés. Dans les deux cas, il peut en ré­sul­ter l’uti­li­sa­tion de nom­breuses ver­sions si­mi­laires, mais dif­fé­rentes de l’OS dans plu­sieurs pro­jets. La main­te­nance de­vient alors un vé­ri­table casse-tête. Dans la plu­part des ap­pli­ca­tions em­bar­quées dans les­quelles un OS est dé­ployé, l’uti­li­sa­tion d’un com­po­sant plus éla­bo­ré qu’un simple noyau pa­ral­lé­li­sé, par exemple un sys­tème de fi­chiers ou une pile ré­seau, est né­ces­saire. De telles op­tions peuvent être dis­po­nibles, mais dans le cas contraire, un ef­fort sup­plé­men­taire doit être consen­ti pour lo­ca­li­ser le com­po­sant lo­gi­ciel né­ces­saire et le por­ter ou l’adap­ter à l’OS choi­si. L’un des prin­ci­paux cri­tères de sé­lec­tion d’un OS (qu’il soit libre ou non) est la prise en charge du pro­ces­seur qui a été choi­si pour votre pro­jet. Ce­pen­dant, après avoir choi­si l’OS, un in­ves­tis­se­ment consi­dé­rable en temps et en ef­forts s’im­pose. S’il peut être mis à pro­fit sur un grand nombre de pro­jets, ce­la en vaut la peine. Si dif­fé­rents pro­ces­seurs sont sé­lec­tion­nés, com­ment ga­ran­tir la dis­po­ni­bi­li­té ac­tuelle ou fu­ture de l’as­sis­tance ? Tous les lo­gi­ciels, qu’ils soient libres ou com­mer­ciaux, font d’une ma­nière ou d’une autre l’ob­jet d’une li­cence. La li­cence peut être un do­cu­ment très com­plexe qui li­mite le dé­ploie­ment du lo­gi­ciel d’une cer­taine fa­çon. Les sanc­tions en cas de vio­la­tion d’une li­cence peuvent être sé­vères. Les lo­gi­ciels open source peuvent s’avé­rer par­ti­cu­liè­re­ment pro­blé­ma­tiques, car la li­cence risque de com­pro­mettre l’état de votre code ap­pli­ca­tif, vous obli­geant ain­si à mettre son code source à la dis­po­si­tion du pu­blic. Avant d’in­té­grer un code open source dans votre ap­pli­ca­tion, il est re­com­man­dé d’ob­te­nir l’avis d’un conseiller ju­ri­dique.

Sys­tèmes d’ex­ploi­ta­tion per­son­na­li­sés

La rai­son la plus cou­ram­ment in­vo­quée pour jus­ti­fier le dé­ve­lop­pe­ment d’un noyau en in­terne est le main­tien du contrôle com­plet du code. Cette approche semble ju­di­cieuse, mais elle pré­sup­pose que les res­sources pos­sé­dant les com­pé­tences né­ces­saires, qui sont re­la­ti­ve­ment spé­cia­li­sées, soient main­te­nues en fonc­tion. Il n’existe, bien en­ten­du, au­cun coût de li­cence per­ma­nent pour le code dé­ve­lop­pé en in­terne. Mais les coûts ré­cur­rents de main­te­nance ne peuvent pas être igno­rés. Un autre mo­tif cou­ram­ment avan­cé pour le dé­ve­lop­pe­ment en in­terne est la ca­pa­ci­té des RTOS ob­te­nus à ré­pondre pré­ci­sé­ment aux exi­gences du pro­jet. On pour­rait pen­ser que les fonc­tions du noyau sont plus sus­cep­tibles d’être dé­fi­nies en fonc­tion des ef­forts de dé­ve­lop­pe­ment pou­vant y être consa­crés. Un OS com­mer­cial, en­tiè­re­ment confi­gu­rable, se­ra très pro­ba­ble­ment en me­sure de ré­pondre pré­ci­sé­ment aux be­soins et ce sans com­pro­mis. Toute opé­ra­tion de dé­ve­lop­pe­ment de lo­gi­ciel coûte de l’ar­gent. Ce­pen­dant, les coûts de dé­ve­lop­pe­ment d’un noyau en in­terne sont

cou­ram­ment ab­sor­bés dans un pro­jet de sorte qu’ils ne sont pas vi­sibles. Une fois dé­ployé, il est pro­bable qu’un OS soit uti­li­sé pen­dant un cer­tain temps. Une as­sis­tance à long terme est par consé­quent né­ces­saire. Ce­la ne pose pas de pro­blème si les dé­ve­lop­peurs res­tent en fonc­tion. En outre, le be­soin d’as­sis­tance est moins pro­blé­ma­tique si le code est mi­nu­tieu­se­ment do­cu­men­té. Mais il s’agit là d’hy­po­thèses dangereuses. Comme in­di­qué pré­cé­dem­ment, le code pa­ral­lé­li­sé peut pré­sen­ter des er­reurs sub­tiles, qui né­ces­sitent un dé­bo­gueur com­pa­tible avec l’OS pour être dé­tec­tées. Après avoir créé un noyau, il est peu pro­bable que des ef­forts sup­plé­men­taires soient dé­ployés pour dé­ve­lop­per un tel ou­til. Une so­lu­tion consiste à adap­ter un dé­bo­gueur com­mer­cial au noyau in­terne. Il est pos­sible qu’un noyau in­terne soit uti­li­sé dans plu­sieurs pro­jets au fil du temps. Tou­te­fois, il est à craindre que chaque équipe de pro­jet cher­che­ra à amé­lio­rer le code de base. Il en ré­sulte plu­sieurs ver­sions du noyau, ce qui aug­men­te­ra le pro­blème de sup­port et de main­te­nance. Il est peu pro­bable qu’un simple noyau suf­fise. Le dé­ve­lop­pe­ment de com­po­sants lo­gi­ciels sup­plé­men­taires aug­men­te­rait da­van­tage les coûts de dé­ve­lop­pe­ment et il se­rait éton­nant que les four­nis­seurs de com­po­sants com­mer­ciaux en­vi­sagent la pos­si­bi­li­té d’un por­tage vers des RTOS pro­prié­taires. À me­sure que la tech­no­lo­gie évo­lue, il se­ra né­ces­saire de pré­voir un chan­ge­ment de pro­ces­seur. Ce­la est un pro­blème si le noyau exige des ca­rac­té­ris­tiques de trai­te­ment très so­phis­ti­quées. Gé­né­ra­le­ment, une par­tie si­gni­fi­ca­tive du lan­gage as­sem­bleur ain­si que la prise en charge de «l’en­dia­nisme» (or­ga­ni­sa­tion de l’en­co­dage) et des in­ter­rup­tions doivent être exa­mi­nées. Le prin­ci­pal in­con­vé­nient du dé­ve­loppe- ment d’un OS en in­terne est d’ordre phi­lo­so­phique. Les en­tre­prises les plus per­for­mantes se concentrent tou­jours sur leurs com­pé­tences de base. À moins d’être un dé­ve­lop­peur de noyaux, il semble plus lo­gique de se fo­ca­li­ser sur votre coeur de mé­tier.

Cri­tères de choix

Une fois la dé­ci­sion prise d’uti­li­ser un OS com­mer­cial ou du moins sup­por­té com­mer­cia­le­ment, une sé­rie de ques­tions de qua­li­fi­ca­tion doivent être ré­so­lues:

- Votre ap­pli­ca­tion s’exé­cute-t-elle en temps réel ?

Temps réel ne veut pas for­cé­ment dire ra­pide, mais plu­tôt pré­vi­sible ou dé­ter­mi­niste. Ces termes ne sont pas ab­so­lus. Il s’agit de sa­voir dans quelle me­sure votre sys­tème doit ré­agir de ma­nière pré­vi­sible aux évé­ne­ments.

- Quelle est l’im­por­tance du fac­teur temps?

Si vous né­ces­si­tez un ni­veau éle­vé de dé­ter­mi­nisme, alors un RTOS est pro­ba­ble­ment votre meilleur choix. Dans cer­tains cas, Li­nux peut conve­nir, en par­ti­cu­lier si l’uti­li­sa­tion d’ex­ten­sions en temps réel est ac­cep­table.

- La taille de la mé­moire est-elle li­mi­tée?

Con­trai­re­ment à un or­di­na­teur de bu­reau, la taille de la mé­moire de la plu­part des sys­tèmes em­bar­qués est li­mi­tée. La quan­ti­té de mé­moire dis­po­nible est un autre cri­tère de choix pri­mor­dial. À moins que plu­sieurs mé­ga­oc­tets soient dis­po­nibles pour l’OS, il est peu pro­bable que la mise en oeuvre de Li­nux soit une so­lu­tion viable.

- La puis­sance du pro­ces­seur est-elle li­mi­tée?

La puis­sance de pro­ces­seur dis­po­nible est tout aus­si im­por­tante. Si la puis­sance du pro­ces­seur est tout juste suf­fi­sante pour exé­cu­ter l’ap­pli­ca­tion, vous ne dis­po­sez d’au­cune marge pour ab­sor­ber les coûts d’exé­cu­tion in­tro­duits par l’OS. Les sys­tèmes d’ex­ploi­ta­tion en temps réel ont ten­dance à uti­li­ser le temps pro­ces­seur de ma­nière très ef­fi­cace, mais éga­le­ment pré­vi­sible.

- La consom­ma­tion d’éner­gie de l’ap­pa­reil est-elle une prio­ri­té ?

Sur de nom­breux types de sys­tèmes, la consom­ma­tion d’éner­gie se trouve au centre des pré­oc­cu­pa­tions, par sou­ci de pré­ser­va­tion de la du­rée de vie de la bat­te­rie sur les ap­pa­reils por­ta­tifs ou pour des rai­sons en­vi­ron­ne­men­tales et éco­no­miques dans le cas de sys­tèmes fixes. Les cri­tères pré­cé­dents de taille de mé­moire et de puis­sance du pro­ces­seur ont un im­pact à ce ni­veau. La taille et l’ef­fi­ca­ci­té d’exé­cu­tion de l’OS ont donc leur im­por­tance. Un cer­tain nombre de sys­tèmes d’ex­ploi­ta­tion in­cluent des fonc­tions de ges­tion de consom­ma­tion d’éner­gie. Li­nux in­clut quelques-unes de ces fonc­tion­na­li­tés et un nombre crois­sant de RTOS in­tègrent des mé­ca­nismes de ges­tion d’ali­men­ta­tion, no­tam­ment Nu­cleus.

- Dis­po­sez-vous de pé­ri­phé­riques in­con­nus ou per­son­na­li­sés?

Un sys­tème em­bar­qué in­clut tou­jours un cer­tain nombre de pé­ri­phé­riques pa­ral­lè­le­ment au pro­ces­seur. Si ces pé­ri­phé­riques sont lar­ge­ment uti­li­sés, des pi­lotes de­vraient être dis­po­nibles, quel que soit l’OS choi­si. Il en va de même pour les pro­to­coles de com­mu­ni­ca­tion. Si vous pos­sé­dez des ap­pa­reils moins connus, vous ris­quez d’avoir des pro­blèmes. Même si de nom­breux RTOS sup­portent une gamme éten­due de pi­lotes, ils se­ront presque tou­jours de­van­cés par Li­nux. Si vous dis­po­sez d’un ma­té­riel unique et per­son­na­li­sé, un pi­lote de­vra être écrit. L’un des avan­tages de Li­nux est la dis­po­ni­bi­li­té d’une très large base de com­pé­tences pour le dé­ve­lop­pe­ment de pi­lotes. Vous avez donc la pos­si­bi­li­té de re­cru­ter du per­son­nel ou de de­man­der l’aide d’un four­nis­seur pre­nant en charge un sys­tème Li­nux em­bar­qué, tel que Men­tor Em­bed­ded.

- Dis­po­sez-vous d’une uni­té de ges­tion de la mé­moire (ou pou­vez-vous en in­clure une)? Si votre concep­tion n’in­clut pas d’uni­té de ges­tion de la mé­moire (MMU), il ne se­ra pas pos­sible d’uti­li­ser Li­nux, car une MMU est obli­ga­toire pour tous les sys­tèmes d’ex­ploi­ta­tion sup­por­tant un mo­dèle de pro­ces­sus. La plu­part des RTOS sup­portent des mo­dèles d’exé­cu­tion par tâche ( thread) et ne né­ces­sitent pas de MMU. Ce­pen­dant, cer­tains RTOS peuvent uti­li­ser ef­fi­ca­ce­ment une MMU, si celle-ci est dis­po­nible. - La sé­cu­ri­té des ap­pli­ca­tions est-elle une prio­ri­té ?

Cer­tains ap­pa­reils em­bar­qués ont be­soin d’une sé­cu­ri­té sup­plé­men­taire. Sou­vent, ce­la si­gni­fie que les tâches doivent être pro­té­gées les unes des autres. Une telle pro­tec­tion ne peut vé­ri­ta­ble­ment être mise en oeuvre que si une MMU est dis­po­nible. Les sys­tèmes d’ex­ploi­ta­tion haut de gamme et quelques RTOS uti­lisent un mo­dèle de pro­ces­sus of­frant un haut ni­veau de sé­cu­ri­té. D’autres RTOS, ex­ploi­tant un mo­dèle d’exé­cu­tion de type thread, peuvent éga­le­ment of­frir un ni­veau de pro­tec­tion adé­quat en uti­li­sant la MMU pour rendre sim­ple­ment des par­ties de la mé­moire in­ac­ces­sibles au lieu de re­map­per en­tiè­re­ment la mé­moire.

- Votre ap­pli­ca­tion né­ces­site-t-elle une cer­ti­fi­ca­tion de sé­cu­ri­té?

Dans cer­tains sec­teurs, la cer­ti­fi­ca­tion est une obli­ga­tion. Ce pro­ces­sus peut être coû­teux et exige l’ac­cès à l’in­té­gra­li­té du code source. Les coûts de cer­ti­fi­ca­tion étant d’une cer­taine fa­çon liés au nombre de lignes de code, un OS de plus pe­tite taille est na­tu­rel­le­ment at­trac­tif. Il est gé­né­ra­le­ment né­ces­saire de cer­ti­fier une ap­pli­ca­tion com­plète. Il n’est donc pas pos­sible d’ache­ter un OS pré-cer­ti­fié. Cer­tains four­nis­seurs d’OS peuvent vous ai­der en four­nis­sant une par­tie de la do­cu­men­ta­tion re­quise. Il est évi­dem­ment re­com­man­dé de choi­sir un OS qui a fait ses preuves dans le do­maine d’ap­pli­ca­tion en ques­tion. Par exemple, même s’il n’est pas pos­sible de vous vendre une ver­sion du RTOS Nu­cleus « cer­ti­fiée pour sys­tème mé­di­cal », ce RTOS a été uti­li­sé avec suc­cès par un grand nombre d’uti­li­sa­teurs dans ces ap­pli­ca­tions.

- Né­ces­si­tez-vous une in­ter­opé­ra­bi­li­té avec les pro­gi­ciels ?

Si votre ap­pa­reil doit as­su­rer une in­ter­opé­ra­bi­li­té im­por­tante avec des pro­gi­ciels, dans ce cas, les pro­duits Mi­cro­soft peuvent être un ex­cellent choix. - Connaît-on le prix de vente et le vo­lume li­vré pour l’ap­pli­ca­tion ?

Il est fa­cile de se perdre dans les dé­tails tech­niques lors de l’ana­lyse des dif­fé­rents sys­tèmes d’ex­ploi­ta­tion dis­po­nibles. Sou­vent, comme dans de nom­breuses dé­ci­sions d’achat, le coût est un fac­teur dé­ci­sif. Dans ce cas, il ne s’agit pas seule­ment d’ob­te­nir le meilleur prix pos­sible. Le mo­dèle de ges­tion est éga­le­ment dé­ter­mi­nant. Pour cer­tains ap­pa­reils em­bar­qués, le paie­ment d’une re­de­vance sur cha­cun d’eux est rai­son­nable. Pour d’autres avec un vo­lume de pro­duc­tion im­por­tant, un mo­dèle libre de re­de­vances est pré­fé­rable. L’open source est bien sûr un choix in­té­res­sant, mais, dans ce cas, comme pour les pro­duits stric­te­ment com­mer­ciaux, les coûts de main­te­nance ré­cur­rents doivent être pris en compte.

- Avez-vous une ex­pé­rience si­gni­fi­ca­tive avec d’autres OS?

La for­ma­tion étant oné­reuse et fas­ti­dieuse, il est tou­jours pré­fé­rable de ti­rer par­ti de l’ex­pé­rience exis­tante chaque fois qu’il est pos­sible. Si l’équipe de dé­ve­lop­pe­ment est fa­mi­lia­ri­sée avec une API en par­ti­cu­lier, ce­la peut avoir une in­fluence si­gni­fi­ca­tive sur le pro­ces­sus de sé­lec­tion. Bien en­ten­du, si cette ex­pé­rience porte sur une norme, comme POSIX, votre marge d’ac­tion est plus grande. L’ex­pé­rience au­près d’un four­nis­seur a éga­le­ment son im­por­tance. En par­ti­cu­lier, les échanges an­té­rieurs avec le sup­port tech­nique sont pré­cieux. De même, te­nez compte de la qua­li­té de la do­cu­men­ta­tion et du code source.

Ar­chi­tec­tures mul­ti­coeurs

D’une ma­nière gé­né­rale, on dis­tingue deux types de sys­tèmes mul­ti­coeurs. Si les pro­ces­seurs/coeurs sont tous iden­tiques, ils sont qua­li­fiés d’ho­mo­gènes. Si les pro­ces­seurs/coeurs ne pré­sentent pas tous la même ar­chi­tec­ture, ils sont consi­dé­rés comme hé­té­ro­gènes. Un sys­tème peut éga­le­ment être un hy­bride des deux types. Par ailleurs, on dé­nombre gé­né­ra­le­ment deux ar­chi­tec­tures lo­gi­cielles. Le mul­ti­trai­te­ment sy­mé­trique (SMP) dé­signe l’exé­cu­tion d’un seul OS sur plu­sieurs coeurs qui ré­par­tit le tra­vail entre ces der­niers. Le SMP ne peut être mis en oeuvre que sur un sys­tème multicoeur ho­mo­gène. Le mul­ti­trai­te­ment asy­mé­trique (AMP) at­tri­bue à chaque pro­ces­seur une ins­tance propre d’un OS. L’AMP peut être mis en oeuvre sur n’im­porte quelle confi­gu­ra­tion multicoeur. Un hy­bride, dans le­quel cer­taines par­ties du sys­tème forment un sous-sys­tème SMP et d’autres re­pré­sentent un AMP, est tout à fait pos­sible. Avec un sys­tème SMP, l’OS ré­par­tit le tra­vail entre les coeurs dis­po­nibles. Pour ce­la, une va­riante de l’OS spé­ci­fique est né­ces­saire. Tous les sys­tèmes d’ex­ploi­ta­tion haut de gamme dis­posent de cette op­tion, puis­qu’il s’agit d’une pra­tique cou­rante sur les sys­tèmes de bu­reau. Un nombre crois­sant de sys­tèmes d’ex­ploi­ta­tion temps réel in­clut une ver­sion SMP. De toute évi­dence, l’ef­fi­ca­ci­té avec la­quelle l’ar­chi­tec­ture multicoeur est uti­li­sée peut être un fac­teur clé de choix de l’OS. Le choix de l’OS pour chaque coeur d’un sys­tème AMP im­pose de suivre la même pro­cé­dure que lors de la sé­lec­tion d’un OS pour un sys­tème mo­no­coeur. Ce­pen­dant, reste éga­le­ment la ques­tion de la com­mu­ni­ca­tion entre coeurs, où l’uti­li­sa­tion de MCAPI peut être une so­lu­tion in­té­res­sante. Par ailleurs, un hy­per­vi­seur peut être uti­li­sé pour as­su­rer la su­per­vi­sion glo­bale d’un sys­tème AMP. Il im­porte de ré­flé­chir aux ou­tils. Pour tout dé­ve­lop­pe­ment de lo­gi­ciel em­bar­qué, dis­po­ser des ou­tils adé­quats s’avère es­sen­tiel. Dans le cas d’un pro­jet mul­ti-OS et multicoeur, le choix de l’ou­til le mieux adap­té de­vient absolument cru­cial. Pour ga­ran­tir la vi­si­bi­li­té com­plète sur le sys­tème, éva­luer ses per­for­mances et dé­bo­guer les in­ter­ac­tions com­plexes entre le code sur dif­fé­rents coeurs, l’uti­li­sa­tion d’ou­tils so­phis­ti­qués est né­ces­saire. La dis­po­ni­bi­li­té de ces ou­tils peut avoir une in­fluence ma­jeure sur le choix des sys­tèmes d’ex­ploi­ta­tion et le four­nis­seur que vous avez sé­lec­tion­né – on ci­te­ra par exemple Em­bed­ded Sour­ce­ry Ana­ly­zer de Men­tor pour les concep­tions mul­ti-OS et mul­ti­coeurs.

Co­lin Walls compte plus de vingt-cinq ans d’ex­pé­rience dans l’in­dus­trie élec­tro­nique, se consa­crant prin­ci­pa­le­ment aux lo­gi­ciels em­bar­qués. In­ter­ve­nant fré­quent dans des confé­rences et au­teur de deux ou­vrages sur les lo­gi­ciels em­bar­qués, M. Walls est membre du ser­vice mar­ke­ting de la di­vi­sion Sys­tèmes em­bar­qués de Men­tor.

≥ À l’ins­tar de Nu­cleus, un nombre crois­sant d’OS temps réel in­tègrent des mé­ca­nismes de ges­tion d’ali­men­ta­tion.

≥ Les concep­tions mul­ti- OS et mul­ti­coeurs né­ces­sitent des ou­tils lo­gi­ciels so­phis­ti­qués – ici l’ou­til Em­bed­ded Sour­ce­ry Ana­ly­zer de Men­tor.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.