370 likes | 503 Views
Conception des logiciels critiques dans le domaine spatial. Du système au logiciel... Retour d’expérience sur les méthodes formelles David LESENS EADS LAUNCH VEHICLES , Route de Verneuil BP 2, F-78133 Les Mureaux Cedex – France Email : david.lesens@launchers.eads.net. Plan.
E N D
Conception des logiciels critiquesdans le domaine spatial Du système au logiciel... Retour d’expérience sur les méthodes formelles David LESENS EADS LAUNCH VEHICLES, Route de Verneuil BP 2, F-78133 Les Mureaux Cedex – France Email : david.lesens@launchers.eads.net
Plan • EADS LAUNCH VEHICLES • Qui nous sommes • Méthodologie de développement d’un système véhicule • Développement • Validation • Les méthodes formelles de spécification logicielle • Pourquoi • Comment • Retour d’expérience • L’Automatic Transfer Vehicle • Spécification du logiciel MSU • Bilan
EADS : Un acteur majeur de l’industrie aéronautique et de défense n° 3 mondial - n° 1 européen Thales Northrop CA 2000* : 24,2 Mds € Raytheon Prise de commandes 2000*: 49,3 Mds € Bae-Systéms * valeur pro forma EADS Lockheed-Martin Boeing 0 10 20 30 40 50 60
European Aeronautics Defence and Space companyLAUNCH VEHICLES
M4 / M5M51Maîtrise d’œuvre systèmes complets Systèmes stratégiques • Ariane 4Ariane 5 • ATV • Soyuz • Lanceurs complémentaires • ARD • ARES THEMIS Transport spatial • Equipements spatiaux • Produits satellites • Produits technologiques et divers Equipements Activités phares d’EADS LAUNCH VEHICLES
Chiffre d’affaires par activité CA 2000 : 1043,5 Millions € 50 Millions € Equipements 5% 295,8 Millions € Lanceurs stratégiques 28% Transport spatial civil 697,7 Millions € 67%
Plan • EADS LAUNCH VEHICLES • Qui nous sommes • Méthodologie de développement d’un système véhicule • Développement • Validation • Les méthodes formelles de spécification logicielle • Pourquoi • Comment • Retour d’expérience • L’Automatic Transfer Vehicle • Spécification du logiciel MSU • Bilan
Développement d’un logiciel spatial Gestion de mission Communication Thermique Puissance Spécification véhicule Panneaux solaires Propulsion Conception véhicule Spécification équipements Spécification logicielles Algorithmes navigation, guidage, control I/F I/F Développement Développement Développement Simulateur
Validation du logiciel Simulateur de l’environnement Simulateurs des équipements Equipements réels Logiciel réel Simulation d’un vol complet Le premier vol est un vol de qualification
Objectif de la spécification logicielle • Capturer le besoin système • Spécialistes métiers • Servir d’entrée à l’activité de développement • Cohérence • Complétude • Référence pour la validation fonctionnelle • Exigences validables
Plan • EADS LAUNCH VEHICLES • Qui nous sommes • Méthodologie de développement d’un système véhicule • Développement • Validation • Les méthodes formelles de spécification logicielle • Pourquoi • Comment • Retour d’expérience • L’Automatic Transfer Vehicle • Spécification du logiciel MSU • Bilan
Etudes Systèmes Reprise immédiate Diminution des corrections tardives Qualification Génération de tests Spécification « validable » Pourquoi utiliser des méthodes formelles ? Ecriture des spécifications en méthode formelle Validation Fonctionnelle Spécification Technique Conception Intégration Tests Unitaires Raffinement Développement
1er objectif des méthodes formelles de spécification • Augmenter la formalisation de notre spécification • Standard de communication • Pour des informaticiens • Pour des non informaticiens • Différents types d’application • Synchrone et/ou • Asynchrone et/ou • Algorithmique
2nd objectif des méthodes formelles de spécification • Détecter les erreurs en phase amont de développement • Validation de la spécification • Cohérence de la spécification • Complétude de la spécification • Preuve sur la spécification • Test • Prototypage rapide • Simulation de la spécification
3ième objectif des méthodes formelles de spécification • Faciliter le raffinement de la spécification vers une conception • Réutilisation des tests de simulation de la spécification • Ecriture d’une conception à l’aide d’une méthode formelle ? • Génération de code • Séquentiel ou multitâche • Langage cible • Embarquable ?
Et en pratique ? Soyons pragmatiques !Retour d’expérience • Les méthodes formelles sont lourdes à utiliser • Utiliser selon les besoins • Modélisation statique • Type SADT ou SART • Vérification de la cohérence des flots de données • Modélisation dynamique • Mieux comprendre un point dur • Simulation / validation • Spécification • Développement complet • Spécification véhicule ou code embarquable • Choix de la méthode En support d’une spécification ou d’une analyse
Quelles méthodes « formelles » choisir? Exemples d’applications Simulink James Système véhicule Etudes algorithmiques SDL, StateCharts Spécification logicielle Scade Signal Esterel Conception logicielle UML Codage Méthode B
Plan • EADS LAUNCH VEHICLES • Qui nous sommes • Méthodologie de développement d’un système véhicule • Développement • Validation • Les méthodes formelles de spécification logicielle • Pourquoi • Comment • Retour d’expérience • L’Automatic Transfer Vehicle • Spécification du logiciel MSU • Bilan
Retours d’expérience à EADS Launch Véhicles • Spécification système • Chaîne de sécurité ATV • Sol / Système de communication • Pool d’ordinateurs de bord / bus / liens filaires • Système de sécurité (MSU) et logiciel associé • Spécification logicielle • Architecture du GNC Ariane 5 • Cyclique / synchrone • Multi-fréquence, condition d ’activation • Séquentiel Ariane 5 • Asynchrone couplé au synchrone • Logiciel MSU • Sécurité ATV / ISS Etudes amont En SDL Etudes amont Rétro ingénierie en SCADE Etudes amont Rétro ingénierie en SDL Développement opérationnel en SCADE
The Automated Transfer Vehicle (ATV) context One of the European contributions to the International Space Station (ISS). It will supply from 2004 onward the following services to the ISS: • Refuelling, • ISS orbit correction, • Freight delivery, • ISS trash destruction.
FTCP Health status DPU 1 DPU 2 DPU 3 Safety Chain MSU 1 Reset MSU 2 ATV safety chain and Collision Avoidance maneuver Thrusters • Rendezvous • monitoring • Red button • 2 redundant chains • Coded in ADA • No ADA exception • Single task Sensors Responsible of ISS safety by triggering a CAM
Technical Specification of the MSU SW • State automaton • MSU SW architecture • CAM sequencer • Non functional requirements • Functional requirements SCADE modeling FrameMaker editor Algorithms Reference Documents GNC algorithms How the MSU software is specified ? +
Contains of the MSU SW SCADE model Synchronous and cycle architecture Hierarchical decomposition Activation condition CAM Control Post-CAM Navigation Monitoring Data flow description FBY 2 Data ageing
Executable specification • Spec validation • Code generation • Simulation Validation of a SCADE specification No ambiguous Easy to understand (graphic) Well accepted by the participants Formal semantics • Specification • Complete • Coherent • Implementable Semantics verifier Formal proof • Validation improprement • Exhaustiveness • Automatic
Formal proofs on the MSU SW TS Environment description Logical Property SCADE model LESAR tools True property Exhaustive verification Diagnostic LESAR tool is developed by the VERIMAG laboratory
Properties description • Use of synchronous observer, specified • In SCADE • In LUSTRE • Using regular expression Environment oracle Environment Inputs Observed software Outputs Properties Properties oracle
Proof by model checking • Construction of a mathematical model of the SCADE model • Computation of the reachable states • Comparison with the forbidden states Forbidden states Initial states SCADE model Mathematical model
on1 arm1 on2 arm2 Init S1 S2 S3 S4 Property examples • A CAM test can only be triggered by a “red button” signal • true_after_false( CAM_TEST_TRIG ) RED_BUTTON • No assertion is required from the environment to satisfy this property. • When the initialisation of the two MSU chains is correct, they can not triggered both a CAM at the same time • #( MSU1_CAM_TRIG , MSU2_CAM_TRIG ) • It is satisfied only when the initialisation of the 2 MSU is correct • cam_arm( SWITCH_ON_MSU1, ARM_MSU1, SWITCH_ON_MSU2, ARM_MSU2, RED_BUTTON )
- Description of a MSU cyclic and • synchronous architecture • - Formal semantics (no ambiguity, • no incoherence) • . Data flow / Activation condition • . Data obsolescence description • - MSU SW TS easy to understand • - Semantics verification / Formal proof Improve the quality of the TS of the MSU Software - Non adapted for asynchronous software - Limited to small, cyclic, synchronous software - Start of the MSU software design Not usable for a complex software Conclusion on formal method use for ATV
Complex software (1): level of description ? Asynchronous specification Synchronous specification GNC GNC Data update Algorithms Data update Algorithms ack cmd TC TM TC TM Communication system Communication system
Complex software (2): synchronous hypothesis (1) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n
Complex software (2): synchronous hypothesis (2) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n
Complex software (2): synchronous hypothesis (3) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n
Plan • EADS LAUNCH VEHICLES • Qui nous sommes • Méthodologie de développement d’un système véhicule • Développement • Validation • Les méthodes formelles de spécification logicielle • Pourquoi • Comment • Retour d’expérience • L’Automatic Transfer Vehicle • Spécification du logiciel MSU • Bilan
Conclusion: Comment utiliser les méthodes formelles • En rétro-ingénierie • Développement d’un modèle formel • A partir d’une spécification logicielle • Pour analyser un point particulier • Trois étapes en développement • Spécification • Quand débuter le développement ? Maturité du besoin • Précision de la description ? Positionnement dans le cycle • Validation de la spécification • Nouvelle activité à planifier et à financer • Raffinement vers du code • Evolution du cycle de développement
Prospectives (1) Amélioration des techniques utilisées • Des techniques de spécification • Mixer synchrone et asynchrone • Raffiner de l’asynchrone vers du synchrone • ... • Des techniques de preuve • Spécification des propriétés • Puissance des outils • ... • Des techniques de conception • Langages de compilation • Architectures multi-tâches • ...
Prospectives (2) Amélioration de la méthodologie • Etendre l’approche formelle au système véhicule • Utilisation par des non informaticiens • Raffinement • Rendre systématique l’approche formelle • Utilisation dans les futures projets • Systèmes critiques et moins critiques • Culture d’entreprise