1 / 37

Conception des logiciels critiques dans le domaine spatial

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.

gage
Download Presentation

Conception des logiciels critiques dans le domaine spatial

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. European Aeronautics Defence and Space companyLAUNCH VEHICLES

  5. 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

  6. 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%

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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 ?

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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.

  21. 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

  22. 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 ? +

  23. 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

  24. 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

  25. 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

  26. Properties description • Use of synchronous observer, specified • In SCADE • In LUSTRE • Using regular expression Environment oracle Environment Inputs Observed software Outputs Properties Properties oracle

  27. 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

  28. 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 )

  29. - 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

  30. 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

  31. Complex software (2): synchronous hypothesis (1) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n

  32. Complex software (2): synchronous hypothesis (2) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n

  33. Complex software (2): synchronous hypothesis (3) Algo period Cmd Measurement Bus frame Software Algo Algo Algo Cycle n-1 Cycle n+1 Cycle n

  34. 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

  35. 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

  36. 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 • ...

  37. 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

More Related