Dans les obligations de preuve générées, une ou même plusieurs preuves peuvent ne pas être satisfaites. Dans ce cas, nous devons effectuer un diagnostic afin d’établir si l’exigence n’est pas satisfaite ou si l’ensemble des contrats doit être raffiné afin de prouver la satisfaction de l’exigence. Nous basons ce diagnostic sur la génération d’un contre-exemple, qui pour la méthode précédente conduira à l’état d’erreur π, et l’utilisation de l’approche CEGAR [50].
Nous pouvons distinguer deux cas pour lesquels la solution dépend de la manière d’appliquer le raisonnement, pour la conception ou pour la vérification : (1) la satisfaction d’un contrat ou un pas de dominance n’est pas satisfait ou (2) la vérification de la conformité échoue. Pour le premier cas, si nous sommes dans une approche de conception et si toutes les étapes précédentes ont été prouvées, nous devons raffiner les composants/contrats sources tels que le contre-exemple soit éliminé. Ceci garantit que les composants développés sont corrects par construction à l’égard de l’exigence. Si nous sommes dans une approche de vérification avec un système complètement modélisé, il faut raffiner le(s) contrat(s) cible car il est plus fréquent que l’abstraction soit erronée.
Pour le dernier cas, nous devons d’abord vérifier sur le système si le contre-exemple généré est incorrect à cause des abstractions définies ou valide, ce qui signifie que le système ne satisfait pas l’exigence. Pour un contre-exemple faux, il faut raffiner le contrat cible et vérifier au moins l’étape de dominance et la satisfaction du contrat inverse. Des itérations de raffinement de contrats doivent être exécutées jusqu’à ce que toutes les vérifications soient validées. Pour un contre-exemple valide, l’utilisateur doit redéfinir les implémentations, à savoir les composants
atomiques pour lesquels la preuve a échoué. Pour cela, le raisonnement à base de contrats peut être appliqué dans une approche de conception afin d’obtenir les contrats corrects qui satisfont les obligations de preuve et les raffiner vers des implémentations correctes.
Nous remarquons que, dans le cas de nos outils, le contre-exemple généré est exprimé au niveau des automates temporisés entrée/sortie, tandis que le raffinement de contrats/composants a lieu dans un langage de modélisation de haut niveau. Le pont entre les deux formalismes est unidirectionnel : la transformation présentée ci-dessus est donnée à partir de SysML vers des automates temporisés entrée/sortie. Afin d’exploiter le scénario d’erreur, le concepteur doit appréhender en détail le système et faire usage de son expérience pour effectuer ce raffinement. Ce point est une question ouverte pour laquelle la recherche actuelle prévoit certaines options [56, 3] ; il constitue une de nos perspectives de travail.
5.5
Travaux connexes
Comme décrit à la section 2.2, il existe plusieurs frameworks à base de con- trats disponibles pour les systèmes temporisés qui sont basés sur le raisonnement hypothèse-garantie. La méta-théorie de [142] est la seule qui propose un raison- nement circulaire permettant de réduire la dominance à un ensemble de preuves de satisfaction de contrat. A notre connaissance, cette étude est la première in- stanciation de la méta-théorie définie dans [142] pour les systèmes temporisés avec communication asynchrone.
Le framework à base de contrats proposé dans [63] pour les automates temporisés entrée/sortie présenté dans [61, 62] définit la satisfaction d’un contrat comme la simulation alternée temporisée sur le quotient. Formellement, la relation s’écrit K ≤ (A k G)\\A, où ≤ désigne la simulation et \\ l’opérateur de quotient. Cette théorie ne prend pas en compte le raffinement de signature entre les spécifications. En outre, l’opérateur de quotient est partiel : les conditions dans lesquelles l’opérateur peut être appliqué et ce qu’il advient si le résultat ne peut pas être calculé ne sont pas abordés. Comme cette théorie est une instanciation de la méta-théorie décrite en [17], la dominance ne peut être établie que par la composition des contrats et la vérification du raffinement entre la composition et le contrat abstrait. Enfin, ce cadre ne précise pas clairement quel type d’exigence peut être vérifiée ni comment une exigence doit être modélisée. En conséquence, l’étape de la conformité n’est pas formalisée.
entrée/sortie de [7] qui sont étendus par la notion de coinvariant sur les états afin d’exprimer des hypothèses de vivacité. Ce cadre est adapté afin de vérifier des propriétés de sûreté et vivacité borné dans le temps. La relation de raffinement est identique à la nôtre, c.à.d l’inclusion des traces temporisées, mais le raffinement de signature n’est pas considéré ici alors qu’il est explicitement traité dans notre cadre. Une deuxième différence consiste en la définition du contrat : le cadre de [44] définit une théorie d’interfaces où une spécification englobe à la fois l’hypothèse et la garantie. L’avantage d’avoir des hypothèses et des garanties disjointes est discuté à la section 2.2.
La théorie de [43, 39, 42] couvre ces différences en proposant un framework de raisonnement hypothèse-garantie mais seulement pour les systèmes non-temporisés. Par conséquent, un contrat est donné par deux ensembles de traces — un pour l’hypothèse et l’autre pour la garantie, alors qu’une relation d’inclusion de traces covariante pour les entrées et contravariante pour les sorties est considérée pour la satisfaction d’un contrat. Comme pour la méta-théorie de [17], vérifier la dominance exige de composer les contrats et ensuite de vérifier le raffinement. En revanche, notre condition suffisante pour la dominance permet d’effectuer une vérification sur des composants plus abstraits. De plus en cas de violation, le contrat erroné peut être plus facilement identifié.
6
Une étude de cas issue de l’industrie : le
Solar
Generation System de l’ATV
Cette section présente le système Solar Wing Management (SGS) de l’Automated Transfer Vehicle (ATV) et sa vérification selon la technique de raisonnement à base de contrats. L’ATV, développé par Airbus Defence and Space1 (ADS) est un
cargo spatial mis en orbite par le lanceur européen Ariane 5 ayant comme objectif le ravitaillement de la Station Spatiale Internationale. Le système SGS décrit ici est responsable de la gestion des panneaux solaires qui fournissent au véhicule l’énergie nécessaire pour remplir sa mission. Il contient les chaînes fonctionnelles qui réalisent le déploiement et la rotation des panneaux solaires.