/ / /
Real-Time Simulation in Project Mercury / 55
/ /
/ / / /
RANGE, AZIMUTH, ELEVATION DATA FOR ALL SITES
SELECTED RADAR DATA TAPE
SHREDDED DATA IN RADAR FORMAT WITH TIME TAGS
~----' AND ERRORS
SHRED TAPE SORTED BY TIME TAGS
DATA GENERATION PROCEDURE FOR MERCURY SIMULATION SYSTEM
Figure 1
56 / Computers - Key to Total Systems Control flight profile and the entering of varying error conditions.
The Observer program is used to generate basic flight profile. If the profile is to con-tain launch data a series of position and ve-locity vectors for the powered flight portion of the trajectory are obtained from the missile guidance equations. From this data is ob-tained the insertion conditions at burnout. If launch data is not to be used then the insertion conditions must be given as input data.
Using the insertion conditions Observer now computes the orbit by numerical integra-tion giving posiintegra-tion and velocity vectors for as many orbits as specified by the input data.
The data also specifies re-entry conditions.
This is either in the form of retro-rocket firing time or desired impact area. If the retrofiring time is given the change in ve-locity is computed and the re-entry trajectory computed. If the impact area is given, stations and computers all the Range, Azimuth and Elevation readings which are in range of each station. These R, A, and E readings are all now written on Observers final output tape. perturbations of the data are called for. Sta-tions may be left out or made to start trans-mission late or early. Different types of errors for application to the data, such as different noise levels, bias errors, transmis-sion errors and pathological errors are now called for. It is here that all the major troubles that can occur during a real flight may be specified so that the full capabilities and the limitations of the Mercury program may be tested.
The Shred program processes the Selector outputs to produce simulated inputs. Since the function of this routine is primarily one Technology Laboratories. These consist of launch inputs representing GE-Burroughs Atlas Guidance Computer outputs and pOSition, velocity vectors which are used to calculate IP 709 outputs. From these two sets of inputs Shred produces images that reflect what would be in the Goddard or Bermuda computers at the time of an input interrupt. The different images are: GE-Burroughs, IP 709, and High-Speed raw radar for Goddard each with its 72 bit telemetry message; low-speed TTY Verlort or FPS-16 radar inputs for Goddard;
high-speed Verlort and FPS-16 radar for Bermuda; and Bermuda'S 64 bit telemetry message.
Shred has three methods for introducing variations into the true input values. Each routine is independent of the other and while none individually are in any sense sophisti-cated in combination they have proven to be quite satisfactory. One routine is used to introduce random errors which simulate the general radar noise. The second routine forces certain bits in the message to always be one's. We call these errors pathological errors and ostensible rep res e n t frozen encoders. The third type of error routine is for transmission error simulation.
Random errors are added to measurements according to an input standard deviation and a normal dis t rib uti 0 n. Sixteen different standard deviations are allowed for each run.
A code associated with the input vector de-termines which sigma is to be used in the particular case.
So called pathological errors are bit pat-terns which are used to turn on the matching one bits in the true value. Again, 16 patterns are provided with the desired pattern specified by a code associated with the input vector.
Pathological errors put a varying positive bias into the readings.
Transmission errors are simulated by either altering, dropping, or adding a com-puter word in the input message. A probabil-ity of error is associated with each word of output and if a calculated random number (from a rectangular distribution) is less than the probability of error, an error is applied.
The form of the error is determined by a similar technique using three conditional probabilities. Each routine can have a dif-ferent transmission error table and within
one table three different probabilities of error are provided. The probability to be used is determined by a code associated with the input vector.
A constant error, that is, a bias error, is simulated by adding the desired amount of bias during the calibrating.
When writing Shred a primary assumption was made that, no matter how vehemently and dogmatically stated, all message formats and parameter units would change. Thus, the pro-gram was written to be modified and great use was made of tables, input parameters and switches. This turned out very well for sure enough there is not one output produced by Shred that has not changed at least once and some several times. Units have changed, sampling rates have changed, ranges of values have changed, telemetry bits have changed, message lengths have changed, subchannels to be used have changed. However, since this was expected, measures were taken to live with the situation.
A typical example of programmed flexibil-ity is the unit conversion routine for radars.
There are only two types of radars presently used and Shred's input vectors represent the radar readings although in different units, thus all that is required to convert a reading
"r" to "R" is:
if A, then R = r x X A
if B, then R
=
r x X B •However, since it is always possible a differ-ent radar type might be suddenly installed or biased conversions required, the following scheme was used. A table containing the X and a constant for each radar parameter was set up for each type of radar. A second table of addresses referencing one of the conver-sion factors table was set up using station number (a unique radar site identification) as an argument to define which of the con-version factors table to be used. Thus add a new radar type-make a new conversion table and add its location in the control table;
change units of input-change the conversion table; if "biased" readings are required-make the constants non-zero. The tables have been modified several times in the past year and will be modified again but the basic calculating routine will not be touched.
Shred will of course produce quite varied runs. It is of interest to note that most errors
Real-Time Simulation in Project Mercury / 57 are applied at random thus a specific error for one observation is not a normal type of operation (it can be done with bias or with pathological errors). This was done primarily to discourage people from concentrating too much looking for certain oddball cases where the effect is essentially known anyway, and to encourage testing with general error levels.
The feeling here is that the unexpected and potentially disastrous type or combination of errors could best be discovered by using a monte carlo technique as opposed to a pre-conceived set of errors.
On the whole this approach appears to though we had good success USing perturbed inputs, some of the most interesting bugs, however, showed up using error free data.
One worthy note occurred in editing. Exten-sive use is made of s tat i s tic a 1 editing throughout the system, however, the original coding failed to protect against zero or very small standard deviations thus perfect inputs turned out to be unacceptable. The coding program, readily modified, but also one that requires a good deal of esorteric skill to operate.
The output from Shred can take several forms. For the powered flight portion of the trajectory an unsorted high speed data tape is produced. This represents the data which is received from Cape Canaveral. For the orbit and re-entry pOSitions of the trajectory an unsorted low speed data tape is produced.
This represents the teletype data normally received from the remote sites. SIC which will be described next.
58 / Computers - Key to Total Systems Control