Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation?

Transcription

1 Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation? L I S EDF Electricité de France technicatome THOMSON-CSF Philippe Le Meur Aerospatiale Matra Airbus et LIS Page : 1

2 Plan de la présentation! Problématique générale! Problématique de la validation! Choix du mode d appropriation! Etapes de filtrage des COTS! Vérification du COTS au sein du système hôte! Conclusion Page : 2

3 Problématique générale! Objectif de l intégration de COTS : " Bénéficier d un composant logiciel récent et évolutif " A moindre coût " Opérationnel dans les meilleurs délais " Réutilisable potentiellement sur d autres systèmes spécifiques! Contraintes : problèmes de sûreté de fonctionnement " Fautes internes de conception du COTS " Influence des défaillances des éléments matériels et logiciels du système hôte Page : 3

4 Problématique de la validation! La stratégie de vérification d un COTS est fortement associée à la validation du système hôte car dépendante Des configurations opérationnelles choisies en fonction de l adéquation aux besoins De l importance de la couche de protection logicielle Des restrictions d utilisation! Certification séparée impossible aux vues des normes! La stratégie de validation du système incluant un COTS est influencée par Le domaine d application Le niveau de criticité Le choix du niveau d appropriation du COTS Page : 4

5 Mode boîte noire! Le COTS répond à un besoin exprimé, les interfaces sont spécifiées mais son contenu est inconnu (processus de développement, spécification, conception, code, tests)! Allègement de la vérification : focalisation sur les interfaces LOGICIEL SPECIFIQUE HOTE COUCHE DE PROTECTION COTS! Manque de visibilité des composants et du processus de développement (conception et test principalement) " Couverture fonctionnelle difficile à démontrer " Couverture structurelle impossible " Peu d éléments pour la certification Page : 5

6 Mode boîte blanche! Le COTS répond à un besoin exprimé, les interfaces sont spécifiées et son contenu devient la propriété de l intégrateur du logiciel spécifique hôte (processus de développement, spécification, conception, code et tests)! Utilisé si réel besoin de visibilité du contenu et du processus de développement! Le COTS devient alors partie intégrante du logiciel spécifique hôte avec : " Possibilité d adapter une stratégie de validation de même sévérité " Transfert d une partie du savoir-faire du fournisseur vers l intégrateur " Adaptation du COTS au strict besoin du logiciel spécifique! Inconvénient : plus de bénéfice des évolutions du COTS Page : 6

7 Mode boîte grise! Le COTS répond à un besoin exprimé, les interfaces sont spécifiées et son contenu est partiellement connu. Certaines données de développement (les tests du fournisseur par exemple) deviennent la propriété de l intégrateur du système hôte! Visibilité du code source et de certaines documentations techniques (spécifications), des tests du fournisseur,...! Meilleure appréhension du processus de développement (méthodologie, stratégie de vérification du COTS,...)! Plus d informations à fournir pour la certification du système hôte (historique en service, couverture structurelle,...)! Intégration partielle de la validation du fournisseur avec celle du système spécifique hôte Page : 7

8 Acquisition et vérification du COTS! Le processus d acquisition du COTS est coordonné avec son processus de vérification au sein du système hôte " Connaissance fonctionnelle du COTS " Affinage des choix architecturaux " Preuves pour certification " Orientation de la stratégie de vérification du système spécifique! Etapes nécessaires : 1) Présélection Filtrage 2) Etalonnage 3) Prototypage 4) Vérification du COTS au sein du système hôte Page : 8

9 Filtre 1 : la présélection! Objectif : Faire une première sélection parmi les candidats en vérifiant que chaque COTS en compétition répond correctement aux critères de sélection! Moyens : Documentations commerciales et techniques, audits chez les fournisseurs, check-list, expérience en service,...! Recommandations : " Bien analyser l adéquation de l offre COTS avec le cahier des charges du logiciel spécifique à développer " Choisir de préférence un COTS offrant des interfaces standardisées (normes POSIX par exemple) pour l organisation et la comparaison des jeux de tests appliqués sur les COTS " Choisir un fournisseur de COTS : Qui garantit le suivi du COTS en maintenance évolutive et corrective Qui souhaite mettre à disposition des informations requises suivant le mode d appropriation choisi Page : 9

10 Filtre 2 : Approche expérimentale par étalonnage! Objectifs : " Soumettre chaque COTS présélectionné à une approche expérimentale basée sur l exécution isolée du COTS hors du système spécifique hôte " S assurer de la conformité de la documentation préalablement étudiée " Poursuivre la vérification de l adéquation du COTS avec le besoin " Comparer le comportement fonctionnel et temporel des COTS retenus! Moyens : " Des jeux de tests (fournis par les fournisseurs, proposés par les normes, créés en interne, issus des benchmarks de sûreté de fonctionnement,...) " Des outils (cf. MAFALDA, Ballista)! Recommandations : " Se focaliser sur les fonctionnalités attendues " Ne pas se disperser vers des fonctions ou des configurations non utilisées " Mettre l accent sur la couverture fonctionnelle du COTS " Homogénéiser les étalonnages pour la comparaison Page : 10

11 Filtre 3 : Approche expérimentale par prototypage! Objectifs : " Finaliser le choix du COTS à retenir " Confirmer l intégration du COTS dans le prototype du système à développer " Minimiser les risques potentiels liés à son utilisation! Moyens : " Un prototype du système hôte " Des tests nominaux et de robustesse du prototype " Des listes des modes de défaillance (COTS et système hôte) " Des outils (cf MAFALDA et BALLISTA)! Recommandations : " S assurer de la compatibilité du COTS avec le système hôte (modes de défaillance, mécanismes de protection, interfaces) " Restreindre les configurations choisies afin de minimiser l effort de vérification " Ne pas hésiter à remettre en question l architecture logicielle hôte pour faciliter l intégration. Page : 11

12 Vérification du COTS au sein du système hôte! Objectif : Intégrer au sein de la stratégie de validation du système hôte des vérifications supplémentaires pour s assurer de la bonne interopérabilité du COTS avec les autres composants (spécifiques ou COTS)! Moyens : " Le COTS choisi dans sa ou ses configurations opérationnelles " Un système hôte avec les composants réels! Recommandations " Valider fonctionnellement et progressivement le logiciel spécifique complet avec le COTS dans sa ou ses configurations opérationnelles " Satisfaire les exigences de certification en s appuyant sur les preuves accumulées " Valider l implémentation de la couche de protection du logiciel spécifique hôte autour du COTS Page : 12

13 Conclusion! Il n existe pas une technique «panacée» mais un processus gradué de vérification basé surtout sur la maîtrise des interactions entre le COTS et le système hôte! L accentuation des exigences requises en matière de sûreté de fonctionnement doit tendre vers une définition plus précise des objectifs de certification! Pour les logiciels critiques " Passer du mode boîte blanche au mode boîte grise est envisageable " En mode boîte noire, il faut pratiquement démontrer que le COTS n a pas d influence en matière de sûreté de fonctionnement Page : 13