Nav databases - size constraints
Thread Starter
Join Date: May 2005
Location: On a good day - at sea
Posts: 263
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by nnc0; 13th Oct 2012 at 23:47.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
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.
A few co-pilots had no idea how to 'navigate' - interesting times.
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.
A few co-pilots had no idea how to 'navigate' - interesting times.
Transparency International
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]
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]
Join Date: Nov 2001
Location: Inside the M25
Posts: 2,404
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Mar 2011
Location: engineer at large
Posts: 1,409
Likes: 0
Received 0 Likes
on
0 Posts
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.
(note: the latest version of the FMC runs on a 30mhz 486 chip)
- 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)
Last edited by FlightPathOBN; 14th Oct 2012 at 21:41.
N4790P
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).
(The data providers (Jeppeson, Lido etc.) charge exorbitantly by the record for the 28 day cycle updates too).
Thread Starter
Join Date: May 2005
Location: On a good day - at sea
Posts: 263
Likes: 0
Received 0 Likes
on
0 Posts
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?
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?
N4790P
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.
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.
Join Date: Mar 2011
Location: engineer at large
Posts: 1,409
Likes: 0
Received 0 Likes
on
0 Posts
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...)
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...)
Last edited by FlightPathOBN; 15th Oct 2012 at 14:32.
Thread Starter
Join Date: May 2005
Location: On a good day - at sea
Posts: 263
Likes: 0
Received 0 Likes
on
0 Posts
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
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.
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.
Join Date: Mar 2011
Location: engineer at large
Posts: 1,409
Likes: 0
Received 0 Likes
on
0 Posts
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...
Digital Obstacle file
These are very easy to edit sections or areas that you need...
