Définition et prototypage d`une chaîne de traitement d`image

Transcription

Agence spatiale européenne
Direction technique et de gestion de la qualité
DESCRIPTIF DES TRAVAUX
Définition et prototypage d'une chaîne de traitement d'image
autonome
Référence: TEC-EEP/2006.92/XX
Version: 1, révision 3
Date: 12/04/2007
Appendice 1 à AO/1-5374/07/NL/HE
European Space Agency
ESTEC
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk zh,
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Descriptif des travaux
Définition et prototypage d'une chaîne de traitement d'image autonome
Version: 1
Révision: 3
Date: 12/04/2007
Table des matières
1
INTRODUCTION......................................................................................................................................... 3
1.1
CADRE DU DOCUMENT ............................................................................................................................. 3
1.2
DOCUMENTS D'APPLICATION ET DE REFERENCE ....................................................................................... 3
1.2.1
Documents d'application générale (AD) ......................................................................................... 3
1.2.2
Documents de référence (RD) ......................................................................................................... 3
1.3
SIGLES ET ABREVIATIONS ........................................................................................................................ 5
2
ARRIERE-PLAN ET OBJECTIFS............................................................................................................. 6
2.1
2.2
2.3
2.4
2.5
3
ARRIERE-PLAN ......................................................................................................................................... 6
OBJECTIFS DES TRAVAUX......................................................................................................................... 6
DESCRIPTION DE LA CHAINE DE TRAITEMENT D'IMAGE ............................................................................ 7
ACTIVITES CONNEXES ............................................................................................................................ 10
ACTIVITES CONNEXES DE L'AGENCE ...................................................................................................... 11
DETAIL DES TRAVAUX.......................................................................................................................... 11
3.1
ORGANISATION DES TRAVAUX ............................................................................................................... 11
3.2
DESCRIPTION DES TRAVAUX .................................................................................................................. 12
3.2.1
Tâche 1: Bilan des connaissances, exigences de référence et spécification technique ................. 12
3.2.2
Tâche 2: Conception détaillée et réalisation................................................................................. 13
3.2.3
Tâche 3: Vérification et validation du logiciel.............................................................................. 13
3.2.4
Tâche 4: Jeu d'essai des performances de bout en bout................................................................ 14
3.2.5
Tâche 5: Synthèse, recommandations et travaux ultérieurs.......................................................... 15
4 EXIGENCES EN MATIERE DE GESTION, DE COMPTE RENDU, DE REUNIONS ET
D'ELEMENTS A FOURNIR ............................................................................................................................. 15
4.1
GESTION ................................................................................................................................................ 15
4.2
COMPTE RENDU ..................................................................................................................................... 15
4.3
REUNIONS .............................................................................................................................................. 16
4.4
ELEMENTS A FOURNIR ............................................................................................................................ 16
4.4.1
Documents et données................................................................................................................... 16
4.4.2
Logiciel.......................................................................................................................................... 17
5.
CALENDRIER ET GRANDES ETAPES DES TRAVAUX ................................................................... 18
ANNEX 0: DEFINITIONS................................................................................................................................. 20
ANNEX 1: ECSS-E40 TAILORING ................................................................................................................. 21
Introduction................................................................................................................................................... 21
Description of the tailoring........................................................................................................................... 21
List of ECSS-E40 applicable requirements ................................................................................................... 25
Document Requirement List [as specified in ECSS-E-40 part 2B (15 November 2004)] ............................. 30
ANNEX 2: SOFTWARE REQUIREMENTS................................................................................................... 33
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 2 of 34
Version: 1
Révision: 3
Date: 12/04/2007
1 Introduction
1.1 Cadre du document
Le présent document spécifie les travaux à accomplir et les produits à fournir à l'Agence
Spatiale Européenne au titre de l'étude susvisée.
Il fait partie intégrante du contrat et sera d'application tout au long des travaux.
Le but de cette activité, qui s'inscrit dans le cadre du programme d'études générales (GSP), est
de définir une architecture générique pour une chaîne de traitement autonome d'images
optiques, et de réaliser un prototype de détecteur d'observation de la Terre à haute résolution
spatiale et de géométrie rectangulaire (balayage "pushbroom" ou "whiskbroom").
Les résultats de la présente étude pourront être mis à profit pour des missions futures telles
que Sentinel 2 [RD-20] ou Sentinel 3 [RD-21].
1.2 Documents d'application et de référence
Les documents dont la liste suit doivent être considérés comme applicables à la présente étude
et de référence.
1.2.1 Documents d'application générale (AD)
Les documents suivants, énumérés dans l'ordre de priorité où ils s'appliquent, contiennent les
exigences applicables à la présente activité:
AD-1
ECSS-E-40 Part 1B; Space Engineering – Software; 28 novembre 2003
http://www.ecss.nl/
1.2.2 Documents de référence (RD)
Le Contractant pourra consulter les documents suivants car ils contiennent des informations
utiles:
RD-1
Schowengerdt, R. A. (1997). Remote Sensing Models and Methods for Image
Processing, ISBN: 0126289816, Editorial Elsevier, pp. 522.
RD-2
Site Internet du projet GMES (Mission de surveillance mondiale pour
l'environnement et la sécurité): http://www.gmes.info
RD-3
Baillarin, S., Bouillon, A., Bernard, M., Chikhi, M. (2005), Using a Three
Dimensional Spatial Database to Orthorectify Automatically Remote Sensing
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 3 of 34
RD-4
Version: 1
Révision: 3
Date: 12/04/2007
Images. ISPRS Workshop on Service and Application of Spatial Data
Infrastructure, XXXVI (4/W6), 14-16 oct., Hangzhou, Chine.
Page Internet de PCI Geomatics: http://www.pcigeomatics.com
RD-5
Philippe Goudy, Philippe Kubik, Bernard Rouge, Christophe Latry (2002).
From Image Processing Concepts to Instrument Design in Remote Sensing
Satellites. Actes de EUSIPCO 2002. Volume II pp 431-434.
RD-6
Page Internet d'ENVI: http://www.ittvis.com/envi/
RD-7
Schiller, C.; Triebnig, G.; Kim, Y.; Maass, H. (2005). KOMPSAT European
cooperation. Geoscience and Remote Sensing Symposium, 2005. IGARSS '05.
Actes de la conférence. 2005 IEEE International. Volume 2, 25-29 July 2005
Page(s):1173 - 1176
RD-8
Jinsong Chen, Hui Lin, Yun Shao, Limin Yang (2006). Oblique striping
removal in remote sensing imagery based on wavelet transform. International
Journal of Remote Sensing. Volume 27, Number 8 / 20, pp. 1717 – 1723.
RD-9
Yong Du Cihlar, J. Beaubien, J. Latifovic, R. (2001). Radiometric
normalization, compositing, and quality control forsatellite high resolution
image mosaics over large areas. Geoscience and Remote Sensing, IEEE
Transactions on; Volume: 39, Issue: 3; pp. 623-634.
RD-10
Jalobeanu, A.
Blanc-Feraud, L.
Zerubia, J. (2000) Satellite image
deconvolution using complex wavelet packets. Image Processing, 2000. Actes
de la conference. 2000 International Conference on; Vol.3, pp. 809-812 vol.3.
RD-11
A. Jalobeanu1, L. Blanc-Féraud, J. Zerubia (2006). Adaptive Parameter
Estimation for Satellite Image Deconvolution. Rapport de recherche de
l'INRIA. Référence interne: RR-3956.
RD-12
Lien Internet: http://eu.spaceref.com/news/viewpr.html?pid=12727
RD-13
Descriptif des travaux du contrat de l'ASE n° 20226/06/NL/HE "Modèle
physique pour l'analyse des erreurs géométriques en imagerie de télédétection".
RD-14
Yong Du Cihlar, J. Beaubien, J. Latifovic, R. (2001). Radiometric
normalization, compositing, and quality control forsatellite high resolution
image mosaics over large areas. Geoscience and Remote Sensing, IEEE
Transactions on; Vol. 39, Issue 3; pp. 623-634.
RD-15
Page Internet de VICAR: http://www-mipl.jpl.nasa.gov/external/vicar.html
RD-16
Page Internet de MIPL: http://www-mipl.jpl.nasa.gov/
RD-17
Page Internet d'ISIS: http://isis.astrogeology.usgs.gov/
RD-18
European Planetary Mapping GREEN PAPER, Europlanet Conference 2006.
RD-19
Page Internet d'ALOS (Satellite évolué d'observation de la Terre):
http://www.jaxa.jp/projects/sat/alos/index_e.html
RD-20
Documentation de l'appel d'offres de l'Agence "GMES SENTINEL-2 PHASE
B2/C/D/E1". AO5340. 16/02/2007.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 4 of 34
Version: 1
Révision: 3
Date: 12/04/2007
RD-21
Documentation de l'appel d'offres de l'Agence "GMES SENTINEL-3 PHASE
B2/C/D/E1". AO5314. 12/02/2007.
RD-22
Dial G., Grodecki J. (2002). IKONOS Accuracy without Ground Control.
Actes de la conference "Integrated Remote Sensing at the Global, Regional and
Local Scale ISPRS Symposium". 10-15 novembre 2002, Denver, CO USA.
AMORGOS Automated MERIS ORtho-rectified Geo-location Operational
Software). http://earth.esrin.esa.it/resources/softwaretools/
Page Internet de VEGETATION: http://vegetation.cnes.fr/
Page Internet de PLEIADES: http://smsc.cnes.fr/PLEIADES/
Page Internet de MERIS:
http://envisat.esa.int/object/index.cfm?fobjectid=1665
FORMOSAT-2: http://www.spotimage.fr/html/_167_171_977_979_.php
KOMPSAT-2: http://www.spotimage.fr/html/_167_171_1155_.php
Dial, G., Grodecki, J. (2002). Block Adjustment with Rational Polynomial
Camera Models. ACSM-ASPRS 2002 Annual Conference Proceedings.
Manuel de MERIS: http://envisat.esa.int/dataproducts/meris/toc.htm
RD-23
RD-24
RD-25
RD-26
RD-27
RD-28
RD-29
RD-30
1.3 Sigles et abréviations
ANDORRE
AR
ARCS
CNES
DLR
ESA/ASE
FR
GCP
GMES
IGN
KARI
MTF
NLR
PDR
PSF
QR
RPC
SPOT
TP
VHR
Atelier Numérique D’ORthoREctification
Revue de recette
Centres de recherche autrichiens
Centre National d'Etudes Spatiales
Deutsches Zentrum für Luft- und Raumfahrt
Revue finale
Point d'appui
Initiative européenne pour la surveillance pour l'environnement et la sécurité
Institut Géographique National
Institut coréen de recherche aérospatiale
Fonction de transfert de modulation
Nationaal Lucht- en Ruimtevaartlaboratorium
Revue de définition préliminaire
Fonction d'étalement du point
Revue de qualification
Polynôme à coefficients rationnels
Satellite Pour l'Observation de la Terre
Point de rattachement
Très haute résolution
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 5 of 34
Version: 1
Révision: 3
Date: 12/04/2007
2 Arrière-plan et objectifs
2.1 Arrière-plan
Suite à l'émergence des missions GMES (surveillance mondiale pour l'environnement et la
sécurité) [RD-2], le traitement automatique des images à haute résolution est appelé à jouer un
rôle clé. Le principal objectif du programme GMES est de surveiller la planète en continu, ce
qui produira un volume considérable de données à haute résolution (métrique à décamétrique)
et nécessitera un traitement d'image automatique de haute qualité, une orthorectification et un
mosaïquage. Cette exigence est jugée critique dans le cadre du programme GMES.
La réussite du programme GMES et, de façon générale, le développement du marché de la
télédétection, dépendent dans une grande mesure du traitement en temps réel des données et
exigent en conséquence de limiter le plus possible l'intervention humaine pour la génération
d'images orthorectifiées et mosaïquées.
Dans le domaine des sciences planétaires, de nombreuses missions (par exemple VEX, MEX,
SMART-1, Rosetta et BepiColombo) doivent ou devront acquérir un volume considérable
d'images optiques. Le besoin présent et futur d'outils de traitement d'image est dont une
réalité. Bien que la présente étude porte essentiellement sur l'observation de la Terre, ses
résultats pourront également être utiles pour les missions de sciences spatiales.
2.2 Objectifs des travaux
Il s'agit de définir et de mettre en œuvre une chaîne de traitement d'images rapide et
autonome pour les missions de télédétection optique à haute résolution spatiale et à géométrie
rectangulaire (balayage "pushbroom" ou "whiskbroom").
Cette chaîne
suivant):
A.
B.
C.
D.
E.
F.
G.
devra comprendre les fonctions ci-dessous (voir les définitions au chapitre
Etalonnage
Egalisation
Déconvolution
Réduction du bruit
Alignement
Orthorectification
Mosaïquage
L'orthorectification ne sera envisagée et mise en œuvre que dans le cadre d'une méthode
relativement simplifiée et directe, car elle est traitée de façon plus approfondie dans le cadre
d'une autre étude [RD-13]. A noter en outre que toutes les fonctions mentionnées plus haut ne
sont pas nécessairement séquentielles (par exemple, la déconvolution et la réduction du bruit
peuvent être combinées).
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 6 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Ce logiciel devra être testé pour une zone géographique représentative (incluant les variations
topographiques fortes et faibles) au moyen d'images de synthèse et réelles.
La chaîne de traitement devra être livrée sous forme de logiciel opérationnel.
2.3 Description de la chaîne de traitement d'image
Pour les détecteurs de prise d'images optiques, la conversion des données de niveau 0 en
données mosaïquées de niveau 1C à étudier recouvre les étapes décrites à la figure 1. Les
définitions envisagées pour chaque niveau de produit figurent à l'Annexe 0.
Pre-processing
Radiometric corrections
Level 0
Non-linearity &
stray-light
corrections.
Source data
extraction and
defective pixels
exclusion
Calibration (dark
and absolute)
Equalization
De-convolution
De-noising
Level 1C
Geometric corrections
Co-registration
Orthorectification
Mosaicking
Figure 1: Schéma de la chaîne de traitement au sol pour la conversion des données de niveau
0 en données mosaïquées de niveau 1C.
Aux fins de la présente étude, seules les fonctions suivantes seront envisagées (pavés grisés de
la figure 1):
A. Etalonnage (conversion de nombres numériques en unités physiques)
B. Egalisation (compensation des différentes réponses de chaque élément de détection
élémentaire) [RD-8, 9].
C. Déconvolution (compensation de la fonction d'étalement du point du détecteur) [RD10, 11].
D. Réduction du bruit (méthodes en général combinées à la déconvolution et appelées
restauration d'image) [RD-11].
E. Alignement (réunit toutes les bandes spectrales dans le même système de référence
géométrique).
F. Orthorectification (transforme la géométrie de l'image pour l'adapter à un système de
référence, géolocalisation à l'aide des points d'appui et ré-échantillonnage) [RD-3, 4].
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 7 of 34
Version: 1
Révision: 3
Date: 12/04/2007
G. Mosaïquage (réunit un ensemble d'images dans un système de référence
cartographique commun) [RD-14, 3]
Pour chacune de ces fonctions, il existe diverses options dans les milieux de la recherche et du
développement. Le Contractant devra faire un tour d'horizon complet des différentes
méthodes, les comparer et conseiller l'Agence quant aux options les mieux adaptées, au vu de
certaines missions futures de référence.
L'étalonnage consiste à convertir les nombres numériques mesurés par le capteur en unités
physiques de luminance énergétique mesurée à l'entrée du détecteur.
L'égalisation permet de compenser les différentes réponses (décalage et gain) de chaque
élément de détection élémentaire et est utile pour éviter les effets de raies qui apparaissent sur
l'image brute, en particulier dans le cas des instruments à balayage "pushbroom" ou
"whiskbroom". L'égalisation est en général effectuée par étalonnage vicariant, par le biais de
l'acquisition d'images au-dessus de cibles sombres et brillantes (par exemple l'océan la nuit
pour une cible sombre, la neige ou le désert pour une cible brillante), au moyen du matériel de
bord (par exemple un diffuseur solaire), ou par une combinaison des deux. Les coefficients de
correction du décalage et du gain sont en général calculés au sol par égalisation des
histogrammes ou autres techniques. D'autres méthodes reposant sur des réseaux neuronaux
ont été proposées pour le cas de l'acquisition au-dessus de cibles non uniformes. Les
coefficients d'égalisation peuvent être soit appliqués au sol après réception des données
brutes, soit transmis au satellite et appliqués à bord. La seconde méthode sera mise en
pratique pour la mission Pléiades. L'égalisation à bord présente deux avantages en cas de
compression à bord: en supprimant les raies directement sur l'image brute avant la
compression à bord, elle réduit l'entropie de l'image et peut améliorer le rapport de
compression de 5% à 10% pour une qualité d'image constante; elle évite en outre les erreurs
introduites par la contre-égalisation constatée lorsque l'égalisation est effectuée après la
compression ou décompression.
La déconvolution permet d'améliorer la fonction de transfert de modulation de l'image, en
particulier aux fréquences élevées proches de la fréquence de Nyquist, ce qui permet de
réduire le flou de l'image. Néanmoins, l'efficacité de la déconvolution dépend dans une grande
mesure du crénelage et ne se justifie en général qu'aux fréquences non polluées par le
crénelage et cette méthode n'est dans la pratique employée que lorsque la fonction de transfert
de modulation à la fréquence de Nyquist est en général inférieure à 0,20. Aux fréquences
entachées de crénelage, la déconvolution ne rétablit pas les détails réels de l'image, mais ne
fait qu'amplifier le phénomène de crénelage. L'efficacité de la déconvolution dépend
également du niveau de bruit de l'image, qui peut être amplifié si la déconvolution n'est pas
effectuée en même temps que la réduction du bruit. La méthode classique de déconvolution
est le filtrage inverse de Wiener, mais des méthodes plus évoluées, reposant sur les
transformées en ondelettes et combinant la déconvolution et la réduction du bruit sont plus
précises (figure 2). Ces méthodes seront employées pour la mission Pléiades.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 8 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Figure 2: Image de Cayenne prise par SPOT 3. En haut: floue et bruitée. En bas: après
déconvolution avec l'algorithme de l'INRIA (France) [RD-11].
L'alignement consiste à réunir toutes les bandes spectrales dans le même système de référence
géométrique. Cette fonction repose sur une corrélation de l'image consécutive à un
prétraitement efficace (suréchantillonnage, rotation de la géométrie épipolaire, adaptation de
la dynamique radiométrique et autres). La corrélation de l'image est l'étape critique de
l'alignement des différentes bandes spectrales. Les méthodes classiques de corrélation d'image
reposent sur le déplacement d'une fenêtre de référence dans une fenêtre de recherche, sur le
déplacement du coefficient de corrélation à chaque emplacement, sur la construction d'une
surface de corrélation bidimensionnelle par la méthode de l'interpolation. Des techniques de
substitution reposant sur un ré-échantillonnage dichotomique des fenêtres de référence et de
recherche et sur le calcul de la surface de corrélation à des résolutions spatiales supérieures
ont également été mises au point et se sont révélées plus précises, avec une précision de
corrélation type inférieure à 0,1 point d'image contre 0,2 à 0,3 pour les méthodes classiques.
Les techniques de corrélation d'image fondées sur un ré-échantillonnage dichotomique ont été
utilisées pour VEGETATION [RD-24] et le seront également dans les détecteurs à très haute
résolution, dont Pléiades [RD-25].
L'orthorectification de l'image est réalisée dans le cadre de la présente étude au moyen d'une
procédure automatisée faisant appel à des points d'appui et/ou à des points de rattachement.
Le Contractant peut aussi recourir à des fonctions de polynôme à coefficients rationnels pour
établir les relations entre le terrain et l'image pour un détecteur donné [RD-22, 29]. S'agissant
de l'orthorectification, la corrélation d'image est également une étape critique car elle
détermine la précision de l'extraction des points d'appui et des points de rattachement, ce qui
produit un effet direct sur les performances générales de géolocalisation.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 9 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Le mosaïquage de l'image est important pour répondre aux besoins des utilisateurs qui
s'intéressent à une zone géographique dépassant les limites d'une image unique. Les
principaux problèmes à résoudre résident dans les différences de conditions d'observation qui
engendrent des différences de résolution spatiale entre les images à mosaïquer, des différences
d'éclairement par le Soleil et des problèmes de zones dissimulées en cas de variations
importantes de la topographie, comme dans le cas des grandes villes ou des flancs de
montagne et falaises abrupts. Si un retard sépare l'acquisition de deux images, les cibles au sol
ou les nuages ont pu se déplacer dans l'intervalle, ce qui accroît la complexité du travail de
mosaïquage. Pour parvenir à un mosaïquage automatique fluide, une sélection automatique de
la ligne de coupe entre deux images voisines est indispensable: on utilise les détails
cartographiques linéaires classiques, comme des routes, des cours d'eau, qui doivent alors être
automatiquement détectés et mis en correspondance entre les deux images. Cette méthode fait
en général appel à une analyse de la texture de l'image (par exemple en utilisant des imagesgradients et en recherchant des structure linéaires) et on effectue une corrélation entre les
deux images pour déterminer la position de la ligne de coupe entre elles. Ce point a été
exploré dans le cadre des missions à très haute résolution de type Pléiades [RD-12].
2.4 Activités connexes
Pour l'observation de la Terre, les fonctions prévues pour cette chaîne de traitement d'image
automatisée ont été mises au point dans différents cadres.
En Europe, les fonctions A, B, C et D (étalonnage, égalisation sur des scènes uniformes,
déconvolution et réduction du bruit) ont fait l'objet d'études approfondies au CNES, dans le
cadre des programmes SPOT et Pléiades [RD-5].
Les fonctions E, F et G (alignement, orthorectification et mosaïquage) ont été plus largement
étudiées et mise en œuvre aux fins de services opérationnels. Ainsi, par exemple, le CNES,
l'IGN (Institut Géographique National) et Spot Image ont récemment collaboré à la mise au
point d'une chaîne de traitement destinée à l'orthorectification des images SPOT (appelée
ANDORRE [RD-3]). Une autre initiative majeure est le travail mené conjointement entre les
centres de recherche autrichiens, le DLR (Deutsches Zentrum für Luft- und Raumfahrt), le
NLR (Nationaal lucht- en ruimtevaartlaboratorium) et le KARI (Institut coréen de recherche
aérospatiale) pour automatiser le traitement des données de Kompsat [RD-7, 28].
Des chaînes ont également été réalisées dans le cadre d'initiatives privées pour exécuter
automatiquement les fonctions E et F. L'un des logiciels les plus éminents du marché est PCI
Geomatics [RD-4] avec son système de correction d'image ICS qui automatise le traitement et
la préparation des images de télédétection et permet de réaliser instantanément un gain de
temps et d'argent pour l'orthocorrection. D'autres logiciels de traitement d'image comme
ENVI [RD-6] réalisent également les fonctions de base pour l'orthocorrection automatique
des données d'Ikonos, par exemple.
Dans le domaine des sciences de l'espace, le traitement d'image repose essentiellement sur des
logiciels américains, l'un appelé VICAR [RD-15] mis au point par le laboratoire MIPL
(traitement d'images multi-mission) [RD-16], à la NASA, et l'autre appelé ISI, mis au point
par l'USGS [RD-17]. VICAR est actuellement exploité pour le traitement des images de la
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 10 of 34
Version: 1
Révision: 3
Date: 12/04/2007
caméra HRSC à bord de Mars Express et de la caméra VMC à bord de Venus Express. Ces
deux logiciels mettent déjà en œuvre d'une certaine façon les fonctions E et F.
A souligner également qu'à la dernière conférence Europlanet, une réunion de travail a été
spécialement consacrée à la cartographie planétaire. Le but en était de coordonner les activités
actuelles au sein d'un programme européen de cartographie planétaire. Son rôle est similaire à
celui que joue l'USGS aux Etats-Unis. Un livre vert a été rédigé au cours de cette conférence
[RD-18].
2.5 Activités connexes de l'Agence
S'agissant de la chaîne de traitement au sol des instruments de prise d'images optiques à
moyenne résolution, l'expérience de l'Agence repose principalement sur la chaîne de
traitement du spectromètre MERIS à bord d'ENVISAT [RD-26, 30]. Dans ce cadre, par
exemple, l'un des outils mis au point par l'Agence est AMORGOS (logiciel opérationnel de
géolocalisation orthocorrigée de précision de MERIS) qui effectue une géolocalisation précise
[RD-23].
S'agissant de l'orthocorrection automatique, une autre activité est en cours à l'Agence dans le
cadre d'une étude du programme GSP, intitulée "Modèle physique pour l'analyse des erreurs
géométriques en imagerie de télédétection" [RD-13]. Cette activité vise à mettre au point un
processeur de correction automatique de la géométrie des images optiques au moyen d'un
modèle physique de ligne de visée. Comme il a été dit plus haut, étant donné que cette
fonction fait déjà l'objet d'autre activités en cours, une fonction d'orthocorrection automatique
ne sera pas abordée dans le cadre de la présente étude, et elle ne sera mise en œuvre dans le
processeur que selon une méthode relativement simple reposant sur les points d'appui et les
points de rattachement, et éventuellement sur le coefficient à polynômes rationnels, afin
d'établir un lien entre les points d'image et leur position au sol [RD-22].
3 Détail des travaux
3.1 Organisation des travaux
L'étude s'articule en trois parties. L'achèvement de la première partie (comprenant la tâche 1)
sera sanctionné par une première réunion d'étape, la revue de définition préliminaire. La
deuxième partie (comprenant les tâches 2 et 3) se conclura par la revue de qualification et de
recette. La troisième partie s'achèvera avec la revue finale.
La présente étude devra obéir aux stipulations de la version adaptée de la norme ECSS-E40
[AD-1], jointe en Annexe 1, et aux exigences logicielles visées à l'Annexe 2.
La première tâche (Bilan des connaissances, exigences de référence et spécification
technique) se conclura par la revue de définition préliminaire à laquelle les dossiers
renfermant les exigences de référence et la spécification technique seront évalués et soumis à
l'approbation de l'Agence. Un avant-projet d'exigences de référence devra être remis deux
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 11 of 34
Version: 1
Révision: 3
Date: 12/04/2007
mois avant la revue de définition préliminaire. A cette même revue, une première version de
la "Spécification des essais de validation du logiciel d'après les exigences de référence" et un
"Plan du jeu d'essai" (non spécifiés dans la norme ECSS-E40) devra être soumise à l'Agence
pour approbation.
Le démarrage de la tâche 2, portant sur la conception détaillée et la réalisation de l'outil, est
subordonné à l'achèvement concluant de cette revue. Un avant-projet du dossier de définition
de la conception sera remis à l'Agence au milieu de la tâche 2. La version finale de ce dossier
sera remise à l'Agence, pour approbation, à la fin de cette deuxième tâche.
La tâche 3 (Vérification et validation du logiciel) démarrera au cours de la tâche 2 et se
déroulera donc pendant un certain temps en parallèle avec celle-ci. Le dossier de justification
de la conception devra être remis à l'Agence à la fin de la tâche 3 (revue de qualification et de
recette). Un avant-projet devra au préalable en être remis au moins un mois avant la fin de
cette tâche.
La tâche 4 (Jeu d'essais de performances de bout en bout) et la tâche 5 (Synthèse,
recommandations et suite des travaux) seront conclues par une revue finale à laquelle tous les
éléments à livrer devront être soumis à l'Agence pour approbation.
Le rapport d'analyse des modifications et problèmes (dossier de maintenance) devra être remis
à la revue finale et à l'achèvement du contrat.
3.2 Description des travaux
3.2.1 Tâche 1: Bilan des connaissances, exigences de référence et
spécification technique
¾ Matière de départ
Les interfaces du module fonctionnel d'orthorectification seront spécifiées par
l'Agence.
¾ Travail à accomplir
S'agissant des fonctions d'une chaîne de traitement d'image à étudier (étalonnage,
égalisation, déconvolution, réduction du bruit, alignement, orthorectification et
mosaïquage), décrites au chapitre 2.3, faire un tour d'horizon exhaustif des démarches
adoptées dans les milieux concernés (scientifiques et industriels).
Faire choix d'une démarche pour chaque fonction de la chaîne de traitement par le
biais d'un processus d'analyse comparative et justifier ces choix au vu des
performances en matière de qualité d'image (géométrique et radiométrique) et de
temps de traitement.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 12 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Etablir les exigences de référence et la spécification technique du logiciel en
respectant les exigences visées à l'annexe 2 et en se conformant à la norme ECSS-E40
adaptée selon l'annexe 1.
Le Contractant devra en outre définir la "Spécification des essais de validation du
logiciel d'après les exigences de référence" et un "Plan du jeu d'essai" (non spécifiés
dans la norme ECSS-E40). Ces documents devront décrire la stratégie de validation et
toutes les informations de départ requises.
¾ Résultats et conditions d'approbation
•
Rapport reprenant les conclusions des travaux et les raisons des choix
effectués.
•
Dossiers des exigences de référence et de la spécification technique.
•
Spécification des essais de validation du logiciel par rapport à la
spécification technique.
•
Plan du jeu d'essai (aux fins de la tâche 4).
Le dossier technique relatif à la tâche 1 devra être soumis à l'Agence pour agrément et
présenté à la revue de définition préliminaire.
3.2.2 Tâche 2: Conception détaillée et réalisation
Produits de la tâche 1.
Sur la base des exigences de référence et de la spécification technique, concevoir et
réaliser la chaîne de traitement conformément aux exigences visées à l'annexe 2 et à
l'adaptation de la norme ECSS-E40 (annexe 1).
Remise du dossier d'avant-projet et du dossier de justification de la conception.
3.2.3 Tâche 3: Vérification et validation du logiciel
Ensemble de données requis pour l'exécution de la vérification et de la validation du
logiciel, comme il est stipulé dans la "Spécification des essais de validation du logiciel
d'après les exigences de référence". Les données nécessaires seront fournies par le
Contractant et remises à l'Agence à la fin de cette tâche.
L'Agence pourra proposer des ensembles de données et jeux d'essais supplémentaires.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 13 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Il s'agit de vérifier et à de valider le fonctionnement de la chaîne de traitement comme
il est stipulé dans la "Spécification des essais de validation du logiciel d'après les
exigences de référence".
Remise du dossier de maintenance, du dossier de gestion et du dossier justificatif
de la conception revu et corrigé.
Le dossier technique relatif à la tâche 2 devra être soumis à l'Agence pour agrément et
présenté à la revue de qualification et de recette.
3.2.4 Tâche 4: Jeu d'essai des performances de bout en bout
Produits des tâches 2 et 3
Ensemble de données requis pour l'exécution de la vérification et de la validation du
logiciel, comme il est stipulé dans le "Plan du jeu d'essai". Les données nécessaires
seront fournies par le Contractant et remises à l'Agence à la fin de cette tâche.
Il s'agit de valider les performances de la chaîne de traitement d'image conformément
à la procédure et aux objectifs de performances spécifiés dans le "Plan du jeu d'essai".
La validation utilisera en entrée de la chaîne de traitement des images réelles obtenues
par avion ou par satellite (ayant éventuellement subi un prétraitement, par exemple
pour simuler un détecteur à plus basse résolution simulant lui-même une fonction
d'étalement du point précise, ou un niveau de bruit). Différents essais pourront être
effectués pour différents modules fonctionnels au moyen de différentes images (prises
par avion ou par satellite).
Le logiciel devra être testé pour une zone géographique représentative (incluant les
variations topographiques fortes et faibles).
Les données auxiliaires pourront comprendre ce qui suit:
•
Caractéristique du détecteur et de la plate-forme (fonction d'étalement du
point, niveaux de bruit, etc.).
•
Fonctions de points d'appui, de points de rattachement et de coefficient à
polynômes rationnels) aux fins de l'orthorectification.
•
Modèle numérique de terrain pour le site expérimental sélectionné.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 14 of 34
•
Version: 1
Révision: 3
Date: 12/04/2007
Vérité-sol aux fins de validation des corrections géométriques et
radiométriques (points d'appui, points de rattachement, mesures de référence
radiométrique, etc.).
Rapport reprenant les conclusions et recommandations sur lesquelles ce jeu d'essai a
débouché, à soumettre à l'Agence pour approbation.
3.2.5 Tâche 5: Synthèse, recommandations et travaux ultérieurs
Produits de toutes les tâches précédentes.
Synthèse et rapport reprenant tous les résultats de l'étude, présentant certaines
recommandations à l'Agence et indiquant la direction dans laquelle les travaux futurs
doivent être menés (y compris la maintenance).
Les recommandations et la suite des travaux devront inclure des études de l'adaptation
future de la chaîne de traitement à des détecteurs de résolution moins fine (par
exemple les détecteurs de prise d'images optiques de Sentinel 3).
Chapitre du rapport final présentant la synthèse de l'étude, les recommandations faites
à l'Agence et les travaux à accomplir ultérieurement. Elaboration de conclusions, de
recommandations à l'intention de l'Agence et description des travaux à accomplir par
la suite.
4 Exigences en matière de gestion, de compte rendu, de réunions
et d'éléments à fournir
Les conditions usuelles en la matière (Appendice 2 du contrat) s'appliquent avec les ajouts et
exigences spécifiques ci-après, qui auront la primauté en cas de divergence.
4.1 Gestion
La section 1 des Conditions types en matière de gestion, de compte rendu, de réunions et
d'éléments à fournir est d'application.
4.2 Compte rendu
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 15 of 34
Version: 1
Révision: 3
Date: 12/04/2007
4.3 Réunions
4.4 Eléments à fournir
Le Contractant devra remettre ce qui suit, en se conformant aux définitions données dans les
conditions types (Appendice 2 du contrat) et à la norme ECSS-E40 [AD-1]:
•
Dossiers des exigences de référence et de la spécification technique
•
Rapport de tâche 1
•
"Spécification des essais de validation du logiciel par rapport à la spécification
technique", à partir du dossier de justification de la conception
•
"Plan du jeu d'essai" (aux fins de la tâche 4).
•
Dossier d'avant-projet
•
Dossier de justification de la conception
•
Dossier de maintenance
•
Dossier de gestion
•
Rapport de tâche 4
•
Rapport final
•
Sommaire
•
Abrégé
•
Programmes d'ordinateur et modèles
Le Contractant mettra en place un site FTP à partir duquel tous les éléments à livrer au titre de
la présente activité pourront être téléchargés, et qui sera actualisé en permanence tout au long
du contrat. Les documents électroniques des présentations faites aux réunions d'avancement y
seront également disponibles.
4.4.1 Documents et données
Identification
Titres
Etape
D1
Dossier des exigences de
référence
D2
Dossier de la
spécification technique
Nombre
d'exemplaires
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 16 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Identification
Titres
Etape
Nombre
d'exemplaires
D3
Rapport de tâche 1
D4
Spécification des essais
de validation du logiciel
par rapport à la
spécification technique (à
partir du dossier de
justification de la
conception)
Version électronique
Revue de définition
préliminaire (fin de la
tâche 1).
D5
Plan du jeu d'essai pour
la tâche 4
D6
Dossier d'avant-projet
D7
Dossier de justification
de la conception
D8
Dossier de maintenance
D9
Dossier de gestion
D10
Données de départ de la
tâche 3
(Fin de la tâche 3)
D11
Rapport de tâche 4
Fin de tâche 4
D12
Données de départ de la
tâche 4
D13
Rapport final, sommaire,
abrégé et versions finales
de tous les documents
des dossiers techniques
Revue finale (fin de
la tâche 5)
Version électronique,
7 exemplaires sur
papier (pour le
rapport) et 7 CDROM ou DVD
Fin de tâche 2
Revue de
qualification et de
recette
4.4.2 Logiciel
Identification
Description
Etape
Nombre
d'exemplaires
SW1
Logiciel de la chaîne
de traitement (code
source et exécutable)
Revue finale
7 CD-ROM ou DVD
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 17 of 34
Version: 1
Révision: 3
Date: 12/04/2007
5. Calendrier et grandes étapes des travaux
5.1
Durée
La durée du contrat est limitée à 16 mois, du démarrage à l'achèvement des travaux
(achèvement concluant de la revue finale).
5.2
Etapes
Le contrat sera jalonné par les grandes étapes suivantes:
•
•
•
5.3
Revue de définition préliminaire
Revue de qualification et de recette
Revue finale
Revues de travaux
Les revues ci-dessous devront être prévues:
5.3.1 Revue de définition préliminaire
¾ Date: A déterminer dans la soumission
¾ Lieu: ESTEC
¾ Matière de départ: Produits de la tâche 1.
¾ Description: La première tâche se conclura par la revue de définition préliminaire
à laquelle les dossiers renfermant les exigences de référence et la spécification
technique seront évalués et soumis à l'approbation de l'Agence.
¾ Produit attendu: Si l'Agence juge que cette revue est probante, les travaux pourront
se poursuivre. Dans le cas contraire, le Contractant devra affiner ou améliorer les
dossiers des exigences de référence et de la spécification technique et les
soumettre de nouveau à l'approbation de l'Agence. L'état de mise au point du
logiciel à l'issue de la revue de définition préliminaire est appelé "état spécifié".
5.3.2 Revue de qualification et de recette
¾ Date: A déterminer dans la soumission
¾ Lieu: ESTEC ou ESRIN
¾ Matière de départ: Résultats des tâches 1, 2 et 3.
¾ Description: La revue combinée de qualification et de recette vise à confirmer que
les exigences du client ont été correctement prises en compte, que toutes les
exigences ont été satisfaites, que toutes les contraintes de conception ont été
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 18 of 34
Version: 1
Révision: 3
Date: 12/04/2007
respectées et que le produit logiciel a été évalué dans son cadre d'exploitation. Un
processus secondaire de cette revue est le transfert du logiciel au client et sa recette
par celui-ci. Il doit être exécuté une fois que le produit logiciel a été transféré au
client et installé sur une plate-forme matérielle de l'Agence. La revue de recette
sanctionnera l'achèvement des activités de validation du logiciel.
¾ Produit attendu: Après l'approbation par l'Agence du dossier technique livré, le
logiciel sera considéré comme étant "dans un état qualifié et accepté".
5.3.3 Revue finale
¾ Date: T0+16
¾ Lieu: ESTEC
¾ Matière de départ: Tous les éléments à livrer (rapport final éventuellement à l'état
d'avant-projet)
¾ Description: Examen des résultats finaux, vérification de la remise de tous les
documents et prototypes de logiciel.
¾ Produit attendu: Tous les documents et dossiers techniques du logiciel livrés à
l'Agence.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 19 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Annex 0: Definitions
Image Level 0
Raw observation data after restoration of the chronological data sequence for the
instrument(s) operating in observation mode, at full space/time resolution with all
supplementary information to be used in subsequent processing (e.g. orbital data, health, time
conversion, etc.) appended, after removal of all communication artefacts (e.g.,
synchronization frames, communications headers, duplicated data). Level 0 data are timetagged.
Image Level 1a
Level 0 data with corresponding radiometric and spectral correction and calibration
computed and appended, but not applied, and possibly with preliminary geometric correction
not altering the radiometry (i.e. integer shift).
Image Level 1b
Level 1a data not re-sampled, quality-controlled and radio-metrically calibrated, spectrally
characterised, geometrically characterised, annotated with Satellite position, Satellite
pointing and landmarks.
The Level 1b product consists of Top of Atmosphere (TOA) radiance (W.m-2.sr-1.µm-1).
Image correlation, if involved to meet the spatial co-registration requirements, shall be
performed using a selectable re-sampling method including at least:
- Dichotomic resampling based correlation
Image Level 1c
Level 1b data ortho-rectified, re-sampled to a specified grid.
Image re-sampling is performed using a selectable re-sampling method including at least:
- Windowed truncated Shannon interpolation, also called Hamming window re-sampling
- High-order B-spline interpolation
- Bi-cubic convolution interpolation
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 20 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Annex 1: ECSS-E40 Tailoring
Introduction
ECSS-E40 (Space Engineering – Software) has replaced the PSS-05 for the development of new
space software that is software involved in the production of space systems. ECSS-E40 has the
same goal as its PSS-05 predecessor, which is to assist developers in applying good software
practices during the development. Compared to PSS-05, however, ECSS-E40 allows for more
flexibility in that:
• The standard encompasses a set of software processes without prescribing any specific life
cycle.
• Each software process terminates with reviews that directly tie with those of a satellite
development, so that the former explicitly contribute to the progress of the latter.
• Each software process releases descriptive information, not necessarily a set of documents with
prescribed table of contents. The contractor may place and organise the required information in
whatever form they may choose to. The contractor is able to apply their specific development
methodology, as long as that satisfied the ECSS-E40 process requirements.
• The ECSS-E40 standard requirements must be tailored and adjusted to the specific needs, the
costs and risks of the project.
This annex specifically addresses the last item of the above list. The baselined version ECSSE40 part 1B (from 28 November 2003) is made up of several sections, in which only section 5
expresses requirements.
Description of the tailoring
Project characteristics
Hereafter, an overview of the whole system to be specified, designed, developed and verified and
an assessment of the keys drivers for the ECSS-E-40 tailoring of the software items of the
“Definition and Prototyping of an Autonomous Image Processing Chain” for ESA-ESTEC.
System overview
This system is essentially composed of one software items called “Autonomous Image
Processing Chain” (AIPC).
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 21 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Project Key drivers
A software project or product can be characterized as a function of technical, operational and
management factors that are “key drivers” for the tailoring process of the ECSS-E-40 part 1B
Standard.
Technical factors
Novelty of the domain of application
Complexity of the software, as measured by the number of interface or
similar metrics [External interfaces]
Amount of software that has to be produced [estimated]
Reusability required of the software being developed
Interface to system development projects
Degree of use of COTS or existing software
Maturity of the COTS
Completeness or stability of the user requirements
Operational factors
Type of application (platform, payload, experiment, test infrastructure)
Number of potential users of the software
Criticality of the software as measured by the consequences of its
failure
Expected lifetime (until retirement’s notification) of the software
Number of sites where the software is used
Maintenance constraints
Management factors
Amount of effort required to develop the software
Amount of time required to develop the software
Budget requirements for implementing and operating the software
Schedule requirements for delivering the software (in months)
Number of people required to develop, operate and maintain the
software
Low
Medium
X
High
X
X
X
X
X
X
X
Simulation & modelling
tools
X
X
X
X
X
X
X
X
16 Months
X
Project risks
Hereafter, a table giving a rough estimation of the magnitude of the risks related to the threats
mostly encountered in software development.
Threat description
Risk magnitude
LOW
MEDIUM
Complex specification or unknown technology
X
Tricky design
X
Reliability critical
X
Safety critical
HIGH
X
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 22 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Threat description
Risk magnitude
LOW
MEDIUM
Long term use
HIGH
X
Supplier’s background experience and maturity
N/A
Potential lack of computers resources (processing time & memory)
Potential lack of real time performances
X
X
Roles
•
•
•
•
•
The Customer is ESA
The Supplier is the selected contractor
The User is ESA
The Maintainer is the selected contractor who has designed and developed the system during
the 6 months’ warranty period
There is no operator in the frame of this contract (with respect to the operator definition in E40
part 1)
Processes involved
The following software processes are part of this project:
System engineering processes related to software
In this process the contractor:
•
•
•
•
•
capture the model requirements in specifying the models characteristics, the
accuracy and fidelity level, the data sources, the development constraints (if any)
and the general performances
describe the most appropriate “Modelling & Simulation” System Architecture
(system breakdown and interfaces with others systems or equipments, and possibly
COTS or reused software items (e.g. OS, MMI generator, 2D/3D representation,
GIS)
support the model definition requirements in performing, in the literature, an
extensive survey of existing approaches, models and/or available experimental data
define the theoretical model (e.g. mathematical description of the physical law,
assumptions, simplifications and assessed limitations) and its computational
algorithm (e.g. simulation/calculation methods, input data range, singularities in the
transition regions)
validate or verify by analysis the consistency, coherency and feasibility of the
model requirements in terms of needed computers resources, memory and
appropriateness of the computational algorithms (e.g. calculation methods)
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 23 of 34
Version: 1
Révision: 3
Date: 12/04/2007
The software requirement and architecture engineering process,
In this process, the contractor provides the technical specifications of the software system to
be implemented, mainly the model requirements allocated to the software items and, in that
case:
• The specifications of the AIPC requirements, mainly, the data formats, the
processing represented by the selected algorithms), and the accuracy and fidelity
level
• The high-level interface control document
• The software system breakdown into software components
The software design and implementation engineering process,
The software items are detailed designed, coded.
The software validation process
The software is validated, against the requirement baseline (System Requirements Document
including interfaces requirements).
The software verification process,
At least for the establishment of the RB-TS /SVTS- SATS traceabilty matrices and probably
also for the analyses and demonstration of the feasibility of intermediate work products (e.g.
algorithms assessment reports, numerical accuracy)
The software delivery and acceptance process,
The software management process
Since the bidder will have to include, in its proposal, a draft development plan (including
organization breakdown structure, work breakdown structure, life cycle, development
methods and tools, reused software products, documentation to be produced, risk
management, milestones, and deliveries).
The software maintenance process
Since this contract covers implicitly the corrective maintenance activities to be performed
during the 6 months warranty period.
The following software processes are not part of this project (e.g.):
• The software operation process as no helpdesk is necessary to operate this software in the
frame of this contract.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 24 of 34
Version: 1
Révision: 3
Date: 12/04/2007
List of ECSS-E40 applicable requirements
ECSS-E-40 part 1B from 28 November 2003
5.2 System Engineering Processes related to software
5.2.2.1 System requirements specification
5.2.2.2 System and functional criticality analysis
5.2.2.3 MMI software mock up requirements
5.2.2.4 MMI general requirements and guidelines
5.2.3.1a System design
5.2.3.1b System design to system requirements conformance
5.2.3.1c System requirements to system design traceability
5.2.3.2a Software-hardware interface requirements
5.2.3.2b Traceability to system partitioning
5.2.3.2c System partition with definition of items (HW, SW, human
operation)
5.2.3.2d System configuration items list
5.2.4.2 qualification engineering requirements (verification & validation
process requirements)
5.2.4.3 Software validation requirements at system level
5.2.4.4 Requirement baseline verification
5.2.4.5 SRR
5.2.5.1 Identification of observability requirements
5.2.5.2 Control and data interfaces for system level integration
5.2.5.3 Data medium requirements for integration
5.2.5.4 System database specification (content and use)
5.2.5.5 Identification of development constraints (to support the
software integration into the system)
5.2.5.6 Definition of constraints for software to be reused
5.2.5.7 Identification of customer’s input for software integration into
the system
5.2.5.8 Identification of customer’s output for software integration into
the system
5.2.5.9 Planning of supplier support to system integration
5.2.6.1 Phasing and management / operational plan
5.2.6.2 System requirements definition for software operations
5.2.7.1 Software maintenance requirements
5.2.7.2 Definition of inflight capabilities for flight software
Applicability
Yes
No
No
No
Yes
Yes
Yes
No
No
No
No
Yes
Yes
No (merged with PDR)
No
Yes
No
No
No
5.3 Software Management Process (only at proposal)
5.3.2.1 Definition of software life cycle
5.3.2.2 Software life cycle identification
5.3.2.3 Identification of inputs and outputs associated to each phases
5.3.2.4 Identification of documentation relevant to each
5.3.2.5 Identification of interface between the development and the
maintenance processes
5.3.2.6 Requirements baseline at the SRR (at PDR in that case )
5.3.2.7 Software technical specification phase
5.3.2.8 PDR (Preliminary Design Review)
5.3.2.9 DDR (detailed design review for flight software)
No
No
No
No
No
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 25 of 34
5.3.2.10 CDR (Critical Design Review)
5.3.2.11 software verification and validation process
5.3.2.12 QR (Qualification Review)
5.3.2.13 AR (Acceptance Review)
5.3.2.14 Validation activities phasing wrt AR
5.3.2.15 Software procurement process implementation
5.3.3.2 Support to software reviews
5.3.3.3 Technical reviews
5.3.4.1 Interface definition
5.3.4.2 Interface management procedures
5.3.5.1 Technical budget and margin philosophy
5.3.5.2 Technical budget and margin status at each milestone
5.4 Software requirements and architecture engineering process
5.4.2.1 Establishment and documentation of software requirements /
software requirements specification:
5.4.2.1-a software requirements – functional and performance
5.4.2.1-b software requirements – software product quality
requirements
5.4.2.1-c software requirements – security specifications
5.4.2.1-d software requirements – human factors / ergonomics
specifications
5.4.2.1-e software requirements – data definition and DataBase
requirements
5.4.2.1-f software requirements – Interfaces external to the software
item
5.4.2.2 Definition of functional and performance requirements for
inflight modification
5.4.2.3 Identification of requirements unique identifier
5.4.2.4 Definition of a software logical model
5.4.2.5 Definition of a behavioural view
5.4.2.6a MMI specifications for software
5.4.2.6b Report on evaluation on MMI specifications using a software
mock up
5.4.2.6c end users participation in the MMI mock up evaluation
5.4.3.1 Transformation of software requirements into a software
architecture
5.4.3.2 Software design description
5.4.3.3 Software design documentation
5.4.3.4 Software architectural design contents
5.4.3.5 Software design method
5.4.3.6 Selection of a computational model for real time software
5.4.3.7 Description of software dynamic behaviour
5.4.3.8 Development and documentation of the software interfaces
5.4.3.9 Definition of methods and tools for software to be reused
5.4.3.10 Evaluation of potential reuse of software
5.4.3.11 Evaluation of reuse of predeveloped software
5.4.3.12 Analysis of potential reusability
Version: 1
Révision: 3
Date: 12/04/2007
Applicability
No
Yes
Yes
Yes
No
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
No
Yes
No
No
No
No
No
Yes
Yes
Yes
Yes
No
No
No
No
No
Yes
No
No
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 26 of 34
5.4.3.13 Definition and documentation of the software integration
requirements and plan
5.4.3.14 Conducting a preliminary Design Review (PDR)
5.5 Software design & implementation engineering process
5.5.2.1 Detailed design of each software components
5.5.2.2 Development and documentation of the software interface
detailed design
5.5.2.3 Production of software items physical model
5.5.2.4 Utilization of method for software static design
5.5.2.5a Description of the software dynamic aspects of physical model
for real-time software
5.5.2.5b Description of the software dynamic aspects of physical model
for real-time software
5.5.2.6 Utilization of description techniques for the software behaviour
5.5.2.7 Determination of design methods consistency for real-time
software
5.5.2.8 Development and documentation of the software user manual
5.5.2.9 Definition and documentation of the software unit test
requirements and plan
5.5.2.10 Updating of the software integration requirements and plan
5.5.2.11 Conducting a DDR (Detailed Design Review) for flight software
5.5.3.1 Development and documentation of the software units, test
procedures and test data
5.5.3.2 Software unit testing
5.5.3.3 software user manual updating
5.5.3.4 Updating of the software integration test requirements and plan
5.5.4.1 Software integration test plan development
5.5.4.2 Software units and software components integration and testing
5.5.4.3 Software user manual updating
5.6 Software validation process
5.6.2.1 Determination of the validation effort
5.6.2.2a Establishment of a validation process – process description
5.6.2.2b Establishment of a validation process – methods and tools
5.6.2.3a Selection of an ISVV organization
5.6.2.4 Development and documentation of a validation plan
5.6.3.1 Development and documentation of a software validation testing
specification (SVTS) wrt TS
5.6.3.2 Conducting the validation wrt TS
5.6.3.3 Updating the software user manual
5.6.3.4 Test readiness review
5.6.3.2 Conducting a Critical Design Review (CDR)
5.6.4.1 Development and documentation of a software validation testing
specification (SVTS) wrt RB
5.6.4.2 Conducting the validation wrt RB
5.6.4.3 Updating the software user manual
5.6.4.4 Test readiness review
Version: 1
Révision: 3
Date: 12/04/2007
Applicability
No
Yes
Yes
Yes
No
No
No
No
No
No
Yes
No
No
No
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
No
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 27 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Applicability
5.6.4.5 Conducting a Qualification Review (QR)
Yes
5.7 Software delivery and acceptance
5.7.2 Software delivery and installation
5.7.2.1 Preparation of the software product
5.7.2.2 Supplier’s provision of training and support
5.7.2.3 Installation planning
5.7.2.4 Installation activities reporting
5.7.3 Software acceptance
5.7.3.1 Acceptance test planning
5.7.3.2 Acceptance test execution
5.7.3.3 Executable code generation and installation
5.7.3.4a Supplier’s support to customer’s acceptance
5.7.3.4b Links with Q
5.7.3.4c Acceptance testing documentation
5.7.3.5 Evaluation of acceptance testing
5.7.3.6 Conducting an Acceptance Review (AR)
5.8 Software verification process
5.8.2.1 Determination of the verification effort for the project
5.8.2.2 Establishment of the verification process, methods and tools
5.8.2.3 Selection of the organization responsible for conducting the
verification
5.8.2.4 Development and documentation of a verification plan covering
the software verification activities
5.8.3 Verification activities
5.8.3.1 Verification of software requirements
5.9.3.2 Verification of software architectural design
5.8.3.3 Verification of software detailed design
5.8.3.4 Verification of code
5.8.3.5 Verification of software integration
5.8.3.6 Verification of software documentation
5.8.3.7 Verification of test specifications
5.8.3.8 verification of software validation with respect to TS and RB
5.8.3.9 Evaluation of validation: complementary system level validation
5.8.3.10 problem and non conformance handling
5.8.3.11 Schedulability analysis for real-time software
5.8.3.11a /as support for verification of software requirements &
architectural design
5.8.3.11b /as support for verification of software detailed design
5.8.3.11c /as support for verification of software coding and testing
5.8.3.12 Technical budget management
5.8.3.12a / as support for verification of software requirements &
architectural design / sizing (memory) and timing (CPU load) estimation
5.8.3.12b / as support for verification of software detailed design/
sizing (memory) and timing (CPU utilization in WCET) estimation
refinement
5.8.3.12c/ as support for verification of software coding and testing /
sizing (memory) and timing (CPU utilization in WCET) calculation
Yes
No
No
No
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
No
No
No
No
No
No
Yes
No
No
Yes
No
No
Yes
No
No
No
Yes
No
Yes
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 28 of 34
5.8.3.13 Behaviour modelling verification
5.8.3.13a/ as support for verification of software requirements &
architectural design / verification of the behavioural view of the logical
model
5.8.3.13b/ as support for verification of software detailed design /
modelling the software behaviour and verifying by means of the
techniques used for its description
5.8.3.14 Verification of design: feasibility of testing / availability of
appropriate verification points, assertions, capability of fault injection
5.9 Software Operation Process
5.9.2.1 Operational plans and standards development
5.9.2.2 Problem handling procedures definition
5.9.2.3 Operational testing definition
5.9.3.1 Operational testing execution
5.9.3.2 software operational requirements demonstration
5.9.4 software operation
5.9.5.1 user’s assistance
5.9.5.2 handling of user’s requests
5.9.5.3 provisions of work-around solutions
5.10 Software Maintenance Process
5.10.2.1 Software maintenance process planning
5.10.2.2 Software maintenance process: procedures, methods and
standards
5.10.2.3 problem reporting and handling
5.10.2.4 Implementation of configuration management process
5.10.3.1 Problem analysis
5.10.3.2 Problem verification
5.10.3.3 Development of options for modifications
5.10.3.4 Documentation of problem, analysis and implementation
5.10.3.5 Customer approval of selected modifications options
5.10.4.1 Analysis and documentation of product modification
5.10.4.2 Documentation of software product changes
5.10.4.3 Invoking of software engineering process for modification
implementation
5.10.5 Conducting maintenance review
5.10.6.1 Applicability of this standard to software migration
5.10.6.2 Migration planning and execution
5.10.6.3 Contribution to the migration plan
5.10.6.4 Preparation for migration
5.10.6.5 Notification of transition to migrated system
5.10.6.6 Post-operation review
5.10.6.7 Maintenance and accessibility of data of former system
5.10.7.1 Retirement planning
5.10.7.2 Notification to the operator of retirement
5.10.7.3 identification of requirements for software retirement
5.10.7.4 maintenance and accessibility to data of the retired product
Version: 1
Révision: 3
Date: 12/04/2007
Applicability
No
No
No
N/A
No
No
No
No
No
Yes
Yes
No
Yes
No
Yes
Yes
No
No
No
No
No
No
No
No
No
No
No
No
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 29 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Document Requirement List [as specified in ECSS-E-40 part 2B (15
November 2004)]
The ECSS software standards are completed with some DRDs, describing the most important software
documents. The DRD list is a subset of the exhaustive list of documents to be produced in order to cover all
the work output required by the standards.
The expected output of the requirements resulting of this tailoring can be placed either in the hereunderdesignated DRDs, either in other document items (not having DRD).
Document item
(Software) System Specification
Software Interface Requirements Document
Acronym
in DRD
RSI
Delivery
Date
SSS
Yes
PDR
-
Yes
PDR
System partition with definition of items
Folder
RB
System Configuration Item List
Interface management procedures
Software Requirements Specification
Software Interface Control Document
Software Design Document: Software static and/or
dynamic architecture
No
No
No
SRS
TS
Yes
PDR
-
Yes
PDR
SDD
Yes
End Task 2
Software Design Document (including Software
Components Design): Detailed design
DDF
No
-
Yes
End Task 2
Software Configuration File
SCF
Yes
End Task 2
Software Release Document
SRD
Yes
End Task 2
-
Yes
End Task 2
Software Source Code
Software Delivery
Training Material
No
Software User Manual
SUM
Yes
Software Verification Plan
SverP
No
Software Validation Plan
SValP
No
ISVV Plan
-
No
Software Units Test Plan
SUITP
No
Software Integration Test Plan
SUITP
No
Software Validation Testing Specification wrt TS
SVTS
No
Software Validation Testing Specification wrt RB
SVTS
DJF
End Task 2
Yes
PDR
Mid Task 2
Acceptance Test Plan
-
Yes
Installation Plan
-
No
Software Units Test Report
-
No
Software Integration Test Report
-
No
Software Validation Test Report wrt TS
-
No
Software Validation Test Report wrt RB
-
Yes
QR+AR
Acceptance Testing Documentation
-
Yes
QR+AR
Acceptance Test Report
-
Yes
QR+AR
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 30 of 34
Document item
Version: 1
Révision: 3
Date: 12/04/2007
Acronym
in DRD
Folder
RSI
Delivery
Date
Installation Report
-
No
(Analyses, Inspection & RoD) verification report wrt
TS
-
No
(Analyses, Inspection & RoD) verification report wrt
RB
-
Yes
QR+AR
Software Traceability Matrices
-
Yes
QR+AR
Traceabilty to system partitioning
-
No
Independent Software Validation & Verification
Report
-
No
SRF
If any
Software Budget Report
-
Yes
Numerical Accuracy Analysis Report
-
No
Software Reuse File
Schedulability Analysis Report
-
No
Software Behavior Verification Report
-
No
Software Requirements Verification Report
-
Software Arch. Design and Interface Verification
Report
-
No
Software Detailed Design verification Report
-
No
Software Code Verification Report
-
Yes
Software Documentation Verification Report
-
No
Software Integration Verification Report
-
No
Validation Report Evaluation wrt TS
-
No
Validation Evaluation Report wrt RB
-
Yes
Software Design and Test Evaluation Report
-
No
DJF
QR+AR
No
Testing Feasibility Report
-
No
Problems and Nonconformance Report
-
No
QR+AR
QR+AR
Milestones & Technical Reviews Report
-
No
Software Acceptance Data Package
-
Yes
QR+AR
Procured Software Component Lists
-
Yes
QR+AR
Maintenance Plan
-
No
Maintenance Records
PR & NCR - Modification analysis report -Problem
analysis report
-
Migration Plan
-
MF
No
Yes
End of
the
contract
No
Retirement Plan
No
Software Operational Plan
-
OP
No
No
Operational testing results
Software Development Plan (at proposal only)
SDP
Yes
MGT
Software Configuration Management Plan
Training Plan
N/A
No
No
Customer Approval of Documents
Software Product Assurance Plan
No
SPAP
Records of Training and Experience
No
No
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 31 of 34
Document item
Version: 1
Révision: 3
Date: 12/04/2007
Acronym
in DRD
Compliance Matrix to the Applicable Software Product
Assurance Requirements
Folder
RSI
PAF
No
Software Product Assurance Requirements for
Suppliers
No
Software Criticality Analysis Report
No
List of Critical Software Components
No
Software Product Assurance Report
No
Audit Plan
No
Software Process Assessment Plan
No
Software Process Assessment Records
No
Delivery
Date
<End of ECSS-E40 Tailoring>
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 32 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Annex 2: Software Requirements
Requirement
Description
R-1
The software shall be composed by modules in order to ease future
developments or in order to allow the reuse of certain components.
The main processing chain functions of the software shall also be
autonomous, i.e. executable independently from the other functions.
R-2
R-3
The architecture of the chain should make it adaptable in the future to other
kinds of Earth Observation or Space science missions.
R-4
The software shall include a GUI (Graphical User Interface)
R-5
The software shall be compilable and executable on a PC with both
operating systems Linux and Windows. The use of GNU compilers is the
solution suggested to achieve this (http://www.gnu.org).
R-6
The interfacing of the modules will be defined in agreement with the
Agency during Task 1.
R-7
The software shall implement the functions calibration, equalization, deconvolution, de-noising, co-registration, ortho-rectification and mosaicking
according the general guidelines presented in section 2.2 (Image
processing chain description).
R-8
Image correlation shall be based on dichotomic re-sampling. Other
approaches can be included as options.
R-9
The mosaicking function shall be consistent with resolutions of 10m or
lower, i.e. minimization of hidden areas is not mandatory
R-10
The processing chain shall be implemented for a high spatial resolution
(metric to decametric) imaging sensor with a rectangular geometry.
Sentinel-2 shall be taken as reference mission in the development of
software, i.e. the functions implemented shall be a first prototype of what
could be an operational image processor for the Sentinel-2 mission.
R-11
The ortho-rectification module shall be implemented using an automated
methodology based on ground control points (GCPs) and/or TPs (Tie
Points). The ortho-rectification can possibly use RPC (Rational Polynomial
Coefficient) functions.
R-12
The chain shall be optimised in terms of processing time.
R-13
The chain shall be developed considering a data volume for processing
similar to the one foreseen for Sentinel-2 [RD-20].
R-14
The processing chain shall be designed and implemented in order to ensure
autonomy, i.e. operation without requiring human intervention.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 33 of 34
Version: 1
Révision: 3
Date: 12/04/2007
Requirement
Description
R-15
Image re-sampling shall be performed using a selectable re-sampling
method, including at least:
- Windowed truncated Shannon interpolation, also called Hamming
window re-sampling.
- High-order B-spline interpolation.
- Bi-cubic convolution interpolation.
ESTEC
The Netherlands
Tel: +31 71 565 6565 Fax: +31 71 565 5060
Page 34 of 34

Définition et prototypage d`une chaîne de traitement d`image

Transcription

Documents pareils

Ingénieurs Software Embarqué

Arrivée d`une nouvelle version

Télécharger CV - Andries Fabrice

X340/X340n/X342n MFP

Essai Florian Cramer - "L`art logiciel "

Banque Populaire décentralise la gestion des temps

Software Engineer with a minimum of 5 years of experience

Future Facilities et nlyte Software s`associent pour

GoMotion de Ligos Software, un logiciel d

Easyphone et Holy-Dis s`allient pour renforcer leur positionnement