Space Shuttle Primary Flight Software System

SPECIAL SECTION

Paul Schneck Guest Editor Design, Development, Integration: Space Shuttle Primary Flight Software System

The development of Space Shuttle software posed unique requirements above and beyond raw size (30 times larger than Saturn V software), complexity, and criticality.

WILLIAM A. MADDEN and KYLE Y. RONE

The design, development, and integration of the Shuttle services. It is responsible for the guidance, navigation, on-board Primary Avionics Software System (PASS) and flight control functions performed during all flight have posed unique requirements associated with few phases. This includes both the gathering of environ- other aerospace or commercial software systems. These ment and sensor input data and the issuing of com- challenges stem from its size and complexity, its criti- mands to the vehicle effectors (engines and aerosur- cality to completion of the Space Shuttle mission, and faces). It supports all vehicle/ground interface func- from the fact that it is only one of many components of tions with the Launch Processing System at the Ken- an overwhelmingly complex state-of-the-art Space nedy Space Center prior to vehicle lift-off through the Transportation System (STS). launch data bus (LDB). During in-flight operation, the With respect to size and complexity, the software network signal processing (NSP) interface functions are being readied for the first orbital flight test (STS-1) of used for processing of data and/or commands received the Shuttle is actually eight separately executable pro- from the Mission Control Center at the Johnson Space grams or memory configurations sharing a common op- Center. Other software functions include the manage- erating system. These programs are stored on a mass ment and monitoring of on-board systems, fault detec- memory tape device and are loaded into the on-board tion and annunciation, and preflight and preentry computers on crew request (Figure 1). Each is designed checkout and sating procedures. to perform the set of support functions required for the To obtain the required "Fail-operational/Fail-safe" different ground and in-flight phases of Shuttle opera- reliability, the software in certain critical flight phases tions. In all, these eight programs, including the soft- must execute redundantly in multiple computers. To ware operating system, comprise approximately one- achieve this redundancy, an intercomputer synchroni- half million 32-bit words of data and executable in- zation scheme has been developed to guarantee identi- structions. The size is at least 30 times that of the Sat- cal inputs and outputs from the redundant computers. urn V flight software system. It also provides such functions as computer synchronization at rates of up to 330 times per second and control SOFTWARE IS KEY TO SHUTTLE FUNCTIONS of input data to ensure that all computers receive iden- Without software, the Space Shuttle cannot fly. There tical information from redundant sensors whether or are few functions integral to the Shuttle operation for not hardware failures have occurred. which the software does not perform computational Above and beyond the size, complexity, and criticality of the software, several other factors contributed to The present tense of this article, as published in 1980-1981, has been retained in republication. complexity of the development problem. The overall

014 Communications of the ACM September 1984 Volume 27 Number 9 Special Section

Shuttle program schedules required that the software fined, documented, and established before implementa- be certified and ready to support the first orbital flight. tion begins. The requirements on the Shuttle program, However, the detailed definition of all requirements however, evolved during the software development could not be completed in time to support a proven process. The requirements were developed over a long software design, implementation, and verification de- period of time with significant change activity occur- velopment cycle (Figure 2) due to the ongoing vehicle ring after each baseline (Figure 3). Strong interfaces engineering analysis work. Additionally, the Orbiter with the requirements originators were developed to avionic integration and certification activities per- gain an early understanding of the changes. Used in the formed at Houston, Downey, California, Palmdale, Cali- development planning process, this insight enabled ac- fornia, and at the Kennedy Space Center required the curate and timely software deliveries to users. use of the software very early in the development cycle Several factors contributed to the changes in the re- to accomplish certification responsibilites. To satisfy quirements baseline. Primary among these was the tim- these conflicting demands and still deliver a fully veri- ing of the vehicle test program. Because test facility fied, error-free software system consistent with Shuttle resources were being established concurrently and the flight schedules, a development strategy was evolved vehicle was not available, critical aerodynamic and that preserved the effectiveness of the proven develop- structural tests were scheduled after the initial set of ment cycle and satisfied the customer requirements. detailed requirements was provided. The initial re- This paper describes the major elements of the devel- quirements were formulated with the intent of incorpo- opment strategy that evolved. Aspects of the succeeding rating the results of these tests with data changes only; verification and maintenance phases are not addressed however, these goals were not completely realized and here. some significant software design changes resulted. The second most significant factor affecting the re- EARLY INVOLVEMENT IN CUSTOMER quirements was on-board computer resources (core and REQUIREMENTS CPU). Early in the development cycle, projections indi- From an idealistic viewpoint, software should be devel- cated that the computer capacity would be exceeded in oped from a concise set of requirements that are de- both size (core) and load (CPU). After the initial soft-

Function

• DPS H/~V • IMU Calib~atio(1 Interface and arid AJignrrlent Count • Guidance, Subsystems • Fault Annunciation • Guidance, • Mass Memory Checkout • ControlSystem "'m''un'h• Guidance, I Navigabsn, I'--• Guidance, l's'Navtga~on, y m'°n°rngl • Payload Bay Door Navigation, Alterations • Subsystem end Display Navigation. Flight Right Control Right Cootrol Operation Flight Control ~out Checkout Control • Antenna Management OPS SM 9 ~ GNC 9 ~' GNC1/6 ~GNC2 ~' GNC8 ~' SM2 ~'GNC3 PL9

Ascent/Aborts On-Orbit Checkout Systems Management (101.1K) Ut~y (105.2K) (83.1K) (80.3K) (84.1K) (70.1K)

*32-B~tWoods (IncludesOpecating System) ~¢r Y Y •

5/ ,~''~ ' Main Engine Cutoff "~ / • I / ~ia1~.~Z 'Abort-Once-Around Entry ~X ~'~o,°a~`

I Preflight I .....,o I l~t~r0S'l~nglSS~Du~tiOn=54Hrs'30Min* I X...... " ' ...... ' ~A,~r ~ %

~_.#.~_©" l.~-Off

MinOS 20 Minutes

FIGURE 1. Shuttle Mission Profile and Software Memory Configurations

September 1984 Volume 27 Number 9 Communications of the ACM 915 Special Section

\ m

E~E m

-.~ ~ ~-~ ~8~ 8~ ~NB

~ ~ .~_ OJ o

og -- F--~ 2!

~-~ I J

°°~ • ,~

-6 >. "F.

~ ~ _.~

~ ~ ~ .| E_ =~ P.,O

016 Communications of the ACM September 1984 Volume 27 Number 9 Special Section

1975 1976 1977 1978 1979 1980 10 ] 2Q[ 30 [ 4Q 1Q [ 20 i 3QI 40 I IQ I 2Q 130 14Q 1012o 13o I ,o IQ I 2Q I 3Q ] 4Q IQ 12Q 1 3O I =0

Zl 0 0 Phase 1SDR Vehicle Checkout RTLS 1600 & 0 0 rr Entry TAEM, A&L Entry TAEM, A&L G-RTLS Fit. Redundancy Mg~. 0 Ascent, AOA Aborts Control .I Sequencing Displays Ascent AOA Systems Mgt. gJ y O I. 0 L On-Orbit Subsystem Operating j Pr°grams0 /

,, 800-

z 600--

400

Z~ System Design Review (SDR) 0 BaselineRequirements Document ReleaseDate

1Q 12013O I =0 1Q [ 2Q [ 3Q 140 10120130140 lO 12o13o14o 10120130140 1012013014a

FIGURE 3. STS-1 Flight Software Requirements Change Requests (CRs)

ware design optimization, it became obvious that the changing requirements without significant cost or only way to solve the problem was to rework the re- schedule impacts. quirements. This took two forms: deletion of functions and reduction of execution rates. These items caused REQUIREMENTS IMPLEMENTATION PLANNING changes in both the software architecture and the de- In establishing an initial implementation plan, several tailed design. software development and Shuttle program objectives Another factor that strongly influenced change activ- were considered, including the following: ity was exposure of the software to the vehicle and laboratory test environments where real hardware was 1. Implement the most mature requirements first to available, operational procedures were used, and flight minimize rework. crews were training. In many cases, it was found that 2. Release software for verification/certification as the real hardware interfaces differed from those in the soon as possible for maximum exposure and testing. requirements, operational procedures were not fully 3. Support certification of simulation/training facili- supported, and additional or modified functions were ties. required to support the crew. Again these changes fed 4. Support Orbiter fabrication, checkout, and integra- back into both the architecture and detailed design. tion at Palmdale and the Kennedy Space Center. Experience from the Approach and Landing Test (ALT} program had led both NASA and IBM manage- Due to the size, complexity, and evolutionary nature ment to anticipate these problems. A requirements of the program, it was recognized early that the ideal analysis group was formed to provide a systems engi- software development cycle (Figure 3) could not be neering interface between the requirements definition strictly applied and still satisfy the objectives. However, and software implementation worlds and to effect an an implementation approach was devised for STS-1, understanding of the requirements of each. They would which met the objectives by applying the ideal cycle to be the primary people to identify requirements and de- small elements of the overall software package on an sign trade-offs and clearly communicate the implica- iterative basis (Figure 4). tions of the trades to both worlds. This approach proved This approach was based on incremental releases. to be effective and made it possible to accommodate the The releases were first separated into flight phases or

September 1984 Volume 27 Number 9 Communications of the ACM 917 Special Section

1977 1 1978 I 1979 I 1980 I 19131 SIOINID JIF IMIAIMIJIJIAISIOINID J IFIMIAIMIJ IJIAISIOINID JIFIMIAIMIJIJI A ISIOINID JIFIM|A[MI 10,'4 12/5 2/6 3/6 5/4 6/5 7/5 9/4 12/11 2/5 3/19 5/21 7/30 10/16 12/18 2/5 3/18 7/8 9/23 12/16 STS-1 • • • • • • • • • • • • • • • • • • Software ECL PMD2 AOA I ENT | ENT STS-1 STS-I~ CY2 REL13 REL 14 REL 15 REL 16~PS1.2 PS3 PS4 PS5 PS6 PS7/ Releases I I PMD3 FACI KSC UPD 1 FACI UPD i i I~l | I i ,o. I [ I I TI i~R~' IE .... M°d'f'"t'°n' I [ ~°~"'t~°' I En t r'~,' ~ ~ ~ E~ e2 " Update 3 (b E.... ill) Erltry Entry(304-305) C/L 1 Entry(301-305lC/L 2 I~':~,TI Update1 I TM I (CRs/DRs) I (cRdDRs) ! ~ ~c.., I I I I Ascent ~ ', : Ascent Ascent OAscent, Ascent I Update(CRs) I (CRs/DRs) I (CRs/ORs) C/L (.OA) I I I I

Orbit (I) ~{'~] ~ Orbit (I)Orbit Orbit Orbit (CRs/ORs) |(CRs/DRs) C/I 1 c/~2 I I I I I System Management {SM) i I (CRs) ~ (CRs/DRs) (CRs/ORs) PBD I Vehicle I I I I Checkout (i) UpdateI(CRs) --£ Update2(CRs) • (CRs/DRs)vco ,I, vco (VCO) PMD1 G9 (CRs/DRs) S9/P9 (CRs)-- Denotesincorporation of RequirementsChanges (DRs)-- DenotesIncorpocation of DiscrepancyCorrections FIGURE 4. Interim Flight Software Releases

memory configuration, i.e., entry, ascent, and vehicle The last objective of supporting vehicle test was ac- checkout. The first drop for each release represented a complished by phasing the vehicle-checkout function basic set of operational capabilities and provided a development on the same schedule as that of the vehi- structure for adding other capabilities on later drops. cle fabrication and integration. Initial releases sup- The development of the full set of baseline capabilities ported the vehicle fabrication test at Palmdale. Later for each release culminated at a first-article configura- releases incorporated additional capabilities required to tion inspection (FACI) point, which marked the begin- support total system integration and test at Kennedy ning of the verification effort for that release. Space Center. The STS-1 software development program has had 17 interim release drops in a 31-month period starting in FORMULATION OF DEVELOPMENT STANDARDS October 1977 (Figure 4). Although full software capabil- The early formulation of development standards cov- ity was provided after the ninth release in December ered both design and implementation. Following an 1978, an additional eight releases of the software have across-the-board review, the standards were baselined. been necessary to accommodate the continued require- Deviation from the baseline required management and ments changes and discrepancy correction activity in- change control board approval. Compliance with all de- herent in large, complex, first-of-a-kind software sys- velopment standards was checked during each design/ tems. code inspection and a postdevelopment audit with de- This incremental release approach satisfied the origi- viations documented by discrepancy reports (DRs). nal objectives. The mature portions of the Orbital Here are seven subjects that are addressed by the de- Flight Test (OFT) software were those parts most com- velopment standards: mon to the ALT program such as "entry through land- • redundant computer operation/synchronization; ing" and "vehicle checkout." These were developed first. Other parts were built and integrated into the • data homogeneity; system incrementally until the final FACI release was • processor and I/O rates, priorities, and phasing; reached. • interprocess data protection; The second and third objectives were uniquely satis- • program structuring and language utilization; fied by the development approach. The software was exposed in small increments to both verification and • module/data naming conventions; field users. This allowed early identification of software • design documentation and code commentary. discrepancies and eased problem resolution. The software was incrementally exposed to the simulators. THE DESIGN AND IMPLEMENTATION PROCESS Thus, the simulator checkout was completed in an en- The architectural foundation for the OFT flight soft- vironment where the number of variables could be ware (Figure 5) was the ALT system with six primary controlled, thus easing problem isolation. features:

918 Communications of the ACM September 1984 Volume 27 Number 9 Special Section

Flight computer operating system (FCOS} to support re- Flight software system generation and maintenance fa- dundant computer operations/synchronization and the cilities, including the HAL/S compiler, IBM AP-101 as- basic functions of process management, I/O manage- sembler, linkage editor, program library management, ment, and DPS configuration management. Also in- and mass memory build facilities. cluded is the set of service macros (SVCs) for the soft- Software Development Laboratory (SDL), including the ware interface to the FCOS and external hardware. flight software system generation and maintenance fa- System control (SC) functions to support system initiali- cilities and the facilities to simulate environment and zation, memory overlay/loading, and DPS configuration vehicle subsystem operations with which the flight initialization. software could be tested and debugged. User interface (UI) functions to support user input proc- Basic GN&C entry, system management, and vehicle essing, output display/message generation, and applica- checkout applications software. tions process controls. A set of macros called the control segment grammar provides the capability to de- In addition to the system foundation used from ALT, velop standard application control logic and display/ the management and technical experience gained in keyboard interface structures. ALT also was beneficial. To successfully implement the

Orbiier Ground Orbiter Subsystems Support Avionics Ii MassMemory rl Kevb°ardDisplay il OtherGPC's Hardware SYstems Hardware Units Units ICC I lr / '[1

I ,I I/ \\ / \ I/O Management / \ / \ / FCOS Service Interface (SVC's)

SYSTEM CONTROL

Command Input Output Message Processing I Processing E

USER INTERFACE r- Operations Control E 0

Control Segment (OPS/SPEC)

c- O_ uO o,)

APPLICATION PROCESSES

FLIGHT COMPUTER OPERATING SYSTEM

D-On-board software

FIGURE 5. Software Architecture

September 1984 Volume27 Number9 Communications of the ACM 919 Special Section

much more complex OFT flight software, a more disci- Very early in the development cycle, while the re- plined and structured development approach was fol- quirements definition was in process, a small group of lowed (Figure 6). Increased emphasis was given in the the more experienced programmers (system design "front end" aspects of the development cycle, including team) designed the control segment structures for the requirements definition, system design, standards defi- different memory configurations required for OFT. Si- nition, top-down development, and identification of de- multaneously, the existing ALT system software velopment tools requirements and the resultant tools (FCOS/SC/UI) was installed in new OFT program li- (Figures 7 and 8). Similarly, during implementation, braries. It was checked out to ensure its use as a base to added emphasis in design/code reviews and testing implement modifications needed for OFT to reduce helped achieve the required software reliability within size, improve reliability and performance, and extend customer schedules. capabilities, In addition to steps taken to participate in the re- The design team developed top-level control segment quirements definition and the development of an incre- structures, which were implemented and tested with mental release strategy, a significant degree of planning ALT base system software. As the requirements defini- was accomplished relative to the design implementation process evolved, modifications were made to im- tion process. This addressed both the implementation plement more detail or lower level aspects of the struc- and maintenance of the existing ALT system, and the tures. Where anticipated but undefined requirements development of the top-level OFT design structure. Pro- were known, "stubs" were implemented. Stubs enable cedures for development of the design structure, modi- software linkage to proceed without execution, and fication enhancements of the base ALT system, and thus, testing can be continued. Throughout this evolu- implementation of new OFT functional and detail re- tionary process, the implemented structure was tested quirements were put into place. on a continuing basis to ensure the overall system sta-

HAL/S I I" APlOl POD I I Language I I And Support I Orbiter Avionics I Orbiter Avionics I I Software / I

~ Programmiog "~~ Standards Requirements/FormulationDefinition Definition \

R I SystemLVL A J Functional LVL B I Detail LVL C ;rt°ng r;a:~r~ ing I I Software I I Software I Software I Requirements I I Requirements I Requirements

Detail Design ~ ~ Design Design Definition ~ ~ Definition

~ Design Development Inspection Software Functional Inspection Detail Lab (SDL) And Design Design And Design Requirements CPU/MEM Spec. ~ Spec. CPU/MEM Spec. Definition Projq tion

Iso I Preliminary Critical RequirementsI Design Design ~Document Review Review

Software Implementation

FIGURE 6. Fflight Software Requirements and Design

920 Contmunications of the ACM September 1984 Volume 27 Number 9 Special Section

FIGURE 7. Flight Code Generation

bility. Continued testing established a sound building- the overview and consistency of all elements of the block approach and also provided training valuable to detailed design. Memory and CPU projections were up- programmers for interfacing with the system and for dated on a continuing basis. This process generated a learning software implementation and configuration detailed design containing a "code to" level of detail, control procedures. including module structure and interfaces, database When the definition of system (Level A) and func- definition and organization, equations and algorithms, tional (Level B) requirements was accomplished and I/O data tables and interprocess variable data protec- baselined at system design reviews, the software function. Upon completion of the detailed design for each tional design was completed and documented. Major module, a formal design review was held with analysts elements were the memory size and CPU loading pro- and programmers to assure compliance with require- jections that were developed based on the overall sys- ments and standards, correctness, completeness, effi- tem structure that had been implemented and the an- ciency, and adequacy of interfaces. Design inspections ticipated detail requirements. A preliminary design re- were tracked during development and the results docu- view was held with NASA and associate contractors to mented. When the detail design for all software was critique and approve the design. This established a completed, a critical design review was held with the baseline for subsequent detailed requirements and de- Shuttle community where the design was approved and sign development. baselined for implementation. As the detail (Level C} requirements and associated The implementation phase was performed with the design evolved, the development environment became same attitude toward understanding, completeness, more production oriented with an increased number of consistency, and overall planned system approach as people involved. The design team was responsible for was done for the design phase. The preparation and

September 1984 Volume 27 Number 9 Communications of the ACM 921 Special Section

development testing of Orbiter flight code utilized the ual process since the master system was updated on a same ground rules of top-down, structured develop- three-week cycle. Postbuild testing was performed be- ment. The resource of the HAL/S high-level language, fore release of the new master system to ensure contin- which is particularly suited for top-down structured ued stability. Build results were documented and coding, was especially helpful during this phase. This widely distributed to the project to provide visibility resource permitted coding the functional design of the into the status of the integration process and the master major elements of the flight software system. The system (Figure 8). higher level modules were coded while leaving the As a flight software release neared completion, a final lower levels as undefined and {for the time) unneeded programming standards audit was performed. This au- stubs. This orderly procedure was very useful because dit was conducted using both automated and manually it allowed coding and testing of the higher level logic generated data and emphasized multicomputer redun- and algorithms in the total development process. To dant set operations, interprocess variable data protec- generate flight code, the production and test facilities of tion, overlap of data processing with I/O, process the SDL are used (Figure 7). Use of a high-level lan- schedu!ing and termination, and restricted instructions guage coupled with improved development techniques and sequencing. The status and results of this audit and tools doubled productivity over comparable Apollo were presented at a FACI, which marked the comple- development processes. tion of the baseline requirements implementation and Each coded module of software was subjected to a the start of formal verification. code inspection with an audit team to ensure that the code was consistent with requirements, design, and AN INTEGRATED TEST APPROACH standards, and efficient in terms of memory and CPU. The improved implementation methods and controls Each review process was tracked in the software devel- used during the development process help to produce opment plans, and review results were documented. software with fewer latent errors. However, assurance Upon completion of module coding, review, and unit that the software is error-free can be gained only by a testing (Level 1), each module was scheduled for inclu- well-structured form of testing. Early in OFT, determi- sion into the baseline master system. This was a contin- nation was made that an integrated test approach was

New "1 Software ] Source I Discrepancy Modules I Reports New I I Master New I .~w~m | Source ~ Progr; mmil Object ~ ~,-~.~ ~ Library Stand |rds INTEGRATION & VERIFICATION TESTING Modules F-J I : Audit r"~ SDLP=tl I- Te:t ! New li:Lu __ I i..j ~ ' I ~ Master AP 01 t APt01 CEo; z;' ion oh, Edi :or Est I/O Mgt / DPS Cnfg Mgt MMU t I SVs Cnt / ProcessMgt m 1 Applications Interface I Approved I _1 ILOADab B~ledi'/nRe~lease I -I ara, ,,er GN&C MFB VCO SM ~___= • MFB MFB

G1/6 G2 G3 G9 G8 $9 P9 S2 lass lemory luild :acility

~| Release Patch i wl Devel°pment , .

FIGURE 8. Flight Software Integration

922 Communications of the ACM September 1984 Volume 27 Number 9 Special Section required to control the testing process across the project. Several goals were set forth to ensure a successful test approach: establishment of documentation and control to ensure visibility into the testing process, establishment of test execution and documentation standards, and parallel test planning during the design process. The key element of this test approach, however, was development of a test management approach that emphasized a hierarchical ordering of development tests that allowed for continual integration of program parts as they were developed and a systematic sequence of evaluation tests on the flight software system (Figure 9). During the development period, compilation units were added to the master system via the system build process, which was invoked cyclically. Parts of the processing associated with each cyclic master system update were tested to determine the preservation of the Space Shuttle "Enterprise," as it flew during the Approach and software's basic capabilities on that particular master Landing Tests, provided beneficial technical and management system update. Also, more detailed tests were used to experience needed for the more disciplined and structured determine the quantitative status of the new capabili- development approach used in developing the more complex ties that had completed testing. The former testing was Orbital Flight Test flight software. termed "regression testing"; the latter, "new capabilities testing." All specified test plans were documented in an integrated test plan that covered all phases of testing. plications programs from the integrity of the algorithms to the interfaces with the system software were exer- Level 1 Testing (Unit) cised. Completion of the Level 3 tests was one of the During the development activity, specific testing was key milestones in the path to releasing a system for done to ensure that the mathematical equations and verification and the field usage. The test results were logic paths provided the results expected. These algo- documented in development test reports. rithms and logic paths were checked for accuracy and, where possible, compared against results from external Level 4 Testing (System) sources and against the system design specification Level 4 testing exercised control logic interfaces, opera- (SDS). The testing activity occurred in parallel with tional sequence (OPS) transitions, mode-to-mode transi- new capability testing but was accomplished by the tions, specialist function (SPEC) operations, and display development programmer. The test results were docu- processing in a multiple flight computer environment. mented by means of a unit test checklist. Inter- and intracomputer interfaces (overlays, data transfers and timing, and process synchronization) were Level 2 Testing (Functional) tested to check the hardware and software interfaces in the SDL environment. The test results were docu- The Level 2 facet of the development test activity was mented in the development test reports. similar to the Level 1 testing. However, the Level 1 testing described above was expanded to test modules that interfaced with each other in the total functional Level 5 Testing (Release Validation) Prior to delivering the software to field users, the Level environment and that are required to satisfy a specific 4 tested end item was loaded into a hardware mass user input command. It combined modules that by de- memory and a system test was executed in one of the sign operated in conjunction with each other and tested NASA simulation/training facilities. This was to verify them as a function against the SDS and the require- that the delivered software would function in the most ments. This activity was accomplished in parallel with realistic hardware environment available. The test re- ongoing new capability testing. Test results were docu- suits were presented with the delivery. mented in development test reports. CONFIGURATION CONTROL Level 3 Testing (Subsystem) One of the most complicating factors that affected the Level 3 testing demonstrated the ability of a subsystem development of the Orbiter avionics software was the to execute its nominal functions in a simplex flight extremely large number of people involved. This in- computer environment (e.g., fly an ascent trajectory or cluded not only the programming staff but also those perform self-test of part of the vehicle hardware). These involved in requirements definition, SDL development, tests were the first real indicators of the software per- verification, and field support. Coupled together with formance as an integrated system. All facets of the ap- the previously mentioned high degree of requirements

September 1984 Volume 27 Number 9 Communications of the ACM 023 Special Section

Title SHUTTLEPRIMARY FLIGHTSOFTWARE IV & V I Date [ Page of _ FAe, CI FRR 77-- OEVE,OPMENT VERI FICATION ~ VALIDATION~ plF Vnl iiu© ~'r~ ~ DELIVERY OF "~ VOLUME 2 ITP I `= VOLUME 3 ITP S/WCOMP~ NENTSTO MAgi TER SYSTEM J l i EQUATIONS LEVEL1 PATHS TESTING RANGE OF VALUES

LEVEL2 • UNITINTERFACES TESTING • USER COMMANDS • FUNCTIONAL INTERFACES LEVEL3 • MULTIPLE FUNCTIONS I TESTING • TIMING LEVEL 4 • SYSTEM INTERFACES TESTING • MISSION PROFILE • MASS MEMORY UTILIZATION I LEVEL5 • TAPE/LISTING VALIDATION TESTING • SYSTEM LEVEL TEST

LEVEL 6 TIMING INTERFERENCE TESTING DETAILEDFUNCTIONAL TESTS PERFORMANCE I TESTINGLEVEL 7 _j~e ACCEPTANCETESTS I .-A t' MISSION UNIQUE ) CONTINUOUS INTEGRATION \ TESTING j ( (POST BUILD, REGRESSION. & FLOOR RELEASE VALIDATION) A (~ DELIVERYOF ) (~ DELIVERYOF ) S/W SYSTEMTO S/W SYSTEM TO THE USERS & VERIFICATION THE NASA

FIGURE 9. Levels of Testing

change, the incremental releases of early versions of nism to achieve strict configuration control. Each board the software, and the overall size and complexity of the that was responsible for assessing and scheduling software itself, a very complicated configuration man- changes kept an up-to-date log of all recommendations agement problem was created. that were brought to the BCB for approval. After re- In order to gain control of this situation, an internal view, all items that were approved were documented in control/coordination board structure was established. a project baseline report. Changes not authorized by This started with a requirements review board (RRB), this report were not allowed on builds. Similarly, items where the assessment of all requirements changes was scheduled, but not supported, were analyzed very thor- coordinated. A baselines control board (BCB) was estab- oughly. lished to coordinate and control the system build/ Changes to approved configuration baselines, which release schedule planning and associated content con- evolved from design changes, requirements change re- figuration definition/control. Eventually the structure quests (CRs), or software discrepancy reports (DRs), was expanded to include five different review/control were coordinated through the appropriate boards (inter- boards (Figure 10). Results, actions, and recommenda- nal) and ultimately approved by NASA. This structure tions of these five independent boards were coordi- allowed an internal coordination of a total impact and nated through a project baselines control board, which then provided one central, coordinated assessment to in turn interfaced with spacecraft software division the NASA control boards reflecting IBM's position or configuration control board (SSD CCB) and the orbiter changes. This applies to both application software base- avionics software control board (OASCB). lines and support software. Membership of the internal review boards included Documentation of approved baselines was subse- representatives from all affected project areas. This quently reported and monitored in project management projectwide representation enhanced communication plans, orbiter management review monthly presenta- among functional organizations and provided a mecha- tions, and Shuttle avionics software schedule baseline

924 Communications of the ACM September 1984 Volume 27 Number 9 Special Section

TitJe ONBOARD FLIGHT SOFTWARE SYSTEM I Date 8120/80 I Page47 of 95

OASCB Responsible For Flight T&O BOARD ! Software Change Control • Special Patches • Primary i Orbiter n MMU Element • Backup Avionics Schedules a Engine Controller Software • Waiver Reviews • Etc Control • DR Dispositions Board t SSD CCB Responsible For Assess- Spacecraft ments And Recommendation Software For Primary Software Changes Division • Impacts Change • schedules Control • Delivery Contents Board NASA IBM t- Requirements Review B( • Flight Software Change Impact • Flight Software Change Schedu • Requirements h • NASA Control

Support Systems Reviav • Support Softw~ Impact Assessn~ • Support Softws Scheduling • Support Softwa Issues Review ,,, , ,,,,,,,,, ,

FIGURE 10. Configuration Control Boards Structure

and planning data package. Audits to verify consistency • establishment of design and code reviews and au- between approved baselines and reported baselines dits, were performed weekly by the project office. • establishment of an integrated test approach for the entire development process, and SUMMARY • configuration control of the incremental build and Since the software package is an integral and critical integration of the evolving software system. part of the Shuttle systems, a development and testing approach was employed that ensured that the software met customer requirements, performed in accordance CR Categories and Subject Descriptors: C.4 [Performance of Sys- tems]--reliability, availability, and serviceability; D.2.2 [Software Engi- with Shuttle operational requirements, and was deliv- neering]: Tools and Techniques;D.2.5 [Software Engineering]: Testing ered to users with minimum errors. In order to develop and Debugging;D.2.9 [Software Engineering]: Management--software and deliver a software system that met these goals, the quality assurance; D,4.5 [Operating Systems]: Reliability;J.2 [Physical Science and Engineering]--aerospace; K.6.3 [Managementof Computing development organization addressed the following and Information Systems]: Software Management--software develop- areas: ment, software maintenance General Terms: Design, Management,Reliability, Verification • early involvement with software requirements gen- Additional Key Words and Phrases: avionicssystem, PASS, space eration, shuttle • development of a reasonable requirements implementation plan, Authors' Present Address: WilliamA. Madden and Kyle Y. Rone, IBM, Federal Systems Division,1322 Space Park Drive, Houston, TX 77058. • early identification of development standards,

• utilization of top-down, structured implementation Permission to reprint this article is granted by the Technical Directions techniques, maga~'ine,a publicationof the IBM Federal Systems Division.

September 1984 Volume 27 Number 9 Communications of the ACM 025