The Mercury Programming System - COMPUTERS - KEY TO TOTAL SYSTEMS CONTROL

Marilyn B. Scott and Robert Hoffman International Business Machines Corporation

Federal Systems Division Washington, D. C.

The Mercury Programming System was designed to meet the specific objective of tracking the Mercury spacecraft during all possible phases of light-launch, abort, orbit and re-entry, and to predict continually the spacecraft impact point so that a safe and speedy recovery of the Mercury astronaut could be effected.

To perform this task, two IBM 7090 IS,

operating in parallel at NASA's Goddard Space Flight Center at Greenbelt, Maryland, receive data by teletype from digital data transmitters associated with radars around the world and by high-speed data links from the Cape Canaveral Complex. In turn, the 7090's feed high-speed data to displays at Goddard and the Cape and send acquisition messages by teletype to remote sites.

Each 7090 has attached to it 12 magnetic tape drives, an on-line printer, punch and card-reader, and an IBM 7281 Data Commu-nications ChanneJ (DDC), which allows data to be transmitted directly to and from the 32-thousand-word core memory of the 7090.

Each Data Communications Channel can han-dle data on each of 32 subchannels. In the Mercury, system we currently receive data through the DCC from 17 TTY inputs, two high-speed inputs, a WWV minute signal, and a half - second signal. We send data through the DeC to two high-spee,d outputs, three TTY outputs, and a sense output console.

The two 7090' s operate in parallel to pro-vide backup. Although both receive all inputs, only one is transmitting its computed output to remote sites at any given instant. Both machines, however, feed local displays and

send output to the sense console which indi-cates the status of each and provides the means for switching outputs from one com-puter or the other.

All of the input/output devices used in the Mercury Programming System produce traps to signal entry or exit of data to and from core memory. A trap is the automatic trans-fer of control to a preset location in core when one or more conditions are met. In reading a magnetic tape, for example, if a certain instruction is used to request a rec-ord, an indicator will be set in the computer when that record has been brought into core memory. This condition, Le., the "on" status of the indicator, will cause a transfer of trol to lower memory. This transfer of con-trol, or trap, will occur only if the machine is "enabled." The computer is said to be

"enabled" when traps are permitted to occur and "disabled" when they are not. The ma-chine may be enabled for one or more condi-tions and disabled simultaneously for others.

The machine enters the enabled or disabled mode through execution of a programmed instruc tion.

There is one other mode of operation upon which the programming system relies. This is the "inhibited" mode. This mode is entered automatically when a trap occurs. While the machine is inhibited, no further traps may occur until the machine is re-enabled, thereby guaranteeing that necessary, work may be ac-complished without interruption.

These, then, are the three modes of oper-ations: (1) enabled-a trap may occur; (2) disabled-a trap may not occur; and (3)

48 / Computers - Key to Total Systems Control which are hardware-oriented; those which are task-oriented; and those which are in-dependent of both task and equipment and serve to control the interaction and lines of flow among all the other routines in the system.

The first category of routines-those that are hardware-oriented-is concerned with receipt and transmission of input and output.

These routines are entered through trapping and are called "trap processors." Since traps may occur asynchronously, even simultane-ously, trap processors must respond fast enough to receive all the information from any given source without loss of information from any other source. This is accomplished by (1) allowing all trap processors to operate completely in the inhibited mode in which they are entered by trapping, and (2) requir-ing that every individual trap processor be written to act fast enough so that the worst combination 0 f simultaneous input/output stimuli will not result in an undesirable loss of information from any source. A typical trap processor might complete its operation and restore trapping in less than one milli-second. At present there are 23 trap proc-essors in the Mercury system to handle at least as many reasons for trapping.

The teletype input trap processor handles a six-character byte of teletype data from anyone of 17 teletype transmitters, and moves it to an area for use by the teletype input program. The teletype output trap processor receives control each time six characters of teletype information have left the machine, and refills the output area until a complete message is sent. The high-speed input and output trap processors accomplish the same functions for data traveling at the rate of 1000 bits per second. The printer trap proc-essor tells the system that the on-line printer is available for further output.

Two trap processors handle the timing for the system. One takes control every half-second on receipt of a half -half-second pulse and calculates the need for computing output and feeding displays. It also updates the current Greenwich mean time within the machine upon which all time tags are based. The other timing trap proces'sor recognizes receipt of

a WWV minute Signal and checks that the timing of the system is correct.

Other trap processors signal the trans-mission of data to the sense console and be-tween core memory and magnetic tapes.

Tapes are used for bringing in programs when they are needed, for bringing in such data as location and atmospheric conditions of remote sites, for writing out a log of all data which enters or leaves the system, and for gener-ating or reading restart parameters for use in the event of machine failure. Each of these

The second category of routines are those which are task-oriented. The objective of tracking and predicting the landing point of the Mercury capsule is accomplished by diverse procedures during each of the four possible phases of flight. During launch and low aborts, while the capsule is still within range of Cape Canaveral and its radars, the programs are receiving telemetry and com-putedpositional data from the IP 7090 and the GE-Burroughs Guidance Computer. They also accept high-speed raw r~dar data. The inputs are arriving at the 1000 bits per second rate and displays are being fed every half-second in launch and every second in abort. The only station which receives acquisition messages during these two phases is Bermuda.

In high aborts, those occurring near in-sertion, both high-speed computed data and low-speed raw radar may be received. Many of the programs of both launch and orbit are required. For instance, the high abort phase requires the use of both the launch program to interpret telemetry data from high-speed sources and the orbital integration program to compute impact point. In orbit the output display rate changes to once every six sec-onds and no high-speed data is received. Ac-quisition is sent to more than 20 telemetry and radar sites around the world. The acqui-sition messages are sent at the sjx-character per second TTY rate and are sent three times per orbit for each station with lead times of approximately 45, 25, and 5 minutes before the spacecraft crosses the local horizon. The orbital programs generate a prediction table which cover three orbits, receive raw radar data, edit it, and use it to differentially cor-rect the prediction table. From this table,

data concerning present and predicted posi-tion are calculated. From it the time to fire the retro-rockets to bring the spacecraft back to earth is computed and displayed. During the re-entry phase the display rate changes to once every three seconds, twice the rate of the orbit displays. Different quantities are calculated and acquisition data is sent with less lead time.

The routines which combine to accomplish the tasks of the various phases are called

"ordinary processors." They operate in the enabled mode, Le., they may be interrupted at any point. These ordinary processors are programs in themselves, require no sub-routine linkage and can be unit-tested before they are incorporated into the operating sys-tem.

At present there are more than 40 ordinary processors in the Mercury Programming System. They include edit program, teletype code conversion routines, coordinate conver-sion routines, output generators, a retro-fire calculation routine, a numerical integration program, a differential correction program, and a host of others. Because these proc-essors accomplish specific tasks and are completely independent programs, they may be considered the building blocks of the Mer-cury system. By using them in different combinations and at different frequencies, we can use the same routines to perform differ-ent tasks. The use of such building blocks minimizes the amount of programming re-quired to meet the obj ectives of the system, and provides good flexibility in meeting addi-tional specifications. Furthermore, t his modular concept spares programmers of ordinary processors the job of understanding the complexities of real-time control and equipment idiosyncracies, whereas the re-maining programmers need not concern them-selves with the mathematics of the ordinary processors. called "prefixes" and "suffixes." There is at least one prefix and one suffix for each ordinary processor. A prefix precedes pro-gram and performs such functions as placing inputs required by the program in a prescribed location. The first instruction of the prefix is the entry point to the ordinary processor.

The Mercury Programming System / 49 The prefix may be said to set the scene for entering the processor. The suffix does just the opposite. It ties up loose ends after the processor is completed, such as making the computed results of the program available for use in the system.

In addition the prefixes and suffixes pro-vide the liaison between the ordinary proc-essors and the third category of routines, those that control the interaction and lines of flow between the various elements of the sys-tern. The programs in the third group are called the controllers or monitor routines.

The controllers maintain the proper sequence of operations between the various processors, and, in accordance with the modular concept, are completely independent of these proc-essors' Le., they would accomplish ~he same functions no matter what processors they monitor.

Implicit in the nature of the ordinary proc-essors and trap procproc-essors is a relative priority among them. Since the ordinary processors operate in the enabled mode, con-trol may pass to one of the trap processors at any moment. Therefore, as a group, the trap processors enjoy a higher priority in the system than the ordinary processors. Prior-ity among the trap processors is a function of data rate and built-in priority in the hardware.

Among the ordinary processors, however, priority is dictated by urgency of introducing their output into the system and the length of requires more than three seconds for execu-tion must be given a priority lower than the three second display program, or the system will fail to output on time. It may well enjoy a priority higher than the minutes processor, however. The relative priorities of the ordi-nary processors are established in a table called the priority table.

The heart of the monitor system is a con-troller routine called PRIO. Every ordinary processor and trap processor returns control to PRIO upon completion of their tasks. Both ordinary and trap processors can determine the need for entering other routines in the system. They convey this requirement to PRIO by setting indicators in the priority table. PRIO must examine these indicators

50 / Computers - Key to Total Systems Control and give control to the proper routine in ac-cordance with their relative priorities.

Since ordinary processors can be trapped at any time or any place, this priority scheme affords multiple levels o~ interruption. For example, the orbit prediction updating pro-gram may be interrupted by the half-second clock trap processor, whereupon this trap processor determines that it is time for the higher priority, acquisition data .generator to send predicted orbit parameters to sites ahead of the spacecraft. When the half -second trap processor returns control to PRIO, con-trol must now be passed to the beginning of the acquisition data generator. But the fact that the orbit prediction update was. originally interrupted must not be forgotten.

Once PRIO has given control to the acqui-sition data generator, it too can be inter-rupted, say, by the teletype input trap proc-essor transmitting radar data from a tracking site. And now this trap processor indicates to PRIO the need for the teletype conversion processor, and this has a higher priority than the acquisition data generator, etc., 'until there may be as many interrupts as there are levels of priority. To control such situations, a system of remembering a stack of interrupts is provided by two controllers, SAVE and RTRN.

The very first duty of any trap processor is to enter SAVE to preserve the condition of the machine's program-accessible registers and the return address. Each time SAVE is entered, these items are preserved in a save block assigned to the interrupted routine.

Whenever PRIO sees that all higher priority routines have been serviced, control is passed to RTRN which restores the machine'S condi-tions according to the save block and returns control to the interrupted routine at the inter-rupt point. This save-and-restore procedure holds for all traps except those which occur within PRIO and RTRN. By permitting SAVE to ignore traps from within PRIO and R TRN, control functions are made more responsive to the expediencies of the real-time environ-ment than to the lower priority requireenviron-ments of the ordinary processors. Thus trapping takes priority over anything PRIO or RTRN are doing.

How is the priority system applied to the ordinary processors?

Associated with each ordinary processor are t~ree kinds of indicators which convey

control sequence requirements of the system to the controller PRIO:

1. The "A" indicator is turned on by a processor if it is in process.

2. The "B" indi~ator is turned on for a given processor if a need for its oper-ation has been determined.

3. C, D, E . . . . indicators for a given processor are turned on if a need has been determined to suppress its oper-ation.

The entry point to each ordinary proc essor appears in the priority table together with the indicators associated with that routine. (The indicators are merely bits in a word.) The routine whose indicators are examined first by PRIO has the highest priority.

Suppress indicators for a given ordinary processor take precedence over its A and B indicators in that PRIO examines them first.

PRIO will not transfer control to any routine whose suppress indicators are 0 n. Each ordinary processor has a specific suppress indicator for each individual condition which requires its suppression. If no suppress bit one additional request for X's operation has been made. When both A and B are on, there-fore, PRIO will return control through RTRN to the interrupt point in X, leaving the B indi-cator on for future control. If only the B in-dicator is on for ordinary proc essor X, PRIO transfers control to the beginning of X. The first act of every ordinary processor thus entered at the starting location is to turn its own A indicator on, and its last act before transferring control back to PRIO is to turn off its A indicator. Thus, in the event it is interrupted before completion, each ordinary processor provides an indication to PRIO that it is in process.

Indicator B can indicate that more than one request has been made for the operation of its associated ordinary processor. This is ac-complished by queueing, a proc edure in which one or more requests for a given routine are indicated by placing information in a table, called a queue table. An entry in the queue table can simply indicate a request for oper-ation, or it can also include information tell-ing where input is to be found or where output is to be placed, etc. For instance, an ordinary

processor which determines the need for sending acquisition data to radar sites places entries, by queueing, in the queue tables for the teletype output processors, telling them which sites are to receive data. Entries are placed in the queue table in the order in which they occur. After turning on its A indicator, the output processor turns off its B indicator if it has no queue or if it is not desired to have PRIO cycle control to it repeated for some reason. If the routine has a queue, the routine itself must enter the disabled mode and test, while disabled, whether it is not processing the last request in its queue. If the last request is being processed, B is turned off. If not, B stays on, so that the other requests may be answered in turn until the queue is emptied. In either case, the test must be followed by an enabling instruction since a 11 ordinary processors must run enabled. The B indicator for a given routine may be turned on by any ordinary processor, trap processor or controller which deter-mines the need for that routine to be executed.

The optimum assignment of priorities for ordinary processors can only be done through careful study of the system in a real or sim-ulated environment. However, the assignment of priorities is not as rigid as it might ap-pear, for both suppression and trapping in reality constitute dynamic modification of the priority system in response to real-time events. A reasonable first approximation of the optimum priority assignment might be constructed from consideration of the levels of input/output timing requirements.

This, then, is the basic Mercury Monitor real-time control system w h i c h combine groups of processors to handle the demands of any particular phase of the Mercury flight:

controllers, which maintain sequence control between ordinary processors in an environ-ment of asynchronous interrupts, handled and interpreted by trap processors.

The use of this modular concept has proved to be of enormous advantage in coping with the seemingly ever-changing system specifica-tions.

One of the benefits derived from this ap-proach is perhaps Significant for all large, complex real-time control systems under-going a continuous growth process: efficient use of large scale computer systems by

Im Dokument COMPUTERS - KEY TO TOTAL SYSTEMS CONTROL (Seite 63-68)