Skip to content

workshop 1

Jump to bottom
BL Choy edited this page Mar 4, 2021 · 34 revisions

Workshop 1

I. Introduction

This is the first of a series of workshops to explore what and how meteorological (MET) information and services are being provided in the SWIM environment (MET on SWIM). In this workshop, things (responsible entities, infrastructure, hardware and software, specifications, technologies, methodologies, procedures, etc.) which we believe are important for MET on SWIM are identified and discussed.

CAVEAT: Information provided on this wiki page is for the sake of debate and the reader shall not take this as the official understanding, opinion and/or decision of any person or organisation with regard to the actual implementation of MET on SWIM.

II. The MET on SWIM setting

In this workshop we would like to explore what is the overall setting for an institution to set up and provide MET information and services over SWIM.

I would like to first look into some of the available documents. The Manual on System Wide Information Management (SWIM) Concept (ICAO Doc.10039) defines SWIM Enterprise and SWIM Region as below:

  • SWIM Enterprise. A SWIM enterprise can be an ATM service provider (ASP), a group of ASPs, or an Airspace User, or an ATM support industry that has full control of the implementation planning and execution within the enterprise.

  • SWIM Region. A collection of SWIM enterprises that have agreed upon common regional governance and internal standards. A region will be delineated by the area of influence of a given governance structure that defines the standards, policies, etc. that are applicable to all the participants within the region.

Section 5.3 - Interconnecting SWIM Services Across ASP/Regional Boundaries further indicated that "local SWIM enterprises are most likely to connect, by necessity, to similar enterprises through a series of bilateral agreements to achieve interoperability... there needs to be a means for the global provision and connection of services across SWIM enterprises."

The final draft of ICAO PANS-IM agreed by IMP/WG9 on 24 Oct 2019 points out that semantic interoperability, syntactic interoperability and metadata are essential for maintaining a common understanding of the meaning of the information in an information service payload. In SWIM, semantic interoperability is achieved by aligning the meaning of the information exchanged with the Air Traffic Management Information Reference Model (AIRM); syntactic interoperability is achieved by establishing agreements in relation to data encoding; and metadata should be used to describe both the information service payload and the information service that delivers it.

As described in the final draft, an information service provider shall make available information service metadata through information service overviews for information service consumers to assess the fitness for purpose of an information service. An information service overview shall be structured using standardized metadata fields which should facilitate discoverability of information services and enables information service consumers to compare between different information services. The following are some metadata fields in an information service overview:

  • Service Name;
  • Service Version;
  • Provider Organization;
  • Provider Point of Contact;
  • Brief Description of the Service;
  • Lifecycle Information;
  • Geographical Extent of Information;
  • Quality of Service;
  • Access Restrictions;
  • Message Exchange Pattern;
  • Information Exchange Model;
  • Service Validation;
  • Additional Service Information;
  • Service Functions;
  • Filtering Available;
  • Source of Information; and
  • Support Availability.

To start the debate I would like to bring up the famous relationship diagram being promoted for SWIM (Diagram 1):

From a consumer's perspective, they may be seeing the following with instances of classes (or objects) from the above diagram (Diagram 2):

The following diagram with existing/known entities in black borders/lines together with entities which I think is essential for a complete set up in pink borders/lines (Diagram 3):

III. The debate

1. The role of national centres and regional centres / brokers with B2C information exchange methods like MQ and Web Services

Choy's argument

Under ICAO Annex 3, the MET Service Provider (MSP) appointed by the MET Authority (MA) has roughly two roles: (i) Make local observations, forecasts and warnings and distribute them to local stakeholders and MSPs abroad, (ii) collect observations, forecasts and warnings from MSPs abroad and distribute them to local stakeholders. These together with AFS and ROCs' + RODBs' "store and forward" exchange mechanism established an effective 2-layer approach - redistributing messages within the MET community (B2B) before they are served to aviation stakeholders (B2C). In the SWIM environment any MSP can provide its local information directly to local and remote aviation stakeholders through the B2C information services. However, it is not user friendly (see the Smart Consuming Application in Diagram 2) and the varying network distances between a user and the MSPs may make the service level (e.g latency) highly uncertain.

Do we want to continue to have the 2-layer approach? Or we want to have one or more regional brokers to serve all aviation stakeholders within the region? How to provide global service if different regions choose different approaches?

A wild idea to preserve the 2-layer approach with existing technologies is shown in the diagram below. Note that this only supports the passing of prepackaged collectives and subsequent request/reply with query. To access higher fidelity local MET reports one still needs to directly access the MET Service Provider's interfaces:

Having said that, the 2-layer approach is more appropriate to the exchange of "baseline information" like those mentioned in Annex 3. To support the retrieval/distribution of high (spatial and temporal) fidelity data, the latency/timeliness and bandwidth requirements could impose tremendous pressure to the B2B layer. In this scenario, direct (or through proxy if also act as a broker) B2C could be a solution.

[Update] A recent discussion with our French experts indicated that MQ may not be a suitable mean for distribution of different sets of MET information to different users; a large number of MQs may needed to be set up. In the worst case if all 10 users need different combinations of MET information, one may need to setup 10 separate MQs to meet their requirement! It appears that AMHS which allows one to specify recipients still has its value in active MET information distribution.

2. What is the need of our end-users? Information or information service?

Choy's argument

Up to this moment we usually describe the MET information we provide in terms of the name of the report it belongs (e.g. METAR) as ICAO Annex 3 provides a comprehensive specifications of these MET elements in the associated TAC templates. Even with the information service overview described in the draft PANS-IM, it will be easy to do a reverse search to find which information service has a payload of METAR for example. Looking forward when TAC has retired (and so must be the associated TAC templates) and the provision of MET parameters becomes popular, it will be more difficult to dig out the information services one needs without using a common set of metadata to describe the information payload. There may also be a need to store the description by MSPs and relevant infrastructure may be required (see those items in red borders in Diagram 3).

Shall we align the MET information being provided among MSPs or the MET information service? How can we align information services if we allow MSPs to provide direct B2C services to local and remote aviation stakeholders?

3. Should MET information be exchanged solely on the IP network serving AFS or be extended to include Internet under the SWIM context?

Choy's argument

There is no doubt that the AFS has been designed to be a highly available and safe medium for exchange of aviation information. It possess characteristics of an Intranet (accessible by (limited) members of the aviation community, isolated communication infrastructure, safe (and hence less effort in protecting transactions), carefully planned traffic capacity, functionality and quality of service, etc.). Some MET related data (OPMET) has the luxury of being exchanged over AFS, but the majority of MET information supporting operation of the aviation community is being exchanged through other medium like private network, satellite and Internet (e.g. WAFCs products). There is currently no indication how we should deal with this multi-medium exchange in SWIM. The famous diagram of the SWIM layers:

does not give any clues to the bottom-most two layers whether they should be a single medium, multiple but isolated mediums or multiple and connected mediums. Each of these types have different challenges (e.g. high price for an isolated medium supporting high traffic, complexity of multiple but isolated mediums and security issues for multiple and connected mediums). In any case, it appears that non-MET members of the aviation community are not aware of the high traffic currently involved in exchanges outside the AFS. This will definitely make the option for having a single medium for the transport layer more difficult to achieve.

Clone this wiki locally