Précédent : Résultats nouveaux Remonter : Projet PAMPA, Modèles et outils Suivant : Actions régionales, nationales et internationales
Précédent : Résultats nouveaux Remonter :
Projet PAMPA, Modèles et
outils Suivant : Actions régionales,
nationales et internationales
Contrat CTI-CNET ref. 95 1B 151 - Novembre 1994-Novembre 1998
Participants : Claude Jard , Renée Boubour .
Mots-clés : gestion de réseau, supervision, gestion
d'alarmes, diagnostic, systèmes distribués, réseaux de Petri,
HMM
Gestion de réseau: désigne la couche haute de gestion d'un
réseau de télécommunications (surveillance, maintenance,
etc).
Supervision: opérations de surveillance, diagnostic et
reconfiguration du réseau.
Gestion d'alarmes: opérations de traitement, filtrage
et interprétation des alarmes circulant sur le réseau.
Diagnostic: interprétation des alarmes en vue des
opérations de reconfiguration et maintenance.
HMM: Hidden Markov Models (Modèles de Markov Cachés),
technique consistant à inférer, à partir d'observations
``bruitées'', l'état interne caché d'un automate stochastique (ou
chaîne de Markov). Technique très utilisée en reconnaissance de
la parole, et plus récemment dans le diganostic de systèmes
dynamiques discrets ou hybrides. Nous étendons cette technique
aux réseaux de Petri.
Résumé : Cette activité est commune avec le projet SIGMA2, et se situe dans le cadre de la CTI-CNET 95 1B 151. Il s'agit de développer une approche systématique pour le diagnostic de réseaux de télécommunications, avec les objectifs suivants:
- prendre en compte explicitement le caractère distribué des réseaux,
- suivre une approche ``modèle'', modèle sur lequel s'appuiera l'algorithme de diagnostic,
- prendre en compte les aléas (perte d'alarme, confusions possibles,...),
- viser une mise en oeuvre du logiciel de diagnostic qui soit répartie sur le réseau.
Une technologie originale, fondée sur une notion nouvelle de Réseau de Petri stochastique conforme au point de vue dit de la ``concurrence vraie'' a été développée. Cette technologie nous permet naturellement de prendre en compte toutes les contraintes qui résultent du contexte ``distribué'' où nous nous situons.
Nous avons opté pour un cadre approprié à la description des états de fonctionnement des systèmes distribués, à savoir les Réseaux de Petri saufs (RdP) avec une sémantique adaptée au cadre de la vraie concurrence. Dans ce but, nous utilisons un modèle de temps en ``ordre partiel'': deux événements ne sont ordonnés que s'ils surviennent sur un même site, ou bien s'ils sont reliés par une relation de causalité (par exemple en tête et en queue d'une communication). Les techniques indiquées ci-après doivent être adaptées à ce point de vue ``ordres partiels'', ce qui fait la difficulté du sujet.
Le RdP permet de décrire l'apparition spontanée de pannes ou dysfonctionnements, ainsi que leur propagation et effets induits. Il joue ainsi, dans un cadre dynamique et distribué, le rôle d'arbre de défaillances. Le franchissement d'une transition matérialise un changement d'état de (dys)fonctionnement et cause l'émission d'un faisceau d'alarmes observées de manière répartie sur le réseau. Les transitions et l'émission des alarmes peuvent être randomisées (tout particulièrement la perte éventuelle des alarmes).
Le diagnostic est alors effectué par le biais 1/ du calcul à la volée de l'ensemble des trajectoires d'état interne compatibles avec les alarmes observées, et, en cas de multiplicité de solutions, 2/ le calcul de la trajectoire la plus probable par une technique de maximum de vraisemblance mise en oeuvre via une programmation dynamique généralisée aux systèmes distribués.
Pour réaliser le programme décrit plus haut, il nous a fallu 1/ développer une technique d'observateur d'état fondée sur une technique de dépliage de RdP, 2/ créer une nouvelle notion de RdP stochastique adaptée à la sémantique en ordres partiels et aux techniques de dépliage, 3/ étendre l'algorithme de Viterbi calculant la trajectoire d'état de vraisemblance maximale pour un automate stochastique aux RdP avec interprétation en ordres patiels. Le détail de ces techniques est décrit dans le rapport d'activité du projet Sigma2.
Un maquettage du logiciel correspondant est en cours de réalisation par Renée Boubour (projet PAMPA) et Armen Aghasarian (projet SIGMA2). Ce maquettage ne traite pas de la répartition du superviseur sur le réseau, seule une mise en oeuvre centralisée est donnée pour l'instant. L'application support est une partie de réseau SDH.
Participants : César Viho , Hakim Kahlouche , Claude Jard
, Thierry Jéron
Mots-clés : architecture multi-processeurs, hardware,
cohérence de caches, vérification formelle, génération de
tests
Résumé : Ce travail qui a démarré en 1996 pour le projet Pampa, s'effectue dans le cadre de l'action VASY (Validation de Systèmes) du GIE (Groupement d'Intérêt économique) Bull-Inria Dyade. En collaboration avec l'Inria Rhône-Alpes (H. Garavel), il s'agit de fournir des méthodes et outils pour la vérification formelle et le test du protocole de cohérence de caches de l'architecture multi-processeurs Polykid en cours de développement à Bull-Italie.
Sur la base de la spécification formelle en LOTOS (langage de
spécification formelle normalisé par l'ISO) de l'architecture
fournie par l'Inria Rhône-Alpes (qui s'occupe également de sa
vérification formelle), le projet Pampa utilise son prototype TGV
pour générer automatiquement des suites de tests abstraits pour
le protocole de cohérences de caches. Ceci a permis :
Nous sommes actuellement dans la phase de traduction des tests abstraits en tests exécutables qui doit aboutir à la mise en oeuvre de ces tests sur la plate-forme réelle de test à Bull-Italie.
Contrat INRIA 1 97 C699 00 31318 01 1, Octobre 1997 - Juillet 1998
Participants : Jean-Marc Jézéquel , Alain Le Guennec
, Claude Jard , Thierry Jéron , Benoît Caillaud
Mots-clés : validation formelle, UML, technologies
objets
Résumé : L'objectif de ce projet de collaboration Irisa/Pampa-Softeam est d'étudier la faisabilité de l'intégration des technologies de validation formelle de logiciel distribué dans un cycle de vie objet, afin de pouvoir relever le défi du déploiement de services distribués fiables (client-serveurs et autres multimedia), i.e. dépourvus de bogues logiciels dues à l'asynchronisme et au non-déterminisme.
L'élaboration de ce pont technologique entre technologie objet d'un côté et validation formelle de l'autre permettrait d'envisager la construction d'un environnement de développement intégré permettant de mener conjointement toutes les phases d'un projet industriel de haute qualité dans le domaine des objets distribués.
Pour la première fois, nous associons :
Le projet Pampa apporte son expertise en matière de technologie objet et de technologie de validation formelle, Softeam apporte sa maîtrise dans le domaine de l'analyse et de la conception par objet (avec notamment la méthode ClassRelation, seule méthode objet d'origine française largement référencée au niveau international) ainsi qu'un environnement de développement ouvert (Objecteering) dans lequel il est possible d'intégrer de nouveaux outils.
Participants : Jean-Louis Pazat , Hugues Leroy (Ingénieur
atelier)
Mots-clés : HPF, Cenju-3
Résumé : L'Inria et NEC Corporation (NEC) lancent sur deux ans une recherche conjointe dans le traitement parallèle. Pour soutenir ce projet, NEC a installé à l'Irisa le dernier-né de ses calculateurs parallèles, le Cenju-3. Coordonnées par le projet CAPS, l'Inria compte mener trois actions d'évaluation sur cette machine.
L'action du projet PAMPA consiste à évaluer le code produit par le compilateur HPF (High Performance Fortran) pour le Cenju-3. Le projet Pampa a été choisi pour sa longue expérience en la matière, notamment du fait de sa participation au projet européen Esprit Prepare.
Contrat INRIA 1 97 A663 00 000MC 005, Septembre 1997 - Février 1999
Participants : Benoît Caillaud , Claude Jard , Thierry
Jéron
Mots-clés : OSEK, Protocoles automobiles, génération de
tests, TGV
Résumé : Projet européen R & D conduit par Dassault électronique, en collaboration avec plusieurs constructeurs automobiles, Modistarc a pour objectif de mettre en place une méthodologie de tests pour les protocoles de communications et de gestion embarqués sur les automobiles. Le projet Pampa participe en proposant une méthode automatique de génération de tests partant des spécifications formelles LDS existantes et en mettant le prototype TGV à disposition de Dassault.
Statut du projet
Objectifs et résultats
L'objectif du projet MODISTARC est de contribuer à l'effort des industriels Européens du secteur automobile pour développer une architecture normalisée de systèmes répartis embarqués pour l'automobile. Dans le cadre des activités du consortium OSEK/VDX (Open systems and the corresponding interfaces for automotive electronics), les industriels Européens de l'automobile ont défini trois nouveaux standards : un système d'exploitation pour calculateurs embarqués (ECU) pour l'automobile (OSEK/VDX OS), un protocole de communication inter et intra ECU (OSEK/VDX COM) et un protocole de gestion de réseaux idoine (OSEK/VDX NM). Ces standards ont pour vocation, d'une part de permettre la portabilité des applications d'un système à un autre et d'autre part, de permettre l'interopérabilité des plate-formes et des applications à l'intérieur d'un même système.
Les travaux au sein de projet MODISTARC portent sur :
Contribution du projet Pampa
La participation du projet Pampa porte sur la définition de la
méthodologie de test pour la communication et la gestion de
réseaux. La solution préconisée est la génération automatique des
cas de tests à partir des spécifications formelles des protocoles
COM et NM. L'outil de génération employé sera TGV
(voir ![[*]](../icons/cross_ref_motif.gif){kind=icon}
).
Pour la durée du projet, l'outil TGV sera mis à la disposition de
Dassault Électronique qui effectuera le travail de production des
cas de tests. Nous traitons en ce moment une étude de cas
simplifiée fournie par Renault pour démontrer l'intérêt de notre
technologie.
Contrat Inria n° 1 97 A 93600 000MC012, Novembre 1995 - Février 2001
Participants : Claude Jard , Jean-Marc Jézéquel , Benoît
Caillaud , Zakaria Bouziane , Hubert Canon , Thierry Jéron .
Mots-clés : Méthode, UML, langage d'interface, IDL,
BDL, synchrone, objets
Résumé : La collaboration avec Alcatel a commencé en novembre 1995 dans le cadre de l'appel Artica du ministère de la recherche et la mise à disposition d'un post-doctorant Inria chez Alcatel en 1996. En septembre 1997, elle a pris un nouvel essor avec un contrat direct avec Alcatel permettant le démarrage de plusieurs thèses. Claude Jard en est le coordinateur à l'Inria. L'objectif de la collaboration est la maîtrise du développement logiciel d'applications de télécommunication par la conception d'outils de manipulations formelles à l'intérieur d'une chaîne de développement définie par Alcatel. Cinq équipes de l'Inria participent au projet (Adp, Compose, Ep-Atr, Meije et Pampa) autour de quatre actions scientifiques. Pampa est principalement engagé avec Ep-Atr dans la définition et l'outillage d'un langage d'interface appelé BDL.
Le défi pour Alcatel est de réduire les coûts de développement tout en améliorant la qualité du logiciel. Il s'agit aussi d'assurer une flexibilité et réactivité élevées en regard des évolutions du marché et des technologies naissantes. Précisément, il s'agit d'utiliser et de contrôler au mieux la mise en oeuvre d'une application sur une plate-forme donnée (par génération de code quand c'est possible).
Le cadre de développement d'Alcatel est défini dans l'esprit Corba (the Common Object Request Broker Architecture) et met l'accent sur l'écriture de schémas de programmes dans des langages d'interface comme IDL (Interface Definition Language). Il doit être compatible en amont avec une méthodologie de conception objet type UML. Il doit aussi pouvoir s'interfacer avec un choix libre de plate-formes d'exécution : il faut donc bien veiller au rôle tampon du langage d'interface qui doit abstraire correctement la plate-forme et permettre aussi l'utilisation de langages variés pour la programmation des objets logiciels.
Pour faire en sorte qu'il ne reste pas un simple guide de structuration du logiciel, et puisse vraiment répondre aux objectifs généraux de la maîtrise du développement, il est nécessaire de lui adjoindre une batterie d'outils pour assister le concepteur d'applications. C'est ici que se situe l'offre de l'Inria proposant l'utilisation de méthodes formelles. Par méthode formelle, nous entendons un formalisme fondé sur une sémantique mathématique et un ensemble de techniques associées permettant la manipulation (en général automatique) des programmes, à savoir la génération de code, des transformations, des vérifications, des optimisations, de la génération de tests, ... Le travail consiste à proposer des extensions aux langages d'interface pour faire apparaître des informations non fonctionnelles (comportementales) et à concevoir des outils de manipulation formelle traitant les schémas de programme définis par les interfaces. L'Inria se propose aussi de participer à l'extension de la chaîne pour la prise en compte de la résistance aux défaillances.
Les équipes Inria engagées dans Reutel sont :
et se sont regroupées sur quatre actions de recherche :
Le travail du projet Pampa se concentre principalement sur l'action 3 en coopération étroite avec le projet Ep-Atr. Nous concevons un nouveau langage d'interface : BDL (pour Behavioural Description Language). Le rôle de BDL est d'accompagner le développeur depuis les tâches préliminaires de spécification jusqu'au travaux de codage.
BDL intervient dans cette chaîne comme support à cet accompagnement et comme interface à l'intégration d'outils. Il est tout autant, pour son utilisateur, un langage de spécification, riche, expressif et structuré, avec une forte orientation objet, qu'un moyen de représentation intermédiaire simple, flexible et efficace pour l'utilisation des logiciels d'analyse, de test, de vérification et d'optimisation envisagés.
BDL se présente techniquement comme un formalisme permettant d'abstraire un objet et ses méthodes sous la forme d'un ensemble de graphes orientés étiquetés par les états de l'objet et de son environnement. Ces graphes permettent de coder les communications et leur ordonnancement, ainsi que les dépendances de données et de contrôle. Du point de vue de l'utilisateur, BDL se rapproche du formalisme des MSC (Message Sequence Charts), notation standard dans la méthode objet UML. Du point de vue sémantique, ils correspondent aux automates d'ordres partiels.
Lorsque ces ordres partiels sont synchronisés, on se retrouve dans le monde des langages synchrones à la Signal, ce qui permet de récupérer les techniques de preuve et de génération de code associés. Ces ordres partiels peuvent également être interprétés de manière asynchrone, donnant un fondement sémantique à la communication, et permettant aussi une connexion avec les outils de preuve et test CADP et TGV.
Précédent : Résultats nouveaux Remonter :
Projet PAMPA, Modèles et
outils Suivant : Actions régionales,
nationales et internationales