Méthodologie d'analyse temporelle des applications temps réel à contraintes strictes.

Transcription

1 Méthodologie d'analyse temporelle des applications temps réel à contraintes strictes. Jean-Philippe Babau* - Francis Cottet** * L3i/INSA DeptIF bat Av A. Einstein VILLEURBANNE CEDEX jpbabau@if.insa-lyon.fr **LISI / ENSMA BP FUTUROSCOPE CEDEX ensma.univ-poitiers.fr RÉSUMÉ : Les applications temps réel à contraintes strictes sont des applications où les contraintes temporelles doivent être strictement satisfaites. L étude présentée porte sur le développement d applications multitâches contrôlées par un noyau temps réel. La méthodologie de validation développée s'appuie sur la mise en place d'outils d'analyse temporelle dédiés à chaque étape du cycle de développement. L'environnement de conception intègre la prise en compte des requêtes périodiques et apériodiques et des schémas de programmes exprimant des coopérations fixes ou variables entre les tâches. Après transformation du modèle comportemental en un ensemble de tâches sous forme normale, la validation est basée sur une analyse d'ordonnançabilité. Cette validation est effectuée sur les comportements réalistes de l'application. L'utilisation des outils peut servir à la validation finale de l'application, à une validation anticipée ou à la mise au point de l'application. ABSTRACT : The hard real-time systems, we consider, are composed of a set of tasks. Each of them must be mandatory completed before its deadline. The methodology of validation is based on a set of temporal analysers for each step of the design cycle. The design environment integrates periodic, sporadic tasks as well as servers. Moreover programming schemes with variable co-operation relationships between tasks can be used. After a transformation of the behavioural model into a set of standard tasks associated with a precedence graph, the validation consists of a schedulability analysis. This validation is based on the different realistic behaviours of the system. Then, it is possible to use the different tools in order to obtain the final validation, an anticipated validation or to define the architecture of the system. MOTS CLÉS : système temps réel, ordonnancement, analyse temporelle, validation KEY WORDS : Real-Time Systems, Scheduling, Temporal Analysis, Validation Journal Européen des Systèmes Automatisés

2 2 Journal Européen des Systèmes Automatisées 1. Introduction Le cycle de développement classique d'une application informatique se décompose en cinq étapes principales : la spécification, la conception, le codage, les preuves et les tests, et la validation. Lors de la spécification des applications temps réel à contraintes strictes (ATRCS) des contraintes temporelles sont exprimées et doivent être strictement satisfaites. Le développement de telles applications doit répondre à la principale exigence : la sûreté de fonctionnement. La conception aboutit à un logiciel généralement formé d'un ensemble de modules synchronisées, communicants et partageant des ressources critiques [Sta 88]. L étude présentée porte sur des applications multitâches contrôlées par un noyau temps réel. Le logiciel est écrit d'une part dans un langage de programmation comme le langage "C" et d'autre part sur un noyau temps réel qui fournit au concepteur tous les outils pour contrôler l'environnement logiciel des tâches. Une partie essentielle du noyau temps réel est l'ordonnanceur qui réalise (en environnement monoprocesseur) l'élection de la tâche à exécuter en fonction des diverses contraintes opérationnelles. La plupart des noyaux temps réel existants fournissent un ordonnanceur de type préemptif basé sur des niveaux de priorité. Avant l'exécution du logiciel, le concepteur doit donc réaliser l'affectation des priorités pour chacune des tâches. Lors de la validation temporelle, il doit s'assurer que les tâches se réaliseront à partir de leur date de déclenchement, en fonction de leurs contraintes opérationnelles, dans leur délai (ou échéance) strict donné. Pour éviter l'affectation de priorité suivant des critères non formels, des algorithmes comme "Rate Monotonic" (RM), "Deadline Monotonic" et "Earliest Deadline" (ED) ont été développées dès 1973 [LL 73] [LW 82]. Ces méthodes permettent de définir, d'une part, une politique d'affectation de priorité et, d'autre part, de valider a priori l'application par rapport au critère de respect des délais pour l'ensemble des tâches. La validation se fait par évaluation de conditions nécessaires ou suffisantes ou par simulation d'exécution [LL 73] [Raj 91]. Ces résultats sont obtenus pour des tâches périodiques et indépendantes, modèle de tâches restrictif. Des extensions à ces algorithmes permettent de prendre en compte des tâches apériodiques[ssl 89][SB 94], partageant des ressources critiques [SRL 90] [CL 90] et liées par des relations de précédence [CSB 90]. Dans les algorithmes d'ordonnancement, les tâches sont classiquement représentées par le quadruplé (ri, Ci, Ri, Ti) où ri est la date de départ, Ci la durée d'exécution, Ri l échéance et Ti la période. Pour chaque tâche i, l'appel de chaque ressource Sj est caractérisé par les trois durées suivantes : Ciα(Sj) durée d'exécution avant utilisation de la ressource, Ciβ(Sj) durée d'utilisation de la ressource et Ciγ(Sj) durée d'exécution après libération de la ressource (avec la relation Ci = Ciα(Sj) + Ciβ(Sj) + Ciγ(Sj) ). Enfin, le graphe de précédence est communément utilisé pour représenter les relations de synchronisation entre les tâches. Cet ensemble de caractéristiques temporelles, est nécessaire à la mise en place des algorithmes d'ordonnancement. Il peut être vu comme une forme "normale" des applications temps réel à contraintes strictes.

3 - 3-3 Les méthodologies de validation temporelle définissent des environnements de conception, produisant des applications modélisables, et fournissent aussi les outils de modélisation et d'analyse nécessaires à la validation des applications. Au cours de la conception, ces méthodologies apparaissent classiquement lors des trois phases suivantes : - phase 1 : développement dans un environnement intégrant les concepts de parallélisme : modules s exécutant en parallèle (avec lois d activation) et éléments de coopération/concurrence entre modules. - phase 2 : modélisation temporelle afin de préparer la phase de validation; - phase 3 : validation par évaluation d'une séquence ou de conditions. Les phases 2 et 3 sont spécifiques à la validation temporelle. La phase 1 est commune avec la phase de conception fonctionnelle de l'application. Suivant ces principes, de nombreux langages ou outils ont été développées tels que EUCLID [KS 86] [SHH 91], STRESS [ABR 94] et PERTS[LRD 93]. Pour les applications multitâches, les méthodologies existantes s'appuient sur le code de l'application. Or, à chaque étape du cycle développement, des choix déterminants ont été réalisés qui influencent le comportement temporel de l'application. Dans le but d obtenir une validation, il est donc nécessaire d'accompagner chacune de ces étapes d'une analyse temporelle. Cette analyse a pour objet la détermination, au plus tôt dans le développement, des spécifications temporelles complètes de l'application (ri, Ci, Ri, Ti, relations de précédence, dates d'accès aux ressources). La méthodologie développée possède pour chaque étape du cycle de développement un outil d'analyse temporelle. Cet outil permet de calculer, à partir du modèle défini lors de l'étape étudiée, les caractéristiques temporelles ou leurs contraintes. La démarche proposée englobe les trois phases décrites ci-avant : conception, modélisation, validation. L'analyse temporelle développée dans ce travail porte sur le résultat des diverses phases de conception et non sur les opérations de conception en elles mêmes. Les opérations de raffinement, de rétroconception ou d'itération, inhérentes à la conception ne sont pas détaillées ici. A notre niveau, nous considérons donc une conception linéaire de type cycle en V. Lors de la conception d'applications temps réel, les relations de synchronisation n'apparaissent pas toujours en début ou en fin d'exécution des tâches et ces relations sont souvent variables (conditionnelles). Il devient alors difficile, lors de la phase 2, d'extraire un graphe de précédence cohérent. Or, ce modèle est indispensable pour l'analyse temporelle de l'application, permettant de réaliser une validation temporelle. L'étude que nous présentons se propose d'obtenir, dans ces conditions, le graphe de précédence complet ainsi que les durées à partir d'une ATRCS développée dans un environnement temps réel classique et de réaliser alors une validation réaliste de l'application. Après un bref rappel sur les principaux algorithmes d'ordonnancement choisis et de quelques langages existants, les principes des outils d'analyse temporelle sont présentés pour chaque étape du cycle de développement. Ensuite, l'utilisation des outils de la méthodologie est présentée en montrant en particulier la fonction d'aide au développement.

4 4 Journal Européen des Systèmes Automatisées 2. Ordonnancement des tâches Dans le cadre d'un système monoprocesseur et pour des tâches préemptibles, indépendantes et périodiques, des algorithmes d'ordonnancement sont connus soit par une affectation de priorités statiques selon la plus petite période Rate Monotonic (RM), soit par une affectation de priorités statiques selon la plus petite échéance Deadline Monotonic (DM), soit enfin avec une priorité dynamique établie selon l'échéance dynamique la plus courte Earliest Deadline (ED). Les règles d'affectation de priorités répondent alors aux spécifications suivantes (Pi : priorité de la tâche i) : - RM [LL 73], algorithme statique : Ti < Tj => Pi > Pj - DM [LW 82], algorithme statique : Ri < Rj => Pi > Pj - ED [LL 73], algorithme dynamique ( Ri(t) = ri + Ri - t ) à chaque instant t, Ri(t) < Rj(t) => Pi > Pj Les activations de tâches ne suivent pas toujours une loi strictement périodique. La requête non-périodique arrive à des instants inconnus a priori. Ce type de requête est très fréquent dans le contrôle de procédé car les événements en provenance du procédé sont rarement synchronisés avec le système. Suite à l'arrivée d'une requête, deux actions sont alors à réaliser : - la prise en compte de la requête ; - la réalisation du service lié à la requête. La première action doit être réalisée immédiatement après l'arrivée de la requête car son rôle est de mémoriser l'occurrence de la requête. La deuxième action correspond à l'exécution du traitement lié à la requête. La réalisation de cette action est régie selon deux principes. Soit le service est réalisé selon un mécanisme particulier traité par un algorithme exécuté en ligne (traitement immédiat ou traitement dans les temps creux), soit le service est réalisé par des tâches classiques (périodiques ou apériodiques). Cette deuxième approche, lorsqu'elle est possible, est souhaitable car elle permet de maîtriser les caractéristiques temporelles du service et donc de mieux contrôler l'analyse temporelle de l'application. Les serveurs sont traités comme des tâches affectées de paramètres liés aux caractéristiques temporelles de la ou des requêtes apériodiques à servir [LSS 87] [SLS 88] [SSL 89] [SB 94]. Une application temps réel est souvent un ensemble de tâches qui partagent des ressources critiques matérielles ou logicielles. Pour gérer l'accès aux ressources, pour éviter l'inversion de priorité et pour prévenir l'interblocage, un protocole à héritage de priorité (PHP) avec une priorité plafond (PPP) peut être utilisé [CL 90] [SRL 90]. Ces politiques en rapport avec RM, DM ou ED permettent de définir des nouvelles conditions suffisantes d'ordonnançabilité en présence de ressources critiques. Elles permettent en plus de borner le temps d'attente maximum sur libération d'une ressource.

5 Protocole à héritage de priorité La tâche en section critique hérite de la priorité maximum des tâches bloquées. - Protocole à priorité plafond La priorité plafond d'une ressource est la priorité maximum des tâches pouvant la demander. Une tâche ne peut entrer en section critique que si sa priorité est strictement supérieure aux priorités plafonds des ressources alors allouées. Enfin, les relations de synchronisation exprimées sous forme de relations de précédence peuvent être intégrées dans les caractéristiques temporelles des tâches pour revenir à un problème plus classique de tâches indépendantes. Nous traitons des relations de précédence avec des tâches non périodiques et périodiques. Dans le cas de tâches périodiques, les tâches possèdent la même période. Soient deux tâches A et B, de période TA, TB avec la relation "A avant B", nous imposons l'égalité : TA = TB. L'objectif des algorithmes de prise en compte des relations de précédence est de transformer la configuration de tâches avec relations de précédence en une configuration de tâches indépendantes. Cette nouvelle configuration, lors de l'ordonnancement doit alors nécessairement vérifier les relations de précédence imposées. L'idée des algorithmes est donc d'intégrer explicitement ou implicitement les relations de précédence dans l'affectation de priorité. En effet, la priorité permet d'assurer un ordre d'exécution entre les tâches. Pour que ce principe soit correct, il est nécessaire qu'une tâche ne soit jamais activée avant que les tâches devant la précéder le soient. En effet, pour respecter les relations de précédence, il est nécessaire qu'une tâche ne s'exécute jamais avant une tâche la précédant. Ces principes définissent un ordre partiel de priorité pour des tâches de même période. Cet ordre ne doit pas contredire les ordres de priorité entre tâches de périodes différentes. En résumé, dans le cas où la tâche A précède la tâche B, les algorithmes de précédence, respectent les principes suivants : - rb ra - Si une tâche est périodique, l'autre l'est obligatoirement : TA = TB. - PA > PB dans le respect de l'algorithme d'ordonnancement choisi Pour des tâches périodiques de même période appartenant à un graphe de précédence, l'algorithme RM ne spécifie pas le choix des priorités. Pour tenir compte des règles de précédence énoncées ci-avant nous appliquons les algorithmes suivants - RM ri* = Max (ri, rjpréc) Ti < Tj =>Pi >Pj Ti = Tj, tâchei précède tâchej => Pi > Pj Ti = Tj, tâchei et tâchej indépendantes, Ri <Rj => Pi >Pj Ti = Tj, Ri = Rj, tâchei et tâchej indépendantes, i<j => Pi > Pj - préc : prédécessseur, i et j sont les numéros des tâches

6 6 Journal Européen des Systèmes Automatisées Dans le cas de l'algorithme DM, on applique alors le même algorithme que pour RM. Afin de rester cohérent il est nécessaire qu'une tâche précédant une autre possède un délai inférieur à cette dernière, soit : - DM ri* = Max (ri, rjpréc) Ri* = Min(Ri, Rj succ) Ri* < Rj* =>Pi >Pj Ri* = Rj*, tâchei précède tâchej => Pi > Pj Ri* = Rj*, Ti < Tj (tâchei et tâchej indépendantes) => Pi >Pj Ri* = Rj*, Ti = Tj, tâchei et tâchej indépendantes, i<j => Pi > Pj - succ : successeur Avec "ED" la prise en compte de la précédence des processus est basée sur la modification de deux des attributs temporels des tâches : la date d'activation et l'échéance [CSB 90]. - ED (di : échéance dynamique absolue) ried = Max(ri, rjpréc + Cjpréc) died = Min(di, djsucc -Cjsucc) RiED = died - ried di < dj =>Pi >Pj di = dj, temps d'attente(tâchei )>temps d'attente(tâchej) => Pi >Pj di = dj, temps d'attente(tâchei )>temps d'attente(tâchej), i<j => Pi > Pj Il est à noter que les algorithmes liés à la prise en compte de la précédence sont compatibles avec les algorithmes d'affectation de priorité en présence de ressources critiques [SS 94]. 3. Langages et outils Nous présentons rapidement trois environnements temps réel représentatifs du domaine. Ils couvrent l ensemble des trois phases de l analyse temporelle (conception, modélisation temporelle, validation) Le langage Real Time EUCLID est un langage multitâche qui intègre des fonctionnalités de synchronisation entre tâches. Le corps des tâches est écrit dans un langage algorithmique impératif classique. Le langage permet de préciser les caractéristiques ri, Ti des tâches. Les tâches ne font appel à aucune primitive de synchronisation en cours d'exécution. Lors de la compilation, une modélisation temporelle est réalisée qui conduit à la construction d'une séquence d'exécution et donc à la validation de l'application. Le langage EUCLID englobe donc les trois phases conception, modélisation et validation. Le langage STRESS est un langage de modélisation temporelle d'applications temps réel conçues dans un environnement de conception basé sur un langage algorithmique impératif classique gérant les synchronisations et les ressources critiques. Les durées sont ici représentées par le triplet : durée minimale, durée

7 - 7-7 moyenne, pire durée. Les tâches sont supposées avoir une borne maximale pour leur durée d exécution. Un outil permet de réaliser une analyse d'ordonnançabilité de l'application modélisée. STRESS englobe donc les deux dernières phases modélisation et validation. Enfin, lors de la phase de validation, on peut utiliser l'outil PERTS [LRD 93]. Ce dernier permet de décrire graphiquement les caractéristiques opérationnelles d'une application temps réel multitâche avec partage de ressources critiques en environnement multiprocesseur. Une validation temporelle est alors possible selon les politiques d'ordonnancement RM, DM et ED. Les schémas de programme proposées par ces environnements sont simples. Ils ne permettent pas l expression de comportements variables des tâches en terme de synchronisation. Enfin, ils ne couvrent pas l ensemble du cycle de développement de l application. Certaines données, telles les périodes, sont connues a priori. 4. Principes de la méthodologie L'analyse temporelle développée dans ce travail porte sur le résultat des diverses phases de conception et non sur les opérations de conception en elles mêmes. Les différentes étapes de la méthodologie développée sont représentées sur la figure 1. Le fonctionnement des outils n'est possible que si le prototype conçu à chaque étape est temporellement modélisable et analysable. Ceci conduit à imposer des règles de conception spécifiques de manière à rendre l'application analysable d'un point de vue temporel. Ces contraintes apparaissent soit sous la forme de règles de conception à respecter (pas de récursivité lors du codage,...), soit sous la forme d'ensemble de modèles de conception standards fournis au concepteur (modèles de tâches, schémas de programme). Les caractéristiques temporelles obtenues, après analyse, sont alors des valeurs ou des paramètres. La deuxième solution est souhaitable car, lors de la validation, il est préférable d'avoir des paramètres que l'on pourra ajuster plutôt que de posséder des valeurs fixes imposées. On peut alors itérer sur la modification des paramètres (dans le respect des contraintes obtenues sur les paramètres lors des diverses analyses) afin d'obtenir la validation d'ordonnançabilité et les performances temporelles finales souhaitées. Le but final de la méthodologie fonctionnelle et opérationnelle est la description par le concepteur de l'application comme un ensemble de tâches. Ces dernières sont décrites afin de pouvoir fonctionner avec un exécutif temps réel multitâches à niveaux de priorités, gérant les tâches périodiques, les interruptions et les ressources critiques.

8 8 Journal Européen des Systèmes Automatisées Etape du développement Conception préliminaire Conception détaillée Codage Règles de conception Spécification synchronisation entre les tâches schémas de programme Principes des outils d'analyse Résultats après réalisation de l'étape Formalisme Description des entrées/sorties modélisation et des fonctionnalités Formalisme de pré et post conditions Description des éléments composant l'application (tâches, événements,...) Formalisme de pré et post conditions Description de l'architecture logicielle des tâches Langage algorithmique et noyau générique Analyse temporelle association signal-tâches Découpage caractéristiques temporelles obtenues dmin, dv, RE. ri, Ri, Ti Ci (Dij) Ci!, Ci ", Ci # règles de génie logiciel Description algorithmique des divers blocs fonctionnels Langages applicatifs Mesure de durée {Dij} Figure 1. Etapes de la méthodologie de développement avec analyse temporelle. 5. Spécification La spécification est l'élément de référence pour la validation. Lors de la spécification d'une application temps réel, on décrit, en particulier, l'ensemble des signaux échangés, entrées ou sorties, entre le procédé et l'application (SA-RT "Structure Analysis for Real Time" [HP 91]). La spécification doit permettre d'identifier correctement les besoins temporels de l'application. Ces dernières sont dues au procédé (contraintes physiques), à l'utilisateur (besoins spécifiques), et aux signaux (contraintes matérielles). Ces diverses contraintes sont dérivées, dans notre approche, en des contraintes de validité sur les signaux d'entrée (événements, mesures, consignes), des contraintes d'intégrité sur les signaux de sortie (commandes, affichages) du procédé à contrôler et des contraintes de temps de réponse à des requêtes en provenance du procédé. Une contrainte de validité correspond à la définition d un intervalle de temps (fenêtre temporelle) durant laquelle un signal est considéré valide. Une contrainte d intégrité correspond à la définition d une fréquence minimale de production d un signal. L'analyse temporelle

9 - 9-9 correspond alors à une modélisation des signaux basée sur une taxonomie temporelle des signaux. Les divers modèles sont à composante spatiale (donnée permanente ou à durée de validité finie) et/ou temporelle (événements périodiques, cycliques et sporadiques) (cf. figure 2). Les signaux sont, considérés comme indépendants. Dans l étude présentée, il n a pas été prévu d exprimer de relations du type : «le signa1 sl est présent si le signal s2 est absent». 6. Conception préliminaire Au niveau de la conception préliminaire, on dégage l'ensemble des tâches ainsi que leurs caractéristiques temporelles (ri,ri,ti). Afin de pouvoir prendre en compte les différentes classes d'activités rencontrées dans les applications temps réel, le modèle temporel des tâches, exprimant les spécifications temporelles, conduisent classiquement aux deux types de tâches suivants : - les tâches matérielles qui peuvent être déclinées en tâches périodiques, tâches serveurs ou sporadiques qui sont reliées aux interruptions internes (horloge temps réel, chien de garde, ) ou aux interruptions externes provenant du procédé. - les tâches logicielles qui sont toujours activées par une autre tâche matérielle ou logicielle. Cette tâche appelée peut n avoir aucune relation temporelle particulière avec la tâche appelante ou, au contraire, avoir un délai maximum ou minimum d'activation à respecter correspondant respectivement à des tâches dites de réaction et des tâches dites de mesure de contrôle [PHLJ 93]. donnée discrète dmin donnée discrète à durée de validité finie dv dmin événement cyclique dmin événement sporadique à temps de réponse evt RE IT1 IT2 IT3 IT4 rs inconnu Figure 2. Modèles temporels des signaux.

10 10 Journal Européen des Systèmes Automatisées A chaque signal d'entrée/sortie, on fait correspondre l'ensemble des tâches dont l'activation est liée directement (tâche matérielle) ou indirectement (tâche logicielle) à ce signal. Chaque ensemble est alors regroupé dans un "groupe" de tâches. Cette notion de groupe est à rapprocher de la notion de groupe de tâches définie dans le langage SDL [NSR 95]. Les tâches d un même groupe sont liées par des relations de précédence. Cette contrainte impose, lors de la mise en place des algorithmes d ordonnancement, une même période d exécution pour les tâches d un même groupe. Quatre règles sont alors à vérifier lors de la conception préliminaire afin de pouvoir réaliser une analyse temporelle. Soient les règles suivantes : - chaque groupe contient une et une seule tâche matérielle ; - une tâche appartient à un groupe et un seul ; - deux tâches placées dans deux groupes distincts ne peuvent se synchroniser ; - si le signal est de type sporadique, le groupe ne contient qu'une tâche. Certains signaux peuvent être traités par des types de tâches différents. Par exemple un signal "événement cyclique + données" peut être traité soit par une tâche périodique qui va venir scruter la donnée liée au signal, soit par un serveur déclenché par l'occurrence de l'événement. Une fois le type de tâche choisi, l'analyse temporelle peut être réalisée pour définir les caractéristiques temporelles de chaque tâche en fonction des caractéristiques temporelles des signaux correspondants. Les principes d'analyse permettant d'évaluer leurs contraintes (ri,ri,ti) respectent les règles suivantes : - la période d'activation des tâches doit permettre la prise en compte de tous les changements en provenance du procédé (donnée ou événement) ; - lorsque la tâche s'exécute, la donnée traitée doit être égale à la donnée présente sur le procédé. Les principes à respecter sont donc le traitement de l'ensemble des signaux et leur validité lors du traitement. L'application de ces règles permet de définir des contraintes temporelles sur les tâches matérielles de l'application selon leur type : - tâche périodique : Ti < intervalle minimum entre deux changements ou Ti < période d'arrivée d'un événement périodique Ri < délai maximum - tâche serveur [Bab 96]: (Ti+Ri) < intervalle min. entre deux événements ou (Ti+Ri) < délai maximum - tâche sporadique : Ri < délai maximum Certaines méthodologies décrivent, dès cette étape, les relations de précédence unissant les tâches. Dans ce cas, une tâche ne possède pas de points de synchronisation autres qu en début ou fin d exécution. Le concepteur connaît et gère, dès la description des tâches, l ordre d exécution des tâches. Dans notre approche, les relations de précédence découlent des relations de synchronisations exprimées lors de la conception détaillée des tâches Nous avons fait ce choix afin de permettre une expression plus riche et plus réaliste des relations de synchronisation entre tâches. En particulier des tâches peuvent se synchroniser en cours d exécution. Les relations de précédence sont automatiquement évaluées et ne sont plus gérées par le concepteur.

11 Conception détaillée 7.1. Structures de conception La conception détaillée des tâches est réalisée à l'aide d'un langage algorithmique classique et d'un noyau temps réel générique basé sur les principes énoncés dans le projet SCEPTRE [SCE 92]. La tâche est vue comme une combinaison de blocs fonctionnels non bloquants, de structures algorithmiques et d'éléments de coopération. La composition des structures proposées par le langage de conception détaillée est liée aux possibilités d analyse du modèle temporel. L'analyse doit fournir les relations de précédence et les durées nécessaires à la validation. Le concepteur doit suivre l'ensemble des règles de conception s'il souhaite réaliser l'analyse temporelle de son application en vue d'une validation. On retrouve les structures séquentielles, alternatives et répétitives classiques permettant de coder tout algorithme. Le nombre de répétitions est obligatoirement borné. Cette limitation est à considérer comme une information sur le comportement de la structure et non comme une limitation de la structure répétitive. Les plus fortes restrictions sont en fait imposées sur la combinaison des structures algorithmiques et des primitives de coopération (synchronisation et partage de ressource). Dans le cas d'une répétition contenant des primitives de coopération, le nombre d itérations maximum est une valeur entière connue. De plus, on ne peut trouver, lors de l'appel d une ressource, des primitives de synchronisation. Les possibilités offertes au concepteur permettent toutefois de réaliser des opérations répétitives, alternatives et séquentielles de coopération (cf. figure 3). La synchronisation conditionnelle permet d exprimer, par exemple, des synchronisations du type «: A doit être exécuté deux fois plus souvent que B». Le schéma de programme à utiliser est alors le suivant : task A task B begin begin <liste_instructions> wait_event(s_b) ; if (start_b) then <liste_instructions> signal_event(s_b) ; end task B ; start_b = FALSE ; else start_b = TRUE ; end if <liste_instructions> end task A ;

12 12 Journal Européen des Systèmes Automatisées type de synchronisation envoi attente fixe précédence séquentielle conditionnelle variable paramétrique ou ou ou : tâche : liste d instructions : événement Figure 3. Structures de synchronisation autorisées lors de la phase de conception Modélisation Une application temps réel peut être vue selon les deux aspects fonctionnel et temporel [PHLJ 93]. Dans notre approche, le côté temporel est privilégié par rapport à l'autre étant donné que le but essentiel de l'étude est de fournir une validation temporelle de l'application. Ainsi l'étape de conception détaillée a permis d'obtenir une architecture générale du logiciel qui peut être utilisée d'une part pour une conception détaillée fonctionnelle et d'autre part pour une modélisation temporelle. Les différents modèles utilisés font un certain nombre d'hypothèses sur le logiciel et le matériel, mais restent suffisamment réalistes pour correspondre à des environnements de développement d'applications temps réel à contraintes strictes. La programmation doit permettre de garantir que toutes les parties du programme peuvent être bornées en temps d'exécution. La modélisation de l'application conduit alors à une représentation de l'application d'un point de vue strictement temporel et relationnel. Le but de la modélisation est d'arriver à une représentation sous forme d'un ensemble de tâches de durée fixe, se précédant, et faisant appel à des instants donnés à des ressources critiques, soit la forme normale nécessaire à une validation temporelle de l'application basée sur les algorithmes d'ordonnancement. Les éléments du langage algorithmique de conception des tâches sont modélisés par leur durée d'exécution. C'est en effet ce qui les caractérise d'un point de vue temporel. Le bloc ou à l appel de procédure ne contenant aucune instruction bloquante, est modélisé par une durée : D(i,j) : durée du bloc j de la tâche i. Une structure de contrôle (boucle ou structure alternative) est modélisée par une structure de durée nulle. La durée de la structure est alors incluse dans le programme. Soit pour une structure conditionnelle :

13 structure if (cond ) then action_1; else action_2; end if ; modèle de la structure IF COND(i,j) THEN D_ITE_T(i,j); D(action_1); ELSE D_ITE_F(i,j); D(action_2); ENDIF D_ITE_T est la durée du test à vrai, D_ITE_F la durée du test à faux. Ces durées correspondent au temps passé pour l'évaluation du test et aux divers branchements à réaliser. Les primitives de noyau temps réel générique non bloquantes sont simplement modélisées par leur durée. ( D_RTP(i) correspond à la durée de la i ème primitive du noyau). La modélisation des primitives de synchronisation ou de gestion de ressource se fait par la représentation de leur durée et par deux primitives de durée nulle modélisant l'effet opérationnel de la primitive. La modélisation de ces primitives doit faire apparaître l'ensemble des appels de ressources et l'ensemble des synchronisations. - appel de ressource (i numéro de la ressource r-port dans la liste de ressources de l'application) lock_resource(r-port); action_1; unlock_resource(r-port); - synchronisation signal_event(fin); wait_event(fin) D_RTP(30);LOCK(RES(i)); D(action_1); D_RTP(31);UNLOCK(RES(i)); SEND(evt(i)) ; WAIT(evt(i)) ; Selon le principe de représentation de toutes les relations de précédence, la modélisation d'une synchronisation paramétrique donne : - synchronisation paramétrique (i peut valoir 3, 4 ou 5) /* i < 3..5 */ signal_event(ok(i)); SEND(evt(j3)); SEND(evt(j4)); SEND(evt(j5)); Pour les communications entre tâches, on ajoute le temps de la communication soit une durée D_RTP avant le ou les SEND, après le ou les WAIT. De même les appels de primitive liés à une synchronisation variable ont une durée correspondant à la mise à jour ou à la consultation d'un booléen lié à l'envoi ou non de l'événement Analyse Le modèle temporel obtenu doit faire apparaître l'ensemble des durées, des appels de ressources et l'ensemble des relations de synchronisation. Afin de faire apparaître des durées fixes et des relations de précédence à partir des relations de

14 14 Journal Européen des Systèmes Automatisées synchronisation, il est nécessaire d'utiliser les deux règles d'analyse du modèle (R1) et (R2). - Le pire des cas d'exécution (R1) A une durée d'exécution variable, on fait correspondre le maximum des durées. Dans l étude présentée, on ne traite pas le cas de fautes temporelles pouvant entraîner une dérive temporelle. Nous supposons qu il est toujours possible de borner en temps les opérations. La règle R1 est celle utilisée par [PaS 91] et [PuS 93] pour l'évaluation de la pire durée d'exécution d'une tâche. On peut la résumer par les quatre règles suivantes : - cas d'une instruction : durée d'une instruction durée(a) = maximum des durées possibles de A - cas d'une séquence : durée(a suivi de B) = durée(a) + durée(b) - cas d'une alternative : durée(a ou B) = Maximum(durée(A),durée(B)) - cas d'une répétition : durée(maximum N fois A) = N * durée(a) - Le découpage de tâche (R2) Une tâche composée de la séquence d'actions (A1;A2) est remplacée par deux tâches possédant les mêmes caractéristiques temporelles (date de départ, échéance, période) se précédant et correspondant aux actions A1 et A2. L'application de (R2) implique que le modèle de la tâche A soit remplacé par un nouveau modèle composé de deux sous-tâches A1 et A2 (cf. figure 4). Elle impose donc lors de la phase de conception détaillée, l ajout d une primitive temps réel pour signaler le changement d'état de la tâche au point de découpage. Ce changement d état est en fait un changement de priorité dans le cadre des algorithmes à priorité fixe ou un changement de d échéance dans le cas d Earliest Deadline. En effet la modélisation traitée qui est à l origine de la validation doit représenter de manière correcte l'application étudiée. La validation se fait sur la tâche découpée et l exécution se fait avec la tâche non découpée. Les deux modèles (une tâche A composée de deux modules A1 et A2 séparés par une primitive de changement de priorité et deux tâches A1 et A2 de priorités différentes ) sont équivalents du point de vue de l'analyse d'ordonnançabilité [Bab 96]. Il n'existe pas de difficulté particulière pour l'analyse des répétitions complexes. En effet le nombre de répétitions maximum est borné et est de plus connu. Il suffit alors de dérouler la structure répétitive. On se retrouve alors dans le cas précédent des structures simples. Comme lors d une synchronisation dans une structure séquentielle, les structures variables présentées à la figure 3 peuvent se décomposer en deux modules d exécution : les instructions situées avant le point de découpage et celles situées après (cf. figure 5). Il est à noter que dans le cas d'une structure conditionnelle, le point de découpage se trouve alors dans les deux branches de l'alternative [Bab 96]. tâche A1-A2 tâche A1 a&6aé tâche A2

15 partie A1 change_status() partie A2 <=> partie A1 partie A2 Figure 4. Représentation des deux modèles opérationnels équivalents. tâche C => C1 C2 C1 C2 ou ou tâche D => D1 D2 D1 D2 : point de découpage : relation de précédence variable Figure 5. Découpage des tâches pour des synchronisations variables. Suite à l'analyse temporelle associée à l'étape de conception détaillée, on obtient un graphe de précédence reliant les tâches et les sous-tâches de l'application. Chaque sous-tâche possède un modèle paramétré de durée (Ci fonction des Dij : durées des blocs fonctionnels composant la tâche). Les relations de précédence sont ici fixes ou variables. Dans ce dernier cas, si la tâche A précède la tâche B, la contrainte de précédence est à respecter mais la tâche B n est pas toujours à exécuter. Son activation dépend de l envoi d un signal par la tâche A. Si par exemple, l envoi du signal est dans un structure conditionnelle, l envoi dépend de la valeur de la condition évaluée en-ligne. 8. Codage Le logiciel est codé à partir d un langage algorithmique (langage C) dit langage applicatif et des primitives temps réel disponibles dans l environnement d un exécutif temps réel implanté sur le processeur cible ("exécutif temps réel"). D'un point de vue fonctionnel le rôle de l'étape de codage est de fournir, pour chaque

16 16 Journal Européen des Systèmes Automatisées bloc, un algorithme, et de le coder dans le langage cible. D'un point de vue temporel, on souhaite obtenir les valeurs de l'ensemble des durées des divers blocs fonctionnels. Les durées considérées ici sont des pires durées d'exécution. Des méthodes analytiques permettent de prédire cette durée d'exécution des tâches dans le respect d'hypothèses fortes sur le comportement du logiciel (récursivité, déclarations dynamiques, points de blocage, types flottant ou entiers longs, appels implicites de procédures et boucles illimitées interdits) et du matériel (mémoire cache, pagination, DMA, parallélisation des micro-codes interdits) [Sha 89] [PaS 91] [PK 89]. Afin d'éviter le développement d'outils spécifiques, il est intéressant de développer un outil de mesure basé sur la simulation. L hypothèse sur le matériel est de considérer son comportement comme déterministe du point de vue temporel : deux simulations logicielles du même code ne peuvent avoir deux durées d exécution différentes. La simulation permet de prédire la durée d exécution sans utiliser des algorithmes analytiques de prédiction, complexes et contextuels à l architecture, qui simulent le comportement exact du matériel (effet du cache, du pipe-line, du DMA, etc.) [AMW 94][MR 95]. Pour que la simulation soit correcte, le bloc simulé et le bloc exécuté sur le processeur cible doivent posséder la même durée d'exécution. Il est donc nécessaire d'obtenir l'égalité des codes compilés pour le bloc simulé et le bloc exécuté. Le comportement temporel d'une tâche dépend de sa conception (code), du matériel cible choisi et du comportement du procédé à contrôler [Par 93]. Le matériel est pris en compte lors de la phase de simulation. Les autres aspects sont pris en compte lors de la définition des jeux d'essai couvrant l'ensemble des modes temporels du bloc étudié. Un jeu d'essai caractérise un chemin d'exécution car, dans le respect des hypothèses matérielles, chaque parcours d'un chemin possède une durée fixe. Un bloc est alors vu comme un ensemble de chemins d'exécution. Les jeux d'essai obtenus sont issus d'une analyse structurelle du bloc à mesurer. Cette analyse intègre les effets de compilation et permet de dégager l'ensemble des comportements réalistes du bloc en détectant les chemins d'exécution non faisables (code mort) [BGC 96]. En particulier, l'influence du procédé externe sur la faisabilité des chemins d'exécution est intégrée lors de l'analyse par ajout d'assertions de réalisme sur les variables du bloc (cf. tableau 1). L'analyse est une analyse descendante par assertion de type pré et post condition [Hoa 69]. L'analyse fournit pour chaque chemin un ensemble de conditions portant sur les variables du bloc. Trois situations sont alors envisageables. Dans la première, on arrive à résoudre le système d'équations déterminé pour le mode de fonctionnement et on obtient alors un jeu d'essai. Dans la deuxième, le système n'est pas résolvable mais on a une solution particulière qui vérifie le système. On obtient alors un jeu d'essai. Enfin si on n'arrive ni à résoudre le système, ni à trouver des jeux d'essai qui vérifient le système, il faut revenir aux méthodes analytiques donnant un majorant de la durée d'exécution recherchée pour le domaine considéré. Ce cas est peu présent dans le cadre d'algorithmes simples et linéaires [Sha 89]. Tableau 1. Assertions de réalisme sur les variables d'un bloc.

17 condition sur le contenu des variables a est strictement inférieur à 3 : /* a < 3 */ a est non nul : /* a <> 0*/ a appartient à l'ensemble {1,5,8,9} : /* a << {1,5,8,9} */ - condition sur la dimension des ensembles la file contient de 2 à 5 éléments : /* 2 <= length(file) <= 5 */ - limitation de boucles : la répétition boucle1 ne peut être réalisée au maximum que 100 fois : /* maxi 100 boucle1*/ /* boucle1 */ while (b) {... } /* end boucle1 */ - limitation de structure au sein d'une boucle la structure struct1 inclus dans la répétition boucle1 ne peut être réalisée que 50 fois : /* maxi 100 boucle1 */ /* boucle1 */ while (b) {... /* maxi 50 struct1 in boucle1 */ /* struct1 */ {... } /* end struct1 */... } /* end boucle1 */ - relation entre deux conditions : if (a) {...} else { } le chemin passant par a implique que la condition b est vraie /* a => b */ si c est vrai alors on passe par le chemin a faux : /* not(a) <= c */ a est toujours le contraire de b : /* a <=> not(b) */ a équivaut à b : /* a<=> b */ Le nombre de jeux d'essais à réaliser peut limiter l'approche. Dans le cas où le nombre de tests est trop important, il est nécessaire de réaliser une réduction des mesures en mixant approche analytique (règle du pire cas) et simulation [BGC 96]. Cette approche s'est avérée efficace et simple à mettre en oeuvre dans le cadre des applications temps réel où l'analyse des chemins d'exécution est simple (algorithmes peu complexes) et où un jeu de test est facile à déterminer pour chaque chemin (systèmes linéaires à résoudre), cette méthode apparaît comme une solution convenable au problème d'évaluation des durées d'exécution. 9. Validation 9.1. Affectation de priorité L'ensemble des contraintes de précédence, variables ou fixes, doivent être considérées pour l'affectation des priorités des tâches ou des sous-tâches. De plus, on considère la pire durée d'exécution pour chaque sous-tâche. Cette vue temporelle de l'application est nécessaire à la mise en place des algorithmes d'ordonnancement (cohérence de l'affectation des priorités selon la précédence, évaluation du retard sur

18 18 Journal Européen des Systèmes Automatisées l'appel de ressources). Il est alors possible de réaliser une affectation de priorité selon RM et DM, les priorités sont indépendantes des durées. Pour ED, l'algorithme de prise en compte des relations de précédence dépend des valeurs des pires durées d'exécution des blocs Modes réalistes Afin de réaliser une analyse temporelle réaliste de l'application, un ensemble de modes temporels est extrait, correspondant aux divers comportements de l'application. Ils correspondent à l'ensemble des parcours possibles du graphe de précédence de l'application. On sait, a priori, que certains chemins dans le parcours du graphe de précédence sont impossibles. Un événement n est pas toujours envoyé par une tâche (synchronisations conditionnelles ou paramétriques). L'ensemble des sous-tâches n'est donc pas toujours à effectuer. De plus selon le mode d'exécution considéré les tâches possèdent un ensemble de comportements possibles en durée (ceux-ci sont liés aux conditionnelles rencontrées lors du parcours du graphe de précédence). Pour chaque comportement possible, l'ensemble des informations nécessaires à la validation sont connues (ri, Ci, Ciα, Ciβ, Ciγ, Ri, Ti, Pi). Une tâche possède sa forme dite normale et l'application peut donc être validée pour chaque mode. Pour illustrer cet aspect, nous considérons l exemple présenté à la figure 6. Un premier groupe G1 de tâches de période égale à 10 unité de temps (ut) est composé des tâches A, B et C. La tâche A (découpée en trois sous-tâches A1, A2 et A3) envoie un événement dans une structure conditionnelle à la tâche B (B1), puis envoie toujours un événement à la tâche C (C1). Le deuxième groupe G2 de tâches de période égale à 20 ut, est composé des tâches D, E, F et G. La tâche D (découpée en deux sous-tâches D1 et D2) envoie un événement soit à la tâche E (E1), soit à F (F1), soit à G (G1). Dans le premier groupe, selon la condition, deux comportements sont possibles : dans le premier (mode 1 pour la tâche A), B n est pas activé ; dans le deuxième (mode 2 pour la tâche A), B est à exécuter. Pour chaque mode, les pires durées des sous-tâches A1 et A2 ne sont pas identiques. Dans le deuxième groupe, trois comportements sont possibles : soit la tâche E1 est à exécuter et pas les tâches F1 et G1 ; soit F1 seule ; soit G1 seule. Pour la détermination de l'ensemble des comportements de l'application, nous définissons dans un premier temps un ensemble de modes par groupe de tâches (un groupe de tâche est un ensemble de tâches logicielles liées à une même tâche matérielle). Il suffit alors de parcourir le graphe de précédence pour définir les modes possibles de chaque groupe. Chaque structure conditionnelle d envoi définit deux modes, chaque structure paramétrique entraîne autant de modes que d événement possible. Sur une séquence de validation, le groupe est activé plusieurs fois. A chaque activation, le groupe possède l'un ou l'autre de ses modes d'exécution.

19 Graphe de précédence groupe G1 (T = 10) groupe G2 (T = 20) A1 D1 A2 B1 D2 E1 F1 G1 A3 C1 : condition : mode 1 pour la tâche A : mode 2 pour la tâche A contrainte de précédence fixe contrainte de précedence variable Figure 6. Exemple d application composée de 2 groupes de tâches : G1(3 tâches A, B et C) et G2(4 tâches D, E, F et G). Soit N M le nombre de modes possibles pour un groupe, soit N A le nombre d'activations du groupe sur une séquence de validation de l application. Le calcul combinatoire donne : - N N N G = ( M) A Lorsqu il n existe qu un mode, on retrouve que le nombre de comportement est égal à un (N G =1). De même, s'il n'existe qu'une activation du groupe, le nombre de modes est égal à N M (N G = N M ). Dans le cas, par exemple de trois modes (N M =3) pour deux activations (N A = 2), on obtient : 2 - N G = 3 = 9 On obtient le nombre de mode pour l application par combinaisons des divers modes lors des diverses activations N G de chaque groupe de tâches : - N = ( N ) E! pour t ous l es gr oupes G A partir de cet ensemble de modes d'exécution d'un groupe de tâche sur une séquence d'exécution, il suffit alors de réaliser le produit cartésien de l'ensemble des comportements pour chaque groupe de l application. Dans l exemple donné, sur une durée de validation de 20 ut, le groupe G2 est activé une fois et possède donc 3 comportements (3 modes d exécution). Le groupe G1 est activé deux fois et possède donc 4 comportements (2 modes d exécutions). On obtient un total de douze comportements temporels pour l application à valider. L'ensemble des comportements possibles de l'application est alors à valider. Cet ensemble de

20 20 Journal Européen des Systèmes Automatisées validation peut être utilisé pour calculer des valeurs moyennes de temps de réponse par exemple. Le résultat fournit l'ensemble des validations à réaliser. Ce nombre peut être élevé. On peut alors se baser sur une «pire» vue de l application. Cette vue est celle où toutes les sous-tâches sont à exécuter (on considère que tous les événements sont envoyés) avec leur pire durée d exécution. C est la vue qui est utilisée pour l affectation de priorité mais qui n est pas réaliste. Pour une analyse plus complète (performances temporelles moyennes), l'ensemble des comportements est à considérer. 10. Mise en oeuvre des outils d'analyse Analyse linéaire La mise en oeuvre des outils d'analyse implique la connaissance des choix matériels. En effet l'analyse temporelle permet de déterminer les caractéristiques temporelles de l'application lors de son exécution dans l'environnement cible, dépendant des choix matériels. Ces derniers influencent donc l'ensemble des diverses analyses. Les types de capteurs/actionneurs et leur interface associée permettent de définir les contraintes temporelles associées aux signaux. Le type d'exécutif utilisé (exécutif cyclique ou préemptif à priorité) permet de déterminer les types de tâches utilisés lors de la conception préliminaire. Enfin, lors du codage, les choix matériels (langages, processeurs) sont nécessaires à l'évaluation des durées d'exécution. Les choix matériels peuvent être imposés lors de la définition des besoins (matériel peu coûteux, matériel certifié,...). La mise en place de la méthodologie impose alors un cycle de développement linéaire de type cycle en V. En effet, le résultat de l'analyse de chaque étape influence l'étape de conception suivante. Il est nécessaire de connaître les types de signaux pour réaliser la conception préliminaire dans le respect des règles imposées. Une fois cette étape réalisée, chaque tâche définie, il est possible de réaliser la conception détaillée de ces dernières et enfin de passer à l'étape de codage. Les outils d'analyse temporelle peuvent être alors utilisés à chaque étape du cycle de développement Mise au point des choix matériels Certains choix matériels sont réalisés au cours, ou en fin, de conception. L'avantage de réaliser les choix matériels en fin de conception est de pouvoir les ajuster en fonction de critères temporels. Le modèle temporel (durées des blocs, périodes de scrutation,...) obtenu au cours du développement, n est instancié qu en fin de conception en fonction des choix matériels (processeur, convertisseur analogique-numérique,...). La méthodologie permet d aider à la définition du

21 matériel afin d'obtenir la validation temporelle souhaitée. Les outils servent à la spécification du matériel en terme de performance temporelle. La modélisation temporelle intègre les effets du matériels (par exemple la prédictibilité temporelle du processeur). Le matériel doit respecter les contraintes imposées par la modélisation. Par exemple, lors de la conception, un signal "état_du_procédé" est spécifié comme étant périodique et donc traité par un groupe de tâches périodiques de même période. Lors des choix matériels, des capteurs différents entraînent un découpage du signal "état_du_procédé" en deux signaux physiques "température" et "pression". Les deux signaux doivent être alors synchronisés afin de respecter le modèle temporel. Les tâches de traitement appartiennent, d'un point de vue de la conception, au même groupe de tâche et possèdent la même période. Si la synchronisation des deux signaux n est pas possible, il est nécessaire de revenir sur la conception de l'application afin de séparer les traitements liés au signal "pression" de ceux liés au signal "température" afin de faire apparaître deux groupes de tâches, l un lié au signal "température" et l autre au signal "pression" Validation anticipée Il peut être souhaitable de connaître les caractéristiques temporelles d'une application relativement tôt dans le cycle de développement. La validation anticipée permet alors de réaliser très tôt dans le cycle de développement une meilleure adéquation entre les contraintes temporelles et l'architecture de l'application. Comme il a été dit, les caractéristiques temporelles complètes ne peuvent être connues que si les choix matériels ont été réalisés. Si on souhaite, donc, avoir l'ensemble des caractéristiques temporelles à une étape du développement, il faut fixer les caractéristiques inconnues (choix matériels et caractéristiques temporelles non évaluées). Il faut ensuite vérifier que la conception aux étapes suivantes reste dans les contraintes imposées. Les outils d'analyse décrits sont donc toujours nécessaires pour obtenir les caractéristiques finales. La validation finale, réalisée en fin de conception correspond à une validation des contraintes imposées. Les durées d'exécution peuvent être anticipées dès la conception détaillée. Il est ensuite nécessaire de vérifier que les durées réelles sont inférieures ou égales aux durées estimées lors de cette validation. Une bibliothèque complète d'éléments déjà caractérisés du point de vue temporel peut être aussi utilisée. Cette approche permet d'éviter la phase d'analyse et de valider l'application à toutes les étapes de conception. Les éléments issus de la bibliothèque doivent être pires ou équivalents d'un point de vue temporel à ceux issus de la conception. Le comportement temporel d'un élément dépendant de sa conception mais aussi des autres éléments de l'application, de l'environnement d'exécution choisi et enfin du comportement du procédé, pour fonctionner. Cette approche est régulièrement utilisée lors de l'évaluation des durées d'exécution à partir de tables de durées d'instructions du langage, préalablement définies dans un pire cas d'exécution.