FR2932935A1

FR2932935A1 - Detection d'erreur dans un systeme de communication.

Info

Publication number: FR2932935A1
Application number: FR0854112A
Authority: FR
Inventors: Christophe Chevrier; Benoit Parreaux
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2008-06-20
Filing date: 2008-06-20
Publication date: 2009-12-25

Abstract

Pour détecter des erreurs dans un système dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des événements observés dans le système, chaque transition associée à plusieurs événements simultanés de l'automate est remplacée par des transitions entrelacées associées auxdits événements simultanés. Chaque évènement non observable est représenté par une transition interne. Chaque transition évènementielle relative à un évènement observable est remplacée par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable. Toutes les transitions internes sont supprimées après avoir ajouté des transitions évènementielles liées à ces dernières afin de fournir un automate superviseur (SUP). Une erreur est détectée par l'automate superviseur en simulant l'exécution d'un service dans le système en fonction d'une spécification erronée du système (SPE) dans laquelle des fautes sont introduites dans des automates de comportement du système.

Description

Détection d'erreur dans un système de communication

La présente invention concerne un outil pour calculer la capacité de détection d'une architecture de supervision d'un système de communication en fonction d'hypothèses d'observabilité des évènements se produisant dans ce système. Plus particulièrement, elle a trait à la capacité de détection d'erreurs survenant lors de l'exécution d'un service dans un système de communication tel qu'un réseau informatique. On utilise, de manière classique, des outils de supervision pour vérifier le bon fonctionnement de systèmes de communication. Pour ce faire, on met en place une "architecture de supervision", c'est-à-dire un ensemble de points de détection choisis dans l'architecture du système, ainsi que des observateurs respectivement associés à ces points de détection. Un "point de détection" est apte à observer un ensemble d'évènements survenant dans un composant du système ou dans un port d'un composant du système. Par exemple, les évènements à observer sont des messages entrants ou sortants d'un composant du système. Une propriété importante du point de détection est d'être capable de détecter des violations de propriété locale dans un composant. Une architecture de supervision optimale comprend autant de points de détection que de points de connexion des éléments du système de communication ; en variante, on peut ne prendre qu'un seul point de détection par élément du système. En outre, il est possible de réaliser une supervision globale du système en collectant certains évènements observés localement et en les analysant de façon globale. Les observateurs font état des

évènements qu'ils ont observés à un superviseur afin que ce dernier les analyse. Un "superviseur" est un automate représentant l'ensemble des séquences d'évènements observables du système. Cet automate évolue en fonction des évènements observés sur le système simulé. La simulation du système est exhaustive lorsqu'elle parcourt l'ensemble des chemins possibles de la spécification du système. Le superviseur est apte à détecter le moment où le système simulé quitte son comportement observable attendu. Enfin, on peut ajouter à ce mécanisme d'observation un ensemble d'injecteurs qui permettent de modéliser des sondes actives. Ces injecteurs sont capables d'interagir avec un élément de l'architecture du système.

Actuellement, la définition et le déploiement d'outils de supervision d'un système de communication sont réalisés de façon empirique grâce aux connaissances d'experts des domaines techniques à superviser. La supervision locale de chaque élément du système participant à la réalisation d'un nouveau service est généralement assurée. La supervision globale du service, et notamment l'analyse des différentes données par un utilisateur, demande un travail plus important ainsi que plus d'expertise sur le service en exploitation. La supervision est souvent réalisée en partant de l'hypothèse que le service fonctionne correctement si chaque composant fonctionne correctement, et que chaque alarme provenant des composants indique un dysfonctionnement du service. Ce type de processus aboutit à créer des systèmes produisant trop de données, qu'il faut ensuite filtrer pour les traiter et éviter d'engorger

le système. Ce filtrage peut être fait soit en agissant directement sur les données remontées par les sondes, soit en limitant le nombre de celles-ci. La définition des évènements à observer est faite de façon empirique et aboutit parfois à rendre impossible la détection d'évènements qui provoquent des perturbations. L'observation de ces évènements après déploiement est très coûteuse et complexe.

Pour remédier aux inconvénients évoqués ci-dessus, un procédé selon l'invention pour calculer la capacité à détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système, est caractérisé en ce qu'il comprend les étapes de : remplacer chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées associées auxdits évènements simultanés, représenter dans l'automate chaque évènement non observable par une transition interne, remplacer chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable, pour chaque état relié indirectement à un autre état par au moins une transition interne suivie d'une transition évènementielle dans l'automate, relier directement ledit état audit autre état par la transition évènementielle et supprimer toute transition interne afin de fournir un automate de supervision,

introduire au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et détecter au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite. Concernant les transitions de l'automate de supervision d'un système associées à des évènements observés relatifs à des éléments de ce système, on appelle, dans le cadre de la présente invention : - "transitions entrelacées" (associées à une pluralité d'évènements) des transitions dans lesquelles lesdits évènements se produisent l'un après l'autre, en prenant en compte les différents ordres de succession possibles, - "transition interne" une transition qui n'est associée à aucun évènement observable, et - "transition évènementielle" une transition qui est associée à un évènement unique (par opposition à une pluralité d'évènements simultanés). Ainsi, selon l'invention, les inconvénients évoqués précédemment sont éliminés en calculant une architecture de supervision dont la capacité de détection est optimisée par la production d'un automate de supervision correspondant, et par un test de détection d'une ou plusieurs erreurs prévues par une spécification erronée du système. On peut ainsi évaluer, au moyen de modèles, la capacité de détection de l'architecture de supervision prévue. Après avoir obtenu de la sorte une architecture de supervision satisfaisante, on pourra mettre en place, dans le système de communication réel, une architecture de supervision correspondante qui aura la même capacité de détection. L'invention offre

avantageusement une approche rationnelle de la supervision du système, et donc une meilleure efficacité pour un coût moindre. En particulier, la transformation du graphe modélisant le comportement simulé du système en un automate de supervision focalise la détection d'erreur sur un ou plusieurs évènements observables et analysables par l'automate de supervision, en introduisant une ou plusieurs erreurs prédéfinies dans le comportement des éléments du système. Selon une autre caractéristique de l'invention, la faute introduite dans un automate de comportement d'un élément du système peut être prédéterminée en fonction de l'un de trois types de défaillance selon lesquels : un service n'est pas rendu par un élément du système, un service est rendu avec un défaut temporel par un élément du système, et un service est mal rendu par un élément du système. Les fautes introduites dans les automates de comportement sont déterminées de manière à ce qu'elles concernent la plupart des évènements observables tels que des émissions de signal et à ce qu'elles provoquent des défaillances réalistes. Pour la défaillance selon laquelle un service n'est pas rendu par un élément du système, l'introduction d'une faute dans l'automate de comportement d'un élément du système peut comprendre une duplication d'une transition de l'automate, associée à une émission de message et une suppression de l'émission de message associée à la transition résultante. Pour la défaillance selon laquelle un service est rendu avec un défaut temporel par un élément du système, l'introduction d'une faute dans l'automate de comportement d'un élément du système peut comprendre une création d'un état intermédiaire

et de première et deuxième transitions supplémentaires en plus d'une transition initiale de l'automate, la première transition supplémentaire étant déclenchée par des mêmes causes que la transition initiale pour aboutir à l'état intermédiaire et la deuxième transition supplémentaire issue de l'état intermédiaire étant déclenchée à l'expiration d'un délai. Pour la défaillance selon laquelle un service est mal rendu par un élément du système, l'introduction d'une faute dans l'automate de comportement d'un élément du système peut comprendre une création d'une transition de copie d'une transition initiale de l'automate associée à une émission de message et un remplacement de l'émission de message associée à la transition de copie par une émission d'un message incorrect.

L'invention concerne également un dispositif pour détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système. Le dispositif est caractérisé en ce qu'il comprend : un moyen pour remplacer chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées associées auxdits évènements simultanés, un moyen pour représenter dans l'automate chaque évènement non observable par une transition interne, un moyen pour remplacer chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable,

un moyen, pour chaque état relié indirectement à un autre état par au moins une transition interne suivie d'une transition évènementielle dans l'automate, pour relier directement ledit état audit autre état par la transition évènementielle et supprimer toute transition interne afin de fournir un automate de supervision, un moyen pour introduire au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et un moyen pour détecter au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite. L'invention se rapporte encore à un programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour détecter au moins une erreur dans un système de communication, ledit programme comprenant des instructions qui, lorsque le programme est exécuté dans ledit dispositif, réalisent les étapes conformes au procédé de l'invention.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations de l'invention données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique d'un dispositif de détection d'erreur selon l'invention pour un système de communication ; - les figures 2A et 2B représentent l'introduction d'une défaillance de type "service non

rendu" sur un automate de comportement d'un composant du système de communication ; - les figures 3A et 3B représentent l'introduction d'une défaillance de type "service rendu avec délai" sur un automate de comportement d'un composant du système de communication ; - la figure 4 représente l'introduction d'une défaillance de type "service mal rendu" sur un automate de comportement d'un composant du système de communication ; - la figure 5 représente la transformation des transitions associée à plusieurs événements dans un graphe d'accessibilité étiqueté du système de communication ; - la figure 6 représente la suppression des transitions internes dans un graphe d'accessibilité étiqueté du système de communication ; - la figure 7 est un algorithme d'un procédé de détection d'erreur selon l'invention pour système de communication ; - la figure 8 est un automate de comportement d'un client dans un système de communication ; et - la figure 9 est un automate de comportement modifié du client dans le système de communication selon l'invention.

L'invention décrite ci-après est relative à un système de communication exécutant un service. Le système est modélisé selon une spécification donnée et peut être simulé pour détecter au moins une erreur ou plus généralement des erreurs survenant lors de l'exécution du service dans le système. Par exemple, le système de communication est un réseau informatique, tel qu'un intranet d'une entreprise.35

Préalablement, quelques termes et concepts utiles à la compréhension de l'invention sont définis ci-après, en relation avec la spécification du système.

Un système de communication est décrit par un ensemble de composants qui possèdent des ports de communication et qui sont interconnectés au moyen de ces ports. Un composant est une description d'un type d'élément de l'architecture du système. Un composant est décrit par son comportement, et possède des ports pour communiquer avec d'autres composants. Une instance de composant est un élément ayant les caractéristiques du type d'élément décrit par le composant. Par exemple, si un composant décrit un élément du type "imprimante" communiquant avec des ports donnés, deux instances de composant peuvent être une première imprimante et une deuxième imprimante qui peuvent communiquer avec lesdits ports donnés. Un signal est un message asynchrone échangé entre deux composants. Une interface est une description des messages susceptibles d'être reçus par un composant qui fournit cette interface. Un composant qui requiert une interface est donc susceptible d'émettre les messages déclarés dans cette interface. Un port est une description d'un point du système auquel une instance de composant est connectée. Un port déclare les interfaces que le composant requiert et fournit par ce port. Une connexion est un lien entre deux ports respectifs de deux instances de composants. Les connexions permettent de montrer l'architecture du système.

Le comportement de chaque composant du système est modélisé par une machine à état. Une machine à état est un automate qui comprend des transitions correspondant à des actions du composant, et des états reliés par des transitions. Chaque état est relié à au moins un début de transition ou une fin de transition. Un protocole est une machine à état décrivant les actions en relation avec les messages échangés par l'un des ports du composant ou dans le composant lui-même.

Par exemple, un composant passe d'un état "A" à un état "B" en fonction d'une transition caractérisant une émission de message. Un composant peut être à un état "A" inactif suite à l'initialisation du composant ; après l'émission d'une requête par le composant, ce dernier bascule à un état "B" en attente d'une réponse à la requête émise.

En référence à la figure 1, un dispositif de détection d'erreur DS selon un mode de réalisation de l'invention supervisant un système de communication comprend un module de graphe d'accessibilité MGA, un module d'observation M0, un module d'erreur ME et un module de détection MD. Le dispositif DS est par exemple un ordinateur du type ordinateur personnel ou serveur relié au système de communication. En particulier les divers automates auxquels recourt le procédé de détection d'erreur selon l'invention et qui sont construits et/ou modifiés par le procédé sont enregistrés par exemple dans un moyen de mémoire comme une base de données incorporée dans le

dispositif DS ou dans un serveur de gestion de base de données communiquant avec le dispositif DS.

Une faute est considérée être à l'origine d'une erreur dans le système. Une ou plusieurs fautes peuvent provoquer des erreurs ou des défaillances du système. Les erreurs et les défaillances surviennent dans un élément de l'architecture du système. Selon l'invention, la supervision du système de communication repose sur la notion d'erreur. En effet, la supervision selon l'invention intervient une fois le système déployé pour observer des erreurs du système qui sont des conséquences de fautes créées et introduites dans le système. Une erreur, si elle est observable, apparaît sous la forme d'un ensemble de symptômes qui portent sur des éléments observables du système.

L'invention fournit un modèle de défaillance du système basé sur des modèles à composants décrits sous forme d'une spécification. La spécification inclut une description de l'architecture du système, c'est-à-dire les différents ports de communication et les différentes connexions entre les éléments du système, et une représentation sous forme d'automate du comportement observable du système. Le modèle de défaillance associé à l'architecture du système porte sur les éléments observables de l'architecture. A titre d'exemple, on considère dans la présente description les éléments observables du type message envoyé ou message reçu par un composant. On aurait pu, tout aussi bien, considérer la valeur de variables choisies associées aux composants. L'homme du métier comprendra que le procédé selon l'invention est aisément généralisable

à tout type d'élément observable, pour lequel on cherche à observer un changement d'état. L'architecture du système peut être représentée sous forme d'un modèle "n-tiers" dans lequel chaque composant rend un service à d'autres composants. Le modèle de défaillance comporte ainsi les trois types de défaillance suivants. Selon un premier type de défaillance, le service n'est pas rendu, par exemple lorsque le composant supposé rendre le service n'émet pas la réponse attendue. Selon un deuxième type de défaillance, le service est rendu avec un défaut temporel. Cette défaillance survient dans le cas où le composant rend le service dans un intervalle de temps différent d'un intervalle de temps prédéterminé. Selon un troisième type de défaillance, le service est mal rendu, par exemple lorsque le composant émet un message non prévu, appartenant ou non à l'ensemble des messages que le composant peut émettre, ou lorsque le composant émet un message erroné, c'est-à-dire un message dont le contenu est erroné. Pour une architecture basée sur un modèle "n- tiers", des défaillances supplémentaires peuvent apparaître concernant le comportement d'un tiers en tant que client du service rendu par un autre tiers. Dans ce cas, pour le premier type de défaillance, le tiers n'émet pas des messages liés à la demande de service; pour le deuxième type de défaillance, le tiers émet des messages avec un défaut temporel; et pour le troisième type de défaillance, le tiers émet des messages erronés.

Selon l'invention, des fautes sont produites puis introduites dans la spécification du système. Ces fautes sont déductibles de la spécification de façon à ce que les défaillances causées par ces fautes soient réalistes. A cette fin, des défaillances qui sont applicables à la spécification traitée sont extraites de l'ensemble des défaillances connues, et des fautes correspondant aux défaillances extraites sont introduites dans la spécification du système en modifiant les automates représentant le comportement du système.

Dans les figures 2A et 2B, 3A et 3B, et 4 sont illustrés trois types de défaillance du modèle de défaillance selon l'invention, représentés sous forme d'automates de comportement d'un composant. Pour le premier type de défaillance dans lequel le service n'est pas rendu par un composant, la défaillance peut être représentée par le comportement du composant selon deux possibilités illustrées respectivement aux figures 2A et 2B. Selon une première possibilité, la défaillance peut être traduite par la non-émission d'un message par le composant. Après la réception d'un message par un port du composant, l'émission du message en retour par ce même port est supprimée. Selon la figure 2A, l'automate de comportement du composant sans introduction de faute passe d'un état A à un état B après une émission de message symbolisée par l'étiquette "!MES" associée à la transition de l'état A à l'état B. Avec une introduction de faute, l'automate passe de l'état A à l'état B sans émission de message, la transition de l'état A à l'état B étant vide.

Selon une deuxième possibilité, la défaillance peut être traduite par l'ignorance d'un message en entrée du composant. La réception d'un message par le composant ne fait pas évoluer l'automate de comportement du composant. Par exemple, le message reçu est une notification. Selon la figure 2B, l'automate de comportement du composant sans introduction de faute passe d'un état A à un état B après une réception de message symbolisée par l'étiquette "?MES" associée à la transition de l'état A à l'état B. Avec une introduction de faute, l'automate reste à l'état A malgré la réception de message. Pour le deuxième type de défaillance dans lequel le service est rendu avec un défaut temporel par un composant, la défaillance peut être représentée par le comportement du composant selon deux possibilités illustrées respectivement aux figures 3A et 3B. Selon une première possibilité, le composant fournit une réponse attendue en émettant un message, avec un délai trop long et la défaillance peut être traduite par l'introduction d'un délai avant l'émission du message. Selon la figure 3A, l'automate de comportement du composant sans introduction de faute passe d'un état A à un état B après une émission de message symbolisée par l'étiquette "!MES" associée à la transition de l'état A à l'état B. Avec une introduction de faute, l'automate passe de l'état A à un état A' après le déclenchement d'un délai symbolisé par l'étiquette "start timer" associée à la transition de l'état A à l'état A' et passe de l'état A' à l'état B à l'expiration du délai après l'émission de message, symbolisée par l'étiquette "when timer, !MES" associée à la transition de l'état A' à l'état B. Si l'émission du message dépend du

déclenchement du délai dans l'automate sans introduction de faute, la défaillance peut être traduite par l'augmentation de la durée du délai. Selon une deuxième possibilité, le composant fournit une réponse attendue en émettant un message, avec un délai trop court et la défaillance peut être traduite par la réduction de la durée d'un délai lorsque l'émission du message est directement liée au déclenchement du délai. Selon la figure 3B, l'automate de comportement du composant sans introduction de faute passe d'un état A à un état B à l'expiration d'un délai après une émission de message symbolisée par l'étiquette "when timer, !MES" associée à la transition de l'état A à l'état B. Avec une introduction de faute, l'automate passe de l'état A à l'état B à l'expiration d'un délai raccourci d'une durée DT après une émission de message symbolisée par l'étiquette "when timer - DT, !MES" associée à la transition de l'état A à l'état B.

Pour le troisième type de défaillance dans lequel le service est mal rendu par un composant, la défaillance peut être représentée par l'émission d'un message différent d'un message attendu. En référence à la figure 4, l'automate de comportement du composant sans introduction de faute passe d'un état A à un état B après une émission de message attendu symbolisée par l'étiquette "!MES" associée à la transition de l'état A à l'état B. Avec une introduction de faute, l'automate passe de l'état A à l'état B après une émission d'un message incorrect différent du message attendu symbolisée par l'étiquette "!MI" associée à la transition de l'état A à l'état B, le message incorrect pouvant appartenir à l'ensemble des messages du système.35

Le modèle de défaillance est régi par des règles selon lesquelles pour toutes les transitions possédant une émission de signal, des défaillances de type "service non rendu", "service avec délai" et "service mal rendu" sont produites. Cette transformation permet d'obtenir le modèle exhaustif des défaillances possibles dans le système. La spécification du système est modifiée par l'introduction de fautes dans cette dernière comme décrit précédemment. La spécification du système est ainsi surchargée par les fautes et contient le comportement correct ainsi que le comportement erroné des composants. La modification de la spécification du système est exécutée selon les trois règles suivantes du modèle de défaillance. Selon une première règle, pour appliquer une faute de type "service non rendu" sur une transition initiale, une transition de copie de la transition initiale est créée et tout évènement correspondant à une émission de message est supprimé. Selon une deuxième règle, pour appliquer une faute de type "service avec délai" sur une transition initiale d'un premier état à un deuxième état, un état intermédiaire et deux transitions supplémentaires sont créés : la première transition supplémentaire créée reliant le premier état à l'état intermédiaire est déclenchée par les mêmes causes que la transition initiale et la deuxième transition supplémentaire créée reliant l'état intermédiaire au deuxième état est déclenchée par un signal "trigger" qui est un signal de déclenchement. Selon une troisième règle, pour appliquer une faute de type "service mal rendu" sur une transition initiale, une transition de copie de la transition initiale est créée et l'émission de message associée

à la transition de copie est remplacée par l'émission d'un message incorrect.

L'architecture de supervision considérée ici comprend un ensemble choisi de points de détection dont le rôle est de détecter l'émission ou la réception de messages. Dans un premier temps, on applique, de manière classique, un ou til de vérification, dit outil de "model checking", à une spécification décrite sous la forme d'un ensemble d'automates communicants et d'observateurs associés auxdits points de détection de l'architecture de supervision. Cet outil de "model checking" permet d'obtenir le "graphe d'accessibilité" GA du système. Ce graphe d'accessibilité GA représente l'ensemble des évènements possibles pour le système, chaque évènement étant associé à au moins une transition entre deux états du graphe GA.

Compte tenu de l'architecture de supervision mise en place, certains de ces évènements sont observables, et d'autres ne le sont pas. Comme rappelé ci-dessus, les observateurs font état des évènements qu'ils ont observés à un superviseur afin que ce dernier les analyse. Ensuite, selon l'invention, tous les évènements concurrents, c'est-à-dire simultanés, sont remplacés par des évènements entrelacés. En référence à la figure 5, un premier automate comprend une transition entre des états A et B associée à une étiquette "!a, ?b" symbolisant l'émission d'un message "a" simultanée à la réception d'un message "b". Cette transition est remplacée par deux transitions successives "!a" et "?b", et deux transitions successives "?b" et "!a". L'automate transformé

comprend alors deux états intermédiaires supplémentaires I et I' associées aux successions de transitions précédentes. Par exemple, l'automate passe de l'état A à l'état I après l'émission du message "a" et passe de l'état I à l'état B après la réception du message "b". Chaque émission ou réception de message par un composant est alors remplacée par la réception par le superviseur d'un signal de type émission ou réception de message dans le composant donné. D'autre part, chaque évènement non observable par l'architecture de supervision est représenté par une transition interne, c'est-à-dire une transition vide qui n'est associée à aucune étiquette.

Le graphe est ensuite complété pour supprimer les transitions internes. A cette fin, des transitions évènementielles sont rajoutées à chaque transition interne avant de supprimer toutes les transitions internes. Par ailleurs, des états non accessibles peuvent être en outre supprimés. En référence à la figure 6, un automate avec des états A, B, C, D et E comprend initialement des transitions internes "i" de l'état A à l'état B et de l'état B à l'état D, une transition évènementielle "!a" de l'état B à l'état C, et deux transitions évènementielles "?b" respectivement de l'état C à l'état D et de l'état D à l'état E. Les transitions évènementielles sont rajoutées à chacune des transitions internes de sorte qu'un premier état relié indirectement à un deuxième état de l'automate par au moins une transition interne suivie d'une transition évènementielle soit relié directement au deuxième état par la transition évènementielle. Selon un exemple, l'état A initialement relié indirectement à l'état C via l'état B par une transition interne

"i" et une transition évènementielle "!a" est relié directement à l'état C par la transition évènementielle "!a". Selon un autre exemple, l'état A initialement relié indirectement à l'état E via les états B et D par deux transitions internes "i" et une transition évènementielle "?b" est relié directement à l'état E par la transition évènementielle "?b". Ensuite, toutes les transitions internes "i" sont supprimées. Selon l'exemple illustré à la figure 6, l'automate transformé ne comprend plus de transitions internes entre les états A et B et entre les états B et D, l'état A étant directement relié aux états C et D respectivement par les transitions évènementielles "!a" et "?b" et l'état B étant directement relié à l'état E par la transition évènementielle "?b". Le graphe d'accessibilité est ainsi transformé en un automate représentant un superviseur qui évolue en fonction de l'ensemble des évènements observables du système. Tout évènement reçu qui n'est pas attendu par l'automate provoque le blocage du superviseur et donc la détection d'une erreur.

L'automate transformé peut être écrit dans le langage d'un outil de type "model checking". Afin de détecter des blocages, l'automate transformé est placé dans un état d'erreur si une file d'attente d'évènements observés n'est pas vide alors que le temps avance pour au moins l'un des états de l'automate. Ce blocage dans un état d'erreur signifie qu'il y a, dans la file d'attente, un signal qui ne correspond à aucune transition partant de l'état considéré. En variante, pour détecter les blocages, l'automate est complété de telle façon que tout

évènement non attendu dans un état amène le superviseur dans un état d'erreur. Par ailleurs, des observateurs simples peuvent mettre en évidence des cas où le superviseur entre dans un état d'erreur. De plus, des observateurs, dits "intrusifs" en ce sens qu'ils exercent une action sur le système, émettent des messages vers un composant qui représente le superviseur. Un tel observateur possède un seul état stable, et à chaque signal en entrée ou en sortie du point de détection, il émet un signal correspondant vers le superviseur. Selon un exemple de réalisation, l'architecture de supervision est transformée de la manière suivante afin de produire automatiquement des observateurs permettant d'extraire des événements observables aux points de détection du système. Pour tout point de détection de l'architecture de supervision, un observateur intrusif est construit avec un état stable appelé "idle". Pour chaque signal en entrée du point de détection, une transition de type "match input" est créée dans l'observateur. Si le signal en entrée du point de détection est reçu par le composant, alors le signal correspondant est émis par l'observateur vers le superviseur. Pour chaque signal en sortie du point de détection, une transition de type "match output" est créée dans l'observateur. Si le signal en sortie du point de détection est émis par le composant, alors le signal correspondant est émis par l'observateur vers le superviseur. Par ailleurs, le protocole admis sur chacun des ports d'un composant peut être décrit par une machine à état. A partir d'une telle machine à état, un

observateur peut être produit de manière à ce que tout signal non attendu amène l'observateur dans un état d'erreur. En outre, des erreurs non détectées par l'architecture du système peuvent être obtenues en identifiant les transitions introduites dans la spécification et absentes de l'ensemble des chemins menant à un état d'erreur du superviseur.

En référence à la figure 7, le procédé de détection d'erreur selon l'invention comprend des étapes El à E4 exécutées automatiquement dans le dispositif de détection d'erreur DS et mises en oeuvre par des instructions d'un programme d'ordinateur enregistré sur un support d'enregistrement lisible par le dispositif DS. Initialement, un système de communication apte à exécuter un service donné est modélisé selon une spécification donnée. La spécification inclut une description de l'architecture du système et une représentation sous forme d'automate du comportement observable du système. Selon l'invention, dans un premier temps, un superviseur SUP est déterminé en simulant l'exécution du service en fonction d'une spécification du système et d'une architecture de supervision ; dans un deuxième temps, le superviseur SUP détecte des erreurs lorsque l'on simule l'exécution du service en fonction d'une spécification erronée du système.

Plus précisément, à l'étape El, le module de graphe d'accessibilité MGA du dispositif de détection d'erreur DS fournit un superviseur SUP, en fonction de la spécification du système et de l'architecture de supervision, à partir d'un graphe d'accessibilité du système, selon des sous-étapes E11 à E14, comme

cela a été décrit plus haut en référence aux figures 5 et 6. Le graphe d'accessibilité du système a été préalablement obtenu en simulant l'exécution du service dans le système.

A la sous-étape E11, le module MGA découpe tous les évènements concurrents dans le graphe d'accessibilité en des évènements entrelacés. A cette fin, le module MGA identifie au moins une transition du graphe entre des premier et deuxième états associée à plusieurs évènements simultanés. Pour chaque transition identifiée, le module MGA détermine un nombre NES d'évènements simultanés associés à la transition et produit des états intermédiaires entre les premier et deuxième états en reliant ces derniers par des transitions unitaires associées respectivement à des évènements distincts parmi les évènements simultanés. On rappelle que les transitions unitaires sont appelées transitions évènementielles TE. Les états intermédiaires et les transitions évènementielles produites servent à construire un automate exprimant l'ensemble des enchaînements possibles des évènements simultanés. Par exemple, un nombre NEI d'états intermédiaires produits est égal au nombre NES d'évènements simultanés moins un : NEI = NES - 1, et un nombre NTE de transitions évènementielles produites est égal au factoriel du nombre NES d'évènements simultanés : NTE = !NES.

A la sous-étape E12, le module MGA représente dans l'automate chaque évènement non observable par l'architecture de supervision par une transition interne TI dans le graphe d'accessibilité. A la sous-étape E13, le module MGA transforme 35 chaque émission ou réception de message par un

composant en la réception par le superviseur d'un signal de type émission ou réception de message dans le composant donné dans le graphe d'accessibilité. En d'autres termes, chaque étiquette associée à une transition évènementielle TE et correspondant à un évènement particulier est remplacée par une étiquette correspondant à la réception par le superviseur d'un signal d'information sur l'évènement particulier. A la sous-étape E14, le module MGA complète le graphe d'accessibilité par des transitions évènementielles TE et supprime les transitions internes TI, comme cela a été décrit en référence à la figure 6. Dans le graphe d'accessibilité, pour chaque premier état relié indirectement à un deuxième état par au moins une transition interne TI suivie d'une transition évènementielle TE, le module MGA ajoute la transition évènementielle TE au premier état pour que ce dernier soit relié directement au deuxième état par la transition évènementielle TE. Le module MGA supprime ensuite toutes les transitions internes TI du graphe. A l'issue de l'étape El, le module MGA fournit l'automate du superviseur SUP qui correspond au graphe d'accessibilité modifié comme précédemment.

A l'étape E2, le module d'observation MO construit des observateurs OBS en fonction des points de détection de l'architecture de supervision. Selon une réalisation de l'invention, les points de détection sont associés aux éléments observables du système, c'est-à-dire aux composants du système. Chaque observateur associé à un composant par le biais d'un point de détection détecte l'émission ou la réception d'un message par le composant. Les observateurs OBS sont donc déterminés de sorte que l'automate du superviseur SUP tel que défini à la

sous-étape E13 soit capable de recevoir les signaux provenant des observateurs relatifs à des évènements survenant dans les composants du système. En variante, l'étape E2 est exécutée avant l'étape El. A l'étape E3, le module d'erreur ME produit une spécification erronée SPE du système de communication selon des sous-étapes E31 et E32. A la sous-étape E31, le module ME détermine un modèle de défaillance comprenant les différents types de défaillances pouvant survenir dans les composants du système. Le modèle de défaillance comprend les trois types de défaillance selon lesquels le service n'est pas rendu, le service est rendu avec un défaut temporel, et le service est mal rendu, comme définis précédemment. Pour chaque composant du système, le module ME détermine quelles défaillances sont applicables parmi les trois types de défaillance possibles pour chacune des transitions associées à une émission de signal dans un automate de comportement du composant. A la sous-étape E32, le module ME introduit des fautes dans la spécification du système, notamment dans les automates de comportement des composants du système. Les fautes sont introduites en fonction des trois types de défaillance déterminés pour produire une spécification erronée SPE du système de communication. Pour la défaillance selon laquelle le service n'est pas rendu, le module ME duplique une transition initiale en une transition de copie TC, et l'émission de message associée à la transition de copie TC est supprimée. La transition de copie est donc une transition vide.

Pour la défaillance selon laquelle le service est rendu avec un défaut temporel, le module ME crée un état intermédiaire EI et des première et deuxième transitions supplémentaires TS en plus d'une transition initiale. La première transition supplémentaire est déclenchée par les mêmes causes que la transition initiale pour aboutir à l'état intermédiaire et la deuxième transition supplémentaire issue de l'état intermédiaire est déclenchée à l'expiration d'un délai. Pour la défaillance selon laquelle le service est mal rendu, le module ME crée une transition TC de copie d'une transition initiale et l'émission de message associée à la transition de copie TC est remplacée par l'émission d'un message incorrect MI. En variante, l'étape E3 est exécutée avant l'étape El ou E2. A l'étape E4, le module de détection MD simule l'exécution du service dans le système de communication en fonction de la spécification erronée SPE du système produite par le module d'erreur ME et assiste le superviseur SUP coopérant avec les observateurs OBS pour détecter des erreurs dans le système ainsi simulé.

Le superviseur SUP fourni par le module MGA au module MD évolue en fonction des signaux émis par les observateurs OBS, c'est-à-dire en fonction des évènements observés sur le système simulé. Lors de la simulation du système en fonction de la spécification erronée SPE du système de communication, le superviseur SUP détecte une erreur lorsqu'il reste bloqué dans un état de l'automate, c'est-à-dire lorsqu'un signal reçu par le superviseur à un état donné ne correspond à aucune transition partant de l'état donné. En outre, le superviseur SUP est

capable d'établir l'enchaînement des transitions et des états qui ont abouti à l'état d'erreur du superviseur. Finalement, la capacité de détection de l'architecture de supervision décrite pourra être évaluée en fonction du fait que les erreurs introduites dans la spécification erronée ont été ou n'ont pas été détectées par le superviseur.

Selon un exemple de réalisation illustré aux figures 8 et 9, le système de communication comprend un client, un serveur et un authentificateur. Le service exécuté dans le système consiste à authentifier le client souhaitant communiquer avec le serveur par l'intermédiaire de l'authentificateur. Le client demande une action au serveur qui requiert une authentification du client auprès de l'authentificateur. Lorsque l'authentificateur rend un verdict sur l'authentification au serveur, ce dernier peut traiter la demande du client. En référence à la figure 8 relative à l'automate de comportement du client, à l'initialisation du client, l'automate passe d'un état initial "In" à un état stable "idle" via une transition déclenchée par un signal d'initialisation "init". Lorsque le client émet une requête pour être authentifié, l'automate passe à un état d'attente de réseau "waitRes" via une transition déclenchée par un signal de requête "req". Lorsque le client reçoit une requête pour être identifié, l'automate passe à un état d'attente d'identification "waitld" via une transition déclenchée par un signal de requête d'identification "recldReq". L'automate reste à l'état "waitld", c'est-à-dire le client est en attente d'être authentifié, après l'émission d'une identité du

client symbolisée par une transition en boucle associé à un signal d'émission d'identité "sendId". Lorsque l'authentification est achevée, l'automate repasse à l'état "waitRes" via une transition déclenchée par un signal d'authentification "auth". L'automate revient ensuite à l'état "idle" via une transition déclenchée par un signal de confirmation "trOk" pour confirmer que l'authentification est achevée. L'automate peut également repasser à l'état "idle" via une transition déclenchée par un signal de retard "late" si un délai pour confirmer l'authentification est dépassé. En référence à la figure 9 relative à l'automate de comportement du client modifié selon l'invention, des fautes sont introduites dans l'automate, après avoir extrait les défaillances possibles de l'automate de la figure 8. En particulier, l'automate peut passer de l'état "idle" à l'état "waitRes" via une transition déclenchée par un signal de requête erroné "regl2", ou successivement via une transition déclenchée par un signal de délai "delayTransl3" vers un état intermédiaire "delayStatel3" puis via une transition déclenchée par un signal de requête erroné "regl3". Par ailleurs, l'automate peut rester à l'état d'attente d'identification "waitId" après l'émission d'une identité erronée du client symbolisée par une transition en boucle associée à un signal d'émission erroné "sendIdlO", ou après l'émission retardée d'une identité du client symbolisée par une transition de l'état "waitId" à un état intermédiaire "delayStatell" déclenchée par un signal de délai "delayTransll" et par une transition de l'état intermédiaire "delayStatell" à l'état "waitId" déclenchée par un signal d'émission erroné "sendIdll".

Le superviseur SUP détecte une erreur par exemple lorsqu'il reçoit un signal d'un observateur indiquant que le client a émis un signal de requête erroné "regl2" qui ne correspond à aucune transition dans le superviseur, et le signal d'observateur reste dans une file d'attente sans être traité par le superviseur qui est bloqué dans un dernier état précédant la réception du signal d'observateur.

L'invention décrite ici concerne un procédé et un dispositif pour détecter une erreur dans un système de communication. Selon une mise en oeuvre, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un dispositif informatique tel que le dispositif de détection d'erreur DS. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur enregistré sur ou dans un support d'enregistrement lisible par un ordinateur et tout dispositif de traitement de données, adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention. Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le

programme. Par exemple, le support peut comporter un moyen de stockage sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette ("floppy disk") ou un disque dur. D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon l'invention.

Claims

REVENDICATIONS1 - Procédé pour calculer la capacité à détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système, caractérisé en ce qu'il comprend les étapes de : remplacer (E11) chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées (TE) associées auxdits évènements simultanés, représenter (E12) dans l'automate chaque évènement non observable par une transition interne, remplacer (E13) chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable, pour chaque état relié indirectement à un autre état par au moins une transition interne (TI) suivie d'une transition évènementielle (TE) dans l'automate, relier (E14) directement ledit état audit autre état par la transition évènementielle et supprimer toute transition interne afin de fournir un automate de supervision (SUP), introduire (E32) au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et détecter (E4) au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite.35
2 - Procédé conforme à la revendication 1, selon lequel la faute introduite dans un automate de comportement d'un élément du système est prédéterminée en fonction de l'un de trois types de défaillance selon lesquels : un service n'est pas rendu par un élément du système, un service est rendu avec un défaut temporel par un élément du système, et un service est mal rendu par un élément du système.
3 - Procédé conforme à la revendication 1 ou 2, selon lequel l'introduction d'une faute dans l'automate de comportement d'un élément du système comprend une duplication d'une transition de l'automate, associée à une émission de message et une suppression de l'émission de message associée à la transition résultante.
4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel l'introduction d'une faute dans l'automate de comportement d'un élément du système comprend une création d'un état intermédiaire et de première et deuxième transitions supplémentaires en plus d'une transition initiale de l'automate, la première transition supplémentaire étant déclenchée par des mêmes causes que la transition initiale pour aboutir à l'état intermédiaire et la deuxième transition supplémentaire issue de l'état intermédiaire étant déclenchée à l'expiration d'un délai.
5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel l'introduction d'une faute dans l'automate de comportement d'un élément du système comprend une création d'une transition de copie d'une transition initiale de l'automate associée à une émission de message et un remplacement de l'émission de message associée à la transition de copie par une émission d 'un message incorrect.
6 - Dispositif (DS) pour détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système, caractérisé en ce qu'il comprend : un moyen (MGA) pour remplacer chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées (TE) associées auxdits évènements simultanés, un moyen (MGA) pour représenter dans l'automate chaque évènement non observable par une transition interne (TI), un moyen (MGA) pour remplacer chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable, un moyen (MGA), pour chaque état relié indirectement à un autre état par au moins une transition interne (TI) suivie d'une transition évènementielle (TE) dans l'automate, pour relier directement ledit état audit autre état par la transition évènementielle (TE) et supprimer toute transition interne (TI) afin de fournir un automate de supervision (SUP), un moyen (ME) pour introduire au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et un moyen (MD) pour détecter au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite.
7 - Programme d'ordinateur apte à être mis en oeuvre dans un dispositif (DS) pour détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système, ledit programme étant caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est exécuté dans ledit dispositif, réalisent les étapes de : remplacer (E11) chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées (TE) associées auxdits évènements simultanés, représenter (E12) dans l'automate chaque évènement non observable par une transition interne, remplacer (E13) chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable, pour chaque état relié indirectement à un autre état par au moins une transition interne (TI) suivie d'une transition évènementielle (TE) dans l'automate, relier (E14) directement ledit état audit autre état par la transition évènementielle et supprimer toute transition interne afin de fournir un automate de supervision (SUP), introduire (E32) au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et détecter (E4) au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite.
8 - Support d'enregistrement lisible par un dispositif (DS) pour détecter des erreurs dans un système de communication dont le comportement simulé est modélisé par un automate comprenant des états reliés par des transitions associées à des évènements observés relatifs à des éléments du système, caractérisé en ce qu'il a enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes suivantes : remplacer (E11) chaque transition associée à plusieurs évènements simultanés de l'automate par des transitions entrelacées (TE) associées auxdits évènements simultanés, représenter (E12) dans l'automate chaque évènement non observable par une transition interne, remplacer (E13) chaque transition évènementielle relative à un évènement observable, par une réception par l'automate d'un signal étiqueté en fonction dudit évènement observable, pour chaque état relié indirectement à un autre état par au moins une transition interne (TI) suivie d'une transition évènementielle (TE) dans l'automate, relier (E14) directement ledit état audit autre état par la transition évènementielle et supprimer toute transition interne afin de fournir un automate de supervision (SUP), introduire (E32) au moins une faute dans au moins un automate de comportement d'un élément du système pour produire une spécification erronée du système, et détecter (E4) au moyen de l'automate de supervision au moins une erreur dans une simulation de l'exécution d'un service dans le système en fonction de la spécification erronée produite.