NASA Logo, National Aeronautics and Space Administration

EXEC In Action

              <img src="/m/project/remote-agent/images/psbig.png" alt="Cartoon" style="float: left;" height="172" width="200">
                <strong>Here is an authentic example which illustrates how EXEC works.</strong>
                To refresh your memory, during its mission, DS1 performs a task called Autonomous Optical 
                Navigation (OpNav) to determine its position in space.  One task in this activity involves
                taking pictures of several asteroids using DS1's Miniature Integrated Camera and 
                Spectrometer (MICAS). Planner/Scheduler (PS) generates a plan describing how this is to 
                be accomplished. EXEC's job is to execute the plan and recover from any faults that 
                interfere with the execution. Let's see how EXEC does it.
              <h2>Executing the Plan</h2>
              <h3>Getting the Plan</h3>
                First EXEC must obtain the plan for a certain period of time from PS.  EXEC's request for 
                a new plan is part of the previous plan.  The plan comes in the form of timelines, filled 
                with "tokens".  A token is just a behavior or action in the plan.  There is a separate 
                timeline for each category of tasks. (See PS section for more details.)  The diagram below
                illustrates four of the timelines for a given plan period or "schedule horizon."  The 
                original goal that these timelines are based upon is an OpNav activity.  
                Note:  these timelines only represent the last 20 hours of a possible plan that would be 
                developed by the PS during the Remote Agent Experiment.
              <img src="/m/project/remote-agent/images/diagram5.png" alt="Last 20 Hours of the Planning Horizon" height="265" width="490">
              <h3>Decomposing the Plan</h3>
                The tokens in the plan need to be "decomposed" or broken down into smaller more specific 
                tasks.  For example, the first token is to turn MICAS on.  Many things must happen in 
                order for this to occur.  EXEC must check that MICAS electronics are on, that the power 
                distribution unit is feeding MICAS power, and that the MICAS switch is healthy,  in 
                addition to turning the switch to the "on " position.  EXEC uses its knowledge of the
                status of the spacecraft to decide which actions are necessary.  For example, if MICAS is 
                already on, it doesn't send the command to the switch to go to the "on" position.
                Sometimes, there is more than one way to decompose a particular token.  EXEC uses 
                information on the status of the spacecraft and what resources are available when deciding
                the most efficient method.  For example, there are two amplifiers for the communications 
                system.  If one amplifier is already on or if one has a problem, EXEC will take that 
                information into account when deciding which amplifier to use.
              <h3>Commanding an Action</h3>
                For each token in the plan, or the tasks resulting from decomposing the token, EXEC 
                commands the relevant spacecraft component to act.  For example, in the plan above, the
                first token on the MICAS mode timeline is "MICAS turning on".  EXEC's job is to send a 
                command to the MICAS system to turn the switch to the "on" position. 
              <h3>Determining Token Initiation Times</h3>
                Sometimes, certain things must occur before a token can be completed.  For example, 
                before MICAS can take a picture, it must be turned on and in the "ready" mode and the 
                attitude control system must not be turning.  EXEC makes sure all such preconditions are 
                met before commanding the action.  To be as time efficient as possible, EXEC will send 
                the command for an action as soon as all the preconditions are met, so the plan moves 
                along quickly and no time is wasted.
              <h2>Failure Recovery</h2>
              <h3>Monitoring Execution</h3>
                While EXEC is executing the plan, it is also monitoring the completion of the tasks it has
                commanded.  One method it uses to monitor task completion is direct feedback from the 
                system involved.  For example, if EXEC commands MICAS to take a set of pictures, the MICAS
                software will let EXEC know when it has received an image that MICAS took.  If EXEC does 
                not receive this information in a reasonable amount of time, it will know that something 
                is wrong.
                A second method it uses to monitor task completion is a constant flow of updated 
                information from the Mode Identification and Recovery (MIR) component of Remote Agent, 
                regarding the status of the spacecraft components.  For example, if EXEC commanded MICAS 
                to turn on, it should receive information from MIR that MICAS's switch is in the "on" 
                position soon after issuing the command.
              <h3>Recovering from a Fault</h3>
                If EXEC commanded MICAS to take a picture and it doesn't get feedback that the picture has
                been taken in a reasonable amount of time, it will assume that something is wrong.  EXEC 
                addresses this problem by requesting that MICAS try again.  After four tries, EXEC will 
                abort the plan and go into standby mode, which means it stops all activities and wait for 
                instructions from the ground.
                If MIR reports to the EXEC that there is a failure with one of the components, for example
                MICAS switch is stuck in the "off" position when it should be in the "on" position, EXEC 
                will ask MIR to recommend a recovery action that EXEC will then execute.  If a failure is 
                permanent, EXEC will try to find a way to carry out the plan without the use of the failed
                component.  If the plan cannot be executed under the current conditions, EXEC will 
                request that the PS produce a new plan, taking into account the new status of the 
                Finally, there are some failures that are so serious, that EXEC doesn't even take the time
                to ask for a recovery action from MIR.  An example of this type of failure is lack of 
                power.  If MIR reports a significant lack of power, EXEC will go directly into standby 
                mode and waits for instructions from ground control.
First Gov logo
NASA Logo -