Nou­velle édi­tion du livre « Lab­view Pro­gram­ma­tion et ap­pli­ca­tions »

Mesures - - Guide D’achat - Cé­dric Lar­dière

Coé­crite par 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­view Ar­chi­tecte, Lab­view Cham­pion et Tests­tand Dé­ve­lop­peur chez Me­su­log, Fran­cis Cot­tet, di­rec­teur de l’école na­tio­nale su­pé­rieure de mé­ca­nique et d’aé­ro­tech­nique (ENSMA) de Poi­tiers, et Mi­chel Pi­nard, en­sei­gnant à L’ESIEE et au CNAM, la 4e édi­tion de l’ou­vrage «Lab­view Pro­gram­ma­tion et ap­pli­ca­tions » (édi­tions Du­nod) s’en­ri­chit no­tam­ment d’un cha­pitre consa­cré à Lab­view NXG, la nou­velle gé­né­ra­tion de l’en­vi­ron­ne­ment de dé­ve­lop­pe­ment Lab­view. Les lec­teurs re­trou­ve­ront les cha­pitres consa­crés à l’ini­tia­tion à Lab­view, avec la des­crip­tion des élé­ments de base et la prise en main de l’édi­teur, à la pro­gram­ma­tion avan­cée, en dé­fi­nis­sant des tech­niques et ar­chi­tec­tures dans les règles de l’art – le code est main­te­nable, évo­lu­tif et per­for­mant –, ain­si qu’aux ca­pa­ci­tés spé­ci­fiques de Lab­view pour l’ac­qui­si­tion de don­nées, le pi­lo­tage d’ins­tru­ments de me­sure, le trai­te­ment du si­gnal, l’ana­lyse sta­tis­tique, la sau­ve­garde des don­nées et la gé­né­ra­tion de rap­port. Cet ou­vrage com­plet et pro­gres­sif s’adresse ain­si aus­si bien au dé­bu­tant qu’au dé­ve­lop­peur ex­pé­ri­men­té.

de­mandes liées au Big Da­ta. La com­plexi­té gran­dis­sante des équi­pe­ments s’ac­com­pagne de vo­lumes de don­nées gi­gan­tesques, qu’il faut ar­ri­ver à trai­ter. Re­po­sant sur un al­go­rithme is­su pour par­tie de Dia­dem,ana­ly­sis Ser­ver au­to­ma­tise les scripts de post­trai­te­ment pour ana­ly­ser plus de don­nées et la gé­né­ra­tion de rap­ports sur un ser­veur, ce qui per­met de stan­dar­di­ser ces opé­ra­tions pour les équipes. « Le pas­sage à des en­vi­ron­ne­ments ba­sés sur le Web fa­ci­lite gran­de­ment le tra­vail col­la­bo­ra­tif et l’ac­cès à un cloud. C’est aus­si une ma­nière de s’af­fran­chir des pro­blèmes liés à l’évo­lu­tion ra­pide des sys­tèmes d’ex­ploi­ta­tion », in­dique Neil Mar­tin (Key­sight Tech­no­lo­gies). Vic­tor Fer­nandes (Mar­vin Test So­lu­tions) confirme la mise en oeuvre d’ou­tils sup­plé­men­taires pour fa­ci­li­ter le dé­ve­lop­pe­ment, la va­li­da­tion et la si­mu­la­tion, ain­si que le dé­ploie­ment du tra­vail col­la­bo­ra­tif, à sa­voir plu­sieurs équipes ré­par­ties dans dif­fé­rents pays, mais iden­ti­fie d’autres évo­lu­tions : « les nou­velles orien­ta­tions sont la cy­ber­sé­cu­ri­té – le code gé­né­ré est pro­té­gé par dif­fé­rentes mé­thodes de cryp­tage, sur­tout au ni­veau de l’ap­pli­ca­tif client –, les de­mandes concer­nant la do­cu­men­ta­tion des pro­grammes de test, qui est in­dis­pen­sable pour les au­dits, ain­si que le sup­port à long terme et, donc, la ges­tion d’ob­so­les­cence. » Dans les do­maines mi­li­taires, nu­cléaires et du trans­port, il est fré­quent que les sys­tèmes de test et les bancs d’es­sais fonc­tionnent pen­dant 10 ou 15 ans, voire plus. Les in­gé­nieurs doivent se po­ser des ques­tions sur les ou­tils per­met­tant de ré­cu­pé­rer du code exis­tant, de le va­li­der et de l’in­té­grer dans un en­vi­ron­ne­ment plus ré­cent. Au risque si­non de se re­trou­ver, un jour ou l’autre, avec du ma­té­riel et/ou des ap­pli­ca­tifs ob­so­lètes.

Un mo­dèle éco­no­mique qui change

Il existe en­core d’autres ques­tions que les fu­turs ac­qué­reurs de lo­gi­ciels de test et de me­sure de­vraient se po­ser. « Le dri­ver est l’élé­ment in­dis­pen­sable, mais tous les dri­vers ne se valent pas, même entre deux ins­tru­ments aux fonc­tions iden­tiques. Cer­tains fa­bri­cants, comme Na­tio­nal Ins­tru­ments, sont connus pour la qua­li­té de leurs dri­vers, mais ce­la a un coût », ex­plique Luc Des­ruelle (Me­su­log). On en vient au nerf de la guerre. « La gra­tui­té est pos­sible pour de plus en plus de lo­gi­ciels qui, au­pa­ra­vant, étaient payants, tout en of­frant en­core plus de fonc­tions. Les ou­tils sont sou­vent la pro­lon­ga­tion de l’ins­tru­ment et leur coût est alors in­té­gré. Plus il est per­son­na­li­sé, ce qui est de plus en plus sou­vent le cas de par la com­plexi­té des tech­no­lo­gies, plus le coût d’un sys­tème aug­mente. Ce n’était pas le cas il y a des di­zaines d’an­nées », se rap­pelle Em­ma­nuel Ro­set (Na­tio­nal Ins­tru­ments France). Neil Mar­tin (Key­sight Tech­no­lo­gies), lui, constate que « le mo­dèle éco­no­mique des lo­gi­ciels change. Les clients pri­vi­lé­gient des so­lu­tions plus flexibles, telles que des li­cences flot­tantes, au dé­tri­ment de l’achat, à l’ins­tar du ma­té­riel.c’est un grand chan­ge­ment dans le monde du test et de la me­sure. » À l’ave­nir, la me­sure de­vien­dra par ailleurs de plus en plus liée à l’en­vi­ron­ne­ment, que ce soit une mac­hine, un avion ou un vé­hi­cule, d’où l’in­té­gra­tion ac­crue des ou­tils au sein de si­mu­la­tions ma­té­rielles uti­li­sant des sys­tèmes d’ex­ploi­ta­tion temps réel. « C’est dé­jà le cas avec les si­mu­la­tions HIL dé­ter­mi­nistes », in­dique Em­ma­nuel Ro­set (Na­tio­nal Ins­tru­ments France). « Et n’ou­blions pas l’in­tel­li­gence ar­ti­fi­cielle, qui va jouer un rôle pri­mor­dial dans le fu­tur », conclut Neil Mar­tin (Key­sight Tech­no­lo­gies).

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.