| layout | date | from | serial | subject |
|---|---|---|---|---|
tindallgram |
Feb 12 1970 |
FA/Chairman, Apollo Spacecraft Software Configuration Control Board |
70-FA-T-13 |
Software 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 Software 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 autopilot, 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 baseline 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 officially 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 developers. 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.