9. Lesson: Configuration Control Procedures
The phased approach to development should be complemented by a progressively mature control of hardware design. Initially, the hardware design is merely conceptual in nature and may be described parametrically, by equations or design parameters, for example. At this stage, the subsystem designer should have little controls placed upon the details. The designer should be engaged in trade studies, sensitivity analyses, and design variations which will lead to the next phase of hardware control, "base lining the system." This base line permits concentration on a specific design and allows detail design to begin. After a system is base lined, the designer can only change the concept when there is due cause and only after notifying other program elements to assure that each subsystem designer is aware of the design of interfacing subsystems. At CDR (drawing release) the detail design is complete and then formal Configuration Control should be initiated. At this time a rigid process should be established which will ensure that a design modification is only undertaken for understood cause and the full cost, and interface impact is analyzed prior to initiating the change.
Background:
Controlling the configuration too late in the development cycle results in design instability, particularly when systems interact. A seemingly minor change in, say, a reaction control valve could be reflected as a major change in computer software. conversely, the application of controls before the design has been completed, or before trade studies have been made, result in costly modifications.
It can easily be seen that subsystem maturity should be timed so each subsystem is in the same state of development at CDR. When one system is based upon known technology and another interrelated system is advancing the state-of-the-art, initiation of design effort and the level of effort should be adjusted accordingly.
At the time of the failure, project personnel mentioned that the shield "probably was not needed anyway." The Program Director did not ask the next question, namely: why test it then? The proper pursuit of the requirement would have saved the cost of repeating the test and probably would have saved the agony of the Skylab 1 launch failure.
Caution: while a review is beneficial to ensure that program resources are not being expended to fulfull superceded requirements, no requirement should be changed without fully understanding the design implications.
These lessons learned are from SKYLAB LESSONS LEARNED AS APPLICABLE TO A LARGE SPACE STATION, A dissertation submitted to the faculty of The School of Engineering and Architecture Of the Catholic University of America For the Degree Doctor of Engineering by William C. Schneider, Washington, D.C., 1976.
Home - NASA Office of Logic Design
Last Revised:
March 07, 2004
Digital Engineering Institute
Web Grunt:
Richard Katz
