Onboard Science Instrument Autonomy for the Detection of Microscopy Biosignatures on the Ocean Worlds Life Surveyor

The data preprocessing step applies simple parallelized image manipulations to prepare an observation for further analysis. Both DHM and FLFM data are resized from dimensions of 2048 × 2048 to 1024 × 1024 pixels, which reduces the compute and memory costs of the downstream particle identification and tracking algorithms. The resizing process is parallelizable, and can be configured for even lower resolutions at some cost to particle tracking precision.

The data validation step has two goals: (1) summarize the entire observation to provide contextual information to science teams and (2) execute quality checks to identify potential problems with the instrument or science data. For example, each motion history image (MHI) in Figure 5 provides a quickly interpretable image to understand the quantity and movement characteristics of all particles in an observation. A full list of validation products is described in Table 2. Many products were developed in direct response to science needs or data problems encountered during the development of OWLS. For example, the pixel intensity and pixel difference time series products ensure that observation frames have stable characteristics through time. Large pixel differences between frames can indicate instrument vibration, which will negatively affect particle tracking. The previously described DQE aggregates these pass/fail checks through a weighted summation.

Zoom In Zoom Out Reset image size

To extract biosignatures, HELM and FAME must first identify and characterize particle motion. Particles are detected in each frame by identifying pixels that are substantially different than the background field (calculated as the median frame across the entire observation). We then apply the DBSCAN algorithm (Ester et al. 1996) to find clusters of pixels meeting a specific size threshold, which are deemed particles. This identification method is agnostic to particle morphology, and tracking directly from the unreconstructed hologram avoids the computationally expensive reconstruction process, which is currently too resource intensive for onboard implementation (Marin et al. 2018).

The particles are then associated into motion "tracks" over time via the linear assignment problem (LAP) tracking algorithm (Jaqaman et al. 2008). The LAP tracker first employs frame-to-frame particle linking, assigning nearby particles in consecutive frames into track segments. This step is spatially global but temporally greedy; it makes no assumptions about particle motion characteristics, but it is also brittle to time gaps in particle detection. Therefore, the tracker employs a second gap-closing step, using global optimization to link the starts and ends of track segments into complete tracks. This method is computationally efficient and produces tracks that are robust to short particle occlusions and overlaps. However, extremely crowded samples can overwhelm the tracker by confusing the initial identification or violating the global assumption—that a particle will be nearest to itself as it moves between frames. If such conditions are expected, increasing the resolution and frame rate can improve the efficacy of this tracking method.

We formalize the particle tracks produced by this step in preparation for the following sections. An observation of n frames of p × p pixel resolution results in a set of tracks K . Each track k ∈ K is a set of particle positions (x, y)_t , where x and y are pixel coordinates of the center of the particle, and t is the frame number, representative of time. A track starts and ends at times t_s and t_e , and the particle tracking algorithm imposes a minimum on t_e − t_s to filter out spurious false positive identifications. We formally define a track with Equation (1) as follows:

$$\begin{eqnarray}&&k=\{{(x,y)}_{t}| 0\leqslant (x,y)\leqslant p,0\leqslant {t}_{s}\leqslant t\leqslant {t}_{e}\leqslant n\}.\end{eqnarray} \tag{ 1 }$$

For all tracks in K , the spatiotemporal coordinates are stored for further biosignature assessment (i.e., motility and fluorescence) in future processing steps. Track coordinates are also included for transmission as the compact collection of integers has a relatively small data volume and permits manual review of particle motion by science teams.

Once particles are tracked, HELM and FAME must assess them for signs of motility. To our knowledge, existing systems for motility characterization only evaluate specific species, detect specific patterns (e.g., the run-and-tumble motion of E. coli), or are currently too computationally expensive to deploy on spacecraft-ready computers (Rosser et al. 2013; Son et al. 2015). Instead, we developed an onboard system to identify any motion that cannot be explained by Brownian motion and simple fluid dynamics. The OSIA achieves this by quantitatively describing each track with a feature vector where every element in the vector is calculated using a different movement metric. This vector is then classified by a machine learning (ML) model to estimate the probability of motility.

Simple motion features, like speed and acceleration (Equations (2) and (3), respectively), are calculated to identify particles with changing movement patterns. The mean, standard deviation, and maximum value of these discrete values are included as features.

$$\begin{eqnarray}\begin{array}{rcl}{\boldsymbol{s}} & = & \{\parallel {(x,y)}_{t}-{(x,y)}_{t-1}{\parallel }_{2}| {t}_{s}\lt t\leqslant {t}_{e}\}\\ \mu ({\boldsymbol{s}}) & = & \mathrm{Mean}\ \mathrm{Speed}\\ \sigma ({\boldsymbol{s}}) & = & \mathrm{Standard}\ \mathrm{Deviation}\ \mathrm{of}\ \mathrm{Speed}\\ \max ({\boldsymbol{s}}) & = & \mathrm{Maximum}\ \mathrm{Speed}\end{array}\end{eqnarray} \tag{ 2 }$$

$$\begin{eqnarray}\begin{array}{rcl}{\boldsymbol{a}} & = & \{{s}_{t}-{s}_{t-1}| {t}_{s}+1\lt t\leqslant {t}_{e}\}\\ \mu ({\boldsymbol{a}}) & = & \mathrm{Mean}\ \mathrm{Acceleration}\\ \sigma ({\boldsymbol{a}}) & = & \mathrm{Standard}\ \mathrm{Deviation}\ \mathrm{of}\ \mathrm{Acceleration}\\ \max ({\boldsymbol{a}}) & = & \mathrm{Maximum}\ \mathrm{Acceleration}\end{array}\end{eqnarray} \tag{ 3 }$$

We also measure a particle's step angle at each frame (the discrete angular velocity; Equation (4)), as frequent or large deviations from a straight path suggest motility. Again, the mean, standard deviation, and maximum values are included as features. Here, we omit the conversion of step angle radian values to the range [−π, π] for simplicity.

$$\begin{eqnarray}\begin{array}{rcl}{\boldsymbol{\theta }} & = & \{\arctan \left(\displaystyle \frac{{y}_{t}-{y}_{t-1}}{{x}_{t}-{x}_{t-1}}\right)| {t}_{s}\lt t\leqslant {t}_{e}\}\\ {\rm{\Delta }}{\boldsymbol{\theta }} & = & \{| {\theta }_{t}-{\theta }_{t-1}| | {t}_{s}+1\lt t\leqslant {t}_{e}\}\\ \mu ({\rm{\Delta }}{\boldsymbol{\theta }}) & = & \mathrm{Mean}\ \mathrm{Step}\ \mathrm{Angle}\\ \sigma ({\rm{\Delta }}{\boldsymbol{\theta }}) & = & \mathrm{Standard}\ \mathrm{Deviation}\ \mathrm{of}\ \mathrm{Step}\ \mathrm{Angle}\\ \max ({\rm{\Delta }}{\boldsymbol{\theta }}) & = & \mathrm{Maximum}\ \mathrm{Step}\ \mathrm{Angle}\end{array}\end{eqnarray} \tag{ 4 }$$

We can treat each of the speed, acceleration, and step angle features as a time series and measure their autocorrelation for any time lag. This quantifies whether a particle exhibits a movement pattern with some periodicity. We generate features with time lags of 15 and 30 frames (corresponding to 1 and 2 s, respectively), but note that additional time offsets could be added.

In addition to frame-discrete features, we calculate features describing holistic track movement. The length of the track is measured in pixels (Equation (5)) and the duration of the track is measured in frames (Equation (6)). The horizontal, vertical, Euclidean, and angular displacements from the start to end of the track are also measured (Equations (7), (8), (9), and (10); since there is often background fluid flow in the sample chamber, the direction of the total displacement could be indicative of a particle moving against this flow. Sinuosity, the ratio between the track length and the total displacement, quantifies movement inefficiency, as motile particles may appear to meander while exploring for nutrients or responding to stimuli (Equation (11)). Finally, the mean-squared displacement (MSD) slope (as implemented in Manzo & Garcia-Parajo 2015) is used to distinguish Brownian motion from other types of motion.

$$\begin{eqnarray}&&\mathrm{Track}\ \mathrm{Length}=\mathrm{len}=\displaystyle \sum _{t={t}_{s}+1}^{{t}_{e}}{s}_{t}\end{eqnarray} \tag{ 5 }$$

$$\begin{eqnarray}&&\mathrm{Track}\ \mathrm{Duration}={t}_{e}-{t}_{s}\end{eqnarray} \tag{ 6 }$$

$$\begin{eqnarray}&&\text{End-to-end}\,{\rm{H}}{\rm{o}}{\rm{r}}{\rm{i}}{\rm{z}}.\,{\rm{D}}{\rm{i}}{\rm{s}}{\rm{p}}.\,=\,{x}_{{t}_{e}}-{x}_{{t}_{s}}\end{eqnarray} \tag{ 7 }$$

$$\begin{eqnarray}&&\text{End-to-end}\,{\rm{V}}{\rm{e}}{\rm{r}}{\rm{t}}.\,{\rm{D}}{\rm{i}}{\rm{s}}{\rm{p}}.\,=\,{y}_{{t}_{e}}-{y}_{{t}_{s}}\end{eqnarray} \tag{ 8 }$$

$$\begin{eqnarray}&&\text{End-to-end}\,{\rm{E}}{\rm{u}}{\rm{c}}{\rm{l}}{\rm{i}}{\rm{d}}{\rm{e}}{\rm{a}}{\rm{n}}\,{\rm{D}}{\rm{i}}{\rm{s}}{\rm{p}}.\,=\,{\rm{d}}{\rm{i}}{\rm{s}}{\rm{p}}=\parallel {\left(x,y\right)}_{{t}_{e}}-{\left(x,y\right)}_{{t}_{s}}{\parallel }_{2}\end{eqnarray} \tag{ 9 }$$

$$\begin{eqnarray}&&\text{End-to-end}\,{\rm{D}}{\rm{i}}{\rm{s}}{\rm{p}}.\,{\rm{A}}{\rm{n}}{\rm{g}}{\rm{l}}{\rm{e}}=\arctan \left(\displaystyle \frac{{y}_{{t}_{e}}-{y}_{{t}_{s}}}{{x}_{{t}_{e}}-{x}_{{t}_{s}}}\right)\end{eqnarray} \tag{ 10 }$$

$$\begin{eqnarray}&&\mathrm{Sinuosity}=\displaystyle \frac{\mathrm{len}}{\mathrm{disp}}\end{eqnarray} \tag{ 11 }$$

$$\begin{eqnarray}\mathrm{MSD}\ \mathrm{Slope}:\mathrm{defined}\ \mathrm{by}\ \mathrm{Manzo}\,\&\,\text{Garcia-Parajo}\,(2015)\end{eqnarray} \tag{ 12 }$$

While these features describe each track independently, we also wish to identify tracks k that behave differently from the set of all other tracks in an observation, { K \k}. We generate the relative speed feature to capture the ratio between a track's mean speed and the mean speed of all other tracks (Equation (13)). Similarly, the relative step angle features are compared between a track's mean step angle and the mean step angle of all other tracks (Equations (16) and (17)). The mean horizontal and vertical displacements of each track (Equations (14) and (15)) are also provided as features.

$$\begin{eqnarray}&&\mathrm{Rel}.\ \mathrm{Speed}=\displaystyle \frac{\mu {(s)}_{k}}{\mu {(\mu (s)}_{\{{\boldsymbol{K}}\setminus k\}})}\end{eqnarray} \tag{ 13 }$$

$$\begin{eqnarray}&&\mathrm{Mean}\ \mathrm{Horiz}.\ \mathrm{Disp}.\,=\,{{mdx}}_{k}=\mu (\{{x}_{t}-{x}_{t-1}| {t}_{s}\lt t\leqslant {t}_{e}\})\end{eqnarray} \tag{ 14 }$$

$$\begin{eqnarray}&&\mathrm{Mean}\ \mathrm{Vert}.\ \mathrm{Disp}.\,=\,{{mdy}}_{k}=\mu (\{{y}_{t}-{y}_{t-1}| {t}_{s}\lt t\leqslant {t}_{e}\})\end{eqnarray} \tag{ 15 }$$

$$\begin{eqnarray}&&\begin{array}{l}\mathrm{Rel}.\ \mathrm{Step}\ \mathrm{Angle}\ \mathrm{Cos}.\ \mathrm{Sim}.\\ =\,\mathrm{cossim}{({(x,y)}_{k,{t}_{e}}-(x,y)}_{k,{t}_{s}},(\mu ({{mdx}}_{\{{\boldsymbol{K}}\setminus k\}}),\mu ({{mdy}}_{\{{\boldsymbol{K}}\setminus k\}})))\end{array}\end{eqnarray} \tag{ 16 }$$

$$\begin{eqnarray}&&\begin{array}{l}\mathrm{Rel}.\ \mathrm{Step}\ \mathrm{Angle}\ \mathrm{Diff}.\\ \ =\,\left|\arctan \left(\displaystyle \frac{{y}_{k,{t}_{e}}-{y}_{k,{t}_{s}}}{{x}_{k,{t}_{e}}-{x}_{k,{t}_{s}}}\right)-\arctan \left(\displaystyle \frac{\mu ({{mdy}}_{\{{\boldsymbol{K}}\setminus k\}})}{\mu ({{mdx}}_{\{{\boldsymbol{K}}\setminus k\}})}\right)\right|\end{array}\end{eqnarray} \tag{ 17 }$$

In total, we compute 23 features to quantify the movement characteristics of each track in preparation for biosignature analysis, but additional features can be added if needed. While these features are not downlinked, they can be recalculated on the ground from downlinked track coordinates. With these track features, HELM and FAME are able to assess tracks for evidence of motility.

After calculating track features, HELM and FAME investigate tracks for evidence of motility and fluorescence. For both, an ML classifier estimates the probability that each track exhibits motile behavior. While the system is agnostic to the ML model used, the computational and interpretability requirements (Table A3) lead us to deploy classical ML methods, including gradient boosted trees (GBTs), random forests (RFs), and support vector classifiers (SVCs). We describe the implementation and evaluation of our model in Section 5.6.2. The posterior probabilities (i.e., confidences) produced by these classifiers further inform data downlink prioritization via the SUE (as discussed in Section 3.3.6). In a flight scenario, the classification model would be trained on the ground and stored onboard for inference with the possibility to retrain and re-transmit new model parameters throughout the mission. FAME also assesses particle fluorescence by directly analyzing the color profile of tracked particles. It calculates maximum particle fluorescence of each color channel and uses this to inform downstream prioritization through both the SUE and DD.

Finally, we excise small image crops (or "portraits") from the original, full-resolution DHM or FLFM frames for tracks of interest. These portraits can then be reconstructed on the ground to retrieve a volumetric image of each particle (McKeithen & Wallace 2021) as demonstrated in Section 5.6.3. While these represent important ASDPs as they are portions of the raw data, they also use considerable data bandwidth. Therefore, users can configure the size of particle portraits, the number of desired portraits per track, and optionally limit transmissions to only include portraits for motile tracks in DHM data.

The final output of the OSIA processing pipeline is a list of ASDP bundles from each observation. Each bundle includes: (1) data validation and contextual products, (2) particle tracks and results from their respective biosignature investigations, and (3) original-resolution portraits of scientifically interesting particles.

As described in Section 3.2, HELM and FAME compute a SUE, DD, and DQE for each processed observation. HELM's SUE is defined to assign high science importance to observations with tracks that are long in duration and have high motility probabilities. Motile particles that stay in the field of view for a long duration present the best opportunities for further evaluation. First, we score each track by multiplying each track's motility probability, P(motile∣k_i ), by its duration, ∣k_i ∣. Next, we sum the top five scores, then normalize them to [0, 1] by dividing by the ideal scenario: five full-duration tracks with 1.0 motility probability. This SUE definition is expressed in Equation (18), where k is a track vector as previously defined, n is the duration of the entire observation, and the summation assumes the tracks are sorted by their motility probability. We discuss the efficacy of this SUE definition in Section 5.2.

$$\begin{eqnarray}&&\mathrm{SUE}=\displaystyle \frac{{\sum }_{i=1}^{5}P(\mathrm{motile}| {k}_{i})\cdot | {k}_{i}| }{5n}\end{eqnarray} \tag{ 18 }$$

FAME computes its SUEs by calculating the median of tracks' fluorescence intensities. Since a particle must fluoresce to be observed in FLFM data, the median places scientific value on observations with a population of strongly fluorescing particles.

To quantify diversity, HELM includes particle size, speed, and displacement features in its DD in order to incorporate particle morphology and overall particle movement information into the prioritization. We discuss the efficacy of this definition in differentiating types of observations in Section 5.3.2. FAME defines its DD similarly but also includes the pixel intensities across three image bands to capture the fluorescence profile induced by the binding of different fluorescent tags (or autofluorescence). Refer to Section 3.3.1 for the calculation of the DQE.

To balance utility, diversity, and data quality, a system called JEWEL was developed to prioritize ASDPs from a set of processed observations for downlink (Doran et al. 2021). Intuitively, JEWEL seeks to select ASDPs for observations that balance strong evidence of biosignatures and are also diverse compared to previously transmitted observations' ASDPs. If all instruments calculate the aforementioned prioritization metrics, JEWEL can generate a single prioritization queue for a multi-instrument platform like OWLS. The prioritization algorithm is based on the Maximum Marginal Relevance algorithm (Carbonell & Goldstein 1998), which iteratively selects observations that maximize the additional science utility after applying a "discount factor" based on the most similar observation from those already downlinked. It estimates the similarity of observations by calculating the Gaussian similarity between pairs of DDs (described more in Section 5.3.2) of each candidate observation and the most similar previously downlinked observation. More formally, from the similarity metric, a diversity factor (df_i ) is computed for the ith observation as follows:

$$\begin{eqnarray}&&{{df}}_{i}=(1-\alpha )+\alpha \left(1-\mathop{\max }\limits_{j}\mathrm{sim}\left({\mathrm{DD}}_{i},{\mathrm{DD}}_{j}\right)\right),\end{eqnarray} \tag{ 19 }$$

where DD_j are the DDs for all previously downlinked data products. The $\alpha \in \left[0,1\right]$ parameter provides a mechanism to control the degree to which diversity-based discounting is applied as opposed to using the initial SUE values. When α = 0, the diversity factor is always 1.0 and no discount is applied (e.g., when observations with the strongest identified biosignatures are desired). On the other hand, when α = 1, the similarity-based discount factor is fully applied (e.g., when an equal balance of utility and diversity is desired). After each iteration of selecting a product for downlink, the marginal SUE values are recalculated according to Equation (20) to select the next observation for downlink:

$$\begin{eqnarray}&&{\mathrm{SUE}}_{i}^{\mathrm{marginal}}={\mathrm{SUE}}_{i}\times {{df}}_{i}\times {\mathrm{DQE}}_{i}.\end{eqnarray} \tag{ 20 }$$

JEWEL stores a simple onboard manifest of each observation's prioritization metrics and their downlink status to permit future prioritization for an arbitrary number of downlink events.

To engender trust with scientists and mission operators, JEWEL provides two methods of modifying or overriding the OSIA's prioritization decisions. First, JEWEL replicates the commonly used concept of "priority bins" for downlink prioritization, where high-priority ASDPs are transmitted before moving to the next bin. Operators can use a priori knowledge to direct observations ASDPs to specific bins if their importance is known in advance. Mission operators can also use this mechanism to ensure that some nonzero amount of high-priority ASDPs are transmitted for each instrument regardless of the global (across-instrument) prioritization scheme. Second, operators have the ability to manually override SUE values or move ASDPs to different bins during ground-in-the-loop commanding opportunities. This may be necessary, for example, if science teams believe an observation's ASDPs are more (or less) valuable than the OSIA's original estimation. Note that JEWEL also permits different per-bin configurations if a sophisticated prioritization scheme is desired.

While a full operator interface is outside the scope of this work, JEWEL generates an interactive ground report to expose ASDPs and prioritization decisions to ground teams. The visualization displays the cumulative SUE of all downlinked products, a dimensionality-reduced representation of DDs, each observation's DQEs, and a subset of ASDPs. The visualization was developed for the Mono Lake field campaign to quickly inform scientists of any identified biosignatures and explain the OSIA's summarization and prioritization decisions.

At the start of a mission, science teams seek observations that most directly satisfy the mission's primary science objectives. For HELM and FAME, the SUE, a quantified proxy for the scientific value of an observation, helps identify observations that contain motility or fluorescence biosignatures. JEWEL can be configured to prioritize by simply maximizing the SUE of returned observations. To evaluate the performance of HELM in estimating the SUE, we compare the OSIA-estimated SUEs to the "true" SUEs calculated from human-provided track annotations (Figure 10). As shown, the system demonstrates the generation of skillful SUEs for use during prioritization (per Req. L4-5 in Table A3).

Zoom In Zoom Out Reset image size

While the ideal OSIA system could perfectly estimate SUE values, the most important outcome is that observations are prioritized given the proper relative ordering. Therefore, we compare the sorted lists of observations by their estimated and true SUEs with Kendall's rank correlation coefficient (or Kendall's τ). τ = 1 indicates that the desired and actual ordering match perfectly, whereas τ = 0 indicates no correlation between the orderings. HELM is able to achieve τ = 0.529 on the entire lab data set, rejecting τ = 0 with a p-value of 1.09 × 10⁻⁶. Kendall's τ could be used by future works improving upon this system to benchmark their SUE-based observation prioritization. Additionally, mission concepts could define their OSIA prioritization requirements by determining an acceptable τ for autonomous downlink prioritization through rigorous trade studies.

To explore more deeply the remaining challenges in our system and observations, we investigated three performance cases from Figure 10 to understand how faithfully HELM's SUE calculations represented the data. First, the orange triangle in Figure 10 is a representative observation from a population of low-interest data (true SUE 0–0.2) that is overestimated by 0.1–0.2. In this observation, only one true motile track was found during labeling, which lasted through nearly the entire observation. However, due to a high particle density (exceeding assumptions described in Section 3.1), HELM identified many tracks with 0.4–0.6 motility probabilities. This characterizes the system's response to overcrowding: an overestimation of the utility due to motility. While undesirable, fortunately, this inflation is not sufficient to crowd out legitimately high-interest observations.

Second, the green star is an example where HELM generated an appropriate SUE value. Annotators identified 10 motile tracks, with the top five tracks ranging from 100–250 frames in duration. HELM also identified many of these tracks with similar durations and motility probabilities ranging from 0.6–0.8. Even in these nominal observations, the estimated SUEs tend to be lower than the ground truth, with most samples sitting below the red dashed diagonal of perfect estimation. We attribute this to the ability of human annotators to track motile particles for their entire duration with absolute confidence, while the automated tracker generally captures partial tracks due to confounders, even with existing mechanisms that combine track fragments. Should a mission concept require better SUE accuracy (if abundant high-SUE samples are expected, for example), model calibration (discussed in Section 5.6.2) and general tracker and instrument improvements could address this underestimation. For our use cases, however, the relative prioritization order was minimally affected as all samples' SUEs were consistently underestimated.

Finally, the purple diamond in Figure 10 is a high-interest example where the SUE was underestimated. Annotators identified 10 motile tracks, with the top five tracks lasting all 300 frames. HELM identified its top five tracks with durations ranging around 200 frames, with motility probabilities ranging from 0.4–0.6. However, the particles were at the limits of detection and sometimes overlapped, leading to track fragmentation. The classifier was also less confident with these motility patterns, consisting of slowly curving paths that were not well represented in the rest of the training data. This supports the need to further expose the system to a robust set of motility styles, both real and simulated, once mission resources become available for a full flight implementation.

We also include the DD as a component of prioritization to ensure a diverse set of samples comprise the final prioritized list. Whereas the SUE provides a mechanism to exploit an environment by identifying specific biosignatures, the DD provides a mechanism to explore samples across a range of conditions. It enables the autonomy to distinguish between different categories of observations independent of the SUE. On a real mission, diversity-based sampling would be most relevant once the primary science objectives of a mission were met, or if the initial SUE was a poor fit for the spacecraft's environment; in such situations, ground teams might desire a holistic understanding of the target environment's variability both for exploration and to help identify new biosignatures for SUE reformulation.

To define the DD vectors, we identified track metrics that reasonably separated the different observations into similar groups. For HELM, we used a 9D vector using the 10th, 50th, and 90th percentiles of the size, speed, and end-to-end displacement of tracks within each observation. For FAME, we use the same percentiles for fluorescent intensity, acceleration mean, and step angle mean. Therefore, the DD demonstrated the capability to separate lab and natural samples as well as different flow conditions and organism characteristics (per Req. L4-6 in Table A3).

Figure 11 shows three exemplar approaches to prioritizing DHM observations using different relative weights for the SUE and DD using the prioritization framework outlined in Section 3.3.6. The color of each point indicates an observation's SUE value, while the axes indicate an observation's relative relationship to others using DD elements. For intuitive visualization, we have plotted against only two of the original nine DD elements.

Zoom In Zoom Out Reset image size

A utility-only prioritization scheme (Figure 11, left) ranks observations based solely on the SUE. In our evaluation data, this prioritizes lab observations containing dozens of clear, motile Bacillus subtilis (B.Sub.) organism tracks. The speed and size of tracked particles in these observations was fairly consistent (comprising most of the grouping toward the lower left). Such a scheme is most beneficial when ground teams are confident in both their restricted interest in specific biosignatures and that the OSIA is well tuned to identify these key observations.

In contrast, a diversity-only prioritization scheme (Figure 11, right) ranks observations by the difference from the set of all previously transmitted observations (using the DD hyperspace as a quantitative proxy). After an initial, high-SUE observation is selected, the rest are sequentially chosen by their distance/difference from the previously selected observations. This includes natural samples from Newport Beach, CA on the right side of the plot which had large particles and were relatively fast. A diversity-focused prioritization strategy may be desirable after the primary mission science objectives are achieved or if the initial transmitted observations fail to satisfy a mission's science objectives and contextual information is needed to retune the OSIA. They also can provide key awareness of unexpected observation contents critical to inform instrument and OSIA reconfiguration.

However, a science team will often desire a blend of utility-based and diversity-based prioritization (Figure 11, middle). Here, the lower-left cluster of observations (with many motile organisms) is still sampled, but some observations containing large and/or fast particles (right and top of the plot, respectively) are also included despite lower utility scores. A balanced strategy allows a mission to pursue its stated science objectives while maintaining awareness of unexpected observation content. As the relative weighting between SUE and DD is a tunable parameter (see Equation (19)), ground teams can update the prioritization strategy as their understanding grows. Taken together, these analyses demonstrate that our OSIA system meets the L3-2 requirement for data prioritization, as described in Table A2.

The algorithms used for particle identification and tracking (described in Section 3.3.2) have several configurable parameters. We used genetic optimization via Tuning Optimizing Genetic Algorithm (TOGA) ⁵ to optimize the parameters over a subset of our hand-labeled lab HELM data set (described in Section 4.1). The optimizer sought to maximize the α tracking quality measure, commonly used to measure particle tracking performance (Chenouard et al. 2014). α is analogous to recall, and α = 1 represents a perfect match between labeled and predicted tracks. A high α is analogous to meeting the "Particle Tracking True Positives" requirement described in Table A3, but note that the system can be optimized to meet different mission requirements.

To report the achieved performance of particle track detection, we again use α, corresponding to recall, and β, corresponding to precision (capped at β = α). On the entire lab HELM data set, the optimized tracker reached macro-averages of α = 0.572 and β = 0.474. We specified = 25 pixels for these measurements; while prior work has set this value to the Rayleigh criterion (Chenouard et al. 2014; for our instrument, about 4 pixels), a larger value is reasonable here as we are processing unreconstructed frames from the DHM and FLFM. Instead, we defined our value based on our assumptions described in Section 3.1, which bounds the expected particle sizes and the distances between them. With respect to tracking, we demonstrate a macro-average true track coverage of 84.7%, and 8.45 false track points per uncrowded observation frame meeting requirements L4-1,2 in Table A3. Figure 13 shows example tracker output overlaid on a frame of an observation.

Zoom In Zoom Out Reset image size

To assess how tracking performance was affected by particle density and SNR, we generated 360 simulated studies spanning three particle density levels and six SNR levels (Figure 14). Higher amounts of particle overlap (e.g., resulting from crowded scenes) led to substantial degradation in tracker performance. This indicates that tracking is limited in observations with many particles even if those particles are visually obvious against the background. In general, once SNR crosses above approximately 0.5, it has a relatively small effect on tracker performance in crowded scenes. For uncrowded and semicrowded scenes, increasing SNR confers a steadier increase in performance. Experimentally, these results indicate that the capability to dilute water samples (to reduce particle density) is important to ensure optimal particle tracking.

Zoom In Zoom Out Reset image size

We evaluated three ML architectures for classifying track motility: GBTs (Friedman 2001), RFs (Breiman 2001), and SVCs (Cortes & Vapnik 1995). These methods were chosen for their simplicity, interpretability, and the computational efficiency of their Scikit-learn implementations (Pedregosa et al. 2011). We used five-fold stratified cross-validation to iterate over different combinations of the labeled data (Section 4.1) while avoiding data leakage from highly similar experiments. We also applied Bayesian optimization to optimize each method across its hyperparameter search space. ⁶ Each model was optimized to maximize the area under the receiver operating characteristic curve (AUC ROC). AUC ROC was chosen for its ability to represent the precision-recall trade-off; with a model that performs reasonably over a range of posterior probability thresholds, ground teams can make an informed trade-off between conserving data bandwidth and missing a low-confidence motile organism. For a specific flight mission implementation, this tuning would be thoroughly re-examined.

Figure 15 shows the performance of each optimized model architecture using precision-recall and decision error trade-off (DET) curves, which assess binary classification performance over a range of decision thresholds. Precision-recall curves represent the trade-off between the two metrics and are especially informative if the data set contains a class imbalance. DET curves provide the same information as an ROC curve, but at a scale that better highlights cross-model performance differences and explicitly represents the trade-off between false positives and false negatives for a range of probability thresholds (Martin et al. 1997). In both representations of model performance, the RF and GBT models surpass the SVC model. The GBT, RF, and SVC models achieved AUC ROCs of 0.88, 0.92, and 0.86, respectively. RF reaches the higher overall F₁-score (the arithmetic mean between precision and recall) of 0.78, compared to 0.71 and 0.63 for the GBT and SVC, respectively. A different F_β score may be used to evaluate different precision/recall trade-offs as desired. Elapsed ML prediction times for all models were well below 1 s, but the GBT and SVC architectures were approximately 75 × faster than the RF (see Table 5 for onboard runtimes). Due to the classifier performance and acceptably short runtime, we selected the RF model for further analysis.

Zoom In Zoom Out Reset image size

To interpret how individual features (track extracted variables) contribute to classifier decisions, we applied the ML explainability method Shapley additive explanations (SHAP) to our trained RF model. SHAP uses a game-theoretic approach to estimate the role of each feature in individual predictions (Lundberg & Lee 2017). Figure 16 shows the SHAP values for the 10 most impactful features used by the RF model. Here, negative SHAP values (left of center) indicate data points where the feature value corresponded to a push toward nonmotile predictions, while positive values (right of center) indicate tracks where the feature value corresponded to a push toward a motile prediction. For an intuitive example, tracks with a low mean speed or relative speed—indicating tracks that moved slower overall or relative to other tracks in the same observation—translated to lower motility probability as indicated by the concentration of blue points to the left of center.

Zoom In Zoom Out Reset image size

In general, the classifier used a variety of different feature types to make decisions. Relative features, which quantify how similar or dissimilar a track was compared to the population of other tracks in the observation, make up the top two features. This highlights the importance of comparing each track against other tracks observed at the same time. High values for relative step angle, which implies a track changed direction much more than other observed tracks, corresponded to a strong push toward motile predictions. For relative cosine similarity, high feature values—implying the end-to-end track direction was nearly identical with other tracks—tended to correspond to nonmotile predictions. The importance of relative features in classification decisions also implies the existing system is likely to perform worse for (1) extremely sparse observations where only a single track is observed or (2) cases where multiple motile cells move in unison (similar to a school of fish). Interestingly, "standard" metrics related to speed and acceleration (see Section 3.3.3) were of limited importance; only two of the 10 calculated ranked among the top 10. Others have noted that this line of explainability analysis, seeking to characterize precisely how the model makes its determinations, is a vital step toward gaining mission inclusion because it helps build trust with all stakeholders through familiarity and intuition (Slingerland et al. 2022).

Section 3.3.4 described how the classifier's posterior probabilities may be used for downlink prioritization. To validate the model outputs, we conducted a calibration assessment by binning posterior probabilities from the test set and checking if the percentage of truly motile tracks aligned with the model's predictions. Since each model appears under- or over-confident for certain portions of the predicted probability, we applied model calibration to adjust their output probabilities. Figure 17 shows the original (uncalibrated) and calibrated GBT, RF, and SVC models on the held-out test set. Here, cross-validated isotonic calibration was applied, but other methods also exist. While the application of calibration improves model outputs to more closely match the diagonal line (corresponding to ideal performance), some under- and overconfidence remains. Regardless of whether or not the calibrated model is used in a mission scenario, this procedure improves transparency and interoperability by exposing how faithfully an ML model's probability estimates align with reality based on the training/validation data available to the system. Note that calibration functions are strictly monotonic, and therefore do not impact model performance metrics shown in Figure 15. Taken together, these results demonstrate that the motility classifier meets requirement L4-3 in Table A3, with both satisfactory classification performance and estimation of probability of lifelike motility.

Zoom In Zoom Out Reset image size

While raw DHM and FLFM observations are much too large to transmit from ocean worlds, HELM and FAME crop small, full-resolution particle "portraits" to extract the raw image data containing tracked particles (as discussed in Section 3.3.5). Scientists can reconstruct these portraits to different z-planes and analyze morphology or search for subcellular structures in any suspected microorganisms. Since the reconstruction algorithm is computationally expensive (see Section 2.2) and the space of possible particle morphologies is difficult to analyze autonomously with OSIA, we include these particle portraits in the downlinked ASDPs for manual investigation by science teams. Figure 18 shows two example reconstructions from Mono Lake data. While the microorganisms identified during the field campaign were small, spherical, and displayed no obvious subcellular details, this capability to extract individual particle sizes would provide valuable detail for microorganisms with nonspherical shapes or resolvable subcellular structures.

Onboard science capabilities may be developed to achieve a variety of goals. We will explore six here: addressing data sufficiency, supporting advanced instruments, leveraging inactive periods, shortening reaction times, retargeting/reprocessing observations, and improving communication robustness. While we discuss these at a high level, detailed, formulation trade studies are needed to both identify which (if any) of these advantages warrant OSIA consideration and to quantify any expected benefits. We acknowledge that, for each of these capabilities, additional constraints and considerations such as available power, thermal management, and consumable resources such as sampling vessels, time to physically collect samples, and competing instrument observation schedules will ultimately influence infusion. Some of these concerns may be addressed by integrating synergistic autonomy elements such as onboard planning and scheduling (Gaines et al. 2022).

Data Sufficiency—For any new mission concept, mission architects must show how the volume and type(s) of observational data collected will address the scientific questions at hand. OSIA offers an alternative to the standard practice of transmitting all collected raw instrument data. For example, mission teams may wish to acquire more observations than can be downlinked when searching for rare phenomena and then only transmit those deemed scientifically useful. Alternatively, for a fixed bandwidth, missions can transmit summaries of many more observations than would be possible if returning raw data. Here, a simple metric of success could compute the ratio of total time spent returning an observation to the team (processing + transmission) for traditional and OSIA-based approaches (as we do later in Section 6.1.3).

Advanced Instruments—The combination of OSIA and next-generation processors will enable the consideration of newer, high data volume instruments that are infeasible for today's planetary mission concepts. Such was the core benefit provided by HELM and FAME—summarization of high-resolution video enables the search for cellular motility even when exploring bandwidth-constrained science targets like Europa and Enceladus. This mismatch between data collection and data downlink rates also limits the use of other advanced instruments such as high-resolution imaging spectrometers or Raman spectrometers. The combination of both OSIA and next-generation processors is likely required for deployment of these instruments beyond Earth's orbit. Modern multispacecraft concepts (e.g., cubesat constellations or distributed landers) may also face a similar challenge as their collective data volumes can outstrip today's monolithic spacecraft. When considering OSIA, an early metric of success might be to simply assess feasibility; for a given communication bandwidth, concept teams could determine if OSIA could conceivably summarize these large observations to fit within bandwidth constraints.

Leveraging Inactive Periods—Missions may include periods of inactivity due to communication downtime or limited observation opportunities. These idle periods may be reclaimed for observation processing to summarize and/or prioritize previously acquired observations for upcoming communication windows or other autonomously triggered tasks. This could substantially increase the number of observations returned by reducing or eliminating the impact of OSIA processing on "active mission time." Such was the primary benefit of the AEGIS algorithm deployed on the Curiosity and Perserverence rovers (discussed in Section 1.5), which selects rocks for ChemCam sampling after a drive but before a ground-in-the-loop command cycle (Francis et al. 2017). One useful metric of success here might be the number that additional science data returned when comparing a manually commanded spacecraft to one with OSIA.

Faster Reaction Times—The time required to transmit, process, and review raw observations during traditional "ground-in-the-loop" cycles limits the agility of mission teams. Current missions do not determine transmission order according to an onboard estimate of scientific utility; raw data requires (sometimes extensive) ground processing before reaching science teams, and spacecraft cannot often react autonomously to scientific data even if other autonomous systems are in place (e.g., for planning and scheduling). Thus, reactions to instrument data or problems can be delayed to the point of irrelevance. OSIA's ability to assess observations onboard means transmitted data can directly inform ground teams about the state of the scientific environment, thereby permitting faster decision making. It also opens the possibility for more missions to make autonomous decisions based on science data. A simple proxy metric for evaluating OSIA might be the reduction in time required to alert ground teams to phenomena of interest.

Soft Retargeting and Reprocessing—When data summarization involves excising regions of interest from the original observation (either autonomously as with HELM and FAME or via manual specification), there is the risk of omitting scientifically interesting content. By storing the raw data onboard and supporting reconfiguration of the OSIA, observations may be reprocessed to better extract the desired content without re-acquiring each observation. Similarly, OSIA parameters may be updated to improve summary products and optimize science utility on previously processed raw observations. For this benefit, a possible metric of success is the total number of unique observations that are processed and transmitted to ground. With retargeting and reprocessing, repeat observations (e.g., to correct issues with an initial observation) should be reduced, so the spacecraft can spend more resources sampling the environment for new phenomena.

Communication Robustness—To receive instrument data, transmissions from spacecraft beyond Earth's orbit must go through the Deep Space Network (DSN). Therefore, a mission's science yield may be affected if those assets do not meet the availability that was envisioned during formulation. For example, increased rationing of DSN downlink time during upcoming crewed Artemis missions or malfunctions in one of the aging Martian relay orbiters could impact the transmission viability of interplanetary missions. Where appropriate, OSIA is worth exploring as a tool to improve communication robustness during such situations; the capability to prioritize transmission of data with the highest estimated science utility or tune OSIA configuration to summarize more aggressively may mitigate mission risks. A method to quantify any benefits might involve first collecting (or simulating) a set of representative instrument data. Using this data set, a mission formulation team could estimate how science return is affected under a set of increasingly strict bandwidth constraints for conventional versus OSIA-based processing approaches.

A critical consideration for the infusion of any OSIA is compute feasibility. For some mission concepts, advanced compute resources will be required to enable the autonomy algorithms developed in this work. To inform this need, we provide coarse feasibility estimates for OSIA on future missions by considering how the runtime of our algorithms will change depending on the compute platform available. We acknowledge that, short of benchmarking a skillfully ported algorithm to a specific flight compute architecture, cross-processor comparisons are difficult to estimate accurately. Therefore, we limit these analyses to an order-of-magnitude (OOM) estimate.

We broadly divide our compute comparison into current- and next-generation processors. The first category of processors we consider are those with clock speeds in the 100 MHz range; this includes the RAD750 and LEON class of processors. The RAD750 was deployed on Mars Science Laboratory (MSL) (Curiosity) and M2020 (Perseverance) while LEON processors were used on the LICIACube satellite, which observed DARTs asteroid impact, as well as a number of Low Earth Orbit (LEO) CubeSats. The second category consists of processors with clock speeds in the 1 GHz range, including the Snapdragon 855 and High Performance Space Computer (HPSC). The Ingenuity helicopter uses an earlier Snapdragon model (the 801), but note that the HPSC has not been deployed as it was in development as of the time of this work. A previous study by the NEAScout mission quantified onboard science processing performance changes across these two processor classes (Lightholder et al. 2023a). A variety of compute operations demonstrated runtime improvements on the order of 10 × to 220 × (with a total improvement of 50 × ) when moving from megahertz- to gigahertz-scale processors. Using this analysis, we provide tentative predictions about the runtimes of HELM and FAME on future missions.

If deployed, we expect that a flight implementation of our OSIA algorithms will run at least as fast on a dedicated gigahertz-scale processor (e.g., the Snapdragon 855) as on the i7-3612QE third-generation quad-core processor used in our field trial, as benchmarked in Table 5. This is a reasonable assumption as: (1) we expect that a compiled flight-ready implementation of our software will run faster than the current implementation in Python (an interpreted language), (2) the Snapdragon 855 has a faster base frequency (2.96 GHz) than the i7 processor (2.1 GHz), (3) the Snapdragon 855 has eight physical cores compared to the i7 processor's four (hyperthreaded to eight), and (4) the Snapdragon 855 has hardware accelerators (including a Graphics Processing Unit (GPU)) that could further accelerate image processing steps used on HELM and FAME. (The i7's integrated HD4000 GPU was not used in this work). Therefore, we can conservatively estimate that HELM's and FAME's per-observation processing time will remain in the hundreds of seconds for gigahertz-scale compute platforms (as quantified in Table 5). Further, we take the most conservative conclusion from Lightholder et al. (2023a) and estimate a 10× slowdown for megahertz-scale compute platforms, estimating a runtime of thousands of seconds for this category. Beyond processor considerations, HELM and FAME were designed with RAM, storage, and runtime constraints in mind. Software configuration allows mission operators to adjust parallelism to take advantage of platforms with extensive hardware resources (RAM and CPU cores), while still operating on platforms with limited resources. We acknowledge that many other factors affect compute time, and other mission constraints and risk posture will limit choices around flight processors. Regardless, these estimates indicate that OSIA algorithms described in this work could be feasibly deployed on either megahertz- or gigahertz-scale compute platforms.

Existing reference mission concepts aimed at detecting life in our solar system vary greatly in terms of their constraints and proposed ConOps. Therefore, it is illustrative to explore how OSIA might impact each. We refer to OSIA capabilities outlined in Section 6.1.1 below, but we emphasize that complete formulation trade studies are needed to precisely quantify any potential benefits. Such a study must consider other critical choices (e.g., available power, thermal management, consumable resources, scheduling, sample collection). While a full trade study is beyond the scope of this work, we highlight how OSIA can enhance the architecture or operations of existing mission concepts. To support this analysis, we will refer to Table 7, which calculates the time-to-ground speeds for computing and downlinking ASDPs compared to the more conventional approach of downlinking raw data after ZIP compression. We also continue our focus on microscopes for biosignature detection, but the benefits of science autonomy for other instruments are discussed elsewhere (Francis et al. 2017; Mauceri et al. 2022; Theiling et al. 2022).

Table 7. Coarse OOM Estimates for Time-to-ground Speed-up Ratios of a Single DHM Observation (Defined in Section 4 and Table 4) for Three Mission Concepts, Two Processor Categories, and Using HELM Summarization (ASDPs Produced by the "High-bandwidth" Configuration) or ZIP Compression

Ref. Mission	ZIP product	ASDP	MHz Scale	GHz Scale
(Downlink Rate)	Downlink (s)	Downlink (s)	OOM Speed-up a	OOM Speed-up b
Enceladus Orbilander (34 kbit s−1)	2.6 × 105	3.4 × 102	≈2	≈3
Europa Lander (48 kbit s−1)	1.8 × 105	2.4 × 102	≈2	≈3
Martian Rover (1000 kbit s−1)	8.8 × 103	1.2 × 101	≈1	≈2

Notes. While these estimates provide rough intuition for how to compute platforms and the inclusion of onboard processing may benefit science return, a thorough mission architecture trade study must consider many other constraints to evaluate the true impact on any mission concept. Estimated OSIA runtimes are from Table 6.

^a $\mathrm{round}({\mathrm{log}}_{10}(\mathrm{ZIP}\ \mathrm{Downlink}/(1\times {10}^{3}\,{\rm{s}}\,\mathrm{Runtime}+\mathrm{ASDP}\ \mathrm{Downlink})))$ ^b $\mathrm{round}({\mathrm{log}}_{10}(\mathrm{ZIP}\ \mathrm{Downlink}/(1\times {10}^{2}\,{\rm{s}}\,\mathrm{Runtime}+\mathrm{ASDP}\ \mathrm{Downlink})))$

Download table as:  ASCIITypeset image

Enceladus Orbilander—The Enceladus Orbilander (MacKenzie et al. 2021) is a concept with potential OSIA applications driven by its extreme distance and relatively long duration of 2 yr. While at Saturn, the concept estimates a science data downlink rate limited to 34 kbit s⁻¹. It describes the deployment of a Life Detection Suite (LDS) similar to OWLS, and includes a microscope as a high-risk, high-reward instrument. Over the course of 2 yr of surface operations, the mission concept specifies 29 microscope observations totaling 0.12 GB of data, and would collect only still images to directly look for cells.

In this case, potential OSIA applications are driven by the 2 yr surface phase. This affords considerable onboard processing time, meaning that a less-powerful onboard processor may be permissible given ample inactive periods to process each observation. As seen in the first row of Table 7, OSIA with a megahertz-scale processor would still provide a two OOM speed-up over downlinking raw compressed products. As samples are collected passively (dependent on fallout and accumulation rates) or actively (dependent on scooping material from the surface), OSIA alone would not enable additional sample collection. However, multiple observations per physical sample could be enabled. Each would then be analyzed and down-prioritized to reduce scientifically redundant information to improve data sufficiency. Additionally, OSIA could better inform follow-up sample collection. For example, the "LDS Full" operational mode specifies two separate sample scooping procedures. Expedient, prioritized return of summarized ASDPs from the initial observations could inform reactive decisions about when and where to collect the second scoop. Finally, the three OOM speed-up afforded by more powerful onboard computation would enable advanced instrument observations such as microscopy videos. This could enable the search for motility biosignatures as demonstrated with HELM and FAME.

Europa Lander—The second reference mission is the Europa Lander mission concept (Hand et al. 2022) with OSIA applications driven by its substantial distance, short mission duration of 30 days, and a desire for a combination of autonomous operations and decision making by the ground science team. The concept describes a baseline model payload that includes optical and atomic force microscopes and plans for only five total samples. Communication bandwidth is estimated at 48 kbit s⁻¹, which would be shared between science and telemetry. The authors noted in a previous concept that the communication rate could "represent the biggest bottleneck in the timely return of decisional data" (Hand et al. 2017). The latest concept specifically discusses autonomy to address this issue, including "autonomy and machine-learning techniques...to allow the onboard system to replan communications activity, based on assessment of instrument data and priority measurements" (Hand et al. 2022).

With an expected combined science and engineering data return of >187.5 MB over the 30 day mission, data sufficiency and communication robustness are important considerations for this mission concept. Compared to the planned approach of raw-data transmission, OSIA's ability to summarize and prioritize data could improve the chances that any encountered biosignatures are successfully transmitted. As in the second row of Table 7, OSIA with a gigahertz-scale processor would provide a three OOM speed-up over downlinking raw compressed products. In addition, the short lifetime of the mission implies that operators will be under significant time pressure for any ground in the loop operations. Therefore, the rapid transmission of any summarized scientific insights is likely to be valuable for informing and shortening decision-making processes. The mission concept also states that, due to the constraints of direct to Earth communication, there would be significant idle time on the surface of Europa, which could not be utilized without autonomy (Hand et al. 2022). Finally, as with the Enceladus Orbilander concept, OSIA would enable advanced instruments (such microscopy videos for motility assessment) without significantly increasing downlink bandwidth or requiring new samples. For a mission as sample- and time-limited as Europa Lander, an additional biosignature capability could translate to a meaningful improvement in life detection sensitivity.

Martian Rover—The final reference mission we consider is a Martian rover (similar to Curiosity or Perseverance) focused on life detection. We include this reference to evaluate OSIA benefits for a relatively close, high-bandwidth mission. Current rovers like Curiosity and Perseverance depend on orbiters (Mars Reconnaissance Orbiter (MRO), Odyssey, Mars Atmosphere and Volatile Evolution (MAVEN), and ExoMars Trace Gas Orbiter (TGO)), to support their data transmission, which ranges from 8–2048 kbit s⁻¹ (Gladden et al. 2022). For the sake of this estimation, we will consider an average data rate of 1000 kbit s⁻¹.

OSIA inclusion on this future Martian rover concept would be driven by the need to support a daily operations planning cycle. Here, the mission cadence is likely to be similar to past rovers involving a sequence of detailed site explorations with short drives between each. While rover planning teams will not regularly face planning cycles as consequential as on Europa Lander, reaction time is still a concern. The ability to rapidly return a few summary data products could guide mission teams to better optimize where and how they spend resources when searching for biosignatures. This reduces the risk that a sample site is abandoned prematurely or that valuable mission time is squandered at a site of low scientific value. OSIA also offers the chance to collect many observations and leverage soft retargeting to analyze collected data over a long time period. Longer drives, for example, may leave substantial inactive time for iterative OSIA analysis of previously collected observations. As seen in the third row of Table 7, OSIA with an existing megahertz-scale processor would provide an OOM speed-up over downlinking raw compressed products. This would be advantageous if the mission chose to collect data at high rates while at a site of interest, then process and transmit data during the upcoming drive. OSIA may also provide communication robustness if there are any malfunctions in the orbital relay network, which would otherwise unexpectedly limit the rate and/or cadence of data transmission. Given the relatively high data bandwidth, a Mars mission may also be the most likely to deploy advanced instruments like Raman or imaging spectrometers. Overall, OSIA may offer some enhancements and risk reduction for a future rover concept, but the advantages are not as enabling compared to the Enceladus Orbilander and Europa Lander concepts exploring the outer solar system.

Ultimately, we seek to inform mission concept teams how processor choice and the presence or absence of OSIA will impact science return. By comparing the combined runtime and transmission time of different strategies, Table 7 displays the estimated OOM change in an observation's time-to-ground given choices in available data processing techniques (simple ZIP compression or OSIA) and available compute platforms (megahertz- or gigahertz-scale; Table 6). At a high level, this analysis indicates that OSIA has the greatest potential benefits for missions with low downlink bandwidth and a next-generation, gigahertz-scale processor. For missions with high bandwidth, OSIA's potential benefits are diminished as the onboard runtime becomes a significant component of the total processing and transmission time. Regardless of the processor choice, we estimate that OSIA will provide at least one OOM speedup in data return, which translates to either reduced time for a set data volume to reach ground teams or the ability to transmit a larger number of summarized observations in a fixed time window. Note that while we isolated these two aspects of the trade space for clarity, a true mission architecture study must explore a multitude of interconnected design choices simultaneously.