The data processing complex includes the following key features:
- Five GPC's mechanized in a parallel-redundant digital computation system
- Software programs combined in individual memory loads which provide all required subsystem, vehicle, and mission services
- Multiplexed data transmission with standardized subsystem interfaces
- Distributed I/O through remotely located multiplexer/demultiplexer (MDM) units
- Multifunctional cathode-ray-tube (CRT) displays/keyboards
- Mass program storage in two tape memory units
The five GPC's are identical IBM AP-101B machines. Each GPC is packaged in two boxes, one containing the central processing unit (CPU) and part of the memory (80k 32-bit words), the other containing the input/output processor (IOP) and the rest of the memory (24k 32-bit words). A GPC upgrade, to the AP-101S, is currently under way in the program. This upgrade will combine the CPU and the IOP into one package and increase the memory to 256k. All GPC's are wired alike with both discrete and serial digital I/O provisions. The discretes are used for computer moding, control, synchronization, station identification, and redundancy management. Twenty-four serial digital ports provide the interfaces with the rest of the avionics system. Each port has a bus control element (BCE), which is under software control and which can be individually enabled to transmit and receive on the respective data bus. The transmit/receive configuration of the ports on each machine is automatically established by the resident software, using the station identification discretes and other information to determine its location or slot. It is possible, however, to reconfigure ports and GPC string assignments manually to accommodate failures. The function, the authority, and the capability of a GPC at any given point in the mission are established by the applications software resident in the machine. For example, if a computer is loaded with a GN&C (ascent, on-orbit, entry) program, it will assume control of the bus ports assigned to its slot to obtain access to flight control sensor data and to provide a command path to the required control effectors.During dynamic phases of the mission, such as ascent and entry, four of the machines are loaded with the same software and operate in a "redundant set," with each assigned a set of data buses giving control of a set of sensors and control effectors. The fifth GPC is loaded with a backup program capable, when selected, of communicating on all buses to provide for mission completion or safe return from any point in the mission. To prevent divergence while operating in a redundant set, it has proven necessary both to synchronize the processes within the machines and to provide them with identical input data. The synchronization (synch) technique mechanized uses "synch points" inserted at appropriate locations in the software. When a synch point occurs, each computer stops execution, notifies the other machines by way of synch discretes that it is ready for synchronization, and waits for receipt of corresponding synch discretes from the rest of the redundant set. When all discretes are received, execution resumes and continues until the next synch point occurs. If all discretes are not received within a preset time limit, the synchronized computers resume execution and declare any nonresponsive GPC to be "failed." Common input data are provided to each of the computers in the redundant set through the use of the "listen mode," a provision which allows a machine to receive information on a data bus not under its control. In this mode, illustrated in figure 4-8, each GPC enables the receivers only, on the I/O ports that access the buses assigned to the other computers in the set. When sensor data are requested by a controlling machine, the others monitor and retrieve the transmitted data. For example, GPC 1 may request data from rate gyro 1 on flight control bus 1. When the data are transmitted, also on bus 1, GPC's 2, 3, and 4 - operating in the listen mode on their bus 1 ports - retrieve the data simultaneously with GPC 1.
Concurrently, GPC's 2, 3, and 4 will be requesting data from the rate gyros under their control, and each will monitor the others' data. Using this technique, all GPC's have simultaneous access to all redundant data used in an application, yet each string maintains independence from a control or interference standpoint.
Figure 4-8. - Listen mode.
Two essentially independent software systems have been developed to operate the Orbiter avionics system. The primary avionics system software (PASS), consisting of several memory loads, is normally used to perform virtually all mission and system functions. The backup flight system (BFS) software, consisting of one memory load, is used only during critical mission phases to provide an alternate means of orbital insertion or return to Earth if a failure occurs in the PASS.
Primary Avionics System Software
The PASS is structured from the user point of view into three major functions (MF's):
- Guidance, Navigation, and Control (GNC)
- System Management (SM)
- Payload (PL)
Because the software required to satisfy all Space Shuttle requirements greatly exceeds the memory capacity of a GPC, each of these MF's is further structured into operational sequences (OPS), which are collections of programs and capabilities required to conduct a phase of the mission or perform an integrated function. The OPS, either individually or in combination, form memory configurations, which are loaded into the GPC's from onboard tape units called mass memories. The current set of memory configurations is shown in figure 4-9, associated with the mission phase in which each is active. To the extent possible, the OPS are structured so as to require memory overlays only in quiescent, nondynamic periods. The substructure within the OPS consists of major modes, specialist functions (SPEC's), and display functions (DISP's). Each OPS has one or more major modes, which are further substructured into blocks that segment the processes into steps or sequences. (See fig. 4-10.) The blocks are linked to CRT display pages and, therefore, establish an orderly sequence by which the crew can monitor and control the function. Sequencing from mode/block to mode/block and internal processing can be initiated by keyboard entry from the crew or, in some cases, can be initiated automatically in response to a specific event or condition detected by the software. The SPEC function, initiated only by keyboard entry, also contains blocks that are linked to CRT pages and that establish and present the valid keyboard entry options available to the crew for controlling the operation or monitoring the process. Major modes accomplish the primary functions within an OPS, whereas SPEC's are used for secondary or background functions. The DISP functions, also initiated by keyboard input, contain no processing other than that necessary to produce the display; and are used only for monitoring data processing results.
Figure 4-9. - Memory configurations.
Figure 4-10. - OPS substructure
The software architecture embodied in each PASS memory configuration is shown in figure 4-11. The application processes which make up the major functions of a given memory load are shown in the lower inner block of the diagram, essentially isolated by the system software. The control segment manages the sequencing of all processing required within an OPS, a major mode, or a SPEC, and defmes the associated CRT displays and keyboard entry options. The user interface consists of three primary functions: command input processing, operations control, and output message processing. User interfaces supported in addition to the keyboards and CRT's include the launch data bus used to communicate with the LPS while on the ground, the network signal processor used to process data and commands received by way of the radiofrequency (RF) communications links, and the intercomputer buses used to communicate between GPC's.
Figure 4-11. - Software architecture
The system control function performs initialization and configuration control of the data processing complex including the associated data bus network. The flight computer operating system (FCOS) functions can be grouped into three main categories: process management, by which the allocation of all internal computer resources is controlled; I/O management, by which the allocation of the IOP resources is controlled; and DPS configuration management, by which loading of computer memories and sequencing and control of the GPC and IOP operating states are accomplished.
Memory configurations are structured as shown in figure 4-12 to minimize the size of the overlay required when changing from one OPS to another. The system software base includes code and data common to all OPS loads and major functions. The major function base contains code and data common to a major applications function used in more than one OPS load. The OPS overlay contains the applications code and data unique to an OPS load. Main memory loading occurs during the transition from one OPS to another in response to a major function switch selection and keyboard entry from the crew. The contents of the OPS in progress determine which of the three parts must be loaded for support of the new OPS. For instance, the transition of the GNC computers from ascent to on- orbit to entry OPS requires only the OPS overlay; however, to establish SM2 in one of the machines after the ascent phase is completed, a major function base overlay is required as well. Memory loads can be made either from mass memory or from another GPC already loaded with the desired configuration.
System software base Major function base overlay OPS overlay
- I/O mgmt
- Config mgmt
- Sys control
- Proc mgmnt
- Appl I/F
- OPS X
(within major function)
Figure 4-12. - GPC memory configuration
Backup Flight System
The BFS consists of the designated GPC, three backup flight controllers (BFC's), the backup software, and associated switches and displays. Anyone of the five central GPC's can be designated the backup machine by appropriate keyboard entry. The GPC selected will request the backup software load from mass memory and operate in an alert standby mode thereafter. During normal operations, while the Space Shuttle is under control of the primary redundant-set system, the backup system operates in the listen mode to monitor and obtain data from all prime machines and their assigned sensors. Acquisition of these data allows the BFS to maintain computational currency and, thus, the capability to assume control of the Space Shuttle at any time. At the option of the crew, data from the backup machine can be displayed on one of the cockpit CRT displays for monitoring purposes. Backup data are also available on the instrumentation downlink. Backup system control of the Space Shuttle can only be engaged manually using a pushbutton thumb switch on either right or left rotational hand controller (RHC). When either of these switches is depressed, logic in the BFC's transfers control of all required data buses from the redundant-set machines to the designated backup machine.
The software package for the BFS has been independently developed and coded to reduce the possibility of generic software errors common to the primary system. The entire BFS is contained in one memory configuration, loaded before lift-off and normally maintained in that machine throughout the mission to provide independence from the mass memories. To reduce the crew training required, the BFS software is organized similarly to the PASS into operational sequences and major modes with SPEC and DISP functions; however, only OPS1 (ascent) and OPS3 (entry) are supported. Although all required guidance, navigation, flight control, sequencing, and system management functions are included, generally, only the simplest mode is mechanized. Limited on-orbit attitude stabilization is provided using the last major mode of OPS1. The intent is to reload and return to the PASS if a stable orbit has been achieved. The system software uses a synchronous approach and, therefore, is significantly simpler than is the FCOS.
Digital Data Bus System
Twenty-eight data buses connect the GPC complex to BTU's distributed throughout the vehicle. Each data bus has a 1-Mbit/sec clock rate, is formatted in Manchester II code, and provides multiple word/message correctness checks. The bus system consists of standard multiplexer interface adapters (MIA's), data bus couplers (DBC's), data bus isolation amplifiers (DBIA's), and twisted, shielded wire pairs. To ensure standardization, performance, and compatibility, the bus elements were purchased from a single manufacturer and MIA's were supplied to all BTU designers for installation in their LRU's. The major bus characteristics are listed in figure 4-13. The system operates in a command/response mode with all bus control vested in the GPC's. The allowable data bus word configurations are shown in figure 4-14. All bus traffic is initiated by command words transmitted by the GPC's. If the intent is to transmit data from a computer to a BTU, a command word is sent first as an indicator of a forthcoming data transmission, followed by the required number of data words. To obtain data from a BTU, the computer sends a command word requesting the type and amount of data. The BTU then responds with the desired number of words. In all cases, the expected word count must be correct or the entire message is rejected. The 28 data buses are allocated by functional use, criticality, and traffic load into categories as shown in table 4-1. The data bus structure interconnecting the GPC's and the various BTU's is shown in figure 4-15, which is a distillation of information contained in the system block diagram. (Again, the reader is urged to maintain correspondence between the figures which are used to emphasize a feature or function of the system and the system block diagram.) The BTU's and their acronyms are listed in the lower left corner of figure 4-15. The attributes of each of these are discussed in sections to follow. The eight flight-critical buses are used for all traffic (data and commands) associated with guidance, navigation, flight control, mission sequences such as separation, and management of critical nonavionics system functions. Also included is the interface with the Space Shuttle main engine controller. Eight buses are required for these critical functions both to provide the necessary fault tolerance and to spread the traffic load. Five buses are devoted to intercomputer data transmission. Each computer acts as the bus controller on one of the five buses and is therefore capable of initiating communications with the other four machines. Two buses interconnect the five computers to the two mass memory units (MMU's). These buses are used for loading of software programs as required throughout the mission. Four buses provide the interface between the five GPC's and the general-purpose CRT display and keyboard equipment. These buses comprise the primary interface between the crew and the DPS. Five buses are used for instrumentation data. These buses are unique in that each computer has a dedicated bus connected to a port on dual pulse code modulation (PCM) master units. They are used to transmit downlink data and to acquire data gathered by the operational instrumentation (01) system needed for onboard system management and caution and warning functions. Two buses provide an interface for payload support operations, system management functions, payload bay door control, and communications antenna switching. Finally, two buses provide access to the launch processing system while on the ground, serve as the interface for data gathered from the solid rocket boosters, and control the remote manipulator. These buses are unique in that they require isolation amplifiers both to accommodate the long wire runs to the LPS and to isolate the buses when disconnected at lift-off and SRB separation.
Table 4-I. - Data Bus Utilization
- 1 Mbps clock rate
- Manchester II code format
- Multiple word/message correctness checks
Multiplexer interface adapter (MIA)
- Standardized LRU interface to data bus
- Converts NAZ from host to Manchester II
- Generates synch bits; assigns parity bits
- Checks data validity
Data bus coupler (DBC)Signal coupling between bus and LRU
- Transformer coupling/isolation
- Impedance matching
Data bus isolation amplifier (DBIA)
- In ground support equipment and SRB interfaces
- Amplification for long wire runs
- Isolation for guillotined signals
Figure 4-13. - Data bus characteristics.
Figure 4-14. - Data bus message formats.
Figure 4-15. - Data bus architecture
Bus Terminal Units
The BTU's provide the interface between the computer complex and the rest of the avionics system and other vehicle systems which are supported by the avionics system. They can be considered to be a form of distributed input/output in that they extend the serial digital interface throughout the vehicle to locations as near the subsystems served as practicable. As indicated previously, each BTU contains one or more standard MIA's. The following discussions of each type of BTU are limited to physical and functional characteristics. Their use in a system sense is covered in the treatment. of each subsystem and function contained in subsequent sections. The reader is urged to use figure 4-15 and the system block diagram to maintain correspondence with the overall system.
The MDM is a flexible, multipurpose device which provides a variety of interface capabilities. Figure 4-16 is a simplified block diagram showing the redundant bus interface on the DPS side and the I/O modules (IOM's) on the subsystem side. The MDM recognizes and reacts to any valid, correctly addressed data bus transmission detected by either MIA; however, simultaneous or overlapping messages on both buses are not allowed and, if received, will cause the unit to halt. Normally, overlapping messages are precluded by the system architecture and configuration. The sequence control unit (SCU) controls the operation of the MDM and contains programmable read only memory (PROM), which can be programmed to acquire large blocks of data with a single request. The 16 I/O slots can be populated with a mix of 9 different types of modules from the following list:
- Discrete output high (DOH), 28 volts, three l6-bit channels
- Discrete output low (DOL), 5 volts, three l6-bit channels
- Discrete input high (DIH), 28 volts, three l6-bit channels
- Discrete input low (DIL), 5 volts, three l6-bit channels
- Analog output differential (AOD), 16 channels
- Analog input differential (AID), 16 channels
- Analog input single-ended (AIS), 32 channels
- Serial input/output (SIO), four channels
- Tacan/radar altimeter (special-purpose I/O)
Figure 4-16. - Multiplexer/demultiplexer block diagram
The system interface requirements for each MDM are dependent on its unique location in the Space Shuttle vehicle and determine the mix of I/O modules installed. The MDM's are located in both avionics bays and in the two SRB's as near the subsystems serviced as possible. The following three-part MDM nomenclature convention is used:
- First letter - Data bus category
- F - Flight critical
- L - Ground or launch
- P - Payload operations
- 0 - Operational instrumentation
- Second letter - Location
- F - Forward
A -Aft L - Left SRB R - Right SRB Number - Number in a set
Mass Memory Units
Two MMU's are installed in the Orbiter, each connected to a dedicated bus and addressable from any GPC. They are magnetic tape units with random access storage capacity of 4.2 x 106 32-bit words. They provide nonvolatile onboard software storage for the following:
- System software
- Duplicate copies of application programs
- Overlay program segments
- CRT display formats
- Prelaunch test routines
- Fault isolation diagnostic test programs
- I-loads (mission- and hardware-unique data)
- Checkpoint data
- Downlink data formats
Control of MMU read/write operations is from the GPC's.
Master Events Controller
Two master events controllers (MEC's) are installed within the Orbiter to provide the control interface for critical lift-off and stage-separation functions including control of the pyrotechnic initiator controllers (PIC's). Figure 4-17 is a simplified block diagram of an MEC. The critical signal selection operates both on a comparison of the four inputs and on the relative timing of the arm and fire commands. This mechanization is required because the functions controlled by the MEC's are unique in that they must occur at the proper time and must be prevented from occurring at all other times.
Figure 4-17. - Master events controller.
Engine Interface Unit
Figure 4-18 is a block diagram of the engine interface unit (EIU) showing the four Orbiter bus inputs, the internal logic in the device, and the three-command/two-data-return bus interface with the main engine controller. The EIU converts the commands received from the GPC's on the Orbiter buses to the engine bus protocol, which includes the use of the Bose-Chaudhuri-Hocquenghen (BCH) error-detecting code. Commands received on inputs 1 and 2 are passed through on engine buses 1 and 2. The first command received on either input 3 or input 4 is selected and passed to engine bus 3. The EIU is also used to acquire high-rate telemetry data from the engines on two buses and to selectively pass it to the Orbiter telemetry system and the GPC's.
Figure 4-18. - Engine interface unit.
Display Driver Unit
The display driver unit (DDU), the driver for the primary flight control displays, has four data bus inputs. The bus which actually drives the displays is manually selected by the flightcrew using a rotary switch. The serial digital input data stream is converted in the DDU to appropriate analog signals required to drive the various flight instruments.
Display Electronics Unit
The display electronics unit (DEU) is the device which drives the general-purpose CRT's and accepts crew inputs from the alphanumeric keyboard. Each DEU has one data bus input and contains an IBM SP-0 special-purpose processor with 8k l6-bit words of memory used to store critical CRT formats and DEU software. Display and refresh of static formats selected by GPC command is performed locally by the DEU; however, dynamic data are provided by the GPC's, integrated into the static format by the DEU, and refreshed as required depending on the sample rate. Keyboard keystrokes are detected by the DEU, evaluated for validity, and transmitted to the GPC if correct.
PCM Master Unit
The PCM master unit (PCMMU) is the data acquisition, formatting, and multiplexing unit in the instrumentation system, and each has five computer data bus inputs, one dedicated to each GPC. These units are used both for transmission of computer data to be incorporated into the telemetry downlink data stream and for acquisition by the GPC's of instrumentation data for use in system management and caution and warning functions. Each PCMMU also has two instrumentation data bus inputs. These interface with the OF and OA MDM's, which comprise the instrumentation network. The active PCMMU serves as the bus controller on these buses.
Manipulator Controller Interface Unit
The manipulator controller interface unit (MCIU) is the control computer for the remote manipulator system (RMS). It has one data bus port used for receipt of moding and outer loop control signals from the GPC's.
Master Timing Unit
The master timing unit (MTU) is the primary source of time and frequency information for the spacecraft. It is not, by the definition, a BTU because it provides time information through three flight-critical MDM's, but it is described here because of its intimate interface with the data processing complex. The MTU contains two independent 4.608-megahertz crystal oscillators operating in an active/standby mode. Built-in drift detectors monitor oscillator performance and cause an automatic switchover if an out-of-limits condition occurs. Frequency dividers, counters, and accumulators are included to develop the various outputs required.
DPS Redundancy Management
The DPS, when configured in the redundant set, is designed to operate, when failures are experienced, in a manner so as to require minimal action on the part of the flightcrew. The system will maintain full operation through any single failure with no action whatever. To provide protection against subsequent failures, however, the flightcrew is required to deactivate disabled components as soon as the opportunity arises. Extensive fault detection and annunciation capability is provided to the flightcrew on the dedicated displays and on the multifunction CRT's. Each GPC continuously assesses its own functionality and that of the other machines in the redundant set. This assessment produces discrete outputs, which cause lights to be illuminated on the annunciator display unit (ADU) located on the front overhead panel. The ADU contains a five-by five-light matrix with a row and a column designated for each GPC as shown in figure 4-19. Each GPC controls one row of lights - the yellow (Y) is its self-assessment; the white (W) is its assessment of the other machines. The GPC's have extensive built-in test capability and will shut down automatically if failures are detected. No computer or set of computers can cause another to shut down, however. This action must be taken by the crew, based on an evaluation of the ADU and other system information available.
Figure 4-19. - Annunciator display unit.
The architecture of the data bus network also provides failure protection with no immediate response required by the crew. Figure 4-20 contains a view of this architecture which illustrates the multiple interconnectability of the computers and the BTU's. In this figure, the computer ports are shown configured for a nominal ascent mission phase with GPC 5 selected as the backup computer. Note that each primary GPC has control of two flight-critical buses, one flight forward and one flight aft. These buses each connect to redundant ports on one flight forward and one flight aft MDM with primary and secondary status as shown. These flight-critical MDM's, in general, provide access to one-fourth of the sensors and one-fourth of the control effectors required to fly the vehicle. With this arrangement, the system can withstand any two failures in the computers, the buses, or the MDM's and remain operational without reconfiguration, providing no failures exist in effectors in active strings. If the failure situation warrants, the system can be manually reconfigured to maximize the number and effectiveness of the available LRU's remaining. For instance, if communication is lost to one or more of the flight forward MDM's, the system can be manually reconfigured by way of keyboard input to communicate with these MDM's on the flight aft buses and the secondary ports. To keep the software sequences as identical as possible, any such reconfiguration will cause all primary GPC's to switch to the secondary ports. The MEC's and the DDU's have four inputs each and therefore can sustain the loss of any two GPC's without loss of function. The EIU's also have four inputs, but two of these are switched such that the first input is selected for the third output. Therefore, loss of two nonswitched inputs will cause loss of one EIU. A broader view of the redundancy management features of the avionics system is contained in the following sections.
Figure 4-20. - Data bus control.
NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz