On Board Computer Subsystem.pdf

Pr. A. Addaim
UIR/SAE Plan
Chapter 2 : Satellites Platform
C i ti b t
Chapter 2 : Satellites Platform
 Communication subsystem
 Telemetry, Tracking Command Subsystem
y g y
 Thermal Control Subsystem
P S l S b
 Power Supply Subsystem
 On‐Board Computer Subsystem
p y
 Orbit and Attitude Control subsystem
1

Pr. A. Addaim
ENSA ‐ Kenitra On‐Board Computer Subsystem
Introduction
 On s’interessera aux fonctions de la gestion bord : sur un satellite, seul un
sous-ensemble de ces fonctions est implanté à bord le reste étant réalisé au
sous ensemble de ces fonctions est implanté à bord, le reste étant réalisé au
sol.
 En générale, plus un satellite est autonome (ex : sonde lointaine) et plus il
 En générale, plus un satellite est autonome (ex : sonde lointaine) et plus il
sera nécessaire d'implanter un grand nombre de ces fonctions à bord.
Inversement, pour un satellite en visibilité permanente du sol et à faible
autonomie (ex : satellite de télécommunications géostationnaire), seul un
( g ),
sous-ensemble réduit sera réalisé à bord.
 Pour une mission donnée, le niveau d'autonomie bord doit prendre en
compte les contraintes de la mission. Exemple : temps de visibilité

Pr. A. Addaim
On‐Board Computer Subsystem
Introduction
 Vu les contraintes de la mission d ’un microsatellite LEO (temps
de visibilité, temps de transmission des données de/vers le satellite,
p
disponibilité requise, etc.), il sera nécessaire d'implanter un grand
nombre de fonctions à bord pour que le microsatellite soit plus
autonome.
autonome.
 Il faut réaliser un compromis entre le coût d'implantation à bord
(matériel + logiciel) de cette autonomie et les gains en performances
(matériel + logiciel) de cette autonomie et les gains en performances
attendus (réduction des coûts d'opération au sol, amélioration de la
sécurité et de la disponibilité, réduction des débits de TM/TC, etc.).

Pr. A. Addaim
 Les fonctions d ’un calculateur de bord sont :
initialisation des différents sous systèmes dans un état sûr
– initialisation des différents sous-systèmes dans un état sûr.
– La réception des télécommandes, leur décodage et leur
distribution.
– Acquisition des données de différents sous-systèmes de la
plate-forme et de la charge utile.
gestion du temps bord
– gestion du temps bord.
– stockage des données pendant la période de non visibilité,
– transmission des données de télémesure vers le sous-
système TM/TC durant la période de visibilité.
– Surveillance, détection de pannes et reconfiguration.
Implémentation d contrôle d’altit de de la distrib tion
– Implémentation du contrôle d’altitude, de la distribution
d’énergie et du contrôle thermique.
– traitement des données de la mission.

Pr. A. Addaim
CONCEPTION DU LOGICIEL DE VOL
• L ’architecture informatique est organisée autour d'un
calculateur central, gérant d'un bus de données sur lequel sont
connectés des abonnés : sous-systèmes, charges utiles ou
équipements Ces abonnés peuvent être construits autour d'un
équipements. Ces abonnés peuvent être construits autour d un
microprocesseur.
• Le logiciel de vol du sous-système de calculateur de bord a
g y
essentiellement à gérer des activités de :
– communication
– gestion/surveiliance/reconfiguration
– traitement

Pr. A. Addaim
CONCEPTION DU LOGICIEL DE VOL (suite)
– Il réalise l'exécution de l'ensemble des tâches logicielles de
gestion bord (en particulier les tâches de surveillance et de
f )
reconfiguration).
– Il a en charge la gestion de l'artère de données (bus). Il
génère les interrogations sur le bus vers les autres sous-
génère les interrogations sur le bus vers les autres sous-
systèmes pour acquérir les données de télémesures devant
être multiplexées dans le format TM.
– Il analyse les données TC
– Il génère le format de télémesure à partir des informations
ll té d l t tè t i t
collectées dans les autres sous-systèmes et en interne.
– Il contient l'horloge bord, gère le temps bord et les délivre aux
autres sous-systèmes à travers le bus.
autres sous systèmes à travers le bus.

Pr. A. Addaim
Contraintes
Contraintes
Limitation des ressources
• Les calculateurs embarqués au même titre que tous les
équipements du véhicule spatial sont soumis à de sérieuses
limitations en terme de poids, volume, consommation. Ces
limitations vont se traduire pour le logiciel en contraintes pour ce
i
qui concerne:
– l'occupation mémoire
l i d l l
– la puissance de calcul
• Ces contraintes conduisent à choisir des langages efficaces
pour le codage du logiciel
pour le codage du logiciel.

Pr. A. Addaim
Contraintes
• Les processeurs et les mémoires des calculateurs comme
Environnement spatial
• Les processeurs et les mémoires des calculateurs comme
l'électronique des équipements embarqués impose un grand
nombre de contraintes:
– Radiations: résister à une dose cumulée entre 5 et 20 Krads
suivant les missions et le blindage. Résister aux ions lourds du
point de vue Latch up (destruction du composant) et upsets
point de vue Latch-up (destruction du composant) et upsets
(basculements logiques de cellules mémoire).
– Mécaniques : Vibrations au moment du lancement.
q
– Thermique: nombreux cyclages thermiques pendant la mission
et températures extrêmes variables suivant mission.

Pr. A. Addaim
Contraintes
• La capacité de communication entre le satellite et les stations
Limitation de la communication bord/sol
La capacité de communication entre le satellite et les stations
sol est limitée par les périodes de visibilité.
• La maintenance du logiciel de vol, qu'il s'agisse de remplacer le
logiciel ou de le modifier est une opération complexe, coûteuse,
logiciel ou de le modifier est une opération complexe, coûteuse,
voir même hasardeuse.

Pr. A. Addaim
DEVELOPPEMENT DES LOGICIELS DE VOL
Etapes de développement
Analyse des besoins
Spécification
Architecture
Implémentation
Intégration
g
Validation

Pr. A. Addaim
 Le développement du logiciel démarre après une phase
Analyse des besoins
pp g p p
d'analyse système globale au cours de laquelle sont définis :
 les différents constituants de l'architecture informatique
q
 le rôle, les interfaces et les performances de chaque composant
de l'architecture sont connus et les développements, souvent
pp ,
indépendants, de chacun d'eux peuvent démarrer.
 Une architecture préliminaire du logiciel
p g

Pr. A. Addaim
S é ifi i
• Cette étape correspond à l'analyse ce que doit faire le logiciel de
manière exhaustive et à la vérification de ce que toutes les
Spécification
manière exhaustive et à la vérification de ce que toutes les
exigences exprimées par les différents utilisateurs peuvent
cohabiter et être satisfaites dans l'environnement matériel du
calculateur.
• Cette vérification peut nécessiter de mener des activités de
prototypage pour arbitrer sur la faisabilité de certains "points
prototypage pour arbitrer sur la faisabilité de certains points
durs" ou anticiper certains aspects de la phase d'architecture du
logiciel.
• Elle doit s'accompagner d'une analyse critique pour surmonter
les "points durs" et d'une manière plus générale réduire la
complexité du logiciel
complexité du logiciel.

Pr. A. Addaim
L l i i l t à bâti à ti d t t l i i é
Architecture
• Le logiciel est à bâtir à partir de toutes les exigences exprimées
dans l'étape précédente en construisant l'architecture statique et
l'architecture dynamique du logiciel telles qu'elles ont été
décrites dans le paragraphe précédent.
• A cette étape, on s'intéresse également à estimer les besoins en
capacité de traitement et mémoire et vérifier les marges
capacité de traitement et mémoire et vérifier les marges
existantes a priori.

Pr. A. Addaim
ARCHITECTURE DES LOGICIELS TEMPS REEL
Point de vue statique
 L'architecture de ces logiciels se construit selon 2 points de vue :
• décrit comment sont organisées les activités du logiciel.
• Toutes les fonctions à réaliser par le logiciel sont décomposées
d l ( bj t ) ê t t défi i l
en modules (objets) en même temps que sont définies les
relations entre ces modules.
• Le logiciel se présente comme une hiérarchie de modules. Les
g p
modules de plus bas niveau sont codés dans le langage de
programmation, ils sont testés puis assemblés pour recomposer
le module de niveau supérieur et ainsi de suite jusqu'au plus
le module de niveau supérieur et ainsi de suite jusqu au plus
haut niveau.

Pr. A. Addaim
ARCHITECTURE DES LOGICIELS TEMPS REEL
• décrit comment, dans le temps, vont se dérouler les activités (on
Point de vue dynamique
p (
parle du comportement du logiciel).
• Les fonctions sont organisées en processus (tâches) qui se
t t d l t l (CPU
partagent dans le temps la ressource processeur (CPU,
Mémoire...) selon différentes stratégies bâties autour d'un
séquenceur cyclique ou d'un "exécutif temps réel" :
q y q p
– séquenceur cyclique: toutes les tâches sont périodiques,
indépendantes les unes des autres.
– Exécutif asynchrone préemptif: les tâches peuvent être
périodiques ou sporadiques.

Pr. A. Addaim
• L'architecture définie dans l'étape précédente est complétée par
Implémentation
• L architecture définie dans l étape précédente est complétée par
la définition des activités à l'intérieur de chaque module.
• Ces modules sont codés et testés puis assemblés au sein d'un
programme. Ces activités sont conduites sur" station de travail"
sur laquelle a été installé l'environnement de développement du
logiciel: compilateur, simulateur du processeur cible, débogueur...
g p , p , g

Pr. A. Addaim
• Le logiciel produit dans la phase précédente est installé sur le
Intégration
• Le logiciel produit dans la phase précédente est installé sur le
calculateur cible.
• Il faut l'intégrer avec la couche du logiciel qui gère le matériel et
g g q g
vérifier
– le fonctionnement correct des entrées/sorties,
– la bonne connexion des interruptions,
– la validité des protocoles de communication,
– le respect des contraintes temporelles de chaque processus,
– tout ce qui dépend de l'environnement d'exécution du logiciel.

Pr. A. Addaim
• Il s'agit de vérifier que le fonctionnement du logiciel dans son
Validation
g q g
environnement d'exécution correspond à l'ensemble des
spécifications qui définit ce que doit faire le logiciel :
– vérification du fonctionnement nominal
– vérification du fonctionnement nominal
– vérification du comportement en présence d'erreurs
– contrôle des performances et essais dans des conditions aux
limites.
 Le logiciel s'exécute dans des conditions réelles d'exploitation et
ces essais de qualification participent également à la validation du
logiciel.

Pr. A. Addaim
L’évolution de conception des cartes électronique vers l’FPGA

Pr. A. Addaim
Choix de la carte FPGA
 Fournisseur: Xilinx ou Altera? License d’exportation?
 Fréquence de travail : 12, 25, 30, 40… MHz
 Système d’exploitation temps réel
 Outils de développement : VHDL, compilateur C, logiciel
de simulation
 Température de travail : de –40 jusqu’à +85 deg °C
 Radiation Hardness: la dose total 10k, 20k, 30k… rad
 Qualifié spatial? Déjà volé?
 Prix

Pr. A. Addaim
Communication subsystem
Modular Architecture of satellite
Antenna
Antenna
Tx
Modulator
Rx
Demodulator
Communication subsystem
Telecommand
Decoder
Telemetry
Encoder TTC subsystem
On-board computer
Bus of the satellite
Orbit and
attitude control
subsystem
Thermal
control
subsystem
Payload
Power
control
subsystem
Propulsion
subsystem

Pr. A. Addaim
Choix du bus de communication
CAN SPI I²C
Consommation de l’énergie 3 5 5
Disponibilité 2 5 4
Complexité matérielle de l’esclave 2 5 3
Complexité logiciel de l’esclave 2 5 3
Complexité de câblage 4 3 5
Complexité de câblage 4 3 5
Facilité d’interfaçage avec les portes
logiques
1 4 1
Key: 5= Meilleur 1= médiocre
Key: 5= Meilleur, 1= médiocre

On Board Computer Subsystem.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à On Board Computer Subsystem.pdf

Similaire à On Board Computer Subsystem.pdf (20)

Dernier

Dernier (15)

On Board Computer Subsystem.pdf