N d ordre 04ISAL0052.. Année 2004 Thèse Développement formel de systèmes temps réel à l'aide de SDL et IF (Compilation pour système temps réel) présentée devant L Institut National des Sciences Appliquées de Lyon pour obtenir le grade de docteur Ecole doctorale :EDIIS (Informatique et Information pour la Société) Spécialité : ISCE (Informatique et Systèmes Coopératifs pour l Entreprise) par Ahmad Badreddin ALKHODRE Soutenue le 20 septembre 2004 Jury MM. M.SIFAKIS Joseph, Professeur CNRS-Verimag Grenoble (Président). M.MAMMERI Zoubir, Professeur IRIT-Toulouse (Rapporteur). M.TERRIER François Professeur CEA Paris (Rapporteur). M.BONIOL Frédéric Maître de conférence à l'onera-cert-toulouse (Examinateur). M.SCHWARZ Jean-Jacques, Professuer UCBL (Directeur de thèse). M.BABAU Jean-Philippe, Maître de conférence à l'insa de Lyon (co-encadrant). Cette thèse a été préparée au Laboratoire de CITI Centre d Innovations en Télécommunications et Intégration de Services de L INSA de Lyon.
ii
Introduction générale... 1 Objectif de la thèse... 3 Structure du mémoire... 4 Partie I... 5 Contexte de travail... 5 1 Notions de système réactif et de contraintes temps réel... 6 1.1 Les systèmes réactifs... 6 1.2 Les systèmes temps réel... 6 1.3 Les contraintes temps réel... 6 1.4 Conclusion... 8 2 Méthodologies... 10 2.1 Principes généraux des méthodologies... 10 2.1.1 Le modèle en cascade... 10 2.1.2 Le modèle "cycle de vie en V"... 11 2.1.3 Discussion...12 2.2 Les techniques formelles... 12 2.3 Développement de systèmes temps réel... 13 2.4 Conclusion... 15 3 Langages de développement des systèmes temps réel... 16 3.1 Langage de spécification... 16 3.1.1 SA-RT... 16 3.1.1.1 Introduction... 16 3.1.1.2 Caractéristiques du langage... 16 3.1.1.3 Conclusion... 17 3.1.2 UML... 17 3.1.2.1 Introduction... 17 3.1.2.2 Principes d'uml... 18 3.1.2.3 Caractéristiques du langage... 18 3.1.2.4 Conclusion... 20 3.1.3 SDL... 21 3.1.3.1 Introduction à SDL... 21 3.1.3.2 Principes de SDL... 21 3.1.3.3 Caractéristiques du langage.... 24 3.1.3.4 Discussion... 31 3.2 Langage de conception... 32 3.2.1 LACATRE...32 3.2.2 SDL-RT... 33 3.2.3 Autre langage de conception... 34 3.2.4 Discussion...34 3.3 Conclusion générale de la partie langages... 35 4 Validation et vérification... 36 4.1 Vérification comportementale... 36 4.1.1 Relation d'équivalence... 36 4.1.1.1 Système de transitions étiquetées (LTS) :... 36 4.1.1.2 Bisimulation forte... 37 4.1.1.3 Bisimulation faible... 37 4.1.1.4 F-simulation... 38 4.1.2 Model-checking... 39 4.1.2.1 Le principe du Model-checking... 39 4.2 Vérification temps réel... 40 4.2.1 Les automates temporisés... 40 4.2.2 La logique temps réel... 40 4.2.3 Techniques dédiées à la validation des système temps réel... 42 i
4.2.3.1 Principes... 42 4.2.3.2 Vérification des implémentations multitâches... 44 4.2.4 Discussion...45 4.3 Conclusion... 46 Partie II... 48 5 Description de la méthodologie... 49 5.1 Les étapes de la méthodologie... 49 5.1.1 Modèle de contraintes... 50 5.1.2 Modèle d exécution... 50 5.1.3 Implémentation... 50 5.1.4 Choix des langages... 50 5.2 Validation... 51 6 Le modèle de contraintes... 52 6.1 Modèle d'interaction... 52 6.2 Modèle temporel de l environnement... 54 6.2.1 Introduction... 54 6.2.2 Activation périodique... 54 6.2.2.1 Introduction... 54 6.2.2.2 Spécification en SDL... 55 6.2.2.3 La sémantique en IF :... 56 6.2.3 Activation sur interruption... 57 6.2.3.1 Source d interruption régulière... 57 6.2.3.2 Source d'interruption en rafale... 58 6.2.4 Le modèle temporel des données... 61 6.2.4.1 Spécification en SDL... 61 6.2.4.2 La sémantique en IF... 62 6.2.5 Activation par message... 63 6.2.5.1 La spécification en SDL... 63 6.2.5.2 La sémantique en IF... 64 6.3 Le modèle temporel des actions... 65 6.3.1 Spécification SDL du modèle temporel d'action.... 65 6.3.2 La sémantique du modèle temporel d'action.... 68 6.4 L'échéance et l'âge de donnée... 69 6.4.1 Introduction... 69 6.4.2 L'âge d une donnée... 70 6.4.3 Echéance... 70 6.4.4 Politique temps réel :... 71 6.4.4.1 Filtrage : Vérification de durée de séparation... 71 6.4.4.2 Vérification d échéance... 73 6.4.4.3 Vérification de l âge de données... 74 6.5 Utilisation des modèles... 74 6.6 Conclusion... 75 7 Le modèle d exécution... 76 7.1 Introduction... 76 7.2 Eléments applicatifs... 78 7.2.1 Les routines... 78 7.2.1.1 La routine d interruption... 78 7.2.1.2 La routine d alarme... 80 7.2.2 Les tâches... 81 7.2.2.1 Les tâches périodiques... 82 7.2.2.2 Les tâches sporadiques... 83 7.2.2.3 Les serveurs à scrutation... 84 7.2.2.4 Les tâches logicielles... 86 7.2.3 Les données... 90 7.3 Modèle d'exécution pour l'environnement... 90 7.3.1 Source d'interruption et alarme périodique... 90 7.4 Contrôleur programmable des interruptions... 91 ii
7.4.1 La modélisation du PIC en SDL... 91 7.4.2 La sémantique du PIC en IF... 92 7.5 Politique temps réel... 92 7.5.1 Utilisation du chien de garde... 93 7.5.1.1 La modélisation en SDL... 93 7.5.1.2 La sémantique en IF 2.0... 94 7.5.2 Utilisation de la fonction check... 95 7.5.2.1 La modélisation en SDL... 95 7.5.2.2 La sémantique en IF 2.0... 96 7.6 Politique d ordonnancement... 97 7.7 Eléments sépcificques... 98 7.7.1 La base de temps... 99 7.8 Mode d'utilisation... 99 7.9 Conclusion... 100 8 Génération de code... 101 8.1 Introduction... 101 8.2 Principe... 102 8.3 La communication entre objets... 103 8.4 Les annotations formelles : La politique d ordonnancement et la priorité... 104 8.5 Code pour des OS classiques embarqués (Windows)... 105 8.5.1 Windows et temps réel... 105 8.5.2 Du modèle d exécution à Win32... 105 8.5.2.1 La communication entre les objets... 105 8.5.2.2 La routine d interruption... 106 8.5.2.3 Alarme... 106 8.5.2.4 La routine d alarme... 106 8.5.2.5 La tâche périodique... 107 8.5.2.6 Le serveur à scrutation... 107 8.5.2.7 La tâche logicielle... 108 8.5.2.8 Le «main»... 108 8.5.2.9 La gestion de priorités... 108 8.6 Code pour des exécutif temps réel... 109 8.6.1 VxWorks et le temps réel... 109 8.6.2 Du modèle d exécution vers VxWorks... 110 8.6.2.1 La communication entre les objets... 110 8.6.2.2 La routine d'interruption... 110 8.6.2.3 L alarme... 110 8.6.2.4 La routine d alarme... 111 8.6.2.5 La tâche périodique... 111 8.6.2.6 Le serveur à scrutation... 111 8.6.2.7 La tâche logicielle... 112 8.6.2.8 Le «main»... 112 8.6.2.9 La gestion de priorités... 113 8.6.3 Restrictions sur l'action Afaire... 113 8.6.4 Contrôle temps réel... 113 8.7 La compilation du modèle d exécution vers Win32 ou VxWorks... 116 8.7.1 L analyseur lexical et l analyseur syntaxique... 116 8.7.2 L analyse sémantique... 118 8.7.3 La génération du code C/ Win32 ou C / VxWorks... 119 8.8 Conclusion... 120 9 Validation... 122 9.1 Introduction... 122 9.2 Validation formelle... 123 9.2.1 Technique de validation... 123 9.2.2 Définition de problème... 124 9.2.3 Formalisation du problème de compatibilité... 125 9.2.3.1 Modèle de contraintes... 125 9.2.3.2 Modèle d'exécution... 126 9.2.3.3 Algorithme... 128 iii
9.3 Méthodologie de la validation formelle... 129 9.3.1.1 Redéfinir une base de temps unitaire... 129 9.3.1.2 La deuxième étape : le renommage... 130 9.3.1.3 La troisième étape : abstraction et réduction des modèles :... 130 9.3.1.4 La quatrième étape : comparaison... 131 9.3.2 Exemple d'application... 131 9.3.2.1 Exemple d'activations sporadiques... 131 9.3.2.2 Exemple d'activations périodiques... 135 9.3.2.3 Observation d'échéance... 138 9.3.3 Conclusion... 140 9.4 Vérification des propriétés temps réel... 142 9.4.1 Modèle RMA... 142 9.4.2 Extraction des paramètres temporels pour RMA... 142 9.4.3 Les propriétés à vérifier... 143 9.4.3.1 Vérification d'une échéance simple... 143 9.4.3.2 Vérification d'une échéance de bout en bout... 145 9.4.3.3 Vérification la validité d'une donnée... 146 9.5 Conclusion... 147 Conclusion générale.... 149 Perspectives... 151 Références... 152 Bibliographie liée à l'étude... 168 Annexes... 169 Annexe 1... 170 iv
Introduction générale 1
Un système temps réel est un système qui interagit avec un environnement physique en remplissant souvent des missions critiques pour lesquelles une faute du système peut avoir des conséquences graves. Il sera dit correct s'il possède les bonnes fonctionnalités et si cellesci sont réalisées à temps, c'est-à-dire avec le respect des contraintes temporelles imposées par l environnement ou par une certaine qualité de service offerte à un utilisateur. La validation fonctionnelle et temporelle des systèmes temps réel est ainsi une nécessité forte. Toutes les situations, tous les comportements du système doivent être envisagés pour que la validation fournisse des résultats fiables. Si l'on sait maintenant comment faire pour développer des systèmes temps réel (aller de la spécification vers la réalisation) il est indispensable, vu les conséquences possibles d'une faute temporelle, de porter un intérêt particulier à la sûreté de fonctionnement, aux méthodes permettant de valider le développement avec pour objectif de garantir à l'avance le bon fonctionnement du point de vue temporel. Afin de garantir le bon fonctionnement du système, il faut utiliser lors du développement de ce système, des techniques de modélisation et outils formels (possédant des représentations mathématiques que l'on peut associer à un programme) qui permettent d'effectuer des preuves de modèles. Le développement d'un système temps réel passe par l'utilisation de langages et d'outils adaptés aux besoins des différentes étapes de développement (la spécification, la conception, l'implémentation et la vérification) et les contraintes temps réel se doivent d'être exprimées et prise en compte à chacune de ces étapes. Le modèle associé à l'étape de spécification est le modèle de contraintes. On y décrit le comportement du système et les contraintes temporelles du système (ce que le système doit faire). Le modèle associé à la conception est appelé le modèle d'exécution : on y décrit l'architecture d'exécution de l'application (comment le système doit s'exécuter). Ce modèle est une abstraction de l'implémentation, qui cache tous les détails de l'implémentation, comme par exemple les moyens de communication. Différentes solutions dépendantes des technologies d'implémentation sont, bien sûr, possibles et chacune d entre elles aura recours à un outillage approprié. Dans le cadre de ce travail nous n'étudions que l'implémentation basée sur l utilisation d un système multitâches monoprocesseur. Ce type d implémentation qui s'appuie donc sur les services d'un exécutif temps réel est largement utilisé par les industriels à cause de la relative facilité d utilisation, mais n a pas bénéficier de beaucoup de développement d outils pour la valididation. Les travaux de recherches liés au développement de système temps réel se divisent en plusieurs axes. Dans un premier axe, les travaux menés se concentrent sur une étape particulière du développement telle que la spécification, la conception ou l'implémentation. En ce que concerne la spécification, les travaux menés s'appuient en général sur l'utilisation d un langage de haut niveau. Ainsi, à titre d exemple, vu la facilité de son utilisation, SA-RT (Structure Analysis - Real Time) [79] a été utilisé pour la spécification de systèmes temps réel, même s il n est qu un langage informel. D'autres approches adoptent des langages de modélisations orientés objet comme UML (Unified Modelling Language) [136]. Ce dernier est un langage semi-formel qui ne possède pas une sémantique précise. Enfin, des approches utilisent des langages formels comme SDL (Specification and Description Language) [85] 2
[125]. Il reste toutefois que SDL ne possède pas de mécanismes lui permettant d'exprimer précisément les contraintes temps réel. Afin de pallier cette lacune, plusieurs travaux ont été développés pour enrichir SDL sur ce point, soit par l'adjonction à une autre langage temps réel [30], soit par l'ajout de nouvelles syntaxes [7] [145].Lors de la conception, toutes les approches telles que LACATRE [160], UML-RT [124] ou SDL-RT [175] proposent des boîtes à outils qui s'appuient sur des boîtes grises à instancier lors de la conception. Les langages UML-RT et SDL-RT permettent d'intégrer les aspects temps réel mais ils ne proposent pas un cadre formel de conception. L'approche de LACATRE [160] [158] propose un cadre formel pour le développement, mais pas pour la prise en compte des contraintes temps réel. Finalement, peu de travaux sont développés autour de la problématique concernant la transformation entre le modèle associé à la spécification et le modèle associé à la conception tels que proposés dans [72] [106]. En ce qui concerne la correction de cette transformation, elle peut être garantie en utilisant les techniques d'abstraction et de vérification. Les approches développées dans [60] [61] [121] [150] ne s'appliquent que dans le cas où le modèle d'exécution est une adaptation du modèle de contraintes. Dans le deuxième axe, les travaux se concentrent sur la mise en place d'une architecture d'exécution. On essaie alors d'optimiser le déplacement des actions dans les tâches [72] [106]. A titre d'exemple l'approche CODARTS propose des règles et des principes aidant à mapper une spécification d un système temps réel sur une conception basée sur le langage Ada [72]. Les travaux dans du troisième axe se focalisent sur le développement de techniques de validation du système temps réel telles que proposées par [91] [75] [37][185]. Ces techniques permettent de valider des propriétés par rapport à un modèle donné, par exemple l'approche de model-checking [104] [119], soit de valider la conformité de modèles en s appuyant sur la notion d'équivalence [60] [121]. Toutes ces études apportent des principes, des solutions ou des modèles intéressants pour le développement de systèmes temps réel. Cependant ces approches se concentrent spécifiquement sur une étape particulière du développement indépendamment des autres. Donc, aujourd'hui, il existe peu d'approches complètes et formelles qui regroupent tous les aspects nécessaires pour le développement d'un système temps réel en passant de la spécification à la réalisation (implémentation). Objectif de la thèse Dans le cadre des implémentations à base d exécutifs multitâche temps réel, le travail présenté dans cette thèse tente d apporter une approche complète formelle de la suite spécification, conception et implémentation. Dans ce cadre, il porte aussi un intérêt particulier à une méthode de validation de la transformation entre le modèle de contraintes et le modèle d'exécution Dans un premier temps, nous décrivons plus particulièrement la formalisation des phases aboutissant à la définition du modèle de contraintes et du modèle d exécution de l application. Dans ce but, nous utilisons le langage SDL [67] [85] [122] présentant suffisamment de caractéristiques formelles. SDL, langage normalisé par l ITU-T, est très utilisé dans la communauté des télécommunications, mais son cadre d application actuel dépasse largement ce domaine : il est employé avec succès dans des domaines comme les systèmes embarqués 3
ou le multimédia [64]. Le monde industriel l apprécie car il est soutenu par un environnement de développement intégré (objectgeode [135], Tau [200]). Par contre, SDL ne possède pas d éléments de spécification clairs et précis de l écoulement du temps et il ne fournit pas une description complète de la façon dont le modèle doit s exécuter dans le temps [29]. Ensuite, le but de cette étude est de prendre en considération la dimension temporelle dans nos modèles SDL. C est le langage IF [28] qui sera exploité pour fixer une sémantique temporelle utile à la validation. Afin de prouver la correction de la transformation entre le modèle de contraintes et le modèle d'exécution, nous proposons une relation de compatibilité comportementale entre ces deux modèles. Cette relation de compatibilité sera exploitée par une méthodologie en quatre étapes pour vérifier la correction de la transformation entre le modèle de contraintes et le modèle d'exécution. Finalement, afin de valider l'implémentation multitâche proposée, nous présentons une approche de validation qui s'appuie sur l'analyse d'ordonnançabilité RMA [98]. Cette approche permet de vérifier, d'une part, la cohérence temporelle de modèle d'exécution et d'autre part les propriétés temps réel exprimées dans les modèles (de contraintes et d'exécution) telles que l'échéance et la durée de la validité d'une donnée. Structure du mémoire Dans cette optique, ce document est constitué de deux parties. La première partie présente le contexte de notre travail : les systèmes temps réel et leur contraintes en faisant état de leurs spécificités et exigences. Nous décrivons divers éléments pris en compte lors de leur développement (chapitre 1), en particulier les méthodologies de développement (chapitre 2), les langages utilisés (chapitre 3) et les techniques de validation (chapitre 4). Dans la deuxième partie nous présentons la structuration de notre contribution, puis chaque étape (spécification, conception et implémentation) sera détaillée. Nous présentons la description de la méthodologie à suivre dans le chapitre 5. Les modèles de contraintes et d'exécution exprimés en SDL avec la sémantique en IF font l objet des chapitres 5 et 6. Le chapitre 8 est consacré aux principes de génération de code et, au final, le chapitre 9 traite le problème de la validation et de la vérification. Nous y abordons le problème de la conformité du modèle d'exécution par rapport au modèle de contraintes et nous montrons comment il est possible de vérifier les contraintes temps réel par une analyse de type RMA à partir des modèles proposés. 4
Partie I Contexte de travail. L objectif de cette partie du mémoire est de présenter le domaine visé par notre contribution que sont les systèmes temps réel. En particulier, on s'intéresse aux divers éléments mis en place lors du développement de tels systèmes que sont les méthodologies, les langages et les techniques de validation et de vérification. 5
1 Notions de système réactif et de contraintes temps réel 1.1 Les systèmes réactifs Les systèmes informatiques sont traditionnellement classés suivant trois catégories [78] : Les systèmes transformationnels transforment des données pour produire un ou plusieurs résultats. Les programmes de calcul scientifique sont des exemples de systèmes transformationnels. Les résultats produits dépendent uniquement des données traitées. Les systèmes interactifs interagissent avec leur environnement. Leur exécution est contrôlée par une boucle d attente des événements auxquels sont associés des traitements. Pour ces systèmes, l environnement est généralement limité à un utilisateur humain. Les programmes de bureautique sont des exemples de systèmes interactifs. Les résultats produits dépendent des données et des événements. Les systèmes réactifs réagissent aux stimuli émis par leur environnement. A la différence des systèmes interactifs, l environnement évolue de manière indépendante et n attend pas la fin du traitement associé à un stimulus émis. Les systèmes de contrôle - commande sont des exemples de systèmes réactifs. Les résultats dépendent des données, des événements et de leur enchaînement en lien avec l'état de l'environnement. Dans ce travail, nous nous intéressons aux systèmes réactifs et plus précisément aux systèmes réactifs temps réel. 1.2 Les systèmes temps réel Les systèmes temps réels sont une classe de systèmes informatiques réactifs dont le but est de suivre et piloter les évolutions d un procédé dynamique avec des contraintes de temps physique [57]. Le temps de réaction du système aux stimuli du procédé doit être assujetti à la dynamique du procédé. La correction d un système temps réel ne s évalue donc pas uniquement du point de vue fonctionnel (justesse des résultats calculés) et temporel (enchaînement correct des événement) mais également du point de vue temps réel (dates d arrivée des événements) : "Un résultat juste mais hors délai est un résultat faux" [177]. Ces systèmes sont aujourd hui présents dans des domaines tels que l automobile, l avionique, le spatial mais aussi le contrôle de chaînes de production, de processus chimique, etc. Le caractère critique souvent attaché aux systèmes temps réel résulte principalement du souci de préserver le procédé (par exemple un engin spatial), son environnement (par exemple une centrale nucléaire) et les personnes (par exemple un engin de transport). En conséquence, il est nécessaire d appliquer des techniques de validation tout au long du processus de développement de tels systèmes [168]. La validation doit aussi bien porter sur les contraintes fonctionnelles que sur les contraintes temporelles et sur les contraintes temps réel. 1.3 Les contraintes temps réel Dans le cycle de vie d un système temps réel, les contraintes temps réel apparaissent dès la phase d expression des besoins. Ainsi, lorsque sont spécifiées les fonctionnalités du 6
système liées au contrôle du procédé, les contraintes temps réel nécessaires à la garantie de ce contrôle doivent être données. En fait, les systèmes réactif temps réel, sont vus comme un ensemble d'actions qui opèrent sur des données en prenant en compte l'écoulement du temps et des événements qui apparaissent au niveau du système réactif ou de son environnement [125]. De ce fait, les contraintes temps réel doivent être exprimées sur ces trois éléments principaux. Contraintes temps réel associées aux actions Une action peut correspondre à tout traitement ayant une fonctionnalité bien précise au niveau d'un système. Selon [88] une action peut être : Une action primitive : c est une opération consommant une quantité bornée de ressource du système. Une action composite : c est une séquence d actions primitives. Les contraintes temporelles portant sur les actions sont : La date de réveil : c'est l'instant où l'action peut démarrer. L'instant d exécution : il représente l'instant où une action commence à s'exécuter. La durée d'exécution : il représente le temps écoulé pendant l'exécution d'une action. La date de fin d exécution : il représente l'instant où l'action se termine. Contraintes temps réel associées aux événements Un événement est un marqueur temporel, c'est-à-dire une occurrence qui marque un point temporel ayant son importance dans la description du comportement du système. Les événements sont classés en plusieurs types : Un événement périodique est un évènement ponctuel, mais revenant périodiquement, par exemple tous les 5 millisecondes. Il est donc caractérisé par sa période. Un événement sporadique est un événement aléatoire, mais il existe une durée minimale et une autre maximale entre deux occurrences de deux événements successifs. Un événement apériodique est un événement aléatoire dont on ne possède pas d'informations temporelles quant à sa date d'occurrence. Les contraintes temporelles exprimées sur les événements sont : Une durée séparative minimale et maximale entre l'occurrence de deux événements successifs : Dans le cas des événements périodiques un seule durée (période) caractérise l'occurrence des événements. Par contre, deux durées caractérisent l'occurrence des événements sporadiques. Une échéance de bout en bout (End-to-End Deadline) représente un intervalle de temps maximum entre un événement en entrée et un événement en sortie du système. Elles sont typiquement associées à une action (celle déclenchée par l'événement entrée) et se répercutent alors sur les différentes entités qui participent à la réalisation de cette action. 7
Une échéance relative qui porte sur la terminaison d une action, soit entre les deux événements date de réveil et date de fin d'exécution. Ces contraintes apparaissent par exemple avec l éclatement de contraintes de bout en bout correspondant au découpage du logiciel. Contraintes temps réel associées aux données Une donnée représente toute information utilisée par une ou plusieurs actions pour s'exécuter. Les données appartiennent aux deux types suivants : Les données actives : ce sont des données dont la mise à jour provoque une réaction du système et qui se matérialise par le déclenchement d actions (mises à jour d autres données, déclenchement d une alarme,...). La mise à jour des données suit soit une loi périodique (par exemple, la mise à jour périodique de la vitesse d un avion déclenche la mise à jour de l altitude [186] ), soit une loi sporadique. Les données temporelles sont des données datées qui permettent de gérer l historique de leur évolution [168]. Ces données sont soient lues sur le procédé, soit émises vers le procédé. Pour prendre des décisions correctes en tenant compte de l état réel de l environnement, les données manipulées par une application temps réel doivent être cohérentes du point de vue temporel. Les contraintes temporelles exprimées sur ces deux types de données sont : La contrainte de cadence : elle caractérise un intervalle de temps entre deux mises à jour. De telles contraintes sont caractéristiques des systèmes échantillonnés. L'âge d'une donnée est l intervalle maximum entre la date de production par le procédé et la date de consommation par toute action du système. La latence est le délai requis par le système de contrôle pour prendre en compte une donnée (c est à dire la date maximum entre la date de production de la donnée par le procédé et la date de consommation par toute action du système). Selon qu il faille absolument respecter une contrainte ou qu il soit possible de la violer occasionnellement, il est usuel de classer les contraintes dans deux catégories [125]. Les contraintes temps réel «dures» sont celles qu il faut à tout prix respecter. Les contraintes temps réel «souples» sont celles qu il faut respecter autant que possible, mais qui supportent occasionnellement d être violées. 1.4 Conclusion Les systèmes temps réel, sont vus comme un ensemble d'actions qui opèrent sur des données en prenant en compte l'écoulement du temps et les événements qui apparaissent au niveau du système réactif ou de son environnement. Ces événements sont soit des événements périodiques, soit des événements sporadiques. Ils sont caractérisés d'une part par leurs fréquences d'arrivées et des durées d min et d max, et d'autre part, par la contrainte de délai entre un événement en entrée et un événement en sortie. Les données sont caractérisées par une fréquence de mise à jour et possèdent une durée de validité. 8
Nous présentons maintenant les travaux menés autour du développement des systèmes temps réel. Nous parlons d'abord des méthodologies de développement. 9
2 Méthodologies Nous présentons dans ce chapitre les principales méthodologies, les techniques formelles et enfin, les travaux principaux menés dans le développement du système temps réel. 2.1 Principes généraux des méthodologies Le modèle du cycle de vie d une application est un modèle des étapes ou des activités qui commencent quand le logiciel est conçu et se termine quand le produit n est plus disponible pour l utilisation [126]. Le cycle de développement d une application comprend typiquement une étape d expression des besoins, une étape de spécification, une étape de conception, une étape d'implémentation, une étape d intégration et de test, une étape d installation et de vérification ainsi que des étapes d opération et de maintenance. Selon le cycle de développement choisi, ces étapes ou activités peuvent survenir une ou plusieurs fois dans un ordre prédéterminé. Ces étapes font partie de tous les cycles de développement de systèmes indépendamment de la nature, du domaine, de la taille et de la complexité du système à développer. Plusieurs modèles de cycle de développement d une application existent : le modèle en cascade [155], la cycle de vie en V[169], le prototypage rapide [152], le prototypage évolutif [69], le réutilisation de logiciel [70], le développement incrémental [81], etc. Nous présentons rapidement les principes des modèles classiques qui sont le modèle en cascade et le cycle en V. 2.1.1 Le modèle en cascade Le modèle en cascade (figure 2.1) décrit le cycle de vie comme une succession d'étapes conduisant à raffiner des niveaux de description du problème jusqu'à sa réalisation, en partant de la définition jusqu'à l'exploitation et à la maintenance. Chaque étape est liée à l'étape suivante pour représenter le raffinement, et à l'étape précédente pour représenter les corrections par retour-arrière. A chaque étape est associée une phase de vérification ayant pour but de s'assurer de la conformité de la solution retenue avec les spécifications en entrée de l'étape. Un défaut de conformité implique de reprendre l'étape ou de revoir le résultat de l'étape précédente. Ce modèle s'appuie sur le fait qu'un accroissement important de l'effort de validation durant les premières étapes favorise une correction rapide des premières erreurs et réduit le coût de correction considérable lors de l'implémentation. 10
Vérifié KO Besoin Système Besoin Logiciel Vérifié OK Vérifié OK Vérifié KO Conception Préliminaire Vérifié OK Légende Etape Raffinement Rectification Vérifié KO Vérifié KO Conception détaillé Vérifié KO Vérifié OK Implémentation et Vérification Vérifié KO Fig. 2.1 : Le modèle en cascade. Vérifié OK Intégration et Test Vérifié OK Exploitation et Maintenance 2.1.2 Le modèle "cycle de vie en V" Le modèle "cycle en V" considère la vérification et l'évaluation du système à chaque étape de réalisation. Il montre que la démarche de spécification/conception est globalement descendante tandis que la phase de réalisation/vérification est globalement ascendante. Il s'agit alors d'assembler les constituants pour obtenir les fonctionnalités souhaitées. Le cycle de vie en V du génie logiciel (figure 2.2) [169], a largement inspiré le cycle de vie des Systèmes Automatisés de Production. CAHIER DES CHARGES SPECIFICATION SYSTEME Certification Validation EVALUATION TEST OPERATIONNEL TEST INTEGRATION SYSTEME SPECIFICATION LOGICIELLE Validation TEST PERFORMANCE Validation Spécification Correction CONCEPTION PRELIMINAIRE CONCEPTION DETAILLEE Vérification TEST INTEGRATION TEST UNITAIRE Réalisation Conception REALISATION Fig. 2.2 : Cycle de vie en V du génie logiciel. L approche par étapes est adaptée aux systèmes temps réel car ce sont des systèmes dont les besoins sont figés et clairement identifiables. En effet, lorsqu un système est destiné à piloter un procédé, l analyse des besoins se déduit naturellement des lois de commande conçues pour assurer ce pilotage et des caractéristiques physiques de l installation à contrôler. De plus, en identifiant clairement les débuts et fins des différentes étapes, une approche par étape est statique et donc bien adaptée à la certification (ce qui est une nécessité pour la 11
majorité des systèmes critiques). De plus, dans les domaines comme l'automobile, une séparation claire et faite entre ceux qui spécifient (constructeur) et ceux qui conçoivent (constructeur/équipementier) et implémentent (équipementier). 2.1.3 Discussion A partir de ces deux modèles du cycle de développement, on peut conclure que les grandes étapes à suivre afin de développer un système sont la spécification, la conception et l'implémentation. La spécification décrit ce que le système doit faire, mais pas comment il le fait. La conception modélise une abstraction de haut niveau de l'implémentation qui cache tous les détails de l'implémentation. L implémentation décrit précisément l'exécution de l'application. Lors du développement d'un tel système, le passage d'un niveau à un autre est assuré par des opérations de transformations. La nature du problème lié aux systèmes temps réel nécessite donc l utilisation d un processus de développement et de maintenance rigoureux. Les propriétés que le système doit satisfaire doivent être identifiées puis maintenues tout au long du développement lors de chaque transformation. Ceci suppose la mise en œuvre d une ou de plusieurs techniques formelles. Les modèles proposés fournissent des principes généraux pour le développement des systèmes temps réel, mais ne fournissent pas un cadre formel nécessaire aux systèmes visés par cette étude. Nous présentons maintenant, quelques travaux de recherche recentrés sur les techniques formelles. 2.2 Les techniques formelles Dans le cadre du génie logiciel, un technique est qualifiée de formelle lorsque les différentes opérations qu'elle supporte, les objets manipulés par ces opérations ainsi que le système de preuve qu'elle possède sont exprimés dans un langage à syntaxe et à sémantique formelles, à base mathématiques. Les techniques formelles relèvent de la sémantique, c'est-àdire de la représentation mathématique que l'on peut associer à un programme. La vérification de la correction lors du développement de systèmes temps réel nécessite d utiliser des techniques formelles dont l objectif final est d assurer que les systèmes développés satisfont les propriétés exprimées dans le cahier de charges (figure 2.3 et 2.4). Dans ce but, la définition et l utilisation de techniques rigoureuses de développement apparaissent comme une composante indispensable des étapes de production d un système correct. Ces deux activités sont indispensables dans le cycle de développement des applications temps réel et interviennent à tous les niveaux. Le travail mené dans [8] présente une démarche d utilisation des techniques formelles. Après avoir identifier les propriétés que le système étudié doit satisfaire et le langage ou la technique formelle à utiliser, la démarche propose deux cadres d'utilisation des techniques formelles. Le premier assure la vérification des propriétés d une application exprimées par des techniques ou langages permettant leur représentation formelle. La figure 3 reprend ces principes où OP p est l objet programme représentant le système étudié et P p l ensemble de propriétés de OP p. On parlera de vérification de la correction d'un modèle. 12
Représentation du système Représentation des propriétés OP p Expression et vérification de propriétés P p Fig. 2.3 : L'utilisation des techniques formelles pour la vérification. La deuxième approche assure la maintenance des propriétés de programme lors d une opération de transformation ou de raffinement. La figure 4 reprend ces principes où OP p, P p sont définis comme ci-dessus, OP ' p est l objet programme obtenu suite à la transformation, et P ' p l ensemble de propriétés de OP ' p. On ainsi assure la validation du programme transformé et on parlera de conformité de la transformation d'un modèle. Représentation du système Représentation des propriétés OP p P p Opération de développement Conformité de la transformation O P p P p Fig. 2.4 : L'utilisation des techniques formelles lors d'une transformation ou d'un raffinement. L utilisation de techniques formelles rend possible de nombreux développements de programmes et de nombreuses vérifications de propriétés. Par contre, des efforts doivent être faits pour les rendre utilisables, à grande échelle, dans la pratique. 2.3 Développement de systèmes temps réel Après ces présentations d'ordre général, nous présentons, dans cette section, les travaux plus spécifiquement liés au développement des systèmes temps réel. Les travaux de recherche mentionnés dans ce domaine peuvent être classés selon quatre axes principaux. Un premier axe concerne les travaux qui ne se concentrent sur une certaine étape de développement (la spécification, la conception ou l'implémentation). Dans un deuxième axe, les travaux se concentrent sur le raffinement et la transformation entre les étapes. On peut, par exemple, citer les travaux concernant la traduction de langage orienté spécification vers un langage orienté conception. La troisième catégorie de travaux propose de coupler des langages informels à des langages formels. Le dernier axe, enfin, concerne des méthodes globales de développement qui regroupent plusieurs étapes du développement. Dans le premier axe, les travaux menés dans [40] [170] se recentrent sur l'étape de spécification. Plus précisément, ces travaux traitent des langages de spécification et de leurs capacités d'expression de contraintes temps réel. Le travail présenté dans [153] propose d'introduire le temps dans le diagramme de classe d'uml (Unified Modelling Language) 13
[137]. D'autres travaux sont orientés sur l'étape de conception [113]. Par exemple le travail mené dans [155] propose d'intégrer des techniques d'ordonnancement temps réel dans une conception orientée objet (en utilisant le langage UML-RT [171] comme un langage de conception). Enfin, en ce qui concerne la phase de l'implémentation, on peut situer le travail mené dans [11]. Ce travail se concentre sur la traduction automatique d'un programme ESTEREL vers un code microprocesseur. Enfin de nombreux de travaux portant sur la validation et la vérification de systèmes temps réel, nous détaillons ces aspects par ailleurs dans le document. En ce qui concerne le deuxième axe, il s'agit de raffiner un modèle ou transformer un modèle (par exemple la spécification) vers un autre modèle (par exemple la conception). Par exemple, dans l approche proposée par [106], les auteurs se concentrent sur l'optimisation de code générée à partir d'une conception faite en SDL (Specification and Description Language). L'approche étudie deux stratégies pour générer le code à partir du modèle de conception. La première stratégie (Activity Server) est de générer à partir d'un chaque processus SDL un processus VHDL combiné avec une boîte aux lettres. La deuxième stratégie préconise la mise en place d un modèle d exécution orienté événement nommé BAT (Basic Activity Thread). Dans ce cas, on associe une tâche à chaque enchaînement d'actions provoqué par un événement externe. CODARTS [72] est une méthode basée sur SA-RT. CODARTS fournir des éléments pour construire à partir d un modèle SA-RT (Structure Analysis - Real Time) un modèle d exécution multitâche pour une architecture monoprocesseur. Ces éléments sont des règles et des principes aidant à mapper une spécification d un système temps réel sur une conception basée sur Ada comprenant des tâches et des informations de communications entre les tâches. Cette approche est très intéressante mais elle reste limitée du fait de l'aspect informel de SA-RT et des règles de transformation. D'autres travaux [139] ont été proposés dans le cadre de SA-RT/CODARTS : ils proposent d'utiliser le réseau de Pétri coloré avec pour objectif d augmenter la capacité temporelle analytique de CODARTS, l aspect qualité de service et la conception de la concurrence. Cette approche propose de mapper les tâches de CODARTS, les modèles de communication et l exclusion mutuelle par des données partagées en réseau de Pétri coloré. Enfin, l'approche présentée dans [100] propose de combiner UML avec SDL. Cette approche permet de définir les règles de transformation automatique d un sous ensemble formalisé d OMT [100] noté OMT* [130] vers SDL. Cette approche n'intègre pas tous les diagrammes supportés par UML comme le diagramme de composant et de déploiement. Une autre approche proposée par [87] définit un profil d'uml pour SDL nommé "SDL with UML". Ce profil définit un ensemble de spécialisations UML qui permettent d'utiliser un ensemble de concepts d'uml en conjonction avec SDL. En ce qui concerne le troisième axe, les travaux mettent l accent sur plusieurs phases de développement des systèmes temps réel, telles que la spécification, la conception, l'implémentation et la vérification. Dans ce sens, le projet DESS de l'itea [114] propose d'utiliser le langage UML afin de spécifier les système temps réel. Les contraintes temps réel (échéances) sont spécifiées au travers de timers virtuels proposés dans le diagramme de classe. Ce projet propose aussi de traduire la spécification semi formelle d'uml dans un formalisme formel tel que Trio [75], Esterel [38] ou Kronos [185] afin de vérifier des contraintes temps réel. [58] propose d'utiliser une ou plusieurs techniques formelles dans la phase de conception pour décrire le comportement du système par niveaux d'abstraction. Cette formalisation est traduite à partir d'une spécification informelle des besoins. L'implémentation est faite 14
automatiquement en utilisant des synthèses à partir de cette abstraction afin d'assurer que l'implémentation est correcte. La validation dans cette approche est faite via la simulation. Au final, dans le dernier axe, l'approche présentée dans [172] recentre sur deux phases du développement du système temps réel, la spécification et la conception. Tout d'abord, la spécification dans cette approche est faite en utilisant la sémantique UML+. Cette dernière est inspirée des StateCharts temporisés [99]. La conception est la traduction de cette spécification en un modèle UML-RT [171]. L'implémentation est basée sur le fait que UML-RT peut produire directement du code en utilisant les outils existants comme Rational ROSE-RT [192] PROSEUS [35] [21] est un guide méthodologique qui peut être utilisé par des concepteurs voulant utiliser UML pour la description et la spécification et SDL pour l'implémentation de diagrammes UML. Il propose d'utiliser SDL comme un langage intermédiaire entre UML et l'implémentation finale. PROSEUS propose d'utiliser le modèle de SDL pour le prototypage, la génération de code et la vérification de l'application. Il définit les différentes étapes de développement et la méthode de passage entre étapes. Dans chaque étape, PROSEUS propose un formalisme à utiliser et la manière dont il peut être mis en œuvre, mais pas un cadre formel de développement. 2.4 Conclusion En conclusion, le développement de systèmes temps réel doit s'appuyer sur des étapes de spécification, conception et implémentation. Les contraintes temps réel doivent être exprimées à chaque étape du développement. Le passage d'une étape à l autre, si nécessaire, est assuré par des opérations de transformations ou de raffinements. Enfin, la vérification de propriétés fonctionnelles, comportementales et la validation des transformations doit s'appuyer sur des techniques formelles. Nous allons désormais étudier les langages du domaine temps réel susceptibles de supporter une telle approche. 15
3 Langages de développement des systèmes temps réel. Dans ce chapitre, nous étudions, les langages qui peuvent être utilisés dans le cycle de développement de Systèmes Temps Réel (STR). Il s agit au premier lieu de langages utilisés pour spécifier et modéliser les besoins des STR tels que SA-RT, UML et SDL, puis de langages utilisés pour leur conception (LACATRE, SDL-RT). Un point particulier est mis sur SDL. 3.1 Langage de spécification Au niveau de la spécification, la description des systèmes s appuie classiquement sur des langages qui permettent de les spécifier sous différents aspects (les types de données, les fonctionnalités, les protocoles de communication, etc.). Certains de ces langages sont informels comme SA-RT [79], semi-formels comme UML [136] ou formels comme SDL [135]. 3.1.1 SA-RT 3.1.1.1 Introduction Le langage SA-RT fut développé par D.J. Hatley et I.A. Pirbhai afin de spécifier et de concevoir des systèmes temps réel [79]. Il répond aux besoins de ces systèmes en intégrant l analyse structurée de DeMarco [49] et la théorie des machines à états finis pour la représentation d une structure de contrôle [187]. Le langage SA-RT [44] est un langage permettant de spécifier les aspects dynamiques non décrits dans la méthode SA. Ce langage dissocie les aspects fonctionnels et événementiels d une application temps réel. L aspect fonctionnel est une représentation de la transformation que le système opère sur les données via des processus de transformation des données. L aspect événementiel est une représentation des événements qui conditionnent l évolution d un système et la spécification de la logique de contrôle. Cette dernière déclenche les actions, produit des événements en fonction d événements en entrée et fait changer d état le système. 3.1.1.2 Caractéristiques du langage SA-RT [49] est un langage fonctionnel qui permet de spécifier un système temps réel tant du point de vue logiciel que matériel (via des diagrammes d'architecture). De plus ce langage comprend plusieurs points importants concernant les aspects génie logiciel. Le raffinement est assuré par la décomposition descendante de SA-RT. Par ailleurs, la lisibilité dans une spécification SA-RT provient de la hiérarchisation du modèle en utilisant plusieurs niveaux de diagrammes. Ainsi la spécification d un système permet de décomposer celui-ci en plusieurs sous systèmes. La spécification SA-RT est informelle et ne permet donc pas de vérifier le modèle décrit. Afin de pallier ce manque, le projet IPTES (Incremental Prototyping of Technology for Embedded System) [188] propose une méthode basée sur des prototypes. Ces prototypes sont décrits par un langage de spécification qui est une extension de diagrammes SA-RT complétée par des descriptions en Meta-IV. Ce dernier est un langage basé sur le langage formel VDM (Vienna Development Method) [17], pour spécifier les données et les transformations. Les 16
besoins temporels sont exprimés en utilisant un formalisme qui s appelle High Level Timed Petri Net, dans lequel les modèles SA-RT sont transformés. A L'aspect temps réel L aspect temps réel dans SA-RT s'appuie sur des spécifications des temps de réponse et des fréquences de répétitions. Ces deux contraintes ne sont apparentées qu'aux signaux présents à l'interface du système ou ceux présents dans les diagrammes de contexte. La fréquence de répétition est spécifiée pour les signaux primitifs externes dans le dictionnaire de données. Le temps de réponse entre une entrée et une sortie est défini sous forme de table listant les événements qui sont détectés aux entrées du système, les événements correspondants qui doivent se produire aux sorties du système et les contraintes d'échéance à l intérieur desquels le système doit générer ces réponses. Enfin le travail mené dans [142] propose de compléter la spécification SA-RT par des spécifications exprimées sous forme de Réseaux de Petri avec pour un objectif d améliorer les aspects formels et temporels. La spécification du contrôle est faite par les réseaux de Petri qui permet de prendre en compte certains aspects temps réel comme, par exemple, l'utilisation du chien de garde pour définir des fenêtres temporelles associées à la prise en compte de certains événements. L inconvénient majeure réside dans la génération du graphe de marquage avec le nombre de places et de connections qui peut être assez très grand même pour des petits systèmes. 3.1.1.3 Conclusion Le langage SA-RT est très répandue et très utilisée pour spécifier les systèmes temps réel, vraisemblablement à cause de sa simplicité d utilisation et son pouvoir d expression, graphique en particulier : SA-RT possède l'avantage d'être bien lisible car la spécification est faite d une manière hiérarchique. Cependant cette spécification est informelle et ne permet pas de vérifier directement le modèle. Les travaux menés s'appliquent à fixer une sémantique au langage. Pour autant, actuellement, peu de travaux sont en cours et peu d'outils formels disponibles. Dans la suite, nous présentons les travaux menés autour du langage UML, langage semi formel et orienté objet. 3.1.2 UML 3.1.2.1 Introduction L utilisation de l approche Orientée Objet (OO) dans le développement de logiciel augmente la qualité du fait de la mise en oeuvre des principes de modularité (un logiciel est formé d un ensemble d objets), d encapsulation (une donnée n'est pas accessible que via une interface) et de réutilisation (principe d héritage). Dans le domaine des langage OO, UML [136] s impose comme un standard. UML est un langage de modélisation graphique qui se veut universel pour les systèmes d information. Il est utilisé pour percevoir et documenter les phases de développement des systèmes. 17
UML a été standardisé en 1997 par l organisme de normalisation industriel OMG (Object Management Group) [194] et a fait l objet d améliorations successives jusqu à ses dernières versions (UML 0.8 UML 0.9 UML 1.0 à UML-2.0 [194] ). En fait, UML dérive de trois différentes approches orientées objet, OMT [154], OOSE [132] et BOOCH [39] [22] UML définit une sémantique pour les modèles objets et fournit des notations pour capturer la structure et le comportement du système. 3.1.2.2 Principes d'uml Lors de la modélisation d'un système, UML voit le système à travers plusieurs niveaux d'abstraction exprimés par divers diagrammes. Le diagramme de cas d utilisation est utilisé pour décrire les interactions entre l'environnement et l'application. Ce diagramme se compose de l'ensemble des acteurs, du système et des cas d'utilisation eux-mêmes. Chaque acteur représente un rôle joué par une personne ou un élément qui interagit avec le système. Le cas d'utilisation regroupe la famille des séquences d interaction (les scénarios) du point de vue de l utilisateur. Le diagramme de classe lui, exprime la structure statique d un système, en termes de classes et de relations entre ces classes. Chaque classe consiste à un ensemble d'attributs qui représentent les données et un ensemble des méthodes qui représentent les services. Le diagramme d'instance décrit les objets qui constituent le système. Pour présenter le comportement dynamique d un classe, le diagramme d'état transition (Statechart) définit les méthodes à exécuter en fonction de l état courant et des messages reçus. Enfin, le diagramme d'activité permet de décrire un enchaînement d'actions. Les diagrammes de séquence et de collaboration permettent de modéliser les interactions entre les objets au cours de scénarios donnés. Ils s'appuient sur les cas d'utilisation, les diagrammes de classe et d'instance. Tous ces modèles peuvent être "décorés" de contraintes non fonctionnelles (temps, précédence, etc.) à l'aide de mécanismes d'extension d'uml et du langage de description de contraintes OCL (Object Constraint Language specification) [136]. Les architectures matérielles et logicielles d'un système peuvent être décrites en UML via les diagrammes de déploiement et de composants respectivement. Dans la suite, nous présentons les caractéristiques du langage (aspect génie logiciel, formel et temps réel) et les travaux mentionnés autour de chaque aspect. 3.1.2.3 Caractéristiques du langage A Aspect génie logiciel UML a été créé dans le but de fournir à l utilisateur la possibilité de modéliser tous les aspects d un système. Le raffinement n est pas formellement défini mais on peut l exprimer par les relations de dépendances entre paquetages en utilisant le stéréotype «refine» [15]. La validation du raffinement s effectue de manière manuelle. 18