Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial

ETR’11 – Best le 29 août 2011 1

Problématique et retour d’expérience du

développement des Logiciels embarqués pour

le spatialPaul ARBERET


• 1- Introduction• 2- Description fonctionnelle• 3- Environnement calculateur• 4- Sûreté de fonctionnement• 5- Problématique de maintenance en vol• 6- Le(s) cycle(s) de développement des logiciels de vol• 7- Les phases de vie du logiciel : objectifs et moyens• 8- Difficultés• 9- Conclusion : perspectives

Plan de la présentation


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

http://sesame.cnes.fr/Livelink/livelink.exe?func=ll&objAction=Open&objId=20972782



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%




1-Introduction : les missions spatiales

européennes• Les lanceurs et véhicules de transport spatial :

Ariane, ATV




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)


- orbite basse « observation de la terre / scientifique » SPOT-Pléiades - Jason : nombre de passages réduit (10mn/100mn) - bande passante faible (quelques centaines de kbits/s)

- géostationnaire « télécommunication » Telecom1 - Stentor - E3000 : continuité du service (satellites télécom) -> réactivité aux pannes

- sonde interplanétaire « astrophysique / scientifique » - Rosetta/Mars Express : autonomie vis à vis des pannes - très faible bande passante - interruptions TM/TC - capacité de reprogrammation.

- lanceur - Ariane : aucune commandabilité sol hormis la sauvegarde

1- Introduction : les orbites et leurs contraintes

LV


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)


1-Introduction : au cœur du système Bord/Sol

Le Logiciel de Vol « LV » = à l ’interface entre le sol et le satellite, assure les fonctions embarquées « intelligentes » vitales qui ne permettraient pas une réactivité suffisante si réalisées au sol.– niveau d ’autonomie requis par la mission,– capacité d ’évolution tardive y compris en

vol que ne permettent pas les composants matériels !

LV

Calculateur CU

Calculateur PF

Eq-1 Eq-2

Satellite

Calculateur Sol

Centre de Contrôle


1-Introduction : logiciel temps réel

Le Logiciel de Vol « LV » = des activités réalisées en temps « borné » par les exigences de la mission et les contraintes du système.– Temps réel dur : cycles de quelques µs à

quelques centaines de ms,– Temps réel mou : cycles d’une seconde à

quelques secondes.Déterminisme et prédictabilité

nécessaires.

LV

Calculateur CU

Calculateur PF

Eq-1 Eq-2

Satellite

Calculateur Sol

Centre de Contrôle


2- Description fonctionnelle

• Dialogue Bord/Sol « TM/TC » • Contrôle d ’attitude et d ’orbite (SCAO)• Contrôle thermique actif• Contrôle de l ’énergie• Séquence automatique / Contrôle de Vol• Programmation mission / charge utile• Gestion des anomalies et des reconfigurations (FDIR)

LV

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



Dialogue Bord/Sol + communication avec le matériel : gestion des protocoles• réception TC / émission TM : protocole sol/bord (CCSDS)• encodage/décodage/mémorisation et routage de/vers les sous-systèmes (CCSDS)• élaboration de tables de diagnostic (extrema de paramètres, divers historiques, dwell / acquisitions à la demande) • capacité de mémorisation et exécution différée TC

LV

fonction de « service » non algorithmique simple de manipulation de données / vérifications - configurée par la Base de Données Système (BDS) : complexité due aux interactions temps réel entre fonctions et niveaux de tâches.



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



Contrôle thermique actif• assure la stabilité thermique de la plateforme et des instruments : acquisition des températures - prédiction et envoi des commandes/consignes de réchauffage

LV

fonction « applicative » algorithmique (calcul numérique de type proportionnel/intégral = filtre du 2ème ordre - vote sur plusieurs thermistances).



Contrôle de l ’énergie• gère la charge et la décharge des batteries en fonction du niveau d ’éclairement des panneaux solaires (passages en éclipse)• asservissement du moteur d ’entrainement des panneaux solaires pour garantir un éclairement maximal (orbite basse) ou utilisation pour pilotage attitude satellite (géostationnaire)

LVfonction « applicative » - algorithmie simple



Séquence automatique / Contrôle de Vol (CDV)• cadence l ’envoi des ordres pyrotechniques / AMF durant la mise à poste satellite (déploiement des antennes, panneaux solaires, déblocage des mécanismes)• séquence l ’ensemble des mises en œuvre matérielles lanceur

LV

fonction « applicative » cyclique = séquenceur d ’ordres interprétés (commandes - délais - vérifications - logique simple) capacité de reprogrammation simple en fonction des missions (ex : CDV Ariane V ou Séquence Automatique SL)


2- Description fonctionnelleProgrammation mission / charge utile• gère les mises en œuvre des différents composants de la charge utile sur ordre de programmation du sol (plan de travail)• Traite données mission

LV

fonction « applicative » supportée par un interpréteur de séquences élémentaires (commandes bas niveau - délais - vérifications) capacité de mémorisation du plan de travail (chargé par TC) et d ’exécution différée en continu sur l ’orbite (satellites orbite basse)capacité / souplesse de reprogrammation tardive dans le développement, ou en vol - meilleure indépendance du LV vis à vis de la mission (ex : IASI - SPOT5 / HELIOS 2 - Stentor)Traitement numérique + ou – complexe sur les données mission


2- Description fonctionnelleGestion des modes• gère les ressources et l ’état des ressources depuis le niveau matériel jusqu’au niveau des fonctions et du satellite

LV

Satellite SCAO CUSurvie Survie CSU

Lancement

MRVMAGMAF1MAF2

CLTCSU

Nominal

MPFMCCMCO

COPCVF

fonction « de service » simple qui mémorise les états des ressources, et des fonctions et du satellite. = Chef d ’orchestre en charge de cadencer les activités LV

Modes LVC SPOT5 :


2- Description fonctionnelleIsolation et passivation des pannes• surveille les paramètres sous-systèmes et systèmes dans des intervalles de valeurs attendues

• consommation électrique : tensions, courants,• thermique : températures,• protocoles : checksum, parités,• aberrations algorithmiques /dysfonctionnements : erreurs matérielles et logicielles

• reconfigure le(s) sous-système(s) défaillant(s)• mise en œuvre du sous-système redondant et mise hors service du sous-système en panne• repliement vers un mode sain -> Survie

LV

fonction de « service » paramétrée par la BDS capacité de reprogrammation tardive y compris en vol - complexité système (combinatoire des pannes et logique de déclenchement)


2- Description fonctionnelleReprogrammation/Support diagnostic en vol• gestion de l ’implantation mémoire et des versions logicielles (ex : Myriade - Pharao) • patch/dump : rechargement de tout ou partie du LV (ex : Hipparcos - ERS2 - SPOT1)• fonctions programmables à la demande (chargement de parties « libres » du logiciel ou de ses données)• reprogrammation simple des séquences interprêtées (ex : IASI - Stentor/E3000 - Rosetta - PHARAO)• suppression des fonctions inutiles (ex : suppression séquence automatique après le succès de la mise à poste - HELIOS1A)

LV

peu de code spécifique mais des règles de conception et codage permettent d ’assurer ces mises en œuvre en vol


Limitation des ressourcesmasse, consommation

Environnement spatialradiations, températures

3- Environnement : la problématique calculateur

Besoin de programmation efficaceEnvironnement de développement limitéSystème de développement spécifique

machine hôte/carte ciblecompilateur croisé

Processeurs

spécifiques

LV


Processeur Perf o TR Taille MemSPOT4 F9450 0,7 MI PS 256 KoSPOT5 MA3-1750 1 MI PS 512 KoPléiades ERC32 13 MI PS 6 MoPROTEUS MA3-1750 1 MI PS 512 KoMYRI ADE T805 4 MI PS 2 Mo

3-Environnement : Les Performances calculateur

LV Plateformes d ’observation et scientifiques


Processeur Perf o TR Taille MemE3000/Stentor MA3-1750 1 MI PS 256 KALPHABUS ERC32 13 MI PS 4 MoAGORA MA3-1750 1 MI PS 1 Mo

3- Environnement : Les Performances calculateurLV Plateformes télécom

LV lanceurProcesseur Perf o TR Taille Mem

Ariane V 68020 +68082

1,2 MI PS222 Kflops

1 Mo


Processeur Perf o TR Taille MemI ASI – IMSS MA3-1750 1 MI PS 1 MoI ASI - DPS ADSP 21020 15 MI PS /

45 MflopsPM = 768 KoDM = 1Mo

SPI - Integral MA3-1750 1 MI PSPHARAO ERC32 10 MI PS 10 Mo

3- Environnement : Les Performances calculateurLV Instruments


Le LV est le seul sous-système non redondé à bord = point de panne unique

• Comme tout logiciel, il est difficile à valider exhaustivement (combinatoire exponentielle)

• C ’est sur le LV que repose la plupart des évolutions tardives avant tir avec tous les risques associés (validation de la non-régression)

• ...y compris en vol : problématique de maintenance des moyens et compétence

Exemples d ’anomalies « célèbres » :– ARIANE 501– Survie SPOT3

4- La Sûreté de fonctionnement


En réponse à l ’ensemble des problématiques et contraintes posées, le LV est un métier d ’austérité et de rigueur :

• Processus de développement et de validation strict (ECSS)• Standards applicables pour chaque phase de développement et de

validation : objectifs, moyens, règles, documents• Traçabilité de boût en boût :

– suivi des exigences dans tout le cycle (phase par phase)– suivi des évolutions : anomalies, améliorations (gestion de configuration)

• Adéquation et pérennité des compétences et moyens pendant toute la durée du développement et la vie du satellite

• Investissement conséquent recherche / solutions innovantes

4-Sûreté de fonctionnement : une démarche « avant tout » qualité


5-Problématique de la maintenance en vol

Besoins

LVCorrection d’anomalies logiciellesImplémentation de palliatifs des anomalies systèmes/matériellesAmélioration de la missionExpériences embarquéesPalliatifs en fin de vie

Performances réduites du lien bord/solObservabilité limitée du comportement du logicielRechargement des modifications logiciel à sécuriserPerturbations de la mission à minimiser (disponibilité)


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

6- Cycle(s) de développement LV


Analyse besoins

Spécification

Architecture

Production

Validation

Qualification

Intégration

Activités avioniqueActivités logiciel

6- Cycle de développement théorique « en V »

URD

SRD

ADD

DDD UTR

ITR

SVTR


• Définition de plusieurs versions, « les incréments », du LV– par fonction : suivant des besoins des utilisateurs (ex : ordre

d ’intégration). – par niveau de validation suivant de la criticité des besoins planning.

• Chaque fonction élémentaire suit un cycle en V de développement.

Exemple SPOT5:– LV100 services généraux TM/TC : niveau fin TU (besoin intégration

calculateur HW/SW)– LV200 SCAO : fin essais fonctionnels SCAO (besoin essais avionique)– LV200 CU : fin essais fonctionnels CU (besoin intégration CU)– LV300 complet (besoin essais LV sur satellite)

6- Cycle(s) incrémentaux :


Analysis

Design

TranslationTesting

Next step preparation

Integrationtest Validation

TestingCoding

UnitTesting

IterativePrototypes

6- Exemple de processus en spirale


7.1 - Collecte des besoins7.2 - Spécification détaillée et l ’architecture LV7.3 - Production - Intégration : conception détaillée,

codage, TU, TI7.4 - Validation fonctionnelle7.5 - Qualification - Validation système

7.6 - La gestion des évolutions/non-régression7.7 - La maintenance en vol

7- Les phases de développement et de validation LV : objectifs et moyens


Analyse système globale => définir – La répartition bord/sol– L ’autonomie de la mission– La fiabilité/disponibilité : stratégie de surveillance et reconfiguration– Les constituants de l’architecture informatique matérielle et logicielle– La répartition matériel/logiciel– Les informations échangées bord/sol et bord/bord

Rôle, interfaces, performances de chaque élément du système URD + ICD

Démarrage des développements

7.1- Collecte et Analyse des besoins


7.2.1 - Spécification détaillée- Modélisation

7.2.2 - Architecture- Architecture statique- Architecture dynamique- Interpréteurs embarqués- Production des données BDS

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


• Exprimer tout ce que doit faire le logiciel, mais sans sur-spécifier– Traduction informatique d ’exigences systèmes (SCAO, thermique, C&C)– Problématique de terminologie dûs aux différences de culture de chaque métier– Traçabilité des exigences vis à vis des spécifications de besoin

• Exprimer les exigences temporelles– Durée à respecter entre l ’acquisition d ’une mesure et l ’envoi d ’une commande– Retrait du contenu d ’une TC avant écrasement par la TC suivante– Datation d ’un événement (--> 1 ms)

• Vérifier la faisabilité et la testabilité de l ’ensemble de ces exigences

– Nécessité d ’exprimer dans un langage formalisé, éventuellement exécutable – Numérotation des exigences - matrice de testabilité

7.2.1- Spécifications

LV


• Modèles descriptifs – formaliser la représentation de spécifications, de conceptions

• Modèles exécutables (logiciels ou systèmes)- modèles de dimensionnement et de performances (SES/workbench, Opnet)- modèles comportementaux (UML, SDL)

vue précoce et exécutable du système - détection d ’erreurs, incomplétudes, incohérences - gain important en validation

analyses comparatives, évaluation de l’impact d ’une modification amélioration de la communication meilleure confiance dans le système

utilisation limitée pour l’instant pendant la phase de spécification LV

7.2.1-Spécifications : La modélisation

LV


7.2.1- Spécifications : Modélisation de performances

Pour un logiciel ou un système


Exemple de résultats


STATECHARTSLes diagrammes d’état servent à représenter les états qu’un objet traverse en réponse à des stimuli, ainsi que ses réponses ou actions. Une machine à états est rattachée à une classe ou à une méthode.

CLASS DIAGRAMLe diagramme de classes représente l’architecture objet logique du système, c’est à dire la structure statique du modèle.

SEQUENCE DIAGRAMCe diagramme sert à dérouler un scénario correspondant en général à un cas d’utilisation. Il met en évidence les interactions entre les éléments du système.

USE CASECe diagramme sert à modéliser les cas d’utilisation du système, c’est à dire les interactions entre des acteurs externes et les services identifiés. Exemple :

Utilisateur

Enregistreur numérique

Ecouter un message

Enregistrer un message

Effacer un message

Enregistreur numériqueUtilisateur Haut-parleurSystème

Jouer message

Jouer son

Afficher progression

Arrêter

Arrêter son

TEMPS

Controleur

Haut_parleurMicro

Interface_utilisateur

Jouer()Arreter()

ClavierAfficheurAttente

EnregistreJoue

Attente

EnregistreJoue

DemarrerEnregistrer

Stop

Fin

Les principaux diagrammes UML (1/2)


Les principaux diagrammes UML (2/2)

Diagramme de collaboration

(communication entre objets)

Diagramme de déploiement(organisation du

matériel)


Exemple de diagramme de séquenceSCA Charge UtileGestion

Bord

Alarme panne équipement

Alarme survie

TEMPS

Commande passage survie

Mode Normal Mode Normal

Mode Survie

Mode Survie

Reconf avec panne Désactiver Charge Utile


7.2.2- Architecture Statique : notion de

couches

SCAO - Contrôle thermique - CU

TM/TC - Surveillances / Reconfigurations - Gestion modes

Application

Services

OS +Drivers

Matériel

Le logiciel est structué en plusieurs couches, de la plus proche du matériel à la plus indépendante :

LV


Parent

OP1

OP2

OP3 Enfant_1

AVANTAGES :-Règles de structuration

- Principe d ’abstraction

- Encapsulation des données

- ModularitéMaintenabilité

• L ’architecture repose sur des objets (Méthode HOOD) qui offrent des services : OP1,OP2, OP3• Les objets (parents) sont décomposés en objets (fils) ...

7.2.2- Architecture statique : notion d ’objet


Logiciel Réactif : qui réagit aux stimulations de l ’environnement

son fonctionnement est lié au temps

- Le logiciel est organisé en tâches- La ressource processeur est partagée entre ces tâches

Comment ?

- séquenceur périodique: SPOT ( 3 tâches périodiques)

- exécutif préemptif : Pléiades - Proteus (>20 tâches périodiques et apériodiques)

7.2.2- Architecture dynamique

LV


avertir la CPU qu’un événement s’est produit

• Quand une interruption survient, le processeur déroute l’exécution à un programme dédié (handler d’interruption)

• A fin du handleur d’interruption, le contrôle est rendu au programme interrompu

• Des priorités sont attribuées aux différentes IT

Sources d’interruptions : timers (ex : horloge), entrées/sorties asynchrones, matériels, …

7.2.2- Architecture dynamique : les interruptions

IT niveau 0IT niveau 2IT niveau 5


IT 64 Hz

IT 1 Hz

Tâche 32 Hz

Tâche 8 Hz

Tâche 1 Hz

7.2.2- Architecture dynamique Séquenceur Périodique (exemple SPOT)

LV


• Exécutif = Logiciel de gestion de l ’attribution du processeur aux tâches et gestion des ressources. Exemples : ( ASTRES, OSTRALES, VxWorks, RTEMS…)

– Fonctionalités de gestion des tâches • Encapsulation des handlers d’interruptions associés aux évènements

externes• Ordonnancement des tâches en fonction des priorités définies et du

schéma d’ordonnancement (pre-emptif, time-slicing…)

– Fonctionalités de gestion des ressources• Gestion mémoire (zones privées et publiques)

• Messages and sémaphores (communication entre tâches)

LV

7.2.2- Architecture dynamique : Exécutif temps réel


- A chaque tâche est affectée une priorité- A tout instant, la tâche qui s ’exécute est la tâche prête de plus haute priorité(la tâche en cours peut être pré-emptée …)

Exécutif temps réel : les états des tâches

En attenteressource, évt

En cours

Prête Différéedélai


Les tâches peuvent être :Périodiques : périodes et phases multiples de l ’horloge Apériodiques : déclenchées par la présence d ’un événement

Exemple : Périodique : traitements répétitifs, surveillances +Apériodique : communications, événements, exceptions

La vérification de la possibilité « d ’ordonnancer » toutes les tâches :

- a priori : par calcul- a posteriori : par observation

Exécutif temps réel : les types de tâches


Besoin = évolutivité/souplesse de reprogrammation par TC au sol et/ou en vol sans recours au patch/rechargement LV– langage dédié aux spécificités de la fonction à réaliser :

• acquisition de données• envoi de commandes• traitement / logique simples• délais

– modifications réalisées en AIT ou en vol par des non-spécialistes LV. Validation plus légère que des évolutions LV classiques

7.2.2- Architecture : Interpréteurs embarqués

LV

Exemples : • séquences automatiques satellite SPOT4 - SPOT5• contrôle de vol lanceur Ariane, mise en œuvre instruments IASI et PHARAO, • mise en œuvre Charge Utile SPOT5


La Base de Données Système (BDS) décrit :– Ensemble des paramètres système : valeurs– Formats TC et TM : agencement des paramètres, codage– Surveillances bord : seuils, filtres, valeurs attendues– Les programmes interprétés

7.2.2- Architecture : Production des données BDS

LV

Ces données sont produites automatiquement -génération de code- dans le LV au moyen d ’un outil appelé Programme de Production (PP) :• des données et structures de données (déclaration des types et

des variables associées), pour les surveillances, les paramètres TM/TC, les formats TM/TC, les paramètres système.

• initialisation des valeurs (par assignation), dont les paramètres système et les programmes interprétés (table de valeurs)...


• Chaque service offert par l’objet est décrit en détail• Codage (Ada ou C - assembleur si nécessaire) en

conformité avec les standards• Utilisation de compilateurs croisés/natifs • Exécutable produit à partir de :

– Code source, données logiciel et données communes (BDS)

7.3 - La phase de production et d ’intégration

ParentOP1

OP2

OP3

Enfant_1

Conception détaillée, codage


• Chaque service ou « module » du logiciel est testé indépendamment

• Objectif = couverture 100% code, branches, décisions (en fonction du niveau de criticité)


ParentOP1

OP2

OP3

Enfant_1

Tests unitaires

• Le module sous test est activé par un module de test (driver)• Les modules appelés par le module sous test sont simulés par

des modules de test (stubs)• Les tests sont joués en natif dans l ’environnement de

développement ou en croisé sur la machine cible• Le traitement des traces d ’exécution permet de déterminer la

couverture atteinte


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


ParentOP1

OP2

OP3

Enfant_1

Tests d ’intégration

• Le module sous test est activé par un module de test (driver)• Les modules appelés par le module sous test sont les

modules réels• Les tests sont joués en natif dans l ’environnement de

développement ou en croisé sur la machine cible• Une combinatoire finie -non exhaustive- des valeurs

numériques est choisie (min, max, médiane)


Outil de miseau point

Carte processeur

Station dedéveloppement

Noyau

Applicatif

Liaison série

Liaison Ethernet

TTY

7.3 - La phase de production et d ’intégrationMoyens de test TU/TI

LV


• Validation par fonction : essais « boîte noire »– Comportement fonctionnel et

algorithmique pur– Vérification de toutes les

exigences « unitaires » de la SRDSimulateur natif ou hybride

Validation fonctionnelle globale :– Comportement nominal– Comportement en

présence d’erreurs– Essais aux limites– Vérification des exigences

de couplage entre fonctions SRD

Simulateur natif ou hybride

• Validation HW/SW– Performances TR + numériques– Vérification de toutes les exigences

des ICD– Interfaces calculateur– Gestion mémoireSimulateur hybride - sonde temps réel

7.4- La validation fonctionnelle


Target Computer

RS 232 Ethernet network

LICE PC

Host Computer (SUN Workstation)

LICE Probe

CPU BoardChild board

L’outil LICE : sonde temps réel• Spécifiée par le CNES

• Le logiciel est instrumenté

• Ecriture d’un entier à une adresse de sortie correspondant à la sonde LICE

• Collectés et datés par LICE et envoyés vers le PC pour postraitement (chronogrammes, performances)


La visualisation dynamique


• Validation chaîne fonctionnelle– Adéquation des besoins LV aux

matériel réel « sur la table »– Vérification de toutes les

exigences de niveau URDBanc avionique - banc système

• Validation système QT/QO– adéquation des besoins LV et

du satellite aux opérations– Couplage bord/solBanc système + satellite• Validation LV sur Satellite

– Adéquation des besoins LV aux spécifications satellite et au matériel de vol

– Opérabilité/commandabilité des scénarios proches du vol

Satellite

7.5- La validation système « qualification »


De nombreuses évolutions - plusieurs centaines- (corrections d ’anomalies, évolutions fonctionnelles : interfaces, besoins mission) à gérer tout au long du cycle de développement et hors développement.– Les évolutions sont groupées en lot de modification donnant lieu à

production d ’une nouvelle version logicielle (si évolutions postérieures à la production)

– Gestion des impacts des évolutions exigence par exigence grâce à la traçabilité : SRD, ADD, DDD, code

– Rejeu des essais strictement nécessaires impactés par l ’évolution toujours grâce à la traçabilité (TU, TI, TF, …)

– Définition d ’essais fonctionnels de « non-régression » ou de bonne santé = couverture des effets de bord sur les parties non modifiées du LV.

7.6- Gestion des évolutions / non-régressions LV


Support LV aux équipes opérationnelles : – Investigations anomalies– Evolutions : corrections anomalies ou évolutions fonctionnelles

• Définition et mise en œuvre des évolutions nécessaires (voir §7.6)• Vérification au sol de la procédure de chargement de la nouvelle version ou du

patch (sur banc système)• Chargement effectif et vérification du comportement nominal

– Cycle MIM (Maintien Image Mémoire) périodique (exemple SPOT = 6 mois)• Produire une version logicielle reflétant les évolutions réalisées sur une période

donnée : patchs, chargement de paramètres, … : entrainement des équipes - maintien de la compétence

• Vérifier le bon fonctionnement de tous les moyens : atelier de développement, moyens d ’essais : anticiper et gérer les obsolescences si nécessaire

• Vérifier la capacité opérationnelle à recharger le LV et revenir en mode routine : entrainement des équipes - maintien de la compétence

7.7- La maintenance en vol LV


8- Difficultés (1/3)

LV• Difficulté de planning : développement coincé entre - le besoin d’un niveau de spécification suffisant

développement parallèle des sous-systèmes et du logiciel- des livraisons urgentes pour intégrations- des évolutions fréquentes

• Augmentation très significative du volume et de la complexité du logiciel

- augmentation des attentes- autonomie : de plus en plus de fonctions à bord

• Différence de culture entre le système, les sous-systèmes et le LV- efforts de communication- documents d’interface

LVBesoins AITSpécifications

temps


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



• 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



• Augmentation autonomie/intelligence embarquée : stratégie de développement/validation de logiciels de plus en plus complexes (cohabitation temps réel dur / mou)

9- Conclusion : perspectives LV

• Evolutions calculateurs (obsolescence composants) -> utilisation COTS /systèmes multi-processeurs / cache : problématique de tolérance aux fautes, perte déterminisme exécution - stratégie de validation à définir

• Amélioration processus de capture des besoins : démarche co-ingénierie système-logiciel, déploiement méthodes formelles et modélisation amont

• Architectures génériques réutilisables indépendantes du matériel : développement composants – Time and Space Partitionning

• Standardisation des protocoles et méthodes = normalisation (MP, ECSS) -> synergie avec ESA et les industriels

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


Exemples de projets


Les logiciels de vol centraux SPOT

• Lancement– Mars 98

• Logiciel applicatif – ASTRIUM

• Processeur– F9450

• Langage– assembleur

• Taille code– 31 kmots (16 bits)

• Taille données– 32 kmots (16 bits)

• Lancement– Mai 2002

• Logiciel applicatif – ASTRIUM

• Processeur– MA3 1750

• Langage– Ada 83 + assembleur

• Taille code– 64 kmots (16 bits)

• Taille données– 160 kmots (16 bits)

SPOT5SPOT4 Observation de la terre


PROTEUS

• Lancement – 7 décembre 2001

• Logiciel applicatif P/F– Alcatel

• Calculateur et couches basses– SAAB Ericsson Space



• Conception– HOOD

• O.S. – Ostrales

• Nombre de lignes– 25000

• Taille code– 100 kmots

• Taille données– 100 kmots

PlateForme réutilisable pour l’observation scientifique de la terre, des étoiles, de la couverture nuageuse, …


Jason1, 7 déc 2001, AltimétrieCoopération NASA JPL

Calipso, début 2005, LidarCoopération NASA LaRC

Corot, début 2006, AstronomieCoopération européenne

PROTEUS : les missions (1/2)


SMOS, Radiomètre bande LCoopération ESA

Megha-Tropiques, Cycle de l ’eauCoopération ISRO (Inde)

Jason2

PROTEUS : les missions (2/2)


• Plate-forme ESA (XMM)

• Charge Utile : 4 instruments :

– SPI : SPectromètre Integral– IBIS : Imager on Board Integral– JEM-X : Joint European X-ray

Monitor– OMC : Optical Monitoring Camera

INTErnational Gamma Ray Astrophysics LaboratoryINTEGRAL


• Maîtrise d’œuvre interne de l’instrument principal (SPI)

INTEGRAL : schéma d’ensemble

Calculateur P/F

DigitalProcessi

ng Equipme

nt

Photons et rayons gamma

Equipements de collecte des

données

SOL

TM TC

Calculateur DPE


• Responsable du logiciel de vol du calculateur DPE• Définition du besoin• Spécification logicielle• Développement logiciel (DIAF-Transiciel)• Intégration/tests sur les modèles (CNES) :

=> conduite des essais sur simulateur

=> participation aux essais sur matériel réel

• Forte implication dans les choix système Gestion Bord• Supports ponctuels

• Expertise SW/HW pendant l’appel d’offres• Expertise compression • Utilisation des moyens de laboratoire SEA/IL pendant

la phase B• Modélisations • Participation à des revues

Logiciel SPI : activités du CNES


Logiciel du DPE

• Logiciel applicatif – DIAF/Transiciel et 3IP/CS

• Calculateur – CRISA

• Couches basses– GMV


• Conception– HOOD


• O.S. – Astres 1750

• Nombre de lignes– 38000


Matériel (CRISA)

Log. base (GMV)

Log. applicatif CNES (SEA/IL)DIAF/Transiciel

}{

Com

mun

s aux

4 in

stru

men

ts

Conduite de tests (EGSE)

CESR

Mire

CESR

Berkeley

DSS & MPE (Allemagne)

CEA

ESA

Inté

grat

ion

Sate

llite

(A

leni

a)

Mission OperationCentre (ESOC)

Integral ScienceData Centre

SPI : interfaces

Calculateur DPE


Cons

ultat

ion

LV (f

ev)

RDP

SPI (

dec)

RCS

(sept

)

Répo

nse A

ppel

d'Offr

e (oc

t)

Appe

l d'O

ffre (

juin

)

Livr

aison

log.

App

licati

f (ju

ill)

PDR

(jan)

Livr

aison

SEM

(dec

)

SRR

(oct)

Kick

Off

(juil)

Rece

tte lo

g. ap

plica

tif (j

uill)

Livr

aison

EM

(avr

il)

Test

Fonc

tionn

el M

odèle

de v

ol (s

ept)

Livr

aison

Mod

èle d

e vol

(m

ai)

Tir (

octo

bre 2

002)

SPI : chronologie

1994 1995 1996 1997 2001200019991998 2002


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

Documents

Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial