# Presentation: 876228

## Session 3A: Design of Goal-based Sequences

- NOTICE: The Adaptable State Based Control System is patented (US 6,745,089) to the California Institute of Technology (Caltech). Should you be interested in implementing and using the system, methods associated with implementing the system, or in obtaining software tools or code to implement the system or method, you should obtain a license from the Office of Technology Transfer at the Caltech. The distribution of this training material does not constitute a license to practice the patent or to use any tools or software code.
- The information contained in this document has been designated by the California Institute of Technology (Caltech) as Technology and Software Publicly Available (TSPA). Copyright 2006. The copyrights and patents related to this technology are owned by Caltech. United States Government sponsorship acknowledged.

## Themes of this Session

- Coordination of control through goal elaborations
- Scheduling & validation of goal networks
- Along the way, we’ll also touch on:
- Resource management (Projection)

## Goal-based Operation

- In the last session, we examined:
- How State Analysis helps us to develop models of the system under control;
- How these models are used in the design of estimation and control software;
- How to define a valid goal.
- Another key feature of State Analysis is its emphasis on ***goal-based closed-loop operation. ***
- In this session, we will discuss the fundamentals of goal-based operation, including:
- How the models are used to ‘elaborate’ high-level specifications of intent into goal-based sequences (a.k.a. goal networks), and
- How the models inform scheduling & validation of these networks.

- Goal and Elaboration Specifications  are Implemented in Software

## Coordinating Control through Goal Elaborations

## Coordinating the Control System

**Control System**

**State variables**

**State variables**

**System**
**Under Control**

**commands**

**measurements**

**Elaboration, projection, & scheduling **

**State variables**

**Intent**

**Knowledge**

**Execution**

**System**
**Under Control**

**state-based model**

- Real systems have many states to be controlled in a coordinated way
**Goal Elaboration** is the first step in coordinating activities of the Control System
- The Model of the System Under Control is the starting point for specifying how goals elaborate...

## Where Do Goals Come From?

**Where Do Goals Come From?**

- Simplest mechanism: Goals are simply asserted
- E.g., issued by the ground controllers, or
- Preloaded as part of “background” goal set capturing flight rules and constraints

## Where Do Goals Come From?

**Where Do Goals Come From?**

- But simply stating a goal does not tell the whole story!
- What about ***implications on other states?***

## Where Do Goals Come From?

**Where Do Goals Come From?**

- Elaboration can be done on the ground or onboard

## What are Goal Elaborations?

- As previously discussed, our model of the system under control captures the *physical cause-and-effect relationships* between state variables.
- Elaborations account for these causal relationships as blocks of goals that can be assembled into plans.
- Elaborations specify supporting goals on related state variables that:
- may be necessary in order to achieve the goal, or
- may simply make the original goal more likely to succeed.
**Elaboration specifications are defined based on the State Effects Model, a small set of rules, engineering judgment, and ...**

- Elaboration Specifications are Implemented in Software

## Rules for Specifying Goal Elaborations

- A goal on a state may elaborate to *control* sub-goals on _directly affecting_ states.
- A control goal on a state may elaborate to a *knowledge* sub-goal on the same state, and vice-versa.
- A knowledge goal on a state may elaborate to knowledge sub-goals on its _directly affecting and affected_ states.
- A “maintenance”-type goal on a state may elaborate to a “transition”-type goal on the same state, with an ending time point coincident with the starting time point of the “maintenance”-type goal.
- A goal’s elaboration may include temporal constraints to reserve time in the schedule for actions required by the goal.

## Applying the Rules

**Camera Power:****is On**

***Legend*****:**

**min to max**

**temporal constraint**

**time point**

**goal**

**common****time point**

**State****Effects****Diagram**

**Camera****Power****Switch**

**Camera****Power**

**Rule Reminders:**
**Directly affecting states**
**Knowledge/control of same state**
**Knowledge of affecting/affected**
**Transition / Maintenance**
**Temporal constraints**

## Applying the Rules

**Applying the Rules**

**Wheel Steering Angle:**** is known with ******** ≤ 0.5o**

**Steering Motor Mode & Health:****state is known with high certainty**

- Rule #3

**State****Effects****Diagram**

**Steering **
**Motor Mode**
**& Health**

**Wheel****Steering****Angle**

**Wheel Steering Angle:**** is transitioning to ****known with ******** ≤ 0.5o**

- Rule #4

**Rule Reminders:**
**Directly affecting states**
**Knowledge/control of same state**
**Knowledge of affecting/affected**
**Transition / Maintenance**
**Temporal constraints**

## Applying the Rules

**Applying the Rules**

**Wheel Steering Angle:**** is transitioning to ****known with ******** ≤ 0.5o**

**Steering Motor Mode & Health:****state is known with high certainty**

- Rule #3

**State****Effects****Diagram**

**Steering **
**Motor Mode**
**& Health**

**Wheel****Steering****Angle**

- Rule #5

**0 to 1 min**

**Wheel Steering Angle:****is turning right until stop**

- Rule #2

**Rule Reminders:**
**Directly affecting states**
**Knowledge/control of same state**
**Knowledge of affecting/affected**
**Transition / Maintenance**
**Temporal constraints**

## Alternate Tactics

- Different ways of accomplishing a goal can be defined as alternate*** elaboration tactics:***
- Selection of an appropriate tactic may be based on assigned priorities or other mechanisms*.

**Thruster Inlet Flow:****is Flowing**

**Thruster Inlet Flow:****is Flowing**

**Valve A:****is Closed**

**Valve B:****is Open**

**Thruster Inlet Flow :****is known with high certainty**

**Valve A:**** is Open**

**Valve B:****is Closed**

**Thruster Inlet Flow :****is known with high certainty**

- * e.g., conditioned on state information – to be discussed in a later session...

**A**

**B**

- Tactics are Implemented in Software

## Goal Elaboration 

**Goal Elaboration **

- Goal elaborations are defined locally for each goal
- Goal elaboration is a recursive process
- Elaborate parent goal, then child goal(s), then grandchild goal(s), etc.

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**Etc...**

**0 to 10 sec**

**1 to 2 hours**

## Goal Network 

- The resulting collection of interconnected goals is called a *goal network*

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

## Goal-based Macros 

- Goal networks are defined by systems engineers
- Specify operational scenarios* constructed from:
- individual high-level goals, or
- carefully-crafted “sequences” of high-level goals on one or more state variables, also known as *goal-based macros*.
- Goal-based macros are similar to elaborations, except that they assemble goals on state variables that may be unrelated in the State Effects Model.
- Unlike regular goals, Goal-based macros are not associated with a particular state variable
**Defining goal-based macros is part of the State Analysis process**

- * Goal networks also include “background” goals that implement flight rules and constraints that need to be enforced

- GBMs are Implemented in Software

## Goal-based Macro Example

**Drive-Turn-Drive Macro (x1,y1,********,x2,y2,d)**

**We can define a goal-based macro for a common activity like “Drive to a specified location, turn in place, then drive to another specified location”.**

**Each child goal in the macro elaboration would be elaborated, as usual.**

**We might define this goal-based macro’s “elaboration” as follows...**

## Benefits of Goal-based Macros

- Each goal-based macro “encapsulates” otherwise unrelated goals that combine to perform an activity
- Activities retain separate identities, and can be invoked via the macro
- Can be added or removed (along with their offspring) from the goal network as conditions warrant
- No additional mechanisms needed (macro behaves just like an elaboration)
- Defining macros enables reuse, and facilitates monitoring of high-level activities

## Recap: Goal Elaboration 

- Systems engineers define goal elaboration specifications
- Software Engineers implement these specifications.
- These specifications serve as inputs to the scheduling process
- Elaboration creates:
- New subgoals (goals obligated to the original goal)
- New time points to attach them to (if necessary)
- New temporal constraints (if necessary)
- Elaborations are recursive
- If A affects B and B affects C, and A and B are controllable states, then controlling C implies a need to control B, and controlling B implies a need to control A
- Elaborations are like sequence block expansions, with an important distinction:
- The elaborated goal is not replaced by the goals in its elaboration
- Rather, these goals are added to the plan along with the elaborated goal
- Original intent of the expansion is not lost

**A**

**B**

**C**

*affects*

*affects*

- Elaboration is guided by the State Effects Model

## Elaboration Options

- Systems engineers specify the scope of elaboration options during State Analysis
- Simple elaborations may offer no options at all
- Fixed expansion (usually very simple — just a few invariant subgoals)
- Modestly more complex elaborations can invoke multiple “tactics” (elaboration options)
- An elaborator may “choose” its Tactic based upon several criteria
- Try in order, one at a time, or
- Select based on goal parameters, or
- Select based on observed system state, or
- Invoke safing (more on this later...), or
- Combinations of the above (basically, apply simple expansion procedures)
- In the extreme, could envision elaborations that apply complex reasoning
- Deduce appropriate elaborations, given models of behavior
- Search for a suitable plans to solve a problem
- Etc.

## Scheduling and Validatingthe Goal Network

## Goal-based Sequencing

**Goal-based Sequencing**

- Once the necessary set of elaborations has been defined as part of the State Analysis process, they can be encoded into ground and flight software
- This enables sequence designers to **specify desired behavior in terms of high-level goals (or macros)**
- A planner/scheduler* can then:
*Elaborate* these goals into the set of appropriate supporting goals
*Integrate* these elaborated goals into the current goal network, which includes all background goals (from flight rules & constraints) and all previously-scheduled activities
*Schedule* the augmented goal network to satisfy all temporal constraints, eliminate any conflicts, and verify consistency

*** This can be a human, scheduling activities by hand, or ****an automated software system, or a combination of both!  The automated software system can be on the ground, onboard, or a combination of both!**

## Coordinating the Control System

**Control System**

**State variables**

**State variables**

**System**
**Under Control**

**commands**

**measurements**

**Elaboration, projection, & scheduling **

**State variables**

**Intent**

**Knowledge**

**Execution**

**System**
**Under Control**

**state-based model**

- Goal networks specify the intent used to coordinate the actions of the Control System
- To ensure that intent is specified correctly, the goal network resulting from elaboration of operator-specified goals must be **scheduled.**
- The Model of the System Under Control guides the specification of the logic used in scheduling...

## Intent Time Lines

- Can think of a goal network as a set of *intent time lines*, one for each state variable in the system under control

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

## Intent Time Lines

- Can think of a goal network as a set of *intent time lines*, one for each state variable in the system under control

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

## Intent Time Lines

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

***Legend*****:**

**min to max**

**timepoint**

**goal**

**x-goal**

**common****timepoint**

**Camera Power Switch:****is Closed**

**Camera Power:**** is known and On**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:**** is known and transitioning to On**

**Intent Time Lines**

**Original Goal Net**

- CameraPower

- CameraPowerSwitch

**temporal****constraint**

**Framework**

**Adaptation**

## Intent Time Lines

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

***Legend*****:**

**min to max**

**timepoint**

**goal**

**x-goal**

**common****timepoint**

**Camera Power Switch:****is Closed**

**Camera Power:**** is known and On**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:**** is known and transitioning to On**

**Intent Time Lines**

**Original Goal Net**

- CameraPower

- CameraPowerSwitch

- We use the term “executable goal”, or ***x-goal***, to refer to the post-merged, as-scheduled constraints on the intent timelines

**temporal****constraint**

**Framework**

**Adaptation**

## Intent Time Lines

**Camera Power:****is On**

**Camera Power Switch:****is Closed**

**Camera Power:****is known**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:****is known**

**Camera Power:****is transitioning to On**

**0 to 10 sec**

**1 to 2 hours**

***Legend*****:**

**min to max**

**timepoint**

**goal**

**x-goal**

**common****timepoint**

**Camera Power Switch:****is Closed**

**Camera Power:**** is known and On**

**Camera Power Switch:****is transitioning to Closed**

**Camera Power:**** is known and transitioning to On**

**Intent Time Lines**

**Original Goal Net**

- CameraPower

- CameraPowerSwitch

- We use the term “executable goal”, or ***x-goal***, to refer to the post-merged, as-scheduled constraints on the intent timelines

**temporal****constraint**

***x-goals ***are implemented in the framework and instantiated by the Scheduler.

**Framework**

**Adaptation**

## Scheduling Guided by Models

- Though the computation-intensive aspects of scheduling may happen in software, systems engineers still need to specify the logic that the scheduler will use to:
- Check that each goal in the network is achievable
- Check that each consecutive pair of goals on an intent time line are compatible
- Check whether concurrent goals on the same state variable are compatible and, if so, what it means to achieve them concurrently
- In keeping with our model-based engineering philosophy, our models help us to specify this logic.

- Software engineers encode this logic in the software.

## Checking Goal Validity

- Can the controller and estimator achieve this state constraint?

**Camera Temperature:****between 10 and 20 oC**

**True**

**isAchievable?**

**Camera Temperature:****between 10 and 10.05 oC**

**False****(beyond the capability****of the temp. controller)**

**isAchievable?**

## Checking Transition Consistency

- Can the controller and estimator achieve both of these state constraints back to back?

**Camera Temperature:****between 10 and 20 oC**

**Camera Temperature:**** transition to between 10 and 20 oC**

- True

**Is Transition****Achievable?**

**Consecutive x-goals on time line**

**Camera Temperature:****between 10 and 20 oC**

**Camera Temperature:****between 5 and 25 oC**

- False

## Merging Concurrent Goals

- The merged constraint, or *x-goal*, is what needs to be achieved, in order to fully satisfy intent (all concurrent goals)

- Controlling both ofthese simultaneously...

**NOTE: just because we’ve merged these two goals doesn’t mean that we throw them away – they remain in the goal network so we can monitor them individually during execution.**

**Merging Concurrent Goals**

**merge**

**Camera Temperature:****between 10 and 20 oC**

**Camera Temperature:****between 15 and 25 oC**

**Camera Temperature:****between 15 and 20 oC**

## Merging Partially Overlapping Goals

**Camera Temperature:****between 10 and 20 oC**

**E**

**1 hour**

**2 hours**

**3 hours**

**4 hours**

**Camera Temperature:****between 15 and 25 oC**

- X-goals are the product of merging all compatible concurrent constraints over a time interval

## Merging Partially Overlapping Goals

**Camera Temperature:****between 10 and 20 oC**

**E**

**1 hour**

**2 hours**

**3 hours**

**4 hours**

- Note that this transition is not achievable, and would presumably be caught by the transition consistency logic discussed previously...

**Camera Temperature:****between 15 and 25 oC**

## Merging Partially Overlapping Goals

**Camera Temperature:****between 10 and 20 oC**

**E**

**1 hour**

**2 hours**

**3 hours**

**4 hours**

- However, elaboration would presumably introduce an appropriate transition goal that would prevent this problem from occurring...

**Camera Temperature:****between 15 and 25 oC**

## Merging Partially Overlapping Goals

**Camera Temperature:****between 10 and 20 oC**

**E**

**1 hour**

**2 hours**

**3 hours**

**4 hours**

**Camera Temp:****transitioning to****betw. 15 and 25 oC**

**0.5 hour**

**Camera Temperature:****between 15 and 25 oC**

## Scheduling Example (Before Scheduling)

**Camera Temperature:****between 10 and 20 oC**

**Heater Switch & Health:****healthy and switching between on and off**

**Camera Temperature:****transition to between ****10 and 20 oC**

**Heater Switch & Health:**** healthy and switching between on and off**

*Elaboration 1*

*Elaboration 2*

**e**

**0 to 3 hrs**

**Heater Switch & Health:**** healthy and off**

**e**

**0 to 2 hrs**

**e**

****

**0 to 30 mins**

**Camera Temperature:****between 15 and 25 oC**

**1 hr**

- Flight Rule

## Scheduling Example (Scheduling)

**Camera Temperature:****between 10 and 20 oC**

**Heater Switch & Health:****healthy and switching between on and off**

**Camera Temperature:****transition to between ****10 and 20 oC**

**Heater Switch & Health:**** healthy and switching between on and off**

*Elaboration 1*

*Elaboration 2*

**e**

**0 to 3 hrs**

**Heater Switch & Health:**** healthy and off**

**e**

**0 to 2 hrs**

**e**

****

**0 to 30 mins**

**Camera Temperature:****between 15 and 25 oC**

**1 hr**

**≥****0**

- The framework does this.

## Scheduling Example (After Scheduling)

**Camera Temp.**

**Heater****Switch & Health**

**e**

**e**

**e**

****

**Camera Temperature:****betw. 15 & 20****degrees C**

**Camera Temperature:****betw. 15 & 25 degrees C and transitioning to betw.15 & 20 degrees C**

**Heater Switch & Health:****healthy and switching between on and off**

**Heater Switch & Health:**** healthy and switching between on and off**

**Camera Temp:****betw. ****15 & 25****degrees C**

**e**

**e**

****

****

**Camera Temp:****betw. 15 & 25****degrees C**

**Unconstrained**

**Heater Switch & Health:**** healthy and off**

**0 to 2 hrs**

**0 to 30 mins**

*Elaboration 1*

*Elaboration 2*

**1 hr**

**Camera Temperature:****between 10 and 20 oC**

**Heater Switch & Health:****healthy and switching between on and off**

**Camera Temperature:****transition to between ****10 and 20 oC**

**Heater Switch & Health:**** healthy and switching between on and off**

**Heater Switch & Health:**** healthy and off**

**Camera Temperature:****between 15 and 25 oC**

**0 to 3 hrs**

**0 to 2 hrs**

**0 to 30 mins**

**1 hr**

## Mutual Exclusion

- Consider a scheduled goal network that includes a goal on Camera Pointing, in support of an OpNav activity:
- Now, if we try to schedule a science activity that applies the following goal on Camera Pointing:
- The scheduler will try to merge them and discover that it is unable to do so.
**Goal merging thus provides a mechanism for resource management via mutual exclusion.**

**Camera Pointing****toward reference stars**

**E**

**1 hour**

**10 mins**

**Camera Pointing****toward science target**

**E**

**1 hour**

**30 mins**

## Using Models to Anticipate Problems

**Camera****Heater**

**Using Models to Anticipate Problems**

**Heater Model**

- COLD

- Hot

- Off

- Failed

- ON

- OFF

- Poof

**Heater O****N****/O****FF**
**commands**

**H****OT****/C****OLD**** ****“current”**
**measurements**

**Switch****Command**

**Heater****Command**

|  | Open | Close |
| --- | --- | --- |
| Opened(No cmds sent to heater) | Opened
(no change) | Closed |
| Closed
(Cmds sent to heater) | Opened | Closed
(no change) |
| Tripped(No cmds sent to heater) | Opened
(reset) | Tripped
(no change) |
| Stuck-open
(No cmds sent to heater) | Stuck-open | Stuck-open |
| Stuck-closed
(Cmds sent to heater) | Stuck-closed | Stuck-closed |

*Switch command*

*Switch**State*

**Switch Model**

- Let’s again consider our heater/switch example:

## Using Models to Anticipate Problems

- Let’s assume that, at the end of the last sol, an onboard heater switch was diagnosed “Stuck-Open”:
- From our model, we know that the “Stuck-Open” fault mode is permanent, so it doesn’t make sense to plan a future goal that specifies that the switch be closed!

- Estimate from the end of sol 371: *Switch is Stuck-Open*

**Heater****Switch**

**Switch is Closed**

- Proposed plan for next sol:

**E**

**Start of sol 372**

## Projecting State

- Somehow, we need a scheduling mechanism that takes information about the current state and uses the model to anticipate potential future problems in our plan.
**This mechanism is called *****projection.***

**Heater****Switch**

**Switch is Closed**

- Proposed plan for next sol:

**E**

**Start of sol 372**

**Heater****Switch**

- Projected state for next sol:

**E**

**Start of sol 372**

**Switch is Stuck-Open**

**...**

**Conflict! This goal is****not achievable.**

## Projection Definition

- Projection is the prediction of future State, in the context of the current plan.
- What will happen if the plan is attempted?
- The projection can be compared against the plan to check the plan for feasibility with the latest estimated state and the model.
- Will the plan achieve the desired result?
- Among other things, Projection is the most general MDS solution to the problem of resource modeling and resource management.

## Power Example

- State Effects
- Resource: Power Margin
- Users: camera, heater
- Source: solar array
- For any plan involving these State Variables...we want to compare intended state to predicted state.
- Projection is how we get the State Effects model into the software so we can make that comparison...

## Power Example

**Power Margin**

- Power

- Slide From Matthew Bennett

## Predict Resource Violation

- A State Variable (Power Margin) determines its projected state by applying its projection model to...
- the commanded Goals
- the current estimate (State Value)
- the projected state of State Variables which affect it
- The plan is valid if the projected state does not violate the desired state.
- The desired state is a combination of the commanded Goals and ever-present “flight rule” Goals.

## Predict Resource Violation

- A State Variable (Power Margin) determines its projected state by applying its projection model to...
- the commanded Goals
- the current estimate (State Value)
- the projected state of State Variables which affect it
- The plan is valid if the projected state does not violate the desired state.
- The desired state is a combination of the commanded Goals and ever-present “flight rule” Goals.

- The projected state should be specified in a format consistent with the State Value.

## Projection Types

- Depending upon the nature of the State Variable, Projection may be accomplished in several different ways.
**Local** – Depends only on the current XGoal
- Example: Instantaneously commandable state variables, that never fail, and have no affecting state variables  (e.g. an ideal power switch)
**Serial** – May depend on the current state value, current and immediately preceding XGoals, and projections for affecting state variables
- Example: Health or Power Margin
**Global** – Like serial, and may depend on later XGoals and their temporal constraints.
- Example: state variables whose affecting state variables’ effects are integrated over time (e.g. Battery State of Charge)

## Recap: Scheduling

- Critical step in sequence generation and validation
- Ground operators specify desired behavior in terms of goals on state variables of interest (or macro)
- These goals are elaborated into appropriate supporting goals (either by hand or by software automatically)
- Elaborated goals are added into current goal network
- The goal network is scheduled (automated in software):
- Add appropriate temporal constraints to ensure concurrent goals are consistent (no conflicts)
- Merge goals into executable goals (a.k.a. *x-goals*) on timelines
- Project state according to state constraints & state effects model *(more on this later)*
- Check consistency of resulting x-goal time lines

- The scheduling process is informed by our models

- The scheduling software is informed by our representation of those models in software.

## Goal Net Flexibility

- Amount of flexibility in goal network is “tunable”...
- From fully constrained:
- Ground planning results (e.g., timing) can be imposed as additional constraints in the original goal network
- Fully elaborated and scheduled goal network is sent to the spacecraft for execution
- To minimally constrained:
- Only essential ordering is specified
- Elaboration of all goals is completed on board
- With options in between, such as:
- Fully constraining key activities, while leaving others free
- Elaborating to mid-level goals, but leave details to be completed on board, and so on

- Various options may be exercised during operations, over the lifetime of the mission

## Summary: Goal-based Sequencing

**Summary: Goal-based Sequencing**

- Elaboration is a model-driven sequence expansion process
- More nested than typical blocks
- Goals may expand into additional supporting sub-goals
- Each expansion is as narrow as possible
- All information about dependencies is preserved
- Expansion may be conditioned on state
- Expanded goals are integrated with the rest of the sequence
- Goal merging is a supported operation accomplished by a scheduler
- Overlap is accommodated
- Goal-based macros specify subnets of “high-level” goals
- Goal-based macros are elaborated like other goals
- Activities retain separate identities
- Can be added or removed as conditions warrant
- Any macro (and its offspring) can be cancelled
- The logic needed for scheduling the sequence needs to be provided as a product of State Analysis, based on models
- A scheduled sequence is a validated sequence

## Software Engineering Checklist

- Implement the elaboration hierarchy of Goals.
- Implement the logic by which a Goal chooses a Tactic.
- Implement the logic by which the Scheduler derives a valid event timeline for each State Variable.
- Implement the logic by which the Scheduler determines the future (projected) state of each State Variable.

## State Analysis Checklist

- As part of the State Analysis, systems engineers must specify:
- Goal elaborations based on the state effects models, including alternative tactics where appropriate
- Goal-based macros for common high-level activities
- Achievability logic for executable goals
- Transition rules for legal sequential operations
- Merge rules for legal simultaneous operations
- Projection rules based on models