Str

Collège Militaire Royal

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Hiver 1999 Capt. J. Dolbec Poste 6656 SB4008

PLAN DE COURS GEF499B

BUT Le but de ce cours est de présenter aux étudiants de quatrième année en génie informatique, option génie logiciel, es concepts de développement de logiciels en temps réel.

OBJECTIFS Ce cours vise à atteindre les objectifs suivants:a. comprendre ce qu'est un système en temps réel; b. connaître les caractéristiques des systèmes en temps réel;c. étudier la méthode de conception ROOM et être familier avec l'outil de conception ObjecTime; d. comprendre les principes de réalisation des systèmes en temps réel; et e. comprendre les principes reliés aux systèmes d'exploitation en temps réel; et f. apprécier les difficultés reliées à conception des systèmes en temps réel et les approches pour les résoudre.

CONTENU DU COURS A. Introduction1. Introduction à la Conception des Systèmes en Temps Réel (1 heure) 2. Caractéristiques et Exemples de Systèmes en Temps Réel (2 heures)B. La Méthode de Conception ROOM - Partie 11. Introduction à la Méthodologie ROOM (1 heure)

Collège Militaire Royal

1

Collège Militaire Royal

2. Modélisation de la Structure - Partie 1 (1 heure) 3. Modélisation du Comportement - Partie 1 (1 heure) 4. Le Langage RPL (1 heure) 5. Les Services du Run-Time System (RTS) (1 heure) 6. Modélisation de la Structure - Partie 2 (1 heure) 7. Modélisation du Comportement - Partie 2 (1 heure) 8. Réalisation des Acteurs et du Micro RTS 1 (2 heures)C. Réalisation des Systèmes en Temps Réel1. Les Langages de Programmation en Temps Réel (1 heure) 2. Les Noyaux de Systèmes en Temps Réel (1 heure) 3. Communication et Synchronisation des Procédés en Temps Réel (2 heures) 4. Gestion de la Mémoire des Systèmes en Temps Réel (1 heure) 5. Les Systèmes Distribués en Temps Réel (1 heure)D. Le MicroC/OS1. Architecture et Caractéristiques (1 heure) 2. Étude Détaillée (3 heures) 3. MicroC/OS version orientée objet (1 heure)E. Vérification des Systèmes en Temps Réel1. Les Algorithmes de Temporisation (3 Heures) 2. Estimation de la Fiabilité de Systèmes en Temps Réel (3 heures)

ÉVALUATION 1. Laboratoires: 10% 2. Projet: 20% 3. Devoirs et Mini-Tests: 5% 4. Examen(s) de Mi-Session (Pratique et Théorique): 25% 5. Examen Final: 40%

HORAIRE DES CLASSES Lundi: Période 4

Collège Militaire Royal

2

Collège Militaire Royal

Jeudi: Période 3 Vendredi: Période 5

LABORATOIRES Mardi: Périodes 8 & 9

Laboratoire 1: Introduction à ObjecTime RPL (2 semaines) Laboratoire 2: Introduction à ObjecTime C++ (1 semaine) Laboratoire 3: Concepts Avancés en C++ avec ObjecTime (1 semaine) Laboratoire 4: Le Problème du Chronomètre avec ObjecTime (2 semaines) Laboratoire 5: Conception et Réalisation Avancée avec ObjecTime (4 semaines) Laboratoire 6: Système d'Exploitation en Temps Réel (2 semaines) Laboratoire 7: MicroC/OS(2 semaines)RAPPORTUn rapport de laboratoire devra être soumis pour chaque laboratoire. Tous les laboratoires devront être effectués sous une base individuelle. Tous les rapports de laboratoires doivent être remis une semaine après la dernière période du laboratoire correspondant. Une pénalité de 10% par jour de la note de base sera appliquée à tous les rapports soumis en retard.

MINI-TESTS Des mini-tests auront lieu à intervalle régulier. Le contenu des ces mini-tests portera sur la matière présentée jusqu'à l'annonce du mini-test et peut aussi porter sur le contenu des laboratoires.

DEVOIRS Des devoirs sont requis à la fin de certains cours. Ces devoirs sont à remettre trois jours ouvrables après la fin de la leçon correspondante.

ADMINISTRATION Faire les lectures indiquées à la fin de chaque leçon et réviser les notes. Vous savez quoi faire pour le reste!

BIBLIOGRAPHIE Collège Militaire Royal

3

Collège Militaire Royal

Les notes ont été mises à jour avec des articles et des livres courants. Notez toutefois que la date de la publication de l'article n'est en aucun cas une indication de la validité des propos. Livre de cours: [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994. Autres références: [Booc94] G. Booch, Object-Oriented Analysis and Design with Applications, The Benjamin/Cummings Publishing Company Inc. 1994, ISBN 0-8053-5340-2. [Came89] J. Cameron, JSP and JSD: The Jackson Approach to Software Development, Los Alamitos, Ca:IEEE Computer Press Society, 1989. [Clem92] A. Clements, MicroProcessor Design: 68000 Hardware, Software, and Interfacing, PWS-Kent, 1992, ISBN 0-534-92568-5. [DeMa78] T. DeMarco, Structured Analysis and System Specification, Englewood Cliffs, N.J.: Prentice Hall, 1978. [Dijk68] E.W. Dijkstra, Co-Operating Sequential Processes, Programming-Languages, F. Genuys, Ed. New York: Academic Press, 1968, pp. 43-112. [Fris97] A. Frisch, The Windows NT World View, SunExpert Magazine, September 1997. [Goma84] H. Gomaa, A Software Design Method for Real-Time Systems, Communications ACM, September 1984. [Goma93] H. Gomaa, Software Design Methods for Concurrent and Real-Time Systems, Addison Wesley, 1993. [Hala91] W.A. Halang and A.D. Stoyenko, Constructing Predictable Real-Time Systems, Kluwer Academic Publishers, 1991, ISBN 0-7923-9202-7. [Hala92] W.A. Halang, Real-Time Systems: Another Perspective, The Journal of Systems and Software, April 1992, pp. 101-108. [Hare87] D. Harel, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming, July 1987, pp. 231-274.

Collège Militaire Royal

4

Collège Militaire Royal

[Hatl88] D.J. Hatley et I.A. Pirbhai, Strategies for Real-Time System Specification, Dorset House Publishing Co., 1988. [Heni80] K.L Heninger, Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, Se-6, January 1980, pp. 2-13. [IEEE93] Software Engineering, IEEE Standards Collection, 1993 Edition [Kavi92] K.M. Kavi, Real-Time Systems Abstractions, Languages and Design Methodologies, IEEE Computer Society Press, 1992, ISBN 0-8186-3152-X [Labr92] J.J. Labrosse, µCOS The Real-Time Kernel, R&D Technical Books, 1992, ISBN 0-87930-444-8. [Labr95] J.J. Labrosse, Embedded Systems Building Blocks, R&D Technical Books, 1995, ISBN 0-87930-440-5. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. [Leve93] N.G. Leveson et C.S. Turner, An Investigation of the Therac-25 Accidents, IEEE Computer, 1993. [Liu86] Y Liu et C.A. Gibson, Microcomputer Systems: The 8086/8088 Family, Prentice Hall, 1986, ISBN 0-13-580499-X. [Obje97a] ObjecTime, ObjecTime RPL Guide, August 1997. [Obje97b] ObjecTime, MicroRTS Guide, March 1997. [Parn72] D.L. Parnas, On the Criteria to be Used in Decomposing Systems into Modules, Communications of the ACM, Vol. 15, No. 12, December 1972, pp. 1053-1058. [Parn74] D.L. Parnas, On a 'Buzzword', Hierarchical Structure, IFIP Congress 74, North Holland Publishing Company, 1974, pp.336-339. [Parn84] D.L. Parnas, Software Engineering Principles, INFOR Canadian Journal of Operations Research and Information Processing, Vol. 22, No. 4, November 1984. [Parn86] D.L. Parnas and P.C. Clements, A Rational Design Process: How and Why to Fake It, IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 251-257. [Pres92] R.S. Pressman, Software Engineering: A Practionner Approach Third Edition, McGraw-Hill, 1992.

Collège Militaire Royal

5

Collège Militaire Royal

[Rumb91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, "Object-Oriented Modelling and Design", Prentice Hall Inc, 1991, ISBN 0-13-629841-9. [Sanc90] J. Sanchez et M.P Canton, IBM Microcomputers: A Programmer's Handbook, McGraw Hill, 1990, ISBN 0-07-054594-4. [Smit86] J.T. Smith, The IBM PC AT Programmer's Guide, Brady, 1986, ISBN 0-89303-580-7. [Tane87] A.S. Tanenbaum, Operating Systems: Design and Implementation, Prentice-Hall, 1987, ISBN 0-13-637406-9. [Zave82] P. Zave, An Operational Approach to Requirements Specification for Embedded Systems, IEEE Transactions on Software Engineering, Vol. SE-8, No. 3, May 1982, pp. 250-269.

Collège Militaire Royal Département de Génie Électrique et Informatique

GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #1 Hiver 1999 Capt. J. Dolbec

INTRODUCTION À LA CONCEPTION DES SYSTÈMES EN TEMPS RÉEL

Objectif L'objectif de ce cours est de présenter la matière suivante:1. définition d'un système en temps réel; 2. application des systèmes en temps réel; 3. les cycles de développement du logiciel; 4. définitions de termes reliées à la conception;

Collège Militaire Royal

6

Collège Militaire Royal

5. évolution des méthodes de conception des logiciels; et 6. les systèmes en temps réel intégrés.

Matière 1. Définition d'un Système en Temps Réela. Définition: Plusieurs définitions sont disponibles mais aucune des définitions n'est acceptée universellement. En voici deux: i. "We can think of real-time systems as those that react to external inputs and in a timely manner affect the environment in which they operate." [Kavi92]; et ii. "The operating mode of a computer system in which the programs for the processing of data arriving from the outside are permanently ready, so that their results will be available within predetermined periods of time; the arrival times of the data can be randomly distributed or be already a priori determined on the different applications." [Hala92]. b. Le systèmes en temps réel sont souvent très complexes car ils doivent traiter plusieurs types d'entrées et produire plusieurs types de sorties. De plus, le traitement de ces signaux d'entrée et de sortie peut se faire simultanément.2. Application des Systèmes en Temps Réela. Les domaines d'application possibles pour les systèmes en temps réel sont nombreux. En voici quelques uns (Section 1.2 [Burn97]): i. le contrôle de procédés (Figure 1.2 [Burn97]); ii. lignes de production (Figure 1.3 [Burn97]); iii. communication, commandement, et contrôle (Figure 1.4 [Burn97]); et iv. les systèmes intégrés. b. Des exemples concrets de ces domaines d'application suivent: i. la central nucléaire de Darlington; ii. la suspension active dans les voitures; iii. le système d'avionique du CF-188 (distribué en temps réel); et iv. le Ground Collision Avoidance System (GCAS) du CC-130.3. Les Cycles de Développement du Logiciela. Cette section présente un résumé des principaux cycles de développement du logiciel. Le Modèle Classique ou Waterfall: a. Le modèle waterfall est souvent appelé le cycle classique de développement des logiciels. Ce modèle est typiquement composé de cinq phases: spécification des besoins, conception, programmation, tests, et maintenance. Si ce modèle est appliqué de façon non-itérative, il présente deux problèmes majeurs: i. la spécification des besoins du logiciel ne peut être adéquatement vérifiée avant que le système soit opérationnel; et

Collège Militaire Royal

7

Collège Militaire Royal

ii. un système opérationnel n'est disponible que tard dans le cycle de développement. Un problème majeur de performance peut donc être détecté très tard et, à ce moment, il est souvent impossible de le corriger pour des raisons financières, opérationnelles, etc... Le Throwaway Prototyping a. Ce genre de prototype est développé rapidement et à un coût minime au début d'un cycle de développement classique du logiciel pour clarifier les besoins des utilisateurs. Ce genre de prototype peut aussi être utilisé pour valider certaines parties du design. Cette approche aide à résoudre les problèmes de communication entre les utilisateurs et les concepteurs. Le Prototype Évolutif a. Cette approche est une forme de développement par incréments. Ce genre de développement vise à produire un prototype qui sera continuellement raffiné jusqu'à ce qu'il soit accepté par les utilisateurs. Cette approche peut aider à déterminer plus rapidement si un système va rencontrer les normes de performance requises. La Méthodologie ROOM a. La méthodologie ROOM (Real Time Object Oriented Modelling) est une méthode développée spécifiquement pour les besoins de conception des systèmes en temps réel. La philosophie ROOM est basée sur le développement évolutif de l'architecture d'un système en temps réel. b. La méthodologie ROOM possède une notation pour le développement de modèles de structure et du comportement de logiciel. Ces modèles sont évolués jusqu'à la phase de réalisation. Les modèles peuvent être exécutés à n'importe quel moment lors du développement sur la Machine Virtuelle de ROOM. Le code est généré à partir du modèle. Le code généré sera exécuté sur un Micro Run-Time System (MicroRTS) qui effectuera le lien avec le système d'exploitation sur la plate-forme d'exécution.4. Définition de Termes Reliés à la Conceptiona. "Une méthode de conception des logiciels est une approche systématique pour créer un design. Un méthode de conception décrit généralement des étapes à suivre pour créer un design. Une méthode de conception est basée sur un ensemble de principes de conception et documente un design en utilisant une ou plusieurs notations de conception." [Goma83] Par exemple, Real-Time Object Oriented Modelling (ROOM) est une méthode de conception des logiciels en temps réel.5. Évolution des Méthodes de Conception des Logiciels [Goma93]a. Dans les années 60, les programmes étaient réalisés avec très peu ou aucune considération pour l'analyse et la spécification des besoins et la conception. b. Les organigrammes (flowcharts) étaient l'instrument principal utilisé pour documenter les logiciels et pour planifier un design détaillé avant la phase de codage. c. Les sous-routines ou sous-procédures constituaient le moyen de choix pour décomposer un programme. A l'origine, elles furent créées pour qu'un bloc de code puissent être disponibles dans plusieurs parties d'un programme. Par la suite, les sous-routines ont été adoptées comme outil de gestion et utilisées pour construire des systèmes modulaires (programmation structurée).

Collège Militaire Royal

8

Collège Militaire Royal

d. Dans le début des années 70 et avec la popularité de la programmation structurée, les idées de top-down design comme le stepwise refinement ont été acceptées comme méthode de conception. Le stepwise refinement consiste a élaborer au cours de plusieurs itération des énoncés de fonction partant d'un haut niveau d'abstraction jusqu'au niveau du langage de programmation. e. Une des premières méthodes de conception de logiciel a été développée par Dijkstra [Dijk68] lors de la conception du système d'exploitation THE. Le document en référence est considéré comme un document classique du génie logiciel puisqu'il a introduit en premier les concepts de procédés simultanés et de l'utilisation des sémaphores pour la synchronisation des procédés. La méthode de conception présentée suggère qu'un logiciel peut être structuré en plusieurs niveaux ou les modules d'un niveau rendent des services aux modules de niveaux supérieurs. Le but de Dijkstra était de produire une méthode pour concevoir, programmer, et tester un système hiérarchique de façon systématique. f. Dans le milieu des années 70, deux nouvelles stratégies de conception sont apparues: la conception par flot de données (data flow oriented design) et la conception structurée des données (data structured design). g. La méthode de Conception Structurée (Structured Design) est basée sur les flots de données. Cette méthode est une des premières méthodes de conception bien documentée et suggère qu'une meilleure connaissance des fonctions d'un système peut être obtenue en considérant le flot de données à travers le système. Cette méthode propose donc une approche systématique pour développer des diagrammes de flot de données et pour ensuite les associer à des chartes structurées (structure charts) qui correspondent à la structure d'un programme (Figure 11.17 [Pres92]). Cette méthode met l'emphase sur la décomposition fonctionnelle en modules et la définition des interfaces des modules. La méthode de conception structurée a introduit les concepts de coupling et de cohésion pour évaluer la qualité d'un design. h. L'approche de conception structurée des données suggère d'étudier un problème en considérant les structures de données. L'emphase est donc mise sur la description des structures de données en premier. La structure du programme sera déterminée par après selon les structures de données. La méthode la plus populaire de ce genre est celle de Jackson [Came89]. j. Une des grandes contributions au problème de la conception du logiciel a été celle de Parnas et de son article sur le principe d'information hiding [Parn72]. Ce concept est une solution au problèmes créés par l'utilisation des données globales. Ce genre de données cause de nombreux problèmes mais principalement, rends les systèmes difficile à modifier. k. Au cours des années 80, les méthodes de conception des logiciels ont évoluées. Un des efforts les plus remarqués est le travail de Parnas sur l'avion A-7 en conjonction avec le Naval Research Laboratory (NRL) [Heni80]. Au cours de ce projet, Parnas a exploré l'utilité du principe d'information hiding sur la conception des systèmes à grande échelle. m. A partir des méthodes d'analyse structurée et de conception structurée, de nouvelles méthodes de conception ont été dérivées pour le développement de systèmes en temps réel: Real-Time Structured

Collège Militaire Royal

9

Collège Militaire Royal

Analysis and Design (RTSAD) [Hatl88] et Design Approach for Real-Time Systems (DARTS) [Goma84] (Figures 2.1 et 2.4 [Hatl88]). n. A la fin des années 80 et au début des années 90, la popularité du concept orienté objet a conduit à la création de nombreuses méthodes de conception basées sur ce concept [Booc94] [Rumb91]. Noter que pour créer un programme orienté objet, c'est à dire programmer de façon orienté objet, il n'est pas nécessaire d'avoir auparavant conduit une analyse des besoins et un phase de conception selon les principes orienté objet. p. Une des méthodes orienté objet qui se situe à la fine pointe de la technologie est la méthode Real-Time Object Oriented Modelling (ROOM) (Figures 4.25 et 4.37 [Seli94]). L'étude de cette méthode constitue la moitié de ce cours. Cette méthode est probablement ce qu'il y a de mieux présentement pour la conception des systèmes en temps réel.6. Les Systèmes en Temps Réel Intégrésa. Les systèmes en temps réel peuvent être classifiés comme étant intégrés (embedded) ou non. Les systèmes intégrés font partie d'un système plus large et satisfont une partie des besoins de ce système. b. Pour ce cours, toute référence à un système en temps réel est à ceux de type intégrés.

Références [Booc94] G. Booch, Object-Oriented Analysis and Design with Applications, The Benjamin/Cummings Publishing Company Inc. 1994, ISBN 0-8053-5340-2. [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Came89] J. Cameron, JSP and JSD: The Jackson Approach to Software Development, Los Alamitos, Ca:IEEE Computer Press Society, 1989. [Dijk68] E.W. Dijkstra, Co-Operating Sequential Processes, Programming-Languages, F. Genuys, Ed. New York: Academic Press, 1968, pp. 43-112. [Goma84] H. Gomaa, A Software Design Method for Real-Time Systems, Communications ACM, September 1984. [Goma93] H. Gomaa, Software Design Methods for Concurrent and Real-Time Systems, Addison Wesley, 1993. [Hatl88] D.J. Hatley et I.A. Pirbhai, Strategies for Real-Time System Specification, Dorset House Publishing Co., 1988. [Heni80] K.L Heninger, Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, Vol. SE-6, January 1980, pp. 2-13.

Collège Militaire Royal

10

Collège Militaire Royal

[Parn72] D.L. Parnas, On the Criteria to be Used in Decomposing Systems into Modules, Communications of the ACM, Vol. 15, No. 12, December 1972, pp. 1053-1058. [Parn84] D.L. Parnas, Software Engineering Principles, INFOR Canadian Journal of Operations Research and Information Processing, Vol. 22, No. 4, November 1984. [Parn86] D.L. Parnas and P.C. Clements, A Rational Design Process: How and Why to Fake It, IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 251-257. [Pres92] R.S. Pressman, Software Engineering: A Practionner Approach Third Edition, McGraw-Hill, 1992. [Rumb91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, Object-Oriented Modelling and Design, Prentice Hall Inc. 1991, ISBN 0-13-629841-9. [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Lecture Lire l'article [Parn86] et le chapitre 2 de [Burn97].

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #2 Hiver 1999 Capt. J. Dolbec

CARACTÉRISTIQUES DES SYSTÈMES EN TEMPS RÉEL (PARTIE 1)

Objectif Le but de cours est de présenter les caractéristiques des systèmes en temps réel [Seli94]:1. la réaction à temps;

Collège Militaire Royal

11

Collège Militaire Royal

2. la structure interne dynamique; et 3. la réactivité

Matière 1. La Réaction à Temps a. Cette caractéristique peut être définie selon deux intervalles de temps: i. Temps de Service Le temps de service est le temps net qu'un système prend pour calculer une réponse à un stimulus. Ce temps est principalement une fonction du programme et il peut donc être déterminé; et ii. Période de Latence La période de latence est la somme des délai entre l'occurrence d'une entrée au système et le temps ou le système répond, et entre la production de la réponse et le temps où la réponse est reçue. Ce temps est souvent une combinaison de plusieurs délais dans le système. La période de latence peut être variable ou fixe selon le contexte où le système est utilisé. b. Les systèmes en temps réel n'ont pas tous les même critères par rapport aux temps de réaction. Dans certains cas, certains systèmes doivent respecter les normes de temps d'exécution établies. Ces systèmes sont appelés hard real-time. Ces systèmes sont souvent des systèmes dont la sécurité des êtres humains en dépend comme les équipements médicaux ou les systèmes de contrôle des centrales nucléaires. Dans ce cours, l'emphase est mise sur ce type de systèmes. c. D'autres systèmes tolèrent que les limites de temps soient à l'occasion manquées. Ces systèmes sont appelés soft real-time. Par exemple, les systèmes de téléphone requiert qu'une tonalité soit présente après un certain temps lorsque l'utilisateur décroche l'acoustique. Cependant, le fait que la tonalité n'est pas entendu dans la limite de temps prescrite n'est pas catastrophique. Il faudra cependant que l'occurrence de ce genre d'événement ne dépasse pas une certaine limite. Pour les systèmes de type soft real-time, si les normes de temps ne sont pas rencontrées, on a une dégradation de la performance. Vérification des Normes de Temps a. Deux techniques existent présentement pour déterminer si un système rencontre ses normes d'exécution: i. les techniques analytiques: Ces techniques sont basées sur l'utilisation de méthodes formelles. On retrouve dans cette catégorie le Théorème de la Limite d'Utilisation, et le Théorème du Temps de Complétion; et ii. les techniques de simulation: Ces techniques sont basées sur la construction d'un modèle informatique exécutable à partir duquel il est possible d'extraire les caractéristiques de performance. Ces techniques ne peuvent donner des prédictions adéquates que dans un environnement prévisible.

Collège Militaire Royal

12

Collège Militaire Royal

2. La Structure Interne Dynamique a. La conception d'un système en temps réel peut se faire de façon à ce que le système soit en mesure de répondre à une situation d'opération extrême (maximum load). Ainsi donc, dans les pires circonstances, le système devrait pouvoir maintenir les normes de temps prescrites. b. Le gestion des ressources donne cependant naissance à de nouveaux problèmes. Un problème principal est la création et la destruction dynamique des composantes du système et des relations établies entre les composantes. Un problème se pose aussi en raison du temps d'exécution requis pour effectuer ce travail. c. Le besoin d'avoir une structure interne dynamique force les langages de modélisation comme ROOM a avoir la capacité de modeler ce type de système. La structure des modèles devra donc elle aussi être dynamique. 3. La Réactivité a. Les logiciels peuvent être classés comme étant des systèmes de transformation ou des systèmes réactifs. Les systèmes de transformation commencent leur exécution avec des données initiales qui sont par la suite transformées après une série de calculs pour produire les données de sortie désirées. b. Un système réactif est en général en interaction continuelle avec son environnement. L'environnement génère des stimulus captés par les interfaces d'entrée du système et le système réagit en changeant son état ou en générant des signaux aux interfaces de sortie. L'ordre et le temps des événements n'est pas toujours prévisible. 4. Exemples 1. Exemple 1.1 [Lapl93]. Le traitement de données pour ce logiciel sera effectué a différents taux. Comment peut-on réaliser cela? 2. Exemple 1.2 [Lapl93]. Quel mécanisme peut on utiliser pour que la deuxième interruption puisse interrompre tout autre tâche ou procédé?

Références [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #3

Collège Militaire Royal

13

Collège Militaire Royal

Hiver 1999 Capt. J. DolbecCARACTÉRISTIQUES DES SYSTÈMES

EN TEMPS RÉEL (PARTIE 2)

Objectif Le but de cours est de présenter les caractéristiques des systèmes en temps réel [Seli94]:1. la simultanéité; 2. la distribution; et 3. impact des caractéristiques sur la conception.

Matière 1. La Simultanéité a. La plupart des systèmes en temps réel sont de nature simultanée. Le développement de ces systèmes sera facilité avec l'utilisation de langages de programmation qui supportent la simultanéité. b. Par définition, chaque procédé (process) ou tâche (task) dans un système à son propre fil de contrôle. Le cycle de vie d'un procédé est illustré à la figure 7.1 [Burn97]. c. Les programmes en Pascal ou Fortran n'ont qu'un seul fil de contrôle. Les actions d'un fil de contrôle peuvent modifier l'état d'un système. Cette modification dépendra de l'état du système au moment ou l'action est initiée et le type de l'action. d. L'interaction entre les différent fils de contrôle est au c?ur de la difficulté des systèmes simultanés. Pour adresser le problèmes d'interaction entre les procédés, plusieurs techniques d'interaction ont été mise de l'avant. Parmi les formes d'interaction de base on retrouve:i. la synchronisation: La synchronisation permet de dicter l'ordre d'exécution des procédés. La synchronisation entre les procédés peut s'effectuer à l'aide de mémoire commune, et ou à l'aide de messages. Parmi les formes de synchronisation on retrouve les sémaphores, les event flags ou signaux; et ii. la communication: La communication entre les procédés est nécessaire pour permettre l'échange d'information. Elle peut s'effectuer à l'aide de mémoire commune, et/ou à l'aide de messages. Parmi les formes de communication on retrouve les variables globales et les mailboxes.e. Quand les deux formes d'interactions précédentes sont présentes entre des fils de contrôle, on parle de communications synchronisées. Lorsqu'il n'y a pas de synchronisation mais seulement de l'échange d'information, on parle de communications asynchrones. f. Noter qu'un scénario représente une combinaison de plusieurs fils de contrôle.2. La Distribution

Collège Militaire Royal

14

Collège Militaire Royal

a. Noter que la distribution peut être une caractéristique inhérente d'un système, par exemple les systèmes de téléphonie ou peut être créée pour des fins de fiabilité, d'efficacité, etc... b. Il existe plusieurs sources de difficultés dans la conception des systèmes distribués:i. la simultanéité; ii. les communications non-fiables (messages perdus, messages corrompus...); iii. les délais prolongés et variables; iv. les effets relativiste (Figure 2.6 [Seli94]); et v. la possibilité de défaillances dans le système.3. Impact des Caractéristiques sur la Conception a. Les caractéristiques des systèmes en temps réel imposent certaines contraintes particulières par rapport à leur conception. La conception des système en temps réel nécessite une attention particulière aux éléments suivants: i. la sélection judicieuse de matériel et de logiciel pour en arriver à une solution bien balancée entre le coût et la performance (Structure Dynamique); ii. la décision d'utiliser un système d'exploitation en temps réel commercial ou de créer son propre système d'exploitation (Simultanéité, Distribution, Structure Dynamique); iii. la maximisation de la tolérance au fautes (fault tolerance) et de la fiabilité à la suite de vérifications intensives et rigoureuses (Réactivité, Réaction à Temps); et iv. la conception, l'administration, et la sélection des tests et de l'équipement de développement (compilateurs, logiciels de vérification, etc...).4. Exemples a. Exemple Figure 14.1 [Burn97]. b. Exemple Figure 12.2 [Lapl93] c. Exemple du Système de Teinture [Seli94].

Références [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Collège Militaire Royal

Collège Militaire Royal

15

Collège Militaire Royal

Département de Génie Électrique et Informatique

GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #4 Hiver 1999 Capt. J. Dolbec

INTRODUCTION À ROOM (PARTIE 1)

Objectif Le but de cours est de présenter la matière suivante:1. introduction aux caractéristiques du langage ROOM; 2. l'approche opérationnelle; 3. l'élimination des discontinuités de développement; et 4. le concept orienté objet.

Matière 1. Introductiona. Le raison d'être du langage de modélisation ROOM est de faciliter le développement des systèmes en temps réel, et de permettre le développement de logiciels complexes et à grande échelle. Noter que ROOM a été développé initialement pour la spécification et la conception des systèmes de téléphonie.2. L'Approche Opérationnellea. Les personnes développant des logiciels ont tendance à être affectées par le syndrome rush-to-code. Cet état d'esprit est en partie le résultat du fait qu'ils désirent rapidement observer et exécuter un produit. Ce désire n'est évidemment pas satisfait par les méthodes traditionnelles de conception et d'analyse des besoins qui nécessitent la génération de plusieurs documents qui ne sont pas reliés au produit final en termes d'exécution. b. Reconnaissant la valeur de pouvoir observer l'opération d'un logiciel plus tôt dans le cycle de développement (prototypage), l'approche opérationnelle vise à produire des spécifications de besoins et des modèles de design qui ont une interprétation formelle et qui peuvent donc être exécutées comme un programme conventionnel. L'approche opérationnelle à pour origine la recherche de Pamela Zave qui a créé le langage exécutable de spécification des besoins PAISLey [Zave82].

Collège Militaire Royal

16

Collège Militaire Royal

c. Exemple: Le système de contrôle de teinture [Seli94] devra être en mesure de suivre les phases d'une dyeing run. Ces phases ou états sont par exemple la préparation, remplir le bain de teinture à la suite de la commande start, et l'état d'abandon à la suite d'une commande stop. Noter que les diagrammes de transition d'états ont l'avantage de présenter une notation graphique qui peut être facilement interprétée et qui permet d'observer l'exécution. Ceci est la raison pourquoi ROOM utilise une notation graphique pour la modélisation de haut niveau. Figure 3.5 [Seli94] montre le résultat de cinq séquences d'entrées différentes.3. Élimination des Discontinuités de Développementa. Le fait de créer des modèles différents du système désiré lors de l'analyse des besoins, de la conception, et de l'implémentation crée des discontinuités dans le cycle de développement du logiciel. Ceci vient principalement du fait que les notations utilisées à chaque étape du développement ne permettent pas une transition entre elles. b. Il existe aussi un problème de discontinuité sémantique lorsque différentes méthodes sont utilisées lors d'une même phase du développement. Par exemple, l'interprétation et l'identification des objet, états, ou fonctions du problème peut varier si on utilise des DFDs et des diagrammes de type Entity-Relationship (ER). c. L'approche de ROOM est détaillée à la figure 3.7 [Seli94]. L'interface de conception permet de créer et modifier des modèles à l'aide du langage de modélisation ROOM. Le modèle peut par la suite être exécuté en utilisant l'interface d'exécution (run-time interface). Cette interface permet entre autre de contrôler l'exécution, d'obtenir de l'information sur l'exécution, et de tracer les erreurs. Noter que la machine virtuelle de ROOM donne les services de base d'exécution au modèle (communication, synchronisation, et traitement des exceptions).4. Le Concept Orienté Objeta. Les êtres humains apprennent très tôt à reconnaître des objets. Nous apprenons que différents objets on différents comportements et différentes caractéristiques. L'utilisation du concept orienté objet nous est donc intuitive. b. Voici une définition d'un langage de programmation orienté objet: "A programming language that allows the user to express a program in terms of objects and messages between those objects." [IEEE93] c. Le concept orienté objet permet donc de réaliser un système en combinant plusieurs entités appelées objets. Ces objets ont le potentiel d'être réutilisés d'un système à l'autre permettent ainsi une diminution possible de l'effort requis lors du développement d'un système. Par exemple, un objet servant d'interface avec un utilisateur pourrait être réutilisé. d. Bien que le concept orienté objet ait été initialement développé pour les langages de programmation, au cours des dernières années, ce concept est maintenant appliqué au niveau de la conception et de la spécification des besoins du logiciel. Les Instances ou Objets

Collège Militaire Royal

17

Collège Militaire Royal

a. Du point de vue de la programmation, un objet est une collection de données et un ensemble de procédures. A ce niveau, ces objets sont considérés comme des abstract data types. L'abstraction d'un objet se concentre sur quoi révéler au monde extérieur. L'idée essentielle d'un abstract data type est de décrire une donnée non pas par sa structure interne, mais par son comportement observable. C'est une séparation de comment et du quoi. Les Classes de ROOM a. Il y a 3 types de classes avec ObjecTime: les acteurs, les protocoles, et les données passives (passive data objects). Toutes ces classes sont instantiées lors de l'exécution d'un modèle. Références [Booc94] G. Booch, Object-Oriented Analysis and Design with Applications, The Benjamin/Cummings Publishing Company Inc. 1994, ISBN 0-8053-5340-2. [IEEE93] Software Engineering, IEEE Standards Collection, 1993 Edition [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994. [Zave82] P. Zave, An Operational Approach to Requirements Specification for Embedded Systems, IEEE Transactions on Software Engineering, Vol. SE-8, No. 3, May 1982, pp. 250-269.

Lecture Lire le chapitre 3 de [Seli94].

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #5 Hiver 1999 Capt. J. Dolbec

INTRODUCTION A ROOM (PARTIE 2)

Objectif Collège Militaire Royal

18

Collège Militaire Royal

Le but de cours est de présenter la matière suivante:1. les niveaux d'abstraction; 2. les dimensions de modélisation; et 3. les langages de modélisation.

Matière 1. Introductiona. ROOM est un langage formel conçu pour être utilisé au travers de plusieurs phases du cycle de développement d'un logiciel. Pour cette raison, ROOM est basé sur de nombreux concepts et de nombreuses règles. b. Au fur et à mesure que ces concepts et règles seront présentés, il est probable qu'il sera difficile de les reliés les uns aux autres et de comprendre leur utilité. Pour cette raison, il est nécessaire de présenter, avant tout, des références auxquelles ces concepts et règles peuvent être reliés. c. Ces références ou principes de base sont pratiques pour déterminer l'utilité des concepts et des règles de ROOM ainsi que pour avoir un idée, dans ce cours, de la matière couverte et de ce qui reste à couvrir.2. Les Niveaux d'Abstractiona. La philosophie de ROOM est de séparer les concepts et la notation utilisés pour représenter différents niveaux de détails (levels of granularity or scopes) d'un logiciel. Ces niveaux de détails sont appelés niveaux d'abstraction. b. ROOM est organisé en nivaux d'abstraction ayant chacun leur propre notation et traitant chacun un domaine particulier. Présentement, ROOM couvre deux niveaux d'abstraction: le niveau détaillé (Detail Level) et le niveau schématique (Schematic Level). D'autres niveaux d'abstraction pourraient être ajoutés et leurs concepts existent déjà sous certaines forme. Par exemple, l'assembleur et les langages pour modeler le matériel (VHDL) appartiennent à des niveaux sous le niveau détaillé. c. Noter qu'en dépit de ces niveaux de séparation, les concepts de chaque niveau sont liés les uns aux autres de façon formelle. Ceci assure que pour tout modèle, les spécifications des niveaux inférieurs respectent les spécifications des niveaux supérieur.3. Les Dimensions de Modélisationa. Le modèle d'un système doit répondre aux deux questions suivantes: i. Quelles sont les composantes principales? ii. Comment fonctionne-t-il? Ces deux questions sont reliées puisque le fonctionnement d'un système est déterminé par l'interaction entre les composantes. La réponse à la première question donne la structure du système (statique). La réponse à la seconde question donne le comportement du système (dynamique). b. Une des caractéristiques principales du concept orienté objet (utilisé par ROOM) est l'existence d'un hiérarchie d'héritage entre les classes d'objets. A première vue, il serait tentant de traiter l'héritage comme étant un élément de la structure. Cependant, parce que le développement d'une classe d'héritage requiert une effort similaire au développement du comportement et de la structure, le principe d'héritage sera traité comme étant une troisième dimension de modélisation.4. Les

Collège Militaire Royal

19

Collège Militaire Royal

Langages de Modélisationa. La méthodologie ROOM est présentement réalisée sur l'outil ObjecTime. ObjecTime permet l'utilisation de deux langages de modélisation: i. RPL (Rapid Prototyping Language); et ii. C++.

Référence [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Lecture Lire le chapitre 5 de [Seli94].

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #6 Hiver 1999 Capt. J. DolbecMODÉLISATION DE LA STRUCTURE

DE HAUT NIVEAU - LES ACTEURS (PARTIE 1)

Objectif Le but de cours est de présenter la matière suivante:1. introduction à la modélisation de la structure; 2. les acteurs; 3. la coquille d'encapsulation des acteurs; 4. les composantes d'interface d'un acteur; et 5. la combinaison d'acteurs.

Matière 1. Introduction à la Modélisation de la Structurea. Lorsque l'on parle de la structure d'un système,

Collège Militaire Royal

20

Collège Militaire Royal

on parle de l'ensemble des entités qui composent le système et des relations entre ces entités. Avec ROOM, les deux formes de structure sont appliquées au niveau d'abstraction schématique. b. Noter que les structures de haut niveau définies avec ROOM peuvent être réutilisées. Ceci constitue un aspect très important de ROOM et représente une tendance technologique courante.2. Les Acteursa. Étant donné que ROOM est un langage de modélisation orienté objet, il est donc normal que les concepts de modélisation de ROOM soient basés sur un type d'objet. Le concept de l'objet acteur (actor) est utilisé par ROOM. b. On dit qu'un acteur est actif car il peut avoir son propre fil de contrôle et peut donc opérer simultanément avec d'autres objets actifs dans son domaine. c. Les acteurs sont intimement reliés aux données objet passives (passive data objects). Les données objet passives sont souvent utilisées comme variables d'état des acteurs. Les données d'état peuvent seulement être accédées par l'acteur qui l'encapsule. Donc, il n'y a pas de partage de données entre différents fils de contrôle. d. La notation graphique d'un acteur est un rectangle identifié avec un nom. Le nom doit être unique.3. La Coquille d'Encapsulation des Acteursa. Un acteur est l'abstraction d'une fonctionnalité quelconque. La coquille d'encapsulation d'un acteur (encapsulation shell) est opaque que ce soit de l'intérieur ou de l'extérieur. C'est à dire que la coquille cache la structure interne d'un acteur du monde extérieur et empêche aussi les composantes internes de l'acteur de pouvoir voir le monde extérieur. La coquille d'encapsulation correspond donc aussi au principe d'information hiding.4. Les Composantes d'Interface d'un Acteura. Pour communiquer avec d'autres entités dans son environnement, un acteur possède une ou plusieurs ouvertures ou interfaces dans sa coquille d'encapsulation. Les interfaces permettent l'échange d'information entre l'acteur et son environnement. Chaque interface est formellement définie pour identifier et s'assurer que seul l'information permise voyage au travers de l'interface. b. Les ports sont utilisés pour permettre la communication entre les acteurs d'une même couche. Les points d'accès de service et les points de provision de service permettent la communication entre les couches. c. Les ports sont représentés par des petits carrés sur le périmètre du rectangle des acteurs. Les ports sont tous identifiés par un nom unique correspondant à celui contenu dans la définition de l'acteur. Les ports conjugués sont représentés par un carré vide. Les ports non-conjugués sont représentés par des carrés pleins.5. La Combinaison d'Acteursa. La combinaison d'objets ou d'acteurs est au c?ur de la modélisation de la structure. La structure est une combinaison de parties qui sont connectées d'une façon déterminée. b. La combinaison est le procédé par lequel on crée une structure d'acteurs. La combinaison consiste à choisir quels éléments doivent être utilisés et à définir les relations entre ces éléments. Relations de Communication

Collège Militaire Royal

21

Collège Militaire Royal

a. Un port qui n'est pas attaché à un binding ne peut recevoir de messages. Cependant, des messages peuvent être envoyés par des ports qui ne sont pas attachés à un binding. Ces messages seront tout simplement perdus. b. La notation graphique d'un binding est une ligne continue qui connecte deux ports. Les bindings doivent être identifiés par un nom significatif. c. Noter que le mot contrat est utilisé pour identifier la combinaison de deux ports et du binding qui les relie. Structures Hiérarchiques et Relations de Contenu a. Dans plusieurs situations, il est utile de représenter une structure d'acteurs comme une seule unité conceptuelle qui fait partie d'un système plus grand. Ceci permet donc de faire abstraction des détails relatifs à une structure quelconque et de créer une hiérarchie. b. Pour réaliser des hiérarchies, ROOM utilise le concept d'acteur composite (composite actor). Les acteurs composite sont utilisés pour encapsuler des structures d'acteurs et sont donc à la base du procédé d'abstraction et de la création de structures hiérarchiques. c. Les acteurs composite peuvent être contenus dans d'autres acteurs composite. L'espace contenu dans la coquille d'encapsulation d'un acteur composite est appelée decomposition frame. Tous les acteurs qui apparaissent dans cet espace de décomposition sont appelés peer actors puisqu'ils sont au même niveau d'abstraction.

Référence [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Lecture Lire chapitre 6 de [Seli94].

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #7 Hiver 1999 Capt. J. Dolbec

Collège Militaire Royal

22

Collège Militaire Royal

MODÉLISATION DU COMPORTEMENT DE HAUT NIVEAU (PARTIE 1)

Objectif Le but de cours est de présenter la matière suivante:1. notation détaillée des ROOMcharts; et 2. les événements.

Matériel 1. Introductiona. Cette leçon présente la dimension du comportement au niveau schématique. Ce domaine est caractérisé par deux phénomènes complexes: la simultanéité et la distribution. b. Pour pouvoir être exécuté, un acteur a besoin d'un mécanisme pour envoyer et recevoir des messages, mettre à jour ses variables d'états, et modifier sa configuration. Cet ensemble de mécanismes est appelé le comportement de la classe d'acteur. c. Lorsqu'un acteur est en attente dans un état, il est prêt à recevoir et à traiter des événements externes. Les événements qui se produisent au ports des acteurs et qui ne force pas le changement d'état présent sont ignorés et détruits. d. A partir des ROOMcharts, il est possible de définir les méthodes ou fonctions associées avec les acteurs. On peut aussi accéder les SAPs/SPPs.2. Notation Détaillée des ROOMchartsa. Les éléments suivants font partie de la notation des ROOMcharts: i. le point initial; ii. la transition initiale; iii. le déclencheurs de transitions; iv. le code d'action d'entrée, de sortie, et de transition; v. les points de choix; et vi. les points de transition.3. Les Événementsa. Avec ROOM, on dit qu'un événement est généré lorsqu'un message est envoyé par un acteur au travers d'une de ses composantes d'interface. De plus, on dit qu'un événement à lieu (an event occurs) lorsqu'un acteur reçoit un message. b. Les événements générés à l'extérieur de l'environnement de ROOM et qui doivent être acheminés vers les acteurs sont traduits par la Machine Virtuelle de ROOM (MVR) et le MicroRTS et par la suite sont introduits dans l'environnement de ROOM au travers de SAP spéciaux.

Collège Militaire Royal

23

Collège Militaire Royal

c. Noter que la rapidité du service de livraison des messages est cependant un facteur de la qualité de service des couches de communication inférieures et du système de temporisation.

Références [Hare87] D. Harel, State charts: A Visual Formalism for Complex Systems, Science of Computer Programming, July 1987, pp. 231-274. [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Lecture Lire le chapitre 8 de [Seli94].

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #8 Hiver 1999 Capt. J. DolbecLE LANGAGE RPL

Objectif Le but de cours est de présenter les concepts reliés à l'utilisation du langage RPL:1. les règles du langage; 2. les classes de données; et 3. l'utilisation de fichiers.

Matière 1. Introductiona. Le langage RPL (Rapid Prototyping Language) est utilisé par ObjecTime pour permettre la création rapide de prototypes. RPL est un langage orienté objet. L'avantage de RPL est sa simplicité et le fait qu'il permet de déverminer plus facilement les modèles ROOM. b. On a demandé au vice-président de la recherche et du développement d'ObjecTime si les personnes utilisant ObjecTime préfèrent utiliser C++ au lieu d'ObjecTime lorsqu'il connaissent très

Collège Militaire Royal

24

Collège Militaire Royal

bien ObjecTime: "A lot of them do because they figure they will save time. There are two reasons behind this, one invalid, the other one not. The INVALID reason is their belief that the time spent on learning RPL is wasted: I will guarantee that it is not. Consider the fact that RPL compilation turnaround time is in the order of several seconds and for C++ it is a minimum of 40 seconds, but can often be much longer due to the more frequent need to recompile entire system (RPL is much less sensitive to change in this way). Also, let's face it: the error reporting and debugging facilities for RPL are much better than for C++ (this is changing somewhat in release 5.0.) If you are doing high-level modelling, trying to understand your problem, etc. you simply do not need the annoyance of low-level C++ errors, it's rather pedantic static type checking, memory management, etc. For those cases, I would estimate that it is 2-3 times faster to learn and use RPL compared to C++ (how does it appear in your courses?). The valid reason is that, if you go too far in modelling detailed data structures and code with RPL, then you will end up with a significant conversion effort. Hence, the trick is to determine when to abandon RPL and switch to C++. For something like the type of stuff that would be covered in your course, I would think imagine the use of RPL would be more efficient. That, however, ignores the cultural inertia factor which can be significant. If people feel that RPL is imposed on them, they may resist it and thereby fight it all the way. This is certainly not productive."2. Règles du Langage RPL a. La syntaxe du langage RPL est présentée en détail dans [Obje97a]. b. Voici quelques règles de syntaxe qui seront utiles:i. le mot clé new est utilisé pour créer une instance d'une classe; ii. les commentaires sont identifiés par des guillemets (") et tous les énoncés doivent être séparés par un point; iii. il existe une différence entre l'opérateur d'égalité (=) et l'opérateur d'identité (==); iv. il existe un ensemble de structures de contrôle de programmation de type IF, WHILE, et FOR; v. les noms définis par l'utilisateur sont case sensitive. Les mots clés du langage doivent être en majuscules. Par exemple: SEND outport SIGNAL réponse ENDSEND.vi. les déclarations suivantes peuvent être utilisées dans le code RPL: nil, true, false, $A (un caractère), 'xxxx' (une chaîne de caractères), et SignalName (nom du signal d'un protocole). vii. les variables locales sont identifiées par le symbole | et ne sont pas typées. Par exemple: | var1 var2 var3 |viii. l'opérateur d'assignation est :=; ix. les méthodes de classe sont invoquées à l'aide des énoncés SELF, SUPER, et CALLSUPER; et

Collège Militaire Royal

25

Collège Militaire Royal

x. l'énoncé de retour d'une fonction doit avoir la forme: ^ <expression>.3. Les Classes de Donnéesa. Avec RPL, il est possible d'utiliser des classes de données existantes ou de créer nos propre classes de données. Les instances de ces classes peuvent être utilisées pour représenter l'état des acteurs ou comme données à l'intérieur de messages. Les données sont des objets passifs a l'intérieur du modèle ROOM. b. Les classes numériques de base avec RPL sont: Integers, Real, Character, String, Boolean, et Null. On peut créer des classes dérivées de ces classes numériques à l'aide du Data Class Browser. c. Les classes définies par l'utilisateur sont aussi créées avec le Data Class Browser mais sont de type Enumerated, SequenceOf (arrays), Sequence (record), et Choice. Ces classes sont appelées constructeurs modifiables. d. Les types de données du système sont: RTActorId, RTMessage, RTByteBlock, RTPointer, RTTimespec, et Time. Le type RTMessage est très important car il représente un message envoyé entre deux acteurs. Le type RTMessage possède les attributs signal, priority, et data. e. Noter que le langage RPL possède aussi un ensemble de classes de Collection, de Streams, et d'accès de fichiers (Page 69 [Obje97a]).3. L'Utilisation de Fichiersa. L'accès aux fichiers est basé sur l'utilisation de streams. Avant d'accéder à un fichier il faut ouvrir un stream: filestream := 'UnFichier' asFilename rplWriteStream. Ceci crée un fichier nommé UnFichier dans le répertoire où ObjecTime a été exécuté. b. Pour lire un stream: filestream := 'UnFichier' asFilename rplReadStream. Noter que cette instruction va créer une erreur d'exécution si le fichier n'existe pas. c. Pour lire et écrire à un stream: filestream := 'UnFichier' asFilename rplReadWriteStream. d. Les fichiers doivent être fermés après utilisation: filestream rplClose. Références [Obje97a] ObjecTime, ObjecTime RPL Guide, August 1997.

Devoir Expliquer l'utilité et le fonctionnement des gardes. Envoyer votre explication ainsi qu'un simple modèle pour expliquer ces concepts par courrier électronique au professeur.

Collège Militaire Royal

Collège Militaire Royal

26

Collège Militaire Royal

Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #9 Hiver 1999 Capt. J. DolbecLES SERVICES DU RUN-TIME SYSTEM (RTS)

Objectif Le but de cours est de présenter les différents services disponibles par l'entremise du Run-Time System (RTS) d'ObjecTime:1. service de communication; 2. service d'enregistrement; 3. service temporel; 4. service de frame; et 5. service d'exception.

Matière 1. Introductiona. Les services présentés ci-dessous sont disponibles en RPL et en C++. Accès à ces services diffère évidemment du point de vue de la syntaxe selon le langage choisit (Figure 1 [Obje97b]).2. Service de Communicationa. Il existe une instance de la classe RTMessage appelée msg qui est prédéfinie dans chaque modèle et que l'on peut utiliser pour accéder le message qui active la transition d'état courante: i. msg data retourne la donnée du message; ii. msg priority retourne la priorité du message; et iii. msg sap retourne le port de terminaison où le message a été reçu. Noter que les priorités de messages disponibles avec ObjecTime sont: Panic, High, General, Low, et Background.3. Service d'Enregistrementa. Le RTS d'ObjecTime offre un service d'enregistrement d'information (Log). Pour utiliser ce service, il faut créer un SAP ayant comme protocole la classe Log. Log est un nom de protocole réservé pour la machine virtuelle de ROOM. b. Sous le menu de Protocol Class, choisir l'option Filter. Lorsque la nouvelle fenêtre apparaît, cocher l'option System Classes et tous les protocoles du système apparaîtront dans la fenêtre. Noter que ce type de menu existe aussi pour le menu des données passives.

Collège Militaire Royal

27

Collège Militaire Royal

c. Les méthodes suivantes s'appliquent à la classe RTLogSAP: open, close, log:, show:, space, cr, tab, crtab, crtab:, clear, et commit.4. Les Services Temporelsa. Il y a deux types de services temporels (Timing) disponibles avec ObjecTime: i. basic timing services qui supporte le temps réel. Classe RTTimerSAP; et ii. simulation timing service qui supporte le temps simulé. Classe RTSyncTimerSAP. Noter que la précision n'est pas garantie. Il n'est donc pas recommandé d'utiliser ces services pour l'implémentation des systèmes hard-real time. b. Pour utiliser les services temporels il faut créer un SAP avec un protocole de type Timing ou de type Simulation Timing. c. Les méthodes suivantes s'appliquent à cette la RTSyncTimerSAP et RTTimerSAP: informIn:, informAt:, cancelTimer:, id, delayFor:, and currentTime.5. Service de Framea. Ce service est utilisé pour créer des instances des acteurs de type optionnel. La syntaxe pour cette opération est: incarnate: Cette méthode retourne un RTActorId quand l'opération a été un succès ou nil. b. On peut détruire un acteur optionnel avec le même service: destroy: 6. Service d'Exceptiona. Ce service permet de définir des politiques pour le traitement des conditions d'exception. Il y a deux catégories principales d'exception: i. celles qui sont le résultat d'une erreur dans le design; ii. celles qui sont générées par le RTS pour des raisons de manque de ressources ou d'erreurs dans sa réalisation.

Références [Obje97a] ObjecTime, RPL User Guide & Reference, July 1995. [Obje97b] ObjecTime, MicroRTS Guide, March 1997.

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #10 Hiver 1999 Capt. J. DolbecMODÉLISATION DE LA STRUCTURE

DE HAUT NIVEAU - LES ACTEURS (PARTIE 2) Collège Militaire Royal

28

Collège Militaire Royal

Objectif Le but de cours est de présenter la matière suivante:1. la relation entre le comportement et la structure; 2. les messages; 3. les protocoles de ports; 4. les ports de relais; 5. les ports de terminaison; et 6. la duplication.

Matière 1. Relation entre Structure et Comportementa. Pour pouvoir être exécuté, un acteur a besoin de mécanismes pour envoyer et recevoir des messages, mettre à jour l'information qu'il encapsule, et modifier sa configuration. Cet ensemble de mécanismes est appelé comportement d'une classe d'acteurs. b. ROOM représente le comportement des acteurs à l'aide de ROOMcharts. Une ROOMchart est une représentation élaborée des diagrammes de transition d'états. Un état sur une ROOMchart représente une période de temps lors de laquelle l'acteur va faire certaines tâches ceci à la suite de l'occurrence d'un événement spécifique. c. Le comportement d'un acteur est représenté comme étant séparé de la structure mais est cependant une propriété de la structure. Le comportement d'un acteur est représenté sous forme d'une composante de comportement (behavior component) qui est optionnelle (Figure 6.15 [Seli94]). Le composante de comportement est un attribut de la classe qui le contient.2. Les Messagesa. La communication entre les acteurs est basée exclusivement sur l'envoi de messages. Ceci permet à l'expéditeur et le receveur d'être physiquement séparés et permet donc de modeler des systèmes distribués. La communication entre les acteurs peut être asynchrone ou synchronisée. b. Le type d'un message est déterminé par le signal et le type de la donnée (optionnelle). Le type de donnée null est utilisé quand le type de la donnée du message n'est pas connu.3. Les Protocoles de Portsa. L'ensemble des messages échangés entre deux acteurs aux travers de leurs ports respectifs est appelé protocole. Pour chaque protocole, on définit les message qui le compose ainsi que la direction et l'ordre relatif dans lequel les messages sont transmis et reçus. b. Une règle utile à suivre lorsque l'on définit les protocoles est de les définir à partir des clients et de les conjugués sur les serveurs. Ceci à l'effet de standardiser la définition des protocoles pour le système en son entier.

Collège Militaire Royal

29

Collège Militaire Royal

c. Textuellement, un protocole est définit comme suit: protocol class P: in: {{sig1, data-type1}{sig2, data-type2},...} out: {{sigm, data-typem}{sign, data-typen},...} d. Seul les ports avec des protocoles compatibles peuvent être reliés avec des bindings. Bien que les ports conjugués soient évidemment compatibles, la compatibilité est définie de façon plus générale. Deux ports sont considérés comme étant compatibles si les conditions suivantes sont vraies: i. pour chaque port, chaque type de message dans l'ensemble des messages de sortie d'un protocole de port fait partie de l'ensemble des messages d'entrée du protocole de port opposé. Ceci veut dire que chaque message de sortie pour n'importe quel port peut être reçu par le port opposé. Il est cependant possible qu'un port puisse recevoir des messages d'entrée additionnels qui ne sont pas disponibles dans l'ensemble des messages de sortie du port opposé; ii. les deux protocoles ont des séquences identiques; et iii. les deux protocoles ont des qualités de service équivalentes. e. Noter que la relation de compatibilité est transitive. Si protocole P1 est compatible avec P2, et protocole P2 est compatible avec P3, alors P1 est compatible avec P3.4. Les Ports de Relaisa. Les ports de relais (relay ports) apparaissent à l'extérieur des acteurs composite. Les ports de relais, comme leurs nom indique, relaient des messages aux acteurs contenus dans des acteurs composite et relaient aussi les messages de sortie venant des acteurs contenus. b. Noter que le protocole P associé à un port de relais est toujours définit par rapport au côté externe du port. C'est à dire que les messages d'entrée pour le port sont ceux qui voyagent vers l'intérieur de l'acteur composite. Sur le côté interne du port de relais, la polarité du protocole est inversée et donc, le côté interne d'un port de relais est le conjugué du côté externe. c. Il est donc maintenant possible de créer des acteurs qui exporteront n'importe quel type de fonctionnalité. Par exemple à la figure 6.13 de [Seli94], les fonctionnalités des acteurs S1 et S2 sont disponibles, simultanément si nécessaire, au monde extérieur par l'entremise de l'acteur composite qui les contient.5. Les ports de terminaisona. Les ports de terminaison (end ports) permettent d'indiquer la présence d'une composante de comportement dans l'acteur. Ces ports sont identifiés par un cercle à l'intérieur d'un carré (Figure 6.16 [Seli94]). b. La caractéristique principale de ces ports et que la composante de comportement peut directement leur faire référence. En fait, les ports de terminaison sont le lien entre la structure et le comportement puisqu'ils sont visibles dans les deux dimensions. Noter que les ports de relais ne sont visibles que dans la dimension de modélisation de la structure. c. Noter que les messages venant des ports de relais ne sont pas vus par la composante de comportement d'un acteur. Les ports de relais ne font que passer de l'information à un acteur contenu.6. La duplicationa. La duplication (replication) est utilisée pour indiquer que deux ou plusieurs acteurs jouent le même rôle. La duplication permet de simplifier la notation graphique.

Collège Militaire Royal

30

Collège Militaire Royal

b. Le facteur de duplication d'un acteur est représentée par un nombre dans le côté supérieur droit de l'acteur (Figure 6.30 [Seli94]). Le facteur de duplication d'un port n'est pas indiqué sur la notation graphique du port. Il est spécifié dans l'information textuelle qui complète la notation graphique du port. Cependant, la notation graphique du port comme telle est modifiée (Figure 6.31 [Seli94]).

Références [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #11 Hiver 1999 Capt. J. DolbecMODÉLISATION DU COMPORTEMENT

DE HAUT NIVEAU (PARTIE 2)

Objectif Le but de cours est de présenter la matière suivante:1. le traitement des événements; et 2. la temporisation et le queueing avec ROOM.

Matière 1. Traitement des Événementsa. Lorsqu'un message est reçu par un acteur, une réponse est souvent requise de la composante de comportement. Typiquement, cette réponse requiert certains calculs pour formuler une réponse appropriée et de l'envoie de un ou plusieurs messages. b. Le comportement alterne entre deux modes. Un mode d'écoute qui consiste à attendre pour le prochain messages et un mode occupé (busy) pendant lequel le comportement répond à un message (Figure 8.2 [Seli94]). c. ROOM utilise un combinaison de preemption et de run-to-completion. L'arrivée d'événements pour différents acteurs peut suspendre le traitement d'un événement par un autre acteur (Figure 8.3

Collège Militaire Royal

31

Collège Militaire Royal

[Seli94]). Ceci ne cause pas de problème car ROOM ne permet pas le partage de données par plusieurs acteurs. d. A l'intérieur d'un acteur, les événements de haute priorité ont une certaine précédence en terme de délais de livraison sur les événements de moindre priorité. La réponse aux événements à l'intérieur d'un acteur est cependant exécutée jusqu'à la complétion.2. La Temporisation et Queueing avec ROOMa. Avec ROOM, la temporisation (scheduling) des événements est effectué par la Machine Virtuelle de ROOM. Noter que pour les modèles distribués, le système de temporisation peut être réparti sur plusieurs plate-formes physiques. Chaque plate-forme aura donc son propre environnement local de temporisation. b. Le modèle run-to-completion pour le traitement des messages à l'intérieur des acteurs est utilisé par ROOM et requiert que chaque événement qui arrive doit attendre lorsque un événement antérieur est traité. Les événements doivent donc être mis dans des queues.

Références [Seli94] B. Selic, G. Gullekson, and P.T. Ward, Real Time Object Oriented Modelling, John Wiley & Sons, 1994.

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #12 Hiver 1999 Capt. J. DolbecRÉALISATION DES ACTEURS ET DU MicroRTS

Objectif Le but de cette leçon est de présenter les détails de réalisation reliés au MicroRTS d'ObjecTime et aux acteurs. La matière suivante est présentée:1. conception générale du MicroRTS; 2. composantes du MicroRTS; et 3. détails de réalisation d'un modèle.

Collège Militaire Royal

32

Collège Militaire Royal

Matiere 1. Conception Générale du MicroRTSa. Le MicroRTS qui exécute sur une plateforme UNIX est appelé EmulationRTS. Le MicroRTS qui exécute sur un système intégré avec un Système d'Exploitation en Temps Réel (RTOS) est appelé TargetRTS. Pour simplifier, on utilisera le nom TargetRTS. b. Le coeur du TargetRTS est un objet appelé contrôleur qui a pour responsabilité de recevoir, sauvegarder, et émettre les message générés par les acteurs. L'implémentation du contrôleur et des acteurs sera examinée. c. Pour les plateformes qui ne supportent pas les fils d'exécution multiples et pour le cas ci-dessus, il existe une version du targetRTS qui n'a qu'un seul fil d'exécution (Figure 4 [Obje97]). Cette version possède un seul objet contrôleur dans lequel la boucle principale du programme exécute. d. Pour les plateformes qui supportent les fils d'exécution multiples, chaque fil d'exécution possède son propre object contrôleur (Figure 5 [Obje97]). Chaque contrôleur contient les structures nécessaires pour traiter les messages et une boucle principale. e. Noter qu'ObjecTime permet d'assigner une priorité au fils d'execution donc permet un certain contrôle sur la temporisation. De plus, ObjecTime permet facilement l'exécution de modèles dans un environement distribué comme un réseau (Figure 6 [Obje97]).2. Composantes du MicroRTSa. On cherche ici a donner une description générale des composantes clé au coeur du TargetRTS. Ces composantes sont: i. les queues; ii. le gestionnaire de ressources (ResourceMgr); iii. le contrôleur; iv les références et les incarnations; v. les classes de données; et vi. les classes de fils d'exécution. b. Les messages sont sauvegardés dans des queues qui sont implémentées comme des listes chaînées. Il y a deux classes de queues: RTMessage (Figure 11 [Obje97]) et RTLayerSAP. Ces classes héritent de la classe abstraite RTQnode (Figure 10 [Obje97]). c. Le gestionnaire de ressources est de classe RTResoureMgr (Figure 12 [Obje97]) et est utilisé par les objets contrôleur pour réserver de la mémoire supplémentaire lorsque il n'ont plus de place pour sauvegarder les messages qu'ils recoivent. Le nombre de messages reçus pourra donc augmenter dynamiquement la limite étant la mémoire disponible (Figure 16 [Obje97]).

Collège Militaire Royal

33

Collège Militaire Royal

d. Chaque fil d'exécution dans ObjecTime possède un contrôleur. Le contrôleur contrôle le flôt d'exécution entre les acteurs. Le contrôleur crée l'illusion d'exécution simultanée en exécutant les transitions des acteurs de façon séquentielle. e. Le contrôleur doit être une instance d'une sous-classe de la classe abstraite RTControlleur (Figure 13 [Obje97]) qui elle hérite de la classe abstraite RTJob (Figure 14 [Obje97]). La classe RTJob implémente un diagramme de transition d'état qui représente la vie d'un fil d'exécution (Figure 15 [Obje95]). f. Exemple du cycle de vie d'un fil d'exécution: RTJob * job; // Polymorphisme Job = new RTSpecialJob(); // Classe dérivée quelconque ... job.waitUntil(RTJob:started); ...// mainLoop()... job.kill(); job.waitUntil(RTJob:killed); ... delete job; g. La classe RTControlleur contient plusieurs des définitions de méthodes importantes associées avec la traitement et la livraison de messages (Figure 16 [Obje97]). L'envoi et la livraison de messages à l'intérieur d'un fil d'exécution sont présentés sur les figures 17 et 18 de [Obje97]. h. Les figures 19 et 21 de [Obje97] présentent respectivement la structure de la classe RTPeerController et RTSoleController. Les mécanismes d'envoi et de réception de messages en environnement multi-tâche sont présentés à la figure 20 de [Obje97]. j. Le code de la méthode mainloop() pour la classe RTSoleControlleur est présenté à la page 26 de [Obje97]. k. Les références et les incarnations sont intimement reliées. Les objets références ont comme super-classe la classe RTReference (Figure 23 et 24 [Obje97]): i. une référence de port est de classe RTEndPortRef (Figure 29 [Obje97]) et maintient une liste des incarnations d'une classe de port (RTEndPort) (Figure 30 [Obje97]); et ii. une référence d'acteur est de classe RTActorRef (Figure 27 [Obje97]) et maintient une liste des

Collège Militaire Royal

34

Collège Militaire Royal

incarnations d'une classe d'acteurs (RTActor) (Figure 28 [Obje97]). m. Pour les implémentations multi-tâche, le TargetRTS utilise 3 classes de fils d'exécution: i. RTThread; ii. RTMutex; et iii. RTCondVar. n. Noter que les figures 31 et 32 de [Obje97] présentent respectivment les séquences d'initialisation pour les environements multi-tâche et ceux avec un seul fil d'exécution.3. Détails de Réalisation d'un Modèlea. Appendice A de [Obje97] présente un exemple du code généré pour un modèle très simple. Le modèle est présenté à la figure 36 de [Obje97].

Références [Obje97] ObjecTime, MicroRTS Guide, March 1997.

Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #13 Hiver 1998 Capt. J. DolbecLES LANGAGES DE PROGRAMMATION ETLES SYSTÈMES EN

TEMPS RÉEL (PARTIE 1) Objectif Le but de ce cours est d'identifier les caractéristiques des langages de programmation et l'impact de ces caractéristiques sur la programmation des systèmes en temps réel. La matière suivante est présentée: 1. caractéristiques des langages de programmation; et

2. caractéristiques désirables pour le développement de systèmes en temps réel. Matière 1. Caractéristiques Désirables des Langages de Programmationa. Lorsque l'on considère les caractéristiques générales des langages de programmation, il est souvent nécessaire de faire

Collège Militaire Royal

35

Collège Militaire Royal

la différence entre les caractéristiques qui contribuent à faciliter la décomposition et celles qui contribuent à créer des composantes logicielles bien définies. Ces deux ensembles de caractéristiques peuvent être identifiés respectivement comme étant: i. le support pour la programmation à grande échelle (programming in the large); et ii. le support pour la programmation à petite échelle (programming in the small). b. L'exemple suivant montre que FORTRAN n'est pas un langage avec une bonne syntaxe et donc il n'est pas robuste et n'est pas un langage de choix pour les systèmes en temps réel. L'utilisation du de ce langage a causé la perte du satellite américain Viking dans les années 1970: DO 20 I = 1 . 5 .... 20 CONTINUE L'erreur dans cet énoncé est que le point devrait être une virgule. Puisque FORTRAN ignore généralement les espaces et qu'une variable peut commencer par la lettre D, l'énoncé est interprété comme étant: DO20I = 1.5 L'énoncé ci-dessus est donc une assignation de variable. Noter que l'énoncé 20 CONTINUE ne cause pas d'erreurs. 2. Caractéristiques Désirables pour le Développement de Systèmes en Temps Réela. L'utilisation de mécanismes d'exception contribue à rendre les programmes plus robustes et fiables. La motivation initiale pour les exceptions vient de la nécessité de traiter les conditions anormales lors de l'exécution d'un programme. Le traitement d'exception aide aussi les programmes à tolérer les fautes qui ont pour cause des erreurs de conception. Finalement, les exceptions, permettent de réaliser un mécanisme général pour la détection et le traitement d'erreurs à l'intérieur d'un programme. b. La simultanéité est probablement la caractéristique la plus commune des systèmes en temps réel. Les langages de programmation en temps réel devraient donc permettre la définition de fils d'exécution/procédés et devraient posséder des mécanismes qui permettent la synchronisation de ces procédés. c. Un programme en temps réel doit non seulement être correcte mais doit aussi respecter les normes de temps qu'on impose sur son exécution. Un langage de programmation en temps réel doit donc pouvoir permettre l'analyse et la vérification des caractéristiques temporelles des programmes. d. Les systèmes en temps réel font souvent interface avec différents types de matériel. Pour cette raison, un langage de programmation en temps réel devrait avoir des mécanismes qui permettent l'accès facile au matériel. De plus, ces langages doivent posséder des moyens pour traiter directement les interruptions matérielles. e. Noter qu'il existe trois variantes des mécanismes d'interruptions: i. interrupt driven program controlled; ii. interrupt driven program initiated (DMA controlled); et iii. interrupt driven channel program controlled (comme un processeur autonome). f. Les caractéristiques secondaires suivantes sont aussi à considérer: i. allocation dynamique de la mémoire vs. vitesse; ii. des mécanismes d'envoi de paramètres efficaces vs. vitesse; et iii. le strong typing. L'utilisation du strong typing permet d'éviter que les variables soient tronquées ou arrondies et force le programmeur à être précis quant à la façon de manipuler les données. Noter que l'on a une perte de performance lorsque l'on Collège Militaire Royal

36

Collège Militaire Royal

tronque ou arrondi; et iv. le besoin d'être facile à comprendre et à maintenir est un critère nécessaire pour tous les langages de programmation. Un langage qui n'est pas trop complexe, qui est facile à lire et à modifier, permet de réduire les efforts et les coûts de maintenance. g. Finalement, noter que les langages de type interpreter sont plus lents que les langages qui effectuent la compilation avant l'exécution. Références [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Hala91] W.A. Halang and A.D. Stoyenko, Constructing Predictable Real-Time Systems, Kluwer Academic Publishers, 1991, ISBN 0-7923-9202-7. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #14 Hiver 1998 Capt. J. DolbecLES LANGAGES DE PROGRAMMATION ETLES SYSTÈMES EN

TEMPS RÉEL (PARTIE 2) Objectif

Le but de ce cours est d'identifier les caractéristiques des langages de programmation et l'impact de ces caractéristiques sur la programmation des systèmes en temps réel. La matière suivante est présentée: 1. les langages de programmation en temps réel. Matière 1. Les Langages de Programmation en Temps Réela. Plusieurs langages de programmation sont utilisés pour les systèmes en temps réel. La panoplie de langage s'étend de l'assembleur aux langages de haut niveau. b. Parmi les langages de haut niveau, on retrouve les langages commerciaux suivants: i. FORTRAN. Ces avantages sont la simplicité sa structure raisonnable. Ces désavantages sont l'absence de support pour l'analyse de temporisation, de mécanismes de traitement d'erreurs, de mécanismes multitâche, d'accès direct au matériel, et de modularité; ii. Ada. Ce langage est le résultat d'un besoin de standardisation du DOD aux États-Unis. Ada a l'avantage d'être un langage bien structuré, facile à lire, modulaire, strongly typed, qui permet la compilation séparée, qui permet l'accès direct au matériel, qui Collège Militaire Royal

37

Collège Militaire Royal

possède de bons mécanismes de traitement d'erreurs, et qui supporte le concept de procédés et de leur synchronisation au travers des rendez-vous. Le désavantage majeur d'Ada est qu'il soit un langage complexe qui requiert beaucoup de support d'exécution ce qui rend difficile la production de code efficace. De plus, Ada n'offre pas de support pour l'analyse de temporisation; et iii. C. Ce langage a l'avantage d'être structuré, facile à lire, modulaire, qui permet la compilation séparée, qui permet l'accès direct au matériel. C++ a l'avantage supplémentaire de posséder des mécanismes de traitement d'erreurs. C et C++ ne supportent cependant pas l'analyse de temporisation, le concept de procédés, et ne sont pas strongly typed. c. Le développement de systèmes en temps réel ayant des contraintes de temps strictes (hard real time) demande idéalement l'utilisation de langages de programmation spécialisés. Pour cette raison, on retrouve plusieurs les langages de haut niveau développés spécialement pour ce type de système. Parmi ces langages on retrouve TOMAL, DICON, ORE, FLEX, RTC++, et Real-Time Euclid. d. Real-Time Euclid (RT Euclid) respecte toutes les caractéristiques principales des langages de programmation. RT Euclid permet d'analyser un programme pour en assurer la temporisation. RT Euclid offre des services de traitement d'erreurs, la compilation séparée, est modulaire, bien structuré, et strongly typed. RT Euclid est cependant un langage purement expérimental pour lequel peu de données pratique existent. Critère /LangageAssembleurFortranAdaCRT

EuclidTemporisationNonNonNonNonOuiSécuritéNonNonOuiLimitéeOuiSimultanéitéNonNonOuiNon MatérielOuiNonOuiOuiOuiMaintenanceNonLimitéeOuiOuiProbablementEfficacitéOuiOuiLimitéeLim

Table 1 - Comparaison des Langages de ProgrammationRéférences

[Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Hala91] W.A. Halang and A.D. Stoyenko, Constructing Predictable Real-Time Systems, Kluwer Academic Publishers, 1991, ISBN 0-7923-9202-7. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #15 Hiver 1998

Collège Militaire Royal

38

Collège Militaire Royal

Capt. J. DolbecLES SYSTÈMES D'EXPLOITATION EN TEMPS RÉEL (PARTIE 1)

Objectif Le but de cette leçon est de présenter les concepts nécessaires pour permettre aux étudiants de construire leur propre système d'exploitation en temps réel (RTOS). La matière suivante est présentée: 1. les structures de systèmes d'exploitation; 2. les systèmes d'exploitation en temps réel; et 3. les méthodes de temporisation des procédés.Matière 1. Les Structures de Systèmes d'Exploitationa. Plusieurs architectures de systèmes d'exploitation qui ont été développées. En voici quatre: i. les systèmes monolithiques (Figure 1.8 [Tane92]); ii. les systèmes en couches (Figure 1.10 [Tane92]); iii. les machines virtuelles (Figure 1.11 [Tane92]); et

iv. les modèles clients-serveur (Figures 1.12 et 1.13 [Tane92]). 2. Les Systèmes d'Exploitation en Temps Réel a. Un système d'exploitation est utilisé pour faire l'interface entre les applications en temps réel et le matériel ou l'environnement. Bien que plusieurs systèmes d'exploitation commerciaux soient disponibles, ces systèmes d'exploitation sont souvent trop gros et trop généraux pour être utilisés efficacement avec des applications en temps réel qui sont intégrées (embedded) et qui ont des normes de temps d'exécution strictes. b. Souvent les concepteurs d'applications en temps réel doivent en fait concevoir leur propre système d'exploitation ou utiliser un système d'exploitation commercial spécialisé pour les applications en temps réel. c. Un noyau de système d'exploitation utilise des ressources du système: ROM, RAM, et du temps de CPU (2% à 4%). 3. Méthodes de Temporisation des Procédés a. Avec les noyaux à temporisation avec préemption, la temporisation des tâches est dictée par des interruptions matérielles ou logicielles. L'initiation des procédés est réalisée par les routines de traitement d'interruptions. b. Noter que les noyaux à préemption ne devrait pas permettre l'utilisation de code de type non-reentrant à mois que ce code ne soit protéger pas des sémaphores d'exclusion mutuelle. c. Pour maintenir la simultanéité avec les systèmes sans préemption, les tâches ont la responsabilité de retourner le contrôle au système d'exploitation. Cette approche est appelée Collège Militaire Royal

39

Collège Militaire Royal

cooperative multitasking. Le traitement d'interruptions dans ce contexte retourne toujours le contrôle à la tâche qui exécute. d. Dans les deux cas, selon le niveau de priorité et l'ordre d'arrivée, si applicable, le contrôleur d'interruption devra initier la routine d'interruption appropriée selon la valeur du vecteur d'interruption correspondant. Le contexte d'exécution présent devra être sauvegardé avant d'initier le contexte du prochain procédé. Cette opération est appelée changement de contexte (context switching). L'information de changement de contexte est traditionnellement sauvegardée sur une pile. e. Noter que l'assignation de priorité peut cependant créer des problèmes de service des tâches de priorité inférieur. Des problèmes appelés starvation apparaissent. On peut aussi avoir de problèmes d'inversion de priorité (ex: Mars PathFinder). La solution à ce dernier est d'augmenter la priorité des tâches de basse priorité qui retiennent des ressources. Références [Fris97] A. Frisch, The Windows NT World View, SunExpert Magazine, September 1997. [Labr95] J.J. Labrosse, Embedded Systems Building Blocks, R&D Technical Books, 1995, ISBN 0-87930-440-5. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. [Tane92] A. Tanenbaum, Modern Operating Systems, Prentice-Hall, ISBN 0-13-588187-0. Lecture Lire l'article [Fris97]. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #16 Hiver 1998 Capt. J. DolbecLES SYSTÈMES D'EXPLOITATION EN TEMPS RÉEL (PARTIE 2)

Collège Militaire Royal

40

Collège Militaire Royal

Objectif Le but de cette leçon est de présenter les concepts nécessaires pour permettre aux étudiants de construire leur propre système d'exploitation en temps réel (RTOS). La matière suivante est présentée: 1. les systèmes de type foreground/background; 2. exemples de méthodes de temporisation des noyaux; et 3. le traitement d'interruptions. Matière 1. Les Systèmes de Type Background/Foregrounda. Ces systèmes combinent la temporisation d'un groupe de procédés appelés foreground dont l'exécution est basée sur des interruptions et d'un second groupe de procédés appelés background qui exécutent dans une boucle infinie. b. Noter que les tâches de background ne pourront exécuter dans des situations de maximum load. 2. Exemples de Méthodes de Temporisation des Noyauxa. Voici une liste de différentes méthodes de temporisation des procédés: i. les systèmes de type polled loop; ii. les co-routines ou le cooperative multitasking; iii. les systèmes de type round-robin; et iv. les systèmes de type rate monotonic. Les Systèmes de Type Polled Loop a. Les noyaux de type polled loop sont les plus simples. Ces noyaux permettent une réponse rapide à des périphériques mais rien de plus. b. Une variation de ce type de noyaux est le noyau polled loop avec interruption. Ce type de noyau utilise une horloge à interruption fixe. L'interruption de l'horloge permet d'imposer un temps d'attente après que la condition ait été détectée comme étant vraie (utile pour les commutateurs). Les Co-routines ou le Cooperative Multitasking a. Certains programmes utilisent des énoncés de type if - else et switch ou des conditions d'états du programme (finite state automaton ou FSA) pour décomposer le traitement d'une fonction en segments. Cette séparation permet de suspendre l'exécution des procédés de façon temporaire sans perte de données critique. Ceci permet donc de créer un environnement de type multitâche. b. Exemples 6.4, 6.5, et 6.6 [Lapl93]. Les Systèmes Round-Robin a. Un système round-robin est un système à interruption où plusieurs procédés exécutent de façon séquentielle jusqu'à complétion ou par tranches de temps. b. Avec les systèmes round-robin with time slicing, on assigne à chaque procédé une période de temps pour exécuter. Le procédé exécute jusqu'à complétion ou jusqu'à ce que son temps d'exécution alloué se termine. Si la tâche n'est pas complétée, son contexte devra être sauvegardé (Figure 6.3 [Lapl93]). c. Noter qu'il existe plusieurs variation sur ce thème (FIFO, LIFO...). Collège Militaire Royal

41

Collège Militaire Royal

Les Systèmes de Type Rate Monotonic a. Les systèmes de type rate monotonic sont une classe spéciale des systèmes de type preemptive priority. Ce type de système est commun dans les applications intégrées comme les systèmes d'avionique (CF-188). b. Ce type de système est utile lorsque toutes les tâches ont des priorités et des périodes précises. Les tâches de haute fréquence auront les plus hautes priorités.3. Le Traitement d'Interruptionsa. Les interruptions sont un mécanisme matériel utilisé pour informer le microprocesseur qu'un événement c'est produit. Lorsqu'une interruption est reconnue par le CPU, le CPU sauve ces registres (en partie ou au complet) et exécute une routine de service d'interruption (ISR). Les interruptions permettent au microprocesseur de traiter les événements lorsqu'ils se produisent (pas de polling). b. La majorité des microprocesseurs sont en mesure d'ignorer ou de reconnaître des interruptions grâce à des instructions spéciales. Les systèmes en temps réel devraient le mois souvent possible ignorer les interruptions car ceci a pour effet d'augmenter la période de latence. c. Un des aspects les plus importants à spécifier pour un noyau de système en temps réel est le temps total pendant lequel les interruptions sont ignorées. Les systèmes en temps réels doivent ignorer les interruptions pour manipuler les sections critiques de code. Plus ce temps est long plus la période de latence sera longue. d. Noter que le temps d'exécution de la routine d'interruption (ISR) du noyau devrait être le plus court possible. Plus le temps des ISR est élevé, plus l'overhead sur le système sera grand. e. L'horloge (clock tick) est une interruption spéciale. L'horloge permet au noyau de retarder des tâches et de créer des timeouts pour les tâches qui attendent que des événements se produisent.Références [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #17 Hiver 1998 Capt. J. Dolbecµ COS (PARTIE 1)

Objectif Le but de cette leçon est de présenter la structure du noyau du µ COS de J. Labrosse. La matière suivante est présentée:

Collège Militaire Royal

42

Collège Militaire Royal 1. introduction au µ COS; 2. le modèle d'exécution de tâches du µ COS; 3. les blocs de contrôle de tâche; et 4. la temporisation. Matière 1. Introduction au µ COSa. Les caractéristiques générales du µ COS sont les suivantes: i. peut gérer 64 tâches; ii. préemption complète avec priorité. La tâche de plus haute priorité prête sera exécutée la première; iii. possède 63 niveaux de priorités de 0 (plus élevé) à 62; iii. spécification de grosseur de pile indépendante pour chaque procédé; iv. fourni des services de boîtes aux lettres, de sémaphores, et de fonctions temporelles; v. performance comparable à n'importe quel RTOS disponible commercialement; vi. les interruptions peuvent suspendre l'exécution des tâches; vii. 255 niveaux d'emboîtage d'interruptions; viii. les interruptions sont invalidées au maximum 500 cycles de CPU; ix. 200 cycles de CPU sont requis pour sauvegarder le contexte et avertir le µ COS que qu'une interruption est traitée; et x. le temps d'exécution de tous les services est déterministe. b. Le µ COS possède les limitations suivantes: i. les tâches qui exécutent sur le µ COS doivent avoir un numéro de priorité unique. Le µ COS ne peut donc pas faire de la temporisation de type round-robin; ii. des appels aux fonctions du µ COS ne peuvent être effectués dans la routine de service NMI car le µ COS doit pouvoir invalider les interruptions pour exécuter des sections critiques de code (la plupart des RTOS on cette limitation); et iii. le temps d'exécution requis pour traiter un tick d'horloge dépend du nombre de tâches mais est cependant déterministe. 2. Le Modèle d'Exécution de Tâchesdu µ COS a. Avec le µ COS, une tâche est une boucle infinie ou une fonction qui se détruit lorsqu'elle a fini d'exécuter. Cette tâche pourra être preempted par une interruption qui aura pour effet d'exécuter une tâche de plus haute priorité. Noter que le niveau de priorité de la tâche sert de numéro d'identification pour la tâche. b. L'état des tâches du µ COS est décrit à la figure 2.1 de [Labr92]. L'état DORMANT correspond à une tâche qui réside sur un EPROM et à laquelle le µ COS n'a pas encore accès. c. Les tâches peuvent toutes être interrompues à moins que la tâche ait invalidé les interruptions. L'ISR pourra mettre une ou plusieurs tâches à l'état prêt. Avant de retourner le l'ISR, le µ COS devra déterminer si la tâche interrompue est toujours la tâche de plus haute priorité prête à être exécutée. d. Si toutes les tâches sont en attente ou délayées, le µ COS exécute OSTaskIdle(). e. Les tâches peuvent être créées avant ou après l'appel de la fonction OSStart(). Si la tâche est créée après avoir engagé le mode multitâche, le temporisateur est appelé pour déterminer quelle est la tâche de plus haute priorité à exécuter. 3. Les Blocs de Contrôlede Tâchesa. Les Blocs de Contrôle de Tâche (TCBs) sont utilisés par le µ COS pour maintenir l'état des tâches lorsqu'elles sont interrompues. Tous les TCBs sont gardés en mémoire (Figure 2.2 de [Labr92]). b. La fonction OSTaskCreate() appellera la fonction OSTCBInit() (Figure 2.3 [Labr92]) qui assignera un nouveau TCB à la tâche. 4.La Temporisationa. La temporisation multitâche exécute toujours la tâche de priorité prête à exécuter. Cette responsabilité appartient à la fonction OSSched(). b. Chaque tâche prête à exécuter est placée dans une liste qui contient deux variables: OSRdyGrp et Collège Militaire Royal

43

Collège Militaire Royal

OSRdyTbl[8] (Figure 2.4 [Labr92]). c. Tout le code dans OSSched() est considéré critique. Lorsque OSSched() trouve une tâche de plus haute priorité prête à exécuter, la macro OS_TASK_SW() est utilisée. Pour le x86, OS_TASK_SW() défini une instruction de type INT qui est vectorisée à l'ISR OSCtxSw. Cette instruction est appelée ucos et est définie au début du programme. d. Noter que le code de OSSched() aurait put être écrit en assembleur ceci pour réduire le temps de temporisation. Il a cependant été écrit en C pour avoir un code portable, facile à lire, et pour minimiser le code en assembleur. Références [Labr92] J.J. Labrosse, µCOS The Real-Time Kernel, R&D Technical Books, 1992, ISBN 0-87930-444-8. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #18 Hiver 1998 Capt. J. DolbecCOMMUNICATION ET SYNCHRONISATIONDES PROCÉDÉS EN

TEMPS RÉEL (PARTIE 1) Objectif Le but de cette leçon est de présenter la matière suivante:

1. l'exclusion mutuelle et la synchronisation avec condition; et

2. les variables partagées.Matière 1. Introductiona. Des difficultés majeures apparaissent donc lorsque l'on a des procédés simultanés qui interagissent. Le comportement correct d'un programme simultané dépendra donc des mécanismes de la synchronisation et communication entre les procédés du système d'exploitation. b. La synchronisation est la satisfaction des contraintes des actions concurrentes initiées par des procédés. La synchronisation a rapport avec l'état des procédés. La communication est l'échange d'information entre les procédés. c. Ces deux concepts sont reliés car la communication requiert de la synchronisation, et la synchronisation peut être Collège Militaire Royal

44

Collège Militaire Royal

considérée comme une forme de communication. d. La communication et la synchronisation entre les procédés est basée sur deux approches: i. l'utilisation de variables partagées (shared variables); et/ou ii. l'envoi de messages (message passing). 2. L'Exclusion Mutuelle et La Synchronisation avec Condition a. Considérer l'énoncé: x = x + 1. Sur la plupart des machines, cet énoncé ne sera pas exécuté comme une action indivisible (atomique). Cet énoncé sera exécuté comme trois opérations distinctes. Dans un environnement simultané, si la variable x est globale, cet énoncé présente un danger. b. Exemple: un système de type producer-consumer comme l'utilisation d'un tampon (buffer) pour l'échange de données. Noter que dans certains cas ce type de mécanisme d'échange peut être plus efficace que l'envoi de messages. Une condition de synchronisation (pour un tampon limité) serait d'empêcher le procédé qui produit les données de déposer d'autres données lorsque le tampon est plein. 3. Les Variables Partagées a. Plusieurs variantes basées sur les variables partagées existent pour permettre la synchronisation et la communication des procédés: i. le busy waiting; ii. le suspend and resume; iii. les sémaphores; iv. les conditions critical regions (CCR); v. les moniteurs; et

vi. les objets protégés. b. L'utilisation de sémaphores est une méthode développée par Dijkstra [Dijk65]. Cette méthode requiert l'utilisation d'une variable spéciale appelée sémaphore et de deux opérations possibles sur cette variable appelées semaphore primitives. c. Traditionnellement, l'opération d'attente est dénotée P(S), et la seconde opération est dénotée par V(S). Exemples 7.4 et 7.5 [Lapl93]. d. Les mécanismes iv à vi ont été développés pour contrer les problèmes introduits par l'utilisatio de sémaphores. Ces trois mécanismes sont supportés au niveau de certains langages de programmation. e. Le problème principale des CCRs est qu'ils sont typiquement dispersés au travers du programme. Les moniteurs corrigent ce problème en permettant d'encapsuler les section critiques de code à l'intérieur d'un seul module appelé moniteur. L'exécution des procédures du minteurs sera toujours effectuée en condition d'exclusion mutuelle. Références [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. Collège Militaire Royal

45

Collège Militaire Royal

[Dijk65] Dijkstra E. W., Co-operating Sequential Process, Technical Report EWD-123, Eindhoven, Netherlands, 1965. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6.

Lecture Lire le chapitre 8 de [Burn97]. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #19 Hiver 1998 Capt. J. DolbecCOMMUNICATION ET SYNCHRONISATIONDES PROCÉDÉS EN

TEMPS RÉEL (PARTIE 2) Objectif Le but de cette leçon est de présenter la matière suivante: 1. l'envoi de messages; 2. les boîtes aux lettres. Matière 1. L'Envoi de Messagesa. L'alternative à l'utilisation de variables partagées pour la synchronisation et la communication est l'envoi de messages. L'envoi de messages est supporté par certains langages de programmation. Il existe une grande variété de mécanismes d'envoi de messages. Cette diversité découle de trois facteurs: i. le modèle de synchronisation; ii. les méthode de process naming; et iii. la structure des messages. b. Avec l'envoi de messages, il existe une synchronisation implicite: le receveur ne peut obtenir un message avant que ce dernier n'ait été envoyé. Bien que ce fait soit trivial, il doit être comparé avec l'utilisation de variables partagées. c. Noter qu'il est possible d'avoir des communications asynchrones dans un environnement synchrone en créant des procédés tampons. Cependant, l'utilisation excessive de ces tampons peut avoir des effets indésirables sur la performance d'un système. d. Deux aspects importants doivent être traités lorsque l'on parle du process naming: i. la direction vs. l'indirection; et ii. la symétrie. e. Dans un modèle direct, le nom du récepteur est explicitement nommé. Dans un modèle indirect, l'émetteur nomme une entité intermédiaire typiquement appelée un canal, une boîte aux lettres, un link port, ou une pipe. f. Le process naming est symétrique si les procédés se Collège Militaire Royal

46

Collège Militaire Royal

nomment directement ou indirectement. Le procédé est asymétrique si le récepteur ne spécifie aucune source mais accepte les messages de tous les procédés ou boîtes aux lettres. g. Idéalement un langage de programmation devrait permettre d'envoyer n'importe quel objet de donnée de n'importe quel type. 2. Les Boîtesaux Lettresa. Les boîtes aux lettres sont souvent utilisées comme mécanisme de communication entre les tâches avec plusieurs systèmes d'exploitation commerciaux. b. L'opération d'écriture dans une boite aux lettres est appelée post operation et l'opération de lecture est appelée pend operation. La différence entre une opération de type pendet une opération de type polled est qu'avec l'opération pend l'exécution du procédé est suspendue. On ne perd donc pas de temps à continuellement vérifier si les données sont arrivées. c. Les boîtes aux lettres sont réalisées facilement à l'aide de tables de ressources. Exemple, tables 7.1, et 7.2 [Lapl93]. Certains systèmes d'exploitation supportent l'utilisation de boites aux lettres qui peuvent empiler plusieurs demandes de type pend. Ces systèmes auront typiquement des opérations de type qpend et qpost. Références [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. [Dijk65] Dijkstra E. W., Co-operating Sequential Process, Technical Report EWD-123, Eindhoven, Netherlands, 1965. [Lapl93] P.A. Laplante, Real-Time Systems Design and Analysis, IEEE Press, 1993, ISBN 0-7803-04444-6. Lecture Lire le chapitre 9 de [Burn97]. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #20 Hiver 1998 Capt. J. DolbecLA TEMPORISATION DESSYSTÈMES EN TEMPS RÉEL (PARTIE 1)

Objectif Collège Militaire Royal

47

Collège Militaire Royal

Cette leçon présente les concepts reliés à l'analyse de la performance des logiciels en temps réel. La matière suivante est présentée:

1. introduction aux modèles de temporisation; 2. modèle de procédé simple; 3. la temporisation basée sur le modèle d'exécutif cyclique; 4. la temporisation basée sur les tâches; et

5. la temporisation de type rate montonic. Matière 1. Introduction aux Modèles de Temporisationa. L'analyse de la temporisation des systèmes est particulièrement importante pour les systèmes de type hard real-time. Les modèles visent principalement à déterminer si un groupe de tâches rencontre ses normes de temps d'exécution. b. Les modèles de temporisation ont deux caractéristiques principales: i. un algorithme pour ordonner l'utilisation des ressources du système (en particulier le CPU); et ii. un moyen de prédire le comportement worst-case du système lorsque l'on applique l'algorithme de temporisation. Les prédictions générées seront utilisées pour confirmer que les exigences temporelles du système seront rencontrées. c. Le problème associé avec les modèles dynamiques est le coût requis pour développer le modèle. Cependant ce type de modèle donne la meilleure précision et le meilleur détail. Il faut de plus atteindre une balance entre la vitesse de simulation et son degré de réalisme. D'autres problèmes reliés sont la validation et les méthodes pour calibrer ces modèles avec le vrai monde. 2. Modèle de Procédé Simplea. Un programme en temps réel complexe quelconque ne peut être facilement analysé pour prédire son pire comportement d'exécution. Il est donc nécessaire d'imposer certaines restrictions sur la structure de ces programmes. b. Un modèle de base ayant les caractéristiques suivantes sera donc utilisé: i. l'application consiste en un nombre fixe de tâches; ii. tous les procédés sont périodiques avec un période connue; iii. les procédés sont indépendants l'un de l'autre; iv. les temps d'overhead du système comme le changement de contexte seront ignorés donc égales à zéro; v. tous les systèmes doivent compléter avant la fin de leur période; et vi. tous les procédés ont un temps d'exécution worst case définit. c. Noter que la table 13.1 de [Burn97] présente une notation standard pour l'ensemble des caractéristiques des procédés. 3. La Temporisation Basée sur le Modèle d'Exécutif Cycliquea. Si l'on a un ensemble de tâches purement périodiques, il est possible de dériver une cédule complète d'exécution qui permettra de garantir que chaque procédé exécutera en temps. Cette approche est appelée exécutif cyclique (cyclic executive). b. Exemple: Figure 13.1 et table 13.2 de [Burn97]. 4. La Temporisation Basée sur les Tâchesa. Collège Militaire Royal

48

Collège Militaire Royal

L'approche de l'exécutif cyclique ne préserve pas la notion d'un procédé. L'alternative est de supporter directement la notion d'un procédé en assumant qu'ils peuvent exécuter à n'importe quel moment selon leur priorité. Cette approche est évidemment la norme pour les systèmes d'exploitation. b. Les procédés en état exécutable seront exécutés selon leur priorité. La priorité d'un procédé sera déterminée par ses besoins temporels non par sa fonction. 5. La Temporisation de Type Rate Monotonica. Le premier algorithme de temporisation des tâches périodiques a été développé par Liu et est appelé Rate Monotonic Analysis (RMA). Cette théorie sera présentée car elle constitue la base de la compréhension pour les autres algorithmes plus avancés. b. A des fins de notation, on considère une tâche périodique de période T qui a un temps d'exécution C. Son temps d'utilisation du CPU sera dénoté par le rapport C/T. Une tâche sera temporisée si son deadline est rencontrée. Un groupe de tâches peut être temporisé si tous les deadlines sont rencontrés. c. Exemple: T=2 sec et C=200ms => C = 0.1 Théorème 1 - Utilization Bound Theorem a. Selon la théorie de temporisation RMA, un groupe de n tâches indépendantes rencontreront toujours leurs deadline si la somme des rapports C/T est en dessous d'un nombre limite supérieur représentant d'utilisation totale du CPU. b. L'Utilization Bound Theorem (Théorème 1) est présenté à l'équation 13.1 de [Burn97]. c. Si la valeur de l'utilisation totale des tâches est supérieure à la limite U(n), on ne peut pas garantir que les tâches vont rencontrer leur deadline et on doit donc se référer à un autre théorème. Des recherches effectuées, on cependant démontrer que pour un nombre de tâches ayant des paramètres arbitraires, la limite supérieur est de 88%. d. Exemples pages 405 à 407 de [Burn97]. Références [ Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X. Collège Militaire Royal Département de Génie Électrique et Informatique GEF499B Systèmes en Temps Réel Intégrés Notes de Cours #21 Hiver 1998 Capt. J. DolbecLA TEMPORISATION DESSYSTÈMES EN TEMPS RÉEL (PARTIE 2)

Objectif La matière suivante est présentée: 1. le completion time theorem; 2. la temporisation des tâches apériodiques; et Collège Militaire Royal

49

Collège Militaire Royal

3. le generalized utilization bound theorem. Matière 1. Le Completion Time Theorem a. Puisque l'application du théorème de l'Utilization Bound ne nous permet pas de garantir avec certitude qu'un ensemble de tâches pourra être temporisé, il faut trouver d'autres alternatives. Le completion time theorem est une extension de la théorie développée par Liu et vise à adresser ce problème. b. Pour le procédé de plus haute priorité, le pire temps de réponse sera égal à son temps de calcul, c'est à dire: R = C. Les procédés de moindre priorité seront sujets à de l'interférence de la part des procédés de plus haute priorité. En général, pour un procédé i: Ri = Ci + Ii où Ii est l'interférence maximale d'un procédé i à n'importe quel temps dans l'intervalle [t, t+Ri). c. En partant de la pire situation d'exécution lorsque tous les procédés doivent commencer en même temps, il sera possible de vérifier pour chaque procédé s'ils complètent leur exécution à temps. d. [Burn97] donne une description du développement du théorème de complétion à la section 13.5. Le développement de ce procédé se fait selon les étapes suivantes: i. détermination pour une tâche i du nombre d'exécution d'un procédé j de plus haute priorité à l'intérieur de sa période; ii. détermination de temps maximum d'interférence du procédé i par la tâche j; iii. détermination du temps total d'interférence de toutes les tâches de plus haute priorité que la tâche i; et iv. résolution de l'équation de type fixed-point. e. A l'équation 13.4 de [Burn97], on observe que les valeurs de wi vont augmenter de façon monotone. Lorsque les deux termes avec w sont égaux, l'équation est résolue. Noter que n est une valeur qui est utilisée pour résoudre l'équation récursive (correspond plus ou moins à la période). 2. La Temporisation des TâchesApériodiques a. Si la période d'une tâche apériodique est connue, la tâche peut être temporisée comme une tâche périodique. 3. Le Generalized Utilization Bound Theorem a. Avec un système réel, les hypothèses de la théorie rate monotonic ne sont pas toujours valides. Deux cas retiennent notre attention: i. une tâche apériodique peut être traitée comme une interruption. Cette tâche devra être exécutée immédiatement lorsque l'interruption se présente même si sa période est supérieure au procédé qui exécute; et ii. une tâche de priorité supérieure peut être bloquée par une tâche de priorité inférieure. b. Il est possible de modifier le théorème de l'utilization bound pour traiter cette situation. Le nouveau théorème est appelé generalized utilization bound theorem. Références [Burn97] A. Burns and A. Weelings, Real Time Systems and Programming Languages, Addison-Wesley, 1997, ISBN 0-201-40365-X.

Collège Militaire Royal

50