CPDLC UM79 and UM 80 messages - autoloading of route amendments

[richjb]

Hello Hardy,

I am reviewing the FAA's Data Comm User's Guide and using PSX to work my way through some of the uses of Enroute CPDLC coming to the US in the next year and half.   While reviewing the UM79 CLEARED TO [position] VIA [route clearance] and the UM80 [route clearance] messages, the FANS and FAA document says that these uplinks should automatically load the revised routing into the FMC's ROUTE and LEGS pages for the crew to review and EXEC.  I tried experimenting this with PSX, but couldn't get the route changes to appear in the ROUTE and LEGS pages.  Is this "auto-load" feature implemented in PSX's CPDLC engine?  Or, does the user need to enter the route modifications into the FMC ROUTE or LEGS page manually?

Thanks!

Rich Boll
Wichita KS 

[Hardy Heinlin]

Hi Rich,

autoload is only modeled via the route request key on the RTE page; you need not enter a company route name on the RTE page if you select a default route on Instructor > Situation > Human > Dispatcher with the buttons in the middle of the Dispatcher page. When a default route is set, this route will always be uplinked when the pilot downlinks a route request. Other features are not modeled.


Regards,

|-|ardy

[richjb]

Thanks Hardy,

The LOAD prompt appears on the ATC UPLINK page above ACCEPT when a UM79, UM80, and UM83 route/route modification is uplinked. 

As this is an important part of the FANS system, especially as model US Enroute CPDLC operations.  In fact, with current policy auto-load of UM79, UM80, and UM83 route modifications is mandatory for participation in US Enroute CPDLC.

Would it be possible to place this on a feature request list for future implementation in PSX?  Understand that it won't be added tomorrow. 


Thanks again for answer my question and consideration of my request for adding CPDLC ATC UPLINK LOAD capability.

Best regards,


Rich Boll
Wichita KS

[Hardy Heinlin]

It's been on my todo list already. But the list never gets shorter as real-life technology progresses as well, so it will take a very long time ...

(It's not just about the FMC feature itself, I also need to design a tool on the CPDLC console so that the instructor can build a route for uplink.)


Regards,

|-|ardy

[richjb]

Thanks Hardy!

I sympathize with you.  The "to-do" list keeps getting longer, yet no one ever thinks to add more hours to the day!


Thanks for the reply and for the information.  PSX is still a great tool for practicing and learning about CPDLC and FANS!


One more question on FANS.  Im not completely familar with the Boeing FANS implementation, but is there any way in PSX to set the FANS settings like latency monitor?


Thanks,


Rich Boll

[Hardy Heinlin]

Do you mean settings for physical latency effects outside the FMS and the ground console -- or settings for latency monitoring functions inside the FMS and the ground console?

Either way: Nope ... I'm sorry.


|-|ardy

[Jeroen Hoppenbrouwers]

The Latency Monitor is part of FANS-1/A+ (notice the +). It is an extremely useful feature that is NOT found on many aircraft...

To really get down to this detail, you won't just need FANS on the FMS and a fully-fledged FANS console for the instructor (who then turns into a virtual ATC), but also a not-perfect delivery mechanism of the messages so that the latency timer actually can trigger. I believe this is outside the scope of PSX.

If my real world work would not take up all time doing these things I would gladly jump in and bring my existing (very old) FANS stuff over to natively integrate with PSX... but...


Hoppie

[richjb]

Hoppie & Hardy,

Thanks for the reply.  What I'm referring to is the recent NAT FANS message assurance requirement to set the max uplink delay value to 300 seconds.  This can result in ATC uplinking the CPDLC free text message SYSU-6 (UM169) SET MAX UPLINK DELAY VALUE TO [delayed message parameter] SECONDS to prompt the pilot to enter the specified latency value into the aircraft avionics (refer to the Global Operational Data Link Manual (GOLD) ICAO Doc 10037 Appendix A table A.4.13).  The underlined text is copied from a recent NAT Ops Bulletin.  These messages started in May of 2018.


I don't know a thing about the Boeing FANS implementation. I barely understand the Collins FANS system in the CL300 that I fly.  So my question is whether manually setting the latency monitor is a function of the Boeing B744 FANS implementation and if so is it modeled in PSX?

Sorry for so many questions.  I'm trying to learn how to use all this stuff while safely on the ground!

Thanks again,


Rich Boll

[Jeroen Hoppenbrouwers]

As far as I know (I am certainly not THE specialist) this delay timer is to avoid a situation such as happened a year ago with the Iridium subsystem.

http://flightservicebureau.org/iridium-fault/

After years of operation it turned out that the 24-hour message buffer maintained by the ground station would work as designed if pushed hard enough. An aircraft system had been left off for so long that when it pulled out all waiting messages after re-activation, it got at least one that was from a previous flight. Nothing in the airborne part of the FANS system was able to deduce that the message was older than a few minutes and thus operationally irrelevant. FANS was not designed with long-running slow message transfers in mind -- the thinking was near-instant, no buffering. A major oversight in FANS design, not really in Iridium's delivery mechanism. Don't trust your radios, they are too stupid.

The issue was solved by running a deletor query over Iridium's ground database every four minutes, killing off pending messages that had already been expired after three minutes by their originators, but that were not being canceled downstream by those originators (the real bug, in my opinion).

Later FANS implementations, with the "+" mark, have this latency timer that can drop and ignore messages sent by ATC more than n seconds ago. Unfortunately the system only works if both all ground stations support it (most do, all in the USA do) *AND* all airplane stations, and most don't as they don't have the right software load. Changing this software is technically not that hard but commercially very expensive, basically you need to upgrade your whole FMS and most related boxes. So few airlines do it. And if one aircraft does not have it, the problem of accidentally responding to a day-old message remains.

As far as I know, this timer therefore guards the system itself, to assure that it will not show pilots messages that originated at ATC more than n seconds ago. It is not something that, for example, warns somebody if they don't respond quick enough. That was always part of FANS. This one is just for the underlying message transport protocol.

And if PSX wants to implement this, it would need a field on the instructor FANS console "intentionally delay this message so long that it would not reach the plane in time". The plane then would drop it. The pilot would never see it, or at best receive a message that a message was dropped.


Hoppie
pretty sure about all this but not 100% so any comment welcome

[richjb]

Thanks Hoppie!

Great explanation about the Iridium issue from last year.  I remember that one and the fuss that it caused with FANS CPDLC.  I never found a good explanation on how to fix it.


During our Rockwell Collins FANS training, I recall being able to get into the FMS pages to set the latency timer as directed by the NAT guidance.  I was wondering if the Boeing 744 FANS implementation had a similar feature in the FMS that the pilots could change.  It doesn't sound like that is the case and the crew should reply "UNABLE" to the Free Text request in the NAT. 


More stuff to learn!

Thanks again!

Rich Boll

[Jeroen Hoppenbrouwers]

Got this straight from the source today (FAA/industry meeting at Boeing this week):

The CPDLC latency function must be manually activated by the pilots, the default is zero seconds. The agreed trigger message, which is usually automatically sent to aircraft logging onto the CPDLC system where this latency is in use, is the free text message UM169: SET MAX UPLINK DELAY VALUE TO [X] SECONDS.

Boeing normally displays a late message with "uplink latency exceeded" as a warning note.

Airbus suppresses the display and returns a warning to ATC:
DM62: ERROR INVALID DATA
plus
DM67: UPLINK DELAYED IN NETWORK AND REJECTED / RESEND OR CONTACT BY VOICE.

Boeing airplanes keep the latency setting when handover to another center occurs; Airbus airplanes drop it (reset back to zero).

On Airbus aircraft, there is an issue when CPDLC messages get to the aircraft Really Fast, which can only be achieved on VDL mode 2. This typically happens near Iceland. The issue is that the latency function triggers while it shouldn't and rejects the totally correct message.

Programmers will love this:
When the board clock is one second behind the ground clock, this causes a reception of a message sent at, say, 12:00:00 at 11:59:59 which is considered a latency of just under 24 hours and thus causes a reject.
There is no date in the CPDLC time stamp!
There is no subsecond information in the CPDLC time stamp!

Airbus solution: 2-second tolerance to avoid small clock sync errors. Takes 2 years to implement, more to roll out.
New Zealand solution: add two seconds of delay to each uplink. Works like a charm.


Hoppie

[richjb]

Hi Jeroen,

You must have been at the PARC CWG meeting today.  I participate in the PARC PCPSI and PARC NAV WG for NBAA.  I don't believe the organization had anyone covering that meeting, unfortunately.

I found out that our Challenger 300 will automatically set the latency timer to uplinked value when the pilot ACCEPTs the UM169 message; however, that's not true will all installations.

Some of this stuff is getting really, really complicated!

Thanks, and enjoy Seattle!

Rich

[Hardy Heinlin]

Got this straight from the source today (FAA/industry meeting at Boeing this week):

The CPDLC latency function must be manually activated by the pilots, the default is zero seconds. The agreed trigger message, which is usually automatically sent to aircraft logging onto the CPDLC system where this latency is in use, is the free text message UM169: SET MAX UPLINK DELAY VALUE TO [X] SECONDS.

UM169 may be the message type you can find on the PSX CPDLC menu under "Miscellaneous" > "FREE TEXT". This is the last menu item at the very end of the CPDLC console.

But then we still don't know what the FANS-1 crew would do when they get such an uplink message.

[Hardy Heinlin]

Regarding the "route request" message again ...

Before I start refreshing all my brain cells, here's a quick question to refresh five of them:

When you go to the ATC ROUTE REQUEST 4/4 page of the FMC and select RTE1 at line 3L or RTE2 at 3R, and then verify and send the request as usual, what will you expect to happen?

Will a route be uplinked by ATC in the same way as it would be uplinked by the airline? That is, you will go to the FMC RTE page and see the usual effects and options just as if you got a route uplink from your company?

If so, I might provide an easy solution: The simulated CPDLC ATC will just use the same route archive that the simulated dispatcher uses. For training scenarios, a "CPDLC route" may be created before the flight using the FMC for route programming, and that "CPDLC route" may then be archived as usual (like a company route) in the Aerowinx/Routes folder. The simulated CPDLC ATC can at any time select a default route from that folder for uplink.


Regards,

|-|ardy

[mark744]

Got this straight from the source today (FAA/industry meeting at Boeing this week):

The CPDLC latency function must be manually activated by the pilots, the default is zero seconds. The agreed trigger message, which is usually automatically sent to aircraft logging onto the CPDLC system where this latency is in use, is the free text message UM169: SET MAX UPLINK DELAY VALUE TO [X] SECONDS.

UM169 may be the message type you can find on the PSX CPDLC menu under "Miscellaneous" > "FREE TEXT". This is the last menu item at the very end of the CPDLC console.

But then we still don't know what the FANS-1 crew would do when they get such an uplink message.

Sorry to jump backwards in the topic:
The MAX U/L DELAY is set by LSK 4L  in this version of ATC LOGON/STATUS page

[Hardy Heinlin]

Thanks!

Has the ADS stuff been moved to page 2/2?

What does the "ATN" mean in "ATN READY"?


|-|ardy

[mark744]

Yes, now page 2



ATN= Aeronautical Telecommunication Network

Mark

[Hardy Heinlin]

Any comments from pilots at other airlines? Do all airlines have this new LOGON page design?

Another question: What's the difference between "READY" and "ATN READY"?


Edit: I think this new LOGON design comes with the NG 744 FMC package.

[Hardy Heinlin]

Back to the "RTE REQUEST" function: I read various manuals in the past and the descriptions were always brief and vague. They say when the RTE 1 key at 3L is pushed, the route stored in RTE 1 will be selected for route request. I don't understand this language. It sounds like the pilots send their route to ATC. When the crew requests a route that is already stored in the RTE 1 memory, why should they request it if they have it already? My interpretation in my language would read:

"When the RTE 1 key at 3L is pushed, ATC will uplink a route to be loaded into the RTE 1 memory."

Is my interpretation correct?

The effect would be the same as pushing the RTE REQUEST key on the RTE 1 page. The airline will uplink a route to be loaded into the RTE 1 memory. The scratchpad message will be ROUTE 1 UPLINK READY, and it can only be loaded into RTE 1, not RTE 2 in this example.


And the manuals also say: "When RTE 1 has a pending modification, the modified route is requested." This again sounds like a route will be sent from the aircraft to ATC, in this case the modifed route will be sent to ATC.

If the crew gets a route from ATC to be loaded into the RTE 1 memory while RTE 1 is active, the load process will first load it into the MOD RTE memory anyway. It will only be copied to the RTE 1 memory when the EXEC key is pushed.


|-|ardy

[Jeroen Hoppenbrouwers]

Another question: What's the difference between "READY" and "ATN READY"?

The Aeronautical Telecommunication Network (ATN) is an extra layer over basic block messaging (Plain Old ACARS), which was/is/should be the new standard for datalink. It is invisible to pilots, it is what IP is for Ethernet, so to say. However the industry is slowing down ATN and moving to IP for obvious reasons. ATN is a 1980-s OSI layer model thing.

Simplified, if you are on VDL mode 2, or on new Inmarsat, you're on ATN. Else, you're on POA.

I am pretty sure we're looking at the NG box for all these things.


Hoppie