Rapprocher les méthodes formelles, l’analyse statique et les tests
description
Transcript of Rapprocher les méthodes formelles, l’analyse statique et les tests
Rapprocher les méthodes formelles, l’analyse statique et
les tests29 mai 2012
Le projet Hi-Lite
Hi-Lite
Tests unitaires
Preuves formelles
Analyse statique
Combiner tests et preuves
Renforcer mutuellementtests et analyse statique
Faciliter la preuve formelle grâce à l’analyse statique
Un language commun d’annotation
Travail de la deuxième année des partenaires
Résumé d’ensemble
• T1 : Management et dissémination
• Gestion de projet
• Dissémination des produits du projet
• Forge Hi-Lite : http://forge.open-do.org
• Mailing listes, dépot de sources, …
• Nombreuses publications et participations à des conférences
• T2 : Spécifications
• Exigences collectées l’année dernière, affinées cette année
Rapport d’activité par tâche
• T3 : Langages
• ALFA, E-ACSL manuels de référence mis à jour
• Extensions SPARK
• T4 : Traducteurs
• Gros progrès sur le traducteur ALFA vers Why (gnat2why)
• Support complete de ALFA dans GNAT Pro
• Greffon Frama-C: E-ACSL vers C
Rapport d’activité par tâche
• T5 : Outils d’analyse et de test
• CodePeer : adaptations à ALFA ~ terminée, améliorations
• Nombreuses améliorations dans GNATtest (génération d’un framework de tests unitaires), y compris support des aspects Test_Case
• Evolutions du prouveur Alt-Ergo et de Why3
• Evolutions de la plate-forme Frama-C
• T6 : Bibliothèques et interfaces utilisateur
• Intégration de gnatprove et gnattest dans GPS
• Support de ALFA dans GPS
• Conception en cours d’un outil de consolidation des résultats
• Améliorations dans AltGr-Ergo
Rapport d’activité par tâche
• T7 : Applications industrielles
• Outils (gnatprove/gnat2why, gnattest, GPS, why3, alt-ergo, greffon e-acsl) mis à disposition
• Retour d’expérience, mises à jour disponibles
• Etudes de cas : Thales, Astrium
• Application des outils sur eux-mêmes
• Utilisation de CodePeer sur CodePeer, GNAT, GPS
Rapport d’activité par tâche
• Extensions du langage SPARK dans le but d’améliorer les techniques de preuve, support d’ALFA, et de la bibliothèque des conteneurs, par exemple:
- Invariants de type
- Génériques
• Développement et intégration de “Victor” un traducteur des conditions de vérification SPARK vers le format SMT-Lib afin de facilite l’utilisation de démonstrateurs de théorèmes alternatifs, par exemple Alt-Ergo.
Praxis Work Package
• Implémentation des génériques est en cours de développement par Gaétan Allaert d’Altran-Praxis France.
• SPARK Generics LRM et le document SPARK Generics User View ont été publiés.
• Implémentation par étapes: la dernière version de l’outil SPARK a été délivrée en Décembre 2011 avec support des sous-programmes génériques SPARK.
• La fonction générique Ada.Unchecked_Conversion a été étendue afin de supporter dans le contexte de preuve la possibilité d’appliquer une pré et une post conditions à l’instanciation.
Progrès du Praxis Work PackageLes génériques
• Les activités de validation de la version incluent:
• à travers le tests, l’ajout d’un ensemble considérable de tests dans le but de valider l’implémentation des sous-programmes génériques;
• l’ajout d’annotation de preuve au nouveau code et au code modifié par l’analyse des sous-programmes génériques. Les conditions de vérification qui en résulte ont été déchargées en utilisant les outils de preuve SPARK, y compris Victor et Alt-Ergo.
• L’implémentation des paquetages génériques se poursuit et devrait être disponible dans la prochaine version de l’outil SPARK.
Progrès du Praxis Work PackageLes génériques
• Les génériques comme décrit dans le "SPARK Generics LRM" sont inclus dans la nouvel édition de “SPARK: The proven approach to High Integrity Software” par John Barnes, que sera publié durant Q3 2012.
• Les génériques SPARK excluent certaines caractéristiques d’Ada qui ne sont pas autorisées en SPARK mais gardent un sous-ensemble utilisable.
• L’accent a été placé afin de supporter les caractéristiques nécessaires à supporter une implémentation utilisable de la bibliothèque des conteneurs SPARK.
• Supporter le concept of démontrer une seul fois utiliser plusieurs fois.
Les generiques SPARK
• Tous les composants de la bibliothèque inclus dans la dernière version de l’outil SPARK sont:• SPARK.Ada.Strings.Unbounded• SPARK.Ada.Command_Line• SPARK.Ada.Text_IO• Ada.Interfaces, Ada.Interaces.C • Ada.Character.Handling, SPARK.Unsigned
• Une première spécification de la bibliothèque des conteneurs a été écrite et sera mis à jour suivant le travail réalisé par AdaCore concernant la preuve des programmes utilisants les conteneurs.
• La bibliothèque des conteneurs SPARK sera implémentée des que les paquetages génériques seront disponible en SPARK.
Progrès du Praxis Work PackageBibliothèque SPARK
• Unification de la sémantique entre ALFA et SPARK pour les pré & post conditions ainsi que pour les expressions dans les autres contextes de preuve
− ALFA a une sémantique exécutable.
− SPARK est basé sur une sémantique mathématique.
− Des réunions entre AdaCore et Altran Praxis ont été tenues avec succès dans le but de définir une approche commune.
• Riposte – un générateur de contre-exemples a été développé par Altran Praxis (non financé par le projet Hi-Lite) et des investigations ont été menées pour le rendre disponible avec une interface Why dans le cadre de la technologie Hi-Lite.
Progrès du Praxis Work PackageSupport pour ALFA
Amélioration des techniques de preuve
Buts principaux du projet Hi-Lite (rappel)
- combiner les techniques de test logiciel et de vérification formelle- appliquer ces techniques aux programmes mixtes Ada + C
Contributions visées par le CEA LIST dans ce contexte
- définir un langage de spécifications exécutables pour le C, E-ACSL, fondé sur le langage ACSL existant
- implanter un traducteur d'E-ACSL vers C
- améliorer la plateforme Frama-C dédiée à l'analyse statique de programmes C
E-ACSLExecutable ANSI/ISO C Specification Language
- langage d'annotations exécutables pour le langage C- annotation exécutable = traductible en une expression C évaluable à l'exécution- le plus possible sémantiquement compatible avec ALFA- fondé sur le langage ACSL (ANSI/ISO C Specification Language)- défini au cours de la 1ère année du projet- amélioration au cours de cette seconde année- nouvelle version du manuel de référence (version 1.5-4) à partir de laquelle une implantation a été effectuée- Une publication soumiseM. Delahaye, N. Kosmatov and J. Signoles. Towards a Common Specification Language for Static and Dynamic Analyses of C Programs. Submitted to QSIC 2012.
Traducteur d'E-ACSL vers C
- nouveau greffon de la plateforme Frama-C- traduire les annotations E-ACSL en C pour permettre la vérification d'assertions à l'exécution : runtime assertion checking- utilisation d’entiers GMP (entiers mathématiques) pour être fidèle à la sémantique d’E-ACSL.- schéma de traduction non trivial.- prise en compte d’une grande partie d’E-ACSL, à l’exception notable des constructions liés à la mémoire et aux réels.- version 0.1 distribuée en open source en janvier 2012.- amélioration en cours et prévue pour la fin du projet :
-système de types pour générer un code beaucoup plus efficace-support des constructions liées à la mémoire
Évolution de la plateforme Frama-C
- nouvelle version publique de Frama-C : version Nitrogen-20111001- version requise par le traducteur d’E-ACSL en C- nouveaux mécanismes facilitant les collaborations inter-analyses pour la vérification de propriétés et améliorant le retour utilisateur- une publication acceptée et deux soumises :P. Cuoq, D. Doligez and J. Signoles. Lightweight Typed Customizable Unmarshaling. ML Workshop 2011.
L. Correnson and J. Signoles. Combining Analyses for C Program Verification. Submitted to FMICS 2012.
P. Cuoq, F. Kirchner, N. Kosmatov, V. Prevosto, J. Signoles and B. Yakobowski. Frama-C: a Program Analysis Perspective. Submitted to SEFM 2012.
Résumé des travaux du CEA LIST
- nouvelle version du langage de spécifications exécutables E-ACSL
- distribution open source de la version 0.1 du traducteur d’E-ACSL en C
- évolution de la plateforme Frama-C : version Nitrogen-20111001.
- requise par le traducteur- collaboration inter-analyses
- dissémination scientifique : 1 publication et 3 soumises sur les thématiques Hi-Lite
- à venir :- poursuite du travail d’implantation- vérification programmes Ada + C
Stratégie de Thales dans le projet
• Intégrer les approches Hi-Lite dans l’outillage Thales pour la génération d’applications
• Remontée des spécifications formelles dans les modèles
• Adaptation du code généré pour le rendre conforme à Hi-Lite
• Évaluer cette intégration sur un cas d’étude du domaine spatial
Nouvelle spécification du code à générer
• Mise au point d’un prototype de code adapté aux contraintes d’Hi-Lite
• Masquage des pointeurs dans les structures
• Conservation des fonctionnalités (presque) à l’identique
• Discussions avec les équipes industrielles pour l’adoption du nouveau code
• En cours d’évaluation par rapport aux outils Hi-Lite
Intégration dans l’approche de modélisation
• Définition d’un méta-modèle pour les spécifications formelles
• Préparation des expérimentations sur la modélisation
C1 instance
1C2
instance 2
Tâche 1
Processus 1
C2 instance
1
Specifications
Cas d’étude• Délimitation du cas d’étude
• Contrôle de régulation thermique dans le logiciel de vol
• Assemblage de composants et code d’implémentation
• Objectifs
• Évaluer l’intégration des outils Hi-Lite dans l’approche de modélisation
• Étudier les possibilités de spécifications systématiques sur le code généré
Astrium activities in Hi-Lite• Industrial user• Task 2.1: “Specifications”
• Definition of the industrial needs for the development of critical real time embedded software in the space domain Finalized in 2012
• Task 7.2: “Industrial applications”• Validation of the Hi-Lite approach
Definition of toy examples to validate some specific concepts Definition of a “realistic” application
Task 2.1: “Specifications” (1/2)• Analysis of standards
• ECSS-E-ST-40C (« Space engineering – Software »)• ECSS-Q-ST-80C (« Space product assurance –
Software product assurance »)• Main conclusions
• Test shall be the main validation techniques• Formal proof is accepted and sometimes
recommended• Validation & verification objectives
• Exhaustive detection of run-time errors, traceability between test cases and test procedures, etc.
Important number covered by Hi-Lite
Task 2.1: “Specifications” (2/2)• Astrium general needs
• Decrease of costs and delays• Increase of the quality
• More specific needs• Validation of generic software / customised software• Safe reuse of software building blocks• Verification of the sensor data• Properties on vectors• Etc.
• Used Ada features• Mathematical operators, arrays, ...• Generics, discriminant records, expression functions, ...
Sensors
Actuators
Control
Guidance
Envi
ronm
ent
Envi
ronm
ent
Navigation
GNCGNC
Task 7.2: “Industrial applications” (1/3)
ECS
EPC
EAP
EAP
ECS
EPC
EAP
EAP
ECS
EPC
EAP
EAP
MVMMVM
TC
TM
TM/TCTM/TC
Mission & Vehicle Management
MVMMVM
Telemetry / TelecommandTMTCTMTC
• Orientation of the ATV solar wings• Optimisation of energy
• Experimentations in SPARK• Comparison with Hi-Lite
Task 7.2: “Industrial applications” (3/3)
Algorithms
GenericGeneric
DiscriminantDiscriminant
ContractContract
Test casesTest cases
Formal proofFormal proof
TestsTests
Travail à venir
• Tâches 4 (traducteurs), 5 (outils analyse/test) et 7 (bibliotheques, IHM) en pleine charge
• Finalisation des tâches 2 (spécifications) et 3 (langages)
• Début de la tâche 7 (applications industrielles)
Travail pour cette année
Questions ?