Transcript Problématique et retour d`expérience du développement des

Problématique et retour
d’expérience du
développement des Logiciels
embarqués pour le spatial
Paul ARBERET
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
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%
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
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)
ETR’11 – Best le 29 août 2011
6
1- Introduction : les orbites et leurs contraintes
LV
- orbite basse « observation de la terre / scientifique » SPOTPlé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
ETR’11 – Best le 29 août 2011
7
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
8
LV
1-Introduction : au cœur du
système Bord/Sol
Calculateur
PF
Eq-1
Calculateur
CU
Eq-2
Satellite
Calculateur
Sol
Centre de Contrôle
ETR’11 – Best le 29 août 2011
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 !
9
LV
1-Introduction : logiciel temps
réel
Calculateur
PF
Eq-1
Calculateur
CU
Eq-2
Satellite
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,
Calculateur
Sol
– Temps réel mou : cycles d’une seconde à
quelques secondes.
Déterminisme et prédictabilité nécessaires.
Centre de Contrôle
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
LV
• 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
ETR’11 – Best le 29 août 2011
11
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
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
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
13
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
ETR’11 – Best le 29 août 2011
14
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
ETR’11 – Best le 29 août 2011
LV
15
2- Description fonctionnelle
LV
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)
ETR’11 – Best le 29 août 2011
16
2- Description fonctionnelle
LV
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
ETR’11 – Best le 29 août 2011
17
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 :
Satellite
Survie
SCAO
Survie
MRV
MAG
MAF1
Lancement MAF2
MPF
MCC
MCO
Nominal
ETR’11 – Best le 29 août 2011
CU
CSU
CLT
CSU
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
COP
CVF
18
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
LV
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
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
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
ETR’11 – Best le 29 août 2011
20
LV
3- Environnement : la problématique
calculateur
Limitation des ressources
masse, consommation
Environnement spatial
Processeurs
spécifiques
radiations, températures
LV
Besoin de programmation efficace
Environnement de développement limité
Système de développement spécifique
machine hôte/carte cible
compilateur croisé
ETR’11 – Best le 29 août 2011
21
3-Environnement : Les Performances calculateur
LV Plateformes d ’observation et scientifiques
Processeur
Perfo TR
Taille Mem
SPOT4
F9450
0,7 MIPS
256 Ko
SPOT5
MA3-1750
1 MIPS
512 Ko
Pléiades
ERC32
13 MIPS
6 Mo
PROTEUS
MA3-1750
1 MIPS
512 Ko
MYRIADE
T805
4 MIPS
2 Mo
ETR’11 – Best le 29 août 2011
22
3- Environnement : Les Performances calculateur
LV Plateformes télécom
Processeur
Perfo TR
Taille Mem
E3000/Stentor
MA3-1750
1 MIPS
256 K
ALPHABUS
ERC32
13 MIPS
4 Mo
AGORA
MA3-1750
1 MIPS
1 Mo
LV lanceur
Processeur Perfo TR
Ariane V
ETR’11 – Best le 29 août 2011
68020 +
68082
Taille Mem
1,2 MIPS 1 Mo
222 Kflops
23
3- Environnement : Les Performances calculateur
LV Instruments
Processeur
Perfo TR
Taille Mem
IASI – IMSS
MA3-1750
1 MIPS
1 Mo
IASI - DPS
ADSP 21020 15 MIPS /
45 Mflops
SPI-Integral
MA3-1750
1 MIPS
PHARAO
ERC32
10 MIPS
ETR’11 – Best le 29 août 2011
PM = 768 Ko
DM = 1Mo
10 Mo
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
Besoins
anomalies systèmes/matérielles
Amélioration de la mission
Expériences embarquées
Palliatifs en fin de vie
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
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
ADD
DDD
ETR’11 – Best le 29 août 2011
Validation
Architecture
SVTR
ITR
Intégration
UTR
Production
29
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
Coding
Unit
Testing
Integration
test
Validation
Testing
Iterative
Prototypes
Next step preparation
Design
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
ETR’11 – Best le 29 août 2011
33
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
ETR’11 – Best le 29 août 2011
34
7.2.1- Spécifications
LV
•
Exprimer tout ce que doit faire le logiciel, mais sans sur-spécifier
•
Exprimer les exigences temporelles
•
Vérifier la faisabilité et la testabilité de l ’ensemble de ces exigences
– 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
– 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)
– Nécessité d ’exprimer dans un langage formalisé, éventuellement exécutable
– Numérotation des exigences - matrice de testabilité
ETR’11 – Best le 29 août 2011
35
7.2.1-Spécifications : La modélisation
•
Modèles descriptifs
•
Modèles exécutables (logiciels ou systèmes)
– formaliser la représentation de spécifications, de conceptions
- modèles de dimensionnement et de performances (SES/workbench, Opnet)
- modèles comportementaux (UML, SDL)

LV
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
ETR’11 – Best le 29 août 2011
36
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
SEQUENCE DIAGRAM
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 :
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.
Enregistreur numérique
Utilisateur
Ecouter un
message
Système
Haut-parleur
Jouer message
Jouer son
Enregistrer un
message
Afficher progression
Utilisateur
Arrêter
Effacer un
message
Arrêter son
CLASS DIAGRAM
STATECHARTS
Le diagramme de classes représente l’architecture objet logique du système, c’est à
dire la structure statique du modèle.
Interface_utilisateur
Attente
Fin
Clavier
Afficheur
Jouer()
Arreter()
Stop
Enregistrer
Demarrer
Controleur
Joue
Micro
ETR’11 – Best le 29 août 2011
TEMPS
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.
Enregistre
Haut_parleur
39
Les principaux diagrammes UML (2/2)
Diagramme de
collaboration
(communication entre
objets)
ETR’11 – Best le 29 août 2011
Diagramme de
déploiement
(organisation du matériel)
40
Exemple de diagramme de séquence
SCA
Gestion
Bord
Mode Normal
Charge Utile
Mode Normal
Alarme panne
équipement
Commande passage
survie
Mode Survie
Alarme survie
Mode Survie
TEMPS
Reconf avec panne
ETR’11 – Best le 29 août 2011
Désactiver Charge Utile
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 :
Application
Services
OS +Drivers
SCAO - Contrôle thermique - CU
TM/TC - Surveillances /
Reconfigurations - Gestion modes
LV
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) ...
Parent
OP1
-Règles de
structuration
- Principe
d ’abstraction
OP2
OP3
AVANTAGES :
Enfant_1
- Encapsulation
des données
- Modularité
Maintenabilité
ETR’11 – Best le 29 août 2011
43
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)
LV
- exécutif préemptif : Pléiades - Proteus (>20 tâches
périodiques et apériodiques)
ETR’11 – Best le 29 août 2011
44
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
IT niveau 0
Sources d’interruptions : timers (ex : horloge),
IT niveau 2
entrées/sorties asynchrones, matériels, …
IT niveau 5
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
Tâche 1 Hz
ETR’11 – Best le 29 août 2011
46
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)
LV
• Messages and sémaphores (communication entre tâches)
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
ETR’11 – Best le 29 août 2011
Prête
Différée
délai
48
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
ETR’11 – Best le 29 août 2011
49
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
LV
– modifications réalisées en AIT ou en vol par des nonspé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
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 codedans 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
51
7.3 - La phase de production et d ’intégration
Conception détaillée, codage
Parent
OP1
OP2
Enfant_1
•
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
OP3
•
Utilisation de compilateurs croisés/natifs
•
Exécutable produit à partir de :
– Code source, données logiciel et données communes (BDS)
ETR’11 – Best le 29 août 2011
52
7.3 - La phase de production et d ’intégration
Tests unitaires
Parent
OP1
•
Chaque service ou « module » du logiciel est testé
indépendamment
OP2
Enfant_1
•
OP3
Objectif = couverture 100% code, branches, décisions
(en fonction du niveau de criticité)
•
•
•
•
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
Parent
OP1
•
Intégration « bottom-up » des modules depuis les
couches basses (interfaces matérielles) jusqu ’aux
OP2
Enfant_1
couches applicatives
OP3
•
Objectif = couverture 100% des interfaces (en
fonction du niveau de criticité)
•
•
•
•
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
TTY
Outil de mise
au point
Noyau
Applicatif
Carte processeur
Liaison série
Liaison Ethernet
LV
Station de
développement
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 HW/SW
– Performances TR + numériques
– Vérification de toutes les exigences
des ICD
– Interfaces calculateur
– Gestion mémoire
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
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é
•
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)
LICE
Probe
LICE
PC
Target
Computer
Host Computer
(SUN
Workstation)
CPU Board
RS
232
ETR’11 – Best le 29 août 2011
Child board
Ethernet network
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 LV sur Satellite
• Validation système QT/QO
– adéquation des besoins LV et
du satellite aux opérations
– Couplage bord/sol
Banc système + 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
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.
ETR’11 – Best le 29 août 2011
60
LV
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
ETR’11 – Best le 29 août 2011
61
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
Spécifications
temps
LV
Besoins AIT
• 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
ETR’11 – Best le 29 août 2011
62
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
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
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
SPOT4
•
•
•
•
•
•
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)
ETR’11 – Best le 29 août 2011
•
•
•
•
•
•
SPOT5
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)
67
PROTEUS
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
ETR’11 – Best le 29 août 2011
• Conception
– HOOD
• O.S.
– Ostrales
• Nombre de lignes
– 25000
• Taille code
– 100 kmots
• Taille données
– 100 kmots
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
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
ETR’11 – Best le 29 août 2011
71
INTEGRAL : schéma d’ensemble
• Maîtrise d’œuvre interne
de l’instrument principal (SPI)
Equipements de
collecte des
données
Calculateur DPE
Calculateur
P/F
Digital
Processing
Equipment
Photons et
rayons gamma
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
– DIAF/Transiciel et 3IP/CS
• Calculateur
– CRISA
• Couches basses
– GMV
• Processeur
– MA3 1750
ETR’11 – Best le 29 août 2011
• Conception
– HOOD
• Langage
– Ada 83 + assembleur
• O.S.
– Astres 1750
• Nombre de lignes
– 38000
74
SPI : interfaces
Intégration Satellite
(Alenia)
Mire
ESA
Mission Operation
Centre (ESOC)
CESR
Integral Science
Data Centre
DSS & MPE
(Allemagne)
CEA
Matériel (CRISA)
Berkeley
Log. base (GMV)
Log. applicatif
ETR’11 – Best le 29 août 2011
{
}
Communs aux
4 instruments
Calculateur DPE
CESR
CNES (SEA/IL)
DIAF/Transiciel
Conduite de tests (EGSE)
75
SPI : chronologie
1994
1995
1996
ETR’11 – Best le 29 août 2011
1997
1998
1999
2000
2001
76
2002
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
ETR’11 – Best le 29 août 2011
77