,

20029-H006-RO-00

PROJECT TECHNICAL REPORT

TASK ASPO - 92

EXECUTIVE SUMMARY

ANALYSIS OF THE APOLLO SPACECRAFTOPERATIONAL DATA MANAGEMENT SYSTEM

NAS 9-12330 DECEMBER 1971

Prepared forNATIONAL AERONAUTICS AND SPACE ADMINISTRATION

MANNED SPACECRAFT CENTERHOUSTON, TEXAS

Prepared byTRW Systems

Houston OperationsSpace Park Drive

Houston, Texas 77058. , ,~ .':-

"". ~. '1,.

'. :,~ ': J ,i

:. . ~ ..... 'I,

'''\. - '. -_. -- .-

(CATE~R'Y)

fI

(NASA-CR-115422) ANALYSIS OF THE APOLLOSPACECRAFT OPERATIONAL DATA MANAGEMENTSYSTEM. EXECUTIVE SUMMARY (TRW Systems)Dec. 1971 27 P CSCL 05C\\' '

, ~ (N~SA c~ aR TMt 6"R ~D ~;M\'@'\""\

G3/34

N72-18981

Unclas17620

,';-,j'" .>- ..

... - .......~",~.- .

.,

"

r-I OPEN " Reproduced by \

NATIONAL TECHNICALINFORMATION SERVICE

Spn"ngfield, Va. 22151 J

https://ntrs.nasa.gov/search.jsp?R=19720011331 2018-07-08T12:27:32+00:00Z

NAS 9-12330

20029-H006-RO-00

PROJECT TECHNICAL REPORT

TASK ASPO - 92

EXECUTIVE SUMMARY

ANALYSIS OF THE APOLLO SPACECRAFTOPERATIONAL DATA MANAGEMENT SYSTEM

DECEMBER 1971

Prepared forNATIONAL AERONAUTICS AND SPACE ADMINISTRATION

MANNED SPACECRAFT CENTERHOUSTON, TEXAS

Prepared byTRW Systems

Houston Operations

TRW

PREFACE

This Executive Summary provides a synopsis of the final report preparedunder MSC/TRW Task ASPO-92, IIApollo Spacecraft Operational Data ManagementSystem Analysis. 1I During the course of this three-month study, topicalworking papers were presented and discussed at bi-weekly MSC/TRW reviewmeetings. The study final report is based on restructured and clarifiedversions of these papers. Since this Summary and the Final Report havediffering orders of content, the Summary text provides references to thatReport to facilitate quests for greater detail.

CONTENTS

Page

1. INTRODUCTION .

2. ANALYSIS OF PRESENT DATA MANAGEMENT SYSTEMS.

1

2

2.1 APOLLO AND SKYLAB. . . . . . 2

2.1.1 System Description. . 22.1.2 Problems Experienced. 22.1.3 Conclusions. . . . . . . . . . . . . . . . . . . . 72.1.4 Recommendations for Apollo and Skylab Improvements. 7

2.2 DATA MANAGEMENT SYSTEMS OTHER THAN APOLLO AND SKYLAB 8

10

12

12

. . . . 13

15

~ . 16

2.2.1 Titan II and Minuteman. . . . . . . . . . . . . 82.2.2 Cheyenne. . . . . . . . . . . . . . . . . . . 82.2.3 Kentucky. . . . . . . . . . . . . . . . . . . . 9

3. REQUIREMENTS FOR FUTURE OPERATIONAL DATA MANAGEMENTSYSTEMS. . . . . . . . . . . . . . . . . . . . . . .

4.2 SYSTEM CONCEPT.

4.3 IMPLEMENTATION.

5. AUTOMATED DATA MANAGEMENT TECHNIQUES

4. AN INFORMATION SYSTEM FOR A FUTURE SPACECRAFT PROGRAM

4.1 GENERAL ....

6. DEVELOPMENT OF OPERATIONAL DATA REQUIREMENTS . 21

i

1. INTRODUCTION

The purpose of Task ASPO-92 was to study Apollo, Skylab and severalother data management systems to learn what techniques can be applied tothe management of operational data for future manned spacecraft programs.Operational data is defined as:

"Data which describe spacecraft and spacecraftsubsystems performance capabilities and limita­tions, and which are required to accomplish mis­sion planning, analysis, and/or real time support."

The study was performed by: 1) analyzing present data management systems,2) developing requirements for future operational data management systems,3) ~valuating automated data management techniques, and 4) preparing a planfor data management applicable to future space programs. As this studyprogressed, it became increasingly evident that cost-effective managementof spacecraft operational data must include consideration of other techni­cal data such as test results, configuration control, and reliability. Theinterplay between data sources, data users, and program time phasing pro­duces a situation where operational data can be made largely a by-productof other data-producing activities of the program. Furthermore, the pro­cesses which produce the purely technical data are also potential generatorsof management data required for program visibility and decision-making. Itwas concluded that a cost-effective approach to operational data lay in thedirection of an integrated data base containing at least the technical andmanagement information of the program.

This conclusion is reflected in the plan recommended for future programs,a plan based on the potential utility to MSC of a center-wide InformationManagement System (IMS) serving all Center Groups. The IMS would be useroriented, have several coordinated elements, and function as a service. Theuser determines how he will apply the IMS to his needs and what data he willmanage. One element of the system would promote commonality, set standards,establish procedures, encourage compatibility among users, and provide usertraining in the IMS application. Other elements would provide computer-baseddata processing functions and those functions not feasible for automation.

1

2. ANALYSIS OF PRESENT DATA MANAGEMENT SYSTEMS

2.1 APOLLO AND SKYLAB

2.1.1 System Description. The Apollo Operational Data Management System(OMS) began in 1965, when the need for a single authoritative source forspacecraft operational data was recognized by the Apollo Spacecraft ProgramOffice and the Mission Planning and Analysis Division. Since then thesystem has evolved to meet the needs of the Apollo Program as it progressedthrough the mission planning and operational phases. The present Apollosystem produces the Spacecraft Operational Data Book (SODB) which is aseven-volume Class I document, and also provides additional data as re­quired by the many individual data users. While this system uses a com­puter to perform certain calculations, it is considered to be a manualsystem because all major activities are performed manually, and data arehandled, formatted, and published manually. Skylab activities began twoyears later than Apollo with an Operational OMS similar to that ofApollo. Skylab operational data are published in a five-volume OperationalData Book (ODB). A simplified flow diagram and description of the Apolloand Skylab Operational Data Management Systems are presented in Figure 1.Detailed flow diagrams and descriptions are contained in Appendix A of theFinal Report, and the contents of both the SODB and the ODB are describedin Appendix D.

While the Apollo and Skylab DMS's are similar, two factors necessi­tated study of both systems, viz.;

1) The Skylab system was structured to avoid some early Apollosystem problems. An assessment of the effectiveness ofthese changes is required.

2) The Skylab system involves two NASA field centers (while the

Apollo system is captive to MSC) and is more representative of thefuture situation with multi-center data management functions.

2.1.2 Problems Experienced. The management objective of the Apolloand Skylab spacecraft operational data systems has been simple: to obtainand provide accurate spacecraft data in a timely fashion to satisfy the

2

SOOB-ODB BASIC DATA FLOW

DATA 7REQUI REMENTS

IMPOSED ONSUPPLIER

,1 CONTRACTOR 2 3 IF FORMAT 5 6

NASA/CONTRACTOR CONCURRENCE ~ NASA SSM APP. MSC SIGN-OFF- ~ ---- USERDATA SUBMITTAL MSC & TRW APP. EVALUATION PUBLISH &EVALUATION DISTRIBUTE

J~ ---,--

IF NOT APP.

IF NOTAPP. RESOLVE 4

DISCREPANCIES.DELETE ORPUBLISH ASNASA DATA SOURCE

...........................................................................?~!.~ ..~~9.~L~~~~~:: '"

OPERATIONAL DATA FLOW DESCRIPTION

The basic functional flow as shown above is representative of both theApollo and Skylab Operational Data Management Systems. The basic functionsare as follows:

1. In fulfillment of MSC data requirements, data are submitted bythe responsible contractor (or NASA) to MSC for incorporationin the SOOB or OOB.

2. Oata submitted by NASA or contractors are evaluated for incorpor­ation in the SOOB or OOB.

3. If the data are approved by the contractor and/or Program Office,the data are given to the NASA SSM for evaluation and validation.

4. If the data are not approved for SOOB-ODB incorporation by thecontractor and/or Program Office, an attempt is made to resolvediscrepancies and delete inappropriate data; without resolution,the data are published as a NASA Oata Source (without contractorconcurrence) .

5. After data approval by the SSM, MSC approves, formats, publishesand distributes the data to the designated standard and specialusers.

6. As the user identifies more data requirements to satisfy hisplanning needs, he submits data requirements to the ProgramOffice. The Program Office evaluates the requirements versusthe need to obtain these additional data at no additional costsor added costs (as the case may be).

7. If these data requirements are approved, the data requirementsare imposed on the appropriate data supplier who will preparedata submittals and forward them (as described in 1. above) toMSC.

Figure 1. SODB-ODB Basic Data Flow

3

requirements of the large data user community. However, implementation toaccomplish this objective in the real world has been more complex. Someof this complexity is caused by the need to define data requirements con­current with design of the techniques for use of the data, e.g., softwaremodeling, and the need to use data prior to development of the spacecraftsystems which the data must characterize. During the early planning phaseof Apollo, this resulted in vague definitions of requirements by the usersand a reluctance to estimate data values by the data suppliers. When datawas obtained, the MSC subsystem managers did not effectively respond intheir validation role. In general, many of the participants in the datamanagement system were uncertain about the purpose and authority of thedata and its relationship to other data in the program. The presence ofredundant data in the many technical documents of the program served tonurture this uncertainty. As time passed, program problems occurred whichwere attributable to data deficiencies; therefore, management involvementincreased. Simultaneously, the coordinating efforts of the data managementgroup of ASPO were causing an awareness of the data management objectives topermeate throughout MSC. By the time the operational phase of Apollo wasreached, these occurrences had coupled with the increased knowledge of bothdata requirements and data values to yield a widely recognized and supportedspacecraft operational OMS.

However, at this point the cost was high, for large sets of previouslyunplanned data requirements began to unfold and were imposed on the datasuppliers (mostly Apollo contractors). This resulted in costly add-onsto contracts, with schedules for fulfillment of these requirements, and

even some of the requirements severely compromised to maintain reasonablecosts. More harmful instances occurred when the opportunity to acquirecritical data was missed and the data were sUbsequently irretrievable.At present, schedules for some key data are uncontrolled, resulting inthe submittal of large masses of data so close to Apollo launch dates asto severely compromise the value of the data.

The growing pains experienced by MSC on Apollo have been alleviatedsomewhat on Skylab. Lessons learned from Apollo caused greater awarenessof operational data requirements and acceptance of the operational data

4

management concept throughout MSC at earlier stages of program development.However, there are problems similar in nature to previous Apollo problems:1) there are redundant and conflicting data among documents from whichoperational data are derived; 2) the data validation role, while improvedover Apollo, leaves much to be desired in terms of response priority; and3) there are uncertainties among some of the OMS participants about theirresponsibilities. These problems serve to impede the timely fulfillmentof data requirements.

During the course of this study, both users and va1idators of Apolloand Sky1ab data were surveyed to determine their attitude about the Opera­tional DMS and their involvement with the system, and to solicit recommenda­tions for improvements applicable to operational data management for futurespacecraft programs. Surveys were conducted with TRW, MSC, and MSFC per­sonne1. The TRW survey was performed first and served as a basis for re­finement of the survey technique prior to surveying MSC and MSFC. Theresults of these surveys are presented in Appendix C of the Final Report.A summary of survey results, presented in Table 1, serves to substantiatethe above discussion of Apollo and Skylab Operational Data Managementproblems encountered at MSC.

The MSFC survey results summarized in Table 1 were based on interviewswith seven data users and seven data va1idators during a one-day meeting,and because of this small sample, may not reflect the general attitude ofMSFC. However, the results suggest a situation at MSFC which is similarto the situation of uncertainty which prevailed at MSC during the early daysof Apollo. While the MSFC data management personnel present during theseinterviews were attuned to the goals of the operational OMS, the data userswere uncertain about the purpose, content, and authority of the OOB. Inreality, they are probably not users, for they appear to circumvent theintent of the ODS by fulfilling their data requirements through contactwith whomever they believe to be a reliable source. The MSFC va1idatorsappear to take their validation role seriously, but do not appear to usethe OOB as a reliable source of data.

5

Tab

le1.

Sum

mar

yof

Use

r/V

alid

ator

Surv

eys

Con

duct

edJu

lyan

dA

ugus

t19

71

Use

rs(N

o.o

fPe

rson

nel

Surv

eyed

)Su

mm

ary

ofSu

rvey

Res

ults

MSC

(53)

All

requ

ire

sing

leau

tho

rita

tiv

eso

urce

ofop

erat

iona

lda

ta.

Mos

tco

nsid

ered

data

accu

rate

,w

hile

one­

hal

fco

nsid

ered

itti

mel

y.R

equi

red

resp

onse

times

vary

from

imm

edia

tely

to1

mon

th.

Dif

ficu

ltie

sen

coun

tere

dw

ithla

rge

mas

ses

ofup

date

pape

r.

MSF

C(7

)N

one

used

ODB

asa

sour

ceof

data

.N

one

knew

purp

ose

ofOD

B(o

rot

her

dat

a),

but

data

was

cons

ider

edto

beob

sole

te.

Wid

espr

ead

info

rmal

sour

ces

for

oper

atio

nal

data

are

used

.

App

lica

bili

tyof

Res

ults

Apo

lloan

dSk

ylab

Skyl

abon

ly

aso

urce

ofda

ta,

but

tobe

perf

orm

edco

n­th

ough

they

did

not

know

Val

idat

ors

MSC

(30)

MSF

C(7

)

All

beli

eve

SSM

shou

ldon

lyon

e-ha

lfat

tach

edva

lida

tion

effo

rt.

ODB

isno

tus

edas

vali

dati

onap

pear

ssc

ient

ious

ly,

even

purp

ose.

vali

date

data

,w

hile

}hi

ghp

rio

rity

toth

e

}A

pollo

and

Skyl

ab

Skyl

abon

ly

2.1.3 Conclusions. The problems experienced by MSC with Apollo and SkylabSpacecraft Operational Data Management Systems led to some significantconclusions about those factors which contributed to a successful system,and those factors which adversely affected success.

1) Program office and user management emphasis and conscientiousdata management group activities have resulted in widespread useracceptance of the "single authoritative data source concept."

2) In general, line management emphasis on the validation role isinsufficient, which adversely affects the timeliness of data.

3) The complexities of handling and updating large quantities ofpaper serve to inhibit the smooth and timely flow of data.

4) The definition of data requirements subsequent to the earlyplanning stages of a program results in costly contract additions,and compromised fulfillment of data requirements.

Based entirely on the small sample size survey conducted at MSFC, thesituation appears similar to the situation at MSC four years ago, viz.;

1) The relationships and purposes of program documentation areunknown by those expected to use the documentation.

2) Except for establishment of an MSFC data management group, high­level management emphasis on participation in the Skylab Opera­tional Data Management System appears lacking.

2.1.4 Recommendations for Apollo and Skylab Improvements. While theprimary orientation of this study is focused on recommendations applicableto future manned programs, the study results indicate that some improve­ments to the current Apollo and Skylab operational OMS's would be cost­effective. The following actions are recommended to facilitate theseimprovements.

1) The advantages of single authoritative data sources betweencenters, and the need to identify these sources should be dis­cussed with MSFC management.

2) Firm and realistic schedules for submittal of contractor supplieddata to MSC should continue to be pursued by the Program Offices.

3) Greater emphasis should be placed on the timely validation andsupply of data by line management, and alternate validationauthorities should be designated.

7

4) Requirements should be established for suppliers to submit datachanges as soon as the data becomes available, and to assess allhardware and redline changes, and ground and flight test resultsfor operational data impacts.

5) The roles and responsibilities of all Skylab data managementparticipants should be explicitly defined.

6) The SODB should be printed at one facility only and high priorityshould be given to printing and distribution.

2.2 DATA MANAGEMENT SYSTEMS OTHER THAN APOLLO AND SKYLAB

The Titan II and Minuteman (Ballistic Missiles), Cheyenne (Helicopter),and Kentucky (State Government) Integrated Data Management Systems werestudied to determine characteristics which could be applied to enhanceeffective management of data for future manned spacecraft programs. Theseare systems with which TRW has been associated and with which the studyteam is familiar. Descriptions of these systems are provided in AppendixB of the Final Report. Significant characteristics of these systems arepresented in the following paragraphs.

2.2.1 Titan II and Minuteman. Early integrated planning of technical dataneeds was an important contributing factor to program success, as well asto data management system success. Contractually imposed specificationscalled for program-wide functional analyses which were sensitive to thedefinition of specific data requirements. The data then evolved frommore detailed analysis efforts to fulfill these requirements. It isinteresting to note that throughout the duration of the program, functionalanalysis data were used effectively as a systems integration tool.

In Minuteman, the responsibility for both the end item specificationsand operational performance estimates were consolidated within the samepersonnel groups. Similar consolidation of data validation responsibili­-ties has occurred during the management of the Skylab and Apollo operationaldata and is desirable for future programs.

2.2.2 Cheyenne. An early study of program data requirements by theCheyenne Program Manager resulted in the development of the IntegratedTechnical Data System (ITDS) and is believed to be the primary factorleading to widespread acceptance by program personnel. ITDS was organized

8

as an integrated data system for management of all program data. The systemwas considered very effective in assisting the management of the program.

2.2.3 Kentucky. The Kentucky Data Management System was patterned afterITDS and reflects a modularized information management system approach whichis planned to eventually handle most of the state government's data. Itis presently used to manage Highway Department, State Finance, Personnel,and Executive Office data. The personal involvement of the Governor ofKentucky is credited with achieving ready acceptance by the many partici­pants.

9

3. REQUIREMENTS FOR FUTURE OPERATIONALDATA MANAGEMENT SYSTEMS

The requirements necessary to develop an effective future spacecraftoperational Data Management System (OMS) were based on results of theanalyses described in Section 2. The complete set of requirements (sub­divided to group management policy, system implementation, and operationaldata requirements) is presented in Section 2 of the Final Report. Thecontent of this Executive Summary is confined to a discussion of onlythose requirements which deserve to receive high-level management attention.

The development and subsequent ratification of an operational datapolicy required a long time to evolve on Apollo and was accompanied bycostly implementation. A key lesson from Apollo is the need for earlycommittment by senior management to a specific policy concerning an opera­tional OMS.

It is recommended that management endorse the following requirementsfor future operational OMS's, and that these requirements be reflected inpolicy direction to all participants.

1) The operational OMS shall be a subset of a total planned TechnicalData Management System for the program. This requirement wouldassure early planning of the primary data needs of a program, andwould facilitate four important contributions to cost-effective­ness:

a) It would foster a planned relationship between operationaldata and the many technical functions from which it is derived,e.g., specification development and qualification testing.This would cause operational data requirements to be coupledwith the other data requirements related to each function.

b) It would enhance a clear definition of authoritative programdata. This would preserve the concept of a single authori­tative source for spacecraft operational data which ispresently acclaimed, but was painfully achieved for Apollo.

10

c) It would, if widely promulgated, provide center-wide visibilityof key program data. This would serve to inhibit the occurrenceof special-purpose redundant data which arises from uncertain­ties about the content and interrelationships of planned pro­gram data.

d) It would promote explicit definition of OMS roles, with assign­ments made in consonance with program need and understood andaccepted throughout the center.

2) The program OMS shall be defined prior to contractor participationand shall be reflected in all program requests for proposals.This requirement would cause all prospective contractors to bidagainst a known data baseline in a competitive manner and wouldresult in early familiarity with the required data supportresponsibilities and participant roles. It would also serve toinhibit subsequent add-on costs attributed to bidding uncertainties.

3) The program plans shall enable continual definition, refinementand evolution of data requirements throughout the program withminimal contractual effect. This requirement would cause plansand processes to be developed which would cope with the inherentinability to completely define all operational data requirementsat the beginning. Solutions are expected to require continuinginteraction between the spacecraft design and development andmission and operations planning and thus are a part of the systemengineering function.

11

4. AN INFORMATION SYSTEM FOR A FUTURE SPACECRAFT PROGRAM

4.1 GENERAL

The analysis of spacecraft operational data in the Apollo program hasexposed two significant and unique characteristics, viz;

1) Operational data can be obtained as a by-product ofactivities conducted for other purposes.

2) A time paradox occurs between availability and need.

The first of these characteristics is the basis for the subsequent dis­cussion while the second is discussed in Section 6.

The user of operational data is not normally associated with the sourceof the data. His data requirements are met by activities that are con­ducted for purposes other than the production of operational data; hence,operational data can be extracted as a by-product from the "data pools" ofother program activities. In order to alleviate data management problems,the information required for the management of operational data should beobtained in a similar way. Thus, both operational data and informationfor its management (e.g., status and availability) should be obtained asan adjunct output of many different program activities. We recommend thatthe effective solution for operational data management is an integrated(and automated) data base for both the technical data and management infor­mation of a program.

Based on the lessons learned from the study of Apollo and other Infor~

mation Management Systems (IMS), a plan for an IMS for a future spacecraftprogram has been developed and is described in Section 1 of the Final Report.The plan is based on the expectation that MSC will provide a user-orientedinformation management service for its operating elements. This servicewill take the form of software and hardware configurations which are suit­able for general purpose data storage and retrieval and are compatible withintegrated data bases. The configuration would be managed by a CenterData Management Office. The reasons for a center-wide system are to mini­mize the cost of software, to ensure compatibility of systems among usersand between programs so that data can be readily exchanged, to simplifytraining of users, and to coordinate prioritized assignment of computer

12

terminals. Three rules have been adopted to guide the system design:1) use the MSC functional structure, 2) plan on use of existing MSC hard­ware and software, and 3) recognize that acceptance of a new informationmanagement approach will take time to evolve and be accepted.

4.2 SYSTEM CONCEPT

The overall system concept is shown in Figure 2. As the figure em­phasizes, a key to the operation of the system is the existence of a database containing the common pool of data for the program. The ready accessto this data by all persons engaged on the program is assured through acombination of computer terminals and computer-aided access to hard copyfiles. By its existence, the data base injects a degree of disciplineinto the management of program data that is not possible with fragmentedsystems.

A second key to smooth operation of the data base, and thereby thetotal IMS, is the existence within the Program Office of several applica­tions engineers who are knowledgeable of the operation of the total IMS aswell as being de facto representatives of MSC development organizations.Within the system concept, the applications engineers would be expected tointegrate requirements for operational data with those for other functions.For example, basic proof-of-performance test data requirements specifiedby a subsystem manager would be expanded to include the reporting of out­of-limits performance data for operational data needs. The applicationsengineers would also be the principal interface through which informationwould be supplied to the data base. They would develop the file structureand indexing procedures for the data base and would provide assistance tousers who are not familiar with the mechanics of search and retrieval.

The system depends heavily on automation for its eventual cost­effectiveness. The Computation and Analysis Division (CAD) of FOD has beenstudying software which, together with the 1106/1108 computer complex, couldform the basis for an operational system. This service would be coordi­nated by the Center Data Management Office (COMO) which would integrateautomation, hard copy, and procedural aspects into a center-wide IMS.From then on, the COMO would maintain configuration control, and provideguidance in the use of the IMS to operating elements in the program offices

13

CENT

ERDA

TAMA

NAGE

MENT

OFFI

CE--------

PROV

IDE

GUID

ANCE

AND

STAN

DARD

S

~l

SYST

EMAN

DSU

BSYS

TEM

MANA

GERS

DRL

PROG

RAM

OFFI

CEAP

PLIC

ATIO

NSDR

LCO

MODR

DEN

GINE

ERS

DRD

DOCU

MENT

MANA

GEME

NTOF

FICE

PROC

UREM

ENT

f-----

--

--

-~

-------

--------

r--

---

------

PREP

ARE

DRL'

SAN

DDR

D'S

APPR

OVE

AND

COOR

DINA

TEAP

PROV

ALIN

CLUD

EIN

CONT

RACT

DATA

INDE

XFI

LEST

RUCT

URIN

GUS

ERS

--

~SU

BSYS

TEM

DEVE

LOPM

ENT

CONT

RACT

INTE

GRAT

EDDA

TABA

SERE

QUIR

EMEN

TS~-------~

CONT

RACT

ORS

DATA

REQU

IREM

ENTS

••

PROG

RAM

OFFI

CES

PREL

IMIN

ARY

DATA

~PROCUREMENT

OFFI

CES

VALI

DATE

DDA

TASY

STEM

SDE

VELO

PMEN

T

PREL

IMIN

ARY

VALI

DATE

DDA

TA

VALI

DATE

DDA

TAPR

OGRA

MOF

FICE

APPL

ICAT

IONS

DATA

SYST

EMAN

DSU

BSYS

TEM

MANA

GEME

NTRE

SPON

SECO

NTRA

CTOR

ENGI

NEER

S1

--------

-~------

r---------

-FI

LEST

RUCT

URE

AND

COOR

DINA

TION

VALI

DATI

ONPR

OVID

EDA

TA

PREL

IMIN

ARY

DATA

Fig

ure

2.IM

SC

once

pt

and functional directorates. The IMS would be user-oriented in that theusing organization would decide how and when to use it, and for what pur­poses.

4.3 IMPLEMENTATION

The first step of implementation is a crucial one. We recommend thatCenter management appoint a policy team to draft and publish a Centerpolicy concerning a center-wide IMS which provides a user-oriented service.An IMS planning team headed by the (new) Center Data Manager and composedof representatives of CAD, program offices, user organizations and severalData Management Systems engineering specialists, would then work out thesystem specifications, designs, and the size and extent of integrated databases, and begin training within several months. We also recommend thatthe IMS planning team follow the phased-approach (to automation) recommenda­tions presented in the following section. We believe the system could bein operation before the Space Shuttle Phase C/O contract is let.

15

5. AUTOMATED DATA MANAGEMENT TECHNIQUES

The contribution of automation techniques to spacecraft operationaldata management system effectiveness was analyzed, and an approach believedto be cost-effective is recommended for future systems. This approachreflects consideration of the evolving nature of MSC's automation capabili­ties, the requirements for effective data management, and the characteris­tics of spacecraft operational data. The scope of this approach was ex­panded to consider the additional benefits derived from applying theapproach to all the technical data of a program. Detailed discussions ofthese topics are presented in Section 3. of the Final Report, and arebriefly discussed in the following paragraphs.

While a manual data management system implemented to satisfy the re­quirements developed during this study would function, there are undersirablefeatures to certain aspects of such a system - e.g., 1) the overridingemphasis on paper mechanics detracts from emphasis on data quality, 2) thetime lags associated with paper processing and distribution, and 3) thecomplexities of search and update imposed on the user population. Converse­ly, there are many operations which must be performed manually, such asthe definition and revision of data requirements, the establishment ofvalidation procedures, and the follow-up on data availability. With thedata itself, there are many items which are simply not good candidates forcomputer storage. Thus, during the next decade, any cost-effective systemwill undoubtedly be partly automated and partly manual.

Automation alternatives were investigated to determine the extent towhich the above considerations could be accommodated. It was assumed thatpresent and planned automation capabilities of MSC would be available foruse with operational data. At present there are two major computer com­plexes at MSC; the Univac 1106/1108 and the IBM-360. An informationretrieval software system and an Exec VIII time share/terminal capabilityare expected to be operational on the 1106/1108 in the near future. Asoftware system to effectively handle and edit large volumes of text materi­al is available.

16

The IBM-360 complex has been traditionally committed to near real-timeand real-time support of manned spaceflight missions. Relaxation from thisstatus is evident from the recent implementation of the Mission OperationsPlanning System (MOPS) which provides an interactive mission planningcapability further upstream in the mission development cycle than ever be­fore. Recent MSC sponsored studies by IBM and Computer Sciences Corpora­tion point to a sophisticated information management system in the future.

It is anticipated that these complexes will eventually merge, eitherwith software providing the interface or with a new set of integratinghardware. In addition, somewhere along this path an interactive graphicscapability will be made available to the majority of the data user popu­lation. Automation of operational data would probably be constrained tostart with the 1106/1108 information retrieval capability and a limited(in terms of the quantity of terminals available) time share/terminal capa­bility, and then increase in consonance with expansion of the automationcapabilities of MSC. The flexibility to take advantage of these expandedcapabilities should therefore be included in any plan for automation ofoperational data.

The characteristics of operational data encompass the entire rangeof possible data characteristics in any technical area. Operational datainclude drawings, graphs, tabular data, and short and long text. Thegraphical, tabular, and short text data are the most dynamic in terms ofupdate frequency, and the data management system would benefit most fromthe automation of these data types. Long text is usually descriptive innature and does not require frequent change, while drawings are consideredrelatively invariant.

In view of the progressively increasing automation capabilitiesanticipated and the broad spectrum of data characteristics comprisingoperational data, it appears that a cost-effective operational data manage­ment system would be achieved by:

17

1) Structuring the entire operational data population for indexingthrough a central source and automating a data reference fileat the beginning of a program. This would serve to consolidatethe identification, status, and location of data and would soonbecome recognized as the primary source for operational data.

2) Structuring the more dynamic data (in terms of update frequency)into the automated data base. Key data users would be providedwith terminal access (on a single "ques tion and answer" basis)to that data which changes frequently. Data validators wouldhave coded access for validation purposes. This would alleviatethe search and update complexity encountered with large amountsof frequently changing paper. Graphical data which are not easilyautomated for widespread use at present, would be present intabular format during the near-term. The user would have to plothis own graphs or have them plotted by use of his own batch oron-line plot program. Either of these alternatives is easilyaccomplished and is not considered a severe system constraint.

3) Structuring the remainder of the data into a manual or semi­automated set of files indexed to conform with the data referencefile described above. This would complete the integrated database set.

4) Providing a capability to maintain the entire integrated database set and to handle new data requirements. At any point intime, the advisability of automating additional data would beassessed in terms of the available automation capabilities andexperience with the automated part of the system. As both capa­bilities and experience increase, more and more data would beautomated. Thus the undesirable features of a manual system de­scribed in previous paragraphs would be progressively eliminated.

5) Publishing operational data to satisfy the large number of userswho would not have convenient access to terminals and who do notrequire short update response times. Data contained in the auto­mated data base could be processed by direct computer printoutand greatly alleviate the manual processing load.

6) Prioritizing assignment of the limited quantity of teletype ter­minals presently available, reflecting the needs of both opera­rional data users for a given program and the needs of otherterminal users for other programs. These priority decisionswould undoubtedly be made by center-level management.

The advantages of this phased approach to automation at the beginningof a program contrast favorably with the alternative of planning only fora manual system and then proceeding to automation when the need becomescritical. They include:

18

1) The long exposure period necessary for widespread acceptance ofany system would commence upon implementation of management policy,thus facilitating earlier operational effectivity.

2) The costly and confusing impact of changing some of the operationsand roles of the data management system participants downstreamin the program would be avoided (e.g., contract changes).

3) The probable need to restructure manual data files to accommodateautomation would be avoided. If the structuring of data filesfor automation is delayed, then when it does occur, the programimpact will include start-up delays and widespread confusion aboutwhich data are available, and what data are valid.

While the above approach is deemed cost-effective when applied tospacecraft operational data alone, it would be more cost-effective from anoverall program standpoint if the data spectrum were expanded to includeconsideration of all technical data of the program.

Operational data are extracted from gross estimates, technical require­ments and initial versions of end item specifications during the early seg­ment of a spacecraft program. As detailed analyses, performance models anddevelopment tests begin to occur, operational data are then progressivelyupdated to reflect later knowledge, and finally during the operational phaseof a program, these data are updated to reflect operational experience.Thus while operational data have not been the major product of any functionduring any phase of the program, they have been a minor product of a major­ity of the functions throughout the definition, design, development andoperational phases. In essence, a portion of the data generated by thesefunctions during each of these phases is operational data.

Since spacecraft operational data are so interwoven with much of thetechnical data of a program, the above arguments in favor of phased andplanned-from-the-beginning automation also appear to be applicable toautomation of all technical data. In addition, consideration of alltechnical data would enhance retention of the close coupling between opera­tional data and the other technical data of a program reflected in therequirements of Section 3.

19

Additional benefits would be realized. Traditionally, program officesare responsible for maintaining a reasonable balance between program costs,schedules, and performance, and must detect and be responsive to unbalancingforces; this responsiblity is shared to varying extents with functionalmanagement. Information necessary to perform this function is derived inpart from technical data in a manner similar to operational data. Auto­mation of all technical data (initially through development of referencefiles) would facilitate the correlation and extraction of the data necessaryto provide management visibility.

The above described benefits of automation appear to be of overwhelm­ing value to both the data management and program management efforts offuture programs. For this reason it is recommended that the phased approachrecommended above for operational data be widened in scope and applied tothe development of an overall program information management system.

20

6. DEVELOPMENT OF OPERATIONAL DATA REQUIREMENTS

Ideally all data requirements for a program would be known at thebeginning of the program and would be specified explicitly in the initialcontract. To a considerable and probably acceptable degree, this can bedone for most spacecraft data since requirements, data management pro­cesses, and program management methods have matured from experience. How­ever, this does not appear to be the case for spacecraft operational dataand shows up in the form of IItime paradoxes ll mentioned in Section 4.Examples are: the operational data user invariably recognizes additionaldata requirements at the conclusion of the development process, while theopportunity to satisfy these requirements occurs earlier in the developmentprocess; the mission planner's data requirements depend on hardware con­figurations, yet he is asked to supply definitive inputs to assist inselection of those same hardware configurations; even in preparing con­tracts, the operational data user is asked years in advance to define hisrequirements for data about systems not yet conceived. Possibly the mostserious consequence of these paradoxes comes from those instances wheredata are irretrievably lost because an obvious need does not develop untilafter the acquisition opportunity has passed. We believe the solution tothis problem is the system engineering function which relates hardwaredevelopment to eventual operational employment.

The operational data user must be represented in the hardware develop­ment process to resolve the paradoxes above, but his data problem is onlya part of this system engineering function. The total job requires con­tinual interplay between the operations world and the hardware develop­ment world to produce an effective spacecraft system - i.e., continualiteration between operations analysis and hardware design. By maintainingan awareness of the operational data users I needs and expanding and refin­ing their stated requirements, the user can be supplied with the IIbest ll

available data and planning can be maintained to improve the data as futuredevelopment and test activities permit. At any given time, a user's needin the far future will be specified now for acquisition and storage in theintermediate future. The user's representative in this process must

21

function from a base of experience acquired on a previous program and havesufficient training and maturity to exercise good engineering and programmanagement judgement. The above system engineering activity suggests anOperations Analysis Group which might work along the lines of the Apollo

Data Priority Group, but which would start at the beginning of the program.Further exploration of this subject is beyond the objectives of this study.

Several recommendations are made for alleviating the operational dataproblem along a line compatible with the above. First, where requirementsare known, they should be included in the prime contract RFP through DRL'sand DRD's in conformance with current contracting practice. Second, thoseDRL's and DRD's should be coordinated on a program-wide basis to allowintegration of requirements for operational data. Third, to assist indeveloping data requirements before contracts are firmed up, a techniquesuch as that illustrated in Figure 3 is suggested.

This technique causes the time-phased functional activities to be re­lated to their necessary input and output data needs. In the diagram, theblack dots identify the activities for which the data items serve as input.That part of the diagram below the "MSC Data Base" would be largely a MSCactivity while the upper part would be primarily a contractor responsibility.An example of both sections of the diagram would be included with the RFP.As a part of his proposal, the contractor would be expected to respondwith a version reflecting his spacecraft development plan. This version,when negotiated, would be included by the NASA program office in an overallprogram data function diagram. Although complex and highly interrelated,the diagram would form the basis for the entire program data plan andstructure of an automated data base. While difficult to maintain manually,elements of the diagram could easily be handled by an automated IMS withcorrelative features. As a result of this exercise in the RFP/Proposalstage, additional firm data requirements could be included in the contract.

The common desire among operational data users for early and continual"best data" inputs deserves specific attention, since it affects the datamanagement system discipline and apparent integrity. Operational datasources are reluctant to "formally" supply estimates which have limited"provabil i ty. II Contractor management i nhi bits the submi ss i on of estimated

22

I I ICONTROL OF I IINTERFACE II CONTROL TECH CONTROL END ITEMREQUIREMrTS ! REQUIREMENTS ~ SPECIFICATIONS 7

J JL_. PRELIMINARY I DETAILED Ir---DESIGN DESIGN

ECP'S

PRELIM OPERATING FIRMPRELIM CONFIG & DESCRIPTIONS CDNFIG & tPERF CHAR SPECS. SPECS •

1971

PROGRAMMILESTONES

CONFIGURATIONCONTROLFUNCTION

HDWR/SFTWRDESIGNFUNCTION

1972

I 2 I

.C CONTRACTAWARD

6.

3 I 4

TECH. REQ.REVIEW

6.

1973

1 I 2 I 3 I 4

PDR

~

1 I1974

2 I 3 I 4

CDR

~

1975

1 I 2 I 3 I 4 1 I

FACI

6.

1976 I2 I 3/1

(I

"'\I'll

~ao~

":::0~I'1l-

f

IJI)

EVAL EFFECTSOF CHANGESON ANALYSES

CHANGEMFG

EVAL EFFECTSOF CHANGES ON

REFINE . ~~~~:b~~~sPROCEDURESIN SIMULATOR

EVAL EFFECTS OFCHANGES ON TEST VALID

I I ,

DEVELOPMENT & QUALIFICATIONTESTING

•m0LTS I I

SIMULATORMFG

I IPRELIMCREW OPE RATPROCEDURES

, IMOCKUPMFG

PLAN TRNGSIMULATOR

I I

PRELIM

DEVE.LOP +TEST PLN

I

PROCEDURESANALYSIS

MOCKUPDESIGN

BREADBOA'RD PROTOTYPEMFG MFG

FAILURE MODES EVAL EFFECTS& EFFECTS OF CHANGESANALYSIS FMEA ON FMEA

DATA

MAINTENANCEANALYSIS

~

REL ANAL

INTERFACE I 1 I 1 I MAINT-+-ANALYSIS PLAN

1l

I I ITEST PLANNING. I I I

~

~;::0b

IRELIAB~ BDGTS..I~

-';:)i1r~w.e>

I INTER-'"FACE

~ REFINE BDGTS.B TECH e.g. ,;:; REQS WT,~ I PWR

~

~

g'"'"..."«>-«'"

SYSTEMSENGINEERINGFUNCTION

TRAININGFUNCTION

REALIABILITY &QUAL ITY ASSUR.FUNCTION

HDWR/SFTWRMFGFUNCTION

HDWR/SFTWRTESTFUNCTION

§~'"00rjt;G:;~"'!z>- '"

~~~u

~~

MSC DATAI----f BASE DEVELOPMENT

AND MANAGEMENT

, t •• , •.B REL, WT,PREL PREL PREL

DATA PREL I PWR PERF SPECS OPSBASE TECH PREL CHAR & DESCR

REQ BDGTS 1 FIRM

+TEC~ REQ

+ Ft IPRELIM TESTPREL DATA CREW OPE RAT RESULTSDEV I PROCEDURESTEST FIRM I MAINTPLN SPECS PLAN,

ECP'S&ACTIONRECORDS

+MISSIONPLANNINGFUNCTION

MISSIONPROFILE& EVENTSSTUDIES

DEVELOP SIMULATioNS •,GUID & NAVSTUDIES

ICONSUMABLESCOMPATIBILITYSTUDIES

;)

SUCCESSIVEREFINEMENTS

1

LEGEND• , DATA-FUNCTION INTERFACEA' DIRECTION OF DATA FLOW

FLIGHTPROCEDURESPLANNINGFUNCTION

IDEVELOP FLI GHTPLNG REQS

DEVELOPFLT PRDC

(

I I I T I I I T TTl ITT T-'f---' I T I I I

NW

~

~':; ICREW::2 TRAINING« ~ FUNCTION~'"o

~0..o

LOGISTICSFUNCTION

DEVELOP TRNGREQUIREMENTS

DEVELOP LOGISTICSPLANNING CAPABILITY

PLAN TRNGSIMULATIONS

LOGISTICS PLANNING STUDIES

(

)(

FLIGHTOPERATIONSPLANNINGFUNCTION

FLIGHTSAFETYFUNCTION

4

FLIGHT OPERATIONSREQUIREMENTS STUDIES

FLIGHT SAFETYREQS STUDIES

I

OPERATIONALDATA REQSANALYSIS

)

i ...,or"Oloc:-i."::Q»:s:/TI

Fi gure 3. Sample Data-Function Diagram forSpacecraft Subsystem Development

~

data which may later prove contradictory to the data eventually producedby the design, development, control and acceptance activities. The aboveconflicts are not completely resolved on the Apollo or Skylab programs.The following solution is recommended:

1) The contract statement of work would provide for jointMSCjcontractor estimates of expected spacecraft perfor­mance. It would limit contractor accountability tofurnishing conscientious estimates by those contractorpersonnel best qualified to make such technical judge­ments, and specify that such estimates would have nocontractual significance.

2) The early data estimates, together with the basis forthe estimates, would be placed in the automated database of the IMS and keyed to trigger reassessment andreconfirmation of their validity at short-time intervals.This would serve to assure that an early estimate wouldnot continue to drive program functions after it hadbecome obsolete.

To cover the unforeseen need for data after a contract is initiated,some Level of Effort (LOE) of a call contract nature should be included inthe basic prime contract. The amount of the LOE needed might be estimatedas some percentage of the effort spent on known data requirements.

24