Maestro 2019 through the eyes of Naviair 2019

After med MUG 2019 I got some ideas to bring into the testing and research of the Maestro product.


- Optimisation of the climb profile

- Use Mf as or along with feeder fix, to achive the benefit of metering fixes

- Try to get rid of certain delay/gain values (this was done in cooperation with the Maestro team, prototyping)

- Try to have the TopSky ATC to control the runway for a specific aircraft within Maestro (this was done in cooperation with the Maestro team , prototyping)

- Trying to optimise the actual sequence (this was driven much by the introduction of a FAST concept for COOPANS which later has been descaled)

- Trying to define runway detection zones that actually can warn the controller in a timely manner and without nuisance alerts

- Using the parameter "Coupling Airports" to avoid certain processing before the TP in Maestro has got the flight detected.


Climb profile :


We tried to optimise our dataset parameters as much as possible but we need some change in the coding from Thales before we have reach our goal. We need the climb profile calculation to know the RFL from the flight plan and we need the climb profile algorithm to allow some detection at the same level without determining that the aircraft is at level. This last part is especially seen with departing turbo prop traffic that often for a short while will level out to gain speed and the current algorithm will determine that the aircraft has gone to cruise phase if 2 radar updates contain the same altitude. Furthermore the problem occurs if the aircraft is cleared an intermiate level due to other traffic then the RFL must be used as comparison to determine if the aircraft is at cruise. This is by Naviair considered as a "Quick Win"


MF to act as FF :


These trials were a bit harder to get success with since some groundpilars need to change. First of all the Maestro team has to implement some coding that give the MF the same possibilities as FF eg. make an MF-Overfly condition as for the FF. Furthermore it is our clear suggestion that it should be possible to offline define if FF or MF should be used for reference for the ACC delay. This feature already exists in the I4D prototype Aman product. Then for an HMI point of view the settings of the MF need to be visible and accessible from the main HMI header as is the case for FF. This is again by Naviair considered as a relative "Quick Win"


Hide certain array of delays or gains :


This trial was probably specific COOPANS related since we wanted to hide certain array of delays to be distributed to the label as TTL/TTG. A prototype was developed by the Maestro team and it was partly successfull but there was some major flaws that could not make the feature work in reality, we are back at the drawing board with that issue. Still I would like to address that we touched an issue related to this during the MUG last year with the Delay advisories : Color coding of the delay or gain. We would also like to have the ability offline to define when the rounding should be applied, pr. 30 seconds or pr. 1 minute!


One runway input into the systems :


From a Naviair perspective we always have a setup with parallel runway where 1 is for departures and 1 is for arrivals therefore in the Aman dataset I have always defined 100% designation to a certain runway in all my runway conditions. However we still have the option to tactically move an arriving aircraft to another runway (opposite, parallel or crossing) but this is alway done by the controller under a certain set of conditions and is often done at a relatively late stage seen from Aman perspective. What controllers forget is to input the runway change for a specific aircraft into multiple systems (TopSky ATC, Aman, Tower System etc.) My controlles always correct the runway in TopSky ATC (this is where is makes mst sence to our setup) and tend to forget to update subsystems. In our case when the Aman is not updated with an aircraft going to another runway than designated in Aman then a trigger to activate the estrip in the tower system is not activated hence the tower controller is missing the flight in his finale strip bay! To get around this I suggested to Thales if they could provide me with a prototype that would allow this feature In_Qfu_Allocation_Mode = FALSE to work in all states then the Aman inherits the runway from the TopSky ATC in my case. This solution works perfectly in my case, now I am just waiting to get an official release with this feature. While we are waiting for this release we have started to do some trials on the "runway detection" feature to highlight to the controller if an aircraft is flying towards a runway that is different from the Aman designated runway , it is still in the testphase.


Actual Sequence :


Naviair has provided Thales with plenty of ideas to solve this issue and correct the flaws/errors detected by Naviair - status of this is unknown.


Coupling Airports :


In Naviair we, as you probably know, use TP from Aman. This allow us to use some strong tools to manipulate/optimise the sequence to fit reality. The feature "Coupling Airports" has it's forces with traffic rather close to the airport. Instead of starting to process the flight based of an event from the flightplan we simply tell the Aman not to process flights from a coupling airport before the flight is radarcoupled and detected by TP. This is a strong feature that need to be used with caution since the effect can be both positive and negative depending on the point of view from the user. In my latest case I have activated EDDH (Hamburg) as a coupling airport meaning that I do not want Aman to process such flight before radarcoupling, this is in my case done to avoid too early stabilisation of the aircraft which often occured since the flightplan was activated with not fully updated estimates then the flight would become stable based on wrong estimates.