Apollo Experience Report a Use of Network Simulation Techniques in the Design of the Apollo Lunar Surface Experiments Package Support System

8/8/2019 Apollo Experience Report a Use of Network Simulation Techniques in the Design of the Apollo Lunar Surface Experi…

http://slidepdf.com/reader/full/apollo-experience-report-a-use-of-network-simulation-techniques-in-the-design 1/14

N A S A T E C H N IC A L N O T E NASA TN 0-7783

M00hh

APOLLO EXPERIENCE REPORT -

A USE OF NE T WORK SI MUL AT I ON

TECHNIQUES I N THE DESIGN

OF THE APOLLO LUNAR SURFACE

EXPERIMENTS PACKAGE SUPPORT SYSTEM

by Richard A. Gustafson a n d Jeffrey N. Wilkes

Lyndon B. Johnson Space Center

Houstoq Texas 77058

- 7+.\97=

N A T I O N A L A E R O N A U T I C S A N D S P A C E A D M I N I S T R A T I O N WA SH ING TO N, D. C. SEPTEMBER 1974



1. Report No.

NASA TND-7783~

4 Ti t le and Subt i t l e

APOLLO EXPERIENCE REP ORT -A USE OF NETWORK SIMULA-TION TECHNIQUES IN THE DESIGN O F THE APOLLO LUNARSURFACE EXPERIMENTS PACKAGE SUPPORT SYSTEM

2 . Government Accession No.

7. Author (s )

Ric har d A. Gustafson and Jeff rey N. Wilkes

9. Performing Organization Name and Address

Lyndon B. Johnson Space Cen terHouston, Texas 77058

17. Key Words (Suggested by Author(s1' Systems C,ompat ibi l i ty' L u n a r E x p l o r a t io n* C o m p u t e r S i m u l a t io n' Data Links

12. Sponsor ing Agency Name and Address

Nat iona l Aeron aut ics and Space A dmini s t r a tionWashington, D. C. 20546

18. Dis t r ibut ion Statement

STAR Subject Catego ry: 31.

15. Supplementary Notes

19. Secur i ty Classi f. (of this r epo r t )

Unclas s i f i ed Unclas s i f i ed 1 2

20. Security Classif. (of this page) 21. No. of Pages

3. Recipient's Catalog No.

22 . Price

$3.00

~~

5. Report Date

S ep t em b e r 1974

6. Performing Organization Code

8. Per forming Organizat ion Rep or t N o.

JS C S-404

10. Wor k U n i t N o .

921 -10-10-00-72

1 1 . Contrac t or Grant No

13. Typ e of Report and Per iod Covered

Technical Note

14. Sponsor ing Agency Code

16. Abstract

A c as e s tudy of da ta -com mun ica t ions ne twork model ing and s imula t ion is presen ted .app l i cab i li ty of s imula t ion t echniques in ear ly sys tem des ign phas es is dem ons t r a ted , an d theea s e w i th w h ich m o d e l p a r am e t e r s c an b e ch ang ed and co m p r eh en s i v e s t a t i s t i c s g a t h e r ed isshown.an d i m p l em en t a t io n of the Apollo lunar su r fac e exper im ents package ground-suppor t sys tem .

The

The d i scus s ion of the model design and appl ica t ion a l so y ie lds an ins igh t in to the de s ign



APOLLO EXPERIENCE REPORT EDITORIAL COMMITTEE

The material submitted f o r the Apollo ExperienceReports (a se r i e s of NASA Technical Notes) was reviewedand approved by a NASA Editorial Review Board at theLyndon B. Johnson Space Center consis ting of the followingmembers: Scott H . Simpkinson (Chairman), Richard R.Baldwin, J am es R. Bates, William M. Bland, Jr . , Aleck

C. Bond, Robert P. Burt, Chris C. Cri tzos, E . M. Fields,John M. Eggleston, Donald T. Gregory, Edward B.Hamblett, Jr., Kenneth F. Hecht, David N. Holman (Editor/Secre tary) , and Ca rl R. Huss.



APOLLO EXPER ENCE REPORTA U S E O F N E TWO RK S I M U L A T I O N TE C H NI QU E S I N

THE DE SIG N OF THE APOLLO LUNAR SURFACE

E X P E R IME N T S P A C K A G E S U P P O R T S Y S T E M

B y R i c h a r d A. G u s t a fs o n a n d J e f f r e y N. W i l k e s

L y n d o n B . J o h n s o n S p ac e C e n t e r

S U M M A R Y

The Apollo lunar surface experiments package ground-support system and theManned Space Flight Network ar e described functionally, A suspected design problemconcerning the experiments package/network inter face is discussed. It w a s learnedthat analysis of the data-communications interface problem w a s most feasible by theapplication of modeling techniques. The data-handling conventions of the MannedSpace Flight Network communications system are discussed , and the embedding ofthese conventions in a genera l -purpose simulation -system network model is described.The model was run using anticipated network traffic loads fo r a lunar-landing missionand extensive data-traffic statistics. The resul ts of the network simulation confirmedthe suspected data-handling problems and suggested alternative solutions. Thevalidity of the simulation results and of the implemented solution w a s confirmedby postmission analysis of the logged data traffic.

I N T R O D U C T I O N

In the summ er of 1968, the NASA Lyndon B. Johnson Space Center (JSC) (for-merly the Manned Spacecraft Center (MSC)) w a s charged with the real-t ime dataacquisition , command, and control of the Apollo lunar surface expe riments packagesthat were to be emplaced on the lunar surface during the lunar explorations. The

(ALSEP) progr am we re considerably different fro m those previously encountered inthe suppor t of manned missions. Some of the unique ALSEP support requirements arestated in the following paragraphs.

support r equir ement s necess itated by the Apollo lunar surface exper iments package

Sustained, continuous support was requi red for long mission phases. EachALSEP required 45 days of continuous support after deployment on the lunar sur face,2 . 5 days of continuous support after each terminator crossing (lunar sunrise and sun-set), and 2 hour s of support per E ar th day. Because each ALSEP had a projected



lifetime of 1 to 2 yea rs, multiple mission support w a s also required.duration, long -term support requir ements had to be contrasted to the relativelyshort-duration manned missions (8 to 9 days for Apollo missions) fo r which the MSC

Mission Control Center (MCC) w a s intended.

These long-

A high degree of support-system reliability w a s not requ ired for ALSEP

suppor t, and data-system redundancy was not required, Restoration of failed systemshad to be accomplished only within 2 hours, The rather modest system reliability andavailability requirements fo r the ALSEP support wer e relaxed considerably f rom these ve re requir ements placed on manned-mission support syste ms ; for example, thereal-time computer complex (RTCC) required the attainment of a reliability (proba-bility of zero failures) goal of 0.9995 for the critical phases of Apollo missions.

Support of the ALSEP did not requi re large support sy st em s comparable to thescal e of the MCC Apollo systems. Pr oc es so r sizing est imat es indicated that amedium -scale computer sys tem would meet communications and data -processing r e -quirements. The MCC Apollo sy st em involved the use of a Univac 494 as a communica-tions processor and an IBM 360/75 as a real-time data processor; both of these were

large -scale computer systems.

An MCC ALSEP support system that was independent of but compatible with theApollo systems w a s necessary because of the requirements that the ALSEP have sus-tained support, minimal reliability, and moderate processing ; that the ALSEP supporthave minimal effect on Apollo support; and that the ALSEP systems be as compatibleas possible with exist ing syst ems. Not only would the compatibility of the ALSEP andQpollo support sy st ems facili tate necessary human and equipment inte rfaces withexisting systems, b u t syste ms compatibility also would allow the sa me hardware andsoftware technology used in Apollo support to be used in the design and implementationof the ALSEP support system.

S Y S T E M D E S C R I P T I O N

The resulting ALSEP support system used a medium -scale general-purposecomputer system (an IBM 360/50) as a combined communications and real-time dataprocessor. E a r l y in the design stages of the ALSEP support syste m, it w a s recognizedthat maximum and efficient use of the MCC resources would result if the ALSEP couldbe supported by the existing large -scale IBM 360/75 computer sy st em s constitutingthe RTCC. Initially, the following basic f ac to rs precluded using an IBM 360/75 tosupport the ALSEP.

1. At that time, Apollo and ALSEP development, testing, and simulations re-quired all available computing re so ur ce s, including the IBM 360/50 computersupporting the ALSEP.

2. Efficient use of the IBM 360/75 computer in suppor t of ALSEP required thefinal development and checkout of a multijobbing real-time operating system So that theex ce ss capacity of the IBM 360/75 supporting the ALSEP could be used for other tasks.

2



The requirements of reduced computing -resource needs and development of amultijobbing real-time operating system were met by the time of the first successfullunar landing (Apollo 11) . Consequently, ALSEP support was re located to the RTCCduring the first lunar night after deployment of the early Apollo scientific experimentspackage, a reduced version of ALSEP. It should be noted that the eventual use of an

IBM 360/75 rather than an IBM 360/50 computer had no functional effect on the ALSEPsupport system. In fact, even the programing system w a s completely compatible witheit her machine.

The ALSEP computer provided the necessa ry interf aces and processing capabilityto accept, format, process, and transmit ALSEP telemetry, command, display, andcontrol data. After being telemetered from the lunar surface, all ALSEP telemetrydata wer e sent directly from the Manned Space Flight Network (MSFN) through theNASA Goddard Space Flight Center (GSFC) to the MCC data links. This mode of opera-tion allowed the ALSEP support system to function without dependence on the commu-nications pro cess ors at the MCC. The ALSEP command and control data were receivedfrom the ALSEP display/control subsystem. Then, the commands were verified and

forwarded to the ALSEP directly through the MSFN interface o r , i f the Apollo syst em salso wer e using the network, through the MCC communications pr oc es so rs to the net-work and, ultimately, to the ALSEP. Control data were used to select display formats,to control ALSEP teleme try st re am selection, and, in general, to control the ALSEPcomputer processing . The ALSEP display data wer e transmitt ed by the ALSEP com-puter, under display control, to the ALSEP display/control subsystem. Display dataconsisted of data for the ALSEP high-speed line prin ter ; digital data for digital eventindications; and analog data for seismic drum recorders, analog strip-chart recorders,and analog met er displays. The ALSEP support system and its relation to Apollo sup-port systems in the MCC are shown in figure 1 .

A s can be seen in figure 1, the goal of an independent ALSEP support system at

the MCC was met by implementing a modest (by Apollo standa rds ) facility to beoperat ed in parall el with the existing Apollo syst ems. However, both the ALSEP andApollo s ys te ms requ ired an interface with and used the MSFN for data communicationsand command traffic. The design and implementation of the ALSEP interf ace with theMSFN was a cri tical step in the evolution of the ALSEP support system.

1

~~

The MCC communications processing facility (communications, command, andte lemet ry system) was composed of th ree Univac 494 computers, and the real-timeprocessin g facility (the RTCC) w a s composed of five IBM 360/75 computers .

3



Worldwide remote sites

2.4-kbps data lines

Goddard Space

Flight Center1

Mission Control

Center

50-kbps

w Ide- band

data links

NETWORK INTERFACE

Goddard Space Flight Center

communications processors

ALSEP

displaylcontrol

subsystem

Figure 1. - The ALSEP and Apollodata flow,

A contradiction in requ ireme nts wasencountered when the functional design ofthe ALSEP interfa ce with the MSF" was

initiated. Redundancy of the ALSEP sup-

whereas the compatibility of ALSEP sup-

was required. These superficially unrelatedrequirements conflicted because all networktraffic was received by the MCC through re-

dundant 50-kbps wide -band data ci rcui tsoperating in a primary/alternate configura-tion. An inter face with both wide-bandcircuits would have required redundantALSEP interfacing equipment. Because the

network interface equipment was requir edto provide message framing and er r o r -blockencoding and decoding and to meet all data-se t and computer conventions, the cost foreach in terface unit was expected to be quitehigh. The "no redundancy" requir ementcould not, therefore, be taken lightly.

por t sy ste ms was explicitly not required,

port with existing ground-support systems

One possible solution to the networkinter face imp asse would have involved the

a manual switch to the alternate cir-

construction of a single interface unit with the capability to switch between the two

data circuits. If the pr ime cir cui t should fail,cuit could be made. This approach would appea r satisfactory because syste m failuresrequir ed res toration within 2 hours. Certainly, lo ss of data (failure) could be detectedand a switch to the alternate cir cui t made within seconds or , at most, minutes. How-eve r, one additional facto r had to be considered.

The second line of the two wide-band da ta c ircuit s between the GSFC and theMCC was used not only as a backup in case the first line failed but als o as an overflowline in case the data-carrying capacity of the first line was exceeded. There fore, datalo ss to the ALSEP facility would occ ur if ALSEP data overflowed to the alternate linewhile the interface unit w a s connected to the pr im ary line. However, an Apollo mis sio nground rul e required that mission traffic always be limited to the capacity of a singleline.short-term data rate exceeded the line capacity of 50 kbps while the long-term rateremained below 50 kbps.

Assuming this ground rule was obeyed, overflow could be expec ted only when the

'Circuit failure was assum ed when the mes sag e originator failed to receive amessage acknowledgment from the rece iver f or five consecutive 600-bit data blocks.Trans mission would then switch automatically to the alternate circuit.

4



Because of a possibility of data loss, a study w a s initiated to determine theprobable severity of data overflow to the alternate ci rcuit and, i f severe, to examineand recommend alte rnat ive courses of action. It should be noted that overflow couldoccur only during those periods when both Apollo and ALSEP data were being sentover the network; the ALSEP data alone could not precipitate data overflow. Moreover,

if desir ed and if Apollo sy st em s were not using the network, the data link between theGSFC and the MCC could be used in the "forced" mode; that is, by forcing all data

over one circuit.

NETWORK DESCR IPTI O N

For the purposes of the analysis, th e M S F " consisted of worldwide remote sitesto acquire telemetry and trajectory data, 2.4-kbps data links to telemeter the digital

data to the GSFC, communications process ors at the GSFC to reformat and multiplexthe data, and two 50-kbps wide-band data circuits to route the multiplexed data to the

MCC. This data flow is illustrated in figure 1.

The telemet ry equipment at each remote si te w a s capable of transmittingtwo 2.4-kbps data s t rea ms continuously. Each 2400-bps data st rea m w a s formattedinto 2400-bit blocks. The data rate and block size wer e fixed for each telem etry siteand wer e not dependent on vehicle or mission. Each fixed remot e sit e in high-speedtracking support produced ten 240-bit blocks/sec on a 2 . 4 -kbps circuit.

The GSFC communications processor transmitted the received remote -sitehigh-speed data to the MCC through the wide-band data links at a data rate of 50 000 bpsin 600-bit burs ts . Each 600-bit block consisted of a 480-bit block, containing data orf i l l (or both), and 120 bit s of overhead. Therefore , five 600-bit blocks we re requi red to

support each remote-site telemetry stream (480 data bits/block X 5 blocks = 2400 bits).A maximum of two telemetry st re am s for each sit e was possible. Each fixed trackingsit e requir ed ten 600-bit blocks/sec to transmit the 10 incoming 240-bit blocks. A s ofthe date of the analysis, no attempt had been made to pack two high-speed trackingfo rm at s into one wide-band data form at.

Because the GSFC me ssag e -switching sys tem wa s designed to "throughput" datawith minimum delays, a 600-bit block was formatted as soon as 480 telemetry bi ts o r240 tracking bits wer e buffered fro m a remote site. This design implied the fo rm a-tion of a 600-bit block every 200 milliseconds for each remote-site telemetry streamand every 100 milliseconds for each remote tracking site.

Each of the two GSFC/ MCC wide-band data circ ui ts used an output queue (aline of data blocks ready to be serv iced) capable of queuing fifteen 600-bit wide-banddata blocks. One circuit was designated the pr im e circuit and the other the alt ernatecircu it. During normal operation, message transmission was on a "messagerot ary - pr im ar y/ overflow" basis. Therefore, messages were transmitted on theprime circuit i f available and on the alte rnate (overflow) cir cui t if the prim e circuitW a s not available. Messages could consist of one or more segments (600-bit blocks),and a me ssa ge could not be split ac ro ss the two ci rcuit s. A telemetry message con-tained fiv e segments, whereas a fixed-site trajectory message contained one segment.

5



The availability of a ci rcui t was determ ined by the length of the output queue. Onreceipt of the first segment in each message, the count of the pri me and alte rnatequeues was compared and the message transmitted on the circuit with the shorte stqueue. If only one wide-band data ci rcu it was made available ( forced mode), the full15-segment queue was used with no possibility of overflow. Two additional segmentbuffers fo r each queue were effectively "hidden, " however, from the routing logic.These hidden-segment buffers result ed f ro m the double buffering of outgoing segments

within the wide-band data-network i nter face units (Univac special polynomial t erm ina lsubsystem type 33/ 22) a t GSFC. Actually, the hidden-segment buffe rs made therouting operate a s i f overflow could occur only af ter t hre e segments were in the pri mequeue instead of one.

NETWORK TRAFF IC

To perform an overflow analysis, a knowledge of the expec ted traf fic to be

handled by the network is required. Esti mates for the worst-case network trafficduring lunar-landing mi ssions were four tracking sites with thr ee two -line t elemetry

sites durjng lunar descent/ascent phases and thr ee tracking si te s with four two-linetelemetry sit es during launch phases. Remote -site support estim ates of t his magni-tude re sul ted in the following traffic -loading predictions fo r the GSFC/MCC wide -banddata link.

1. During descent/ascent phases: 40 segments/ sec t racking and 30 segments/s e c telemetry, yielding 42 000 bps

2. During launch phases: 30 segments/sec tracking and 40 segments/sec

telemetry, again yielding 42 000 bps

The ALSEP data load had to be added to the Apollo traf fic. In support of ALSEP

(a maximum of two ALSEP sit es) , each remote s it e would contribute 5 segments/ sec tothe data-link traffic. Because the worst-case Apollo phases resulted in equal traffic,

the aggregate anticipated wors t-case loads on the GSFC/MCC wide -band data links

we re Apollo mission support with one ALSEP site (45 000. bps) and Apollo missi on sup-port with two ALSEP sites (48 000 bps). Although the pred icted traf fic loads we re with-in a single wide-band da ta-cir cui t capaci ty of 50 kbps, queuing of segments withsubsequent data overflow could occur i f the segment arr iva ls to the circuit queue werenot spaced equally in time, Thi s '%bunching in time" of s egments wa s possible becausethe remote sites, which ultimately controlled segment generation, wer e not synchro -nized and could initiate a message start a t any random ti me (random within a 1-secondinterval).

C I R C U I T O VERFLOW A N A L Y S I S B Y M O D E L I N G

To obtain the probability of data overflow to the alt ernate wide-band ci rcui t, thefollowing three basic approaches were consid ered: a n analytic probabilistic solution,an empi rical solution obtained by act ual network operation, and a modeling solutionobtained by simulating the network. After the analy tica l approach was discard ed as

6



being essentially insolvable without drastic simplification assumptions and afte r theempirical approach was discarded as being impractical because of the cost and thedifficulty of operating a worldwide data-communications network for test purposes, thesimulation approach w a s chosen.

To simulate data-overflow conditions and to obtain sta tis tic s on overflow occ ur-rences, a network model was developed. The model w a s driven by a variable numberof telemetry and tracking sources corresponding to the remote sites. Each telemetrysource w a s represented by the random generation of a message segment having a uni-form distribution on the interval from 0 to 1 second and of subsequent segments havinga period of 200 milliseconds. Each five successive segments constituted one telemet rymessage. Each line of the two-line telemetry rem ote sit es was represented by a sep-arate teleme try source. Each tracking source wa s represented by the random genera-tion of a mess age segment having a uniform distribution on the inte rval from 0 to1 second and of subsequent segments having a period of 100 milliseconds. Eachsegment constituted one tracking message.

The network model accepted each source segment and determined whether it wasa "first of message" segment. If the segment was a "first" segment, the modelchecked the pr im ary output queue count. If K (the queue-overflow level) or fewersegments were in the prima ry queue, the message w a s assigned to the prime queue.If mor e than K segments were in the prim e queue, the alternate queue count w a schecked and the message w a s assigned to the shor tes t queue. The factor K w a s avariab le. Each segment incremented the count of the queue to which it w a s assigned.

Both queues decremented at the rate of once each 1 2 milliseconds (the tra nsmi ssio ntime of a 600-bit segment on the wide-band data links). The following statistics wereto be collected from the model.

1. Average length of queues

2. Maximum length of queues

3. Number of tracking segments sen t to prime and alternate queues

4. Number of t elemetr y segments sent to prim e and alternate queues

5. Number of ALSEP segments sent to pr im e and alternate queues (The ALSEPwas treated as a single-line telemetry source. )

6. Total number of telemetry, tracking, and ALSEP segments generated

7. Extent of p ri me and alternate circuit use

M ODEL I M PLEM ENTATI ON AND OP ERAT I ON

The network model w a s designed and implemented in the IBM general-purpose

The model was fairl y short, requiring approximately 100 GPSSsimulation system (GPSS) language and was executed on the MCC IBM 360/50 and360/75 computers.

7



operations. A s input parameters, the model accepted the queue-overflow level K , thenumber of telemetry sou rces (f or which each double-line telemetry source was treated

as two telemetry source s), the number of tracking sourc es, and the number of A L S E Psources (treated as single -line telemetry sites ), A s output, the model automaticallyprovided the maximum length of queues, the total number of segments sen t to eachqueue, the use of wide-band data lines, the number of segments sent to each line, and

the various queue and line statistics. In addition to the aggregat e queue and linestatistics, tables on the queue contents (both primar y and alternate) wer e generated f ortelemetry, tracking, and ALSEP data. These tables indicated the number of segmen tsin the prima ry o r alternate queue awaiting transm issio n after each segment w a s placedin the prime/al terna te queue. Thi s information allowed examination of the distr ibut ionof queue contents,we re specified in integral numbers of seconds.

The model time resolution was 1 millisecond, and the model runs

To calibrate and tes t the network model, sev eral predictable t raff ic -loadingcases were modeled. These ca se s started telemetry, tracking, and A L S E P traffic atspecified tim es (as contrasted to random times). Because the start times were the

only random pro cess es in the model, the res ul ts were predetermined and agreed withpredictions,

Because the traffic -source (telemetry, tracking, and A L S E P ) start times werethe only random variabl es i n the model, network-traff ic flow became periodic within

1 second (period of telemetry and A L S E P messages). Because of the periodicity, eachsimulation randomly started all sites, collected data for 1 second, and repeated theprocess for the period of specified time. The "r est ar t each second" model allowedthe maximum random variation of the traf fic flow. Severa l ca se s of traffi c flow weresimulated by varying the combinations of traffic s our ces and aggregate traffic loads.

In addition, seve ral cas es with varying queue-overflow level s were modeled. The

results of these runs a r e summarized in table I.

of two represented the model of the existing routing technique. A queue-overflow

level of two was used because the previously mentioned double buffering of eachnetwork interface unit effectively resulted in two hidden-segment buffe rs in each

queue. The "queue-overflow level" column of table I includes the two hidden buffers.

Cases having a queue-overflow level

Data overflow occurred in all cas es that we re simulated with an overflow levelof two, as seen in table I. Overflow continued at high traffic loads until the overflowlevel was increased to nine segments. It is interesting to note that the maximumdifference between maximum queue contents with overflow leve ls of two and nine wasonly th ree segments, an indication of a minor segmen t time-delay difference betweenthe different overflow levels.

MODEL1NG RESULTS

With an overflow level of two segments, overf low of A L S E P data to the altern ateline was deemed probable at anticipated traffic loads. This conclusion w a s based onthe observed high ra te of overflow shown by the simulation runs. The us e of the pri meline was fair ly low (68 to 89 percent of capacity) on the ru ns with an overflow level Of

two (table I), an indication of a high overflow rat e. An in cr eas e in overflow level tofive segments significantly reduced the overflow probability but did not eliminate it.

8



bzkl0

w w w m m m a w e e w w m a w t - e w4

.r(

Y

.-I

3&I

0

IIIPe0V

aJ

00CT)

u-4

m

Palcd

Y

4zr(

m

'CIecd

Pe

aJm

8

k0,>aJ

0)V&7

m

s:

E

V.r(

2

Y

9



At an overflow level of nine segmerits, no data overflows occurred during all simula-tion run s with traf fic loads below line capacity. This elimination of overflows occu rr edwith a maximum incr ease of thr ee queued segments over the cases with an overflowlevel of two (from six to nine segments ), It should be noted that an overflow is possible(but not probable) even with an overflow level of nine. Rece ipt of 10 segments within12 milliseconds would have caused an overflow at 30 kbps.

Certain combinations of telemetry - and tracking -segment arr iva l t ime s couldhave resulted in overflow, even though aggregate traf fic loads were below line capacityand a high overflow level was used, Because the number of possible combinations of

data-source ar ri val ti mes ranged from 1021 toresolution and start times from 6 to 12 data so urces uniformly distributed over1 second), an exhaustive examination of all possible combinations clearly was impossi -ble. Therefore, the model could randomly sel ect only a small sample of these combi-nations. Consequently, it w a s cautioned that, although no overflows occurred withtraff ic loads below 48K with an overflow level of nine in the model runs , the proba -bility (apparently slight) did exist that overflow could occur.

(assuming 1 millisecond time

CONCLUDING REMARKS

The resu lts of the network simulations indicated that a single Apollo lunar sur-face experiments package facility inter face with the network would re sul t in data lo ssi f the existing data-routing techniques were used.data-overflow problem seemed apparent. The first two proposed solutions, increasingthe queue-overflow level to nine segments or recognizing and f orce -routing all Apollolunar surface experiments package data on the prime line, had to be eliminated becausethey would have required modifications to the routing programs at the Goddard SpaceFlight Center.

changes was considered unacceptable.with network conventions and the implementation of functionally redundant networkinter face units, one unit for each of the tw o wide-band data circuits.

Three alternative solutions to the

The ri sk to Apollo missions that is inherent in any routing-program

The remaining solution required compliance

The implementation of two interface units was the cour se of action followed.validity of this solution was verif ied when, after the support of the Apollo 11 missionand the early Apollo scientifi c experiments package, examination of data log tapesindicated significant Apollo lunar surface experiments package data overflow to thealternate line.unit.

The

These data were, of course, received on the second network interface

Lyndon B. Johnson Space CenterNational Aeronautics and Space Administration

Houston, Texas, May 6, 1974921 10 10 0072

10 NASA-Langley, 1974 5-404



AERONAUTICS AND SPACE ADMINISTRATION

WASHINGTON, D.C. PO546

OFFICIAL BUSINESS

PENALTY COR PRIVATE USE m oo SPECIAL FOURTH-CLASS RATE

BOOK

POSTAGE AND FEES P A I D

NATIO NAL AERONAUTICS AN D

SPACE ADMINISTRATION

4S 1

P O s T M A s T ~ R :If Undeltverable (Sectlon 168Postnl Mnnunl) Do Not Return

“The aeronautical and space activities of the United States shall beconducted so as to contribute . . , to the expansion of human knowl-edge of phenomena in the atmosphere and space. The Administrationshall provide for the widest practicable and appropriate disseminationof information concerning i t s activities and the results thereof.”

-NATIONAL AERONAUTICSND SPACE ACT OF 1958

NASA SCIENTIFIC AND TECHNICAL PUBLICATIONS

TEC HN ICAL REPORTS: Scientific and

technical information considered important,

complete, and a lasting contribution to existingknowledge.

TECH NICA L NOTES: Information less broadin scop e but nevertheless of imp ortan ce as a

contribution to existing knowledge.

TECHNICAL MEMORAND UMS:

Information receiving limited distribution

because of prelim inary data , security classifica-

TECHNICAL TRANSLATIONS: Information

published in a foreign language considered

to merit NASA distribution in English.

SPECIAL PUBLICATIONS: Information

derived from or of value to N ASA activities.

Publica tions include final reports of ma jor

projects, monographs, data compilations,

handbooks, sourcebooks, and special

bibliographies.

tion, or other reasons. Also includes conference

proceedings with either limited or unlimited

distribution.PUBLICATIONS: Information on technology

used by NASA that may be of particular

CON TRACT OR REPORTS: Scientific andtechnical information generated under a NASA

contract or grant and considered an important

contribution to existing knowledge.

interest in comm ercial and other- non-aerospaceapplications. Publications include Tech Briefs,

Technology Utilization Reports and

Technology Surveys.

Dotails on the availability of these publications may bo obtalnod from:

SCIENTIFIC AND TECHNICAL INFORMATION OFFICE

N A T I O N A L A E R O N A U T I C S A N D S P A C E A D M I N I S T R A T I O N

Washington, D.C. 20546

Documents

Apollo Experience Report a Use of Network Simulation Techniques in the Design of the Apollo Lunar Surface Experiments Package Support System