NASA Office of Logic Design

NASA Office of Logic Design

A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.

NASA SP-504: Space Shuttle Avionics System

Section 3  Data Processing

As indicated in section 2, the state of technology in the early seventies severely limited the choices available in the data processing area. In the early stages of Space Shuttle development, a number of computer configurations were considered including options by which flight control was segregated from guidance and navigation; the guidance, navigation, and control (GN&C) function was separated from other data processing system (DPS) functions; or aerodynamic ascent/entry and space-flight functions were mechanized in different machines. The considerations discussed previously, which led to a tightly coupled, synchronized FO/FS computation requirement for flight control and sequencing functions, drove the system toward a four-machine computer complex. The difficulties involved in attempting to interconnect and operate multiple complexes of machines, possibly of different types and numbers, drove the configuration toward a single complex with central, integrated computation. A fifth machine was added in the final configuration, primarily because of uncertainty as to the future computation requirements which might be placed on the system. Initially, this computer was to be used to off-load nonessential mission applications, payload, and system management tasks from the other four. As will be seen, however, the fifth machine eventually became the host for the backup system flight software.

The size of the Space Shuttle computer memory to be baselined was significantly at issue in the beginning, with estimates running as low as 24k 32-bit words (k = 1024). Sixty-four thousand words of memory were eventually selected as the maximum which could be reasonably included considering the state of the art of computer design and vehicle weight, power, and thermal constraints. Memory limitations were a continuing problem throughout the early development phases and, as soon as technology permitted, the size was increased to l04k.

The program participants unanimously agreed that a top-down, structured methodology was the proper design approach for the Space Shuttle onboard software; however, the use of a high-order language and the selection of an operating system approach were subjects of significant controversy. The NASA had contracted for the development of HAL/S, a high-order language tailored specifically for aerospace avionics applications, but the capability of it, or any other high-order language, to produce code with size, efficiency, and speed comparable to those of an assembly language program was questioned. The issue was resolved after a competition, in which representative software routines were coded by different teams - one using HAL/S; the other, assembly language - showed that the approximate 10 percent loss in efficiency resulting from the use of the high-order language was insignificant when compared to the advantages of increased programmer productivity, program maintainability, and visibility into the software. Therefore, the use of HAL/S was baselined for all software modules except the operating system.

The operating system approaches in contention were a synchronous concept and a concept in which an asynchronous, priority-driven scheme was used. The synchronous approach afforded repeatability, predictability, and visibility into system operations, all attributes which ease testing and verification, but at the expense of adaptability for future growth. The asynchronous concept would readily accommodate growth but was more difficult to verify because it was not as predictable or repeatable. The concept that was finally baselined for the primary system software was a hybrid approach which incorporated a synchronous foreground executive structure and an asynchronous priority-driven background. This approach was considered to be more readily adaptable to any future requirements which might arise.

As indicated previously, data buses were baselined for Space Shuttle vehicle internal signal transmission; however, a number of design issues remained to be settled in this area. Based on advanced development work performed in NASA laboratories, a half-duplex, biphase Manchester code, 1-megabit data bus transmission technique had been selected but questions were raised as to the reliability of such a system to handle critical messages. Techniques for enhancing message correctness statistics were considered including the use of error-detecting codes such as Bose-Chaudhuri-Hocquenghen (BCH) and an echo or answering concept. After an analysis of the predicted word and bit error rates indicated that the basic system coding and message protocol would provide more than adequate signal reliability, an approach without additional protection was baselined for all buses except those which interfaced with the main engine computers. (A design which used the BCH error-detecting code had already been baselined for this interface.) To ensure continued emphasis on performance in this critical area, the data buses and bus interface devices were procured as an integrated system from a single vendor. All other vendors whose subsystems used the data bus system were furnished these standard interfacing devices and required to install them in their line-replaceable units (LRU's).

The number of computer input/output (I/O) ports and associated data buses, and their functional allocation, was also the subject of much discussion in the early design phase. The total system bus traffic density could only be grossly estimated initially, and, because of the catastrophic effects on the system of reaching or exceeding the 1-Mbit/sec bus limits, provisions for significant growth had to be included. The uncertainty in this area and the desire for functional isolation resulted in the baseline 24-bus port configuration, the maximum number which could reasonably be accommodated in the computer I/O processor. Allocation of these buses was based on a combination of factors including criticality, frequency of use, traffic density, and similarity of usage or function.

A summary of baselined requirements and approaches covered in this section includes

Home - NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz