The centralized processing approach, combined with our previously fielded network and audio elements, allowed us to view all of the panels as fundamentally identical. They consist of five internally located and integrated items:

1. Panel Interface Unit
2. Chassis with switches, knobs, keypads, and displays
3. Remote Interface Unit (performs sound manipulation and network management)
4. Audio Interface Unit (performs sound input/output amplification and buffering)
5. The Model Server state machine code.

This panel design architecture provides panels which are fundamentally identical, and allowed us to move ahead with parallel panel related tasks, utilizing multiple resources. See Figure 5.

The Remote Interface Unit (RIU) is a standard element of the ASTi product range. It is a multi-drop device which performs input analog to digital, and output digital to analog conversion for each of the human operators within the training system. Each RIU, can input/output up to four audio streams to the DACS node, and is uniquely set with a TDM address from 1-15, which maps digital audio data to its respective source and destination. This audio data is placed by the RIU on to one of the Time Division Multiplexed (TDM) loops of the DACS. The TDM/RIU architecture eliminates all audio signal transport via line level signals (which are both noisy and lossy over long distances) and allows audio to be transported digitally and, consequently, noise-free. The TDM loop architecture allows total loop lengths (i.e. physical operator separation) of up to 250 meters.

Except for new firmware required to support the new internal data protocol, the RIU remained unchanged from its previous release.

The PIU existed prior to this contract, but a new revision was developed. A single, multi-purpose board was designed based on a superset of the number of analog and digital input/outputs and display numerals as well as the size of keypad matrices required on the collective ORTT communications panel types.

These were based on photographs and engineering drawings provided by Lockheed Martin, Canada. This task, unique to each panel type, was one of the most protracted elements of the schedule.

Fortunately, since the PIU hardware was designed from a superset viewpoint, the mechanical design and production task could be largely subcontracted out-of-house to local resources. The manufacturing drawings produced by these suppliers were considered proprietary to the manufacturer, although copies of all the documentation was made available to the customer.

The recommended maintenance philosophy was to treat each panel as a Lowest Replaceable Unit (LRU). This meant that it was not necessary to document the internal repair or assembly process. To provide a comprehensive O & M manual for each panel would have been inordinately expensive. Each panel was regarded as a COTS LRU, in that it could be competed for remanufacture to any competent source based upon the original drawings and our specifications. Several additional copies of each panel were made to support work-in-progress maintenance and spares.

This communications software was written to interface the superset PIU board as defined above, to the internal data transport protocols.

The internal data transport protocol was a simple extension of the existing voice distribution mechanism across the TDM Cat5 cable loop. Time slots were allocated exclusively for each set of panel data. This yielded an efficient method by which switch and control information (e.g. volume control) could be transported between the panel and the software functions in the Model Builder communications environment located on the same node. Implementation of this protocol required a change to the Remote Interface Unit firmware (embedded within each panel), and to the DACS Model Builder software.

The external data transport protocol switch and control information (received from the panel over the TDM using the internal data protocols) could be transported from the DACS platform across the ethernet to state machines located within the central Model Server platform. This data traffic, unlike the internal data traffic, was event-driven so that traffic was only present during an change of panel status. Because the data rates were insignificant compared to voice traffic, this data imposed a negligible burden on the bandwidth.

Implementation of this protocol required a mid-level change to Model Builder software resident on the DACS and required additional system data routines within the Model Server software.

Next page: Hardware Design (cont.)