-- Leo's gemini proxy

-- Connecting to thrig.me:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

Apollo Design Considerations


/science/what-made-apollo-a-success.pdf


Why? The large amount of resources flowing into NASA, the clear goal, and the communal action.


Other particular points bear dwelling on; various things were designed for simplicity, so that one person could understand the whole system. Other things were complicated where the operational goal was simplicity:


> The latching device for the crew hatch, (fig. 2-3) illustrates a complex but simply operated mechanism. Although the device contains approximately 400 parts, it allows a crewman, with a single movement of his arm, to open the command module hatch in less than 10 seconds.


This device doubtless received quite a lot of design and testing, though it does point to where complexity, if handled appropriately, can lead to simplicity in some other aspect.


There was redundancy (within the bounds of cost, time, and weight) though some complexity was pushed elsewhere (e.g. to ground support) or ignored as the mission duration and other restrictions did not favor in-flight maintenance. Sure, just pull over and pop the hood.


Passive design and insulation reduced power requirements and maintenance needs. Maybe there could be something to learn from that.


Testing


Theoretically, one does not need to test once something is done with. In practice, tests are required.


> After the spacecraft fire... subcontractors and vendors for 33 Apollo spacecraft assemblies, ... received 79 detailed questions ... This survey reveal the inadequacy of environmental acceptance tests or, in many cases, the nonexistence of acceptance tests.


The document does point out that there can be redundant tests, so it may be good to streamline the workflow to avoid the same test over and over, especially if it's a physical part that too much testing causes damage to that part, or if there are a lot of tests that take too long or use up too many resources. However, "no evidence in the flight-failure history indicates a failure caused by too much testing."


There should be both low-level tests (so that something bad does not get released too early and then causes problems down the line) and high-level tests that check whether the entire thing actually works. Apollo 7 had an anomaly because no integrated systems test had been performed.


The test plan should change as confidence grows in a system.


Bandwidth


> By the advent of the Apollo Program, two high-speed (2.4 kbps) data lines connected each remote site to the Mission Control Center


Smoking!


Documentation


> Preparing the procedural documents instills in the flight controller the capabilities and responsibilities of his position and the methods of using his position most efficiently.


There's an example diagram with "CATASTROPHIC FAILURE?" and "CATASTROPHIC FAILURE IMPENDING?" choices. Fun times!

-- Response ended

-- Page fetched on Wed May 22 01:21:39 2024