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.
Timeline Overview: Procedural Approach to Managing Inflight Fatality
Explore the source record for details and available documents.
Human Mars Surface Mission Surface Power Impacts on Timeline and Traverse Capabilities
The National Aeronautics and Aerospace Administration’s (NASA) Mars Architecture Team (MAT) developed a concept for power management operations to support a thirty-day, minimal infrastructure Mars surface mission. The surface elements in this minimal surface mission concept include three landers as platforms for surface operations, a crewed Mars ascent vehicle (MAV), an unpressurized rover, and a pressurized rover where the crew will live for the duration of the thirty-day mission. In this analysis the power system is a ten kilowatt fission power system, which has been selected for its resiliency to dust storms, and will provide power for all aspects of the surface mission including thermal management of propellant and electronic systems, communications, and battery recharge of mobile surface assets. Developing a power management plan with the consideration of the various elements and mission phases helps define the traverse and exploration capabilities for the crew in the pressurized rover. Also, considerations need to be made for the different power requirements for each phase of the surface mission including arrival, offload, surface exploration, launch preparation, and departure. The described analysis aims to achieve a balance of maintaining power to critical systems while enabling desired traverse and exploration range in the pressurized rover. Additionally, a few enhancing technologies were explored that could expand the power capability if the additional capacity is necessary in the future. This study is used as a baseline to understand the constraints on all aspects of the surface mission for a minimal surface infrastructure human Mars campaign if a ten-kilowatt fission surface power system is available on the surface.
Human Mars Mission Surface Power Impacts on Timeline and Traverse Capabilities
The National Aeronautics and Aerospace Administration’s (NASA) Mars Architecture Team (MAT) developed a concept for power management operations to support a thirty-day, minimal infrastructure Mars surface mission. The surface elements in this minimal surface mission concept include three landers as platforms for surface operations, a crewed Mars ascent vehicle (MAV), an unpressurized rover, and a pressurized rover where the crew will live for the duration of the thirty-day mission. In this analysis the power system is a ten kilowatt fission power system, which has been selected for its resiliency to dust storms, and will provide power for all aspects of the surface mission including thermal management of propellant and electronic systems, communications, and battery recharge of mobile surface assets. Developing a power management plan with the consideration of the various elements and mission phases helps define the traverse and exploration capabilities for the crew in the pressurized rover. Also, considerations need to be made for the different power requirements for each phase of the surface mission including arrival, offload, surface exploration, launch preparation, and departure. The described analysis aims to achieve a balance of maintaining power to critical systems while enabling desired traverse and exploration range in the pressurized rover. Additionally, a few enhancing technologies were explored that could expand the power capability if the additional capacity is necessary in the future. This study is used as a baseline to understand the constraints on all aspects of the surface mission for a minimal surface infrastructure human Mars campaign if a ten-kilowatt fission surface power system is available on the surface.
Evolving GEOS Systems: Snapshots and Timelines
Explore the source record for details and available documents.
Moon-to-Mars Strategy: Evolving Projects, Timelines, and Architectural Update
Explore the source record for details and available documents.
In-Space Crew-Collaborative Task Scheduling
For all past and current human space missions, the final scheduling of tasks to be done in space has been devoid of crew control, flexibility, and insight. Ground controllers, with minimal input from the crew, schedule the tasks and uplink the timeline to the crew or uplink the command sequences to the hardware. Prior to the International Space Station (ISS), the crew could make requests about tomorrow s timeline, they could omit a task, or they could request that something in the timeline be delayed. This lack of control over one's own schedule has had negative consequences. There is anecdotal consensus among astronauts that control over their own schedules will mitigate the stresses of long duration missions. On ISS, a modicum of crew control is provided by the job jar. Ground controllers prepare a task list (a.k.a. "job jar") of non-conflicting tasks from which jobs can be chosen by the in space crew. Because there is little free time and few interesting non-conflicting activities, the task-list approach provides little relief from the tedium of being micro-managed by the timeline. Scheduling for space missions is a complex and laborious undertaking which usually requires a large cadre of trained specialists and suites of complex software tools. It is a giant leap from today s ground prepared timeline (with a job jar) to full crew control of the timeline. However, technological advances, currently in-work or proposed, make it reasonable to consider scheduling a collaborative effort by the ground-based teams and the in-space crew. Collaboration would allow the crew to make minor adjustments, add tasks according to their preferences, understand the reasons for the placement of tasks on the timeline, and provide them a sense of control. In foreseeable but extraordinary situations, such as a quick response to anomalies and extended or unexpected loss of signal, the crew should have the autonomous ability to make appropriate modifications to the timeline, extend the timeline, or even start over with a new timeline. The Vision for Space Exploration (VSE), currently being pursued by the National Aeronautics and Space Administration (NASA), will send humans to Mars in a few decades. Stresses on the human mind will be exacerbated by the longer durations and greater distances, and it will be imperative to implement stress-reducing innovations such as giving the crew control of their daily activities.
International Space Station (ISS) Payload Autonomous Operations Past, Present and Future
Draper Laboratorys Timeliner is a scripting and automation system that runs onboard computers in the International Space Station (ISS). Timeliner is fully integrated with ISS and can be used to automate ISS operations tasks. Some of the most challenging aspects of operating a payload in low earth orbit are communication delays, ground equipment failures, and human errors. How does a Payload Developer (PD) know their equipment is operating nominally and collecting science in the most efficient way possible or even powered at any given time? During a ground Loss of Signal (LOS) data outage, PDs have no insight into their experiments state, and benefit greatly from Timeliner scripts executing on ISS to perform telemetry monitoring and commanding operations. This paper will discuss current software designs, and new operational uses for Timeliner. Existing Timeliner capabilities discussed will include: autonomous EXPRESS Rack activation and deactivation; autonomous science data downlinks; Minus Eighty Degree Freezer (MELFI) Dewar autonomous safing; JAXA and ESA module autonomous payload facility safing; as well as many others. New operational concepts discussed will include allowing Timeliner on the payload computer to issue core commands (Thermal, Power, Fire Detection), creation of new ground tools that will monitor the current status of Payload Racks as well as all the messaging from autonomous scripts executing, decreasing approval time for Timeliner bundles, and opening up the Payload MDM Enhanced Processor Integrated Communications Card (EPIC) interface. The EPIC interface could provide a new crew interface for PL Timeliner execution. The new interface could operate on either a Payload Computer System (PCS) or a Station Support Computer (SSC) that is plugged into either the Payload LAN or the Operations LAN which will make communicating to the PL MDM more flexible and greatly increase band width for communication.
Onboard Short Term Plan Viewer
Onboard Short Term Plan Viewer (OSTPV) is a computer program for electronic display of mission plans and timelines, both aboard the International Space Station (ISS) and in ISS ground control stations located in several countries. OSTPV was specifically designed both (1) for use within the limited ISS computing environment and (2) to be compatible with computers used in ground control stations. OSTPV supplants a prior system in which, aboard the ISS, timelines were printed on paper and incorporated into files that also contained other paper documents. Hence, the introduction of OSTPV has both reduced the consumption of resources and saved time in updating plans and timelines. OSTPV accepts, as input, the mission timeline output of a legacy, print-oriented, UNIX-based program called "Consolidated Planning System" and converts the timeline information for display in an interactive, dynamic, Windows Web-based graphical user interface that is used by both the ISS crew and ground control teams in real time. OSTPV enables the ISS crew to electronically indicate execution of timeline steps, launch electronic procedures, and efficiently report to ground control teams on the statuses of ISS activities, all by use of laptop computers aboard the ISS.
Irreducible Tests for Space Mission Sequencing Software
As missions extend further into space, the modeling and simulation of their every action and instruction becomes critical. The greater the distance between Earth and the spacecraft, the smaller the window for communication becomes. Therefore, through modeling and simulating the planned operations, the most efficient sequence of commands can be sent to the spacecraft. The Space Mission Sequencing Software is being developed as the next generation of sequencing software to ensure the most efficient communication to interplanetary and deep space mission spacecraft. Aside from efficiency, the software also checks to make sure that communication during a specified time is even possible, meaning that there is not a planet or moon preventing reception of a signal from Earth or that two opposing commands are being given simultaneously. In this way, the software not only models the proposed instructions to the spacecraft, but also validates the commands as well.To ensure that all spacecraft communications are sequenced properly, a timeline is used to structure the data. The created timelines are immutable and once data is as-signed to a timeline, it shall never be deleted nor renamed. This is to prevent the need for storing and filing the timelines for use by other programs. Several types of timelines can be created to accommodate different types of communications (activities, measurements, commands, states, events). Each of these timeline types requires specific parameters and all have options for additional parameters if needed. With so many combinations of parameters available, the robustness and stability of the software is a necessity. Therefore a baseline must be established to ensure the full functionality of the software and it is here where the irreducible tests come into use.
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.
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.
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.
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.
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.
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
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.
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.