C03 Rtos

Systèmes d'exploitation
Temps Réels
F. Touchard Polytech Marseille INFO4 2016-17 Introduction aux systèmes Temps Réels Systèmes d'exploitations pour le temps réel 1
Introduction
● système d'exploitation ou exécutif temps réel
➢ fournir à l'utilisateur un environnement lui permettant de
mettre en œuvre facilement son application, en lui cachant
un certain nombre de problèmes (gestion des
périphériques, des fichiers, interruptions, etc...)
➢ constitué d'un ensemble de primitives chargées de fournir
cette fonctionnalité
✔ souvent (mais pas toujours) exécutées en mode noyau
(appels système, ou system calls)
✔ interfacées avec l'utilisateur par des fonctions dites
"systèmes" (de la libc dans les environnements à la UNIX)
➢ possédant des fonctionnalités spécifiques pour gérer les
contraintes temporelles
✔ le comportement du système doit être prédictible en terme de
temps de réponse
✔ il doit fournir les outils pour aider à respecter les échéances
les exécutifs du marché
● plusieurs dizaines de systèmes d'exploitation temps réel
➢ la plupart sont des OS généralistes
✔ VxWorks
✔ QNX
✔ ChorusOS (VirtualLogix)
✔ pSOS+
✔ VRTX
✔ Windows CE
✔ Xenomai
➢ beaucoup plus de systèmes spécialisés développés dans le
cadre d'un secteur d'activité (automobile, avionique,
téléphonie, etc...)
✔ OSEK/VDX
✔ IPhone, Android, Windows Phone 7
➢ ouverts ou propriétaires
● motivations pour des systèmes généralistes
➢ la plupart des applications ont besoin de services
"généraux"
✔ accès à des fichiers
✔ accès au réseau
➢ souci de minimiser les phases de développement
✔ minimiser les coûts
✔ réutilisation de composants
➢ souci de portabilité des applications, indépendance vis-à-vis
de la plate-forme d'exécution
● Motivations pour des systèmes spécialisés
➢ performances
✔ adéquation au matériel utilisé
➢ utilisations très spécifiques
➢ marché captif
✔ automobile
✔ avionique
✔ télécoms
➢ quand le coût n'est pas un argument...
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 interruptions exceptions appels interruptions

extérieures hw/sw systèmes horloge
Espace noyau gestion des tâches, IPC, temps, interrupts, etc...
Matériel
prise de contrôle par le noyau
Interruptions exceptions appels interruptions
extérieures hw/sw systèmes de l'horloge
Trap
switch
create_thread
Immediate suspend_thread Services liés
interrupt destroy_thread au temps et
service ... ordonnanceur
create_timer
timer_sleep
timer_notify
appel à ...
l'ordonnanceur open
read
...
etc...
Noyau retour d'exception
appels systèmes
● fonctions exécutées par le noyau au nom d'une tâche
utilisateur
➢ permettent d'accéder de façon « sûre » à des ressources
privilégiées
● implique un changement de contexte d'exécution
➢ 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
➢ 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
➢ pas de mode privilégié
➢ l'appel système est traité comme une procédure ordinaire
services liés au temps
● l'ordonnancement des activités est au cœur du travail du
noyau
➢ mis en œuvre périodiquement et dès qu'une tâche se
termine
● 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
➢ 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
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
✔ capteurs, interfaces réseaux, périphériques (disques)
➢ temps de réponse très variables
● prise en charge par la CPU en passant par un mode
spécial « interruption »
➢ 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
● 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

● 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
✔ le dispositif responsable de l'interruption se signale à l'OS
➢ 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
✔ dans l'espace noyau ou utilisateur
✔ ordonnancée
services liés au temps
● au moins une horloge présente dans les RTOS
➢ à ne pas confondre avec l'horloge de la CPU
➢ dans les systèmes POSIX : CLOCK_REALTIME
● pour chaque horloge
➢ compteur
➢ liste de timers
➢ traitant d'interruption (handler) pour incrémenter le compteur
et voir quels timers ont expiré
● résolution
➢ 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
services liés à l'ordonnancement
● implémentation d'algorithmes d'ordonnancement
➢ algorithmes à priorités fixes
✔ SCHED_FIFO
✔ SCHED_RR
➢ algorithme à priorités variables
✔ EDF
➢ blocage de la préemption
✔ le plus souvent par inhibition de l'ordonnanceur
✔ pendant un temps le plus court possible
➢ gestion des serveurs de tâches apériodiques
✔ SCHED_SPORADIC
communication et synchronisation
● fonctionnalités essentielles pour l'activité des tâches
➢ communication
✔ échange d'informations de contrôle
✔ échange d'informations de données
➢ synchronisation
✔ définir le moment et les conditions où ces échanges peuvent
avoir lieu
● communication par files de messages
➢ 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é
● communication par mémoire partagée
➢ 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é !...
● mécanismes de synchronisation
➢ essentiels dans un environnement multithreadé
● plusieurs mécanismes
➢ 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
notification par événement
● nécessaire de notifier de façon asynchrone l'occurrence
de faits importants
➢ expiration d'un timer
➢ réception d'un message
➢ terminaison d'une entrée-sortie asynchrone
➢ etc...
● le plus souvent (POSIX) par le mécanisme de signaux
➢ Asynchronous Procedure Calls sous Windows
● notification par un mécanisme analogue à celui des
interruptions
➢ quand le thread est notifié par un signal
✔ 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
notification par événement
● la notification peut aussi s'effectuer de façon synchrone
➢ le thread qui attend l'événement se bloque jusqu'à
l'occurrence du signal
● limitations des signaux
➢ 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
Études de cas
● VxWorks
● OSEK/VDX
● extensions Temps Réel pour Linux : Xenomai
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
✔ é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
VxWorks
● faible empreinte mémoire
➢ 20 kB pour le micronoyau
➢ adaptable à la configuration utilisateur
● disponible sur de nombreuses architectures
➢ ARM (9, 11)
➢ Intel Pentium (2, 3, 4, M)
➢ Intel XScale (IXP425, IXP465)
➢ MIPS (4K, 5K, ...)
➢ PowerPC
➢ SuperH (4, 4a)
Linux
● Linux est un système d'exploitation généraliste
➢ réponse « statistique » pour donner à chacun un temps de
réponse « acceptable » et un comportement « équitable »
➢ pas conçu pour fournir un comportement temporel
déterministe
● mais Linux est un noyau offrant beaucoup de qualités
➢ gratuit et open source
➢ stable
➢ bons temps de réponse moyens en situation de forte
charge
➢ conforme aux extensions temps réel de POSIX.4
✔ ordonnancements FIFO et RR
✔ priorités temps réel (de 1 à 99) indépendantes de l'interactif
➢ ordonnancement SCHED_DEADLINE (EDF + CBS) depuis
3.14 (pas défini dans POSIX)
✔ plus d'infos : man 7 sched
Linux
● l'approche préférée de Linus Torwalds fait que Linux reste
malgré tout un système orienté vers le temps partagé
● on peut cependant rester dans un cadre « Linux » et voir
une comportement « temps réel »
● 2 approches pour avoir un comportement temps réel
➢ noyau complètement préemptible (patch RT_PREEMPT)
➢ co-noyau (RTLinux, Xenomai)
approche PREEMPT-RT
● modifications apportées au noyau Linux pour lui donner
un comportement temps réel
● présentées sous forme d'un patch
● philosophie de la démarche :
➢ l'essentiel du code du noyau est constitué par les drivers
➢ seuls les drivers qui seront utilisés par l'application temps
réel devront avoir un comportement temps réel
➢ les parties du cœur du noyau qui peuvent affecter le
comportement temps réel sont celles où la préemption est
désactivée, et concernent
✔ le verrouillage
✔ la gestion des interruptions
● l'essentiel du travail des développeurs va concerner la
vérification et la modification éventuelle des drivers pour
éviter la désactivation de la préemption
approche PREEMPT-RT
● modifications du noyau
➢ prise en compte des interruptions par des threads « kernel »
✔ autorise la préemption des ISR
➢ mise en place de mécanismes d'héritage de priorité basé sur
des mutex
➢ remplacement des spinlocks par des mutex
➢ mise en place de timers à haute précision pour exprimer les
délais et les échéances en microsecondes
● solution suffisante pour la plupart des applications
➢ mais disponible de façon satisfaisante seulement sur x86 et
x86_64
➢ plus d'infos sur https://rt.wiki.kernel.org/
approche co-noyau
● 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
✔ délègue ceux-ci à un noyau spécialisé
✔ le noyau Linux continue à servir les tâches classiques
➢ 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
✔ 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
Linux
➢ plusieurs approches
✔ support pour l’exécution des tâches temps réel dans l’espace
utilisateur
✘ Xenomai
✘ RTAI
✔ tâches temps réel uniquement dans l’espace noyau
(modules)
✘ RTLinux/GPL
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)
● la version que nous utilisons est Xenomai-2.6.4 (septembre
2014)
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
applications dans
VxWorks
VxWorks RTAI
RTAI VRTX
VRTX POSIX
POSIX ...
... l’espace noyau
(pilotes)
couche
couche générique
générique temps
temps réel
réel
(Xenomai
(Xenomai core)
core)
SAL/HAL
SAL/HAL
I-Pipe
I-Pipe
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
interrupts
et traps
domaine de domaine domaine de

priorité max root priorité min
Noyau
Linux
Interrupt Pipeline
● distribution prioritisée des interruptions suivant le schéma
de "protection optimiste des interruptions" :
➢ un domaine peut passer en mode bloqué (stalled)
✔ les interruptions arrivantes ne sont plus distribuées aux
handlers du domaine
✔ les interruptions arrivantes sont accumulées et ne sont plus
transmises aux domaines de priorité inférieure
✔ les domaines de priorité supérieure continuent à recevoir les
interruptions et à les traiter
➢ au déblocage, les interruptions accumulées sont traitées et
éventuellement passées aux domaines de priorité inférieure
● les événements systèmes sont propagés par le même
pipeline abstrait
➢ notifications synchrones d'exceptions (division par zéro,
accès mémoire invalide,...), d'actions exécutées par le
noyau Linux (pagination, ...)
➢ ne peuvent pas être retardées, à l'inverse des interruptions
Xenomai Core
● pour fournir toutes les ressources systèmes utilisées par
les peaux
➢ briques génériques pouvant être spécialisées
➢ groupées dans un module : le noyau Xenomai
● constitué de :
➢ un objet « thread temps réel » contrôlé par un
ordonnanceur temps réel (FIFO par niveau de priorité)
➢ un objet générique « interruption »
➢ un objet « allocateur de mémoire » ayant un temps de
réponse prédictible
➢ un objet générique « synchronisation » dont sont dérivés
les sémaphores, mutexes, files de messages, etc...
➢ un objet « gestion du temps »
peaux Xenomai
● à partir des fonctions de Xenomai Core, plusieurs API ont
été développées
➢ « native »
➢ POSIX (toutes les fonctions de la glibc)
➢ RTDM (pour le développement de drivers temps réels)
et aussi
➢ VxWorks
➢ pSOS+
➢ VRTX
➢ uiTRON
➢ RTAI
● la peau native est la plus « complète » en termes de
fonctionnalités directement fournies
➢ toutes ces fonctionnalités peuvent être obtenues avec la
peau POSIX (code portable)
➢ nous n'étudierons que la peau POSIX
peaux Xenomai
● organisation du logiciel
Coexistence de Linux et Xenomai
● interaction des tâches temps réel avec les tâches non
temps réel
● mécanisme du « real time shadowing »
➢ pour les tâches non temps réel qui deviennent temps réel
➢ objet « RT shadow » attaché à la tâche qui peut être alors
ordonnancée par l’ordonnanceur de Xenomai
➢ partage des structures task_struct (spécifique Linux) et
xnthread (spécifique Xenomai) par les ordonnanceurs
ordonnanceur
ordonnanceur ordonnanceur
ordonnanceur
Linux
Linux Xenomai
Xenomai
lien interne
struct struct
task_struct xnthread
● les threads temps réels peuvent s'exécuter
➢ dans l'espace noyau sous forme de modules noyau
➢ dans l'espace utilisateur (threads Xenomai)
● à ne pas confondre avec les threads Linux classiques,
non temps réel
● les threads Xenomai peuvent s'exécuter
➢ dans le domaine de plus haute priorité du pipeline (mode
d'exécution "primaire")
➢ dans l'espace Linux (mode d'exécution "secondaire"), mais
avec des temps de latence d'ordonnancement un peu plus
grands
● Quand le noyau Xenomai ne « sait » pas répondre à une
demande de service (appel système), c'est Linux qui
prend le contrôle du thread, qui passe donc en mode
secondaire
● pour que les threads Xenomai en mode secondaire
puissent être temps réel, il faut :
➢ un schéma de priorités commun pour le noyau temps réel
et le noyau Linux
✔ si un thread Xenomai en mode primaire passe en mode
secondaire, le noyau Linux va hériter de sa priorité
✔ un thread Xenomai en mode primaire ne va préempter un
thread en mode secondaire que si sa priorité effective est
supérieure
✔ un thread Linux en mode SCHED_FIFO sera toujours
préempté par un thread en mode primaire et sera en
compétition avec les threads en mode secondaire
➢ des temps d'exécution prédictibles
✔ blocage des interruptions destinées à Linux par un domaine
Adeos intermédiaire : le "bouclier à interruptions" (interrupt
shield), activé dès qu'un thread Xenomai tourne en mode
secondaire
➢ un noyau Linux avec un ordonnancement à grain fin pour
les threads Xenomai en mode secondaire
➢ la gestion des inversions de priorité
● pipeline Xenomai
Interruptions
et traps
Xenomai bouclier à Linux

(primaire) interruptions (secondaire)
● propagation des interruptions
➢ le noyau temps réel de Xenomai reçoit en premier les
interruptions
✔ il les traite
✔ il les marque pour être passés dans la suite du pipeline
✔ quand le dernier traitant est terminé, Xenomai donne la CPU
au thread Xenomai de plus haute priorité
➢ quand il n'y a plus de threads Xenomai à exécuter, la CPU
est donnée au bouclier qui va les passer au noyau Linux s'il
est désactivé, ou les bloquer s'il est activé
➢ 2 modes de propagation pour Adeos, par domaine et par
interrupt (implicite ou explicite)
➢ Xenomai utilise le mode explicite
✔ chaque traitant doit faire appel au service de propagation
pour toutes les interruptions prises en compte
✔ si aucun traitant n'a été déclaré, l'interruption est
automatiquement passée au noyau Linux
RTDM
● couche intermédiaire entre une application temps réel et
les services fournis par un pilote
➢ pilotes à protocole (communication par échange de
message)
✔ réseaux temps réel
✔ bus CAN
➢ pilotes pour des périphériques nommés
✔ cf périphériques caractères
Xenomai : développements récents
● Xenomai-3 : première release en octobre 2015
● deux possibilités pour l'utilisateur :
➢ l'approche dual core (dite « Cobalt ») ressemblant à
Xenomai-2 mais avec beaucoup d'améliorations en interne
➢ une nouvelle approche (dite « Mercury ») basée sur le
noyau Linux natif (éventuellement patché avec
PREEMPT_RT)
● les deux approches utilisent une nouvelle interface (dite
« copperplate ») entre les API
ée
st
te
r e
co
en
s
pa
OSEK/VDX
● exécutif développé dans le cadre des applications
embarquées pour le contrôle automobile (automotive)
● http://www.osek-vdx.org
OSEK/VDX
● Offene Systeme und deren Schnittstellen für die
Elektronik im Kraftfahrzeug (BMW, Bosch,
DaimlerChrysler, Opel, Siemens, VW et l'Université of
Karlsruhe)
➢ Open Systems and the Corresponding Interfaces for
Automotive Electronics
➢ Systèmes Ouverts et les Interfaces Correspondantes
pour l'Electronique Automobile
● Vehicle Distributed eXecutive (Renault)
OSEK/VDX
● exécutif développé dans le cadre des applications
embarquées pour le contrôle automobile (automotive)
● 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
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, ETAS GmbH & Co KG, IRISA, Stenkil Systems AB,Sysgo Real-Time Solutions GmbH,
Accelerated Technology Inc., FIAT- Centro Ricerche, Lauterbach TECSI,
ACTIA, Ford (Europe), LucasVarity, Metrowerks Telelogic GmbH,
AFT GmbH, FZI, Magneti Marelli, TEMIC,
Ashling, GM Europe GmbH, Mecel, Texas Instruments,
ATM Computer GmbH, Greenhills, Motorola, Thomson-CSF Detexis,
Blaupunkt, Grupo Antolin, National Semiconductor, Trialog,
Borg Instruments GmbH, Hella KG, NEC Electronics GmbH, UTA - United Technologies Automotive,
C&C Electronics, Hewlett Packard France, Noral, Valeo Electronics,
Cambridge Consultants, Hitachi Micro Systems Europe Ltd., NRTA, VDO Adolf Schindling GmbH,
Continental Teves, Hitex, Philips Car Systems, Vector Informatik,
Cummins Engine Company, IBM Deutschland Entwicklung GmbH, Porsche AG, Visteon,
Delco Electronics, Infineon, Sagem Electronic Division, Volvo Car Corporation,
Denso, INRIA, Softing GmbH, Wind River Systems,
EDS Integrated Systems Inc., ST Microelectronics, 3Soft GmbH.
Epsilon GmbH,
Working Group Working Group Working Group Working Group

Operating System Communication Network Manag. Certification
Groupe
Groupe des
des Utilisateurs
Utilisateurs
Exigences spécifiques
● dues au contexte de développement des applications
automobiles
➢ 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
Architecture générale
● organisée autour des ECUs (Electronic Control Unit)
● 3 entités :
➢ 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
Operating System
Application
Network Management
Communication
Interaction Layer (IL)
Transport Layer (TL)
Data Link Layer (DLL)

Communication hardware
Data Link Layer (DLL)
Réseau (CAN bus)
● OSEK fournit un environnement d'exécution pour les
applications qui peuvent s'exécuter indépendamment
les unes des autres
● 2 interfaces utilisateurs fournies par OSEK pour gérer
les entités qui veulent accéder concurrement à la CPU:
➢ les routines de gestion d'interruption (ISR) gérées par
l'OS
➢ les tâches
✔ basiques
✔ étendues
Priorité
haute
● 3 niveaux d'exécution Niveau

➢ interrupt d'interruption
sans OS services
➢ niveau logique (fonction- avec OS services
nement de l'ordonnanceur)
➢ niveau tâche
● les 3 niveaux vont en Niveau logique pour l'ordonnanceur
ordre décroissant de
priorité Niveau
● les niveaux de priorité à des tâches
attente : oui/non
l'intérieur d'un niveau 2

3
4
d'exécution sont définis 1

Tâches
de façon statique préemption :
non/full/mixed
Déroulement
du contexte
basse
● les services de l'OS gèrent les 3 niveaux d'exécution
ainsi que
➢ 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
Les tâches d'OSEK/VDX
● tâches basiques
➢ sans points bloquants
➢ rend le processeur running
✔ à la terminaison
terminate
✔ préemption par une tâche
de priorité supérieure
✔ sur occurrence d'un
interrupt preempt suspended
✔ 3 états start
✘ running : la tâche a la CPU
✘ ready : la tâche a été préemptée activate
✘ suspended : la tâche est terminée
et attend une requête de ready
ré-activation
● tâches étendues
➢ en plus des propriétés des
tâches basiques, elles running
peuvent invoquer des
services bloquants wait terminate
➢ possèdent un état
supplémentaire : waiting,
pendant lequel elles waiting suspended
attendent l'allocation de la
ressource bloquante preempt
start
activate
release
ready
● les tâches basiques n'ont pas d'autres points de
synchronisation que leur début et leur fin
➢ des applications avec des points internes de
synchronisation seront implémentées par plusieurs
tâches basiques
➢ peu gourmandes en termes de ressources système
(RAM)
● les tâches étendues peuvent se suspendre pour
attendre une information intermédiaire
➢ elles peuvent implémenter une application cohérente en
une seule tâche
➢ elles demandent un peu plus de ressources système
Propriétés des tâches
● activation
➢ 2 primitives
✔ ActivateTask
✔ ChainTask
➢ après l'activation, la tâche est prête dès la 1ère instruction
➢ suivant la classe de conformance, la requête d'activation
est prise en compte ou non :
✔ pas d'instances multiples d'une tâche
✔ les requêtes multiples sont éventuellement mises en queue
pour être prises en compte à la terminaison
Propriétés des tâches
● terminaison
➢ ne peut être provoqué que par la tâche elle-même
➢ 2 primitives
✔ TerminateTask
✔ ChainTask
● activation des tâches périodiques à l'aide de compteurs
(voir plus loin)
● changement de contexte
➢ par appel à la primitive Schedule
➢ par décision de l'ordonnanceur
● priorité
➢ à priorité égale, FIFO par rapport à l'activation
➢ une tâche préemptée est première de la liste d'attente
Politique d'ordonnancement
● valeur des priorités statique (sauf quand on utilise

l'algorithme de priorité plafonnée)
● 3 politiques
➢ préemptif
➢ non préemptif
➢ mixte
Politique d'ordonnancement
● l'ordonnanceur est considéré comme une ressource qui peut
être réservée, empêchant ainsi temporairement la
préemption (appel à la primitive GetRessource)
● l'appel à l'ordonnanceur est effectué dans les conditions
"classiques" (terminaison, opération bloquante, activation
d'une tâche de priorité supérieure, appel à
ReleaseResource, retour d'interrupt)
pas d'appel pendant la routine d'interrupt
Traitement des interruptions
● par une routine dédiée : ISR, généralement dans le
contexte de la tâche interrompue
● acquitte l'interruption sur le contrôleur et la transforme
en action pour l'application (e.g. Event)
● 2 modèles d'ISR
➢ type 1: routine où l'on n'a pas besoin de faire un appel
système → seulement un retard
➢ type 2: déclarée comme telle → appels systèmes pour
l'entrée et la sortie de la routine d'interruption.
pas d'appel à l'ordonnanceur pendant son exécution, pas
d'appel bloquant
Synchronisation par événement
● utilise le modèle synchrone, c'est-à-dire qu'un
événement est généré et attendu de façon explicite
● de type "privé" appartenant au consommateur,
utilisable uniquement pour des tâches étendues
● critère pour la transition waiting → ready quand un au
moins des événements attendus est présent
● un événement est persistant, c'est-à-dire qu'une tâche
dans l'état running demandant à attendre un
événement déjà arrivé va rester dans cet état
● l'effacement d'un événement doit se faire de façon
explicite (permet de simuler des événements fugaces)
● synchronisation de tâches étendues préemptables
✔ exemple de 2 tâches T1 et T2 avec prio(T1) > prio(T2)
✔ T1 est bloquée dans l'attente d'un événement que va
envoyer T2
Ordonnanceur
Evénement de la
tâche étendue 1
Tâche étendue 1 waiting
Tâche étendue 2 running
prio(T1) > prio(T2)
Ordonnanceur
Evénement de la
tâche étendue 1
y
ad
re
Tâche étendue 1 waiting running
Tâche étendue 2 running set event ready
prio(T1) > prio(T2)
Ordonnanceur
Evénement de la
tâche étendue 1
y
ad
re
Tâche étendue 1 waiting running clear event
Tâche étendue 2 running set event ready
prio(T1) > prio(T2)
Ordonnanceur
Evénement de la
tâche étendue 1
y
ad
re
wait for
Tâche étendue 1 waiting running clear event waiting
event
Tâche étendue 2 running set event ready running
prio(T1) > prio(T2)
● synchronisation de tâches étendues non préemptables
Ordonnanceur
Evénement de la
tâche étendue 1
Tâche étendue 1 waiting
Ordonnanceur
Evénement de la
tâche étendue 1
Tâche étendue 1 waiting ready
set
event
Ordonnanceur
Evénement de la
tâche étendue 1
Tâche étendue 1 waiting ready running
set reschedule
Tâche étendue 2 running ready
event
Ordonnanceur
Evénement de la
tâche étendue 1
Tâche étendue 1 waiting ready clear event running
set reschedule
Tâche étendue 2 running ready
event
Ordonnanceur
Evénement de la
tâche étendue 1
wait for
Tâche étendue 1 waiting ready clear event running waiting
event
set reschedule
Tâche étendue 2 running ready running
event
Gestion des ressources
● OSEK-VDX permet la pleine gestion des ressources
critiques
➢ algorithme de la priorité plafonnée pour éviter les
phénomènes d'inversion de priorité et les interblocages
➢ l'algorithme de priorité plafonnée peut être optionnellement
étendu aux accès à des ressources partagées par des ISR
✔ pour assigner les priorités plafonds, des priorités virtuelles plus
grandes que celles des tâches sont assignées aux interrupts
✔ sinon l'OS n'exécutera une ISR que si toutes les ressources
qui y seront demandées sont libres
➢ l'OS interdit l'accès imbriqué à une même ressource
➢ l'ordonnanceur est une ressource
Alarmes et compteurs
● pour le traitement des événements récurrents
➢ timers
➢ nombre de tours de l'arbre à cames
● enregistrés par un objet "compteur" qui compte les ticks
et repasse à 0 quand il atteint la valeur maximale.
Plusieurs alarmes peuvent être associées à un
compteur. Une tâche peut être associée à l'alarme (de
façon statique, à la génération du système)
● à l'occurrence de l'alarme, au choix :
➢ activation de la tâche
➢ signalisation d'un événement de la tâche
➢ exécution d'une routine dans le contexte de l'exécutif
Communication
● par des messages dont la structure est définie à la
génération du système
➢ messages d'événements
✔ messages mis en queue dans une file de message. Mais il
ne peut y avoir qu'une seule tâche en attente
✘ transition d'état demandée, alarmes, etc...
➢ messages d'état
✔ message au "tableau noir", non mis en queue mais
contenu dans un buffer à une place, surécrits quand un
nouveau arrive
✘ résultat d'un capteur...
● modèle de communication asynchrone (les appels en
lecture ou écriture ne sont jamais bloquants)
Communications
● re-synchronisation sur la fin de l'opération par
➢ polling
➢ activation d'une tâche en fin d'opération
➢ signalisation d'un événement en fin d'opération
➢ exécution d'une routine de callback
➢ occurrence d'une alarme si l'opération ne s'est pas
terminée dans un délai de garde
● type de communication défini de façon statique
➢ 1 à 1 (mais on peut définir une liste à la générarion et ne
choisir le destinataire qu'à l'exécution)
➢ 1 à n, chaque destinataire recevant le message
Développements récents
● de plus en plus de technologies "assistées"
➢ 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)
Bus

C03 Rtos

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

C03 Rtos

Загружено:

Авторское право:

Доступные форматы

Systèmes d'exploitation

Espace utilisateur interruptions exceptions appels interruptions

Espace noyau gestion des tâches, IPC, temps, interrupts, etc...

Noyau retour d'exception

other interrupt priorities

lowest interrupt priority

other interrupt priorities

lowest thread priority

applications dans l’espace utilisateur

domaine de domaine domaine de

Xenomai bouclier à Linux

Working Group Working Group Working Group Working Group

Interaction Layer (IL)

Transport Layer (TL)

Data Link Layer (DLL)

Réseau (CAN bus)

● 3 niveaux d'exécution Niveau

➢ niveau logique (fonction- avec OS services

l'intérieur d'un niveau 2

d'exécution sont définis 1

● valeur des priorités statique (sauf quand on utilise

Tâche étendue 1 waiting

Tâche étendue 2 running

prio(T1) > prio(T2)

Tâche étendue 2 running set event ready

prio(T1) > prio(T2)

Tâche étendue 2 running set event ready

prio(T1) > prio(T2)

Tâche étendue 2 running set event ready running

prio(T1) > prio(T2)

Tâche étendue 1 waiting

Tâche étendue 2 running

Tâche étendue 1 waiting ready

Tâche étendue 1 waiting ready running

Tâche étendue 1 waiting ready clear event running

Вам также может понравиться