North Atlantic Waypoints
Thread Starter
Join Date: Jul 2000
Location: My views - Not my employer!
Posts: 1,032
Likes: 0
Received 0 Likes
on
0 Posts
North Atlantic Waypoints
So, t'other day we headed across the pond at 57N. Every waypoint was at 57N, so each waypoint in the confuzer differed by 1 number, and I thought this is why it's too easy to get a GNE.
So then I started to think (steady Cough!) why don't we use named waypoints over the Atlantic? I mean it's a long time since anyone had a navigator that did star shots and the Lat/Long needed to mean something... And named waypoints are quite common in the South Atlantic... So why persist with Lat/Long in the North Atlantic when they lead to so many GNE's?
(Promise to stop thinking pronto. Lockdown can't cope with thought...)
So then I started to think (steady Cough!) why don't we use named waypoints over the Atlantic? I mean it's a long time since anyone had a navigator that did star shots and the Lat/Long needed to mean something... And named waypoints are quite common in the South Atlantic... So why persist with Lat/Long in the North Atlantic when they lead to so many GNE's?
(Promise to stop thinking pronto. Lockdown can't cope with thought...)
Join Date: Mar 2000
Location: Scotland
Posts: 85
Likes: 0
Received 0 Likes
on
0 Posts
It’s a question that comes up regularly for this airspace .... notwithstanding the safety arguments for, and against, this approach as these can be assessed .... a key factor is often quoted as being the airborne database size necessary to hold all waypoints versus the fleet capabilities at any one time as there’s quite a lot of metal around that measures memory capacity in kb and mb, and not gb. There’s also logistical issues with separating the 5LNC points given the variety of city pairs here too and proximity of similarly spelled and sounding points at other ends of the NAT.
Also, bear in mind that this airspace is managed by the ICAO NAT Systems Planning Group .... they know very well how often a wrong coordinate is flown etc.
Finally, automatic systems are implemented that check your route using the confirm assigned route message, and a great deal of this airspace is surveilled using space based ADS-B with very frequent updates and route adherence checking (so ATC know before you enter the airspace that your route matches what they’re holding, and if you change route, track or level, they get an alert within seconds of it being input into the MCP - depending on ADS-B equipage - so that they can intervene).
Also, bear in mind that this airspace is managed by the ICAO NAT Systems Planning Group .... they know very well how often a wrong coordinate is flown etc.
Finally, automatic systems are implemented that check your route using the confirm assigned route message, and a great deal of this airspace is surveilled using space based ADS-B with very frequent updates and route adherence checking (so ATC know before you enter the airspace that your route matches what they’re holding, and if you change route, track or level, they get an alert within seconds of it being input into the MCP - depending on ADS-B equipage - so that they can intervene).
Thread Starter
Join Date: Jul 2000
Location: My views - Not my employer!
Posts: 1,032
Likes: 0
Received 0 Likes
on
0 Posts
It’s a question that comes up regularly for this airspace .... notwithstanding the safety arguments for, and against, this approach as these can be assessed .... a key factor is often quoted as being the airborne database size necessary to hold all waypoints versus the fleet capabilities at any one time as there’s quite a lot of metal around that measures memory capacity in kb and mb, and not gb. There’s also logistical issues with separating the 5LNC points given the variety of city pairs here too and proximity of similarly spelled and sounding points at other ends of the NAT.
Also, bear in mind that this airspace is managed by the ICAO NAT Systems Planning Group .... they know very well how often a wrong coordinate is flown etc.
Finally, automatic systems are implemented that check your route using the confirm assigned route message, and a great deal of this airspace is surveilled using space based ADS-B with very frequent updates and route adherence checking (so ATC know before you enter the airspace that your route matches what they’re holding, and if you change route, track or level, they get an alert within seconds of it being input into the MCP - depending on ADS-B equipage - so that they can intervene).
Also, bear in mind that this airspace is managed by the ICAO NAT Systems Planning Group .... they know very well how often a wrong coordinate is flown etc.
Finally, automatic systems are implemented that check your route using the confirm assigned route message, and a great deal of this airspace is surveilled using space based ADS-B with very frequent updates and route adherence checking (so ATC know before you enter the airspace that your route matches what they’re holding, and if you change route, track or level, they get an alert within seconds of it being input into the MCP - depending on ADS-B equipage - so that they can intervene).
The following is just opinion of course...
The database size is I think a red herring. All the waypoints used are effectively waypoints in our databases anyhow, so to change '5650N' to 'WHALE' or similar wouldn't take any extra storage. But going to the named waypoints I think has some good benefits...
Data Entry - One night, I listened to an A380 who'd clearly made a data entry error going on to PBCS track be refused entry onto the track by Gander as they were headed to the wrong waypoint. I think they were headed for something like 56N050W and they should have been going to 5630N050W. Looking later on flightaware the aircraft took 3 (+?) large loops prior to getting it right. I felt for the Gander controller in this instance for having to deal with it (he was v.good) but also for the crew because the database doesn't help in these circumstances - If their's was like ours, then 56N050W is 5650N and 5630N050W is N5650 (I think!). See how easy that is to mess up? (we are encouraged upon reroutes to use the full lat/long rather than these short codes...) If the Gander Domestic controllers or Shannon controllers think we always forget to mention the '30minute part' when manually reading back the next waypoint when going oceanic on a PBCS track, that's why. You look at the waypoint name in the FM(G)C and it just doesn't say '30minute' to us... A waypoint name would be so much easier, and less RT.
Next is capacity - We can't take a reroute to a 30minute PBCS track unless the route is datalinked to us. If the points were named and thus the chances of data entry minimised, then we probably then would be able to. When the capacity gets going again, wouldn't that be useful?
It's late, think that's enough thinking for now! Thanks for engaging...
Join Date: Apr 2009
Location: UK
Posts: 489
Likes: 0
Received 0 Likes
on
0 Posts
How resilient are your SOPs for crossing the ocean? Ours typically start in the office. We print out paper copies of the flight plans (LIDO generated) and check the route to the track message (if on a published track), checking its validity etc. Onboard we use acars to download the flight plan into the fmgc. each pilot will independently check the flight plan routing to the box and vice versa. If there is time available before we push we will check the lat/longs of the oceanic waypoints from the fmgc (selecting each one in turn) to the flight plan. The flight plan gets various company prescribed annotations beside each waypoint to show this was done. Once we are settled in the cruise and well before we enter the ocean if we haven't checked the lats and longs then we do that. Then we check the track and distance between each waypoint from the fmgc to the flight plan. We also have procedures for checking the OCX to the fmgc. If we get a track change then a new flight plan is sent to use onboard from operations so we can do all the above checks and balances. As as approach a waypoint we will double check the next waypoint (belts and braces as it was checked earlier) and call it out to the other pilot along with the track and distance. We have a standard call of the pfd and ND as we go over the waypoint and we log various things as we do. As a further protection against a GNE we check 2 degrees after waypoint passage that we are on the intended track. We used to use a paper plotting chart for this and occasionally still do if the EFB isn't working for whatever reason. The EFB is a hell of a lot more accurate than the paper plotting charts ever were and gets the own ships position from the aircraft. The final backstop is CPDLC with its automatic position reporting.
Join Date: Nov 2018
Location: Bonvoy Marriott
Posts: 408
Likes: 0
Received 0 Likes
on
0 Posts
How resilient are your SOPs for crossing the ocean? Ours typically start in the office. We print out paper copies of the flight plans (LIDO generated) and check the route to the track message (if on a published track), checking its validity etc. Onboard we use acars to download the flight plan into the fmgc. each pilot will independently check the flight plan routing to the box and vice versa. If there is time available before we push we will check the lat/longs of the oceanic waypoints from the fmgc (selecting each one in turn) to the flight plan. The flight plan gets various company prescribed annotations beside each waypoint to show this was done. Once we are settled in the cruise and well before we enter the ocean if we haven't checked the lats and longs then we do that. Then we check the track and distance between each waypoint from the fmgc to the flight plan. We also have procedures for checking the OCX to the fmgc. If we get a track change then a new flight plan is sent to use onboard from operations so we can do all the above checks and balances. As as approach a waypoint we will double check the next waypoint (belts and braces as it was checked earlier) and call it out to the other pilot along with the track and distance. We have a standard call of the pfd and ND as we go over the waypoint and we log various things as we do. As a further protection against a GNE we check 2 degrees after waypoint passage that we are on the intended track. We used to use a paper plotting chart for this and occasionally still do if the EFB isn't working for whatever reason. The EFB is a hell of a lot more accurate than the paper plotting charts ever were and gets the own ships position from the aircraft. The final backstop is CPDLC with its automatic position reporting.
Just because we're in this century doesn't mean that all of the aircraft flying today are. No doubt things will change eventually but not just yet.
Most 5 letter waypoint names are already repeated multiple times all over the world which could lead to errors. Lat and long can't be.
Sops should be robust enough to check waypoints accurately - there aren't many of them and you've got plenty of time.
Thread Starter
Join Date: Jul 2000
Location: My views - Not my employer!
Posts: 1,032
Likes: 0
Received 0 Likes
on
0 Posts
MCDU2 - Our SOP's sound very similar. I'm just very paranoid to ensure that I get it right first time!
Not misunderstood. If I'm routing across at 58N, then 6940N is still in my database. In fact all the points are as I've tried many waypoints NOT on my flight plan.
Not misunderstood. If I'm routing across at 58N, then 6940N is still in my database. In fact all the points are as I've tried many waypoints NOT on my flight plan.
Join Date: Mar 2014
Location: Way north
Age: 47
Posts: 497
Likes: 0
Received 0 Likes
on
0 Posts
At least in the North Atlantic when reporting a position on the frequency, you also have to give next waypoint with an estimate for it and the following as well, so it's relatively easy to pick up when you are off track.
I'm not sure about the data sent via datalink, ADS-C and ADS-B though, but with ADS you can monitor if an aircraft is off track.
One more thing to consider, many routes are created based on winds at altitude, and those winds change over the day/year.
I'm not sure about the data sent via datalink, ADS-C and ADS-B though, but with ADS you can monitor if an aircraft is off track.
One more thing to consider, many routes are created based on winds at altitude, and those winds change over the day/year.
Join Date: Nov 2018
Location: Bonvoy Marriott
Posts: 408
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Mar 2000
Location: Scotland
Posts: 85
Likes: 0
Received 0 Likes
on
0 Posts
Database size is often quoted by airline association representatives as being a factor. Your description of how ARINC424 has the potential to confuse pilots is well known by ATC and aircrew alike, and the user interface into the FMS often doesn’t help - I empathise, totally !
I agree that direct entry datalinked coordinates would be helpful, but again many airborne systems can’t accept that and the scale of human change to get pilots to accept a third party directly entering data into the FMS means this isn’t coming quickly either. Though many agree it’s the direction of travel for us all, for this and other reasons UM137/DM40 are used to check what’s in the FMS is correct as it’s quicker, less prone to error (human and ATC loop errors), and provides a faster way to intervene should errors occur. It also provides great data to determine the prevalence and impact of the types of error you described with Gander. This was a solid base is for the mandating of FANS on the NAT, though a solid financial impact analysis also deemed it beneficial too.
Some other food for thought .... ARINC424 manages 30minute increments of latitude and, currently, NAT flights report at 10 degrees of longitude. It’s relatively easy to calculate the number of extra positions that would need to be defined, loaded and tested in every CFP and ATM system. ATC will try to remove organised tracks in future and, generally, make NAT airspace more fuel efficient and predictable to fly in (I’ll try to cleverly add an image posted by Aireon of NAT airspace ... look at all the rhombus shaped black bits ... they reflect airspace inefficiency due to historical flight planning and ATC separation constraints and evidence my point).
Doing this may mean flights report at different longitudes (every other meridian, or perhaps twice as often, and every 5 degrees of longitude), plus new ATC separation standards may benefit from a 15minute increment of latitude too ... so the number of named points may increase substantially with few being commonly used, as they’re all there for airline flexibility. So yI’m could be argued that the problems with naming every point get bigger whilst the benefits of doing so get smaller ... never a good foundation for the business case to change. (Safety is key, we’d all agree too, but I don’t believe we currently have a material NAT safety problem that this would prove to be a/the solution for, so I’ve not argued that point).
if I may offer a personal thought around this .... there are many suggestions that propose ‘organic’ improvements to what’s there already in the NAT that appear logical and practical and seek to be helpful. In my experience, they chase a line of diminishing return as they struggle to keep pace with traffic growth and safety events (COVID excluded, of course). It’s been my experience that finding new, more transformational, ways to achieve the performance and environment needed, rather than tinkering with the old ways, gets better, and more sustainable results. In this respect, leading NAT ANSPs are likely to take things in the latter approach, progressing only the former for short term actions with a quick/short hit is attractive.
I hope this explains why we are where we are ... it doesn’t make other views wrong as I sense we all want a safe, easy and efficient system that helps get us to where we want to go (!)
I agree that direct entry datalinked coordinates would be helpful, but again many airborne systems can’t accept that and the scale of human change to get pilots to accept a third party directly entering data into the FMS means this isn’t coming quickly either. Though many agree it’s the direction of travel for us all, for this and other reasons UM137/DM40 are used to check what’s in the FMS is correct as it’s quicker, less prone to error (human and ATC loop errors), and provides a faster way to intervene should errors occur. It also provides great data to determine the prevalence and impact of the types of error you described with Gander. This was a solid base is for the mandating of FANS on the NAT, though a solid financial impact analysis also deemed it beneficial too.
Some other food for thought .... ARINC424 manages 30minute increments of latitude and, currently, NAT flights report at 10 degrees of longitude. It’s relatively easy to calculate the number of extra positions that would need to be defined, loaded and tested in every CFP and ATM system. ATC will try to remove organised tracks in future and, generally, make NAT airspace more fuel efficient and predictable to fly in (I’ll try to cleverly add an image posted by Aireon of NAT airspace ... look at all the rhombus shaped black bits ... they reflect airspace inefficiency due to historical flight planning and ATC separation constraints and evidence my point).
Doing this may mean flights report at different longitudes (every other meridian, or perhaps twice as often, and every 5 degrees of longitude), plus new ATC separation standards may benefit from a 15minute increment of latitude too ... so the number of named points may increase substantially with few being commonly used, as they’re all there for airline flexibility. So yI’m could be argued that the problems with naming every point get bigger whilst the benefits of doing so get smaller ... never a good foundation for the business case to change. (Safety is key, we’d all agree too, but I don’t believe we currently have a material NAT safety problem that this would prove to be a/the solution for, so I’ve not argued that point).
if I may offer a personal thought around this .... there are many suggestions that propose ‘organic’ improvements to what’s there already in the NAT that appear logical and practical and seek to be helpful. In my experience, they chase a line of diminishing return as they struggle to keep pace with traffic growth and safety events (COVID excluded, of course). It’s been my experience that finding new, more transformational, ways to achieve the performance and environment needed, rather than tinkering with the old ways, gets better, and more sustainable results. In this respect, leading NAT ANSPs are likely to take things in the latter approach, progressing only the former for short term actions with a quick/short hit is attractive.
I hope this explains why we are where we are ... it doesn’t make other views wrong as I sense we all want a safe, easy and efficient system that helps get us to where we want to go (!)
Thread Starter
Join Date: Jul 2000
Location: My views - Not my employer!
Posts: 1,032
Likes: 0
Received 0 Likes
on
0 Posts
Great post RT - Thankyou.
As a man who has seen seen the benefits of getting a third party to enter the route for him I'm hopeful that the future can involve this tech. If that became routine for entering the clearance through the NAT in my book that would just be fantastic. Interestingly, it would probably swing away from the ARINC waypoint format to just using LAT/LONG which I see as a bonus.
CPDLC route entry above was shown when ATC invoked a ground stop due TS so we shut down in the deice bay in BWI one summer - The controller there zapped 3 different (and complex!) routes to us via CPDLC inside 3 minutes which placed the route on the ND alongside the weather radar returns - Ground stop resolved, we started again and got going - Simply stunning use of technology.
MIX of LAT/LONG vs ARINC entries. As you've guessed by default we get the ARINC format uploaded. When we get a direct to a waypoint on the Atlantic (quite usual for Gander to give direct to 50W) then that comes up as a direct to a lat/long and the FMC offers you a 'load' button to load that into the route. But as the FMC doesn't recognise the similarity between that point and the ARINC point you then get a break in the route that needs resolving. If the route was uplinked as the clearance (as lat/long), then this would never need resolving which would be fab... Even if all aircraft can't accept the route, to have the facility to send it to those that can would be awesome...
As a man who has seen seen the benefits of getting a third party to enter the route for him I'm hopeful that the future can involve this tech. If that became routine for entering the clearance through the NAT in my book that would just be fantastic. Interestingly, it would probably swing away from the ARINC waypoint format to just using LAT/LONG which I see as a bonus.
CPDLC route entry above was shown when ATC invoked a ground stop due TS so we shut down in the deice bay in BWI one summer - The controller there zapped 3 different (and complex!) routes to us via CPDLC inside 3 minutes which placed the route on the ND alongside the weather radar returns - Ground stop resolved, we started again and got going - Simply stunning use of technology.
MIX of LAT/LONG vs ARINC entries. As you've guessed by default we get the ARINC format uploaded. When we get a direct to a waypoint on the Atlantic (quite usual for Gander to give direct to 50W) then that comes up as a direct to a lat/long and the FMC offers you a 'load' button to load that into the route. But as the FMC doesn't recognise the similarity between that point and the ARINC point you then get a break in the route that needs resolving. If the route was uplinked as the clearance (as lat/long), then this would never need resolving which would be fab... Even if all aircraft can't accept the route, to have the facility to send it to those that can would be awesome...
