Un système temps réel est un système (application ou ensemble d’applications) informatique dont le fonctionnement est assujetti à l’évolution dynamique d’un
télécharger 47.7 Kb.
|
Introduction Temps réel
Nous pouvons aussi trouver les qualificatifs suivants :
Exercice : répondre par vrai ou faux Information soumise à des contraintes temps réel = information à obtenir rapidement ……. Traitement temps réel = traitement à effectuer avant une certaine date ……… Traitement temps réel = traitement à effectuer rapidement ……. Information soumise à des contraintes temps réel = information à obtenir avant une certaine date
Le respect des contraintes temporelles d’une application temps réel dépend essentiellement de la dynamique du procédé. Cette caractéristique temporelle peut être très différente suivant l’application : – Milliseconde : systèmes radar, systèmes vocaux, systèmes de mesures… – Seconde : systèmes de visualisation, robotique… – Minute : chaîne de fabrication… – Heure : contrôle de réactions chimiques… Ce paramètre temporel correspond à l’ordre de grandeur de la capacité de réponse ou de traitement du système temps réel.
Les contraintes temporelles peuvent être de deux types :
Ex.: projection vidéo (décalage entre le son et l’image). Ex.: un robot qui capte des infos sur des objets défilant sur un convoyeur
Ex.: contrôle de trafic aérien, système de conduite de missile, etc. Exemple des contraintes temporelles : • Echéance (deadline) à respecter : évènement dont la date est fixée « au plus tard » ou « au plus tôt », • Cohérence temporelle à assurer pour la production de résultats, exemple : synchronisation son/image en multimédia,  • Cadence à préserver pour la présentation de résultats : régularité pour la sortie d’images vidéo Dans le cas des systèmes temps réel dur, on cherchera à être prévisible, déterministe et fiable => Utilisation de techniques mathématiques (ordonnancement, évaluation des pires cas…) Dans le cas des systèmes temps réel lâche, on cherchera à minimiser la probabilité de rater une échéance plusieurs fois de suite... Prédictibilité (predictability): Les performances de l’application doivent être définies dans tous les cas possibles de façon à assurer le respect des contraintes de temps. On parle de pire cas. Déterminisme (determinism): Il n’y a aucune incertitude sur le comportement du système: pour un contexte donné le comportement est toujours le même. Fiabilité (reliability): Capacité d’un système à réaliser et maintenir ses fonctionnalités dansdes conditions normales d’utilisation. En temps réel, la fiabilité concerne le respect des contraintes temps réel. On peut également vouloir que le système reste fiable même si certaines pannes sont apparues, on parle alors de tolérance aux fautes.
Nous pouvons citer quelques exemples d’applications temps réel : Robot de production : un robot, réalisant une activité spécifique (peinture, assemblage, tri) sur une chaîne de production, doit effectuer son travail en des temps fixés par la cadence de fabrication. S’il agit trop tôt ou trop tard, l’objet manufacturier traité sera détruit ou endommagé conduisant à des conséquences financières ou humaines graves. Téléphone mobile : le système de contrôle-commande doit remplir plusieurs fonctions dont certaines ont des contraintes temporelles fortes pour avoir une bonne qualité de service (QoS : Quality of Service ). Ainsi, la première fonction est de transmettre et de recevoir les signaux de la parole (577 μs de parole émises toutes les 4,6 ms et 577 μs de parole reçues toutes les 4,6 ms à des instants différents). En parallèle, il est nécessaire de localiser en permanence le relais le plus proche et donc de synchroniser les envois par rapport à cette distance (plus tôt si la distance augmente et plus tard si la distance diminue). Des messages de comptes rendus de la communication sont aussi émis avec une périodicité de plusieurs secondes. Les contraintes Système de vidéoconférence : ce système doit permettre l’émission et la réception d’images numérisées à une cadence de 20 à 25 images par seconde pour avoir une bonne qualité de service. Afin de minimiser le débit du réseau, une compression des images est effectuée. D’autre part la parole doit aussi être transmise. Bien que correspondant à un débit d’information moindre, la régularité de la transmission, qualifiée par une gigue temporelle, est nécessaire pour une reproduction correcte. De plus ce signal doit être synchronisé avec le flux d’images. L’ensemble de ces traitements (numérisations images et parole, transmission, réception, synchronisation…) sont réalisés en cascade, mais avec une cohérence précise.temporelles imposées au système doivent être imperceptibles à l’utilisateur.
V-1) Architecture logicielle des applications temps réel
D’une manière très générique, la figure suivante donne l’architecture logicielle d’une application temps réel multitâche. Nous pouvons ainsi découper cet ensemble de tâches ou activités selon les groupes suivants : – Tâches d’entrées/sorties : ces tâches permettent d’accéder aux données externes par l’intermédiaire de cartes d’entrées/sorties et ensuite de capteurs et d’actionneurs directement liés au procédé géré. Ces tâches peuvent être activées de façon régulière ou par interruption. – Tâches de traitement : ces tâches constituent le cœur de l’application. Elles intègrent des traitements de signaux (analyse spectrale, corrélation, traitement d’images, etc.) ou des lois de commande (régulation tout ou rien, régulation du premier ordre, régulation PID, etc.). Dans le cadre de ce cours, nous considérerons ces tâches comme des boîtes noires, c’est-à-dire que le traitement effectué par ces tâches relève des domaines comme le traitement du signal, le traitement d’images ou l’automatique, disciplines qui débordent largement le contexte de ce cours. – Tâches de gestion de l’interface utilisateur : ces tâches permettent de présenter l’état du procédé ou de sa gestion à l’utilisateur. En réponse, l’opérateur peut modifier les consignes données ou changer les commandes. Ces tâches peuvent être très complexes et coûteuses en temps de calcul si l’interface gérée est de taille importante (tableau de bord) ou de type graphique (représentation 3D). – Tâches de communications : ces tâches sont destinées à gérer les messages envoyés ou reçus à travers un ou plusieurs réseaux ou bus de terrain. Si ce type de tâches existe, l’application est dite distribuée ou répartie. – Tâches de sauvegarde : ces tâches permettent de stocker l’état du système à des instants fixés. Cette sauvegarde peut être utilisée a posteriori pour analyser le fonctionnement de l’application ou lors d’une reprise d’exécution à une étape précédente. Les tâches obtenues, qui constituent l’application temps réel, ne sont pas des entités d’exécution indépendantes. En effet, certaines tâches sont connectées vers l’extérieur pour les entrées/sorties. De plus elles peuvent être liées par des relations de type: – synchronisation : cela se traduit par une relation de précédence d’exécution entre les tâches ; – communications : à la notion de précédence, traduite par la synchronisation, s’ajoute le transfert de données entre les tâches ; – partage de ressources : les tâches utilisent des éléments mis en commun au niveau du système comme des zones mémoire, des cartes d’entrées/sorties, cartes réseau, etc. Certaines de ces ressources, comme par exemple les zones mémoire, ne sont pas ou ne doivent pas être accessibles, pour avoir un fonctionnement correct, par plus d’une tâche à la fois, elles sont dites ressources critiques . 
Nous pouvons distinguer deux modèles d’exécution de ces systèmes temps réel : l’exécution dite synchrone et l’exécution asynchrone. Nous allons présenter ces deux modèles d’exécution à l’aide d’un modèle d’application très simple. Cette application, constituée d’un ensemble de tâches pour gérer le procédé, intègre en particulier les deux tâches suivantes : – Tâche de lecture des données entrées par l’opérateur à l’aide d’un clavier, appelée « Lecture_consigne ». L’intervention humaine fait que cette tâche peut être longue. – Tâche d’alarme qui se déclenche sur un événement d’alerte correspondant au dépassement d’un paramètre critique, appelée « Alarme ». Celle-ci doit s’exécuter au plus vite pour éviter l’endommagement du procédé. Pour mettre en avant les différences entre les deux modèles d’exécution, nous allons étudier la situation dans laquelle la tâche « Lecture_consigne » s’exécute et la tâche « Alarme » demande son exécution alors que la tâche « Lecture_consigne » n’est pas terminée.  Fig : Modèle d’exécution synchrone d’une application temps réel   Fig : Modèle d’exécution asynchrone d’une application temps réel
Une application temps réel étant par définition un système multitâche, le rôle essentiel du noyau temps réel est donc de gérer l’enchaînement et la concurrence des tâches en optimisant l’occupation de l’unité centrale du système informatique. Les principales fonctions d’un noyau temps réel peuvent être scindées en trois groupes : 1. gestion des entrées/sorties (gestion des interruptions, gestion des interfaces d’entrées/sorties, gestion des réseaux de communications…) ; 2. ordonnancement des tâches (orchestration du fonctionnement normal, surveillance, changements de mode, traitement des surcharges…) ; 3. relations entre les tâches (synchronisation, communication, accès à une ressource critique en exclusion mutuelle, gestion du temps…). Il important de noter que les tâches sont les unités actives du système ; le noyau temps réel n’est actif que lors de son appel. Une tâche activée peut appeler le noyau temps réel par une requête. Les différentes requêtes sont servies par des modules du noyau temps réel appelées primitives. Ensuite le noyau temps réel réactive une tâche de l’application selon l’algorithme d’ordonnancement utilisé. Ainsi, le noyau temps réel centralise toutes les demandes d’activation des tâches et gère des tables lui permettant de comparer les priorités (ou les urgences) et l’état de ces diverses tâches, ainsi que l’état d’occupation des ressources. La décision d’activation d’une tâche étant prise, le noyau temps réel lance les modules de programmes correspondant à cette tâche et lui alloue les ressources disponibles. La tâche activée occupe le processeur jusqu’à la fin de son exécution sous le respect des conditions suivantes : – Elle ne réalise pas d’opérations d’entrées-sorties. – Les ressources utilisées sont disponibles. – Aucun événement extérieur ne revendique le déroulement d’une tâche plus prioritaire.  Fig : Interaction entre les tâches et le noyau temps réel. Nous pouvons donc décrire schématiquement le contexte complet d’exécution d’une application temps réel avec les deux parties : tâches et noyau temps réel  Fig Architecture de l’application : tâches et noyau temps réel.
Comme nous le verrons au cours de ce cours, les langages de développement des applications temps réel sont très divers. Mais, par rapport à l’environnement d’exécution que nous venons de décrire (noyau temps réel avec les trois fonctions décrites : 1. gestion des interruptions, 2. ordonnancement, 3. Relations entre les tâches), il est possible de décliner les langages en trois groupes: – langages standards (langage C…) : le noyau temps réel qui supporte ce type de langage doit être complet puisque le langage n’intègre aucune spécificité de ce domaine de contrôle-commande multitâche ; – langages multitâches (langage Ada…) : ces langages permettent de décrire l’application en termes de tâches ; ainsi le noyau peut être plus réduit et ne comporter que les deux premières fonctions ; – langages réactifs (langages Lustre, Esterel, Signal…) : ces langages donnent non seulement la possibilité de décrire les fonctionnalités du programme, mais aussi l’enchaînement des différentes parties. Le noyau est donc limité à une couche proche du matériel lié notamment à la gestion des interruptions. En revanche, étant donné la possibilité très limitée d’expression de l’aspect fonctionnel, ils sont souvent associés à un langage standard pour palier ce manque.  Fig Langages utilisés pour développer les applications temps réel avec un noyau temps réel (1. gestion des interruptions, 2. ordonnancement, 3. Relations entre les tâches). V-2) Architecture matérielle des applications temps réel L’aspect matériel a une très grande importance dans les applications temps réel. Cette implication est liée d’une part à la connexion directe avec le monde physique réel à l’aide d’une grande diversité de systèmes d’entrées/sorties et d’autre part au matériel informatique parfois spécifique et développé pour une application donnée. À titre d’exemple, les différents calculateurs embarqués dans un véhicule automobile sont dédiés et spécialement développés pour cette application. Dans ces matériels, nous trouvons un processeur de type microcontrôleur redondé pour avoir un haut niveau de sécurité, des composants spécifiques (ASIC : Application Specific Integrated Circuit), une alimentation électrique… Tout ce matériel est ensuite encapsulé dans un boîtier résistant à l’environnement de fonctionnement usuel (chaleur, vibrations, ambiance corrosive, etc.). Enfin, dans de nombreux cas, les applications de temps réel sont de type distribué, c’est-à-dire qu’elles sont composées de plusieurs sites ou processeurs, sur lesquels s’exécutent un environnement multitâche, reliés par un ou des réseaux informatiques (Ethernet, CAN, FIP…). 
La figure suivante représente le cycle en « V » de développement avec le positionnement de quelques-unes de ces méthodes dans ce cycle.   – Méthodes fonctionnelles structurées : • JSD : Jackson System Design (Michaël Jackson, 1981) • SA_RT : Structured Analysis Real Time (Ward-Mellor, 1984 ; Pirbhaï-Hatley, 1986) • DARTS : Design Approach for Real-Time Systems (Gomaa, 1984) • SDL : Specification and Description Language (CCITT, 1988) • MSMC : Modélisation Simulation des Machines Cybernétiques (Brenier, 2001) – Méthodes basées sur les machines à états : • Réseaux de Petri (Petri, 1962) • GRAFCET : Graphe Fonctionnel de Commande Étape Transition (IEC 1988) • Statecharts : (D. Harel, 1987) • Langages réactifs synchrones : Lustre (Caspi, 1991), Esterel (Berry, 1991), Signal (le Guernic, 1991) – Méthodes objets ou orientés objets : • UML : Unified Modeling Language (OMG, 1995) • HOOD : Hiearchical Object Oriented Design (CRI-Cisi Ingénierie-Matra, 1987) Quelques exemples industriels d’applications de contrôle-commande Afin d’illustrer les différents environnements de développements des applications temps réel, nous présentons des exemples industriels issus de programmes de taille importante des années 1990-2000. Ces exemples sont caractérisés par le nom du programme, la ou les sociétés en charge du programme et les méthodes et langages utilisés, soit : – Programme ISO – lnfrared Space Observatory (Aérospatiale/ESA) : ensemble de satellites destinés à une observation de l’espace dans un domaine infrarouge • Spécifications et conceptions : SART et HOOD • Langages : Ada (15 000 lignes), Assembleur (11 000 lignes) – Programme SENIT8 (Dassault Électronique & DCN-Ingénierie) : équipements de gestion et de contrôle-commande du porte-avions Charles de Gaulle • Spécifications et conceptions : SART et Ada-Buhr (proche de la méthode DARTS) • Langages : Ada (1 000 000 lignes), C (400 000 lignes) – Programme Rafale (Dassault Électronique) : avion militaire • Spécifications et conceptions : SA-RT et OMT • Langages : Ada (800 000 lignes à 1 500 000 lignes selon les versions). Nous pouvons remarquer que les environnements de développement intègrent une analyse fonctionnelle et structurée avec SA-RT et une conception orientée objet. Cela est dû essentiellement soit à des obligations du cahier des charges (applications spatiales) soit à la taille de l’application qui justifie une méthode orientée objet.  -- |
similaire:
 | «De par sa qualité audio conforme aux attentes des professionnels, le système Polycom Communicator encouragera les entreprises à... |  | «cross ‐ layer» qui permet alors d'améliorer de façon significative la réactivité du système. Afin de faciliter l'intégration et... |
| «vieillissant» ris. Wds fournit un système de déploiement automatisé afin de distribuer des images systèmes via le réseau. Grâce... | | «charnières» dans le squelette dont l’ouverture et la fermeture favorisent une mobilité orientée dans le sens antérieur. Et l’organisation... |
| «charnières» dans le squelette dont l’ouverture et la fermeture favorisent une mobilité orientée dans le sens antérieur. Et l’organisation... | | «Un Système d’information (SI) est un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures… permettant... |
| «New Technology». Ce système d’exploitation de la firme Microsoft évolue de la manière suivante | | |
| | «l’évolution est un fait scientifique». Mais un fait est par nature irréfutable, c’est-à-dire qu’il est exact, indéniable, et qu’on... |