Soutenance mémoire
Les différents systèmes de contrôle-commande
Il y a 4 différents spécifications de systèmes de contrôle-commande mais ils peuvent se combiner.
a) Système de contrôle-commande temps réel : C’est un système dont l’exactitude des applications dépend du résultat et du temps auquel ce résultat est produit. Ces contraintes temporelles pourront causer des défaillances sur le système si elles ne sont pas respectées. Il y a deux types de contraintes temporelles :
• Contraintes temporelles strictes et dures : L’échéance des taches doit être impérativement respecté, sinon des catastrophes physiques pourront se produire.
• Contraintes temporelles relatives ou lâches : Le non-respect de l’échéance des tâches est tolérable, mais devrait être corrigé.
b) Système de contrôle-commande embarqué : C’est un système piloté par un logiciel et qui est complètement intégré au système qu’il contrôle, donc pas d’intervention humaine directe (pas de modification ou des paramètres du programme).
c) Système de contrôle-commande dédié : C’est un système dont les architectures matérielles et logicielles sont spécifiques à l’application (noyau, processeur…).
d) Système de contrôle-commande distribué ou réparti : C’est un système dont l’architecture matérielle est constituée de plusieurs processeurs reliés entre eux par un bus ou un réseau.
Architectures logicielle et matérielle
Le système de contrôle-commande a deux composantes fondamentales :
• La composante matérielle : interface permettant de piloter le procédé et de recueillir des informations en provenance de ce dernier (carte d’entrée/sortie …).
• La composante logicielle : assure le bon fonctionnement du procédé.
Architecture logicielle : Un système informatique de contrôle-commande doit satisfaire a priori la cohérence entre des changements de l’environnement et des réactivités du système face à ces changements. L’environnement est décrit en tant que système fortement parallèle à cause du comportement concurrent des évènements et des données externes. Ce parallélisme conduit à la mise en place d’une architecture multitâche qui permet de faciliter la conception de logiciel définissant les tâches comme « les entités d’exécution et de structuration de l’application ».
Les groupes des tâches :
• Tâches d’entrée/sortie : permettent d’accéder aux données externes fournies par des capteurs, ou de générer des commandes aux actionneurs par l’intermédiaire de carte d’entrée/sortie (exécutée régulièrement ou par interruption)
• Tâches de traitement : constituent le cœur de l’application, et sont considérées comme des boites noires, exécutant des algorithmes.
• Tâches de l’interface de l’utilisateur : permettent de présenter l’état de procédé ou de sa gestion à l’utilisateur.
L’utilisateur peut modifier les consignes données ou changer les commandes.
• Tâches de communication (pour l’application distribuée ou répartie) : servent à gérer les messages envoyés ou reçus à travers un ou plusieurs réseaux ou bus de train.
• Tâches de sauvegarde : permettent de stocker l’état du système à des instants fixés.
Les tâches obtenues, qui constituent le système informatique de contrôle-commande, ne sont pas des entités d’exécution indépendantes. Certaines tâches, dès leur activation, communiquent et/ou se synchronisent avec les autres tâches, ou sont connectées à l’extérieur pour les entrées/sorties. Ainsi, dans l’architecture logicielle multitâche, il faut que le concepteur adresse des problèmes de relations entre tâches, qui sont représentés typiquement par la synchronisation, la communication, le partage de ressources, afin d’assurer le comportement concurrent des systèmes de contrôle-commande.
Architecture matérielle : L’aspect matériel a une très grande importance dans les applications de contrôlecommande. Il assure la connexion directe avec le monde physique réel à l’aide d’une grande diversité de système d’entrée/sortie et l’agencement des composants électroniques ainsi que leur interaction. Dans ces matériels on peut citer : microcontrôleur, des mémoires, des horloges, des composants spécifiques, des alimentations…
Processeur
• Un microprocesseur est une unité de traitement optimisée pour le calcul. Généralement plus rapide qu’un microcontrôleur, c’est le cœur des microordinateurs. Il est capable d’effectuer des entrées/sorties (moyens de communication entre l’ordinateur et le monde extérieur : capteurs, actionneurs, périphériques divers) via des circuits spécialisés (ports série, ports parallèle, USB, etc.) et surtout, dans le cadre des applications de contrôle-commande, via des cartes spécialisées enfichables nommées cartes d’acquisition.
• Un microcontrôleur est une unité de traitement optimisée pour les entrées sorties.
Généralement, un microcontrôleur est associé directement à plusieurs types d’entrées/ sorties, et il ne nécessite pas l’apport de cartes enfichables supplémentaires. Il est de ce fait plus compact qu’un microprocesseur muni de cartes d’acquisition, mais moins performant en termes de calcul. Les unités de calculs sont caractérisées par une fréquence d’horloge en hertz (Hz). Cette fréquence correspond au nombre de cycle par seconde effectué par l’unité de calcul. Chaque instruction de bas niveau exécutée par l’unité de calcul nécessite d’un à quelques cycles d’horloge. La fréquence d’horloge des microprocesseurs actuels se situe aux alentours de quelques gigahertz (GHz), alors que les microcontrôleurs sont cadencés (ce terme vient du fait que l’horloge interne donne la cadence) à quelques dizaines de mégahertz (MHz). Les instructions d’un programme, ainsi que les données et le contexte d’exécution du programme sont stockés dans la mémoire centrale (mémoire vive comme la RAM pour Random Access Memory, ou mémoire FLASH plus lente que la RAM mais rémanente). Une mémoire se caractérise par sa taille, la taille des mots mémoires (taille de données que le processeur et la mémoire échangent à chaque accès) et son temps d’accès. Le temps d’accès est donné soit en fréquence, soit en nombre d’accès par seconde. Dans un système informatisé, la taille est caractérisée en octets. Un octet est une entité composée de 8 bits (bit binary digit, chiffre binaire). Toute information (instructions, données, informations sur l’état interne, etc.) est représentée en binaire sur un certain nombre d’octets. L’octet est la plus petite entité adressable : chaque octet possède une adresse en mémoire centrale.
Outils de communication et de synchronisation
Les outils de communication et de synchronisation permettent aux tâches d’interagir. Effectivement, les exécutifs temps réel ne proposent pas toujours ces outils mais il faut dans certains cas les implémenter en utilisant ces concepts de base.
Sémaphore : C’est un outil introduit par Dijkstra en 1965 dont, l’un de ses rôles est de protéger une zone de programme dite réentrante, c’est-à-dire qu’il permet de limiter le nombre d’accès à une ressource partagée, en comptant le nombre d’autorisations acquises et rendues Le sémaphore gère donc un ensemble de permis, en nombre fixé, et accorde ces permis à ceux qui en font la demande et ces demandeurs sont mis à l’état bloqué jusqu’à ce qu’un permis lui a été délivré. C’est une variable soit binaire soit n-aires.
Moniteur : Un outil utilisé pour synchronisé deux ou plusieurs tâches qui utilisent des ressources partagées. L’utilisation de ressource ne peut avoir lieu qu’à travers ce dernier. Il est constitué :
• D’ensemble de primitive permettant l’interaction avec la ressource partagée
• D’un verrou d’exclusion mutuelle
• Des variables associées à la ressource
Il y a deux type : classique et à la Ada.
Signaux : Ce sont des évènements (sans donnée) pouvant être envoyer à une ou plusieurs tâches simultanément. On distingue deux types de signaux :
• Signaux synchrone : internes à une tâche ou un processus. C’est le résultat d’un évènement interne à une tâche.
• Signaux asynchrone : provenant d’une source externe (autre tâche ou processus) à l’adresse :
o D’une tâche ou un processus (privé)
o Ou à plusieurs tâches et/processus (public)
La boite aux lettres : La boite aux lettres permet une communication asynchrone entre des tâches. Elle est constituée de :
• Zone d’échange tampon (buffer) : dans laquelle le tâche « émettrice » peut déposer des données.
• Mécanisme de gestion de données stockées.
La communication est dite asynchrone car la tache émettrice n’a pas besoin d’attendre que la tâche réceptrice soit à l’écoute pour lui envoyer des données.
Le rendez-vous : C’est une communication synchrone asymétrique des tâches avec passage de données où une tâche « acceptante » attend un rendez-vous et une tâche appelante demande à effectuer un rendez-vous avec cette dernière.
Tableau noire : Il est la forme la plus simple des outils de communication asynchrone. C’est une zone de mémoire pouvant contenir un message où l’écriture d’un message écrase le message précèdent, et la lecture est non bloquante et non destructive.
La méthode SA-RT
a) Histoire : D’abord SA : L’analyse structurée SA, définie par E. Yourdon et T. Demarco, est une méthode descendante par affinages successifs des traitements, appelés « process ». Les différents diagrammes sont donc ordonnés hiérarchiquement en faisant apparaître pour les derniers niveaux des fonctions élémentaires, appelées primitives élémentaires ou « process » primitifs. Les différents outils composant cette méthode sont :
– diagrammes de transformations de données ou diagramme de flots de données (DFD) ;
– dictionnaire de données ;
– spécifications des « process » primitifs.
Pour exprimer complètement le comportement de l’application, le diagramme flots de données de SA manquait d’un moyen permettant de spécifier l’aspect opérationnel, c’està-dire la description de l’enchaînement des différents process. Cette lacune fut comblée par la création de méthode SA-RT (Structured Analysis-Real Time). Deux groupes élaborèrent la méthode SA-RT avec des différences notables en termes de représentation : d’une part, la méthode établie par Ward et Mellor en 1985 qui associe le fonctionnel et le contrôle dans un même diagramme et, d’autre part, la méthode proposée par Hatley et Pirbhai en 1986 qui sépare le fonctionnel et le contrôle.
b) Description : La méthode SA-RT est une méthode d’analyse fonctionnelle et opérationnelle des applications de contrôle-commande. Cette méthode permet de réaliser une description graphique et textuelle de l’application en termes de besoins, c’est-à-dire de « ce que l’on a à faire » ou le « quoi ». Cette mise en forme du « cahier des charges » de l’application est formelle dans le sens où la méthodologie (ensemble des documents à élaborer) et l’expression (syntaxe graphique) sont définies. En revanche, elle ne permet pas d’effectuer une vérification de propriétés de l’application à partir des seules descriptions SA-RT. Des études ont été menées pour associer à la méthode SA-RT des méthodes formelles afin d’apporter des possibilités de simulation et de vérification. C’est la méthode SA-RT (Structured Analysis for Real-Time Systems), une méthode de spécification se basant sur le modèle des processus de la méthode SA. Le principe de la méthode SA-RT est d’abord de décomposer un système en processus fonctionnels, et de décrire le passage d’information sous forme de flot de données. Puis un processus de contrôle joue le rôle de chef d’orchestre en activant/désactivant ou en déclenchant ces processus fonctionnels grâce à des événements prédéfinis : «Enable» (Activation), «Disable» (Désactivation), et «Trigger» (Déclenchement). La spécification SA-RT comporte généralement un diagramme de contexte de données, un ensemble de diagrammes de flot de données/flot de contrôle hiérarchique, et un diagramme EtatTransition.
c) Eléments utilisés : Les diagrammes de flot de données sont construits à partir de quatre éléments graphiques : traitement (cercle), flot de données (flèche), unité de stockage (traits parallèles) et entité externe (rectangle). À partir de ces éléments de base, il est possible de décrire l’aspect fonctionnel d’une application par un diagramme flot de données. Ces composants du diagramme peuvent être liés par une flèche continue (flot de données : discrète ou continue) ou par une flèche discontinue (Enable/Disable, Tigger, Evènement), ou bien les deux à la fois.
d) Fonctionnement : Le processus de contrôle représente la logique du pilotage des processus fonctionnels. Les flots de contrôle (ou Flot d’Evénement) transportent les événements ou informations qui conditionnent directement ou indirectement l’exécution des processus de transformation de données. Alors que les données peuvent prendre soit des valeurs discrètes, soit le plus souvent des valeurs continues, les signaux de contrôle prennent toujours des valeurs discrètes (voir la Figure I-30). SA-RT est une méthode de spécification des systèmes basée sur le concept de la rétroaction. Dans le modèle des besoins de la méthode SA-RT, nous voyons que le système est décomposé non seulement en processus primitifs, mais également en état de façon à ce que la réponse de ces processus primitifs soit dirigée par un processus de contrôle en fonction des conditions passées et présentes à l’intérieur et à l’extérieur du système. Tandis que l’activation des processus fonctionnels dans les diagrammes de flot de données de la méthode SA est réalisée par leurs données, le fait que des processus fonctionnels dans les diagrammes de flot de données sont activés par des événements rend la méthode SA-RT bien adaptée à des systèmes de contrôle/commande temps réel. Du point de vue de la spécification des besoins, les diagrammes état-transition (ou tables étattransition, matrices état-transition) nous permettent de décrire distinctement l’aspect comportemental des systèmes de manière dynamique (par rapport aux méthodes SA et JSP). De plus, une spécification des contraintes de temps peut être associée sous la forme de temps de réponse entrée-sortie (une représentation simple du domaine des temps de réponse admissibles entre chaque événement survenant sur les terminaux d’entrée, et chaque événement résultant sur les terminaux de sortie). Cependant, dans le cas des grands systèmes, en particulier des systèmes complexes, la décomposition en état peut provoquer le problème de l’explosion des états où les diagrammes état-transition peuvent être inappropriés en comparaison avec les statecharts ou les tables état-transition. Quand plusieurs événements associés à un état surviennent simultanément, le choix de la transition à exécuter et de l’état suivant correspondant dans un diagramme état transition devient non-déterministe. Etant une méthode de spécification, la méthode SART ne propose aucun mécanisme pour résoudre ce problème. Il laisse cela aux étapes suivantes (l’étape de conception et d’implémentation). La communication entre le processus de contrôle et ses processus de données dans SA-RT est la communication synchrone faiblement couplée réalisée uniquement par des flots d’événement (soit un Enable/Disable (E/D) événement, soit un Trigger (T) événement). Mais la communication synchrone fortement couplée entre les processus de données peut être faite par des flots de données discrets de façon à ce que le processus appelant va envoyer une requête au processus appelé, attendre une donnée de ce dernier.
e) Règle : Comme dans SA, des DFD hiérarchiques sont créés en partant du diagramme de contexte de données en respectant les règles suivantes : un seul ou aucun processus de contrôle par niveau de diagramme (diagramme préliminaire ou diagramme de décomposition); les flots de données ne sont traités que dans les processus primitifs, les flots de contrôle ne sont que dans le processus de contrôle et font des interfaces entre le processus de contrôle et des processus fonctionnels.
f) Organisation : Les traits essentiels de cette méthodologie hiérarchique descendante résident dans la mise en avant des aspects fonctionnels et comportementaux (exécution) de l’application analysée.
– Diagramme de contexte : premier diagramme flot de données permettant de décrire l’environnement de l’application à développer. Le DCD représente les bornes entre le système et l’environnement externe. Il identifie les entités extérieures avec lesquelles le système doit communiquer. Chaque entité est représentée sous la forme d’une terminaison par un rectangle étiqueté. Le système est représenté par un processus unique qui expose le but principal (c’est-à-dire le cercle contenant l’identification du rôle central du système). Toutes les entrées et les sorties du système sont représentées sous la forme des flots de données qui font des interfaces entre les terminaisons et le processus principal : donc tous les flots qui circulent vers le processus principal sont en entrée, et tous les flots qui circulent à partir du processus principal sont en sortie.
– Diagramme préliminaire : diagramme flot de données présentant le premier niveau d’analyse fonctionnelle de l’application. Le DFD décompose le processus central unique et les flots d’entrée/sortie dans le DCD en sousprocessus et en sous-flot respectivement (les sous-flots sont donc introduits entre les sousprocessus) afin de détailler le fonctionnement du système. Le DFD contient seulement des processus, des flots de données et des zones de stockage. Les processus et les flots de données sont similaires à ceux du diagramme de contexte de données. Les stockages, indiqués par des paires de lignes de droites parallèles avec des noms à l’intérieur, représentent des données stockées pour une utilisation ultérieure par un processus.
– Diagrammes de décomposition : diagramme flot de données présentant les analyses des processus fonctionnels non primitifs.
– Spécification des processus fonctionnels primitifs : spécification textuelle des fonctions réalisées par les processus fonctionnels.
Dans le diagramme préliminaire, nous voyons très clairement la fusion entre le modèle de contrôle et le modèle des processus dans la spécification des besoins de la méthode SA-RT. Le processus de contrôle, appelé « Contrôle Chauffage », est le contrôleur du système. Il dirige le fonctionnement de tous les processus fonctionnels grâce à des flots d’événement appropriés. Donc les processus d’acquisition sont activés ou désactivés par des événements «Enable/Disable» (ou E/D), et les processus de commande sont déclenchés par des événements «Trigger» (ou T).
– Spécification des processus de contrôle : diagrammes état/transition décrivant le fonctionnement des processus de contrôle.
Nous savons que dans le cas où un diagramme de flot de données contient un processus de contrôle, il est nécessaire de générer une description ou une spécification du processus de contrôle afin de représenter l’aspect comportemental de l’application. Cette spécification peut être faite sous la forme d’un diagramme état-transition. Le diagramme état-transition est la représentation la plus familière d’une machine séquentielle (une machine séquentielle est définie comme une machine à états finis dont les sorties sont déterminées à la fois par les entrées courantes et passées). Dans un diagramme étattransition, nous précisons tous les états possibles d’un système lors de son exécution. Les états sont représentés par des boîtes rectangulaires avec les noms des états. A un instant donné, le système doit être toujours dans l’un de ses états spécifiés. Le changement d’un état courant à un autre état est déterminé par un arc de transition avec une flèche vers l’état suivant. Des événements causant la transition, et des actions engendrées lorsque la transition est franchie sont notés directement sur l’arc de transition. Les deux sont séparés par une ligne.
– Dictionnaire de données : liste exhaustive des données et des événements utilisés dans la spécification. Le dictionnaire de données regroupe la sémantique et la structure des données présentées dans le système. Le dictionnaire fournit une définition exacte de chaque flot de données et de tous les stockages.
La programmation parallèle
1. Pourquoi la programmation parallèle ?
• La puissance de calcul d’une machine « standard » n’est pas suffisante pour toutes les applications informatiques
• Il n’y a presque plus d’architecture monoprocesseur, par faute de difficulté d’augmentation de la fréquence d’horloge, les constructeurs font recours à l’augmentation de nombre de processeur
• Pour augmenter la puissance des machines sans attendre de nouvelle technologie
• Pour augmenter les performances des machines monoprocesseur grâce à des mécanismes parallèles intégrés (unités de traitement/calcul indépendantes, multiplication des unités de calcul, pipeline) et aux architectures parallèles associées au processeur.
2. Définition : Une architecture parallèle est un ensemble de processeurs élémentaires communiquant qui coopèrent pour résoudre un problème. Le système parallèle c’est découper un gros problème en de nombreux petits problèmes. Le parallélisme a deux niveaux : à l’intérieur du processeur (instructions en parallèle et multi-cœur) et multiprocesseurs. [2][9] Définition (Petit Robert) : En Informatique c’est une Technique d’accroissement des performances des ordinateurs utilisant plusieurs processeurs fonctionnant simultanément.
Le parallélisme au sein du processeur : L’exécution d’une instruction (multiplication par ex.) nécessite plusieurs cycles d’horloge. On exécute en parallèle les instructions indépendantes pour gagner du temps. Un processeur possède plusieurs Unité Arithmétique et Logique. Les instructions peuvent être réarrangées afin d’améliorer le rendement (out of order execution).
Multi-cœur : Un cœur est une unité exécutant les instructions dans un processeur. D’où le multi-cœur est l’ensemble de plusieurs unités exécutant des instructions en parallèle. Multi-cœur (tous sur un même circuit) multiprocesseur (circuits différents)
3. Les objectifs du parallélisme
Un gain de performance
▪ Multiplier les ressources matérielles pour diviser le temps d’exécution d’autant
▪ Accroitre la taille des problèmes à résoudre
▪ Mais un gain linéaire est difficile à obtenir
Un gain conceptuel
▪ Plusieurs expressions des modèles de calcul parallèle
▪ Une approche intrinsèquement parallèle des problèmes peut déboucher sur des solutions plus efficaces
Mais aussi : répartition de l’ampliation et tolérance aux pannes
4. L’exploitation du parallélisme :
Les trois phases de l’exploitation
Exhibition : construction d’algorithmes parallèles
▪ Rechercher et mettre en évidence le caractère parallèle d’une application
▪ Analyser les graphes de données et de contrôle de l’application
▪ Prévoir le parallélisme théorique maximum qui pourra être obtenu
Extraction : exprimer les algorithmes parallèles dans un modèle de calcul (ex: CSP, message passing, fork and join)
Exécution : les modèles de calcul sont mis en œuvre conjointement
▪ Par des outils logiciels (compilateurs optimisant, interprètes…)
▪ Par des outils matériels (architectures matérielles parallèles)
Chaque étape introduit des contraintes qui limitent les performances.
5. Les 3 sources du parallélisme
|
Table des matières
REMERCIEMENTS
LISTE DES SYMBOLES ET ABREVIATIONS
LISTE DES TABLEAUX
LISTE DES FIGURES
INTRODUCTION
PARTIE I: Système de contrôle-commande
I. Généralités
1. Définition
2. Les différents systèmes de contrôle-commande
3. Caractéristiques de systèmes de contrôle-commande
4. Architectures logicielle et matérielle
II. Contrôle-commande temps réel
1. Noyau de système d’exploitation
2. Noyau temps réel
3. Concepts des tâches
4. Gestion des tâches
5. Outils de communication et de synchronisation
6. Gestion du temps
7. Ordonnancement
8. Implémentation des applications de contrôle-commande temps réel
III. Spécification et conception d’une application de contrôle-commande
1. La méthode SA-RT
2. La méthode DA-RT
PARTIE II: La technique multitâche et la programmation parallèle
I. Technique multitâche
1. Généralité
2. Notion de processus et threads
3. Définition d’une tâche et d’une application multitâche
4. La technique multitâche ou la gestion multitâche
5. Type de programme multitâche
6. Multitâche, multithreading, multitraitement
II. La programmation parallèle
1. Pourquoi la programmation parallèle ?
2. Définition
3. Les objectifs du parallélisme
4. L’exploitation du parallélisme
5. Les 3 sources du parallélisme
III. Multithreading en Java
1. La classe thread et l’interface runnable
2. Créer, lancer et stopper un thread
3. Ordonnancement
4. Cycle de vie d’un thread
5. Groupe de threads
6. Manipulation des threads [3]
b) Join
7. Avantages et inconvénient d’une application multithread
PARTIE III: Etude de cas reel et simulation du système de contrôle-commande temps réel avec java
I. Cahier de charge
1. Cas réel
2. Modèle réduit du cas réel
II. Spécification des processus et tâches aves la méthode SA-RT
1. Diagramme de contexte
2. Diagramme de flot de données et de contrôle, diagramme préliminaire et diagramme état/transition
3. Dictionnaire de données et processus primitifs du diagramme préliminaire
III. Conception des communications et synchronisations des tâches avec la méthode DA-RT
IV. Implémentation sur JAVA
1. Diagramme des classes
2. L’implémentation sur JAVA
3. Résultats
CONCLUSION
BIBLIOGRAPHIE
ANNEXE
Télécharger le rapport complet
