4
$\begingroup$

Ground Based Augmentation Systems broadcast message four, the Final Approach Segment, along with corrections for GNS signals in messages one and two. Since the FAS is essentially a semi-static approach plate, it seems like it could be distributed by subscription along with all the other info in a flight database instead of wasting VHF link bandwidth as it does. In fact, the Satellite Based Augmentation System uses the flight database subscription method.

For SBAS, the FAS data block is stored in the aircraft’s navigation database, while for GBAS the FAS data block is broadcast as a VHF data message.

What was the purpose for the GBAS design choice? It is impossible for the SBAS system to do this, but once the less constrained method was established, it seems like both systems should use it.

$\endgroup$

2 Answers 2

6
$\begingroup$

The reasons GBAS and SBAS are the way they are goes back to decisions made in the early 1990's when the concepts were first proposed. When the push started for satnav approaches it was obvious that augmentation was necessary to meet the accuracy and integrity needed for approach procedures. The FAA tasked RTCA to develop the standards and that was delegated to Special Committee 159 (SC-159).

SC-159 is a very large committee with representatives from government agencies, airlines, aircraft manufacturers, general aviation, avionics suppliers, and pretty much anyone with an interest in the system. Because of the huge amount of work and the differing systems the work was broken out to separate subcommittees. So while there were some people working on both subcommittees, the subcommittees each took there own path.

GBAS was being promoted by the FAA to be a functional replacement to ILS with support for CAT I and eventually CAT II/III operations. This needed support of the airlines who were only willing to go along if it didn't add significantly to their costs (preferably it would provide capability where ILS wasn't feasible and give them additionally capability at little to no cost.) So a fundamental goal of GLS was to be as operationally similar to ILS as it could get - minimal crew training, minimal aircraft system changes.

That last bit is key as the ILS is a DAL A system tied to the autoland system which is very expensive to certify. The avionics solution to this is the multi-mode receiver (MMR), ref: ARINC 755. The MMR allowed for retrofit as it occupied the same package as the legacy ILS receivers.

The MMR added a GPS sensor (which wasn't standard in the early 90's) and it allowed for integration with the ILS and its interfaces. The first MMRs were just and ILS and GPS sharing a box. But later versions added a precision approach navigator (PAN). The PAN could use the ILS output busses to provide the "ILS Look-Alike" output. But the GPS needs the augmentation data. This is broadcast from the GLS ground station on a VOR/ILS frequency. So the ILS receiver (a software defined radio) is repurposed in GLS mode to receive and decode the VHF data broadcast (VDB) from the ground station. It can then provide the augmentation data to the GPS and the FAS data to the PAN.

The reason for the FAS data being broadcast and not being in the nav database is that database is located in the FMS, not the MMR and the FMS is not a DAL A system. It also follows the concept that the ILS/GLS is a stand-alone unit that can support a precision approach even if other systems have failed.

Conversely, SBAS was pretty much ignored by the airlines (they only added WAAS GPS receivers when ADS-B drove the need.) SBAS was championed by the general aviation community that want RNAV approaches into airports that didn't have good approach options - no ILS, maybe a VOR or NDB approach. An RNAV approach was a big step up. Due to the large number of small airports that desired the capability, SBAS was more cost-effective than a GBAS approach. It was also cheaper for the user as it was contained within the GPS navigator/FMS. The limited bandwidth of SBAS forces the procedure data to be included in the nav database. But SBAS will likely never go beyond LPV capability which is acceptable to the GA community.

So the different needs of the GBAS and SBAS resulted in the different solutions.

$\endgroup$
3
  • 1
    $\begingroup$ Great insight Gerry. About WAAS and ADS-B: ADS-B doesn't need WAAS. It's the FAA that requires WAAS for an ADS-B installation, but most other countries don't require any SBAS for ADS-B. From the safety and performance analysis of the ADS-B applications it is very hard to derive a need for WAAS. It may have been added to the ADS-B mandate to justify the development of WAAS $\endgroup$
    – DeltaLima
    Oct 19, 2020 at 21:48
  • 1
    $\begingroup$ @DeltaLima The comment about ADS-B and WAAS was a bit of a simplification as there are other factors as well. One was supply side. The Airbus RFP for an MMR for the A350 (c. 2007) wanted GLS support and DAL A, and it had to comply with EASA's latest guidance for DAL A. That included dissimilarity, which the then current unit didn't meet. So a new (expensive development) chipset was needed, and including WAAS meant the chipset could be sold into the bizjet market where WAAS is desired in addition to the airlines. I also worked SC-186 (ADS-B) back then. Getting consensus there was a challenge. $\endgroup$
    – Gerry
    Oct 20, 2020 at 2:22
  • $\begingroup$ I was in SC-186 too (actually Eurocae WG 51, but the majority of our meetings were joined), but I only joined the meetings just after DO260B went through FRAC (I first joined in 2010 in Chicage IIRC, DO-260B FRAC meeting was end of 2009). I can agree that getting consensus was challenge :-) $\endgroup$
    – DeltaLima
    Oct 24, 2020 at 9:51
1
$\begingroup$

The GBAS method allows for more dynamic implementations than the database method. Databases are updated only on the AIRAC cycle date, and getting a change through requires months of preparation beforehand. The GBAS message can theoretically be changed overnight.

For example, if an airport needs to urgently displace a runway threshold (e.g. because of unplanned maintenance or an incident) this can be done overnight with GBAS. If a database change would be required, this can't be done on short notice. In the AIRAC system the AIS organisation has to publish the data 42 days in advance to allow users or their suppliers to prepare and distribute the updated database. Getting a displaced threshold through would take at leas 42 days, and at most 70 days. The same for moving the threshold back. For airports it is a huge benefit to have that flexibility.

For SBAS it is impossible to provide approach data, since the same SBAS signal serves a very large airspace with countless airports in it. For example, the US WAAS system uses 3 satellites at the moment. Providing approach data for all USA airports would result in very inefficient use of bandwith: approach data for all of the US would be broadcast to every location in the US. That would either require very high throughput (bandwidth) or result in very low repetition rates (making it less practical if you have to hold for several hours to obtain the approach data).

$\endgroup$
4
  • $\begingroup$ I don't think the GBAS (GLS) approach data would change out of cycle. I do think it is a good idea as it does not require a current database to fly the approach. The data will be current on the VHF frequency. The pilots will need to have current approach plates though. I don't know if the transitions or intermediate segments are broadcast so those may require a current database. $\endgroup$
    – wbeard52
    Oct 18, 2020 at 21:22
  • $\begingroup$ @wbeard. At the moment a current database is required. The problem we have is that the current AIRAC system is very rigid, but it's almost impossible to move away from it. GBAS offers a first stepin the roght direction, but by itself it will not enable more flexibility. But combine it, for example, with an autonomous aircraft and the possibilities are clear. $\endgroup$
    – DeltaLima
    Oct 18, 2020 at 21:29
  • $\begingroup$ "The GBAS message can theoretically be changed overnight". This is a mis-characterization of how navigation data is managed. The FAA has the same approval rules and process regardless of distribution method. The average delay between SBAS and GBAS update methods is half the 28 day AIRAC cycle, or 14 days. What message four data is so crucial or changes so frequently that 14 days makes a difference? $\endgroup$
    – Pilothead
    Oct 18, 2020 at 22:23
  • 1
    $\begingroup$ It's way more than 14 days, and also more than 28 days to go through the process of an avionics database change. 42 days before the change takes effect, the AIS organisation has to publish the data to allow users or their suppliers to prepare and distribute the updated database. So if you urgently need to displace a runway threshold (e.g. because of unplanned maintenance or an incident) this can be done overnight with GBAS. If a database change would have been required, it would take at leas 42 days, at most 70 days. For airports it is a huge benefit to have that flexibility. $\endgroup$
    – DeltaLima
    Oct 19, 2020 at 19:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .