Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Execution”

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,513 records · Page 84

A Sampling-Based Optimization Approach to Handling Environmental Uncertainty for a Planetary Lander

Planning for unknown environments presents a number of technical challenges. The planner must ensure robustness to unknown phenomena and manage unpredictable variation in execution, all while operating in a capacity that maximizes its objective. Productivity in the face of these challenges re-quires an integrated approach to planning and execution that is capable of accomplishing goals, reacting to variation, and maximizing overall utility. We examine this problem in the context of a Europa Lander concept mission. We model the problem as a hierarchical task network, framing it as a utility maximization problem constrained on a depletable energy resource. We propose an uncertainty–sensitive deterministic planning framework that utilizes periodic replanning to better handle model uncertainty and variable execution. We demonstrate the efficacy of our framework through simulations of a Europa Lander concept mission in which our algorithm out-performs several baseline approaches in both utility maximization and robustness

Chien, Steve↗

Should’ve Could’ve: Progress in the Systems Engineering of the Mars2020 On-Board Planner

Mars rover operations has traditionally controlled behavior using meticulously compiled, so-called “Master” sequences that enforce deterministic timing and ordering of activities. While the approach is effective at managing risk and complexity, it can also be inefficient. Extended operations of the Mars2020 rover envisions a fundamentally different scheduling and execution approach. Atomic activities are constrained by mission operators in time, resource usage, and a structure of dependencies. The rover flight software will create and re-create schedules, responding to available energy, data volume, actual activity durations and execution status, observed temperatures, and other on-board state. Schedules are expected to change substantially in the course of execution. The solution space is prohibitively large and probabilistic in nature. A range of emergent behavior is accessible depending on the interaction between actual on-board state and a given formulation of constraints. For years, the specification and implementation of this capability have been considered and refined, as testing and analysis have mapped the contours of the system. Many concepts that could have been adopted were rejected, and in some cases, emergent properties have been exposed and beaten back with approaches to steer the behavior. This paper discusses some of the design history and underlying reasoning in the systems engineering of the first autonomous activity planner on Mars.

Kuhn, Stephen R↗

Lila: Optimal Dispatching in Probabilistic Temporal Networks using Monte Carlo Tree Search

Executing a Probabilistic Simple Temporal Network (PSTN) amounts at scheduling, i.e. \textit{dispatch}, a set of events under time uncertainty. This constitutes a NP-hard online optimization problem. The right execution time must be dynamically assigned to each event of the PSTN such that the temporal constraints are met, whereas activity durations are progressively observed as the execution unfolds. We propose a dispatching algorithm based on Monte Carlo Tree Search, called Lila, with the following characteristics: (i) it is an anytime algorithm, both offline and online, proven asymptotically optimal; (ii) it returns the current probability of success, either before or at any moment during operations; (iii) it handles any possible continuous or discrete, even non-parametric, probability distributions, as well as inter-dependencies between random variables, exogenous and endogenous uncertainty; and (iv) can be easily extended to handle probabilistic external events, PSTNs with resources, PSTNs with cutoff times and precondition chains, etc. Lila is universal in the sense that it can handle any dispatching protocol, simply by specifying it to the algorithm. It has the unlimited flexibility offered by the simulation paradigm, whilst it asymptotically converges to optimal decisions and/or robustness approximations.

Chien, Steve A.↗

Mars 2020 Perseverance Rover Surface Operations Commissioning Phase Overview

This paper presents work done by the Mars 2020 Project to plan, test, and execute the Mars 2020 Perseverance Rover surface operations commissioning phase. Immediately after the successful landing of Mars 2020 Perseverance rover at Jezero Crater on February 18, 2021, the rover autonomously initiated mission critical commanding necessary to transition the vehicle from a Cruise/EDL to Surface operations configuration. This began the surface operations commissioning phase, referred to as Surface Operations Transition (SOX). The objective of SOX phase is to establish vehicle health and safety and to verify that the operational characteristics of the vehicle, now operating in the Martian environment, are as-expected and safe to proceed into nominal operations. The SOX commissioning phase is organized into six logical sub-phases occurring in the following chronological order; (1) SOX1a, (2) FSW Transition, (3) SOX1b, (4) SOX2a, (5) Heli, (6) SOX2b. In total, the SOX commissioning phase was expected to take up-to 111 sols (Martian days). The Perseverance rover is an extremely complex, highly-integrated, robotic system-of-systems that requires numerous activities to incrementally and methodically verify their safe operations. This paper will discuss the development process used to plan, test, and execute the SOX commissioning phase for Mars 2020 Perseverance rover surface operations. We will discuss key challenges associated with SOX development as well as actual operations execution experience.

Koch, Justin↗

Assurance Equations: A Cost and Criticality Model for Optimizing Quality Assurance Surveillance

The cost of quality vs cost of failure correction has been a long-running topic of discussion within the Aerospace community. It leads directly to concepts of “risk tolerance”, and risk-based decision-making. It would be valuable if there was a way to compute the optimal investment in customer-executed quality assurance activities using defect significance with respect to performance objectives, the activities’ defect detection effectiveness, and the cost-penalty for late discovery of impactful defects. This optimization is particularly of interest to projects whose budget constraints significantly limit their risk management options.The cost to fix defects (i.e., failure correction) escalates as the project matures. There have been studies attempting to determine the relative cost of fixing defects discovered during various phases of a project life cycle with important implications, all of which suggest growth factors are large. The commonly referred to 1:10:100 rule represents a cost multiplier for repair/rework across the Design to Fab to Test hardware development phases. Cost premiums for QA activities also accumulate when they are treated as mandatory (due to schedule drag) or are performed later than their assigned phase.This paper describes the modeling of development phase -dependencies in the conduct of typical customer-executed quality assurance activities. Our initial modeling encompasses:• Distinct phases of the production lifecycle• Multiple kinds of Defects, each with some a-priori likelihood of being present• Each defect’s impact on performance Objectives for a type of hardware• The cost and efficacy of assurance techniques at detecting such Defects• The costs of fixing those Defects detected in a given phase of the production lifecycleThe model captures assurance activities’ abilities to Detect defects. Upon detection it is assumed that the Defect is immediately fixed. Defects that “escape” detection by some activity may thereafter be detected by a later activity, but by then the cost of fixing the Defect may have escalated. Defects are related to the performance Objectives they would detract from, were those Defects to remain present in the operating system.We have constructed and are exploring, a model that relates the importance of hardware system elements to mission objectives, the impact of types of Defects on those hardware types, the cost of customer-executed assurance activities (i.e., supplier controls) and their effectiveness towards reducing an impactful quality escape, and the cost of Defect correction across production phase. We describe the approach taken to select the key model aspects, why they are relevant to our NASA mission, and our efforts to populate it with relevant and contemporary data. We use a notional example to illustrate model design and function.

Plante, Jeannette↗

Enterprise Mission Integration for Artemis Lunar Missions

Mission integration is an iterative process by which a specific mission is formulated, refined, planned, and executed within the established vehicle(s), architecture, and ground systems design. Mission integration includes the people, vehicle(s) and ground hardware/software, products, processes, analyses, schedules, facilities, Certification of Flight Readiness, etc. The Artemis Mission Integration Task Team (MITT) developed a series of products and processes to support the complex mission integration across various Programs within the Artemis Mission Campaign (Orion, Space Launch Systems, Exploration Ground Systems, Gateway, Human Landing System, and Extravehicular Activity and Human Surface Mobility). The Moon to Mars (M2M) Program is referred to as ‘the enterprise’ as it includes both the M2M organization and the Programs supporting the Artemis Mission Campaign. Artemis Mission Integration has five phases: mission capability, mission definition, mission preparation, mission execution, and post-mission assessment. This paper focuses on one of the enterprise-level mission checkpoints as a kick-off to the Mission Preparation phase, the Mission Integration Review (MIR), which occurs 18-24 months prior to launch. The MIR helps to confirm the defined mission technical baseline is within the existing analyzed design envelope. Details are provided on the identification of dependencies, issues, or gaps for mission-specific objectives and requirements, as well as the definition of the analysis, training, mission execution products, facilities, and detailed supporting operations requirements. The MIR was held for both Artemis I and II and this paper aims to share with the aerospace community its value as we prepare for upcoming Artemis Missions.

Mary Anne Plaza↗

ARRISTOTLE Simulation Demo

NASA’s Katherine Johnson Independent Verification and Validation (NASA IV&V) Jon McBride Software Testing and Research (JSTAR) laboratory has developed the Advanced Risk Reduction Integrated Software Test and Operations Tri-program Lightweight Environment (ARRISTOTLE). ARRISTOTLE is a digital twin of NASA’s Artemis mission. ARRISTOLE executes the true SLS and Orion flight binaries integrated on a single laptop computer. This demo will showcase the execution of the full Artemis liftoff. Once airborne, an inflight anomaly will be injected, resulting in Orion detaching from the booster. The Launch Abort System (LAS) will safely bring Orion back to earth. The Unity game engine is used to visualize the flyout as flight software executes.

emulation↗

Information Systems for Crew-Led Operations Beyond Low-Earth Orbit

On past and present human space missions, the management of vehicle health and status has primarily been executed from Earth. Missions such as Apollo, Space Shuttle, and ISS have relied on a safety net of ground-based experts with access to real-time telemetry data, broad and deep systems expertise, and powerful analytical and computing capabilities. The ground team monitors and manages the vehicle’s health in real-time and responds quickly to critical situations and malfunctions. Ground operators also provide real-time oversight and verbal guidance to flight crew members, especially during complex procedure execution and high-risk activities like extra-vehicular activities. However, this operational paradigm, in place for 60 years, will not transfer to long duration exploration missions beyond low Earth orbit (LEO). Lunar and deep-space crewed missions will encounter delayed communications that prohibit real-time operational and medical support. Additionally, there will be infrequent resupply and a diminished capacity to evacuate or rescue crew members. A small crew must operate independently, managing the vehicle’s state, responding to time-critical events, and executing complex procedures, all without the safety net of real-time support.

data representation↗

Hierarchical Semantic Frames for Grounding Language in Robot Control Primitives

As robots become increasingly present in human environments, we need robots to be intuitively commanded by and effectively communicate with humans. In particular, non-expert users should be able to communicate task goals with robots. Language emerges as a logical mode of interaction due to its ubiquity in human environments and, more importantly, as the way humans naturally express tasks. Natural language commands present challenges in that robots must reason over ambiguous language probabilistically and reason over commands they may not be able to execute. We present hierarchical semantic frames , which ground commands in robot control primitives through hierarchies that construct high-level commands from lower-level commands. We demonstrate that hierarchical semantic frames allow robots to understand and execute a variety of commands, such as those involving multiple verb meanings, command variations, and compound nouns. The robot quickly processes hierarchical semantic frames and accurately grounds and executes the commanded tasks, demonstrating the power of hierarchical semantic frames for allowing users to intuitively interact with robots.

Emily Sheetz↗

NASA Small Spacecraft Technology (SST) Program - Recent and Upcoming Technology Demonstrations and Development Efforts

The Small Spacecraft Technology program within NASA’s Space Technology Mission Directorate, expands the ability to execute unique missions through rapid development and demonstration of capabilities for small spacecraft applicable to exploration, science, and the commercial space sector. Through targeted development and frequent in space testing, the program: • Enables execution of missions at much lower cost than previously possible • Substantially reduces the time required for development of spacecraft • Enables new mission architectures through the use of small spacecraft • Expands the reach of small spacecraft to new destinations and challenging new environments • Enables the augmentation of existing assets and future missions with supporting small spacecraft. The program achieves its objectives through: • Identification and investment in the development of new subsystem technologies to enhance or expand the capabilities of small spacecraft • Sponsorship of flight demonstrations of new technologies, capabilities and applications for small spacecraft • Promotion of the use of small spacecraft as platforms for testing and demonstrating technologies and capabilities that might have more general applications in larger-scale spacecraft and systems Program-funded projects may be executed at academic institutions, in the private sector, at NASA Centers, as public-private partnerships, or cooperative agreements.

SST↗

Recommendations on Evidence and Process for Certification of Learning-enabled Components in Aerospace Systems

This report primarily identifies a collection of relevant and necessary evidence for assurance of machine learnt components (MLCs)—also known as learning-enabled components—integrated into aircraft systems, and gives preliminary suggestions on the elements of a certification process that invoke the identified evidence. The main focus is on feedforward neural networks that are static and trained offline through supervised learning. A brief background on the generic elements of the lifecycle of an MLC is given to contextualize the assurance considerations and, consequently, the evidence that is relevant and necessary to support certification. At the level of an MLC, those considerations relate to: (i) the consistency and correctness of MLC contributions to system functions in the context of a validated functional intent; and (ii) the absence of MLC contributions to aircraft-level failure conditions. At an ML model level, confidence in model and data properties contribute to assurance of the containing MLC, in particular: (a) generalizability and robustness of models, in the presence of inputs not previously seen during training, disturbances to inputs, and unexpected inputs; and (b) valid data, i.e., data that are at least representative, relevant, complete, and accurate. Evidence for the above span the elements of the ML lifecycle, and includes, at a minimum, lifecycle artifacts that pertain to: (1) properties of requirements capturing functional intent, safety constraints, and aspects of the intended use and operating environment; (2) model performance, model complexity and design, and algorithm choice; (3) achievement of required performance at the levels of a trained model during model development, a trained model after model development is complete, and a trained model that is transformed into an executable equivalent; (4) model implementation aspects necessary for transforming a trained model into the executable equivalent; (5) integration of the executable trained model into the containing MLC, and eventually the larger system; and, (6) lastly, the verification and validation (V&V) of each of the above. Such V&V lifecycle artifacts themselves include: aspects of coverage, e.g., of various levels of requirements by the input space of the model and the data; traceability (where applicable); application of formal methods for property specification, analysis, and checking. Examples of evidence generation methods and tools further ground the discussion on what constitutes evidence, and the contribution to assurance during certification. The identified assurance considerations and supporting evidence is not a comprehensive set. Additionally, neither what should be considered as sufficient evidence relative to the assigned criticality of an MLC, nor how criticality ought to be determined and adjusted, have been considered in this report. However, suggestions are made for potential activities of the ML lifecycle that are aimed at providing confidence that an MLC can be relied upon when integrated into its containing (aircraft) system. Those activities are proposed as candidate elements of a certification process for MLCs. The main purpose of this report to inform regulatory guidance and consensus standards that may be used to meet the safety intent of the applicable regulations.

Aviation safety↗

Testing a Run-Time Assurance Framework Coupled with Integrated Risk Mitigation Capabilities for Autonomous Urban UAS Flights

The In-Time Aviation Safety Management System (IASMS) Concept of Operations (ConOps) envisions new capabilities to monitor, assess, and mitigate flight safety risks. Systems will be tailored to mission type, vehicle/equipage type, operational environment, and safety risk tolerance. Within an IASMS framework, several capabilities may be implemented spanning three operational phases (pre-flight, in-flight, and post-flight/off-line); and consisting of lower level functions and information services which may reside onboard the aircraft, on third-party server(s), and/or on ground/operator station(s). Each capability will be designed to produce and disseminate safety-relevant information; perform detection, diagnosis, and prediction of unsafe situations; and/or execute mitigation actions when hazardous events warrant such changes. This paper focuses on recent testing of airborne capabilities that demonstrate inflight aspects of the overarching concept for autonomous unmanned aircraft systems (UAS) operations in urban environments. A flight test architecture is described that applies run-time assurance principles (e.g., executes independent of the unassured autopilot), real-time risk assessment, and a technique to execute contingencies if necessary either automatically or via pilot intervention. Several tests using small UAS were conducted to verify the assured in-flight risk mitigation capability. The paper draws significantly from a larger NASA technical report and recent prior conference papers, providing additional details. Data is analyzed for two representative flights to illustrate the performance for various sequential and simultaneous hazards used during testing. During each automated flight, several hazards are encountered at various points along the flight path. At each point, the hazard is mitigated by the system, with the vehicle then continuing to subsequent points. The paper concludes with lessons-learned regarding relevant aspects of the overarching IASMS concept and how it may be updated and further advanced in the future.

population activity↗

Using Artificial Intelligence and Machine Learning to Enhance Mission Design and Operations of the Habitable Worlds Observatory (HWO)

One key aspect in the development of HWO is the early deployment of artificial intelligence (AI) and machine learning (ML) to enhance mission science and operations. Our subtask group is part of the HWO AI/ML working group and focuses on AI and ML for mission operations. Our task group seeks to educate other HWO working groups about AI and ML capabilities for mission operations, investigate how to bridge technology gaps, and enable new capabilities particularly in the areas of observational scheduling, instrument health monitoring, and downlink operations. We focus on mission tasking / scheduling both for mission analysis in development and operations. AI and ML for mission scheduling includes: tools to support proposal calls and review, ensuring fairness in calls for proposals, community peer reviews and ease workloads, as well as in-flight and ground software development (e.g., using natural language processing (NLP) to support process automation from requirements). AI and ML for the mission’s development and operations include 1) anomaly detection and prediction (from onboard and ground based tools) to monitor the spacecraft’s health, 2) ground-based automated scheduling for mission operations including long-term and short-term planning and maintenance, and 3) flight system flexible execution (as flight proven for Spitzer and JWST) to enable robust execution despite execution variations, and 4) data analysis for prioritization (e.g., real-time data evaluation leading to autonomous actions and adjustments, high-priority identification, onboard data compression, etc.). Incorporation of ML and AI will enable HWO to address the major science questions related to exoplanet characterization, general astrophysics, and solar system exploration and also extend the boundaries of space mission technologies.

Mark Moussa↗

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

Evolving the SpaceFOM: Lessons Learned and Future Development

For over fifty years, simulation has been a cornerstone technology for space missions. In many cases, one single simulator, developed by one team, is not enough to meet the simulation objectives. Astronaut crew training, docking, vehicle testing and complex mission planning all require several simulations to be connected and to interoperate, in order to achieve the goal of the simulation. To facilitate the development of interoperable simulations, an open standard, the SISO SpaceFOM was developed in collaboration between government, industry and academia. The standard was released in 2020. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. A number of requirements for the next version of SpaceFOM have been identified and proposed solutions are already under development. One key area is the object classes used for data exchange, where a richer set of classes have been proposed, based on practical use cases. For time management, the use of variable time resolutions and variable time steps is also proposed. For execution control, save and restore of simulations is considered as well as improved robustness, to handle failing components. A number of clarifications are also under consideration. This paper provides both a forward-looking view of the technical developments underway and a retrospective on the standard's evolution. The authors emphasize that prioritizing core challenges and delivering a practical first version were crucial steps. While not every idea was implemented in the initial release, the timely delivery of a functional standard enabled real-world applications, the growth of a user community, and the collection of valuable insights to shape future versions. The authors look forward to working with the next version of SpaceFOM together with the growing user community.

FOMs↗

Mission Design Considerations for a Low-Thrust Spacecraft

Developing an executable low-thrust trajectory for use in a spaceflight mission requires the design and optimization of a deterministic trajectory as well as the validation that the selected architecture is robust to some set of uncertainties, execution errors, and potential contingencies. Uncertainty in the ability of the spacecraft and its launch vehicle to execute a trajectory as well as potential deviations such as in-flight anomalies combine with design-to constraints and requirements to complicate the optimization problem. The approach by which robust mission design was accomplished for the initial capability of NASA’s Gateway is presented as well as associated results.

NRHO↗

Mission Design Considerations for a Low-Thrust Spacecraft

Developing an executable low-thrust trajectory for use in a spaceflight mission requires the design and optimization of a deterministic trajectory as well as the validation that the selected architecture is robust to some set of uncertainties, execution errors, and potential contingencies. Uncertainty in the ability of the spacecraft and its launch vehicle to execute a trajectory as well as potential deviations such as in-flight anomalies combine with design-to constraints and requirements to complicate the optimization problem. The approach by which robust mission design was accomplished for the initial capability of NASA’s Gateway is presented as well as associated results.

mission design↗