SYSTMESTEMPS RELDE CONTRLE-COMMANDEConception et implmentation Francis CottetEmmanuel Grolleau SRIE | EEAISBN 2 10 007893 3Cet ouvrage prsente une mthodologie complte et oprationnellede dveloppement des systmes temps rel de contrle-commande.Il permet au lecteur de : connatre et mettre en uvre les mthodes de spcification et deconception ; dfinir et paramtrer lenvironnement dexcution des systmes ; raliser limplmentation multitche base sur un noyau tempsrel ; dvelopper lapplication en C, Ada ou LabVIEW.Louvrage fait galement le point sur les dernires avances dans ledomaine des systmes temps rel multitches. De nombreux exemplesindustriels sont traits, permettant de comprendre puis de mettre enuvre les principes de cette mthodologie de dveloppement.Ce livre sadresse tous les ingnieurs ou techniciens concepteursdapplications temps rel de contrle-commande de procdsindustriels. Il est galement destin aux tudiants en informatiqueindustrielle.TECHNIQUE ET INGNIERIESrie EEAFrancis Cottet Emmanuel GrolleauF. COTTETE. GROLLEAUSYSTMES TEMPS REL DE CONTRLE-COMMANDESYSTMES TEMPS REL DECONTRLE-COMMANDE Conception et implmentation FRANCIS COTTETest professeur lENSMA(cole NationaleSuprieure de Mcaniqueet dArotechnique).EMMANUEL GROLLEAUest matre de confrences lENSMA.Tous deux sont chercheurs au Laboratoiredinformatiquescientifique et industrielle(LISI), dans lquipe Systme temps rel ,coordonne par FrancisCottet lui-mme.www.dunod.comGESTION INDUSTRIELLECONCEPTIONFROID ET GNIE CLIMATIQUEMCANIQUE ET MATRIAUX CHIMIEENVIRONNEMENT ET SCURITEEA Francis CottetEmmanuel Grolleau S YSTMES TEMPS RELDE CONTRLE-COMMANDE Conception et implmentation cottet_prelimsPage IMardi, 1. mars 20052:33 14 D U MME AUTEUR : F RANCIS C OTTET LabVIEW Programmation et applications, Dunod, 2001 Dunod, Paris, 2005ISBN2 10 007893 3 cottet_prelimsPage IIMardi, 1. mars 20052:33 14III Dunod La photocopie non autorise est un dlit. TABLE DES MATIRES Avant-ProposV1 Dveloppement des systmes de contrle-commande1 1.1 Introduction 1 1.2 Architecture des applications de contrle-commande 7 1.3 Dveloppement des applications de contrle-commande 18 2 Spcification selon la mthode SA-RT27 2.1 Introduction gnrale la mthode SA-RT 27 2.2 Prsentation de la syntaxe graphique de la mthode SA-RT 30 2.3 Les diagrammes flot de donnes 36 2.4 Laspect contrle de la mthode SA-RT 41 2.5 Spcification des processus primitifs 49 2.6 Spcification des donnes 51 2.7 Organisation gnrale de la mthode SA-RT 54 2.8 Exemples 56 2.9 Extensions de la mthode SA-RT 70 3 Conception selon la mthode DARTS81 3.1 Introduction 81 3.2 Prsentation de la mthode DARTS 85 3.3 Exemples de conception avec la mthode DARTS 102 4 Architectures systmes109 4.1 Architecture matrielle 109 4.2 Architecture logicielle 138 4.3 Rseaux et bus de terrain 160 5 Excutifs temps rel181 5.1 Introduction 181 5.2 Concepts des excutifs temps rel 184 5.3 Principales normes temps rel 209 5.4 Exemples dexcutifs temps rel 230IV 6 Programmation des systmes multitches245 6.1 Programmation C, Ada et LabVIEW 245 6.2 Programmation multitche en langage C 285 6.3 Programmation multitche en langage Ada 314 6.4 Programmation multitche en langage LabVIEW 331 7 Traitement complet dune application industrielle341 7.1 Cahier des charges 341 7.2 Spcification 342 7.3 Conception 350 7.4 Implmentation sur simulateur 354 7.5 Spcification et conception adaptes 388 7.6 Implmentation de la commande relle 394 7.7 Conclusion 405 8 tude avance des systmes temps rel407 8.1 Introduction 407 8.2 Modlisation des tches 409 8.3 Ordonnancement des tches indpendantes priodiques 431 8.4 Ordonnancement des tches indpendantes apriodiques 447 8.5 Ordonnancement des tches priodiques dpendantes 463 8.6 Analyse dordonnanabilit en environnement monoprocesseur 481 8.7 Ordonnancement en environnement multiprocesseur 491 Annexes A Reprsentation de linformation 513B Standards POSIX 519C Module de botes aux lettres POSIX 523D Module de communication Ada 533Bibliographie539Lexique anglais franais541Sigles546Index551V Dunod La photocopie non autorise est un dlit. AVANT-PROPOS Les applications informatiques dites de contrle-commande ont envahi lenviron-nement industriel et notre vie quotidienne. Depuis quelques dcennies, les besoinsde plus en plus accrus en termes de technicit ont conduit intgrer une trs forteautomatisationdanstouslesproduitsindustrielsoudestinslusage grandpublic . La liste inniment longue des exemples contient des produits aussi diversquun tlphone mobile, un vhicule automobile, un four micro-onde, une consolede jeu, un satellite dexploration, etc. Le dnominateur commun toutes ces appli-cations est la fourniture de fonctionnalits toujours plus sophistiques : interfacehomme-machine(crancouleurdehautednition,crantactile,commandevocale), nombre lev de fonctions dbordant largement lutilisation de base duproduit (visualisation des commandes, liaison Internet), sret de fonctionnement(robustesse, tolrance aux fautes, rpartition, maintenance rapide et aise).Pour ces raisons, les trois grands domaines permettant ces dveloppements : llec-tronique, lautomatique et linformatique, ont d progresser et sadapter. lectronique : processeur multifonctions (microcontrleur), processeur faibleconsommation, ralisation de circuits lectroniques ddis (FPGA, FPLA), etc. Automatique : lois de rgulations adaptes, rgulation numrique, etc. Informatique : mthodes et mthodologies de dveloppement, systmes dexploi-tationouexcutifsembarqus,langagesapplicatifs,mthodesdetestsetdevalidations, etc.Lesdomainesdellectroniqueetdelautomatiquenesontpasleproposdecetouvrage. Toutefois, tant donn le dveloppement li entre les deux parties matrieletlogiciel ,uneprsentationsuccinctedumatrielestfaite.Enrevanche,nousallons nous intresser particulirement laspect informatique ou plus exactement laspect gnie logiciel, cest--dire la ou les mthodes permettant de dveloppercorrectement ces applications. La signication du terme correctement est pr-cise dans le chapitre suivant, mais nous pouvons dj annoncer que ces applicationsdoivent tre dveloppes avec un grand souci de rigueur tant donn que leurs uti-lisations peuvent avoir un impact nancier important, un effet nuisible sur lenvi-ronnement, ou plus gravement, mettre en jeu des vies humaines. Aussi la mtho-dologiededveloppementdesapplicationsdecontrle-commandedoitassurerunequalitderalisationentermesdeabilit,defcacit,demaintenabilit,dvolutivit, etc.Il est important de noter quil nest pas possible de parler des applications de contrle-commandecommeunensemblehomogneausensdeleurralisation.Eneffet,VI entrelesdveloppementsdelapplicationinformatiquegrantunfourmicro-ondeetcellepilotantunenavettespatiale,ladistanceestimmense :criticitdelapplication, taille du logiciel, volution de lapplication Le seul lien en communestquetoutescesapplicationsmettentenrelationunprogrammeinformatiqueavec un procd externe.Dautre part, le dveloppement des applications de petite taille ou de taille moyenneasouventtconduitpardesprofessionnelsdumondedelautomatiqueoudellectronique. Les rgulations de type lectromcanique ou lectronique analogiqueont rapidement fait place des systmes purement numriques ; seuls les capteurset les actionneurs, faisant le lien vers le monde rel, sont toujours analogiques. Lesconcepteurs de ces applications ont des mthodes bases sur laspect fonctionnel :schmasblocs,grafcets,etc.Eneffet,laspcicationetlaconceptiondetellesapplications sont plus aises lorsquelles sont penses en termes de fonctions ou detraitementsdesdonnes.Aussileslangagesddiscetypedapplicationssonttoutnaturellementdeslangagesfonctionnelsexcutionsquentiellecommelelangage C, les assembleurs ou le langage ot de donnes LabVIEW.Dans le domaine informatique, en parallle, ces applications ont conduit la miseen place de mthodes de spcication ou de conception rpondant ces besoins,cest--diredesmthodesbasessurladescriptiondelaspectfonctionnel,soitlanalysestructure(SA),lanalysestructuretempsrel(SA-RT),laconceptionstructure(SD),etc.Cesmthodescorrespondentparfaitementcesbesoinscondition que les applications ne deviennent pas de grande taille et nimpliquentdes nombreuses donnes complexes (donnes structures). Dautre part, il est impor-tant de noter que ces mthodes ont une drivation trs directe vers une implmen-tation multitche qui permet de rpondre la fois la logique du paralllisme dumonde rel en termes de conception et aux contraintes temporelles exiges.Encequiconcernelesapplicationsinformatiquesditesclassiques(applicationsbureautiques,basesdedonnes),desmthodesbasessurlesdonnesonttlabores an de rpondre un besoin fort de modlisation des donnes et de leursvolutions. Ces mthodes, dites orientes objets, permettent une spcication et uneconception des applications en pensant avant tout en termes de donnes et dactionssur ces donnes, mais en ngligeant dans les premires tapes laspect fonctionnel,cest--dire lenchanement, le squencement ou lexcution des diffrentes partiesde lapplication. Ces mthodes orientes objets, unies sous le nom UML ( UniedModelingLanguage ),sontdevenuesincontournablespourledveloppementdesapplications informatiques.Actuellement, ces mthodes orientes objets sont de plus en plus utilises dans ledomainedesapplicationsdecontrle-commande,domainenonconcerninitia-lement par ce type de modlisation objet. Il est concevable et acceptable de suivre unetelledmarchepourdesapplicationsinformatiques,mmedecontrle-commande,degrandetaillepossdantsouventdesdonnesconsquentesdetypecomplexe.Mais il ne semble pas naturel de vouloir imposer ce type doutils pour des applica-tionsdecontrledeprocdsdepetiteoumoyennetailleayantdesdonnesennombre rduit et de type simple. Dautant plus que, comme nous lavons not pr-cdemment, les utilisateurs de ces outils ont une culture de conception de type fonc-tionnel qui a une trs grande efcacit. Ensuite les mthodes orientes objets vontVII Dunod La photocopie non autorise est un dlit. conduiredesdifcultspourpasserltapedelimplmentationmultitche ;cetterupturedelachanededveloppementdiminuefortementlintrtdecesmthodes de spcication et de conception.Cet ouvrage a donc pris le parti de prsenter une mthodologie complte de dvelop-pement dapplications de contrle-commande bas sur un aspect fonctionnel condui-sant naturellement vers une implmentation multitche. Sans rejeter les mthodesorientesobjetslargementrpanduesaujourdhui,ilsemblecontraireauxrglesdu gnie logiciel dutiliser une mthodologie non cohrente avec le domaine desapplications cibles, non cohrente la fois en termes de logique danalyse de bouten bout et dobjectifs applicatifs. Notre mthodologie, base sur une approchefonctionnelle au niveau de lanalyse et une approche multitche au niveau dela conception, sadapte parfaitement aux applications de contrle-commandede petite taille ou de taille moyenne mettant en jeu des donnes simples. Le premier chapitre prsente lenvironnement de dveloppement des systmes decontrle-commande en dcrivant la spcicit de ces applications en termes darchi-tectures logicielles et matrielles. Le second chapitre traite de la mthode de spci-cation fonctionnelle choisie SA-RT ( Structured Analysis for Real Time systems ). Lamthode de conception DARTS ( Design Approach for Real-Time Systems ) qui est lasuite logique de SA-RT est dcrite dans le chapitre 3. Les environnements matrielset logiciels (excutifs temps rel) trs particuliers de ces applications sont prsentsdans les chapitres 4 et 5 an de mieux comprendre la partie implmentation de cessystmesdecontrle-commande.Lechapitre 6estddilimplmentationdesapplications de contrle-commande en dclinant trois environnements : noyau tempsrel et langage de type langage C, langage Ada et enn un environnement spciquebas sur LabVIEW. Les prcdents chapitres sont illustrs par des exemples simplesmais ralistes ; en revanche, le chapitre 7 propose le dveloppement complet duneapplication relle industrielle. Enn, le chapitre 8 ouvre le dveloppement de cesapplications vers des aspects avancs concernant lordonnancement. Tlchargement sur Internet Vous trouverez en tlchargement sur le site www.dunod.com les codes sources detous les programmes prsents dans cette ouvrage.1 Dunod La photocopie non autorise est un dlit. 1 DVELOPPEMENT DES SYSTMESDE CONTRLE-COMMANDE 1.1 Introduction 1.1.1 Dfinitions Nous pouvons dnir un systme de contrle-commande comme un systme infor-matique en relation avec lenvironnement physique rel externe par lintermdiairede capteurs et/ou dactionneurs, contrairement aux systmes dinformatiques scien-tiques(gestiondebasededonnes,CAO,bureautique)quiontdesentresconstitues de donnes fournies par des chiers ou ventuellement un oprateur.Lesgrandeursphysiquesacquisespermettentausystmedecontrle-commandede piloter un procd physique quelconque. Donnons ainsi une dnition gnraledun systme de contrle-commande (gure 1.1) : Un systme de contrle-commande reoit des informations sur ltat duprocd externe, traite ces donnes et, en fonction du rsultat, value unedcisionquiagitsurcetenvironnementextrieurandassurerun tatstable .Cette notion dtat stable peut tre diffrente selon les applications ou procds.Il dpendducahierdeschargesdelapplication(maintiendunetempraturedeconsigne, rgime moteur, qualit de service). Deux caractristiques font quunsystme de contrle-commande ne possde pas les proprits classiques des systmesdinformatiques scientiques : indpendance du rsultat produit par rapport la vitesse dexcution. Le rsultatdun calcul effectu partir de donnes dentre similaires est indpendant de lavitesse du calculateur. En revanche, ltat stable dun procd dpend de la dyna-mique du procd par rapport la vitesse dexcution du systme de contrle-commande ; comportementreproductible.Uncalculeffectupartirdedonnesdentreidentiques donne toujours le mme rsultat. En revanche, dans le cas de donnesdentre (grandeurs physiques) obtenues par des capteurs, le systme de contrle-commandetravaillesurundomainededonnesrellesapproximesquisonttrs rarement identiques.2 1.1Introduction 1 Dveloppement dessystmes de contrle-commande Linteraction du systme de contrle-commande avec le procd extrieur piloterse dcompose en deux parties (gure 1.2) : observationsparlintermdiairedecapteurs( sensors )quipermettentdobtenirdes informations sous la forme des interruptions (information tout ou rien) oudes mesures (information continue) en provenance du procd physique ; actions ralises par lintermdiaire dactionneurs ( actuators ) qui permettent dagirsur le procd physique sous la forme de commandes (modication dtat phy-sique du systme) ou simplement sous la forme dun afchage (diodes, lampes,afcheurs, crans, etc.).Cette dnition des systmes de contrle-commande ayant t faite, nous pouvonsreplacer ces systmes par rapport aux autres systmes informatiques en faisant troiscatgories : les systmes transformationnels qui utilisent des donnes fournies linitiali-sation par lutilisateur. Ces donnes, leurs traitements et lobtention du rsultatnont aucune contrainte de temps ; les systmesinteractifs danslesensolesdonnessontproduitesparinter-actionaveclenvironnementsousdiffrentesformes(clavier,chier,rseaux,souris,etc.).Maisletempsnintervientpasentantquetelsicenestavecunaspect confort de travail ou qualit de service ; les systmes de contrle-commande ou ractifs qui sont aussi en relation aveclenvironnementphysiquerelpourlesdonnesenentre ;mais,danscecas,Systmede contrle-commandeProcdexterneSystmeinformatiqueEntresSortiesFigure 1.1 Reprsentation schmatique dun systme de contrle-commande.Procd externe pilotercapteurSystme informatiquede contrle-commandecapteurcapteuractionneurMesuresInterruptionsCommandesAffichagesFigure 1.2 Reprsentation schmatique de linteraction du procd physique pilot et du systme de contrle-commande.1.1Introduction 3 Dunod La photocopie non autorise est un dlit. 1 Dveloppement dessystmes de contrle-commande laspect temps a une place importante sous la forme dun temps de raction,dune chance respecter, etc.Nous terminons cette section par des dnitions qualiant des systmes de contrle-commandeayantdesspcicationsparticulires.Lapremiredecescatgoriesconcerne les systmes temps rel ( real-time system ) dont la dnition est : un sys-tme de contrle-commande dans lequel lexactitude des applications ne dpendpas seulement du rsultat mais aussi du temps auquel ce rsultat est produit. Si les contraintes temporelles de lapplication ne sont pas respectes, on parle de dfail-lance du systme . Ces contraintes temporelles peuvent tre de deux types : contraintestemporellesrelatives oulches(tempsrelmou : softreal-time ) :les fautes temporelles sont tolrables (ex. : jeux vido, applications multimdia,tlphonie mobile) ; contraintes temporelles strictes ou dures (temps rel dur : hard real-time ) : lesfautestemporellesnesontpastolrables(ex. :avionique,vhiculesspatiaux,automobile, transport ferroviaire).Dans le cas des systmes temps rel contraintes temporelles relatives, nous pouvonsparler de systmes de contrle-commande classiques.Nous pouvons aussi trouver les qualicatifs suivants : systmedecontrle-commande embarqu ( embeddedreal-timesystem ) :pasdintervention humaine directe (pas de modication du programme ou des para-mtres du programme) ; systme de contrle-commande ddi ( dedicated real-time system ) : les architec-tures matrielles ou logicielles sont spciques lapplication (noyau, processeur) ;Donnes produites par lenvironnementPas de contraintes de tempsSynchronisationsou communicationsAspect relationentre entitsdu programme Aspect temporel AspectcomportementalDonnes produites par lenvironnementContraintes de tempsProprits temporellesAspecttransformationnelSystmesinteractifs(ex. : bureautique, CAO)Systmes ractifsou de contrle-commandeSystmestransformationnels(ex. : code de calcul)Donnes linitialisationPas de contraintes de tempsAlgorithmiqueFigure 1.3 Comparaison des systmes de contrle-commande par rapport aux autres applications informatiques.4 1.1Introduction 1 Dveloppement dessystmes de contrle-commande systmedecontrle-commande rpartioudistribu ( distributedreal-timesystem ) :larchitecturematrielleestconstituedeplusieursprocesseursrelisentre eux par un bus ou un rseau.Il est vident que ces diffrentes spcications dun systme de contrle-commandepeuventsecombinercommeparexempleunsystmedecontrle-commandeddi, distribu et contraintes temporelles strictes (application pour un vhiculeautomobile). 1.1.2 Principales caractristiques des systmes de contrle-commande Considronsunexemplereprsentatifduneapplicationdecontrle-commandereprsent sur la gure 1.4. Cet exemple de contrle-commande dun moteur com-bustion est repris de faon dtaille dans le chapitre suivant. Le contrle-commandede cette application est fait par lintermdiaire dun ensemble de capteurs et daction-neurs (pdale dacclrateur, temprature air, pression air, temprature eau, rotationvilebrequin, capteurs de pollution, injection essence, allumage, admission air, etc.)et dune connexion au rseau interne lautomobile. Lanalyse de cet exemple dappli-cation permet de mettre en exergue les principales caractristiques des systmes decontrle-commande : grande diversit des dispositifs dentres/sorties : les donnes acqurir quisont fournies par les capteurs et les donnes fournir aux actionneurs sont de typestrs varis (continu, discret, tout ou rien ou analogique). Il est aussi ncessairede piloter un bus de terrain pour les communications ;Capteurpdale acclrateurCapteur temprature eauCommandeallumageCapteurtemprature airCommandeinjecteur essenceCapteur vitesse de rotationdu vilebrequin Capteurpollution en aval Capteurpollution en amontCommunicationsavec les autrescalculateursCommande de r-injectiongaz chappementCapteurpression collecteurairCalculateurCommande admission air(papillon)BusCANFigure 1.4 Exemple dune application de contrle-commande dun moteur combustion.1.1Introduction 5 Dunod La photocopie non autorise est un dlit. 1 Dveloppement dessystmes de contrle-commande prise en compte des comportements concurrents : lensemble de ces donnsphysiques qui arrivent de lextrieur et le rseau qui permet de recevoir des mes-sages ne sont pas synchroniss au niveau de leurs volutions, par consquent, lesystme informatique doit tre capable daccepter ces variations simultanes desparamtres ; respect des contraintes temporelles : la caractristique prcdente impose delapartdusystmeinformatiquedavoiruneractivitsufsantepourprendreen compte tous ces comportements concurrents et en rponse ceux-ci, de faireune commande en respectant un dlai compatible avec la dynamique du systme ; sret de fonctionnement : les systmes de type contrle-commande mettentsouvent en jeu des applications qui demandent un niveau important de scuritpour raisons de cot ou de vies humaines. Pour rpondre cette demande, il estncessaire de mettre en uvre toutes les rponses de la sret de fonctionnement(dveloppementssrs,tests,mthodesformelles,prvisibilit,dterminisme,continuit de service, tolrance aux fautes, redondance, etc.). 1.1.3 Caractristique temporelle des systmes de contrle-commande Lerespectdescontraintestemporellesduneapplicationdecontrle-commandedpend essentiellement de la dynamique du procd. Cette caractristique temporellepeut tre trs diffrente suivant lapplication (gure 1.5) : Milliseconde : systmes radar, systmes vocaux, systmes de mesures Seconde : systmes de visualisation, robotique Minute : chane de fabrication Heure : contrle de ractions chimiquesCe paramtre temporel correspond lordre de grandeur de la capacit de rponseou de traitement du systme de contrle-commande.ApplicationTempsSystmesradarSystmesmesuresscientifiques100 ns1 s1 ms1 seconde1 minute1 heure10 msContrleen chimieContrlefabricationContrlestockageSystmesvocauxRobotiqueFigure 1.5 Comparaison de la dynamique de diffrentes applications de contrle-commande.6 1.1Introduction 1 Dveloppement dessystmes de contrle-commande Mais, comme nous le verrons dans le chapitre 8, il est ncessaire de prciser et deformaliser cette caractristique temporelle qui peut prendre de nombreuses formu-lations. Ainsi, nous pouvons dnir de manire non exhaustive : Dure dexcution duneactivit :lactivitduneapplication,quipeuttrelenchanement de plusieurs activits lmentaires (acquisition, traitement, com-mande, afchage),possdeuneduredexcutionquipeuttremesuredediverses manires. Cette dure nest pas constante chaque occurrence de cetteactivit puisque les programmes et les enchanements de programmes ne sont pastoujours identiques (branchement conditionnel, itration, synchronisation). Cadence de rptition ou priodicit dune activit : lacquisition dune donneou la commande dun actionneur peuvent ncessiter une rgularit lie par exemple la frquence dchantillonnage. Date au plus tt ou date de rveil : dans certains cas, un traitement doit tredclench une date prcise relative par rapport au dbut de lexcution de lappli-cation ou absolue (plus rarement). Cette date de rveil nimplique pas obligatoi-rement lexcution ; il peut y avoir un dlai de latence d lindisponibilit duprocesseur. Date dactivation : cet instant correspond lexcution effective de lactivit. Date au plus tard ou chance : le traitement ou la commande dun actionneurdoivent tre termins un instant x par rapport au dbut de lexcution delapplication. Dans le cas dapplications contraintes temporelles strictes, cettechance doit tre respecte de faon imprative, sinon il y a faute temporelle etlapplication est dclare non valide. Temps de rponse : cette caractristique peut sappliquer une activit de rgu-lation ou un ensemble dactivits de rgulation ; elle est directement lie ladynamique du systme. Ce paramtre correspond la diffrence entre la date derveil et la date de n de lactivit. Gigue temporelle : ce paramtre caractrise la rptabilit dune activit au furetmesuredesesoccurrences.Eneffet,entredeuxexcutionssuccessivesdunemme activit, ses caractristiques temporelles peuvent changer : date dactivation,dure dexcution, temps de rponse, etc. 1.1.4 Quelques exemples dapplications Nous pouvons citer quelques exemples dapplications de contrle-commande : Robotdeproduction :unrobot,ralisantuneactivitspcique(peinture,assemblage, tri) sur une chane de production, doit effectuer son travail en destemps xs par la cadence de fabrication. Sil agit trop tt ou trop tard, lobjetmanufacturier trait sera dtruit ou endommag conduisant des consquencesnancires ou humaines graves (oubli dun ou plusieurs rivets sur un avion). Robotdexploration :cerobotdoitsedplacerdansunenvironnementenprincipe non connu (zone radioactive aprs un accident, plante, pave sous lamer). Il est important quil puisse ragir aux obstacles xes ou mobiles an dene pas conduire sa perte.1.2Architecture des applicationsde contrle-commande 7 Dunod La photocopie non autorise est un dlit. 1 Dveloppement dessystmes de contrle-commande Tlphonemobile :lesystmedecontrle-commandedoitremplirplusieursfonctions dont certaines ont des contraintes temporelles fortes pour avoir unebonne qualit de service (QoS : Quality of Service ). Ainsi, la premire fonctionest de transmettre et de recevoir les signaux de la parole (577 s de parole misestoutes les 4,6 ms et 577 s de parole reues toutes les 4,6 ms des instants dif-frents). En parallle, il est ncessaire de localiser en permanence le relais le plusproche et donc de synchroniser les envois par rapport cette distance (plus tt sila distance augmente et plus tard si la distance diminue). Des messages de comptesrendus de la communication sont aussi mis avec une priodicit de plusieurssecondes. Les contraintes temporelles imposes au systme doivent tre imper-ceptibles lutilisateur. Systmedevidoconfrence :ce systme doit permettre lmission et la rcep-tion dimages numrises une cadence de 20 25 images par seconde pour avoirune bonne qualit de service. An de minimiser le dbit du rseau, une com-pression des images est effectue. Dautre part la parole doit aussi tre transmise.Bienquecorrespondantundbitdinformationmoindre,largularitdelatransmission, qualie par une gigue temporelle, est ncessaire pour une repro-duction correcte. De plus ce signal doit tre synchronis avec le ux dimages.Lensembledecestraitements(numrisationsimagesetparole,transmission,rception, synchronisation) sont raliss en cascade, mais avec une cohrenceprcise. Pilotage dun procd de fabrication (fonderie, laminoir, four verrier) : parexemplelafabricationdunebobinedaluminium(laminagefroid)exigeuncontrle en temps rel de la qualit (paisseur et planit). Cette vrication enproductiondelaplanitncessiteuneanalysefrquentielle(FFT)quiinduitun cot important de traitement. Le systme doit donc raliser lacquisition dungrand nombre de mesures (246 Ko/s) et traiter ces donnes (moyenne, FFT) la priode de 4 ms. Ensuite, il afche un compte rendu sur lcran de loprateurtoutes les 200 ms et enn imprime ces rsultats dtaills toutes les 2 s. Un fonc-tionnement non correct de ce systme de contrle de la qualit peut avoir desconsquences nancires importantes : production non conforme la spcicationdemande. 1.2 Architecture des applications de contrle-commande 1.2.1 Architecture logicielle des applications de contrle-commande m Architecture multitche Le comportement concurrent des vnements et grandeurs physiques externes amnedcrirelenvironnementcommeunsystmefortementparallle.Celaconduitnaturellement adapter les mthodes de conception et de ralisation du systme decontrle-commande dun tel environnement ce paralllisme. Aussi, larchitecturela mieux adapte pour rpondre ce comportement parallle du procd externe8 1.2Architecture des applicationsde contrle-commande 1 Dveloppement dessystmes de contrle-commande estune architecturemultitche .Ainsi,auparalllismedelenvironnement,larponse est le paralllisme de conception. Nous pouvons dnir la tche ou activitou processus comme une entit dexcution et de structuration de lapplication .Cette architecture logicielle multitche facilite la conception et la mise en uvre etsurtout augmente lvolutivit de lapplication ralise.Dunemaniretrsgnrique,lagure 1.6donnelarchitecturelogicielleduneapplication de contrle-commande multitche. Nous pouvons ainsi dcouper cetensemble de tches ou activits selon les groupes suivants : Tches dentres/sorties : ces tches permettent daccder aux donnes externespar lintermdiaire de cartes dentres/sorties et ensuite de capteurs et daction-neurs directement lis au procd gr. Ces tches peuvent tre actives de faonrgulire ou par interruption. Tches de traitement : ces tches constituent le cur de lapplication. Elles int-grent des traitements de signaux (analyse spectrale, corrlation, traitement dimages,etc.) ou des lois de commande (rgulation tout ou rien, rgulation du premierordre, rgulation PID, etc.). Dans le cadre de cet ouvrage, nous considreronsces tches comme des botes noires, cest--dire que le traitement effectu par cestches relve des domaines comme le traitement du signal, le traitement dimagesou lautomatique, disciplines qui dbordent largement le contexte de ce livre. Tches de gestion de linterface utilisateur : ces tches permettent de prsenterltat du procd ou de sa gestion lutilisateur. En rponse, loprateur peut modi-er les consignes donnes ou changer les commandes. Ces tches peuvent tre trscomplexes et coteuses en temps de calcul si linterface gre est de taille impor-tante (tableau de bord) ou de type graphique (reprsentation 3D).LiaisonrseauRseauxSauvegarde RcuprationUnits de stockage LiaisonrseauLiaisonrseauOprateursProcdphysiqueexterneInterfaceentres/sortiesTraitementsdes donnesInterfacehomme/machineLiaisonstockageMesuresCommandesConsignesVisualisationProgrammation multitche Figure 1.6 Architecture logicielle dune application de contrle-commande multitche.1.2Architecture des applicationsde contrle-commande 9 Dunod La photocopie non autorise est un dlit. 1 Dveloppement dessystmes de contrle-commande Tches de communications : ces tches sont destines grer les messages envoysou reus travers un ou plusieurs rseaux ou bus de terrain. Si ce type de tchesexiste, lapplication est dite distribue ou rpartie. Tches de sauvegarde : ces tches permettent de stocker ltat du systme desinstantsxs.Cettesauvegardepeuttreutilise aposteriori pouranalyserlefonctionnement de lapplication ou lors dune reprise dexcution une tapeprcdente.Aprslanalyseetlaconceptiondelapplication,nousobtenonsunensembledetches ou activits qui cooprent an de raliser le contrle-commande du procdgr. Ces tches appartiennent aux diffrents groupes lists prcdemment : tchesdentres/sorties, tches de traitement, tches de gestion de linterface utilisateur,tches de communications et tches de sauvegarde. Ce dcoupage purement fonc-tionnelpeuttremodidanscertainscasenutilisantuneconceptiontournevers les entits ou objets contrler. Cet aspect de la conception et de la miseen uvre est prsent dans les chapitres suivants.Les tches obtenues, qui constituent lapplication de contrle-commande, ne sontpas des entits dexcution indpendantes. En effet, certaines tches sont connectesvers lextrieur pour les entres/sorties. De plus elles peuvent tre lies par des rela-tions de type (gure 1.7) : synchronisation : cela se traduit par une relation de prcdence dexcution entreles tches ; communications :lanotiondeprcdence,traduiteparlasynchronisation,sajoute le transfert de donnes entre les tches ; partage de ressources : les tches utilisent des lments mis en commun au niveaudu systme comme des zones mmoire, des cartes dentres/sorties, cartes rseau,etc. Certaines de ces ressources, comme par exemple les zones mmoire, ne sontpasounedoiventpastreaccessibles,pouravoirunfonctionnementcorrect,par plus dune tche la fois, elles sont dites ressources critiques .Ces diffrents concepts sont tudis de faon dtaille dans le chapitre 4.RSynchronisationRessourcecritiqueSortieEntreTche 6Tche 4 Tche 7Tche 8Tche 1Tche 3Tche 2Tche 5Figure 1.7 Reprsentation schmatique de larchitecture multitche dune application de contrle-commande.10 1.2Architecture des applicationsde contrle-commande 1 Dveloppement dessystmes de contrle-commande m Modles dexcution et ordonnancement Cette architecture logicielle peut tre vue comme un ensemble de tches synchro-nises, communicantes et partageant des ressources critiques. Le rle essentiel dusystme informatique est donc de grer lenchanement et la concurrence des tchesen optimisant loccupation du processeur, cette fonction est appele l ordonnance-ment . Ce principe dordonnancement est un point crucial des systmes de contrle-commande ; en effet lordonnancement va dterminer les caractristiques tempo-relles et tre le garant du respect des contraintes de temps imposes lexcution delapplication.Nous pouvons distinguer deux modles dexcution de ces systmes de contrle-commande : lexcution dite synchrone et lexcution asynchrone . Nous allons pr-senter ces deux modles dexcution laide dun modle dapplication trs simple.Cette application, constitue dun ensemble de tches pour grer le procd, intgreen particulier les deux tches suivantes : Tche de lecture des donnes entres par loprateur laide dun clavier, appele Lecture_consigne . Lintervention humaine fait que cette tche peut tre longue. Tchedalarmequisedclenchesurunvnementdalertecorrespondantaudpassement dun paramtre critique, appele Alarme . Celle-ci doit sexcuterau plus vite pour viter lendommagement du procd.Pour mettre en avant les diffrences entre les deux modles dexcution, nous allonstudier la situation dans laquelle la tche Lecture_consigne sexcute et la tche Alarme demandesonexcutionalorsquelatche Lecture_consigne nestpas termine.Dans le modle d excution synchrone , la perception de loccurrence de tout v-nement par le systme est diffre du temps dexcution de la tche en cours. Danslexemple propos, nous pouvons constater que la prise en compte dun signal dalertenest effective que lors de la n de la tche Lecture_consigne (gure 1.8). Dunpoint de vue du procd, la raction est perue comme diffre, alors que du pointde vue du systme informatique, elle est perue comme immdiate. LoccurrencetempsClavier AlerteRaction perue comme diffre par le procd Raction perue comme immdiatepar le systmeLecture_consigneAlarmeOccurrencesmisespar le procdOccurrencesobservespar le systmeApplicationFigure 1.8 Modle dexcution synchrone dune application de contrle-commande.1.2Architecture des applicationsde contrle-commande 11 Dunod La photocopie non autorise est un dlit. 1 Dveloppement dessystmes de contrle-commande desvnementsexternesadonctarticiellementsynchroniseaveclesystmeinformatique, do le nom dexcution synchrone.Ceretardpeutaffecterlapriseencomptedenimportequelvnement,quellequen soit la gravit pour lapplication. Il faut donc vrier que larchitecture op-rationnellechoisiepermettradeprendreencomptelescontraintestemporelles :hypothse de la fentre de visibilit des vnements ou dinstantanit des actions.La capacit du systme apprhender un vnement externe est caractrise par ladure de la tche la plus longue puisque les tches sont non interruptibles ou nonpremptibles .Dans le cas du modle synchrone dexcution, nous avons un systme dordonnan-cement compltement prvisible et, en consquence, il est possible en faisant uneanalyse exhaustive de lexcution de produire une squence dexcution qui est jouede faon rptitive. Cette tude de la squence est appele analyse de lordonnan-cement hors ligne. Lordonnancement peut se rduire un squencement. Nousavons alors un environnement informatique trs simple de lapplication dveloppepuisquil se rduit une liste de tches excuter. Lenvironnement informatiquepour piloter cette liste de tches se rduit un systme trs simple : un squenceur.Dans le modle dexcution asynchrone, loccurrence de tout vnement est imm-diatementpriseencompteparlesystmepourtenircomptedelurgenceoudelimportance.Danslexemplepropos,nouspouvonsconstaterquelapriseencompte dun signal dalerte est immdiate sans attendre la n de la tche Lecture_consigne (gure 1.9). La prise en compte de lvnement alerte est identiquepour le procd et le systme informatique. Loccurrence des vnements externesnest pas synchronise avec le systme informatique, do le nom dexcution asyn-chrone.Dans ce contexte, nous avons des tches qui sont interruptibles ou premptibles.En consquence, lordonnancement nest pas totalement prvisible et lanalyse delexcution des tches doit se faire en ligne par simulation ou par test. Cela ncessitelutilisation dun gestionnaire centralis des vnements et de la dcision dexcu-tion : excutif ou noyau temps rel.tempsClavier AlerteLes vnements sont immdiatement peruspar le systmeSuspension d'un traitement en coursAlarmeOccurrencesmisespar le procdOccurrencesobservespar le systmeApplicationLecture_consigne Lecture_consigneFigure 1.9 Modle dexcution asynchrone dune application de contrle-commande.121.2Architecture des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commandePour terminer cette section, nous allons rappeler trois dnitions importantes quenous avons utilises et xer le contexte de cet ouvrage. Nous avons ainsi dni : Tche non premptible ou premptible : Une tche non premptible ne peut tre interrompue qu des endroits spci-ques et la demande de la tche elle-mme : n_de_tche, attente_signalDans ce cas, la programmation et plus simple et aucun mcanisme de partagede ressources critiques nest prvoir. En revanche, des temps de rponse longspeuvent se produire. Unetchepremptiblepeuttreinterrompuenimportequelinstantetleprocesseur affect une autre tche. Dans ce cas, les temps de rponse un v-nement externe peuvent tre trs courts ; mais nous avons alors une program-mation plus complexe avec un besoin de mcanisme de partage de ressourcescritiques. Analyse de lordonnancement hors ligne ou en ligne : Uneanalysedelordonnancementhorslignecorrespondlaconstructiondune squence dexcution complte sur la base des paramtres temporels destchesenutilisantunemodlisation(rseauxdePetri)ouunesimulation(animation ou numration du modle). Lordonnanceur ncessaire est minimalpuisquelasquencedexcutionestprdnie,ilserduitunsquenceur.En revanche, lapplication ainsi ge est peu exible. Une analyse de lordonnancement en ligne correspond un choix dynamiquede la prochaine tche excuter en fonction des paramtres de la tche en utili-sant une modlisation de lalgorithme dordonnancement et une simulation delexcution. Lordonnancement a un cot temporel non ngligeable ; en revanche,lapplication peut ragir des vnements ou des situations non prvus. Excution synchrone ou asynchrone : Une excution est dite synchrone si les tches sont non premptibles et sex-cutent les unes aprs les autres dans un ordre qui peut tre dni par une analysehors ligne de lordonnancement. Une excution est dite asynchrone si les tches sont premptibles et sexcutentselon lordonnancement. Une analyse de la squence doit se faire obligatoire-ment en ligne.Dans la suite de cet ouvrage, nous nous intressons plus particulirement aux sys-tmes asynchrones composs de tches premptibles avec un ordonnancement enligne. Ainsi, larchitecture logicielle de lapplication est compose de plusieurs tchesralises par le concepteur et dun environnement spcique, le noyau temps rel,que nous allons dcrire. Le point essentiel de cet environnement est lordonnanceurquipermetdaffectertoutinstantleprocesseurunetcheanderespecterlensemble des contraintes temporelles attaches la gestion du procd.m Excutif ou noyau temps relCet environnement particulier dexcution, excutif ou noyau temps rel, peut treassimilunsystmedexploitationdepetitetailleddiauxapplicationsdecontrle-commande. La caractristique fondamentale est son dterminisme dex-1.2Architecture des applicationsde contrle-commande13 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commandecution avec des paramtres temporels xs (temps de prise en compte dune inter-ruption, changement de contexte entre deux tches, etc.). Nous pouvons comparerles diffrences au niveau des objectifs xs pour le noyau dexcution dun systmeinformatique classique et dun systme informatique de contrle-commande.Un systme classique na pas t conu pour permettre de respecter des contraintestemporelles, mais il suit les rgles suivantes : politiques dordonnancement des activits bases sur le partage quitable du pro-cesseur : affectation identique du temps processeur tous les processus en cours ; gestion non optimise des interruptions ; mcanismes de gestion mmoire (cache) et de micro-excution engendrant desuctuations temporelles (difcult pour dterminer prcisment les dures destches) ; gestiondestemporisateursoudelhorlogepasassezne(plusieursmilli-secondes) ; concurrence de lapplication temps rel avec le systme dexploitation toujoursactif ; gestion globale base sur loptimisation dutilisation des ressources et du tempsde rponse moyen des diffrents processus en cours.Unsystmeinformatiquedecontrle-commandesattacheauxcaractristiquessuivantes : efcacit de lalgorithme dordonnancement avec une complexit limite ; respect des contraintes de temps (chances). Ces contraintes temporelles setraduisent plus en termes de choix dune activit excuter un instant donnplutt que de rapidit dexcution de toutes les activits ; prdictibilit (rptitivit des excutions dans des contextes identiques) ; capacit supporter les surcharges ; possibilitdecerticationpourlesapplicationsdecertainsdomainescommelavionique, lautomobileEn gnral, contrairement un noyau temps rel, les contraintes temporelles ne sont pas garantiesdans un systme dexploitation classique (Unix, Windows NT).Une application temps rel tant par dnition un systme multitche, le rle essentieldu noyau temps rel est donc de grer lenchanement et la concurrence des tches enoptimisant loccupation de lunit centrale du systme informatique. Les principalesfonctions dun noyau temps rel peuvent tre scindes en trois groupes :1. gestiondesentres/sorties(gestiondesinterruptions,gestiondesinterfacesdentres/sorties, gestion des rseaux de communications) ;2. ordonnancementdestches(orchestrationdufonctionnementnormal,surveil-lance, changements de mode, traitement des surcharges) ;3. relations entre les tches (synchronisation, communication, accs une ressourcecritique en exclusion mutuelle, gestion du temps).141.2Architecture des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commandeIl important de noter que les tches sont les units actives du systme ; le noyau tempsrel nest actif que lors de son appel. Une tche active peut appeler le noyau tempsrel par une requte. Les diffrentes requtes sont servies par des modules du noyautemps rel appeles primitives. Ensuite le noyau temps rel ractive une tche delapplicationselonlalgorithmedordonnancementutilis(gure 1.10).Ainsi,lenoyau temps rel centralise toutes les demandes dactivation des tches et gre destables lui permettant de comparer les priorits (ou les urgences) et ltat de ces diversestches, ainsi que ltat doccupation des ressources. La dcision dactivation dunetche tant prise, le noyau temps rel lance les modules de programmes correspon-dant cette tche et lui alloue les ressources disponibles. La tche active occupe leprocesseur jusqu la n de son excution sous le respect des conditions suivantes : Elle ne ralise pas doprations dentres-sorties. Les ressources utilises sont disponibles. Aucun vnement extrieur ne revendique le droulement dune tche plus prio-ritaire.Nous pouvons donc dcrire schmatiquement le contexte complet dexcution duneapplication temps rel avec les deux parties : tches et noyau temps rel (gure 1.11).En conclusion de cette section sur lordonnancement qui est tudi de faon pluscomplte dans le chapitre 8, lordonnancement dans le cas des systmes temps rel contraintes temporelles strictes a pour objectif principal de rpondre aux deux cassuivants : Fautes temporelles : cela correspond un non respect dune contrainte temporelleassocieunetchecommeledpassementdeladatelimitedexcutionouchance. Cela induit la notion durgence dune tche. Surcharge : lors de loccurrence dune ou plusieurs fautes temporelles, lordon-nanceur peut ragir en supprimant une ou plusieurs tches de lapplication, ce quiamne la notion dimportance, cest--dire le choix dune tche excuter parrapport aux spcications fonctionnelles de lapplication.m Implmentation des applications de contrle-commandeComme nous le verrons au cours de cet ouvrage, les langages de dveloppement desapplications de contrle-commande sont trs divers. Mais, par rapport lenviron-nementdexcutionquenousvenonsdedcrire(noyautempsrelaveclestroisTche iTche j Noyautemps rel ExcutionprogrammeExcutionprogrammeExcutionprimitives et ordonnanceur Requte ActivationFigure 1.10 Interaction entre les tches et le noyau temps rel.1.2Architecture des applicationsde contrle-commande15 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commandefonctionsdcrites :1. gestiondesinterruptions,2. ordonnancement,3. relationsentre les tches), il est possible de dcliner les langages en trois groupes (gure 1.12) : langages standards (langage C) : le noyau temps rel qui supporte ce type delangage doit tre complet puisque le langage nintgre aucune spcicit de cedomaine de contrle-commande multitche ; langagesmultitches(langageAda) :ceslangagespermettentdedcrirelapplicationentermesdetches ;ainsilenoyaupeuttreplusrduitetnecomporter que les deux premires fonctions ;ApplicationTche i Tche jTche kTche x Tche yMesures CommandesNoyauouExcutifInterruptionsHorlogetemps rel Gestiondes interruptionsGestiondu tempsGestiondes vnementsActivation RequtePrimitivesOrdonnanceurFigure 1.11 Architecture de lapplication : tches et noyau temps rel.Langagesstandards(Langage C) NoyautempsrelLangagesmultitches(Langage Ada) NoyautempsrelLangagesractifsNoyautempsrel1 121 2 3 AutrelangageFigure 1.12 Langages utiliss pour dvelopper les applications de contrle-commandeavec un noyau temps rel (1. gestion des interruptions, 2. ordonnancement, 3. relationsentre les tches).161.2Architecture des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commande langages ractifs (langages Lustre, Esterel, Signal) : ces langages donnent nonseulement la possibilit de dcrire les fonctionnalits du programme, mais aussilenchanement des diffrentes parties. Le noyau est donc limit une coucheproche du matriel li notamment la gestion des interruptions. En revanche,tantdonnlapossibilittrslimitedexpressiondelaspectfonctionnel,ilssont souvent associs un langage standard pour palier ce manque.1.2.2 Architecture matrielle des applications de contrle-commandeComme nous lavons vu en introduction, laspect matriel a une trs grande impor-tance dans les applications de contrle-commande. Cette implication est lie dunepart la connexion directe avec le monde physique rel laide dune grande diver-sitdesystmesdentres/sortiesetdautrepartaumatrielinformatiqueparfoisspcique et dvelopp pour une application donne. Ce dernier point concerne lesapplications dites ddies et embarques ; le matriel a t conu et cr spcique-ment pour une application, comme un tlphone portable, une camra vido, etc. titre dexemple, les diffrents calculateurs embarqus dans un vhicule automobilesont ddis et spcialement dvelopps pour cette application (gure 1.13). Dansces matriels, nous trouvons un processeur de type microcontrleur redond pouravoir un haut niveau de scurit, des composants spciques (ASIC : ApplicationSpecic Integrated Circuit), une alimentation lectrique Tout ce matriel est ensuiteencapsuldansunbotierrsistantlenvironnementdefonctionnementusuel(chaleur, vibrations, ambiance corrosive, etc.).Beaucoup dapplications de contrle-commande sexcutent sur des plateformes PCclassiques. En revanche, il est toujours ncessaire de disposer de cartes dentres/sorties qui doivent souvent tre synchronises (acquisition et commande effectues des instants prcis). Ainsi, dans ce domaine dapplications informatiques, des matrielsspciques existent et permettent ce fonctionnement temporel : cest par exemplele cas de la plateforme PXI concatnation dune plateforme classique PC et de cartesdentres/sorties synchronises.Enn, dans de nombreux cas, les applications de contrle-commande sont de typedistribu, cest--dire quelles sont composes de plusieurs sites ou processeurs, surlesquelssexcutentunenvironnementmultitche,relisparunoudesrseauxinformatiques (Ethernet, CAN, FIP).Lensemble de ces aspects matriels est trait en dtail dans le chapitre 4.171.2Architecture des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commande Dunod La photocopie non autorise est un dlit.BotierLes calculateurs situs dans des partiesexposes sont placs dans des botiersmtalliques tanches et blinds.Ceux de lhabitacle sont en plastique. Mmoire Stocke les tches utilisantle microcontrleur.HorlogeDtermine la vitesse dexcution des oprations. Elle se mesure en mgahertz. (50 MHz).Microcontrleur de scurit Certains calculateurs (injection, ABS, etc.) disposent dun microcontrleurde secours (redondance).AlimentationAlimente le calculateur en lectriciten diminuant la tension en provenancede la batterie.Microcontrleur Excute les diffrentes tchesstockes en mmoire.ASIC Un ASIC (Application Specific

Integrated Circuit) est une puce ddie une application quelle excute directement. Amplificationdes informations dentre.Figure 1.13 Matriel ddi utilis pour implmenter une application de contrle-commande du domaine de lautomobile.181.3Dveloppement des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commande1.3 Dveloppement des applications de contrle-commandeLedveloppementdesapplicationsinformatiquesdemandedeplusenplusderigueurdanslesuividesdiffrentestapesdespcication,deconceptionetdecodage. Ce cycle de dveloppement permet ainsi dobtenir des applications de trsbonne qualit dun point de vue architecture logicielle, daugmenter la maintena-bilit et lvolutivit. En particulier, cette rigueur de dveloppement accrot de faonsignicative la correction des programmes en suivant une dmarche de tests unitaireset dintgration. Si ces tests, qui sont un point primordial dans lobtention dunequalit logicielle, sont aiss raliser dans le cas dapplications informatique classi-ques,enrevanche,danslecasdesapplicationsdecontrle-commande,lestestsoprationnels en excution relle sont souvent difciles produire cause de diversesparticularits : excution unique : satellite dexploration ; cot trs lev : fuse ; risques humains : avionAinsi, malgr des phases de tests souvent coteuses et consquentes, de nombreusesapplications de contrle-commande nont pas rempli les objectifs xs. Nous pou-vons citer quelques exemples connus : Mission Vnus : le satellite dexploration est pass plus de 500 000 km de laplante Venus au lieu de 5 000 km, prvu initialement. Cet chec a t attribu un simple remplacement dune virgule par un point dans un programme Fortran( DO 20 I 1. 5 au lieu de DO 20 I 1, 5 ). Avion militaire amricain F16 : lors des premiers essais en vol, lavion tait dclarsur le dos au passage de lquateur la trs grande surprise du pilote. Celatait simplement d une erreur de signe dans le programme. Navette spatiale amricaine : lors du premier lancement de la navette, le dparta t annul et la mission recule de trois jours (cot trs important). Ce fauxdparttaitduneerreurdesynchronisationentrelesdeuxordinateursdeconduite de vol. Le fonctionnement en redondance de ces ordinateurs conduisait un test de cohrence de certaines grandeurs physiques. tant donn une dsyn-chronisation des deux ordinateurs, ce test a t ngatif simplement cause de lamesure du mme paramtre effectue des instants diffrents. Mission sur Mars : lors de la mission dexploration de la plante Mars par le robotPathnder, une remise zro priodique des donnes acquises a fortement per-turb la mission. Ce problme tait li un blocage dune tche trs prioritairepar une tche moins prioritaire mais dtenant une ressource critique (rseau decommunication vers la terre). En particulier les donnes mtorologiques mesurestaient trs spciques dun point de vue dure et taille du fait des caractris-tiques martiennes. Fuse Ariane V : lors du premier lancement, la fuse a d tre dtruite causedune trajectoire non correcte. Cette erreur tait lie la rutilisation de certains= =1.3Dveloppement des applicationsde contrle-commande19 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commandemodules logiciels utiliss dans le contexte dAriane IV. Les spcications, attaches lacclration, auraient d tre diffrentes en termes de limites an dviter cedysfonctionnement.Cettelistedexemplesdeproblmesauniveaudelexcutiondapplicationsdecontrle-commande montre la ncessit de mettre en place un cycle de dveloppe-ment encore plus rigoureux pour ces applications de gestion de procd physiquedont les tests en excution relle ne sont pas toujours facilement accessibles.1.3.1 Cycle de dveloppement des applications informatiquesLe cycle de dveloppement des applications informatiques suit les trois tapes clas-siques que sont la spcication, la conception et la programmation. Lanalyse desbesoins permet dcrire le cahier des charges de lapplication. partir de ce cahierdes charges, le droulement des trois tapes conduit successivement aux descriptionssuivantes de lapplication (gure 1.14) : spcicationglobale :descriptionde cequelonafaire oule quoi ,cest--dire une mise en forme plus ou moins formelle du cahier des charges ; conceptions prliminaire et dtaille : description du comment , cest--direunemodlisationdelarchitecturelogicielledelapplication(modules,tches,objets).Ilpeuttrencessairedemployerdiffrentsniveauxderafnementselon la taille de lapplication ; programmation : traduction dans un langage excutable de larchitecture logi-cielle de lapplication dcrite prcdemment. Suivant la mthode de conceptionemploye et le niveau de rafnement, la traduction dans un langage de program-mation peut tre plus ou moins automatise.Cesdiffrentestapespeuventtreplusoumoinsformellesselonlesmthodesemployes.Aussi,chaquetape,ilestprimordialdevrierlacohrencedeladescriptionoudelatraductionralisepartirdeltapeprcdente.Cetravailconcerne la validation. Celle-ci constitue une preuve si la mthode est formelle ouun test si elle ne lest pas.CahierdeschargesAnalyse Analysedes desbesoins besoinsSpcificationglobaleConceptionsprliminaireet dtailleLogicielSpcification Conception Conception Programmation ProgrammationValidation externe Validation externe Validations internes Validations internesFigure 1.14 Cycle de dveloppement dune application informatique classique.201.3Dveloppement des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commandeUne prsentation gnralement plus adapte est celle du cycle en V (gure 1.15).Dans cette reprsentation, chaque niveau danalyse ou de conception correspondun niveau de validation ; ainsi, nous avons : conception dtaille et tests unitaires ; conception prliminaire et tests dintgration ; spcication et validation globale.Il est vident que cette formalisation mthodologique du dveloppement des appli-cations informatiques a pour principaux objectifs : viter les fautes logicielles, accrotrela maintenabilit, faciliter lvolutivit chaque tape ou ensemble dtapes cor-respond unemthodequiestgnralementsupporteparunoutilinformatiquepour aider sa mise en uvre plus ou moins automatise (CASE Tools : ComputerAided Software Engineering Tools).Lexprience du dveloppement de logiciels prouve que llaboration complte delapplication ne se fait pas en une seule fois : volution du cahier des charges, modi-cations du dcoupage modulaire, correction de programmes, etc. Cela a induit denouveaux schmas de dveloppement, appels itratifs ou en spirale, qui consistent prendre en compte les passages successifs dans les diffrentes tapes du dveloppe-ment. Lide forte retenir est que, lors de toutes modications apportes lappli-cation quelque niveau que ce soit, il est ncessaire de dcliner nouveau toutesles tapes du dveloppement.1.3.2 Dveloppement coupl matriel et logicielAvant de dcrire les diffrentes mthodes utilises dans le cadre des applications decontrle-commande et leurs spcicits, il est important de remarquer la particula-rit du dveloppement de ces applications quant au caractre du couplage fort entreles aspects matriel et logiciel.En effet, le cahier des charges dune application de contrle-commande dun pro-cd va intgrer dans la grande majorit des cas la fois la description du matriel etVALIDATIONINTGRATIONTESTS UNITAIRESCODAGECONCEPTIONDTAILLECONCEPTIONPRLIMINAIRESPCIFICATIONFigure 1.15 Cycle de dveloppement en V dune application informatique classique.1.3Dveloppement des applicationsde contrle-commande21 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commandeles fonctions remplir par ce procd (gure 1.16). Ainsi, la spcication de lappli-cation commence par une spcication systme (matriel et logiciel). Une partie dela conception prliminaire peut aussi intgrer les deux aspects puisque la ralisationdunmodulefonctionnellepeuttreralisesoitdemanirematrielle(circuitintgr spcique FPLA : Field Programmable Logic Array ou FPGA : Field Pro-grammable Gate Array) soit dune manire logicielle. Ensuite, le dveloppement desdeuxpartiespeutcontinuerdefaondiffrencieetclassiqueaveclaconceptiondtaille, limplmentation (ralisation ou codage) et les tests. nouveau, les deuxaspects de lapplication doivent se rejoindre pour passer la phase dintgration etde validation de lensemble. La phase dintgration est certainement ltape la plusimportante et la plus difcile. En effet, une partie logicielle va tre insre dans unenvironnement matriel trs spcique.Bien que ce ne soit pas le propos de cet ouvrage, laspect matriel est abord de faonsuccinctedanslechapitre 4.Auniveaudelaconception,ilexisteaussidenom-breuses mthodes permettant davoir des dveloppements de qualit. Ainsi, le lan-gage VHDL (VHSIC Hardware Description Language VHSIC : Very High SpeedIntegrated Circuit) de description des fonctions raliser dun point de vue matrielconduit une conception formelle des circuits, cest--dire autorisant une preuvede la conception tablie.Prenons un exemple trs rpandu comme les consoles de jeux portables. Ces matrielspossdentuneinterfaceutilisateurtrsspciquecomportantunensembledeCONCEPTI ONDTAILLECONCEPTI ONDTAILLECODAGE RALISATIONTEST TESTI NTGRATI ONVALIDATIONArchitectureoprationnelleLogiciel Matriel +ArchitecturelogicielleArchitecturematrielleCONCEPTI ONPRLIMINAIRESPCI FI CATI ONSYSTMEFigure 1.16 Cycle de dveloppement matriel et logiciel dune application de contrle-commande de procd.221.3Dveloppement des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commandeboutons, un haut-parleur et un cran couleur. De plus, ces consoles intgrent gnra-lement une liaison vers lextrieur de type infrarouge ou laire pour une connexionavec une autre console de la mme gamme. ces entres/sorties trs ddies, sajoutentdes contraintes de ralisation lies la caractristique embarque de lapplication :alimentation sur batterie, autonomie importante, encombrement rduit, ergonomie,design du botier, ralisation en trs grande quantit, cot le plus bas possibleToutes ces contraintes vont avoir un impact important sur le dveloppement aussibien matriel que logiciel. Ainsi, le processeur est de type microcontrleur faibleconsommation intgrant des entres/sorties multiples auquel sajoute un processeurgraphique pour grer lcran couleur. Le noyau temps rel implant doit possder lescaractristiquessuivantes :petitetaille(taillemmoirelimite),rapiditdexcution(ensembles de primitives simples), cot faible (ralisation en trs grande quantit)Ces diffrentes spcications, qui lient la ralisation matrielle limplmentationlogicielle, doivent tre prises en compte au dbut de lanalyse de lapplication.Aussi, nous pouvons rsumer lenvironnement de dveloppement dune applicationde contrle-commande par le schma de la gure 1.17. Les spcications du systmesont donc largies ; en plus des aspects fonctionnels et comportementaux classiquespour ce type dapplication, nous devons ajouter les contraintes de dveloppementvoques prcdemment, soit : contraintes matrielles : type de processeur, architecture (distribu, multiproces-seur),taillemmoire,dimensionphysique,consommation,environnement(temprature, pression, corrosion) ; noyau temps rel : primitives, taille (micronoyau), certiEnvironnement de dveloppement LogicielapplicatifNoyautemps relEnvironnement dexcutionSpcifications du systme Aspect fonctionnel et aspect comportemental Autres contraintes de dveloppement : matriel (processeur, architecture, taille, consommation) noyau temps rel langage de dveloppementLogicielMatriel LogicielFigure 1.17 Environnement spcifique du dveloppement dune application de contrle-commande de procd.1.3Dveloppement des applicationsde contrle-commande23 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commande langagesdedveloppement :assembleurs,langagedehautniveau,langageformel Ensuite, il est important de noter que le dveloppement de la partie logicielle duneapplication de contrle-commande va tre ralis sur une plate-forme dite hte qui na aucun rapport avec lenvironnement dexcution ou environnement cible en termes de processeur, mmoire, systme dexploitation, etc. Lorsque le logicielapplicatif est ralis et test autant que faire se peut sur cette plate-forme hte ,le programme est compil dans le code du processeur cible par un compilateurcrois ; puis il est tlcharg avec le noyau temps rel choisi vers larchitecture mat-rielle cible . De nouveau, des tests doivent tre raliss dans cet environnementdexcution.Eneffet,lecomportementduprogrammedanscettearchitecture cible de lapplication peut tre diffrent et amener des modications cons-quentes du programme. Ce processus conduit modier le cycle en V de dve-loppement des applications informatiques classiques par un cycle en W o ladeuxime partie du cycle correspond la reprise de la premire partie du cycle maisdans lenvironnement cible (gure 1.18). Nous trouvons en particulier dans cecycle en W un codage crois et lintgration avec le noyau.Ce constat de la dualit de dveloppement des applications de contrle-commandede procd amne plusieurs remarques concernant les environnements permettantdlaborer ce type dapplication : le noyau temps rel choisi doit tre adapt larchitecture cible de lapplica-tion en termes de codage, de taille et de fonctionnalits (primitives, gestion desentres, gestion du temps) ; lenvironnement de dveloppement sur la plate-forme hte doit possder unmulateur du noyau temps rel an de pouvoir faire les premiers tests du logicielmultitche ralis ;Dveloppementen environnement hte SIMULATION VALIDATIONINTGRATIONavec noyauTESTSCONCEPTIONADAPTEINTGRATIONSPCIFICATIONCONCEPTIONCODAGE CODAGE - CroisDveloppementen environnement cible TESTSFigure 1.18 Cycle de dveloppement en W dune application de contrle-commande de procd.241.3Dveloppement des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commande lenvironnementdedveloppementsurlaplate-forme hte doitpouvoirfaire une compilation croise dans le code du processeur de larchitecture cible ; lenvironnementdedveloppementsurlaplate-forme hte doitpermettreun debug delapplicationlorsdesonexcutionsurlarchitecture cible .Cette observation de lexcution se fait distance par une liaison rseau quel-conque (Ethernet). De nombreux environnements proposent une reprsenta-tion graphique de lexcution des tches. La plus grande difcult rside dans lefait de ne pas modier lexcution de lapplication par cette observation.Toutes ces remarques impliquent dans le choix dun environnement de dveloppe-mentdecesapplicationsdeprendreencomptelensembledescaractristiquessuivantes : environnement cible (microprocesseurs, architecture) ; environnement hte (type de systme dexploitation) ; conformit une norme ou pseudo-norme (POSIX, projet Sceptre) ; compacit (pour les applications embarques) ; outils daide au dveloppement ( debug , analyse en ligne) ; primitives temps rel (liste de tous les services fournis) ; caractristiques de lordonnanceur (politiques dordonnancement) ; caractristiques temporelles : temps de masquage des interruptions (interrupt latency), temps pendant lequelles interruptions sont masques et ne peuvent donc pas tre prises en compte, temps de rponse (task response time) : temps entre loccurrence dune inter-ruption et lexcution de la tche rveille.Lensemble de ces notions concernant le noyau temps rel et son choix pour uneapplication donne est abord dans le chapitre 5.1.3.3 Cycle de dveloppement des applications de contrle-commandeIl existe de nombreuses mthodes appliques au dveloppement logiciel des appli-cations de contrle-commande de procd. Ces mthodes couvrent une ou plusieurstapesducyclededveloppementselonlesniveauxderafnementoellessontutilises.Sansvouloirfaireunexposexhaustifdelexistant,ilestintressantdeciter quelques mthodes en les diffrenciant par leur concept de base. Nous trouvonsainsi des mthodes fonctionnelles et structures, dites aussi ots de donnes, quisont fondes sur le principe du dcoupage fonctionnel de lapplication. Ces lmentsou modules fonctionnels sont appliqus aux donnes qui se propagent de fonctionen fonction. Le deuxime ensemble de mthodes est celui des mthodes bases surdes modles de machines tats. Ces mthodes reposent sur des bases formelles etpermettent en gnral des vrications plus avances que les prcdentes. La troi-sime catgorie, plus rcente, de mthodes est dite oriente objets ou objets. Nouspouvonsrsumercesderniresendisantquecesmthodesmettentenavantlesdonnesetleurstructuration.Nouspouvonsdonnerlesexemplessuivantsdanschacun de ces ensembles :1.3Dveloppement des applicationsde contrle-commande25 Dunod La photocopie non autorise est un dlit.1 Dveloppement dessystmes de contrle-commande Mthodes fonctionnelles structures : JSD : Jackson System Design (Michal Jackson, 1981) SA_RT : Structured Analysis Real Time (Ward-Mellor, 1984 ; Pirbha-Hatley,1986) DARTS : Design Approach for Real-Time Systems (Gomaa, 1984) SDL : Specication and Description Language (CCITT, 1988) MSMC : Modlisation Simulation des Machines Cyberntiques (Brenier, 2001) Mthodes bases sur les machines tats : Rseaux de Petri (Petri, 1962) GRAFCET : Graphe Fonctionnel de Commande tape Transition (IEC 1988) Statecharts : (D. Harel, 1987) Langagesractifssynchrones :Lustre(Caspi,1991),Esterel(Berry,1991),Signal (le Guernic, 1991) Mthodes objets ou orients objets : UML : Unied Modeling Language (OMG, 1995) HOOD : Hiearchical Object Oriented Design (CRI-Cisi Ingnierie-Matra, 1987)La gure 1.19 reprend le cycle en V de dveloppement avec le positionnementde quelques-unes de ces mthodes dans ce cycle.Comme cela a t justi et expliqu dans lavant-propos, les mthodes SA-RT etDARTS, qui permettent de dcrire compltement le cycle dans ses phases de sp-cication et de conception, sont celles qui sont tudies de faon dtaille dans cetouvrage. En effet, dans le cas dapplications embarques de taille petite ou moyennequi sont implmentes dans une architecture multitche, il semble plus pertinentdutiliser une analyse et une conception de type fonctionnel et structur.DARTSStateChartsGRAFCETHOODSA-RTDARTSMSMCStateChartsUMHOODSA-RT MSMCStateChartsUMLCODAGECONCEPTIONDTAILLETESTS UNITAIRES VALIDATIONCONCEPTIONPRLIMINAIRESPCIFICATIONINTGRATIONFigure 1.19 Quelques mthodes de dveloppement dune application de contrle-commande de procd.261.3Dveloppement des applicationsde contrle-commande1 Dveloppement dessystmes de contrle-commande1.3.4 Quelques exemples industriels dapplications de contrle-commandeAn dillustrer les diffrents environnements de dveloppements des applications decontrle-commande, nous prsentons des exemples industriels issus de programmesde taille importante des annes 1990-2000. Ces exemples sont caractriss par lenom du programme, la ou les socits en charge du programme et les mthodes etlangages utiliss, soit : Programme Spot 4 (Matra Marconi Space/CNES) : satellite destin une obser-vation de la terre (mtorologie, environnement, agriculture) Spcications et conceptions : HOOD Langages : Ada, Assembleur Programme Ariane 5 (Arospatiale/CNES) : lanceur Spcications et conceptions : HOOD Langages : Ada, noyau temps rel ARTK, Assembleur (Motorola 68020) Programme ISO lnfrared Space Observatory (Arospatiale/ESA) : ensemble desatellites destins une observation de lespace dans un domaine infrarouge Spcications et conceptions : SART et HOOD Langages : Ada (15 000 lignes), Assembleur (11 000 lignes) Programme SENIT8 (Dassault lectronique & DCN-Ingnierie) : quipementsde gestion et de contrle-commande du porte-avions Charles de Gaulle Spcicationsetconceptions :SARTetAda-Buhr(prochedelamthodeDARTS) Langages : Ada (1 000 000 lignes), C (400 000 lignes) Programme Rafale (Dassault lectronique) : avion militaire Spcications et conceptions : SA-RT et OMT Langages : Ada (800 000 lignes 1 500 000 lignes selon les versions).Nous pouvons remarquer que les environnements de dveloppement intgrent uneanalyse fonctionnelle et structure avec SA-RT et une conception oriente objet.Cela est d essentiellement soit des obligations du cahier des charges (applicationsspatiales) soit la taille de lapplication qui justie une mthode oriente objet.27 Dunod La photocopie non autorise est un dlit. 2 SPCIFICATIONSELON LA MTHODE SA-RT 2.1 Introduction gnrale la mthode SA-RT La mthode SA-RT est une mthode danalyse fonctionnelle et oprationnelle desapplicationsdecontrle-commande.Cettemthodepermetderaliserunedes-criptiongraphiqueettextuelledelapplicationentermesdebesoins,cest--direde ce que lon a faire ou le quoi ( What ?). Cette mise en forme du cahierdes charges de lapplication est formelle dans le sens o la mthodologie (ensembledesdocumentslaborer)etlexpression(syntaxegraphique)sontdnies.Enrevanche, elle ne permet pas deffectuer une vrication de proprits de lapplication partir des seules descriptions SA-RT. Des tudes ont t menes pour associer lamthode SA-RT des mthodes formelles an dapporter des possibilits de simulationet de vrication. Une de ces mthodes est prsente la n du chapitre. Aucunergle ofcielle ou normalisation na t mise en place pour la mthode SA-RT et sonutilisation. Par consquent, il existe de nombreuses mises en uvre de la mthodeSA-RT avec des diffrences plus ou moins importantes et aussi des extensions sp-ciques de la mthode. Ceci fera lobjet du dernier point trait dans ce chapitre.Nous allons nous attacher dcrire la mthode SA-RT la plus gnrale et la plususite, et correspondant la mthodologie de dveloppement dune application decontrle-commande qui est lobjectif de cet ouvrage.Laccroissement trs important de la taille des logiciels dvelopps dans les annes 70a conduit mettre en place des mthodes danalyse et de conception permettantune meilleure ralisation et aussi une maintenance plus efcace dans lexploitationdes logiciels. Le mot essentiel de ces mthodes est structuration dans le sens dunedcomposition en lments ou blocs fonctionnels pour un niveau danalyse donnet dune dcomposition hirarchique cohrente entre les diffrents niveaux danalyse.Ces mthodes danalyse ou de conception structures conduisent naturellement la programmation structure. La deuxime particularit commune ces mthodes estla description sous forme de ux ou ots de donnes, de contrle ou autres. Laspectoprationnel de la description est alors visualis par la propagation de ces ux.Ainsi,noustrouvonslamthodeSA-DT( StructuredAnalysisDesign Technics )despcicationdunsystmequipermetdexprimerunblocreprsentantsoitlesactivits (fonctions) soit les donnes. Les ots entrants sont les donnes, un contrleoudesmcanismes(mthodes)etlesotssortantscorrespondentauxsortiesde28 2.1Introduction gnrale la mthode SA-RT 2 Spcificationselon la mthode SA-RT donnes. Cette mthode trs gnrale de description dun systme a t adapte laspcicationdelogicielsaveclamthodetrsconnueSA( StructuredAnalysis )(gure 2.1).LanalysestructureSA,dnieparE. Yourdonet T. Demarco,estunemthodedescendante par afnages successifs des traitements, appels process . Les diffrentsdiagrammessontdoncordonnshirarchiquementenfaisantapparatrepourlesderniersniveauxdesfonctionslmentaires,appelesprimitiveslmentairesou process primitifs. Les diffrents outils composant cette mthode sont : diagrammes de transformations de donnes ou diagramme de ots de donnes(DFD) ; dictionnaire de donnes ; spcications des process primitifs.Lesdiagrammesdeotsdedonnessontconstruitspartirdequatrelmentsgraphiques : traitement (cercle), ot de donnes (che), unit de stockage (traitsparallles) et entit externe (rectangle) (tableau 2.1). partir de ces lments de base,il est possible de dcrire laspect fonctionnel dune application par un diagramme otsde donnes. Un exemple, prsent sur la gure 2.2, montre lanalyse dune applica-tion trs simple de rgulation de temprature avec trois entits externes, deux processet une unit de stockage. Remarque Il est intressant de noter que cette description graphique fonctionnelle dune application laidede la mthode SA sera presque entirement reprise dans la mthode SA-RT, montrant bien ainsi sadpendance chronologique. Pour exprimer compltement le comportement de lapplication, le diagramme otsde donnes de SA manquait dun moyen permettant de spcier laspect oprationnel,Spcificationdun systmeSpcificationstatiquedun logicielSpcificationdynamiquedun logicielSADTSASA-RTESMLStructured Analysis Design Technics(D.T. Ross, 1976)Structured Analysis(E. Yourdon, T. Demarco, 1979)Structured Analysis Real Time(Ward/Mellor, 1985 ; Hatley/Pirbhai, 1986)Extended Systems Modeling Language(W. Bruyn, R. Jensen, D. Keskar,P. Ward-Boeng, Hugues Aircraft, 1987)Figure 2.1 Positionnement chronologique de la mthode SA-RT.2.1Introduction gnrale la mthode SA-RT 29 Dunod La photocopie non autorise est un dlit. 2 Spcificationselon la mthode SA-RT cest--direladescriptiondelenchanementdesdiffrentsprocess.CettelacunefutcombleparlacrationdemthodeSA-RT( StructuredAnalysis-Real Time ).Deux groupes laborrent la mthode SA-RT avec des diffrences notables en termesde reprsentation : dune part, la mthode tablie par Ward et Mellor en 1985 quiassocie le fonctionnel et le contrle dans un mme diagramme et, dautre part, lamthodeproposeparHatleyetPirbhaien1986quisparelefonctionneletlecontrle. Mais ces deux vues de la mme mthode restent trs similaires en termes decapacitdexpressiondelaspcication.Nousprsentonsdanscetouvragelamthode SA-RT tablie par Ward et Mellor en 1985.Comme le montre la gure 2.1, la mthode SA-RT a continu voluer au seindes entreprises en intgrant des besoins spciques un domaine dapplications.Ainsi, nous trouvons une mthode SA-RT, appele ESML et utilise dans lavionique,qui a t enrichie dun point de vue ot de contrle. Tableau 2.1 Les diffrents lments graphiques de la mthode SA. Fonction Signification Reprsentation graphique Traitement ou process Unit de travail qui ralise la transformation des donnes dentre en donnes de sortie Cercle ou bulle Action dcrite par : verbe + nomFlot de donnes Vecteur nomm reliant deux process, sur lequel circule un ensemble de donnes de mme natureFlche en trait plein Donne nommeUnit de stockage ou rservoirEntit ou zone de rangement de donnes Deux traits parallles Entit nommeEntit externe ou terminateurProvenance, source ou destination des donnes Rectangle Entit nommeAcqurirMesuresMesuresMesuresCapteurTension lue Temprature Tension_commandeTemprature_consigneCommande_chauffageThermistanceCommanderchauffageAcqurirtempratureRsistancechauffanteTmoinde chauffageFigure 2.2 Exemple simple du diagramme flot de donnes de la mthode SA correspondant une application de rgulation de temprature.30 2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 2 Spcificationselon la mthode SA-RT La mthode SA-RT intgre les trois aspects fondamentaux dune mthode de spci-cation en mettant laccent sur les deux premiers qui sont des points essentiels dansles applications de contrle-commande : aspect fonctionnel (ou transformation de donnes) : reprsentation de la trans-formation que le systme opre sur les donnes et spcication des processus quitransforment les donnes ; aspect vnementiel (pilot par les vnements) : reprsentation des vnementsquiconditionnentlvolutiondunsystmeetspcicationdelalogiquedecontrle qui produit des actions et des vnements en fonction dvnements enentre et fait changer le systme dtat ; aspect informationnel (donnes) : spcication des donnes sur les ots ou dansles stockages. Ce dernier aspect qui est en gnral assez nglig dans ce type dappli-cation peut faire lobjet dune description spcique choisie au sein dune entre-prise. 2.2 Prsentation de la syntaxe graphique de la mthode SA-RT Nous allons prsenter la syntaxe graphique complte de SA-RT permettant dlaborerles diffrents diagrammes de la mthode. Cette syntaxe graphique trs simple peuttre scinde en deux parties : la syntaxe graphique affrente laspect fonctionnelet la syntaxe ddie laspect contrle ou vnementiel. 2.2.1 Syntaxe graphique pour laspect fonctionnel m Syntaxe graphique du processus fonctionnel En premier lieu, nous trouvons le Processus fonctionnel ou Processus qui repr-sente une transformation de donnes. Un ou plusieurs ux de donnes en entressont traits pour donner un ou plusieurs ux de donnes en sortie (gure 2.3). LeProcessus est reprsent par un cercle avec une tiquette ou label explicite form de :tiquette_Processus verbe (+ un ou plusieurs complments dobjets) + numro m Syntaxe graphique du flot de donnes Puis, nous avons le Flot de Donnes qui supporte ou transporte les valeurs dunecertaine information diffrents instants. Ce concept reprsente le cheminementdes donnes. Le ot de donnes est reprsent par un arc orient avec une tiquetteou label explicite form de (gure 2.4) : tiquette_Flot_de_Donnes nom (+ qualiant)Les valeurs de ce ot de donnes sont supposes disponibles pendant tout le tempso le processus producteur de ce ot est en mesure de les gnrer.Le ot de donnes peut reprsenter aussi bien une donne de type continu, code parunentierouunrel( Temprature )quunedonnediscrtecodeparunboolen,==2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 31 Dunod La photocopie non autorise est un dlit. 2 Spcificationselon la mthode SA-RT exemple Position_interrupteur . Un ot de donnes peut dcrire aussi bien unedonne lmentaire ou unique, exemple Temprature quune donne structureintgrantplusieursdonneslmentaires,exempleladonne Pressions quiestcompose de Pression_huile et Pression_air . Il est alors possible de faire appa-ratre ltiquette du ot de donnes sous la forme suivante : tiquette_Donne_Structure tiquette_Donne_1 , tiquette_Donne_2 Une spcication dtaille de cette donne, vhicule par le ot de donnes, est faitedans le Dictionnaire de donnes (voir ci-aprs).Mesurertemprature1Commandervanne2Calculermoyenne3Lecturede donnescriturede donnesTransformationde donnesExemplestiquetteProcessusNFigure 2.3 Processus fonctionnel de la mthode SA-RT.Mesurertemprature1Commanderlampe2Calculervitesse3TempraturemesureAllumagelampeAffichagevitesseDistanceparcourueTophorlogeSignaltempratureSignalinterrupteurFigure 2.4 Exemples simples de flots de donnes de la mthode SA-RT.=32 2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 2 Spcificationselon la mthode SA-RT Ces ots de donnes peuvent se dcomposer ou au contraire se regrouper lors des liai-sons entre les processus fonctionnels dans le diagramme ot de donnes (gure 2.5). m Syntaxe graphique du stockage de donnes Le troisime lment graphique est le Stockage de Donnes qui modlise le besoinde mmorisation dune donne de telle faon que sa valeur puisse tre relue plu-sieurs fois. Comme le ot de donnes auquel il est troitement associ, il est nommpar une tiquette ou label explicite form de : tiquette_Stockage_de_Donnes nom (+ qualiant)Le stockage de donnes est reprsent par deux traits horizontaux encadrant lti-quette dnie ci-avant (gure 2.6). Les arcs ots de donnes arrivant ou partantde lunit de stockage ne sont pas tiquets sils transportent les donnes mmorisescompltes. Si une partie de la donne est crite ou lue, larc transportant de faonpartielle la donne doit tre tiquet avec le nom de cette donne.Un exemple de diagramme ot de donnes intgrant ces trois lments graphiquesde la mthode SA-RT (processus fonctionnel, ot de donnes et unit de stockage)est prsent sur la gure 2.7.Dcompositione n n o DRegroupemente n n o D y o v n e t s es t o l f x u e d s e l r u se n n o D1 _ e n n o D e d t i a r t x e t s e e n n o DnnoDe1_e n n o D1 _ e n n o D t e 2 _ e n n o D t n o se d s t i a r t x e e n n o DnnoDe1_nnoDe2_e n n o Dn o i t a r C e d e v i t a n r e t l a e n n o De n n o Dt o l f e L e n n o D i h c i r n e t s e se d 1 _ e n n o DnnoDe1_e n n o Dt o l f e L e n n o D t i u r t s n o c t s e c e v as t o l f s e l 1 _ e n n o D t e 2 _ e n n o DnnoDe1_nnoDe2_Figure 2.5 Dcomposition et regroupement des flots de donnes de la mthode SA-RT.=PressionTempratureParamtres_moteur Paramtres_moteurFigure 2.6 Unit de stockage de la mthode SA-RT.2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 33 Dunod La photocopie non autorise est un dlit. 2 Spcificationselon la mthode SA-RT Remarque Pour des besoins de clart graphique, un stockage de donnes peut tre visualis plusieurs fois surun diagramme ot de donnes en notant cette duplication par une * . Il est important de noter que lutilisation de llment stockage de donnes peutcorrespondre deux cas : mmorisation ou reprsentation des constantes du systme ; mmorisation de valeurs de donnes partages entre deux ou plusieurs processusdsynchroniss (consommation et production des donnes des instants ou desrythmes diffrents). m Syntaxe graphique de la Terminaison Enn, le dernier lment graphique, utilis dans cet aspect fonctionnel, est la Termi-naison , ou encore appele bord de modle , qui reprsente une entit extrieurechangeant des donnes avec le systme modlis. Une terminaison peut donc treuneentitlogicielle(programme,basededonnes)oumatrielle(capteurs,actionneurs, console oprateur). Reprsente par un rectangle, elle est nommepar une tiquette ou label explicite form de (gure 2.8) :tiquette_Terminaison nom (+ qualiant)Temprature_consigne*ChauffageRgulertemprature2Mesurertemprature1Signal_tempratureTemprature_mesureAffichageTemprature_consigne*Affichertemprature3Figure 2.7 Exemple dun diagramme flot de donnes de la mthode SA-RT.=34 2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 2 Spcificationselon la mthode SA-RT 2.2.2 Syntaxe graphique pour laspect contrle Dans les diagrammes ot de donnes, le dclenchement de lexcution des processusdetransformationdedonnespeuttreliaurythmedapparitiondesdonnesentrantes (diagramme pilot par les donnes : data-driven ). Mais, dans le cas de laspcication des applications temps rel, il est prfrable davoir un contrle de cestransformations de donnes pilot par des conditions externes comme loccurrencedvnements ( event-driven ) (gure 2.9). Cette vue dynamique du modle imposela mise en place de la partie contrle : processus de contrle et ot de contrle m Syntaxe graphique du processus de contrle Le Processus de contrle reprsente la logique du pilotage des processus fonctionnels.Il gnre lensemble des vnements qui vont activer ou dsactiver les processus fonc-tionnels. En retour, les processus fonctionnels fournissent au processus de contrletous les vnements ncessaires aux prises de dcision. Le processus de contrle nepeut en aucun cas grer des donnes.Le Processus de contrle est reprsent par un cercle en pointill avec une tiquetteou label explicite form de (gure 2.10) :tiquette_Processus_Contrle verbe (+ un ou plusieurs complments) + numroProductionde donnesSignalCapteurConsommationde donnesCommandeActionneurFigure 2.8 Terminaison ou bord de modle de la mthode SA-RT.Donne_1Donne_3Donne_2Pilotage de lexcutionPilotage de lexcutionProcessus1vnement(a)Donne_1Donne_3Donne_2Processus1(b)Figure 2.9 Pilotage de lexcution dun processus fonctionnel : (a) pilot par les donnes et (b) pilot par les vnements.=2.2Prsentation de la syntaxe graphiquede la mthode SA-RT 35 Dunod La photocopie non autorise est un dlit. 2 Spcificationselon la mthode SA-RT m Syntaxe graphique du Flot de contrle Le Flot de Contrle transporte les vnements ou informations qui conditionnentdirectementouindirectementlexcutiondesprocessusdetransformationsdedonnes. Le ot de contrle est reprsent par un arc orient pointill avec une ti-quette ou label explicite form de (gure 2.11) : tiquette_Flot_de_Contrle nom (+ qualiant)Lesvnements,fournisparle processusdecontrle ,sontgnralementlislactivation ou la dsactivation des processus fonctionnels. Aussi, ces vnementsspciques ont t formaliss et prdnis : E pour Enable (activation) ; D pour Disable (dsactivation) ; T pour Trigger (dclenchement).Les deux premiers vnements sont utiliss ensemble E/D pour piloter un processusfonctionnel de type boucle sans n ou priodique, cest--dire que le processusde contrle doit lancer lexcution de ce processus avec lvnement E et ensuitepeut larrter avec lvnement D . Lvnement T est utilis pour activer unprocessus fonctionnel de type dbut-n ou sporadique, cest--dire que le pro-cessus de contrle doit lancer lexcution de ce processus avec lvnement T etensuite le processus sarrte la n de son excution sans intervention du contrle.Contrlertemprature1Pilotervanne2Grermoteur3Figure 2.10 Processus de contrle de la mthode SA-RT.=Contrlerchauffage2Vrifiertemprature1Trop_chaudTempratureTemprature_consigneDclenchementFigure 2.11 Exemple simple dune partie contrle lie une partie fonctionnelle de la mthode SA-RT.362.3Les diagrammes flot de donnes 2 Spcificationselon la mthode SA-RT2.3 Les diagrammes flot de donnes2.3.1 Prsentation dun exemple simple dapplication de contrle-commandeAn dillustrer la mthodologie au fur et mesure de la prsentation, nous allonsprsenter un exemple simple qui va tre dclin en dtail au cours de cet ouvrage.Considrons un systme de freinage automobile qui est constitu dune part dunensemble classique compos dune pdale de frein (demande de freinage) et dun frein(actionneur de freinage) et dautre part dun systme ABS (Anti-blocking Brake System).Un capteur de glissement de roues est associ ce systme ABS. Pour simplier, lefonctionnement de lABS est bas sur un arrt du freinage ds quun glissement estdtect sur les roues, et cela mme si la demande du conducteur est toujours effective.Le conducteur a la possibilit dactiver ou non ce systme ABS laide dun boutonspcique (bouton deux positions stables : interrupteur). Un voyant permet de luiindiquer lactivation du systme ABS. En revanche, il nest pas possible de dsactiverle systme ABS en cours de freinage, cest--dire pendant lappui sur la pdale de frein.La spcication fonctionnelle de cette application laide de la mthode SA-RT vaseffectuer en plusieurs tapes : diagramme de contexte ; diagramme prliminaire ; diagrammes de dcomposition.2.3.2 Diagramme de contexte dune applicationLediagrammedecontexteestunepremiretapeextrmementimportantepuis-quelle va dnir le contexte et lenvironnement extrieur du systme pilot. Nouspouvons la considrer comme le contrat de ralisation entre le concepteur et sonclient. Les bords de modle ou terminaisons vont apparatre uniquement dans cediagramme.Lesdescriptionsprcisesdecesterminaisons,ainsiquedesdonnesou ventuellement des vnements entrants ou sortants de ceux-ci, sont la chargedu donneur dordre. Un exemple gnrique dun diagramme de contexte est donnsur la gure 2.12.Noustrouvonsunetunseulprocessusfonctionnel,numrot 0 ,quitraduitlapplication raliser effectivement par le concepteur. Autour de ce processus fonc-tionnel, un ensemble de bords de modles fournit ou consomme les donnes ouvnements de cette application. Ces bords de modles peuvent donc tre les lmentsphysiques suivants : capteurs (thermocouples, dynamomtres, etc.) ; actionneurs (rsistances chauffantes, vannes, etc.) ; oprateur(s) li(s) des capteurs (interrupteurs, potentiomtres, etc.) ; systmes dafchage (lampes, diodes, cran dordinateur, etc.) ; systme de stockage ou de sauvegarde externe (disque, bande magntique, etc.) ; systme dimpression (imprimante, drouleur papier, etc.) ; 2.3Les diagrammes flot de donnes37 Dunod La photocopie non autorise est un dlit.2 Spcificationselon la mthode SA-RTLensemble des donnes ou vnements changs avec lextrieur du processus fonc-tionnel ,quireprsentelapplication,constituelesspcicationsdentresetdesorties de lapplication. La description de ces entres/sorties sera faite dans le diction-naire de donnes ( 2.5).Dans lexemple simple dun systme de freinage automobile ( 2.3.1), le diagrammede contexte est constitu du processus fonctionnel Contrler systme freinage 0 et de cinq bords de modles (gure 2.13) : terminaison Pdale de frein fournissant la donne Demande_freinage ; terminaison Bouton dactivation de lABS fournissant la donne Activation_ABS ; terminaison Capteur de glissement fournissant la donne Glissement_roue ; terminaison Systmedefreinage consommantladonne Commande_freinage ; terminaison Voyant ABS consommant la donne Afchage_ABS .Ce diagramme de contexte dnit parfaitement linterface entre le concepteur et leclient, cest--dire les donnes fournir ou gnrer. La suite du travail danalyseDonne_E_1Donne_E_2 Donne_S_2Donne_E_3Donne_S_3Donne_S_1Consigne_1Affichage_1Capteur 1Capteur 2Capteur 3Actionneur 1Actionneur 2Actionneur 3Oprateur 1cranPiloterapplication0Figure 2.12 Diagramme de contexte gnrique de la mthode de spcification SA-RT.Demande_freinageCommande_freinageAffichage_ABSGlissement_roueActivation_ABSMise_en_marcheContrlersystmefreinage0Systme de freinageVoyant ABS Capteur glissementBouton activation ABSPdale de freinConducteurFigure 2.13 Diagramme de contexte de lapplication systme de freinage automobile .382.3Les diagrammes flot de donnes 2 Spcificationselon la mthode SA-RTva donc se situer dans lexpression du processus fonctionnel raliser : Contrlersystme freinage 0 .2.3.3 Diagramme prliminaire et diagrammes de dcompositionLepremierniveaudanalyseestreprsentparlediagrammeprliminaire.Cediagramme prliminaire est la premire dcomposition du processus rali