Search NASA⌕ Search

SEARCH · Search NASA

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Digital Prototyping Methods to Enable Product Development Analysis Cycle Compression in Aerospace Systems

Historically, the product development life cycle (spanning from origination of a systems concept to initial delivery or fielding) for large-scale aerospace systems is 10-25 years. Examples of recent programs exhibiting this timeline are the Space Shuttle (13 years), , International Space Station (18 years), NASA Hubble telescope (16 years), USAF F-35 Strike Fighter (22 years), Missile Defense Agency THAAD (21 years), USAF V-22 Osprey (26 years), USAF B-2 Spirt (19 years), US Army RAH-66 Comanche (22 years, cancelled prior to fielding), James Webb Space Telescope (25 years), Space Launch System (10 years). This list illustrates the challenges of developing and fielding a modern integrated multi-disciplinary aerospace system. These development timelines are often preceded by significant research and development programs and followed by multiple increments, blocks, or spirals to reach planned operational capability. In the modern era of aerospace system acquisition, there is significant pressure to reduce system development timelines to meet system objectives and enable competitiveness in the current industry and landscape. Across the aerospace industry, a range of rapid acquisition and prototyping programs are seeking to achieve system development within timelines considerably less than 10 years. Notably, in September of 2019, NASA issued a solicitation for the development and demonstration of a Human Landing System (HLS) to deliver humans to the lunar surface by 2024 (5 years) and for the development and demonstration of a more sustainable HLS by 2026 (7 years). Lengthy product development cycle timelines are a product of multiple factors ranging from programmatic, sociological, technical, and systems engineering issues. New approaches in systems engineering provide new ways to enable these compressed development timelines. These approaches employ expanded application of advanced systems engineering methods and cross-cutting digital tools to accelerate system development, utilizing digital prototyping to connect maturing sub-system or component technologies into system or system-of-systems hardware prototypes. Approaches such as the use of system integrating physics relationships to reduce the number of design analysis cycle iterations and state analysis modeling to reduce necessary software testing (and improving coverage of system execution scenarios) represent steps forward in reducing the engineering time needed to field new systems. In addition to cost, schedule and performance benefits, expanded digital exploration and demonstration reduce risk in live system test and demonstration. This incremental demonstration approach, where digital prototyping and demonstration leads and informs full system test and demonstration, could be more important for space applications because of the increased difficulty of test and demonstration of space systems and architectures. The Advanced Concepts Office (ACO) at Marshall Space Flight Center merges traditional multi-disciplinary concept definition methods with modern, cross-cutting systems engineering concepts to enable iterative design and analysis of space architectures and systems through coordinated, strategic management of human capital, technical processes, and technology. This paper provides an overview of that approach, including recent examples and a strategic path forward to enabling continued reduction of aerospace system product development life cycles.

Michael D Watson↗
NASA NTRSDate not supplied

Identifying Emerging Safety Threats Through Topic Modeling in the Aviation Safety Reporting System: A Covid-19 Study

The NASA Aviation Safety Reporting System (ASRS) is a voluntary, confidential aviation safety reporting system. The ASRS receives reports from pilots, air traffic controllers, flight attendants, and others involved in aviation operations. The reports are de-identified and coded by ASRS expert safety analysts, and a short descriptive synopsis is written to describe the safety issue. The de-identified reports are then disseminated to the aviation community in many ways, including via an online database, Safety Alert Bulletins, For Your Information Notices, and the CALLBACK newsletter. In this work, we consider whether we can improve the grouping, linking, and understanding of safety concerns through topic modeling. Specifically, we use topic modeling as a building block to identify emerging safety threats over time. This unsupervised approach, we argue, offers the flexibility to identify new emerging themes in this large dataset by constructing different timelines based on the content similarity of ASRS report narratives. This method's unsupervised nature improves upon related research, which is limited to pre-defined labels and therefore can not fully capture emerging safety threats. We apply our method to all ASRS reports in 2020 to assess if the generated timelines can highlight COVID-19 as it is emerging as a safety threat in incoming ASRS reports. We perform both a quantitative and qualitative evaluation of the automatically constructed timelines. The qualitative evaluation is performed by describing the evolution of top terms in the timelines, generated by our method, which we found explicitly convey the themes of COVID-19. Separately, we use a set of 1,213 COVID-19 reports from 2020 that were manually identified by ASRS analysts to quantitatively evaluate the COVID-19 reports distribution across the timelines. Our results have shown that COVID-19 emergence can be identified using the top terms that were generated by topic modeling. The top terms in topic modeling therefore can serve as a summary alternative to manually inspecting reports. Moreover, leveraging the manually identified COVID-19 reports, we found the manually identified timelines accounted for over 70% of the COVID-19 reports curated by the ASRS analysts, which demonstrates the potential of this approach for facilitating the understanding of safety concerns as they emerge and evolve. This method shows great potential to understand aerospace safety threats and other narrative- driven incident report databases.

ASRS↗
NASA NTRSDate not supplied

Identifying Emerging Safety Threats Through Topic Modeling in the Aviation Safety Reporting System: A COVID-19 Study

The NASA Aviation Safety Reporting System (ASRS) is a voluntary, confidential aviation safety reporting system. The ASRS receives reports from pilots, air traffic controllers, flight attendants, and others involved in aviation operations. The reports are de-identified and coded by ASRS expert safety analysts, and a short descriptive synopsis is written to describe the safety issue. The de-identified reports are then disseminated to the aviation community in many ways, including via an online database, Safety Alert Bulletins, For Your Information Notices, and the CALLBACK newsletter. In this work, we consider whether we can improve the grouping, linking, and understanding of safety concerns through topic modeling. Specifically, we use topic modeling as a building block to identify emerging safety threats over time. This unsupervised approach, we argue, offers the flexibility to identify new emerging themes in this large dataset by constructing different timelines based on the content similarity of ASRS report narratives. This method's unsupervised nature improves upon related research, which is limited to pre-defined labels and therefore can not fully capture emerging safety threats. We apply our method to all ASRS reports in 2020 to assess if the generated timelines can highlight COVID-19 as it is emerging as a safety threat in incoming ASRS reports. We perform both a quantitative and qualitative evaluation of the automatically constructed timelines. The qualitative evaluation is performed by describing the evolution of top terms in the timelines, generated by our method, which we found explicitly convey the themes of COVID-19. Separately, we use a set of 1,213 COVID-19 reports from 2020 that were manually identified by ASRS analysts to quantitatively evaluate the COVID-19 reports distribution across the timelines. Our results have shown that COVID-19 emergence can be identified using the top terms that were generated by topic modeling. The top terms in topic modeling therefore can serve as a summary alternative to manually inspecting reports. Moreover, leveraging the manually identified COVID-19 reports, we found the manually identified timelines accounted for over 70% of the COVID-19 reports curated by the ASRS analysts, which demonstrates the potential of this approach for facilitating the understanding of safety concerns as they emerge and evolve. This method shows great potential to understand aerospace safety threats and other narrative- driven incident report databases.

ASRS↗
NASA NTRS2009

An Analysis of Rocket Propulsion Testing Costs

The primary mission at NASA Stennis Space Center (SSC) is rocket propulsion testing. Such testing is generally performed within two arenas: (1) Production testing for certification and acceptance, and (2) Developmental testing for prototype or experimental purposes. The customer base consists of NASA programs, DOD programs, and commercial programs. Resources in place to perform on-site testing include both civil servants and contractor personnel, hardware and software including data acquisition and control, and 6 test stands with a total of 14 test positions/cells. For several business reasons there is the need to augment understanding of the test costs for all the various types of test campaigns. Historical propulsion test data was evaluated and analyzed in many different ways with the intent to find any correlation or statistics that could help produce more reliable and accurate cost estimates and projections. The analytical efforts included timeline trends, statistical curve fitting, average cost per test, cost per test second, test cost timeline, and test cost envelopes. Further, the analytical effort includes examining the test cost from the perspective of thrust level and test article characteristics. Some of the analytical approaches did not produce evidence strong enough for further analysis. Some other analytical approaches yield promising results and are candidates for further development and focused study. Information was organized for into its elements: a Project Profile, Test Cost Timeline, and Cost Envelope. The Project Profile is a snap shot of the project life cycle on a timeline fashion, which includes various statistical analyses. The Test Cost Timeline shows the cumulative average test cost, for each project, at each month where there was test activity. The Test Cost Envelope shows a range of cost for a given number of test(s). The supporting information upon which this study was performed came from diverse sources and thus it was necessary to build several intermediate databases in order to understand, validate, and manipulate data. These intermediate databases (validated historical account of schedule, test activity, and cost) by themselves are of great value and utility. For example, for the Project Profile, we were able to merged schedule, cost, and test activity. This kind of historical account conveys important information about sequence of events, lead time, and opportunities for improvement in future propulsion test projects. The Product Requirement Document (PRD) file is a collection of data extracted from each project PRD (technical characteristics, test requirements, and projection of cost, schedule, and test activity). This information could help expedite the development of future PRD (or equivalent document) on similar projects, and could also, when compared to the actual results, help improve projections around cost and schedule. Also, this file can be sorted by the parameter of interest to perform a visual review of potential common themes or trends. The process of searching, collecting, and validating propulsion test data encountered a lot of difficulties which then led to a set of recommendations for improvement in order to facilitate future data gathering and analysis.

Ramirez-Pagan, Carmen P.↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗
NASA NTRS2022

Mars 2020 Entry, Descent, and Landing Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. In addition to performing the critical function of landing the rover on the Martian surface, the EDL timeline behavior must co-exist in a non-partitioned software and system environment with other high-level functions that accomplish the goals for the rest of the mission. Due to the criticality of EDL, the potential for loss of mission, and a need for complete system autonomy, the standard for how the EDL Timeline interacts with other functions in the system is highly constrained. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗
NASA NTRS1991

Resource representation in COMPASS

A set of viewgraphs on resource representation in COMPASS is given. COMPASS is an incremental, interactive, non-chronological scheduler written in Ada with an X-windows user interface. Beginning with an empty schedule, activities are added to the schedule one at a time, taking into consideration the placement of the activities already on the timeline and the resources that have been reserved for them. The order that the activities are added to the timeline and their location on the timeline are controlled by selection and placement commands invoked by the user. The order that activities are added to the timeline and their location are independent. The COMPASS code library is a cost effective platform for the development of new scheduling applications. It can be effectively used off the shelf for compatible scheduling applications or it can be used as a parts library for the development of custom scheduling systems.

Fox, Barry R.↗
NASA NTRS1993

An intelligent planning and scheduling system for the HST servicing missions

A new, intelligent planning and scheduling system has been delivered to NASA-Goddard Space Flight Center (GSFC) to provide support for the up-coming Hubble Space Telescope (HST) Servicing Missions. This new system is the Servicing Mission Planning and Replanning Tool (SM/PART). SM/PART is written in C and runs on a UNlX-based workstation (IBM RS/6000) under Motif. SM/PART effectively automates the complex task of building or rebuilding integrated timelines and command plans which are required by HST Servicing Mission personnel at their consoles during the missions. SM/PART is able to quickly build or rebuild timelines based on information stored in a Knowledge Base (KB) by using an Artificial Intelligence (AI) tool called the Planning And Resource Reasoning (PARR) shell. After a timeline has been built in the batch mode, it can be displayed and edited in an interactive mode with help from the PARR shell. Finally a detailed command plan is generated. The capability to quickly build or rebuild timelines and command plans provides an additional safety factor for the HST, Shuttle and Crew.

Johnson, Jay↗
NASA NTRS1996

Visualizing Time-Varying Phenomena In Numerical Simulations Of Unsteady Flows

Streamlines, contour lines, vector plots, and volume slices (cutting planes) are commonly used for flow visualization. These techniques are sometimes referred to as instantaneous flow visualization techniques because calculations are based on an instant of the flowfield in time. Although instantaneous flow visualization techniques are effective for depicting phenomena in steady flows,they sometimes do not adequately depict time-varying phenomena in unsteady flows. Streaklines and timelines are effective visualization techniques for depicting vortex shedding, vortex breakdown, and shock waves in unsteady flows. These techniques are examples of time-dependent flow visualization techniques, which are based on many instants of the flowfields in time. This paper describes the algorithms for computing streaklines and timelines. Using numerically simulated unsteady flows, streaklines and timelines are compared with streamlines, contour lines, and vector plots. It is shown that streaklines and timelines reveal vortex shedding and vortex breakdown more clearly than instantaneous flow visualization techniques.

Lane, David A.↗
NASA NTRS2014

The Cassini Solstice Mission: Streamlining Operations by Sequencing with PIEs

The Cassini Solstice Mission (CSM) is the second extended mission phase of the highly successful Cassini/Huygens mission to Saturn. Conducted at a much-reduced funding level, operations for the CSM have been streamlined and simplified significantly. Integration of the science timeline, which involves allocating observation time in a balanced manner to each of the five different science disciplines (with representatives from the twelve different science instruments), has long been a labor-intensive endeavor. Lessons learned from the prime mission (2004-2008) and first extended mission (Equinox mission, 2008-2010) were utilized to design a new process involving PIEs (Pre-Integrated Events) to ensure the highest priority observations for each discipline could be accomplished despite reduced work force and overall simplification of processes. Discipline-level PIE lists were managed by the Science Planning team and graphically mapped to aid timeline deconfliction meetings prior to assigning discrete segments of time to the various disciplines. Periapse segments are generally discipline-focused, with the exception of a handful of PIEs. In addition to all PIEs being documented in a spreadsheet, allocated out-of-discipline PIEs were entered into the Cassini Information Management System (CIMS) well in advance of timeline integration. The disciplines were then free to work the rest of the timeline internally, without the need for frequent interaction, debate, and negotiation with representatives from other disciplines. As a result, the number of integration meetings has been cut back extensively, freeing up workforce. The sequence implementation process was streamlined as well, combining two previous processes (and teams) into one. The new Sequence Implementation Process (SIP) schedules 22 weeks to build each 10-week-long sequence, and only 3 sequence processes overlap. This differs significantly from prime mission during which 5-week-long sequences were built in 24 weeks, with 6 overlapping processes.

Vandermey, Nancy↗
NASA NTRS2016

Integrated Mecical Model (IMM) 4.0 Verification and Validation (VV) Testing (HRP IWS 2016)

Timeline, partial treatment, and alternate medications were added to the IMM to improve the fidelity of this model to enhance decision support capabilities. Using standard design reference missions, IMM VV testing compared outputs from the current operational IMM (v3) with those from the model with added functionalities (v4). These new capabilities were examined in a comparative, stepwise approach as follows: a) comparison of the current operational IMM v3 with the enhanced functionality of timeline alone (IMM 4.T), b) comparison of IMM 4.T with the timeline and partial treatment (IMM 4.TPT), and c) comparison of IMM 4.TPT with timeline, partial treatment and alternative medication (IMM 4.0).

risk assessment↗
NASA NTRSDate not supplied

Assessment of Crew Time for Maintenance and Repairs Activities for Lunar Surface Missions

NASA is currently evaluating different methods to predict how much time crewmembers will spend conducting repair and maintenance activities on future space missions. As mission scope and spacecraft architectures change, it will be necessary to understand how crew repair and maintenance timelines are impacted by mission operations and technology changes. Past work has been done using historical ISS data to accurately predict crew habitation and operation timelines, resulting in the development of NASA’s Exploration Crew Time Model (ECTM). However, understanding crew maintenance and repair requirements has posed a unique challenge due to the complexity of available datasets, the probabilistic nature of sub-system failures, and the impacts of reliability growth on failure rates. This paper presents a methodology to collect and condition empirical repair and maintenance time data from available data sets, to extrapolate from that data to estimate projected maintenance and repair times for a lunar Surface Habitat, and to assess how uncertainty in repair time could impact utilization time on the lunar surface. NASA International Space Station (ISS) maintenance and crew time data are logged into two central databases, the Maintenance Data Collection (MDC) and the Operations Planning Timeline Integration System (OPTimIS) respectively. Separately, each of these two datasets capture only portions of the complete set of data required to generate an accurate assessment of crew time spent on maintenance activities at a sub-system level. MDC provides a detailed catalog of failure events and an overview of the failure’s required maintenance and OPTimIS provides a description of crew activities and crew time durations dedicated to maintenance. To create a more useful crew time estimate for maintenance timelines, the authors developed a methodology to capture relevant data from each set and combine and utilize that data by linking crew time requirements to specific components. The authors compare the failure logs in the MDC to crew activity logs pulled from OPTimIS and then process the data to estimate required repair times for each failure event. Data is also classified by the outcome of each repair event, whether the failed component was replaced or whether it was repaired in place. The entire maintenance activity dataset is then categorized based on the class of failed component to allow for a statistically significant sample size for each class and to provide accurate crew time estimates for any components lacking relevant data. This resultant component repair time data can be used in the future to generate Mean Time To Repair (MTTR) estimates and confidence intervals for each class of component based on a probabilistic distribution of documented maintenance events. These improved MTTR values can then be applied to candidate element sub-system architectures, along with component Mean Time Between Failure (MTBF) data to generate distributions for potential required system crew repair time estimates for a given mission. Repair time distributions can then be used to develop more accurate crew schedules and to assess potential available utilization time.

Crew Time↗
NASA NTRSDate not supplied

Assessment of Crew Time for Maintenance and Repair Activities for Lunar Surface Missions

NASA is currently evaluating different methods to predict how much time crewmembers will spend conducting repair and maintenance activities on future space missions. As mission scope and spacecraft architectures change, understanding how crew repair and maintenance timelines are impacted by mission operations and technology changes is vital for future mission planning. Past work has been done using historical International Space Station (ISS) data to accurately predict crew habitation and operation timelines, resulting in the development of NASA’s Exploration Crew Time Model (ECTM). However, understanding crew maintenance and repair requirements has posed a unique challenge due to the complexity of available datasets, the probabilistic nature of sub-system failures, and the impacts of reliability growth on failure rates. This paper presents a methodology to collect and condition empirical repair and maintenance time data from available datasets, to extrapolate from that data to estimate projected maintenance and repair times for a lunar Surface Habitat (SH), and to assess how uncertainty in repair time could impact utilization time on the lunar surface. NASA ISS maintenance and crew time data are logged into two central databases: the Maintenance Data Collection (MDC) and the Operations Planning Timeline Integration System (OPTimIS). Separately, each of these two datasets capture only portions of the complete set of data required to generate an accurate assessment of crew time spent on maintenance activities at a sub-system level. To create a more useful crew time estimate for maintenance timelines, the authors developed a methodology to capture relevant data from each set and combine and utilize that data by linking crew time requirements to specific components. The authors compare the failure logs in the MDC to crew activity logs pulled from OPTimIS and then process the data to estimate required repair time for each failure and repair event. The entire maintenance activity dataset is then categorized based on the class of failed component to ensure a significant sample size for each class and accurate crew time estimates for any components lacking relevant data. This resultant component repair time data can be used in the future to generate Mean Time to Repair (MTTR) estimates and confidence intervals for each class of component based on a probabilistic distribution of documented maintenance events. These improved MTTR values can then be applied to candidate element sub-system architectures, along with component Mean Time Between Failure (MTBF) data to generate distributions for potential required system crew repair time estimates for a given mission. The authors applied these modeling methods to a case study of a crewed mission to the planned SH and produced expected corrective maintenance crew time distributions. The results produced an expected corrective maintenance crew time at over 24 hours per mission, and a maintenance crew time distribution that reflects the importance of planning for sufficient maintenance requirements each mission. Repair time distributions can then be used to develop more accurate crew schedules and to assess potential available utilization time.

Crew Time↗
NASA NTRSDate not supplied

A Decision Support System for Extravehicular Operations Under Significant Communication Latency

Within the next few decades, humanity hopes to perform extravehicular activities (EVAs) on the surface of Mars; however, several technical and operational challenges must first be overcome. Foremost among these challenges is managing a significant two-way communication latency between Earth and Mars. Current and historical paradigms of EVA operations have required near-real-time communication between the crewmember(s) performing an EVA and an Earth-based mission control. Next-generation operational paradigms for supporting deep space exploration will necessitate a distributed decision authority system, including delayed Earth-based mission control, the on-planet extravehicular crewmember(s), and intermediate mission support from intravehicular crewmember(s) within real-time communication range. This latter group is of particular interest: they must provide operations support without the plentiful resources available to mission control on Earth. For this purpose, NASA is developing the Personalized EVA Informatics and Decision Support (PersEIDS) software platform. PersEIDS is designed to bolster operator situational awareness and offload operator workload by automating the tracking and projection of consumables usage over an EVA timeline, providing real-time probabilistic safety assessments of an EVA timeline given consumables constraints, and recommending alternative EVA timeline(s) when the active timeline is not expected to be completed under consumables limits. The PersEIDS concept of operations, use cases, and models will be presented. A limited version of PersEIDS was demonstrated during a three-day-long study where each day a roughly four-hour-long simulated Martian EVA was performed in virtual reality at the NASA Johnson Space Center. The first day was a control trial without PersEIDS support; the second and third days represented different levels of decision support provided by PersEIDS to the intravehicular crewmember acting as mission control. With PersEIDS support, the IV crewmember was able to manage the mission to completion faster and with more remaining consumables; however, additional testing is required to understand confounding factors, e.g. training bias.

Mars↗
NASA NTRSDate not supplied

Crew Autonomy Through Self-Scheduling: Operational Characterization

NASA’s future long-duration exploration missions (LDEMs) will encounter increasing communication transmission delays as they move farther from Earth-based ground stations. This necessitates a new approach, as crews can no longer rely on real-time support from ground planners and must self-schedule their own operational timelines effectively and efficiently. To enable this transition, our team has developed Playbook, a mission planning and scheduling tool. Our research focuses on quantifying scheduling performance using Playbook to inform the design and development of future features to streamline timeline creation. We also aim to propose standards and guidelines for autonomous crews in LDEMs. In the past year, we have focused on further validating and quantifying the effects of countermeasure aids on self-scheduling performance. There are two software aids in Playbook (self-scheduling platform): Suggested Fixes, which propose an edit to resolve violations within a timeline, and No-Go Zones, which highlight where activities should not be scheduled on a timeline. We have made significant progress in HERA Campaign 7 (C7) data collection, increasing the number of days crew must self-schedule from 4 to 8. As a result, almost 20% of the mission is self-scheduled by the analog astronauts. We have also started data collection on a controlled lab experiment designed to quantify performance effects due to the countermeasures. We expect to present the preliminary results from both efforts. Finally, we have conducted an exploratory analysis of NASA’s HERA Campaign 6 (C6), investigating the mission-level impacts of self-scheduling. We derived basic patterns and descriptive statistics to better characterize crew autonomy through self-scheduling. We also assessed if there are any individual indicators of preference for self-scheduling, such as experience or predilection for autonomy. Preliminary analysis indicates that the HERA C6 crew self-scheduled one out of four flexible activities, indicating unprompted adoption of self-scheduling as a concept of operation for crew autonomy.

analog↗
DOE OSTI2025

A VSC-HVDC-Assisted Black-Start Strategy in Bulk Power Systems a Case Study in San Diego

With the worldwide growth in deploying high-voltage direct current (HVDC) transmission systems, their ability to facilitate black-start (BS) restoration has been a research topic of interest. In this context, voltage source converter (VSC)-HVDC is regarded as a BS resource, and this paper proposes a VSC-HVDC-assisted parallel BS restoration strategy in bulk power systems. The proposed strategy consists of two stages: 1) determination of the VSC and generator startup sequence and 2) load restoration simulation. In the first stage, the entire blackout system is sectionalized into multiple subsystems. Each subsystem includes a VSC-HVDC station or traditional BS unit, it independently determines its generator startup timeline and the energization timelines for buses and lines. The second stage involves load restoration, conceptualized as a modified unit commitment problem, with the timelines established in the first stage work as critical inputs. The proposed BS restoration strategy is tested on the San Diego power system to simulate the 2011 Southwest blackout. The simulation results validate the effectiveness of using VSC-HVDC links as a BS resource which not only speeds up the restoration process but also reduces both energy and economic losses.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2026

SolarAPP+ Performance Review (2024 Data)

The Solar Automated Permit Processing Plus (SolarAPP+) platform is an online portal to facilitate and expedite rooftop solar photovoltaic (PV) and battery storage permitting processes. SolarAPP+ allows PV contractors to upload system specifications, have that information automatically reviewed for code compliance, and receive instant approval for code-compliant systems, reducing authority having jurisdiction (AHJ) staff time needed for review. SolarAPP+ also provides inspection checklists to verify installation practices and adherence to approved designs. This report is part of an ongoing series of reviews of SolarAPP+ performance. Consistent with previous performance reviews, we summarize SolarAPP+ adoption trends to date and compare various metrics for PV systems permitted through SolarAPP+ versus systems permitted through traditional AHJ permitting processes. As of the end of 2024, 799 AHJs had expressed interest in the platform, with 264 fully adopting (215) or piloting (49) the platform. In 2024, 861 installers submitted 37,393 permits through the SolarAPP+ platform, including 27,375 permits for PV+storage systems. SolarAPP+ permits accounted for around 43% of all permits issued in all participating AHJs, and more than 60% of all permits in several participating AHJs. We compare permitting timelines through SolarAPP+ to traditional AHJ permitting processes to assess the platform's performance. Consistent with previous SolarAPP+ performance reviews, we find that permitting timelines are significantly shorter for SolarAPP+ projects. Based on median timelines, a typical SolarAPP+ project is permitted and inspected 12 business days sooner than traditional projects. We estimate that automatic SolarAPP+ permitting saved around 18,400 hours of AHJ staff time in 2024. Finally, we estimate that SolarAPP+ eliminated over 100,000 business days in permitting-related delays in 2024.

14 SOLAR ENERGY↗