Progress Report – RTCC program development – Review of AS-258(!) requirements

FA/Director of Flight OperationsMAR 29 196767-FM1-26FM/Deputy Chief, Mission Planning & Analysis DivisionProgress Report – RTCC program development – Review of AS-258(!) requirements

This lengthy memorandum deals with the recently completed review of AS-258(!) RTCC computer program requirements. I hasten to say, many other areas remain to be examined in our effort to bring the over-all job supported by the MCC-H to within acceptable bounds and to assure economical RTCC usage. Of course, specific actions resulting from our efforts are covered in detail by other memos and directives, primarily those issued by the Flight Support Division to IBM. In addition, several analyses have been initiated within MPAD. My primary objective here is to summarize what we did and to document, for his- torical purposes, the rationale behind some of the decisions made.

Before I do that though, there is something else I'd like to point out. It became apparent to me that our review meetings had significant benefit aside from the main purpose of making sure the requirements were all justified. It turned out that there were several areas in which misunderstandings existed about what the flight controllers wanted and what the Flight Support people were attempting to provide. Resolution of these differences should be benefi- cial by improving the program and, in some cases, by significantly reducing the effort required. Another benefit was the recognition that certain asso- ciated things were not being done and action was immediately initiated. Probably the most significant of these was the lack of definition of the AGC telemetry downlinks by MIT which was severely impacting everyone's work – a problem we have taken steps to clear up. This also applies to renewed con- sideration of some displays provided to support certain flight controller functions but which are likely to be inadequate. Studies and analyses have been initiated to determine the inadequacy and, if necessary, to develop alternate proposals.

One other thing I probably should point out is that some of the processing and display capability which was identified as unnecessary in the AS-258 pro- gram obviously also applies to some of the earlier development flights. As a result, although we do not intend to go through a detailed review of AS-501 and AS-206 programs which have proceeded too far along to be fruitful, AS-258 deletions which also apply to those development flights are being made.

As usual, the material will be covered separated into three categories – trajectory, command and telemetry.

Trajectory:

1. Spacecraft weights, c.g. location, moments of inertia and fuel remain- ing computations are being deleted from the RTCC program since these tasks are carried out in parallel by the GNC flight controllers and their staff support personnel, whose computations are trusted more than those in the RTCC.

2. Maneuver line monitor displays were deleted. These displays were a carryover from Gemini, although they were not found to be particularly use- ful on that project. In fact, they apparently were never used for anything.

3. Double integration is a complex processor which was deleted following rather lengthy discussions and without flight controller concurrence. This capability was provided primarily for use in determining whether or not an SIVB state vector update should be made prior to the simulated TLI maneuver on AS-503. This was one of those capabilities which had been included in hopes it might help to do this difficult job. Subsequently, investigation has shown that this special, complicated logic was unnecessary in the first place since the equivalent job can be done with the program as it remains defined today. Still, it is notclear that doing the job in the proposed way is adequate and continuing analysis is underway.

4. Special logic was being provided to specify use of the y and z RCS thrusters for orbital maneuvers. We deleted this capability for two reasons: one – there is no capability being provided onboard the spacecraft for making guided maneuvers with those thrusters and, two – the RTCC program as current- ly defined is already capable of supporting maneuvers of this type, although the procedures are somewhat inconvenient.

5. A composite display of all pertinent spacecraft REFSMMAT's has been deleted since that information is available on other displays.

6. The target closest approach display is a carryover from Gemini for use by the flight crew support people primarily to support their work on inflight experiments. This was another controversial deletion which was only made after our agreeing to re-evaluate their capability to get along using two new Apollo displays in the AS-258 system and reconsidering addition of this dis- play if they encounter unacceptable difficulty. It is my impression the con- siderable new capability that the Experimental Acquisition Site display and the Star Sighting display have added should be adequate for handling their requirements, although perhaps not in quite such a convenient way.

7. It was agreed to delete the keyhole acquisition display provided the same information was incorporated in the Next Station Contacts display. It was our argument that this would not only simplify the program, but would actually present this information in a more convenient format for the flight controllers. For those of you unfamiliar with the expression “keyhole”, as I understand it, this refers to the loss of telemetry and command from some S-band sites when the spacecraft trajectory is such that the pointing angles fall within certain areas in which tracking is not possible. When it is determined by the RTCC that loss of contact will result, the Next Station Contact display will list that station as two or more separate contacts with all the associated information regarding duration of coverage, etc.

8. The M vs T_ff, M vs V and V_g displays were all dropped as being un- necessary for flight control.

9. Reentry footprint display was another controversial deletion which, incidentally, also applied to the AS-501 program. The Landing and Recovery Division people insist this display is used for making recovery force de- ployment decisions, but it appeared to me to be more of a “how goes it” display for impressing visiting dignitaries not directly involved in the operation. In its place we are slightly modifying the World Map display during the reentry phase to provide the same information. However, due to the reduced scale of the world map, this compromise does not completely satisfy those people most interested in retaining this display. Significant weight was given to the fact that projection plotboard displays of this type require by far the most extensive checkout and a significant reduction in effort would be achieved by this deletion.

10. Recovery Zone Summary plot was deleted since the information is readily available on other displays, such as the Recovery Zone Digital and Recovery Targeting Displays.

11. Revolution of the Ascending Node display is used by the flight crew support people and the recovery people for updating the crew and the recovery forces, respectively, with the information they need to lay out the ground tracks for the next six orbits. They had requested that the format of this display be changed somewhat, primarily to reduce the number of RTCC computer controller inputs required to support them. It was decided to put up with this not trivial inconvenience rather then to make this change now.

12. The General Purpose Maneuver programs and displays provide the flight dynamics people with a great deal of capability for determining maneuvers to satisfy a wide assortment of specific requirements. Although none of this processor will be eliminated, it is intended to restrict the flight verifi- cation testing to certain of the options based on a priority which has been established by the flight controllers.

13. The Launch Simulation Program was used to generate launch “nominals” on Gemini based on the desired insertion vector computed in the ACR. This Gemini carryover vas included in the Apollo 258(!) program but was found to be unnecessary and was deleted.

14. The line of sight thrusting for orbital maneuvers processor was deleted. This was provided for such things as making adjustments in perigee by maneuvers at apogee with the spacecraft aligned toward the horizon.

15. Probably the most controversial deletion in the trajectory area was a cutback in the number of options available to the retrofire officer for computing his maneuver. This subject is treated in detail in another memo. Briefly, it is intended to eliminate the capability of the RTCC to iterate for retrofire attitude in addition to retrofire time. This deletion was made based on my judgment that it was unnecessarily accurate and complex for the job that needed to be done.

Command:

Altogether, there are about 60 command formats which can be generated by the RTCC for the CMC, LGC and SLV for mission AS-258(!). We only deleted five and simplified one of the remaining, since all were either used fre- quently through out the mission or were required during time critical situa- tions. Two of those deleted were digital autopilot initialization command formats: the one for the command module was deleted since it could be handled with relative ease using the universal uplink (i.e., erasable memory uplink); the one for the LM was deleted since the design of the spacecraft computer program was such that even if sent the command would be ignored. Two special command formats had been requested for the retrofire external ΔV maneuver. One of these was deleted and the other was simplified by the elimination of the digital autopilot initialization parameters. Finally, it is my impression that two of the four SLV switch selector update formats are to be deleted.

Telemetry:

Most of the changes in the telemetry system are of two basic types – dele- tion of 104 discrete display formats (out of about 450 requested), and elimination of some of the redundancy in the data recall capability which was to be provided. In addition, there is one outstanding item initiated by our review which, if resolved favorably, will result in a substantial re- duction of work to be done. This is the elimination of all teletype telem- etry data. I understand there is a good chance this will happen.

Following is a summery of the changes brought about by our review:

1. High speed digital displays have been reduced from 94 to 62 formats!

2. High speed/low speed paging tabulation displays are one of the capabil- ities being provided for data recall. All together there were to have been 84 different parameter sets available in this display mode. This has been reduced to 75 sets which, at the rate of three display formats per set, eliminated 27 display formats.

Of equal or even greater significance than that is the reduction of the extent of data recall from 39 samples to a total of 15 samples. Based on the sample rate estimated by the flight controllers, this would have provided a data recall capability of about three revolutions rather than one. This extended recall capability required a large amount of extra computer logic, the elimination of which considerably reduces the total effort nec- essary to get the system running. My recommendation for this deletion was based on a feeling that the extended capability for instant recall really didn't do such good. A total mission data recall capability is provided by the RTCC Report Processor which prints out precisely the same informa- tion offline in a much more readable format. Of course, this introduces a 20 to 30 minute delay in obtaining the data as opposed to instant recall, but that doesn't sees unreasonable considering the way it will be used. The point is, in actual practice, it seems to me it will be necessary to rely on the offline processing to carry out this function anyway. Obvious- ly, if this turns out not to be the case, further consideration should be given to providing extended paging – probably for a longer term than two extra revolutions.

3. System plots have been reduced from 37 to 34 formats. These plots are set up to cover time spans of 200 seconds or 10 minutes. An effort was made to eliminate one or the other of these durations, but this was impossible due to their rather substantial justification.

4. Trend plots is a data recall capability which was carried over from the Gemini system, even though it was not found to be particularly useful to the “Systems” Flight Controllers. (It should be noted that some Flight Directors use them for handing over control from one shift to the next). Trend plots of all parameters stored within the RTCC were out of the ques- tion, and as a result only a limited number (37 formats in all) were to be provided. It has been decided to eliminate all of these with the under- standing that this job will have to be performed by hand plotting if nec- essary. It was apparent that hand plotting of parameters requiring special attention would have been done anyway since the quality of the trend plots on the TV screen is not adequate for detailed analysis.

5. There is a catchall category termed “special displays” which we re- duced from 14 to 9 formats.

6. Playback/dump displays. The capability to call up displays driven by real time data and playback data simultaneously was requested and is being provided. In some instances, the flight controllers have requested different display formats for the playback data as opposed to the real time data resulting in an over-all increase in the number of display formats re- quired. Consideration was to given making them all the same, but this proved to be impractical at this late date.

7. Limit sensing had been provided on two levels, but on closer examina- tion it was found that providing the secondary level was of little value since there were only a few instances in which it was to be used. As a result, this general flexibility is being deleted from the system and those special cases are being programmed individually.

Whew! That's about it! Long, but nothing particularly startling. Prob- ably not as great a cut back as you hoped might be possible. I really don't think anyone lost anything needed very badly and would argue that most of the stuff we cut out should not have been there, even if we didn't have a computer time shortage. That is, the cleanup was probably worth- while just for economical reasons.

Our next ventures are into the land of GSSC simulation and a look at the additives going from this program to AS-503(!).