NASA Investigation Board Report On The INITIAL FLIGHT ANOMALIES OF SKYLAB 1

The management system utilized for the Skylab program was derived directly from that which had been developed and used in the Apollo program. As such, it included a series of formal reviews and certifications at progressive points in the program life cycle that are intended to provide visibility to contractor and NASA management on program status, problems and their resolution.. The selected review points and their primary purpose are set forth in Skylab Program Directive No. 11A, which is summarized as follows:

The primary thrust of these key program milestones is thus a formal review and certification of equipment design or program status; the primary purpose being served is to provide visibility into these matters to senior NASA and contractor program management. As noted in the Skylab Program Directive, the organization and conduct of the review is a major responsibility of a senior program or management official. For each review, specific objectives are to be satisfied, in conformance with preestablished criteria and supported by specified documentation. The reviews are, thus highly structured and formal in nature, with a major emphasis on design details, status of various items and thoroughness of documentation. Several hundred specialists, subsystem engineers and schedule managers are generally in attendance.

The material presented in these reviews is, of course, developed over a period of time in many lower-level reviews and in monthly progress reports dealing with various systems and subsystems. In addition, several other major reviews peculiar to Skylab were conducted, including the following:

There was thus no shortage of reviews. In order to determine the consideration given to the meteoroid shield throughout the program, the Board examined the minutes, presentation material, action items, and close-out of data of each of these reviews and progress reports. In every case, complete records and documentation were available for inspection. In no case did the Board uncover any conflict or inconsistency in the record. All reviews appeared to be in complete conformance to Program Directive 11A and were attended by personnel appropriate to the subject matter under consideration. The system was fully operational.

And yet, a major omission occurred throughout this process - consideration of aerodynamic loads on the meteoroid shield during the launch phase of the mission. Throughout this six.year period of progressive reviews and certifications the principal attention devoted to the meteoroid shield was that of achieving a satisfactory deployment in orbit and containment of the ordnance used to initiate the deployment. As noted in the preceding section on possible failure modes, design attention was also given to the strength of the hinges, trunnion straps and bolts, to the crushing pressures on the frames of the auxiliary tunnel, to flutter and to the venting of both the auxiliary tunnel and the several panels of the shield. But never did the matter of aerodynamic loads on the shield or aeroelastic interactions between the shield and its external pressure environment during launch receive the attention and understanding during the design and review process which in retrospect it deserved.

This omission, serious as it was, is not surprising. From the beginning, a basic design concept and requirement was that the shield be tight to the tank. As clearly stated in much of the early documentation, the meteoroid shield was to be structurally integral with the S-IVB tank - a piece of structure that was well proven in many previous flights. The auxiliary tunnel frames, the controlled torque on the trunnion bolts and the rigging procedure itself were all specifically intended to keep the shield tight against the tank. The question of whether the shield would stay there under the dynamics of flight through the atmosphere was simply not considered in any coordinated manner - at least insofar as the Board could determine by this concentrated investigation.

Possibly contributing to this oversight was the basic view of the meteoroid shield as a piece of structure. Organizationally, responsibility for the meteoroid shield at MDAC-W was established to develop it as one of the several structural subsystems, along with such items as spacecraft structure and penetrations, pressure vessels, scientific airlocks, protective covers and finishes. Neither the government, (MSFC), or the contractor, (MDAC-W), had a full-time subsystem engineer assigned to the meteoroid shield. While it is recognized that one cannot have a full-time engineer on every piece of equipment, it is nonetheless possible that the complex interactions and integration of aero-dynamics, structure, rigging procedures, ordnance, deployment mechanisms, and thermal requirements of the meteoroid shield would have been enhanced by such an arrangement. Clearly, a serious failure of communications among aerodynamics, structures, manufacturing and assembly personnel, and a breakdown of a systems engineering approach to the shield, existed over a considerable period of time. Further, the extensive management review and certification process itself, in its primary purpose of providing visibility of program status to management, did not identify these faults.

Further insight into this treatment of the meteoroid shield as one of several structural subsystems is obtained by a comparison of a listing of the design reviews conducted on both the MS and the SAS. At MDAC-W, the SAS was considered a major subsystem and was placed under the direction of a full-time project engineer. A comparison of the design reviews held jointly between MDAC-W and MSFC on the MS and on the SAS is presented in tables IX-1 and IX-2, respectively. The more concentrated and dedicated treatment received by the SAS is evident in this comparison.

The Board is impressed with the thoroughness, rigor and formalism of the management review system developed by Apollo and used by Skylab. Great discipline is imposed upon everyone by this system and it has served very well. In a large program as geographically dispersed and intrinsically complex as Skylab, such visibility of program status and problems, is a management necessity. We therefore have no wish to alter this management system in any basic manner. But all systems created by man have their potential flaws and inherent hazards. Such inherent flaws and weaknesses must be understood by those who operate the system if it is not to become their master. We therefore wish to identify some of those potential flaws as they have occurred to us in this investigation, not to find fault or to identify a specific cause of this particular flight failure but to use this experience to further strengthen the management processes of large and complex endeavors.

As previously noted the management system developed by NASA for manned space flight places large emphasis on rigor, detail and thoroughness. In hand with this emphasis comes formalism, extensive documentation, and visibility in detail to senior management. While nearly perfect, such a system can submerge the concerned individual and depress the role of the intuitive engineer or analyst. It may not allow full play for the intuitive judgment or past experience of the individual. An emphasis on management systems, can, in itself, serve to separate the people engaged in the program from the real world of hardware. To counteract these potential hazards and flaws, we offer the following suggestions.

• Deployable systems or "structures" that have to move, or that involve other mechanisms, devices, or components in their operation, should not be considered as piece of structure or be the basic responsibility of structures organization.

• A complex, multi-disciplinary system such as the meteoroid shield should possibly have a designated project engineer who is responsible for overseeing all aspects of analysis, design, fabrication, test and assembly.

• Management must always strive to counteract the natural tendency of engineers to believe that a drawing is the real world. First-hand experience with how hardware behaves and can fail is of the essence to design engineers. Possibly, some design engineers should be required to spend time in testing, operations, or failure analysis. Such experience may not contribute to cleverness or sophistication of analysis, but something equally valuable - actual experience may be added to the design group. An unfamiliarity with hardware, first hand, makes it difficult to conceptualize a living, breathing, piece of hardware from an analysis or a drawing.

• The extensive use of the computer for complex analyses can serve to remove the analyst from the real world. One should, therefore, require a simplified or supporting analysis that provides an understandable rationale for the phenomena under consideration before accepting the results of a computer analysis.

• The emphasis on "visibility to management" in the review process should not be extended to the point that one can be led to believe the job is completed, or the design is satisfactory, when such visibility is provided. A major emphasis on status, on design details, or on documentation can detract from a productive examination of "how does it work" or "what do you think."

• Today's organizations seldom include the old-fashioned "chief engineer" who, relatively devoid of administrative or managerial duties, brings his total experience and spends most of his time in the subtle.integration of all elements of the system under his purview. Perhaps we should more actively seek and utilize these talented individuals in an engineering organization.