Transcript HMA Outline and Status

Heterogeneous Missions Accessibility
Context and Architecture
Pier Giorgio Marchetti
HMA Project Manager
With contribution from:
Earth Observation Programme
Ground Segment Department
ESA / ESRIN
Y. Coene Spacebel
D. Marchionni Datamat
F. Sery EADS-Astrium
[email protected]
HMA
May 2006 – Slide 1
High Level Requirements
• The GMES ground segment provides the “necessary
interfaces for requesting and accessing data from
national and Eumetsat missions forming part of
GMES”. The component publishing these interfaces is
named Data Access Integration Layer – DAIL
[GMES Advisory Council Paper]
• HMA shall permit to integrate EO products, space data
with all kinds of other data and information.
[Oxygen objective]
• Project started in mid 2005 within the ESA GMES
Preparatory Activities
• TODAY the project is executed within the
ESA GMES Programme Phase-1 Segment-1
HMA
May 2006 – Slide 2
HMA - High level objectives
• Consolidate scenarios and interoperability requirements
• Define the EO DAIL architecture
• Define and prototype an interoperable protocol for catalogue,
order, mission planning,…
• Define approach for User Management
• Define approach for online data access
• Address interoperability requirements arising from:
 data quality and formats
 data policy, SLA, etc.
 security
HMA
May 2006 – Slide 3
Industrial Consortium
Prime
EADS Astrium Ltd
Leading the Requirements
phase activities
Spacebel
Datamat
• Leading the Prototyping
activities
• In charge of the
Catalogue ICD preparation
• In charge of the
Standardisation activities
• Contributions to the
Requirements phase
activities (User
Management, Processing)
• Contributions to the
Architecture activities
• Leading the Architecture
activities
• Leading the trade-off
analyses phase
• In charge of the Ordering,
Mission Planning and
ODA ICD’s preparation
• Contribution to
Prototyping activities
• Contributions to the
Requirements phase
activities
Spot Image
• Main contributor to the
Requirements phase on
the subjects of Mission
Planning and Ordering
• Assessment of OGC
SWE standards for HMA
SciSys
Siemens
• Leading the collection of
data needs & operational
requirements from GSE
and EC IP projects
• Leading the Capacity
Planning activities
• Leading the Data Supply
Agreements activity
• Main contributor to the
Requirements phase on
the subjects of Online Data
Access and User
Management
• Leading the definition of
the User Management
concept for HMA
HMA
EADS Astrium SAS
• Leading the definition of
the Security concept for
HMA
May 2006 – Slide 4
ESA Project team
ESA Project Team
Pier Giorgio Marchetti
Technical Officer
HMA Project Manager
Andrea Simonini
Product Assurance
Jolyon Martin
Standardisation
Prototype
Sergio Benetti
Contract Officer
Annette Tauber
Project Controller
Ludwig Moeller
Scenario, Requirements
Sergio Vazzana
Mission Planning
HMA
Pierre Potin
Capacity, Agreements, Security
May 2006 – Slide 5
Partners and GMES contributing missions
Partner
Mission
ASI / Alenia Spazio
Cosmo-Skymed
CNES
Pleiades, Spot
CSA / MDA
Radarsat 2
DLR
Terrasar
EUMETSAT
Meteo Missions
EUSC
User
ESA
ERS, ENVISAT,
Sentinels
HMA
May 2006 – Slide 6
Missions interoperation

Independent missions do not provide any access nor
management of any resources to another mission.

Federated missions share access to GS resources, typically
catalogue functions.

Cooperative missions allow other missions to place orders, i.e. to
access to their space resources.

Collaborating (or loosely coupled) missions may delegate mission
planning functions to a partner, e.g. for optimum scheduling of
observations over exclusive right zones.

Integrated (or tightly coupled) missions are the highest level of
interoperation, typically conceived as a single system
HMA
May 2006 – Slide 7
Multiple Missions
Management
of Space
Resources
Management of
Ground Segment
Resorces
Access to
Space
Resources
Access to GS
Resources
Example(s)
Comments Common or
joint
Quick Bird,
Radarsat-1
No catalogue
X
Spot
Catalogue yes,
order no
X
X
Landsat,
Spot
(planned)
ENVISAT,
ERS
Catalogue yes
, Order yes
X
X
X
ALOS,
COSMO –
Pleiades
CosmoSAOCOM
Catalogue,
order, some
mission
planning
Independent
Federated
Cooperative
Loosely coupled
-Collaborating
Tightly Coupled Integrated
X
X
X
X
CosmoBISSAT
Delegation of
ROI and Time
Integrated
X
X
X
X
Tandem-X
Orbit control
Mission classification based on resource access and management
HMA
May 2006 – Slide 8
Related projects and activities

External Requirements and Interfaces
• ESA studies (sentinels, service architecture, …)
• GSE projects
• EC GMES Integrated Projects (e.g. ORCHESTRA, WIN OASIS,
GEOLAND, …)
• INSPIRE
• EUMETSAT
HMA
May 2006 – Slide 9
Related projects and activities
• GSE projects
 Collocation in December 2005
• EC GMES Integrated Projects (e.g. ORCHESTRA,
WIN OASIS, GEOLAND, …)
 Architecture WG established with ORCHESTRA, WIN OASIS
• INSPIRE
 Coordinated approach set-up, work-plan on catalogue issues
established
• EUMETSAT
 Technical co-ordination under definition
• UN-SDI
 Technical co-ordination under definition
HMA
May 2006 – Slide 10
GMES HMA Architecture –
Methodology – RM-ODP Model

The approach to describe the architecture follows the RM-ODP model
(Reference Model of Open Distributed Processing (ISO/IEC 107461:1998)).

RM-ODP model analyses the systems through 5 different views:
• The enterprise viewpoint: A viewpoint on the system and its
environment that focuses on the purpose, scope and policies for the
system.
• The information viewpoint: A viewpoint on the system and its
environment that focuses on the semantics of the information and
information processing performed.
• The computational viewpoint: A viewpoint on the system and its
environment that enables distribution through functional decomposition of
the system into objects which interact at interfaces.
• The engineering viewpoint: A viewpoint on the system and its
environment that focuses on the mechanisms and functions required to
support distributed interaction between objects in the system.
• The technology viewpoint: A viewpoint on the system and its
environment that focuses on the choice of technology in that system.
HMA
May 2006 – Slide 11
GMES HMA Architecture –
Methodology – Tayloring of RM-ODP

The RM-ODP approach focuses on distributed processing systems,
while the GMES HMA is a loosely coupled network of services
 Need for tayloring, as for ORCHESTRA project.

The HMA definition of is:
• The enterprise viewpoint: same as RM-ODP.
• The information viewpoint: Specifies the modelling of all categories of
information the GMES HMA Architecture deals with including their
thematic, spatial, temporal characteristics as well as their meta-data.
• The service viewpoint: This is the view that correspond to the
computation view point. It specifies the GMES HMA services that support
the syntactical and semantic interoperability between GSs, clients, EO
DAIL.
• The engineering viewpoint: Specifies the mapping of the GMES HMA
service specifications and information models to the chosen service and
information infrastructure.
• The technology viewpoint: Specifies the technological choices of the
service infrastructure and the operational issues of the infrastructure.
HMA
May 2006 – Slide 12
GMES HMA Architecture –
Methodology
 Design driven also by the “Simple Service Architecture” concept defined in the
OpenGIS Service Architecture, section 7.6:
•
•
•
•
•
Message-operations. The HMA Services operations will be modelled as messages. A
message operation shall consist of a request and response. Requests and responses contain
parameters as the payload, which is transferred in uniform manner independent of content.
Separation of control and data. A client accessing a HMA service may not want the full
results of the service. A client should have the option of receiving just the status of an operation
and separately the data should be accessible through a separate operation.
Synchronous versus Asynchronous Service
Depending on the expected response time services will be defined either synchronous (i.e.
service response is real time -e.g. catalogue service) or asynchronous ( e.g. order)
Known service type. All service instances are of specific service types and the client knows
the type prior to runtime. This hypothesis makes the interaction between the different HMA
elements (clients, EO DAIL, Ground Segments) simpler because it is avoided the completely
dynamic discovery and invocation of service operations.
Adequate hardware. HMA services are software implementations running on hardware hosts.
This assumption means that the hardware assignment is transparent to user.
HMA
May 2006 – Slide 13
GMES HMA Architecture –
Enterprise View - Context
SCI
Science
COM
COMMERCIAL
GMES
Service Access Layer
Integration
EO Data Access integration layer
INSPIRE
Non European
ESA
Other European
Other European
Mission
MM
Mission
Mission
Ground Segment
Ground Segment
Ground Segment
Ground Segment
HMA
Meteorological
Static
in
Mission
Geo-spatial
situ
May 2006 – Slide 14
GMES HMA Architecture –
Enterprise View – Distributed Architecture
HMA
May 2006 – Slide 15
GMES HMA Architecture –
Enterprise View – High level requirements

HL_GEN_505: The overall HMA architecture, including the DAIL one,
shall be driven to minimise the cost and impact on partners’ ground
segments.

HL_GEN_506: The DAIL architecture shall be independent of a
particular partner’s ground segment.

HL_GEN_507: The HMA architecture shall permit integration and
reuse by additional partners in the future.

HL_GEN_509: It shall be possible to add missions without changing
the HMA architecture.

HL_GEN_510: The HMA shall permit the support of INSPIRE
implementing rules.
HMA
May 2006 – Slide 16
GMES HMA Architecture –
Enterprise View – High level requirements

HL_GEN_511: The HMA architecture shall allow the use of partners’
proprietary GUI clients that are compliant to HMA interface
specifications for the user access to HMA provided functionality/
services.

HL_GEN_512: The HMA shall allow the traceability of all transactions
which are handled through the DAIL.

HL_GEN_513: The HMA architecture shall permit the partner to
choose whether the user registration and the management of user
privileges and or policies are managed either on the DAIL or at the
partners’ ground segment or both.

HL_GEN_500: The Access to the services from the missions
participating in GMES will be ruled by Data Access Agreements to be
signed between ESA and the mission owner.

HL_GEN_501: The Data Access Agreements will define the Service
Level Agreements to be supported for the specific mission/data
access.
HMA
May 2006 – Slide 17
GMES HMA Architecture –
Information View
 HMA will
manage the following information:
• Service metadata - Service Discovery.
• User Identity - User Management
• Transaction Tracking data - Monitoring & Control
service
HMA
May 2006 – Slide 18
GMES HMA Architecture –
Information View
 Transaction Tracking data model - Monitoring & Control
service
HMA
May 2006 – Slide 19
GMES HMA Architecture –
Information view – Namespaces
Catalogue metadata specific
to EO space mission type
sar.xsd
ohr.xsd
Catalogue metadata specific
to EO space missions
atm.xsd
hma.xsd
smXML - gmd
(ISO 19139)
Generic catalogue
metadata
gml
Namespaces for
radar missions
Namespaces for
optical missions
HMA
Namespaces for
atmospheric missions
May 2006 – Slide 20
GMES HMA Architecture –
Service view (Work in Progress)
 HM
and GS services:
• Discovery
• Catalogue
• Mission Planning
• Ordering
• Data Access Request
• Monitoring & Control
• User Management
HMA
May 2006 – Slide 21
GMES HMA Architecture –
Service view (Work in Progress)
 Relationships
between
HMA services and GS
Services
HMA
May 2006 – Slide 22
GMES HMA Architecture –
Technology view
• Pull IT standards (W3C/OASIS) e.g.
XML/SOAP/WSDL.
• Push EO specific profile within OGC
• Propose adoption within the INSPIRE Implementing
Rules
• ISO adoption / standardisation of specifications - long
term goal
HMA
May 2006 – Slide 23
GMES HMA Architecture –
Technology view
Selected technologies & protocols:
• Service Oriented Architecture (SOA)
 XML Schema
 Message-based SOAP (Simple Object Access Protocol) over HTTP or HTTPS
for secure communication
 WSDL (Web Services Description Language)
 Business Process Execution Language (BPEL)
 UDDI service registry
 Ws-addressing
• Security/Identity management




Security Assertion Markup Language (SAML)
Lightweight Directory Access Protocol (LDAP)
WS-Security
WS-Policy
• Inspire
 Open Geospatial Consortium GML,WMS, WFS,WCS
 OGC CSW2.0 Application Profile ISO19115/19119
HMA
May 2006 – Slide 24
GMES HMA Architecture –
Engineering view
 HMA Services
allocation (EO DAIL vs GS) criteria:
• When the responsibility for follow-on actions is with the GS Owner,
then the service shall be provided by the GS owner
• The splitting of complex service request, the combination of
results, the tracking of the transaction is allocated to EO DAIL;
• Complex coordination functions are allocated to ESA MM Ground
Segment (either current or future);
• If support needed by GS Owner (station, processing, etc.) then the
service shall be provided by the ESA MM GS
• The level of performance and/or reliability provided by the different
components (e.g. EO DAIL, GS Owner, ESA MM GS) may be
used as criterion to allocate service execution responsibility.
HMA
May 2006 – Slide 25
GMES HMA Architecture –
Engineering view (Work in Progress)
HMA
May 2006 – Slide 26
GMES HMA Architecture –
Engineering view – DAIL Architecture
HMA
May 2006 – Slide 27
Identity Mgt- Engineering view
EODAIL
Mission GSk
Users
(local) Policy
store
Policy
Management
DAIL Server
Client
Identity Server
Policy Enforcement
Pointk
Federation Server
Identity Server
LDAP User
Directory Service
ws-security
ws-addressing
SOAP
HTTP
LDAP User
Directory Service
WS - order
Existing GSk
systems
WS - catalogue
HMA
May 2006 – Slide 28
GMES HMA Architecture –
Engineering view – DAIL Architecture

HTTP Server: listen to incoming SOAP over HTTP calls.

Servlet Engine: hosts the execution of Servlets

SOAP Engine: de-seriale the SOAP request message in a structured
java class and serialize the answer in a properly formatted SOAP
message.

Application Layer: contains ad-hoc software implementing the EO
DAIL services

RDBMS: database management system needed to store the data
supporting the Application Layer.

Workflow Engine: in charge of executing predefined workflows upon
triggering from the Application Layer.

LDAP: in charge of storing the user identity information
HMA
May 2006 – Slide 29
Planning 2006-2007

HMA SRR 2 March 2006

HMA Standards Workshop 2728 April 2006


•
•
HMA CDR 5-6 September 2006

HMA AR 28-29 November 2006

HMA FP 27-28 February 2007
HMA
6-9 March 2006
26-29 June 2006

CEOS WGISS Architecture info
11 May 2006

GI Workshop 21 June 2006
HMA PDR 6-7 June 2006

OGC Meetings
May 2006 – Slide 30
HMA prototype
Based on ESA Service Support Environment infratstructure:
• http://services.eoportal.org
• [email protected]
• [email protected]
HMA
May 2006 – Slide 31