Print Story Simulations and D&D
By ana (Wed Aug 16, 2006 at 10:38:13 AM EST) the Space Biz, What I Did with my Summer Vacation (all tags)
Not so very long ago, I told a tale about my involvement in a project that resulted in science being done from a payload attached to the space shuttle.

Last night on the way to dinner, I interrupted a story I was telling toxicfur with "hey, I should write a husi diary about this." So, here we are.

The Idea

Anyway. One has an idea, one searches the various funding agencies (in this case, NASA) for opportunities, since the kind of science we're talking about here has to be done from above the atmosphere. A satellite would be peachy, but those come in rather modest numbers, and, in those days, They had a Solution In Search Of A Problem in the person of the Space Shuttle.

A proposal is written (to be followed over the years by many many more). Peer review happens. A few megabucks change hands. Which is enough to hire a few engineers of that rare breed who are actually willing to talk directly to scientists, and come up with something that [a] works, kinda sorta mostly, and [b] does something interesting to the scientist. But you can't hire that many of them, for that long, so it helps if they also have other projects to work on.


There are several layers of stuff here. The instrument itself is largely built by scientists and grad students; in our case it had flown on a sounding rocket before, as proof of concept. Power supply, control electronics, heaters, motors, interfaces, etc. are built by the engineers. Software for the on board processors (in our case, 4 8086- and 80286-class microchips) is written by people who know what the fuck they're doing, in machine language. I am in awe.

The interface to the shuttle is quite arcane in many ways, and this is true both of the mechanical interface, and the electrical one (power and signals). So the program simplified it quite substantially and we only had to fulfill the program's requirements, not the general shuttle payload reqs (though the program of course included some of those). And of course anything going on a manned (well, and womanned) spacecraft needs to be safe, in the sense that no credible failure, no pair of simultaneous credible failures, can injure anybody even if they're having unnatural relations with the instrument at the time.

So you have instrument hardware, which interfaces with the program's box, which interfaces to the shuttle. Signals go hither and yon and come eventually to the program's ground support equipment (GSE; mostly used of computers) in a room in Maryland (or, in the case of the 2nd program I was involved in, Alabama), where a cable carries the signals to our GSE (redundant pairs of PDP-11 based computers).

Where people sit, looking at incoming telemetry data, thinking, and sending commands. Mostly (but not completely) loading up the stored command buffer on-board.

Ground Mode

Prior to flight, we cut out the middleman and hooked our GSE up pretty much directly to the instrument. We could run tests that way, and in fact clocked many times the hours in this "ground" mode vs. the "flight" mode.

In addition to testing, this also allows for rehearsals. We spent many quality hours doing simulated mission operations. The wetware, after all, takes up the slack for the software, which in turn takes up the slack for the hardware. Things we couldn't afford to or figure out how to do in hardware were done in software. Likewise things we weren't clever enough to do in software we did with people at consoles. Which requires lots of rehearsal time.

After everybody was checked out on basic stuff like plumbing diagrams, syntax of commanding, safety precautions, instrument health precautions, etc. etc., we organized them into teams, each with a job to do, working together to get the instrument commanded and the data stowed for a shift at a time.


And then we started doing simulations. First off, just normal operations, so we'd know what "normal" was. But this is also a great time to work the kinks out of the off-nominal procedures book. So one team leader would put another team through the disaster of the day. The more formal NASA simulations have an engineer or somebody who's the Sim Conductor, who functions very much like the Dungeon Master in Dungeons and Dragons. He tells you what symptoms you're seeing, you tell him what you're doing, he tells you the results. As realistically as possible, even to talking to people in the same room over voice loops (so that, during the actual mission, it can be recorded for later analysis).

It was during one of these in-house sims that I looked up from my team lead position at the sim conductor, and pointed out that he really should have several 20-sided dice at his disposal.

Eventually one gets to mission-level simulations. The astronaut crew has been doing vehicle-related sims for months or years, learning how to fly a complicated gadget. For missions with a lot of crew interaction, it's also important to practice the ground control/flight team interface, so nothing's a surprise come flight time.

A Sea Story

One memorable day we had 60 or more folks in Huntsville, AL from out of town, representing 3 instrument teams, for a mission-level sim. The astronauts were in a shuttle simulator in Houston. The devious sim coordinators had a curve ball to throw... They figured that if they tossed in an engine failure during ascent, it would test the procedures for that for the commander and pilot, and then monkey-wrench payload operations because the finely-tuned schedule depended on the period of the resulting orbit, which would be a minute or two shorter.

But... they spoke a minute or so too soon. The pilot flipped through his charts, and with the help of the launch control crew in Houston, decided an abort landing in Spain was what they had to do, not having enough energy to make orbit on 2 engines.

So the payloads folks sat on our hands for a couple hours while they rehearsed that, went out for a potty break, and recycled to try again.

I think all told that sim ran for about 45 hours. One of the more realistic aspects of that was dragging oneself out of bed at very odd hours, finding breakfast, titrating the caffeine dose, and being alert and ready to slide into a chair somebody else had been keeping warm, right on schedule.

In the event, of course, something more or less unforeseen goes wrong. And the A team, the engineering talent, even though several of them have the flu, have to pull the mission out of the fire in real time.

That, to the extent that it's my story to tell, is the subject for another day.

< Tattoos while you wait. | BBC White season: 'Rivers of Blood' >
Simulations and D&D | 2 comments (2 topical, 0 hidden) | Trackback
R-rated engineering by Kellnerin (2.00 / 0) #1 Wed Aug 16, 2006 at 02:04:23 PM EST
Not the "unnatural relations" bit, I'm talking about the people who "come up with something that ... does something interesting to the scientist." One wonders what the latter something is, and if the scientist enjoys it as much as the former something does.

Was that photo taken with toxicfur's camera phone?

Do not misuse.

um... by ana (2.00 / 0) #2 Wed Aug 16, 2006 at 03:03:19 PM EST
does something of interest to the scientist... zthat better?

And no, the pic was a NASA one. The odd little gadget near the one astronaut's head was our instrument.

Can you introspect out loud? --CRwM

[ Parent ]
Simulations and D&D | 2 comments (2 topical, 0 hidden) | Trackback