Les lo­gi­ciels pour le test et la me­sure

Mesures - - Front Page -

De­puis des dé­cen­nies, il existe des lo­gi­ciels as­so­ciés aux ins­tru­ments de me­sure, à l’ins­tar des fa­meux dri­vers. Mais le lo­gi­ciel prend au­jourd’hui une place tou­jours plus grande dans les so­lu­tions de test et de me­sure, au point par­fois d’éclip­ser le ma­té­riel. À cô­té des ou­tils as­so­ciés à chaque type d’ins­tru­ments de chaque fa­bri­cant, les uti­li­sa­teurs ont aus­si à leur dis­po­si­tion des lo­gi­ciels gé­né­riques ou­verts ou des ou­tils pro­prié­taires dé­ve­lop­pés par des tiers. Un tour d’ho­ri­zon s’im­pose pour mieux ap­pré­hen­der les avan­tages et in­con­vé­nients de cha­cun.

Dans le do­maine du test et de la me­sure élec­tro­niques, ou ce­lui de l’ac­qui­si­tion de don­nées, le ma­té­riel joue un rôle es­sen­tiel dans les per­for­mances et la qua­li­té des me­sures. Mais que se­raient les mul­ti­mètres, les os­cil­lo­scopes nu­mé­riques, les gé­né­ra­teurs de formes d’onde ar­bi­traires, les nu­mé­ri­seurs et autres ana­ly­seurs sans leur par­tie lo­gi­cielle. Ce­la semble évident pour la com­mu­ni­ca­tion des ap­pa­reils avec les fa­meux dri­vers et, en­core plus, pour les ap­pa­reils mo­du­laires, qui ne dis­posent pas d’in­ter­face uti­li­sa­teur. Mais les lo­gi­ciels in­ter­viennent au­jourd’hui à bien d’autres ni­veaux et dans bien d’autres tâches, telles que la pro­gram­ma­tion, la créa­tion de si­gnaux, le sé­quen­ce­ment de tests, l’ana­lyse de don­nées, voire le dé­ve­lop­pe­ment d’ap­pli­ca­tions avec un en­vi­ron­ne­ment de concep­tion. Au point même par­fois d’éclip­ser le ma­té­riel… En plus de ces dif­fé­rentes tâches, il existe éga­le­ment des ou­tils pro­prié­taires, des lo­gi­ciels gé­né­riques, des lo­gi­ciels pour l’ac­qui­si­tion de don­nées, etc. Pour es­sayer de s’y re­trou­ver dans cette foul­ti­tude de so­lu­tions lo­gi­cielles, nous al­lons par­tir de la ques­tion sui­vante: pour mettre en oeuvre des ins­tru­ments de me­sure, quelle so­lu­tion la mieux adap­tée un uti­li­sa­teur doit-il choi­sir par­mi l’offre dis­po­nible sur le mar­ché?

Trois ca­té­go­ries dif­fé­rentes de lo­gi­ciels

Avant d’al­ler plus loin, il se­rait in­té­res­sant de sa­voir ce que l’on en­tend par lo­gi­ciels gé­né­riques, pro­prié­taires, etc. « Je dis­tingue les ou­tils pro­prié­taires des lo­gi­ciels gé­né­riques plus ou­verts, comme ceux de Na­tio­nal Ins­tru­ments, les nôtres, etc. Les pre­miers per­mettent d’ex­ploi­ter les res­sources, les

fonc­tions as­so­ciées à un ma­té­riel don­né ; les se­conds doivent prendre en compte tout le ma­té­riel et le lo­gi­ciel qui existent sur le mar­ché », pré­cise Vic­tor Fer­nandes, res­pon­sable pour l’eu­rope de l’amé­ri­cain Mar­vin Test So­lu­tions. Pour Luc Des­ruelle, in­gé­nieur, ar­chi­tecte lo­gi­ciel et chef de pro­jet Test et Me­sure, cer­ti­fié Lab­vie­war­chi­tecte, Lab­view Cham­pion et Tests­tand Dé­ve­lop­peur chez le fran­çais Me­su­log, « il existe les ou­tils as­so­ciés aux ins­tru­ments de me­sure et dé­ve­lop­pés par les fa­bri­cants, les lo­gi­ciels gé­né­riques, ou plu­tôt les lo­gi­ciels d’édi­teurs, qui sont des so­lu­tions ou­vertes et prêtes à l’em­ploi (Dia­dem, Ex­cel, Tests­tand…), ain­si que les ou­tils pro­prié­taires dé­ve­lop­pés avec un en­vi­ron­ne­ment tel que Lab­view ». Les ou­tils des fa­bri­cants per­mettent de ne réa­li­ser que des étapes élé­men­taires, à l’ins­tar de l’ac­qui­si­tion de don­nées –il peut s’agir d’un pe­tit lo­gi­ciel ser­vant à tes­ter les fonc­tions de la res­source –, d’une ana­lyse, de la vi­sua­li­sa­tion des me­sures et/ou de l’édi­tion de rap­ports de test, par exemple. « Les ou­tils des fa­bri­cants dif­fèrent de ceux pour le test élec­tro­nique ou les bancs d’es­sais. Comme ce sont sou­vent de gros sys­tèmes com­po­sés de dif­fé­rents ins­tru­ments (mul­ti­plexeurs, mul­ti­mètre nu­mé­rique, etc.), nous sommes donc plus sur des so­lu­tions d’édi­teurs », pour­suit Luc Des­ruelle. De son cô­té, l’amé­ri­cain Na­tio­nal Ins­tru­ments, l’édi­teur du cé­lèbre en­vi­ron­ne­ment de concep­tion gra­phique Lab­view (et dé­sor­mais Lab­view NXG; voir Me­sures n° 907), pri­vi­lé­gie une autre seg­men­ta­tion. « Nous avons en ef­fet or­ga­ni­sé nos lo­gi­ciels prin­ci­pa­le­ment sur deux axes : l’un pour s’adap­ter au ni­veau de com­pé­tence des uti­li­sa­teurs et l’autre pour adap­ter nos lo­gi­ciels aux dif­fé­rentes étapes dans les pro­ces­sus de concep­tion, de­puis la R&D jus­qu’à la pro­duc­tion », ex­plique Em­ma­nuel Ro­set, in­gé­nieur mar­ke­ting Pro­duits d’ac­qui­si­tion de don­nées et Lab­view, spé­cia­liste en test temps réel chez Na­tio­nal Ins­tru­ments France.

Des ou­tils au-de­là de la me­sure

Ce­la se tra­duit donc, pour le ni­veau de com­pé­tence, par des lo­gi­ciels clé en main in­ter­ac­tifs, comme les faces-avant d’ins­tru­ments de me­sure ou le lo­gi­ciel en­re­gis­treur Flex­log­ger, puis par des lo­gi­ciels ba­sés confi­gu­ra­tion, ou lo­gi­ciels d’ap­pli­ca­tion, pour dé­fi­nir des tâches d’au­to­ma­ti­sa­tion (Dia­dem) ou pour une prise en main en ac­qui­si­tion de don­nées (Da­qex­press,tests­tand ou Ve­ris­tand), et en­fin dif­fé­rents ni­veaux d’en­vi­ron­ne­ments de pro­gram­ma­tion se­lon la per­son­na­li­sa­tion (Lab­view et Lab­view NXG). En ce qui concerne l’adap­ta­tion aux dif­fé­rentes étapes de concep­tion, on re­trouve no­tam­ment des lo­gi­ciels pour la mise au point et la dé­fi­ni­tion d’un sys­tème en R&D, les tests Hard­ware-in-theLoop (HIL; Ve­ris­tand), la va­li­da­tion et la pro­duc­tion, ou en­core l’ana­lyse lo­cale

ou dis­tri­buée. « Chaque lo­gi­ciel s’in­sère dans un éco­sys­tème com­plet et peut in­ter­agir de con­cert sur toutes les étapes en fonc­tion des com­pé­tences. Car le but est la réuti­li­sa­tion glo­bale des élé­ments par la stan­dar­di­sa­tion des for­mats », af­firme Em­ma­nuel Ro­set. De­puis quelque temps, cer­tains ac­teurs lancent des lo­gi­ciels qui couvrent des ap­pli­ca­tions au-de­là du test et de la me­sure pro­pre­ment dits. On peut par exemple ci­ter Sys­tem­link de Na­tio­nal Ins­tru­ments, qui est une sorte d’épine dor­sale pour la ges­tion des don­nées et des parcs d’ins­tru­ments à dis­tance ( voir Me­sures n° 907). La suite Pa­th­wave de l’amé­ri­cain Key­sight Tech­no­lo­gies fait par­tie de ce nou­veau type d’ou­tils. Cette pla­te­forme de dé­ve­lop­pe­ment ou­verte et flexible couvre un très large éven­tail d’ap­pli­ca­tions lo­gi­cielles, dont la concep­tion, le contrôle d’ins­tru­ments de me­sure, la vi­sua­li­sa­tion, la pro­duc­ti­vi­té. « Il s’agit d’un seul en­vi­ron­ne­ment pour tous les be­soins d’une en­tre­prise, et pas seule­ment en termes de test et de me­sure, puisque l’on trouve aus­si des liens vers des ou­tils de concep­tion, des lo­gi­ciels de test d’ixia, des ou­tils ana­ly­tiques ou de sur­veillance des ac­tifs. Au­pa­ra­vant, au sein d’une même en­tre­prise, dif­fé­rentes équipes pou­vaient uti­li­ser dif­fé­rents ou­tils pour la concep­tion, le test et la pro­duc­tion », ex­plique Neil Mar­tin, Di­rec­tor De­si­gn and Test Soft­ware Bu­si­ness de Key­sight­tech­no­lo­gies. D’où les éco­no­mies de temps ap­por­tées par une seule et unique pla­te­forme, en par­ti­cu­lier face à des de­si­gns et des si­gnaux plus com­plexes.

Avant tout, bien iden­ti­fier ses be­soins

Re­ve­nons à la ques­tion ini­tiale, à sa­voir la so­lu­tion la mieux adap­tée pour un uti­li­sa­teur sou­hai­tant mettre en oeuvre des ins­tru­ments de me­sure. Pour­vic­tor Fer­nandes (Mar­vin Test So­lu­tions), « la prin­ci­pale ques­tion est de sa­voir quel est le be­soin d’in­dus­triel : est-ce qu’il veut sim­ple­ment pi­lo­ter des ins­tru­ments de me­sure ? Doit-il réa­li­ser une ac­qui­si­tion de don­nées lente, ou ra­pide, une ac­qui­si­tion as­so­ciée à un sto­ckage des don­nées ? Doit-il mettre en oeuvre un test au­to­ma­tique, sé­quen­tiel ou pa­ral­lèle, en temps réel ? Ce n’est que dans un deuxième temps que l’on re­garde ce qui existe sur le mar­ché. » Ce que confirme d’ailleurs Luc Des­ruelle (Me­su­log) en pré­ci­sant que « bien

connaître les be­soins et les ob­jec­tifs per­met d’évi­ter une mau­vaise for­mu­la­tion et/ou une mé­con­nais­sance du client et, donc, de re­mettre en cause un pro­jet. Dif­fé­rentes so­lu­tions peuvent ré­pondre à un pro­jet don­né, mais ce se­ra un dé­tail qui fe­ra re­je­ter telle so­lu­tion et adop­ter telle autre. » Lorsque l’on choi­sit un lo­gi­ciel de test et de me­sure, il faut, en pre­mier lieu, s’as­su­rer que les fonc­tion­na­li­tés cor­res­pondent à son be­soin –ce qui pa­raît évident–, mais aus­si étu­dier le temps qui se­ra né­ces­saire à sa prise en main. « La fa­ci­li­té d’uti­li­sa­tion est la clé du suc­cès d’un ou­til de me­sure. Per­sonne ne veut d’un lo­gi­ciel trop com­pli­qué, avec des fonc­tions in­utiles, ou sur­char­gé et pas­ser du temps à re­cher­cher comment ex­traire une in­for­ma­tion. Dans ce cas, les uti­li­sa­teurs le laissent tom­ber.tout le monde sou­haite ob­te­nir le plus vite pos­sible les ré­sul­tats pour les ana­ly­ser afin d’amé­lio­rer son sys­tème », constate Em­ma­nuel Ro­set (Na­tio­nal Ins­tru­ments France). Du cô­té de Key­sight Tech­no­lo­gies, Neil Mar­tin men­tionne d’autres cri­tères pou­vant in­ter­ve­nir dans le choix d’un lo­gi­ciel: « pour cer­tains clients, il s’agit d’avoir une confiance sans faille dans la jus­tesse et la qua­li­té de leurs me­sures ; pour d’autres, c’est le sup­port qui est pri­mor­dial, par exemple avoir ac­cès à une ex­per­tise tech­nique, un sup­port dis­po­nible dans le monde en­tier ». Pour al­ler plus loin que ces pre­mières consi­dé­ra­tions, in­té­res­sons-nous main­te­nant aux avan­tages et in­con­vé­nients de chaque ca­té­go­rie de lo­gi­ciel. En ce qui concerne les lo­gi­ciels as­so­ciés aux ins­tru­ments des fa­bri­cants, les per­sonnes in­ter­viewées s’ac­cordent sur un point: « leur prin­ci­pal avan­tage est qu’ils sont très ra­pides pour ac­cé­der ponc­tuel­le­ment à une don­née four­nie par un ap­pa­reil, lors d’une mise en route par exemple », ré­sume Neil Mar­tin. « Si la so­lu­tion dis­pose de toutes les fonc­tions dé­si­rées, pour­quoi ne pas choi­sir des ou­tils des fa­bri­cants, car le client bé­né­fi­cie ain­si aus­si du sup­port », ajoute tou­te­fois Vic­tor Fer­nandes (Mar­vin Test So­lu­tions). Et c’est éga­le­ment une ma­nière pour les fa­bri­cants d’ins­tru­ments de me­sure de pro­mou­voir leur ma­té­riel.

Des lo­gi­ciels gé­né­riques ou­verts

Mais les in­con­vé­nients res­tent trop nom­breux. « Même s’ils ne sont pas chers du tout, voire même gra­tuits, ain­si que simples d’uti­li­sa­tion et donc prêts à l’em­ploi, les lo­gi­ciels des fa­bri­cants ne peuvent pi­lo­ter des ins­tru­ments que du fa­bri­cant, ni réa­li­ser une syn­chro­ni­sa­tion entre plu­sieurs ma­té­riels. Si l’uti­li­sa­teur doit ra­jou­ter des pe­tites fonc­tion­na­li­tés, ce­la de­vient vite moins fa­cile, et si l’on change le sys­tème d’ex­ploi­ta­tion du PC, le sys­tème n’est plus main­te­nable », énu­mère Luc Des­ruelle (Me­su­log). D’où le re­cours à des lo­gi­ciels gé­né­riques, bien sou­vent pour les sys­tèmes de test élec­tro­nique et les bancs d’es­sais, dans les­quels on re­trouve un éven­tail plus ou moins large de res­sources dif­fé­rentes. « En par­tant sur des ou­tils gé­né­riques, les clients bé­né­fi­cie­ront de leur sou­plesse, mais il fau­dra tou­te­fois bien dé­fi­nir en amont les be­soins, tels que la confor­mi­té à de nou­veaux stan­dards », confirme Vic­tor Fer­nandes (Mar­vin Test So­lu­tions). Il existe de plus en plus sou­vent des so­lu­tions ar­chi­tec­tu­rées au­tour d’un châs­sis au for­mat PXI et as­so­ciées à un ou­til gé­né­rique, l’en­semble étant op­ti­mi­sé

pour des fonc­tion­na­li­tés bien pré­cises. « Ces ou­tils pa­cka­gés offrent alors une ou­ver­ture mi­ni­male dans les bancs de test », pour­suit-il. Ce qui fait dire à Neil Mar­tin (Key­sight Tech­no­lo­gies) que « les lo­gi­ciels doivent être suf­fi­sam­ment ou­verts pour pou­voir s’in­ter­fa­cer avec les ou­tils de nom­breux ven­deurs et être com­pa­tibles avec le plus de sys­tèmes d’ex­ploi­ta­tion du mar­ché. » Et Em­ma­nuel Ro­set (Na­tio­nal Ins­tru­ments France) d’abon­der dans le même sens: « Les lo­gi­ciels gé­né­riques doivent pré­sen­ter une stan­dar­di­sa­tion d’échange avec les autres en­vi­ron­ne­ments ou ma­té­riels, sous peine d’être iso­lés et aban­don­nés à cause du manque de par­tage des in­for­ma­tions qu’ils col­lectent. » Le fa­bri­cant amé­ri­cain a d’ailleurs mis en place une pla­te­forme de par­tage d’ap­pli­ca­tion, Lab­view Tools Net­work, qui per­met aux in­gé­nieurs et aux scien­ti­fiques de créer et par­ta­ger des codes et des ap­pli­ca­tions (lo­gi­ciels com­plé­men­taires ou clé en main, payants ou gra­tuits). Là en­core, la ques­tion de sa­voir s’il est pos­sible d’ajou­ter fa­ci­le­ment des fonc­tion­na­li­tés sup­plé­men­taires ul­té­rieu­re­ment est à se po­ser. « Si les lo­gi­ciels d’édi­teurs [lo­gi­ciels gé­né­riques] ré­pondent au be­soin du client, il faut les choi­sir – des API per­mettent par exemple d’ajou­ter du code ex­té­rieur (code mo­dule ou écrit dans un autre lan­gage) –, car ils res­tent moins chers que les ou­tils pro­prié­taires, jus­qu’à une cer­taine com­plexi­té », ex­plique Luc Des­ruelle (Me­su­log). Les ou­tils pro­prié­taires, à sa­voir dé­ve­lop­pés sur ca­hier des charges par un tiers, af­fichent des avan­tages in­dé­niables, à com­men­cer par être per­son­na­li­sés se­lon les exi­gences du client (cou­leur, bou­tons, syn­chro­ni­sa­tion), évo­lu­tifs et main­te­nables, ce qui se tra­duit par un gain de temps en ex­ploi­ta- tion. « C’est le lo­gi­ciel qui prend la com­plexi­té des tâches de l’en­chaî­ne­ment, et non l’opé­ra­teur. Avec un lo­gi­ciel sur éta­gère, la for­ma­tion du per­son­nel est plus im­por­tante », pour­suit-il. Les points dé­li­cats des ou­tils pro­prié­taires portent sur leur dé­ve­lop­pe­ment: le temps de mise en place est plus long et le coût, plus im­por­tant qu’avec des ou­tils d’édi­teurs, et il faut que l’in­dus­triel dé­cide s’il fait le dé­ve­lop­pe­ment en in­terne ou en ex­terne. « Il est par­fois dif­fi­cile pour une en­tre­prise de dis­po­ser des com­pé­tences né­ces­saires en test et en me­sure et d’avoir la vi­sion de sa ca­pa­ci­té de dé­ve­lop­pe­ment. Il ne faut alors pas hé­si­ter à s’en­tou­rer de per­son­nels spé­cia­li­sés cer­ti­fiés Lab­view, ce qui ap­porte aus­si des avan­tages en termes de pé­ren­ni­té », in­siste Luc Des­ruelle.

Pro­duc­ti­vi­té et ges­tion d’ob­so­les­cence

À l’ins­tar des autres seg­ments de mar­ché, les ac­teurs dans le do­maine des lo­gi­ciels pour le test et la me­sure font évo­luer leurs so­lu­tions, en­core plus que pour le ma­té­riel d’ailleurs, pour an­ti­ci­per les évo­lu­tions du mar­ché. « Les sys­tèmes sous test de­ve­nant de plus en plus com­plexes et né­ces­si­tant des com­pé­tences tou­jours plus poin­tues, la ten­dance ac­tuelle est de créer des ou­tils sim­pli­fiés re­grou­pant tou­jours plus de fonc­tion­na­li­tés et de mu­tua­li­ser les com­pé­tences en groupe d’uti­li­sa­teurs ou par par­te­na­riats de dé­ve­lop­peurs, dont cha­cun à une spé­cia­li­té pour ré­soudre les dé­fis de me­sure. Le mot-clé est donc la pro­duc­ti­vi­té », constate Em­ma­nuel Ro­set (Na­tio­nal Ins­tru­ments France). En plus de tra­vailler sur des in­ter­faces contri­buant à ac­cé­der plus vite aux ré­sul­tats, l’amé­ri­cain pro­pose éga­le­ment Sys­tem­link ( voir pré­cé­dem­ment) et Ana­ly­sis Ser­ver, pour ré­pondre aux

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.