Ryan Malloy
4ed92efd69
Cospas-Sarsat specification summaries moved to reference/ for internal use only. Links updated to point to official cospas-sarsat.int site. The extracted images remain in public/ for use in other pages.
3899 lines
106 KiB
Markdown
3899 lines
106 KiB
Markdown
---
|
||
title: "A006: C/S A.006 Issue 5 - Rev.8"
|
||
description: "Official Cospas-Sarsat A-series document A006"
|
||
sidebar:
|
||
badge:
|
||
text: "A"
|
||
variant: "note"
|
||
# Extended Cospas-Sarsat metadata
|
||
documentId: "A006"
|
||
series: "A"
|
||
seriesName: "Operational"
|
||
documentType: "operational"
|
||
isLatest: true
|
||
issue: 5
|
||
revision: 8
|
||
documentDate: "October 2025"
|
||
originalTitle: "C/S A.006 Issue 5 - Rev.8"
|
||
---
|
||
|
||
> **📋 Document Information**
|
||
>
|
||
> **Series:** A-Series (Operational)
|
||
> **Version:** Issue 5 - Revision 8
|
||
> **Date:** October 2025
|
||
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
||
|
||
---
|
||
|
||
COSPAS-SARSAT
|
||
MISSION CONTROL CENTRE
|
||
COMMISSIONING STANDARD
|
||
C/S A.006
|
||
Issue 5 – Revision 8
|
||
|
||
|
||
|
||
HISTORY
|
||
Issue Revision Date
|
||
Comments
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-7)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-15)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-31)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-35)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-37)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-39)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-41)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-43)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-45)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-47)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-49)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-51)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-55)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-57)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-59)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-61)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-62)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-63)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-64)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-66)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-69)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-71)
|
||
|
||
|
||
Approved by the Cospas-Sarsat Council (CSC-73)
|
||
|
||
TABLE OF CONTENTS
|
||
Page
|
||
1.
|
||
INTRODUCTION ............................................................................................................ 1-1
|
||
1.1
|
||
Purpose ...................................................................................................................... 1-1
|
||
1.2
|
||
Scope ......................................................................................................................... 1-1
|
||
1.3
|
||
Reference Documents ............................................................................................... 1-1
|
||
2.
|
||
INTEGRATION OF MCCS IN THE COSPAS-SARSAT SYSTEM ........................... 2-1
|
||
2.1
|
||
Pre-Integration Test................................................................................................... 2-1
|
||
2.1.1
|
||
General ........................................................................................................ 2-1
|
||
2.1.2
|
||
Preliminary Actions .................................................................................... 2-1
|
||
2.1.3
|
||
Pre-Integration Test .................................................................................... 2-2
|
||
2.2
|
||
Integration Test ......................................................................................................... 2-2
|
||
2.2.1
|
||
General ........................................................................................................ 2-2
|
||
2.2.2
|
||
Test Preparation and Commissioning Plan ................................................. 2-3
|
||
2.2.3
|
||
Test Requirements ...................................................................................... 2-3
|
||
2.3
|
||
Data Collection and Analysis .................................................................................... 2-4
|
||
2.3.1
|
||
General ........................................................................................................ 2-4
|
||
2.3.2
|
||
DMCC Data Collection .............................................................................. 2-4
|
||
2.3.3
|
||
Ground Segment Status Summary .............................................................. 2-5
|
||
2.3.4
|
||
Performance Specifications Not Part of the Integration Test ..................... 2-5
|
||
2.3.5
|
||
Analysis ...................................................................................................... 2-5
|
||
2.3.6
|
||
MCC Commissioning Report ..................................................................... 2-5
|
||
2.4
|
||
Commissioning of New MCCs ................................................................................. 2-5
|
||
2.5
|
||
Recommissioning of a Previously Commissioned MCC .......................................... 2-7
|
||
2.6
|
||
Change of Location of a Commissioned MCC ......................................................... 2-7
|
||
3.
|
||
ESTABLISHMENT OF NEW NODAL MCCS ............................................................. 3-1
|
||
3.1
|
||
Principles for Establishing New Nodal MCCs ......................................................... 3-1
|
||
3.2
|
||
Preliminary Actions .................................................................................................. 3-1
|
||
3.3
|
||
Regional Coordination and Commissioning Plan ..................................................... 3-2
|
||
3.3.1
|
||
Regional Coordination ................................................................................ 3-2
|
||
3.3.2
|
||
Commissioning Plan ................................................................................... 3-2
|
||
3.4
|
||
Commissioning of New Nodal MCCs ...................................................................... 3-2
|
||
3.4.1
|
||
General ........................................................................................................ 3-2
|
||
|
||
3.4.2
|
||
Pre-test Coordination .................................................................................. 3-3
|
||
3.4.3
|
||
Test Requirements ...................................................................................... 3-3
|
||
3.5
|
||
Nodal MCC Data Collection and Analysis ............................................................... 3-3
|
||
3.5.1
|
||
General ........................................................................................................ 3-3
|
||
3.5.2
|
||
New Nodal MCC Data Collection .............................................................. 3-3
|
||
3.5.3
|
||
Performance Specifications Not Part of the Commissioning Tests ............ 3-4
|
||
3.5.4
|
||
Analysis ...................................................................................................... 3-4
|
||
3.5.5
|
||
Nodal MCC Commissioning Report ........................................................... 3-4
|
||
3.6
|
||
Commissioning Procedure and Implementation ....................................................... 3-4
|
||
LIST OF ANNEXES
|
||
Page
|
||
Annex A
|
||
Guidelines for Integration of New MCCs in the Cospas-Sarsat System ............. A-1
|
||
Annex B
|
||
Format for Reporting DMCC Test Data ............................................................. B-1
|
||
Annex C
|
||
MCC Commissioning Report .............................................................................. C-1
|
||
Annex D
|
||
Guidelines for Implementing New Nodal MCCs ................................................ D-1
|
||
Annex E
|
||
Nodal MCC Commissioning Report .................................................................... E-1
|
||
Annex F
|
||
MCC Commissioning Guidelines ........................................................................ F-1
|
||
Annex G
|
||
Declaration of DMCC on Operator Capability ................................................... G-1
|
||
Annex H
|
||
Declaration of DMCC Initial Operational Capability ......................................... H-1
|
||
LIST OF FIGURES
|
||
Page
|
||
Figure 2-1:
|
||
MCC Commissioning Procedure ......................................................................... 2-9
|
||
|
||
LIST OF TABLES
|
||
Page
|
||
Table B-1:
|
||
LUT Summary Database ..................................................................................... B-1
|
||
Table B-2:
|
||
Alert Data Summary Database ............................................................................ B-2
|
||
Table B-3:
|
||
Non-Alert Message Summary Database ............................................................. B-4
|
||
Table C-1:
|
||
Communications Links ....................................................................................... C-2
|
||
Table C-2:
|
||
Operational Requirements ................................................................................... C-2
|
||
Table C-3:
|
||
Functional Requirements ..................................................................................... C-9
|
||
Table C-4:
|
||
Performance Requirements ............................................................................... C-15
|
||
Table C-5:
|
||
FGB LEOSAR and GEOSAR Incident Alert Messages ................................... C-19
|
||
Table C-6:
|
||
FGB MEOSAR Incident Alert Messages .......................................................... C-20
|
||
Table C-7:
|
||
SGB Incident Alert Messages ........................................................................... C-21
|
||
Table C-8:
|
||
System Messages ............................................................................................... C-23
|
||
Table C-9:
|
||
System Messages for Space Segment Providers ............................................... C-24
|
||
Table E-1:
|
||
Communications Links ........................................................................................ E-2
|
||
Table E-2:
|
||
Operational Requirements .................................................................................... E-2
|
||
Table E-3:
|
||
Functional Requirements ...................................................................................... E-3
|
||
Table E-4:
|
||
Performance Requirements .................................................................................. E-3
|
||
Table E-5:
|
||
Co-ordinating Requirements ................................................................................ E-4
|
||
Table G-1:
|
||
Operator Capability ............................................................................................. G-1
|
||
|
||
1-1
|
||
|
||
INTRODUCTION
|
||
1.1
|
||
Purpose
|
||
This document shall be used to verify that a new Mission Control Centre (MCC) or a new nodal
|
||
MCC complies with the provisions of document C/S A.005, “Cospas-Sarsat Mission Control
|
||
Centre Performance Specification and Design Guidelines”.
|
||
Participants connecting their MCC to the Cospas-Sarsat System or assuming the responsibility of
|
||
a new nodal MCC in the Cospas-Sarsat System shall conduct tests and provide data as specified
|
||
in this document. This document shall also be used to verify that a previously commissioned MCC
|
||
continues to comply with the provisions of document C/S A.005, as appropriate.
|
||
1.2
|
||
Scope
|
||
The commissioning process outlined in this document is required to ensure that all MCCs,
|
||
including nodal MCCs, provide for reliable, timely and accurate exchange of alert data and System
|
||
information within the Cospas-Sarsat Ground Segment.
|
||
The commissioning process includes preliminary actions to be performed by the responsible
|
||
Ground Segment operators, co-ordination required with other Ground Segment operators involved
|
||
in the commissioning tests, practical steps to be accomplished for implementing the
|
||
commissioning tests, and the formal procedure leading to Council approval of the commissioning
|
||
of the new MCC or the new nodal MCC in the Cospas-Sarsat System.
|
||
1.3
|
||
Reference Documents
|
||
a.
|
||
C/S A.001
|
||
Cospas-Sarsat Data Distribution Plan,
|
||
b.
|
||
C/S A.002
|
||
Cospas-Sarsat Mission Control Centres Standard Interface Description,
|
||
c.
|
||
C/S A.003
|
||
Cospas-Sarsat System Monitoring and Reporting,
|
||
d.
|
||
C/S A.005
|
||
Cospas-Sarsat Mission Control Centre Performance Specification and
|
||
Design Guidelines,
|
||
e.
|
||
C/S P.011
|
||
Cospas-Sarsat Programme Management Policy,
|
||
f.
|
||
C/S S.011
|
||
Cospas-Sarsat Glossary,
|
||
g.
|
||
C/S T.001
|
||
Specification for Cospas-Sarsat [First-Generation] 406 MHz Distress
|
||
Beacons,
|
||
h.
|
||
C/S T.002
|
||
Cospas-Sarsat
|
||
LEOLUT
|
||
Performance
|
||
Specification
|
||
and
|
||
Design
|
||
Guidelines,
|
||
i.
|
||
C/S T.005
|
||
Cospas-Sarsat LEOLUT Commissioning Standard,
|
||
|
||
|
||
|
||
1-2
|
||
|
||
j.
|
||
C/S T.009
|
||
Cospas-Sarsat GEOLUT Performance Specification and Design
|
||
Guidelines,
|
||
k.
|
||
C/S T.010
|
||
Cospas-Sarsat GEOLUT Commissioning Standard,
|
||
l.
|
||
C/S T.015
|
||
Cospas-Sarsat Specification and Type-Approval Standard for 406 MHz
|
||
Ship Security Alert System (SSAS) Beacons,
|
||
m.
|
||
C/S T.018
|
||
Specification for Cospas-Sarsat Second-Generation 406 MHz Distress
|
||
Beacons,
|
||
n.
|
||
C/S T.019
|
||
Cospas-Sarsat MEOLUT Performance Specification and Design
|
||
Guidelines,
|
||
o.
|
||
C/S T.020
|
||
Cospas-Sarsat MEOLUT Commissioning Standard.
|
||
Other information that is used in this document is contained on the Cospas-Sarsat web-site,
|
||
available at http://www.cospas-sarsat.int/en/pro.
|
||
The acronyms used in this document are contained in the “Cospas-Sarsat Glossary”, document
|
||
C/S S.011.
|
||
- END OF SECTION 1 –
|
||
|
||
2-1
|
||
|
||
INTEGRATION OF MCCS IN THE COSPAS-SARSAT SYSTEM
|
||
2.1
|
||
Pre-Integration Test
|
||
2.1.1
|
||
General
|
||
Prior to formal integration testing, the new MCC under development (DMCC) shall
|
||
provide the Cospas-Sarsat Secretariat with information about its new Local User
|
||
Terminal(s) (LUTs), if any, its proposed service area, and all other information needed to
|
||
amend the appropriate pages of the Cospas-Sarsat website and the sections of document
|
||
C/S A.001. Upon completion of these steps the Cospas-Sarsat Joint Committee will
|
||
designate or approve a nodal MCC as the host MCC (HMCC) to which the DMCC will
|
||
be connected. Bilateral arrangements between the DMCC and the host MCC needed to
|
||
support integration testing are the responsibility of the respective Administrations. Any
|
||
equipment needed for the commissioning test shall normally be provided by the DMCC.
|
||
For an MCC with an associated LUT (or LUTs), the LUT commissioning, defined in
|
||
documents C/S T.005, C/S T.010, and/or C/S T.020 may take place at the same time that
|
||
the MCC is being commissioned. If so, it is desirable that operational data exchange be
|
||
scheduled after responsible Administrations have conducted preliminary tests to verify
|
||
that their LUT(s) comply with the provisions of documents C/S T.002, C/S T.009, and/or
|
||
C/S T.019, as appropriate.
|
||
2.1.2
|
||
Preliminary Actions
|
||
Prior to undergoing commissioning, preliminary actions regarding participation in
|
||
Cospas-Sarsat shall have been undertaken in accordance with the "Guidelines for
|
||
Integration of New MCCs in the Cospas-Sarsat System" attached at Annex A to this
|
||
document. The DMCC shall have completed those actions specified in Steps A and B of
|
||
the Guidelines at Annex A to this document.
|
||
In preparation for formal commissioning, the DMCC shall ensure that:
|
||
a)
|
||
its LUT/MCC interface(s) functions satisfactorily1 and that the LUT is able to
|
||
provide the data needed to support message exchanges with the DMCC;
|
||
b)
|
||
it is capable of receiving and generating messages in accordance with the applicable
|
||
requirements of document C/S A.005, and formatted in accordance with the
|
||
provisions of document C/S A.002;
|
||
c)
|
||
it has conducted preliminary communications checks with the host MCC, using
|
||
SIT 915 narrative messages and determined that the selected communications
|
||
1 This applies only to an MCC that has an associated LUT.
|
||
|
||
|
||
|
||
2-2
|
||
|
||
circuits are suitable for operational testing in accordance with the applicable
|
||
requirements of document C/S A.005;
|
||
d)
|
||
it is capable of suppressing unwanted data in accordance with the applicable
|
||
requirements of document C/S A.005; and
|
||
e)
|
||
it is capable of providing message traceability, national Ground Segment
|
||
monitoring and information retrieval in accordance with the applicable
|
||
requirements of document C/S A.005.
|
||
The foregoing preliminary actions are the responsibility of the DMCC. When they have
|
||
been completed, the DMCC shall complete the standard declaration form at Annex G to
|
||
this document, inform the host MCC accordingly, and advise that it is ready for further
|
||
testing.
|
||
2.1.3
|
||
Pre-Integration Test
|
||
The host MCC, when satisfied with the progress reported by the DMCC, will schedule a
|
||
pre-integration test with the DMCC. The pre-integration test may include validation of
|
||
SIT message formats, alert processing, operator capabilities and Geosort. The pre-
|
||
integration test can be undertaken continuously or be interrupted to resolve any problems
|
||
encountered.
|
||
To ensure the success of the formal integration test, it would be prudent to conduct the
|
||
pre-integration test over a period of up to a 21 days and to resolve all noted deficiencies
|
||
prior to the integration test. Results from the pre-integration test should not be treated as
|
||
part of MCC commissioning integration test and should not be included in the MCC
|
||
commissioning report.
|
||
2.2
|
||
Integration Test
|
||
2.2.1
|
||
General
|
||
The integration test involves the exchange of alert data to and from the DMCC in
|
||
accordance with document C/S A.001.
|
||
Alert data referred to above shall include all real-life alerts occurring during the
|
||
integration test period and a series of pre-formatted messages generated by the host MCC
|
||
to check C/S A.005 requirements. In addition, test-coded 406-MHz beacons may be
|
||
deployed to supplement real-life beacon activations, as needed.
|
||
The commissioning tests shall include alerts from the LEOSAR, MEOSAR, and
|
||
GEOSAR systems. The commissioning tests shall also include data from all types of
|
||
operational Cospas-Sarsat distress beacons, including First-Generation Beacons (FGBs,
|
||
compliant with C/S T.001), Second-Generation Beacons (SGBs, compliant with C/S
|
||
T.018), Ship Safety Alerting System beacons (SSAS, compliant with C/S T.015), distress
|
||
|
||
2-3
|
||
|
||
tracking ELT(DT) beacons (based on both FGB and SGB specifications), Return Link
|
||
Service (RLS) beacons (based on both FGB and SGB specifications), and Two-Way
|
||
Communication (TWC) beacons.
|
||
The test data may be generated either by activating a test beacon for the purposes of this
|
||
test or by simulating messages to force the testing of a specific feature of the MCC
|
||
specification.
|
||
The integration test should last a minimum of 48 hours but should not exceed 21 days.
|
||
The HMCC may extend this period, in particular to test items that were not tested in the
|
||
initial integration test period or retest failed items.
|
||
2.2.2
|
||
Test Preparation and Commissioning Plan
|
||
The DMCC should give as much advance notice as possible to the host MCC of its request
|
||
to be commissioned. The host MCC shall:
|
||
a)
|
||
notify all operational MCCs of the test period;
|
||
b)
|
||
co-ordinate 406 MHz beacon codes to be used for the test, and the individual beacon
|
||
on/off times and locations (beacon locations shall be provided to the nearest 10
|
||
metres);
|
||
c)
|
||
provide operational MCCs with predicted times for the 406 MHz test beacon
|
||
detections; and
|
||
d)
|
||
ensure that a Commissioning Test Plan has been developed that satisfies the test
|
||
requirements of section 2.2.3.
|
||
2.2.3
|
||
Test Requirements
|
||
During the integration test, the message routings and formats defined in documents
|
||
C/S A.001 and C/S A.002 shall be used. The basic functions of the DMCC that shall be
|
||
tested include the capability to:
|
||
a)
|
||
receive, process and forward alert data2 and System information in accordance with
|
||
document C/S A.001;
|
||
b)
|
||
selectively report or suppress transmission of alert data2 for a particular beacon
|
||
when requested;
|
||
c)
|
||
re-transmit a specified message;
|
||
d)
|
||
respond to direct requests for information from other MCCs or SPOCs;
|
||
e)
|
||
retrieve information on request;
|
||
f)
|
||
generate a "notification of country of beacon registration" (NOCR) message;
|
||
2 Note that all references to alert data include data of all types, including LEOSAR, MEOSAR, and GEOSAR alert
|
||
data, and must include data for all types of Cospas-Sarsat distress beacons.
|
||
|
||
2-4
|
||
|
||
g)
|
||
use all identified communication links;
|
||
h)
|
||
switch to backup procedures (to be identified by the DMCC in the appropriate
|
||
subsection of the “Description of Cospas-Sarsat MCCs” part of the section entitled
|
||
“Cospas-Sarsat Space and Ground Segment Description” in document C/S A.001);
|
||
i)
|
||
process unlocated 406-MHz alerts2;
|
||
j)
|
||
process ship security alerts2;
|
||
k)
|
||
process distress tracking ELT alerts2;
|
||
l)
|
||
generate a message to the Return Link Service Provider (RLSP) for a Return Link
|
||
Service (RLS) beacon;
|
||
m)
|
||
generate a message to the Two-Way Communication Service Provider (TWC-SP)
|
||
for a Two-Way Communication (TWC) beacon, and
|
||
n)
|
||
process and forward alert data2 to SPOCs that the DMCC will service after FOC.
|
||
During the test, if any serious problems are noted either by the DMCC or by other
|
||
operational MCCs, the host MCC shall be notified immediately. The host MCC will
|
||
assess the information provided and decide whether the test should continue, be delayed,
|
||
or be re-scheduled at a later date. The decision will depend upon the impact of the problem
|
||
on normal operations and the time needed for its correction.
|
||
2.3
|
||
Data Collection and Analysis
|
||
2.3.1
|
||
General
|
||
In order to facilitate data collection and analysis, key operational data should be collected
|
||
and provided in the standard format defined at Annex B to this document. Each
|
||
participating MCC shall retain copies of all incoming and outgoing messages exchanged
|
||
with the DMCC during the test period. The DMCC shall also retain copies of all messages
|
||
exchanged with other participating MCCs.
|
||
2.3.2
|
||
DMCC Data Collection
|
||
The DMCC shall provide the following data to the host MCC:
|
||
a)
|
||
a summary of LUT data (LUT Summary), per Annex B, Table B-13;
|
||
b)
|
||
a detailed summary of alert data exchanged (Alert Data Summary) including alerts
|
||
forwarded to SPOCs if applicable, per Annex B, Table B-2;
|
||
c)
|
||
a summary of non-alert messages (Non-Alert Messages Summary), per Annex B,
|
||
Table B-3; and
|
||
d)
|
||
a summary report on the status of its Ground Segment equipment (Ground Segment
|
||
Status Summary).
|
||
3 This applies only to an MCC that has an associated LUT.
|
||
|
||
2-5
|
||
|
||
Other participating MCCs shall provide the host MCC with a summary report of their
|
||
own results, as necessary, noting only deficiencies which may warrant further
|
||
examination.
|
||
2.3.3
|
||
Ground Segment Status Summary
|
||
This is a general report prepared by the DMCC giving the status of its Ground Segment
|
||
equipment during the test and describing any unusual problems that might have affected
|
||
its performance, together with an assessment of its readiness to continue 24 hours per day
|
||
operations.
|
||
This report should include the confirmation that the DMCC is capable of meeting all of
|
||
the timing requirements of the MCC specification (document C/S A.005).
|
||
2.3.4
|
||
Performance Specifications Not Part of the Integration Test
|
||
In connection with the operational test, the DMCC shall declare that it is capable of
|
||
performing the responsibilities listed in document C/S A.005 that are not part of the
|
||
operational test. The declaration shall be sent to the host MCC which shall compare it to
|
||
the operational test results as applicable. Any follow up questions from the host MCC
|
||
shall be answered by the DMCC. The host MCC shall include the DMCC declaration
|
||
together with its own comments, in its report on the commissioning test.
|
||
2.3.5
|
||
Analysis
|
||
Upon receipt of the above data, the Host MCC shall examine it to determine whether the
|
||
DMCC meets the criteria as outlined in documents C/S A.001, C/S A.002, C/S A.003,
|
||
and C/S A.005. This analysis will involve the DMCC and other MCCs, as necessary. If
|
||
deficiencies are noted, the DMCC shall correct these deficiencies and notify the host
|
||
MCC when it is ready to repeat the relevant portion of the integration test.
|
||
2.3.6
|
||
MCC Commissioning Report
|
||
The DMCC shall prepare the preliminary MCC Commissioning Report using the data
|
||
gathered for analysis. The Report shall be prepared according to the format provided in
|
||
Annex C and forwarded to the host MCC for review and completion. The host MCC shall
|
||
complete the Report and forward it to the Secretariat prior to the date the DMCC is
|
||
expected to achieve Full Operational Capability (FOC), for consideration at the next Joint
|
||
Committee meeting.
|
||
2.4
|
||
Commissioning of New MCCs
|
||
When the integration test is completed and accepted by the host MCC and the procedure of the
|
||
formal association of the new Ground Segment Provider has been completed, the DMCC is
|
||
considered operational in an Initial Operational Capability (IOC). The host MCC shall advise other
|
||
|
||
2-6
|
||
|
||
Ground Segment operators of the change in status in accordance with document C/S A.001, using
|
||
the format specified in Annex H of this document.
|
||
The host MCC, through its designated Agency, shall forward the "MCC Commissioning Report"
|
||
to the Cospas-Sarsat Secretariat and recommend that the DMCC be commissioned. The report will
|
||
be reviewed by the Joint Committee and approved by the Cospas-Sarsat Council at their next
|
||
meeting to formally confirm that the new MCC is commissioned in the Cospas-Sarsat System, and
|
||
to direct the Secretariat to update the document C/S A.001 and the Cospas-Sarsat website.
|
||
However, the new MCC will be allowed to operate in the Cospas-Sarsat System in the IOC and
|
||
FOC status under the responsibility of the Ground Segment Provider at the IOC/FOC dates
|
||
confirmed by the host MCC, independent of the dates of the next Joint Committee and Council
|
||
meetings.
|
||
During the Initial Operational Capability phase, the new MCC will participate in all Cospas-Sarsat
|
||
Ground Segment operations as a fully functional MCC. The only limitation placed on the new
|
||
MCC’s operation during the IOC phase is that the service area of the new MCC is limited to its
|
||
national search and rescue region. However, the Ground Segment Provider of the new MCC will
|
||
ensure that the LUT commissioning tests have been completed, and the LUT commissioning report
|
||
has been forwarded to the Secretariat, as applicable, before distributing the LUT alert data in the
|
||
Cospas-Sarsat System when the new MCC attains IOC status.
|
||
If no significant problems are discovered during the IOC phase, the new MCC will normally
|
||
assume Full Operational Capability (FOC), including the servicing of its service area as
|
||
coordinated in accordance with Annex F to this document, at the FOC date. The FOC date is
|
||
automatically set at the IOC date plus 90 days, or as agreed with the Joint Committee prior to
|
||
integration testing. The IOC phase can be extended by up to an additional nine months, if problems
|
||
are discovered during the operation of the MCC.
|
||
If the MCC is not able to transition to FOC at the end of the one-year period, the new MCC will
|
||
be considered not operational and will be documented as “under development”. When the new
|
||
MCC is ready to be reintegrated into the System it must retest the elements that prevented it from
|
||
reaching FOC status and again operate in an IOC phase until it is ready to reach FOC. The host
|
||
MCC will ensure that the MCC commissioning report has been completed and forwarded to the
|
||
Secretariat for submission to the Joint Committee before confirming the FOC date of the new
|
||
MCC.
|
||
At Full Operational Capability date, the new MCC shall confirm to SPOCs in its service area, all
|
||
MCC operators and the Cospas-Sarsat Secretariat, its change of status.
|
||
The complete commissioning process is represented in Figure 2.1, and the evolution from IOC to
|
||
FOC status is described at Step D of Annex A "Guidelines for Integration of New MCCs in the
|
||
Cospas-Sarsat System".
|
||
|
||
2-7
|
||
|
||
2.5
|
||
Recommissioning of a Previously Commissioned MCC
|
||
A commissioned MCC shall be commissioned again in the following circumstances:
|
||
•
|
||
it has significantly upgraded its hardware, software or communications,
|
||
•
|
||
it has been declared “commissioned, not operational” (CNO), as defined in document
|
||
C/S A.003, or
|
||
•
|
||
there has been a major change in the MCC specification that requires a recommissioning of
|
||
previously commissioned MCCs; for example, the introduction of MEOSAR capability.
|
||
When an MCC that requires recommissioning is ready for recommissioning, it shall undergo a set
|
||
of commissioning tests as determined by the associated nodal MCC (which is normally the backup
|
||
nodal MCC if the upgraded MCC is itself a nodal MCC), to verify that it complies with the
|
||
requirements of document C/S A.005 and other associated documents. The nodal MCC, or the
|
||
backup nodal MCC if the upgraded MCC is itself a nodal MCC, shall decide what constitutes a
|
||
significant upgrade. If the upgraded MCC maintains an “operational” status, it shall continue to
|
||
distribute alert data to its associated SPOCs, unless the associated nodal MCC determines that
|
||
continued distribution poses a significant risk that the associated SPOCs will not receive timely,
|
||
reliable alerts.
|
||
The associated nodal MCC shall determine the set of commissioning tests to be conducted, based
|
||
on the scope of changes in the upgraded MCC, or, in the case of an MCC that had been declared
|
||
“commissioned, not operational”, the nature of the failure(s) that caused the MCC to be declared
|
||
non-operational. Results of the commissioning tests shall be reported by the upgraded MCC and
|
||
the associated nodal MCC, following the established procedures for commissioning a new MCC.
|
||
Depending on the condition(s) that warranted recommissioning, the associated nodal MCC should
|
||
also perform tests to assess the continued capability of the operators of the CNO MCC to perform
|
||
the functions detailed in Annex G of this document and should obtain a renewed declaration on
|
||
operator capability from the CNO MCC.
|
||
After the commissioning tests have been successfully completed, the tested MCC shall be declared
|
||
at Initial Operational Capability (IOC) and then upgraded to Full Operational Capability (FOC),
|
||
following the same procedure as has been established for a new MCC. The duration of the period
|
||
of IOC shall be determined by the nodal MCC, based on the condition(s) that warranted
|
||
recommissioning, and on the duration of the period of non-operational status.
|
||
When a commissioned MCC upgrades its software solely to comply with modified MCC
|
||
requirements, the upgraded MCC need not be commissioned again, unless the Cospas-Sarsat
|
||
Council has decided that a new commissioning is needed for those modified requirements.
|
||
2.6
|
||
Change of Location of a Commissioned MCC
|
||
If the location of a commissioned MCC is changed, the responsible national Administration shall
|
||
ensure that the MCC satisfies the requirements of document C/S A.005 prior to resuming
|
||
|
||
2-8
|
||
|
||
operations. Additionally, the national Administration shall submit to the Cospas-Sarsat Secretariat
|
||
an amendment to the MCC commissioning report detailing the new location of the MCC, a
|
||
description of the primary and backup communications to associated LUTs and other MCCs, and
|
||
a declaration that the MCC satisfies all C/S A.005 requirements.
|
||
|
||
2-9
|
||
|
||
Figure 2-1: MCC Commissioning Procedure
|
||
- END OF SECTION 2 –
|
||
DMCC’s (1) National
|
||
Administration
|
||
Expresses Intent to
|
||
Join the Program
|
||
HMCC(2) is Identified
|
||
DMCC Completes
|
||
Description of Ground
|
||
Segment and Service Area
|
||
Cospas-Sarsat
|
||
Secretariat
|
||
HMCC
|
||
Cospas-Sarsat Secretariat
|
||
Prepares Updates to the
|
||
DDP
|
||
DMCC and HMCC
|
||
Develop Commissioning
|
||
Plan
|
||
Commissioning
|
||
Test
|
||
DMCC and HMCC
|
||
Perform Pre-Integration
|
||
Test
|
||
DMCC
|
||
Operates in
|
||
Accordance with
|
||
C/S A.005?
|
||
No
|
||
HMCC Ensures that DMCC’s Formal
|
||
Association is Complete
|
||
DMCC
|
||
Reaches IOC
|
||
DMCC
|
||
Reaches FOC
|
||
Cospas-Sarsat Secretariat
|
||
Distributes Updates to the
|
||
DDP
|
||
DMCC Develops
|
||
Commissioning Report
|
||
HMCC Reviews and Completes
|
||
Commissioning Report
|
||
HMCC Submits Report to Joint
|
||
Committee
|
||
Joint Committee Reviews
|
||
Report and Recommends
|
||
Commissioning
|
||
Cospas-Sarsat Council
|
||
Approves
|
||
Commissioning
|
||
DMCC is Formally
|
||
Commissioned in Cospas-
|
||
Sarsat
|
||
Yes
|
||
(1) DMCC = MCC Under Development
|
||
(2) HMCC = Host MCC
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
3-1
|
||
|
||
ESTABLISHMENT OF NEW NODAL MCCS
|
||
3.1
|
||
Principles for Establishing New Nodal MCCs
|
||
The implementation of a new nodal MCC in the Cospas-Sarsat System may significantly affect
|
||
existing MCCs and nodal MCCs, requiring extensive coordination with all affected MCCs/nodal
|
||
MCCs, software changes and possibly new communication links with existing nodal MCCs.
|
||
Therefore, the establishment of a new nodal MCC will be considered only if:
|
||
a)
|
||
a need for improving the Cospas-Sarsat data distribution system is recognized by the Cospas-
|
||
Sarsat Council; the improvement may be achieved as a result of enhancing the reliability of
|
||
data distribution, enhancing the effectiveness of data distribution or reducing the workload
|
||
on an existing nodal MCC;
|
||
b)
|
||
an existing MCC is prepared to accept the responsibility of a nodal MCC for the new Data
|
||
Distribution Regions (DDRs) to be implemented; and
|
||
c)
|
||
the proposed new nodal MCC can provide all nodal functions for at least one other MCC in
|
||
the new DDR.
|
||
Note that all nodal MCCs must be previously commissioned MCCs that are fully capable of
|
||
processing data from the LEOSAR, GEOSAR and MEOSAR systems (that is, they must be
|
||
LEOSAR–GEOSAR-MEOSAR-capable, LGM MCCs).
|
||
3.2
|
||
Preliminary Actions
|
||
The following actions should be accomplished before a final decision can be made in the Council
|
||
to proceed with the implementation of a new nodal MCC:
|
||
a)
|
||
the Joint Committee assesses the need to improve the exchange of alert and System data
|
||
between MCCs in the Cospas-Sarsat System using the guidelines provided in Annex D;
|
||
b)
|
||
the Joint Committee assesses the capabilities of existing MCCs and makes a
|
||
recommendation to Council on the practical options for developing a new nodal MCC;
|
||
c)
|
||
the Joint Committee recommends to Council that such improvement should be pursued with
|
||
establishing one (or several) additional DDR(s);
|
||
d)
|
||
the Council approves the Joint Committee recommendation(s);
|
||
e)
|
||
after approval by the Council and acceptance by the proposed new nodal MCC(s), the Joint
|
||
Committee identifies:
|
||
•
|
||
the new DDR(s) associated with the new nodal MCC(s),
|
||
•
|
||
the new structure of the inter-regional data distribution network; and
|
||
|
||
|
||
|
||
3-2
|
||
|
||
f)
|
||
the Council approves the new DDR(s) and the inter-regional network structure.
|
||
3.3
|
||
Regional Coordination and Commissioning Plan
|
||
3.3.1
|
||
Regional Coordination
|
||
The new nodal MCC shall coordinate all commissioning activities with assistance from
|
||
the host nodal MCC before the new nodal MCC begins commissioning tests.
|
||
The Commissioning Plan can be coordinated through bi-lateral contacts. However, a
|
||
regional meeting of all MCCs in the DDR and the host nodal MCC is recommended to
|
||
develop and finalize the Commissioning Plan.
|
||
3.3.2
|
||
Commissioning Plan
|
||
The new nodal MCC shall analyse the additional requirements for a nodal MCC and
|
||
ensure that they can be met. These requirements should include hardware enhancements,
|
||
software enhancements and communication links at regional and inter-regional levels as
|
||
required.
|
||
The new nodal MCC, in cooperation with the host nodal MCC, shall develop a
|
||
Commissioning Plan that is coordinated with all MCCs involved in the commissioning
|
||
process. The Commissioning Plan shall contain the following information as a minimum:
|
||
a)
|
||
procedures and schedule for connecting MCCs to the new nodal MCC and, if
|
||
necessary, for connecting the new nodal MCC to other nodal MCCs;
|
||
b)
|
||
roles of participants;
|
||
c)
|
||
a description of the tests to be performed;
|
||
d)
|
||
a test schedule;
|
||
e)
|
||
data collection requirements for participants; and
|
||
f)
|
||
backup arrangements for the new nodal MCC.
|
||
3.4
|
||
Commissioning of New Nodal MCCs
|
||
3.4.1
|
||
General
|
||
The new nodal MCC commissioning will involve testing communication links and
|
||
exchange of test specific and alert data through the new nodal MCC. The intent of the
|
||
commissioning process is to test alert data and System information distribution
|
||
procedures including geographical sorting of alerts and specific nodal requirements
|
||
outlined in document C/S A.005, section 6 (Specifications for Nodal MCCs). The
|
||
operational, functional, and performance requirements contained in document C/S A.005,
|
||
sections 3 (Operational Requirements), 4 (Functional Requirements), and 5 (Performance
|
||
Requirements) are not to be included in the commissioning tests for a new nodal MCC.
|
||
|
||
3-3
|
||
|
||
3.4.2
|
||
Pre-test Coordination
|
||
It is the responsibility of the host nodal MCC to notify all MCCs regarding the start of
|
||
the commissioning test. The notification shall include information on the schedule of
|
||
tests, the number and identification of test beacons and any special processing required.
|
||
The host nodal MCC, new nodal MCC and one of the MCCs in the DDR shall modify
|
||
their MCC software for geographical sorting of alerts, communications addresses and/or
|
||
links in order to begin commissioning tests.
|
||
3.4.3
|
||
Test Requirements
|
||
During the commissioning tests, the new nodal MCC shall be capable of:
|
||
a)
|
||
receiving, filtering and transmitting alert data to/from the MCC(s) in its DDR and
|
||
to/from the host nodal MCC;
|
||
b)
|
||
receiving and transmitting System data within the DDR and between DDRs;
|
||
c)
|
||
verifying and validating System data;
|
||
d)
|
||
meeting nodal MCC requirements outlined in document C/S A.005; and
|
||
e)
|
||
demonstrating the functionality of backup arrangements identified in the
|
||
Commissioning Plan or maintaining the option to return to the initial configuration
|
||
of the DDR on a temporary basis until such backup arrangements can be made.
|
||
During the tests, if any serious problems are noted by any participating MCCs, the host
|
||
nodal MCC will be notified and it shall assess whether the test should continue, be delayed
|
||
or be re-scheduled for a later date. If necessary, the initial configuration of the DDR
|
||
should be restored.
|
||
3.5
|
||
Nodal MCC Data Collection and Analysis
|
||
3.5.1
|
||
General
|
||
In order to facilitate the data analysis, the new nodal MCC shall collect test specific data
|
||
in accordance with sections C and D of Annex A to this document. Furthermore, each
|
||
participating MCC shall retain copies of all incoming and outgoing alert and system
|
||
messages and forward them to the host nodal MCC. Each participating MCC should
|
||
attempt to collect test specific data in accordance with sections C and D of Annex A.
|
||
3.5.2
|
||
New Nodal MCC Data Collection
|
||
The new nodal MCC shall provide all of the data described in section 2.3.24.
|
||
4 Note that the test alerts should include all of LEOSAR, GEOSAR and MEOSAR incident alert data, and should
|
||
include data from all types of Cospas-Sarsat distress beacons.
|
||
|
||
3-4
|
||
|
||
3.5.3
|
||
Performance Specifications Not Part of the Commissioning Tests
|
||
The new nodal MCC shall, in conjunction with the commissioning test, declare that it is
|
||
capable of performing the responsibilities listed in document C/S A.005 that are not part
|
||
of the commissioning tests. The declaration will be made to the host nodal MCC and if
|
||
possible verified by the host.
|
||
3.5.4
|
||
Analysis
|
||
The host nodal MCC will collect and analyse data from other MCCs, as necessary. The
|
||
data shall be analysed to ensure that the new nodal MCC meets the commissioning criteria
|
||
as outlined in document C/S A.005 and operates in accordance with document C/S A.001.
|
||
If any deficiencies are noted, the host nodal MCC will notify the new nodal MCC. After
|
||
the deficiencies are corrected, the relevant portions of the commissioning tests will be
|
||
repeated.
|
||
3.5.5
|
||
Nodal MCC Commissioning Report
|
||
After all the MCCs in the proposed DDR are integrated successfully, the new nodal MCC
|
||
will complete the nodal MCC commissioning report (provided as Annex E to this
|
||
document) and forward it to the host nodal MCC. The host nodal MCC will review the
|
||
report and forward it to the Cospas-Sarsat Secretariat.
|
||
3.6
|
||
Commissioning Procedure and Implementation
|
||
The new nodal MCC will connect to one other MCC within the proposed DDR and test alert and
|
||
system data distribution procedures. When tests with the first MCC have been successfully
|
||
completed, the host nodal MCC will declare the new nodal MCC at IOC. The host nodal MCC
|
||
shall advise all ground segment operators of the change in status in accordance with document
|
||
C/S A.001.
|
||
At IOC, the new nodal MCC is expected to provide the nodal functions for one MCC in the new
|
||
DDR. The new nodal MCC should then proceed with the testing and integration of the remaining
|
||
MCCs in the DDR as provided in the Commissioning Plan. Such changes should not affect other
|
||
nodal MCCs except the host nodal MCC.
|
||
If links to other nodal MCCs are required as per the Commissioning Plan, the new nodal MCC
|
||
will proceed with testing these links.
|
||
The new nodal MCC shall complete and forward the nodal MCC commissioning report to the host
|
||
nodal MCC. The host nodal MCC, through its designated agency, shall forward the nodal MCC
|
||
commissioning report to the Cospas-Sarsat Secretariat and recommend that the new nodal MCC
|
||
be commissioned. The report will be reviewed by the Joint Committee and, as appropriate,
|
||
approved by the Cospas-Sarsat Council at their next meeting.
|
||
|
||
3-5
|
||
|
||
The host nodal MCC will coordinate the FOC date for the new nodal MCC, with all nodal MCCs
|
||
involved, and inform all Ground Segment operators.
|
||
At the FOC date, all nodal MCCs involved will implement the new data exchange matrix and the
|
||
geographical sorting of alert data as provided in the document C/S A.001.
|
||
- END OF SECTION 3 –
|
||
|
||
A-1
|
||
|
||
ANNEX A
|
||
GUIDELINES FOR INTEGRATION OF NEW MCCs
|
||
IN THE COSPAS-SARSAT SYSTEM
|
||
1.
|
||
The material in this Annex is a textual flow-chart which sketches procedures for
|
||
integrating an MCC under development (DMCC) into the existing Cospas-Sarsat Ground
|
||
Segment.
|
||
2.
|
||
The introduction of new MCCs in the Cospas-Sarsat System is supervised by the Cospas-
|
||
Sarsat Joint Committee whose objectives include:
|
||
a)
|
||
to improve the overall coverage and performance of the Cospas-Sarsat Ground
|
||
Segment; and
|
||
b)
|
||
to maintain technical control of the development of the Cospas-Sarsat MCC
|
||
network.
|
||
3.
|
||
The purpose of these procedures is:
|
||
a)
|
||
to provide the Joint Committee with guidelines to manage and coordinate the
|
||
introduction of new MCCs into the existing Ground Segment; and
|
||
b)
|
||
to assist the DMCC in planning and performing the appropriate integration tests.
|
||
4.
|
||
Step A may be completed outside of Joint Committee meetings, if necessary. All this
|
||
information, albeit preliminary at times, should be sent directly to the Cospas-Sarsat
|
||
Secretariat.
|
||
5.
|
||
Step B should be conducted on a regional basis and, after agreement, be presented to the
|
||
Joint Committee for adoption.
|
||
6.
|
||
Step C and Step D should be conducted with the host MCC with which the DMCC is to
|
||
be aligned.
|
||
STEP A
|
||
Initial Ground Segment Description and LUT Coverage
|
||
Objective:
|
||
Preliminary information gathering to assist the Joint Committee in deciding how
|
||
the DMCC best fits into the existing System.
|
||
|
||
A-2
|
||
|
||
A-15
|
||
The Cospas-Sarsat Secretariat develops and updates the worldwide map of visibility areas
|
||
of LUTs in the Cospas-Sarsat System. The map should be a standard geographic
|
||
coordinate system showing the coverage areas of all operational LUTs.
|
||
A-25
|
||
The DMCC shall identify its new LUT(s) with: (1) coordinates, (2) address, (3)
|
||
frequencies and (4) LUT antenna mask(s).
|
||
A-35
|
||
With these coordinates, the Secretariat shall plot the new LUT coverage on a map
|
||
projection.
|
||
A-4
|
||
The DMCC shall propose its new service area, in accordance with the document
|
||
C/S P.011, “Cospas-Sarsat Programme Management Policy” and taking into account the
|
||
factors described in Step B below.
|
||
A-5
|
||
The DMCC shall provide information required to amend the Cospas-Sarsat website (SAR
|
||
points of contact, points of contact for 406-MHz beacon registers, MCCs and LUTs) and
|
||
document C/S A.001 (SID implementation status, regional (DDR) procedures or
|
||
arrangements). The information may be preliminary at times but should be kept updated.
|
||
STEP B
|
||
Assignment of Service Area and Message Distribution Procedures
|
||
Objective:
|
||
To determine the DMCC's responsibilities within the Cospas-Sarsat MCC network,
|
||
consistent with the goal of improving System performance.
|
||
B-1
|
||
The Joint Committee shall review the service area and the message routing assignments
|
||
for System information and alert data distribution, including regional procedures, if any.
|
||
The following factors should be taken into account when developing and reviewing the
|
||
service area of a new MCC:
|
||
a)
|
||
aeronautical, maritime and terrestrial regions in which the MCC's national
|
||
authorities facilitate or provide SAR services should become part of its MCC
|
||
service area;
|
||
b)
|
||
where practical, any Search and Rescue Region (SRR) will be entirely included
|
||
within the service area of a given MCC; and
|
||
c)
|
||
communications infrastructure: new service areas should maximize the efficiency
|
||
with which alert data can be delivered.
|
||
In the case where difficulties arise with the development of a new MCC's service area,
|
||
the following additional factors should be considered:
|
||
•
|
||
global communications capabilities,
|
||
5 These steps are only required for a new MCC with associated LUTs.
|
||
|
||
A-3
|
||
|
||
•
|
||
existing national SAR and bilateral/multilateral operational arrangements,
|
||
•
|
||
common SAR area boundaries,
|
||
•
|
||
common service area boundaries,
|
||
•
|
||
preferences declared by the country responsible for a SRR.
|
||
If agreement cannot be reached on the service area of a new MCC, the affected service
|
||
areas shall be established in accordance with document C/S P.011 (under “MCC Service
|
||
Areas”).
|
||
B-2
|
||
The DMCC shall identify and notify the Host MCC of the Search and Rescue Point of
|
||
Contact (SPOC) in each of the countries within its service area.
|
||
B-3
|
||
The DMCC shall identify and notify the Host MCC of the SSAS Competent Authority in
|
||
each of the countries within its service area.
|
||
B-4
|
||
The Joint Committee shall select or review the prior selection of a host MCC, taking into
|
||
account, among others, the following operational factors:
|
||
•
|
||
geographical location and north/south structure of the network,
|
||
•
|
||
global communications capabilities,
|
||
•
|
||
national SAR arrangements,
|
||
•
|
||
bilateral operational agreements,
|
||
•
|
||
common service area boundaries,
|
||
•
|
||
common SAR area boundaries.
|
||
B-5
|
||
The Joint Committee shall review the service area of the DMCC to ensure that the service
|
||
area is consistent with document C/S P.011. Based on the declared service area and host
|
||
MCC selection, the Joint Committee shall review the message routing assignments for
|
||
System information and alert data distribution, including regional procedures, if any, and
|
||
agree the appropriate amendments of the document C/S A.001 and of the Cospas-Sarsat
|
||
website.
|
||
B-6
|
||
Prior to the integration test, the DMCC shall establish bilateral communication checks,
|
||
message distribution and test procedures with each Cospas-Sarsat MCC with which it will
|
||
exchange data operationally. This test shall demonstrate correct message formatting using
|
||
the required message fields.
|
||
STEP C
|
||
Integration Test
|
||
|
||
A-4
|
||
|
||
Objective:
|
||
To test the DMCC's operational readiness and compliance with Ground
|
||
Segment requirements.
|
||
Recommendation: Experience of DMCCs and host MCCs implementing the procedures outlined
|
||
in this document has shown the considerable value of a detailed bi-lateral
|
||
meeting over two or three days, if necessary, held prior to the integration test.
|
||
This meeting should endeavour to develop a complete script of the integration
|
||
test, clarify all aspects of the procedures, and define the methods and points
|
||
of contact for the resolution of incidents during the integration testing and the
|
||
necessary coordination of activities after the DMCC Initial Operational
|
||
Capability has been established.
|
||
C-1
|
||
Prior to the integration test, the DMCC shall state to the host MCC that it complies with
|
||
all applicable Ground Segment requirements as defined in Cospas-Sarsat System
|
||
documents and is prepared to initiate operational integration into the Cospas-Sarsat MCC
|
||
network.
|
||
C-2
|
||
The DMCC shall give as much notice as possible to the host MCC when planning its
|
||
integration test. The integration test should be completed as soon as possible.
|
||
C-3
|
||
All MCCs scheduled to interface with the DMCC, as specified in Step B, shall participate
|
||
in the test.
|
||
C-4
|
||
During the test, the DMCC shall exchange data with the host MCC (HMCC) (and other
|
||
participating MCCs) as if it were an “operational MCC”. However, the integration test
|
||
shall not impact the distribution of operational alert data as per the current DDP.
|
||
Therefore, only the DMCC shall use the modified sections of document C/S A.001 during
|
||
the test. In addition, the HMCC shall filter alert data received from the DMCC so that it
|
||
is not distributed in the operational MCC network.
|
||
C-5
|
||
At the conclusion of the test, the DMCC and each participating MCC shall evaluate the
|
||
test results in accordance with the procedures, formats and requirements specified in the
|
||
System documentation. Each participating MCC shall notify the DMCC of any
|
||
deficiencies in complying with Ground Segment requirements.
|
||
C-6
|
||
The DMCC shall correct its deficiencies, if any, and notify the host MCC its readiness
|
||
for repeating the relevant portion of the integration test. The host MCC shall determine
|
||
and coordinate the schedule of the new test and, if successful, shall declare the DMCC
|
||
operational.
|
||
C-7
|
||
The DMCC shall prepare the preliminary “MCC Commissioning Report” and forward to
|
||
the host MCC for review and completion.
|
||
|
||
A-5
|
||
|
||
STEP D
|
||
Establishment of Initial and Full Operational Capability
|
||
Objective:
|
||
To start operation at the Initial Operational Capability (IOC) date and assume Full
|
||
Operational Capability (FOC) at the pre-determined FOC date.
|
||
Remark:
|
||
Before confirming the DMCC IOC status, the host MCC shall assure itself that:
|
||
a)
|
||
the procedure for the formal association of the Ground Segment Provider (or
|
||
the Ground Segment Operator) with the Cospas-Sarsat Programme has been
|
||
completed; and
|
||
b)
|
||
all tests required for the integration of the DMCC in the Cospas-Sarsat
|
||
Ground Segment have been successfully completed.
|
||
The FOC date of the new Cospas-Sarsat MCC is automatically set at IOC date plus
|
||
90 days. If confirmation of IOC status is delayed, the FOC date will be postponed
|
||
by the same amount of time. MCCs which have not reached FOC within one year
|
||
of the initial IOC date will be considered not operational, documented as “Under
|
||
Development,” and will require a retest of the elements which prevented it from
|
||
reaching FOC. The MCC then must operate in an IOC phase again prior to reaching
|
||
FOC.
|
||
D-1
|
||
When the integration test is completed, and no significant deficiencies are noted by the
|
||
host MCC, the DMCC is ready for operation in an Initial Operational Capability. The
|
||
DMCC may operate in an Initial Operational Capability with minor deficiencies, as
|
||
determined by the host MCC, provided that the DMCC agrees to fix these deficiencies
|
||
prior to FOC.
|
||
D-2
|
||
During IOC phase, the new MCC is permitted to participate in all Cospas-Sarsat Ground
|
||
Segment operations (i.e., exchange of alert data and System information through the
|
||
Cospas-Sarsat MCC network). However, the service area of a new MCC at IOC is limited
|
||
to its national search and rescue region. Requirements in respect of the service area of a
|
||
previously commissioned MCC are described in section 2.5.
|
||
D-3
|
||
The host MCC shall notify all Ground Segment operators of the new MCC IOC status
|
||
(Annex H) and confirm the tentative date for Full Operational Capability. Prior to FOC,
|
||
the new MCC shall ensure that it has established appropriate arrangements with SPOCs
|
||
in its service area for the distribution of alert data. At FOC date, the updated data
|
||
distribution procedures contained in document C/S A.001 will be implemented.
|
||
D-4
|
||
At Full Operational Capability date, the new MCC assumes all its operational
|
||
responsibilities, including servicing its service area as determined under Step B. The new
|
||
MCC shall confirm to SPOCs in its service area, all MCC operators and the Secretariat,
|
||
its change of status at FOC date.
|
||
|
||
A-6
|
||
|
||
D-5
|
||
Prior to FOC date, the host MCC, through its designated Agency, shall forward the "MCC
|
||
Commissioning Report" to the Cospas-Sarsat Secretariat and recommend commissioning
|
||
of the new MCC. The report shall be reviewed by the Joint Committee and, as appropriate,
|
||
forwarded to the Cospas-Sarsat Council with a recommendation for approval by the
|
||
Council at their next meetings.
|
||
STEP E
|
||
Limited Re-Commissioning of an MCC
|
||
Objective:
|
||
To continue or resume operation at the Initial Operational Capability (IOC) date
|
||
and assume Full Operational Capability (FOC) at the pre-determined FOC date.
|
||
Remark:
|
||
This describes the actions to be taken after the DMCC has been out of service for
|
||
an extended period of time, or after a major upgrade of the DMCC hardware or
|
||
software has been performed.
|
||
The FOC date of the upgraded or restored Cospas-Sarsat MCC is automatically set
|
||
at IOC date plus90 days. If confirmation of IOC status is delayed, the FOC date will
|
||
be postponed by the same amount of time. MCCs which have not reached FOC
|
||
within one year of the declared IOC date will be considered not operational,
|
||
documented as “Under Development,” and will require a retest of the elements
|
||
which prevented it from reaching FOC. The DMCC then must operate in an IOC
|
||
phase again prior to reaching FOC.
|
||
E-1
|
||
If an MCC is out of service for an extended period of time, or if a major upgrade of the
|
||
MCC hardware or software is performed, then the MCC may have to undergo a limited
|
||
re-commissioning. In general, the re-commissioning will consist of a subset of the tests
|
||
that are described in this Commissioning Standard. The extent of the commissioning tests
|
||
to be performed will be established by the associated nodal MCC, taking into account the
|
||
nature of the reasons for the MCC being out of service or the nature of the upgrade that
|
||
has been performed.
|
||
E-2
|
||
When the integration test is completed, and no significant deficiencies are noted by the
|
||
host MCC, the DMCC is ready for operation in an Initial Operational Capability. The
|
||
DMCC may operate in an Initial Operational Capability with minor deficiencies, as
|
||
determined by the host MCC, provided that the DMCC agrees to fix these deficiencies
|
||
prior to FOC.
|
||
|
||
B-1
|
||
|
||
ANNEX B
|
||
FORMAT FOR REPORTING DMCC TEST DATA
|
||
For the commissioning of any MCC, report data in accordance with Tables B-1 to B-3. Note that
|
||
Table B-1 should address the LUTs that are the primary sources of data for the DMCC during the
|
||
commissioning tests. It does not have to be a LUT that is associated with the DMCC.
|
||
1Table B-1: LUT Summary Database
|
||
Field
|
||
Description
|
||
Detailed Format
|
||
|
||
LUT identifier (see C/S A.002)
|
||
nnnn
|
||
|
||
Spacecraft identifier (see C/S A.002)
|
||
nnn
|
||
|
||
LEOLUT AOS
|
||
GEOLUT data collection start time
|
||
MEOLUT data collection start time
|
||
YYDDDhhmm
|
||
|
||
LEOLUT LOS
|
||
GEOLUT data collection end time
|
||
MEOLUT data collection end time
|
||
YYDDDhhmm
|
||
|
||
LEOLUT Time Processing Complete
|
||
(n/a for MEOLUT or GEOLUT)
|
||
YYDDDhhmm
|
||
|
||
Time MCC completed processing of LEOSAR
|
||
pass
|
||
Time MCC completed processing of MEOSAR
|
||
or GEOSAR data
|
||
YYDDDhhmm
|
||
|
||
Number of solutions with independent locations,
|
||
not including ELT(DT) solutions
|
||
nnnn
|
||
|
||
Number of solutions with no independent
|
||
location, including all ELT(DT) solutions
|
||
nnnn
|
||
|
||
Comments
|
||
AAAAAAAA
|
||
|
||
B-2
|
||
|
||
2Table B-2: Alert Data Summary Database
|
||
Field
|
||
Description
|
||
Detailed Format
|
||
|
||
Source identifier (LUT or MCC)
|
||
(see C/S A.002)
|
||
nnnn
|
||
|
||
Beacon location (Nearest town or sea area) (if
|
||
available)
|
||
AAAAAAAAAAA
|
||
|
||
Beacon identifier
|
||
(15-Hex ID (FGB) or 23-Hex ID (SGB)
|
||
padded on the right with blanks)
|
||
AAAAAAAAAAAAAAAAAAA
|
||
AAAA
|
||
|
||
Spacecraft identifier (see C/S A.002)
|
||
nnn
|
||
|
||
Calculated TCA (if no Doppler location, use
|
||
time of first data point.)
|
||
YYDDDhhmm
|
||
|
||
Input message number (“0” if not available)
|
||
nnnnn
|
||
|
||
Source of message (see C/S A.002)
|
||
nnnn
|
||
|
||
Receipt time
|
||
YYDDDhhmm
|
||
|
||
MCC Time Processing Complete
|
||
YYDDDhhmm
|
||
|
||
Processing Disposition Code:
|
||
ab - for data processed for output
|
||
PR – NOCR
|
||
PP - passed for output/located
|
||
PV - passed for output/unlocated
|
||
PM - merged for output
|
||
ab - for data suppressed
|
||
SR - redundant/located
|
||
SV - redundant/unlocated
|
||
SN - suppressed national procedure
|
||
SM - suppressed/merged
|
||
SO - suppressed other reason
|
||
Fields 11 - 14 are used only if solution is
|
||
processed for output.
|
||
AA
|
||
|
||
Output message number
|
||
nnnnn
|
||
|
||
Transmit time
|
||
YYDDDhhmm
|
||
|
||
Output message SIT number
|
||
(see C/S A.002)
|
||
nnn
|
||
|
||
Destination
|
||
AAAA
|
||
|
||
Doppler A or DOA MCC Service Area
|
||
AAAA
|
||
|
||
B-3
|
||
|
||
Field
|
||
Description
|
||
Detailed Format
|
||
|
||
Doppler A or DOA latitude
|
||
snn.nnn
|
||
|
||
Doppler A or DOA longitude
|
||
snnn.nnn
|
||
|
||
Doppler B MCC Service Area
|
||
AAAA
|
||
|
||
Doppler B latitude
|
||
snn.nnn
|
||
|
||
Doppler B longitude
|
||
snnn.nnn
|
||
|
||
DOA altitude (km)
|
||
snn.nnn
|
||
|
||
Solution mode:
|
||
L=local (LEOSAR or GEOSAR)
|
||
G=global (LEOSAR)
|
||
S=single burst (MEOSAR)
|
||
M=multi-burst (MEOSAR)
|
||
A
|
||
|
||
Encoded position MCC Service Area
|
||
AAAA
|
||
|
||
Encoded position latitude
|
||
snn.nnn
|
||
|
||
Encoded position longitude
|
||
snnn.nnn
|
||
|
||
Encoded position altitude (km)
|
||
snn.nnn
|
||
|
||
Beacon type:
|
||
F=First-Generation
|
||
E=FGB ELT(DT)
|
||
A=SSAS
|
||
S=Second-Generation
|
||
T=SGB ELT(DT)
|
||
A
|
||
|
||
Alert type:
|
||
D=Distress
|
||
T=Distress Tracking
|
||
R=Return Link Service/Two-Way
|
||
Communication request
|
||
S=Ship Security Alert
|
||
A
|
||
|
||
Comments
|
||
AAAAAAAA
|
||
|
||
B-4
|
||
|
||
3Table B-3: Non-Alert Message Summary Database
|
||
Field
|
||
Description
|
||
Detailed Format
|
||
|
||
Source
|
||
nnnn
|
||
|
||
Destination
|
||
nnnn
|
||
|
||
Message Number
|
||
nnnnn
|
||
|
||
SIT Number
|
||
nnn
|
||
|
||
Time received / sent
|
||
YYDDDhhmm
|
||
|
||
Comments
|
||
AAAAAAAA
|
||
- END OF ANNEX B -
|
||
|
||
C-1
|
||
|
||
ANNEX C
|
||
MCC COMMISSIONING REPORT
|
||
Country or national Administration:
|
||
_______________
|
||
Location of MCC:
|
||
_______________
|
||
Cospas-Sarsat Identifier:
|
||
_______________
|
||
Start of Commissioning Period:
|
||
_______________
|
||
End of Commissioning Period:
|
||
_______________
|
||
Section 1 contains information on the communication links established by the DMCC. Section 2
|
||
contains the summary tables with the commissioning results, where the Method of Compliance is
|
||
one or more of:
|
||
•
|
||
declaration by the national Administration (D),
|
||
•
|
||
verification by the host MCC (V),
|
||
•
|
||
verification by the national Administration (Vn),
|
||
•
|
||
measurement by the host MCC (M), or
|
||
•
|
||
measurement by the national Administration (Mn).
|
||
Where the method of compliance is listed as verification, evidence of that verification shall be
|
||
included in the data package that is submitted to the Cospas-Sarsat Secretariat with the MCC
|
||
Commissioning Report. Section 3 contains a summary of SIT messages exchanged. Section 4
|
||
contains explanatory comments necessary to amplify the results contained in the summary tables
|
||
of section 2. Section 5 contains any other relevant information concerning the conduct of the
|
||
commissioning test, while section 6 contains the recommendations of the host MCC towards the
|
||
commissioning of the MCC under test.
|
||
1.
|
||
COMMUNICATION LINKS
|
||
Provide information on each link that will be used operationally by the DMCC, to LUTs, RCCs,
|
||
SPOCs, SSAS Competent Authorities, the Location of an Aircraft in Distress Repository (LADR),
|
||
Return Link Service Providers (RLSPs), Two-Way-Communication Service Providers (TWC-
|
||
SPs), and other MCCs. The destination type is to be identified (in brackets) below the destination
|
||
name. Include links required to backup other MCCs.
|
||
|
||
C-2
|
||
|
||
4Table C-1: Communications Links
|
||
Destination
|
||
Name
|
||
(and Type)
|
||
Network
|
||
Type
|
||
(e.g., FTP)
|
||
Link Address
|
||
Direction of Data to
|
||
DMCC
|
||
(Input, Output, Both)
|
||
Pass/
|
||
Fail
|
||
Comments
|
||
2.
|
||
SUMMARY TABLES
|
||
5Table C-2: Operational Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.1 General Operations
|
||
3.1.1
|
||
Establish procedures for alert
|
||
data distribution
|
||
n/a
|
||
D
|
||
3.1.2
|
||
Respond to request for
|
||
information
|
||
V
|
||
Detailed specific tests are documented
|
||
in C/S A.005, sections 3.9 and 3.10.
|
||
3.1.3
|
||
Account for all messages
|
||
D/V
|
||
Limited verification by HMCC
|
||
3.1.4
|
||
Validate received messages
|
||
D
|
||
3.1.5
|
||
Configurable to selectively
|
||
process or suppress alert data
|
||
V
|
||
Addressed in section 4.3 of C/S A.005.
|
||
See note 6
|
||
3.1.6
|
||
Voice communication with
|
||
other MCCs
|
||
V
|
||
3.1.7
|
||
Transmit solution data for
|
||
reference beacons designated
|
||
for QMS from LEOLUTs
|
||
V
|
||
This requirement only applies if the
|
||
MCC has an associated LEOLUT
|
||
3.1.8
|
||
Transmit solution data for
|
||
reference beacon designated for
|
||
QMS from GEOLUTs
|
||
V
|
||
This requirement only applies if the
|
||
MCC has an associated GEOLUT
|
||
6 Each Central Data Distribution Region (CDDR) MCC shall demonstrate the ability to process alert messages
|
||
provided by CDDR LEOLUTs with Doppler data and CDDR MEOLUTs with DOA data based only on the 406
|
||
MHz beacon message when an accuracy ratio falls below the associated “red” threshold defined in document
|
||
C/S A.003 (in document C/S A.003, see subsections entitled “Unreliable Alert Data Filtering” in “LEOLUT
|
||
Location Accuracy Assessment, Status Reporting and Follow-up Actions” and “MEOLUT Location Accuracy” in
|
||
“MEOLUT Assessment, Status Reporting and Follow-up Actions”).
|
||
|
||
C-3
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.1.9
|
||
Transmit solution data for
|
||
reference beacon designated for
|
||
QMS from MEOLUTs
|
||
V
|
||
This requirement only applies if the
|
||
MCC has an associated MEOLUT
|
||
3.2 Availability
|
||
3.2
|
||
Operational 24/7 with people
|
||
available to respond, as needed
|
||
24-hour
|
||
availability
|
||
D/V
|
||
Limited verification by HMCC
|
||
3.3 LUT Co-ordination
|
||
3.3.1
|
||
Process associated LUT data
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.3.2
|
||
Transmit System data to LUT
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.4 Data Communication
|
||
3.4.1
|
||
Internal communication links
|
||
n/a
|
||
n/a
|
||
n/a
|
||
n/a
|
||
3.4.5
|
||
Distribute ELT(DT) alert data to
|
||
the LADR
|
||
C/S A.005
|
||
V
|
||
Only applicable for nodal MCCs.
|
||
Limited verification by the HMCC
|
||
3.4.6
|
||
Use of communication networks
|
||
defined in C/S A.002
|
||
V
|
||
3.4.6
|
||
Receive messages in non-SIT
|
||
format
|
||
V
|
||
3.4.7
|
||
Communication links as defined
|
||
in C/S A.001
|
||
V
|
||
3.4.7
|
||
Maintain at least two
|
||
international networks
|
||
V
|
||
3.4.7
|
||
Bilateral agreements with other
|
||
MCCs
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Describe, if any
|
||
3.4.8
|
||
Communication links with
|
||
SPOCs in service area
|
||
D
|
||
3.4.9
|
||
Access to two communication
|
||
links recommended
|
||
Via national
|
||
SAR
|
||
authority if
|
||
necessary
|
||
D
|
||
|
||
C-4
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.4.9
|
||
Communication links
|
||
documented in C/S A.001
|
||
V
|
||
3.4.10
|
||
Communications use standards
|
||
and protocols in C/S A.002
|
||
D/V
|
||
Limited verification by HMCC
|
||
3.4.11
|
||
Communications links and
|
||
networks operate
|
||
simultaneously
|
||
D
|
||
|
||
C-5
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.5 Data Formats
|
||
3.5.1
|
||
Internal data formats
|
||
n/a
|
||
n/a
|
||
n/a
|
||
n/a
|
||
3.5.2
|
||
Use formats from C/S A.002
|
||
C/S A.002
|
||
V
|
||
See
|
||
the
|
||
section
|
||
entitled
|
||
“Data
|
||
Communication
|
||
Facilities”
|
||
of
|
||
document C/S A.002;
|
||
section 3 of this Commissioning
|
||
Report
|
||
contains
|
||
counts
|
||
of
|
||
SIT
|
||
messages exchanged
|
||
3.5.3
|
||
Send or receive every SIT
|
||
message format
|
||
C/S A.002
|
||
V
|
||
See
|
||
the
|
||
section
|
||
entitled
|
||
“Data
|
||
Communication
|
||
Facilities”
|
||
of
|
||
document C/S A.002;
|
||
section 3 of this Commissioning
|
||
Reports contains counts of SIT
|
||
messages exchanged
|
||
3.5.4
|
||
Receive and verify LEOSAR
|
||
orbit vectors and SARP
|
||
calibration data
|
||
C/S A.002
|
||
V
|
||
3.5.4
|
||
Send orbit vectors and SARP
|
||
calibration to LEOLUTs
|
||
C/S A.002
|
||
V
|
||
This requirement only applies if the
|
||
MCC has an associated LEOLUT
|
||
3.5.4
|
||
Receive and verify MEOSAR
|
||
orbit vectors
|
||
C/S A.002
|
||
V
|
||
3.5.5
|
||
Process spacecraft (system)
|
||
messages
|
||
C/S A.005
|
||
V
|
||
Only applicable for Space Segment
|
||
Providers
|
||
3.5.6
|
||
Process messages for interferer
|
||
data, registration data and TAC
|
||
related data.
|
||
C/S A.002
|
||
V
|
||
Includes SIT 121, SIT 141, SIT 925,
|
||
SIT 926 and SIT 927 messages
|
||
3.5.7
|
||
Use different comm networks
|
||
and message formats for input
|
||
vs output
|
||
C/S A.005
|
||
V
|
||
3.5.8
|
||
Change message format to
|
||
SIT 915 if required
|
||
C/S A.002
|
||
V
|
||
3.5.9
|
||
Use of SIT 185 message format
|
||
C/S A.002
|
||
V
|
||
|
||
C-6
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.6 Monitoring of National Ground Segment
|
||
3.6.1
|
||
Monitoring of associated LUTS
|
||
C/S A.003
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.6.2
|
||
Monitoring of MCC/LUT(s)
|
||
communication link(s)
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.6.3
|
||
Monitor operation of MCC
|
||
D/V
|
||
Limited verification by HMCC for
|
||
filtering of corrupt data
|
||
3.6.4
|
||
Monitor external
|
||
communications
|
||
D/V
|
||
Limited verification by HMCC
|
||
3.6.5
|
||
Notify status if anomaly
|
||
detected, and implement backup
|
||
procedures, if required
|
||
C/S A.001
|
||
and
|
||
C/S A.003
|
||
D
|
||
3.7 Backup Provisions
|
||
3.7.1
|
||
Implement backup procedures,
|
||
as required
|
||
D/V
|
||
Describe backup procedures
|
||
Limited verification by the HMCC
|
||
3.7.1
|
||
Inform other MCCs using status
|
||
message
|
||
C/S A.001
|
||
V
|
||
3.7.2
|
||
Failure of associated LUT(s)
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.7.3
|
||
Transmit messages manually
|
||
D
|
||
Optional – describe any capabilities
|
||
3.7.3
|
||
Bilateral agreement for transfer
|
||
of LUT data if MCC inoperative
|
||
Recommend
|
||
ed
|
||
D
|
||
This requirement only applies if the
|
||
MCC has an associated LUT
|
||
3.8 Re-routing of Messages
|
||
3.8
|
||
Re-route messages
|
||
D/V
|
||
Optional – describe and verify any
|
||
capabilities
|
||
|
||
C-7
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.9 406 MHz Beacon Register
|
||
3.9
|
||
Maintain access to national
|
||
406 MHz beacon register
|
||
D/V
|
||
3.9
|
||
Request FGB information from
|
||
other States’ registers
|
||
V
|
||
3.9
|
||
Request SGB information from
|
||
other States’ registers
|
||
V
|
||
3.9
|
||
Respond to request for beacon
|
||
register information using FGB
|
||
and SGB 15-hex code
|
||
V
|
||
3.9
|
||
Respond to request for beacon
|
||
register information using SGB
|
||
23-hex code
|
||
V
|
||
3.9
|
||
Respond to request for beacon
|
||
register information using
|
||
vehicle mobile identification
|
||
data
|
||
V
|
||
3.10 Information Archival and Retrieval
|
||
3.10
|
||
Archive and retrieve messages
|
||
D/V
|
||
3.10
|
||
Retransmit information to
|
||
requesting entity
|
||
V
|
||
Details provided in sections 3.10.1 and
|
||
3.10.2 of C/S A.005
|
||
3.10.1
|
||
Retrieve FGB alert data
|
||
V
|
||
Describe interrogation modes tested
|
||
3.10.1
|
||
Retrieve SGB alert data
|
||
V
|
||
Describe interrogation modes tested
|
||
3.10.1
|
||
Retrieve SSAS alert data
|
||
V
|
||
Describe interrogation modes tested
|
||
3.10.1
|
||
Retrieve ELT(DT) alert data
|
||
V
|
||
Describe interrogation modes tested
|
||
3.10.2
|
||
Retrieve C/S messages
|
||
V
|
||
Describe interrogation modes tested
|
||
|
||
C-8
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
3.11 Test and Exercise Co-ordination and Reporting
|
||
3.11
|
||
Participate in test and exercises
|
||
as requested
|
||
C/S A.001
|
||
and
|
||
C/S A.003
|
||
D
|
||
3.11
|
||
Collect and report data using
|
||
agreed formats
|
||
C/S A.003
|
||
D
|
||
3.12 Interference Control
|
||
3.12
|
||
Co-operate to locate and remove
|
||
interference
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide
|
||
description
|
||
of
|
||
national
|
||
arrangements
|
||
3.12
|
||
Collect 406 MHz interference
|
||
data through SARR channel of
|
||
associated LEOLUTs
|
||
D/V
|
||
Optional. Limited verification by
|
||
HMCC.
|
||
This requirement only applies if the
|
||
MCC has an associated LEOLUT with
|
||
interference monitoring capability
|
||
3.12
|
||
Collect 406 MHz interference
|
||
data through SARR channel of
|
||
associated MEOLUTs
|
||
D/V
|
||
Optional. Limited verification by
|
||
HMCC.
|
||
This requirement only applies if the
|
||
MCC has an associated MEOLUT
|
||
with
|
||
interference
|
||
monitoring
|
||
capability
|
||
3.12
|
||
Report on detected interferers
|
||
C/S A.003
|
||
D
|
||
3.13 Reference Beacon Operation
|
||
3.13
|
||
Provision of orbitography or
|
||
reference beacon, if applicable
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short description of national
|
||
arrangements.
|
||
3.13
|
||
Provision of MEOSAR
|
||
reference beacon, if applicable
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short description of national
|
||
arrangements.
|
||
3.13
|
||
Process orbitography and
|
||
reference beacon detections
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short description of how
|
||
beacons are processed by MCC.
|
||
3.14 Reporting Requirements
|
||
3.14
|
||
Reporting
|
||
C/S A.003
|
||
D
|
||
|
||
C-9
|
||
|
||
6Table C-3: Functional Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.1 Data Acquisition
|
||
4.1
|
||
Receive messages without loss
|
||
D/V
|
||
Limited verification by HMCC.
|
||
4.1
|
||
Time tag and store incoming data
|
||
D/V
|
||
Limited verification by HMCC.
|
||
4.1
|
||
Store data electronically
|
||
D
|
||
4.1
|
||
Incoming data accessible to
|
||
operator
|
||
V
|
||
See related sections 3.10.2 and
|
||
5.8 of C/S A.005
|
||
4.2 Data Validation
|
||
4.2.1
|
||
Validate format and consistency
|
||
of SIT messages
|
||
C/S A.001 and
|
||
C/S A.002
|
||
V
|
||
4.2.1
|
||
Request retransmission of
|
||
message
|
||
V
|
||
4.2.2
|
||
Validate FGB incident alert
|
||
messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.2.2
|
||
Validate SGB incident alert
|
||
messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.2.2
|
||
Validate SSAS incident alert
|
||
messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.2.2
|
||
Validate ELT(DT) incident alert
|
||
messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.2.2
|
||
Process uncorroborated
|
||
MEOSAR alerts
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
|
||
C-10
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.2.3
|
||
Validate position against satellite
|
||
footprint (encoded location)
|
||
C/S A.001,
|
||
Section 3.2.1
|
||
V
|
||
Validate against a selected
|
||
sample of solutions
|
||
4.2.3
|
||
Validate position against satellite
|
||
footprint (LEOSAR)
|
||
C/S A.001,
|
||
Section 3.2.1
|
||
V
|
||
Validate against a selected
|
||
sample of solutions
|
||
4.2.3
|
||
Validate position against satellite
|
||
footprint (MEOSAR)
|
||
C/S A.001,
|
||
Section 3.2.1
|
||
V
|
||
Validate against a selected
|
||
sample of solutions
|
||
4.3 Process Data Selectively
|
||
4.3.1
|
||
Selectively process data
|
||
V
|
||
4.3.2
|
||
Suppress transmission of alert
|
||
data for specific FGB beacon
|
||
V
|
||
4.3.2
|
||
Suppress transmission of alert
|
||
data for specific SGB beacon
|
||
V
|
||
4.3.2
|
||
Suppress transmission of alert
|
||
data for specific ELT(DT)
|
||
beacon
|
||
V
|
||
4.3.3
|
||
Filter Doppler or DOA locations,
|
||
based on a specified source of
|
||
data (LUT), per beacon
|
||
generation (FGB or SGB)
|
||
V
|
||
4.4 Position Matching
|
||
4.4
|
||
Use position matching criteria for
|
||
alerts according to C/S A.001
|
||
C/S A.001
|
||
V
|
||
4.5 Position Confirmation
|
||
4.5.1
|
||
Use the criteria contained in
|
||
C/S A.001 to confirm position
|
||
C/S A.001
|
||
V
|
||
4.5.1
|
||
Position Matching and
|
||
Unresolved Doppler Position
|
||
Match
|
||
C/S A.001,
|
||
section 4.2.2 (i)
|
||
V
|
||
|
||
C-11
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.5.2
|
||
Continue distribution of alert
|
||
data to other MCCs after position
|
||
confirmation
|
||
C/S A.001 section
|
||
3.2.5
|
||
V
|
||
4.5.2
|
||
Selectively discontinue
|
||
transmission after position
|
||
confirmation
|
||
V
|
||
4.5.3
|
||
Use of other means at national
|
||
level to confirm position
|
||
D
|
||
Provide short description.
|
||
4.6 Geographic Sorting of Alert Data
|
||
4.6
|
||
Geographically sort beacon
|
||
locations by Cospas-Sarsat
|
||
GEOSORT
|
||
V
|
||
Verify for FGBs and SGBs
|
||
4.6
|
||
Geographically sort beacon
|
||
locations for SPOC service areas
|
||
as required
|
||
V
|
||
Verify for FGBs and SGBs
|
||
4.7 Filtering Redundant Alert Data
|
||
4.7
|
||
Filter solutions
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.7
|
||
Determine better quality
|
||
solutions
|
||
C/S A.001,
|
||
Section 4.2
|
||
D/V
|
||
Limited verification by HMCC.
|
||
4.7
|
||
Do not filter QMS data
|
||
C/S A.001,
|
||
Section 4.2
|
||
D/V
|
||
Limited verification by HMCC.
|
||
Not applicable for nodal MCCs.
|
||
4.7
|
||
LEOSAR image position
|
||
determination prior to ambiguity
|
||
resolution
|
||
C/S A.001,
|
||
section 3.2.3 and
|
||
C/S A.002,
|
||
Appendix B.2 to
|
||
Annex B
|
||
V
|
||
Per description of MF \#24 in
|
||
C/S A.002, determination of a
|
||
LEOSAR image position is
|
||
optional.
|
||
Use
|
||
of
|
||
image
|
||
position
|
||
determination information is
|
||
required.
|
||
4.7
|
||
Filter redundant ELT(DT) data
|
||
C/S A.001,
|
||
section 3.2.3.2
|
||
V
|
||
|
||
C-12
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.8 Notification of Country of Beacon Registration (NOCR)
|
||
4.8
|
||
Provide NOCR messages
|
||
C/S A.001
|
||
D/V
|
||
Limited verification by HMCC.
|
||
See sections 1 and 2.2 of this
|
||
C/S A.006.
|
||
4.9 Notification of Return Link Service (RLS) Beacon Alerts
|
||
4.9
|
||
Provide RLS messages to RLSP
|
||
C/S A.001
|
||
D/V
|
||
Limited verification by HMCC.
|
||
See sections 1 and 2.2 of this
|
||
C/S A.006.
|
||
4.9
|
||
Process RLS messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
D/V
|
||
Limited verification by HMCC.
|
||
4.9
|
||
Support MCC that is RLS-
|
||
capable (\*)
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.9
|
||
Support MCC that is not RLS-
|
||
capable (\*)
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
(\*) until all MCCs are RLS-capable
|
||
4.10 Two-Way Communication (TWC) Beacon Alerts
|
||
4.10
|
||
Provide TWC messages to TWC-
|
||
SP
|
||
C/S A.001
|
||
D/V
|
||
Limited verification by HMCC.
|
||
See sections 1 and 2.2 of this
|
||
C/S A.006.
|
||
4.10
|
||
Process TWC messages
|
||
C/S A.001,
|
||
Section 4.2
|
||
D/V
|
||
Limited verification by HMCC.
|
||
4.10
|
||
Support MCC that is TWC-
|
||
capable (\*)
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.10
|
||
Support MCC that is not TWC-
|
||
capable (\*)
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
(\*) until all MCCs are TWC-capable
|
||
4.11 Ship Security Alerts
|
||
4.11
|
||
Process ship security alerts
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
|
||
C-13
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.12 Distress Tracking ELT(DT) Beacon Alerts
|
||
4.12
|
||
Process ELT(DT) messages
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
4.12
|
||
Support MCC that is ELT(DT)-
|
||
capable**
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
4.12
|
||
Support MCC that is not
|
||
ELT(DT)-capable**
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
4.12
|
||
Send FGB ELT(DT) data to
|
||
LADR
|
||
C/S A.001
|
||
Section 3.13
|
||
V
|
||
[To be verified once the LADR
|
||
is available.]
|
||
Note: only nodal MCCs send
|
||
data directly to the LADR.
|
||
4.12
|
||
Send SGB ELT(DT) data to
|
||
LADR
|
||
C/S A.001
|
||
Section 3.13
|
||
V
|
||
[To be verified once the LADR
|
||
is available.]
|
||
Note: only nodal MCCs send
|
||
data directly to the LADR.
|
||
(**) until all MCCs are ELT(DT)-capable
|
||
4.13 Second-Generation Beacon Alerts
|
||
4.13
|
||
Process SGB messages
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
4.13
|
||
Support MCC that is SGB-
|
||
capable***
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
4.13
|
||
Support MCC that is not SGB-
|
||
capable***
|
||
C/S A.001
|
||
Section 4.2
|
||
V
|
||
(***) until all MCCs are SGB-capable
|
||
|
||
C-14
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration /
|
||
Verification or
|
||
Comments
|
||
4.14 Cancellation Message
|
||
4.14
|
||
Process FGB ELT(DT)
|
||
cancellation message
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.14
|
||
Process SGB (non-ELT(DT))
|
||
cancellation message
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.14
|
||
Process SGB ELT(DT)
|
||
cancellation message
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.14
|
||
Process FGB ELT(DT)
|
||
cancellation message with restart
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.14
|
||
Process SGB (non-ELT(DT))
|
||
cancellation message with restart
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.14
|
||
Process SGB ELT(DT)
|
||
cancellation message with restart
|
||
C/S A.001,
|
||
Section 4.2
|
||
V
|
||
4.15 TAC related information on beacon characteristics
|
||
4.15
|
||
Process TAC information
|
||
V
|
||
|
||
C-15
|
||
|
||
7Table C-4: Performance Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
5.1 Availability
|
||
5.1
|
||
Availability
|
||
Operational 99.5%
|
||
over 1 year
|
||
D/M
|
||
Limited measurement by HMCC
|
||
during test period.
|
||
5.2 Communication Links
|
||
5.2
|
||
Implement procedures to ensure
|
||
specifications are met
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short description of any
|
||
procedures implemented
|
||
LUT/MCC
|
||
5.2.1.1
|
||
Receive data from LUT(s)
|
||
within 10 min.
|
||
99% of time
|
||
Mn
|
||
This requirement only applies if
|
||
the MCC has an associated LUT.
|
||
Provide summary to HMCC.
|
||
5.2.1.2
|
||
Lost messages from LUT(s)
|
||
< 0.1%
|
||
Mn
|
||
This requirement only applies if
|
||
the MCC has an associated LUT.
|
||
Provide summary to HMCC.
|
||
5.2.1.3
|
||
Distress tracking alert messages
|
||
from LUT(s)
|
||
within 2 min.
|
||
99% of time
|
||
Mn
|
||
This requirement only applies if
|
||
the MCC has an associated LUT.
|
||
Provide summary to HMCC.
|
||
MCC/MCC
|
||
5.2.2.1
|
||
Transfer data to other MCCs
|
||
within 10 min.
|
||
99% of time
|
||
M
|
||
5.2.2.2
|
||
Lost or corrupted messages to
|
||
other MCCs
|
||
< 0.1%
|
||
M
|
||
5.2.2.3
|
||
Availability of communication
|
||
link to other MCCs
|
||
99% each day
|
||
M
|
||
|
||
C-16
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
MCC to Non-MCC Alert Recipient
|
||
5.2.3
|
||
Availability of MCC to SPOC
|
||
communication network
|
||
95% each day
|
||
Mn
|
||
Provide summary to HMCC.
|
||
5.2.3
|
||
Availability of MCC to SSAS
|
||
Competent Authority
|
||
communication network
|
||
95% each day
|
||
Mn
|
||
Provide summary to HMCC.
|
||
5.2.3
|
||
Availability of MCC to RLSP
|
||
communication network
|
||
95% each day
|
||
Mn
|
||
Provide summary to HMCC.
|
||
Only applies if DMCC sends
|
||
directly to RLSP
|
||
5.3 Alert Data Processing Capacity
|
||
5.3.1
|
||
Process distress alert data from
|
||
associated LEOLUT
|
||
at least 100 alerts
|
||
per LUT
|
||
D
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
LEOLUT
|
||
5.3.1
|
||
Process distress alert data from
|
||
associated GEOLUT
|
||
at least 100 alerts
|
||
per LUT
|
||
D
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
GEOLUT
|
||
5.3.1
|
||
Process distress alert data from
|
||
associated MEOLUT
|
||
at least 500 alerts
|
||
per LUT
|
||
D
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
MEOLUT
|
||
5.3.2
|
||
Process distress alert data from
|
||
other MCCs
|
||
at least 100 alerts
|
||
in 10 minutes
|
||
D
|
||
DMCC will declare:
|
||
• the forecast volume
|
||
of alert traffic, and
|
||
• its
|
||
ability
|
||
of
|
||
processing
|
||
the
|
||
forecast traffic.
|
||
5.3.3
|
||
Process distress alerts to alert
|
||
data destinations
|
||
at least 100 alerts
|
||
in 10 minutes
|
||
D
|
||
5.4 System Information Processing Capacity
|
||
5.4
|
||
Send and receive System
|
||
information messages
|
||
15 per day
|
||
D
|
||
|
||
C-17
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
5.5 QMS Continuous Monitoring & Objective Assessment Capacity
|
||
5.5.1
|
||
Transmit LEOLUT solution data
|
||
per QMS procedures
|
||
V
|
||
See C/S A.003.
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
LEOLUT
|
||
5.5.2
|
||
Transmit GEOLUT solution
|
||
data per QMS procedures
|
||
V
|
||
See C/S A.003.
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
GEOLUT
|
||
5.5.3
|
||
Transmit MEOLUT solution
|
||
data per QMS procedures
|
||
V
|
||
See C/S A.003.
|
||
This requirement only applies if
|
||
the MCC has an associated
|
||
MEOLUT
|
||
5.6 Processing Time
|
||
5.6
|
||
Processing time for alert data
|
||
5 minutes 99% of
|
||
time
|
||
Mn
|
||
Provide summary to HMCC.
|
||
5.7 Processing Integrity
|
||
5.7.1
|
||
Maintain accuracy of distress
|
||
alert location
|
||
no more than
|
||
0.2 km from
|
||
received data
|
||
V
|
||
Compare locations sent by the
|
||
DMCC to locations sent to the
|
||
DMCC.
|
||
5.7.2
|
||
Accurately Geosort beacon
|
||
locations to appropriate
|
||
RCC/SPOC
|
||
± 25 km of
|
||
Geosort boundary
|
||
V
|
||
5.7.3
|
||
Maintain accurate time reference
|
||
within ± 25 sec
|
||
D/V
|
||
Provide description of capability.
|
||
Limited verification by HMCC.
|
||
5.7.4
|
||
Maintain integrity of transiting
|
||
data
|
||
no corruption
|
||
D/V
|
||
Limited verification by HMCC.
|
||
|
||
C-18
|
||
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
5.8 Access to Archived Information
|
||
5.8.1
|
||
Archive data and messages
|
||
at least 30 days
|
||
V
|
||
5.8.2
|
||
Respond to request for archived
|
||
alert data and messages
|
||
60 minutes
|
||
V
|
||
5.8.3
|
||
Respond to request for alert data
|
||
and messages covering last 48 hr
|
||
30 minutes
|
||
V
|
||
5.9 Backup Timing
|
||
5.9
|
||
Time required to switch to
|
||
backup system
|
||
30 minutes
|
||
V
|
||
Note actual time, for use in
|
||
operational backup procedures
|
||
5.10 Additional Timing Requirements
|
||
5.10.1
|
||
Suppress alert data
|
||
10 minutes
|
||
V
|
||
5.10.2
|
||
Implement backup procedures
|
||
60 minutes
|
||
V
|
||
5.10.3
|
||
Access beacon register
|
||
15 minutes
|
||
V
|
||
5.10.4
|
||
Forward retrieved information to
|
||
requestor
|
||
15 minutes
|
||
V
|
||
5.10.5
|
||
Update orbital data at its
|
||
associated LEOLUT(s) and
|
||
notify RCCs and SPOCs of a
|
||
satellite manoeuvre (see
|
||
corresponding section of
|
||
document C/S A.005).
|
||
Immediately or 4
|
||
hours (per
|
||
document
|
||
C/S A.005)
|
||
D / V
|
||
DMCC to provide a brief
|
||
description of its associated
|
||
procedure, noting whether the
|
||
procedure can be performed
|
||
solely by the MCC Operator.
|
||
5.10.6
|
||
Update SARP Time calibration
|
||
information at its associated
|
||
LEOLUT(s).
|
||
4 hours
|
||
D / V
|
||
DMCC to provide a brief
|
||
description of its associated
|
||
procedure, noting whether the
|
||
procedure can be performed
|
||
solely by the MCC Operator.
|
||
|
||
C-19
|
||
|
||
3.
|
||
SIT MESSAGE FORMAT
|
||
Provide information for all SIT messages that will be exchanged by the DMCC operationally,
|
||
including those that are mandatory according to document C/S A.002 and those listed as
|
||
implemented in document C/S A.001.
|
||
8Table C-5: FGB LEOSAR and GEOSAR Incident Alert Messages
|
||
The 8 types of SIT 185 messages listed below, in sequence, correspond to SIT messages 122 to
|
||
133, respectively.
|
||
SIT
|
||
Name
|
||
Pass/
|
||
Fail
|
||
Number of Messages
|
||
Sent and Received
|
||
HMCC
|
||
Tx
|
||
DMCC
|
||
Rx
|
||
DMCC
|
||
Tx
|
||
HMCC
|
||
Rx
|
||
|
||
Interferer Notification
|
||
|
||
Incident (No Doppler)
|
||
|
||
Position Conflict (Encoded Only)
|
||
|
||
Position Confirmation (Encoded Only)
|
||
|
||
Incident (Doppler)
|
||
|
||
Position Conflict (Doppler)
|
||
|
||
Position Confirmation (Doppler)
|
||
|
||
NOCR (Encoded Only)
|
||
|
||
NOCR (Doppler)
|
||
|
||
Return Link Alert (Encoded Only)
|
||
|
||
Return Link Alert (Doppler)
|
||
|
||
Cospas-Sarsat Incident (No Doppler)
|
||
|
||
Cospas-Sarsat Position Conflict (Encoded Only)
|
||
|
||
Cospas-Sarsat Position Confirmation (Encoded
|
||
Only)
|
||
|
||
Cospas-Sarsat Incident (Doppler)
|
||
|
||
Cospas-Sarsat Position Conflict (Doppler)
|
||
|
||
Cospas-Sarsat Position Confirmation (Doppler)
|
||
|
||
Cospas-Sarsat NOCR (Encoded Only)
|
||
|
||
Cospas-Sarsat NOCR (Doppler)
|
||
|
||
C-20
|
||
|
||
9Table C-6: FGB MEOSAR Incident Alert Messages
|
||
The 8 types of SIT 185 messages listed below, in sequence, correspond to SIT messages 142 to
|
||
147, 136 and 137, respectively.
|
||
SIT
|
||
Name
|
||
Pass/
|
||
Fail
|
||
Number of Messages
|
||
Sent and Received
|
||
HMCC
|
||
Tx
|
||
DMCC
|
||
Rx
|
||
DMCC
|
||
Tx
|
||
HMCC
|
||
Rx
|
||
|
||
NOCR (Encoded Only)
|
||
|
||
NOCR (DOA)
|
||
|
||
Return Link Alert (Encoded Only)
|
||
|
||
Return Link Alert (DOA)
|
||
|
||
Interferer Notification
|
||
|
||
Incident (No DOA)
|
||
|
||
Position Conflict (Encoded Only)
|
||
|
||
Position Confirmation (Encoded Only)
|
||
|
||
Incident (DOA)
|
||
|
||
Position Conflict (DOA)
|
||
|
||
Position Confirmation (DOA)
|
||
|
||
Cospas-Sarsat Incident (No DOA)
|
||
|
||
Cospas-Sarsat Position Conflict (Encoded Only)
|
||
|
||
Cospas-Sarsat Position Confirmation (Encoded
|
||
Only)
|
||
|
||
Cospas-Sarsat Incident (DOA)
|
||
|
||
Cospas-Sarsat Position Conflict (DOA)
|
||
|
||
Cospas-Sarsat Position Confirmation (DOA)
|
||
|
||
Cospas-Sarsat NOCR (Encoded Only)
|
||
|
||
Cospas-Sarsat NOCR (DOA)
|
||
|
||
C-21
|
||
|
||
10Table C-7: SGB Incident Alert Messages
|
||
The 8 types of SIT 185 messages listed below, in sequence, correspond to SIT messages 342 to
|
||
347, 336 and 337, respectively.
|
||
|
||
C-22
|
||
|
||
SIT
|
||
Name
|
||
Pass/
|
||
Fail
|
||
Number of Messages
|
||
Sent and Received
|
||
HMCC
|
||
Tx
|
||
DMCC
|
||
Rx
|
||
DMCC
|
||
Tx
|
||
HMCC
|
||
Rx
|
||
|
||
LEOSAR/GEOSAR Incident (No Doppler)
|
||
|
||
Position Conflict (GEOSAR Encoded Only)
|
||
|
||
Position Confirmation (GEOSAR Encoded Only)
|
||
|
||
NOCR (GEOSAR Encoded Only)
|
||
|
||
Return Link or Two-Way Communication Alert
|
||
(GEOSAR Encoded Only)
|
||
|
||
NOCR (MEOSAR Encoded Only)
|
||
|
||
NOCR (MEOSAR with DOA)
|
||
|
||
Return Link or Two-Way Communication Alert
|
||
(MEOSAR Encoded Only)
|
||
|
||
Return Link or Two-Way Communication Alert
|
||
MEOSAR with (DOA)
|
||
|
||
MEOSAR Incident (No DOA)
|
||
|
||
Position Conflict (MEOSAR Encoded Only)
|
||
|
||
Position Confirmation (MEOSAR Encoded Only)
|
||
|
||
Incident (MEOSAR with DOA)
|
||
|
||
Position Conflict (MEOSAR with DOA)
|
||
|
||
Position Confirmation (MEOSAR with DOA)
|
||
|
||
Cospas-Sarsat Incident (No DOA)
|
||
|
||
Cospas-Sarsat Position Conflict (Encoded Only)
|
||
|
||
Cospas-Sarsat Position Confirmation (Encoded
|
||
Only)
|
||
|
||
Cospas-Sarsat Incident (DOA)
|
||
|
||
Cospas-Sarsat Position Conflict (DOA)
|
||
|
||
Cospas-Sarsat Position Confirmation (DOA)
|
||
|
||
Cospas-Sarsat NOCR (Encoded Only)
|
||
|
||
Cospas-Sarsat NOCR (DOA)
|
||
|
||
C-23
|
||
|
||
11Table C-8: System Messages
|
||
SIT
|
||
Name
|
||
Pass/
|
||
Fail
|
||
Number of Messages
|
||
Sent and Received
|
||
HMCC
|
||
Tx
|
||
DMCC
|
||
Rx
|
||
DMCC
|
||
Tx
|
||
HMCC
|
||
Rx
|
||
|
||
LEOSAR Orbit Vectors
|
||
|
||
LEOSAR Orbit Vectors
|
||
|
||
MEOSAR Orbit Vector (TLE)s
|
||
|
||
LEOSAR SARP Calibration
|
||
|
||
LEOSAR SARP-3 Calibration
|
||
|
||
LEOSAR SARR Frequency Calibration
|
||
|
||
System Status
|
||
|
||
Narrative
|
||
|
||
406 MHz Beacon Registration Data
|
||
|
||
406 MHz Beacon Registration Data
|
||
|
||
Beacon operational characteristics information for
|
||
MCCs
|
||
|
||
Beacon operational characteristics for SPOCs
|
||
|
||
C-24
|
||
|
||
12Table C-9: System Messages for Space Segment Providers
|
||
The system messages that are used by the space segment providers to command or report on the
|
||
status of the SAR payloads are only to be tested if the MCC is operated by a Space Segment
|
||
Provider, and only those messages that apply to the provided space segment instruments need to
|
||
be tested.
|
||
SIT
|
||
Name
|
||
Pass/
|
||
Fail
|
||
Number of Messages
|
||
Sent and Received
|
||
HMCC
|
||
Tx
|
||
DMCC
|
||
Rx
|
||
DMCC
|
||
Tx
|
||
HMCC
|
||
Rx
|
||
|
||
SARP Telemetry
|
||
|
||
SARP Out of Limit
|
||
|
||
SARP Command
|
||
|
||
SARP Command Verification
|
||
|
||
SARR Telemetry
|
||
|
||
SARR Out of Limit
|
||
|
||
SARR Command
|
||
|
||
SARR Command Verification
|
||
4.
|
||
EXPLANATORY COMMENTS AS REQUIRED FOR ITEMS IN SECTION 2,
|
||
SUMMARY TABLE
|
||
(List each comment by reference to test paragraph number from column 1 of Summary
|
||
Table)
|
||
5.
|
||
OTHER INFORMATION RELEVANT TO THE COMMISSIONING TEST
|
||
(Include any comments not covered elsewhere on the conduct, analysis, or results of the
|
||
commissioning test
|
||
6.
|
||
RECOMMENDATIONS
|
||
- END OF ANNEX C -
|
||
|
||
D-1
|
||
|
||
ANNEX D
|
||
GUIDELINES FOR IMPLEMENTING NEW NODAL MCCs
|
||
1.
|
||
The material included hereunder is a textual flow-chart which sketches the procedures for
|
||
integrating new nodal MCCs into the existing Cospas-Sarsat Ground Segment.
|
||
2.
|
||
The introduction of a new nodal MCC in the Cospas-Sarsat System is supervised by the
|
||
Joint Committee and approved by the Cospas-Sarsat Council, with the objective of
|
||
improving the Cospas-Sarsat data distribution system.
|
||
3.
|
||
The purpose of this annex is to provide guidelines, used in conjunction with the contents
|
||
of section 3 of this document C/S A.006, for coordinating the introduction of a new nodal
|
||
MCC and assisting the new nodal MCC in planning and performing the appropriate
|
||
integration tests.
|
||
4.
|
||
The guidelines are separated into the following steps.
|
||
STEP A
|
||
Determination of Need and Selection of New Nodal MCC
|
||
A-1
|
||
The Joint Committee assesses the need to improve the exchange of alert and System data
|
||
between MCCs in the Cospas-Sarsat System.
|
||
The improvement can be achieved by:
|
||
•
|
||
improving the reliability of data distribution,
|
||
•
|
||
improving the effectiveness of data distribution, or
|
||
•
|
||
reducing the workload of an existing nodal MCC.
|
||
The reliability of alert data distribution may be increased with the introduction of a new
|
||
nodal MCC and DDR. The increased reliability could be a result of a new nodal MCC’s
|
||
ability to validate alerts better at a regional level, or to monitor the system better at a
|
||
regional level. The ability of a new nodal MCC to provide better backup arrangements
|
||
also increases reliability. Given that a nodal MCC may be a single point of failure in
|
||
Cospas-Sarsat data distribution, reliability can be improved if the number of MCCs in a
|
||
DDR remains small. Lastly, the reliability of data distribution may be improved due to a
|
||
better communications infrastructure between the new nodal MCC and MCCs in the
|
||
region and other nodal MCCs.
|
||
The effectiveness of alert data distribution may be improved by taking into consideration:
|
||
•
|
||
language barriers - planning, coordination and problem resolution may be improved
|
||
if personnel from different MCCs speak the same language,
|
||
|
||
D-2
|
||
|
||
•
|
||
existing bilateral or regional operational arrangements - Cospas-Sarsat data
|
||
distribution may be enhanced if ICAO or IMO regional plans exist for SAR
|
||
services,
|
||
•
|
||
geographic proximity and bordering SAR boundaries - planning, coordination and
|
||
problem resolution may be improved if MCCs within the DDR are in close
|
||
proximity and within the same time zones,
|
||
•
|
||
reduction in time for alert data distribution - effectiveness of alert data can be
|
||
increased if the time for alerts to reach their final destination is reduced,
|
||
•
|
||
compatible communication links - Cospas-Sarsat data distribution may be enhanced
|
||
if MCCs in a region share similar communication links.
|
||
The data distribution in Cospas-Sarsat may also be improved if one nodal MCC is not
|
||
overburdened distributing alerts. The burden may be quantified by the size of the existing
|
||
nodal MCC’s service area, the size of the DDR, and the resources expended to complete
|
||
the nodal MCC’s mission. The size of the DDR can be measured in many different ways
|
||
(e.g., the message filter factor from the Exercise of 1990), but ultimately must be reviewed
|
||
on a case-by-case basis as the capabilities of different MCCs vary considerably.
|
||
A-2
|
||
The Joint Committee assesses the capabilities of existing MCCs and makes a
|
||
recommendation to Council on the practical options for selection and development of a
|
||
new nodal MCC.
|
||
A-3
|
||
The Joint Committee recommends to Council that such improvement should be pursued
|
||
by the establishment of a new nodal MCC and its associated DDR.
|
||
A-4
|
||
The Council considers and approves the Joint Committee recommendation, as
|
||
appropriate.
|
||
A-5
|
||
After approval by the Council and acceptance by the proposed new nodal MCC, the Joint
|
||
Committee identifies:
|
||
•
|
||
the new Data Distribution Region (DDR) associated with the new nodal MCC,
|
||
•
|
||
the new structure of the inter-regional data distribution network.
|
||
A-6
|
||
The Council approves the new DDR and the inter-regional network structure.
|
||
|
||
D-3
|
||
|
||
STEP B
|
||
Preparation for System Commissioning Test
|
||
B-1
|
||
The Joint Committee designates a host MCC to assist the new nodal MCC in System
|
||
integration. The host MCC will usually be the existing nodal MCC in one of the DDR(s)
|
||
affected, and therefore, the nodal MCC in the best position to assist the new nodal MCC
|
||
in the commissioning process.
|
||
B-2
|
||
The new nodal MCC coordinates with MCCs in the proposed new DDR on procedures
|
||
for exchange of data and communications media to be used.
|
||
B-3
|
||
The new nodal MCC analyses the additional requirements for a nodal MCC and ensures
|
||
they can be met. The requirements analysis includes the necessary hardware
|
||
enhancements, software enhancements and communication links at regional and inter-
|
||
regional levels.
|
||
B-4
|
||
The new nodal MCC coordinates all commissioning activities, with assistance from the
|
||
host nodal MCC, before commissioning tests begin.
|
||
B-5
|
||
The new nodal MCC, in cooperation with the host nodal MCC, develops a
|
||
Commissioning Plan that is coordinated with all MCCs involved in the commissioning
|
||
process.
|
||
STEP C
|
||
Commissioning Test
|
||
C-1
|
||
The host nodal MCC notifies all MCCs regarding the start of the commissioning test.
|
||
C-2
|
||
The host nodal MCC, the new nodal MCC and one of the MCCs in the new DDR modify
|
||
their MCC software for geographical sorting of alerts, communications addresses and/or
|
||
links in order to begin commissioning tests.
|
||
C-3
|
||
The host nodal MCC, the new nodal MCC, and one MCC in the new DDR conduct the
|
||
commissioning test according to the prepared Commissioning Plan.
|
||
C-4
|
||
The host nodal MCC, the new nodal MCC, and the remaining MCCs in the new DDR
|
||
conduct the commissioning test according to the prepared Commissioning Plan.
|
||
C-5
|
||
Each MCC participating in the test collects test data in accordance with sections C and D
|
||
of Annex B to this document.
|
||
C-6
|
||
The new nodal MCC completes the nodal MCC commissioning report (provided as
|
||
Annex E to this document) and forwards it to the host nodal MCC.
|
||
C-7
|
||
The host nodal MCC collects and analyses data from participating MCCs, as necessary.
|
||
|
||
D-4
|
||
|
||
C-8
|
||
The host nodal MCC, through its designated agency, forwards the new nodal MCC
|
||
commissioning report to the Cospas-Sarsat Secretariat and recommends that the new
|
||
nodal MCC be commissioned.
|
||
C-9
|
||
The Joint Committee reviews the commissioning report and recommends approval by the
|
||
Cospas-Sarsat Council at their next meeting.
|
||
STEP D
|
||
Establishment of Initial and Full Operational Capability
|
||
Remark
|
||
When the commissioning tests are completed and accepted by the host nodal MCC,
|
||
the new nodal MCC is considered operational in an Initial Operational Capability
|
||
(IOC), with respect to its nodal functions. The host nodal MCC shall advise all
|
||
ground segment operators of the change in status in accordance with document
|
||
C/S A.001.
|
||
D-1
|
||
At IOC the new nodal MCC provides the nodal functions for one MCC in the new DDR.
|
||
Such change should not affect other nodal MCCs except the host nodal MCC.
|
||
D-2
|
||
The new nodal MCC proceeds with the testing and implementation of the communication
|
||
links to the remaining MCCs in the DDR, as provided in the Commissioning Plan.
|
||
D-3
|
||
If no links to other nodal MCCs are required, and all MCCs in the DDR have been
|
||
successfully connected to the new nodal MCC, the host nodal MCC declares the new
|
||
nodal MCC at Full Operational Capability (FOC) and informs all Ground Segment
|
||
operators.
|
||
D-4
|
||
If links to other nodal MCCs are required as per the Commissioning Plan, the new nodal
|
||
MCC proceeds with testing these communication links. When all communication tests
|
||
have been completed successfully, the host MCC coordinates the FOC date for the new
|
||
nodal MCC with all nodal MCCs involved, and informs all ground segment operators.
|
||
D-5
|
||
Before the FOC date, the Secretariat shall update the sections of document C/S A.001 and
|
||
the system status tables on the Cospas-Sarsat website.
|
||
D-6
|
||
Before the FOC date, the Secretariat shall provide the new nodal MCC with the access
|
||
passwords and any other requirements to enable it to modify the system status tables on
|
||
the Cospas-Sarsat website.
|
||
D-7
|
||
At the FOC date, all nodal MCCs involved implement the new data exchange matrix and
|
||
the geographical sorting of alert data as provided in the document C/S A.001.
|
||
- END OF ANNEX D -
|
||
|
||
E-1
|
||
|
||
ANNEX E
|
||
NODAL MCC COMMISSIONING REPORT
|
||
Country or national Administration:
|
||
_______________
|
||
Location of MCC:
|
||
_______________
|
||
Cospas-Sarsat Identifier:
|
||
_______________
|
||
Start of Commissioning Period:
|
||
_______________
|
||
End of Commissioning Period:
|
||
_______________
|
||
Section 1 contains information on the communication links established with other MCCs to
|
||
support nodal MCC functions.
|
||
Section 2 contains the summary tables that show the commissioning results, where the Method of
|
||
Compliance is one of:
|
||
•
|
||
declaration by the national Administration (D),
|
||
•
|
||
verification by the host MCC (V),
|
||
•
|
||
verification by the national Administration (Vn),
|
||
•
|
||
measurement by the host MCC (M), or
|
||
•
|
||
measurement by the national Administration (Mn).
|
||
Where the method of compliance is listed as verification, evidence of that verification shall be
|
||
included in the data package that is submitted to the Cospas-Sarsat Secretariat with the
|
||
MCC Commissioning Report. Section 3 contains explanatory comments necessary to amplify the
|
||
results contained in the summary tables of section 2. Section 4 includes any comments required on
|
||
the commissioning process or new nodal MCC status. Finally, section 5 includes the
|
||
recommendations of the host MCC as to the readiness of the new nodal MCC to be commissioned.
|
||
|
||
E-2
|
||
|
||
1.
|
||
COMMUNICATION LINKS
|
||
Provide information on each link that will be used operationally by the MCC to perform its nodal
|
||
functions, as indicated in documents C/S A.001 and C/S A.005. This includes links to other MCCs
|
||
in its DDR and to other nodal MCCs.
|
||
This table does not have to contain information on the links to the national LUTs, RCCs, SPOCs,
|
||
SSAS Competent Authorities or LADR that have been described in the original Commissioning
|
||
Report for this MCC.
|
||
13Table E-1: Communications Links
|
||
Destination
|
||
MCC
|
||
Network
|
||
Type
|
||
(e.g., FTP)
|
||
Link Address
|
||
Direction of Data to
|
||
Nodal MCC (Input,
|
||
Output, Both)
|
||
Pass/
|
||
Fail
|
||
Comments
|
||
2.
|
||
SUMMARY TABLES
|
||
14Table E-2: Operational Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
Operational Requirements
|
||
6.1.1
|
||
On-site staff 24/7
|
||
n/a
|
||
D
|
||
6.1.2
|
||
Access to
|
||
communication links
|
||
n/a
|
||
D
|
||
6.1.2
|
||
Send and receive
|
||
simultaneously
|
||
n/a
|
||
D
|
||
6.1.3
|
||
Monitor operation of
|
||
C/S System within
|
||
DDR (QMS metrics)
|
||
C/S A.003
|
||
n/a
|
||
V
|
||
Computations for each relevant QMS metric
|
||
per C/S A.003 section 2 and associated actions
|
||
(e.g., notification to MCCs, updates to the C/S
|
||
website, and alert data filtering) should be
|
||
verified. Verification is not required for a QMS
|
||
metric if no GEOLUT, LEOLUT or MEOLUT
|
||
in the DDR of that type is operational or
|
||
planned for operational use.
|
||
6.1.3
|
||
Monitor operation of
|
||
C/S System within
|
||
DDR (other)
|
||
C/S A.003
|
||
D / V
|
||
Monitoring not included in QMS metrics, as
|
||
described above. Limited verification by the
|
||
HMCC.
|
||
6.1.4
|
||
Develop backup
|
||
procedures
|
||
C/S A.001
|
||
V
|
||
Present backup plan to HMCC
|
||
|
||
E-3
|
||
|
||
15Table E-3: Functional Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
6.2.1.1
|
||
Receive and process alert data
|
||
V
|
||
6.2.1.2
|
||
Maintain data integrity
|
||
V
|
||
6.2.2
|
||
Geosort beacon locations for all
|
||
MCC service areas, as necessary
|
||
V
|
||
6.2.3.1
|
||
Receive and process System
|
||
information
|
||
V
|
||
6.2.3.2
|
||
Validate and transmit System
|
||
information
|
||
C/S A.001
|
||
and
|
||
C/S A.003
|
||
V
|
||
6.2.3.2
|
||
Report invalid data to appropriate
|
||
MCC
|
||
V
|
||
6.2.4
|
||
Narrative Information Processing
|
||
V
|
||
16Table E-4: Performance Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/Verification or
|
||
Comments
|
||
6.3.1
|
||
Availability of MCC functions
|
||
99.5% over
|
||
one year
|
||
n/a
|
||
D/V
|
||
Limited verification by
|
||
HMCC during test period.
|
||
6.3.1
|
||
Implement backup if non-
|
||
availability > 1 hour
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of
|
||
procedures
|
||
6.3.2
|
||
Availability of inter-nodal MCC
|
||
communication
|
||
99.5% each
|
||
day
|
||
n/a
|
||
D
|
||
6.3.3.1
|
||
Capacity to process expected
|
||
volume of distress alert data
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of
|
||
capability
|
||
6.3.3.2
|
||
Capacity to transmit expected
|
||
volume of distress alert data
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of
|
||
capability
|
||
|
||
E-4
|
||
|
||
17Table E-5: Co-ordinating Requirements
|
||
Paragraph
|
||
in
|
||
C/S A.005
|
||
Requirement
|
||
or
|
||
Test
|
||
Pass
|
||
Criteria
|
||
Result
|
||
Pass/
|
||
Fail
|
||
Method of
|
||
Compliance
|
||
Declaration/
|
||
Verification or
|
||
Comments
|
||
6.4.1
|
||
Co-ordinate development of
|
||
communication links within
|
||
DDR
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of plans
|
||
to develop links
|
||
6.4.2
|
||
Act as focal point for C/S
|
||
matters within DDR
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of plans
|
||
to accomplish requirements of
|
||
C/S A.005, section 6.4.2
|
||
6.4.3
|
||
Provide support and assistance
|
||
to developing MCCs within
|
||
DDR
|
||
n/a
|
||
n/a
|
||
n/a
|
||
D
|
||
Provide short statement of plans
|
||
to accomplish these requirements
|
||
3.
|
||
EXPLANATORY COMMENTS AS REQUIRED FOR ITEMS IN SECTION 2,
|
||
SUMMARY TABLE
|
||
(List each comment by reference to test paragraph number from column 1 of Summary Table.)
|
||
4.
|
||
OTHER INFORMATION RELEVANT TO THE COMMISSIONING TEST
|
||
(Include any comments not covered elsewhere on the conduct, analysis, or results of the
|
||
commissioning test.)
|
||
5.
|
||
RECOMMENDATIONS
|
||
- END OF ANNEX E –
|
||
|
||
F-1
|
||
|
||
ANNEX F
|
||
MCC COMMISSIONING GUIDELINES
|
||
|
||
COSPAS-SARSAT COMMISSIONING POLICY
|
||
The general principles of the Cospas-Sarsat Council policy regarding Ground Segment equipment
|
||
commissioning, including MCC commissioning, are provided in the document C/S P.011,
|
||
“Cospas-Sarsat Programme Management Policy”. These principles shall prevail if any discrepancy
|
||
is found in these guidelines for MCC commissioning.
|
||
The commissioning of a new MCC, and especially of newly developed software, is an undertaking
|
||
that may require significant knowledge, effort and time. Accordingly, Administrations
|
||
implementing new MCCs should implement the following steps prior to commencing pre-
|
||
integration tests:
|
||
•
|
||
Assign a staff member exclusively to the task of implementing and commissioning the new
|
||
MCC. The knowledge required to implement and commission a new MCC exceeds the
|
||
knowledge level of most MCC operators. A permanently assigned staff member will be able
|
||
to obtain relevant knowledge and will have adequate time to smoothly work through the
|
||
complex steps in the commissioning process.
|
||
•
|
||
Install DMCC into a test setup that matches as closely as possible the planned operating
|
||
environment. This can be achieved through additional temporary communications routes,
|
||
through special temporary software configuration and other inexpensive means. Under ideal
|
||
circumstances this test setup could be used to conduct significant portions of the pre-
|
||
integration test while permitting operations to continue uninterrupted on the operational
|
||
system. In this way Administrations can find and correct errors in their DMCC prior to
|
||
scheduling actual commissioning tests.
|
||
•
|
||
Implement work processes for configuration control and for maintenance and support
|
||
systems. As modern software is highly user configurable, Administrations may not be able
|
||
to rely upon manufacturer staff to control software configuration processes. Thus, MCC
|
||
managers will need to implement their own work processes to identify baseline
|
||
configuration, and to recommend, test and implement changes. Further, if the new MCC
|
||
involves a new support model with the vendor, work process will need to be created or
|
||
updated to ensure support is available before, during, and after commissioning.
|
||
|
||
MCC COMMISSIONING PROCESS
|
||
The following principles govern the implementation of the Cospas-Sarsat MCC Commissioning
|
||
Standard (C/S A.006).
|
||
2.1
|
||
In preparation for its commissioning and integration into the Cospas-Sarsat Ground
|
||
Segment, the developmental MCC (DMCC) shall follow the steps indicated in the
|
||
|
||
F-2
|
||
|
||
"Guidelines for Integration of New MCCs in the Cospas-Sarsat System", (Annex B).
|
||
These pre-test actions include:
|
||
•
|
||
coordinating its future service area and communication links with other Cospas-
|
||
Sarsat MCCs,
|
||
•
|
||
determining, in coordination with the Joint Committee, the Host MCC which
|
||
accepts to participate in the DMCC commissioning tests,
|
||
•
|
||
developing the required bilateral arrangements between DMCC and the Host MCC.
|
||
2.2
|
||
The DMCC will be responsible for equipment which may be required for performing the
|
||
commissioning tests. Costs associated with performing the commissioning tests should
|
||
be addressed in bilateral arrangements between the DMCC and the Host MCC, as
|
||
appropriate.
|
||
2.3
|
||
A pre-integration test shall be run to identify possible SIT-format errors in messages
|
||
issued by the DMCC or the Host MCC and all deficiencies shall as far as possible be
|
||
eliminated prior to the integration testing.
|
||
2.4
|
||
The commissioning test plan shall include testing of all basic functional requirements and
|
||
evaluating all performance parameters specified in the document C/S A.005,
|
||
“Cospas-Sarsat MCC Specification and Design Guidelines”. For those functional
|
||
requirements which cannot be tested and measured in a practical way, the DMCC shall
|
||
provide a declaration stating that these capabilities are met.
|
||
2.5
|
||
The DMCC shall, in coordination with the Host MCC, analyse the test data and produce
|
||
a Commissioning Report to be submitted to the Secretariat through the Host MCC
|
||
Representative, for distribution to Ground Segment Providers and User States.
|
||
2.6
|
||
A statement by the Host MCC Representative that the requirements of document
|
||
C/S A.005, "MCC Performance Specification and Design Guidelines" are met by the
|
||
DMCC, shall be considered sufficient to declare that the DMCC is operational and ready
|
||
for integration into the Cospas-Sarsat Ground Segment, as coordinated with the Joint
|
||
Committee.
|
||
2.7
|
||
The Joint Committee shall, at its following meeting, review the DMCC report and
|
||
recommend to the Cospas-Sarsat Council, as appropriate, formal commissioning of the
|
||
DMCC.
|
||
2.8
|
||
The connection of a new LUT to an MCC which is currently in operation would not
|
||
require repeating the Commissioning procedure for that MCC. However, the test of the
|
||
LUT/MCC communication link, which is not part of the LUT commissioning procedure,
|
||
will have to be performed by the MCC operator, after it has been verified that the LUT
|
||
meets the criteria of document C/S T.002, C/S T.009, or C/S T.019.
|
||
|
||
F-3
|
||
|
||
GRANTING OF IOC AND FOC STATUS
|
||
In accordance with the Cospas-Sarsat policy for Ground Segment equipment commissioning as
|
||
stated in document C/S P.011:
|
||
3.1
|
||
An MCC will be granted IOC status at the date agreed with the Nodal MCC after it has:
|
||
•
|
||
declared its service area in accordance with document C/S P.011,
|
||
•
|
||
demonstrated its capability to exchange Cospas-Sarsat data in accordance with the
|
||
DDP, including with its own RCCs,
|
||
•
|
||
met the requirements of the document C/S A.005 “MCC Performance Specification
|
||
and Design Guidelines”, and the document C/S A.006 “MCC Commissioning
|
||
Standard”;
|
||
3.2
|
||
FOC status will be granted 90 days after IOC, provided that the MCC has satisfied all
|
||
applicable Cospas-Sarsat performance requirements during IOC operation;
|
||
3.3
|
||
To minimize disruptions to the operational Cospas-Sarsat system, an operational MCC
|
||
that has been recommissioned to meet new Cospas-Sarsat requirements may be permitted
|
||
to distribute data to its SPOCs (and to other MCCs within its Data Distribution Region,
|
||
in the case of a nodal MCC) during the IOC phase of its operation, provided that the MCC
|
||
has met all applicable Cospas-Sarsat performance requirements.
|
||
3.4
|
||
On reaching the FOC date, the nodal MCC should confirm to all MCCs and the Secretariat
|
||
that all necessary procedures have been established; and
|
||
3.5
|
||
Commissioning of an MCC by the Cospas-Sarsat Council and the attribution of IOC and
|
||
FOC dates are without prejudice to any bilateral discussions on service areas.
|
||
- END OF ANNEX F -
|
||
|
||
G-1
|
||
|
||
ANNEX G
|
||
DECLARATION OF DMCC ON OPERATOR CAPABILITY
|
||
Note:
|
||
The following declaration is to be provided to the HMCC prior to the integration test
|
||
and formal commissioning.
|
||
The DMCC declares that its operators have been trained to use the equipment installed at the
|
||
DMCC, and are capable of performing all necessary functions, including those listed in the table
|
||
that follows, without the need for external support.
|
||
The DMCC also declares that it is fully capable of receiving and processing data from the
|
||
LEOSAR, MEOSAR, and GEOSAR systems.
|
||
The DMCC also declares that once it has been commissioned and confirmed at Initial Operations
|
||
Capability (IOC), it will be fully staffed and operational 24 hours per day, seven days per week.
|
||
18Table G-1: Operator Capability
|
||
No.
|
||
TASK
|
||
Reference C/S A.005
|
||
YES
|
||
NO
|
||
|
||
Selectively report alert data for a particular beacon
|
||
3.10.1
|
||
|
||
Selectively suppress or process transmission of alert data
|
||
for a particular beacon
|
||
3.1.5, 4.3 & 5.10.1
|
||
|
||
Retransmit a specified message
|
||
3.10
|
||
|
||
Respond to direct requests from MCCs and SPOCs
|
||
3.1.2
|
||
|
||
Retrieve information on request
|
||
3.10 & 5.10.4
|
||
|
||
Use all identified communication links
|
||
3.4.7
|
||
|
||
Monitor its national ground segment
|
||
3.6
|
||
|
||
Account for all messages received and transmitted
|
||
3.1.3
|
||
|
||
Transmit narrative messages SIT 915, SIT 925 and
|
||
SIT 605
|
||
3.5.3
|
||
|
||
Access a beacon register
|
||
3.9, 5.10.3 & 5.10.4
|
||
|
||
Notify status if an anomaly is detected & implement
|
||
backup
|
||
3.6.5, 3.7 & 5.10.2
|
||
|
||
Manage the processing of orbit and calibration data
|
||
received at the MCC
|
||
3.5.4
|
||
- END OF ANNEX G –
|
||
|
||
H-1
|
||
|
||
ANNEX H
|
||
DECLARATION OF DMCC INITIAL OPERATIONAL CAPABILITY
|
||
Minimum information to be given by the Host MCC when declaring an MCC at IOC:
|
||
•
|
||
Date / Time IOC declared for .......... MCC (ID):
|
||
.....................
|
||
•
|
||
This MCC is a LEOSAR-GEOSAR-MEOSAR-capable MCC.
|
||
•
|
||
MCC Contact numbers for alerts:
|
||
Primary
|
||
..............................
|
||
Secondary
|
||
..............................
|
||
Other
|
||
..............................
|
||
•
|
||
Person to person contact numbers:
|
||
E-Mail Address:
|
||
.............................................
|
||
MCC Telephone:
|
||
.............................................
|
||
MCC Fax:
|
||
.............................................
|
||
Officer-In-Charge Name:
|
||
.............................................
|
||
•
|
||
GEOSORT Search & Rescue regions supported:
|
||
•
|
||
Associated LUT(s)1:
|
||
•
|
||
City:
|
||
............................................
|
||
•
|
||
LUT ID:
|
||
............................................
|
||
•
|
||
LUT Antenna Position(s):
|
||
............................................
|
||
•
|
||
LUT Commissioned
|
||
and Report Submitted to the Secretariat (Yes / No): …………
|
||
•
|
||
Maximum Number of Alerts Requested After Position Confirmation:
|
||
…………
|
||
•
|
||
Commissioned Capabilities of Associated MEOLUT(s)2:
|
||
…………………………
|
||
- END OF ANNEX H –
|
||
- END OF DOCUMENT -
|
||
1 This section is only required if the MCC has one or more associated LUTs. One copy of this section shall be
|
||
completed for each associated LUT.
|
||
2 Including MEOSAR IOC requirements for DOA position accuracy and EHE reliability (reported separately for FGBs
|
||
and SGBs), the MEOSAR IOC requirement for a low processing anomaly rate (reported separately for FGBs and
|
||
SGBs), and the requirement for fast-moving beacon location accuracy (reported separately for FGBs and SGBs).
|
||
|
||
Cospas-Sarsat Secretariat
|
||
1250 boulevard René-Lévesque West, Suite 4215, Montréal, Québec H3B 4W8 Canada
|
||
Telephone: + 1 514 500 7999
|
||
Fax: + 1 514 500 7996
|
||
Email: mail@cospas-sarsat.int
|
||
Website www.cospas-sarsat.int |