217 lines
8.5 KiB
TeX
217 lines
8.5 KiB
TeX
\documentclass[a4paper,french,12pt]{article}
|
|
|
|
\title{Programmation Multitâches et Temps Réel}
|
|
\author{}
|
|
\date{Dernière compilation~: \today{} à \currenttime}
|
|
|
|
\usepackage{styles}
|
|
\usepackage{tikz}
|
|
\usetikzlibrary{shapes.multipart}
|
|
\usepackage{xfrac}
|
|
\usepackage{xcolor,colortbl}
|
|
|
|
\begin{document}
|
|
|
|
\maketitle
|
|
\tableofcontents
|
|
|
|
\clearpage
|
|
|
|
\section{Système d'exploitation temps réel}
|
|
|
|
Un système d'exploitation est considéré temps réel si le changement de contexte et le temps de réponse sont inférieurs à 10$\mu{}s$.
|
|
|
|
Quelle est la différence entre un OS classique et un OS temps réel~?
|
|
Un OS classique utilise la notion de temps partagé~:
|
|
|
|
\begin{itemize}
|
|
\item ordonnancement complexe
|
|
\item priorité peu considérée (partage équitable)
|
|
\item gestion des temps CPU limitée
|
|
\item incertitudes sur les temps
|
|
\item noyau non préemptif
|
|
\item la gestion des I/O peut générer des temps morts
|
|
\end{itemize}
|
|
|
|
Un OS temps réel~:
|
|
|
|
\begin{itemize}
|
|
\item ordonnancement temps réel
|
|
\item gestion strict de la priorité
|
|
\item perception du temps (donc plus de précision)
|
|
\item noyau préemptif
|
|
\item primitives de synchronisation
|
|
\item respect total ou partiel de la norme POSIX
|
|
\end{itemize}
|
|
|
|
\subsection{Contraintes matérielles}
|
|
|
|
\begin{itemize}
|
|
\item processeur~: horloges, \ldots
|
|
\item mémoire~: RAM, ROM, EPROM, \ldots
|
|
\item interruption du processeur
|
|
\item I/O~: les bus
|
|
\end{itemize}
|
|
|
|
\subsection{Validation d'une application en temps réel}
|
|
|
|
\begin{itemize}
|
|
\item Par prototypage, par exemple la méthodologie $A^3$ (adéquation, algorithme, architecture) pour Cycab (véhicule électrique semi-autonome).
|
|
\item Par analyse statistique (projet Heptane de l'IRISA).
|
|
\item Par simulation (simulateur RTFSim).
|
|
\item Par techniques hybrides.
|
|
\end{itemize}
|
|
|
|
\subsection{Contraintes temporelles}
|
|
|
|
Elles peuvent être strictes~: le dépassement d'une échéance conduit à un état grave.
|
|
Par exemple contrôle d'une unité de production industrielle (centrale nucléaire, usine chimique\ldots).
|
|
Il faut alors respecter strictement toutes les contraintes temporelles.
|
|
|
|
Elles peuvent être souples~: le dépassement d'une échéance conduit à un état dégradé mais non grave.
|
|
|
|
Elles peuvent aussi être fermes~: la contrainte est sévère mais une faible probabilité de manquer les limites temporelles peut être tolérée.
|
|
|
|
En réalité, la majorité des systèmes temps réel sont hybrides.
|
|
Certaines tâches sont à contraintes souples, d'autres ont des contraintes strictes.
|
|
|
|
\subsection{Modèles d'arrivées des tâches}
|
|
|
|
\paragraph{Modèle périodique}
|
|
|
|
\paragraph{Modèle apériodique}
|
|
|
|
Une tâche apériodique ne s'exécute~:
|
|
|
|
\begin{itemize}
|
|
\item qu'une seule fois (inter-arrivée infinie)
|
|
\item à un instant à priori inconnu par le système
|
|
\end{itemize}
|
|
|
|
\paragraph{Modèle sporadique}
|
|
|
|
Une tâche sporadique est une tâche~:
|
|
|
|
\begin{itemize}
|
|
\item dont on connait l'inter-arrivée minimale séparant deux arrivées successives (abusivement appelée la période)
|
|
\item dont on ne connaît pas l'inter-arrivée maximale
|
|
\item dont les dates d'activation sont à priori inconnues
|
|
\end{itemize}
|
|
|
|
\subsection{Échéances}
|
|
|
|
\begin{itemize}
|
|
\item L'échéance relative~: c'est une durée.
|
|
\item L'échéance absolue de terminaison au plus tard~: c'est une date.
|
|
Il y a l'échéance de terminaison au plus tôt et l'échéance de démarrage au plus tard.
|
|
\end{itemize}
|
|
|
|
Quand on parle juste d'échéance, on parle d'échéance de terminaison au plus tard.
|
|
|
|
\subsection{Conception}
|
|
|
|
\begin{itemize}
|
|
\item Déterminaison des modules sujets aux temps réel.
|
|
\item Description des contraintes temporelles.
|
|
\item Représentation logique et temporelle du système.
|
|
\item Prédéterminaison des paramètres temporels.
|
|
\item Choix de l'architecture logicielle et matérielle.
|
|
\item Évaluation des performances.
|
|
\item Validation de l'application.
|
|
\end{itemize}
|
|
|
|
\subsection{Support langage}
|
|
|
|
Un langage de programmation temps réel doit pouvoir~:
|
|
|
|
\begin{itemize}
|
|
\item manipuler des tâches
|
|
\item gérer la synchronisation
|
|
\item évaluer le comportement des tâches
|
|
\end{itemize}
|
|
|
|
Les points importants considérés par la spécification du langage~:
|
|
|
|
\begin{itemize}
|
|
\item ordonnancement des tâches
|
|
\item gestion de la mémoire
|
|
\item partage des ressources et synchronisation
|
|
\item horloges et timers
|
|
\end{itemize}
|
|
|
|
\subsection{Ordonnancement}
|
|
|
|
Dans un système multi-tâches, de nombreux processus attendent qu'un évènement se produise.
|
|
Ils n'ont pas besoin du processeur, mais doivent pouvoir l'obtenir en priorité.
|
|
|
|
\paragraph{Types d'ordonnancement}
|
|
|
|
\begin{itemize}
|
|
\item Souples
|
|
\item Strictes
|
|
\begin{itemize}
|
|
\item Dynamique
|
|
\item Statique
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
Le rôle d'un ordonnanceur temps réel est de vérifier la faisabilité du système.
|
|
Il garantit que l'arrivée d'une nouvelle tâche, acceptée par l'ordonnanceur, sera ordonnançable.
|
|
|
|
\paragraph{Priorités}
|
|
|
|
Les ordonnanceurs peuvent être à priorité fixe (chaque tâche conserve sa priorité durant toute sa durée de vie), ou à priorité dynamique (la priorité d'une tâche peut changer pendant son exécution).
|
|
Les ordonnanceurs à priorité fixe sont plus répandus.
|
|
|
|
Les priorités peuvent être déterminées selon~: l'échéance relative (D~: durée), la période (T~: échéance) ou l'importance de la tâche (P).
|
|
|
|
On peut alors avoir~:
|
|
|
|
\begin{itemize}
|
|
\item Rate Monotonic (RM) ---
|
|
La tâche ayant la plus petite période est la plus prioritaire.
|
|
\item Deadline Monotonic (DM) ---
|
|
La tâche ayant la plus petite échéance relative est la plus prioritaire.
|
|
\item Highest Priority First (HPF) ---
|
|
Les priorités sont attribuées aux tâches selon leur importance.
|
|
\end{itemize}
|
|
|
|
Exemples d'ordonnanceurs à priorités dynamiques~:
|
|
|
|
\begin{itemize}
|
|
\item La tâche peut changer de priorité à chacune de ses activations, selon un des paramètres variables suivants~:
|
|
\begin{itemize}
|
|
\item D (échéance absolue)
|
|
\item T (période)
|
|
\item C (temps d'exécution restant)
|
|
\end{itemize}
|
|
\item Earliest Deadline First (EDF) ---
|
|
La tâche la plus proche de son échéance absolue aura la priorité la plus élevé.
|
|
C'est l'ordonnanceur le plus optimal.
|
|
\item Least Laxity First (LLF) ---
|
|
La tâche la plus prioritaire est celle de moindre laxité (différence entre l'échéance absolue et l'instant de terminaison de la tâche si on l'exécute totalement).
|
|
\end{itemize}
|
|
|
|
\paragraph{Analyse de faisabilité}
|
|
|
|
Calcul de la charge du processeur (U = CPU Utilization), le temps processeur nécessaire à l'exécution des tâches~:
|
|
|
|
\begin{align*}
|
|
U = \sum_{i=1}^n \frac{C_i}{T_i} \leq 1
|
|
\quad \text{avec}
|
|
\left\{
|
|
\begin{array}{l}
|
|
C \text{ le coût de la tâche } \\
|
|
T \text{ la période de la tâche } \\
|
|
\end{array}
|
|
\right.
|
|
\end{align*}
|
|
|
|
Dans le cas d'un ordonnanceur à priorités fixes (Rate Monotonic), la charge maximale est inférieure à 1.
|
|
Elle dépend du nombre de tâches dans le système~:
|
|
|
|
\begin{align*}
|
|
U = \sum_{i=1}^n \frac{C_i}{T_i} \leq U_{RM} \quad \text{avec} \quad U_{RM} = n (2^{\frac{1}{n}} - 1)
|
|
\end{align*}
|
|
|
|
\end{document}
|