"Is 'Peckerhead' Hyphenated?" Building the International Space Station

Vicent Cordoba

At this point in the story, I will assume that most readers have developed some appreciation, and maybe even a mild distaste, for the detracting environment in which we engineers had to maintain focus on the fundamental goal of the project - which was to build a space station.

The technical challenge was no cruise in the Caribbean. The vehicle was supposed to sustain human life in the harsh, unforgiving environment of space. It was supposed to snap together, piece by piece, in space, like a very big and very sophisticated LEGO toy. There were millions of parts, built by different contractors, all supposed to fit and work together without any problems.

Different people, tied down by their own, different experiences, had different ideas about how to do things. People often quit the project before completing whatever it was they were supposed to be defining, designing, building or integrating, leaving the inheritors to figure things out for themselves. And, on top of all that, the lack of clear, stable and timely requirements only increased the number of possible design solutions, which led to change after change and worsened the ever-present schedule pressure.

One classic conundrum that haunted us, the design engineers, as we tried to design our flight systems was trying to find a balanced solution somewhere between what the users (the ground controllers and the crew) wanted - which was basically everything (total control, total data, all the time) - and what the system could do within the limitations of the components and the philosophy of keeping things simple to reduce the risk of things going wrong. Debates about this went on all the time, and no one was ever satisfied. The users wanted more. The engineers who had to build it (on schedule) wanted less.

Tim O'Reilly was a conscientious fellow who began working on the project while in his early thirties. Within a few years of working hard only to know more frustration than accomplishment, he was transformed into a grumpy and tired old man in his mid-to-late thirties. He was a thoughtful engineer (smart, as opposed to prone to making kind remarks to others) who listened to opposing viewpoints but did not have much patience with unreasonable people.

During one exhausting and unproductive technical meeting, the number of safety features
(hazard-preventing interlocks, inhibits, backups, etc.) to be included in the design had been discussed to death. There comes a point where one has to stop adding 'safety' features [which, it can be argued, may actually decrease safety because they add complexity] to the design because the what-if-the-Nth-line-of-defense-fails argument can go on forever without reaching absolute certainty. With a reasonable agreement close at hand, someone representing the ground operations people still insisted that additional 'command inhibits' (extra steps which prevent inadvertent or unauthorized commanding by requiring two actions to take place before the function is performed) be built in. Tim O'Reilly had had enough and snapped back at the guy:

"If an astronaut forgets to put his helmet on before he opens the airlock,...Darwin works!"

Later, in that same meeting, the same disgruntled proponent of more safety features was trying a different approach by shifting the technical discussion into the realm of the English language, the requirements and the letter of the law. He was arguing that his scenario qualified as a credible 'hazard', as defined by the Space Station program, which opened the door for the inclusion of those additional, redundant safety features he wanted. Tim O'Reilly made known what he thought about that:

"If you use that [the Station program's] definition of 'hazard' in your house, you couldn't plug in an iron [without inhibits] 'cause it could be sitting on your head when you plug it in."

Most people agreed. Tim O'Reilly: 2. Other guy: 0.

I'd like to end this tale about command inhibits with the right perspective, if only to tease Endora Broome a bit. As I already pointed out, Endora was a dedicated engineer who strongly believed that a good, safe design required inhibits all over the place and resorted to her hypnosis-assisted charm to successfully convince others (mostly older men) and get them (the inhibits) into the design. The basic idea of command inhibits is to prevent a given command from being able to execute by 'inhibiting' (disabling) it. The inhibit must be removed before that command can be executed. Inhibits are applied and removed by other commands - which can, themselves, be inhibited. Woody Nelson, one of the most technically proficient engineers I ever worked with, once asked:

"What happens when somebody command inhibits the command inhibit command?!"

Since useful, detailed control system requirements were unavailable in the early years of the program, we, the design engineers, had to make decisions whether or not to include certain capabilities such as inhibits. Jose Cabesagrande explained this to Bud Hellcat during a C&C Mode Team telecon:

"The low-risk option was to put it [an inhibit] in there and make the inhibits inhibitable."

The war between the 'Safety Community' (which is what the inhibit seekers called themselves) and the design engineers went on regardless of individual skirmishes won or lost here and there. I do not exaggerate when I say that the Safety guys were still arguing over the definitions of 'hazard' and 'catastrophic' well after the hardware and software was running - safely - in the labs. No real engineer I ever worked with ever ignored safety (the concept). Real safety is a very serious business. It would be less than truthful, however, to pretend that the Safety Community (the cult) were respected by all. Skip Vroomberg summed up his personal view of their value to the program this way:

"The Safety guys are just a bunch of sheep running around saying, 'I'm scared!'."

Enough about the Safety people. Plenty of other interesting technical specialists and "experts" adorned the program. There were system/hardware/software design engineers, mechanical engineers, thermal/thermodynamics experts, electrical and electronic engineers, electromagnetic interference experts, computer systems and communications experts, software programmers, simulation developers, test engineers (lab rats), manufacturing people, parts and logistics people, and, barely rounding out the rear fringe of the technical domain for completeness, masters of paperwork, briefing charts, government standards and procedures, rules and regulations, processes and process development.