Validation temporelle de réseaux embarqués critiques et fiables pour l automobile

Transcription

1 N d ordre : Année 2004 Thèse Validation temporelle de réseaux embarqués critiques et fiables pour l automobile 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é : Informatique par Karen GODARY Soutenue le 3 novembre 2004 devant la Commission d examen Jury Mme. Isabelle AUGÉ-BLUM Maître de conférences Co-Encadrante M. Samuel BOUTIN Direction de la Recherche Renault M. Richard CASTANET Professeur Rapporteur Mme. Anne MIGNOTTE Professeur Directrice de thèse M. Jean-Pierre THOMESSE Professeur Rapporteur M. Yvon TRINQUET Professeur Président Version du 19 avril 2005

2 2

3 Remerciements Il est d usage d effectuer des remerciements au début des manuscrits de thèse. Malgré l apparente formalité de cette étape, c est cependant avec sincérité et une réelle gratitude que je me plierai à cette tradition. Les travaux présentés dans ce manuscrit ont été effectués au laboratoire L3i, Ingénierie de l Informatique Industrielle, puis au laboratoire CITI, Centre d Innovations en Télécommunications et Intégration de Services, de l INSA de Lyon. Je tiens à exprimer ma gratitude à Madame Anne Mignotte, directrice du laboratoire L3i, et à Monsieur Stéphane Ubeda directeur du laboratoire CITI, pour leur accueil. Je remercie la Direction de la Recherche Renault, en particulier Samuel Boutin et Ray Snyder, qui par leur collaboration et leur investissement ont rendu ces travaux possibles. Je remercie bien sûr Anne Mignotte et Isabelle Augé-Blum, co-encadrantes de ma thèse, qui par leur soutien, leurs conseils, leur tolérance et leur complémentarité m ont beaucoup apporté et m ont permis de mener à bien ce travail. Je remercie également les membres de mon jury, en particulier Richard Castanet et Jean-Pierre Thomesse, qui ont accepté d être rapporteurs de cette thèse, et Yvon Trinquet qui a accepté la charge de président de soutenance. Je tiens également à remercier le département Télécommunications Services & Usages de l INSA de Lyon, et ses deux directeurs successifs Claude Guédat et Attila Baskurt, qui m ont fait confiance et m ont accueillie au sein de leur équipe enseignante. Je remercie chaleureusement les membres du CITI (Jean-Philippe, pour ses conseils et tout le reste, SFR pour le café et la clé,..) et mes compagnons de bureau successifs qui, par leur sympathie et leur aide, m ont permis d avancer dans mes recherches et surtout Antoine, qui en plus de son amitié, m a prêté son portable pour pouvoir rédiger cette thèse dans tous les lieux du monde et de l univers. Je remercie également les stagiaires de DEA et de PFE qui m ont aidée dans mes recherches, en particulier Marc Riner pour sa collaboration à l étude des formalismes, et également ceux qui m ont aidée (ou pas) sur un plan différent : merci la Ahou Corp. Ensuite, je tiens à remercier de tout mon coeur ma famille, mes parents, Céline et Bertrand qui m ont toujours soutenue et encouragée, même et surtout dans les moments les plus difficiles. Ma reconnaissance va particulièrement à mes parents, pour leur amour et leur patience et à toi, maman, pour tes bons pique-nique et l abnégation dont tu as fait preuve pour la relecture de ce manuscrit! Je ne peux oublier non plus mes amis qui en ces instants, m ont prouvé combien ils étaient chers : Sonia, Béa, Fanny, Vaness, Alex, vous qui avez su comment m aider ; les filles de mon équipe et ma coach, qui m ont comprise et soutenue ; et bien sûr toi, Antoine, sans qui ces instants auraient été beaucoup plus durs.. 3

4 Et enfin, car je le lui ai promis, je remercie ma souris, qui malgré les vols planés et autres chutes spectaculaires autant qu inattendues, ne m a jamais lâchée. Je remercie donc toutes ces personnes qui ont permis l aboutissement de ce doctorat qui m a beaucoup enrichie, et qui m ouvre maintenant de nouvelles portes et de nouveaux horizons. 4

5 Table des matières I Partie 1 - CONTEXTE 13 1 Contexte de l étude Le contexte automobile Applications et systèmes cibles Contraintes Fiabilité Définitions Fiabilité d un système Tolérance aux fautes dans un système automobile TTA - Time-Triggered Architecture Architectures embarquées pour l automobile L architecture TTA Architecture générale Topologies Sous-système hôte Le protocole TTP/C : services de base La technologie Time-Triggered Structures de données de base Services de communication Services des couches supérieures La tolérance aux fautes dans TTA Hypothèses de fautes de TTA Contention des fautes et des erreurs Hypothèses de fautes de TTA Garantie des hypothèses Notion de couverture Solutions matérielles Le bus guardian Topologie en étoile Solutions logicielles : les services de fiabilité CRC et status des trames Membership et acquittement Signe de vie de l hôte et du contrôleur La redondance Redondance d application La couche FT layer Conclusion

6 4 Contexte : conclusion 41 II Partie 2 - VALIDATION : ETAT DE L ART 43 1 Validation d un système Validation dans le processus de développement d un système Validation a posteriori Peer reviewing Test Injection de fautes a posteriori : conclusion Validation a priori Preuve Méthodes basées sur des modèles formels Simulation Model checking Résumé - Comparaison des méthodes Validation temporelle pour TTA : état de l art Injection de fautes - projet FIT Expérimentations Résultats Simulation Validation formelle par la preuve Preuves d algorithmes indépendants Intéractions des algorithmes Couplage de méthodes de validation Validation : conclusion 57 III Partie 3 - METHODOLOGIE DE VALIDATION POUR TTA 59 1 Méthodologie de validation Première phase : conception d un modèle abstrait validé Deuxième phase : validation des bornes Choix du formalisme de validation Formalisme de modélisation pour TTA Pouvoir d expression pour TTA Représentation du temps Présentation de cinq formalismes potentiels pour la modélisation de TTA Comparaison du pouvoir d expression Méthodes d analyse Graphe des classes d états Graphe des régions Graphe de simulation en temps discret : LTS Complexité et comparaison théorique Expérimentation des automates hybrides linéaires avec HyTech

7 2.4 Comparaison de deux méthodes : UPPAAL vs SDL+RdPT Choix des outils d analyse Comparaison expérimentale Optimisation de l analyse de TTA avec UPPAAL : abstractions L outil UPPAAL : modélisation et validation Formalisme de modélisation Expression des propriétés Méthode d analyse : le model checking symbolique Optimisations de l outil UPPAAL Complexité et méthodes d optimisation Implémentation et stockage des états symboliques Optimisation de l algorithme de model checking Abstractions du modèle de TTA Réduction des entrelacements Réduction du nombre d horloges Réduction du nombre d automates : fusion Applications d abstractions : résultats Vérification du modèle conceptuel Méthodologie : conclusion 113 IV Partie 4 - RESULTATS Modélisation Hypothèses Modélisation du comportement normal Modèle global Modélisation du sous-système hôte Modélisation du sous-système de communication Scénario Paramètres du modèle Abstraction du niveau hôte Valeurs des paramètres Exemples de validation de bornes temporelles Borne temporelle du service de réintégration Modélisation de la réintégration Réintégration après une faute symétrique Réintégration après une faute byzantine Borne temporelle de la détection d une perte de membership Services de membership et d acquittement Bases de la modélisation Modélisation du contrôleur Modélisation des fautes Validation Borne temporelle composée : détection d une perte de membership et réintégration Somme des bornes des services

8 2.3.2 Modélisation Validation : borne composée Résultats : conclusion Bornes temporelles validées par notre méthodologie Comparaison avec des bornes temporelles existantes Exemples d utilisation des bornes temporelles Publications internationales Publications nationales Rapports internes de recherche

9 Introduction 9

10 Introduction Introduction Dans le domaine de l automobile, la tendance actuelle est au remplacement des parties mécaniques par de l électronique embarquée dans les véhicules. Cette technologie offre en effet de nouvelles possibilités, en particulier en terme de sécurité des véhicules et des composants et en terme de coût de production et de maintenance. Il existe déjà des cas de systèmes électroniques embarqués. Cependant, dans le domaine automobile, ces systèmes ne concernent en général que des applications de confort, c est-à-dire non critiques, ou sont des applications de soutien aux systèmes mécaniques comme par exemple l ABS (Anti-lock Braking System) qui est un soutien au système de freinage classique. Dans le domaine de l avionique 1, des systèmes électroniques sont déjà utilisés pour la gestion des applications critiques, comme par exemple l application fly-by-wire, ou le moteur de contrôle du système de commandes électroniques d un avion. Les contraintes du domaine de l avionique sont cependant différentes de celles des constructeurs automobiles, en particulier sur le plan du coût de conception. Il était donc nécessaire de concevoir une architecture spécifique aux contraintes du domaine automobile, et d intégrer dans le cycle de développement un nouveau processus de validation adapté à ces nouveaux systèmes embarqués critiques. Les applications concernées sont des applications liées à la gestion des services critiques des véhicules. Ces applications sont appelées X-by-wire, comme par exemple le break-by-wire qui est le service de contrôle de freinage. Ces systèmes sont des systèmes distribués, temps réel et critiques sur le plan de la fiabilité. Ces applications doivent donc être basées sur des architectures spécifiques, implémentant des services de gestion des contraintes temporelles et de la tolérance aux fautes. Le processus de validation dédié à ces systèmes devra donc permettre la validation des contraintes temporelles en présence de fautes. L architecture TTA (Time-Triggered Architecture) a été développée spécifiquement pour répondre aux contraintes des applications X-by-wire par un consortium d industriels et d universitaires. TTA est une architecture comprenant plusieurs composants distribués autour d un bus de communication redondant. Chacun de ces composants est formé de plusieurs couches implémentant des services indépendants, reliées entre elles par une mémoire partagée. La couche inférieure implémente un contrôleur de communication exécutant le protocole TTP/C (Time Triggered Protocol for class C). Ce protocole implique une gestion TDMA (Time Division Multiple Access) de l accès au bus, c est-à-dire que les différents composants possèdent une période d émission fixe et déterminée statiquement par un ordonnancement prédéfini des tâches et des messages. Ce comportement déterministe permet un contrôle total du temps et du comportement temporel du système. En plus des services de communication de base, l architecture TTA permet la tolérance aux fautes de façon matérielle ou logicielle, ou avec de la redondance. La redondance est la stratégie la plus courante dans la tolérance aux fautes. Elle est parfois la seule solution pour tolérer certains types de fautes comme par exemple les fautes permanentes. TTA intègre certaines formes de redondance, et offre la possibilité d en utiliser d autres, en particulier la redondance d applications. Les différents mécanismes et services de tolérance aux fautes sont directement intégrés à l architecture, et assurent le bon fonctionnement du système sous certaines hypothèses de fautes. Les scénarios de fautes sortant de ces hypothèses seront détectés et une stratégie spécifique est définie pour le traitement de ces cas d urgence. Dans ce contexte de temps réel et de tolérance aux fautes, le comportement d un service est aussi important sur le plan de son bon fonctionnement que sur le plan de son temps d exécution. Par exemple 1 http ://tttech.com/customers/aerospace.htm 10

11 un service de détection d erreurs devra non seulement détecter l erreur, mais le faire dans un temps borné. Une nouvelle notion doit donc être ajoutée pour la validation de l architecture TTA : la validation des bornes temporelles de ses services. La détermination d une technique de validation adaptée à la validation d un système dépend de plusieurs critères. Dans le contexte industriel, et encore plus automobile, le temps et le coût du processus sont des facteurs indispensables à prendre en compte. Dans le contexte spécifique des systèmes embarqués critiques, la validation produite doit être garantie. Ces différents éléments orientent le choix d une technique de validation formelle, et pouvant être effectuée a priori, c est-à-dire tôt dans le processus de développement. Les méthodes formelles se basent sur une modélisation formelle du système et permettent une plus grande garantie de la validation, tandis que la détection anticipée des fautes de conception permet une économie en temps et en coût. Plusieurs techniques de validation ont été appliquées à l architecture TTA, qui ont conduit à la validation de certains algorithmes, à la validation des hypothèses de fautes, et parfois à la détection d erreurs de conception menant à la correction des spécifications. Cependant, la plupart de ces techniques ne permettent pas une validation formelle de l architecture, ou ne permettent la validation de l architecture que partiellement. Il est donc nécessaire de définir une nouvelle méthodologie de validation de l architecture TTA, permettant la validation des bornes temporelles de ses services en présence de fautes. Cette thèse propose une telle méthodologie. Elle a été réalisée dans le cadre d une collaboration entre le laboratoire CITI et la direction de la recherche de Renault. Plan du manuscrit Le manuscrit de cette thèse se compose de quatre parties. La première partie présente tout d abord une introduction du contexte de cette thèse, du domaine automobile et des applications X-by-wire. En particulier, cette partie insiste sur les différentes contraintes impliquées par ce contexte. Puis l architecture TTA est décrite, architecture conçue pour répondre aux contraintes précédentes. Cette description se concentre sur les services de base de TTA et de son protocole de communication TTP/C. Enfin, une dernière section donne la description détaillée des différents mécanismes de tolérance aux fautes intégrés à cette architecture. La deuxième partie est un état de l art des différentes méthodes de validation existantes dans le domaine de la validation de systèmes. Une définition est donnée des principales caractéristiques des méthodes existantes, et des avantages et inconvénients de leur application à notre contexte de la validation temporelle de systèmes critiques pour l automobile. Puis un résumé des résultats des différentes méthodes de validation appliquées à l architecture TTA est proposé qui montre que, malgré les résultats obtenus, aucune validation formelle de l architecture globale ni de ses bornes temporelles n existe. Cette partie conclut donc sur l utilité du développement d une nouvelle technique de validation de TTA, basée sur la méthode du model checking. La troisième partie est la présentation d une méthodologie de validation des bornes temporelles des services de TTA. Cette partie donne la description générale de cette méthodologie, qui est composée de deux phases : la conception d un modèle abstrait et validé de l architecture TTA, puis la validation effective de ce modèle. Le reste de cette partie est consacré à l explication de la première phase et à son application à l architecture TTA. Tout d abord, la conception du modèle repose sur le choix d un formalisme de modélisation adapté à la représentation du système et de ses caractéristiques. Le choix du formalisme pour la modélisation de TTA est expliqué, en se basant sur une analyse théorique des caractéristiques de TTA, ainsi que des pouvoirs d expression et d analyse des différents formalismes. Cette analyse théorique a été complétée par une comparaison expérimentale, afin de pouvoir aboutir au choix final du formalisme et de son outil associé : les TSA (Timed Safety Automata) et l outil UP- 11

12 PAAL 2, développé par les universités Aalborg University (AAL) au Danemark et Uppsala University (UPP) en Suède. Cette première phase de la méthodologie permet de concevoir un premier modèle du système : le modèle conceptuel. Ce premier modèle est cependant trop expressif pour être efficace lors de son analyse et mène souvent à un dépassement des limites de l outil. Une section présente alors des techniques d optimisation de la complexité du processus d analyse. Cette optimisation s effectue d une part par des techniques d optimisation implémentées directement dans l outil UPPAAL. D autre part, notre méthodologie intègre, dans une deuxième étape de la phase de conception du modèle, des règles d abstraction qui permettent des optimisations complémentaires de la complexité de l analyse. Enfin, la quatrième partie illustre la deuxième phase de notre méthodologie : la validation effective des bornes temporelles de TTA avec UPPAAL. L environnement nécessaire à la validation est tout d abord introduit, en précisant les hypothèses de fautes et de modélisation, en décrivant le modèle de base de l architecture (le fonctionnement normal) et le scénario applicatif considéré. Puis une étude détaillée de la validation des bornes temporelles de deux services de TTA est effectuée, ainsi que celle de la borne temporelle de leur composition. Cette partie s achève par la liste de l ensemble des bornes obtenues par l application de notre méthodologie sur différents services de TTA sous différentes hypothèses de fautes, par une comparaison avec une borne extraite de la littérature par une méthodologie proche de la nôtre, et par deux exemples d utilisation de ces bornes temporelles. Ce manuscrit se termine par une conclusion de nos travaux et par la présentation de nouvelles pistes de recherche. Confidentialité Ce travail de doctorat ayant été effectué sous contrat industriel, les annexes et la partie 1.3 ne seront pas incluses dans la version diffusable de ce document

13 Première partie Contexte 13

14 14

15 Chapitre 1 Contexte de l étude L étude réalisée dans cette thèse se situe dans le contexte des architectures embarquées pour l automobile. Ce domaine possède des caractéristiques particulières et entraîne ainsi des contraintes spécifiques. En particulier, les systèmes cibles supportent des applications critiques sur le plan de la fiabilité. Ce sont des systèmes embarqués distribués, à fortes contraintes temporelles et tolérants aux fautes. Pour répondre à leurs contraintes spécifiques de fiabilité, des architectures ont été développées, comme par exemple TTA 1 (Time-Triggered Architecture) [Kop98], [KB03], intégrant des mécanismes de tolérance aux fautes. Cette partie est composée de trois chapitres. Le premier chapitre aborde le contexte automobile, par une description des systèmes cibles et des contraintes qui y sont rattachées. Ensuite, le contexte de la fiabilité d un système, et plus particulièrement de la tolérance aux fautes, sera introduit de façon globale. Le second chapitre traite des architectures spécifiques développées pour le contexte défini, et en particulier d une architecture particulière : TTA (Time-Triggered Architecture). Cette architecture est basée sur un protocole de communication, TTP/C (Time-Triggered Protocol for Class C applications, [KG94], [TTT03]). Le dernier chapitre décrit plus en détail les différents mécanismes de tolérance aux fautes implémentés dans TTA. 1.1 Le contexte automobile Applications et systèmes cibles L évolution technologique actuelle dans les voitures s oriente vers la substitution des composants mécaniques par des composants soit intégrant de l électronique, soit complètement électroniques et communiquant grâce à un réseau. L amélioration des standards de sécurité dans le domaine automobile passe en effet par le remplacement des structures mécaniques par des systèmes distribués, fiables et tolérants aux fautes, embarqués dans le véhicule. Les systèmes informatiques embarqués peuvent également implémenter de nouvelles fonctionnalités complémentaires permettant l amélioration de la sécurité. L introduction de l électronique peut de plus, par exemple, offrir une baisse du coût global de fabrication, une diminution de la pollution, une amélioration des performances ou une réduction du poids et du volume utilisé. Depuis plusieurs années, des applications informatiques non critiques sont embarquées dans les véhicules pour assurer des fonctionnalités de confort, comme par exemple la gestion des vitres électriques ou la régulation de la pollution. Ces applications ne concernent cependant pas les applications de contrôle des fonctionnalités liées au fonctionnement des véhicules, comme par exemple le contrôle du freinage ou de la direction. Ces applications sont des applications critiques, ou temps-réel dur, c est-à-dire que la violation de leurs contraintes temporelles peut avoir des conséquences catastrophiques. Ces applications

16 sont dites de classe C dans une étude menée par le comité SAE (Society of Automotive Engineers) [SAE94]. Elles pourront améliorer la sécurité des véhicules en déchargeant le conducteur des tâches courantes et en l assistant dans les situations critiques, et permettront un gain du coût des véhicules. Il existe déjà des cas concrets d introduction de l électronique dans des systèmes critiques. Ces fonctionnalités ne sont cependant pour l instant que des fonctions complémentaires, assistées en cas de fautes par l ancienne structure mécanique. Un exemple typique est l ABS, qui gère les forces de freinage appliquées aux roues sans toutefois remplacer le système de freinage mécanique. L objectif est cependant de supprimer totalement cette charge mécanique, dans des systèmes dit X-by-wire. Un système X-by-wire est conçu comme un système distribué composé de plusieurs composants tolérants aux fautes, connectés par un système de communication temps-réel fiable. Le X de X-by-wire représente une application critique de classe C, comme par exemple le système break-by-wire illustré sur la figure : le trait rouge représente le système de freinage, reliant les quatre composants gérant les roues et le capteur de pédale de frein. Cette figure montre également (en jaune) un système de transmission. FIG. 1.1 Break-by-wire, système critique embarqué pour l automobile L introduction de ce type de systèmes by-wire dans les véhicules est déjà réalisée dans le domaine de l avionique. De nombreux systèmes critiques dans les avions sont gérés par des systèmes électroniques embarqués, et non plus par des systèmes mécaniques. Le domaine de l avionique n a cependant pas les mêmes contraintes que l automobile sur le processus de développement, en particulier sur le coût. Par exemple, le taux de redondance utilisé pour garantir la tolérance aux fautes dans l avionique est beaucoup trop coûteux à l échelle d un véhicule automobile. Dans notre contexte, les architectures employées sont donc différentes, avec des contraintes différentes Contraintes Sûreté de fonctionnement L industrie automobile est un domaine impliquant directement la vie d êtres humains. Le principal facteur à prendre en considération est donc la sûreté de fonctionnement, c est-à-dire la propriété d un système permettant à ses utilisateurs (autre système, humain ou physique) de placer une confiance justifiée dans le service délivré ([Zie96]). La sûreté de fonctionnement est un ensemble de contraintes à respecter lors de la spécification, la conception, le développement et la validation des véhicules automobiles. Elle comprend différents aspects complémentaires : Fiabilité : capacité d un système à fournir le service demandé pendant une durée donnée (continuité du service) ; Maintenabilité : capacité d un système défaillant à redevenir opérationnel ou à être réparé ; 2 The Rare Glitch Project : Verifying Bus Protocols for Embedded Systems, Edmund Clarke and Daniel Kroening, Carnegie Mellon University 16

17 Disponibilité : capacité d un système à délivrer le service attendu à un instant donné ; Sécurité-Innocuité : aptitude d un système à éviter les états défaillants avec des conséquences catastrophiques ; Sécurité-Confidentialité : aptitude d un système à conserver la confidentialité et l intégrité des informations. Les critères de fiabilité, maintenabilité et disponibilité peuvent être définis comme des mesures permettant de quantifier l alternance entre l état correct du système, c est-à-dire lorsque le service fourni accomplit la fonction demandée, et l état incorrect lorsque le service délivré n accomplit pas cette fonction. Contraintes du X-by-wire : fiabilité et temps-réel L importance relative des différents critères de la sûreté de fonctionnement dépend des fonctions applicatives du système cible. Dans le contexte des systèmes X-by-wire, la principale caractéristique des applications est leur besoin essentiel de fiabilité, ce terme regroupant dans le contexte de la sûreté de fonctionnement les attributs fiabilité, disponibiblité et maintenabilité. La fiabilité inclut de nombreuses contraintes et mécanismes, concernant en particulier la tolérance aux fautes, la détection d erreurs ou le service d acquittement. Ces différents éléments seront décrits dans la partie suivante. Un deuxième élément indispensable à considérer dans les caractéristiques des systèmes X-by-wire est le temps réel. Les systèmes temps réel sont des systèmes dont le comportement temporel est soumis à des contraintes fortes. Dans ces systèmes, le dépassement par une tâche de son temps d exécution supposé peut avoir des conséquences catastrophiques, souvent sur le plan financier, ou même impliquant la vie d êtres humains. La gestion du temps réel et des contraintes temporelles est donc un facteur dominant à intégrer à notre contexte. Autres contraintes du domaine automobile En plus de cet aspect sûreté de fonctionnement, l industrie automobile est soumise à des contraintes spécifiques caractéristiques : en tant qu industrie de masse grand public, le domaine automobile est soumis à une forte contrainte de coût et de temps sur le processus de conception. Ces contraintes s appliquent à tous les stades du processus, de la conception au développement, la validation et la maintenance, contrairement à des domaines comme l avionique par exemple pour lesquels la production en petite série réduit les contraintes sur les coûts matériels par rapport à ceux du développement logiciel. une caractéristique intrinsèque à l automobile est le découpage en fonctionnalités complémentaires et modulaires. D une part, une même gamme de véhicule est proposée avec différentes options fonctionnelles. D autre part, l évolution rapide des gammes et la conception répartie entre différents équipementiers nécessitent une possibilité d utilisation de fonctionnalités hétérogènes. La modularité fonctionnelle est donc un élément essentiel dans la conception de l architecture. d autres facteurs influencent le processus de conception, comme le respect de la législation (normes anti-pollution en Europe par exemple). La réduction du poids et de l encombrement, ainsi que de la consommation sont également des facteurs qui entrent en compte dans la conception. L étude des systèmes caractéristiques du contexte des applications X-by-wire dans l automobile a permis d extraire un certain nombre de contraintes à respecter lors de l implémentation des architectures de ces systèmes. La principale contrainte reste pour ces applications critiques le besoin de fiabilité du système à faible coût, dont les principes fondamentaux vont être présentés dans la section suivante. 17

18 1.2 Fiabilité Définitions Défaillance, erreur, faute Les termes de défaillance, erreur et faute peuvent sembler synonymes dans le langage commun. Ils ont cependant, dans le contexte de la tolérance aux fautes, des définitions distinctes ([Jal94]) : une défaillance représente un mauvais fonctionnement du service fourni par le système ; une erreur est la cause d une défaillance : elle se rapporte à un état erroné du système, et donc peut être aisément observée et évaluée ; une faute est la cause d une erreur : la détection d une erreur signifie qu une faute s est produite. La différence fondamentale entre ces trois concepts réside dans leur rôle au sein d un système. D une part, la faute étant à la base des problèmes, une solution simple de garantie du fonctionnement fiable d un système est d empêcher son occurrence. D autre part, les erreurs sont le reflet de la faute dans un état du système. Elles sont donc aisément détectables et éventuellement réparables. Enfin, les défaillances sont les conséquences finales des fautes, une modification du service fourni. Elles permettent de mesurer l effet des fautes sur le système. Ces différentes caractéristiques impliquent que des techniques liées à la fiabilité pourront être basées sur l une ou l autre de ces notions. Elles se reportent cependant toutes, directement ou non, à la faute initiale, et seront souvent considérées globalement comme un traitement des fautes. Confinement des fautes L occurrence d une faute dans un composant d un système et l apparition de l erreur et la défaillance de ce composant qui en résulte, entraîne souvent une propagation à travers tout le système en générant de nouvelles fautes aux autres composants. Il apparaît donc une notion de domaine ou région de confinement, qui est une partie d un système dans laquelle peut se propager une faute. La caractérisation de ces domaines de confinement selon différents critères peut conduire à une caractérisation des différents types de fautes d un système. Classification des fautes La caractérisation des différents types de fautes peut s effectuer dans un premier temps en fonction des différents modes de défaillances résultant de ces fautes. Les fautes se distinguent par exemple suivant le domaine ou les conséquences des erreurs qu elles produisent ([Bau01]). Une faute peut modifier la valeur des données transmises. Elle peut également être temporelle, c est-à-dire que l information est transmise, reçue ou calculée au mauvais moment. Il est également possible de considérer les fautes spatiales, c est-à-dire qu une même faute touche tous les éléments situés dans un espace géographique donné. Une autre classification des fautes d un système distribué ([Rus01a]) est basée sur le comportement du composant lorsqu il est fautif et la perception des fautes par les autres composants. Ainsi, les fautes les plus simples sont les fautes manifestes, qui ont un effet visible aisément détectable (comme par exemple l absence de transmission). Puis viennent les fautes symétriques, dont l effet est le même pour tous les composants non-fautifs du système. Enfin, les fautes asymétriques ([Ade03b]) peuvent être perçues différemment suivant les composants. Un exemple connu sont les fautes SOS (Slightly Off Specification), se produisant lors de l interprétation du signal reçu : le signal est considéré correct s il est à l intérieur d une fenêtre de fréquence ou de voltage. Une valeur proche de la limite de cette fenêtre peut être considérée correcte par certains récepteurs et incorrecte par d autres. Un autre exemple de fautes asymétriques sont les fautes byzantines 3, c est-à-dire qu un message envoyé est reçu correctement du 3 le terme fautes byzantines est souvent associé plus généralement aux fautes asymétriques. 18

19 point de vue structurel, mais avec des contenus différents. Les fautes asymétriques sont complexes et difficilement détectables. De plus, le type des fautes est bien sûr lié à la durée de la faute : une faute transitoire est de durée limitée, provoquée par un mauvais fonctionnement temporaire du système ou par une interférence externe (souvent un phénomène électromagnétique) ; une faute intermittente est une faute transitoire répétitive, correspondant par exemple à des modifications dans les paramètres d un composant matériel dûes essentiellement à des contraintes mécaniques (vibrations, chocs..) ; enfin, une faute permanente entraine une modification définitive d un paramètre ou d un composant du système, et persistera jusqu à réparation. Enfin, une dernière méthode de caractérisation est de se baser sur la phase d introduction de la faute. On peut donc distinguer les fautes de conception, principalement introduites dans l applicatif ou l ordonnancement lors de la phase de même nom, par opposition aux fautes opérationnelles dues à des problèmes physiques lors de l exécution. La figure 1.2 résume la classification des fautes décrite ci-dessus. Cette classification se limite aux types de fautes pertinentes dans notre contexte. Certains types de fautes ne sont pas considérés. Par exemple, les fautes intentionnelles sont un type de fautes qui a une influence capitale dans des systèmes d applications de gestion d informations très confidentielles (système bancaire par exemple). Ce ne sont par contre pas des fautes significatives dans le contexte automobile. Une liste détaillée des types de fautes spécifiques à deux architectures de l automobile, CAN 4 (Controller Area Network [ISO93]) et TTA (Time-Triggered Architecture, [Kop98], [KB03]), a été effectuée dans le cadre de cette thèse. Le résultat est donné en annexe A. Un exemple de faute de l architecture TTA est la rupture d un lien nœud-réseau. Cette faute est une faute matérielle et permanente, qui empêchera définitivement un nœud d émettre ou de recevoir des messages par ce lien. Si ce lien est redondé dans l architecture, cette faute sera tolérée (pas de perte de message car le deuxième lien fonctionne) et ne perturbera pas les autres nœuds. Un autre exemple de faute, commun à tous les systèmes distribués communicants, est le babbling-idiot : le niveau applicatif tente d émettre à des instants aléatoires et incohérents, ou même de façon continue. valeur manifeste type temporelle comportement symétrique spatiale byzantine transitoire conception durée intermittente phase d introduction permanente opérationnelle FIG. 1.2 Classification des fautes Fiabilité d un système La définition générale de la fiabilité d un système est la capacité de ce système à continuer à fournir un service (pouvant être dégradé ou différent) dans un environnement donné lorsque des événements peuvent causer des dommages majeurs au système ou à son environnement ([LAB 96]). 4 http :// 19

20 Fiabilité La conception et la réalisation d un système fiable passe par l utilisation combinée de quatre méthodes : Prévention des fautes : vise à empêcher l occurrence de fautes à la conception ou à la fabrication ; les techniques utilisées pour cela sont, lors de la conception et de la construction du système, le test et la vérification. Tolérance aux fautes : correspond à un ensemble de mécanismes qui permet au système de fournir un service conforme à ses spécifications malgré l occurrence de fautes ; Elimination des fautes : vise à réduire le nombre de fautes ou la sévérité de leur conséquence, par des tests et par validation pendant la phase de conception et de réalisation, et par de la maintenance durant la vie opérationnelle du système ; Prévision des fautes : vise l estimation de la présence, de la création et des conséquences des fautes par évaluation analytique et expérimentale ; Les mécanismes dédiés à la suppression des fautes sont limités par l impossibilité d anticiper et d éliminer toutes les fautes. Certaines fautes sont imprévisibles ou inévitables comme par exemple les fautes humaines, le vieillissement du matériel ou les catastrophes naturelles. Ainsi, la tolérance aux fautes est un mécanisme indispensable afin d atteindre les conditions de fiabilité extrême des systèmes critiques. C est sur cette notion qu est concentrée l étude menée dans cette thèse. Tolérance aux fautes La tolérance aux fautes est un ensemble de mécanismes de traitement des fautes et des erreurs permettant au système de fournir un service continu même en présence de fautes. Elle peut être traitée suivant deux méthodes différentes : le traitement des erreurs par recouvrement ou par compensation ([Bau01], [Zie96]). La première méthode implémente des mécanismes de détection et d identification des erreurs, puis de recouvrement de l erreur en fonction de son type. Cette fonction de recouvrement entraîne soit une restauration du système dans un état non fautif, soit le passage dans un mode de fonctionnement différent. Cette méthode provoque une réaction dépendante de l application concernée et de la nature de la faute, et donc parfaitement adaptée. Elle entraîne cependant des délais de recouvrement (temps de détection ou de changement de mode de fonctionnement par exemple), ainsi que des surcharges logicielles comme par exemple la nécessité d effectuer des sauvegardes des états du système pour pouvoir revenir dans un état précédent non erroné. La méthode de traitement par compensation est le masquage des défaillances grâce à de la redondance : le système contient des composants redondants afin de pouvoir tolérer les défaillances de l un d eux. Cette méthode permet de décharger le niveau applicatif de la gestion des tâches de tolérance aux fautes. Cela entraîne ainsi une baisse de la complexité des applications, et par conséquent de leur coût et de leur durée de conception, ainsi qu une baisse de la probabilité des fautes de conception. De plus, la détection des erreurs au niveau de l architecture est plus rapide qu une détection logicielle au niveau applicatif, et permet de détecter des erreurs parfois indétectables par le niveau applicatif lui-même s il est défaillant. Un exemple typique est le babbling idiot, pendant lequel le niveau applicatif est fautif et tente d émettre à des instants aléatoires. Enfin, cela permet de développer, de vérifier et de valider ce service de détection une seule fois lors du développement de l architecture, et non chaque fois qu une application est implémentée. L utilisation de la redondance a cependant un coût non négligeable, dépendant du taux de redondance implémenté (quantité d éléments dupliqués). Les deux approches de traitement d erreurs sont souvent supportées dans une même architecture, et sont utilisées de façon complémentaire. La redondance est toutefois la méthode principale utilisée pour la tolérance aux fautes. Une dernière étape de la tolérance aux fautes concerne le traitement des fautes. Une fois l erreur détectée, un mécanisme d identification de la faute responsable de cette erreur est mis en œuvre. Puis une stratégie doit être activée afin d empêcher la faute de se reproduire, soit simplement en rendant 20

21 l élément fautif passif, soit par l activation d un mode de fonctionnement dégradé du service délivré. Cette phase de tolérance aux fautes est effectuée au niveau applicatif et suppose une interaction entre le service de détection des erreurs et celui de traitement des fautes. La redondance La redondance peut être matérielle, logicielle ou temporelle. Elle peut ainsi toucher différents domaines : La redondance matérielle entraîne la duplication de composants matériels, afin de tolérer la défaillance de l un d entre eux. Un exemple évident d une telle redondance peut être la duplication du bus de transmission. Il existe deux formes de redondance matérielle. Le composant dupliqué peut fonctionner en parallèle de l autre composant, dans ce cas la défaillance de l un d eux ne trouble pas le comportement du système. La seconde possibilité est un composant ombre, c est-à-dire qu il ne prend le relais de l autre composant que lorsque celui-ci tombe en panne. Cela implique un mécanisme spécifique de gestion de la transition entre les deux modes. La redondance matérielle est rarement utilisée seule, c est souvent une conséquence de la redondance logicielle. La redondance logicielle, ou redondance d application, implique la duplication de tout ou une partie d une application. Cette redondance implique une redondance matérielle des composants supportant cette application, ainsi que des éléments logiciels supplémentaires afin de pouvoir la gérer. Cette redondance permet la tolérance à plusieurs types de fautes, à condition qu au moins un des réplicas ne soit pas touché par les fautes. Un exemple d une telle redondance est montré sur la figure 1.3. Soit A une application envoyant une information a à une application B, comme sur le schéma de gauche de la figure. La duplication de l application A entraîne également la duplication de son information qui sera transmise trois fois (a1, a2 et a3). Les réplicas A1, A2 et A3 étant la même application, ces informations sont censées être produites au même instant. Cette triple transmission implique donc une redondance matérielle du composant supportant l application, et du support de communication des informations. Il est de plus nécessaire de rajouter un mécanisme, représenté par la boîte grisée G, afin de déterminer à partir de ces trois informations dupliquées laquelle transmettre à l application B. Ce mécanisme peut être de nature différente selon les applications concernées (vote majoritaire par exemple, ou moyenne des trois valeurs). Dans le contexte de la tolérance aux fautes, la gestion de la redondance d informations sera orientée dans le but de tolérer une erreur sur l une de ces informations. De plus, dans le contexte d applications temps-réel, la pertinence d une information ne réside pas seulement dans sa valeur, mais également dans son instant de production. Ainsi, la redondance logicielle implique également l utilisation d un service de synchronisation des réplicas, afin d assurer la pertinence des informations dupliquées : a1, a2 et a3 doivent être produites dans un intervalle de temps réduit et connu afin de pouvoir être considérées comme correctes. A a B A1 A2 a1 a2 G a B A3 a3 FIG. 1.3 Redondance logicielle de l application A Enfin, la redondance temporelle est une duplication des informations, mais dans le domaine temporel. En reprenant l exemple précédent (figure 1.3), le gestionnaire de redondance G ne recevra pas trois informations dupliquées simultanées, mais trois informations dupliquées successives. Cette redondance 21

22 n implique pas forcément la redondance d application : une même application peut par exemple effectuer elle-même cette redondance temporelle en envoyant plusieurs fois le même message. Cette redondance permet la tolérance aux fautes transitoires : même si une faute perturbe l ensemble du système à un instant donné, seule l une des informations dupliquées sera touchée. G A1 a1 a B A2 a2 FIG. 1.4 Redondance logicielle avec composants fail-silent La redondance est utilisée afin de masquer les défaillances des composants individuels. Afin de limiter le nombre de composants redondés, et donc le coût de la redondance, les nœuds peuvent produire un comportement fail-silent, c est-à-dire qu ils ne fournissent que des résultats corrects, ou aucun résultat. Ainsi, pour tolérer la défaillance d un composant, il sera nécessaire d utiliser trois réplicas dans le cas normal, et seulement deux s ils sont fail-silent. En effet, dans le cas normal, comme sur la figure 1.3, trois valeurs dupliquées sont nécessaires : si une des trois valeurs est erronée, au moins deux autres doivent être identiques afin de détecter l erreur. Dans le cas de composants fail-silent par contre (figure 1.4), une valeur erronée n est pas produite. Deux valeurs dupliquées sont donc suffisantes pour tolérer une erreur : si l une est erronée et donc non produite, il restera l autre valeur qui est correcte. La propriété de fail-silence s implémente par des stratégies de détections des erreurs, matérielles ou logicielles, au sein du composant. Une propriété de fail-silence idéale doit s appliquer dans le domaine des valeurs, c est-à-dire qu une valeur produite est correcte, mais aussi sur le plan temporel, c est-à-dire qu une valeur correcte produite doit l être à un instant correct. Plus de détails sur les différents types de redondance d application sont donnés dans le cadre de la redondance de TTA, section Tolérance aux fautes dans un système automobile Cette partie, résultat d une collaboration avec la direction de la recherche Renault, n est pas diffusable pour des raisons de confidentialité. 22

23 Chapitre 2 TTA - Time-Triggered Architecture 2.1 Architectures embarquées pour l automobile Le chapitre précédent introduit les contraintes spécifiques à notre contexte. Les applications X-bywire sont des applications critiques, ce qui entraîne de nouvelles contraintes. Les réseaux de communication actuellement utilisés dans le milieu automobile sont principalement LIN 1 (Local Interconnect Network) [LIN03] et CAN (Controller Area Network) [ISO93]. Le réseau LIN est un réseau économique, utilisé pour les applications de confort, par exemple la gestion des vitres électriques. Il n intrègre en effet pas de mécanismes perfectionnés de détection et de recouvrement d erreurs, il ne peut donc pas être utilisé dans le contexte d applications plus critiques. Le réseau CAN, par contre, intègre de nombreux mécanismes de détection des erreurs. Ce réseau est devenu une norme de référence dans l automobile. Ainsi, le bus CAN est largement utilisé pour un grand nombre d applications distribuées embarquées dans l automobile. Cependant, ce protocole est basé sur une approche event-triggered, c est-à-dire que l évolution du système est liée à l occurrence des événements. Ainsi, le traitement des erreurs (effectué par retransmission automatique) ou la concurrence des requêtes d émission des niveaux applicatifs, peuvent entraîner une surcharge du réseau, et donc une augmentation de la latence ou des pertes de messages. De plus, la détermination d applications prioritaires peut empêcher les autres de transmettre si les prioritaires sont fautives et monopolisent le bus (typiquement le babbling idiot). Ces caractéristiques ne sont donc pas adaptées dans un contexte de temps-réel et de tolérance aux fautes. Dans ce contexte, de nouvelles architectures ont été conçues, basées sur une technologie différente : le time-triggered. Le comportement du système est ainsi basé sur l évolution du temps, et non plus sur l occurrence asynchrone d événements. Cette technologie implique une définition déterministe du système. La première architecture time-triggered développée est l architecture TTA, issue d une collaboration entre des industriels de l automobile, de l avionique et de l aérospatiale et des universitaires. Cette architecture est basée sur un ordonnancement des tâches applicatives défini statiquement a priori. Elle intègre un grand nombre de mécanismes de tolérance aux fautes, de détection mais aussi de traitement des erreurs. Une architecture concurrente, conçue pour répondre aux mêmes besoins, est FlexRay 2. Cette architecture, issue d un consortium d industriels, principalement des constructeurs automobiles et des équipementiers, compense la rigidité des contraintes du time-triggered en intégrant une phase de communication asynchrone afin d accroître la flexibilité de conception des applications. Cela implique le report d une partie de la gestion de la tolérance aux fautes au niveau applicatif. Enfin, une troisième architecture est dédiée au contexte des applications critiques pour l automobile : TTCAN 3. TTCAN applique un ordonnancement statique prédéfini des messages sur un niveau de communication géré par CAN. L ordonnancement statique permet d éviter la concurrence d accès au bus, et donc d éviter les risques de CAN.html/ 23

24 surcharge du réseau. Le traitement des erreurs est géré par CAN, c est-à-dire par retransmission, pendant un intervalle de temps dédié. Les deux dernières architectures citées, FlexRay et TTCAN, sont récentes et leurs spécifications ne sont publiques que depuis peu. Cette thèse s est donc orientée sur l étude de l architecture TTA décrite dans la section suivante. 2.2 L architecture TTA Dans cette section, nous utiliserons les termes anglais des éléments des spécifications ([TTT03]), que nous signalerons en italique, plutôt que de les traduire artificiellement. Cela permet également de faciliter la correspondance avec le document de référence de TTA Architecture générale TTA ([Kop98], [KB03]) est une architecture embarquée pour l automobile composée d un ou plusieurs clusters. Un cluster est un ensemble de nœuds indépendants interconnectés par un réseau de communication de diffusion dupliqué. L interconnexion de plusieurs clusters est présentée dans [Bau01]. Un nœud dans TTA est appelé SRU, Smallest Replaceable Unit [KHK 97a]. C est le plus petit élément remplacé en cas de fautes. Dans la suite de cette thèse, les termes SRU et nœud seront employés indifféremment pour parler d un nœud du système TTA. Chaque SRU est divisé en deux sous-systèmes : hôte et communication. La composition d un SRU est montrée sur la figure 2.1 : Le niveau hôte exécute les applications temps réel distribuées ; les tâches applicatives sont ordonnancées par un système d exploitation temps réel de type OSEKTime ([OSE01b]). Ce système d exploitation (SE) gère également les tâches de la couche FT layer (Fault Tolerant layer). Cette couche spécifique est dédiée à la gestion de la redondance d application implémentée dans l architecture, sur les principes de la norme FTCom [OSE01a]. Cette couche est optionnelle et son comportement dépend des applications et de leur taux de redondance. Le niveau communication est une couche spécifique consacrée à la transmission des messages sur le bus basée sur le protocole TTP/C ([TTT03], [KG94]). Le niveau de communication peut également intégrer un autre protocole TTP/A ([KHE00]. Ce protocole, basé sur des principes similaires à ceux de TTP/C, représente une version moins onéreuse et moins fiable, utilisée pour des applications moins critiques. Il ne sera donc pas l objet de cette thèse. La communication entre ces couches s effectue par des interfaces, zones de mémoires partagées : le CNI (Communication Network Interface) ([KK95]) sépare le contrôleur TTP/C de la couche supérieure, et le FTCNI (Fault Tolerant Communication Network Interface) sépare la couche FT layer de l application. Enfin, l accès au bus est contrôlé pour chaque nœud par un composant indépendant, le bus guardian ([Tem98]). Le fonctionnement de ce composant est décrit dans la section Topologies L architecture TTA se décline en deux topologies différentes : en bus dans la version TTA-bus ou en étoile dans TTA-star (figure 2.2). Dans l architecture TTA-bus, le réseau de communication est constitué de deux bus répliqués. La version TTA-star par contre est composée de deux concentrateurs centraux répliqués qui émulent le bus. Ces deux versions de l architecture TTA se différencient principalement dans le domaine de la tolérance aux fautes, détaillé dans le chapitre 3. La topologie en étoile offre en effet des possibilités de services 24

25 sous système hote Application SE temps réel FTCNI sous système communication FT layer CNI Controleur TTP/C bus guardian FIG. 2.1 Architecture d un SRU supplémentaires à moindre coût, grâce à la centralisation du composant bus gardian. La spécificité de la topologie en étoile est décrite en section FIG. 2.2 Topologies de TTA, figures tirées de [KB03] 2.3 Sous-système hôte Le sous-système hôte contient les tâches applicatives ainsi que le système d exploitation permettant la gestion de ces différentes tâches. Ce système d exploitation est compatible avec la norme OSEK- Time, définie par [OSE01b]. Il se base sur la technologie time-triggered pour gérer l ordonnancement des tâches, c est-à-dire que l exécution des tâches est liée à l évolution du temps et non à l arrivée d événements. Ainsi, il existe une table globale d ordonnancement des tâches statique et prédéfinie au niveau applicatif : le TADL (Task Descriptor List). Le rôle du système d exploitation est de garantir le respect des contraintes temporelles des tâches afin de garantir les instants d émission et de réception des messages au niveau de la couche de communication. Pour cela, les tâches sont considérées comme non-bloquantes (par exemple elles ne peuvent pas stopper leur exécution dans l attente d un événement). La norme OSEKTime prévoit la possibilité de préemption des tâches à la condition que les contraintes temporelles de la tâche préemptée soient respectées. La gestion de ces contraintes doit donc être prévue à la conception de l ordonnancement statique 25

26 des tâches. Le système d exploitation implémente de plus un mécanisme de gestion d interruption afin de pouvoir gérer les cas d urgence. Par exemple, si exceptionnellement une contrainte temporelle n est pas respectée, il s agit de provoquer une réaction du système (souvent un arrêt) en accord avec une routine d interruption programmable par le concepteur. Un exemple de système d exploitation implémentant les bases d OSEKTime peut être trouvé dans le système gérant les maquettes TTTech 4 : TTP-OS. Il reprend les principaux principes d OSEKTime, sans toutefois implémenter tous les mécanismes décrits dans la norme. Les fonctions applicatives sont des fonctions temps réel critiques de classe C, aux contraintes de fiabilité fortes. 2.4 Le protocole TTP/C : services de base La technologie Time-Triggered Le protocole TTP/C implémente une communication par diffusion qui se déroule selon un schéma d accès prédéfini TDMA (Time-Division Multiple Access) [Tan96], comme dans l exemple de la figure 2.3. Ainsi à chaque SRU du système est attribuée une durée d émission fixe et périodique, le slot, pendant lequel il pourra émettre. Tous les slots sont regroupés en TDMA rounds : durant un round les droits d émission sont accordés au maximum une fois à chacun des SRU dans un ordre prédéfini. La phase d exécution normale du système consiste à assurer l ensemble des communications indiquées dans ces rounds de manière cyclique (cluster cycle). cluster cycle round slot A B C D A B C D Noeud1 Noeud2 Noeud3 Noeud4 Noeud1 Noeud2 Noeud3 Noeud4 FIG. 2.3 Accès TDMA Il existe donc un ordonnancement statique et global des messages, défini à la conception, qui doit correspondre à l attribution des slots aux nœuds émetteurs. Ces informations globales des messages à émettre et de leurs instants d émission sont stockées dans une table globale au niveau des SRU : le MEDL (MEssage Descriptor List) dont tous les nœuds possèdent une copie locale. Le MEDL d un nœud contient toutes les informations relatives à l ordonnancement des messages, ainsi que toutes les informations nécessaires à l exécution des services de TTP/C (par exemple les valeurs des paramètres des algorithmes). La connaissance globale et prédéfinie des communications permet d éviter la transmission explicite de l identificateur de l émetteur : à partir de l instant de réception, les nœuds connaissent, grâce au MEDL, le type du message et d où il vient. Le slot représente donc une unité temporelle spécifique. Cette période est découpée en différentes phases indiquées sur la figure 2.4, chacune associée à une phase du comportement des contrôleurs : La phase de transmission TP (Transmission Phase), qui correspond à la transmission effective de la trame ; La phase de post-réception PRP (Post-Receive Phase), pendant laquelle seront exécutés les différents algorithmes liés à la réception d une trame ;

27 La phase Idle, servant de phase intermédiaire et pendant laquelle le contrôleur attend ; La phase de pré-émission PSP (Pre-Send Phase), pendant laquelle un nœud exécute les algorithmes de vérification et de préparation à l émission de sa trame dans le slot suivant. La phase IFG (Inter-Frame Gap) représente l intervalle de temps nécessaire au contrôleur pour exécuter toutes les tâches spécifiques au protocole. Elle regroupe les trois phases qui ne sont pas de la transmission pure, c est-à-dire PRP, Idle et PSP. TP PRP Idle PSP IFG TDMA slot FIG. 2.4 Décomposition d un slot en phases temporelles Structures de données de base Une des structures de données de base de TTA, le MEDL, a déjà été définie section Le protocole TTP/C se base également sur une autre structure : le CState, ainsi que sur des informations transmises dans des types de trames spécifiques. le CState La technologie time triggered est basée sur une vue globale commune du système. En effet, tous les nœuds doivent connaître à un instant donné : le mode courant de fonctionnement du système, l existence éventuelle d une requête de changement de mode en attente, le slot courant, la valeur du temps global, et l ensemble des nœuds actifs du système. Afin de pouvoir stocker ces informations, chaque nœud possède une structure : le CState. Le CState contient toutes ces informations, il refléte l état du système qui doit être le même pour tous les nœuds. Les types de trames Le fonctionnement du protocole TTP/C nécessite plusieurs types de trame : les trames dites normales, permettant de transmettre les données du niveau application. Ces trames contiennent également quelques informations liées au protocole : identificateur du type de trame, requête de changement de mode de fonctionnement, le CState et un CRC calculé sur cette trame. Les trames normales sont en général à CState implicite, c est-à-dire que le CState n est pas transmis directement dans la trame, mais qu il est inclus dans le calcul du CRC (cf section 3.3.1). les trames à CState explicite sont identiques aux précédentes, mais contiennent en plus le CState. Le calcul du CRC portera alors uniquement sur la trame transmise. Enfin, le service d initialisation du système nécessite un type de trames particulier : les trames coldstart. Ces trames contiennent explicitement les informations globales du système : le temps global et le slot courant Services de communication Le protocole TTP/C fournit aux couches supérieures les services suivants : 27

28 transport déterministe des messages, avec une latence et une gigue faibles grâce à la technologie time-triggered. modularité du système, garantie d un temps global, garantie d une vue globale du cluster par les nœuds non défaillants, par des services de membership et de synchronisation (détaillés ci-dessous et dans la section 3.3.2), surcharge minimale du protocole, en longueur et nombre des messages, grâce à la vision globale du CState (transmission implicite), adaptation à des débits élevés. Ces services principaux reposent sur un certain nombre de services spécifiques de base décrits dans cette section, regroupant des services de communication et des services des couches supérieures. Cependant, la majeure partie des services de TTP/C concerne la tolérance aux fautes, et seront décrits dans le chapitre 3 de cette partie. Pour plus d informations sur le fonctionnement des différents services, se référer aux spécifications de TTP/C [TTT03] qui en offrent une description détaillée. Les services développés dans cette partie sont ceux nécessaires à la compréhension des travaux de cette thèse. Transport des données : Le transfert des données entre la couche communication et la couche supérieure s effectue de façon indirecte à travers le CNI. Les accès concurrents au CNI en lecture et écriture sont gérés par des mécanismes spécifiques dépendant de l implémentation (comme par exemple un protocole NBW - Non-blocking Write [KR93]). Gestion du temps : La technologie time-triggered est basée sur un temps global commun à tous les nœuds. TTP/C possède un service assurant une vue globale du temps, et donc une synchronisation des horloges locales des nœuds avec une précision fixée notée ([Kop97], [KHK 97b]). Ce service exploite la connaissance commune des nœuds de l ordonnancement global des messages : chaque nœud mesure la différence entre l instant d arrivée prévu et l instant d arrivée réel d un message, afin de connaître la différence entre l horloge locale de l émetteur et la sienne. Cette information est alors utilisée par l algorithme average tolérant aux fautes [Kop97] pour calculer périodiquement dans chacun des nœuds un terme de correction à appliquer sur leur horloge locale. Le service de synchronisation permet également de détecter les erreurs de synchronisation (Synchronization Error - SE). La détection de ces erreurs dans un temps borné est indispensable à la garantie de l intervalle de synchronisation. La convergence de cet algorithme a été prouvée par validation formelle ([PSvH99], [Pfe03]). Acquittement : Le service d acquittement du protocole TTP/C permet à un nœud de détecter une erreur de transmission de l une de ces trames. Il est directement lié à plusieurs services de tolérances aux fautes implémentés dans TTA. Ces services sont décrits dans la section Initialisation du système : L initialisation du système est effectuée au démarrage ou redémarrage du système complet. Elle s effectue en plusieurs étapes : Initialisation de l hôte et du contrôleur Ecoute des bus pendant un temps prédéfini (le Listen timeout) et attente de réception d une trame à CState explicite ; 28

29 Si une telle trame est reçue : il y a intégration du nœud Si le Listen timeout expire avant la réception d une trame à CState explicite : le système rentre dans une phase de Cold Start, avec envoi d une trame coldstart sur laquelle les autres nœuds du cluster pourront s initialiser. Intégration d un nœud : Le service d intégration permet à un nœud de rejoindre un cluster déjà en fonctionnement. Ce service regroupe en fait deux services différents, suivant l état du nœud à intégrer : la réinitialisation et la réintégration. La réinitialisation permet à un nœud externe de rejoindre un cluster déjà en fonctionnement. C est le cas par exemple pour un nœud mis en route tardivement, ou un nœud fautif dont la faute a provoqué la perte des informations globales du système. L intégration de ce nœud ne s effectuera alors pas sur une trame coldstart comme lors du service d initialisation d un cluster, mais sur une trame avec un CState explicite, émise par l un des nœuds actifs du cluster. L émission régulière de ces trames à CState explicite est en effet une hypothèse du protocole TTP/C. Cela permet aux nœuds désirant se réintégrer de récupérer les informations globales du système, de se synchroniser avec les autres nœuds et de pouvoir intégrer le cluster dans le même mode de fonctionnement. Le service de réintégration permet à un nœud fautif exclu temporairement du cluster de le réintégrer. Ce mécanisme est utilisé après la détection de certaines fautes, lorsque le nœud fautif est encore synchronisé avec les autres nœuds et possède encore les informations globales du système. Par exemple, une faute du niveau hôte d un nœud ne provoque pas de perturbation de la vision globale du niveau communication. La détection d une telle faute cependant l oblige à s exclure temporairement du système pour ne pas perturber les autres nœuds. Il passe alors de l état actif vers l état passif, et cesse d émettre le temps de s assurer qu il possède encore la même vue globale que les autres nœuds. Dans ce cas, il peut repasser en état actif et émettre de nouveau. Les étapes de ce service de réintégration sont : Passage en état passif à l instant de détection de la faute, Dans cet état, le nœud cesse d émettre mais continue à recevoir les trames des autres nœuds. Il tente alors de se réintégrer dans le cluster. Pour cela, il doit recevoir un nombre de trames correctes supérieur à une valeur MIC (Minimum Integration Count), paramètre des spécifications de TTP/C. Lorsqu un nœud en état passif atteint son propre slot (phase PSP), il vérifie si la condition précédente de réintégration est vérifiée. Si oui, il repasse en état actif et peut émettre sa trame. Si non, il reste en état passif. Durant ce processus de réintégration, le reste du système n est pas perturbé et conserve un mode d exécution normal. Ce service est étudié plus en détail dans le chapitre 2 de la partie 4, dans lequel son processus de validation temporelle est détaillé Services des couches supérieures Modes de fonctionnement TTP/C offre aux applications la possibilité d initier des changements de modes de fonctionnement [KNH 97]. A un instant donné, tous les nœuds d un cluster fonctionnent sur le même mode. La requête de changement de mode est transmise d une application vers son contrôleur, puis vers les autres nœuds dans la prochaine trame transmise par le nœud demandeur. Tous les nœuds effectueront ensuite le changement de mode à un instant prédéfini (la fin du cycle de cluster). Ce mécanisme est décrit en détail dans [KNH 97] et sa validation temporelle est étudiée dans l annexe B de cette thèse, ainsi que dans [GAM03a]. 29

30 Synchronisation externe Une synchronisation externe des horloges locales est possible. Cette synchronisation est gérée par l hôte qui peut transmettre au contrôleur un paramètre de correction d horloge via le CNI. Le mécanisme de synchronisation de TTP/C ajoute alors cette correction externe à celle générée par l algorithme interne de synchronisation. Parmi les différentes architectures spécifiques du domaine automobile, cette section décrit les services de base de l architecture TTA. Cette architecture a été conçue pour répondre aux besoins spécifiques des systèmes cibles décrits dans le chapitre 1 précédent, en particulier en terme de tolérance aux fautes. Les services et mécanismes spécifiques, dédiés à la tolérance aux fautes dans cette architecture, sont étudiés en détail dans la section suivante. 30

31 Chapitre 3 La tolérance aux fautes dans TTA Ce chapitre est consacré à la description des services et mécanismes de tolérance aux fautes intégrés à l architecture TTA. 3.1 Hypothèses de fautes de TTA Le but du protocole TTP/C est d assurer le fonctionnement correct du système pour tous les nœuds non fautifs, même en présence de nœuds fautifs. Les hypothèses de fautes de TTP/C ([Rus01a], [BKS03], [TTT03]) sont les fautes tolérées par le protocole TTP/C. Ces hypothèses portent sur le type, la fréquence, le nombre des fautes, ainsi que sur les composants touchés. Les scénarios de fautes non inclus dans les hypothèses annoncées seront gérés par une stratégie NGU (Never Give Up) : à la détection de cette situation, le contrôleur prévient l application qui décidera elle-même de la gestion de ces fautes. Dans tous les cas, toutes les fautes devront être détectées. Les sections suivantes précisent les hypothèses de l architecture TTA Contention des fautes et des erreurs La tolérance aux fautes dans TTP/C est basée sur la notion d isolation des fautes dans des FCR (Fault Containment Region), également appelées FCU (Fault Containment Unit). Les FCR sont des régions de contention des fautes, dont le but est de limiter l impact d une faute à une région donnée. Une FCR est formée des composants dépendants d une même ressource partagée, comme par exemple leur source d alimentation ou d horloge. Le protocole spécifie dans ses hypothèses deux types de FCR : les nœuds et les canaux de communication. Dans notre contexte, les ressources partagées pouvant être à l origine de fautes dans un FRC sont les éléments matériels, mais aussi logiciels. Par exemple, deux composants comme un contrôleur et son bus guardian ne seront réellement indépendants du point de vue temporel que s ils possèdent des sources d horloge différentes, mais aussi des services de synchronisation indépendants. La définition précise des différents FCR est un élément des hypothèses de fautes. Elle dépend de la topologie du système et de la configuration matérielle des nœuds. Une erreur provoquée par une faute dans le FCR émetteur peut se propager à d autres FCR par l intermédiaire d un message erroné. Un message erroné peut l être dans l espace des valeurs des données, ou dans celui du temps. Pour empêcher la propagation de cette erreur, des mécanismes de détection sont donc nécessaires dans les FCR récepteurs. Ce service de détection ne doit pas être situé dans le FCR déjà fautif, afin de ne pas risquer d être affecté lui-même par la faute ayant provoqué l émission du message fautif. Les FCR concernent donc les composants, mais aussi les mécanismes de tolérance aux fautes. 31

32 3.1.2 Hypothèses de fautes de TTA TTP/C est basé sur l hypothèse qu un seul composant peut être défaillant à la fois. La probabilité que des composants soient touchés par plusieurs fautes simultanément est supposée suffisamment faible pour ne pas être tolérée par l architecture. Les mécanismes de détection de fautes de TTP/C doivent pouvoir détecter une faute dans un temps suffisamment court afin que les effets de plusieurs fautes isolées ne se cumulent pas (le système doit avoir fini de traiter la première faute avant l arrivée de la deuxième). Cela se traduit par une hypothèse de fréquence d une faute pour deux rounds. A notre connaissance, les constructeurs automobiles semblent se satisfaire de ces hypothèses. Les hypothèses de fautes spécifient également le type de fautes tolérées. Les hypothèses de base fixent une tolérance aux fautes symétriques, temporelles et transitoires. Les fautes asymétriques, permanentes, de valeurs ou spatiales ne sont pas incluses dans ces hypothèses de base, mais pourront être incluses par l implémentation de techniques supplémentaires, comme l utilisation des bus guardians centraux ou de la redondance (décrits ultérieurement). Le mécanisme de CRC (cf section 3.3.1) associé à la redondance du bus permet la tolérance aux fautes de valeurs au niveau du sous-système de communication. Il n assure cependant pas la tolérance aux fautes de valeurs pouvant se produire dans les niveaux supérieurs et dans les interfaces mémoires (CNI et FTCNI). La figure 3.1 résume les types de fautes tolérées dans TTA : les types de fautes tolérées sont représentés en gras (et de couleur bleue), tandis que les types de fautes pouvant être tolérées par de la redondance ou l implémentation d une topologie en étoile avec des bus guardian centraux (cf section 3.2.2) sont en italiques (et en rose). valeur manifeste type temporelle comportement symétrique spatiale byzantine transitoire conception durée intermittente phase d introduction permanente opérationnelle FIG. 3.1 Types de fautes tolérées par TTA Les fautes considérées ici sont des fautes de transmission. En effet, tous les types de fautes se transforment en fautes de transmission ou n auront pas d effet sur les autres nœuds du cluster. Enfin, les fautes touchant les composants bus gardian et canaux de communication sont considérées comme passives (c est-à-dire que ces composants ne peuvent pas générer de trames) Garantie des hypothèses Les hypothèses de fautes précédemment énoncées sont garanties par l architecture TTA si une configuration matérielle minimale est respectée. Cette configuration inclut les conditions minimum des algorithmes, ainsi que les hypothèses de FCR. Dans TTP/C, une configuration minimum impose deux FCR : d une part les nœuds, d autre part les canaux de communication. La deuxième contrainte de la configuration minimum porte sur le nombre de composants. Tout d abord, la redondance du canal de communication est intrinsèque à l architecture. Ensuite, certains services proposés par TTP/C imposent certaines conditions : le nombre de nœuds corrects minimum du cluster est fixé à 4 par l algorithme de synchronisation 32

33 le service d intégration impose une fréquence minimum de 1 trame à CState explicite transmise par TDMA round. Les hypothèses de fautes précédemment introduites sont des hypothèses de base définies pour toutes les topologies possibles. Une extension de ces hypothèses proposée par l utilisation d une topologie en étoile avec des bus guardians centraux est décrite dans la section Notion de couverture Les hypothèses de fautes annoncées par TTP/C couvrent une partie des fautes possibles. Le taux de couverture d une architecture donnée peut cependant évoluer en fonction de la configuration choisie ([BKP01]), en y intégrant de la redondance matérielle ou logicielle. La conception d une architecture est le résultat d un équilibre entre le taux de couverture désiré et la quantité et donc le coût de la redondance ajoutée. Les sections suivantes présentent les différentes solutions proposées dans TTP/C pour assurer la tolérance aux fautes. 3.2 Solutions matérielles Le bus guardian Le bus guardian ([Tem98]) est un composant spécifique lié aux nœuds, possédant sa propre horloge et donc indépendant du contrôleur du point de vue temporel. L utilisation d un bus guardian permet de supprimer la possibilité des fautes temporelles en émission. D une part, un nœud ne pourra pas émettre en dehors de la période d émission qui lui est assignée. En effet, le bus guardian possède une source temporelle indépendante et la connaissance des instants d émission du nœud (dans le MEDL). Il permet l accès au bus durant une période limitée (fenêtre d émission) autour de ces instants. Cela permet en particulier de résoudre le problème du babbling idiot, faute caractéristique des applications distribuées. Le bus guardian dans ce cas n accordera pas les droits d émission sur le bus au nœud défaillant en dehors de son slot d émission. La figure 3.2 illustre une situation dans laquelle un nœud fautif essaie d émettre en continu, mais le bus guardian permet de garantir que le bus est protégé. De plus, un réglage approprié de la fenêtre d émission des bus guardian permet noeud fautif bus guardian signal du bus FIG. 3.2 Résolution du babbling idiot avec un bus guardian, figure tirée de [Mai02] d empêcher la transmission de la trame émise en dehors des fenêtres de réception des autres nœuds du cluster et ainsi de supprimer les fautes asymétriques liées à la désynchronisation des nœuds ([ABST03]). D autre part, si le bus guardian est fautif, la désynchronisation entre sa vision du temps global et celle du contrôleur va entraîner l absence d émission sur le bus. Puis le mécanisme de synchronisation du bus guardian va détecter la faute, et un service de traitement de cette faute sera déclenché (réinitialisation du nœud par exemple). La gestion de l accès au bus par un bus guardian indépendant permet donc d assurer un comportement fail-silent au nœud sur le plan temporel : une faute temporelle de l un ou l autre du contrôleur ou du bus guardian va entraîner l absence d émission sur le bus. 33

34 3.2.2 Topologie en étoile Dans la topologie en bus, les bus guardians sont présents sur chacun des nœuds. Le taux d indépendance de ces composants par rapport au contrôleur TTP/C du nœud est variable, en fonction du choix effectué entre le coût d implémentation et la qualité de tolérance aux fautes. Dans l architecture TTA-star, par contre, les bus guardians sont centralisés dans les concentrateurs [BKS03]. Il n en existe qu un seul par concentrateur qui gère l accès de tous les nœuds du réseau, ce qui limite les coûts introduits par les bus guardians. Il est ainsi possible d assurer l indépendance totale de ces composants sur le plan physique (alimentation) comme sur le plan temporel (oscillateur et synchronisation), et donc de définir une nouvelle FCR. La figure 2.2 montre les concepts de base d un bus guardian dans TTA-star : le réseau en étoile émule un bus de diffusion mais est en fait un ensemble de liaisons point à point entre les nœuds et chacun des bus guardian. La topologie en étoile permet une tolérance aux fautes spatiales qui touchent tous les composants dans un certain espace. Cette topologie en effet implémente deux bus guardians centraux indépendants, reliés avec chacun des nœuds par une liaison point à point, comme le montre la figure 2.2. Une faute touchant tous les éléments spatialement proches d un nœud ne pourra par conséquent perturber que ses propres liens de communication, et non tout le réseau. La topologie en bus par contre ne peut, par définition, pas être résistante à ces fautes : au niveau d un nœud, les deux bus sont spatialement proches. Enfin, les bus guardians centraux peuvent également être utilisés pour tolérer les fautes byzantines ([KBP01], [Ade02], [ABST03]). Ces fautes sont générées par des problèmes d interprétation différente au niveau des nœuds. Certains nœuds peuvent ainsi considérer une trame correcte alors que d autres la rejetteront. Un exemple de tolérance à ces fautes est celui du niveau de tension du signal transmis : s il est proche d un certain seuil, certains nœuds vont le considérer correct et d autres non. L implémentation d une fonction de régénération du signal dans le bus guardian central permet d éviter cette faute. Ainsi, l utilisation de bus guardian centraux dans la topologie en étoile entraîne une extension des hypothèses de fautes de TTA. 3.3 Solutions logicielles : les services de fiabilité Bien que la plupart des services offerts par TTA soient conçus et orientés pour la tolérance aux fautes, certains services lui sont spécifiques. En particulier, plusieurs services de détection de fautes sont disponibles, ainsi qu un service de contrôle d activité des différents niveaux de l architecture d un nœud CRC et status des trames Calcul du CRC : Lors de la réception d une trame, un calcul de CRC (polynomial dépendant de la longueur maximale des trames et de distance de Hamming 6, [Fuc95] et [TTT03]) est effectué afin de déterminer si cette trame est correcte. Comme le montre la figure 3.3 extraite des spécifications, ce calcul de CRC peut être de deux types, suivant le type de la trame : Si la trame contient un CState explicite, le CRC est calculé sur la trame entière traditionnellement, en rajoutant simplement l identificateur local du MEDL courant ; Si le CState est implicite, le CRC est calculé en ajoutant à la trame reçue une copie du CState du récepteur. La valeur de CRC incluse dans la trame ayant été calculée par l émetteur avec son propre CState, ce type de CRC permet donc également la vérification de la conformité des CStates des deux nœuds. Les 2 types de calcul du CRC incluent également l identifiant du MEDL en cours, afin que les nœuds soient assurés de fonctionner sur le même MEDL. En effet, chaque mode de fonctionnement possède son propre ordonnancement, et donc son propre MEDL. 34

35 Trame à CState explicite : ID du MEDL Type req CM CState Données applicatives CRC Trame à CState implicite : ID du MEDL Type req CM Données applicatives CState CRC valeur du CRC, envoyée dans la trame données explicites dans la trame et incluses dans le CRC données non transmises dans la trame, mais incluses dans le CRC FIG. 3.3 Calcul du CRC, figure tirée des spécifications de TTP/C [TTT03] Status des trames : A l instant de réception d une trame, le contrôleur vérifie l état de cette trame, que nous appellerons status pour ne pas confondre avec l état du contrôleur. Ce calcul du status s effectue dans la phase PRP du slot : S il n y a pas de trafic détecté durant la phase TP, le status de la trame est nul. Si le signal est reçu en dehors de la fenêtre de réception, s il y a une erreur de codage ou si le signal reçu n a pas la structure d une trame : le status est invalide. Ces deux status nul et invalide entraînent le rejet de la trame. Lorsqu une trame valide est détectée, un calcul de CRC est effectué afin de déterminer si la trame est correcte. Ce calcul de CRC peut se décomposer en plusieurs tests, utilisés par l algorithme d acquittement implicite expliqué ci-dessous. Une erreur de l un de ces tests de CRC détermine un status incorrect. De plus, une trame ayant passé les algorithmes de CRC mais contenant une requête de changement de mode non valide ne sera pas correcte : status other error. Enfin, une trame correcte peut avoir deux status différents : correct ou tentative, suivant dans quelle phase d acquittement le nœud récepteur se trouve. Ces trames sont correctes du point de vue applicatif : les données reçues sont retransmises au niveau supérieur par l intermédiaire du CNI Membership et acquittement Membership Le membership est une vision de tous les nœuds présents et actifs du système. Il est représenté dans TTA ([BP00], [Pfe00]) par un vecteur de taille N, N étant le nombre de nœuds du système. Chacun des bits de ce vecteur représente l état, actif ou non, du nœud qui lui est associé, c est-à-dire son membership. Le service de membership permet de garantir la validité de ce vecteur, avec une latence réduite. Le bit de membership d un nœud est modifié par deux mécanismes : à chaque réception d une trame, les nœuds récepteurs vérifient l activité de l émetteur en fonction de l état de la trame qu ils en reçoivent. Ils mettent alors à jour le bit de membership de ce nœud émetteur. Si la trame reçue n est pas correcte, les nœuds considèrent l émetteur comme non actif 35

36 et mettent son bit de membership à faux. lors de l algorithme d acquittement, un nœud venant d émettre tente de s acquitter en fonction des trames qu il reçoit de ses successeurs (nœuds ayant émis juste après lui). Il modifiera alors son propre bit de membership, reflet de son état dans le système. L algorithme d acquittement est décrit dans la section suivante. Acquittement L acquittement dans TTP/C est implicite, en fonction de la bonne réception des trames émises par les successeurs du nœud désirant s acquitter. Il est basé sur le service de membership du protocole : un nœud ne recevant pas une trame exclut l émetteur de son membership, et deux nœuds ne possédant pas le même vecteur de membership ne peuvent plus communiquer. La figure 3.4 montre un exemple d acquittement du nœud N1 : émission du nœud N1 ; bonne réception de tous les nœuds : les memberships restent identiques ; émission du nœud N2 ; bonne réception par tous les nœuds, y compris par N1, ce qui lui permet de s acquitter. réception OK réception OK => acquittement N1 N2 N1 N2 N3 N3 N4 N3 réception OK réception OK réception OK réception OK FIG. 3.4 Acquittement du nœud N1 Le service d acquittement permet bien sûr la détection des erreurs d émission. Il permet en particulier la détection d une perte de membership, illustrée dans la figure 3.5 pour le nœud N1 : émission du nœud N1 ; mauvaise réception de tous les nœuds qui excluent N1 de leur membership ; le nœud N1, qui ne sait pas encore que son émission était fautive, a donc un membership différent de tous les autres nœuds et ne pourra pas recevoir leurs trames ; émission du nœud N2 ; bonne réception des nœuds N3 et N4, mais mauvaise réception de N1 (le vecteur de membership appartient au CState, il entre donc dans le calcul du CRC ; ici ce calcul est donc faux et la trame est rejetée) ; N1 va attendre une deuxième trame pour décider de son acquittement ; émission de N3 ; bonne réception des nœuds N2 et N4, mais mauvaise réception de N1 : N1 se rend compte qu il est fautif et détecte une perte de membership ; Ces services de membership et d acquittement seront détaillés dans la partie 4, pour l étude de la validation de la borne temporelle de la détection d une perte de membership. Détection d une clique ou d un communication blackout L algorithme d acquittement est complété par deux mécanismes de détection de fautes : détection des cliques [BP00] et détection des communication blackout. Une clique est une séparation du cluster en 36

37 réception KO => exclusion de N1 réception KO réception KO => pas acquitté => perte de membership réception OK N1 N2 N1 N2 N1 N2 N4 N3 N4 N3 N4 N3 réception KO => exclusion de N1 réception KO => exclusion de N1 réception OK réception OK réception OK FIG. 3.5 Perte de membership du nœud N1 différents ensembles de nœuds, dont la vision globale du système est la même dans chacun des groupes, mais dont les visions globales de chaque groupe sont différentes. Dans ce cas, les nœuds des différents groupes n ont pas le même CState et ne peuvent plus communiquer. Le communication blackout est l absence totale de transmission de trames sur le bus, pendant une certaine durée (détection au bout de un round dans TTA). Ces deux mécanismes permettent de détecter les fautes non détectables par le seul algorithme d acquittement. Ces services supplémentaires sont étudiés et validés en annexe de cette thèse. Ces mécanismes de détection utilisent la valeur de deux compteurs : l un pour le nombre de trames correctes reçues dans un round, et l autre pour le nombre de trames non correctes reçues. Une fois par round, dans son PSP, un nœud vérifie les deux conditions de détection d une erreur de clique (c est-àdire que le nombre de trames correctes reçues est supérieur au nombre de trames incorrectes) ou d un communication blackout (c est-à-dire qu au moins une trame a été reçue pendant le dernier round) sont remplies Signe de vie de l hôte et du contrôleur Le niveau communication et le niveau hôte ne communiquent pas directement dans l architecture TTA. La vérification de l activité de ces éléments s effectue donc par un mécanisme particulier, par l intermédiaire d un signe de vie. L hôte utilise un signe de vie spécifique, dépendant de l implémentation. Régulièrement (dans son PSP), le contrôleur vérifie l activité du niveau hôte, et donc la validité des données présentes dans le CNI. De son côté, le contrôleur met régulièrement à jour des champs du CState, ce qui permet le contrôle de son activité par l hôte. 3.4 La redondance La redondance d application est une solution qui permet l extension des hypothèses de fautes : tolérance aux fautes de valeurs des données, tolérance à plusieurs fautes simultanées, etc Redondance d application Les mécanismes précédents permettent de garantir la tolérance aux fautes de transmission et aux fautes temporelles. Cependant, les nœuds fautifs peuvent tout de même produire des données erronées, il est donc nécessaire de masquer les effets des fautes dans le domaine des valeurs des données applicatives. Cet aspect de la tolérance aux fautes est effectué grâce à de la redondance d application qui permet de fournir plusieurs données identiques mais présentant des modes de fautes différents, c est-à-dire ne pouvant pas être touchés par une même faute. 37

38 L implémentation de la redondance d application utilise la notion de FTU (Fault Tolerant Unit) ([BK00]). Un FTU est un ensemble de SRU dupliqués replica determinist, c est-à-dire exécutant une même application et produisant les mêmes données. Ces données redondantes peuvent donc être utilisées afin de masquer la faute de l un de ces SRU. Le nombre de SRU et la configuration d un FTU, ainsi que le type de gestion de cette redondance, dépendent du taux et du type de tolérance aux fautes désirés. Cette redondance est basée sur le principe qu un certain nombre de nœuds dupliqués sont actifs dans le FTU, soutenus éventuellement par des nœuds passifs (les nœuds ombres). FTU1 FTU2 ombre multiplexé dupliqué N N M dupliqué M réseau de communication FIG. 3.6 Types de redondance d application Il existe plusieurs types de redondance possibles [Bau01] au sein même d un FTU (figure 3.6) : La redondance active : tout d abord, les SRU peuvent être simplement répliqués (nœuds N et N, ou M et M de la figure 3.6), ce qui permet d obtenir une redondance des messages émis par les applications de ces SRU. Cette redondance des messages permet une plus grande résistance aux fautes transitoires. Le nombre de réplicas dans un même FTU peut varier selon le taux de fiabilité désiré pour l application concernée. Une configuration courante est la TMR (Triple Modular Redundancy), duplication de 3 SRU actifs, qui permet la tolérance aux fautes byzantines sans supposer de comportement fail-silent de la part des SRU ([Bau01]). La redondance passive : un autre type de redondance est l utilisation d un nœud ombre, représenté sur la figure 3.6 en arrière du nœud N. Dans ce concept, le nœud en réserve est passif, c est-à-dire qu il n émet pas de trame, il ne possède pas de slot. Il reçoit cependant tous les messages émis sur le bus et effectue les opérations nécessaires pour rester opérationnel, comme la synchronisation et le membership. Si le nœud actif tombe en panne, le nœud ombre entre dans l état actif, c est-à-dire qu il va émettre sur le bus en utilisant le slot du nœud qu il a remplacé. Une autre forme de redondance est le multiplexage, c est-à-dire qu un nœud est l ombre commune de plusieurs nœuds actifs. Par exemple sur la figure 3.6 à droite, le nœud est en réserve et pourra prendre la place soit du nœud M, soit de M, selon la panne. Il prendra alors le slot du nœud qu il remplace. Ces deux dernières techniques sont basées sur un mécanisme de reconfiguration qui permet le remplacement dynamique d un nœud par un autre. Au sein d un FTU avec un nœud ombre par exemple, ce mécanisme permet de détecter la panne d un des SRU initialement actif et d attribuer son slot au nœud ombre correspondant. 38

39 3.4.2 La couche FT layer Dans TTA, la gestion de la redondance d application est implémentée dans une couche particulière : le FT layer (Fault Tolerant Layer, [BK00], [Bau01]) qui permet la transparence de cette redondance du point de vue de l application. Cette couche accomplit deux tâches principales : l estimation de l état d activité des différents FTU par un membership spécifique, c est-à-dire la vérification des états de chacun des SRU d un FTU, et le transfert des messages entre les interfaces FT CNI et CNI (figure 2.1). La remontée des messages du CNI vers le niveau supérieur (FT CNI) implique une gestion de la redondance des messages liée à la redondance de l application, par une mise en place d un mécanisme de vote adapté à la topologie du FTU associé [Bau01]. FTU Tache 1 Tache 1 Tache 2 Application m1 m1 m1 FT layer m1 m1 TTP/C Bus 1 m1 m1 Bus 2 m1 m1 Slot 1 Slot 1 FIG. 3.7 Gestion de la redondance des messages Un exemple est donné figure 3.7 : soit Tâche2 un processus d application devant recevoir un message m1 d une autre application (Tâche1). Si Tâche1 est dupliquée dans deux SRU différents alors quatre instances du message m1 vont être émises. Tout d abord le premier réplica de Tache1 va émettre m1 pendant son slot d émission sur les deux bus. Puis le deuxième réplica fera de même plus tard, pendant son slot. La gestion de la redondance de messages engendrée par la réplication des bus de communication est intégrée au protocole TTP/C. Le contrôleur sélectionne un des messages reçu dans une trame correcte et le remonte à la couche FT layer via le CNI. La Tâche2 va toutefois recevoir deux instances du message m1 au lieu d une seule. La couche FT layer va alors permettre d effectuer la sélection entre ces messages dupliqués et ne déposer dans le FT CNI qu un seul message m Conclusion Cette section vient de décrire les différents mécanismes implémentés dans TTA pour la tolérance aux fautes. Ces mécanismes peuvent être regroupés suivant deux principes de bases de la tolérance aux fautes dans TTA : l isolation des fautes et le masquage des fautes. L isolation des fautes permet tout d abord d éviter qu un nœud fautif perturbe le reste du système. Cette opération est effectuée au niveau architec- 39

40 tural par la garantie des FCR et l implémentation des bus guardians. L isolation des fautes ne concerne cependant pas les fautes du domaine des valeurs : un SRU peut toujours transmettre une donnée erronée dans une trame considérée comme correcte. TTA implémente donc la redondance afin de masquer ces fautes de valeurs. 40

41 Chapitre 4 Contexte : conclusion Ce chapitre a introduit le contexte de notre étude : les systèmes distribués temps réel critiques et tolérants aux fautes pour l automobile. Ces systèmes sont constitués de nombreux mécanismes logiciels et matériels dédiés à la tolérance aux fautes et à la gestion du temps réel. Dans ce contexte, la conception des systèmes doit être validée par des techniques permettant la garantie de leur fiabilité. En effet, les spécifications fournissent une description des différents services, et donc du comportement de l architecture. Elles précisent également les hypothèses de fautes tolérées par l architecture et les bornes temporelles de certains services. Cependant, la conception des spécifications repose sur une analyse théorique des besoins et sur une interprétation humaine de ces besoins. A ce stade, aucune technique ne garantit réellement que les services décrits dans les spécifications répondent réellement à ces besoins, et que l architecture est réellement tolérante sous les hypothèses données. C est en particulier le cas pour les architectures distribuées, pour lesquelles certains services sont conçus de façon locale et doivent être testés dans le cadre d une intégration au système global. Il est donc nécessaire d utiliser des techniques de validation qui permettent la vérification des spécifications et assurent la fiabilité du comportement du système. La prise en compte des contraintes spécifiques du contexte entraîne en particulier une validation temporelle en présence de fautes. Le chapitre suivant va introduire le processus de validation, les différentes techniques disponibles, et les résultats existants pour l architecture TTA. 41

42 42

43 Deuxième partie Validation : Etat de l art 43

44 44

45 Chapitre 1 Validation d un système La partie 1 précédente a introduit le contexte des architectures automobiles temps réel critiques tolérantes aux fautes. Ces systèmes sont conçus pour résister à un environnement exposé aux fautes et doivent continuer dans cet environnement à fournir les services pour lesquels ils sont conçus. Cependant, le développement d une telle architecture devra être soumis à des étapes de validation afin de fournir la fiabilité nécessaire à ces systèmes critiques. Cette partie 2 propose une étude des différentes méthodes de validation existantes au sein du processus de développement d un système, qu elles se situent au début (validation a priori) ou à la fin (validation a posteriori) du cycle de développement. Puis l état de l art des méthodes de validation et des résultats obtenus pour la validation temporelle de TTA est décrit. Il montre qu il existe encore des manques dans ce domaine pour la validation de l architecture globale et de l interaction de plusieurs services. 1.1 Validation dans le processus de développement d un système Le processus de développement d un système est représenté par le classique modèle en V (figure 1.1). Il peut être décomposé en trois parties : la phase d analyse, la phase de réalisation et la phase de validation. La phase d analyse du système entraîne la conception des architectures fonctionnelle et opérationnelle à partir d une analyse des besoins du système et de la spécification du cahier des charges. La phase suivante est la réalisation physique du système, basée sur l architecture opérationnelle définie dans la phase d analyse. Les différents composants du système sont conçus et programmés de façon indépendante, puis intégrés pour la conception du système global. Cette phase de réalisation du système comprend souvent une première étape de conception d un prototype, avant l étape de conception finale. Enfin la dernière phase, celle de validation, constitue la dernière étape du cycle. Elle est traditionnellement effectuée par des tests sur les composants indépendants, puis sur le système global après l intégration. Cette phase fait partie intégrante du processus de garantie de la sûreté de fonctionnement. Elle permet d une part d éliminer les erreurs de conception ou de réalisation et d autre part de valider l architecture opérationnelle, la tolérance aux fautes et les hypothèses de fautes du système final. Dans le contexte de notre étude, cette phase de validation est capitale : d une part les systèmes cibles sont exigeants du point de vue de la fiabilité, et d autre part, le contexte spécifique industriel, en particulier dans le domaine de l automobile, rajoute des contraintes fortes d optimisation du coût et de la durée du processus de développement. Or la méthode traditionnelle du test, décrite plus en détail dans la section 1.2.2, comporte plusieurs inconvénients dans ce contexte tant sur le plan des contraintes de fiabilité que sur celui du coût. En particulier, la phase de test s effectue à un instant tardif du processus, c est-à-dire après la phase de réalisation, sur un prototype du système ou sur le système lui-même. Ainsi, la détection d une erreur de conception à ce stade entraîne un retour en arrière sur toutes les étapes déjà effectuées, ce qui est souvent long et coûteux. De plus, la technique du test ne permet souvent pas de 45

46 détecter un taux d erreurs suffisant dans le cadre de systèmes critiques. Pour remédier à ces problèmes et améliorer le processus de développement, plusieurs autres méthodes ont été étudiées et souvent appliquées pour la validation des systèmes, à différents stades du processus. L application de ces nouvelles méthodes peut permettre la détection d erreurs à des stades moins avancés, mais aussi offre des possibilités nouvelles en introduisant notamment la notion de vérification formelle ([Rus95]). La suite de cette section va introduire les principales méthodes de validation disponibles ([Kat01], [Möl02]), en essayant d en extraire les caractéristiques dans le contexte de cette étude, c est-à-dire les applications critiques dans le domaine de l automobile. Cahier des charges Exploitation expression formelle des spécifications Spécification de l architecture fonctionnelle peer reviewing, test et injection de fautes du système global Intégration * model checking * preuve de théorème Spécification de l architecture opérationnelle peer reviewing et test de composants * simulation et test * injection de fautes Réalisation FIG. 1.1 Validation dans le cycle de développement, inspirée de [Cas00] 1.2 Validation a posteriori Les phases de validation dites a posteriori sont, comme le test, celles qui sont effectuées après la phase de réalisation physique du système. Elles sont en général appliquées directement sur le système, ou sur des prototypes de celui-ci. Trois méthodes sont principalement utilisées dans les milieux industriels : le peer reviewing, le test et l injection de fautes. Ces méthodes sont intégrées depuis longtemps aux processus industriels de développement des systèmes. Elles profitent donc d une grande facilité de mise en oeuvre, et disposent souvent de l appui d outils développés dans ce but au sein des entreprises. Les méthodes a posteriori permettent la détection des erreurs introduites lors de la phase de réalisation et de programmation qui représentent presque 50% des erreurs ([Kat01]). 46

47 1.2.1 Peer reviewing Le peer reviewing, que l on pourrait traduire par examen minutieux, est une vérification de l implémentation du système par des hommes, au moyen d une analyse statique minutieuse. Cette technique, bien que souvent assez efficace, nécessite beaucoup de temps et d investissements. Elle ne concerne de plus que la partie logicielle du système, ce qui exclut la détection de certaines erreurs liées au matériel ou à la distribution de l architecture fonctionnelle Test Une méthode complémentaire est le test qui exécute le système et peut ainsi l analyser dynamiquement. La vérification s effectue en stimulant l exécution par des scénarios de valeurs d entrées spécifiques, et en observant le comportement du système et la valeur de ses sorties. La comparaison du comportement observé avec celui désiré permet de déduire si le système est correct ou non. Les scénarios de tests sont définis pendant la phase d analyse du système, parallèlement au cahier des charges, de façon à couvrir le comportement désiré. Cependant, un inconvénient majeur du test est l impossibilité de tester de manière exhaustive tous les comportements possibles du système. Il faudrait pour cela envisager tous les scénarios d entrée provoquant tous les comportements du système, ce qui n est pas réalisable. Ainsi, les méthodes de test permettent la détection de certaines erreurs, mais ne permettent pas d affirmer qu un système est entièrement correct Injection de fautes Le cas spécifique de la validation des systèmes tolérants aux fautes implique une méthode de test dite d injection de fautes, dans laquelle le système est soumis à l occurrence de nombreuses fautes. L injection de fautes est utilisée pour l élimination des erreurs de conception et de réalisation, ainsi que pour la validation de la fiabilité d un système en présence de fautes. Les techniques d injection de fautes [HTI97] sont variables suivant le type de fautes injectées, et souvent complémentaires. Elles se différencient par leur accessibilité aux divers composants du système cible pour l injection de fautes, par la contrôlabilité de cette injection (précision de l instant et du lieu) et la capacité d observation du comportement du système. Elles se répartissent en deux types ([Ade03b], [Hex99]) : les injections de fautes matérielles, qui génèrent des perturbations réelles comme par exemple une interférence électromagnétique, et les injections de fautes logicielles, qui impliquent l intégration d un logiciel spécifique dédié à la simulation de fautes. Le choix entre les différentes méthodes est lié aux caractéristiques des systèmes étudiés et au but de l injection de fautes. Une campagne de validation par injection de fautes associe généralement plusieurs techniques qui sont complémentaires ([STA02], [KFA 95]). L injection de fautes matérielle est effectuée sur une émulation ou sur une implémentation du système réel. Elle permet la génération de fautes reflétant les conditions réelles, et donc la validation des hypothèses de fautes et des mécanismes de tolérance aux fautes d un système. Elle est cependant plus coûteuse et moins facile à manipuler (scénarios de fautes non reproductibles par exemple) que l injection logicielle. Cette dernière peut être utilisée sur une implémentation du système final ou sur un prototype, mais aussi plus tôt dans le cycle de développement sur un modèle de simulation du système. L injection de fautes logicielle consiste en l exécution d une tâche logicielle spécifique, intégrée au code applicatif ou exécutée par le contrôleur. Cependant, elle peut impliquer une modification du comportement temporel du système lié au temps nécessaire pour l exécution de cette tâche supplémentaire. Ce phénomène, connu sous le nom de probe effect, constitue un inconvénient majeur qu il faudra maîtriser dans le contexte de systèmes temps réel. Elle ne peut de plus générer que des fautes sur des éléments accessibles par logiciel. 47

48 1.2.4 a posteriori : conclusion Les méthodes a posteriori décrites ci-dessus sont intrinsèquement limitées dans le contexte de notre étude : elles ne permettent pas un taux de détection suffisant et le coût introduit par cette phase de validation est important. En particulier, la détection d erreurs à un stade tardif du processus de développement entraîne forcément un retour en arrière sur certaines étapes de la phase de réalisation, et même jusqu à la phase de conception si l erreur détectée est une erreur introduite pendant la phase d analyse et entraîne une modification des choix de conception. Ce retour en arrière est inévitablement long et coûteux, le temps et le matériel utilisé pour le développement du système (ou d un prototype du système) étant devenus inutiles. Il y a donc un grand intérêt à développer d une part des techniques de validation formelles, et d autre part des techniques effectuées a priori, c est-à-dire avant la phase de réalisation du système. En effet, l introduction de la notion formelle permet une vérification plus précise de la fiabilité des systèmes [Rus95], tandis que l exécution de la vérification à un stade moins avancé du cycle de développement, et par des méthodes souvent moins onéreuses, permet une réduction conséquente des coûts et de la durée de la phase de validation. 1.3 Validation a priori Les méthodes de validation a priori sont appliquées sur les architectures fonctionnelles ou opérationnelles (cf figure 1.1). Elles effectuent la validation des spécifications, de la conception de l architecture fonctionnelle et de sa distribution sur l architecture matérielle. Elles peuvent par exemple valider les contraintes de tolérance aux fautes réparties sur l architecture opérationnelle (cf. section 1.3 de la partie 1). Les méthodes effectuées a priori sont des méthodes formelles, c est-à-dire dédiées à la validation de systèmes en se basant sur des notions mathématiques. Il existe deux types de méthodes formelles : les approches déductives et les approches basées sur un modèle formel du système. La validation s effectue en général par la vérification de propriétés sur un modèle du système Preuve La preuve permet de déterminer qu une propriétés d un système est correct par l utilisation de concepts purement mathématiques. Cette propriété est la conséquences logiques d axiomes ou d hypothèses dont la vérité est admise [LUS04]. La preuve peut être informelle, c est-à-dire que la démonstration de la propriété est effectuée en langage naturel et acceptée par les experts de la spécialité. Ce type de preuve s oppose aux preuves formelles qui peuvent être vérifiées automatiquement par des outils. Il est alors nécessaire pour cela de formaliser complétement le problème de vérification. Le système et les propriétés à vérifier sont alors spécifiés en formules logiques, puis leur vérification est effectuée de façon systématique à l aide d outils implémentant des théories mathématiques. Une méthode permet la vérification de la propriété en se basant sur des axiomes mathématiques et des hypothèses génériques qui devront être satisfaites par le système pour que la preuve soit valide. La formule à prouver est déduite de ces axiomes de bases par différentes étapes de raisonnement mathématique. Une version différente est la vérification de preuves, qui permet la vérification automatique d une preuve proposée par un utilisateur. Ces deux méthodes permettent de prouver de façon certaine la validité du système ou de l algorithme étudié, en vérifiant par exemple des propriétés d invariance ou de vivacité. La construction de la preuve nécessite cependant une large intervention humaine pour l implémentation du système et des théories de base et pour la définition d une stratégie d application des axiomes, et exige donc une grande expertise de l utilisateur. Cette caractéristique entraîne une limitation du domaine d application de ces méthodes, notamment dans les milieux industriels non familiarisés avec les théories mathématiques utilisées. De plus, le système doit pouvoir être exprimé dans une théorie mathématique 48

49 précise, ce qui n est pas toujours le cas pour les systèmes complexes ou réactifs, et la preuve de certains systèmes (systèmes distribués par exemple) est souvent longue et difficile, voire impossible à l heure actuelle Méthodes basées sur des modèles formels Le second type de méthodes a priori est basé sur la description du système en un modèle formel. Cette première étape de formalisation permet déjà de supprimer certaines erreurs dûes aux ambiguïtés et aux manques des spécifications, souvent exprimées en langage naturel, erreurs d autant plus probables que les systèmes étudiés sont complexes. Ces modèles sont associés à des techniques de vérification automatique, soit par une exploration exhaustive de tous les chemins d exécution par model checking, soit par une exploration partielle des chemins d exécution par simulation Simulation La simulation est un outil indispensable à la conception qui permet une première étude du comportement du système et aide à la détection des erreurs de conception les plus grosses. Cette analyse s effectue par l exécution d une simulation du modèle sur des scénarios de tests ou de façon aléatoire, et par l étude de l exécution pas à pas des scénarios fautifs. Cependant la simulation aléatoire, bien que très utile dans de nombreux processus de conception, ne fournit pas une couverture exhaustive de tous les comportements possibles. Une alternative proche est l application de la méthode du test sur un modèle. Cette technique est applicable à des systèmes dont la modélisation n est pas complète, comme par exemple la représentation d un composant dont la structure interne est inconnue. Les tests s effectuent sur des scénarios de valeurs représentant le comportement de la partie du modèle manquant. L application de tests sur un modèle, en plus de la dimension formelle de la modélisation, offre la possibilité de générer les jeux de tests automatiquement. Comme la simulation, le test de modèle est cependant limité par l impossibilité d être exhaustif pour les scénarios. Elle n est donc pas suffisante dans le cadre de systèmes à fortes contraintes. Il est alors nécessaire de valider de façon formelle le respect de ces contraintes en analysant de façon exhaustive tous les chemins d exécution possibles Model checking Une autre méthode de validation basée sur l analyse d un modèle du système est le model checking ([Mer01], [SBB 99]). Cette méthode examine tous les scénarios et comportements possibles du modèle d une façon systématique et exhaustive. Sur cette base, le model checking permet la validation formelle du système par la vérification d un certain nombre de propriétés. Ces propriétés sont établies lors de la phase d analyse, parallèlement à l établissement du cahier des charges, et définissent le comportement désiré du système. La vérification de ces propriétés, ainsi que le parcours des états du système, sont effectués par des méthodes d analyse automatique du modèle implémenté dans des outils spécifiques : les model checker. Si un état du modèle ne respecte pas une des propriétés vérifiées, le model checker peut générer une trace du chemin d exécution ayant mené à cet état. L analyse de cette trace (souvent avec un simulateur) permet ainsi une détection aisée de l erreur. Le model checking permet donc une vérification formelle exhaustive des propriétés sur le modèle du système. Le model checking peut également être utilisé comme appui dans la validation de certains algorithmes par preuve. Pour résoudre le problème de complexité des preuves de certains systèmes, une solution peut être l association de ces deux techniques dans une méthodologie où la preuve est utilisée pour abstraire certains éléments du système afin d obtenir un modèle simplifié du système pouvant être vérifié par model checking ([HS96]). L utilisation de la technique de preuve pour créer un modèle abstrait permet de garantir la validité des abstractions. L association de ces deux méthodes peut donc permettre 49

50 la vérification de systèmes complexes, elle conserve cependant les inconvénients de la preuve sur l expertise et l investissement de l utilisateur. 1.4 Résumé - Comparaison des méthodes Les tableaux 1.1 et 1.2 proposent un résumé des caractéristiques des différentes méthodes de validation présentées dans ce chapitre. Ces caractéristiques sont classées en Avantages et Inconvénients en prenant en considération le contexte de notre étude : les systèmes embarqués temps réel distribués critiques. Une attention particulière a donc été apportée aux deux facteurs les plus importants dans ce contexte : le coût et la fiabilité de la validation. Ces méthodes constituent un progrès indiscutable dans la phase de validation du processus de développement d un système, tant sur le plan de l amélioration des possibilités de détection des erreurs que sur le plan de la réduction du coût ou de la durée de la phase de validation. Les méthodes formelles impliquent cependant une étape supplémentaire dans le processus global de développement. Car même si elles permettent rapidement la détection des erreurs de conception, elles ne remplacent pas la phase de test qui reste indispensable pour la détection des erreurs introduites durant la phase de réalisation physique du système. En effet, elles permettent la vérification formelle d un modèle du système, et non du système lui-même. De plus, la validation formelle est un concept relativement nouveau dans le milieu industriel, et son introduction implique un apprentissage de nouvelles techniques, ainsi que le développement d outils adaptés aux systèmes caractéristiques de l industrie. Ces méthodes de validation sont donc des éléments complémentaires aux méthodes utilisées traditionnellement pour la validation dans le processus de développement d un système industriel. La surcharge en temps et en coût introduit pendant la phase de conception sera largement compensée par les gains liés à une meilleure gestion de la détection des erreurs (plus tôt et en plus grand nombre). C est dans ce cadre que se situe le travail de cette thèse, afin de définir une méthodologie globale de validation adaptée aux architectures embarquées communicantes et tolérantes aux fautes telle que l architecture TTA. Une première partie de notre travail a donc consisté en l étude de l état de l art de la validation de cette architecture spécifique. 50

51 Méthode Avantages peer reviewing test injection de fautes matérielle injection de fautes logicielle a posteriori injection de fautes logicielle a priori preuve simulation assez efficace ; détection des erreurs des deux phases (conception et réalisation) outils performants ; détection des erreurs des deux phases (conception et réalisation) scénarios de fautes réelles ; détection des erreurs des deux phases (conception et réalisation) détection des erreurs des deux phases (conception et réalisation) ; précision des fautes injectées détection tôt ; précision des fautes injectées ; faible coût détection tôt ; validation = preuve ; espace d états infini ; faible coût détection tôt ; modélisation formelle ; faible coût test sur modèle détection tôt ; modélisation formelle ; génération automatique des tests ; faible coût model checking détection tôt ; modélisation formelle ; automatique outils ; précision formelle de la validation ; exhaustive pour les propriétés vérifiées ; faible coût TAB. 1.1 Avantages des méthodes de validation dans le contexte des systèmes temps réel critiques 51

52 Méthode Inconvénients peer reviewing détection tardive ; implication importante (humaine) en temps et en coût ; analyse statique : pas tous les types d erreurs test détection tardive ; coût du matériel pour les prototypes ; non exhaustif : tous les comportements possibles ne sont pas testés ; durée importante de la validation injection de fautes matérielle injection de fautes logicielle a posteriori injection de fautes logicielle a priori preuve simulation test sur modèle model checking détection tardive ; matériel d injection coûteux ; scénarios de fautes non reproductibles ; non exhaustif détection tardive ; limitation du type de fautes injectées ; surcharge logicielle ; non exhaustif limitation du type de fautes injectées ; validation sur un modèle ; surcharge logicielle ; non exhaustif le système doit être exprimable en théorie mathématique ; besoin d un expert de la méthode utilisée pour la validation ; pas de détection des erreurs de réalisation non exhaustif : les scénarios ne couvrent pas tous les comportements possibles ; validation d un modèle et non du système lui-même ; pas de détection des erreurs de réalisation non exhaustif : tous les comportements ne sont pas testés ; validation d un modèle ; pas de détection des erreurs de réalisation espace d états finis (pas de données à valeurs aléatoires) ; souvent explosion combinatoire de l espace des états ; validation d un modèle et non du système ; pas de détection des erreurs de réalisation TAB. 1.2 Inconvénients des méthodes de validation dans le contexte des systèmes temps réel critiques 52

53 Chapitre 2 Validation temporelle pour TTA : état de l art Le chapitre précédent a présenté les différentes méthodes de validation d un système. Les principes de base de ces méthodes ont été décrits, et une analyse de leurs avantages et de leurs inconvénients dans le contexte des architectures temps réel critiques pour l automobile est résumée dans les tableaux 1.1 et 1.2. Ce chapitre introduit maintenant l état de l art des différentes techniques utilisées pour la validation de l architecture TTA et les résultats obtenus. Cela montre qu il existe un manque dans l utilisation de techniques formelles permettant la validation de l architecture complète et de ses bornes temporelles, que pourrait combler le model checking. 2.1 Injection de fautes - projet FIT Expérimentations L architecture TTA a été l objet d une campagne approfondie de tests avec injection de fautes, dans le cadre du projet FIT - Fault Injection for TTA. Ce projet a réuni les travaux de six universités et trois industriels qui, sur trois ans ( ), ont appliqué plusieurs techniques d injection de fautes matérielle ou logicielle à TTA, comme résumé dans la figure 2.1. Ces fautes ont été injectées sur un prototype matériel de l architecture (maquette TTTech 1 ), ainsi que sur un modèle de simulation développée en langage CSim (langage proche du langage C) [Gil01]. Une partie de ce projet concerne également la validation de l architecture matérielle sur un modèle VHDL (Very high speed integrated circuit Hardware Description Language), mais ce type de validation (matérielle et non temps réel) ne sera pas abordé dans cette thèse. Les détails du projet FIT peuvent être trouvés sur le site officiel 2, ainsi que dans les différentes publications qui y sont associées (entre autres les thèses de doctorat [Hex99], [Ade03b]) Résultats Ces expérimentations d injection de fautes ont conduit à la détection de plusieurs erreurs ou ambiguïtés dans les spécifications de TTA, mais aussi à la vérification de l implémentation des prototypes et modèles utilisés ([AHGH02] par exemple). L injection de fautes multiples a permis de vérifier le comportement du système et l efficacité des mécanismes de tolérance aux fautes en présence de fautes. Même si la méthode de validation par test ne peut pas, par nature, être exhaustive, la couverture des fautes testées est large grâce à l utilisation d un grand nombre de techniques complémentaires ([Ade03b], [HRH02], [Ade02], [Ade03a]). Ce projet met cependant en évidence un inconvénient majeur de l injection de FIT - Fault Injection for TTA, 53

54 Techniques d injection de fautes sur un modèle (simulation) sur un prototype (maquette TTTech) modèle VHDL modèle CSim injection de fautes matérielle (PFI) injection de fautes logicielle (SWIFI) Injection de fautes au niveau des pins Radiation d ions lourds Injection de fautes dans le microcode du protocole FIG. 2.1 Techniques d injection de fautes du projet FIT fautes, lié à la détection tardive des erreurs de conception. Ainsi, les erreurs détectées dans ce projet ont conduit à la modification des spécifications du protocole, ce qui a rendu obsolète la première version du prototype implémenté. En particulier, une nouvelle topologie en étoile plus fiable a été développée. Il a donc été nécessaire de concevoir un nouveau prototype, et de renouveler la campagne d injection de fautes pour valider le nouveau système [ABST03], ce qui a entraîné une surcharge conséquente en temps et en coût du processus de développement. 2.2 Simulation Parallèlement au projet FIT, qui se concentrait sur la validation des mécanismes de tolérance aux fautes de TTA, une approche plus temporelle a été étudiée par le biais de la simulation de l architecture [Pal00]. Un environnement de validation permet la vérification du pire temps d exécution de certains services de détection d erreurs sur un modèle de simulation de l architecture. Cet environnement intègre des scénarios d injection de fautes au sein de la simulation. Cette approche a l avantage d être flexible, à la fois dans la possibilité d implémentation des détails de l architecture (le niveau applicatif par exemple), et dans le retour possible sur les scénarios d erreurs. Cependant, une validation par simulation correspond à un test non exhaustif de tous les comportements possibles du système. Ainsi, les temps d exécution vérifiés ne seront pas des bornes temporelles au sens du pire temps d exécution. De plus, l approche logicielle de l injection de fautes s accompagne du problème du probe effect, et l approche discrète du temps dans le processus de simulation ne permet pas une vision aussi précise que les approches à temps continu. 2.3 Validation formelle par la preuve Un effort particulier a été apporté à l architecture TTA par une partie de la communauté de validation formelle par utilisation de la preuve. Outre l intérêt de la validation du système lui-même, TTA offre, de par ses caractéristiques, plusieurs challenges intéressants dans ce domaine de la validation. En effet, l application de la validation par la preuve dans le contexte de systèmes distribués et de protocole de communication est assez récente. Dans le cadre de la validation de TTA, les différents algorithmes ont été tout d abord considérés indépendamment, et une preuve formelle a été apportée pour certains d entre-eux ([Rus02]). Cependant, l architecture TTA est un ensemble d algorithmes interagissants afin de fournir les 54

55 différents services de communication et de tolérance aux fautes. L interaction de ces algorithmes est donc un élément à prendre en considération dans le processus de vérification : les algorithmes ne peuvent pas être considérés comme validés si leur validation n a pas intégré cette dépendance Preuves d algorithmes indépendants Deux utilisations différentes de la technique de preuve ont été appliquées à la validation de TTA : d une part un système complet de validation par preuve, le système PVS Prototype Verification System, et d autre part une utilisation de la théorie des graphes. Les algorithmes ici sont validés indépendamment de l architecture globale, c est-à-dire que la validité des autres algorithmes de TTA, en particulier ceux garantissant la vision globale du temps ou du membership, est une hypothèse de base de la preuve. PVS (Prototype Verification System) L outil PVS [ORSvH95] est un système de vérification pour la spécification et la construction de preuves. Son moteur de construction de preuves (theorem prover) permet l application automatique d un grand nombre de techniques décidables (calcul propositionnel ou arithmétique linéaire par exemple), ainsi que d heuristiques de techniques comme l induction et l instantiation. Ces techniques permettent la vérification ou la réfutation automatique d un certain nombre de théorèmes et de propriétés du système. La construction de la preuve complète nécessite cependant une large intervention humaine, pour l implémentation du système et des théories de base, et pour la définition d une stratégie de construction. Une illustration simple de l utilisation du système PVS pour la vérification formelle d un algorithme de TTA (vérification de la fenêtre temporelle d émission) est donnée dans [Rus01b]. PVS a également été utilisé pour la vérification de plusieurs autres algorithmes de TTA [Rus02] : validation de la validité des algorithmes de synchronisation et de membership, validation de leur interaction et validation de l algorithme de gestion de l accès au bus par les bus guardian ([Pfe03, PvH01, Pfe00, PSvH99, Rus01b]). Théorie des graphes Une autre technique de preuve a été appliquée dans [BM02] pour la validation de l algorithme de détection de cliques. En plus de la convergence de l algorithme, un élément supplémentaire est vérifié : la validité du système est définie comme une convergence de l algorithme en un temps borné. La preuve utilise la théorie des graphes : le système est représenté par un graphe, dont les sommets sont les nœuds du système et les arcs entre deux sommets représentent l accord de membership entre ces nœuds. Une clique, qui représente un ensemble de nœuds d accord entre-eux sur le vecteur de membership, est alors un sousgraphe complet du graphe global. L évolution temporelle permettant la vérification de la borne maximale de validité est intégrée à la représentation du système par une approche discrète du temps : le temps est considéré comme une succession de slots. La preuve est effectuée par l application d axiomes de la théorie des graphes, l utilisateur doit donc être expert dans cette théorie mathématique. Une approche automatique est ensuite proposée, basée sur une abstraction du système conduisant à sa modélisation en automates, et à la modélisation des propriétés à vérifier en logique. Les propriétés sont ensuite vérifiées automatiquement par model checking avec des outils spécifiques. L abstraction proposée du système permet théoriquement l extension de la preuve au cas plus général d un nombre arbitraire de nœuds et de fautes. L outil de vérification est cependant très rapidement exposé au problème de l explosion combinatoire (pour 2 fautes). De plus, cette méthodologie n est applicable qu aux algorithmes exprimables par la théorie des graphes, ce qui n est pas le cas de tous les services du protocole TTP/C Intéractions des algorithmes La section précédente résume les preuves existantes des algorithmes de TTA considérés de façon indépendante, en se basant sur l hypothèse de validité des autres algorithmes. Typiquement, la validité 55

56 de la tolérance aux fautes de l algorithme de synchronisation de TTA est basée sur l hypothèse que l algorithme de membership permet l exclusion des nœuds fautifs, et donc qu il est valide. De même, la validité de l algorithme de membership se base sur la disponibilité d une vue globale du temps, et donc de la validité de l algorithme de synchronisation. Cette notion d interaction de ces deux algorithmes est indispensable au processus de validation et a été étudiée ([Rus02], [PvH01], [Pfe03]) afin d intégrer cette notion à la preuve des algorithmes. Cependant, l architecture TTA implique une interaction encore plus grande des différents algorithmes que celle considérée jusqu à présent. Un exemple typique concerne la preuve de l algorithme de membership effectuée en PVS, dont l interaction avec l algorithme de synchronisation a été considérée. Cependant, l algorithme de synchronisation n est pas le seul à influencer le comportement de l algorithme de membership. Par exemple, une seconde hypothèse prise en compte est la validité du service de gestion de la fenêtre de transmission du bus guardian, qui lui-même repose sur l hypothèse de la validité de l algorithme de synchronisation. Le processus de validation de l architecture TTA complète entraîne donc la prise en compte d un grand nombre d éléments dépendants, et donc une modélisation et une construction de la preuve très complexe, voire impossible. 2.4 Couplage de méthodes de validation Certains travaux exploitent la complémentarité des différentes méthodes de validation. Ainsi dans [BM02] la technique de preuve a été utilisée pour la validation d un service de TTA en association à la technique de model checking. La première étape de cette méthodologie consiste à établir la preuve de la fiabilité d une représentation simplifiée du modèle (faible nombre de nœuds par exemple). Il est alors possible d en extraire un modèle abstrait du système, représentable dans un langage formel de modélisation comme les automates. Puis des propriétés sont vérifiées sur le modèle abstrait par model checking. Une autre approche est décrite dans [LUS04]. Ces travaux propose une méthode basée sur l utilisation de la preuve afin de générer des tests. Le test est employé ici pour compléter la validation d algorithmes dont la preuve n a pas aboutie ou est informelle, en analysant celle-ci pour en extraire des informations pertinentes pour le test. La faisabilité de cette méthodologie a été montrée par son application à l algorithme de membership de TTA. 56

57 Chapitre 3 Validation : conclusion Les sections précédentes présentent les différents résultats de validation obtenus par l application de différentes méthodes de validation sur l architecture TTA. Ces résultats, qu ils soient complets ou non, ne sont cependant pas le seul intérêt dans l absolu. En effet, l élément capital dans la définition d une stratégie globale de validation est l étude de la faisabilité et l efficacité des méthodes utilisées. Cette section présente donc une analyse des différentes techniques de validation dans le contexte de TTA, et montre qu il existe un manque pour la validation de l architecture globale du système et de ses différents services lorsqu ils sont intégrés. De plus, un nouvel aspect est introduit pour la validation des services de TTA : la validation temporelle des bornes de ces services. C est-à-dire que dans le contexte temps réel critique, la validation d un service implique également un aspect de validation de sa borne temporelle (son pire temps d exécution). Un exemple d illustration de l utilisation de ces bornes est donné dans la partie 4 de cette thèse, dans le cadre de l étude de la qualité d une application contrôle-commande. Complémentarité du model checking pour la validation de TTA D une part les méthodes non formelles, comme l injection de fautes, sont intrinsèquement limitées par leur nature informelle. Bien que des projets de test et d injection de fautes intensifs aient permis la détection de plusieurs erreurs ayant mené à la correction des spécifications du protocole TTP/C, ils ne garantissent pas l absence d autres erreurs. Ces projets ont de plus été longs et coûteux : le projet FIT par exemple a impliqué le développement d un simulateur, d une maquette, la mise en oeuvre de différentes techniques d injection de fautes nécessitant des composants matériels (magnétique par exemple), etc.. De plus, la détection de certaines erreurs a entraîné la modification des spécifications et donc de la phase de réalisation (de la maquette). La mise en oeuvre de techniques de validation moins onéreuses et permettant la détection d erreurs de spécifications, comme peuvent le faire les techniques formelles a priori, peut donc être une solution complémentaire à ces vérifications. D autre part, les validations par la preuve sont difficilement exploitables dans le contexte de systèmes distribués communicants, et encore plus dans le cadre industriel, à cause de la nature de ces techniques et de l utilisation de théories mathématiques complexes et restrictives. De plus, la validation d une architecture complète dont les algorithmes sont interdépendants est un problème souvent trop lourd pour la technique de preuve. L association du model checking à la preuve pourrait être une solution à ce dernier problème, mais l inconvénient de la complexité d utilisation de cette dernière méthode demeure. Validation des bornes temporelles Un autre aspect, peu pris en compte dans les techniques existantes, est la validation des bornes temporelles des services validés. En effet, dans le contexte du temps réel et de la tolérance aux fautes, la validité d un service dépend de l exécution correcte de son comportement dans un temps borné, mais également du temps nécessaire à cette exécution. La validation de la borne d un service, c est-à-dire la vérification que son temps d exécution dans le pire cas sera inférieur à une borne donnée spécifiée, 57

58 est donc un élément capital de la validation d un système, et la méthode de validation devra permettre l expression et la vérification de ce type de propriétés temporelles. Les services les plus concernés par cette validation sont les mécanismes de détection et de recouvrement d erreurs. Certaines approches existent pour l architecture TTA, sans toutefois offrir une méthodologie adaptée. Par exemple, la validation de l algorithme de détection des cliques dans [BM02] intègre cette notion de borne dans la représentation du système. Ainsi, la propriété vérifiée est la détection de l erreur en moins de deux rounds. Le modèle conçu pour cette validation dépend cependant de cette borne, et devra être modifié si elle change. Elle nécessite donc une connaissance a priori de la borne, et ne permet pas de la déterminer avec précision. Une approche prenant en compte plus précisément la notion de borne temporelle est présentée dans [Pal00]. L approche utilisée est l injection de fautes sur un modèle de simulation, approche qui ne fournit pas les garanties offertes par les méthodes formelles. Ces garanties sont cependant nécessaires pour la validation des systèmes critiques. Le chapitre suivant va présenter la méthodologie pour la validation des bornes temporelles des services de l architecture TTA que nous proposons dans cette thèse. Cette méthodologie est basée sur la technique de model checking, solution complémentaire aux expérimentations de simulation et d injection de fautes d une part et aux validations formelles par preuves de théorèmes d autre part. Elle permet, à partir d un modèle du système et de son environnement (hypothèses de fautes), la vérification de propriétés comportementales et temporelles. En particulier, elle permet de déterminer la borne temporelle d un service intégré dans l architecture complète. Cette méthodologie a été élaborée et développée à partir de Récemment, une équipe de recherche (Steiner, Rushby, Sorea, Pfeifer) a mis en place une méthodologie proche pour définir ces mêmes bornes temporelles. La similitude de cette approche avec la nôtre semblerait prouver que cette technique est effectivement une solution appropriée dans le contexte spécifique de TTA. Il serait très intéressant de comparer en détail cette technique avec la nôtre, afin d étudier par exemple la pertinence dans notre contexte de la représentation continue du temps par rapport à la représentation discrète utilisée dans l approche de cet article. L article [SRSP04] ne datant que de juillet 2004, cette comparaison est à l heure actuelle une perspective de notre travail. 58

59 Troisième partie Méthodologie de validation pour TTA 59

60 60

61 Chapitre 1 Méthodologie de validation La partie précédente a présenté un état de l art des différentes méthodes de validation et des travaux effectués pour la validation temporelle de l architecture TTA. Cette partie a montré que la méthode de model checking pouvait être efficace pour la validation de cette architecture. Cette méthode peut être une solution complémentaire aux autres méthodes en apportant les avantages des méthodes formelles et a priori, tout en évitant la complexité de la validation par preuves de théorèmes. Les résultats de ces dernières peuvent cependant être utilisés dans notre méthodologie, en les intégrant dans les hypothèses de modélisation pour effectuer des abstractions des modèles. La partie qui suit va présenter nos travaux, en proposant une méthodologie de validation de bornes temporelles basée sur la méthode de model checking. 1.1 Première phase : conception d un modèle abstrait validé La première phase de la méthodologie consiste en la conception d un modèle abstrait et validé de l architecture TTA. Cette phase est représentée figure 1.1 Choix d un formalisme de modélisation La première phase de la méthodologie consiste en l établissement d un modèle du système. Il est donc nécessaire de choisir un formalisme de modélisation, dépendant de nombreux critères liés aux caractéristiques du système et aux propriétés à valider. Le choix du formalisme pour la validation des bornes temporelles de TTA est détaillé dans le chapitre 2 suivant. Dans le cadre de la validation par model checking, le système est traditionnellement modélisé en systèmes états/transitions. Conception du modèle conceptuel La première étape de modélisation du système est la conception d un modèle conceptuel. Le but de ce premier modèle est de permettre une représentation fidèle des spécifications, en exprimant concrètement les détails du système. Ce concept permet une étape de conception plus aisée et moins sensible aux erreurs de modélisation. Par exemple, le modèle conceptuel va représenter indépendamment chacun des composants du système, ou va représenter chacun de ses paramètres par une variable indépendante. Validation du modèle conceptuel Cette première phase de modélisation est accompagnée d une étape de validation, afin de vérifier l exactitude du modèle par rapport aux spécifications. Deux méthodes permettent une première validation : un examen minutieux effectué par un expert et des simulations permettant l observation du comportement du modèle. Cette étape est facilitée par l expressivité de ce modèle conceptuel. Elle ne garantit cependant que la détection des erreurs grossières de modélisation. Une vérification plus fine de l exactitude du modèle passe par la vérification de propriétés comportementales, extraites des spécifications 61

62 modèle de TTA Simulation + Vérification Légende: modèle TTA vérifié Modèles Actions Abstractions + Vérification modèle TTA vérifié et abstrait FIG. 1.1 Première étape de la méthodologie : conception d un modèle abstrait vérifié et reflétant le comportement désiré du modèle. La vérification de propriétés par model checking passe par l exploration exhaustive de tous les comportements du système donc par un parcours de l espace des états possibles du système. Or le modèle conceptuel est très détaillé et l espace d états d un tel modèle est souvent trop important pour une analyse exhaustive qui entraîne une explosion du temps de calcul et de l utilisation mémoire. Abstraction du modèle conceptuel Une étape d abstraction du modèle conceptuel est alors nécessaire afin de réduire l espace des états à parcourir lors de la vérification des propriétés. Les abstractions applicables dépendent des caractéristiques du système, ainsi que des hypothèses déterminées pour la validation. Les abstractions appliquées sur le modèle conceptuel de l architecture TTA sont décrites dans la section 3. Validation du modèle abstrait Enfin la dernière étape de conception d un modèle du système consiste en la validation du modèle abstrait. Un ensemble de propriétés comportementales est validé par model checking sur le modèle. Ces propriétés permettent de valider le comportement désiré du système. Cette étape de validation du modèle peut également inclure d autres méthodes de validation. Le comportement du modèle peut par exemple être comparé au comportement d un prototype ou d un modèle de simulation existant de l architecture (par exemple ceux validés par injection de fautes lors du projet FIT, cf. section 2.1). La première phase de la méthodologie présentée ici aboutit donc à un modèle abstrait validé du système. Ce modèle de base de l architecture sera complété (en suivant ces mêmes étapes de validation et d abstraction) par une modélisation spécifique du ou des services étudiés. Le modèle final pourra ensuite être utilisé pour la validation des bornes temporelles. 62

63 1.2 Deuxième phase : validation des bornes La deuxième phase de la méthodologie, présentée figure 1.2, est l étape de validation effective et d extraction des bornes. Observateur Modèle TTA abstrait et vérifié Scénarios Modèle de fautes Model checking Légende: Modèles Actions num B S Bornes numériques : (dépendantes des paramètres) Résultats Analyse Humain Borne paramétrée B S = +π FIG. 1.2 Deuxième étape de la méthodologie : validation des bornes temporelles en présence de fautes Modèles de fautes Le but de cette méthodologie est la validation des bornes temporelles des services de TTA, architecture tolérante aux fautes. Il est donc nécessaire, dans une deuxième phase, d établir les hypothèses de fautes auxquelles le système devra être tolérant, puis de modéliser ces hypothèses et enfin d intégrer cette modélisation au modèle issu de la première phase. Le modèle des hypothèses dépend des hypothèses de fautes générales du système, mais aussi du service à valider et du type de validation. En effet, on peut distinguer deux types de services : les services de détection d erreurs, qui doivent détecter tous les types de fautes, et les autres services censés résister à certaines fautes. Ainsi, la validation d un service de détection entraînera nécessairement la modélisation de toutes les fautes. Pour la validation des autres services, deux types de validation peuvent être effectués : d une part la vérification des hypothèses de fautes et des limites de la tolérance du service considéré, qui entraîne la modélisation de toutes les fautes pour étudier le comportement de ce service dans tous les cas, d autre part la détermination de la borne temporelle du service, sous ces hypothèses de fautes. Dans ce cas, seules ces hypothèses de fautes seront modélisées, les fautes entraînant la défaillance du service ne devront pas être considérées. Validation de la propriété temporelle, borne temporelle numérique La validation de la borne temporelle s effectue par la vérification que le pire temps d exécution du service ne dépasse jamais une certaine valeur maximale donnée. La méthodologie présentée ici permet 63

64 également de déterminer une valeur numérique de la borne temporelle du service validé (c est-à-dire le pire temps d exécution de ce service). La plupart des outils de validation ne permettent pas d obtenir directement une valeur numérique du pire temps d exécution d un scénario donné. Ils offrent par contre la possibilité de vérifier si ce pire temps ne dépasse pas une valeur donnée. Dans ce cas, cette borne est obtenue par raffinement de la valeur maximale vérifiée. Soit une valeur validée par l analyse du modèle : le temps d exécution du service étudié ne dépasse jamais. Cette valeur est alors diminuée jusqu à ce que l analyse détecte une violation de cette valeur maximale ( ). La plus grande valeur maximale validée est alors la borne du service :! #" (1.1) En pratique, nous déterminons cette valeur par dichotomie à partir d une valeur initiale extraite par une analyse humaine des spécifications TTP/C. Une telle analyse donne un ordre de grandeur de la borne réelle, plus ou moins précise suivant la complexité du service analysé. Cette borne validée est le pire temps d exécution du service de l architecture TTA, dépendant du modèle de fautes et de la valeur des paramètres du système. Par exemple, la borne d un service validée avec un modèle de faute simple (1 seule faute symétrique) ne sera pas valable sous des hypothèses de fautes asymétriques. De même, les différents paramètres du système comme typiquement le temps de propagation d un message ou le nombre de nœuds du système pourront influencer cette borne. Analyse du pire scénario et extraction de la borne paramétrée La détermination de la borne temporelle numérique du service permet de déterminer le pire scénario : lorsque le temps d exécution du service atteint la valeur $. La plupart des outils de model checking permettent la génération de l un de ces pires scénarios. Cette trace peut être analysée et simulée, afin d en extraire le comportement du système lié au pire temps d exécution du service. Cette analyse, couplée à une connaissance du comportement du système (spécifications TTP/C), permet d extraire les paramètres du système pouvant influer sur la borne de ce service. Par exemple, la durée d un slot ou d un round est souvent un paramètre influent. Le processus de validation de la borne numérique est alors réexécuté avec de nouvelles valeurs des paramètres. Les nouvelles bornes numériques extraites et les nouveaux pires scénarios sont alors également analysés. Ces différentes analyses des bornes numériques %& et des pires scénarios associés permettent ainsi d extraire la borne temporelle paramétrée du service étudié. Cette borne est alors générique pour les paramètres du protocole et dépendante des hypothèses de fautes. Elle peut également être dépendante de la structure de l architecture (nombre de composants par exemple). 64

65 Chapitre 2 Choix du formalisme de validation La méthodologie présentée dans la section précédente repose sur la modélisation formelle du système et de ses propriétés, puis sur la vérification de ces propriétés sur le modèle par une méthode d analyse adaptée. La première étape et certainement la plus importante, consiste à choisir un formalisme de modélisation adapté au système et à sa validation. Ce choix repose sur l estimation de différents critères en fonction des caractéristiques du système et de ses propriétés. Cette section présente le processus global de choix du formalisme de modélisation pour la validation temporelle de TTA : analyse des caractéristiques de l architecture en terme de modélisation et de validation, étude dans ce contexte des différents formalismes disponibles et comparaison de plusieurs formalismes possibles afin d en choisir un adapté à notre contexte. Etat vs état Il est tout d abord nécessaire d éclaircir un point de vocabulaire : un état peut signifier ici deux choses. D une part, il représente un élément du formalisme état-transition. Une transition relit deux états entre eux. Dans les réseaux de Petri temporels ([Ram74]), ce type d état est qualifié de place. Cependant, dans les formalismes comme les automates temporisés ([AD90, AD94]) ou SDL (Specification and Description Language, [ITU00]), cet élément conserve le nom état. D autre part, dans le cadre de l analyse d un modèle, l ensemble des comportements de ce modèle est représenté par un graphe d états. Dans ce cadre, l état se rapporte alors à l état du système (du modèle), qui regroupe toutes les informations relatives au modèle à un instant donné. Par exemple, l état d un système modélisé en RdPT contiendra le marquage des places, les transitions sensibilisées et leurs intervalles de tir. Mais l état d un système modélisé en automates temporisés va contenir l état des automates (dans le premier sens du terme), ainsi que les contraintes temporelles de ses horloges et éventuellement la valeur des autres variables du système s il y en a. Lorsque le contexte ne permet pas de différencier clairement ces deux termes, nous essayerons autant que possible de le faire nous-mêmes. 2.1 Formalisme de modélisation pour TTA Le choix d un formalisme adapté à la modélisation d un système particulier dépend de différents critères, dont les trois fondamentaux ([Boy01]) sont : le pouvoir d expression, c est-à-dire la capacité d un formalisme à pouvoir exprimer certaines caractéristiques du système ; le pouvoir de modélisation, c est-à-dire sa capacité à l exprimer simplement. Cet aspect permet une facilité de modélisation, mais est également souvent lié au pouvoir d analyse. le pouvoir d analyse ou de vérification, c est-à-dire sa capacité à exprimer et à vérifier des propriétés du système. Le pouvoir d analyse est en fait souvent celui de la méthode d analyse associée au formalisme. 65

66 Le choix d un formalisme dépend donc quasiment entièrement du type de système à modéliser, de ses caractéristiques à exprimer et de ses propriétés à valider. Le pouvoir de modélisation est souvent impossible à définir précisément et à comparer, car il dépend de la perception de l utilisateur et de sa connaissance a priori des formalismes. Nous ne nous intéresserons donc ici qu aux pouvoirs d expression et d analyse. La section suivante introduit une analyse des besoins de l architecture TTA en terme de modélisation. Ces caractéristiques définissent en partie le pouvoir d expression du formalisme nécessaire à la modélisation de cette architecture et un certain nombre de formalismes peuvent être désignés comme potentiellement adaptés. Une comparaison théorique de leur pouvoir d expression est alors présentée et résumée dans le tableau 2.1 de la section Système états - transitions La partie 2 précédente a motivé le choix de la méthode de validation par model checking. Dans ce cadre, le système est traditionnellement représenté en un système états - transitions fini et les propriétés à vérifier sont exprimées en logique temporelle. En effet, les systèmes états-transitions constituent une représentation classique du comportement dynamique. Le système est considéré dans un état à un instant donné, puis l occurrence d un événement (représentée par une transition) le fait passer dans un autre état. L ensemble des états possibles est appelé espace d états du système. Une exécution donnée du fonctionnement du système peut donc être représentée par une suite d états et de transitions alternés. L ensemble des comportements possibles d un système peut ainsi être représenté par un graphe représentant l ensemble des chemins d exécution. Ce graphe est le graphe d états du système. La détection des comportements cycliques est intégrée aux méthodes d analyse. Cette représentation permet alors une analyse de propriétés sur les différents états possibles du système par un parcours du graphe d états. Les systèmes à états-transitions sont donc des formalismes bien adaptés à la modélisation du comportement d un système dans le cadre de la validation de propriétés. Il est maintenant nécessaire de sélectionner parmi ces formalismes ceux qui correspondent au contexte étudié Pouvoir d expression pour TTA Aspect distribué TTA est un système composé d entités communicantes réparties autour d un réseau et qui fonctionnent en parallèle. Cette caractéristique nécessite de pouvoir exprimer dans le modèle les concepts de parallélisme, de communication et de concurrence. Ces concepts impliquent souvent la possibilité de modélisation de la communication par signaux (sur rendez-vous synchronisés) ou de la gestion de variables partagées. Traitement des données La nature même de l architecture TTA, comme de la plupart des architectures communicantes, est basée sur l échange de données applicatives entre différentes entités. Bien que la valeur de ces données ne soit théoriquement significative que pour les tâches applicatives, elle peut également influencer le comportement de certains mécanismes, typiquement ceux dédiés à la gestion de la redondance. Il est donc nécessaire de pouvoir modéliser les données applicatives de façon explicite, ainsi que leur traitement. L expression des données dans la modélisation de TTA est en particulier importante pour la modélisation du niveau hôte de TTA : les tâches applicatives et la couche FT layer. Cependant, il n est pas nécessaire d exprimer des données complexes. En effet, il faut considérer le fait que le système à valider est l architecture TTA et les services qui lui sont intégrés. La plupart de ces services se situent au niveau du sous-système de communication et sont indépendants de la valeur des données applicatives. Le niveau FT layer n intègre que les valeurs des données transmises sur le bus de communication qui sont a priori des données simples. Enfin, le but de ce processus de validation est de valider l architecture et ses services 66

67 et non l application elle-même. Les tâches applicatives ne seront donc pas directement modélisées, mais représentées de façon abstraite (cf section 1.1). Vision globale Une autre caractéristique de l architecture TTA, ou tout du moins de son niveau de communication géré par le protocole TTP/C, est la disponibilité d une vue globale du système. TTP/C assure en effet une vision globale d un certain nombre d informations communes à tous les nœuds, comme le membership ou le temps global. La notion de représentation du temps sera abordée séparément, mais l idée de vision globale des éléments du système, en particulier des variables, reste une caractéristique à conserver dans le choix du formalisme de modélisation. Tolérance aux fautes Le chapitre 1 a montré que la plupart des systèmes tolérants aux fautes comportent de la redondance. Que cette redondance soit matérielle ou logicielle, son expression du point de vue modélisation passe par la possibilité d implémenter des comportements réutilisables/reproductibles. Le formalisme choisi devra donc permettre une modélisation modulaire Représentation du temps La gestion du temps dans notre contexte est un des éléments principaux de la modélisation et de la validation. Le système cible est en effet un système temps réel critique et la validation effectuée est une validation de propriétés temporelles. Cette section introduit donc les différentes représentations possibles du temps ([Boy01]) ainsi que les besoins de l architecture TTA. Temps quantitatif La caractéristique de temps réel et de criticité des systèmes cibles impose une représentation fine du temps et des contraintes temporelles du système. Ces contraintes temporelles, en particulier celles qui sont nécessaires à la validation des bornes des services de TTA, s expriment en terme de temps d exécution : une série d actions nécessaires à l accomplissement d un service devra être bornée dans le temps. Le formalisme choisi devra donc pouvoir exprimer la durée d une action ou d une série d actions. Cela entraîne une considération quantitative du temps, c est-à-dire que les événements ne sont pas uniquement ordonnés (considération qualitative), mais ils le sont à des instants temporels valués. Cela permet d exprimer une notion de durée, intervalle quantitatif entre deux instants. Dans ce cadre, il existe deux considérations possibles : le temps discret et le temps continu (ou dense). Dans un modèle à temps discret, l évolution du temps est considérée comme une succession croissante de nombres entiers. Les événements sont supposés se produire exactement à l un de ces instants temporels. La seconde considération du temps est le temps continu, représentant l hypothèse qu entre deux instants il en existe toujours un autre. Cette dernière représentation est donc plus précise que la considération du temps discret et donc idéalement préférable pour la validation de systèmes critiques sur le plan temporel. De plus, l un des buts de nos travaux était l étude de l impact de la désynchronisation des horloges des nœuds sur le comportement temporel du système. La prise en compte de cette désynchronisation entraîne la considération de plusieurs échelles de temps (au niveau de la désynchronisation et donc des tics d horloge, au niveau des slots et des rounds et au niveau plus global des cycles de cluster). Dans ce cadre, le temps continu semble plus adapté à la modélisation du système afin de limiter l explosion combinatoire impliquée par ces différentes échelles de temps. Le temps continu entraîne cependant une plus grande complexité de l analyse. Temps global La représentation d une vision globale du temps dans un système distribué impose une caractéristique 67

68 de modélisation supplémentaire. En effet, les différents composants répartis du système n ont qu une vision locale du temps (horloge locale). Le temps global est fourni par des mécanismes spécifiques, comme l algorithme de synchronisation de TTA qui garantit une synchronisation des horloges locales à un intervalle près. Cet intervalle de désynchronisation d horloges locales fait donc partie du système et devra être modélisé, ainsi que la possiblité d exprimer une horloge globale à tous les composants du système. Synchronisation d actions Dans notre contexte, pour la modélisation de systèmes complexes, parallèles ou modulaires, le concept de synchronisation des actions est nécessaire. Cette synchronisation peut être synchrone, sur rendez-vous de deux entités, c est-à-dire en un échange de signal instantané. Elle peut également être asynchrone, c est-à-dire par la transmission d un message à une autre entité. Cette différence de gestion de la synchronisation doit être gérée lors de la modélisation, afin d éviter des comportements indésirables. Par exemple, le rendez-vous en automates temporisés est bloquant, c est-à-dire qu un automate attendant un signal de synchronisation ne peut évoluer tant qu il ne l a pas reçu. Le modèle doit donc être conçu de façon à empêcher les deadlocks, situations dans lesquelles plus aucune évolution du système n est possible. Un autre exemple est le délai introduit par l envoi d un message de la synchronisation asynchrone : le message de synchronisation n est pas forcément prioritaire, son instant de réception dépend du mode de gestion des messages. Par exemple, si la boîte aux lettres de l entité réceptrice contient déjà des messages, le message de synchronisation ne sera reçu qu après les autres messages déjà en attente. Contraintes temporelles La notion de contraintes temporelles d un système peut impliquer deux types de contraintes : les conditions et les obligations. Le premier type permet de déterminer une condition temporelle sur l exécution d une action. Le deuxième type de condition temporelle peut être nommé l urgence. Cette notion permet de spécifier des conditions fortes sur le comportement du système : une action non seulement peut, mais doit être exécutée à un instant donné. L urgence permet de faciliter l expression et la vérification des contraintes temporelles et offre des possibilités de contraintes supplémentaires. Cette notion est très importante dans notre contexte. En particulier, elle permet la représentation des propriétés temporelles de vivacité par la représentation de la notion de chien de garde. Le chien de garde [Boy01] permet de vérifier que la durée écoulée entre deux actions est inférieure à une borne donnée. Il permet de signaler la violation de cette condition par une alarme. La représentation des chiens de garde nécessite la possibilité de représentation de l urgence et la synchronisation des actions Présentation de cinq formalismes potentiels pour la modélisation de TTA Première sélection de formalismes La réflexion pour l établissement du choix du formalisme s est d une part portée sur le choix entre les langages synchrones et les langages asynchrones. Ces deux familles de formalismes sont adaptées à la modélisation des systèmes temps réel. Le comportement d un système est défini par des règles qui réagissent aux entrées du système. Dans les langages synchrones, les entrées-sorties sont considérées comme instantanées (c est-à-dire dans le même tic d horloge), et les actions ont une durée nulle. Ces formalismes sont cependant peu adaptés à notre problématique sur deux points : ils conviennent mal à la représentation des systèmes distribués (puisqu ils supposent la formation de blocs atomiques de logique), la sémantique de temps convient mal à la vérification de propriétés temporelles quantitatives. Une action doit alors être représentée comme une suite d entrées-sorties dont le nombre représente sa durée avec comme unité de temps le cycle d horloge du système. 68

69 Ainsi, les langages synchrones ont été écartés car ils semblent moins adaptés à la représentation du système cible et de ses contraintes temporelles que les systèmes à états-transitions asynchrones. Le choix du model checking comme méthode d analyse permet d aute part d écarter certains formalismes dédiés à la conception d application (tels UML [OMG01] ou SA/RT [WM85]) qui sont trop peu formels dans notre contexte de validation. Dans le cas d UML, il existe cependant une extension applicable dans le contexte des systèmes distribués temps réel : le profil TURTLE-P [ACLdSS04], extension de TURTLE (Timed UML and RT-LOTOS Environnement) [AdSSL 01]. Ce dernier est un profil UML qui utilise des opérateurs de RT-LOTOS (temporels et de synchronisation) afin de fournir une extension temps réel possédant une sémantique formelle. TURTLE-P rajoute à ce profil la possibilité de modéliser des protocoles et des architectures distribuées. La sémantique formelle des modèles TURTLE et TURTLE-P repose sur leur traduction [Loh02] en spécifications RT-LOTOS. Le langage RT-LOTOS (Real-Time LOTOS) [CSLO00] est une extension temporelle permettant l expression du temps quantitatif de l algèbre de processus LOTOS (Language of Temporal Ordering Specification) [ISO88]. Les spécifications RT-LOTOS ainsi obtenues peuvent être validées grâce à l outil RTL 1, par simulation (et analyse de traces) ou par génération d un graphe d accessibilité. L outil RTL génère ce graphe grâce à la compilation des spécifications RT-LOTOS en automates temporisés. Ainsi, l utilisation de TURTLE-P ou RT-LOTOS permet une modélisation de haut niveau du système tout en fournissant une sémantique formelle. Le processus de validation lui-même est cependant basé sur un modèle exprimé en un formalisme de plus bas niveau : les automates temporisés, obtenu par traduction automatique. L utilisation directe de ce formalisme permettra d avoir plus de contrôle sur la modélisation, les abstractions des modèles ou la complexité de l analyse. TURTLE-P et RT-LOTOS ne seront donc pas envisagés plus avant pour la validation temporelle de TTA. Des caractéristiques de l architecture, il est possible d extraire une notion indispensable qui oriente directement le choix : l expression quantitative du temps. Le choix du formalisme de modélisation nécessaire à la modélisation de TTA s oriente donc vers les extensions temporelles des systèmes étatstransitions permettant la gestion du temps quantitatif. Le formalisme choisi devra également pouvoir exprimer les données simples, une vision globale du système, permettre l expression des contraintes temporelles (avec du temps quantitatif), du parallélisme et de la concurrence et si possible de la modularité de la modélisation. A notre connaissance, parmi les extensions temporelles des systèmes états-transitions, cinq formalismes semblent être adaptés à la modélisation de TTA du point de vue de la satisfaction de ces exigences de modélisation : les réseaux de Petri temporels (que nous nommerons RdPT) [Mer74], SDL (Specification and Description Language) [ITU00], IF (Intermediate Format) [BFG 99], les TSA (Timed Safety Automata, extensions des automates temporisés) [BY04] et les automates hybrides [ACHH92]. Les caractéristiques de TTA ont permis d exclure certains formalismes, comme par exemple les réseaux de Petri temporisés [Ram74] qui ne permettent pas la modélisation d intervalles de temps, mais seulement de durées, ou les automates temporisés de base qui ne permettent pas l expression des contraintes temporelles nécessaires à la modélisation de l urgence. Cette section introduit les concepts de base des cinq formalismes cités ci-dessus. Réseaux de Petri temporels Les réseaux de Petri temporels [Mer74] sont une extension temporelle des réseaux de Petri. Les réseaux de Petri sont des outils classiques de modélisation des systèmes distribués. Le comportement du système est exprimé par un réseau de places pouvant être marquées par des jetons, reliées entre elles par des transitions. Le comportement dynamique du système est représenté par l évolution du marquage des places, en fonction du tir des transitions. Les arcs des transitions peuvent être valués en leur associant 1 http :// 69

70 une valeur correspondant au poids de cet arc lors du tir de la transition. Dans le cas simple d un poids de tous les arcs égal à 1, une transition est sensibilisée si toutes les places en amont sont marquées par au moins un jeton. Le tir d une transition supprime un jeton de chacune des places en amont et génère un jeton dans chacune des places en aval. Dans le cas d une transition dont les arcs sont valués, le nombre de jetons consommés lors du tir dans les places en amont ou produits dans les places en aval est égal au poids des arcs de la transition. Les réseaux de Petri temporels permettent d associer un intervalle de tir aux transitions, en spécifiant deux dates de tir minimale et maximale ( et ). Une fois sensibilisée, la transition pourra être tirée au plus tôt à et devra au plus tard être tirée à (sauf si le tir d une autre transition la désensibilise). La gestion de l évolution du temps est locale à chacune des transitions : chaque sensibilisation initialise un compteur lié à la transition. L évolution du système global s effectue en fonction de la valeur de tous les compteurs actifs en cours. La sémantique des réseaux de Petri temporels ne permet pas d exprimer les données. Certains types peuvent être représentés indirectement comme par exemple les booléens ou les compteurs, mais ce formalisme n est en général pas adapté à l expression des données. Horloge Horloge [ 1; 1 ] Top Top Utilisateur FIG. 2.1 Modélisation d une horloge simplifiée en RdPT Un exemple de modélisation est donné dans la figure 2.1, issue de l outil Romeo 2. Ce modèle est la représentation d une horloge simplifiée en réseaux de Petri temporels. Le principe est de prévenir un utilisateur toutes les unités de temps (top d horloge). Cet exemple servira d illustration de la modélisation des systèmes dans les cinq formalismes. Le poids des arcs dans cette figure est égal à 1 pour tous les arcs. Dans cet exemple le temps s écoule pendant la sensibilisation de la transition Horloge. Au bout de une unité (les bornes minimale et maximale étant égales, cet intervalle devient une durée fixe), la transition est tirée et la place Top est marquée, ainsi que de nouveau la place Horloge. Le marquage de la place Top sensibilise la transition Top, qui est instantanée ( ) et qui représente le top d horloge pour l utilisateur (ici représenté par le marquage de la place Utilisateur). Ce comportement se répète : la transition Horloge a été resensibilisée par le marquage de la place Horloge et donc sera de nouveau tirée au bout de une unité de temps. SDL - Specification and Description Language Le langage SDL est défini par la norme Z.100 de l ITU (International Telecommunication Union) [ITU00]. C est un langage formel basé sur des machines états-transitions qui permet de spécifier et de décrire la structure et le comportement des systèmes. C est un formalisme qui permet une modélisation hiérarchique ; les différents composants du modèle communiquent par signaux et peuvent partager des données. Le comportement du système est représenté par une succession d états. Le système dans un état y reste jusqu à ce qu une transition soit possible. Une transition peut consister en la réception d un signal provenant d un autre composant du système ou de l expiration d un compteur, ou être forcée pour 2 http :// 70

71 provoquer une transition instantanée. Le système peut alors effectuer une action, puis transite dans un autre état (qui peut être le même). La norme initiale de SDL ne spécifie aucun contrôle sur l évolution du temps. Le temps s écoulant dans un état du système ou pendant l exécution d une action n est pas déterminé. Cet indéterminisme temporel ne permet pas la construction d un graphe fini de représentation des comportements du système et rend donc impossible l analyse de ce système ([BGK 00]). La version de SDL considérée ici possède une sémantique stricte pour la gestion de l évolution du temps de simulation du modèle. Elle repose sur deux hypothèses : les actions et la transmission des signaux sont considérées en temps 0 (leurs temps d exécution et de transmission sont nuls) et le temps de simulation global du système ne peut évoluer tant qu il reste des transitions exécutables. Le temps évolue ensuite de façon discrète, chaque transition ne peut donc se produire qu à des instants à valeurs entières. process H process U Horloge SET (now +1,T) T Utilisateur Horloge TOP TOP SET (now +1,T) Utilisateur Timer T; Horloge FIG. 2.2 Modélisation d une horloge simplifiée en SDL La figure 2.2 montre la modélisation du même système d horloge que celui représenté précédemment en RdPT. Le système est modélisé par deux composants : H, qui envoie le signal top au composant U. H s initialise (l état initial d un composant est représenté par l état sans nom) en armant une temporisation à la valeur now. La valeur now est une variable du système qui contient la valeur actuelle du temps de simulation. La temporisation ainsi armée se déclenchera une unité de temps plus tard. Le composant H passe ensuite dans l état Idle. Sur réception d un signal correspondant à l expiration de la temporisation t-top, il réarme cette temporisation, envoie un signal top et repasse dans l état Idle. Ce composant envoie donc un signal top toutes les unités de temps. Le destinataire de ce signal a été défini comme le composant U. Ce dernier, à l initialisation du système, passe directement dans l état Idle, dans lequel il est prêt à recevoir le signal top. Sur réception de ce signal, il reste en Idle, il est donc toujours prêt à recevoir top. IF - Intermediate Format IF est une appellation commune à un langage de description de système ([BFG 99]) et à un environnement de validation ([BFG 00]). Cette section présente le langage IF, formalisme de modélisation de l environnement IF. Un système peut être modélisé par un ensemble de processus, communiquant par messages asynchrones (boîte aux lettres), rendez-vous ou variables partagées. Chacun des processus est une extension des automates temporisés avec la possibilité de représenter les variables et les contraintes temporelles comme par exemple l urgence et les chiens de garde. Les transitions entre les états peuvent être associées à des contraintes sur les variables et les horloges du système, ou à la réception d un signal. 71

72 Ces transitions sont souvent instantanées, mais peuvent être liées à des délais fixes ou bornés (attributs eager, delayable ou lazy). Le comportement temporel du système est ainsi géré en considérant les délais définis sur les transitions et le temps écoulé dans les états, défini par les contraintes sur les horloges. L urgence sur les états peut également être représentée par des états instantanés, suivant la valeur de l attribut stable. var x clock ; signal " ; signalroute " #urgent. from to with ; process " var clock ; state Init #start ;. task x :=0 ;. nextstate Horloge ; endstate ; state Horloge #start ;. when x=1 ;. output " via " ;. set x :=0 ;. nextstate Horloge ; endstate ; process " state Utilisateur. input " ;. nextstate Utilisateur ; endstate ; endprocess ; endprocess ; FIG. 2.3 Modélisation d une horloge simplifiée en IF Un exemple de modélisation IF est donné figure 2.3 pour le même système d horloge que précédemment. Le système se décompose en deux processus H et U. Le processus H envoie un signal top toutes les unités de temps au processus U. Le processus U ne contient qu un seul état Utilisateur dans lequel il est prêt à recevoir le signal top. Sur réception de ce signal, il retourne dans le même état. Le processus H possède un état initial Init, qu il quitte en initialisant son horloge x puis transite dans l état Horloge. Dans cet état, lorsque l horloge x atteint la valeur 1, H envoie alors le signal top et reste dans le même état en réinitialisant son horloge. L action d envoi du signal top dans la signalroute S impose un rendez-vous sur ce signal : parallèlement, le processus U effectue l action de réception de ce signal, puis il reste dans le même état Utilisateur. Ce comportement se répète alors, les deux processus H et U se retrouvant dans les mêmes états que précédemment. TSA - Timed Safety Automata Les Timed Safety Automata (TSA), présentés dans [BY04] à partir de [HNSY94], sont une extension des automates temporisés ([AD90, AD94]). Les TSA permettent la représentation de conditions sur les transitions : les guards, qui obligent l automate à ne prendre cette transition que si les conditions du guard sont remplies. Les horloges sont déclarées comme des variables et peuvent être réinitialisées lors de l exécution d une transition. Les TSA permettent également de spécifier des contraintes sur les 72

73 horloges pour restreindre le temps passé dans un état donné (invariant). Un automate ne pourra donc rester dans un état que tant que les conditions de son invariant sont remplies et devra quitter cet état lorsque l invariant devient faux. Les TSA offrent également une possibilité de synchronisation entre deux ou plusieurs automates par l échange de signaux sur rendez-vous ou par diffusion. Cette synchronisation d actions est bloquante, c est-à-dire qu un automate devant émettre un signal ne pourra évoluer que si un autre automate est prêt à le recevoir. Enfin, les TSA offrent deux possibilités de représentation de l urgence sur les états : urgent et committed. Dans les deux cas, le temps ne pourra pas s écouler dans les états marqués comme tels. La différence entre urgent et committed est qu un état committed devra être quitté immédiatement, tandis qu aucune condition supplémentaire n est appliquée aux états urgents. Cette différence n est perceptible que lorsque deux transitions sont concurrentes : une transition sortant de la place committed sera exécutée en priorité, tandis que celle qui sort d une place urgent n a aucune priorité par rapport à toutes les autres transitions exécutables au même instant. H guard U Init Horloge Top Utilisateur x:=0 x==1 invariant x<=1 top! x:=0 commited top? FIG. 2.4 Modélisation d une horloge simplifiée en TSA L exemple de la modélisation de l horloge de la figure 2.4 illustre différents aspects de ce formalisme. Ce modèle est composé de deux automates communicants : l horloge H et l utilisateur U. Tout d abord la gestion du temps par contraintes temporelles est illustrée par la gestion de l horloge x de l automate H. x est initalisée par l exécution de la transition du passage de l état Init à l état Horloge. Ensuite, la seule transition possible du système est celle pour passer dans l état Top, exécutable uniquement si x==1. Or l automate H ne peut rester dans l état Horloge si son horloge dépasse la valeur 1, la transition est donc obligatoirement tirée. L automate transite alors dans l état Top, qui est committed, c est-à-dire qui doit être quitté immédiatement. La transition de retour est alors exécutée immédiatement, envoyant le signal top et réinitialisant l horloge x à 0. L automate utilisateur U reçoit alors le top d horloge. Le comportement se répète étant donné que le système se retrouve dans le même état qu au départ, H dans l état Horloge avec x=0. Les automates hybrides linéaires Les automates hybrides [ACHH92, SBB 99] sont dédiés à la modélisation des systèmes dits hybrides, typiquement constitués de composants digitaux tels que les contrôleurs qui interagissent avec un environnement dont les valeurs sont continues, et qui utilisent également des variables de contrôle à valeurs discrètes. Les automates hybrides permettent d une part une représentation du comportement discret des programmes et d autre part une représentation du comportement continu des variables de l environnement. L évolution de ces variables continues est exprimée par des équations différentielles permettant une description fine de leur évolution temporelle. Les automates hybrides linéaires [AHH96] sont des automates hybrides pour lesquels ces équations différentielles sont linéaires. L évolution d une variable x sera donc représentée par une équation de la forme a.dx = b, avec a et b des constantes, ou par un 73

74 Modèle de l horloge var x : clock; automaton H synclabs: top; initially Horloge & x=0; loc Horloge : while x<=1 wait {} when x=1 goto Top; loc Top : while True wait {} when asap do {x =0} sync top goto Horloge; end -- fin de l automate H automaton U synclabs: top; initially Utilisateur; loc Utilisateur : while True wait {} when True sync top goto Utilisateur; end -- fin de l automate U FIG. 2.5 Modélisation d une horloge simplifiée en automates hybrides linéaires 74

75 ensemble de ces équations (a.dx b,c ). dx représente la dérivée première de x (en fonction du temps). Les automates hybrides permettent aussi bien la modélisation des horloges et des chronomètres que des dérives d horloges ou des paramètres comme la température ou la vitesse. Il existe pour cela cinq types de variables : discrete, clock, stopwatch, analog et parameter. Les discrete représentent les variables discrètes du système ; les clock représentent les horloges, c est-à-dire que ces variables évoluent obligatoirement de façon linéaire avec dx=1 ; les stopwatch représentent le principe de chronomètre : elles peuvent soit évoluer comme une horloge, soit rester constantes (dx=0) ; les analog permettent de représenter les autres variables continues, dont le comportement temporel est plus complexe ; enfin, le type parameter est particulier : il permet de ne pas donner explicitement une valeur à une variable. L évolution du système devra considérer tous les cas possibles suivant toutes les valeurs possibles de ce paramètre. Ce type particulier permet l analyse paramétrée d un modèle. Le reste de la modélisation en automates hybrides est celle des automates temporisés classiques, comme celle servant de base aux TSA. Ainsi le système est représenté par la composition parallèle d automates, composés d états associés à des invariants reliés par des transitions associées à des guards, des signaux de synchronisation et des updates (réinitialisation des variables). Et de même que dans les TSA, la synchronisation entre automates s effectue de façon synchrone par rendez-vous. L urgence peut être représentée par le tir au plus tôt d une transition. La modélisation en automates hybrides linéaires de l exemple de l horloge est donnée figure 2.5. On y retrouve les mêmes composantes que pour le modèle en TSA : deux automates H et U, H possédant deux états Horloge (état initial) et Top tandis que U ne possède qu un état Utilisateur. La variable x du système est une horloge qui évolue donc linéairement avec dx=1 (l équation différentielle dx=1 est sous-entendue) dans les états du système. Lorsque x=1, l automate H passe de l état Horloge à Top en générant un signal de synchronisation top qui génère le tir simultané de la transition de l automate U. Puis H retourne dans l état Horloge au même instant (la guard de cette transition est marquée asap - as soon as possible -, elle est donc tirée immédiatement) et réinitialise x Comparaison du pouvoir d expression La section précédente a présenté plusieurs formalismes correspondants à la modélisation de TTA. Un résumé de l étude théorique de leur pouvoir d expression [Boy01, Rin03] est donné dans le tableau 2.1, spécifiant pour chacun des critères nécessaires à la modélisation de TTA si le formalisme y répond. RdP-T SDL IF TSA Hybrides Représentation du temps dense discret discret dense dense Vision globale du temps non non non oui oui Urgences non non états, états, états, transitions transitions transitions Synchronisation place partagée messages messages, signaux signaux signaux Chien de garde oui non oui oui oui Gestion des données pas de donnée locale, locale locale, globale partagée partagée globale Modularité non oui oui oui oui Parallélisme et concurrence oui oui oui oui oui TAB. 2.1 Résumé des pouvoirs d expression des formalismes sélectionnés Ces formalismes ne répondent cependant pas tous à tous les critères. Par exemple, les réseaux de Petri temporels offrent une bonne gestion du temps, mais ne permettent pas la gestion des données, 75

76 tandis que SDL possède les avantage et inconvénient inverses. Ces deux formalismes ont été retenus dans l idée de leur association pour une modélisation de l architecture TTA à deux niveaux. Ils pourront ainsi se compléter et permettre la modélisation et la validation du système global. La faisabilité de cette association pour la modélisation de l architecture TTA est étudiée dans [GAM03a], qui montre que la décomposition de l architecture TTA en deux sous-systèmes (le niveau hôte et le niveau communication) correspond à des caractéristiques de modélisation différentes. La méthode proposée associe chacun des formalismes à un des sous-systèmes (SDL pour le niveau hôte et les RdPT pour le niveau de communication) et montre la faisabilité de leur association dans le cadre de la validation de la borne temporelle d un service de TTA. Les autres formalismes (IF, les TSA et les automates hybrides) semblent par contre pouvoir représenter toute l architecture TTA. Cette étape de comparaison ne suffit cependant pas, le pouvoir d analyse s opposant souvent au pouvoir d expression. En effet, la grande expressivité d un modèle entraîne une augmentation du nombre de ses comportements possibles et donc de la complexité de son processus de validation. De plus, le choix entre temps discret et temps continu n est à ce stade pas encore évident. Ces deux considérations du temps peuvent avoir un impact sur le processus d analyse des propriétés temporelles. La notion de temps discret pose des problèmes pour la modélisation de certains systèmes temps réel, dans lesquels les événements ne se produisent pas forcément à des instants à valeurs entières. Il est alors nécessaire de fixer a priori une échelle de temps adaptée, ce qui limite souvent la précision de la modélisation et peut conduire à des problèmes dans l analyse. En effet, [Alu91] montre que fixer la granularité des instants temporels a priori entraîne la possibilité, dans un processus de model checking, d exclure des états accessibles, ce qui est difficilement acceptable dans le cadre de systèmes temps réel critiques. La seconde considération du temps, le temps continu, est par contre parfaitement adaptée à la modélisation et l analyse des systèmes temps réel. Elle entraîne cependant une plus grande complexité de l analyse par l augmentation de l espace d états du système. En effet, la considération du temps continu entraîne a priori un espace d états infini, tandis que le nombre de dates à considérer dans un système discret est dénombrable et aisément fini. Il faudra alors utiliser des techniques d analyse spécifiques afin de pouvoir gérer cette particularité, ce qui complexifie le processus de vérification des propriétés sur l espace d états du système. Notre travail se situe dans le contexte d une expérimentation réelle de validation, ne se limitant pas à une étude théorique mais devant également fournir des résultats concrets de validation de TTA. Dans ce cadre, une étude pratique est nécessaire afin de déterminer la faisabilité de la validation avec le formalisme choisi. Par exemple, les besoins de fiabilité des systèmes étudiés incitent à considérer le temps continu, mais l obligation de résultats oblige à considérer également la complexité des analyses. Ainsi, le choix du formalisme de modélisation ne dépend pas seulement de son pouvoir d expression théorique, mais également de son pouvoir d analyse et des outils disponibles pour la réalisation effective du modèle et de sa validation. L étude théorique effectuée dans cette section a donc été complétée par une étude pratique et théorique de l efficacité des outils de validation associés aux différents formalismes. 2.2 Méthodes d analyse Toutes les méthodes d analyse considérées ici sont basées sur la construction d un graphe représentant l espace des états possibles du système. La validation des propriétés consiste ensuite à parcourir le graphe afin de les vérifier sur chacun des états. Le model checking est la construction du graphe d états et la vérification automatique de propriétés exprimées en logique temporelle. L étude proposée dans cette section a pour but d effectuer une comparaison théorique des différentes méthodes d analyse associées aux formalismes sélectionnés. Trois méthodes seront donc étudiées : le graphe des classes [BD91, Ber83, Ber01], le graphe des régions [AD94] et le graphe de simulation en temps discret. Ces méthodes sont traditionnellement associées respectivement aux réseaux de Petri temporels, aux automates temporisés et aux formalismes en temps discret, ici IF et SDL. Il est cependant 76

77 possible d appliquer le graphe des régions sur les RdPT (cf section 2.4). Cette section décrit ces trois méthodes et les compare sur le plan théorique Graphe des classes d états La méthode des classes d états permet de représenter l ensemble des comportements temporels du système. Elle permet ainsi une analyse d accessibilité du réseau. L état d un réseau de Petri temporel peut être défini comme une paire " où est le marquage du réseau et est le domaine de tir, c est-à-dire un ensemble d intervalles de tir pour toutes les transitions sensibilisées correspondant au marquage. est donc représenté par un ensemble de contraintes temporelles sur les temporisations locales aux transitions. Un nouvel état est généré par le tir d une transition à une date comprise dans son intervalle de tir. Cependant, la représentation du temps dans les RdPT étant continue, une transition peut être tirée à tout instant de cet intervalle. Un état admet ainsi une infinité de successeurs et la construction du graphe des états du système est impossible. P 1 P 2 T 3 T 1 T 2 [ 1; 3 ] [ 4; 9 ] [ 0; 2 ] P 3 P 4 FIG. 2.6 Exemple de RdP, version simplifiée de [Ber01] Un exemple est donné pour la construction du graphe d états du modèle de l exemple de la figure 2.6. La figure 2.7 montre le début de la construction du graphe d état : Le premier état correspond à l état initial ; les places et sont marquées et seule la transition est sensibilisée, avec pour intervalle de tir. le tir de cette transition à une date génère un nouvel état. La construction de cet état ne pose pas de problème car aucune transition de l état ne reste sensibilisée, il n y a donc pas de problème de gestion du temps. Les intervalles de tir des transitions nouvellement sensibilisées constituent le domaine de tir de l état et la date de tir n a aucune influence. le tir de la transition à la date à partir de l état illustre par contre le problème. En effet, le nouvel état généré possède un domaine de tir dépendant de la date. Or peut prendre une infinité (non dénombrable) de valeurs dans l intervalle, ce qui génère une infinité de successeurs à l état. La méthode des classes d états permet une représentation de l espace d états. Elle permet un regroupement des états en classes d équivalence. Une classe d état est un couple ", avec le marquage (identique) de tous les états de et la réunion de tous les domaines de tirs des états de. Une nouvelle classe est générée à partir d une classe en sélectionnant une transition tirable dans et en calculant le nouveau marquage et les nouvelles contraintes temporelles impliquées par l intervalle de tir de cette transition. Une illustration peut être donnée en reprenant le modèle de la figure 2.6. Tout d abord les deux premières classes et sont respectivement identiques aux états et. La méthode des classes d états permet de représenter le tir de la transition à partir de la classe. Les différents domaines de tir possibles des successeurs de par sont regroupés en un domaine de tir équivalent maximal : l intervalle de tir devient donc. La classe d états équivalente aux états successeurs de par le tir de la transition est représentée sur la figure 2.7. Ce regroupement 77

78 E0 = C0 E1 = C1 m0={1, 1, 0, 0} tir de T1 m1={0, 0, 1, 1} dans [4, 9] D0 : solution de D1 : solution de 4 < T1 < 9 0 < T2 < 2 1 < T3 < 3 C2 tir de T2 à la date t dans [0, 2] 2 E2 m2={0, 1, 1, 0} D2 : solution de 0 < T3 < 3 classe d équivalence m2={0, 1, 1, 0} D2 : solution de max(0, 1 t 2) < T3 < 3 t2 FIG. 2.7 Construction du graphe d état de l exemple de la figure 2.6 conserve les traces d exécution maximales et donc les propriétés de contraintes temporelles pourront être validées sur le graphe des classes d états Graphe des régions Le graphe des régions permet la représentation de l espace d états des automates temporisés. Ce formalisme gère comme les RdPT le temps de façon continue, il est donc confronté au même problème d infinité de successeurs sur le plan temporel. Cette méthode est cependant différente du graphe des classes car elle se base sur un nombre fixe d horloges. En effet, dans les automates temporisés, le nombre d horloges est déclaré statiquement dans le système, alors que dans les RdPT une horloge est générée dynamiquement lors de la sensibilisation de chaque transition. Avec un nombre d horloges fixe, il est possible de considérer à partir du graphe des classes des relations d inclusion entre les états et d utiliser ces relations pour construire un graphe optimisé : le graphe des régions. L idée repose sur la fusion de tous les états dont la partie temporelle (c est-à-dire de l ensemble des valeurs de ses horloges) peut être " un état du système modélisé par un automate temporisé, incluse dans celle d un autre. Ainsi, soit avec l état de l automate et l ensemble des contraintes temporelles sur les horloges du modèle. Un nouvel état " ne sera pas ajouté si et. Cette optimisation fournit un graphe représentant une surestimation des chemins d exécution possibles ([Boy01]), c est-à-dire que tous les chemins du graphe ne sont pas réellement le reflet d un comportement possible du système. Par contre, une propriété qui n est pas vérifiée dans un tel graphe sera garantie de ne jamais être vérifiée dans le système. Le graphe des régions permet ainsi de gérer les ensembles de contraintes sur les horloges qui sont la partie temporelle des états du système. A partir d un système de contraintes, une relation d équivalence [AD94] permet de générer un nombre fini de régions. Ces régions permettent de déterminer sur le plan temporel les différents états successeurs possibles d un état donné (lors de la construction du graphe d états). Soit un ensemble de contraintes de la forme :,, avec l ensemble 78

79 segment ouvert : x=1 y>0 y point fixe : x=1 y=1 région ouverte : x>2 y> x FIG. 2.8 Régions d un système de contraintes - [AD94] des horloges de l automate et donc et les bornes minimale et maximale de l horloge. Les régions constituent l ensemble des solutions de ce système de contraintes. Le nombre de régions dépend de la valeur maximale des bornes des contraintes sur les horloges. La figure 2.8 permet une illustration à partir d un exemple : elle donne les régions d un ensemble de contraintes sur deux horloges et, avec et. Il existe dans ce cas 28 régions : 6 points fixes, 14 segments et 8 régions ouvertes. Un exemple de chacun de ces trois types de régions est donné sur la figure. Ainsi, un état possédant ces contraintes temporelles sur ces deux horloges et pourra théoriquement posséder 28 successeurs, associés aux 28 régions Graphe de simulation en temps discret : LTS La représentation de l espace des états du système dans SDL ou IF est différente des deux méthodes décrites précédemment de par la considération du temps discret. Un exemple de gestion du temps discret est donné figure 2.9 sur un exemple simple. Soit un système composé de processus ( à ). Chaque ligne verticale sur la figure représente un état du système, c est-à-dire les informations concernant l état de chacun des processus, la valeur de leurs variables et les informations concernant le temps. Les variables ne seront pas représentées ici pour simplifier l exemple. Le temps doit être considéré de deux façons : d une part, le temps d exécution global du système qui représente le temps universel. L espace d état du système est construit en analysant le comportement possible du modèle pas à pas, à chaque unité de temps de ce modèle. D autre part, le temps représenté par les horloges et les attributs du modèle est utilisé pour la représentation des contraintes temporelles du système. Ainsi, à un instant du temps de simulation, l évolution possible du système est définie par ces contraintes. Dans la figure 2.9, le premier état du système correspond à tous les états initiaux des processus et le temps de simulation est nul. La transition du processus est alors possible, ce qui génère un nouvel état du système. Le temps de simulation est cependant toujours nul, les transitions étant instantanées. De même, une transition est tirée qui génère un nouvel état. Puis aucune transition n est tirable à cet instant et le temps de simulation du système peut évoluer de unités de temps jusqu à ce qu une nouvelle transition soit tirable. Le temps de simulation est alors égal à. Puis l analyse du comportement du système continue de la même manière : la transition peut être tirée, qui génère un nouvel état du système. La construction du graphe d états du système conduit à la construction d un graphe de transition étiqueté (LTS - Labelled Transition System) [And94]. Il s effectue pas à pas, pour chaque unité de temps. Les 79

80 temps = 0 temps = δ1 temps = + S0 S1 S2 S3 S4 S5 δ 1 δ 2 P 1 t 1 P 2 P 3... P k t 2 δ 1 2 t 3 δ FIG. 2.9 Gestion du temps discret d exécution du système, [BGMO04] sommets de ce graphe sont les états du système et les arcs les transitions possibles entre ces états. Les transitions entre les différents états du système peuvent être de deux types : soit des actions ( sur la figure), exécutées en temps simultané, soit des délais ( ), c est-à-dire que deux états du système sont alors différenciés par la valeur du temps global d exécution du système. Par exemple sur la figure 2.9, l état a été généré par le tir de la transition à partir de l état. Ces deux états possèdent le même ensemble d états d automates et les mêmes valeurs de variables, mais sont différenciés par la valeur du temps global qui vaut en et en. L exemple de la figure 2.9 pourra ainsi être représenté par une suite linéaire d états. L exemple de cette figure est un exemple simple d exécution séquentielle. L introduction du parallélisme et donc de l entrelacement des transitions (cf section 3.3.1), ainsi que la gestion des valeurs des variables, sont souvent la source d une multiplication des états et des chemins d exécution du graphe. La représentation du temps discret entraîne cependant une représentation finie du nombre de successeurs d un état donné, au contraire de la représentation continue, comme expliqué dans la section En effet, le tir d une transition dans un intervalle donné ne pourra s effectuer que sur tous les instants entiers de cet intervalle, ce qui génère un nombre fini d instants possibles du tir de cette transition Complexité et comparaison théorique La complexité d une méthode d analyse se rapporte à deux composantes : la complexité temporelle, c est-à-dire le temps d exécution de l analyse et la complexité mémoire, c est-à-dire la taille mémoire nécessaire à cette analyse. Dans notre contexte, la taille mémoire représente principalement la place mémoire nécessaire pour le stockage du graphe représentant l espace d états du système. Cette composante dépend de deux paramètres : la taille mémoire d un état donné et le nombre total d états à stocker. Le temps d exécution représente le temps nécessaire au calcul de ce graphe d états, plus le temps nécessaire à la vérification des propriétés sur ce graphe. Cette complexité temporelle dépend bien sûr du nombre d états générés, mais aussi de la complexité de calcul des différentes opérations élémentaires effectuées par l algorithme d analyse sur les états déjà stockés. Cette dernière complexité dépend en grande partie de la taille des états, ainsi que de leur implémentation. La complexité d une analyse est difficile à établir d une façon précise. Bien que l étude théorique des méthodes d analyse permette de déterminer globalement les paramètres influant sur la complexité, 80

81 les algorithmes d analyse de base sont souvent complétés par l implémentation d un certain nombre d optimisations locales ou globales dont la complexité est difficilement évaluable. De plus, la plupart de ces optimisations sont basées sur la nature du modèle analysé. Par exemple, une optimisation permettant la suppression des entrelacements ne sera efficace que sur un système fortement parallèle, c est-à-dire contenant de nombreux entrelacements. De plus, l expression de la complexité dans le pire cas est rarement réaliste par rapport aux modèles rencontrés. Il est donc impossible a priori d établir une complexité générique et réaliste. Il est cependant possible de comparer globalement les complexités des différentes méthodes d analyse en comparant théoriquement leur fonctionnement. Par exemple, une première comparaison peut être faite entre le graphe des classes et le graphe des régions. En effet, ce dernier est une abstraction du graphe des classes. Il permet par définition une réduction du nombre d états du système, en ne représentant explicitement qu un seul état pour tous les états possédant un sous-ensemble de sa représentation temporelle. L efficacité de cette abstraction dépend de la structure du modèle analysé, mais le graphe des régions génèrera dans le pire cas (aucune inclusion possible) le même nombre d états que le graphe des classes. La réduction du nombre d états permet une réduction de la complexité mémoire comme temporelle, le graphe des régions sera donc plus efficace. Un autre paramètre déterminant dans la complexité de ces méthodes d analyse est l expression du comportement temporel, c est-à-dire le nombre d horloges et la complexité des contraintes temporelles. Pour une représentation continue du temps, les deux formalismes RdPT et TSA proposent une gestion différente du comportement temporel : d une part les automates temporisés possèdent un nombre fixe d horloges globales ou locales et d autre part les RdPT associent une temporisation à chacune des transitions sensibilisées à un instant donné. La complexité temporelle des RdPT est donc très difficile à estimer, le nombre d horloges et donc de contraintes temporelles à un instant donné étant variable et dépendant du comportement antérieur du système. Il est très difficile de contrôler le nombre d horloges dans les RdPT, alors qu à l inverse, l expression explicite des horloges dans les TSA permet une plus grande contrôlabilité du comportement temporel par le concepteur du modèle. Enfin, la représentation discrète du temps entraîne une gestion différente de l analyse. La complexité ne se situe plus directement sur le comportement des horloges du système, mais sur celle de l horloge d exécution, qui représente le nombre d étapes temporelles nécessaires à la construction du graphe d états. La comparaison théorique de la complexité de ces deux méthodes de représentation est un problème qui reste ouvert et qui pourra être complété par des études expérimentales de la validation d un même système. 2.3 Expérimentation des automates hybrides linéaires avec HyTech La validation d un système modélisé en automates hybrides peut s effectuer par model-checking comme par exemple dans l outil HyTech [HHWT95, HHWT97]. HyTech permet ainsi la vérification de propriétés d accessibilité exprimées sur les éléments du modèle. Cet outil permet également d effectuer des analyses paramétrées : il permet d extraire toutes les valeurs possibles d un paramètre remplissant une condition. Par exemple, il est possible d extraire les valeurs d un paramètre qui permettent d atteindre un état donné du système. Cet outil est l un des outils d analyse des systèmes hybrides le plus connu, et l un des seuls qui permettent l analyse exhaustive des états du système couplée à une analyse paramètrée. HyTech se limite à l analyse des automates hybrides linéaires (les dérivées des variables continues sont des constantes) tandis que les outils HyperTech (extension de HyTech) [HHMWT00] ou d/dt [DAN00] permettent la validation d automates hybrides à équations différentielles, plus complexes. Les automates hybrides linéaires sont suffisamment expressifs dans notre contexte, notre choix s est donc porté pour la validation temporelle de TTA sur l outil HyTech. Les automates hybrides linéaires offrent deux caractéristiques très attirantes dans notre contexte : leur richesse de modélisation permet une représentation aisée des horloges de TTA, et l analyse paramétrée 81

82 de l outil HyTech permettrait d extraire directement les bornes temporelles des services que l on désire valider. Cependant, cette richesse de la modélisation et de l analyse est obligatoirement accompagnée d une augmentation de la complexité du processus de validation. Le graphe d états du système est basé sur le graphe des régions. Les régions sont représentées par un ensemble de contraintes sur l ensemble des variables continues : horloges et chronomètres mais aussi les variables analog dont le comportement temporel est plus riche. Ces contraintes sont donc plus complexes à calculer, et le nombre de régions (et donc d états) du graphe plus important. De même, l analyse paramétrée oblige la considération de tous les états possibles pour toutes les valeurs possibles des paramètres, ce qui augmente également le nombre d états du graphe. Ces automates et l outil HyTech ont déjà été utilisés pour la validation de différents systèmes par la vérification de contraintes temporelles [HWT96, TOM97, Tom98, BF99]. Cependant, les cas d application de la validation de systèmes réels concernent des systèmes peu complexes ou qui ont été simplifiés afin de pouvoir éviter l explosion combinatoire. L architecture TTA est un système plus complexe qui risque d atteindre les limites de ce formalisme. Une mise en œuvre expérimentale a donc été effectuée afin de vérifier la possibilité de l utilisation de HyTech et des automates hybrides linéaires dans notre contexte. Un premier modèle de l architecture TTA a été conçu, composé de 3 contrôleurs. Les bus guardians ainsi que les niveaux application et FTlayer n ont pas été modélisés (et donc l ordonnancement des tâches non plus). L ordonnancement des messages se répartit en 2 rounds et 3 slots. Un service simple a été représenté dans les contrôleurs : la réintégration. Le modèle se compose donc également d un automate générateur de fautes et permettant la vérification de la borne temporelle de ce service. Cependant, l analyse de ce modèle atteint les limites de l outil HyTech : le processus d analyse ne se termine pas. L architecture TTA est donc trop complexe pour ce formalisme et cet outil. L outil HyTech et les automates hybrides sont plus appropriés pour des systèmes réellement hybrides, et non pour des systèmes dont les seules représentations continues sont les horloges [HHWT97]. La complexité de notre système se situe exclusivement dans la gestion du temps et des variables discrètes. Il a donc été nécessaire de s orienter vers des formalismes plus spécifiques et plus adaptés. 2.4 Comparaison de deux méthodes : UPPAAL vs SDL+RdPT La section 2.2 propose une étude théorique des méthodes d analyse traditionnelles. Cette étude s est cependant effectuée indépendamment des différentes optimisations pouvant être intégrées dans les outils d analyse. Or ces optimisations peuvent influencer la complexité de l analyse sur le plan pratique. Les analyses théoriques doivent donc être complétées par une comparaison expérimentale. Une première étude pratique a permis d exclure les automates hybrides linéaires des formalismes possibles. Cette section présente une autre étude permettant la comparaison de deux autres formalismes : les TSA et les réseaux de Petri temporels Choix des outils d analyse Une étude expérimentale des formalismes et de leur méthode d analyse débute invariablement par le choix d un outil de validation. Il existe de nombreux outils, développés par des universités ou des entreprises spécialisées et il est difficile de tous les connaître. Les critères de sélection retenus dans le choix des outils utilisés pour cette thèse sont la performance de l analyse, les possibilités de validation, la disponibilité de l outil. La sélection de l outil de modélisation pour le formalisme IF peut paraître évidente, étant donné que cet outil est directement associé à un environnement de même nom, IF [BFG 00]. Cet environnement est cependant un ensemble de multiples outils différents, d utilisations diverses (test, génération de code, validation). IF est un format intermédiaire conçu pour permettre la connexion de ces différents outils sur un même modèle initial du système cible. L outil utilisé ici est EVALUATOR, outil de l environnement 82

83 de validation CADP 3 dédié à la validation formelle temporelle et pouvant fonctionner sur un modèle IF. C est un model checker permettant la vérification de propriétés complexes exprimées en logique temporelle [JHA 96]. Le choix de l outil associé aux TSA s est porté sur UPPAAL 4 [LPY97], outil développé conjointement par les universités d Uppsala (Suède) et d Aalborg (Danemark). UPPAAL est un outil de modélisation et de vérification des systèmes temps réel complets, c est-à-dire que la méthode d analyse est intégrée à l outil. Cet outil semble adapté pour plusieurs raisons. Tout d abord, la possibilité de son utilisation pour la validation temporelle de systèmes réels a déjà été prouvée [DY00, JLS96, LP97]. De plus, son implémentation repose sur un groupe de recherche actif et a beaucoup évolué durant ces dernières années. Enfin, c est un outil public, facile d accès et complété du point de vue théorique par de nombreuses publications. Il offre également une relative facilité d utilisation, de par une interface graphique riche et surtout la modularité intrinsèque des TSA. Enfin, UPPAAL permet la vérification d un grand nombre de propriétés exprimées en logiques temporelles, y compris des propriétés de vivacité du système. Le cas du formalisme SDL est plus simple : ce formalisme est déjà largement utilisé dans l industrie, des outils performants sont fournis par la société Télélogic. L outil ObjectGeode, [Tel04], dédié à la conception et à la validation de systèmes temps réel distribués, semblait idéal dans notre contexte. Cet outil permet la vérification par simulation, partielle ou exhaustive, de propriétés comportementales du système. Le type de propriétés vérifiables est très large, mais ne concerne pas les propriétés de vivacité. Il est par contre possible de vérifier des propriétés d accessibilité d un état du modèle. Enfin, les outils associés aux réseaux de Petri temporels sont relativement nombreux et se limitent souvent à la génération du graphe de représentation de l espace d états, sans implémenter d analyses supplémentaires. Un outil cependant est en train d évoluer dans cette voie : l outil Romeo 5, développé au sein de l équipe Systèmes Temps-Réel de l IRCCYN. Cet outil permet la modélisation en réseaux de Petri, ainsi que deux méthodes d analyse du modèle, basées sur une construction différente du graphe représentant l espace des états du système. A partir de ce graphe, il propose la vérification de propriétés simples de marquage du modèle et donc d accessibilité d une place. Il permet également une représentation des classes d états et du graphe de marquage en automates temporisés. La disponibilité de ces différents graphes peut permettre la vérification de propriétés temporelles plus poussées Comparaison expérimentale Nous avons réalisé une première étude sur la comparaison des pouvoirs d analyse de deux méthodes appliquées à la validation temporelle de l architecture TTA. Ce premier choix a été orienté par la tentative d utilisation du temps continu, motivée par le but de modéliser les effets de la désynchronisation (cf section 2.1.2). La première de ces méthodes consiste en l association de deux formalismes complémentaires : SDL et les réseaux de Petri temporels. Nous avons démontré la faisabilité de cette approche et montré les résultats obtenus dans [GAM03a, GAM03b]. En effet, la décomposition de l architecture TTA en deux sous-sytèmes hôte et de communication permet d extraire deux orientations majeures des besoins de modélisation. D une part le sous-système hôte (Application + OS + FT layer) nécessite principalement l expression des données applicatives et des traitements, tandis que d autre part la modélisation du soussystème de communication (protocole TTP/C et bus de transmission) nécessite une représentation fine et quantitative du temps et des contraintes temporelles. Cette décomposition, associée à l analyse des pouvoirs d expression des formalismes (section 2.1), offre une première idée de modélisation de l architecture TTA, en associant SDL au niveau hôte et les RdPT au niveau de communication. 3 http :// 4 wwwuppaal.com

84 La deuxième méthode consiste en l utilisation de l outil UPPAAL, c est-à-dire du formalisme TSA et du model-checker implémenté dans l outil. Cette section propose une étude théorique rapide de la complexité des différentes méthodes d analyse, ainsi qu une comparaison pratique de la validation d une borne temporelle d un service de TTA. La comparaison expérimentale des deux approches a consisté en la modélisation du système TTA sous les mêmes hypothèses, afin d obtenir la modélisation du même comportement et de pouvoir vérifier les mêmes propriétés. Il est ainsi possible de considérer ces modélisations comme équivalentes. Les détails des modèles ne seront pas donnés ici, seuls les résultats seront expliqués. Pour plus de détails, se référer à [GAM04]. Nombre A B C Scénario 3 SRU, 3 slots par round, 2 rounds par cycle 4 SRU, 4 slots par round, 3 rounds par cycle 5 SRU, 5 slots par round, 2 rounds par cycle TAB. 2.2 Scénarios de base significatifs des expériences La vérification de la borne temporelle du service de TTA, c est-à-dire son pire temps d exécution, est ici effectuée par l intermédiaire d un observateur (cf section 3.1.2) qui permet de transformer la vérification de cette propriété de vivacité par une vérification d accessibilité. Les résultats donnés sont ceux obtenus lorsque la propriété n est pas vérifiée, c est-à-dire que la validation a entraîné le parcours de tout l espace des états du système. Cette vérification est effectuée automatiquement par l outil sélectionné, la vérification d accessibilité étant possible dans les trois outils : Romeo, ObjectGEODE et UPPAAL. La validation a été effectuée sur plusieurs versions de modèles du système, avec différents nombres de nœuds et différents MEDL. Le tableau 2.2 donne trois exemples de scénarios, dont les résultats des mesures de performances seront significatifs pour l explication et la comparaison des méthodes d analyse. Résultats RdPT L outil Romeo permet la construction du graphe des classes du système sous différents formats. Ce graphe pourra alors être utilisé par des outils de vérifications automatiques de propriétés. Romeo permet également la vérification automatique de propriétés de marquages sur un graphe des marquages temporisés calculés à partir de la méthode de graphe de régions. Cette vérification s effectue à la volée, c est-à-dire que la propriété est vérifiée au fur et à mesure de la construction du graphe. Le graphe des régions est calculé à partir d une traduction automatique du modèle RdPT en un automate temporisé. Les tableaux 2.3 et 2.4 donnent les résultats de mesures de performances pour la validation des trois scénarios du tableau 2.2. Les colonnes Taille des modèles RdPT du premier tableau donnent la taille du modèle du système pour le scénario donné (ces valeurs sont les mêmes quelle que soit la méthode d analyse utilisée). Le premier tableau donne également la taille du graphe des classes obtenu (colonnes Taille du graphe), puis dans les deux dernières colonnes le temps CPU et la consommation mémoire utilisés par le processus de validation. Le deuxième tableau donne ces mêmes résultats, mais pour une validation obtenue avec le graphe des régions, représenté sous la forme d un automate temporisé appelé AT des marquages. Ces valeurs sont celles obtenues avec la version de l outil Romeo. La nouvelle version semble plus rapide, mais ne résoud toujours pas le problème de l explosion combinatoire pour le système TTA. Un élément à considérer est la complexité de la modélisation d un gros système en RdPT. Ce formalisme n offre en effet aucune possiblité de modularité ou de hiérarchie et la conception de modèle complexe est difficile. Une analyse des résultats des différentes expériences effectuées pour l analyse d un modèle du niveau de communication de TTA montre : 84

85 que l utilisation des RdPT pour la vérification d une borne temporelle du niveau communication de TTA est une méthode effectivement faisable sur le plan théorique. La vérification de la borne temporelle est réalisable sur un modèle simple (scénario A) avec une consommation mémoire raisonnable (ligne 1 des deux tableaux 2.3 et 2.4). que la construction du graphe des classes d états explose rapidement. Un modèle un peu complexe (scénario C), mais tout de même largement réaliste dans le cadre étudié (5 SRU) entraîne l explosion de l analyse. Cette explosion est due à la trop grande utilisation mémoire nécessaire. Bien que l ordinateur utilisé n ait pas une grosse capacité mémoire ( ), l évolution de la consommation mémoire pour la construction du graphe des classes d états (tableau 2.3) comporte sans aucun doute un facteur exponentiel qui rend impossible l utilisation de cette méthode des graphes des classes à plus grande échelle. que la méthode de l analyse du graphe des marquages, basée sur la construction du graphe des régions est également limitée même si elle est plus efficace que celle du graphe des classes. En effet, le facteur exponentiel se retrouve rapidement dans le tableau 2.4 et le scénario C correspond à la limite de cette analyse. Scénario Taille des modèles RdPT Taille du graphe Temps CPU Mémoire Transitions Places Arcs Classes Transitions (secondes) (KB) A B C TAB. 2.3 Résultats de la construction du graphe des classes, avec Romeo et les RdPT Scénario Taille des modèles RdPT Taille de l AT des marquages Temps CPU Mémoire Transitions Places Arcs Etats Transitions Horloges (secondes) (KB) A K B C TAB. 2.4 Résultats de la construction du graphe des régions, avec Romeo et les RdPT Conclusion RdPT Les réseaux de Petri temporels et la méthode de graphe des classes implémentée dans l outil Romeo semblent donc atteindre rapidement leurs limites dans le cadre de la modélisation et de la validation de TTA. En effet, dans un premier temps la construction du graphe d états explose très rapidement, ce qui semble confirmer l analyse théorique de la complexité de cette méthode. Le système TTA est en effet largement parallèle, provoquant de nombreux entrelacements. Cette caractéristique vient de la représentation d une horloge globale et de l ordonnancement TDMA : par exemple, tous les nœuds reçoivent la trame émise au même instant. Les actions de réception d un message de tous les nœuds sont donc parallèles. Par ailleurs, la méthode du graphe des régions, théoriquement plus efficace, entraîne également une explosion combinatoire à cause de la complexité du modèle qu elle analyse. En effet, le graphe des régions est calculé sur un modèle en automates temporisés issu de la traduction automatique du modèle RdPT. Or cette traduction génère un modèle constitué d un automate associé à une horloge pour chaque transition du modèle RdPT. Les modèles analysés comporteront ainsi entre 46 et 90 horloges. Bien que ces transitions ne soient pas toutes sensibilisées en même temps et donc que le nombre effectif de contraintes temporelles ne soit pas aussi élevé, ce nombre risque tout de même d être très important. En 85

86 considérant la complexité théorique du graphe des régions, largement dépendante du nombre d horloges du système, l explosion combinatoire s explique aisément. Enfin, une dernière explication provient du formalisme lui-même : la modélisation d un système complexe en RdPT entraîne obligatoirement un modèle de grande taille. Par exemple, la taille du modèle a quasiment doublé entre les scénarios A et C, alors que cette augmentation ne correspond qu à l ajout de deux SRU. Ce formalisme n offre donc pas un niveau d abstraction suffisant pour la représentation de systèmes de grande taille. Résultats SDL La modélisation en SDL concerne le sous-système hôte de TTA. L interface avec le niveau de communication s effectue par l intégration de bornes temporelles, extraites de la validation en RdPT et qui reflètent le comportement temporel des couches inférieures. Cette méthode est basée sur l indépendance relative des deux sous-systèmes dans TTA (comportement déterministe, pas de signaux de contrôle...). Bien que la plupart des services de TTA ne soient implémentés qu au niveau du protocole TTP/C, certains peuvent être également validés au niveau applicatif. Ce processus de validation de propriétés temporelles sur un modèle SDL est effectué avec l outil ObjectGEODE. Cet outil permet une vérification de propriétés par simulation du modèle. Cette vérification est basée sur la construction d un graphe de simulation reflétant les états du système et par la vérification à la volée des propriétés. L option de simulation exhaustive permet une validation formelle. Conclusion SDL Les expériences de validation effectuées sur les mêmes scénarios que précédemment ont vite démontré que cet outil était peu adapté à la validation de propriétés temporelles. En effet, la simulation exhaustive du scénario le plus simple (scénario A du tableau 2.2) est déjà soumise à l explosion combinatoire et à l arrêt du processus d analyse dû au manque d espace mémoire, après la génération de plus de états. Ce résultat est peu surprenant, du fait de la richesse du pouvoir d expression de SDL. La richesse des informations modélisées est inversement proportionnelle à la taille de l espace d états du système. En particulier, SDL ne possède pas une facilité intrinsèque de gestion du temps [BGK 00]. Ce formalisme est principalement dédié à la spécification et à la conception de systèmes, plus qu à leur validation formelle. Les méthodes d analyses développées et implémentées de manière efficace pour ce formalisme sont donc principalement des méthodes de détection d erreurs de conception, par test et simulation, qui n effectuent pas un parcours exhaustif de l espace d états du graphe. Résultats UPPAAL L outil UPPAAL a été utilisé pour la modélisation et la validation de l architecture complète. La vérification des propriétés est effectuée à la volée, parallèlement à la construction du graphe de représentation de l espace d états. Basée sur le graphe des régions, la méthode d analyse implémentée dans UP- PAAL est en réalité beaucoup plus complexe. Tout d abord le processus d analyse utilise des zones, qui sont une représentation symbolique de l union de plusieurs régions (cf section 3.1.3). Ensuite, de nombreuses possibilités d optimisation ont été implémentées. En particulier, plusieurs implémentations différentes des structures de stockage des états sont proposées, ce qui modifie la complexité de l analyse. La méthode de représentation en zone, l algorithme de model checking symbolique et les différentes représentations des structures de données de stockages des états implémentés dans UPPAAL sont décrits plus en détail dans la section 3.1 suivante. La plupart de ces possibilités d optimisation sont utilisables dans l outil de façon optionnelle. En effet, l efficacité des différentes optimisations est très largement dépendante de la nature du modèle analysé. L utilisation d une méthode plutôt qu une autre reste donc le choix de l utilisateur. Les résultats de mesures de performances donnés dans le tableau 2.5 sont ceux effectués pour la validation des propriétés sur le modèle de l architecture complète. Ces résultats ont été obtenus avec 86

87 les options par défaut de l outil, c est-à-dire sans l activation de la plupart des options d optimisation. Les informations précises sur le graphe de représentation de l espace d états du système ne sont pas disponibles, il est cependant possible de déterminer, comme pour les autres outils, l utilisation mémoire du processus d analyse. La mémoire utilisée pendant l analyse correspondant principalement au stockage des états du système, cela permet d estimer la taille de ce graphe et de comparer avec les autres techniques de validation. Le tableau 2.5 montre que les expériences de validation effectuées sur les mêmes scénarios que ceux provoquant l explosion combinatoire des autres méthodes n explosent pas dans UPPAAL. Au contraire, le temps d analyse reste inférieur à et l espace mémoire utilisé n atteint pas les. L outil UPPAAL semble loin de ses limites en terme de capacité d analyse. Scénario Taille des modèles UPPAAL Time Memory Automates Horloges Etats Transitions (secondes) (KB) A B C TAB. 2.5 Résultats de la vérification des propriétés dans UPPAAL Conclusion UPPAAL Les très bons résultats de l outil UPPAAL peuvent s expliquer d une part par les optimisations implémentées, bien que toutes les possibilités d optimisations de l outil n aient pas été exploitées. Mais la taille des modèles, en particulier leur nombre d horloges, explique également ces performances. En effet la complexité théorique de l analyse, basée sur le graphe des régions, dépend forcément du nombre d horloges du modèle. De plus, la complexification des scénarios n entraine pas comme en RdPT une explosion rapide de la taille du modèle. L outil UPPAAL est donc beaucoup plus efficace que l association RdPT+SDL dans le cadre de la validation temporelle de l architecture TTA. En allant plus loin, il semble même que l outil UPPAAL soit très bien adapté à ce contexte, les limites de l outil étant loin d être atteintes lors des expériences effectuées. Les modèles utilisés ici restent cependant des modèles simples. Ils représentent en effet le comportement du système en fonctionnement normal, c est-à-dire sans occurrence de fautes. L introduction de ces fautes entraîne un nombre de nouveaux états possibles très important qui risque de provoquer une explosion de l analyse. Une étude plus poussée de l outil est donc nécessaire, en particulier de sa méthode d analyse, des optimisations implémentées et des structures de données disponibles. Ces optimisations ne sont cependant pas toujours efficaces, ni nécessaires, pour la validation de certains systèmes. Il est alors intéressant d intégrer des abstractions directement au niveau de la modélisation, afin de permettre une baisse de la complexité de l analyse. La section 3.1 suivante introduit une étude des abstractions applicables dans notre contexte. 87

88 Chapitre 3 Optimisation de l analyse de TTA avec UPPAAL : abstractions La section précédente a montré de façon théorique et expérimentale que les automates temporisés étendus associés à la méthode de model checking symbolique et implémentés dans l outil UPPAAL semblent être la meilleure solution pour la modélisation et la validation temporelle des services de TTA. Ce choix a été effectué suite à l étude des pouvoirs d expression et d analyse des différents formalismes disponibles, ainsi que sur des expérimentations ayant permis de tester et de comparer certaines solutions. La technique d analyse de l outil UPPAAL, le model checking, est basée sur la construction de l espace des états accessibles du système. Cela provoque donc inévitablement des problèmes d explosion combinatoire pour les systèmes réels et donc intrinsèquement complexes, en particulier pour la validation en présence de fautes. Une analyse de ces systèmes passe donc inévitablement par l application de techniques d optimisations permettant de réduire cette complexité. Ces optimisations sont cependant des mécanismes automatiques qui, par nature, sont souvent trop génériques pour être réellement efficaces pour tous les systèmes modélisés. De plus, certaines abstractions peuvent être appliquées au modèle en se basant sur des hypothèses très spécifiques. Ces abstractions, qui peuvent entraîner une nette diminution de la complexité de l analyse, ne peuvent être appliquées à un modèle qu en supposant une connaissance du modèle et de son comportement, c est-à-dire a priori par son concepteur. Cette section propose une étude plus détaillée des mécanismes d analyse et d optimisation implémentés dans UPPAAL, puis propose des abstractions pour l amélioration des performances du processus d analyse du modèle de TTA. Certaines pistes de formalisation de ces abstractions sont proposées. Puis sont donnés les résultats d une étude de l application d abstractions similaires, inspirées des mêmes concepts, sur le modèle d une architecture différente (CAN). 3.1 L outil UPPAAL : modélisation et validation Formalisme de modélisation Le formalisme de modélisation de l outil UPPAAL, les TSA, a déjà été décrit dans la section précédente (section 2.1.3). Il ne sera donc pas repris ici. Il est cependant important de préciser qu un modèle UPPAAL complet est un réseau de TSA communiquant par signaux synchronisés et partageant des variables globales. L interaction des différents automates est reflétée par leur composition parallèle (voir par exemple [ABL98]). La représentation de la composition parallèle de deux états est montrée figure 3.1. Un état du système représente l état du système à un instant donné. Pour un automate simple, cet état contient des informations sur l état dans lequel se trouve cet automate et la valeur de ses variables et de ses horloges. Il peut être représenté par un triplet ", avec son état, une fonction d attribution/assignement de ses variables et une fonction d assignement de ses horloges. A un instant donné, 88

89 E1 Etat : e1 Variables : v1 Horloges : h1 E (composition de E1 et E2) E2 Etat : e2 Variables : v2 Horloges : h2 Etat : e=(e1,e2) Variables : v=(v1,v2) Horloges : h=(h1,h2) partie discrète partie continue FIG. 3.1 Représentation de l état d un réseau de TSA l état résultant de la composition parallèle de deux automates E1 et E2, d états respectifs " et ", est un triplet " avec un vecteur d états dans lequel se trouvent les deux automates, une fonction d assignement des variables de E1 et E2 équivalente à et et une fonction d attribution de valeur aux horloges du système, équivalente à et. Ce triplet " peut se décomposer en deux parties : le couple " et la fonction, respectivement appelées la partie discrète et la partie continue de cet état du système Expression des propriétés Langage : sous-ensemble de TCTL La logique utilisée pour l expression des propriétés dans UPPAAL est un sous-ensemble de la logique TCTL (Timed Computation Tree Logic, [ACD93] [SBB 99]), logique temporelle permettant l expression du temps quantitatif. Les expressions élémentaires de cette logique sont le nom des états, des variables et des horloges du modèle du système. Les opérateurs de la logique TCTL sont directement exprimables en UPPAAL (voir tableau 3.1). Les formules logiques se réfèrent à un arbre de comportement du système. TCTL Description UPPAAL E il existe un chemin E A pour tous les chemins A G tous les états dans un chemin F au moins un état dans un chemin TAB. 3.1 Opérateurs de la logique d UPPAAL Cette logique permet, par la combinaison de ces opérateurs, l expression des propriétés de fiabilité : invariance et accessibilité, ainsi que des propriétés de vivacité. Les propriétés temporelles vérifiables par l outil UPPAAL sont illustrées dans la figure 3.2. Ces figures représentent schématiquement sous la forme d un arbre le graphe d états symboliques : les nœuds de l arbre sont les états symboliques (cf. section 3.1.3). Dans ces figures, les propriétés p et q sont des propriétés dites locales, associées et vérifiées sur un état symbolique du système, c est-à-dire à un instant donné. 89

90 équivalences : p >q A[ ] (p imply A<>q) A[] p p E<> p p imply q not p or q p p p >q p p p p A<> p E[] p p p q p p q p p p FIG. 3.2 Type de propriétés vérifiables dans l outil UPPAAL Expression des propriétés de temps maximal d exécution Dans notre contexte, la vérification de la borne temporelle des services de TTA est la vérification que le pire temps d exécution de ce service ne dépasse pas une valeur maximale. Cette propriété n est pas directement exprimable dans la logique temporelle de UPPAAL. Une solution pourrait être d utiliser la possibilité en UPPAAL de vérifier des propriétés de vivacité ( ). Une autre méthode, celle que nous utiliserons, consiste en la transformation de ce problème en vérification d accessibilité, en utilisant un automate de test, ou observateur ([JLS96], [ABL98]). Un observateur est un automate spécifique indépendant rajouté au modèle du système, adaptant la propriété de chien de garde (cf section 2.1.2). L alarme dans ce cas est représentée par l accès à un état spécifique erreur lorsque la valeur maximale est dépassée. Cet automate possède sa propre horloge, dédiée à la vérification du temps d exécution du service à valider. L utilisation d un automate observateur indépendant comporte plusieurs avantages. Tout d abord un tel automate est relativement simple à concevoir, [JLS96] en donne quelques règles de dérivation automatique. Ensuite, l indépendance de cet automate permet de ne modifier que très peu le modèle initial du système, ce qui est intéressant dans le cadre de la vérification de plusieurs propriétés du même modèle. Les figures 3.3 et 3.4 illustrent le principe utilisé dans notre méthodologie pour la vérification des services de TTA : la première montre l interaction de l automate observateur avec le reste du modèle et la seconde le modèle d un observateur simple utilisé dans notre méthodologie (modélisé avec UP- PAAL). A l instant de démarrage du service, un des automates du modèle global du système envoie le signal debut service à l automate Observateur. Celui-ci quitte alors l état Initial et passe dans l état Service, en initialisant son horloge x. Cet état comporte un invariant : x Borne, qui contraint l horloge x à ne pas dépasser la valeur Borne. Cette constante représente la borne maximale que ne doit pas dépasser le temps d exécution du service. L automate Observateur reste alors dans l état Service jusqu à la fin de l exécution du service, c est-à-dire la réception du signal fin service, ou jusqu à l atteinte de la valeur Borne. Si cette valeur est atteinte avant l instant de fin du service, l automate Observateur transite dans l état Erreur. C est l accessibilité de cet état Erreur qui sera vérifiée, dans le modèle issu de la composition parallèle du modèle initial du système et de l observateur. 90

91 Légende : modèle (réseau d automates) automate Modèle du système Observateur debut_service! fin_service! FIG. 3.3 Interaction de l automate observateur avec le modèle global Initial fin_service? Erreur debut_service? x==borne Service x<=borne FIG. 3.4 Modèle d un observateur 91

92 3.1.3 Méthode d analyse : le model checking symbolique L algorithme de model checking dans UPPAAL effectue la vérification des propriétés à la volée, en parallèle de la construction du graphe d états du système. Il permet la validation de la propriété ou dans le cas de sa violation, il génére un contre-exemple sous la forme d une trace simulable. Graphe d états : Zones et régions Le graphe de représentation de l espace des états du système dans UPPAAL est une interprétation symbolique du graphe des régions introduit dans [AD94] ou [ACD93] (cf section 2.2.2), appelé graphe des états symboliques. Le graphe d états du système est construit sur le principe de la méthode du graphe des régions, les contraintes des horloges dans ce graphe sont utilisées pour partitionner l évaluation des horloges en ensembles convexes : les régions. Le nombre de régions est cependant encore souvent trop important. Sa complexité dépend en effet du nombre d horloges et de la plus grande constante du système des contraintes représentées (cf [AD94] et section 2.2.4). Dans l outil UPPAAL, une nouvelle représentation des régions est donc utilisée : les zones ([Möl02], [BY04]), unions convexes de régions. Les zones sont une représentation efficace de l union des régions, qui permet en particulier l optimisation de certaines opérations élémentaires de l algorithme de model checking (décrit section suivante). Les états symboliques du graphe de représentation du comportement du modèle sont donc de la forme " avec un vecteur d états (des automates), une fonction d attribution de valeurs aux variables du modèle et Z une zone, c est-à-dire un ensemble de contraintes sur les horloges du système. Chaque état symbolique représente un ensemble d états ". La figure 3.5 schématise le concept d état symbolique pour un automate : un état de A est représenté à gauche de cette figure, par le triplet ", avec son état, la fonction d attribution de ses variables et celle de ses horloges, c est-à-dire ici. Un état symbolique de A est représenté à droite : ". est une zone, c est-à-dire un ensemble de contraintes sur les horloges et :. Cet état symbolique contient tous les états du système de vecteur d état, de fonction d attribution de variables et dont les valeurs d horloges sont incluses dans la zone. Etat Etat symbolique ( e; v; x=1,8; y=2,1 ) ( e; v; 1<x<3; 1<y<2,5 ) y y zone : conjonction de contraintes x x FIG. 3.5 Etat symbolique Algorithme d accessibilité L algorithme symbolique d accessibilité, donné dans [DBLY03, BY04] et dans la figure 3.6, est un algorithme de model checking symbolique permettant la vérification des propriétés exprimées en logique temporelle. Cet algorithme permet de construire le graphe d états symboliques du modèle. Il est basé sur 92

93 deux structures de données principales : les listes Waiting (les états symboliques à explorer) et Passed (les états symboliques déjà explorés et donc accessibles par une trace d exécution du modèle). 1. Waiting " 2. Passed 3. tant que Waiting faire 4. prendre " dans Waiting 5. Waiting Waiting " 6. si TestPropriété " alors retourner VRAI 7. si " Passed : alors 8. Passed Passed " 9. tant que " Successeur( " ) faire 10. si " Waiting : alors 11. Waiting Waiting ". finsi. fintantque. finsi. fintantque 12. retourner FAUX FIG. 3.6 L algorithme d accessibilité de UPPAAL - Source : [DBLY03, BY04] Cet algorithme est l algorithme de base de construction du graphe d états symbolique. Dans l outil UPPAAL, il n est cependant pas implémenté tel quel. Par exemple, la vérification d une propriété est effectuée à la volée, c est-à-dire au fur et à mesure. Ainsi, la propriété est vérifiée sur chaque nouvel état symbolique généré, afin d éviter la construction du graphe complet dans le cas de sa violation. De plus, plusieurs techniques ont été implémentées sur cet algorithme afin d optimiser les performances du processus de model checking, en particulier pour la consommation mémoire. Ces optimisations seront présentées dans la suite de ce chapitre. Dans l algorithme de la figure 3.6, un état symbolique est représenté par un couple ", avec la partie discrète de cet état ( " ) et la partie continue, c est-à-dire une zone représentant les contraintes temporelles sur ses horloges. Deux parties discrètes " et " seront identiques si et. Le fonctionnement de cet algorithme, en particulier pour la gestion des listes Waiting et Passed, est schématisé figure 3.7. Les lignes 1 et 2 de l algorithme correspondent à l initialisation : l état initial est stocké dans la liste Waiting et la liste Passed est vide. Puis tant qu il reste un état " dans la liste Waiting (lignes 3 et 4), l algorithme le traite. Tout d abord il le supprime de la liste Waiting (ligne 5). Ensuite, il teste la propriété sur cet état. Si la propriété est vérifiée, le parcours exhaustif n est pas obligatoire, l algorithme s arrête et renvoie VRAI (ligne 6). Puis la ligne 7 teste l inclusion de l état traité " dans la liste Passed. Cet état ne sera ajouté à Passed (ligne 8) que s il n existe pas d état de même partie discrète, ou si les états de même partie discrète ne peuvent inclure la partie continue dans leur propre partie continue ( ). L algorithme génère ensuite les successeurs " de l état ". Pour chacun de ces successeurs (ligne 9), il sera intégré à la liste Waiting (ligne 11) s il n existe pas déjà dans cette liste un état de même partie discrète, ou si les états à partie discrète n ont pas une partie continue pouvant inclure (c est-à-dire ), ligne 10. Si l algorithme a traité tous les états de la liste Waiting sans que la propriété ne soit vérifiée, il renvoie alors FAUX (ligne 12). UPPAAL implémente également un algorithme proche permettant la vérification des propriétés de vivacité, c est-à-dire, et. Cet algorithme n est pas celui utilisé pour la vérification 93

94 Waiting Passed (l, Z ) (l, Y ) ( l, Z ) ( l, Z ) ( l, Y ) ligne 4 ligne 11 ligne 8 (l, Z ) successeurs ligne 9 état traité : ( l, Z ) FIG. 3.7 Schéma de l algorithme d accessibilité des propriétés dans notre contexte, il ne sera donc pas abordé ici. Pour plus de détails se référer à [Möl02]. 3.2 Optimisations de l outil UPPAAL Complexité et méthodes d optimisation Le principal problème de la technique de model checking est l explosion combinatoire de l espace d états du système et donc en particulier de l espace de stockage nécessaire pour le parcours exhaustif de ce graphe. L utilisation mémoire du processus d analyse s exprime selon deux critères : le nombre total d états à stocker et la taille de chacun de ces états. Les techniques d optimisations dédiées à la réduction de l utilisation mémoire peuvent donc être classées en deux types : les optimisations locales, qui peuvent être appliquées à chacun des états stockés et les optimisations globales qui permettent la réduction du nombre d états stockés. La complexité temporelle du processus d analyse est moins critique pour le model checking que celle de l utilisation mémoire. Il est cependant nécessaire de ne pas la négliger et de déterminer les facteurs essentiels de cette complexité. Le premier élément évident est le nombre total d états traités, c est-à-dire le nombre total d états du système mais aussi de sa structure globale. Mais cette complexité temporelle est beaucoup plus complexe. Tout d abord, l algorithme d accessibilité est composé de plusieurs opérations élémentaires appliquées localement sur les états symboliques. En particulier, les tests d inclusion ou d ensemble vide sont récurrents et une modification de leur complexité locale de calcul peut influencer la complexité globale de l algorithme. Ces opérations élémentaires ont une complexité dépendante du nombre et de la taille des éléments qu elles traitent. Par exemple, la ligne 7 de l algorithme (figure 3.6) effectue un test d inclusion de la zone d un état " sur toutes les zones des états " de la liste Passed. Ce test d inclusion dépend du nombre total d états dans la liste Passed, du nombre d états de cette liste ayant la même partie discrète et de la complexité élémentaire du test d inclusion d une zone avec une autre, qui lui-même dépend de la taille de la zone et de son implémentation. Ces exemples montrent donc clairement que la complexité précise du processus d analyse dans UP- PAAL est difficile. Il est cependant possible d en extraire les facteurs importants. Le tableau 3.2 résume les facteurs les plus influents pour la complexité, en terme d éléments de l analyse dans la première colonne, puis en terme d éléments du système dans la deuxième. Ce sont ces éléments qui sont la source de la complexité. Un facteur supplémentaire doit également être considéré : le type de propriété. En effet, si la propriété à vérifier est une propriété d atteignabilité, l analyse pourra s arrêter dès le premier état atteint. Par contre, une propriété d invariance provoquera l arrêt de l algorithme d analyse si elle n est plus vérifiée. Le principal problème du model checking étant sa complexité spatiale, de nombreuses méthodes d optimisations ont été développées sans l outil UPPAAL pour résoudre ce problème. Certaines méthodes sont des optimisations locales, qui permettent la réduction de la taille des états eux-mêmes par des tech- 94

95 Complexité spatiale Taille d un état - partie discrète Taille d un état - partie continue Nombre d états dans Passed Nombre d états dans Waiting Terminaison de l analyse Nombre d états et de variables des automates Nombre d horloges, de contraintes et implémentation Structure du programme, algorithme Structure du programme Type de propriété, structure du programme Complexité temporelle Nombre d états traités Test de la propriété sur un état Test de l inclusion Calcul du successeur Terminaison de l analyse Structure du programme, algorithme Taille de la propriété, taille et implémentation de l état Nombre d états stockés, taille et implémentation des états Structure du programme, complexité des opérations élémentaires Type de propriété, structure du programme TAB. 3.2 Facteurs influents pour la complexité de l analyse dans UPPAAL niques d implémentations optimisées de la structure de données utilisée pour leur représentation. Ces techniques concernent la partie continue des états, la partie discrète étant fixée a priori par le nombre d états des automates et de variables du système. Trois implémentations des zones sont considérées pour l outil UPPAAL, décrites dans la section Une autre approche se base sur la réduction du nombre d états stockés dans les listes Passed et Waiting (optimisations globales). Deux exemples de telles optimisations sont implémentées dans UPPAAL : la réduction du nombre d états stockés dans Passed ([LLPY03]) et l union des listes ([DBLY03, Ben01]), décrites dans la section Implémentation et stockage des états symboliques Une solution de réduction du problème d explosion de l espace des états est l utilisation de techniques symboliques, c est-à-dire la représentation des états du système regroupés dans des classes d équivalence. Mais ces techniques doivent être complétées par d autres méthodes, en particulier pour l optimisation de l espace mémoire utilisé lors du processus de model checking. En effet, il existe différentes façons d optimiser cet espace mémoire. L une est évidemment l optimisation du nombre d états générés et donc traités. C est le but des techniques symboliques décrites précédemment (graphe des régions et utilisation des zones). Mais une autre optimisation, dite optimisation locale, réside dans l optimisation de la place mémoire nécessaire au stockage d un état. Ainsi, des travaux ont été développés dans le domaine de l implémentation mémoire de ces états et trois implémentations différentes sont proposées dans UPPAAL ([BBD 02]) : les DBM Difference Bounded Matrice, les MCR Minimal Constraints Representation et les CDD Clock Difference Diagram. Ce sont des structures de données utilisées pour la représentation du système de contraintes (partie continue) des états symboliques du graphe d états du système construit par l algorithme de model checking. De plus, outre les variations sur l espace mémoire nécessaire au processus d analyse, ces différentes implémentations peuvent influencer son temps de calcul d un point de vue local, en optimisant les opérations de test d inclusion et d ensemble vide. DBM - Difference Bounded Matrice Les DBM [Dil90], [BBD 02] sont la représentation de base de la plupart des algorithmes de model checking. Ils permettent la représentation des systèmes de contraintes, c est-à-dire des zones, par une conjonction de contraintes sur les différences entre chaque paire d horloges. Une DBM est un graphe orienté valué, dont les sommets sont les horloges du système et dont les arcs représentent l existence d une contrainte entre ces horloges, de valeur indiquée sur le poids des arcs. Une forme canonique est 95

96 une forme de représentation unique pour un système de contraintes. La forme canonique d un DBM peut être calculée en temps ", avec le nombre d horloges du système. Cette forme permet de beaucoup réduire la complexité de certaines opérations élémentaires effectuées sur les systèmes de contraintes durant l algorithme de model checking. La représentation en DBM donnant une borne explicite pour la différence entre chaque paire d horloges, elle utilise donc un espace mémoire de l ordre de ". La figure 3.8 donne au centre l exemple de représentation en DBM du système de contraintes suivant (sur les horloges ) : DBM MCR 4 x x x x x 0 5 x 3 x 0 x 3 FIG. 3.8 Exemple de représentation d un système de contraintes en DBM puis en MCR - [LLPY97] MCR - Minimal Constraints Representation Ces DBM peuvent cependant stocker des contraintes redondantes. Or le nombre de contraintes est un facteur important dans la complexité de l analyse, sans parler de la place mémoire pure utilisée pour le stockage de chacune des contraintes. Par exemple, les états stockés dans la liste Passed ne sont ensuite utilisés que pour des tests d inclusion (ligne 7 de l algorithme de la figure 3.6), qui dépendent évidemment du nombre de contraintes à tester (test en temps linéaire sur le nombre de contraintes). Une représentation compacte des DBM est donc disponible, c est-à-dire qu un nombre minimal de contraintes est calculé à partir de la DBM initiale. Cette nouvelle structure de données, les MCR [LLPY97], est construite à partir d un DBM par un algorithme de minimisation des arcs orientés valués ([LLPY97, LLPY03]) calculé en temps ". Cette représentation minimale est également canonique. Elle est appelée structure de données compacte. Un exemple est donné figure 3.8, dont la partie droite est la représentation MCR (issu du DBM de gauche) du système de contraintes précédent. Le gain réel de cette optimisation des DBM en MCR est difficile à évaluer : d une part le calcul de la forme minimale est coûteux en temps, tandis qu on obtient un gain de place de stockage (utilisation mémoire en pratique de l ordre de ", [BLP 99]), mais aussi un gain de temps lors de certaines opérations élémentaires de l algorithme d accessibilité, en particulier pour les tests d inclusion et d ensemble vide. Les variations du temps de calcul seront donc dépendantes de la nature du système étudié. Union de zones Les DBM et leur forme minimale MCR ont donc permis une optimisation de l espace mémoire et du temps de calcul de l algorithme de model checking, rendant cette analyse possible pour un certain nombre de cas d étude. Cependant, le processus de model-checking reste à ce stade souvent trop lourd pour l analyse de systèmes réels complexes. De nouvelles optimisations de l algorithme de model checking ont donc été envisagées, dont certaines nécessitant l utilisation de l union des zones. Par exemple l article [BLP 99] montre qu un état " de la liste Waiting n aura pas besoin d être exploré si sa zone est incluse dans l union des zones des états de même partie discrète de la liste Passed, c est-à-dire : " Passed. Or les structures 96

97 DBM ou MCR ont un problème lié à l union des zones. En effet, une union de deux DBM ne conserve pas leurs caractéristiques, il est alors nécessaire de remplacer l union des zones par une liste de zones, ce qui bien sûr entraîne une utilisation mémoire et un temps de calcul des opérations élémentaires très importants. CDD - Clock Difference Diagram Une nouvelle forme de représentation des contraintes a donc été étudiée : les CDD [BLP 99], permettant de stocker les zones sous la forme d un arbre de décision de différence des horloges. Les nœuds de cet arbre représentent les différences d horloges (y compris une horloge fictive représentant la valeur 0) et les arcs représentent les bornes de ces différences. Les feuilles de l arbre représentent les contraintes globales Vrai et Faux. Seules les contraintes menant à la feuille Vrai ont besoin d être représentées. Ainsi, un nœud représentant la différence, associé à un arc sortant d intervalle, représente la contrainte ". Deux exemples simples, extraits de [BLP 99, BBD 02], sont donnés figure y x y x x x [0,2] [1,3] [4,6] y y [0,1] [2,3] [1,3] x y x y Vrai [0,0] Vrai [ 3,0] FIG. 3.9 Deux exemples de représentations de zones par CDD - [BLP 99, BBD 02] Les CDD permettent une optimisation de la manipulation et surtout du stockage des unions de zones, au prix d une augmentation du temps de calcul, nécessaire pour la transformation des zones en CDD. Cependant, cette augmentation est atténuée par les gains de temps de calcul obtenus sur les opérations élémentaires effectuées sur les états. De plus, le principal problème du model checking est surtout l espace mémoire nécessaire au stockage du graphe d états. L optimisation de l utilisation mémoire est donc prioritaire sur le temps de calcul. Ainsi, trois implémentations différentes des structures de données utilisées pour la représentation des états symboliques du processus de model checking sont disponibles. Les deux premières sont implémentées dans l outil UPPAAL. Le choix d utilisation de l une ou l autre de ces implémentations va influencer les performances de l analyse, différemment en fonction de la structure du modèle du système étudié. 97

98 3.2.3 Optimisation de l algorithme de model checking Les optimisations présentées dans la partie précédente concernent des optimisations locales du processus d analyse, au niveau de la représentation des états du système. Un deuxième type d optimisations concerne le processus global, c est-à-dire une optimisation de l algorithme de model checking. En particulier, le gain recherché est celui de l utilisation mémoire, les optimisations concernent donc le nombre d états stockés et donc indirectement le nombre d états explorés. Algorithme à la volée La première optimisation implémentée dans l algorithme de model checking de l outil UPPAAL est la vérification à la volée de la propriété à vérifier. Cette optimisation (ligne 6 de la figure 3.6) permet d éviter le parcours de tout l espace des états si la propriété n est pas vérifiée et évite un double parcours du graphe (un pour la construction et un pour la vérification). Cette optimisation n est cependant pas très influente pour la plupart des propriétés vérifiées dans le cadre de la validation d un système critique (les propriétés vérifiées sont plus souvent du genre il doit être impossible d avoir quelque chose, ce qui implique un parcours exhaustif du graphe). Optimisation de la liste Passed Un exemple d optimisation de ces listes est donné dans [LLPY03], [LLPY97] ou [Pet99]. C est une optimisation du nombre d états stockés dans la liste Passed, basée sur l idée que tous les états n ont pas besoin d être stockés. Les états stockés dans la liste Passed le sont pour deux raisons : garantir la terminaison de l algorithme et éviter le traitement multiple d un même état. Cependant, un état n aura pas besoin d être stocké si ses prédécesseurs le sont déjà. La figure 3.10 montre un exemple caractéristique de graphe dont l état n a pas besoin d être stocké si l état l est. Cette optimisation est composée de deux étapes : d une part l analyse statique de la structure du modèle permet d identifier les états potentiellement concernés et d autre part l algorithme de model checking est modifié pour identifier à la volée les nœuds dont le stockage est effectivement inutile. Ces étapes d analyse supplémentaires entraînent une surcharge du temps de calcul au profit d un gain de la consommation mémoire. Cette surcharge temporelle est en partie compensée par la réduction du nombre d états sauvegardés. Comme pour les optimisations précédentes, le gain réel est dépendant de la structure du système analysé, mais [LLPY03] montre qu ils peuvent être très importants. A B FIG Exemple d optimisation du stockage des états symboliques Fusion des listes Passed et Waiting Une autre optimisation possible de l utilisation mémoire du processus de model checking est basée sur la fusion des deux listes Passed et Waiting en une seule PWList assurant la double fonctionnalité [BBD 02]. Dans l ancien algorithme, un état nouvellement généré, par exemple l état " de la figure 3.7, sera stocké dans la liste Passed s il ne peut être inclus dans aucun état de cette liste de même partie discrète. Par contre, si un tel état existe en attente dans la liste Waiting, " sera tout de même 98

99 stocké dans Passed inutilement. L optimisation est donc basée sur cette idée et un état ajouté dans la liste PWList en attente d être traité sera tout de même considéré pour le test d inclusion d un nouvel état. Cette section présente un rapide résumé de quelques unes des optimisations implémentées dans l outil UPPAAL afin de tenter de résoudre le problème de l explosion combinatoire de l analyse des modèles complexes. Toutes n ont pas été décrites [Möl02], il existe par exemple des méthodes de sur-estimation de l espace des états qui n ont pas été considérées ici car elles ne sont pas exactes. Cette section ne traitera pas non plus des différentes techniques d implémentation mémoire des listes et des données (fonctions de haschage par exemple), qui sont des problèmes très proches du matériel ou du langage utilisé. Des détails pourront être trouvés dans [Ben01]. Le but de cette thèse n est cependant pas de faire une description détaillée de tous ces mécanismes. Dans le cadre de la validation effective de TTA, le but ultime est d obtenir une méthodologie applicable à une validation réelle. Dans ce cadre, l intérêt est de savoir si les optimisations implémentées sont suffisantes et de proposer des solutions concrètes dans le cas contraire. 3.3 Abstractions du modèle de TTA La méthodologie de validation de l architecture TTA est présentée dans le chapitre 1 de cette partie. La première phase consiste en la conception d un modèle du système. Ce modèle doit être juste, c est-à-dire qu il doit représenter le comportement attendu du système d après les spécifications. Afin de s assurer de cette justesse du modèle, une première solution consiste à concevoir un modèle le plus proche possible des spécifications. Un tel modèle est plus expressif, compréhensible, aisé à concevoir et à modifier. Une deuxième solution, pour garantir la justesse d un modèle, est d effectuer sur ce modèle des vérifications de propriétés reflétant le comportement désiré. Ces propriétés sont facilement exprimables sur un modèle expressif, proche des spécifications. Le problème de cette approche réside dans la grande complexité d un tel modèle. La complexité de l analyse est en effet invariablement liée à l expressivité du modèle. Or la vérification des propriétés, même comportementales, implique une analyse du modèle et donc un parcours de l espace des états du système. Or l analyse de ce premier modèle conceptuel est confrontée au problème de l explosion combinatoire, en particulier sur le plan de la mémoire. Les optimisations présentées précédemment, implémentées dans l outil UPPAAL, ne suffisent pas toujours à compenser la trop grande complexité de l analyse liée à la grande expressivité du modèle conceptuel. Des techniques supplémentaires, non automatiques, doivent donc être appliquées à ce premier modèle. Ces techniques sont basées sur des modifications du modèle lui-même, en effectuant des abstractions de certaines informations redondantes ou inutiles du modèle conceptuel. Les informations pouvant être abstraites peuvent être sélectionnées soit de façon systématique, ce qui pourrait mener à une automatisation de l abstraction correspondante, soit en se basant sur la connaissance a priori du système, ce qui rend ces abstractions très spécifiques au modèle de TTA. Le choix des informations à abstraire est guidé par la prise en considération de la complexité de l analyse. Les facteurs à réduire sont ceux qui influencent cette complexité (cf tableau 3.2), en particulier ceux qui possédent une grande influence ou ceux qui ne pouvent pas être optimisés par les techniques d optimisation implémentées dans l outil UPPAAL. Cette section propose donc des règles d abstractions efficaces pour la validation du modèle de TTA en UPPAAL. Ces régles sont en général inspirées de techniques d abstractions existantes, puis ont été adaptées au contexte de TTA et de l outil UPPAAL. De plus, à ces idées d abstractions automatiques, a été intégrée une connaissance du comportement réel du système, ce qui entraîne des abstractions parfois très spécifiques au modèle étudié. L intégration de la connaissance du système dans le choix des abstractions limite grandement l automatisation de ces techniques. Le but ici n est cependant pas de définir formellement de nouvelles règles d abstractions, ni de modifier l outil UPPAAL mais d obtenir les meilleurs résultats possibles pour la validation de TTA (en terme de performances). Ces abstractions 99

100 spécifiques sont donc très utiles. Cette section présente ainsi, pour un certain nombre de facteurs influant sur la complexité, des règles théoriques d abstraction applicables automatiquement, puis précise les abstractions réellement appliquées au modèle de TTA en y intégrant la connaissance du système Réduction des entrelacements Les optimisations implémentées dans l outil UPPAAL sont intégrées directement dans le processus de model checking. A ce stade, les éléments du modèle sont fixés, c est-à-dire le nombre d automates, d états des automates, de transitions, de variables et d horloges. Or ces éléments entrent largement dans les facteurs influençant la complexité de l analyse (cf tableau 3.2). Cette section va introduire les abstractions appliquées sur le modèle de TTA, inspirées de techniques d analyse statique existantes. Les modifications réelles effectuées sur le modèle ne seront pas détaillées. Le but ici est de fournir une réflexion plus large sur ces abstractions, sur leur possiblité d automatisation dans le but de pouvoir les appliquer aux modèles d autres systèmes. Entrelacement : définition Les systèmes étudiés dans notre contexte impliquent la modélisation de la concurrence. Celle-ci est représentée par des entrelacements lorsque plusieurs transitions sont tirables simultanément. Un exemple simple d entrelacement est donné ci-dessous. Soit un réseau d automates (figure 3.11) composé de deux automates concurrents et. Pour simplifier, le système considéré dans cet exemple est non temporisé et aucune variable n est représentée. Sur cette figure, il existe une situation de concurrence pour les deux transitions et, qui peuvent toutes deux être tirées à partir de l état initial du système (automates respectivement en et ). Deux comportements du système sont donc possibles, suivant la transition choisie. Automate A Automate B A0 ta A1 B0 tb B1 FIG Exemple d automates concurrents Le graphe d états de ce système d automates est donné figure L état initial du système " contient les deux états d automates initiaux. Puis les deux comportements sont explorés : tir de en premier, ou tir de. Les deux séquences de transitions et aboutissent alors au même état final ", les transitions et étant indépendantes l une de l autre. Deux transitions sont indépendantes si leur ordre d exécution n influence pas le comportement du système. Cette situation est typique des entrelacements et un seul des chemins du graphe est nécessaire pour l analyse de ce système. Règle d optimisation des entrelacements pour les TSA Ainsi, une optimisation du processus de model checking pourrait reposer sur la réduction de l espace des états du système accessibles et donc devant être explorés. Des techniques automatiques existent dans la littérature, dites de réduction d ordre partiel ([BJLY98]), qui permettent la réduction des entrelacements en se basant sur une analyse statique du modèle. Il n existe cependant pas de technique de réduction des entrelacements adaptés à la sémantique des TSA, extension des automates temporisés utilisés dans l outil UPAAL. Ce formalisme possède en effet une sémantique particulière, notamment pour la gestion de l urgence, avec les notions urgent et committed. 100

101 (A0, B0) ta tb (A1, B0) (A0, B1) tb ta (A1, B1) FIG Entrelacement dans l espace d états du système de la figure 3.11 Nous allons donner ici une règle informelle applicable aux TSA et inspirée des travaux existants sur la réduction d ordre partiel. Cette règle pourrait être la base d une implémentation de cette technique dans l outil UPPAAL. En reprenant l exemple de la figure 3.11, on pourra définir un entrelacement dans un système d automates temporisés par la conséquence des trois situations suivantes : plusieurs automates sont dans un état connu simultanément, c est-à-dire au même instant ; sur la figure 3.11, ces états sont et ; on nommera ces états des états simultanés. de ces états simultanés partent des transitions concurrentes, c est-à-dire qu elles peuvent s exécuter au même instant ; sur la figure 3.11, ce sont et ; enfin, ces transitions sont indépendantes, c est-à-dire que leur ordre d exécution n influence pas le comportement du système. En appliquant ces définitions à la sémantique des TSA, il est possible d en extraire certaines informations qui peuvent donner une piste dans l idée de l automatisation de cette technique. Soit un système, réseau d automates TSA ( et ) donné figure L ensemble des états d automates de sera noté ; ici, on a, avec, et les états initiaux des automates. L invariant d un état est noté et les guards et updates d une transition sont respectivement notés et. Ces éléments apparaissent entre parenthèses sur la figure. La première étape de l optimisation des entrelacements consiste à détecter les états simultanés. Ces états sont difficilement détectables par une analyse statique du modèle. Les TSA permettent cependant la détection d un sous-ensemble de ces états : ceux qui résultent du tir d une transition associée à l émission d un signal. Il est ainsi possible de déterminer statiquement un ensemble d états simultanés, que nous appellerons. Ainsi dans la figure 3.13, on a car ces états sont atteints simultanément par le tir simultané des transitions associées à l émission et à la réception du signal de synchronisation. L étape suivante devient alors la détection des transitions concurrentes. Un élément spécifique des TSA permet de détecter aisément un sous-ensemble de transitions concurrentes : l urgence. En effet, les états marqués urgent ou committed doivent être quittés immédiatement, sans écoulement du temps. Ainsi, si un sous-ensemble de est marqué par l un de ces mots-clé, l ensemble des transitions sortantes de ces états, noté, seront alors des transitions concurrentes. Dans l exemple de la figure 3.13, les états et sont marqués urgent, les transitions et sont alors détectées comme concurrentes, on a donc et. L état est normal, c est-à-dire non marqué urgent, il est donc exclu et sera traité normalement. Une extension pourrait l inclure dans le traitement. Il reste enfin à tester l indépendance des transitions de. Pour que deux transitions soient indépendantes, il faut que les variables et les horloges modifiées lors du tir de l une des transitions, c est-à-dire modifiées dans son update, ne concernent pas celles impliquées dans les conditions de tir de l autre, 101

102 A0 B0 C0 s! s? s? A1 (I A1) ta (G ta,u ta) B1 (I ) B1 tb (G tb,u tb) C1 tc A2 (I A2) B2 (I ) B2 C2 FIG Exemple de détection de réduction d un entrelacement c est-à-dire dans sa guard ou dans les invariants de ses états source et destination. Ainsi, en considérant les deux transitions et de l exemple précédent, il faut : " " Soit une transition, on notera son état source et son état destination. Il est donc possible de généraliser l indépendance de deux transitions et par le système d équations : " " Une fois l indépendance des transitions prouvée, une situation d entrelacement a alors été détectée. Il est dans ce cas nécessaire d intégrer un traitement de cette situation afin d éviter l exploration de tous les chemins concurrents. La technique proposée ici devra être intégrée directement à l algorithme de model checking. Une première phase d analyse statique du modèle permettrait la détection des états simultanés et des transitions concurrentes indépendantes. Ces transitions devront être marquées par un marquage spécifique. Il serait alors nécessaire d intégrer un traitement spécial de ces transitions dans l algorithme d exploration du graphe d états du système, permettant de réduire l entrelacement à un seul chemin en exécutant ces transitions dans un ordre arbitraire. Cette technique permet ainsi de supprimer un certain nombre d entrelacements, dans le cas particulier d états marqués urgent à la suite d une transition de synchronisation. Cette situation, qui de prime abord semble très spécifique, est un cas relativement fréquent dans la modélisation des systèmes concurrents temps-réel en TSA. Elle peut par exemple traduire la modélisation d une série d actions instantanées, ou d une action complexe, suite à un signal précis (un top d horloge ou un événement extérieur). Il est possible d étendre ces définitions à des cas plus larges. Par exemple, deux transitions sont également concurrentes si leurs états source sont simultanés et marqués tous deux committed. Une deuxième idée serait de considérer des suites de transitions concurrentes. Par exemple, en reprenant la figure 3.13, on peut imaginer que les états et soient également marqués urgent. Ces états seront alors également simultanés. 102

103 Application sur le modèle TTA Dans notre contexte, aucune modification n a été apportée à l algorithme d analyse. Le traitement des situations d entrelacement détectées a donc été effectué à la main. La détection des situations d entrelacement reste par contre très proche de la méthode décrite ci-dessus. Pour éviter les entrelacements, la technique la plus utilisée a été l utilisation de l urgence : un état d automate marqué committed est prioritaire sur un état marqué urgent. Ainsi, la situation d entrelacement illustrée dans la figure 3.13 a été traitée en modifiant l un des états ou en le rendant committed. Les transitions et ne sont alors plus concurrentes, celle dont l état source est committed étant prioritaire. Les résultats de cette optimisation manuelle sont donnés dans la section Réduction du nombre d horloges Un autre facteur omniprésent dans la complexité du processus d analyse est le nombre d horloges du système. Ce facteur influence le nombre de régions et le nombre de contraintes sur les horloges, c està-dire le nombre d états du système et la taille de ces états. Une technique d optimisation du nombre d horloges d un automate temporisé est présentée dans [DY96]. Cette approche est basée sur la combinaison de deux algorithmes, l un pour la détection des horloges actives, c est-à-dire celles qui peuvent influencer l évolution future du système et l autre pour la détection des horloges ayant des valeurs toujours égales. Cette technique a été étendue à l optimisation d un réseau d automates dans [DT98] et utilisée dans [BBD 02]. La technique que nous avons appliquée sur le modèle de TTA pour l optimisation du nombre d horloges est cependant un peu différente des techniques automatiques de réduction. En effet, certaines transformations du modèle sont des abstractions basées sur une connaissance précise du système et sur des hypothèses qui peuvent être rajoutées. Ces abstractions sont alors spécifiques au modèle étudié et ne peuvent pas être basées sur une analyse automatique. Par exemple, l une des abstractions appliquées dans notre cas consiste en la suppression des horloges locales de bus guardians pour les remplacer par une horloge globale. La notion locale de temps est donc abstraite au profit d une notion de temps global qui suppose que toutes les visions locales sont identiques. Cela suppose donc que les horloges locales sont synchronisées entre elles. Pour être fiable, cette abstraction repose sur l hypothèse de la validation du service de synchronisation de ces horloges, ainsi que du service de gestion de la fenêtre d accès au bus. Ces deux hypothèses sont acceptées car elles ont été validées formellement par la preuve [PSvH99], [Rus01a]. L influence de ces abstractions sur les performances du processus de validation est donnée dans la section Une autre optimisation du nombre d horloges dans le modèle est le résultat d un autre type d abstraction : la fusion d automates. Cette abstraction est présentée dans la section suivante Réduction du nombre d automates : fusion Un dernier élément qui peut être modifié est le nombre d automates. Outre la diminution du nombre d automates, qui permet d optimiser la place mémoire utilisée pour la partie discrète des états en réduisant la longueur du vecteur d états, cette optimisation entraîne aussi souvent une diminution du nombre de variables et de transitions. Les gains sont évidemment largement liés à la structure du modèle et à la nature de l abstraction effectuée. Dans le cadre de la modélisation de TTA, l abstraction est appliquée sous la forme de la fusion de deux automates indépendants. L indépendance de deux automates est une notion complexe à exprimer de façon formelle et générique. La technique appliquée dans notre cas est principalement basée sur la connaissance précise du comportement du système et du modèle. Quelques règles globales peuvent cependant être extraites, pour les deux types d indépendance que nous avons traités et que nous appellerons indépendance d automates séquentiels et indépendance d automates à états stables. 103

104 Indépendance d automates séquentiels En effet, deux des trois fusions effectuées concernent des automates indépendants, c est-à-dire dont le comportement est indépendant car ils représentent des composants ou des services ne s exécutant jamais en parallèle. Le premier exemple est typique : les deux automates fusionnés sont un automate permettant de modéliser la phase d initialisation et un deuxième automate modélisant la gestion du temps en fonctionnement normal. Ces deux phases avaient, dans le modèle conceptuel, été modélisées par deux automates séparés car elles concernent des services différents. Il est cependant possible de modéliser ces deux phases en un seul automate, comprenant deux parties séquentielles successives repésentant les deux phases. automate A automate B fin FinA DebutB debut FIG Automates séquentiels Cette première forme d indépendance est l indépendance d automates dits séquentiels. Cette règle d indépendance peut être généralisée comme sur la figure Tout d abord le premier automate ( ), modélisant le comportement exécuté le plus tôt, possède une structure particulière : il possède un état final, représentant la fin du comportement du service modélisé. Le deuxième automate ( ) possède par contre symétriquement un état représentant le début du service qu il modélise. Sur la figure, ces états sont appelés respectivement FinA et DebutB. La transition fin mène à l état FinA. Le tir de cette transition correspond à la fin du service de l automate. De même, le tir de la transition debut correspond à l activation du service de l automate. Ces deux automates et sont séquentiels si la fin du service du premier est toujours avant le début du service du deuxième, c est-à-dire que le tir de la transition fin sera toujours avant celui de la transition debut. Soit l instant de tir d une transition, la condition d indépendance de deux états séquentiels est donc : Cette condition peut être vérifiée dans les cas simples par une analyse statique du modèle, mais peut également résulter d une connaissance approfondie du comportement du système. Les deux automates peuvent alors être fusionnés. automate fusionné fin FinA = DebutB debut FIG Fusion de deux automates séquentiels La fusion de deux automates séquentiels consiste à mettre ces deux modèles dans un même automate 104

105 de façon séquentielle, en fusionnant les états FinA et DebutB en un seul état. En effet, dès la fin du premier service, l automate fusionné sera prêt à démarrer le deuxième. Le résultat est donné sur la figure Cette fusion permet également souvent d optimiser le nombre d horloges ou de variables : les variables et horloges locales utilisées par le premier service pourront être réutilisées par le deuxième. Indépendance d automates à états stables Le deuxième type d indépendance traité est celui des automates à états stables, c est-à-dire que les automates ne contiennent qu un seul état, comme les automates et représentés sur la figure Il est alors possible de fusionner ces deux états, et sur la figure, en un seul état stable associé à toutes les transitions du système. Un cas particulier doit cependant être traité : celui des transitions synchronisées. En effet, deux transitions synchronisées doivent être tirées en même temps, ce qui n est pas possible si ces deux transitions se trouvent après la fusion dans le même automate. Soient la synchronisation attachée à une transition et l ensemble des transitions d un automate. L indépendance de deux automates à états stables et est garantie si les synchronisations des transitions sont disjointes. La condition d indépendance pour deux automates à états stables est donc : automate A automate B automate fusionné t1 (S t1) E A t3 (S ) t3 + E B t4 (S t4) t1 E t4 t3 t2 (S ) t2 t5 (S t5) t2 t5 FIG Automates à états stables Gestion des variables et des horloges Lors de la fusion de deux automates, il est nécessaire de gérer, en plus des états et transitions des automates, les variables et horloges locales de ces automates. La technique habituelle est la technique du renommage, afin que deux variables locales ne possèdent pas le même nom dans l automate fusionné. Mais il est également possible ici d obtenir des optimisations supplémentaires grâce à cette fusion. Par exemple, lors de la fusion d automates séquentiels, les variables et horloges nécessaires à la modélisation du premier service deviennent inutiles dès lors que ce service est désactivé. Elles peuvent donc être réutilisées pour la modélisation du second. Dans le cadre de cette thèse, cette gestion a été effectuée manuellement, en fonction des connaissances du système et du modèle. Il existe des techniques basées sur l analyse statique du modèle, permettant le renommage automatique et la détection des variables inutiles ([FBG03]) Applications d abstractions : résultats La section précédente propose quelques pistes pour l application automatique d abstractions sur des modèles UPPAAL. Ces pistes sont des idées inspirées le plus souvent de techniques existantes et adaptées à la sémantique des TSA, formalisme de modélisation de UPPAAL. En effet, la plupart des techniques 105

106 d abstractions reposent sur une analyse statique du modèle du système. Elles ne sont que des pistes de recherche et n ont à ce stade pas été implémentées dans l outil. Cependant, dans le contexte de la validation pratique de TTA avec UPPAAL, il est nécessaire de réaliser effectivement ces abstractions, afin de pouvoir obtenir des résultats de validation de propriétés sur le système dans des temps corrects. Des abstractions réelles ont donc été appliquées au modèle de TTA, inspirées des règles précédentes et adaptées au contexte spécifique du système. De plus, certaines abstractions ont été rajoutées, basées sur la connaissance du fonctionnement du système. Structure du modèle conceptuel Ces expériences d abstractions ont été effectuées sur un modèle simple de TTA : le fonctionnement normal, auquel a été ajoutée une modélisation simple du service de réintégration. Ce modèle est décrit plus en détail dans la partie 4 suivante. Ce paragraphe va introduire rapidement la structure du modèle conceptuel, afin de donner les éléments de comparaison nécessaires à l analyse ultérieure des résultats de performances. Ce modèle est composé de trois automates permettant la gestion globale du système : Initialisation : modélisation de la phase d initialisation ; Temps : gestion du temps global ; MEDL : gestion globale des instants d émission et de réception sur le bus ; Puis, pour chaque nœud appartenant au cluster, sont associés les automates : BGi, modélisation du bus guardian, OS Ni modélisation de l ordonnanceur, Appli Ni, modélisation abstraite du niveau applicatif, FT Ni, modélisation de la couche FT layer, Ci, modélisation du contrôleur TTP/C. Enfin, la gestion des fautes et la validation sont gérées de façon globale par deux automates : Generateur Fautes, qui permet la modélisation de l occurrence des fautes, Observateur, qui permet la validation de la propriété de bornes temporelles par l utilisation d un observateur. Abstractions du modèle conceptuel de TTA Une étude sur les différentes abstractions applicables au modèle de TTA a été menée ([GA04]). A partir du modèle conceptuel initial (version 0), un certain nombre d abstractions ont été appliquées, comme le montre la figure 3.17 qui en donne le graphe de dépendance : Abstraction n 1 - réduction des entrelacements, par simplification de la phase initiale et gestion de l urgence des états des automates. Abstraction n 2 - réduction du nombre d horloges : les horloges locales des bus gardians sont supprimées et remplacées par une seule hypothèse de la validation du service de synchronisation des bus gardians. Abstraction n 3 - réduction du nombre d automates : les bus gardians indépendants sont remplacés par un bus gardian global hypothèse de la validation du service de synchronisation et de la fenêtre d accès au bus. Abstraction n 4 - réduction du nombre d horloges : les horloges locales des ordonnancements sont supprimées et remplacées par une horloge globale hypothèse de la validation du service de synchronisation au niveau hôte. Abstraction n 5 - réduction du nombre d automates : 3 fusions de 2 automates indépendants. Ces abstractions ont été apliquées séparément les unes des autres, afin de pouvoir détecter l influence de chacune d entre elles sur les performances du processus d analyse du modèle. Résultats Les résultats des abstractions appliquées au modèle initial sont donnés sous plusieurs formes. 106

107 Version 0 n 1 réduction des entrelacements : phase d initialisation + gestion de l urgence n 2 réduction du nombre d horloges : Version 1 horloge globale pour tous les bus guardians n 4 n 5 réduction du nombre d automates : fusion d automates indépendants réduction du nombre d horloges : horloge globale pour tous les niveaux hotes Version 2 n 3 Version 3 Version 4 Version 5 réduction du nombre d automates : un automate bus guardian global FIG Abstractions appliquées au modèle conceptuel initial de TTA Tout d abord, le tableau 3.3 montre les résultats obtenus sur la structure des modèles, c est-à-dire en terme de nombre d éléments de ces modèles. Ces résultats sont ensuite analysés et généralisés au cas d un modèle à SRU. Ensuite, la figure 3.18 montre les mesures de performances obtenues lors de la validation du modèle de TTA, en terme de temps CPU et de consommation mémoire. Résultats - Réduction du nombre d éléments du modèle Le tableau 3.3 donne la taille des différentes versions du modèle de TTA. Dans ce tableau, seuls sont donnés le nombre d automates et le nombre d horloges. Le nombre de variables des modèles n a pas été modifié par nos abstractions, ce facteur ne rentrera donc pas en compte dans l étude de l influence des abstractions sur les performances du processus de validation. Il faut considérer ce tableau en parallèle de la figure Chacune des lignes de ce tableau est le résultat d une seule abstraction, appliquée sur le modèle initial version 0. Seule l abstraction n 3 est appliquée au-dessus de l abstraction n 2, étant donné que la considération d un bus guardian global entraîne forcément l utilisation d une horloge globale. La dernière colonne du tableau précise l abstraction appliquée. Versions Nombre Nombre Abstraction du modèle d automates d horloges modèle initial abstraction n abstraction n abstraction n 2+n abstraction n abstraction n 5 TAB. 3.3 Tailles des modèles des différentes versions 107

108 Ces résultats sont des résultats numériques liés au modèle utilisé. Il est cependant possible de paramétrer les gains obtenus en fonction du nombre de nœuds du système. En effet, la plupart des abstractions appliquées sur le modèle concerne des automates modélisant une partie ou une fonctionnalité d un nœud. Or les automates concernant la modélisation d un nœud sont dédiés à ce nœud, il existe donc autant de ces automates que de nœuds. Par exemple, l automate Ci modélisant le contrôleur d un nœud est associé à ce nœud et le modèle complet contiendra automates Ci. L abstraction n 1 ne se traduit pas par une réduction visible des éléments du modèle. Elle permet la suppression du traitement des entrelacements liés à la concurrence des transitions, sans bien sûr supprimer les transitions elles-mêmes. Il n y a donc pas d évolution visible du nombre d éléments du modèle. L abstraction n 2 permet un gain de 3 horloges. En effet, toutes les horloges locales des automates contrôleurs ont été supprimées, c est-à-dire 4, pour la remplacer par 1 horloge globale. Le gain obtenu par cette abstraction peut donc être généralisé par :. De même, l abstraction n 4 fournit de la même façon (suppression des horloges des automates OS Ni) un gain :. L abstraction n 3 permet l optimisation du nombre d automates. La réduction du nombre d horloges observée est liée à l abstraction n 2, qui a été conservée. On observe une optimisation de 3 automates, c est-à-dire que les 4 automates BGi ont été remplacés par un seul BG global. Ainsi, on obtient un gain en automates de :. Enfin, l abstraction n 5 est la fusion de plusieurs automates. Contrairement aux abstractions précédentes, cette abstraction n est pas forcément paramétrable. L abstraction n 5 regroupe en fait trois abstractions différentes, appelées et, toutes basées sur la fusion d automates. : fusion de Initialisation et Temps : fusion de Generateur Fautes et Observateur : fusion, pour chaque, de Appli Ni et FT Ni Les fusions et concernent les automates globaux. Ainsi, le gain obtenu ne sera pas dépendant du nombre de nœuds dans le cluster et on aura un gain de 1 seul automate pour chacune de ces fusions ( ). Par contre, la fusion permet également une optimisation du nombre d horloges, en permettant l utilisation de la même horloge par les deux services modélisés :. La fusion, par contre, concerne les automates impliqués dans la modélisation des nœuds. On a donc :. La somme des gains de l ensemble de ces trois fusions est donc : ". Abstraction TAB. 3.4 Gains paramétrés en nombre d éléments du modèle Ces résultats, résumés dans le tableau 3.4, montrent que certaines abstractions sont beaucoup plus intéressantes sur des modèles de système de grandes tailles, c est-à-dire dans le contexte de TTA avec beaucoup de SRU. Ces résultats ne sont pas visibles sur la figure 3.18, ces mesures ayant été effectuées sur le modèle d un seul système et donc sur un nombre fixe de SRU. Résultats- Mesures de performance Les mesures présentées dans la figure 3.18 ont été effectuées avec l outil memtime 1. L ordinateur 1 disponible sur le site d UPPAAL, 108

109 utilisé pour ces mesures est un Pentium III 500MHz, avec 512MB de mémoire. Aucune mesure ne correspond à la version 0 car la validation de celle-ci ne se termine pas, elle aboutit à une terminaison du processus de validation liée à la saturation mémoire, après plusieurs heures de calcul. Les effets de cette abstraction ne sont pas réellement mesurables, ni visibles. En effet le nombre d éléments du modèle n est pas modifié. Par contre, le traitement des entrelacements est capital dans les systèmes concurrents et en particulier dans notre contexte. Ainsi, cette abstraction est indispensable à la terminaison du processus de validation. Le gain de performances apporté par les autres abstractions sera donc évalué à partir de cette version 1 du modèle. Les mesures de la figure 3.18 montrent logiquement que chacune des abstractions effectuées apportent un gain en temps et en consommation mémoire par rapport au modèle version temps taille memoire Temps (s) Taille memoire (KB) Version FIG Mesures de performances du processus de validation L interprétation détaillée de ces résultats est complexe, pour les mêmes raisons que les effets des optimisations implémentées dans UPPAAL sont complexes à déterminer. En effet, la réduction d un élément du modèle peut influencer plusieurs étapes différentes de l algorithme de model checking. Elle peut également agir de façon locale, c est-à-dire sur tous les états du graphe, ou alors de façon globale c est-à-dire en réduisant le nombre de ces états. De plus, une abstraction semblant similaire n aura pas forcément la même influence. Par exemple, les abstractions n 2 et n 4 semblent a priori similaires : elles permettent la réduction du nombre d horloges en supprimant horloge du système. Elles ne génèrent toutefois pas les mêmes gains, qui sont nettement supérieurs pour l abstraction n 2. En effet, la complexité du graphe d états n est pas directement dépendante de ce nombre d horloges. La section montre que le nombre de régions est également dépendant du nombre de contraintes sur ces horloges et de leur taille. Bien que la complexité du graphe d états construit dans UPPAAL ne soit pas égale à celle du graphe de régions de par l implémentation des optimisations et l utilisation des zones, elle en est cependant assez proche. Ainsi, les résultats de la figure 3.18 montrent que l abstraction sur les horloges des BGi a permis une simplification très nette du système de contraintes associées à ce temps des bus guardian. Alors que la suppression des horloges des automates OS Ni n a pas généré une telle simplification. Cette section a présenté un certain nombre d abstractions effectuées sur le modèle de TTA, complémen- 109

110 taires des techniques d optimisations implémentées dans l outil. L application de ces abstractions sur le modèle de TTA a permis de réduire l expressivité du modèle conceptuel de TTA initialement conçu et donc d optimiser les performances du processus d analyse. Ce chapitre a présenté également la formalisation de certaines règles d abstractions utilisées, dans le contexte de la sémantique des TSA. Une étude est en cours, dans le cadre du DEA de Tahiry Razafindralambo 2, pour l application de ces règles d abstractions sur le modèle UPPAAL d une autre architecture : CAN. 2 laboratoire CITI, INSA Lyon 110

111 Chapitre 4 Vérification du modèle conceptuel La validation du modèle obtenu par abstraction du modèle conceptuel est ensuite complétée par la vérification d un certain nombre de propriétés comportementales. L ensemble de ces propriétés comportementales est en grande partie extrait des spécifications du système, afin que le modèle respecte les mêmes contraintes comportementales que ces spécifications. La liste de telles propriétés est longue, seuls quelques exemples représentatifs sont donnés dans le tableau 4.1. La plupart de ces propriétés devront être vérifiées pour chacun des SRU. La première ligne exprime la propriété dans le langage d expression de propriétés de l outil UPPAAL. La deuxième ligne indique leur rôle en français : Propriétés A[] not deadlock Pas de blocage du système. E temps 1 and msg==-2 Pas de messages erronés ou de slots vides en fonctionnement normal. A[] bg ok[0]==1 imply (bg ok[1]==0 and bg ok[2]==0 and bg ok[3]==0) Un seul SRU est autorisé à parler à la fois par son bus guardian. A[] not(c1.psp and (C2.PSP or C3.PSP or C4.PSP)) Aucun autre SRU ne se considère émetteur lorsque le SRU1 est émetteur. A[] ((temps==deltaround and temps!=0) imply Host N1.val r==val tab[2]) Vérification de la bonne transmission d une valeur applicative, à la fin d un round. A[] temps DeltaRound and temps bg DeltaRound and date ref DeltaRound Vérification de la gestion cyclique du temps. A[] type==1 imply emetteur==1 Vérification de la bonne émission des trames à CState explicite. A[](temps == OS inst[0][0] and OS act[0][0] == 3) imply CNI ttp[0]!= 0 Vérification de la transmission interne des messages : les données doivent être écrites dans le CNI par le niveau supérieur (FT layer) avant que le contrôleur ne le lise. TAB. 4.1 Vérification du modèle conceptuel 111

112 Ces propriétés ne permettent la vérification comportementale que du fonctionnement normal, sans service supplémentaire modélisé et sans occurrence de fautes. D autres propriétés spécifiques ont été rajoutées pour la vérification des différents services. Le tableau 4.2 donne trois exemples de propriétés vérifiées sur les modèles de TTA comprenant certains services. La variable G2 par exemple (deuxième propriété) est une variable spécifique du service de détection des cliques. Propriétés A[] not (deadlock and not Faute.Erreur and not Faute.Fin) Vérification qu il n existe pas de deadlock si le modèle n est pas dans un état considéré comme final, c est-à-dire si l automate Faute est dans l état Erreur, ou si une clique a été détectée (Faute.Fin) E G2==N and (not Faute.Erreur and not Faute.Fin) Il n est pas possible qu aucun nœud ne reçoive de trame (en fonctionnement normal) : l émetteur se suppose toujours actif et reçoit sa propre trame E not (Faute.NbReint==0 or Faute.NbReint==1) Vérification qu un seul nœud se réintègre à la fois (par hypothèse, un seul nœud fautif à la fois) E C1.etat==5 and (C2.etat==5 or C3.etat==5 or C4.etat==5) Vérification qu il n existe pas 2 nœuds en état passif simultanément TAB. 4.2 Propriétés spécifiques aux services 112

113 Chapitre 5 Méthodologie : conclusion Cette partie présente une méthodologie mise au point pour la validation des bornes temporelles de l architecture TTA. Cette méthodologie est composée de deux étapes principales, l une de conception d un modèle de l architecture et l autre de validation effective. Après un premier chapitre permettant l explication générale de cette méthodologie, le reste de cette partie décrit l application de cette méthode au cas de TTA. Le chapitre 2 fait une analyse des besoins en terme de modélisation pour l architecture TTA. En fonction de ces besoins et d une comparaison de différents formalismes de modélisation sur le plan théorique, une première sélection de formalismes a été faite. Puis une expérimentation pratique a permis d approfondir cette comparaison et a permis d écarter trois des formalismes initialement sélectionnés : les automates hybrides linéaires (avec l outil HyTech), les réseaux de Petri temporel (avec l outil Romeo) et SDL (avec l outil ObjectGEODE). Le premier formalisme, les automates hybrides linéaires, est finalement assez peu adapté à notre système dont la seule composante continue est le temps et qui comporte également une grande complexité de son comportement discret. Le second formalisme, les réseaux de Petri temporels, souffre d une explosion liée à une gestion spécifique de la concurrence. Enfin, le formalisme SDL est associé à des outils spécifiques à la conception d applications et peu adaptés à la validation temporelle exhaustive. Le formalisme de modélisation finalement sélectionné sont les TSA, automates temporisés étendus et leur outil associé UPPAAL. Les études pratique et théorique ont en effet montré que ce formalisme était adapté à notre contexte, tant sur le plan du pouvoir d expression que sur le plan du pouvoir d analyse de la méthode d analyse implémentée dans l outil UPPAAL. Les TSA et la méthode implémentée dans UPPAAL permettent la validation de systèmes exprimés en automates temporisés étendus avec une gestion du temps continu. Le temps discret reste a priori moins précis que le temps continu, mais ce dernier engendre en théorie une plus grande complexité. Cependant, la technique d analyse utilisée, le graphe des régions, permet dans UPPAAL une gestion de cette complexité. De plus, un certain nombre d optimisations globales sont disponibles pour la réduction de la complexité de l algorithme de model checking, qui permettent la réduction du nombre d états traités ou stockés. Un second type d optimisations sont les optimisations locales qui permettent la réduction de la place mémoire nécessaire au stockage des états, ou du temps de calcul nécessaire à l exécution d opérations élémentaires sur ces états. De plus, nous avons effectué des recherches supplémentaires afin de fournir des abstractions des modèles de TTA permettant de réduire encore plus le problème de l explosion combinatoire de l espace des états. L outil UPPAAL a donc été retenu et utilisé de par son efficacité et sa facilité d utilisation. La technique de représentation continue du temps utilisée dans UPPAAL s oppose à la gestion du temps discret, comme implémenté dans l environnement IF. Les analyses dans IF sont basées sur la construction des LTS, graphe de l espace des états fondé sur une gestion du temps discret. Une comparaison poussée de ces deux techniques d analyse serait une piste de recherche intéressante pour l évaluation de la pertinence de la représentation continue dans le cadre de TTA et pour la comparaison des complexités de ces deux processus d analyse. Une autre utilisation de la représentation discrète du temps dans le cadre de la validation de TTA est 113

114 présentée dans [SRSP04], qui propose une méthodologie très proche de la nôtre. La similarité de cette méthode avec la nôtre semble montrer que l approche de validation considérée dans notre méthodologie est pertinente. Les auteurs sont en effet des membres issus de l équipe de recherche ayant travaillé sur la validation des algorithmes de TTA par preuve. Leur nouvelle approche est réorientée vers une validation de propriétés par model checking avec l outil SAL 1. Cette méthode est cependant basée sur une modélisation discrète du temps dans l architecture TTA. Elle est illustrée par la vérification de propriétés et d une borne temporelle sur l algorithme d initialisation de TTA. L outil SAL est un outil dédié à la validation formelle de systèmes concurrents temps réel. Il est basé sur un langage de système de transitions, support à plusieurs outils de validation et d abstractions. L un de ces outils est le model checker de SAL, qui permet la vérification de propriétés (exprimées en langage SAL) par un parcours exhaustif de l ensemble des états du système. Les auteurs utilisent dans cette méthodologie une abstraction du temps continu en temps discret pour limiter l explosion de l espace d états que génère la gestion du temps continu. Ils considèrent donc les slots de TTP/C comme une unité de temps indivisible et basent leur analyse sur cette représentation du temps. Cette abstraction implique donc une considération particulière des fautes, qui ne permet pas une modélisation précise des instants d occurrence de ces fautes. Ainsi, les fautes représentées sont limitées à l état d un slot : réception de la trame correcte ou incorrecte. La méthodologie présentée dans [SRSP04] a permis la validation de propriétés, dont la borne temporelle, du service d initialisation de l architecture TTA en présence de fautes de transmission, de réception et d émission. La borne validée dans cet article sera comparée aux nôtres dans la section 3.2. La partie 4 suivante montre l application pratique de notre méthodologie à la validation des services de TTA. Une description du modèle du fonctionnement normal de l architecture est donnée dans un premier chapitre. Puis la section 3.3 propose l illustration détaillée de trois bornes temporelles, pour les services de réintégration, de détection d une perte de membership et pour la composition de ces deux services. Ce chapitre donne la description détaillée des résultats obtenus et de l analyse des scénarios des pires cas permettant l obtention de bornes paramétrées. Enfin, la conclusion de cette partie 4 donne toutes les bornes obtenues par l application de notre méthodologie pour différents services de TTA et différentes hypothèses de fautes, fait une courte comparaison de la borne de l article [SRSP04] avec les nôtres et présente des exemples d utilisation de ces bornes temporelles dans un contexte industriel. 1 http ://sal.csl.sri.com/ 114

115 115

116 Quatrième partie Résultats 116

117 117

118 Chapitre 1 Modélisation Une vérification complète de l architecture TTA implique la vérification de l ensemble de son comportement. Cela passe par la vérification de ses différents mécanismes séparément, mais aussi intégrés au sein de l architecture. Il sera ainsi possible de valider le comportement global de l architecture. La méthodologie présentée dans le chapitre 1 de la partie 3 précédente permet de vérifier des propriétés temporelles comme le temps maximum d exécution d un service (bornes temporelles). Ce chapitre donne les résultats de la vérification des bornes temporelles de l ensemble des services de TTA, ainsi qu une illustration de la méthodologie par l analyse détaillée de la vérification de trois bornes temporelles de TTA : service de réintégration, de détection d une faute de perte de membership, puis la composition de ces deux services. Le service de réintégration est un service simple, qui sert dans un premier temps à illustrer la méthodologie d obtention et de validation des bornes temporelles. Le service de réintégration est déclenché lors de la détection de différentes fautes, par exemple la perte de membership. L obtention de la borne temporelle du mécanisme de cette faute sera donc ensuite présentée. Enfin, la composition de ces deux bornes sera étudiée. L analyse des autres services de TTA est donnée en Annexe B de cette thèse. 1.1 Hypothèses Les hypothèses considérées pour la modélisation et la validation des services de TTA sont celles de TTA, exposées dans la section 3.1 de la partie 1. Certaines hypothèses supplémentaires ont de plus été ajoutées : Les horloges locales des contrôleurs sont considérées synchronisées sur le temps global avec une précision de. Cet intervalle est assuré par l algorithme de synchronisation du protocole TTP/C. Cette hypothèse peut être faite car cet algorithme a été le sujet de validation formelle [PSvH99] qui permet de garantir son comportement. L ordre d émission dans les différents slots a été défini de façon simple : le SRU i émet dans le slot i. La durée des slots et des différentes phases est de longueur fixe. Cette hypothèse simplifie la modélisation, et n implique pas d erreur dans la validation : on considère la durée maximale de toutes les phases. Ainsi, la borne temporelle sera au pire une surestimation de la réalité. De même, le service de gestion des fenêtres d accès au bus des bus guardians est considéré correct et n a pas été modélisé. Cette hypothèse se base sur la preuve existante de l algorithme de ce service, reportée dans [Rus01b]. 118

119 1.2 Modélisation du comportement normal Modèle global MEDL BG Controleur 1 Controleur 2 Controleur 3 Controleur 4 Appli FTlayer 1 Appli FTlayer 2 Appli FTlayer 3 Appli FTlayer 4 OS 1 OS 2 OS 3 OS 4 FIG. 1.1 Modèle global de TTA La première étape dans la modélisation de l architecture TTA a été de modéliser son comportement normal, sans représenter les détails des services. Ce modèle global est représenté sur la figure 1.1. Les automates sont représentés par les rectangles et les flèches représentent les communications (par signaux) entre ces automates. Le modèle global de TTA est composé de plusieurs automates : un MEDL, qui représente la vision globale des instants d émission et de réception sur le bus. un bus guardian (BG), qui modélise les fonctions des bus guardians indépendants, un gestionnaire de fonctionnement du modèle (non représenté figure 1.1), un ensemble d automates pour chaque nœud du système : l ordonnanceur (OS), l automate application-ft layer, le contrôleur. Chacun de ces automates est identifié par une variable id, permettant de les associer à un nœud précis Modélisation du sous-système hôte Le sous-système hôte se compose de 2 automates pour chaque SRU : Ordonnancement, qui gère l activation des tâches applicatives et de celles de la couche FT layer, et l automate Appli-FTLayer, qui modélise le comportement des tâches elles-mêmes. Cette partie de la modélisation est très simplifiée : l application est réduite à un rôle d émetteur/consommateur périodique de données, et la couche FT layer ne comporte qu un seul traitement de redondance de message. Cette modélisation ne sera pas détaillée dans cette thèse, car elle n influence aucune des bornes temporelles étudiées. Seuls les services considérés de bout en bout, comme le changement de mode (cf. annexe de cette thèse), intègrent des informations du niveau hôte. 119

120 Initialisation DeltaRound:=Nb_slot*DeltaSlot, temps:=0 Cycle temps<=deltaround temps==deltaround fin_round! temps:=0, date_ref:=0 FIG. 1.2 Automate Fonctionnement, gestion du temps global Modélisation du sous-système de communication Gestionnaire de fonctionnement du modèle L automate Fonctionnement est nécessaire pour la gestion du fonctionnement du point de vue modélisation ; il ne représente pas un élément réel de l architecture (il n est donc pas représenté sur la figure 1.1). Il permet par exemple de démarrer tous les automates simultanément après l initialisation des variables du système. Il permet également de gérer le temps global du système par la variable globale temps, sur laquelle se base l automate MEDL pour gérer l ordonnancement des messages et l accès au bus TDMA. Cette partie de l automate est montrée sur la figure 1.2, les états précédant l état Cycle de cet automate correspondent à l initialisation du modèle et ne sont pas montrés sur cette figure. La gestion du temps global s effectue grâce à l horloge globale temps, qui est réinitialisée dès que le temps atteint la valeur DeltaRound. Cette valeur est calculée pendant la phase d initialisation, en fonction des paramètres du système (nombre de nœuds et durée des slots) : DeltaRound :=NbSlot*DeltaSlot. La variable date ref est gérée de la même façon et en même temps que l horloge temps. Elles ont la même valeur et servent toutes deux à représenter le temps global. La variable date ref est nécessaire afin de pouvoir utiliser la valeur du temps global dans des opérations et des initialisations de variables. La fin d un round est indiquée à tous les automates par l envoi d un signal fin round. MEDL L automate MEDL représente une partie de la vue globale du système partagée par tous les nœuds non fautifs : l ordonnancement statique des messages. En se basant sur le temps global du système, le MEDL permet de séquencer les émissions et réceptions des différents nœuds, avec une précision donnée (Pi ttp sur les figures). Cette valeur représente la désynchronisation maximale des horloges locales des nœuds. Suivant la décomposition temporelle des slots, le MEDL envoie des signaux (voir figure 1.3) aux automates des contrôleurs afin de leur indiquer les instants : de préparation de l émission (signal msg send), c est-à-dire le début de la phase PSP, de début de la phase TP (signal msg at), et de réception, c est-à-dire la fin de la phase PRP (signal msg receive). Seuls ces trois instants sont nécessaires à la modélisation du comportement temporel des contrôleurs. Par exemple, la fin de la phase PRP modélise simultanément la réception de la trame transmise durant la phase TP et la fin des algorithmes de réception exécutés durant la phase PRP. En effet, les actions liées aux résultats de ces algorithmes ne seront pas déclenchées avant la fin de la phase PRP. Le comportement de l automate MEDL (figure 1.4) est cyclique, il suit les différentes phases d accès TDMA : slot, round et cycle de cluster : dans chacun des états MsgAT, MsgReceive ou MsgSend, il envoie les signaux appropriés à tous les automates Controleur, dans un intervalle de temps de durée Pi ttp ; ces signaux correspondent au début des phases TP, Idle ou PSP, comme le montre la figure 1.3 puis il passe respectivement dans les phases Reception, Idle et Emission, correspondant aux phases TP/PRP, Idle et PSP ; le signal msg send n est envoyé qu à l automate correspondant au SRU émetteur dans le slot 120

121 msg_send msg_at msg_receive PRP Idle PSP TP PRP Idle PSP slot FIG. 1.3 Gestion des phases temporelles par l automate MEDL suivant. Il est donc nécessaire de mémoriser le numéro du slot en cours : c est dans la variable slot ; il est également nécessaire de comptabiliser le nombre de rounds (variable round) afin de pouvoir gérer les cycles de cluster ; ainsi la fin d un slot peut correspondre : soit à la fin d un slot normal, dans ce cas la variable slot est incrémentée ; soit à la fin d un round, dans ce cas la variable round est incrémentée et slot réinitialisée ; soit à la fin d un cycle, les deux variables sont alors réinitialisées. Cette réinitialisation des variables s effectue dans le modèle au début de la phase PSP (sur les transitions d entrée dans l état MsgSend). La fin réelle d un round est cependant effective à la fin de cette phase. Lors de la fin d un round, le MEDL entre donc dans l état Fin RoundCycle et attend le signal fin round (en provenance de l automate Fonctionnement) avant de reprendre son comportement normal. bus guardian L automate BG (figure 1.5) représente un bus guardian central, possédant sa propre vision globale indépendante. Cette modélisation peut représenter plusieurs topologies de TTA, suivant les hypothèses matérielles de la structure de l architecture : soit la topologie en bus, en faisant comme hypothèse que les bus guardians sont totalement indépendants de leur contrôleur, autant sur le plan physique (alimentation par exemple) que temporel (source d horloge et mécanisme de synchronisation indépendants). Sous cette hypothèse, le comportement des bus guardian est alors validé formellement ([Rus01b]) et n aura donc pas besoin d être modélisé en détail. soit la topologie en étoile, avec des hypothèses de fautes simples : aucun mécanisme supplémentaire de tolérance aux fautes n est implémenté dans le bus guardian. Ces hypothèses permettent de représenter la fonctionnalité d accès au bus sous la forme d un seul automate gérant l accès de tous les nœuds. Les droits d accès sont représentés par une valeur booléenne dans le tableau bg ok[] : bg ok[i]==1 si le SRU i possède les droits d émission sur le bus. Toutes les autres valeurs bg ok[j] (j i) devront alors être égales à 0. Le temps global des bus guardian est représenté par l horloge temps bg, gérée indépendamment de l horloge temps. L automate BG a un comportement cyclique alternant entre les états Ouvert, pendant lequel un automate controleur a accès à la ressource bus, et Ferme pendant lequel aucun Controleur ne peut émettre. L état Attente cycle correspond à la cyclicité temporelle du comportement time-triggered : à la fin d un round, c est-à-dire à la date DeltaRound, l horloge temps bg est réinitialisée. Contrôleur Le modèle d un contrôleur TTP/C en fonctionnement normal est donné figure 1.6. Il est composé de trois états principaux : Idle, PSP et TP PRP. Ils correspondent aux phases temporelles de même nom de la figure 2.4 de la partie 1. Les phases TP et PRP ont été fusionnées dans le modèle car leur dissociation n était pas utile pour la modélisation du comportement du contrôleur pour les services étudiés. 121

122 Idle temps<=date MsgSend temps<=date temps==date, slot==nb_slot, round==nb_round slot:=1, round:=1, emetteur:=slot, date:=date_ref+pi_ttp/2, i:=0 MsgReceive temps<=date i==0 msg_send! i :=i+1 temps==date, slot<nb_slot slot++, date:=date_ref+pi_ttp/2, emetteur:=slot, i:=0 i==n date_ref:=date_ref+deltaslot DeltaPRP DeltaPSP DeltaTP, date:=date_ref Pi_ttp/2, type:= 1, msg:= 1 msg_receive! i++ Reception temps<=date temps==date i:=0, date := date_ref+pi_ttp/2 i<n id_signal:=i+1 i==1 date_ref:=date_ref+deltapsp, date := date_ref Pi_ttp/2 temps==date, slot==nb_slot, round<nb_round slot:=1, round++, emetteur:=slot, date:=date_ref+pi_ttp/2, i:=0 Fin_RoundCycle i<n id_signal:=i+1 Start temps==date, slot==1 msg_at! i++ Emission temps<=date temps==date, slot!=1 i:=0, date := date_ref+pi_ttp/2 fin_round? date:=date_ref+pi_ttp/2, i:=0 i==n date_ref:=date_ref+deltatp+deltaprp, date:=date_ref (Pi_ttp/2) startup? slot:=1, round:=1, i:=0, emetteur:=1, date:=date_ref+pi_ttp/2 MsgAT temps<=date FIG. 1.4 Modèle du MEDL, fonctionnement normal 122

123 Ferme temps_bg<=date temps_bg==date bg_ok[bg]:=1, date:=slot*deltaslot+deltatp+deltaprp+(pi_ttp/2 +1) temps_bg==date bg_ok[bg]:=0, bg:=(bg+1)%n, date:=slot*deltaslot-deltapsp-(pi_ttp/2 +1) date<deltaround date>=deltaround Ouvert temps_bg<=date temps_bg==deltaround temps_bg:=0, date:=date%deltaround startup? date:=deltatp+deltaprp+(pi_ttp/2 +1), bg_ok[0] := 1, temps_bg:=0, bg:=0 Start Attente_cycle temps_bg<=deltaround FIG. 1.5 Modèle du bus guardian, fonctionnement normal Les transitions entre ces différentes phases sont déclenchées par la réception d un signal envoyé par l automate du MEDL. L automate passe alors en état TPPRP end, état instantané qui permet de modéliser des actions du contrôleur effectuées à la fin de leurs phases respectives, et donc sur réception du signal. Les variables globales emetteur et id signal permettent de déterminer le nœud destinataire du signal émis. Par exemple, pour un automate Controleur donné, le signal msg at lui sera destiné si la condition id signal==id est remplie. Le modèle du comportement normal d un contrôleur, c est-à-dire en état actif, peut être décrit ainsi : contrôleur en état idle si le nœud est émetteur dans le slot suivant (c est-à-dire emetteur==id), le signal msg send lui est alors destiné. Le contrôleur passe dans l état PSP, et stocke dans un buffer local msg l les données applicatives lues dans le CNI. puis tous les nœuds reçoivent un signal msg at (en provenance du MEDL) : le nœud émetteur passe de l état PSP à l état TP PRP. Cette transition correspond au début de la phase d émission (TP) du message sur le bus : la variable msg s initialise à la valeur de la donnée à transmettre stockée en local, ou à une valeur spécifique suivant l état du bus guardian (msg==-2 : accès au bus interdit par le bus guardian). les autres nœuds (récepteurs), sur réception du signal msg at, passent directement de l état Idle à l état TP PRP sans action particulière. à la fin de la phase PRP, tous les contrôleurs reçoivent un signal msg receive. Ils repassent alors dans l état Idle, et remontent à la couche supérieure le message reçu (stockage dans le CNI) si ce message est valide (msg!=-2). 1.3 Scénario Paramètres du modèle Le modèle de TTA présenté ici représente le fonctionnement normal de l architecture. Ce modèle est générique mais dépend des valeurs de certaines variables, paramètres du protocole ou variables liées au 123

124 startup? Start msg!=-2 CNI_ttp[id-1] := msg Idle msg==-2 TP_PRP_end emetteur==id, bg_ok[id-1]==1 msg_send? msg_l:= CNI_ft[id-1], CNI_ft[id-1]:=0 PSP emetteur==id, bg_ok[id-1]==0 msg_send? msg:=-2, type:=-2 id_signal==id msg_at? id_signal==id msg_at? msg:=msg_l, msg_l:=0, type:=type[slot-1][round-1] id_signal==id msg_receive? TP_PRP FIG. 1.6 Modèle du contrôleur, fonctionnement normal scénario applicatif. Dans le contexte de la validation d un service de TTA, il est donc indispensable d analyser l influence des différentes variables du modèle sur l exécution du service. Il est en effet nécessaire de valider les services de l architecture de façon globale, pour tous les scénarios applicatifs possibles. Variables du niveau hôte Le niveau hôte est composé de l application, du système d exploitation et de la couche FT layer. Un scénario spécifique fixe le nombre de nœuds, le nombre d applications différentes et la répartition de ces applications sur les différents nœuds du système. Il fixe également le taux de redondance des applications et donc le fonctionnement de la couche FT layer. Une fois tous ces éléments fixés, un MEDL est généré, sur lequel va se baser le sous-système de communication. Le niveau applicatif n a alors, en absence de fautes, plus que très peu d influence sur le comportement du niveau de communication. Les seules interactions entre ces niveaux sont liées au service de changement de mode (génération d une requête), ou aux fautes (génération de fautes par le niveau hôte). Ces variables seront gérées par le modèle de génération des fautes, et n influent pas directement sur l exécution des algorithmes exécutés par les contrôleurs. Variables du MEDL Une fois le MEDL fixé, toutes les autres variables du niveau hôte n auront alors plus aucune influence sur le comportement du niveau communication. C est donc les variables représentant le MEDL dans le modèle qu il faut modifier, lorsque l on veut changer de scénarios. Variables du MEDL : nombre de nœuds : N nombre de rounds : NbRound nombre de slots : NbSlot=N 124

125 durée des slots : DeltaSlot durée de la phase de transmission : DeltaTP Un autre élément du MEDL à considérer est l ordre d attribution des slots au contrôleur. La technologie TDMA impose que cet ordre soit le même dans tous les rounds : un SRU émet toujours dans le même slot. L hypothèse de notre étude spécifiant que les SRU émettent toujours dans l ordre croissant de leur identifiant n aura donc pas d influence sur les bornes temporelles. Paramètres du protocole TTP/C Une autre catégorie de variables pouvant influencer le comportement du niveau de communication est l ensemble des paramètres du protocole TTP/C. Ces paramètres sont fixés ou configurables, mais ne peuvent pas être modifiés dynamiquement au cours de l exécution. Le seul de ces paramètres ayant une influence directe sur tous les services de communication est l intervalle de synchronisation :. D autres, comme par exemple la valeur des temporisations Startup Timeout et Listen Timeout du service initialisation, sont spécifiques à certains services et seront traités lors de la validation de ces services. Autres variables du MEDL Le MEDL contient beaucoup d autres variables, qui ne figurent pas ici. Certaines n influencent pas le comportement du contrôleur, comme par exemple l indication du débit d émission (Communication Bit Rates) qui n est utile que pour l émission proprement dite, mais ne modifie pas la durée de la phase TP. D autres, par contre, sont spécifiques à un service donné et seront traités lors de l étude du service associé. Par exemple dans la section 2.1, le rôle du paramètre MIC (Minimum Integration Count, nombre minimum de trames devant être reçues avant de pouvoir se réintégrer) est discuté. Variables spécifiques du contrôleur au niveau matériel Certains paramètres sont fixés par les possibilités matérielles de l implémentation du contrôleur utilisé. Ainsi, les phases PSP et PRP sont les phases pendant lesquelles s exécutent les algorithmes du protocole. Le temps d exécution de ces algorithmes est donc variable selon la technologie utilisée. durée de la phase PRP : DeltaPRP durée de la phase PSP : DeltaPSP Abstraction du niveau hôte Scénario applicatif N1 N3 N2 N4 FIG. 1.7 Schéma du scénario applicatif La figure 1.7 donne un exemple de scénario applicatif, considéré dans notre étude : Les nœuds N1 et N2 envoient successivement leurs messages à N3. N2 est un réplica de N1, le nœud récepteur N3 ne récupèrera qu une seule de ces deux valeurs. 125

126 Puis N3 répond aux deux nœuds N1 et N2, et envoie également sa valeur à N4. Les communications s effectuant par diffusion, ces trois communications se font donc en même temps. N4 répond à N3. Le comportement de l application représenté dans ce modèle est très simpifié. En effet, on s intéresse au comportement temporel du système, ainsi seul cet aspect doit être représenté. Le reste du comportement applicatif est donc abstrait, et le modèle ne représente que les instants d émission et de réception de l application. Dans TTA, cela représente les instants d écriture et de lecture dans le CNI. Services de niveau hôte La plupart des services offerts par TTA sont en réalité fournis par le protocole TTP/C. Ce sont ces services qui ont été validés dans cette thèse. Leur comportement, et donc leur pire temps d exécution, ne sera influencé que par les paramètres listés section instant au plus tot Ecriture d une nouvelle valeur par l application instant au plus tard Ecriture d une nouvelle valeur par l application Niveau hote intervalle pour l écriture dans le CNI CNI t1 t1 t2 Niveau communication Lecture du CNI par le niveau communication Nouvelle lecture du CNI par le niveau communication FIG. 1.8 Hypothèse pour la validation des services de niveau hôte Il existe cependant certains services qui concernent directement les applications et qui peuvent être considérés de bout-en-bout. Le changement de mode par exemple, est initié par l application. Son pire temps d exécution pourrait donc être validé entre deux instants de niveau applicatif. Cela implique cependant de tenir compte des instants de production ou de consommation des messages applicatifs par l application. Or ces instants, dépendant directement du comportement des applications, ne sont pas connus. Une application peut par exemple produire un message dans un intervalle de temps borné, comme le montre la figure 1.8. Sur cette figure, les instants t1 et t2 représentent les instants d écriture et de lecture dans le CNI. Un message lu par le niveau inférieur à l instant t2 sera correct, quel que soit l instant auquel ce message a été écrit, dans l intervalle entre t1 et t2. La solution adaptée pour la validation des services de niveau hôte est de considérer le pire instant de production du message par l application, c est-à-dire tout de suite après t1 (instant t1 de la figure). Ce cas de figure donnera un pire cas de la borne. De plus, l ajout d une couche FT layer va introduire un délai supplémentaire, entre l instant de production du message par l application dans le FTCNI et l instant d écriture de ce même message dans le CNI par la couche FT layer. Cela est discuté lors de la validation du changement de mode, en annexe B de cette thèse qui montre que la borne temporelle globale du changement de mode se décompose en deux parties, l une dépendant de l ordonnancement des tâches applicatives et de la couche FT layer, et l autre étant la borne générique paramétrable du changement de mode au niveau communication. 126

127 1.3.3 Valeurs des paramètres Les valeurs initiales des paramètres du modèle sont données dans le tableau 1.1. Ces valeurs, afin de refléter un scénario réaliste, ont été extraites du document [Mai02] de TTTech, fournisseur des logiciels et matériels du protocole TTP/C. Paramètre Valeur Définition N 4 nombre de nœuds Pi ttp 2 intervalle de synchronisation DeltaPSP 30 durée de la phase PSP DeltaPRP 40 durée de la phase PRP DeltaTP 220 durée de la phase TP DeltaSlot 300 durée des slots NbRound 2 nombre de rounds par cycle NbSlot 4 nombre de slots par round TAB. 1.1 Valeurs des variables modifiables du modèle Cette section a décrit le modèle du fonctionnement normal du système. Ce modèle sera la base des modèles utilisés pour la validation des différents services de TTA. Il sera alors complété par le comportement spécifique des services étudiés. La section suivante donne l exemple de la validation temporelle du service de réintégration, puis du service de détection d une perte de membership par le service d acquittement. La dernière partie sera une illustration de la validation de la composition de ces services. 127

128 Chapitre 2 Exemples de validation de bornes temporelles 2.1 Borne temporelle du service de réintégration Modélisation de la réintégration Contrôleur avec réintégration (figure 2.1) Le mécanisme de réintégration a été décrit dans la section 3.3 de la partie 1. Les éléments de modélisation de ce service sont décrits ici. Tout d abord, la réintégration commence à l instant de détection d une faute. La modélisation des fautes sera abordée dans le paragraphe suivant, elle se traduit dans l automate Controleur par le passage dans les états FaultDetection PSP ou FaultDetection- PRP. Le contrôleur passe alors dans l état passif. Les différents états d un contrôleur sont modélisés par la variable état. Les valeurs de cette variable (4 : état actif, 5 : état passif) correspondent à la numérotation des états dans les spécifications. Le contrôleur dans l état passif a un comportement proche de l état actif : il suit les mêmes phases PSP, TP PRP et Idle, et reçoit les trames des autres SRU. Cependant il n émet pas de données sur le bus (msg :=-2) et tente dans chaque phase PSP de se réintégrer : au passage dans l état passif : mise à zéro de la variable integration qui correspond à la variable integration counter des spécifications ; à chaque réception correcte : incrémentation de ce compteur ; dans chaque phase PSP : vérification de la condition de réintégration integration MIC. Selon la norme, MIC est par défaut égal à 2. si cette condition est remplie, le contrôleur repasse dans l état actif et peut émettre dans son slot. Hypothèses de fautes Le service de réintégration est provoqué par la détection de trois types de fautes : perte de membership, erreur de l application ou pas de signe de vie de l application. Dans les deux derniers cas, ces erreurs sont des erreurs du niveau hôte, c est-à-dire internes au nœud, et donc n influeront pas sur les autres nœuds. Elles sont en effet détectées durant la phase PSP, et le nœud entre dans l état passif sans émettre de trames erronées. Par contre, la perte de membership correspond à une émission erronée ou à une perte de message sur le bus, ce qui touche l ensemble des nœuds. En particulier, une faute byzantine peut entraîner plusieurs nœuds à se déclarer fautifs, et provoquer l exécution de plusieurs mécanismes simultanément (comme la détection de clique par exemple). Afin d étudier le mécanisme de réintégration indépendamment des autres mécanismes, les fautes byzantines seront dans un premier temps ignorées. De plus, ces fautes ne sont pas considérées dans les hypothèses de fautes de base de TTA (section 3.1). Le mécanisme sera donc tout d abord modélisé et validé pour des fautes exclusivement symétriques. De plus, la fréquence maximale de fautes de TTA 128

129 Start emetteur==id msg_send? msg_l:= CNI_ft[id-1], CNI_ft[id-1]:=0 PSP id_signal==id, faute==id, type_faute==1 msg_at? startup? etat:=4 id_signal==id,!(faute==id && type_faute==1 ) msg_at? FaultDetection_PSP FaultDetection_PRP id_signal==id, faute==id, type_faute==1 msg_at? PSP_end deb_faute! integration:=0, etat:=5 Idle etat==4 && bg_ok[id-1]==1 msg:=msg_l, msg_l:=0, type:=type[slot-1][round-1] etat==5, bg_ok[id-1]==1, integration>=integrationmax fin_faute! etat:=4, msg:=msg_l, msg_l:=0, type:=type[slot-1][round-1] id_signal==id, faute==id, type_faute==2 msg_receive? CNI_ttp[id-1] := msg id_signal==id,!(faute==id && type_faute==1 ) msg_at? bg_ok[id-1]==0 && etat==4 msg:=-3 etat==5 && integration<integrationmax msg:=-2 msg==-2 msg==-3 msg!=-2 && msg!=-3 && etat==4 CNI_ttp[id-1] := msg msg!=-2 && msg!=-3 && etat==5 TP_PRP_end integration++, CNI_ttp[id-1] := msg id_signal==id,!(faute==id && type_faute==2) msg_receive? TP_PRP deb_faute! integration:=0, etat:=5 FIG. 2.1 Modèle du contrôleur avec réintégration 129

130 spécifie qu il ne peut y avoir qu une faute pour deux rounds. On suppose donc dans un premier temps que la réintégration sera exécutée sans faute, puisqu elle est provoquée elle-même par une faute. En se basant sur la figure 2.2, cela signifie qu on a : Cette hypothèse sera toujours respectée dans les scénarios étudiés dans cette thèse. occurence de la faute détection réintégration nouvelle faute Détection Reintegration fréquence de faute minimale : 2* round FIG. 2.2 Hypothèse de fréquence de faute Puis une deuxième étude plus détaillée sera effectuée dans la section pour étudier l influence des fautes byzantines sur la borne temporelle de réintégration. Le reste des hypothèses de fautes (fréquence, régions de contention..) reste conforme à celles de TTA (section 3.1). Cette validation sort légèrement des hypothèses de TTA. Cela permet cependant l étude de plusieurs services s exécutant simultanément (détection de perte de membership, détection de clique), ainsi que la validation du service de réintégration dans une situation plus complexe (plusieurs nœuds détectent une erreur suite à la faute byzantine). Modélisation des fautes - Génération et observateur La faute générée dans ce modèle est représentée par une variable globale faute. Cette variable, initialisée à -1, prendra la valeur de l identifiant du nœud concerné par la faute. De plus, la variable globale type faute représente le type de la faute. De ce paramètre va dépendre dans quelle phase la faute sera détectée :type faute=1 pour la phase PSP, et 2 pour la phase PRP. Les deux cas sont représentés afin de vérifier la borne du mécanisme de réintégration de façon exhaustive. L automate Observateur (figure 2.3) est dédié à la génération de la faute et à la vérification de la borne de réintégration. La transition de l état Normal à l état Faute représente la génération d une faute : la variable faute prend la valeur du nœud fautif désiré, et la variable type faute prend aléatoirement les valeurs 1 ou 2. L automate reste dans l état Normal pendant au maximum la durée d un cycle de cluster (l invariant sur l état Normal empêche l automate de rester dans cet état lorsque la condition x Nb round*deltaround n est plus respectée), suivant les hypothèses de fautes spécifiant une fréquence de une faute pour deux rounds, c est-à-dire dans notre modèle un cycle de cluster. Ainsi un contrôleur, pendant ses phases PSP ou PRP, exécute les algorithmes de détection de fautes : il vérifie s il n existe pas une faute le concernant (faute==id) et détectable dans la phase dans laquelle il se trouve. Si le contrôleur détecte une faute pendant le PSP, il passe dans l état FaultDetection PSP. Il envoie alors un signal deb faute à l automate Observateur, puis retourne dans l état Idle en passant en état passif (etat :=5). A la fin de la réintégration, lorsque le contrôleur repasse en état actif, il envoie de même un signal fin faute à l automate Observateur et la variable état reprend la valeur 4. A la réception du signal deb faute, l automate passe dans l état Reintegration. Il initialise alors son horloge x et restera dans cet état jusqu à la fin de la réintégration du nœud (signal fin faute) ou jusqu au dépassement du pire temps de réintégration : le paramètre deadline reintegration. 130

131 Si ce pire temps est atteint, l automate transite dans l état Erreur. La vérification de la borne de réintégration s effectuera par vérification de l accessibilité de cet état (cf section 3.1.2). Lors du passage dans l état Reintegration, l horloge x n est pas initialisée à 0. En effet, le signal deb faute correspondant à la détection de la faute et donc au début de la réintégration, est modélisé à la fin de la phase de détection (PSP ou PRP). Or cette détection peut se produire à n importe quel moment de ces phases, on suppose donc, pour obtenir le pire cas, que la détection s effectue au début. On rajoute donc au temps maximal d exécution de la réintégration, vérifié par UPPAAL, la valeur de la phase de détection (PRP ou PSP suivant la valeur de la variable type faute). Ainsi, l automate réinitialise son horloge à la valeur DeltaPRP ou DeltaPSP sur réception du signal deb faute. startup? x:=0, faute:=-1 faute:=fautif, x:=0, type_faute:=1 faute:=fautif, x:=0, type_faute:=2 Normal x<=nb_round*deltaround Faute type_faute==1 deb_faute? x:=deltapsp, faute:=-2 type_faute==2 deb_faute? x:=deltaprp, faute:=-2 x==deadline Erreur Fin Reintegration x<=deadline fin_faute? FIG. 2.3 Modèle des fautes et observateur Réintégration après une faute symétrique Bornes numériques La vérification de la borne de réintégration a été effectuée pour chacun des nœuds du système. Cela a montré que la borne de réintégration est indépendante du nœud fautif, et que la faute provoquant le pire temps de réintégration est de type 2, c est-à-dire détectée dans le PRP. A cet instant de la validation, la borne vérifiée est une valeur numérique, dépendante des valeurs des constantes et des paramètres fixés dans le modèle. Il est donc nécessaire de l exprimer en fonction de ces paramètres. Le tableau 2.1 donne les résultats obtenus pour la vérification de la borne de réintégration en faisant varier les paramètres du système (voir le glossaire pour la signification des notations). La première ligne donne la borne temporelle (dernière colonne, grisée) pour les valeurs initiales des paramètres. Les lignes suivantes donnent la borne de la réintégration pour une variation de chacun des paramètres. Seuls figurent les paramètres influant sur la réintégration, les autres sont sans effet sur cette borne. N MIC TAB. 2.1 Bornes numériques du service de réintégration 131

132 Pire scénario de réintégration La figure 2.4 illustre le pire cas du mécanisme de réintégration pour le nœud 2 : Détection d une faute dans le PRP du slot 4 : le nœud 2 passe en passif et initialise son compteur integration ; Réception correcte dans le slot 1 : integration++ ; le nœud 2 atteint sa phase PSP, mais la condition de réintégration n est pas remplie : il reste en passif, le slot 2 sera donc vide ; réceptions correctes pendant les slots 3, 4 et 1 : integration++ ; le nœud 2 atteint de nouveau sa phase PSP, et se réintègre car integration>mic. π 2 IFG deadline de réintégration : D Reint (MIC 1) slot round π 2 slot4 slot1 slot2 slot3 slot4 slot1 PRP PRP PSP PSP réceptions ok integration++ arrivée de la faute détection de la faute slot vide integration=4 => N2 passif réception ok integration<=mic integration>mic integration=0 integration++ => N2 reste en Passif => N2 actif FIG. 2.4 Pire scénario de réintégration pour une faute symétrique Borne temporelle paramétrée L analyse des résultats du tableau 2.1 et de la figure 2.4 permet d extraire une borne paramétrée du service de réintégration de TTA après une faute symétrique : MIC En effet, le pire cas se produit lorsque le nœud fautif ne peut pas se réintégrer dans son PSP immédiatement suivant la détection de la faute, mais doit attendre le PSP suivant (un round plus tard). Pour cela, la condition de réintégration ne doit pas être remplie lors du premier PSP, c est-à-dire que integration<mic. Donc la faute peut être détectée au pire dans le MICième slot avant une phase PSP. Les résultats numériques du tableau confirment cette borne. Par exemple, la ligne 1 donne : Problème de l intervalle de synchronisation La troisième ligne du tableau 2.1 montre un résultat différent de la borne paramétrée donnée. En effet, pour, la borne numérique du pire temps d exécution devrait être. Or le tableau donne une valeur de Cette différence s explique par une analyse un peu plus poussée du modèle : l outil UPPAAL ne gère que les nombres entiers. Or le modèle utilise la valeur pour représenter la désynchronisation des horloges locales des nœuds : pour un instant global donné, les 132

133 valeurs des horloges des contrôleurs pourront s échelonner entre et. Cependant, une valeur impaire du paramètre va poser le problème du traitement des décimaux. L outil effectue une simplification, et utilise la valeur entière du résultat de l opération. Ainsi, une valeur va générer le même intervalle de désynchronisation que si. Ce problème se retrouvera dans toutes les bornes temporelles validées par le modèle Réintégration après une faute byzantine L étude du comportement des services de TTA en présence de faute byzantine est plus complexe que pour une faute symétrique. Il est en effet nécessaire de modéliser des réceptions différentes selon les nœuds récepteurs. De plus, dans le cas d une faute byzantine, plusieurs services sont parallèlement utilisés par le contrôleur pour détecter cette faute : les services de détection d une perte de membership, d une erreur de clique ou de communication blackout, et l algorithme d acquittement. Tous ces services peuvent influencer le comportement du service de réintégration lors d une faute byzantine. La validation de ce dernier service doit donc également prendre en compte ces fautes et le comportement simultané des autres services. Le modèle des contrôleurs présenté précédemment a donc été complété, ainsi que l automate générateur de fautes et observateur. Ce nouveau modèle sera détaillé dans la section 2.2 (en même temps que la description du modèle du deuxième service de TTA validé dans cette thèse). Cette section présente les résultats de la vérification de la borne de réintégration pour une faute byzantine et leur analyse. Pire scénario de réintégration après une faute byzantine D Reintegration slot2 slot3 π IFG 2 slot4 slot slot1 slot2 round slot3 slot4 slot1 π 2 slot2 N2 N3 N4 PSP PRP empty PSP empty N3 N4 empty PSP N2 Détection d une perte de membership par N2 integration=0 faute byzantine : G1={N1,N2} G2={N3,N4} Détection d une erreur de clique par N1 réceptions ok integration++ integration<mic =>N2 reste en passif integration>=mic => N2 repasse en actif FIG. 2.5 Pire scénario de réintégration après une faute byzantine, avec MIC=2 La figure 2.5 illustre le pire scénario de réintégration après une faute byzantine, pour N=4 nœuds et le paramètre MIC=2 : Emission du nœud N2 : faute byzantine. Partage du cluster en deux groupes G1= N1,N2 et G2= N3,N4, chacun avec des vecteurs de membership différents : N1, N2 : réception correcte (N2 est émetteur et suppose donc sa trame correcte), N3, N4 : réception incorrecte de la trame. Emission du nœud N3 : N1, N2 : réception incorrecte car ils ne sont pas du même groupe que N3. N2 ne peut pour l instant pas s acquitter, N4 : réception correcte. 133

134 Emission de N4 : N1, N2 : réception incorrecte. N2 ne s acquitte pas et détecte une perte de membership, il commence sa phase de réintégration, N3 : réception correcte. Phase PSP de N1 : détection d une erreur de clique par N1, qui s exclut du cluster. Slot de N1 : vide car N1 est exclu (état Freeze ou phase de réinitialisation), Slot de N2 : vide car N2 est en état passif, Emission de N3 : N2 : première réception correcte pendant sa phase de réintégration, N3, N4 : réception correcte. Emission de N4 : N2 : deuxième réception correcte pendant sa phase de réintégration, N3, N4 : réception correcte. Slot de N1 : vide car N1 est exclu, PSP de N2 : réintégration possible du nœud N2. Ce scénario inclut la détection d une erreur de clique. Le nœud ayant détecté cette erreur passe alors en état Freeze, et tentera de se réinitialiser sur ordre de son niveau hôte. La validation de la borne temporelle du service de détection des cliques est présentée en détail en annexe de cette thèse. Rôle du paramètre MIC La vérification du pire temps d exécution du service de réintégration après une faute byzantine semble donner les mêmes résultats numériques que pour une réintégration sur faute symétrique. Le tableau 2.2 donne les résultats de cette vérification, pour différentes valeurs du paramètre MIC. La ligne 1, vérification obtenue avec N=4 nœuds et MIC=2, semble donner le même résultat que pour une faute symétrique : MIC. N MIC TAB. 2.2 Bornes numériques du service de réintégration après une faute byzantine Cependant les lignes suivantes du tableau 2.2 ne confirment plus cette borne. De plus, l analyse du pire scénario de réintégration après une faute byzantine ne permet plus de déterminer de façon évidente le rôle du paramètre MIC dans la borne de réintégration. En effet, l analyse effectuée pour une faute symétrique, c est-à-dire que toutes les trames des autres nœuds sont correctes, n est plus valable. D une part, le nombre de trames correctes reçues dans un round dépend du nombre de nœuds de chacun des groupes formés par la faute. Le nombre de rounds nécessaires à la réception de MIC trames correctes peut alors être déterminé en fonction de ce nombre, et de MIC lui-même. La figure 2.6 représente le pire scénario de réintégration avec N=4 nœuds et MIC=3. Cette figure montre que le nombre de rounds nécessaires à la réception correcte de au moins MIC trames dépend du nombre de nœuds du groupe correct. Ici, le groupe G1= N1,N4 est considéré comme fautif : N1 détecte une perte de membership et N4 une erreur de clique. Les trames correctes sont donc celles du groupe G2= N2,N3. Dans cette situation, qui représente le pire cas d une détection de perte de membership pour 4 nœuds, le nombre de trames correctes par round est égal à 2. Cela explique les résultats du tableau 2.2 : pour MIC 2, 1 seul round est suffisant. Par contre, pour MIC=3 ou 4, 2 rounds seront nécessaires, et pour MIC=5 il en faudra 3. D autre part, le nombre de slots vides présents entre la détection de la faute et le premier PSP 134

135 du nœud fautif dépend également du nombre de nœuds dans chacun des groupes formés par la faute. Ici, seul 1 slot sera vide : celui de N4, qui a détecté une erreur de clique. faute byzantine : G1={N1,N4} G2={N2,N3} round D Reintegration round slot1 slot2 slot3 slot4 slot1 slot2 slot3 slot4 slot1 slot2 slot3 slot4 slot1 N1 N2 N3 empty empty N2 N3 empty empty N2 N3 empty N1 N1 : perte de membership integration=0 N4 : erreur de clique integration<mic =>N1 reste en passif réceptions correctes integration++ réceptions correctes integration++ integration<mic =>N1 reste en passif integration>=mic => N1 repasse en état actif FIG. 2.6 Pire scénario de réintégration après une faute byzantine, avec MIC=3 Borne temporelle de réintégration, après faute byzantine, pour N=4 nœuds L analyse précédente permet donc de donner une nouvelle borne temporelle du mécanisme de réintégration, valable pour N=4 nœuds : MIC MIC " Dans cette équation, les constantes 2 (de MIC ) et 1 (de 1* ) sont spécifiques au contexte N=4. L extension de cette borne, comme de toutes les bornes des services de TTA, au cas généralisé à N nœuds, est une perspective de ces travaux. De plus, lorsque la valeur de la borne dépasse la valeur de la fréquence minimum des fautes des hypothèses initiales, c est-à-dire 2 rounds, ce qui est le cas pour MIC>2, un nouvel élément devra entrer en ligne de compte : la possibilité d arrivée d une nouvelle faute. Cette nouvelle faute pourra influencer de nouveau la borne temporelle du service de réintégration. La borne temporelle analysée ici n est donc pas générique. Il est cependant possible de se limiter à des hypothèses réalistes, en fixant le paramètre MIC=2, comme cela est suggéré dans les spécifications. On peut alors obtenir la borne temporelle du service de réintégration de TTA : Cette section a décrit le processus de validation temporelle du service de réintégration de l architecture TTA, sous différentes hypothèses de fautes (suite à une faute symétrique, puis suite à une faute byzantine). Une deuxième illustration de la méthodologie présentée dans le chapitre 1 est donnée dans la section suivante, par la validation du service de détection d une perte de membership inclus dans le service d acquittement. 135

136 2.2 Borne temporelle de la détection d une perte de membership Le service validé ici est le service de détection d une perte de membership. Ce service est associé à deux autres services : le membership et l acquittement, décrits dans la section 3.3 de la partie 1. Ces services n étant pas indépendants, ils seront donc tous modélisés afin de pouvoir valider la borne de la détection d une perte de membership. De même, les services de détection des cliques et des communication blackouts sont complémentaires à ces services et ont donc été modélisés également. Ils ne seront cependant pas décrits ici, car ils n influent pas sur la borne temporelle validée. Leur étude détaillée se trouve en annexe de cette thèse Services de membership et d acquittement La détection d une perte de membership est intégrée aux services de membership et d acquittement. La validation de la borne temporelle de cette détection, et donc sa modélisation, implique la modélisation précise de l ensemble de ces services. Compteurs de trames : et L algorithme d acquittement implicite, ainsi que certains mécanismes de détection de fautes (détection des cliques et des communication blackout) utilisent deux compteurs pour chacun des nœuds : (agreed slots counter) : nombre de trames correctes reçues. (failed slots counter) : nombre de trames erronées reçues. Ces compteurs sont mis à jour régulièrement par les nœuds, à chaque réception de trame. Ils sont réinitialisés une fois par round, dans la phase PSP, lorsque le nœud va émettre. Réception : A chaque réception normale, c est-à-dire lorsque leur contrôleur ne se trouve pas en phase d acquittement, les nœuds récepteurs exécutent le service de membership : ils effectuent dans leur phase PRP une mise à jour des compteurs de trame et de leur vecteur de membership en fonction du status (cf. partie 1) de la trame reçue : status = correct ou tentative réception correcte : ; status = null ou invalid aucun compteur n est incrémenté, l émetteur est considéré comme fautif et exclu du membership ; status = incorrect, other error réception erronée :, l émetteur est considéré comme fautif et exclu du membership ; Acquittement : L acquittement d une trame d un nœud A s effectue en plusieurs phases. L algorithme complet d acquittement est donné figure 2.7. Il est basé sur le résultat de la comparaison du CRC de la trame reçue (et donc contenant implicitement le membership de l émetteur) et de celui calculé avec le membership du récepteur (ici le nœud A) (cf. section 3.3.1). Le membership local peut être modifié avant d effectuer le test de CRC, en fonction de la phase d acquittement du nœud. première phase d acquittement : le nœud A tente d acquitter sa dernière trame émise en considérant la trame reçue de son premier successeur. Cette phase correspond à la partie haute de la figure : Check Ia : test normal, c est-à-dire avec son propre bit de membership et celui de son premier successeur à la valeur 1. Si ce test est valide, il n y a pas eu d erreur, le nœud est acquitté et son premier successeur est considéré comme toujours actif. Check Ib : si le test Ia n est pas valide, un deuxième test est effectué pour s assurer que le problème concerne bien sa propre réception ou pour déterminer si le problème provient d un 136

137 1ère réception de A (transmission de succ1) succ1=id+1 succ2=id+2 Ac=Fc=0 transmission de A (1er successeur fautif) Fc++ memb(succ1)=0 succ1++ succ2++ memb(a)={1,1,...} Check Ia OK KO memb(a)={0,1,...} KO Check Ib OK 2ème réception de A (transmission de succ2) Ac++ réception correcte acquittement de A (2ème successeur fautif) Fc++ memb(succ2)=0 succ2++ KO Check IIa KO Check IIb memb(a)={1,0,1,...} OK memb(a)={0,1,1,...} OK Ac++ Fc++ memb(id)=0 (1er successeur fautif) Ac++ Fc++ memb(succ1)=0 succ1++ succ2++ A fautif : membership loss FIG. 2.7 Algorithme d acquittement implicite de TTA autre membre du membership. Ce test est effectué avec le bit de membership du nœud A à 0 et celui de son premier successeur à 1. Si ce test n est pas valide, le problème ne concerne pas directement la trame que A a émise ; le premier successeur est alors considéré comme fautif et son bit de membership est mis à 0 ; A va alors prendre un nouveau premier successeur et reste dans la première phase d acquittement. Si le test Ib est valide, il y a alors un problème sur la réception de la trame de A : soit cette trame était erronée car A est fautif, soit c est le premier successeur de A qui n a pas reçu cette trame car il est lui-même fautif. Le nœud A passe donc en deuxième phase d acquittement et attend l émission d un deuxième successeur qui va permettre de décider lequel de A ou de son premier successeur est fautif. deuxième phase d acquittement : Check IIa : test avec le bit de membership du premier successeur de A à 0. Si ce test est valide, le deuxième successeur permet la confirmation que le problème est dû à une mauvaise réception de la trame de A par son premier successeur. Ce dernier est alors considéré fautif et le nœud A est acquitté. Check IIb : si le test IIa n est pas valide, un deuxième test est effectué pour vérifier si le deuxième successeur a reçu la trame de A ou pas : le bit de membership de A est mis à 0. Si ce test est valide, cela signifie que la trame de A a été mal émise et A n est pas acquitté. Il se considère comme fautif, la faute détectée est une perte de membership et le nœud A devra se réintégrer. 137

138 Si le test IIb n est pas valide, le problème ne réside pas dans l émission de la trame de A, le deuxième successeur est considéré comme fautif et le nœud A reste en deuxième phase d acquittement, en attente d un nouveau deuxième successeur Bases de la modélisation Phase d initialisation du système Afin que les compteurs et aient des valeurs cohérentes avec le fonctionnement normal du système, il est nécessaire de laisser s exécuter le modèle sans faute pendant un round afin que les compteurs puissent s initialiser avec des valeurs réalistes. Les valeurs obtenues en l absence de fautes sont alors, par exemple à la fin d un round, celles données dans le tableau 2.3. Ac Fc Contrôleur 1 (C1) 4 0 Contrôleur 2 (C2) 3 0 Contrôleur 3 (C3) 2 0 Contrôleur 4 (C4) 1 0 TAB. 2.3 Valeur des compteurs et Automates Les mécanismes de gestion du membership et de l acquittement sont des algorithmes implémentés dans chacun des nœuds, au niveau du contrôleur. C est donc l automate Controleur qui a été modifié, comme le montre la figure 2.8. Cette figure est découpée en différentes parties qui modélisent le comportement du contrôleur à différents instants : émission, réception, acquittement,.. Ces parties seront expliquées dans la suite de cette section. Ce modèle du comportement du contrôleur intègre également le service de réintégration. Modélisation du calcul de CRC Les trames dans ce modèle ne sont pas entièrement modélisées. En particulier, la valeur du CRC n est pas explicitement représentée dans le modèle. Cependant dans le cas de l algorithme d acquittement, seuls les résultats concernant la comparaison des memberships sont nécessaires. La modélisation du calcul de CRC se limite donc à une comparaison explicite du membership de l émetteur qu il a copié dans la variable globale memb[n] lors de l émission de sa trame, et du membership local m[n] du nœud concerné par la réception. Le résultat de la comparaison de ces deux tableaux est stocké dans la variable check : check=1 s ils sont identiques, et 0 s ils sont différents. La comparaison est effectuée case par case, et la variable check est calculée avec un ET logique : check := check && (m[i] == memb[i]). Dans cette version du modèle, seules les trames à CState implicite sont modélisées, et donc a priori seule la méthode de calcul du CRC associé à ces trames (cf section de la partie 1). Cependant, la modélisation du membership émis comme une variable globale est une représentation du cas à CState explicite. Les deux calculs sont donc possibles. Modélisation du status des trames L état des trames est modélisé par la variable globale status. Cette variable est globale car elle est liée à la trame transmise, globale à tous les nœuds. Elle peut prendre 3 valeurs différentes : status=0 pour les trames nulles ou invalides, status=1 ou 2 pour les trames valides et pouvant être soumises aux tests de CRC (Ia, Ib..). Une trame incorrecte du point de vue du membership sera détectée par ces tests. Par contre, une 138

139 erreur dans le reste de la trame ne sera pas détectée par le calcul de CRC implémenté dans le modèle. De même, le test de validité d une quelconque requête de changement de mode n est pas implémenté, le changement de mode étant un service indépendant non considéré ici. Afin de prendre tout de même en compte ces cas, la valeur status=2 a été introduite. La valeur status=1 représente les autres trames ( correcte et tentative ou incorrecte à cause du membership). Variables de base La modélisation des services de membership et d acquittement est basée sur trois éléments principaux : Les compteurs de trames, modélisés respectivement par les variables Ac et Fc. Ces compteurs sont spécifiques à chaque nœud, ils sont donc modélisés comme des variables locales. Le membership local des contrôleurs est représenté par un tableau de booléens m[n] de taille N, N étant le nombre de nœuds du système. Premier et deuxième successeurs : ils sont représentés par les variables locales succ1 et succ2. Pour un nœud donné, ces variables ont pour valeur l indice de ces nœuds successeurs. Phase d acquittement : la variable locale ack va permettre de détecter si un nœud est à la recherche d acquittement (ack!=0), et dans quelle phase d acquittement il se trouve (ack=1 pour la première phase et ack=2 pour la deuxième) Modélisation du contrôleur L automate Controleur décrit dans cette section est une extension de celui utilisé pour le fonctionnement normal et la réintégration (cf. section 2.1). La figure 2.8 représente le nouveau modèle du contrôleur, avec les services de membership et acquittement. Ce modèle comprend également la modélisation du service de réintégration, utilisée par la suite (section 2.3) pour la validation de la borne temporelle composée de plusieurs services. En plus des différentes phases du comportement normal décrites dans la section 1.2, cet automate peut être considéré en plusieurs parties quasiment indépendantes, séparées sur la figure par des zones colorées : Partie A : émission du contrôleur ; Partie B : réception pour le contrôleur venant d émettre ; Partie C : réception d une trame invalide ; Partie D : réception d une trame valide, contrôleur non en phase d acquittement ; Partie E : réception d une trame valide, contrôleur en phase d acquittement ; Partie F : détection d une perte de membership. Partie A - Emission La phase d émission a été modifiée afin d intégrer la transmission du membership de l émetteur. Ainsi, à l instant de transmission, c est-à-dire au début de la phase TP (signal msg at), le nœud émetteur alors en état PSP transite en état TP, puis dans l état Emission (s il est actif). Il copie alors son membership local (m[]) dans la variable globale de membership (memb[]), puis passe en état TPPRP en attente de la fin des phases TP et PRP. Partie B - Réception de l émetteur Cette partie représente la modélisation de la réception du nœud qui vient d émettre dans le slot en cours. A la fin des phases TP/PRP, l automate transite en état ReceptionEmetteur, puis passe en phase Idle. Si le contrôleur est en état actif, il suppose sa propre trame correcte et incrémente le compteur Ac. 139

140 MembershipLoss i<n m[i]:=memb[i], i++ i==n, check==1 check:=0, i:=0 partie F i==n deb_reint! integration:=0, etat:=5, ack:=0, m[id 1]:=0, m[succ1 1]:=1, m[succ2 1]:=1 PSP Start initial!=id startup? etat:=4, Ac:=2 initial==id startup? etat:=4, Ac:=2 Idle emetteur==id, etat==4, bg_ok[id 1]==1 msg_send? msg_l:= CNI_ft[id 1], CNI_ft[id 1]:=0, G1:=G2:=0 emetteur==id, (etat==5 bg_ok[id 1]==0) msg_send? msg:= 2, type_trame:= 2 i<n check := check && (m[i] == memb[i]), i++ i==n, check==0 m[id 1]:=0, check:=1, m[succ1 1]:=1, i:=0 CheckIa i==n, check==1 ack:=0, check:=0, Ac++, CNI_ttp[id 1] := msg etat==5 integration++ etat==5 id_signal==id, (faute==id && type_faute==1) msg_at? id_signal==id,!(faute==id && type_faute==1),!(ac<=fc Ac+Fc <= 1) msg_at? succ1:=id%n+1, Ac:=0, Fc:=0, succ2:=(id%n+1)%n+1 id_signal==id, faute==id, type_faute==1 msg_at? partie B ReceptionFin etat==4 partie D i==n, check==0 i:=0, Fc++, m[emetteur 1]:=0 etat==4 trame_end! Ac++, G1++ ReceptionEmetteur id_signal==id msg_receive? TP i==n, check==0 Fc++, m[id 1]:=1, m[succ1 1]:=0, succ1:=(succ1%n)+1, succ2:=(succ2%n)+1 TPPRP etat==4, bg_ok[id 1]==0 memb[id 1]:=0, status:=0 i==n, check==1 check:=0, i:=0, Ac++, CNI_ttp[id 1] := msg ack==0 ReceptionNormale SlotVide etat==5, integration<integrationmax memb[id 1]:=0, status:=0 etat==4, bg_ok[id 1]==1 integration:=0, status:=1, m[id 1]:=1, ack:=1, msg:=msg_l, msg_l:=0, i:=0, type_trame:=type[slot 1][round 1] i<n memb[i]:=m[i], i++ i<n check := check && (m[i] == memb[i]), i++ i<n check := check && (m[i] == memb[i]), CheckIb i++ CheckIIb i==n, check==1 m[id 1]:=1, ack:=2 i==n, check==0 m[succ2 1]:=0, Fc++, succ2:=(succ2%n)+1 i==n, check==1 Ac++, Fc++, ack:=0, m[succ1]:=0, check:=0, succ1:=(succ1%n)+1, succ2:=(succ2%n)+1, CNI_ttp[id 1] := msg ack!=0 succ1:=(succ1%n)+1, succ2:=(succ2%n)+1 partie C i==n i:=0 trame! Emission id_signal==id,!(faute==id && type_faute==1) msg_at? ack==1 m[id 1]:=1, i:=0, m[succ1 1]:=1, check:=1 ack==0 check:=1, i:=0, m[emetteur 1]:=1 etat==5, integration>=integrationmax fin_reint! etat:=4, status:=1, m[id 1]:=1, ack:=1, msg:=msg_l, msg_l:=0, i:=0, type_trame:=type[slot 1][round 1] partie A i==n, check==0 m[id 1]:=0, i:=0, m[succ1 1]:=1, check:=1 CheckIIa ack==2 m[id 1]:=1, i:=0, check:=1, m[succ1 1]:=0 SlotNonVide id_signal==id, status!=0 msg_receive? G1++ partie E i<n check := check && (m[i] == memb[i]), i++ i<n check := check && (m[i] == memb[i]), i++ id_signal==id, status==0 msg_receive? m[emetteur 1]:=0, G2++ trame_end! Reception HostErreur_LifeSignNotUpdate deb_reint! integration:=0, etat:=5, m[id 1]:=0 FIG. 2.8 Modèle du contrôleur avec membership et acquittement 140

141 Partie C - Réception d une trame invalide Si le contrôleur ne reçoit pas une trame valide, c est-à-dire status=0, l automate passe alors dans l état SlotVide et considère l émetteur de ce slot comme fautif (m[emetteur-1] :=0). Puis il passe en état Idle, en modifiant les indices des successeurs (succ1++ et succ2++) s il est en phase d acquittement (c est-à-dire ack!=0). Partie D - Réception d une trame valide, contrôleur non en phase d acquittement Cette partie correspond à la modélisation de la réception d une trame valide par un nœud non émetteur et qui n est pas en recherche d acquittement. A l instant de réception, si le status de la trame reçue est non nul, alors la trame est valide et l automate passe dans l état SlotNonVide. Puis il vérifie s il est en phase d acquittement. Si ce n est pas le cas (ack==0), l automate passe en état ReceptionNormale et vérifie le membership de la trame reçue. Si les deux memberships sont identiques, alors le contrôleur incrémente son compteur Ac et remonte le message applicatif reçu dans le CNI (CNI ttp[id-1] :=msg). Si les memberships sont différents, l émetteur de cette trame est considéré comme fautif (m[emetteur-1] :=0) et le compteur Fc est incrémenté. Puis il passe en état Idle. Partie E - Réception d une trame valide, contrôleur en phase d acquittement Si le contrôleur se trouve en phase d acquittement, il vérifie dans quelle phase d acquittement il se trouve. Si ack==1, c est la première phase et l automate passe dans l état CheckIa, qui correspond au test Ia, puis dans l état CheckIb dans ReceptionFin (puis en Idle) suivant le résultat du test Ia (c est-à-dire de la variable check). Si le test Ib est effectué, l automate passera en état ReceptionFin, mais le contrôleur restera en phase d acquittement, première ou deuxième, suivant le résultat du test. De même, les variables Ac, Fc, succ1, succ2 et le membership local m[] sont mis à jour suivant les résultats de ces tests. La deuxième phase d acquittement est modélisée de façon similaire à la première : les états CheckIIa et CheckIIb représentent les tests IIa et IIb, et les différentes variables sont mises à jour en fonction des résultats. Partie F - Détection d une perte de membership Lors de la deuxième phase d acquittement, le nœud peut détecter une perte de membership si le test IIb est valide. L automate entre alors dans l état MembershipLoss. Il détecte ainsi qu il est fautif et que son vecteur de membership est erroné. Puis le contrôleur passera en état passif et tentera de se réintégrer Modélisation des fautes La section précédente décrit la modélisation du contrôleur et des services étudiés. Il est maintenant nécessaire de compléter ce modèle afin de permettre la validation des services modélisés en présence de fautes. Hypothèses de fautes Les hypothèses de fautes considérées sont celles précisées dans les spécifications de TTP/C, et résumées dans la section 3.1 de la partie 1. Les services présentés dans la section 3.3 permettent la détection des fautes de transmission sur le bus. Les différents types de fautes considérés ici sont : 1. faute manifeste : le nœud émetteur a un problème en émission, aucun des autres SRU ne reçoit sa trame ; 2. faute symétrique : la trame est mal émise ou mal transmise, tous les SRU reçoivent une trame erronée ; 141

142 3. faute byzantine : il y a un problème lors de la transmission de la trame, seuls certains SRU reçoivent la trame correcte ; Variables de base Afin de pouvoir générer différents types de fautes, plusieurs variables ont été intégrées au modèle (ces variables sont utilisées par l automate Faute, automate de génération de fautes et observateur) : compteurs G1 et G2 : ces variables globales représentent respectivement, pour l émission d une trame, le nombre de nœuds ayant reçu cette trame correctement, et ceux n ayant pas reçu la trame (ou une trame incorrecte). G1 et G2 sont également mises à jour par les automates Controleur lors de la réception des trames. variable NbActif : permet de définir le nombre de nœuds actifs dans le système. Cette variable est gérée par l automate Faute : l automate d un nœud qui devient inactif (passage en état passif ou en état Freeze) envoie un signal à l automate Faute. Sur réception de ce signal, ce dernier décrémente la variable NbActif. variable nb : permet de stocker, à la génération d une faute byzantine, le nombre de nœuds du groupe le plus petit. Cette variable permettra de définir la fin de la détection d une telle faute par l ensemble du système. En effet, une faute byzantine va entraîner plusieurs nœuds fautifs (nb), et donc plusieurs détections de fautes. La fin de la détection de la faute byzantine correspond à l instant de détection de la faute par le dernier SRU fautif. variable type : cette variable va permettre de différencier les types des fautes générées. Génération des fautes L automate Faute (figure 2.9) est chargé de deux fonctions : la génération des fautes dans un premier temps, puis la validation de la borne temporelle par la technique de l observateur. Les fautes de transmission sont générées dans le modèle à la fin de la phase PRP, lorsque l automate est dans l état FauteTransmission, instant de la détermination du status de la trame par le contrôleur. Afin de générer une faute, l automate Faute modifie la valeur de la variable globale status au moment où les automates Controleur la lisent. Ainsi, un Controleur pourra par exemple considérer la trame correcte (status==1), alors que le Controleur suivant ne recevra pas la trame (status==0). La faute générée sera dans ce cas une faute byzantine. Les premiers états de l automate (en haut à droite de la figure) représentent la phase d initialisation des paramètres et d attente de l instant de génération des fautes : L automate ne peut générer une faute qu après la phase d initialisation du modèle, donc à partir du deuxième round. Il attend donc de recevoir un signal de fin de round fin round avant de quitter son état initial Start. Le slot dans lequel la faute est générée est choisi aléatoirement, dans l état Slot. Une fois le numéro du slot déterminé, il est stocké dans la variable num slot. L automate attend alors le début de ce slot : il reste dans l état Attente pendant le temps (num slot-1)*deltaslot-pi ttp/2. Puis il passe dans l état DebutFaute et réinitialise son horloge. La variable clock de l automate Faute, utilisée pour mesurer l intervalle entre le début de la faute et sa détection, est réinitialisée au début de la phase TP. En effet, une faute de transmission dans le pire cas peut se produire au début de cette phase. L automate reste dans l état DebutFaute jusqu à l instant effectif de génération de cette faute : la fin de la phase PRP. Il attend donc DeltaTP+DeltaPRP, puis passe dans l état de génération de la faute : FauteTransmission. Type de faute générée Afin de déterminer le type de faute générée, un test est effectué sur les valeurs de G1 et G2. En effet, 142

143 initialisation et attente de l instant de génération Slot num_slot<n num_slot++ fin_round? num_slot:=1 Start Normal Reintegration (G1==N and G2==0) and (G1+G2==N) type:= 1 deb_reint? FauteSymetrique x<=deadline_ml status:=0 (G1==1 and G2==N 1), (G1+G2==N) type:=1 status:=2 status:=1 num_slot==1 x:=0, date:=(num_slot 1)*DeltaSlot num_slot!=1 x:=0, date:=(num_slot 1)*DeltaSlot (Pi_ttp/2) x==date G1:=G2:=0 FauteTransmission Attente x<=date x==date x:=0, date:=deltatp+deltaprp DebutFaute x<=date x==deadline_ml deb_reint? (G1>1 and G1<N 1), (G2>1 and G2<N 1), (G1+G2==N) type:=2, nb:=g1<?g2 Génération de la faute Erreur x==deadline_ml FauteByzantine clique_erreur? Observateur Clique FIG. 2.9 Automate de génération de fautes et observateur 143

144 ces deux variables permettent de stocker le nombre de nœuds ayant reçu correctement ou non la trame émise. Ainsi pour une faute symétrique, tous les nœuds vont appartenir au groupe 2 sauf l émetteur qui suppose sa trame bonne. On aura donc G1=1 et G2=N-1. Le cas d une émission correcte, c est-à-dire sans faute, est traduit pas G1=N et G2=0. Une faute byzantine sera donc quant à elle détectée par les autres possibilités : 1<G1<N et 0<G2<N-1. Le cas G1=0 et G2=N est impossible en fonctionnement normal (l émetteur suppose toujours sa trame correcte). Observateur Une fois la faute générée, l automate Faute devient un observateur, nécessaire à la validation de propriétés temporelles de vivacité bornée des services. Cependant, cette fonction d observateur est assez complexe, le service à valider étant dépendant du type de faute générée. Ainsi, les fautes symétriques sont détectées par l algorithme d acquittement, par une perte de membership. Les fautes byzantines par contre peuvent mener soit à une perte de membership, soit à des erreurs de clique, et pour plusieurs nœuds différents. La validation désirée ici est celle de la borne temporelle du service de détection d une perte de membership. Il est donc nécessaire de pouvoir distinguer, au moment de la détection de la faute, le type de faute générée et le service ayant effectué cette détection. Pour cela, une variable type est utilisée : type=1 si une faute symétrique est générée. Le service de détection concerné sera donc celui de détection d une perte de membership ; type=2 si une faute byzantine est générée. Dans ce cas, il peut se produire une perte de membership ou une détection de clique Validation Détection d une perte de membership après une faute symétrique La borne temporelle du service de détection d une perte de membership sera vérifiée en deux étapes. Dans un premier temps, la borne temporelle de détection d une perte de membership pour une faute symétrique sera validée de façon classique, c est-à-dire comme pour le service de réintégration étudié précédemment. La propriété à vérifier sera alors l accessibilité de l état Erreur, dans le cas où la variable type=1 : E<> Faute.Erreur and Faute.type==1. La borne temporelle à valider est la variable deadline ML. Dans ce cas, l état FauteSymetrique représente l attente de la détection de la faute et le temps écoulé dans cet état représente la durée d exécution du mécanisme de détection. Un exemple de pire scénario de détection d une perte de membership après une faute symétrique est donné figure 2.10 : La trame du nœud N1 est perdue pour tous les nœuds dans le slot 1 Emission du nœud N2 dans le slot 2. Cette trame est correctement reçue par les nœuds N3 et N4. Le nœud N1, qui est en première phase d acquittement, détecte que le nœud N2 l a exclu de son membership et passe en deuxième phase. Emission du nœud N3 dans le slot 3. Cette trame est correctement reçue par les nœuds N2 et N4. Le nœud N1, en deuxième phase d acquittement, va détecter sa faute puis passer en actif pour se réintégrer , , , , , , , ,857 TAB. 2.4 Bornes numériques du service de détection de perte de membership 144

145 N1 : 1ère phase ack, Ia ko, Ib ok, => passage en 2ième phase N1 : 2ième phase ack, IIa ko, IIb ok, => perte de membership perte de la trame de N1 N1 : émetteur N2, N3, N4 : pas de réception N2 : émetteur N3 : réception normale ok N4 : 1ère phase ack, Ia ok => acquitté N2 : 1ère phase ack, Ia ok => acquitté N3 : émetteur N4 : réception normale ok π 2 empty PRP PSP m={0,1,1,1} 2* slot TP + PRP D Membership m={0,1,1,1} PRP slot1 slot2 slot3 π 2 FIG Pire scénario de détection d une perte de membership - faute symétrique Les résultats numériques de la vérification du deadline ( ) de détection d une perte de membership sont donnés dans le tableau 2.4. Ce tableau ne donne que des exemples de résultats, et ne montre que les paramètres influençant la borne temporelle. Une analyse du pire scénario (figure 2.10) et de ces bornes numériques permet d extraire une borne temporelle paramétrée : Détection d une perte de membership après une faute byzantine La seconde étape de validation est plus complexe. En effet dans le cas d une faute byzantine, deux mécanismes peuvent détecter la faute. Il n est donc pas possible de vérifier la borne de façon classique : l état FauteByzantine représente l attente de détection de la faute, mais peut représenter indifféremment le temps d exécution des deux services de détection, suivant le scénario de la faute. Une contrainte temporelle sur cet état aboutirait donc à la validation du service de détection possédant la pire borne temporelle. Or la borne temporelle de la détection d une erreur de clique est pire que celle d une perte de membership. Afin de vérifier que le temps de détection dans le cas d une faute byzantine n est pas supérieur à celui de détection dans le cas d une faute symétrique, on peut utiliser la borne temporelle précédemment validée. Il suffit de vérifier que la détection d une perte de membership dans le cas d une faute byzantine ne s effectue jamais après cette borne : la détection d une perte de membership se traduit par le passage d un des nœuds (le nœud fautif) dans l état MembershipLoss. il suffit ensuite de vérifier que dans ce cas, l horloge x de l automate observateur Faute n est pas supérieure à la borne. La propriété vérifiée dans l outil UPPAAL est donc, pour les valeurs initiales des paramètres : E<> (C1.MembershipLoss or C2.MembershipLoss or C3.MembershipLoss 145

146 or C4.MembershipLoss) and Faute.x>862 Cette section, ainsi que la précédente, a permis de déterminer la borne temporelle d un service de TTA. Ces services peuvent être validés en les considérant de manière indépendante, sans interaction des autres services sur le service étudié. Les services de réintégration et de détection d une perte de membership ont été validés sur ce principe. Cependant, une vision réaliste du système implique la considération simultanée de plusieurs services, certains services étant indissociables. Il faut donc considérer la validation de la composition de services indépendants. Ainsi, l exécution d un service est souvent déclenchée par un autre, et même si ces services ne sont pas exécutés en parallèle, il est intéressant d étudier l influence de cette composition sur la borne temporelle de ces deux services. En effet, l association des pires scénarios de deux services donnés correspond rarement au pire scénario de l association de ces services. La somme des bornes de ces services correspond donc souvent à une majoration de la borne composée réelle. La section suivante présente une étude de l association de deux services, indépendants du point de vue comportemental, mais liés dans le comportement global de l architecture : le service de détection d une perte de membership et la réintégration qui s en suit. 2.3 Borne temporelle composée : détection d une perte de membership et réintégration Somme des bornes des services Ces services étant successifs du point de vue temporel (la fin du premier déclenche le deuxième), une première approche pour obtenir la borne du pire cas d exécution est d effectuer la somme des bornes des deux services. Cette solution garantit d obtenir une valeur de pire cas. Dans notre cas, on obtient : " " Cette nouvelle borne temporelle peut remettre en question l hypothèse de validation de la réintégration dans un contexte sans faute. En effet, si la borne composée est supérieure à 2 rounds, cela signifie qu une nouvelle faute peut se produire avant la fin de la phase de réintégration. Il serait alors nécessaire de modéliser et de valider ce service avec une deuxième faute pouvant se produire après 2 rounds. Il est cependant tout d abord nécessaire de vérifier la justesse de cette borne Modélisation La validation de la composition des deux services n entraîne pas de modification du modèle du contrôleur : ces deux services sont déjà modélisés. De même, la génération de fautes reste identique, toutes les fautes de transmission étant déjà modélisées. Il reste cependant un élément à rajouter dans l automate observateur Faute : la vérification de ces deux services. La figure 2.11 montre l automate Faute, qui est une version modifiée de celui de la figure 2.9 : ajout d une variable horloge x2, spécifique à la vérification de la borne composée ; à l instant de début théorique de la faute (passage dans l état DebutFaute) : mise de x2 à 0 ; dans les états traversés lors de l exécution des deux services : vérification du respect du deadline : x2<=deadline Composee ; Si violation de ce deadline : passage dans un état erreur spécifique : Erreur2. 146

147 Observateur Génération de la faute Initialisation et attente de l instant de génération Normal (G1==N and G2==0) and (G1+G2==N) type:= 1 Start fin_reint? type:= 1, NbReint Reintegration x<=deadline_reint, x2<=deadline_composee FauteSymetrique x<=deadline_ml, x2<=deadline_composee status:=0 status:=1 x:=0, x2:=0 clique_erreur? Erreur2 Fin deb_reint? type:=41, x:=0, NbReint++ x==deadline_reint x2==deadline_composee x2==deadline_composee Erreur x2==deadline_composee (N nb)%nbactif==0 (G1==1 and G2==N 1), (G1+G2==N) type:=1 x==deadline_ml deb_reint? x:=0, type:=42, NbReint++ x==deadline_ca_debut x==deadline_ca_fin clique_erreur? NbActif deb_reint? NbActif, type:=23 (N nb)%nbactif!=0 FauteTransmission (G1>1 and G1<N 1), (G2>1 and G2<N 1), (G1+G2==N) type:=2, nb:=g1<?g2 FauteByzantine x<=deadline_ca_debut, x2<=deadline_composee clique_erreur? type:=22, NbActif Clique x<=deadline_ca_fin fin_reint? NbReint DebutFaute x<=date FIG Modèle des fautes et observateur pour la borne composée 147

148 2.3.3 Validation : borne composée π 2 DMembershipLoss D Reintegration π 2 slot2 slot3 slot4 slot1 slot2 slot3 slot4 slot1 slot2 N2 N3 N4 PSP PRP empty PSP empty N3 N4 empty PSP N2 Détection d une perte de membership par N2 integration=0 faute byzantine : G1={N1,N2} G2={N3,N4} Détection d une erreur de clique par N1 integration<=mic =>N2 reste en passif réceptions ok integration++ integration>mic => N2 repasse en actif FIG Pire scénario de la composition des services détection d une perte de membership et réintégration Vérification de la borne avec UPPAAL Pour les valeurs initiales (cf. section 1.3.1) des paramètres du modèle, la borne numérique composée, si elle est la somme des bornes des services, serait donc : Or la vérification avec UPPAAL du deadline des deux services montre que la borne numérique réelle est de, comme le montre le tableau 2.5. Le pire scénario correspondant à cette valeur est donné figure Il correspond au cas d une faute byzantine. En effet dans ce cas, la faute ayant provoqué la perte de membership de l un des nœuds (ici N2) a également provoqué une erreur de clique pour le nœud N1. Tous les slots de N1 seront donc vides pendant la réintégration de N2. La différence entre les deux bornes est alors évidente : afin de considérer réellement le pire cas, la phase PRP de détection de la faute a été incluse dans les deux bornes. Or pour l association de ces deux services, une seule phase PRP est réellement exécutée. la désynchronisation des horloges est comprise dans un intervalle de désynchronisation constant, assuré par l algorithme de synchronisation de TTP/C. La désynchronisation ne pourra donc pas dépasser cette valeur. N MIC , , , ,3202 TAB. 2.5 Bornes numériques de la composition des services de détection d une perte de membership et de réintégration La borne temporelle paramétrée de l association des deux services est donc : 148

149 Chapitre 3 Résultats : conclusion 3.1 Bornes temporelles validées par notre méthodologie Le chapitre précédent a permis d illustrer la méthodologie présentée dans la partie 3 précédente, par la validation de deux services de TTA (la réintégration et la détection d une perte de membership par le service d acquittement) ainsi que par la validation de la composition de ces deux services. Le tableau 3.1 donne les bornes temporelles des services de TTA validés sous les hypothèses de fautes données par les spécifications de TTA, sauf indication contraire (la deuxième colonne précise le type de faute, l indication TTA signifiant les hypothèses de bases de TTA). Services validés Faute Borne temporelle Réintégration TTA MIC Réintégration byzantine Détection d une perte de membership TTA Détection d une erreur de clique byzantine Détection d un communication blackout blackout Acquittement TTA Initialisation sans faute WCET Passage en mode normal (après init) sans faute WCET Borne composée : ML + réintégration byzantine Changement de mode au niveau hôte sans faute Changement de mode au niveau TTP sans faute TAB. 3.1 Bornes temporelles des services de TTA La dernière section du chapitre précédent a également permis d étudier la validation de la composition de plusieurs services indépendants. Ainsi, bien que le comportement d un service particulier ne soit pas modifié par l exécution des autres services, la borne temporelle de leur composition n est pas forcément la somme des bornes temporelles des services composés. En effet, l association des pires cas d exécution de chacun des services n est pas forcément réaliste dans une exécution continue de ces services, et la somme des bornes est une surestimation de la borne temporelle composée. Des compositions fréquentes et réalistes des services de l architecture sont donc à valider. Cette liste de bornes n est pas exhaustive, en particulier du point de vue de ces scénarios de fautes. Il serait en effet intéressant par exemple de valider le service d initialisation avec occurence de fautes, ou de valider les services de TTA sous des scénarios de fautes sortant des hypothèses de TTA, comme l a été en partie le service de réintégration. 149

150 3.2 Comparaison avec des bornes temporelles existantes Nous avons vu dans la conclusion de la partie 3 que l article [SRSP04] propose une méthode proche de la nôtre, qui permet également la validation de bornes temporelles. La borne donnée en illustration de leur méthodologie est celle du service d initialisation de TTA avec la topologie en étoile, en présence de fautes. Cette borne ne pourra pas être immédiatement comparée aux nôtres, nos travaux n ayant porté actuellement que sur la topologie en bus. Il est cependant possible d établir un parallèle qui, sans fournir une comparaison exacte, donnera un ordre d idée. La borne de l initialisation de la topologie en étoile donnée dans [SRSP04] est (les notations ont été adaptées à celles utilisées dans cette thèse) : (3.1) Cette borne représente le pire temps d exécution pour l initialisation d un seul nœud, en présence d un composant fautif. Les hypothèses de fautes pour la topologie en étoile sont étendues à un composant fautif à la fois, comme pour la topologie en bus, mais dont le comportement peut être arbitraire. La borne d initialisation de la topologie en bus validée par notre méthodologie est : WCET (3.2) Cette borne est le pire temps d exécution du service d initialisation sans faute, pour l initialisation de tous les nœuds du cluster. Dans le comportement sans faute, ce temps correspond au temps d initialisation du nœud le plus long, comme dans [SRSP04]. Par contre, la borne (3.2) ci-dessus représente le comportement sans faute, elle est donc logiquement inférieure à la borne (3.1). Bien que ce résultat soit logique, il ne permet pas d extraire plus d informations, comme par exemple la comparaison du même service dans les deux topologies. Il est cependant possible de remarquer que notre borne semble plus précise que celle fournie avec la méthodologie de [SRSP04], ce qui s explique par l abstraction du temps continu en un temps discret de granularité égale au slot : il sera a priori impossible de descendre à la précision des différentes phases comme par exemple la durée de la phase de transmission TP ( ) présente dans notre borne de réintégration. Un autre domaine de comparaison peut être les mesures de performances du processus de validation. Pour un modèle avec un même nombre de nœuds égal à 4, la borne (3.1) a été obtenue en un temps CPU compris entre et suivant le scénario de fautes considéré. Ces mesures ont été effectuées sur un Intel(R) Xeon(TM), de vitesse et avec % de mémoire. Ces mesures montent rapidement avec le nombre de nœuds : elles passent à plus d 1 heure ( ) pour la validation d un système de 5 nœuds. Les mesures de performances effectuées pour la validation de la borne (3.2) sont nettement meilleures : et utilisés. Elles ont de plus été effectuées sur un ordinateur beaucoup moins puissant : Pentium III, de vitesse 500MHz, avec 500MB de mémoire. Ces données sont cependant difficilement comparables, étant donné que l absence de la modélisation des fautes simplifie énormément le processus d analyse. Il serait intéressant, pour pouvoir obtenir plus d informations de ces comparaisons, d appliquer les deux méthodologies sur des systèmes à structures identiques, sur le même ordinateur (ou tout au moins équivalent), et pour des hypothèses de fautes identiques. Ces comparaisons expérimentales pourraient également être complétées par une analyse théorique détaillée de la méthode d analyse employée dans l outil SAL afin de la comparer avec celle de l outil UPPAAL. Cette comparaison pourrait permettre de déterminer les possibilités des deux techniques 150

151 développées ([SRSP04] et la nôtre), qui sont différentes de par la représentation du temps : abstraction discrète dans [SRSP04] et continue dans notre méthodologie. La publication de [SRSP04] étant récente, ces travaux sont à l heure actuelle des perspectives de cette thèse. 3.3 Exemples d utilisation des bornes temporelles Représentation de TTA et TTP/C Les bornes temporelles validées par notre méthodologie représentent le pire temps d exécution des différents services de l architecture TTA. L existence de ces bornes peut permettre l intégration de TTA dans des environnements de développement, de validation ou de simulation sous forme abstraite. L architecture sera représentée par ses caractéristiques, par exemple sous forme d un nombre de messages perdus, ou sous forme d un délai de transmission. La traversée du réseau de communication serait alors considérée comme une boîte noire dont le comportement est déterministe en fonction des données d entrées, de la structure du système et des hypothèses de fautes considérées. En effet, la détermination des bornes permet d extraire, dans un environnement donné, le comportement du sous-système de communication. Ce comportement pourra ensuite être associé au taux de redondance pour en déduire un comportement global de l architecture. L influence de l occurrence de fautes au niveau communication se traduit au niveau applicatif par la disponibilité ou non des données applicatives transmises ou à recevoir. Dans un environnement comme l architecture TTA, possédant un ordonnancement statique et un ensemble de mécanismes de tolérance aux fautes directement intégrés, cela se traduit ici par un nombre de pertes de messages, et éventuellement par un délai de transmission. Application Application A Application B t0 t4 FT layer TTP/C m1 m1 m1 t3 m1 t1 t2 Bus Tdeb m1 Tfin m1 Slot 1 Slot 1 Tfin intervalle de non disponibilité du réseau pour l application A : borne temporelle des services de détection et de recouvrement FIG. 3.1 Influence des bornes temporelles sur le nombre de pertes de messages applicatifs Imaginons par exemple le cas de la figure 3.1. Cette figure illustre l influence des bornes temporelles de l architecture sur le nombre de pertes de messages du niveau applicatif. Soit un message m1 redondé dans le temps au niveau communication, et donc émis sur un même bus aux instants et. Cette redondance est transparente pour l application émettrice, qui transmet son message m1 à l instant. Les deux messages dupliqués m1 et m1 sont reçus au niveau du nœud récepteur et comparés à l instant 151

152 par un mécanisme de gestion de redondance. Le message résultant, m1, est alors lu par l application réceptrice à l instant. De même que pour l application émettrice, la gestion de la redondance des messages est transparente pour l application. Si une faute entraînant la perturbation des émissions sur le bus se produit à l instant, avant l émission du premier message m1, ce message est alors perdu. La redondance temporelle de ce message ne sera utile que si les nœuds concernés (supportant les applications et ) sont de nouveau actifs à l instant d émission du message redondé, c est-à-dire si la borne temporelle des services de détection et de recouvrement de la faute est inférieure à l intervalle entre les deux émissions redondées : avec avant. Si ce n est pas le cas, soit que le nœud de ne peut pas émettre m1, soit que le nœud de n est pas apte à le recevoir, alors le message m1 sera également perdu et l application ne recevra jamais ces données. Cet exemple montre que pour une architecture fixée (en particulier le taux de redondance), les bornes temporelles peuvent influencer le niveau applicatif en se transformant en nombre de pertes de données applicatives. Evaluation de la qualité d une application Ce facteur a été utilisé dans le cadre d une étude de l évaluation de critères de fiabilité de systèmes de contrôle, effectuée en collaboration avec F. Jumel 1 et décrite plus en détail dans [JGA04]. Cet article illustre une méthodologie d évaluation de tels systèmes, proposée dans [JNS03, JTAM03], implantant une application automobile distribuée sur un réseau de communication, c est-à-dire sur l architecture TTA. Ainsi, on suppose une application contrôle-commande conçue au-dessus d un réseau (figure 3.2). Une seule intervention du réseau est considérée afin de simplifier l étude du système dans le but de prouver la faisabilité de la méthodologie. La loi de commande considérée est implémentée sur un contrôleur directement relié aux capteurs, mais dont les valeurs de sorties (vers les actionneurs) traversent un réseau TTP/C pouvant être exposé à des fautes et donc engendrer des pertes de données applicatives. modèle du véhicule capteurs actionneurs données des capteurs valeurs des commandes réseau TTP/C loi de commande modèle de l algorithme de controle FIG. 3.2 Système contrôle commande avec un réseau Le but de la méthodologie est de permettre l étude de l influence des fautes et du réseau sur la qualité de l application, exprimée par des termes propres à l application. Dans le cas du freinage par exemple, cela peut se traduire par la distance de freinage avant l arrêt du véhicule. Le comportement du véhicule et de la loi de commande sont traditionnellement modélisés en automatique par des équations d état. La traversée du réseau TTP/C peut induire des pertes ou des délais dans la transmission de ces commandes transmises. Seules les pertes ont été considérées dans cette étude. 1 enseignant-chercheur au Laboratoire CITI, INSA LYON 152

153 La méthodologie a été appliquée à une application de freinage. Une vision simplifiée du système peut se limiter à l étude de la vitesse du véhicule. Si aucune commande de freinage n est transmise aux actionneurs, la vitesse diminue d un facteur (dû à l inertie du véhicule) tandis que l application d une commande de freinage entraîne la diminution d un facteur. La fonction de freinage peut donc se traduire par l équation 3.3 suivante, qui est une bonne approximation d un système de type ABS : " (3.3) avec la vitesse interne du véhicule à un instant donné et la représentation des erreurs : si la commande transmise sur le réseau est perdue, et si la commande est reçue. Ces deux valeurs correspondent à deux scénarios de fautes différents. En effet, des fautes de types différents impliqueront l exécution de services de détection et de recouvrement différents, et donc des bornes temporelles différentes. La variation de ces bornes entraînera ou non la perte des messages, comme le montre la figure 3.1. Pour l illustration de la méthodologie, la conséquence d une faute sur la fonction de freinage a été amplifiée. Ainsi, on considère une vitesse initiale unités ( ), et des facteurs et. Ces valeurs de paramètres sont exagérées, le nombre d étapes pour un freinage étant en réalité de l ordre de la centaine (l état final correspond à ). Différents comportements de la fonction de freinage sont représentés sur la figure 3.3 2, avec un freinage sans faute, un freinage dans le cas où aucune des commandes de freinage n est reçue, et un exemple de scénario intermédiaire. FIG. 3.3 Exemple de comportements de freinage Enfin, afin d étudier la fiabilité de cette fonction de freinage, il est nécessaire de considérer l ensemble des scénarios de fautes. Une approche classique dans le domaine de l analyse de la fiabilité d un système est l approche probabiliste. Une loi binomiale d occurrence de fautes a été choisie ici, afin de pouvoir représenter l évolution du processus de freinage par une chaîne de Markov. Différentes situations de fautes peuvent être considérées, chacune avec des probabilités différentes. Puis l ensemble de ce système et des occurrences de fautes sont représentés par une chaîne de Markov, comme dans l exemple de la figure 3.4. L état correspond à l instant initial du processus de freinage, et l état correspond à l arrêt du véhicule. Soit la probabilité d occurrence d une faute, ce qui correspond à une perte de la 2 Toutes les figures de cette section sont tirées ou inspirées de [JGA04] 153

154 commande de freinage sur le réseau. Le processus de freinage évolue donc de avec une probabilité. Si la commande est bien reçue (probabilité ), le processus de freinage évolue de étapes. FIG. 3.4 Représentation de l évolution du processus de freinage par une chaîne de Markov A partir de résultats connus sur les chaînes de Markov, on peut déterminer la probabilité d atteindre l état final en étapes. Dans notre cas, si la contrainte de qualité exprime qu un freinage en plus de 10 étapes est dangereux, on peut définir la probabilité que cela arrive. Il est également possible d extraire d autres caractéristiques du processus étudié, comme par exemple le nombre moyen d étapes nécessaires pour atteindre l état final. Ainsi, cette méthodologie permet l intégration de l architecture TTA, par l intermédiaire de ces bornes temporelles, dans des processus d étude de la fiabilité de systèmes de contrôle. L intégration à un système de contrôle du comportement du réseau suivant une probabilité d occurrence de fautes permet d étudier l influence de ce réseau sur la qualité de la fonction de contrôle-commande du système. Conception d applications L abstraction du comportement de l architecture TTA, ou de celui du protocole TTP/C, permettrait son intégration dans différents environnements, par exemple, dans le processus de conception des applications. Actuellement, les applications sont modélisées dans un langage de simulation spécifique (souvent Simulink 3 ), puis leur simulation permet l observation du comportement du modèle et une certaine forme de validation. Ces applications sont ensuite implantées et validées par différentes méthodes décrites dans le chapitre 1 de la partie 2. Cependant, l influence de la transmission d un message sur un réseau de communication est peu représentée. Une solution pour cela est de fournir une représentation du réseau modélisant les effets (pertes, délais, erreurs) de ce réseau sur les messages le traversant. Ces éléments peuvent apparaître dans les outils de conception par une boîte noire représentant une abstraction du réseau. L environnement TTP-Matlink 4 offre la possibilité d intégration des concepts du réseau TTP/C dans un environnement Simulink de conception d applications. L intégration de nos bornes temporelles dans cette boîte TTP/C permettrait une représentation plus fine et plus réaliste du comportement de ce réseau et de son influence sur les messages applicatifs. La méthode décrite dans la section 1.3 de la partie 1 propose une répartition des exigences de tolérance aux fautes au niveau des architectures fonctionnelles. Cette architecture fonctionnelle doit ensuite être mappée sur une architecture matérielle, avec un taux de redondance donné et intégrant des communications sur des réseaux. Le taux de redondance comme le type de réseaux choisi influent sur la tolérance aux fautes du système. L intégration de l influence des réseaux dans le processus de développement des applications permettrait ainsi une validation des exigences définies sur l architecture fonctionnelle. Cette technique permettrait de créer un outil d aide à la conception des architectures, en intégrant un module de tolérance aux fautes permettant de choisir le taux de redondance et le type de réseaux à utiliser main.html?prod id=359&prod name=ttp-matlink 154

155 Simulateur de réseaux Enfin, un dernier exemple d utilisation de nos bornes temporelles est l intégration de TTA, ou du niveau de communication TTP/C, dans des environnements de simulation de réseaux. L outil OPNET 5 par exemple est un outil très utilisé dans le monde des réseaux. Il permet de simuler des communications sur différentes sortes de réseaux, avec des perturbations aléatoires. Il serait possible d y intégrer une boîte noire TTA, dont l influence en perte ou en délai de messages serait calculée en fonction des bornes temporelles et des scénarios de fautes désirés

156 [ 156

157 CONCLUSION]Conclusion 157

158 Conclusion 158

159 Conclusion Conclusion Cette thèse propose une méthodologie pour la validation temporelle de l architecture TTA. En particulier, cette méthodologie permet la validation des bornes temporelles des services de TTA, c est-à-dire leur pire temps d exécution. Cette validation est effectuée sous certaines hypothèses de fautes, qui ont été modélisées et intégrées à la validation. Elle se base sur la méthode de model checking, c est-à-dire la vérification de propriétés par un parcours exhaustif de l ensemble des comportements possibles du système. La première phase de cette méthodologie consiste en la conception d un modèle abstrait validé du système. Pour cela, une première étude a été effectuée afin de déterminer un formalisme adapté à la modélisation de l architecture cible. Afin de représenter ses contraintes, différentes notions devront être exprimables par ce formalisme. Les systèmes distribués nécessitent la modélisation du parallélisme et de la concurrence, les systèmes temps réel exigent l expression du temps quantitatif et des contraintes temporelles strictes, et la modélisation du niveau applicatif implique la modélisation des données. Sur ces critères, plusieurs formalismes ont été dans un premier temps sélectionnés par une étude théorique de leur pouvoir d expression : les réseaux de Petri temporels, SDL, les TSA de l outil UPPAAL, les automates hybrides et IF. Puis ces formalismes ont été analysés par leur pouvoir d analyse, c est-à-dire par leur méthode d analyse associée. Cette étude théorique permet une première évaluation des complexités de ces méthodes d analyse. Une étude expérimentale a ensuite été menée sur la comparaison de deux approches de modélisation de l architecture TTA : d une part les TSA et d autre part une association des réseaux de Petri temporels et de SDL. Ces formalismes ont, dans un premier temps, été choisis dans le cadre d une étude de l influence de la désynchronisation des horloges. Cela implique la considération de différentes échelles de temps, a priori mieux gérées par une représentation du temps continue. L approche associant les deux formalismes RdPT et SDL est basée sur la décomposition de TTA en deux sous-systèmes, hôte et communication, modélisé chacun par l un des formalismes. La comparaison se place dans le cadre de la validation d un modèle simple de l architecture : le fonctionnement normal avec réintégration. Les mesures de performances du processus de validation montrent que les TSA et l outil UPPAAL sont largement plus efficaces que l association des formalismes SDL et réseaux de Petri temporels. Cette étude, couplée à la considération de la complexité théorique des méthodes d analyse considérées, nous a permis d écarter définitivement ces deux derniers formalismes. L outil UPPAAL est apparu comme un environnement bien adapté à notre contexte. Il permet de plus une modélisation continue du temps, plus précise que la représentation discrète considérée dans IF. Enfin, la représentation des horloges est la seule composante continue du système TTA. L utilisation des automates hybrides, qui permettent la modélisation de systèmes hybrides à variables continues et discrètes n est donc pas indispensable. Une expériemntation de la validation d un modèle simplifié de TTA avec l outil HyTech a en effet montré que la richesse d expression de ce formalisme limite rapidement cet outil par l explosion combinatoire. UPPAAL a donc été choisi pour la modélisation et la validation temporelle de TTA. Une analyse plus poussée, tant sur le plan théorique qu expérimental, serait cependant intéressante pour réellement comparer ces deux formalismes. Une telle comparaison permettrait également d étudier les concepts de représentation du temps continu et discret dans notre contexte. Dans ce cadre, une comparaison avec la méthode de validation présentée dans [SRSP04], proche de la nôtre mais basée sur une abstraction discrète du temps dans le modèle de TTA serait également intéressante. Nos bornes ont été comparées avec une borne validée par la méthodologie décrite dans [SRSP04]. Les premiers résultats semblent montrer que notre approche est 159

160 plus efficace et complète pour la validation des bornes temporelles. Une étude plus poussée reste à faire, des contacts ont été pris dans ce but avec les auteurs de cet article. Ainsi le choix d un formalisme de modélisation s est porté sur les TSA de l outil UPPAAL et sa méthode d analyse associée. Cependant, la modélisation des différents services de TTA et des scénarios de fautes considérés pour la validation, implique une augmentation de la complexité du modèle, et donc du processus d analyse. Une étude supplémentaire a donc été menée sur les techniques d optimisation de ce processus. Certaines optimisations de l algorithme de model checking ou de l implémentation mémoire des états sont intégrées à l outil UPPAAL. Elles ne suffisent cependant pas toujours, et des abstractions du modèle ont été effectuées afin de réduire la complexité de l analyse. Ces abstractions, inspirées de techniques d abstraction existantes, sont également en grande partie dépendantes du système et de sa modélisation. Un début de formalisation de certaines règles d abstraction est donné, dans le but de les généraliser ou de les automatiser. Une étude est actuellement en cours pour l application de ces abstractions sur une modélisation UPPAAL du réseau CAN. Des travaux plus poussés dans ce domaine pourraient permettre de définir des règles formelles génériques, applicables automatiquement sur différents systèmes. Des expérimentations ont prouvé que ces techniques sont efficaces pour l architecture TTA et permettent ainsi d obtenir un modèle de l architecture TTA efficace pour la validation. Une illustration pratique de notre méthodologie est ensuite donnée, par la validation des bornes temporelles de deux services de TTA, la réintégration et la détection d une perte de membership, puis de leur borne composée. Ces différents services, ainsi que l étape d analyse conduisant à l obtention de leurs bornes temporelles, sont décrits en détail. Un tableau récapitulatif de l ensemble des bornes temporelles validées au cours de nos travaux est donné pour la plupart des services de TTA validés sous les hypothèses de l architecture. Enfin, un exemple d utilisation de nos bornes est présenté dans le cadre de l étude de la qualité d un système contrôle-commande. Une méthodologie est développée et illustrée sur un exemple pour en prouver la faisabilité, qui intègre l influence de la traversée d un réseau TTP/C en présence de fautes. La méthodologie présentée dans cette thèse est consacrée à la validation de l architecture TTA en présence de fautes. Nos travaux ont conduit à la validation d un certain nombre de bornes temporelles en présence de fautes. Le problème de la validation est cependant très large, et les possibilités de validation restent très spécifiques. Par exemple dans notre cas, les bornes données sont liées à la topologie en bus de l architecture, et devront être validées à nouveau pour le passage à la topologie en étoile. De même, les hypothèses de fautes considérées pour ces validations ont été fixées par les hypothèses données par l architecture TTA. Afin de vérifier le comportement de l architecture dans des scénarios de fautes différents, une nouvelle phase de validation devra être effectuée avec de nouveaux modèles de fautes. Enfin, les bornes données sont pour la plupart dépendantes de l architecture. Bien que la plupart de ces bornes soient aisément généralisables à un nombre quelconque de SRU, une étape d analyse supplémentaire devra être réalisée. Toutes ces considérations montrent que le domaine de la validation de TTA reste encore incomplet. Perspectives La méthodologie de validation présentée dans cette thèse intègre une abstraction du niveau applicatif et du système d exploitation. Ces couches sont abstraites en incluant leur comportement temporel de façon simplifiée. Cette abstraction repose sur la technologie time-triggered qui fournit un ordonnancement statique des tâches applicatives prédéfini. Il serait intéressant d envisager la modélisation complète du système d exploitation, ce qui permettrait d intégrer des instants d émission et de réception plus réalistes au niveau applicatif. Cette extension semble envisageable dans le cas d une architecture entièrement déterministe comme TTA, mais certainement plus complexe dans le cas d architecture plus 160

161 flexible comme FlexRay. Or la validation de cette dernière architecture impose la représentation du comportement de ses couches supérieures (système d exploitation et application), la plupart des mécanismes de tolérance aux fautes étant situés à ce niveau. L intégration du comportement réel du niveau applicatif dans notre méthodologie engendrera sans doute une grande complexité dans le cadre de la validation formelle du modèle complet. Une décomposition par hiérarchisation de la validation sera sans doute nécessaire. Notre méthodologie permet la validation temporelle de TTA sous différents scénarios de fautes. Cependant, cette méthodologie pourrait être remise en cause par la considération d hypothèses de fautes plus complexes, et peut-être plus réalistes, écartées par les concepteurs de TTA. Par exemple les rafales de fautes, problème typique des applications de l avionique, ont été considérées comme très rares, voire improbables. Cette situation est cependant réelle, et serait intéressante à soumettre à un système critique pour l étude de son comportement, ne serait-ce que pour tester l efficacité de sa stratégie Never Give Up dans ce cas particulier. La considération de fautes aussi complexes nécessitera sans doute des modifications de notre méthodologie, en particulier dans le choix du formalisme de modélisation pour lequel une approche probabiliste sera certainement plus adaptée à la complexité du problème. Notre méthodologie a été définie et appliquée sur l architecture TTA. Certains de ces éléments, comme le formalisme de modélisation sélectionné ou les abstractions appliquées sur le modèle, sont spécifiques à cette architecture, mais peuvent s appliquer à d autres architectures. En effet, la nécessité de validation temporelle en présence de fautes est une réalité pour un grand nombre d architectures temps réel et critiques sur le plan de la fiabilité. Dans le contexte automobile, plusieurs architectures ont été conçues dans le but de répondre aux mêmes contraintes que TTA. FlexRay est le concurrent annoncé de TTA. Développé par un consortium puissant d industriels, il est basé sur un mélange des technologies time-triggered et event-triggered. Beaucoup plus récente que TTA, cette architecture n a pas encore été soumise à des processus de validation formelle permettant la validation de l architecture complète et des bornes temporelles de ses services. Il pourrait donc être intéressant de considérer l application de notre méthodologie pour la validation temporelle de cette architecture. De même, l architecture TTCAN, implémentant une technologie Time-Triggered au niveau applicatif au-dessus du bus CAN, est une architecture créée dans le but de remplir les contraintes du contexte des applications embarquées critiques dans l automobile. Cette architecture également récente a besoin d être validée. Les deux architectures concurrentes TTA et FlexRay s opposent sur leur principe même. Bien que toutes deux conçues dans le même contexte et pour répondre aux mêmes contraintes, elles se basent sur deux concepts antinomiques : la flexibilité et la maîtrise du comportement applicatif. La réduction de la flexibilité par la conception d un ordonnancement statique, comme dans TTA, impose d une part des contraintes de conception sur les applications et implique d autre part une étape supplémentaire dans leur cycle de conception. Par contre, plus de flexibilité ne permet plus l intégration de mécanismes de tolérance aux fautes qui étaient basés sur une maîtrise du comportement. Le choix d une architecture et son intégration dans le cycle de développement des véhicules représente un gros investissement pour les constructeurs. L architecture TTA implique des contraintes financières et de conception que n impose pas FlexRay. Les constructeurs ont donc besoin d une garantie du bon fonctionnement de l architecture, afin de justifier cet investissement. De même, FlexRay prône plus de flexibilité au détriment de l intégration directe de la tolérance aux fautes au sein de l architecture. Un processus de validation fiable est nécessaire pour évaluer les conséquences de cette réduction de la tolérance aux fautes au niveau architecture. L utilisation d une méthodologie commune pourrait faciliter la comparaison entre ces deux architectures. Alors que dans un futur proche, les constructeurs automobiles devront choisir l une de ces architectures, une telle comparaison permettrait de fournir des arguments pour l évaluation de leur fiabilité et pourrait procurer des critères scientifiques pour le choix de l une ou de l autre. Cependant, le contexte industriel est rarement aussi simple. Les standards émergeant à un instant donné ne sont pas forcément le résultat d un choix unanime sur une évidence d efficacité. Le poids 161

162 politique et économique d un industriel ou plus souvent d un groupe d industriels, influence souvent beaucoup plus le marché que les considérations scientifiques pures. Ainsi, l architecture TTA, bien que semblant bien adaptée au contexte des applications X-by-wire, n a pas réussi à s imposer immédiatement dans l automobile. Elle est fortement concurrencée par FlexRay qui est appuyé par de puissants partenaires. Le consortium FlexRay comprend en effet un grand nombre de constructeurs et d équipementiers souvent très influents dans le domaine automobile. De même, l architecture TTCAN, ne reposant pas sur un consortium de constructeurs, est relativement peu connue du milieu industriel. La situation est donc actuellement bloquée et hésitante, en attente de la validation de FlexRay ou de la décision économique d un ou plusieurs géants du marché. Enfin, une dernière réflexion plus humaniste s adressera aux amoureux du sport automobile et de la mécanique. La gestion des applications critiques par des systèmes embarqués est un problème complexe, impliquant des technologies et des méthodes nouvelles. Ce concept sera donc long et difficile à mettre en œuvre, comme tout nouveau standard plus ou moins révolutionnaire. Cependant, cette évolution semble définitivement inévitable et les voitures considérées comme idéales par les constructeurs, comme les prototypes futuristes présentés aujourd hui dans les salons automobile, sont loin des anciennes voitures entièrement mécaniques. L avenir nous montrera peut-être les voitures de nos parents comme de vieilles reliques à la technologie oubliée, comme sont considérées de nos jours les voitures hippomobiles que la mécanique avait elle-même exclues de notre vie. 162

163 163

164 Bibliographie [ABL98] L. Aceto, A. Bergueno, and K. G. Larsen. Model checking via reachability testing for timed automata. In Bernhard Steffen, editor, Proc. of the 4th Int. Workshop on Tools and Algorithms for the Construction and Analysis of Systems, pages , Lisbon, Portugal, Gulbenkian Foundation. [ABST03] Astrit Ademaj, Günther Bauer, Hakan Sivencrona, and Jan Torin. Evaluation of fault handling of the time-triggered architecture with bus and star topology. In IEEE International Conference on Dependable Systems and Networks (DSN 2003), San Francisco, USA, June [ACD93] [ACHH92] [ACLdSS04] R. Alur, C. Courcoubetis, and D. L. Dill. Model-checking in dense real-time. Journal of Information and Computation, 104(1) :2 34, Rajeev Alur, Costas Courcoubetis, Thomas A. Henzinger, and Pei-Hsin Ho. Hybrid automata : An algorithmic approach to the specification and verification of hybrid systems. In Hybrid Systems, pages , Ludovic Apvrille, Jean-Pierre Courtiat, Christophe Lohr, and Pierre de Saqui-Sannes. Turtle : A real-time uml profile supported by a formal validation toolkit. IEEE Trans. Software Eng., 30(7) : , [AD90] R. Alur and D. L. Dill. Automata for modeling real-time systems. Proc. of 7th Int. Colloquium on Automata, Languages and Programming, pages , Springer- Verlag. [AD94] [Ade02] [Ade03a] [Ade03b] [AdSSL 01] [AHGH02] R. Alur and D. L. Dill. A theory of timed automata. Journal of Theoretical Computer Science, 126(2) : , Astrit Ademaj. Slightly-off-specification failures in the time-triggered architecture. In Seventh Annual IEEE International Workshop on High Level Design Validation and Test, pages 7 12, Astrit Ademaj. Achieving fail silence in the time-triggered architecture. 6th IEEE Int. Workshop on Design and Diagnostics of Electronics Circuits and Systems (DDECS 03), April Poznan, Poland. Astrit Ademaj. Assessment of Error Detection Mechanisms of the Time-Triggered Architecture Using Fault Injection. PhD thesis, Technische Universität Wien, Institut für Technische Informatik, Treitlstr. 3/3/182-1, 1040 Vienna, Austria, L. Apvrille, P. de Saqui-Sannes, C. Lohr, P. Sénac, and J.-P. Courtiat. A new UML profile for real-time system formal design and validation. In Martin Gogolla and Cris Kobryn, editors, UML The Unified Modeling Language. Modeling Languages, Concepts, and Tools. 4th International Conference, Toronto, Canada, October 2001, Proceedings, volume 2185 of LNCS, pages Springer, Astrit Ademaj, Pavel Herout, Petr Grillinger, and Jan Hlavicka. Fault tolerance evaluation using two software based fault injection methods. In International On-Line testing Workshop, France, July

165 [AHH96] [Alu91] [And94] Rajeev Alur, Thomas A. Henzinger, and Pei-Hsin Ho. Automatic symbolic verification of embedded systems. IEEE Trans. Softw. Eng., 22(3) : , Rajeev Alur. Techniques for Automatics Verification of Real Time Systems. PhD thesis, Standford University, H.R. Andersen. Model checking and boolean graphs. Journal of Theoretical Computer Science, 126(1) :330, [Bau01] Günther Bauer. Transparent Fault Tolerance in a Time-Triggered Architecture. PhD thesis, Technische Universität Wien, Institut für Technische Informatik, Treitlstr. 3/3/182-1, 1040 Vienna, Austria, [BBD 02] [BD91] [Ben01] [Ber83] G. Behrmann, J. Bengtsson, A. David, K. G. Larsen, P. Pettersson, and W. Yi. Uppaal implementation secrets. In Proc. of the 7th Int. Symp. on Formal Techniques in Real- Time and Fault-Tolerant Systems, pages 3 22, Oldenburg, Germany, September Springer-Verlag. Bernard Berthomieu and Michel Diaz. Modeling and verification of time dependent systems using time Petri nets. IEEE Transactions on Software Engineering, 17(3) : , Johan Bengtsson. Reducing memory usage in symbolic state-space exploration for timed systems. Technical Report , Uppsala universitet, Institutionen för informationsteknologi, May B. Berthomieu. An enumerative approach for analyzing time petri nets. In IFIP Congress Series, volume 9, pages 41 46, North Holland, [Ber01] B. Berthomieu. La méthode des classes d états pour l analyse des réseaux temporels - mise en oeuvre. In Actes de Modélisation des Systèmes Réactifs, Toulouse, France, Octobre [BF99] [BFG 99] [BFG 00] [BGK 00] [BGMO04] [BJLY98] Béatrice Bérard and Laurent Fribourg. Automated verification of a parametric real-time program : The ABR conformance protocol. In Nicolas Halbwachs and Doron Peled, editors, Proceedings of the 11th International Conference on Computer Aided Verification (CAV 99), volume 1633 of Lecture Notes in Computer Science, pages , Trento, Italy, July Springer. M. Bozga, J.C. Fernandez, L. Ghirvu, S. Graf, J.P. Krimm, L. Mounier, and J. Sifakis. If : An Intermediate Representation for SDL and its Applications. In Proc. of SDL- FORUM 99, Montreal, Canada, M. Bozga, J.C. Fernandez, L. Ghirvu, S. Graf, J.P. Krimm, and L. Mounier. IF : A validation environment for timed asynchronous systems. In Proc. of Computer Aided Verification (CAV 00), Chicago, USA, Marius Bozga, Susanne Graf, Alain Kerbrat, Laurent Mounier, Iulian Ober, and Daniel Vincent. SDL for Real-Time : What is Missing? In Proc. of 2nd Workshop on SDL and MSC (SAM 00), pages , Grenoble, France, June IMAG. Marius Bozga, Susanne Graf, Laurent Mounier, and Iulian Ober. If tutorial. Presented at the 9th SPIN 04 Workshop on Model-Checking of Software, Barcelona, Spain, April Johan Bengtsson, Bengt Jonsson, Johan Lilius, and Wang Yi. Partial order reductions for timed systems. In Proc. of the 9th International Conference on Concurrency Theory, pages , Nice, France, September Springer-Verlag. 165

166 [BK00] [BKP01] [BKS03] [BLP 99] [BM02] [Boy01] [BP00] [BY04] [Cas00] [CSLO00] [DAN00] [DBLY03] [Dil90] [DT98] [DY96] Günther Bauer and Hermann Kopetz. Transparent redundancy in the time-triggered architecture. In International Conference on Dependable Systems and Networks (ICDSN 2000), New York, NY, US, June Günther Bauer, Hermann Kopetz, and Peter Puschner. Assumption coverage under different failure modes in the time-triggered architecture. In Proc. of the 8th IEEE International Conference on Emerging Technologies and Factory Automation, pages , Antibes Juan les Pins, France, October Günther Bauer, Hermann Kopetz, and Wilfried Steiner. The central guardian approach to enforce fault isolation in the time-triggered architecture. In Proc. of the Sixth International Symposium on Autonomous Decentralized Systems (ISADS 03), pages 37 44, Pisa, Italy, April Gerd Behrmann, Kim Guldstrand Larsen, Justin Pearson, Carsten Weise, and Wang Yi. Efficient timed reachability analysis using clock difference diagrams. In Proceedings of the 11th International Conference on Computer Aided Verification, pages , Trento, Italy, July Springer-Verlag. A. Bouajjani and A. Merceron. Parametric verification of a group membership algorithm. In 7th Int. Symp. on Formal Techniques in Real-Time and Fault Tolerant Systems, volume LNCS 2469, pages , Oldenburg (Germany), September Marc Boyer. Contribution à la modélisation des systèmes à temps contraint et application au multimédia. PhD thesis, Université Toulouse 3, Juillet Günther Bauer and Michael Paulitsch. An investigation of membership and clique avoidance in ttp/c. In 19th IEEE Symposium on Reliable Distributed Systems, Nürnberg, Germany, October Johan Bengtsson and Wang Yi. Timed automata : Semantics, algorithms and tools. In W. Reisig and G. Rozenberg, editors, Lecture Notes on Concurrency and Petri Nets, Lecture Notes in Computer Science vol Springer Verlag, Paolo Castelpietra. Modélisation modulaire pour l évaluation de performances d applications embarqués dans l automobile. Technical report, Firtech, Nancy (INPL), September J.P. Courtiat, C.A.S. Santos, C. Lohr, and B. Outtaj. Experience with rt-lotos, a temporal extension of the lotos formal description technique. Computer Communications, 23(12) : , Thi Xuan Thao DANG. Vérification et Synthèse des systèmes hybrides. PhD thesis, INPG - Institut National Polytechique de Grenoble, Octobre A. David, G. Behrmann, K. G. Larsen, and W. Yi. A tool architecture for the next generation of UPPAAL. Technical Report , Department of Information Technology, Uppsala University, February D. L. Dill. Timing assumptions and verification of finite-state concurrent systems. In Proc. of the international workshop on Automatic verification methods for finite state systems, pages , Grenoble, France, Springer-Verlag New York, Inc. C. Daws and S. Tripakis. Model checking of real-time reachability properties using abstractions. In In Tools and Algorithms for the Construction and Analysis of Systems TA- CAS 98, number 1384 in LNCS, Lisbon, Portugal, C. Daws and S. Yovine. Reducing the number of clock variables of timed automata. In IEEE Computer Society Press, editor, Proc. of the 17th IEEE Real Time Systems Symposium, RTSS 96, Washington, DC, USA, December

167 [DY00] [FBG03] Alexandre David and Wang Yi. Modelling and analysis of a commercial field bus protocol. In Proc. of the 12th Euromicro Conference on Real Time Systems (ECRTS00), pages , Stockholm, Sweden, June Jean-Claude Fernandez, Marius Bozga, and Lucian Ghirvu. State space reduction based on live variables analysis. Science of Computer Programming, 47(2-3) : , [Fuc95] Emmerich Fuchs. Cyclic redundancy codes (CRC) for TTP/C. Research Report 10/1995, Technische Universität Wien, Institut für Technische Informatik, Treitlstr., Vienna, Austria, [GA04] [GAM03a] [GAM03b] [GAM04] [Gil01] [Hex99] K. Godary and I. Augé Blum. Evaluation of model abstractions for the temporal validation of TTA with uppaal. Technical Report RR2004-2, Lab. CITI, INSA Lyon, K. Godary, I. Augé Blum, and A. Mignotte. Complémentarité entre SDL et les réseaux de Petri temporels pour la validation temporelle de TTA. In RTS & Embedded Systems, Paris, France, Avril K. Godary, I. Augé Blum, and A. Mignotte. SDL and time Petri nets link for TTA temporal validation. Technical Report RR2003-1, Lab. CITI, INSA Lyon, K. Godary, I. Augé Blum, and A. Mignotte. SDL and timed petri nets versus UPPAAL for the validation of embedded architecture in automotive. In Forum on specification & Design Language (FDL 04), Lille, France, September Petr Gillinger. Simulation model of TTP/C protocol. In 23th International Autumn Colloquium ASIS 2001, Advanced Simulation of Systems, MARQ, Czerch rep., René Hexel. Validation of Fault Tolerance Mechanisms in a Time-Triggered Communication Protocol using Fault Injection. Phd thesis, Technische Universität Wien, Institut für Technische Informatik, Treitlstr., Vienna, Austria, [HHMWT00] Thomas A. Henzinger, Benjamin Horowitz, Rupak Majumdar, and Howard Wong-Toi. Beyond hytech : Hybrid systems analysis using interval numerical methods. In HSCC, pages , [HHWT95] [HHWT97] Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. A user guide to hytech. In Tools and Algorithms for Construction and Analysis of Systems, pages 41 71, Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. HYTECH : A model checker for hybrid systems. International Journal on Software Tools for Technology Transfer, 1(1-2) : , [HNSY94] Thomas A. Henzinger, Xavier Nicollin, Joseph Sifakis, and Sergio Yovine. Symbolic model checking for real time systems. Journal of Information and Computation, 111(2) : , [HRH02] P. Herout, S. Racek, and J. Hlavicka. Model-based dependability evaluation method for ttp/c applications. In EDCC-4 - Fourth European Dependable Computing Conference, ISBN , pages pp , Toulouse, France, October [HS96] Klaus Havelund and Natarajan Shankar. Experiments in theorem proving and model checking for protocol verification. In Marie-Claude Gaudel and Jim Woodcock, editors, FME 96 : Industrial Benefit and Advances in Formal Methods, pages , Oxford UK, March Springler-Verlag. [HTI97] [HWT96] Mei-Chen Hsueh, Timothy K. Tsai, and Ravishankar K. Iyer. Fault injection techniques and tools. Computer, 30(4) :75 82, Thomas A. Henzinger and Howard Wong-Toi. Using hytech to synthesize control parameters for a steam boiler. In Formal Methods for Industrial Applications, volume 1165 of LNCS, pages Springer-Verlag,

168 [ISO88] [ISO93] [ITU00] [Jal94] [JGA04] [JHA 96] [JLS96] [JNS03] [JTAM03] [Kat01] [KB03] [KBP01] [KFA 95] [KG94] [KHE00] [KHK 97a] ISO Standard LOTOS, a formal descripion technique based on temporal ordering of observational behavior, International Standards Organisation. ISO Road Vehicles Interchange of digital information Controller area network (CAN) for high speed communication, ITU (International Telecommunication Union). Specification and Description Language - SDL, recommendation z.100 edition, Pankaj Jalote. Fault Tolerance in Distributed Systems. Prentice Hall, Englewood Cliffs, New Jersey, F. Jumel, K. Godary, and I. Augé Blum. Safety evaluation of controlled system distributed on tta architecture. In International Conference on Advances in Vehicle Control and Safety (AVCS 04), Genoa, Italy, October J. -C. Fernandez, H. Garavel, A. Kerbrat, L. Mounier, R. Mateescu, and M. Sighireanu. CADP : a protocol validation and verification toolbox. In Rajeev Alur and Thomas A. Henzinger, editors, Proc. of the Eighth International Conference on Computer Aided Verification CAV, volume 1102, pages , New Brunswick, NJ, USA, / Springer Verlag. H. E. Jensen, K. G. Larsen, and A. Skou. Modelling and analysis of a collision avoidance protocol using spin and uppaal. In Proc. of the 2nd SPIN Workshop, New Jersey, USA, August Rutgers University. Fabrice Jumel, Nicolas Navet, and Françoise Simonot. Influence des performances d une architecture informatique sur la fiabilité des systèmes échantillonnés. In RTS & Embedded Systems, Paris, France, F. Jumel, J-M. Thiriet, J-F Aubry, and O. Malasse. Towards an information-based approach for the dependability evaluation of distributed control system. In Proceedings of 21th IEEE Instrumentation and Measurement Technology Conference (IMTC 2004), Como, Italy, May Joost-Pieter Katoen. Principles of model checking. Lecture Notes, System Validation, Hermann Kopetz and Günther Bauer. The time-triggered architecture. Proc. of the IEEE, 91(1) : , January Hermann Kopetz, Günther Bauer, and Stefan Poledna. Tolerating arbitrary node failures in the time-triggered architecture. In Society of Automotive Engineers World Congress, Detroit, MI, USA, March J. Karlsson, P. Folkesson, J. Arlat, Y. Crouzet, and G. Leber. Predictably Dependable Computing Systems, pages pp Springer-Verlag, H. Kopetz and G. Grünsteidl. Ttp - a protocol for fault-tolerant real-time systems. Computer, 27(1) :14 23, January Hermann Kopetz, Michael Holzmann, and Wilfried Elmenreich. A universal smart transducer interface : TTP/A. In 3rd IEEE International Symposium on Object-oriented Realtime distributed Computing (ISORC 2000), Newport Beach, CA, USA, March Hermann Kopetz, René Hexel, Andreas Krüger, Dietmar Millinger, Roman Nossal, Andreas Steininger, Christopher Temple, Thomas Führer, Roman Pallierer, and Markus Krug. A prototype implementation of a TTP/C controller. In SAE Congress and Exhibition, Detroit, MI, USA, February SAE Paper No

169 [KHK 97b] [KK95] [KNH 97] [Kop97] [Kop98] [KR93] [LAB 96] Hermann Kopetz, René Hexel, Andreas Krüger, Dietmar Millinger, and Anton Schedl. A synchronization strategy for a TTP/C controller. In SAE Congress and Exhibition, Detroit, MI, USA, February SAE Paper No A. Krüger and H. Kopetz. A network controller interface for a time-triggered protocol. In Proc. of the SAE Symposium on Future Transportation Electronics : Multiplexing and In-Vehicle Networking, May Hermann Kopetz, Roman Nossal, René Hexel, Andreas Krüger, Dietmar Millinger, Roman Pallierer, Christopher Temple, and Markus Krug. Mode handling in the timetriggered architecture. In Proc. of the 14th IFIP/IFAC Int. Conf. on Distributed Computer Control Systems (DCCS 97), Seoul, Korea, June Hermann Kopetz. Real-Time Systems : Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Hermann Kopetz. The time-triggered architecture. Proc. of the First International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 98), April Kyoto, Japan. Hermann Kopetz and Johannes Reisinger. Nbw : A non-blocking write protocol for task communication in real-time systems. In Proc. of the 14th Real-Time Systems Symposium (RTSS 93), pages , Raleig-Durban, NC, December J.C. Laprie, J. Arlat, J. Blanquart, A. Costes, Y. Crouzet, Y. Deswarte, J.C. Fabre, H. Guillermain, M. Kaâniche, K. Kanoun, C. Mazet, D. Powell, C. Rabéjac, and P. Thévenod. Guide de la Sûreté de Fonctionnement. Laboratoire d Ingénierie de la Sûreté de Fonctionnement, seconde edition edition, [LIN03] LIN Consortium. LIN Specification Package 2.0, September http :// [LLPY97] [LLPY03] [Loh02] [LP97] [LPY97] K.G. Larsen, F. Larsson, P. Pettersson, and W. Yi. Efficient verification of real-time systems : Compact data structure and state-space reduction. In Proc. of the 18th ICCC Real Time Systems Symposiums (RTSS 97), pages 14 24, San Francisco, California, USA, December Kim G. Larsen, Fredrik Larsson, Paul Pettersson, and Wang Yi. Compact data structures and state-space reduction for model-checking real-time systems. Real-Time Syst., 25(2-3) : , Christophe Lohr. Contribution à la spécification de système temps réel en s appuyant sur la technique de description formelle RT-LOTOS. PhD thesis, Institut National Polytechnique de Toulouse, décembre H. Lönn and P. Pettersson. Formal verification of a TDMA protocol startup mechanism. In Proc. of IEEE Pacific Rim International Symposium on Fault-Tolerant Systems (PRFTS 97), pages , Taipei, Taiwan, December K.G. Larsen, P. Pettersson, and W. Yi. UPPAAL in a nutshell. Int. Journal on Software Tools for Technology Transfer, 1(1) : , december [LUS04] Guillaume LUSSIER. Test guidé par la preuve. Application à la vérification d algorithmes de tolérance aux fautes. PhD thesis, INSA Toulouse, Septembre [Mai02] Reinhard Maier. TTP/C lecture. TTTech Services, May [Mer74] P.M. Merlin. A Study of the Recoverability of Computing Systems. Phd thesis, Irvine : Univ. California, Depart. of Information and Computer Sience, TR 58,

170 [Mer01] [Möl02] Stephan Merz. Model checking : A tutorial overview. In F. Cassez et al., editor, Modeling and Verification of Parallel Processes, volume 2067 of Lecture Notes in Computer Science, pages Springer-Verlag, Berlin, Oliver Möller. Structure and Hierarchy in Real-Time Systems. Phd thesis, BRICS PhD school, University of Aarhus, February [OMG01] OMG UML specification. Unified Modeling Language, v.1.4 edition, [ORSvH95] [OSE01a] Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures : Prolegomenato the design of PVS. IEEE Transactions on Software Engineering, 21(2) : , feb OSEK/VDX Steering Committee. OSEK/VDX Fault-Tolerant Communication Specification 1.0, July http :// [OSE01b] OSEK/VDX Steering Committee. OSEK/VDX Time-Triggered Operating System 1.0, July http :// [Pal00] Roman Pallierer. Validation of Distributed Algorithms in Time-Triggered Systems by Simulation. PhD thesis, Technische Universität Wien, Institut für Technische Informatik, Treitlstr. 3/3/182-1, 1040 Vienna, Austria, [Pet99] P. Pettersson. Modelling and Verification of Real-Time Systems Using Timed Automata : Theory and Practice. Phd thesis - technical report docs 99/101, Department of Computer Systems, Uppsala University, February [Pfe00] [Pfe03] Holger Pfeifer. Formal verification of the ttp group membership algorithm. In Tommaso Bolognesi and Diego Latella, editors, Formal Methods for Distributed System Development Proc. of FORTE XIII / PSTV XX 2000, pages 3 18, Pisa, Italy, October Kluwer Academic Publishers. Holger Pfeifer. Formal Analysis of Fault-Tolerant Algorithms in the Time-Triggered Architecture. PhD thesis, Universität Ulm, Germany, [PSvH99] Holger Pfeifer, Detlef Schwier, and Friedrich W. von Henke. Formal Verification for Time-Triggered Clock Synchronization. In Charles B. Weinstock and John Rushby (eds.), editors, Dependable Computing for Critical Applications 7, volume 12 of Dependable Computing and Fault-Tolerant Systems, pages IEEE Computer Society, January [PvH01] [Ram74] [Rin03] [Rus95] [Rus01a] [Rus01b] Holger Pfeifer and Friedrich W. von Henke. Formal Analysis for Dependability Properties : the Time-Triggered Architecture Example. In 8th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA 2001), pages , Antibes Juan-les-Pins, October C. Ramchandani. Analysis of asynchronous concurrent systems by Timed Petri Nets. PhD thesis, MIT Cambridge, MA, United Kingdom, M. Riner. Validation d architectures embarquées temps-réel pour l automobile. Technical Report RR2003-2, Lab CITI, INSA Lyon, juillet John Rushby. Formal methods and their role in the certification of critical systems. In Roger Shaw, editor, Safety and Reliability of Software Based Systems (Twelfth Annual CSR Workshop), pages 1 42, Bruges, Belgium, September Springer. John Rushby. A comparison of bus architectures for safety-critical embedded systems. Technical report, Computer Science Laboratory, SRI International, Menlo Park, CA, John Rushby. Formal verification of transmission window timing for the time-triggered architecture. Technical report, March

171 [Rus02] [SAE94] [SBB 99] [SRSP04] [STA02] J. Rushby. An overview of formal verification for the time-triggered architecture. In Werner Damm and Ernst-Rüdiger Olderog, editors, Formal Techniques in Real-Time and Fault-Tolerant Systems, volume 2469 of LNCS, pages , Oldenburg, Germany, Springer-Verlag. Class C multiplexing, part 1 jun93 applications requirements. I.R. J2056, SAE Society of Automotive Engineers, Warrendale, PA, Philippe Schnoebelen, Béatrice Bérard, Michel Bidoit, François Laroussinie, and Antoine Petit. Vérification de logiciels : techniques et outils du model-checking. Vuibert, April Wilfried Steiner, John Rushby, Maria Sorea, and Holger Pfeifer. Model Checking a Fault- Tolerant Startup Algorithm : From Design Exploration To Exhaustive Fault Simulation. In Proc. of the International Conference on Dependable Systems and Networks (DSN 2004), Florence, Italy, June Hakan Sivencrona, Jan Torin, and Astrit Ademaj. Deployment of different fault injection techniques with respect to design phase and functional level. In Proc. of the International Conference on Dependable Systems and Networks (DSN 2002), Washington DC, USA, June [Tan96] Andrew Tanenbaum. Computer Networks, volume Third Edition. Prentice Hall Inc., [Tel04] [Tem98] [TOM97] [Tom98] Telelogic, Inc. TELELOGIC OBJECTGEODE - A SDL tools for real time systems development, http :// Christopher Temple. Avoiding the babbling-idiot failure in a time-triggered communication system. In 28th International Symposium on FTCS, München, Germany, June T. Stauner, O. Mueller, and M. Fuchs. Using HYTECH to verify an automotive control system. In O. Maler, editor, Hybrid and Real-Time Systems, pages , Grenoble, France, Springer Verlag, LNCS C. J. Tomlin. Hybrid Control of Air Traffic Management Systems. PhD thesis, Department of Electrical Engineering and Computer Sciences, University of California at Berkeley, [TTT03] TTTech Computertechnik AG, Time-Triggered Technology, Vienna, Austria. Time- Triggered Protocol TTP/C, High-Level Specification Document - edition 1.4.3, November http :// [WM85] [Zie96] P. Ward and S. Mellor. Structured Development for Real-Time Systems. Prentice Hall, Christian Ziegler. Sûreté de fonctionnement d architectures informatiques embarquées sur automobile. PhD thesis, Laboratoire d Analyse et d Architecture des Systèmes du CNRS, Institut National Polytechnique de Toulouse,

172 172

173 Bibliographie de l auteur 3.4 Publications internationales [ISSS 01] Antoine Fraboulet, Karen Godary and Anne Mignotte, Loop Fusion for Memory Space Optimization, in International Symposium on System Synthesis (ISSS 01), Montreal, Canada, October [DIPES 04] K. Godary, I. Augé Blum and A. Mignotte, Temporal Bounds for TTA : Validation, Proc. of the IFIP Working Conference on Distributed and Parallel Embedded Systems (DIPES 04), Toulouse, France, August [FDL 04] K. Godary, I. Augé Blum and A. Mignotte, SDL and Timed Petri Nets versus UPPAAL for the validation of embedded architecture in automotive, Forum on specification & Design Language (FDL 04), Lille,France, September [AVCS 04] F. Jumel, K. Godary and I. Augé Blum, Safety Evaluation of Controlled System distributed on TTA Architecture, International Conference on Advances in Vehicle Control and Safety (AVCS 04), Genoa, Italy, October Publications nationales [RTS 03] K. Godary, I. Augé Blum et A. Mignotte, Complémentarité entre SDL et les Réseaux de Petri temporels pour la validation temporelle de TTA, RTS & Embedded Systems, Paris, France, Avril Rapports internes de recherche [n RR2001-1] K. Godary, I. Augé Blum, A. Mignotte, Estimation du WCET d un programme, Rapport de recherche n RR2001-1, lab. CITI, INSA Lyon, juillet [n RR2002-1] K. Godary, I. Augé Blum, A. Mignotte, TTA - Architecture embarquée temps-réel tolérante aux fautes, Rapport de recherche n RR2002-1, lab. CITI, INSA Lyon, juillet

174 [n RR2003-1] K. Godary, I. Augé Blum, A. Mignotte, SDL and Time Petri Nets link for TTA temporal validation, Research report n RR2003-1, lab. CITI, INSA Lyon, [n RR2004-2] K. Godary, I. Augé Blum, Model abstractions for the temporal validation of TTA with UPPAAL, Research report n RR2004-2, lab. CITI, INSA Lyon, [n RR2004-3] K. Godary, I. Augé Blum, A. Mignotte, Temporal Bounds for TTA : Validation, Research report n RR2004-3, lab. CITI, INSA Lyon, juin [n RR2004-4] K. Godary, I. Augé Blum, A. Mignotte, Validation Temporelle des Services de TTA, Rapport de recherche n RR2004-4, lab. CITI, INSA Lyon, juin Confidentiel. 174