Search NASA⌕ Search

SEARCH · Search NASA

Results for “adaptive control architecture”

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.

495 records · Page 28

Risk of Performance and Behavioral Health Decrements Due to Inadequate Cooperation, Coordination, and Psychosocial Adaptions within a Team

The Risk of Performance and Behavioral Health Decrements Due to Inadequate Cooperation, Coordination, Communication, and Psychosocial Adaptation within a Team (the Team Risk) is primarily performance-focused, with a secondary emphasis on behavioral health outcomes resulting from team performance and interpersonal interactions. Monitoring tools, measures, and countermeasures are aimed at enhancing team processes and team composition configurations to optimize team performance and functioning. Long-duration exploration missions (LDEMs) will include major challenges that could affect team performance, including social isolation, physical confinement, a small and diverse crew, communication delays between crew and ground, limited or no crew rotation or evacuation options, limited or no resupply, and a high-consequence environment. Each of these conditions will affect the crew’s coordination, cooperation, psychological well-being, and performance. Although the International Space Station (ISS) remains important for studies that require spaceflight testing and validation, the current conditions on the ISS do not adequately mimic the exploration environment that is required for National Aeronautics and Space Administration (NASA) teams research, and thus access to terrestrial or ground-based analogs of LDEM conditions is paramount. The emphasis on analogs for research is reflected in this updated evidence review of the Team Risk, and includes data from studies conducted at isolated, confined, extreme (ICE) environments (e.g., Antarctic stations), and from several mission simulation analogs such as the Human Exploration Research Analog (HERA) (HERA Experiment Information Package, 2014), also known as isolated, confined, controlled (ICC) environments. These studies have characterized many team factors regarding LDEMs, and the Team Risk has now matured from risk characterization to focusing more on countermeasure development. Because spaceflight evidence for team-level research is lacking, no reliable data is available to quantify the impact of team-level variables on individual and team-level outcomes during spaceflight missions. Until recently, no systematic attempt had been undertaken to measure the performance effects of team cohesion, team composition, team training, or team-related psychosocial adaptation during spaceflight. The Team Risk is a relatively young research area for NASA, with substantial growth only since the 2000s, and with limited access to spaceflight performance data. As a result, spaceflight evidence is lacking to identify specifically what team composition, level of training, amount of cohesion, or quality of psychosocial adaptation is necessary to reduce the risk of performance errors in space. However, astronaut journals and interviews and reports from spaceflight subject matter experts (SMEs) provide testimonies that team performance during spaceflight is important for mission success and to maintain crew health. Team spaceflight data is now being collected as part of the Spaceflight Standard Measures task (Clement, 2021)—a set of core measurements related to many human spaceflight risks that are collected from astronauts before, during, and after long-duration missions. The team-related standard measures focus on team cohesion, team performance, group living, team climate, and team processes. Collection of standard measures data is ongoing and published data is not yet available. Finally, although spaceflight evidence is lacking, evidence gleaned from ground studies and spaceflight analog studies will help close the gaps outlined in the Team Risk. Ground-based studies provide quantitative evidence for team functioning in ICE environments. Academic research on teams has produced dozens of meta-analyses that can be used to understand the general relationships among team inputs (e.g., team member characteristics and skills, job context), team processes, and emergent states (e.g., coordination, communication, cooperation, cohesion, trust, shared cognition), and team outcomes (e.g., effectiveness, errors, adaptation). Teams are complex, incorporating individual characteristics of team members, but also existing at a level that is greater than the sum of its parts. Therefore, the Team Risk must be integrated with other individual-focused NASA Human Research Program (HRP) risks, including Behavioral Medicine (BMed), Sleep, and Human-Systems Integration Architecture (HSIA), and emerging research indicates more integration may needed between the Team Risk and the physiologically oriented risks. Much of this integration occurs through the Human Systems Risk Board (HSRB). A lack of team functioning may be a stressor in some circumstances, but the team often acts as a countermeasure. For example, support for team leaders and teammates can facilitate individual functioning and encourage psychological and physically healthy behaviors and attitudes. However, more research is needed regarding teams during LDEMs and the remaining gaps in the research are described in the current report.

Lauren Blackwell Landon↗

Probabilistic Modeling of a Three-Stage Human Landing System Architecture

Space Policy Directive-1 has led to NASA partnerships with commercial entities on procurement which includes the development of the Human Landing System (HLS) [1]. With the goal of delivering human crew to the lunar surface by 2024, system uncertainties become an important obstacle to the maturation of multiple new, driving technologies and mission concepts of the HLS program. As unmitigated uncertainties have previously led to failed development programs, these risks and their impacts must be understood and handled to ensure program success [2]. Sources of uncertainty include novel engine designs and configurations, increased reliance on cryogenic fluid management(CFM), and refueling technologies—which propagate as high-level performance metrics such as overall propellant mass and engine performance. Also, the occurrence of operational uncertainties—e.g. launch conditions or need to abort during the mission—can cause cascading effects on the rest of the mission that are difficult to definitively quantify, and are outside the scope of control. These concrete examples and other occurrences can be categorized as either epistemic or aleatory uncertainties.Epistemic uncertainty arises due to a lack of knowledge and can be alleviated with design and program maturation. Aleatory uncertainty is due to the inherent randomness of the system and cannot be directly reduced, unlike epistemic uncertainty. Robust design and probabilistic methods can compensate for aleatory effects. A taxonomy of uncertainty is referred to for this work [3]. In this paper, a probabilistic methodology to handle uncertainties has been demonstrated on a three-element HLS concept [1, 4], which allows tracking of current best estimates of the concept and assessment of concept design robustness against uncertainties. A sample case has been completed for this abstract, and an expansion on the methodology will be included in the final paper. This methodology has two key parts: first, the creation of a dynamic architecture model of a three-element HLS concept; and second, its use with surrogate modeling and range estimating techniques to capture and propagate uncertainties. This abstract will cover the basics of the approach used, and further details and justifications will be in the final paper.The mission profile associated with this three-element concept (Fig 1) was modeled as a set of mission events that facilitated mass changes, idles, or spacecraft maneuvers. The mission profile scope starts with each element’s NRHO orbit insertion and aggregation and ends at post-sortie rendezvous with Orion. More detail on the mission profile will be in the final paper. The DYnamic Rocket EQuation Tool (DYREQT), a space systems synthesis and sizing framework used by NASA, was used as the physics framework to model the HLS architecture for applying the probabilistic methodology [5, 6]. Specifically, a parametric representation of the lander, ascent, and transfer elements and the mission profile of each element was established, with vehicle and mission parameters available as inputs to allow for a dynamic model. Each vehicle stage was modeled with high-level performance metrics, using Isp and propellant mass fraction (PMF) to remain parametric. For the probabilistic analysis, uncertainties of interest within the HLS concept were enumerated and represented as parameters within the DYREQT model as inputs for vehicle stages or mission profile events. These parameters were frozen at their nominal values for the purposes of baselining architecture performance and sizing the vehicle appropriately based on reference documentation [1]. Range estimating—a probabilistic method that combines Monte Carlo sampling, focus on critical parameters, and heuristics to assess risk and opportunities—is traditionally used with Mass Equipment Lists (MELs), but has been adapted with operational parameters as well as vehicle parameters in theDYREQT model to capture mission uncertainty alongside vehicle uncertainty [7, 3]. This method was selected due to its application and insight on a system from a bottom-up perspective, independence from historical rules of thumb, and ability to generate sensitivities based on design decisions and uncertainties. As a sample case for the abstract, the boiloff rates of the vehicle elements and the loiter times during the mission (simulating launch time variations and changing window of opportunities) were used with range estimating to provide preliminary results. To perform the range estimation portion of this methodology (depicted in Fig. 3, further details in final paper), the DYREQT model was sampled using a Design of Experiments (DoE) to efficiently explore the architecture design space with respect to the sample set of uncertainty parameters; 5,000 cases via Latin Hypercube Sampling were computed on the DYREQT architecture model. Then, the results were used to create surrogate models, multivariate regressions that can visualize hypercube trends in the design space, of the architecture with respect to the uncertainty parameters. Range estimating was applied to the surrogates instead of the actual models, which saves computational expense due to the bulk of cases needed for the Monte Carlo simulation as part of range estimating. Uncertainty parameters were sampled independently from triangular distributions using the DoE ranges as ‘min’ and ‘max’, and the nominal value as ‘most likely’. Based engineering intuition, some uncertainty parameters are correlated—e.g. if the main propellant has a high boil-off rate, the oxidizer should follow suit as both are related to CFM technology.While a Monte Carlo simulation samples all inputs as independent, the results would show model correlations; thus, it is efficient to sample the inputs as correlated. Using a correlation matrix constructed for the uncertainty parameters, previously independent samples were transformed to perform a Correlated Monte Carlo. A table for the DoE ranges and probability distribution parameters is shown in Table 1, and more details on Correlated Monte Carlo Simulations will be discussed in the final paper. The model’s resulting DoE showed that multivariate polynomial equations fit via least squares method captured its behavior accurately for the sample case. For the Correlated Monte Carlo Simulation, a positive correlation between fuel and oxidizer boiloff rates was used as a demonstration. 10,000 cases were computed with the surrogates and the launched masses for each vehicle element was collated. The results can be displayed in a probability density function (PDF), showing the impact of the uncertainty parameters chosen. Integrating the PDFs will yield a cumulative distribution function (CDF) that shows the cumulative probability of a given value on the x-axis. For the sample case, the elements’ launch mass margin was calculated and represented in as CDFs, as a demonstrated representation of figures of merit for the HLS concept. For the lander and ascent elements, the NRHO mass insertion limit is 16t; the transfer element has a limit of 30t [1]. It can be seen with Figure 2 that this probabilistic methodology can provide insight into mass margin with respect to the uncertainties being modeled. Currently, the results show that the lander (descent) vehicle element has the most restrictive design space; it is the only element to show a 10% probability of negative margin. Further analysis on the Monte Carlo results will show sensitivities for driving constraints and parameters for architecture feasibility, which can lead to establishing potential mission rules.The combination of range estimating with a parametric architecture model for HLS demonstrated the capability of this probabilistic methodology in a sample case. As the HLS development progresses, this methodology has the potential for keeping current best estimates of architecture performance for awarded concepts due to the flexibility in DYREQT’s modeling framework and its parametric nature. Concept maturation and increased epistemic knowledge can be injected into the model probabilistic modeling, and thus continue to track probability of mission success.

Stephanie Y Zhu↗

Enabling IP Header Compression in COTS Routers via Frame Relay on a Simplex Link

NASA is moving toward a networkcentric communications architecture and, in particular, is building toward use of Internet Protocol (IP) in space. The use of IP is motivated by its ubiquitous application in many communications networks and in available commercial off-the-shelf (COTS) technology. The Constellation Program intends to fit two or more voice (over IP) channels on both the forward link to, and the return link from, the Orion Crew Exploration Vehicle (CEV) during all mission phases. Efficient bandwidth utilization of the links is key for voice applications. In Voice over IP (VoIP), the IP packets are limited to small sizes to keep voice latency at a minimum. The common voice codec used in VoIP is G.729. This new algorithm produces voice audio at 8 kbps and in packets of 10-milliseconds duration. Constellation has designed the VoIP communications stack to use the combination of IP/UDP/RTP protocols where IP carries a 20-byte header, UDP (User Datagram Protocol) carries an 8-byte header, and RTP (Real Time Transport Protocol) carries a 12-byte header. The protocol headers total 40 bytes and are equal in length to a 40-byte G.729 payload, doubling the VoIP latency. Since much of the IP/UDP/RTP header information does not change from IP packet to IP packet, IP/UDP/RTP header compression can avoid transmission of much redundant data as well as reduce VoIP latency. The benefits of IP header compression are more pronounced at low data rate links such as the forward and return links during CEV launch. IP/UDP/RTP header compression codecs are well supported by many COTS routers. A common interface to the COTS routers is through frame relay. However, enabling IP header compression over frame relay, according to industry standard (Frame Relay IP Header Compression Agreement FRF.20), requires a duplex link and negotiations between the compressor router and the decompressor router. In Constellation, each forward to and return link from the CEV in space is treated independently as a simplex link. Without negotiation, the COTS routers are prevented from entering into the IP header compression mode, and no IP header compression would be performed. An algorithm is proposed to enable IP header compression in COTS routers on a simplex link with no negotiation or with a one-way messaging. In doing so, COTS routers can enter IP header compression mode without the need to handshake through a bidirectional link as required by FRF.20. This technique would spoof the routers locally and thereby allow the routers to enter into IP header compression mode without having the negotiations between routers actually occur. The spoofing function is conducted by a frame relay adapter (also COTS) with the capability to generate control messages according to the FRF.20 descriptions. Therefore, negotiation is actually performed between the FRF.20 adapter and the connecting COTS router locally and never occurs over the space link. Through understanding of the handshaking protocol described by FRF.20, the necessary FRF.20 negotiations messages can be generated to control the connecting router, not only to turn on IP header compression but also to adjust the compression parameters. The FRF.20 negotiation (or control) message is composed in the FRF.20 adapter by interpreting the incoming router request message. Many of the fields are simply transcribed from request to response while the control field indicating response and type are modified.

Nguyen, Sam P.↗

Orion Launch Abort System Performance on Exploration Flight Test 1

This paper will present an overview of the flight test objectives and performance of the Orion Launch Abort System during Exploration Flight Test-1. Exploration Flight Test-1, the first flight test of the Orion spacecraft, was managed and led by the Orion prime contractor, Lockheed Martin, and launched atop a United Launch Alliance Delta IV Heavy rocket. This flight test was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety. This test included the first flight test of the Launch Abort System preforming Orion nominal flight mission critical objectives. NASA is currently designing and testing the Orion Multi-Purpose Crew Vehicle (MPCV). Orion will serve as NASA's new exploration vehicle to carry astronauts to deep space destinations and safely return them to earth. The Orion spacecraft is composed of four main elements: the Launch Abort System, the Crew Module, the Service Module, and the Spacecraft Adapter (Fig. 1). The Launch Abort System (LAS) provides two functions; during nominal launches, the LAS provides protection for the Crew Module from atmospheric loads and heating during first stage flight and during emergencies provides a reliable abort capability for aborts that occur within the atmosphere. The Orion Launch Abort System (LAS) consists of an Abort Motor to provide the abort separation from the Launch Vehicle, an Attitude Control Motor to provide attitude and rate control, and a Jettison Motor for crew module to LAS separation (Fig. 2). The jettison motor is used during a nominal launch to separate the LAS from the Launch Vehicle (LV) early in the flight of the second stage when it is no longer needed for aborts and at the end of an LAS abort sequence to enable deployment of the crew module's Landing Recovery System. The LAS also provides a Boost Protective Cover fairing that shields the crew module from debris and the aero-thermal environment during ascent. Although the Orion Program has tested a number of the critical systems of the Orion spacecraft on the ground, the launch environment cannot be replicated completely on Earth. A number of flight tests have been conducted and are planned to demonstrate the performance and enable certification of the Orion Spacecraft. Exploration Flight Test 1, the first flight test of the Orion spacecraft, was successfully flown on December 5, 2014 from Cape Canaveral Air Force Station's Space Launch Complex 37. Orion's first flight was a two-orbit, high-apogee, high-energy entry, low-inclination test mission used to validate and test systems critical to crew safety, such as heat shield performance, separation events, avionics and software performance, attitude control and guidance, parachute deployment and recovery operations. One of the key separation events tested during this flight was the nominal jettison of the LAS. Data from this flight will be used to verify the function of the jettison motor to separate the Launch Abort System from the crew module so it can continue on with the mission. The LAS nominal jettison event on Exploration Flight Test 1 occurred at six minutes and twenty seconds after liftoff (See Fig. 3). The abort motor and attitude control motors were inert for Exploration Flight Test 1, since the mission did not require abort capabilities. A suite of developmental flight instrumentation was included on the flight test to provide data on spacecraft subsystems and separation events. This paper will focus on the flight test objectives and performance of the LAS during ascent and nominal jettison. Selected LAS subsystem flight test data will be presented and discussed in the paper. Exploration Flight Test -1 will provide critical data that will enable engineering to improve Orion's design and reduce risk for the astronauts it will protect as NASA continues to move forward on its human journey to Mars. The lessons learned from Exploration Flight Test 1 and the other Flight Test Vehicles will certainly contribute to the vehicle architecture of a human-rated space launch vehicle.

McCauley, R.↗

Supervisory Control with Dual Tasking in Post G-Transition Vehicle Landings

BACKGROUND Landing during exploration spaceflight may consist of both planned automated supervisory control and unplanned crew override. Supervisory control, particularly when performed under cognitive load with additional monitoring tasks, is essential for ensuring overall mission success during landing contingencies. Evaluating performance in a relevant Human Landing System (HLS) supervisory landing task after long-duration microgravity exposure can help identify potential risks from human error and sensorimotor alterations. Adaptive changes in the sensorimotor system can manifest during g-transitions as spatial disorientation. Although training and landing aids facilitate successful landings despite disorientation, these adaptive changes may heighten cognitive demand, which must be considered in the landing strategy. It is important to characterize these effects as soon as possible following the G-transition while the sensorimotor system remains in a state of adaptive flux to inform appropriate countermeasures. METHODS A Multi-attribute Lunar Table Battery (MALTB) task was developed for an iOS tablet device to provide flexible crew testing and training capabilities in-flight and on the ground. Elements of the tablet task were derived from the Multi-Attribute Task Battery (MATB, Cegarra et al. 2020). The task requires crew members to study a map of a planned landing site and memorizing the terrain and surface landmarks to inform potential divert maneuvers during landing. The user will oversee a series of approaches through touchdown simulations on the tablet with an external camera view of the Lunar surface. The primary responsibility of the crew member will be to execute a divert if the guidance recommended site is erroneous (e.g., the guidance projected landing target is not within 10m of the planned landing site center), or the projected landing site is no longer suitable due to surface obstacles. Considering vehicle maneuverability and fuel reserves, the divert capabilities will diminish as the task progresses. In cases where a divert is initiated, a new landing target will need to be designated by the user and will be evaluated for the proximity to the original pre-planned site. A secondary operational monitoring task will challenge the user's cognitive reserve by requiring the user to maintain several gauges within acceptable limits and respond to a visual indicator while completing the landing approach. Outcome measures include distance from the planned landing site to the user-initiate divert landing location, ground slope at the new landing site, time to divert, the ability to accomplish the secondary monitoring tasks, and perceived workload. The tablet task is being evaluated in a ground-based study to determine the learning effect of first-time users. The tablet task will be utilized in a flight study to test performance multiple times postflight. Future potential testing in-flight have been identified for capsules with iOS tablet devices. Multi-attribute Lunar Table Battery Task MALTB comprises video footage of thirty distinct landing conditions. The landing scenarios feature various landing sites (n = 3), hazardous object sizes (n = 6), sun azimuth degrees (n = 4), camera modes (i.e., fixed or gimbaled), and navigation bias (i.e., true or false). Each seventy second trial uses a sixty-degree constant glideslope trajectory. The application architecture and layout include user identification setup and data storing, a guided walkthrough of the task and interface components, practice mode for task familiarization, and a modified Bedford workload scale administered following task completion. The time-based dependent measures are saved locally to the iOS Files application and post-processing scripts have been developed to evaluate the remaining measures of performance. RELEVANCE This project will deliver an operational demonstration of crew monitoring capability following spaceflight and identify potential deficits that may require remediation. Comparison of individual vestibular and cognitive changes with crew performance will help better characterize the landing risks associated with sensorimotor alterations. ACKNOWLEDGEMENTS: This project is funded by NASA’s Human Research Program Human Health Countermeasures Element. REFERENCES Cegarra J, Valery B, Avril E, Calmettes C, Navarro J (2020) OpenMATB: A Multi-Attribute Task Battery promoting task customization, software extensibility and experiment replicability. Behav Res Methods 52:1980-1990 doi: 10.3758/s13428-020-01364-w

Matthew McDonnell↗

Grid-Connected Modular Soft-Switching Solid State Transformers (M-S4T)

The objective of this project is to develop and verify the concept of a flexible and modular soft-switching solid-state transformer (M-S4T) for direct grid-connected applications. The ability to directly connect power electronics converters to the medium voltage grid (4 kV – 13 kV), and to potentially replace the passive and bulky, but ubiquitous 60 hertz service transformer in the 25 kVA to 100 kVA range, with a more flexible and controllable device, has been regarded as the ‘holy grail’ in grid control. However, this has proven to be extremely difficult. This project has developed the solutions to several key challenges of the direct grid-connected power electronics and realized a 7.2 kV M-S4T prototype. First, a protection method to protect the M-S4T from the high voltages (110 kV for the 13 kV system) that occur on the grid due to transients and lightning strikes have been developed and experimentally verified. Second, the realization and the operation of the M-S4T based on high-voltage SiC devices (>3.3 kV) and a medium-frequency medium-voltage low-leakage transformer in a single-stage solid-state transformer with zero-voltage switching, low dv/dt, and low electromagnetic interference has been successfully demonstrated up to 7.5 kV peak. Third, an oil-cooling system and stable communication and distributed control system for converter module voltage sharing have been developed and experimentally verified. The developed M-S4T has realized a modular universal high-performance power conversion system. This conversion system is scalable to different voltage and power levels and adaptable to four-quadrant bidirectional operation. Moreover, the use of passive cooling techniques meets the equipment life requirements, and the lightning protection scheme fulfills the basic insulation level specifications for direct grid connection. Such power conversion system opens up near-term opportunities, including energy storage, solar PV, or electric vehicle charging with significant cost and footprint savings. In the longer term, the possibility of replacing the utility distribution transformer with an M-S4T will be transformative for future distribution grids with a compact footprint and full controllability to enable high renewable energy and storage penetration. In addition to the main project, this report expands on the Plus-Up projected including as part of the main award. This project developed and demonstrated the technology for autonomous collaborative inverters that can be connected in an ad hoc manner to the grid. The aim of the project was to: (1) evaluate the existing techniques for grid-connected inverters and find their limitations; (2) develop detailed requirements for grid-connected inverters in the modern grid with millions of active nodes; (3) design a unified control strategy that brings more autonomy and intelligence to grid-connected inverters, and addresses parts of the issues with the existing techniques. The proposed technique, called UniCon, enables inverters to 1) connect/disconnect to/from the grid in an ad hoc manner; (2) work based on local sensing. Slow communication could be used for a more optimized behavior; (3) work automatically in both grid-forming/grid-following mode; (4) handle large disturbances, e.g., big load step and fault, in an oscillation-free manner; (5) work collaboratively with other inverters in steady-state and during transients. UniCon can be implemented in the middle-level control; hence it is agnostic to the vendor and to the implementation of the inner voltage/current and protection loops. Furthermore, a new synchronization scheme, based on deep learning, was developed that can extract the grid voltage phase and amplitude in a stable manner. The method is cheap to implement can improve the dynamic performance of the grid-connected inverters during fast transients, e.g., fault. The proposed control scheme was validated by (1) MATLAB/Simulink; (2) hardware-in-the-loop results, and; (3) experimental results using three inverters that form a microgrid in a down-scaled feeder. Lastly, both the M-S4T and UniCon have achieved promising tangible paths to markets. In the case of the M-S4T, the underlying technology — the Soft Switching Solid State Transformer (S4T) developed at the Georgia Tech Center for Distributed Energy (GT-CDE) has been licensed by GridBlock from the Georgia Tech Research Corporation, and GridBlock has been working with manufacturing partner Jabil (one of the largest US-based contract manufacturers) and system integrator Power Secure (largest deployer of microgrids in the US with 4.7 GW under management), to meet the strong initial demand. Similarly, GridBlock has an exclusive license to the UniCon technology, developed under this award by GT-CDE. The UniCon provides an intermediate control layer that enables the implementation of the higher-level ‘transactive’ control commands for the system. The architecture of the system - slow communications with the cloud for system optimization and setpoints, and the use of locally measured quantities for real-time control, provide a very robust and secure way of implementing a real-time must-run grid that is also secure and stable. This is a brand-new functionality that is critical for the future grid and key to GridBlock’s business model.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗

Automating Trend Analysis for Spacecraft Constellations

Spacecraft trend analysis is a vital mission operations function performed by satellite controllers and engineers, who perform detailed analyses of engineering telemetry data to diagnose subsystem faults and to detect trends that may potentially lead to degraded subsystem performance or failure in the future. It is this latter function that is of greatest importance, for careful trending can often predict or detect events that may lead to a spacecraft's entry into safe-hold. Early prediction and detection of such events could result in the avoidance of, or rapid return to service from, spacecraft safing, which not only results in reduced recovery costs but also in a higher overall level of service for the satellite system. Contemporary spacecraft trending activities are manually intensive and are primarily performed diagnostically after a fault occurs, rather than proactively to predict its occurrence. They also tend to rely on information systems and software that are oudated when compared to current technologies. When coupled with the fact that flight operations teams often have limited resources, proactive trending opportunities are limited, and detailed trend analysis is often reserved for critical responses to safe holds or other on-orbit events such as maneuvers. While the contemporary trend analysis approach has sufficed for current single-spacecraft operations, it will be unfeasible for NASA's planned and proposed space science constellations. Missions such as the Dynamics, Reconnection and Configuration Observatory (DRACO), for example, are planning to launch as many as 100 'nanospacecraft' to form a homogenous constellation. A simple extrapolation of resources and manpower based on single-spacecraft operations suggests that trending for such a large spacecraft fleet will be unmanageable, unwieldy, and cost-prohibitive. It is therefore imperative that an approach to automating the spacecraft trend analysis function be studied, developed, and applied to missions such as DRACO with the intent that mission operations costs be significantly reduced. The goal of the Constellation Spacecraft Trend Analysis Toolkit (CSTAT) project is to serve as the pathfinder for a fully automated trending system to support spacecraft constellations. The development approach to be taken is evolutionary. In the first year of the project, the intent is to significantly advance the state of the art in current trending systems through improved functionality and increased automation. In the second year, the intent is to add an expert system shell, likely through the adaptation of an existing commercial-off-the-shelf (COTS) or government-off-the-shelf (GOTS) tool to implement some level of the trending intelligence that humans currently provide in manual operations. In the third year, the intent is to infuse the resulting technology into a near-term constellation or formation-flying mission to test it and gain experience in automated trending. The lessons learned from the real missions operations experience will then be used to improve the system, and to ultimately incorporate it into a fully autonomous, closed-loop mission operations system that is truly capable of supporting large constellations. In this paper, the process of automating trend analysis for spacecraft constellations will be addressed. First, the results of a survey on automation in spacecraft mission operations in general, and in trending systems in particular will be presented to provide an overview of the current state of the art. Next, a rule-based model for implementing intelligent spacecraft subsystem trending will be then presented, followed by a survey of existing COTS/GOTS tools that could be adapted for implementing such a model. The baseline design and architecture of the CSTAT system will be presented. Finally, some results obtained from initial software tests and demonstrations will be presented.

Davis, George↗

Uncrewed Lunar Surface Operations and Support Activities

Sustained human presence on the surface of the Moon and future missions to Mars require increased independence from surface crews and Earth-based mission control to operate efficiently, safely, and reliably. The time for surface crews to perform tasks will be limited. Extravehicular activities by surface personnel are burdensome and time-consuming, even when a continuous human presence on the surface occurs. Identifying and balancing human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle will be essential to achieve mission objectives. Among these objectives are attaining a sustained human presence, improving performance and mission effectiveness, reducing operations and maintenance (O&M) costs, and ensuring operations that are robust to communication delays. To achieve these objectives, an operational shift toward increased automation and autonomy with less reliance on humans is needed. Uncrewed lunar surface operations and support activities occur when surface crews are not present or are independent of surface crew timeline activities requiring no surface crew oversight or intervention. These uncrewed surface opportunities can also be planned to minimize crew workload that avoids routine maintenance and support tasks, thus maximizing crew exploration time. Uncrewed preparations such as staging and prepositioning equipment and materials before the crew arrives could improve crew task efficiency. Additional opportunities exist to conduct uncrewed science, exploration, and utilization. Uncrewed surface architecture functions can include science and exploration; habitation; launch and landing support; surface communication and navigation; surface power generation and distribution; human surface mobility; lifting, handling, manipulating; excavation, construction, and site preparation; logistics management; maintenance and repair; surface resource utilization; integrated site operations and shared support services (e.g., site scheduling/prioritization, dust mitigation/contamination control, and surface safety). Early robotic lunar surface campaigns will provide information on the availability of resources, such as oxygen and water, and demonstrate surface-based technologies. After the Artemis III human lunar return mission, a series of landers will deliver surface systems, cargo, supplies, science packages, spare parts, and commodities. A balance of crewed and uncrewed surface operations will enable a sustained lunar surface presence at the South Pole of the Moon at a site that will be known as the Artemis Base Camp (ABC). It is envisioned that base camp operations on and around the Moon will then help prepare for the mission durations and activities needed to support the first human mission to Mars. Before long-duration crew missions to the base camp can occur, the necessary surface infrastructure will be pre-deployed and verified operational. Surface assets will be teleoperated and remotely managed from Earth. Additionally, robotic and short-duration crewed missions to the ABC will ensure the site’s merit to achieve long-term science objectives, availability of usable resources, and that terrain, seasonal variations, and illumination conditions are acceptable. ABC will consist of different areas where specific functions and services are rendered, including: • Launch and Landing Area • Habitation Area • Power Production Area • Resource Areas Launch and Landing Area—The launch and landing area will support associated functions for the arrival and departure of vehicles, such as crewed landing and ascent and uncrewed cargo deliveries and offloading. It will evolve from an unimproved site at the beginning of the exploration campaign to a more sustainable landing and launch area that can support repeated arrivals and departures. Initial uncrewed Lunar Terrain Vehicle (LTV) surface operations may include emplacement of navigation beacons and communication equipment, real-time video and photography of landing/liftoff events, and element repositioning, such as portable utility power (PUP) (applicable for other landed assets at other areas). Site preparations, such as surface leveling, soil compaction, and berm/path construction, may be needed for a more sustainable launch and landing area capable of accommodating vehicles that are increasingly more reusable and reduce the effects of plume surface interactions and ejecta impacts on nearby surface assets. During the ABC missions, cargo and logistics will be delivered to the lunar surface via robotic cargo landers before the crew arrives. These shipments, which can arrive in pressurized logistics carriers, will deliver the logistics necessary to support a crewed mission and include items such as food, water, equipment spares, etc. Providing the capability to retrieve, offload, and transport the logistics closer to the ABC site before the arrival of the crew will increase the overall efficiency of crew operations once they arrive. In the sustained phase of exploration, other supporting services may be needed, such as lander propellant servicing, surface power services, commodity refreshes, and additional inspection, maintenance, and repair capabilities, to sustain a cadence of extended personnel stays and cargo arrivals and departures. Habitation Area—Uncrewed support to surface habitation could involve supporting activation and pre-entry operations of the habitat while the crew is in orbit at the Gateway outpost preparing for a surface landing. Surface Habitat (SH) uncrewed operations may include bringing the cabin environment to a habitable temperature and air mix and activating other critical crew support systems. Potential crop production uncrewed tasks in the SH could also include autonomous watering and tending. Additionally, when the crew departs, the SH enters dormancy for the long period of uncrewed operation. A logistical staging area could also be collocated near the SH. If so, staging operations for crew supplies, waste re-location, and recycling operations may be opportunities for uncrewed operations. Power Production Area—The Fission Surface Power (FSP) element and its supporting distribution equipment provide power to surface elements as needed across the ABC to supplement day-to-day operations and survive lunar nights. Uncrewed support of this power system includes any initial LTV-assisted deployments of cables and other distributed equipment, associated electrical connections, and system testing and activation operations. Robotically performing some inspections, maintenance, or repair tasks on the power distribution equipment could reduce the surface crew workload. Resource Area— Uncrewed resource prospecting, mapping, and characterizing possible resource sites is likely to be time-consuming and represents an opportunity for uncrewed operations between crewed missions. Uncrewed mobile equipment operations will be needed in the extreme environments of permanently shadowed locations where resource extractions occur. As In-Situ Resource Utilization (ISRU) pilot plant operations begin, uncrewed surface support activities with available mobile and portable assets (LTV, PUP, etc.) will better support these operations. Any produced commodities can be stored at a centralized storage location for future use. Also associated with these operations is the use of mobile robotic excavators for resource acquisition and robotic/autonomous regolith processing. The waste tailings generated during excavation and regolith processing would also need to be transported and deposited at a dedicated location. Surface assets will continue operating between crew visits to maintain surface capabilities, conduct lunar surface science, technology demonstrations, and public outreach opportunities. Additionally, certain sustaining tasks that would consume valuable crew time could be performed before crew arrival, or after their departure. This capability may offer more affordable options to construct, activate, test, and maintain a broad set of surface assets. Telerobotically operated human surface mobility systems, such as the LTV and Pressurized Rover (PR), can be utilized for various tasks. Surface environmental conditions pose a distinct challenge for all these activities. Surface illumination and localized shadows are one such factor. Night-survival operations could consist of thermal management, battery pre-charging, and load shedding. Some surface systems may hibernate through the night and then awake and continue nominal operations. Uncrewed mobile assets may use a more adaptive approach to optimize their power and operations; one method is to follow the sunlight. Night-survival operations may be initiated remotely by teleoperation, automated, or accomplished by supervised autonomous operation. The ability to pre-deploy and control remote assets in orbit or on Mars before the arrival of the mission crew is a key capability that can be simulated on the moon. The base camp provides a venue where these advanced operational concepts, technologies, and autonomous methods and techniques, including the incorporation of time delays to simulate Earth-Mars latency can be replicated to help buy down future Mars mission risks. This paper will examine the evolution of uncrewed lunar surface operations and support activities. It will also discuss the lunar surface environmental conditions (thermal, lighting, terrain, topography, communications) along with the challenges they pose on uncrewed surface operations, and the performance of these activities with limited to minimal human interaction and/or teleoperation. Since lunar missions include Mars mission analogs, such investigation provides the framework for future uncrewed Mars mission support.

Mark E Lewis↗