• Media type: Text; Electronic Thesis; E-Book
  • Title: Aide au diagnostic de vérification formelle de systèmes ; A diagnosis support for formal verification of systems
  • Contributor: Leildé, Vincent [Author]
  • Published: theses.fr, 2019-11-14
  • Language: French
  • Keywords: Diagnostic ; Bloom’s taxonomy ; Taxonomie de Bloom ; Problem solving method ; Diagnosis ; Méthode de résolution de problèmes ; Model checking
  • Origination:
  • Footnote: Diese Datenquelle enthält auch Bestandsnachweise, die nicht zu einem Volltext führen.
  • Description: 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 ...
  • Access State: Open Access