Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Timeline”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,315 records · Page 73

Orion Backup Flight Software

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

Orion↗

Entry Systems Modeling and Ground Testing: Enabling Flight Performance and Risk Reduction

Entry, Descent, and Landing (EDL) comprise a relatively small portion of a mission’s timeline, however, it is typically among the largest risks. Flying through a body’s atmosphere reliably and accurately – from orbit to ground or via aerocapture – is a critical step toward successful in situ exploration. This exhibit will highlight EDL simulation and ground test capabilities, both existing and under development, that could support mission design, risk reduction, and post-flight analysis for Planetary Science mission concepts displayed in the 2023 SMD Planetary Science Technology Showcase.

Entry Systems↗

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile↗

On the paragenetic modes of minerals: A mineral evolution perspective

A systematic survey of 57 different paragenetic modes distributed among 5659 mineral species reveals patterns in the diversity and distribution of minerals related to their evolving formational environments. The earliest minerals in stellar, nebular, asteroid, and primitive Earth contexts were dominated by relatively abundant chemical elements, notably H, C, O, Mg, Al, Si, S, Ca, Ti, Cr, and Fe. Significant mineral diversification subsequently occurred via two main processes, first through gradual selection and concentration of rarer elements by fluid-rock interactions (for example, in hydrothermal metal deposits, complex granite pegmatites, and agpaitic rocks), and then through near-surface biologically mediated oxidation and weathering. We find that 3349 mineral species (59.2%) are known from only one paragenetic context, whereas another 1372 species (24.2%) are associated with two paragenetic modes. Among the most genetically varied minerals are pyrite, albite, hornblende, corundum, magnetite, calcite, hematite, rutile, and baryte, each with 15 or more known modes of formation. Among the most common paragenetic modes of minerals are near-surface weathering/oxidation (1998 species), subsurface hydrothermal deposition (859 species), and condensation at volcanic fumaroles (459 species). In addition, many species are associated with compositionally extreme environments of highly differentiated igneous lithologies, including agpaitic rocks (726 species), complex granite pegmatites (564 species), and carbonatites and related carbonate-bearing magmas (291 species). Biological processes lead to at least 2707 mineral species, primarily as a consequence of oxidative weathering but also through coal-related and other taphonomic minerals (597 species), as well as anthropogenic minerals, for example as byproducts of mining (603 minerals). However, contrary to previous estimates, we find that only ~34% of mineral species form exclusively as a consequence of biological processes. By far the most significant factor in enhancing Earth’s mineral diversity has been its dynamic hydrological cycle. At least 4583 minerals—81% of all species—arise through water-rock interactions. A timeline for mineral-forming events suggests that much of Earth’s mineral diversity was established within the first 250 million years. If life is rare in the universe, then this view of a mineralogically diverse early Earth provides many more plausible reactive pathways over a longer timespan than previous models. If, however, life is a cosmic imperative that emerges on any mineral- and water-rich world, then these findings support the hypothesis that life on Earth developed rapidly in the early stages of planetary evolution

Robert M. Hazen↗

Increasing Cognitive Ability/Reserve Using Software – Pilot (ICARUS-Pilot)

Background: This research study was competitively awarded under the 2022 JSC Innovation Charge Account (ICA) program administered by NASA Johnson Space Center’s Joint Technology Working Group. Study period of performance was May through September 2022, with a maximum allowed procurement budget of $10K. The study sought to quantify and assess the potential benefit of using commercial-off-the-shelf (COTS) cognitive training software to improve cognitive performance in an astronaut-like terrestrial population. Methods: Five volunteer research participants were recruited from the JSC employee population to mimic certain demographic characteristics of the NASA astronaut population (age, education/discipline). Participant cognitive performance was assessed before and after executing eighteen sessions of remote cognitive training executed nominally three times per week using six exercises within an adaptive app-based COTS software package (BrainHQ, Posit Science) on study-provided tablets. Pre- and post-training cognitive performance was measured using internal assessments in BrainHQ as well as Cognition Test Battery (CTB) version ISS B01 v3 (3.0.9-201710021500), an independent software test developed specifically for NASA and used currently in research studies on astronauts. BrainHQ exercises were posited to map well or partially to several CTB sub-tests. Participants provided feedback on their study experience formally via semi-structured interview at the conclusion of testing and informally throughout the study if they encountered issues. Results: The enrolled ICARUS-Pilot study participants generally matched Artemis crew demographic characteristics. Four of five participants have completed study training and assessment activities as of the writing of this abstract. These test participants complied well with desired training session frequency and duration yielding an average cumulative active training duration of 15 hours over an average of 45 days; participants showed 78% average improvement in metric performance for the six trained exercises, with an associated overall 33%ile ranking increase against performance of the entire BrainHQ subscribing population for internal pre/post assessment, agreeing with post-study survey self-reported performance increases. CTB overall feedback scoring, not corrected for learning effects, showed an average of 19% performance improvement across its 10 performance measures over the training period for the completed participants. Detailed analyses will be conducted once participant data collection for the study is complete and the resulting dataset is fully populated. Discussion: These preliminary results provide a positive trend for the effectiveness of the training approach, but further analysis will be needed to establish significance, investigate far transfer, and suggest the needed participant pool size for subsequent efforts to achieve statistically significant outcomes given similar results. The pilot study has already been helpful by allowing the study team to learn a great deal about the capabilities and limitations of the COTS software package that will be reflected in future proposals along with revised timelines for study execution and test participant management. From participant feedback, one common thread regarding the COTS training was that it felt overly repetitive – future proposals should reassess overall training duration, available levels for each trained exercise, and the behavior of the BrainHQ internal scheduler in determining which exercises should be trained and for how long. If the final analysis of this feasibility study ultimately supports it, the study team will recommend further investigation to fully evaluate this potential countermeasure and optimize its implementation. Future proposals would cite this feasibility study’s outcome and would seek to refine the training protocol and obtain statistically significant results for cognitive performance increases as well as retention data.

cognitive training↗

HelioSwarm: The Swarm is the Observatory

HelioSwarm will transform our understanding of space plasma turbulence by being the first-of-its-kind simultaneous, multiscale observatory comprising multiple spacecraft. HelioSwarm was competitively selected under the Heliophysics Explorers Program 2019 Medium-Class Explorer (MIDEX) Announcement of Opportunity. The central powered-ESPA hub spacecraft is co-orbited by eight SmallSat Node spacecraft, together moving through a High Earth Orbit to obtain data in various solar wind regimes. The mission architecture is that of hub-and-spoke, with the larger hub serving as a communications relay between the nodes and DSN. Mission operations, management, and technical oversight are provided by NASA Ames Research Center; the spacecraft are provided by Northrop Grumman and BCT. The instrument suite includes foreign-contributed instruments and U.S. ones, all under the oversight of University of New Hampshire (which is also the Principal Investigator’s home institution and Science Operations Center). The mission timeline from launch through conclusion of the one-year science mission is provided along with a summarized concept of operations, with particular emphasis on placing the nodes in their proper relative orbit loops to form the geometry needed for science collection at apogee. A brief discussion of how a combination of legacy tools and custom-created swarm analysis tools are used to design the swarm and sort and visualize the collected science data and telemetry in context is provided. Finally, an exploration of the pathfinding nature of HelioSwarm and some implications for future large scientific swarms is offered.

Heliophysics↗

Development of A Crew Health and Performance System Probabilistic Risk Assessment Tool: Proof-of-Concept Approach

The crew health and performance (CHP) system represents the span of technological interventions and tested processes and procedures that in combination address the human risk to space flight. The Human Research Program (HRP) mental model of the CHP system breaks the capabilities needed to meet NASA human flight systems standards into specific categories (i.e., countermeasures, behavioral health, medical intervention). These categories are further broken down into specific sub-groups generally associated with the human system risks that these capabilities seek to mitigate. Like the approach used to develop the Integrated Medical Model (IMM) and the Medical Extensible Dynamic Probabilistic Risk Analysis Tool (MEDPRAT), HRP tasked NASA GRC’s Cross-Cutting Computational Modeling Project with developing a CHP probabilistic risk assessment tool, the CHP-PRA. The CHP-PRA model seeks to quantify and relatively assess the human risk state within the crew health and performance domain, using a combination of knowledge about human system risks and technology and practices likely to be applied during space flight missions. This modeling system will incorporate customer and stakeholder feedback and be flexible enough to address multiple different questions about important low-level mission-specific parameters. This presentation will introduce the initial concept and development timeline for this tool and demonstrate proof-of-concept through an application addressing a specific human risk question posed within the Artemis program.

Risk analysis↗

The Big Plunge at Venus: The DAVINCI Descent Phase

DAVINCI (Deep Atmosphere Venus Investigation of Noble gases, Chemistry, and Imaging) was selected as one of two new Discovery missions in summer of 2021 with the primary goals are to study how the Venus atmosphere formed and changed over time. DAVINCI does this by making in situ measurements of the atmosphere and taking images below the cloud layer during the descent phase. The probe is neither designed nor required to land on the surface so all critical science data must be taken and transmitted to a relay spacecraft prior to impact. This architecture drives the mission to a carefully-crafted concept of operations; deployments, instrument operations, and communications are choreographed to ensure the right data is gathered at the right altitude given the uncertainties in the trajectory and timeline. A complex flow of analyses and tests throughout development will validate the system’s ability to execute the mission goals. In the end, DAVINCI will be ready for the one opportunity at one hour of descent time to meet its driving science goals.

DAVINCI↗

Orion Backup Flight Software (BFS)

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

CFS↗

VfOx in GEER: Functional Test of a Venus Oxygen Fugacity Sensor

VfOx, which stands for “Venus Oxygen Fugacity” is the DAVINCI mission’s Student Collaboration Experiment (SCE); a small single- objective sensor used to measure the partial pressure of molecular oxygen in Venus’ lower atmosphere. Through the mission timeline, VƒOx will be designed, fabricated, tested, operated, and results analyzed by undergraduate and graduate students mentored by the DAVINCI team in partnership with Johns Hopkins University and other institutions. The simple principal of VƒOx is a ceramic O 2 sensor derived from common applications, utilizing diffusion of O -2 ions between a standard (PdO) inside the sensor and the target atmosphere measured by a mW level voltage that depends directly on the standard/sample fO 2 ratio. A 60-day environmental test of a prototype design of the sensor was conducted at the Glenn Extreme Environment Rig (GEER) from August to October of 2022, in which VƒOx (Fig. 1) was placed inside the experimental chamber (Fig. 2) and brought to Venus surface temperature (460 °C) and pressure (92 bar) conditions, in a Venus like atmosphere (96.5% CO 2 , 3.5% N 2 ) that included trace gases like SO 2 , maintained by occasional “boosts” of extra gas during the experimental run.

Noam R. Izenberg↗

A Preliminary Assessment of Cognition and Fatigue During Simulated Lunar Surface Extravehicular Activities

Exploration Extravehicular Activity (xEVA), or spacewalks, during NASA’s future Lunar (Artemis) missions are expected to be more physically and cognitively demanding than any previous missions. Characterizing the effects of xEVA tasks and timelines on cognition and fatigue will be valuable, and perhaps essential, to the preservation of crew health and performance during xEVA.

Taylor E. Schlotman↗

APRES Prototype Mission Planner System Demonstration

Activity Planning with Resources for the Exploration of Space (APRES) is a mixed-initiative mission planning system for ground operations. APRES has been designed to support multi-spacecraft missions. The APRES Interface is browser-based and includes a plan editor, a timeline plan display, a temporal constraint editor, display of the state and numeric chronicles, and a violation resolution manager. Automation support is supplied by the APRES Service, which includes components that provide the following capabilities:(1) plan simulation, which determines the state and numeric chronicles (values of the model variables over time) and determines when "processes" are triggered and terminated based on world states in the execution trace, (2) violation detection of constraints and flight rules encoded in the domain model, and of the temporal constraints created by the user, (3) violation resolution suggestions as to how to fix the plan's violations via rescheduling. The user controls when and how to utilize the automation support. Demo video included with paper, runtime 8:54 in color with sound.

John L. Bresina↗

The Role of Trust and Usability in Enabling Spaceflight Crew Autonomy

Future long duration exploration missions will require an increased use of onboard automated systems as spaceflight crews venture further than before and have longer communications delays with ground support. The design of these systems must support appropriate crew trust and have sufficient usability to enable spaceflight crew autonomy or risk being misused while crews wait to communicate with ground support. We evaluated trust & usability in our self-scheduling tool, Playbook, for crew mission timelines. Data was collected in a controlled lab experiment with 31 participants. Participants in the study conducted two tasks: scheduling, where participants were responsible for scheduling a majority of a day's operational tasks, and rescheduling, where participants were provided a schedule and asked to reschedule higher priority activities. We found a significant correlation between system trust and usability, irrespective of self-scheduling tasks. We conclude that system usability may play a bigger role in how trust is learned while conducting novel crew autonomy tasks such as self-scheduling. Future research should investigate the role of usability to encourage appropriate trust in onboard automated crew systems and enable crew autonomy.

crew autonomy↗

Enabling Communication Between Astronauts and Ground Teams for Space Exploration Missions

Over the last four years, Playbook’s Mission Log has evolved to become an enabling capability for analog missions that simulate deep space, exploration missions with communication transmission latency. Playbook is a planning and execution web-application for mission operations, aggregating multiple sources of information for astronauts to execute the mission in one place: timeline, procedures, chat interface. Playbook’s Mission Log provides a multimedia chat software interface with unique features and functionalities that support asynchronous communication between analog astronauts and ground support teams. This paper describes the iterative design the Mission Log has undergone based on user observations and solicited feedback. Key features include indicators that help users cope with asynchronous communication as well as aids that assist teams coordinate work. Future work and capabilities are outlined, which build upon the increased use of the Mission Log as a communication and coordination tool for space exploration.

communication↗

CubeSAT Security Attack Tree Analysis

Once a novelty, small satellites, often referred to as CubeSats, have become important tools for a variety of space activities ranging from exploration to defense. Their relative affordability and short development timeline have made them attractive options to complement larger space vehicles, conduct reconnaissance and other finite tasks. The specialized nature of many CubeSat missions do not make their security any less important as their missions could easily be matters of national security. This paper demonstrates the use of attack tree analysis to assess vulnerabilities of a CubeSat. First, we abstract and build an architectural model of an operational CubeSat. We then create a series of attack trees for the abstracted architecture to illustrate a series of potential attack vectors for small satellites. We conclude by discussing some strategies that could be employed to improve CubeSat resilience.

Santangelo, Andrew↗

Actuator and Motor Control End-to-End V&V on the Mars 2020 Rover

The Mars 2020 Perseverance rover is the most advanced robotic exploration system ever sent to another planet. To support the complex scientific and mobility needs of the mission, the rover utilizes 33 actuators, three multi-degree-of-freedom force-torque sensors, fifteen single or dual-speed resolvers, two solenoid valves, and twelve contact switches. The control for these actuators and sensors is achieved by several levels of flight software, coordinated between two computers with varying bandwidth control loops. Furthermore, the actuators and sensors were integrated into multiple larger robotic mechanisms that were delivered by different organizations at various points in the Integration and Test (I&T) timeline. All of this created a very complex Verification and Validation (V&V) scenario involving multiple subsystems and teams, several hardware and software testbeds with varying levels of fidelity, and significant systems engineering to ensure the overall I&T schedule could be maintained while ensuring system hardware safety.This paper details the integrated V&V effort across multiple teams and venues to provide full coverage of all necessary functionality, performance, and fault protection. First, it provides an overview of how the V&V campaign was subdivided among teams and venues and provides descriptions of the various hardware configurations used to support the testing. The Mars 2020 implementation of the plan incorporates many of the lessons learned from Mars Science Laboratory’s test campaign, and these value-added modifications are discussed here. Also included in this section is the system-level environmental testing approach used for mechanisms. Second, the paper describes the phased approach used by the teams to support new hardware and software deliveries to testbed and Systems I&T. In this approach the test campaign was built upon higher-level mechanism needs for performance, functionality, and safety at specific times in the campaign. Finally, the paper discusses lessons learned from the V&V campaign that should be applied to future large-scale motion control testing efforts.

Borne, Davis↗

Automating Surface Attitude Positioning and Pointing Operations for Mars 2020

The Surface Attitude Positioning and Pointing (SAPP) subsystem of the Mars Perseverance rover keeps track of the rover’s position and attitude on the surface of Mars. The SAPP Downlink Engineering Operations team members receive data from the rover on a daily basis. They must interpret the data to make sure the rover is staying safe and to support uplink planning. The SAPP team keeps track of the error growth in the rover’s attitude estimate due to noise in the Rover Inertial Measurement Unit’s (RIMU) gyroscopes used to propagate that attitude estimate whenever the rover is moving. Whenever this error grows to a particular threshold, SAPP is responsible for updating the onboard attitude knowledge using the RIMU’s accelerometers to estimate rover roll and pitch and sun imaging to estimate rover yaw, thereby reducing this attitude estimation error. Accurate attitude estimation is required so that the rover can successfully point its High Gain Antenna (HGA) to receive information from Earth and as a backup to the Mars orbiters used for sending data from the rover to Earth, point instruments on its Remote Sensing Mast (RSM), and support safe movement and placement of instruments by the rover’s ARM relative to the Martian surface. The Mars 2020 Engineering Operations team has been working to increase the operational efficiency of the mission and eventually move to a five-hour timeline for daily operations. In pursuit of this goal, the SAPP Engineering Operations team has automated their downlink process by developing a centralized Jupyter notebook to analyze the data received daily from the rover. The SAPP downlink Jupyter notebook automatically collects the data relevant to the SAPP subsystem and visualizes this information in plots and tables that can be easily read by downlink operators to aid them in assessing the status of the subsystem. Various Application Programming Interfaces (APIs) have been incorporated into the downlink daily notebook to automate the collection and posting of data, such as gathering and posting data products to the cloud. The SAPP team has also developed a SAPP downlink software library that includes functions to aid the notebook in processing data. In addition to assessing the SAPP subsystem on a daily basis, operators need to assess the long-term trending behavior of the subsystem over time. An automated trending process has been developed to collect information from the daily notebooks in order to plot and analyze that data in a centralized place. These daily and trending processes have expedited the SAPP downlink assessment and laid the groundwork to completely automate the SAPP downlink process so that SAPP operators are unnecessary unless something unexpected occurs. This paper will provide an overview of the functions that the SAPP subsystem carries out on a daily basis, and will then dive into the automations that have been developed for daily and trending downlink assessment. An assessment of the downlink efficiency will be provided, along with a summary of lessons learned and work to go. Finally, the authors will discuss how these types of automated spacecraft health assessments could be more broadly used within mission operations.

Zarifian, Anais↗

Power Operations of the Mars Exploration Rovers

The rovers of the National Aeronautics and Space Administration’s (NASA) Mars Exploration Rovers (MER) project, Spirit (MER-A) and Opportunity (MER-B), safely landed on the surface of Mars three weeks apart during January 2004. Spirit and Opportunity were built and operated by the Jet Propulsion Laboratory (JPL), which is managed by the California Institute of Technology (Caltech) for NASA. Spirit landed at Gusev Crater, 14.8 degrees south of the equator, and operated continuously on the surface of Mars from January 4, 2004 until last contact from Spirit on March 22, 2010. Opportunity landed at Meridiani Planum, a location 2.5 degrees south of the Martian equator. Opportunity operated continuously on the Martian surface from January 25, 2004 until the last received transmission from Opportunity on June 10, 2018. The goal of the MER project was to determine if Mars ever had a habitable environment, in particular, if it ever had water. During their missions, both Spirit and Opportunity found evidence that liquid water once flowed on the surface of Mars. Both Spirit and Opportunity used a 1.33 m2 triple-junction solar array as their power sources. Based on observations of the original Mars rover, the Sojourner rover of the Mars Pathfinder mission that landed on Mars on July 4, 1997, the expectation was that the Martian dust would rapidly accumulate on the solar arrays of Spirit and Opportunity, and that the rovers would not have enough energy to continue operations after 90 Martian days (sols). Instead, due in part to lower dust accumulation rates than expected and numerous dust cleaning events, the Spirit and Opportunity rovers continued to operate on the Martian surface for over 2000 sols (MER-A) and 5000 sols (MER-B), respectively. During this time, the rovers experienced multiple Martian winters and several dust storms. Because the sources of solar array energy loss were known, the solar array energy output offered a method to scientifically estimate the loading and aeolian removal of dust from the solar arrays each sol. The MER Power operations team called this value that they calculated the solar array Dust Factor (DF). Dust Factor was defined as the fraction of sunlight that penetrates the accumulated dust on the surface of the solar array. A Dust Factor of 1.0 would indicate that the solar array was perfectly clean. A Dust Factor of 0.6 would indicate that only 60% of the available sunlight was able to penetrate the accumulated dust on the solar arrays. The MER Power subsystem operations team used the Multi-Mission Power Analysis Tool (MMPAT) to perform these Dust Factor calculations. The MMPAT software tool modeled the behavior of the solar arrays and the batteries as they interacted with the spacecraft power loads over the mission timeline. MMPAT also had knowledge (through telemetry and user inputs) of telemetered Power subsystem voltages and currents, atmospheric opacity (Tau), rover surface location, rover attitude, the planetary tilt and distance of Mars from the sun based on day of year, the instantaneous elevation of the sun based on time of day, temperatures (internal and external), terrain masking, and shadowing (due to the camera mast and antennas). Once all of the known sources of array energy loss are accounted, the remaining difference between the expected array energy and the actual array energy determines the solar array Dust Factor. The assumptions made while determining the Dust Factor are 1) that the single measured atmospheric opacity value (Tau) is constant over the course of the entire sol, 2) there is no measurable solar cell degradation, 3) there are no shorted strings and therefore, 4) all unexpected solar array energy losses are due to accumulated dust on the solar array. Although it cannot provide an absolute measure of dust loading, the determination of solar array Dust Factor provides a useful way of tracking dust accumulation and aeolian dust removal trends on Martian spacecraft. Any spacecraft on the Martian surface is vulnerable to dust, especially solar-powered spacecraft. The Spirit and Opportunity rovers were operational on the Martian surface for much longer than expected due in part to aeolian removal of dust from their solar arrays. The first few dust removal events were a pleasant surprise to the MER operations teams; however, over time a pattern began to arise. In over three Mars Years on the surface, the Power operations team tracked the solar array Dust Factor at Gusev Crater (location of MER-A) and observed that there were several significant dust removal and deposition events in Mars Year (MY) 27, even in the absence of a large dust storm. In MY 28 at Gusev Crater, the large atmospheric opacity (Tau) increase lagged significant dust removal events. Overall at Gusev Crater, there was a pattern of steady dust accumulation on the solar arrays, with a small number of significant dust cleaning events. At Meridiani Planum, where Opportunity rover operated for over seven Mars Years (late MY 26 to mid MY 34), a clear and consistent pattern of dust movement emerged. Meridiani Planum had a predictable, seasonally dependent pattern of gradual and continuous dust accumulation and removal. In summary, this paper explains the reasons for the development of the solar array Dust Factor and how it was used in mission operations. In particular, this paper describes the MMPAT software package, how it models array energy, including the important assumptions, model inputs and sources of error. And finally, this paper will show how the calculated solar array Dust Factor was used at Gusev Crater and Meridiani Planum to predict dust accumulation rates and weather patterns, and the importance of this generated data set for current and future solar- powered missions to Mars, such as the InSight lander and the planned Mars Sample Return rover.

Chin, Keith B.↗