SBAS-ASECNA - Phase B - TDR V1.2

TERMES DE REFERENCE
---
REALISATION DE L’ETUDE PRELIMINAIRE DE DEFINITION
D’ARCHITECTURE, DITE PHASE B, DU PROGRAMME
SBAS-ASECNA
- 1/67 -
Programme SBAS-ASECNA - Etude phase B - Termes de référence - Version 1.2 - Novembre 2018
SOMMAIRE
1. INTRODUCTION ......................................................................................................... 3
1.1. CONTEXTE : LE PROGRAMME SBAS-ASECNA .......................................... 3
1.2. LOGIQUE DU PROGRAMME ET CONTEXTE de l’ETUDE ............................ 4
1.3. OBJET ET STRUCTURE DU DOCUMENT ..................................................... 6
1.4. DOCUMENTS APPLICABLES ........................................................................ 8
1.5. DOCUMENTS DE REFERENCE .................................................................... 10
1.6. ACRONYMES ET ABREVIATIONS ............................................................... 12
2. PHASE DE DEFINITION : OBJECTIFS DE L’ACTIVITE ......................................... 14

2.1. OBJECTIFS de l ’ETUDE .............................................................................. 14
2.2. ETUDES ANTERIEURES............................................................................... 18
2.3. MISSION SBAS-ASECNA ............................................................................. 19
3. EXIGENCES GENERALES ...................................................................................... 20

3.1. EXIGENCES TECHNIQUES .......................................................................... 20
3.2. EXIGENCES d’APPROVISIONNEMENT ....................................................... 20
3.3. EXIGENCES CALENDAIRES ........................................................................ 20
3.4. EXIGENCES ECSS ........................................................................................ 20
3.5. EXIGENCES DE GESTION DE PROJET....................................................... 20
3.6. ASSURANCE PRODUIT, SURETE de FONCTIONNEMENT et SECURITE 21
3.7. Exigences relatives aux droits de propriété intellectuelle ........................ 22
4. EXIGENCES DETAILLEES. TACHES A REALISER ............................................... 23

4.1. ORGANIGRAMME DES TÂCHES ................................................................. 23
4.2. DESCRIPTION DES TÂCHES ....................................................................... 25
5. LISTE DES LIVRABLES........................................................................................... 58
6. CALENDRIER ET ECHEANCES .............................................................................. 62

6.1. PHASES et JALONS ..................................................................................... 62
6.2. POINTS-CLES et REVUES ............................................................................ 62
7. FOURNITURES ASECNA ........................................................................................ 64

7.1. LISTE DES FOURNITURES (CFI) ................................................................. 64
8. ANNEXES ................................................................................................................. 65
8.1. DESCRIPTION DES ANALYSES SYSTEME ................................................ 65
8.2. PERSONNEL CLE ......................................................................................... 66
- 2/67 -
1. INTRODUCTION
1.1. CONTEXTE : LE PROGRAMME SBAS-ASECNA

1.1.1. Définition
Le programme SBAS-ASECNA constitue l’ensemble des activités et projets concourant de manière
interdépendante et transversale aux objectifs fixés par l’ASECNA en matière de fourniture de services de
navigation par satellite fondés sur EGNOS, en lien avec le Plan d’Orientation Stratégique de l’Agence :
• Fournir, dans la zone de sa responsabilité à moyen terme, puis de manière étendue au sein de la
région AFI, des services SBAS pour renforcer les opérations de navigation (PBN) et de surveillance
au cours de toutes les phases de vol, améliorant ainsi de manière significative et durable la sécurité
et l’efficacité des vols ;
• Renforcer et étendre son positionnement comme fournisseur de services de navigation aérienne à
haute-valeur ajoutée, et préparer ainsi son avenir en œuvrant à son rayonnement et à son leadership
au plan international.
Ce programme, basé essentiellement sur l’introduction des services avancés de navigation par satellite,
constitue une évolution technologique majeure et essentielle pour l’Agence à l’instar de ce qu’ont été les
services de télécommunications aéronautiques par satellite au cours des années 1995. Cette évolution
nécessite une gestion anticipée, car induisant une mutation profonde de la nature des services rendus, des
infrastructures et des procédures, des métiers et des compétences requises pour leur fourniture, ainsi que de
leur mode de gouvernance de par leur caractère global, dépassant les frontières de souveraineté des Etats et
de responsabilité des organisations internationales. Dans sa vision non seulement de préparer et maitriser
cette évolution technologique, l’Agence vise également le développement et le renforcement de ses capacités
en matière de fourniture de services, en faisant le choix résolu de la propriété de l’infrastructure
correspondante, ainsi que du contrôle et de la fourniture de manière autonome des signaux et des services
vers les usagers finaux.
1.1.2. Besoins opérationnels

Au-delà de cette vision stratégique, le programme répond à des besoins opérationnels de renforcement des
opérations de navigation et de surveillance. Les services SBAS seront en particulier des catalyseurs
importants du PBN, notamment pour les services d’approche à guidage vertical (RNP APCH APV) offrant une
solution efficiente pour des opérations équivalentes aux procédures ILS CAT-I « partout et à tout moment ».
Ces services permettront à termes des gains importants et durables en matière de sécurité et d’efficacité des
vols, en particulier sur le nombre important de seuils de pistes non desservis actuellement par des approches
de précision, sans aucun besoin de mise en œuvre locale d’infrastructure et de personnel. Ce qui constitue
une solution adaptée voire appropriée surtout pour les aéroports situés dans les régions isolées (difficiles
d’accès) et/ou soumises à des problèmes de sûreté ou de sécurité.
Concernant la sécurité des vols, la réduction des CFIT constitue un enjeu extrêmement important, dans un
contexte où, sur la période 2011-2015, les accidents de ce type ont représenté 20% des cas de décès, dont
la majorité d’entre eux se sont produits en phase d’approche et d’atterrissage, et étant souvent associées à
des approches de non précision (source IATA).
Concernant l’efficacité des vols, les bénéfices des services SBAS se traduiront par une réduction significative
des délais et des déroutements des vols, l’introduction d’approches plus précises et directes, des trajectoires
de vol plus optimisées, une amélioration de l’accessibilité aux aéroports et aux régions isolées, une réduction
des temps de vol, de la consommation de carburant, de l’emport réduit de la quantité de carburant, une
réduction des nuisances sonores et des gaz à effet de serre etc.
- 3/67 -
1.2. LOGIQUE DU PROGRAMME ET CONTEXTE de l’ETUDE

Dans le cadre de la mise en œuvre des services SBAS, l’Agence a opté pour l’adoption d’une démarche portée
par le volontarisme et le pragmatisme tout en recherchant des gains rapides à travers des services pionniers
en favorisant une démarche de mise en œuvre graduelle en matière de couverture et de performances des
services, prenant en compte les évolutions technologiques, et une transformation continue des métiers et des
compétences requises pour la fourniture de ces services. L’approche sera ainsi basée sur le principe du
développement évolutif permettant de satisfaire progressivement les besoins opérationnels à travers des
étapes courtes, réalisables, mesurables, favorisant un retour d’expérience et permettant des prises de
décisions intermédiaires, par opposition à une approche qui viserait l’atteinte d’une couverture et des
performances complètes en une seule étape.
En application d’une telle approche progressive adoptée, les objectifs de fourniture des services SBAS-
ASECNA, fondés sur EGNOS se déclinent suivant deux étapes principales :
 Etape 1 : Fourniture de services « initiaux » (mono-fréquence GPS L1) à partir de 2021/2022 ;
 Etape 2 : Fourniture de services « complets » (bi-fréquence GPS L1/L5 et Galileo E1/E5) au-delà de
l’horizon 2028-2030.
La mise en œuvre de ces services se fera par incrémentation à travers une ou plusieurs sous-étapes, c’est à
dire avec une ou plusieurs évolutions système offrant des niveaux et des zones de service croissants. Sur le
plan de gestion du signal dans l’espace (SiS), il se fera par le support d’un service de sauvegarde de la vie
humaine (SoL) équivalent au signal « Safety of Life » fourni en Europe.
Sur le plan de l’infrastructure, un des principes fondamentaux du programme consistera pour l’Agence à
exploiter les actifs notamment la documentation, les matériels et les logiciels développés ou qui seront
développés pour EGNOS en Europe. Ce principe justifie de la nécessité d’une signification de « services
fondés sur EGNOS » et d’évolution de manière concomitante avec le programme Européen. La stratégie
associée consistera à utiliser ces actifs en les adaptant pour les besoins de l’infrastructure ASECNA, avec si
nécessaire des développements spécifiques, répondant à des évolutions technologiques propres.
L’acquisition des composants de l’infrastructure devra donc porter autant que possible sur des éléments
récurrents. L’objectif ainsi recherché est de bénéficier au maximum des développements réalisés en Europe
et de limiter les coûts de développement. Par ailleurs, en matière de technologie, tout développement d’un
composant requis pour l’étape 2, mais qui serait disponible en temps utile, et compatible, pour l’étape 1, sera
en principe utilisé pour cette dernière. Là où ce n’est pas le cas, l’ASECNA se réserve la possibilité, le cas
échéant, de développer une caractéristique technologique propre permettant donc de bénéficier dès l’étape 1
d’améliorations système et de favoriser la transition vers l’étape 2.
Sur le plan de l’ingénierie des systèmes, les cycles de vie pour ces deux principaux objectifs de fourniture de
services (étapes 1 et 2), et leurs évolutions intrinsèques, comprennent les phases suivantes conformément
aux bonnes pratiques de gestion des programmes spatiaux :
 Pré-phase B : Besoins, missions, faisabilité ;
 Phase B : Définition préliminaire (en deux sous phases B1, puis B2) ;
 Phase C : Définition détaillée ;
 Phase D : Production et qualification ;
 Phase E : Exploitation.
Après les avancées réalisées en matière de Recherche et Développement au cours des dernières années,
notamment celles issues des travaux de caractérisation de l’ionosphère dans le cadre du projet SAGAIE avec
le CNES, et des expérimentations, et des preuves de concepts dans le cadre des projets SIRAJ, MAGNIFIC
ou ACCEPTA, le programme SBAS-ASECNA rentre dans la phase B pour les services SBAS-ASECNA
initiaux.
- 4/67 -
Les objectifs de cette étude phase B sont :

 Définir et justifier la meilleure option de l’architecture qui soutiendra la fourniture des services SBAS-
ASECNA initiaux ;
 Préparer et permettre à l’ASECNA de disposer d’une visibilité complète sur les phases suivantes C/D de
mise en œuvre (définition détaillée, production et qualification) et d’exploitation E pour les services SBAS-
ASECNA initiaux (Etape 1), sur leurs évolutions suivantes, et sur la transition vers les services SBAS-
ASECNA complets (Etape 2).
Cette visibilité complète comprendra une base technique (architecture, performances, plan de développement
et de déploiement incluant les couts associés) dont la maturité doit permettre d'engager l'ensemble des
activités des phases C/D.
- 5/67 -
1.3. OBJET ET STRUCTURE DU DOCUMENT

1.3.1. Objet
Ce document décrit les Termes de référence pour la réalisation de l’étude préliminaire de définition
d’architecture, dite phase B, du programme SBAS-ASECNA.
Il constitue un des éléments du Dossier d’Appel d’Offres pour la sélection d’un consultant pour la réalisation
de ladite étude.
1.3.2. Structure et contenu

Le présent document, complété par ses documents applicables et de référence cités, spécifie le travail à
réaliser et les contraintes à prendre en compte par le soumissionnaire, dans le cadre de l’étude de phase B.
Il est structuré de la façon suivante :
 En introduction (section1), on rappelle la définition et la logique du programme SBAS-ASECNA, le
contexte et l’objet de l’étude, ainsi que ses documents applicables et ses documents de référence.
 La section 2 définit les objectifs de l’étude, la démarche à suivre, et les résultats à atteindre.
 La section 3 fournit les exigences générales relatives à la gestion de l’étude et à la qualité.
 La section 4 détaille les tâches à réaliser et les éléments à produire.
 La section 5 rappelle la liste des livrables et indique leurs échéances.
 La section 6 précise le calendrier de l’étude et ses jalons.
 La section 7 indique les fournitures de l’ASECNA pour les besoins de l’étude.
Enfin, une Annexe décrit les principales analyses système à réaliser en phase B.
1.3.3. Définitions
Le système SBAS-ASECNA est le système de radionavigation par satellite de l’ASECNA qui contrôle et
corrige les signaux émis par les systèmes de radionavigation par satellites, principalement GPS et Galileo,
permettant aux utilisateurs de ces systèmes mondiaux d’obtenir de meilleures performances, notamment en
termes de précision, et d’intégrité. SBAS-ASECNA est la propriété de l’ASECNA. Il comprend une
infrastructure au sol et plusieurs transpondeurs installés sur des satellites géostationnaires. L’infrastructure au
sol sera constituée notamment de stations RIMS, d’un ou plusieurs centres de contrôle de la mission et de
stations NLES. La couverture de SBAS-ASECNA est prioritairement la zone de compétence de l’ASECNA.
Par système SBAS-ASECNA s’entend aussi bien la version initiale du système que toutes ses évolutions
successives, y compris les évolutions double fréquence et multi constellation. La mise en place de ce système
comprend notamment des phases de définition et de conception, de développement et de déploiement, et
d’homologation et de certification. Elle est suivie d’une phase d’exploitation.
Dans ce document, le terme « Système » désigne l’infrastructure sol du système SBAS-ASECNA. Les
constellations de satellites (GPS, Galileo), les transpondeurs installés sur des satellites géostationnaires
(GEOs) ainsi que le milieu de propagation (troposphère, ionosphère) ne font pas partie de la définition du
« Système », et sont des composantes externes au Système. Cependant elles contribuent aux performances
clefs du Système, c’est pourquoi elles doivent être prises en compte (en tant que contributeurs externes) dans
l’analyse dudit système, de ses interfaces et de ses coûts.
Le terme « Segment » désigne les principales chaînes fonctionnelles du Système (Acquisition de Données,
Traitement de données, Dissémination de données, etc…) plus le Segment Support.
Le terme « Sous-système » désigne les éléments appartenant au niveau inférieur au niveau segment.
Typiquement, dans le système EGNOS, le CPF est considéré comme sous-système du segment de de
Traitement de données, et les RIMS sont considérées comme sous-système du segment de Collecte de
données.
- 6/67 -
Le terme « Elément critique » désigne un composant matériel (HW) ou logiciel (SW) d’un sous-système qui
a une forte influence sur le Système et peut induire certains risques en termes de :
 Performances (en particulier intégrité et continuité) ;
 Sécurité et sûreté ;
 Cycle de développement et calendrier (déploiement, transitions, mise en service, …)
 Risque technologique ;
 Opérabilité ;
 Coût de possession ;
 Certification (notamment dans le cas d’un composant réutilisé et modifié).
Le terme « Opération » recouvre, dans ce document, les activités telles que :
 Opérations du Système et Maintenance ;
 Opérations du Centre de Service ;
 Entrainement, formation ;
 Analyse et prédictions de performances, interface ATM (NOTAM) ;
 Surveillance du service au travers de récepteurs représentatifs de la communauté utilisateur du service
SoL.
- 7/67 -
1.4. DOCUMENTS APPLICABLES

Ces documents applicables sont mis à disposition avec les présents Termes de Référence, à l’exception des
documents ISO, EUROCAE/RTCA et OACI, et des standards ECSS.
Pour tous ces documents, par défaut, la dernière version parue et entrée en vigueur est applicable.
DA1 : Document spécifications et objectifs généraux (HLRD) SBAS-ASECNA, V1.1 (Novembre 2018)
DA2 : Exigences de sécurité de l’ASECNA

 DA2.1 : Document 9859 de l’OACI
 DA2.2 : Annexe 19 de l’OACI
 DA2.3 : Manuel SMI de l’ASECNA
 DA2.4 : Procédure de réalisation des études de sécurité de l’ASECNA (R1.5-PRO-02-A)
NB : Un complément de référentiel en matière de Sécurité pourrait être fourni en début d’exécution de l’étude.
DA3 : Exigences de sureté de l’ASECNA

 DA3.3 : Annexe 17 de l’OACI
 DA2.3 : Manuel SMI de l’ASECNA
 DA3.4 : Norme ISO 27002 - Code de bonne pratique pour le management de la sécurité de l’information
(pour la structuration de l’analyse de sureté)
NB : Un complément de référentiel en matière de Sûreté pourrait être fourni en début d’exécution de l’étude.
DA4 : Standards SBAS

 DA4.1: Minimum Operational Performance Standards for Global Positioning System/Wide Area
Augmentation System Airborne Equipment RTCA MOPS DO-229C, 28/11/2001
 DA4.2: Minimum Operational Performance Standards for Global Positioning System / Wide Area
Augmentation System Airborne Equipment”, RTCA MOPS DO-229D with Change 1, 1st February 2013
 DA4.3: Minimum Operational Performance Standards for Global Positioning System/Satellite-Based
Augmentation System Airborne Equipment RTCA MOPS DO-229E, 15th December 2016
 DA4.4: ICAO Standards and Recommended Practices (SARPs), Annex 10 of the Chicago Convention,
Volume 1, including amendments up to 89 dated the 13/11/2014
 DA4.5: ICAO Standards and Recommended Practices (SARPs), Annex 10, Part 1, Amendment 90 10th
November 2016
DA5 : Documents de contrôle de l’Interface Signal (SiS)

 DA5.1: European GNSS (Galileo) Open Service Signal in Space Interface Control Document
 DA5.2: Global Positioning Systems Directorate, Systems Engineering & Integration, Interface
Specification, IS-GPS-200, NAVSTAR GPS Space Segment/Navigation User Segment Interfaces
 DA5.3: Global Positioning Systems Directorate, Systems Engineering & Integration, Interface
Specification, IS-GPS-705 (L5 frequency), NAVSTAR GPS Space Segment/Navigation User Segment
Interfaces
 DA5.4: Global Positioning System Standard Positioning Service Performance Standard (SPS)
- 8/67 -
DA6 : Standards ECSS

NB : Charge au soumissionnaire de proposer l’adaptation de ces standards aux besoins de l’étude
 Project planning and implementation ECSS-M-ST-10C
 Configuration and information management ECSS-M-ST-40C
 Integrated Logistic Support ECSS-M-70A
 Risk Management ECSS-M-ST-80C
 Description, implementation and general requirements ECSS-S-ST-00C
 Organization and conduct of reviews ECSS-M-ST-10-01C
 Cost and schedule management ECSS-M-ST-60C
 System engineering general requirements ECSS-E-ST-10C
 Ground Systems and Operations ECSS-E-ST-70C
 Technical Requirements Specification ECSS-E-ST-10-06C
 Human Factors Engineering ECSS-E-ST-10-11C
 Interface management ECSS-E-ST-10-24C
 Product Assurance management ECSS-Q-ST-10C Rev.1
 Critical Item control ECSS-Q-ST-10-04C
 Non-conformance control system ECSS-Q-ST-10-09C
 Quality Assurance management ECSS-Q-ST-20C Rev1
 Storage, handling and transportation of hardware ECSS Q-ST-20-08C
 Dependability ECSS-Q-ST-30C Rev.1
 Failure modes, effects (and criticality) analysis ECSS-Q-ST-30-02C
 Availability analysis ECSS-Q-ST-30-09C
 Safety ECSS-Q-ST-40C Rev.1
 Hazard analysis ECSS-Q-ST-40-02C
 Fault Tree Analysis ECSS-Q-ST-40-12C
 Software ECSS-E-ST-40C
 Software product assurance ECSS-Q-ST-80C Rev.1
DA7 : Concept d’Opération de l’ASECNA

 DA7.1 : Enoncé de Politique de Maintenance du Directeur Général
DA8 : Directives EUROCAE

 DA8.1: Guideline for Communication, Navigation, surveillance, and air traffic management (CNS/ATM)
systems software Integrity Assurance (ED-109/DO- 278)
 DA8.2: Software Considerations in Airborne Systems and Equipment Certification (ED-12C/DO-178B)
 DA8.3: Design Assurance Guidance for Airborne Electronic Hardware (ED-80/DO-254)
- 9/67 -
1.5. DOCUMENTS DE REFERENCE

Ces documents de référence sont mis à disposition avec les présents Termes de Référence, à l’exception des
règlements européens qui sont publics.
Pour tous ces documents, par défaut, la dernière version parue et entrée en vigueur est à prendre en compte.
DR1 : Extraits des documents applicables au système EGNOS v2.4.2

Note ; Documentation appartenant à l’Union européenne :
 DR1.1: EGNOS V2 Mission Requirements Document, EC-EGN-MRD 2.2 rev 1.
 DR1.2: EGNOS V2 System Requirements Document (V2 SRD) E-RD-SYS-E-001-ESA, Issue 8.5.1
DR2 : Extraits des documents applicables au système EGNOS v3

Note : Documentation appartenant à l’Union européenne
 DR2.1 : EGNOS V3 Mission Requirements Document V1.2 (25/11/2015)
 DR2.2: SBAS L5 DFMC Interface Control Document, GNSS-EV3-ST-ESA-X-00120, Issue 1 Revision 4
(15/03/2017)
 DR2.3: Assumptions on the DFMC SBAS MOPS, GNSS-EV3-TN-ESA-X-00159, Issue 1.3 (07/03/2017)
 DR2.4: European GNSS (Galileo) Initial Services, Open Service, Service Definition Document
 DR2.5: N/A
 DR2.6: EGNOS V3 Phase C/D - Complementary Assumptions on Galileo constellation performances
ESA-EGN-V3-TN-0006, Issue 1.1 (15/03/2017)
 DR2.7 EGNOS V3 Phase C/D - Complementary Assumptions on GPS constellation performances
ESA-EGN-V3-TN-0007, Issue 1.1 (15/03/2017)
 DR2.8: Extrait de EGNOS V3 Phase C/D - System Engineering Statement of Work (pages 95 to 98)
 DR2.9: Extrait de EGNOS V3 Phase C/D - Software and Hardware Requirements from Engineering to
Qualification (SHREQ) (pages 92 à 166)
 DR2.10: Extrait de EGNOS V3 Operations Cost Model Requirements & V2 Summary Operations Costs
Benchmark Report
DR3 : Règlements européens applicables au SBAS

Outre les standards ECSS qui relèvent des bonnes pratiques en matière d’ingénierie des systèmes et qui sont
applicables à l’étude, on tiendra compte également des règlements européens suivants :
 Regulation (EC) No 1070/2009 of the European parliament and of the council of 21 October 2009
amending Regulations (EC) No 549/2004, (EC) No 550/2004, (EC) No 551/2004 and (EC) No 552/2004
in order to improve the performance and sustainability of the European aviation system;
 Commission implementing regulation (EU) 2017/373 of 1 March 2017 laying down common
requirements for providers of air traffic management/air navigation services and other air traffic
management network functions and their oversight, repealing Regulation (EC) No 482/2008,
Implementing Regulations (EU) No 1034/2011, (EU) No 1035/2011 and (EU) 2016/1377 and amending
Regulation (EU) No 677/2011;
 [2014/30/EU] Electromagnetic compatibility, immunity and emissions;
 [2014/35/EU] Product safety (low Voltage);
 [2014/53/EU] Radio Equipment;
 [2011/65/EU] Restriction of Hazardous Substance (RoHS2);
 [2012/19/EU] Waste Electrical and Electronic Equipment (WEEE);
 [EC regulation 1907/2006] Registration, Evaluation, Authorization and Restriction of Chemicals
(REACH).
- 10/67 -
DR4 : Résultats d’études antérieures

 DR4.1 : Caractérisation de l’ionosphère : Etudes SAGAIE (CNES/TAS-F).
o NT3-1 : Note sur la variabilité de l’ionosphère observée en région équatoriale via les bandes
GPS/Glonass/Galileo (V1.1, 10/09/2015)
o NT3-2 : Note décrivant et justifiant la méthode sélectionnée pour calculer les grilles ionosphériques
en zone équatoriale (V2, 15/12/2015)
o NT4 : Note technique décrivant les scintillations ionosphériques et l’impact sur la disponibilité du
service EGNOS (V2.0, 15/12/2015),
o NT5 : Note technique « Impact des bulles plasmiques sur l’intégrité mono fréquence (V2.0,
15/12/2015)
 DR4.2 : ASECNA Description du Réseau de Télécommunication par satellite de l’ASECNA.
 DR4.3 : Enquête sur les solutions géostationnaires : EGNOS- Africa Joint Programme Office (JPO).
Final Report for ASECNA GNSS/EGNOS Programme GEO SURVEY (Step 1, Pre-phase B, Project P-
01-05)
- 11/67 -
1.6. ACRONYMES ET ABREVIATIONS

AIVQ Assemblage, Intégration, Vérification et Qualification
AFI Région Afrique et Océan Indien (Africa Flight Information)
APV Procédure d'approche avec guidage vertical (Approach Procedure with Vertical Guidance)
ASECNA Agence pour la Sécurité de la Navigation Aérienne en Afrique et à Madagascar
ATM Gestion du trafic aérien (Air Traffic Management)
CAPEX Dépenses d'investissement (CAPital EXpenditure)
CAT Catégorie d’approche aéronautique
CBA Analyse coût-avantage (Cost-Benefit Analysis)
CFI Fournitures du Client (Customer Furnished Item)
CFIT Collision avec le sol en vol piloté (Controlled Flight Into Terrain)
COTS Equipement sur étagère (Commercial Off The Shelf)
CPF Unité centrale de traitement (Central Processing Facility)
DAL Niveaux de criticité (Development Assurance Level)
DJF Dossier de justification
DOP Dilution de Précision (Dilution of Precision)
ECSS European Cooperation for Space Standardization
EGNOS Système européen de navigation par recouvrement géostationnaire (European Geostationary
Navigation Overlay Service)
EM-UE États membres de l'Union européenne
DFMC Services bi-fréquence et multi constellation (Dual Frequency & Multi Constellation)
FIR Région d'information de vol (Flight Information Region)
FDIR Détection, Isolation et Recouvrement de Pannes (Fault Detection, Isolation and Retrieval)
FE Evènement redouté (Feared Event)
FMECA Failure Mode, Effect and Criticality Analysis
Galileo E1 Fréquence E1 du système Galileo, correspondant à 1 575,42 MHz
Galileo E5a Fréquence E5a du système Galileo, correspondant à 1 176,45 MHz
GPS Système de positionnement mondial (Global Positioning System)
GPS L1 Fréquence L1 du système GPS, correspondant à 1 575,42 MHz
GPS L5 Fréquence L5 du système GPS, correspondant à 1 176,45 MHz
GNSS Global Navigation Satellite System
HAL Limite d'alerte horizontale (Horizontal Alert Limit)
HLRD Document de spécifications de haut niveau (High Level Requirement Document)
IERS Service international de la rotation terrestre et des systèmes de référence (International Earth
Rotation and Reference Systems Service)
I&CoS Intégrité et Continuité du Service (Intégrity and Continuity of Service)
LCC Coûts du Cycle de Vie (Life Cycle Cost)
LPV Performance d'alignement de piste avec guidage vertical (Localizer Performance with Vertical
guidance)
MOPS Normes de performances opérationnelles minimales (Minimum Operational Performance
Standards)
MRD Exigences Mission (Mission Requirement Document)
NOTAM Messages aux navigants aériens (Notice to AirMen)
OPEX Dépenses d'exploitation (OPerational EXpenditure)
OS Service ouvert (Open Service)
OACI Organisation de l'Aviation Civile Internationale
PBMF Fichier des Performances (Performance Budget & Management File)
PBN Navigation Basée sur la Performance (Performance Based Navigation)
PDR Revue de Définition Préliminaire (Preliminary Design Review)
PK Point Clef (PKM Point Clef Mission, PKA Point Clef Architecture)
RAMS Fiabilité, disponibilité, maintenabilité, et sécurité (Reliability Availability Maintenability Safety)
RIMS Stations de télémétrie et de contrôle d'intégrité (Ranging and Integrity Monitoring Stations)
- 12/67 -
NPR Normes et pratiques recommandées

SDAS Service d'accès aux données SBAS-ASECNA (SBAS-ASECNA Data Access Service)
SBAS Système de renforcement satellitaire (Satellite-Based Augmentation System)
SIS Signaux émis par les systèmes GNSS (Signal In Space)
SoL Sauvegarde de la vie (Safety of Life)
SRR Revue des Exigences Système (System Requirement Review)
SRD Document d’Exigences Système (System Requirement Document)
UTC Temps universel coordonné (Universal Time Coordinated)
VAL Limite d'alerte verticale (Vertical Alert Limit)
- 13/67 -
2. PHASE DE DEFINITION : OBJECTIFS DE L’ACTIVITE
2.1. OBJECTIFS de l ’ETUDE

2.1.1. Objectifs généraux
Les objectifs généraux de l’étude phase B sont les suivants :
 Définir et justifier la meilleure option de l’architecture qui soutiendra la fourniture des services SBAS-
ASECNA initiaux ;
 Préparer et fournir une visibilité complète sur les phases suivantes de mise en œuvre (C/D) et
d’exploitation (E) pour les services SBAS-ASECNA initiaux (Etape 1), sur leurs évolutions suivantes, et
sur la transition vers les services SBAS-ASECNA complets (Etape 2).
Cette étude est divisée en deux sous phases dont les objectifs de haut niveau sont les suivants :
 En phase B1 :
o Etablir les documents d’exigences mission (MRD) et d’exigences système (SRD) ;
o Définir le système à un niveau compatible d’une revue SRR, au sens des standards ECSS, et qui
permette d’autoriser le passage en phase B2 ;
o Fournir les éléments préliminaires (coûts, plan de développement, scénarios de déploiement) pour
alimenter la préparation de la phase C/D au niveau programme.
 En phase B2 :
o Choisir l’architecture de référence du système ;
o Compléter la définition du système à un niveau compatible d’une revue PDR, au sens des standards
ECSS, et qui permette d’autoriser une transition directe (sous réserve du succès de la PDR) vers les
phases C/D ultérieures ;
o Consolider les éléments indiqués précédemment (coûts, plan de développement, …) afin de pouvoir
préparer la demande de proposition pour la phase C/D.
2.1.2. Résultats à atteindre

Les résultats à atteindre par le prestataire en charge de la réalisation de l’étude sont les suivants :
 L’ASECNA dispose des éléments pertinents (spécification des scénarios, outils et résultats de simulation
et d’analyse, estimation des coûts, critères d’évaluation etc.) pour sélectionner la meilleure option
d’architecture ;
 L’ASECNA dispose de l’ensemble de la documentation de conception préliminaire de l’infrastructure pour
l’option d’architecture retenue ;
 L’ASECNA est dotée d’un plan de développement et de mise en œuvre, avec évaluation des coûts
plafond, et d’un concept d’opérations, pour l’architecture retenue ;
 L’ASECNA est dotée d’une Spécification de Sécurité et de Sûreté qui lui permet de consolider les
conditions de certification et d’homologation du système ;
 L’ASECNA est dotée d’un plan d’évolutions pour les services SBAS-ASECNA initiaux et d’un plan de
transition vers les services SBAS-ASECNA complets.
Ces résultats doivent notamment permettre à l’ASECNA d'engager ensuite l'ensemble des activités des
phases C/D.
- 14/67 -
2.1.3. Démarche et activités principales

L’étude sera conduite conformément aux standards applicables (e.g. ECSS [DA6)) et aux bonnes pratiques
de gestion des programmes spatiaux en Europe. Sa durée maximale est de 18 mois.
Les principales activités envisagées sont :
 Activité 1 : Gestion de l’étude et coordination externe ;
 Activité 2 : Consolidation des services et détermination des exigences ;
 Activité 3 : Elaboration des scénarios d’infrastructure ;
 Activité 4 : Développement d’un prototype système et études de performances ;
 Activité 5 : Conception préliminaire du système ;
 Activité 6 : Elaboration d’un plan de développement et de mise en œuvre, avec détermination des coûts.
L’étude comprend 4 jalons principaux :

 Le Point Clé Mission (PKM) en début de phase B1 ;
 La Revue des Exigences système (SRR) en fin de phase B1 ;
 Le Point Clé de décision de l’option d’architecture (PKA) en milieu de phase B2 ;
 La revue de définition préliminaire (PDR) en fin de phase B2.
Le planning indicatif de l’opération dans laquelle s’inscrit cette étude de phase B est le suivant :
L’Activité 1 s’exerce tout au long de l’étude. Les Activités 2 et 3 sont à réaliser en phase B1. Les Activités 4, 5
et 6, préparées en phase B1, sont à réaliser en phase B2.
- 15/67 -
Il est demandé au consultant en charge de la réalisation de l’étude d’établir pour le Point-Clé Mission, et à
partir des documents applicables à ces Termes de Référence, le document d’exigences de mission (MRD),
puis de produire, sur cette base et pour la SRR, le document d’exigences système (SRD).
HLRD
MRD
Mission / Service
Système / Opérations
SRD
Pour la phase B2, le SRD devient document applicable (après approbation par l’ASECNA) et les spécifications
techniques du système seront alors construites en regard de ces exigences. Ce SRD sera consolidé au cours
de la phase B2.
Cependant, un certain support est attendu de la part du prestataire pour poursuivre la consolidation de la
définition de la Mission tout au long de l’étude. Cette consolidation s’effectue selon un processus incrémental
à l’occasion de chacun des jalons de l’étude tels que décrits section 6. En effet la cohérence entre le niveau
Mission (HLRD/MRD) doit être maintenue avec le niveau système (SRD).
De la même façon, les avancements du programme EGNOS, notamment le développement de certains actifs
(tels que les RIMS) devront être pris en compte de manière continue au cours de l’étude.
2.1.4. Objectifs détaillés de l’étude

Pour chaque phase (B1 et B2), on indique les objectifs détaillés de l’étude qui sont en lien soit avec la Mission
(M), le Système (S) ou le Programme (P) :
 La phase B1 qui a pour but de :

o 1M-1 : Consolider, à partir du HLRD, les besoins de mission et d’élaborer les documents d’exigence
de Mission (MRD) et d’exigences Système (SRD) ;
o 1M-2 : Consolider les exigences de sécurité et de sureté applicables au Système ;
o 1S-1 : Consolider la documentation système notamment à partir de la documentation issue du
système EGNOS ;
o 1S-2 : Elaborer la première version des Spécifications Techniques du Système, de ses interfaces
externes et de son Concept d’Opération ;
o 1S-3 : Elaborer les scénarios d’infrastructure (selon les scénarios de déploiement envisagés dans le
HLRD) ;
o 1S-4 : Comparer les performances des différents scénarios par rapport au scénario de base et
élaborer une architecture Système (jusqu’au niveau segment) pour le scénario proposé comme
référence à la SRR ;
o 1S-5 : Spécifier le prototype système et les expérimentations à réaliser en phase B2 ;
o 1S-6 : Construire le premier niveau des spécifications techniques des sous-systèmes ;
o 1S-7 : Consolider les performances Système (incluant I&COS et RAMS), et le Fichier d’Assurance
Sécurité (SAF) ;
o 1S-8 : Déterminer la stratégie de qualification ;
o 1S-9 : Fournir pour la SRR des éléments quant aux évolutions nécessaires du réseau de
télécommunication ;
o 1P-1 : Etablir une méthodologie d’estimation des coûts (CAPEX + OPEX) ;
- 16/67 -
o 1P-2 : Fournir, pour la revue SRR, l’ensemble de la documentation conforme aux standards ECSS
[DA6] permettant le passage en phase B2 (sous réserve de la décision de l’ASECNA) ;
o 1P-3 ; Proposer des objectifs de certification et d’homologation (les conditions de certification
applicables à EGNOS seront utilisées par défaut).
 La phase B2 qui a pour but de :

o 2M-1 : Consolider les exigences Système (SRD) et maintenir leur cohérence avec les exigences de
Mission ;
o 2S-1 : Développer le prototype système et mettre en œuvre les expérimentations / études de
performances ;
o 2S-2 : Consolider, pour l’architecture système de référence et le scénario de déploiement décidés
au PKA, les Spécifications Système, la Spécification de Sécurité et de Sûreté et le Concept
d’Opération ;
o 2S-3 : Compléter la définition préliminaire du système jusqu’au niveau des sous-systèmes et de leurs
éléments critiques ;
o 2S-4 : Spécifier et définir l’ensemble des interfaces internes et externes
o 2S-5 : Etablir une définition préliminaire des procédures d’opération, pour la maintenance et la
logistique, et pour le segment support
o 2P-1 : Raffiner les estimations de coûts en support aux analyses CBA (CAPEX et OPEX) et
consolider le choix d’architecture système de référence ;
o 2P-2 : Evaluer les coûts des phases C/D puis E ;
o 2P-3 : Elaborer un plan de développement et de mise en œuvre, en détaillant les transitions
identifiées ;
o 2P-4 : Etablir l’état de conformité de la définition du système et de ses exigences, avec le dossier
justificatif associé ;
o 2P-5 : Fournir, pour la revue PDR, l’ensemble de la documentation conforme aux standards ECSS
[DA6] permettant le passage en phase C/D (sous réserve de la décision de l’ASECNA) ;
o 2P-6 : Consolider les conditions de certification et d’homologation du Système.
- 17/67 -
2.2. ETUDES ANTERIEURES

Ce paragraphe concerne les études antérieures dont les résultats pourraient être exploités pour aider à la
réalisation des activités spécifiées.
2.2.1. Actifs et référentiels EGNOS

Comme rappelé en introduction, un des principes fondamentaux du programme SBAS-ASECNA consiste à
exploiter les actifs (documentation, matériels, logiciels) développés ou qui seront développés pour EGNOS en
Europe.
L’acquisition des composants de l’infrastructure devra donc porter autant que possible sur des éléments
récurrents. Par ailleurs, tout développement d’un composant (de type EGNOS V3) pour l’Etape 2 qui serait
disponible en temps utile, et compatible, pour l’Etape 1, sera en principe utilisé pour cette dernière. Là où ce
n’est pas le cas, l’ASECNA se réserve la possibilité, si elle le juge opportun, de développer une caractéristique
technologique propre, permettant donc de bénéficier dès l’Etape 1 d’améliorations système et de favoriser la
transition vers l’Etape 2.
Pour l’étude de phase B, les éléments du référentiel EGNOS cités en référence sont rendus disponibles, sous
autorisation de l’UE. D’autres actifs EGNOS, jugés complémentaires et pertinents pour la réalisation des
activités spécifiées, pourraient être identifiés en début de phase B1 (KOM), ainsi que leur calendrier de
disponibilité souhaitable.
2.2.2. Caractérisation de l’ionosphère

Le CNES et l’ASECNA ont déployé un réseau de stations de mesures GNSS (SAGAIE) en Afrique
subsaharienne. L’exploitation de ces mesures a permis d’une part d’améliorer la connaissance du milieu de
propagation (état de l’ionosphère suite au pic d’activité solaire de 2012-2013), et d’autre part de démontrer la
faisabilité de la fourniture d’un service SBAS mono fréquence en zone tropicale.
Les résultats de ces analyses et les flux de mesures issus de ce réseau peuvent être rendus disponibles pour
les besoins de l’étude, notamment pour les besoins la définition des modèles ionosphériques adaptés aux
zones de services et pour les besoins du prototype système à développer en phase B2. L’interface SAGAIE
consiste en la mise à disposition en temps différé des fichiers de mesures.
Le consultant peut proposer de faire bénéficier l’étude d’autres expériences, résultats ou mesures dont il
disposerait dans ce domaine.
2.2.3. Caractérisation du réseau de télécommunications de l’ASECNA

L’ASECNA dispose, pour ses besoins propres d’un réseau de télécommunication dont les caractéristiques
sont rendues disponibles afin d’évaluer son aptitude à satisfaire les besoins du système SBAS-ASECNA (y
compris au plan de la sûreté) et de spécifier les évolutions qui seraient nécessaires pour satisfaire lesdits
besoins. Les éléments quant aux évolutions nécessaires du réseau de télécommunication doivent être fournis
pour la SRR.
2.2.4. Enquête sur les solutions Géostationnaires

Une enquête sur les solutions envisageables en matière de relais Géostationnaires pour les besoins du SBAS
africain est rendue disponible. Elle devra être complétée en début de phase B par une définition, par le
consultant, des services attendus en matière de transpondeurs géostationnaires, de leur plan d’acquisition et
de leurs coûts. Les éléments quant au choix de ces services et leur niveau de redondance doivent être fournis
si possibles pour la SRR, et au plus tard au PKA.
- 18/67 -
2.2.5. Liste des sites potentiels pouvant héberger les éléments de l’infrastructure
sol du système SBAS-ASECNA
Une liste des sites potentiels pour l’accueil de l’infrastructure est indiquée dans le HLRD (DA1). La réutilisation
de certains sites de RIMS EGNOS et/ ou de leur flux de mesures doit faire l’objet d’une analyse concertée
avec le programme EGNOS. L'acceptation par ASECNA du réseau RIMS de référence est un objectif et critère
de succès de la SRR.
2.3. MISSION SBAS-ASECNA

Les objectifs de haut niveau, la nature des services à fournir et les zones de services à couvrir (et les scénarios
associés) ainsi que les principales exigences techniques et opérationnelles à satisfaire par le système SBAS-
ASECNA, et les contraintes opérationnelles spécifiques, sont indiqués dans le HLRD [DA1].
- 19/67 -
3. EXIGENCES GENERALES
Toutes les exigences numérotées de ces Termes de Référence, sous la forme [N], doivent être interprétées
comme : « le soumissionnaire doit ».
3.1. EXIGENCES TECHNIQUES

[1] réaliser une évaluation critique des exigences de ces Termes de Référence.
[2] évaluer la conformité de sa réponse à toutes les exigences contenues dans ces Termes de Référence, en
précisant l’état de sa proposition, soit conforme (C), en fournissant les éléments de preuve associés, soit non
conforme (NC) en regard de chaque exigence.
[3] aider l’ASECNA à consolider les exigences Mission et Système de cette phase de définition.
3.2. EXIGENCES d’APPROVISIONNEMENT

Les standards ECSS relatifs au processus d’approvisionnement s’appliquent pour tout élément approvisionné
au cours de la phase B.
3.3. EXIGENCES CALENDAIRES

[4] proposer et entretenir un planning général pour l’étude de phase B borné à 18 mois maximum et divisé en
deux sous-phases : (1) B1 : 6 mois (T0 à T0 + 6 mois maximum), (2) B2 : 12 mois (T0+6 mois maximum à
T0+18 mois maximum).
[5] fournir un planning détaillé (de type GANTT) de l’ensemble des tâches de son organigramme technique,
en explicitant ses dépendances à d’éventuelles fournitures externes, et en intégrant les marges proportionnées
aux risques identifiés.
3.4. EXIGENCES ECSS

[6] appliquer tous les standards ECSS référencés et adaptés à cette étude de phase B.
Note : pour cette adaptation, [DR2.8] et [DR2.9] pourront être utilisés.
[7] prendre en compte dans les plans à préparer pour les phases ultérieures (C/D) les standards ECSS
référencés qui sont adaptés à ces phases C et D.
3.5. EXIGENCES DE GESTION DE PROJET

[8] appliquer les standards ECSS propres aux études de type phase B pour la gestion de projet, les rapports,
les réunions d’avancement et les fournitures de cette étude.
[9] évaluer et atténuer les risques liés aux dépendances éventuelles à certaines activités externes au projet,
afin d’éviter toute situation de blocage ou de retard, ainsi que leurs impacts en terme de coût.
- 20/67 -
3.6. ASSURANCE PRODUIT, SURETE de FONCTIONNEMENT et

SECURITE
Outre l’exigence [6] concernant l’application des standards ECSS, les règles et directives listées dans cette
section doivent être considérés comme applicables.
3.6.1. DIRECTIVES ASECNA

[10] analyser et prendre en compte les contraintes opérationnelles spécifiques du système SBAS -ASECNA,
tels que définis dans le HLRD (DA1).
[11] appliquer les exigences de Sécurité de l’ASECNA définies en DA2.
[12] appliquer les exigences de Sureté de l’ASECNA définies en DA3.
3.6.2. DIRECTIVES EUROCAE

Le système SBAS-ASECNA devant fournir un service de Navigation aérienne, le fournisseur de ces services
devra être certifié, et des preuves de l’application d’une démarche qualité garantissant la sécurité du système
dans son ensemble seront alors exigées.
Ainsi, selon la démarche qualité mise en œuvre au travers de l’application des ECSS [DA6], la définition et le
développement des logiciels ou équipements électroniques utilisés dans les fonctions critiques doivent suivre
un processus spécifique, selon leur niveau de criticité, afin d’assurer le niveau d’intégrité exigé.
Pour faciliter la certification finale des services fournis par le système SBAS-ASECNA, on considère les
directives EUROCAE utilisées en aéronautique et reconnues par les Autorités de Certification comme preuves
acceptables de conformité [DA8]. Par défaut, les dernières versions de ces directives parues et entrées en
vigueur sont applicables.
[13] doit appliquer la directive “Guideline for Communication, Navigation, surveillance, and air traffic
management (CNS/ATM) systems software Integrity Assurance” (ED-109/DO- 278) pour garantir l’intégrité
des logiciels critiques, Cette directive doit être utilisée en conjonction avec le document “Software
Considerations in Airborne Systems and Equipment Certification” (ED-12C/DO-178B).
[14] doit appliquer la directive “Design Assurance Guidance for Airborne Electronic Hardware” (ED-80/DO-
254) pour garantir l’intégrité des équipements électroniques critiques.
Mais pour les logiciels dont la criticité est faible, c'est-à-dire confirmée DAL-E (selon ED-12B/DO- 178B) or
SWAL 6 (selon ED-109/DO-278) par évaluation de sécurité, les directives EUROCAE ne sont pas appliquées.
Le soumissionnaire doit alors :
[15] appliquer les standards ECSS-E-ST-40C et ECSS-Q-ST-80C pour la définition et le développement des
logiciels non critiques.
- 21/67 -
3.7. Exigences relatives aux droits de propriété intellectuelle

Pour les besoins de la réalisation de l’étude, l’ASECNA mettra à disposition du consultant en charge de cette
réalisation, un ensemble de fournitures dont celles listées à la section 7.1 (CFI).
Certaines de ces fournitures font l’objet de droits de propriété intellectuelle appartenant à l’ASECNA ou à des
tiers, notamment l’Union Européenne.
Il sera ainsi exigé dans le marché qui régira la réalisation de cette étude :
 La concession à l’ASECNA des droits de propriété des résultats de l’étude crées ou générés sur la base
des droits de propriété appartenant à l’ASECNA et mis à disposition dans le cadre des fournitures client ;
 La concession, via l’ASECNA, à l’Union Européenne des droits de propriété des résultats de l’étude crées
ou générés sur la base des droits de propriété appartenant à l’Union Européenne et mis à disposition
dans le cadre des fournitures client ;
 La concession, via l’ASECNA, aux autres tiers désignés dans le marché des droits de propriété des
résultats de l’étude crées ou générés sur la base des droits de propriété appartenant auxdits tiers et mis
à disposition dans le cadre des fournitures client ;
 La concession à l’ASECNA des droits de propriété des résultats de l’étude créés ou générés à partir de
connaissances libres ;
 La concession à l’ASECNA, pour une durée indéterminée, du droit d’utiliser, de faire utiliser, de modifier
et de fabriquer, les résultats créés ou générés à partir des connaissances antérieures propriété du
consultant titulaire du marché. Ce dernier devra informer l’ASECNA avant toute transmission à tiers, ou
exploitation dans un autre cadre, des nouveaux droits ainsi créés ou générés ;
 La concession à l’ASECNA et aux tiers désignés dans le marché (via l’ASECNA), pour une durée
indéterminée, du droit d’utiliser les connaissances antérieures propriété du consultant titulaire du marché,
si ces connaissances sont nécessaires pour utiliser les droits crées ou générés au cours de l’étude.
De plus, il sera demandé au titulaire du marché la tenue d’un registre des droits de propriété intellectuelle
précisant :
 L’objet du droit (invention, logiciel, base de données, etc…) ;
 La nature du droit (droit d’auteur, brevet, …) ;
 Le droit d’utilisation concédé (concerne par défaut tous les droits d’utilisation, reproduction, adaptation,
fabrication…) ;
 Le territoire pour lequel le droit est mis à disposition ;
 La durée de mise à disposition (par défaut la durée est indéterminée).
Ce registre sera complété en trois étapes :

a) lors de la réponse à l’Appel d’Offre : Avec les droits propres au soumissionnaire ;
b) lors de la réunion de démarrage : Avec l’ensemble des droits existants et disponibles pour l’étude (droits
mis à disposition par l’ASECNA et droits propres au titulaire du marché) ;
c) à la réunion de clôture de la PDR (RF) : Avec l’ensemble des nouveaux droits créés au cours de l’étude.
- 22/67 -
4. EXIGENCES DETAILLEES. TACHES A REALISER
4.1. ORGANIGRAMME DES TÂCHES

[18] se conformer à la structure générale de l’organigramme des tâches selon la décomposition suivante
proposée par l’ASECNA.
[18b] Néanmoins, le soumissionnaire peut proposer des tâches en option (i.e. des tâches complémentaires)
ou des variantes, mais il doit alors signaler les adaptations de l’organigramme technique qu’il suggère.
Figure : OT Phase B
- 23/67 -
Le lien entre les tâches et les activités définies est le suivant :
ACTIVITES / TÄCHES WP1 WP2 WP3 WP4 WP5 WP6 WP7

Activité 1 :
Gestion de l’étude et X
coordination externe
Activité 2 :
Consolidation des X
services et détermination
des exigences
Activité 3 :
Elaboration des scénarios X X
d’infrastructure
Activité 4 :
Développement d’un X X
prototype système et
études de performances
Activité 5 :
Conception préliminaire X X X X
du système
Activité 6 :
Elaboration d’un plan de X
développement, avec
détermination des coûts
WP1 : Gestion de l’étude
WP2 : Consolidation Mission et Spécification Système
WP3 : Définition système & Scénarios d’infrastructures
WP4 : Performances Système et Qualification
WP5 : Définition des Sous-systèmes
WP6 : Fourniture des Services et Opérations
WP7 : Prototype Système et Expérimentations
- 24/67 -
4.2. DESCRIPTION DES TÂCHES

4.2.1. WP1 : GESTION DE L’ETUDE
4.2.1.1.T1.1 : GESTION DE PROJET

Objectifs :
Assurer la coordination et le suivi technique de toutes les activités d’ingénierie à réaliser, y compris au sein du
groupement d’entreprises le cas échéant.
Elaborer les plans et procédures qui règleront les activités SBAS-ASECNA pour la phase B, mais également
le plan de développement et de mise en œuvre et la détermination des coûts pour les phases ultérieures
(C/D/E).
Détails :
[19] assurer la préparation et le support pour chacun des jalons de la phase B (revues et points clefs) ;
[20] élaborer un Plan de Gestion (incluant gestion des risques et gestion de configuration) pour la phase B et
proposer un Plan de Gestion pour les phases ultérieures ;
[21] réaliser toutes les fonctions de gestion de projet imposées par les standards de gestion applicables ;
[22] réaliser toutes les fonctions de gestion de configuration imposées par les standards de gestion applicables
[23] tracer dans une fiche de risques l’ensemble des points ouverts qui pourront apparaitre au cours de cette
phase B ;
[24] consolider à la SRR la proposition technique pour la phase B2 en fonction des sorties de la phase B1 ;
[25] produire, en tant que fourniture documentaire de la PDR, le rapport final de l’étude de phase B, ainsi que
son résumé exécutif.
Entrées :
ECSS [DA6]
Sorties :
D1.1.1a Plan de gestion pour la phase B
D1.1.1b Plan de gestion pour la phase C/D (en phase B2)
D1.1.2 n Rapport d’avancement intermédiaire
D1.1.3 Rapport final de l’étude
D1.1.4 Registre des risques techniques
D1.1.5 Proposition technique mise à jour pour la phase B2
D1.1.6 Résumé du rapport final de l’étude
D1.1.7 Liste des éléments de configuration
- 25/67 -
4.2.1.2.T1.2 : ASSURANCE PRODUIT ET SURETE DE FONCTIONNEMENT

Objectifs :
Réaliser toutes les activités d’Assurance Produit selon les standards de gestion applicables.
Réaliser toutes les activités d’Assurance de la Sécurité et de Sureté de Fonctionnement requises pour tracer
les impacts sur la sécurité des fonctions du SBAS-ASECNA.
Détails :
[26] adapter le plan de gestion de l’Assurance Produit et des RAMS au contexte du SBAS-ASECNA, à partir
des ECSS applicables et des standards aéronautiques relatifs à la sécurité aérienne ;
[27] élaborer un Plan de Gestion d’Assurance Produit pour la phase B et proposer un Plan de Gestion pour
les phases ultérieures ;
[28] mettre en place un processus RAMS permettant réaliser, en coordination avec les équipes projet, une
analyse indépendante des risques pour la sécurité ;
[29] élaborer un Plan de Gestion « RAMS » pour la phase B et proposer un Plan de Gestion pour les phases
ultérieures ;
[30] ajuster les besoins de diversification au sein de l’architecture en fonction des allocations de criticité en
matière de sécurité ;
[31] établir et maintenir au cours de la phase B une Analyse Préliminaire de Risques (PHA, norme CEI-300-
3-9) sur l’architecture sélectionnée, en étroite coordination avec les études I&CoS ;
[32] établir et maintenir au cours de la phase B un journal des recommandations relatives aux risques pour la
sécurité, et rassembler dans un même Fichier d’Assurance Sécurité (SAF) l’ensemble des constats et enjeux
majeurs en matière de sécurité.
Entrées :
Standards ECSS [DA6] et directives EUROCAE [DA8]
Sorties :
D1.2.1a Plan d’Assurance Produit pour la phase B
D1.2.1b Plan d’Assurance Produit pour la phase C/D (en phase B2)
D1.2.2a Plan de Gestion « RAMS » pour la phase B
D1.2.2b Plan de Gestion « RAMS » pour la phase C/D (en phase B2)
D1.2.3 Fichier d’Assurance Sécurité (SAF)
D1.2.4 Analyse de Risques (PHA)
- 26/67 -
4.2.1.3.T1.3 : GESTION DES DEVELOPPEMENTS & OPERATIONS

Objectifs :
Elaborer les différents scénarios d’architecture et consolider l’architecture de référence, en termes de
développement, AIVQ, déploiement, opérations et scénarios d’évolutions pour les services initiaux (et
scénarios de transition vers les services complets), en ligne avec la stratégie et les décisions de l’ASECNA.
Elaborer le plan d’acquisition des services à fournir par le ou les transpondeurs géostationnaires et identifier
les interdépendances de ce plan d’acquisition avec le plan de développement et de déploiement de
l’infrastructure SBAS-ASECNA.
Garantir que les critères de coût du cycle de vie (LCC) sont systématiquement pris en compte dans tous leurs
aspects, y compris les coûts des services du ou des transpondeurs géostationnaires.
Procéder à une analyse critique du calendrier de phase C/D et des dates de mise en service.
Détails :
[33] proposer un plan de mise œuvre adapté pour (1) déployer les services selon les scénarios et priorités de
l‘ASECNA, (2) réduire les risques, (3) minimiser le coût du cycle de vie du système (LCC) ;
[34] proposer un schéma de versions pour le système SBAS-ASECNA qui permette (1) la réutilisation la plus
efficace des actifs les plus récents issus de la technologie EGNOS, (2) un déploiement incrémental de son
infrastructure ;
[35] identifier les technologies critiques pour le développement SBAS-ASECNA, évaluer leur situation et, si
nécessaire, identifier les développements complémentaires ou les actions d’approvisionnement à mettre en
œuvre ;
[36] proposer une stratégie de développement pour le scénario de référence sélectionné par l’ASECNA, en
détaillant les activités à réaliser pour la mise en œuvre de la phase C/D, et en procédant à une analyse critique
du calendrier proposé ;
[37] mettre en place un plan de développement et de déploiement permettant de satisfaire les besoins
exprimés dans le MRD, tout en garantissant que tous les critères de coût de l’ensemble du cycle de vie (LCC)
du système seront systématiquement pris en compte ;
[38] spécifier une stratégie AIVQ qui permette une approche modulaire et incrémentale pour construire et
mettre à jour le fichier de Qualification au fur et à mesure des évolutions du système (sans nécessiter une
reprise complète de qualification au niveau système pour chaque changement ou évolution, et en visant à
réduire la durée globale d’une montée de version) ;
[39] spécifier les tâches de Qualification Système et indiquer leur planning dans le plan de développement du
système, tant pour la première version du système que pour les versions ultérieures ;
[40] établir un projet de plan d’Opérations (incluant maintenance système, gestion des obsolescences,
certification, fourniture du service) ;
[41] consolider et justifier (par décomposition des activités) les scénarios d’évolutions au cours de l’Etape 1
(services mono fréquence) du déploiement du SBAS-ASECNA, puis de transition vers l’Etape 2 (services
multi-constellation bi-fréquence) afin de garantir la continuité du service ;
[42] établir la stratégie de référence pour la mise en service du SBAS-ASECNA.
Entrées :
Etudes de niveau Mission et Système du WP2
Etudes d’architecture du WP3
Exigences système (SRD)
- 27/67 -
Sorties :
D1.3.1 Plan de développement et de déploiement
D1.3.2 Plan AIVQ
D1.3.3 Plan d’Opération
D1.3.4 Scénario de référence pour les transitions. Plan de migration vers les services complets.
D1.3.5 Plan de mise en service et d’évolution des services initiaux.
- 28/67 -
4.2.1.4.T1.4 : GESTION de l’INGENIERIE

Objectifs :
Décrire le processus d’ingénierie système et les moyens et outils qui seront utilisés au cours de la phase B
(une attention particulière sera donnée à la gestion des interfaces).
Recommander une politique générale en matière d’approvisionnement de produits sur étagère (HW ou SW)
compatible avec les standards applicables aux systèmes dont la sécurité est essentielle.
Définir un plan de Qualification des logiciels. Ce plan doit décrire comment établir les preuves en vue de la
certification, et comment maintenir ces preuves au cours des évolutions.
Décrire la politique générale en matière d’Ergonomie, de Facteurs Humains, et d’Interface Homme Machine.
Détails :
[43] décliner des standards ECSS un plan d’ingénierie système décrivant les processus clef (traçabilité, RAMS,
arbre de défaillance, …) à appliquer au cours de la phase B ;
[44] contrôler la mise en œuvre de ce plan d’ingénierie par l’ensemble du groupement industriel (le cas
échéant) ;
[45] définir une politique générale pour les approvisionnements matériel (HW) et logiciel (SW) tendant à
résoudre les problèmes de : (1) diversification, (2) éléments critiques, (3) approvisionnements à long délais de
livraison, (4) obsolescence, (5) modularité et indépendances (Cf. [83]), (6) certification, etc.
[46] recommander une politique générale en matière de développement logiciels avec une attention
particulière aux questions touchant aux éléments critiques ou aux interfaces homme machine ;
[47] définir un plan général de Qualification pour les logiciels (au niveau application et COTS) ;
[48] recommander une politique générale en matière d’Ergonomie, de Facteurs Humains, et d’Interface
Homme Machine, et la mettre en œuvre ;
[49] recommander une politique générale en matière de développement et de qualification HW, avec un accent
particulier sur les problèmes de sécurité.
Entrées :
ECSS [DA6]
Directives EUROCAE [DA8]
HLRD [DA1] et MRD
SRD
Exigences de Sécurité de l’ASECNA [DA2]
Sorties :
D1.4.1 Plan d’Ingénierie Système
D1.4.2 Politique d’approvisionnement des COTS
D1.4.3 Directives pour le développement de logiciels
D1.4.4 Plan de Qualification des logiciels
D1.4.5 Politique en matière d’Ergonomie, de Facteurs Humains, et d’Interface Homme Machine
- 29/67 -
4.2.1.5.T1.5 : GESTION de la SECURITE et de la SURETE

Objectifs :
Définir un Plan de Gestion des Risques cohérent avec les Exigences de Sécurité et de Sûreté de l’ASECNA
[DA2] et [DA3]. Les conditions de certification et d’homologation de SBAS-ASECNA n’étant pas déterminées
en début de phase B, les conditions de certification applicables à EGNOS seront utilisées par défaut.
Détails :
[50] évaluer les exigences exprimées en DA2 et DA3, et en dériver un Plan de Gestion de la Sécurité et de la
Sureté adapté aux besoins du système SBAS- ASECNA ;
[51] déployer un processus de sécurité et de sûreté intégré qui permette de réaliser et de maintenir une analyse
de sécurité et de sureté en coordination avec les équipes d’ingénierie au cours de la phase B ;
[52] proposer lors de la SRR un Plan préliminaire d’Accréditation ;
[53] Proposer à la PDR un plan d’Accréditation consolidé.
Entrées :
Exigences de Sécurité de l’ASECNA [DA2]
Exigences de Sûreté de l’ASECNA [DA3]
Sorties :
D1.5.1 Plan de gestion de la Sécurité et de la Sureté pour la phase B
D1.5.2 Plan d’Accréditation
- 30/67 -
4.2.1.6.T1.6 : ESTIMATION DES COÛTS

Objectifs :
Proposer une méthodologie pour estimer les coûts du cycle de vie du système.
Note : pour cette évaluation, [DR2.10] pourra être utilisé
Estimer le coût du cycle de vie (LCC) du système, y compris ceux des services externes (par exemple, la
location du ou des transpondeurs géostationnaires) et le justifier par répartition des coûts.
Evaluer les coûts d’Opération du système SBAS-ASECNA.
Détails :
[54] proposer une méthodologie pour estimer le LCC et identifier les facteurs de coûts déterminants en
opération ;
[55] estimer le LCC, et le justifier par répartition des coûts ;
[56] minimiser ce LCC selon des méthodes à détailler et à justifier (déploiement progressif des infrastructures
et des services, minimisation des redondances et des diversifications, efficacité des opérations de
maintenance et de montées de version, …) ;
[57] comparer les coûts d’opération estimés à ceux constatés sur d’autres systèmes similaires et les raffiner
dans l’objectif de les réduire de façon significative.
Entrées :
ECSS [DA6]
Exemple de décomposition des coûts d’Opération [DR2.10]
Sorties :
D1.6.1 Plan et Rapport d’Evaluation des coûts du Projet (au standard ECSS)
D1.6.2 LCC et justification
D1.6.4 Facteurs de coûts déterminants en Opération
- 31/67 -
4.2.2. WP2 : CONSOLIDATION MISSION et SPECIFICATION SYSTEME
4.2.2.1.T2.1 : MRD/SRD
Objectifs :
Evaluer, avec un regard critique, les exigences de haut niveau formulées par l’ASECNA (HLRD, DA1).
Recenser, sur la base des documents applicables et des documents de référence, la documentation utile à
l’établissement du MRD et du SRD.
Elaborer et consolider, au cours de la phase B, le MRD et le SRD selon les étapes suivantes :
- En début de phase B1 (Point Clef Mission) : Version préliminaire du MRD
- En fin de phase B1 (SRR) : Version préliminaire du SRD
- En phase B2 (Point Clef Architecture) : versions consolidées du MRD et du SRD
- En phase B2 (PDR) : versions finales des MRD et SRD
Soumettre à ASECNA pour approbation et décision, à l’occasion des principaux jalons de l’étude, les versions
successives du MRD et du SRD.
Détails :
[58] évaluer avec un regard critique le HLRD
[59] formuler, sur la base du HLRD et de la documentation disponible, les exigences de mission (MRD et de
niveau système (SRD), les consolider et les faire approuver par ASECNA.
[60] réaliser les analyses système telles que spécifiées en Annexe 8.
Entrées :
HLRD [DA1]
Sorties :
D2.1.1 Document d’Exigences Mission (MRD)
D2.1.2 Document d’Exigences Système (SRD)
D2.1.3 Résultats des Analyses Système
- 32/67 -
4.2.2.2.T2.2 : FACTEURS CLEFS (Mission et Système)

Objectifs :
Identifier les facteurs de complexité et de coûts induits par les exigences Mission et Système.
Détails :
[61] identifier, parmi les exigences Mission et Système, celles qui constituent des facteurs déterminants de
complexité et/ou de coût, pour l’architecture de référence du système, sa définition, et ses coûts d’opération ;
[62] évaluer en quoi ces exigences Mission et Système peuvent être redéfinies afin de relâcher les contraintes
sur le système et ses opérations, sans remettre en cause la qualité des services à fournir.
Entrées :
HLRD/MRD
SRD
Sorties :
D2.2.1 Facteurs déterminants (Mission & Système)
- 33/67 -
4.2.2.3.T2.3 : SPECIFICATIONS TECHNIQUES (système+ opérations)

Objectifs :
Décliner les spécifications techniques et opérationnelles à partir des exigences Mission et Système.
Etablir le statut de conformité du système à ses exigences.
Consolider les interfaces externes du système par :
- Une analyse des caractéristiques du réseau ASECNA en regard des exigences de transport du WAN
SBAS, l’identification des écarts, et la spécification des solutions pour combler ces écarts
- La spécification des services attendus des transpondeurs géostationnaires,
- La proposition et l’analyse technique et opérationnelle d’un concept pour l’utilisation des sites et/ou
des mesures de certaines RIMS EGNOS
- La définition des modèles d’ionosphères adaptés à la zone de service.
Détails :
[63] établir l’état de conformité du Système vis-à-vis du MRD et du SRD ;
[64] affecter et décliner les exigences Mission et Système en Spécification Technique du Système d’une part,
Spécification des Opérations d’autre part ;
[65] établir les documents d’interfaces externes et internes du système. Les interfaces externes comprennent
notamment l’interface avec le Service GEO, l’interface avec le Réseau WAN, l’interface éventuelles avec
certaines RIMS du système EGNOS, et les modèles ionosphériques adaptés. La liste exhaustive de toutes
les interfaces externes (y compris ATM, IERS, et toute autre interface opérationnelle) est à établir ;
[66] mettre à jour au cours de la phase B, si nécessaire, les spécifications techniques selon les évolutions
éventuelles des exigences Mission et Système ;
[67] vérifier en permanence et assurer (en prenant en compte les sorties de T2.4 pour les aspects Sécurité et
Sûreté) la cohérence globale de la définition de référence du système dans ses différentes composantes
(définition, opération, RAMS, Sécurité et Sureté) au long de la phase B ;
[68] identifier la méthode de vérification de chaque exigence Système (Inspection, Analyse, Simulation, etc..)
et l’indiquer dans les documents de spécifications techniques et opérationnelles ;
[70] identifier en phase B1 les arbitrages ou compromis potentiels (entre Opérations, Performances et Coûts)
à effectuer en phase B2 selon les scénarios envisagés ;
[71] finaliser en phase B2 les arbitrages ou compromis identifiés en phase B1 ;
[72] fournir, en support aux autres WP ‘s, l’expertise transverse en ingénierie et le support aux différents
domaines (ingénierie système et sous-systèmes, interfaces, performances, RAMS, AIVQ, sécurité-sûreté,
opérations) de la définition du système au cours de la phase B.
Entrées :
MRD
SRD et autres documents appelés par ces Termes de Référence
- 34/67 -
Sorties :
D2.3.1 Statut de conformité au MRD
D2.3.2 Statut de conformité au SRD
D2.3.3 Spécification Technique du Système
D2.3.4 Spécification des Opérations du Système
D2.3.5 Spécifications Technique des Segments (AC)
D2.3.7 Synthèse des évaluations, consolidations et arbitrages en cours de phase B
D2.3.8 Document d’Interfaces Externes
D2.3.8.1 Spécification des besoins et solutions d’adaptation du réseau ASECNA aux besoins
du WAN SBAS-ASECNA
D2.3.8.2 Spécification des services des transpondeurs géostationnaires
D2.3.8.3 Concept d’interface opérationnel pour l’utilisation des mesures des RIMS EGNOS
D2.3.8.4 Modèles d’ionosphère adaptés à la zone de service.
D2.3.9 Document d’Interfaces Internes
- 35/67 -
4.2.2.4.T2.4 : SPECIFICATIONS DE SURETE

Objectifs :
Effectuer une analyse de risques en matière de sureté, identifier les contre-mesures, et proposer une
Spécification de Sureté.
Etablir les spécifications de sureté du Système.
Détails :
[73] évaluer, avec un regard critique, les exigences de sureté de l’ASECNA ;
[74] effectuer une Analyse de Risques, en prenant en compte (1) les exigences de sureté, et les modèles de
menaces associées, (2) les risques (internes ou externes) identifiés par l’industriel, (3) la définition du système
proposée par l’industrie ;
[75] élaborer une Analyse de la sureté du Système et le Plan de Traitement associé ;
[76] proposer des entrées pour le plan de gestion des risques du WP1 ;
[78] affecter et décliner à partir de l’Analyse de Risques, les spécifications de sureté à appliquer à la définition
du système et/ou ses opérations (SecREQ) ;
[79] identifier dans le document SecOPS, les exigences relatives aux procédures d’opérations qui contribuent
à la sureté du système ;
[81] établir et maintenir un statut de conformité au Relevé des exigences de Sûreté (SecREQ).
Entrées :
Exigences de Sûreté de l’ASECNA (DA3)
Sorties :
D2.4.1 Analyse de sureté du Système et Plan de Traitement
D2.4.2 Relevé des exigences Sûreté (SecREQ) (définition système et opération)
D2.4.3 Spécification préliminaire des Procédures Sûreté (SecOPS)
D2.4.4 Répartition les exigences Sûreté sur les composantes du système (traçabilité SecREQ)
D2.4.5 Statut de conformité au Relevé des exigences de Sûreté (SecREQ)
- 36/67 -
4.2.3. WP3 : DEFINITION SYSTEME & SCENARIOS D’INFRASTRUCTURE
4.2.3.1.T3.1 : ARCHITECTURE FONCTIONNELLE

Objectifs :
Consolider l’architecture fonctionnelle du système et sa définition jusqu’au niveau segment et sous- systèmes.
Stabiliser l’architecture de référence du système pour le Point Clef décisionnel d’Architecture.
Détails :
[82] identifier et évaluer les scénarios d’architecture correspondant aux différents scénarios de déploiement
envisagés, puis stabiliser l’architecture de référence répondant à l’ensemble des spécifications techniques
issues du WP2 ;
[83] allouer, à partir de la spécification technique (WP2), les fonctions du système à ses différentes
composantes ;
[84] exploiter, pour consolider la définition du système, les résultats du banc de test ou prototype (WP7)
notamment pour ce qui relève de l’évaluation des performances (T4.1) ;
[85] définir les interfaces fonctionnelles entre l’infrastructure du système et les entités externes en interaction.
Entrées :
SRD
Résultats de WP2 et de WP7
Sorties :
D3.1.1 Architecture fonctionnelle (associée au Dossier de Définition système D3.2.1)
D3.1.2 Interfaces fonctionnelles
- 37/67 -
4.2.3.2.T3.2 : ARCHITECTURE PHYSIQUE et INTERFACES

Objectifs :
Consolider l’architecture physique du système en tenant compte des sites d’accueil potentiels des différents
éléments de l’infrastructure, et de la disponibilité effective des actifs développés dans le cadre du programme
EGNOS.
Définir tous les échanges de flux de données entre (1) le système et ses interfaces externes, (2) en interne
système, entre les principales composantes ou segments, (3) entre les sous-systèmes
Détails :
[86] consolider, jusqu’au niveau sous-systèmes, la définition du système sur la base de l’architecture
fonctionnelle de référence définie en T3.1 ;
[87] définir une méthodologie pour la spécification et la définition des interfaces ;
[89] définir toutes les interfaces entre le système et les entités externes, et les interfaces entre les différentes
composantes internes du système ;
[90] estimer, au travers des études RAMS et des études de performance, l’aptitude de l’architecture
sélectionnée à fournir les services de l’Etape 1 selon le scénario de déploiement retenu au PKA.
Entrées :
Sorties de T3.1
SRD
Sorties :
D3.2.1 Dossier de définition (DDF)
D3.2.2 Dossier de justification de la définition (DJF)
D3.2.3 Dossier de contrôle des Interfaces externes (DCI)
D3.2.4 Dossier de Contrôle des interfaces internes (DCI inter sous-systèmes)
D3.2.5 Matrice de Vérification
- 38/67 -
4.2.3.3.T3.3 : SPECIFICATION des PREDEVELOPPEMENTS et EXPERIMENTATIONS

Objectifs :
Diminuer les risques au cours du développement et du déploiement de SBAS-ASECNA.
Proposer des actions en diminution de risques.
Détails :
[91] identifier et justifier, à la SRR, la liste des éléments et technologies critiques (par exemple : récepteurs,
algorithmes critiques, …) dont les schémas d’approvisionnement ou de développement doivent être sécurisés
pour la PDR ;
[92] proposer et justifier, pour ces éléments, des actions en diminution de risques au travers, soit de pré
développements, soit d’expérimentations spécifiques à réaliser au titre du WP7.
Entrées :
MRD, SRD
Facteurs déterminants Mission & Système (issus de T2.2)
D1.1.4 Registre des risques techniques
Sorties :
D3.3.1 Identification de la liste des éléments et technologies critiques, et sélection des pré
développements ou expérimentations à réaliser en phase B2
- 39/67 -
4.2.3.4.T3.4 : EVALUATION DES SCENARIOS DE DEPLOIEMENT

Objectifs :
Evaluer de manière critique, en support au WP1, les scénarios de déploiement de l’Etape 1 et, puis le scénario
de transition de l’Etape 1 vers l’Etape 2, du point de vue de la définition du système.
Détails :
[93] évaluer de manière critique, en support au WP1, les différents scénarios de déploiement envisagés, du
point de vue de la définition du système ;
[94] enrichir ces scenarios avec les contraintes et/ou les impacts identifiés au niveau de la définition du
système ;
[95] fournir des recommandations au WP1 pour la consolidation des scénarios de transition.
Entrées :
Scénarios de déploiement identifiés dans le HLRD (DA1) ;
Plan d’extension de la couverture des services du HLRD (DA1) ;
Plan de gestion des obsolescences ;
Pré-développements et expérimentations identifiés en T3.3.
Sorties :
D3.4.1 Entrées pour le Plan de migration (T1.3)
- 40/67 -
4.2.4. WP4 : PERFORMANCES SYSTEME ET QUALIFICATION

Les objectifs globaux de ce lot de travail sont de :
 Analyser les différents niveaux de performances du système pour les différents scénarios d’architecture
et selon les différents scénarios de déploiement qui sont envisagés, pour contribuer au choix de
l’architecture et du scénario de référence ;
 Analyser en détail le niveau de de performance du système pour l’architecture et de scénario de référence.
Cette évaluation de performance et de conformité sera basée sur les analyses I&CoS, RAMS, et les
simulations de performances, l’accent étant mis sur la consistance du scénario de simulation ;
 Spécifier et définir les moyens d’AIVQ et les outils support pour l’Ingénierie.
4.2.4.1.T4.1 : Exploitation des résultats du Prototype

Objectifs :
Evaluer les résultats du prototype système (WP7) et consolider le scénario de référence
Détails :
[96] réaliser une évaluation des résultats, issus du WP7, des expérimentations du prototype ;
[97] comparer les performances des différents scénarios d’architecture et de déploiement, et consolider sur
cette base, le scénario de référence.
Entrées :
Résultats du prototype système et de ses expérimentations (WP7)
Sorties :
D4.1.1 Analyse critique des différents scénarios d’architecture et de déploiement, et éléments pour le choix
de l’architecture de référence et de son scénario de déploiement
- 41/67 -
4.2.4.2.T4.2 : Etudes “RAMS” et “I&CoS”

Objectifs :
Effectuer les études de sureté de fonctionnement et de robustesse aux évènements redoutés, afin de
démontrer la conformité des performances du système par rapport aux exigences Mission et Système.
Prendre en compte dans ces études l’analyse des risques pour la sécurité et la sureté.
Détails :
[98] effectuer les études RAMS depuis la définition fonctionnelle du système, jusqu’à la caractérisation de
l’architecture physique au niveau des sous-systèmes ;
[99] consolider la liste des évènements redoutés, en y intégrant ceux liés au milieu de propagation dans les
zones de services à couvrir, aux nouvelles constellations et signaux GNSS à augmenter, le cas échéant, aux
niveaux de redondance identifiés et aux allocations de fonctionnalités entre segments et sous-systèmes ;
[100] examiner les cas de corrélation d’évènements redoutés, les scénarios de pannes multiples, afin d’évaluer
la robustesse des barrières de sécurité proposées ;
[101] prendre en compte les retours de l’exploitation du prototype (T4.1) (ou ceux du système EGNOS lui-
même si rendus disponibles) pour ajuster les frontières entre conditions de fonctionnement « sans erreur » et
conditions de fonctionnement « avec événements redoutés » ;
[102] prendre en compte les retours du WP5 (ou ceux des sous-systèmes d’EGNOS eux-mêmes, si rendus
disponibles) concernant les analyses RAMS/I&CoS des sous-systèmes ;
[104] consolider les études de robustesse du système ;
[105] fournir un support aux activités relatives à la sûreté impliquant une certaine synergie avec le domaine
RAMS ;
[106] évaluer, du point de vue des RAMS, tout dispositif de sureté qui serait proposé pour la définition du
système ou ses opérations.
Entrées :
HLRD [DA1] et MRD
SRD
Définition détaillée du système issue de WP3
D5.4.1 Analyses RAMS/I&CoS de niveau sous systèmes
D2.4.1 Analyse de la Sécurité du Système et Plan de Traitement
D2.4.2 Relevé des exigences sécurité (SecREQ) (définition système et opération)
Sorties :
D4.2.1 Analyses RAMS
D4.2.2 Dossier de Justification RAMS
D4.2.3 Analyses I&CoS
D4.2.4 Dossier de Justification I&CoS
- 42/67 -
4.2.4.3.T4.3 : Simulations de Performances

Objectifs :
Construire un budget de performances consolidé (PBMF) détaillant le niveau de performances attendu pour
les services SBAS-ASECNA.
Détails :
[107] consolider la méthodologie d’évaluation des performances qui sera appliquée aux différents services,
basée sur les exigences Mission et Système, et sur l’architecture système de référence ;
[108] réaliser une analyse comparative à partir de simulations à base de macro modèles en condition « sans
erreur », et combiner ces résultats avec ceux issus du prototype système ;
[109] effectuer une analyse de sensibilité des performances de l’architecture de référence afin de déterminer
les contributeurs clefs au budget de performance, en termes de disponibilité, d’intégrité et de continuité (par
exemple les performances du réseau, le MTBF des sous-systèmes, les constellations satellite à augmenter,
l’environnement multi trajet des sites RIMS, etc…) ;
[110] documenter systématiquement la liste des hypothèses selon lesquelles la performance est établie, ainsi
que les modifications potentielles de la configuration système qui pourraient être acceptables sans remettre
en cause le budget de performance (par exemple ajout de RIMS, ou ajout de satellites dans la constellation) ;
[111] prendre en compte les retours du WP 5 concernant les analyses de performances des sous-systèmes ;
[112] consolider les différents postes du budget de performance de référence (PBMF) en précisant les
contributions en condition « sans erreur » et celles avec évènements redoutés telles que définies en T4.2 ;
[113] décliner un dossier de vérification des performances de niveau système pour chacun des services
spécifiés dans le HLRD ;
[114] allouer les performances aux différentes composantes du système, en soulignant les principaux
contributeurs, puis identifier et quantifier les marges en termes de performances ;
[115] extrapoler, au niveau segment utilisateur, les performances qui seront atteintes pour tous les services et
pour l’ensemble des zones à couvrir, tels que spécifiés dans le HLRD ;
[116] synthétiser l’ensemble des résultats qualitatifs et quantitatifs dans la version consolidée du PBMF.
Entrées :
Les sorties de T4.2 et de T4.1
HLRD [DA1], MRD et SRD
Sorties :
D4.3.1 Budget de Performances (PBMF)
- 43/67 -
4.2.4.4.T4.4 : Plan de test système et spécification des moyens AIVQ

Objectifs :
Spécifier (en accord avec le plan AIVQ) le plan de test système permettant de valider et de vérifier/qualifier
les fonctionnalités du système, ses performances et sa robustesse.
Spécifier les moyens, et les opérations associées, requis pour l’AIV, de déploiement, et la qualification du
système.
Détails :
[117] spécifier le plan de test système permettant de valider et de vérifier/qualifier les fonctionnalités du
système, ses performances et sa robustesse, ainsi que l’opérabilité et la maintenabilité du système ;
[118] spécifier, en termes de fonctionnalités et d’opération, les moyens nécessaires pour supporter les tâches
du plan d’AIV (D1.3.2 de WP1) ;
[119] spécifier, en termes de fonctionnalités et d’opération, les moyens nécessaires pour la Qualification du
système.
Entrées :
D1.3.2 Plan AIVQ
Sorties :
D4.4.1 Plans de Test pour la validation Système
D4.4.2 Plans de Test pour la vérification/qualification Système
D4.4.3 Spécification des moyens d’AIV et de qualification
D4.4.4 Plan de développement des moyens AIVQ
- 44/67 -
4.2.4.5.T4.5 : Spécification des Outils Support en Ingénierie

Objectifs :
Spécifier les outils support en ingénierie, nécessaires en phase B, puis en phase C/D.
Détails :
[120] spécifier les outils (Volume de Service, RAMS, I&CoS, …) nécessaires pour évaluer les performances
du système (tant en mode « sans erreur » qu’en configuration « évènements redoutés ») durant la phase B ;
[121] spécifier l’outil à utiliser pour la spécification et la définition des interfaces ;
[122] établir un plan de développement ou d’approvisionnement pour ces outils supports.
Entrées :
Sorties :
D4.5.1 Spécification des outils support en ingénierie
D4.5.2 Plan de développement (ou d’approvisionnement) des outils support
D4.5.3 Spécification de l’outil support pour la spécification et la définition des interfaces
4.2.4.6.T4.6 : Définition des moyens de test AIVQ

Objectifs :
Définir (en accord avec le Plan de Test) les cas test système permettant de valider et de vérifier/qualifier les
fonctionnalités du système, ses performances et sa robustesse ;
Définir la plate-forme et les moyens nécessaires à l’AIV, au déploiement et à la Qualification du système
Détails :
[123] spécifier (à partir des sorties de T4.4) les cas tests permettant de valider et de vérifier/qualifier les
fonctionnalités du Système, ses performances et sa robustesse ;
[124] définir la plate-forme et les moyens nécessaires aux tâches d’AIV du système et de ses sous-systèmes,
et les opérations associées ;
[125] définir la plate-forme et les moyens nécessaires à la Qualification du système, et les opérations
associées.
Entrées :
Sorties de T4.4
Sorties :
D4.6.1 Cas Tests pour la validation Système
D4.6.2 Cas Tests pour la vérification/qualification Système
D4.6.3 Définition des moyens d’AIVQ
- 45/67 -
4.2.4.7.T4.7 : Définition et Développement des outils Support en Ingénierie

Cette tâche n’est prévue que pour le cas où certains outils support seraient développés, plutôt
qu’approvisionnés.
Objectifs :
Définir les outils support en ingénierie.
Développer et valider les outils supports nécessaires à la phase B.
Détails :
[126] définir les nouveaux outils support nécessaires à l’évaluation des performances en phase B, puis en
phase C/D ;
[127] définir l’outil à utiliser pour la spécification et la définition des interfaces ;
[128] développer et valider les outils support nécessaires à la phase B.
Entrées :
Sortiew de T4.5
Sorties :
D4.7.1 : Dossier de définition et de justification des outils support en ingénierie
D4.7.2 : Dossier de définition et de justification de l’outil pour les interfaces
D4.7.3 : Plan de validation et procédures de test des outils support en ingénierie
D4.7.4 : Matériels et logiciels des outils support en ingénierie
- 46/67 -
4.2.5. WP5 : DEFINITION PRELIMINAIRE DES SOUS SYSTEMES (Y COMPRIS

SEGMENT SUPPORT)
Hormis la tâche T5.1 (spécification des sous-systèmes), les tâches du WP5 dépendent des décisions en
matière de réutilisation de tout ou partie des composantes du système EGNOS et de leur disponibilité effective
(réutilisation des actifs du système EGNOS, y compris certains éléments de l’infrastructure EGNOS, ou
l’utilisation des données brutes de certaines RIMS EGNOS selon des solutions techniques à définir).
Ces décisions relèvent de l’ASECNA (en concertation avec le programme EGNOS), sur la base des
propositions du soumissionnaire, à fournir à la SRR. A ce titre, le soumissionnaire peut être amené à préciser
sa proposition pour la phase B2, lors de la SRR.
En matière de redéfinition ou de réutilisation de sous-systèmes, le soumissionnaire peut proposer des options
(i.e. des tâches complémentaires) ou des variantes. Il tiendra compte notamment du calendrier de disponibilité
des composants réutilisables et de leur niveau d’obsolescence.
En cas de réutilisation par le système SBAS-ASECNA de sous-systèmes d’EGNOS, l’exigence [136]
s’applique.
En cas d’utilisation des sites et/ou des données de certaines RIMS du système EGNOS, qui impliquerait une
modification quelconque du système EGNOS, les différentes solutions possibles doivent être identifiées (T2.3)
ainsi que leurs impacts en termes de sécurité et de sureté. La solution retenue par ASECNA en concertation
avec le programme EGNOS à la SRR sera alors instruite en phase B2 dans le cadre de ce WP5.
4.2.5.1. T5.1 : Spécification des sous-systèmes

Objectifs
Etablir, pour chaque partie du système (segment), les spécifications techniques des sous-systèmes
composants cette partie (y compris le Segment Support).
Détails
[129] identifier, sur la base de l’architecture de référence du système, tous les sous-systèmes et leurs
segments ;
[130] établir la spécification technique de chaque sous-système ;
[131] fournir une matrice de traçabilité entre la spécification système et les spécifications des sous-systèmes ;
[132] identifier la méthode de vérification de chaque exigence des sous-systèmes.
Entrées :
Sorties des tâches T2.3, T3.1 et T3.2
Sorties
D5.1.1i Spécification du Sous-système (i), incluant sa matrice de traçabilité
- 47/67 -
4.2.5.2. T5.2 : Plans de gestion Sous-systèmes

Objectifs
Définir pour chaque sous-système (y compris de Segment Support) toutes les activités d’ingénierie et de
développement.
Détails
[133] présenter en détail, pour chaque sous-système toutes les activités d’ingénierie et de développement :
(1) Plan Assurance Produit, (2) Plan de développement, (3) Plan d’analyse de sécurité et de sureté de
fonctionnement, (4) Plan AIVQ
Entrées
Sorties des tâches T5.1 et T1.3
Sorties
D5.2.1i Plan de Gestion du Sous-système
D5.2.2i Plan d’Assurance Produit du Sous-système
D5.2.3i Plan de gestion des RAMS
D5.2.4i Plan de développement du Sous-système
D5.2.5i Plan AIVQ du Sous-système
D5.2.6i Plan de sécurité et sûreté du Sous-système
4.2.5.3. T5.3 : Définition et Justification des Sous-systèmes

Objectifs
Décliner la définition préliminaire de chaque sous-système à partir de sa spécification technique.
Détails
[134] décliner à partir de sa spécification technique, la définition préliminaire de chaque sous-système ;
[135] démontrer et justifier la conformité de la définition aux spécifications techniques des sous-systèmes ;
[136] évaluer, si un COTS est proposé comme composant, (1) son adéquation en regard des exigences, (2)
son adéquation en regard des performances, (3) ses possibilités d’adaptation/modification et les justifications
associées, et identifier les approvisionnements ou les pré-développements nécessaires (T3.3).
Entrées :
Sorties de T5.1
Sorties
D5.3.1i Dossier de définition préliminaire du Sous-système
D5.3.2i Dossier de justification Sous-système à partir de sa spécification technique
- 48/67 -
4.2.5.4. T5.4 : Performances Sous-Systèmes

Objectifs
Evaluer et justifier, pour chaque sous-système, sa contribution aux performances/RAMS/I&CoS du système,
et identifier les sous-systèmes critiques.
Estimer par analyse et simulation les performances attendues, en relation avec la définition préliminaire de
chaque sous-système.
Détails
[137] évaluer et justifier la contribution de chaque sous-système, aux performances/RAMS/I&CoS du
système ;
[138] identifier les sous-systèmes critiques en regard de leur contribution aux performances/ RAMS/ I&CoS
du système ;
[139] estimer les performances/ RAMS/ I&CoS de chaque sous-système ;
[140] identifier et justifier le niveau d’assurance logicielle (DAL, norme EUROCAE ED-79) des composants de
chaque sous-système.
Entrées :
Sorties
D5.4.1i Analyse RAMS/I&CoS de chaque sous-système incluant les allocations DAL
D5.4.2I Analyse de performances de chaque sous-système
4.2.5.5. T5.5 : Interfaces entre Sous-Systèmes

Objectifs
Définir les interfaces entre sous-systèmes.
Détails
[141] définir, en accord avec l’architecture système et ses interfaces, les interfaces entre sous-systèmes (au
niveau logiciel, physique et opérationnel).
Entrées :
Sorties de T3.2
Sorties
D5.5.1i Document de Contrôle d’Interface (ICD) du sous-système
- 49/67 -
4.2.5.6. T5.6 : Opérations des Sous-Systèmes

Objectifs
Décliner au niveau sous-système le Concept d’Opération du Système.
Détails
[142] déduire du Concept d’Opération du Système, le scénario opérationnel de base de chaque sous-
système ;
[143] déterminer les sous-systèmes critiques du point de vue de l’opérabilité du système.
Entrées :
Sorties de T6.1
Sorties
D5.6.1i Procédures opérationnelles du sous-système
4.2.5.7. T5.7 : Spécifications Préliminaires des équipements critiques

Objectifs
Spécifier les équipements critiques.
Détails
[144] fournir une spécification technique préliminaire pour les équipements critiques identifiés (voir exigence
[91])
Entrées :
Sorties de T5.3
Sorties
D5.7.1i Spécification technique préliminaire de l’équipement critique (i)
- 50/67 -
4.2.6. WP6 : FOURNITURE DES SERVICES et OPERATIONS
4.2.6.1. T6.1 : Fourniture du Service et Concept d’Opération

Objectifs
Consolider en prenant en compte les sorties de T2.3 pour le volet opération, le Concept préliminaire
d’Opération SBAS-ASECNA.
Justifier ce Concept d’Opération en regard des choix d’architecture et de définition.
Note : Conformément à ses pratiques, l’ASECNA recherche à internaliser au maximum les opérations.
Détails
[145] élaborer un concept d’opération et de fourniture des services consolidé. Les aspects suivants, entre
autres, doivent être détaillés et justifiés :
(1) niveaux de redondances ;
(2) distribution géographique des sites de l’infrastructure et plan de rotation ;
(3) besoin d’une surveillance en local pour l’environnement des sites ;
(4) états et modes de transitions ;
(5) principes de gestion des défaillances (FDIR) dans le contexte d’une robustesse et d’une complexité accrue
des services ;
(6) gestion des opérations à distance ;
(7) gestion de la configuration technique ;
(8) gestion des mises à jour, etc…
Entrées
Sorties de T2.3 (volet opération)
Sorties
D6.1.1 Concept d’Opération SBAS-ASECNA
D6.1.2 Justification du Concept d’Opération
D6.1.3 Recueil des Opérations (principales procédures d’Opération)
- 51/67 -
4.2.6.2. T6.2 : Evaluation Opérationnelle des scénarios de transition

Objectifs
Apporter un support à l’ASECNA, du point de vue Opération et Fourniture de Services, pour le choix du
scénario de référence pour le déploiement du SBAS-ASECNA au cours de l’Etape 1.
Détails
[146] définir des critères quantitatifs pour (1) évaluer les dépenses opérationnelles ou les charges induites par
les transitions, (2) consolider les arbitrages en matière de scénarios de transition de l’Etape 1 ;
[147] évaluer les différents scénarios de déploiement envisagés, au travers d’une identification des contraintes
principales à considérer pour garantir des transitions sans heurt du point de vue de la fourniture du service ;
[148] apporter un support à la consolidation de la stratégie de déploiement du système et de fourniture des
services de l’ASECNA.
Entrées
D1.3.4 Scénario de référence pour les transitions. Plan de migration
D6.1.1 Concept d’Opération
Sorties
D6.2.1 Evaluation opérationnelle des scénarios de transition de l’Etape 1
4.2.6.3. T6.3 : Exigences opérationnelles pour la spécification du Segment Support

Objectifs
Définir les fonctions support (et l’infrastructure associée) qui sont nécessaires pour le soutien aux opérations
et à la fourniture des services (suivi des opérations et de maintenance du système, opérations du centre de
service, formation, analyse de performances, prédictions & NOTAM, surveillance des services au travers de
récepteurs représentatifs de ceux des communautés utilisatrices du service SoL, etc.).
Détails
[149] proposer une base de référence pour les fonctions du Segment Support qui puisse couvrir l’ensemble
des besoins en matière d’Opération et de Services ;
[150] proposer des fonctions support relatives aux opérations couvrant au minimum les domaines suivants:
(1) gestion des opérations, rapports et coordination, (2) gestion de configuration de tous les actifs (aussi bien
ceux déployés sur le terrain, que leurs rechanges en magasin), (3) suivi des performances, (4) support
d’ingénierie pour les opérations critiques telles que : investigations en cas de pannes, déploiements, ou
montées de version, (5) la coordination avec les fournisseurs ou les utilisateurs externes de données, (6)
l’archivage des données, (7) la qualification de la version de référence en opération, et le support à sa
certification, …
Entrées
Définition préliminaire des fonctions du segment support (WP3 et WP5)
Sorties
D6.3.1 Exigences opérationnelles pour la spécification du Segment Support
- 52/67 -
4.2.6.4. T6.4 : Spécification des activités de Maintenance et de Logistique

Objectifs
Spécifier les fonctions supportant les activités de Logistique Intégrée et de Maintenance.
Détails
[151] spécifier les fonctions support en matière de Logistique et de Maintenance, qui doivent couvrir au moins ;
(1) la coordination du planning de maintenance, (2) l’ingénierie en fiabilité et maintenabilité, et l’identification
des obsolescences (3) la maintenance de troisième niveau et les réparations, (4) la gestion des
approvisionnements (rechanges, consommables) (5) la gestion des équipements de test et de support, (6) la
formation et les dispositifs associés, (7) la gestion des données techniques et des publications, (8) la gestion
des ressources informatiques, (9) la gestion des installations, (10) la gestion d'emballage, de manutention, de
stockage et de transport, …)
Entrées
Définition préliminaire des fonctions du Segment Support (WP3 et WP5).
Sorties
D6.4.1 Spécification préliminaire des activités de Logistique et de Maintenance
4.2.6.5. T6.5 : Définition & Justification des activités de Maintenance et de Logistique

Objectifs
Définir et justifier, sur la base des spécifications de Logistique et de Maintenance, comment les activités de
Logistiques et de Maintenance seront prises en compte.
Détails
[152] définir et justifier les fonctions de support logistique en lien avec la gestion des obsolescences, le
Concept d’Opération et la définition des procédures ;
[153] définir et justifier les fonctions de Maintenance en lien avec la gestion des obsolescences, le Concept
d’Opération et la définition des procédures.
Entrées
Sorties
D6.5.1 Définition préliminaire et justification des activités de Maintenance et de Logistique
D6.5.2 Recueil des Opérations (procédures principales de Maintenance)
- 53/67 -
4.2.6.6. T6.6 : Plan Validation des activités de Maintenance et de Logistique

Objectifs
Définir le plan et les moyens de validation des activités de Maintenance et de Logistique.
Détails
[154] définir le plan de validation des moyens traitant des aspects de Maintenance et de Logistique
Entrées
D6.5.1 Définition préliminaire et justification des activités de Maintenance et de Logistique
Sorties
D6.6.1 Plan de Validation Logistique et Maintenance
4.2.6.7. T6.7 : Recueil des Opérations et des Scénarios Opérationnels

Objectifs
Définir et justifier, du point de vue du fournisseur de service, et sur la base du Recueil des procédures
d’Opération et de Maintenance, les Scénarios Opérationnels du Système
Détails
[155] définir et justifier, du point de vue du Fournisseur de Service, et sur la base du Recueil des procédures
d’Opération (T6.1) et de Maintenance (T6.5), les scénarios opérationnels du système
Entrées
Sorties de T6.1, T6.2, T6.3, et T6.5
Sorties
D6.7.1 Scénarios Opérationnels du Système (y compris Formation et Maintenance)
- 54/67 -
4.2.6.8. T6.8 : Plan de validation des Scenarios Opérationnels

Objectifs
Définir la stratégie et les plannings à utiliser pour valider les scénarios opérationnels du système.
Détails
[156] détailler les tâches et le planning permettant de valider les Scénarios Opérationnels du Système ;
[157] définir les moyens spécifiques nécessaires pour supporter la validation des Scénarios Opérationnels.
Entrées
D6.7.1 Scénarios Opérationnels du Système
Sorties
D6.8.1 Plan de validation des Scénarios Opérationnels
- 55/67 -
4.2.7. WP7 : PROTOTYPE SYSTEME et EXPERIMENTATIONS
4.2.7.1. T7.1 : Préparation des expérimentations et du prototype système

Objectifs
Préparer, en accord avec les sorties de T3.3, les pré-développements et expérimentations à réaliser au cours
de la phase B.
Définir le prototype système (ou banc de test SBAS-ASECNA) qui doit permettre d’effectuer les évaluations
de performances des différents scénarios d’architecture et de déploiement, et d’expérimenter certains
algorithmes critiques.
Détails
[158] Préparer en termes d’objectifs, spécifications, plan de tests et procédures, critères de test, etc., le
prototype système, les pré-développements et les expérimentations à réaliser en T7.2
Entrées
Sorties de T3.3
Sorties
D7.1.1 Objectifs du Prototype, des Pré développements et des Expérimentations
D7.1.2 Spécifications du Prototype, des Pré développements et des Expérimentations
D7.1.3 Plan de Test, Procédures et critères de succès du Prototype, des Pré développements et des
Expérimentations
- 56/67 -
4.2.7.2. T7.2 : Prototype, Pré développements et Exécution des expérimentations

Objectifs
Mettre en œuvre les activités de prototypage système, pré développement et expérimentations, au cours de
la phase B.
Générer les rapports issus des activités de prototypage système, pré-développement et expérimentations.
Injecter les résultats de ces activités pour la consolidation, au travers du WP2, du système et le choix de
l’architecture et du scénario de SBAS-ASECNA.
Détails
[159] mettre en œuvre les activités de prototypage système, pré-développement et expérimentations, tout au
long de la phase B ;
[160] générer les rapports et recommandations issus des expérimentations ;
[161] injecter dans les études système, au travers du WP2, les résultats des expérimentations et les
recommandations associées, avec pour objectif de contribuer à la consolidation de l’architecture du scénario
de référence pour SBAS-ASECNA ;
[162] organiser et mettre en œuvre la recette usine puis la recette site du prototype système.
Entrées
Sorties de T7.1
Sorties
D7.2.1 Rapports d’expérimentations (incluant les recommandations vers la définition du système)
D7.2.2 Matériels et Logiciels (exécutables et codes source correspondant aux développements spécifiques,
notamment ceux basés sur les connaissances antérieures du consultant) développés ou
approvisionnés au titre du WP7, et les Procès-Verbaux des recettes Usine et Site
Note : Le prototype système est à livrer à l’ASECNA à Dakar dès la fin de son développement, étant entendu
que le consultant dispose de ses propres moyens pour la réalisation des études de performances.
- 57/67 -
5. LISTE DES LIVRABLES
Ce chapitre indique la liste des livrables, ainsi que leurs étapes de livraison.
Le soumissionnaire doit :
[168] fournir les documents à produire selon les échéances indiquées dans la liste des fournitures (Voir tableau
ci-dessous, « Liste des fournitures ») ;
[169] identifier et proposer le cas échéant un regroupement logique des documents à produire, afin d’alléger
la charge de gestion documentaire tout en assurant au client une bonne visibilité sur le travail accompli ;
[171] rendre accessible la documentation produite, au travers d’un serveur dédié (FTP ou HTTP), sachant
que, à la SRR et à la PDR, trois CD-ROM de la documentation doivent être fournis ;
[172] fournir également les documents d’exigences dans le format de l’outil de gestion des exigences retenu
(par exemple DOORS), en sus des formats Word ou PDF ;
Les tableaux suivants résument la liste des fournitures issues des tâches décrites précédemment.
Ces tableaux indiquent également :
 A quel jalon ces fournitures sont attendues : Point-clé Mission (PKM), SRR, Point-clé Architecture
(PKA), PDR ;
 Dans quel état : (P) Préliminaire, (C) Consolidé, (F) Final ;
 Et pour quelle finalité : Approbation O, Revue O, ou Information O ;
 La langue à utiliser : les noms des documents à livrer en français sont indiqués en gras, les autres
documents peuvent être livrés en anglais ou en français.
GESTION de PROJET PKM SRR PKA PDR
D1.1.1a Plan de gestion pour la phase B P C

D1.1.1b Plan de gestion pour la phase C/D (en phase B2) P C
D1.1.2 n Rapport d’avancement intermédiaire F F F F
D1.1.3 Rapport final de l’étude P F
D1.1.4 Registre des risques techniques P C F
D1.1.5 Proposition technique mise à jour pour la phase B2 C
D1.1.6 Résumé du rapport final de l’étude P F
D1.1.7 Liste des éléments de configuration P C F
D1.4.1 Plan d’Ingénierie Système P C F
D1.4.2 Politique d’approvisionnement des COTS P C F
D1.4.3 Directives pour le développement de logiciels P C F
D1.4.4 Plan de Qualification des logiciels P C F
D1.4.5 Politique en matière d’Ergonomie, de Facteurs Humains, et d’Interface P F
Homme Machine
GESTION des COÜTS PKM SRR PKA PDR
D1.6.1 Plan et Rapport d’Evaluation des coûts du Projet (au standard ECSS) P C F
D1.6.2 LCC et justification P C F
D1.6.4 Facteurs de coûts déterminants en Opération P C F
- 58/67 -
ASSURANCE PRODUIT ET SECURITE PKM SRR PKA PDR
D1.2.1a Plan d’Assurance Produit pour la phase B P F

D1.2.1b Plan d’Assurance Produit pour la phase C/D (en phase B2) P F
D1.2.2a Plan de Gestion « RAMS » pour la phase B P F
D1.2.2b Plan de Gestion « RAMS » pour la phase C/D (en phase B2) P F
D1.2.3 Fichier d’Assurance Sécurité (SAF) P C F
D1.2.4 Analyse de Risques (PHA) P C F
SPECIFICATION SYSTEME PKM SRR PKA PDR
D1.3.1 Plan de développement et de déploiement P C F

D1.3.2 Plan AIVQ P C F
D1.3.3 Plan d’Opération P C F
D1.3.4 Scénario de référence pour les transitions. Plan de migration vers P C F
services complets.
D1.3.5 Plan de mise en service et d’évolutions pour les services initiaux P C F
D2.1.1 Document d’Exigences Mission (MRD) P C F
D2.1.2 Document d’Exigences Système (SRD) P C F
D2.1.3 Résultats des Analyses Système P C F
D2.2.1 Facteurs déterminants (Mission et Système) P C F
D2.3.3 Spécification Technique du Système P C F
D2.3.4 Spécification des Opérations du Système P C F
D2.3.8 Document d’Interfaces Externes P C F
D2.3.9 Document d’Interfaces Internes P C F
D2.3.8.1 Spécification des besoins et solutions d’adaptation du réseau P F
ASECNA aux besoins du WAN SBAS
D2.3.8.2 Spécification des services des transpondeurs géostationnaires P F
D2.3.8.3 Concept d’interface opérationnel pour l’utilisation des mesures des P F
RIMS EGNOS
D2.3.8.4 Modèles d’ionosphère adaptés à la zone de service. P F
D2.3.1 Statut de conformité au MRD P C F
D2.3.2 Statut de conformité au SRD P C F
D2.3.5 Spécifications Technique des Segments (AC) P F
D2.3.7 Synthèse des évaluations, consolidations et arbitrages en cours de P C F
phase B
D3.1.1 Architecture fonctionnelle (associée au Dossier de Définition système P C F
D3.2.1)
D3.1.2 Interfaces fonctionnelles P C F
D4.1.1 Analyse critique des différents scénarios d’architecture et de P C F
déploiement
DEFINITION SYSTEME PKM SRR PKA PDR
D3.2.1 Dossier de définition (DDF) P C F

D3.2.2 Dossier de justification de la définition (DJF) P F
D3.2.3 Dossier de contrôle des Interfaces externes (DCI) P F
D3.2.4 Dossier de Contrôle des interfaces internes (DCI inter sous-systèmes) P F
D3.2.5 Matrice de Vérification P C F
D3.4.1 Entrées pour le Plan de migration P C F
- 59/67 -
PROTOTYPE et PRE DEVELOPPEMENTS PKM SRR PKA PDR
D3.3.1 Identification de la liste des éléments et technologies critiques, et P F

sélection des pré développements ou expérimentations à réaliser en
phase B2
D7.1.1 Objectifs du Prototype, des Pré développements et des P F
Expérimentations
D7.1.2 Spécifications du Prototype, des Pré développements et des P F
Expérimentations
D7.1.3 Plan de Test, Procédures et critères de succès du Prototype, des Pré P F
développements et des Expérimentations
D7.2.1 Rapports d’expérimentations (incluant les recommandations vers la P C F
définition du système)
D7.2.2 Matériels et Logiciels (exécutables et codes source correspondant aux P F
développements spécifiques, notamment ceux basés sur les
connaissances antérieures du consultant), et les Procès-Verbaux des
recettes Usine et Site
D5.7.1i Spécification technique préliminaire de l’équipement critique (i) P F
PERFORMANCES SYSTEME et SURETE de FONCTIONNEMENT PKM SRR PKA PDR
D4.2.1 Analyses RAMS P C F

D4.2.2 Dossier de Justification RAMS P C F
D4.2.3 Analyses I&CoS P C F
D4.2.4 Dossier de Justification I&CoS P C F
D4.3.1 Budget de Performances (PBMF) P C F
AIVQ SYSTEME PKM SRR PKA PDR
D4.4.1 Plans de Test pour la validation Système P F

D4.4.2 Plans de Test pour la vérification/qualification Système P F
D4.4.3 Spécification des moyens d’AIV et de qualification P F
D4.4.4 Plan de développement des moyens AIVQ P F
D4.5.1 Spécification des outils support en ingénierie P F
D4.5.2 Plan de développement (ou d’approvisionnement) des outils support P F
D4.5.3 Spécification de l’outil support pour la spécification et la définition des P F
interfaces
D4.6.1 Cas Tests pour la validation Système F
D4.6.2 Cas Tests pour la vérification/qualification Système F
D4.6.3 Définition des moyens d’AIVQ F
D4.7.1 Dossier de définition et de justification des outils support en ingénierie P F
D4.7.2 Dossier de définition et de justification de l’outil pour les interfaces F
D4.7.3 Plan de validation et procédures de test des outils support en ingénierie P F
D4.7.4 Matériels et logiciels des outils support en ingénierie P F
- 60/67 -
NIVEAU SOUS-SYSTEME (y.c. Segment Support) PKM SRR PKA PDR
D5.1.1i Spécification du Sous-système incluant sa matrice de traçabilité P F

D5.2.1i Plan de Gestion du Sous-système P F
D5.2.2i Plan d’Assurance Produit du Sous-système P F
D5.2.3i Plan de gestion des RAMS P F
D5.2.4i Plan de développement du Sous-système P F
D5.2.5i Plan AIVQ du Sous-système P F
D5.2.6i Plan de sécurité et sûreté du Sous-système P F
D5.3.1i Dossier de définition préliminaire du Sous-système F
D5.3.2i Dossier de justification Sous-système à partir de sa spécification F
technique
D5.4.1i Analyse RAMS/I&CoS de chaque sous-système incluant les allocations F
DAL
D5.4.2i Analyse de performances de chaque sous-système F
D5.5.1i Document de Contrôle d’Interface (ICD) du sous-système F
D5.6.1i Procédures opérationnelles du sous-système F
OPERATIONS PKM SRR PKA PDR
D6.1.1 Concept d’Opération SBAS-ASECNA P C F

D6.1.2 Justification du Concept d’Opération P C F
D6.1.3 Recueil des Opérations (principales procédures d’Opération) P F
D6.2.1 Evaluation opérationnelle des scénarios de transition P C F
D6.3.1 Exigences opérationnelles pour la spécification du Segment Support P F
D6.4.1 Spécification préliminaire des activités de Logistique et de Maintenance P F
D6.5.1 Définition préliminaire et justification des activités de Maintenance et de F
Logistique
D6.5.2 Recueil des Opérations (procédures principales de Maintenance) P F
D6.6.1 Plan de Validation Logistique et Maintenance F
D6.7.1 Scénarios Opérationnels du Système F
D6.8.1 Plan de validation des Scénarios Opérationnels F
SECURITE et SURETE PKM SRR PKA PDR
D1.5.1 Plan de gestion de la Sécurité et de la Sureté pour la phase B P F

D1.5.2 Plan d’Accréditation P F
D2.4.1 Analyse de la Sécurité du Système et Plan de Traitement P F
D2.4.2 Relevé des exigences sécurité (SecREQ) (définition système et opération) P F
D2.4.3 Spécification préliminaire des Procédures Sécurité (SecOPS) P F
D2.4.4 Répartition les exigences sécurité sur les composantes du système P F
(traçabilité SecREQ)
D2.4.5 Statut de conformité au Relevé des exigences de Sécurité (SecREQ) P F
Tableau : Liste des fournitures
- 61/67 -
6. CALENDRIER ET ECHEANCES
6.1. PHASES et JALONS

[173] La durée de l’étude ne devra pas dépasser 18 mois depuis la réunion de démarrage jusqu’à la clôture
des activités de la phase B2, à l’issue de la Revue de Définition Préliminaire (PDR)
L’étude de phase B est divisée en deux sous phases, ponctuées de jalons intermédiaires :
 Phase B1 :
o Réunion de démarrage : T0
o Point Clef Mission : T0 + 2 mois
o Revue des Exigences Système (SRR) : T0 + 6 mois maximum
 Phase B2 :
o Réunion de démarrage : T0 + 6 mois maximum
o Point clef d’Architecture : T0 +12 mois maximum
o Revue de Définition préliminaire T0 +18 mois maximum
6.2. POINTS-CLES et REVUES

Les revues et point-clés à organiser par le contractant au cours de l’étude sont listées ci-dessous. Les dates
associées à ces jalons visent à rester cohérentes avec le calendrier général du programme SBAS-ASECNA.
Le contractant sera invité à proposer un plan de revue, et un processus de revue. A noter que pour les points-
clés intermédiaires, le processus peut être simplifié.
[174] Chaque jalon (revue ou point-clé) fera l’objet d’une note d’organisation, et doit comprendre les étapes
suivantes associées à des délais indicatifs :
Présentation : Questions/réponses: Comité Directeur: Clôture :

1 semaine 1 semaine 1 semaine 1 semaine 1 semaine 1 semaine 1 à 4 semaines
Analyse des Documents
FEPS + Réponses
Rapport au CD
1) la fourniture des livrables 2 semaines à l’avance
2) une présentation orale par le contractant
3) une session de FEP (Fiches d’Etude des Problèmes Soulevés) et de questions/réponses sur les fournitures,
au plus tard 2 semaines après la présentation orale
4) des Recommandations au Comité Directeur (uniquement pour les revues), au plus tard 3 semaines après
la présentation orale, le Comité Directeur se réunissant au plus tard 4 semaines après la présentation orale
5) une session de clôture 5 semaines après la présentation orale pour les jalons intermédiaires (au plus tard
2 mois après la présentation orale pour la Revue de Définition Préliminaire), à l’issue de laquelle le procès-
verbal d’acceptation des livrables pourra être émis, si les problèmes soulevés qui sont bloquants pour la mise
en œuvre de la phase suivante sont résolus.
6) les relevés de conclusions des réunions qui seront avalisés par l’ASECNA à l’issue de la session de clôture.
Les objectifs de chaque jalon (revue ou point-clé) sont résumés dans la table suivante :
- 62/67 -
ID. TITRE OBJECTIFS DATE LIEU
KOM Réunion de démarrage Lancement des activités de phase B1 T0 ASECNA Dakar

B1 de la phase B1 Fournir des documents d’entrée à l’industrie
PKM Point-Clé Mission Consolider les exigences Mission, les plans de T0+2m CNES Toulouse
gestion de l’étude et la spécification du
prototype
SRR Revue des Exigences Clore la phase B1 T0+6m CNES

Système Toulouse
KOM Réunion de démarrage Autoriser le démarrage de la phase B2 T0+6m Visio Conférence

B2 de la phase B2
PKA Point-Clé d’Architecture Sélectionner le schéma d’architecture et le T0+12m ASECNA Dakar

scénario de déploiement de référence
PDR Revue de Définition Conclure la définition préliminaire T0+16m CNES Toulouse

Préliminaire T0+17m Comité Directeur
à Dakar
RSP Recette site du Prototype Livrer le prototype système T0+16m ASECNA Dakar
Prononcer la recette site du prototype (*)
(*) Date à préciser selon la fin du
développement du prototype
RF Réunion de clôture Clore la phase B T0+18m ASECNA Dakar
Table : Liste des jalons et de leurs objectifs
Les jalons PKM, SRR, PKA et PDR sont considérés comme des revues (dossier des documents à livrer,
présentation orale, processus de RID’s, groupe de revue, questions/réponses, recommandations et Comité
directeur).
Le point-clef de Mission (PKM) ainsi que la revue SRR se tiendront sur le site du CNES à Toulouse.
Le point clef d’architecture (PKA), qui sera traité comme une revue, sera organisé sur le site de l’ASECNA, à
Dakar (la réponse aux questions pourra s’effectuer par visio-conférence), et son Comité Directeur se tiendra
en visio-conférence.
La revue de définition préliminaire (PDR), sera organisée sur le site du CNES à Toulouse, et son Comité
Directeur se tiendra sur le site de l’ASECNA à Dakar.
La recette finale du Prototype Système s’effectuera sur le site de l’ASECNA, à Dakar. Le prototype système
est à livrer à l’ASECNA dès la fin de son développement, étant entendu que le consultant dispose de ses
propres moyens pour la réalisation des études de performances.
La réunion finale de clôture (RF) se tiendra à Dakar.
- 63/67 -
7. FOURNITURES ASECNA
7.1. LISTE DES FOURNITURES (CFI)

ID. NOM du CFI Mise à Remarques
disposition
CFI (1a) Documentation issue du référentiel EGNOS Avec les termes Documentation
citée en référence [DR1 et DR2]. de référence appartenant à l’UE et
mise à disposition de
l’ASECNA
CFI (1b) GPS Feared Events for EGNOS L1-only A la réunion de Documentation
Service, E-TN-SPE-E1-0151-ESA, issue 1.2, démarrage appartenant à l’UE et
18/09/2015 mise à disposition de
l’ASECNA
GEO-3 Statement of Work Annex 1 –
Technical Specifications, E-RD-SPE-E1-0045-
ESA, Iss. 1.1, 18/10/2016
EGNOS RIMS-Hosting Site IRD, EGN-
TASFRQ/200639462U, Issue 1C, 06/06/14
Annex A to EGNOS Services TWAN
Requirement Document 200673714C, Issue
3B, 22/01/15
CFI (2) Résultats Etudes IONO (SAGAIE) [DR4.1] Avec les termes
de référence
CFI (3) Mesures Réseau SAGAIE (fichier RINEX) PKM Autorisation CNES et
ASECNA
CFI (4) Caractérisation Réseau ASECNA [DR4.2] Avec les termes
de référence
CFI (5) Etude GEO Survey [DR4.3] Avec les termes

de référence
CFI (6) Exigences de Sécurité et de Sureté de Avec les termes
l’ASECNA (DA2 et DA3) de référence
CFI (7) Coûts unitaires d’opération de l’ASECNA PKM
CFI (8) Procédures d’exploitation et de maintenance PKM
de l’ASECNA : recueils d’instructions et
circulaires (RIC)
Table : Mise à disposition des fournitures client
- 64/67 -
8. ANNEXES
8.1. DESCRIPTION DES ANALYSES SYSTEME

On identifie dans cette section les principales analyses de sensibilité à réaliser en phase B1 et en phase B2.
Le soumissionnaire est invité à proposer d’autres analyses complémentaires ou alternatives.
8.1.1. Analyses de sensibilité en phase B1

Les analyses de sensibilité en phase B1 devront comprendre au minimum :
 Sensibilité des performances système (Intégrité, disponibilité, continuité) pour tous les scénarios à
étudier (Cf. HLRD, [DA1])
 Robustesse des performances système (Intégrité, disponibilité, continuité) à différents scénarios
ionosphériques (activité solaire nominale et activité solaire extrême), pour le scénario de référence
 Robustesse des performances système (Intégrité, disponibilité, continuité) à différents évènements
redoutés, pour le scénario de référence
8.1.2. Analyses de sensibilité en phase B2

Les analyses de sensibilité en phase B2 devront comprendre au minimum :
 Confirmation du budget de performance des services pour le scénario de déploiement retenu ;
 Robustesse des services opérationnels (continuité du service) lors des évolutions au sein de l’Etape1,
(puis de la transition de l’Etape1 à l’Etape2).
8.1.3. Entrées pour analyse coûts / bénéfices (CBA)

Au niveau du programme SBAS-ASECNA, il est prévu de procéder, pour soutenir le PKA, à une analyse coûts-
bénéfices (CBA).
Outre les fournitures prévues dès la SRR en sortie de tâche T1.6, l’ASECNA doit pouvoir compter sur
l’assistance du prestataire en charge de l’étude pour affiner cette analyse CBA et ainsi conforter le choix
définitif de l’architecture système et du scénario de déploiement de référence, au plus tard lors du PKA, par
ASECNA.
- 65/67 -
8.2. PERSONNEL CLE
Chef d’Equipe, Expert Senior en systèmes de navigation par satellite
Profil de poste
Responsable de la réalisation effective de l’étude préliminaire de définition d’architecture (phase B) du

programme SBAS-ASECNA, et de la gestion de projet y afférente.
Cette personne sera garante de la bonne exécution de l’ensemble des activités de l’étude et de l’atteinte des
objectifs fixés dans les Termes de Références de l’étude. Elle supervisera à ce titre l’ensemble de l’équipe en
charge de cette étude ainsi que tout autre expert intervenant.
Elle sera le point de contact de l’ASECNA avec qui elle assurera toute la coordination nécessaire et à qui elle
rendra compte de manière régulière selon les dispositions définies.
Qualifications et compétences essentielles
 Diplôme d’ingénieur, ou expérience équivalente

 Capacité de compréhension des contextes programmatiques et techniques se rattachant aux systèmes
globaux de navigation par satellite (GNSS) et au système EGNOS
 Connaissance attestée des standards et pratiques de gestion des programmes spatiaux en Europe
 Capacité avérée de gestion d’équipe et de gestion de projet technologique à forte complexité dans le
domaine spatial et de la navigation par satellite
 Capacité de gestion en matière d’assurance qualité, sécurité et sûreté
 Maitrise courante du Français et de l’Anglais
Expérience professionnelle
 Au moins 10 ans d’expérience professionnelle

 Au moins 5 ans d’expérience dans le domaine de la navigation par satellite
 Au moins 5 ans d’expérience dans la gestion d’équipe et la gestion de projet complexe
 Expérience dans le domaine de l’aviation civile
 Une expérience de travail en Afrique serait un atout important
- 66/67 -
FIN du DOCUMENT
- 67/67 -

SBAS-ASECNA - Phase B - TDR V1.2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SBAS-ASECNA - Phase B - TDR V1.2

Transféré par

Droits d'auteur :

Formats disponibles

TERMES DE REFERENCE

REALISATION DE L’ETUDE PRELIMINAIRE DE DEFINITION

D’ARCHITECTURE, DITE PHASE B, DU PROGRAMME

2. PHASE DE DEFINITION : OBJECTIFS DE L’ACTIVITE ......................................... 14

3. EXIGENCES GENERALES ...................................................................................... 20

4. EXIGENCES DETAILLEES. TACHES A REALISER ............................................... 23

5. LISTE DES LIVRABLES........................................................................................... 58

6. CALENDRIER ET ECHEANCES .............................................................................. 62

7. FOURNITURES ASECNA ........................................................................................ 64

1.1. CONTEXTE : LE PROGRAMME SBAS-ASECNA

1.1.2. Besoins opérationnels

1.2. LOGIQUE DU PROGRAMME ET CONTEXTE de l’ETUDE

Les objectifs de cette étude phase B sont :

1.3. OBJET ET STRUCTURE DU DOCUMENT

1.3.2. Structure et contenu

1.4. DOCUMENTS APPLICABLES

DA2 : Exigences de sécurité de l’ASECNA

DA3 : Exigences de sureté de l’ASECNA

DA4 : Standards SBAS

DA5 : Documents de contrôle de l’Interface Signal (SiS)

DA6 : Standards ECSS

DA7 : Concept d’Opération de l’ASECNA

DA8 : Directives EUROCAE

1.5. DOCUMENTS DE REFERENCE

DR1 : Extraits des documents applicables au système EGNOS v2.4.2

DR2 : Extraits des documents applicables au système EGNOS v3

DR3 : Règlements européens applicables au SBAS

DR4 : Résultats d’études antérieures

1.6. ACRONYMES ET ABREVIATIONS

NPR Normes et pratiques recommandées

2. PHASE DE DEFINITION : OBJECTIFS DE L’ACTIVITE

2.1. OBJECTIFS de l ’ETUDE

2.1.2. Résultats à atteindre

2.1.3. Démarche et activités principales

L’étude comprend 4 jalons principaux :

2.1.4. Objectifs détaillés de l’étude

 La phase B1 qui a pour but de :

 La phase B2 qui a pour but de :

2.2. ETUDES ANTERIEURES

2.2.1. Actifs et référentiels EGNOS

2.2.2. Caractérisation de l’ionosphère

2.2.3. Caractérisation du réseau de télécommunications de l’ASECNA

2.2.4. Enquête sur les solutions Géostationnaires

2.3. MISSION SBAS-ASECNA

3.1. EXIGENCES TECHNIQUES

3.2. EXIGENCES d’APPROVISIONNEMENT

3.3. EXIGENCES CALENDAIRES

3.4. EXIGENCES ECSS

Note : pour cette adaptation, [DR2.8] et [DR2.9] pourront être utilisés.

3.5. EXIGENCES DE GESTION DE PROJET

3.6. ASSURANCE PRODUIT, SURETE de FONCTIONNEMENT et

3.6.1. DIRECTIVES ASECNA

[11] appliquer les exigences de Sécurité de l’ASECNA définies en DA2.

[12] appliquer les exigences de Sureté de l’ASECNA définies en DA3.

3.6.2. DIRECTIVES EUROCAE

3.7. Exigences relatives aux droits de propriété intellectuelle

Ce registre sera complété en trois étapes :

4. EXIGENCES DETAILLEES. TACHES A REALISER

4.1. ORGANIGRAMME DES TÂCHES

Le lien entre les tâches et les activités définies est le suivant :

ACTIVITES / TÄCHES WP1 WP2 WP3 WP4 WP5 WP6 WP7

WP1 : Gestion de l’étude

WP2 : Consolidation Mission et Spécification Système

WP3 : Définition système & Scénarios d’infrastructures