Tolérance aux fautes imprévues dans les systèmes complexes Costin Caval Amal El Fallah Seghrouchni Patrick Taillibert

Sommaire De quoi on parle Difficultés identifiées Qu’est-ce qu’on veut faire

Faute imprévue? Définition Toutes les fautes sont imprévues ? Faute dont l’apparition n’est pas prévue dans le système  Toutes les fautes sont imprévues ? Nous prenons un cycle de production simplifié…

Conception Fautes ? Oui Non Développement Fautes ? Oui Non

Conception Fautes ? Oui Non Développement Sure ? Fautes ? Oui Non

Conception Oui Fautes ? Oui Traitement ? Non Non Développement Sure ? Oui Fautes ? Oui Traitement ? Non Non

Faute imprévue ? Définition Par qui ? Faute dont l’apparition n’est pas prévue dans le système Faute non identifiée ou volontairement ignorée (« risque assumé ») au moment de la conception et/ou de la construction d’un système Par qui ? Résultat = Concepteurs + Développeurs + Outils

Faute imprévue? État d’esprit aider le concepteur à décrire et le développeur à écrire des programmes implicitement fiables Langage Plateforme Méthodologie

Faute imprévue? Travaux que nous regardons Observer [Diaz et al. 1994] Sentinelles [Shah et al. 2009, Klein et al. 1999] Détection des anomalies [Chandola et al. 2009] Mission data system [Rasmussen 2001]

Verrous #1 Agents communiquant uniquement par échange de messages #2 Agents au comportement dirigé par des buts #3 Détection des erreurs #4 Localisation des agents contaminés

#1 Agents Avantages « classiques » des agents L’autonomie … des autres Interactions par des messages Propagation limitée des erreurs L’autonomie … des autres

#2 Agents et buts Contrôle sur les résultats des actions Méthodologie format des buts, plans, automates etc. Langage

#3 Détection Limitation des « libertés » des développeurs Assembler -> C -> Java -> ?... (ex.: Erlang) Typage, contraintes, contrôle des états d’attente

#4 Localisation Hypothèses sur l’état correct des interlocuteurs Métadonnées pour les messages échangées

Conclusions Définir le concept de faute imprévue Décrire des agents dirigés par des buts Définir un langage Ajouter des éléments de localisation

Merci 

Références Chandola, Varun, Arindam Banerjee, and Vipin Kumar. 2009. “Anomaly Detection: A Survey.” ACM Comput. Surv. 41 (3) (July): 15:1–15:58. Diaz, Michel, Guy Juanole, and Jean-Pierre Courtiat. 1994. “Observer-A Concept for Formal On-Line Validation of Distributed Systems.” IEEE Trans. Softw. Eng. 20 (12) (December): 900–913. Klein, Mark, and Chrysanthos Dellarocas. 1999. “Exception Handling in Agent Systems.” In Proceedings of the Third Annual Conference on Autonomous Agents, 62–68. AGENTS  ’99. New York, NY, USA: ACM. Rasmussen, R.D. 2001. “Goal-based Fault Tolerance for Space Systems Using the Mission Data System.” In Aerospace Conference, 2001, IEEE Proceedings., 5:2401–2410. Shah, Nazaraf, Rahat Iqbal, Anne James, and Kashif Iqbal. 2009. “Exception Representation and Management in Open Multi-agent Systems.” Inf. Sci. 179 (15) (July): 2555–2561.

Notes suite à la présentation Q : Est-ce que vous vous intéressez que à des fautes de conception et de développement ou à d’autres fautes aussi? R : Nous nous intéressons à toutes les fautes qui peuvent se produire et nous les traitons en ligne en fonction des buts des agents. Néanmoins, nous ne pouvons pas garantir le résultat du système dans tous les cas, car le système peut perdre des ressources vitales à l’achèvement de ses buts. Q : Pourquoi est-ce que vous voulez proposer un nouveau langage? R : La proposition d’un nouveau langage est hypothétique à ce niveau, mais le langage que nous avons dans le laboratoire (ALMA) a certains aspects que nous comptons utiliser dans notre méthode, comme le raisonnement sous hypothèses et les timeouts pour les états d’attente. Néanmoins, nous pourrions être amenés à utiliser un des autres langages déjà existants comme base pour notre proposition.