1. AAAv3 to include VA sensor data


2. SAA AMDAR Data Problem


3. ARINC620v5 to include IAGOS specification?


4. AMDAR Panel-14 Proposed Agenda


5. Mexico Workshop Agenda


6. Meeting AMDAR Panel MG


7. AMDAR Document for Aviation


8. AMDAR Reporting Levels


9. Your visit to De Bilt

There might me more (hidden) subjects, but I consider these as the most relevant ones at the moment.

My comments, one by one:

1.  I agree that there is an increasing pressure to find ways to present Vulcanic Ash data (if needed). The AMDAR system, like for water vapour, might be the beneficial (and existing) way to make that happen. Water vapour however is extremely important for operational meteorology and aviation, making it one of the most wanted AMDAR parameters. The requirement of VA data comes (understandably) from the aviation industry. I feel a certain unbalance in the view (or wish) to use the AMDAR system, because the aviation industry is on the other hand very reluctant in installing AMDAR. But that is my personal opinion.

I have some doubts on the relevance of including VA data into the AMDAR data stream, not only from a financial point of view (who will pay for the AAAv3 upgrade, the re-installation of the software and the transmission cost) but also looking at the real use of it. In the case of the Icelandic volcano and, just recently because of the Chile volcano, we saw that the commercial airlines effected did ground their aircraft just because of the volcanic ash for safety reasons. Will give the installation of VA sensors the assurance that passenger aircraft will be directed to the regions effected by volcanic ash plumes?  Some airlines might take the decision that flights are “safe” (airlines in Europe did complain that they were only directed by the authorities not to fly and that this was not their own decision).  

In short: we (the AMDAR community) should first come to a sort of agreement with …? (which organisation is responsible for VA measurement?) before starting any initiative and it has to be made clear what the costs are who is paying for what. I think the Panel has to draft a sort of recommendation including this kind of approach, but further discussion between ourselves (and certain VA responsible persons) before bringing this to the Panel would be needed.

2. I follow the SAA AMDAR Data Problem with great interest (and I am glad that Gabo has become active again, I had a discussion on the lack of response from SAWB with the PR during Congress). Better for me to stay out of the discussion (it is handled by you and our South African friends in an effective way) but I will step in if my involvement might be needed.

3. I have my doubts about including the IAGOS specification into the next version of ARINC620. In the past we have has lengthy discussions whether or not to include IAGOS into the AMDAR definition and the conclusion was to see AMDAR and IAGOS (for several reasons) as two separated systems. That resulted in a separate IAGOS BUFR Template and a separate IAGOS Data Stream. The data format was chosen to be as similar as possible to AMDAR in order to make it possible of making use of the E-AMDAR infrastructure.

Including IAGOS in  the next ARINC620 version would contradict with what was decided as described before. Axel’s assumption (but also doubt) that by defining a special trigger would be the solution for not having the large increase in data volume is very uncertain and has to be confirmed by AEEC. We will se a lot of overhead and relatively few used parts in the ARINC620 specification only for a relatively small number of aircraft intending to fly IAGOS.

Wouldn’t it be more effective to develop a specific ARINC620-like specification only for IAGOS. This would be a pure aviation business separated from AMDAR. Certainly we could be of assistance in writing the definition (as we are in the IAGOS discussions) but it would make the current views on the update of the ARINC620 specification less complicated (as it is already because of the inclusion of Water Vapour and the other new definitions).

We need to be rather quick on developing our position because of the dead line for providing the draft ARINC620 update for discussion in AEEC.

4. (re. your e-mail of 7 July to Carl) Carl has certainly a point in stating that the major player in AMDAR are involved in all facets. And because of the different way these programmes are implements it should be interesting for the smaller programmes or the potential programmes to learn how such a programme could be developed. I however also share your idea of making more time available for planning, short to long term. Especially because AMDAR is now more tightly included into the WMO Strategy. Therefore all aspects of WIGOS/WIS, ICT/IOC (ET-AIR) and ET-EGOS should be considered. But we should not forget the increasing importance for the airline industry which requires a different approach. We will introduce the Associated Members for which IATA, ICAO and others are candidate, we will have to consider their planning aspects and technical possibilities with more attention.

I agree that we should try and start this process of (gradually) changing the nature of the agenda and the focus of our Panel/ET-AIR discussions. Let us see how far we can get during your visit to De Bilt (see 8).

5. (re. Stig’s e-mail of 7 July) It is anxiously quite about the Mexico Workshop, the organisational activities around it and the finalization of the agenda (speakers have to be confirmed, etc).

Certain aspects (what and how to be presented) are not yet clear, see the justified question asked by Stig. We also need to discuss and to go over the status of the organisation, the still needed steps to be taken and the actions to be started shortly in order to make the Mexico Workshop successful (this is more than a workshop organised by the Panel! It belongs to a larger bilateral USA/Mexico programme of which AMDAR is a relevant part). Also to be discussed further in De Bilt.

6. It is a pity that we cannot organise a MG meeting in the short term, looking at all the urgent issues as described above and beneath. I respect however the limits of all of us and I hope that the telecon will synchronise at least the members of the MG. It would be very good for achieving that if you and I (and perhaps some others relevant to some or all subjects to be discussed) could meet before that telecon. My calendar is  still open in the period 8-19 August and I hope not all of us are on holiday so that a date/time can be decided soon. I guess that we will need at least an hour.

7. It seems to be extremely difficult to catch somebody from the aviation community to help us out producing a document particularly for that community. In the past Stewart has also tried to involve a person from BA but with the same result: too busy.

The only expert I can think of at the moment is Hans-Rudi. He might have the same problem but if we could find a supporting team of AMDAR Panel members he might be convinced. Your thoughts about the next steps are appreciated. We do need this document desperately.

8.  Under AMDAR Reporting Levels, two issues are relevant. One is Generic Software Specification and two is AMDAR software for E-jets.

Let me start with #2: first question is what type Embraer are we talking about? E-190? I am asking this because in E-AMDAR we have discussed the software development for the B777 (all B77s have Honeywell avionics) and it seems that the E-190 also has the same or similar Honeywell avionics and according KLM the specs for the B777 (are ready to be delivered to Air France as the requesting airline, KLM is the potential developer) are also applicable for the E-190.

On one, in the WIGOS PP for AMDAR we have decided to define the definition for the generic AMDAR software as a long-term activity. This was because we have to wait until the updated ARINC620 specs are adopted by the AEEC, which might take 1-2 years (will be much shorter than for the current ARINC620v4. That was a new definition and took 4-5 years. It was initiated by Jeff Stickland!).