# Presentation: 765821

## Session 4 Robust Execution and Fault Management

- 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

- System robustness and fault protection
- Critical sequence development and execution
- Reactive vs. deliberative coordinated control
- Along the way, we’ll also touch on:
- Hierarchical control patterns
- “Virtual” devices

## System with Ground & Flight Deployments

- Goal-based sequence

- Telemetry

*Ground deployment(s)*

*Flight deployment*

**Sequence execution**

**Execution monitoring**

**Strategic planning**
**Tactical sequencing**
**Sequence validation**

- Recall from an earlier session:

- In the last session, we discussed ***ground-based monitoring*** of nominal execution scenarios...

## Off-nominal Behavior

- The ground-based monitoring scheme we discussed is adequate in the (unrealistic) case of nominal execution(no faults or unexpected occurrences, everything proceeds as planned).
- But what if something goes wrong?
- Or “nominal” behavior strays out of expected bounds due to inaccurate modeling?
- Communication delays generally preclude ground-in-the-loop response.

## System with Ground & Flight Deployments

- Goal-based sequence

- Telemetry

*Ground deployment(s)*

*Flight deployment*

**Critical & non-critical sequence execution**
**Onboard execution monitoring**
**Fault management**

**Execution monitoring**

**Strategic planning**
**Tactical sequencing**
**Sequence validation**

- In this session we consider:

## Fault Protection

- Traditionally, spacecraft have included *Fault Protection*, which is generally implemented in various forms:
- Localized reactive FP behavior, typically done without impacting the sequence, e.g.:
- transient recovery
- automatic retries
- degraded operation
- switch-over to redundant components
- etc.
- System-level FP that takes control ofthe spacecraft under serious off-nominalcircumstances
- Handles faults with broad implications, e.g., power under-voltage, attitude loss, command loss
- Includes irresolvable command execution errors
- Involves system-wide response, e.g., safing

## Goal-based Fault Management

- In this session, we discuss a FP design that is:
- More tightly integrated, using the same goal-based mechanisms as nominal sequence execution
- More flexible, offering a selectable spectrum of responses, depending on the severity of the problem
- Potentially more robust, due to the inherent closed-loop nature of goals and the improved traceability of software to fault models

**Control System**

**State variables**

**State variables**

**Elaboration, projection, & scheduling **

**State variables**

**Intent**

**Knowledge**

**Control System**

**State variables**

**State variables**

**System**
**Under Control**

**commands**

**measurements**

**State variables**

**Execution**

**Downlink**

**Uplink**

**Ground**

**Flight**

**Elaboration, projection, & scheduling **

**Intent**

**Knowledge**

## Fault Diagnosis

## Modeling Off-nominal Behavior

- The first challenge for FP is being able to recognize that something is wrong in the first place, and to ***diagnose*** the cause of the problem.
- Providing the ability to do this is one of the more difficult, time-consuming, and expensive aspects of systems and software engineering.
- KEY STEP: ***adequately*** model the off-nominal behavior of the system under control.
- Traditionally, this effort is done through FMEAs, Fault Tree Analyses, etc, and is generally performed later in the project lifecycle
- Experience has shown that fault protection design/development/validation often uncovers problems in the underlying architecture and nominal design.
- This results in unnecessary iteration.
- In State Analysis, nominal and off-nominal states are given equal stature in the model
- State Analysis provides the opportunity for (but does not obligate) earlier consideration of faults and off-nominal behavior.
- Although this pushes some effort earlier, as compared to the traditional engineering lifecycle, it results in ***earlier risk identification****, ****greater opportunity for thorough mitigation****, and ****less overall risk**** for a project.*

## Diagnosing Off-nominal Behavior

- With a State Effects Model that captures both nominal and off-nominal behavior, we are better equipped to design estimation algorithms that also perform diagnosis.
- The challenge is to figure out a way to use our models (state effects, measurement, & command models) to design these estimation algorithms.

**State Effects Diagram**

- Temperature
- Sensor
- Health

- Sensor
- Scale
- Factor

- Camera
- Temperature

- Temperature
- Measurement

- Sensor
- Bias &Noise

## Diagnosis via Hypothesis Testing

**Measurement Model for m:**
- m = f (Temp, SensorHealth, SensorScaleFactor, SensorBias, SensorNoise),
- where function f (...) is defined as follows: if SensorHealth = healthy,
- 	m is within SensorNoise of SensorScaleFactor * (Temp + SensorBias);
- else if SensorHealth = saturated-low,
- 	m = some value < Threshold;
- else if SensorHealth = failed-no-signal,
- 	m has noData.

- We want to use the following measurement model to estimate the SensorHealth:
- Given the latest estimates for Temp, SensorScaleFactor, SensorBias, & SensorNoise
- Algorithm:
- Hypothesis: SensorHealth is Healthy
- Compute m from measurement model and compare with actual measurement to confirm or refute the hypothesis.
- If refuted, change hypothesis...

## Model-based Estimation & Diagnosis

- Having an explicit state effects model also makes it easier to take advantage of state-of-the-art model-based estimation/diagnosis software.
- Computes state estimates by directly reasoning about explicit models
- E.g., Livingstone system flown on DS-1, MIT’s Titan system
- Requires expressing the model in a language (or graphical formalism, e.g., state transition diagrams) that is amenable to automated reasoning.

**Standby**

**Engine Model   **

**Off**

**Failed**

*(thrust = full) AND*
*(power_in = nominal)*

*(thrust = zero) AND*
*(power_in = zero)*

*(thrust = zero) AND*
*(power_in = nominal)*

**On**

**     ****Camera Model**

**Off**

- turnoff-
- cmd

- turnon-
- cmd

*(power_in = zero) AND*
*(shutter = closed)*

*(power_in = nominal) AND*
*(shutter = open)*

- 0.01

- 0.01

**Firing**

**Resettable**

- reset-
- cmd

## Onboard Execution Monitoring

## Enabling Fault Protection

- In order to implement even basic FP responses like safing, need to endow the spacecraft with the ability to monitor its execution.
- Recall from the last session that monitoring execution means comparing **estimated** state with **intended** state:

**Camera****Temperature**

**Temp****between 10 and 20****o****C**

**Transition to temp between 10 and 20****o****C**

**e**

****

**Unc.**

**Unc.**

- Uplinked goal time line:

- Downlinked state time line:

**Downlink****Time**

**12:30pm**

**2:00pm**

**1 to 2 hours**

## Enabling Fault Protection

- In order to implement even basic FP responses like safing, need to endow the spacecraft with the ability to monitor its execution.
- Recall from the last session that monitoring execution means comparing **estimated** state with **intended** state:

**Camera****Temperature**

**Temp****between 10 and 20****o****C**

**Transition to temp between 10 and 20****o****C**

**e**

****

**Unc.**

**Unc.**

- Uplinked goal time line:

- Downlinked state time line:

**Downlink****Time**

**12:30pm**

**2:00pm**

**1 to 2 hours**

**Whereas on the ground this comparison was done “in hindsight” for all executed goals on the time lines, doing it in flight enables us to check each currently executing goal, *****in***** *****real time*****.**

## Checking Success/Failure of a Goal

**Camera****Temperature**

**Temp****between 10 and 20****o****C**

**Transition to temp between 10 and 20****o****C**

**e**

****

**Unc.**

**Unc.**

- Scheduled goal time line:

- State time line stored in SV:

**12:30pm**

**2:00pm**

**1 to 2 hours**

- 20

- 2:00 pm

**Time**

- 3:30 pm

- 10

- 12:30 pm

**Camera****Temperature****(in deg C)**

- But we don’t want to only check merged x-goals! Must check each goal in the goal network (in case of failure, want to be able to trace back to original statement of intent, consider ramifications and select appropriate response)

- Now, move this process onboard:

## Checking Success/Failure of a Goal

**Transition to temp between 5 and 20****o****C**

**Checking Success/Failure of a Goal**

**Camera****Temperature**

**Temp****Between 10 and 30****o****C**

**Transition to temp between 10 and 30****o****C**

**e**

****

**Unc.**

**Unc.**

- Scheduled goal network:

- State time line stored in SV:

**12:30pm**

**2:00pm**

**1 to 2 hours**

- 20

- 2:00 pm

**Time**

- 3:30 pm

- 10

- 12:30 pm

**Camera****Temperature****(in deg C)**

## Enabling Fault Protection

- Checking success/failure of a goal is an evaluation of whether its state constraint is being satisfied.
- Since the spacecraft control system already has a copy of the goal network and x-goal time lines, and has direct access to the state estimates stored in the State Variables, this is relatively straightforward...
- 		We just need to *move the “comparison” logic onboard*.
**For each goal, systems engineers must define the satisfaction conditions as part of the State Analysis process...**

## IsStillSatisfiable Condition

- Is this currently-executing goal still being satisfied?

**Camera Temperature: **
**between 10 and 20 ****o****C**

**IsStillSatisfiable**

**Return TRUE if 10****o****C ****≤**** Current Temp Estimate ****≤**** 20oC**
**Return FALSE otherwise**

## IsStillSatisfiable Condition

- For many goals, this is trivial – just check whether the latest state estimate satisfies the goal’s state constraint.
- However, consider goals with constraints that are not instantaneously verifiable, e.g.:

**Heater Switch: **
**Remains closed 90% of the time**

- This goal is designed to be robust to some level of spurious switch-tripping.

- Also, it doesn’t really make sense in the absence of a specified goal duration.

**1hr**

## IsStillSatisfiable Condition

- For many goals, this is trivial – just check whether the latest state estimate satisfies the goal’s state constraint.
- However, consider goals with constraints that are not instantaneously verifiable, e.g.:
- In such cases, just looking at the latest estimate doesn’t tell us enough information – we must evaluate the state constraint over an interval of time.
- Furthermore, we don’t necessarily need to wait for the full duration of the goal in order to determine if it fails (e.g., it has no hope of succeeding if the switch has been tripped for 6 minutes or more)

**Heater Switch: **
**Remains closed 90% of the time**

**1hr**

## More General IsStillSatisfiable Condition

**IsStillSatisfiable**

**Return FALSE if: Heater Switch state history ****	****from start-of-goal to CurrentTime ****	****has been in any state other than ****	****closed**** for at least 6 minutes**
**Return TRUE otherwise**

- Is this goal still *satisfiable*, given our model and our achiever’s capabilities?

**Heater Switch: **
**Remains closed 90% of the time**

**1hr**

- The IsStillSatisfiable logic is associated with the goal’s achiever.

## Averting Goal Failure

## Averting Goal Failure

- One way to avoid goal failure is to design achievers with sufficient robustness & flexibility such that they can react immediately to off-nominal states
- “First line of defense” in FP: local reactive behaviors built into state control loops
- This mechanism is also the “last line of defense” for certain critical sequences, like EDL
- These reactions should be transparent to the goal-based execution mechanism (high-level intent remains satisfied)
- This requires flexibility in the specification of the goal’s IsStillSatisfiable condition

## Averting Goal Failure: Example

- IMU OpMode Cmd

- IMU Power Switch State & Health

- IMU Power Switch State  Msmnt

- IMU Msmnt

- IMU Power SwitchCmd

**Averting Goal Failure: Example**

## IMU Power/OpMode/HealthState Effects Model

- Unhealthy (Permanent)
- When Measuring, 1 or more channels producing data out of range

- Unhealthy (Recoverable)When Measuring, 1 or more channels producing data out of range

- Off
- Producing no data

- Initializing
- Measurementinit flag = True

- Measuring
- Measurement init flag = False

- PowerSwitch = ClosedAND Cmd = TurnOn

- Initializationcompleteafter 15 to 22 secs in Initializing

- PowerSwitch = Open OR Cmd = TurnOff

- Healthy

- Cmd = Reset ORCmd = TurnOff OR
- PowerSwitch = Open

- ON

- Cmd = Reset

**IMU Power/OpMode/Health****State Effects Model**

- Unlikelyrandomoccurrence

- Unlikelyrandomoccurrence

## IMU Power/OpMode/HealthState Effects Model

- Unhealthy (Permanent)
- When Measuring, 1 or more channels producing data out of range

- Unhealthy (Recoverable)When Measuring, 1 or more channels producing data out of range

- Off
- Producing no data

- Initializing
- Measurementinit flag = True

- Measuring
- Measurement init flag = False

- PowerSwitch = ClosedAND Cmd = TurnOn

- Initializationcompleteafter 15 to 22 secs in Initializing

- PowerSwitch = Open OR Cmd = TurnOff

- Healthy

- Cmd = Reset ORCmd = TurnOff OR
- PowerSwitch = Open

- ON

- Cmd = Reset

- Unlikelyrandomoccurrence

- Unlikelyrandomoccurrence

- Using this model, we can design a control loop that automatically attempts recoveries in response to a potentially recoverable fault, without failing its goal unless it diagnoses a “permanently unhealthy” device. NOTE: a more complete model would include other fault modes that are deemed realistic.

## IMU Power/OpMode/HealthEstimator Algorithm

- PermanentlyUnhealthy

- Probably
- Recoverable

- Initializing
- Meas init flag = true

- Measuring
- Meas init flag = false

- Meas init flag = false

- PowerSwitch= Open ORCmd = TurnOff

- Healthy

- Measuring & 1 or more channels providing out-of-range data & ResetCount >= 2

- Off
- Null
- measurements

- Measuring & 1 or more channels providing
- out-of-range data

- Cmd = Reset

- PowerSwitch= Closed ANDCmd = TurnOn

- Off or Initializing

- Cmd = Reset ORCmd = TurnOff OR
- PowerSwitch = Open;
- Upon transition,
- increment ResetCount

- Measuring & providing in-range data on all channels;
- Upon transition,ResetCount = 0

- Measuring & 1 or more channels providing out-of-range data & ResetCount < 2

- Unknown

- ON & Persistent null measurements
- (see State Function)

- PowerSwitch = Open OR (PowerSwitch = Closed & Measurement received)

- PowerSwitch= Open

- Meas init flag = true

- Meas init flag = false

- ON

- PowerSwitch= Closed ANDReceiving Meas.

_**State & Uncertainty Representation**_
- Power/OpMode: [Off, Initializing, Measuring]
- Health: [Healthy, Prob. Healthy, Prob. Recoverable, Perm. Unhealthy] + ResetCount

- orUnknown

## IMU Power/OpMode/HealthEstimator Algorithm

- PermanentlyUnhealthy

- Probably
- Recoverable

- Initializing
- Meas init flag = true

- Measuring
- Meas init flag = false

- Meas init flag = false

- PowerSwitch= Open ORCmd = TurnOff

- Healthy

- Measuring & 1 or more channels providing out-of-range data & ResetCount >= 2

- Off
- Null
- measurements

- Measuring & 1 or more channels providing
- out-of-range data

- Cmd = Reset

- PowerSwitch= Closed ANDCmd = TurnOn

- Off or Initializing

- Cmd = Reset ORCmd = TurnOff OR
- PowerSwitch = Open;
- Upon transition,
- increment ResetCount

- Measuring & providing in-range data on all channels;
- Upon transition,ResetCount = 0

- Measuring & 1 or more channels providing out-of-range data & ResetCount < 2

- Unknown

- ON & Persistent null measurements
- (see State Function)

- PowerSwitch = Open OR (PowerSwitch = Closed & Measurement received)

- PowerSwitch= Open

- Meas init flag = true

- Meas init flag = false

- ON

- PowerSwitch= Closed ANDReceiving Meas.

_**State & Uncertainty Representation**_
- Power/OpMode: [Off, Initializing, Measuring]
- Health: [Healthy, Prob. Healthy, Prob. Recoverable, Perm. Unhealthy] + ResetCount

- orUnknown

- NOTE: In this example, it’s important to recognize the use of a StateChart as an algorithm specification, as opposed to previous use as a physics model (or simulation specification).

## IMU Power/OpMode/HealthController Algorithm

|  | Is transitioning to and maintaining Off | Is transitioning to and maintaining Measuring & Healthy | ... | Is transitioning to and maintaining Healthy or Prob. Healthy |
| --- | --- | --- | --- | --- |
| Off & Prob. Healthy | No Command | If PowerSwitch = Closed, issue Cmd = TurnOn | ... | No Command |
| Initializing & Prob. Healthy | Cmd = TurnOff | No command | ... | No command |
| Measuring &Healthy | Cmd = TurnOff | No Command | ... | No Command |
| Measuring &Prob. Recoverable | Cmd = TurnOff | Cmd = Reset | ... | Cmd = Reset |
| Measuring & Perm. Unhealthy | Cmd = TurnOff | No command | ... | No command |
| ... | ... | ... | ... | ... |
| Unknown | Cmd = Reset | Cmd = Reset | ... | Cmd = Reset |

- Goal

- Estimated State

## Off-nominal Execution

## Off-nominal Events

- Two types of problems can be encountered during execution:
- Temporal Constraint Violations
- Goal Failure
- Let’s consider each of these in turn...

## Temporal Constraint Violations

**10 to 15 minutes**

**Camera Temperature**

**Heater Switch & Health**

**External Temperature**

**Between 10 and 20 degrees C**

**Transition to temp between 10 and 20 degrees C**

**e**

****

**Unc.**

**Unc.**

**Healthy and switching between both on and off**

**Healthy and switching between both on and off**

**e**

****

**Unc.**

**Unc.**

**e**

****

**Unconstrained**

**Fire Timepoint?**

- What if some time point never returns *isReadyToTransition = True*, causing its temporal constraint to become violated?

- Execution horizon

## Temporal Constraint Violations

**10 to 15 minutes**

**Camera Temperature**

**Heater Switch & Health**

**External Temperature**

**Between 10 and 20 degrees C**

**Transition to temp between 10 and 20 degrees C**

**e**

****

**Unc.**

**Unc.**

**Healthy and switching between both on and off**

**Healthy and switching between both on and off**

**e**

****

**Unc.**

**Unc.**

**e**

****

**Unconstrained**

**isReadyToTransition?**

**isReadyToTransition?**

- Execution horizon

**Elapsed duration: 10 mins**

**No**

**Yes**

- What if some time point never returns *isReadyToTransition* *= True*, causing its temporal constraint to become violated?

## Temporal Constraint Violations

**10 to 15 minutes**

**Camera Temperature**

**Heater Switch & Health**

**External Temperature**

**Between 10 and 20 degrees C**

**Transition to temp between 10 and 20 degrees C**

**e**

****

**Unc.**

**Unc.**

**Healthy and switching between both on and off**

**Healthy and switching between both on and off**

**e**

****

**Unc.**

**Unc.**

**e**

****

**Unconstrained**

**isReadyToTransition?**

**isReadyToTransition?**

- Execution horizon

**Elapsed duration: 13 mins**

**No**

**Yes**

- What if some time point never returns *isReadyToTransition = True*, causing its temporal constraint to become violated?

## Temporal Constraint Violations

**Temporal Constraint Violations**

**10 to 15 minutes**

**Camera Temperature**

**Heater Switch & Health**

**External Temperature**

**Between 10 and 20 degrees C**

**Transition to temp between 10 and 20 degrees C**

**e**

****

**Unc.**

**Unc.**

**Healthy and switching between both on and off**

**Healthy and switching between both on and off**

**e**

****

**Unc.**

**Unc.**

**e**

****

**Unconstrained**

**isReadyToTransition?**

**isReadyToTransition?**

- Execution horizon

**Elapsed duration: 15 mins**

**No**

**Yes**

- What if some time point never returns *isReadyToTransition = True*, causing its temporal constraint to become violated?

## Temporal Constraint Violations

- The time point fires, anyway!
- A subsequent goal may fail
- Handled by goal failure mechanism

**IsStillSatisfiable?**

**10 to 15 minutes**

**Module Temperature**

**Heater Switch & Health**

**External Temperature**

**Between 10 and 20 degrees C**

**Transition to temp between 10 and 20 degrees C**

**e**

****

**Unc.**

**Unc.**

**Healthy and switching between both on and off**

**Healthy and switching between both on and off**

**e**

****

**Unc.**

**Unc.**

**e**

****

**Unconstrained**

- Execution horizon

## Goal Failure

- Goal failure occurs when there is a ***state constraint violation***, i.e., the estimated state isn’t consistent with the goal as reported by the *IsStillSatisfiable* condition.
- As we will see shortly, goal failure may propagate up the elaboration tree, i.e., a parent goal may decide to fail itself if one of its children goals fails.

## Checking Success/Failure of a Goal

**Temp****Between 5 and 20****o****C**

**Transition to temp between 5 and 20****o****C**

**Checking Success/Failure of a Goal**

**Camera****Temperature**

**Temp****Between 10 and 30****o****C**

**Transition to temp between 10 and 30****o****C**

**e**

****

**Unc.**

**Unc.**

- Scheduled goal network:

- State time line stored in SV:

**12:30pm**

**2:00pm**

**[1hr, 2hr]**

- 20

- 2:00 pm

**Time**

- 3:30 pm

- 10

- 12:30 pm

**Camera****Temperature****(in deg C)**

## Checking Success/Failure of a Goal

**Temp****Between 5 and 20****o****C**

**Transition to temp between 5 and 20****o****C**

**Checking Success/Failure of a Goal**

**Camera****Temperature**

**Temp****Between 10 and 30****o****C**

**Transition to temp between 10 and 30****o****C**

**e**

****

**Unc.**

**Unc.**

- Scheduled goal network:

- State time line stored in SV:

**12:30pm**

**2:00pm**

**[1hr, 2hr]**

- 20

- 2:00 pm

**Time**

- 3:30 pm

- 10

- 12:30 pm

**Camera****Temperature****(in deg C)**

## Checking Success/Failure of a Goal

**Temp****Between 5 and 20****o****C**

**Transition to temp between 5 and 20****o****C**

**Checking Success/Failure of a Goal**

**Camera****Temperature**

**Temp****Between 10 and 30****o****C**

**Transition to temp between 10 and 30****o****C**

**e**

****

**Unc.**

**Unc.**

- Scheduled goal network:

- State time line stored in SV:

**12:30pm**

**2:00pm**

**[1hr, 2hr]**

- 20

- 2:00 pm

**Time**

- 3:30 pm

- 10

- 12:30 pm

**Camera****Temperature****(in deg C)**

## Reacting to Goal Failure

## Reacting to Goal Failure

**Reacting to Goal Failure**

- Multiple possible reactions to goal failure:
- Safing (non-critical sequences)
- Partial goal shedding
- Re-elaboration and re-scheduling
- Best-effort (critical sequences)
- Each of these will be discussed shortly...
- The failure of a goal is normally reported via telemetry.
**Defining appropriate reactions to goal failure for different types of goals and different mission phases is a critical systems engineering function, and is part of the State Analysis process.**

## Safing

**Safing**

- Safing response is appropriate...
- when safety of the spacecraft is at risk,
- when no obvious local response can be identified, or
- when there are potential implications on success/failure of future activities
- Traditional safing:
- Sequences are terminated (or at least suspended, if critical).
- Safing functions are a combination of sequenced and reactive behaviors.
- Goal-directed safing:
- Failure of key goals (e.g., critical flight rule) can result in invocation of the *safe* *goal network* — a macro of goals that establish a safe system state.
- Currently executing goal net gets replaced wholesale by the safe goal net.
- This can be very fast, and prescheduled (all temporal relationships hard-coded) to deliver the same effect as traditional safing.
- Takes advantage of the elaboration mechanism discussed previously, with scheduling short-circuited.
**Careful development of a robust and correct safing goal net is an important part of State Analysis**

## Partial Goal Shedding

- In case of non-critical goal failure, an appropriate response may be to simply extract these goals from the network (along with supporting goals in its elaboration), and continue execution.
- Failed goals may be placed into a holding bin for later re-elaboration and re-scheduling.
- Similar idea to MER “Bonus Science”, except we can shed non-critical goals anywhere in the sequence, not just at the end.

## Re-elaboration and Re-scheduling

- If time allows, it may be possible to take a goal that has just failed, re-elaborate it (invoking alternate tactics), re-integrate it into the network and re-schedule it.
- This strategy is appropriate for non-critical (but non-expendable) activities where we might be able to leverage:
- Physical or functional redundancy (exploit tactics).
- Temporal flexibility in the scheduled goal network.

## Best-Effort Execution

- For critical sequences, such as EDL, there may be insufficient time to apply any of these mechanisms.
- As previously mentioned, we will generally rely on robustness built into the estimators and controllers and reactive coordination mechanisms.
- When even our most robust local reactive behaviors are unsuccessful at averting goal failure, there’s pretty much only one thing we can do: keep trying! (subject to other constraints in the goal net, e.g., timeouts)
- In this case, the most appropriate response to goal failure is to do nothing at all:
- leave the failed goal in the network, and
- continue to attempt to achieve it.

## Part of the MER EDL “Goal Net”

## Goal Failure Responses

- Nominal goal net (elaboration tree)

- Re-elab. &Re-sched.:

- Safing:

- Best-Effort:

- Partial GoalShedding:

## Goal Failure Responses

- Nominal goal net (elaboration tree)

- Re-elab. &Re-sched.:

- Safing:

- Best-Effort:

- Partial GoalShedding:

## Goal Failure Responses

- Re-elab. &Re-sched.:

- Safing:

- Best-Effort:

- Partial GoalShedding:

## Reactive vs. Deliberative Coordination of Control

## Reactive Coordinated Control

- Under time-critical circumstances where multiple high-rate control loops must be coordinated, robustness is best provided through a hierarchical control mechanism
- Example: MSL EDL propulsion subsystem
- 6 descent engine controllers
- coordinated by a position and attitude controller
- can compensate for poor performance of any engine by redistributing the thrusting to other engines

## Coordinated Control:Deliberative vs. Reactive

- This idea doesn’t only apply to off-nominal situations & fault protection!
- Certain nominal activities require tight coordination that can’t be completely pre-planned, e.g.:
- Rover driving
- Visual odometry-based hazard avoidance (e.g., GESTALT)
- Manipulator arm control
- Etc.

## Delegation

- Goals are issued to goal achievers (estimators and controllers) in one of two ways:
- The Deliberative Way
- _Pre-planned_ system-wide coordination
- Elaboration and scheduling of goals into a Goal Network
- Network execution sends goals to achievers at proper time
- Example: All science and engineering activities for day *N* on Mars
- The Reactive Way
- Achiever sends goals directly to other achiever(s) during execution
- Enables one achiever to coordinate several other controllers
- Enables reactions in milliseconds rather than seconds or minutes
- Example: Rover driving and steering

- The Reactive Way is accomplished through the Delegation Pattern

## Delegation Example: Rover Driving

**Delegation Example: Rover Driving**

- Wheel 5

- Wheel 2

- Wheel 4

- Wheel 6

- Wheel 3

- Wheel 1

- Driving
- Controller

- Steering
- Controller

- Driving
- Controller

- Driving
- Controller

- Driving
- Controller

- Driving
- Controller

- Driving
- Controller

- Steering
- Controller

**Rover Position &**
**Heading Controller**

**Rover Position & Heading SV**

***Rocky 7***

- In this example, ***delegation*** enables a single controller to direct the actions of one or more other controllers...

- goals

- goals

- goals

- goals

- goals

- goals

- goals

- goals

## Delegation Pattern

**Delegation Pattern**

- Achiever
**A**

- Achiever
**B**

- “The delegate”

- “The delegator”

- Pre-planned goals

- Non-planned goals
- (reactive)

- Delegation from B to A is an option when the value of state variable B affects the value of state variable A
**During Elaboration:**The delegator (B) authorizes the delegate (A) to send reactive goals to B
**During Execution:**A sends goals to B, as needed, to achieve A’s goal

- B affects A

- Goal Network

- Pre-planned goals

- (P&H controller)

- (Wheel 2 drivingcontroller)

## Establishing Delegation Relationships

- Given that delegation is really a reactive execution-time mechanism, how do we “plan” for it, at elaboration and schedule time?
- Systems engineers define “delegation goals” as part of the elaborations.
- Can think of these goals as establishing an *authorization* for reactive coordination to happen (but they do not necessarily require it to happen – this is at the discretion of the delegate achiever).

**Camera Temperature:**** Between 10 and 20****o****C**

**Heater Op Mode:****delegate to Camera Temperature**

## Delegation Goals

**Delegation Goals**

- Delegation is an option when B affects A
- Delegation is authorized through goal elaboration
- A goal on state variable A elaborates into a *delegation subgoal* on state variable B
- The result is that achiever B accepts goals from achiever A (at execution time)

- affects

- State Effects Model

- Goal Elaboration Diagram

- [min, max]

**State Variable A****(ordinary goal)**

**State Variable B****(delegate to A)**

- Collaboration Diagram

**Achiever**
**A**

- Achiever
**B**

- reactive
- goals

- The delegate

- The delegator

## Scheduling Delegation Goals

- Each delegation authorization must be accompanied by an ***allocation constraint***, i.e., a constraint on allowable control (delegation is a form of *limited* authority).
- May delegate control of a SV to *more than one other controller*, so we must avoid “oversubscribing” the delegator controller’s capabilities, e.g.:
- Thruster controllers may delegate their authority to both the Spacecraft Position & Attitude controller (for reaction control purposes) and the Reaction Wheel Motor controller (for the purposes of desaturation).
- Merging two delegation goals consists of ensuring that the two separate demands on the SV are compatible with each other, and don’t oversubscribe the resource.
- If incompatible, don’t allow the two delegation goals to be scheduled at the same time.

## Delegation Example: Rover Driving

**Delegation Example: Rover Driving**

- Wheel Steering & Driving Controllers delegate control to Position & Heading Controller

## Fault Isolation throughMeasurement Distillation

## Fault Isolation

- We would like to design a control system such that faults are isolated close to their source and their effects are contained.
- Can design control system that “isolates” fault behavior by filtering, i.e., “distilling” from a measurement the information relating to a fault state.
- Enables us to define “virtual” or “idealized” device control loops that need not worry about off-nominal behavior.

## Original Control System Design

- Camera TempSensor HA

- Camera TempMeas. Model

- Update State

- Camera TempSensor HealthEstimator

- Camera TempSensor HealthSV

- Camera TempEstimator

- Camera TempSV

- Update State

- GetState

- Camera TempSensor Calibr.Params. SV

- GetState

- GetState

- GetState

- GetState

- Meas “m”

- CameraTemp

- CameraTemp Meas.

- Camera TempSensor Health

- Camera TempSensor Calibr.Parameter

## Control System Design with Distillation

**Control System Design with Distillation**

- Camera TempSensor HA

- Camera TempMeas. Model

- Camera TempSensor HealthEstimator

- Camera TempSensor HealthSV

- Camera TempEstimator

- Camera TempSV

- Update State

- GetState

- Camera TempSensor Calibr.Param. SV

- GetState

- m

- m’

- GetState

- DistilledCamera TempMeas. Model

- Update State

- CameraTemp

- CameraTemp Meas.

- Camera TempSensor Health

- Camera TempSensor Calibr.Parameter

- DistilledCameraTemp Meas.

## Control System Design with Distillation

**Control System Design with Distillation**

- Camera TempSensor HA

- Camera TempMeas. Model

- Camera TempSensor HealthEstimator

- Camera TempSensor HealthSV

- Camera TempEstimator

- Camera TempSV

- Update State

- GetState

- Camera TempSensor Calibr.Param. SV

- GetState

- m

- m’

- GetState

- DistilledCamera TempMeas. Model

- Update State

- Same algorithm as previously, except:
- When sensor is estimated to be healthy, output m’ = m.
- When sensor is estimated to be unhealthy, output nothing.

- Distilled measurement model not dependent on sensor health!

- Estimator can use the “ideal” sensor model. Algorithm design is thus independent of actual sensor implementation (simpler, reusable)

- CameraTemp

- CameraTemp Meas.

- Camera TempSensor Health

- Camera TempSensor Calibr.Parameter

- DistilledCameraTemp Meas.

## Summary: Goal-based Fault Management

- We have discussed a goal-based FP design that is:
- Tightly integrated (uses same mechanisms for nominal & off-nominal)
- Flexible (offers a selectable spectrum of responses)
- Highly robust (due to the inherent closed-loop nature of goals and the improved traceability of software to fault models)

**Control System**

**State variables**

**State variables**

**Elaboration, projection, & scheduling **

**State variables**

**Intent**

**Knowledge**

**Control System**

**State variables**

**State variables**

**System**
**Under Control**

**commands**

**measurements**

**State variables**

**Execution**

**Downlink**

**Uplink**

**Ground**

**Flight**

**Elaboration, projection, & scheduling **

**Intent**

**Knowledge**

## State Analysis Checklist

- As part of the State Analysis, systems engineers must specify:
- Adequate fault models as part of the State Effects Model
- Estimator designs that provide sufficient diagnosis capability
- IsStillSatisfiable logic for each goal
- Robust estimator and controller designs to avert goal failure, e.g., for critical sequences
- Appropriate fault response mechanisms for each goal and macro
- A carefully-constructed and correct safing goal network
- Carefully-constructed “critical sequence” goal networks that accurately specify acceptable behavior
- Delegation patterns for reactive coordinated control
- Appropriate delegation goals (with allocations and merge/scheduling logic) and their elaborations
- Distillation patterns where appropriate for fault isolation and/or virtual device reuse