HONEYWELL
Aerospace Electronic Systems
Page 26
Use or disclosure of information on this page is subject to the restrictions on the title page of this document.
4 DATABASES
Honeywell pioneered the concept of airline reconfiguration and partitioned software for datalink systems in
the early 1990s. The reconfiguration concept has continually evolved and improved as each new product has
been introduced. Reconfiguration started in the industry with the Honeywell Mark II ACARS unit, and
expanded with the B-777 and Mark II CMU. This design concept has continued to be improved resulting in
the Mark III CMU being the most flexible and powerful system available today providing unparalleled flexibility
in defining the AOC application. In addition, the reconfiguration concept has been expanded to allow support
for ATC (Certification related processing). This allows the system to easily be expanded for current and
future ATC processing. The architecture for supporting such reconfiguration is centered around the Database
design contained with the Mark III CMU. Changes to these databases do not require embedded operational
software changes, making changes much simpler and faster (and not prone to software coding errors).
Further, like our Mark II CMU, the approach supports the ability of airlines making changes to the AOC
database, using a PC-based tool, without impacting the certification of the unit.
There are three primary databases contained with the Mark III CMU. The AMI database defines the airlines
AOC functions. This is the database that either Honeywell or the Airline can create, and update at any time,
using a PC based tool (GBST). The second database is the HGI database. The HGI is a database similar to
the AMI, but contains information that is considered by certification authorities as requiring certification
control. As an example, ATC messages and the corresponding MCDU screens are defined in the HGI
database. The HGI database is only modifiable by Honeywell, and does require changes to be under
certification control. The third database is the FIDB database. This database defines the mapping between
external (input) parameters received from other subsystems on the aircraft and the corresponding
parameters used within the CMU as well as in the GBST reconfiguration tool. The FIDB database approach
provides a significant improvement over other previous reconfiguration systems, by allowing the CMU to have
a single database for all aircraft types, with the FIDB defining aircraft differences. With this approach, single
database part numbers can be used across an airlines complete fleet of aircraft, rather than separate
database part numbers for each fleet type. Further information on these databases and reconfiguration are
provided in the following sections.
4.1 FIDB
The Flexible Input Data Base (FIDB) is a cornerstone of the Mark III CMU database design. Aircraft
parameter data for each aircraft type is captured in mini-FIDBs. All of the mini-FIDBs are collected into a
single master FIDB that contains aircraft data for all aircraft types. For a given customer, data for that
customer's aircraft types are put into the Customer FIDB. (See Figure 10).
