Systèmes temps réel

SYSTMESTEMPS RELDE CONTRLE-COMMANDE

Conception et implmentation

Francis CottetEmmanuel Grolleau

SRIE | EEA

ISBN 2 10 007893 3

Cet 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 de

conception ; dfinir et paramtrer lenvironnement dexcution des systmes ; raliser limplmentation multitche base sur un noyau temps

rel ; 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 EEA

Francis Cottet Emmanuel Grolleau

F. CO

TTETE. G

RO

LLEAU

SYSTM

ES TEMPS R

EL D

E CO

NTR

LE-C

OM

MA

ND

E

SYSTMES TEMPS REL DECONTRLE-COMMANDE Conception et implmentation

FRANCIS COTTET

est professeur lENSMA(cole NationaleSuprieure de Mcaniqueet dArotechnique).

EMMANUEL GROLLEAU

est 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.com

GESTION INDUSTRIELLE

CONCEPTION

FROID ET GNIE CLIMATIQUE

MCANIQUE ET MATRIAUX

CHIMIE

ENVIRONNEMENT ET SCURIT

EEA

NordCompoFichier en pice jointe9782100078936_couverture.jpg

Francis CottetEmmanuel Grolleau

S

YSTMES TEMPS RELDE

CONTRLE-COMMANDE

Conception et implmentation

cottet_prelims Page I Mardi, 1. mars 2005 2:33 14

D

U

MME

AUTEUR

: F

RANCIS

C

OTTET

LabVIEW Programmation et applications,

Dunod, 2001

Dunod, Paris, 2005ISBN 2 10 007893 3

cottet_prelims Page II Mardi, 1. mars 2005 2:33 14

III

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.

TABLE DES MATIRES

Avant-Propos V

1

Dveloppement des systmes de contrle-commande 1

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-RT 27

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 DARTS 81

3.1 Introduction

81

3.2 Prsentation de la mthode DARTS

85

3.3 Exemples de conception avec la mthode DARTS

102

4

Architectures systmes 109

4.1 Architecture matrielle

109

4.2 Architecture logicielle

138

4.3 Rseaux et bus de terrain

160

5

Excutifs temps rel 181

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

230

IV

6

Programmation des systmes multitches 245

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 industrielle 341

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 rel 407

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 513

B

Standards POSIX 519

C

Module de botes aux lettres POSIX 523

D

Module de communication Ada 533

Bibliographie 539

Lexique anglais franais 541

Sigles 546

Index 551

V

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t 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 forteautomatisation dans tous les produits industriels ou destins lusage grandpublic . La liste infiniment 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 (cran couleur de haute dfinition, cran tactile, 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 faible

consommation, ralisation de circuits lectroniques ddis (FPGA, FPLA), etc. Automatique : lois de rgulations adaptes, rgulation numrique, etc. Informatique : mthodes et mthodologies de dveloppement, systmes dexploi-

tation ou excutifs embarqus, langages applicatifs, mthodes de tests et devalidations, etc.

Les domaines de llectronique et de lautomatique ne sont pas le propos de cetouvrage. Toutefois, tant donn le dveloppement li entre les deux parties matrielet logiciel , une prsentation succincte du matriel est faite. En revanche, nousallons nous intresser particulirement laspect informatique ou plus exactement laspect gnie logiciel, cest--dire la ou les mthodes permettant de dveloppercorrectement ces applications. La signification 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 financier important, un effet nuisible sur lenvi-ronnement, ou plus gravement, mettre en jeu des vies humaines. Aussi la mtho-dologie de dveloppement des applications de contrle-commande doit assurerune qualit de ralisation en termes de fiabilit, defficacit, de maintenabilit,dvolutivit, etc.Il est important de noter quil nest pas possible de parler des applications de contrle-commande comme un ensemble homogne au sens de leur ralisation. En effet,

VI

entre les dveloppements de lapplication informatique grant un four micro-onde et celle pilotant une navette spatiale, la distance est immense : criticit delapplication, taille du logiciel, volution de lapplication Le seul lien en communest que toutes ces applications mettent en relation un programme informatiqueavec un procd externe.Dautre part, le dveloppement des applications de petite taille ou de taille moyennea souvent t conduit par des professionnels du monde de lautomatique ou dellectronique. 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 :schmas blocs, grafcets, etc. En effet, la spcification et la conception de tellesapplications sont plus aises lorsquelles sont penses en termes de fonctions ou detraitements des donnes. Aussi les langages ddis ce type dapplications sonttout naturellement des langages fonctionnels excution squentielle comme lelangage C, les assembleurs ou le langage flot de donnes LabVIEW.Dans le domaine informatique, en parallle, ces applications ont conduit la miseen place de mthodes de spcification ou de conception rpondant ces besoins,cest--dire des mthodes bases sur la description de laspect fonctionnel, soitlanalyse structure (SA), lanalyse structure temps rel (SA-RT), la conceptionstructure (SD), etc. Ces mthodes correspondent parfaitement ces besoins condition 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.En ce qui concerne les applications informatiques dites classiques (applicationsbureautiques, bases de donnes), des mthodes bases sur les donnes ont tlabores afin de rpondre un besoin fort de modlisation des donnes et de leursvolutions. Ces mthodes, dites orientes objets, permettent une spcification 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, unifies sous le nom UML (

UnifiedModeling Language

), sont devenues incontournables pour le dveloppement desapplications informatiques.Actuellement, ces mthodes orientes objets sont de plus en plus utilises dans ledomaine des applications de contrle-commande, domaine non concern initia-lement par ce type de modlisation objet. Il est concevable et acceptable de suivre unetelle dmarche pour des applications informatiques, mme de contrle-commande,de grande taille possdant souvent des donnes consquentes de type complexe.Mais il ne semble pas naturel de vouloir imposer ce type doutils pour des applica-tions de contrle de procds de petite ou moyenne taille ayant des donnes ennombre 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 efficacit. Ensuite les mthodes orientes objets vont

VII

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.

conduire des difficults pour passer ltape de limplmentation multitche ;cette rupture de la chane de dveloppement diminue fortement lintrt de cesmthodes de spcification 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 mthodesorientes objets largement rpandues aujourdhui, il semble contraire aux rglesdu 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 spcificit de ces applications en termes darchi-tectures logicielles et matrielles. Le second chapitre traite de la mthode de spci-fication 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 afin de mieux comprendre la partie implmentation de cessystmes de contrle-commande. Le chapitre 6 est ddi limplmentation desapplications de contrle-commande en dclinant trois environnements : noyau tempsrel et langage de type langage C, langage Ada et enfin un environnement spcifiquebas sur LabVIEW. Les prcdents chapitres sont illustrs par des exemples simplesmais ralistes ; en revanche, le chapitre 7 propose le dveloppement complet duneapplication relle industrielle. Enfin, 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

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.

1 DVELOPPEMENT DES SYSTMESDE CONTRLE-COMMANDE

1.1 Introduction

1.1.1 Dfinitions

Nous pouvons dfinir 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-tifiques (gestion de base de donnes, CAO, bureautique) qui ont des entresconstitues de donnes fournies par des fichiers ou ventuellement un oprateur.Les grandeurs physiques acquises permettent au systme de contrle-commandede piloter un procd physique quelconque. Donnons ainsi une dfinition gnraledun systme de contrle-commande (figure 1.1) :

Un systme de contrle-commande reoit des informations sur ltat duprocd externe, traite ces donnes et, en fonction du rsultat, value unedcision qui agit sur cet environnement extrieur afin dassurer un

tatstable

.

Cette notion dtat stable peut tre diffrente selon les applications ou procds.Il dpend du cahier des charges de lapplication (maintien dune temprature deconsigne, rgime moteur, qualit de service). Deux caractristiques font quunsystme de contrle-commande ne possde pas les proprits classiques des systmesdinformatiques scientifiques : indpendance du rsultat produit par rapport la vitesse dexcution. Le rsultat

dun 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 ;

comportement reproductible. Un calcul effectu partir de donnes dentreidentiques donne toujours le mme rsultat. En revanche, dans le cas de donnesdentre (grandeurs physiques) obtenues par des capteurs, le systme de contrle-commande travaille sur un domaine de donnes relles approximes qui sonttrs rarement identiques.

2

1.1 Introduction

1 Dveloppement dessystmes de contrle-commande

Linteraction du systme de contrle-commande avec le procd extrieur piloterse dcompose en deux parties (figure 1.2) : observations par lintermdiaire de capteurs (

sensors

) qui permettent dobtenirdes 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

(modification dtat phy-sique du systme) ou simplement sous la forme dun

affichage

(diodes, lampes,afficheurs, crans, etc.).

Cette dfinition 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

systmes interactifs

dans le sens o les donnes sont produites par inter-action avec lenvironnement sous diffrentes formes (clavier, fichier, rseaux,souris, etc.). Mais le temps nintervient pas en tant que tel si ce nest avec unaspect confort de travail ou qualit de service ;

les

systmes de contrle-commande

ou ractifs qui sont aussi en relation aveclenvironnement physique rel pour les donnes en entre ; mais, dans ce cas,

Systmede contrle-commande

Procdexterne

Systme informatiqueEntres

Sorties

Figure 1.1 Reprsentation schmatique dun systme de contrle-commande.

Procd externe piloter

capteur

Systme informatiquede contrle-commande

capteurcapteur

actionneur

MesuresInterruptions

CommandesAffichages

Figure 1.2 Reprsentation schmatique de linteraction du procd physique pilot et du systme de contrle-commande.

1.1 Introduction

3

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


laspect temps a une place importante sous la forme dun temps de raction,dune chance respecter, etc.

Nous terminons cette section par des dfinitions qualifiant des systmes de contrle-commande ayant des spcifications particulires. La premire de ces catgoriesconcerne les systmes temps rel (

real-time system

) dont la dfinition 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 :

contraintes temporelles relatives

ou lches (temps rel mou :

soft real-time

) :les fautes temporelles sont tolrables (ex. : jeux vido, applications multimdia,tlphonie mobile) ;

contraintes temporelles strictes

ou dures (temps rel dur :

hard real-time

) : lesfautes temporelles ne sont pas tolrables (ex. : avionique, vhicules spatiaux,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 qualificatifs suivants :

systme de contrle-commande

embarqu

(

embedded real-time system

) : pasdintervention humaine directe (pas de modification du programme ou des para-mtres du programme) ;


ddi

(

dedicated real-time system

) : les architec-tures matrielles ou logicielles sont spcifiques lapplication (noyau, processeur) ;

Donnes produites par lenvironnementPas de contraintes de temps

Synchronisationsou communications Aspect relation

entre entitsdu programme

Aspect temporel

Aspectcomportemental

Donnes produites par lenvironnementContraintes de temps

Proprits temporelles

Aspecttransformationnel

Systmesinteractifs

(ex. : bureautique, CAO)

Systmes ractifsou de contrle-commande

Systmestransformationnels

(ex. : code de calcul)Donnes linitialisationPas de contraintes de temps

Algorithmique

Figure 1.3 Comparaison des systmes de contrle-commande par rapport aux autres applications informatiques.

4

1.1 Introduction



rparti ou distribu

(

distributed real-timesystem

) : larchitecture matrielle est constitue de plusieurs processeurs relisentre eux par un bus ou un rseau.

Il est vident que ces diffrentes spcifications dun systme de contrle-commandepeuvent se combiner comme par exemple un systme de contrle-commandeddi, distribu et contraintes temporelles strictes (application pour un vhiculeautomobile).

1.1.2 Principales caractristiques des systmes de contrle-commande

Considrons un exemple reprsentatif dune application de contrle-commandereprsent sur la figure 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 acclrateur

Capteur temprature eau

Commandeallumage

Capteurtemprature air

Commandeinjecteur essence

Capteur vitesse de rotationdu vilebrequin

Capteurpollution en aval

Capteurpollution en amont

Communicationsavec les autrescalculateurs

Commande de r-injectiongaz chappement

Capteurpression collecteur

air

Calculateur

Commande admission air(papillon)

Bus CAN

Figure 1.4 Exemple dune application de contrle-commande dun moteur combustion.

1.1 Introduction

5

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


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 dela part du systme informatique davoir une ractivit suffisante pour prendreen 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(dveloppements srs, tests, mthodes formelles, prvisibilit, dterminisme,continuit de service, tolrance aux fautes, redondance, etc.).

1.1.3 Caractristique temporelle des systmes de contrle-commande

Le respect des contraintes temporelles dune application de contrle-commandedpend essentiellement de la dynamique du procd. Cette caractristique temporellepeut tre trs diffrente suivant lapplication (figure 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.

Application

Temps

Systmesradar

Systmesmesures

scientifiques100 ns

1 s

1 ms

1 seconde

1 minute

1 heure

10 ms

Contrleen chimie

Contrlefabrication

Contrlestockage

Systmesvocaux

Robotique

Figure 1.5 Comparaison de la dynamique de diffrentes applications de contrle-commande.

6

1.1 Introduction


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 dfinir de manire non exhaustive :

Dure

dexcution

dune activit : lactivit dune application, qui peut trelenchanement de plusieurs activits lmentaires (acquisition, traitement, com-mande, affichage), possde une dure dexcution qui peut tre mesure dediverses 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 fix 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 fin de lactivit.

Gigue temporelle

: ce paramtre caractrise la rptabilit dune activit au furet mesure de ses occurrences. En effet, entre deux excutions successives dunemme 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 :

Robot de production

: un robot, ralisant une activit spcifique (peinture,assemblage, tri) sur une chane de production, doit effectuer son travail en destemps fixs par la cadence de fabrication. Sil agit trop tt ou trop tard, lobjetmanufacturier trait sera dtruit ou endommag conduisant des consquencesfinancires ou humaines graves (oubli dun ou plusieurs rivets sur un avion).

Robot dexploration

: ce robot doit se dplacer dans un environnement enprincipe non connu (zone radioactive aprs un accident, plante, pave sous lamer). Il est important quil puisse ragir aux obstacles fixes ou mobiles afin dene pas conduire sa perte.

1.2 Architecture des applicationsde contrle-commande

7

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


Tlphone mobile

: le systme de contrle-commande doit remplir plusieursfonctions 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.

Systme de vidoconfrence

: 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. Afin de minimiser le dbit du rseau, une com-pression des images est effectue. Dautre part la parole doit aussi tre transmise.Bien que correspondant un dbit dinformation moindre, la rgularit de latransmission, qualifie par une gigue temporelle, est ncessaire pour une repro-duction correcte. De plus ce signal doit tre synchronis avec le flux dimages.Lensemble de ces traitements (numrisations images et parole, transmission,rception, synchronisation) sont raliss en cascade, mais avec une cohrenceprcise.

Pilotage dun procd de fabrication

(fonderie, laminoir, four verrier) : parexemple la fabrication dune bobine daluminium (laminage froid) exige uncontrle en temps rel de la qualit (paisseur et planit). Cette vrification enproduction de la planit ncessite une analyse frquentielle (FFT) qui induitun 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 affiche un compte rendu sur lcran de loprateurtoutes les 200 ms et enfin imprime ces rsultats dtaills toutes les 2 s. Un fonc-tionnement non correct de ce systme de contrle de la qualit peut avoir desconsquences financires importantes : production non conforme la spcificationdemande.

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 amne dcrire lenvironnement comme un systme fortement parallle. Cela conduitnaturellement 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 externe

8



est une

architecture multitche

. Ainsi, au paralllisme de lenvironnement, larponse est le paralllisme de conception. Nous pouvons dfinir 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.Dune manire trs gnrique, la figure 1.6 donne larchitecture logicielle duneapplication 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 externes

par 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-fier 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).

Liaisonrseau

Rseaux

SauvegardeRcupration

Units de stockage

Liaisonrseau

Liaisonrseau

OprateursProcdphysiqueexterne

Interfaceentres/sorties

Traitementsdes donnes

Interfacehomme/machine

Liaisonstockage

Mesures

Commandes

Consignes

Visualisation

Programmation multitche

Figure 1.6 Architecture logicielle dune application de contrle-commande multitche.


9

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


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 desinstants fixs. Cette sauvegarde peut tre utilise

a posteriori

pour analyser lefonctionnement de lapplication ou lors dune reprise dexcution une tapeprcdente.

Aprs lanalyse et la conception de lapplication, nous obtenons un ensemble detches ou activits qui cooprent afin 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-tionnel peut tre modifi dans certains cas en utilisant une conception tournevers 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 (figure 1.7) : synchronisation : cela se traduit par une relation de prcdence dexcution entre

les tches ; communications : la notion de prcdence, traduite par la synchronisation,

sajoute le transfert de donnes entre les tches ; partage de ressources : les tches utilisent des lments mis en commun au niveau

du systme comme des zones mmoire, des cartes dentres/sorties, cartes rseau,etc. Certaines de ces ressources, comme par exemple les zones mmoire, ne sontpas ou ne doivent pas tre accessibles, pour avoir un fonctionnement correct,par plus dune tche la fois, elles sont dites

ressources critiques

.

Ces diffrents concepts sont tudis de faon dtaille dans le chapitre 4.

R

Synchronisation

Ressourcecritique

SortieEntre

Tche 6Tche 4

Tche 7

Tche 8Tche 1

Tche 3

Tche 2 Tche 5

Figure 1.7 Reprsentation schmatique de larchitecture multitche dune application de contrle-commande.

10



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.

Tche dalarme qui se dclenche sur un vnement dalerte correspondant audpassement 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 demande son excution alors que la tche 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 fin de la tche Lecture_consigne (figure 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. Loccurrence

tempsClavier Alerte

Raction perue comme diffre par le procd

Raction perue comme immdiatepar le systme

Lecture_consigne

Alarme

Occurrencesmises

par le procd

Occurrencesobserves

par le systme

Application

Figure 1.8 Modle dexcution synchrone dune application de contrle-commande.


11

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


des vnements externes a donc t artificiellement synchronise avec le systmeinformatique, do le nom dexcution synchrone.Ce retard peut affecter la prise en compte de nimporte quel vnement, quellequen soit la gravit pour lapplication. Il faut donc vrifier que larchitecture op-rationnelle choisie permettra de prendre en compte les contraintes temporelles :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-diatement prise en compte par le systme pour tenir compte de lurgence ou delimportance. Dans lexemple propos, nous pouvons constater que la prise encompte dun signal dalerte est immdiate sans attendre la fin de la tche Lecture_consigne (figure 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 Alerte Les vnements sont immdiatement perus

par le systme

Suspension d'un traitement en cours

Alarme

Occurrencesmises

par le procd

Occurrencesobserves

par le systme

ApplicationLecture_consigne Lecture_consigne

Figure 1.9 Modle dexcution asynchrone dune application de contrle-commande.

12



Pour terminer cette section, nous allons rappeler trois dfinitions importantes quenous avons utilises et fixer le contexte de cet ouvrage. Nous avons ainsi dfini : Tche non premptible ou premptible :

Une tche non premptible ne peut tre interrompue qu des endroits spci-fiques et la demande de la tche elle-mme : fin_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.

Une tche premptible peut tre interrompue nimporte quel instant et leprocesseur 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 : Une analyse de lordonnancement hors ligne correspond la construction

dune squence dexcution complte sur la base des paramtres temporels destches en utilisant une modlisation (rseaux de Petri) ou une simulation(animation ou numration du modle). Lordonnanceur ncessaire est minimalpuisque la squence dexcution est prdfinie, il se rduit un squenceur.En revanche, lapplication ainsi fige est peu flexible.

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 dfini 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 spcifique, le noyau temps rel,que nous allons dcrire. Le point essentiel de cet environnement est lordonnanceurqui permet daffecter tout instant le processeur une tche afin de respecterlensemble des contraintes temporelles attaches la gestion du procd.

m Excutif ou noyau temps rel

Cet environnement particulier dexcution, excutif ou noyau temps rel, peut treassimil un systme dexploitation de petite taille ddi aux applications decontrle-commande. La caractristique fondamentale est son dterminisme dex-


13

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


cution avec des paramtres temporels fixs (temps de prise en compte dune inter-ruption, changement de contexte entre deux tches, etc.). Nous pouvons comparerles diffrences au niveau des objectifs fixs 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 desfluctuations temporelles (difficult pour dterminer prcisment les dures destches) ;

gestion des temporisateurs ou de lhorloge pas assez fine (plusieurs milli-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.

Un systme informatique de contrle-commande sattache aux caractristiquessuivantes :

efficacit 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 ;

possibilit de certification pour les applications de certains domaines commelavionique, lautomobile

En 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 dfinition 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. gestion des entres/sorties (gestion des interruptions, gestion des interfacesdentres/sorties, gestion des rseaux de communications) ;

2. ordonnancement des tches (orchestration du fonctionnement normal, surveil-lance, changements de mode, traitement des surcharges) ;

3. relations entre les tches (synchronisation, communication, accs une ressourcecritique en exclusion mutuelle, gestion du temps).

14



Il 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 delapplication selon lalgorithme dordonnancement utilis (figure 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 fin 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 (figure 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 temporelleassocie une tche comme le dpassement de la date limite dexcution ouchance. 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 spcifications fonctionnelles de lapplication.

m Implmentation des applications de contrle-commande

Comme nous le verrons au cours de cet ouvrage, les langages de dveloppement desapplications de contrle-commande sont trs divers. Mais, par rapport lenviron-nement dexcution que nous venons de dcrire (noyau temps rel avec les trois

Tche i Tche j Noyau

temps rel

Excutionprogramme

Excutionprogramme

Excutionprimitives et ordonnanceur

Requte Activation

Figure 1.10 Interaction entre les tches et le noyau temps rel.


15

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


fonctions dcrites : 1. gestion des interruptions, 2. ordonnancement, 3. relationsentre les tches), il est possible de dcliner les langages en trois groupes (figure 1.12) : langages standards (langage C) : le noyau temps rel qui supporte ce type de

langage doit tre complet puisque le langage nintgre aucune spcificit de cedomaine de contrle-commande multitche ;

langages multitches (langage Ada) : ces langages permettent de dcrirelapplication en termes de tches ; ainsi le noyau peut tre plus rduit et necomporter que les deux premires fonctions ;

Application

Tche i Tche j Tche k Tche x Tche yMesures Commandes

Noyau ou Excutif

Interruptions

Horlogetemps rel

Gestiondes interruptions

Gestiondu temps

Gestiondes vnements

ActivationRequte

Primitives

Ordonnanceur

Figure 1.11 Architecture de lapplication : tches et noyau temps rel.

Langagesstandards

(Langage C)

Noyau temps rel

Langagesmultitches

(Langage Ada)

Noyau temps rel

Langagesractifs

Noyau temps rel

11

2

1

2

3

Autrelangage

Figure 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).

16



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,tant donn la possibilit trs limite dexpression de laspect fonctionnel, ilssont souvent associs un langage standard pour palier ce manque.

1.2.2 Architecture matrielle des applications de contrle-commande

Comme 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-sit de systmes dentres/sorties et dautre part au matriel informatique parfoisspcifique et dvelopp pour une application donne. Ce dernier point concerne lesapplications dites ddies et embarques ; le matriel a t conu et cr spcifique-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 (figure 1.13). Dansces matriels, nous trouvons un processeur de type microcontrleur redond pouravoir un haut niveau de scurit, des composants spcifiques (ASIC : ApplicationSpecific Integrated Circuit), une alimentation lectrique Tout ce matriel est ensuiteencapsul dans un botier rsistant lenvironnement de fonctionnement usuel(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 matrielsspcifiques existent et permettent ce fonctionnement temporel : cest par exemplele cas de la plateforme PXI concatnation dune plateforme classique PC et de cartesdentres/sorties synchronises.Enfin, dans de nombreux cas, les applications de contrle-commande sont de typedistribu, cest--dire quelles sont composes de plusieurs sites ou processeurs, surlesquels sexcutent un environnement multitche, relis par un ou des rseauxinformatiques (Ethernet, CAN, FIP).Lensemble de ces aspects matriels est trait en dtail dans le chapitre 4.

17



D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.

Bo

tier

Les

calc

ulat

eurs

situ

s d

ans

des

parti

ese

xpos

es

son

t pla

cs

dans

des

bo

tiers

mt

alliq

ues

tan

ches

et b

lind

s.Ce

ux d

e lh

abita

cle s

ont e

n pl

astiq

ue.

Mm

oire

Stoc

ke le

s t

ches

util

isan

tle

mic

roco

ntr

leur

.

Hor

loge

Dt

erm

ine

la v

itess

e

de

xcu

tion

des

opr

atio

ns.

Elle

se

mes

ure

en m

gah

ertz

.

(50 M

Hz).

Mic

roco

ntr

leu

r de

scu

rit

Certa

ins

calcu

late

urs

(injec

tion,

ABS,

etc

.) disp

osen

t du

n m

icro

cont

rle

urde

sec

ours

(red

onda

nce).

Alim

enta

tion

Alim

ente

le c

alcu

late

ur e

n l

ectri

cit

en

dim

inua

nt la

tens

ion

en p

rove

nanc

ede

la b

atte

rie.

Mic

roco

ntr

leu

r

Exc

ute

les

diff

ren

tes

tch

esst

ock

es

en

mm

oire

.

ASI

C

Un A

SIC

(App

licat

ion

Spec

ific

Inte

gra

ted

Circ

uit) e

st un

e puc

e

ddi

e

u

ne

app

licat

ion

que

lle

ex

cute

dire

ctem

ent.

Am

plifi

catio

nde

s in

form

atio

ns d

en

tre

.

Figu

re 1

.13

M

atr

iel d

di

uti

lis

pour

impl

men

ter

une

appl

icat

ion

de c

ontr

le-

com

man

de d

u do

mai

ne d

e la

utom

obile

.

18

1.3 Dveloppement des applicationsde contrle-commande


1.3 Dveloppement des applications de contrle-commande

Le dveloppement des applications informatiques demande de plus en plus derigueur dans le suivi des diffrentes tapes de spcification, de conception et decodage. 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 faonsignificative 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, en revanche, dans le cas des applications de contrle-commande, les testsoprationnels en excution relle sont souvent difficiles produire cause de diversesparticularits :

excution unique : satellite dexploration ;

cot trs lev : fuse ;

risques humains : avion

Ainsi, malgr des phases de tests souvent coteuses et consquentes, de nombreusesapplications de contrle-commande nont pas rempli les objectifs fixs. 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 fauxdpart tait d une erreur de synchronisation entre les deux ordinateurs deconduite 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 robotPathfinder, 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 spcifiques 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

= =


19

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


modules logiciels utiliss dans le contexte dAriane IV. Les spcifications, attaches lacclration, auraient d tre diffrentes en termes de limites afin dviter cedysfonctionnement.

Cette liste dexemples de problmes au niveau de lexcution dapplications decontrle-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 informatiques

Le cycle de dveloppement des applications informatiques suit les trois tapes clas-siques que sont la spcification, 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 (figure 1.14) : spcification globale : description de ce que lon a faire ou le quoi ,

cest--dire une mise en forme plus ou moins formelle du cahier des charges ; conceptions prliminaire et dtaille : description du comment , cest--dire

une modlisation de larchitecture logicielle de lapplication (modules, tches,objets). Il peut tre ncessaire demployer diffrents niveaux de raffinementselon 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 raffinement, la traduction dans un langage de program-mation peut tre plus ou moins automatise.

Ces diffrentes tapes peuvent tre plus ou moins formelles selon les mthodesemployes. Aussi, chaque tape, il est primordial de vrifier la cohrence de ladescription ou de la traduction ralise partir de ltape prcdente. Ce travailconcerne la validation. Celle-ci constitue une preuve si la mthode est formelle ouun test si elle ne lest pas.

Cahierdes

charges

AnalyseAnalysedesdes

besoinsbesoins

Spcificationglobale

Conceptionsprliminaireet dtaille

Logiciel

Spcification ConceptionConception ProgrammationProgrammation

Validation externeValidation externe Validations internesValidations internes

Figure 1.14 Cycle de dveloppement dune application informatique classique.

20



Une prsentation gnralement plus adapte est celle du cycle en V (figure 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 ; spcification 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 une mthode qui est gnralement supporte par un outil informatiquepour 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, modifi-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 modifications 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 logiciel

Avant de dcrire les diffrentes mthodes utilises dans le cadre des applications decontrle-commande et leurs spcificits, 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 et

VALIDATION

INTGRATION

TESTS UNITAIRES

CODAGE

CONCEPTIONDTAILLE

CONCEPTIONPRLIMINAIRE

SPCIFICATION

Figure 1.15 Cycle de dveloppement en V dune application informatique classique.


21

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


les fonctions remplir par ce procd (figure 1.16). Ainsi, la spcification de lappli-cation commence par une spcification systme (matriel et logiciel). Une partie dela conception prliminaire peut aussi intgrer les deux aspects puisque la ralisationdun module fonctionnelle peut tre ralise soit de manire matrielle (circuitintgr spcifique FPLA : Field Programmable Logic Array ou FPGA : Field Pro-grammable Gate Array) soit dune manire logicielle. Ensuite, le dveloppement desdeux parties peut continuer de faon diffrencie et classique avec la conceptiondtaille, 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 difficile. En effet, une partie logicielle va tre insre dans unenvironnement matriel trs spcifique.Bien que ce ne soit pas le propos de cet ouvrage, laspect matriel est abord de faonsuccincte dans le chapitre 4. Au niveau de la conception, il existe aussi de nom-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 matrielspossdent une interface utilisateur trs spcifique comportant un ensemble de

CONCEPTIONDTAILLE

CONCEPTIONDTAILLE

CODAGE RALISATION

TEST TEST

INTGRATION

VALIDATION

Architectureoprationnelle

Logiciel Matriel+

Architecturelogicielle

ArchitecturematrielleCONCEPTIONPRLIMINAIRE

S P CIFICATIONSYSTME

Figure 1.16 Cycle de dveloppement matriel et logiciel dune application de contrle-commande de procd.

22



boutons, un haut-parleur et un cran couleur. De plus, ces consoles intgrent gnra-lement une liaison vers lextrieur de type infrarouge ou filaire 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 lescaractristiques suivantes : petite taille (taille mmoire limite), rapidit dexcution(ensembles de primitives simples), cot faible (ralisation en trs grande quantit)Ces diffrentes spcifications, 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 figure 1.17. Les spcifications 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), taille mmoire, dimension physique, consommation, environnement(temprature, pression, corrosion) ;

noyau temps rel : primitives, taille (micronoyau), certifi

Environnement de dveloppement

Logicielapplicatif

Noyautemps rel

Environnement dexcution

Spcifications du systme Aspect fonctionnel et aspect comportemental Autres contraintes de dveloppement :

matriel (processeur, architecture, taille, consommation) noyau temps rel langage de dveloppement

Logiciel

Matriel Logiciel

Figure 1.17 Environnement spcifique du dveloppement dune application de contrle-commande de procd.


23

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


langages de dveloppement : assembleurs, langage de haut niveau, 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. En effet, le comportement du programme dans cette architecture cible de lapplication peut tre diffrent et amener des modifications cons-quentes du programme. Ce processus conduit modifier 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 (figure 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 afin de pouvoir faire les premiers tests du logicielmultitche ralis ;

Dveloppementen environnement hte

SIMULATION VALIDATION

INTGRATIONavec noyau

TESTS

CONCEPTIONADAPTE

INTGRATION

SPCIFICATION

CONCEPTION

CODAGE CODAGE - Crois

Dveloppementen environnement cible

TESTS

Figure 1.18 Cycle de dveloppement en W dune application de contrle-commande de procd.

24



lenvironnement de dveloppement sur la plate-forme hte doit pouvoirfaire une compilation croise dans le code du processeur de larchitecture cible ;

lenvironnement de dveloppement sur la plate-forme hte doit permettreun debug de lapplication lors de son excution sur larchitecture 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 difficult rside dans lefait de ne pas modifier lexcution de lapplication par cette observation.

Toutes ces remarques impliquent dans le choix dun environnement de dveloppe-ment de ces applications de prendre en compte lensemble des caractristiquessuivantes :

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-commande

Il existe de nombreuses mthodes appliques au dveloppement logiciel des appli-cations de contrle-commande de procd. Ces mthodes couvrent une ou plusieurstapes du cycle de dveloppement selon les niveaux de raffinement o elles sontutilises. Sans vouloir faire un expos exhaustif de lexistant, il est intressant deciter quelques mthodes en les diffrenciant par leur concept de base. Nous trouvonsainsi des mthodes fonctionnelles et structures, dites aussi flots 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 vrifications plus avances que les prcdentes. La troi-sime catgorie, plus rcente, de mthodes est dite oriente objets ou objets. Nouspouvons rsumer ces dernires en disant que ces mthodes mettent en avant lesdonnes et leur structuration. Nous pouvons donner les exemples suivants danschacun de ces ensembles :


25

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.1 Dveloppement des


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 : Specification 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) Langages ractifs synchrones : Lustre (Caspi, 1991), Esterel (Berry, 1991),

Signal (le Guernic, 1991)

Mthodes objets ou orients objets :

UML : Unified Modeling Language (OMG, 1995) HOOD : Hiearchical Object Oriented Design (CRI-Cisi Ingnierie-Matra, 1987)

La figure 1.19 reprend le cycle en V de dveloppement avec le positionnementde quelques-unes de ces mthodes dans ce cycle.

Comme cela a t justifi et expliqu dans lavant-propos, les mthodes SA-RT etDARTS, qui permettent de dcrire compltement le cycle dans ses phases de sp-cification 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.

DARTSStateChartsGRAFCET

HOOD

SA-RTDARTSMSMC

StateChartsUM

HOOD

SA-RT MSMC

StateChartsUML

CODAGE

CONCEPTIONDTAILLE TESTS UNITAIRES

VALIDATION

CONCEPTIONPRLIMINAIRE

SPCIFICATION

INTGRATION

Figure 1.19 Quelques mthodes de dveloppement dune application de contrle-commande de procd.

26



1.3.4 Quelques exemples industriels dapplications de contrle-commande

Afin 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) Spcifications et conceptions : HOOD Langages : Ada, Assembleur

Programme Ariane 5 (Arospatiale/CNES) : lanceur Spcifications 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 Spcifications 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 Spcifications et conceptions : SART et Ada-Buhr (proche de la mthode

DARTS) Langages : Ada (1 000 000 lignes), C (400 000 lignes)

Programme Rafale (Dassault lectronique) : avion militaire Spcifications 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 justifie une mthode oriente objet.

27

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.

2 SPCIFICATIONSELON LA MTHODE SA-RT


La mthode SA-RT est une mthode danalyse fonctionnelle et oprationnelle desapplications de contrle-commande. Cette mthode permet de raliser une des-cription graphique et textuelle de lapplication en termes de besoins, 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 (ensembledes documents laborer) et lexpression (syntaxe graphique) sont dfinies. Enrevanche, elle ne permet pas deffectuer une vrification de proprits de lapplication partir des seules descriptions SA-RT. Des tudes ont t menes pour associer lamthode SA-RT des mthodes formelles afin dapporter des possibilits de simulationet de vrification. Une de ces mthodes est prsente la fin du chapitre. Aucunergle officielle 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-cifiques 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 efficace 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 flux ou flots de donnes, de contrle ou autres. Laspectoprationnel de la description est alors visualis par la propagation de ces flux.Ainsi, nous trouvons la mthode SA-DT (

Structured Analysis Design Technics

) despcification dun systme qui permet dexprimer un bloc reprsentant soit lesactivits (fonctions) soit les donnes. Les flots entrants sont les donnes, un contrleou des mcanismes (mthodes) et les flots sortants correspondent aux sorties de

28


2 Spcificationselon la mthode SA-RT

donnes. Cette mthode trs gnrale de description dun systme a t adapte la spcification de logiciels avec la mthode trs connue SA (

Structured Analysis

)(figure 2.1).

Lanalyse structure SA, dfinie par E. Yourdon et T. Demarco, est une mthodedescendante par affinages successifs des traitements, appels process . Les diffrentsdiagrammes sont donc ordonns hirarchiquement en faisant apparatre pour lesderniers niveaux des fonctions lmentaires, appeles primitives lmentaires ou process primitifs. Les diffrents outils composant cette mthode sont :

diagrammes de transformations de donnes ou diagramme de flots de donnes(DFD) ;

dictionnaire de donnes ;

spcifications des process primitifs.

Les diagrammes de flots de donnes sont construits partir de quatre lmentsgraphiques : traitement (cercle), flot de donnes (flche), 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 flotsde donnes. Un exemple, prsent sur la figure 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 flotsde donnes de SA manquait dun moyen permettant de spcifier laspect oprationnel,

Spcificationdun systme

Spcificationstatique

dun logiciel

Spcificationdynamique

dun logiciel

SADT

SA

SA-RT

ESML

Structured 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.


29

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


cest--dire la description de lenchanement des diffrents process. Cette lacunefut comble par la cration de mthode SA-RT (

Structured Analysis-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, lamthode propose par Hatley et Pirbhai en 1986 qui spare le fonctionnel et lecontrle. Mais ces deux vues de la mme mthode restent trs similaires en termes decapacit dexpression de la spcification. Nous prsentons dans cet ouvrage lamthode SA-RT tablie par Ward et Mellor en 1985.Comme le montre la figure 2.1, la mthode SA-RT a continu voluer au seindes entreprises en intgrant des besoins spcifiques un domaine dapplications.Ainsi, nous trouvons une mthode SA-RT, appele ESML et utilise dans lavionique,qui a t enrichie dun point de vue flot 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 + nom

Flot de donnes Vecteur nomm reliant deux process, sur lequel circule un ensemble de donnes de mme nature

Flche en trait plein Donne nomme

Unit de stockage ou rservoir

Entit ou zone de rangement de donnes

Deux traits parallles Entit nomme

Entit externe ou terminateur

Provenance, source ou destination des donnes

Rectangle Entit nomme

AcqurirMesures

Mesures

Mesures

Capteur

Tension lue Temprature Tension_commande

Temprature_consigne Commande_chauffage

Thermistance Commanderchauffage

Acqurirtemprature

Rsistancechauffante

Tmoinde chauffage

Figure 2.2 Exemple simple du diagramme flot de donnes de la mthode SA correspondant une application de rgulation de temprature.

30

2.2 Prsentation de la syntaxe graphiquede la mthode SA-RT


La mthode SA-RT intgre les trois aspects fondamentaux dune mthode de spci-fication 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 spcification des processus quitransforment les donnes ;

aspect vnementiel

(pilot par les vnements) : reprsentation des vnementsqui conditionnent lvolution dun systme et spcification de la logique decontrle qui produit des actions et des vnements en fonction dvnements enentre et fait changer le systme dtat ;

aspect informationnel

(donnes) : spcification des donnes sur les flots ou dansles stockages. Ce dernier aspect qui est en gnral assez nglig dans ce type dappli-cation peut faire lobjet dune description spcifique 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 flux de donnes en entressont traits pour donner un ou plusieurs flux de donnes en sortie (figure 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 flot de donnes est reprsent par un arc orient avec une tiquetteou label explicite form de (figure 2.4) :

tiquette_Flot_de_Donnes

nom (+ qualifiant)

Les valeurs de ce flot de donnes sont supposes disponibles pendant tout le tempso le processus producteur de ce flot est en mesure de les gnrer.Le flot de donnes peut reprsenter aussi bien une donne de type continu, code parun entier ou un rel (

Temprature

) quune donne discrte code par un boolen,

=

=

2.2 Prsentation de la syntaxe graphiquede la mthode SA-RT

31

D

unod

L

a ph

otoc

opie

non

aut

oris

e es

t un

dlit

.


exemple

Position_interrupteur

. Un flot de donnes peut dcrire aussi bien unedonne lmentaire ou unique, exemple

Temprature

quune donne structureintgrant plusieurs donnes lmentaires, exemple la donne

Pressions

qui estcompose de

Pression_huile

et

Pression_air

. Il est alors possible de faire appa-ratre ltiquette du flot de donnes sous la forme suivante :

tiquette_Donne_Structure

tiquette_Donne_1

,

tiquette_Donne_2

Une spcification dtaille de cette donne, vhicule par le flot de donnes, est faitedans le

Dictionnaire de donnes

(voir ci-aprs).

Mesurertemprature

1

Commandervanne

2

Calculermoyenne

3

Lecturede donnes

criturede donnes

Transformationd

Systèmes temps réel

Documents

Transcript of Systèmes temps réel