Versions Compared

Version Old Version 3 New Version 4
Changes made by

Xiaoxia Chen

Timo Proescholdt

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • High-level architecture of WIS2.0 monitoring

Summary

The teams met to review the high-level requirements and discuss the high-level architecture of the WIS monitoring prototype with a view of implementing a GBON and WIS 2.0 monitoring. The teams agreed that the overall architecture will consist of a several sensor centers providing monitoring information to a central monitoring component. An “active” approach, whereby the sensor centers process data and extract the metadata needed for the monitoring should be taken. The team also discussed the extent to which WIS 2.0 principles could be used in the design. A PubSub approach would in principle allow to send monitoring data in real-time to the central component instead of a periodic transfer of aggregate information. However, the functional requirements do not require real-time access and the teams tentatively felt that a periodic file transfer, perhaps supported by a broker would result in an operationally more stable solution. The teams agreed to meeting again in 2-3 weeks time to again discuss the issue of data-transfer as well as more detailed requirements.

Discussion topics

No

Item

Presenter

Notes

1

Opening

Timo

Timo:Data Policy, GBON were approved. To build the pilot project for WIS2.0 monitoring.

Timeline for monitoring GBON implementation was set in the summer.

Objective tool: look at data at different points, not to be linked to NWPC

Cristina: What is the idea behind GBON?

Enrico: 1) GBON was approved in Cg-2021; 2) to build a team for GBON implementation; 3) not clear for the stations selection creteria; 4) Monitoring of both WDQMS and WIS, the objective this joint team

2

High-level architecture

Presentation

Timo

Presentation is here. The goal is to leverage the principles for monitoring.

View file
nameJoint TT-WIS Mon TT-WDQMS meeting -Timo-20220121.pptx

Questions to be discussed:

  1. Exchange format

  2. Link between distributed sensor-centers and central storage/reporting component

3

Discussion

ALL

Kai

  • Shares the presentation of WIS2.0 Monitoring Procedures.

    • Sensor Centers (requirements, procedure,)

    • Monitoring Centers

View file
nameWIS 2.0 Monitoring Procedures-Kai-20220121.pdf

Enrico

  • It is a good starting point.

  • to provide the software to the centers (opensource)

  • GTS: multiple stations in one message

  • WIS2.0: to avoid having collective messages

  • Complexity of monitoring lies in decoding part (many BUFR templates), for example, 5+ templates for SYNOP

Timo: we need pragmatic ways

  • broker: sensor centers to have one broker each or a cloud based broker

  • 2 or 3 sensor centers (to standardize the message format)

Jeff

  • US: support this proposal, not for GISC Washington

Enrico

  • to make a decision about the proposal today

  • to reach TT-GISC for their contribution

  • a strategy of data sent in real time

Kai:

  • preference: active

  • WIS2

Cristina

  • preference: active (if software provided)

Cristiano

  • preference: active

  • guidance needed for sub-pub in real-time

  • process for WIS pilot project

    • Timo: ECMWF and WMO MoU for software development, and it is also a member driven process

    • Enrico: to think 5 sensor centers generating traffic, a real-time data, monitoring near-real-time is acceptable; some tests are needed

    • Kai: amount and frequency of reports: no impact on technical implementation; message received, reports to be grouped on an hourly basis and sent out

    • Enrico: MQP, group the report of messages.

    • Timo: to discuss the configuration variable of aggregation rules at the next meeting

    • JMA would be also a sensor center.

    • Hassane: 1) real time is more useful at the local level not the global level; 2) determinator: compare what we receive and what it is expected to receive; 3) component in WIS2node

...