See listMAR 23 196767-FM1-23FM/Deputy Chief, Mission Planning and Analysis DivisionSummary of what needs to be done to develop flight confidence in the spacecraft computer programs
There has been growing concern in many quarters regarding the adequacy and formality of the final verification testing of the Apollo spacecraft computer program and its interfaces with other spacecraft systems. This concern led to a meeting on March 21st to decide whether everything was really okay and whether something should be done about it. Attendees to this meeting were Don Cheatham, Aaron Cohen, Cline Frasier, Bob Gardiner, Tom Gibson, Myron Kayton, Stan Mann, Tom Price and Bill Tindall of MSC and John Norton and Mike Richter of TRW.
Our attention was primarily focused on the first LM program [formerly known as AS-206] although it was not restricted to that one. Indeed, this group felt that the situation vas not satisfactory; that formal flight verification testing was not being carried out in the controlled, thorough manner necessary to develop flight confidence; that documenta- tion of the test plans and test results was not even adequate to really understand what bad been done.
One conclusion, obvious from the start, was that the AS-206 flight sched- ule, or whatever the first LM mission is to be called, does not permit delay of rope manufacture until that testing and documentation which would ordinarily be considered necessary prior to rope manufacture could be completed. In this instance, they must be carried out in parallel. If results of this effort are such that changes in the program are con- sidered mandatory, ropes will have to be remanufactured and a slip in the flight schedule may occur. Alternately, flaws in the program revealed in this process could result in revision in the manner in which the mission will be flown; e.g., changes could be made in the erasable load, maneuver targeting, command update from the ground, mission rules, flight limits, etc.
Specific action items resulting from this rump session are as follows:
1. It was agreed that only MSC is in a position to integrate the over-all system. It is our proposal that this be carried out by the Guidance Soft- ware Control Panel [GSCP], and the Chairman of that panel accepted as an action item the task of developing plans and an organization to carry out the MSC integration function. It was emphasized that this is a systems integration task not restricted to spacecraft computer programming but also covering all interfaces with that component. This task includes coordinating the activity of all associated organizations and making sure that nothing falls down a crack.
2. Each individual organization involved [i.e., MIT, GAEC, TRW, MSC, etc.] shall be called upon to document their understanding of the current situation regarding AS-206(!) flight verification for the GSCP. That is, in order to determine logically what must be done, it is necessary that the GSOP have a thorough and up-to-date knowledge of what has been done.
3. The Flight Software Branch shall direct MIT to deliver AS-206(!) test plans and test results, including analyses, of a quality at least as good as shall be available for AS-258, if you know what that means. This shall include complete documentation of the Level 4 and Level 5 tests and results already accomplished, as well as a complete verifica- tion plan on which acceptance of the final program assembly shall be based. In addition to this, MIT shall prepare a list of all program components which have not been unit tested (Level 2) and will make sure that unit testing which has been performed is completely documented.
4. Since it is anticipated that three of the six rope modules to be used on the AS-206(!) mission will have been manufactured from one pro- gram assembly and the other three from a later, different assembly, MIT shall be directed to prepare a verification plan documenting the manner in which they intend to verify compatibility of the various rope modules with each other.
5. It is intended that the so-called Bit-by-Bit simulation facility at MSC is to play a formal part in the program verifications process. Effort on readying that facility is currently divided between work on the programs required for the AS-206(!) program verification and on those for Apollo 2. Considering the flight schedule, as well as the fact that most of the former should apply to the latter, the Flight Software Branch will revise the priority to the Computation and Analysis Division and their Lockheed contractor such that the AS-206(!) work takes prece- dence in all respects.
6. Recognizing that certain aspects of the total systems verification task is beyond the capability of MIT to perform on their facilities, we have concluded that they must be augmented by including other organiza- tions in this process, It is our proposal that ASPO direct GAEC to pre- pare a verification plan to check out all software/hardware interfaces to assure compatibility. It is recognized that this task and the actual carrying out of the testing itself on the GAEC facilities is beyond their current contractual obligation, which will make changes in that neces- sary.
It is obvious that items 1 and 6, above, are new. However, the need seems equally obvious, and we feel that they should be adopted as a recognized way of doing business for all subsequent flights. Items 2, 4 and 5 are tasks unique for this particular mission in that we are attempting to correct a deficiency. Item 3 is also unique to AS-206(!) in that we must go back and do something which-should have been done much sooner but had been rationalized away in the press of the flight schedule, aa well as a general atmosphere which prevailed previously. Formal test planning and documentation for all program development following AS-206(!) is already well under control.
It is anticipated that slippage in hardware delivery and flight dates will make it possible to carry out this work within a time period that will be acceptable for the development of flight confidence. Although the diversion of MIT effort to carry all this out could and, in fact, will likely impact MIT's delivery of other flight programs, it is anti- cipated that this, too, will be considered satisfactory.
- Aug 08, 1967 – MPAD contractual effort provided FSD for software verification (3.1σ)