Honeywell Understanding Database Systems for Enhanced Network Router Functionality

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).

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.