A diagnosis support for formal verification of systems

Le model checking est une technique de vérification formelle qui consiste à certifier que le comportement d’un système formel satisfait des propriétés formelles. Son principe est d’explorer l’ensemble des exécutions possibles du système pour découvrir des chemins d’exécution (traces) violant les propriétés. Si c’est le cas, l’ingénieur doit remonter aux causes qui ont produit la trace. L’objectif de la thèse est d’assister l’ingénieur lors de cette phase que l’on appelle diagnostic. Nous proposons un cadre combinant différents types de connaissances et activités cognitives, supporté par une méthode et une infrastructure. Nous illustrons l’approche sur la sécurisation d’un système SCADA. Quand le diagnosticien est vérificateur du modèle, il doit faire face à des traces de grande taille. Il réalise un diagnostic en mobilisant une multitude d’activités cognitives complexes. Pour les outiller, nous proposons une classification de ces activités selon la taxonomie de Bloom. Quand la cause réelle opère sur des connaissances autres que celles du model checking, ces moyens sont alors insuffisants. Quand le diagnosticien est le concepteur du modèle, il dispose ou non de connaissances de domaine permettant de le débloquer en lui offrant des nouveaux regards sur la trace. Pour y parvenir, il faut disposer du domaine et corréler les connaissances du domaine et du model checking pour réduire leur fossé sémantique. Nous proposons des structures pour capturer et réutiliser le domaine. D’un côté le problem case formule le problème que l’on cherche à résoudre et permet de préciser le diagnostic de la solution construite. D’un autre côté les sample, pattern et component cases capturent des éléments de solutions et permettent d’isoler le diagnostic. Quand le diagnosticien est l’architecte du système, il combine des éléments de problèmes et de solutions provenant à la foisde l’ingénierie du domaine et de l’application. Pour progresser de manière fluide dans la solution et enrichir les propriétés à vérifier, nous proposons une méthode de résolution de problème. Alimentée par la base de connaissances issue du domaine, celle-ci réalise des allers-retours entre l’espace du problème et l’espace de la solution, traçant problèmes et solutions choisies, et augmentant la vérification et le diagnostic grâce à de nouvelles propriétés. De manière transversale aux autres phases, le processus de vérification doit être organisé. Nous proposons une infrastructure permettant d’organiser, capitaliser et réutiliser les diverses connaissances (model checking, domaine, méthode). L'infrastructure est divisée en trois niveaux, le niveau physique regroupe les données brutes, le niveau connaissance regroupe des ontologies, et le niveau d’accès fournit des interactions supportées par les connaissances, dont les activités cognitives de diagnostic, organisées suivant la taxonomie de Bloom. Nous proposons un outil de simplification de traces par facettes reposant sur cette infrastructure.Model checking is a formal verification technique verifying that a system behavior satisfies formal properties. This technique explores all the possible executions of the system to discover execution paths (traces) violating formal properties. When a property is violated, the engineer must find the root causes that produced the trace. The goal of this work is to assist the engineer during this phase, which is called diagnosis. Our proposition is a framework combining various kinds of knowledge and cognitive activities, supported by a method and an infrastructure. We apply the approach to securing a SCADA system. When the diagnostician is the model verifier, he generally faces large traces. The diagnosis is obtained by mobilizing a multitude of complex cognitive activities. To tool these activities, we propose to classify them according to the Bloom’s taxonomy. Even so, these means are insufficient when the real cause doesn’t operate on model checking knowledge. When the diagnostician is the model designer, he may or may not have domain knowledge. This knowledge offers new perspectives about the trace, and may unblock the diagnosis. We propose a structure to capture and reuse this knowledge. Correlations can be explicited o reduce the semantic gap between domain and model checking knowledge. On the one hand, the problem case formulates the problem to be solved, and precises the diagnosis of the constructed solution. On the other hand, the sample, pattern and component cases capture elements of solutions, and isolate the diagnosis. When the diagnostician is the system architect, he combines elements of problemsand solutions from both domain and application engineering. To progress smoothly in the solution and enrich the properties to be checked, we propose a problem solving method. Fed by the domain knowledge base, the method goes back and forth between the problem space and the solution space, tracing chosen problems and solutions, and facilitating verification and diagnosis thanks to new properties. We propose an infrastructure to organize, share and reuse various knowledge implied during the verification process (model checking, domain, method). This infrastructure is divided into three levels, the physical level gathers the raw data, the knowledge level gathers ontologies, and the access level provides interactions supported by knowledge. We offer a trace simplification tool diagnosis based on facets, and promoted by our infrastructure