document production - european gnss agency ref : date : gala-gmv-dd051 ... • do not delete the...

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: a

DOCUMENT PRODUCTIONYou are using a template created for the GALA data production:

• Do not delete the Document Production and Document Distribution sections.

• Do not modify its styles which are common to all project documents.

• At each section, a short guideline is given to help you find the nature of information to fillin. Those guidelines are given in “Italics” font and are to be deleted.

• Some text are already included . They are presented in the “Normal” font style used in thetemplate. Keep those and complete with the information requested.

• The Company Logo can be added in the footer part.

Before final edition of your document you need to update:

• in the "Summary Folder" :

• Title

• Author (Check it)

• Comments (Document summary)

• in the " Custom Folder", the following properties :

• Doc Approved By (Name)

• Doc Classification (TBD)

• Doc Company (TBD)

• Doc Contract Number (TBD)

• Doc Date Issue (Issue Date)

• Doc Identification (Document Identification)

• Doc Issue Number (Issue Number)

• Doc Project Acronym (GALA)

• Doc Project Name (GALILEO Overall ArchitectureDefinition)

• Doc Status (- / Reviewed / Approved)

• Doc Type (A / R / I)

• Doc Verified By (Name)

• Doc WBS Code (WBS Code)

To do so follow following instructions:

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: b

• Double-click on the following button

U pdate Properties

• Select the property

• Modify it and click on the button Modify

• CTRL+A, F9 , F9 and answer to the questions.(If some are to be ignored, leave the default ones proposed.)

• Before printing, check that Table of Content has been properly updated and fill the field"Date" of Change record with current date.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: c

Hereafter the mandatory fields with a TBD value are listed in RED

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: d

THIS PAGE IS INTENTIONALLY LEFT BLANK

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: A

DOCUMENT DISTRIBUTION

From : Ángel J. Gavín Alarcón

Project Acronym : GALA

Project Name : Galileo Overall Architecture Definition

Title : Support Segment Definition. Synthesis of LLD

Issue : 2A

Reference : GALA-GMV-DD051

Date : 10/11/2000

Pages Number : 46

File : dd051v2a

Issue : 2A

Classification : PU

WBS : WP 7

Contract : GALA-1999-AM-004

Emitting Entity : GMV

Type of Document : -

Status : -

Template Name : GALA.DOT

To :

Internal Distribution

Service Name N° Ex. Service Name N° Ex.

External Distribution

Company Name N° Ex. Company Name N° Ex.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: B

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000

Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 1

Sustainable Mobility and IntermodalityPromoting Competitive and Sustainable Growth

Galileo Overall ArchitectureDefinition

Support Segment Definition. Synthesis of LLD

Written by Responsibility - Company Date Signature

Ángel J. Gavín Alarcón

Miguel M. Romay Merino

All other WP 7 partners

GMV

Verified by

Miguel M. Romay Merino GMV

Approved

Miguel M. Romay Merino GMV

Documentation Manager

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


WBS Code : WP 7

Emitting entity : GMV

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


CHANGE RECORDS

ISSUE DATE § : CHANGE RECORD AUTHOR

1 2/6/2000 First issue. Miguel Romay

2 10/6/2000 Document updated after WP 7 end of activities Miguel Romay

Ángel Gavín

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


TABLE OF CONTENTS

1 INTRODUCTION ......................................................................................................................... 7

2 REFERENCES............................................................................................................................... 9

2.1 DEFINITIONS........................................................................................................................... 9

2.2 ACRONYMS.............................................................................................................................. 9

2.3 APPLICABLE DOCUMENTS............................................................................................... 10

2.4 REFERENCE DOCUMENTS................................................................................................ 10

3 SUPPORT SEGMENT OVERALL DEFINITION AND ANALYSIS ................................... 11

3.1 SUPPORT SEGMENT. MISSION AND OBJECTIVES..................................................... 11

3.1.1 The Role and the Scope of the Support Segment in Galileo.........................................11

3.2 SUPPORT SEGMENT OVERALL DEFINITION.............................................................. 13

3.3 SUPPORT SEGMENT SIMULATION TOOLS.................................................................. 14

3.4 DEVELOPMENT AND CERTIFICATION ISSUES .......................................................... 17

3.5 REUSE OF EXISTING SIMULATION TOOLS ................................................................. 18

3.6 SUMMARY AND CONCLUSIONS ...................................................................................... 19

4 DESIGN SUPPORT TOOLS SPECIFICATION..................................................................... 20

4.1 DESIGN SUPPORT TOOLS DEFINITION......................................................................... 20

4.1.1 Galileo Mission Analysis Simulator (GMAS)................................................................21

4.1.2 Galileo Service Volume Simulator (GSVS) ...................................................................22

4.1.3 Galileo Signal Validation facility (GASIVA).................................................................23

4.1.4 Galileo End To End Simulator (GETES) ......................................................................24

4.1.5 Galileo Network Modelling simulator (GANEMO)......................................................25

4.1.6 Galileo Co-ordination Facility (GCF) ............................................................................26

5 DEMONSTRATION TOOLS SPECIFICATION.................................................................... 27

5.1 OVERALL DEFINITION OF THE GSS DEMONSTRATION TOOLS .......................... 27

5.2 SUMMARY OF THE WP ACTIVITIES .............................................................................. 28

5.2.1 Description of demonstrations........................................................................................28

5.2.2 Functional description of demonstration tools: ............................................................29

5.2.3 Analysis of existing tools..................................................................................................29

5.2.4 Demonstration tools requirements .................................................................................30

5.2.5 Definition of tools .............................................................................................................30

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


5.2.5.1 Updates to simulation tools .....................................................................................30

5.2.5.2 Test Beds...................................................................................................................32

5.2.5.3 Promotion tools ........................................................................................................34

6 VALIDATION TOOLS SPECIFICATIONS............................................................................ 35

6.1 GALILEO VALIDATION CONCEPT ................................................................................. 35

6.2 SUMMARY OF ACTIVITIES............................................................................................... 36

7 SAFETY TOOLS SPECIFICATION ........................................................................................ 37

7.1 INTRODUCTION TO SAFETY ISSUES ............................................................................. 37

7.1.1 Definition phase................................................................................................................37

7.1.2 Design and development phase.......................................................................................38

7.1.3 In Orbit Validation Phase ...............................................................................................38

7.1.4 System Deployment phase...............................................................................................38

7.1.5 System replenishment phase ...........................................................................................38

7.2 SAFETY TOOLS REQUIREMENTS ................................................................................... 38

7.3 SAFETY TOOLS ANALYSIS................................................................................................ 39

8 EXISTING TOOLS UPDATES ................................................................................................. 40

8.1 IDENTIFICATION OF TASKS REQUIRING TOOLS UPDATE.................................... 40

8.2 PROPOSED STRATEGY....................................................................................................... 41

8.3 PERFORMED UPDATES...................................................................................................... 42

9 DEVELOPMENT PLAN OF THE GSS.................................................................................... 43

10 COST ESTIMATES OF THE GSS............................................................................................ 44

11 CONCLUSIONS .......................................................................................................................... 45

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


LIST OF FIGURES

Figure 3-1: Overall Architecture of the GSS ........................................................................... 14

Figure 3-2 High level architecture for the GSSS-P.................................................................. 16

Figure 3-3 High level architecture for the GSSS..................................................................... 17

Figure 4-1: GMAS architecture ............................................................................................... 22

Figure 4-2: Snapshot of the EGNOS Service Volume Simulator (ESVS) .............................. 23

Figure 4-3: Functional diagram of GASIVA........................................................................... 24

Figure 4-4: High-level functions of the GETES...................................................................... 25

Figure 4-5: GCF Interfaces ...................................................................................................... 26

Figure 5-1: Demonstration Tools Architecture........................................................................ 28

Figure 5-2: Graphical Output of ELCANO Urban Environments Module ............................. 31

Figure 5-3: Different points of view of the same street ........................................................... 31

Figure 5-4: More examples of graphical outputs obtained with the Urban Environmentsmodule of ELCANO........................................................................................................ 32

Figure 5-5: GSTB Overall Architecture .................................................................................. 33

Figure 5-6: Two snapshots of video animations showing the deployment phase and the finalconstellation of Galileo.................................................................................................... 34

Figure 6-1: System Life Cycle................................................................................................. 36

Figure 9-1: GSS Development Plan......................................................................................... 43

Figure 10-1: GSS Overall Cost Estimates ............................................................................... 44

LIST OF TABLESTable 4-1: Design Support Tools Definition ........................................................................... 20

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


1 INTRODUCTION

This document provides a summary of all documents produced in the frame of the GALA WP7 ‘Support Segment Definition’, contributions from the following lower level work-packagesare included:

� WP 7.1 Support Segment Overall Definition and Analysis

� WP 7.2 Design Support Tools Specifications

� WP 7.3 Demonstration Tools Specifications

� WP 7.4 Validation Tools Specifications

� WP 7.5 Safety Tools Specifications

� WP 7.6 Existing Tools Update

The WP 7 activities are being performed by a team constituted by 14 European companies.

WP 7.1

Overall Definition

& Analysis

WP 7.3

Demonstration

Tools Specification

WP 7.2

Design Support

Tools Specification Space Engineering

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


WP 7.4

Validation Tools

Specification

WP 7.5

Safety Tools

Specification in tecs sistemi

WP 7.6

Existing Tools

Update

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


2 REFERENCES

2.1 Definitions

The Galileo Support Segment consists of a set of tools to assist the system design,development, validation and demonstration. Only specific GNSS tools will constitute theGalileo Support Segment.

2.2 Acronyms

ADAS Advanced Driver Assistance System

ASQF Application Specific Qualification Facility

COTS Commercial Off The Shelf

DOP Dilution of Precision

EETES EGNOS End-To-End Simulator

EGNOS European Geostationary Navigation Overlay Service

ESTB EGNOS System Test Bed

ESVS EGNOS Service Volume Simulator

FMEA Failure Modes Effects Criticality Analysis

FMECA Failure Modes Effects Analysis

FTA Fault Tree Analysis

GCF Galileo Co-ordination Facility

GDST Galileo Design Support Tools

GETES Galileo End-To-End Simulator

GIS Geographic Information Service

GLONASS GLObal NAvigation Satellite System

GMAS Galileo Mission Analysis Simulator

GNSS Global Navigation Satellite System

GPS Global Positioning System

GRS Galileo RAMS Simulator

GSS Galileo Support Segment

GSSS Galileo Support Segment Simulator

GSTB Galileo System Test Bed

GSVS Galileo Service Volume Simulator

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


IOV In-Orbit Validation

LAN Local Area Network

MEO Medium Earth Orbit

MMI Man Machine Interface

PHA Preliminary Hazard Analysis

RAIM Receiver Autonomous Integrity Monitoring

RAMS Reliability, Availability, Maintainability and Safety

RBD Reliability Block Diagram

SIS Signal In Space

UERE User Equivalent Ranging Error

2.3 Applicable documents

[A.1.] D7.1 Support Segment Overall Definition and Analysis

[A.2.] D7.2 Design Support Tools Specifications

[A.3.] D7.3 Demonstration Tools Specifications

[A.4.] D7.4 Validation Tools Specifications

[A.5.] D7.5 Safety Tools Specifications

[A.6.] D7.6 Existing tools updates

2.4 Reference documents

[R.1.] D2.1 Overall Requirements

[R.2.] D3.3 Support Segment

[R.3.] D6 Overall System Safety Analysis

[R.4.] D8.2 Future Projects

[R.5.] D13 Security

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


3 Support Segment Overall Definition and Analysis

3.1 Support Segment. Mission and Objectives

The major objective of this task is to define the specifications and approach to develop theGalileo Support Segment to support the system definition and design phases of Galileo. Themajor objective of the Galileo Support Segment is to validate, by means of computersimulations or by using real HW, the high level as well as the low level specifications. Inaddition it is also to allow for specific design optimisations and to analyse critical designissues.

The Galileo Support Segment will contain the Galileo system models and database as well asan ensemble of software tools required to support the Galileo design through simulation. Inaddition to that some HW modules will be required mainly for demonstration and validationof the system performances. Moreover, since the Galileo Support Segment will need to beadapted to the unavoidable Galileo design evolving nature, it will have a scalable and flexiblearchitecture, both from the hardware and software point of view. This flexibility allows aneasy incorporation of updates and replacement of tools and models.

Galileo Support Segment definition will take into account the existing initiatives in support ofthe development of tools that could be either included or optimised to become part of theGalileo Support Segment.

In addition and according to the EC resolution, specific attention will be devoted to analysethe potential reuse of EGNOS facilities. Results of INTEG project will be taken into account.

From the different EGNOS facilities to be potentially reused, the ones related to theoperational validation for different applications (as the ASQF) are understood to be the mostpromising ones as they are basically concentrated in the application part and hence are tosome extent Navigation System independent.

3.1.1 The Role and the Scope of the Support Segment in GalileoThe Support Segment for Galileo is intended to provide a set of facilities supporting theoverall development process of Galileo until the system is fully operational. Tools will belater reused for supporting the maintenance and future upgrades of the system.

Those development activities include:

� Design, including

� Constellation design (from deployment up to end of life disposal)

� Signal design

� Support for algorithms design

� Detailed system and mission performances

� Satellites design

� Receiver design

� Augmentations

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


� Demonstration, including

� System demonstration tools (System Test Bed)

� Applications demonstrations tools (Applications Test Bed)

� Promotion Tools

� Validation including tools for both technical and operational validation of

� Signal

� Space Segment

� Mission Segment

� Ground Segment

� Overall Performance

� Safety Tools including tools to perform RAMS analysis, covering:

� System Functional Hazard Analysis

� Component Functional Hazard Analysis

� System Fault Tree Analysis

� System Failure Mode and Effects Analysis

� Component Failure Mode and Effects Analysis

� Common Case Analysis

While Support Segment supports these very different development activities that could be inprinciple of very different nature, the potential commonalties among the sort of tools neededrecommend their definition as a whole as the basis for an optimised design and, hence, cost.

Although that generic definition is very ambitious, the detailed scope of the SupportFacilities needs to be focused in those specific (novel) aspects of a Satellite Navigationsystem. As it is understood that, for other parts of the system which major commonalties withother existing satellite systems, the reuse of existing facilities and infrastructure could bemore efficient. As an example, specific tools required for the validation of the satellite (suchas the ones supporting vibration and thermal tests) are not intended to be defined as part of theSupport Facilities

Many of the tools belonging to the Support Facilities are identified as “simulators” assimulation is a major need for the design of space systems and specially relevant in thedevelopment of navigation systems. In this context, simulation offers an incomparable meansto support all the design and design validation along the overall Galileo developmentlifecycle. The situation in Galileo concerning simulation tools is even more demanding thanin EGNOS as design of the latter has been also supported by the availability of differentprototypes that processed real Signal-In-Space coming from GPS and GLONASS and evenEURIDIS.

Note that the word simulation is used in a broad sense covering any sort of tool that allowsmodelling any behaviour of the system and its environment. While the Galileo SupportSegment is intended to provide a broad simulation capability for many relevant aspects of theGalileo design, it is to be emphasised that it is not intended to cover all potential simulationneeds. But it is basically concentrated in flight dynamics, navigation performance aspects,users and applications. I.e. other simulation tools required for instance for the design of the

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


satellite as far as platform design (e.g. thermal and power control) are not intended to becomepart of the Galileo Support Segment.

Thus, the major activities to be supported by Galileo Support Segment cover:

� Requirements Analysis and Apportionment� Performance analysis and performance budget support in particular, assessment of

the navigation performance (in terms of accuracy, integrity, continuity and availability atuser level) provided by different potential designs/architectures

� Support for system design and parameters selection and optimisation in particular forperforming different design trade-offs and analysis of critical design issues. In particular:

� Support the validation of design by demonstrating its compliance to the differentrequirements and also allowing providing confidence on the system behaviour.

� Support for subsystem design and, in particular, design of different ground segment,satellite and user algorithms related as far as navigation performance is concerned.

� Support to definition of operations in particular those related to flight dynamics.

� Support to definition of performance validation procedures

� Support demonstration activities.

In addition, the Galileo Support Segment shall be designed to be easily upgradeable, to copewith some new requirements or design modifications.

3.2 Support Segment Overall Definition

The basic source or requirements for the Galileo Support Segment are the different activitiesthat are being defined in the frame of the GALA project. Many activities (both of GALA andfuture Galileo development phases) require specific tools to perform analysis, validation,demonstration, certification, etc. When those tools are relevant enough and their commondevelopment and/or independent development becomes a relevant issue they will be part ofthe Galileo Support Segment.

Taking into account the areas of development of the GSS mentioned above, the major toolscomposing the Galileo Support Segment can be classified as:

� Design Tools

� Demonstration Facilities/Tools

� Validation Facilities/Tools

� Safety Tools

It is worthy mentioning the fact that there are several commonalties between these tasks. Forinstance, performance analysis must be done both in design and validation. And safetyanalysis is not a task independent of the system design, demonstration or validation activities.On the contrary, these three activities will heavily contribute to the procurement of safetyevidence. So, in order to avoid duplication of work, we must define an overall concept for theSupport Segment of Galileo. So, the Galileo Support Segment will be constituted by:

� Specific tools for each of the four identified tasks. For instance, a prototype Test Bedmay be needed to support the early Galileo concept definition and to demonstrate itspotential performance. Also, specific tools (e.g. mobile platforms equipped with

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


appropriate Galileo receivers) may also be needed to support the validation of userperformance.

� SW models and simulation tools common to all four activities. Simulation is a majorneed for the design of space systems and specially relevant in the development andvalidation of navigation systems since they are characterised by:

The situation is depicted in Figure 3-1.

DEMONSTRATIONDESIGN SAFETY

SpecificDemonstration Tools

and Facilities

Specific DesignTools

Specific SafetyTools andFacilities

SpecificValidation Tools

and Facilities

VALIDATION

GSSS

GSS

COMMON SW MODELS AND SIMULATION TOOLS

Figure 3-1: Overall Architecture of the GSSOne of the major objectives of the Overall Definition of the Galileo Support Segment is thedefinition of tools that are common to all the different elements of the Support Segment, aslisted above.

It is believed at this stage that the major commonalties will be found around the simulationtools. Therefore a clear definition of this simulations tools has been performed to avoidduplication of work in the different WP 7 sub-packages.

The basic idea is that those simulation tools will mainly be defined in WP 7.2 (DesignSupport Tools) and WP 7.5 (Safety Tools), the rest of the WPs will analyse the possible reuseof the proposed simulation concept and will introduce new requirements to the GalileoSupport Segment Simulator. This will assure appropriate interfaces and will avoid duplicationof work.

3.3 Support Segment Simulation Tools

The role of simulation tools in the Galileo Support Segment will be very high provided thatnot only Galileo design requirements are considered when defining the simulator. Thepreliminary identified Galileo Support Segment requirements cover a very broad definition ofcapabilities covering different aspects and viewpoints of the Galileo system behaviour.

While a highly sophisticated simulator of the Galileo system could theoretically cover allsimulation capabilities in a single tool, cost, time response requirements and efficiency

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


recommends to develop various different independent tools that, properly exploited and co-ordinated, allows to satisfy all different needs in a more efficient manner.

The identification of these different tools and the definition of the means to ensure theircoherence are a key for a successful Galileo Support Segment Simulation tools development.

Based on the EGNOS accumulated experience both as tool developers and operators anappropriate definition of tools has been possible that, according to the experience provides anoptimum design. The following tools have been identified:

� GSVS (Galileo Service Volume Simulator). Assessment of Galileo long term temporaland spatial navigation performance at user level, in terms of accuracy, continuity andavailability (and other related parameters) provided by different potentialdesign/architectures, allowing to perform trade-off studies between several solutions.

� GMAS (Galileo Mission Analysis Simulator). Optimisation of the Galileo constellationconsidering all major requirements. Different aspects will be covered, like:

� End of Life disposal

� Deployment strategy

� Replacement strategy

� Operations and Maintenance

� GETES (Galileo End to End Simulator). This tool will provide the capabilities toperform detailed assessment of Galileo navigation performances based on detailed modelsof the different system components and the environment including:

� Spacecraft platform and dynamics

� Navigation Payload and Signal

� Environment (ionosphere, troposphere, multipath, interference, etc.)

� Ground Segment Data Processing for navigation (including orbit determination, timesynchronisation, etc.)

� User Algorithms

� GRS (Galileo RAMS Simulator). Analysis of the apportionment to the Galileonavigation performance of the different elements and phenomena affecting it, including:

� Assessment of the contribution of the Ground and Space Segment to the systemIntegrity, Availability, Continuity and Maintainability

� Detailed identification, characterisation and study of the effect of failures, systemdegraded modes and feared events on the navigation performances.

� GCF (Galileo Support Segment Co-ordination Facility). The Co-ordination Facilitywill provide a link between the different modules of the Support Segment, and inparticular will contain a database that can be accessed by each of the modules, and a corethat will allow (if required) co-ordinated execution of the different modules. The GCF istherefore responsible for ensuring a coherent exploitation of the other tools and, therefore,constitutes a key element for the Galileo Support Segment. It is also the central databasethat interfaces the Galileo configuration database in order to ensure coherence of thebaseline used for simulation.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


From the above functional decomposition the high complexity of the Galileo SupportSegment can already be observed. Some modules like the GSVS, GMAS and GCF arecovering quite general aspects, but some others like the GETES, and the GRS as coveringquite specific aspects. An adequate implementation of the GETES and GRS will require asignificant level of definition of the Galileo system. This is clearly suggesting a two stepdevelopment approach:

� Phase 1. Prototype development, the prototype shall cover the functionality of thefollowing modules:

� GSVS

� GMAS

� GCF

Figure 3-2 High level architecture for the GSSS-P

� Phase 2. Final version development covering all different modules:

GSSS-P

GCF-P

GSVS-P GMAS-P

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 3-3 High level architecture for the GSSS

The preliminary proposed overall development approach is based on the stepwise approachproposed for the implementation where two major activities (lifecycles) are performed, onefor the engineering (as the basis for detailed definition of the URDs for Galileo SupportSegment Simulator) and a second one for the SW development.

Engineering activities will be performed mainly during the prototyping phase but will be laterrefined as result of:

� Experience gained during the prototyping phase.

� Updated context for Galileo Support Segment Simulator development as, for instance, theavailability of a more detailed Galileo architecture.

3.4 Development and certification issues

Development approach and certification issues have been analysed in the frame of WP 7.1.

The main conclusion of the study is the necessity for a development effort, prior to thestarting of the segment development process, in order to define an specific and appliedsoftware development standard document, that based in ECSS general standards and DO-178B guidelines.

The objective is not to create a third standards, but a handbook on the implementation on thestandard.

This handbook shall have insight on the different approaches to be applied to differentcomponents (MMI, prototype, validation approved, operational approved); taking intoaccount the evolution from one kind of component to the other (i.e. from prototype to designuse, to validation use, to operational use)

The handbook shall include as well the set of COTS that are approved for use in the projectand their qualification status.

GSSS

GCF

GSVS GMAS

GETES GRS

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Is of key importance the availability of the final document before the Galileo SupportSegment development is launched.

The document shall be also used as a key element in the qualification of the validation toolsfor the certification of the overall system.

Another key issue is the independence that the certification authority may impose between thedevelopment tools and the validation tools. Should this independence requirement exist fromsystem level certification proceedings, the pertinent feedback to the currently envisagedarchitectural design (considering common design and validation facilities) is to be made.

Potential ways to improve productivity are to define a flexible and re-usable architecturalsolution; based on COTS, built in certifiable stacks for communication protocols; and theoutsourcing of the verification process for components that would require the higher level ofqualification.

It is recommended that an agent independent to the developer of the Segment will first definethe document, and then perform the pertinent liaison process.

Finally, it is necessary to remark that requirements on Galileo Support Segment developmentcertification issues will depend on Galileo wide requirements.

3.5 Reuse of existing simulation tools

The following major tools which provides functionality which are on-line with some of thefunctionalities required by the Support Segment, therefore they constitute a strong startingpoint for SW reuse, or for requirements & functionality identification:

� ELCANO

� ORION

� EETES

� ESVS

� OPTINAV

� AVIGA

� EGNOS Support Facilities

Some of these tools are briefly described in low level WP 7 documents and they provide agood indication about the complexity and functionality of the Galileo Support Segment. Theirpossible application (reuse) to the Galileo Support Segment development will be analysed inthe next subsections.

It should be considered that these tools have not all been developed following the samestandards and using the same programming languages. This will condition the possible reuseof the tool.

In some cases, like for the tools developed in the frame of EGNOS, a high reuse is envisaged.In some others the reuse would be at the algorithm level, like for ORION were some moduleshave been developed in Fortran 77.

In any case and considering the high technical complexity of the Galileo Support Segment amaximum reuse is necessary, especially for the prototype, in order to achieve the objectives.The major criteria for the reuse will be:

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


� Programming language

� Efficiency of the implemented algorithms

� SW Standards used during the development

� Verification and validation status

� EGNOS functionality

� Modularity and flexibility of the code

� Property rights

� Complexity

Reuse of tools like ELCANO, ESVS, and ORION will guarantee the success of the GalileoSupport Segment prototype, while the reuse of the EETES and the prototype will guaranteethe success of the final version of the Galileo Support Segment.

The reuse of EGNOS tools is believe to be fundamental in order to keep compatibility withGNSS-1. For instance the reuse of the EETES for the GETES will guarantee all end-to-endEGNOS simulation capabilities in the Galileo Support Segment Simulator without additionaleffort, the same is applicable to the reuse of the ESVS.

3.6 Summary and conclusions

The overall concept for the Support Facilities have been defined, by:

� Analysing the requirements

� Defining the major functionality

� Defining the major components

� Defining the simulation concept and tools, including a preliminary development approach

� Analysing the possible reuse of existing tools

A significant effort has been done to clarify those tools which are common to the differentelements of the Support Segment to avoid duplication of work.

It is important to remark the major scope of the support segment:

The detailed scope of the Support Facilities needs to be focused in those specific (novel)aspects of a Satellite Navigation system. As it is understood that, for other parts of thesystem which major commonalties with other existing satellite systems, the reuse of existingfacilities and infrastructure could be more efficient. As an example, specific tools requiredfor the validation of the satellite (such as the ones supporting vibration and thermal tests)are not intended to be defined as part of the Support Facilities.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


4 Design Support Tools Specification

The major objective of the Design Support Tools is to support the Galileo system designphase, by means of computer simulations or possibly by using real HW. More specifically,they are aimed at fulfilling the following tasks:

� Optimise the system design, allowing

� Performance analysis

� Performance margins assessment

� Analysis of critical design issues

� System trade-offs

� Algorithms development and optimisation

� Apportionment of performance requirements among the different system componentsand/or segments

� Support for system design and parameters selection and optimisation

� Support for subsystem design and, in particular, design of different ground segment,satellite and user algorithms but only as far as navigation performance is concerned.

In addition, the Design Support Tools shall be flexible and scalable enough to be easilyupgradeable, to cope with some new requirements or design modifications, since Galileo hasan unavoidable evolving nature. Furthermore, special attention must be paid in the reuse ofEGNOS tools and facilities, taking also into account INTEG results.

4.1 Design Support Tools definition

Taking into account design objectives and requirements (analysed also in WP 7.2), as well asthe overall definition of the Support Segment, as defined in WP 7.1, tools in Table 4-1 areaimed at fulfil the proposed tasks.

Task Kind of Tool Tool name

Optimise constellation Mission Analysis Tool GMAS

Long Term Performances Service Volume Simulator GSVS

Signal Design & Optimisation Signal Simulator GASIVA

Algorithm Design End-To-End Simulator GETES

Data Transmission Analysis Network Simulator GANEMO

Co-ordination between Tools Co-ordination Facility GCF

Table 4-1: Design Support Tools Definition

A short description of each of the tools is provided in the next subsections.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


4.1.1 Galileo Mission Analysis Simulator (GMAS)The Galileo Mission Analysis Simulator (GMAS) will allow the design and optimisation ofthe Galileo space segment with a high degree of realism. This tool will be based on someexisting tools already developed to support the design of constellations and in particular fornavigation and telecommunication constellations.

The major functionality of the GMAS module will be:

� Constellation design. This module will allow optimising the Galileo constellationconsidering all major requirements. This will allow performing trade-offs betweenconstellations and performances (and in particular DOP). Sensitivity analyses withrespect to the major constellation parameters can also be performed. The major objectivewill be to design a constellation fulfilling all requirements with a minimum cost.

� Constellation deployment and replacement strategies. An extensive launcher databasewill be implemented to support the optimum selection of launchers as well as to definethe optimum constellation to minimise deployment costs. The replacement strategies willalso be optimised according to the major requirements.

� Space Debris analysis. When selecting the Galileo constellation the risk of collision withspace debris shall be analysed, not only considering the actual situation but alsoconsidering the complete Galileo operational life. Some modules will be implemented toassess those risks and to support the definition of the optimum constellation.

� Operations and Maintenance. Some tools will be implemented inside the GMAS todefine the optimum control strategy for the selected constellation. This again will allowoptimising the constellation to minimise the number of manoeuvres required, and thusmaximise the operational life of satellites.

� End of Life disposal. Some modules will be implemented to assess the most suitable endof life disposal strategy.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


MMI

Results Analysis ToolVertical accuracy versus

number of satellites/number of orbital planes(Without GEO)

3456789

101112

24 26 28 30 32 34 36 38 40Number of satellites

Acc

urac

y (m

) 3 planes4 planes5 planes6 planes

MMI

Simulation Control Tool

MMI

Scenario Definition Tool

GMAS DBGMASMMI

•Constellation File Generation•Measurement Grid Interface•Environment conditions•Archiving filters

•Simulation core modules•Simulation Definition•Debugging•Monitoring•Simulation Control

•Map generation•Statistical toolbox•Chart Generation•Archiving filters

Operator

GCF

Figure 4-1: GMAS architecture

4.1.2 Galileo Service Volume Simulator (GSVS)The Galileo Service Volume Simulator (GSVS) is a simulation tool that allows performingthe Service Volume Simulations. So, the objective of the GSVS is to analyse in a fast andeasy way the space time variations of GALILEO accuracy, availability, integrity andcontinuity performances for different navigation requirement, degraded modes andoperational scenarios.

The GSVS is a system engineering tool planned to be used in the frame of:

� Evaluation of space-time variations of Navigation Performance : during advancedproject, design, validation and operational phases

� Support to justification and validation of design

� Support to performance management (requirement allocation, margins management)

� Support to system architecture sizing : space segment configuration and maintenancestrategy, ground stations network configuration.

� Support to Safety assessment : contribution to integrity and continuity of serviceassessments

� GALILEO promotion and performance demonstration: accuracy, availability andcoverage maps and animations, in particular for demonstrations outside Europe.

� Support to mission planning functions design (elaboration and evaluation of integrityMEO up-link planning algorithm, operational mission prototyping and demonstration)

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 4-2: Snapshot of the EGNOS Service Volume Simulator (ESVS)

4.1.3 Galileo Signal Validation facility (GASIVA)The general purpose of this tool is to study the Galileo signals, mainly the navigationdownlink signal and optimise their performances: link budget, coding, frequency, data rate,encryption scheme…

The goal is to simulate the RF signal coming from GALILEO satellites, as seen by a userterminal, taking into account everything that affects the signal in its path between the satelliteand the user receiver, and to analyse the impact of the different options on the quality of thereceived signal.

The Simulator will generate a signal that will be input to the receiver (Test User terminal),and the simulation process as well as the received data collection and analysis will beperformed at a Control and Processing Unit.

This tool will be a laboratory test bed, and will work as a standalone tool, without need of anyother hardware. Nevertheless it needs an interface with GCF (see before), to export outputfiles, and to import input files, such as user receiver characteristics, constellation files….

GASIVA will also provide the capability of adding additional signals to be input to the userreceiver. These signals may come from an external GPS constellation simulator, GEOsatellites GNSS signals.

The generated signal can be also input to other instruments, so that other measurements ortests can be performed.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


COMMAND & CONTROL

CPUCOMMAND

& CONTROL

SIMULATOR

SignalGenerator Signal

Receiver

PROCESSINGMODULE

MMI

AdditionalHW

GCF EXPORT& IMPORT MODULE

DB

AdditionalSignals

Figure 4-3: Functional diagram of GASIVA

4.1.4 Galileo End To End Simulator (GETES)The GETES will be a highly sophisticated non real time tool that will feature faithfully themain Galileo system functions as far as affecting navigation performance.

The GETES will simulate, with a high degree of realism, the navigation performances for acomplete variety of users under different operating conditions and different modes (includingdegraded modes) by including detailed simulation models of all major elements of the systemand the environment that affect to those performances.

The objectives of the GETES are

❑ To provide a system end-to-end simulation as the basis for detailed analysis of systemlevel performance and with the capability to analyse the effect of different designsolutions and parameters in the overall system performance.

❑ Detailed investigations of the effect of failures as the basis for supporting integrity andcontinuity performance analysis as well as supporting different RAMS investigations.

❑ Detailed investigations of the effect of environment in the overall system performance.

❑ Support the detailed design of critical subsystems, especially those involvingsophisticated computation algorithms (payload, ground data processing...)

❑ Investigation of operational aspects such as on-board autonomy, frequency of up-link,messages characteristics...

❑ Optimise Galileo design in terms of requirements compliance (with the proper margins).

To allow a better understanding of what the GETES will be, notice that, in particular, it willsupport the development of ground segment and user receiver algorithms for a variety ofscenarios. So it will simulate the whole system (as far as navigation is concerned) and itsenvironment allowing testing those algorithms by “inserting” them in the simulator (a suitablemechanism is provided).

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 4-4: High-level functions of the GETES

Figure 4-4 shows the high-level functions of the GETES (apart from the MMI and thescenarios definition module). The boxes coloured in grey are those replaceable, allowing thecorresponding algorithms to be developed. The GETES will include high-sophisticatedmodels in order to produce simulations as realistically as possible. Notice that the GETESwill be able to handle with real measurements gathered, for instance, by the Galileo SystemTest Bed (GSTB). See section 5.2.5.2.

4.1.5 Galileo Network Modelling simulator (GANEMO)The complexity of the Galileo network calls for a complete modelling of thenetwork/satellites ensemble, to be achieved by the use of a suitable simulation tool, in order toverify the achievement of the service requirements. In order to accomplish this task theGalileo Network Modelling simulator (GANEMO) is proposed.

GANEMO will be capable of analyse, simulate and gather results of the data flow over thewhole Galileo Network, including MEO and GEO satellites, ground stations, processing andcontrol centres. GANEMO will allow:

� The detailed analysis of the latency times budget.

� Modelling and optimising:

� the network and data links, including up-links and down-links

� Hardware architecture

� Redundancies, analyse switchover and switchover delays

� Navigation-related communication services.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


4.1.6 Galileo Co-ordination Facility (GCF)The main purpose of the GCF (Galileo Core Facility) is to provide an environment in whichthe GDST (Galileo Design Support Tools) components and largely the GSSS (GalileoSupport Segment Simulator) tools can co-operate in order to:

� Support the system definition and the design phases of Galileo, including system trade-off, performance analysis, algorithms development and optimisation

� Validate the Galileo specifications

GCF shall provide the following basic functionality:

� Principally:

� A database for managing the system configuration data and the interface filesbetween the different tools, and for ensuring the configuration control of simulations

� Related archive facilities, to store all simulation parameters collected as well as datagenerated during a simulation run

� Command and control for all the components (tools and objects) embedded in theGDST system

� And also

� Support the documentation of the simulation results in order to reduce as much aspossible the human workload when generating detailed analysis of results, synthesisand conclusions

� Prepare, execute and evaluate a simulation session involving all or part of the GDSTcomponents

� Man-machine interface capability, implementing a user friendly graphical interfaceby means of which the operator of the GCF can have full control of all the abovefunctionality

� Provide the GDST components with common basic functions, such as orbitsimulation, mathematical functions, graphical functions…

ValidationTools

GSVS

S tationlocations

Uplink filesGETES

E rror budget

S imulated data

GMAS Constellationparameters

Nav. message specifications

SafetyTools

Failure & s tateprobabilities

DemoTools

User environment

GSTB R eal data

GASIVA S ignal definition GANEMO

Network & Hwarchitecture

Transmissiondelays

Figure 4-5: GCF Interfaces

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


5 Demonstration Tools Specification

Demonstration tools will support the demonstration of the compliance of the differentnavigation requirements at users/applications level. Notice that by demonstrations we meanboth system and applications demonstrations.

In order to set a suitable definition of the GSS Demonstration Tools, the following topicshave been considered

� First of all, the capable areas of demonstration have been identified and described. Thisleads to a set of capabilities that demonstration tools must include.

� Second, the overall definition of the Galileo Support Segment (as described in WP 7.1)have been taken into account to assure the coherence with the rest of GSS tools

� Finally, the experience of EGNOS (which is also pointed out in WP 7.1) has been alsoconsidered fundamental. It is expected to reuse as much as possible EGNOS tools andfacilities

Having these issues in mind, we have defined an architecture for demonstration tools, whichis presented in the next section.

5.1 Overall definition of the GSS Demonstration Tools

The demonstration tools will basically be constituted by:

� Simulation tools. These tools will be playing an important role during the early Galileodevelopment phases, as no real SIS will be available. To minimise the effort most of thesimulation tools used for demonstration will have a high commonality with those used fordesign, validation or safety. Therefore only those new requirements imposed bydemonstration needs will be here discussed. Actually, this tools will be necessary updatesto simulation tools (specially the GETES and the GSVS) for demonstration purposes,including issues such as

� Urban canyons

� Local augmentations

� Use of other systems and sensors

� Test Beds. Including a system test bed (GSTB) and test beds for specific purposes. TestBeds will play a major role when real Galileo components become available. The GalileoTest Bed will have to be defined here by providing specifications. It is important to takeinto account that the EGNOS Test Bed is already in use, and some practical experiencewill be collected in order to define better the Galileo Test Bed. The possible use of theEGNOS Test Bed during the early Galileo development phases.

� Promotion Tools. These tools are considered as auxiliary tools that will allow presentingthe results obtained when using the simulation tools or the Test Bed in a clear andcomprehensive manner. Mainly by means of computer animations showing theperformances achieved for the different applications.

The architecture of the GSS Demonstration Tools is depicted in Figure 5-1

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


SIMULATIONTOOLS

TESTBEDS

PROMOTIONTOOLS

GSSS

DEMONSTRATION TOOLSOTHER GSS

TOOLS &FACILITIES

Figure 5-1: Demonstration Tools Architecture

The figure shows also some interfaces related with demonstration tools. So, both Test Bedsand Simulation Tools1 are able to provide data to promotion tools to make “realistic”presentations based on real or simulated data. Also Test Beds can provide real data toSimulation Tools. Regarding with external interfaces, Test Beds can also provide real data toGSSS such as the GETES (Galileo End-To-End Simulator). On the other hand, simulationtools are related with GSSS tools by its own definition (for instance, a urban canyon simulatorcan provide information on the masking angle to the GSVS or even the GETES). In general,demonstration tools can be related with other GSS tools (for instance, with safety tools).

5.2 Summary of the WP activities

5.2.1 Description of demonstrationsUsing inputs coming from mass market analysis (GALA WP 1) and pilot projects (WP 8), thefollowing application areas have been considered of interest as far as applicationdemonstrations are concerned:

� Train Control

� Advanced Driver Assistance Systems

� Electronic Tolling

1 More exactly, Updates to Simulation Tools. For shortness, we will use simply SimulationTools in this document (if no confusion).

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


� Time and Frequency (time transfer and calibration; synchronisation of communicationnetworks…)

� Land Survey and GIS mapping

� Oil and gas off-shore positioning and hydrographic survey

� Controlled Access (which would address the data broadcast function of Galileo)

� Urban canyons

� Signal Robustness (to hostile environments)

5.2.2 Functional description of demonstration tools:In order to fulfil demonstration requirements, demonstration tools need also the followingcapabilities (both from simulation and test beds point of view):

a) Other sensors and navigation systems: Some applications need other sensors or systems,to enhance the availability, continuity or integrity performance provided by GNSS, as wellas the level of protection against poor environment conditions (loss of satellite visibility,RF interference…).

b) Local augmentations systems: Local augmentation can be introduced in demonstrationsfor either one of the following two possible purposes:

✓ to simulate a real application that would use it, mainly for availability or integrity

✓ to compensate for the DOP l i mitations provided by the test bed facilities (GSTB,IOV); this applies particularly to ADAS and train control applications, that require asub-meter accuracy (at 95%)

c) Failure events generation: The purpose of this tool is to support the demonstration ofintegrity service provision. Integrity performance cannot be the subject of convenientdemonstrations, since it is essentially described with a very low probability level ofhazardous misleading information.

d) Urban canyon availability: The urban canyon is a common environment for manysatellite navigation applications, either car or pedestrian navigation. Considering theexpected number of Galileo terminal units, the urban canyon may well be a commonsituation for most of the users. The poor satellite visibility conditions generate a lack ofavailability, and the need for additional sensors or systems.

e) Generation of RF and multipath: The purpose these tools is to generate someperturbations to a Galileo SIS receiver, in order to show its ability to cope with them,presumably better than what GPS/EGNOS receivers do.

5.2.3 Analysis of existing toolsa) The EGNOS System Test Bed (ESTB): A complete analysis and description of the ESTB

is provided as it is considered fundamental for the next reasons

✓ Its objectives, architecture a n d applications are a reference for a Galileo SystemTest Bed (GSTB) proposal

✓ It is expected its inclusion in the GSTB itself (or an appropriate update, namedESTB+) for the regional integrity provision within Europe.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


b) User/applications environment simulation tools: The simulation of physicalenvironments like urban or space environments for demonstration purposes is becomingnowadays spreadly used. Very modern tools allow the fast development of 3D applicationswith very real models of the everyday life objects (cars, people, houses, monuments,airplanes, etc), which can directly interact with all kinds of users in real time. Severalcommercial environment 3D simulation tools are analyzed, providing relevant informationabout their main functionalities and to develop a comparison basis using several metrics.

5.2.4 Demonstration tools requirementsRequirements for demonstration tools have been established. These requirements have beensplit in each of the demonstration areas, namely, simulation tools, test beds and promotiontools.

5.2.5 Definition of tools

5.2.5.1 Updates to simulation toolsThe updates to simulation tools are presented by means of a prototype. Starting fromELCANO (which is a constellation design tool developed by GMV in the frame of Galileo,having functionalities of a Service Volume Simulator), a urban environment module has beendeveloped.

This module allows:

� Considering different constellation: Every satellite is defined by its Keplerianparameters, relative failure probability and the UERE budget model that will be used tocalculate the positioning accuracies.

� Considering different UERE budgets: Contains information about different UEREbudget models as function of the elevation angle.

� Modelling the street characteristics at will of the user (latitude, longitude and azimuthorientation of the street, together with the size and relative location of the different layersof obstacles, typically buildings).

� Choosing different simulation parameters, such as vehicle velocity, the time interval inwhich the constellation is propagated, use of augmentation systems, the availability levelat which performances will be calculated, etc.

� Computing navigation performances over the user trajectory along the street for thegiven availability level. It contains the longitude and latitude variation (in degrees) of theuser location along the road within the fixed time step and the given velocity. It alsoprovides performance values for each step (horizontal accuracy, vertical accuracy, etc).

A graphical tool allows an easy and comprehensive interpretation of the results. A snapshot ofone of such graphical outputs is shown in Figure 5-2, which shows the number of satellites inview for a typical European street. On the left of the picture we can see the street from bothsides (buildings and obstacles are represented as green rectangles), as well as the number ofsatellites in view along the street according to the coloured scale shown on the right. A three-dimensional representation of the street and the performances is also provided.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 5-2: Graphical Output of ELCANO Urban Environments Module

Some graphical capabilities are also included, such as zoom, change of the point of view,move a car interactively… See Figure 5-3 and Figure 5-4.

Figure 5-3: Different points of view of the same street

More graphical outputs are shown in Figure 5-4 below. A GPS + Galileo constellation hasbeen used.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 5-4: More examples of graphical outputs obtained with the Urban Environmentsmodule of ELCANO.

The development of this module has allowed us estimating:

� The complexity of this kind of tools

� The development time and effort needed

� The cost

5.2.5.2 Test BedsBy Test Beds we mean both a system test bed and test beds for specific purposes. The majoreffort has been devoted to the first one, due to its relevance, complexity and the lack of acomplete identification of such specific test beds, whom necessity will arise during the designand development phase of Galileo.

The objectives of the Galileo System Test Bed (GSTB) are

❑ To have a first assessment of the global performance that may be reached for real usersunder real conditions with Galileo

❑ To analyse in depth specific critical design issues or trade-offs between several options

❑ Allow the early detection of operational problems, implementation problems andlimitations

❑ To develop and validate system test methods

❑ Real gathering data for use in other prototypes (GETES…)

❑ To analyse the interoperability and compatibility with EGNOS, and potentially otherGNSS systems

❑ To support the In Orbit Validation (IOV) phase

❑ Demonstration to users with real applications of the operational system

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


According to these objectives, an architecture for the GSTB has been proposed. The keydrivers used in such proposal have been

� GSS demonstration tools objectives and requirements

� Galileo baseline architecture

� Experience from the EGNOS Test Bed (ESTB) and the reusability of this tool

� Modularity

� Flexibility

GLOBALCOMPONENT

REGIONALCOMPONENT

USERCOMPONENT

DATA ANALYSIS COMPONENT

Figure 5-5: GSTB Overall Architecture

The overall architecture is depicted in Figure 5-5. The GSTB will be constituted of:

� A global component: including all stations, networks and processing facilities needed forthe global mission of Galileo (orbit determination, time synchronisation…)

� A regional component: in charge of providing regional integrity information withinEurope, compliant with INTEG conclusions. It is expected that the ESTB will be used forthis component

� A user component, essentially a user receiver allowing its inclusion in differentplatforms making use of suitable interfaces

� A data analysis component, for the off-line analysis of the navigation performances

The satellites can be associated to the global component. The GSTB tries to reflect as much aspossible the Galileo actual system, providing and using a real SIS. However, the system hassome limitations in terms of accuracy, availability… when compared with the actual system.For instance, it will use a reduced number of satellites, not the complete Galileo constellation.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


More details can be found in the document and, in particular, a more detailed architecture ofthe system.

5.2.5.3 Promotion toolsPromotion tools will be produced to demonstrate the capabilities of the Galileo system,although they are not really part of the core of the Demonstration Tools. A promotion tool hasbeen developed starting from prototypes in order to estimate the final cost of these tools. Twosnapshots are shown in Figure 5-6.

Figure 5-6: Two snapshots of video animations showing the deployment phase and thefinal constellation of Galileo

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


6 Validation Tools Specifications

The objective of the Validation Tool Specifications is to identify the tools that must beconsidered to prove that system is in accordance with the Galileo requirements. The final aimof the work is to prove that Galileo accomplishes high levels of Safety and Security for theUser.

6.1 Galileo Validation concept

Figure 6-1 shows the Galileo life cycle by means of a ‘V’-diagram that provides a graphicaloverview of the process that leads to an operational use of Galileo. There is a distinctionbetween the technical and the operational validation:

� Technical Validation - Validation of factors (i.e. requirements) not directly concernedwith the provision of a service (e.g. survival in a space environment) but necessary tosupport the mission. Such factors should be susceptible to a large degree of validationwithout consideration of the intended use. If well understood, such factors may also besufficiently validated by more abstract means and not require more concrete testing. Ingeneral it may be expected that technical validation will not require open ended scenariosbut can be assessed within repeatable, well defined conditions.

� Operational Validation - Validation of factors (i.e. requirements) that are directlyconcerned with the provision of a service or where the intended uses are significant. Suchfactors are likely to involve complexities that are not susceptible to analyticalunderstanding and that may require more concrete testing. In general it may be expectedthat operational validation will involve interactions and dynamic, adaptive conditions.

According to this the cost assessment for validation tools is divided into technical andoperational validation.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Figure 6-1: System Life Cycle

6.2 Summary of activities

This WP is devoted to the analysis and specification of tools needed to support the validationprocess of Galileo. The major aspects that have been addressed are:

� Identification of “elements” (in a wide sense) to be validated (with inputs from DD037)

� Identification of requirements for validation tools

� Analysis of tools for validation (both technical and operational)

� Development planning and cost estimates

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


7 Safety Tools Specification

7.1 Introduction to safety issues

The objective of this activity is to describe the requirements and the preliminary cost elementsof existing safety and RAM tools.

Tools related with safety are:

� Tools for Preliminary Hazard Analysis (PHA)

� Tools for Failure Modes Effects Criticality Analysis (FMECA), Failure Modes EffectsAnalysis (FMEA) and Fault Tree Analysis (FTA)

� Tools for RBD (Reliability Block Diagram)

� Tools for apportionment

� Tools for stress/strength

The rest of this section is devoted to explain briefly the impact of safety issues in followingGalileo phases.

� Definition phase

� Design and Development phase

� Overall System Validation phase

� System Deployment phase

� System Replenishment phase

7.1.1 Definition phaseThe objectives of the definition phase are to provide the design and the specifications down toelement level of:

� The overall Galileo architecture

� The Galileo components (Global, Regional, Local)

� The user segment

� The support segment

� Launchers and Spare Strategies

(The planning today is based on the hypothesis that no launch failure will happen. A riskAnalysis should be performed and alternative strategies for spare management have to bedefined to minimise the effects of launch failures.)

The inputs for this phase are the RAMS requirements and the specifications ofcomponents. Using qualitative (PHA, FMECA, FMEA) and quantitative (apportionment)methods, a preliminary validation of software tools is possible, as well as theconsolidation of specifications down to element level. Different SW tools have beenanalysed for those methods.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


7.1.2 Design and development phaseFrom RAMS requirements and specifications of the elements, the safety analysis allows:

� The specifications for subsystems and equipment

� Detailed results of design development and testing

� Input for LCC-analyses

Qualitative (PHA, FMECA, FMEA) and quantitative (apportionment, FTA, RBD, loadstrength) methods are used. Different tools have been analysed.

7.1.3 In Orbit Validation PhaseAccording to DD067 the overall system Validation phase includes three main sub-phases:

� Overall System Validation Design phase

� In Orbit Validation phase

� Final System Validation phase

The objective is to define the complete validation process (first step) and to perform anintermediate validation campaign on a reduced system configuration (second step). The thirdstep is aimed at performing of the overall system validation campaign.

The In-Orbit Validation phase is to design, prepare and execute an intermediate validationcampaign bases on a reduced system configuration of the Global Component.

The In-Orbit validation phase is analysed in validation work packages.

7.1.4 System Deployment phaseAccording to DD 067 this phase is defined as the phase in which the complete systemconfiguration can be set up, being the system design frozen.

The objective of this phase is to carry out the deployment of the complete final system,including the Global Component, the European Regional Component and a reference LocalComponent.

During this phase the engineering model of the user terminals have to be finalised in order toguarantee the availability of different types of user terminals for the validation phase.

The major controversy of this phase is the complete system set-up ready to be validated.

There are no interactions between RAMS software tools and the validation process.

7.1.5 System replenishment phaseThis phase takes place in 2008-2038. There is no way to imagine what software tools in safetyand RAMS analysis will be developed up to these years.

7.2 Safety tools requirements

A set of requirements for safety tools has been analysed. This has been done to identify toolsneeded for safety analysis. A traceability matrix of these requirements against safety tools(see next section) have been done to investigate if all these requirements are fulfilled.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


7.3 Safety tools analysis

A complete analysis of tools for safety analysis has been provided. For each tool, thefollowing topics have been considered (when available):

� Supplier

� Description

� Cost elements (including different licenses, maintenance and training)

As result of this analysis, together with the requirements mentioned before, it has been shownthat safety analyses can be performed using COTS, and no new tools have to be developed.Recommendations regarding with these COTS are also provided.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


8 Existing Tools Updates

The major objective of this task is to perform minor upgrades to existing tools in order tosupport the Galileo overall architecture definition. Those upgrades will only be performed incases where the availability of the tool is urgent and some design issues would not be closedif the tool were not available.

Within this task the following major activities have been identified:

1. Identification of upgradeable tools. The needs for a tool upgrade will be identifiedmainly in the frame of WP 2, Overall system requirements and trade-offs.

2. Analysis of the tool to be upgraded. The possible tools to be upgraded will have to beanalysed to assess if the required modification/upgrade is feasible, and in particular, in thecase that several tools were available, to identify the most suitable tool.

3. Definition of the upgrade. The upgrade to be implemented will be defined to a level ofdetail that will allow the further implementation process. Some support from the potentialusers of the tool may be required to identify the major requirements.

4. Implementation and validation of the upgrades. The identified upgrades will beimplemented and tested. The level of detail of the validation phase will be depending onschedule.

5. Documentation. The implemented changes will have to be documented; these documentscould be considered as annexes to the available documentation of the tools.

8.1 Identification of tasks requiring tools update

In a first step the tasks that are requiring an urgent upgrade of the tools are those identified astechnical trade-offs, and technical issues.

Trade-off analyses will be performed in the navigation and communication domains, in linewith the baseline document and include key technological objectives that impact Galileoarchitecture definition. The following main areas for trade-offs have already been identified,and are addressed by Work Package 2. The major trade-offs will be:

� Performances and constellation. Advanced tools will be used to consider all theperformance requirements in the high-level constellation design. Technical advances andinnovation are necessary to be able to consider diverse sets of requirements, to assess thefinal user performance in a representative way, and to analyse all possible constellationsin an exhaustive way. The selection of possible constellations also needs adequatecriteria, deployment cost including launch being one of them.

� Integrity. Scientific advances will be performed on integrity processing, based on theexperience gained on EGNOS: integrity processing will be analysed for each constituentof Galileo system, namely the ground segment, the satellite and the user terminal.

Another key domain is related to the selection of Galileo satellites that broadcast integrityinformation. The technical selection criteria will be analysed, and subsequent simulations willbe performed to determine the number of integrity channels needed to broadcast integrityinformation from coincident regions. A worldwide integrity broadcast from a unique entitycould be rejected for legal and strategic reasons.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


Also integrity broadcast could be performed through ground infrastructure.

� Almanacs, ephemeris and corrections. A high level technical approach will beconsidered to derive the most adequate scheme for user data provision. Orbitdetermination and synchronisation performance assessments will be done, with sensitivityanalyses, in order to derive a justified definition of almanacs, ephemeris and correctionsto be broadcast to the users.

As technical issues the following one may require to be considered when upgrading the toolsin a preliminary phase:

� Operation and maintenance strategy. One of the major contributions to the system costof a constellation is the choice of the maintenance strategy and the selected operationscenario. Therefore effort will be directed at an early stage to the trade-off betweendeployment, operation and maintenance strategies.

8.2 Proposed strategy

The proposed strategy is based in the use of tools developed in the frame of EGNOS or otherprevious Galileo related studies. Basically:

� Comparative System Study (CSS)

� EURONAV

� European Navigation Satellite System (ENSS)

� Navigation Flight Experiment (NAFEX)

Those tools will be analysed to investigate if they can be used for the trade-offs to beperformed, in case they could not be used, then the necessary upgrades will have to bedefined, or even in some cases some tools will have to be developed.

When selecting the tools the team responsible to perform the different trade-offs will beconsidered; in the case that different tools may be considered one important criterion will bethe level of familiarity between the responsible team and the tool. For tools belonging to thesame company, several factors are important in choosing which tool to upgrade, including thefollowing:

� Algorithm efficiency

� Complexity

� Flexibility and modularity

� SW standards used during the development

� Verification and validation status

Most of the trade-offs requiring tools updates are being performed by the partners involved inWP 7.6. This was in fact the rational for the selection of the partners involved in WP 7.6. Dueto the fact that the updates will be performed for urgent needs, it may not be possible toupdate tools from non WP 7.6 partners.

It should be considered that small changes to existing tools are not implying any changesregarding the property rights of the tools. The property rights remains as they were before thechanges.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


8.3 Performed updates

This section describes the updates performed till now, all those updates are described to someextend in the relevant low level documentation, here only a list is provided:

� ELCANO Constellation Performance Module: Upgrade to improve the algorithm thatcalculates performances at a daily availability level

� ELCANO module, upgrade to use EGNOS like systems

� ELCANO module, upgrade to use EUROFIX like systems

� ELCANO module, upgrade to simulate different user scenarios

� GSVS-p upgrade to include hybridisation:

� General positioning error model

� Modifications for clock and baroaltimeter aiding

� Modifications for pseudolite aiding

� GSVS-p upgrade for RAIM algorithm improvement

� GSVS-p upgrade for user masking angle

� ELCANO module modifications to produce standard orbit files

� Development of an orbit comparison utility

� Upgrades to NavMess to test GPS almanac accuracy

� Upgrades to NavMess to fit a GPS almanac or ephemeris message to a realistic orbit, thefollowing options have been implemented:

� GPS

� GLONASS

� SPOT

� Polynomial approach

� GPS with harmonic correction to LAN

� GPS with inertial to earth fixed rotation parameters

� GPS with harmonic correction to LAN and inertial to earth fixed frame rotationparameters

� Upgrades to NavMess to fit an orbit arc by means of Lagrange interpolation

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


9 Development Plan of the GSS

The development plan proposed for the Galileo Support Segment (GSS) is based on theDesign and Development plan from WP 9.1 (GALA-ALS-DD067). Figure 9-1 shows theoverall development plan for the GSS.

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4DESIGN SUPPORT TOOLS

V1V2

DEMONSTRATION TOOLSVALIDATIONSAFETY

2001 2002 2003 2004

Figure 9-1: GSS Development PlanThe V1 phase of the Design Support Tools includes the prototypes of the GDST tools (GSVS-P, GMAS-P and GCF-P).

So, assuming that the support activities start in the beginning of 2001, these tools will beavailable at the end of 2003 year.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


10 Cost Estimates of the GSS

Figure 10-1 shows the corresponding cost estimates for the different GSS tools (classified indesign, demonstration validation and safety support).

Tool Cost (keuro) Nature % to add

Design Support Tools 7,535 202 EST 0%Simulation Tools 1,400 30 EST 0%Test Beds 25,500 1,500 EST 0%Promotion Tools (2) 340 0 EST 0%Validation Tools 8,000 240 EST 0%Safety Tools 23 0 EST 0%

Total 42,798

(1) No information on maintenance available on some tools (3% of the cost assumed)(2) 10 promotion tools assumed

Maintenance per year (1)

1,972

Figure 10-1: GSS Overall Cost Estimates

So, the overall cost of the GSS will be of about 50 MEUROS. To see particular assumptionson these estimations, see the corresponding deliverable document.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


11 Conclusions

The Galileo Support Segment (GSS) is aimed at providing support to:

� System Design

� System and applications demonstrations

� Validation

� Safety

Due to the fact that major commonalties exist between those activities, an overall architectureof the GSS has been proposed, trying to avoid duplication of work and optimising thedevelopment effort.

This optimisation of work also includes the reuse, when feasible, as much as possible of theEGNOS tools and facilities, which also has the benefit of allowing an easy integration ofEGNOS into Galileo (or its co-operation), according to INTEG results.

So requirements for each of the four areas mentioned before have been proposed, taking intoaccount the needs of the corresponding area. Specific tools has been defined and proposed insome cases. In others, it has been proven that it is possible to fulfil the requirements by meansof existing tools/facilities or COTS.

All this analysis is accompanied by a development plan for each tool, as well cost estimations.

GALA REF :

DATE :

GALA-GMV-DD051

10/11/2000


END OF DOCUMENT

document production - european gnss agency ref : date : gala-gmv-dd051 ... • do not delete the...

Documents