ESPAIS AIS System Study Final Report

ESPAIS Final Report Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 1 of 78 Title: ESPAIS AIS System Study – Final Report Document No.:...
Author: Caren Greer
2 downloads 0 Views 3MB Size
ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 1 of 78

Title:

ESPAIS AIS System Study – Final Report

Document No.:

ESPAIS-OHB-FR-01

Issue:

2

DRD Reference:

-

Prepared by:

ESPAIS Team

Date: 08.12.2010

Checked by:

Frank te Hennepe (OHB)

Date: 08.12.2010

Product Assurance:

-

Date: -

Frank te Hennepe (OHB)

Date: 08.12.2010

Date: 08.12.2010

Project Management:

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 2 of 78

Final Report

Distribution:

Name:

Company / Organisation:

08.12.2010

Rita Rinaldo

ESA

08.12.2010

DCC

OHB

DOCUMENT CHANGE RECORD Issue

Date

Originator

Page and/or Paragraph affected

Change

1

30.11.2010

OHB

All

Initial Issue

2

08.12.2010

OHB

All

Minor changes Set confidentiality level to “Public"

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 3 of 78

ESA STUDY CONTRACT REPORT ESA Contract No 21959/08/NL/HE

AIS System Study for Maritime Safety

OHB-System AG

Issue 1

ESPAIS-OHB-FR-01

Abstract: An important system in the field of global maritime surveillance is the Automatic Identification System (AIS), which is responsible for communicating ship- and voyage-related data of surface vessels. In order to improve the performance of the existing land-based AIS system, a consortium led by OHB has been responsible for the development of a full-fledged European space-based AIS system. The main challenge in space-based AIS is the collision of multiple AIS messages in a single slot. Several innovative technologies have been applied to the payload to maximize its detection performance. The constellation has been optimized for high performance, sufficient coverage and low timeliness, resulting in 4 orbital planes consisting of 3 satellites each. Orbital parameters are 550 km altitude at 88° inclination. Assessment of the AIS constellation performance is done by using a dedicated AIS simulator applying either present-day or future traffic models. After definition of the use cases, including so-called of High Traffic Zones, which contain exceptionally dense traffic, the performance per use case has been evaluated. Considering all vessels, the user requirements of 1 hour update interval with 80% detection probability for non-HTZ and 3 hour update interval with 80% detection probability for HTZ, can be met for most use cases. For critical use cases, such as North Atlantic or Mediterranean, these requirements will be met for open sea traffic. Such a situation is representative of space-based AIS complementing the already existing infrastructure of coastal stations. In addition, the feasibility of a so-called First Element has been investigated, which will serve as an opportunity to demonstrate the data fusion between space-based AIS and electro-optical data. The work described in this report was done under ESA Contract. Responsibility for the contents resides in the author or organisation that prepared it. Names of authors: L. Evans, M. Wieser, F. te Hennepe, C. Tobehn (OHB-System) Ø. Helleren, Ø. Olsen, R. Olsen (Norwegian Defense Research Establishment) F. Storesund, K. Reiten (Kongsberg Seatex) R. Challamel, T. Calmettes (Thales Alenia Space France) N. Ramponi, R. Heron, G. Harles, F. Dubreucq (SES ASTRA TechCom) L. De Vos, S. Lesschaeve (OIP Sensor Systems) M. Vandewal (Royal Military Academy Belgium)

Rita Rinaldo

Frank te Hennepe

ESA-IAP

OHB-System AG

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 4 of 78

Table of Contents Page 1 

Scope .........................................................................................................................................................6 



Requirements Analysis ............................................................................................................................7  2.1  User Requirements ................................................................................................................................. 8  2.2  Mission Requirements .......................................................................................................................... 12  2.3  Scenario Definition................................................................................................................................ 14 



System Architecture...............................................................................................................................17  3.1  Functional Architecture ......................................................................................................................... 17  3.2  Communications Architecture............................................................................................................... 18  3.2.1  Payload Data Downlink ............................................................................................................ 19 



3.2.2 

On-Board Processing Downlink Channel Definition ................................................................. 19 

3.2.3 

Hybrid Downlink Channel Definition ......................................................................................... 19 

3.2.4 

Telemetry Downlink .................................................................................................................. 21 

3.2.5 

Telecommand Uplink ................................................................................................................ 21 

System Design ........................................................................................................................................22  4.1  Constellation ......................................................................................................................................... 22  4.2  Antenna ................................................................................................................................................ 26  4.3  Payload ................................................................................................................................................. 31  4.3.1  Detection Task .......................................................................................................................... 31  4.3.2 

Demodulation Task ................................................................................................................... 33 

4.3.3 

Management Task .................................................................................................................... 36 

4.4  Platform ................................................................................................................................................ 37  4.4.1  Payload Data Handling System ................................................................................................ 38  4.4.2 

Communications ....................................................................................................................... 38 

4.4.3 

On-Board Data Handling .......................................................................................................... 39 

4.4.4 

Power ........................................................................................................................................ 39 

4.4.5 

Attitude Determination and Control .......................................................................................... 40 

4.4.6 

Orbit Control ............................................................................................................................. 40 

4.4.7 

Mechanisms.............................................................................................................................. 41 

4.4.8 

Thermal Control ........................................................................................................................ 41 

4.4.9 

Structure ................................................................................................................................... 41 

4.5  Ground Segment .................................................................................................................................. 42  4.6  Launcher ............................................................................................................................................... 46 

ESPAIS Final Report



Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 5 of 78

Performance Simulations ......................................................................................................................48  5.1  Simulator Description ........................................................................................................................... 48  5.2  Traffic Model ......................................................................................................................................... 51  5.3  Use Case Definition .............................................................................................................................. 52  5.3.1  Summary of maritime traffic characterisation ........................................................................... 52  5.4  Selected Simulation Results ................................................................................................................. 54 



First Element ...........................................................................................................................................58  6.1  Description ............................................................................................................................................ 58 



Design and Development Plan ..............................................................................................................63  7.1  Roadmap .............................................................................................................................................. 63  7.2  Design Standards ................................................................................................................................. 63  7.3  Proposed Development Schedule ........................................................................................................ 64  7.4  Cost Estimates...................................................................................................................................... 65  7.5  Reliability .............................................................................................................................................. 65  7.5.1  Redundancy Approach ............................................................................................................. 65  7.5.2 



Reliability Budget ...................................................................................................................... 66 

Conclusions and Recommendations ...................................................................................................67  8.1  Conclusions .......................................................................................................................................... 67  8.2  Recommandations ................................................................................................................................ 69 



Associated Documentation ...................................................................................................................70  9.1  Applicable Documents .......................................................................................................................... 70  9.2  Reference Documents .......................................................................................................................... 70  9.3  List of Acronyms and Abbreviations ..................................................................................................... 71  9.4  List of Figures ....................................................................................................................................... 76  9.5  List of Tables ........................................................................................................................................ 77 

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 6 of 78

1 SCOPE In the ESPAIS (European SPace-based AIS) project, a study was performed into the feasibility of a European space-based AIS system. AIS, or in full Automatic Identification System, is a maritime surveillance system used for tracking ships. Its primary application is monitoring ship traffic, thereby aiming to realise collision avoidance between ships. Currently the main receiving stations are all land-based, which limits the effective range to 40 nautical miles off the coast due to the characteristics of the applied VHF signals. Therefore, ESA has issued an in-depth study into the development of a European space-based system in order to extend the AIS range to open sea areas, which will effectively yield global AIS coverage. This report is meant to summarise the in-depth study of a European space-based system and provide an overview of the proposed system. The proposed system has two scenarios that have been addressed, the first scenario is a cost effective solution and the second scenario is a high performance solution. A brief description of some results and trade-offs will also be discussed in order to illustrate how the system was chosen, and to provide an outlook on some of the other proposals. In previous reports, descriptions of the design for every element of the ESPAIS system have been presented. By combining all relevant parameters for every available configuration, the various baseline options are generated. Over the study, two configurations were chosen as baselines and evaluated against each other. These configurations will be seen throughout this report, until the final suggestions have been made. This document is a summary of the ESA study and has incorporated numerous reports for facts and figures. The following is a list of documents that have been used to generate this report. ESPAIS-FFI-RS-01 User and Mission Requirement Report ESPAIS-FFI-RP-02 Traffic Characterization Document ESPAIS-OHB-RS-04 System Technical Requirements Document ESPAIS-OHB-RP-05-System Functional Architecture ESPAIS-OHB-RP-06 System Scenario Definition Document ESPAIS-OHB-RP-07 System Top Level Design Document ESPAIS-OHB-RP-08 Design Methodology Description ESPAIS-FFI-RP-09 Payload Performance Analysis Report ESPAIS-OHB-RP-10 Constellation Performance Analysis Report ESPAIS-KSX-RP-11 Payload Detailed Design Report ESPAIS-OHB-RP-12 Satellite Detailed Design Report ESPAIS-TAS-RP-13 Ground Segment Detailed Design Report ESPAIS-OHB-RP-14 Cost Assessment Report & Roadmap ESPAIS-OHB-RP-17 First Element Mission Justification File ESPAIS-OHB-RP-18 First Element Mission Description Document

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 7 of 78

2 REQUIREMENTS ANALYSIS In the first step, the user needs are refined into so-called mission requirements. As the user requirements are often given as a collection of loose statements, they have to be transformed into more tangible expressions. Mission requirements are derived from the refinement of these user needs and converted into a set of high-level requirements of the system. The evaluation of user needs ensures that the requirements address the needs of the system and user, reducing the possibility of an increase in development costs due to the late integration of new requirements. In Figure 2-1, the flow diagram of the requirement analysis process is depicted.

Figure 2-1: Process flow in requirements analysis

Every requirement is ranked by their relative priority in terms of the application needs. This ranking is defined in terms of the following classification:

ƒ

Necessary requirements are basic requirements that ensure the Primary Mission Objectives can be met.

ƒ

Goals are desirable attributes for the system that advance the state of the art and provide opportunities to address secondary mission objectives.

ƒ

Optional requirements are discretionary attributes for the system that advance the state of the art without significant cost, risk or schedule implications in order to address tertiary mission objectives.

This initial ranking is intended to be independent of the perceived engineering difficulty of the requirements and provides a basis for trading mission requirements against each other.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 8 of 78

2.1 User Requirements This chapter list the user needs identified from the users listed in ESPAIS-FF1-RS-01 User and Mission Requirements Document. The list also includes additional requirements given in [RD 1]. No Class or User ID is given for requirements from [RD 1], as these are requirements from ESA and EU made based on the requirements provided by other stakeholders. Table 2-1: User requirements (needs) User Need ID/Class

Requirement Description

User ID

Doc. ID - TBC

FUTURE NEEDS UN000/ABCDEF

UN-010/ ABDE

The system should be able to accommodate future changes to the AIS system: format compatibility, e.g. international standards, and interoperability with existing systems e.g. data representations.

System shall accommodate anticipated growth in ships transmitting AIS messages the next 15 years. (e.g. possible extended use of AIS on smaller fishing vessels)

POC, INS, FN, DPC, ICG, GC, HCG, EMSA, DSTL, IMTO INT-O TRP-CO, TRP-INST

LIMES D2100.1 Part1

IMT-O

OVR 27, OVR 36

IBC-O

OVR 28

MARISS [U5] Core User Needs [RD 3] TRP, RES-210-10 [RD 2] [RD 1]

[RD 1]

SATELLITE/GROUND STATION NEEDS UN020/ABEF

UN-030/ BCDE

The system should respect security rules: no information leakage, not publicly available, different levels of security, traceability...

The AIS messages should preferably be available on the ground in less than 30 minutes after they are detected received by a satellite.

POC, INS, HCG, FN, SCG, EUSC, NCG, DSTL TRP-INST

LIMES D2100.1 Part1

DSTL, NCA, EMSA TRPCO

[RD 3] TRP, RES-210-10

MARISS [U5] Core User Needs [RD 2]

[RD 2] [RD 1]

UN040/ABDE

The system should have an independent time stamp with an accuracy of 1 minute

NCG, IMTO

[RD 3] TRP, RES-210-10 [RD 1]

PERFORMANCE NEEDS UN050/ABDEF

The system should improve pre-existing systems performances e.g. time delivery (generally between 1 and 3 hours), enlarging the national traffic picture.

DPC, HCG, GDC, ICG, GC, PDE, FN, PN, INS, SCG, PDA, FRONTEX

MARISS [U5] Core User Needs

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 9 of 78

User Need ID/Class

Requirement Description

User ID

UN051/ABDE

The system should provide a continuous information outside land-based AIS and coastal radar range e.g. to provide an information where there is no coverage at all times.

SCG, NCA, NCG, NMD, HCG, ESBC, DPC, ICG, FN, DG JLS, ADF, PN, FRONTEX, DSTL

LIMES D2100.1 Part1

INS, NCG, GC, HCG, FN, DPC, ICG, SCG, PN, EMSA. DSTL

LIMES D2100.1 Part1

The system should allow for tracking vessels World Wide (for shipping activities)

TRP-CO

[RD 2]

The system should allow for updates of vessel information as often as possible and at least every 24 hours.

TRP-CO

[RD 2]

The system should allow for updates of the AIS information every 3 hours.

DSTL, NCA, EMSA, TRP-INST

[RD 3] TRP, RES-210-10

UN-052/ABE

UN-053/C

UN-060/C

UN-061/BDE

The system should improve the RMP (Recognised Maritime Picture)1: to understand better the daily activity, to help towards an early warning, to remote new sites.

Doc. ID - TBC

MARISS [U5] Core User Needs [RD 3] TRP, RES-210-10

MARISS [U5] Core User Needs [RD 3] TRP, RES-210-10

[RD 1]

[RD 2] [RD 1]

UN-062/ BD

The system should allow for hourly updates of the AIS information within 500 nmi off the coast

DSTL, NCA, TRPINST

[RD 3] TRP, RES-210-10 [RD 2] [RD 1]

UN-070/AB

The system should have at least 80 % detection probability in the open seas

NCG, FWIC

[RD 3] TRP, RES-210-10 [RD 4]

UN-071/ABD

The system should have better than 90 % detection probability in territorial and economic waters

NCG, NCA, FWIC

[RD 3] TRP, RES-210-10 [RD 4]

UN-072

1

The system should provide an estimation of the number of undetected AIS messages transmitted by Class A vessels in certain geographical area

[RD 1]

RMP: “The Recognized Maritime Picture is defined as a composite picture of activity over a maritime area of interest.” Source: Defense Research and Development Canada.

ESPAIS Final Report

User Need ID/Class

Requirement Description

UN-080/AC

The system shall provide dynamic AIS information. If possible also static/voyage information

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 10 of 78

User ID TRP-CO, NCG

Doc. ID - TBC [RD 2] [RD 3] TRP, RES-210-10 [RD 1]

UN-081

The system shall be able to detect the AIS messages transmitted by Class A surface vessels according to rec. ITU-R M. 1371-3

[RD 1]

UN-082

The system shall be able to detect the AIS messages transmitted by Class B surface vessels according to rec. ITU-R M. 1371-3

[RD 1]

VALIDATION NEEDS UN090/ABDEF

UN091/ABCD

The system should detect anomalous situations e.g. vessels non-compliant with AIS reporting, abnormal speed, abnormal route, high risk vessels or unwanted vessels.

The system should seek to utilize any available information for validation of the positional information in the detected received AIS messages.

POC, GC, SCG, NCA, HCG, EMSA, ADF, DPC, ICG, TRPINST, TRPCO

LIMES D2100.1 Part1

DSTL, ICGO IBC-O IFC-O ICTO IAD-O, TRP-CO, TRP-INST

[RD 3] TRP, RES-210-10

MARISS [U5] Core User Needs [RD 2]

[RD 2] [RD 1]

UN-092/A

The system should provide information about the true error of the system, to determine if the system will hold if used e.g. in court

NCG

[RD 3] TRP, RES-210-10

UN-100/D

The time delay between the data from the system and possible secondary sources like Radar satellites should be minimized

NCA

[RD 3] TRP, RES-210-10

NCG,DSTL, TRP-INST

[RD 3] TRP, RES-210-10

ARCHIVING NEEDS UN-110/AB

The system should be able to store and retrieve historical data for 3+ years, with the possibility to regain in correct timeframe, to be able to backtrack and understand historic activity.

[RD 2] [RD 1]

UN-111/C

The system should retain an archive of detected received AIS messages for a period of at least: 3 months, (if possible > 1 year)

UN-112

The system should retain an archive of delivered Space Based (SB) AIS data in accordance to the SB-AIS Data Policy that will be defined by the Steering Committee (of ESPAIS)

TRP-CO

[RD 2]

[RD 1]

ESPAIS Final Report

User Need ID/Class

Requirement Description

UN-113

The system should store the satellite AIS date in the archive according to the standard IEC 62320 or any more updated standard for AIS data that will become available before system operations

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 11 of 78

User ID

Doc. ID - TBC [RD 1]

SERVICE NEEDS UN-120/ ABD

If an independent geo-localisation process fails, the AIS message shall be processed as “un-verified”

IMT-O

OVR 27

UN-121/ ABD

If the AIS message localisation is ascertained contradicting the independent geo-localisation, the AIS message shall be transmitted as “alarming”

IMT-O

OVR 27

IBC-O

OVR 28

UN-122/ ABDE

The system should report AIS message transmission time stamp and localisation even if the AIS message content cannot be read e.g. due to messages collision REMARK: Technically not feasible

IMT-O

OVR 27

IBC-O

OVR 28

UN-123/ ABDE

The system should report the AIS messages only partially decoded in the standard AIS message template with incomplete fields marked accordingly REMARK: Technically not feasible

IMT-O

OVR 27

UN-124/ ABDE

The system design must allow deciding with certainty if an AIS reporting ship conforming to international regulation is in the “surveyed zone” of the system

IMT-O

OVR 27, OVR 36

UN-125/ ABDE

The definition of “surveyed zones” can exclude all zones properly covered by in-situ AIS receivers networks

IMT-O

OVR 27, OVR 36

UN130/ABDE

The absence of AIS messaging iteration at the time it should have been repeated in accordance with international agreements is an event to be reported at system level as “transmission interruption”, when the ship planned /expected route has been surveyed next REMARK: This is a task for services not within this AIS system study

IMT-O

OVR 27, OVR 36

IBC-O

OVR 28

UN-140/C

The cost of AIS data from the system should be comparable to that of LRIT (e.g. in the order of 365 USD/ship/year)

TRP-CO

[RD 2]

[RD 1]

UN-150

The system should be operational by 2013

[RD 1]

UN-160

The system shall respect and EU defined data policy as well as the international agreements for worldwide AIS data distribution

[RD 1]

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 12 of 78

2.2 Mission Requirements From the user requirement description which can be found in Table 2-1, the mission requirements were derived and can be found below. In the classification column, the origin of the mission requirement can be inferred. Those requirements that are necessary are most likely to be those derived from the user requirements as the system is meant to satisfy the user. Table 2-2: Mission requirements Mission Req. ID

Requirement Description

Classification

User Need Ids/Class

MR-10

System shall be able to track surface vessels operating class A AIS transponders

Necessary

UN-050/ABDEF, UN-051/ABDE UN-081

MR-20

System shall be able to geographically cover all global areas

Necessary

UN-050/ABDEF, UN-051/ABDE, UN-052/ABE, UN-053/C

MR-30

Deleted

-

-

MR-40

System shall allow for updates of the AIS data within intervals of at maximum 3 (1) hours

Necessary (Goal)

UN-050/ABDEF, UN-060/C, UN-061/BDE, UN-062/BD

MR-50

AIS data shall be available on ground maximum 1 hour (30 min) after being decoded by a spacecraft

Necessary (Goal)

UN-030/BCDE, UN-052/ABE

MR-60

System shall be able to decode all AIS message types detected with a valid checksum

Necessary

UN-080/AC UN-081 UN-082

MR-61

The system shall include a received signal strength indicator (RSSI) for each timeslot and frequency to be used for estimation of number of vessels in an area

Goal

UN-072

MR-70

System shall be capable of providing an independent time stamp for each message detected, with timing accuracy of at most 1 minute

Necessary

UN-040/ABDE

MR-80

System shall have a minimum ship detection probability of 80% (95 %) within the time given in MR-40.

Necessary (Goal)

UN-070/AB UN-071/ABD

MR-90

System shall utilize external information (e.g. Doppler, satellite position) for validating positional information in AIS data

Goal

UN-090/ABDEF, UN-91/ABCD, UN-92/A

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 13 of 78

Mission Req. ID

Requirement Description

Classification

User Need Ids/Class

MR-91

The system shall seek to correlate orbits with orbits of radar satellites for the best time correlation of signals from co-operative (AIS) and non-cooperative (SAR) system

Optional

UN-100/D

MR-100

System shall be compatible with and be able to interact with existing AIS infrastructure, e.g. on a format according to the standard IEC 62320-1 or any newer standards for AIS messages.

Goal

UN-050/ABDEF, UN-052/ABE, UN-113

MR-110

Deleted

-

-

MR-120

Security framework shall be applied according to national / international regulations

Necessary

UN-020/ABEF

MR-121

The AIS data shall be delivered and archived in any ground location in accordance to the Space-based AIS Data Policy that will be defined by the Steering Committee

Necessary

UN-112

MR-122

The system shall respect any EU defined data policy as well as international agreements for worldwide AIS data distribution

Necessary

UN-160

MR-130

System shall be able to accommodate future changes in AIS transmitting frequency within the frequency band 156 (TBC) MHz to 162,025 (TBC) MHz

Goal

UN-000/ABCDEF

MR-140

System shall be able to accommodate future changes in AIS signals, e.g. format

Goal

UN-000/ABCDEF

MR-150

Deleted

MR-160

System shall be able to store data in a historical archive for at least 3 years

Necessary

UN-110/AB, UN-111/C

MR-170

System shall accommodate anticipated growth in ships transmitting AIS messages the next 15 years. (e.g. possible extended use of AIS on smaller fishing vessels)

Necessary

UN-010/ABDE

MR-180

System shall enable distribution of decoded AIS messages with incorrect CRC (i.e. decoded AIS messages with one or more bit errors)

Optional

UN-123/ABDE

MR-190

System shall be operational in 2013

Necessary

UN-150

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 14 of 78

Final Report

2.3 Scenario Definition Based on the mission requirements and a first analysis of ship traffic visibility from space, the main geographical areas and key performances were used to define a first set of different system scenarios. The scenarios are defined by adding distinct differences in requirements for the various considered use cases. Use cases define regions that are used for the maritime traffic characterization and the performance evaluation of AIS constellations. They can be divided into High Traffic Zones (HTZs) and Non-HTZs. The full set of use cases is described in ESPAIS-FFI-RP-02 Traffic Characterization Document. The use cases that are used for performance evaluation are shown here. „

High Traffic Zones: -

„

North Sea Mediterranean Sea GB China Gulf of Mexico Black Sea

Non–HTZ: US-East-Coast North Atlantic US Atlantic

The map below shows location and shape of these use cases. Gulf of Mexico

US-EastCoast

NorthAtlantic

USAtlantic

Bay of Biscay

-60°

-30°

GB

North Sea

Med. Sea

Black Sea

China Asia

90°

60°

30°



-30°

-60°

-90° -180°

-150°

-120°

-90°



30°

60°

90°

120°

150°

180°

Figure 2-2: Use Cases selected for detection probability evaluation The use cases were picked based on the evaluation of several criteria. These criteria are described below.

ƒ Geographical Area Geographical areas are separated and derived from the ship traffic distribution. Ship traffic is concentrated in two or three areas: North Sea, Caribbean Sea or Chinese / Yellow Sea referred as High Traffic Zones (HTZ). Coastal Zones are separated, due to the existing land based AIS reception infrastructure. The rest is assessed as the remaining global area with low ship traffic. Due to this different ship traffic density, different update intervals are defined for different areas.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 15 of 78

Figure 2-3 Depiction of high traffic zones (HTZ) for scenario 1 and 2

ƒ Update Interval Update interval is defined as the time interval between position reporting of a particular ship on a AIS traffic map until the next instance of position reporting of the same ship.

ƒ Minimal Ship Detection Minimal ship detection is defined as the minimum percentage of ships within the mentioned geographical areas, which have to be updated within the update interval. The requirements for this category of 80% with a goal of 95% is independent the other categories and therefore the same for all categories.

ƒ Timeliness Time interval between the reception of the AIS by the satellite and the distribution of the contained AIS data to the user. The requirements for this category of 1h with a goal of 30 minutes is independent the other categories and therefore the same for all categories. In Table 2-3, a summary of the proposed system scenarios is presented. The requirements are separately defined for high traffic zones and non-high traffic zones. Note that high traffic zones do not include the North Sea, as this area is so extremely populated with vessels that defining a requirement would render every technical solution non-compliant. Table 2-3 System Scenarios Overview Scenario Number

HTZ except North Sea

Global except HTZ

Minimal Ship Detection (within Update Interval)

Timeliness

#1

N/A

3 hr

80 % (95 % goal)

1h (30 min. goal)

#2

3 hr

1 hr

80 % (95 % goal)

1h (30 min. goal)

In the following paragraphs, the various system scenarios will be described in more detail. Refer to Table 2-3 for the definition of the various system scenarios.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 16 of 78

Scenario #1 represents a baseline solution as the requirements are less stringent, requiring an 80% detection probability for a minimum update interval of 3 hours. Global coverage is demanded, however the socalled high traffic zones (HTZs) are excluded. This means that the requirement regarding update interval does not apply to these HTZs. These limited HTZs are the main driver for the number of AIS messages to be received and decoded by a satellite, even with a narrow field of view. For HTZ the AIS reception can be achieved with the use of land/shore based infrastructure, which is more cost efficient, while relaxing the AIS payload processing and coverage (number of satellites) requirements.

N/A 3h

Figure 2-4: Definition of Scenario 1 Scenario #2 is a more realistic scenario with more demanding requirements. The update interval for global waters is equal to 1 hour and for high traffic zones excluding the North Sea it is 3 hours. Note that in this scenario, the driving requirement will likely be the desired update interval of 3 hours for the high traffic zones.

N/A

3h 1h

Figure 2-5: Definition of Scenario 2

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 17 of 78

3 SYSTEM ARCHITECTURE 3.1 Functional Architecture This part is covered in [RD 5]. Here a very short description is given for overview and terminology explanation. Here a very short description is given for overview and terminology explanation. In Figure 3-1, the system architecture of the ESPAIS system is shown. It contains all subsystems of the ESPAIS system, including relevant interfaces, in addition to interfaces to other systems.

Figure 3-1: ESPAIS system architecture From Figure 3-1, it is clear that although ESPAIS is a separate system from existing land based AIS systems, although there is a connection of data through the downstream services that are available. Through this connection a more secure global AIS system is achieved. A data flow block diagram of the space based AIS message path can be seen below to clarify what actually happens to the message and where the message is taken.

Figure 3-2: Data flow block diagram of AIS message

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 18 of 78

3.2 Communications Architecture Within the ESPAIS system, many communication links are presented to transfer information from one entity to another. These communication links are present between, the space segment and ground segment, within the ground segment (e.g. between a gateway and the satellite control centre), and between the ground segment and user / service segment). A block diagram of the communications architecture is presented in Figure 3-3. Data flows between the various entities are clearly shown.

Figure 3-3: Communications architecture of the ESPAIS system In Figure 3-3, it is assumed that all elements of the ground segment are connected to an established terrestrial communications infrastructure, (e.g. high-speed internet). Moreover, it is concluded that the terrestrial communications links are infinitely fast, therefore allowing data packages to be transferred instantaneously from one entity to another. Furthermore, it is assumed that all terrestrial entities are connected to a power source with infinite capacity (e.g. power grid, diesel generator), such that any power requirements do not pose a problem. On the other hand, the links between the space segment and the ground segment do not have the luxury of infinite availability of power and bandwidth. Therefore, these links have to be investigated in more detail. Three different links have been identified:

ƒ Payload data downlink ƒ Telemetry downlink ƒ Telecommand uplink

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 19 of 78

Final Report

3.2.1 Payload Data Downlink 3.2.2 On-Board Processing Downlink Channel Definition After having established the required data rates and downlink bandwidths of the on-board processing concept, a downlink channel will be assigned link. As the exact assigned frequency band is not known at this point in time, the centre frequency of the selected band is used to assess the link budgets. Note that all transmit power values correspond to RF power; required DC power values will be higher. It was concluded that due to overcrowding of the S-band, the only viable downlink option for the ESPAIS system will be the use of C-band. Hence, the on-board processing downlink will be accommodated in the 6700 – 7075 MHz band. In the on-board processing concept, on-board processing data and housekeeping telemetry data are multiplexed into a single data stream. This downlink mode will be used over polar ground stations. Note that housekeeping telemetry will only be sent over Svalbard, not over McMurdo. It is proposed to use hemispherical antennas for this mode. In Figure 3-4, this situation is illustrated.

On-Board Processing Housekeeping Telemetry

Figure 3-4: Sketch of on-board processing downlink channel In the high data rate downlink, on-board processing and housekeeping telemetry data are multiplexed into a single data stream. This means that the high data rate downlink has to be able to transmit a total data volume of 8.7 Mbit + 3 Mbit. This value will be rounded up to 11.7 Mbit. Assuming that a minimum contact time of 6 minutes will be achieved, a net data rate of 32.5 kbps has to be generated. Introducing overhead due to framing and encryption increases this data rate to 33.4 kbps. Regarding forward error correction, a convolutional code with a coding rate of 3/4 is used. This results in a gross bit rate of 44.6 kbps. It has been chosen to adopt commonly used modulation and coding to reduce complexity and risk. In this case, it is opted to use QPSK modulation. This results in an output symbol rate at the transmitter of 22.3 kbaud. After application of a square-root raised cosine filter, the required channel bandwidth is equal to 30.1 kHz. It has been decided to accommodate the high data rate downlink in the 6700 – 7075 MHz frequency band. Hence, a center frequency of 6887.5 MHz will be used for link budget purposes. 3.2.3 Hybrid Downlink Channel Definition After having established the required data rates and downlink bandwidths of the on-board processing and digital sampling modes in the hybrid concept, downlink channels will be assigned. As the exact assigned frequency band is not known at this point in time, the centre frequency of each available band is used to assess the link budgets. Note that all transmit power values correspond to RF power; required DC power values will be higher.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 20 of 78

It was concluded that due to overcrowding of the S-band, the only viable downlink option for the ESPAIS system will be the use of C-band. Hence, the on-board processing downlink will be accommodated in the 6700 – 7075 MHz band. The hybrid payload downlink will make use of two modes: a low data rate mode and a high data rate mode. These modes will be offered by a single piece of transmitting equipment, which will switch between modes dependent on the orbital position. For primary data downlink, the high data rate mode will be used. In this mode, digital sampling data, onboard processing data and housekeeping telemetry data are multiplexed into a single data stream. High data rate mode will be used over polar ground stations. Note that housekeeping telemetry will only be sent over Svalbard, not over McMurdo. As downlink antenna, an isoflux antenna is used. This situation is sketched in figure A. of Figure 3-5. The low data rate mode will only be used for on-board processing payload data downlink. This mode is entered over low latitude stations. As it is proposed to use hemispherical antennas for this mode, it is also used to perform emergency mode telemetry downlink. In figure B. of Figure 3-5, this situation is illustrated.

Digital Sampling On-Board Processing Housekeeping Telemetry

A.

B. Figure 3-5: Sketch of hybrid downlink channel A. High data rate; B. Low data rate

3.2.3.1 High Data Rate In the high data rate downlink, digital sampling data, on-board processing data and housekeeping telemetry data are multiplexed into a single data stream. This means that the high data rate downlink has to be able to transmit a total data volume of 9,200 Mbit + 8.7 Mbit + 3 Mbit. This value will be rounded up to 9,250 Mbit. Assuming that a minimum contact time of 6 minutes will be achieved, a net data rate of 25,700 kbps has to be generated. Introducing overhead due to framing and encryption increases this data rate to 26,500 kbps. Regarding forward error correction, a Trellis Code Modulation with a coding rate of 2/3 is used as inner coding, which is combined with an outer Reed Solomon code of (255,239). This results in a gross bit rate of 42,400 kbps. As the bit rate has a very high value, it is chosen to apply a modulation with a high-spectral efficiency to save bandwidth. Therefore, it is opted to use 8PSK modulation. This results in an output symbol rate at the transmitter of 14,200 kbaud. After application of a square-root raised cosine filter, the required channel bandwidth is equal to 19,100 kHz. It should be noted that the application of an LDPC code, which is presently under investigation by CCSDS, reduces the bandwidth significantly. Furthermore, it will result in a decrease in required RF power. However, it will not be considered baseline, due to the fact that it is not CCSDS compliant. It has been decided to accommodate the high data rate downlink in the 6700 – 7075 MHz frequency band. Hence, a center frequency of 6887.5 MHz will be used for link budget purposes.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 21 of 78

3.2.3.2 Low Data Rate In the low data rate mode, only on-board processing data will be sent. Hence, the low data rate downlink has to be able to transmit 8.7 Mbit. Assuming that a minimum contact time of 6 minutes will be achieved, a net data rate of 24.2 kbps has to be generated. Introducing overhead due to framing and encryption increases this data rate to 24.9 kbps. Regarding forward error correction, a convolutional code with a coding rate of 3/4 is used. This results in a gross bit rate of 33.2 kbps. It has been chosen to adopt commonly used modulation and coding to reduce complexity and risk. In this case, it is opted to use QPSK modulation. This results in an output symbol rate at the transmitter of 16.6 kbaud. After application of a square-root raised cosine filter, the required channel bandwidth is equal to 22.4 kHz. It has been decided to accommodate the high data rate downlink in the 6700 – 7075 MHz frequency band. Hence, a center frequency of 6887.5 MHz will be used for link budget purposes. 3.2.4 Telemetry Downlink The telemetry downlink will be performed by multiplexing the data with payload data, which is consequently downlinked in C-band. In this way, housekeeping telemetry data will be sent to Earth every orbit. The telemetry downlink has to adhere to the requirements laid down in [AD 1]. An important requirement with respect to housekeeping telemetry and telecommanding is that it should be possible for a ground station to establish contact with the spacecraft irrespective of its attitude. Therefore, at least two hemispherical antennas have to be used to provide omnidirectional coverage to the spacecraft. In the on-board processing concept, a hemispherical antenna is applied for downlink of on-board processing data and telemetry data. Therefore, the aforementioned contact requirement will be met. In the hybrid concept, the telemetry data will be downlinked in a high data rate mode using the isoflux antenna in nominal mode. This will yield problems in emergency mode, because of the limited coverage of the isoflux antenna. Hence, the housekeeping telemetry will be sent by a low data rate mode using hemispherical antennas in emergency mode. The housekeeping history data set consists of multiple record entries of the housekeeping data frame. This data frame will be generated by sampling spacecraft parameters, which are of interest when monitoring the spacecraft status. Sampling is done either in a real channel, i.e. using hardware, or in a virtual channel, i.e. using software. 3.2.5 Telecommand Uplink For accommodating the telecommand uplink, it has been chosen to reuse the hemispherical antennas, which are used for the low data rate downlink. This means that the telecommand uplink will be performed in Cband. The telecommand uplink has to adhere to the requirements laid down in [AD 2]. Because the spacecraft will be designed to have a high level of autonomy, the amount of telecommands to be sent during a ground station pass will be very limited. The main functions of ground station telecommand will include:

ƒ ƒ ƒ ƒ

Requesting current spacecraft status Ordering an orbital correction manoeuvre Changing parameters in OBC register Emergency recovery

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 22 of 78

Final Report

4 SYSTEM DESIGN 4.1 Constellation The constellation design was performed by analysing the predefined scenarios detailed in section 2.3 to ensure that the system would be able to meet all of the requirements for all use cases. The critical requirements that need to be satisfied are a detection probability of at least 80% and an update interval of 3 hours for regions not including the high traffic zones (HTZ). These requirements become especially challenging in areas with an increase in ship traffic, which are referred to as HTZs and are typically near coastal regions. The HTZ areas identified for this study can be seen in Figure 2-3. In Figure 4-1 below it can be seen that lower inclinations give greater coverage duration at low and medium latitudes when compared to polar orbits. Polar orbits on the other hand, allow for more observation time at higher latitudes. As some high traffic zones such as the Gulf of Mexico lie at medium latitudes and others, like the North Sea, at high latitudes, actual detection probability simulations with AISDET were performed (see chapter 5). AISDET simulations were used to evaluate the detection probabilities for the various areas and determine the best inclination for the ESPAIS system. It was found that only small use-cases such as the North Sea and Black Sea show significant variations in detection probability between 65° and 80° inclination, and no use-cases showed a significant difference in detection probability for inclinations between 80° and 90°. Since the Black Sea is not a driver for the ESPAIS constellation, a polar inclination of 88° is preferred as it gives both very good ground station contacts and AIS detection performance

600 km, 0° Ground Elevation

Coverage duration [min/day]

200

30 35

180

40

160

45

140

50 55

120

60

100

65

80

70

60

75

40

80

20

85

0

90 0°

20°

40°

60°

80°

100°

Latitude

Figure 4-1: Coverage duration versus inclination Another factor that greatly affects the constellation design and performance is the type of antenna that will be used. The table below gives an indication of the required number of satellites to fulfil the threshold requirement, a detection probability greater than 80%, for various antenna configurations. It can be seen that the difference in the number of satellites between the different antennas is quite large. Additionally, in Figure 4-2 it is evident that the inclusion of land based AIS, significantly reduces the load on the system for the scenario considering the HTZs. This is a critical analysis as most HTZs are near ports or the coast, therefore the use of land based AIS significantly increases the overall systems detection probability, reducing the demand on the satellite system. This is possible because it is assumed that those vessels within the range of the land based AIS, 40NM off the coastline, have a detection probability of 100%.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 23 of 78

Final Report

Table 4-1: Required number of satellites for different use cases and different antenna/orbit options Required Satellites for 80% det. probability and 3 hours update interval for a 2009 vessel distribution Antenna

North Sea

Bay of Biscay

GB

Med. Sea

Gulf of Mexico

China

Black US-East- North USSea Coast Atlantic Atlantic

3 Monopoles

>150

35

150

68

23

10

10

5

5

5

Dipoles

>150

26

73

29

16

6

8

5

5

5

Helix Array

>150

29

73

30

14

6

8

5

5

5

Helix Array 532km

>150

16

40

27

14

5

6

5

5

5

Patch Array X

>150

12

36

16

8

5

6

5

5

5

Patch Array XY

>150

9

26

13

6

5

5

5

5

5

Areas with land based AIS coverage are included in Figure 4-2, and assumed to have 100% detection probability. This shows the detection probability a user gets from the system after satellite and land based data has been combined. The combined detection probability from land and space assets can be seen in the following figure. With land based AIS station coverage, all European high traffic zones besides the North See are significantly above 80%. This can be compared to the results for the same window however, without the use of land based AIS.

100%

100%

North Sea

North Sea w/ Land AIS

70%

Bay of Biscay

60%

Bay of Biscay w/ Land AIS

50%

GB

40% GB w/ Land AIS

30% 20%

Mediterranean Sea

10%

Mediterranean Sea w/ Land AIS

0% 0

3

6

9

12

15

18

3 hour window (+-1.5h)

21

24

Detection Probability

Detection Probability

80%

North Sea

90%

90%

80%

North Sea w/ Land AIS

70%

Bay of Biscay

60%

Bay of Biscay w/ Land AIS

50%

GB

40% GB w/ Land AIS

30%

Mediterranean Sea

20% 10%

Mediterranean Sea w/ Land AIS

0% 0

3

6

9

12

15

18

21

24

3 hour window (+-1.5h)

Figure 4-2: Left: Detection probability ignoring area covered by land based AIS stations. Right: Detection probability including land based AIS stations. The results from the reference scenario provided a reasonable baseline for the system analysis, however a more detailed analysis which combine the results of the altitude and inclination sensitivity study with antenna properties is required. For this, two orbital scenarios were analysed. The scenarios that were investigated further can be seen detailed below. It should be noted that as the ESPAIS system is intended to be operational for 15 years, the vessel distribution values have been estimated for the year 2024. Through the preliminary analysis it was evident that as the number of vessels increased over time, the number of satellites required would increase. Consequently, it has been proposed to launch 2 batches of satellites, one in 2014 and the second in 2021 in order to help the system cope with the influx of vessels. The details of each batch can be seen below in Table 4-3 and Table 4-4. In the following, the proposed constellations for both system scenarios are presented. For easy reference, Table 4-2 recapitulates the definition of these scenarios.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 24 of 78

Table 4-2: System Scenarios Overview Scenario Number

HTZ except North Sea

Global except HTZ

Minimal Ship Detection (within Update Interval)

Timeliness

#1

N/A

3 hr

80 % (95 % goal)

1h (30 min. goal)

#2

3 hr

1 hr

80 % (95 % goal)

1h (30 min. goal)

Scenario 1 After more simulation results became available a more detailed analysis on the number of satellites for scenario 1 was performed. The satellites of scenario 1 will be equipped with 3 dipole antennas and will not perform orbit altitude maintenance, resulting in their altitude decreasing during their operational period of 7.5 years from an initial altitude of 600km to an approximate altitude of 550km. Therefore, an altitude of 550km has been assumed for end of life (EOL) performance of each batch of satellites. The figure below shows the detection probability of 8 and 16 satellite constellations with dipole antennas for a 3 hour update interval and different vessel distribution. In these plots an orbit altitude of 600km has been assumed, because the performance of a 550km altitude will be better. The use of interference cancellation techniques has minor influence when combined with dipole antennas. As can be seen in the two figures below, 16 dipole satellites are not sufficient for 80% detection probability in all non-HTZ with the 2024 vessel distribution. Therefore 20 satellites will have to be used for the second batch of scenario 1 satellites. At EOL in 2029 the number of vessels will have increased but the altitude of the satellites will be lower resulting quite stable performance. For the first batch of satellites a launch date of 2014 and an EOL in 2021 is expected. Therefore roughly 12 satellites are necessary to achieve 80% detection probability in the non-HTZ.

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

8 Sat, 2014, ESA 8 Sat, 2024, SIC

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

16 Sat, 2014, ESA 16 Sat, 2024, SIC

Figure 4-3: Effect of increasing vessel distributions on detection probability (3 dipole antennas) Scenario 2 For Scenario 2, phased array antennas have been selected as most cost effective choice. Besides the North Sea, which is not used for constellation sizing, the most demanding use case is the Mediterranean Sea. To achieve 80% detection probability within 3 hours, 14 (when taking land based AIS coverage into account) to 20 satellites are necessary. To achieve sufficient EOL performance in 2029, 20 satellites with nine phasing laws are used as first candidate for the Scenario 2 constellation. Based on these results, the following constellations have been proposed for scenarios 1 and 2. The first batch of satellites will only have 12 satellites to account for the reduced amount of vessels. This is also pos-

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 25 of 78

sible because in 2021 when the number of vessels increases to that of marginal detection probabilities a new batch of satellites will be launched to withstand the influx of vessels. Table 4-3, shows the orbital parameters of the constellations for scenario 1 and 2. In addition, these scenarios will be referred to throughout the document as the details of the satellite design vary on the antenna choice and orbital parameters, which are different in the two scenarios. Table 4-3: Initial batch to be launched in 2014, maximum revisit time of 43 minutes Criteria

Scenario 1

Scenario 2

Satellites

12

12

Planes

4

4

RAAN Increment

46°

46°

True anomaly phasing

60°

60°

600km, decreasing to 550km

550km

88°

88°

Three dipole antennas

Patch antenna phased array

Orbit Altitude Inclination Payload antennas

Figure 4-4: 12-Satellite constellation for batch one The image above depicts the satellite constellation for scenario 1 and 2, as they have the same number of planes and satellites, and the satellite spacing is identical. The only variation between the two constellations is the antenna that is used and the marginal orbital maintenance that is performed by scenario 2. The orbital characteristics for the second batch of satellites to be implemented in 2021 can be found in Table 4-4. The characteristics are comparable to those used for the first batch.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 26 of 78

Final Report

Table 4-4: Batch two of constellation, to be launched in 2021, maximum revisit time of 16 minutes Criteria

Scenario 1

Scenario 2

Satellites

20

20

Planes

5

5

RAAN Increment

37°

37°

True anomaly phasing

36°

36°

600km

550km

88°

88°

Three dipole antennas

Patch antenna phased array

Orbit Altitude Inclination Payload

Based on the two orbital scenarios, the detection probability was analysed using the 2021 traffic model with ESA algorithms. It was found that the use of the ESA algorithms in combination with SIC algorithms only increased the detection probability by 2%. Table 4-5: ESPAIS global detection probability assessment for initial batch, with a 2021 traffic model Update Interval

Scenario 1 (3 Dipole antennas)

Scenario 2 (Patch antenna phased array)

Ship Based

1 hour

48,3%

66,1%

(Without land based AIS)

3 hours

61,5%

80,2%

Area Based

1 hour

94,8%

97,0%

(With land based AIS)

3 hours

96,2%

98,7%

From the table above it is evident that as the first batch of satellites nears their EOL, their performance is greatly reduced, such that the detection probability for the global scenario is less than 80%. It should be noted that for all areas not classified as HTZs, the detection probability is around or above 80%. This is significant because this means that ESPAIS coupled with the land based AIS can provide the required detection probability. This was analysed for the second batch as well, which proved to have slightly lower results than batch 1, however was still around 80% in most areas. It can also be seen that scenario 1 which utilises the patched antenna phased array, had better results than scenario 1, often obtaining an update interval times of 1 hour (at 80% detection probability).

4.2 Antenna Multiple antennas were analysed in order to obtain the best performance for the given orbit parameters and AIS performance requirements. Of the antennas that were examined the two antennas that were chosen for the two scenarios were the dipole antenna and the phased patched array, which will be used in scenario one and two respectively. It can be seen in ESPAIS-KSX-RP-11 Payload Detailed Design Report that the relative performance of the different antennas does not vary much between most use-cases. This means that antennas, which are good in one use case, in general are also good in other use cases. Based on the Mediterranean use case the detection probability was evaluated for each antenna option for a single satellite. In Table 4-6, a summary of the average probability of detection of a vessel in the Mediterranean is shown for the different antenna configurations. These values have been generated by simulating a single satellite for 24 hours.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 27 of 78

Final Report

Table 4-6: Performance summary of available antenna design options Design Option

Detection Probability

Helix vertical

0.26

Helix off-nadir

0.34

Spinning helix

0.30

One patch

0.28

One monopole

0.32

Three monopoles

0.37

Three ideal dipoles

0.41

Phased array – four helices

0.44

Phased array – four patches

0.45

These results are confirmed in the following figures as the time to receive updates from 80% of the vessels is less for the patch array. It can also be seen that this is primarily a concern for the HTZ, as those areas that are not as densely populated have a similar update time. Lastly, Figure 4-7 illustrates the different detection probabilities for each antenna variation, for all use cases. It is evident that the best performance is achieved with the patch array antenna.

Figure 4-5: Time in hours to receive updates from 80% of vessels in 2021 with dipole

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 28 of 78

Final Report

Figure 4-6: Time in hours to receive updates from 80% of vessels in 2021 with patch 100% 90% 80% 70% 60% 3-Monopoles

50%

dipoles

40%

helix_arrays\helices4

30%

helices_532km\helices4

20%

Patch_Arrays\patches5_PX Patch_Arrays\patches5_PXY

10%

G ul f

a

an

Pe rs i

Ea st As i

na

ac k Se a US -E as t- C oa st No rth At la nt ic US -A tla nt ic

Bl

Ch i

M

ed G B ite rr a ne an Se a G ul fo fM ex ic o

ca y of Bi s

Ba y

No rth

Se a

0%

Figure 4-7: Detection probability after the initial 30 orbits The two antenna configurations on the satellite are seen in the figures below. Along with the antenna configurations the antenna gain patterns are displayed as they are affected by the presence of the platform. The dipole antenna patterns depict the ideal case and therefore do not consider the spacecraft however, when compared to the monopole analysis the effects of cross coupling can be determined. In Figure 4-8, link budgets for three perpendicular ideal dipoles is presented. These figures assume a dipole on the ground. The antennas are oriented left right, up-down and perpendicular to this page

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 29 of 78

Figure 4-8: Link budget for three perpendicular ideal dipoles

Figure 4-9 Sketched views of deployed 3 orthogonal dipoles ESPAIS spacecraft The antenna pattern and link budget depictions for the phased array have considered the influence of the satellite bus.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 30 of 78

Figure 4-10: Link budget of phased array antenna. Left: Nadir focused, Right: Quadrant focused

Figure 4-11 View of deployed 4 patches ESPAIS spacecraft

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 31 of 78

4.3 Payload The payload for the ESPAIS mission is an AIS receiver that must collect thousands of transmitted AIS messages from vessels across the world, and do so with a minimal loss of information. In order for this to be possible the payload must perform three tasks. The first task is to detect the AIS messages, which will be performed via hardware and the second task is to demodulate the message, which is primarily done via reprogrammable software. Lastly, is the management task, which must overlook the payloads operations. The payload is broken down into 3 elements which will be outlined in this section.

ƒ

AIS Receiver -

ƒ

Signal processing -

ƒ

Hardware, firmware and software

Advanced algorithms

Antenna

4.3.1 Detection Task There were two options that were proposed for the AIS receiver which is responsible for the detection task of the payload, they were the “FPGA solution”, proposed by Kongsberg Seatex and the “ASIC solution”, proposed by Thales Alenia Space. The two options have similar modes in regards to on-board processing (OBP) and digital sampling (DS), however vary in their digital signal processing hardware. Both options were found to support four operational modes including dedicated and hybrid modes. The four modes are as follows, on-board processing mode, digital sampling mode, altering between OBP and DS (semi-hybrid) and simultaneous OBP and DS (hybrid mode). Of the two options it was decided to use the FPGA solution as the baseline for the AIS receiver, therefore only details for the FPGA solution will be provided. The front end of the FPGA solution can be seen below.

Figure 4-12: Block diagram of the FPGA solution front-end chain The block diagram displays the principal signal flow from the antenna to the external interfaces of the payload. The received signal is filtered by band pass filters and amplified in a low noise amplifier before it passes through an analogue-to-digital converter (ADC). Due to the terrestrial VHF signals and the possibility of saturating the ADC, narrow filters with sharp roll-offs need to be designed. Unfortunately, narrow filters are associated with high insertion losses and therefore need to be placed after the LNA in order to minimize these affects. There are multiple solutions that can satisfy these requirements however two have been suggested based on the desire to keep all four AIS channels open. The two solutions for placement of the narrow filters can be seen in Table 4-7. .

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 32 of 78

Table 4-7 Solutions for narrow filter implementation, due to terrestrial VHF Solutions

Advantages

Disadvantages

Splitting signal into two narrow filters. One for AIS channels 1 and 2, and one for AIS channels 3 and 4.

- Include all four frequencies.

- increased number of serial components

Utilising filter that covers the entire maritime VHF band

- Include all four frequencies.

- Excellent filtering of signals outside AIS channels.

- Same filter utilised for input filter.

- custom filters are necessary - Receiver cannot handle signals >0dBm within the maritime VHF band.

The continuation of the front-end chain can be found in Figure 4-13, where the FPGA solution for scenario one is displayed.

Figure 4-13: AIS receiver (Scenario 1 - FPGA solution) The FPGA solution for scenario 2 is the same as scenario 1 however it utilises an 8-input x 4-ch AIS demodulator, and there are 2 instances of the 1-Ch EQM AIS demodulator providing information to the message interface. During the on-board processing mode, the signal will be demodulated and decoded down to AIS NMEA sentence level, processed, filtered and stored, waiting to be transmitted down to a ground station. This technique reduces the need for large storage capabilities and simplifies the ground segment. In digital sampling mode, the received data is simply down converted and stored in its raw format. This solution will in areas of high traffic provide maximum resolution if compared to on-board processing, but requires a rather large storage capability. Due to the higher strains on the system, this mode requires data transfer to be sent via a high data link, as opposed to the low data link required for the on-board processing mode. The FPGA solution that was selected was from the Xilinx Virtex family, specifically the Xilinx Virtex 5QV as it is RAD hardened and has embedded scrubbing mechanisms to prevent false readouts from radiation. The use of the Virtex 4QV is also a viable solution however it is not RAD hardened and therefore two must operate in parallel to prevent single event effects (SEEs). In the event that the Virtex 5QV is not available due to ITAR the ASIC solution will be used as it is more capable, space proven and ITAR free. The ASIC solution is not a COTS product and therefore will have an increased cost and development time. An indication of relative capabilities can be given as follows : ƒ ASIC : 5 billion of usable gates ƒ RTAX4000 (FPGA): 400 000 equivalent usable ASIC gates ƒ Virtex 4 (FPGA): 3 billion of equivalent usable ASIC gates

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 33 of 78

Final Report

The full FPGA firmware implementation of the 1-ch ESA AIS Demodulation algorithm is estimated to process a single-slot message (256-bit timeslot) in 0.9 ms when operated at a 150 MHz system clock. The demodulator algorithm is capable to recover a relative frequency shift of 0.15xRb (1.44 kHz). In order to recover a frequency shift of 4 kHz, the algorithm has to be run for three iterations, i.e. a total processing time of 2.7 ms for single-slot messages and 5.4 ms for dual-slot messages. When operated at a system clock of 200 MHz (or 4×fs), one instance the Digital Down Converter (DDC) module is capable of serving 4 AIS-channels, time multiplexed. This implies that the two main AIS channels and the two eventual supplementary channels at a RF-input may be down converted by one instance of the DDC module. The maximum number of AIS channels that may be processed by two instance of the algorithm in is summarised in the table below. Table 4-8: Firmware processing capacity (AIS Demodulation Tasks) Demodulated Channels

AIS message length supported

Max. Frequency Error

Single-slot

Dual-slot

1.4 kHz

58

28

4.0 kHz

18

8

NOTE: It should be possible to improve the processing capacity outlined in Table 4-8 by utilising more FPGA resources in parallel to the ESA algorithm implementation. A minimum of 10 dual-slot / 20 single-slot “AIS Demodulation Tasks” at 4.0 kHz frequency error should be practical. 4.3.2 Demodulation Task In addition to the payload hardware, four different demodulator technologies were discussed for digital signal processing to provide the highest ship detectability.

ƒ ƒ ƒ ƒ

Differential demodulator Non-coherent CPM demodulator Non-coherent CPM demodulator with SIC algorithm Optimal coherent demodulator

The four demodulator technologies were evaluated based on the following criteria with the following weighting factors.

ƒ

Performance (50%) -

Performance with AWGN (10%)

-

Robustness to interferers (20%)

-

Performance in complete simulation (20%)

ƒ

Complexity (35%)

ƒ

Maturity

(15%)

Based on the evaluation criteria the recommendations are; ƒ

to consider the CPM demodulator without MUD as the baseline

ƒ

to consolidate the impact on performance and complexity of MUD algorithms (SIC and others)

ƒ

to consolidate the residual margin on defined processing architecture

ƒ

to use the residual margin to integrate the most interesting MUD algorithms

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 34 of 78

The baseline for processing is the non-coherent CPM demodulation. Even if it has good performance due to its near-optimal demodulation, which is theoretically achievable, it is still a single access demodulation resulting in any colliding messages to be taken as noise. Concerning the first limitation, single access demodulation, the SIC (Signal Interference Cancellation) algorithm has been proposed. If a strong signal has been correctly demodulated, it is removed from the input signal and then a second demodulation process can be achieved on an eventual second message. The removal performance of this algorithm approaches the system capacity, limiting the performance by the demodulation of the first signal. With or without SIC, the performance is then limited when an interfering signal, considered as noise, is too close in terms of equivalent power (compensated by the frequency difference), meaning typically less than 9 dB. The objective of a simultaneous demodulation algorithm is precisely to make possible the demodulation of two messages at the same time, so that an interfering message is no longer considered as noise, but it is considered as a real signal, in particular in terms of power and phase variation. Two algorithms have been studied:

ƒ

Asynchronous SIC: studied for ESPAIS; detailed design and performances are given

ƒ

Adapted parallel demodulator (APD): studied for another study; performance overview is given

Based on the recommendations, the Asynchronous SIC algorithm or other interesting MUD algorithms are to be used. The main differences between the asynchronous SIC algorithm and the adapted parallel demodulator is that the parallel demodulator is better with power differences between the two signals over 3 dB. This adapted parallel demodulator (APD) can also be adapted to 3 or more signals. SIC and APD algorithms are therefore complementary and allow the solving of most of the 2-signal collisions in the whole AIS domain. A more detailed description of the asynchronous SIC algorithm will be provided. The principle of the asynchronous SIC algorithm is to use the synchronisation difference between two signals to determine recursively the values of the bits of the two signals. On each bit, there are two steps:

ƒ

The first step is the “Evaluation”, of the time period on which the considered signal is alone

ƒ

The second step is the “Removal” of the time period on which the next bit of the other message begins.

It is closed to the basic SIC, but the removal is not done on the complete signal, but recursively bit after bit. The principle is given by the following figure, for a MSK modulation (101010…) on two signals separated by half-a-bit:

Figure 4-14: Simple illustration of asynchronous SIC If the two signals are not separated by half a bit, the “evaluation” part on one signal will be shorter than halfa-bit while it will be longer on the other signal. The “removal” part will on the contrary be longer on the first signal and shorter on the second one.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 35 of 78

Figure 4-15: Synthesised principle of the asynchronous-SIC algorithm For comparison purposes the principle of the adapted parallel demodulator is shown below.

Figure 4-16: Synthesised principle of adapted parallel demodulator (APD)

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 36 of 78

4.3.3 Management Task The management tasks will vary slightly depending on the operational mode of the payload, however the key management tasks have been defined below: ƒ ƒ ƒ

Manage and stock AIS messages coming from the AIS message decoding block. Command and configure the AIS-message decoding, the digital sample and the digital downconversion blocks. Manage the interface with the platform (bus 1553, TM/TC)

A supplementary task has been identified, which consists (after demodulation of a message) of checking if the ship has already been detected, if it is the case, to replace the previous detection. The management functionality will be realised by a FPGA soft-processor core (or PowerPC).

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 37 of 78

Final Report

4.4 Platform The first estimation of constraints on the payload and antenna architecture are dictated by the platform, therefore various candidate platform concepts have been investigated. These concepts are based on existing commercial-of-the-shelf (COTS) platforms, but will be custom manufactured to fulfil the needs of the ESPAIS payload to the highest extent. As satellite bus, the LEO-200 bus, which was developed by OHB-System for application to medium-sized communication satellites in Low Earth Orbit, was selected for application on the ESPAIS spacecraft. With the LEO-200 bus as the platform baseline, the following satellite subsystems are to be designed:

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

Payload Data Handling System Communications On-Board Data Handling Power Attitude Determination and Control Orbit Control Mechanisms Structure Thermal

In Figure 4-17, a block diagram of the complete platform is presented, which shows all relevant subsystems and their interfaces. MagnetoGPS meter Receiver (3 – Axis)

GPS GPS Receiver Receiver

Magnetic GPS Torquer Receiver (3 – Axis)

4-Reaction GPS Wheel Receiver Assembly

GPS Earth Receiver Sensor

GPS Analog Sun Receiver Sensors

GPS Digital Sun Receiver Sensors

AIS Payload Solar Array Solar Array

Digital Signal Processing Digital RF FrontSignal AIS Receiver End Payload Processing Digital RF FrontSignal End Processing RF FrontEnd

VHF Antenna

Cryptography

On-Board Computer On-Board Computer En-/Decoder

Power Conditioning Power Conditioning and Distribution and Distribution Unit Unit

DC/DC

Battery Management

DC/DC

Payload Data Handling System En-/Decoder

Solar Array Mechanisms

Battery Heater Battery Heater

Fuel Heater Fuel Heater C-Band Low Gain Antenna

C-Band Transceiver C-Band Transceiver

C-Band Medium Gain Antenna

Propulsion Propulsion System System

Battery Battery

Antenna Mechanisms

LEGEND Power Interface Data Interface

Figure 4-17: Platform block diagram A brief overview of some of these systems will be discussed in the following subchapters.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 38 of 78

4.4.1 Payload Data Handling System A payload data handling system is required, which stores the payload data during payload operations and extracts it for downlink in times of ground station visibility. For mass memory implementation, classical SDRAM memory devices have been used for years. But additionally, non-volatile Flash memory technology has been evaluated for use in space. Flash has a couple of advantages with respect to SDRAM. However, the main disadvantage is that Flash has not been space qualified at the moment. However, plans exist to perform space qualification of Flash based mass memory in the near future. Therefore, a Flash based solution is used as baseline for the ESPAIS payload data handling system. The payload data handling system consists of:

ƒ ƒ ƒ

Storage Module Input Multiplexer and Decoder Module PDH Controller Module ƒ

PDH Controller Unit

ƒ

Output Multiplexer

ƒ

Channel Coding Unit (including Framing and Encryption)

4.4.2 Communications In order to establish a channel between the ESPAIS spacecraft and the gateway to accommodate a communications link, the ESPAIS spacecraft will be equipped with a C-band transceiver. This piece of equipment combines a receiver for uplink purposes and a transmitter for downlink purposes. In the on-board processing concept, the transmitter possesses only a single mode. It is responsible for transmitting the multiplexed data stream of on-board processing data and housekeeping telemetry. On the other hand, the receiver is responsible for receiving and demodulating telecommands, which have been sent by a ground station. In the hybrid concept, the transmitter possesses only two modes: high data rate and low data rate. The high data rate mode is responsible for transmitting the multiplexed data stream of digital sampling data, on-board processing data and housekeeping telemetry. On the other hand, the low data rate mode is responsible for transmission of on-board processing data and emergency housekeeping telemetry. Additionally, the receiver is responsible for receiving and demodulating telecommands, which have been sent by a ground station.

Cross Strapping

Cross Strapping

In Figure 4-18A, a functional block diagram of the C-band communication system in the on-board processing concept is shown, while Figure 4-18A shows one for the hybrid concept

A. B. Figure 4-18: Block diagram of C-band transceiver A. On-board processing concept B. Hybrid concept

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 39 of 78

4.4.3 On-Board Data Handling The On-Board Computer (OBC) is responsible for the overall control of the payload elements and the bus subsystems. For this purpose, the OBC is responsible for several important functions, which include: „

Telecommand reception from TMTC subsystem

„

Direct telecommand distribution to platform subsystems and payload

„

Support to software command distribution to platform subsystems and payload

„

Telemetry acquisition from platform subsystems and payload

„

Telemetry transmission to TMTC subsystem with configurable data rate

„

Support to Attitude Determination and Control, and Orbit Control subsystems with interfaces to respective sensors / actuators

„

Reconfiguration (with FDIR) and Safe Guard Memory

„

Mass memory management

For the purpose of clearly distinguishing these functions, the design of the On-Board Computer is segmented into multiple module boards. Every board represents a particular set of functions, which have to be performed by the On-Board Computer. This modular design is very flexible, as it allows easy implementation of late design changes. The following modules are included in the OBC: „

Controller modules (primary and back-up)

„

Reconfiguration module (with Safe Guard Memory)

„

TMTC module

„

Interface modules

„

High power module

„

Power converter module

4.4.4 Power The electrical power subsystem is responsible for the generation, storage, conditioning and distribution of electrical power in the ESPAIS spacecraft. For this purpose, the electrical power subsystem consists of various parts: „

Solar array (power generation)

„

Battery ( power storage)

„

Power Conditioning and Distribution Unit (power conditioning, power distribution)

The attitude law of the ESPAIS spacecraft will be equal to nadir pointing with yaw control for sun pointing. Because the ESPAIS spacecraft are not located in a sun-synchronous orbit, the location of the ascending node with respect to the solar radiation vector changes with every orbit. Therefore, the available power has to be assessed for every value of LTAN in the range of 0 o’clock to 24 o’clock. By doing this analysis, it is found that the lowest amount of power is produced in a pseudo 12 o’clock orbit in summer solstice conditions. In a similar way, it is found that the highest amount of power is generated in a pseudo 6:00 (or 18:00) orbit in vernal equinox conditions. A brief power breakdown can be seen in Table 4-9. Table 4-9: Average required and generated power breakdown Dipoles: 3 Rx OBP

Patches: 8 Rx HYB

Average Required Power

220.4

W

248.5

W

Generation Threshold, EOL, 1 SC

520.0

W

579.6

W

Maximum Generated, EOL, 1 SC

579.2

W

636.8

W

Maximum Generated, BOL, 1 SC

806.1

W

886.3

W

2.8

m2

Solar Array Area

2.6

2

m

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 40 of 78

Final Report

4.4.5 Attitude Determination and Control In order to determine the pointing requirements of the spacecraft, multiple systems need to be investigated. The pointing sensitive elements that require consideration are; payload antenna, downlink antenna, power generation (solar arrays) and the thrusters. Combining the pointing requirements of these elements shows that the roll and pitch angles are dictated by the C-band downlink antenna, while the yaw angle is dictated by power generation. Summarizing, the following requirements have been defined.

ƒ ƒ ƒ

Roll: 2.8° Pitch: 2.8° Yaw: 1.8°

The satellites will be placed under numerous disturbance torques and will require specific sensors to measure the spacecrafts displacement and/or rotation. Once the displacement is measured the spacecraft requires certain actuators to rectify its pose. During the different phases of the spacecrafts orbit, the spacecraft will require different orientations in order to operate in its respective mode. A table listing the modes and the specific sensors and actuators enabled is shown below. R,P,Y defines the angle of rotation being measured and X defines when the actuator is in use. Table 4-10: Correlation matrix between sensor and actuator use and attitude modes. Sensor Earth Sensor

Nominal

Eclipse

Acquisition

Thrusting

R, P

R, P

R, P

R, P

Analog sun sensor Digital sun sensor

Y

Safe R, P, Y

Y

Magnetometer

Y

Actuator

Y

R, P, Y Safe

Nominal

Eclipse

Acquisition

Thrusting

Reaction wheel

X

X

X

X

Magnetic torquer

X

X

X

4.4.6 Orbit Control As is calculated in ESPAIS-OHB-RP-12 Satellite Detailed Design Report, the total delta V, which is to be produced during the satellite’s lifetime is equal to 78.9 m/s. This delta V has to be provided by the orbit control system, which consists of the satellite propulsion system. Several propulsion technologies are available. Calculations have been performed for the most promising technologies and can be seen below: Table 4-11: Required resources for orbit control system design options Technology

Fuel

Specific Impulse

Fuel Mass

Tank Volume

Power Consumption

Cold gas

N2 (g)

70 s

43.3 kg

118 l

12 W

Monopropellant

N2H4 (l)

220 s

13.2 kg

14 l

18 W

Resistojet

NH3 (l)

250 s

11.6 kg

17 l

97 W

Green

HPGP (l) 230 s

12.6 kg

11 l

18 W

Based on the results from the table and the consideration that the fuel mass is not the only mass to be considered the baseline propulsion system was chosen to be green propellant. Green propellant does not have the disadvantages of high toxicity of high power consumption, but is at a relative low technology readiness level. However, qualification procedures are running presently, such that space qualification will be accomplished in the very near future.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 41 of 78

Final Report

4.4.7 Mechanisms Mechanisms have to be applied to the following appendages in order to ensure their proper deployment:

ƒ ƒ ƒ

Payload antennas GPS antennas Solar array

4.4.8 Thermal Control The thermal subsystem is responsible for keeping the temperature of all spacecraft components within a predefined range under all circumstances. These include both hot case and cold case situations. The hot case situation for the ESPAIS spacecraft is in a pseudo 6 o’clock orbit in vernal equinox conditions, which coincides with the best case situation for power generation. Similarly, the cold case assumption is in a pseudo 12 o’clock orbit in summer solstice conditions, which coincides with the worst case situation for power generation. The temperature limits for the nodes in the preliminary thermal model can be seen below. Table 4-12: Minimum and maximum temperatures of ESPAIS thermal model nodes Node Solar Array

Minimum Temperature

Maximum Temperature

-93 °C

51 °C

Body

-7 °C

43 °C

Front Panel

-9 °C

3 °C

-23 °C

3 °C

Payload

10 °C

15 °C

Subsystems

16 °C

45 °C

Bottom Panel + Antennas

In addition to the passive elements, the thermal subsystem also comprises active elements. These are heaters and/or heat pumps (coolers), often in combination with a controller and thermostat to incorporate closed loop control. These have to be added to locations, at which the requirement on operating temperature cannot guaranteed by using passive thermal control only. 4.4.9 Structure The structural subsystem is responsible for providing structural integrity to the satellite for the entirety of the mission lifecycle, and to provide accommodation to the payload and subsystems. The main structure composes of the majority of the structural subsystem. The most common material used for this part is an aluminium alloy in a honeycomb or sandwich structure, although titanium or CFRP are also applied. In addition to the main structure, the spacecraft makes use of fasteners and stiffeners to realize connections of subsystems and provide stiffness to the structure.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 42 of 78

4.5 Ground Segment The ground segment for ESPAIS is composed of a control and a mission segment. The control segment is responsible for all actions considering monitoring and controlling of the spacecraft, whereas the mission segment is responsible for all actions considering AIS payload data. As described in the Overall Architecture, the control segment performs several functions including: ƒ

Monitoring of the spacecraft

ƒ

Generation of an operations schedule

ƒ

Reception of Telemetry Data

ƒ

Transmission of Telecommands

ƒ

Satellite Management

Similarly the mission segment can be broken down into three elements; AIS receiving stations, processing centre and a mission segment network. These three elements perform the following functions: ƒ

Collect AIS payload data

ƒ

Operational planning

ƒ

Data processing/archiving/distribution

ƒ

Receiver Antenna

ƒ

Network

ƒ

Operations

The ground segment was then analysed for two scenarios which were identified in the ESPAIS-TAS-RP-13 Ground Segment Detailed Design Report and based on the results from the constellation design. The two scenarios can be seen listed below.

Table 4-13: Breakdown of ground segment scenarios analysed Scenario Batch

Satellites

Earliest launch dates

1

12

Mid 2014 - 2015

2

20

Begin 2021 - End 2021

1

Payload Antenna: 3 dipoles Receiver Architecture : OBP only Antenna: 3 dipoles Receiver Architecture: OBP only Antenna: Phased Array

1

12

Mid 2014 - Mid 2015

(9 phasing laws, 4 antennas) Receiver Architecture: OBP & DBP Hybrid

2

Antenna: Phased Array 2

20

Begin 2021 - End 2022

(9 phasing laws, 4 antennas) Receiver Architecture: OBP & DBP Hybrid

The main differences between the two scenarios are the change in antenna type and the change in data processing mode. A brief description of the difference in computer modes is followed.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 43 of 78

Final Report

ƒ Option “OBP mode only” payload: For such a payload, only the On-Board Processing mode is used. AIS processing is done on-board the satellite, and the AIS downlink is composed of processed AIS data (low rate). Data is transferred in C band, concatenated with satellite servitude telemetry.

ƒ Option “full hybrid OBP & DS mode” payload: For such a payload, On-Board Processing and Digital Sampling can be used, depending of the mission phase. Two modes are recommended, in order to optimize the downlink: -

Mode OBP (On-Board Processing): when the satellite flies over maritime low density areas, as described in the OBP only option.

-

Mode DS (Digital Sampling) + OBP (On-Board Processing): When the satellite flies over maritime high density areas, AIS signals are digitalized on-board and directly bent-piped to the ground: the AIS downlink is composed of raw AIS digitalized signals data (high data rate). Those data are concatenated with satellite servitude telemetry, and also with AIS OBP data processed in parallel on-board. Table 4-14: Payload downlink results for scenario one and two Scenario One

Scenario Two

Low Data Rate

High Data Rate

Low Data Rate

Downlink:

Downlink:

Downlink:

Concatenation of AIS On-board

Concatenation of AIS Digital Sam- AIS On-board Processing,

Processing, Housekeeping Teleme-

pling, AIS On-board Processing,

try, no optical mission

Housekeeping Telemetry

Uplink:

Uplink:

Uplink:

Telecommand

Telecommand

N/A

Downlink:

Downlink:

Data Stream Contents

Housekeeping Telemetry

Housekeeping Telemetry

Emergency & LEOP operations

Uplink:

Uplink:

Telecommand

Telecommand

Data Stream Contents Nominal operations

N/A

PDHS Mean Input Bit Rate (kbps)

4.0

3 220

3.0

Maximum Data Volume (Mbit)

11.7

9 250

8.7

Net Bit Rate (kbps)

32.5

25 700

24.2

44.6

42 400

33.2

Modulation

QPSK

8PSK

QPSK

Coding

Convolutional (3/4)

Channel Bandwidth (kHz)

30.1

useful downlinked data Gross Bit Rate (kbps) (including coding)

TCM (2/3) + RS (255,239) 19 100

Convolutional (3/4) 22.4

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 44 of 78

Final Report

Scenario One

Scenario Two

Low Data Rate

High Data Rate

Low Data Rate

Channel Frequency (GHz)

Into 6.7-7.025GHz

Into 6.7-7.025GHz

Into 6.7-7.025GHz

G/S Antenna Diam (m)

2.4 m

G/S Antenna Type

C-band Parabola

G/S Antenna Locations

Polar stations

7.3 m

2.4 m

C-band Para bola

C-band Para bola

Polar stations

Equatorial stations

Equipment Required

Polar Site

6 x 2,4m antennas

6 x 7,3 m antennas

(3 at each pole)

(3 at each pole)

N/A

30 x 2,4m antennas (15 sites, 2 per site

Equatorial Site

In order to evaluate the timeliness of the information, the maximum revisit time of the satellite was mainly considered (the delay of the ground processing assumed negligible). To determine the best timeliness, three receiving networks were analysed. It was assumed that the minimum elevation for all receiving stations was 5°. The list of receiving stations in each network can be seen below:

ƒ Network A -

Svalbard

-

MacMurdo

ƒ Network B

ƒ

-

Svalbard

-

MacMurdo

-

Redu

Network C -

Svalbard

-

MacMurdo

-

15 equatorial ground stations

From the analysis of the three receiving networks it was verified that Network A is capable of ensuring a data information age of less than 60 minutes worldwide. However, if a reduction of data latency is required, Network B is recommended for 30 minutes over Europe and Network C for 30 minutes worldwide. The detailed results can be seen below Table 4-15: Data information age for various networks, in minutes Timeliness Analysis

Network A

Network B

Network C

Max response time worldwide (minutes)

42,0

42,0

24,4

Mean response time worldwide (minutes)

15,9

15,1

4,7

Max response time over Europe (minutes)

42,0

0,0

4,7

Min access duration (minutes)

6,5

2,0

2,0

Max access duration (minutes)

10,1

10,1

10,1

Mean access duration (minutes)

8,9

8,8

8,3

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 45 of 78

Final Report

Table 4-16: Satisfaction of timeliness requirement by various networks Timeliness Requirement

Network A

Network B

Network C

"30 minutes aging of info over EUR" requ.

NC

C

C

"30 minutes aging of info worldwide" requ. Worldwide

NC

NC

C

"60 minutes aging of info worldwide" requ. Worldwide

C

C

C

As seen in the table above, the only network that is capable of meeting all of the requirements is Network C, however, Network C also involves the most ground stations and therefore has the highest operational cost and complexity. Therefore, based on the actual needs of the user, and the timeliness that is required network the solution may change. Based on the two scenarios that have been evaluated the following results were found. Table 4-17: Network recommendations for each scenario Timeliness

Solution

Comments

1 hr

A

If European requirement, then Network B must be chosen.

C

Recommendation for scenario 2: For the low data rate function Network C is necessary, however for the high data rate Network A is acceptable.

0.5 hr

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 46 of 78

4.6 Launcher In order to investigate the possibility of performing a multi-launch of ESPAIS spacecraft, which involves launching multiple spacecraft simultaneously, several launchers were investigated. As the goal is to use a relatively small platform for the ESPAIS spacecraft (i.e. micro-satellites), only small low-cost launchers have been taken into account. The following launch vehicles have been identified as potential systems: „

Vega - Launched from Kourou, French Guyana. Launch service provider is Arianespace, France.

„

Rockot - Launched from Plesetsk, Russia. Launch service provider is Eurockot, Germany.

„

Dnepr - Launched from Baikonur, Kazakhstan. Launch service providers is Kosmotras, Russia.

„

Falcon 1e - Launched from Kwajalein Atoll, USA. Launch service providers is SpaceX, USA.

„

PSLV - Launched from Bangalore, India. Launch service provider is ANTRIX, ISRO, India.

The rockets listed above were compared and analysed based on their performance capabilities, cost effectiveness and compatibility with ITAR regulations. Based on this preliminary analysis PSLV was chosen as the baseline for the launcher, with Vega as the alternate. In addition, the Falcon-1e was analysed further to evaluate its cost effectiveness.

Figure 4-19: Falcon 1e

Figure 4-20: PSLV

Figure 4-21: Vega

In Table 4-18, the capability of the candidate launchers of launching multiple satellites simultaneously is shown considering the maximum performance. In order to assess the performance capability of every launcher, the wet mass of a single spacecraft was be recalled. These are listed below for the two plausible configurations. „

3 Dipoles: 188.1 kg

„

4 Patches XY: 327.5 kg

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 47 of 78

For every spacecraft, an additional 20% of mass relating to the launch adapter has to be taken into account. This leads to the results shown in Table 4-18. Launcher

3 Dipoles

4 Patches XY

Falcon 1e

3

1

PSLV

7

4

Vega

6

4

Table 4-18: Mass compatibility assumption based on fairing mass Another constraint is introduced by the dimensions of the fairing. This could limit the number of satellites, which are to be launched simultaneously, as the satellites have to be accommodated in a suitable way. It should be noted that although the launcher is capable of launching a large amount of satellites simultaneously, the maximum number of satellites to be launched at a single time is dictated by the amount of satellites in a single orbital plane. A preliminary accommodation procedure on-board the PSLV launcher has been investigated. For this purpose, the 4 Patch antenna concept was chosen. For the 3 dipole concept, the accommodation will be similar, because the spacecraft bus will have approximately the same size. A difference will be the exclusion of the patch antennas in this option, but this will not seriously impact the accommodation. In Figure 4-22, an isometric view of the proposed accommodation lay-out for 4 Patch antenna spacecraft in the PSLV launcher is shown. The required envelope of a single ESPAIS satellite in stowed conditions is equal to 920 x 1020 x 1020 mm.

Figure 4-22: Isometric view of ESPAIS 4 Patches accommodation on-board PSLV launcher.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 48 of 78

5 PERFORMANCE SIMULATIONS 5.1 Simulator Description A simulation tool, AISDET, has been developed at FFI to perform detection probability analysis of AIS equipped vessels. AISDET uses a global vessel density map to simulate reception of AIS messages at LEO. Each vessel transmits according to the SOTDMA scheme on two channels. AISDET computes the signal strength of each message to check if it can be decoded according to receiver performance lookup tables or by defining a signal to noise level for 20% package error rate.

Figure 5-1: Interfaces to the simulations software The outputs of the AIS simulator are:

ƒ Files that provides the coordinates of the sub-satellite point, the number of vessels within the field of view, the number of detected vessels and statistics of the number of messages per slot every 10 second.

ƒ Vessel detection probability maps (per orbit and accumulated maps) ƒ Detection times of each vessel. These files can be loaded by STK to create multi-track objects.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 49 of 78

Final Report

The detection probability of use cases can be calculated in two different ways: ƒ

One is to calculate the detection probability based on the number of vessels (e.g. 2000 of 4000 vessels of a particular use case are detected, therefore there is a detection probability of 50%). The results show the percentage of the assumed vessel distribution will be detected.

ƒ

The other method to calculate the detection probability is based on area. This means that at first a global detection probability map is calculated. Then each use case is divided into small sub-areas (e.g. one square degree). As a final step the average detection probability is then calculated from the mean detection probability of all sub-areas. The result shows what the overall detection probability within the use case is.

In Figure 5-2, the difference between these methods is shortly explained. As more vessels are located in the low detection probability HTZs, the detection probability based on the vessel count average of the green use case areas becomes smaller than the area based average.

Vessel Distribution

AIS Satellite Constellation

AISDET Detection Probability Map 100% 80% 60% 40% 20% 0%

Vessel Based Det. Probability 40% of all vessels in the green target area 50%

100% 100%

80%

50%

100%

95%

100%

70%

50%

50%

70%

100% 100%

Area Based Det. Probability 80% average over green target area Figure 5-2: Area based and vessel count based average use-case detection probability. The modelling of vessel distribution requires certain assumptions to be made. Each vessel transmits according to the SOTDMA protocol. This requires a nominal repetition interval for each vessel and knowing which vessels are within communication range of one another. AISDET assumes that any vessels within 20nm of one other can receive each other’s messages. Class A equipped vessels transmit at 12.5W while class B vessels transmit at 2W, and are given message repetition rates according to the distribution given in “Maritime Traffic Characterization Technical Report”. The default ship radiation pattern is modelled as a 5/8λ dipole antenna mounted three meters above a perfect ground and with vertical polarization. Its gain resembles a doughnut with zero gain in the vertical. The

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 50 of 78

true radiation pattern depends on where the antenna is mounted on a vessel, the materials, shape and orientation of the vessel and reflections from the sea. It is not feasible to model the antenna pattern for each vessel. AISDET can instead use an ideal dipole or an isotropic antenna to investigate how the detection probabilities depend on the transmitter pattern. AISDET computes the polarization of the received signal if the satellite antenna is linearly polarized. It takes into account Faraday rotation and assumes that the polarization was vertical at transmission. This requires knowledge of Earth’s magnetic field and ionosphere. The International Geomagnetic Reference Field (IGRF) gives the Earth’s magnetic field with an accuracy of 0.1nT from 2000 and onwards. CODE2 produces global Total Electron Content (TEC) maps every second hour. Figure 5-3 shows a contour plot of such a map at 12:00 UTC on July 1 2005. The TEC-value used to estimate Faraday rotation is calculated by linear interpolation between successive maps at the relevant time. These calculations include the rotation of the ionosphere maps with respect to the Earth.

Figure 5-3: Contour lot of a global TEC map at 12:00 UTC on July 1 2005 produced by CODE To compute the received signal strengths at the receiver antenna, AISDET uses by default numerical antenna patterns generated by NEC-win (NOU files). NOU files include total gain and the magnitude and phase of the electric field components as functions of the angles theta (vertical) and horizontal (phi). The coordinate system of the NOU files must be identical to the satellite coordinate system. Gain and polarization mismatch loss are computed by transforming the direction of arrival and the direction of the incoming electric field into the antenna coordinate system. Interpolation of the NOU files provides gain and the necessary quantities to compute polarization mismatch loss. The antenna patterns should take into account the structure of the satellite. Figure 5-4 shows one example of a NEC-Win model.

Figure 5-4: NEC-Win model of a 3 dipole antenna pattern along the x-axis

2

http://www.cx.unibe.ch/aiub/ionosphere.html

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 51 of 78

5.2 Traffic Model The vessel model is based on several different sources, which include for the moment ICOADS, NATO, Helcom, flight experiments performed by FFI and the US, Canadian, Danish and Norwegian coast guards. The data sources do not cover all of the world’s littoral waters, i.e. only the east coasts of US and Canada, Gulf of Mexico, Greenland, Iceland, European waters, North Africa, Red Sea and the Gulf of Persia are completely covered. Global vessel distributions are not available and assumptions about the distributions for the open seas and in littoral waters with little or no data must be made. Only the east and west coasts of US and Canada, Gulf of Mexico, Greenland, Iceland, European waters, North Africa, Red Sea and the Gulf of Persia are completely covered. The ICOADS data set serves as a starting point for the open seas distribution. The ICOADS map was scaled by counting the traffic entering and leaving European waters for South and North America. To estimate the number of vessels in these waters, the GDP at purchasing power parity of groups of countries was used as a measure for the number of vessels within the exclusive economic zone (EEZ) of these countries. This required a vessel density number per GDP at purchasing power, which was calculated by simply dividing the number of vessels within European, US and Canadian waters by their total GDP at purchasing power parity. The ICOADS vessel density distribution was scaled within the world’s EEZs according to the vessels per GDP number. Furthermore, dividing the world into subsets removes most of the northsouth bias in the ICOADS density map since most of the vessels are close to the coast. The vessel distribution has 55,500 active vessels together with two different distributions of message repetition rates; see Figure 5-5 and Table 5-1. The two distributions were determined by analyzing speeds, rate of turns and navigational status in the North Sea, the Mediterranean Sea and vessels leaving European waters travelling towards America. The repetition rate of vessels outside 40nm uses the last observed speed and rate of turn before the vessels left regions observable by AIS base stations. 40nm is a typical range of AIS base stations. The final assumptions made about the vessel distribution are that the each vessel’s repetition rate remains constant during each simulation and that the vessels stay in the same area during each simulation. The last assumption does not hold for long simulation runs were vessels may travel long distances. However, the distribution itself is expected to remain the same throughout the simulation. It is also necessary to make some assumptions about the transmitted AIS signals. AISDET models the transmissions as those coming from a vertical 5/8λ dipole antenna transmitted at 12.5W. There are indications that the transmitted signal strength varies significantly from vessel to vessel. [RD 5] defines the relationship between speed, rate of turn and navigational status with repetition rates.

Figure 5-5: Plot of vessel density distribution

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 52 of 78

Table 5-1: Measured distribution of repetition rates for class A vessels and using vessels in the North Sea, the Mediterranean Sea and vessels leaving European waters for America from August 2008. Repetition rates (s)

Within 40nm of a coastline

Outside 40nm

2

0.04

0.06

3 1/3

0.06

0.15

6

0.14

0.29

10

0.48

0.48

180

0.28

0.02

Additionally, assumptions need to be made for the vessel distribution for the coming years, particularly because the ESPAIS needs to be functional for years to come. Consequently, the increase in vessels until 2024 has been estimated. The number of vessels may increase with 20% to 60% per decade depending on economic growth and there may be as much as 20% to 40% extra vessels due to regulation changes for fishing vessels. The model has 65,700 vessels in 2014, 78,600 vessels in 2019, 94,200 in 2024 and 107,800 in 2024 when including regulatory changes.

5.3 Use Case Definition One-square-degree detection probability maps from FFI’s AISDET simulations have been used as starting point for the per-use-case evaluations. From these area-based products average vessel detection probabilities have been calculated for the following use cases: ƒ

ƒ

High Traffic Zones: -

North Sea

-

Mediterranean Sea

-

GB

-

China

-

Gulf of Mexico

-

Black Sea

Non–HTZs: -

US-East-Coast

-

North Atlantic

-

US Atlantic

The use-cases can be seen depicted in section 2.3. 5.3.1 Summary of maritime traffic characterisation The baseline vessel distribution of class A transponders contains 55,500 vessels. Approximately 20% of the vessels are outside the range of shore-based AIS base stations. The seasonal variations are less than the uncertainty in the total number of vessels, but some changes were observed: 1. There are more fishing vessels with AIS in the Arctic during winter than during summer. 2. The highest number of leisure boats and passenger ships in the Mediterranean Sea are seen during the holidays in August.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 53 of 78

Final Report

Table 5-2 summarizes some details from this distribution. The areas of some of the use cases include significant land areas. These use cases are the Arctic, British Isles, US East coast, US West coast, Australia and New Zealand. The number of vessels outside the range of shore based AIS stations (3rd frequency) are highly uncertain for the use cases where the number of vessels are estimated from GDP. Class B vessels are currently not a significant source of noise. The specific vessel lists used in the system simulations will be provided together with the simulations results. Table 5-2: Summary of maritime traffic characterization as of October 2008 Use Case

Area (km2)

Number of vessels (today + 15 years)

3rd frequency (today + 15 years)

Comment

Arctic (north of 67°N)

20,300,000

470 (940)

120 (240)

NATO-feed plus flights, 50% of the vessels are near the Norwegian coast. 5% increase per year due to oil and gas exploitation in the Arctic

Barents Sea

600,000

30 (60)

7 (14)

NATO-feed plus flights, 15 vessels more than 40nm from the coast

Coast of Nordic countries excl. Iceland

530,000

2500 (3400)

0 (0)

Within the range of coastal AIS base station

North Sea

660,000

2000 (2700)

400 (540)

NATO feed + flights, 300 vessels outside the range of base stations

British Isles

1000,000

1500 (2000)

270 (360)

NATO feed, excl. channel coast (October 2008)

Bay of Biscay

470,000

370 (500)

170 (230)

NATO feed + flights, includes shipping lanes (October 2008)

Mediterranean Sea

2,500,000

6200 (8300)

750 (1000)

NATO feed, 750 vessels more than 40nm from the coast (October 2008)

Black Sea

436,000

1100 (1300)

200( 270)

NATO feed, 150 vessels more than 40nm from the coast (October 2008)

Persian Gulf

251,000

1000 (2100)

160 (330)

NATO feed (October 2008)

EEZ of Australasia

15,300,000

4500 (7600)

450 (7600)

Estimate based on GDP, high uncertainty

EEZ of Africa

7,800,000

1500 (3000)

600 (1200)

Estimate based on GDP, excludes the Mediterranean Sea

EEZ of South America

8,700,000

2500 (5200)

250 (520)

Estimate based on GDP, high uncertainty

Gulf of Mexico

2,800,000

3500 (4700)

400 (540)

US coast guard (July 2007)

US and Canadian west coast

11,200,000

2000 (2700)

500 (670)

US coast guard (July 2007)

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 54 of 78

Final Report

Use Case

Area (km2)

Number of vessels (today + 15 years)

3rd frequency (today + 15 years)

Comment

US East coast

8,900,000

2500 (3400)

600 (800)

US coast guard (July 2007)

New Zealand & Australia

26,300,000

2800 (3800)

350 (470)

Estimate based on GDP and ICOADS in open waters, high uncertainty

China, South-Korea, Japan

1,300,000

8500 (16000)

850 (1600)

Estimate based on GDP and ICOADS in open waters, high uncertainty, Korea and Japan are developed countries

EEZ of India

1,500,000

1900 (4000)

200 (420)

Estimate based on GDP, high uncertainty

Straits of Singapore and Malacca

230,000

1400 (1900)

10 (13)

National Defence Magazine, (June 2007)

Simulations of the system performance must take into account uncertainty in the vessel distribution and message repetition rates. The uncertainty is 10% or better in the areas covered by the Helcom and NATO sources, and up 25% elsewhere. Varying the repetition rates by much more than their uncertainties may provide an understanding on how the detection probabilities of specific vessels depend on their repetition rates. The following traffic scenarios will be used together with the baseline traffic scenario: 1. 10% increase and decrease in the number of vessels with respect to the baseline scenario 2. An increase in the number of vessels according the growth rates given in the ESPAIS-FFI-RP-02 Traffic Characterization Document for the next 5, 10 and 15 years. 3. Fourteen thousand extra vessels near land due to regulation changes for fishing vessels 4. Add up to 20,000 and 50,000 class B vessels in littoral waters to check the interference from Class B vessels on current and future traffic conditions. 5. Investigate the effect of interference due to land-based reuse of AIS frequencies on current and future traffic conditions. Three sources will be evenly spaced in the mountain states of USA that transmit on one AIS-channel at 50W and during 10%, 40% and 100% of time. 6. The scenarios 1 through 4 will be repeated for a third AIS frequency optimized for space

5.4 Selected Simulation Results The performance simulations have provided input into both constellation design and antenna selection. The simulated antenna options are phased patch array, phased helix array, three perpendicular monopoles, three perpendicular dipoles, spinning and non-spinning long helix antenna and a phased Yagi array. The phased patch array had the best performance, but it was also the most complex antenna solution. Additional simulations were required for the constellation design: three satellites with phased helix array, three satellites with three perpendicular monopoles, satellites with 65, 73 and 90° inclination and a constellation with nine satellites. The outputs from these simulations include maps with a spatial resolution of 1x1 degrees containing average detection probabilities and files containing message detection probabilities for each message sent during the simulation. These detection probability maps were provided for each orbit and for requested intervals of orbits

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 55 of 78

Final Report

In Table 5-3, the obtained detection probability of a single satellite during a 24 hours time interval is shown for every possible antenna option categorized per use case.

North Sea

Bay of Biscay

Mediterranean Sea

Black Sea

Africa

Persian Gulf

Far East

Singapore

Australia

US Pacific Coast

US Atlantic Coast

Gulf of Mexico

North Atlantic

Antenna Type Yagi Array 3 Ideal Dipoles 4 Helices, 4 Phases 4 Helices, 5 Phases 4 Patches CP, 4 Phases 4 Patches XY, 4 Phases 4 Patches CP, 5 Phases 4 Patches XY, 5 Phases Helix Vertical Helix Left 60° Helix Right 60° Helix Backward 60° Helix Forward 60° One Patch Spinning Helix Three Monopoles One Monopole

Barentsz Sea

Use Case

Arctic North

Table 5-3: Summary of detection probability values per use case

0,99 1,00 1,00 1,00 1,00 1,00 1,00 1,00 0,98 1,00 0,99 0,99 0,98 1,00 1,00 1,00 0,99

1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00

0,01 0,13 0,14 0,14 0,14 0,14 0,14 0,20 0,07 0,06 0,11 0,07 0,09 0,07 0,06 0,10 0,02

0,29 0,64 0,58 0,58 0,64 0,87 0,66 0,90 0,11 0,23 0,42 0,34 0,34 0,16 0,35 0,56 0,25

0,24 0,54 0,55 0,55 0,57 0,72 0,58 0,77 0,30 0,41 0,40 0,37 0,34 0,35 0,37 0,47 0,31

0,50 0,65 0,67 0,67 0,77 0,86 0,77 0,87 0,31 0,35 0,46 0,53 0,43 0,35 0,55 0,56 0,44

0,98 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 0,99 1,00 1,00 0,99 1,00 0,99

0,88 0,94 0,96 0,97 0,99 0,99 0,99 0,99 0,86 0,88 0,91 0,89 0,86 0,82 0,86 0,92 0,86

0,44 0,60 0,56 0,56 0,65 0,79 0,67 0,80 0,35 0,42 0,42 0,43 0,47 0,39 0,44 0,50 0,38

0,74 0,82 0,84 0,84 0,85 0,89 0,86 0,89 0,76 0,75 0,79 0,76 0,77 0,70 0,76 0,79 0,67

0,93 0,99 0,99 0,99 1,00 1,00 1,00 1,00 0,95 0,96 0,95 0,95 0,96 0,95 0,95 0,98 0,94

0,97 0,97 0,98 0,98 0,98 0,99 0,98 0,99 0,93 0,95 0,95 0,93 0,94 0,92 0,94 0,97 0,94

0,88 0,89 0,92 0,92 0,94 0,97 0,95 0,98 0,75 0,83 0,82 0,81 0,80 0,75 0,82 0,87 0,81

0,50 0,62 0,69 0,69 0,73 0,82 0,76 0,83 0,32 0,41 0,42 0,38 0,39 0,29 0,80 0,56 0,40

0,77 0,87 0,87 0,87 0,89 0,94 0,90 0,95 0,69 0,76 0,79 0,78 0,78 0,72 0,78 0,83 0,74

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 56 of 78

Each graph of the update interval CDF shows the behaviour of the update interval for every possible repetition time. These graphs show a general trend that the lower the repetition time, the lower the update interval. This can be easily explained by realizing that a low repetition time infers a high probability that at least a single message will be detected. For every single use case, the Cumulative Density Function (CDF) is shown. In Figure 5-6, the update interval CDF of the North Atlantic use case is presented. Similarly, the update interval CDF of the Gulf of Mexico use case is shown in Figure 5-7, while Figure 5-8 shows the update interval CDF of the Mediterranean use case.

Figure 5-6: Update interval CDF of North Atlantic use case

Figure 5-7: Update interval CDF of Gulf of Mexico use case

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 57 of 78

Figure 5-8: Update interval CDF of Mediterranean use case

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 58 of 78

6 FIRST ELEMENT 6.1 Description The primary objective of the ESPAIS First Element will be to demonstrate the improved performance of the hybrid phased array solution. Hence, the Patch XY concept with hybrid payload will be used as baseline for the development of the first element. An important function of the first element will be to demonstrate the compatibility of the AIS and optical payloads. The EO payload will operate in a random sampling mode, which has a higher performance-to-cost ratio and will make use of a scanning mirror to increase the effective swath width. The EO payload will operate with 14 mirror positions, 7 left and 7 right, resulting in a total effective swath width of over 1000 km.

Figure 6-1: Image collection using a scanning mirror In Figure 6-2, a close-up of the proposed EO payload is shown. In consists of an MWIR optical system, which is a refractive system containing 5 lenses, made of Silicon and Germanium (see Figure 1). It is designed for snapshot operation, imaging an area on the ground of 46.3 km along track x 57.8 km across track on the detector surface. The detector is oriented such that the shortest side of the detector is parallel to the movement of the satellite. This way, the widest possible swath is covered.

Figure 6-2: Close-up of proposed EO payload

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 59 of 78

Table 6-1 shows the performance parameters of the EO payload, while Table 6-2 presents relevant technical parameters. Table 6-1: EO payload performance parameters

Table 6-2: EO payload technical parameters Parameter

Value 31.2

Mass Dimensions (envelope) Power Consumption

kg

537 x 158 x 150 Imaging

38

W

Standby

16

W

Cooldown

25

W

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 60 of 78

Final Report

In relation to the First Element, the broadband C-band link is well-suited to accommodate any data generated by the EO payload. After all, its character allows accommodation of the large data rate of the EO payload. The narrowband link would be ill-suited because it would not have sufficient bandwidth. Starting out with selection of the total bandwidth, the available duty cycle of the EO payload can be calculated. After all, the required bandwidth due to AIS digital sampling is known, hence the remainder of the bandwidth can be used for EO payload data. After selecting a total bandwidth of 22,000 kHz, an EO payload duty cycle of 23.6 % is found, which is assumed to be constant across all orbits. Ideally the EO payload and AIS payload would detect the same vessels. However, in practice this is unlikely to occur due to the limited field of view of the optical sensor. The maximum time difference between the collection of AIS data and EO data for the same vessel is 370.7 seconds which is deemed acceptable. Taking note of the abovementioned analysis, it is concluded that a dipole concept would not be well-suited for the First Element. After all, it would have to be equipped with an additional C-band broadband transmitter. In addition, the frequency filing at ITU for a broad C-band transmission slot has to be done (although it will not be used after the First Element phases out). The First Element design parameters are summarized in Table 6-3. Table 6-3: Baseline technical parameters of First Element Parameter

Value 550

Orbit Altitude # of Receivers

km

8

Dry Mass

363.3

kg

Wet Mass

389.8

kg

Payload Mass

102.2

kg

Delta V

77.7

m/s

Average Power Consumption

271.9

W

Payload Power (Average, excl. Tx)

97.1

W

Peak Power Generation (EOL, 1 SC)

694.4

W

Data Storage

10,660

Mb

Downlink Data Rate

48,800 kbps

Detailed consequences to the subsystem components are listed in Table 6-4. Table 6-4: First Element detailed component consequences Component

Baseline

First Element

Delta

EO Payload

None

Integrated

Complete EO payload

Solar Array

18s44p; 2.8 m2

18s48p; 3.0 m2

4 extra strings, 0.20 m2

Battery

8s20p

8s24p

4 extra strings

C-band Transmitter

42,400 kbps; 12 WRF

48,800 kbps; 15 WRF

6,400 kbps; 3 WRF

Payload Data Handling Unit 9,250 Mbit

10,660 Mbit

1,410 Mbit

Mass

331.6 kg

389.8 kg

58.2 kg

Delta-V

78.9 m/s

77.7 m/s

-1.2 m/s

Power

248.4 W

271.9 W

23.5 W

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 61 of 78

In Figure 6-3, the deployed configuration of the ESPAIS First Element satellite is shown. Included in this illustration is the field of view of the electro-optical payload.

Figure 6-3: Deployed view of ESPAIS First Element spacecraft

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 62 of 78

In Figure 6-4, a close-up internal view of the ESPAIS First Element spacecraft is shown, which focuses on the accommodation of the electro-optical payload.

Figure 6-4: Close-up view of EO payload accommodation in First Element spacecraft

A. B. Figure 6-5: First Element launcher accommodation A. Single spacecraft in Falcon-1e launcher B. Two spacecraft in PSLV launcher

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 63 of 78

7 DESIGN AND DEVELOPMENT PLAN 7.1 Roadmap As has been stated in the requirements, the ESPAIS system has to be operational in 2015. Furthermore, a total system lifetime of 15 years has to be guaranteed. An additional requirement states that the satellite lifetime shall be at least 7.5 years. Hence, in total 2 batches of satellites have to be deployed to meet the system lifetime requirement. However, the amount of satellites will differ for both batches due to changes in the maritime traffic situation. The launch of the first main batch of spacecraft will be preceded by the deployment of the First Element. Although this First Element will be launched before deployment of the main system, it will be a part of the complete operational system. Hence, it has to make a contribution to meeting the system lifetime requirement. All in all, three deployment phases are envisaged for the ESPAIS system. These are:

ƒ First Element ƒ Batch I ƒ Batch II In the cost assessment and roadmap creation, it has been assumed that a commercial development approach will be taken. This allows for a short development schedule and low cost deployment strategy. In the next chapters, the cost assessment for both Scenario 1 and Scenario 2 will be given. In the main cost assessment only First Element and Batch I will be taken into account. Batch II will not be further considered due to high uncertainty in its technical design and the economic situation at time of development.

7.2 Design Standards OHB provides a long range of experiences in Product Assurance & Safety activities as Prime-Contractor for ESA projects such as EPM, SGEO and GALILEO, and the German Government for SAR-Lupe as well as subcontractor in a wide range of manned and unmanned projects. Appropriate Product Assurance programs have controlled these programs for full Customer satisfaction. The selection of components and qualified manufacturers/suppliers will be based on the knowledge regarding technical performance, qualification status and history of previous use in similar space applications (EnMAP). If CLASS 3 components do not meet the operating performance, stability, environmental, material, safety, quality and reliability conditions for the life cycle than higher classes will be selected in order to fulfil the radiation control policy and test philosophy in compliance with the radiation requirements in order to avoid additional radiation testing. Components will be chosen which are included in the European Preferred Parts List ESCC 12300. The procurement from non European/Canadian sources will be minimized. Special concern will be given to the procurement planning dependent on the export restrictions (ITAR). Components selection will be driven by similarity to comparable projects and mission profiles to be more cost effective. Procurement control may also refer to previous projects. OTS (“Off-The-Shelf”) hardware and software equipment may be used, provided that it is evaluated, if necessary modified, analyzed, and qualified, in order to demonstrate compliance with the S-5 Precursor environmental and functional requirements. The identification, documentation, justification and tracking of all information concerning each OTS (HW or SW) is part of the procurement plan (OTS Item List, OTS Suitability File). Hardware designed and qualified for use on other space programmes shall be considered for use on the low cost mission. Re-used software has been already used for a previous space project (SAR-Lupe, EnMAP). With additional tests and documentation, the adoption for a new project should be possible. Reuse of existing software will be described in the Software Product Assurance Plan.

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 64 of 78

Final Report

7.3 Proposed Development Schedule In Figure 7-1 the proposed development schedule for the ESPAIS project is presented. In line with the aforementioned assumptions, only Batch I is considered. Please note that the dates of the included milestones are tentative only. Nr.

Vorgangsname 4. Qtl

1

Preliminary Requirements Review

2

Phase-B1

3

System Requirements Review

4

Phase-B2

5

Preliminary Design Review

6

Phase-C

7

Critical Design Review

8

Phase-D

2011 1. Qtl PRR

2. Qtl 3. Qtl 04.04.

4. Qtl

2012 1. Qtl

2. Qtl

3. Qtl

SRR

4. Qtl

2013 1. Qtl

2. Qtl

3. Qtl

4. Qtl

2014 1. Qtl

2. Qtl

3. Qtl

4. Qtl

2015 1. Qtl

2. Qtl

3. Qtl

4. Qtl

2016 1. Qtl

2. Qtl

3. Qtl

4. Qtl

01.10. PDR

02.07. CDR

31.03.

9

Qualification Review

10

Operational Readiness Review

11

Acceptance Review

12

Phase-E

13

Flight Readiness Review

14

Launch Readiness Review

15

Launch 1

16

Launch 2

17

Launch 3

18

Launch 4

L4

19

Commissioning Result Review

CRR

QR

03.08. ORR

05.10.

AR

05.10.

FRR

02.11.

LRR

07.12. L1

01.02. L2

14.03. L3

Figure 7-1: Proposed development schedule

02.05. 18.07. 01.08.

2017 1. Qtl

2. Qtl

3. Qtl

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 65 of 78

7.4 Cost Estimates For the cost assessment, the following assumptions have been taken:

ƒ Launch in 2015 ƒ Lifetime of 7.5 years ƒ No dedicated First Element: First Element is merged with Batch I into a single batch of 12 satellites ƒ Constellation of 4 planes times 3 satellites ƒ All satellites carry identical AIS payloads, i.e. no phased array payload for First Element satellites in Batch I (divergence from technical baseline)

ƒ Only polar ground stations, i.e. no low-latitude stations Cost estimates values have been consequently provided for both scenarios 1 and 2 in their baseline constellations (12 satellites). In order to check the sensitivity of these cost values to the amount of satellites, also 6satellite and 9-satellite constellations were investigated, which might provide a cost-effective alternative at the cost of not meeting the 80 % detection probability requirement in some use cases.

7.5 Reliability 7.5.1 Redundancy Approach Every ESPAIS spacecraft is designed according to the single point failure free principle. This means that a failure of a single component is not allowed to cause complete failure of the mission. For this reason, critical components have to be applied redundantly. In the next discussion, every redundant component is in cold redundancy, that is the redundant component is switched off until the primary component fails. As was described in detail in the previous sections, the design of most subsystems already incorporated some form of redundancy. In the following paragraphs, all redundancy measures are summarized. The solar array was sized to cope with the loss of strings due to damage cause by e.g. micrometeorites. This was done by adding an additional strings to the solar array to the minimum required amount. Note that this concept can only handle a string failure in open circuit. A short circuit failure can be handled by the remaining cells in the string by shifting their operating point. Multiple short circuits could prove problematic, however.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 66 of 78

7.5.2 Reliability Budget In Table 7-1, a reliability budget of the complete ESPAIS spacecraft is presented. Table 7-1: Reliability budget of the complete ESPAIS spacecraft is presented. Subsystem

Reliability @ 7.5 years

AIS Receivers

0.92

Payload Data Handling + Transmission

0.98

Payload total

0.90

Power

0.97

OBC

0.95

ADCS

0.98

OCS

0.99

S-band Downlink & TMTC

0.98

C-band Downlink

0.98

Platform total

0.89

Spacecraft total

0.80

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 67 of 78

Final Report

8 CONCLUSIONS AND RECOMMENDATIONS 8.1 Conclusions The solution proposed for the ESPAIS system was determined by evaluating two scenarios, therefore providing two solutions. The two scenarios can be seen listen in Table 8-1, whereby scenario one will use a satellite configuration with 3 dipole antennas and scenario 2 will use a satellite configuration with a phased patched array antenna. Performance analyses were performed for every available system configuration option, resulting in a constellation layout, which was optimized for the fulfilment of the requirements corresponding to each system scenario. For every system configuration, a spacecraft has been designed, which is capable of supporting the corresponding payload architecture. On basis of the complete system design, a cost assessment has been performed, which resulted in the selection of a baseline system configuration for every available system scenario. Note that the system configurations have been optimized to the threshold requirement of 80% detection probability. Table 8-1: System Scenarios Overview Scenario Number

HTZ except North Sea

Global except HTZ

Minimal Ship Detection (within Update Interval)

Timeliness

#1

N/A

3 hr

80 % (95 % goal)

1h (30 min. goal)

#2

3 hr

1 hr

80 % (95 % goal)

1h (30 min. goal)

It has been determined that the ESPAIS system will be implemented in two batches in order to be cost effective and to ensure that the increase in vessel traffic over time will be accommodated by the system. A summary of the batch details is as follows.

ƒ

Batch I ƒ

ƒ

12 satellites -

4 orbital planes

-

3 satellites per orbital plane

Batch II ƒ

20 satellites -

5 orbital planes

-

4 satellites per orbital plane

The orbital parameters are very similar for the two scenarios and can be found in section 4.1. The two scenarios that have been generated throughout this study are shown in section 2.3 . These are the two scenarios that are being recommended for future studies, such that depending on the time, budget and requirements a single solution can be chosen.

Payload The payload for the ESPAIS system will be an AIS receiver that must be able to detect a minimum of 80% of vessels in the required areas. A FPGA solution will be used that will allow the satellite to operate in two modes: an on-board processing (OBP) mode and a digital sampling (DS) mode. In scenario 1, only OBP mode will be used, while in scenario 2, the OBP mode will be used majority of the time in addition to the DS mode being used over HTZs. In addition, the systems will utilise asynchronous SIC algorithms (ESA algorithm + SIC) to increase performance, which subsequently increases the detection probability by almost 3 percentage points. The antenna choice for the payload was driven by the two scenarios and the detection probabilities that they required. The two antenna options chosen were 3 orthogonal dipoles for scenario 1 and an XY polarised

ESPAIS

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 68 of 78

Final Report

phased patched array for scenario 2. Of the antennas that were evaluated, the phased array options showed the best results, particularly for the HTZs. However, for scenario 1, HTZs were excluded therefore allowing the simpler 3 dipole option to be used as it provided sufficient results. As satellite bus, the LEO-200 bus, which was developed by OHB-System for application to medium-sized communication satellites in Low Earth Orbit, was selected for application on the ESPAIS spacecraft. With the LEO-200 bus as the platform baseline, the following satellite subsystems are to be designed: A summary of the two configurations can be seen below, as they are driven by the payload. Table 8-2: Summary of characteristics of baseline configurations

Orbit Altitude

Scenario 1 Optimized

Scenario 2 Optimized

3 Dipoles

4 Patches XY

600 → 500

# of Receivers Receiver Architecture

km

550

km

3

8

On-board Processing

Hybrid

Dry Mass

184.7

kg

315.0

kg

Wet Mass

188.1

kg

327.5

kg

Delta V

39.0

m/s

78.9

m/s

Average Power Consumption

220.4

W

248.5

W

Power Generation Threshold (EOL, 1 SC)

520.0

W

579.6

W

Data Storage

11.7

Mb

9,250

Mb

Downlink Data Rate

44.6

kbps

42,400

kbps

Ground Segment The ground segment selection is critical for the timeliness of data collected by the ESPAIS satellites and therefore 3 networks were considered. The amount of data generated for the two scenarios varies as the first scenario does not have to collect data over the HTZs and therefore never has to use the digital sampling mode. It consists of two segments that divide the tasks into terrestrial and space based. The control segment is responsible for all actions considering monitoring and controlling of the spacecraft, whereas the mission segment is responsible for all actions considering AIS payload data. As gateways, two polar stations being Svalbard and MacMurdo will be used for both payload data downlink and TMTC. These baseline stations can be complemented by 15 equatorial gateways to reduce the timeliness to below 30 minutes. In scenario 1, on-board processing data and housekeeping telemetry data are multiplexed into a single data stream. Scenario 2 will make use of two modes: a low data rate mode and a high data rate mode. These modes will be offered by a single piece of transmitting equipment, which will switch between modes dependent on the orbital position. First Element The first element has been chosen to use the phased patched array antenna in order to demonstrate the improved detection probability that it can achieve. In addition, the first element is intended to compare the two operating modes, and verify the performance of various components and subsystems. Although the first element will use the phased patched array, it will be unable to meet the requirements for many use cases. However, it will already be able to deliver a high detection performance in specific use cases with lower amount of traffic.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 69 of 78

An important function of the first element will be to demonstrate the compatibility of the AIS and optical payloads. The EO payload will operate in a random sampling mode, which has a higher performance-to-cost ratio and will make use of a scanning mirror to increase the effective swath width. The EO payload will operate with 14 mirror positions resulting in a total effective swath width of over 1000 km. Performance The performance of the configurations for each scenario was very good, as the detection probability was met for most use cases. For scenario 1 the detection probability results for global waters including the HTZs was 48% in 1 hour and 61% in 3 hours. The analysis was performed using the 2021 traffic model with ESA algorithms in combination with SIC algorithms. It should be noted that in the early phases of the scenario the detection probabilities will be better as the constellation is to be launched in 2014, meaning there will be less vessels to cause signal interference. The simulated results do not meet the desired 80% detection level for every case however, when the results are looked at on a closer level it is clear that the results are better than initially perceived. For all global regions (excluding HTZs) there were only two areas that were lower than the 80% detection requirement which were the North Atlantic and the US Atlantic. This is encouraging because with the implementation of land based AIS, the ESPAIS system only has to detect those vessel in open seas, improving the results dramatically. The combination of land based and space based AIS enables the detection probability to exceed the required 80% and reach the goal of 95% detection. The results for scenario 2 are better than scenario 1 as expected, as the detection probability for the patch array is better than the 3 dipole antenna. The system was able to provide a detection probability of 66% for 1 hour and 80% for 3 hours on a global scale, using the same traffic model and combination of algorithms as scenario 1. When evaluating the results it can be seen that the user requirements for the global 1 hour update interval is not satisfied however, the results are still promising. A closer look at the results for the 3 hour update interval is needed to see if the 3 hour detection probability for HTZs is met. Overall, the solution performed well, however the 3 hour update case in the HTZs still proved to be problematic for the Gulf of Mexico and the North Sea. These results were improved by including the use of land-based or coastal AIS, whereby all use cases had a detection probability greater than 80%, surpassing the goal of a detection probability of 95% except for the North Sea, which was 74%. Despite the few use cases that did not meet the user requirements for scenario one and two, most areas were able to satisfy the user requirements. The area that had unsatisfactory results can achieve the desired results if only open sea traffic is taken into account. This situation is representative of the space-based AIS using the existing infrastructure of coastal stations to reduce the load on the satellite system, which is a viable assumption to consider for this system. The coordination between land and space based AIS is vital to achieve the desired results and is a highly feasible solution.

8.2 Recommandations Several recommendations can be drafted as a result of the ESPAIS study. These are: „

Further develop solution in terms of constellation design and receiver/antenna technology in order to meet AIS user requirements. Cost-effectiveness and low risk shall be closely considered. This will be the subject of ARTES-21 Phase-B1.

„

Expand mission analysis to include complementary payloads (e.g. SAR, I/R, Navrad detector) for maritime surveillance proposes. This is the subject of the SMRS mission within the GSTP-5 programme.

„

Further investigate the application of phased array antennas for AIS signal detection.

„

Further develop signal processing algorithms with the focus on multi-user detection algorithms.

„

Investigate integration of space-based AIS data with other sources to enhance the recognised maritime picture. This will be the subject of ARTES-21 Hybrid Model Elaboration.

„

Investigate funding possibilities to increase the probability of getting a European space-based AIS system deployed, e.g. PPP. This will be the subject of ARTES-21 Public Private Partnership.

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 70 of 78

9 ASSOCIATED DOCUMENTATION 9.1 Applicable Documents Ref. No.

Organisation; Publisher

Title

Document ID No.

Issue /Rev.

Date

[AD 1] Project Planning and Implementation

ECSS

ECSS-M-ST-10C

3 Rev. 1

March 2009

[AD 2] PA & Safety Strategy for Inorbit Demonstration LightSat Concept

ESA-ESTEC

TEC-Q/09-6970

1

March 2009

Table 9-1: List of Applicable Documents

9.2 Reference Documents Ref. No.

Organisation; Publisher

Title

Document ID No.

Issue Rev.

Date

[RD 1]

Space-based AIS User Requirements

ESA - Directorate of Telecommunication and Integrated Applications

TIA-TF/200915894/RR

02

29.04.2009

[RD 2]

Identification of European Needs and Benefits of a Global Space based Automatic Identification System

FFI

RES-1110-30

1.1

05.02.2009

[RD 3]

Technology Reference and Proof-of-Concept for a Space-Based Automatic Identification System for Maritime Security – User Requirements Document

FFI

RES-210-10

1.2

05.09.2007

[RD 4]

EUSC communication with the French West Indies Commandment

EUSC

ESPAIS-EUSC-RS01

1.0

30.01.2009

[RD 5]

Technical characteristics for a universal shipborne automatic identification system using time division multiple access in the VHF maritime mobile band

ITU

ITU-R M.137-1

Table 9-2: List of Reference Documents

2001

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 71 of 78

9.3 List of Acronyms and Abbreviations Acronyms and Abbreviations AC

Alternating Current

ACS

Attitude Control System

A/D

Analog to Digital

AD

Applicable Document

ADCS

Attitude Determination and Control System

AIS

Automatic Identification System

AIV

Assembly, Integration and Verification

AMVER

Automated Mutual-assistance Vessel Rescue System

AOCS

Attitude and Orbit Control System

APD

Adapted Parallel Demodulator

ASP

Application Services Provider

BER

Bit Error Ratio

C4ISR

Command, Control, Computers, Communications, Intelligence, Sensors and Reconnaissance

CAPEX

Capital Expenses

CDR

Critical Design Review

CDU

Channel Decoding Unit

CCSDS

Consultative Committee for Space Data Systems

CCU

Channel Coding Unit

C/N

Carrier/Noise

COTS

Commercial Off The Shelf

CSP

Communication Services Provider

CZ

Coastal Zone

D/C

Down Converter

DC

Direct Current

DS

Digital Sampling

D/U

Desired/Undesired

ECSS

European Cooperation for Space Standardization

EDA

European Defence Agency

EGSE

Electrical Ground Support Equipment

EEE

Electrical, Electronic and Electromechanical

EIRP

Equivalent Isotropic Radiated Power

EIS

European Index Server

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 72 of 78

Acronyms and Abbreviations EM

Engineering Model

EMSA

European Maritime Safety Agency

EO

Electro-Optical

EPS

Electrical Power Subsystem

EQM

Engineering Qualification Model

ESA

European Space Agency

ESOC

European Space Operations Centre

ESPAIS

European Space-Based AIS System

ESTEC

European Space Research and Technology Centre

EU

European Union

EUSC

European Union Satellite Centre

FM

Flight Model

FOV

Field of View

FR

Final Review

GIS

Geographic Information System

GMES

Global Monitoring for the Environment and Security

GNSS

Global Navigation Satellite System

GPS

Global Positioning System

G/S

Ground Segment

GSD

Ground Sampling Distance

GSE

Ground Support Equipment

HTZ

High-Traffic Zone

H/W

Hardware

IARU

International Amateur Radio Union

ICOADS

International Comprehensive Ocean-Atmosphere Data Set

IEEE

Institute of Electrical and Electronics Engineers

I/F

Interface

IF

Intermediate Frequency

IMO

International Maritime Organization

IR

Infra-Red

ISL

Inter Satellite Link

ISO

International Standards Organization

ITT

Invitation To Tender

ITU

International Telecommunication Union

LEOP

Launch and Early Orbit Phases

ESPAIS Final Report

Acronyms and Abbreviations LEO

Low Earth Orbit

LNA

Low Noise Amplifier

LOS

Line of Sight

LRIT

Long Range Identification and Tracking

MDR

Mission Design Review

MGSE

Mechanical Ground Support Equipment

MoU

Memorandum of Understanding

MTF

Modulation Transfer Function

MUD

Multi-User Detection

MWIR

Medium Wave Infra-Red

N/A

Not Applicable

NATO

North Atlantic Treaty Organization

NETD

Noise Equivalent Temperature Difference

NPV

Net Present Value

NRT

Near Real Time

NSS

Nominal Start Slot

NTS

Nominal Transmission Slot

OBC

On-Board Computer

OBDH

On-Board Data Handling

OBP

On-Board Processing

OBS

On-Board Software

OCS

Orbit Control System

OPEX

Operational Expenses

OTS

Off-The Shelf

PA

Product Assurance

PCDU

Power Control and Distribution Unit

PDGS

Payload Data Ground Segment

PDHS

Payload Data Handling System

PDR

Preliminary Design Review

PFM

Proto Flight Model

P/L

Payload

PM

Progress Meeting

PMP

Parts, Materials and Processes

PPP

Public Private Partnership

PT

Product Tree

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 73 of 78

ESPAIS Final Report

Acronyms and Abbreviations QA

Quality Assurance

QE

Quantum Efficiency

QM

Qualification Model

QSL

Qualitification Status List

RAM

Random Access Memory

RCM

Radarsat Constellation Mission

RD

Reference Document

REV/Rev

Revision

RF

Radio Frequency

RM

Reference Model

RMP

Recognize Maritime Picture

RT

Real Time

SAR

Search and Rescue

SAR

Synthetic Aperture Radar

SCC

Satellite Control Centre

SDR

System Design Review

SDR

Software Defined Radio

SIC

Signal Interference Canceller

SNR

Signal-to-Noise Ratio

SoC

Statement of Compliance

SOLAS

International Convention for the Safety of Life at Sea

SOTDMA

Self Organized Time Division Multiple Access

SoW

Statement of Work

SRD

System Requirements Document

SRIT

Short Range Identification and Tracking

SSN

Safe Sea Net

STK

Satellite Tool Kit

S/W

Software

SWIR

Short Wave Infra-Red

TBC

to be confirmed

TBD

to be defined

TC

Telecommand

TCS

Thermal Control System

TDI

Time Delayed Integration

TDMA

Time Division Multiple Access

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 74 of 78

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 75 of 78

Acronyms and Abbreviations TIR

Thermal Infra-Red

TM

Telemetry

TMA

Three Mirror Anastigmatic

TRL

Technology Readiness Level

TT&C

Telemetry, Telecommand & Control

U/C

Up Converter

URR

User Requirements Review

UTC

Universal Time Coordinated

VHF

Very High Frequency

VNIR

Visible and Near Infra-Red

VTS

Vessel Traffic Service

WBS

Work Breakdown Structure

WPD

Work Package Description Table 9-3: Acronyms and Abbreviations List

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 76 of 78

9.4 List of Figures Figure 2-1: Process flow in requirements analysis .............................................................................................7  Figure 2-2: Use Cases selected for detection probability evaluation ...............................................................14  Figure 2-3 Depiction of high traffic zones (HTZ) for scenario 1 and 2 .............................................................15  Figure 2-4: Definition of Scenario 1 ..................................................................................................................16  Figure 2-5: Definition of Scenario 2 ..................................................................................................................16  Figure 3-1: ESPAIS system architecture ..........................................................................................................17  Figure 3-2: Data flow block diagram of AIS message ......................................................................................17  Figure 3-3: Communications architecture of the ESPAIS system ....................................................................18  Figure 3-4: Sketch of on-board processing downlink channel .........................................................................19  Figure 3-5: Sketch of hybrid downlink channel A. High data rate; B. Low data rate ........................................20  Figure 4-1: Coverage duration versus inclination .............................................................................................22  Figure 4-2: Left: Detection probability ignoring area covered by land based AIS stations. Right: Detection probability including land based AIS stations. ..........................................................................................23  Figure 4-3: Effect of increasing vessel distributions on detection probability (3 dipole antennas)...................24  Figure 4-4: 12-Satellite constellation for batch one ..........................................................................................25  Figure 4-5: Time in hours to receive updates from 80% of vessels in 2021 with dipole ..................................27  Figure 4-6: Time in hours to receive updates from 80% of vessels in 2021 with patch ...................................28  Figure 4-7: Detection probability after the initial 30 orbits ................................................................................28  Figure 4-8: Link budget for three perpendicular ideal dipoles ..........................................................................29  Figure 4-9 Sketched views of deployed 3 orthogonal dipoles ESPAIS spacecraft ..........................................29  Figure 4-10: Link budget of phased array antenna. Left: Nadir focused, Right: Quadrant focused.................30  Figure 4-11 View of deployed 4 patches ESPAIS spacecraft ..........................................................................30  Figure 4-12: Block diagram of the FPGA solution front-end chain ...................................................................31  Figure 4-13: AIS receiver (Scenario 1 - FPGA solution) ..................................................................................32  Figure 4-14: Simple illustration of asynchronous SIC ......................................................................................34  Figure 4-15: Synthesised principle of the asynchronous-SIC algorithm ..........................................................35  Figure 4-16: Synthesised principle of adapted parallel demodulator (APD) ....................................................35  Figure 4-17: Platform block diagram ................................................................................................................37  Figure 4-18: Block diagram of C-band transceiver A. On-board processing concept B. Hybrid concept ........38  Figure 4-19: Falcon 1e .....................................................................................................................................46  Figure 4-20: PSLV ............................................................................................................................................46  Figure 4-21: Vega .............................................................................................................................................46  Figure 4-22: Isometric view of ESPAIS 4 Patches accommodation on-board PSLV launcher. .......................47  Figure 5-1: Interfaces to the simulations software ...........................................................................................48  Figure 5-2: Area based and vessel count based average use-case detection probability. ..............................49  Figure 5-3: Contour lot of a global TEC map at 12:00 UTC on July 1 2005 produced by CODE ....................50  Figure 5-4: NEC-Win model of a 3 dipole antenna pattern along the x-axis ....................................................50  Figure 5-5: Plot of vessel density distribution ...................................................................................................51 

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 77 of 78

Figure 5-6: Update interval CDF of North Atlantic use case ............................................................................56  Figure 5-7: Update interval CDF of Gulf of Mexico use case ...........................................................................56  Figure 5-8: Update interval CDF of Mediterranean use case...........................................................................57  Figure 6-1: Image collection using a scanning mirror ......................................................................................58  Figure 6-2: Close-up of proposed EO payload .................................................................................................58  Figure 6-3: Deployed view of ESPAIS First Element spacecraft......................................................................61  Figure 6-4: Close-up view of EO payload accommodation in First Element spacecraft ..................................62  Figure 6-5: First Element launcher accommodation A. Single spacecraft in Falcon-1e launcher B. Two spacecraft in PSLV launcher ....................................................................................................................62  Figure 7-1: Proposed development schedule...................................................................................................64 

9.5 List of Tables Table 2-1: User requirements (needs) ...............................................................................................................8  Table 2-2: Mission requirements ......................................................................................................................12  Table 2-3 System Scenarios Overview ............................................................................................................15  Table 4-1: Required number of satellites for different use cases and different antenna/orbit options .............23  Table 4-2: System Scenarios Overview ...........................................................................................................24  Table 4-3: Initial batch to be launched in 2014, maximum revisit time of 43 minutes ......................................25  Table 4-4: Batch two of constellation, to be launched in 2021, maximum revisit time of 16 minutes .............. 26  Table 4-5: ESPAIS global detection probability assessment for initial batch, with a 2021 traffic model..........26  Table 4-6: Performance summary of available antenna design options ..........................................................27  Table 4-7 Solutions for narrow filter implementation, due to terrestrial VHF ...................................................32  Table 4-8: Firmware processing capacity (AIS Demodulation Tasks) .............................................................33  Table 4-9: Average required and generated power breakdown .......................................................................39  Table 4-10: Correlation matrix between sensor and actuator use and attitude modes. ..................................40  Table 4-11: Required resources for orbit control system design options .........................................................40  Table 4-12: Minimum and maximum temperatures of ESPAIS thermal model nodes .....................................41  Table 4-13: Breakdown of ground segment scenarios analysed .....................................................................42  Table 4-14: Payload downlink results for scenario one and two ......................................................................43  Table 4-15: Data information age for various networks, in minutes .................................................................44  Table 4-16: Satisfaction of timeliness requirement by various networks .........................................................45  Table 4-17: Network recommendations for each scenario...............................................................................45  Table 4-18: Mass compatibility assumption based on fairing mass .................................................................47  Table 5-1: Measured distribution of repetition rates for class A vessels and using vessels in the North Sea, the Mediterranean Sea and vessels leaving European waters for America from August 2008. ..............52  Table 5-2: Summary of maritime traffic characterization as of October 2008 ..................................................53  Table 5-3: Summary of detection probability values per use case...................................................................55  Table 6-1: EO payload performance parameters .............................................................................................59  Table 6-2: EO payload technical parameters ...................................................................................................59  Table 6-3: Baseline technical parameters of First Element..............................................................................60 

ESPAIS Final Report

Doc.-No.: ESPAIS-OHB-FR-01 Issue: 2 Date: 08.12.2010 Page: 78 of 78

Table 6-4: First Element detailed component consequences ..........................................................................60  Table 7-1: Reliability budget of the complete ESPAIS spacecraft is presented...............................................66  Table 8-1: System Scenarios Overview ...........................................................................................................67  Table 8-2: Summary of characteristics of baseline configurations ...................................................................68  Table 9-1: List of Applicable Documents ..........................................................................................................70  Table 9-2: List of Reference Documents ..........................................................................................................70  Table 9-3: Acronyms and Abbreviations List ....................................................................................................75