6 – Testing, Integration, and Instrumentation

The purpose of any form of testing is to determine the quality or functional capability of an item. In the testing of 1553 devices, the purpose of the test procedure is to verify that the design does meet the 1553 specifications and that the options implemented have been done so correctly.

In the early days of 1553 implementation, there were few, if any, standard components (e.g. transceivers, encoders/decoders, protocol sequen­cers, etc.) available for the designers to use. There­fore, designers were developing their own based upon their interpretation of the standard. In addition, there was no standard “off-the-shelf” 1553 test equipment available to test the design, so the designers had to develop limited capability testers themselves to prove that their own designs worked and to provide their production facilities with a method of testing. As time and the popularity of the standard progressed, standardized components (sometimes available from multiple sources) started to become available. More important though, the experience in testing and integrating 1553 systems has led to the generation of a series of standardized test plans to support these requirements.

6.1.1 Levels of Testing

The levels of testing can be identified as follows: developmental, design verification, production, systems integration, and field/operational testing. These levels may be applied to the remote terminal, bus controller, monitor, or actual bus system (cable, couplers, stubs, etc.). These levels are discussed as follows:

1. Developmental Testing. Developmental testing begins with the breadboard of the design. It is used to determine the circuits operation and to eliminate any design flaws. This level of testing also includes the testing of the circuits operating margins and tolerance limits usually over the required operational requirements (e.g., temperature range, etc.).
2. Design Verification. For design verification, usually a preproduction unit is subjected to a series of tests designed to verify that the unit satisfies the requirements of the 1553 standard and the options specified in the system specification. This level is generally the most extensive phase of testing.
   The BUS-65518 and BUS-69124 (formerly BUS-65520) validation tester plan (VTP) provides a turnkey tool for performing this test.
3. Production Testing. Production testing is generally referred to as “end item” or “acceptance” testing, but can also be applied to in progress or subassembly items. It is assumed that the design has been previously verified and that this level of testing is performed to verify that all of the circuitry is functioning properly including mode code operation, error message validation, and any other special sequences that can normally be performed.  Production testing procedures usually consist of a subset of the design verification tests. The BUS-65518 and BUS-69123 (formerly BUS-65519) production tester plan (PTP) provides a turnkey tool for performing this test (see photo below).
4. Systems Integration Testing. The purpose of sys­tems level testing is to insure that all elements of the bus network *play” together. This level of testing is usually centered around the operation of the bus controller’s software and its ability to manage the data flow on the bus. This level of testing is generally performed in a Systems Integration Laboratory (see paragraph 6.2 on integration).
5. Field/Operational Testing. Regardless of the amount of integration testing performed, the final design verification is the actual field/operational testing of the system. Often this is the first time the actual subsystems (as opposed to simulated systems) are interfaced to the bus network. For military applications this level of testing is usually referred to as Development Test/Operational Test (DT/OT). This level of testing is systems oriented and encompasses a total examination of all systems functions from the man/machine interface to the accuracy to the systems performance.

Paragraph 1.6.8 describes the efforts of the Air Force testing program and the development of a series of test plans to cover both the remote terminal and bus controller for validation and production testing. These test plans have been jointly developed by industry and government 1553 experts and should be used as a source of guidance in the areas of circuit design, specification interpretations, and testing procedures.

6.1.2 Test Requirements

Test requirements for terminals can be divided into two main topics: electrical interface tests (including noise tests), and protocol tests. The electrical interface tests apply to all terminal types (remote terminals, bus controllers, and monitors), whereas the protocol tests are a function of the type of terminal being tested. All tests should be applied to each of the buses when the terminal contains redundant buses. Some of the tests are used to “characterize” the terminal rather that to verify compliance to the standard and the results should be included in the Interface Control Document (see paragraph 3.9). Each of the tests are summarized as follows:

6.1.2.1 Electrical Interface Tests

The specifications called out in the standard define the requirements at the connector pins of the terminal. These points are defined by point A in figures 9 and 10 of MIL-STD-1553B. It is important to note that all of the specified requirements are for the terminal itself and are not to be measured with the terminal connected to a system where they would be dependent on other system elements. The electrical interface tests can be subdivided into four parts: input, output, isolation, and noise tests.

The input tests include:
a)  input polarity
b)  input impedance
c)  input signal amplitude
d)  zero crossing distortion
e)  rise/fall times
f)  common mode rejection
g)  input bit rate stability

The output tests include:
a) output polarity
b)  output amplitude
c)  zero crossing stability
d)  rise/fall times
e)  distortion, overshoot, and ringing
f)  output symmetry/tailoff
g)  output noise
h)  power on/off noise
i)  output bit rate stability

Since terminals functioning as monitors need not be designed with a transmitter, the output tests do not always apply.

The isolation tests are used to verify the input and output isolation between buses in a redundant bus design. The requirement is given as the ratio in dB between the voltage on the active bus and the voltage on the inactive bus.

The noise rejection tests are required to verify that the terminal exhibits a maximum word error rate of one part in 10 when operating in the presence of additive white Gaussian noise. The noise test is run continuously until the number of words received by the terminal exceeds the required number for acceptance or is less that the required number for rejection for a particular number of errors. The accep­tance/rejection criteria is specified in Table II in the standard. In this test, it is the common practice to gate the noise source off while the terminal responds to the bus tester. This reduces the probability of the status word being *garbled.” A typical set up for the noise rejection test is shown in figure 6.1.

6.1.2.2 Protocol Tests

The protocol tests are performed as a function of the terminal type. Bus controllers which are also capable of performing as a remote terminal (e.g. while acting as the backup bus controller) need to be tested for both functions. The protocol tests for the remote terminal and bus controller are summarized as follows:

1. Remote Terminal Protocol Tests. The first step in testing the remote terminal is to verify that the terminal responds properly to all the legal (valid) information transfer formats including BC-RT, RT-BC, RT-RT, mode commands with and without data words (receive and transmit). These formats should be tested with all subaddress and word counts implemented in the terminal. All implemented mode code operations also need to be tested. If the terminal is designed to recognize illegal commends, then all of these commands, and their specified response, need to be tested.The unique terminal address of the terminal needs to be checked by sequencing the address through all combinations while issuing commands to all the other addresses.
   In addition, if the broadcast option has been implemented, all of these tests need to be repeated for the broadcast address.The terminals timing characteristics need to be verified and characterized. This includes the measurement of the status word response time. The terminal should also be tested for its ability to respond to superseding commands.The message validation of the terminal needs to be examined by injecting messages with various error conditions. The validation criteria which needs to be tested includes
   a) sync errors
   b) encoding errors
   c) bit count errors (word length)
   d) parity errors
   e) word count errors (message length)
   f) gaps (discontinuous data)
2. Bus Controller Protocol Tests. Testing of the bus controller function requires prior knowledge of the bus controllers software. The first step is to verify that the bus controller is capable of issuing the desired command list and data. This is often difficult to do, especially in systems where events occurring on the bus or data word patterns cause the insertion of various aperiodic messages into the command list. Also an important part of this test is to monitor that the controller never issues invalid commands (1553) OR commands prohibited by the systems specification (i.e., dynamic bus control mode codes). The bus controller must also be tested to insure that it transmits on only one bus at a time.

If possible, the proper processing of the normal valid terminal responses must be tested. The bus controller must also be tested for its processing of abnormal or invalid responses. These may include: no response; improper status bits; word errors (sync, encoding, parity, etc.); discontinuous data words; and word count errors.

The bus controllers timing characteristics also needs to be verified. This includes the minimum intermessage gap and the minimum no response time out. As can be seen, knowledge of the software operation is required in order to perform most of the bus controller protocol tests.

Systems integration is the process where all of the components (bus controllers, remote terminals, and subsystems) are brought together and “married” into the common bus network. For multilevel or hierarchical networks, this may be first done at the lower bus level and then later combined into the total system. The process almost always includes the *marriage” of the system hardware (bus network) and software (bus controller and backup bus controller). In past applications, the systems integration task has been the responsibility of the aircraft manufacturer or the developer of the bus controller.

To assist in the integration effort, most companies have developed Systems Integration Laboratories (SIL), usually dedicated to the particular program. The SIL facility can vary greatly from a “hot bench” to full computer simulation. Today most SlL’s provide for a mixture of capabilities allowing for the emulation/simulation of a component until a breadboard or preproduction unit is delivered. The advantage of this method is that the development (and checkout) of the bus controller software and the system can proceed without having to have the actual equipment.

While it is the desire of every systems designer to *marry” all the components, apply power, and watch everything work (correctly), it is seldom, if ever, accomplished. To this end, the method of “incremental integration” is most often applied. With this method, a portion of the bus control software is developed and initially integrated with one or two terminals. Then as more software is developed or more terminals are delivered, they are added to the system until at last the entire system has been successfully “married” together.

6.2.1 Simulation

Due to the schedule compression of most programs today, the systems integrator and system/bus controller software developers are turning to the emulation/simulation of the systems components. For definition purposes: emulation is used to replace a hardware function (e.g., use of a bus tester to communicate as a remote terminal); and simulation is used to perform the operational function of a terminal (e.g., manipulation of the data within the terminal based upon data word contents or a pre-programmed algorithm). In short, emulation applies to the hardware, whereas simulation applies to the software.
By using the incremental integration method, it is possible to get an early start on the integration of the bus controllers and the development of the bus control and applications software development and checkout. Some systems designers have used bus testers (functioning as remote terminals) to emulate the various terminals on the bus. Some testers are even capable of emulating multiple terminals based upon the total number of messages which can be handled by the tester. Initially, the actual content of the data words is of little or no importance and therefore they can be set to random or constant data patterns or be set to incrementally change for each message transmission. The use of the bus testers for this emulation function will allow for the injection of errors in the messages and allow for the verification of the bus controllers error handling and recovery procedures.

As the integration and software development progress, the content of the data words will start to become of some importance, especially to the applications programs. Some of the bus tester have limited processing capability which would allow for the movement of data between buffers or simple operations upon the data. For some terminals, this level of simulation may be sufficient. However, for the more complex subsystems and terminals, it may be necessary to go to a bigger computer with more computational power. To this end, several manufacturers have developed 1553 cards which interface to mini/micro computer backplanes (e.g. LS1-11, PDP-11, VAX, NOVA, Eclipse, S.E.L., Multibus) and interface via DMA techniques to the computer. This allows for some large applications simulation programs (i.e. aircraft flight characteristics, navigational models, etc.) to be developed on the host computer and the results downloaded to the 1553 interface card to be transmitted on the bus when commanded.

This simulation method can be used until actual hardware is available or until it is necessary to install the components on the aircraft or platform. Most systems integrators retain the SIL facility for use in solving system problems encountered during DT/OT and for the integration of future additions to the system.

The ultimate systems test is DT/OT testing. Whether the application is airborne or ground based, this is often the first time some of the platform or mission equipment (e.g., engines, sensors, weapons systems, etc.) are connected to the bus network. It is also during the DT/OT phase that the customer evaluates the performance of the product. Therefore, it is necessary in the effort of continued systems integration or performance evaluation to monitor and collect data from the bus network. In addition to the testing phase, some applications continuously monitor certain bus parameters as part of the vehicle/platform maintenance activity.

For validation and testing purposes, it is often necessary to collect one hundred percent of the data bus traffic. Today, bus monitors exist which are capable of extracting all data or being programmed to collect only certain messages to selective terminal addresses and subaddresses or error conditions.

Since 1553 is a one megabit asynchronous bus, the high speed (compared to other platform functions) and the non-synchronous nature of the data traffic present particular problems in the acquisition and analysis of the data. There are two primary methods for acquiring and storing this data; on board bulk storage, and telemetry.

On board bulk storage is performed by means of magnetic tape or semiconductor memory. High density, multitrack tape has advantages of allowing the data bus to be recorded and synchronized to a clock. Its obvious disadvantage is the amount of data which can be acquired due to the time limitations of the tape (speed, length, etc.). The amount of data storable in semiconductor memory can easily be increased by the addition of more memory, but there are limitations. Additionally, data compression techniques and algorithms can be applied to condense the data and increase storage capacity without loss of data or its resolution.

Telemetry systems collect and encode the data for transmission, via a radio communications link, to a ground station for recording and analysis. Systems available today monitor for the desired data and then synchronize the data with a clock. The synchronized data is then encoded via pulse code modulation (PCM) and time multiplexed along with other signals into the telemetry system. The data is usually formatted to the IRIG (Inter-range Instrumentation Group) standards and hence existing ground receiving equipment can handle the decommutation of the data.

The instrumentation of the data bus needs to be addressed as part of the overall testing and systems integration activities. The systems designer needs to analyze and identify the signals with need to be monitored such that an adequate instrumentation package can be designed.

The BUS-65518 tester/simulator card (see photo on page I-84) provides a tool that can serve many uses in 1553 development, testing, and maintenance. The board, which plugs into an IBM PC or compatible, is capable of emulating bus controller, up to 32 remote terminals, and bus monitor simultaneously. The board has capabilities for BC message scheduling (including minor and major frames), extensive error injection for BC and RTs, and “trigger” and *selection” (filtering) capabilities for the monitor. The BUS-65518 comes with interactive menu software allowing easy setup of all modes with no programming. The board can be used in a lab environment for software development and systems integration and debug.

In addition to the interactive menu software, real time libraries are available for C, Pascal, Windows 3.1X, 95 and NT.. The real-time libraries, which provide an interface between the user’s program and the board, are ideal for test, simulation, and demonstration applications. Other software options for the BUS-65518 allow emulation of MIL-STD-1553A RTs, implement the validation and production RT test plans, support monitor-to-hard-disk storage, provide parameter monitor capabilities, and provide capabilities to reconstruct message traffic from monitored data.