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

2

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

SESAR Deployment Manager Projects

3

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

SESAR Deployment ParametersIP67 3D Radar

4

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

Convection Probablity product calculated by AROME-PE

Based on three ensemble systems by DWD, Méteó-France and Met Office

SESAR Deployment:

2015_068_AF5 : Harmonised, Pan-European Adverse Weather Forecasts

charts provided by Météo-France

SESAR Deployment:

2015_068_AF5 : Harmonised, Pan-European Adverse Weather Forecasts

6

Weather Hazards:

• Turbulence (example shown)

• Icing

• Convection

• Winter Weather

charts provided by the Met Office

Input forecasts

Harmonised

forecast:

Services for gridded and vector data

being implemented

WAFC – World Area Forecast Centre

7

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

https://www.metoffice.gov.uk/services/transport/aviation/regulated/wafs-2022

MET SWIM activities

8

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

Gridded data - API request:https:Servername/Resolution/Parameter/BoundingBox/Levels/Timeperiod

9

• User defined API definition

• 4MB cut out from a 220MB file

• <1 second to request and retrieve

• Grib2 format

• 1 timestep, all vertical levels

Benefit:

End user can define JUST what they

want in their payload.

They can move away from having to

download everything

What has been learnt (so far)… (1)

10

• 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

What has been learnt (so far)… (2)

11

• 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

Example of using the SWIM TI Yellow Profile

12

MET provider IT must be highly available, highly resilientSWIM 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 informationSecurity 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!

More things we learnt

13

• 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?

More things we considered

14

• 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.

What types of technology are being used?

15

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

Internal ancillary considerations when developing services

16

- 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

Creation of a Service

17

Generating a specific (technical) implementation of a service - METAR

18

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.

Runningservice

Where comes a Service Definition into play?

19

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

LatestMETAR DWD

+ Technique

LatestMETAR

MO + Technique

LatestMETAR MF + Technique

…

Template

METAR

service

(Service

Definition)

refer to/use

User story – a scenario vs service candidate

20

Suitable Service

Definition found

Identify Service Candidate Definition for METAR service

Want to provide METARs for certain area of responsibility (e.g. using OGC WFS)

Add specific provider information to template

All (mandatory) fields

completed

Service Description

Published in SWIM

registry

Submit to SWIM registry

Add availableprovider information to template

Not all (mandatory) fields

completed

Service Candidate

Description

Feedback on using SWIM specifications

21

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?

Does the MET ANSP community in Europe recommend to harmonise common MET Services? – YES!

22

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

Next:Meteo France Access Point

23

CONTACT DETAILS

EIG EUMETNET European Meteorological Services' Network

www.eumetnet.eu

24

Lauren Donohue

Aviation Coordinator

+44 (0)787 6001 817

lauren.donohue@eumetnet.eu