CHAPITRE 1 Introduction -...

avril 29, 2009

GIF-3003 Systèmes parallèles et temps réel 1

CHAPITRE 1 Introduction

Les systèmes parallèles et temps réel (SPTR) sont des systèmes numériques programmables intégrantdes modules avancés au niveau du matériel et du logiciel.

Ils sont interfacés au monde réel et sont utilisés dans des applications complexes pour lesquelles lesspécifications sont nombreuses et exigeantes.

Un de leurs aspects spécifiques est donc un besoin de traitement informatique intense, performant, enpartie “intelligent”, et soumis à des contraintes dynamiques.

Les trois thèmes principaux du cours sont reliés aux aspects fondamentaux et techniques de cessystèmes intelligents en interaction avec un environnement dynamique: les architectures et letraitement parallèles, le traitement en temps réel, et la fiabilité et la tolérance aux fautes.

Dans les SPTR, ces trois thèmes sont intimement interreliés autant au niveau du matériel que dulogiciel.

Par exemple, les SPTR ont typiquement de nombreuses contraintes de temps réel sévères et doiventdonc s’exécuter sur du matériel performant et fiable.

On utilise alors des architectures de calcul avancées de type multiprocesseurs, en parallèle oudistribués, dans lesquelles les différents éléments de traitement communiquent au moyen d’un réseaud’interconnexion pour échanger des données, se synchroniser et collaborer à la réalisation desapplications complexes.

1.1 Développement d’un SPTR

De façon générale, le processus de développement d’un système peut être vu comme la recherched’une solution à un problème. Ce problème est défini par les exigences du système à développer: desbesoins à satisfaire, à l’aide des ressources disponibles, en respectant des contraintes imposées.

Dans le domaine du génie informatique en général et des SPTR en particulier, la solution ouapplication comportera généralement deux parties principales: l’architecture (matériel et logicielsystème) et le logiciel d’application (algorithme et code).

PROBLÈME SOLUTION

architecturelogiciel

d’application

matériel etlogiciel système

algorithmeet code

exigences

besoins, contraintes, ressources

Figure 1.1 Processus de développement d’un système


Méthodologies et objectif Robert Bergevin (c)

Une solution à un problème correspond à une alternative, c’est-à-dire à une suite de choix oudécisions qui sont pris pour satisfaire les besoins, en général le mieux possible i.e. en faisant certainscompromis, et ce dans le respect des contraintes.

Lorsque le processus de développement se limite à la conception du système, la solution est plus oumoins détaillée et elle consiste en un modèle plus ou moins général du système à réaliser. Parexemple, on peut définir formellement, dans un langage approprié, l’architecture matérielle dusystème et l’algorithme de traitement des données qui sera utilisé.

Il y a deux approches principales pour le développement d’un système. La première est une approchequi part des exigences de l’application sans égard aux ressources disponibles. C’est une approche quidéfinira la solution en allant du général au particulier (“top-down”): modèle général de la solutionpuis division en modules de plus en plus détaillés jusqu’à l’implantation ou réalisation.

La seconde approche part plutôt des ressources disponibles et de leurs limitations précises. C’est uneapproche qui définira la solution en allant du particulier au général (“bottom-up”): modèle détaillé descaractéristiques et possibilités des modules mis en jeu dans l’implantation puis intégration de cesmodules en un système complet.

En pratique, le développement d’un SPTR empruntera simultanément aux deux approches dans unprocessus itératif. Par exemple, le système pourra d’abord être défini par un modèle très général (voirmodèle SPTR plus loin) tandis que certaines parties de la solution détaillée pourront être fixées par lesexigences du problème, par exemple l’architecture pourra être imposée par les ressources disponibles.

1.2 Méthodologies et objectif

Le développement et la mise en oeuvre d’un SPTR nécessite en pratique une coordination des effortsdes différents membres d’une équipe et l’utilisation de méthodologies avancées combinant, entreautres, une approche intégrée de design et des outils informatiques d’aide à la conception.

Ainsi, de nombreuses méthodes ont été proposées et des outils et environnements de développementmatériel et logiciel basés sur ces méthodes sont maintenant disponibles commercialement.

L’étude et l’expérimentation d’une ou plusieurs de ces méthodes se fera plus naturellement en milieude travail ou dans un cours spécifiquement dédié au design et à la réalisation de projets.

Dans le cadre de ce cours, notre objectif consistera plus simplement à présenter et analyser diversprincipes fondamentaux et concepts techniques qui sont communs aux différents types de SPTR.

Ces principes et concepts seront présentés dans un contexte de développement intégré et enconsidérant autant les aspects matériels que les aspects logiciels de ces systèmes.

1.3 Historique des SPTR

Voyons d’abord les grandes étapes ayant conduit à l’étude et au développement des SPTR et qui sontillustrées à la figure suivante, que l’on doit examiner en allant du haut vers le bas.


Historique des SPTR Robert Bergevin (c)

Les premiers ordinateurs utilisés à grande échelle étaient basés sur un modèle de traitementséquentiel avec un processeur unique. Ce modèle, toujours le plus commun, s’est ensuite affiné avecl’introduction de logiciels d’exploitation plus évolués, particulièrement pour permettre le traitementsimultané de plusieurs applications en partageant le temps de calcul disponible.

Ces premiers ordinateurs étaient fabriqués à partir de composantes discrètes, d’abord des relaisélectromécaniques puis des tubes et enfin des transistors. La majeure partie des applications réaliséesà l’aide de ces ordinateurs (branche de droite de la figure) utilisaient un modèle de système trèssimple: réception en entrée d’un ensemble de données structurées, traitement de ces données d’unemanière prédéterminée et le plus rapidement possible puis transmission du résultat de ces traitementsà la sortie.

Le développement des circuits intégrés et de la micro-électronique a permis d’augmenter laperformance des ordinateurs pour ces applications et de créer ainsi les premiers superordinateurs.Ceux-ci étaient utilisés dans les calculs scientifiques de plus en plus complexes où la quantité dedonnées manipulées était de plus en plus grande, d’où le besoin d’améliorer la performance.

Étant donné le marché relativement restreint des ordinateurs scientifiques, gouvernementaux oucorporatifs, et dans le but d’assurer leur rentabilité face à des coûts de développement toujourscroissants (en 1997, on parlait déjà d’investissements de 1 milliard de dollars US pour une usine defabrication de circuits VLSI à la fine pointe de la technologie), les compagnies de micro-électroniqueont ensuite visé à développer des marchés de masse.

Ceux-ci correspondaient en particulier aux systèmes embarqués ou dédiés (branche de gauche de lafigure), i.e. aux ordinateurs utilisés pour réaliser des fonctions de contrôle et de calcul dans unsystème plus vaste. On retrouva rapidement ces systèmes dans les produits d’électronique de

superordinateurssystèmes embarqués

systèmes en temps réel ordinateurs parallèles

ordinateurs séquentiels

Figure 1.2 Historique des SPTR

systèmes parallèles et temps réel


Historique des SPTR Robert Bergevin (c)

consommation, l’automobile, les télécommunications, l’instrumentation, les produitsd’automatisation, etc.

Face à tous ces nouveaux besoins, le domaine de l’informatique en général, autant du côté matérielque du côté logiciel, a ensuite évolué rapidement, que ce soit au niveau académique ou de recherchequ’au niveau industriel.

Cette croissance a permis, entre autres, le développement de systèmes embarqués dans desapplications de plus grande complexité i.e. traitant sur la base de contraintes diverses et nombreuses,des données d’une plus grande variabilité et donc moins structurées. De plus, ces applicationscomportaient souvent une composante dynamique beaucoup plus importante et exigeante, nécessitantainsi des systèmes en temps réel pour lesquels la ponctualité des résultats est mise sur un piedd’égalité avec la vitesse et l’exactitude du traitement.

Ce nouveau besoin influa à son tour sur le développement de nouveaux circuits spécialisés pour lessystèmes embarqués comme le microcontrôleurs, les processeurs de traitement de signal, les circuitsd’interface, etc., de même que sur la définition de normes pour l’intégration de ces systèmes, parexemple les bus d’interconnexion de modules.

Le besoin toujours croissant de performance, en particulier pour les applications structurées, ainsi quela limite technologique entrevue sur le modèle séquentiel, mena ensuite au regroupement de plusieursprocesseurs pour former des ordinateurs parallèles, parfois intégrés sur des bus d’interconnexion oureliés en réseau, donnant lieu au domaine de l’informatique distribuée.

Cette nouvelle évolution des systèmes informatiques a été rendue possible, entre autres, parl’augmentation régulière de la performance des microprocesseurs, par la baisse de leurs ratio prix/puissance, dimensions, poids et consommation d’énergie.

Allié aux besoins plus grands en flexibilité et fiabilité des systèmes en temps réels qui s’attaquaient àdes applications de plus en plus exigeantes et complexes et à l’importance de plus en plus grandeprises par les réseaux informatiques, ce nouveau domaine s’est aussi développé rapidement.

Ainsi, avec la disponibilité de ressources matérielles et logicielles de plus en plus sophistiquées, il estmaintenant possible de considérer de façon intégrée les systèmes ou applications diverses réunissantles deux branches de la figure et qui forment ce que nous appelons les SPTR.

Dans la suite, lorsque le SPTR étudié sera propre à la branche de droite de la figure, nous parleronsd’une application structurée. Inversement, lorsqu’il aura plus d’affinités avec la branche de gauche,nous dirons que l’application visée est non-structurée.

D’une façon générale, les applications d’intérêt seront non-structurées à la base mais elles pourrontcomporter une partie qui est structurée, par exemple un module spécialisé pour le calcul rapide defonctions particulières.


Modèle général des SPTR Robert Bergevin (c)

1.4 Modèle général des SPTR

D’un point de vue général, les SPTR peuvent être vus comme des systèmes numériques complexes decommande et de contrôle.

La figure ci-dessous donne un vue schématique d’un modèle général des SPTR, que nous appelleronssimplement le modèle SPTR.

Remarquons d’abord que ces systèmes sont intimement couplés à l’environnement. En ce sens, cesont donc des systèmes embarqués. Cependant, cet environnement n’est pas limité à des mécanismesou à des procédés. Il peut aussi inclure un environnement ouvert, aux limites physiques non définies,incluant d’autres systèmes et personnes avec lesquels le système peut interagir.

C’est le cas, par exemple pour un véhicule robotisé autonome qui utilise la vision numérique pour sedéplacer dans des environnements complexes, à l’intérieur ou à l’extérieur, et qui peut rencontrerd’autres véhicules ou des personnes.

Dans ce cas précis, la perception consiste à faire l’acquisition d’images de l’environnement, letraitement consiste à les analyser pour en comprendre le contenu et l’action peut consister, parexemple, à se déplacer pour éviter certains obstacles, à changer l’orientation des caméras de prise devue, à reconnaître des personnes et interagir avec elles ou à saisir et déplacer des objets.

On voit donc que ces actions peuvent avoir une influence autant sur le système lui-même que surl’environnement dans lequel il évolue. C’est pourquoi on remarque dans le diagramme un module derétroaction interne au système et un deuxième couplage de la sortie sur l’entrée par l’intermédiaire del’environnement.

Dans ces systèmes, le traitement est souvent varié et complexe et peut donc nécessiter desarchitectures matérielles avancées, par exemple des ordinateurs parallèles. Comme on l’a dit, unepartie de ce traitement peut être structurée. En fait, le modèle SPTR peut même s’appliquerdirectement, dans son ensemble, aux SPTR structurés. Dans ce cas, l’environnement représente lasource et la destination des données traitées.

perception traitement action

environnement

rétroaction

Figure 1.3 Modèle SPTR



Aussi, même si un seul bloc est utilisé pour représenter chacun des modules de perception, detraitement et d’action et que ces blocs sont dans une boucle unique, la réalisation d’un SPTR impliquegénéralement du matériel distribué, reproduit en plusieurs exemplaires, parfois hétérogène, ainsi quedu traitement parallèle avec des contraintes temporelles variées. Par ailleurs, autant le système quel’environnement ont des composantes dynamiques.

Dans l’exemple donné plus haut, le véhicule autonome se déplace, ses caméras peuvent changerd’orientation et des objets (autres véhicules, personnes) peuvent être mobiles (ou déplacés) dansl’environnement.

Les modules de perception, de traitement et d’action ont donc souvent à faire face à des contraintestemporelles, ce qui fait que ces systèmes doivent fonctionner en temps réel.

Finalement, on peut mentionner que ces systèmes sont souvent critiques et doivent donc fonctionneren continu, sur de longues périodes et être fiables et tolérants aux fautes.

1.4.1 Architecture matérielle des SPTR

Une représentation schématique de l’architecture matérielle d’un SPTR est donnée à la figure ci-dessous.

On a dit plus haut qu’un SPTR était un système embarqué, au sens large, avec des propriétésparticulières résultant de la complexité des domaines d’application, comme par exemple le traitementen temps réel, le parallélisme et la tolérance aux fautes.

Il est aussi à noter que dans les SPTR, l’utilisateur est considéré partie intégrante de l’environnement.

De plus, le système multiprocesseur ou distribué, qui est le coeur et la tête du SPTR, sera parfois relié,localement ou à distance, à d’autres systèmes numériques. Ce sont les aspects logiciels et matériels dece système que nous étudierons plus particulièrement dans les chapitres qui suivent, laissantgénéralement de côté les éléments d’interface avec l’environnement.

Interfaces “personne-machine”: écran, clavier, palonnier,

capteurs

actuateurs

conditionnement

du signal d’entrée

conditionnement du signal de sortie

processus externe “contrôlé”

(DAC)de sortieinterface

interfaced’entrée

(ADC)multiprocesseur

état

contrôle

microphone, haut-parleur, interface haptique, lunettes 3D, etc.

Figure 1.4 Architecture matérielle d’un SPTR

utilisateur

système

ou distribué



1.4.2 Exemples de SPTR

Le modèle général présenté ci-dessus s’applique presque sans distinction à tous les domainesd’application avancés en ingénierie1.

Pour ce faire, il s’agit de déterminer ce que sont les différents modules de perception, de traitement etd’action, ainsi que l’environnement du système, dans chaque cas.

La liste suivante donne divers domaines d’application où ce modèle s’applique bien:

• commande de procédés industriels;

• production automatisée intégrée et flexible;

• commande de mécanismes divers;

• robotique intelligente et vision artificielle;

• surveillance et reconnaissance automatisée;

• avionique et aérospatiale;

• exploration sous-marine;

• réseaux de télécommunication numériques avec ou sans fil;

• véhicules automobiles et autres véhicules autonomes ou assistés;

• système d’accès à des bases de données distribuées;

• traitement distribué de transactions et commerce électronique;

• systèmes experts et de prise de décision;

• télémanipulation et téléopération;

• télé-conférences et télé-apprentissage;

• multimédia et réalité virtuelle ou augmentée;

• jeux vidéo interactifs;

• gestion du trafic terrestre et aérien;

• acquisition de données distribuée;

• imagerie médicale et monitorage;

• simulation distribuée et intervention assistée.

À titre d’exemple, le système informatique embarqué d’un véhicule automobile peut être vu commeun SPTR.

En effet, l’automobile, par l’entremise de ce système informatique, est en interaction avec unenvironnement dynamique et complexe (réseau routier et conducteur) et elle comporte plusieurs sous-systèmes embarqués ayant des fonctions diverses et qui doivent fonctionner de façon partiellementautonome.

1. Il s’applique aussi, par analogie, à plusieurs domaines non techniques.



Parmi les sous-systèmes informatisés actuels et futurs de l’automobile, [Mullender] cite:

• le contrôle dynamique du véhicule (moteur, transmission, freins, vitesse decroisière, suspension, traction, direction).

• l’aide à la perception (éclairage visible et ultra-violet, télémétrie radarcourte-distance, alerte).

• les systèmes d’information du conducteur (circulation, navigation,reconnaissance des panneaux routiers, tableau de bord électronique).

• les fonctions de confort du conducteur (climatisation et chauffage,verrouillage central, contrôle des fenêtres, sièges, miroirs, etc., systèmesanti-vol).

Le concept des autoroutes intelligentes va encore plus loin en considérant les différents systèmescontrôlant l’ensemble du réseau routier, incluant les axes routiers, les véhicules, la signalisation, etc.,comme un seul SPTR qui doit être développé pour maximiser le débit des véhicules, réduire lenombre d’accidents et la consommation globale d’énergie, etc.

On voit donc qu’un SPTR, e.g. celui d’un réseau routier intelligent, peut être une structurehiérarchique où chaque élément, e.g. les systèmes informatisés des véhicules automobiles, est aussiun SPTR. Une partie du contrôle est globale (pour optimiser l’ensemble du réseau routier) et unepartie est locale (pour optimiser chaque véhicule).

Étude Déterminer ce que sont les différents modules de perception, de traitementet d’action, ainsi que l’environnement du système pour les domaines d’application quivous intéressent plus particulièrement dans la liste donnée ci-dessus.

1.4.3 Exemple en vision robotique

Un exemple de SPTR tiré du domaine de la vision robotique est présenté schématiquement à la figureci-dessous. Ce système contrôle un bras robotisé et des caméras pour faire le suivi et la saisie entemps réel d’un objet en mouvement. Ce type de système pourrait être utilisé, par exemple, dans uneapplication spatiale pour intercepter des objets en orbite.

Dans ce système, la perception se fait au moyen de deux types de caméras. Le premier type est unecaméra vidéo qui offre une bonne rapidité d’acquisition et un bon champ de vision mais uneinformation plus difficile à interpréter. Le second type est une caméra télémétrique qui offre unchamp de vision plus restreint, une acquisition plus lente, mais une information plus facile àinterpréter pour la tâche de suivi et de saisie.

L’objet en mouvement et le déplacement de la caméra 3D représentent les aspects dynamiquesprincipaux du système.

La prise d’images au moyen des caméras des deux types se fait à des périodes et phases différentes, cequi introduit aussi des contraintes temporelles.



Le traitement se fait sur un système multiprocesseur ou distribué pour gérer plus simplement ladiversité et la complexité des calculs ainsi que la distribution spatiale et temporelle des données enentrée et en sortie.

Sans aller plus à fond dans les détails de réalisation de ce système, il est quand même possibled’examiner les étapes principales de son fonctionnement et de se convaincre qu’il se conforme bel etbien au modèle SPTR.

1.4.3.1 Étapes de fonctionnement du système

Le système fonctionne en régime cyclique comportant trois phases séquentielles, répétées à tour derôle, ayant toutes une ou plusieurs composantes de perception, de traitement et/ou d’action.

Dans la phase 1, l’objet doit être reconnu par le système. Ceci implique que l’on détectera l’objet lorsde son passage et que l’on déterminera sa position approximative dans l’espace à une fréquencesuffisamment rapide et de façon continue i.e. en temps réel.

La phase 1 comporte les étapes suivantes. D’abord obtenir une ou plusieurs images 2D de la scène i.e.de l’environnement par où doit passer l’objet. Ensuite, détecter un objet mobile dans la scène puisdéterminer son identité et sa trajectoire (position et orientation à intervalles réguliers).

Dans la phase 2, l’objet doit être “suivi des yeux” par le système. Pour ce faire, il faut d’aborddéplacer le bras robotisé selon la trajectoire estimée. Ensuite, il faut orienter la caméra 3D selon laposition estimée. Lorsque la caméra est bien orientée pour placer l’objet dans son champ de vision defaçon automatique, il faut obtenir une image télémétrique de l’objet. Des traitements permettent alorsd’estimer la position et l’orientation précise (la pose) de l’objet dans l’espace. Finalement, le systèmepeut estimer la trajectoire de l’objet en fonction des poses calculées dans plusieurs cycles consécutifs.

Dans la phase 3, l’objet doit être saisi par le préhenseur (pince) qui se trouve à l’extrémité du brasrobotisé. Il faut d’abord orienter le préhenseur selon la pose estimée. Ensuite, il suffit d’actionner lepréhenseur et de valider la saisie de l’objet.

CAMÉRA 3D

ROBOT 6 ddl

OBJET

CAMÉRAS 2D

Figure 1.5 Exemple tiré du domaine de la vision robotique



Ainsi, la phase 1 comporte une étape de perception suivie de trois étapes de traitement. La phase 2débute par deux étapes d’action qui sont suivies d’une étape de perception et de deux étapes detraitement. Quant à la phase 3, elle comporte deux étapes d’action suivies d’une étape de traitement.

Les étapes de chaque phase se font parfois simultanément, ou du moins en chevauchement partiel.

Par ailleurs, la quantité de données à traiter est importante, les contraintes de temps sont sévères et lacomplexité du traitement est considérable.

En pratique, un tel système fonctionnerait en continu, par exemple en déposant l’objet après la saisiepour ensuite répéter les trois phases pour le prochain objet passant dans l’espace de travail du robot.

Selon le type d’environnement dans lequel un tel système est utilisé, par exemple en usine ou dansl’espace, les contraintes de fiabilité et de tolérance aux fautes pourraient être soit légères, moyennesou sévères.

Étude Trouver une application possible d’un tel système de vision robotique etessayer d’identifier les principales difficultés techniques associées à chacune desétapes mentionnées auparavant.

1.4.4 Caractéristiques recherchées

Sur la base de différents exemples examinés, on peut conclure que les caractéristiques recherchéespour les SPTR se résument aux points suivants: robustesse (données bruitées), fiabilité (tolérance auxfautes), flexibilité (conditions imprévues), performance (rapidité) et ponctualité (ajustement auxconditions réelles).

Le système doit faire preuve de robustesse face aux bruits d’acquisition (perception) et d’actuation(action) et aux erreurs de traitement, de fiabilité face aux enjeux environnementaux, humains, ouéconomiques, et de flexibilité face à la variabilité des exigences et des situations et aux bris possibles.

Plus précisément, les choix de conception doivent assurer une dégradation lente des performances etde la fonctionnalité du système face aux événements internes et externes imprévus et aux erreurs deperception, de traitement et d’action.

De plus, il est important de pouvoir maintenir le système et le mettre à jour lorsque les besoinschangent ou augmentent.

Le système doit aussi être performant et ponctuel pour fonctionner en synchronisme avec lesprocessus externes, à l’entrée (perception) et à la sortie (action). Pour ce faire, le traitement doitgénéralement être rapide.

Ce sont ces caractéristiques qui incitent à développer les SPTR sur la base d’architectures parallèleset/ou distribuées (réparties) et du traitement en temps réel.

Étude Déterminer en quoi ces caractéristiques sont importantes dans le cas del’application que vous avez choisie ci-dessus.


Exercices à faire Robert Bergevin (c)

1.4.5 Autres modèles similaires proposés

Le modèle général des SPTR présenté ci-dessus s’intéresse aux systèmes parallèles et temps réel entant que partie intégrante d’applications d’ingénierie complexes.

Un autre modèle basé sur les applications est le modèle universel BMR du traitement parallèleprésenté dans [Lawson]. Ce dernier suggère que les applications complexes soient décomposées enfonction d’un modèle de comportement (donc dynamique) puis traduites en termes de processus degranularité variable qui sont ensuite distribués sur des architectures parallèles.

Ce modèle, quoique similaire au modèle SPTR par son emphase sur les applications avancées ayantune composante dynamique et utilisant le traitement parallèle, diffère sur un point important par sonabsence de toute relation explicite à l’environnement et à l’interfaçage ou couplage du système à cetenvironnement.

On peut aussi citer, à l’appui du modèle SPTR, le concept de “produit intelligent” tiré de [Mullender]qui est défini ainsi (traduction libre): “un système en temps réel autonome qui réalise un service outâche spécifique pour ses utilisateurs. Ce produit intelligent consiste en un sous-système mécanique,des capteurs, des actuateurs, un sous-système de contrôle et une interface utilisateur simple”.

Un produit intelligent est donc défini sur les mêmes bases qu’un SPTR. Comme dans le modèleSPTR, l’utilisateur fait partie de l’environnement. Ainsi, la perception inclut la lecture de commandesde l’utilisateur au moyen d’une interface appropriée, tandis que l’action comprend aussi laprésentation, aussi au moyen d’une interface appropriée, des résultats du traitement.

Étude Un domaine technique pluridisciplinaire en croissance rapide depuisquelques années est la mécatronique. Déterminer en quoi ce domaine s’apparente eten quoi il diffère du concept de produit intelligent ou du modèle SPTR.

1.5 Exercices à faire

Q1.1 à Q1.3.

1.6 Les trois thèmes du cours

Comme on l’a mentionné, les trois thèmes principaux du cours sont liés aux caractéristiquesidentifiées pour les systèmes parallèles et temps réel.

Ce sont

• les architectures et le traitement parallèles, résultant de la complexité et dela structure physique des SPTR.

• le traitement en temps réel, résultant du fondement dynamique des SPTR.

• la fiabilité et la tolérance aux fautes, résultant des exigences et desconditions d’opération des SPTR.

Ces trois thèmes sont intimement interreliés autant au niveau du matériel que du logiciel.


Les trois thèmes du cours Robert Bergevin (c)

Nous présentons et analysons, dans le cadre de ce cours, plusieurs principes fondamentaux etconcepts techniques reliés à ces trois thèmes et communs aux différents types de SPTR.

Ces principes et concepts sont présentés dans un contexte de développement intégré et en considérantautant les aspects matériels que les aspects logiciels de ces systèmes.

Dans ce premier chapitre, nous allons nous contenter d’introduire brièvement un certain nombre deces principes et concepts. Leur étude détaillée sera abordée dans les deux chapitres suivants.

1.6.1 Premier thème: architectures et traitement parallèles

Ce premier thème concerne les considérations matérielles et logicielles qui font qu’un système pourramaintenir plusieurs activités simultanées, réagissant à plusieurs événements internes ou externes,faisant plusieurs traitements ou calculs complexes et contrôlant plusieurs paramètres simultanément.

1.6.1.1 Traitement concourant

Au niveau logiciel, l’élément de base à considérer est le traitement concourant. Celui-ci est basé surla notion de processus qui est une instanciation d’un programme qui s’exécute séquentiellement maispeut-être simultanément avec d’autres processus d’une même application ou d’applicationsdifférentes.

Sur un ordinateur séquentiel (microprocesseur standard ou monoprocesseur), le traitement concourantse fait grâce à la multiprogrammation par temps partagé (MTP) qui permet une pseudo-simultanéité.C’est-à-dire que plusieurs processus semblent s’exécuter en même temps mais en fait ils utilisent àtour de rôle les ressources du processeur.

De façon traditionnelle, le tout se fait typiquement sans contrôle temporel par le programmeurd’application, les processus étant considérés comme indépendants et gérés par le systèmed’exploitation de façon équitable. C’est le cas, par exemple, lorsque plusieurs applicationsindépendantes se partagent un même ordinateur.

Dans un SPTR, les processus ne sont plus indépendants. En effet, ils doivent tous concourir à laréalisation d’une même application.

En particulier, dans les applications non-structurées, la notion de traitement concourant doit êtreexaminée dans toute sa généralité. Les différents problèmes relevant du traitement concourantdoivent alors être considérés. On peut citer: le changement de processus (“switching”),l’ordonnancement des processus (“scheduling”), l’exclusion mutuelle dans le partage des ressourcespar les processus ainsi que la synchronisation et la communication entre les processus.

Typiquement, les problèmes de traitement concourant ne sont plus alors de la seule responsabilité dusystème d’exploitation. Le programmeur d’application doit en assumer une partie.

1.6.1.2 Traitement parallèle

En vue de profiter au maximum des possibilités du traitement concourant, le module de traitement desSPTR sera typiquement basé sur une architecture matérielle parallèle ou distribuée plutôt que sur unordinateur séquentiel.



Le traitement concourant deviendra alors du traitement réellement parallèle i.e. simultané.

On peut définir le traitement parallèle comme une méthode d’organisation des opérations dans unordinateur parallèle par laquelle plusieurs opérations sont effectuées simultanément.

Quant à l’ordinateur parallèle, on le définit comme une collection de processeurs qui communiquententre eux et coopèrent pour solutionner efficacement des problèmes qui sont généralement de grandeenvergure.

Ainsi, dans un ordinateur parallèle, le traitement se fait en exécutant simultanément des processus surdifférents processeurs qui sont reliés et qui partagent ou non un espace mémoire commun.

Un ordinateur parallèle peut donc être vu comme un groupe de processeurs reliés par un réseaud’interconnexion sur lesquels le traitement d’une même application est réparti au moyen de plusieursprocessus.

Les processus s’exécutant sur les différents processeurs coopèrent pour réaliser l’application.

Ils doivent donc partager les ressources du système, se synchroniser et communiquer soit par le biaisde la mémoire commune, si elle existe, ou par le passage ou transfert de messages par le réseau.

L’étude des topologies possibles pour l’architecture matérielle du réseau est un aspect important del’étude des SPTR. Nous examinerons dans ce cours les différentes architectures parallèles existantesou possibles ainsi que quelques éléments supplémentaires reliés à l’exploitation des architectures lesplus communes.

1.6.1.3 Architectures parallèles

Diverses catégories d’architectures sont possibles, chacune mieux adaptée à des applications oucalculs particuliers, structurés ou non.

Un ordinateur parallèle contient plusieurs modules de traitement (PE: “processing element) ounoeuds de calcul, en général symétriques.

Un PE correspond essentiellement à un processeur ou CPU (ALU, registres, horloges, unités decontrôle pour processeur et bus). Selon le type d’ordinateur parallèle, chaque PE peut contenir ou nonun décodeur d’instructions et un compteur de programme.

Un ordinateur parallèle comprend trois éléments principaux: les processeurs ou modules detraitement (P ou PE), la mémoire, qui peut être partagée ou non, et le réseau d’interconnexion reliantces éléments.

Réseau d’interconnexion

M M M M

P P P P

PPPP

M M M M

Réseau d’interconnexion

mémoire partagée mémoire privée (distribuée)

Figure 1.6 Deux types génériques d’ordinateurs parallèles



Dans le cas des ordinateurs à mémoire privée, on inclut parfois la mémoire dans la définition du PE.

Le compromis entre l’augmentation théorique possible de la performance par l’augmentation dunombre de processeurs ou processus utilisés et la surcharge de communication et la complexité de lasynchronisation qui en résultent doit être examiné attentivement. Nous verrons que divers modèlesanalytiques permettent de prédire l’effet d’une modification des principaux paramètres del’architecture parallèle.

1.6.1.4 Parallélisme interne et virtuel

Il ne faut pas confondre le parallélisme d’architecture de système et de programmation, qui nousintéresse ici, avec celui qui peut exister au niveau interne de chaque processeur séquentiel.

Celui-ci vise à augmenter la vitesse d’exécution des instructions, par exemple par des techniques depipeline, d’exécution spéculative, de processeur I/O autonome.

Il vise aussi à accélérer les transferts entre le CPU et la mémoire, par exemple par la mémoire cache.

Ces mécanismes, qui sont plutôt du domaine de l’architecture des microprocesseurs, visent à aller au-delà des limites de base d’un ordinateur séquentiel.

Ils ne sont cependant pas visibles au programmeur d’application et ils ont peu ou pas d’incidence surle logiciel système.

Un niveau intermédiaire est le parallélisme “multi-thread” ou traitement concourant à l’intérieur d’unmême processeur. Celui-ci peut mener à la définition d’instructions spécialisées pour le processeur.

Par ailleurs, avec l’augmentation des capacités matérielles du VLSI, de plus en plus d’architecturesparallèles (multi-thread, multi-contextes, multi-processeurs) sont développées sur des systèmes à unou à quelques circuits (“chips”) à très haute intégration.

Par contre, cette réduction des dimensions ne change en rien les besoins en langages, compilateurs etsystèmes d’exploitation parallèles pour exploiter ces architectures miniaturisées.

La même remarque peut s’appliquer aux architectures parallèles virtuelles qui sont obtenues à l’aided’une couche logicielle (e.g. PVM ou MPI) s’exécutant sur un groupe de postes de travail (“cluster”)reliés en réseau.

Ces architectures sont souvent, pour le programmeur d’application, équivalentes à une architecturematérielle proprement parallèle.

1.6.1.5 Objectifs du traitement parallèle

Parmi les objectifs principaux du traitement parallèle, en particulier dans le cadre des SPTR, on peutciter:

• l’augmentation de la performance du système.

En particulier on vise à rendre possibles des traitements qui sont excessifsmême sur les superordinateurs existants. Cet objectif s’applique plusparticulièrement aux applications structurées.



Par exemple, on avait évalué au début des années 1990 les besoins enpuissance de calcul des applications les plus exigeantes du futur.

Dans cette lignée, on visait à développer un ordinateur Teraflops (1012

opérations en virgule flottante par seconde, en continu) avant l’an 2000,objectif qui a été atteint depuis mais qui a fait place à de nouveaux objectifsencore plus ambitieux.

• l’augmentation du rapport performance/coût.

Ici, on vise plutôt à rendre plus accessibles des traitements qui ne sontactuellement possibles que sur les superordinateurs. D’un point de vuepratique, cet objectif est plus réaliste que le premier pour la plupart desapplications structurées ou non qui sont basées sur les SPTR.

• l’augmentation de la flexibilité et de la productivité.

Ceci est lié à la nécessité de développer des environnements et outils deprogrammation permettant de réaliser plus rapidement et plus efficacementdes systèmes avancés d’envergure, performants et fiables.

Ce dernier objectif est intimement lié aux besoins des SPTR, en particulierpour les applications non-structurées. Il nécessite alors, en surplus, lesoutils du traitement en temps réel.

1.6.2 Deuxième thème: traitement en temps réel

Dans un SPTR, en particulier pour les applications non-structurées, les traitements sont effectués enrespectant des contraintes, paramètres, ou spécifications termporelles.

Un SPTR est donc aussi, par définition, un système en temps réel.

1.6.2.1 Modèles de base des SPTR

Pour débuter, examinons plus en détail le concept de processus et, en particulier, son utilisation dansle cadre des SPTR.

Différents modèles de SPTR correspondent à différents niveaux de granularité temporelle (et souventspatiale) des processus.

Trois modèles principaux peuvent être identifiés, en plus de leurs combinaisons.

1.6.2.1.1 Réalisation matérielle (“direct-mapped systems”)

Dans cette première approche, pratiquement assimilable aux applications structurées des SPTR, lesprocessus (traitements) sont réalisés par des circuits spécialisés (“processeurs”) ou assignés chacun àun seul processeur spécialisé (e.g. de type DSP).



L’ensemble des processus est fixe. Il y a allocation statique des ressources aux processus. Le tout estorganisé pour satisfaire les contraintes temporelles pré-établies (par exemple, pour traiter un signalaudio ou vidéo sans en effecter la perception ou compréhension). Les processus opèrent généralementde façon pré-déterminée.

La propagation des données (le signal) entre les processus peut être synchronisée à l’aide d’unehorloge ou être asynchrone.

Les résultats intermédiaires sont parfois mémorisés et il est souvent possible d’utiliser un agencementde type “pipeline” pour augmenter le débit des données (e.g. pour le traitement de signal).

Enfin, les paramètres temporels du système, comme le temps de réponse bout-à-bout (“end-to-end”)du capteur à l’actuateur, peuvent être calculés et mesurés précisément.

En particulier, le temps de calcul ne dépend généralement pas du contenu des données maisseulement de leur quantité (il fixe le débit).

Le format d’entrée est identique au format de sortie des données.

Ce modèle est particulièrement utile pour traiter une grande quantité de données de façon uniformesous des contraintes de temps sévères et sans intervention de l’utilisateur.

La granularité temporelle des processus est très fine car ils s’exécutent de façon généralementcontinue. Par exemple, filtrage, encodage, ou compression d’un flot de données continu.

On utilise ce type de système pour traiter les signaux vidéo ou audio continus, ces derniers étantnumérisés et transformés en une séquence d’étapes fixe.

On le retrouve en traitement des images, traitement de la parole, et en général tout le domaine descommunications numériques: téléphonie cellulaire, modems, vidéo-conférences, etc.

Ce type de système prend de plus en plus d’importance et il est connu sous le nom de système detraitement de signal ou de transformation des données (“data transformation”).

Il est de plus en plus généralement basé sur des microprocesseurs spécialisés pour le traitement designal (DSP) plutôt que sur du matériel fait sur mesure (“custom”).

Ces derniers sont optimisés pour le calcul arithmétique et pour la réponse rapide aux interruptions(acquisition) ainsi qu’aux changements de contexte.

Notons enfin que le développement de ces systèmes se fait maintenant souvent en utilisant des outilssophistiqués pour déterminer l’architecture matérielle (de type VHDL de haut niveau) et poureffectuer des simulations. Par exemple, plusieurs logiciels permettent de développer des systèmesbasés sur des processeurs de traitement de signal.

1.6.2.1.2 Opération cyclique

Cette deuxième approche est très commune dans les SPTR commerciaux actuels de complexité faibleà moyenne. Elle concerne les applications moyennement structurées des SPTR.



Des processus critiques sont exécutés périodiquement sur des processeurs généraux qu’ils separtagent.

Des processus sporadiques peuvent aussi être présents (e.g. suite à une interruption) mais ils nedoivent pas créer de délais imprévisibles dans l’exécution des processus critiques.

Les processus sporadiques sont souvent “transformés” en processus périodiques en ajoutant unprocessus de scrutation (“pooling”) périodique d’un indicateur d’interruption.

Le nombre de processus périodiques est fixe mais le temps d’exécution de chacun n’est pas le même.

Un ordonnancement statique des processus est calculé a priori, souvent de façon manuelle ou par uneapproche itérative ou essais-erreurs.

Ce type de modèle s’applique bien aux situations où l’acquisition d’une quantité limitée de donnéesdiverses, pouvant influer sur le traitement, se fait sur une base périodique.

La granularité temporelle des processus est plus grossière que pour les systèmes réalisésmatériellement.

Le système est aussi plus flexible car les ressources de traitement sont toujours programmables et lesdonnées ne sont pas dans un format pré-déterminé.

Enfin, le début de chaque cycle d’exécution de l’ensemble des processus est contrôlé par une horloge.

Un ordonnanceur général n’est pas requis à l’exécution.

1.6.2.1.3 Opération asynchrone ou par événements

Cette dernière approche est la plus générale. Elle est assimilable aux applications non-structurées desSPTR. Dans ce cas-ci, les événements (et non le temps) déterminent l’ordre d’exécution desprocessus.

Ces événements (ou exceptions) peuvent être externes au système et donc provenir del’environnement. Par exemple, des interruptions asynchrones par un dispositif ou par l’utilisateur.

Les événements peuvent aussi être internes au système. Par exemple, des “signaux” logiciels quipeuvent aussi être synchrones.

L’ensemble des processus actifs est déterminé dynamiquement.

Un processus “système” d’allocation des ressources et d’ordonnancement doit contrôler l’ordred’exécution des autres processus.

La communication entre les processus se fait généralement au moyen de variables partagées ou demessages.

La coopération et l’accès à des ressources communes se fait au moyen de mécanismes desynchronisation.

Les différentes catégories de processus (critiques, essentiels et non-essentiels) sont traités parl’utilisation de priorités qui sont calculées et qui déterminent l’ordre dans lequel les processusdevraient être exécutés.



Ce type de système est de type préemptif car les processus en exécution peuvent être remplacés à toutmoment par un processus plus prioritaire. Aussi, lorsque les ressources sont limitées, les possibilitésd’impasse doivent être surveillées.

Seul ce dernier modèle nécessite absolument un traitement concourant et donc le coût additionnel(”overhead”) des ressources de support “système”.

1.6.2.1.4 Combinaison des modèles de base

Les SPTR, systèmes avancés ou complexes qui nous intéressent plus particulièrement dans ce cours,peuvent être réalisés par une combinaison de ces trois modèles de base.

Ainsi, les processus périodiques seront traités de façon cyclique, les calculs intenses et structurésseront réalisés matériellement par des modules de traitement spécialisés et les événementsasynchrones seront pris en compte en assurant un respect des contraintes temporelles et une toléranceaux fautes matérielles et logicielles.

Comme on l’a mentionné, les SPTR sont réalisés à l’aide de systèmes programmables et dutraitement concourant. Ceci contraste avec les systèmes de moindre complexité qui sont réalisés avecdu matériel analogique ou numérique fait sur mesure pour l’application.

Parmi les raisons expliquant cette façon de faire, on peut citer:

• le fait que les sous-composantes du système sont disponiblescommercialement;

Par exemple, les microcontrôleurs, les microprocesseurs spécialisés (e.g.DSP), les circuits d’interface, les commutateurs, les compilateurs et lessystèmes d’exploitation.

• le fait que l’opération du système peut être exprimée par logiciel et est doncmodifiée plus aisément;

• le fait qu’on puisse effectuer des changements en cours d’opération, àl’aide d’une interface utilisateur.

Cette situation amène quelques besoins nouveaux comme:

• la nécessité de pouvoir traiter des signaux analogiques et numériques àl’entrée et à la sortie;

• la nécessité d’introduire des langages, compilateurs, systèmesd’exploitation et autres outils de développement adaptés au temps réel.

Avec ceux-ci, on pourra exprimer les exigences temporelles del’application et éliminer les incertitudes quant à l’utilisation des ressourceset au respect des contraintes.

1.6.2.2 Systèmes embarqués programmables

Comme on l’a vu auparavant, on peut considérer tous les SPTR comme des systèmes embarqués.



Certains sont “fermés” (définition traditionnelle avec “boîte noire” et un nombre limité d’interactionsI/O bien définies, en général sans interface utilisateur).

Les autres sont “ouverts”. L’environnement physique fait partie du système et l’interaction est moinscontrôlée car le système doit s’adapter à tout changement dans l’environnement qui inclut l’interfaceutilisateur.

Par exemple, un robot mobile (véhicule autonome) peut être considéré comme un système embarquéouvert.

Étude Identifier, dans le cas du système de vision robotique présenté plus tôt, descontraintes temporelles à respecter.

Un SPTR est généralement en interaction étroite avec un environnement dynamique, par exemple parl’entremise des interfaces matérielles des différentes composantes d’un système externe.

Le rôle du SPTR est alors de contrôler le système externe, qui peut être complexe i.e. comporterplusieurs modules en interaction.

Ce contrôle passe donc par une réaction aux événements de l’environnement.

Il peut aussi impliquer la réalisation d’actions périodiques initiées par le système en temps réel.

1.6.2.3 Contraintes temporelles

Des contraintes (unitaires) de début et de durée maximale (“deadline”) peuvent exister pour chacundes traitements effectués par les processus du SPTR.

Parmi ces contraintes, on peut retrouver le temps de réponse, qui est le temps entre un événement àl’entrée du système et une action appropriée à la sortie (temps “bout-à-bout”). Il n’y a qu’une seulecontrainte de ce type dans les systèmes “direct-mapped”.

Il y a aussi l’échéance (“deadline”), qui représente le moment où un traitement ou action doit seterminer. En pratique, cette contrainte est souvent exprimée sur une base périodique. Il y a unecontrainte de ce type par processus en général.

Les SPTR doivent souvent répondre à des événements. Ceux-ci sont soit synchrones ou asynchrones.

Dans le premier cas, ils peuvent provenir:

• d’une source interne;Par exemple une boucle de scrutation ou des interruptions logiciellesréglées sur une horloge (“watchdog timer”).

• d’une source externe.Par exemple un dispositif réglé sur une horloge qui génère des interruptionspour chaque transmission de données.

Dans le deuxième cas, ils peuvent aussi provenir d’une source interne, par exemple une interactionavec un traitement de durée variable, ou d’une source externe, par exemple un capteur qui génère uneinterruption lorsque la variable mesurée dépasse une valeur prédéterminée.



Un SPTR réagissant à des événements synchrones est dit basé sur le temps (“time-driven”) tandis ques’il réagit à des événements asynchrones on le dit basé sur les événements (“event-driven”). Dans lesdeux cas, on parle d’un système réactif.

Les événements peuvent être instantanés, par exemple l’arrivée d’un objet sur un tapis roulant, ouétendus dans le temps, par exemple la transmission d’un message sur un réseau.

Il y aura donc des contraintes liées à des instants sur l’échelle de temps et d’autres liées à desintervalles sur cette même échelle.

Contrairement aux applications n’ayant pas de contraintes de temps réel explicites, le bonfonctionnement (“correctness”) d’un SPTR dépend non seulement du résultat logique des traitementseffectués mais aussi du moment où ils sont disponibles (e.g. sorties vers les “actuateurs”).

De plus, de façon générale, temps réel ne veut pas dire rapide. Selon les besoins de l’application, letemps de réponse requis à un événement externe peut être plus ou moins court.

1.6.2.4 SPTR de type sévères et indulgents

À la limite on pourrait dire que tous les systèmes pratiques sont en temps réel car ils ont tous descontraintes de temps de réponse non infinis.

Cependant, la particularité des SPTR, en particulier pour les applications non-structurées, est que cescontraintes sont explicites et qu’on doit s’assurer qu’elles seront respectées.

Lorsque le non-respect des différentes contraintes de temps a des conséquences majeures (impactshumains ou économiques) sur le système contrôlé, on parle d’un SPTR de type sévère ou strict(“HRTS: hard real-time system”).

On retrouve ces systèmes dans les applications ayant un élément de sécurité important et/ou un coûtélevé. Par exemple, les systèmes de contrôle de centrales nucléaires, les systèmes aéronautiques (e.g.pilotage automatique), les systèmes spatiaux et les systèmes médicaux.

Dans le cas contraire, on parle d’un SPTR de type indulgent ou large (“SRTS: soft real-timesystem”). Ici, seule une simple dégradation de la performance résulte du non respect des contraintesde temps.

Par exemple, les systèmes de réservation de billets (e.g. aviation) ou d’interrogation de bases dedonnées (e.g. guichets automatiques, Web) représentent des SPTR indulgents. Ce sont en général dessystèmes distribués et interactifs.

Les SPTR indulgents deviennent de plus en plus importants dans les nouvelles applications.

1.6.2.5 Prévisibilité versus rapidité

La caractéristique la plus souhaitée pour un système en temps réel est qu’il soit prévisible i.e. que l’onveut une “garantie” que tous les traitements seront effectuées (e.g. les sorties appropriées serontgénérées) au bon moment.

Ceci, en autant que les hypothèses de base ou spécifications soient respectées.



Cette caractéristique est la plus difficile à respecter mais elle est aussi plus importante que la seulerapidité du système.

Les contraintes de temps impliquent souvent mais pas toujours une haute performance de calcul. Ceciest particulièrement vrai dans les applications structurées.

Pour les SPTR, ce qui importe est d’avoir une performance toujours suffisante pour satisfaire toutesles contraintes de temps.

C’est le point de différence majeur avec les systèmes informatiques d’usage général qui visent plutôtà maximiser la performance moyenne.

Étude Dire en quoi les exigences de temps réel et le parallélisme peuvent sesupporter et en quoi ils peuvent se nuire.

1.6.2.6 Exemples d’applications en temps réel

Plusieurs types d’applications complexes nécessitent le développement de systèmes avancéscomportant des contraintes de temps réel.

Voyons quelques exemples typiques d’applications non-structurées et examinons certaines questionsqu’ils soulèvent.

1.6.2.6.1 Système de pilotage automatique

Un système de pilotage automatique sur un avion comporte de nombreuses spécifications dontplusieurs sont reliées au temps réel.

Par exemple, on peut avoir à calculer (traitement) et afficher (action) la vitesse de l’avion à toutes les40 msec sur la base de 3 types de données (acquisition):

• accélérations en x, y, et z reçues à toutes les 5 msec (placées dans unregistre par un module externe);

• orientations en x,y et z reçues à toutes les 40 msec (placées en mémoire parun mécanisme d’accès direct “DMA”);

• autres variables comme la température reçues à un taux de une donnée àtoutes les secondes.

Comment avoir des processus ajustés à ces périodes variables?

Comment s’assurer que ces périodes seront respectées?

Comment arbitrer les demandes de ces processus et des autres fonctions du systèmes?

Comment les processus vont-ils communiquer entre eux?

Comment corréler les données reçues?

Comment synchroniser dans le temps les composantes x,y et z de la vitesse?

Comment détecter et corriger des mesures erronées?



1.6.2.6.2 Système moniteur d’une centrale nucléaire

Ici, on peut demander au système de réagir à deux types d’événements signalés par des interruptions:par des modules externes: le premier en 1 seconde et le deuxième en 1 msec.

Comment s’assurer que toutes les interruptions seront servies dans le temps requis?

Comment s’assurer que les autres fonctions du système seront aussi réalisées sur une base régulière?

Comment comparer la priorité de ces événements et de ceux des processus périodiques?

1.6.2.6.3 Système de réservation de billets

L’objectif peut être de gérer la réservation de billets d’avion à partir de plusieurs terminaux reliés enréseau sous deux contraintes:

• toute demande est traitée en moins de 15 secondes;

• il y a un nombre maximal de réservations par vol.

Comment s’assurer que les données seront acheminées de façon fiable et efficace entre chacun desterminaux répartis géographiquement et le système central?

Comment s’assurer qu’une panne affectant une partie du réseau ne se traduira pas par une perte deperformance inacceptable du système?

Comment s’assurer que la base de données partagée entre les terminaux ne sera pas modifiée pardeux personnes en même temps?

C’est à ce type de questions que nous répondrons de façon générale dans les chapitres suivants.

Étude Faire une liste de tout ce que pourraient comprendre, au niveau matériel etlogiciel, les modules de perception, de traitement et d’action du modèle SPTR dans unevoiture complètement automatisée.

1.6.3 Troisième thème: fiabilité et tolérance aux fautes

La fiabilité d’un système est un concept défini en termes du temps moyen entre les pannes ou de ladurée relative des périodes où le système est en marche. On utilise généralement une formulationprobabiliste de la fiabilité.

La tolérance aux fautes est une caractéristique permettant d’augmenter la fiabilité d’un systèmecomplexe. C’est un aspect important des SPTR. En fait, c’est un aspect souvent négligé dans l’étudethéorique des systèmes mais qui s’avère très important en pratique.

L’approche prise est de détecter les fautes et de prévoir des mécanismes pour les tolérer i.e. pourpouvoir continuer à fonctionner malgré certaines fautes logicielles ou matérielles inévitables enpratique. Attention: tolérer, ici, ne veut pas dire ne pas s’en occuper.

Cette approche contraste avec l’évitement des fautes qui est plus commune pour les systèmes moinscomplexes et qui consiste à concevoir et à tester le système pour que toute faute soit éliminée avant lamise en marche.


Exercices à faire Robert Bergevin (c)

Plusieurs raisons expliquent la nécessité d’utiliser une approche de tolérance aux fautes dans lesSPTR. On peut citer:

• la complexité des systèmes dont le nombre de modules et leursinteractions;

• l’opération des systèmes dans des conditions variables et imprévisibles;

• la longue durée de vie et la modification possible des systèmes en cours deroute.

Un des buts de la tolérance aux fautes est de permettre une remise en marche ou reprise en douceur(“graceful recovery”) en cas de faute matérielle, logicielle, ou temporelle.

Pour ce faire on utilise souvent le principe de la redondance autant au niveau matériel et logiciel(redondance dite spatiale) qu’au niveau temporel.

Le parallélisme rend possible la redondance et donc la tolérance face aux fautes matérielles etlogicielles.

Un élément logiciel qui prend de l’importance est celui des algorithmes dit incrémentaux (“imprecisecomputation”). Ceux-ci adaptent la qualité de leurs résultats en fonction du temps disponible, sur labase de compromis prédéfinis et spécifiques à l’application. Par exemple, l’apparition d’une fautepeut réduire les possibilités du système qui devra alors faire appel à un algorithme moins précis maisqui permettra de respecter les contraintes de temps.

La réalisation de mécanismes de tolérance aux fautes doit tenir compte des divers aspects d’un SPTRcomme les contraintes temporelles, les contraintes quant aux ressources disponibles, les relations deprécédence entre les processus qui sont propres à l’application, le degré de criticalité de chacun desprocessus, etc.

Étude Identifier, pour un domaine d’application donné respectant le modèle SPTR,des cas précis où la tolérance aux fautes est nécessaire.

1.7 Exercices à faire

Q1.4 à Q1.7.

1.8 État de l’art

L’utilisation du parallélisme et des systèmes distribués est un développement relativement récent dessystèmes temps réel qui est rendu nécessaire par les applications plus complexes, donnant lieu auxSPTR.

Le développement de modèles et d’outils pour la programmation système et d’application des SPTRfait encore l’objet de nombreux efforts en recherche et développement.


État de l’art Robert Bergevin (c)

Plusieurs possibilités sont encore à explorer et à évaluer tant au niveau des architectures matérielles(processeurs, réseaux) que des logiciels (langages, compilateurs, systèmes d’exploitation et autresoutils de développement adaptés au parallélisme et au temps réel).

Le défi consistera à définir des méthodologies et à réaliser des outils de développement intégrés etcompatibles avec la grande diversité des applications complexes en ingénierie [Cottet 1], [Calvez],[Gomaa 1], [Gomaa 2], [Cooling].

Ceci pourra se faire sur la base de modèles génériques, comme le modèle SPTR, qui tententd’identifier la structure et les aspects communs de ces applications, par exemple le temps réel, leparallélisme et la tolérance aux fautes, ainsi que les besoins qui en résultent autant au niveau matérielque logiciel.

Dans la suite du cours, nous explorerons ce qui a déjà été proposé pour aborder ces différents thèmesainsi que leur intégration. Nous nous situerons au niveau des applications et des concepts systèmesd’assez haut niveau. Ainsi, nous ne traiterons pas directement du langage machine, des interruptions,de l’interfaçage aux périphériques, des pilotes de dispositifs, de la mesure du temps ou del’acquisition des données. Nos concepts de base seront les architectures de traitement, les processusde calcul et les communications.


Révision Robert Bergevin (c)

1.9 Révision

• Qu’est-ce qu’un SPTR?

• Quels sont les deux types de SPTR et qu’est-ce qui les différencie?

• Donnez deux exemples de chaque type de SPTR.

• Qu’est-ce qu’un système embarqué?

• Qu’est-ce qu’un ordinateur parallèle?

• Quelle est la différence principale entre traitements concourant et parallèle?

• Quelle est la relation entre SPTR et système embarqué.

• Pourquoi la fiabilité est-elle importante dans les SPTR?

• Comment obtient-on la fiabilité dans les SPTR?

• Qu’est-ce qu’un événement?

• Qu’est-ce qu’un processus?

• Quels sont les différents éléments d’interface dans le modèle SPTR?

• À quoi correspondent les capteurs et les actuateurs dans le modèle SPTR?

• Est-ce que les SPTR sévères sont plus nombreux que les SPTR indulgents?

• Qu’est-ce que la prévisibilité dans les SPTR?


Exercices Robert Bergevin (c)

1.10 Exercices

Q1.1 Expliquez en quoi le modèle SPTR est plus général que le modèle simple d’un système decommande avec rétroaction.

Q1.2 Nous avons vu que les SPTR ont une architecture logique comportant des modules génériquesde perception, traitement, action, et rétroaction.a) Montrer cette architecture au moyen d’un diagramme.b) Décrire brièvement chacun des modules génériques de ces systèmes.c) Choisir un exemple de système dans un des domaines d’application mentionnés et

expliquer à quoi correspond chacun des modules dans ce cas.d) Répéter c) avec un autre domaine d’application.

Q1.3 Nous avons expliqué, au moyen d’un diagramme, que le processus de développement d’unsystème peut être vu comme la recherche d’une solution à un problème.

Dans le cas des SPTR, nous avons présenté un modèle très général de la solution sous la formedu diagramme suivant:

a) Expliquez les liens que l’on peut faire entre les éléments du diagramme problème-solutionet ceux du modèle SPTR.

Q1.4 Expliquez, pour l’exemple du système de vision robotique présenté, en quoi on peutconsidérer que l’on y retrouve les 3 modèles de base des SPTR, soit la réalisation matérielle,l’opération continue ou cyclique et l’opération asynchrone ou par événements.

PROBLÈME SOLUTION

architecturelogiciel

d’application

matériel etlogiciel système

algorithmeet code

exigences

besoins, contraintes, ressources

perception traitement action

environnement

rétroaction


Exercices Robert Bergevin (c)

Q1.5 Associez l’énoncé (A-H) avec la définition correspondante (a-h):

A- Système en temps réel, B- Système embarqué, C- Traitement concourant, D- Processus, E-Ordinateur séquentiel, F- Ordinateur parallèle, G- Multitraitement, H- Traitement parallèle.

a- Partie d’un programme qui s’exécute séquentiellement.b- Méthode d’organisation des opérations dans un ordinateur par laquelle plusieurs opérationssont effectuées simultanément.c- Système dédié et autonome.d- Système qui doit respecter des contraintes temporelles.e- Collection de processeurs qui communiquent entre eux et coopèrent pour solutionnerefficacement des problèmes d’envergure.f- Système de traitement réparti par exécution de processus sur différents processeurs quicommuniquent par passage de messages.g- Méthode par laquelle différents processus participent en commun à la solution d’unproblème unique.h- Processeur unique qui permet seulement la pseudo-simultanéité du traitement.

Q1.6 Associez les éléments A-H aux énoncés a-p suivants. Plusieurs éléments peuvent se rapporterau même énoncé et vice-versa.A- système embarqué ouvert, B- système embarqué fermé, C- événement synchrone, D-événement asynchrone, E- événement instantané, F- événement étendu dans le temps, G-système temps réel sévère, H- système temps réel indulgent.

a- scrutation, b- système de pilotage automatique, c- microcontrôleur, d- applicationd’intelligence artificielle, e- console de jeux vidéo, f- avionique, g- imprimantes, h- DSP, i-interruption, j- système pour contrôler les injecteurs d’une automobile, k- système deréservation, l- arrivée d’un objet sur un tapis roulant, m- système de télécommunication, n-centrale nucléaire, o- transmission d’un message, p- robot autonome mobile.

Q1.7 Expliquez en quoi les navigateurs Internet (“browser”) peuvent être considérés comme desapplications en temps réel.


Références Robert Bergevin (c)

1.11 Références

[Calvez]: Spécification et conception des systèmes: une méthodologie, J.P. CALVEZ, Masson, 1990.

[Cooling]: Software Engineering for Real-Time Systems, J. COOLING, Addison-Wesley, 2003.

[Cottet 1]: Systémes temps réel de contrôle-commande: conception et implémentation, F. COTTET,E. GROLLEAU, Dunod, 2005.

[Gomaa 1]: Software Design Methods for Concurrent and Real-Time Systems, H. GOMAA, Addison-Wesley, 1993.

[Gomaa 2]: Designing Concurrent, Distributed, and Real-Time Applications with UML, H. GOMAA,Addison-Wesley, 2000.

[Halang]: Real-Time Systems: Implementation of Industrial Computerised Process Automation, W.A.HALANG, K.M. SACHA, World Scientific, 1992.

[Lawson]: Parallel Processing in Industrial Real-Time Applications, H.W LAWSON, Prentice-Hall,1992.

[Mullender]: Distributed Systems, 2nd Edition, S. MULLENDER, Editor, Addison-Wesley, 1993.S

CHAPITRE 1 Introduction -...

Documents

Transcript of CHAPITRE 1 Introduction -...