GALA REF : GALA-GMV-DD051

Transcription

1 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: a DOCUMENT PRODUCTION You 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 fill in. 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 the template. 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 Architecture Definition) Doc Status (- / Reviewed / Approved) Doc Type (A / R / I) Doc Verified By (Name) Doc WBS Code (WBS Code) To do so follow following instructions:

2 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: b Double-click on the following button Update 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.

3 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: c Hereafter the mandatory fields with a TBD value are listed in RED

4 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: d THIS PAGE IS INTENTIONALLY LEFT BLANK

5 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: A DOCUMENT DISTRIBUTION From To : : Á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 Internal Distribution Service Name N Ex. Service Name N Ex. External Distribution Company Name N Ex. Company Name N Ex.

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

7 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 1 Sustainable Mobility and Intermodality Promoting Competitive and Sustainable Growth Galileo Overall Architecture Definition Support Segment Definition. Synthesis of LLD Written by Responsibility - Company Date Signature Ángel J. Gavín Alarcón GMV Miguel M. Romay Merino All other WP 7 partners Verified by Miguel M. Romay Merino GMV Approved Miguel M. Romay Merino GMV Documentation Manager

8 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 2 WBS Code : WP 7 Emitting entity : GMV

9 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 3 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

10 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 4 TABLE OF CONTENTS 1 INTRODUCTION REFERENCES DEFINITIONS ACRONYMS APPLICABLE DOCUMENTS REFERENCE DOCUMENTS SUPPORT SEGMENT OVERALL DEFINITION AND ANALYSIS SUPPORT SEGMENT. MISSION AND OBJECTIVES The Role and the Scope of the Support Segment in Galileo SUPPORT SEGMENT OVERALL DEFINITION SUPPORT SEGMENT SIMULATION TOOLS DEVELOPMENT AND CERTIFICATION ISSUES REUSE OF EXISTING SIMULATION TOOLS SUMMARY AND CONCLUSIONS DESIGN SUPPORT TOOLS SPECIFICATION DESIGN SUPPORT TOOLS DEFINITION Galileo Mission Analysis Simulator (GMAS) Galileo Service Volume Simulator (GSVS) Galileo Signal Validation facility (GASIVA) Galileo End To End Simulator (GETES) Galileo Network Modelling simulator (GANEMO) Galileo Co-ordination Facility (GCF) DEMONSTRATION TOOLS SPECIFICATION OVERALL DEFINITION OF THE GSS DEMONSTRATION TOOLS SUMMARY OF THE WP ACTIVITIES Description of demonstrations Functional description of demonstration tools: Analysis of existing tools Demonstration tools requirements Definition of tools...30

11 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: Updates to simulation tools Test Beds Promotion tools VALIDATION TOOLS SPECIFICATIONS GALILEO VALIDATION CONCEPT SUMMARY OF ACTIVITIES SAFETY TOOLS SPECIFICATION INTRODUCTION TO SAFETY ISSUES Definition phase Design and development phase In Orbit Validation Phase System Deployment phase System replenishment phase SAFETY TOOLS REQUIREMENTS SAFETY TOOLS ANALYSIS EXISTING TOOLS UPDATES IDENTIFICATION OF TASKS REQUIRING TOOLS UPDATE PROPOSED STRATEGY PERFORMED UPDATES DEVELOPMENT PLAN OF THE GSS COST ESTIMATES OF THE GSS CONCLUSIONS... 45

12 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 6 LIST OF FIGURES Figure 3-1: Overall Architecture of the GSS Figure 3-2 High level architecture for the GSSS-P Figure 3-3 High level architecture for the GSSS Figure 4-1: GMAS architecture Figure 4-2: Snapshot of the EGNOS Service Volume Simulator (ESVS) Figure 4-3: Functional diagram of GASIVA Figure 4-4: High-level functions of the GETES Figure 4-5: GCF Interfaces...26 Figure 5-1: Demonstration Tools Architecture Figure 5-2: Graphical Output of ELCANO Urban Environments Module Figure 5-3: Different points of view of the same street Figure 5-4: More examples of graphical outputs obtained with the Urban Environments module of ELCANO Figure 5-5: GSTB Overall Architecture Figure 5-6: Two snapshots of video animations showing the deployment phase and the final constellation of Galileo Figure 6-1: System Life Cycle Figure 9-1: GSS Development Plan Figure 10-1: GSS Overall Cost Estimates LIST OF TABLES Table 4-1: Design Support Tools Definition... 20

13 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 7 1 INTRODUCTION This document provides a summary of all documents produced in the frame of the GALA WP 7 Support Segment Definition, contributions from the following lower level work-packages are included: G WP 7.1 Support Segment Overall Definition and Analysis G WP 7.2 Design Support Tools Specifications G WP 7.3 Demonstration Tools Specifications G WP 7.4 Validation Tools Specifications G WP 7.5 Safety Tools Specifications G 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.2 Design Support Space Engineering Tools Specification WP 7.3 Demonstration Tools Specification

14 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 8 WP 7.4 Validation Tools Specification WP 7.5 WP 7.6 Existing Tools Update in tecs sistemi Safety Tools Specification

15 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 9 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 the Galileo Support Segment. 2.2 Acronyms ADAS ASQF COTS DOP EETES EGNOS ESTB ESVS FMEA FMECA FTA GCF GDST GETES GIS GLONASS GMAS GNSS GPS GRS GSS GSSS GSTB GSVS Advanced Driver Assistance System Application Specific Qualification Facility Commercial Off The Shelf Dilution of Precision EGNOS End-To-End Simulator European Geostationary Navigation Overlay Service EGNOS System Test Bed EGNOS Service Volume Simulator Failure Modes Effects Criticality Analysis Failure Modes Effects Analysis Fault Tree Analysis Galileo Co-ordination Facility Galileo Design Support Tools Galileo End-To-End Simulator Geographic Information Service GLObal NAvigation Satellite System Galileo Mission Analysis Simulator Global Navigation Satellite System Global Positioning System Galileo RAMS Simulator Galileo Support Segment Galileo Support Segment Simulator Galileo System Test Bed Galileo Service Volume Simulator

16 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 10 IOV LAN MEO MMI PHA RAIM RAMS RBD SIS UERE In-Orbit Validation Local Area Network Medium Earth Orbit Man Machine Interface Preliminary Hazard Analysis Receiver Autonomous Integrity Monitoring Reliability, Availability, Maintainability and Safety Reliability Block Diagram Signal In Space User Equivalent Ranging Error 2.3 Applicable documents [A.1.] [A.2.] [A.3.] [A.4.] [A.5.] [A.6.] D7.1 Support Segment Overall Definition and Analysis D7.2 Design Support Tools Specifications D7.3 Demonstration Tools Specifications D7.4 Validation Tools Specifications D7.5 Safety Tools Specifications D7.6 Existing tools updates 2.4 Reference documents [R.1.] [R.2.] [R.3.] [R.4.] [R.5.] D2.1 Overall Requirements D3.3 Support Segment D6 Overall System Safety Analysis D8.2 Future Projects D13 Security

17 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 11 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 the Galileo Support Segment to support the system definition and design phases of Galileo. The major objective of the Galileo Support Segment is to validate, by means of computer simulations or by using real HW, the high level as well as the low level specifications. In addition it is also to allow for specific design optimisations and to analyse critical design issues. The Galileo Support Segment will contain the Galileo system models and database as well as an ensemble of software tools required to support the Galileo design through simulation. In addition to that some HW modules will be required mainly for demonstration and validation of the system performances. Moreover, since the Galileo Support Segment will need to be adapted to the unavoidable Galileo design evolving nature, it will have a scalable and flexible architecture, both from the hardware and software point of view. This flexibility allows an easy incorporation of updates and replacement of tools and models. Galileo Support Segment definition will take into account the existing initiatives in support of the development of tools that could be either included or optimised to become part of the Galileo Support Segment. In addition and according to the EC resolution, specific attention will be devoted to analyse the 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 the operational validation for different applications (as the ASQF) are understood to be the most promising ones as they are basically concentrated in the application part and hence are to some extent Navigation System independent The Role and the Scope of the Support Segment in Galileo The Support Segment for Galileo is intended to provide a set of facilities supporting the overall development process of Galileo until the system is fully operational. Tools will be later reused for supporting the maintenance and future upgrades of the system. Those development activities include: G 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

18 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 12 G Demonstration, including System demonstration tools (System Test Bed) Applications demonstrations tools (Applications Test Bed) Promotion Tools G Validation including tools for both technical and operational validation of Signal Space Segment Mission Segment Ground Segment Overall Performance G 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 in principle of very different nature, the potential commonalties among the sort of tools needed recommend 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 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 the system which major commonalties with other existing satellite systems, the reuse of existing facilities and infrastructure could be more efficient. As an example, specific tools required for 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 Many of the tools belonging to the Support Facilities are identified as simulators as simulation is a major need for the design of space systems and specially relevant in the development of navigation systems. In this context, simulation offers an incomparable means to support all the design and design validation along the overall Galileo development lifecycle. The situation in Galileo concerning simulation tools is even more demanding than in EGNOS as design of the latter has been also supported by the availability of different prototypes that processed real Signal-In-Space coming from GPS and GLONASS and even EURIDIS. Note that the word simulation is used in a broad sense covering any sort of tool that allows modelling any behaviour of the system and its environment. While the Galileo Support Segment is intended to provide a broad simulation capability for many relevant aspects of the Galileo design, it is to be emphasised that it is not intended to cover all potential simulation needs. 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

19 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 13 satellite as far as platform design (e.g. thermal and power control) are not intended to become part of the Galileo Support Segment. Thus, the major activities to be supported by Galileo Support Segment cover: G Requirements Analysis and Apportionment G Performance analysis and performance budget support in particular, assessment of the navigation performance (in terms of accuracy, integrity, continuity and availability at user level) provided by different potential designs/architectures G Support for system design and parameters selection and optimisation in particular for performing different design trade-offs and analysis of critical design issues. In particular: G Support the validation of design by demonstrating its compliance to the different requirements and also allowing providing confidence on the system behaviour. G Support for subsystem design and, in particular, design of different ground segment, satellite and user algorithms related as far as navigation performance is concerned. G Support to definition of operations in particular those related to flight dynamics. G Support to definition of performance validation procedures G Support demonstration activities. In addition, the Galileo Support Segment shall be designed to be easily upgradeable, to cope with 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 activities that are being defined in the frame of the GALA project. Many activities (both of GALA and future Galileo development phases) require specific tools to perform analysis, validation, demonstration, certification, etc. When those tools are relevant enough and their common development and/or independent development becomes a relevant issue they will be part of the Galileo Support Segment. Taking into account the areas of development of the GSS mentioned above, the major tools composing the Galileo Support Segment can be classified as: G Design Tools G Demonstration Facilities/Tools G Validation Facilities/Tools G Safety Tools It is worthy mentioning the fact that there are several commonalties between these tasks. For instance, performance analysis must be done both in design and validation. And safety analysis 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 safety evidence. So, in order to avoid duplication of work, we must define an overall concept for the Support Segment of Galileo. So, the Galileo Support Segment will be constituted by: G Specific tools for each of the four identified tasks. For instance, a prototype Test Bed may be needed to support the early Galileo concept definition and to demonstrate its potential performance. Also, specific tools (e.g. mobile platforms equipped with

20 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 14 appropriate Galileo receivers) may also be needed to support the validation of user performance. G SW models and simulation tools common to all four activities. Simulation is a major need for the design of space systems and specially relevant in the development and validation of navigation systems since they are characterised by: The situation is depicted in Figure 3-1. GSS Specific Design Tools Specific Demonstration Tools and Facilities Specific Validation Tools and Facilities Specific Safety Tools and Facilities DESIGN DEMONSTRATION VALIDATION SAFETY GSSS COMMON SW MODELS AND SIMULATION TOOLS Figure 3-1: Overall Architecture of the GSS One of the major objectives of the Overall Definition of the Galileo Support Segment is the definition of tools that are common to all the different elements of the Support Segment, as listed above. It is believed at this stage that the major commonalties will be found around the simulation tools. Therefore a clear definition of this simulations tools has been performed to avoid duplication 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 (Design Support Tools) and WP 7.5 (Safety Tools), the rest of the WPs will analyse the possible reuse of the proposed simulation concept and will introduce new requirements to the Galileo Support Segment Simulator. This will assure appropriate interfaces and will avoid duplication of work. 3.3 Support Segment Simulation Tools The role of simulation tools in the Galileo Support Segment will be very high provided that not only Galileo design requirements are considered when defining the simulator. The preliminary identified Galileo Support Segment requirements cover a very broad definition of capabilities covering different aspects and viewpoints of the Galileo system behaviour. While a highly sophisticated simulator of the Galileo system could theoretically cover all simulation capabilities in a single tool, cost, time response requirements and efficiency

21 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 15 recommends to develop various different independent tools that, properly exploited and coordinated, 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 their coherence are a key for a successful Galileo Support Segment Simulation tools development. Based on the EGNOS accumulated experience both as tool developers and operators an appropriate definition of tools has been possible that, according to the experience provides an optimum design. The following tools have been identified: G GSVS (Galileo Service Volume Simulator). Assessment of Galileo long term temporal and spatial navigation performance at user level, in terms of accuracy, continuity and availability (and other related parameters) provided by different potential design/architectures, allowing to perform trade-off studies between several solutions. G GMAS (Galileo Mission Analysis Simulator). Optimisation of the Galileo constellation considering all major requirements. Different aspects will be covered, like: End of Life disposal Deployment strategy Replacement strategy Operations and Maintenance G GETES (Galileo End to End Simulator). This tool will provide the capabilities to perform detailed assessment of Galileo navigation performances based on detailed models of 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, time synchronisation, etc.) User Algorithms G GRS (Galileo RAMS Simulator). Analysis of the apportionment to the Galileo navigation performance of the different elements and phenomena affecting it, including: Assessment of the contribution of the Ground and Space Segment to the system Integrity, Availability, Continuity and Maintainability Detailed identification, characterisation and study of the effect of failures, system degraded modes and feared events on the navigation performances. G GCF (Galileo Support Segment Co-ordination Facility). The Co-ordination Facility will provide a link between the different modules of the Support Segment, and in particular will contain a database that can be accessed by each of the modules, and a core that will allow (if required) co-ordinated execution of the different modules. The GCF is therefore 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 database that interfaces the Galileo configuration database in order to ensure coherence of the baseline used for simulation.

22 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 16 From the above functional decomposition the high complexity of the Galileo Support Segment can already be observed. Some modules like the GSVS, GMAS and GCF are covering quite general aspects, but some others like the GETES, and the GRS as covering quite specific aspects. An adequate implementation of the GETES and GRS will require a significant level of definition of the Galileo system. This is clearly suggesting a two step development approach: G Phase 1. Prototype development, the prototype shall cover the functionality of the following modules: GSVS GMAS GCF GSSS-P GSVS-P GMAS-P GCF-P Figure 3-2 High level architecture for the GSSS-P G Phase 2. Final version development covering all different modules:

23 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 17 GSSS GSVS GMAS GCF GETES GRS Figure 3-3 High level architecture for the GSSS The preliminary proposed overall development approach is based on the stepwise approach proposed for the implementation where two major activities (lifecycles) are performed, one for the engineering (as the basis for detailed definition of the URDs for Galileo Support Segment Simulator) and a second one for the SW development. Engineering activities will be performed mainly during the prototyping phase but will be later refined as result of: G Experience gained during the prototyping phase. G Updated context for Galileo Support Segment Simulator development as, for instance, the availability 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 the starting of the segment development process, in order to define an specific and applied software 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 the standard. This handbook shall have insight on the different approaches to be applied to different components (MMI, prototype, validation approved, operational approved); taking into account the evolution from one kind of component to the other (i.e. from prototype to design use, to validation use, to operational use) The handbook shall include as well the set of COTS that are approved for use in the project and their qualification status.

24 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 18 Is of key importance the availability of the final document before the Galileo Support Segment development is launched. The document shall be also used as a key element in the qualification of the validation tools for the certification of the overall system. Another key issue is the independence that the certification authority may impose between the development tools and the validation tools. Should this independence requirement exist from system level certification proceedings, the pertinent feedback to the currently envisaged architectural design (considering common design and validation facilities) is to be made. Potential ways to improve productivity are to define a flexible and re-usable architectural solution; based on COTS, built in certifiable stacks for communication protocols; and the outsourcing of the verification process for components that would require the higher level of qualification. It is recommended that an agent independent to the developer of the Segment will first define the document, and then perform the pertinent liaison process. Finally, it is necessary to remark that requirements on Galileo Support Segment development certification 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 the functionalities required by the Support Segment, therefore they constitute a strong starting point for SW reuse, or for requirements & functionality identification: G ELCANO G ORION G EETES G ESVS G OPTINAV G AVIGA G EGNOS Support Facilities Some of these tools are briefly described in low level WP 7 documents and they provide a good indication about the complexity and functionality of the Galileo Support Segment. Their possible application (reuse) to the Galileo Support Segment development will be analysed in the next subsections. It should be considered that these tools have not all been developed following the same standards and using the same programming languages. This will condition the possible reuse of 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 modules have been developed in Fortran 77. In any case and considering the high technical complexity of the Galileo Support Segment a maximum reuse is necessary, especially for the prototype, in order to achieve the objectives. The major criteria for the reuse will be:

25 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 19 G Programming language G Efficiency of the implemented algorithms G SW Standards used during the development G Verification and validation status G EGNOS functionality G Modularity and flexibility of the code G Property rights G Complexity Reuse of tools like ELCANO, ESVS, and ORION will guarantee the success of the Galileo Support Segment prototype, while the reuse of the EETES and the prototype will guarantee the 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 with GNSS-1. For instance the reuse of the EETES for the GETES will guarantee all end-to-end EGNOS simulation capabilities in the Galileo Support Segment Simulator without additional effort, 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: G Analysing the requirements G Defining the major functionality G Defining the major components G Defining the simulation concept and tools, including a preliminary development approach G Analysing the possible reuse of existing tools A significant effort has been done to clarify those tools which are common to the different elements 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 the system which major commonalties with other existing satellite systems, the reuse of existing facilities and infrastructure could be more efficient. As an example, specific tools required for 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.

26 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 20 4 Design Support Tools Specification The major objective of the Design Support Tools is to support the Galileo system design phase, by means of computer simulations or possibly by using real HW. More specifically, they are aimed at fulfilling the following tasks: G Optimise the system design, allowing Performance analysis Performance margins assessment Analysis of critical design issues System trade-offs Algorithms development and optimisation G Apportionment of performance requirements among the different system components and/or segments G Support for system design and parameters selection and optimisation G 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 easily upgradeable, to cope with some new requirements or design modifications, since Galileo has an unavoidable evolving nature. Furthermore, special attention must be paid in the reuse of EGNOS 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 as the overall definition of the Support Segment, as defined in WP 7.1, tools in Table 4-1 are aimed 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.

27 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: Galileo Mission Analysis Simulator (GMAS) The Galileo Mission Analysis Simulator (GMAS) will allow the design and optimisation of the Galileo space segment with a high degree of realism. This tool will be based on some existing tools already developed to support the design of constellations and in particular for navigation and telecommunication constellations. The major functionality of the GMAS module will be: G Constellation design. This module will allow optimising the Galileo constellation considering all major requirements. This will allow performing trade-offs between constellations and performances (and in particular DOP). Sensitivity analyses with respect to the major constellation parameters can also be performed. The major objective will be to design a constellation fulfilling all requirements with a minimum cost. G Constellation deployment and replacement strategies. An extensive launcher database will be implemented to support the optimum selection of launchers as well as to define the optimum constellation to minimise deployment costs. The replacement strategies will also be optimised according to the major requirements. G Space Debris analysis. When selecting the Galileo constellation the risk of collision with space debris shall be analysed, not only considering the actual situation but also considering the complete Galileo operational life. Some modules will be implemented to assess those risks and to support the definition of the optimum constellation. G Operations and Maintenance. Some tools will be implemented inside the GMAS to define the optimum control strategy for the selected constellation. This again will allow optimising the constellation to minimise the number of manoeuvres required, and thus maximise the operational life of satellites. G End of Life disposal. Some modules will be implemented to assess the most suitable end of life disposal strategy.

28 Number of satellites GALA Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 22 Operator MMI Scenario Definition Tool Constellation File Generation Measurement Grid Interface Environment conditions Archiving filters GMAS MMI MMI Simulation Control Tool Simulation core modules Simulation Definition Debugging Monitoring Simulation Control GMAS DB GCF MMI Results Analysis Tool Map generation Statistical toolbox Chart Generation Archiving filters Vertical accuracy versus number of satellites/number of orbital planes (Without GEO) planes 4 planes 9 5 planes 8 6 planes Accuracy (m) 6 7 Figure 4-1: GMAS architecture Galileo Service Volume Simulator (GSVS) The Galileo Service Volume Simulator (GSVS) is a simulation tool that allows performing the Service Volume Simulations. So, the objective of the GSVS is to analyse in a fast and easy way the space time variations of GALILEO accuracy, availability, integrity and continuity performances for different navigation requirement, degraded modes and operational scenarios. The GSVS is a system engineering tool planned to be used in the frame of: G Evaluation of space-time variations of Navigation Performance : during advanced project, design, validation and operational phases G Support to justification and validation of design G Support to performance management (requirement allocation, margins management) G Support to system architecture sizing : space segment configuration and maintenance strategy, ground stations network configuration. G Support to Safety assessment : contribution to integrity and continuity of service assessments G GALILEO promotion and performance demonstration: accuracy, availability and coverage maps and animations, in particular for demonstrations outside Europe. G Support to mission planning functions design (elaboration and evaluation of integrity MEO up-link planning algorithm, operational mission prototyping and demonstration)

29 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 23 Figure 4-2: Snapshot of the EGNOS Service Volume Simulator (ESVS) Galileo Signal Validation facility (GASIVA) The general purpose of this tool is to study the Galileo signals, mainly the navigation downlink 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 user terminal, taking into account everything that affects the signal in its path between the satellite and the user receiver, and to analyse the impact of the different options on the quality of the received 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 be performed at a Control and Processing Unit. This tool will be a laboratory test bed, and will work as a standalone tool, without need of any other hardware. Nevertheless it needs an interface with GCF (see before), to export output files, 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 user receiver. These signals may come from an external GPS constellation simulator, GEO satellites GNSS signals. The generated signal can be also input to other instruments, so that other measurements or tests can be performed.

30 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 24 Additional Signals Additional HW Signal Generator Signal Receiver SIMULATOR COMMAND & CONTROL CPU DB COMMAND & CONTROL PROCESSING MODULE MMI GCF EXPORT & IMPORT MODULE Figure 4-3: Functional diagram of GASIVA Galileo End To End Simulator (GETES) The GETES will be a highly sophisticated non real time tool that will feature faithfully the main Galileo system functions as far as affecting navigation performance. The GETES will simulate, with a high degree of realism, the navigation performances for a complete variety of users under different operating conditions and different modes (including degraded modes) by including detailed simulation models of all major elements of the system and 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 system level performance and with the capability to analyse the effect of different design solutions and parameters in the overall system performance. Detailed investigations of the effect of failures as the basis for supporting integrity and continuity 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 involving sophisticated 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 will support the development of ground segment and user receiver algorithms for a variety of scenarios. So it will simulate the whole system (as far as navigation is concerned) and its environment allowing testing those algorithms by inserting them in the simulator (a suitable mechanism is provided).

31 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 25 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 the scenarios definition module). The boxes coloured in grey are those replaceable, allowing the corresponding algorithms to be developed. The GETES will include high-sophisticated models in order to produce simulations as realistically as possible. Notice that the GETES will be able to handle with real measurements gathered, for instance, by the Galileo System Test Bed (GSTB). See section Galileo Network Modelling simulator (GANEMO) The complexity of the Galileo network calls for a complete modelling of the network/satellites ensemble, to be achieved by the use of a suitable simulation tool, in order to verify the achievement of the service requirements. In order to accomplish this task the Galileo Network Modelling simulator (GANEMO) is proposed. GANEMO will be capable of analyse, simulate and gather results of the data flow over the whole Galileo Network, including MEO and GEO satellites, ground stations, processing and control centres. GANEMO will allow: G The detailed analysis of the latency times budget. G 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.

32 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: Galileo Co-ordination Facility (GCF) The main purpose of the GCF (Galileo Core Facility) is to provide an environment in which the GDST (Galileo Design Support Tools) components and largely the GSSS (Galileo Support Segment Simulator) tools can co-operate in order to: G Support the system definition and the design phases of Galileo, including system tradeoff, performance analysis, algorithms development and optimisation G Validate the Galileo specifications GCF shall provide the following basic functionality: G Principally: A database for managing the system configuration data and the interface files between the different tools, and for ensuring the configuration control of simulations Related archive facilities, to store all simulation parameters collected as well as data generated during a simulation run Command and control for all the components (tools and objects) embedded in the GDST system G And also Support the documentation of the simulation results in order to reduce as much as possible the human workload when generating detailed analysis of results, synthesis and conclusions Prepare, execute and evaluate a simulation session involving all or part of the GDST components Man-machine interface capability, implementing a user friendly graphical interface by means of which the operator of the GCF can have full control of all the above functionality Provide the GDST components with common basic functions, such as orbit simulation, mathematical functions, graphical functions GMAS Constellation parameters Nav. mes sage specifications GSVS Station locations Uplink files GE TE S E rror budget S imulated data Safety Tools Demo Tools Failure & state probabilities User environment GASIVA S ignal definition GANE MO Network & Hw architecture Transmission delays GS TB Real data Validation Tools Figure 4-5: GCF Interfaces

33 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 27 5 Demonstration Tools Specification Demonstration tools will support the demonstration of the compliance of the different navigation requirements at users/applications level. Notice that by demonstrations we mean both system and applications demonstrations. In order to set a suitable definition of the GSS Demonstration Tools, the following topics have been considered G First of all, the capable areas of demonstration have been identified and described. This leads to a set of capabilities that demonstration tools must include. G 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 G Finally, the experience of EGNOS (which is also pointed out in WP 7.1) has been also considered fundamental. It is expected to reuse as much as possible EGNOS tools and facilities Having these issues in mind, we have defined an architecture for demonstration tools, which is presented in the next section. 5.1 Overall definition of the GSS Demonstration Tools The demonstration tools will basically be constituted by: G Simulation tools. These tools will be playing an important role during the early Galileo development phases, as no real SIS will be available. To minimise the effort most of the simulation tools used for demonstration will have a high commonality with those used for design, validation or safety. Therefore only those new requirements imposed by demonstration needs will be here discussed. Actually, this tools will be necessary updates to 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 G Test Beds. Including a system test bed (GSTB) and test beds for specific purposes. Test Beds will play a major role when real Galileo components become available. The Galileo Test Bed will have to be defined here by providing specifications. It is important to take into account that the EGNOS Test Bed is already in use, and some practical experience will be collected in order to define better the Galileo Test Bed. The possible use of the EGNOS Test Bed during the early Galileo development phases. G Promotion Tools. These tools are considered as auxiliary tools that will allow presenting the results obtained when using the simulation tools or the Test Bed in a clear and comprehensive manner. Mainly by means of computer animations showing the performances achieved for the different applications. The architecture of the GSS Demonstration Tools is depicted in Figure 5-1

34 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 28 GSSS SIMULATION TOOLS TEST BEDS OTHER GSS TOOLS & FACILITIES PROMOTION TOOLS DEMONSTRATION TOOLS Figure 5-1: Demonstration Tools Architecture The figure shows also some interfaces related with demonstration tools. So, both Test Beds and Simulation Tools 1 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 to Simulation Tools. Regarding with external interfaces, Test Beds can also provide real data to GSSS such as the GETES (Galileo End-To-End Simulator). On the other hand, simulation tools are related with GSSS tools by its own definition (for instance, a urban canyon simulator can 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 Description of demonstrations Using inputs coming from mass market analysis (GALA WP 1) and pilot projects (WP 8), the following application areas have been considered of interest as far as application demonstrations are concerned: G Train Control G Advanced Driver Assistance Systems G Electronic Tolling 1 More exactly, Updates to Simulation Tools. For shortness, we will use simply Simulation Tools in this document (if no confusion).

35 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 29 G Time and Frequency (time transfer and calibration; synchronisation of communication networks ) G Land Survey and GIS mapping G Oil and gas off-shore positioning and hydrographic survey G Controlled Access (which would address the data broadcast function of Galileo) G Urban canyons G Signal Robustness (to hostile environments) Functional description of demonstration tools: In order to fulfil demonstration requirements, demonstration tools need also the following capabilities (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 well as the level of protection against poor environment conditions (loss of satellite visibility, RF interference ). b) Local augmentations systems: Local augmentation can be introduced in demonstrations for 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 a sub-meter accuracy (at 95%) c) Failure events generation: The purpose of this tool is to support the demonstration of integrity service provision. Integrity performance cannot be the subject of convenient demonstrations, since it is essentially described with a very low probability level of hazardous misleading information. d) Urban canyon availability: The urban canyon is a common environment for many satellite navigation applications, either car or pedestrian navigation. Considering the expected number of Galileo terminal units, the urban canyon may well be a common situation for most of the users. The poor satellite visibility conditions generate a lack of availability, and the need for additional sensors or systems. e) Generation of RF and multipath: The purpose these tools is to generate some perturbations to a Galileo SIS receiver, in order to show its ability to cope with them, presumably better than what GPS/EGNOS receivers do Analysis of existing tools a) 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 System Test Bed (GSTB) proposal It is expected its inclusion in the GSTB itself (or an appropriate update, named ESTB+) for the regional integrity provision within Europe.

36 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 30 b) User/applications environment simulation tools: The simulation of physical environments like urban or space environments for demonstration purposes is becoming nowadays spreadly used. Very modern tools allow the fast development of 3D applications with 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. Several commercial environment 3D simulation tools are analyzed, providing relevant information about their main functionalities and to develop a comparison basis using several metrics Demonstration tools requirements Requirements for demonstration tools have been established. These requirements have been split in each of the demonstration areas, namely, simulation tools, test beds and promotion tools Definition of tools Updates to simulation tools The updates to simulation tools are presented by means of a prototype. Starting from ELCANO (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 been developed. This module allows: G Considering different constellation: Every satellite is defined by its Keplerian parameters, relative failure probability and the UERE budget model that will be used to calculate the positioning accuracies. G Considering different UERE budgets: Contains information about different UERE budget models as function of the elevation angle. G Modelling the street characteristics at will of the user (latitude, longitude and azimuth orientation of the street, together with the size and relative location of the different layers of obstacles, typically buildings). G Choosing different simulation parameters, such as vehicle velocity, the time interval in which the constellation is propagated, use of augmentation systems, the availability level at which performances will be calculated, etc. G Computing navigation performances over the user trajectory along the street for the given availability level. It contains the longitude and latitude variation (in degrees) of the user location along the road within the fixed time step and the given velocity. It also provides performance values for each step (horizontal accuracy, vertical accuracy, etc). A graphical tool allows an easy and comprehensive interpretation of the results. A snapshot of one of such graphical outputs is shown in Figure 5-2, which shows the number of satellites in view for a typical European street. On the left of the picture we can see the street from both sides (buildings and obstacles are represented as green rectangles), as well as the number of satellites in view along the street according to the coloured scale shown on the right. A threedimensional representation of the street and the performances is also provided.

37 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 31 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 has been used.

38 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 32 Figure 5-4: More examples of graphical outputs obtained with the Urban Environments module of ELCANO. The development of this module has allowed us estimating: G The complexity of this kind of tools G The development time and effort needed G The cost Test Beds By Test Beds we mean both a system test bed and test beds for specific purposes. The major effort has been devoted to the first one, due to its relevance, complexity and the lack of a complete identification of such specific test beds, whom necessity will arise during the design and 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 users under 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 and limitations 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 other GNSS systems To support the In Orbit Validation (IOV) phase Demonstration to users with real applications of the operational system

39 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 33 According to these objectives, an architecture for the GSTB has been proposed. The key drivers used in such proposal have been G GSS demonstration tools objectives and requirements G Galileo baseline architecture G Experience from the EGNOS Test Bed (ESTB) and the reusability of this tool G Modularity G Flexibility GLOBAL COMPONENT REGIONAL COMPONENT USER COMPONENT DATA ANALYSIS COMPONENT Figure 5-5: GSTB Overall Architecture The overall architecture is depicted in Figure 5-5. The GSTB will be constituted of: G A global component: including all stations, networks and processing facilities needed for the global mission of Galileo (orbit determination, time synchronisation ) G A regional component: in charge of providing regional integrity information within Europe, compliant with INTEG conclusions. It is expected that the ESTB will be used for this component G A user component, essentially a user receiver allowing its inclusion in different platforms making use of suitable interfaces G 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 as possible the Galileo actual system, providing and using a real SIS. However, the system has some 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.

40 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 34 More details can be found in the document and, in particular, a more detailed architecture of the system Promotion tools Promotion 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 has been developed starting from prototypes in order to estimate the final cost of these tools. Two snapshots are shown in Figure 5-6. Figure 5-6: Two snapshots of video animations showing the deployment phase and the final constellation of Galileo

41 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: 35 6 Validation Tools Specifications The objective of the Validation Tool Specifications is to identify the tools that must be considered to prove that system is in accordance with the Galileo requirements. The final aim of the work is to prove that Galileo accomplishes high levels of Safety and Security for the User. 6.1 Galileo Validation concept Figure 6-1 shows the Galileo life cycle by means of a V -diagram that provides a graphical overview of the process that leads to an operational use of Galileo. There is a distinction between the technical and the operational validation: G Technical Validation - Validation of factors (i.e. requirements) not directly concerned with the provision of a service (e.g. survival in a space environment) but necessary to support the mission. Such factors should be susceptible to a large degree of validation without consideration of the intended use. If well understood, such factors may also be sufficiently validated by more abstract means and not require more concrete testing. In general it may be expected that technical validation will not require open ended scenarios but can be assessed within repeatable, well defined conditions. G Operational Validation - Validation of factors (i.e. requirements) that are directly concerned with the provision of a service or where the intended uses are significant. Such factors are likely to involve complexities that are not susceptible to analytical understanding and that may require more concrete testing. In general it may be expected that operational validation will involve interactions and dynamic, adaptive conditions. According to this the cost assessment for validation tools is divided into technical and operational validation.

42 Support Segment Definition. Synthesis of LLD ISSUE : 2A PAGE: Summary of activities Figure 6-1: System Life Cycle This WP is devoted to the analysis and specification of tools needed to support the validation process of Galileo. The major aspects that have been addressed are: G Identification of elements (in a wide sense) to be validated (with inputs from DD037) G Identification of requirements for validation tools G Analysis of tools for validation (both technical and operational) G Development planning and cost estimates