Nav databases - size constraints
 

Does anybody understand Nav database formats?

We fly a bunch of older A319s with a 400k database and I'm trying to understand the approach and waypoint constraints on a databases this size in North American airspace. Our newer FMSs are 10 meg so obviously Honeywell is expecting that the larger size is required but not being a pilot or a nav database specialist I'm having a difficult time understanding why the extra size is required and in deciding/justifying if we should upgrade our older A319 FMS's.

As to 'formats', no.

The growth in waypoint data with the spread of RNAV has considerably increased the requirement for space. Airports also seem more than ready to throw loads of procedures. mostly RNAV based, onto the system.. Individual airlines also may wish to add company route data (which significantly reduces turn-round time) over having to type in every airway manually.

In my last airline, a couple of 737-300s returned from overseas lease with miniscule databases such that we had to sneak around in stealth mode non-RNAV for a while.:rolleyes: A few co-pilots had no idea how to 'navigate' - interesting times.

I'm a little busy right now but the short answer is: You can never have too much memory.

It isn't as much a "format" question but rather that the whole ATC system is going RNP which translate into more complicated and thus memory hungry procedures.

Every day ATC procedure designers are developing new RNP / RNAV based procedures to be loaded on top of the conventional procedure. In the case of Honeywell you cannot get rid of the procedures you are not using, as Honeywell insists on loading all "standard data" - even including the ones you are not allowed to fly.

Every AIRAC-cycle update you get contains both the current data and the next data. When a new cycle carries a lot of changes, you will have to load these on top of the current data. This could easily result in a demand from Honeywell that you remove some destinations and their associated procedures to make space.

Rgds.
dusk2dawn
[desperately managing nav-data for a fleet with Honeywell Non-One-Mega FMCs]

The file format, from what I remember having looked at the content of Aerad floppy disks, is very compact. The B737-300/400/500 fleet we used to have had between 1991 and 1997 (I believe) a 96KB memory (that's Kilobytes, a total of less than 100,000 characters of memory). This was tight for our operation; we did kick out SIDs and STARs for secondary airfields. However, we got two database cycles in that, plus its 4k of workspace - thus, the data for a pretty usable operation around Europe.

Unlike bloatware inefficiently produced by companies such as M**r***f* and A***e (have you seen how much space a single Word page takes up?!), I'm pretty sure that the data standard has remained pretty compact.

It's true that you can't have too much memory. On the other hand, if you're filling it up with stuff that you won't ever use, then the extra memory is no more useful than the fuel in the tanks that you won't ever actually use - it just makes you feel a bit more comfortable, and makes somebody a bit of incremental money by virtue of you carrying it around.

In its most basic form, the FMC has a 96k word navigation database, where one word is two bytes (ie a 16 bit processor). This was increased to 192k words in 1988, 288k in 1990, 1 million in 1992 and is now at 4 Mega words for the 737-NG with Update 10.7. The navigation database is used to store route information which the autopilot will fly when in LNAV mode.

• Waypoints/Intersection
• Airways
• Radio navigation aids including DME, VOR, NDB, and ILS.
• Airports
• Runways
• Standard instrument departure (SID)
• Standard terminal arrival (STAR)
• Holding patterns (only as part of IAPs-although can be entered by command of ATC or at pilot's discretion)
• Instrument approach procedure (IAP)
• PBN/RNP arrival, departure, engine out, etc

(note: the latest version of the FMC runs on a 30mhz 486 chip):{

The A320 Thales Topflight FMS database is 7MB.



(The data providers (Jeppeson, Lido etc.) charge exorbitantly by the record for the 28 day cycle updates too).

Do you know the average price?

Thanks folks

I guess the issue I'm having difficulty with is projecting how much longer we can operate with only 400k. Navigation database issues are new territory for me but from what I understand GPS approaches are being developed fast and furious and RNAV waypoints even faster. At the same time though they must be replacing old approaches that can be dropped out of the databases so how can I quantify the delta. AT least then I would know how long we can go without needing to start managing and editing content. . Any thoughts or suggestions?

Fullblast
Fees are quite complex and doubt there is an average as such.

Typically consist of Service fees for tailored data, a Processing fee dependent upon database size and another Service fee factored for fleet size with other minor costs for unplanned ad hoc activities. Not cheap.

nnCo,

If you have been getting by with the 400K database for this long, you would certainly have to justify the upgrade.

Who is you current navdatabase provider? Who's charts are you using? They would be the first to ask for a tailored database for your company. This is very common.
I havent ever heard where the end user can manage or do anything to the data..

(they virtually NEVER drop anything from the navdatabase, it is always an add...)

You're right I found out. Our real problem with the older databases is the restriction on the number of waypoints in the database. No way around it other than a new FMS.

Thanks for your feedback folks and for those that are interested I came this recent 2012 IEEE document that presented the subject nicely

FLIGHT MANAGEMENT COMPUTER (FMC) NAVIGATION DATABASE CAPACITY
http://www.mitre.org/work/tech_paper...24/12_1324.pdf

Just for reference, does anyone know what the size of the EGPWS terrain and obstacle databases are?

I'm seeing NAV memory sizes quoted here from 400K to 10MB. But I seem to recall that some EGPWS systems use removable Compact Flash (CF) cards, which could hold as much as 256 GB (more for recent CF versions). So it would seem that the modern solution to NAV memory limitations would be to offer upgradable storage. Since this media is already in use for terrain data, the issues of certification and firmware to read it have already been solved.
:8

EGPWS uses the NOAA or NACO DOF for the terrain and obstacle file ...currently that is a 10.4MB file

Digital Obstacle file

These are very easy to edit sections or areas that you need...