La seconde communauté qui occupe une part toute aussi importante dans nos travaux est celle de l’analyse des systèmes critiques. Cette communauté regroupe les personnes et entités cherchant à définir la criticité d’un système, à l’évaluer, à proposer des outils permettant de l’assurer à un certain niveau et enfin à proposer un ensemble de règles de certification, qui sont gages de la qualité du système en termes de maîtrise des risques.
Dans l’aviation, nous avons déjà évoqué l’importance de la norme [ARP 4754] en matière de développement de systèmes avioniques. Pour garantir le respect de cette norme au regard de la complexité croissante des systèmes, de nouvelles techniques de génie logiciel sont régulièrement intégrées dans la certification des systèmes dès lors qu’ils sont jugés suffisamment matures. Parmi ces techniques de génie logiciel, les techniques de méthodes formelles en particulier sont considérées par beaucoup de spécialistes comme ayant atteint un niveau de maturité suffisant pour être intégrées aux processus de certification. Depuis 2012, elles sont par exemple mentionnées dans la norme DO-178C comme permettant de compléter (mais non remplacer) les phases de tests pour le développement des logiciels avioniques.
Ces techniques reposent sur une modélisation du système dans un langage formel, qui permet de vérifier automatiquement si l’architecture et la dynamique du système respectent un niveau suffisant de criticité. On parle de Model-Based System Engineering lorsque les modèles formels sont utilisés comme moyen de communication et d’information pour concevoir un système ; on parle de Model-Based Safety Assessment lorsque les modèles formels sont utilisés pour réaliser une analyse de risque de façon automatique à partir de modèles, par exemple en produisant des arbres de fautes ou une FMEA (Failure Mode and Effects Analysis).
Pour exprimer cette notion de niveau suffisant de criticité, la majorité des études récentes de MBSA se basent sur les Logiques Temporelles.
II.2.1 Logiques Temporelles
Pnueli [Pnu77] en particulier a contribué à populariser l’utilisation des Logiques Temporelles pour la vérification de programmes. Dans ses travaux fondateurs, il définit une approche de vérification formelle basée sur la prise en compte de la dépendance temporelle entre évènements. Le temps est ici représenté comme une séquence d’états, et les dépendances entre états sont exprimées de manière mathématique sous la forme d’assertions logiques dans une logique modale, appelée depuis Logique Temporelle Linéaire(LTL). Ces travaux étaient réalisés initialement dans le but de vérifier des conditions de séquentialité et parallélisme de programmes, mais ont été appliqués depuis à un vaste panel de domaines, théoriques et industriels.
La logique elle-même a dû être étendue pour prendre en compte d’autres modèles du temps. C’est en particulier le cas de la logique CTL (Computational Tree Logic), proposée quelques années plus tard par Clarke et Emerson [CES86]. CTL est une Logique Temporelle où le temps est vu comme un arbre d’états successifs, ce qui représente le fait que le futur n’est pas déterminé. Une branche de l’arbre représente alors un futur possible. À partir de la logique CTL, on parle de Model-Checking pour désigner le fait de vérifier des propriétés sur un système ou un programme à partir de Logiques Temporelles. CTL permet d’exprimer des assertions telles que "lorsque toutes les variables sont positives, alors toutes exécutions possibles du programme ne mènent jamais à une division par 0". Un model-checker explorera alors de façon exhaustive toutes les branches possibles satisfaisant la condition initiale, et vérifiera que toutes les exécutions dans le futur respectent la seconde condition. Bien que CTL et LTL aient été développés de façon indépendante et parallèle, ils ont une grande proximité, en dépit de certaines propriétés qui ne peuvent être exprimées qu’en CTL ou en LTL.
Ce manque d’interopérabilité complète entre CTL et LTL a été à l’origine de la création de la logique CTL*, permettant notamment de combiner librement des quantificateurs et des opérateurs temporels. Tout comme CTL, CTL* est une Logique Temporelle basée sur un arbre. On peut montrer trivialement que CTL* contient à la fois CTL et LTL.
En termes de complexité de vérification, Emerson [Eme90] a prouvé que la vérification d’une propriété LTL était de complexité PSPACE dans le cas général. Il a été prouvé par ailleurs que le
Model-Checking CTL* a la même complexité (PSPACE). Dans ses travaux, Emerson s’est intéressé à la comparaison de plusieurs Logiques Temporelles, y compris LTL et CTL, permettant de mettre en valeur ce qui est exprimable ou non dans une certaine logique. Il apparaît en particulier que de nombreuses Logiques Temporelles peuvent être construites sur des concepts différents, telles que des logiques centrées sur le passé au lieu du futur, des logiques prenant en compte des probabilités, ou encore des logiques permettant de raisonner sur l’état de la connaissance des systèmes réactifs.
Chacune de ces logiques gagne en expressivité par rapport aux logiques LTL et CTL ; nous allons à présent en détailler plusieurs qui nous semblent particulièrement pertinentes pour notre problème.
Baier, Katoen et Hermanns ont défini en 1999 [BKH99] la logique CSL (Continuous Stochastic Logic)permettant d’exprimer des propriétés dans un système à temps continu. Le modèle sous-jacent est celui des Chaînes de Markov à Temps Continu, dont nous rappellerons la définition par la suite. CSL est une logique particulièrement puissante ; elle est devenue la référence de nombreux outils pour le Model-Checking à temps continu, au même titre que LTL et CTL sont les références pour le Model-Checking à temps discret. Baier et al. ont proposé de nombreuses méthodes de résolution, montrant qu’il est possible de ramener les assertions CSL à des systèmes d’équations linéaires, pour lesquelles des méthodes très performantes existent. CSL a elle-même été étendue par la suite, en particulier avec l’ajout de récompenses par HaverKort et al. [HCH+02] et avec l’ajout de probabilités par Baier et al. [BHHK03].
L’ajout de récompenses en particulier est intéressante pour notre problème, puisqu’elle permet d’imposer des vérifications sur des niveaux de performance dans le temps, en plus d’imposer des performances sur la séquentialité et l’atteignabilité des états. Ce type de considération nous rapproche des considérations que nous avons dans les systèmes critiques, pour lesquels nous souhaitons aussi évaluer les évolutions futures d’un système en fonction d’un niveau de performance, privilégiant par exemple les évolutions les moins onéreuses, ou les plus rapides, sous conditions évidemment qu’elles respectent aussi les autres contraintes de Logique Temporelle. De telles évaluations peuvent être exprimées en CSRL (Continuous Stochastic Reward Logic), qui est une logique se basant sur des Modèles de récompense Markoviens. Néanmoins, il est essentiel de noter que CSRL ne parle pas d’optimisation de récompense (cumulée), mais de vérification d’un niveau de performance : il ne s’agit pas de chercher la performance maximale, mais seulement de garantir qu’elle a en moyenne (probabiliste) un certain niveau. Cette distinction pourrait s’avérer bloquante pour notre problème, dans l’utilisation de logiques telles que CSRL, puisqu’il ne semble pas trivial d’adapter la vérification de propriétés CSRL à de la prise de décision sous contraintes CSRL.
L’ajout de probabilités à CSL est tout aussi intéressant : Baier et al. s’inspirent de plusieurs logiques existantes pour construire une logique évaluant des mesures de probabilités sur des ensembles de chemins dans une Chaîne de Markov à Temps Continu. Les auteurs proposent une méthode de résolution basée sur un système d’équation intégrale, ainsi qu’une réduction du problème au travers d’une bisimulation. L’intérêt pour notre problème est que les contraintes que nous devons prendre en compte sont de nature probabilistes : pour un système critique, il faut en général vérifier qu’une certaine séquence d’évènements, par exemple la perte d’une fonction de pilotage, n’arrive qu’avec une probabilité extrêmement faible ; c’est-à-dire qu’il faut vérifier que le système atteint un état défaillant avec une probabilité inférieure à un certain seuil. Au premier regard, ce type de contraintes que nous recherchons semble correspondre à celles qui sont exprimables avec cette extension de CSL.
Cependant, ces deux dernières extensions de CSL ont pour principale limitation d’augmenter de manière conséquente la complexité de la vérification, c’est-à-dire le temps de calcul moyen mis pour vérifier une assertion. Il est difficile d’évaluer a priori dans quelle mesure cette limitation rend inenvisageable l’utilisation de CSL pour notre problème, puisqu’il existe certains exemples dans la littérature où un algorithme à variables continues a de meilleures performances qu’un algorithme à variables discrètes. Cependant, nous pouvons identifier la cause principale de cette complexité : la logique CSL prend en compte un temps continu, ce qui nécessite un traitement intégral lors des cas les plus complexes. Il semble donc pertinent de s’intéresser en priorité aux modèles à temps discret, et de déterminer dans quelle mesure les modèles que nous souhaitons traiter nécessitent un temps continu. La version probabiliste tire son inspiration de la logique PCTL (Probabilistic real time Com-putation Tree Logic ) [HJ94], qui elle-même tire son inspiration de CTL et de travaux d’auteurs
CHAPITRE II. ÉTAT DE L’ART
ayant étendu CTL. Hansson et Jonsson définissent ainsi une logique exprimant des formules sur une Chaîne de Markov à Temps Discret, ainsi que des algorithmes permettant de vérifier ces formules en temps polynomial, dans la taille de la formule et dans la taille de la chaîne de Markov. Tout comme la version probabiliste ultérieure de CSL, les formules exprimées correspondent à la mesure de la probabilité d’occurrence de certaines formes de chemins. PCTL est devenue depuis une des logiques de référence pour les outils de Model-Checking probabiliste. Hansson et Jonsson ont montré que l’ensemble des opérateurs de CTL pouvaient être exprimés à partir des opérateurs de PCTL.
De nombreux travaux ultérieurs se sont basés sur PCTL pour proposer des extensions de la logique, des méthodes de vérification efficaces ou encore des problématiques de vérification différentes. Il est intéressant de noter par exemple les travaux de Brasfil et al. [BFKK08] sur la satisfiabilité de PCTL, c’est-à-dire le fait de trouver un modèle vérifiant une certaine formule PCTL. Ce problème est intéressant puisqu’il montre l’étendue des applications possibles pour PCTL, bien qu’il ne semble que difficilement praticable pour des cas industriels en raison de sa complexité : pour la satisfiabilité de CTL et PCTL, les travaux de Brasfil et al. montrent que la complexité est EXPTIME-complet.
En termes de performances, on pourra noter les méthodes récentes basées sur les Strongly Connec-ted Components (SCC)[Tar72] tels que les travaux de Teichteil, Infantes et Seguin [TKIS11] : ces méthodes utilisent les algorithmes définis par Hansson et Jonsson en les combinant à une découverte à la volée des états d’un système, ainsi que des boucles présentes entre ces états. La découverte de boucle permet alors d’effectuer un ensemble de calculs locaux afin de rendre la vérification de la formule PCTL plus rapide. De telles méthodes, exploitant la structure des données, contribuent à rendre le model-ckecking probabiliste réalisable sur des modèles de taille industrielle avec les techniques de calcul de ces dernières années.
Enfin, parmi les extensions PCTL qui sont d’un intérêt particulier pour notre problème, on pourra noter les travaux récents de Yoo, Fitch et Sukkarieh [YFS12], qui augmentent l’expressivité du langage PCTL avec des contraintes sur des ressources, exprimées au moyen de variables dans R. Ces contraintes expriment des seuils de performance ou de ressources qui doivent être respectés de manière ferme ou douce. Il s’agit encore une fois de concepts intéressants pour notre problème, puisque nous serons éventuellement amenés à devoir contraindre l’évolution d’un système en fonction d’un niveau de performance attendu. Cependant, ces méthodes se concentrent sur la validation de contraintes et non la synthèse de stratégie permettant de les valider, ou encore optimisant un niveau de performance. Il n’est donc pas évident sans une étude préliminaire de savoir s’il sera possible d’exploiter ces travaux en l’état, puisqu’il n’est pas trivial de passer de la vérification à la synthèse de contrôleur valide.
II.2.2 Outils de modélisation
Si l’avantage principal des techniques de Model-Checking est de proposer une analyse exhaustive des risques - ce qu’il est difficile de garantir par un processus manuel - leur inconvénient principal est le coût de construction du modèle. Les modèles que nous considérons sont des modèles logiques, c’est-à-dire qu’il n’est pas nécessaire de simuler précisément la valeur de chacun des signaux, mais simplement de se concentrer sur des notions telles que "transmis", "correct" ou "erroné" ; néanmoins il est nécessaire de créer ces modèles à partir de la connaissance des concepteurs du système, sous une forme qui puisse donc à la fois être facilement lisible par un être humain et lisible par une machine. On parle de langage formel pour décrire un langage lisible par une machine sans ambiguïté. Par exemple, une spécification écrite en texte libre dans un document peut comporter des ambiguïtés, alors qu’une formule mathématique n’en comporte pas. L’enjeu des outils assistant la modélisation formelle est donc de proposer des aides à un utilisateur pour saisir les données dans un langage formel ; ceci passe dans un premier temps par la définition de ce langage, qui agit comme pont entre l’utilisateur et la machine.
Arnold, Point, Griffault et Rauzy [APGR99] ont défini le langage Altarica dans cet objectif. Il s’agit d’un langage permettant de décrire le comportement d’un système complexe, constitué de plusieurs composants qui interagissent de façon dynamique. Le cœur de cette dynamique repose sur la notion de machine à état et de transition : chaque composant peut subir des évènements, le faisant changer d’état. Arnold et al. ont défini les règles syntaxiques et sémantiques de ce langage ; ils ont prouvé la cohérence du langage au travers de la définition d’une bisimulation, permettant de montrer que les
résultats de validation formels obtenus dépendent uniquement du comportement décrit dans le modèle, et non de la syntaxe choisie pour décrire chacun des composants.
Le langage Altarica a depuis donné naissance à de nombreuses dérivations, en particulier les versions Altarica Dataflow [Rau02] et Altarica 3.0 [Pro14] qui se sont concentrées sur les facilités de modélisation et de validation dans un contexte industriel. Altarica Dataflow en particulier a été intégré à des outils tels que Cecilia OCAS (Dassault Aviation), Simfia (EADS Apsys) ou Safety Designer (Dassault Systemes). Ces évolutions du langage apportent à la fois des avantages et des limitations, qui sont à prendre en considération en fonction du système que l’on souhaite modéliser [BBC+04]. Ainsi, Altarica Dataflow impose une restriction au langage pour en rendre la validation plus rapide en termes de temps de calcul ; cependant cette restriction dans la direction des flux de données rend impossible ou complexe la modélisation de certains systèmes, tels que des systèmes hydrauliques où il n’est pas aisé d’identifier une direction unique de propagation. À l’inverse, sans cette restriction, certains modèles sont trop complexes pour que les algorithmes de validation puissent les traiter en temps raisonnable. Il semble y avoir ainsi deux difficultés actuelles qui limitent l’acceptabilité de ce langage et des langages similaires par le milieu industriel : celle de trouver le juste milieu entre l’expressivité du langage et la facilité d’utilisation - ce qui comprend le temps de traitement des modèles - et celle de la reconnaissance par les processus de certification.
D’autres outils de Model-Checking existent, qui se sont attaqués à ces problèmes avec le même succès relatif. On citera par exemple le langage B [Abr96] et les suites d’outils Atelier B et RODIN, qui sont l’un des exemples d’application des méthodes formelles à des cas industriels concrets : le langage B a été utilisé pour certifier le logiciel embarqué de la ligne 14 du métro parisien. Ce langage a depuis été utilisé pour la certification d’autres lignes de métro. L’apport principal du langage B est qu’il permet de générer directement une partie du logiciel embarqué, dont il est prouvé qu’il vérifie des spécifications formelles. Cependant, son applicabilité à notre problème est limité puisqu’il ne permet pas de façon native de vérifier des contraintes probabilistes. On peut aussi citer des langages tels que ADL [MT00] ou SMV (ainsi que l’outil NuSMV permettant le Model-Checking [CCG+02]), et nous renvoyons un lecteur intéressé aux différentes études qui montrent les avantages et les inconvénients de ces formalismes.
Parmi les outils de Model-Checking probabiliste, on notera en particulier l’outil MRMC (Markov Reward Model Checker) [KZH+11], supportant le Model-Checking PCTL et CSL ainsi que les extensions de ces deux logiques avec des récompenses. Cet outil est intéressant dans la mesure où il offre des performances raisonnables pour la vérification de contraintes PCTL et CSL, ce qui correspond à une partie du problème que nous souhaitons résoudre. De façon similaire, l’outil et le langage PRISM [KP13] permet de réaliser de la vérification formelle probabiliste avec des techniques efficaces pour les logiques PCTL et CSL. Une partie de l’efficacité de ces techniques repose sur l’utilisation de structures de données adaptées telles que les Binary Decision Diagram [BRB91].
II.2.3 Questions ouvertes en amont de notre étude
Au regard des travaux existants au début de cette étude (Figure 8 page 38), nous pouvons en conclure que les technologies de vérifications formelles ont atteint une maturité suffisante pour être intégrées au sein de processus industriels. Nous pouvons aussi en conclure qu’aucun outil ne paraît avoir reçu d’approbation unanime de la part des concepteurs de systèmes ; ceci découle en particulier du fait que les deux questions suivantes ne semblent pas avoir reçu de réponse satisfaisante :
– Comment faciliter la saisie d’un modèle par des ingénieurs systèmes ?
– Quel est le niveau de modélisation nécessaire ? En particulier, à quel point peut-on réduire l’expressivité d’un langage tout en permettant à un utilisateur de saisir et vérifier les systèmes cibles ?
Il semble probable qu’il n’y ait pas de réponse unique à ces questions, qui dépendront des domaines d’applications industriels envisagés.
Si ces deux questions semblent principalement adressées aux outils et langages de modélisation, elles ont néanmoins un impact sur le modèle mathématique qui sous-tend la vérification. On peut de
CHAPITRE II. ÉTAT DE L’ART DiscretuTimeu MarkovuChain CTL CTL* CSL CSRL Model-checking probabiliste Model-checking PCTL LTL Méthodesuformelles ContinuousuTime MarkovuChain MarkovuRewarduModel Modèles mathématiques Logiques temporelles Analyse des systèmes critiques AudériveudeuB AuPermetudeumodéliseruB A B A B
F i g u r e 8 – État de l’art de l’analyse des systèmes critiques, centré sur les Logiques Temporelles pour l’expression de contraintes.
la même manière se poser la question de l’expressivité d’une Logique Temporelle choisie : dans quelle mesure est-il nécessaire de choisir des Logiques Temporelles complexes (CSL, PCTL, ...) pour exprimer les contraintes de notre problème, et dans quelle mesure peut on se limiter à des logiques plus simples et potentiellement plus faciles à vérifier ?
Il semble ainsi apparent que les technologies de modélisation formelles ont quitté le domaine de la recherche fondamentale, pour s’orienter vers une problématique d’industrialisation : la question n’est plus de fournir des réponses génériques à des problématiques théoriques, mais de faire face à l’acceptabilité par les industries ainsi qu’au problème de passage à l’échelle sur des données réelles.