A High-Reliability Photoelectric Detection System for Mars Sample Return’s Orbiting Sample

Abstract

The Mars Sample Return campaign is an endeavor of unprecedented technological complexity and coordination that attempts to answer fundamental questions about the habitability of Mars by returning the first samples of Martian material to Earth for analysis. The third mission in the campaign consists of the NASA-provided Capture, Containment, and Return System (CCRS) onboard the European Space Agency’s Earth Return Orbiter, which will retrieve the Orbiting Sample (OS) container from its orbit around Mars. Retrieving a passive sample container from a planetary orbit has never been attempted by any spacecraft and requires the development of new technology to succeed in this ambitious task. This paper introduces the high-reliability Capture Sensor Suite (CSS), a novel optical detection system that provides CCRS with the capability to autonomously detect the OS as it is captured. This article will discuss the challenges and requirements for the fault-tolerant design of the CSS.

1. Introduction

The international partnership of NASA and the European Space Agency (ESA) to return samples from Mars is the most technologically complex planetary science mission ever attempted. The Mars Sample Return (MSR) campaign aims to bring Martian soil, rock, and atmospheric samples back to Earth to search for signs of ancient life on Mars. The MSR campaign consists of four coordinated missions to gather samples on the Martian surface, launch them into low Mars orbit (LMO), capture and contain the sample container for its journey to Earth, and analyze the samples on their arrival [1]. Figure 1 shows the MSR timeline and planning architecture.

The first of these four missions, NASA-funded Jet Propulsion Laboratory’s (JPL) Mars 2020, landed the Perseverance rover safely on the Martian surface in February 2021. It is now actively collecting and storing samples in specially designed tubes for Earth return. To date, Perseverance has already acquired twenty-three of a planned thirty-eight samples, including one atmospheric, two regolith, and twenty rock samples [2]. This accomplishment fulfills many years of external guidance to NASA, including the top recommendation of the U.S. planetary community in their most recent national strategy [3].

The second mission is the Sample Retrieval Lander (SRL), also developed by JPL. The lander would carry two types of payload vehicles: a rocket known as the Mars Ascent Vehicle (MAV) and dual Sample Recovery Helicopters (SHRs). The Perseverance rover is the primary means for delivering the sample tubes to SRL, where a robotic Sample Transfer Arm (STA) provided by ESA would insert the samples into a container atop the MAV. The SHRs would serve as backups to bring the sample tubes to SRL in case Perseverance becomes unable to perform this task. The sample tubes would be packaged in an oblong capsule roughly the size of a volleyball called the Orbiting Sample. Once the tubes are positioned inside the OS, the MAV would perform the first launch from another planet to put the OS into low Mars orbit [4].

The third mission of the MSR campaign is the ESA-led Earth Return Orbiter (ERO). ERO would enter Mars orbit and provide a communication relay to Earth for the other MSR elements. The ERO would perform rendezvous maneuvers, allowing its NASA-built payload, the Capture, Containment, and Return System, to capture the OS. Onboard CCRS, the OS would be sterilized for back-planetary protection, then securely stowed, and assembled into the Earth Entry System (EES) for the return voyage to Earth. Three days prior to arrival, the EES would be released by the spacecraft on a trajectory to land safely on Earth [4].

The last stage of the MSR campaign is entirely terrestrial. After the samples arrive on Earth, the Sample Receiving Project (SRP) would store and analyze the returned samples. The samples would be kept under stringent containment conditions and not released to other laboratories until it could be confirmed that they were safe. Once their safety has been established, laboratories around the world will strive to unlock the secrets that they contain [4].

The Capture, Containment, and Return System

The focus of this paper is the Capture Containment and Return System’s Capture Sensor Suite optical detection system. During the operation to capture the OS, the CSS collects telemetry to confirm that the OS has entered the spacecraft. This function is critical for the success of the first-ever capture of a sample container from a planetary orbit. As of this writing, CCRS is currently in the planning and design stages of development and has recently successfully completed its Preliminary Design Review (PDR).

CCRS consists of three modules that achieve its project objectives: The Capture Enclosure (CE), the Assembly Enclosure (AE), and the Micrometeoroid Enclosure (ME). These modules correspond to the functions of Capture, Containment, and Return in the following ways: the CE rendezvouses with and captures the OS, and the AE prepares it for the return to Earth in the ME’s Earth Entry System. Figure 2 shows the three payload modules and identifies the major components of the CE with respect to the Sensor Suite.

The Capture Sensor Suite is active during the Capture Phase of the mission, which occurs when the ERO spacecraft is in low Mars orbit. The spacecraft begins this phase by opening the Capture Lid, exposing the cylindrical volume of the Capture Cone where the OS will enter the spacecraft. To guide the OS into the Capture Cone, ERO will perform a series of rendezvous maneuvers using Light Detection and Ranging (LIDAR) modules mounted to the exterior of the enclosure.

As the OS approaches and enters the Capture Cone, it will leave the field of view of the LIDAR arrays, leaving the spacecraft blind to its exact location. To account for this, the surface of the Capture Cone is furnished with cutouts to accommodate the Capture Sensor Suite. Telemetry from the sensors is transmitted to the spacecraft’s Jettison Avionics system, which interprets the telemetry to deploy the paddle of the Linear Transfer Mechanism (LTM) behind the OS as it enters, capturing it.

2. The Capture Sensor Suite

The Capture Sensor Suite comprises two main hardware elements: dual Sensor Arrays, mounted on opposing sides of the Capture Cone, and dual Capture Sensor Electronics (CSE) boxes, as shown in Figure 3.

The Sensor Arrays consist of a generatively designed support structure and the 28 sensor channels it holds. Each channel consists of paired light-emitting diode (LED) emitter and photodiode (PD) receiver subassemblies. The emitter and receivers are mounted on opposing brackets in a through-beam configuration. The through-beam configuration of photoelectric sensors was selected for its simplicity and reliability in comparison to laser or inductive sensor alternatives [5]. Specifically, this technology offers resilience to the harsh radiation and environmental conditions in Mars orbit, as well as processing simplicity that can support the stringent timing requirements for OS detection. The Sensor Arrays are physically divided into two layers, stacked vertically, each containing 14 sensor channels.

The Capture Sensor Electronics provide electrical power for the sensor channels, process the sensor signals, and communicate with the dual upstream electronics known as the Jettison Avionics Hubs. The two CSEs operate simultaneously and are connected to the Hubs in a cross-strapped configuration for redundancy. Each CSE controls an independent set of sensors in the two layers, transmitting simultaneously to both Hubs through serial interfaces. The two CSEs and their associated sensor channels are referred to as the A and B sides of the Sensor Suite.

Although not physically a part of the CSS, as the interface to the rest of the CCRS-ERO spacecraft, the Jettison Avionics electronics play an essential part of the Sensor Suite’s architecture. Cross-strapped serial buses provide communication between the two CSEs and two Hubs. During the Capture operation, the Hubs receive the sensor state telemetry from both CSEs and ultimately command the LTM to deploy. Figure 4 shows the electrical connections of the CSE with the Jettison Avionics. Also shown are the Jettison Avionics’ Low Voltage Power Cards, which provide 28 Volt bus power for the CSS.

2.1. Driving Requirements

The essential requirement of the Capture Sensor Suite is to provide telemetry for the spacecraft to determine that the OS has entered the Capture Cone volume and can be captured by deploying the LTM paddle. Successful OS detection for the capture sequence is a critical operation in the overall chain of Mars Sample Return campaign operations. The primary design driver for the CSS is the timing of the Capture operation, which manifests in several ways.

The first timing requirement is due to the telemetry latency of communications with the spacecraft in Martian orbit, which may be several minutes long depending on the orbital location of Mars. Therefore, the OS capture must be performed autonomously, without ground-in-the-loop action from Earth.

Onboard CCRS, this constraint is shared across the components used for Capture in a timing budget, starting from the moment that the Capture Sensor telemetry confirms the presence of the OS in the Capture Cone. After the trigger instant, the OS then continues into the capture volume, contacts the internal Capture Cone volume, and bounces back towards the capture aperture to the plane of the LTM. It is at the point when the OS bounces back to the plane of the LTM that the capture timing budget ends. The Sensor Suite must provide enough time for Jettison Avionics to process its telemetry and the LTM to deploy.

Another consequence of the timing constraint is the fault tolerance of the system. Just as there is insufficient time for a ground-in-the-loop operation to capture the OS, there is insufficient time for ground-in-the-loop intervention in the event of Sensor Suite malfunction. As a Class A NASA mission, the CSS must be robust to single point failures in its design. Accordingly, the architecture of the Sensor Suite is designed to identify and operate through single point failures of any nature.

2.2. Concept of Operation

When the ERO spacecraft performs its final rendezvous maneuver to capture the OS, the sample capsule is tracked with a LIDAR unit mounted to the exterior of the Capture Enclosure [4]. As the OS enters the Capture Cone volume, it exits the field of view of the externally mounted LIDAR system [6] and the sensor suite takes over, monitoring the sensor channels for any loss of signal from the presence of the OS.

The sensors are arranged in two planes, or layers, perpendicular to the bore of the Cone and the nominal OS trajectory. This design of the CSS builds upon previous explorations of the sample capture detection problem [5,7,8]. As the OS travels down the bore of the Cone, it first obstructs sensors in only the upper Trigger Layer, then both layers, then only sensors in the lower Confirmation Layer. The transition of the Trigger Layer sensors from blocked to unblocked, while the Confirmation Layer is still blocked, is the criteria for detection. This method ensures that the OS will be entirely within the Capture Cone. At this moment, the LTM will swing out into the Capture Cone, capturing the OS.

Figure 5 shows each stage in the sensor layer sequence for detection. Position four is the critical moment, when the OS detection sequence has been fulfilled. The two-layer design gives a positive indication that the OS has fully passed below the Trigger Layer. The Trigger Layer is located just below the plane of the LTM’s swing-out travel, which works to ensure that the OS is not hit by the LTM as it swings outward. The offset spacing between the swingout plane and the sensor layer has been minimized to account for the lowest speed of the OS, providing the longest time for capture.

2.3. System Redundancy

As previously shown in Figure 4, the cross-strapped A- and B-side CSEs cards are arranged in a passive dual modular redundant configuration. Each CSE controls and monitors half of the sensor channels on each sensor layer fully independently. In the event that one of the CSEs malfunctions, the system degrades gracefully because the remaining CSE provides sufficient telemetry to the Jettison Avionics for the detection of the OS. The geometric spacing of the channels is arranged to support this functionality; the arrangement of the sensor channels is discussed in detail in Section 3.3.2.

Both A and B sides are nominally operational to prevent the OS from escaping if either side were to fail during capture. The capture timing dynamics happen too fast for a switchover from a primary to a backup system; with both sides nominally operating, there is no dropout of sensor telemetry from a switchover. In nominal operation, the Jettison Avionics Hub receives sensor channel telemetry from both CSEs and, using the known geometry of the sensor channels, combines the data for processing. The specifics of the detection algorithm are discussed in Section 3.2.

3. Design Implementation

This section details the implementation of the Capture Sensor Suite’s design. It is broken into subsections that focus on the core functional blocks of the system: the CSE control electronics, the algorithm for processing the CSE telemetry, and the design of the Sensor Arrays themselves.

3.1. Capture Sensor Electronics

The Capture Sensor Electronics are printed circuit board assemblies that provide power, commanding, and telemetering of the sensor channels. A block diagram showing the main hardware elements of the CSE is presented in Figure 6. Figure 7 shows the fully assembled Engineering Development Unit (EDU) CSE hardware.

Each CSE is a stand-alone system that provides isolated and regulated lower voltage power rails derived from the primary 28 Volt bus provided by Jettison Avionics. The low-voltage power rails generated are +5 Volts, +3.3 Volts, and +1.2 Volts. The +5 Volt rail is used by the circuitry responsible for driving the LEDs and sensing the photodiodes. The +3.3 Volt and +1.2 Volt rails are used by the RS-422 transceivers, the oscillator, analog-to-digital converters (ADC), and the field-programmable gate array (FPGA).

Radiation-hardened analog-to-digital converters are used to monitor all telemetry signals on boards. Two of these ADCs are used to sense the primary photodiode signals for OS detection. Two more ADCs are used to monitor the fourteen LED current drivers, which allows the CSEs to compensate for radiation degradation of the LEDs or to detect fault conditions in the LEDs. An additional ADC monitors housekeeping voltage and temperature telemetry of the board.

A radiation-tolerant reprogrammable FPGA is the centerpiece of the CSE. This device is the key element of the system because it implements all the logic responsible to drive the LEDs, control the ADCs, and handle communication with the Jettison Avionics through the cross-strapped serial interface.

FPGA Architecture and Signal Processing

The FPGA design is based around the Advanced Microcontroller Bus Architecture (AMBA) 2.0 on-chip bus architecture. Employing a standard and widely used bus like the AMBA allows the system to integrate heritage components easily, reducing development time and increasing the reliability of the system. The FPGA design architecture is shown in Figure 8. The system implements two Universal Asynchronous Receiver-Transmitters (UART) that are connected to both Hubs of the Jettison Avionics. The CSE telemetry is sent simultaneously to both Hubs, but commands are only received through one interface at any time. A key component of the FPGA architecture is the Command and Data Handling (CDH) intellectual property (IP) Core. It is connected to both UARTs and acts as a master in the AMBA Advanced High-performance Bus (AHB). The CDH component performs the communication of the system, receiving and executing the telecommands and transmitting the telemetry, including housekeeping and LED information. The CSE Interrupt Request (IRQ) IP Core implements a Direct Memory Access (DMA) module that collects the data to be transferred from the signal processing components and the ADCs on the AMBA Advanced Peripheral Bus (APB).

The LEDs are driven by the LED Modulation Control block within the FPGA. The control signals of the LEDs use Pulse Width Modulation (PWM) to produce a sinusoidal output when a sensor channel is enabled, rather than a constant time-invariant light output. Figure 9 shows the block diagram of this component.

This sinusoidal signal is received by the photodiodes and digitized with the ADCs onboard the CSEs. The FPGA then uses an implementation of the Goertzel algorithm [9] to evaluate the strength of the frequency assigned to the sensor channel. The frequency of each LED is unique and configurable to allow for differentiation between sensor channels. The Goertzel implementation is shown in Figure 10.

The sinusoidal light output and Goertzel demodulation technique are key features of the CSS’s design. Detecting the frequency component of a sinusoidal signal rather than a constant light intensity is advantageous because it allows the FPGA to consider only the light from a sensor channel’s source LED, ignoring both ambient light conditions and crosstalk interference from other sensor channels within the CSS. It also enables the capability to identify misaligned sensor channels because the source of an unexpected frequency can be traced to the source LED.

The output of the Goertzel signal processing block represents the intensity of the target frequency, which is compared to a threshold to determine whether that channel has been blocked by the OS. This comparison yields a single bit that indicates whether a sensor channel is blocked (1) or unblocked (0). This bit is referred to as the state bit for that channel. The state bit telemetry for all sensor channels is used by the Hub during capture.

The CSE also provides onboard error detection for the sensor channels to the Hub for use in the OS detection algorithm. The current implementation for error checking monitors for expected current values in the LEDs to ensure that an LED is properly functioning and saturated values of the photodiode signals, as a check for solar blinding. As with the state bit for each channel, this information is consolidated to a single health bit for each channel. Nominally, this bit is high, indicating that the channel is functioning correctly. The simplified end-to-end signal flow for a single sensor channel is shown in Figure 11.

3.2. OS Detection Algorithm

During the Capture operation, each CSE transmits sensor state and health bit telemetry at fixed rated, nominally 40 Hz. Each time the CSEs transmit new sets of sensor telemetry, the Hub cyclically executes a sequence of calculations to determine if either layer of sensors is blocked and then if the correct sequence of blocked layers has occurred to indicate the presence of the OS.

These calculations are performed by the Hub’s FPGA rather than locally at each CSE to leverage both the A and B sets of sensors. A consideration in this design was the resiliency of the algorithms to sensor failures both prior to and during the OS’s transit through the Capture Cone. The system is designed to successfully detect the OS if a sensor channel fails or an entire CSE is lost (and thereby half of the sensors are lost with it).

The Hub first calculates whether enough physically consecutive and healthy sensor channels on a layer are blocked. This indicates that the OS is obstructing that layer, or a “hit”. The hit calculation is performed separately for each layer, and the two outputs are then monitored for the successful capture sequence described above. To prevent spurious, pre-emptive, or false-positive triggering, each state in the sequence must be maintained for a certain quantity of samples, known as the persistence duration.

First, the Hub takes both categories of bits and interleaves the A- and B-side data in accordance with their physical arrangement. The interleaved health bits are then examined by counting the number of healthy bits in each set of six adjacent bits. Next, a bitwise logical AND operation is performed on the interleaved state and health bits. Each group of six adjacent bits in the combined bits is then similarly counted. Finally, these two counts are compared for any match. Figure 12 shows this algorithm flow and example data for a successful hit. This sequence ensures that in any grouping of six sensors, all healthy sensors have been blocked.

The six-adjacent-bit criteria is an essential element of the design of the Capture Sensor Suite, derived from the requirement that the OS must be detected despite any single point failures in the system. The worst possible single point failure is the loss of an entire CSE; this would result in the loss of telemetry from half of the sensor channels in the system. Using the error checking technique as described, the system will maintain its triple modular redundancy with the bits from the remaining CSE. Accordingly, the physical spacing between sensor channels is derived from the smallest dimension of the OS, so that in any orientation, six sensor channels will be obstructed.

The time history of the layer hit calculation for the Trigger and Confirmation Layers is then monitored for the correct sequence, as illustrated previously in Figure 5. Once the sequence is completed, the Hub commands the LTM to deploy, capturing the OS. Once this objective has been achieved, the operation of the Capture Sensor Suite is complete.

3.3. Sensor Arrays

This section presents the second hardware element of the CSS, its two Sensor Arrays. Within the spacecraft, the Sensors Arrays mount to a bulkhead inside the Capture Enclosure on opposing sides of the Capture Cone. Cutouts from the Cone surface provide line-of-sight access for the optoelectronic subassemblies that make up the sensor channels.

3.3.1. Optoelectronic Subassemblies

The LED emitters and PD receivers that make up the sensor channels are packaged into discrete subassemblies. Each LED subassembly is interchangeable with any other LED subassembly, and the same applies for the PD subassemblies. This allows for flexibility during verification and integration: each subassembly undergoes identical testing prior to integration into the bracket structure and may be installed in any location. Figure 13 shows the LED and PD subassemblies mounted to the bracket structure.

The LED subassemblies contain only the LEDs themselves and mechanical strain relief for their electrical leads. The LEDs selected for this system are low-powered alternatives to lasers considered in previous architectures [5]. The selection of narrow-field LEDs balances efficient use of the light generated with alignment difficulties from tightly focused lasers. The 850 nm, near-infrared wavelength of the selected LEDs coincides with the peak responsivity of silicon photodiodes for efficiency.

In contrast with the simple LED subassemblies, the photodiode subassemblies include additional optical filters and Photodiode Pre-Amplifier (PPA) circuits. The photodiodes themselves are components with a very large active area, selected for their sensitivity. The silicate glass optical filters provide a passband centered around the peak 850 nm wavelength of the LED block interference from light sources outside the area of interest; in this application, the dominant interference is sunlight.

The PPA electronics are included in the photodiode subassemblies to boost the very small (microampere-level) output of the raw photodiode for transmission along the harnessing to the main CSE. Due to thermal and space constraints, the CSEs cannot be packaged in the immediate vicinity of the Sensor Arrays. The amplification stages also provide filtering of the PD signals to eliminate signals outside the frequency range of interest. These preamps use a transimpedance amplifier topology with DC biasing to operate in a photoconductive mode. This design choice allows the PPAs to use a single 5 Volt power rail, simplifying the electrical topology, which in turn allows for component and mass savings.

3.3.2. Sensor Array Geometry

The concept of the Sensor Suite relies only on the known dimensions of the OS capsule and the parameters of its incoming trajectory. As a result, the specific geometry of the sensor channels has been designed to ensure that all possible combinations of trajectory and OS orientation will result in successful detection. Additionally, as previously discussed in Section 2.3, the Sensor Suite is designed to be able to detect the OS even if one of the CSEs fails, taking out half of the sensors with it. Figure 14 depicts a rendering of the sensor spacing geometry. Note that the sensor channels for the A side and B side face opposite directions: all A side emitters are mounted in one bracket, and all B side emitters are mounted on the other.

The spacing of the sensors on each layer is driven by three things: the minimum OS dimension, the Cone diameter, and the requirement that the Sensor Suite must function with a single CSE operational. This last requirement imposes the spacing as a byproduct of the OS detection algorithm, which needs three sensor channels (from the remaining CSE) to be broken by the OS’s minimum dimension. Therefore, the spacing is set to guarantee six channels (across both CSEs) are broken for the smallest OS dimension. The quantity of sensors per layer is set by maintaining this spacing across the width of the Cone, yielding 14 total sensors.

The spacing between the layers is set to guarantee that no matter the speed of the OS, sensors will be obstructed for the minimum persistence duration required by the layer sequence algorithm. Optimally, the two sensor layers would be rotated 90 degrees from each other along the axis of the Capture Cone to minimize crosstalk between them. In practice, the placement of the LTM along the edge of the Capture Cone limits the angular offset to twenty-three degrees.

3.3.3. Structural Design

The design of the Sensor Array bracket structure is primarily driven by the position requirements of the 56 LED and photodiode subassemblies. The bracket is mounted to an internal bulkhead of the Capture Enclosure and therefore must stretch around a large angle of the Cone’s perimeter to allow the sensors to have coverage across the width of the Cone. Although a segmented approach was considered for the structural bracket, the alignment of the Capture Sensor suite was a key requirement and primarily driven by the bracket. The position and repeatability of each sensor are easier to control when the mounting for each set of sensors is contained in a single structure and the mounting feet spread as far as possible. These factors all contribute to the use of a large integrated structure for all subassemblies on each side of the Capture Cone.

Initially, a traditionally manufactured bracket was designed to hold the subassemblies on either side of the Capture Cone. However, due to the number of individual mounting interfaces for each sensor and the curvature of the Cone, this led to a large, bulky, and extremely mass-inefficient part. Given that the details of the intermediate bracket structure are inconsequential to the sensors if they can withstand the shock and vibration loads from launch, the brackets became a ripe target for mass reduction.

Accordingly, the bracket was redesigned with the use of generative design software. Generative design allows the user to input geometric constraints, manufacturing constraints, and loading cases, after which the software runs through tens of iterations to optimize the design for mass savings while maintaining high structural stability. The decision to use this software did not come without hesitancy—with their unusual topologies, large generative (or evolved) structures have yet to be widely demonstrated in aerospace applications due to perceived risk. However, this fear has been largely unfounded in practice [10]. The Capture Sensor Suite is a useful proving ground for this methodology because of the relatively low loads it must withstand (allowing for very high factors of safety) and the opportunity for substantial mass savings.

Generative design allows the user to input geometrical constraints, including “preserve” and “obstacle” geometries, indicating to the software where there must be material (such as around the photodiodes and photodetectors to allow them to be bolted onto the bracket) and where there may not be material (which is used to maintain clearance to the Capture Cone, allow a clean field of view for the sensors, and provide installation access for all fasteners in the assembly). Figure 15 below shows this starting geometry for the design on the left, with the preserve geometries in green and obstacle geometries in red (obstacle geometry for the Capture Cone surface is hidden for clarity). Additionally, the material for the bracket (Aluminum 6061-T6), manufacturing method (five-axis milling), and minimum desired factor of safety (2.00) were set. Finally, the anticipated worst-case mechanical loading was set within the software of launch loads of 63 g applied in the x, y, and z directions with the mounting feet fixed at the bolt locations. The final output of this design given the described input constraints is shown on the right side of Figure 15 below.

The final design of the bracket, created with the use of generative design, perfectly met the requirements and goals of the design. Minor clean-up and post-processing of the model was carried out for the final design and to ensure manufacturability. This involves adding larger cutter radii and straightening out material members to reduce machining time. The fabricated EDU version of the bracket is shown below in Figure 16. It accommodates all bulkhead mounting locations and sensor positions while minimizing the amount of material necessary to support the mass of these parts through launch, resulting in a mass reduction of 60% from initial concepts using traditional design methods. The design of the bracket successfully went through a standard structural analysis to confirm the strength of the design guaranteed by the generative design software, which is described in detail in the next section.

3.3.4. Structural Analysis

While the generative process can assess the design based on the specific loading provided, it cannot assess the design against all loading scenarios, including launch vibration and operational thermal loading, nor can it assess against combined loads. Therefore, the validity of the design must be confirmed through the traditional structural analysis methods.

Due to the complex geometry created through generative design, there were special considerations when creating the Finite Element Model (FEM) of the bracket. It is only possible to mesh complex geometries like this bracket with a solid tetrahedral mesh, and therefore the mesh quality and sensitivity are especially important. Details of the mesh are shown in Figure 17.

Approximately 1.2 million 10-node parabolic tetrahedral elements were used to mesh the bracket. The mesh was concentrated at the high-stress geometry transitions between the feet and structure and the structure and diode mounts. Mass elements were used to represent the sensor subassembly mass, and bolts were represented through spring and rigid element connections.

The significant node count was manageable at the component level due to high-performance computing; however, to create a thermally mapped FEM or one that could be passed on to the next higher assembly level, a lower-fidelity version of the FEM was created with 175,000 10-node tetrahedral elements. The difference in modal stiffness between the detailed and the low-fidelity models was less than 0.5% on the primary mode.

The Sensor Array bracket was analyzed against the following environments:

• Quasistatic launch loading of 63 G in three axes (shown in Figure 18).
• Random vibration of 14.1 Grms in three axes; standard proto-flight General Environmental Verification Standard (GEVS) input.
• Bulk Survival Cold Thermal environment of −40 °C.
• Hot and cold operational thermal loading, nodes thermally mapped based on thermal analysis results.

Stress analysis indicates that the bracket will survive launch and operational loading with considerable margin. The minimum margin from these environments was +0.26 against vertical quasistatic load and analysis-only factors of safety (2.0 against yield and 2.6 against ultimate tensile strength).

As the development of this bracket is still at the PDR stage, the use of the Mass Acceleration Curve (MAC) and GEVS random inputs is appropriate but also very likely conservative at this early stage of component-level analysis. There is a high likelihood that as the overall design and analysis of the spacecraft and surrounding structure mature, structural loading will become less severe. Therefore, positive margins of +0.26 at PDR can be considered healthy.

4. Development and Validation

To validate the conceptual design of the Sensor Suite, an EDU prototype of the CSS was assembled and integrated for testing. In addition to the two CSE cards and the two Sensors Arrays, each populated with a full complement of LED and PD subassemblies, the testbed includes a ground support rack computer to simulate the communication and power interfaces of the Jettison Avionics. Figure 19 shows the EDU Capture Sensor Suite, with all components integrated into the testbed.

Prior to their integration into the full Sensor Suite testbed, all electronic components underwent verification test campaigns at each stage of integration. The Capture Sensor Electronics cards underwent electrical verification of all onboard circuits. The light output of the LED subassemblies was verified prior to integration with the Sensor Arrays. Similarly, the PD subassemblies underwent electrical verification of the PPA boards and then tested to characterize spectral responsivity across the modulation frequency range.

As of this writing, the full EDU Sensor Suite testbed has been powered on and undergone a basic demonstration of its hardware capabilities. Figure 20 shows an infrared (IR) photo of a demonstration with a full-scale model of the OS in situ.

Planned future testing with the EDU testbed falls into two stages. The first is performance testing of the system to verify that the OS can be detected in any possible configuration. The second stage is environmental testing to demonstrate the system’s compatibility with the thermal, mechanical, and electromagnetic stresses of the mission. Successful completion of this campaign is a requirement for advancing this system’s design maturity ahead of its CDR and the build of the flight system.

5. Conclusions and Future Work

In this paper, the requirements, challenges, and ensuing design of the Capture Sensor Suite were presented. A highly fault-tolerant system, it is designed to detect the Mars Sample Return’s mission Orbiting Sample onboard the CCRS-ERO spacecraft while in low Mars orbit. The EDU hardware build was assembled, passing basic functional checks, and is ready for performance and environmental testing to demonstrate its CDR-level design maturity.