Amendments for INFCOM-4

guide/index.adoc

@@ -1,7 +1,7 @@
-:title: Guide to the WMO Information System (WMO-No. 1061), Volume II - WMO Information System 2.0 (APPROVED)
+:title: Guide to the WMO Information System (WMO-No. 1061), Volume II - WMO Information System 2.0 (DRAFT-INFCOM-4)
 :titletext: {title}
-:version: 1.3.0
-:date: 2026-06-15
+:version: 1.4.0-draft
+:date: {docdate}
 :copyright: Copyright © 2026 World Meteorological Organization (WMO)
 :doctype: book
 :encoding: utf-8
@@ -17,11 +17,11 @@
 |===
 |{set:cellbgcolor:#FFFFFF}
 |[big]*World Meteorological Organization*
-|Date: 2026-06-15
+|Date: {docdate}
 |Version: {version}
-|Document status: APPROVED
+|Document status: DRAFT-INFCOM-4
 |Revision history: see <<_revision_history,Annex A>>
-|Document location: https://wmo-im.github.io/wis2-guide/guide/wis2-guide-APPROVED.html
+|Document location: https://wmo-im.github.io/wis2-guide/guide/infcom/guide/wis2-guide-DRAFT-INFCOM-4.html
 |WMO publication location: https://library.wmo.int/idurl/4/69130
 |Standing Committee on Information Management and Technology (SC-IMT)footnote:[https://community.wmo.int/governance/commission-membership/commission-observation-infrastructures-and-information-systems-infcom/commission-infrastructure-officers/infcom-management-group/standing-committee-information-management-and-technology-sc-imt]
 |Commission for Observation, Infrastructure and Information Systems (INFCOM)footnote:[https://community.wmo.int/governance/commission-membership/infcom]
@@ -43,8 +43,13 @@ include::sections/part4/index.adoc[]
 
 include::sections/part5/index.adoc[]
 
-include::sections/annex_a.adoc[]
+include::sections/part6/index.adoc[]
+
+include::sections/appendix_a.adoc[]
 
+include::sections/appendix_b.adoc[]
+
+include::sections/annex_a.adoc[]
 
 
 // include::sections/other-considerations.adoc[]

guide/sections/annex_a.adoc

@@ -9,4 +9,5 @@
 |November 2024 | 1.1.0 | SC-IMT |https://github.com/wmo-im/wis2-guide/milestone/3?closed=1[See GitHub]| Fast-track 2024-2
 |February 2026 | 1.2.0 | SC-IMT |https://github.com/wmo-im/wis2-guide/milestone/7?closed=1[See GitHub] |Fast-track 2025-2
 |June 2026 | 1.3.0 | SC-IMT |https://github.com/wmo-im/wis2-guide/milestone/4?closed=1[See GitHub] |Fast-track 2026-1
+|August 2026 | 1.4.0-DRAFT | SC-IMT | |INFCOM-4
 |===

guide/sections/appendix_a.adoc

@@ -0,0 +1,94 @@
+[appendix]
+:appendix-caption: Annex
+
+== APPENDIX A: PER-COMPONENT OPERATIONAL CRITERIA 
+
+This appendix contains additional information to section 2.7.2.9. The operational criteria specific for each category of designated Global Services are set out below. Criteria for other types of Global Service will be added in subsequent revisions of this Guide.
+
+=== A.1 Global Broker
+
+The operational status of a Global Broker is assessed against two KPIs, both measured through Sensor Centre Global Broker (SCGB) instances operating in different parts of the globe, so as to reduce the influence of localized network conditions or of any individual Sensor Centre. Hourly KPI evaluation is based on the best result across all SCGB instances; KPIs are calculated at the Global Monitor, not at the Sensor Centre itself.
+
+==== A.1.1 Message completeness KPI
+
+This KPI measures the percentage of WIS2 Notification Messages (WNM) published by the Global Broker, within a defined cut-off time, compared against a baseline derived from all Global Brokers.
+
+*Measure (calculated each hour):*
+
+The percentage of WNM messages published by the Global Broker within the cut-off time of 60 seconds, compared to the baseline, is assessed using a randomized sample of approximately 10 per cent of messages. The number of messages published by each Global Broker within the cutoff time is recorded using the metric `wmo_wis2_scgb_messages_published_total`. The baseline is the highest number of messages published by any Global Broker, as recorded by any SCGB instance, within the previous hour. A message is considered "missed" if a Global Broker has not published that message within 60-seconds of it first being published by any other Global Broker.
+
+*KPI evaluation (hourly):* 
+
+The message completeness KPI is set to "pass" for the hour if the percentage of messages published is not less than 95 per cent of the baseline; otherwise it is set to "fail" for the hour.
+
+==== A.1.2 Connectivity KPI
+
+This KPI measures the proportion of the hour during which the public MQTT endpoint of the Global Broker are reachable, as determined from the connection status recorded by SCGB instances.
+
+*Measure (calculated each hour):*
+
+The proportion of time that the Global Broker’s MQTT end-point is accessible, published by the Sensor Centre Global Broker using metric `wmo_wis2_scgb_connected_flag`.
+
+*KPI evaluation (hourly):* 
+
+The connectivity KPI is set to "pass" for the hour if the `wmo_wis2_scgb_connected_flag` is set to `1` ("True", connected) for not less than 95 per cent of the time; otherwise it is set to "fail" for the hour.
+
+==== A.1.3 Combined hourly and monthly KPI
+
+* For each hour, the Global Broker is considered operational where *both* the message completeness KPI *and* the connectivity KPI are set to "pass". If either KPI fails for the hour, the Global Broker is considered non-operational for that hour.
+* Each month, the overall KPI is set to "pass" if the combined hourly KPI passes for not less than 98 per cent of hours in the month (i.e. the Global Broker may experience up to 14 "failure" hours in a calendar month and still be considered performing within the service level).
+* Hours coinciding with planned outages, or other _force majeure_ agreed by SC-IMT, are excluded from the monthly KPI calculation.
+* The monthly KPI is used in the assessment of Global Broker performance informing the determination of downtime in accordance with section 2.7.2.6.
+
+'''
+
+=== A.2 Global Cache
+
+The operational status of a Global Cache is assessed against two KPIs, both measured through Sensor Centre Global Cache (SCGC) instances operating in different parts of the globe, so as to reduce the influence of localized network conditions or of any individual Sensor Centre. Hourly KPI evaluation is based on the best result across all SCGC instances; KPIs are calculated at the Global Monitor, not at the Sensor Centre itself.
+
+==== A.2.1 Cache completeness KPI
+
+This KPI measures the percentage of data items published by the Global Cache compared with the total number of data items published by all WIS2 Nodes (on `origin` topics).
+
+*Measure (calculated each hour):*
+
+The number of data items published by all origin WIS2 Nodes is recorded using the metric `wmo_wis2_scgc_messages_published_total`. Only those data items expected to be cached are included in this measure.
+
+The number of data items cached by a Global Cache is recorded using the metric `wmo_wis2_scgc_messages_cached_total`. Data items that are cached more than 600-seconds after publication by the origin WIS2 Node are excluded from this measure.
+
+Because Global Caches are designed to discard out-of-sequence updates, and counting such discards as "misses" would not be a fair reflection of performance, KPI performance is evaluated only for "canonical" data items (i.e., where the Notification Message specifies the link-relation `canonical`). Both `wmo_wis2_scgc_messages_published_total` and `wmo_wis2_scgc_messages_cached_total` metrics include the label `rel` to distinguish the link-relation.
+
+The percentage of data items published by a Global Cache is calculated as the increase in metric `wmo_wis2_scgc_messages_cached_total (rel=canonical)` over the previous hour ÷ the increase in metric `wmo_wis2_scgc_messages_published_total (rel=canonical)` over the previous hour.
+
+*KPI evaluation (hourly):* 
+
+The cache completeness KPI is set to "pass" for the hour if the percentage of data items cached is not less than 95 per cent of the number published by origin; otherwise it is set to "fail" for the hour.
+
+==== A.2.2 Successful downloads KPI
+
+This KPI measures the proportion of cached data items that can be successfully downloaded from the Global Cache, including, where a checksum is available in the message, validation of data integrity.
+
+*Measure (calculated each hour):* 
+
+This measure is evaluated using a sample set of 300 randomly selected data items each hour. Data items must be cached by all Global Caches to be included in the sample set. The same sample set is used for all Global Caches. A small sample size is used to avoid overloading both Global Caches and Sensor Centres.
+
+The total number of data items sampled for download validation is recorded using the metric `wmo_wis2_scgc_download_selected_total`.
+
+The total number of data items in the sample set successfully downloaded by each Global Cache is recorded using the metric `wmo_wis2_scgc_download_successful_total`.
+
+The percentage of data items successfully downloaded is calculated as the increase in metric `wmo_wis2_scgc_download_successful_total` over the previous hour ÷ the increase in metric `wmo_wis2_scgc_download_selected_total` over the previous hour.
+
+*KPI evaluation (hourly):* 
+
+The successful download KPI is set to "pass" for the hour if the percentage of successful downloads is not less than 95 per cent; otherwise it is set to "fail" for the hour.
+
+Note that if `wmo_wis2_scgc_download_selected_total` is zero for the previous hour (i.e., no data items were cached by any Global Cache - perhaps because one Global Cache is offline), the successful downloads KPI cannot be calculated. In this case, the KPI is automatically set to "pass" for all Global Caches. The Global Cache that is offline will fail the cache completeness KPI, thus the combined KPI (see below) for the offline Global Cache will always be a fail.
+
+==== A.2.3 Combined hourly and monthly KPI
+
+* For each hour, the Global Cache is considered operational where *both* the cache completeness KPI *and* the successful downloads KPI are set to "pass". If either KPI fails for the hour, the Global Cache is considered non-operational for that hour. 
+* Each month, the overall KPI is set to "pass" if the combined hourly KPI passes for not less than 98 per cent of hours in the month (i.e. the Global Cache may experience up to 14 "failure" hours in a calendar month and still be considered performing within the service level).
+* Hours coinciding with planned outages, or other _force majeure_ agreed by SC-IMT, are excluded from the monthly KPI calculation.
+* The monthly KPI is used in the assessment of Global Cache performance informing the determination of downtime in accordance with section 2.7.2.6.
+
+

guide/sections/appendix_b.adoc

@@ -0,0 +1,3 @@
+== APPENDIX B: WMO CORE METADATA PROFILE (VERSION 2), KEY PERFORMANCE INDICATORS
+
+https://wmo-im.github.io/wcmp2/kpi/wcmp2-kpi-DRAFT.html

guide/sections/part1/data-consumer.adoc

@@ -54,9 +54,9 @@ A discovery metadata record or notification message may provide more than one do
 
 A data consumer should expect to receive multiple notification messages about the same data item. Furthermore, data consumers should not assume that messages arrive in time-sequence order (i.e., newest published message, as indicated by ``properties.pubtime``, arriving last). Consequently, for notification messages relating to the same data item (i.e., notification messages with identical ``properties.data_id``), they should:
 
-1. Prioritise the message with the latest publication time. 
+1. Prioritise the message with the latest publication time.
 2. Discard any notification messages earlier publication time that have not yet been processed or may be received in the future.
-3. Where a previous notification message with earlier publication time has already been processed, any data or metadata associated with the earlier notification message should be overwritten. 
+3. Where a previous notification message with earlier publication time has already been processed, any data or metadata associated with the earlier notification message should be overwritten.
 
 This means that a data consumer should keep track of notification messages that have been processed so that newly arrived notification messages can be compared with earlier messages identify which notification message relates to the latest version of the data or metadata. Given that messages propagate rapidly through WIS2, a record of previous messages need not exceed a 60-minute duration.
 

guide/sections/part1/data-publisher.adoc

@@ -183,11 +183,11 @@ Data publishers planning to operate WIS2 Nodes, at a minimum, should read the fo
 
 The following sections are recommended for further reading:
 
-* <<_part_iii_information_management>>
-* <<_part_iv_security>>
-* <<_part_v_competencies>>
+* <<_part_iv_information_management>>
+* <<_part_v_security>>
+* <<_part_vi_competencies>>
 
-Note that _PART IV. Security_ and _PART V. Competencies_ reference content originally published for WIS1. These sections remain largely applicable and will be updated in subsequent releases of this Guide. 
+Note that _PART V. Security_ and _PART VI. Competencies_ reference content originally published for WIS1. These sections remain largely applicable and will be updated in subsequent releases of this Guide. 
 
 Data publishers publishing aviation weather data via WIS2 for onward transmission through the International Civil Aviation Organization (ICAO) System Wide Information Management (SWIM), should also read <<_2_8_1_1_publishing_meteorological_data_through_wis2_into_icao_swim>>.