4 Final Report - Emits - ESA

4 Final
Report
shorter. As a consequence, the Ground Segment baseline architecture takes into account both types
of missions in order to be equally suited for routine type applications and emergency type applications.
In the frame of a study for CNES, it has been envisaged that routine type applications could be served
via a “Central” PDGS, due to the fact that (1) they are less time critical than emergency applications
and (2) they require some value added processing (via service segment entities) in order to actually
satisfy the needs of end users who are not experts in the manipulation and understanding of satellite
images. This is compliant with the generic PDGS architecture model with, however, the PDGS
providing products up to Level 1b only and further processing up to the delivery of a value added
service being performed by specialised value added providers within the service segment.
For emergency applications such as disaster monitoring (fires, floods), the study for CNES privileged
an architecture model with specific decentralised user’s facilities for data reception, processing and
dissemination. The crisis headquarters would be equipped with a small reception terminal and with the
means to at least perform basic processing and dissemination towards the crisis actors on the
operations theatre. The rationale for such a decentralised model is that it will provide quicker response
times by delivering the data directly on the operations field.
The decentralised model supposes that (1) the crisis headquarters or even the mobile command posts
are equipped with all means to process data and (2) the end users can cope with a relatively basic
level of processing.
The projects currently on-going in the field of natural risks management do not foresee a direct
delivery of basic products (e.g. Level 1b, which could be provided by processing on-board the S/C) to
the end users but rather still foresee the involvement of specialised service providers in the value
adding chain. To be easily understandable by non experts, the basic products must be geo-referenced
and combined with geographical or socio-economic information, and finally be integrated into a
Geographic Information System (GIS).
All of these steps might be performed in the spirit of a Service Oriented Architecture (SOA) of the
overall GEO Oculus PDGS even in the field. However, they are basically relying on the know-how of
the service providers for executing the value adding such as Web Map Services (WMS), Web Feature
Services (WCS) or Web Processing Service (WPS). Note that these services are Web-based by
principle, such that a high-speed WAN connection is mandatory for this kind of applications.
In addition, the processing cannot be executed without input of auxiliary data such as calibration data,
orbit data and attitude data, which in turn requires specific interfaces between the “Core” Payload Data
Ground Segment and the decentralised part of the Payload Data Ground Segment.
So, the main advantage of the decentralised architecture model, which is to optimise the response
time is counterbalanced by the need for a high-speed WAN connection even in the field (which might
as well provide the products generated by the "Central" PDGS) or even the shortcomings of providing
only products of low value, possibly usable only by experts.
For more details, see [RD 10].
4.6.2 Geo-Oculus dedicated Ground Segment issues
This section addresses specific issues linked to the characteristics of the Geo-Oculus mission, i.e. the
fact that (1) the satellite orbit allows permanent contact with the ground both for TM/TC operations and
Page 4-80 Doc. No: GOC-ASG-RP-002
Issue: 2
Astrium GmbH Date: 13.05.2009