4 ms·

You might consider reversing the approach - plan in terms of objectives and their dependencies, rather than in terms of sequential procedures and steps. Unix

by dmckeon 14y ago

You might consider reversing the approach - plan in terms of objectives and their dependencies, rather than in terms of sequential procedures and steps. Unix environments have tools like tsort(1) and make(1) which process objective/dependency relationships, and many OS package managers which process dependency chains. (HN readers: no, I am not suggesting to just use Makefiles for spacewalks. :-) ) If you can build up a library of small procedures and dependency relationships among them, then express objectives in terms of a set of procedures, it should be possible (insert hand waving here) to generate (or regenerate) a reasonable sequence (or N parallel sequences) of steps from the underlying hierarchy. Some questions: How does complexity increase when evN > 2? IOW, what is big O(N)? (Yes, you only do 2 EVs now, but no doubt at some point N <= 2 will be become N > 2, and if you code for N then N>2 and N==2 will both be feasible.) If parts of an EV plan must be radically altered during an EVA, how easy/feasible is it to generate a new plan, or do people fall back to other methods (skip/scrap portions of old plan, stop EVA & start over later, etc.)

dfc 14y ago
Is this a joke?
jamesmontalvo3 14y ago
As you said, we only do 2 EVs currently. However, we do have more than two entities working in parallel. For a hypothetical example, during a joint Space Shuttle and ISS EVA, there would be EV1 and EV2, but there might also be the Space Shuttle robotic arm and Space Station robotic arm (each run by at least one crewmember). Also, there may be a crewmember inside coordinating the EVA (reading procedures) who may have some tasks that need to be done to support the EVA, and there is commanding done from mission control. So that's 6 entities. From an EVA planning perspective, we generalize that to three entities: EV1, EV2 and everyone else. That is, we have three columns in our Word document, and steps in the "everyone else" column will specify who is performing them, i.e. "Station Arm: translate to hardware pickup location"
jamesmontalvo3 14y ago
Regarding your question on replanning: On the fly we won't generally have time to completely redo the procedure, and there's a lot of overhead to setup an EVA, so once outside the airlock we'll avoid scrapping the plan entirely and coming back inside unless there's no way to accomplish anything useful. We almost always have extra tasks, which we don't consider part of the nominal procedure. These tasks can be used if for some reason we couldn't do part of the nominal procedure, or if we get the nominal procedure done vastly ahead of schedule and want to use the EVA time we already had book kept. If, say, EV1 is 30 minutes ahead of EV2 and would otherwise just be waiting for EV2, we could send EV1 to do one of these extra tasks. In those cases normally we won't rewrite the procedure in anyway. A voice call will be made to the Flight Director (which everyone in mission control can here) saying something like "After EV1 completes step 45 he will have to wait for EV2 to complete step 56. We estimate that EV1 would be waiting 30 minutes. As such, we suggest he procede to Get-Ahead procedure 'Install Widget' on page 33"
Figs 14y ago
Along the same sort of programmatic thinking, you could try writing the planned activities with a language that supports coroutines (like lua). Each actor can be modelled as a coroutine that is scheduled by a simple dispatch loop. The dispatch loop updates a clock counter, and the actors are written in terms of primitives like wait_for(condition, timeout) and perform_action(description, minimum_time, max_time) which yield in an internal loop based on the clock and some scenario settings. That way, you can test out proposed scenarios (what happens if it takes too long to finish activity X? Can we still finish Y if tool Z breaks? what happens if everyone takes the best timing? worst timing? random timings?).

by dmckeon 14y ago

dfc 14y ago

Is this a joke?

jamesmontalvo3 14y ago

As you said, we only do 2 EVs currently. However, we do have more than two entities working in parallel. For a hypothetical example, during a joint Space Shuttle and ISS EVA, there would be EV1 and EV2, but there might also be the Space Shuttle robotic arm and Space Station robotic arm (each run by at least one crewmember). Also, there may be a crewmember inside coordinating the EVA (reading procedures) who may have some tasks that need to be done to support the EVA, and there is commanding done from mission control. So that's 6 entities. From an EVA planning perspective, we generalize that to three entities: EV1, EV2 and everyone else. That is, we have three columns in our Word document, and steps in the "everyone else" column will specify who is performing them, i.e. "Station Arm: translate to hardware pickup location"

jamesmontalvo3 14y ago

Regarding your question on replanning: On the fly we won't generally have time to completely redo the procedure, and there's a lot of overhead to setup an EVA, so once outside the airlock we'll avoid scrapping the plan entirely and coming back inside unless there's no way to accomplish anything useful. We almost always have extra tasks, which we don't consider part of the nominal procedure. These tasks can be used if for some reason we couldn't do part of the nominal procedure, or if we get the nominal procedure done vastly ahead of schedule and want to use the EVA time we already had book kept. If, say, EV1 is 30 minutes ahead of EV2 and would otherwise just be waiting for EV2, we could send EV1 to do one of these extra tasks. In those cases normally we won't rewrite the procedure in anyway. A voice call will be made to the Flight Director (which everyone in mission control can here) saying something like "After EV1 completes step 45 he will have to wait for EV2 to complete step 56. We estimate that EV1 would be waiting 30 minutes. As such, we suggest he procede to Get-Ahead procedure 'Install Widget' on page 33"

Figs 14y ago

Along the same sort of programmatic thinking, you could try writing the planned activities with a language that supports coroutines (like lua). Each actor can be modelled as a coroutine that is scheduled by a simple dispatch loop. The dispatch loop updates a clock counter, and the actors are written in terms of primitives like wait_for(condition, timeout) and perform_action(description, minimum_time, max_time) which yield in an internal loop based on the clock and some scenario settings. That way, you can test out proposed scenarios (what happens if it takes too long to finish activity X? Can we still finish Y if tool Z breaks? what happens if everyone takes the best timing? worst timing? random timings?).