alive services assessment...

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 2

Tous droits réservés © Alcatel Alenia Space All rights reserved

Change Record

Issue Revision Date Change Status Origin

1 A 31/01/06 First issue of the document taking into account AAS comments from internal

review held 27/01/06

1 B 27/03/06 Incorporation of ESA RID SRR (Ankit Raj Mathur 14/02/06)

Changes in §4.3.3, §2.4.6, §6.2.1, §3.2.1, §4.3.14, §4.3.2

V2.2 SRR

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 3


Table of Contents

1. INTRODUCTION............................................................................................................. 7 1.1. CONTRIBUTIONS .................................................................................................................9 1.2. REFERENCES .....................................................................................................................10

1.2.1. Applicable Documents...............................................................................................10 1.2.2. Reference Documents................................................................................................11 1.2.3. Acronyms and Abbreviations .....................................................................................13 1.2.4. Definitions ................................................................................................................14

1.3. DOCUMENT OUTLINE.........................................................................................................14 1.3.1. Document Tree .........................................................................................................14 1.3.2. Document Content Presentation.................................................................................15

2. ALIVE SERVICE PRESENTATION ................................................................................... 16 2.1. OVERVIEW........................................................................................................................16 2.2. MAIN QUESTIONS TO BE SOLVED...........................................................................................22 2.3. AVAILABLE BANDWIDTH ANALYSIS ..........................................................................................23

2.3.1. Introduction ..............................................................................................................23 2.3.2. Analyse of the current bandwidth consumption ..........................................................23 2.3.3. ALIVE Message Bandwidth Consumption....................................................................25

2.4. FUNCTIONAL ANALYSIS .......................................................................................................28 2.4.1. Overview..................................................................................................................28 2.4.2. RLSP Interface Manager (1.1) ....................................................................................29 2.4.3. Uplink Message Manager (1.2) .................................................................................29 2.4.4. Service Performance Assessment (1.3) .......................................................................30 2.4.5. Storage Manager (1.4) .............................................................................................30 2.4.6. M&C Manager (1.5)..................................................................................................30 2.4.7. M&C Client (1.6).......................................................................................................31 2.4.8. State Transition Diagram RLM ...................................................................................32

3. ALIVE ARCHITECTURE DEFINITION.............................................................................. 34 3.1. ALIVE SERVICE DEPLOYMENT STRATEGY..................................................................................34

3.1.1. Deployment constraints identification.........................................................................34 3.1.2. Deployment phases identification ..............................................................................34 3.1.3. Description of ALIVE Service configuration steps .........................................................34

3.2. EGNOS SYSTEM ARCHITECTURE FOR ALIVE SERVICE EVOLUTION.................................................36 3.2.1. Overview..................................................................................................................36 3.2.2. Functional to Physical Allocation Mapping .................................................................38 3.2.3. ALIVE Server at MCC.................................................................................................38 3.2.4. ALIVE Service Processing ...........................................................................................40 3.2.5. ALIVE Service Monitoring and Control ........................................................................40 3.2.6. ALIVE Service Archiving .............................................................................................41

4. SYSTEM IMPACT ASSESSMENT OF ALIVE SERVICE EVOLUTION................................... 42 4.1. INTRODUCTION.................................................................................................................42 4.2. FUNCTIONAL IMPACT ASSESSMENT .........................................................................................42

4.2.1. Overall Assessment...................................................................................................42 4.2.2. ALIVE impact on function 8 “provide SIS ranging service and message broadcast” ......43 4.2.3. ALIVE impact on function 9 “provide system communication”......................................44

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 4


4.2.4. ALIVE impact on function 10 “provide system monitoring and control” ........................44 4.3. INTERFACE IMPACT ASSESSMENT ............................................................................................ 44

4.3.1. Identification of impacted EGNOS interfaces .............................................................44 4.3.2. RLSP / ALIVE SERVER External Interface......................................................................46 4.3.3. NLES / GEO external interface ..................................................................................48 4.3.4. GEO / RIMS external interface ..................................................................................49 4.3.5. RIMS / ALIVE SERVER internal interface......................................................................49 4.3.6. RIMS / CPF internal interface ....................................................................................49 4.3.7. ALIVE SERVER / CPF internal interface........................................................................49 4.3.8. CPF / CCF internal interface......................................................................................50 4.3.9. ALIVE SERVER/CCF internal interface .........................................................................51 4.3.10. ALIVE SERVER/M&C internal interface ........................................................................51 4.3.11. NLES / CPF internal interface ....................................................................................52 4.3.12. CCF / Support Facilities ............................................................................................52 4.3.13. M&C Client / Support Facilities..................................................................................53 4.3.14. INSPIRE / RIMS internal interface...............................................................................53

4.4. PERFORMANCES IMPACT ...................................................................................................... 53 4.5. RAM & SAFETY IMPACT ASSESSMENT ..................................................................................... 53

4.5.1. RAMS Assessment Method ........................................................................................53 4.5.2. Qualitative Requirements Analysis .............................................................................55 4.5.3. Quantitative Requirements Analysis ...........................................................................58

4.6. SECURITY IMPACT ASSESSMENT ............................................................................................. 60 4.6.1. Introduction ..............................................................................................................60 4.6.2. Threats Identification & Risk Analysis .........................................................................60 4.6.3. Security Policy Impacts ..............................................................................................62

5. EGNOS S/S IMPACT ASSESSMENT OF ALIVE SERVICE EVOLUTION ............................. 64 5.1. OVERVIEW ....................................................................................................................... 64 5.2. CPF ............................................................................................................................... 65

5.2.1. Introduction ..............................................................................................................65 5.2.2. Current Message Selection Design Description ...........................................................65 5.2.3. Analysis of Bandwidth Requirements..........................................................................67 5.2.4. Impacts to CPF Sets ..................................................................................................68 5.2.5. Key Design Issues .....................................................................................................70 5.2.6. Conclusion ...............................................................................................................71

5.3. CCF .............................................................................................................................. 72 5.4. M&C CLIENT ................................................................................................................... 72 5.5. ALIVE SERVER................................................................................................................... 72 5.6. EWAN ........................................................................................................................... 72 5.7. FEE................................................................................................................................ 74 5.8. ENMA............................................................................................................................ 74 5.9. AIVP .............................................................................................................................. 74 5.10. PACF............................................................................................................................. 74 5.11. ASQF ............................................................................................................................ 75 5.12. DVP/AE (OAT)................................................................................................................ 75 5.13. TUE SW ......................................................................................................................... 75

6. ALIVE SERVICE EVOLUTION IMPLEMENTATION ROADMAP ........................................ 76 6.1. OVERALL DEVELOPMENT LOGIC............................................................................................. 76 6.2. PRELIMINARY SCHEDULE ...................................................................................................... 77

6.2.1. Phase 1: Advanced Operational Capability ...............................................................78 6.2.2. Phase 2: Fully Operational Capability .......................................................................79

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 5


6.3. CONCLUSION...................................................................................................................80 6.3.1. Feasibility study objectives.........................................................................................80 6.3.2. Complementary aspects to be investigated.................................................................80

7. APPENDICES ................................................................................................................ 82 7.1. FMECA SHEETS ................................................................................................................82 7.2. FTA TREES........................................................................................................................86

List Of Figures Figure 1 : ALIVE Service Assessment Study Logic .................................................................................8 Figure 2 : Document Structure .........................................................................................................14 Figure 3 : Broadcast of Information through EGNOS........................................................................18 Figure 4 : EGNOS Geostationary Satellites Coverage .......................................................................19 Figure 5 : Architectural Implementation of SAR Return Link Function ..................................................20 Figure 6 : Architecture concept of Disaster Management Function .....................................................21 Figure 7 : Bandwidth average analysis (SIS 1)...................................................................................24 Figure 8 : Bandwidth margin analysis (SIS 1)....................................................................................25 Figure 9 : Theoretical Bandwidth margin analysis (SoL/Non SoL).......................................................26 Figure 10 : Theoretical Bandwidth margin analysis (Test Mode).........................................................26 Figure 11 : ALIVE Service DataFlow Diagram Level 0........................................................................28 Figure 12 : RLM State Transition Diagram ........................................................................................32 Figure 13 : ALIVE Service Evolution Impact on EGNOS Data Flows....................................................37 Figure 14 : ALIVE Server Multi-MCC Potential Architecture ................................................................39 Figure 15 : RLSP/EGNOS Interaction Diagram .................................................................................46 Figure 16 : MOPS Message Data Block Format ................................................................................49 Figure 17 : Sequence of operation for NOF in CPF-PS MSG..............................................................66 Figure 18 : Typical Message Sequence Status including ALIVE ...........................................................67 Figure 19 : ALIVE (MT15) Simulation Results.....................................................................................68 Figure 20 : ALIVE - CPF Interactions.................................................................................................68 Figure 21 : ALIVE MCC Physical Architecture ....................................................................................73 Figure 22 : ALIVE Service Evolution Overall Development Logic.........................................................76 Figure 23 : ALIVE Service Preliminary Schedule.................................................................................78 Figure 24 : ALIVE Integrity Fault Tree ...............................................................................................86 Figure 25 : ALIVE Continuity Fault Tree ............................................................................................87

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 6


List of Tables

Table 1 : ALIVE Service Allocation of Functions to Physical Equipments .............................................. 38 Table 2 : DataFlow RLSP -> EGNOS ............................................................................................... 47 Table 3 : DataFlow EGNOS -> RLSP ............................................................................................... 48 Table 4 : ALIVE Server/CPF DataFlow .............................................................................................. 50 Table 5 : ALIVE Server/CCF DataFlow ............................................................................................. 51 Table 6 : ALIVE Server/M&C DataFlow ............................................................................................ 52 Table 7 : RAMS FMECA Summary Results......................................................................................... 56 Table 8: ALIVE RAMS Requirements ................................................................................................. 58 Table 9 : ALIVE Service Quantitative Performances Summary ............................................................ 59 Table 10 : Security Risk Analysis ...................................................................................................... 60 Table 11 : Acceptable/Unacceptable Risk Table ............................................................................... 61 Table 12 : ALIVE ESS Impact Checklist ............................................................................................. 64 Table 13 : ALIVE System FMECA...................................................................................................... 85

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 7


1. Introduction

This document is written in the frame of the definition phase activity conducted as part of EGNOS Evolution and Maintenance contract step 1A, also called EGNOS V2 step 1A.

The purpose of the definition phase is to study a set of evolutions to be implemented in the EGNOS system in three main versions, identified as V2.1, V2.2 and V2.3.

One of the evolutions that shall be implemented as part of EGNOS V2.2 is introduction of the ALIVE Service function. ALIVE is the ALert Interface Via EGNOS for Disaster Prevention and Mitigation. It acts as an interface between Disaster Management Centres for users that are in distress. This is motivated by the obvious principle that disaster prevention, mitigation and preparedness are better than mere disaster response.

One objective of the definition phase activity is to define the EGNOS V2.2 architecture and preliminary implementation plan allowing to implement the evolutions allocated to EGNOS V2.2 baseline. With this objective in mind, several feasibility studies have been conducted at EGNOS system and sub-system level, and in particular, related to the ALIVE service evolution.

The purpose of the document is to report on the feasibility status of the ALIVE service evolution. This document will enable the consolidation of applicable system requirements to cover the ALIVE service evolution, and constitutes a first step of the EGNOS V2.2 design justification file.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 8


The ALIVE Service evolution study logic is depicted in the following diagram:

ALIVE Service Needs

ALIVE Technical Architectural, Operational &

Interfaces Impacts

ALIVE Safety & Security Aspects

ALIVE Preliminary

Requirements

Updated TN + Contribution to Development

Plan for Roadmap

ALIVE Service Area

(GBA)

SRR PDR

ALIVE Feasibility TN

ALIVE Service Needs

ALIVE Technical Architectural, Operational &

Interfaces Impacts

ALIVE Safety & Security Aspects

ALIVE Preliminary

Requirements

Updated TN + Contribution to Development

Plan for Roadmap

ALIVE Service Area

(GBA)

SRR PDR

ALIVE Feasibility TN

Figure 1 : ALIVE Service Assessment Study Logic

The study logic has been performed as follows :

1. ALIVE Service Needs : Critical Analysis of the Preliminary System Requirements Document [ALIVE-SRD] and Preliminary Interface Requirements Document [ALIVE-IRD] enables good understanding of what is required of the EGNOS system to effectively provide the ALIVE service.

2. ALIVE Service Area : A brief presentation of the intended ALIVE Service Area will be made, ensuring that it is integrated as part of the System Requirements.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 9


3. Technical, Architectural, Operational Impact Analysis : System level analyses to identify what architectural and operational improvements would need to be incorporated in order to implement the ALIVE Service.

4. Safety & Security Aspects : Given the proposed architecture solution, the safety and security aspects are addressed, thus enabling the specification of the safety and security requirements with minimal impact to the current Software Development Assurance Level for existing EGNOS subsystems.

Major considered assumptions for the study :

During the course of this study, the following main assumptions have been made:

A1 : It is assumed that the EGNOS UP capability will be available for testing of the ALIVE Service (the ESTB will not be used). It should also be noted that the possibility of using SPEED could also be used.1

A2 : In accordance with REQ EEM-S-01110, EGNOS will encapsulate the applications data provided by the Return Link Service Providers (212 bits). It has not been envisaged to split RLSP data over multiple EGNOS messages, or to concatenate smaller applications data messages into a single 212 bit EGNOS SBAS message (one Return Link Message is equivalent to one EGNOS SBAS message).

A3 : Since it is required that the ALIVE is installed at MCC sites (EEM-S-00800), it is assumed that the ALIVE Service will be operated by the current EGNOS operators. This means that the operation of ALIVE should follow the periodic rotation policy implemented for the EGNOS Navigation function via CCF.

1.1. Contributions

Have contributed to the redaction of this document:

Company Name Sections

E. Chambre ALL

C. Lahorgue ALL

F. Deschamps ALL

P. Larhantec ALL

D. Thomas ALL

1 ESA SRR RID

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 10


1.2. References

1.2.1. Applicable Documents

Acronym Title Reference

[ALIVE-PIRD] EGNOS – ALIVE RLSP Preliminary Interface Requirements Document

E-RD-ITF-E-0027-ESA, issue 1, rev 0, 02/11/05

[ALIVE-PSRD] EGNOS ALIVE Preliminary System Requirements Document

E-RD-SYS-E-0028-ESA, issue 1, rev 0, 02/11/05

[AD2] EGNOS V2 Definition Phase Statement Of Work

E-SW-SYS-E-041-ESA issue 1, rev 0, 23/09/2004

[AD3] EGNOS V2 System Definition Phase – Technical Requirements

E-RD-SYS-E-019-ESA, issue 1, rev 0, 23/09/04.

[AD4] EGNOS AOC System Requirements Document

E-RD-SYS-E-001-ESA, issue 3, rev 1, 16/09/99

[IMP_PROP] IMPLEMENTATION PROPOSAL DOCUMENT

EEM-SYST-ASP-PL-4

[MOPS_3B] MINIMUM OPERATIONAL PERFORMANCE STANDARDS FOR GLOBAL POSITIONING SYSTEMIWIDE AREA AUGMENTATION SYSTEM AIRBORNE EQUIPMENT

RTCA/DO-229B, Change 3, May, 1998

[SOC_AD2] Statement of Compliance to Definition Phase – SOW EEM-SYST-ASP-MX-11

SOW-EEM-SYST-ASP-MX-11, issue 1, rev C

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 11


1.2.2. Reference Documents

The following list of documents have been used in preparing this document. Wherever necessary, reference is made to these through the references used in the column “Acronym”.


[CPF_DDF] CPF Subsystem Design Definition / Justification File

EGN-ASP-CPF-DRD208/1, issue 2, rev A.

[CPF_MSG_ALG] CPFPS Message Selection and Generation Algorithm Design Definition File

EGN-GMV-CPFPS-DRD207/6, issue 3, rev F, 06/05/05.

[CPF_PIDS] Prime Item Development Specification for CPF

EGN-ASPI-CPF-DRD202/0002, Issue 5, Rev B, 9/9/00

[DJF] EGNOS System Design Justification File

EGN-ASP-SYST-DRD0106/0001, issue 7, rev A, 21/02/05.

[DAL_PROC] Procedure for Software Development Assurance Level Determination

EGN-ASPI-RAMS-DRD 1150/0001, Issue: 3, rev C

[MOPS_3C] MINIMUM OPERATIONAL PERFORMANCE STANDARDS FOR GLOBAL POSITIONING SYSTEMIWIDE AREA AUGMENTATION SYSTEM AIRBORNE EQUIPMENT

RTCAIDO-229C, November 28, 2001

[PBMF] EGNOS System Performance Budget Management File EGN-ASP-SYST-DRD0107/0001, issue 5, rev C, 29/04/05

[RAMS_INPUT] EGNOS AOC RAMS Input Data EGN-SRTI-RAMS-DRD1126/1, issue 6, rev A, 20/04/05

[RFW-632] Request for Waiver : Use of EWAN provided by service provider as is.

EGN-RFW-E-0632-T4S

[RAMS_REPORT] EGNOS System RAMS Report 10 RAMS Guideline & Executive Summary

EGN-SRTI-RAMS-DRD1112/010, issue 5, rev B, 19/04/05

[TN173] EGNOS Performance Guideline document

EGN-ASPI-SYST-TN/0173, issue 5, rev A, 25/04/05

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 12



[TN390] Assistance to ESA WP91 AFI Expansion

EGN-ASPI-SYST-TN/390, issue 1, Rev A, dated 19/07/04

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 13


1.2.3. Acronyms and Abbreviations

ALIVE ALert Interface Via EGNOS

AOC Advanced Operational Capability

DAL Development Assurance Level

DMC Disaster Management Centre

ECAC European Civil Aviation Conference

EFE External Feared Event

EGNOS European Geostationary Navigation Overlay System

FDIR Failure Detection Isolation & Recovery

FE Feared Event

FMEA Failure Modes Effects Analysis

FOC Fully Operational Capability

GBA Geostationary Broadcast Area

GEO Geostationary

GLONASS The Russian constellation of Global Navigation Satellite System

GNSS Global Navigation Satellite System

GPS Global Positioning System (US)

HMI Hazardous Misleading Information

MMI Man Machine Interfaces

NLES Navigation Land Earth Station

OFE Output Feared Event

RAMS Reliability, Availability, Maintainability, Safety

RIMS Ranging and Integrity Monitoring Station

RLM Return Link Message

RLSP Return Link Service Provider

SBAS Space Based Augmentation System

SAF Safety Assurance File

SIS Signal-In-Space

UDRE User Differential Range Error

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 14


1.2.4. Definitions

The terms used in this document are defined in the "EGNOS Evolutions and Maintenance Glossary of Terms and Definitions" [EEM-SYST-ASP-LI-22].

1.3. Document Outline

1.3.1. Document Tree

The position of this document within EGNOS V2 documentation is depicted in the figure below:

Early Developments

Tech. Req.Batch1 AD5

EGNOS V2.1

Delta SRD

EGNOS V2.1

Delta DJF

EGNOS V2 System Definition

StudyTech. Req. AD3

ALIVE Service

Assessment TN

EGNOS V2.2

Delta SRD

EGNOS V2.2

Delta DJF

V2.2 SRR

V2.2 PDR

Figure 2 : Document Structure

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 15


1.3.2. Document Content Presentation

Section 1 describes the purpose, scope and application field of this document. In addition, it gives useful information for a better understanding of the document such as contractual applicable documents, reference of documents from external sources, specific definitions used or referred to in the document and at least the list of acronyms used. A brief presentation of its content completes this section.

Section 2 presents the ALIVE Service Assessment context and objectives.

Section 3 defines the ALIVE Service mission and the related architecture.

Section 4 introduces the ALIVE Service Performance Parameters : accuracy, availability, continuity and integrity.

Section 5 provides the system impact analysis of the ALIVE Service evolution.

Section 6 identifies the ALIVE service evolution impacts on EGNOS AOC S/S.

Section 7 provides the ALIVE service evolution implementation strategy for the retained implementation solution.

Section 8 lists the appendices which complements this document.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 16


2. ALIVE Service Presentation

2.1. Overview2

In parallel to the start of EGNOS operations, EGNOS is planning a modernization plan to cope with GPS modernization, service extension, standard evolutions and the anticipation of some future Galileo missions. In this context, the availability of free bandwidth enables systems like EGNOS to broadcast additional communication messages. These messages could be, the broadcast of

• Warnings or instructions on the occurrence of natural disasters, calamities, dangers for the safety of life within areas with poor telecommunication infrastructure

• Search and Rescue Return Link Messages.

• Warnings or instructions on limitations in the use of SBAS for specific applications (e.g. aviation)

• Other possible critical communication uses.

We refer to these, in general, as the Communication function of EGNOS - The ESA ALIVE Concept, (ALert Interface Via EGNOS).

Disaster prevention and mitigation is a subject to which currently intensive attention is devoted.

One of the main goals is to identify ways to inform people at risk, for instance, through natural events such as earthquakes, tsunamis, hurricanes, storm surges, extreme precipitation and flooding, or volcanic eruptions, so that specific actions can be taken to mitigate the impact of the disaster and ultimately, to save lives. Moreover, the same information channels would be valuable tools to support rescue and aid operations in the aftermath of disasters thus reducing the total loss of human lives. This discussion is motivated by the obvious principle that disaster prevention, mitigation and preparedness are better than mere disaster response.

Those most affected by disasters are often the poor and the socially disadvantaged in developing countries as they are the least equipped to cope with the situation. In large regions of the Earth, loss of life and capital caused by disasters is increased by the lack of sufficient communication infrastructure for warning, preparation and rescue. For

2 Sourced from [ALIVE-SRD]

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 17


instance, in African countries and the Indian Ocean, where the lack of communication is a severe limitation for efficient warning systems, additional communication paired with a positioning service could be of great help.

The COSPAS-SARSAT Search and Rescue system has helped save many lives during the past several years. This is currently a one way communication system where the distress beacon sends information to the rescue coordination centres. There is no way of communicating the acknowledgements or other rescue related information back to the distress beacon. Having this added functionality will definitely help in improving the efficiency of the Search and Rescue system, resulting in saving a lot more lives. This functionality is currently planned in Galileo (prototype RLSP developed in the frame of the GISAR project).

In both these and other similar contexts, the possibility to use Satellite Based Augmentation Systems (SBAS) message broadcast capability is of considerable interest. Indeed, SBAS systems (EGNOS, for the case of Europe) are associated with a number of inherent characteristics, which make the SBAS solution very attractive:

• The three existing SBAS together provide a global GEO broadcast coverage;

• SBAS receivers are based on GPS receivers and share the same worldwide accepted standards; we may consider that GPS/SBAS is the most popular “satellite communication” (meaning able to receive communication information through satellite) receiver worldwide;

• SBAS GPS receivers can combine the possibility of warning with the ability to determine the location of the receiver in the same equipment (key feature);

• The SBAS systems, having been conceived as safety of life systems with integrity, include the necessary built-in features to guarantee adequate message broadcast, integrity of messages, confirmation of transmission; acknowledge messages to sending organisations, etc;

• It is estimated that there is enough transmission Bandwidth (BW) available to accommodate the proposed function;

SBAS are institutionally controlled, do include security features and are operated for safety of life (i.e. all days all hours of the year with Safety of Life operational standards).

The broadcast of these communication messages is based on the more general concept of using the available EGNOS BW to broadcast spatially related information from an originator to EGNOS users through dedicated SBAS messages. Figure 3 : Broadcast of Information through EGNOS

below indicates the architectural implementation of such a communication function embedded within the EGNOS system.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 18


ESA/EGNOS/10

Architectural Concept

Figure 3 : Broadcast of Information through EGNOS

Independently from the application considered, the information to transfer to EGNOS users is made available to the EGNOS computing platform (CPF) through links and pre-processing stages.

This information is then broadcast as an SBAS message. Users having the possibility to process these specific messages can then extract the enclosed information and use it in the way they need.

The Application clients such as the disaster management centres, search and rescue centres etc. interface with the EGNOS ALIVE Ground segment via their respective Return Link Service Providers.

The added value of this process is the opportunity to provide reliable information to users equipped with an EGNOS terminal within the entire EGNOS geostationary coverage as indicated in Figure 4 : EGNOS Geostationary Satellites Coverage.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 19


ESA/EGNOS/11

EGNOS Coverage

Figure 4 : EGNOS Geostationary Satellites Coverage

Safety critical information (event, recommended action) is typically associated to spatial information (location). This will be of particular importance for the functions of ALIVE.

SAR Architectural concept

The EGNOS system shall support the SAR service by providing the return link from the SAR ground segment to the distress beacon. The SAR mission of EGNOS shall have an operational interface at ground segment level with the COSPAS – SARSAT system. The SAR MCC shall send the return link messages to the EGNOS MCC via its Return Link Service Provider. EGNOS broadcasts these in the L1 band, along with the other EGNOS messages. The preliminary conceivable architecture for this service is shown in the following Figure.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 20


ESA/EGNOS/13

EGNOS SAR Architecture

Figure 5 : Architectural Implementation of SAR Return Link Function

The SAR return link service shall be compatible with the low – cost EGNOS receivers, integrated in future advanced beacons.

The Return Link Service Provider is an entity responsible for the organising, formatting and delivering to the EGNOS ALIVE ground segment the return link messages. The EGNOS ALIVE ground segment shall encapsulate these return link messages in an EGNOS message and uplink it to its satellites. A dedicated SAR/EGNOS beacon shall be able to receive, display and act upon these Return link Messages.

Disaster Management Architectural concept

National and international organisations in charge of disaster management or for the provision of civil protection services make use of infrastructures for monitoring, communication and control.

Here we denote such infrastructures as Disaster Management Centres. A possible architectural implementation of this concept on the basis of the EGNOS system is illustrated in Figure 6 : Architecture concept of Disaster Management Function.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 21


ESA/EGNOS/14

ALIVE Architectural Concept

Figure 6 : Architecture concept of Disaster Management Function

Disaster Management Centres have the task to collect and generate relevant information (e.g.: event, location, status, action) required to fulfil all the missions for which they have been designed.

The information generated by Disaster Management Centres is sent via its return link service provider to the EGNOS MCC, which converts this information into SBAS format broadcasts these messages to the users via its Geos. The RLSPs receive the acknowledgement that the information has been sent with the typical EGNOS guarantee of service.

The message (or messages) containing the information generated by the Disaster Management Centres, is included in the EGNOS up-link and down-link loop in the same way as other messages.

Any user (within the EGNOS satellites footprint) equipped with an EGNOS receiver capable of processing these additional messages is made aware of the problem, location, status and action.

Again, the EGNOS link loop guarantees the delivery of the information to enabled users.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 22


2.2. Main questions to be solved

The purpose of the ALIVE Service Evolution is to upgrade the current EGNOS system in order to optimise the usage of spare bandwidth via implementation of the function described in the previous section. This feasibility study sets out to investigate the following different aspects:

• At mission level :

Evaluation of preliminary System Requirements, Interface Requirements and current spare bandwidth availability.

• At system architecture level :

Impact on EGNOS system architecture and particularly CPF/CCF/EWAN, taking into account performance constraints

Impact on EGNOS system M&C chain

Consideration of RAM and Safety Aspects including possible degraded modes

ALIVE Service deployment strategy to cope with an incremental implementation approach

• Feasibility assessment at S/S level :

Impact on CPF design

Impact on EWAN design

Impact on CCF design

Impact on PACF/ASQF design

Impact on DVP/OAT design

Impact on TUE design

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 23


2.3. Available Bandwidth Analysis

2.3.1. Introduction

In a first paragraph the current EGNOS bandwidth consumption is recalled. Then the bandwidth consumption that will be needed for the ALIVE service is studied. It should be noted that the system baseline used for this analysis is EGNOS V1 AOC, plus the incorporation of the MT0/2 optimisation. In order to have a consolidated EGNOS V2.2 analysis, all V2.2 evolutions should be considered at overall system level (e.g. bandwidth availability should be consolidated taking ISA/REM and ALIVE evolutions into account). This consolidation will be performed as part of the Design Justification for V2.2 PDR.

2.3.2. Analyse of the current bandwidth consumption3

The current bandwidth margin can be estimated from analyses performed in the frame of the SIS 1 activity (Signal In Space step 1 : collected data on 17 deployed RIMS). The following diagram shows the different Message Types disseminated by EGNOS during that campaign. It can be observed that correction/UDRE data are broadcast by type 2, type 3 and type 24 messages only (no use of type 4 and type 5 messages).

3 Sourced from [TN-390]

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 24


Figure 7 : Bandwidth average analysis (SIS 1)

Since EGNOS is not delivering Safety of Life services at the present time, the message type 0 constitutes a margin towards the system operating in SoL mode. The value of the margin is equal to 16.7 % of the global bandwidth since the maximum update interval for the type 0 message is 6 s (1/6). Note that EGNOS v2.0.2 upgrade has enabled the removal of this bandwidth even for the Non-SoL mode since the MT2 and MT0 messages are merged into a single so-called MT0/2 message (refer to [AD3] for more details).

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 25


Figure 8 : Bandwidth margin analysis (SIS 1)

Figure 8 : Bandwidth margin analysis (SIS 1) above shows that the global average margin on messages is equal to almost 21,9 % on the system.

Taking into account that the MT0 nominal consumption is 16,7%, and that its usage will be optimised with the MT0/2 upgrade, the total approximate currently available free bandwidth, using the SIS1 results, can be estimated at 38,6%.

2.3.3. ALIVE Message Bandwidth Consumption

According to the [ALIVE-PSRD] document, a bandwidth of 800 bits/minute have been allocated to the ALIVE Service. It is assumed that a new message type will be defined for the ALIVE service and the complete data field of that message is allocated for ALIVE encoding (i.e. 212 bits of the 250 bit standard MOPS structure). This corresponds to an average message rate of 1 message every 15 seconds, which is 6.67% of the overall budget. The diagram below provides a theoretical representation of the message rates, which is complementary to the SIS1 data results provided above. Note that a very conservative estimate for MT6 occurrences has been made (0,33%).

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 26


Message Type Max Update Interval

Number of messages transmitted over ECAC

in 300 sec period

% BW over ECAC

MT 0 6 0 0,00%MT 1 120 2,5 0,83%MT 2 or MT 0/2 6 50 16,67%MT 3 6 50 16,67%MT 4 6 0 0,00%MT 5 6 0 0,00%MT 6 6 1 0,33%MT 7 120 2,5 0,83%MT 9 120 2,5 0,83%MT 10 120 2,5 0,83%MT 12 300 1 0,33%MT 17 300 1 0,33%MT 18 300 4 1,33%MT 24 6 50 16,67%MT 25 120 4 1,33%MT 26 300 18 6,00%MT X (ALIVE) 15 20 6,67%

Used 69,67%Spare 30,33%

Figure 9 : Theoretical Bandwidth margin analysis (SoL/Non SoL)

Message Type Max Update Interval

Number of messages transmitted over ECAC

in 300 sec period

% BW over ECAC

MT 0 6 50 16,67%MT 1 120 2,5 0,83%MT 2 or MT 0/2 6 50 16,67%MT 3 6 50 16,67%MT 4 6 0 0,00%MT 5 6 0 0,00%MT 6 6 1 0,33%MT 7 120 2,5 0,83%MT 9 120 2,5 0,83%MT 10 120 2,5 0,83%MT 12 300 1 0,33%MT 17 300 1 0,33%MT 18 300 4 1,33%MT 24 6 50 16,67%MT 25 120 4 1,33%MT 26 300 18 6,00%MT X (ALIVE) 15 20 6,67%

Used 86,33%Spare 13,67%

Figure 10 : Theoretical Bandwidth margin analysis (Test Mode)

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 27


It could therefore be concluded that there is sufficient bandwidth available to accommodate the required bandwidth requested for the ALIVE service, even in Test Mode (MT0 and MT2). This result can only be considered intermediary since it is necessary to consolidate all future V2.2 bandwidth consumption at overall system level. This shall be performed for the design justification at PDR phase.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 28


2.4. Functional Analysis

2.4.1. Overview

The following functional analysis has resulted from the review of the Preliminary SRD and IRD requirements documents [ALIVE-PSRD] and [ALIVE-PIRD]. The results are detailed in the form of a functional breakdown of the ALIVE Service as detailed below. Each function is described further in the following sections.

1.1RLSP

InterfaceManager

RLSP

1.3Service

Performance Assessment

ReturnLinkAckNotif

1.2Uplink Message

Manager

1.4StorageManager

1.5M&C

Manager

CPF

RLMCancelRqst

ReturnLinkCancelNotif

INF_ReportInfoRqst

RIMS

RIMSRawData

INF_RlmNotifMntSysStatus

SysStatus

INF_ReportInfoRqst

ALIVEUplinkMsg

ReturnLinkAckNotif

ALIVE Mission Monitoring

M&CCommand

M&CResponse

RLMCancelled

INF_RlmNotifMnt

ReturnLinkAckNotif

FlowControl

EGNOSSysStatus

FlowCtrlInfo

CPFALIVEUplinkStatus

MsgSchQueDissStatus

CCF

ALIVEArchiveData

AllProcessesArchiving

Data

1.6M&CClient

Figure 11 : ALIVE Service DataFlow Diagram Level 0

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 29


2.4.2. RLSP Interface Manager (1.1)

This process is responsible for performing the following functions:

• Security Management with multiple external RLSPs (e.g. authentication)

• Initialisation of communications with multiple external RLSPs

• Monitoring of communications with external RLSPs (e.g. detection of loss in communication via “Watchdog-style” or “ping” service)

• Message sequence checking (message loss detection) and associated error reporting for each RLSP (or each MCC)

• Message format checking and associated error reporting for messages received from RLSPs

• Verification that the requested broadcast position is compatible with the Service Volume (GBA), and reply accordingly

• Health Status of EGNOS ALIVE function

• Forward received messages to Uplink Message Manager

• Forward received messages to Service Performance Assessment

• Forward received messages to Storage Manager

2.4.3. Uplink Message Manager (1.2)

This process is activated at regular intervals when messages are to be sent to the CPF (every 15 secs, at an agreed offset within the 1 second cycle). It’s most essential function is to control the flow of messages delivered to the CPF (the goal is to limit impacting the CPF to the minimum). It is responsible for performing the following functions:

• Scheduling ALIVE Uplink Messages to be sent by the CPFs, depending on the size of the message queue reported by the CPF. The objective is to avoid overloading the CPF message queue in the event of EGNOS alarm (MT6, MT26) congestion.

• Evaluation of internal and CPF message queue sizes and performing flow control in the event of near or full saturation conditions.

• Ordering of messages to be uplinked based on a First-In-First-Out principle (i.e. all requests are treated with equal priority).

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 30


• Management of message repetitions as required. The number of message repetitions could be different for each user application (e.g. SAR may request 5 repetitions and another user may request no repetitions at all).

• Dequeuing of messages from the internal message queue in the event that a cancellation request has been sent by an RLSP. It should be noted that when the RLMs have been sent to the CPFs, no cancellation is possible.

• Forwards the ALIVE message to the CPF for uplinking.

2.4.4. Service Performance Assessment (1.3)


• Preparation of periodic reports (15 mins) to RLSP concerning ALIVE and EGNOS current status

• Preparation of periodic reports (5 mins) to RLSP concerning uplink RLM Monitoring (RLMs cancelled, RLMs awaiting dissemination, RLMs disseminated and successfully received by RIMS)

• Responding to ad hoc report requests from RLSP. Ad hoc reporting can be useful in the event that reports are lost, or the RLSP needs to resynchronise with EGNOS latest status.

• Sending all reports to the Storage Manager

2.4.5. Storage Manager (1.4)


• Forward received storage data to CCF for archiving

2.4.6. M&C Manager (1.5)


• Providing M&C interfacing function for Mission Monitoring (M&C Client or Local M & C Means).4

4 ESA RID SRR

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 31


• Setting the modes of the function in accordance with EGNOS States & Modes concept.

2.4.7. M&C Client (1.6)


• Enabling an operator to Monitor and Control the ALIVE function via the M&C Manager.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 32


2.4.8. State Transition Diagram RLM

The diagram below depicts the state transitions for the RLM as it proceeds through the EGNOS processes:

Scheduled

RLM Request Received from RLSP

Queued

Disseminated

Received

Queue size acceptable for CPF

All SIS Messages Sent by CPFs to respective NLES

Received by at least one ground stationwithin the allocated reception timeout

Cancelled by RLSP

Submitted

Passed incoming checksFailed Incoming checks

or not ready

Cancelled Rejected

Not received within allocatedreception timeout

Figure 12 : RLM State Transition Diagram

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 33


From an external interface point of view, the following states will be made available to the RLSP for external tracking of RLM progress.

The following notes about the states and their transitions:

• Submitted : Upon initial reception of RLM requests from the RLSP.

• Scheduled : The RLSP Interface Manager function is responsible for performing incoming checks of the messages. If the results are passed, the status is set to submitted.

• Queued : The Uplink Message Manager monitors the current ALIVE queue lengths of each of the CPF lanes. When the queue lengths reach an acceptable level, the messages are sent to the CPF and reach the “Queued” state. The bandwidth assessment in section 2.3 above indicates that there is available bandwidth to ensure that queue size in the CPF is kept to a low level (very few messages are queued at a given time). Note that when this status has been attained (i.e. the messages have been sent to the CPF), cancellation is no longer possible (or recommended).

• Disseminated : When all of the CPF GEO lanes have emitted the ALIVE MTX message to its respective NLES, the RLM status is set to “disseminated”.

• Received : When each GEO lane has been disseminated, the RIMS stations are monitored by the Service Performance Assessment function. When all GEO messages have been received, this state is set. This state is an end state.

• Rejected : In the event of failure of incoming checks, ALIVE function not available or other situations that are incompatible for scheduling and RLM, the RLM is rejected.

• Cancelled : RLM uplinking can be cancelled for a number of reasons. The cancellation is not necessarily an abnormal state since the RLSP may issue a cancellation request in the event that the receiving service has been successfully alerted. In the unlikely event that confirmation of RLM reception has not been received by any RIMS station, the status is also set to cancelled.

The above RLM lifecycle is reported by the Service Performance Assessment Manager.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 34


3. ALIVE Architecture Definition

3.1. ALIVE Service Deployment Strategy

The definition of the ALIVE Service deployment strategy will enable the definition of the implementation roadmap aimed at minimising impacts to EGNOS operations.

3.1.1. Deployment constraints identification

The deployment strategy shall cope with the following constraints:

• The ALIVE Service Evolution will have to be deployed when EGNOS system will be operational. This implies that the deployment shall be performed without interrupting the EGNOS system operational service. This includes without interrupting the ALIVE Service operations.

• In order to enable a relatively quick deployment, an initial operational solution shall be implemented followed by a fully capable solution.

3.1.2. Deployment phases identification

The following phases shall be considered:

• Phase 1: ALIVE Service Advanced Operational Capability (AOC)

• Phase 2: ALIVE Service Fully Operational Capability (FOC)

These phases are represented on the preliminary schedule provided in section 6.2.

3.1.3. Description of ALIVE Service configuration steps

The following successive steps for the ALIVE Service configurations are to be considered:

• Step 1: Implementation of a single instantiation of the ALIVE infrastructure (EWAN/ALIVE Server/Security) at one EGNOS MCC with a basic Return Link Message Delivery Service. This Advanced Capability will also enable integration with the first user application (e.g. COSPAS/SARSAT). The INSPIRE

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 35


interface will be the sole means of obtaining feedback with regards to message delivery performances.

• Step 2 : Full multi-MCC site installation, including mechanisms for managing Main/Backup ALIVE Service. This Fully Operational Capability would also include improved robustness to service continuity feared events, full reporting capability to RLSPs, and multi RLSP handling. Additional test means would be integrated to cater for the additional capabilities.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 36


3.2. EGNOS system architecture for ALIVE Service Evolution

3.2.1. Overview

The purpose of this section is to summarise the main characteristics of the ALIVE Service Evolution architecture.

The following figure provides the overview of EGNOS system architecture for

implementation of the ALIVE Service Evolution.

The following main design drivers have been taken into account:

• Cost efficiency, including maximum re-usage policy

• Design simplicity

• Functional segregation : the addition of the ALIVE service could be considered as a service independent of the “core” navigation mission of EGNOS. With this in mind, it is recommended to ensure a degree of segregation between the different services, thus reducing re-qualification effort for the core EGNOS navigation services. This includes giving priority to the allocation of spare real-time processing budget margins for existing ESS to their intended usage which is serving the EGNOS navigation mission.

• Minimisation of operational impact to the currently deployed EGNOS system.

• Although the ALIVE services shall enable serving multiple clients (and hence multiple RLSPs), real-time dynamic reconfigurations are not recommended for safety and security reasons, and also to enable design simplification.

• Ensure that current compliance to system performance requirements, including RAMS requirements is not compromised.

• Ensure that currently allocated software DAL levels remain unaffected

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 37


User

GEO

NLES

CPF

PS

CS

GPS Satellites

ALIVE SERVER

RLSP APP1

CCF

Support Facilities

> ALIVEArchive

> NOF> Addition of MTX

> Uplink Request

> GEO C1> Addition of MTX

> GEO L1> Addition of MTX

> L1> L2 P(Y)

RIMS > GEO L1> Addition of MTX

> L1> L2 P(Y)

> Current RIMS Data> Addition of MTX

RLSP APPN


ALIVE FUNCTIONS

> CPF ALIVEMonitoring Data

ALIVEM&C Client

> ALIVEM & C > Current CPF M&C data

> CPF ALIVE Archive data

> ALIVE M&C Data according to JOS

> Current CCF archive data> Archive data augmented with

ALIVE archive

INSPIRE Interface


Figure 13 : ALIVE Service Evolution Impact on EGNOS Data Flows5

5 ESA RID SRR

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 38


3.2.2. Functional to Physical Allocation Mapping

The functions described in the Functional Analysis have been allocated the physical equipments as identified in the table overleaf.

Function Physical Allocation Justification

RLSP Interface Manager

ALIVE Server • Functional Segregation (including minimisation of impact to existing ESS)

• Cost (CPF modifications likely more costly in terms of development & re-qualification)

Uplink Message Manager



Service Performance Assessment



Storage Manager ALIVE Server • Functional Segregation (including minimisation of impact to existing ESS)


M&C Manager ALIVE Server • Functional Segregation (including minimisation of impact to existing ESS)


M&C Client TBD (CCF or re-use ENMA/ENMA client concept)

• Functional Segregation from the rest of EGNOS Navigation Functions

• Maximum Re-use, Minimal Cost

• Minimise operational impacts

Table 1 : ALIVE Service Allocation of Functions to Physical Equipments

3.2.3. ALIVE Server at MCC

It is proposed to introduce new equipments “ALIVE Server” at the MCC to implement the ALIVE function. Note that since the ALIVE Server implements security as well as RLM functional aspects, it is highly likely that two separate equipments will constitute

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 39


the ALIVE Server (e.g. ALIVE firewall + ALIVE processing equipment). A more precise MCC implementation is provided later in the document. Since the availability requirements do not require an ALIVE server to be installed at each MCC site, it is however proposed to adopt a Main/Backup redundancy management concept as depicted in Figure 14 : ALIVE Server Multi-MCC Potential Architecture, below. Such a Main/Backup organisation would enable EGNOS UP testing and provide a better level of availability. This point should be discussed at SRR. Note that the active (Main) ALIVE Server communicates with CPF, CCF and M&C Client equipments at each of the MCC sites via the inter-MCC EWAN links. All RLSPs are connected to the current Main ALIVE Server.

RLSP-A

MCC#1

CPF

MCC#2

CPF

MCC#3

CPF

MCC#4

CPF

MAINALIVE

SERVER

RLSP-B

COLDBACKUP

ALIVESERVER

NLES

NLES

NLES

NLES

RLSP-X

RLSP-ARLSP-A

MCC#1

CPF

MCC#2

CPF

MCC#3

CPF

MCC#4

CPF

MAINALIVE

SERVER

RLSP-BRLSP-B

COLDBACKUP

ALIVESERVER

NLES

NLES

NLES

NLES

RLSP-X

Figure 14 : ALIVE Server Multi-MCC Potential Architecture

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 40


3.2.4. ALIVE Service Processing

The ALIVE Server is responsible for implementing all functions identified in the functional analysis above:

• RLSP interface manager

• Uplink message manager

• Service Performance Assessment

• Storage Manager

• M&C Manager

• M&C Client

3.2.5. ALIVE Service Monitoring and Control

Both the RLSP and the EGNOS are able to monitor the status of the RLSP-EGNOS interface. The main operational interest of the RLSP is to understand what is happening with respect to the particular application being served by ALIVE (e.g. Search and Rescue Alerts Status). Since the EGNOS ALIVE service manages multiple services simultaneously, operational monitoring reports should be possible at each RLSP service level. The following control and monitoring functions are required for the ALIVE service:

• Capability to manage SWRU configuration (upload, download, get configuration data)

• Monitoring of RLM lifecycle performances per service.

• Manual request to send RLM messages

• Manual request to cancel RLM messages

• Manual request to set the service modes (unavailable/available)

• Manual request to set a system outage message (textual)

Since the CCF primary role is to monitor and control the EGNOS Navigation Mission, it would appear that an alternative means for performing the M & C of the ALIVE Service could be studied. Indeed, a candidate solution could be to re-use the FEE/ENMA/ENMA Client concept and transfer the application specific alarms to the CCF when required (an example alarm being saturation of the ALIVE service due to congestion). A trade-off for possible design solutions will be performed for the V2.2 PDR concerning this point.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 41


It should be noted that whatever the architectural solution decided, the ALIVE Service will remain under the control of the PACF from an operational & configuration management viewpoint. The PACF will direct the ALIVE Service operations using the JOS.

3.2.6. ALIVE Service Archiving

All relevant ALIVE service data is archived via standard CCF archiving channels. The archived data can then be analysed with the support of the PACF and ASQF facilities.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 42


4. System impact assessment of ALIVE Service Evolution

4.1. Introduction

The purpose of this section is to define in more detail, the impact of the ALIVE Service Evolutions on the system in a systematic manner. The following aspects will be considered for the system impacts assessment:

• functional aspect

• interfaces aspect

• performance aspect

4.2. Functional impact assessment

4.2.1. Overall Assessment

The purpose of this section is to provide functional impact assessment of the ALIVE Service Evolution.

The EGNOS AOC system includes the following functions:

• function 1 “collect and pre-process data”

• function 2 “determine satellites orbits”

• function 3 “determine satellites corrections”

• function 4 “provide satellites integrity data”

• function 5 “determine ionosphere corrections and related integrity data”

• function 6 “provide independent verification”

• function 7 “provide EGNOS network time”

• function 8 “provide SIS ranging service and message broadcast”

• function 9 “provide system communication”

• function 10 “provide system monitoring and control”

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 43


In addition to the above functions, it is proposed to add a new system level function in the EGNOS AOC System:

• function 11 “provide ALIVE service”

The following functions are not impacted by the ALIVE service evolution:

• function 1 “collect and pre-process data” : although the content of the GEO satellite data content evolves with the ALIVE evolution, the data collection and pre-process function remains unaffected.

• function 2 “determine satellite orbit”

• function 3 “determine satellite corrections”

• function 4 “provide satellites integrity data”

• function 5 “determine ionosphere corrections and related integrity data”

• function 6 “provide independent verification”

• function 7 “provide EGNOS network time”

4.2.2. ALIVE impact on function 8 “provide SIS ranging service and message broadcast”

The following function 8 requirement shall be updated in order to cope with the incorporation of the ALIVE service:

EGN-S-01245-ESA.4: The navigation message shall include the following data:

a) SBAS satellite ephemeris data;

b) SBAS satellite almanac data;

c) fast correction data;

d) long term correction data;

e) integrity data;

f) ionospheric correction data;

g) timing data;

h) service level data;

i) Return Link Service data,

with format compliant with Appendix A of (AD 04-06), complemented by (AD 04-02), and AD-TBD.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 44


4.2.3. ALIVE impact on function 9 “provide system communication”

The following features shall be added to the function 9, in order to cope with the incorporation of the ALIVE service:

• EGNOS function 9 shall be upgraded to integrate the ALIVE service

• EGNOS function 9 shall be upgraded to allow communications with external Return Link Service Providers (RLSPs) to the ALIVE service.

4.2.4. ALIVE impact on function 10 “provide system monitoring and control”

The following features shall be added on the function 10, in order to cope with the ALIVE evolution:

• EGNOS function 10 shall be upgraded to perform the commanding and monitoring of the ALIVE features added in functions 8 and 11.

• EGNOS function 10 shall be upgraded to archive the function 11 related data.

• EGNOS function 10 shall be upgraded to perform analysis and processing of function 11.

• EGNOS function 10 shall be upgraded to perform the configuration management of the ALIVE evolution on the EGNOS system.

4.3. Interface impact assessment

4.3.1. Identification of impacted EGNOS interfaces

According to the architecture presented in section 3.2 the following EGNOS interfaces are impacted by the ALIVE Service Evolution:

• RLSP / ALIVE SERVER external interface

• NLES / GEO external interface

• GEO / RIMS external interface

• RIMS / ALIVE SERVER internal interface

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 45


• RIMS / CPF internal interface

• ALIVE SERVER / CPF internal interface

• CPF / CCF internal interface

• ALIVE SERVER / CCF internal interface

• ALIVE SERVER / M&C internal interface

• NLES / CPF internal interface

• CCF / Support Facilities

• M&C Client / Support Facilities

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 46


4.3.2. RLSP / ALIVE SERVER External Interface

This is a new external interface for EGNOS and is the sole means of communicating from the RLSP to EGNOS. The data flows are depicted in the interaction diagram and detailed in the table below.

RLSP EGNOSReturnLinkAckNotif

ReturnLinkCancNotif

INF_ReportInfoRqst

INF_RlmNotifMnt

FlowCtrlInfo

SystemStatus

INF_ClkEphemIonoPredData

RLSP EGNOSReturnLinkAckNotif

ReturnLinkCancNotif

INF_ReportInfoRqst

INF_RlmNotifMnt

FlowCtrlInfo

SystemStatus

INF_ClkEphemIonoPredData

Figure 15 : RLSP/EGNOS Interaction Diagram

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 47


4.3.2.1. Data flow from RLSP to EGNOS

From To Dataflow Contents Description Protocol/Synch/

Max Freq/Size

RLSP EGNOS RLSP_Rqst ReturnLinkAckNotif ReturnLinkCancNotif

Requests issued by the RLSP to disseminate a RLM on a particular location on Earth or to cancel the dissemination of a previously requested RLM.

UDP/IP Async/ 15 secs/ 10 KB

RLSP EGNOS RLSP_ReportRqst

INF_ReportInfoRqst Request from the RLSP to obtain particular data/reports from EGNOS.

TCP/IP/ Async/ NA/ 1 KB

Table 2 : DataFlow RLSP -> EGNOS

4.3.2.2. Data flow from EGNOS to RLSP


Max Freq/ Size

EGNOS RLSP RlmStatus INF_RlmNotifMnt This message contains monitoring information regarding Return Link Message (RLM) notification status for each active RLM from the last RLM notification.

UDP/IP Sync/ 300 secs/50 KB

EGNOS RLSP FlowControlInfo FlowCtrlInfo Warning information to the RLSP regarding inability to process requests or capacity restrictions for a particular GEO.

TCP/IP/ Async/ NA/ 10 KB

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 48



Max Freq/ Size

EGNOS RLSP SystemStatus SystemStatus Information provided to the RLSP regarding the status of different ALIVE/EGNOS components.

TCP/IP/ Sync/ 900 secs/50 KB

EGNOS RLSP ReportToRlsp INF_ClkEphemIonoPredData(TBC)

Ephemeris data of GEO satellites provided to the RLSP (possibly required by some users). This will be consolidated for V2.2 CDR.6

FTP/ Sync/ 6000 secs/ 100 KB

Table 3 : DataFlow EGNOS -> RLSP

In addition the messages identified above, the RLSP shall add the standard EGNOS communications header including items such as source address, desitnation address, CRC, data length etc).

4.3.3. NLES / GEO external interface

This interface is implemented through the transmission of the C1 band uplink to the GEO via the NLES RF adapters. This dataflow is impacted as a new MOPS message type (MTX) shall be uplinked to the GEOs. The following diagram depicts the basic frame of the MOPS message7

ALIVE Applications Information

DIRECTION OF DATA FLOW FROM SATELLITE; MOST SIGNIFICANT BIT (MSB) TRANSMITTED

250 bits

Preamble MT PARITY

212 data bits6 bitsmessage

type

8 bitpreamble

24 bitparity

ALIVE Applications Information

DIRECTION OF DATA FLOW FROM SATELLITE; MOST SIGNIFICANT BIT (MSB) TRANSMITTED

250 bits

Preamble MT PARITY

212 data bits6 bitsmessage

type

8 bitpreamble

24 bitparity

6 ESA RID SRR 7 Source [MOPS_3B]

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 49


Figure 16 : MOPS Message Data Block Format

Out of the 212 data bits available, the following proposed bit allocation could be adopted:

3 bits for a ALIVE Service ID

208 bits for ALIVE message content for the ALIVE service8

4.3.4. GEO / RIMS external interface

This interface is implemented through the GEO SIS as specified by the [MOPS_3B] standard. This dataflow is impacted as a new MOPS message type (MTX) shall be broadcast by the GEO satellites and received by the RIMS.

4.3.5. RIMS / ALIVE SERVER internal interface

This interface is implemented through the data flow RIMS_CG. This data flow is impacted as a new MOPS message type (MTX) shall be sent by the RIMS to the ALIVE SERVER. It should be noted that the RIMS_CG is not impacted structurally since the RIMS does not use the newly created MTX message (functional impact is limited to ALIVE).

4.3.6. RIMS / CPF internal interface

This interface is implemented through the data flow RIMS_CG. This data flow is impacted as a new MOPS message type (MTX) shall be sent by the RIMS to the CPF. It should be noted that the RIMS_CG is not impacted structurally since the RIMS does not use the newly created MTX message (functional impact is limited to CPF).

4.3.7. ALIVE SERVER / CPF internal interface

This interface is implemented through a new specific EGNOS data flow ALIVE_CPF and an upgrade to the existing CPF_AG (cyclic data). Note that the CPF manages one ALIVE message queue per GEO lane, which is in linke with the current design of Navigation messages. The following table provides the interface definition.

8 ESA RID SRR

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 50


From To Dataflow Contents Description Protocol/ Synch/ Max Freq/ Size

ALIVE CPF ALIVE_CPF ALIVEUplinkMsg This message contains uplink message requests to each CPF, based on the reported message queue size for the active CPF GEO lanes. The message includes:

• a single 212 bit application part of the MOPS Message Data Block Format depicted in Figure 16 : MOPS Message Data Block Format above.

• message identifier referenced by each CPF when providing uplink status

UDP/IP Multicast/ Async/ 900 secs/ 212 bits+ 99 bit for header, msg id.

CPF ALIVE CPF_AG CPFALIVEUplinkStatus This constitutes an upgrade to the current CPF_AG dataflow. Each CPF reports the status of its FIFO buffered ALIVE messages. The status includes :

• 3 x ALIVE buffer status, including acknowledgement of ALIVEUplinkMsg messages (accept/reject)

UDP/IP Multicast/ Sync/ 1 sec/ 3 * 1 KB

Table 4 : ALIVE Server/CPF DataFlow

4.3.8. CPF / CCF internal interface

This interface is implemented through the existing data flow CPF_AG cyclic monitoring. This data flow shall be upgraded in order to provide

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 51


“CPFALIVEUplinkStatus” (see Table 4 : ALIVE Server/CPF DataFlow, above) message for archiving. It is TBD whether a structural impact to the current CPF_AG flow is necessary. A structural impact in this flow could imply a more complex EGNOS upgrade strategy with respect to backwards compatibility aspects.

Specific commanding interface to CPF for ALIVE purposes has not been foreseen.

4.3.9. ALIVE SERVER/CCF internal interface

This interface is implemented through a new specific EGNOS data flow ALIVE Archive Group (ALIVE_AG). This link carries the ALIVE Server cyclic monitoring data through FEE and EWAN for multicast transmission to an Archive Group (set of CCF).

The following table provides the interface definition.


ALIVE CCF ALIVE_AG ALIVEArchiveData • permanent general and per LRU/SWRU/Function overall status information,

• all RLM related events including state transitions as described in 2.4.8 above.

• cyclic detailed information concerning one or more ALIVE LRU/SWRU/Functions.

UDP/IP Multicast/ Sync/ 1 sec/ TBD

Table 5 : ALIVE Server/CCF DataFlow

4.3.10.ALIVE SERVER/M&C internal interface

This interface is implemented through a new specific EGNOS data flow ALIVE M&C, which is used for Monitoring and Control of the ALIVE Server. Since it has not yet been determined whether a dedicated equipment shall be used or the CCF, the M&C equipment has been represented as a separated box in the architecture diagram.

The following table provides the interface definition.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 52



ALIVE M&C ALIVE_AG

ALIVE_CMD

ALIVE M&C Data

• ALIVE_AG data as shown in previous table

• SWRU configuration (upload, download, configuration data)

• Commands to request to send RLM messages

• Commands to request to cancel RLM messages

• Commands to set the service modes unavailable/available

• Commands to set a system outage message (textual messages)

UDP/IP Multicast/ Sync/ 1 sec/ TBD

(ALIVE_AG)

TBD

(ALIVE_CMD)

Table 6 : ALIVE Server/M&C DataFlow

4.3.11.NLES / CPF internal interface

This flow from CPF to NLES is implemented through the CPF_NLES dataflow. This data flow is impacted as a new MOPS message type (MTX) shall be sent by the CPF to the NLES. The flow from NLES to CPF is implemented through the NLES_CG dataflow.

This data flow is impacted since the NLES provides the last four messages disseminated.

It should be noted that the CPF_NLES and NLES_CG dataflow structures are not impacted since the MOPS structure remains the same (functional impact is limited to CPF).

4.3.12.CCF / Support Facilities

This interface is implemented through the transmission of the upgraded archive data to the PACF and ASQF support facilities.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 53


4.3.13.M&C Client / Support Facilities

This interface is implemented through the transmission of JOS related information from the PACF for commanding/configuration management purposes.

4.3.14.INSPIRE / RIMS internal interface

This interface is implemented through the INSPIRE interface subscription to the RIMS data. This dataflow is impacted as a new MOPS message type (MTX) shall be relayed by the RIMS.9

4.4. Performances impact

The navigation function performances are not impacted by the ALIVE service evolution (TBC). Any potential RAM and Safety performance impacts are completely covered by the RAM & Safety Assessment detailed in the next section.

A complementary analysis will be performed for the real-time processing allocation for the PDR milestone.

4.5. RAM & Safety Impact Assessment

4.5.1. RAMS Assessment Method

The approach to performing the RAMS assessment is extensively described in [RAMS_REPORT] and is briefly described below. The RAMS analyses approach follows two steps:

The first step is qualitative in order to show the robustness of the proposed architecture vis-à-vis single, common or combined failures and/or operator errors. To analyse their effects and to identify which means are implemented to detect and compensate them. The determination of the software DAL with respect to the defined

9 ESA RID SRR

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 54


level of criticality for continuity and integrity (major) is also performed. In order to do this, the following studies are be performed:

• Failures Modes, Effects and Criticality Analysis (FMECA) : to analyse single or common mode failures (with respect to software and hardware), their effects on the ALIVE service (and EGNOS system when relevant) and identify means to detect and compensate them. To identify degraded modes and suggest recommendations for improving the current baseline or minimize any issues arising due to the ALIVE service impacting the EGNOS system (failure propagation cases).

• Fault Tree Analysis (FTA) : to determine combined failure modes resulting in the loss of integrity or continuity of the ALIVE service and allocate the correct software DAL on the ALIVE service elements according to the defined software DAL allocation procedure.

• Human Dependability Analysis : the same as FMECA but with respect to operator errors instead of software or hardware failures. Note that at this stage of the ALIVE function lifecycle, a Human Dependability Analysis has is not considered appropriate due to the immaturity of the design solution and associated operational concept. Human Dependability Analysis shall be performed for V2.2 CDR.

The second step is quantitative to show the level of performances (availability, continuity and integrity) that the ALIVE service can offer according to the definition of the functional chain which supports the ALIVE service and available quantitative data (such as the I&CoS study) from previous assessments performed on EGNOS AOC system to estimate it.

REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 55


4.5.2. Qualitative Requirements Analysis

4.5.2.1. New Requirements

There is one new qualitative requirement:

Name Requirement Text

EGN-ALIVE-180-ESA: Safety Conditions

The provision of EGNOS ALIVE mission shall be considered as “major” in terms of safety criticality.

4.5.2.2. FMECA Analysis

The assumptions taken into account to perform the analysis are recalled below:

• It is assumed all NLES selects the same CPF (conservative assumption).

• Three GEOs are required to ensure the service (conservative assumption)

The results of the FMECA are summarized in the table below:

Subsystem Failure Effect Remarks

ALIVE Firewall, FEE-Firewall and external network links

Loss of ALIVE Interface

ALIVE service is unavailable

Degraded mode: RLSP operator could send messages through another means (phone, fax, e-mail)

ALIVE FEE and TWAN link

Loss of all ALIVE functions


RIMS A and TWAN link No effect as at least one RIMS is enough to have the feedback of messages sent to GEOs

RIMS A common failure mode

No return of sent messages to GEOs

Degradation of ALIVE service performance assessment

Degraded mode: possible use of NLES feedback (not currently part of baseline design)

CPF Loss of one or many messages

Degradation of ALIVE service continuity

The impact on continuity depends on the memorized messages within CPF and the defined strategy after a CPF switch

CPF common failure mode

Loss of generation function


REF: 200136186H

Is.: 1 Rev.: B Date: 27/03/06 Page: 56


Subsystem Failure Effect Remarks

NLES and TWAN link Message not sent to one GEO

Degradation of ALIVE service continuity

- Degraded service: ALIVE service is able to send its messages through 2 GEO only

- Time to switch over (5 min.) the backup NLES is compatible with the required delay in case the message is sent again

NLES common failure mode

Loss of uplink function. ALIVE service is unavailable

CCF and TWAN link