AMOFSG/9-SN No. 11 9/6/11 AERODROME METEOROLOGICAL OBSERVATION AND FORECAST STUDY GROUP (AMOFSG) NINTH MEETING Montréal, 26 to 30 September 2011 Agenda Item 5: Observing and forecasting at the aerodrome and in the terminal area 5.1: Observations REPORT OF THE AD-HOC WORKING GROUP ON THE FUTURE REPORTING OF PRESENT WEATHER IN FULLY AUTOMATED MET REPORTS (Presented by Colin Hord, Rapporteur of AMOFSG/8 ad-hoc WG/3) SUMMARY This paper presents the conclusions of the ad-hoc team tasked with reviewing the options for the future reporting of present weather in fully automated weather reports. 1. INTRODUCTION 1.1 At the eighth meeting of the Aerodrome Meteorological Observation and Forecast Study Group (AMOFSG/8), Action 8/13 led to the formation of an ad-hoc team with the objective to consider the following tasks: a) the representation of missing present weather and other information in weather reports when automatically generated b) review the ability to adequately report TS and SH in automated weather reports (a current Standard). c) review the ability and future need to report certain present weather phenomena in automated reports, which are currently RPs. d) the potential requirement for all CAT II & CAT III airports to be equipped with an automated present weather sensor AMOFSG.9.SN.011.5.en.doc AMOFSG/9-SN No. 11 - 2 - 1.2 The following members have provided valuable information leading to the summarized results in this paper. Colin (Rapporteur) assisted by Darren Hardy, Bill, Herbert, Jan (assisted by Kees Blom, Nico Maat), Jarmo Keith, Ophelia, Steve, Peter & Shona (assisted by Don Anderson). The summarized responses are attached at the appendix to this paper. From the appendix to this paper, an ‘Executive Summary’ is provided that details the discussions and conclusions. 1.3 The responses received lead the Rapporteur to conclude that a single paper should be generated for AMOFSG/9 containing the following 3 sections: 1. Missing information in AUTO METARs 2. Review of capabilities of PW sensors 3. Present Weather Sensor at CAT II and III aerodromes 2. DISCUSSION 2.1 Missing information in AUTO METARs 2.1.1 The ad-hoc team were tasked with considering how best to represent the present weather group in automated reports when a sensor existed but was unserviceable. In addressing this, it became evident that currently most States alert users to the non availability of automated weather reports due to sensor failure through the provision of NOTAMs. It is understood that some States utilise solidii within the automated report itself to denote sensor unserviceability. However, during AMOFSG8 it was noted that the International Federation of Air Line Pilots’ Associations (IFALPA) felt that the use of solidii provide little meaningful information to users. It is concluded that suitable brief guidance on the use of NOTAMs to alert users to sensor unserviceability should be generated in Doc 9837 (Manual on Automated Meteorological Observing Systems at Aerodromes). 2.1.2 For the reasons provided by IFALPA it is considered necessary to generate specific terminology to represent the non availability of information for present weather. There are various combinations that could be used for this purpose, though the consensus view was that the code ‘WXNA’ (Weather data not available due to sensor failure) should be proposed to be adopted in such circumstances. 2.1.3 In consideration of similar issues for each other element of automated reports resulting from the failure of sensors it was considered that a similar format could be proposed to provide additional information on the unserviceability of any other sensor. That being the case, it is proposed that the following format should be proposed to be adopted: ‘xxNA’, where xx refers to any of the following parameters ‘WIND’, ‘VIS’, ‘CLD’, TEMP’ & ‘QNH’, and NA means ‘Not Available due to sensor unserviceability’. With the agreement of group, this would lead to the following additional codes in automated METARs: WINDNA Wind not available due to sensor unserviceability VISNA Visibility not available due to sensor unserviceability CLDNA Cloud not available due to sensor unserviceability TEMPNA Temperature not available due to sensor unserviceability - 3 - AMOFSG/9-SN No. 11 QNHNA Pressure not available due to sensor unserviceability 2.1.4 In recognition of the format differences in automated local and special reports, the following format is offered as a proposal for local & special reports: ‘xx NA’, where xx refers to any of the following parameters ‘WIND’, ‘VIS’, ‘CLD’, T’, ‘DP’ & ‘QNH’, and NA means ‘Not Available due to sensor unserviceability’. (The spacing between xx and NA reflecting consistency with the format defined in Table A3-1 of Annex 3). 2.1.5 It was noted by KNMI in particular the potential additional benefit of discriminating between parts of particular groups in local reports, for example ‘Wind direction’ and ‘wind speed’. With the agreement of group, this would lead to the following additional codes for local reports: WIND NA Wind not available due to sensor unserviceability WINDDIR NA Wind direction not available due to sensor unserviceability WINDSPD NA Wind speed not available due to sensor unserviceability VIS NA Visibility not available due to sensor unserviceability CLD NA Cloud not available due to sensor unserviceability CLDAMT NA Cloud amount not available due to sensor unserviceability CLDHGT NA Cloud height not available due to sensor unserviceability CLDTYP NA Cloud type not available due to sensor unserviceability TEMP NA Temperature not available due to sensor unserviceability DEWP NA Dew point not available due to sensor unserviceability QNH NA Pressure not available due to sensor unserviceability 2.1.6 It was noted that the United States has for a number of years been providing similar information in the RMKs section of METARs. In terms of the need to notify users of sensor unavailability in automated reports, the necessity to keep such information within the body of the METAR (and local report) should be considered in order that the information might be disseminated internationally and ingested within software systems. Action 1: In respect of this, it is proposed that the subgroup ask the Secretary to prepare an Annex 3 amendment for the use of appropriate coding to denote the non-availability of AUTO METAR groups due to sensor failure (paras 2.1.3 & 2.1.5 refers). 2.1.7 The United States also noted that there were a number of issues associated with implementing such a proposal and wished to see further discussions especially with users before implementation. 2.2 Review of capabilities of PW sensors 2.2.1 The existing requirement for the reporting of present weather is defined by Annex 3, para 4.6.4.1. and elaborated on at App 3, para 4.4.2. 2.2.2 These Standards and Recommended Practices (SARPs) however make no distinction between fully automated reports and reports with human intervention. So in theory at least the full extent of weather parameters should be equally available in automated reports as well as from human intervened reports. AMOFSG/9-SN No. 11 - 4 - 2.2.3 The consensus of the group considered that only the following weather groups can be reported in fully automated reports to a similar accuracy to that achievable by human intervention: HZ Haze BR Mist FG Fog RA Rain DZ Drizzle SN Snow RADZ Rain & drizzle RASN Rain & snow UP Unidentified precipitation FZRA Freezing rain FZDZ Freezing drizzle FZUP Freezing unidentified precipitation FZFG Freezing fog 2.2.4 There was strong support for the requirement to report TS and GR/GS in automated weather reports. It was clear that these may be achieved in a number of ways, including remote sensing and single site sensors, but also to a large extent reliant on human detection. However, the results obtained are often variable, especially with hail. It is suggested that States are encouraged by the Secretary to provide information papers (IPs) on methods to detect TS and hail within their States for AMOFSG/9 and focus on technical solutions to derive suitably reliable results. As such, the following additional weather parameters should remain Standards for automated weather reports: TS Thunderstorm TSRA Thunderstorm with rain TSSN Thunderstorm with snow TSGR Thunderstorm of hail TSGS Thunderstorm with small hail/snow pellets TSUP Thunderstorm with unidentified precipitation VCTS Thunderstorm in vicinity The following should remain RPs: SHGR Showers of hail (intermittent hail) SHGS Showers of small hail/snow pellets (intermittent small hail/snow pellet) 2.2.5 Studies carried out by States have concluded that the algorithm used to generate reports of showers in automated reports (which are based on temporal variations in precipitation), provide poor correlation against the traditional definition of showers (indicated by the presence of convective cloud). This suggests that reports of SH in automated reports may provide unreliable or misleading information to users. 2.2.6 Whilst it is perfectly possible to continue to have a requirement to report SH in automated reports, it is suggested that Industry consider the on going requirement to receive information - 5 - AMOFSG/9-SN No. 11 relating to what is more accurately defined as ‘intermittent precipitation’. This will inform the requirement or not to add the following weather parameters as requirements in automated weather reports. SHRA Showers of rain (intermittent rain) SHSN Showers of snow (intermittent snow) SHUP Showers of unidentified precipitation (intermittent unidentified precipitation) Note. — It is assumed that automated systems can adequately differentiate between slight (-), moderate and heavy (+) precipitation) With respect to this, it is questionable whether the prefix SH is required in association with GR and GS in automated reports. Arguably, given the more precise meaning of SH in automated reports, there is a case for permitting GR & GS without that SH prefix.