Upthread: MSFC/MSC OWS Computer Program Meeting (Jan 19, 1970)
See list attachedFebruary 12, 197070-FA-T-13FA/Chairman, Apollo Spacecraft Software Configuration Control BoardSoftware for the AAP CSM spacecraft computer
The time appeared right to try to find out exactly what the program requirements are for the CSM computer for AAP and we had meetings on January 28 and 30 to do that. As a result of these meetings, a number of PCR's will be prepared and submitted to the Apollo Spacecraft Soft- ware Configuration Control Board (SCB) meeting to be held early in March. At that time we will approve or disapprove these changes and the program will be essentially under configuration control. One thing that seems clear from our discussions is that program changes required for AAP are very few in number and, except for the docked digital auto- pilot, seem to be quite simple. This is no surprise; of course, but it is nice to confirm it.
Before getting into the detail of these meetings themselves, I would like to state a couple of ground rules which we established associated with the AAP computer program and how we intend to manage it. First of all, we selected the Apollo 14 command module program as our base- line since it is the latest, completely defined program we have right now. It is our intention to approve automatically any PCR for AAP which is approved for Apollo. In the case of program changes for Apollo which are not desirable for AAP we will issue an AAP PCR at the same time which deletes that particular capability. By this paper-work device we will maintain a complete list of PCR's defining the AAP program changes required for the current Apollo program to make it ready for AAP if we were to break off a flight program from Apollo for AAP at that time. In addition, it will provide an up-to-date definition of the capabilities of the AAP CSM program we plan to implement.
To get this list off with a big bang, we went through the entire Apollo 14 program and identified all those programs, routines, and extended verbs which we felt should be deleted. This list, which will be covered offi- cially by PCR's, accompanies this memo for your information. The criteria used to decide just what should be dropped from the Apollo program for AAP was simple. If someone could not identify a firm requirement for a particular capability, it was automatically deleted. It should be pointed out that by deletion we mean that the capability will not be available for use in flight. We are not insisting that every word of code associated with that particular program needs to be torn from the assembly, but we are asking that all references to these capabilities be eliminated from all AAP program documentation such as the GSOP's, Test Plans, User's Guides, Flow Charts, and so forth. Of course, the thing we are trying to do is to minimize the work of the program devel- opers. Obviously under certain circumstances it will be easier to leave some of these capabilities in the program, including testing them. In that case they should be retained. However, this will be by exception only and will require approval of the SCB.
By far, the largest discussion dealt with the rendezvous and how it should be performed. Basically the question was, should we use the standard Apollo techniques involving a CSI and CDH maneuver or, as some people suggested, should we change to a more flexible sequence of maneuvers used on occasion on Gemini, namely the NCC/NSR combination? The advantage of the former is that it exists in the current program. The advantage of the latter is that it provides a great deal more capability to maintain a nominal terminal phase in the face of dispersion. Its advocates expressed concern, that dispersion could be rather large on AAP due to the limited tracking available for targeting the early phasing-type maneuvers. The eventual outcome of all this was that we decided to go with the NCC/NSR sequence and this program will be changed accordingly. It should be noted that this decision also impacts the mission planning; that is, future reference trajectory documentation will reflect this decision. In addition to agreeing to the change to NCC/NSR, which is said to be rather trivial as far as the programming is concerned, we also agreed to add a new targeting program for computation of two earlier phasing maneuvers.
There were only about 6 or 8 other program changes suggested specifically for AAP and they are all pretty simple, like extending the VHF ranging input capability beyond 327 n. mi. and improving the SPS short burn logic to support the small rendezvous maneuvers. I might also point out two rather substantial Apollo changes which AAP will automatically inherit. They are the rendezvous improvements to simplify the crew's procedures and the universal pointing program being added to P20. Special attention will be given this important one to assure that there are no unique requirements for AAP which have not been provided by this routine since it will probably be used for attitude control of the docked configuration.
We also assigned some action items:
a. Make sure there is no special problem involved in aligning the CSM IMU prior to launch from a Saturn I-B; rather than a Saturn V pad. (Charley Parker, FCD).
b. Verify the interface from the CMC to the Saturn IU is identical to Saturn V to make sure our P11 program is all right. (Tom Lins, GCD)
c. Identify any coarse alignment program requirement we might have for aligning the command module IMU while docked to the Cluster, using the Cluster as an attitude reference.
d. Prepare a complete PCR identifying the functional requirements for the docked DAP. This big job, of course, is the responsibility of the GCD and Tom Lins will see that it gets done.
e. Jack Williams will get everyone concerned together to scrub the telemetry downlist,identifying spares and additions, if any.
I think everyone at the meetings agreed that we are in pretty good shape with respect to the definition of the AAP programs and should have little trouble in preparing the program from the Apollo assembly at the time we decide to do so. Although that won't probably occur for at least another year, it is expected that some off-line assemblies and documentation will be prepared by MIT as often as their effort on Apollo mainline permits.
Enclosure
DELETIONS FOR AAP
DELETED PROGRAMS
P15 Initiation of IU TB6
P22 Orbital Navigation
P24 Rate-aided optics for landmark tracking
P32 Co-Elliptic Sequence Initiation (CSI)
P33 Constant Delta Altitude (CDH)
P37 Return-to-Earth (RTE)
P38 Stable Orbit Rendezvous (SOR)
P39 Stable Orbit Midcourse (SOM)
P52 IMU Realign (Option 4 only)*
P65 Everything used exclusive for V> 27,000 fps can be deleted P66 from the Entry program such as Up Control and Ballistic
P72 LM Co-Elliptic Sequence Initiation (CSI)
P73 LM Constant Delta Altitude (CDH)
P74 LM TPI Targeting
P75 LM TPM Targeting
P76 Target ΔV
P77 LM TPI Search
P78 LM SOR Targeting
P79 LM SOM Targeting
DELETED ROUTINES
R05 S-Band Antenna Acquisition Angles
R33 CMC/LGC Clock Synchronization
R57 Optics Calibration
R64 PTC/Orbital Rate
DELETED EXTENDED VERBS
V44 Set Surface Flag
V45 Reset Surface Flag
V52 Marked on Offset Landing Site
V59 Please Mark (Optics Calibration)
V64 Start S-Band Ant Calibration
V68 CSM Stroke Test On
V94 Enabled Cislunar Tracking Recycle
*General – Delete all lunar and cislunar capability such as numerical integration and anything that requires use of the lunar ephemeris which will not be provided.