SEARCH · Search NASA
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.
The concept of a timeline is used ubiquitously during space mission design and development to specify elements of flight and ground system designs. In this paper we introduce our Timeline Ontology. The Timeline Ontology is grounded in mathematical formalism, thus proving concrete semantics.
No abstract available
Timeliner has been developed as a tool to automate procedural tasks. These tasks may be sequential tasks that would typically be performed by a human operator, or precisely ordered sequencing tasks that allow autonomous execution of a control process. The Timeliner system includes elements for compiling and executing sequences that are defined in the Timeliner language. The Timeliner language was specifically designed to allow easy definition of scripts that provide sequencing and control of complex systems. The execution environment provides real-time monitoring and control based on the commands and conditions defined in the Timeliner language. The Timeliner sequence control may be preprogrammed, compiled from Timeliner "scripts," or it may consist of real-time, interactive inputs from system operators. In general, the Timeliner system lowers the workload for mission or process control operations. In a mission environment, scripts can be used to automate spacecraft operations including autonomous or interactive vehicle control, performance of preflight and post-flight subsystem checkouts, or handling of failure detection and recovery. Timeliner may also be used for mission payload operations, such as stepping through pre-defined procedures of a scientific experiment.
The Gateway Vehicle Systems Manager (VSM), the top-level software control system in a distributed, hierarchical Autonomous System Management Architecture is, like most modern spacecraft software control systems, heavily data-driven. For example, schedules (timelines) will be developed on the ground and, due to the high degree of autonomy, contain complex procedures involving conditional branching, variable timing, and resource contention resolution. In order to verify that an uploaded timeline will function correctly, it is necessary to explore the feasible set of possible executions. While it is possible to test a timeline using a mission simulation, the complexity of the system and duration of a timeline limits the number of trials and therefore the test coverage. To address this problem, the VSM team is using a discrete event system model that can rapidly generate from a timeline sets of event sequences using Monte Carlo techniques. To achieve rapid and trustworthy checking of the event sequences, we use an offline version of the runtime model checking tool R2U2. This presentation describes the approach the VSM team is using to implement the discrete event simulation and evaluate event sequences using R2U2. The presentation will discuss: 1. Description of the timelines by VSM in the context of VSM operations 2. Expansion of a timeline into a sequence of atomic events 3. Adjustment, in the Monte Carlo environment, of an event sequence to account for uncertainty, external events, and failures 4. Definition of R2U2 input and mission-time linear temporal logic files 5. Generation and use of R2U2 verdict sequences 6. Lessons learned and future work
Introduction: In 1997 NASA’S Discovery Program selected the Genesis mission proposal to return solar wind samples to Earth for laboratory analyses. Principal Investigator Donald S. Burnett and the science team defined the purity of collector materials and ability to analyze solar wind composition to the precision required for planetary science. As a small mission, focused on a well-defined science goal, yet needing careful attention to engineering details, the communication among scientists and engineers, nurtured by Don Burnett, was exceptional. Genesis Mission and Curation Legacy: Genesis, as the first U. S. spacecraft to return astromaterial samples since Apollo, not only integrated the mission planning and flight teams, but also the science and sample curation teams during the mission development period. Since Genesis is a sample return mission, the Science Team was essential in certifying the collectors (sample containers for solar atoms). From inception, Genesis established mission funding for returned sample curation. JSC was lead in contamination control during mission preparation, including establishment of an ISO 4 cleanroom facility and use of ultrapure water (UPW) for cleaning flight hardware (and, as it turned out, for cleaning collectors after the mishap). Reliable, fast communication among scientists, engineers and curators at the hands-on level established deep respect among team members and efficient decision-making. JSC’s 50-years of astromaterial sample curation provided experienced sample processors onsite during recovery in Utah (a deep bench for emergency response). Post-recovery curation included iterative collaboration with science sample users to clean or verify cleanliness of samples. The science legacy from Genesis is addressed by Burnett and Jurewicz, this volume. In The Beginning: After Apollo sample return, Burnett and Marcia Neugebauer at JPL began discussing a solar wind sample return, with Neugebauer arguing that separate collection of solar wind regimes was essential science. By 1992 a solar wind sample return mission was presented at a workshop, and by 1994 a mission was proposed named Suess-Urey. The mission was re-proposed under a new name GENESIS and selected in 1997. Susan Niebur captured the Genesis mission history and stories, from high level management documents and from many interviews with participants [2]. Her account lets readers glimpse personality of participants in quotations from interviews. Need and Scope for Detailed Technical Timeline: A timeline constructed from lower level task documents has been initiated to document the resources and skills actually used, as well as task sequence or concurrency. Timelines for high level mission events are captured in two documents [1] [2] and for detailed re-entry events in [3]. A detailed technical timeline for Genesis mission and curation activities will provide data points for lower level tasks, such as ISO 4 curation facility construction time, preparation for nominal sample field recovery, mishap recovery, and UPW expansion. Changes in technology context 1990-2024: Semiconductor technologies were easily accessible in the U.S.A. (1990-1999), and the Genesis team used those resources for cleanroom design and UPW system expansion. Image documentation was changing from film to digital during cleanroom construction and payload cleaning (1997-2001). Engineering design was done using computer aided design proprietary software, making more difficult the archiving of payload configuration and materials. Email of documents, tracked delivery service and virtual meeting capability greatly improved communication efficiency. Information sources – Pre-launch mission preparation: Examples of mission science, engineering and contamination control are collector purity testing, payload design/fabrication and ISO 4 cleanroom construction. Information on timing of these activities comes from facility readiness reviews, management reviews, shipping documents, procurement documents, test reports, travel documents, laboratory logs, Quality Assurance documents, dates on images, participant notebooks and emails. Information sources – Sample return re-entry and field recovery activities: Information comes from event timelines produced by Mid-Air Recovery team, Lockheed team lead notes and from chase video, JPL Quality Assurance. Information also comes from images and logbooks from UTTR cleanroom operations and from curatorial documents. Information sources – Resulting science and sample cleaning processes: Agendas from the annual gatherings of the science team initially trace testing for collector purity/cleanliness, and after sample recovery, include collector cleaning and cleanliness assessment. Post-recovery documents include curatorial orders and procedures, sample allocation documents and LPSC abstracts. Timeline Objectives: A simple spreadsheet timeline with headers DATE, EVENT, PEOPLE, COMMENT, INFORMATION SOURCE has been initiated and currently has over 90 entries. While this is not definitive historical research, it is a quick look at the evolution of Genesis curation with pointers to documents or people with information. Engineers for future missions may find useful points of comparison for development of facilities. References:[1] Genesis Mission Reference Document, (2011) JPL D-62382.[2] Niebur S. M., edited by Brown D. W. (2023) NASA’s Discovery Program: The First 20 Years of Competitive Planetary Exploration, NASA-SP-2023-4238.[3] Genesis Mishap Investigation Board Report, Vol. 1 (July 2005).
As NASA progresses towards sustained crewed space missions, crew timelines will become increasingly important to achieving mission goals. While it is desirable to spend as much time as possible during crewed space missions on science activities and experiments, there are a large number of activities that crew members must perform each day in order to maintain both crew and vehicle health and safety. The time available for science activities in space is highly dependent on mandatory tasks required for crew and vehicle health and safety. The different crewed activities need to be planned accordingly long before the start of a mission in order to optimize crew time for science. To begin assessing the potential crew time for available for science, an understanding of the requirements to maintain crew and vehicle health and safety is needed. These additional activities may include sleep, exercise, vehicle maintenance, logistics handling, crew personal time, as well as many other tasks. The remaining time outside of these required tasks, within a reasonable crew work schedule, can be dedicated to science operations. This paper will detail a collaborative effort to analyzing crew times for sustained spaceflight missions and how the results of that analysis are applied to the crew timeline for the proposed Lunar Surface Habitat (SH).To determine the crew time for all of these required activities, an analysis was conducted utilizing defined agency requirements and historical crewed mission data. Predicted crew activity times were integrated into a daily schedule in order to optimize the crew’s time during the mission. This methodology was utilized to produce expected crew timelines for NASA’s proposed Artemis Base Camp (ABC) missions. The current plans for the ABC contain two different sustained habitats, the Pressurized Rover (PR) and the Surface Habitat (SH). While the crew are separated between the two habitats, the timelines for each element are dependent on the other element’s operations, so the two element timelines are formed in conjunction with one another. The results described in this paper, however, will focus solely on the crew timeline in the SH. This paper will explain the methodology behind predicting the required crew time spent in the SH for each activity, and the process of incorporating these predicted crew times into a coherent schedule.
The Mission Planning Division of the Mission Operations Laboratory at NASA's Marshall Space Flight Center is responsible for scheduling experiment activities for space missions controlled at MSFC. In order to draw statistically relevant conclusions, all experiments must be scheduled at least once and may have repeated performances during the mission. An experiment consists of a series of steps which, when performed, provide results pertinent to the experiment's functional objective. Since these experiments require a set of resources such as crew and power, the task of creating a timeline of experiment activities for the mission is one of resource constrained scheduling. For each experiment, a computer model with detailed information of the steps involved in running the experiment, including crew requirements, processing times, and resource requirements is created. These models are then loaded into the Experiment Scheduling Program (ESP) which attempts to create a schedule which satisfies all resource constraints. ESP uses a depth-first search technique to place each experiment into a time interval, and a scoring function to evaluate the schedule. The mission planners generate several schedules and choose one with a high value of the scoring function to send through the approval process. The process of approving a mission timeline can take several months. Each timeline must meet the requirements of the scientists, the crew, and various engineering departments as well as enforce all resource restrictions. No single objective is considered in creating a timeline. The experiment scheduling problem is: given a set of experiments, place each experiment along the mission timeline so that all resource requirements and temporal constraints are met and the timeline is acceptable to all who must approve it. Much work has been done on multicriteria decision making (MCDM). When there are two criteria, schedules which perform well with respect to one criterion will often perform poorly with respect to the other. One schedule dominates another if it performs strictly better on one criterion, and no worse on the other. Clearly, dominated schedules are undesireable. A nondominated schedule can be generated by some sort of optimization problem. Generally there are two approaches: the first is a hierarchical approach while the second requires optimizing a weighting or scoring function.
Numerous automated and semi-automated planning & scheduling systems have been developed for space applications. Most of these systems are model-based in that they encode domain knowledge necessary to predict spacecraft state and resources based on initial conditions and a proposed activity plan. The spacecraft state and resources as often modeled as a series of timelines, with a timeline or set of timelines to represent a state or resource key in the operations of the spacecraft. In this paper, we first describe a basic timeline representation that can represent a set of state, resource, timing, and transition constraints. We describe a number of planning and scheduling systems designed for space applications (and in many cases deployed for use of ongoing missions) and describe how they do and do not map onto this timeline model.
The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.
Redesign of the Timeline Generator at Fermilab using a web-based Flutter application, GraphQL API and an IOC ABSTRACT = The control system at Fermilab is undergoing an evolution with a shift towards web-based applications with connections to the EPICS infrastructure. The Timeline Generator (TLG) is an application that serves to coordinate events across the lab using different timing links. These links include the Tevatron clock (TCLK), a 10 MHz serial link with events encoded at 20Hz and Ma-chine Data (MDAT), a communication link with states encoded at 720Hz. This paper covers the redesign of the major components of the TLG. This includes a web-based Flutter application for building timelines. A placement service is in use that has a GraphQL interface and uses a timeline input to compute a schedule of events and states. The Flutter application sends this computed schedule to the TLG IOC via a GraphQL interface to the Data Pool Manager (DPM). The TLG IOC runs on an Arria FPGA, the Accelerator Clock Generator (ACLK-GEN), which is responsible for writing the events and states on to the different timing links.
The Timeline Resource Analysis Program (TRAP), developed for scheduling and timelining problems, is described. Given an activity network, TRAP generates timeline plots, resource histograms, and tabular summaries of the network, schedules, and resource levels. It is written in ANSI FORTRAN for the Honeywell SIGMA 5 computer and operates in the interactive mode using the TEKTRONIX 4014-1 graphics terminal. The input network file may be a standard SIGMA 5 file or one generated using the Interactive Graphics Design System. The timeline plots can be displayed in two orderings: according to the sequence in which the tasks were read on input, and a waterfall sequence in which the tasks are ordered by start time. The input order is especially meaningful when the network consists of several interacting subnetworks. The waterfall sequence is helpful in assessing the project status at any point in time.
EVA timeline development occurs using task execution data generated through underwater training and simulation. This project collected task time data during final training events for several Space Shuttle and International Space Station missions and compared like task time data collected during on-orbit execution. Analysis was performed to compare types of activities and times required for each looking specifically for how activities can be accurately trained from a timeline planning perspective. The data revealed two significant aspects of flight timeline planning; Zero-g task times will match training times for activities that can be accurately simulated with appropriate fidelity hardware; and not all activities can be simulated sufficiently to produce training task times that will reflect required zero-g times. An approach for timeline planning utilizing this knowledge is also presented.
The Safety Inhibit Timeline Tool was created as one approach to capturing and understanding inhibits and controls from IT through launch. Global Precipitation Measurement (GPM) Mission, which launched from Japan in March 2014, was a joint mission under a partnership between the National Aeronautics and Space Administration (NASA) and the Japan Aerospace Exploration Agency (JAXA). GPM was one of the first NASA Goddard in-house programs that extensively used software controls. Using this tool during the GPM buildup allowed a thorough review of inhibit and safety critical software design for hazardous subsystems such as the high gain antenna boom, solar array, and instrument deployments, transmitter turn-on, propulsion system release, and instrument radar turn-on. The GPM safety team developed a methodology to document software safety as part of the standard hazard report. As a result of this process, a new tool safety inhibit timeline was created for management of inhibits and their controls during spacecraft buildup and testing during IT at GSFC and at the launch range in Japan. The Safety Inhibit Timeline Tool was a pathfinder approach for reviewing software that controls the electrical inhibits. The Safety Inhibit Timeline Tool strengthens the Safety Analysts understanding of the removal of inhibits during the IT process with safety critical software. With this tool, the Safety Analyst can confirm proper safe configuration of a spacecraft during each IT test, track inhibit and software configuration changes, and assess software criticality. In addition to understanding inhibits and controls during IT, the tool allows the Safety Analyst to better communicate to engineers and management the changes in inhibit states with each phase of hardware and software testing and the impact of safety risks. Lessons learned from participating in the GPM campaign at NASA and JAXA will be discussed during this session.
The control system at Fermilab is undergoing an evolution with a shift towards web-based applications with connections to the EPICS infrastructure. The Timeline Generator (TLG) is an application that serves to coordinate events across the lab using different timing links. These links include the Tevatron clock (TCLK), a 10 MHz serial link with events encoded at 20Hz and Machine Data (MDAT), a communication link with states encoded at 720Hz. This paper covers the redesign of the major components of the TLG. This includes a web-based Flutter application for building timelines. A placement service is in use that has a GraphQL interface and uses a timeline input to compute a schedule of events and states. The Flutter application sends this computed schedule to the TLG IOC via a GraphQL interface to the Data Pool Manager (DPM). The TLG IOC runs on an Arria FPGA, the Accelerator Clock Generator (ACLK-GEN), which is responsible for writing the events and states on to the different timing links.
This report is part of the ongoing Solar Time-Based Residential Analytics and Cycle Time Estimator (SolarTRACE) project, led by the National Renewable Energy Laboratory (NREL). The SolarTRACE project utilizes time-stamped project-level data provided by installer-partners to assess nationwide and AHJ- and utility-level PI&I and other solar PV adoption timelines since 2017. Our dataset now covers 22% of residential solar and 33% of residential storage installs in the U.S. since 2017. This report provides an update to our previous 2022 report (Cruce et al., 2022b) and includes: updated 2017 2023 project timelines for residential rooftop solar PV up to 20kW; updated tracking of permitting process changes at nearly 4,000 AHJs nationwide; and first-ever reporting of timelines for residential PV+storage projects up to 20kW.
Presented herein are the known elements of the timeline for synchrotron reflectance calibrations of HRMA witness samples (Section 2). In Section 3, lists of measurements to be done on each witness flat are developed. The elements are then arranged into timelines for the three beamlines we expect to employ in covering the full 50-12,000 eV energy range (Section 4). Although the required AXAF operational range is only 0.1-10 keV, we must calibrate the extent to which radiation just outside this band may contaminate our in-band response. In Section 5, we describe the working relationships which exist with each of the beamlines, and estimate the time available for AXAF measurements on each. From the timelines and the available time, we calculate the number of flats which could be measured in full detail over the duration of the program for each beamline. A suggestion is made regarding a minimum required baselines of witness flats from each element coating run or qualification run to be used in the calibration. We intend that this suggestion open discussion of the issue of witness flat deployment.
This paper describes the Functional Objective Requirements Collection System (FORCS) software tool that has been developed for use by Principal Investigators (PI's) and Payload Element Developers (PED's) on their own personal computers to develop on-orbit timelining requirements for their payloads. The FORCS tool can be used either in a totally stand-alone mode, storing the information in a local file on the user's personal computer hard disk or in a remote mode where the user's computer is linked to a host computer containing the integrated database of the timeline requirements for all of the payloads on a mission. There are a number of features incorporated in the FORCS software to assist the user. The user may move freely back and forth between the various forms for inputting the data. Several methods are used to input the information, depending on the type of the information. These methods range from filling in text boxes, using check boxes and radio buttons, to inputting information into a spreadsheet format. There are automated features provided to assist in developing the proper format for the data, ranging from limit checking on some of the parameters to automatic conversion of different formats of time data inputs to the one standard format used for the timeline scheduling software.
This slide presentation reviews the use of Human factors and timeline analysis to have a more efficient and effective processing flow. The solution involved developing a written timeline of events that included each activity within each functional flow block. Each activity had computer animation videos and pictures of the people involved and the hardware. The Human Factors Engineering Analysis Tool (HFEAT) was improved by modifying it to include the timeline of events. The HFEAT was used to define the human factors requirements and design solutions were developed for these requirements. An example of a functional flow block diagram is shown, and a view from one of the animations (i.e., short stack pallet) is shown and explained.