Hey, you got simulation in my roleplay! Hey, you got roleplay in my simulation! Wait, it's two great tastes that taste great together!

Thus my students surprised me when they tossed in a role-based stance into what I thought was a straightforward systems engineering analysis. Herein lies the tale.

Background: I'm teaching a course in space mission operations that focuses heavily on scenario analysis. I presented them with a case where they had to balance risk versus success for a space-borne telescope. In rocket science, risk is never something you can eliminate, no matter how much money or resources you toss at it. That's part of what makes it rocket science. Risk can be reduced, mitigated, or even accepted, but never eliminated.

The example was to show that you could boost reliability by accepting more risk, and was based on a historical case called SAC-B + CUBIC. SAC-B was the big mission, and CUBIC was a tag-along. Put simply, the choices were whether to minimize risk to the entire mission (SAC-B) by accepting higher risk of failure for your specific component (CUBIC), or to maximize your own success (CUBIC) at the cost of jeopardizing the entire mission (SAC-B).

I should have realized they'd roleplay it. The question that surprised me was "are we in charge of the entire mission of SAC-B, or are we the CUBIC people?" And they were quite right, as that does make a difference.

If they were in charge of the main SAC-B, then obviously they'd prefer to shunt the risk onto the sub-mission CUBIC. However, if they were that CUBIC sub-mission, their initial stance was "to heck with the primary, let's make them take the risk because we only care about our success or failure!"

From an abstract engineering point of view, that was unexpected. However, that is often how the real world works, a "world revolves around me" pragmatism I found refreshing. And in the process, we had to add components including political concerns and game theory. For example, if you take a hardline "only we matter" stance, will future missions partner with you? Does reputation matter?

In short, by invoking real world concerns, my students turned my cold equations into a roleplay.

Until next month,
Alex

p.s. the short scenario is below, for reference. Permission granted for anyone who wishes to use it in any teaching capacity.

SCENARIO: SAC-B and CUBIC

The US/Argentina solar observatory SAC-B carries the HXRS and GXRE instruments for studying the high energy spectrum of solar flares plus the ISENA instrument for measuring neutral particles.

SAC-B costs $21.5 million.

The Cosmic Unresolved Background Instrument using CCDs (CUBIC) is a secondary payload designed to fit onto the back side of SAC-B (away from the sun) to do spectrographic (not imaging) measurements of the X-ray diffuse background. It is also a technology prototype providing the first testing of X-ray CCDs in space (prior to their use in other more expensive missions). CUBIC cost $2 million to build (and took 4 years of time).

(note: SAC-B did launch on Nov 4, 1996 via Pegasus. Full details are at: http://www2.astro.psu.edu/xray/cubic/index.html)

Situation:

CUBIC is sealed during launch then has to open its 'door' to operate. This door only has to open once. If it opens, CUBIC is a success; if it doesn't open, CUBIC fails. There are 3 methods for opening doors in space: motor, spring, and explosive bolts.

Motors: medium reliability; failure = CUBIC full or partial failure
Spring: medium reliability; failure = CUBIC full failure
Explosive bolts: very reliable; failure = damages entire SAC-B platform.

Discuss whether to use a motor, spring or bolt.

This photo shows the SAC-B satellite on its Ground Support Equipment in a clean room at the OSC facility on Vandenberg Air Force Base, awaiting its attachment to the rocket. The satellite is on its side, with CUBIC on the near side, facing to the left. The solar panels are installed, but are still covered with protective covers. (source: astro.psu.edu)