ETR

1
Problématique et retour dexpérience du
développement des Logiciels embarqués pour le
spatial
Paul ARBERET
2
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

3
1-Introduction le CNES Centre National
dEtudes Spatiales

• Donneur dordre 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 dEvry
• Centre spatial de Toulouse
• Centre spatial Guyanais

      
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 à lESA)
• 2418 salariés
• Répartition homme / femme 65 / 35

      
5
1-Introduction les missions spatiales
européennes

• Les lanceurs et véhicules de transport spatial
  Ariane, ATV

      
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)

7
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) -gt 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

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)

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 !

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 dune seconde à quelques
  secondes.
• Déterminisme et prédictabilité nécessaires.

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)

• Classification des fonctions embarquées
• Gestion modes surveillances - FDIR
• Traitement SCAO contrôle thermique - énergie
• Communication TM/TC protocoles bord

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

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

fonction  applicative  algorithmique (calculs
numériques cycliques plus ou moins complexes
filtres - manipulations et calculs matriciels -
équations sur polynômes) .
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

fonction  applicative  algorithmique (calcul
numérique de type proportionnel/intégral filtre
du 2ème ordre - vote sur plusieurs thermistances).
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)

fonction  applicative  - algorithmie simple
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

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)
17
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
18
2- Description fonctionnelle

• Gestion des modes
• gère les ressources et l état des ressources
  depuis le niveau matériel jusquau 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
19
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 -gt Survie

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

peu de code spécifique mais des règles de
conception et codage permettent d assurer ces
mises en œuvre en vol
21
3- Environnement la problématique calculateur

• Limitation des ressources
• masse, consommation
• Environnement spatial
• radiations, températures

Processeurs spécifiques
Besoin de programmation efficace Environnement de
développement limité Système de développement
spécifique machine hôte/carte cible compilateur
croisé
22
3-Environnement Les Performances calculateur
LV Plateformes d observation et scientifiques
23
3- Environnement Les Performances calculateur
LV Plateformes télécom
LV lanceur
24
3- Environnement Les Performances calculateur
LV Instruments
25
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

26
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

27
5-Problématique de la maintenance en vol

• Correction danomalies 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

• 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é)

28
6- Cycle(s) de développement LV

• Cycle théorique  en V 
• Cycles incrémentaux
• Cycles en spirale

29

• 6- Cycle de développement théorique  en V 

Analyse besoins
Qualification
URD
Activités avionique
Activités logiciel
Spécification
Validation
SRD
SVTR
ADD
ITR
Architecture
DDD
UTR
Production
30
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)

31
6- Exemple de processus en spirale
Translation
Testing
Integration
Unit
test
Testing
Coding
Validation
Testing
Iterative
Prototypes
Next step preparation
Design
Analysis
32
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

33
7.1- Collecte et Analyse des besoins

• Analyse système globale gt définir
• La répartition bord/sol
• L autonomie de la mission
• La fiabilité/disponibilité stratégie de
  surveillance et reconfiguration
• Les constituants de larchitecture 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

34
7.2- Spécification détaillée et architecture LV

• 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

35
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, CC)
• 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 (--gt 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é

36
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 limpact
  d une modification
• amélioration de la communication
• meilleure confiance dans le système
• utilisation limitée pour linstant pendant la
  phase de spécification LV

37
7.2.1- Spécifications Modélisation de
performances

• Pour un logiciel ou un système

38
Exemple de résultats
39
Les principaux diagrammes UML (1/2)
USE CASE Ce diagramme sert à modéliser les cas dutilisation du système, cest à 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 dutilisation. Il met en évidence les interactions entre les éléments du système.
CLASS DIAGRAM Le diagramme de classes représente larchitecture objet logique du système, cest à dire la structure statique du modèle. STATECHARTS Les diagrammes détat servent à représenter les états quun 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.
40
Les principaux diagrammes UML (2/2)
Diagramme de collaboration (communication entre
objets)
41
Exemple de diagramme de séquence
SCA
Charge Utile
Gestion Bord
Mode Normal
Mode Normal
Alarme panne équipement
Commande passage survie
Mode Survie
Alarme survie
Mode Survie
TEMPS
Reconf avec panne
Désactiver Charge Utile
42
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
Matériel
43
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é
44
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 (gt20
tâches périodiques et apériodiques)
45
7.2.2- Architecture dynamique les interruptions

• avertir la CPU quun événement sest produit
• Quand une interruption survient, le processeur
  déroute lexécution à un programme dédié (handler
  dinterruption)
• A fin du handleur dinterruption, le contrôle est
  rendu au programme interrompu
• Des priorités sont attribuées aux différentes IT
• Sources dinterruptions timers (ex horloge),
  
• entrées/sorties asynchrones, matériels,

46
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
Tâche 1 Hz
47
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 dinterruptions
  associés aux évènements externes
• Ordonnancement des tâches en fonction des
  priorités définies et du schéma dordonnancement
  (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)

48
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
49
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
50
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

• 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

51
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

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

52
7.3 - La phase de production et d intégration
Conception détaillée, codage

• Chaque service offert par lobjet 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
53
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

54
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)

55
7.3 - La phase de production et
d intégration Moyens de test TU/TI
56
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 derreurs
• 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

57
Loutil LICE sonde temps réel

• Spécifiée par le CNES
• Le logiciel est instrumenté

• Ecriture dun 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)

58
La visualisation dynamique
59
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

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

61
7.7- La maintenance en vol

• 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

62
8- Difficultés (1/3)

• Difficulté de planning développement coincé
  entre
• le besoin dun 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 dinterface

63
8- Difficultés (2/3)

• Difficulté dexprimer exactement ce quil faut
  faire
• Les spéc amont sont ambitieuses et ne prennent
  pas suffisamment en compte limpact de certains
  choix sur le LV
• gt 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
• gt 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)

64
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 quil 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

65
9- Conclusion perspectives

• 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)
  -gt 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) -gt synergie avec ESA et
  les industriels

• Amélioration de l efficacité des phases de
  validation automatisation des tests - meilleure
  adéquation des moyens

66

• Exemples de projets

67
Les logiciels de vol centraux SPOT
SPOT5
SPOT4
Observation de la terre

• 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)

• Lancement
• Mars 98
• Logiciel applicatif
• ASTRIUM
• Processeur
• F9450
• Langage
• assembleur
• Taille code
• 31 kmots (16 bits)
• Taille données
• 32 kmots (16 bits)

68
PROTEUS
PlateForme réutilisable pour lobservation
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
• 100 kmots

69
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
70
PROTEUS les missions (2/2)
SMOS, Radiomètre bande L Coopération ESA
Jason2
Megha-Tropiques, Cycle de l eau Coopération ISRO
(Inde)
71
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

72
INTEGRAL schéma densemble
Equipements de collecte des données

• Maîtrise dœuvre interne
• de linstrument principal (SPI)

Calculateur DPE
Photons et rayons gamma
Digital Processing Equipment
Calculateur P/F
TM
TC
SOL
73
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) gt
  conduite des essais sur simulateur gt
  participation aux essais sur matériel réel
• Forte implication dans les choix système Gestion
  Bord
• Supports ponctuels
• Expertise SW/HW pendant lappel doffres
• Expertise compression
• Utilisation des moyens de laboratoire SEA/IL
  pendant la phase B
• Modélisations
• Participation à des revues

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

75
SPI interfaces
ESA
Mire
Mission Operation Centre (ESOC)
CESR
Integral Science Data Centre
Intégration Satellite (Alenia)
Calculateur DPE

Matériel (CRISA) Log. base (GMV) Log. applicatif
Communs aux 4 instruments

CNES (SEA/IL) DIAF/Transiciel
Conduite de tests (EGSE)
76
SPI chronologie
Appel d'Offre (juin)
RCS (sept)
Consultation LV (fev)
RDP SPI (dec)
SRR (oct)
Kick Off (juil)
Réponse Appel d'Offre (oct)
PDR (jan)
Livraison SEM (dec)
Livraison EM (avril)
Tir (octobre 2002)
Livraison log. Applicatif (juill)
Livraison Modèle de vol (mai)
Recette log. applicatif (juill)
Test Fonctionnel Modèle de vol (sept)
77
SPI la phase de maintenance du logiciel

• mai 2001 livraison de linstrument 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