Mohamed Ben Ali Mediouni

Mohamed Mediouni ([email protected]) Téléphone :+21622582534

2.1. Définition d’un système temps réel : 2.1.1.

Temps partagé et temps réel

La gestion du temps est un problème majeur pour les systèmes d'exploitation. En effet la ressource principale qui est le processeur ne peut traiter qu’une tâche à la fois alors que ces systèmes sont quasiment tous dit multitâches. Cela oblige le système à allouer du temps processeur entre les différentes tâches. Cette notion de partage implique une gestion de ressources d’une tâche à l’autre. Cette gestion est mise en œuvre par un ordonnanceur (scheduler) suivant un ensemble d'algorithmes. Un système d'exploitation classique comme UNIX, LINUX ou Windows utilise la notion de temps partagé, par opposition au temps réel. Dans ce type de système, le but de l'ordonnanceur est de donner à l'utilisateur une impression de confort tout en s'assurant que toutes les tâches demandées sont finalement exécutées. Ce type d'approche entraîne une grande complexité dans la structure même de l'ordonnanceur qui doit tenir compte de notions comme la régulation de la charge du système ou la date depuis laquelle une tâche donnée est en cours d'exécution. Il apparait que : La notion de temps n’est pas forcément un paramètre critique. La priorité entre les tâches est peu prise en compte, car l'ordonnanceur a pour but premier le partage équitable du temps entre les différentes tâches du système (on parle de quantum de temps ou tick). Les différentes tâches doivent accéder à des ressources dites partagées, ce qui entraîne des incertitudes temporelles. En effet si une tâche effectue une écriture sur le disque dur, celui-ci n'est plus disponible aux autres éventuelles tâches à un instant donné et le délai de disponibilité du périphérique n'est donc pas prévisible. La gestion des entrées/sorties peut générer des temps morts car une tâche peut être bloquée en attente d'accès à un élément d'entrée/sortie.

La gestion des interruptions reçues n'est pas optimisée car le temps écoulé entre la réception de l'interruption et son traitement n'est pas garanti par le système. L'utilisation du mécanisme de mémoire virtuelle peut entraîner des fluctuations importantes dans les temps d'exécution des tâches.

2.1.2.

Notion de temps réel

Les systèmes informatiques temps réel se différencient des autres systèmes informatiques par la prise en compte de contraintes temporelles dont le respect est aussi important que l'exactitude du résultat, autrement dit le système ne doit pas simplement délivrer des résultats exacts, il doit les délivrer dans des délais imposés. Les systèmes informatiques temps réel sont aujourd'hui présents dans de nombreux secteurs d'activités : dans l'industrie de production par exemple, au travers des systèmes de contrôle de procédé (usines, centrales nucléaires), dans les salles de marché au travers du traitement des données boursières en « temps réel », dans l'aéronautique au travers des systèmes de pilotage embarqués (avions, satellites), ou encore dans le secteur de la nouvelle économie au travers du besoin, toujours croissant, du traitement et de l'acheminement de l'information (vidéo, données, pilotage à distance, réalité virtuelle, etc.). Le développement de systèmes temps réel nécessite donc que chacun des éléments du système soit lui-même temps réel, c’est-à-dire permette de prendre en compte des contraintes temporelles. Un système d'exploitation conçu de cette manière est appelé système d'exploitation temps réel. Il est évident que la structure de ce système dépendra de ces fameuses contraintes. On pourra diviser les systèmes en deux catégories :

2.1.2.1.

Système à contraintes souples

Les systèmes dits à contraintes souples ou molles (soft real time). Ces systèmes acceptent des variations dans le traitement des données de l'ordre de la demi-seconde ou la seconde. On peut citer l'exemple des systèmes multimédia : si quelques images ne sont pas affichées, cela ne met pas en péril le fonctionnement correct de l'ensemble du système. Ces systèmes se rapprochent fortement des systèmes d'exploitation classiques à temps partagé. Ils garantissent un temps moyen d'exécution pour chaque tâche. On a ici une répartition égalitaire du temps CPU entre processus.

2.1.2.2.

Système à contraintes dures

Les systèmes dits à contraintes dures ou strictes (hard real time) pour lesquels une gestion sévère du temps est nécessaire pour conserver l'intégrité du service rendu. On citera comme exemples les contrôles de processus industriels sensibles comme la régulation des centrales nucléaires ou les systèmes embarqués utilisés dans l'aéronautique. Ces systèmes garantissent un temps maximum d'exécution pour chaque tâche. On a ici une répartition totalitaire du temps CPU entre tâches. Les systèmes à contraintes dures doivent répondre à trois critères fondamentaux :  Le déterminisme logique : les mêmes entrées appliquées au système doivent produire les mêmes effets.  Le déterminisme temporel : une tâche donnée doit obligatoirement être exécutée dans les délais impartis, on parle d'échéance.  La fiabilité : le système doit être disponible. Cette contrainte est très forte dans le cas d'un système embarqué car les interventions d'un opérateur sont très difficiles voire même impossibles. Cette contrainte est indépendante de la notion de temps réel mais la fiabilité du système sera d'autant plus mise à l'épreuve dans le cas de contraintes dures. 2.1.2.3.

Dualité temps réel/temps partagé

Un système temps réel n'est pas forcément plus rapide qu'un système à temps partagé. Il devra par contre satisfaire à des contraintes temporelles strictes, prévues à l'avance et imposées par le processus extérieur à contrôler. Une confusion classique est de mélanger temps réel et rapidité de calcul du système donc puissance du processeur (microprocesseur, microcontrôleur, DSP). On entend souvent : « Être temps réel, c'est avoir beaucoup de puissance : des Millions d’instructions par seconde” Ce n'est pas toujours vrai. En fait, être temps réel dans l'exemple donné précédemment, c'est être capable d'acquitter l'interruption périodique (moyennant un temps de latence d'acquittement d'interruption imposé par le matériel), traiter l'information et le signaler au niveau utilisateur (réveil d'une tâche ou libération d'un sémaphore) dans un temps inférieur au temps entre deux interruptions périodiques consécutives. On est donc lié à la contrainte de délai entre deux interruptions générées par le processus extérieur à contrôler.

Il convient donc avant de concevoir un tel système de connaître la durée minimale entre deux interruptions, ce qui est assez difficile à estimer voire même impossible. C'est pour cela que l’on a tendance à concevoir dans ce cas des systèmes performants (en terme de puissance de calcul CPU et de rapidité de traitement d’une interruption) et souvent surdimensionnés pour respecter des contraintes temps réel mal cernées à priori. Ceci induit en cas de surdimensionnement un surcoût non négligeable. En résumé, on peut dire qu'un système temps réel doit être prévisible, les contraintes temporelles pouvant s'échelonner entre quelques microsecondes (µs) et quelques secondes.

2.1.3.

Fondements d’un système temps réel

Les contraintes liées à la taille et à la capacité mémoire, nous font retenir les points essentiels suivant lors d’un développement basé sur un RTOS  Gestion des tâches (priorité, ordonnancement).  Gestion des interruptions.  Gestion des temps (minuteries).  Gestion des communications entre tâches.  Gestion de la mémoire.

2.2. Système embarqué temps réel 2.2.1.

Définition

C’est un système logiciel et matériel servant à résoudre des problèmes spécifiques. Il est embarqué dans le sens où, il fait partie d’un système complet qui n’est pas nécessairement un ordinateur et il est utilisé dans un environnement réactif et contraint en temps. Il réalise un nombre fixe et limité de tâches par opposition à un ordinateur général. La puissance dissipée, le coût, le temps de développement et la fiabilité sont souvent des métriques qui influencent la conception.

2.2.2.

Contexte d’une application temps réel

Une application temps réel prend la forme d’un ensemble de programmes ayant la particularité de démarrer leur exécution en réponse aux stimuli de l’environnement et/ou effectuer des traitements dans un temps borné. Un système d’exploitation temps réel doit donc fournir, outre les services d’un système généraliste, des garanties temporelles portant sur les délais d’exécution des programmes. Pour la plupart des systèmes d’exploitation temps réel, les applications sont placées dans l’espace noyau. Ce principe s’adapte particulièrement bien aux systèmes embarqués minimaux (qui gèrent rarement l’espace utilisateur) ainsi qu’aux applications qui doivent réagir très rapidement aux stimuli de l’environnement. En effet, concernant ce dernier point, les stimuli de l’environnement sont perçus sous forme de mécanismes du noyau appelés interruptions qui n’ont pas besoin d’être relayés par le système d’exploitation si l’application se trouve dans l’espace noyau.

Matériel

Système d’exploitation temps réel

Le fait que les programmes temps réel résident dans l’espace noyau permet de les« rapprocher du matériel », améliorant ainsi grandement les performances en termes de temps de réponse. Toutefois, l’inconvénient majeur de cette approche réside dans l’impossibilité de tirer profit des services uniquement accessibles dans l’espace utilisateur tels que la protection de la mémoire (les erreurs de segmentation qui protègent le système d’exploitation et les autres applications des problèmes d’adressage) et l’utilisation de drivers matériels spécifiquement dédiés à l’espace utilisateur.

2.2.3.

Notion de tâche

2.2.3.1.

Définition d’une tâche

Une tâche est un programme élémentaire qui est lancé par le noyau où une autre tâche qui possède des propriétés spécifiques (priorité, temps processeur, données ….) .Il contient des fonctions qui rendent la main au noyau, ou donnent la main à d’autres tâches. Il peut être dans différentes : endormie, en attente, prête, active, interrompue.

2.2.3.2. Notions associées Plusieurs notions peuvent être liées à une telle tâche :  Section critique : c’est un morceau du code qui ne doit pas être interrompu. Son utilisation est nécessaire lorsqu’il ya un accès à des ressources partagées par plusieurs processus (tâche en cours d’exécution). Il existe plusieurs moyens pour la protéger soit par un sémaphore ou par d’autres primitives de la programmation concurrente.

 Ressource : toute entité utilisée par une tâche.  Ressource partagé : entité utilisé par plusieurs tâches.

2.2.3.3.

Noyau préemptif et un noyau non préemptifs

Dans un noyau préemptif, un processus (thread) peut être interrompu (préempté) par l’ordonnanceur si un processus plus prioritaire se trouve dans l’état prêt. Dans un noyau non préemptif, ce changement de contexte n’aura lieu que lorsque le système passe de mode noyau au mode usager. En effet les événements asynchrones sont gérés par des ISR, la tâche de plus haute priorité prend le contrôle à la fin de l’exécution de la tâche en cours.

2.3. Le noyau temps réel C/OS-II 2.3.1.

Préliminaire

COS-II est un noyau temps réel de type préemptif développé par Jean J. Labrosse capable de gérer plusieurs tâches simultanément. Son plus grand atout est certainement que son code source soit accessible librement (www.uCOS-II.com) pour le développement d’applications non-commerciales. Il est donc actuellement très bien documenté et très robuste. Comme principal défaut par rapport aux noyaux commerciaux, précisons que COSII ne gère pas l’algorithme de Round-Robin permettant à deux tâches de même priorité de partager l’usage du CPU. On est ici obligé de ne permettre qu’une seule tâche par niveau de priorité.

2.3.2.

Spécificités et choix du C/OS-II

Il existe une multitude de systèmes d’exploitation temps réel tels que ITRON, FreeRTOS, LynxOS, ChorusOS, PSOS, ART Linux Windows CE, et bien d’autres. Ces systèmes peuvent être dédiés à une fonctionnalité spécifique ou être généraliste. Le choix d’un noyau doit donc être lié aux exigences du développeur. Notre choix s’est porté sur le C/OS-II car se dernier est fourni avec son code source accessible librement et présentant des caractéristiques essentielles et académiques pour le développement des systèmes embarqués :

 Portable : Le code source du noyau C/OS-II est écrit en ANSI C et en assembleur. Donc il est assez facile d’effectuer les modifications nécessaires en vue de son intégration dans le microcontrôleur.  Encapsulable (ROMable) : µC/OS-II a été développé pour les applications embarquées. En effet, il suffit d’avoir un environnement de développement intégrant un compilateur C, un éditeur de lien et un débogueur pour pouvoir concevoir et implémenter des applications embarquées qui s’exécutent sur le noyau temps réel C/OS-II.  Ajustable : Le noyau C/OS-II propose un panel de services tels que les boites aux lettres, les files d’attente, les sémaphores, les fonctions de gestion de mémoire, les fonctions de gestion de temps et de surveillance de la CPU, et bien d’autres. Ces fonctions sont indispensables dans le développement des applications temps réel. Ainsi dans un souci d’optimisation des ressources, certains services peuvent être implémentés ou pas en fonctions des besoins de l’application à implémenter.

2.3.3.

Gestion des tâches

2.3.3.1. Niveaux de priorités dans le µC/OS-II A partir de la version 2.80, le noyau C/OS-II est capable de gérer jusqu’à 255 tâches simultanément. En effet, le code source était modifié pour permettre de gérer 255 tâches au lieu de 64. 2.3.3.2. Les états d'une tâche dans le µC/OS-II Au niveau du noyau C/OS-II, une tâche est une boucle infinie qui peut être dans l’un des cinq états suivants:  Endormie (Dormant): Cet état correspond à une tâche qui réside dans la mémoire mais le noyau ne la considère pas dans l’ordonnancement.  En attente (Waiting) : Une tâche dans cet état attend la réalisation d’un événement.  Prête (Ready): Une tâche qui est dans cet état peut s’exécuter mais elle est moins prioritaire que la tâche qui est en exécution.  Active (Running): C’est un état de la tâche qui gagne le contrôle de la CPU .  Interrompue (Interrupted): Cet état résulte de l’interruption de l’exécution de la

tâche.

Les états d’une tâche dans le RTOS µC/OS-II

2.3.3.3.

Communication entre les tâches

Dans un environnement où plusieurs tâches doivent se partager l’utilisation d’une ressource, il est indispensable de mettre sur pied un mécanisme de synchronisation et d’harmonisation des activités afin d’optimisé l’utilisation de la ressource et permettre ainsi un bon fonctionnement de l’application. Dans le noyau C/OS-II on trouve trois moyens de communication qui sont les sémaphores, les boîtes aux lettres et les files d'attente.

 Les sémaphores Un sémaphore est un entier qui permet de résoudre le problème lié à l’accès à la ressource lorsque nous avons plusieurs tâches concurrentes. Il est constitué d'un compteur à valeur entière (valeur du sémaphore) et d'une file d'attente.

Ressources partagées

Tâche A

Libération

Acquisition

Tâche B

Sémaphore Présentation du concept de sémaphore

 Les boîtes aux lettres Une boîte à lettre est une zone d'échange de taille non fixe permettant la transmission des données d'une tâche à une autre. Les boîtes aux lettres constituent une alternative à l'utilisation de mémoire partagée et permettent de synchroniser la communication entre des tâches asynchrones.

 Les files d'attente Les files d'attente fournissent des liaisons entre émetteurs et récepteurs de messages. Ainsi l'expéditeur et le récepteur d’un message ne soient pas contraints de s'attendre l'un l'autre. Des messages placés dans la file d'attente sont stockés, jusqu'à ce que le destinataire les recherche. L'expéditeur n'a pas à attendre que le récepteur commence à traiter son message, il poste son information et peut passer à autre chose.

Références Bibliographiques  Introduction aux systèmes temps-réel. C. Bonnet, I. Demeure. Hermès, 1999  Isabelle PUAUT / Rémi COZOT, Université de Rennes I « Programmation temps-réel Cours 1 et 2 : Introduction et ordonnancement »  Introduction d’un système temps-réel « concepts de base »ECOLE POLYTECHNIQUE MONTREAL ».  Travail de fin d’études Présenté par Olivier Dubois & Bram De Wachter UNIVERSITE LIBRE DE BRUXELLES : Faculté des Sciences appliquées « Année académique 2000-2001 »  µc/OSII the real- time kernel Second Edition use this complete “Portable, Romable, scalable preemptive”. RTOS in your own product. JEAN .J.LABROSSE CMP Books, 2002 ISBN1-57820- 103-9