Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial
description
Transcript of Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial
ETR’11 – Best le 29 août 2011 1
Problématique et retour d’expérience du
développement des Logiciels embarqués pour
le spatialPaul ARBERET
ETR’11 – Best le 29 août 2011 2
• 1- Introduction• 2- Description fonctionnelle• 3- Environnement calculateur• 4- Sûreté de fonctionnement• 5- Problématique de maintenance en vol• 6- Le(s) cycle(s) de développement des logiciels de vol• 7- Les phases de vie du logiciel : objectifs et moyens• 8- Difficultés• 9- Conclusion : perspectives
Plan de la présentation
ETR’11 – Best le 29 août 2011 3
1-Introduction : le CNES – Centre National d’Etudes Spatiales
Donneur d’ordre du programme spatial français– Propose une politique, une stratégie et un programme
au gouvernement– Met en œuvre cette politique : recherche,
développement et opérations
Quatre établissements :- Siège à Paris- Direction des lanceurs d’Evry- Centre spatial de Toulouse- Centre spatial Guyanais
ETR’11 – Best le 29 août 2011 4
1-Introduction : le CNES – chiffres clés– Créé il y a 50 ans en 1961– 1740 M€ de budget annuel (dont environ la moitié de
subvention à l’ESA)– 2418 salariés– Répartition homme / femme : 65% / 35%
ETR’11 – Best le 29 août 2011 5
1-Introduction : les missions spatiales
européennes• Les lanceurs et véhicules de transport spatial :
Ariane, ATV
ETR’11 – Best le 29 août 2011 6
1-Introduction : les missions spatiales
européennes• Les systèmes orbitaux et les sondes :
– Observation de la terre (SPOT), environnement (JASON) et météo (METEOSAT), défense (HELIOS),
– Télécommunications, – Navigation (GALILEO), – Science (Herschel/Planck, COROT, etc…)– Exploration lointaine (Rosetta, Mars express)
ETR’11 – Best le 29 août 2011 7
- orbite basse « observation de la terre / scientifique » SPOT-Pléiades - Jason : nombre de passages réduit (10mn/100mn) - bande passante faible (quelques centaines de kbits/s)
- géostationnaire « télécommunication » Telecom1 - Stentor - E3000 : continuité du service (satellites télécom) -> réactivité aux pannes
- sonde interplanétaire « astrophysique / scientifique » - Rosetta/Mars Express : autonomie vis à vis des pannes - très faible bande passante - interruptions TM/TC - capacité de reprogrammation.
- lanceur - Ariane : aucune commandabilité sol hormis la sauvegarde
1- Introduction : les orbites et leurs contraintes
LV
ETR’11 – Best le 29 août 2011 8
1-Introduction : principales caractéristiques des logiciels
embarqués• De 1 à 30 logiciels embarqués par satellite• Complexité et fonctionnalités –très- variables en
fonction de la mission et des contraintes du système spatial
• Majoritairement modifiables en vol• 20.000 à 200.000 lignes de code C, ADA, ou
Assembleur (émergence de JAVA)• Durée de développement : 6 mois à 5 ans• Durée de vie du système : quelques minutes
(lanceurs) , de 1 à 15-20 ans (satellites ou les sondes)
ETR’11 – Best le 29 août 2011 9
1-Introduction : au cœur du système Bord/Sol
Le Logiciel de Vol « LV » = à l ’interface entre le sol et le satellite, assure les fonctions embarquées « intelligentes » vitales qui ne permettraient pas une réactivité suffisante si réalisées au sol.– niveau d ’autonomie requis par la mission,– capacité d ’évolution tardive y compris en
vol que ne permettent pas les composants matériels !
LV
Calculateur CU
Calculateur PF
Eq-1 Eq-2
Satellite
Calculateur Sol
Centre de Contrôle
ETR’11 – Best le 29 août 2011 10
1-Introduction : logiciel temps réel
Le Logiciel de Vol « LV » = des activités réalisées en temps « borné » par les exigences de la mission et les contraintes du système.– Temps réel dur : cycles de quelques µs à
quelques centaines de ms,– Temps réel mou : cycles d’une seconde à
quelques secondes.Déterminisme et prédictabilité
nécessaires.
LV
Calculateur CU
Calculateur PF
Eq-1 Eq-2
Satellite
Calculateur Sol
Centre de Contrôle
ETR’11 – Best le 29 août 2011 11
2- Description fonctionnelle
• Dialogue Bord/Sol « TM/TC » • Contrôle d ’attitude et d ’orbite (SCAO)• Contrôle thermique actif• Contrôle de l ’énergie• Séquence automatique / Contrôle de Vol• Programmation mission / charge utile• Gestion des anomalies et des reconfigurations (FDIR)
LV
Classification des fonctions embarquées: Gestion : modes – surveillances - FDIR Traitement: SCAO – contrôle thermique - énergie Communication: TM/TC – protocoles bord
ETR’11 – Best le 29 août 2011 12
2- Description fonctionnelle
Dialogue Bord/Sol + communication avec le matériel : gestion des protocoles• réception TC / émission TM : protocole sol/bord (CCSDS)• encodage/décodage/mémorisation et routage de/vers les sous-systèmes (CCSDS)• élaboration de tables de diagnostic (extrema de paramètres, divers historiques, dwell / acquisitions à la demande) • capacité de mémorisation et exécution différée TC
LV
fonction de « service » non algorithmique simple de manipulation de données / vérifications - configurée par la Base de Données Système (BDS) : complexité due aux interactions temps réel entre fonctions et niveaux de tâches.
ETR’11 – Best le 29 août 2011 13
2- Description fonctionnelle
Contrôle d ’attitude et d ’orbite (SCAO)• assure le pointage adéquat (modes de contrôle d ’attitude) : acquisition des informations senseurs - prédiction des actuations et envoi des commandes aux actuateurs• réalise les manœuvres (modes de contrôle d ’orbite) commandées par le sol
LV
fonction « applicative » algorithmique (calculs numériques cycliques plus ou moins complexes : filtres - manipulations et calculs matriciels - équations sur polynômes) .
ETR’11 – Best le 29 août 2011 14
2- Description fonctionnelle
Contrôle thermique actif• assure la stabilité thermique de la plateforme et des instruments : acquisition des températures - prédiction et envoi des commandes/consignes de réchauffage
LV
fonction « applicative » algorithmique (calcul numérique de type proportionnel/intégral = filtre du 2ème ordre - vote sur plusieurs thermistances).
ETR’11 – Best le 29 août 2011 15
2- Description fonctionnelle
Contrôle de l ’énergie• gère la charge et la décharge des batteries en fonction du niveau d ’éclairement des panneaux solaires (passages en éclipse)• asservissement du moteur d ’entrainement des panneaux solaires pour garantir un éclairement maximal (orbite basse) ou utilisation pour pilotage attitude satellite (géostationnaire)
LVfonction « applicative » - algorithmie simple
ETR’11 – Best le 29 août 2011 16
2- Description fonctionnelle
Séquence automatique / Contrôle de Vol (CDV)• cadence l ’envoi des ordres pyrotechniques / AMF durant la mise à poste satellite (déploiement des antennes, panneaux solaires, déblocage des mécanismes)• séquence l ’ensemble des mises en œuvre matérielles lanceur
LV
fonction « applicative » cyclique = séquenceur d ’ordres interprétés (commandes - délais - vérifications - logique simple) capacité de reprogrammation simple en fonction des missions (ex : CDV Ariane V ou Séquence Automatique SL)
ETR’11 – Best le 29 août 2011 17
2- Description fonctionnelleProgrammation mission / charge utile• gère les mises en œuvre des différents composants de la charge utile sur ordre de programmation du sol (plan de travail)• Traite données mission
LV
fonction « applicative » supportée par un interpréteur de séquences élémentaires (commandes bas niveau - délais - vérifications) capacité de mémorisation du plan de travail (chargé par TC) et d ’exécution différée en continu sur l ’orbite (satellites orbite basse)capacité / souplesse de reprogrammation tardive dans le développement, ou en vol - meilleure indépendance du LV vis à vis de la mission (ex : IASI - SPOT5 / HELIOS 2 - Stentor)Traitement numérique + ou – complexe sur les données mission
ETR’11 – Best le 29 août 2011 18
2- Description fonctionnelleGestion des modes• gère les ressources et l ’état des ressources depuis le niveau matériel jusqu’au niveau des fonctions et du satellite
LV
Satellite SCAO CUSurvie Survie CSU
Lancement
MRVMAGMAF1MAF2
CLTCSU
Nominal
MPFMCCMCO
COPCVF
fonction « de service » simple qui mémorise les états des ressources, et des fonctions et du satellite. = Chef d ’orchestre en charge de cadencer les activités LV
Modes LVC SPOT5 :
ETR’11 – Best le 29 août 2011 19
2- Description fonctionnelleIsolation et passivation des pannes• surveille les paramètres sous-systèmes et systèmes dans des intervalles de valeurs attendues
• consommation électrique : tensions, courants,• thermique : températures,• protocoles : checksum, parités,• aberrations algorithmiques /dysfonctionnements : erreurs matérielles et logicielles
• reconfigure le(s) sous-système(s) défaillant(s)• mise en œuvre du sous-système redondant et mise hors service du sous-système en panne• repliement vers un mode sain -> Survie
LV
fonction de « service » paramétrée par la BDS capacité de reprogrammation tardive y compris en vol - complexité système (combinatoire des pannes et logique de déclenchement)
ETR’11 – Best le 29 août 2011 20
2- Description fonctionnelleReprogrammation/Support diagnostic en vol• gestion de l ’implantation mémoire et des versions logicielles (ex : Myriade - Pharao) • patch/dump : rechargement de tout ou partie du LV (ex : Hipparcos - ERS2 - SPOT1)• fonctions programmables à la demande (chargement de parties « libres » du logiciel ou de ses données)• reprogrammation simple des séquences interprêtées (ex : IASI - Stentor/E3000 - Rosetta - PHARAO)• suppression des fonctions inutiles (ex : suppression séquence automatique après le succès de la mise à poste - HELIOS1A)
LV
peu de code spécifique mais des règles de conception et codage permettent d ’assurer ces mises en œuvre en vol
ETR’11 – Best le 29 août 2011 21
Limitation des ressourcesmasse, consommation
Environnement spatialradiations, températures
3- Environnement : la problématique calculateur
Besoin de programmation efficaceEnvironnement de développement limitéSystème de développement spécifique
machine hôte/carte ciblecompilateur croisé
Processeurs
spécifiques
LV
ETR’11 – Best le 29 août 2011 22
Processeur Perf o TR Taille MemSPOT4 F9450 0,7 MI PS 256 KoSPOT5 MA3-1750 1 MI PS 512 KoPléiades ERC32 13 MI PS 6 MoPROTEUS MA3-1750 1 MI PS 512 KoMYRI ADE T805 4 MI PS 2 Mo
3-Environnement : Les Performances calculateur
LV Plateformes d ’observation et scientifiques
ETR’11 – Best le 29 août 2011 23
Processeur Perf o TR Taille MemE3000/Stentor MA3-1750 1 MI PS 256 KALPHABUS ERC32 13 MI PS 4 MoAGORA MA3-1750 1 MI PS 1 Mo
3- Environnement : Les Performances calculateurLV Plateformes télécom
LV lanceurProcesseur Perf o TR Taille Mem
Ariane V 68020 +68082
1,2 MI PS222 Kflops
1 Mo
ETR’11 – Best le 29 août 2011 24
Processeur Perf o TR Taille MemI ASI – IMSS MA3-1750 1 MI PS 1 MoI ASI - DPS ADSP 21020 15 MI PS /
45 MflopsPM = 768 KoDM = 1Mo
SPI - Integral MA3-1750 1 MI PSPHARAO ERC32 10 MI PS 10 Mo
3- Environnement : Les Performances calculateurLV Instruments
ETR’11 – Best le 29 août 2011 25
Le LV est le seul sous-système non redondé à bord = point de panne unique
• Comme tout logiciel, il est difficile à valider exhaustivement (combinatoire exponentielle)
• C ’est sur le LV que repose la plupart des évolutions tardives avant tir avec tous les risques associés (validation de la non-régression)
• ...y compris en vol : problématique de maintenance des moyens et compétence
Exemples d ’anomalies « célèbres » :– ARIANE 501– Survie SPOT3
4- La Sûreté de fonctionnement
ETR’11 – Best le 29 août 2011 26
En réponse à l ’ensemble des problématiques et contraintes posées, le LV est un métier d ’austérité et de rigueur :
• Processus de développement et de validation strict (ECSS)• Standards applicables pour chaque phase de développement et de
validation : objectifs, moyens, règles, documents• Traçabilité de boût en boût :
– suivi des exigences dans tout le cycle (phase par phase)– suivi des évolutions : anomalies, améliorations (gestion de configuration)
• Adéquation et pérennité des compétences et moyens pendant toute la durée du développement et la vie du satellite
• Investissement conséquent recherche / solutions innovantes
4-Sûreté de fonctionnement : une démarche « avant tout » qualité
ETR’11 – Best le 29 août 2011 27
5-Problématique de la maintenance en vol
Besoins
LVCorrection d’anomalies logiciellesImplémentation de palliatifs des anomalies systèmes/matériellesAmélioration de la missionExpériences embarquéesPalliatifs en fin de vie
Performances réduites du lien bord/solObservabilité limitée du comportement du logicielRechargement des modifications logiciel à sécuriserPerturbations de la mission à minimiser (disponibilité)
ETR’11 – Best le 29 août 2011 28
• Cycle théorique « en V »• Cycles incrémentaux• Cycles en spirale
6- Cycle(s) de développement LV
ETR’11 – Best le 29 août 2011 29
Analyse besoins
Spécification
Architecture
Production
Validation
Qualification
Intégration
Activités avioniqueActivités logiciel
6- Cycle de développement théorique « en V »
URD
SRD
ADD
DDD UTR
ITR
SVTR
ETR’11 – Best le 29 août 2011 30
• Définition de plusieurs versions, « les incréments », du LV– par fonction : suivant des besoins des utilisateurs (ex : ordre
d ’intégration). – par niveau de validation suivant de la criticité des besoins planning.
• Chaque fonction élémentaire suit un cycle en V de développement.
Exemple SPOT5:– LV100 services généraux TM/TC : niveau fin TU (besoin intégration
calculateur HW/SW)– LV200 SCAO : fin essais fonctionnels SCAO (besoin essais avionique)– LV200 CU : fin essais fonctionnels CU (besoin intégration CU)– LV300 complet (besoin essais LV sur satellite)
6- Cycle(s) incrémentaux :
ETR’11 – Best le 29 août 2011 31
Analysis
Design
TranslationTesting
Next step preparation
Integrationtest Validation
TestingCoding
UnitTesting
IterativePrototypes
6- Exemple de processus en spirale
ETR’11 – Best le 29 août 2011 32
7.1 - Collecte des besoins7.2 - Spécification détaillée et l ’architecture LV7.3 - Production - Intégration : conception détaillée,
codage, TU, TI7.4 - Validation fonctionnelle7.5 - Qualification - Validation système
7.6 - La gestion des évolutions/non-régression7.7 - La maintenance en vol
7- Les phases de développement et de validation LV : objectifs et moyens
ETR’11 – Best le 29 août 2011 33
Analyse système globale => définir – La répartition bord/sol– L ’autonomie de la mission– La fiabilité/disponibilité : stratégie de surveillance et reconfiguration– Les constituants de l’architecture informatique matérielle et logicielle– La répartition matériel/logiciel– Les informations échangées bord/sol et bord/bord
Rôle, interfaces, performances de chaque élément du système URD + ICD
Démarrage des développements
7.1- Collecte et Analyse des besoins
ETR’11 – Best le 29 août 2011 34
7.2.1 - Spécification détaillée- Modélisation
7.2.2 - Architecture- Architecture statique- Architecture dynamique- Interpréteurs embarqués- Production des données BDS
7.2- Spécification détaillée et architecture LV
ETR’11 – Best le 29 août 2011 35
• Exprimer tout ce que doit faire le logiciel, mais sans sur-spécifier– Traduction informatique d ’exigences systèmes (SCAO, thermique, C&C)– Problématique de terminologie dûs aux différences de culture de chaque métier– Traçabilité des exigences vis à vis des spécifications de besoin
• Exprimer les exigences temporelles– Durée à respecter entre l ’acquisition d ’une mesure et l ’envoi d ’une commande– Retrait du contenu d ’une TC avant écrasement par la TC suivante– Datation d ’un événement (--> 1 ms)
• Vérifier la faisabilité et la testabilité de l ’ensemble de ces exigences
– Nécessité d ’exprimer dans un langage formalisé, éventuellement exécutable – Numérotation des exigences - matrice de testabilité
7.2.1- Spécifications
LV
ETR’11 – Best le 29 août 2011 36
• Modèles descriptifs – formaliser la représentation de spécifications, de conceptions
• Modèles exécutables (logiciels ou systèmes)- modèles de dimensionnement et de performances (SES/workbench, Opnet)- modèles comportementaux (UML, SDL)
vue précoce et exécutable du système - détection d ’erreurs, incomplétudes, incohérences - gain important en validation
analyses comparatives, évaluation de l’impact d ’une modification amélioration de la communication meilleure confiance dans le système
utilisation limitée pour l’instant pendant la phase de spécification LV
7.2.1-Spécifications : La modélisation
LV
ETR’11 – Best le 29 août 2011 37
7.2.1- Spécifications : Modélisation de performances
Pour un logiciel ou un système
ETR’11 – Best le 29 août 2011 38
Exemple de résultats
ETR’11 – Best le 29 août 2011 39
STATECHARTSLes diagrammes d’état servent à représenter les états qu’un objet traverse en réponse à des stimuli, ainsi que ses réponses ou actions. Une machine à états est rattachée à une classe ou à une méthode.
CLASS DIAGRAMLe diagramme de classes représente l’architecture objet logique du système, c’est à dire la structure statique du modèle.
SEQUENCE DIAGRAMCe diagramme sert à dérouler un scénario correspondant en général à un cas d’utilisation. Il met en évidence les interactions entre les éléments du système.
USE CASECe diagramme sert à modéliser les cas d’utilisation du système, c’est à dire les interactions entre des acteurs externes et les services identifiés. Exemple :
Utilisateur
Enregistreur numérique
Ecouter un message
Enregistrer un message
Effacer un message
Enregistreur numériqueUtilisateur Haut-parleurSystème
Jouer message
Jouer son
Afficher progression
Arrêter
Arrêter son
TEMPS
Controleur
Haut_parleurMicro
Interface_utilisateur
Jouer()Arreter()
ClavierAfficheurAttente
EnregistreJoue
Attente
EnregistreJoue
DemarrerEnregistrer
Stop
Fin
Les principaux diagrammes UML (1/2)
ETR’11 – Best le 29 août 2011 40
Les principaux diagrammes UML (2/2)
Diagramme de collaboration
(communication entre objets)
Diagramme de déploiement(organisation du
matériel)
ETR’11 – Best le 29 août 2011 41
Exemple de diagramme de séquenceSCA Charge UtileGestion
Bord
Alarme panne équipement
Alarme survie
TEMPS
Commande passage survie
Mode Normal Mode Normal
Mode Survie
Mode Survie
Reconf avec panne Désactiver Charge Utile
ETR’11 – Best le 29 août 2011 42
7.2.2- Architecture Statique : notion de
couches
SCAO - Contrôle thermique - CU
TM/TC - Surveillances / Reconfigurations - Gestion modes
Application
Services
OS +Drivers
Matériel
Le logiciel est structué en plusieurs couches, de la plus proche du matériel à la plus indépendante :
LV
ETR’11 – Best le 29 août 2011 43
Parent
OP1
OP2
OP3 Enfant_1
AVANTAGES :-Règles de structuration
- Principe d ’abstraction
- Encapsulation des données
- ModularitéMaintenabilité
• L ’architecture repose sur des objets (Méthode HOOD) qui offrent des services : OP1,OP2, OP3• Les objets (parents) sont décomposés en objets (fils) ...
7.2.2- Architecture statique : notion d ’objet
ETR’11 – Best le 29 août 2011 44
Logiciel Réactif : qui réagit aux stimulations de l ’environnement
son fonctionnement est lié au temps
- Le logiciel est organisé en tâches- La ressource processeur est partagée entre ces tâches
Comment ?
- séquenceur périodique: SPOT ( 3 tâches périodiques)
- exécutif préemptif : Pléiades - Proteus (>20 tâches périodiques et apériodiques)
7.2.2- Architecture dynamique
LV
ETR’11 – Best le 29 août 2011 45
avertir la CPU qu’un événement s’est produit
• Quand une interruption survient, le processeur déroute l’exécution à un programme dédié (handler d’interruption)
• A fin du handleur d’interruption, le contrôle est rendu au programme interrompu
• Des priorités sont attribuées aux différentes IT
Sources d’interruptions : timers (ex : horloge), entrées/sorties asynchrones, matériels, …
7.2.2- Architecture dynamique : les interruptions
IT niveau 0IT niveau 2IT niveau 5
ETR’11 – Best le 29 août 2011 46
IT 64 Hz
IT 1 Hz
Tâche 32 Hz
Tâche 8 Hz
Tâche 1 Hz
7.2.2- Architecture dynamique Séquenceur Périodique (exemple SPOT)
LV
ETR’11 – Best le 29 août 2011 47
• Exécutif = Logiciel de gestion de l ’attribution du processeur aux tâches et gestion des ressources. Exemples : ( ASTRES, OSTRALES, VxWorks, RTEMS…)
– Fonctionalités de gestion des tâches • Encapsulation des handlers d’interruptions associés aux évènements
externes• Ordonnancement des tâches en fonction des priorités définies et du
schéma d’ordonnancement (pre-emptif, time-slicing…)
– Fonctionalités de gestion des ressources• Gestion mémoire (zones privées et publiques)
• Messages and sémaphores (communication entre tâches)
LV
7.2.2- Architecture dynamique : Exécutif temps réel
ETR’11 – Best le 29 août 2011 48
- A chaque tâche est affectée une priorité- A tout instant, la tâche qui s ’exécute est la tâche prête de plus haute priorité(la tâche en cours peut être pré-emptée …)
Exécutif temps réel : les états des tâches
En attenteressource, évt
En cours
Prête Différéedélai
ETR’11 – Best le 29 août 2011 49
Les tâches peuvent être :Périodiques : périodes et phases multiples de l ’horloge Apériodiques : déclenchées par la présence d ’un événement
Exemple : Périodique : traitements répétitifs, surveillances +Apériodique : communications, événements, exceptions
La vérification de la possibilité « d ’ordonnancer » toutes les tâches :
- a priori : par calcul- a posteriori : par observation
Exécutif temps réel : les types de tâches
ETR’11 – Best le 29 août 2011 50
Besoin = évolutivité/souplesse de reprogrammation par TC au sol et/ou en vol sans recours au patch/rechargement LV– langage dédié aux spécificités de la fonction à réaliser :
• acquisition de données• envoi de commandes• traitement / logique simples• délais
– modifications réalisées en AIT ou en vol par des non-spécialistes LV. Validation plus légère que des évolutions LV classiques
7.2.2- Architecture : Interpréteurs embarqués
LV
Exemples : • séquences automatiques satellite SPOT4 - SPOT5• contrôle de vol lanceur Ariane, mise en œuvre instruments IASI et PHARAO, • mise en œuvre Charge Utile SPOT5
ETR’11 – Best le 29 août 2011 51
La Base de Données Système (BDS) décrit :– Ensemble des paramètres système : valeurs– Formats TC et TM : agencement des paramètres, codage– Surveillances bord : seuils, filtres, valeurs attendues– Les programmes interprétés
7.2.2- Architecture : Production des données BDS
LV
Ces données sont produites automatiquement -génération de code- dans le LV au moyen d ’un outil appelé Programme de Production (PP) :• des données et structures de données (déclaration des types et
des variables associées), pour les surveillances, les paramètres TM/TC, les formats TM/TC, les paramètres système.
• initialisation des valeurs (par assignation), dont les paramètres système et les programmes interprétés (table de valeurs)...
ETR’11 – Best le 29 août 2011 52
• Chaque service offert par l’objet est décrit en détail• Codage (Ada ou C - assembleur si nécessaire) en
conformité avec les standards• Utilisation de compilateurs croisés/natifs • Exécutable produit à partir de :
– Code source, données logiciel et données communes (BDS)
7.3 - La phase de production et d ’intégration
ParentOP1
OP2
OP3
Enfant_1
Conception détaillée, codage
ETR’11 – Best le 29 août 2011 53
• Chaque service ou « module » du logiciel est testé indépendamment
• Objectif = couverture 100% code, branches, décisions (en fonction du niveau de criticité)
7.3 - La phase de production et d ’intégration
ParentOP1
OP2
OP3
Enfant_1
Tests unitaires
• Le module sous test est activé par un module de test (driver)• Les modules appelés par le module sous test sont simulés par
des modules de test (stubs)• Les tests sont joués en natif dans l ’environnement de
développement ou en croisé sur la machine cible• Le traitement des traces d ’exécution permet de déterminer la
couverture atteinte
ETR’11 – Best le 29 août 2011 54
• Intégration « bottom-up » des modules depuis les couches basses (interfaces matérielles) jusqu ’aux couches applicatives
• Objectif = couverture 100% des interfaces (en fonction du niveau de criticité)
7.3 - La phase de production et d ’intégration
ParentOP1
OP2
OP3
Enfant_1
Tests d ’intégration
• Le module sous test est activé par un module de test (driver)• Les modules appelés par le module sous test sont les
modules réels• Les tests sont joués en natif dans l ’environnement de
développement ou en croisé sur la machine cible• Une combinatoire finie -non exhaustive- des valeurs
numériques est choisie (min, max, médiane)
ETR’11 – Best le 29 août 2011 55
Outil de miseau point
Carte processeur
Station dedéveloppement
Noyau
Applicatif
Liaison série
Liaison Ethernet
TTY
7.3 - La phase de production et d ’intégrationMoyens de test TU/TI
LV
ETR’11 – Best le 29 août 2011 56
• Validation par fonction : essais « boîte noire »– Comportement fonctionnel et
algorithmique pur– Vérification de toutes les
exigences « unitaires » de la SRDSimulateur natif ou hybride
Validation fonctionnelle globale :– Comportement nominal– Comportement en
présence d’erreurs– Essais aux limites– Vérification des exigences
de couplage entre fonctions SRD
Simulateur natif ou hybride
• Validation HW/SW– Performances TR + numériques– Vérification de toutes les exigences
des ICD– Interfaces calculateur– Gestion mémoireSimulateur hybride - sonde temps réel
7.4- La validation fonctionnelle
ETR’11 – Best le 29 août 2011 57
Target Computer
RS 232 Ethernet network
LICE PC
Host Computer (SUN Workstation)
LICE Probe
CPU BoardChild board
L’outil LICE : sonde temps réel• Spécifiée par le CNES
• Le logiciel est instrumenté
• Ecriture d’un entier à une adresse de sortie correspondant à la sonde LICE
• Collectés et datés par LICE et envoyés vers le PC pour postraitement (chronogrammes, performances)
ETR’11 – Best le 29 août 2011 58
La visualisation dynamique
ETR’11 – Best le 29 août 2011 59
• Validation chaîne fonctionnelle– Adéquation des besoins LV aux
matériel réel « sur la table »– Vérification de toutes les
exigences de niveau URDBanc avionique - banc système
• Validation système QT/QO– adéquation des besoins LV et
du satellite aux opérations– Couplage bord/solBanc système + satellite• Validation LV sur Satellite
– Adéquation des besoins LV aux spécifications satellite et au matériel de vol
– Opérabilité/commandabilité des scénarios proches du vol
Satellite
7.5- La validation système « qualification »
ETR’11 – Best le 29 août 2011 60
De nombreuses évolutions - plusieurs centaines- (corrections d ’anomalies, évolutions fonctionnelles : interfaces, besoins mission) à gérer tout au long du cycle de développement et hors développement.– Les évolutions sont groupées en lot de modification donnant lieu à
production d ’une nouvelle version logicielle (si évolutions postérieures à la production)
– Gestion des impacts des évolutions exigence par exigence grâce à la traçabilité : SRD, ADD, DDD, code
– Rejeu des essais strictement nécessaires impactés par l ’évolution toujours grâce à la traçabilité (TU, TI, TF, …)
– Définition d ’essais fonctionnels de « non-régression » ou de bonne santé = couverture des effets de bord sur les parties non modifiées du LV.
7.6- Gestion des évolutions / non-régressions LV
ETR’11 – Best le 29 août 2011 61
Support LV aux équipes opérationnelles : – Investigations anomalies– Evolutions : corrections anomalies ou évolutions fonctionnelles
• Définition et mise en œuvre des évolutions nécessaires (voir §7.6)• Vérification au sol de la procédure de chargement de la nouvelle version ou du
patch (sur banc système)• Chargement effectif et vérification du comportement nominal
– Cycle MIM (Maintien Image Mémoire) périodique (exemple SPOT = 6 mois)• Produire une version logicielle reflétant les évolutions réalisées sur une période
donnée : patchs, chargement de paramètres, … : entrainement des équipes - maintien de la compétence
• Vérifier le bon fonctionnement de tous les moyens : atelier de développement, moyens d ’essais : anticiper et gérer les obsolescences si nécessaire
• Vérifier la capacité opérationnelle à recharger le LV et revenir en mode routine : entrainement des équipes - maintien de la compétence
7.7- La maintenance en vol LV
ETR’11 – Best le 29 août 2011 62
8- Difficultés (1/3)
LV• Difficulté de planning : développement coincé entre - le besoin d’un niveau de spécification suffisant
développement parallèle des sous-systèmes et du logiciel- des livraisons urgentes pour intégrations- des évolutions fréquentes
• Augmentation très significative du volume et de la complexité du logiciel
- augmentation des attentes- autonomie : de plus en plus de fonctions à bord
• Différence de culture entre le système, les sous-systèmes et le LV- efforts de communication- documents d’interface
LVBesoins AITSpécifications
temps
ETR’11 – Best le 29 août 2011 63
• Difficulté d’exprimer exactement ce qu’il faut faire– Les spéc amont sont ambitieuses et ne prennent pas suffisamment en
compte l’impact de certains choix sur le LV=> complexité pas toujours nécessaire du logiciel
– Les spécifications amont sont parfois incomplètes, ambiguës– Le LV est par nature complet et non ambigu
=> ceux qui font le logiciel sont amenés à faire implicitement des choix système pas toujours judicieux
– Les spécifications amont évoluent pendant tout le développement du système
• Difficulté de Vérifier/Valider– disponibilité et représentativité des moyens de tests– non exhaustivité des tests– validation des données de la BDS– complexité de mise en œuvre du système complet (pas d’ essais en vol)
8- Difficultés (2/3)
ETR’11 – Best le 29 août 2011 64
• On attribue parfois au logiciel des problèmes qui ne sont pas de son fait– le logiciel respecte sa spécification mais elle ne correspond pas
ou plus au vrai besoin– les vrais bugs logiciels sont découverts en général avant la
recette en vol, sauf exceptions... – les évolutions du logiciel après le tir sont majoritairement dues
• à des problèmes externes au LV mais qu’il est le seul à pouvoir résoudre (mode gyroless ERS)
• à des évolutions de la mission (supermode SPOT 1)
• La souplesse du LV est un avantage incontestable mais il ne faut pas en sous-estimer le coût et les risques– le logiciel est toujours considéré comme
• techniquement faisable, dans des délais courts et à faible coût• facilement modifiable par la suite
8- Difficultés (3/3)
ETR’11 – Best le 29 août 2011 65
• Augmentation autonomie/intelligence embarquée : stratégie de développement/validation de logiciels de plus en plus complexes (cohabitation temps réel dur / mou)
9- Conclusion : perspectives LV
• Evolutions calculateurs (obsolescence composants) -> utilisation COTS /systèmes multi-processeurs / cache : problématique de tolérance aux fautes, perte déterminisme exécution - stratégie de validation à définir
• Amélioration processus de capture des besoins : démarche co-ingénierie système-logiciel, déploiement méthodes formelles et modélisation amont
• Architectures génériques réutilisables indépendantes du matériel : développement composants – Time and Space Partitionning
• Standardisation des protocoles et méthodes = normalisation (MP, ECSS) -> synergie avec ESA et les industriels
• Amélioration de l ’efficacité des phases de validation : automatisation des tests - meilleure adéquation des moyens
ETR’11 – Best le 29 août 2011 66
Exemples de projets
ETR’11 – Best le 29 août 2011 67
Les logiciels de vol centraux SPOT
• Lancement– Mars 98
• Logiciel applicatif – ASTRIUM
• Processeur– F9450
• Langage– assembleur
• Taille code– 31 kmots (16 bits)
• Taille données– 32 kmots (16 bits)
• Lancement– Mai 2002
• Logiciel applicatif – ASTRIUM
• Processeur– MA3 1750
• Langage– Ada 83 + assembleur
• Taille code– 64 kmots (16 bits)
• Taille données– 160 kmots (16 bits)
SPOT5SPOT4 Observation de la terre
ETR’11 – Best le 29 août 2011 68
PROTEUS
• Lancement – 7 décembre 2001
• Logiciel applicatif P/F– Alcatel
• Calculateur et couches basses– SAAB Ericsson Space
• Processeur– MA3 1750
• Langage– Ada 83 + assembleur
• Conception– HOOD
• O.S. – Ostrales
• Nombre de lignes– 25000
• Taille code– 100 kmots
• Taille données– 100 kmots
PlateForme réutilisable pour l’observation scientifique de la terre, des étoiles, de la couverture nuageuse, …
ETR’11 – Best le 29 août 2011 69
Jason1, 7 déc 2001, AltimétrieCoopération NASA JPL
Calipso, début 2005, LidarCoopération NASA LaRC
Corot, début 2006, AstronomieCoopération européenne
PROTEUS : les missions (1/2)
ETR’11 – Best le 29 août 2011 70
SMOS, Radiomètre bande LCoopération ESA
Megha-Tropiques, Cycle de l ’eauCoopération ISRO (Inde)
Jason2
PROTEUS : les missions (2/2)
ETR’11 – Best le 29 août 2011 71
• Plate-forme ESA (XMM)
• Charge Utile : 4 instruments :
– SPI : SPectromètre Integral– IBIS : Imager on Board Integral– JEM-X : Joint European X-ray
Monitor– OMC : Optical Monitoring Camera
INTErnational Gamma Ray Astrophysics LaboratoryINTEGRAL
ETR’11 – Best le 29 août 2011 72
• Maîtrise d’œuvre interne de l’instrument principal (SPI)
INTEGRAL : schéma d’ensemble
Calculateur P/F
DigitalProcessi
ng Equipme
nt
Photons et rayons gamma
Equipements de collecte des
données
SOL
TM TC
Calculateur DPE
ETR’11 – Best le 29 août 2011 73
• Responsable du logiciel de vol du calculateur DPE• Définition du besoin• Spécification logicielle• Développement logiciel (DIAF-Transiciel)• Intégration/tests sur les modèles (CNES) :
=> conduite des essais sur simulateur
=> participation aux essais sur matériel réel
• Forte implication dans les choix système Gestion Bord• Supports ponctuels
• Expertise SW/HW pendant l’appel d’offres• Expertise compression • Utilisation des moyens de laboratoire SEA/IL pendant
la phase B• Modélisations • Participation à des revues
Logiciel SPI : activités du CNES
ETR’11 – Best le 29 août 2011 74
Logiciel du DPE
• Logiciel applicatif – DIAF/Transiciel et 3IP/CS
• Calculateur – CRISA
• Couches basses– GMV
• Processeur– MA3 1750
• Conception– HOOD
• Langage– Ada 83 + assembleur
• O.S. – Astres 1750
• Nombre de lignes– 38000
ETR’11 – Best le 29 août 2011 75
Matériel (CRISA)
Log. base (GMV)
Log. applicatif CNES (SEA/IL)DIAF/Transiciel
}{
Com
mun
s aux
4 in
stru
men
ts
Conduite de tests (EGSE)
CESR
Mire
CESR
Berkeley
DSS & MPE (Allemagne)
CEA
ESA
Inté
grat
ion
Sate
llite
(A
leni
a)
Mission OperationCentre (ESOC)
Integral ScienceData Centre
SPI : interfaces
Calculateur DPE
ETR’11 – Best le 29 août 2011 76
Cons
ultat
ion
LV (f
ev)
RDP
SPI (
dec)
RCS
(sept
)
Répo
nse A
ppel
d'Offr
e (oc
t)
Appe
l d'O
ffre (
juin
)
Livr
aison
log.
App
licati
f (ju
ill)
PDR
(jan)
Livr
aison
SEM
(dec
)
SRR
(oct)
Kick
Off
(juil)
Rece
tte lo
g. ap
plica
tif (j
uill)
Livr
aison
EM
(avr
il)
Test
Fonc
tionn
el M
odèle
de v
ol (s
ept)
Livr
aison
Mod
èle d
e vol
(m
ai)
Tir (
octo
bre 2
002)
SPI : chronologie
1994 1995 1996 1997 2001200019991998 2002
ETR’11 – Best le 29 août 2011 77
SPI : la phase de maintenance du logiciel
• mai 2001 livraison de l’instrument complet • janvier 2002 mise à jour du LV • octobre 2002 lancement• février 2003 mise à jour LV : réglages, problèmes mineurs• septembre 2003 mise à jour LV: modification conséquente
suite au changement de format des données scientifiques• Téléchargé en novembre, recette en vol mi-nov