Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial Paul ARBERET ½ heure (BCB, DS) à une heure30 . Les présentations précédentes vous ont montré différentes architectures matérielles que l ’on peut trouver à bord des satellites. Nous allons maintenant nous intéresser aux logiciels qu ’on y trouve, et à ce qui fait que ces logiciels sont différents des logiciels que l ’on peut trouver au sol. Une petite précision : on parle de logiciel « embarqué » (en anglais « embedded SW) quand il s ’agit de logiciels intégré à un équipement, et sur lequel on a une visibilité limitée. C ’est notamment le cas des logiciels qu ’on trouve dans l ’automobile, l ’aéronautique, mais aussi dans les centrales nucléaires ou les métros automatiques. Ces logiciels présentent des commonalités avec les logiciels embarqués à bord des satellites. J ’essaierai, dans mon exposé, de mettre également en évidence ce qui différencie les différents logiciels « embarqués ». ETR’11 – Best le 29 août 2011 1

Plan de la présentation 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 ETR’11 – Best le 29 août 2011 2

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        Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 3

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%        Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 4

1-Introduction : les missions spatiales européennes Les lanceurs et véhicules de transport spatial : Ariane, ATV        Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 5

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) Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 6

1- Introduction : les orbites et leurs contraintes - 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 LV ETR’11 – Best le 29 août 2011 7 1

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) Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 8

1-Introduction : au cœur du système Bord/Sol LV 1-Introduction : au cœur du système Bord/Sol Calculateur CU PF Eq-1 Eq-2 Satellite Sol Centre de Contrôle 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 ! Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 9

1-Introduction : logiciel temps réel LV 1-Introduction : logiciel temps réel Calculateur CU PF Eq-1 Eq-2 Satellite Sol Centre de Contrôle 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. Vous allez voir dans la suite que, faire un LV, c ’est très compliqué. Je voudrais d ’abord vous convaincre que les logiciels à bord sont une nécessité. ETR’11 – Best le 29 août 2011 10

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 Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) 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 11 1

2- Description fonctionnelle LV 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 Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) 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 12 1

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) . Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 13 1

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 fonction « applicative » algorithmique (calcul numérique de type proportionnel/intégral = filtre du 2ème ordre - vote sur plusieurs thermistances). LV Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 14 1

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) fonction « applicative » - algorithmie simple LV Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 15 1

2- Description fonctionnelle LV 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 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) Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 16 1

2- Description fonctionnelle LV 2- Description fonctionnelle Programmation 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 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 Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 17 1

2- Description fonctionnelle LV Gestion des modes gère les ressources et l ’état des ressources depuis le niveau matériel jusqu’au niveau des fonctions et du satellite Modes LVC SPOT5 : 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 Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) ETR’11 – Best le 29 août 2011 18 1

2- Description fonctionnelle Isolation 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 Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) 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 19 1

2- Description fonctionnelle Reprogrammation/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) Une des caractéristiques principales des logiciels de vol est la diversité des intervenants et donc des fonctions à réaliser. Par LV, on entend le LV qui réalise toutes ces fonctions dans le cas d ’une architecture centralisée, mais aussi les logiciels décentralisés, quand ils existent. On comprend aisément la difficulté de faire cohabiter des fonctions aussi différentes que le contrôle thermique ou le traitement des données CU. Les constantes de temps, par exemple, ne sont pas comparables (microsecondes ou dizaine de secondes), les types de traitements sont aussi très différents (bcp d ’I/O, ou bcp de calculs). On choisit souvent de déporter les fonctions demandant bcp de calculs vers des calculateurs spécialisés (DSP), ou des ASICs (ou des FPGAs). Mais on trouve aussi,  c’est le cas pour certains instruments (SPI), toutes les fonctions, gestion de l ’instrument et traitement des données sur le même calculateur (à base de 1750 pour SPI) 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 20 1

3- Environnement : la problématique Processeurs spécifiques calculateur Limitation des ressources masse, consommation Environnement spatial radiations, températures Processeurs spécifiques LV Besoin de programmation efficace Environnement de développement limité Système de développement spécifique machine hôte/carte cible compilateur croisé Les contraintes environnementales ne sont pas toutes spécifiques du spatial. La limitation des ressources se pose à beaucoup de logiciels embarqués (télaphone portable). L ’environnement radiatif est spécifique du spatial. Toutes ces contraintes font qu ’on ne dispose que d ’un choix limité de calculateurs spécialement développés pour le spatial, c ’est-à-dire durcis aux radiations, qui fonctionnent dans des conditions extrêmes (vibrations, chocs, températures), tout en n ’étant ni trop lourds ni trop consommants. Développer et qualifier ce genre de calculateurs prend bcp de temps et coûte très cher, les calculateurs dont on dispose sont donc extrêmement moins performants que les calculateurs sol (ex : 1 à 10 Mips, à 20 MHz) Il faut donc utiliser des langages efficaces, et programmer de façon efficace. Cette contrainte limite l ’utilisation des outils de développement qui n ’ont pas pour premier objectif d ’obtenir un code optimisé en terme de taille mémoire ou de puissance de calcul. ETR’11 – Best le 29 août 2011 21 1

3-Environnement : Les Performances calculateur LV Plateformes d ’observation et scientifiques ETR’11 – Best le 29 août 2011 22

3- Environnement : Les Performances calculateur LV Plateformes télécom LV lanceur ETR’11 – Best le 29 août 2011 23

3- Environnement : Les Performances calculateur LV Instruments ETR’11 – Best le 29 août 2011 24

4- La Sûreté de fonctionnement 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 ETR’11 – Best le 29 août 2011 25

4-Sûreté de fonctionnement : une démarche « avant tout » qualité 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 ETR’11 – Best le 29 août 2011 26

5-Problématique de la maintenance en vol LV Correction d’anomalies logicielles Implémentation de palliatifs des anomalies systèmes/matérielles Amélioration de la mission Expériences embarquées Palliatifs en fin de vie Besoins Maintenir un logiciel embarqué est difficile, et particulièrement pour les logiciels embarqués à bord de satellites. On ne peut pas remplacer physiquement le calculateur ; de la même façon, les capacités de modification du logiciel sont limitées par la bande passante de la voie TC. De toute façon, avant de parler de modifier le logiciel, il faut avoir pu observer ce qui se passe. Les paramètres TM dont on a besoin doivent être bien définis, puisqu ’il faut disposer des points de mesure correspondants. Avec des formats fixes de TM, on est de plus limité par la bande passante de la voie descendante, et il faut avoir défini a priori, le besoin, en particulier la fréquence. Aujourd ’hui, grâce aux paquets CCSDS, on dispose de TM variable, mais il faut quand même disposer des points de mesure et des acquisitions adéquates. Bien définir aussi le niveau des TC : macrocommandes, TC directes... Adaptabilité : exemple : SOHO (mode gyroless), SPOT1 (mode pilotés), ERS2 (mode gyroless en cours) Performances réduites du lien bord/sol Observabilité limitée du comportement du logiciel Rechargement des modifications logiciel à sécuriser Perturbations de la mission à minimiser (disponibilité) ETR’11 – Best le 29 août 2011 27 1

6- Cycle(s) de développement LV Cycle théorique « en V » Cycles incrémentaux Cycles en spirale ETR’11 – Best le 29 août 2011 28

6- Cycle de développement théorique « en V » URD Analyse besoins Qualification Activités avionique Activités logiciel SRD Spécification Validation SVTR ADD ITR Architecture Intégration lire les correspondances Pb : si ambigüité dans spec, c ’est en validation ou en qualification qu ’on s ’en aperçoit, donc très tard. DDD UTR Production ETR’11 – Best le 29 août 2011 29 1

6- Cycle(s) incrémentaux : 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) ETR’11 – Best le 29 août 2011 30

6- Exemple de processus en spirale Translation Testing Unit Integration Coding Testing test Validation Testing Iterative Prototypes Next step preparation Design + process incrémental Réduction de rique, versions intermédiaires, supporte mieux les évolutions Test précoce (specs et archi) UML qu’on va voir tout à l’heure Analysis ETR’11 – Best le 29 août 2011 31

7- Les phases de développement et de validation LV : objectifs et moyens 7.1 - Collecte des besoins 7.2 - Spécification détaillée et l ’architecture LV 7.3 - Production - Intégration : conception détaillée, codage, TU, TI 7.4 - Validation fonctionnelle 7.5 - Qualification - Validation système 7.6 - La gestion des évolutions/non-régression 7.7 - La maintenance en vol ETR’11 – Best le 29 août 2011 32

7.1- Collecte et Analyse des besoins 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 Pour simplifier, on va étudier les phases du cycle de dévt théorique. Il peut y avoir des modélisations En pratique : on démarre avant que ce soit terminé ETR’11 – Best le 29 août 2011 33 1

7.2- Spécification détaillée et architecture LV - Modélisation 7.2.2 - Architecture - Architecture statique - Architecture dynamique - Interpréteurs embarqués - Production des données BDS ETR’11 – Best le 29 août 2011 34

7.2.1- Spécifications 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é La spec doit être complète, non ambiguë, précise. En particulier, les exigences temporelles sont très importantes. Des techniques sont évaluées pour sécuriser la correspondance : analyse des besoins --> spec, s ’assurer de la complétude et des non-ambigüité des specs. Langages formels : UML, MSC, LDS prototypages LV ETR’11 – Best le 29 août 2011 35 1

7.2.1-Spécifications : La modélisation 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 LV Modèles descriptifs : par exemple des modèles d ’architecture avec HOOD dont on va parler plus loin Modèles exécutables : logiciels, systèmes, ou parties (le plus souvent) - modèles de perfos : s ’intéressent principalement aux perfos et au dimensionnement d ’un système. Ils sont réalisés en parallèle du développement et peuvent être affinés au fur et à mesure - modèles comportementaux : permettent de décrire la spéc., puis par raffinements successifs, la conception. Dans certains cas on peut aller jusqu ’à la génération de code (qui est en fait une traduction des infos contenues dans le modèle) Vue précoce et exécutable (=> vérifiable du système) : très important car le coût de correction d ’une erreur (de soft ou de spéc) est minime en début de projet, et peut être énorme en fin de projet Analyses comparatives, évaluer l ’impact de modife avant leur prise en compte, réaliser des essais difficiles à mettre en œuvre sur les bancs Améliore la communication entre les différents acteurs d ’un projet, soulève beaucoup de questions qui auraient été vues (ou pas) beaucoup plus tard => tout cela induit une meilleure confiance dans le système Spéc. Pharao, microsat. Cert Industriels l’utilisent bcp ETR’11 – Best le 29 août 2011 36 1

7.2.1- Spécifications : Modélisation de performances Pour un logiciel ou un système ETR’11 – Best le 29 août 2011 37

Exemple de résultats ETR’11 – Best le 29 août 2011 38

Les principaux diagrammes UML (1/2) USE CASE Ce 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 : SEQUENCE DIAGRAM Ce 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. CLASS DIAGRAM Le diagramme de classes représente l’architecture objet logique du système, c’est à dire la structure statique du modèle. STATECHARTS Les 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. Utilisateur Haut-parleur Système Jouer message Jouer son Afficher progression Arrêter Arrêter son TEMPS On ne détaille pas tous les diagrammes Use cases : les fonctions du système + les acteurs Seq diqag : scénarios Classes : abstractions (spécs, déf. ou types d’objets) décrivent les objets du système Statecharts (exécutables avec outils): comportement Modèle logique (organise les spécs de classes) modèle physique (déploiement des instances du modèle logique) ETR’11 – Best le 29 août 2011 39

Les principaux diagrammes UML (2/2) Diagramme de collaboration (communication entre objets) Diagramme de déploiement (organisation du matériel) Noeuds = HW Liens = communication : réseaux, bus ETR’11 – Best le 29 août 2011 40

Exemple de diagramme de séquence SCA Gestion Bord Charge Utile Mode Normal Mode Normal Alarme panne équipement Commande passage survie Mode Survie Alarme survie Mode Survie TEMPS Reconf avec panne Désactiver Charge Utile ETR’11 – Best le 29 août 2011 41

7.2.2- Architecture Statique : notion de couches Le logiciel est structué en plusieurs couches, de la plus proche du matériel à la plus indépendante : SCAO - Contrôle thermique - CU TM/TC - Surveillances / Reconfigurations - Gestion modes Application Services OS +Drivers LV Le matériel (calculateur, bus) n ’est pas spécifique de l ’application. Ou, du moins, on essaie de plus en plus de ne pas redévelopper un calculateur à chaque nouveau satellite. Si on réutilise du matériel, on pourra aussi, en général, réutiliser les couches les plus basses du logiciel. On commence aujourd ’hui à développer des logiciels de service, c ’est-à-dire non spécifique de l ’application. Ex : fabrication de paquets TC ou TM, ou gestion de fichiers dans une mémoire de stockage de données. Matériel ETR’11 – Best le 29 août 2011 42

7.2.2- Architecture statique : notion d ’objet 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) ... AVANTAGES : -Règles de structuration - Principe d ’abstraction - Encapsulation des données - Modularité Maintenabilité Parent OP1 OP2 OP3 Enfant_1 Quand on parle d ’architecture, il s ’agit à la fois de l ’architecture statique (comme celle qu ’on voit ici), ou d ’architecture dynamique (planche suivante) HOOD = Hierarchical Object Oriented Design L ’architecture est représentée à l ’aide d ’un certain nombre d ’objets qui échangent des services. Un objet est une notion abstraite qui recouvre un ensemble de services et des données. Seuls les services offerts sont visibles de l ’extérieur, leur implémentation est masquée de même que les données. On parle d ’encapsulation des données. Seuls les services permettent de manipuler les données contenues dans l ’objet. Un objet peut faire appel à des services d ’un autre objet (relation ‘ use ’) Un objet parent peut être décomposé en plusieurs objets fils (sur le schéma, le service OP1 est rendu par le fils du haut) Avantages majeurs : beaucoup plus modulaire que les décompositions fonctionnelles, on peut changer l ’implémentation d ’un objet sans que les autres objets s ’en aperçoivent => évolutivité et maintenabilité bien meilleures Pour toi : Les objets échangent les données via les paramètres des opérations, mais c ’est coûteux en temps réel (passage par la pile), et on fait parfois quelques compromis : Astrium utilise la notion de data pool qui permet de partager un certain nb de données Il y a aussi des services internes que les autres objets ne voient pas. Il y a des objets actifs (càd qu ’au moins un service est activé sur événement, par exemple une IT) et passifs ETR’11 – Best le 29 août 2011 43 1

7.2.2- Architecture dynamique 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) LV ETR’11 – Best le 29 août 2011 44 1

7.2.2- Architecture dynamique : les interruptions 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, … IT niveau 0 IT niveau 2 IT niveau 5 Tâches interrompues pendant ce temps Peuvent indiquer des pbs Description du schéma Table de vecteurs d’interruption Sauve registres, et certaines valeurs Appelle routine d’IT (brève) Restore les valeurs et on reprend l’exécution ETR’11 – Best le 29 août 2011 45

7.2.2- Architecture dynamique Séquenceur Périodique (exemple SPOT) IT 64 Hz IT 1 Hz Tâche 32 Hz Tâche 8 Hz LV 1 hz : toutes les secondes, etc. T 8 Hz : au milieu entre 2 T 32 Hz, interrrompue par T 32 Hz. T 1 HZ : au milieu entre 2 T 8 Hz Faut que T 8Hz dure au plus la moitié des 125 ms, elle doit se terminer à temps pour que la tâche 1 HZ puisse s’exécuter. avantage : complètement déterministe, facile à valider inconvénient : sur-dimensionnement : on alloue à chaque tâche sa durée max Tâche 1 Hz ETR’11 – Best le 29 août 2011 46 1

7.2.2- Architecture dynamique : Exécutif temps réel 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 OS le fait en dynamique ETR = OS = Syst d’exploitation avantage : optimal par rapport à l’util de la CPU (dès qu ’une tâche est terminée, on peut démarrer la suivante, s ’il y en a une) les inconvénients : peu prédictible, difficile à valider (multitude de cas possibles) Logiciels récents : ont ~à peu près tous des exécutifs ETR’11 – Best le 29 août 2011 47

Exécutif temps réel : les états des tâches - 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 …) En cours En attente ressource, évt Prête Différée délai Commencer par En cours/Prête ETR’11 – Best le 29 août 2011 48 1

Exécutif temps réel : les types de tâches 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 + Evoquer le pb de l’inversion de priorité. ETR’11 – Best le 29 août 2011 49 1

7.2.2- Architecture : Interpréteurs embarqués 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 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 Comm : type de gestion des attentes, (FIFO ou prio), taille des messages, message prioritaire Synchro : sémaphore binaire, à compte, mutex, type de gestion des attentes (FIFO, prio), héritage prio Délais, evts (synch), signaux (asynch) Gestion mém : dynamique (une tâche peut allouer ou désallouer), contrôle de débt de pile ETR’11 – Best le 29 août 2011 50

7.2.2- Architecture : Production des données BDS 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 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)... Comm : type de gestion des attentes, (FIFO ou prio), taille des messages, message prioritaire Synchro : sémaphore binaire, à compte, mutex, type de gestion des attentes (FIFO, prio), héritage prio Délais, evts (synch), signaux (asynch) Gestion mém : dynamique (une tâche peut allouer ou désallouer), contrôle de débt de pile ETR’11 – Best le 29 août 2011 51

7.3 - La phase de production et d ’intégration Conception détaillée, codage 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) Parent OP1 OP2 OP3 Enfant_1 ETR’11 – Best le 29 août 2011 52

7.3 - La phase de production et d ’intégration Tests unitaires Chaque service ou « module » du logiciel est testé indépendamment Objectif = couverture 100% code, branches, décisions (en fonction du niveau de criticité) Parent OP1 OP2 OP3 Enfant_1 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 53

7.3 - La phase de production et d ’intégration Tests d ’intégration 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é) Parent OP1 OP2 OP3 Enfant_1 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 54

7.3 - La phase de production et d ’intégration Moyens de test TU/TI Les tests unitaires (càd service par service) sont généralement effectués sur la station de développement. Puis, pour l ’intégration du logiciel avec le matériel, on connecte le système de développement à la carte CPU (Central Processing Unit) par l’intermédiaire d’une liaison. Cette carte, sur laquelle se trouve le processeur, sera placée dans le boîtier du calculateur embarqué dans le satellite. Le logiciel de vol est alors chargé sur la carte CPU via la liaison éthernet et l ’intégration logiciel/matériel commence par la couche du logiciel qui gère le matériel. La station supporte l’ensemble des outils de l’environnement de développement, qui permettent de développer et de mettre au point le logiciel pour une carte cible embarquée. Dans l’exemple ci-dessus, l’outil de mise au point permet d’observer les activations des tâches en fonction du temps. Ethernet est beaucoup plus performante que la liaison série mais on peut utiliser la liaison série si on n ’a pas d ’éthernet. La liaison TTY était utilisée pour des communications avec la cible (init pour VxWorks de la liaison avec la carte, visualisations). LV ETR’11 – Best le 29 août 2011 55

7.4- La validation fonctionnelle Validation par fonction : essais « boîte noire » Comportement fonctionnel et algorithmique pur Vérification de toutes les exigences « unitaires » de la SRD Simulateur 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émoire Simulateur hybride - sonde temps réel ETR’11 – Best le 29 août 2011 56

L’outil LICE : sonde temps réel Spécifiée par le CNES Le logiciel est instrumenté Target Computer RS 232 Ethernet network LICE PC Host Computer (SUN Workstation) LICE Probe CPU Board Child board 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 57

La visualisation dynamique ETR’11 – Best le 29 août 2011 58

7.5- La validation système « qualification » 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 URD Banc avionique - banc système Validation système QT/QO adéquation des besoins LV et du satellite aux opérations Couplage bord/sol Banc 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 ETR’11 – Best le 29 août 2011 59

7.6- Gestion des évolutions / non-régressions LV 7.6- Gestion des évolutions / non-régressions 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. A permis de confirmer et formaliser des choses qu’on savait avant, et de les faire reconnaître par la hiérarchie. ETR’11 – Best le 29 août 2011 60

7.7- La maintenance en vol Support LV aux équipes opérationnelles : LV 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 A permis de confirmer et formaliser des choses qu’on savait avant, et de les faire reconnaître par la hiérarchie. ETR’11 – Best le 29 août 2011 61

8- Difficultés (1/3) 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 LV LV Besoins AIT Spécifications temps ETR’11 – Best le 29 août 2011 62 1

8- Difficultés (2/3) 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) ETR’11 – Best le 29 août 2011 63

8- Difficultés (3/3) 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 Dégradation et perte des gyros. Gens du SCAO ont imaginé un nouveau SCAO sans gyro => modifs majeures du logiciel Et heureusement qu’il était là Supermode SPOT 1 : améliorer la perfo mission, mise en place d’un mode qui permet de faire une sorte de ralenti sur image pour avec une image mieux résolue. ETR’11 – Best le 29 août 2011 64

9- Conclusion : perspectives LV Augmentation autonomie/intelligence embarquée : stratégie de développement/validation de logiciels de plus en plus complexes (cohabitation temps réel dur / mou) 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 A permis de confirmer et formaliser des choses qu’on savait avant, et de les faire reconnaître par la hiérarchie. 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 65

Exemples de projets ETR’11 – Best le 29 août 2011 66

Les logiciels de vol centraux SPOT Observation de la terre 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) ETR’11 – Best le 29 août 2011 67

PROTEUS Lancement Conception Logiciel applicatif P/F O.S. PlateForme réutilisable pour l’observation scientifique de la terre, des étoiles, de la couverture nuageuse, … 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 Difficultés : évolutions de spéc ETR’11 – Best le 29 août 2011 68

PROTEUS : les missions (1/2) Jason1, 7 déc 2001, Altimétrie Coopération NASA JPL Calipso, début 2005, Lidar Coopération NASA LaRC Corot, début 2006, Astronomie Coopération européenne ETR’11 – Best le 29 août 2011 69

PROTEUS : les missions (2/2) SMOS, Radiomètre bande L Coopération ESA Jason2 Megha-Tropiques, Cycle de l ’eau Coopération ISRO (Inde) ETR’11 – Best le 29 août 2011 70

INTErnational Gamma Ray Astrophysics Laboratory INTEGRAL INTErnational Gamma Ray Astrophysics Laboratory 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 DPE envoie : cdes de configuration et de contrôle Reçoit : Données scientifiques + état des équipements ETR’11 – Best le 29 août 2011 71

INTEGRAL : schéma d’ensemble Equipements de collecte des données Maîtrise d’œuvre interne de l’instrument principal (SPI) Calculateur DPE Photons et rayons gamma Digital Processing Equipment Calculateur P/F TM TC SOL ETR’11 – Best le 29 août 2011 72

Logiciel SPI : activités du CNES 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 ETR’11 – Best le 29 août 2011 73

Logiciel du DPE Logiciel applicatif Conception Calculateur Langage 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 74

} { SPI : interfaces Calculateur DPE ESA Intégration Satellite CESR Berkeley DSS & MPE (Allemagne) CEA Mire ESA Mission Operation Centre (ESOC) CESR Intégration Satellite (Alenia) Integral Science Data Centre Calculateur DPE Matériel (CRISA) Log. base (GMV) Log. applicatif } Communs aux 4 instruments { CNES (SEA/IL) DIAF/Transiciel Conduite de tests (EGSE) ETR’11 – Best le 29 août 2011 75

SPI : chronologie 1994 1995 1996 1997 2001 2000 1999 1998 2002 Appel d'Offre (juin) Réponse Appel d'Offre (oct) RCS (sept) RDP SPI (dec) Consultation LV (fev) Kick Off (juil) SRR (oct) PDR (jan) Livraison SEM (dec) Livraison EM (avril) Tir (octobre 2002) Livraison log. Applicatif (juill) Recette log. applicatif (juill) Livraison Modèle de vol (mai) Test Fonctionnel Modèle de vol (sept) ETR’11 – Best le 29 août 2011 76

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 DM nombreuses au cours du dévt Sept 2003 : Bruit de fond rayont gamma sous-estimé par les scientifiques (normal pour projet scientifique) => instrument et le logiciel ont eu beaucoup plus d’évts à traiter que prévu => adaptations du logiciel ETR’11 – Best le 29 août 2011 77