MET SWIM Services: Enhanced weather information and how to access in the future - Lauren Donohue - EUMETNET Aviation Coordinator EUROCONTROL SWIM ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
MET SWIM Services:
Enhanced weather information and how
to access in the future
Lauren Donohue – EUMETNET Aviation Coordinator
EUROCONTROL SWIM Implementation Workshop December 2019
MET Air Navigation Service Providers Who are the designated MET providers of in Europe? Designated activities driven by: ICAO Annex 3 (and EU 2017/373, Pilot Common Project (PCP/CP1). SWIM data provision is on the ‘radar’ but variable levels of activity across the MET community 2
SESAR Deployment Manager Projects EUMETNET with project partners are involved in three projects • 2015_067_AF5 – 3D Weather Radar • 2015_068_AF5 – Adverse Weather Hazards • 2015_069_AF5 – MET-GATE: service delivery New and novel pan-European Weather products aimed at delivering consistent information for all aviation actors to assist planning and tactical decision making 3
SESAR Deployment Parameters
IP67 3D Radar
Production of Cross Border
Weather products to assist in
common situational awareness
Data services through the MET
provider producing forecasts and
observations
Use of OGC Web Feature Service
(WFS), Web Coverage Service
Thanks to Meteo France
4
SESAR Deployment:
2015_068_AF5 : Harmonised, Pan-European Adverse Weather Forecasts
Convection Probablity product calculated by AROME-PE
Based on three ensemble systems by DWD, Méteó-France and Met Office
charts provided by Météo-France
SESAR Deployment:
2015_068_AF5 : Harmonised, Pan-European Adverse Weather Forecasts
Input forecasts
Weather Hazards:
• Turbulence
(example shown)
• Icing
• Convection
• Winter Weather
Harmonised
forecast:
Services for gridded and vector data
being implemented
charts provided by the Met Office
6
WAFC – World Area Forecast Centre
Global data set which is going through a transformation via ICAO
More information: more time steps, horizontal and vertical grid
resolution increases = 200 times the volume!
FTP -> API
From ‘everything’ to cut outs of what the consumers requires
7 https://www.metoffice.gov.uk/services/transport/aviation/regulated/wafs-2022
MET SWIM activities WAFC • November 2020 for OPMET as IWXXM, November 2022 for SigWx and Gridded data • Undergoing requirements gathering on how to get the most from an API query • Move to API and away from FTP over next 10 years • Design API’s to ensure they are user friendly, the WAFC’s consumers have to change their processes at the same time EUMETNET MET providers • Météo France – Access Point (presentation by Météo France) • DWD – Access Point, Yellow Profile conform, test user wanted starting 1st quarter 2020 • Met Office – Yellow Profile Access point via API 8
Gridded data - API request: https:Servername/Resolution/Parameter/BoundingBox/Levels/Timeperiod • User defined API definition • 4MB cut out from a 220MB file •
What has been learnt (so far)… (1)
• Importance of a basic understanding of what API’s are and how they work
• Go online: live feed API service (NOMAAD), BI Tool/web page or GRIB2
viewer, play with API settings, view changes, Firewalls
• Access the wealth of SWIM knowledge and tools freely available (ECTRL,
SSCONE, AIM, etc) proven valuable to identify information
• Technical understanding of SWIM Yellow Profile – not being bound on
only one specific format, e.g. WS-Light (WFS, WCS, REST Services) or the
Service Description
• The different SWIM registries (ECTRL, FAA) raise queries in our
community about how finding the information and how that could be
managed to ensure consumers access the most appropriate services
10What has been learnt (so far)… (2)
• The use of Service Definitions as templates simplifies the creation of
Service Descriptions and can be used for other new services
• Find common ground for Service Definitions
• Possibility to set a frame regarding "best practices" and quality aspects
• Although there are three ECTRL SWIM Specifications there is still a
wide range of things to consider:
• Where is it useful to align: which parts are appropriate?
• How much alignment is needed to provide (good) guidance and
not being too restrictive?
• Who will be responsible for those Service Definitions and the
monitoring?
• More Service Examples would be helpful to share experience on how to
build a Service Description and how to publish Service in SWIM Registry
11Example of using the SWIM TI Yellow Profile
MET provider IT must be highly available, highly resilient
SWIM TI YP pushes forward, there are different delivery methods than
MET providers are used to (like SFTP)
Large datasets can be tricky, because there may be size restrictions, e.g.
AMQP: OPMET-IWXXM OK, but gridded data (GRIB2) not intuitively, users
may also have to implement new technologies/methods for retrieving
information
Security standards of TI YP tend to be for the minimum
• Contacted EUROCONTROL SWIM team querying the Security
recommendations and recommending ‘OAUTH’
• Draft proposal to update the standard currently under review
If there is a lack of clarity or ambiguity in the standards,
ask about it as if it affects you, it may affect others!
12More things we learnt
• Format of payload is not mandated by SWIM
• MET Data: Grids (GRIB2, netCDF/HDF5…), vector objects, alerts
(thresholds)
• SLA of service is not mandated by SWIM
• New services are evolving, what will the consumer make with them?
• Missing parts in the mapping between IWXXM and AIRM. DWD
described missing parts and filled a change request (work is ongoing).
this is related to the SWIM Information Definition, not the TI YP
• Uncertainty slows down rapid deployment. When can I officially use the
registry? Will there be validation tools for the Service Descriptions? In
which format should the Service Descriptions be delivered – specification
does not specify a format, XML/XSD are present, but in between JSON
was also under discussion?
13More things we considered
• SWIM candidate services are a good way to attract feedback on a potential
service and highlight similarities and SLA’s. First candidate services will be
available in SWIM registry soon (if XML based). Test users wanted!
• The more SWIM services that are exposed the easier it will be to develop new
services
• Very true in MET community: regulated (METAR/TAF/WAFC), pan-
European
• Cloud service providers: Which to choose?
• Amazon: proprietary messaging protocol (SQS) in use, AMQP V1.0 to be set
up individually – heightened risk compared to Microsoft, no certified
hardware to run on premise of MET provider
• Microsoft: native AMQP V1.0 broker service in portfolio – directly yellow
profile conform, certified hardware to run cloud on premise of MET
provider. The one to choose?
• How about the others? Oracle, Google? There are a lot of details to
consider before choosing a cloud provider.
14What types of technology are being used? Met Office – Cloud/Amazon Web Services Meteo France – Open Source Access Point DWD – Feature Upgrade Internal Structure/Applications, Open Source Other MET ANSPs are following internal and external aaproaches 15
Internal ancillary considerations when developing services
- Authentication & Authorisation & Legal constraints/GDPR & Security
- Updating SWIM registry following customer feedback (staff roles)
- Communications to stakeholders, internal and external
- Service Level Agreement – uptime, resilience, speed of payload
generation, Scope of use, change and passing on by the customer.
- ‘Internal’ Governance and life cycling of SWIM MET services need to be
further considered.
- Aviation terminology vs MET terminology
- Logging & Monitoring
- Know your data formats
- Cost recovery
- API: user defined vs. pre-defined services and design
16Creation of a Service 17
Generating a specific (technical) implementation of a service - METAR
Service Instance:
The service deployed into a running ICT system.
Running service
Service Description:
The information needed in order to use, or consider using, a service.
Running
service
18Where comes a Service Definition into play?
When SWIM service providers decide to to align their services in terms
of what they exchange and in terms of how they are built, they need to
agree on a SWIM Service Definition to document the similarities of the
services (from SWIM Governance)
METAR
Template
METAR
Latest Latest service
METAR Latest
METAR METAR MF …
DWD MO + (Service
+ Technique
+ Technique Technique Definition)
refer to/use
19User story – a scenario vs service candidate
Identify Service Candidate Definition
for METAR service Suitable Service
Definition found
Want to provide METARs for Add
Add specific
available
certain area of responsibility (e.g. provider
provider
using OGC WFS) information
information to
to
template
template
Submit to SWIM registry Not all (mandatory) fields
All (mandatory) fields
Published in SWIM completed
completed
registry Service Candidate
Service Description
Description
20Feedback on using SWIM specifications Aspects that seem ‘old fashioned’ SOAP vs REST, but allows flexibility to build SWIM in different ways Requesting changes and additions possible – be proactive in engaging with the community What were the reasons behind the restrictive AMQP V1.0? New technologies can provide good opportunities, but a new standard causes extra investments and can be challenging during implementation Definition “How to upload (candidate) Service Descriptions”. When will this be published? 21
Does the MET ANSP community in Europe recommend to harmonise common MET Services? – YES! Which MET Services should be harmonised? • OPMET, Gridded data, WindsAloft, Significant Wx,…? How much should be harmonised? • Level of harmonisation: describing part, technical aspects How to develop common Service Definitions? • How do we ensure agrement • MET Working groups, AVIMET, coordination with WMO/ICAO 22
Next:
Meteo France Access Point
23CONTACT DETAILS Lauren Donohue Aviation Coordinator EIG EUMETNET European Meteorological Services' Network www.eumetnet.eu +44 (0)787 6001 817 lauren.donohue@eumetnet.eu 24
You can also read
