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.
1309 lines
57 KiB
Markdown
1309 lines
57 KiB
Markdown
---
|
||
title: "G008: Operational Requirements For"
|
||
description: "Official Cospas-Sarsat G-series document G008"
|
||
sidebar:
|
||
badge:
|
||
text: "G"
|
||
variant: "note"
|
||
# Extended Cospas-Sarsat metadata
|
||
documentId: "G008"
|
||
series: "G"
|
||
seriesName: "General"
|
||
documentType: "overview"
|
||
isLatest: true
|
||
issue: 1
|
||
revision: 3
|
||
documentDate: "October 2014"
|
||
---
|
||
|
||
> **📋 Document Information**
|
||
>
|
||
> **Series:** G-Series (General)
|
||
> **Version:** Issue 1 - Revision 3
|
||
> **Date:** October 2014
|
||
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)
|
||
|
||
---
|
||
|
||
# **OPERATIONAL REQUIREMENTS FOR** **COSPAS-SARSAT SECOND-GENERATION** **406-MHz BEACONS**
|
||
|
||
### C/S G.008 Issue 1 - Revision 3 October 2014
|
||
|
||
**OPERATIONAL REQUIREMENTS FOR COSPAS-SARSAT**
|
||
|
||
**SECOND GENERATION 406 MHz BEACONS**
|
||
|
||
|
||
**History**
|
||
|
||
|
||
**Issue** **Revision** **Date** **Comments**
|
||
|
||
Draft 1 - June 2011 Drafted by JC-25 (document name changed from
|
||
C/S R.017 to C/S G.008)
|
||
|
||
1 - October 2011 Approved by the Cospas-Sarsat Council (CSC-47)
|
||
|
||
1 1 October 2012 Approved by the Cospas-Sarsat Council (CSC-49)
|
||
|
||
1 2 October 2013 Approved by the Cospas-Sarsat Council (CSC-51)
|
||
1 3 October 2014 Approved by the Cospas-Sarsat Council (CSC-53)
|
||
|
||
**TABLE OF CONTENTS**
|
||
|
||
|
||
1. INTRODUCTION ........................................................................................................... 1-1
|
||
1.1 Purpose of the Document ..................................................................................... 1-1
|
||
1.2 Background .......................................................................................................... 1-1
|
||
1.3 Scope .................................................................................................................... 1-2
|
||
1.4 Methodology of Operational Requirements Development .................................. 1-3
|
||
|
||
|
||
2. ASSUMPTIONS AND CONSTRAINTS........................................................................ 2-1
|
||
2.1 Assumptions ......................................................................................................... 2-1
|
||
2.2 Constraints ........................................................................................................... 2-2
|
||
2.3 System Background and Definitions ................................................................... 2-2
|
||
|
||
|
||
3. MINIMUM OPERATIONAL REQUIREMENTS.......................................................... 3-1
|
||
3.1 Compatibility with the Cospas-Sarsat System ..................................................... 3-1
|
||
3.2 Independent Location Capability ......................................................................... 3-2
|
||
3.3 Independent Location Accuracy .......................................................................... 3-3
|
||
3.4 First Burst Transmission Timeliness ................................................................... 3-4
|
||
3.5 Increased Performance in First Thirty Seconds of Distress Alert
|
||
Transmission ........................................................................................................ 3-5
|
||
3.6 Beacon Unique Identification .............................................................................. 3-5
|
||
3.7 Beacon Message Content ..................................................................................... 3-6
|
||
3.8 Operating Life Time ............................................................................................ 3-8
|
||
3.9 Temperature Range of Operation......................................................................... 3-9
|
||
3.10 Self-Test Function .............................................................................................. 3-10
|
||
3.11 Cancellation Function of False Alert by User .................................................... 3-10
|
||
3.12 Indicator of Beacon Activation .......................................................................... 3-11
|
||
3.13 Verification of Beacon Registration .................................................................. 3-11
|
||
3.14 Homing and on-Scene Locating ......................................................................... 3-12
|
||
|
||
|
||
4. OBJECTIVE OPERATIONAL REQUIREMENTS ....................................................... 4-1
|
||
4.1 Encoded Location Data ........................................................................................ 4-1
|
||
4.2 Encoded Location Accuracy ................................................................................ 4-2
|
||
4.3 Message Content .................................................................................................. 4-3
|
||
4.4 ELT Activated in Flight ....................................................................................... 4-4
|
||
4.5 Return Link Capability ........................................................................................ 4-6
|
||
4.6 Battery Status Indicator........................................................................................ 4-6
|
||
|
||
**LIST OF ANNEXES**
|
||
|
||
ANNEX A - Glossary/Terminology A-1
|
||
|
||
|
||
1 - 1 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**1.** **INTRODUCTION**
|
||
|
||
**1.1** **Purpose of the Document**
|
||
|
||
The purpose of this document is to capture the high-level operational requirements for second
|
||
generation 406 MHz beacons designed to operate with the Cospas-Sarsat System. These
|
||
requirements will be used by Cospas-Sarsat to develop and manage detailed specifications and
|
||
type approval procedures for a second generation of 406 MHz distress beacons designed to
|
||
operate with the planned Cospas-Sarsat systems. The operational requirements describe what
|
||
functionality, performance or information the distress beacon is expected to provide; however,
|
||
they do not describe how the beacon must provide it.
|
||
|
||
In addition to the high-level operational requirements, the rationale for each requirement and the
|
||
dependencies associated with meeting that requirement are provided in this document.
|
||
Furthermore, where appropriate, a minimum level of performance is provided along with a
|
||
desired performance level. These requirements are not intended for use by manufacturers as
|
||
specifications to design, develop or manufacture distress beacons. Cospas-Sarsat specifications
|
||
and type approval procedures for the second generation of 406 MHz beacons will be provided in
|
||
separate documents (new System documents C/S T.101 and C/S T.107). National
|
||
Administrations may have additional requirements and approval standards applicable to specific
|
||
types of beacons.
|
||
|
||
**1.2** **Background**
|
||
|
||
The International Cospas-Sarsat System has been successfully operating since 1982 and has
|
||
achieved world-wide recognition as a provider of satellite distress alerts to search and rescue
|
||
(SAR) authorities. The carriage of Cospas-Sarsat distress beacons on board aircraft [1] and ships [2]
|
||
is mandated by Administrations in accordance with the recommendations of the International
|
||
Civil Aviation Organization (ICAO) and the International Maritime Organization (IMO). Their
|
||
use on board fishing vessels, pleasure craft and general aviation aircraft is also a requirement in
|
||
numerous countries. Furthermore, non-mandated usage of distress beacons is becoming
|
||
increasingly popular among individuals at risk in difficult or dangerous environments [3] .
|
||
|
||
|
||
1 Emergency Locator Transmitters (ELTs) are carried onboard aircraft.
|
||
2 Emergency Position Indicating Radio Beacons (EPIRBs) are carried onboard ships.
|
||
3 Distress beacons used by individuals in various environments are called Personal Locator Beacons (PLBs).
|
||
|
||
|
||
1 - 2 C/S G.008 – Issue 1- Rev.3
|
||
|
||
The LEOSAR and GEOSAR systems comprise the current operational Space Segment. CospasSarsat is now developing a new satellite alerting capability, the MEOSAR system, which is
|
||
planned to begin operating in the 2012 - 2015 timeframe. The MEOSAR system will be
|
||
backward compatible and will accommodate the operation of first-generation Cospas-Sarsat
|
||
beacons as specified in document C/S T.001. The MEOSAR system is also expected to provide
|
||
enhanced performance for all 406 MHz beacons, to include global, near-instantaneous alerting
|
||
and locating capabilities and greater resilience to beacon-to-satellite obstructions, and allow for a
|
||
return link to the beacon. Detailed information on MEOSAR system development is available in
|
||
the document C/S R.012 “Cospas-Sarsat 406 MHz MEOSAR Implementation Plan”.
|
||
|
||
**1.3** **Scope**
|
||
|
||
This requirements document describes the high-level interface between Cospas-Sarsat 406 MHz
|
||
distress beacons (hereafter referred to as “beacon”) and the planned Cospas-Sarsat Space and
|
||
Ground Segments. It applies to all beacon types including Emergency Locator Transmitters
|
||
(ELTs), Emergency Position-Indicating Radio Beacons (EPIRBs), Personal Locator Beacons
|
||
(PLBs), but excluding Ship Security Alerting System (SSAS) transmitters. These requirements
|
||
do not preclude the development and integration of additional auxiliary functions and features.
|
||
|
||
As part of Strategic Goal 1 (Continuous and effective System operations) defined in document
|
||
C/S P.016, the Cospas-Sarsat Strategic Plan, Objective 7 calls for the implementation of the
|
||
MEOSAR space and ground segments. Objective 7 includes the following actions:
|
||
|
||
|
||
- Action 2: “consider possible new or revised specifications and type approval standards
|
||
for beacons operating with the MEOSAR system that would enhance performance,
|
||
provide new capabilities and/or allow lower beacon costs”; and
|
||
|
||
- Action 5: “plan for the implementation of a return link capability”.
|
||
|
||
Strategic Goal 5 in document C/S P.016 (a robust industrial base to support system operations)
|
||
includes Objective 3 to “consider opportunities to lower beacon costs and improve beacon
|
||
capabilities and performance” and specifically an action aiming to “provide timely review of
|
||
new technology developments and investigate proposals that could lower the cost or increase the
|
||
functionality of 406 MHz beacons”.
|
||
|
||
Document C/S G.008 provides the background for undertaking the actions of Strategic Goal 1,
|
||
Objective 7 and Strategic Goal 5, Objective 3 quoted above. In particular, it defines and
|
||
analyses users’ and customers’ requirements that should guide the development of new or
|
||
revised specifications. The GEOSAR, LEOSAR and MEOSAR system characteristics are also
|
||
considered in the trade-off of performance versus costs, in a deliberate effort to maximise cost
|
||
effectiveness and System performance, taking advantage of new technologies while ensuring the
|
||
affordability of beacons for various categories of users.
|
||
|
||
|
||
1 - 3 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**1.4** **Methodology of Operational Requirements Development**
|
||
|
||
These operational requirements were developed based on performance requirements established
|
||
by the Fourteenth Session of the International Civil Aviation Organization (ICAO) / International
|
||
Maritime Organization (IMO) Joint Working Group on Search and Rescue and reported at the
|
||
IMO COMSAR 12 Meeting as document COMSAR 12/6. The performance requirements
|
||
established by the ICAO/IMO JWG on SAR are also listed at Annex C to document C/S P.016,
|
||
Cospas-Sarsat Strategic Plan, and used as performance criteria to illustrate existing and future
|
||
capabilities of the Cospas-Sarsat System.
|
||
|
||
In addition, input from Rescue Coordination Centres, System users, beacon manufacturers, and
|
||
standards organisations was used to generate these operational requirements.
|
||
|
||
These operational requirements will be presented to ICAO and IMO for their review. CospasSarsat will ensure that each of these requirements is used to develop detailed specifications
|
||
which can be traced back to this document.
|
||
|
||
The description of these requirements, their application to second generation beacons operating
|
||
with the Cospas-Sarsat satellite system and their translation into specifications and type approval
|
||
standards are managed by the Cospas-Sarsat Council.
|
||
|
||
|
||
- END OF SECTION 1
|
||
|
||
2 - 1 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**2.** **ASSUMPTIONS AND CONSTRAINTS**
|
||
|
||
**2.1** **Assumptions**
|
||
|
||
First generation 406 MHz beacons were designed to operate with the Cospas-Sarsat LEOSAR
|
||
system which includes on board Search and Rescue Processor (SARP) and Search and Rescue
|
||
Repeater (SARR) instruments. SARP instruments allow on-board processing, storage and
|
||
rebroadcast of beacon message contents and frequency measurement results, and provide global
|
||
coverage with independent location capability.
|
||
|
||
First generation 406 MHz beacons are also compatible with the Cospas-Sarsat GEOSAR system.
|
||
The MEOSAR system is being designed to ensure full backward compatibility with these
|
||
beacons and accommodate their operation. However, beacons designed to meet document
|
||
C/S T.001 specifications and document C/S T.007 type approval standards may not achieve
|
||
some of the minimum or objective requirements for second generation beacons provided in this
|
||
document.
|
||
|
||
The LEOSAR SARP on board processing constraints limit the possible evolution of first
|
||
generation beacon specifications. Second generation beacons designed to revised specifications
|
||
aiming to meet the requirements of this document may not be interoperable with the LEOSAR
|
||
SARP processing. If second generation beacons are not interoperable with LEOSAR SARP
|
||
instruments, the LEOSAR system will not provide the alerting and locating functions for these
|
||
beacons on a global basis.
|
||
|
||
Second generation beacon operational requirements have been developed assuming operation
|
||
with the Cospas-Sarsat GEOSAR and MEOSAR systems comprising only on orbit SARR
|
||
instruments, with all signal and data processing performed by ground receiving stations called
|
||
Local User Terminals or LUTs. It is assumed that a complete network of MEOLUTs will be
|
||
available to provide the alerting and locating functions on a global basis for both first and second
|
||
generation 406 MHz beacons, albeit with different performance levels.
|
||
|
||
New processing software will be required and eventually implemented in existing GEOLUTs to
|
||
provide the alerting service for second generation beacons. Existing LEOLUTs may be
|
||
upgraded to process second generation beacon signals relayed via LEOSAR satellite repeaters
|
||
(SARR).
|
||
|
||
Some Participants have developed MEOLUTs in support of the MEOSAR system development.
|
||
These MEOLUTs could require upgrades if warranted by the second generation beacon design.
|
||
|
||
Finally, software upgrades will also be implemented in Cospas-Sarsat Mission Control Centres
|
||
(MCCs) to forward and distribute distress alerts originating from second generation beacons to
|
||
Rescue Coordination Centres (RCCs) and SAR Points of Contact (SPOCs).
|
||
|
||
|
||
2 - 2 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**2.2** **Constraints**
|
||
|
||
The current GEOSAR space segment is in operation and the planned MEOSAR space segment
|
||
has already been designed. Requirements for second generation beacons will be constrained by
|
||
the characteristics of these constellations and the design of their Search and Rescue instruments.
|
||
|
||
The GEOSAR and MEOSAR constellations will consist of various satellite systems which could
|
||
introduce variations of performance levels due to system design differences. Minimum interface
|
||
requirements [4] have been established to minimise such variations and ensure full interoperability
|
||
with commissioned space and ground segment equipment in the Cospas-Sarsat System.
|
||
|
||
The minimum interface requirements and performance characteristics of satellite repeaters and
|
||
ground segment processing equipment in the GEOSAR and MEOSAR systems are the basic
|
||
constraints to be taken into consideration in the cost and benefit trade-offs for the development
|
||
of second generation beacon requirements.
|
||
|
||
Another aspect of the above constraints is to ensure that beacon technology is available at
|
||
reasonable cost, allowing second generation beacons to meet requirements when operating with
|
||
the MEOSAR and GEOSAR systems. Requirements addressing the timeliness and accuracy of
|
||
alert data, or desirable new features associated with the distress alerting function must be
|
||
assessed in terms of affordability for various categories of users as well as in terms of technical
|
||
feasibility. For example, the size of the beacon will be the result of a trade-off between users’
|
||
needs, manufacturer’s cost and battery size, thus affecting the length of time the beacon can
|
||
operate.
|
||
|
||
**2.3** **System Background and Definitions**
|
||
|
||
|
||
**2.3.1** **MEOSAR System**
|
||
|
||
The MEOSAR system is designed to provide:
|
||
|
||
a. baseline performance for existing first generation beacons, as described in
|
||
|
||
document C/S R.012 “Cospas-Sarsat 406 MHz MEOSAR Implementation Plan”,
|
||
and
|
||
|
||
b. enhanced performance with use of second generation beacons.
|
||
|
||
|
||
4 See the “Minimum Performance Requirements for MEOSAR Compatibility with the 406 MHz
|
||
Cospas-Sarsat System” and the “MEOSAR Space Segment Interoperability Parameters” provided at
|
||
Annexes E and F of document C/S R.012 (MIP), respectively.
|
||
|
||
|
||
2 - 3 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**2.3.2** **Minimum and Objective Operational Requirements**
|
||
|
||
**Minimum Operational Requirements** are applicable to all second generation beacons.
|
||
They provide for effective and efficient detection and location of a beacon which
|
||
facilitate the rescue of the persons in distress. Although current technology may not
|
||
allow meeting some minimum operational requirements in a cost effective fashion,
|
||
these requirements are targets which will drive future innovation and specifications.
|
||
|
||
**Objective Operational Requirements** may not apply to all beacons operating within
|
||
the Cospas-Sarsat System. Objective operational requirements provide beacon
|
||
enhancements and allow for desired additional features that may be required for specific
|
||
categories of beacons to meet particular needs and enhance performance in specific
|
||
applications.
|
||
|
||
|
||
- END OF SECTION 2
|
||
|
||
3 - 1 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
**3.** **MINIMUM OPERATIONAL REQUIREMENTS**
|
||
|
||
The following requirements are the minimum operational requirements applicable to all types of
|
||
second generation beacons operating in the Cospas-Sarsat System. These minimum operational
|
||
requirements are consistent with appropriate international regulations. However, additional
|
||
requirements may be applicable to certain types of beacons in accordance with international
|
||
regulations. Competent Administrations are responsible for the enforcement of requirements
|
||
applicable to beacons under their jurisdiction.
|
||
|
||
|
||
**3.1** **Compatibility with the Cospas-Sarsat System**
|
||
|
||
|
||
**3.1.1** **Requirement**
|
||
|
||
Beacons transmitting in the 406.0 - 406.1 MHz frequency band and operating in the
|
||
Cospas-Sarsat System shall not cause harmful interference or degrade the nominal
|
||
system performance.
|
||
|
||
**3.1.2** **Rationale**
|
||
|
||
The Cospas-Sarsat System already accommodates over one million users. At a
|
||
minimum, second-generation beacons must be compatible with the operational CospasSarsat System, as its use is mandated internationally by ICAO and IMO.
|
||
|
||
**3.1.3** **Dependencies**
|
||
|
||
Second generation beacon signals received in the LEOSAR SARP channel and the
|
||
LEOSAR and GEOSAR SARR channels shall not cause harmful interference that
|
||
impact these channels’ performance with existing first generation 406 MHz beacons.
|
||
|
||
Second generation beacon signals received in the LEOSAR and GEOSAR SARR
|
||
channels shall meet applicable performance requirements outlined in documents
|
||
C/S T.002, C/S T.005, C/S T.009 and C/S T.010 when processed by suitably upgraded
|
||
LEOLUTs and GEOLUTs. Operational LEO and GEOLUTs will require software
|
||
changes to accommodate second generation beacons. The more extensive the changes
|
||
required, the higher the cost will be to Ground Segment Providers.
|
||
|
||
At a minimum, LEOLUT and GEOLUT SARR channel processing will have to be
|
||
upgraded to recover valid beacon messages. Depending on the desired degree of
|
||
backward compatibility/interoperability of second generation beacons with the
|
||
|
||
|
||
3 - 2 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
LEOSAR system, LEOLUT SARR channel processing might also be upgraded to
|
||
perform Doppler location computations.
|
||
|
||
While interoperability with the LEOSAR SARP channel may be achieved, second
|
||
generation beacons are not required to be interoperable with the LEOSAR SARP
|
||
channel. Second generation beacons that are not interoperable with the LEOSAR SARP
|
||
channel will not satisfy the requirement for independent location capability and will not
|
||
be accepted for use in the Cospas-Sarsat System until an operational MEOSAR system
|
||
becomes available.
|
||
|
||
However, these interoperability capabilities with the LEO and GEO systems should not
|
||
necessarily be the primary consideration in the definition of second generation beacon
|
||
characteristics. Appropriate changes to documents C/S T.002 and C/S T.009 might be
|
||
required to reflect these limited interoperability capabilities.
|
||
|
||
Second generation beacons shall meet all applicable performance requirements when
|
||
processed in the MEOSAR system.
|
||
|
||
**3.2** **Independent Location Capability**
|
||
|
||
|
||
**3.2.1** **Requirement**
|
||
|
||
The beacon signal shall allow the computation of a location independently of the
|
||
content of the message.
|
||
|
||
**3.2.2** **Rationale**
|
||
|
||
Even though many beacons can provide a GNSS location, the primary method of
|
||
location shall be an independent computation by the Cospas-Sarsat System. Having an
|
||
independent location provides secure and reliable location information that can be
|
||
forwarded to the responsible search and rescue authorities.
|
||
|
||
**3.2.3** **Dependencies**
|
||
|
||
This requirement will drive beacon signal characteristics and ground segment
|
||
processing specifications.
|
||
|
||
An adequate number of satellites must be available in proper orbital positions to ensure
|
||
permanent visibility of a minimum of 3 satellites from any location on Earth and
|
||
MEOLUTs must be available with an appropriate geographic distribution to avoid
|
||
coverage gaps in the 2D location capability and provide redundancy.
|
||
|
||
|
||
3 - 3 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
**3.3** **Independent Location Accuracy**
|
||
|
||
|
||
**3.3.1** **Requirements**
|
||
|
||
The beacon shall have first burst transmission characteristics to allow for independent
|
||
location computation.
|
||
|
||
The operational performance requirement is for first burst 2D independent location
|
||
accuracy within 5 km, 90% of the time.
|
||
|
||
The beacon shall have transmission characteristics to allow for improved accuracy of
|
||
independent location computation over time.
|
||
|
||
The operational performance requirement is for 2D independent location accuracy of:
|
||
|
||
- 5 km, 95% of the time, within 30 seconds after beacon activation,
|
||
|
||
- 1 km, 95% of the time, within 5 minutes after beacon activation, and
|
||
|
||
- 100 m, 95% of the time, within 30 minutes after beacon activation.
|
||
|
||
_After the first 30 minutes of beacon activation the 2D independent location accuracy_
|
||
_computation shall provide a location within 100m, 95% of the time within 30 minutes of_
|
||
_receiving any burst._
|
||
|
||
**3.3.2** **Rationale**
|
||
|
||
Timely, accurate and reliable location information is crucial to SAR authorities.
|
||
Survival rates at sea or on land are dependent on the time required to reach the scene of
|
||
the accident. In the first 5 minutes after a beacon is activated, a distress location with a
|
||
coarse accuracy is sufficient to allow rescue forces to send assets to the general area of
|
||
the alert. As the SAR operation progresses, more accurate location data is required to
|
||
better assist the response effort.
|
||
|
||
**3.3.3** **Dependencies**
|
||
|
||
This requirement will drive beacon signal characteristics and ground segment
|
||
processing specifications.
|
||
|
||
Parts of this requirement may be difficult to achieve. The cost benefit trade-off between
|
||
the performance requirement and beacon and MEOLUT costs needs to be investigated.
|
||
There is a cost trade-off in terms of waveform characteristics and specified location
|
||
accuracy requirements. This could also lead to strict constraints on LUT processing
|
||
algorithms, making them less flexible.
|
||
|
||
|
||
3 - 4 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
If the requirement also pertains to moving objects in distress, the maximum velocity of
|
||
the object, the need for three dimensional location data and associated location accuracy
|
||
requirements must be investigated further.
|
||
|
||
Space Segment: - number of satellites
|
||
|
||
- satellite performance
|
||
|
||
Ground Segment: - LUT performance
|
||
|
||
- TOA and FOA measurement accuracy
|
||
|
||
**3.4** **First Burst Transmission Timeliness**
|
||
|
||
**3.4.1** **Requirement**
|
||
|
||
The beacon shall transmit a valid message within [3] seconds after activation. The
|
||
transmission shall meet appropriate signal characteristics.
|
||
|
||
**3.4.2** **Rationale**
|
||
|
||
This requirement supports the need for detection and location immediately after
|
||
activation. The objective is to reduce the overall system latency from activation to
|
||
delivery to the search and rescue forces. In particular, it provides a better chance that a
|
||
valid alert message will actually be transmitted in a catastrophic event with minimal
|
||
time for transmission, e.g. an aviation crash incident.
|
||
|
||
**3.4.3** **Dependencies**
|
||
|
||
a. The cost benefit trade-off between performance and beacon/MEOLUT costs must
|
||
be investigated.
|
||
|
||
b. The beacon cost could increase substantially if some environmental conditions,
|
||
i.e. extreme temperatures, thermal shock, are to be met on first burst transmission.
|
||
|
||
c. This requirement may be technically very difficult to achieve even if beacon size
|
||
and cost increases were acceptable.
|
||
|
||
d. Mitigation of the potentially large increase in the false alarm rate is dependent on
|
||
the “Cancellation Function” detailed in requirement 3.11. However, this will
|
||
cause additional operational traffic, even if the alert is effectively cancelled.
|
||
|
||
e. Consideration should be given to the timing of float-free EPIRB automatic
|
||
activation under water, noting that the EPIRB may not have reached the surface 3
|
||
seconds after activation.
|
||
|
||
|
||
3 - 5 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
**3.5** **Increased Performance in First Thirty Seconds of Distress Alert Transmission**
|
||
|
||
**3.5.1** **Requirement**
|
||
|
||
The beacon shall have transmission characteristics to allow for enhanced performance
|
||
within the first thirty seconds of activation.
|
||
|
||
The operational performance requirement is for a 99.9% probability of detection of at
|
||
least one valid beacon message within 30 seconds after activation and independent
|
||
location accuracy as defined in section 3.3.
|
||
|
||
**3.5.2** **Rationale**
|
||
|
||
Analysis of previous incidents has shown that some beacons fail within the first
|
||
30 seconds of a distress situation. It is also important to detect and locate a beacon as
|
||
soon as possible in all distress cases. By improving the characteristics of the beacon
|
||
performance in the first 30 seconds it is possible to increase the probability of receiving
|
||
an alert. It may not be practical to sustain this level of performance beyond a certain
|
||
timeframe so that other requirements may be met, such as the operating life time.
|
||
|
||
**3.5.3** **Dependencies**
|
||
|
||
Enhanced detection and independent location performance may be achieved by higher
|
||
repetition rate of the message or increased power of the transmitted signal. However,
|
||
trade-offs in terms of global system performance will be required as illustrated below.
|
||
|
||
a. Risks associated with increased repetition rates are burst collisions, increased false
|
||
alarm rates. Longer protocols may also increase the possibility of message
|
||
collisions in time.
|
||
|
||
b. Increased power may not be a practical proposition, since it has an impact on
|
||
beacon cost and size.
|
||
|
||
**3.6** **Beacon Unique Identification**
|
||
|
||
**3.6.1** **Requirement**
|
||
|
||
Each beacon must be uniquely identified.
|
||
|
||
|
||
3 - 6 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
**3.6.2** **Rationale**
|
||
|
||
This requirement is essential to preclude possible confusion of alert data processing,
|
||
confusion of measurements for independent location calculations and for the purpose of
|
||
MCC, RCC, and SPOC operations and registration database lookup.
|
||
|
||
By ensuring that beacons have unique identifications, situations where a rescue response
|
||
is delayed or cancelled due to the investigation of conflicting beacon registration
|
||
information will be avoided. Most beacon registration databases prevent a second
|
||
registration for the same identifier, which may result in at least one beacon not being
|
||
registered. Duplicate registrations or absence of registration could put lives at risk and
|
||
expend SAR resources needlessly.
|
||
|
||
**3.6.3** **Dependencies**
|
||
|
||
A level of compliance already exists. However, SAR authorities and national
|
||
Administrations should specify what types of unique identification will be required in
|
||
the future, i.e. serial, MMSI, etc.
|
||
|
||
|
||
**3.7** **Beacon Message Content**
|
||
|
||
**3.7.1** **Requirement**
|
||
|
||
The beacon shall transmit a message providing at least the following information. This
|
||
information is considered essential and shall be transmitted within every message burst.
|
||
|
||
a. Identification (ID): To be used for MCC, RCC, and SPOC operations and for
|
||
Registration Database lookup. The identification shall include:
|
||
|
||
- a country code,
|
||
|
||
- additional information that uniquely identifies the beacon when combined
|
||
with the country code, and
|
||
|
||
- Type Approval Certificate (TAC) number.
|
||
|
||
b. Beacon type: Identifier of the beacon type (ELT, EPIRB, PLB, SSAS, Test,
|
||
Orbitography, Multi-Environment, plus nine spares). *
|
||
|
||
c. Type of homing/locating device: Identifier for the technology supported by the
|
||
beacon for on-site location (121.5 MHz homer, 9 GHz SART, AIS, 406 MHz
|
||
homer, plus four spares). *
|
||
|
||
d. Homing device activation: Confirmation of homing device status.
|
||
|
||
|
||
3 - 7 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
e. Self-Test: Used to reduce false alerts and allow service functionality tests.
|
||
|
||
f. User cancellation: Positive confirmation of non-distress or false alert.
|
||
|
||
g. Encoded location: Location data derived as defined in section 4.1, with the
|
||
accuracy required per section 4.2.
|
||
|
||
h. Vessel (MMSI)/Aircraft ID: Identification of the vessel or aircraft on which the
|
||
beacon is carried, to be used for the MCC, RCC and SPOC operations and for
|
||
Registration Database lookup.
|
||
|
||
i. Spare bits: Allows for future requirements.
|
||
|
||
- Provided in alert message from MCC with information derived from TAC database.
|
||
|
||
**3.7.2** **Rationale**
|
||
|
||
Alert messages must contain sufficient information to aid SAR authorities’ response to a
|
||
distress situation. The minimum requirements are listed above and provide mandatory
|
||
data fields. However, there may be other data fields in the message to further assist
|
||
rescue forces. Such additional fields could provide secondary information about the
|
||
beacon and parent craft when registration data is not available. The rationale for each of
|
||
the fields specified above is summarised below:
|
||
|
||
a. ID: Required to ensure correct processing of data. Allows RCCs and SPOCs to
|
||
obtain information on parent craft and user that helps SAR response planning or
|
||
false alert resolution.
|
||
|
||
b. Beacon type: Support SAR response planning by RCCs and SPOCs.
|
||
|
||
c. Type of homing device: Support SAR response planning by RCCs and SPOCs
|
||
and on scene response by SAR forces.
|
||
|
||
d. Homing device activation: Provides confirmation to SAR response that the
|
||
homing device activated and allows for planning and on scene response.
|
||
|
||
e. Self-Test: Used to reduce false alerts and allow service functionality tests.
|
||
|
||
f. User Cancellation: Positive confirmation of non-distress or false alert allowing
|
||
SAR response to terminate mission in a timely manner.
|
||
|
||
|
||
3 - 8 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
g. Encoded Location: Provides confirmation of independent location data and a
|
||
geographic location through the GEO system (if data is available from an external
|
||
of integrated GNSS receiver).
|
||
|
||
h. Vessel (MMSI)/Aircraft ID (transmitted with equal priority and availability as the
|
||
beacon ID): Provides essential identification for beacons, so that RCCs and
|
||
SPOCs can obtain information that helps SAR response planning or false alert
|
||
resolution, which may reduce time for a SAR response.
|
||
|
||
i. Spare Bits: Allows for future expansion and growth.
|
||
|
||
**3.7.3** **Dependencies**
|
||
|
||
a. Existing beacon protocols and equipment constrain future flexibility. Duplicate
|
||
IDs must be avoided to ensure successful alert processing.
|
||
|
||
b. A common format must be internationally agreed.
|
||
|
||
**3.8** **Operating Life Time**
|
||
|
||
|
||
**3.8.1** **Requirement**
|
||
|
||
The beacon shall operate at specified temperature extremes and meet all required signal
|
||
characteristics for a minimum of 24 hours.
|
||
|
||
**3.8.2** **Rationale**
|
||
|
||
The beacon must be able to operate for a length of time to support the response of
|
||
search and rescue forces and recovery of survivors to places of safety.
|
||
|
||
The value of 24 hours has historically been used by Cospas-Sarsat as the minimum
|
||
requirement. National Administrations and intergovernmental organisations may have
|
||
more stringent requirements for beacon operating life time.
|
||
|
||
**3.8.3** **Dependencies**
|
||
|
||
A trade-off between performance requirements and beacon characteristics (battery
|
||
capacity, beacon size and cost) is required. While longer operating life time may be
|
||
required at sea, the lowest operating temperature (-40ºC) is rarely met by EPIRBs.
|
||
Furthermore, the continuous, worldwide capability of the MEOSAR system to provide
|
||
near real-time alerting and locating functions limits the need for a longer operating life
|
||
|
||
|
||
3 - 9 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
time. A trade off may be possible between the repetition rate of transmissions and the
|
||
operating life time.
|
||
|
||
|
||
**3.9** **Temperature Range of Operation**
|
||
|
||
**3.9.1** **Requirement**
|
||
|
||
The temperature range is defined by the maximum and minimum temperatures at which
|
||
the beacon shall be able to operate and meet all required signal characteristics.
|
||
|
||
Two classes of beacon have been defined, which correspond to the following ranges of
|
||
operating temperatures:
|
||
|
||
Class 1: -40 C to + 55 C.
|
||
|
||
Class 2: -20 C to + 55 C.
|
||
|
||
The beacon shall be able to withstand a thermal-shock range of 50 C.
|
||
|
||
**3.9.2** **Rationale**
|
||
|
||
Cospas-Sarsat is a global system and its beacons can be operated in varying
|
||
environmental extremes. A range of operating temperatures is required to properly
|
||
design and power a Cospas-Sarsat beacon and ensure minimum performance
|
||
requirements are met.
|
||
|
||
**3.9.3** **Dependencies**
|
||
|
||
a. Thermal shock has an impact on performance, especially during initial burst
|
||
transmissions.
|
||
|
||
b. The requirement to operate at minimum temperature and meet all signal
|
||
characteristics for the minimum operating life time has a major impact on beacon
|
||
design and battery capacity requirements, hence the beacon cost, size and weight.
|
||
|
||
**3.10** **Self-Test Function**
|
||
|
||
|
||
**3.10.1** **Requirement**
|
||
|
||
The beacon shall include a self-test function which shall provide to the user a
|
||
confirmation that the core functionalities of the beacon are working properly and that a
|
||
self-test message has been emitted in accordance with Cospas-Sarsat requirements.
|
||
|
||
|
||
3 - 10 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
The self test message transmission shall meet all applicable Cospas-Sarsat requirements
|
||
and shall not impact the performance of the operational system. In particular, the selftest transmission shall not be confused with an operational distress transmission when
|
||
processed by any Cospas-Sarsat satellite channel (i.e. LEO, GEO and MEO).
|
||
|
||
The number of self test transmissions should be limited to avoid possible abuses, such
|
||
as tracking applications.
|
||
|
||
|
||
**3.10.2** **Rationale**
|
||
|
||
The self-test function will allow the user and/or service inspectors to test the
|
||
functionality of the beacon without impacting the system operation and SAR services,
|
||
thus reducing the number of false alerts. For some users it is mandatory to test the
|
||
beacon regularly.
|
||
|
||
**3.10.3** **Dependencies**
|
||
|
||
A more specific definition is required in terms of functionality and impact on
|
||
performance.
|
||
|
||
Several self-test transmission types may be required to test the various beacon
|
||
functionalities (e.g. with or without encoded location data).
|
||
|
||
In accordance with Requirement 3.13 (Verification of Beacon Registration), the self-test
|
||
function will be used to display the registration status of the beacon.
|
||
|
||
|
||
**3.11** **Cancellation Function of False Alert by User**
|
||
|
||
|
||
**3.11.1** **Requirement**
|
||
|
||
In case of an inadvertent activation, the beacon shall be capable of transmitting a
|
||
message indicating that previous transmissions were a false alert. The protocol and
|
||
transmission sequence of false alert cancellation messages shall be standardised. This
|
||
should be a separate function from the on/off capability.
|
||
|
||
The beacon shall have characteristics to ensure that a cancellation message is valid
|
||
100% of the time. A cancellation message shall be received 90% of the time within 5
|
||
minutes of the cancellation function being activated.
|
||
|
||
|
||
3 - 11 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
**3.11.2** **Rationale**
|
||
|
||
The cancellation function will help reduce the use of SAR assets for non distress
|
||
situations. SAR services need a positive indication from the user transmitting an alert
|
||
that a SAR response is not required.
|
||
|
||
**3.11.3** **Dependencies**
|
||
|
||
National administrations’ acceptance of beacons having a cancellation function will
|
||
have operational and legal implications. More details on the performance parameters of
|
||
this function are needed (i.e. probability of receipt within [x] minutes).
|
||
|
||
Note that this requirement should not be applicable to SSAS beacons.
|
||
|
||
**3.12** **Indicator of Beacon Activation**
|
||
|
||
|
||
**3.12.1** **Requirement**
|
||
|
||
Visual indicators shall be provided to alert beacon users that their beacon is activated.
|
||
|
||
For beacons which can be remotely activated, the indicators should be attached to both
|
||
the remote activation device and the beacon.
|
||
|
||
**3.12.2** **Rationale**
|
||
|
||
The user should be notified that the beacon is in operation. This indication will
|
||
facilitate recognition of an inadvertent activation and allow notification of SAR
|
||
responders.
|
||
|
||
**3.12.3** **Dependencies**
|
||
|
||
Battery and beacon size and cost trade-offs.
|
||
|
||
|
||
**3.13** **Verification of Beacon Registration**
|
||
|
||
|
||
**3.13.1** **Requirement**
|
||
|
||
The beacon shall be designed such that the registration status of the beacon is displayed
|
||
to the beacon user. The registration status shall remain valid for a period of two years.
|
||
|
||
|
||
3 - 12 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
The beacon shall be designed such that the self-test function indicates by default that the
|
||
beacon is not registered. When registration in the appropriate national register or the
|
||
International Beacon Registration Database is accomplished, the self-test function shall
|
||
indicate that the beacon is registered. The “registered” status shall remain valid for a
|
||
period of two years. Upon re-coding of the beacon, the self-test function shall indicate
|
||
the default, non-registered status until proper re-registration is accomplished.
|
||
|
||
When activated in operational distress mode, the beacon shall send the required distress
|
||
message regardless of its registration status.
|
||
|
||
When activated in self test mode, the beacon shall send the required self-test message
|
||
regardless of its registration status.
|
||
|
||
**3.13.2** **Rationale**
|
||
|
||
Registration data is important for supporting lifesaving efforts. MCCs/RCCs/SPOCs use
|
||
the data to reduce the time required to verify that a distress situation is valid and to
|
||
gather additional information to determine the response required. Proper registration
|
||
reduces the time to identify and resolve false alerts.
|
||
|
||
**3.13.3** **Dependencies**
|
||
|
||
National administration acceptance of this feature will have legal implications. This
|
||
requirement may also have procedural and management implications on the CospasSarsat System, including costs to Cospas-Sarsat providers, users and/or Administrations.
|
||
|
||
Implementation and enforcement of this requirement is to be regulated by a National
|
||
Administration. However, the case when a national Administration declines enforcing
|
||
this requirement also needs to be addressed.
|
||
|
||
**3.14** **Homing and on-Scene Locating**
|
||
|
||
|
||
**3.14.1** **Requirement**
|
||
|
||
Beacon design shall provide for homing and on scene locating.
|
||
|
||
**3.14.1.1 Homing Performance**
|
||
|
||
|
||
Any beacon homing signal shall be suitable for detection and homing by a typical
|
||
direction finding unit to an altitude of 10,000 feet (3048 metres) above ground at a
|
||
range of at least 30.0 nautical miles (55.6 kilometres) or the radio line-of-sight horizon
|
||
(whichever is less). The beacon homing signal shall allow SAR Units travelling at
|
||
|
||
|
||
3 - 13 C/S G.008 - Issue 1 – Rev.3
|
||
|
||
speeds between 0 kts (0 kilometres/hour) and 270 kts (500 kilometres/hour), inclusive,
|
||
to support a line of bearing accuracy of ± 5 degrees by a typical direction-finding unit.
|
||
|
||
Note: Homing signal characteristics suitable for detection by a typical direction-finding
|
||
unit will be addressed in the Specification for Second Generation Cospas-Sarsat 406MHz Distress Beacons (C/S T.X01).
|
||
|
||
**3.14.1.2 On-scene Locating Performance**
|
||
|
||
|
||
Beacon design shall allow suitably equipped SAR units, airports and certain other fixed
|
||
and mobile facilities to receive and decode beacon identities and GNSS data, if
|
||
available, encoded in the beacon or homing transmissions sent via 406 MHz to aid SAR
|
||
units in locating the beacon.
|
||
|
||
**3.14.2** **Rationale**
|
||
|
||
Geographic and environmental conditions may require the use of local locating, homing
|
||
or direction finding to complete the rescue. Locating, homing and direction finding
|
||
functions allow for non Cospas-Sarsat systems and organisations to provide notification
|
||
and support for SAR response.
|
||
|
||
**3.14.3** **Dependencies**
|
||
|
||
The 406 MHz burst shall take precedence over any homing and/or location signal.
|
||
Compliance with the Cospas-Sarsat requirements in this section shall not prevent
|
||
compliance with international and/or national requirements for on-scene locating,
|
||
homing, or signal transmission(s) for direction finding.
|
||
|
||
The goal is to implement these requirements with minimum impact to currently fielded
|
||
aircraft and ground 406 MHz direction finding/homing/local location equipment.
|
||
|
||
|
||
- END OF SECTION 3
|
||
|
||
4 - 1 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**4.** **OBJECTIVE OPERATIONAL REQUIREMENTS**
|
||
|
||
The following operational requirements are desirable objectives for second generation beacons
|
||
which may not be applicable to certain types of beacons operating in the Cospas-Sarsat System.
|
||
Competent Administrations are responsible for requirements applicable to beacons under their
|
||
jurisdiction, in accordance with appropriate international regulations. However in order to
|
||
ensure compatibility and interoperability with the Cospas-Sarsat System, any desired
|
||
requirements deemed necessary by Administrations shall be in accordance with the CospasSarsat requirements and specifications.
|
||
|
||
|
||
**4.1** **Encoded Location Data**
|
||
|
||
|
||
**4.1.1** **Requirements**
|
||
|
||
Second generation beacons should be capable of acquiring Global Navigation Satellite
|
||
System (GNSS) position data after activation, using an external or internal GNSS
|
||
device, and storing and retransmitting the information encoded in the beacon message in
|
||
accordance with Cospas-Sarsat Requirements 4.2 and 4.3 (see below).
|
||
|
||
After acquisition of initial position data, the beacon may continuously or periodically
|
||
acquire position updates. In the case when position updates are available, the updated
|
||
position shall be retransmitted in the beacon message at specified time intervals, in
|
||
accordance with Cospas-Sarsat Requirements 4.2 and 4.3 (see below).
|
||
|
||
The location data encoded in the beacon message shall be accompanied by information
|
||
defining the date and time of position acquisition, as specified by Cospas-Sarsat.
|
||
|
||
|
||
**4.1.2** **Rationale**
|
||
|
||
In the case of GEOSAR alerts, encoded position data is the only method for determining
|
||
and providing the distress location to SAR authorities. Encoded GNSS position data in
|
||
the beacon message can be very accurate and, when available, is a valuable substitute or
|
||
complement to the independent position data provided by the MEOSAR system.
|
||
Furthermore, when both the independent MEOSAR and encoded GNSS positions are
|
||
available and match, the “merged” position exhibits a very high degree of reliability
|
||
which can be relied upon by SAR services to plan and conduct the SAR operation.
|
||
|
||
In case of conflicting independent positions, an encoded location is useful to confirm
|
||
the real position and eliminate errors, thus speeding up the rescue operation. As EPIRB
|
||
actual locations may drift, and portable ELTs’ or PLBs’ positions may change with
|
||
|
||
|
||
4 - 2 C/S G.008 – Issue 1- Rev.3
|
||
|
||
time, a date and time must be associated with the encoded data transmitted by the
|
||
beacon.
|
||
|
||
|
||
**4.1.3** **Dependencies**
|
||
|
||
This special capability must be included at the beacon design stage and impacts the
|
||
beacon cost.
|
||
|
||
Ground segment equipment must be capable of processing the beacon message format
|
||
with encoded location data. Special filtering and routing procedures may be required at
|
||
the MCC level. Special processing is required in cases where independent and encoded
|
||
positions do not match.
|
||
|
||
The coding of an accurate position with associated time requires additional processing
|
||
logic and a longer message, which may affect the overall performance of the System in
|
||
terms of capacity, beacon battery size and beacon cost.
|
||
|
||
|
||
**4.2** **Encoded Location Accuracy**
|
||
|
||
|
||
**4.2.1** **Requirement**
|
||
|
||
Encoded locations shall be provided to an accuracy of 30 m in latitude and longitude,
|
||
95% of the time, within 5 minutes of beacon activation.
|
||
|
||
If available, altitude information shall be provided to an accuracy of 50 m, 95% of the
|
||
time, within 5 minutes of beacon activation.
|
||
|
||
The navigation device shall make at least one attempt every 15 minutes to obtain an
|
||
initial location until an initial location is obtained or 2 hours has passed since beacon
|
||
activation.
|
||
|
||
After an initial location is obtained or 2 hours has passed since beacon activation, the
|
||
navigation device shall attempt location updates following the regime set out below:
|
||
|
||
- In the first 6 hours the navigation device shall attempt at least one location update
|
||
every 30 minutes.
|
||
|
||
- Beyond 6 hours a location update shall be attempted at least every 60 minutes for
|
||
the life of the battery.
|
||
|
||
|
||
4 - 3 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**4.2.2** **Rationale**
|
||
|
||
The MEOSAR system is expected to provide accurate independent location
|
||
information. Encoded location data should be provided with the best accuracy
|
||
obtainable from GNSS receivers to significantly enhance System performance. The
|
||
same logic holds for altitude information, if required in some applications.
|
||
|
||
|
||
**4.2.3** **Dependencies**
|
||
|
||
LUTs and MCCs must have the capability to process encoded location data with the
|
||
specified accuracy.
|
||
|
||
High encoded location accuracy may lead to frequent updates, which require special
|
||
processing and may impact ground segment operation costs and complexity.
|
||
|
||
|
||
**4.3** **Message Content**
|
||
|
||
|
||
**4.3.1** **Requirement**
|
||
|
||
|
||
In addition to the essential data fields for the beacon message content defined in section
|
||
3.7 (i.e. Identification (ID), Beacon Type, Type of Homing Device, Homing Device
|
||
Status, User Cancellation, Encoded Location, and Vessel(MMSI)/Aircraft ID, the
|
||
beacon message should provide the following information:
|
||
|
||
a. Elapsed Time: Time elapsed since the beacon was activated (48 hrs.
|
||
maximum with 1 hr. resolution). 50% probability of detection every two
|
||
hours after activation.
|
||
|
||
b. Information providing Time of last encoded location data. 90% probability
|
||
of detection for the first hour after activation, then 50% probability of
|
||
detection every two hours thereafter.
|
||
|
||
c. Altitude of encoded position when applicable. 90% probability of detection
|
||
for the first hour after activation, then 50% probability of detection every
|
||
two hours thereafter.
|
||
|
||
d. Dilution of Precision (DOP) of encoded location. 50% probability of
|
||
detection every two hours after activation.
|
||
|
||
e. Automated / manual activation notification. 50% probability of detection
|
||
every two hours after activation.
|
||
|
||
|
||
4 - 4 C/S G.008 – Issue 1- Rev.3
|
||
|
||
f. Remaining battery capacity, as percentage of the battery capacity required to
|
||
support beacon operation for the required lifetime. 50% probability of
|
||
detection for the first two hours after activation, 90% probability of
|
||
detection every two hours thereafter.
|
||
|
||
|
||
g. Spare bits for future use. Detection probability dependent on future
|
||
capability requirement(s).
|
||
|
||
|
||
h. Reserved spare bits for national use. 90% probability of detection every 30
|
||
minutes.
|
||
|
||
|
||
**4.3.2** **Rationale**
|
||
|
||
High resolution encoded position data should be provided with appropriate data quality
|
||
indicators (i.e. DOP of the computed position) and the associated time and date of
|
||
acquisition.
|
||
|
||
Specific information on the distress situation (type of emergency) can assist SAR
|
||
authorities in planning the SAR operation.
|
||
|
||
|
||
**4.3.3** **Dependencies**
|
||
|
||
Additional data in the beacon message impact its length, the system capacity, battery
|
||
requirements and ultimately the cost of the beacon. In a GEO/MEO system, which
|
||
provides continuous worldwide coverage, alternate transmissions of data contents could
|
||
provide a means of reducing the impact of this requirement on beacons.
|
||
|
||
Specific ground segment equipment processing capabilities may be required.
|
||
|
||
|
||
**4.4** **ELT Activated in Flight**
|
||
|
||
|
||
**4.4.1** **Requirement**
|
||
|
||
Second generation fixed ELTs should have a capability to be triggered while the aircraft
|
||
is still in-flight (prior to an anticipated accident). The ELT could be activated
|
||
automatically (i.e. while in flight and separate from G-switch detection of a crash)
|
||
and/or be manually activated.
|
||
|
||
The automatic in-flight activation should be triggered by a signal originated by the
|
||
aircraft avionics (or its equivalent) after detection of anomalous flight conditions that
|
||
|
||
|
||
4 - 5 C/S G.008 – Issue 1- Rev.3
|
||
|
||
warrant ELT activation as determined by the triggering algorithm. ELTs with automatic
|
||
activation capability should also transmit encoded location data in the beacon message [5] .
|
||
|
||
|
||
**4.4.2** **Rationale**
|
||
|
||
In many aircraft accidents, the violence caused by the high speed of impact destroys the
|
||
ELT or its antenna system, preventing the transmission of an alert. Anomalous flight
|
||
conditions leading to sudden and rapid loss of altitude resulting in a crash can often be
|
||
reliably detected by aircraft avionics and used to trigger ELT transmissions within the
|
||
typical 30-second interval that precedes the crash. Such transmissions would be helpful
|
||
to SAR authorities, particularly when the ELT does not survive the crash.
|
||
|
||
**4.4.3** **Dependencies**
|
||
|
||
ELT transmissions from aircraft in-flight will be affected by likely large Doppler shifts
|
||
induced by aircraft speed that will impact the LEOSAR system Doppler positioning
|
||
capability. Such Doppler position information in most circumstances will be unreliable
|
||
and will need to be appropriately flagged when distributed to SAR agencies or,
|
||
alternatively, filtered out of the alert data. The impact on independent MEOSAR
|
||
location data will have to be investigated further to ensure reliability and evaluate the
|
||
location accuracy achievable.
|
||
|
||
Automatic in-flight activation capability would be highly desirable for in-flight
|
||
triggering of second generation ELTs, but the implementation of this capability might
|
||
be limited in aircraft with less sophisticated avionics (especially small and/or older
|
||
aircraft).
|
||
|
||
Encoded location data (if available as per paragraph 4.1) would serve as a complement
|
||
to and/or confirmation of independent position determination, and as a unique source of
|
||
precise accident position. However the availability of location data from the avionics is
|
||
inherently limited by the characteristics of those avionics. It is assumed that, if an
|
||
aircraft has automatic in-flight activation capability, encoded location data will also be
|
||
available.
|
||
|
||
|
||
5 Second generation fixed ELTs installed in aircraft subject to the “Accident Site Location” provisions of Annex 6
|
||
to the ICAO Convention (under development) will be required to have automatic in-flight activation capability and
|
||
transmission characteristics allowing for the determination of an accident position within 11.1 km (6 NM) (TBC by [5]
|
||
Second generation fixed ELTs installed in aircraft subject to the “Accident Site Location” provisions of Annex 6 to
|
||
the ICAO Convention (under development) will be required to have automatic in-flight activation capability and
|
||
transmission characteristics allowing for the determination of an accident position within 11.1 km (6 NM) (TBC by
|
||
the pending amendment to Annex 6), 95% of the time, whether the location is determined through independent
|
||
location computation or by providing an encoded location.
|
||
|
||
|
||
4 - 6 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**4.5** **Return Link Capability**
|
||
|
||
|
||
**4.5.1** **Requirement**
|
||
|
||
Second generation beacons should be capable of receiving return link messages to
|
||
acknowledge the receipt of the forward link alert transmission and provide ancillary
|
||
information to the person in distress, or trigger ancillary beacon functions.
|
||
|
||
|
||
The operational performance requirement is for receipt of the RLS message sent by the
|
||
Return Link Service Provider (RLSP) within 15 minutes, 99% of the time.
|
||
|
||
**4.5.2** **Rationale**
|
||
|
||
The return link capability can assist the SAR response. It can potentially provide a
|
||
variety of services.
|
||
|
||
|
||
**4.5.3** **Dependencies**
|
||
|
||
The beacon must include a GNSS receiver which accommodates the Return Link
|
||
Service and the appropriate logic function.
|
||
|
||
Information on the return link capability of the transmitting beacon must be sent with
|
||
the forward link alert message and relayed to appropriate contacts (return link service
|
||
provider and/or SAR authorities). This requires a limited upgrade of Cospas-Sarsat
|
||
MCCs.
|
||
|
||
A detailed definition of the various functions which may be supported by the return link
|
||
capability and a thorough demonstration of the potential benefits are required.
|
||
|
||
|
||
**4.6** **Battery Status Indicator**
|
||
|
||
|
||
**4.6.1** **Requirement**
|
||
|
||
A battery status indicator should be provided, separate from the self test function, to
|
||
warn users of depleted batteries which would not meet the expected operation life time
|
||
requirement.
|
||
|
||
A battery status indicator should always be incorporated into beacons powered by
|
||
rechargeable batteries.
|
||
|
||
|
||
4 - 7 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**4.6.2** **Rationale**
|
||
|
||
A visible indication of battery status would enhance the reliability of beacons as
|
||
prematurely depleted batteries could be replaced. This feature would be essential for
|
||
beacons powered by rechargeable batteries as it would help ensure that battery charge is
|
||
properly maintained.
|
||
|
||
|
||
**4.6.3** **Dependencies**
|
||
|
||
The availability of reliable, cost-effective battery status indicators should be verified
|
||
and their reliability in the context of Cospas-Sarsat beacon use should be assessed.
|
||
|
||
A battery status indicator should not supersede the mandated battery replacement date
|
||
for non rechargeable batteries. Adequate warning to this effect should be attached to
|
||
the indicator.
|
||
|
||
|
||
- END OF SECTION 4
|
||
|
||
## **ANNEXES TO DOCUMENT** **OPERATIONAL REQUIREMENTS FOR** **COSPAS-SARSAT SECOND GENERATION** **406 MHz BEACONS** **C/S G.008**
|
||
|
||
|
||
A-1 C/S G.008 – Issue 1- Rev.3
|
||
|
||
**ANNEX A**
|
||
|
||
|
||
**GLOSSARY/TERMINOLOGY**
|
||
|
||
|
||
Alert detection: At least one valid beacon message is produced by a LUT after
|
||
receiving one or several bursts from the same beacon through one
|
||
or several satellite channels.
|
||
|
||
Alert detection probability: Probability of achieving an alert detection within a given time
|
||
|
||
period.
|
||
|
||
Burst detection: Beacon burst received through a single satellite channel (i.e. a
|
||
unique path from beacon to satellite instrument to LUT antenna and
|
||
receiver system) which produces a beacon message and
|
||
measurements of the appropriate signal characteristics (e.g.
|
||
TOA/FOA measurements).
|
||
|
||
Burst detection probability: Probability of obtaining a burst detection within a given time
|
||
|
||
period.
|
||
|
||
Compatibility: A compatible transmission does not create harmful interference that
|
||
impacts the performance of a satellite channel. Systems are
|
||
compatible when they can operate simultaneously with no
|
||
degradation of their respective performance. Compatible systems
|
||
may operate in a given frequency band with different signals to
|
||
provide different functionalities.
|
||
|
||
First burst: First transmission of a 406 MHz message by a beacon after
|
||
activation.
|
||
|
||
First generation beacon: A beacon which complies with the specifications of document
|
||
C/S T.001 and is tested against the type approval standards of
|
||
document C/S T.007.
|
||
|
||
Interoperability: Systems are interoperable when the same transmission can be
|
||
processed by both systems to provide the expected functions with
|
||
the appropriate performance levels. Interoperable systems may
|
||
provide either similar or different functionalities.
|
||
|
||
|
||
A-2 C/S G.008 – Issue 1- Rev.3
|
||
|
||
Independent location: A location computed by the LEOSAR or the MEOSAR system,
|
||
independently of the data encoded in the beacon message. The
|
||
LEOSAR system provides independent beacon locations using a
|
||
Doppler technique based on received beacon burst frequency
|
||
measurements over a LEO satellite pass. The MEOSAR system
|
||
provides independent locations using a triangulation technique
|
||
based on multiple TOA/FOA measurements from burst detections
|
||
received through a number of MEO satellite channels.
|
||
|
||
MEOSAR system: The Cospas-Sarsat MEOSAR system will comprise a space
|
||
segment consisting of several interoperable MEO satellite
|
||
constellations and a ground segment consisting of a number of
|
||
MEOLUTs suitably located around the globe to ensure that beacon
|
||
transmissions, anywhere on the globe, are received by at least one
|
||
MEOLUT via at least three MEOSAR satellite channels.
|
||
|
||
Second generation beacon: A beacon which complies with the specifications of document
|
||
|
||
C/S T.101 and is tested against the type approval standards of
|
||
document C/S T.107.
|
||
|
||
|
||
- END OF ANNEX A
|
||
|
||
- END OF DOCUMENT
|
||
|
||
______________________________________________
|
||
|
||
|
||
Cospas-Sarsat Secretariat
|
||
1250 Boul. René-Lévesque West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada
|
||
|
||
Telephone: +1 514 500 7999 / Fax: +1 514 500 7996
|
||
|
||
[Email: mail@cospas-sarsat.int](mailto:mail@cospas-sarsat.int)
|
||
[Website: www.cospas-sarsat.int](http://www.cospas-sarsat.org/)
|
||
______________________________________________ |