probl matique et retour d exp rience du d veloppement des logiciels embarqu s pour le spatial
Download
Skip this Video
Download Presentation
Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial

Loading in 2 Seconds...

play fullscreen
1 / 77

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


  • 83 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Problématique et retour d’expérience du développement des Logiciels embarqués pour le spatial' - vala


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
probl matique et retour d exp rience du d veloppement des logiciels embarqu s pour le spatial

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 20111

slide2

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 20112

1 introduction le cnes centre national d etudes spatiales
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 20113

1 introduction le cnes chiffres cl s
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 20114

1 introduction les missions spatiales europ ennes
1-Introduction : les missions spatiales européennes
  • Les lanceurs et véhicules de transport spatial : Ariane, ATV

ETR’11 – Best le 29 août 20115

1 introduction les missions spatiales europ ennes1
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 20116

slide7

LV

1- Introduction : les orbites et leurs contraintes

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

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

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

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

ETR’11 – Best le 29 août 20117

1 introduction principales caract ristiques des logiciels embarqu s
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 20118

1 introduction au c ur du syst me bord sol

LV

Calculateur

PF

Calculateur

CU

Eq-1

Eq-2

Satellite

Calculateur

Sol

Centre de Contrôle

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 !

ETR’11 – Best le 29 août 20119

1 introduction logiciel temps r el

LV

Calculateur

PF

Calculateur

CU

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.

ETR’11 – Best le 29 août 201110

slide11

LV

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

ETR’11 – Best le 29 août 201111

slide12

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 201112

slide13

LV

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

ETR’11 – Best le 29 août 201113

slide14

LV

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

ETR’11 – Best le 29 août 201114

slide15

LV

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 201115

slide16

LV

2- Description fonctionnelle

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

fonction « applicative » cyclique = séquenceur d ’ordres interprétés (commandes - délais - vérifications - logique simple)

capacité de reprogrammation simple en fonction des missions (ex : CDV Ariane V ou Séquence Automatique SL)

ETR’11 – Best le 29 août 201116

slide17

LV

2- Description fonctionnelle

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

fonction « applicative » supportée par un interpréteur de séquences élémentaires (commandes bas niveau - délais - vérifications)

capacité de mémorisation du plan de travail (chargé par TC) et d ’exécution différée en continu sur l ’orbite (satellites orbite basse)

capacité / souplesse de reprogrammation tardive dans le développement, ou en vol - meilleure indépendance du LV vis à vis de la mission (ex : IASI - SPOT5 / HELIOS 2 - Stentor)

Traitement numérique + ou – complexe sur les données mission

ETR’11 – Best le 29 août 201117

slide18

LV

2- Description fonctionnelle

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

Modes LVC SPOT5 :

fonction « de service » simple qui mémorise les états des ressources, et des fonctions et du satellite.

= Chef d ’orchestre en charge de cadencer les activités LV

ETR’11 – Best le 29 août 201118

slide19

LV

2- Description fonctionnelle

  • Isolation et passivation des pannes
  • surveille les paramètres sous-systèmes et systèmes dans des intervalles de valeurs attendues
    • consommation électrique : tensions, courants,
    • thermique : températures,
    • protocoles : checksum, parités,
    • aberrations algorithmiques /dysfonctionnements : erreurs matérielles et logicielles
  • reconfigure le(s) sous-système(s) défaillant(s)
    • mise en œuvre du sous-système redondant et mise hors service du sous-système en panne
    • repliement vers un mode sain -> Survie

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 201119

slide20

LV

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 201120

slide21

LV

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é

ETR’11 – Best le 29 août 201121

3 environnement les performances calculateur
3-Environnement : Les Performances calculateur

LV Plateformes d ’observation et scientifiques

ETR’11 – Best le 29 août 201122

3 environnement les performances calculateur1
3- Environnement : Les Performances calculateur

LV Plateformes télécom

LV lanceur

ETR’11 – Best le 29 août 201123

3 environnement les performances calculateur2
3- Environnement : Les Performances calculateur

LV Instruments

ETR’11 – Best le 29 août 201124

4 la s ret de fonctionnement
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 201125

4 s ret de fonctionnement une d marche avant tout qualit
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 201126

slide27

LV

5-Problématique de la maintenance en vol

  • Correction d’anomalies logicielles
  • Implémentation de palliatifs des anomalies systèmes/matérielles
  • Amélioration de la mission
  • Expériences embarquées
  • Palliatifs en fin de vie

Besoins

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 201127

6 cycle s de d veloppement lv
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 201128

slide29

Intégration

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

URD

Analyse besoins

Qualification

Activités avionique

Activités logiciel

SRD

Spécification

Validation

SVTR

ADD

ITR

Architecture

DDD

UTR

Production

ETR’11 – Best le 29 août 201129

6 cycle s incr mentaux
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 201130

slide31

6- Exemple de processus en spirale

Translation

Testing

Integration

Unit

Testing

test

Coding

Validation

Testing

Iterative

Prototypes

Next step preparation

Design

Analysis

ETR’11 – Best le 29 août 201131

7 les phases de d veloppement et de validation lv objectifs et moyens
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 201132

slide33

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 201133

7 2 sp cification d taill e et architecture lv
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 201134

slide35

LV

7.2.1- Spécifications

  • Exprimer tout ce que doit faire le logiciel, mais sans sur-spécifier
    • Traduction informatique d ’exigences systèmes (SCAO, thermique, C&C)
    • Problématique de terminologie dûs aux différences de culture de chaque métier
    • Traçabilité des exigences vis à vis des spécifications de besoin
  • Exprimer les exigences temporelles
    • Durée à respecter entre l ’acquisition d ’une mesure et l ’envoi d ’une commande
    • Retrait du contenu d ’une TC avant écrasement par la TC suivante
    • Datation d ’un événement (--> 1ms)
  • 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é

ETR’11 – Best le 29 août 201135

slide36

LV

7.2.1-Spécifications : La modélisation

  • Modèles descriptifs
    • formaliser la représentation de spécifications, de conceptions
  • Modèles exécutables (logiciels ou systèmes)
    • modèles de dimensionnement et de performances (SES/workbench, Opnet)
    • modèles comportementaux (UML, SDL)
          • vue précoce et exécutable du système

- détection d ’erreurs, incomplétudes, incohérences

- gain important en validation

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

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

ETR’11 – Best le 29 août 201136

slide37

7.2.1- Spécifications : Modélisation de performances

Pour un logiciel ou un système

ETR’11 – Best le 29 août 201137

slide38

Exemple de résultats

ETR’11 – Best le 29 août 201138

slide39

Utilisateur

Système

Haut-parleur

Jouer message

Jouer son

Afficher progression

Arrêter

Arrêter son

TEMPS

Les principaux diagrammes UML (1/2)

ETR’11 – Best le 29 août 201139

slide40

Diagramme de déploiement

(organisation du matériel)

Les principaux diagrammes UML (2/2)

Diagramme de collaboration

(communication entre objets)

ETR’11 – Best le 29 août 201140

slide41

Exemple de diagramme de séquence

SCA

Gestion

Bord

Charge Utile

Mode Normal

Mode Normal

Alarme panne

équipement

Commande passage survie

Mode Survie

Alarme survie

Mode Survie

TEMPS

Reconf avec panne

Désactiver Charge Utile

ETR’11 – Best le 29 août 201141

7 2 2 architecture statique notion de couches

LV

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

ETR’11 – Best le 29 août 201142

slide43

Parent

OP1

OP2

OP3

Enfant_1

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é

ETR’11 – Best le 29 août 201143

slide44

LV

7.2.2- Architecture dynamique

  • Logiciel Réactif : qui réagit aux stimulations de l ’environnement
  • son fonctionnement est lié au temps
    • -Le logiciel est organisé en tâches
    • - La ressource processeur est partagée entre ces tâches
  • Comment ?
    • - séquenceur périodique: SPOT ( 3 tâches périodiques)
    • - exécutif préemptif : Pléiades - Proteus (>20 tâches périodiques et apériodiques)

ETR’11 – Best le 29 août 201144

slide45

IT niveau 0

IT niveau 2

IT niveau 5

7.2.2- Architecture dynamique : les interruptions

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

  • Quand une interruption survient, le processeur déroute l’exécution à un programme dédié (handler d’interruption)
  • A fin du handleur d’interruption, le contrôle est rendu au programme interrompu
  • Des priorités sont attribuées aux différentes IT

Sources d’interruptions : timers (ex : horloge),

entrées/sorties asynchrones, matériels, …

ETR’11 – Best le 29 août 201145

slide46

LV

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

ETR’11 – Best le 29 août 201146

slide47

LV

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

  • Exécutif = Logiciel de gestion de l ’attribution du processeur aux tâcheset 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)

ETR’11 – Best le 29 août 201147

slide48

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

- A chaque tâche est affectéeune 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

ETR’11 – Best le 29 août 201148

slide49

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 201149

slide50

LV

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

ETR’11 – Best le 29 août 201150

slide51

LV

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

ETR’11 – Best le 29 août 201151

slide52

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

Conception détaillée, codage

  • Chaque service offert par l’objet est décrit en détail
  • Codage (Ada ou C - assembleur si nécessaire) en conformité avec les standards
  • Utilisation de compilateurs croisés/natifs
  • Exécutable produit à partir de :
    • Code source, données logiciel et données communes (BDS)

Parent

OP1

OP2

OP3

Enfant_1

ETR’11 – Best le 29 août 201152

slide53

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

Tests unitaires

  • Chaque service ou « module » du logiciel est testé indépendamment
  • Objectif = couverture 100% code, branches, décisions (en fonction du niveau de criticité)

Parent

OP1

OP2

OP3

Enfant_1

  • Le module sous test est activé par un module de test (driver)
  • Les modules appelés par le module sous test sont simulés par des modules de test (stubs)
  • Les tests sont joués en natif dans l ’environnement de développement ou en croisé sur la machine cible
  • Le traitement des traces d ’exécution permet de déterminer la couverture atteinte

ETR’11 – Best le 29 août 201153

slide54

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

Tests d ’intégration

  • Intégration « bottom-up » des modules depuis les couches basses (interfaces matérielles) jusqu ’aux couches applicatives
  • Objectif = couverture 100% des interfaces (en fonction du niveau de criticité)

Parent

OP1

OP2

OP3

Enfant_1

  • Le module sous test est activé par un module de test (driver)
  • Les modules appelés par le module sous test sont les modules réels
  • Les tests sont joués en natif dans l ’environnement de développement ou en croisé sur la machine cible
  • Une combinatoire finie -non exhaustive- des valeurs numériques est choisie (min, max, médiane)

ETR’11 – Best le 29 août 201154

slide55

LV

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

Moyens de test TU/TI

ETR’11 – Best le 29 août 201155

slide56
Validation par fonction : essais « boîte noire »

Comportement fonctionnel et algorithmique pur

Vérification de toutes les exigences « unitaires » de la SRD

Simulateur natif ou hybride

Validation fonctionnelle globale :

Comportement nominal

Comportement en présence d’erreurs

Essais aux limites

Vérification des exigences de couplage entre fonctions SRD

Simulateur natif ou hybride

7.4- La validation fonctionnelle

  • Validation HW/SW
    • Performances TR + numériques
    • Vérification de toutes les exigences des ICD
    • Interfaces calculateur
    • Gestion mémoire

Simulateur hybride - sonde temps réel

ETR’11 – Best le 29 août 201156

slide57

LICE Probe

LICE PC

Target Computer

Host Computer (SUN Workstation)

Child board

CPU Board

RS 232

Ethernet network

L’outil LICE : sonde temps réel

  • Spécifiée par le CNES
  • Le logiciel est instrumenté
  • Ecriture d’un entier à une adresse de sortie correspondant à la sonde LICE
  • Collectés et datés par LICE et envoyés vers le PC pour postraitement (chronogrammes, performances)

ETR’11 – Best le 29 août 201157

slide58

La visualisation dynamique

ETR’11 – Best le 29 août 201158

slide59
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

7.5- La validation système « qualification »

  • Validation LV sur Satellite
    • Adéquation des besoins LV aux spécifications satellite et au matériel de vol
    • Opérabilité/commandabilité des scénarios proches du vol

Satellite

ETR’11 – Best le 29 août 201159

slide60

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 201160

slide61

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 201161

slide62

LV

temps

LV

Spécifications

Besoins AIT

8- Difficultés (1/3)

  • Difficulté de planning : développement coincé entre
    • le besoin d’un niveau de spécification suffisant
      • développement parallèle des sous-systèmes et du logiciel
    • - des livraisons urgentes pour intégrations
    • - des évolutions fréquentes
  • Augmentation très significative du volume et de la complexité
  • du logiciel
    • - augmentation des attentes
    • autonomie : de plus en plus de fonctions à bord
  • Différence de culture entre le système, les sous-systèmes et le LV
    • - efforts de communication
    • - documents d’interface

ETR’11 – Best le 29 août 201162

slide63

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 201163

slide64

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 201164

slide65

LV

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) -> 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ériquesréutilisables indépendantes du matériel : développement composants – Time and Space Partitionning
  • Standardisationdes 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 201165

slide66
Exemples de projets

ETR’11 – Best le 29 août 201166

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)

Les logiciels de vol centraux SPOT

SPOT5

SPOT4

Observation de la terre

ETR’11 – Best le 29 août 201167

slide68

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
  • Conception
    • HOOD
  • O.S.
    • Ostrales
  • Nombre de lignes
    • 25000
  • Taille code
    • 100 kmots
  • Taille données
    • 100 kmots

ETR’11 – Best le 29 août 201168

slide69

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 201169

slide70

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 201170

slide71

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 201171

slide72

INTEGRAL : schéma d’ensemble

Equipements de collecte des données

  • Maîtrise d’œuvre interne

de l’instrument principal(SPI)

Calculateur DPE

Photons et

rayons gamma

Digital

Processing Equipment

Calculateur

P/F

TM

TC

SOL

ETR’11 – Best le 29 août 201172

slide73

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 201173

slide74

Logiciel du DPE

  • Logiciel applicatif
    • DIAF/Transiciel et 3IP/CS
  • Calculateur
    • CRISA
  • Couches basses
    • GMV
  • Processeur
    • MA3 1750
  • Conception
    • HOOD
  • Langage
    • Ada 83 + assembleur
  • O.S.
    • Astres 1750
  • Nombre de lignes
    • 38000

ETR’11 – Best le 29 août 201174

slide75

DSS & MPE

(Allemagne)

CESR

CEA

Berkeley

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)

ETR’11 – Best le 29 août 201175

slide76

1994

1995

1996

1997

1998

1999

2000

2001

2002

SPI : chronologie

Appel d\'Offre (juin)

RCS (sept)

RDP SPI (dec)

Consultation LV (fev)

Kick Off (juil)

SRR (oct)

PDR (jan)

Livraison SEM (dec)

Livraison EM (avril)

Réponse Appel d\'Offre (oct)

Tir (octobre 2002)

Livraison log. Applicatif (juill)

Livraison Modèle de vol (mai)

Recette log. applicatif (juill)

Test Fonctionnel Modèle de vol (sept)

ETR’11 – Best le 29 août 201176

slide77

SPI : la phase de maintenance du logiciel

  • mai 2001 livraison de l’instrument complet
  • janvier 2002 mise à jourduLV
  • octobre 2002 lancement
  • février 2003 mise à jourLV : réglages, problèmes mineurs
  • septembre 2003 mise à jourLV: 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 201177

ad