At a Glance

In 1991 and subsequently, I designed this Heads Up Technologies aviation checklist system.  I provided:

• The complete hardware design:  schematic diagrams and layouts for 5 circuit boards, in a dual-CPU design.
• The complete firmware and MS-DOS based support software:  a large but unknown number of lines of C and Intel-8051 assembly-language code.
• Documentation:  45 pages for specification and certification purposes, plus an unknown number of pages for internal software and hardware documentation purposes.

Background

This is an audio checklist for pilots.  The idea behind this product is that it is an enhanced replacement for the "Gold" Checklist unit.  Functionally, it is basically the same product, though differing completely in hardware and firmware, but simply with more of everything.  Here are some examples:

• Faster CPU for improved response time.
• Higher capacity -- more memory for larger checklists.
• Improved audio quality, using the audio-compression algorithm I invented for the PBS-400 product.
• Field-reprogrammability, via a replaceable memory cartridge.
• Improved readability of visual display -- LED rather than backlit LCD -- including an automatic brightness adjustment.
• More (and more flexible) audio outputs.
• Greater compatibility with other aircraft equipment, via a more standard case size, mounting method, and connector type.
• Simpler user interface (more buttons and dials).
• Many additional behavioral options in the checklist firmware.


The various features mentioned above have no real technical interest, since they are mostly reasonably straight-forward variations on things I had designed before.  The project is interesting, however, in that it was the first real practical demonstration of the reusable-software system that I had invented previously for the CMS-700 hand-held checklist project.  While various elements of my newly-invented software library had been reused before (PBS-400 and LVA projects), the CMS-400 project was the first instance in which an application program had been substantially reused.  In other words, the high-level code for the CMS-400 checklist was an adapted and expanded form of the CMS-700 checklist program, rather than being yet another complete rewrite of a checklist application (like the original Heads Up Checklist and Gold/Silver Checklists).

Another significant technical aspect to the CMS-400 project is that it marked the first time I made an attempt to provide a truly "user friendly" application, in the form of a support-software package for maintaining the checklist "scripts".  The scripts, which contain textual forms of the pilot's desired checklist, had been maintained as simple ASCII text files for earlier-generation checklists.  True, I had provided MS-DOS based support software for "compiling" these scripts into a binary format suitable for inclusion in the units, as well as software for editing audio clips and maintaining a database of audio clips, but this support software had been in the form of command-line utilities.  With the CMS-400, so many additional features and options had been added that editing the checklist scripts as text files was no longer deemed satisfactory.  So I provided a full-screen editor program, HEDITOR, which could be used for this purpose.

Here are a couple of HEDITOR screenshots:

Though primitive in appearance by today's standards (recall that the program pre-dates any usable version of Microsoft Windows), the HEDITOR program is actually quite usable and indeed, is still in constant use today (2001).  In fact, I included a number of rather sophisticated features in the program, implementing them all myself rather than having the use of commercial packages:

• Multiple file-formats supported.  Both the CMS-400 script format and all of the older (very different) checklist script formats were accepted.
• There is an integrated spell-checker.
• There is a semi-automated abbreviation engine.
• There is a built-in expert system which can scan the checklist for potential configuration problems, and can fix many of these problems, thus allowing rather free conversion of scripts from one type of checklist unit to another.


The "abbreviation engine" probably requires some comment.  Since the checklist units not only play an audio form of the pilot checklist aloud but also display a visual form of the checklist on a rather small display screen, there needs to be a convenient method of creating the abbreviated display screens from the much fuller text of the audio.  For example, suppose that the audio of a given checklist line is "landing gear down and locked -- check!"  A typical display-screen size might be 16 characters by 2 lines, so the display screen might need to show

 
LAND GEAR DOWN
& LOCKED  -CHECK

Or, it might be preferable to display
 
LANDING GEAR
DOWN&LOCKED -CHK

Since any given checklist may contain hundreds of such display screens, it is really impractical to create each one of them manually, and expect there to be any consistency among them.  That's where the abbreviation engine comes into play.  Whenever an abbreviated display has not been entered manually, the engine will create one.  It relies on several methods for doing so.  First, it maintains a database of all abbreviations of complete checklist items that have been used in the past, and picks a match from this list if possible.  If this fails, it also maintains a database of all word abbreviations used in the past, and abbreviates the individual words using this database.  Finally, it can create its own word-abbreviations on the basis of certain rules.  In the latter two cases, however, it requires the user to approve or edit the abbreviations that have been created.  Once approved, the abbreviations enter the databases, and can be used in the future automatically without approval.

Here's a screenshot of the abbreviation engine in action: