Abstract. This paper describes the use of four Intel 80486 based computers operating in parallel to perform the real time missile simulation, data collection, and maintenance and support functions of a threat radar system installed at the Eglin Test Range in Florida. The system simulates in real time the operation and RF environment of a command guided surface to air missile system. The flights of up to two missiles and a single target can be simulated concurrently. The missile simulation includes the simulation of two fire control computers which output commands to the Command Guidance Subsystem (CGS) for missile control. The software sends, via an IEEE-488 bus interface, missile and target coordinates with other control data to special purpose hardware (RF simulators) which inject proper signals into the radar. The real time simulation software collects and logs data with both internal and external data interfaces. The internal data interfaces include two disk drives with removable storage media, two laser printers, graphics displays and operator keyboards and displays. The external interfaces include a strip chart recorder, a bidirectional Centralized Control Facility (CCF) communication link (RS-422), the IEEE-488 bus, and the Real-Time Computer Interface Subsystem (RTCIS). Real time data is time tagged using a time code generator so that post mission data reduction and comparison with data from other sites can be accomplished. The software also performs various automated tests and calibrations as required to validate the performance of the radar subsystems in non-real time mode. When the system was first installed in 1985, a Systems Engineering Labs (SEL) model 32/87 minicomputer was used to perform these tasks. Recently, it was determined that the same functionality could be provided using a network of standard 80486 based computers running in parallel with greatly reduced operating and maintenance costs and higher overall system reliability. This paper describes the hardware and software architecture used by the computers in this system.
1. Overview
The SADS VIII system which was developed by Georgia Tech and became operational in 1985, is an emitter-receiver-processor (ERP) simulator of a threat surface-to-air missile (SAM) system. It simulates the radiated signals of this threat along with the associated receivers, functional displays, and signal processing equipment.
The system is installed at Eglin Air Force Base in Florida and is used to extend the air defense simulation capability of its electronic combat range. The system duplicates critical technical and operational features of the real system so engagement sequences can be authentically simulated according to opposing force doctrine. In addition, it has the capability to provide feedback to assess training and tactics development effectiveness and to satisfy specific testing requirements.
SADS VIII uses RF injection just behind the antennas to concurrently simulate up to two missiles and one target. Two radars, the Target Acquisition Radar (TAR) and the Target Tracking Radar (TTR), are used for acquiring and tracking real and simulated targets. Two independent Missile Tracking Radars (MTRs) are used to track the position of up to two concurrent simulated missiles early in the missile flight. When the angle between the missiles and the target becomes small enough, Differential Missile Tracking Radars (DMTRs), which utilize the TTR antenna, are used to track the missile positions more accurately than is possible with the smaller MTR antennas. Two Command Guidance Subsystems (CGSs) are used to transmit simulated guidance commands. Figure 1 shows a photo of the SADS VIII pedestal.
Extensive commercial measurement devices, such as digital voltmeters and pulse frequency counters, are provided so that automated tests under computer control can be run to measure the performance characteristics of the radar hardware when the system is not in real-time mode.
When the system was installed in 1985, a Systems Engineering Laboratory (SEL) model 32/85 32-bit minicomputer was used to do the simulation, data collection, and automated test functions. Recently, high yearly maintenance fees and low reliability made replacement of the SEL computer with a network of generic Intel 486 based computers an attractive option. It was determined that four 486 computers could provide the same functionality as the SEL minicomputer with greater reliability and lower operating and maintenance costs.
2. Computer Hardware
Figure 2 shows a block diagram of the system of 486 based computers used to replace the SEL computer. The system consists of an Operator Site Functions (OSF) computer, a Data Collection Computer (DCC), and two missile computers. The computers are interconnected via a commercially available Scramnet shared memory interface. An external chassis connected to each computer houses the shared memory electronics. The shared memory chassis are interconnected in a ring topology using fiber optic cables. A 128 kilobyte area of memory is mapped into the address space of each computer. Data written to this area of memory by any of the computers is copied within one microsecond to the same memory location in the other computers.
Bernoulli removable disk storage media manufactured by Iomega are used for program storage and data recording. The DCC has two 90 megabyte disk drives and the OSF has two 150 megabyte disk drives. The missile computers have no data storage requirements and therefore only have 3 1/2 inch floppy drives.
The OSF computer has a National Instruments IEEE-488 interface that is used to send and receive data from test instruments and to send commands to the RF simulation system. The IEEE-488 interface is capable of using Direct Memory Access (DMA) to transfer data without CPU intervention.
The SEL computer used a 32-bit parallel bidirectional High Speed Data (HSD) interface to send and receive data from the radar hardware. Third party companies have developed pin compatible HSD interfaces for other computers. When the SEL was replaced with the 486 computers, a PC compatible version of the HSD interface was installed in the OSF computer. This eliminated the need to develop a new interface for the radar hardware.
The Eglin Test Range has a Centralized Control Facility (CCF) that directs missions and collects data in real-time. A 56 kilobaud synchronous RS-422 serial data link is used to send and receive data from the CCF. To relieve the 486 CPU from the task of becoming directly involved with the transfer of every byte of data, a smart serial card with an on-board V30 processor was installed in the DCC. Data can be transferred rapidly to and from the smart card and a program running on the V30 CPU handles the overhead of sending and receiving each byte over the serial link. The conventional serial ports of the DCC are used to send annotation labels to the strip chart recorders. A serial port on the OSF computer is used to send target position and speed information to a video insertion device.
A 1 kHz signal from the site Time Code Generator is used to synchronize the processing performed by the real-time software. The real time loop must be executed once every 17 milliseconds to provide a faithful simulation. The 1 kHz signal is interfaced to a PCI Timer/Counter board installed in the OSF. The PCI board is programmed to divide the 1 kHz signal by 17 to use as an interrupt input for the OSF. The interrupt is also passed to the other computers in the system via the shared memory interface.
3. Computer Software
3.1 Development/Operating Environment
3.1.1 MSDOS
The MSDOS operating system was chosen for use on this project because of a number of factors. First, all of the personnel available to work on the project had expertise in various aspects of software development under MSDOS. Also, the availability of low cost development tools and support software for the MSDOS environment was a factor in the decision. Probably the most important consideration in choosing the MSDOS operating system was the ability to reuse code developed on other projects, particularly low level device drivers that had many operating system specific dependencies. The reusable code also included an extensive library of subroutines for displaying menus and graphics.
3.1.2 Lahey FORTRAN and Assembly Language
The bulk of the software for the original system installed in 1985 was written in FORTRAN. Naturally to avoid having to recode over 30,000 lines of existing code to other languages such as C or Ada, it was necessary to find a suitable FORTRAN compiler to use under MSDOS. The FORTRAN compiler from Lahey Computer Systems, Inc. was chosen because of its ability to compile large programs that can run in the protected mode of 486 CPUs, allowing code and data segments of up to four gigabytes. The Lahey compiler also supported the use of the faster Weitek math coprocessor.
One drawback to using the Lahey compiler (and indeed, most products running under MSDOS) was the lack of multitasking support, specifically the runtime library subroutines were not designed to be reentrant. To be able to use FORTRAN code as part of the interrupt task, a requirement for this system, it was necessary to save the local data storage area used by Lahey at the beginning of the interrupt task and also the state of the Weitek coprocessor and to restore these to their original state at the completion of the interrupt task.
Low level device drivers were written using assembly language because it was necessary to address specific memory locations and I/O ports to control these devices and this was not possible directly from Lahey FORTRAN. Using assembly language at this level also allowed optimizations for speed to be made. The assembler from Microsoft Corporation was used to assemble these drivers.
3.1.3 Protected Mode Using OS/386
Because segment register values do not point to physical memory segments in protected mode, it is not possible to run protected mode programs directly under MSDOS. Instead, a DOS extender must be used to provide system services in protected mode equivalent to those provided by DOS. Running in protected mode also simplifies the task of writing large programs because 32 bit offset registers can be used to address code and data segments of up to 4 gigabytes in length. OS/386, a DOS extender from Ergo Computing, Inc., was used to allow protected mode programs generated by the Lahey FORTRAN compiler to run under MSDOS. OS/386 handles memory management and switching between real and protected modes. File management and other I/O services are passed on to DOS by OS/386 and are handled by DOS in real mode.
3.2 Operator Site Functions (OSF) Computer
The OSF computer is the main control computer of the system. Most of the interaction with the operators of the system is handled via menus displayed on the OSF screen. The OSF receives the 17 millisecond frame interrupt signal from the site Time Code Generator (a 1 kHz signal that is divided by 17 by a programmable timer board in the OSF) and sends this interrupt to the other computers in the system via the shared memory interface. The OSF handles the I/O with the radar hardware, the RF simulators, and the instrumentation via a High Speed Data (HSD) interface and an IEEE-488 interface. The OSF also controls the setup and execution of the automated tests used to evaluate system performance.
3.2.1 Initialization and Setup
When the OSF program is initiated, a protected mode selector is defined, via a system call to OS/386, that points to the first physical megabyte of memory in the computer. This gives the program access to memory mapped I/O devices, such as the video display and the shared memory interface, and allows programming of other devices that need physical addresses with which to perform DMA, such as the IEEE-488 and HSD interfaces. Interrupt vectors are installed for the HSD interface and the 17 millisecond frame interrupt and both interrupts are enabled. The operator is then presented with the main menu.
Via the main menu, the operator can select to test computer peripherals such as the laser printer and the Bernoulli disks; test the IEEE-488 and HSD interfaces; perform a link check with the CCF; define a sequence of automated tests to be performed on the radar hardware and the specific subsystems to be tested; define real-time mission parameters such as the simulated target characteristics and which data recording devices are to be used; and initiate the start of an automated test or a real-time mission.
3.2.2 Automated Tests
Under OSF control, calibrations and tests are performed on the radar hardware to ensure that the system is functioning within nominal operational limits and to establish current operating parameters to be used during real-time operation of the system. A list of all the automated tests performed by the software is shown below:
3.2.3 Interrupt Processing
In order to provide a faithful simulation in real-time of the actual threat radar system, data must be collected from the radar hardware and output must be obtained from the missile modeling software at least every 17 milliseconds. An interrupt signal derived from the site Time Code Generator is used to initiate I/O with the radar hardware and to trigger the start of a missile model processing cycle.
Whenever the OSF program is running, the frame interrupt is enabled and I/O is performed with the radar hardware to collect data necessary for running automated tests and to display data to the operators on the states and conditions of the radar. However, only during real-time mission operation is the extra processing done to simulate target and missile positions.
3.2.3.1 HSD I/O
The first task performed by the frame interrupt handler is to initiate the start of I/O with the HSD, which is connected to the radar hardware via the Real Time Computer Interface Subsystem (RTCIS). A hardware timing constraint of the RTCIS requires that the I/O must start within 1 millisecond of the frame interrupt or an I/O error will occur. Since no FORTRAN code is used to start HSD I/O, the I/O with the HSD is initiated prior to saving the state of local variables used by the Lahey runtime library subroutines to ensure that the 1 millisecond limit can be met.
Six blocks of data are exchanged with the radar hardware via the HSD and the RTCIS - two output blocks and four input blocks. The HSD uses DMA to transfer the data blocks. At the completion of each data block, the HSD interrupts the CPU so the HSD can be setup to transfer the next block of data. A global flag is set at the completion of the transfer of all six data blocks.
If the I/O completes normally, the data received from the radar hardware is converted to engineering units and saved in global variables for use by the rest of the program. After missile model processing is performed, data to be sent to the radar hardware is packed in an output array in preparation for the next frame interrupt.
3.2.3.2 Video Insertion Generator I/O
A Video Insertion Generator is used to superimpose the TTR azimuth and range and the computed altitude and ground speed of a tracked target on the TTR boresight camera video. A 32 byte data packet with this information is sent to the Video Insertion Generator by the frame interrupt handler using one of the standard COM ports of the OSF computer. Since the frame interrupt processing lasts only a few milliseconds, it is not possible to send the entire data packet at 9600 baud during one frame interrupt. Instead, a buffer is used to store the data for the Video Insertion Generator and the frame interrupt handler sends several characters from this buffer during each interrupt. When transmission of an entire 32 byte packet has been completed, new TTR and target data is stored in the buffer. This provides an acceptable update rate for the Video Insertion Generator.
3.2.3.3 Simulated Target Processing
For testing purposes, a single moving target can be simulated at the RF level. Prior to the start of real-time operation, the operator defines the characteristics of the simulated target flight in one of the setup menus. When real-time operation is initiated, the simulated target scenario begins execution immediately. The frame interrupt handler calculates the current simulated target position based on the previous (or initial) position and the previously defined velocity. Signal levels based on the radar range equation and target off-boresight angles are calculated for use by the RF simulators.
3.2.3.4 Missile Processing
Although most of the missile model processing is handled by the two missile computers, the OSF frame interrupt handler provides inputs to the missile computers, via shared memory, such as launch requests by the operators, measured off-boresight angles and ranges from the radar hardware, and missile termination requests. After new missile position and velocity data is calculated by the missile computers, the frame interrupt handler computes required signal levels and off-boresight angles for the RF simulators in a manner similar to that used for the simulated target.
3.2.3.5 RF Simulator I/O
A 64 byte data packet for target and missile simulation is transmitted to the RF simulators every frame via the IEEE-488 bus. The frame interrupt handler packs the data to be sent to the simulators in a real mode buffer in the first 1 megabyte of memory of the OSF CPU and programs the IEEE-488 interface card to transfer the data using DMA.
Although DMA is used to transfer the data packet, the interface requires port I/O to assert the Attention (ATN) signal on the IEEE-488 bus so that commands such as Unlisten (UNL) and Group Execute Trigger (GET) can be sent on the bus. Therefore, the interrupt handler has to wait for completion of the DMA transfer so that a GET command can be sent to the RF simulators.
3.2.3.6 Shared Memory I/O
The shared memory interface provides a 128 kilobyte common memory block in the address space of all four computers in the system. The frame interrupt handler in the OSF packs data to be logged and data to be sent to the CCF by the Data Collection Computer (DCC) as well as data required by the missile computers into shared memory. The frame interrupt handler unpacks data received from the CCF by the DCC and the new missile state data from the missile computers.
Synchronization of reads and writes of shared memory is handled in a simple manner. Each processor has a dedicated area to which to write data so no two processors try to write to the same shared memory location at the same time. The DCC and the missile computers do not read from shared memory until they receive an interrupt from the OSF computer via a command to the shared memory interface at the end of frame interrupt processing. The OSF does not read from shared memory until the beginning of the next frame. For this reason, no locking mechanisms or flags are needed.
3.3 Data Collection Computer (DCC)
The main purpose of the DCC is to record data collected during real-time operation on disk and to display event messages on the laser printer and the video display. The DCC also handles communication with the CCF.
3.3.1 Initialization
In a manner similar to the OSF computer, the DCC initializes selectors that point to real-mode memory in the first 1 megabyte of its address space in order to access memory mapped I/O devices. A vector for the interrupt handler that processes the interrupts generated by the OSF at the end of each frame is installed and the interrupt is enabled.
One task unique to the DCC is initialization of the Communications Coprocessor (CCP) card that handles the serial communication with the CCF. The CCP has an onboard V30 processor that can be programmed to handle the steps needed to transfer the data. Interface to the DCC processor is via an area of memory that is mapped to the address space of both the DCC and the CCP. During initialization, the DCC transfers the CCP program to this shared memory area and resets the CCP to start execution. The CCP program performs a brief self test of the hardware and reports the status back to the DCC.
3.3.2 Interrupt Processing
The sole source of interrupts to the DCC is the interrupt generated by the OSF computer via the shared memory interface at the end of its frame interrupt processing.
3.3.2.1 Shared Memory I/O
At the beginning of interrupt processing in the DCC, data written to shared memory by other processors in the system is unpacked into global variables. Data received via shared memory that is to be recorded on disk and sent to the CCF is packed in a circular buffer for later processing.
At the end of interrupt processing, data to be sent to other processors, generally target information received from the CCF, is transferred from global variables to shared memory.
3.3.2.2 CCF I/O
On missions where CCF interaction is required, data is sent to the CCF every frame. This data consists of tracked target and missile information and has a length of 20 words (80 bytes). The output data is transferred from the data buffer described in the previous paragraph to the memory mapped area of the CCP serial interface. Double buffering is used by the CCP program so that a block of data can be sent while another block of data is being loaded onto the card. A flag is set in the memory mapped area to notify the CCP program that a block of data is ready to be sent.
Data is also received from the CCF at a non-periodic rate. This data consists of actual target position information as measured by a very accurate radar system on the base and is 21 words (84 bytes) in length. This target position information is used to calculate missile miss distances. The DCC interrupt handler checks flags in the memory mapped area of the CCP card to see if a block of data has been received from the CCF. If so, the data is unpacked into global variables.
3.3.3 Data Logging
During a real-time mission, data is recorded on disk and events such as missile launches and terminations are printed on the laser printer to be used in post mission analysis. Data logging is handled by the DCC main program, i.e., it is not part of the interrupt handler.
3.3.3.1 Disk
The data recorded on disk is the same tracked target and missile information sent to the CCF each frame by the interrupt handler. Ten extra words (40 bytes) are recorded with each record. These extra words are not dedicated to specific information and can be used for recording data of interest to a particular mission. Data is read from the circular buffer packed by the interrupt handler and recorded on disk at a rate such that disk writes occur approximately once per second.
Two 90 megabyte Bernoulli drives with removable storage media are used for data recording. One drive is used until its free disk space is exhausted. At that time, data recording continues on the second drive and the operator is prompted to replace the disk in the first drive with a blank disk. This process can continue indefinitely until the end of the mission.
3.3.3.2 Printer
Events such as missile launches and terminations are time tagged by the OSF and sent to the DCC via shared memory. Generally, these events are not recorded on disk but rather are printed on the laser printer.
The events are coded with one or two integers, depending on whether the event is indicative of a specific one-state event, such as a missile launch, or the event represents a multivalued parameter, such as the state of a rotary switch. Coding the events minimizes the amount of data required to be sent via shared memory. When an event arrives from the OSF, the DCC finds the message to be displayed in a lookup table based on the event number. The message, along with the time tag supplied from the OSF, is sent to the laser printer via the standard parallel port.
During non-real time, the results of automated tests are also displayed on the laser printer. This test result information is transferred to the DCC from the OSF via shared memory.
3.3.3.3 Video Display
During a real-time mission, a split screen display is shown on the DCC video monitor. The top half of the screen displays the accurate target position information received from the CCF. The lower half of the screen shows a scrolling display of the same events printed on the laser printer. This gives the operators timely information on events that occur since the laser printer does not print anything until a whole page has been received.
For this same reason, during the execution of automated tests, the DCC video monitor is used to display the results of the tests (which are also printed on the laser printer) so the operator does not have to wait for an entire page of test results to be ejected from the laser printer.
3.3.3.4 Strip Chart
Events that occur during a real-time mission are also assigned a sequential event number. These event numbers are displayed on the laser printer and video display as described in the previous paragraphs and are also displayed on one of the annotation channels of the strip chart recorder so events can be easily correlated with real-time analog information being recorded by the strip chart pens. Annotation is sent to the strip chart via the standard serial ports of the DCC.
Certain automated tests also use the strip chart annotation channels to display information on the test being conducted. This annotation data is transferred to the DCC from the OSF via shared memory.
3.4 Missile Computers
The system is capable of simulating the flights of up to two command guided missiles in real-time. Two 486 computers, one for each missile, are used to perform the missile model calculations. The missiles are designated "left" and "right" by the system but either missile computer can be set up to do the modeling for either missile. The operation of both missile computers is identical so only one of them will be described here.
3.4.1 Initialization
As is the case with the OSF computer and the DCC, the missile computer sets up a selector to be used to access memory mapped devices in the real address space, in this case, the video display and the shared memory interface. A vector is installed to point to an interrupt handler that catches the interrupts generated by the OSF at the end of frame processing. This interrupt is enabled and the program enters a loop to poll the keyboard for changes in the desired display and to update the selected display.
3.4.2 Interrupt Processing
At the beginning of the interrupt processing, target and missile position data and other status information from the OSF is unpacked from shared memory into global variables. If the missile launch button has been pressed by one of the operators, subroutines are called to initialize and launch a simulated missile. Otherwise, if a missile is already in flight, subroutines are called to simulate the missile guidance computer and the missile autopilot, perform timing and staging checks, and to make airframe state calculations. Data is also collected that will be used to calculate missile miss distance at the end of the flight. If the missile has been terminated by one of the operators, or because the maximum flight time has been exceeded or an error condition occurs, the missile simulation is terminated by calling the appropriate subroutines.
The last task performed by the missile computer interrupt handler is to pack the new missile state data into shared memory so the flights of the missiles can be simulated at the RF level by the OSF computer and so the data can be recorded by the DCC.
3.4.3 Display Update
The main task of the missile computer provides a real-time display of missile and target information. The operator can select one of four displays: two split screen displays of missile and target positions where the top half of the display shows range in meters versus azimuth angle and the bottom half shows range in meters versus altitude in meters; a gunners display which shows the off boresight angle of the target and the missile relative to the TTR pointing angle; and a simulated strip chart display of target tracking errors. For any of the displays, the operator can select to print the current screen on the laser printer.
4. Conclusions
The use of a network of generic 486 computers provided an economical means of replacing an aging minicomputer that was expensive to maintain and becoming more unreliable. In addition to providing the same functionality as the original system, enhancements such as improved operator interfaces and graphical displays were easily incorporated by reusing software modules developed for other projects.
Notwithstanding any language to the contrary, nothing contained herein constitutes nor is intended to constitute an offer, inducement, promise, or contract of any kind. The data contained herein is for informational purposes only and is not represented to be error free. Any links to non-Georgia Tech information are provided as a courtesy. They are not intended to nor do they constitute endorsement by the Georgia Institute of Technology of the linked materials. So there.
Last modified: 09 Sep 98