NASA CONTRACTORREPORT

7 2 - 2 4 S 5

8 7 2 - 2 4 8 5 3

NASA CR-61386

SKYLAB EXPERIMENT PERFORMANCE

EVALUATION MANUAL

By J. E. MeyersTeledyne Brown Engineering CompanyHuntsville, Alabama

January 1972

Prepared for

N A S A - G E O R G E C . M A R S H A L L S P A C E F L I G H T C E N T E RMarshall Space Flight Center, Alabama 35812

https://ntrs.nasa.gov/search.jsp?R=19720017203 2020-07-14T04:40:30+00:00Z

TECHNICAL REPORT STANDARD TITLE PAGE1. REPORT NO.

NASA CR-613864. TITLE AND SUBTITLE

2. GOVERNMENT ACCESSION NO.

Skylab Experiment Performance Evaluation Manual

7. AUTHOR(S)

J. E. Meyers9. PERFORMING ORGANIZATION NAME AND ADDRESS

Teledyne Brown Engineering CompanyHuntsvi l ie, Alabama ,

12. SPONSORING AGENCY NAME AND ADDRESS

National Aeronautics andWashington, D.C. 20546

15. SUPPLEMENTARY NOTES

Prepared for AstronauticsScience and Engineering

Space Administrat ion

3. RECIPIENT'S CATALOG NO. j

5. REPORT DATE

January 19726. PERFORMING ORGANIZATION CODE

8. PERFORMING ORGANIZATION REPORT #

10. WORK UNIT NO.

H. CONTRACT OR GRANT NO.

NAS8-2180413. TYPE OF REPOR'i & PERIOD COVERED

Contractor Report

14. SPONSORING AGENCY CODE

Laboratory

•

16. ABSTRACT

This document contains a series of preparation analysesused for evaluating the performance of the Skylab corollaryexperiments under pre-fl ight, in-fl ight, and post-f l ightconditions. Experiment contingency plan work-aroundprocedure and malfunction analyses are presented in orderto ass is t 'in making the experiment operationally succesful.

17. KEV WORDS

Skylab Experiments

19. SECURITY CLASSIF. (of this report)

Unclassi f ied

18. DISTRIBUTION STATEMENT

Un-Class i f ied-Unl imi ted

y^^t^ s?)- t^^^t—v '̂

i20. SECURITY CLASSIF. (of thU page) 21. NO. OF PAGES 22. PRICE

Unclassif ied 29 $3'0°

MSFC - Form 3292 (May 1969)

TABLE OF CONTENTS

Page

SECTION'I. INTRODUCTION 2

SECTION II. METHODOLOGY 3A. Discussion 3B. Process 4C. P re-Flight Evaluation 4D. In-Flight Evaluation 19E. Post-Flight Evaluation 19

APPENDIX A. EXPERIMENT D-024, THERMAL CONTROLCOATINGS (MSFC/USAF) A-l

APPENDIX B. EXPERIMENT M-415, THERMAL CO'NTROLCOATINGS (MSFC) B-l

APPENDIX C. EXPERIMENT M-479, ZERO GRAVITYFLAMMABILITY (MSFC) C-l

APPENDIX D. EXPERIMENT M-487, HABITABILITY/CREW QUARTERS (MSFC) D-l

APPENDIX E. EXPERIMENT M-512, MATERIALSPROCESSING FACILITY (MSFC) E-l

APPENDIX F. EXPERIMENT M-551, METALSMELTING (MSFC) F-l

APPENDIX G. EXPERIMENT M-552, EXOTHERMICMELTING (MSFC) G-l

APPENDIX H. EXPERIMENT M-553, SPHERE FORMING(MSFC) H-l

APPENDIX I. EXPERIMENT M-554, COMPOSITECASTING (MSFC) 1-1

APPENDIX J. EXPERIMENT M-555, GALLIUM ARSENIDECRYSTAL GROWTH (MSFC) J-l

111

TABLE OF CONTENTS (Concluded)

Page

APPENDIX K. EXPERIMENT S-009, NUCLEAREMULSION (MSFC) K-l

APPENDIX L. EXPERIMENT S-149, PARTICLECOLLECTION (MSC) L-l

APPENDIX M. EXPERIMENT S-150, GALACTIC X-RAYMAPPING (MSFC) M-l

APPENDIX N. EXPERIMENT S-183, ULTRAVIOLETPANORAMA (MSFC) N-l

APPENDIX O. EXPERIMENT T-002, MANUALNAVIGATION SIGHTING (MSFC) O-l

APPENDIX P. EXPERIMENT T-003, INFLIGHT AEROSOLANALYSIS (MSFC/DOL) P-l

APPENDIX Q. EXPERIMENT T-013, CREW/VEHICLEDISTURBANCE (MSFC/LaRC) Q-l

APPENDIX R. EXPERIMENT T-020, FOOT CONTROLLEDMANEUVERING UNIT (MSFC) R-l

APPENDIX S. EXPERIMENT T-027, CONTAMINATIONMEASUREMENT, SAMPLE ARRAY (MSFC) . . S-l

APPENDIX T. EXPERIMENT T-027/S-073, CONTAMINATIONMEASUREMENT, PHOTOMETER ANDGEGENSCHEIN/ZODIACAL LIGHT (MSFC) . . T-l

APPENDIX U. EXPERIMENT M-509, ASTRONAUTMANEUVERING EQUIPMENT (MSC) U-l

REFERENCES 20

BIBLIOGRAPHY 21

IV

LIST OF ILLUSTRATIONS

Figure Title Page

1. Skylab Carrier/ExperimentEvaluation Model 5

2. Contingency Plan Model 16

v

DEFINITION OF SYMBOLS

DOL Department of Labor

DRF Data Request Forms

DRS Data Requirements Summary

ECR Engineering Change Request

EOH Experiment Operations Handbook

ERD Experiment Requirements Document

ES Evaluation Sequence

HOSC Huntsville Operations Support Center

IBD Interface Block Diagram

ICD Interface Control Document

IP&CL Instrumentation Program and Components List

IR Instrumentation Requirements

KSC Kennedy Space Center

L Lift-off

LaRc Langley Research Center

MA - Malfunction Analysis

MCPO Malfunction and Contingency Plan Outline

MRD Mission Requirements Document

MSC Manned Spacecraft Center

MSFC Marshall Space Flight Center

NASA National Aeronautics and Space Administration

O Operation

OA Orbital Assembly

P Preparation

POEA Pre-flight Operations Evaluation Analysis

SD Systems Diagram

SFP Single Failure Point

VI

DEFINITION OF SYMBOLS (Concluded)

SL Skylab

SRFP Skylab Reference Flight Plan

T Termination

USAF United States Air Force

vu

SUMMARY

This document presents the results of a Systems Engineeringexperiment evaluation study concerned primarily with defining carrier/experiment interface requirements, uncovering experiment faults,measuring operational performance, and deriving contingency plans.

Personnel knowledgeable about a particular experiment can usethe information and data contained in the appropriate appendix to assistin evaluating the experiment performance. The information presentedin this report will provide personnel with a general understanding of thefunctions and objectives of the experiment, a procedural sequence ofevents used by evaluation personnel to follow the performance of theexperiment, contingency plans, and malfunction analyses used to assistin evaluating and minimizing expected experiment operating problems.The report also contains various other forms of information that maybe useful for experiment evaluation.

SECTION I. INTRODUCTION

The Mission Development Branch, S&E-ASTN-SD, has devisedan integrated method for evaluating the performance of Skylab modulecarrier and corollary experiment interfaces. The method presented inthis report will be used by S&E-ASTN-SD to develop the necessaryinformation to perform an integrated evaluation of 18 MSFC-developedor proxy-developed experiments and Z MSC-developed experiments.This effort is required so that the S&E-ASTN-SD Branch may fulfill itsexperiment operations support responsibilities, as defined by theAstronautics Laboratory Evaluation Support Plan.

Prior to the actual flight of the experiment, the adequacy ofdesign and expected performance compliance between the flight carrierand corollary experiment interface requirements will be determined.During flight operation, the emphasis will be shifted from the require-ments to the performance of the carrier and experiment systems inso-far as meeting their functional objectives. The measurement ofcarrier/experiment performance will provide the necessary knowledgeand data to determine if the flight hardware is functioning as intendedand meeting its objectives. If the objectives of the carrier and theexperiment are met, the carrier and the experiment can be assumed tobe successful and will be so reported after each Skylab flight mission.If the experiment is a success, the interface requirements were adequate.The above arguments are time-related (pre-flight, in-flight, and post-flight) and, therefore, impose a severe operational constraint on anevaluator (the in-flight response time will probably be stated in termsof seconds and minutes). The evaluator must be highly knowledgeableabout the design and systems with which he is working and be preparedto interpret and respond rapidly to requests for operating performancestatus. If the carrier/experiment operating performance is not withinthe design specification limits, the evaluator must be prepared torecommend a contingency work-around procedure to minimize theproblem. The objective of this manual is to aid an evaluator in fulfillingall of the above requirements within a time interval dictated by theSkylab Program and Mission schedule.

As each corollary experiment is analyzed using the methodologypresented herein, to develop the necessary performance evaluationcriteria, the results will be forwarded to all holders of this manual.The pages should be in'serted as an appendix to the manual (Table ofContents). Appendix updates will be prepared and distributed on anas-required basis.

SECTION II. METHODOLOGY

A. Discussion

The Skylab Experiment Performance Evaluation effort explainedin this report is designed to aid the Astronautics Laboratory (S&E-ASTN)in assessing the adequacy and determining the operational success ofcarrier/experiment interfaces during orbital flight. The adequacy ofinterfaces is determined by carefully analyzing and matching up thedesign, operational, and supporting requirements between the carrierand experiment. Knowledge is desired concerning both how well theserequirements are fitted together and the outcome of their performanceunder nominal and abnormal operating conditions. The above require-ments are analyzed and evaluated for compliance, compatibility, humanfactors, safety, expected performance, and control. A requirementusually dictates a desired input/output function that may or may not beconstrained. A requirement may be considered as the cement that joinsthe experiment to the flight carrier and dictates the criticality of theinterface. If improper bonding occurs, it can preclude the successfuloperation of the carrier and experiment. The operational success of acarrier/experiment interface can be ascertained by measuring how wellthe hardware and supporting operations achieve their functional objectives.The measurement will be both qualitative and quantitative in nature.

The methodology is based on a Systems Engineering approach thatallows an evaluator to make timely decisions based on his extensiveknowledge of operating carrier/experiment systems and their expectedperformance output. The method of this plan is structured so that anevaluator is provided useful experiment input/output performance dataduring pre-flight, in-flight, and post-flight operational phases. Further-more, the plan can be adapted to changing operational phases; it therebypermits the evaluator to handle the performance data as he sees fit. Ifthe model is used properly, an evaluator can:

• Ensure that the flight carrier and experiment design andoperating requirements are adequate, safe, and properlymatched

• Comprehend the carrier/experiment interfaces and understandtheir peculiarities

(

• Help manage system performance requirements for thecarrier and the experiment

• Troubleshoot operating carrier/experiment systems whenabnormalities occur

• Make real-time decisions based on qualitative and quantitativedata with a high level of confidence

*• Devise contingency plans based on astronaut and carrier/

experiment hardware malfunction cues

• Process large quantities of technical information for carrier/experiment performance evaluation.

B. Process

\Figure 1 depicts a functional model of the Skylab Experiment

Performance Evaluation method. The model is designed for operationwithin the framework of the Mechanical and Crew Systems IntegrationDivision (S&E-ASTN-S). It can be easily adapted to the work processesof the Huntsville Operations Support Center (HOSC) during actual andsimulated Skylab mission data acquisition modes.

There are 15 system level functional steps (steps and functionalblocks are used synonymously) that an evaluator would follow to use themodel. Steps 1 through 6 are concerned with carrier/experiment pre-flight evaluation. Steps 8 through 13 are concerned with carrier/experiment in-flight evaluation. Step 15 is concerned with post-flightevaluation of the carrier and experiment. Step 7 may be considered asan overlap of pre-flight and in-flight evaluation, while Step 14 may beconsidered as an overlap of in-flight and post-flight evaluation.

C. Pre-Flight Evaluation

By following Steps 1 through 3 the problem of expected mission,system, and experiment performance can be solved. Knowledge ofexpected performance permits an evaluator to understand what systemsinteract; what engineering elements and variables are essential; andwhat magnitude, range, and tolerances of the variables are permissiblefor nominal operation'. Furthermore, knowledge is required concerningthe performance limitations of the systems in addition to nominalsituations. General performance specifications and baseline require-ments for the Skylab mission and subsystems are searched out andscrutinized in Steps 1 and 2. Specific performance specification andbaseline requirements for corollary experiments are searched out andconsidered in Step 3. It is important to understand that Steps 1 and 2.constrain the final output of Step 3. Step 3 cannot be readily understooduntil Steps 1 and 2 are thoroughly comprehended. A considerable

(J\

ner/ExprnInterface

iicd and Evi

FIGURE 1. SKYLAB CARRIER/EXPERIMENT EVALUATION MODEL

quantity of technical information exists that describes the Skylabmission, Orbital Assembly (OA) modules, and subsystems expectedperformance. S&E-ASTN-SD uses Reference 1 to trace, review,and gain insight into Skylab mission, module, and experiment subsystemoperations. »

t

The result of following Step 1 should yield technical informationin the form of gross expected performance profiles for the Skylabmissions (SL-1 through SL-4). In particular, we are interested inmission, flight operation, and data acquisition plans; and how theyconstrain an experiment's design, operation, performance, andevaluation. t

Following Step 2 should yield technical data in the form ofdiscrete expected performance profiles for the OA modules andassociated subsystems (Orbital Workshop, Multiple.Docking Adapter,Airlock Module, and Apollo Telescope Mount). We are highlyinterested in those sequences of events that lead up to experimentinitiation, occur during the experiment, and immediately followexperiment operations. Thus, when the OA module subsystem operatesand supports a corollary experiment, it is desired to know how well itperformed, since it could ultimately degrade the experiment's per-formance. The following OA operational performance characteristicsare searched out and acquired for each subsystem when applicable:

• Natural and Induced Environments--temperature, humidity,pressure, radiation, shock, vibration, contamination, etc.

• Data Acquisition Properties--signal space, time, information,content, physical, etc.

• Orbital and Ephemeral--altitude, velocity, angle, attitude,tracking, position, epoch, etc.

• Power--standby, average, peak, total wattage, etc.

• Control--crew effort and presence, timeline, communications,etc.

• Consumable Scheduling--life support, power, materials, food,film, etc.

It is necessary to understand the ranges of operational performance andresponse of the OA subsystems so that the experiment can be matchedto the interfaces (carrier), thereby determining if they are compatibleand adequate.

The corollary experiments require extensive investigation, andin many cases expected performance data are not available, because,until recently, useful experiment information was not readily accessible.Moreover, the corollary experiment information and data changefrequently. Some of the data must be interpreted arid related to theSkylab rnission. It is understandable, therefore, that most of the pre-flight carriers/experiment evaluation effort is focused on functionalblocks 3. 0 through 6. 0. »

To gain an insight into the performance of the corollary ex-periments (functional block 3.0), a somewhat rigorous analysis isneeded, depending on Astronautics Laboratory's viewpoint and emphasis.A rigorous support effort is being made on behalf of the MSFC-responsiblecorollary experiments (18 total at present), and a less rigorous effortwill be made for the MSC-responsible experiments (approximately 35at present). Three end items are prepared so that expected performanceprofiles for the MSFC corollary experiments may be realized.

1. Pre-Flight Operations Evaluation Analysis (POEA). A POEAis prepared for each experiment (Section I, Appendices A through U).Almost every important facet of the experiments' design, operation,and expected performance is critically interrogated and analyzed.The analysis is conducted from a carrier/experiment interface com-pliance or malfunction premise. Thus, whenever an experiment hasan operating input requirement dependent upon an external source, therequirement is determined to be adequately or inadequately met, basedupon the carrier, scientific phenomena, power, human presence, groundsupport, etc. If the experiment input requirement cannot be furnished,either a design oversight or malfunction has occurred. Viewed withinthe context of the above stated premise, the POEA provides a mechanismfor:

• Delineating the experiment's value in terms of its objectives,success criteria for meeting the objectives, and prioritywith respect to other experiments (a measure of emphasis)

• Defining and comprehending the functional elements thatconstitute the experiment

• Stating or projecting expected performance ranges and valuesfor critical functional elements

• Denoting the criticality of each experiment's functionalelement, and how it could impact the mission and/or systemoperation

• Anticipating possible design faults, operational malfunction,and failures of the functional elements so that the consequencescan be assessed

• Uncovering carrier/experiment design, operational, andperformance problems, and recommending approaches forsolving the'problems.

The POEA considers.only essential experiment functional elements andinterfaces that are most susceptible to fault, malfunction, and failure.Only selected experiment functional elements that are consideredcritical are followed to determine their probability of failure. This iswhy the functional block number indentures beyond 3. 5 are not listedconsecutively. Moreover, the interfaces are assessed for impact whenthey are deemed pertinent to the experiment element. The carrier/experiment interfaces are: >

• Physical--mechanical, electrical, communications, telemetrydata, and support

• Environmental--natural and induced

• Operational--flight/crew safety, pointing, control, and humanfactors.

2. Interface Block Diagram (IBP). An IBD is prepared for eachexperiment (Section II, Appendices A through U). It shows in a simplifiedmanner the physical, environmental, and operational interfaces thatexist among the carrier, experiment, ground, astronaut, etc. Some ofthe interfaces are abstract in the sense that no physical connectionexists between hardware components which could be controlled by signalintelligence or by the astronaut. Whenever an interface exists amongtwo or more elements on the diagram, the blocks are appropriatelycoded so that they can be described and related to an existing measure-ment number. The IBD contains as many blocks as necessary to pointout all of the physical and abstract interfaces, or to show the need to'acquire an interface where one does not already exist.

3. Systems Diagram (SD). An SD is provided for each ex-periment (Section III, Appendices A through U). It displays a compositebreakout of all operating equipment subsystems that make up the ex-periment. Usually, mechanical, electrical, fluid, instrumentation,telemetry, logic, and other subsystem descriptions are incorporatedin the SD. Evaluation personnel use the SD for familiarization,experiment baseline monitoring, and engineering working papers in thedevelopment of malfunction assessment and contingency plans. The SDis acquired from whatever reliable baseline Skylab program documenta-tion sources are currently available.

4. Data Management. Functional block 4. 0 is designed tospecify, acquire, and justify critical mission, system, and experimentdata requirements. Critical data requirements are essential needs thatmust be met to provide knowledge of the operating status of the abovecited program elements. The evaluator selects only those data measure-ments that measure carrier/experiment interface performance. Theperformance will be monitored over the duration of Skylab mission asnecessary and the experiment will be evaluated for success at the endof the mission.

a. Data Requirements Summary (DRS). A DRS table isprepared for each experiment (Section IV, Appendices A through U).Each table is an aggregation of selected physical a'nd operational datarequirements and is intended for use by the evaluator so that he cananalyze and evaluate the carrier/experiment performance parameters.The essential carrier/experiment data requirements are specified inthe following manner:

• Measurement name

• Measurement range and dimension of variables

• Measurement number

• Telemetry assignment channel

• Data return

• Data time

• Remarks.

Much of the input data used to describe the above requirements can befound in the following carrier/experiment documentation:

• Instrumentation Program and Components List (IPfkCL)

• Mission Requirements Document (MRD)

• Experiment Requirements Document (ERD)

• Instrumentation Requirements (IR)

• Interface Control Document (ICD).

Whenever the measurement and telemetry assignment channel columnalphanumerics are missing from the DRS sheet for a specifiedmeasurement name, the requirement is assumed to be either existingbut undefined ( i . e . , a measurement slot Is provided by NASA), or newand not recognized by MSFC/MSC documentation (i. e. , no measurementslot is provided by NASA). When this information is missing, an

appropriate clarification will be made in the remarks column. Thetime constraints column is used to help organize the data requirementsfor requesting the information from MSFC Skylab Mission OperationsOffice (PM-MO-MGR).

b. Data Request Form (DRF). The carrier/experimentevaluator prepares a DRF for each corollary experiment as needed(Reference 2). The DRF's incorporate the essential data requirementsused in the evaluation of the carrier/experiment performance, and aresubmitted to the PM-MO-MGR office for processing and approval. TheDRF's are used as the administrative processing mechanism foracquiring carrier/experiment performance data from MSC and MSFCflight operation centers. The DRF's are found in Section V,Appendices A through U.

c. Engineering Change Request (ECR). An ECR is preparedfor those data requirements that measure carrier/experiment interfaceperformance when no measurement slot is provided, and it is thoughtthat adequate justification can be made and submitted to the appropriateengineering organizations for disposition. The ECR is used for in-corporating a measurement name and number into the IP&CL and ICDwhere none exists, or the ECR is used as a matter of record when adesired data evaluation measurement is rejected. The ECR's are foundin Section VI, Appendices A through U, when applicable.

5. Evaluation Sequence. Step 5 (Figure 1) devises an efficienttechnique for acquiring operational carrier/experiment performance dataand evaluating them in a timely manner. Previous efforts were aimedat uncovering and defining essential performance data requirements.This step takes the data requirements and organizes them into asequence of procedural events that correspond to the expected operationof the Skylab mission.

An Evaluation Sequence (ES) is prepared for each experiment(Section VII, Appendices A through U). It is used for monitoring,tracking, and comparing carrier/experiment operation status; andtroubleshooting expected carrier/experiment equipment and datamalfunctions. The ES also relates contingency plans to experiment/crew task malfunctions, if they should occur, so that appropriatework-around action can be taken to minimize impacts against themission. The ES organizes information obtained from Reference 1(in particular, the SFP; IP&CL; ERD, Section 6. 0; and EOH, Volume II)for rapid carrier/experiment interface performance evaluation with aminimum of paperwork. The ES is flexible enough to permit theevaluator to change, at will, from a real-time evaluation mode (in

10

terms of seconds and minutes) to an all7time "evaluation mode (in termsof hours and days). Two ES forms are used. One is used for thoseexperiments or portions thereof that have .little or no telemetry outputdata. The other ES form is used for those experiments that have con-siderable telemetry output data. The ES forms are designed to providethe evaluator with the following information:

• Operation Step Number. This entry indicates the sequence ofexperiment or crew task operation with respect to the ex-periment's three operating procedural modes: Preparation (P),Operation (O), and Termination (T). The numbers associatedwith these letters represent the sequential steps and/or crewcues taken to operate the experiment. For example/ P 1.0is the first step taken in preparing the experiment for opera-tion, P 2.0 is the second step, and so on. Whenever a secondor greater alphanumeric indenture is noted, it indicates asubclassification of the previous procedural event and mayhave a single callout or series of telemetry measurementcallouts associated with it. A similar explanation is applicablefor both the Operation and Termination modes. A fourth mode,'Lift-off (L), is included to denote important mission flighttime elements referenced against booster launch.

• Crewman. This entry identifies the personnel responsiblefor performing test procedure tasks.

• Test Procedure. This entry depicts a crewman task operation,an operational status, or procedures that are to be accom-plished.

• Data Return Recorder Number. This entry is an alphanumericcode pertinent to recording and storing experiment data onvarious recorder systems. This identifier can refer to anytype recording system used for displaying or storing data suchas strip chart, tape, computer printout, etc.

• Measurement Name, Number, and Signal. This entry includes

measurement nomenclature, alphanumeric identifier, and adescription of the signal. The signal signature will incorporatethe magnitude or range of the dependent variable (voltage,temperature, pressure, etc.) against a time increment.

• Telemetry Assignment Channel. This entry refers toappropriate IP&CL for definition.

• Function. This entry identifies the type of measurement databeing interrogated, such as event, housekeeping, analog,and digital.

11

• Frequency. This entry indicates the number of times atask, measurement number, or data element is expectedto be performed, repeated, or transmitted. It is an indicationof how many times and/or how often the task is to occur.

• Range and Dimension of Variables. For Range, refer to anappropriate IP&CL for further definition. The Read termdenotes the specific value or range that the evaluator is expectedto acquire .during actual experiment simulation or flightoperations. If the actual experiment data return value orrange is not as shown for the listed Read value or range,the experiment may have malfunctioned or experienced ananomalous condition. Conversely, if the actual experimentdata return value or range is as shown for the Read valueor range, the experiment probably performed satisfactorily.

• Limit of Concern. This entry indicates the maximumallowable limit of variable performance (in engineering units).If the maximum allowable limit is exceeded, an anomaly hasoccurred, thus indicating the seriousness of malfunction orfailure. Whenever "over" and "under" limits can be deter-mined for the carrier/experiment interfaces, they shall beso noted. The stated limit of concern indicates to theevaluator minimum and maximum capable operation limitationfor the carrier/experiment equipment. This concept may beconsidered analogous to that of threshold operational efficiencyand "redline" limits. In both cases, it is understood that thecarrier/experiment can operate above or below its intendeddesign capability for a duration of time without its perfor-mance being materially degraded. The concept of limit ofconcern can aid the evaluator in assessing the seriousness ofa malfunction or failure, and help him to decide whether ornot to implement a contingency plan.

• Data Evaluation Checkoff. This entry denotes the status ofexperiment operation, i.e., satisfactory or anomalous.

• Data Evaluation Remarks. This entry denotes the type oftime frame (Real time, Near/Real time, and All time) inwhich experiment/crew task, measurement number, or dataelement was evaluated or looked at. Real time is stated inseconds-to-minutes interval, near/real time is stated inminutes-to-hours interval, while all time is stated in thehours-to-days interval. The time frame interval can beused to assess the relative importance of the data, when thedata are needed, and the sensitivity or insensitivity of thedata to affect the mission timeline and schedule. Actualcarrier/experiment return data, used as a verification ofthe Read term, may be entered by the evaluator.

12

• Contingency Plan Number. This entry references specificcontingency plans for an experiment/crew task element.The alphanumeric code shown in the column identifies acontingency plan for a particular malfunction or failure ofan experiment/crew task (Section VII, Appendices A through U).It is envisaged and hoped that the malfunction or failure wasconsidered prior to actual Skylab mission flight operations;and that the formulated contingency plan will provide the'required work-around procedures to minimize the malfunctionand failure. If the experiment/crew task is performed asscheduled and no malfunction occurs, the alphanumeric codeis ignored.

• Contingency Plan Remarks. This entry provides appropriatecomments and notes about the implementation of contingencyplans, status of anomaly, and additional problems. Otherentries might cover:--Description of the anomaly, malfunction, or failure, time

in mission when it occurred, and the trends that may havecaused it

.--Criticality of the anomaly, malfunction, or failure and thedegree to which it compromises the experiment and missionobjectives, and impacts subsequent missions

--Identification of any testing required in support of correctiveaction, changes that could impact the mission timeline, andprocedural changes to experiment operation.

6. Malfunction and Contingency Plan Outline. Expected carrier/experiment malfunctions, failures, and contingencies are considered infunctional block 6.0. A contingency plan is devised for each essentialexperiment/crew task that could impact the mission and experiment.objectives. The Malfunction and Contingency Plan Outline (MCPO)provides a set of work-around procedures that are expected to minimizecarrier/experiment malfunctions and failures. This does not meanthat a contingency plan is all inclusive for any possible malfunction andfailure, but rather considers only those malfunctions and failures thatare considered most likely to occur. In addition, even though a con-tingency plan is proposed for a malfunction or failure, it does notnecessarily follow that the plan will actually work the way it was in-tended, but rather the subjective probability of its working is high.This distinction is important because situations may arise where agiven contingency plan can fulfill its intended purpose, while othersituations could occur where a set of contingency plans cannot fulfilltheir intended purpose. When the latter situations arise, the evaluatorwill at least know what contingencies were considered unworkable. Itis hoped, of course, that a contingency plan is devised to cover as manymalfunctions and failures as possible. In fact, it is hoped that a con-tingency plan is never used, implying that the carrier/experiment is

13

- - i - ' —: .functioning as required. If the situation occurs where no work-aroundprocedure fulfills its purpose, the evaluator is required to improviseadditional contingency plans based on his intimate knowledge and ex-perience of the mission, system, and experiment.

Contingency plans for each experiment are found in Section VIII,Appendices A through U. The following information may be acquiredfrom the MCPO:

• Operation Step Number. This entry indicates the step-by-step experiment or crew task operation as previously dis-cussed for the ES sheet. A large background P, O, or Tletter is centered on each contingency outline sheet and helpsthe evaluator to distinguish among the three experimentoperating modes. Only essential carrier/experimentoperation step numbers that require performance evaluationare correlated between the ES and MCPO. Other proceduralevents and astronaut cues will not be shown on the MCPO.

• Experiment/Crew Tasks. This entry presents only theessential carrier/experiment operations that require per-formance evaluation between the ES and MCPO andreferences the contingency plan to the Operation StepNumber.

• Completed (-check). This column may be used to doublecheck the experiment/crew tasks in the ES as desired.

• Possible Malfunction. This entry denotes what carrier/experiment equipment and operational malfunctions can beexpected to occur during actual mission flight conditions.Each malfunction has an alphanumeric code that is correlatedto the MCPO Operation Step Number column, which, inturn, can be related to the ES.

The malfunction information is acquired by reviewing theMission Level and Experiment Level Failure Modes andEffects Analysis and the Mission Operations DesignSupport documentation (Reference 1); and then anticipatingpossible malfunction outcomes based on expected carrier/experiment performance operation lifetime. Further,mission and experiment complexity will influence the numberand types of malfunctions and failures that the evaluatorconsiders. Generally, as the mission and/or the experimentbecomes more complex, the probability of success decreases,and the chance that some element will fail increases. All ofthe above criteria are used to formulate possible malfunctions.It is envisaged that each experiment will be supported by amalfunction analysis and will be provided as backgroundinformation (Section IX, Appendices A through S).

14

• Contingency Plan. This entry provides the necessary work-around procedures to be implemented whenever it is desiredto minimize or eliminate a carrier/experiment malfunctionor failure; The work-around procedures are assigned analphanumeric code and are referenced to the Possible Mal-function and Operation Step Number columns.

The contingency plan is designed to specify alternative work-around procedures for carrier/experiment equipment operations,crew operations, and data retrieval operations. The methodfor devising contingency plan work-around procedures, asused in this report, is shown in Figure 2. The model inFigure 2 is self-explanatory and will not be expanded in thiswrite-up. It is sufficient to say that the model is adaptiveto human, carrier, and experiment needs; and probably somechanges or modifications to it can be expected in the future,whenever an evaluator or analyst deems it necessary.

• Remarks. This entry indicates whatever information or datathe evaluator considers important.

a. Malfunction Analysis (MA). As previously indicated,MA's are used to help define or denote what possible malfunctions andfailures might occur during carrier/experiment operations (Reference 3).Section IX, Appendices A through U presents the MA for the corollaryexperiments. The MA is one of the primary sources used in formulatingcontingency plan work-around procedures. It aids an evaluator in com-prehending what malfunctions and failures should be assessed so thatadequate contingency plans can be made.

7. Functional Block 7. 0. This block is concerned with gaininga comprehensive understanding of how the carrier'/experiment per-formance data are to be received, processed, evaluated, and acknowledgedunder simulated or actual in-flight conditions. It is envisaged that thiseffort will permit an experiment evaluation team to assess the usefulnessand value of the ES and the MCPO under simulated conditions. Anevaluation team can gain a high level of confidence during experimentoperation simulation runs by:

• Measuring the evaluator's ability to monitor and follow themission and carrier/experiment sequence of operations

• Recognizing the differences between nominal and abnormalcarrier/experiment operations

• Determining when malfunctions and failures occur

15

I B S•£ " .2

P< & 3

2 S §5.2 .2•2 -a t;rt 5

u« c

s-l e(D »H *T 0)

I S.2 2"" X 0- m^ w0)

Q

CO

<*HO

vO

T

Sp

ecif

y o

rD

esc

rib

eC

riti

cali

ty o

An

om

aly

or

Fail

ure

ro

sO h

Re

co

rd a

nd

•Hol

d S

olu

tio

nA

pp

roac

hes

fo

Co

nti

ng

ency

Ap

pli

cati

on

©

f> «" 2S i s2 <u2 uJ W

vO

•0 c

s ||IS o

i— 1 ^4rt *. ac ? a

t .

vO 0)w u

O c rt1) rt t< O

S 8 ° a<3 <= I <a

X (5 0 C

- o < 20 > 3a -< •

f t f

wQO

wo£i—*H55OU

C>J

WPSt)o

16

Inp

ut

Re

sult

s a

nd

Co

nc

lusi

on

s fr

om

Va

lue

an

d

Decis

ion

Cri

teri

a G

rou

p,

Re

f:

3.

1,

3.2

, an

d

3.

6.Z

•0 £ (0

:*!~ S«« 9 c« 'w uK a e3 g CO. n V

C

S «

> U « 4 ) 0•- rt o JB •-

I

C ' " o

o

as

t

Pro

bti

on

sp

en

de

nri

ab

les

ate itu

aD

ep

Va

r

*>

-Ills^ a S 3

S. >

O a •" <n

&

wQO

•JPH

Sh-H

HZO

wtf

" o 3

U)ot-l

17

oro

rj

-0 u -g> (D

M 24 L<C O.I* CLo> <;

< c -^ 0•*-» '̂m J

H Ow

fcf •• i javLx

ID "w"E S-* *J yH S 2S s£% 0 c

5 ^ - 2* i 3^ td 3x EC J-

uu

rj

vO ^ 0 ^ 5 ^i o ~^ E Sn) I-, h C ooC G- rt O *"2Kl O- 4J tl r™^

L » ^ " ^••H _ "**̂ jj '""J

„ .2 2 w 2TO ^ p» ^ Ofl? v~4 P ^MH o a .i: ~

HP

12

U2HO

Oo

W

D3k

18

• Selecting and knowing when to implement the appropriatecontingency plan work-around procedures

• Measuring the evaluator's reaction time and response tosimulated'carrier/experiment faults

• Training an evaluator to expect the unexpected.

It is obvious that Step 7 does not have, at this time, a specificdocumentation output and is not referenced in the Appendices. However,future requirements may dictate the need for specific documentation.

• Each experiment that is analyzed and verified for adequacy ofcarrier/experiment interface requirement compliance will have aConclusion and Recommendation component stated at the end of eachappendix (Section X, Appendices A through U).

D. In-Flight Evaluation

Steps 8 through 13 (and probably 7 and 14) are concerned withthe actual carrier and experiment during countdown, launch, andorbital operations (Figure 1). It is envisaged that the above operationswill be monitored by appropriate evaluation teams located at variousNASA centers (probably the HOSC for MSFC). All evaluation and con-tingency plan implementation efforts will be reported to KSC and MSCduring pre-flight (countdown) and to MSC for in-flight (launch andorbit) operating modes. Steps 8 through 13 are designed to be integratedinto any portion of the Skylab flight operation. However, Steps 8through 10 and 12 are only implemented when the carrier/experimentexperiences abnormal operating conditions; otherwise, they are ignored.Most of the carrier/experiment performance evaluation takes placeduring the in-flight portion of the Skylab mission. It is envisaged thatthe evaluator will closely follow the Skylab mission using an SRFP(Reference 1), the ES, and the MCPO documentation to support andevaluate carrier/experiment interface performance.

E. Post-Flight Evaluation

Functional blocks 14. 0 and 15. 0 are self-explanatory insofar asfunctions are performed by the evaluator. However, an explanation ofthe actual information flow and of responsibility for the preparation ofthe final report would be premature. These tasks "are still beingnegotiated among the laboratories at MSFC, as well as NASA; and willbe discussed when better defined.

19

REFERENCES

1. Meyers, J. E. : Skylab A Experiment Documentation Matrix.Teledyne Brown Engineering Company, Huntsyille, Alabama,October 21, 1971, TL-14099.

2. Golden, H. : Support Requirements Submission for Skylab.PM-MO-I-102-70, October 9, 1970.

3. Wilcoxson, C. B. , et al. : Mission Operations Design Support,Volume III-OWS Experiments Malfunction Analyses., MMC,June 30, 1971, ED-2002-1244.

20

BIBLIOGRAPHY

1. Suyemoto, L. : A Priority Model for Flight Operations Planning,ESD-TR-67-391. USAF, Electronic Systems Division, Bedford,Massachusetts, September, 1967.

2. Mesarovic, M. D. , Macko, D. , and Takahara, Y. : Theory oftlieraf cbical Multilevel Systems. Academic Press, New York,1970.

3. Preliminary Considerations Leading to Development of a ContingencyPlan for the Apollo Project, NASA TMX 54708. Office of MannedSpace Flight, Washington, D. C. , July 15, 1963, (Confidential).

4. Arabian, D. D. : Action on Mission Evaluation and Flight Anomalies,Astronautics and Aeronautics. March 1970, pages 72-75.

5. Corcoran, D. M. , Sjoberg, S. A., and Day, R. E. : Flight andGround Crew Operations. Astronautics and Aerospace Engineering,February 1963, pages 68-74.

6. Dorian, M. F. : A New Technique for the Scheduling and Simulationof Manned Orbital Operations. Paper presented at 3rd AIAA AnnualMeeting, Boston, Massachusetts, November 29 - December 2, 1966,AIAA paper no. 66-907.

7. Boynton, J. H. and Kraft, Jr. , C. C. : Flight Operations Planningand Preparation for Manned Orbital Missions. Paper presented at3rd AIAA Annual Meeting, Boston, Massachusetts, November 29 -December 2, 1966, AIAA paper no. 66-904.

8. Purser, P. E. , Faget, M. A., and Smith, N. F. (Editors):Manned Spacecraft Engineering Design and Operation. FairchildPublications, New York, 1964.

9. Mesarovic, M. D. : Multilevel Systems and Concept in ProcessControl. Proceedings of the IEEE, January 1970, pages 111-125.

10. Brewer, A. C. : Interactive Scheduling System, IBM SystemsJournal. November 1971, pages 62-79.

11. Systems Engineering Management. Military Standard MIL-STD-499(USAF), Washington, D. C. July 1969.

21

12. Hall, A. D. : A Methodology for Systems Engineering. D. VanNostrand Company, Inc., New York, N. Y. , 1965.

13. Asimow, M. : Introduction to Design. Prentice-Hall, EnglewoodCliffs, New Jersey, 1962 (Paperback),

NASA—MS FC

22