5.0 The integration, test, and Customer ATP are almost trivial compared to the testing of specially designed switching and connection algorithms.

For most trainer programs any major unanticipated cost growth occurs during that nebulous three-month period shown on the project schedule as "Hardware/Software Integration".

The interface to the ASTi DACS is simple: a single ethernet packet. The ethernet packet is entirely flexible and can be in any format of the customer's choosing - issues such as big-endian-to-little-endian or fixed-to-floating point conversion disappear. The interface is fully tested and supplied with a comprehensive set of pages to assist in visibility and manipulation. Even this requirement for input of host data can be virtually eliminated; if ASTi senses communications panel inputs directly. Then, the only data required are instructor originated dynamic controls (see **).

Full testing of the DACS Custom Model is usually completed in a stand-alone mode in the absence of any other hardware or software using the Model Builder controls for the entry of data into the host packet. For more complex systems ASTi will usually create a host emulator.

This is in dramatic contrast with the problems encountered during HSI for the digital switch. Prior to HSI, a software test harness must be constructed for initial unit test. Then during HSI the actual hardware must be checked out and commissioned for a large variety of test conditions. For simulations of complex real world systems, it will invariably transpire that errors have been made requiring new code and more testing. This discovery and correction process is usually sequential, requiring problems in the hardware installation and panel I/O to be corrected before testing of the comms software can be completed. This is the classic "90% complete" software phase that sometimes consumes as many hours as the original design budget.

Customers familiar with a digital switch architecture (where the ATP must test every element, permutation and combination of a complex set of connection alternatives) find it difficult, at first, to appreciate how simple it is to validate the ASTi communication system implementation.

There are two elements of the implementation that must be validated in an ASTi solution:

1. To confirm that each operator position has been provided with the defined virtual communications assets (e.g., eight UHF and VHF radio channels, three vehicle intercom buses, a radio guard channel, a PA and a multi-priority-level of simulator specific Instructor communications). See ** below.
   
   
2. It is also necessary to confirm the integrity of the physical connections, i.e. that the single (in most instances) cable loop is routed to each operator and is plugged in.

Both these tasks are accomplished by designating a position on the network (or several positions if desired) as the test operator and then communicating across the virtual nets to the position under test (operator N). To check out the different channels takes just a few minutes for each operator position. At the conclusion of this formal test process, the customer SME's are usually provided with as much time for unscripted freeplay as they desire. The confidence in the system is so rapidly established that we find that less than a day is usually more than adequate. We recently concluded customer acceptance testing on a system with over one hundred different operator stations in less than three days (with a single discrepancy - one single panel was late from our vendor).

** This is somewhat of a simplification, because there are other trainer control functions to be checked such as: mission environment control connections (eg. weather condition inputs, terrain data base occlusion, jammer insertion, etc.) and record and playback connections. However these do not add substantively to the RTM/ATP process (Requirements Traceability Matrix/Acceptance Test Procedure).

The problems encountered during customer acceptance testing for the digital switch usually commence prior to his arrival, with obtaining customer approval of the ATP. This document is already substantially thicker than the ASTi equivalent, and, dollars-to-doughnuts, your customer is driving you to include even more test cases, not less. Your assertion that such exhaustive testing is not necessary evaporates embarrassingly with the first example that he discovers of a derivative error (where a function is fine in one mode, but fails under a second set of conditions). All special features of your environment, such as propagation effects, must be extensively checked; this is not a simple process since there are so many pre-conditions such as altitude, output power, lat/long, frequency, squelch and PTT which must be set correctly. Even if your code is impeccable, simple mistakes in setting all these pre-conditions, for both transmitter and receiver, during testing can disrupt communications and lead to erosion of customer confidence.

In staffing the communications system project, you will frequently find that you have been forced to chose a computer science expert who, if you're lucky, has implemented elegant code, but now begins to appear ignorant in the ways of radio to the customer SME. Or, you have given the task to a radio expert, who is now beginning to discover the difficulties inherent in patching up some spaghetti code. Either of these scenarios can result in significantly more problems during the acceptance phase than originally budgeted.