Technique de L'ingénieur [PDF]

Zitiervorschau

AU TO M AT I Q U E - R O B OT I Q U E

Ti660 - Automatique et ingénierie système

Supervision des systèmes industriels Réf. Internet : 42396 | 2nde édition

Actualisation permanente sur www.techniques-ingenieur.fr

Tec h n ique s de l ’I n gé ni eur La plus impor tante ressource documentaire scientifique et technique en français

Une information fiable, claire et actualisée Validés par un comité scientifique et mis à jour en permanence sur Internet, les articles Techniques de l’Ingénieur s’adressent à tous les ingénieurs et scientifiques, en poste ou en formation. Outil d’accompagnement de la formation et de la carrière des ingénieurs, les ressources documentaires Techniques de l’Ingénieur constituent le socle commun de connaissances des acteurs de la recherche et de l’industrie.

Les meilleurs experts techniques et scientifiques Plus de 200 conseillers scientifiques et 3 500 auteurs, industriels, chercheurs, professeurs collaborent pour faire de Techniques de l’Ingénieur l’éditeur scientifique et technique de référence. Les meilleurs spécialistes sont réunis pour constituer une base de connaissances inégalée, vous former et vous accompagner dans vos projets.

Une collection 100 % en ligne • Accessibles sur www.techniques-ingenieur.fr, les dernières nouveautés et actualisations de votre ressource documentaire • Les articles téléchargeables en version PDF

Des services associés Rendez-vous sur votre espace « Mon compte » en ligne pour retrouver la liste des services associés à vos droits d’accès et les utiliser.



Des services associés Pour toute information, le service clientèle reste à votre disposition : Tél : 01 53 35 20 20 l Fax : 01 53 26 79 18 l Mail : [email protected]

III

Cet ouvrage fait par tie de

Automatique et ingénierie système (Réf. Internet ti660) composé de  : Modélisation et analyse de systèmes asservis

Réf. Internet : 42391

Régulation et commande des systèmes asservis

Réf. Internet : 42394

Automatique avancée

Réf. Internet : 42393

Automatique séquentielle

Réf. Internet : 42395

Supervision des systèmes industriels

Réf. Internet : 42396

Systèmes d'information et de communication

Réf. Internet : 42397



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires

IV

Cet ouvrage fait par tie de

Automatique et ingénierie système (Réf. Internet ti660) dont les exper ts scientifiques sont  : Pierre VIDAL Professeur honoraire des universités

Chékib GHARBI Directeur du Centre d'Innovation des Technologies sans Contact (CITC EuraRFID), Lille

Christian TAHON Professeur à l'Université de Valenciennes et du Hainaut Cambrésis (UVHC)

Étienne DOMBRE Directeur de Recherche Émérite du CNRS au LIRMM, UMR 5506 Université Montpellier-CNRS

Éric BONJOUR Professeur à l'université de Lorraine / ENSGSI, Vice-président Enseignement -Recherche de l'AFIS

Dominique LUZEAUX Ingénieur général de l'armement, HDR



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires

V

Les auteurs ayant contribué à cet ouvrage sont :

Philippe ALLOT

Emmanuel GROLLEAU

Frédéric PÉTROT

Pour les articles : S8005 – S8006

Pour les articles : S8055 – S8057 – S8059

Pour l’article : H8200

Arona AW Pour l’article : S7610

Michaël RICHARD Pour l’article : S8070

Pour les articles : S8055 – S8057 – S8059

Roger D. HERSCH

Pascal RICHARD

Pour l’article : S8035

Pour les articles : S8055 – S8057 – S8059

Sébastien GÉRARD

Fathi BOUDRA Pour l’article : S8058

Henri BRENIER Pour l’article : S8100

Jean-Marie HUOT Pour l’article : S8090

Frédéric RIDOUARD

Robert JAY

Pour les articles : S8055 – S8057 – S8059

Xavier CORNU Pour l’article : S8068

Pour l’article : S8058

Francis COTTET Pour l’article : S8056

Jean-Claude ROUHET Sylvie JONAS

Pour l’article : S7610

Pour l’article : S8104

Joëlle DELACROIX Pour l’article : S8056

Nicolas JOUVRAY

Moamar SAYED MOUCHAWEH

Pour les articles : S8030 – S8031

Pour l’article : BE6001

Claude KAISER

François TERRIER

Pour l’article : S8056

Pour l’article : S8070

Zoubir MAMMERI

Arnaud TESSALONIKOS

Pour l’article : S8056

Pour l’article : S8090

Jacky MONTMAIN

Yvon TRINQUET

Pour l’article : S7620

Pour les articles : S8050 – S8052

Edouard PIEGAY

Matthieu VIAL

Pour l’article : S8102

Pour l’article : S8058

Michel PINARD

Élisabeth WALTI

Pour les articles : S8205 – S8206

Pour l’article : R8080

Claude DELANNOY Pour les articles : S8065 – S8066

Henri DELEBECQUE Pour l’article : S8063

David DUBOIS Pour l’article : S8032

Daniel DUPONT Pour l’article : S8032

Pierre FICHEUX Pour l’article : H1570



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires

VI

Supervision des systèmes industriels (Réf. Internet 42396)

SOMMAIRE 1– Méthodes fonctionnelles et outils

Réf. Internet

Présentation du MES. Pilotage et suivi des fabrications pensés comme un système intégré

S8005

11

Exemple d'application MES. Cas du projet BIOPROD du groupe SARIA

S8006

13

Protection des systèmes de contrôle-commande contre les cyberattaques

BE6001

15

2– Systèmes d'exploitation temps réel

Réf. Internet

Systèmes d'exploitation temps réel. Principes

S8050

21

Systèmes d'exploitation temps réel - Exemples d'exécutifs industriels

S8052

27

Ordonnancement temps réel. Ordonnancement monoprocesseur

S8055

31

Ordonnancement temps réel. Ordonnancement réparti

S8056

37

Ordonnancement temps réel. Ordonnancement multiprocesseur

S8057

43

Linux pour le temps réel

S8058

47

Ordonnancement temps réel. Ordonnancement centralisé

S8059

51

3– Technologies logicielles et programmation

Réf. Internet

Langages de programmation pour systèmes automatisés : norme CEI 61131-3

S8030

59

Norme CEI 61499 : programmation distribuée et événementielle des procédés

S8031

65

Réalisation technologique du GRAFCET

S8032

67

Microcontrôleurs  : principes et aspects temps réel

S8035

73

Approche objet

S8063

79

Programmation en langage C++. Concepts

S8065

83

Programmation en langage C++. Exemples

S8066

87

Linux embarqué

H1570

89



page

page

page

Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires

VII

OS embarqués

H8200

93

Java dans les systèmes embarqués et temps réel

S8068

97

UML pour temps réel

S8070

101

Qualité des logiciels industriels

R8080

105

Contrefaçon de logiciel

S8090

109

Spéciications fonctionnelles. Génération automatique de code

S8100

115

Programmation graphique des applications de contrôle-commande. Notions générales et langage G

S8205

121

Programmation graphique des applications de contrôle-commande. Logiciel LabVIEW et applications industrielles

S8206

127

4– Interaction homme-machine

Réf. Internet

Ergonomie. Système homme-machine

S7610

135

Supervision homme-machine

S7620

139

5– Exigences contractuelles

Réf. Internet

Expertise judiciaire en informatique industrielle

S8102

147

Les contrats informatiques

S8104

149



page

page

Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires

Supervision des systèmes industriels (Réf. Internet 42396)

Ｑ 1– Méthodes fonctionnelles et outils

Réf. Internet

Présentation du MES. Pilotage et suivi des fabrications pensés comme un système intégré

S8005

11

Exemple d'application MES. Cas du projet BIOPROD du groupe SARIA

S8006

13

Protection des systèmes de contrôle-commande contre les cyberattaques

BE6001

15

page

2– Systèmes d'exploitation temps réel 3– Technologies logicielles et programmation 4– Interaction homme-machine 5– Exigences contractuelles



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires Ｙ

Ｑ

ＱＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＰＵ

Pre´sentation du MES Pilotage et suivi des fabrications pense´s comme un syste`me inte´gre´ par

Ｑ

Philippe ALLOT Inge´nieur de l’E´cole Centrale de Paris PDG d’ORDINAL Software

1. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10

ˆ le de´cisif du standard ISA-95 (IEC 62264) ........................ Le ro La gene`se du MES – les onze fonctions ............................................ L’ISA et les objectifs de l’ISA-95 ........................................................ Le mode`le fonctionnel de l’ISA-95 .................................................... Relation avec les niveaux du CIM...................................................... Le mode`le objet d’e´change ................................................................ La hie´rarchie des e´quipements .......................................................... Le mode`le ope´rationnel (mode`le d’activite´s) .................................... Les e´changes avec le niveau 4 du CIM (ERP/GPAO) ......................... La fusion ISA-95/ISA-88 ..................................................................... Inte´gration verticale et standardisation .............................................

2. 2.1 2.2 2.3 2.4 2.5 2.6

Typologie des logiciels de MES .................................................... L’importance des proce´de´s cible´s ...................................................... Approche spe´cifique (me´tier) ............................................................ Assemblage de logiciels diffe´rents .................................................... Approche hybride ............................................................................... Progiciels inte´gre´s .............................................................................. Inte´gration MES et supervision .........................................................

— — — — — — —

6 6 6 6 7 7 7

3. 3.1 3.2 3.3 3.4 3.5

Le de´ploiement d’un MES.............................................................. Un projet informatique ...................................................................... Technologies mises en œuvre ........................................................... Compe´tences requises ....................................................................... Facteurs de succe`s et causes d’e´chec ............................................... Capitalisation et « mode`le cœur » .....................................................

— — — — — —

8 8 8 8 8 9

4.

Conclusion........................................................................................

—

9

Pour en savoir plus..................................................................................

S 8 005 – 2 — 2 — 2 — 3 — 3 — 4 — 4 — 4 — 5 — 5 — 5

Doc. S 8 005

e quel fournisseur provenait le colorant utilise´ dans ce yaourt refuse´ par le controˆle qualite´ ? L’e´quipe du matin est-elle plus performante que celle de l’apre`s-midi ? La cuve de me´lange ayant servi a` la pre´paration des produits du 13/9 avait-elle e´te´ lave´e ? Combien de points de productivite´ perdons-nous sur la ligne 4 a` cause des re´glages ? Avons-nous le temps de passer la promo avant la livraison pre´vue pour demain matin ? Les ope´rateurs pre´fe`rent utiliser la machine SESKA pour ce produit car elle connait moins de proble`mes, mais n’est-on pas perdant au global ? Voila` le genre de questions auxquelles un MES (Manufacturing Execution System) va tenter de re´pondre. Et tre`s rapidement, les industriels ont pu s’apercevoir que ni les syste`mes dont ils disposaient pour la production (controˆlecommande et supervision), ni les progiciels de gestion, en particulier les ERP (Enterprise Resource Planning) ne le permettaient. Il y avait donc bien un domaine non couvert. Au de´but des anne´es 1990, une association ame´ricaine a cre´e´ le terme de Manufacturing Execution System pour de´signer ce nouveau domaine, qui a

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｪｵｩｮ＠ＲＰＱＱ

D

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＱＱ

S 8 005 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＰＵ PRE´SENTATION DU MES ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

pas inde´pendantes et se´parables, mais forment un tout. La figure 1 montre comment les taˆches ge´ne´ralement identifie´es dans le MES peuvent s’organiser en fonctions ope´rationnelles et en services transversaux, susceptibles d’eˆtre utilise´s par toutes les fonctions ope´rationnelles.

1. Le roˆle de´cisif du standard ISA-95 (IEC 62264) 1.1 La gene`se du MES – les onze fonctions

1.2 L’ISA et les objectifs de l’ISA-95

Les premiers pas du MES se sont traduits par l’identification par le MESA de onze fonctions qu’il e´tait amene´ a` couvrir (voir encadre´). Pendant longtemps, ces onze fonctions ont pratiquement servi de de´finition au MES lui-meˆme. Le pe´rime`tre du MES e´tait-il clarifie´ ? En fait, pas tant que cela.

L’ISA, pre´sente´e en introduction, est une association ame´ricaine ` l’origine tourne´e vers forte de 39 000 membres de l’industrie. A l’instrumentation, elle a e´tendu le champ de ses travaux a` l’ensemble de l’automation, et est a` l’origine de nombreux standards inde´pendants, dont un nombre conse´quent a e´te´ repris au niveau europe´en sous les de´nominations IEC. Cela a e´te´ le cas en particulier pour le standard ISA-95, repris au niveau europe´en sous la de´nomination IEC 62264.

Les onze fonctions du MES – Gestion des ressources – Ordonnancement – Cheminement des produits et des lots – Gestion des documents – Collecte et acquisition de donne´es – Gestion du personnel – Gestion de la qualite´ – Gestion du proce´de´ – Gestion de la maintenance – Trac¸abilite´ produit et ge´ne´alogie – Analyse des performances

Gestion des ressources Cheminement des produits et des lots

Le second proble`me est plutoˆt se´mantique. En de´finissant le MES par la liste des fonctionnalite´s qu’il est suppose´ assurer, on laisse penser que le tout se re´sume a` la somme de ses parties. Or, la plupart des fonctions liste´es ont e´te´ mises en œuvre avant la cre´ation du terme MES, meˆme partiellement. Ainsi, un grand nombre d’industriels ont utilise´ le MES sans le savoir.

Interface homme/machine Collecte et acquisition des données Gestion des documents

Mais l’on passe a` cote´ de l’essentiel de´fini dans le terme meˆme de MES, et que les initiales tendaient a` faire oublier. La seconde lettre du sigle de´signe en effet l’exe´cution : les fonctions du MES sont orchestre´es autour d’un processus central qui est l’exe´cution des fabrications, c’est-a`-dire l’enchaıˆnement des ope´rations qui aboutissent a` la fabrication des produits. La troisie`me lettre du sigle de´signe un syste`me. Or, dans un syste`me, les fonctions ne sont

S 8 005 – 2

Analyse des documents Traçabilité

Figure 1 – Le MES est un syste`me (source ORDINAL)

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＱＲ

Maintenance

Gestion procédé

Services

Qualité

Opérations

Gestion du personnel

Le premier proble`me tient aux fonctions e´nume´re´es dans l’encadre´. On distingue en effet la gestion des ressources et la gestion du personnel. Mais du point de vue de l’informatique industrielle, le personnel n’est-il pas une ressource ? Le MES aurait pour fonction la Gestion des documents ; cela veut-il dire que toute la gestion des documents d’une entreprise doit eˆtre prise en charge par le MES ? Claire a` premie`re lecture, on voit que cette de´finition du MES preˆte a` beaucoup d’ambiguı¨te´s.

Suivi

Les objectifs de l’ISA-95 sont multiples. Un premier, en apparence modeste, a e´te´ de faire partager aux industriels une terminologie commune pour les notions manipule´es par le MES. En effet,

Ordonnancement

Ｑ

d’ailleurs donne´ son nom a` l’association elle-meˆme (MESA). Le MESA s’est aussi fait connaıˆtre par les « onze fonctions du MES » que nous verrons par la suite. Ne´anmoins, arrive´ nettement apre`s les autres logiciels, le MES a d’abord paˆti de cette situation. Un peu comme dans les auberges espagnoles d’antan, ou` les clients apportaient eux-meˆmes a` manger, les industriels ont cherche´ a` de´finir comme appartenant au MES tout ce qu’ils ne trouvaient pas dans leurs outils existants… Aujourd’hui, comme nous allons le voir, graˆce a` des travaux importants tels que ceux mene´s par l’ISA (International Standard of Automation), et aux efforts de recherche des e´diteurs de logiciels, le MES a re´ellement pris sa place dans la palette des outils indispensables de l’entreprise pour relever ses de´fis.

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＰＶ

Exemple d’application MES Cas du projet BIOPROD du groupe SARIA par

Ｑ

Philippe ALLOT Inge´nieur de l’E´cole centrale de Paris PDG d’Ordinal Software

1.

Enjeux industriels du projet..........................................................

AF S 8006 – 2

2. 2.1

2.3

Sites du projet ................................................................................. Proce´de´ de broyage de viande .......................................................... 2.1.1 Ge´ne´ralite´s ............................................................................... 2.1.2 Recette ..................................................................................... 2.1.3 E´quipements de process ......................................................... 2.1.4 De´roulement du proce´de´ ......................................................... Proce´de´ de se´paration me´canique de viande (volaille) .................... 2.2.1 Ge´ne´ralite´s ............................................................................... 2.2.2 Recette ..................................................................................... 2.2.3 E´quipements de process ......................................................... 2.2.4 De´roulement du proce´de´ ......................................................... Commentaire sur les niveaux d’automatisation ...............................

— — — — — — — — — — — —

2 2 2 2 2 2 3 3 3 3 3 3

3. 3.1 3.2 3.3

De´marche de de´ploiement ............................................................ Pe´rime`tre fonctionnel ......................................................................... Core model et capitalisation initiale .................................................. Ge´ne´ralisation de la solution .............................................................

— — — —

4 4 4 4

4.

Re´sultats et conclusion .................................................................

—

4

2.2

Pour en savoir plus..................................................................................

Doc. S 8 006

e Groupe SARIA est un acteur majeur dans la valorisation de la biomasse. Ce domaine s’inscrit parfaitement dans les de´marches actuelles de pre´servation maximale des ressources alimentaires, ainsi que de valorisation e´nerge´tique des de´chets. Pousse´ par son de´veloppement, le groupe a engage´ une de´marche de modernisation et d’extension portant sur l’ensemble de ses sites lui permettant d’anticiper les exigences les plus se´ve`res en termes de se´curite´, de qualite´ et de trac¸abilite´, tout en ame´liorant le niveau de performance de ses installations. Le de´ploiement de ce projet, de´ja` en production sur un nombre significatif de sites, est un excellent exemple des de´marches de capitalisation qui peuvent eˆtre mises en place dans le cadre d’un projet MES en s’appuyant sur une forte base technologique.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠､￩｣･ｭ｢ｲ･＠ＲＰＱＱ

L

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＱＳ

S 8 006 – 1

Ｑ

ＱＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｂｅＶＰＰＱ

Protection des systèmes de contrôle-commande contre les cyberattaques Par

Ｑ

Moamar SAYED MOUCHAWEH Professeur titulaire Institut des Mines-Telecom (IMT) Lille Douai, Douai, France

1.

Systèmes de contrôle-commande industriels comme systèmes cyberphysiques ......................................................

2. 2.1 2.2 2.3

Cyberattaques contre les systèmes de contrôle-commande industriels..................................................... Classification des cyberattaques ............................................................... Exigences pour des systèmes sûrs............................................................ Évaluation et mesures de l’impact des cyberattaques ............................

— — — —

5 5 5 6

3. 3.1 3.2 3.3

Détection des cyberattaques ............................................................... Détection d’intrusion par des modèles ..................................................... Détection d’intrusion par signatures ......................................................... Détection d’intrusion par anomalies .........................................................

— — — —

7 8 9 11

4.

Conclusion et discussion ......................................................................

—

13

5.

Glossaire ....................................................................................................

—

13

Pour en savoir plus .........................................................................................

BE 6 001 - 2

Doc. BE 6 001

es systèmes de contrôle-commande industriels (SCI) sont des systèmes cyberphysiques qui combinent des couches de calcul, de communication et de physique afin de réaliser un ensemble de tâches. Ils sont utilisés pour surveiller et contrôler des installations, services, processus, applications et systèmes tels que la production et la distribution d’énergie (électricité, gaz, etc.), les réseaux de transport, les systèmes de communication avancés, etc. L’utilisation de ces systèmes devient plus critique dans le contexte de la transition énergétique en raison de la taille importante et croissante des communications et des échanges de données et d’informations entre les consommateurs et les opérateurs du réseau électrique en fonction de multiples services fournis (micro-réseaux, gestion de la demande, etc.). Par conséquent, le rôle des systèmes de contrôle-commande industriels devient essentiel puisqu’ils surveillent la stabilité et la fiabilité de la production et de la distribution d’énergie, optimisent la consommation et la production d’énergie à des échelles centralisées/distribuées, renforcent l’impact de l’énergie renouvelable dans le réseau, etc. Cependant, les SCI sont vulnérables aux cyberattaques, dans la mesure où ils sont conçus pour effectuer des tâches de production prédéfinies et répondre aux défis de la sécurité sans se soucier des problèmes de la sûreté. Ces attaques modifient la programmation du contrôleur pour endommager gravement l’équipement physique. L’attaque Stuxnet contre le programme nucléaire iranien en est un bon exemple. Elle a modifié le programme de contrôle des centrifugeuses d’enrichissement de l’uranium pour les forcer à tourner trop rapidement et trop longtemps, et entraîner leur destruction. Il est donc primordial de déve-

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｯ｣ｴｯ｢ｲ･＠ＲＰＱＹ

L

Copyright © – Techniques de l’Ingénieur – Tous droits réservés

ＱＵ

BE 6 001 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｂｅＶＰＰＱ PROTECTION DES SYSTÈMES DE CONTRÔLE-COMMANDE CONTRE LES CYBERATTAQUES ________________________________________________________

Ｑ

lopper un système de détection de cyberattaques capable de détecter le plus tôt possible ces attaques pour en arrêter ou en limiter les conséquences catastrophiques sur l’équipement physique critique. Le présent article se penche sur le problème de la détection et de l’atténuation des risques représentés par la cyberattaque au sein des SCI, dans le contexte de la transition énergétique. Il abordera tout d’abord la structure d’un système cyberphysique et les composants de ses cybercouches et couches physiques. Il classera ensuite les différentes cyberattaques en fonction des composants d’un système cyberphysique et évaluera leurs impacts sur l’intégrité et les performances du système. Enfin, l’article classera les approches permettant de concevoir un système de détection des intrusions. Ces méthodes sont regroupées en trois familles principales : approche basée sur les modèles, approche basée sur les signatures, et détection des anomalies. Les avantages et les inconvénients de ces approches sont traités selon le type d’attaque et les informations sur la structure du système dont dispose le pirate. Un exemple de système cyberphysique composé d’une pompe, d’une soupape, d’un réservoir, de capteurs, et d’un contrôleur servira dans cet article pour illustrer les différents concepts et méthodes présentés.

1. Systèmes de contrôlecommande industriels comme systèmes cyberphysiques

Prenons l’exemple d’un SCI simple présenté sur la figure 2. Le domaine physique se compose de deux actionneurs (pompe P et soupape V), d’un réservoir T, et de deux capteurs, L1 pour indiquer le niveau haut du réservoir, Lh = 35 cm3, et L2 pour indiquer le niveau bas du réservoir, Lw = 5 cm. Le tableau 1 présente les valeurs numériques de cet exemple. Lorsque L1 = 1, ou L2 = 1, le niveau de liquide dans le réservoir est haut, ou bas. La section transversale S du réservoir est égale à 10 cm2, le débit Qp de la pompe est de 20 cm3/sec, et le débit Qv de la soupape de 10 cm3/sec. Le niveau maximal du réservoir est Lmax = 45 cm. La séquence de contrôle est définie comme ci-après (figure 3). À l’étape 0, la pompe est à l’arrêt, la soupape fermée, et le niveau de liquide dans le réservoir est bas (L2 = 1, L1 = 0). Étape 1 : le contrôleur envoie la commande « Démarrage de la pompe ». Étape 2 : le liquide dans le réservoir quitte le niveau bas (L2 = 0). Étape 3 : le liquide dans le réservoir atteint le niveau haut indiqué par le capteur L1 (L1 = 1).

Les systèmes cyberphysiques [1], [2] font référence à l’application des éléments de calcul et de la technologie de communication embarquée dans les multiples composants et processus physiques dans différents domaines, tels que le transport, la fabrication, les systèmes d’alimentation électrique, l’infrastructure civile, la santé, la chimie, l’aérospatiale, etc. Le cyberdomaine comporte des éléments (matériel/logiciel) réalisant des calculs permettant une communication en duplex intégral, et des actions de contrôle. Le domaine physique comprend des actionneurs, capteurs et tout système naturel créé par l’homme, régi par des lois physiques et fonctionnant en permanence.

Étape 4 : le contrôleur envoie la commande « Arrêt de la pompe », puis attend 5 secondes. Étape 5 : le contrôleur envoie la commande « Ouverture de la soupape ». Étape 6 : le liquide dans le réservoir est vidé, et le niveau quitte le niveau haut (L1 = 0). Étape 7 : le niveau de liquide atteint le niveau bas indiqué par la valeur L2 = 1. Étape 8 : le contrôleur envoie la commande « Fermeture soupape ».

Les systèmes de contrôle-commande industriels (SCI) [3] ont été rattachés aux systèmes cyberphysiques du fait de l’utilisation accrue des réseaux de communication et des technologies d’information pour surveiller et contrôler des systèmes physiques (figure 1). Les SCI sont des systèmes de contrôle combinant des composants matériels et logiciels afin de surveiller, coordonner et contrôler un ensemble d’opérations exécutées par un système physique dans les environnements industriels. Leurs cybercouches comprennent principalement des automates programmables industriels (API) et des systèmes de contrôle et d’acquisition de données (SCADA) en plus d’une interface homme-machine (IHM). L’API est un ordinateur industriel à l’état solide intégrant une interface d’entrée, une interface de sortie, une mémoire de programme et de données, un processeur, une interface de communication, ainsi qu’une alimentation électrique [4]. L’API émet une séquence de commandes selon l’état du système physique estimé en utilisant les données sensorielles. Ces dernières sont délivrées par les capteurs et transmises par le réseau de communication. Les commandes contrôlent l’état des actionneurs afin de leur permettre de fonctionner dans le système physique. Les systèmes SCADA collectent les données distantes du processus de contrôle affiché sur l’IHM.

BE 6 001 – 2

Puis le système relance le même cycle (étapes 1 à 8). L’état de la soupape est représenté par la variable booléenne P. Lorsque P = 1, ou V = 1, la pompe est en marche, ou la soupape ouverte. P = 0, ou V = 0, lorsque la pompe est à l’arrêt, ou la soupape fermée. La figure 3 illustre un automate à l’état fini représentant le modèle opérationnel de cet exemple. Chaque état est représenté par quatre variables booléennes : (P, V, L1, L2). Par exemple, à l’état initial, la pompe est à l’arrêt (P = 0), la soupape est fermée (V = 0) et le niveau de liquide dans le réservoir est bas (L1 = 0 et L2 = 1). Les SCI sont vulnérables aux cyberattaques du fait de l’utilisation de grands réseaux de communication ouverts et de technologies d’information (TI). La vulnérabilité de ces systèmes augmente de manière significative dans le contexte de la transition éner-

Copyright © – Techniques de l’Ingénieur – Tous droits réservés

ＱＶ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｂｅＶＰＰＱ _________________________________________________________ PROTECTION DES SYSTÈMES DE CONTRÔLE-COMMANDE CONTRE LES CYBERATTAQUES

Cyberdomaine Salle de contrôle/serveurs SCADA/stations techniques/serveur de maintenance Ordres de travail

Ｑ

Rapports

Réseau de communication de contrôle (protocole basé sur Ethernet)

API

API

…

Contrôle-commandes

API

Données sensorielles

Réseau de communication de processus (pair à pair/sans fil/bus de terrain/etc.)

Contrôle-commandes

Données sensorielles

Domaine physique Actionneurs (pompe/soupape, etc.)

Installation (réservoir)

Capteurs (débit/niveau/température, etc.)

Figure 1 – Système de contrôle-commande industriel (SCI) en tant que système cyberphysique

gique. Dans ce dernier cas, le réseau de distribution électrique traversera une période de transition vers un réseau intelligent où les cyberdomaines et domaines physiques sont étroitement liés. Les réseaux intelligents constituent un flux d’alimentation et de données bidirectionnel entre producteurs et consommateurs. Pour ce faire, il est nécessaire de recourir à des centres et des stratégies de contrôle d’avant-garde afin de contrôler le flux et la demande de charge. Du fait de l’utilisation croissante de ressources en énergie renouvelable, en particulier au niveau du consommateur (distribution de ressources en énergie renouvelable), et de l’intégration de nouvelles charges telles que les véhicules hybrides rechargeables, batteries de stockage d’énergie, et dispositifs élec-

troniques intelligents, ainsi que de nouveaux services (réponse à la demande, gestion intelligente de l’énergie, etc.), le rôle des SCI devient critique et requiert une communication intensive avec le nombre toujours plus important de nœuds (consommateurs) sur le réseau. Du fait de la complexité des réseaux intelligents en fonction de leur taille (nombre de nœuds), de la forte interconnexion entre le cybersystème et le système physique (production, transmission, distribution), ainsi que de la communication intensive (SCADA, compteur intelligent, etc.) entre les consommateurs et les centres de contrôle (SCI), les points d’entrée pour les pirates sur le réseau et les conséquences des attaques augmentent de manière significative.

Tableau 1 – Valeurs numériques pour l’exemple de réservoir de la figure 2 Réservoir

Soupape

Pompe

Valeurs des capteurs

État soupape

État pompe

Soupape-ouverte V = 0 Niveau bas L1 = 0, L2 = 1

Niveau haut L1 = 1, L2 = 1

Constantes niveau/section (cm, cm2) Lw = 5, Lh = 35, Lmax = 45, S = 10

Soupape-fermée V = 1

Arrêt pompe P = 0

Marche pompe P = 1

Sortie

Entrée

Qv = 10 cm3/sec

Qp = 20 cm3/sec

Copyright © – Techniques de l’Ingénieur – Tous droits réservés

ＱＷ

BE 6 001 – 3

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｂｅＶＰＰＱ PROTECTION DES SYSTÈMES DE CONTRÔLE-COMMANDE CONTRE LES CYBERATTAQUES ________________________________________________________

Démarrage pompe

Ｑ

Arrêt pompe L1

Pompe P

Contrôleur Qp

L2 Attaque Ouverture soupape Fermeture soupape Soupape V

Qv

Figure 2 – Exemple d’un système de contrôle-commande industriel (SCI)

(P V L1 L2)

q1

Démarrage pompe

q2

L2 = 0

(1001)

(0001)

q3

L1 = 1

(1000)

q4 (1010)

Arrêt pompe

Fermeture soupape

q8 (0101)

L2 = 1

q7

L1 = 0

(0100)

q6

Ouverture soupape

(0110)

Figure 3 – Modèle de contrôle sous forme d’un automate à l’état fini pour l’exemple de la figure 2

BE 6 001 – 4

Copyright © – Techniques de l’Ingénieur – Tous droits réservés

ＱＸ

q5 (0010)

Supervision des systèmes industriels (Réf. Internet 42396)

Ｒ

1– Méthodes fonctionnelles et outils 2– Systèmes d'exploitation temps réel

Réf. Internet

Systèmes d'exploitation temps réel. Principes

S8050

21

Systèmes d'exploitation temps réel - Exemples d'exécutifs industriels

S8052

27

Ordonnancement temps réel. Ordonnancement monoprocesseur

S8055

31

Ordonnancement temps réel. Ordonnancement réparti

S8056

37

Ordonnancement temps réel. Ordonnancement multiprocesseur

S8057

43

Linux pour le temps réel

S8058

47

Ordonnancement temps réel. Ordonnancement centralisé

S8059

51

page

3– Technologies logicielles et programmation 4– Interaction homme-machine 5– Exigences contractuelles



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires ＱＹ

Ｒ

ＲＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ

Syste`mes d’exploitation temps re´el Principes par

Yvon TRINQUET Professeur a` l’universite´ de Nantes (IUT de Nantes) Responsable de l’e´quipe « Syste`mes Temps Re´el » de l’Institut de recherche en communications et cyberne´tique de Nantes (IRCCyN)

et

Ｒ

Jean-Pierre ELLOY Professeur a` l’E´cole Centrale de Nantes Responsable de la valorisation a` l’Institut de recherche en communications et cyberne´tique de Nantes (IRCCyN)

1. 1.1 1.2

Contexte ........................................................................................... Cadres et enjeux industriels .............................................................. Syste`mes re´actifs ...............................................................................

2. 2.1 2.2

Application temps re´el .................................................................. Architecture fonctionnelle d’une application .................................... Architecture mate´rielle d’une application .........................................

— — —

3 3 4

3. 3.1 3.2 3.3 3.4

Approches synchrone et asynchrone .......................................... De´marche synchrone .......................................................................... De´marche asynchrone et exe´cutif ...................................................... De´marche dirige´e par le temps.......................................................... Architectures re´parties .......................................................................

— — — — —

4 5 5 7 7

4. 4.1 4.2

Exe´cutif temps re´el......................................................................... Roˆle de l’exe´cutif ................................................................................ Structure de l’exe´cutif ........................................................................

— — —

7 7 8

5. 5.1 5.2 5.3 5.4 5.5

Ordonnancement............................................................................. Calcul de se´quences ........................................................................... Ordonnancement optimal .................................................................. Caracte´risation des taˆches et des contraintes ................................... Me´triques de l’ordonnancement ....................................................... Algorithmes d’ordonnancement ........................................................

— — — — — —

10 11 11 12 12 13

6. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

Services de base d’un exe´cutif ge´ne´raliste ............................... Services pour les taˆches .................................................................... Synchronisation par les e´ve´nements ................................................ Partage de ressources ........................................................................ Communication .................................................................................. Gestion de la me´moire ...................................................................... Gestion du temps ............................................................................... Structure de prise en compte des interruptions ............................... Structure de prise en compte des exceptions ................................... Environnement de de´veloppement pour un exe´cutif ge´ne´raliste ....

— — — — — — — — — —

16 17 19 20 21 23 23 24 24 25

7.

Performances d’un exe´cutif temps re´el ge´ne´raliste ................

—

25

8.

Historique de quelques syste`mes d’exploitation temps re´el acade´miques ....................................................................................

—

26

9.

Exe´cutifs UNIX temps re´el ............................................................

—

27

Pour en savoir plus..................................................................................

S 8 050 – 2 — 2 — 2

Doc. S 8 050

C

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｪｵｩｮ＠ＲＰＱＰ

et article pre´sente les principes de base utilise´s dans les exe´cutifs temps re´el. Ce terme de´signe les syste`mes d’exploitation adapte´s au contexte particulier, par ses exigences temporelles, de l’informatique qualifie´e de « temps re´el ».

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＱ

S 8 050 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ SYSTE`MES D’EXPLOITATION TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

L’article pre´sente d’abord la proble´matique de l’informatique temps re´el et les approches possibles. Puis, la structure de l’exe´cutif et les politiques d’ordonnancement envisageables sont e´voque´es, ce qui conduit a` pre´senter les services ge´ne´riques que l’on peut rencontrer dans les produits industriels. Dans un second fascicule [S 8 052], certains produits bien repre´sentatifs de leur cate´gorie, seront succinctement de´crits.

Ｒ La garantie de bon fonctionnement est un crite`re primordial de conception et de de´veloppement de ces syste`mes. Exemples : ae´ronautique, ferroviaire, nucle´aire… ;

1. Contexte

 Les syste`mes embarque´s produits en tre`s grande quantite´, et a` inte´grer dans des e´quipements classiques. Ils doivent eˆtre a` la fois de couˆt mode´re´, offrir des garanties de fonctionnement suˆr sous des hypothe`ses fixe´es, pre´senter des proprie´te´s essentielles de modularite´, extensibilite´, maintenance… Exemples : automobile, e´quipements me´nagers, capteurs et actionneurs intelligents, signalisation et gestion technique… ;

1.1 Cadres et enjeux industriels D’abord marginal, devenu phe´nome`ne quasi explosif, l’utilisation de l’informatique dans la mise en œuvre des syste`mes automatise´s a pris une place conside´rable ces deux dernie`res de´cennies dans le monde industriel et, e´galement, dans les objets de la vie courante. L’ordinateur, sous des formes tre`s varie´es, du microcontroˆleur au calculateur vectoriel, s’installe dans de tre`s nombreuses applications, ou` sa capacite´ d’adaptation fait merveille et contribue progressivement a` introduire de nouvelles fonctionnalite´s, mais aussi a` re´aliser des fonctions jusqu’alors a` base d’autres technologies.

 Les syste`mes a` l’architecture mate´rielle ou logicielle dynamique. Ce caracte`re dynamique peut eˆtre duˆ : au nombre changeant d’e´quipements de l’application, ou au nombre variable de fonctions ge´re´es par le syste`me informatique en fonction de la charge, ou mode de fonctionnement du proce´de´. Cette nature dynamique peut n’apparaıˆtre qu’au moment de la configuration de l’installation ou au cours de la vie de l’application. Dans le premier cas, elle influe sur la de´marche de conception du syste`me de pilotage. Dans le second cas, elle conditionne la conception des outils de mise en œuvre de l’application. Exemples : unite´s de production en continu (unite´s chimiques, centrales de production d’e´nergie), lignes de fabrication d’e´quipements en se´rie, agroalimentaire, re´seaux de communication…

Par exemple, la part de l’e´lectronique embarque´e dans les ve´hicules automobiles s’accroıˆt constamment : – syste`me controˆlant l’injection au niveau du moteur ; – commande e´lectronique des essuie-glaces ; – syste`me de controˆle de la stabilite´ du ve´hicule ; – gestion des e´quipements multime´dia inte´gre´s dans l’habitacle, etc.

& La proble´matique du temps re´el est apparue au travers des techniques et outils qui ont e´te´ progressivement de´veloppe´s pour permettre la mise en œuvre de ces applications. En premier lieu issus du monde industriel, et en particulier des entreprises et socie´te´s de service inte´grateurs de syste`mes automatise´s, ces outils subissent actuellement des e´volutions tre`s importantes en conception et architecture. Elles sont dues a` l’utilisation croissante de paradigmes informatiques modernes qui en accroissent la modularite´, ainsi qu’a` la conceptualisation du fonctionnement des syste`mes temps re´el, travail effectue´ dans les organismes de recherche acade´miques ou industriels en vue de pouvoir prouver (et certifier) le bon fonctionnement des applications imple´mente´es. Dans le meˆme temps, de nouveaux champs d’application, originellement purement informatiques, s’ouvrent a` ces techniques, comme le multime´dia. De´sormais, cette proble´matique est devenue passerelle entre l’automatique et l’informatique avec sa spe´cificite´ intrinse`que : le temps.

Actuellement, a` l’instar de ce qui se passe dans l’avionique, e´merge la notion de « tout e´lectronique » (terme anglo-saxon habituel : « X-by-Wire ») qui de´signe le remplacement des syste`mes de controˆle me´caniques et/ou hydrauliques par des syste`mes uniquement nume´riques. Des e´tudes, de´ja` avance´es chez de nombreux constructeurs automobiles, sont consacre´es, par exemple, au controˆle de direction (« Steer-by-Wire »). Il s’agit d’un syste`me qui est, pour des raisons topologiques, entie`rement distribue´. De plus, les lois de controˆle, par exemple celles qui commandent la cre´maille`re d’entraıˆnement de l’axe de direction, imposent des proprie´te´s temporelles fortes au syste`me. Enfin, le bon fonctionnement de ce syste`me est crucial pour la se´curite´ du ve´hicule, d’ou` l’importance que prend la suˆrete´ de fonctionnement pour les syste`mes embarque´s temps re´el.

1.2 Syste`mes re´actifs & Les domaines industriels d’application qui s’ouvrent ainsi a` l’informatique « temps re´el » peuvent eˆtre sommairement classe´s en trois groupes.

Synthe´tiquement de´finie, une application temps re´el « met en œuvre des syste`mes informatiques ou informatise´s coope´rant avec l’homme et destine´s a` la perception, l’observation, l’aide a` la de´cision et la conduite de proce´de´s dynamiques ». Dans ce but ont e´te´ e´labore´s des concepts, des mode`les, des me´thodes et des outils en vue de la conception et de la re´alisation mate´rielle et logicielle des syste`mes re´actifs informatise´s. Tous ces e´tudes et produits reposent sur la meˆme perception du temps re´el.

 Les syste`mes embarque´s dans des e´quipements de haute technologie, et dont la se´curite´ est un souci majeur. Le prix de l’informatique y est conside´re´ comme de peu d’importance, relativement aux couˆts qui seraient engendre´s par la de´faillance du proce´de´ pilote´.

S 8 050 – 2

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– SYSTE`MES D’EXPLOITATION TEMPS RE´EL

 Il se re´fe`re ensuite au « temps ». Les interactions entre proce´de´ et syste`me doivent eˆtre « instantane´es ». Fondamentalement, un syste`me temps re´el doit eˆtre a` l’e´coute permanente des variations du proce´de´, et agir en retour aussitoˆt que ne´cessaire sur le proce´de´ afin de le contraindre a` adopter le comportement souhaite´. Ces interactions ne prennent en fait le sens de « temps re´el » que si le proce´de´ est actif, c’est-a`-dire s’il continue d’e´voluer en l’absence de nouvelles commandes, c’est-a`-dire en cas d’inactivite´ ou de retard du syste`me de pilotage. Ce concept s’applique donc essentiellement aux proce´de´s qui posse`dent des dynamiques internes. Or, par principe, le fonctionnement d’un syste`me informatique ne permet qu’une observation e´chantillonne´e de son environnement. Par ailleurs, e´mettre une nouvelle commande est une ope´ration du syste`me informatique qui ne peut eˆtre instantane´e car elle requiert un temps de calcul qui peut eˆtre conse´quent.

Par le CNRS [12] « est qualifie´ de temps re´el le comportement d’un syste`me informatique lorsqu’il est assujetti a` l’e´volution dynamique d’un proce´de´ qui lui est connecte´, et qu’il doit piloter ou suivre en “re´agissant” a` tous ses changements d’e´tat ».  Dans [35] : « Toute activite´ ou syste`me de traitement de l’information doit re´pondre aux stimuli externes dans un temps donne´ ».  Dans [23] : « Un syste`me de calcul ou` de´but et fin des activite´s sont ge´re´s afin de respecter des contraintes temporelles spe´cifiques. Des donne´es temporelles sont associe´es aux fins d’activite´. Le comportement du syste`me est de´termine´ par des algorithmes conc¸us pour maximiser une fonction de valeur globale de´pendant du temps. »  Dans [14] citant la norme allemande DIN 44 300 : « Le mode de fonctionnement d’un syste`me informatique dans lequel les programmes de traitement des donne´es entrantes sont constamment preˆts afin que leurs re´sultats soient disponibles dans des pe´riodes de temps pre´de´termine´es ».

Pour un syste`me de pilotage, re´agir « dans les temps » implique donc une observation et une action suffisamment rapides pour que le proce´de´ n’ait pas le temps d’e´voluer de fac¸on significative entre une variation d’e´tat et l’action qui en re´sulte. Le temps re´el refle`te donc une capacite´ de re´action a` l’e´chelle de temps du proce´de´ : c’est un temps relatif.

 Dans [26] : « Un syste`me temps-re´el est un syste`me dont on exige qu’il re´agisse aux stimuli de l’environnement (incluant le passage de temps) dans l’intervalle de temps relatif impose´ par l’environnement ».  Dans l’« Oxford Dictionary of Computing », cite´ dans [43] : « Tout syste`me pour lequel la date a` laquelle un re´sultat est produit s’ave`re significative ».

2. Application temps re´el 2.1 Architecture fonctionnelle d’une application

Ces de´finitions permettent de bien mettre en e´vidence le particularisme du temps re´el vis-a`-vis des autres classes de syste`mes informatiques : la prise en compte du temps. En effet, on en distingue ge´ne´ralement trois.

Exemple Prenons le cas d’une application de re´gulation de niveau d’un fluide dans un re´servoir a` fuite constante (figure 1) ou`, le roˆle du syste`me de pilotage (un poste de conduite) consiste a` asservir le niveau du fluide a` partir de la mesure pre´leve´e par un capteur analogique. Il s’agit d’une commande a` exe´cuter pe´riodiquement et dont l’action est l’ajustement de l’ouverture de la vanne d’alimentation du re´servoir. A` cette fonction de base, on adjoint deux autres missions comple´mentaires : – commuter de boucle ouverte en boucle ferme´e (et inversement) sur ordre de l’ope´rateur ; – en cas d’alarme signalant l’imminence d’un de´bordement (situation pouvant survenir en cas de panne non de´tecte´e du capteur principal), commuter en boucle ouverte et fixer l’ouverture de la vanne a` une valeur pre´de´finie.

& Les syste`mes transformationnels, comme en rele`vent, par exemple, le calcul scientifique ou la gestion de bases de donne´es, qui utilisent des programmes dont les re´sultats sont e´labore´s a` partir de donne´es disponibles a` l’initialisation de l’application, et dont les instants de production ne sont pas contraints. & Les syste`mes interactifs, comme les syste`mes transactionnels ou les utilitaires de bureautique, qui ge`rent des programmes dont les re´sultats sont fonction de donne´es produites par l’environnement du syste`me (essentiellement l’utilisateur), et dont on souhaite que les instants de production respectent des valeurs statistiques. & Enfin, les syste`mes « re´actifs » qui ge`rent des programmes dont les re´sultats sont entie`rement conditionne´s par le comportement de l’environnement connecte´ (le proce´de´ industriel), et dont les instants de production des re´sultats sont contraints par les dynamiques de cet environnement. Le vocable « re´actif », souvent utilise´ en synonyme de « temps re´el », a l’inte´reˆt de souligner deux concepts a` la base de ces syste`mes.

Commande V

Vanne

 Il se re´fe`re d’abord aux « interactions » entre le proce´de´ et le syste`me tout d’abord. Le syste`me informatique re´actif doit re´agir aux variations d’e´tat constate´es du proce´de´ en lui appliquant les commandes approprie´es, ou en signalant cette variation a` l’ope´rateur. Une forme de « dialogue » s’e´tablit donc entre le proce´de´ et le syste`me informatique de pilotage, et ce via trois types de grandeurs : – des « mesures » que le proce´de´ produit en continu sans signalisation particulie`re et que le syste`me de pilotage doit pre´lever de lui-meˆme pour assurer sa mission ; – des « e´ve´nements » que le proce´de´ signale au syste`me de pilotage, mais qui sont souvent intrinse`quement fugaces (c’est-a`-dire qui disparaissent sitoˆt e´mis), et donc que le syste`me doit saisir « au vol » ; – enfin, et en retour, des « commandes » qui sont des signaux logiques, ou analogiques, maintenus technologiquement sur les actionneurs du proce´de´.

carac

I

A Détecteur Événement de niveau « haut » N Capteur de niveau

Mesure A

Alarme Information N Niveau V Vanne carac Caractère

I

Figure 1 – Re´gulation de niveau

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＳ

S 8 050 – 3

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ SYSTE`MES D’EXPLOITATION TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

 Contraintes « temporelles » Comme les taˆches sont sollicite´es par des e´ve´nements aux occurrences asynchrones, il se peut qu’a` certains moments plusieurs taˆches entrent en concurrence pour leur exe´cution. Si le nombre ou la puissance des processeurs du syste`me de pilotage sont sous-dimensionne´s, il se peut qu’ils ne puissent satisfaire les contraintes temporelles de toutes les taˆches en concurrence, c’est-a`-dire re´pondre a` toutes « a` temps ». Pour e´viter pareil cas, il faudra modifier l’architecture mate´rielle en conse´quence : accroissement de la puissance des unite´s de traitement, utilisation de processeurs spe´cialise´s, re´partition des taˆches sur les processeurs…

N HTR

carac Acquisition Filtrage

BO Æ BF

Directives Visualisation

Commande BF Æ BO V

Ｒ

Émission

I

A Alarme

& Ainsi, pour satisfaire une ou plusieurs de ces contraintes, on peut eˆtre amene´ a` adopter un syste`me informatique de pilotage compose´ de plusieurs stations de traitement interconnecte´es en re´seau. Le « re´seau » devient alors la colonne verte´brale des communications intra-syste`me et ses performances et capacite´s jouent, a` leur tour, un roˆle essentiel dans le respect des contraintes de suˆrete´ et de temps.

Figure 2 – Architecture fonctionnelle de la re´gulation de niveau Nota : un syste`me est dit en boucle ouverte, si la commande du syste`me est calcule´e sans utiliser d’information de valeur de la grandeur controˆle´e. Dans l’exemple, l’ouverture de la vanne est faite inde´pendamment du niveau dans la cuve. A` l’inverse, le syste`me est dit en boucle ferme´e, si le calcul de la commande utilise une information sur la grandeur controˆle´e. Dans l’exemple, l’ouverture de la vanne tient compte du niveau re´el dans la cuve.

Cependant, l’introduction des re´seaux ame`ne son lot de difficulte´s nouvelles qui n’apparaissent pas dans le cas monoprocesseur. En effet, lorsque les actions a` entreprendre sur le proce´de´ sont calcule´es en paralle`le sur des stations distantes, leurs observations de l’e´tat du proce´de´ peuvent diffe´rer de l’une a` l’autre en raison de l’asynchronisme du fonctionnement des processeurs et des de´lais de communication. Dans ce cas, les actions applique´es au syste`me se´pare´ment par ces stations peuvent ne pas eˆtre cohe´rentes entre elles. C’est pourquoi l’introduction d’un re´seau dans l’architecture mate´rielle du syste`me de commande est une donne´e qui en conditionne e´galement la re´alisation logicielle. Ces deux aspects ne sont plus a` dissocier et leur de´veloppement conjoint est ne´cessaire a` la re´alisation de l’application.

L’analyse du cahier des charges de cette simple application conduit au recensement des actions e´le´mentaires que doit effectuer le syste`me de pilotage et que l’on regroupe en taˆches. Une « taˆche » rassemble des fonctions de l’application qui sont exe´cute´es dans les meˆmes conditions e´ve´nementielles. Dans l’exemple de la figure 2, on peut ainsi recenser les taˆches suivantes : – « acquisition-filtrage » et calcul de la « commande » de vanne (activite´ pe´riodique lie´e a` l’horloge temps re´el HTR) ; – « e´mission » de la commande vers l’actionneur ; – commutation de « boucle ouverte en boucle ferme´e » ; – commutation de « boucle ferme´e en boucle ouverte » ; – re´ception et analyse des « directives » de l’ope´rateur ; – re´ception et traitement de « l’alarme ».

L’aboutissement de ce de´veloppement conduit alors a` la de´finition d’un mate´riel, d’une de´composition fonctionnelle et d’une re´partition de ces fonctions sur le mate´riel, le tout garantissant, ensemble, les contraintes temporelles de l’application. Ce re´sultat est appele´ « architecture ope´rationnelle » de l’application.

La figure 2 illustre l’architecture fonctionnelle re´sultante sous la forme d’un sche´ma a` flots d’e´ve´nements.

2.2 Architecture mate´rielle d’une application

3. Approches synchrone et asynchrone

Imple´menter cette application passe par le choix de la configuration mate´rielle du syste`me de pilotage sur lequel seront imple´mente´es les taˆches de l’application. Plusieurs structures de cette configuration sont envisageables, meˆme dans le cas de l’exemple simple pre´ce´dent, et pour chaque structure, on peut a priori envisager l’utilisation de toute une varie´te´ d’e´quipements (processeurs, cartes d’interfaces, re´seaux) aux performances diffe´rentes.

Si on poursuit l’e´tude de l’application de la re´gulation de niveau de la figure 1, il faut maintenant spe´cifier l’architecture mate´rielle du syste`me de pilotage. Plusieurs possibilite´s se pre´sentent, meˆme dans ce cas de l’exemple pourtant simple ; tout de´pend des fonctions que l’on de´cide de de´porter dans le capteur (de niveau) et dans l’actionneur (la vanne de re´gulation).

& Le choix de la configuration et la se´lection des e´quipements sont naturellement et intimement lie´s. De plus, outre les crite`res de couˆt ou de fiabilite´, ils de´pendent essentiellement de trois types de contraintes.

Choisissons ici la solution la plus classique : des capteurs et actionneurs sans intelligence de´porte´e, un poste de conduite constitue´ d’un calculateur monoprocesseur e´quipe´ des interfaces d’entre´es-sorties approprie´es a` l’application, une console ope´rateur. C’est la solution illustre´e sur la figure 1. Il s’agit maintenant de proce´der a` l’imple´mentation dans ce calculateur des taˆches pre´ce´demment de´crites. A` premie`re vue, il pourrait sembler que cette phase d’imple´mentation rele`ve uniquement de techniques de de´veloppement, et que les de´cisions qui conditionnent le bon fonctionnement de l’application sont de´ja` prises. Or si cela est vrai sur le plan fonctionnel, rien n’est encore vraiment re´solu sur le plan temporel.

 Contraintes « topologiques » Ces contraintes apparaissent lorsque le proce´de´ est une installation e´clate´e ge´ographiquement, ou quand le proce´de´ est dote´ d’une instrumentation intelligente qui en de´porte certains traitements (dans l’exemple pre´sente´, cas ou` les fonctions d’acquisition et de filtrage seraient inte´gre´es au capteur) ;  Contraintes de « suˆrete´ de fonctionnement » C’est l’impe´ratif de maintien du service du syste`me de pilotage (nominal ou de´grade´) en cas d’anomalie partielle des e´quipements. Satisfaire cet impe´ratif se traite par la redondance. Cette redondance peut concerner l’instrumentation (dans l’exemple pre´sente´, le de´tecteur de niveau haut supple´e un dysfonctionnement du capteur), mais elle concerne e´galement le syste`me informatique car sa de´faillance engendre la perte totale du controˆle du proce´de´ ;

S 8 050 – 4

Et le traitement des contraintes temporelles va eˆtre e´troitement conditionne´ a` ce moment par un choix majeur : celui de la re´alisation du « lien entre les taˆches et leurs e´ve´nements activeurs ». En

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– SYSTE`MES D’EXPLOITATION TEMPS RE´EL

effet, quels que soient les langages ou formalismes utilise´s, pour de´crire l’application, et les outils adopte´s pour l’imple´mentation, tous peuvent conduire, au niveau « machine », a` deux techniques diffe´rentes de re´alisation du me´canisme d’appel des taˆches. Et ces deux techniques rele`vent de deux principes fondamentaux diffe´rents, « synchrone » et « asynchrone ».

valide, c’est-a`-dire n’engendre pas le de´passement de certaines e´che´ances temporelles quand on passe en situation re´elle, c’est-a`dire avec les ve´ritables dure´es d’exe´cution des actions. & Comme le syste`me de pilotage ne constate l’arrive´e de nouveaux e´ve´nements qu’a` la terminaison de chaque taˆche, voire a` la terminaison d’un groupe de taˆches, il rec¸oit a` cet instant tous les e´ve´nements en attente sans connaıˆtre leur ordre d’arrive´e. Si cet ordre est important pour l’application, c’est-a`-dire conditionne l’action du syste`me de pilotage, quelle action entreprendre alors ?

3.1 De´marche synchrone La technique de mise en œuvre synchrone consiste a` construire directement le lien entre une taˆche et son e´ve´nement activeur sans se pre´occuper de l’existence d’e´ventuels conflits de cette taˆche avec les autres au cours du fonctionnement de l’application.

La technique adopte´e dans l’approche synchrone, pour traiter cette circonstance, consiste a` conside´rer tous les e´ve´nements observe´s au meˆme instant comme e´tant survenus en meˆme temps, c’est-a`-dire comme simultane´s. Cette « simultane´ite´ » peut eˆtre perc¸ue alors comme un nouvel e´ve´nement pour lequel l’utilisateur peut de´finir une action spe´cifique a` entreprendre en ce cas.

Il s’agit donc d’une construction aveugle, et cette technique ne fonctionne que si cet aveuglement n’engendre pas de fautes comportementales, ni temporelles.

La figure 3 illustre le chronogramme des deux taˆches Directives et Alarme exe´cute´es suite a` l’occurrence des e´ve´nements carac et A dans le cas d’une imple´mentation synchrone. On suppose que l’alarme survient au cours de l’exe´cution du traitement d’une directive de l’ope´rateur. Sur cette figure carac’ et A’ de´signent les e´ve´nements re´ellement perc¸us par le syste`me de pilotage. On trouvera plus d’informations dans [3].

Sur le plan comportemental, en particulier, aucune taˆche ne devra acce´der a` une ressource partage´e alors qu’elle est en cours d’utilisation par d’autres, et qui risquerait alors de devenir incohe´rente, car dans cette de´marche aucun me´canisme ne peut en prote´ger l’acce`s exclusif. La solution pour y parvenir consiste a` se´quentialiser l’exe´cution des taˆches, donc a` e´viter la « pre´emption » (voir Nota) de toute taˆche par une autre et a` y encapsuler l’utilisation de toute ressource partage´e.

3.2 De´marche asynchrone et exe´cutif

Nota : la pre´emption est l’action qui consiste a` suspendre l’exe´cution d’une action au profit d’une autre juge´e plus prioritaire (crite`re d’urgence par exemple).

La technique de mise en œuvre asynchrone consiste a` observer en permanence les occurrences d’e´ve´nement, y compris au cours de l’exe´cution des taˆches. Leurs dates d’arrive´e et leurs ordres relatifs sont donc connus : la nature de l’action a` entreprendre n’est pas ambigue¨ et son urgence peut eˆtre imme´diatement prise en compte.

Mais, adopter la non-pre´emption n’est pas sans conse´quences sur le plan temporel : & La perception qu’a le syste`me de l’occurrence de tout e´ve´nement est diffe´re´e du temps d’exe´cution de la taˆche en cours (au moment de l’occurrence). Ce « retard » a` la prise en compte peut affecter n’importe quel e´ve´nement, quelle qu’en soit la gravite´ pour l’application. En outre, ce retard peut eˆtre conse´quent, en cas d’e´ve´nements en rafale, pour la taˆche traite´e en dernier. Il faut donc a` tout prix concevoir l’architecture fonctionnelle, et particulie`rement le de´coupage des taˆches, de fac¸on a` e´viter qu’une taˆche d’importance faible mobilise le processeur.

Malheureusement, la pre´emption, outre son couˆt temporel, engendre de nouveaux proble`mes. ` la diffe´rence de la de´marche synchrone, il devient beaucoup &A plus difficile d’observer et, donc, de ve´rifier le « bon » comportement du syste`me informatique de pilotage. Il serait a priori ne´cessaire d’envisager toutes les situations de pre´emption pour ve´rifier qu’aucune n’engendre le non-respect d’une contrainte temporelle quelconque, ce qui est naturellement impossible. Il faut, comme en synchrone d’ailleurs, passer par une mode´lisation formelle du comportement de l’application pour pouvoir la ve´rifier, mais les mode`les asynchrones qui permettent une telle preuve sont actuellement plus complexes qu’en de´marche synchrone.

Dans l’exemple de la figure 1, ce pourrait eˆtre le cas de la taˆche consacre´e a` la re´ception des directives si sa dure´e est fonction de la vitesse de saisie de l’ope´rateur. On constate donc qu’avec cette technique les contraintes temporelles de l’application doivent eˆtre analyse´es a` la conception de l’application. Il faudra ve´rifier, sur l’architecture ope´rationnelle choisie, si l’hypothe`se « d’instantane´ite´ » des actions, en fait implicite dans la de´marche synchrone, est

En n’observant les occurrences d'événements émis par le procédé qu’à la fin de l’exécution de chaque action, la réaction du système est perçue comme immédiate … par le système de contrôle.

Alarme Application

Occurrences observées

Directives

carac’

A'

Système Occurrences émises par le procédé

A carac

Temps

La prise en compte retardée de certaines occurrences d'évènements est une réaction perçue comme différée … par le procédé.

Figure 3 – Chronogramme d’une exe´cution « synchrone »

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＵ

S 8 050 – 5

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＰ SYSTE`MES D’EXPLOITATION TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

 Cette technique souffre de plusieurs difficulte´s. Tout d’abord, quel est ce parame`tre qui de´finit l’importance d’une taˆche : son e´che´ance (c’est-a`-dire son urgence) ou sa gravite´ (c’est-a`-dire l’ampleur des dommages encourus en cas de non-respect de cette e´che´ance) ? La re´ponse n’est pas unique. Certes, si les e´che´ances sont toutes satisfaites, la question des dommages ne se pose pas, mais en cas de l’e´ventualite´ du non-respect de toutes les e´che´ances ? En ce cas, nombre d’applications ne permettent pas de traduire l’importance d’une taˆche sous la forme d’un indicateur unique, valide pour tous les cas d’occurrence d’e´ve´nements et dans toutes les situations de concurrence des taˆches.

Cela est en partie duˆ au fait que, macroscopiquement, des occurrences d’e´ve´nement tre`s voisines peuvent engendrer des re´actions parfois bien diffe´rentes du meˆme syste`me. Certes, a` l’examen tre`s fin du de´roulement de l’e´volution de chaque taˆche, ces diffe´rences de re´action sont parfaitement justifie´es. Mais, a` l’e´chelle temporelle du proce´de´, on preˆte souvent aux re´actions asynchrones le caracte`re « d’inde´terministes » pour cette raison.

Ｒ

` l’instant d’arrive´e de tout nouvel e´ve´nement, on peut mainte&A nant de´cider a` qui allouer le processeur entre : – la nouvelle taˆche active´e par cet e´ve´nement ; – celle qui e´tait de´ja` en exe´cution a` ce meˆme moment ; – une autre taˆche en attente d’un processeur.

 De nombreuses variantes de re´alisation tentent alors de traduire l’importance multicrite`res d’une taˆche par une priorite´ variable dans le temps, en fonction de l’e´tat du proce´de´ ou de la charge du syste`me de pilotage. La priorite´ perd son sens initial et ces re´alisations ne suivent alors plus la politique d’ordonnancement, qui avait peuteˆtre pourtant e´te´ choisie pour sa garantie de respect des contraintes temporelles. On atteint alors les limites de ce me´canisme.

 De ce choix de´pend le respect des contraintes temporelles. Les modalite´s de ce choix sont donc primordiales pour le bon fonctionnement de l’application : elles constituent ce qu’on appelle une « politique d’ordonnancement ». De nombreuses politiques d’ordonnancement ont e´te´ propose´es dans la litte´rature, mais a` chaque fois pour satisfaire des contraintes temporelles d’une classe d’applications spe´cifique. Pour certaines politiques, il existe meˆme une condition formelle qui permet d’e´tablir hors-ligne si, oui ou non, les contraintes temporelles seront respecte´es dans toutes les situations possibles que peuvent rencontrer les taˆches appartenant a` la classe d’application concerne´e. Dans ces cas spe´cifiques, le risque de non-respect des contraintes peut donc eˆtre identifie´ de`s la phase de conception et traite´ par une modification en conse´quence de l’architecture mate´rielle.

& Une fois l’ordonnancement choisi pour sa garantie de respect des contraintes, une fois son me´canisme de mise en œuvre de´fini, il s’agit de le re´aliser. Reste alors a` construire le dispositif qui centralisera la re´ception de tous les e´ve´nements, qui suivra l’e´volution de l’exe´cution des taˆches et qui, en conse´quence, effectuera le choix a` tout instant des taˆches a` exe´cuter. Ce centralisateur s’appelle « l’exe´cutif », et la composante de l’exe´cutif qui met en œuvre la politique d’ordonnancement s’appelle « l’ordonnanceur ». Adopter la de´marche asynchrone conduit a` la construction ou a` l’acquisition d’un exe´cutif temps re´el.

 Mais, hors de ces cas, pour obtenir le respect des contraintes temporelles, il faut avoir recours a` des palliatifs varie´s : – modification du cahier des charges de l’application pour la ramener a` un cas standard ; – construction hors-ligne d’une se´quence valide en balayant exhaustivement les situations dangereuses ; – simulation hors-ligne des se´quences engendre´es par diverses politiques fixe´es a priori, etc.

` propos de la gestion des ressources partage´es. Comme toute &A taˆche est susceptible d’eˆtre pre´empte´e a` tout moment par d’autres taˆches plus prioritaires, les ressources qu’elles se partagent risquent de devenir incohe´rentes en cas de pre´emption au milieu de leur manipulation. Il devient ne´cessaire de garantir cette cohe´rence par un me´canisme approprie´. C’est un des roˆles qui est confie´ a` l’exe´cutif, puisqu’il est inde´pendant des taˆches et de´ja` gestionnaire de la ressource commune qu’est le processeur. Mais, la politique de gestion des ressources partage´es vient alors se superposer a` celle de l’allocation des processeurs, qui, toutes deux, ont pour roˆle de de´cider l’ordre d’exe´cution des taˆches. Comme leurs crite`res de de´cision sont diffe´rents, il est ine´luctable que ces deux politiques entrent en conflit. Dans ce contexte, e´tablir a priori si, pour les taˆches d’une application donne´e, cette superposition de politiques d’ordonnancement garantit le respect des contraintes temporelles devient encore plus de´licat, et ne peut eˆtre ve´rifie´ que dans des cas bien spe´cifiques. La figure 4 illustre le chronogramme des deux meˆmes taˆches visibles sur la figure 3, mais cette fois dans le cas d’une imple´mentation asynchrone.

& La mise en œuvre en ligne de la plupart de ces politiques s’appuie sur un me´canisme de base bien connu, la « priorite´ ». Ce me´canisme est utilisable lorsque la politique d’ordonnancement consiste a` de´finir l’importance relative de chaque taˆche (vis-a`-vis des autres) en fonction d’un parame`tre unique, comme son e´che´ance, sa pe´riode ou sa gravite´ ; la priorite´ de chaque taˆche est alors une fonction de ce parame`tre.  L’emploi de ce me´canisme en ligne est alors tre`s simple. Pour suivre la politique d’ordonnancement adopte´e, il suffit de choisir comme taˆche a` exe´cuter celle de plus forte priorite´ parmi toutes celles en concurrence. Encore faut-il que l’importance d’une taˆche ne de´pende que de ce seul parame`tre tout au long de l’application.

Le système peut suspendre le traitement d’une action (déclenchée par "carac") au bénéfice d’une autre, jugée plus « importante », (déclenchée par « A ») pour le fonctionnement du procédé.

Alarme Application

Occurrences observées

Directives

carac’ A'

Système Occurrences émises par le procédé

carac

A

Temps

Les occurrences d'événements émis par le procédé sont immédiatement perçues par le système.

Figure 4 – Chronogramme d’une exe´cution « asynchrone »

S 8 050 – 6

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＶ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＲ

Syste`mes d’exploitation temps re´el – Exemples d’exe´cutifs industriels par

Yvon TRINQUET Professeur a` l’Universite´ de Nantes (IUT de Nantes) Responsable de l’E´quipe « Syste`mes Temps Re´el » de l’Institut de Recherche en Communications et Cyberne´tique de Nantes (IRCCyN)

et

Ｒ

Jean-Pierre ELLOY Professeur a` l’E´cole Centrale de Nantes Responsable de la valorisation a` l’Institut de Recherche en Communications et Cyberne´tique de Nantes (IRCCyN)

1.

Situation de l’offre .........................................................................

2.

Exemples d’exe´cutifs ge´ne´ralistes ..............................................

—

2

3. 3.1

Exe´cutifs UNIX temps re´el ............................................................ Aperc¸u de POSIX ................................................................................ 3.1.1 Historique de POSIX ................................................................ 3.1.2 Aperc¸u de quelques caracte´ristiques de POSIX‚ 1003.1 ....... 3.1.3 Les profils temps re´el .............................................................. 3.1.4 Exemple de produits ............................................................... L’approche LINUX temps re´el ............................................................ 3.2.1 Historique de l’approche ......................................................... 3.2.2 Approche par pre´emption du noyau LINUX ........................... 3.2.3 Approche par noyau temps re´el .............................................. 3.2.4 Exemples de produits ..............................................................

— — — — — — — — — — —

3 3 3 3 6 6 7 7 7 7 7

4. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Le standard OSEK/VDX .................................................................. Historique de la proposition OSEK/VDX ........................................... La gestion des taˆches ......................................................................... La synchronisation des taˆches ........................................................... Partage de ressources et exclusion mutuelle .................................... Les objets Alarme et Compteur ......................................................... La communication .............................................................................. Les classes de conformite´ .................................................................. L’approche dirige´e par le temps : OSEKtime ..................................... L’e´volution vers AUTOSAR ................................................................. Exemples de produits ........................................................................

— — — — — — — — — — —

8 8 8 8 9 9 9 10 10 10 11

5. 5.1 5.2

Le standard ARINC 653.................................................................. Aperc¸u du standard ............................................................................ Aperc¸u sur les produits ......................................................................

— — —

11 11 12

3.2

Pour en savoir plus..................................................................................

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｳ･ｰｴ･ｭ｢ｲ･＠ＲＰＱＰ

C

S 8 052 – 2

Doc. S 8 050

et article fait suite au fascicule [R 8 050] et pre´sente certains produits bien repre´sentatifs de leur cate´gorie.

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＷ

S 8 052 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＲ SYSTE`MES D’EXPLOITATION TEMPS RE´EL – EXEMPLES D’EXE´CUTIFS INDUSTRIELS ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Ｒ

1. Situation de l’offre

Enfin, POSIX‚ (Portable operating system interface for computer environments) qui comple`te UNIX‚ de fonctionnalite´s temps re´el est le fruit de travaux mene´s depuis 1984, avec une re´vision majeure en 2001, et a conduit a` plusieurs standards IEEE et ISO.

L’offre industrielle pour les syste`mes d’exploitation temps re´el est importante et varie´e. On trouve des exe´cutifs pour microcontroˆleurs, des exe´cutifs pour les processeurs « classiques » (architecture CISC : Complexed instruction set computer) et enfin des exe´cutifs pour les machines a` architecture RISC (Reduced instruction set computer). Les exe´cutifs peuvent eˆtre conc¸us pour une architecture monoprocesseur, multiprocesseur a` me´moire partage´e (partiellement ou totalement), ou encore multiprocesseur sans me´moire commune (utilisation d’un re´seau de communication).

La pre´sentation qui suit est organise´e comme indique´ ci-apre`s. Tout d’abord quelques exe´cutifs ge´ne´ralistes seront pre´sente´s, puis nous aborderons le domaine des exe´cutifs UNIX‚ temps re´el, a` la fois au travers du standard POSIX‚ et des de´veloppements LINUX‚ temps re´el. Nous continuerons par l’expose´ des principales caracte´ristiques du standard OSEK/VDX, comple´te´ par quelques indications sur AUTOSAR. Enfin nous e´voquerons le standard ARINC 653. La pre´sentation meˆme un peu de´taille´e de syste`mes d’exploitation temps re´el est un exercice extreˆmement de´licat car il faudrait avoir a` disposition l’ensemble des documentations techniques les concernant, ce qui n’est e´videmment pas possible, et qui de plus demanderait beaucoup trop de temps et d’espace pour pre´tendre a` l’exhaustivite´ dans un article. Les sites web des constructeurs sont tre`s riches d’informations, pas toujours faciles a` de´crypter car e´videmment leurs produits sont toujours les meilleurs et les seuls capables de re´pondre aux besoins. L’objectif de cette description est donc surtout d’arriver a` situer les contributions les unes par rapport aux autres, a` charge ensuite a` la personne inte´resse´e d’analyser dans le de´tail les caracte´ristiques pertinentes re´pondant a` ses besoins.

Re´gulie`rement des e´tudes de marche´ paraissent dans la presse spe´cialise´e ou sont effectue´es par des socie´te´s offrant un service de conseil (donc payantes). D’une manie`re ge´ne´rale, les re´sultats de ces enqueˆtes ne sont pas faciles a` analyser, meˆme si des tendances s’en de´gagent, la communication des e´diteurs de logiciel n’e´tant pas toujours claire entre ceux qui se disent leaders, ceux qui ont la plus forte croissance, en inte´grant bien suˆr les chiffres de croissance du marche´ qui sont importants chaque anne´e. Une e´tude publie´e en juin 2006 (http://www.embedded.com) montre la re´partition entre les types de syste`mes d’exploitation utilise´s pour les syste`mes embarque´s. La moitie´ (51 %) sont des OS commerciaux, 21 % sont des OS « proprie´taires », 16 % sont des OS open source et 12 % sont des OS open source avec support commercial. Dans les OS commerciaux la socie´te´ Wind River est (depuis longtemps) leader avec son produit VxWorks et ses de´clinaisons, suivi par les versions « embedded » de Windows‚ (XP embedded et CE). Dans ces re´sultats, on peut observer une proportion non ne´gligeable des re´alisations « proprie´taires ». Le choix d’une telle solution peut eˆtre guide´ :

2. Exemples d’exe´cutifs ge´ne´ralistes On donne ci-apre`s les re´fe´rences de quelques exe´cutifs ge´ne´ralistes que l’on peut trouver sur le marche´.

– par des conside´rations e´conomiques (droit de licence), – par des conside´rations techniques qui conduisent a` re´aliser un produit parfaitement adapte´ aux besoins des applications vise´es, et donc moins ge´ne´raliste ou alors apportant une plus-value par rapport aux produits du marche´, – par des raisons de strate´gie d’entreprise (maıˆtrise comple`te du produit).

& Socie´te´ : Wind River (http://www.windriver.com) VxWorks 5.x : ce produit est l’avant-dernie`re version du syste`me d’exploitation qui a fait la re´putation de la socie´te´, c’est aussi la version la plus re´pandue. C’est un tre`s complet RTOS avec beaucoup de services, offrant ainsi de nombreux et parfois complexes mode`les d’applications (car difficiles a` analyser d’un point de vue comportemental, et donc de la pre´dictibilite´). Il offre une certaine compatibilite´ POSIX‚ 1003.1 et anciennement 1003.1b et 1003.1c. L’offre, en termes de processeurs cibles est tre`s importante, et la plateforme de de´veloppement tre`s riche (Tornado pour la se´rie 5. x). La socie´te´ a e´te´ rachete´e en 2009 par Intel.

Les produits se rattachent souvent a` un standard. Ainsi autant que l’offre de produits il faut parler de l’offre de standards car c’est cela qui infle´chit l’offre (commerciale ou non). Historiquement, de nombreuses tentatives de standardisation des exe´cutifs ge´ne´ralistes ont eu lieu sans qu’aucune n’ait obtenu un cre´dit suffisant aupre`s des utilisateurs et/ou des fournisseurs. On peut citer en premier lieu MOSI (Microprocessor operating system interface standard) [38] influence´ par iRMX d’Intel, qui est devenu le standard IEEE 855 en 1984. De meˆme RTEID (Real time executive interface definition) fut propose´, peu apre`s, par Motorola aupre`s des utilisateurs du produit VME Exec. ORKID (Open real time kernel interface definition) fut propose´ par l’organisme VITA, regroupement d’utilisateurs du bus VME. ORKID a semble´ eˆtre influence´ par pSOS d’Integrated System (produit repris ensuite par Wind River). SCEPTRE 2 (1992) fut une proposition franc¸aise issue d’un groupe de travail finance´ par le programme STRIN (Solutions temps re´el pour l’industrie). Ces travaux faisaient suite a` ceux de 1982 qui avaient conduit au rapport SCEPTRE, proposition de standardisation du cœur des exe´cutifs, qui a influence´ la re´alisation de plusieurs exe´cutifs franc¸ais (RTC de GSI-Tecsi, par exemple).

& Socie´te´ : GreenHILLs Software Inc. (http://www.ghs.com) La socie´te´ s’enorgueillit d’eˆtre celle qui a la plus forte croissante observe´e sur les anne´es 2002 a` 2007 (source : VDC Embedded Market Study 2007). velOSity RTOS : c’est le noyau d’INTEGRITY, le produit phare et complet de la socie´te´. Il est conc¸u pour utiliser une me´moire non prote´ge´e. Il posse`de une petite empreinte me´moire tre`s rapide (latence minimale obtenue par validation quasi permanente des interruptions). m-velOSity Real-Time Microkernel : c’est un noyau temps re´el basique offrant des services pour le multitaˆches avec une empreinte tre`s faible (quelques kilooctets ROM et RAM). & Socie´te´ : OSE ENEA (http://www.enea.com)

De`s 1995, les travaux dans le milieu automobile de´bouche`rent dans les anne´es 2000 sur la proposition OSEK/VDX (Offene systeme und deren schnittstellen fu¨r die elektronik im kraftfahrzeug/vehicle distributed executive), support d’exe´cution temps re´el pour l’« e´lectronique embarque´e » dans les automobiles. Ces travaux ont ensuite e´te´ poursuivis par le consortium AUTOSAR en 2003, en s’appuyant, pour le logiciel de base, sur la proposition OSEK/VDX.

La famille de produits de la socie´te´ ne se re´fe`re a` aucun standard. Trois produits sont propose´s, tre`s optimise´s pour une gamme d’application. Enea OSE Multicore RTOS : c’est le produit phare, pense´ pour des architectures multicœurs (architectures AMP/SMP) et les syste`mes re´partis. La re´putation de ce produit a souvent e´te´ fonde´e sur un service d’IPC (Inter process communication) tre`s efficace (directmessage-passing model) : tous les processus ne communiquent que par message.

Vers la meˆme e´poque, les travaux dans le milieu ae´ronautique de´bouche`rent en 1996 sur la premie`re publication de ARINC 653, standard d’interface Application/OS pour les applications avioniques.

S 8 052 – 2

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＲ –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– SYSTE`MES D’EXPLOITATION TEMPS RE´EL – EXEMPLES D’EXE´CUTIFS INDUSTRIELS

A` partir de 1998 des travaux communs se sont de´roule´s au sein d’un groupe de travail nomme´ « Austin group » (du lieu de la re´union fondatrice au Texas). Ce groupe comprenait des membres de l’IEEE PASC (Portable applications standards commitee), des membres de l’Open group et des membres de l’ISO/IEC Joint technical commitee 1 ; il s’agit donc d’un effort combine´ de comite´s de normalisation et d’industriels du logiciel. L’objectif du groupe e´tait de re´viser et combiner diffe´rents standards en partant de la spe´cification « Single UNIX‚ specification, version 2 » de l’Open group car elle e´tait un sur ensemble des travaux POSIX‚ (hors 1003.13). Les premiers re´sultats ont e´te´ produits en 2001, l’IEEE Std 1003.1, l’ISO/IEC 9945 et l’Open group base specifications issue 6 constituant le cœur de la Single UNIX‚ specification version 3. Une mise a` jour correctrice a ensuite e´te´ e´dite´e en 2004, et des travaux sont toujours en cours organise´s par l’Austin group. Nous utiliserons dans la suite la de´nomination POSIX‚ 1003.1.

Enea OSEck : cette version, moins riche que le pre´ce´dent produit, est spe´cialise´e pour les DSP (la socie´te´ a beaucoup de de´bouche´s dans les te´le´communications). Enea OSE Epsilon : une version tre`s compacte du syste`me d’exploitation, optimise´ pour les syste`mes a` faible ressource a` base de microcontroˆleurs. & Socie´te´ : Micrium (http://www.micrium.com) mC/OS-II : il s’agit d’un noyau multitaˆches pre´emptif certifie´ DO178B niveau A. & Socie´te´ : FreeRTOS (http://www.freertos.org) FreeRTOS : il s’agit d’un noyau temps re´el en version open source. Un autre produit de la meˆme socie´te´, SafeRTOS, est une version similaire mais certifie´ par un organisme de certification ¨ V SU ¨ D). allemand (TU & Socie´te´ : DDC-I (http://www.ddci.com)

3.1.2 Aperc¸u de quelques caracte´ristiques de POSIX 1003.1

Deos (DDC-I embedded operating system) : Deos est un RTOS certifie´ DO-178B niveau A. Il affiche une protection me´moire qui est en fait une se´paration entre les espaces me´moire noyau et taˆches utilisateur. Dans cette protection spatiale les taˆches peuvent cependant eˆtre contraintes quant a` la me´moire utilise´e. Dans le domaine temporel on peut avoir des budgets temporels alloue´s aux taˆches (pourcentage d’utilisation CPU). De plus un algorithme d’utilisation du « slack » (le temps libre) permet de le re´allouer (les taˆches « anytime » sont e´voque´es, c’est un type de taˆches qui ame´liorent les re´sultats produits au fur et a` mesure de leur exe´cution).

Le standard est organise´ autour de quatre parties repre´sentant plus de 400 pages : – les de´finitions et conventions utilise´es dans la spe´cification ainsi que les prototypes ne´cessaires en langage C, – les interfaces applicatives, – la description du shell (langage de commandes) et les utilitaires, – un ensemble de justifications de ce qui a e´te´ propose´. Nota : Pour se le procurer voir : http://www.unix.org/version3

& Socie´te´ : Microsoft (http://www.microsoft.com/windowsembedded)

Le standard est une de´finition d’interfaces, en aucun cas une imple´mentation. Il a pour objectif principal de permettre la portabilite´ des applications, au niveau source, sur les syste`mes UNIX‚, quel qu’en soit le fournisseur, en s’appuyant principalement sur le langage C. POSIX‚ 1003.1 rassemble ce qui e´te´ auparavant disperse´ dans divers standards (1003.1, 1003.1b, 1003.1c, 1003.1d…, 1003.2…), suite au travaux de l’Austin group, et les aspects temps re´el se retrouvent sous forme optionnelle (le cœur du standard est tout de meˆme l’UNIX‚ historique !).

Windows Embedded CE : un syste`me d’exploitation temps re´el, modulaire qui apporte la dimension temps re´el aux autres produits Microsoft, avec lesquels il est pre´vu pour coope´rer. La version actuelle est 6.0R2.

3. Exe´cutifs UNIX temps re´el

3.1.2.1 Gestion des threads, l’ordonnancement

On rappelle, comme cela a e´te´ indique´ en [R 8 050], que deux approches principales ont e´te´ suivies dans les de´veloppements temps re´el autour d’UNIX‚ :

Un processus UNIX‚ est un espace me´moire prote´ge´ dans lequel peuvent s’exe´cuter un ou plusieurs threads (la notion de taˆche dans l’exe´cutif ge´ne´raliste) concurrents et coope´rants. Les threads ne peuvent exister qu’a` l’inte´rieur d’un processus ; aussi, si le processus est de´truit, les threads le sont e´galement. La gestion de la « vie » d’un thread se fait en trois e´tapes :

1) l’une dans la mouvance du standard POSIX‚ : elle consiste a` enrichir le standard par des services adapte´s aux temps re´el ; 2) l’autre, plus tardive, dans la mouvance de LINUX‚. Cette dernie`re peut eˆtre a` nouveau scinde´e en deux approches :

1) la cre´ation d’une structure de donne´es et son initialisation (les attributs du thread). Les types des e´le´ments de cette structure ne sont pas manipule´s directement par l’application (types dits « opaques ») ; ils sont manipule´s au travers de fonctions ;

– celle qui consiste a` rendre le noyau pre´emptif, confe´rant ainsi des capacite´s de re´action temps re´el pour les applications, – celle qui consiste a` utiliser un noyau temps re´el qui conside`re LINUX‚ comme l’une de ses taˆches, avec une faible priorite´. C’est le noyau qui prend le controˆle des interruptions et du processeur.

2) la cre´ation et l’activation du thread ; 3) la terminaison du thread (si ne´cessaire) et l’exe´cution des fonctions de nettoyage (cleanup) associe´es.

3.1 Aperc¸u de POSIX

Les structures de donne´es associe´es a` un thread indiquent les principaux e´le´ments suivants :

3.1.1 Historique de POSIX

– la taille (minimale) de sa pile, – sa priorite´ statique, – le type d’ordonnanceur utilise´, – un boole´en qui indique si, oui ou non, le futur thread he´rite du type d’ordonnanceur et de la priorite´ de son cre´ateur (celui qui invoque le service de cre´ation). Dans ce cas, les deux champs pre´ce´dents ne sont pas significatifs.

Le nom POSIX‚ est une marque enregistre´e de l’IEEE. Il signifie portable operating system interface, le X e´tant la` pour rappeler le lien avec UNIX‚. C’est dans les anne´es 1980 qu’ont commence´ les travaux pour standardiser l’interface applicative d’UNIX‚, au niveau source, ce besoin se faisant alors fortement ressentir. La premie`re proposition a` laquelle a e´te´ associe´ le nom POSIX‚ est l’IEEE Std 1003.1-1988, a` laquelle ont succe´de´ des re´visions. Celle de 1990 a e´galement e´te´ approuve´e comme un standard international ISO/ IEC 9945-1:1990, et elle a apporte´ les services pour le temps re´el avec les parties 1003.1b et 1003.1c. C’est dans la version de 1998 que les profils temps re´el sont apparus (IEEE Std 1003.13-1998).

La cre´ation du thread se fait dans le contexte du processus courant a` l’aide des attributs de la structure mentionne´e ci-avant. De plus, on associe au thread une fonction (cas du langage C) contenant son algorithme, et un identificateur lui est alloue´ par le noyau.

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＲＹ

S 8 052 – 3

Ｒ

Ｒ

ＳＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ

Ordonnancement temps re´el Ordonnancement monoprocesseur par

Emmanuel GROLLEAU Professeur des universite´s en Informatique a` l’ISAE-ENSMA (Chasseneuil du Poitou)

Michae¨l RICHARD

Ｒ

Maıˆtre de confe´rences en Informatique a` l’ISAE-ENSMA (Chasseneuil du Poitou)

Pascal RICHARD Professeur des universite´s en Informatique a` l’universite´ de Poitiers et

Fre´de´ric RIDOUARD Maıˆtre de confe´rences en Informatique a` l’universite´ de Poitiers

1. 1.1

1.2

1.3

1.4 1.5

2. 2.1 2.2

2.3

2.4

Architectures des applications temps re´el ................................ Architecture mate´rielle ....................................................................... 1.1.1 Syste`mes centralise´s ............................................................... 1.1.2 Syste`mes re´partis .................................................................... Architecture logicielle ........................................................................ 1.2.1 Syste`mes d’exploitation et exe´cutifs ...................................... 1.2.2 De´veloppement des applications ............................................ Principes fondamentaux de l’ordonnancement temps re´el .............. 1.3.1 Principales proble´matiques ..................................................... 1.3.2 Faisabilite´ et ordonnanc¸abilite´ ................................................ Mode`les de taˆche ............................................................................... Algorithmes d’ordonnancement ........................................................ 1.5.1 Ordonnancement ge´ne´raliste .................................................. 1.5.2 Principales politiques d’ordonnancement pour le temps re´el 1.5.3 Proprie´te´s ................................................................................. 1.5.4 Mesures de performance ........................................................ Tests d’ordonnanc¸abilite´ ............................................................... Principes ............................................................................................. Taˆches inde´pendantes ........................................................................ 2.2.1 Ordonnancement a` priorite´ fixe aux taˆches ........................... 2.2.2 Ordonnancement a` priorite´s fixes au travaux ........................ 2.2.3 Ordonnancement a` priorite´ dynamique ................................. Taˆches de´pendantes ........................................................................... 2.3.1 Pre´ce´dences ............................................................................. 2.3.2 Partage de ressources ............................................................. Taˆches ape´riodiques ........................................................................... 2.4.1 Serveurs a` priorite´s fixes aux taˆches ...................................... 2.4.2 Serveurs a` priorite´s fixes aux travaux ....................................

S 8055v2 — — — — — — — — — — — — — — — — — — — — — — — — — — —

–4 4 4 5 6 6 8 10 10 11 12 13 13 14 15 17 17 17 18 18 21 23 23 23 25 26 26 27

Pour en savoir plus.................................................................................. Doc. S 8 055v2

es syste`mes informatiques peuvent eˆtre classe´s en trois cate´gories : les syste`mes transformationnels, les syste`mes re´actifs et les syste`mes interactifs. Les syste`mes transformationnels transforment des donne´es d’entre´e en donne´es de sortie a` leur propre rythme, sans interaction avec leur environnement. Les syste`mes interactifs repre´sentent typiquement la classe des programmes avec une interface graphique. Ils re´pondent aux demandes d’un utilisateur, et il est bienvenu qu’ils y re´pondent rapidement. Les syste`mes re´actifs sont en charge de controˆler des proce´de´s. Un proce´de´ est un syste`me physique a` controˆler, posse´dant son propre environnement. Par conse´quent, le syste`me re´actif doit re´agir suffisamment rapidement par rapport a` la dynamique du

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｪｵｩｮ＠ＲＰＱＳ

L

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＱ

S 8 055v2 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Ｒ

proce´de´ controˆle´ et de son environnement. Contrairement aux autres cate´gories, les syste`mes re´actifs ne pre´sentent pas de comportements re´currents : le proce´de´ e´voluant avec sa propre dynamique dans un environnement souvent complexe, il est rare que des sce´narios d’exe´cution syste`me re´actif/e´volution du proce´de´ dans son environnement soient reproductibles. Les syste`mes informatiques controˆlant des proce´de´s physiques critiques, notamment dans le domaine du transport, de l’exploration autonome, etc., sont typiquement embarque´s sur le proce´de´ lui-meˆme. On parle alors de syste`me embarque´ critique. De tels syste`mes sont souvent soumis a` des contraintes de temps inhe´rentes a` la dynamique du proce´de´ controˆle´. On dit alors qu’ils sont temps re´el. Un syste`me temps re´el est un syste`me re´actif, en charge de s’assurer du maintien d’un proce´de´ (drone, syste`me automobile ou avionique, etc.) dans un e´tat de´sire´, tout en assurant une re´activite´ du syste`me qui soit cohe´rente avec les contraintes de temps inhe´rentes au proce´de´ et a` son environnement. Malgre´ l’accroissement de la puissance des calculateurs, d’abord en fre´quence, puis en nombre de cœurs de calcul depuis le de´but des anne´es 2000, les calculateurs embarque´s sont dimensionne´s au plus juste des besoins en puissance de calcul de fac¸on, notamment, a` minimiser l’e´nergie consomme´e, et donc l’autonomie du proce´de´. Deux hypothe`ses sont commune´ment a` la base d’un partitionnement au niveau des mode`les, des me´thodes et des proble´matiques traite´s : l’hypothe`se synchrone et l’hypothe`se asynchrone. L’hypothe`se synchrone conside`re que les traitements sont de´clenche´s directement par l’arrive´e d’e´ve´nements. Les traitements sont conside´re´s comme ayant une dure´e nulle, ou en tout cas infe´rieure a` l’e´cart minimal se´parant deux e´ve´nements de´clencheurs successifs. L’hypothe`se asynchrone se repose sur le paradigme de programmation multitaˆche : des e´ve´nements peuvent, comme dans le cas synchrone, de´clencher des traitements. Cependant, les traitements sont conside´re´s de dure´e non nulle. Par conse´quent, un traitement peut eˆtre pre´empte´ par un autre, c’est-a`-dire interrompu, et mis en attente, pour affecter les ressources de calcul a` un autre traitement plus prioritaire par exemple. Dans le cadre de cet article, nous conside´rons l’hypothe`se asynchrone. Nous conside´rons que cette hypothe`se est re´aliste, notamment dans le cas des syste`mes embarque´s. Dans ce cas, les ressources de calcul se doivent d’eˆtre dimensionne´es au plus juste de fac¸on a` maximiser l’autonomie e´nerge´tique du syste`me. L’un des points centraux sous-jacents a` l’hypothe`se asynchrone est la gestion des ressources de calcul, et notamment du processeur. En fonction des traitements a` exe´cuter a` un instant donne´, que nous appellerons des taˆches, c’est le roˆle de l’ordonnanceur de de´cider quelle taˆche est exe´cute´e sur le processeur, en fonction d’une strate´gie d’ordonnancement. L’ordonnanceur est l’entite´ centrale du noyau, cœur de l’exe´cutif ou syste`me d’exploitation en charge de la gestion des ressources mate´rielles. Parmi les taˆches preˆtes a` eˆtre exe´cute´es, il choisit la taˆche a` exe´cuter suivant une certaine strate´gie. Il y a deux grandes familles d’ordonnanceur : les ordonnanceurs enligne connaissent l’e´tat courant des taˆches actives, et se basent souvent sur des priorite´s pour choisir la taˆche a` e´lire. Les ordonnanceurs hors-ligne, souvent appele´s se´quenceurs, se basent sur la connaissance totale du syste`me actuel, et de son futur, qui a permis, hors-ligne, de baˆtir a` l’avance une se´quence d’ordonnancement qui est suivie a` l’exe´cution. Dans cet article, nous parlerons principalement d’ordonnancement en-ligne qui est le type d’ordonnancement le plus re´pandu. Le syste`me de controˆle est donc multitaˆche, et les taˆches sont ordonnance´es par l’ordonnanceur. Il s’informe de l’e´tat courant du proce´de´ controˆle´ a` l’aide de capteurs, et agit sur celui-ci a` l’aide d’actionneurs. Les contraintes de temps peuvent eˆtre de deux natures : les contraintes de bout-en-bout concernent une chaıˆne de traitement partant d’un ensemble de capteurs et se terminant a` un ensemble d’actionneurs ; des contraintes locales dues a` des limitations mate´rielles. Ainsi, lorsqu’un capteur fournit des informations au syste`me en utilisant un bus de communication, sans l’aide d’un dispositif de me´morisation

S 8 055v2 – 2

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– ORDONNANCEMENT TEMPS RE´EL

(de type buffer), le syste`me doit lire des donne´es entrantes avant qu’elles ne soient e´crase´es par les suivantes. Il arrive aussi qu’une commande envoye´e a` un actionneur doive absolument eˆtre rafraıˆchie a` un certain rythme. De fac¸on ge´ne´rale, dans la the´orie utilise´e pour la validation temporelle, toutes les contraintes temporelles, qu’elles soient locales ou de bout-en-bout, sont traduites sous forme de contraintes locales sur les taˆches. Le respect des contraintes temporelles est plus ou moins important : la violation de certaines contraintes peut mettre le syste`me ou bien son environnement en pe´ril : on parle alors de contraintes strictes. Au contraire, certaines contraintes concernent uniquement la qualite´ du service rendu par le syste`me, dans ce cas on parle de contraintes relatives. Par exemple, l’attitude d’un ae´ronef peut eˆtre instable si le controˆle d’attitude (tangage, roulis) ne peut eˆtre exe´cute´ une fois toutes les 50 millisecondes. Les contraintes de temps applique´es aux taˆches du controˆle d’attitude sont strictes. On parle de contraintes fermes lorsque, sur une feneˆtre temporelle donne´e, un certain nombre de contraintes doivent eˆtre respecte´es afin de garantir l’inte´grite´ du syste`me. Respecter toutes les contraintes de temps augmente dans ce cas la qualite´ de service de l’application. On trouve peu de contraintes relatives dans le domaine du transport, mais on peut en trouver dans les applications non critiques telles les applications multime´dia, ou le jeu vide´o. Dans cet article, seules les contraintes strictes sont conside´re´es.

Ｒ

La proble´matique qui nous inte´resse ici est comment assurer qu’e´tant donne´ un syste`me de taˆches partageant des ressources de calcul, toutes les contraintes temporelles seront toujours respecte´es : c’est la validation temporelle, qui repose sur une e´tude d’ordonnanc¸abilite´. Re´soudre ce proble`me permet aussi de re´pondre a` la question du dimensionnement : quelles ressources de calcul sont-elles ne´cessaires a` une application temps re´el donne´e ? Il est important de garder a` l’esprit que « temps re´el » ne signifie pas « rapidite´ », mais « temporellement de´terministe ». Ainsi, on privile´gie toujours le de´terminisme a` la vitesse d’exe´cution moyenne. La validation temporelle repose en effet sur le fonctionnement pire cas du syste`me : il est primordial, sur un syste`me critique, que le syste`me ne se comporte jamais de manie`re errone´e, et il est ge´ne´ralement intole´rable que le syste`me ne se comporte tre`s bien qu’en moyenne, en e´tant parfois errone´. La validation des syste`mes critiques se base donc sur les pires comportements du syste`me : elle se doit donc d’eˆtre conservative, on parle aussi de pire cas. Cet article est structure´ de la fac¸on suivante : afin de pre´senter le contexte global dans lequel la proble´matique de l’ordonnancement est souleve´e, le chapitre 1 introduit les architectures mate´rielles et logicielles des applications. Nous verrons en particulier le fonctionnement de base des syste`mes d’exploitation temps re´el. Apre`s avoir introduit les principes fondamentaux de l’ordonnancement temps re´el, nous pre´sentons les mode`les temporels des taˆches, qui seront utilise´s lors de la validation temporelle. Ce chapitre introduit enfin les principaux types d’algorithmes d’ordonnancement, et les proprie´te´s et mesures permettant de les caracte´riser. Le chapitre 2 se focalise sur les tests d’ordonnanc¸abilite´, c’est-a`-dire sur les moyens utilise´s pour montrer qu’un syste`me ordonnance´ par un ordonnanceur respectera toujours toutes ses contraintes de temps. Nous commenc¸ons par les mode`les les plus simples (taˆches inde´pendantes), pour lesquels nous montrons les types de tests, classe´s par familles d’algorithmes d’ordonnancement conside´re´es. Nous e´largissons ensuite ces tests au cas de taˆches communicantes ou se synchronisant. Les derniers chapitres introduisent des outils lie´s a` l’analyse d’ordonnanc¸abilite´ et des points d’entre´e vers des travaux plus spe´cifiques. Tout au long de cet article, certains points d’entre´e de re´fe´rences bibliographiques seront cite´s. Le lecteur est invite´ a` consulter [Doc. S 8 055v2] pour trouver les re´fe´rences comple`tes des travaux cite´s.

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＳ

S 8 055v2 – 3

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

1. Architectures des applications temps re´el

Les syste`mes embarque´s centralise´s comportent souvent un calculateur a` logique programme´e (microprocesseur ou microcontroˆleur), sur lequel le syste`me de controˆle s’exe´cute, et peut eˆtre aise´ment modifie´. On lui adjoint un certain nombre de circuits inte´gre´s spe´cialise´s effectuant les calculs trop longs ou complexes pour eˆtre pris en charge par le calculateur. Par exemple, la nume´risation d’une vide´o en temps re´el de qualite´ TV demande soit un processeur cadence´ a` plusieurs centaines de MHz, soit l’utilisation d’un ASIC spe´cialise´ pour cette taˆche.

1.1 Architecture mate´rielle

Ｒ

Le type d’architecture mate´rielle servant a` exe´cuter une application temps re´el a un impact important non seulement sur l’architecture logicielle de l’application, mais aussi sur les moyens utilise´s pour valider temporellement ce syste`me. On classe les syste`mes en deux cate´gories : les syste`mes centralise´s, s’exe´cutant sur une seule puce, alors que les syste`mes re´partis s’exe´cutent sur diffe´rents calculateurs distants les uns des autres.

Depuis le de´but des anne´es 2000, la miniaturisation des circuits s’approchant des limites physiques (transistors de la taille de quelques dizaines d’atomes), les ame´liorations des processeurs en fre´quence de fonctionnement sont de moins en moins marque´es au fil des ge´ne´rations de processeurs. En effet, la consommation d’une puce avec des transistors donne´s (finesse de gravure) est fonction du carre´ de la fre´quence de fonctionnement de celle-ci. La puissance de calcul est donc ame´liore´e par l’utilisation de plusieurs cœurs de calcul fonctionnant en paralle`le sur une meˆme puce : on parle de calculateurs multicœurs. Alors que l’ave`nement du multicœur est de´ja` bien avance´ dans le monde des ordinateurs personnels, l’utilisation des calculateurs multicœurs est en passe de se de´velopper aussi dans le monde de l’embarque´, notamment en avionique, domaine consommateur de puissance de calcul vu le nombre toujours croissant de fonctionnalite´s ge´re´es par le syste`me embarque´. La proble´matique de l’ordonnancement multicœur est pre´sente´e dans l’article [S 8 052].

1.1.1 Syste`mes centralise´s 1.1.1.1 Calculateurs On qualifie de centralise´ un syste`me qui s’exe´cute sur une seule puce, meˆme si cette puce peut avoir plusieurs cœurs de calcul. Le type de support peut eˆtre un microcontroˆleur, un microprocesseur, un processeur de signal nume´rique, ou encore un circuit inte´gre´ spe´cialise´ ; a` part les circuits inte´gre´s qui sont a` logique caˆble´e, les autres supports physiques sont a` logique programme´e. Nous utiliserons le terme ge´ne´rique de calculateur ou processeur pour les supports a` logique programme´e. Le syste`me peut s’appuyer sur des calculateurs secondaires spe´cialise´s dans certains traitements, qui peuvent eˆtre internes ou externes.

1.1.1.2 Entre´es/sorties Un syste`me temps re´el est, la plupart du temps, un syste`me de controˆle/commande. Il doit donc pouvoir mesurer l’e´tat du proce´de´ controˆle´ par le biais de capteur (des entre´es) et modifier l’e´tat du proce´de´ via des actionneurs (sorties). Le passage d’information entre le calculateur et les capteurs et actionneurs peut eˆtre de trois types :

La puissance de calcul se mesure en FLOPS (nombre d’ope´rations en nombres flottants par secondes) ou bien en MIPS (millions d’instructions par seconde). La puissance de calcul de´pend fortement de la fre´quence de fonctionnement interne du calculateur, mesure´e en Hertz (en MHz-me´gahertz ou GHz-gigahertz pour les processeurs).

 Par un signal e´lectrique a` deux e´tats (typiquement 0 ou 5 V ou encore - 2,5 V ou + 2,5 V), on parle d’entre´e/sortie nume´rique. D’un point de vue logique, une ligne nume´rique est une information binaire, qui, d’un point de vue logique, est associe´e a` un bit d’information. Pour la plupart des calculateurs manipulant au minimum des octets (groupes de 8 bits), les lignes sont regroupe´es par 8, 16 ou 32 en ce que l’on appelle des ports. Ainsi, supposons qu’un calculateur soit lie´ a` 8 capteurs de passage, fournissant chacun une tension de 0 V si pas de passage, ou 5 V si un ve´hicule passe sur le capteur : on branche typiquement les 8 lignes nume´riques correspondantes a` un meˆme port d’entre´e nume´rique du calculateur. La lecture du port donne l’e´tat des 8 capteurs, chaque bit correspondant a` l’e´tat d’un capteur. Il en va de meˆme pour les actionneurs : par exemple le pilotage d’un relai e´lectrique est typiquement une sortie nume´rique. On peut noter que d’un point de vue e´lectronique, il est assez simple d’utiliser physiquement le meˆme connecteur qui sera configure´, via le logiciel, soit en entre´e, soit en sortie. Ainsi, sur les microcontroˆleurs, ou bien sur les cartes d’extension dites cartes d’acquisition, on parle d’entre´es/sorties nume´riques.

Un microprocesseur, a` l’instar des microprocesseurs pre´sents dans les ordinateurs personnels, se caracte´rise par une haute fre´quence de fonctionnement, mais aussi par une consommation e´lectrique relativement e´leve´e par rapport aux autres calculateurs, et une absence quasi-totale de moyens d’entre´es-sorties. Un microprocesseur a besoin d’une carte-me`re, qui dispose de moyens d’entre´es-sorties ou bien permet de disposer d’entre´es/sorties par le biais de carte d’extension comme les cartes d’acquisition. Par conse´quent, un couple microprocesseur/carte-me`re est relativement encombrant, a une consommation e´lectrique e´leve´e et donc une production de chaleur relativement importante, pour une puissance de calcul importante. Un microcontroˆleur est dote´ d’entre´es-sorties et peut fonctionner inde´pendamment d’une carte-me`re. Il peut eˆtre directement mis sur un circuit relativement simple. Peu consommateur d’e´nergie, il est en revanche conside´rablement plus lent que les microprocesseurs de la meˆme ge´ne´ration. Parmi les calculateurs a` logique programme´e, le microcontroˆleur est le plus repre´sentatif des calculateurs embarque´s sur des syste`mes critiques, graˆce a` ses qualite´s multiples : faible couˆt, faible encombrement, faible de´perdition de chaleur, entre´es/sorties inte´gre´es, simplicite´ d’inte´gration.

 Par un signal e´lectrique e´voluant de fac¸on continue entre deux bornes, typiquement entre 0 et 10 V, on parle d’entre´e analogique ou de sortie analogique. Un exemple typique d’entre´e analogique est un de´bitme`tre : apre`s e´talonnage, on de´finit une fonction de conversion qui prend en entre´e le voltage de la ligne, et donne en sortie le de´bit correspondant. Une e´lectrovanne a` de´bit variable est un exemple typique d’actionneur analogique : le syste`me peut piloter l’ouverture de l’e´lectrovanne en lui envoyant une tension comprise entre 0 et 10 V. Ces circuits ne´cessitent des conversions relativement complexes : voltage vers repre´sentation nume´rique point fixe, ou point fixe vers voltage. Par conse´quent, les entre´es et les sorties analogiques sont ge´ne´ralement des e´le´ments disjoints. Souvent les entre´es analogiques partagent un meˆme circuit de conversion analogique-nume´rique par le biais du multiplexage ; en

Les circuits inte´gre´s spe´cialise´s (ASIC), peuvent eˆtre re´alise´s totalement sur mesure pour les besoins d’une fonctionnalite´, ce qui entraıˆne un rapport puissance/couˆt unitaire tre`s bas, mais ne´cessitent alors un long et couˆteux processus de conception. Ce type d’ASIC est de´veloppe´ pour des fonctionnalite´s tre`s re´pandues (par exemple des puces 3G, 4G, ou encore des controˆleurs pre´sents sur la plupart des micro-ordinateurs, ou dans les MODEM). Pour un plus haut couˆt unitaire, mais plus de flexibilite´ (notamment la possibilite´ de modification du comportement par syste`me de patch, c’est-a`-dire sans remplacement mate´riel) et une rapidite´ de conception comparable a` celle d’un logiciel, les ASIC peuvent aussi utiliser des circuits programmables tels que le FPGA.

S 8 055v2 – 4

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– ORDONNANCEMENT TEMPS RE´EL

2. Un re´cepteur GPS est muni d’une antenne patch qui permet, par triangulation de signaux satellites, de calculer notamment la position, la vitesse, la vitesse ascensionnelle, et le cap. Ce capteur intelligent envoie les informations sous la forme de trames, transmises octet par octet sur un bus se´rie. Le drone utilise une station sol comme organe de dialogue avec l’ope´rateur.

revanche, chaque sortie analogique doit posse´der son propre circuit de conversion nume´rique analogique.  Via un bus de communication, comme les bus se´rie (EIA RS232), USB (Universal Serial Bus), CAN (Controller Area Network), etc. Dans ce cas, le capteur, ou l’actionneur, comprend un ensemble de protocoles et le syste`me conside´re´ doit eˆtre capable de comprendre et/ou parler ces protocoles. Par exemple, un re´cepteur GPS tel que celui du drone utilise´ en exemple posse`de sa propre ressource de calcul (un microcontroˆleur interne), dont le roˆle est de scruter les signaux perc¸us des satellites de fac¸on a` ope´rer une triangulation, et calculer sa position, sa vitesse, sa vitesse ascensionnelle, son cap, etc. Le calculateur du GPS e´labore alors, en respectant l’un des formats NMEA (ensemble de formats de repre´sentation des informations GPS de´fini par un ensemble de fabricants), une trame, c’est-a`-dire un ensemble d’octets d’information. Cette trame, d’une centaine d’octets environ, est e´mise quatre fois par seconde sur une liaison se´rie EIA RS-232, octet par octet. Le calculateur du drone doit alors non seulement eˆtre muni d’un port se´rie au format RS-232 lui permettant de recevoir les octets un par un, mais aussi d’eˆtre dote´ d’un programme capable d’interpre´ter les donne´es au format NMEA afin d’interpre´ter les trames rec¸ues lorsqu’elles sont comple`tes. De fac¸on duale, l’e´mission d’informations vers le MODEM (conside´re´ alors comme un actionneur) sans fil s’effectue en utilisant une seconde liaison se´rie RS232, en respectant un protocole de repre´sentation de l’information qui soit commun au drone et a` la station sol. Puisque les capteurs ou actionneurs conside´re´s sont capables de lire ou parler en respectant des protocoles, nous les qualifions de capteurs ou actionneurs intelligents : ils posse`dent force´ment un calculateur interne.

3. Un MODEM sans fil, permettant une communication bidirectionnelle entre le drone et la station sol. L’ope´rateur utilise donc la station sol de fac¸on a` dialoguer avec le syste`me du drone. Ce modem communique via un bus se´rie bidirectionnel avec le calculateur central. Il agit sur la dynamique du proce´de´ a` l’aide de deux actionneurs : des servomoteurs et un variateur de moteur. 4. Des servomoteurs pilotant des gouvernes : en diffe´rentiel, les gouvernes commandent l’ae´ronef en roulis, alors qu’en paralle`le elles le commandent en tangage. Pour la commande, on utilise une sortie nume´rique, couple´e a` un circuit mate´riel d’horlogerie, permettant de ge´ne´rer des fronts hauts ou bas d’une certaine dure´e (signal PPM – Pulse Position Modulation). 5. Un variateur de moteur permettant de commander la puissance moteur, commande´ lui aussi en PPM. Les contraintes de temps, strictes, sont d’un ordre de grandeur de quelques dizaines de millisecondes pour la chaıˆne de traitement de controˆle d’attitude constitue´e des traitements suivants : (1) calcul, a` l’aide d’une centrale inertielle, de l’attitude (tangage, roulis) d’un ae´ronef ;

Le type de capteurs et d’actionneurs utilise´s, de base ou intelligents, a un impact important sur la conception et sur la validation du syste`me.

(1’) en mode assiste´, lecture des consignes (donne´es sous la forme de vitesse ascensionnelle, angle de virage, vitesse) rec¸ues de la station sol via une liaison radio ou bien, en mode autonome, calcul des consignes a` partir d’un algorithme de navigation prenant en entre´e le plan de vol, la position courante, le cap courant et la vitesse ascensionnelle courante ;

1.1.1.3 Exemple d’un ae´ronef miniature

(2) utilisation d’algorithmes d’asservissement pour calculer les commandes de vol a` appliquer ; (3) application des commandes sur les gouvernes et le moteur.

Le proce´de´ conside´re´ pour illustrer de nombreux concepts est un mini-drone (figure 1), ae´ronef de moins d’un kilogramme, e´quipe´ afin d’eˆtre capable de vol autonome. Il embarque les capteurs suivants :

Ce syste`me est conside´re´ comme un syste`me centralise´ utilisant un microcontroˆleur monocœur, meˆme si en y regardant de plus pre`s, nous trouvons, en plus du processeur utilise´ pour controˆler le syste`me un microcontroˆleur embarque´ sur le re´cepteur GPS, et un calculateur FPGA embarque´ sur la centrale inertielle. Ces processeurs secondaires font partie inte´grante de ce que nous appelons des capteurs intelligents. En effet, le re´cepteur GPS et la centrale inertielle, bien que be´ne´ficiant de ressources de calcul propres, ne sont pas disponibles pour d’autres calculs que ce pour quoi ces capteurs ont e´te´ conc¸us, et nous n’en avons pas la maıˆtrise.

1. Une centrale inertielle qui contient trois gyrome`tres monte´s en trie`dre, permettant de calculer la vitesse angulaire autour des trois axes, couple´s a` trois acce´le´rome`tres permettant de caler l’information donne´e par les gyrome`tres sur l’information fournie par la gravite´. C’est un capteur intelligent, envoyant les informations au calculateur central sous forme de trames CAN (re´seau de terrain Control Area Network).

L’ope´rationnel en charge de la gestion des ressources mate´rielles, et de l’ordonnancement, est conforme a` la norme Osek, qui est l’une des nombreuses normes de´finissant les interfaces de programmation et les fonctionnalite´s des exe´cutifs temps re´el (§ 1.2.1).

Période = 150 ms Envoyer données MODEM

Gouvernes

Réguler attitude Centrale inertielle

Moteur Période = 250 ms

Lire consignes MODEM

On parle de syste`me re´parti lorsque le syste`me conside´re´ est constitue´ de plusieurs calculateurs connecte´s par un re´seau de communication. Dans le domaine des syste`mes temps re´el, les re´seaux de communication utilise´s sont ge´ne´ralement des bus dits de terrain car ils sont relativement simples, de´terministes et robustes aux conditions exte´rieures. Exemples de bus de terrain [S 8 140] et [S 8 152] : CAN (Control Area Network), AFDX Avionics Full DupleX), FlexRay, etc.

Commandes

Période = 20 ms

Période = 100 ms

1.1.2 Syste`mes re´partis

La validation de syste`mes re´partis a lieu en deux phases interde´pendantes : validation au niveau temps de transmission pire cas des messages, et impact sur l’ordonnancement des calculateurs. Les techniques utilise´es pour mesurer l’impact sur l’ordonnancement des calculateurs sont similaires a` celles que nous verrons dans cet article. La validation des syste`mes re´partis est aborde´e dans l’article [S 8 056].

Lire GPS Récepteur GPS

Figure 1 – Un mini-drone et son syste`me embarque´

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＵ

S 8 055v2 – 5

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＵ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

variables locales sont place´es en sommet de pile. A` la terminaison du sous-programme, ses variables locales sont « de´pile´es » (supprime´es du sommet de la pile), ainsi que les parame`tres d’appel, et l’adresse de retour qui permet de trouver l’endroit dans le code auquel revenir a` la fin du sous-programme. La pile se retrouve alors dans le meˆme e´tat qu’avant l’appel de sous-programme. Toute exe´cution se´quentielle ne´cessite donc l’emploi d’une pile, et chaque taˆche, ainsi que le programme principal, posse`de sa propre pile. On peut donc voir une taˆche comme un sous-programme muni d’une pile, ce qui lui permet de s’exe´cuter paralle`lement au programme principal et aux autres taˆches. Mais la structure d’une taˆche fait qu’elle est elle-meˆme se´quentielle. Notons que toutes les taˆches d’une meˆme application peuvent acce´der sans limite et sans controˆle a` toute la me´moire de l’application.

1.2 Architecture logicielle 1.2.1 Syste`mes d’exploitation et exe´cutifs Le noyau est une couche logicielle permettant la gestion de l’acce`s aux ressources mate´rielles. Le noyau posse`de au minimum un ordonnanceur permettant d’allouer le (ou les) processeur(s) aux diffe´rentes entite´s paralle`les de l’application. Il ge`re les interruptions mate´rielles et permet de de´clencher des traitements appele´s routines de traitement d’interruption (ISR-Interrupt Service Routine) sur occurrence d’interruption mate´rielle. Il permet aussi, sur certains syste`mes, d’assurer la gestion de la me´moire.

Dans les syste`mes d’exploitation ge´ne´ralistes, et dans de rares RTOS, un second niveau de paralle´lisme est introduit : c’est le processus. Un processus est une entite´ paralle`le, elle-meˆme pouvant eˆtre multitaˆche, dont la me´moire est isole´e du reste des processus. Ainsi, les syste`mes d’exploitation ge´ne´ralistes permettent de partitionner totalement les processus, garantissant ainsi confidentialite´ et robustesse entre processus s’exe´cutant sur un meˆme syste`me. En effet, qu’un processus ait un comportement errone´ ou byzantin ne peut pas, en the´orie, nuire aux autres processus s’exe´cutant sur le meˆme syste`me. La notion de processus est rarement pre´sente dans les RTOS, car elle ne´cessite plus de ressources de calcul, et une gestion de la me´moire assiste´e par un dispositif mate´riel, la MMU (Memory Management Unit) que l’on ne trouve qu’occasionnellement sur les microcontroˆleurs.

Enfin, un syste`me d’exploitation est constitue´ d’un exe´cutif, et fournit a` l’utilisateur des moyens de gestion du syste`me, tels un shell permettant une interaction utilisateur/syste`me, un certain nombre d’outils de de´veloppement, de de´verminage et de trac¸age. La diffe´rence entre noyau, exe´cutif et syste`me d’exploitation est illustre´e sur la figure 2. Aujourd’hui, seul un type de syste`mes d’exploitation, UNIX, base´ sur la norme POSIX, et un syste`me d’exploitation proprie´taire, Microsoft Windows, se partagent le marche´ des ordinateurs personnels : ce sont des syste`mes d’exploitation ge´ne´ralistes. Dans le domaine de l’embarque´, on trouve de nombreux syste`mes d’exploitation et exe´cutifs temps re´el (RTOS-Real-Time Operating System), base´s soit sur des normes (POSIX, OSEK, Ada, ITRON, ARINC 653, etc.), soit sur des spe´cifications proprie´taires (VxWorks de Wind River, RTEMS, etc.). Pour plus de de´tails concernant les RTOS, le lecteur peut se re´fe´rer a` l’article [S 8 052].

Par la suite, nous utiliserons toujours les taˆches pour de´finir le comportement des ordonnanceurs, mais les concepts sont aussi valides pour les processus. Notons aussi que les processus sont souvent hie´rarchise´s d’un point de vue ordonnancement. Par exemple, dans l’amendement 1003.1b de la norme POSIX (amendement concernant les aspects multiprocessus), chaque processus est muni d’un ordonnanceur interne servant a` ordonnancer les soustaˆches et sous-processus.

Tous les noyaux permettent le paralle´lisme par le biais de taˆches : une taˆche est une entite´ logicielle dont le code se´quentiel est exe´cute´ en paralle`le des autres taˆches. Une taˆche, appele´e thread en anglais, repre´sente un fil d’exe´cution.

Les e´tats possibles d’une taˆche (figure 3) varient en fonction du noyau, mais on trouve ge´ne´ralement au moins trois e´tats :  preˆte : la taˆche doit eˆtre exe´cute´e, de`s obtention d’un cœur de calcul ;  endormie ou bloque´e : la taˆche est en attente d’un e´ve´nement, par exemple l’arrive´e d’une date, ou bien l’arrive´e d’un message attendu, ou encore la libe´ration d’une ressource, avant d’eˆtre a` nouveau preˆte ;  exe´cute´e : la taˆche utilise un cœur de calcul unique (une taˆche ne peut pas eˆtre paralle´lise´e) pour exe´cuter se´quentiellement ses instructions.

En me´moire, une application multitaˆche est caracte´rise´e par son code, contenant l’ensemble des instructions et sous-programmes utilise´s, ses donne´es dans lequel on stocke les variables globales, ainsi que la me´moire alloue´e dynamiquement, et enfin une pile par taˆche. La pile permet de suivre l’exe´cution dynamique d’un programme se´quentiel pouvant appeler des sous-programmes : lorsqu’une taˆche appelle un sous-programme, l’adresse de retour du sous-programme, ainsi que les parame`tres d’appel, sont dispose´s en sommet de pile. Lors de l’exe´cution du sous-programme, ses

L’ordonnanceur du noyau connaıˆt et ge`re la liste des taˆches : a` chaque fois que cela est ne´cessaire, l’ordonnanceur choisit parmi les taˆches preˆtes une taˆche a` exe´cuter. La taˆche qui e´tait exe´cute´e et ne l’est plus est dite pre´empte´e : son contexte (e´tat des registres) est sauvegarde´ pour eˆtre restaure´ lorsqu’elle sera a` nouveau

Système d’exploitation (shell maintenance, déverminage, etc.)

Inexistante

Créati

on

tion Élec

Noyau (ordonnancement, gestion mémoire, interruptions)

tion

Exécutif (pilotes, protocoles)

Préem p

Ｒ

Un exe´cutif est constitue´ d’un noyau, et d’un ensemble de pilotes de pe´riphe´riques. Par exemple, un exe´cutif peut posse´der une pile IP (Internet Protocol) avec un certain nombre de protocoles d’acce`s au medium de communication, ou bien des pilotes permettant de ge´rer les communications via les ports se´rie du calculateur.

Suppression

Prête

Exécutée

Donne ou ressource disponible Suppression

Bloquée

Attente d’une donnée ou ressource Terminaison

´ tats d’une taˆche Figure 3 – E

Figure 2 – Noyau, exe´cutif, syste`me d’exploitation

S 8 055v2 – 6

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＳＶ

Terminée

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

Ordonnancement temps réel Ordonnancement réparti par

Francis COTTET Professeur d’université (ENSMA, Poitiers Futuroscope) Ingénieur de l’Institut national polytechnique de Grenoble Docteur ès sciences

Ｒ

Joëlle DELACROIX Maître de conférences (Conservatoire national des arts et métiers, Paris) Docteur en informatique de l’université Pierre-et-Marie-Curie

Claude KAISER Professeur (Conservatoire national des arts et métiers, Paris) Ingénieur de l’École polytechnique, ingénieur du génie maritime Docteur ès sciences et

Zoubir MAMMERI Professeur d’université (université Paul-Sabatier, Toulouse) Ingénieur, docteur en informatique Habilité à diriger des recherches

1.2 1.3

Introduction aux systèmes temps réel et répartis ......................... Systèmes répartis généraux : caractéristiques et problèmes de conception............................................................................................... Répartition matérielle et logique................................................................ Problèmes liés aux systèmes temps réel et répartis ................................

2. 2.1 2.2 2.3 2.4

1. 1.1

S 8 056 - 3 — — —

3 4 4

Placement et migration de tâches ...................................................... Ordonnancement local et ordonnancement global.................................. Placement de tâches.................................................................................... Placement dynamique de tâches ............................................................... Migration de tâches.....................................................................................

— — — — —

5 5 5 6 8

3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Ordonnancement de messages ............................................................ Introduction.................................................................................................. Communication et réseaux temps réel...................................................... Caractéristiques des messages et qualité de service ............................... Protocoles de niveau MAC (Medium Access Control).............................. Ordonnancement de messages : principes généraux et propriétés ....... Ordonnancement de messages périodiques ............................................ Ordonnancement de messages apériodiques .......................................... Tableau récapitulatif ....................................................................................

— — — — — — — — —

9 9 10 11 12 14 15 18 20

4. 4.1 4.2

Produits et exemples de réalisations ................................................. Exemples de systèmes d’exploitation temps réel et répartis .................. Méthodes et outils de validation d’applications temps réel ....................

— — —

20 20 23

5.

Conclusion .................................................................................................

—

24

Références bibliographiques .........................................................................

—

25

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｭ｡ｲｳ＠ＲＰＰＰ

L

a complexité des procédés à commander ou à superviser, le nombre élevé de données et d’événements à traiter, la répartition géographique des procédés, d’une part, et l’arrivée depuis plusieurs années, sur le marché, de réseaux locaux industriels, d’autre part, sont tous des facteurs qui ont conduit à repenser les applications temps réel centralisées. Aujourd’hui, la notion d’architectures

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＳＷ

S 8 056 − 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

ORDONNANCEMENT TEMPS RÉEL _________________________________________________________________________________________________________

Calculateur CFAO

Calculateur GPAO

Calculateur de gestion

Réseau d'usine

Contrôleur de qualité

Superviseur

Passerelle

Ｒ

temps réel et réparties est communément acceptée dans le milieu industriel. À titre indicatif, les domaines d’applications qui font couramment appel aux systèmes temps réel et répartis sont : — les télécommunications (systèmes de commutation…) ; — le domaine médical (assistance et contrôle de malades…) ; — le contrôle d’équipements (moteur, freins, suspension...) dans les véhicules ; — le contrôle et la régulation de trafic en milieu urbain ; — les industries (contrôle/commande de procédés…) ; — le domaine militaire (suivi de trajectoires de missiles…) ; — le domaine aérospatial (suivi de satellites, pilotage automatique…) ; — le multimedia (téléconférences, téléachat...) ; — la domotique (sécurité d’habitations…). Un système informatique destiné à commander ou à superviser des opérations est composé, le plus souvent, de plusieurs unités de traitement (des ordinateurs ou des automates programmables), des capteurs, des actionneurs, des périphériques de visualisation et de dialogue avec les opérateurs. L’ensemble de ces éléments est interconnecté par un réseau ou toute une pléiade de réseaux interconnectés entre eux (des réseaux industriels, des réseaux bureautiques, des bus de terrain, etc.), comme le montre la figure A. Ce type de système est qualifié de système temps réel et réparti (ou distribué ou encore décentralisé). Dans ce type de système, l’ordonnancement de tâches et de messages joue un rôle fondamental. L’ordonnancement centralisé de tâches est traité dans l’article « Ordonnancement temps réel. Ordonnancement centralisé » de ce traité. C’est l’ordonnancement de messages qui fait l’objet de cet article.

Gestion de maintenance

Réseau de cellule

Automate programmable

C

C

Commande numérique

Capteurs Bus de terrain

A

A

Commande de robot

C

C

Bus de terrain A

Actionneurs

A

A

Figure A – Exemple de système temps réel et réparti

S 8 056 − 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＳＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS RÉEL

1. Introduction aux systèmes temps réel et répartis

Le développement des systèmes répartis est motivé par plusieurs raisons, notamment : — la demande d’interconnecter le plus possible les applications existantes, en particulier pour les services multimédias (téléconférence, télé-enseignement, télémédecine, ingénierie coopérative...) ;

On appelle système temps réel et réparti tout système composé de plusieurs entités interconnectées par un sous-système de communication et qui coopèrent à la réalisation d’un ensemble de fonctions sujettes à des contraintes de temps (ces contraintes pouvant être strictes ou non selon la nature de l’application à laquelle est associé le système) [9] [28] [56]. Les systèmes temps réel et répartis sont des cas particuliers des systèmes répartis. C’est la raison pour laquelle nous commençons par nous intéresser aux systèmes répartis qui ne prennent pas en compte explicitement des contraintes temporelles, pour voir les principaux problèmes posés par ces systèmes et nous verrons ensuite les difficultés à considérer pour tenir compte des contraintes de temps.

— la volonté d’augmenter la disponibilité d’un système informatique pour permettre le remplacement d’un composant du système par un autre sans dégradation significative (voire sans aucune dégradation) du service rendu. Cet aspect est primordial dans les applications temps réel et réparties pour lesquelles les situations d’arrêt doivent être les plus rares possibles. Dans les systèmes automatisés de production, l’arrêt du système temps réel est synonyme d’un arrêt de production ; — le souci de faciliter l’évolution matérielle ou fonctionnelle d’un système en remplaçant ou en ajoutant certains éléments sans avoir à arrêter les autres éléments du système ; — le partage de ressources matérielles (des imprimantes, des unités de sauvegarde massive...) ou logicielles (des bases de données, des logiciels...) ;

1.1 Systèmes répartis généraux : caractéristiques et problèmes de conception

— la demande de plus de puissance de calcul au moindre coût (par exemple, plusieurs PC en réseau coûtent moins cher qu’un gros ordinateur) ; — enfin, les besoins d’adaptation du système informatique à son environnement : aujourd’hui, que ce soit dans les applications bureautiques ou dans les applications industrielles, les ordinateurs participant à une application se répartissent sur des étendues géographiques plus ou moins importantes − sur plusieurs étages d’un immeuble, ou sur des dizaines de kilomètres carrés dans le cas de raffineries de pétrole, par exemple. Il est donc important, pour le système informatique, de tenir compte de cette répartition géographique.

Un système réparti est constitué d’un ensemble de processeurs reliés entre eux par un sous-système de communication qui leur permet d’échanger des informations. Selon la nature du sous-système de communication, on distingue les multiprocesseurs où la communication peut se passer avec ou sans mémoire commune et les réseaux d’ordinateurs où la communication se passe obligatoirement sans mémoire commune (c’est-à-dire, avec échange de messages). Les machines parallèles sont constituées de plusieurs processeurs, en général identiques, fortement couplés. Les réseaux d’ordinateurs sont formés de machines autonomes, généralement hétérogènes, faiblement couplées. Les distances entre les processeurs d’un réseau d’ordinateurs peuvent être courtes (quelques dizaines de mètres, voire moins) ou très importantes (des milliers de kilomètres, voire plus, pour les réseaux de satellites). Les distances entre les processeurs d’une machine multiprocesseur sont infiniment plus petites (quelques centimètres, voire moins).

Les systèmes répartis ont des caractéristiques qui les distinguent des systèmes centralisés : — les délais de communication entre sites varient d’un message à l’autre et aussi selon les protocoles du réseau de communication utilisés ; — ils n’ont pas d’horloge commune. Chaque site a sa propre perception du temps et, comme les horloges physiques dérivent par rapport au temps de référence, les différents temps lus sur les sites peuvent être différents à une même heure universelle ;

On dit qu’un système réparti est constitué d’un ensemble de processeurs, de sites ou de nœuds interconnectés entre eux (figure 1). Par la suite, nous utiliserons indifféremment, lorsqu’il n’y a pas d’ambiguïté, les termes nœud, site et processeur et nous ne ferons pas de distinction entre les systèmes répartis construits autour d’architectures multiprocesseurs et ceux construits autour de réseaux d’ordinateurs.

— l’absence d’une mémoire commune a pour conséquence l’impossibilité de définir un état global à l’aide de variables communes. Encore plus important, l’existence de délais de communication variables et l’absence d’un référentiel temporel commun ont pour conséquence que chaque site a sa propre vue qui peut être différente de celles des autres sites à un même instant du temps universel ; — comme le nombre d’équipements d’un système réparti est plus élevé que celui d’un système centralisé, les risques de défaillances y sont plus importants. Des mécanismes de tolérance aux fautes doivent être intégrés pour répondre à l’exigence de ne pas dégrader la sûreté de fonctionnement et, en particulier, la disponibilité de ces systèmes [27] ;

Site

Site

Réseau

Site

— l’existence d’interfaces de communication avec l’extérieur rend les systèmes répartis plus vulnérables aux intrusions ;

de

Site

communication

— les applications réparties sont plus complexes à spécifier, à concevoir, à implanter, à tester et à valider.

Site

L’impossibilité de disposer instantanément d’un état global identique sur tous les sites pose beaucoup de problèmes pour la prise de décisions relatives à la gestion et au partage de ressources, à la validation d’actions atomiques faisant intervenir plusieurs sites, à l’établissement d’une vue d’un groupe participant à une application

Site

Figure 1 – Architecture générale d’un système réparti

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＳＹ

S 8 056 − 3

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

ORDONNANCEMENT TEMPS RÉEL _________________________________________________________________________________________________________

coopérative, etc. C’est aussi l’une des principales sources de complexité des algorithmes de placement de tâches (cf. § 2).

Il est important de signaler que la répartition (ou décentralisation) doit être considérée séparément pour chaque fonction du système. Selon les spécificités d’un système, on peut avoir des fonctions centralisées, d’autres partiellement réparties et d’autres complètement réparties. Par exemple, on peut avoir dans un même système : une fonction complètement répartie pour la synchronisation d’horloges, une base de données éclatées sur plusieurs sites, mais toutes les transactions sur la base sont contrôlées par un seul site et une gestion centralisée des fichiers. Tout n’est pas réparti dans un système réparti ! Il est clair qu’il ne peut y avoir de répartition logicielle sans répartition matérielle, mais la réciproque n’est pas vraie. La décentralisation matérielle peut aider ou inciter à la répartition logicielle.

Exemple : un site i diffuse, à l’instant t, un message pour informer les autres sites qu’il a une charge faible et qu’il est prêt à accueillir des tâches en provenance des autres sites. Juste après l’instant t, une avalanche d’événements locaux se produit et le site i est obligé d’exécuter un nombre important d’actions pour répondre aux événements survenus, ce qui conduit à une saturation momentanée de ce site. Les autres sites recevant le message du site i décident de lui envoyer des tâches à exécuter. À la réception des tâches, le site i les rejette, car il est en situation de surcharge.

Ｒ

On remarque, à travers cet exemple, que les délais de communication donnent une image qui peut être dépassée et qui conduit à entreprendre des opérations (de transfert de tâches, par exemple) qui seront annulées.

1.3 Problèmes liés aux systèmes temps réel et répartis

Beaucoup de travaux ont été développés depuis plus d’une quinzaine d’années sur les différents problèmes posés par les systèmes répartis. Nous conseillons au lecteur désireux d’approfondir ses connaissances sur les systèmes répartis de consulter des ouvrages tels que [4] [14] [25] [39] [45] [60].

Dans le cas des systèmes temps réel, la répartition est parfois indispensable : le procédé physique est fortement réparti, les traitements, les contraintes temporelles dépassent les capacités d’un seul processeur, l’arrêt du système est inacceptable… La répartition des systèmes temps réel introduit de nouveaux problèmes, notamment : — les calculs fondés sur les contraintes temporelles qui font référence au temps chronométrique ou à une date absolue risquent de comporter des erreurs de calcul trop importantes et, partant, de ne pas être crédibles, à cause de dérives trop grandes entre les horloges des différents sites ; — l’observation de l’évolution des différents constituants du procédé est retardée et différente d’un site à un autre à cause des délais de communication variables ; — les tests d’ordonnançabilité et les calculs de garantie des contraintes de temps de tâches communicantes, donc l’ordonnancement temps réel réparti, sont tributaires de ces dérives d’horloges et de ces délais de communication ; — la tolérance aux fautes est beaucoup plus complexe, ce qui rend encore plus difficile de tolérer des fautes tout en respectant les contraintes de temps.

1.2 Répartition matérielle et logique Les termes décentralisé, réparti et distribué sont souvent utilisés de manière ambiguë. Pour les préciser, il faut tout d’abord distinguer la répartition matérielle et la répartition logique. ■ La répartition matérielle (ou encore décentralisation physique) est obtenue en utilisant plusieurs unités de traitement qui sont interconnectées par un sous-système de communication. Par exemple, un système de contrôle/commande constitué de capteurs et d’actionneurs en contact direct avec le procédé physique, d’automates programmables dans les salles de commande et de stations de travail dans les salles de CAO, est un système avec une architecture matérielle répartie (ou décentralisée). ■ La taxinomie est plus complexe lorsqu’il s’agit du logiciel. En effet, il faut distinguer : — la répartition des données (ou répartition de l’information) ; — la répartition des traitements ; — la répartition du contrôle. ● L’ensemble des informations (variables simples, fichiers...) qui sont partagées entre des tâches distantes peut être stocké sur un seul site (on parle, dans ce cas, de stockage centralisé de l’information) ou éclaté sur plusieurs sites (on parle, dans ce cas, de stockage décentralisé de l’information). Cette répartition ne préjuge en rien sur la façon dont le contrôle de l’accès aux informations partagées sera géré. ● La répartition des traitements conduit à affecter les programmes (ou tâches) à des sites pour y être exécutés. Cette répartition ne préjuge en rien de la façon dont l’exécution des programmes sera gérée, c’est-à-dire, de la façon dont sera effectué le contrôle de l’exécution des tâches. ● Le contrôle concerne le déclenchement et l’arrêt des tâches, le transfert des tâches d’un site vers un autre, l’accès aux ressources partagées, la validation d’opérations faisant intervenir plusieurs sites, etc. Il peut être à la charge d’un seul site (il s’agit d’un contrôle complètement centralisé), d’une partie des sites (il s’agit d’un contrôle partiellement réparti) ou de tous les sites (il s’agit d’un contrôle complètement réparti). Lorsque le contrôle est distribué, la prise de décision (par exemple, pour valider une opération sur une base de données, pour lancer la production d’un ensemble de pièces ou, encore, pour sortir le train d’atterrissage d’un avion) peut être prise par chaque site séparément, par tous les sites (dans ce cas, si un seul site manque, la décision ne peut être prise) ou à la majorité des sites (on parle, dans ce cas, de décision par consensus).

S 8 056 − 4

Dans le cas de l’ordonnancement temps réel qui nous intéresse ici, la répartition implique l’ordonnancement conjoint de tâches et de messages. Le respect ou non des contraintes temporelles des messages se répercute de manière directe sur celui des tâches, car l’attente de réception d’un message par une tâche est équivalente à l’attente d’acquisition d’une ressource ; si le message n’arrive pas à temps, les contraintes temporelles de la tâche ne peuvent être garanties. L’ordonnancement de tâches dans un système réparti se règle à deux niveaux : au niveau de chaque processeur (ordonnancement local) et au niveau du placement de tâches sur les processeurs. Le problème d’ordonnancement local a été présenté dans l’article [S 8 055] de ce traité ; le problème de placement sera étudié dans le paragraphe suivant. La conception et l’implantation des systèmes temps réel et répartis nécessitent des protocoles de communication qui garantissent aux tâches communicantes de recevoir, dans les délais, les messages qui leur sont destinés. Pour les messages avec des échéances strictes de délivrance, il faut que les protocoles donnent des garanties et, pour les messages non critiques du point de vue temporel, la stratégie du protocole est le meilleur effort (c’est-à-dire, minimiser le retard des messages et le nombre des messages tardifs). Toutefois, la notion de « meilleur effort » doit être utilisée avec certaines précautions dans le cas de systèmes temps réel. Par exemple, perdre une image sur dix dans le cas d’une animation vidéo dans une salle de commande est souvent sans conséquence, par contre perdre neuf images sur dix rend le système de supervision inutile aux yeux des opérateurs. La garantie des contraintes temporelles de messages passe par un ordonnancement adéquat des messages.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＴＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

________________________________________________________________________________________________________ ORDONNANCEMENT TEMPS RÉEL

Le paragraphe 3 est réservé à l’étude du problème de l’ordonnancement de messages et de ses solutions.

qu’une tâche ne requiert qu’un seul processeur à la fois pour son exécution). On remarque aisément que si les paramètres n et p ont des valeurs élevées, l’obtention d’une solution au bout d’un temps raisonnable devient vite impossible. Sauf pour des cas très simples, le problème de placement de tâches est un problème NP-complet [20] (c’est-à-dire, un problème qui ne se résout pas avec un algorithme qui donne un résultat au bout d’un temps polynomial). C’est la raison pour laquelle la quasi-totalité des travaux qui ont traité le problème de placement de tâches utilisent des techniques approximatives et des heuristiques.

Dans un système temps réel et réparti, les tâches sont synchronisées en utilisant le temps chronométrique (par exemple, activation de tâches à des instants précis ou de manière périodique). Il en est de même pour la datation de données et d’événements apparaissant sur les différents sites. Le bon fonctionnement d’un système réparti nécessite le plus souvent l’existence d’un temps global accessible à tous les sites. La solution la plus couramment utilisée pour établir un temps global est la synchronisation d’horloges physiques. D’autres solutions fondées sur l’utilisation de récepteur d’un temps diffusé par une station de radio ou un satellite commencent à être envisagées. Beaucoup d’algorithmes ont été proposés pour régler le problème de synchronisation d’horloges. Le lecteur désireux d’approfondir ses connaissances sur ce sujet peut consulter les références [19] [21].

Le problème de placement consiste souvent à rechercher d’abord une solution qui respecte le plus possible les contraintes initiales puis à choisir le meilleur placement, si plusieurs placements ont été trouvés. La recherche d’un placement doit tenir compte des contraintes initiales des tâches, de l’environnement support ainsi que des critères à optimiser. Les contraintes initiales peuvent être diverses : — existence ou non de tâches à contraintes strictes pour lesquelles la garantie des échéances est une nécessité quelle que soit la charge du système ; — obligation pour certaines tâches de résider sur un processeur précis disposant de ressources matérielles ou logicielles spécifiques (par exemple, une tâche d’acquisition de mesures doit se trouver sur la machine en contact direct avec le procédé physique) ; — limitation du nombre de tâches s’exécutant sur chaque processeur ; — interdiction à deux tâches données de s’exécuter sur un même site (par exemple, pour des raisons de tolérance aux fautes, on exige qu’une tâche et sa copie ne s’exécutent pas sur un même site) ; — regroupement de tâches utilisant certaines ressources ; — etc.

2. Placement et migration de tâches 2.1 Ordonnancement local et ordonnancement global Dans les systèmes répartis, on distingue deux types d’ordonnancement : l’ordonnancement local et l’ordonnancement global. L’ordonnancement local consiste à allouer un processeur aux tâches affectées à ce processeur, en tenant compte de leur urgence et de leur importance.

Afin de chercher un bon placement, il est important de préciser les critères (ou fonctions de coûts) à optimiser. Dans les systèmes temps réel, le critère le plus important est évidemment le respect des contraintes temporelles : (1) garantir le respect des contraintes temporelles des tâches à contraintes strictes et (2) minimiser le nombre de tâches à contraintes relatives qui dépassent leurs échéances. D’autres critères peuvent être envisagés ensuite. Beaucoup de travaux ont été développés dans le contexte de l’ordonnancement non temps réel (c’est-à-dire, dans des problèmes d’optimisation concernant, par exemple, la gestion de production ou des emplois du temps, le transport, l’intelligence artificielle, etc.) montrant comment on peut optimiser un ou plusieurs critères. Dans le cas de l’ordonnancement dans des systèmes répartis, on peut avoir comme critère d’optimisation :

L’ordonnancement global a, quant à lui, pour mission d’essayer de garantir les contraintes de tâches en exploitant les capacités de traitement des différents processeurs composant le système réparti considéré (en procédant, éventuellement, à des migrations de tâches). Ainsi, un ordonnanceur local a pour objectif de répondre à la question « quand exécuter une tâche sur le processeur local, de manière à respecter les contraintes imposées à cette tâche ? ». Un ordonnanceur global, quant à lui, cherche à répondre à la question « quel est le site le mieux adapté pour exécuter une tâche donnée, de manière à respecter ses contraintes ? ». Le placement et l’ordonnancement sont indissociables dans le cas des applications temps réel : il faut placer les tâches sur l’ensemble des processeurs de telle sorte que l’ordonnancement local conduise impérativement au respect des contraintes de temps des tâches critiques du point de vue temporel. L’ordonnancement local utilise des algorithmes comme ceux présentés dans l’article [S 8 055]. Nous nous intéressons ici aux différents aspects de l’ordonnancement global, c’est-à-dire, les aspects liés au placement et à la migration des tâches.

— la minimisation de la durée totale d’exécution de l’ensemble des tâches ; — la minimisation du nombre de processeurs utilisés ; — la minimisation de la charge de communication ; — l’équilibrage de charge des processeurs. Selon la nature de l’application et le système support de l’application, on est amené à privilégier certains critères. Par exemple, si le réseau de communication utilisé est un réseau Ethernet − un réseau qui ne garantit pas de temps de réponse borné et dont le rendement s’écroule si les demandes de transmission dépassent un certain seuil − il est souvent conseillé de chercher particulièrement à minimiser les communications pour permettre aux tâches placées sur des machines distantes de recevoir leurs messages à temps et donc de se terminer à temps.

2.2 Placement de tâches 2.2.1 Problème de placement de tâches À première vue et de manière simplifiée, on peut considérer que le problème de placement (ou allocation, en anglais − à noter aussi que certains utilisent le terme « allocation de tâches » au lieu de « placement de tâches ») de n tâches sur p processeurs conduit à étudier pn cas de placements possibles (en supposant évidemment

Les critères à optimiser sont parfois en contradiction les uns avec les autres. Par exemple, réduire la charge de communication conduit à regrouper les tâches sur un nombre réduit de processeurs, ce qui aboutit donc à des processeurs plus chargés que d’autres.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＴＱ

S 8 056 − 5

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＶ

ORDONNANCEMENT TEMPS RÉEL _________________________________________________________________________________________________________

2.2.2 Classes d’algorithmes et techniques de résolution du problème de placement

Ｒ

placement statique est la solution utilisée aujourd’hui dans les applications temps réel réparties industrielles. Il y a deux principales raisons à cela : — le placement dynamique est complexe, encore peu étudié, et donne rarement une garantie absolue quant au respect des contraintes temporelles ; — le choix d’une architecture matérielle et logicielle (nombre et types de processeurs, type de réseau, types de systèmes d’exploitation...) est souvent dicté par les spécificités de l’application et on construit, par conséquent, une architecture « sur mesure » pour permettre aux tâches de respecter leurs échéances tout en étant placées de manière statique.

Selon le nombre de processeurs, le nombre de tâches à placer et les contraintes temporelles, les contraintes de précédence et les contraintes de ressources, deux familles d’algorithmes peuvent être utilisées : — les algorithmes exacts (ou optimaux) qui procèdent par énumération pour trouver la solution optimale. De tels algorithmes deviennent très vite irréalistes lorsque la taille du problème est importante, à cause de l’explosion combinatoire de cette énumération ; — les algorithmes approchés (ou non optimaux) qui permettent de trouver une solution qui ne respecte pas nécessairement toutes les contraintes. Parfois, la solution obtenue peut être la solution optimale.

On a dépassé aujourd’hui le stade des applications temps réel et réparties composées uniquement de tâches cycliques de régulation avec un nombre d’entrées et de sorties parfaitement connu et où l’on prévoit un arrêt d’urgence dès qu’un événement survient. Imposer une connaissance figée sur une application temps réel et répartie complexe est synonyme d’un surdimensionnement parfois excessif de l’architecture. C’est ainsi que des travaux sont effectués pour éviter ce surdimensionnement et proposer des mécanismes plus dynamiques [13] [52] [54] [56] [57] [74]. On s’oriente à la fois vers un ordonnancement local dynamique et un placement dynamique.

Les méthodes utilisées par les algorithmes de placement de tâches sont notamment : — la technique du branch-and-bound, la programmation dynamique et la théorie des graphes, pour les algorithmes optimaux (la théorie des graphes étant la technique la plus utilisée). Une des méthodes utilisées dans les algorithmes de placement fondés sur la théorie des graphes consiste à déterminer des coupes minimales d’un graphe contenant les tâches, les processeurs et les liens de communication, pour déterminer des solutions de placement. Les algorithmes fondés sur la programmation dynamique représentent le problème de placement sous forme d’un problème d’optimisation avec minimisation d’une fonction de coût sous contraintes ; — les méthodes approximatives et heuristiques (telles que le recuit simulé, le tabou, les algorithmes génétiques, les réseaux de neurones et les algorithmes gloutons) pour les algorithmes non optimaux. Les méthodes itératives (algorithmes génétiques, réseaux de neurones, recuit simulé et tabou) partent d’une solution et tentent de l’améliorer par des itérations successives. Les algorithmes gloutons tentent d’atteindre la solution sans remettre en question les choix déjà effectués. Ils fournissent en général des solutions moins bonnes que les autres méthodes.

La technique idéale du placement serait celle qui permettrait de trouver instantanément le meilleur site pour accueillir une tâche qui est déclenchée ou qui doit reprendre son exécution après une interruption. Le transfert d’une tâche d’un site vers un autre ne doit remettre en cause aucune des tâches plus prioritaires en cours d’exécution sur le système réparti et ne doit pas affecter les performances globales du système. Ce résultat est impossible à atteindre dans la pratique à cause du délai nécessaire pour obtenir un état exact et valide de l’ensemble des sites d’un système réparti (parce que l’obtention de cet état demande de nombreux messages avec des délais de transfert variables). Par ailleurs, les transferts nécessaires pour la migration de tâches peuvent compromettre le respect des contraintes temporelles de tâches et les performances globales du système.

Dans les applications non temps réel, à l’exception des applications de petites tailles, les algorithmes non optimaux sont quasiment les seuls à être utilisés dans la pratique. Pour des applications temps réel à contraintes temporelles strictes, les algorithmes non optimaux sont inadéquats, car ils ne donnent aucune garantie quant au respect des contraintes temporelles des tâches. Par conséquent, des algorithmes optimaux doivent être utilisés. Pour éviter les problèmes d’explosion combinatoire, on impose souvent des contraintes initiales restrictives permettant de trouver, au bout d’un temps raisonnable, une solution garantissant le respect des contraintes temporelles strictes des tâches. Par exemple, on impose que toute tâche critique du point de vue temporel doit être périodique, ou encore que toutes les ressources doivent être affectées à une tâche avant de démarrer son exécution.

2.3 Placement dynamique de tâches On distingue deux grandes classes d’algorithmes de placement dynamique : — le placement sans coopération (ou placement aveugle) : au moment où une requête d’exécution de tâche est créée, un site est choisi de manière aléatoire pour exécuter la tâche considérée ; — le placement avec coopération : les sites s’échangent des informations pour déterminer le site sur lequel sera placée la tâche dont la requête d’exécution vient d’être créée. Les techniques de placement sans coopération sont simples à mettre en œuvre. Comme elles ne tiennent pas compte des charges des sites, elles peuvent conduire à des surcharges de certains sites, donc à des échéances de tâches qui ne seront pas respectées.

2.2.3 Placement statique et placement dynamique

Les techniques de placement avec coopération tiennent compte de la charge d’exécution de chaque site avant de lui affecter de nouvelles tâches. Quand le surcoût en temps qu’elles introduisent est acceptable, elles sont alors plus efficaces pour l’équilibrage de charge et le respect des échéances de tâches, mais elles sont plus complexes à mettre en œuvre.

Les tâches constituant une application répartie peuvent être affectées de manière statique ou dynamique aux sites. Dans le premier cas, on parle de placement statique, dans le deuxième, de placement dynamique. Dans le premier cas, il ne peut plus y avoir de placement des tâches pendant l’exécution de l’application, le placement des tâches est donc figé à la configuration du système. Dans le deuxième cas, l’algorithme d’ordonnancement choisit de placer chaque tâche sur le site le plus apte à respecter ses contraintes temporelles, au moment où elle est déclenchée.

Un algorithme de placement avec coopération est composé d’une fonction de contrôle et, éventuellement, d’une fonction de collecte d’informations [17], [59]. Cette dernière fonction, quand elle est présente, a pour objectif de recueillir et de maintenir des informations concernant l’état et la charge des sites du système réparti. La fonction de contrôle permet de déterminer les sites de placement des tâches.

Le placement statique utilise une connaissance statique : le nombre de tâches, les coûts de communication, la charge du réseau, les bornes des temps de transfert de messages, les temps d’exécution sur les processeurs, etc. sont déterminés une fois pour toutes. Le

S 8 056 − 6

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＴＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＷ

Ordonnancement temps re´el Ordonnancement multiprocesseur par

Pascal RICHARD Professeur des universite´s en Informatique a` l’universite´ de Poitiers

Emmanuel GROLLEAU

Ｒ

Professeur des universite´s en Informatique a` l’ISAE-ENSMA (Chasseneuil-du-Poitou)

Michae¨l RICHARD Maıˆtre de confe´rences en Informatique a` l’ISAE-ENSMA (Chasseneuil-du-Poitou) et

Fre´de´ric RIDOUARD Maıˆtre de confe´rences en Informatique a` l’universite´ de Poitiers

1. 1.1

1.2 1.3

1.4

2. 2.1

2.2

2.3

Architectures des applications temps re´el ................................ Architecture mate´rielle multiprocesseur ........................................... 1.1.1 Syste`mes centralise´s ............................................................... 1.1.2 Syste`mes re´partis .................................................................... Architecture logicielle ........................................................................ 1.2.1 Types de taˆches ....................................................................... Classification des ordonnanceurs multiprocesseurs ........................ 1.3.1 Ordonnanceurs en-ligne et hors-ligne .................................... 1.3.2 Pre´emptions et migrations des taˆches ................................... 1.3.3 Priorite´s des taˆches ................................................................. 1.3.4 Classification ............................................................................ Proprie´te´s des ordonnanceurs ........................................................... 1.4.1 Comparabilite´ des algorithmes ............................................... 1.4.2 Optimalite´ et existence d’algorithme en-ligne ....................... 1.4.3 Pre´dictibilite´, viabilite´ et anomalies d’ordonnancement ........ 1.4.4 Mesures de performance ........................................................ Principaux algorithmes d’ordonnancement .............................. Ordonnancement partitionne´ ............................................................. 2.1.1 Algorithmes de partitionnement ............................................. 2.1.2 E´valuation des algorithmes de partitionnement .................... Ordonnancement global .................................................................... 2.2.1 Algorithmes e´quitables ........................................................... 2.2.2 Ge´ne´ralisation des algorithmes d’ordonnancement monoprocesseur ...................................................................... Approches hybrides entre ordonnancements global et partitionne´ .

Pour en savoir plus..................................................................................

S 8 057 – 3 — 3 — 3 — 4 — 4 — 4 — 5 — 5 — 6 — 6 — 6 — 6 — 6 — 7 — 8 — 9 — — — — — —

10 10 10 12 13 14

— —

17 17

Doc. S 8 057

epuis le de´but des anne´es 2000, on perc¸oit un ralentissement de l’accroissement exponentiel (loi de Moore) des vitesses de calcul d’une ge´ne´ration de processeur a` la suivante. Sur les ordinateurs personnels, l’accroissement en puissance de calcul est maintenu par un accroissement du nombre de cœurs de calcul sur une meˆme puce. Ce phe´nome`ne peut eˆtre explique´ par la miniaturisation atteinte par les fondeurs de processeurs sur une technologie base´e sur des transistors en silicium : pour une taille de transistors donne´e, acce´le´rer la vitesse de calcul a un couˆt quadratique en e´nergie. Or, la taille d’un transistor n’est aujourd’hui que de quelques atomes ; elle est donc de plus en plus difficile a` diminuer, et les gains en fre´quence des calculateurs se font alors de moins en moins sentir.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｳ･ｰｴ･ｭ｢ｲ･＠ＲＰＱＳ

D

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＴＳ

S 8 057 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＷ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Ｒ

Lorsque les calculateurs sont embarque´s sur un proce´de´ (avion, automobile, train, satellite artificiel, etc.) controˆle´ par un syste`me, le compromis entre puissance de traitement et e´nergie consomme´e penche souvent en faveur de la limitation des fre´quences de calcul des processeurs embarque´s lorsque ceux-ci sont alimente´s sur batterie, e´nergie ambiante ou en consommant du carburant. La diminution de la puissance des calculateurs est alors compense´e par la multiplication de leur nombre pour une meˆme puissance globale de calcul. On peut naturellement envisager deux fac¸ons de multiplier les calculateurs : connecter plusieurs calculateurs par des re´seaux de communication (on parle alors de syste`mes re´partis) ou bien mettre sur une meˆme puce plusieurs cœurs de calculs (on parle alors de syste`mes multiprocesseurs ou multicœurs lorsque les cœurs de calcul sont sur une meˆme puce). Bien entendu, on peut associer les deux et avoir des re´seaux de communication reliant des syste`mes multicœurs. Sur un syste`me critique complexe, tel qu’un avion civil, le syste`me de controˆle est constitue´ d’un syste`me re´parti de syste`mes monoprocesseurs. L’architecture avionique de demain, et vraisemblablement celle des autres types syste`mes embarque´s complexes doit augmenter les ressources de calcul sans augmenter la complexite´ du re´seau de communication de´ja` tre`s complexe dans ces syste`mes. Ainsi, l’architecture des syste`mes critiques de demain sera constitue´e de syste`mes re´partis multicœurs. Les syste`mes embarque´s critiques sont ge´ne´ralement soumis a` des contraintes de temps : chaque fonctionnalite´ doit s’exe´cuter dans un intervalle de temps donne´, malgre´ le fait que les ressources de calcul sont partage´es entre plusieurs fonctionnalite´s. On parle alors de syste`mes embarque´s temps re´el, qui doivent eˆtre non seulement valides fonctionnellement mais aussi temporellement. L’objet de cet article est de pre´senter la proble´matique de la validation temporelle d’applications temps re´el sur processeurs multicœurs. Il peut eˆtre conside´re´ comme la suite de l’article [S 8 055v2] et de l’article [S 8 056]. L’ave`nement des syste`mes multiprocesseurs dans les domaines des syste`mes critiques pose de nombreux de´fis scientifiques et entre autres :

" la validation temporelle, a` travers l’e´tude de l’ordonnancement des traitements sur les cœurs de calcul, leurs migrations e´ventuelles, leurs placements, etc. ; " le calcul de pire dure´e d’exe´cution d’un traitement, en fonction des migrations e´ventuelles. Dans certains cas, de nombreuses migrations simultane´es peuvent utiliser intensivement le re´seau pour passer les donne´es d’un cœur a` un autre, et ainsi une migration peut au pire subir un de´lai tre`s important. De meˆme, sur certaines architectures avec caches hie´rarchise´s, la dure´e de de´placement des donne´es en cache d’un cœur vers un autre de´pend du placement des cœurs source et de la destination dans la hie´rarchie de caches ; " le routage et l’optimisation de l’utilisation du re´seau reliant les cœurs de calcul : on parle de NOC (Network On Chip). Cet article se focalise sur l’ordonnancement et la validation temporelle sur syste`mes multicœurs. La proble´matique e´tant en elle-meˆme complexe, l’aspect surcouˆt e´ventuel lie´ aux migrations est le plus souvent ne´glige´ dans les mode`les utilise´s. Cependant, il faut avoir conscience du fait que les migrations, surtout lorsqu’elles sont nombreuses et simultane´es, n’ont dans la re´alite´ pas un couˆt ne´gligeable.

S 8 057 – 2

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＴＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＷ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– ORDONNANCEMENT TEMPS RE´EL

1. Architectures des applications temps re´el

une me´moire distribue´e (chaque processeur posse`de sa propre me´moire). Dans le cas d’une me´moire distribue´e, les donne´es sont e´change´es par le biais de messages passe´s entre les processeurs, sur des re´seaux de communication qui peuvent eˆtre synchrones ou asynchrones. Le proble`me de la validation temporelle e´tant tre`s complexe, l’architecture conside´re´e consiste en une me´moire partage´e acce´de´e par un bus. Dans le cas d’architectures multiprocesseur distribue´es ou hie´rarchise´es, si les transferts de donne´es, ou bien de code lors d’une migration d’un traitement d’un processeur a` un autre sont minimes, alors les re´sultats sur me´moire partage´e acce´de´e par un bus doivent pouvoir eˆtre ge´ne´ralise´s aux architectures plus complexes. Les mode`les conside´re´s actuellement sont tre`s simplistes, comme l’illustrent les figures 1 a` 3 : dans la the´orie actuelle de l’ordonnancement, les aspects communication et cohe´rence de caches sont ne´glige´s. Bien entendu, il est clair que cette

1.1 Architecture mate´rielle multiprocesseur Les architectures mate´rielles sont ge´ne´ralement classe´es en deux cate´gories : les syste`mes centralise´s, qui s’exe´cutent sur une seule puce et les syste`mes re´partis ou distribue´s qui s’exe´cutent sur diffe´rentes puces distantes les unes des autres.

1.1.1 Syste`mes centralise´s 1.1.1.1

Calculateurs

Meˆme si cette puce peut avoir plusieurs cœurs de calcul, on qualifie de centralise´ un processeur contenu dans une seule puce, ou dans plusieurs puces « proches » se trouvant sur un meˆme support physique.

Cœur 1 + Mém 1

La taxinomie de Flynn peut eˆtre employe´e pour de´signer les familles de calculateurs : " SISD (Single Instruction Multiple Data) de´signe les architectures de processeurs simples capables de traiter une instruction a` la fois ; " SIMD (Single Instruction Multiple Data) met en œuvre des architectures vectorielles ou matricielles, comme sur les processeurs graphiques (GPU) ou bien sur des jeux d’instructions particulie`res permettant d’effectuer des calculs identiques sur plusieurs donne´es a` la fois ; " MISD (Multiple Instruction Single Data) traite paralle`lement la meˆme donne´e et le meˆme calcul, mais n’a pas ou a peu de mise en œuvre ; " MIMD (Multiple Instruction Multiple Data) est la cate´gorie d’architecture qui contient les syste`mes multiprocesseurs ou multicœurs. Cette architecture permet d’exe´cuter simultane´ment plusieurs instructions sur des donne´es diffe´rentes. C’est ce type d’architecture sous-jacente que nous conside´rons dans cet article.

Cœur 4 + Mém 4

Cœur 2 + Mém 2

Cœur 3 + Mém 3

Figure 2 – Architecture a` me´moire distribue´e avec un re´seau de type mesh ou hypercube

Les architectures MIMD peuvent avoir une me´moire partage´e (acce´de´e par un bus, ou bien de fac¸on hie´rarchique), ou bien avoir

Cœur 1

Cœur 1

Cœur 2

Cache L1

Cache L1

Cache L2 Mémoire Cœur 4

Mémoire

Cache L2

Cœur 2

Cœur 3

Figure 1 – Architecture simplifie´e ge´ne´ralement conside´re´e lors de l’e´tude d’ordonnanc¸abilite´

Cache L1

Cache L1

Cœur 3

Cœur 4

Figure 3 – Architecture avec me´moire centralise´e, utilisant une hie´rarchie de caches

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＴＵ

S 8 057 – 3

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＷ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Ｒ

approximation est loin d’eˆtre re´aliste. Par conse´quent, on caracte´rise de nombreux algorithmes d’ordonnancement par le nombre de migrations qui peuvent avoir lieu, et de nombreux travaux s’inte´ressent a` les limiter. En effet, lors d’une migration, par exemple en me´moire distribue´e, le code et les donne´es d’une taˆche doivent eˆtre transfe´re´es ; dans le cas d’une me´moire a` caches hie´rarchiques, les caches de donne´es doivent eˆtre synchronise´s, et par exemple une migration du cœur 1 vers le cœur 2 devrait prendre moins de temps qu’une migration du cœur 1 au cœur 3.

La validation de syste`mes re´partis a lieu en deux phases interde´pendantes : validation au niveau temps de transmission pire cas des messages, et impact sur l’ordonnancement des calculateurs. Les techniques utilise´es pour mesurer l’impact sur l’ordonnancement des calculateurs sont similaires a` celles que nous verrons dans cet article. La validation des syste`mes re´partis est aborde´e dans l’article [S 8 056].

Chaque cœur du syste`me contient au moins une unite´ de controˆle permettant de de´coder et lancer l’exe´cution des instructions, et une unite´ arithme´tique et logique. Il peut eˆtre muni d’une me´moire cache de niveau 1 (L1) de fac¸on a` utiliser le principe de localite´ pour optimiser les acce`s a` la me´moire lorsque le cœur est plus rapide que la me´moire. Il peut aussi s’adjoindre une unite´ de calcul spe´cialise´e dans la manipulation des nombres a` virgules flottantes. Chaque cœur, comme dans un syste`me monoprocesseur, est caracte´rise´ par une fre´quence de fonctionnement, exprime´e en MHz (me´gahertz) ou GHz (gigahertz). Cette fre´quence repre´sente le nombre d’instructions e´le´mentaires que le cœur est capable d’exe´cuter. Par exemple, la famille d’architecture ARM Cortex A, tre`s re´pandue sur les smartphones, les petits syste`mes multime´dias, et les syste`mes embarque´s, posse`de des cœurs cadence´s entre 1 et 2 GHz.

La partie assurant la gestion des ressources mate´rielles s’appelle le noyau. Celui-ci est en charge de l’ordonnancement, de la gestion de la me´moire, et de la gestion des interruptions mate´rielles. Le noyau est souvent enrichi de pilotes de pe´riphe´riques (facilitant l’acce`s aux ports se´rie, a` l’e´cran, etc.) et de piles protocolaires (typiquement re´seau, tel que IP, CAN, etc.) : cet ensemble noyau, pilotes, protocoles, se nomme l’exe´cutif. Dans le cas ou` l’ope´rateur peut dialoguer avec le syste`me, ou le ge´rer, par exemple via une interface graphique ou bien lignes de commandes, on parle de syste`me d’exploitation.

1.2 Architecture logicielle

L’application utilisateur, typiquement en charge d’un controˆle de proce´de´ pour les syste`mes temps re´el, est ge´ne´ralement multitaˆche. Chaque taˆche repre´sente un fil d’exe´cution capable de s’exe´cuter paralle`lement aux autres taˆches. Souvent, une taˆche est simplement imple´mente´e par une fonction munie d’une pile, et son e´tat est connu par le noyau. Les e´tats possibles d’une taˆche diffe`rent suivant l’exe´cutif, mais il y a au moins trois e´tats : " preˆt : lorsqu’une taˆche est preˆte, un cœur de calcul doit pouvoir lui eˆtre accorde´ ; " bloque´ : lorsqu’une taˆche attend une certaine dure´e, jusqu’a` une certaine date (une interruption mate´rielle, un e´le´ment de synchronisation tel qu’un se´maphore par exemple, ou encore un message provenant d’une boıˆte aux lettres) elle est bloque´e et ne peut pas se voir allouer un cœur de calcul. Lorsque la condition bloquante est leve´e (de´lai e´coule´, date atteinte, e´le´ment de synchronisation arrive´), la taˆche devient preˆte ; " exe´cute´ : lorsqu’une taˆche preˆte est e´lue par l’ordonnanceur du noyau, elle est place´e sur un et un seul cœur de calcul. Ses instructions sont alors exe´cute´es par le cœur de calcul jusqu’a` ce qu’elle se bloque, ou bien qu’elle soit pre´empte´e par l’ordonnanceur.

1.1.1.2 Communications Lorsque les processeurs partagent la meˆme me´moire centrale, la communication a lieu soit via des caches partage´s (ou des de´rive´s de type scratchpad), soit via la me´moire centrale. Dans le cas de syste`mes a` me´moire distribue´e, la communication a lieu sur des bus. Les bus de communication entre les cœurs fonctionnent de fac¸on synchrone ou asynchrone. Le nombre de cœurs croissant empeˆche un maillage complet du re´seau, par conse´quent, les re´seaux propose´s sont de type mesh (chaque cœur est connecte´ a` ses voisins) ou de type hypercube (meˆme principe mais en trois dimensions). Dans ce cas, un cœur peut servir de routeur pour le transfert de donne´es entre deux cœurs non adjacents. Il en re´sulte que les dure´es de transmission peuvent eˆtre he´te´roge`nes en fonction des cœurs qui communiquent. 1.1.1.3 Mode`les des plateformes

L’ordonnanceur choisit suivant une strate´gie que l’on appelle algorithme d’ordonnancement quelles sont les taˆches a` e´lire, parmi les taˆches preˆtes. Notons que si l’algorithme d’ordonnancement ne laisse jamais une taˆche dans l’e´tat « Preˆt » s’il existe un cœur disponible, on dit que l’algorithme est conservatif.

Les e´tudes sur l’ordonnancement multiprocesseur classifient les syste`mes multiprocesseurs en trois cate´gories : " homoge`ne ou identique : les processeurs et les capacite´s des processeurs sont identiques. Le WCET d’un processeur est donc valide pour tous les processeurs de la plateforme ; " uniforme : les processeurs ont des structures identiques, mais leurs capacite´s sont proportionnelles. Le WCET sur le processeur le plus lent (sans perte de ge´ne´ralite´, il aura une capacite´ unitaire) est multiplie´ par la capacite´ du processeur pour obtenir toutes les dure´es d’exe´cution d’une taˆche sur les processeurs ; " he´te´roge`ne ou non relie´ : chaque processeur posse`de sa propre capacite´ de traitement et ses propres caracte´ristiques internes, inde´pendantes des autres processeurs. Dans ce cas, le WCET de chaque taˆche devra eˆtre de´termine´ pour chacun des processeurs.

1.2.1 Types de taˆches Les taˆches conside´re´es peuvent eˆtre de nature diverse. " Une taˆche re´veille´e pe´riodiquement par l’horloge interne est qualifie´e de pe´riodique. Typiquement, une taˆche charge´e de scruter la valeur d’un capteur analogique, comme un de´bitme`tre, est imple´mente´e sous la forme d’une taˆche pe´riodique. Une taˆche pe´riodique est donc caracte´rise´e par sa pe´riode, totalement maıˆtrise´e. De plus, si sa premie`re date d’activation est connue, toute date de re´veil future est connue. " Une taˆche de´clenche´e par un dispositif externe, comme l’arrive´e d’une trame sur un re´seau de communication, est ge´ne´ralement qualifie´e de sporadique. Ge´ne´ralement on ne connaıˆt pas la premie`re date d’arrive´e de l’e´ve´nement de´clencheur, donc on ne connaıˆt pas la premie`re date d’activation. On caracte´rise une taˆche sporadique par le de´lai minimal se´parant deux activations successives de la taˆche, que l’on appelle pe´riode de la taˆche sporadique. Il faut noter que la pe´riode est ici un de´lai minimal, qui peut croıˆtre a` l’infini.

La tre`s grande majorite´ des re´sultats connus porte sur les syste`mes multiprocesseurs homoge`nes.

1.1.2 Syste`mes re´partis On parle de syste`me re´parti lorsque le syste`me conside´re´ est constitue´ de plusieurs calculateurs connecte´s par un re´seau de communication. Dans le domaine des syste`mes temps re´el, les re´seaux de communication utilise´s sont ge´ne´ralement des bus dits de terrain car ils sont relativement simples, de´terministes, et robustes aux conditions exte´rieures. Exemples de bus de terrain : CAN (Control Area Network), AFDX (Avionics Full DupleX), FlexRay, etc.

S 8 057 – 4

" Une taˆche de´clenche´e par un dispositif externe ou interne, mais dont on ne peut pas caracte´riser le de´lai minimal entre deux activations successives, est qualifie´e d’ape´riodique. Notons que les taˆches ape´riodiques n’ayant pas ou peu e´te´ e´tudie´es dans un contexte multiprocesseur, nous n’e´tudierons pas ce type de taˆches dans cet article.

Toute reproduction sans autorisation du Centre franc¸ais d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＴＶ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＸ

Linux pour le temps réel par

Robert JAY Directeur technique, UXP

Ｒ

Fathi BOUDRA Ingénieur applications, UXP et

Matthieu VIAL Ingénieur applications, UXP

S 8 058 - 2 — 3 — 3

1. 1.1 1.2

Caractéristiques de Linux...................................................................... Avantages..................................................................................................... Principales utilisations ................................................................................

2. 2.1 2.2 2.3

Problématique du temps réel ............................................................... Définitions .................................................................................................... Linux et le temps réel .................................................................................. Déterminisme............................................................................................... 2.3.1 Postulats du modèle temporel .......................................................... 2.3.2 Temps réel en automation ................................................................. Entrées/sorties .............................................................................................

— — — — — — —

4 4 4 4 5 5 5

3.2

Différentes approches et solutions .................................................... Linux, le noyau temps réel.......................................................................... 3.1.1 Comment rendre Linux temps réel ................................................... 3.1.2 Comparatif RTLinux/RTAI ................................................................... Entrées/sorties sur bus de terrain ..............................................................

— — — — —

6 6 6 7 9

4.

Étude d’une application : Alograf .......................................................

—

9

2.4 3. 3.1

Pour en savoir plus...........................................................................................

Doc. S 8 058

es notions de temps réel et de communication dans un système d’exploitation sont indispensables pour les applications techniques et industrielles, et nous partageons ici notre expérience quotidienne du système Linux dans le domaine de l’automation, particulièrement exigeant en termes de réactivité, fiabilité et répétabilité. En effet, les concepteurs de systèmes automatisés de production (SAP) doivent faire face à des contraintes de plus en plus sévères, des exigences de performances en terme de qualité et de productivité, l’utilisation et le suivi des nouvelles technologies tant pour les capteurs et actionneurs qu’au niveau électronique de contrôle-commande, etc., sans parler des progrès énormes des matériaux et de la mécanique. Nous traitons ici des aspects temps réel et déterministes nécessaires aux applications d’informatique industrielle, communication et automation, en laissant le soin à l’utilisateur d’extrapoler vers d’autres domaines d’application. Le monde industriel utilise de plus en plus de PC, déclinés sous toutes les formes : bureautique, industriel en « rack », « shoe box », panel PC, etc. Leur facilité de communication et de fonctionnement coopératif en réseau répond aux besoins d’échanges d’informations pour assurer la réactivité de la production. Ils sont donc entrés dans les ateliers en particulier pour superviser et contrôler des machines de production. On leur confie des tâches de plus en

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｭ｡ｲｳ＠ＲＰＰＴ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur

ＴＷ

S 8 058 − 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＸ

LINUX POUR LE TEMPS RÉEL

Ｒ

_____________________________________________________________________________________________________________

plus complexes, et ils supportent même des applications d’automatisme et de commande numérique. Mais, dans ce cas, on exige d’eux des qualités de robustesse, de fiabilité, de sécurité et bien sûr de performance. Si le matériel répond aujourd’hui à ces critères, il n’en est pas de même pour certains systèmes d’exploitation, développés à l’origine pour des applications bureautiques, donc non critiques. L’utilisateur industriel doit se tourner vers un système d’exploitation répondant à ses exigences, en étant assuré de la pérennité du système, de sa large diffusion et de son évolutivité. C’est le cas du système Linux arrivé à présent à maturité avec un nombre de plus en plus important de références dans les applications critiques et embarquées. Linux est devenu un système d’exploitation robuste intégrant les fonctionnalités d’Unix avec un choix important d’applications et de logiciels libres associés. La qualité de ces logiciels et leur large diffusion font de Linux un produit économique, offrant une plate-forme informatique supportée qui convient à l’environnement de l’entreprise industrielle. Système stable et fiable, Linux répond aux besoins des applications critiques et temps réel de l’entreprise industrielle, en particulier au niveau de la communication dans l’atelier et du contrôle-commande des systèmes automatisés de production. Certaines informations font l’objet de travaux soumis à la propriété industrielle, notamment l’application du paragraphe 4. Le lecteur trouvera des compléments d’information en consultant les sites Internet cités dans [Doc. S 8 058].

1. Caractéristiques de Linux

pendants (tels que Marc Andreesen, développeur de Mosaic, premier véritable navigateur qui révolutionna les échanges, ou Dave McAllister, directeur stratégique technologique de SGI) comme très supérieurs à des systèmes commerciaux similaires.

Linux est un système d’exploitation de type Unix multi-utilisateur et multitâche fonctionnant sur de nombreuses plates- formes, parmi lesquelles la famille des processeurs Intel x86. Linux est une libre implémentation, totalement gratuite, des spécifications POSIX (Portable Operating System Interface uniX), avec des extensions System V et Berkeley (ce qui signifie qu’il ressemble à Unix, mais ne provient pas du tout des mêmes sources). Il est ouvert sur les réseaux et les autres systèmes d’exploitation.

Cela permet à chaque utilisateur de modifier des composants du système d’exploitation et de soumettre des améliorations aux intégrateurs de la distribution officielle. Ce modèle accélère l’intégration de nouvelles fonctionnalités et permet aux utilisateurs de régler les problèmes éventuels dans les plus brefs délais. La présence dans le processus de développement de développeurs venant de divers horizons permet à Linux d’exister sur de nombreuses plates-formes (Mac, Atari, Amiga, Alpha) autres que sa plate-forme d’origine (Intel).

Nota : POSIX est un ensemble de normes de l’IEEE ayant pour but de standardiser l’interface entre les applications et les différents Unix.

La principale singularité de Linux est d’être un logiciel libre (des copies peuvent être distribuées si elles sont accompagnées du code source correspondant), développé de façon collaborative et pour une grande part bénévole par des milliers de programmeurs répartis dans le monde.

Linux n’est plus considéré comme un système en bêta-test depuis que la version 1.0 a été rendue disponible le 14 mars 1994. Comme tout logiciel, il existe des bogues dans le système et de nouveaux bogues apparaîtront et seront corrigés rapidement grâce à son développement collaboratif/communautaire, ce qui lui confère une grande réactivité en ce qui concerne la maintenance corrective.

Bien que le terme Linux, issu du prénom de son créateur, Linus Torvalds, fasse référence au noyau du système d’exploitation, ce nom est communément utilisé pour désigner un ensemble de logiciels qui, avec le noyau, forment un système d’exploitation complet, le terme exact étant « distribution ».

Puisque Linux suit un modèle de développement ouvert, toutes les nouvelles versions seront accessibles au public, qu’elles soient considérées comme suffisamment stables ou non. Cependant, afin d’aider les utilisateurs à déterminer si une version donnée est ou non considérée comme stable, une convention de numérotation spéciale a été mise au point. Les versions x.y.z, où y est un nombre pair, sont stables, et seules des corrections de bogues sont appliquées lorsque z est incrémenté. Par exemple, entre les versions 1.2.2 et 1.2.3, il y a eu uniquement des corrections et aucun ajout de fonctionnalités. Les versions x.y.z, où y est un nombre impair, sont des versions en bêta-test destinées aux développeurs uniquement, peuvent être instables et contiennent de nouvelles fonctionnalités qui sont ajoutées au cours du développement. De temps en temps, quand le développement du noyau se stabilise, un « gel » intervient pour fournir une nouvelle version « stable » (paire) et le développement continue sur une nouvelle version (impaire).

Cet environnement opérationnel incorpore : — des milliers de programmes, parmi lesquels des compilateurs, des interpréteurs, des éditeurs et des utilitaires divers ; — des outils permettant la « connectivité » (Ethernet, SLIP et PPP) et l’interopérabilité ; — la production fréquente de nouvelles versions de logiciels, de même que des versions en cours de développement ; — une équipe de développement dispersée à travers le monde entier et travaillant à rendre Linux portable sur de nouvelles plates-formes et à assurer un support à une communauté d’utilisateurs extrêmement diverse dans ses besoins. Ce modèle de développement joue un grand rôle dans la qualité du résultat obtenu, qui est considérée par des analystes indé-

S 8 058 − 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur

ＴＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＸ

_____________________________________________________________________________________________________________ LINUX POUR LE TEMPS RÉEL

1.1 Avantages

La version stable en 2003 est 2.4.z (z changeant au fur et à mesure que de nouvelles corrections de bogues sont intégrées au noyau) et le développement devrait commencer sur des noyaux expérimentaux, numérotés 2.5.z.

Linux est un système : — puissant : il permet de faire exécuter simultanément de nombreuses applications à sa machine ; — efficace : contrairement à des systèmes bien plus répandus, il n’utilise pour ses besoins propres que très peu de ressources. Les logiciels utilisés par la machine disposent donc de beaucoup plus de puissance pour fonctionner ; — fiable : une machine sous Linux fonctionne 24 h/24 si besoin « sans se plaindre » (si le matériel est prévu pour, en particulier au niveau thermique) ; — robuste : une erreur d’un utilisateur ou un « plantage » éventuel d’une application n’affecte pas le reste du système. D’autre part, il est exceptionnel de devoir l’arrêter : la quasi-totalité des opérations de configuration, mise au point, etc., ne nécessite pas l’arrêt du système ; — très bon marché : le prix demandé par les sociétés qui vendent Linux sur CD-ROM ne sert qu’à couvrir leurs frais et à leur permettre de financer dans une certaine mesure la poursuite de cette activité. Linux étant développé par des passionnés pour le plaisir, personne n’a à supporter le coût de son développement ; — conforme à la norme POSIX et aux standards du marché, en particulier de l’Internet. Cela signifie qu’un logiciel conçu pour un autre système de la même famille (Solaris de Sun, Digital Unix, AIX d’IBM, SCO Unix...) peut être rapidement porté sous Linux et vice versa, ce qui assure une protection de l’investissement logiciel en cas d’obligation de changement de système.

1er

Au février 2003, la version stable de Linux est 2.4.20 et la version de développement est 2.5.62. La version stable précédente 2.2.23 peut toujours être utilisée. La version 2.4 est la référence stable destinée à servir de plate-forme fiable lors du développement de la version 2.5, qui va permettre d’ajouter de nouvelles possibilités et d’essayer des solutions audacieuses et modernes au cœur de Linux. Les versions 1.0 et 1.2 sont maintenant obsolètes. Une fois arrivée à maturité, cette version 2.5 donnera naissance à Linux 2.6, et le jeu continuera de plus belle. Il faut garder à l’esprit que Linux est développé selon un modèle ouvert et réparti, contrairement à la plupart des logiciels connus qui évoluent souvent selon un modèle fermé et centralisé. Cela signifie que la version courante de développement est toujours publique (avec une ou deux semaines de retard) afin que tout le monde puisse l’utiliser. Une version apportant de nouvelles fonctionnalités contient par conséquent presque toujours des bogues, mais ceux-ci sont découverts et corrigés rapidement, souvent en quelques heures, car ceux qui y travaillent sont nombreux. Il est donc facile pour un utilisateur final de les éviter. À l’opposé, le modèle fermé et centralisé signifie que seule une personne ou une équipe travaille sur le projet et qu’elle ne diffuse un programme que lorsqu’elle considère qu’il fonctionne bien. Cela implique souvent de longs intervalles entre les versions, de longs délais avant correction des bogues et un développement moins rapide. Bien sûr, la version la plus récente d’un programme réalisé ainsi est souvent de bonne qualité, mais le développement en est bien plus lent.

1.2 Principales utilisations

Les caractéristiques essentielles de Linux sont les suivantes : — multitâche : exécute plusieurs programmes en pseudo-parallélisme ; — multi-utilisateur : plusieurs utilisateurs actifs sur la même machine en même temps (et sans licence multi-utilisateur !) ; — multi-plate-forme : il fonctionne sur différents processeurs, et pas seulement sur Intel ; — exécution en mode protégé sur les processeurs x86 ; — protection de la mémoire entre les processus, afin qu’un programme ne puisse à lui seul compromettre le fonctionnement de l’ensemble du système ; — bibliothèques partagées liées dynamiquement (DLL, a.out et ELF) ; des bibliothèques statiques sont bien entendu également disponibles ; — très conforme à POSIX, compatible System V et BSD au niveau du programme source ; — plusieurs systèmes de fichiers reconnus : minix-1, Xenix, UFS, EFS, UDF, FAT, FAT32, NTFS, Ext2fs, Ext3fs, NFS, XFS, certains offrant une journalisation ; — support de l’USB v2, du FireWire, de l’I2O ; — possibilité avancée de pare-feu (fonctionnalités de filtrage de paquets, masquerading, load-sharing, quality of service, grâce à Netfilter) ; — support de IPv6 ; — asynchronous I/O (AIO), l’interface POSIX fournissant une efficacité élevée à l’accès des entrées/sorties asynchrone. Un processus peut commencer une ou plusieurs demandes d’E/S à un ou plusieurs fichiers et continuer son exécution.

■ Serveur de fichiers et d’impression : Linux supporte les trois principaux protocoles de partage de fichiers, NFS pour clients Unix, SMB pour clients Windows et AppleShare pour clients MacOS, ainsi que les protocoles de partage d’imprimantes. Linux peut également servir de serveur de fax. ■ Serveur Internet/intranet : on trouve dans les distributions standards de Linux tous les logiciels nécessaires pour réaliser un serveur Internet complet, même sur des machines de puissance modeste. Cela inclut des fonctionnalités de : — transfert et distribution du courrier électronique, des news (Usenet) ; — serveur Web ou FTP ; — serveur de noms de machines ou de domaines. ■ Serveur d’applications client/serveur : un grand nombre de logiciels de serveurs de bases de données (SGBD), relationnels, relationnels-objets ou objets, commerciaux ou libres, sont disponibles pour Linux. Avec ces logiciels, surtout du côté commercial, ce sont des milliers d’applicatifs qui existent. ■ Station de développement : Linux dispose, le plus souvent sous forme de logiciel libre, des outils de développement pour la plupart des langages actuels (C, C++, Fortran, Java, Cobol, LISP, Prolog, SmallTalk). On trouve aussi des outils pour le contrôle des sources, pour le travail en groupe, pour le suivi des erreurs, pour les tests. ■ Station bureautique : grâce à des suites bureautiques intégrées commerciales comme Applix ou StarOffice et à des environnements graphiques comme KDE ou fvwm95, les stations bureautiques sous Linux offrent les mêmes fonctionnalités que leurs équivalents sous Windows ou MacOS. L’utilisateur dispose par exemple de traitement de texte, tableur, logiciel de présentation et de dessin, gestion de fichiers, partage de documents, intégration des technologies Internet/intranet (courrier électronique, Web).

Pour plus de détails, le lecteur est invité à consulter l’article Système Linux [H 1 538].

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur

ＴＹ

S 8 058 − 3

Ｒ

Ｒ

ＵＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ

Ordonnancement temps re´el Ordonnancement re´parti par

Emmanuel GROLLEAU Professeur des universite´s en Informatique a` l’ISAE-ENSMA (Chasseneuil du Poitou)

Michae¨l RICHARD Maıˆtre de confe´rences en Informatique a` l’ISAE-ENSMA (Chasseneuil du Poitou)

Ｒ

Pascal RICHARD Professeur des universite´s en Informatique a` l’Universite´ de Poitiers et

Fre´de´ric RIDOUARD Maıˆtre de confe´rences en Informatique a` l’Universite´ de Poitiers

1. 1.1

S 8 059 – 2 — — — — —

2 4 4 4 5

Re´seau ............................................................................................... Introduction ........................................................................................ Mode`le OSI ......................................................................................... 2.2.1 De´finition ................................................................................. De´lai de bout en bout ........................................................................ Protocoles ........................................................................................... Re´seaux sans fil.................................................................................. Re´seau CAN ........................................................................................ 2.6.1 Pre´sentation ............................................................................. 2.6.2 De´terminisme .......................................................................... Re´seau AFDX ...................................................................................... 2.7.1 Pre´sentation ............................................................................. 2.7.2 De´terminisme ..........................................................................

— — — — — — — — — — — — —

5 5 5 5 6 6 6 6 6 7 7 7 8

Ordonnancement et validation..................................................... Mode`le de taˆches ............................................................................... 3.1.1 Analyse d’ordonnanc¸abilite´ : cas d’un arbitrage de bus base´ sur les priorite´s ........................................................................ Analyse holistique .............................................................................. 3.2.1 De´finitions et principe de l’analyse holistique ....................... 3.2.2 Calcul du pire temps de re´ponse des taˆches .......................... 3.2.3 Calcul du pire temps de re´ponse des messages .................... 3.2.4 Exemple d’application ............................................................. Autre me´thode : Network Calculus .................................................... 3.3.1 Introduction ............................................................................. 3.3.2 Mode´lisation d’un re´seau AFDX par le Network Calculus ..... 3.3.3 De´lai de communication de bout en bout .............................. 3.3.4 Optimisation du calcul re´seau : se´rialisation ......................... 3.3.5 Algorithme ............................................................................... 3.3.6 Exemple d’application .............................................................

— —

8 8

— — — — — — — — — — — — —

8 9 9 10 12 13 14 14 14 17 19 21 22

4. 4.1 4.2

Placement......................................................................................... Proble`mes de validation .................................................................... Proble`mes d’optimisation ..................................................................

— — —

23 23 23

5.

Conclusion........................................................................................

—

23

1.2 1.3

2. 2.1 2.2 2.3 2.4 2.5 2.6

2.7

3. 3.1 3.2

3.3

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠､￩｣･ｭ｢ｲ･＠ＲＰＱＳ

Introduction aux syste`mes temps re´el et re´partis ................... Syste`mes re´partis ge´ne´raux : caracte´ristiques et proble`mes de conception ..................................................................................... Re´partition mate´rielle et logique ....................................................... Syste`mes temps re´el re´partis ............................................................ 1.3.1 De´finition ................................................................................. 1.3.2 Proble´matique .........................................................................

Pour en savoir plus..................................................................................

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＱ

Doc. S 8 059

S 8 059 – 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

a complexite´ des proce´de´s temps re´el a` commander ou a` superviser, le nombre e´leve´ de donne´es et d’e´ve´nements a` traiter, la re´partition topologique des proce´de´s, d’une part, et l’apparition depuis plusieurs anne´es de re´seaux de´die´s aux syste`mes embarque´s, d’autre part, sont tous des facteurs qui ont conduit a` repenser les applications temps re´el centralise´es. Aujourd’hui, la notion d’architecture re´partie, ou distribue´e, est tre`s utilise´e dans le milieu industriel, notamment dans l’industrie du transport. A` titre d’exemple, les domaines d’applications faisant couramment appel aux architectures re´parties sont :

L

Ｒ

 le controˆle d’e´quipements dans les transports (avionique, automobile, ferroviaire…) ;  le controˆle et la re´gulation de trafic en milieu urbain ;  les industries (controˆle/commande de proce´de´s…) ;  le domaine militaire (suivi de trajectoires de missiles…) ;  le domaine ae´rospatial (suivi de satellites, pilotage automatique…) ;  la domotique (se´curite´ d’habitations…) ;  les te´le´communications (syste`mes de commutation…) ;  le domaine me´dical (assistance et controˆle de malades…). Un syste`me informatique destine´ a` commander ou a` superviser des ope´rations est compose´, le plus souvent, de plusieurs unite´s de traitement (ordinateurs, automates programmables, ECU [Electronic Control Unit]…), des capteurs, des actionneurs, des pe´riphe´riques de visualisation et de dialogue avec les ope´rateurs. L’ensemble de ces e´le´ments est interconnecte´ par un re´seau ou par plusieurs re´seaux interconnecte´s entre eux (des re´seaux industriels, des re´seaux bureautiques, des bus de terrain, etc.). Ce type de syste`me est qualifie´ de syste`me temps re´el et re´parti (ou distribue´ ou encore de´centralise´). Dans ce type de syste`me, l’ordonnancement des taˆches et des messages joue un roˆle fondamental dans le processus de validation temporelle de ceux-ci. Nous pre´sentons dans cet article les diffe´rentes techniques d’analyse d’ordonnanc¸abilite´ des taˆches, en fonction de leur type, et des messages en fonction du type de re´seau utilise´ (CAN, AFDX…).

de communication, on distingue les multiprocesseurs ou` la communication peut se passer avec ou sans me´moire commune et les re´seaux d’ordinateurs ou` la communication se passe obligatoirement sans me´moire commune (c’est-a`-dire, avec e´change de messages). Les machines paralle`les sont constitue´es de plusieurs processeurs, en ge´ne´ral identiques et fortement couple´s ; on trouve dans [S 8 057] une e´tude comple`te de ce type d’architecture. Les re´seaux d’ordinateurs sont forme´s de machines autonomes, pouvant eˆtre he´te´roge`nes et faiblement couple´es. Les distances entre les processeurs d’un re´seau d’ordinateurs peuvent eˆtre courtes (quelques dizaines de me`tres, voire moins) ou tre`s importantes (des milliers de kilome`tres, voire plus, pour les re´seaux de satellites). La figure 1 pre´sente un exemple de syste`me re´parti.

1. Introduction aux syste`mes temps re´el et re´partis On appelle syste`me temps re´el et re´parti tout syste`me compose´ de plusieurs entite´s interconnecte´es par un sous-syste`me de communication et qui coope`rent a` la re´alisation d’un ensemble de fonctions sujettes a` des contraintes de temps (ces contraintes pouvant eˆtre strictes ou non selon la nature de l’application a` laquelle est associe´ le syste`me) [1] [2] [3]. Les syste`mes temps re´el et re´partis sont des cas particuliers des syste`mes re´partis. Ainsi, nous commenc¸ons par nous inte´resser aux syste`mes re´partis non temporellement contraints, afin de pre´senter les principales proble´matiques rencontre´es lors de l’e´tude de ceux-ci. Nous pre´sentons ensuite les proble´matiques induites par l’adjonction de contraintes temporelles.

On dit qu’un syste`me re´parti est constitue´ d’un ensemble de processeurs, de sites ou de nœuds interconnecte´s entre eux (figure 2). Par la suite, nous utiliserons indiffe´remment, lorsqu’il n’y a pas d’ambiguı¨te´, les termes « nœud », « site » et « processeur ». Le de´veloppement des syste`mes re´partis est motive´ par plusieurs raisons, notamment :

1.1 Syste`mes re´partis ge´ne´raux : caracte´ristiques et proble`mes de conception

– la demande d’interconnecter le plus possible les applications existantes, en particulier pour les services multimedias (te´le´confe´rence, te´le´-enseignement, te´le´me´decine, inge´nierie coope´rative…) ; – la volonte´ d’augmenter la disponibilite´ d’un syste`me informatique pour permettre le remplacement d’un composant du syste`me par un autre sans de´gradation significative (voire sans aucune

Un syste`me re´parti est constitue´ d’un ensemble de processeurs relie´s entre eux par un sous-syste`me de communication leur permettant d’e´changer des informations. Selon la nature du sous-syste`me

S 8 059 – 2

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– ORDONNANCEMENT TEMPS RE´EL

Calculateur CFAO

Calculateur de gestion

Calculateur GPAO

Contrôleur de qualité

Passerelle

Réseau d'usine

Superviseur

Gestion de maintenance

Réseau de cellule

Commande numérique

Automate programmable

C

C

C

Capteurs Bus de terrain

A

A

Commande de robot

C

Bus de terrain A

Actionneurs

A

A

Figure 1 – Un exemple de syste`me re´parti

automatise´s de production, l’arreˆt du syste`me temps re´el est synonyme d’un arreˆt de production ; – le souci de faciliter l’e´volution mate´rielle ou fonctionnelle d’un syste`me en remplac¸ant ou en ajoutant certains e´le´ments sans avoir a` arreˆter les autres e´le´ments du syste`me ; – le partage de ressources mate´rielles (des imprimantes, des unite´s de sauvegarde massive…) ou logicielles (des bases de donne´es, des logiciels…) ; – la demande de plus de puissance de calcul au moindre couˆt (par exemple, plusieurs PC en re´seau couˆtent moins cher qu’un gros ordinateur) ; – enfin, les besoins d’adaptation du syste`me informatique a` son environnement : aujourd’hui, que ce soit dans les applications bureautiques ou dans les applications industrielles, les ordinateurs participant a` une application se re´partissent sur des e´tendues ge´ographiques plus ou moins importantes – sur plusieurs e´tages d’un immeuble, ou sur des dizaines de kilome`tres carre´s dans le cas de raffineries de pe´trole, par exemple. Il est donc important, pour le syste`me informatique, de tenir compte de cette re´partition ge´ographique.

Site

Site

Réseau

Site

de

Site

communication

Site

Les syste`mes re´partis ont des caracte´ristiques qui les distinguent des syste`mes centralise´s :

Site

– les de´lais de communication entre sites varient d’un message a` l’autre et selon les protocoles du re´seau de communication utilise´s ; – ils n’ont pas d’horloge commune. Chaque site a sa propre perception du temps et, comme les horloges physiques de´rivent par rapport au temps de re´fe´rence, les diffe´rents temps lus sur les sites peuvent eˆtre diffe´rents a` une meˆme heure universelle ;

Figure 2 – Architecture d’un syste`me re´parti

de´gradation) du service rendu. Cet aspect est primordial dans les applications temps re´el et re´parties pour lesquelles les situations d’arreˆt doivent eˆtre les plus rares possibles. Dans les syste`mes

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＳ

S 8 059 – 3

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Ｒ

Selon les spe´cificite´s d’un syste`me, on peut avoir des fonctions centralise´es, d’autres partiellement re´parties et d’autres comple`tement re´parties. Par exemple, on peut avoir dans un meˆme syste`me : une fonction comple`tement re´partie pour la synchronisation d’horloges, une base de donne´es e´clate´es sur plusieurs sites, mais toutes les transactions sur la base sont controˆle´es par un seul site et une gestion centralise´e des fichiers. Tout n’est pas re´parti dans un syste`me re´parti ! Il est clair qu’il ne peut y avoir de re´partition logicielle sans re´partition mate´rielle, mais la re´ciproque n’est pas vraie. La de´centralisation mate´rielle peut aider ou inciter a` la re´partition logicielle.

– l’absence d’une me´moire commune a pour conse´quence l’impossibilite´ de de´finir un e´tat global a` l’aide de variables communes. Encore plus important, l’existence de de´lais de communication variables et l’absence d’un re´fe´rentiel temporel commun ont pour conse´quence que chaque site a sa propre vue qui peut eˆtre diffe´rente de celles des autres sites a` un meˆme instant du temps universel ; – comme le nombre d’e´quipements d’un syste`me re´parti est plus e´leve´ que celui d’un syste`me centralise´, les risques de de´faillances y sont plus importants. Des me´canismes de tole´rance aux fautes doivent eˆtre inte´gre´s pour re´pondre a` l’exigence de ne pas de´grader la suˆrete´ de fonctionnement et, en particulier, la disponibilite´ de ces syste`mes [4] ; – l’existence d’interfaces de communication avec l’exte´rieur rend les syste`mes re´partis plus vulne´rables aux intrusions ; – les applications re´parties sont plus complexes a` spe´cifier, a` concevoir, a` implanter, a` tester et a` valider.

1.3 Syste`mes temps re´el re´partis Les syste`mes temps re´el sont des syste`mes informatiques qui doivent re´agir a` des e´ve`nements tout en respectant des contraintes temporelles. De nombreuses de´finitions diffe´rentes existent pour les syste`mes temps re´el dans la litte´rature [5] [6] [7]. Nous utilisons la de´finition employe´e par J.A. Stankovic : un syste`me temps re´el est un syste`me pour lequel la correction ne de´pend pas seulement des re´sultats, mais e´galement du temps auquel ils sont fournis [8]. Ainsi, les syste`mes temps re´el sont des syste`mes re´actifs [9] pour lesquels des contraintes temporelles doivent eˆtre respecte´es. Si les contraintes temporelles de l’application ne sont pas respecte´es, le syste`me subit alors une de´faillance ; on parle aussi de faute temporelle. Dans le cas des syste`mes temps re´el, la re´partition est parfois indispensable : le proce´de´ physique est fortement re´parti, les traitements, les contraintes temporelles de´passent les capacite´s d’un seul processeur, le nombre de fonctionnalite´s assure´es par le syste`me est tre`s important, l’arreˆt du syste`me est inacceptable…

L’impossibilite´ de disposer instantane´ment d’un e´tat global identique sur tous les sites pose beaucoup de proble`mes pour la prise de de´cisions relative a` la gestion et au partage de ressources, a` la validation d’actions atomiques faisant intervenir plusieurs sites, etc. C’est aussi l’une des principales sources de complexite´ des algorithmes de placement de taˆches sur les diffe´rents sites.

1.2 Re´partition mate´rielle et logique Les termes « de´centralise´ », « re´parti » et « distribue´ » sont souvent utilise´s de manie`re ambigue¨. Pour les pre´ciser, il faut tout d’abord distinguer la re´partition mate´rielle et la re´partition logique. La re´partition mate´rielle (ou encore de´centralisation physique) est obtenue en utilisant plusieurs unite´s de traitement qui sont interconnecte´es par un sous-syste`me de communication. Par exemple, un syste`me de controˆle/commande constitue´ de capteurs et d’actionneurs en contact direct avec le proce´de´ physique, d’automates programmables dans les salles de commande et de stations de travail dans les salles de CAO, est un syste`me avec une architecture mate´rielle re´partie (ou de´centralise´e). La taxinomie est plus complexe lorsqu’il s’agit du logiciel. En effet, il faut distinguer : – la re´partition des donne´es (ou re´partition de l’information) ; – la re´partition des traitements ; – la re´partition du controˆle.

1.3.1 De´finition La re´partition des syste`mes temps re´el introduit de nouveaux proble`mes, notamment : – les calculs fonde´s sur les contraintes temporelles qui font re´fe´rence au temps chronome´trique ou a` une date absolue risquent de comporter des erreurs de calcul trop importantes et ainsi de ne pas eˆtre cre´dibles, a` cause de de´rives trop grandes entre les horloges des diffe´rents sites ; – l’observation de l’e´volution des diffe´rents constituants du proce´de´ est retarde´e et diffe´rente d’un site a` un autre de par des de´lais de communication variables ; – les tests d’ordonnanc¸abilite´ et les calculs de garantie des contraintes de temps des taˆches communicantes, donc l’ordonnancement temps re´el re´parti, sont tributaires de ces de´rives d’horloges et de ces de´lais de communication ; – la tole´rance aux fautes est beaucoup plus complexe, ce qui rend encore plus difficile de tole´rer des fautes tout en respectant les contraintes de temps.

 L’ensemble des informations (variables simples, fichiers…) qui sont partage´es entre des taˆches distantes peut eˆtre stocke´ sur un seul site (on parle, dans ce cas, de stockage centralise´ de l’information) ou e´clate´ sur plusieurs sites (on parle, dans ce cas, de stockage de´centralise´ de l’information). Cette re´partition ne pre´juge en rien sur la fac¸on dont le controˆle de l’acce`s aux informations partage´es sera ge´re´.

Dans le cas de l’ordonnancement temps re´el, qui nous inte´resse ici, la re´partition implique l’ordonnancement conjoint de taˆches et de messages. En effet, le respect ou non des contraintes temporelles des messages se re´percute de manie`re directe sur celui des taˆches puisque l’attente de re´ception d’un message par une taˆche est e´quivalente a` l’attente d’acquisition d’une ressource ; si le message n’arrive pas a` temps, les contraintes temporelles de la taˆche peuvent ne pas eˆtre garanties. L’ordonnancement de taˆches dans un syste`me re´parti se re`gle a` deux niveaux : au niveau de chaque processeur et re´seaux, et au niveau du placement des taˆches sur les processeurs. Le proble`me d’ordonnancement conjoint des taˆches et messages est traite´ dans le paragraphe 3 ; le proble`me de placement sera brie`vement pre´sente´ dans le paragraphe 4. Pour avoir plus de de´tails sur les caracte´ristiques des algorithmes d’ordonnancement, nous recommandons au lecteur de se reporter a` [S 8 055] et [S 8 057]. Dans toute la suite, les algorithmes d’ordonnancement utilise´s sur les diffe´rents sites d’un syste`me re´parti sont conside´re´s enligne, pre´emptifs et conservatifs. La conception et l’implantation des syste`mes temps re´el et re´partis ne´cessitent des protocoles de communication qui garantissent

 La re´partition des traitements conduit a` affecter les programmes (ou taˆches) a` des sites pour y eˆtre exe´cute´s. Cette re´partition ne pre´juge en rien de la fac¸on dont l’exe´cution des programmes sera ge´re´e, c’est-a`-dire, de la fac¸on dont sera effectue´ le controˆle de l’exe´cution des taˆches.  Le controˆle concerne le de´clenchement et l’arreˆt des taˆches, le transfert des taˆches d’un site vers un autre, l’acce`s aux ressources partage´es, la validation d’ope´rations faisant intervenir plusieurs sites, etc. Il peut eˆtre a` la charge d’un seul site (il s’agit d’un controˆle comple`tement centralise´), d’une partie des sites (il s’agit d’un controˆle partiellement re´parti) ou de tous les sites (il s’agit d’un controˆle comple`tement re´parti). Lorsque le controˆle est distribue´, la prise de de´cision (par exemple, pour valider une ope´ration sur une base de donne´es, pour lancer la production d’un ensemble de pie`ces ou, encore, pour sortir le train d’atterrissage d’un avion) peut eˆtre prise par chaque site se´pare´ment, par tous les sites (dans ce cas, si un seul site manque, la de´cision ne peut eˆtre prise) ou a` la majorite´ des sites (on parle, dans ce cas, de de´cision par consensus). Il est important de signaler que la re´partition (ou de´centralisation) doit eˆtre conside´re´e se´pare´ment pour chaque fonction du syste`me.

S 8 059 – 4

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– ORDONNANCEMENT TEMPS RE´EL

– de´finition de l’ensemble des messages avec pour chaque message : la taˆche e´mettrice, la taˆche re´ceptrice et la longueur du message ; – protocole re´seau de´finissant le support, l’e´change et l’ordonnancement des messages.

aux taˆches communicantes de recevoir, dans les de´lais, les messages qui leur sont destine´s. Pour les messages avec des e´che´ances strictes de de´livrance, il faut que les protocoles donnent des garanties et, pour les messages non critiques du point de vue temporel, la strate´gie du protocole est le meilleur effort (c’est-a`-dire, minimiser le retard des messages et le nombre des messages tardifs). Dans un syste`me temps re´el et re´parti, les taˆches sont synchronise´es en utilisant le temps chronome´trique (par exemple, activation de taˆches a` des instants pre´cis ou de manie`re pe´riodique). Il en est de meˆme pour la datation de donne´es et d’e´ve´nements apparaissant sur les diffe´rents sites. Le bon fonctionnement d’un syste`me re´parti ne´cessite le plus souvent l’existence d’un temps global accessible a` tous les sites. La solution la plus couramment utilise´e pour e´tablir un temps global est la synchronisation d’horloges physiques. D’autres solutions fonde´es sur l’utilisation de re´cepteur d’un temps diffuse´ par une station de radio ou un satellite peuvent eˆtre envisage´es. Beaucoup d’algorithmes ont e´te´ propose´s pour re´gler le proble`me de synchronisation d’horloges. Le lecteur de´sireux d’approfondir ses connaissances sur ce sujet peut consulter les re´fe´rences [10] [11].

Dans le paragraphe suivant, nous pre´sentons les deux protocoles caracte´ristiques des syste`mes re´partis critiques : CAN et AFDX.

2. Re´seau 2.1 Introduction Un re´seau se de´finit par un ensemble d’entite´s communicantes entre elles via un me´dia. Les entite´s peuvent eˆtre aussi bien des personnes (re´seaux sociaux), des voitures (re´seaux routiers) que des syste`mes informatiques (re´seaux informatiques). Un syste`me re´parti est compose´ d’un ensemble de processeurs relie´s entre eux par un re´seau. Ce re´seau permet l’e´change de donne´es conduisant au bon fonctionnement du syste`me. Ces donne´es ou messages sont repre´sente´s sous forme de paquets appele´s aussi trames de donne´es. Dans un re´seau de paquets, chaque e´le´ment permettant le transport des paquets de bout en bout est appele´ un « nœud ».

1.3.2 Proble´matique La validation d’un syste`me temps re´el passe par une ve´rification du respect des contraintes temporelles de l’ensemble des taˆches qui compose le syste`me. Le syste`me utilise un algorithme d’ordonnancement pour choisir a` chaque instant la taˆche a` exe´cuter. L’algorithme est en-ligne et se base sur les priorite´s pour e´lire la taˆche. Les taˆches sont pe´riodiques et la dure´e de vie du syste`me est suppose´e infinie. Les syste`mes re´partis sont de´finis par un ensemble de taˆches s’exe´cutant sur des processeurs et s’e´changeant des messages. Le re´seau est le seul moyen de communication entre les processeurs. Il repre´sente donc une ressource partage´e par les taˆches. Le re´seau permet l’e´change de donne´es (messages) assurant le bon fonctionnement du syste`me. Plusieurs proble`mes sont fonction des caracte´ristiques du syste`me re´parti : – placement des taˆches sur les processeurs ; – migration entre les processeurs des taˆches au cours de leur exe´cution ; – synchronisation entre les taˆches ; – re´partition des taˆches entre les processeurs : chaque taˆche est assigne´e (de´finitivement) a` un processeur (pas de migration) ; – algorithme d’ordonnancement des taˆches sur les processeurs ;

4

3

2

1

2.2 Mode`le OSI 2.2.1 De´finition La complexite´ des communications re´seau a conduit a` les normaliser par un mode`le en couches. De´fini en 1977, le mode`le OSI (Open System Interconnected) est compose´ de sept couches et a e´te´ normalise´ par l’ISO (International Organization for Standardization). Ce mode`le de´finit les principales fonctionnalite´s de la communication entre deux e´le´ments re´seau. Pour plus de de´tails sur le mode`le OSI, le lecteur peur se re´fe´rer a` l’article [S 7 574], paragraphe 1.2. Dans les re´seaux, et plus particulie`rement, dans les re´seaux embarque´s (ou temps re´el), le mode`le OSI n’est pas totalement imple´mente´. Ainsi, la pile re´seau utilise´e, dans un contexte embarque´ est simple et n’imple´mente ge´ne´ralement que les quatre premie`res couches (voire moins). Le sche´ma ge´ne´ral du mode`le OSI adapte´ aux re´seaux temps re´el est pre´sente´ par la figure 3.

ÉMETTEUR

RÉCEPTEUR

Transport

Transport

Réseau

Réseau

Liaison de données

Liaison de données

Physique

Physique

4

3

2

1

Figure 3 – Mode`le OSI adapte´ aux re´seaux temps re´el

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＵ

S 8 059 – 5

Ｒ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＵＹ ORDONNANCEMENT TEMPS RE´EL ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

2.3 De´lai de bout en bout

Enfin, en utilisant les me´thodes dynamiques par compe´tition, chaque station du re´seau essaie quand elle en a besoin d’acce´der au canal sans tenir compte des besoins des autres. Si deux stations e´mettent en meˆme temps, elles rentrent en conflit et une solution doit eˆtre de´finie. La famille des CSMA (Carrier Sense Multiple Access) est un exemple de me´thodes dynamiques par compe´tition.

Les communications peuvent eˆtre classe´es en deux cate´gories : connecte´ et non-connecte´. Le mode connecte´ est une communication de type « te´le´phonique » : l’e´metteur pre´vient le destinataire d’un envoi de messages qui confirme a` l’e´metteur sa disponibilite´. En mode asynchrone, ou non-connecte´, (communication de type « courrier »), l’e´metteur envoie son message sans en avoir averti pre´alablement le destinataire.

Le principe ge´ne´ral d’une me´thode CSMA consiste a` laisser les nœuds du re´seau e´mettre librement des trames. Lorsque deux nœuds e´mettent simultane´ment, une collision se produit. Chaque station de´tecte la collision de sa trame, attend un temps ale´atoire et re´essaye d’e´mettre.

Le mode connecte´ permet des communications point a` point (ou unicast). Tandis que le mode non connecte´ permet le mode diffusion (ou multicast) :

Ｒ

Pour une e´tude approfondie sur les protocoles, le lecteur peut se reporter a` l’article [H 2 285]. De plus, pour les me´thodes d’acce`s, il pourra consulter l’article [S 8 120].

– mode de diffusion : les paquets sont envoye´s sur l’ensemble du re´seau (ou a` un groupe pre´de´fini de destinataires). Il n’utilise qu’un seul support et est adapte´ a` une topologie en bus ou en anneau ; – mode point a` point : les messages sont envoye´s de lien en lien jusqu’a` leur arrive´e aux destinataires choisis. Ils s’utilisent sur des topologies en e´toile ou maille´es.

2.5 Re´seaux sans fil Les re´seaux sans fil regroupent l’ensemble des re´seaux qui interconnectent des e´le´ments entre eux sans aucun caˆble, uniquement par ondes. Comme pour les re´seaux classiques, ils pourront eˆtre classifie´s selon leur taille :

On peut faire une analogie entre le mode non-connecte´ et l’envoi de courrier. Il n’y a pas de garantie que le paquet ait e´te´ correctement rec¸u. Pour reme´dier a` ce proble`me, les re´seaux embarque´s sont de´finis avec des processus permettant de s’assurer de la fiabilite´ de la communication et par conse´quent, de la non perte d’information. La majorite´ des re´seaux embarque´s fonctionne en mode non connecte´.

– les re´seaux personnels sans fils (exemple : les re´seaux bluetooth) : ils font 1 ou 2 me`tres de grandeur ; – les re´seaux locaux sans fil (exemple : le WiFi) : ils mesurent de l’ordre d’une dizaine de me`tres ou un peu plus ; – les re´seaux me´tropolitains sans fil (exemple : wimax) : ils s’e´tendent sur plusieurs kilome`tres ; – les re´seaux e´tendus sans fil (exemple : GSM, 4G) : ils s’e´tendent sur plusieurs centaines de kilome`tres.

En plus de la non perte d’information, dans certains contextes critiques comme l’ae´ronautique, les re´seaux ont besoin de garantir une borne supe´rieure sur le de´lai de bout en bout de chaque paquet e´change´ sur le re´seau (certification requise du re´seau). Le de´lai de bout en bout d’un paquet de´signe le temps mis par une trame entre son entre´e sur le re´seau et sa re´ception a` son point de sortie.

Le de´ploiement d’un re´seau sans fil de´finit le moyen de communication entre les e´le´ments d’un re´seau. Il existe deux mode`les de de´ploiement :

Un re´seau est dit « de´terministe » s’il peut certifier la non perte d’information et en plus, garantir une borne supe´rieure sur le de´lai de traverse´e d’un re´seau de bout en bout de chaque paquet. Pour garantir le de´terminisme, il y a deux familles de me´thodes :

– le mode infrastructure : pour communiquer entre eux, les e´le´ments re´seaux doivent se connecter a` des points d’acce`s et les donne´es e´change´es passent de routeur en routeur jusqu’au destinataire ; – le mode Ad-Hoc : les e´le´ments re´seaux se connectent directement entre eux pour communiquer.

– interdire les collisions sur les liens ; – de´tecter les collisions sur les liens et imple´menter des proce´dures de de´tection et de re´e´mission.

La norme la plus couramment utilise´e est la 802.11 et pour plus d’informations sur les re´seaux sans fil, le lecteur peut se re´fe´rer a` l’article [TE 7 375].

2.4 Protocoles Les protocoles re´seaux de´crivent les me´canismes mis en place dans les nœuds afin d’effectuer l’acheminement des paquets, mais aussi pour la gestion des erreurs et le controˆle des flux sur le medium de communication.

2.6 Re´seau CAN

Les diffe´rentes me´thodes d’acce`s au me´dia de communication peuvent se classer en trois cate´gories :

2.6.1 Pre´sentation

– me´thodes statiques ; – me´thodes dynamiques par e´lection ; – me´thodes dynamiques par compe´tition.

Le bus CAN (Controller Area Network) a e´te´ de´veloppe´ par Bosch et Intel. Il fut pre´sente´ en 1985 et standardise´ au de´but des anne´es 1990 par la norme ISO 11898. Pour plus d’informations sur le bus CAN, on pourra se re´fe´rer a` l’article [S 8 140]. A` ses de´buts, il fut principalement utilise´ dans le monde automobile mais maintenant, il est utilise´ dans la plupart des secteurs industriels comme l’ae´ronautique. Le bus connecte par un caˆble (ou bus) un ensemble de stations (appele´s aussi « nœuds ») qui vont communiquer tour a` tour.

L’utilisation des me´thodes statiques consiste a` multiplexer le temps ou les fre´quences d’e´mission statiquement entre les stations e´mettrices. Par exemple, le TDMA (Time Division Multiple Access) est un mode de multiplexage temporel applique´ sur le segment statique du re´seau FlexRay [12]. Il de´finit pour chaque e´metteur un intervalle de temps pendant lequel il sera le seul a` transmettre des donne´es sur le canal.

Le bus CAN n’imple´mente pas toutes les couches du mode`le OSI mais uniquement les deux premie`res (physique et liaison). Le bus CAN repose sur une paire torsade´e avec un de´bit maximum de 1 Mbps. La longueur maximum du bus de´pend du de´bit ; il est par exemple de 40 m pour un de´bit de 1 Mbps. Au niveau de la souscouche MAC, il utilise le protocole CSMA/CR pour ge´rer l’acce`s des stations au bus.

Les me´thodes dynamiques par e´lection de´finissent un e´le´ment arbitraire qui choisira la station autorise´e a` e´mettre. Ce choix arbitraire peut eˆtre fait soit par une station « maıˆtre » qui choisira en fonction de ses crite`res ou par un jeton qui circule entre les stations et seule la station qui posse`de le jeton peut transmettre sur le canal.

S 8 059 – 6

Copyright © - Techniques de l’Inge´nieur - Tous droits re´serve´s

ＵＶ

Supervision des systèmes industriels (Réf. Internet 42396)

1– Méthodes fonctionnelles et outils

Ｓ

2– Systèmes d'exploitation temps réel 3– Technologies logicielles et programmation

Réf. Internet

Langages de programmation pour systèmes automatisés : norme CEI 61131-3

S8030

59

Norme CEI 61499 : programmation distribuée et événementielle des procédés

S8031

65

Réalisation technologique du GRAFCET

S8032

67

Microcontrôleurs  : principes et aspects temps réel

S8035

73

Approche objet

S8063

79

Programmation en langage C++. Concepts

S8065

83

Programmation en langage C++. Exemples

S8066

87

Linux embarqué

H1570

89

OS embarqués

H8200

93

Java dans les systèmes embarqués et temps réel

S8068

97

UML pour temps réel

S8070

101

Qualité des logiciels industriels

R8080

105

Contrefaçon de logiciel

S8090

109

Spéciications fonctionnelles. Génération automatique de code

S8100

115

Programmation graphique des applications de contrôle-commande. Notions générales et langage G

S8205

121

Programmation graphique des applications de contrôle-commande. Logiciel LabVIEW et applications industrielles

S8206

127

page

4– Interaction homme-machine



Sur www.techniques-ingenieur.fr • Saisissez la référence Internet pour accéder directement aux contenus en ligne • Retrouvez la liste complète des ressources documentaires ＵＷ

5– Exigences contractuelles

Ｓ

ＵＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ

Langages de programmation pour systèmes automatisés : norme CEI 61131-3 par

Nicolas JOUVRAY ICS Triplex France, ISaGRAF

Ce texte est la version actualisée de l’article écrit par Patricia JARGOT en 1999.

S 8 030v2 - 2

1.

Architecture de projet ............................................................................

2.

Objets communs .......................................................................................

—

4

3.

Langage SFC ..............................................................................................

—

10

4.

Langage FC .................................................................................................

—

15

5.

Langage FBD ..............................................................................................

—

15

6.

Langage LD.................................................................................................

—

17

7.

Langage ST .................................................................................................

—

21

8.

Langage IL ..................................................................................................

—

26

Pour en savoir plus ........................................................................................... Doc. S 8 030v3

es langages de programmation des systèmes automatisés sont décrits dans deux normes complémentaires : – la norme CEI 61131-3 fait l’objet du présent article ; – la norme CEI 61499 est décrite dans l’article [S 8 031]. La norme CE 61131-3 définit entre autres choses, cinq langages qui peuvent être utilisés pour la programmation d’applications d’automates programmables industriels (API). Les cinq langages sont : – SFC (« Sequential Function Chart ») : issu du langage GRAFCET, ce langage, de haut niveau, permet la programmation aisée de tous les procédés séquentiels ; – FBD (« Function Block Diagram », ou schéma par blocs) : ce langage permet de programmer graphiquement à l’aide de blocs, représentant des variables, des opérateurs ou des fonctions. Il permet de manipuler tous les types de variables ; – LD (« Ladder Diagram », ou schéma à relais) : ce langage graphique est essentiellement dédié à la programmation d’équations booléennes (true/false) ; – ST (« Structured Text » ou texte structuré) : ce langage est un langage textuel de haut niveau. Il permet la programmation de tout type d’algorithme plus ou moins complexe ; – IL (« Instruction List », ou liste d’instructions) : ce langage textuel de bas niveau est un langage à une instruction par ligne. Il peut être comparé au langage assembleur. Cet article présente sommairement l’architecture d’un projet d’automatisme et introduit la notion de programme, puis décrit de façon détaillée la syntaxe des cinq langages de la norme CEI 61131-3.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｪｵｩｮ＠ＲＰＰＸ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＵＹ

S 8 030v2 – 1

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ LANGAGES DE PROGRAMMATION POUR SYSTÈMES AUTOMATISÉS : NORME CEI 61131-3 _________________________________________________________

Les POU de la section « Fonctions » sont des programmes qui peuvent être appelés par tout autre programme du projet. Ils s’appellent fonctions. Une fonction peut appeler une autre fonction.

1. Architecture de projet Un projet se compose de configurations. Une configuration est une plate-forme matérielle comprenant une ou plusieurs ressources. Une ressource représente une machine virtuelle. Une ressource est divisée en plusieurs unités de programmation appelées POU (program organization unit). Les POU d’une ressource sont organisées en une architecture hiérarchisée. Les POU peuvent être décrites avec les langages graphiques ou textuels SFC, FC, ST, IL, FBD, ou LD. Les POU peuvent être des programmes, des fonctions ou des blocs fonctionnels.

Les POU de la section « Blocs fonctionnels » sont des programmes qui peuvent être appelés par tout autre programme du projet. Ils s’appellent blocs fonctionnels. Un bloc fonctionnel de cette section peut appeler d’autres fonctions ou blocs fonctionnels. Les programmes séquentiels principaux doivent être décrits à l’aide des langages SFC ou FC. Les programmes cycliques ne peuvent pas être décrits à l’aide des langages SFC ou FC. Tout programme SFC peut avoir un ou plusieurs SFC fils. Tout programme FC peut « appeler » un ou plusieurs sous-programmes FC. Les fonctions peuvent être décrites à l’aide des langages ST, LD, ou FBD et les blocs fonctionnels peuvent être décrits à l’aide des langages SFC, ST, LD, ou FBD. Les fonctions et les blocs fonctionnels peuvent être appelés depuis des actions ou conditions d’un programme SFC ou FC.

1.1 Programmes

Ｓ

Un programme est une unité logique de programmation qui décrit des opérations entre les variables du procédé. Les programmes décrivent des opérations séquentielles ou cycliques. Les programmes cycliques sont exécutés à chaque cycle de la cible. L’exécution des programmes séquentiels a un comportement dynamique.

Les programmes exécutés au début du cycle (avant les programmes séquentiels) sont typiquement utilisés pour décrire des opérations préliminaires sur les équipements d’entrée, afin de construire des variables de haut niveau. De telles variables sont fréquemment utilisées par les programmes séquentiels. Les programmes exécutés à la fin du cycle (après les programmes séquentiels) sont utilisés typiquement pour décrire des opérations de contrôle sur les variables traitées par les programmes séquentiels, avant d’envoyer les valeurs aux équipements de sortie.

Les programmes sont organisés dans un système hiérarchique arborescent. Les programmes placés au sommet de la hiérarchie sont activés par le système. Les programmes fils (de niveau inférieur dans la hiérarchie – SFC et FC seulement : SFC fils et sous-programmes FC) sont activés par leur programme père. La description d’un programme peut être réalisée à l’aide des langages graphiques ou textuels disponibles : – Sequential Function Chart (SFC ou GRAFCET) ; – Flow Chart (FC) ; – Function Block Diagram (FBD) ; – Ladder Diagram (LD) ; – Structured Text (ST) ; – Instruction List (IL).

1.3 Programmes SFC fils Chaque POU SFC peut contrôler d’autres POU SFC. Ces programmes d’un niveau hiérarchique inférieur s’appellent des programmes SFC fils. Un programme SFC fils est un programme exécuté en parallèle, qui peut être lancé, tué, figé ou relancé par son programme père. Le programme père et le programme fils doivent tous deux être décrits avec le langage SFC. Un programme SFC fils peut avoir des variables locales.

Plusieurs langages ne peuvent pas être mêlés dans le même programme, à l’exception des langages LD et FBD qui peuvent être combinés dans le même diagramme. Les programmes SFC et SFC fils ont des limites de comportements dynamiques qui sont définis au niveau de la ressource. Tandis que les blocs fonctionnels SFC et blocs fonctionnels SFC fils ont chacun leur nombre maximum de jetons qui sont définis dans leurs propriétés individuelles.

Quand un programme père lance un programme SFC fils, il place un jeton SFC (activation) dans chacune des étapes initiales du programme fils. Cette commande peut être décrite avec l’énoncé GSTART ou par le nom du programme fils attaché au qualificatif S. Quand un programme père tue un programme SFC fils, il enlève tous les jetons existant dans les étapes du programme fils. Cette commande peut être décrite avec l’énoncé GKILL ou par le nom du programme fils attaché au qualificatif R. Quand un programme père lance un programme fils, l’exécution du programme père continue.

Sur le GRAFCET, le lecteur est invité à consulter les articles GRAFCET. Concepts de base [S 7 240] et GRAFCET. Structuration des descriptions. Applications [S 7 241].

Quand un programme père fige un programme SFC fils, il enlève tous les jetons existant dans les étapes du programme fils, et mémorise leur position. Cette commande peut être décrite avec l’énoncé GFREEZE. Quand un programme père relance un programme SFC fils figé, il remet en place tous les jetons enlevés lorsque le programme a été figé. Cette commande peut être décrite avec l’énoncé GRST.

1.2 Opérations cycliques et séquentielles La hiérarchie des POU se divise en trois sections ou groupes principaux : – Programmes : les programmes dans cette partie représentent le cycle de la cible ;

Les instances de blocs fonctionnels SFC fils, tels que leurs pères blocs fonctionnels, ont un nombre maximum de jetons, contrairement aux programmes SFC qui ont leurs limites de comportement dynamique définis au niveau de la ressource. La limite de jetons pour un bloc fonctionnel SFC se spécifie dans ses propriétés de paramétrages auxquelles on accède en sélectionnant le bloc, puis à partir du menu Édition, on choisit Propriétés, puis l’onglet Paramétrages.

Nota dans cette section, les programmes SFC et FC, qui représentent des opérations séquentielles, sont regroupés.

– Fonctions :

ensemble de fonctions qui peuvent être appelées par tous les programmes ; – Blocs fonctionnels : ensemble de blocs fonctionnels qui peuvent être appelés par tous les programmes.

Les programmes avant et après les programmes SFC et FC décrivent des opérations cycliques, et ne sont pas dépendants du temps. Ils sont appelés programmes cycliques. Les programmes SFC et FC décrivent des opérations séquentielles, où les opérations élémentaires sont explicitement synchronisées par le temps. Ils sont appelés programmes séquentiels. Les programmes cycliques sont exécutés systématiquement au début de chaque cycle. Les programmes séquentiels principaux (au sommet de la hiérarchie) sont exécutés selon le comportement dynamique SFC et FC.

S 8 030v2 – 2

Lors de l’utilisation d’un bloc fonctionnel SFC avec un SFC fils, on accède, en mode lecture seulement, aux valeurs locales du fils à partir de son père en entrant le nom du fils et le paramètre dans une action ou un code de transition. Par exemple, pour accéder au paramètre Local1 d’un fils SFC nommé FB_Fils, dans l’action ou la transition défini pour le bloc fonctionnel FC père, on entre le code suivant : FB_Child.Local1

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ _________________________________________________________ LANGAGES DE PROGRAMMATION POUR SYSTÈMES AUTOMATISÉS : NORME CEI 61131-3

1.4 Sous-programmes FC

LD :

Tout programme FC peut appeler un ou plusieurs sous-programmes FC. L’exécution du sous-programme FC est réalisée par son programme père. L’exécution du programme FC père est suspendue jusqu’à ce que l’exécution du sous-programme FC soit terminée.

1.6 Blocs fonctionnels

Sous-programme FC

Programme père

utilisation d’une bobine avec le nom du paramètre de retour : FunctionName

Un bloc fonctionnel peut être programmé dans les langages SFC, ST, LD, ou FBD. Les blocs fonctionnels sont initialisés, ce qui signifie que les variables locales d’un bloc fonctionnel sont copiées pour chaque instance. Lorsqu’un programme appelle un bloc, il appelle en fait l’instance du bloc : le même code est appelé mais les données utilisées sont celles qui ont été allouées pour l’instance. Les valeurs des variables de l’instance sont conservées d’un cycle à l’autre.

Sous-programme FC

Exemple d’implémentation d’un bloc fonctionnel (* Programmation ST *) (* FB1 est une instance déclarée du bloc fonctionnel SAMPLE *)

1.5 Fonctions L’exécution d’une fonction est demandée par son programme père. L’exécution du programme père est suspendue jusqu’à ce que la fonction soit terminée.

FB1(high, value, low,1); high_alarm :=FB1.QH ; low_alarm :=FB1.QL ; any_alarm :=FB1.Q ; Programme principal

Chaque programme de chaque section peut appeler une ou plusieurs fonctions. Une fonction peut avoir des variables locales. Les langages ST, LD, FBD ou IL peuvent être utilisés pour décrire une fonction.

Les informations suivantes montrent comment forcer la valeur d’un paramètre de sortie dans le corps d’un bloc fonctionnel, dans les différents langages : ST : assignation du paramètre de sortie en utilisant son nom concaténé avec le nom du bloc fonctionnel FunctionBlockName.OutputParaName:= ;

Attention : le système ne supporte pas la recursivité dans les appels de fonctions. Une erreur surviendra à l’exécution si un programme de la section « Fonctions » est appelé par lui-même ou par l’une des fonctions qu’il appelle. De plus, une fonction ne « stocke » pas la valeur de ses variables locales. Une fonction n’est pas initialisée et ne peut donc pas appeler des blocs fonctionnels. L’interface de la fonction doit être définie explicitement, avec un type et un nom unique pour chacun de ses paramètres d’appel (ou paramètres d’entrée) et son paramètre de retour (ou paramètre de sortie). Afin de respecter les conventions d’écriture du langage ST, le paramètre de retour doit porter le même nom que la fonction. Une fonction a un seul paramètre de retour. Les informations suivantes montrent comment forcer la valeur du paramètre de retour dans le corps d’une fonction, dans les différents langages : ST : assignation du paramètre de retour en utilisant son nom (le même nom que la fonction) : FunctionName:=; IL :

FBD :

Donnée de l’instance

L’interface d’un bloc fonctionnel doit être définie explicitement, avec un type et un nom unique pour chacun de ces paramètres d’appel (ou paramètres d’entrée) et paramètres de retour (ou paramètres de sortie). Un bloc fonctionnel peut avoir plusieurs paramètres de sortie.

Fonction

Fonction

Code

IL :

utilisation de l’opérateur LD et ST : LD FunctionBlockName.OutputParaName ST 20 (* valeur du paramètre = 20 *)

FBD :

forçage du paramètre de retour en utilisant son nom : OutputParaName

LD :

utilisation d’une bobine avec le nom du paramètre de retour : OutputParaName

Attention : en cas de besoin d’une boucle dans un bloc fonctionnel, il faut utiliser une variable locale avant la boucle. Ne fonctionne pas :

la valeur du résultat courant (registre IL) à la fin de la séquence est stockée dans le paramètre de retour : LD 10 ADD 20 (* valeur du paramètre de retour = 30 *)

>= >=1 &

forçage du paramètre de retour en utilisant son nom :

Fonctionne : >=

>=1

>=1

&

IntResult &

FunctionName

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＱ

S 8 030v2 – 3

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ LANGAGES DE PROGRAMMATION POUR SYSTÈMES AUTOMATISÉS : NORME CEI 61131-3 _________________________________________________________

Les blocs fonctionnels SFC, tels leurs blocs SFC fils, ont un nombre maximum de jetons, contrairement aux programmes SFC pour lesquels les limites de comportement dynamique sont définis au niveau de la ressource. Pour spécifier la limite de jetons pour un bloc fonctionnel SFC, dans ses propriétés de paramétrages, on sélectionne le bloc, puis à partir du menu Édition, on choisit Propriétés, puis l’onglet Paramétrages.

2. Objets communs

1.7 Langage de programmation

2.1 Types de données

La description d’un programme peut être réalisée à l’aide des langages graphiques ou textuels suivants :

Toute expression, constante ou variable utilisée dans une POU (écrite dans n’importe quel langage), doit être caractérisée par un type. La cohérence des types doit être respectée dans les opérations graphiques et les instructions textuelles.

Sont présentés ici les fonctionnalités et objets communs de la base de données de programmation. De tels objets peuvent être utilisés dans toute POU (program organization unit : programmes, fonctions ou blocs fonctionnels) écrit en tout langage SFC, FC, FBD, IL, ST, LD.

Les types sont connus par toute ressource d’un projet : les types ont une portée commune. Ces types sont : – types standards CEI 61131 ; – user types (basés sur les types de base).

Sequential Function Chart (SFC) pour des opérations de haut niveau

Ｓ

Flow Chart (FC) pour des opérations de haut niveau

2.1.1 Types standards CEI 61131

Function Block Diagram (FBD) pour des opérations cycliques complexes

Dix-huit types de bases sont disponibles pour les objets de programmation : – BOOL : valeur logique (true ou false) ; – SINT : valeur continue entière courte (8 bits) ; – USINT : valeur continue entière courte non signée (8 bits) ; – BYTE : valeur demi-mot (8 bits) ; – INT : valeur entière continue (16 bits) ; – UINT : valeur entière continue non signée (16 bits) ; – WORD : valeur mot (16 bits) ; – DINT : valeur continue entière double (32 bits) ; – UDINT : valeur continue entière double non signée (32 bits) ; – DWORD : valeur double mot (32 bits) ; – LINT : valeur continue entière longue (64 bits) ; – ULINT : valeur continue entière longue non signée (64 bits) ; – LWORD : valeur mot long (64 bits) ; – REAL : valeur continue réelle (flottante) (32 bits) ; – LREAL : valeur continue réelle longue (flottante) (64 bits) ; – TIME : valeur de temps ou temporisation inférieure à un jour ; ces types de valeurs ne peuvent pas stocker des dates (32 bits) ; – DATE : valeur date (32 bits) ; – STRING : chaîne de caractères ayant une taille définie, qui représente le nombre maximum de caractères que la chaîne peut contenir. Par exemple, pour définir MyString, une chaîne de 10 caractères, on entre MyString (10).

Ladder Diagram (LD) pour des opérations booléennes seulement Structured Text (ST) pour toutes les opérations cycliques Instruction List (IL) pour des opérations de bas niveau

La méthode de distribution IEC 61499 la description d’un programme.

est également disponible pour

Plusieurs langages ne peuvent pas être utilisés ensemble dans le même programme, à l’exception des langages LD et FBD qui peuvent être mêlés dans le même diagramme. Le langage de programmation est sélectionné au moment de la création d’un programme et ne peut pas être changé par la suite.

1.8 Règles d’exécution Le système est synchrone. Toutes les opérations sont échantillonnées. La durée d’un échantillon est appelée le temps de cycle : 1. lecture des variables d’entrées ; 2. consommation des variables liées ; 3. exécution des POU ; 4. production des variables liées ; 5. mise à jour des sorties.

Nota : au sujet des variables de type STRING, voir § 2.3.17.

Il est possible de définir ses propres types basés sur les types de base ci-avant : type utilisateur. De plus, on peut définir des structures en utilisant des types de base et des tableaux ou d’autres types utilisateur. Quand une variable est créée, une dimension peut être donnée pour définir un tableau. L’exemple suivant montre la variable MyVar de type BOOL et qui a une dimension définie comme suit : [1 . . 10]

Attente 1

2

3

4

5

1

2

3

FOR i = 1 TO 10 DO MyVar [i] := FALSE; END_FOR;

Temps de cycle programmé

Dans le cas où des bindings sont définis (le binding est une liaison de données entre les ressources), les variables consommées par cette ressource sont mises à jour après la lecture des entrées, et les variables produites vers d’autres ressources sont envoyées avant la mise à jour des sorties.

2.1.2 Types utilisateurs : tableaux L’utilisateur peut définir des tableaux de types standards CEI 61131 ou de types utilisateur. Un tableau a une ou plusieurs dimensions. Quand un tableau est défini, une variable peut être créée avec ce type et une structure peut avoir un champ de ce type. Les dimensions des tableaux sont des expressions constantes DINT positives et les indices des tableaux sont des expressions constantes DINT ou des variables.

Si un temps de cycle est programmé, la machine virtuelle attend l’écoulement de ce temps avant de commencer l’exécution d’un nouveau cycle. Le temps d’exécution des POU dépend du nombre d’étapes actives dans les programmes SFC, et des instructions comme Jump, IF et Return, etc.

S 8 030v2 – 4

Nota : les tableaux doivent être déclarés dans le dictionnaire avant de les utiliser dans les diagrammes de blocs fonctionnels (FBD).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ _________________________________________________________ LANGAGES DE PROGRAMMATION POUR SYSTÈMES AUTOMATISÉS : NORME CEI 61131-3

2.2.2 Expressions constantes entières courtes

Exemples 1. Tableau unidimensionnel : MyArrayType est un tableau de 10 BOOL. Sa dimension est définie de la manière suivante : [1..10]. MyVar est de type MyArrayType. Ok := MyVar[4];

Une expression constante entière courte représente une valeur entière signée (8 bits) : entre – 128 et + 127. Les expressions constantes entières courtes peuvent être exprimées dans l’une des bases suivantes. Les expressions constantes entières courtes doivent commencer par un préfixe qui identifie la base utilisée :

2. Tableau bi-dimensionnel : MyArrayType2 est un tableau de DINT. Il a deux dimensions définies de la manière suivante : [1..10,1..3] MyVar2 est de type MyArrayType2 MyVar2[1,2] := 100; 3. Tableau d’un tableau : MyVar3 est un tableau de MyArrayType; sa dimension est définie de la manière suivante [1..3] : FOR I := 1 TO 3 DO FOR J := 1 TO 10 DO MyVar3[I][J] := FALSE; END_FOR; END_FOR;

Base

Préfixe

Exemple

décimale

aucun

19

hexadécimale

"16#"

16#A1

octale

"8#"

8#28

binaire

"2#"

2#0101_0101

2.2.3 Expressions constantes entières courtes non signées et demi-mots Une expression constante entière courte non signée, ou demi-mot, représente une valeur entière non signée (8 bits) : entre 0 et 255. Les expressions constantes entières courtes non signées et demi-mots peuvent être exprimés dans l’une des bases suivantes. Les expressions constantes entières courtes non signées et demi-mots doivent commencer par un préfixe qui identifie la base utilisée :

2.1.3 Types utilisateur : structures Les utilisateurs peuvent définir les structures en utilisant les types standards CEI 61131 ou les types utilisateur. Une structure est composée de sous-entrées appelées champ. Quand une structure est définie, une variable peut être créée avec ce type. Exemples MyStruct1 est composée de : Field1 qui est de type BOOL Field2 qui est de type DINT MyStruct2 est composée de : Field1 qui est de type DINT Field2 qui est de type BOOL Field3 qui est un tableau de 10 DINT Field4 qui est de type MyStruct1

Base

Préfixe

Exemple

décimale

aucun

19

hexadécimale

"16#"

16#A1

octale

"8#"

8#28

binaire

"2#"

2#0101_0101

2.2.4 Expressions constantes entières Une expression constante entière représente une valeur entière signée (16 bits) : entre – 32 768 et 32 767. Les expressions constantes entières peuvent être exprimées dans l’une des bases suivantes. Les expressions constantes entières doivent commencer par un préfixe qui identifie la base utilisée :

MyVar de type MyStruct2 peut être utilisé comme suit : Value1 := MyVar.Field1; (* Value1 est de type DINT *) Ok1 := MyVar.Field2; (* Ok1 est de type BOOL *) Tab[2] := MyVar.Field3[5]; (* Tab est un tableau de DINT *) Value2 := MyVar.Field3[8]; (* Value2 est de type DINT *) Ok2 := MyVar.Field4.Field1; (* Ok2 est de type BOOL *)

2.2 Expressions constantes

Base

Préfixe

Exemple

décimale

aucun

– 260

hexadécimale

"16#"

16#FEFC

octale

"8#"

8#177374

binaire

"2#"

2#0101_0101_0101_0101

2.2.5 Expressions constantes entières non signées et mot

Une expression constante est toujours relative à un type. La même notation ne peut pas être utilisée pour représenter des expressions constantes de type différent.

Une expression constante entière non signée ou mot représente une valeur entière non signée (16 bits) : entre 0 et 65 535.

Le caractère souligné (’_’) peut être utilisé pour séparer des groupes de chiffres. Il n’a aucune signification sémantique, mais augmente la lisibilité des expressions constantes.

Les expressions constantes entières non signées et mot peuvent être exprimées dans l’une des bases suivantes. Les expressions constantes entières non signées et mot doivent commencer par un préfixe qui identifie la base utilisée :

2.2.1 Expressions constantes booléennes Il existe seulement deux expressions constantes booléennes : – TRUE est équivalent à la valeur entière 1 ; – FALSE est équivalent à la valeur entière 0. Les minuscules et les majuscules ne sont pas différenciées pour l’écriture des mots clefs true et false.

Base

Préfixe

Exemple

décimale

aucun

+ 33 000

hexadécimale

"16#"

16#80E8

octale

"8#"

8#100350

binaire

"2#"

2#0101_0101_0101_0101

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＳ

S 8 030v2 – 5

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＰ LANGAGES DE PROGRAMMATION POUR SYSTÈMES AUTOMATISÉS : NORME CEI 61131-3 _________________________________________________________

2.2.6 Expressions constantes entières doubles

octale

"8#"

8#1756402

Une expression constante entière double représente une valeur entière signée (32 bits) : entre – 2 147 483 648 et + 2 147 483 647.

binaire

"2#"

2#1101_0001_0101_1101 _0001_0010_1011_1001_1101_ 0001_0101_1101_0001_0010_ 1011_1001

Les expressions constantes entières doubles peuvent être exprimées dans une des bases suivantes. Les expressions constantes entières doubles doivent commencer par un préfixe qui identifie la base utilisée :

Ｓ

Base

Préfixe

Exemple

décimale

aucun

> – 908 16#1A2B3C4D

hexadécimale

"16#"

octale

"8#"

8#1756402

binaire

"2#"

2#1101_0001_0101 _1101_0001_0010_1011_1001

2.2.10 Expressions constantes réelles Les expressions constantes réelles peuvent utiliser une représentation décimale ou scientifique. Le point décimal (’.’) sépare la partie entière de la partie décimale. Il doit obligatoirement être présent car il permet la différenciation des expressions constantes entières et réelles. La représentation scientifique utilise la lettre ’E’ pour séparer la mantisse de l’exposant. L’exposant d’une expression constante scientifique est un entier signé compris entre – 37 et + 37. Exemples 3.14159 – 1.0E + 12 + 1.0 1.0E – 15 – 789.56 + 1.0E – 37 L’expression "123" ne représente pas une expression constante réelle. Sa notation correcte est "123.0" .

2.2.7 Expressions constantes entières doubles non signées et mots doubles Une expression entière double non signée, ou mot double, représente une valeur entière double non signée (32 bits) : entre 0 et 4 294 967 295. Les expressions entières doubles non signées et mots doubles peuvent être exprimés dans une des bases suivantes. Les expressions entières doubles non signées et mots doubles doivent commencer par un préfixe qui identifie la base utilisée : Base

Préfixe

2.2.11 Expressions constantes longues réelles Les expressions constantes longues réelles peuvent utiliser une représentation décimale ou scientifique. Le point décimal (’.’) sépare la partie entière de la partie décimale. Il doit obligatoirement être présent car il permet la différenciation des expressions constantes entières et réelles. La représentation scientifique utilise la lettre ’E’ pour séparer la mantisse de l’exposant. L’exposant d’une expression constante scientifique est un entier signé compris entre 1.7E – 308 et 1.7E + 308. Une variable réelle longue a 5 chiffres significatifs.

Exemple

décimale

aucun

+ 908

hexadécimale

"16#"

16#1A2B3C4D

octale

"8#"

8#1756402

binaire

"2#"

2#1101_0001_0101_1101 _0001_0010_1011_1001

2.2.8 Expressions constantes entières longues

2.2.12 Expressions constantes temporelles

Une expression constante entière longue représente une valeur entière longue signée (64 bits) : entre – 9 223 372 036 854 775 808 et 9 223 372 036 854 775 807.

Les expressions constantes temporelles représentent des valeurs de temps comprises entre 0 seconde et 1 193 h 2 m 47 s 294 ms. La plus petite unité autorisée est la milliseconde. Voici les unités standards de temps utilisées dans les expressions constantes temporelles : – heure : la lettre "h" doit suivre le nombre d’heures ; – minute : la lettre "m" doit suivre le nombre de minutes ; – seconde : la lettre "s" doit suivre le nombre de secondes ; – milliseconde : les lettres "ms" doivent suivre le nombre de millisecondes.

Les expressions constantes entières longues signées peuvent être exprimées dans une des bases suivantes. Les expressions constantes entières longues signées doivent commencer par un préfixe qui identifie la base utilisée : Base

Préfixe

Exemple

décimale

aucun

– 908 16#1A2B3C4D

hexadécimale

"16#"

octale

"8#"

8#1756402

binaire

"2#"

2#1101_0001_0101_1101_ 0001_0010_1011_1001_1101_ 0001_0101_1101_0001_0010_ 1011_1001

L’expression constante temporelle doit commencer par le préfixe "T#" ou "TIME#". Les préfixes et les lettres d’unité peuvent être écrits en minuscules ou en majuscules. Certaines unités peuvent ne pas apparaître.

2.2.9 Expressions constantes entières longues non signées et mots longs

Exemples T#1H450MS 1 heure, 450 millisecondes

Une expression constante entière longue non signée, ou mot long, représente une valeur entière longue non signée (64 bits) : entre 0 et 18 446 744 073 709 551 615.

time#1H3M 1 heure, 3 minutes L’expression "0" ne représente pas une valeur temporelle, mais une expression constante entière.

Les expressions constantes entières longues non signées et mots longs peuvent être exprimés dans une des bases suivantes. Les expressions constantes entières longues non signées et mots longs doivent commencer par un préfixe qui identifie la base utilisée : Base

Préfixe

Les expressions constantes date représentent les valeurs date de format année-mois-jour, séparées par des traits d’union. Les expressions constantes date possible sont entre 1970-01-01 et 2038-01-18 GMT.

Exemple

décimale

aucun

+ 908

hexadécimale

"16#"

16#1A2B3C4D

S 8 030v2 – 6

2.2.13 Expressions constantes date

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＱ

Norme CEI 61499 : programmation distribuée et événementielle des procédés par

Nicolas JOUVRAY ICS Triplex France, ISaGRAF

S 8 031 - 2

1.

Format principal de programme CEI 61499......................................

2.

Format de bloc fonctionnel CEI 61499 de base ..............................

—

2

3.

Format de bloc fonctionnel CEI 61499 composite .........................

—

3

4.

Format principal de bloc fonctionnel CEI 61499 ............................

—

3

5.

Implémentation du qualificatif WITH .................................................

—

4

6.

Temps d’exécution de cycle des programmes CEI 61499 ............

—

4

Pour en savoir plus ...........................................................................................

Doc. S 8 031

es langages de programmation des systèmes automatisés sont décrits dans deux normes complémentaires : – la norme CEI 61131-3 fait l’objet de l’article [S 8 030v2] ; – la norme CEI 61499 est décrite dans l’article présent. La norme CEI 61499 est une méthode permettant la distribution de blocs fonctionnels CEI 61499 individuels définis pour un programme CEI 61499 répartis sur de multiples ressources. Les blocs fonctionnels standards CEI 61499 sont disponibles avec la bibliothèque CEI 61499. Dans un projet CEI 61499, on peut créer des programmes dans lesquels on insère des blocs fonctionnels de base CEI 61499 et des blocs fonctionnels composites CEI 61499. L’implémentation de CEI 61499 dans ISaGRAF est basée sur les normes CEI 61499-1 et CEI 61499-2.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｪｵｩｮ＠ＲＰＰＸ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＶＵ

S 8 031 – 1

Ｓ

Ｓ

ＶＶ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＲ

Réalisation technologique du GRAFCET par

Daniel DUPONT Docteur en automatique Enseignant chercheur à l’École supérieure des techniques industrielles et des textiles (ESTIT)

et

David DUBOIS

Ｓ

Docteur en automatique et informatique industrielle Chargé de cours à l’ESTIT

S 8 032 – 2 — 2 — 3 — 5 — 6 — 9

1. 1.1 1.2 1.3 1.4 1.5

Vers la réalisation technologique........................................................ Du GRAFCET fonctionnel au GRAFCET technologique............................ Cas particuliers ............................................................................................ Exemple d’application................................................................................. Dialogue entre GRAFCET ............................................................................ Conclusion....................................................................................................

2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Équation logique d’une étape............................................................... Rappel des règles d’évolution .................................................................... Équation logique d’une étape..................................................................... Choix de séquences..................................................................................... Séquences parallèles................................................................................... Cas particulier : GRAFCET ou boucle à deux étapes ................................ Gestion des actions ..................................................................................... Prise en compte des modes de marche/arrêt............................................

— — — — — — — —

10 10 11 12 12 13 14 15

3. 3.1 3.2 3.3 3.4

Technologies de réalisation .................................................................. Logique câblée............................................................................................. Automates programmables industriels (API)............................................ Système informatique................................................................................. Conclusion....................................................................................................

— — — — —

17 17 20 22 24

Pour en savoir plus...........................................................................................

Doc. S 8 032

fin de réaliser l’implantation technologique du GRAFCET sur différents supports (câblés ou programmés), une conception en trois temps est préconisée : — l’analyse fonctionnelle qui débouche sur l’élaboration d’un GRAFCET indépendant de la réalisation technologique ; — la transcription du GRAFCET en équations logiques utilisables lors de la réalisation technologique ; — l’implantation des équations logiques sur le support de réalisation câblé ou programmé. Cette démarche met en évidence les difficultés de conception fonctionnelle pour des applications complexes et propose une solution par l’intermédiaire d’une décomposition en modules moins complexes et de dialogues entre les GRAFCET les décrivant. La partie fonctionnelle ne prenant en compte que le mode de fonctionnement normal, la notion des modes de marche/arrêt est intégrée dans l’élaboration des équations logiques et de ce fait intervient dans la réalisation technologique.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｭ｡ｲｳ＠ＲＰＰＲ

A

Cet article vient en complément des articles sur le GRAFCET, notamment Outil de description des automatismes séquentiels : le GRAFCET [R 7 250].

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＶＷ

S 8 032 − 1

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＲ

RÉALISATION TECHNOLOGIQUE DU GRAFCET ________________________________________________________________________________________________

1. Vers la réalisation technologique

Supposons maintenant que la montée-descente de la presse soit commandée par un vérin simple effet (figure 3). L’arrivée d’air en A+ provoque la sortie du vérin et comprime le ressort. Le ressort en l’absence d’air en A+ provoque la rentrée du vérin et donc la montée de la presse. La figure 3b fournit le GRAFCET technologique. L’étape 2 du GRACET de la figure 3b ne possède aucune action associée car le ressort joue son rôle de rappel et la partie commande n’a aucune action à envoyer vers la partie opérative. Ce GRAFCET, possédant deux étapes (2 et 0) qui se suivent sans action associée, peut se transformer (comme bien souvent) en supprimant l’étape 2 (figure 3c). Dans ce cas, il ne faut pas oublier d’ajouter la condition h (qui peut être considérée comme la condition initiale) dans la réceptivité associée à la transition qui suit l’étape 0 ; sinon, l’opérateur peut réappuyer sur le bouton de marche (m) pendant le retour du vérin (donc étape 0 active), ce qui fait ressortir le vérin bien que la rentrée ne soit pas terminée.

1.1 Du GRAFCET fonctionnel au GRAFCET technologique

Ｓ

Le GRAFCET (graphe de commande étapes-transitions) est un outil graphique de représentation du cahier des charges d’un automatisme séquentiel. Il est à la fois simple à utiliser et rigoureux sur le plan formel. Il est basé sur les notions d’étapes auxquelles sont associées des actions et de transitions auxquelles sont associées des réceptivités. Il décrit les ordres émis par la partie commande vers la partie opérative en mettant en évidence les actions engendrées et les événements qui les déclenchent. Cette représentation est étroitement liée à la notion d’évolution du processus.

Ce dernier exemple est cependant particulier car bien souvent, le GRAFCET de niveau 2 possède plus d’étapes que le GRAFCET de niveau 1. En effet, les spécifications technologiques et opérationnelles amènent des contraintes supplémentaires. Toutefois, il montre que le GRAFCET de niveau 2 peut être différent du GRAFCET de niveau 1.

0

Pour parvenir à la réalisation de la partie commande, il est conseillé de diviser le cahier des charges en deux niveaux successifs et complémentaires.

m

Le premier niveau décrit le comportement de la partie commande en fonction de l’évolution de la partie opérative : c’est le rôle des spécifications fonctionnelles décrivant ce que doit faire l’automatisme. À ce niveau, les contraintes technologiques (des actionneurs, des capteurs…) n’interviennent pas, seules comptent les fonctionnalités.

1 Presse

Le second niveau renseigne sur la nature technologique des actionneurs et des capteurs ; on y trouve donc leurs caractéristiques et les contraintes qui y sont associées. C’est aussi à ce niveau que les spécifications opérationnelles décrivant les conditions d’utilisation de l’application apparaissent.

b Descente 2

L’automaticien, confronté à un problème de conception et de réalisation d’un automatisme, aborde donc l’étude en deux phases successives correspondant aux deux niveaux de spécification : — un niveau fonctionnel ; — un niveau technologique.

M

h

a

Cette approche en deux niveaux se retrouve dans la conception du GRAFCET : — un premier GRAFCET dit fonctionnel ou de niveau 1, qui ne prend en compte que la partie fonctionnelle des spécifications et qui fait donc abstraction de toute réalisation technologique. Ainsi, s’il est bien conçu, il est valable pour tout type de réalisation ; — un deuxième GRAFCET dit technologique ou de niveau 2, qui, en s’appuyant sur le GRAFCET de niveau 1, intègre les contraintes technologiques et opérationnelles.

principe

b

GRAFCET fonctionnel

Figure 1 – Commande d’une presse

0

m A+

Exemples : Une application simplifiée, la commande d’une presse (figure 1), permet d’illustrer cette approche. Sur ordre (m) de l’opérateur, la presse descend (D), puis une fois arrivée en bas (b), elle remonte (M) jusqu’à la position haute (h). Le GRAFCET fonctionnel de cette application est fourni par la figure 1b. Il est dit GRAFCET de niveau 1 car il ne fait intervenir que l’aspect fonctionnel sans tenir compte d’aucune contrainte technologique (la technologie utilisée pour les actionneurs et les capteurs n’est pas utile à ce niveau). Supposons maintenant que la technologie utilisée soit une technologie pneumatique et que la montée-descente de la presse soit commandée par un vérin double effet (figure 2). L’arrivée d’air en A+ (resp. en A–) provoque la sortie du vérin et donc la descente de la presse (resp. la rentrée du vérin et donc la montée de la presse). Le GRAFCET technologique de cette application est la figure 2b.

S 8 032 − 2

D

Montée

1

A+

b A– 2

A–

h

a

principe

b

GRAFCET technologique

Figure 2 – Commande d’un vérin double effet

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＶＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＲ

_______________________________________________________________________________________________

RÉALISATION TECHNOLOGIQUE DU GRAFCET

1.2 Cas particuliers

A+

Il est bien souvent intéressant, sinon indispensable, de modifier le GRAFCET de niveau 1 afin d’être sûr d’avoir un GRAFCET réellement indépendant de la technologie et donc de ne pas influencer les choix technologiques (si la partie opérative n’est pas déjà réalisée) et aussi d’être sûr d’avoir un GRAFCET qui répondra à la technologie (si la partie opérative est déjà réalisée).

Ressort

1.2.1 Gestion des fronts a

principe

Dans certains GRAFCET, apparaissent au niveau des réceptivités des informations qui font intervenir l’apparition ou la disparition d’événements plutôt que de tester la présence ou l’absence d’une information. C’est le cas lorsque l’information est déjà présente avant que l’action soit commandée.

0

Exemple : commande d’un moteur (figure 4) Lorsque l’opérateur demande la rotation, l’information d (capteur de position) est déjà vraie. De fait, si la rotation ne doit faire qu’un tour, on ne peut pas tester d comme fin d’action ; il faut tester l’apparition de l’information d. Cela est fait en testant ce qu’on appelle un front montant sur d. La figure 4b présente le GRAFCET fonctionnel. La flèche montante devant l’information d affirme que c’est le passage du niveau 0 (faux) au niveau 1 (vrai) qui permet de franchir la transition entre l’étape 1 et l’étape 0 : on parle de front montant. D’un point de vue technologique, il n’est pas possible de tester directement les fronts. Il est nécessaire de les décomposer en deux étapes : — pour un front montant (apparition d’information), on teste d’abord le niveau bas puis le niveau haut ; — pour un front descendant (disparition d’information), on teste d’abord le niveau haut puis le niveau bas. L’ analyse du GRAFCET de niveau 2 conduit au GRAFCET de la figure 4c. L’étape 1 est doublée afin de pouvoir tester en premier lieu l’absence de l’information d (réceptivité de la transition entre l’étape 1 et 2), puis la présence de l’information d (réceptivité entre l’étape 2 et 0), ce qui revient à tester l’apparition de l’information d.

m

1

A+

0

m.h

b

1

2

b

h

b

A+

c

GRAFCET technologique

GRAFCET simplifié

Figure 3 – Commande d’un vérin simple effet

Rotation

Nota : dans un tel cas, il ne faut pas oublier de répéter les actions dans l’étape qui est « doublée ».

d

a

1.2.2 Exclusivité au niveau des divergences Certains GRAFCET de niveau 1 présentent des choix de séquences sans gérer l’exclusivité de ces choix (figure 5) Or, le GRAFCET autorise l’activation de plusieurs branches.

0

principe

m

0

1

R 1

1

R

2

↑d

b

R

d

m

a

R

2

d

GRAFCET fonctionnel

c

c

D

b

GRAFCET de gestion de front

Figure 4 – Commande d’un moteur

3

M

h

Figure 5 – Début de divergence

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＶＹ

S 8 032 − 3

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＲ

RÉALISATION TECHNOLOGIQUE DU GRAFCET ________________________________________________________________________________________________

G

md

D

simultanément franchies, donc les étapes 2 et 3 sont activées simultanément et les actions associées aux étapes 2 et 3 (D et M) sont envoyées simultanément à la partie opérative.

mg

g

Exemple : soit un chariot (figure 6) pouvant se déplacer entre deux positions (droite et gauche). Si au départ l’opérateur demande le déplacement à droite (md), le chariot se déplace à droite (D) jusqu’à la position droite (d) et s’il demande le déplacement à gauche (mg), le chariot se déplace à gauche (G) jusqu’à la position gauche (g). Si au départ (figure 6b) l’opérateur appuie simultanément sur md et mg, alors les étapes 2 et 3 sont activées simultanément (règle 4 d’évolution du GRAFCET, § 2.1). De fait, les actions D et G sont vraies simultanément et on demande au chariot de se déplacer vers la droite et vers la gauche simultanément, ce qui évidemment n’est pas une solution viable pour la partie opérative (risque de détérioration de l’actionneur). Il faut donc interdire, dans le GRAFCET, le fait que les étapes 2 et 3 puissent être activées simultanément (figure 6c). Le fait de mettre md ⋅ g (resp. mg ⋅ d ) comme réceptivité entre les étapes 1 et 2 (resp. 1 et 3) interdit l’activation de l’étape 2 (resp. étape 3) et donc la demande de déplacement à droite (resp. à gauche) si le chariot n’est pas à gauche (resp. à droite). Comme le chariot ne peut pas être physiquement à droite et à gauche simultanément, il y a exclusivité dans le choix de séquence. Pour certaines applications, il ne peut pas y avoir de choix exclusif basé sur les propriétés physiques de la partie opérative ; dans ce cas, il est possible de donner une priorité à une séquence (figure 6d). Ici, le fait de mettre md ⋅ mg entre l’étape 1 et 2 fait que, si l’opérateur appuie simultanément sur md et mg, alors cette réceptivité est fausse et donc uniquement l’étape 3 sera activée. La priorité est donc donnée à la séquence de droite.

d a

principe

1

Ｓ

mg

md

2

D

3

d

b

G

g

activation simultanée possible

1

md . g

2

1.2.3 Gestion des simultanéités en fin de convergence

mg . d

D

3

d

Soit la partie de GRAFCET de la figure 7a. Lorsque les étapes 10 et 20 sont actives simultanément, alors les actions associées (A et B) sont vraies simultanément. La désactivation des étapes ne se fera que lorsque les informations a (fin de l’action A) et b (fin de l’action B) seront vraies simultanément.

G

g

Que se passe-t-il si l’une des actions se termine avant l’autre (par exemple, l’action A) ? c

interdiction d'activation simultanée

Compte tenu du GRAFCET, la partie commande continue à envoyer cette action à la partie opérative, ce qui peut être dommageable (actionneur en butée). Il est donc nécessaire de trouver une parade à ce problème. Le fait d’associer des actions conditionnelles aux étapes 10 et 20 le règle (figure 7b) car effectivement l’action A (resp. B) s’arrête quand l’information a fin de l’action A (resp. b fin de l’action B) est vraie.

1

md . mg

2

D

d

d

Toutefois, un autre problème persiste : même si d’un point de vue fonctionnel, cette solution est tout à fait correcte, elle implique des contraintes au niveau de la réalisation technologique des capteurs (a et b) de fin d’action.

mg

3

G

En effet, supposons que l’action A corresponde par exemple à un déplacement de chariot. Lorsque ce déplacement entraîne le chariot en position a, le capteur passe à 1 et la partie commande stoppe l’envoi du déplacement. Toutefois, par inertie, le chariot ne s’arrête pas immédiatement et risque de dépasser la zone de détection du capteur a. De fait, a repasse à 0 et l’action A est de nouveau vraie car l’étape 10 est toujours active. Donc le chariot repart en s’éloignant de la position a et la réceptivité a ⋅ b ne pourra plus être vraie. De fait, les étapes 10 et 20 resteront toujours actives, entraînant les actions A et B (d’où risque de butée, de casse, etc.). Il faut utiliser ici des capteurs à contacts maintenus.

g

priorité au déplacement à gauche

Figure 6 – Commande du déplacement latéral d’un chariot

Lorsque l’étape 1 est active et si les réceptivités a et c sont vraies simultanément, alors la transition entre les étapes 1 et 2 et la transition entre les étapes 1 et 3 sont simultanément franchissables. La règle 4 d’évolution du GRAFCET (§ 2.1) nous dit alors qu’elles sont

S 8 032 − 4

La solution (figure 7c) consiste à ajouter des étapes de synchronisation en fin de séquences simultanées qui garantissent un GRAFCET de niveau 1 correct sans implication sur une quelconque réalisation technologique au niveau des capteurs a et b.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＲ

_______________________________________________________________________________________________

RÉALISATION TECHNOLOGIQUE DU GRAFCET

Quand les deux séquences sont terminées (étapes 11 et 21 actives simultanément), alors l’étape 2 est activée et les étapes de synchronisation 11 et 21 sont désactivées. 10

A

20

Au niveau de la transition avant l’étape 2, il faut mettre une réceptivité toujours vraie (1) et non a ⋅ b , sinon on retombe dans le même travers que précédemment.

B

1.3 Exemple d’application

a.b

L’exemple de la figure 8 permet de faire quelques remarques sur la réalisation de GRAFCET fonctionnels minimisant l’implication sur les GRAFCET technologiques correspondants. Lorsque l’opérateur appuie sur le départ cycle (m), les chariots partent pour un allerretour.

2

a

a

10

■ Solution 1

b

A

20

Si l’étape 0 est active et si m est vraie, chaque chariot part pour un aller-retour (figure 9a). Le premier qui termine son trajet (par exemple, le chariot 1) réactive l’étape initiale 0. Supposons que le chariot 2 se trouve dans l’étape 22 (en phase de retour) et que l’opérateur appuie sur le départ cycle. De fait, la transition suivant l’étape 0 est franchie, ce qui entraîne l’activation des étapes 11 et 21. Comme l’étape 22 est active, les actions D2 et G2 sont envoyées simultanément à la partie opérative, d’où dysfonctionnement et risque de casse.

B

a.b

■ Solution 2

2

Cette fois-ci (figure 9b), l’ordre de départ cycle n’est effectif que si les chariots se trouvent dans les conditions initiales, ce qui interdit le problème précédent. Toutefois, on retombe sur le problème rencontré précédemment (§ 1.2.3) : en effet, les contacts g1 et g2 doivent être maintenus et donc ce GRAFCET impose une contrainte technologique à la réalisation.

b

10

A

20

a

Il faut remarquer que même si ces deux GRAFCET (figure 9) sont corrects d’un point de vue syntaxique, généralement les séquences simultanées se terminent avec des étapes de synchronisation (fins de séquences simultanées, § 1.2.3).

B

■ Solution 3

b

11

L’introduction des étapes de synchronisation 13 et 23 (figure 10a) permet de supprimer le test des conditions initiales au niveau de la réceptivité associée à la transition suivant l’étape 0.

21

■ Solution 4 L’introduction de deux étapes initiales (figure 10b) permet de supprimer les étapes de synchronisation (13 et 23). En effet, les étapes 10 et 20 jouent aussi le rôle d’étapes de synchronisation.

1

Cette solution possède une qualité supplémentaire qui permet de séparer facilement ce GRAFCET en deux GRAFCET indépendants (figure 10c). La synchronisation des deux GRAFCET est réalisée en testant l’activité de l’étape initiale de l’autre GRAFCET (variables X10 et X20).

2

c Figure 7 – Fin de divergence

G1

Lorsque l’étape 10 est active, l’action A est vraie jusqu’au moment où l’information a est vraie. Dans ce cas, la transition entre l’étape 10 et 11 est franchie, l’étape 11 est activée et l’étape 10 désactivée. L’action A est stoppée. L’étape 11 permet à la séquence de gauche d’attendre que la séquence de droite se termine (étape 21). Si la séquence de droite se termine en premier, l’étape 21 est activée et permet d’attendre la fin de la séquence de gauche (étape 11 active).

m

D1

G2

C1

g1

D2

C2

d1

g2

d2

Figure 8 – Aller-retour de deux chariots

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＱ

S 8 032 − 5

Ｓ

Ｓ

ＷＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

Microcontrôleurs : principes et aspects temps réel par

Roger D. HERSCH Professeur à l’École Polytechnique Fédérale de Lausanne Département d’informatique

1. 1.1 1.2 1.3 1.4 1.5 1.6

Microprocesseurs et microcontrôleurs ............................................. Système informatique minimal.................................................................. Exécution de programme ........................................................................... Catégories d’instructions ............................................................................ Le concept de pile........................................................................................ Adressage d’opérandes .............................................................................. Exemple de microcontrôleur : le 68331 .....................................................

2. 2.1 2.2 2.3 2.4 2.5

Entrées-sorties .......................................................................................... Signaux d’interface du processeur 68000 ................................................. Décodage d’un espace d’entrée-sortie ...................................................... Décodage d’une position ............................................................................ Ports d’entrée-sortie sur microcontrôleurs................................................ Synthèse de signaux de sélection sur microcontrôleurs .........................

— — — — — —

11 11 12 13 14 15

3. 3.1 3.2 3.3

Interruptions.............................................................................................. Principes ....................................................................................................... Mécanismes d’interruption......................................................................... Interruptions sur microcontrôleur 68331...................................................

— — — —

16 16 17 18

4. 4.1 4.2 4.3 4.4 4.5 4.6

Gestion du temps et des événements................................................ Principes ....................................................................................................... Lecture du compteur libre........................................................................... Capture d’événements en entrée ............................................................... Synthèse de signaux de sortie ................................................................... Décompte d’événements extérieurs .......................................................... Synthèse de signaux à largeur d’impulsion variable (pulse width modulation)............................................................................

— — — — — —

18 18 19 20 22 23

—

23

5.

Conclusions ...............................................................................................

—

23

Référence bibliographiques ...........................................................................

—

27

S 8 035 - 2 — 2 — 3 — 6 — 9 — 10 — 11

es microcontrôleurs sont et continueront à être largement utilisés pour les applications de régulation et de commande de processus. Ce sont de véritables micro-ordinateurs intégrés sur une puce de silicium qui comportent une unité centrale, de la mémoire ou une interface à de la mémoire externe, des ports d’entrée-sortie, une interface pour lignes série (RS-232) ainsi qu’une unité de gestion de temps et d’événements. Les signaux d’entrée-sortie du microcontrôleur peuvent être facilement interfacés à des coupleurs optiques afin d’interfacer des capteurs et des actuateurs industriels. Pratiquement tous les fabricants de microprocesseurs (Motorola, Intel, Hitachi, Texas Instrument, Toshiba, ST Microélectronique-ex SGS-Thomson, etc.) proposent une ou plusieurs gammes de microcontrôleurs. Les microcontrôleurs 4 bits servent essentiellement à des tâches simples. De tels microcontrôleurs sont par

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠､￩｣･ｭ｢ｲ･＠ＲＰＰＱ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＳ

S 8 035 − 1

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

M ICROCON TRÔLEURS : PRIN CIPES ET ASPECTS TEM PS RÉEL ___________________________________________________________________________________

exemple utilisés au sein d’objets ménagers grand public, tels que des cuisinières, machines à laver ou aspirateurs. Les microcontrôleurs 8 bits sont capables de répondre à des exigences plus élevées et sont utilisés pour la commande de dispositifs informa-tiques tels que des joysticks, tablettes graphiques et modems. Ils sont également utilisés pour la programmation de petits robots ainsi que pour l’acquisition de données (convertisseurs A/D, etc.). Les microcontrôleurs 16/32 bits sont utilisés pour la commande de machines ou le contrôle de processus, lorsque les contraintes temps réel sont sévères ou lorsque les algorithmes de régulation nécessitent une puissance de calcul importante. Des variantes de microcontrôleurs avec canaux d’accès mémoire direct offrant un grand débit entre mémoire et entrées-sorties sont utilisés dans les applications multimédia et pour le contrôle d’imprimantes laser.

Ｓ

1. Microprocesseurs et microcontrôleurs

La mémoire est utilisée pour le stockage d’instructions, de données ainsi que pour la pile(2). La mémoire est constituée de cellules de mémorisation binaires, groupées en mot de 8, 16, 32 ou 64 bits. La mémoire est adressée par mots de 8 bits, c’est-à-dire par octets (bytes). Une position mémoire est spécifiée par l’adresse d’un octet.

Dans ce paragraphe, nous expliquons d’abord le fonctionnement de base d’un système microprocesseur, puis présentons comme exemple l’architecture du microcontrôleur Motorola 68331.

Nota : (2) la pile est une portion mémoire réservée pour sauver le contexte d’exécution d’une procédure (voir § 1.4).

Les entrées-sorties permettent au processeur d’accéder au monde extérieur par l’intermédiaire de cycles de lecture ou d’écriture sur des interfaces d’entrée-sortie (interface clavier, interface écran, interface disque, interface ligne série, etc.). Une interface en sortie est généralement formée d’un registre se trouvant à une certaine position de l’espace d’adressage du processeur. Une interface en entrée comprend une porte 3 états, accessible par un cycle de lecture à une certaine position de l’espace d’adressage du processeur. Le bus système comporte les lignes permettant de relier entre eux le processeur, la mémoire et les entrées-sorties. Il comprend les lignes d’adresses provenant du processeur, les lignes de données bidirectionnelles et les lignes de contrôle. Le cœur d’un système informatique est formé par l’interaction entre le processeur et sa mémoire (figure 2). Le compteur ordinal contient l’adresse de la position mémoire de l’instruction à exécuter. Cette adresse est placée sur les lignes d’adresses ; la position mémoire correspondante, qui contient le code de l’instruction, est sélectionnée, lue, placée sur les lignes de données et mémorisée dans le registre d’instruction du processeur (figure 3). Le processeur décode le code de l’instruction. En fonction de la valeur de ce code, il effectue des cycles d’accès mémoire supplémentaires pour chercher les opérandes, effectuer l’opération désirée et stocker le résultat à la position mémoire ou dans le registre spécifié par le code de l’instruction.

1.1 Système informatique minimal D’un point de vue matériel, un système informatique minimal est constitué d’un processeur, d’une mémoire et d’entrées-sorties (figure 1). Le processeur (figure 3) a pour mission de rechercher les instructions qui sont en mémoire, de les décoder et de les exécuter. À cette fin, il contient un compteur ordinal pointant à l’adresse mémoire où se trouve la prochaine instruction à rechercher et à exécuter. Il contient également un registre d’instruction qui permet de stocker le code de l’instruction (code opératoire) recherchée en mémoire. Après chaque recherche d’instruction, le compteur ordinal est incrémenté afin de pointer à la prochaine instruction(1). Les registres de données permettent de stocker les opérandes nécessaires aux instructions de calcul ainsi que les résultats lors d’opérations logiques et arithmétiques. Les registres d’adresses permettent de stocker les adresses d’opérandes qui se trouvent en mémoire. Une unité arithmétique et logique permet d’effectuer les opérations arithmétiques et logiques les plus courantes. Nota : (1) plus précisément, après chaque recherche d’octet ou de mot mémoire faisant partie d’une instruction, le compteur ordinal est incrémenté afin de pointer sur la suite de la même instruction ou sur l’instruction suivante.

Interfaces d'entrée-sortie (I/O)

Processeur

Mémoire

Interface disque

Interface ligne série RS232C

Interface entréessorties

Interfaces pour la commande de dispositifs mécaniques

Bus système (adresses, données, lignes de contrôle)

Figure 1 – Architecture d’un système informatique minimal

S 8 035 − 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

__________________________________________________________________________________

M ICROCON TRÔLEURS : PRIN CIPES ET ASPECTS TEM PS RÉEL

(0)

Tableau 1 – Signification d’instructions de transfert et de saut

Lignes d’adresses Mémoire

Processeur

Zone programme Zone données

Signaux de contrôle

Compteur ordinal

Instruction en assembleur

Signification

MOVE.B #QUANTITE, D0

Chargement de QUANTITE dans le registre D0, QUANTITE est une valeur immédiate 8 bits qui se trouve dans l’instruction

MOVE.B D0, PERIPH

Transfert du contenu du registre D0 (8 bits) vers l’adresse d’entrée-sortie PERIPH

BRA ETIQUETTE

Saut relatif à l’instruction se trouvant à l’adresse spécifiée par ETIQUETTE (adresse symbolique représentant une adresse absolue)

Registre d’instructions

Pile

Lignes de données bidirectionnelles

Vers les interfaces d’entrée-sortie

Figure 2 – Architecture von Neumann (mémoire banalisée)

Lignes d’adresses Lignes de contrôle

Adresse valide Données transférées (acquittement) Lecture/écriture

32 bits

PC Compteur ordinal

32 bits

D0 Registre de données

16 bits

Lignes de données

Étudions un petit programme qui engendre un son dans le hautparleur du système décrit à la figure 7. La seule action du programme consiste à envoyer de manière répétitive sur le registre de sortie haut-parleur un signal binaire alternatif (1,0,1,0...) afin de faire vibrer celui-ci. Selon l’état du signal écrit sur le bit Q0 du registre de sortie, la membrane du haut-parleur est attirée ou relâchée. Lors d’un cycle d’écriture sur un registre d’entrée-sortie, celui-ci ne mémorise la valeur se trouvant sur les lignes de données que si l’adresse apparaissant sur les lignes d’adresses correspond à sa propre adresse. Si c’est le cas, le décodeur d’adresses engendre un flanc montant sur l’entrée horloge du registre. Seul le bit de poids 20 (Q0) est utilisé pour commander la membrane du haut-parleur.

24

Remise à zéro Reset

I Registre d’instruction 16

Dans le programme BruitHP (figure 4), la colonne de gauche indique l’adresse où se trouve l’instruction située sur la même ligne. La deuxième colonne donne le code hexadécimal du code machine associé à l’instruction assembleur située sur la même ligne. La troisième colonne décrit l’instruction en langage assembleur. La quatrième colonne est réservée aux commentaires.

Figure 3 – Architecture d’un processeur élémentaire 16/32 bits

Le compteur ordinal détermine, en nombre de bits, la taille de l’espace mémoire directement accessible. Les processeurs dits 8 bits ont, en général, un compteur ordinal 16 bits permettant d’adresser 64 kilo-octets (216 octets). Les lignes de données (figure 3) sont au nombre de 8, 16 ou 32. Les instructions recherchées en mémoire et les données lues ou à écrire en mémoire transitent sur les lignes de données. Les lignes d’adresses permettent au processeur de spécifier la position mémoire ou l’interface d’entréesortie sélectionnée pour une opération d’écriture ou de lecture. Les lignes de contrôle synchronisent les échanges d’information entre processeur, mémoire et interfaces d’entrée-sortie. La ligne adresse valide est activée lorsque les adresses sont valides. La ligne lecture/ écriture indique s’il s’agit d’un transfert de données en lecture ou en écriture. La ligne d’acquittement données transférées permet aux mémoires et interfaces d’entrée-sortie de signaler que le transfert est terminé. Un processeur simple est présenté à la figure 3. L’activation de la ligne de remise à zéro (reset) remet à zéro la valeur du compteur ordinal et force le processeur à redémarrer.

Sur ce processeur, les instructions sont formées de 2 ou 4 octets. Chaque mot de 16 bits (2 octets) est représenté par 4 chiffres hexadécimaux qui représentent chacun 4 bits. Par exemple, la première instruction est représentée par les mots mémoire H’103C et H’0000, qui en binaire sont respectivement codés par B’0001’0000’0011’1100 et B’0000’0000’0000’0000. Les chiffres hexadécimaux sont les chiffres 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E et F, où les lettres A à F sont utilisées comme chiffres pour représenter les valeurs 10 à 15. Un nombre hexadécimal est précédé de la lettre H ’ et un nombre binaire de la lettre B ’. Dans les figures 7, 8, 9 le code du programme stocké en mémoire est représenté selon la figure 5. Chaque case horizontale correspond à un mot mémoire 16 bits, qui contient soit le code d’une instruction (par exemple MOVE.B , D0), soit une valeur immédiate (par exemple #HPOFF), soit une adresse d’entrée-sortie (par exemple HP), soit le code de l’instruction de saut (H’6000) auquel s’additionne un déplacement relatif (− H’12=H’EE) sur 8 bits (c’est-à-dire H’60EE dans l’instruction BRA OSCIL). À l’exécution du programme, la valeur #HPOFF définie comme 0 est transférée dans le registre D0. Ensuite le contenu de celui-ci est transmis au registre de sortie HP commandant la membrane du haut-parleur. La valeur #HPOFF a pour effet de faire relâcher la membrane. La même action est répétée avec la valeur #HPON, ce qui a pour effet d’attirer la membrane. Afin d’engendrer un son continu, ce programme boucle continuellement.

1.2 Exécution de programme Examinons en détail le fonctionnement du microprocesseur décrit à la figure 3, c’est-à-dire la nature et le séquencement des cycles de recherche et d’exécution d’instructions. Bien que les instructions machines soient codées en binaire, on les représente de manière symbolique par des mots compréhensibles par l’être humain (langage assembleur). Admettons que le processeur considéré possède les instructions décrites au tableau 1.

Sur les processeurs 16 et 32 bits, il est nécessaire de spécifier dans l’instruction la taille de l’opérande, par exemple MOVE.B, MOVE.W ou MOVE.L pour des instructions de chargement de 8, respectivement 16 et 32 bits. Les instructions en langage assembleur sont exprimées selon la notation de Motorola pour la famille des processeurs 68000.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＵ

S 8 035 − 3

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

M ICROCON TRÔLEURS : PRIN CIPES ET ASPECTS TEM PS RÉEL ___________________________________________________________________________________

; titre du programme

TITLE BruitHP

; définition des constantes

;

code

;

hexa-

;adresse:

décimal:

0000

103C

HP

EQU 0x8040 ; constante adresse haut-parleur (FFFF8040)

HPOFF

EQU 0

; constante membrane relachée

HPON

EQU 1

; constante membrane attirée

programme assembleur:

; commentaires:

OSCIL:

; étiquette marquant le début du programme

MOVE.B

#HPOFF, D0 ; charge la valeur HPOFF (8 bits) dans le registre D0

MOVE.B

D0, HP

MOVE.B

#HPON, D0 ; charge la valeur HPON dans le registre D0

MOVE.B

D0, HP

BRA.B

OSCIL

0000 0004

11C0

0008

Ｓ

103C

; transfère le contenu du registre D0 (8 bits) à l’adresse ; de l’interface haut-parleur

8040 0001 000C

11C0

00010

60EE

; transfère le contenu du registre D0 à l’adresse ; de l’interface haut-parleur

8040

; saute de -H’12 positions pour recommencer au ; début, c’est-à-dire à la position mémoire définie par ; l’étiquette OSCIL (position 0)

END

; H’EE représente le nombre -H’12, c’est-à-dire -18 ; fin du programme

Figure 4 – Programme BruitHP

Code hexadécimal

Adresse de l’octet

Représentation symbolique du code de l’instruction

Instruction correspondante Adresses

Mot mémoire 0000 Mot mémoire 0002

MOVE.B #HPOFF

,D0 103C 0000

MOVE.B #HPOFF,D0

Figure 5 – Représentation en mémoire de l’instruction MOVE.B #HPOFF,D0

Lecture du code de l’instruction

Lecture de l’adresse destination d’entrée-sortie

Écriture du contenu de l’accumulateur à l’adresse d’entrée-sortie H'FFFF8040

4

6

H’8040

Données

H’11C0

H’8040

0000

Type de cycle

Lecture mémoire, Zone programme

Lecture mémoire, Zone programme

Écriture espace d’entrée-sortie, Zone données

Figure 6 – Cycles d’accès à la mémoire et à l’espace d’entrée-sortie, en zone programme et en zone de données

L’exécution d’un programme consiste en une succession de cycles d’accès mémoire en lecture ou en écriture. L’information circule sur les lignes de données (16 bits). Lors d’un cycle d’accès mémoire ou d’entrée-sortie, le processeur place, sur les lignes d’adresses, l’adresse de la position sélectionnée. Lors d’un accès en lecture, le contenu de la position mémoire accédée est placé sur les lignes de données. Le processeur mémorise ainsi la valeur correspondante dans un de ses registres (registre d’instruction ou de données). Lors d’un cycle d’écriture, le processeur place sur les lignes de données la valeur à mémoriser. La mémoire ou, le cas échéant, un registre d’entrée-sortie mémorise cette valeur.

On différencie donc, au niveau du processeur, des accès en lecture à la zone mémoire où se trouve le programme et des accès en lecture ou écriture dans les zones mémoire ou entrées-sorties où se trouvent les données. Par exemple, la recherche et l’exécution de l’instruction MOVE.B D0, HP du programme BruitHP entraînent les cycles d’accès mémoire et entrées-sorties représentés à la figure 6. Dans le cas de notre processeur simple, après activation de la ligne de remise à zéro (reset) (figure 3) le compteur ordinal (PC) est remis à zéro. La première action entreprise par le processeur consiste à effectuer un cycle d’accès mémoire afin de lire le code de la première instruction à l’adresse 0 en mémoire (figure 7). Le processeur mémorise ce code (H’103C) dans son registre d’instruction, le décode et l’interprète. Le compteur ordinal (PC) est ensuite mis à jour pour pointer au prochain mot mémoire.

À l’exécution, nous distinguons les types d’accès processeur suivants : — recherche du code d’une instruction en mémoire (instruction code fetch) : accès en lecture en zone programme ; — recherche de la valeur immédiate ou de l’adresse contenue dans l’instruction courante : accès en lecture en zone programme ; — lecture d’une opérande provenant de la mémoire ou de l’espace d’entrée-sortie lors de l’exécution de l’instruction : accès en lecture en zone données ; — écriture d’une opérande en mémoire ou dans l’espace d’entrée-sortie lors de l’exécution de l’instruction : accès en écriture en zone données.

S 8 035 − 4

Le décodage du code H’103C indique au processeur qu’il s’agit d’une instruction de transfert de la valeur immédiate dans le registre de données D0. Au prochain cycle d’accès mémoire, la valeur immédiate se trouvant à la position mémoire 2 est transférée dans le registre de données D0 (figure 8). Le compteur ordinal (PC) est mis à jour afin de pointer à la prochaine instruction.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＶ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

__________________________________________________________________________________

Adresses

M ICROCON TRÔLEURS : PRIN CIPES ET ASPECTS TEM PS RÉEL

24

Mémoire

Processeur

00

MOVE.B

,D0 103C

02

#HPOFF

0000

04

MOVE.B D0,

11C0

06 0

+2

2

PC

,D0 103C

#HPON

0A

D0

8040

MOVE.B

08

AD

MOVE.B ,D0 103C

HP

0001

0C

MOVE.B D0,

11C0

0E

HP

8040

10

BRA.B

OSCIL 60EE

MOVE.B #HPOFF,D0 Haut-parleur MOVE.B D0,HP Interface d’entréesortie

MOVE.B #HPON,D0

Décodage d’adresses

MOVE.B D0,HP BRA.B

OSCIL

Q7 D7

Reg Instr

Registre de sortie

16

Données

PC : Compteur ordinal

RegInstr : Registre d’instruction

Ｓ

Q0 D0

D0 : Registre de données AD : Registre d'adresse interne (invisible du programmeur)

Pour simplifier, les signaux de contrôle sont omis Figure 7 – Recherche du code de la première instruction

Adresses

24

Mémoire 00

Processeur +2

4

PC AD

04

MOVE.BD0,

08 0A 0C

#HPOFF 0000

D0

,D0 103C

#HPOFF

06 0

MOVE.B

02

0000 11C0

HP

8040

MOVE.B

,D0 103C

#HPON MOVE.B D0,

0E

HP

10

BRA.B

0001 11C0 8040

OSCIL 60EE

MOVE.B #HPOFF,D0 Haut-parleur MOVE.B D0,HP Interface d’entréesortie

MOVE.B #HPON,D0

Décodage d’adresses

MOVE.B D0,HP BRA.B

OSCIL

16

Données

PC : Compteur ordinal

RegInstr : Registre d’instruction

Q0 D0

Q7 D7

MOVE.B ,D0 RegInstr 103C

Registre de sortie

D0 : Registre de données AD : Registre d'adresse interne (invisible du programmeur)

Pour simplifier, les signaux de contrôle sont omis Figure 8 – Recherche de la valeur immédiate

Ainsi s’effectue l’exécution de tout le programme : à chaque instruction, le code de l’instruction est lu de la mémoire, l’instruction

est décodée, les opérandes (valeurs immédiates ou adresses) sont recherchées et l’instruction est exécutée.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＷ

S 8 035 − 5

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＳＵ

M ICROCON TRÔLEURS : PRIN CIPES ET ASPECTS TEM PS RÉEL ___________________________________________________________________________________

Adresses

24

Mémoire MOVE.B

00

Processeur

#HPOFF

04

MOVE.B D0,

PC

8040

AD

Ｓ

,D0 103C

#HPON

0A

D0

11C0 8040

MOVE.B

08

0001

MOVE.B D0,

0C #HPOFF 0000

0000

HP

06 08

,D0 103C

02

0E

HP

10

BRA.B

11C0 8040

OSCIL 60EE

MOVE.B #HPOFF,D0 Haut-parleur MOVE.B D0,HP

MOVE.B #HPON,D0

Interface d’entréesortie Décodage d’adresses

MOVE.B D0,HP BRA.B

OSCIL

Q0 D0

Q7 D7

MOVE.B D0, HP RegInstr 11CO

Registre de sortie

16

Données PC : Compteur ordinal

RegInstr : Registre d’instruction

D0 : Registre de données AD : Registre d'adresse interne (invisible du programmeur)

Pour simplifier, les signaux de contrôle sont omis Figure 9 – Cycle d’écriture lors de l’exécution de l’instruction MOVE.B D0,HP

Lignes d’adresses

Lignes de données

Type de cycle (lecture ou écriture, zone Programme ou Données)

0

2

4

6

103C 0000 11C0 8040

lect P

lect P

lect P

lect P

8040

00

écr D

8

A

C

E

103C 0001 11C0 8040

lect P

lect P

lect P

lect P

8040

01

écr D

10

0

2

4

6

60EE 103C 0000 11C0 8040

lect P

lect P

lect P

lect P

lect P

…

…

…

Figure 10 – Succession des cycles d’accès mémoire et entrées sorties lors de l’exécution du programme BruitHP

L’exécution proprement dite d’une instruction peut s’effectuer implicitement à l’intérieur du processeur, sans exiger de cycle mémoire supplémentaire (par exemple lorsqu’une valeur immédiate est chargée dans un registre de données). Elle peut également exiger un ou plusieurs cycles d’accès mémoire, lorsqu’il s’agit d’écrire une valeur en mémoire ou à une position d’entrée-sortie. Par exemple, lors de l’exécution de la 3ème instruction du programme MOVE.B D0,HP, il y a d’abord un cycle mémoire de recherche de code de l’instruction, puis un cycle de recherche de l’adresse HP (cette adresse est placée dans le registre interne AD) et enfin l’exécution proprement dite de l’instruction par un cycle d’écriture de la valeur qui se trouve dans le registre D0 sur l’adresse d’entréesortie (figure 9).

1.3 Catégories d’instructions Le fonctionnement des principales instructions disponibles sur microprocesseurs et microcontrôleurs est expliqué. En pratique, la plupart des microcontrôleurs sont programmés en langage C. Nous montrons donc pour certaines instructions en langage assembleur l’équivalent en langage C.

1.3.1 Fanions et instructions de saut conditionnel Chaque processeur comporte un certain nombre de fanions (en anglais flags) qui permettent de tester le résultat d’une opération. Par exemple, lors de l’addition de deux nombres positifs 8 bits, il peut y avoir un report. Le fanion de report (Carry) devient actif (« 1 ») s’il y a eu un report. Autrement, il reste inactif (« 0 »). De manière similaire, la soustraction d’un nombre positif par un autre peut

Le diagramme temporel de la figure 10 donne la succession des cycles d’accès mémoire et entrées-sorties lors de l’exécution du programme BruitHP (figures 7, 8, 9).

S 8 035 − 6

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＷＸ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＳ

Approche objet par

Henri DELEBECQUE Docteur en sciences Professeur à l’École supérieure d’électricité (Supelec)

S 8 063 - 2 — 2 — 2

1. 1.1 1.2

Contexte...................................................................................................... Courants ayant influencé les langages à objets ........................................ Langages à objets abordés .........................................................................

2. 2.1 2.2 2.3 2.4

Concepts de base ..................................................................................... Objet.............................................................................................................. Classe ............................................................................................................ Message........................................................................................................ Héritage.........................................................................................................

— — — — —

2 2 4 7 9

3. 3.1 3.2

Approche objet ......................................................................................... Application exemple .................................................................................... Règles de conduite avec des objets ...........................................................

— — —

12 12 14

Pour en savoir plus ...........................................................................................

Doc. S 8 063

es notions de base des langages à objets, et l’approche objet en général sont traitées dans ce document. En nous appuyant sur une connaissance minimale d’un langage de programmation classique, nous présentons les notions de bases présentes dans tout langage à objets que sont les concepts d’objet, de classe, de message et d’héritage. Puis, au travers d’une application typique, nous comparons une décomposition traditionnelle, une décomposition dirigée par les données et une décomposition objet d’un programme.

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｭ｡ｲｳ＠ＲＰＰＸ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＷＹ

S 8 063 – 1

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＳ APPROCHE OBJET __________________________________________________________________________________________________________________

1. Contexte

La terminologie Smalltalk sera préférentiellement employée, lors de l’introduction de nouveaux concepts. Les synonymes existant en C++ et Java, voire d’autres quand certains courants des langages à objets en définissent, seront cités. Les exemples seront donnés en Smalltalk-80, puis soit en C++ soit en Java, en fonction de celui qui se révèle le plus démonstratif.

1.1 Courants ayant influencé les langages à objets On trouve deux courants majeurs à l’origine des langages à objets : l’intelligence artificielle et le parallélisme. Fondamentalement, trois autres courants ont également contribué à faire des langages à objets ce que nous en connaissons : le génie logiciel, la simulation et les langages de programmation pour le Web.

Le lecteur est invité à consulter : – Lisp [H 2 520] (Common Lisp : § 5.1) ; – Langage Java [H 3 088] ; – Conception par objets en C++ [H 3 138] ; – Programmation en langage C++. Concepts [S 8 065] ; – Programmation en langage C++. Exemples [S 8 066].

L’intelligence artificielle a apporté son besoin de liaison dynamique et le pouvoir expressif des langages. Ce courant a apporté également à la communauté des langages à objets un dynamisme et un souci de rigueur théorique particulièrement riches.

Ｓ

Le parallélisme est un courant relativement plus discret (dans les langages à objets), qui toutefois a marqué ceux-ci d’une influence persistante. En effet, les langages à objets (sous la dénomination moins bien définie de langage d’acteurs) sont un moyen relativement naturel de décrire des entités coopérantes et indépendantes, et permettant d’implémenter assez simplement des entités parallèles. Les adeptes du génie logiciel sont intervenus plus tard dans le monde des langages à objets, mais fortement. Ils ont apporté avec eux la rigueur du typage, l’efficacité des compilateurs et les contrôles à l’exécution indispensables à toute bonne application opérationnelle.

2. Concepts de base Nous allons tout d’abord étudier les concepts que l’on rencontre dans tous les langages à objets. L’objectif n’est pas de définir des critères binaires, qui permettraient de trancher entre ce qui est et ce qui n’est pas un langage à objets. Cette querelle est, à mon avis, stérile et peu intéressante. Stérile car le meilleur langage ne peut rien contre un programmeur têtu et décidé à faire de la mauvaise programmation coûte que coûte. De ce fait, l’utilisation d’un langage à objets ne suffit pas à garantir que l’on programme par objets. Peu intéressante car la dénomination même de langage à objets est devenue un label vital, et qu’il existe actuellement peu de langages nouveaux qui ne le soient pas.

L’influence des concepteurs de systèmes de simulation ne doit pas être sous-estimée. La simulation utilise des primitives de parallélisme, développe souvent des logiciels très volumineux (ce qui représente des contraintes proches de celles du génie logiciel), le tout avec une interface homme machine le plus agréable possible. La filiation entre les premiers langages de simulation [1] et les environnements modernes de fenêtrage passe par les langages à objets.

2.1 Objet

Enfin, un des langages à objets les plus récents, Java [2], a été initialement conçu par Sun pour être embarqué dans des appareils électroniques à usage domestique, quel que soit leur processeur. De ce cahier des charges est né un langage particulièrement adapté à la diffusion d’applications sur Internet. Ses contraintes d’opérationnalité lui confèrent des caractéristiques assez proches des langages du génie logiciel.

L’objet est la notion centrale dans un langage à objets. En première approximation, on peut dire que tout ce qui est décrit ou manipulé dans un langage à objets est un objet. L’utilisation d’objets pour représenter toute chose dans un langage à objets signifie que les entités créées par l’utilisateur, par le système et celles préexistantes sont parfaitement semblables. De ce fait, l’utilisateur du langage (le programmeur) ne pourra distinguer ses propres objets des autres. Cela constitue un avantage important : le système devient pour lui aussi accessible que son propre code. L’axiome « tout est objet » que nous venons d’énoncer implicitement sera repris en détail dans la suite de ce paragraphe consacré aux concepts de base.

1.2 Langages à objets abordés Smalltalk a été, très longtemps, un standard de fait dans le monde des langages à objets. Ceci est d’autant plus remarquable que la communauté des concepteurs de langages à objets était prolifique à cette époque. On pouvait donc redouter une profusion de langages sans points communs significatifs, ni terminologie commune.

Les objets sont classiquement assez dynamiques : ils s’échangent des informations, apparaissent et disparaissent au fur et à mesure du déroulement de l’application.

En effet, la définition d’un langage à objets en « extension » d’un langage classique (Lisp, Prolog, C) est assez simple. Cela a favorisé l’émergence d’une multitude de langages à objets, quelquefois réduits à de simples modèles. Smalltalk dans sa version 1980 (alias Smalltalk-80 [3]) servira de langage de référence par la suite, car il conserve un statut de modèle pédagogique dans les langages à objets. Quand ses options personnelles ne permettront pas de mettre en évidence certains mécanismes intéressants, C++ [4], Java, voire CLOS (Common Lisp Object System) seront utilisés. Le premier est un langage à objets construit au-dessus de C, le second est proche du premier, mais reprend nombre des options de Smalltalk-80, le dernier une extension objet de Common Lisp (voir Lisp [H 2 520]).

2.1.1 Définition Un objet est défini par deux composantes, une dite déclarative (qui définit l’état de l’objet), et l’autre procédurale (qui définit les procédures qui s’appliquent à cet état). La distinction entre les deux n’est pas toujours évidente, parfois même de par la volonté du concepteur du langage. Elle porte essentiellement sur la forme que prennent les définitions. La composante déclarative (§ 2.1.1.1) est la partie statique de l’objet, par opposition à la composante procédurale (§ 2.1.1.2), qui décrit l’évolution, et concerne donc la dynamique de l’objet. Cette seconde dichotomie n’est pas obligatoirement mieux respectée que celle qui sépare déclaratif et procédural. On trouvera par exemple des informations statiques dont la définition sera en partie dynamique (vérification, valeur par défaut...) ou des comportements qui retournent des valeurs constantes.

Dans le premier et le dernier cas, il serait abusif et dangereux de considérer respectivement le compilateur C++ comme un préprocesseur, et CLOS comme une simple collection de fonctions. L’un comme l’autre ont à régler des problèmes non triviaux pour respectivement fournir un code C et appeler les fonctions Lisp convenables.

S 8 063 – 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＸＰ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＳ ___________________________________________________________________________________________________________________ APPROCHE OBJET

2.1.1.1 Composante déclarative

2.1.2.2 Universalité du concept d’objet

La composante déclarative de l’objet est interne et rémanente. Par interne, il faut entendre que le monde extérieur (c’est-à-dire les autres objets) n’a que peu, voire aucun moyen d’atteindre directement ces informations déclaratives. La propriété de rémanence permet de considérer chaque objet comme un automate plus ou moins complexe, capable de mémoriser une ou plusieurs informations, de les modifier ou de fournir leurs valeurs, selon la demande qui lui est faite par un autre objet.

Un des pères de Smalltalk, Alan Kay, a énoncé vers les années 1970 un principe qui a régi depuis beaucoup de modèles de langages à objets : « tout est objet ». Ce principe est très important pour la rigueur et la validité du modèle du langage. Intuitivement, nous réalisons que plus le langage que nous examinons décrit de concepts différents (types scalaires et vectoriels, agrégats, déclarations avec ou sans initialisations, affectations, opérateurs, fonctions, procédures, structures de contrôle, modules, tâches...), plus son modèle va être complexe, et plus le novice va souffrir pour assimiler et maîtriser correctement ces concepts, surtout si la même notion peut être traduite avec plusieurs d’entre eux, sans choix évident.

La composante déclarative d’un objet est décomposée en attributs. Chaque objet possède des attributs personnels, nommés, qui ressemblent aux champs d’une structure C ou d’un record Pascal. L’objet qui désire consulter un de ses attributs le fera exclusivement en le nommant. On parlera de slots en intelligence artificielle, de variables d’instance (nous définirons le terme d’instance bientôt (§ 2.2.1)) en Smalltalk ou en Java. C++, quant à lui, appellera les attributs de ces objets des membres. Les valeurs associées à ces attributs constituent, en première analyse, les seuls liens de l’objet vers le monde extérieur. En effet, la valeur d’un attribut (un entier par exemple) sera en fait une référence (un pointeur, un identificateur d’objet) sur un autre objet (un objet entier) dans un langage comme Smalltalk-80.

Tout l’intérêt des langages à objets est d’avoir unifié tout ce qui était information dans la notion d’attribut, et tout ce qui était traitement dans la notion de méthode. 2.1.2.3 Liberté de définition de structure interne Nous avons vu que l’encapsulation de l’objet interdisait à tout objet externe de consulter un attribut d’un autre objet. Cela apporte des propriétés très intéressantes de protection et de fiabilité. Mais cela permet également à un objet d’être indépendant des autres : il est libre de renommer, de créer ou de supprimer des attributs sans que quoi que ce soit en dehors de ses méthodes n’évolue.

2.1.1.2 Composante procédurale La composante procédurale est la contrepartie du caractère protégé de l’état interne. Sans moyen d’accéder aux informations protégées par l’objet, celles-ci seraient inutiles. Un des rôles de la composante procédurale est donc de fournir des accès (en lecture et en écriture) à certaines informations privées de l’objet. La composante procédurale traduit le comportement de l’objet face aux requêtes qui vont lui être adressées. Elle est décomposée en méthodes qui sont désignées, comme les attributs, par des noms. L’appellation « méthode » est pratiquement admise par tous les langages (C++ fait exception, en parlant de fonctions membres).

On peut faire cohabiter des implémentations différentes des mêmes entités, ou même remplacer (éventuellement en cours d’exécution) des objets implémentés selon une technique par d’autres plus efficaces, ou plus puissants, sans remettre en cause les autres. Cette propriété est désignée dans la littérature anglo-saxonne par data abstration. Prenons l’exemple d’un point. Il peut être représenté en coordonnées polaires ou cartésiennes. Les objets qui utilisent des points (les rectangles, par exemple), n’ont pas à connaître le type de point qu’ils utilisent. En fait, ils doivent même en être indépendant, pour pouvoir accepter indifféremment les uns ou les autres. Cela peut se réaliser trivialement dès que les points sont bien des objets, et donc bien encapsulés.

Remarquons que le nom d’une méthode est défini localement, ce qui permet d’avoir des méthodes de même nom, avec des implémentations différentes, associées à autant d’objets.

2.1.2 Propriétés

Qui plus est, cette indépendance fait partie intégrante du modèle des langages à objets. Elle n’est pas « plaquée » sur le langage, comme l’approche modulaire peut l’être sur Pascal ou sur Fortran. Elle est obtenue sans contraintes, en utilisant une approche différente (l’approche objet) du problème à régler.

Selon les langages, les objets vont bénéficier de propriétés plus ou moins intéressantes et plus ou moins contraignantes. 2.1.2.1 Encapsulation Parmi ces propriétés, nous allons trouver le respect de l’aspect privé de la composante déclarative. Cette propriété est habituellement appelée encapsulation de l’objet. Elle est indispensable pour garantir la conformité de l’état interne à un ensemble de règles que le programmeur peut fixer dans la spécification de l’objet. En effet, si n’importe quel objet est capable d’altérer la valeur d’un attribut d’un objet, ce dernier n’a plus la possibilité de vérifier la cohérence de son état interne. Il ne peut le faire que s’il est le seul à atteindre, via ses méthodes, les valeurs de ses attributs.

2.1.2.4 Liberté d’implémentation du comportement Une même sollicitation peut être reçue par de nombreux objets, qu’ils soient représentés ou non de la même manière (par exemple, des points cartésiens ou polaires pourront se voir demander leur abscisse). Il va de soi que ces requêtes ne peuvent être traitées de la même manière par tous les objets. Or, l’indépendance que nous souhaitons obtenir entre les objets nous interdit de « spécialiser » la requête (son nom) en fonction du destinataire. Par exemple, il n’est pas concevable qu’un rectangle doive utiliser tantôt abscisse_pour_cartésien ou abscisse_pour_polaire, car il devrait alors connaître la nature de l’objet auquel il s’adresse. Le remplacement définitif des points cartésiens par des points polaires aurait alors un impact non négligeable sur tous les objets utilisateurs de points cartésiens.

Le respect de cette propriété est donc un credo fondamental des langages à objets orientés vers le génie logiciel. On retrouve les bons principes de la programmation modulaire, mais vécus non pas comme une contrainte à respecter, mais comme une caractéristique normale de toute entité du langage. Certains langages à objets qui se destinent au génie logiciel vont même plus loin, incluant des préconditions et postassertions sur l’état interne de l’objet, déclenchées respectivement avant et après l’exécution d’une méthode (Eiffel [5] ou D [6]). Cependant, pour qu’une entité d’un langage à objets soit encapsulée, elle doit être définie comme un objet. Donc, tout ce qui n’est pas un objet ne pourra bénéficier de cette propriété. Cela nous conduit à une autre propriété potentielle des langages à objets.

L’objet doit donc être capable d’attacher une implémentation particulière à une requête qu’il reçoit. Cette requête sera appelée message et l’objet pourra associer une méthode spécifique à chaque message qu’il sait traiter. Nous aborderons au paragraphe 2.3 la définition d’un message. La fonction d’association entre message et méthode est donc définie localement pour un objet.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＸＱ

S 8 063 – 3

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＳ APPROCHE OBJET __________________________________________________________________________________________________________________

2.1.3 Variantes suivant les langages

2.2 Classe

Les langages à objets classiques reprennent le modèle d’objet que nous venons de décrire, dans ses grandes lignes. Mais ils lui apportent toujours des caractéristiques supplémentaires, pour des raisons qui leur sont propres. Nous allons examiner les principales divergences que l’on peut rencontrer, en tenant compte du courant auquel appartient le langage à objets en question.

Nous avons défini les objets et vu qu’ils constituent le moyen privilégié de représentation des informations. Mais définir chaque structure de chaque objet est fastidieux d’une part, dangereux d’autre part. Imaginons par exemple les dizaines de points nécessaires à la construction d’une fenêtre définis chacun par une liste d’attributs. Le programmeur passera beaucoup de temps à créer des points, en dupliquant les définitions (ce qui n’est pas une bonne chose), peut-être en les changeant légèrement, ce qui est également à proscrire. Il vient donc tout naturellement à l’esprit de factoriser cette description des attributs communs à tous les points dans une classe.

2.1.3.1 L’objet est-il réellement encapsulé ? En Smalltalk-80, l’encapsulation est strictement respectée, ce qui correspond à une jonction des courants génie logiciel et simulation dans laquelle Smalltalk s’insère. Le monde extérieur ne peut jamais atteindre les informations privées d’un objet.

Ｓ

La présence de classes est un signe distinctif des langages à objets. C’est d’autre part dans la définition de celle-ci que les langages se distinguent les uns des autres. Certains vont définir des classes comme de véritables objets (et respecter l’axiome d’Alan Kay), alors que d’autres limiteront pratiquement leur rôle au seul compilateur.

L’encapsulation est binaire : tout ce qui n’est pas public est privé, et inversement. De plus, et cela est relativement dommage, la protection est imposée par Smalltalk-80 selon le type d’information : les attributs sont toujours privés, les méthodes toujours publiques. Cette option n’est pas fondamentalement gênante, puisque, de par le principe de l’encapsulation, le monde extérieur ne peut discerner de différence. Seul le concepteur se voit limité dans son implémentation. En effet, si on peut « simuler » des attributs par des méthodes retournant une constante, l’inverse n’est pas vrai.

2.2.1 Définition La classe est tout d’abord un « moule » d’objet, c’est-à-dire qu’elle contient une définition de la structure de l’objet qu’elle doit créer. On parlera, pour définir cette structure, de schéma d’instance. En corollaire, l’objet qui a été créé par une classe sera appelé une instance de cette classe. Les objets qui sont instances d’une même classe vont, assez normalement, servir dans les mêmes conditions, et donc répondre aux mêmes sollicitations. Il a donc paru naturel d’ajouter un second rôle à la classe : elle possède toutes les informations partagées entre toutes ses instances, au premier rang de celles-ci, les méthodes qui caractérisent ses instances.

Notons enfin que le fait de fournir des méthodes d’accès à un attribut ne supprime pas l’encapsulation, dans la mesure où il existe toujours un point d’entrée unique pour atteindre sa valeur : la méthode d’accès. La suppression de l’attribut n’entraînerait qu’une réécriture de la méthode, mais aucune modification du monde extérieur. C++ et Java vont se retrouver très souvent ensemble, dans la suite de ce document, puisqu’ils procèdent des mêmes principes : un typage fort permettant d’atteindre simultanément les objectifs de sécurité (par une détection d’un maximum d’erreurs dès compilation) et de rapidité.

2.2.2 Propriétés Nous avons dit que tout, dans un bon langage à objets, était objet. Compte tenu de la définition de la classe que nous venons de donner, on peut compléter en affirmant que tout est issu d’une classe. Donc tout est instance.

Ils constituent les fers de lance des langages à objets actuels. Ils garantissent, tant que le programmeur en a décidé ainsi, le respect de l’encapsulation. Le programmeur peut, à loisir, déclarer un attribut ou une méthode publique ou privée. Ils décrivent tous deux une possibilité supplémentaire, mais d’usage différent.

2.2.2.1 La classe est un générateur

C++ parle de friends pour indiquer qu’un objet pourra consulter les attributs d’un autre objet dont il a été déclaré comme « ami » comme s’ils étaient les siens. Java définit une encapsulation « par défaut », de type package, dans laquelle les attributs ou méthodes sont visibles de toutes les classes et méthodes du même paquetage (qui est en fait un ensemble de classes, définis dans autant de fichiers, et retrouve la sémantique que le langage Ada [7] donnait à cette notion).

En tant que telle, elle doit posséder tout ce qui est nécessaire à la création d’une instance, donc un schéma d’instance mais aussi le mécanisme de création (d’instanciation). Dans le cas d’un langage à objets non typé, cette information suffit, puisque tous les attributs auront le même encombrement mémoire. Dans le cas contraire, le schéma d’instance devra contenir le type de chaque attribut. Le mécanisme d’instanciation procède essentiellement à une réservation de l’espace-mémoire suffisant, à l’attribution d’un identifiant unique à la nouvelle instance créée, puis à son initialisation (dans certains langages).

Il faut conserver à l’esprit que la description d’un attribut comme public amoindrit considérablement les possibilités d’évolution de l’objet qui le fait. C’est toujours déconseillé. De ce fait, la seule justification des friends est la recherche d’efficacité (en transigeant sur la sécurité), puisque l’accès direct peut être plus rapide qu’un appel à une fonction d’accès, si elle évite des contrôles de validité d’arguments.

Clarifions tout de suite cette notion d’identifiant. La capacité de s’adresser à un objet, et à lui seul, est fondamentale pour le dialogue entre objets. Elle repose sur l’existence d’une bijection entre l’ensemble des identifiants et celui des objets. D’un point de vue concret, l’identifiant peut, dans un langage à objets non distribué (c’est-à-dire destiné à s’exécuter sur une seule machine) être un pointeur sur l’objet. Par contre, le problème cesse d’être trivial dès que l’on cherche à distribuer le monde des objets sur plusieurs processeurs ou processus, car la notion d’adresse n’est alors plus significative. Or, le problème de la distribution des objets au sein d’une configuration multiprocesseur ou multiprocessus est maintenant excessivement courant dans un contexte opérationnel.

2.1.3.2 L’objet est-il typé ? Le typage est une option classique des langages à objets qui se destinent au génie logiciel. Il permet d’assigner un domaine de valeurs à un attribut (ou de manière plus générale à une variable). Le génie logiciel s’y intéresse car il permet au compilateur de détecter un grand nombre d’erreurs, et donc d’améliorer la fiabilité du code. Ce typage est donc partie intégrante du modèle de langages à objets destinés au génie logiciel. C++ et Java sont typés. Smalltalk-80, comme les extensions objets de Lisp, n’introduit aucune forme de typage.

S 8 063 – 4

Le mécanisme de création proprement dit est un comportement de classe. Il est classiquement le même pour toutes les classes. Seule l’initialisation sera particularisée par chaque classe. Le comportement de création est défini par une méthode (tout ce qui

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. – © Editions T.I.

ＸＲ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＵ

Programmation en langage C++ Concepts par

Claude DELANNOY Ingénieur de l’ENSEM (École nationale supérieure d’électricité et de mécanique) de Nancy Ingénieur informaticien au CNRS (Centre national de la recherche scientifique)

S 8 065 – 2

1.

Présentation générale.............................................................................

2.

Améliorations de C++ par rapport à C ...............................................

—

3

3.

Notion de classe.......................................................................................

—

5

4.

Fonctions amies .......................................................................................

—

8

5.

Surdéfinition d’opérateurs ....................................................................

—

8

6.

Héritage ......................................................................................................

—

9

7.

Fonctions virtuelles et polymorphisme .............................................

—

12

8.

Flots d’entrée et de sortie .....................................................................

—

12

9.

Patrons de fonctions...............................................................................

—

13

10. Patrons de classes ...................................................................................

—

14

11. Gestion des exceptions ..........................................................................

—

16

12. Bibliothèque standard ............................................................................

—

16

Références bibliographiques .........................................................................

—

18

a programmation orientée objet (en abrégé POO) est dorénavant universellement reconnue pour les avantages qu’elle procure. Notamment, elle améliore largement la productivité des développeurs, la robustesse, la portabilité et l’extensibilité de leurs programmes. Enfin, et surtout, elle permet de développer des composants logiciels entièrement réutilisables. Un certain nombre de langages dits « langages orientés objet » (LOO) ont été définis de toutes pièces pour appliquer les concepts de POO. C’est ainsi que sont apparus dans un premier temps des langages comme Smalltalk, Simula ou Eiffel, puis Java. Le langage C++, quant à lui, a été conçu suivant une démarche quelque peu différente par B. Stroustrup (AT&T) ; son objectif a été, en effet, d'adjoindre au langage C un certain nombre de spécificités lui permettant d'appliquer les concepts de POO. Ainsi, C++ présente-t-il sur un vrai LOO l'originalité d'être fondé sur un langage répandu. Cela laisse au programmeur toute liberté d'adopter un style plus ou moins orienté objet, en se situant entre les deux extrêmes que constituent la poursuite d'une programmation classique d'une part, une pure POO d'autre part. Si une telle liberté présente le risque de céder, dans un premier temps, à la facilité en mélangeant les genres (la POO ne renie pas la programmation classique - elle l'enrichit), elle permet également une transition en douceur vers la POO pure, avec tout le bénéfice que l'on peut en escompter à terme. De sa conception jusqu'à sa normalisation, le langage C++ a quelque peu évolué. Initialement, un certain nombre de publications de AT&T ont servi de référence au langage. Les dernières en date sont : la version 2.0 en 1989, les versions 2.1 et 3 en 1991. C’est cette dernière qui a servi de base au travail du comité ANSI (American National Standard Institute) lequel, sans la remettre en cause, l'a enri-

ｐ｡ｲｵｴｩｯｮ＠Ｚ＠ｳ･ｰｴ･ｭ｢ｲ･＠ＲＰＰＳ

L

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＸＳ

S 8 065 − 1

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＵ

PROGRAMMATION EN LANGAGE C++ ______________________________________________________________________________________________________

chie de quelques extensions et surtout de composants standards originaux se présentant sous forme de fonctions et de classes génériques que l’on désigne souvent par le sigle STL (Standard Template Library). La norme définitive de C++ a été publiée en juillet 1998. Cet article est extrait de l’ouvrage « Programmer en langage C++ » du même auteur, paru aux éditions Eyrolles [5].

1. Présentation générale

Ｓ

dérablement la maintenance : une modification éventuelle de la structure des données d’un objet n’a d’incidence que sur l’objet luimême ; les utilisateurs de l’objet ne seront pas concernés par la teneur de cette modification (ce qui n’était bien sûr pas le cas avec la programmation structurée). De la même manière, l’encapsulation des données facilite grandement la réutilisation d’un objet.

Afin de mieux situer le langage C++, nous commencerons par quelques rappels concernant la POO.

1.1.3 Classe

1.1 Programmation orientée objet

En POO apparaît généralement le concept de classe, qui correspond à la généralisation de la notion de type que l’on rencontre dans les langages classiques. En effet, une classe n’est rien d’autre que la description d’un ensemble d’objets ayant une structure de données commune et disposant des mêmes méthodes. Les objets apparaissent alors comme des variables d’un tel type classe (en POO, on dit aussi qu’un objet est une « instance » de sa classe).

1.1.1 De la programmation structurée à la POO Si l’activité de programmation peut s’avérer simple lorsqu’il s’agit de développer un code de quelques lignes, elle peut devenir extrêmement complexe lorsque la taille des programmes devient importante. La production industrielle de logiciel doit alors chercher à imposer des exigences de qualité et tenter de les mesurer en utilisant certains critères comme l’exactitude, la robustesse, l’extensibilité, la réutilisabilité, la portabilité, l’efficience.

1.1.4 Héritage

La programmation structurée a, en son temps, permis de faire progresser la qualité de la production des logiciels. Elle reposait sur ce que l’on nomme souvent « l’équation de Wirth », à savoir :

Un autre concept important en POO est celui d’héritage. Il permet de définir une nouvelle classe à partir d’une classe existante (que l’on réutilise en bloc !), à laquelle on ajoute de nouvelles données et de nouvelles méthodes. La conception de la nouvelle classe, qui « hérite » des propriétés et des aptitudes de l’ancienne, peut ainsi s’appuyer sur des réalisations antérieures parfaitement au point et les « spécialiser » à volonté. Comme on peut s’en douter, l’héritage facilite largement la réutilisation de produits existants, d’autant plus qu’il peut être réitéré autant de fois que nécessaire (la classe C peut hériter de B, qui elle-même hérite de A).

Procédures + Structures de données = Programmes Bien sûr, elle a permis de structurer les programmes, et partant, d’en améliorer l’exactitude et la robustesse. En revanche, elle n’a pas tenu ses promesses pour ce qui est de l’adaptation ou la réutilisation des programmes. Ces opérations obligeaient généralement à remettre en cause une structure de données et donc à modifier une ou plusieurs des procédures agissant sur elle. Ce type de difficultés émane directement de l’équation de Wirth, qui découple totalement les données des procédures agissant sur ces données.

1.2 Place de C++ par rapport à C

C’est là qu’intervient la programmation orientée objet (en abrégé POO), fondée justement sur le concept d’objet, à savoir une association des données et des procédures (que l’on appelle alors méthodes) agissant sur ces données. Par analogie avec l’équation de Wirth, on pourrait dire que l’équation de la POO est :

On peut dire que C++ se présente comme une extension du langage C offrant des possibilités de POO. Mais tous les apports du C++ par rapport au C ne sont pas liés à la POO. Certains pourraient en effet être ajoutés avec profit au C, sans qu’il devienne pour autant orienté objet. Cela est notamment le cas pour la notion de référence et pour les surdéfinitions de fonctions que nous examinerons au paragraphe 2.

Méthodes + Données = Objet

1.1.2 Encapsulation Mais cette association est plus qu’une simple juxtaposition. En effet, elle s’assortit de ce que l’on nomme une encapsulation des données. Cela signifie qu’il n’est pas possible d’agir directement sur les données d’un objet ; il est nécessaire de passer par l’intermédiaire de ses méthodes, qui jouent ainsi le rôle d’interface obligatoire. On traduit parfois cela en disant que l’appel d’une méthode est en fait l’envoi d’un « message » à l’objet.

Les possibilités de POO représentent bien sûr l’essentiel des apports de C++. On y retrouve tout naturellement les notions de classe, d’encapsulation et d’héritage, évoquées précédemment. Mais le programmeur n’est pas tenu d’y recourir à tout prix comme il devrait le faire dans un pur langage orienté objet. Ainsi, pourra-t-il créer un programme sans utiliser de classes, ou encore créer des classes sans respecter totalement le principe d’encapsulation...

Le grand mérite de l’encapsulation est que, vu de l’extérieur, un objet se caractérise uniquement par les spécifications (noms, arguments et rôle) de ses méthodes, la manière dont sont réellement implantées les données étant sans importance. On décrit souvent une telle situation en disant qu’elle réalise une « abstraction des données », ce qui exprime bien que les détails concrets d’implémentation sont cachés. L’encapsulation des données présente un intérêt manifeste en matière de qualité de logiciel. Elle facilite consi-

Par ailleurs, C++ se trouve doté de fonctionnalités POO originales dont ne disposent pas tous les langages orientés objet : — comme en Java, une classe peut être munie de constructeur (méthode obligatoirement exécutée lors de toute création d’un objet) et de destructeur (méthode exécutée au moment de la destruction d’un objet) ; — on peut définir des « fonctions amies d’une classe ». Il s’agit de fonctions « usuelles » (qui ne sont donc pas des méthodes d’une

S 8 065 − 2

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＸＴ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＵ

______________________________________________________________________________________________________ PROGRAMMATION EN LANGAGE C++

classe) qui sont autorisées (par une classe) à accéder aux données (encapsulées) de la classe ; — la surdéfinition d’opérateurs permet de doter une classe d’opérations analogues à celles que l’on rencontre pour les types prédéfinis. Par exemple, on pourra définir une classe nommée complexe (destinée à représenter des nombres complexes) et la munir des opérations d’addition, de soustraction, de multiplication et de division. Qui plus est, ces opérations pourront utiliser les symboles existants : +, -, *, / ; — les entrées-sorties deviennent fondées sur la notion de « flot », ce qui permet de leur donner un sens pour les types définis par l’utilisateur que sont les classes (grâce au mécanisme de surdéfinition d’opérateur) ; — la notion de patron permet de définir des modèles utilisables pour générer différentes classes ou différentes fonctions qualifiées parfois de génériques, même si cette généricité n’est pas totalement intégrée dans le langage lui-même, comme c’est par exemple le cas avec ADA ; — dans la bibliothèque standard de C++, qui vient compléter celle du C, toujours disponible, on trouve de nombreux patrons de classes et de fonctions permettant de mettre en œuvre les structures de données et les algorithmes les plus usuels, évitant ainsi d’avoir à réinventer la roue à la moindre occasion.

namespace une_bibli { // déclarations usuelles } Pour se référer à des identificateurs définis dans cet espace de noms, on utilisera une instruction using : using namespace une_bibli // ici, les identificateurs de une_bibli sont connus On peut aussi utiliser l'instruction using pour faire un choix permanent : using une_bibli::point ; // dorénavant, l'identificateur point, // employé seul correspondra à celui // défini dans l'espace de noms une_bibli Tous les identificateurs des fichiers en-tête standards sont définis dans l’espace de noms std ; aussi est-il nécessaire de recourir systématiquement à l’instruction : using namespace std ;

// utilisation des fichiers // en-tête standard //

Généralement, cette instruction figurera à un niveau global. Elle ne peut cependant apparaître que si l’espace de noms qu’elle mentionne existe déjà ; en pratique, cela signifie que cette instruction sera placée après l’inclusion des fichiers en-tête.

2. Améliorations de C++ par rapport à C

2.3 Nouvelles possibilités d'entrées-sorties

Nous décrivons ici les principales améliorations non orientées objet que C++ a apporté au langage C.

C++ dispose de nouvelles facilités d'entrées-sorties. Bien qu'elles soient fortement liées à des aspects POO (surdéfinition d'opérateur en particulier), elles sont parfaitement utilisables en dehors de ce contexte. C'est tout particulièrement le cas des possibilités d'entrées-sorties conversationnelles (clavier, écran) qui remplacent avantageusement les fonctions printf et scanf. Ainsi :

2.1 Sécurisation de l’utilisation des fonctions

cout variable_2 >> ......... >> variable_n lit sur le flot cin (connecté par défaut à l'entrée standard stdin) des informations de l'un des types char, short, int, long, float, double ou char * (les pointeurs ne sont pas admis). Les conventions d'analyse des caractères lus sont comparables à celles de scanf, avec cette principale différence que la lecture d'un caractère commence par sauter les espaces blancs (espace, tabulation horizontale, tabulation verticale, fin de ligne, changement de page).

float fexp (int, double, char *); — soit d'une définition préalable au sein du même fichier source (ce dernier cas étant d'ailleurs peu conseillé, dans la mesure où des problèmes risquent d'apparaître si, par la suite, on sépare ladite fonction du fichier source en question).

Ces nouvelles possibilités d'entrées-sorties nécessitent l'inclusion d'un fichier en-tête nommé iostream. Compte tenu de la notion d’espace de noms examinée ci-avant, on voit qu’il est généralement nécessaire de faire précéder tout fichier source de ces instructions : #include using namespace std ;

2.2 Espaces de noms Lorsque l'on doit utiliser plusieurs bibliothèques dans un programme, on peut être confronté au problème dit de « pollution de l’espace des noms », lié à ce qu'un même identificateur peut très bien avoir été utilisé par plusieurs bibliothèques. Le même problème peut se poser, à un degré moindre toutefois, lors du développement de gros programmes. C'est la raison pour laquelle la norme ANSI du C++ a introduit le concept d’« espace de noms ». Il s'agit simplement de donner un nom à un « espace » de déclarations, en procédant ainsi :

2.4 Nouvelle forme de commentaires En C, un commentaire peut être introduit en n'importe quel endroit où un espace est autorisé en le faisant précéder de /* et suivre de */. Il peut alors éventuellement s'étendre sur plusieurs lignes.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. © Techniques de l’Ingénieur, traité Informatique industrielle

ＸＵ

S 8 065 − 3

Ｓ

ｒ￩ｦ￩ｲ･ｮ｣･＠ｉｮｴ･ｲｮ･ｴ ｓＸＰＶＵ

PROGRAMMATION EN LANGAGE C++ ______________________________________________________________________________________________________

Exemple : utilisation de la transmission d'arguments par référence en C++

En C++, vous pouvez en outre utiliser des « commentaires de fin de ligne » en introduisant les deux caractères : //. Dans ce cas, tout ce qui est situé entre // et la fin de la ligne est un commentaire. Notez que cette nouvelle possibilité n'apporte qu'un surcroît de confort et de sécurité ; en effet, une ligne telle que : cout