The IXEG VNAV State of Affairs

[tkyler]

This is a lengthy post,  explaining our VNAV situation, or at the least, how we arrived where we are today, and where we're going from here.  This is a tale of how being too ambitious and trying to be all things to all people bit us and our customers. 

In the beginning was nav data in XML format....whether other formats were avail in the beginning, I don't know, I only know this was my beginning because I inherited the FMS work and this was the dataset that landed on my plate.   It was from Navigraph.  The first thing I did when I started was to open up a few XML files to get the lay of the land.  I noted several differing "types" of data like so:

and decided I needed to know every single type in the dataset so I could design algorithms around it.  So I wrote a program to go through all the files and log each unique occurence of a data type, i.e. "Star"  "Sid". "Sid_Transition", "Approach", etc.  After I had that list (because I couldn't find any spec), I set about programming the FMS....for a few years.  All was pretty well.  THEN....somewhere towards the end, we loaded up the same XML format dataset...but this time by Aerosoft, thinking "hey, lets support both providers, since there are plenty users of each". ...and for a while things were good; however,  we started seeing some issues related to the fact that Aerosoft had additional XML types that Navigraph didn't have...and for which I didn't have code to handle.  So I started throwing up 'band-aids' to get the Aerosoft dataset integrated....which would lead to some anomalies for Navigraph users...OK...a few more band-aids ought to do it.  And this went back and forth until I had all 10 fingers plugging up holes in the dike.   But turns out I needed a few more fingers....OR a more robust dike (hint...that's where this is going).   Over time, we'd see bug reports for navigraph users that aerosoft users weren't seeing and vice-versa.  Without exception though, the most obvious problem spot was in "decent FMS entries", i.e. STARS, Star transitions, etc.  Entering these procedures were frought with all sorts of bugs and gizmo crashes.   For online users who frequently enter these procedures in the air, as they approach their destinations, this simply was a deal killer.

So...fast forward to today when I'm revisiting the FMS code from a much higher level and seeing that these band-aids just didn't cover the wounds well enough.  So..case in point.  Here is how Aerosoft and Navigraph each represent STARs with runway transitions, specifically KBOS.

 

Aerosoft uses a data type "RwyTransition" to denote a runway transition waypoint, whereas Navigraph does not.  This is where things went south originally when we tried to support Aerosoft users late in our development process.  

Now when a user enteres a STAR, and no arrival runway has been selected, then you'd expect to load those waypoints in the STAR that are not unique to runways, i.e. "common points".  If you're using NAVIGRAPH, you will note that each XML "block" is associated with a runway.  So if no runway is selected, we have no way of knowing which block of code to load for navigraph users.  If you're using Aerosoft, then I can load the STAR waypoints only (and not the transition waypoints)....except all my code was written for the navigraph formats....and trying to make this work "last second" ended up causing more code confusion and debugging difficult.  If I had a bigger picture of all these types from day 1, I would have written better structured algorithms.

The good news, is I can see it better now and CAN write better structures; however,  better than both these XML formats is the XP1100 dataset that we plan to migrate to in the future.  But there is still more good news.  Looking at the code with clearer eyes and hindsight, I can see a few trouble spots that I can fix that should make this whole VNAV decent business improve significantly.   Indeed one or two poor lines of code can bring down the house and does for a few instantces of entering STARS / Transitions.

We are going to add a new message to the CDU, which is NOT realistic, but required in our opinion to avoid confusion.  If you select a STAR that is associated with a runway, or has runway transitions, we will display a message "RWY SELECTION REQD".    While Aerosoft has the necessary common points separated so as to load those without a runway selection,  recall my code was not orginally written for it, and so for the moment, I am not going to create a fork to handle it just yet.   Knowing we are switching to XP1100 navdata format,  I'll have to gauge the effort of accomodating Aerosoft's transition points differently than the Navigraph data vs the effort of just focusing on the XP1100 integration.  It could be, that accomodating Aerosoft's transition points is not so difficult...and in this case, a user could select a STAR and STAR transition without having an approach selected; however, Navigraph folks, we simply need to know the arrival runway before we can load up these "runway transition" STAR types.  For STARS that are NOT associated with a specific runway, but serve all runways,  this arrival runway selection is NOT required before STAR selection.  Many times users don't notice that the STAR they are selecting are unique to a runway (and subject to the case described here) and so in the course of their simming would see inconsistent behavior with STAR selection as they flew differing flights around the globe.  This "RWY SELECTION REQD"  message will let them know.

And finally....my code handling STAR transitions for these "runway transition" STARS was completely borked (by a poor band-aid), messing up the waypoint table and rendering any VNAV calcualtions / representation completely useless.   This is why some folks see good VNAV behavior and others do not.   It is dependent on which route your are flying, which STAR type you select and whether or not you selected a transition. 

I believe this CDU message will fix a lot in the interim, but ultimately the swap to XP1100 nav data format, with its consistency and basis in ARINC 429, will be our final and most durable solution.  

Aside from the issue described here, the other glaring issue is the waypoint altitude restrictions.  We will be attacking those soon enough and with clearer eyes, I expect to get this cleaned up also.

-TomK

 

 

 

 

 

Edited June 9, 2020 by tkyler

[SWA4420]

Hi TomK - for me, it's been all about the altitude restrictions.  If it says 18000A, it causes an extreme delay in descent for getting on glide.  If I code it to 18000, it tended to work better with the older version and stayed on glide a lot better after changing all Above to the specified altitude instead.  I've made a couple of flights since updating to 1.31, and it hasn't worked as well-->had to use VS to get to different altitudes necessary to get her back on terra firma, alternating with VNAV.

Best of luck with re-coding all this!
Jim

[tkyler]

Thx,   specific experiences / routes vs expectations regarding these altitude restriction issues are very good data points for me.  Thx for the input. 

-tkyler

[donoscar]

Thanks for the info Tom,

one major issue with the current VNAV profile happens when we have restrictions with below and above altitudes for one fix. It seems to be taking the higher restriction and simply convert it into an above one, ending of course in a very steep descent to catch up. I am sure you are already aware of it. While it forces me to precisely check my fpl against the charts and raises my situation awareness, most users I talk to are not aware and they tend to get frustrated after a while. hope it makes sense

cheers

Oscar

[okernel]

Thanks for making the effort to explain current limitations.  I do not pretend to understand a single word of it, but I do appreciate your desire to keep us informed.

Cheers

[evaamo]

Thanks for the informative post, Tom. Moving to the XP dataset seems like a winning choice. Won't ask ETAs! hehe

cheers

-E

[Torbinator]

Thanks for the details Tom.  In addition to the above reported altitude restriction blocks on STARS mentioned above,  some other odd behavior I noticed on STARs is that despite the speeds  for fixes over 10,000 often reading 280 kts in the CDU, I'd often see the speed cursor would set itself to 290 and the engines would periodically speed the plane up to about 300, then go idle till it slows to 260, then engines spool up again till we hit near 300, and repeat this behavior several times throughout the descent. Not sure how others have experienced this, but I figured I'd mention it.

[Litjan]

1 hour ago, Torbinator said:

Thanks for the details Tom.  In addition to the above reported altitude restriction blocks on STARS mentioned above,  some other odd behavior I noticed on STARs is that despite the speeds  for fixes over 10,000 often reading 280 kts in the CDU, I'd often see the speed cursor would set itself to 290 and the engines would periodically speed the plane up to about 300, then go idle till it slows to 260, then engines spool up again till we hit near 300, and repeat this behavior several times throughout the descent. Not sure how others have experienced this, but I figured I'd mention it.

Hi Torbinator,

I have seen the same (and stranger!) things with VNAV in descent. But I am pleased to report that Tom has implemented some coding changes related to STARs and it´s transitions (as posted above) that also seem to have a very positive effect on VNAV. I have done a few flights with VNAV descents, and I still see some quirky behaviour (mostly not adhering to the first of multiple AT restrictions), but overall the VNAV has become more predictable and more reliable and I am sure we can build on that and improve it further.

I am curious what you guys will report when flying the next (1.32) patch.

Cheers, Jan

 

[Tim013]

So, help me understand....Will the eventual move to the XP1100 format, remove the mandatory runway selection for navigraph users?

 

 

[Litjan]

7 hours ago, Tim013 said:

So, help me understand....Will the eventual move to the XP1100 format, remove the mandatory runway selection for navigraph users?

 

 

I think so - because there is an option to get Navigraph data in the XP1100 format, which forces to have different names for the "same" STAR, if it serves multiple runways (and has a different lateral path for each one).

Cheers, Jan

 

[disidd]

Add some of my observations.  As they all write, when straightened to a direct, the traction A/T up speed up to 292 knots, not responding to restrictions on altitude (250/10000) and speed, and this can only be fixed by switching off the A/T and A/P  In addition, I noticed a missed direct at the approach.  The plane instead of turning to the right is half a block straight.  LNAV and VNAV and A/P were activated. This happened for the first time in all the time I fly to IXEG. 

[Litjan]

We kow that VNAV  responese can become wrong. But your post shows me that you do not know how to fly the 737 in other modes. Please follow the tutorials on autopilot and autothrottle use and you will see that

6 hours ago, disidd said:

this can only be fixed by switching off the A/T and A/P 

is totally wrong.

6 hours ago, disidd said:

The plane instead of turning to the right is half a block straight.

needs some more explanation. Which airport, which approach? Can you provide a screenshot? We would like to see the case where the autopilot in LNAV is not following the magenta line, so we can fix it.

[Alpha Floor]

I don't know if this has been reported (haven't seen it), but something I experience often is that VNAV will not engage on departure because the altitude restrictions of the SID are not correct, or just blank with dashes. I don't know if the issue here lies with the AIRAC database, or the IXEG VNAV logic. To fix it I go through LEGS and hit the DELETE key, then right LSK on the "offending" restrictions. Once all are clear, the FMC populates the passing altitudes or flight levels and I can finally engage VNAV.

[mmerelles]

41 minutes ago, Alpha Floor said:

I don't know if this has been reported (haven't seen it), but something I experience often is that VNAV will not engage on departure because the altitude restrictions of the SID are not correct, or just blank with dashes. I don't know if the issue here lies with the AIRAC database, or the IXEG VNAV logic. To fix it I go through LEGS and hit the DELETE key, then right LSK on the "offending" restrictions. Once all are clear, the FMC populates the passing altitudes or flight levels and I can finally engage VNAV.

this is a known behavior of current vnav implementation, if you are planning to fly a SID/STAR having dual altitude contrains. i.e cross waypoint 123 below XXX and above ZZZ then the FMC will code invalid altitudes and prevent vnav from engaging.

 

It is important you delete those restrictions and re-enter them manually correctly until vnav code is redone.

[tkyler]

On 6/11/2020 at 5:45 PM, Tim013 said:

So, help me understand....Will the eventual move to the XP1100 format, remove the mandatory runway selection for navigraph users?

 

Many procedures are "mated" to runways.  On the Beoing 737 NG, if you select a runway that is not mated to a currently selected SID, you will get a message "RUNWAY N/A FOR SID:"  The FMC will then make that runway the selection, delete your SID waypoints and filter the SIDs list for you to select a 'matching' SID.   

Conversely if you select a procedure that is not mated to the currently selected runway, the message then reads:  "DEP N/A FOR RUNWAY" ...and the FMS again selected the SID, dumps any previous procedures and filters the runway list for you to select a mating runway,

We now simulate this behavior, as opposed to the "RUNWAY REQUIRED" message.   This situation can still exist with XP1100 data, depending on the procedures; however, it will be less common.

-tkyler

[Benweston]

I noticed that the aircraft wants to turn in the wrong direction with a handful of SIDS. Last night I tried the LORED 2B departure from Runway 13 at Malta. Instead of a right turn to 180 and then a left turn back to 360, the aircraft wanted to chop out the initial turn and just head for 360 which I’m sure would upset ATC. I flew it manually with HDG select but raw data single pilot procedures aren’t the easiest, anyone else run into this? 

[Litjan]

Hi Benweston,

I checked the SID. The reason for this is that our FMS assumes that you will accelerate to 250kts fairly quick. That is the reason for the BYPASS of waypoint D161D - the radius would be too large for it to make the turn without overshooting the calculated intercept point for the leg to the north...

I think the real FMS may do a bit better in this case (you can see how the route draws good before you ACTIVATE the route)...but this is a tough SID to fly for our FMS and therefore was not handled perfectly.

You did the right thing in flying it manually/HDG SEL, though. There are a few SIDs in real life that I always flew like that (DEGES2S in LSZH or SPI7C in EBBR) because it is more efficient. Others (DET2G in EGLL) must be flown in HDG SEL because the FMS would bust the first turn going too wide... So the pilot always has to monitor the performance of the automation, you won´t get away with a "but the FMS flew it that way! It is not my fault!"

Cheers, Jan

 

[Benweston]

39 minutes ago, Litjan said:

Hi Benweston,

I checked the SID. The reason for this is that our FMS assumes that you will accelerate to 250kts fairly quick. That is the reason for the BYPASS of waypoint D161D - the radius would be too large for it to make the turn without overshooting the calculated intercept point for the leg to the north...

I think the real FMS may do a bit better in this case (you can see how the route draws good before you ACTIVATE the route)...but this is a tough SID to fly for our FMS and therefore was not handled perfectly.

You did the right thing in flying it manually/HDG SEL, though. There are a few SIDs in real life that I always flew like that (DEGES2S in LSZH or SPI7C in EBBR) because it is more efficient. Others (DET2G in EGLL) must be flown in HDG SEL because the FMS would bust the first turn going too wide... So the pilot always has to monitor the performance of the automation, you won´t get away with a "but the FMS flew it that way! It is not my fault!"

Cheers, Jan

 

Thanks for the response Jan. Indeed don’t bet your licence on the FMC! : )