Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Scheduling and planning”

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 685 records · Page 38
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Enhanced project management tool

A system for managing a project that includes multiple tasks and a plurality of workers. Input information includes characterizations based upon a human model, a team model and a product model. Periodic reports, such as one or more of a monthly report, a task plan report, a schedule report, a budget report and a risk management report, are generated and made available for display or further analysis or collection into a customized report template. An extensible database allows searching for information based upon context and upon content. Seven different types of project risks are addressed, including non-availability of required skill mix of workers. The system can be configured to exchange data and results with corresponding portions of similar project analyses, and to provide user-specific access to specified information.

Maluf, David A.↗
NASA NTRS2013

Unique Challenges Testing SDRs for Space

This paper describes the approach used by the Space Communication and Navigation (SCaN) Testbed team to qualify three Software Defined Radios (SDR) for operation in space and the characterization of the platform to enable upgrades on-orbit. The three SDRs represent a significant portion of the new technologies being studied on board the SCAN Testbed, which is operating on an external truss on the International Space Station (ISS). The SCaN Testbed provides experimenters an opportunity to develop and demonstrate experimental waveforms and applications for communication, networking, and navigation concepts and advance the understanding of developing and operating SDRs in space. Qualifying a Software Defined Radio for the space environment requires additional consideration versus a hardware radio. Tests that incorporate characterization of the platform to provide information necessary for future waveforms, which might exercise extended capabilities of the hardware, are needed. The development life cycle for the radio follows the software development life cycle, where changes can be incorporated at various stages of development and test. It also enables flexibility to be added with minor additional effort. Although this provides tremendous advantages, managing the complexity inherent in a software implementation requires a testing beyond the traditional hardware radio test plan. Due to schedule and resource limitations and parallel development activities, the subsystem testing of the SDRs at the vendor sites was primarily limited to typical fixed transceiver type of testing. NASA s Glenn Research Center (GRC) was responsible for the integration and testing of the SDRs into the SCaN Testbed system and conducting the investigation of the SDR to advance the technology to be accepted by missions. This paper will describe the unique tests that were conducted at both the subsystem and system level, including environmental testing, and present results. For example, test waveforms were developed to measure the gain of the transmit system across the tunable frequency band. These were used during thermal vacuum testing to enable characterization of the integrated system in the wide operational temperature range of space. Receive power indicators were used for Electromagnetic Interference tests (EMI) to understand the platform s susceptibility to external interferers independent of the waveform. Additional approaches and lessons learned during the SCaN Testbed subsystem and system level testing will be discussed that may help future SDR integrators

Chelmins, David↗
NASA NTRS2013

Unique Challenges Testing SDRs for Space

This paper describes the approach used by the Space Communication and Navigation (SCaN) Testbed team to qualify three Software Defined Radios (SDR) for operation in space and the characterization of the platform to enable upgrades on-orbit. The three SDRs represent a significant portion of the new technologies being studied on board the SCAN Testbed, which is operating on an external truss on the International Space Station (ISS). The SCaN Testbed provides experimenters an opportunity to develop and demonstrate experimental waveforms and applications for communication, networking, and navigation concepts and advance the understanding of developing and operating SDRs in space. Qualifying a Software Defined Radio for the space environment requires additional consideration versus a hardware radio. Tests that incorporate characterization of the platform to provide information necessary for future waveforms, which might exercise extended capabilities of the hardware, are needed. The development life cycle for the radio follows the software development life cycle, where changes can be incorporated at various stages of development and test. It also enables flexibility to be added with minor additional effort. Although this provides tremendous advantages, managing the complexity inherent in a software implementation requires a testing beyond the traditional hardware radio test plan. Due to schedule and resource limitations and parallel development activities, the subsystem testing of the SDRs at the vendor sites was primarily limited to typical fixed transceiver type of testing. NASA's Glenn Research Center (GRC) was responsible for the integration and testing of the SDRs into the SCaN Testbed system and conducting the investigation of the SDR to advance the technology to be accepted by missions. This paper will describe the unique tests that were conducted at both the subsystem and system level, including environmental testing, and present results. For example, test waveforms were developed to measure the gain of the transmit system across the tunable frequency band. These were used during thermal vacuum testing to enable characterization of the integrated system in the wide operational temperature range of space. Receive power indicators were used for Electromagnetic Interference tests (EMI) to understand the platform's susceptibility to external interferers independent of the waveform. Additional approaches and lessons learned during the SCaN Testbed subsystem and system level testing will be discussed that may help future SDR integrators.

transmitters receivers↗
NASA NTRS2016

Design, Development, and Testing of a UAV Hardware-in-the-Loop Testbed for Aviation and Airspace Prognostics Research

The airspace is becoming more and more complicated, and will continue to do so in the future with the integration of Unmanned Aerial Vehicles (UAVs), autonomy, spacecraft, other forms of aviation technology into the airspace. The new technology and complexity increases the importance and difficulty of safety assurance. Additionally, testing new technologies on complex aviation systems & systems of systems can be very difficult, expensive, and sometimes unsafe in real life scenarios. Prognostic methodology provides an estimate of the health and risks of a component, vehicle, or airspace and knowledge of how that will change over time. That measure is especially useful in safety determination, mission planning, and maintenance scheduling. The developed testbed will be used to validate prediction algorithms for the real-time safety monitoring of the National Airspace System (NAS) and the prediction of unsafe events. The framework injects flight related anomalies related to ground systems, routing, airport congestion, etc. to test and verify algorithms for NAS safety. In our research work, we develop a live, distributed, hardware-in-the-loop testbed for aviation and airspace prognostics along with exploring further research possibilities to verify and validate future algorithms for NAS safety. The testbed integrates virtual aircraft using the X-Plane simulator and X-PlaneConnect toolbox, UAVs using onboard sensors and cellular communications, and hardware in the loop components. In addition, the testbed includes an additional research framework to support and simplify future research activities. It enables safe, accurate, and inexpensive experimentation and research into airspace and vehicle prognosis that would not have been possible otherwise. This paper describes the design, development, and testing of this system. Software reliability, safety and latency are some of the critical design considerations in development of the testbed. Integration of HITL elements in the development phases and veri cation/ validation are key elements to this report.

HITL↗
NASA NTRS2017

Understanding the International Space Station Crew Perspective following Long-Duration Missions through Data Analytics & Visualization of Crew Feedback

The International Space Station (ISS) first became a home and research laboratory for NASA and International Partner crewmembers over 16 years ago. Each ISS mission lasts approximately 6 months and consists of three to six crewmembers. After returning to Earth, most crewmembers participate in an extensive series of 30+ debriefs intended to further understand life onboard ISS and allow crews to reflect on their experiences. Examples of debrief data collected include ISS crew feedback about sleep, dining, payload science, scheduling and time planning, health & safety, and maintenance. The Flight Crew Integration (FCI) Operational Habitability (OpsHab) team, based at Johnson Space Center (JSC), is a small group of Human Factors engineers and one stenographer that has worked collaboratively with the NASA Astronaut office and ISS Program to collect, maintain, disseminate and analyze this data. The database provides an exceptional and unique resource for understanding the "crew perspective" on long duration space missions. Data is formatted and categorized to allow for ease of search, reporting, and ultimately trending, in order to understand lessons learned, recurring issues and efficiencies gained over time. Recently, the FCI OpsHab team began collaborating with the NASA JSC Knowledge Management team to provide analytical analysis and visualization of these over 75,000 crew comments in order to better ascertain the crew's perspective on long duration spaceflight and gain insight on changes over time. In this initial phase of study, a text mining framework was used to cluster similar comments and develop measures of similarity useful for identifying relevant topics affecting crew health or performance, locating similar comments when a particular issue or item of operational interest is identified, and providing search capabilities to identify information pertinent to future spaceflight systems and processes for things like procedure development and training. In addition, the comments were scored for sentiment using a polarity scoring algorithm to identify both positive and negative comments for particular groups and clusters, allowing the team to make analytically informed decisions regarding future hardware and operating procedures. The use of polarity scoring with time series analysis was used to provide insight into how crew health and habitability is changing throughout various spaceflight increments or the station lifecycle as a whole. Finally, a visualization framework was developed to address the needs of the end users to search for and analyze comments by user, category or mission. This paper will discuss how the use of an analytical framework in conjunction with the current human interface, improved the understanding of crew perspective and shortened the time for analysis allowing for more informed decisions and rapid development of improvements. These methods are significantly optimizing the way that this valuable data can be assessed and applied to current and future spaceflight design and development. This collaboration allows the FCI OpsHab team to effectively analyze and share data in a more automated and timely fashion. Trends are no longer derived manually and can be illustrated effectively and accurately with these evolving techniques to an ever growing group of human spaceflight end users.

Bryant, Cody↗
NASA NTRS2017

A Virtual Laboratory for Aviation and Airspace Prognostics Research

Integration of Unmanned Aerial Vehicles (UAVs), autonomy, spacecraft, and other aviation technologies, in the airspace is becoming more and more complicated, and will continue to do so in the future. Inclusion of new technology and complexity into the airspace increases the importance and difficulty of safety assurance. Additionally, testing new technologies on complex aviation systems and systems of systems can be challenging, expensive, and at times unsafe when implementing real life scenarios. The application of prognostics to aviation and airspace management may produce new tools and insight into these problems. Prognostic methodology provides an estimate of the health and risks of a component, vehicle, or airspace and knowledge of how that will change over time. That measure is especially useful in safety determination, mission planning, and maintenance scheduling. In our research, we develop a live, distributed, hardware- in-the-loop Prognostics Virtual Laboratory testbed for aviation and airspace prognostics. The developed testbed will be used to validate prediction algorithms for the real-time safety monitoring of the National Airspace System (NAS) and the prediction of unsafe events. In our earlier work1 we discussed the initial Prognostics Virtual Laboratory testbed development work and related results for milestones 1 & 2. This paper describes the design, development, and testing of the integrated tested which are part of milestone 3, along with our next steps for validation of this work. Through a framework consisting of software/hardware modules and associated interface clients, the distributed testbed enables safe, accurate, and inexpensive experimentation and research into airspace and vehicle prognosis that would not have been possible otherwise. The testbed modules can be used cohesively to construct complex and relevant airspace scenarios for research. Four modules are key to this research: the virtual aircraft module which uses the X-Plane simulator and X-PlaneConnect toolbox, the live aircraft module which connects fielded aircraft using onboard cellular communications devices, the hardware in the loop (HITL) module which connects laboratory based bench-top hardware testbeds and the research module which contains diagnostics and prognostics tools for analysis of live air traffic situations and vehicle health conditions. The testbed also features other modules for data recording and playback, information visualization, and air traffic generation. Software reliability, safety, and latency are some of the critical design considerations in development of the testbed.

LVC-DE↗
NASA NTRS2019

Omni-gravity Hydroponics for Space Exploration

As part of the NASA Plant Water Management technology demonstration experiments, a capillary fluidics hydroponic system that can function in a variety of gravity environments has been developed and tested for crop production in space. A passive liquid delivery method is employed that drastically reduces the number of contaminable moving parts providing a high reliability solution requiring minimal resources for operation. The terrestrial, lunar, and Martian environments are managed in a ‘gravity-dominated mode,’ while the low-gravity transit and orbit environments are managed in a ‘capillary fluidics mode,’ where the role of gravity is replaced by the equally passive effects of surface tension, conduit shape, and wettability. The unique considerations for priming, germination, aeration, nutrient supply, root accommodation, layout, crew interaction, etc. are highlighted. Design guides for system function are provided along with high Technology Readiness Level demonstrations of the system during terrestrial and drop tower tests. Long duration tests are planned on short schedule aboard the International Space Station in 2019.

gravity↗
NASA NTRSDate not supplied

DIP for Service Providers

The second DIP workshop’s topic is DIP for Service Providers. The workshop presentation covers topics such as DIP onboarding process, service authentication, catalog service capabilities, API requirements, NASA services and their access points, and data requirements for service providers. The Onboarding Process describes the required documentation that enables to collaborate with NASA as well as other industry partners through DIP. Also, step by step approach for the partner to take to register services or consme services through the DIP platform. The Catalog Service describes the different ways for the users to search for services that are of interest as well as registering services to the platform, so other users can search and discover. The API Requirements and Service Specifications describes the benefits of DIP's API management approach via API Gateway where services are managed centrally but ownership is decentralized and partners completely own the administration of their own services. NASA Services and Data Access Points topic describes the services, both data access service and machine learning prediction service, that NASA provides via the DIP platform in near time and post operations via REST API endpoints defined on the API Gateway. Also, NASA's approach for data storage process is explained. The Data Requirements for service providers describes the requirements for storing and exposing to support the performance of services that are provided by the service providers. Lastly, NASA's technology development plan with preliminary scheduler will be presented. There will be a Q&A session at the end of each segment of the presentation to solicit feedback from the participants.

ATM-X↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRSDate not supplied

NASA's Initial Artemis Human Landing System

In April 2020, NASA announced the selection of three companies to begin the initial phase of development of human landing systems to take the first woman and the first person of color to the lunar surface through NASA’s Artemis lunar exploration program. The selected companies were a Blue Origin-led team with Lockheed Martin, Northrup Grumman, and Draper; Dynetics (a Leidos company); and SpaceX. Contracts were awarded shortly after, kicking off a ten-month base period during which NASA worked closely with each company to finalize functional and performance requirements, confirm lander development standards, and establish baseline designs, schedules, and management plans for contract execution and human spaceflight certification. At the end of the base period, in the Spring of 2021, NASA awarded a single follow-on Option A contract to SpaceX to continue their work on Human Landing System (HLS) Starship development. Currently NASA and SpaceX are working collaboratively on Option A which will ultimately culminate in one uncrewed and one crewed mission to the lunar surface under Artemis III. This paper will provide a look at the Option A phase of development for the Human Landing System Program, including publicly available information on SpaceX’s HLS Starship design as well as near-term and future milestones for HLS and the Artemis program.

Lisa Watson-Morgan↗
NASA NTRS1981

The 30/20 GHz flight experiment system, phase 2. Volume 4: Experiment system development plan

The development plan for the 30/20 GHz flight experiment system is presented. A master program schedule with detailed development plans for each subsystem is planned with careful attention given to how technology items to ensure a minimal risk. The work breakdown structure shows the organization of the program management with detailed task definitions. The ROM costs based on the development plan are also given.

Bronstein, L.↗
NASA NTRS2020

Ground-Based Automated Scheduling for the Mars 2020 Rover

The Mars 2020 Rover Mission will be using an automated ground-based scheduling system called Copilot to schedule the rover’s activities at landing. Using automated scheduling technology will allow for plans to be generated more quickly. Because automated scheduling tools have not been widely used for prior rover missions, developing users’ trust in the system is crucial. An explainable scheduling tool called Crosscheck has been developed to visualize the creation of a schedule, and to explain why activities failed to schedule given their constraints. This will allow science planners to change activity constraints to allow failed activities to successfully schedule, achieving their science goals.

Towey, S.↗
NASA NTRS1989

PST and PARR: Plan specification tools and a planning and resource reasoning shell for use in satellite mission planning

Plan Specification Tools (PST) are tools that allow the user to specify satellite mission plans in terms of satellite activities, relevent orbital events, and targets for observation. The output of these tools is a set of knowledge bases and environmental events which can then be used by a Planning And Resource Reasoning (PARR) shell to build a schedule. PARR is a reactive planning shell which is capable of reasoning about actions in the satellite mission planning domain. Each of the PST tools and PARR are described as well as the use of PARR for scheduling computer usage in the multisatellite operations control center at Goddard Space Flight Center.

Mclean, David↗
NASA NTRS2019

Prototyping Operational Autonomy for Space Traffic Management

Current state of the art in Space Traffic Management (STM) relies on a handful of providers for surveillance and collision prediction, and manual coordination between operators. Neither is scalable to support the expected 10x increase in spacecraft population in less than 10 years, nor does it support automated manuever planning. We present a software prototype of an STM architecture based on open Application Programming Interfaces (APIs), drawing on previous work by NASA to develop an architecture for low-altitude Unmanned Aerial System Traffic Management. The STM architecture is designed to provide structure to the interactions between spacecraft operators, various regulatory bodies, and service suppliers, while maintaining flexibility of these interactions and the ability for new market participants to enter easily. Autonomy is an indispensable part of the proposed architecture in enabling efficient data sharing, coordination between STM participants and safe flight operations. Examples of autonomy within STM include syncing multiple non-authoritative catalogs of resident space objects, or determining which spacecraft maneuvers when preventing impending conjunctions between multiple spacecraft. The STM prototype is based on modern micro-service architecture adhering to OpenAPI standards and deployed in industry standard Docker containers, facilitating easy communication between different participants or services. The system architecture is designed to facilitate adding and replacing services with minimal disruption. We have implemented some example participant services (e.g. a space situational awareness provider/SSA, a conjunction assessment supplier/CAS, an automated maneuver advisor/AMA) within the prototype. Different services, with creative algorithms folded into then, can fulfil similar functional roles within the STM architecture by flexibly connecting to it using pre-defined APIs and data models, thereby lowering the barrier to entry of new players in the STM marketplace. We demonstrate the STM prototype on a multiple conjunction scenario with multiple maneuverable spacecraft, where an example CAS and AMA can recommend optimal maneuvers to the spacecraft operators, based on a predefined reward function. Such tools can intelligently search the space of potential collision avoidance maneuvers with varying parameters like lead time and propellant usage, optimize a customized reward function, and be implemented as a scheduling service within the STM architecture. The case study shows an example of autonomous maneuver planning is possible using the API-based framework. As satellite populations and predicted conjunctions increase, an STM architecture can facilitate seamless information exchange related to collision prediction and mitigation among various service applications on different platforms and servers. The availability of such an STM network also opens up new research topics on satellite maneuver planning, scheduling and negotiation across disjoint entities.

space traffic management↗
NASA NTRS1990

Yes, there was a moon race

Examination of newly disclosed evidence confirms that the Soviets were indeed striving to reach the moon before the U.S. in 1969. It is noted that a Soviet unmanned lunar probe crashed on the moon's surface only hours before the U.S. Apollo landing. Now confirmed openly are moon-exploration schedules that were competitive with Apollo plans, the names and histories of Soviet lunar boosters and landers, identities of the lunar cosmonauts; and even photos of manned lunar craft are available. Additional details on the troubled moon-probe program are presented: technical problems, continuous changes in goals, schedules, and planning, vehicle and personnel disasters, transfer of authority between ministries, and political power struggles in the scientific community.

Oberg, James E.↗
NASA NTRS1990

Analysis of sequencing and scheduling methods for arrival traffic

The air traffic control subsystem that performs scheduling is discussed. The function of the scheduling algorithms is to plan automatically the most efficient landing order and to assign optimally spaced landing times to all arrivals. Several important scheduling algorithms are described and the statistical performance of the scheduling algorithms is examined. Scheduling brings order to an arrival sequence for aircraft. First-come-first-served scheduling (FCFS) establishes a fair order, based on estimated times of arrival, and determines proper separations. Because of the randomness of the traffic, gaps will remain in the scheduled sequence of aircraft. These gaps are filled, or partially filled, by time-advancing the leading aircraft after a gap while still preserving the FCFS order. Tightly scheduled groups of aircraft remain with a mix of heavy and large aircraft. Separation requirements differ for different types of aircraft trailing each other. Advantage is taken of this fact through mild reordering of the traffic, thus shortening the groups and reducing average delays. Actual delays for different samples with the same statistical parameters vary widely, especially for heavy traffic.

Neuman, Frank↗