Le model checking pour Lustre

Le model checking est une méthode formelle qui permet de vérier qu'un système satis- fait une spécication sur tous les états accessibles, de manière rigoureuse et automatique. Le model checking est principalement utilisé dans la conception de circuits électroniques et la vérication de programmes, mais c'est une technique qui peut également permettre d'analyser des systèmes nanciers, physiques ou biologiques [Clarke, 2008].

Le model checking nécessite une description adaptée du système. Généralement il s'agit d'une représentation sous forme d'automate explicite, c'est à dire d'un graphe orienté qui décrit les états possibles du système et son évolution. Pour vérier qu'un programme satisfait une propriété (exprimée dans une logique appropriée, détaillée ci-dessous), le model checker vérie de manière exhaustive (mais optimisée) tous les états possibles du programme, ce qui ne peut être fait par du test. En Lustre, chaque état correspond à une combinaison possible de valeurs pour tous les ots. La principale diculté du model checking est donc de gérer l'explosion des états. Une avancée majeure dans la gestion de ce problème a été apportée les techniques symboliques : plutôt que de stocker individuellement chaque état, il est possible

de représenter des ensembles d'états de manière symbolique et compacte, notamment par diagramme de décision binaire (BDD) [Baier and Katoen, 2008] [Mebsout, 2014].

Exemple: Si on considère un système à deux variables a et b et que les états possibles pour toute exécution sont (11), (01) et (10) alors, il est possible de manipuler la fonction booléenne a ∨ b qui représente cet ensemble (sous réserve que a ∨ b, qui ne distingue pas les valeurs de a et b, soit pertinent pour la formule à prouver).

En plus de la description du système, le model checking a besoin d'une logique pour per- mettre d'exprimer les propriétés à vérier. L'avantage de Lustre est qu'il bénécie d'une dénition formelle déclarative. Il est donc possible d'exprimer des propriétés dans le même langage que celui utilisé pour programmer (via un ot booléen). Un n÷ud Lustre qui en- code une propriété est appelé un observateur d'Halbwachs-Caspi [Halbwachs et al., 1988] [Halbwachs, 1993] [Raymond, 2008]. Comme tout n÷ud Lustre, il s'agit d'une relation ma- thématique/logique entre des ots d'entrée et de sortie.

Propriétés en Lustre

En Lustre, il est seulement possible d'écrire des propriétés de sûreté (safety) [Verimag, 2018]. Intuitivement, ces propriétés assurent que  quelque chose n'arrivera jamais . Au contraire, les propriétés de vivacité (liveness) sont des propriétés qui assurent que  quelque chose arrivera  à partir d'une certaine exécution [Lamport, 1977]. Ce type de propriétés implique de raisonner sur des exécutions innies, ce qui nécessite généralement de faire appel à des logiques temporelles plus complexes, ou à d'autres modèles comme les réseaux de Pétri qui exploitent des techniques algébriques [Petri, 1980] [Murata, 1989].

Exemple: Pour vérier la propriété  x ne sera jamais diérent de y , on peut écrire en Lustre l'observateur (obs) suivant :

node obs(x, y : int) returns (prop: bool); let

prop = x = y; tel

Le ot booléen prop est vrai quand x = y. La propriété est donc satisfaite si prop est toujours vrai.

Dans bon nombre de cas, il est possible de transformer les propriétés de vivacité en pro- priétés de sûreté, en utilisant la négation. De plus, pour l'étude des systèmes critiques, ce sont généralement les exigences de sûreté qui nécessitent d'être vériées. Dans ce contexte, la limitation de Lustre à l'écriture des propriétés de sûreté n'est donc pas trop contrai- gnante [Verimag, 2018].

Les outils de model checking pour Lustre : le cas particulier de Kind2

Plusieurs outils de model checking existent pour vérier des propriétés en Lustre. On peut notamment citer Lesar [Pace et al., 2004] [Verimag, 2018], Nbac [Jeannet, 2000] [Jeannet, 2010], Luke [Franzén, 2006] et Rantanplan [Hagen and Tinelli, 2008].

Nous allons présenter plus en détail le model checker Kind2 [Champion et al., 2016] car c'est celui que nous utilisons dans cette thèse (Chapitre 8). Il est plus sophistiqué que les autres model checkers mentionnés ci-dessus et il a notamment été montré plus ecace pour des systèmes proches de ceux sur lesquels nous travaillons [Hagen and Tinelli, 2008] [De Maria et al., 2016]. Kind2 est un model checker open-source qui repose sur des solveurs SMT (pour Satisabilité Modulo Théories). Les solveurs SMT sont des outils qui permettent de répondre au problème de la satisabilité d'une formule exprimée en logique du premier ordre (sans quanticateurs) combiné à des théories comme la théorie des réels, la théorie des nombres ou la formalisation de structures de données [Biere et al., 2009] [Thiré, 2016].

Exemple: Étant donnée la formule (a > 0 ∧ a < 10) ∧ (a = b − 2) ∧ (b > 10 ∨ b < 0), qui ne contient pas de quanticateurs ( quelque soit  ∀ ou  il existe  ∃), le problème SMT consiste à déterminer si elle est satisable par rapport à une théorie donnée. Si on considère la théorie des réels, il s'agit de déterminer s'il existe des valeurs réelles pour a et b telles que la formule soit vraie.

Kind2 a été implémenté en se fondant sur les techniques de son prédécesseur PKind [Kahsai and Tinelli, 2011]. Il permet de vérier des propriétés (de sûreté) expri- mées en Lustre sous forme de propriétés invariantes, c'est à dire sous forme de prédicats sur les variables qui doivent être satisfaits dans tous les états atteignables. Kind2 représente le programme Lustre par un système de transition d'états, c'est à dire par un ensemble d'états et de transitions entre les états, qui peuvent être étiquetées.

Pour vérier que le système satisfait une certaine propriété, Kind2 fait appel à plusieurs techniques qui s'exécutent simultanément et coopèrent :

• la k-induction qui consiste à prouver que la propriété est satisfaite dans tous

les états atteignables en k transitions et que si elle est satisfaite pour k transi- tions consécutives alors cela implique qu'elle est satisfaite à la k + 1i`eme _transi-

tion [Gurnkel and Ivrii, 2017] ;

• la méthode IC3 (pour Incremental Construction of Inductive Clauses for In-

dubitable Correctness) qui génère un renforcement inductif lorsque l'induction échoue [Bradley, 2012] ; intuitivement, IC3 permet de réexprimer une propriété induc- tive en s'appuyant sur une autre propriété qui est elle-même inductive et satisfaite sur les états initiaux [Sebastian, 2014] [Gurnkel and Ivrii, 2017] ; IC3 est souvent com- plémentaire avec la k-induction [Champion et al., 2016] [Gurnkel and Ivrii, 2017] ;

• plusieurs moteurs qui génèrent des propriétés invariantes auxiliaires à la vo-

lée pour faciliter la résolution par les techniques ci-dessus [Tiwari et al., 2001] [Champion et al., 2016].

Kind2 est utilisé académiquement, mais également dans l'industrie, en particulier pour la conception de systèmes embarqués (Rockwell Collins, General Electrics, NASA Ames) [Champion et al., 2016]. Dans le Chapitre 8 de cette thèse, nous présentons une utilisation de Kind2 pour la vérication de propriétés sur des modèles de neurones.

ÉTAT DE L'ART ET MOTIVATIONS

Nos travaux ne s'inscrivent pas de manière évidente dans un courant qui possède une bi- bliographie établie. Par conséquent, l'état de l'art dans lequel se positionne cette thèse est relativement hétérogène. Nous choisissons donc de diviser ce chapitre en plusieurs sections bien distinctes.

Puisque notre objectif principal est de dénir un nouveau modèle de neurone unique, nous commençons par introduire les modèles existants (Section 3.1). Le but ici n'est pas d'en donner une liste exhaustive, mais simplement de fournir les informations nécessaires pour mettre en évidence notre positionnement original par rapport à l'état de l'art de ce domaine.

Notre objectif à plus long terme est d'appliquer de manière systématique des méthodes formelles de l'informatique pour permettre de raisonner, de manière assistée par ordinateur, sur des neurones en réseaux. Dans une seconde section, nous présentons donc des exemples de formalismes pour modéliser des systèmes biologiques dynamiques, qui bénécient largement des méthodes formelles et en particulier du model checking (Chapitre 2, Section 2.4). Nous pourrons constater, à cette occasion, que le succès des méthodes formelles repose sur un niveau d'abstraction susant du système à étudier (Section 3.2).

Enn, nous expliciterons les motivations amenant à la dénition du modèle de neurone unique proposé dans cette thèse (Chapitre 4). L'idée est la suivante : nous souhaitons un modèle susamment abstrait pour tirer prot, à terme, des méthodes de preuve formelle de l'informatique, tout en étant biologiquement plausible dans le contexte de l'étude des assemblées de neurones (Section3.3).

3.1 Modèles de neurones uniques

Il n'existe pas de catégorisation universelle des modèles de neurones uniques, mais nous nous eorçons dans cette section de diérencier les modèles à la fois en fonction de leur domaine d'application et en fonction des paradigmes et hypothèses sur lesquels ils reposent. Il n'y a pas de frontière stricte entre les diérentes catégories, mais plutôt des sortes d'ordres partiels entre les modèles, selon le point de vue.