Systèmes d`exploitation Temps Réel
publicité
Systèmes d'exploitation Temps Réel Plan du cours fonctionnalités d'un système d'exploitation ● fonctionnalités d'un système d'exploitation temps réel ● exemples ● F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 2 système d'exploitation ● un programme qui permet à un utilisateur « ordinaire » d'accéder à toutes les fonctionnalités du processeur : ➢ ➢ ➢ ➢ ➢ ➢ à la CPU à la mémoire aux fichiers aux périphériques au réseau etc... cache la complexité des opérations ● permet d'accéder à des ressources privilégiées sans avoir besoin de droits spéciaux (et dangereux...) ● F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 3 système d'exploitation ● suivant le contexte de leur utilisation, on trouve ➢ les OS simple utilisateur ✔ ➢ par opposition aux OS multi-utilisateurs les OS mono-tâches ✔ par opposition aux OS multi-tâches ✘ ✘ ➢ les OS distribués ✔ ➢ ➢ ● gérant les ressources de plusieurs machines reliées par un réseau les OS embarqués les OS temps réels ils peuvent être ➢ généralistes ✔ ➢ fonctionnant souvent en temps partagé spécialisés ✔ F. Touchard préemptif ou coopératifs développés pour un domaine restreint d'applications Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 4 exemples de systèmes d'exploitation ● OS généralistes ➢ ➢ ● OS embarqués ➢ ➢ ● ➢ ➢ VxWorks Linux + patch PREEMPT-RT Xenomai OS spécialisés ➢ ➢ ➢ ➢ F. Touchard uClinux Windows CE OS temps réels ➢ ● Windows Linux (Fedora, Debian, Ubuntu, etc...) Android BlackberryOS iOS OSEK/VDX (automobile) Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 5 systèmes d'exploitation temps réels ● un système d'exploitation avec des propriétés particulières liées à la nature des applications qu'il contribue à mettre en œuvre ➢ ➢ mécanismes « standards » pour la gestion des ressources (CPU , mémoire, etc...) mécanismes et outils spécifiques pour assurer ✔ ✔ la prédictibilité du comportement le respect des échéances ✘ ✘ F. Touchard ordonnancement gestion du temps avec une précision compatible avec l'échelle de temps de l'application Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 6 services attendus d’un RTOS ● gestion des activités (threads) ➢ ➢ ➢ ● gestion du temps ➢ ➢ ● horloges timers communication et synchronisation ➢ ➢ ➢ F. Touchard création suspension destruction files de messages mémoire partagée sémaphores, mutexes, variables conditionnelles Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 7 services attendus d’un RTOS ● notifications asynchrones ➢ ● gestion de la mémoire ➢ ➢ ➢ ● signaux, événements mémoire virtuelle verrouillage de la mémoire protection de la mémoire entrées-sorties ➢ ➢ ➢ open read write directs ou asynchrones ● gestion du réseau F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 8 la norme POSIX les services sont fournis par des fonctions spécifiques du système d'exploitation ● la norme POSIX propose une interface assurant la portabilité des applications ● ➢ ➢ ➢ ● Portable Operating System Interface dans un environnement à la UNIX développée par l'IEEE pour le temps réel ➢ POSIX1.b ✔ ✔ ✔ ✔ ➢ POSIX1.c ✔ F. Touchard ordonnancement signaux timers, horloges communication threads Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 9 architecture d'un RTOS ● dans la plupart des cas ➢ ➢ un noyau ou micro-noyau fournissant les fonctions de base des couches logicielles fournissant les fonctions plus élaborées Espace utilisateur Espace noyau interruptions extérieures exceptions hw/sw appels systèmes interruptions horloge gestion des tâches, IPC, temps, interrupts, etc... Matériel F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 10 prise de contrôle par le noyau Interruptions exceptions extérieures hw/sw appels systèmes interruptions de l'horloge Trap switch Immediate interrupt service appel à l'ordonnanceur Noyau F. Touchard Polytech Marselle Département MT create_thread suspend_thread destroy_thread ... create_timer timer_sleep timer_notify ... open read ... etc... Services liés au temps et ordonnanceur retour d'exception Systèmes d'exploitation Temps Réel 11 appels systèmes ● fonctions exécutées par le noyau au nom d'une tâche utilisateur ➢ ● implique un changement de contexte d'exécution ➢ ➢ ● ➢ ➢ le noyau exécute un « retour d'exception » la CPU repasse en mode « normal » l'ordonnanceur est appelé et la tâche de plus haute priorité prend la CPU dans beaucoup de processeurs embarqués ➢ ➢ F. Touchard sauvegarde du contexte d'exécution de la tâche passage de la CPU en mode privilégié (« noyau ») une fois la fonction terminée ➢ ● permettent d'accéder de façon « sûre » à des ressources privilégiées pas de mode privilégié l'appel système est traité comme une procédure ordinaire Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 12 services liés au temps ● l'ordonnancement des activités est au cœur du travail du noyau ➢ ● l'activation périodique de l'ordonnanceur est provoquée par une horloge dédiée (pas celle de la CPU) ➢ ● génère une interruption à chaque tick (~ milliseconde) à chaque interruption, le noyau ➢ ➢ ➢ F. Touchard mis en œuvre périodiquement et dès qu'une tâche se termine gère tous les timers, en déclenchant éventuellement les actions liées aux timers qui viennent d'expirer gère les budgets de temps d'exécution des tâches met à jour la liste des tâches prêtes et invoque l'ordonnanceur Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 13 interruptions extérieures ● le plus souvent dues à l'interaction avec du matériel ➢ occurrences d'événements externes liés à des activités sporadiques dues à des entrées/sorties ✔ ➢ ● temps de réponse très variables prise en charge par la CPU en passant par un mode spécial « interruption » ➢ ➢ ➢ ➢ ➢ F. Touchard capteurs, interfaces réseaux, périphériques (disques) niveaux de priorités dépendant de l'origine de l'interruption désactivation de la prise en compte des interruptions sauvegarde du contexte d'exécution et branchement à un point spécial de l'OS réactivation des interruptions et exécution d'une routine dédiée (ISR) reprise du cours normal d'exécution Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 14 interruptions extérieures ● si une interruption de priorité supérieure se produit pendant l'exécution de l'ISR, elle est prise en charge immédiatement par le système ➢ sinon, on attend la fin du traitement de l'interruption en cours system shutdown priority power down priority clock interrupt priority highest interrupt priority other interrupt priorities lowest interrupt priority dispatcher/scheduler priority highest thread priority other interrupt priorities lowest thread priority F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 15 interruptions extérieures ● en cas de partage de la même ligne d'interruptions (fréquent sur les systèmes embarqués) ➢ polling des dispositifs qui partagent la ligne ✔ ➢ ou bien utilisation d'un vecteur d'interruption ✔ ● le dispositif responsable passe à l'OS un « vecteur » contenant l'adresse spécifique à laquelle se brancher le plus souvent l'ISR ne traite pas complètement l'interruption ➢ ➢ temps le plus court possible dans le mode interruption réveil d'une tâche dédiée ✔ ✔ F. Touchard le dispositif responsable de l'interruption se signale à l'OS dans l'espace noyau ou utilisateur ordonnancée Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 16 services liés au temps ● au moins une horloge présente dans les RTOS ➢ ➢ ● pour chaque horloge ➢ ➢ ➢ ● ➢ ➢ F. Touchard compteur liste de timers traitant d'interruption (handler) pour incrémenter le compteur et voir quels timers ont expiré résolution ➢ ● à ne pas confondre avec l'horloge de la CPU dans les systèmes POSIX : CLOCK_REALTIME liée à la capacité à traiter les interruptions de 10 ms à quelques centaines de µs peut être très améliorée dans certaines architectures en utilisant l'horloge de la CPU (Time Stamp Counter) POSIX1.b : chaque thread/process peut avoir ses propres horloges et timers, basés sur des temps absolus ou relatifs, synchrones ou asynchrones Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 17 services liés à l'ordonnancement ● implémentation d'algorithmes d'ordonnancement ➢ algorithmes à priorités fixes ✔ ✔ ➢ algorithme à priorités variables ✔ ➢ ✔ F. Touchard EDF blocage de la préemption ✔ ➢ SCHED_FIFO SCHED_RR le plus souvent par inhibition de l'ordonnanceur pendant un temps le plus court possible gestion des serveurs de tâches apériodiques Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 18 communication et synchronisation ● fonctionnalités essentielles pour l'activité des tâches ➢ communication ✔ ✔ ➢ synchronisation ✔ F. Touchard échange d'informations de contrôle échange d'informations de données définir le moment et les conditions où ces échanges peuvent avoir lieu Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 19 communication et synchronisation ● communication par files de messages ➢ ➢ ➢ ➢ ➢ ➢ ● communication par mémoire partagée ➢ ➢ ➢ ➢ F. Touchard simple et efficace possibilité de communiquer dans un environnement distribué possibilité de synchronisation par des mécanismes d'écriture et de lecture bloquants possibilité de notification asynchrone d'écriture dans une file vide possibilité de définir des niveaux de priorité des messages possibilité d'implémenter un protocole d'héritage de priorité très rapide nécessite des moyens de synchronisation possible de communiquer dans un environnement distribué (projection de fichiers sur un disque) complexe et très risqué !... Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 20 communication et synchronisation ● mécanismes de synchronisation ➢ ● plusieurs mécanismes ➢ ➢ ➢ ➢ ● F. Touchard essentiels dans un environnement multithreadé sémaphores mutexes variables conditionnelles verrous lecteurs/écrivain peuvent permettre la mise en place des protocoles d'héritage de priorité ou de priorité plafonnée pour prendre en compte les problèmes d'inversion de priorité ou de deadlock Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 21 notification par événement ● nécessaire de notifier de façon asynchrone l'occurrence de faits importants ➢ ➢ ➢ ➢ ● le plus souvent (POSIX) par le mécanisme de signaux ➢ ● expiration d'un timer réception d'un message terminaison d'une entrée-sortie asynchrone etc... Asynchronous Procedure Calls sous Windows notification par un mécanisme analogue à celui des interruptions ➢ quand le thread est notifié par un signal ✔ ✔ ✔ ✔ F. Touchard il interrompt le cours de son exécution le processeur passe en mode interruption un traitant (handler) exécuté le processeur repasse en mode normal et invoque l'ordonnanceur Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 22 notification par événement ● la notification peut aussi s'effectuer de façon synchrone ➢ ● limitations des signaux ➢ ➢ ➢ ➢ ● F. Touchard le thread qui attend l'événement se bloque jusqu'à l'occurrence du signal pas nombreux pas de mise en queue pas de déterminisme dans l'ordre de prise en compte ne transportent pas d'information en partie résolu par les signaux temps réels de POSIX Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 23 les RTOS du marché il existe de nombreux systèmes d'exploitation ayant des propriétés conformes à la liste des fonctionnalités que nous venons de voir ● deux grandes catégories ● ➢ OS généralistes ✔ ✔ ✔ ✔ ➢ OS spécialisés, développés dans le cadre d'un secteur d'activité déterminé (télécommunications, avionique, automobile, défense...) ✔ ✔ ✔ ● F. Touchard VxWorks Xenomai (Linux) QNX LynxOS OSEK/VDX iOS Android ils peuvent être ouverts ou propriétaires Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 24 les RTOS du marché ● motivations pour des systèmes généralistes ➢ la plupart des applications ont besoin de services "généraux" ✔ ✔ ➢ souci de minimiser les phases de développement ✔ ✔ ➢ F. Touchard accès à des fichiers accès au réseau minimiser les coûts réutilisation de composants souci de portabilité des applications, indépendance vis-à-vis de la plate-forme d'exécution Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 25 les RTOS du marché ● motivations pour des systèmes spécialisés ➢ performances ✔ ➢ ➢ utilisations très spécifiques marché captif ✔ ✔ ✔ ➢ F. Touchard adéquation au matériel utilisé automobile avionique télécoms quand le coût n'est pas un argument... Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 26 VxWorks ● RTOS propriétaire produit par Wind River (filiale de Intel) ➢ ➢ ➢ ➢ ● le plus utilisé dans le monde de l'embarqué rendu célèbre par la mission Pathfinder sur Mars équipe la plupart des missions NASA (Curiosity) dernière version : VxWorks 7 (février 2014) peu d'informations sur l'architecture de l'OS ➢ ➢ ➢ non UNIX, mais interface conforme à POSIX construit autour d'un micronoyau (WIND) les applications, les protocoles de communication sont complètement séparés du noyau ✔ ➢ ➢ ➢ F. Touchard évolution du système plus facile et sûre accent mis sur la connectivité supporte les architectures multiprocesseurs, symétriques et asymétriques, aussi bien que monoprocesseur supporte les architectures avec ou sans MMU Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 27 VxWorks ● faible empreinte mémoire ➢ ➢ ● disponible sur de nombreuses architectures ➢ ➢ ➢ ➢ ➢ ➢ F. Touchard 20 kB pour le micronoyau adaptable à la configuration utilisateur ARM (9, 11) Intel Pentium (2, 3, 4, M) Intel XScale (IXP425, IXP465) MIPS (4K, 5K, ...) PowerPC SuperH (4, 4a) Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 28 Linux Linux n'est pas un RTOS ● points forts ● ➢ ➢ ➢ ➢ ➢ ● points faibles ➢ ➢ ● empreinte opensource (licence GPL) il existe des solutions pour faire de Linux un RTOS : ➢ ➢ F. Touchard fiable bon marché performant portable (conforme à POSIX) ouvert aux autres systèmes adjonction d’un co-noyau temps réel modifier Linux pour avoir un noyau entièrement préemptible Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 29 Linux ● approche « noyau entièrement préemptible » ➢ ➢ ➢ ➢ modifier le noyau pour que les tâches non temps réel et dont les temps d’exécutions ne sont pas connus n’interfèrent pas avec les tâches temps réel complexe (le noyau est gros) mais seuls le cœur du noyau et quelques pilotes doivent être modifiés (travail d’experts) patch PREEMPT_RT Real Time Linux Wiki (https://rt.wiki.kernel.org/) ✔ ✔ ✔ ✔ ➢ F. Touchard prise en compte des interruptions par des threads noyaux implémentation de l'héritage de priorité remplacement des spinlocks par des mutex mise en place de compteurs à haute précision pour exprimer les délais et les échéances approche généralement suffisante pour le temps réel mou ou ferme Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 30 Linux ● approche « co-noyau » ➢ ➢ solution « classique » (a existé même pour Windows : RTX) impossible de faire confiance au noyau GPOS pour les aspects temps réels ✔ ✔ ➢ ➢ ➢ le noyau temps réel intercepte toutes les interruptions matérielles et les traite avant de les passer éventuellement au noyau Linux (PIC virtuel) Linux fonctionne avec une priorité inférieure à celle du noyau temps réel mais ✔ ✔ F. Touchard délègue ceux-ci à un noyau spécialisé le noyau Linux continue à servir les tâches classiques nécessité de porter sur le noyau temps réel tous les pilotes dont on attend une réponse temps réel les appels aux fonctions de la glibc peuvent avoir des latences importantes Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 31 Linux ➢ plusieurs approches ✔ support pour l’exécution des tâches temps réel dans l’espace utilisateur ✘ ✘ ✔ tâches temps réel uniquement dans l’espace noyau (modules ) ✘ F. Touchard Xenomai RTAI RTLinux/GPL Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 32 Xenomai basé sur les spécifications ADEOS (Adaptive Domain Environment for Operating Systems) de Karim Yaghmour ● projet initialement créé pour faciliter le portage des applications temps réel vers un RTOS de type Linux (virtualisation) ● F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 33 Xenomai ● abstraction des propriétés communes des RTOS traditionnels ➢ couche générique H/W (HAL) et S/W (SAL) ➢ « peaux » pour émuler les RTOS traditionnels applications dans l’espace utilisateur interface interface appels appels systèmes systèmes Linux Linux VxWorks VxWorks RTAI RTAI VRTX VRTX POSIX POSIX ... ... couche couche générique générique temps temps réel réel (Xenomai (Xenomai core) core) applications dans l’espace noyau (pilotes) SAL/HAL SAL/HAL I-Pipe I-Pipe F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 34 Xenomai ● « interrupt pipeline » pour organiser la distribution des interruptions de façon à ce que le noyau Linux ne retarde pas leur prise en compte par le RTOS ➢ ➢ implémentation de ADEOS organise un ensemble de domaines connectés par le pipeline ✔ ✔ partagent le même espace d’adresses implémentés sous forme de module Interruptions et traps Xenomai (primaire) F. Touchard Polytech Marselle Département MT bouclier à interruptions Systèmes d'exploitation Temps Réel Linux (secondaire) 35 Xenomai ● deux types de threads peuvent coexister : ➢ threads contrôlés par l'ordonnanceur du noyau Xenomai (threads temps réels, ou threads Xenomai) ✔ ➢ font appel à des fonctions spécifiques pour toutes les opérations temps réel threads contrôlés par Linux quand un thread Xenomai fait un appel système qui n'est pas pris en charge par le noyau Xenomai, il migre vers le domaine Linux, mais reste plus prioritaire que les threads non temps réels ● quand toutes les tâches temps réel ont été effectuées par Xenomai, le contrôle est redonné au noyau Linux ● F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 36 OSEK/VDX exécutif développé dans le cadre des applications embarquées pour le contrôle automobile (automotive) ➢ http://www.osek-vdx.org ● Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug (BMW, Bosch, DaimlerChrysler, Opel, Siemens, VW et l'Université of Karlsruhe) ● ➢ ➢ ● F. Touchard Open Systems and the Corresponding Interfaces for Automotive Electronics Systèmes Ouverts et les Interfaces Correspondantes pour l'Electronique Automobile Vehicle Distributed eXecutive (Renault) Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 37 OSEK/VDX ● ● ● ● ● ● F. Touchard Consortium européen (franco-allemand) depuis 1995 pour les configurations mono processeur avec des contraintes temps réel strictes pour une grande variété d'applications, pour les phases de mise au point aussi bien que pour la production (gestion des erreurs) indépendant du langage de programmation (syntaxe à la ANSI-C) portabilité et ré-utilisation du software Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 38 OSEK/VDX ● organisation du consortium (2011) Comité de direction Adam Opel AG, BMW AG, Daimler AG, IIIT - Univ. Karlsruhe, GIE.RE. PSA, Renault, Robert Bosch GmbH, Continental Automotive GmbH, Volkswagen AG Comité technique STEERING COMMITTEE, Accelerated Technology Inc., ACTIA, AFT GmbH, Ashling, ATM Computer GmbH, Blaupunkt, Borg Instruments GmbH, C&C Electronics, Cambridge Consultants, Continental Teves, Cummins Engine Company, Delco Electronics, Denso, EDS Epsilon GmbH, ETAS GmbH & Co KG, FIAT- Centro Ricerche, Ford (Europe), FZI, GM Europe GmbH, Greenhills, Grupo Antolin, Hella KG, Hewlett Packard France, Hitachi Micro Systems Europe Ltd., Hitex, IBM Deutschland Entwicklung GmbH, Infineon, INRIA, Integrated Systems Inc., Working Group Operating System Working Group Communication IRISA, Lauterbach LucasVarity, Metrowerks Magneti Marelli, Mecel, Motorola, National Semiconductor, NEC Electronics GmbH, Noral, NRTA, Philips Car Systems, Porsche AG, Sagem Electronic Division, Softing GmbH, ST Microelectronics, Stenkil Systems AB,Sysgo Real-Time Solutions GmbH, TECSI, Telelogic GmbH, TEMIC, Texas Instruments, Thomson-CSF Detexis, Trialog, UTA - United Technologies Automotive, Valeo Electronics, VDO Adolf Schindling GmbH, Vector Informatik, Visteon, Volvo Car Corporation, Wind River Systems, 3Soft GmbH. Working Group Network Manag. Working Group Certification Groupe Groupe des des Utilisateurs Utilisateurs F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 39 OSEK/VDX ● exigences spécifiques dues au contexte de développement des applications automobiles ➢ ➢ ➢ ➢ ➢ F. Touchard l'OS est configuré et mis à l'échelle de façon statique (spécification statique du nombre de tâches, de ressources, de services) l'OS est capable de tourner à partir de mémoires ROM l'OS fournit la portabilité des tâches applicatives l'OS doit se comporter de façon prédictible et documentées et se conformer aux exigences temps réel des applications automotives l'OS doit permettre l'implémentation de paramètres de performance prédictibles Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 40 OSEK/VDX architecture générale organisée autour des ECUs (Electronic Control Unit) ● 3 entités : ● ➢ ➢ ➢ F. Touchard OSEK-OS (real time operating system) : environnement d'exécution des ECUs OSEK-COM (communication) : échange de données entre et inter ECUs OSEK-NM (network management) : configuration, registration et monitoring des ECUs Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 41 OSEK/VDX Operating System Communication Interaction Layer (IL) Transport Layer (TL) Network Management Application Data Link Layer (DLL) Communication hardware Data Link Layer (DLL) Réseau (CAN bus) F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 42 OSEK/VDX Priorité haute 3 niveaux d'exécution ➢ interrupt ➢ niveau logique (fonction-nement de l'ordonnanceur) ➢ niveau tâche ● les 3 niveaux vont en ordre décroissant de priorité ● les niveaux de priorité à l'intérieur d'un niveau d'exécution sont définis de façon statique ● Niveau d'interruption sans OS services avec OS services Niveau logique pour l'ordonnanceur Niveau des tâches attente : oui/non 1 2 3 4 Tâches préemption : non/full/mixed basse F. Touchard Polytech Marselle Département MT Systèmes d'exploitation Temps Réel Déroulement du contexte 43 OSEK/VDX ● les services de l'OS gèrent les 3 niveaux d'exécution ainsi que ➢ ➢ ➢ ➢ ➢ ➢ F. Touchard l'administration des tâches l'administration des événements (synchronisation des tâches) l'administration des ressources matérielles partagées les compteurs et alarmes la communication entre tâches par messages le traitement des erreurs Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 44 OSEK/VDX ● développements récents ➢ de plus en plus de technologies "assistées" ✔ ✔ ➢ ➢ ➢ F. Touchard freinage direction beaucoup plus exigeantes en termes de déterminisme et de contraintes temporelles émergence de réseaux sécuritaires (TTP/C, TTCAN, Flexay ) OSEKtime : OS temps réel qui peut gérer, en plus des tâches "classiques" d'OSEK, des tâches "Time Triggered" (TT) Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 45 Conclusions ● dans la conception des applications temps réels, la maîtrise de l'ordonnancement est primordiale ➢ ➢ ➢ ● partage de la CPU entre les différentes tâches constituant l'application gestion des dépendances entre les tâches (partage de ressources exclusives) gestion des situations de surcharges en plus des fonctionnalités normales d'un système d'exploitation classique, un système d'exploitation temps réel va permettre ➢ de mettre en place les algorithmes d'ordonnancement ✔ ➢ de synchroniser les tâches ✔ ➢ F. Touchard priorités relatives des tâches en particulier l'accès aux ressources partagées de communiquer et d'échanger des données entre les tâches Polytech Marselle Département MT Systèmes d'exploitation Temps Réel 46
