Page : 1 Référence : DIG 95/ AFADL 2000 - Grenoble, 26-28 janvier 2000 Direction de la Prospective Regard sur 10 années dintroduction des méthodes formelles

Page : 1 Référence : DIG 95/AFADL’ 2000 - Grenoble, 26-28 janvier 2000Direction de la Prospective

Regard sur 10 années Regard sur 10 années d’introduction d’introduction

des méthodes formellesdes méthodes formelles

Regard sur 10 années Regard sur 10 années d’introduction d’introduction

des méthodes formellesdes méthodes formelles

Emmanuel Ledinot

Direction de la Prospective


PlanPlanPlanPlan

Contexte industriel: quel besoins ?

Démarche: quelles méthodes dans quel ordre ?

Résultats: quelles expériences ?

Satisfactions

Désillusions

« Conclusion »


Contexte industrielContexte industrielContexte industrielContexte industriel

Quels systèmes ?

Quelle organisation industrielle ?

Quels processus de développement ?

Pourquoi vouloir introduire des méthodes formelles ?


Intégration entre ...Intégration entre ... Le Système de Contrôle du Vol

5 calculateurs numériques + 2 calculateurs analogiques logiciel unique et critique pas de sous-traitance

Les Systèmes ‘ Avion ’ ~ 10 calculateurs spécification et intégration / validation sous-traitance

Le Système Mission ou ‘ Cœur Avionique ’ 2 calculateurs spécification et intégration / validation


Systèmes à logiciel prépondérantSystèmes à logiciel prépondérant

Logiciel du calculateur de mission Rafale F1: ~ 650 000 lignes d’Ada ~ 7500 pages de spécification détaillée

Ordres de grandeur des coûts et délais aujourd’hui: pour une étape de développement de 60.000 lignes 24 mois (spécification détaillée -> livraison calculateur) 30 à 40 personnes 260 fiches de modification


Pourquoi introduire Pourquoi introduire des méthodes formelles ?des méthodes formelles ?Pourquoi introduire Pourquoi introduire des méthodes formelles ?des méthodes formelles ?

Sortir d’une approche artisanale

CAO du logiciel (et du système ?)

Spécifications exécutables et validables augmenter la productivité en avionique mission

Preuve de logiciel embarqué augmenter la sécurité de la couche exécutive SCV


Positionnement dans le processus SNA Positionnement dans le processus SNA

Exigences Opérationnelles Armées de l’Air

Specifications Globales

(Point de vue pilote - Scénarios)

~ 20 x 100 pages

Prototypage rapide IHS

Simulation TR pilotée

Décomposition Fonctionnelle

Equipements


Positionnement processus SNA Positionnement processus SNA

~ 150 + 50 modules fonctionnels

Spécifications Réseaux et dimensionnement

(~40.000 infos)

Spécification Logiciel

Fonctionnelle

Spécification Logiciel

Orienté Objet

Méthodes FormellesMéthodes Formelles

50 x 150 pages

codage manuel ou génération automatique de code

Intégrationet Validation


PlanPlanPlanPlan

Contexte industriel

Démarche

Résultats

Satisfactions

Déceptions

« Conclusion »


20%

30%

50%

Décomposition du coût du logicielDécomposition du coût du logiciel

Spécification

Réalisation

Tests & Validation


AutomatesAlgorithmes

40% en lignes de code 70% en fiches de modification

Mais

Le logiciel contient automates & algorithmes Le logiciel contient automates & algorithmes


Que font les automates ?Que font les automates ?

Les conditions d’activation / désactivation

Les modes

Les commandes

Les reconfigurations


Que font les algorithmes ?Que font les algorithmes ?

localisation, navigation, itinéraires, trajectoires

situation tactique (entretien/affichage des pistes)

domaines de tir, balistiques

calcul de réticules de guidage


DémarcheDémarche

1. Logiciel séquentiel d’application

automates

algorithmes

Logiciel distribué d’exécution (middleware)

transactions sérialisées

consensus, ordonnancement TR, tolérance aux fautes

Esterel, Statemate, Lustre

Coq / ML, B, VDM++


PlanPlanPlanPlan

Contexte industriel

Démarche

Résultats

Satisfactions

Déceptions

« Conclusion »


10 ans d’effort pour passer à l’échelle10 ans d’effort pour passer à l’échelle

Simplicité

Graphique

Passage à l’échelle

Robustesse

Support

Code sûr

Code efficace

Fondements

89 99

Debugger symbolique

Causalité Constructive

Interpreteur

Interpréteur

SyncCharts Rose RT

Simulog

TiGer BDD Package

ModularitéEsterel ++

91 93 95 97

Synthèse de circuit

Simulation Exhaustive

Suite d’équations

Hardware Optimizers

Optimiseurs HardAutomate Explicite


Quelques statistiques Esterel Quelques statistiques Esterel

FCS MC Scheduler

FCS MC Panel

Landing System

Side Displays

FuelManagement

Inputs

Outputs

Modules

Instances

Esterel Lines

Size Kb

Time ms

35 20 36

65

35

1100 160

110

80

3200

17

0.9

30

30

40

2000

124

1.6

1400

500

700

42240

195

n.r

300

65

280

6500

80

2.6

190

105

425

15000

80

2.6

4600

nr

1.55

127

28

69

Alarms


Résultats en preuves de propriétés Résultats en preuves de propriétés

Fonction atterrisseur 17 propriétés ~ 1014 états accessibles (beaucoup de temporisations) ~ 4 jours de temps CPU (Sparc 20 192 Meg de RAM)

Calculateur Test Maintenance SCV 3 propriétés de sûreté ~ 106 états accessibles (ordonnanceur de tâches) ~ 10 heures de temps CPU

Fonction mise en œuvre cabine

5 propriétés ~ 108 états accessibles


Retour sur l’évaluation de Retour sur l’évaluation de SCADESCADE

Expérimentation de l’éditeur en 99 documentation de soutien logiciels de calculateurs systèmes avions essai du générateur de code / simulateur en 2000

Etude des aspects certification du générateur lustre2C en collaboration avec Verilog (98-99 contrat R&D Genie)

Evaluation pour les applicatifs SCV prévue en 2000

Trop tôt pour conclure mais,... Accueil favorable et engagement progressif approche multi-formalisme


Retour sur les outils pour l’algorithmique (1/2)Retour sur les outils pour l’algorithmique (1/2)

« Impossibilité » de la génération automatique de code et de la preuve automatique

Evaluations privilégiant le pouvoir d’expression et la solidité scientifique

Langage Objective Caml de l’INRIA outil de développement puissant pour des prototypes sérieux pas chers mais utilisation de Java dans les autres cas ...

Prouveur Coq de l’INRIA évaluation de 92 à 99: algorithmes BDD, trajectoires, lustre2C une référence, mais ....


Retour sur les outils pour l’algorithmique (2/2)Retour sur les outils pour l’algorithmique (2/2)

Evaluation de la boîte à outils VDM++ de l’IFAD des fonctions intéressantes (assertions riches, couverture de test) des difficultés (efficacité, environnement, sémantique objet)

Pas de solution « descendante » en vue s ’intègrent mal dans les processus actuels

Recherche d’une solution « ascendante » pour les logiciels critiques

C enrichi d’annotations logiques en fonction du besoin Analyseurs statiques automatiques ou interactifs pour les preuves


PlanPlanPlanPlan

Contexte industriel

Démarche

Résultats

Satisfactions

Déceptions

« Conclusion »


Satisfactions scientifiques et techniquesSatisfactions scientifiques et techniques

Maîtrise de la causalité et de l’explosion combinatoire dans la chaîne de développement Esterel

G. Berry, O. Coudert, J.C. Madre, H. Touati

Preuve d’algorithmes complexes en Coq

Développement d’une extension objet-UML d’Esterel E. Nassor, Y. Le Biannic

Développement d’une syntaxe graphique StateCharts pour Esterel

Quelques pistes pour l’asynchrone distribué


Autres satisfactions ...Autres satisfactions ...

En avoir convaincu d’autres ... Base et Direction Technique Dassault Aviation Ilog, Simulog, Cadence, ...

10 ans de travail sur et avec des sujets intéressants ...

Avoir fait passer Esterel + Objets + StateCharts dans les programmes en 98-99

Un sujet qui a encore de l’avenir


Une spécification graphique exécutableUne spécification graphique exécutable



Génération d’un code Génération d’un code conformeconforme

/* scc : C CODE OF EQUATIONS MAIN - SIMULATION MODE */

/* AUXILIARY DECLARATIONS */

#ifndef STRLEN#define STRLEN 81#endif#define _COND(A,B,C) ((A)?(B):(C))#ifdef TRACE_ACTION#include <stdio.h>#endif#ifndef NULL#define NULL ((char*)0)#endif

#ifndef __EXEC_STATUS_H_LOADED#define __EXEC_STATUS_H_LOADED

__SourcePoint source_point;};struct __VariableEntry {char *full_name;char *short_name;char *type_name;int type_code;int comment_kind;int is_initialized;char *p_variable;char *source_name;int written;unsigned char written_in_transition;unsigned char read_in_transition;static struct __SourcePoint __MAIN_SPSPA_0[] = {{1,9,4,0},{1,9,4,0},{1,11,4,0},{1,11,4,0}};static struct __SourcePoint __MAIN_SESPA_1[] = {{1,20,4,0}};static struct __SourcePoint __MAIN_SESPA_2[] = {{1,12,4,0}};static struct __SourcePoint __MAIN_SPSPA_2[] = {{1,17,4,0},{1,17,4,0},

Code cible

Compilation


Utilisé pour les nouvelles Utilisé pour les nouvelles fonctions du Mirage 2000-9fonctions du Mirage 2000-9

et du standard F2 du Rafaleet du standard F2 du Rafale


PlanPlanPlanPlan

Contexte industriel

Démarche

Résultats

Satisfactions

Déceptions

« Conclusion »


DéceptionsDéceptions

Très peu d’outils vraiment fiables et passant « à l’échelle »

Des classes de traitements qui résistent à la preuve l’automatique continu les composants COTS (OS, compilateurs,...) les grands systèmes asynchrones distribués

Une grande ambivalence dans la relation recherche-industrie


Autres déceptions ....Autres déceptions ....

Quel marché pour Simulog, Steria, Verilog, ...?

Humain, trop humain ... la technique est souvent peu de chose face aux questions de carrières, de

budgets, ou d’emploi la productivité se vend mieux que la sécurité

Primat de l’organisation industrielle sur le succès d’une technologie


Autres déceptions ....Autres déceptions ....

Si c’était à refaire, pourrions nous le refaire ? réduction des budgets de R&D départ en retraite des « bâtisseurs » pression pour un ROI court terme

Rôle moteur des autorités de tutelle ou de certification ?


PlanPlanPlanPlan

Contexte industriel

Démarche

Résultats

Satisfactions

Déceptions

« Conclusion »


En guise de conclusion (1/2)En guise de conclusion (1/2)

GIE et développement GPL « à la Linux » pour avoir des « outils MF » pérennes ?

Pas de transferts à pas cher syndrome « du stagiaire » il faut des compétences de développement coté industriel

pour répondre à des besoins non valorisables coté recherche

Choix technologiques orientés « processus » 99,9% d ’accord avec J. Rushby ’s FM99 talk


En guise de conclusion (2/2)En guise de conclusion (2/2)

Sujets de recherche génération de tests

(model checking et interprétation abstraite) vérification modulaire spécification formelle et preuve sur du C restreint

Collaborations avec des labos qui développent du code fini et

veulent vraiment résoudre des problèmes de taille réelle

Documents

Page : 1 Référence : DIG 95/ AFADL 2000 - Grenoble, 26-28 janvier 2000 Direction de la Prospective Regard sur 10 années dintroduction des méthodes formelles