Processus de maîtrise du logiciel libre pour les systèmes embarqués

Présentation au sujet: "Processus de maîtrise du logiciel libre pour les systèmes embarqués"— Transcription de la présentation:

1 Processus de maîtrise du logiciel libre pour les systèmes embarqués
Club SEE « Systèmes informatiques de confiance » Atelier du 20 octobre 2005, ENST Paris Logiciels sur étagère (libres ou commerciaux) : Quelle confiance peut-on leur accorder ? Processus de maîtrise du logiciel libre pour les systèmes embarqués - EADS Astrium Jean-Paul Blanquart Luc Planche Franck Ramon Alain Rossignol Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

2 Logiciel libre et systèmes spatiaux (embarqués)
Un certain nombre de caractéristiques, plus ou moins avantageuses: Par rapport à: Développement spécifique Développement antérieur Composant commercial Telles que: Coûts, délais Particularités contractuelles Standard, ouverture … et la sûreté de fonctionnement? Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

3 La confiance dans le logiciel spatial
Logiciel spécifique Spécifications correctes Spécifications satisfaites Validation/Vérification Intermédiaires Finale Tests fonctionnels Tests structurels Caractérisation produit Métriques Caractérisation processus COTS Spécification? Possible? Sens? Complétude? ?? Oui, mais… Hmmm… Logiciel libre Spécification? Un peu mieux Pareil Plutôt mieux, quoique… Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

4 Les bases de la démarche
Une nécessité: la maîtrise technique du produit Nécessaire en support au choix du produit Nécessaire pour les activités techniques d’intégration Nécessaire pour acquérir et transmettre la confiance Comment l’acquérir En cohérence avec les pratiques et standards En cohérence avec les objectifs de ces pratiques et standards Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

5 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Une double démarche Expérience pratique Incorporation de logiciel libre: Exécutif temps réel (RTEMS) Bibliothèque de fonctions mathématiques et services de base (Newlib C) En réponse aux besoins réels d’un projet réel, Pléiades (CNES) Généralisation et formalisation sous forme d’un processus Définition et validation du processus Étude pour l’ESA (ESTEC, contrat SPASC n°16811/02/NL/SFe) Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

6 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
RTEMS Real Time Executive Multiprocessor System ( distribué par On-line Applications Research (OAR) Un noyau temps réel, et un ensemble d’options Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

7 Processus pour le logiciel libre
Autres processus Composants élémentaires de l’approche Méthodes et techniques en support Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

8 Sélection de logiciel libre
Approche en 3 étapes Identification de candidats Analyse préliminaire, à base d’analyse de risques Comparaison entre solutions Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

9 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Sélection: sorties Documentation préliminaire des solutions Description, caractéristiques, avantages, inconvénients Analyse de risques, identification d’actions Documentation détaillée de la solution retenue Description détaillée, analyse de risques détaillée Dossier justificatif Plans d’intégration, de validation Actions Processus de suivi Solutions de secours (y compris au « niveau global ») Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

10 Support: Checklist (ou trame de document)
Status of the product OS-10 Are the property and confidentiality rules compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-20 Are the installation, utilization and training constraints compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-30 Are the guarantee and maintenance (evolution, correction) conditions compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-40 Is the documentation status compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-50 Are the design and code status compatible with the project needs (e.g. for integration, configuration)? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-60 Are the memory and processing power budget and margins compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-70 Are the human machine interfaces compatible with the project needs and rules? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

11 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Checklist (2/3) Quality standards and requirements OS-80 Is the quality status compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? OS-90 Is the reliability status (e.g., as estimated from documentation, in-service history, fault list and management, version history) compatible with the project needs according to the criticality level? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Development environment and process OS-100 Are the process and environment needed to generate, integrate, use and maintain the product compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Functional and performance needs OS-110 Are the functional (services) and non-functional (temporal performances, dependability characteristics) of the product compatible with the project needs? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

12 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Checklist (3/3) Testing OS-120 Is the product compatible with the project needs in terms of testing strategy (e.g., is there a test suite, is it complete, reusable, maintainable)? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Process OS-130 Is the product compatible with the project needs in terms of process: life-cycle, traceability, configuration management, production? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Skills OS-140 Is the product compatible with the available skills and experience of the project team? Are potential risks analysed, assessed and appropriate actions defined and evaluated? Summary OS-150 Have the identified actions been consolidated, evaluated, judged acceptable and properly incorporated in the project plans and the action follow-up procedure established? OS-160 Have the overall benefits and acceptability of the candidate product been assessed? Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

13 Intégration de logiciel libre
Liaison avec l’intégration système – logiciel Focalisation sur les interfaces et l’adaptation des autres composants Identification de composants additionnels Techniques en support Empaquetage Partitionnement Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

14 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Qualification Qualification du composant, du système Étapes: Identification et analyse de ce qui est disponible Identification des manques et des moyens de les combler Mise en œuvre des moyens complémentaires Support: tests de robustesse, analyse statique, rétro-ingénierie, vérification à base de modèles, etc. Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

15 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Enseignements (2/N) Importance de la qualification De la confirmation A la compréhension… Liens entre les composants du processus Entrées et sorties bien sûr, mais aussi Méthodes communes en support Liens entre sélection et qualification Recouvrement… processus continu Liens entre intégration et qualification Choix (→ SELECTION) du « point d’équilibre » Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005

16 Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005
Recommandations (2/N) Mettre en place un « processus parent » géré par un pôle de compétence transverse aux projets Extension, organisation et mutualisation de la connaissance, et du retour d’expérience: Sur les produits Sur le processus Mieux exploiter les possibilités et la logique du logiciel libre Support Contribution au développement et à la validation de produits, méthodes, processus Utilisateur, acteur, initiateur, fournisseur Club SEE Systèmes informatiques de confiance, atelier du 20/10/2005