Search NASA⌕ Search

SEARCH · Search NASA

Results for “scheduling software”

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 631 records · Page 35
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

QUANT-NET Control Plane Framework (QNCP) v1.0.0

The QUANT-NET Control Plane (QNCP) provides a software framework for expressing and managing quantum network resources. It may be used to orchestrate a physical quantum testbed with real device driver implementations, or it may be used as a proving ground when developing new protocols and management functions. In practice, both approaches may be useful when undertaking research and development in emerging quantum testbeds. While a number of control systems have been developed for specific quantum platform demonstrations, an openly available and general solution for operating quantum networks has not emerged. QNCP is designed to fill this gap. The framework has been designed to provide extensible, modular capabilities that include scheduling, routing, monitoring, and pluggable protocols. A number of reference implementations in each module category have been included in the installable packages; however, the intent is that each of these modules may be extended or re-implemented to meet the needs of the particular deployment or research need. The software is currently being used in the QUANT-NET testbed project, which spans resources between LBNL and UC Berkeley Physics.

Zhang, Liang [Lawrence Berkeley National Laborator↗
NASA NTRS2017

Future ATM Concepts Evaluation Tool (FACET) Interface Control Document

This Interface Control Document (ICD) documents the airspace adaptation and air traffic inputs of NASA's Future ATM Concepts and Evaluation Tool (FACET). Its intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the system. FACET equips Air Traffic Management (ATM) researchers and service providers with a way to explore, develop and evaluate advanced air transportation concepts before they are field-tested and eventually deployed. FACET is a flexible software tool that is capable of quickly generating and analyzing thousands of aircraft trajectories. It provides researchers with a simulation environment for preliminary testing of advanced ATM concepts. Using aircraft performance profiles, airspace models, weather data, and flight schedules, the tool models trajectories for the climb, cruise, and descent phases of flight for each type of aircraft. An advanced graphical interface displays traffic patterns in two and three dimensions, under various current and projected conditions for specific airspace regions or over the entire continental United States. The system is able to simulate a full day's dynamic national airspace system (NAS) operations, model system uncertainty, measure the impact of different decision-makers in the NAS, and provide analysis of the results in graphical form, including sector, airport, fix, and airway usage statistics. NASA researchers test and analyze the system-wide impact of new traffic flow management algorithms under anticipated air traffic growth projections on the nation's air traffic system. In addition to modeling the airspace system for NASA research, FACET has also successfully transitioned into a valuable tool for operational use. Federal Aviation Administration (FAA) traffic flow managers and commercial airline dispatchers have used FACET technology for real-time operations planning. FACET integrates live air traffic data from FAA radar systems and weather data from the National Weather Service to summarize NAS performance. This information allows system operators to reroute flights around congested airspace and severe weather to maintain safety and minimize delay. FACET also supports the planning and post-operational evaluation of reroute strategies at the national level to maximize system efficiency. For the commercial airline passenger, strategic planning with FACET can result in fewer flight delays and cancellations. The performance capabilities of FACET are largely due to its architecture, which strikes a balance between flexibility and fidelity. FACET is capable of modeling the airspace operations for the continental United States, processing thousands of aircraft on a single computer. FACET was written in Java and C, enabling the portability of its software to a variety of operating systems. In addition, FACET was designed with a modular software architecture to facilitate rapid prototyping of diverse ATM concepts. Several advanced ATM concepts have already been implemented in FACET, including aircraft self-separation, prediction of aircraft demand and sector congestion, system-wide impact assessment of traffic flow management constraints, and wind-optimal routing.

FACET↗
DOE OSTI2025

The ePIC Simulation Campaign Workflow on the Open Science Grid

The ePIC collaboration is realizing the first experiment of the future Electron-Ion Collider (EIC) at the Brookhaven National Laboratory that will allow for a precision study of the nucleons and the nucleus at the scale of sea quarks and gluons through the study of electron-proton/ion collisions. This paper will discuss the current workflow for running centralized simulation campaigns for ePIC on the Open Science Grid (OSG) infrastructure. This involves monthly releases of ePIC software and container deployments to CVMFS, generation of input datasets in HepMC format according to collaboration-defined policy, using Snakemake in CI/CD for validation and benchmarking, and submitting jobs to the OSG condor scheduler for opportunistic running on available resources. File transfers utilize XrootD, and Rucio is used for data management. The workflow is continuously refined to improve daily throughput (currently 50-100k core hours per day) and minimize job failures. Since May 2023, monthly simulation campaigns employing the workflow have cumulatively used over 20 million core hours on the OSG and produced over 350 TB of simulation data. The campaigns incorporate simulations for the broad science program of the EIC and are actively used for the detector and physics studies in preparation of the Technical Design Report (TDR).

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS2001

Experience and Challenges in Implementing Stratospheric Aerosol Gas Experiment on Meteor-3M Platform

Implementation of Stratospheric Aerosol Gas Experiment (SAGE) is a joint science mission between the Rosavioskosmos, also called Russian Aviation and Space Agency (RASA) and the National Aeronautics and Space Administration (NASA). Under the global collaboration agreement established by President Clinton and Yeltsin in 1995 between the United States and Russia, space was one of the major areas identified for joint scientific collaboration. There were several collaborative projects identified under space, earth, human exploration of space and aeronautics. SAGE was one of the key Earth Science instruments selected common to both countries' interests in ozone research. SAGE has a long space heritage, and four earlier versions of this instrument have flown in space for the last 15-year period. It has provided a vital ozone and aerosol data in the mid latitudes and has contributed in the overall ozone depletion research. SAGE II, the fourth instrument has been flying in space on NASA's Earth Radiation Budget Satellite (ERBS) for the last 14 years. Ball Aerospace built the instrument under Langley Research Center's (LaRC) management. SAGE III for Russian Meteor-3M mission is a third generation design with more spectral bands, elaborate data gathering and storage and intelligent terrestrial software. The Russian collaboration required a complete integration of SAGE III on the Russian Meteor-3M satellite and a launch on a Zenit-2 launch vehicle manufactured in Ukraine. The whole complex is scheduled to be launched from Baikonur cosmodrome in early 2001. This cooperative mission has presented a number of management, technical and logistical challenges on both sides. This paper makes an attempt to review and document such experiences.

Habib, Shahid↗
NASA NTRS1993

Security System Software

C Language Integration Production System (CLIPS), a NASA-developed expert systems program, has enabled a security systems manufacturer to design a new generation of hardware. C.CURESystem 1 Plus, manufactured by Software House, is a software based system that is used with a variety of access control hardware at installations around the world. Users can manage large amounts of information, solve unique security problems and control entry and time scheduling. CLIPS acts as an information management tool when accessed by C.CURESystem 1 Plus. It asks questions about the hardware and when given the answer, recommends possible quick solutions by non-expert persons.

Source record↗
NASA NTRS2004

Optimizing Mars Airplane Trajectory with the Application Navigation System

Planning complex missions requires a number of programs to be executed in concert. The Application Navigation System (ANS), developed in the NAS Division, can execute many interdependent programs in a distributed environment. We show that the ANS simplifies user effort and reduces time in optimization of the trajectory of a martian airplane. We use a software package, Cart3D, to evaluate trajectories and a shortest path algorithm to determine the optimal trajectory. ANS employs the GridScape to represent the dynamic state of the available computer resources. Then, ANS uses a scheduler to dynamically assign ready task to machine resources and the GridScape for tracking available resources and forecasting completion time of running tasks. We demonstrate system capability to schedule and run the trajectory optimization application with efficiency exceeding 60% on 64 processors.

Frumkin, Michael↗
NASA NTRS2007

A Software Development Simulation Model of a Spiral Process

There is a need for simulation models of software development processes other than the waterfall because processes such as spiral development are becoming more and more popular. The use of a spiral process can make the inherently difficult job of cost and schedule estimation even more challenging due to its evolutionary nature, but this allows for a more flexible process that can better meet customers' needs. This paper will present a discrete event simulation model of spiral development that can be used to analyze cost and schedule effects of using such a process in comparison to a waterfall process.

Mizell, Carolyn↗
NASA NTRS2016

High Data Rate Architecture (HiDRA)

One of the greatest challenges in developing new space technology is in navigating the transition from ground based laboratory demonstration at Technology Readiness Level 6 (TRL-6) to conducting a prototype demonstration in space (TRL-7). This challenge is com- pounded by the relatively low availability of new spacecraft missions when compared with aeronautical craft to bridge this gap, leading to the general adoption of a low-risk stance by mission management to accept new, unproven technologies into the system. Also in consideration of risk, the limited selection and availability of proven space-grade components imparts a severe limitation on achieving high performance systems by current terrestrial technology standards. Finally from a space communications point of view the long duration characteristic of most missions imparts a major constraint on the entire space and ground network architecture, since any new technologies introduced into the system would have to be compliant with the duration of the currently deployed operational technologies, and in some cases may be limited by surrounding legacy capabilities. Beyond ensuring that the new technology is verified to function correctly and validated to meet the needs of the end users the formidable challenge then grows to additionally include: carefully timing the maturity path of the new technology to coincide with a feasible and accepting future mission so it flies before its relevancy has passed, utilizing a limited catalog of available components to their maximum potential to create meaningful and unprecedented new capabilities, designing and ensuring interoperability with aging space and ground infrastructures while simultaneously providing a growth path to the future. The International Space Station (ISS) is approaching 20 years of age. To keep the ISS relevant, technology upgrades are continuously taking place. Regarding communications, the state-of-the-art communication system upgrades underway include high-rate laser terminals. These must interface with the existing, aging data infrastructure. The High Data Rate Architecture (HiDRA) project is designed to provide networked store, carry, and forward capability to optimize data flow through both the existing radio frequency (RF) and new laser communications terminal. The networking capability is realized through the Delay Tolerant Networking (DTN) protocol, and is used for scheduling data movement as well as optimizing the performance of existing RF channels. HiDRA is realized as a distributed FPGA memory and interface controller that is itself controlled by a local computer running DTN software. Thus HiDRA is applicable to other arenas seeking to employ next-generation communications technologies, e.g. deep space. In this paper, we describe HiDRA and its far-reaching research implications.

DTN↗
NASA NTRS2005

A Reliable Service-Oriented Architecture for NASA's Mars Exploration Rover Mission

The Collaborative Information Portal (CIP) was enterprise software developed jointly by the NASA Ames Research Center and the Jet Propulsion Laboratory (JPL) for NASA's highly successful Mars Exploration Rover (MER) mission. Both MER and CIP have performed far beyond their original expectations. Mission managers and engineers ran CIP inside the mission control room at JPL, and the scientists ran CIP in their laboratories, homes, and offices. All the users connected securely over the Internet. Since the mission ran on Mars time, CIP displayed the current time in various Mars and Earth time zones, and it presented staffing and event schedules with Martian time scales. Users could send and receive broadcast messages, and they could view and download data and image files generated by the rovers' instruments. CIP had a three-tiered, service-oriented architecture (SOA) based on industry standards, including J2EE and web services, and it integrated commercial off-the-shelf software. A user's interactions with the graphical interface of the CIP client application generated web services requests to the CIP middleware. The middleware accessed the back-end data repositories if necessary and returned results for these requests. The client application could make multiple service requests for a single user action and then present a composition of the results. This happened transparently, and many users did not even realize that they were connecting to a server. CIP performed well and was extremely reliable; it attained better than 99% uptime during the course of the mission. In this paper, we present overviews of the MER mission and of CIP. We show how CIP helped to fulfill some of the mission needs and how people used it. We discuss the criteria for choosing its architecture, and we describe how the developers made the software so reliable. CIP's reliability did not come about by chance, but was the result of several key design decisions. We conclude with some of the important lessons we learned form developing, deploying, and supporting the software.

Mak, Ronald↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDRs approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

radio equipment↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDR's approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

space communication↗
NASA NTRS1979

KSC facilities status and planned management operations

A status report is presented on facilities and planned operations at the Kennedy Space Center with reference to Space Shuttle launch activities. The facilities are essentially complete, with all new construction and modifications to existing buildings almost finished. Some activity is still in progress at Pad A and on the Mobile Launcher due to changes in requirements but is not expected to affect the launch schedule. The installation and testing of the ground checkout equipment that will be used to test the flight hardware is now in operation. The Launch Processing System is currently supporting the development of the applications software that will perform the testing of this flight hardware.

Gray, R. H.↗
NASA NTRS1984

The 1984 ASEE-NASA summer faculty fellowship program (aeronautics and research)

The 1984 NASA-ASEE Faculty Fellowship Program (SFFP) is reported. The report includes: (1) a list of participants; (2) abstracts of research projects; (3) seminar schedule; (4) evaluation questionnaire; and (5) agenda of visitation by faculty programs committee. Topics discussed include: effects of multiple scattering on laser beam propagation; information management; computer techniques; guidelines for writing user documentation; 30 graphics software; high energy electron and antiproton cosmic rays; high resolution Fourier transform infrared spectrum; average monthly annual zonal and global albedos; laser backscattering from ocean surface; image processing systems; geomorphological mapping; low redshift quasars; application of artificial intelligence to command management systems.

Dah-Nien, F.↗
NASA NTRS1994

Renaissance architecture for Ground Data Systems

The Mission Operations and Data Systems Directorate (MO&DSD) has embarked on a new approach for developing and operating Ground Data Systems (GDS) for flight mission support. This approach is driven by the goals of minimizing cost and maximizing customer satisfaction. Achievement of these goals is realized through the use of a standard set of capabilities which can be modified to meet specific user needs. This approach, which is called the Renaissance architecture, stresses the engineering of integrated systems, based upon workstation/local area network (LAN)/fileserver technology and reusable hardware and software components called 'building blocks.' These building blocks are integrated with mission specific capabilities to build the GDS for each individual mission. The building block approach is key to the reduction of development costs and schedules. Also, the Renaissance approach allows the integration of GDS functions that were previously provided via separate multi-mission facilities. With the Renaissance architecture, the GDS can be developed by the MO&DSD or all, or part, of the GDS can be operated by the user at their facility. Flexibility in operation configuration allows both selection of a cost-effective operations approach and the capability for customizing operations to user needs. Thus the focus of the MO&DSD is shifted from operating systems that we have built to building systems and, optionally, operations as separate services. Renaissance is actually a continuous process. Both the building blocks and the system architecture will evolve as user needs and technology change. Providing GDS on a per user basis enables this continuous refinement of the development process and product and allows the MO&DSD to remain a customer-focused organization. This paper will present the activities and results of the MO&DSD initial efforts toward the establishment of the Renaissance approach for the development of GDS, with a particular focus on both the technical and process implications posed by Renaissance to the MO&DSD.

Perkins, Dorothy C.↗
NASA NTRS1996

The Capabilities of the Graphical Observation Scheduling System (GROSS) as Used by the Astro-2 Spacelab Mission

The Graphical Observation Scheduling System (GROSS) and its functionality and editing capabilities are reported on. The GROSS system was developed as a replacement for a suite of existing programs and associated processes with the aim of: providing a software tool that combines the functionality of several of the existing programs, and provides a Graphical User Interface (GUI) that gives greater data visibility and editing capabilities. It is considered that the improved editing capability provided by this approach enhanced the efficiency of the second astronomical Spacelab mission's (ASTRO-2) mission planning.

Phillips, Shaun↗
NASA NTRS1993

Storm Warning Service

A Huntsville meteorologist of Baron Services, Inc. has formed a commercial weather advisory service. Weather information is based on data from Marshall Space Flight Center (MSFC) collected from antennas in Alabama and Tennessee. Bob Baron refines and enhances MSFC's real time display software. Computer data is changed to audio data for radio transmission, received by clients through an antenna and decoded by computer for display. Using his service, clients can monitor the approach of significant storms and schedule operations accordingly. Utilities and emergency management officials are able to plot a storm's path. A recent agreement with two other companies will promote continued development and marketing.

Source record↗
NASA NTRS2019

Scenario Complexity for Unmanned Aircraft System Traffic

This work introduces an approach to estimate the complexity of a low-altitude air traffic scenario involving multiple UASs using mathematical programming. Given a set of multi-point UAS flight trajectories, vehicle dynamics, and a conflict resolution algorithm, an abstract model is developed such that it can be solved quickly using a mathematical programming optimization software without running high-fidelity simulations that can be computationally expensive and may not suit real-time apA quick and accurate assessment of complexity for a given traffic scenario can help plan and schedule flights to alleviate traffic bottleneck and mitigate operation risks, especially for unmanned aerial system traffic management where high traffic density or complexity is expected. This work introduces a traffic scenario complexity metric that was constructed based on the number of potential conflicts weighted by the conflict resolution cost associated. The cost associated with a conflict is calculated based on the corresponding conflict resolution maneuvers. To obtain the conflict resolution maneuvers, a MILP-based optimization was formulated with the vehicle model and conflict management parameters incorporated. To evaluate the complexity metrics, an approach of using measurements from high-fidelity simulations was proposed. The scenario complexity measurements for 920 random-generated scenarios were obtained through high-fidelity simulations and treated as the ground truth. Two statistics methods: Pearson and Alternative Conditional Expectations were applied for analysis. The results showed that the number of flights has low correlation with the scenario complexity according to the correlation coefficients calculated by both methods. The Alternative Conditional Expectations method shows that the proposed scenario complexity metric has better correlation with the ground truth than the number of potential conflicts.plications. In the abstract model, each vehicle is represented by a time-varied vector associated with position, speed, and heading information. The total extra distance that aircraft need to divert from their original routes to avoid collisions is computed and used to setup a quadratic programming formula. The metrics including the number of conflicts and extra distances travelled by all vehicles are then utilized to estimate the complexity of a given UAS flight scenario. Results and verification against high-fidelity simulations will be provided in the final draft.

traffic complexity↗
NASA NTRS2009

GPS Navigation for the Magnetospheric Multi-Scale Mission

In 2014. NASA is scheduled to launch the Magnetospheric Multiscale Mission (MMS), a four-satellite formation designed to monitor fluctuations in the Earth's magnetosphere. This mission has two planned phases with different orbits (1? x 12Re and 1.2 x 25Re) to allow for varying science regions of interest. To minimize ground resources and to mitigate the probability of collisions between formation members, an on-board orbit determination system consisting of a Global Positioning System (GPS) receiver and crosslink transceiver was desired. Candidate sensors would be required to acquire GPS signals both below and above the constellation while spinning at three revolutions-per-minute (RPM) and exchanging state and science information among the constellation. The Intersatellite Ranging and Alarm System (IRAS), developed by Goddard Space Flight Center (GSFC) was selected to meet this challenge. IRAS leverages the eight years of development GSFC has invested in the Navigator GPS receiver and its spacecraft communication expertise, culminating in a sensor capable of absolute and relative navigation as well as intersatellite communication. The Navigator is a state-of-the-art receiver designed to acquire and track weak GPS signals down to -147dBm. This innovation allows the receiver to track both the main lobe and the much weaker side lobe signals. The Navigator's four antenna inputs and 24 tracking channels, together with customized hardware and software, allow it to seamlessly maintain visibility while rotating. Additionally, an extended Kalman filter provides autonomous, near real-time, absolute state and time estimates. The Navigator made its maiden voyage on the Space Shuttle during the Hubble Servicing Mission, and is scheduled to fly on MMS as well as the Global Precipitation Measurement Mission (GPM). Additionally, Navigator's acquisition engine will be featured in the receiver being developed for the Orion vehicle. The crosslink transceiver is a 1/4 Watt transmitter utilizing a TDMA schedule to distribute a science quality message to all constellation members every ten seconds. Additionally the system generates one-way range measurements between formation members which is used as input to the Kalman filter. In preparation for the MMS Preliminary Design Review (PDR), the Navigator was required to pass a series of Technology Readiness Level (TRL) tests to earn the necessary TRL-6 classification. The TRL-6 level is achieved by demonstrating a prototype unit in a relevant end-to-end environment. The IRAS unit was able to meet all requirements during the testing phase, and has thus been TRL-6 qualified

Bamford, William↗