AERODROME METEOROLOGICAL OBSERVATION AND FORECAST STUDY GROUP (AMOFSG)

Transcription

1 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 en.doc

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 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) 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 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 VISNA CLDNA TEMPNA Wind not available due to sensor unserviceability Visibility not available due to sensor unserviceability Cloud not available due to sensor unserviceability Temperature not available due to sensor unserviceability

3 - 3 - QNHNA Pressure not available due to sensor unserviceability 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) 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 WINDDIR NA WINDSPD NA VIS NA CLD NA CLDAMT NA CLDHGT NA CLDTYP NA TEMP NA DEWP NA QNH NA Wind not available due to sensor unserviceability Wind direction not available due to sensor unserviceability Wind speed not available due to sensor unserviceability Visibility not available due to sensor unserviceability Cloud not available due to sensor unserviceability Cloud amount not available due to sensor unserviceability Cloud height not available due to sensor unserviceability Cloud type not available due to sensor unserviceability Temperature not available due to sensor unserviceability Dew point not available due to sensor unserviceability Pressure not available due to sensor unserviceability 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 & refers) 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 The existing requirement for the reporting of present weather is defined by Annex 3, para and elaborated on at App 3, para 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.

4 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 BR FG RA DZ SN RADZ RASN UP FZRA FZDZ FZUP FZFG Haze Mist Fog Rain Drizzle Snow Rain & drizzle Rain & snow Unidentified precipitation Freezing rain Freezing drizzle Freezing unidentified precipitation Freezing fog 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 TSRA TSSN TSGR TSGS TSUP VCTS Thunderstorm Thunderstorm with rain Thunderstorm with snow Thunderstorm of hail Thunderstorm with small hail/snow pellets Thunderstorm with unidentified precipitation Thunderstorm in vicinity The following should remain RPs: SHGR SHGS Showers of hail (intermittent hail) Showers of small hail/snow pellets (intermittent small hail/snow pellet) 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 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 - 5 - 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 SHSN SHUP Showers of rain (intermittent rain) Showers of snow (intermittent snow) 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. This would allow the reporting of this weather phenomena in cases where cloud type cannot be detected For reasons of existing capabilities, low reliability and/or prohibitive expense it was found that the following present weather parameters may not be feasible to remain a requirement in Annex 3 for fully automated weather reports. These are as follows: FC Smoke PO Dust whirl BCFG Fog patches MIFG Shallow fog PRFG Partial fog DRSN Low drifting snow VA Volcanic ash SA Sand DU Dust SS Sandstorm DS Duststorm FU Smoke VCBLSN Blowing snow in vicinity VCFC Funnel cloud in vicinity VCFG Fog in vicinity VCSH Showers in vicinity Consequently, it is considered that Industry should verify the on going requirement for these weather parameters in automated reports in view of existing capability, investment and need. Further, industry should also consider the cost benefits of the reporting of phenomena in the vicinity in general It might also be beneficial to request IPs relating to the progress of instrument manufacturers to generate more cost effective and effective means of measuring these parameters, with a view to reviewing the SARPs for each ICAO amendment cycle as technology and as user needs change KNMI identified the potential for reporting Ice Pellets (PL), Ice Crystals (IC), Snow Grains (SG) and Squall (SQ) with some reliability. Whilst it is evident that technological improvements are improving the accurate detection scores for frozen precipitation, it is questionable at this time whether their reliable meets the industry requirements. It is suggested therefore to ask the Secretary to request IPs

6 - 6 - relating to existing and future detection capabilities of frozen precipitation with a view to the their future inclusion in automated reports With the views of industry to mind, it is proposed to ask the Secretary to put forward an amendment to Annex 3 Meteorological Service for International Air Navigation (or at least guidance) that clearly defines the list of present weather parameters that shall and should be reported in automated reports, based upon the list provided and following discussions at this meeting. Action 2: Encourage the submission of IPs from Industry representatives on: 1) the continual requirement for the use of SH (denoting intermittent precipitation in AUTO METARs (para refers), 2) the on the going requirement for the weather parameters (para refers), and 3) the on going requirement to report in the vicinity when automated reports are being generated. Action 3: Encourage States to submit IPs on: 1) TS detection currently employed in States (para refers) and 2) the existing and future detection capabilities of frozen precipitation (para refers) Action 4: Ask the Secretary to consider updating Annex 3 with the revised requirements for the automated reporting of present weather, as detailed in para & of this study note. In consideration of the ICAO desire to maintain a minimum common standard for all reports (both manual and automated), the following amendment is proposed: The present weather occurring at the aerodrome and/or its vicinity shall be observed and reported as necessary. The following present weather phenomena shall be identified, as a minimum: precipitation rain, drizzle, snow and freezing precipitation (including intensity thereof), haze, mist, fog, freezing fog and thunderstorms (including thunderstorms in the vicinity). 2.3 Present Weather Sensor at CAT II and III aerodromes This task asked the group to consider the potential value in mandating the availability of sensors that would enable the provision of the present weather groups required as a minimum under Annex 3, para This would be for just CAT II & III airports where operational limits are the most stringent. It should be clear that the availability of such sensors should be required to enhance or supplement human observation, not replace it. In practice, to meet existing minimum present weather requirements, this equates to ensuring the provision of a visiometer (for obscurates) and temperature sensor (for freezing weather), both of which are already required, and precipitation sensor -these combined into a integrated observing system The rationale for this is the increasing propensity for observations to be undertaken from elevated positions within control towers. Whilst there are undoubted advantages in terms of all round

7 - 7 - visibility, the detection of certain present weather phenomena may be hindered by this elevation and lack of external accessibility. The UK has demonstrated proven benefits and greater consistency in the reporting of present weather at its CAT II & III aerodromes by having sensors that can detect and display to the observer present weather information On the basis of the feedback received, it would appear there was consensus that States with CAT II & III airports generally already had sensor capability to supplement human observation. In the interest of trying to raise the minimum standards for accurate weather reporting at such airport, we propose including present weather within Annex 3, para as follows: At aerodromes with runways intended for Category II and III instrument approach and landing operations, automated equipment for measuring or assessing, as appropriate, and for monitoring and remote indicating of surface wind, visibility, present weather, runway visual range, height of cloud base, air and dew-point temperatures and atmospheric pressure shall be installed to support approach and landing and take-off operations. These devices shall be integrated automatic systems for acquisition, processing, dissemination and display in real time of the meteorological parameters affecting landing and take-off operations. The design of integrated automatic systems shall observe Human Factors principles and include back-up procedures. For consistency the RP at para should be similarly updated. Action 5: Ask the Secretary to draft an amendment to Annex 3, para for the addition of present weather to be included within the suite of instrumentation required to supplement human observation at CAT II and CAT III airports. 3. ACTION BY THE GROUP 3.1 In summarising the outcomes in this Paper, the group is invited to: a) note the contents of this paper; b) 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 & refers); and c) encourage the submission of IPs from Industry representatives on: and 1) the continual requirement for the use of SH (denoting intermittent precipitation in AUTO METARs (para refers), 2) the on the going requirement for the weather parameters (para refers), and 3) the on going requirement to report in the vicinity when automated reports are being generated. and d) encourage States to submit IPs on: 1) TS detection currently employed in States (para refers) and

8 - 8-2) the existing and future detection capabilities of frozen precipitation (para refers); and e) ask the Secretary to consider updating Annex 3 with the revised requirements for the automated reporting of present weather, as detailed in para 2.2 of this SN; and f) ask the Secretary to draft an amendment to Annex 3, para for the addition of present weather to be included within the suite of instrumentation required to supplement human observation at CAT II and CAT III airports.

9 Appendix APPENDIX COLLATED RESPONSES AND CONSENSUS OPINION RECEIVED FROM RESPONDENTS Task 1a: Representation of missing or undetected present weather information in automated reports* Task 1b: Representation of missing information in automated reports* due to sensor failure Consider the requirements for the representation of present weather where provided automatically. Consider the requirements for the representation of other missing information due to sensor failure. Questions: a) How are users notified of present weather instrumentation failures, when they are utilized in the provision of automated reports* (i.e. in the METAR itself, by NOTAM, or in the METAR remarks section)? Most States use NOTAMs to notify users of present weather sensor unserviceability, and for that matter sensor unserviceability in general. The use of solidii are made by many States for elements with unserviceable sensors. Some States also used solidii with present weather, whilst no provision currently exists in Annex 3 to do so. The viewpoint of IFALPA during AMOFSG8 was recalled, noting that the use of solidii were meaningless to users. Some use was made of the RMKs section in METARs to refer to sensor unserviceability (though as RMKs, these are not disseminated internationally). b. Are you receptive to the idea of representing such instances of present weather sensor failure in the main body of automated reports* in the future? Given the current disparate ways in which present weather sensor unserviceability is relayed to users, it is perhaps not surprising to learn there was universal support to generating a provision in Annex 3 to represent such instances.

10 Appendix A-2 Such measures would address a potential safety concern of users making operational decisions based upon incomplete or erroneous data by clearly differentiating between a genuine report of no weather and no weather resulting from erroneous sensor output. c. If so, how best should this be represented? A number of solutions were proposed. The UKs suggestion of NOWX was widely felt to be potentially misconstrued as meaning no weather to report. Solutions offered included WXUS, WXNA or NAPW, though the most popular was WXNA. Finland also reflected on the potential additional related codes to denote failure of individual weather sensors such as lightning sensor, precipitation sensor, visiometer etc that would render a partial unserviceability of the overall present weather sensor capability. There is a clear requirement for suitable coding to be defined to represent weather sensor unserviceability. Whilst there was a desire by some responders to take this one stage further to derive code for the unserviceability of individual weather parameters, it is proposed that, as a first step, a generic PW code be developed. Additional information could be provided by individual States via AIPs or use of RMKs) d. Should consideration be given to similarly notifying the unserviceability of other sensors (e.g. wind and pressure) that are used in the provision of AUTO METARs and AUTO Local Reports There was broad support to develop codes to be used in lieu of wind, visibility, cloud, temperature and pressure in automated reports when the sensors used to derive this information were unserviceable. Further, there was a desire for consistency of coding with that agreed for present weather. For example if WXNA (Weather Not Available) was in use, then similarly WINDNA, VISNA etc should be used. It was considered that the practice of reporting solidii would represent be the most efficient (in terms of characters) way of reporting, even if the information supplied was not as transparent to users. However noting the views of IFALPA at AMOFSG/8 it was noted the use of solidii is not well understood and confusing to users. The group agreed the need to make provision of unserviceable elements in automated reports. Such codes should be consistent with the code form defined for PW sensors.

11 A-3 Appendix Task 2: The ability to adequately report SH & TS in automated reports*, which are existing Standards Review the following present weather elements currently required as a Standard which have some inherent limitations in observing ability from automated sensors: SHRA, SHSN, SHGR, SHGS, SHRASN, SHRAGR, SHRAGS, TS, TSRA, TSSN, TSGR, TSGS, TSRASN, TSRAGR, TSRAGS, VCTS, PL and SG Questions: a. The reporting of showers is an existing Standard in Annex 3. This Standard makes no distinction between human intervened and fully automated weather reports. Can the existence of showers be adequately represented by present weather sensors given the meteorological definition of showers (i.e. requiring convective cloud). If not, do existing algorithms provide a realistic outcome in the most part? It was understood that the methodology used to determine the presence of showers varied according to whether or not the report was derived with or without human intervention. Whilst there is an attempt at an objective definition in Doc 9837, the UK queried whether this alone was sufficient and more so whether there was actually a need to differentiate between convective and dynamic precipitation in automated reports. Responders generally agreed that sensors have only limited proven success in correctly determining whether precipitation resulted from convective and non-convective clouds.. Algorithms in use typically look for breaks in precipitation to determine showers in automated reports, which actually add little value or reliability to the character of precipitation. As such, it is perhaps more accurate to describe showers in automated reports as intermittent precipitation. That said, there was appreciation that if sensors could accurately report SH in automated reports they would add value, since this may indicate the presence of convective cloud, especially where ceilometers are not capable of detecting TCU/CB. That being the case however, it is arguable that focus should be on ceilometers to provide suitably reliable output rather than inferring convection from SH in present weather and the poor record that PW sensors have for actually detecting showers. b. Do you have objective data on current ability of sensors to determine SH? A number of States provided objective data on the performance of present weather sensors to correctly determine the reporting of SH. Studies showed that the identification success rate (between sensors reporting SH and human observers reporting likewise) in the UK was 59%. In Australia it was between 16-43% and in Netherlands around 25%. All responders agreed that accurately replicating showers in automated weather reports was difficult and inaccurate. Results did improve where the classification of precipitation (SH or not) is neglected,

12 Appendix A-4 concluding that present weather sensors are reliable in determining the type of precipitation. But unreliable at determining the characteristic. c. Is it actually important for aviation users to know whether precipitation is showery or dynamic? The existing methodology in use for sensors to determine SH is limited (i.e. temporal variations in precipitation) and results have been shown to be largely unreliable. There was significant support for the view that users have little need to know whether the precipitation is dynamic or convective, since this is unlikely to have any bearing on operational decisions, given that operational decisions would be based upon the presence of significant cloud driving the precipitation such as TCU or CB. However, some responders noted that users would use SH to infer the presence of convective cloud, particularly for GA and business aviation and the figures suggest that these assumptions would be erroneous in 50% of occasions Clearly there is significant support for the fact that the determination of SH in automated reports is not a significant issue for aviation or one that can be accurately determined, and could be removed relying on output from ceilometers and/or weather radar to the presence of significant convective activity. However, this support is not universal amongst the Ad-hoc team and requires further debate. d. What is the overall current and foreseeable future ability of States to provide TS information in automated reports*? Is cost a major factor in the existing ability of States to determine TS automatically? Responders provided a strong consensus on the importance of continuing to develop the capability to accurately report TS in automated reports this could be achieved in a number of ways such as a lightning detection network, or possibly aerodrome based sensors. States with such a capability report reasonable results, even with single site sensors which cost roughly the same as a ceilometer. Reports from lightning detection systems are not totally reliable, then again neither are human observers(!) especially with the increasing propensity to report from hermetically sealed and sound proofed VCRs. There is a strong case therefore to promote continuing development and use of TS in automated reported. Further, it is suggested that a greater understanding of TS detection is required, given the huge importance of accurate detection in terms of flight safety. It was also noted that many States derive the presence of lightning at an aerodrome from remote sensing and lightning networks, rather than solely on a lightning sensor. e. What is the overall current and foreseeable future ability of States to provide GR/GS in automated reports*. Do States consider sensors for hail to be reliable enough for operational use?

13 A-5 Appendix The WG broadly agreed that accurate reporting of hail from automated on site or remote sensors was difficult. However, some States have recorded reasonable results (though error bars would be relatively high owing to the relative rarity of occurrence). Other States noted the development of on site sensors which are expected to improve future performance. There was little desire to remove the existing requirement to report GR/GS in automated reports given the importance placed on its detection by aviation, instead the desire was to focus on technological solutions to derive suitably reliable results. Task 3: The ability and future need to report certain present weather phenomena in automated reports*, which are currently RPs. Review of the following present weather elements currently required as a Recommended Practice and considered to be difficult to resolve by instrumentation: FC, PO, BCFG, MIFG, PRFG, DRSN, VA, VCBLSN, VCFC, VCFG, VCSH, SA, DU, SS, DS & FU There was general agreement that the following present weather parameters were either incapable of being reported by sensors alone (i.e. in automated weather reports), had low reliability or were prohibitively expensive to implement: FC PO BCFG MIFG PRFG DRSN VA VCBLSN VCFC VCFG VCSH SA DU SS DS FU Smoke Dust whirl Fog patches Shallow fog Partial fog Low drifting snow Volcanic ash Blowing snow in vicinity Funnel cloud in vicinity Fog in vicinity Showers in vicinity Sand Dust Sandstorm Duststorm Smoke

14 Appendix A-6 Task 4: Upgrading to a Standard the need for CAT II & CAT III airports to be equipped with an automated present weather sensor The potential inclusion of a present weather sensor in the Standard at Annex 3, 4.1.5, which lists the elements that shall be required for Category II and III instrument approach and landing operations Questions: a. Roughly what proportion of CAT II and CAT III airports in your State currently utilize a present weather sensor? Response summary Responses suggest that at present a significant number of CAT II &III airports do not have a full suite of present weather sensors. b. What is the standpoint of users on the need for CAT II & CAT III airports to be equipped with an automated present weather sensor as a standard? Response summary There was general agreement in the benefit of having standardized equipment to help generated consistent reports. There was some discussion on whether a suite of present weather sensors at such airports would generate the requisite step change in quality output, with some stating that many of the parameter they observe are not reliable enough. It should be borne in mind however, that the question posed does not suggest that a suite of sensors that are able to report present weather could replace a human observer at CAT II & II airports; merely whether they should be a requirement that such sensors should supplement human observation at CAT II and III airports, where operational limits are the most stringent. c. What present weather phenomena are these sensors reliably able to detect? Response summary Reports from members of the WG suggest there was broad agreement on the capability of automated sensors to provide accurate reports of the presence of the following weather parameters: HZ BR FG RA Haze Mist Fog Rain

15 A-7 Appendix 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 SHRA Showers of rain (intermittent rain) SHSN Showers of snow (intermittent snow) SHUP Showers of unidentified precipitation (intermittent unidentified precipitation) It would be reasonable to suggest that these weather parameters could become Annex 3 Standards for automated weather reports. Please note the potential definition of showers as intermittent precipitation, to more accurately reflect the methodology of detection. Further, the continuing requirement for showers is dependent upon a continuing requirement from Industry (reference Way Forward in Task 2c) Some responders reported the ability to report TS (with associated weather) without human intervention, though this was by no means standard practice. Human observation is largely responsible for reporting (or validating) TS. There is a clear on-going requirement for reporting TS in automated reports in Annex 3, and as such, the following weather parameters are required in automated reports: TS Thunderstorm TSRA Thunderstorm with rain TSSN Thunderstorm with snow TSUP Thunderstorm with unidentified precipitation VCTS Thunderstorm in vicinity States found little or no capability for automated sensors to report the other weather parameters listed in Annex 3 in automated reports. It may be suggested that on this basis there is little need to note a requirement or recommended practice for these in any Annex 3 provision relating to the present weather requirements in automated reports (see Way Forward at Task 3). This list is largely consistent with Annex 3, Ch 4, para , but more clearly defines the requirements for automated reports. d. Perception of benefits of having Present weather sensor at CAT II & III airports. Response summary It was broadly agreed that where observing is undertaken in VCRs (as is increasingly the case), such location present some additional difficulties for human observation. For example, the observer is often located at a considerable height above ground level which brings potential difficulties in the observing of present weather, such as assessing whether fog is shallow or patchy in nature, and detection of precipitation types and rates (often it is difficult or time consuming to gain outside access). For these

16 Appendix A-8 reasons, present weather sensors provide an invaluable aid to support the provision of high quality observational data to air traffic at the airports with the most stringent weather reporting requirements. It should be noted that, automated sensors at CAT II & CAT III airports would be there to enhance and supplement human observation, not replace it. Further, it is proposed that sensors should be capable of just providing guidance on those weather parameters most reliably detected, i.e. those at Task 4c. In practice this amounts to just a visiometer (for obscurates), temperature sensor (for freezing), precipitation sensor. e. Bearing in mind safety and cost aspects and your other answers, do you support an amendment to Annex 3, para 4.1.5, as follows: At aerodromes with runways intended for Category II and III instrument approach and landing operations, automated equipment for measuring or assessing, as appropriate, and for monitoring and remote indicating of surface wind, visibility, present weather, runway visual range, height of cloud base, air and dew-point temperatures and atmospheric pressure shall be installed to support approach and landing and take-off operations. These devices shall be integrated automatic systems for acquisition, processing, dissemination and display in real time of the meteorological parameters affecting landing and take-off operations. The design of integrated automatic systems shall observe Human Factors principles and include back-up procedures. Response summary There was a majority of responders in favour of this amendment, though Canada and Australia had reservations. As noted at Task 4d the proposal is for sensors should be capable of just providing guidance on those weather parameters most reliably detected, to provide the weather parameters listed at Task 4c. -END-