Operations for Autonomous Spacecraft

In monitoring campaigns, an instrument or suite of instruments monitors a physical system or natural phenomenon by collecting an extended observational data set with the goal of characterizing the behavior of the observed system. With onboard autonomy, the data collection campaign is adapted based on observation data. Within the monitoring class, we considered two scenarios, namely:

• •

  Magnetospheric Variability Detection. The magnetospheric variability detection scenario exercises onboard adaptive data compression in which the magnetospheric data readings from the plasma and particles instrument are used by the onboard autonomy to decide whether to store high-frequency, losslessly-compressed readings or low-frequency, binned data (thus leaving more room for other data products) based on the level of magnetospheric activity.

• •

  Magnetospheric Reconnection Event Detection. Occasionally, magnetospheric field lines reconnect with each other. As it is difficult to predict these high science value events, in this scenario, the onboard autonomy monitors high-frequency data from the plasma and particles instrument, looking for magnetospheric reconnection events. If such an event is detected, the corresponding data is saved in lossless format for downlink; if no such event is detected, the data is discarded.

Mapping of a body’s surface is typically a pre-planned activity; autonomy can enhance mapping by (i) changing observation parameters on the fly (e.g., camera parameters), (ii) adjusting the schedule in response to unexpected events (e.g., a camera reset), and, crucially, (iii) allowing mapping to be executed in parallel with other opportunistic activities, scheduling opportunistic observations for high-value but fleeting events. Within this class of science campaigns, we considered three scenarios, namely:

• •

  Mapping Triton and Plume Detection. While executing a pre-planned Triton mapping activity, a plume is detected by the onboard autonomy software. The autonomy algorithms then modify the onboard plan to collect observations of the plume with both cameras as well as the spectrometer, and replan the mapping task to minimize the loss of coverage while prioritizing plume observations.

• •

  Fault Detection, Isolation, and Recovery (FDIR) during mapping. In this scenario, the camera resets in the midst of executing a pre-planned Triton mapping task. The onboard autonomy recognizes the interruption, ascertains functionality, and replans the remaining observations so as to maximize the amount of the target area covered despite the shorter time available for mapping.

• •

  Mapping Neptune and Storm Detection. An atmospheric storm is detected while the spacecraft is performing a pre-planned mapping of Neptune. The autonomy reacts by revising the spacecraft plan to collect targeted observations of the storm (whose location may be time-varying and imperfectly known) with its cameras and spectrometer, and re-planning the mapping task to minimize the loss of coverage.

Similar to mapping, targeted observations are typically a pre-planned activity; autonomy can provide increased science returns by adapting observation parameters, revising observation opportunities if more or less time than expected is available for observations, and, critically, interspersing opportunistic observations with pre-planned observations. We considered three scenarios within this class:

• •

  Target selection. The spacecraft is given a ranked list of targets to observe on the surface of Triton. A camera reset causes an observation to take longer than expected. Onboard autonomy then replans subsequent observations based on the priorities pre-specified by ground operators, ensuring that once-in-a-mission observations are acquired while skipping lower-priority ones.

• •

  FDIR affects science plan during critical engineering event. A non-critical camera observation is planned during an engine burn. During the burn, FDIR intervenes to counter an unexpected increase in power usage by interrupting the observation. The interrupted science activity is re-planned for a later time.

• •

  Instrument tweaks capture parameters autonomously. While imaging a target, autonomy adjusts the narrow-angle’s observation parameters (specifically, the exposure time and number of exposures to stack) based on the level of noise observed in the images, while ensuring that the resulting observations will fit the downlink budget.

Table 1 reports in detail the uplink and downlink operations capabilities exercised by each scenario. Collectively, the scenarios exercise a number of key capabilities including planning and scheduling, event detection, and FDIR.

In the remainder of this paper, we discuss the tools and workflows that will be used to effectively operate spacecraft in these scenarios.

Space flight projects employ teams of downlink engineers to monitor and review spacecraft system status and report the spacecraft’s status to uplink planners, as part of a continuous cycle of operations over the entire course of a mission. The specific downlink operations concept of a given mission is strongly influenced not only by the mission type, but also by characteristics such as the available communications bandwidth for spacecraft engineering health and status data (which may be a small percentage of the total bandwidth available) and the frequency of downlink opportunities. Generally, the biggest driver to the downlink operations concept (as realized by the downlink operations process) is the timing of receipt of downlink spacecraft engineering telemetry, relative to the need to feed-forward that information into planning operations. Another important driver is the light-speed latency between the spacecraft and the Earth, where long latencies (and the resulting long operational turn around times) are themselves drivers for increasing use of onboard autonomy.

Certain missions, particularly Earth orbiters, are capable of downlinking with very little latency (they can be practically “joysticked” by operations) and also typically aren’t restricted in terms of engineering downlink bandwidth. These missions may have styles of downlink operations ranging from hands-on “continuous operations” to “lights out operations” where little operational monitoring is done by people, outside of anomaly response situations.

Deep space (e.g. Mars) landed missions typically have a longer downlink latency, often accompanied by a short turn-around time required to carry forward downlink analysis results and initial conditions into planning. This is especially true of rover missions such as Curiosity and Perseverance, where a large amount of complex data (including both scientific observations and engineering data) must be reviewed in a very short time span, in order for uplink teams to have time to perform all planning functions ahead of the final available uplink of the day. Further, lander missions often depend on orbital relays for delivery of data to Earth, given the higher bandwidth capabilities of orbiter relays compared to direct-to-Earth communications from the landers; this further constrains the downlink operational process timing and cadence to be dependent on the available orbiter relay communications windows. Critically, in anomaly situations, a lander typically just stops whatever it is doing, allowing time for ground operations to address the issue.

Deep-space flyby and multi-flyby missions, such as Cassini, JUNO and Europa Clipper, present all the challenges of deep space surface operations, and in particular the need to examine complex science and engineering data to assess spacecraft health and inform future planning. Deep-space flyby operations introduce an additional key constraint: if an anomaly occurs, there is no option to just “stop flying”, and a failure to respond in a very short time span may cause loss of mission.

In general, downlink operations of highly autonomous spacecraft includes all of tasks and challenges associated with non- or low-autonomy missions, but brings with it the additional challenge of understanding whether or not actual spacecraft actions and behaviors are appropriate or anomalous, given a large possible set of valid outcomes. In non- or low-autonomy missions, the nominal behavior of the spacecraft is typically unimodal and therefore more straightforward to characterize, given the command sequence provided by uplink; in contrast, in highly autonomous missions, a large number of possible outcomes may all be compatible with the uplink’s intent, depending on the spacecraft’s state and on its perceived environment.

The impact of increased autonomy on downlink for these different types of missions includes:

• •

  Downlink operations will typically require a high knowledge of uplink intent, both to interpret on-board decisions (and, specifically, to assess whether the spacecraft’s behavior is consistent with the provided intent) and to assess the spacecraft’s state.

• •

  The presence of autonomy results in a large number of possible outcomes on board, which cannot be fully determined a priori (indeed, the reason for on-board autonomy is to act on information that is not available on the ground); while prediction tools used by uplink operators can help assess the a priori likelihood and impact of each of these outcomes, operators will have to interpret telemetry from the spacecraft (and compare it to predicted outcomes) in order to fully understand onboard behavior. New tools are likely to be required to compare predictions (which are likely to be highly multi-modal) to actual telemetry, so as to assess the autonomy’s behavior and the spacecraft’s state.

• •

  Operations are likely to require new types of information related to autonomous behaviors to be downlinked and evaluated by operations (e.g., the inputs and execution traces of autonomy modules). This is a particular area of challenge, as long latency and low bandwidth, which are key drivers to adoption of autonomy, may preclude the ability to downlink large amounts of information related to the behaviors (e.g., images analyzed by an event detector, or the full spacecraft state considered by an on-board planner in each replanning cycle). This leaves ground operators to decipher the behavior of on-board autonomy with incomplete information; software tools are likely to be required to “fill in the gaps” in the data based on models of the spacecraft, its environment, and the on-board autonomy.

Downlink spacecraft engineers use a variety of software tools to perform their analysis functions for present-day missions. Tools include analysis scripts, reporting systems, and a range of graphical visualizations, including both 2D and 3D views as needed for specific analysis tasks. Of course the primary data being analyzed and visualized is the data downlinked from the spacecraft. Depending on the role of each subsystem engineer, this may include both spacecraft engineering health and status, as well as science data used in engineering analysis (e.g. rover camera images).

There are three general types of spacecraft data used in analysis of JPL missions:

• •

  Time series data representing onboard measurements of spacecraft state over time. JPL missions generally refer to this type of data as “channelized telemetry” or “channels”, with each channel representing a time series of measurements from spacecraft hardware sensors, as well as data reported by software components (e.g. onboard memory states). Channelized telemetry is the most widely used type of data, going back to the earliest flight missions, and still plays an important role for current and future missions in the reporting of spacecraft state. However, over time spacecraft engineers found the limitations of pure time series data to be a hindrance to operations, and new data types have emerged over the years.

• •

  Event Records (EVRs) representing single events that occurred onboard the spacecraft. Rather than the single data value of a channel record, each ground EVR record contains a message string, which contains further spacecraft state information embedded in that message.

• •

  Engineering Data Products, each containing a range of types of information, depending on the need. There are a wide variety of data products used by projects, including snapshots of state such as memory and data management states.

All of these data types are packetized for downlink delivery, and typically, during a downlink communications session or soon after, data packets are processed by ground telemetry processing tools. In some cases downlink operators monitor data via “real time” displays which are updated as data is processed by the ground system; in other cases, operators wait until data processing is complete on the ground, and review the overall spacecraft states via reports and graphical dashboards. Downlink constraint checks (often called “alarms”) are performed on data both in real time and in post-processing, checking for violations such as data values going over limits (e.g. power levels are too high), invalid behaviors or combinations of behaviors (e.g. activity A cannot ever overlap activity B), and for other types of undesired situations. Further, ground systems often include automated notifications to alert operators of an issue, given there may be a very short turn around time for mission engineers to respond to that issue and possibly prevent the loss of science data or even the spacecraft itself.

Once data is processed on the ground and in the hands of operators, a variety of tools and techniques are employed to analyze spacecraft health and performance. System status dashboards are used by projects to organize and summarize data by subsystem. Automated and user-triggered reports help to answer specific types of questions and pass forward system status to leads and other teams. Interactive tools are used for exploratory analysis, particularly in response to anomalous or otherwise unexpected behaviors.

Many missions incorporate prediction of onboard state and behavior as part of uplink planning, and operators often compare those predicts against actual telemetry during tactical and strategic analysis of the mission. In most cases there is only one predict generated for any given system state, making it fairly straightforward to compare an actual against a predicts. However with an autonomous system, there might be a large number of possible predictable outcomes, which can greatly complicate the ability of an operator to identify if onboard behaviors are within allowable ranges and expectations or not.

Furthermore, the combination of autonomous behaviors and limited downlink bandwidth create a challenge for operators to understand “why” the autonomous system made certain decisions. Even if all available engineering data could be downlinked, along with science results, to put together the whole story as to what happened onboard, it may still be a challenge to make sense of that data, especially if such understanding needs to happen in a short time span in order to uplink or modify new goals for the spacecraft.

This paper focused on these challenges, and identified two tools to improve downlink operations for autonomous missions: (1) an analysis tool capable of visualizing actual telemetry results against a range of possible predicts in the context of onboard events, and (2) a tool capable of providing the information needed to assess “why” the autonomous component made a given series of decisions.

This tool provides an intuitive way for scientists and operators to a) search and for observation opportunities and b) create/update observation goals and organize them within the context of a set of campaigns for the target mission. The UI design in Figure 4 illustrates the design that allows users to search for science observation opportunities, for example across different upcoming flybys, by specifying observation requirements and constraints. For example, scientists can search for observation opportunities that meet geometrical and imaging parameters, and preview potential conflicts. They can click on targets of interest on a 3D model of the planetary body and inspect the resulting footprint. Once an opportunity is satisfying, users can add such observation as a goal in its corresponding campaign.

The tool also allows the direct specification of goals in the form a set of desired activities (e.g. observation, detection) without necessarily using the search mechanism. Figure 5 shows an example of the creation of two goals (one conditional on execution of the other) to monitor a particular location on the surface of Triton, and perform a follow-on observation if a plume is detected. The figure also shows the geometric element on the right hand side, which is an important assistive visual element for creating goals for observations. During tactical planning, scientists and operators can rapidly make changes to the plan, and get instant feedback on the viability of their changes and their impact on overall mission progress and performance. For viability, the tool runs a surrogate of the onboard planning capability on the ground (in this project we use the MEXEC planning and execution system [4]) in nominal (or most likely) scenarios to check for constraint violations. With respect to impact, the small progress bars to the right of the campaign title shows the impact of that goal in the overall mission compared to the original set of goals.

It is important to note that these tools are domain dependent, meaning that they are designed to support science goal specification for a multi-flyby mission for a single spacecraft. This front end, in particular, is not meant to be used in other domain such as ground vehicles. Herein we intentionally designed it to be a familiar visual presentation for scientists for that particular mission. This helps the user express their intent more naturally, as opposed to going to mental efforts to translate their intents to unfamiliar and unnatural representation languages. In this case, the tools provide appropriate views and interactions depending on the user role (e.g., scientist, operator, etc). All the campaigns and goals are represented and stored in the background in a common language across the different views and tools. This common ground representation is called Task Network in this work. We will later cover a more domain independent modeling tool for capture campaign and goals. That is, operators and scientists could also directly work on the Task network modeling tool if desired.

This tool allows users to specify a set of metrics for each campaign, to evaluate spacecraft progress/performance toward goals achievements and campaign completion. The tool design provides templates for encoding the metric, e.g. mapping state variables to thresholds or bounds (e.g. the minimal number of plumes that must be detected and observed is 10). It is assumed that users are able to specify metrics formally and encode the procedure in which progress and completion are evaluate (such as a linear function where one plume observed means progress of 10%, and ten plumes observed achieves 100% completion of that campaign goal). Figure 6 illustrates the UI design for metric specification, showing the number of plumes metric as an example. Progress and impact is also shown for each campaign, based on the inputs given in the Mission Planning tool. Metrics are key inputs to evaluate both current and predicted spacecraft performance. Note that most of the metrics (if not all of them) are usually captured and specified early in the mission, or at the strategic planning level.

This tool (shown in Figure 7) allows scientists, engineers, autonomy engineer and operators to represent and model uncertainty with respect to a multitude of aspects that might impact the performance of the onboard autonomy spacecraft while executing it mission. These aspects include environmental uncertainty/variability, such as the number of plumes or features on the surface of Triton that might be detected, or engineering uncertainty/variability such as the probability that a camera will go into a fault state when in operations, or probability distributions over the duration or power consumption of activities performed onboard. Herein, users represent variability by specifying uncertainty in the form of probability distribution (e.g. Gaussian or Uniform distribution) or discrete percentage. Figure 6 illustrates the variability definition tool. The variability specification is fundamental to study the space of circumstances that the spacecraft might face, and the basis for the prediction phase proposed in this work. It is from these uncertainty models that we sample execution scenarios and evaluate the distribution of possible outcomes.

New additions or updates to variability specification can occur in any stage of the mission. Updates, for example, can come from downlink data, both at the tactical level (e.g. a magnetosphere model might need adjustments), or at the strategic level with trend and history analysis (e.g., the duration of plumes at a certain location can be better estimated given historical data from previous flybys).

This tool leverages previous JPL work on modeling goals [14] using a formalism called Task Networks (tasknets for short). The tool combines the task network editing and visualization, an output of the predicted task execution on a timeline (for a nominal, or most likely, scenario), and a log of messages including predicted EVRs, onboard planner decisions, and projected constraint violations. Figure 8 shows the UI design for the Task Network tool.

On the tasknet editing and visualization front (graph view on Figure 8), operators can visualize state conditions, state impacts (effects), resource constraints, priority constraints, and ordering constraints across tasks in the task network graph view in order to identify missing and conflicting resources and dependencies, or other issues preventing a task from being scheduled as expected. They can also navigate task hierarchy by zooming out to review the goals included in the plan, or zooming in to a specific goal to focus on lower level tasks. Operators can inspect task details including the commands, priority, and command parameters that belong to a task, along with task authorship history. The tool additionally enables merging tasknets together to combine goals, with capabilities akin to Git version control.

The predicted data shown in the timeline comes from a surrogate of the onboard planner (MEXEC in this work), in order to check if a nominal plan schedules as expected. Operators can inspect a moment in time across the different types of data with a brushing capability in order to correlate events, the active task, and resource timelines. Warnings and tooltips draw operators’ attention to goals that failed to schedule (or to be achieved), and then it offers the most likely explanations generated by inference (see Section 5.3 for more details on the inference mechanism) for factors that led to failures as well as nominal outcomes. Operators can also choose to view the final output timeline, or animate individual planning cycles in order to understand how the schedule evolved.

We expect that operators will most frequently generate tasknets using templates and parameters from other supporting tools (e.g., the Science Planning tool), but in less common situations, they can manually construct them by pulling in tasks from a template library. In this work, goals from the Science Planning tools are translated to task network elements and added to a master tasknets, where all the goals are represented and merged. The resulting master task network is the main data product that is uplinked to the spacecraft and handed to the onboard planner. The Task Network tool is central to the intent capture process and will be used both at the strategic and tactical planning levels.

This tool has been designed to show the aggregated summary of all the simulation runs [15] for a given task network, as well as the metrics and variability specifications. Figure 9 shows the predicted outcomes (for the target tasknet) on the left-hand side, ordered from most likely to least likely, aiding the operator in more easily deciphering the expected behavior of the constructed plans. The green and red arrows inform the impact of an added goal (in this case, observing Plume X) on the outcome distribution. For example, the percentage of cases in which Observation A and B will be both performed decreased (red arrow pointing down).

The left-hand side panel also presents the option for filtering the output for specific outcomes. Additionally, the main section contains a timeline view showing the scheduled activity times of the science goals, the modes of all instruments, as well as important spacecraft states including as storage usage and battery status. Since this view displays an aggregate of all outcomes, the charts on the timeline view showcase the overlaid results in a gradient-like pattern indicating all the possible values for the various outcomes. All in all, this view is crucial for the operator in examining all of the possible outcomes after running through the prediction engine.

The mission impact UI view (shown in Figure 10) provides an overview of the simulations spanning the whole mission (that is, looking into all flybys) highlighting, the impact of newly-added goals to the the progress and success of the campaigns and to performance trends. This view also shows how the plans perform with respect to key performance indicators, and the uncertainty associated with them. This view is especially important to operators to ensure that the constructed plans are accomplishing the higher level campaigns set out by the mission, and to what degree. It also highlights the impact of the goal changes for the next flyby (e.g., the addition of a new goal to observe plume X) at the strategic level (see the two bar charts on the bottom, with the impact gap in green). Furthermore, the operators are also presented with a few recommendations on how improve the plan to avoid conflicts and aid in campaign success. These recommendations are essential in fitting in with the iterative workflow of plan development.

The subsystem downlink analysis tool (shown in Figure 11) allows operators to review actual telemetry from downlink and compare it to modeled predicted data (predicts) to support the analysis of onboard health and safety and anomaly detection[16]. The tool resembles conventional downlink analysis tools, plotting onboard state over time overlaid with events, and a list of EVRs. The predicts are clustered, since the uplink process for autonomy produces thousands of predicts instead of just one. Operators can filter down to the cluster that match most closely what happened onboard in order to confirm that the spacecraft performed as expected, and identify improvements that they may need to make to the models. They can also filter EVRs to show exclusively unexpected EVRs, i.e., actual EVRs that did not match predicted EVRs for that plan cluster, or predicted EVRs that did not occur on the spacecraft. The tool can also display inferred data, i.e., the probabilistic distribution of key unmeasured states and parameters, reconstructed on the basis of received telemetry and of models of spacecraft and its environment (the creation of such data products is discussed in detail in Section 5.3). Inferred data can help the operator explain why certain autonomy decisions were taken; the comparison of inferred data with predicts can also help surface the most likely explanation for unexpected outcomes, which they can use as a starting point for an investigation. The Subsystem Downlink Analysis tool provides a simple view of the subsystem performance for nominal cases. In off-nominal or poorly understood cases, operators can access more details in the Behavior Performance Analysis Tool.

The Behavior Performance Analysis Tool (Figure 12) allows autonomy experts and operators to understand the onboard decisions, and compare them with expected behavior, in order to debug unexpected outcomes and evaluate the performance of the autonomy. It repurposes the Task Network tool but, instead of a modeled preview, it presents downlink data juxtaposed with the thousands predicts mentioned in the Subsystem Downlink Analysis tool. In support of this investigation, the tool also features messages describing onboard decisions, including (when applicable) previews of images data that was used to make decisions.

Models of the spacecraft, of its environment, and of the on-board autonomy are needed to perform inference. In order to build such models in a principled way, we adopt the State Analysis framework [23], and employ state effect diagrams to represent the spacecraft state, and goal elaborations diagrams for the on-board autonomy. In this section, we provide a succint description of state effect and goal elaboration diagrams; we refer the reader to [23] for a thorough discussion.

State effect diagrams capture the causal relationship between the states of the spacecraft and of its environment in a principled way. While a state effect diagram does not provide an analytical model for the relationship between individual states, it reduces the problem of capturing the coupled dynamics of a spacecraft and its environment into the much simpler problem of capturing how small subsets of states influence one another.

Figure 15 shows a state effect diagram for a spacecraft capturing magnetometry data, highlighting how the modeling problem is broken down into a number of much smaller, and more manageable, subproblems. In addition, the graph structure of the resulting model is highly amenable to computationally efficient inference, as discussed in the next section.

Goal elaboration diagrams capture relationships between goals in the on-board autonomy. By providing an abstract, synthetic representation of the autonomy’s goals, goal elaboration diagrams allow to “peek into” the decisions of autonomy, capturing the reasoning behind autonomy decisions (which makes such tools especially useful for explanation) while abstracting away algorithm-specific implementation details.

Goal elaboration diagrams focus on expressing the relationship between goals and actions - as such, they are well-suited for goal-based planners which explicitly optimize for achievement of user-specified goals. In contrast, this approach can struggle to capture the behavior of heuristics-based planners, where goals are imperfectly mapped to decisions through heuristics that cannot be properly modeled in a causal fashion; in such cases, a black-box representation of autonomy (using the exact same code employed on board the spacecraft) may be used, resulting in increased fidelity but much lower interpretability.

Figure 16 shows a goal elaboration diagram for an autonomy module autonomously adapting the sampling rate of a magnetometer in response to its measurements.

In order to perform inference, we use state effect and goal elaboration diagrams to build a factor graph [24] representation of the spacecraft. Like Bayes nets, factor graphs represent the joint probability distribution of a set of states as a product of factors; factors, in turn, can be specified as any function over a subset of state variables (for instance, the causal relationship between a spacecraft’s attitude and the likelihood of observing a given region of a body can be represented as a factor, where the inputs are the spacecraft’s attitude states, and the output is the likelihood that the spacecraft’s camera points towards the region of interest). Unitary factors are also possible, where a factor is a function over a single variable (for example, a direct measurement of a variable can be added to the graph as a unitary factor, also called a prior). We adopted the open source library GTSAM [25] to construct new types of factors based on the spacecraft’s continuous measurements and on the variables we would like to infer. The factor graph is then solved as a nonlinear optimization problem, where we determine the set of variables that best explain the measurements. GTSAM does this efficiently by exploiting sparsity (measurements typically only affect a small portion of the total number of variables).

To handle discrete variables and measurements, we make use of a version of GTSAM called MH-ISAM2 [26] which extends GTSAM by adding multi-modal factors. Multi-modal factors can be used to represent discrete set of states or models (e.g., a plume exists or doesn’t exist, the observed magnetic field conforms to one proposed model or another, one of the sensors is operating normally or has experienced a fault) as separate hypothesis; factor graph optimization then finds the hypothesis which best explains the measurements. An example of one type of multi-modal factor is shown in Figure 17 where circles represent the variable of interest (in this case the magnetic field strength) we are trying to infer at sequential time steps. Black nodes connecting the variables represent factors, which have a probability distribution associated with them. In this example, the factors connecting sequential variables describe how models say the magnetic field strength should progress with time. The blue factors are so-called detachable unitary factors that represent magnetometer measurements, with an associated measurement noise uncertainty. If one of the magnetometer measurements is faulty (i.e., the model of the magnetic field says that the magnetic field strength is unlikely to abruptly change in time, but measurement shows a large temporary change in magnetic field strength that can’t be explained by measurement noise), the factor graph is able to consider this option as a separate hypothesis, where the measurement is detached from the graph optimization problem. The set of hypothesis that result in the least accumulated error between the estimated states and their associated factors is then considered the most likely explanation.

Another use case for multi-modal factor graphs are discrete variables. One example we’ve modeled here is the existence of a plume on Triton, and the ability to detect plumes with a camera, shown in Figure 18. To do this, we group together two parallel sets of variables in time, one where a plume exists, and one where it does not, and connect these to a threshold variable representing the properties of the detector through multi-association factors. These multi-association factors represent the hypothesis that either mode of the discrete variable for plume existence explains the detection measurement. The discrete variables are also connected in time through additional multi-association factors that represent the likelihood of a plume transitioning between existing and not existing. We also consider the likelihood that the threshold variable we’ve commanded for the detection algorithm has not been applied correctly with detachable unitary factors.

The output of the factor graph is a maximum-likelihood estimate of the state variables considered, and the marginal distribution of each variable. In future work, this data will be displayed in the Subsystem Downlink Analysis Tool (Figure 11), providing operators with key insight into unmeasured variables and, critically, with the likelihood of each considered hypothesis - helping operators assess the state of the spacecraft and understand why autonomy made its decisions.