Contraintes sur les systèmes TRE

Nous avons vu que la détermination d'une fonction d'évaluation à la fois précise et ecace est cruciale pour permettre la justesse et la performance des algorithmes d'optimisation. Nous présentons ici les contraintes qui s'appliquent aux systèmes TRE, ainsi que des heuristiques permettant de mesurer le degré ou la probabilité de violation de ces contraintes, tant au niveau du modèle qu'à celui des opérations.

4.3.1 Ordonnancement

Par dénition, un système temps-réel doit être strictement ordonnançable. La technique d'or- donnancement utilisée (RMA, EDF, FIFO...) fait varier la taille du sous-ensemble des systèmes ordonnançables, mais visent tous à remplir la condition de l'ordonnancement : assurer que, quelque soit l'exécution, toutes les tâches puissent être exécutées avant leur échéance.

Le problème de l'ordonnancement met en jeu deux aspects diérents : d'une part, l'analyse du pire cas d'exécution (WCET), puis le calcul du temps de réponse des diérentes tâches. Le second aspect utilise les informations produites par le premier, mais ne s'y limite pas. Nous verrons dans cette partie quels sont les problèmes posés par ces deux aspects, et comment nous pouvons les résoudre dans le cadre d'une approche outillée et dirigée par les modèles.

Analyse du WCET

Le WCET peut être calculé de façon statique, ou sa valeur peut être mesurée. Une troi- sième approche consiste à utiliser de façon complémentaire les deux approches précédentes. Les méthodes impliquant des mesures, si elles donnent des valeurs très proches du WCET réel, pré- sentent un risque de sous-estimation qui les disqualie pour les systèmes temps-réels durs [90]. Nous nous limiterons donc à présenter les problématiques liées à l'évaluation statique.

De nombreux travaux ont été eectués pour couvrir l'analyse statique du WCET. Celle-ci, en eet, présente une diculté intrinsèque : les architectures matérielles modernes sont de moins en moins prédictibles, essentiellement pour deux raisons : les caches mémoire, et le pipelining dans les processeurs. A ces deux problèmes s'ajoute celui de l'analyse du ot de contrôle, qui permet de déterminer quels chemins d'exécutions sont possibles.

Cache Le cache permet de réduire les temps de lecture et  dans une moindre mesure  d'écriture pour les données ou les instructions en mémoire. Ce gain, cependant, n'est pas homo- gène : le cache doit charger les données en mémoire en cas de miss. Un enjeu important est donc de déterminer, dans le code fourni, quels éléments amèneront à un miss sur une architecture donnée. L'analyse de cet aspect du WCET est nommé value analysis, et peut orir une image de la plupart des valeurs dans le cache et en mémoire sous l'hypothèse d'un code statique et respectant certaines contraintes [87].

Pipelining Le problème de l'inuence du pipelining est regroupé avec celui du cache sous l'appelation analyse du comportement processeur. Le premier a pourtant des implications parti- culières, puisqu'il permet d'appliquer statistiquement un facteur multiplicateur à l'exécution des instructions. Cette accélération est cependant remise en cause en raison des dépendances que peuvent avoir les diérentes instructions entre elles, et par les branchements conditionnels. Il importe donc de tenir compte de ces éléments pour calculer la vitesse d'exécution eective d'un ensemble d'instructions. Pour cela, il faut produire un modèle temporel du fonctionnement du

4.3. Contraintes sur les systèmes TRE processeur, qui ne peut être obtenu que par une étude très détaillée de celui-ci, et qui permet de suivre l'état du processeur tout au long de l'exécution [57].

Flot d'exécution Le calcul du ot d'exécution revient à construire le graphe des branche- ments et des appels. Quand il est eectué sur du code-source, il est dicile d'en déduire les chemins d'exécution eectifs, car l'étape de la compilation (voire le processeur lui-même) va gé- néralement procéder à des réordonnancements sur le code  c'est pourquoi le ot d'exécution est généralement calculé sur le code machine. Il est cependant très dicile d'inférer le chemin d'exécution à partir du code machine. Les auteurs de [55] proposent une méthode sur le code intermédiaire. Cette méthode utilise une analyse de la valeur des variables associées au compteur de la boucle, pour des compilateurs communs dans l'embarqué. En pratique, les outils existants exigent généralement des indications fournies par l'utilisateur pour calculer les ots d'exécutions. Ce besoin de conguration empêche l'automatisation complète de l'évaluation du WCET. Calcul du temps de réponse

Le calcul du temps de réponse des tâches est un corollaire de l'ordonnancement, puisqu'une des méthodes les plus courantes pour vérier un ordonnancement est d'eectuer une analyse du temps de réponse de chaque tâche dans le pire cas (Response Time Analysis), puis de vérier que les échéances des diérentes tâches sont respectées. Le calcul du temps de réponse dépend de la méthode d'ordonnancement sélectionnée [42]. Une telle opération demande d'avoir une vision de l'ensemble de l'application  puisque les tâches peuvent être en attente du complétement d'autres tâches, et donc concernées par leur temps de réponse. Ce calcul va prendre en entrée les WCETs des diérentes tâches. Les auteurs de [36] proposent une méthode pour calculer en temps linéaire des bornes supérieures pour les diérentes tâches du système, dans un système à priorités xes. On remarquera qu'un tel calcul demande la connaissance d'information architecturales, telles que les dépendances entre les diérentes tâches ou leur priorité.

4.3.2 Dimensionnement

Les systèmes TRE se doivent de respecter les contraintes de dimensionnement, pour assurer leur embarquabilité. L'empreinte mémoire des diérents processes, en particulier, doit respec- ter les limites imposées par l'architecture matérielle. D'autres contraintes de dimensionnement peuvent également s'appliquer, par exemple sur les mémoires spéciques, le nombre de verrous matériels utilisés ou le volume des connexions inter-processus. Dans cette étude, nous nous limi- terons cependant à l'empreinte mémoire.

Taille de la pile

La pile contient les informations liées à la gestion des appels, en particulier les valeurs des diérents paramètres, ainsi qu'un certain nombre de variables de gestion dont le rôle exact dépend de l'architecture matérielle. Puisqu'il dépend directement des diérents appels de sous- programmes, le problème du calcul de la pile est donc similaire à une version simpliée du problème du calcul du WCET qui se réduirait à déterminer les ots de contrôle [88].

Taille des données

L'analyse de la taille des données comporte deux aspects : d'une part l'analyse des variables déclarées statiquement (segments de mémoire data et BSS) et d'autre part l'analyse des données

allouées dynamiquement (le tas). La première partie est simple à eectuer, que ce soit au niveau du code source (on peut simplement sommer les déclarations de variables) ou du code machine (où ces segments apparaissent de façon disctincte du reste du code). Le problème de l'analyse de la taille du tas est pour sa part connu pour être dicile. Celui-ci dépend de l'architecture matérielle, du compilateur et, comme pour l'analyse du WCET, doit prendre en compte les ots d'exécution. Une technique pour calculer la borne supérieure de ce dernier a été proposée par les auteurs de [30].

4.3.3 Sûreté

En plus des aspects liés au temps-réel et à l'embarqué, des contraintes peuvent également découler du contexte éventuellement critique dans lequel le système s'exécute.

La sûreté dans les systèmes informatiques a été traitée de nombreuses façons. Une des ap- proches propose la stricte séparation des partitions, concept venu de celui de Robust Partitioning employé pour la sûreté dans la norme Integrated Modular Avionics (IMA [66]). Cette approche, cependant, soulève la question de l'échange d'informations sécurisé. C'est à cet eet qu'a été conçue l'approche Multiple Independant Levels of Security (MILS [82]). Il s'agit, en utilisant des niveaux de criticité sur les connexions et les partitions, d'orir l'assurance qu'une défaillance dans une partition n'aura pas d'impact sur les partitions de criticité supérieure. Une telle approche permet de contenir strictement les défaillances, et donc de faire tourner plusieurs processes sur le même processeur. Cette technique était utilisée plus anciennement pour assurer la sécurité du système, comme par exemple dans [50].