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.
Integrated Tests and Evaluations
NASA has developed a project plan to address issues related to UAS access to the NAS The plan is being formulated with inputs from our stakeholders. NASA will work with our stakeholders to develop ConOps and a national roadmap to determine key research technologies and policy issues to enable UAS access to the NAS. NASA will use ConOps and roadmap to either validate current NASA research investment areas and make any necessary changes to proposed UAS research portfolio. NASA will conduct integration and testing of key research areas to enable UAS access to the NAS. Use phase I to do detailed test planning for phase II Assist subelements with test planning Assist with documenting test objectives, data and facilities/infrastructure requirements, and detailed test planning Provide facilities/infrastructure to meet test requirements Provide interfaces between tools Develop, document, and execute data handling and dissemination plans Provide a test engineer to facilitate scheduling of facilities, support specific equipment and software needs, track schedule progress, and monitor changes to schedule Provide guidance for alternative facilities or equipment to mitigate risk associated with loss of availability Provide opportunities for subelements to gather data in relevant and increasingly complex environments
Software Cost-Estimation Model
Software Cost Estimation Model SOFTCOST provides automated resource and schedule model for software development. Combines several cost models found in open literature into one comprehensive set of algorithms. Compensates for nearly fifty implementation factors relative to size of task, inherited baseline, organizational and system environment and difficulty of task.
Software integration for integrated electronics
Minimizing cost and schedule problems of integrating software of avionics system
Investigations into Generalization of Constraint-Based Scheduling Theories with Applications to Space Telescope Observation Scheduling
This final report summarizes research performed under NASA contract NCC 2-531 toward generalization of constraint-based scheduling theories and techniques for application to space telescope observation scheduling problems. Our work into theories and techniques for solution of this class of problems has led to the development of the Heuristic Scheduling Testbed System (HSTS), a software system for integrated planning and scheduling. Within HSTS, planning and scheduling are treated as two complementary aspects of the more general process of constructing a feasible set of behaviors of a target system. We have validated the HSTS approach by applying it to the generation of observation schedules for the Hubble Space Telescope. This report summarizes the HSTS framework and its application to the Hubble Space Telescope domain. First, the HSTS software architecture is described, indicating (1) how the structure and dynamics of a system is modeled in HSTS, (2) how schedules are represented at multiple levels of abstraction, and (3) the problem solving machinery that is provided. Next, the specific scheduler developed within this software architecture for detailed management of Hubble Space Telescope operations is presented. Finally, experimental performance results are given that confirm the utility and practicality of the approach.
Study and Demonstration of Planning and Scheduling Concepts for the Earth Observing System Data and Information System
The University of Colorado's Laboratory for Atmospheric and Space Physics (CU/LASP) along with the Goddard Space Flight Center (GSFC) and the Jet Propulsion Laboratory (JPL) designed, implemented, tested, and demonstrated a prototype of the distributed, hierarchical planning and scheduling system comtemplated for the Earth Observing System (EOS) project. The planning and scheduling prototype made use of existing systems: CU/LASP's Operations and Science Instrument Support Planning and Scheduling (OASIS-PS) software package; GSFC's Request Oriented Scheduling Engine (ROSE); and JPL's Plan Integrated Timeliner 2 (Plan-It-2). Using these tools, four scheduling nodes were implemented and tied together using a new communications protocol for scheduling applications called the Scheduling Applications Interface Language (SAIL). An extensive and realistic scenario of EOS satellite operations was then developed and the prototype scheduling system was tested and demonstrated using the scenario. Two demonstrations of the system were given to NASA personnel and EOS core system (ECS) contractor personnel. A comprehensive volume of lessons learned was generated and a meeting was held with NASA and ECS representatives to review these lessons learned. A paper and presentation on the project's final results was given at the American Institute of Aeronautics and Astronautics Computing in Aerospace 9 conference.
Computer-aided software development process design
The authors describe an intelligent tool designed to aid managers of software development projects in planning, managing, and controlling the development process of medium- to large-scale software projects. Its purpose is to reduce uncertainties in the budget, personnel, and schedule planning of software development projects. It is based on dynamic model for the software development and maintenance life-cycle process. This dynamic process is composed of a number of time-varying, interacting developmental phases, each characterized by its intended functions and requirements. System dynamics is used as a modeling methodology. The resulting Software LIfe-Cycle Simulator (SLICS) and the hybrid expert simulation system of which it is a subsystem are described.
Requirement Metrics for Risk Identification
The Software Assurance Technology Center (SATC) is part of the Office of Mission Assurance of the Goddard Space Flight Center (GSFC). The SATC's mission is to assist National Aeronautics and Space Administration (NASA) projects to improve the quality of software which they acquire or develop. The SATC's efforts are currently focused on the development and use of metric methodologies and tools that identify and assess risks associated with software performance and scheduled delivery. This starts at the requirements phase, where the SATC, in conjunction with software projects at GSFC and other NASA centers is working to identify tools and metric methodologies to assist project managers in identifying and mitigating risks. This paper discusses requirement metrics currently being used at NASA in a collaborative effort between the SATC and the Quality Assurance Office at GSFC to utilize the information available through the application of requirements management tools.
Constraint-Based Scheduling System
Report describes continuing development of software for constraint-based scheduling system implemented eventually on massively parallel computer. Based on machine learning as means of improving scheduling. Designed to learn when to change search strategy by analyzing search progress and learning general conditions under which resource bottleneck occurs.
A Strategy for Autogeneration of Space Shuttle Ground Processing Simulation Models for Project Makespan Estimations
Space Shuttle Processing is a complicated and highly variable project. The planning and scheduling problem, categorized as a Resource Constrained - Stochastic Project Scheduling Problem (RC-SPSP), has a great deal of variability in the Orbiter Processing Facility (OPF) process flow from one flight to the next. Simulation Modeling is a useful tool in estimation of the makespan of the overall process. However, simulation requires a model to be developed, which itself is a labor and time consuming effort. With such a dynamic process, often the model would potentially be out of synchronization with the actual process, limiting the applicability of the simulation answers in solving the actual estimation problem. Integration of TEAMS model enabling software with our existing schedule program software is the basis of our solution. This paper explains the approach used to develop an auto-generated simulation model from planning and schedule efforts and available data.
SPRINT: Scheduling Planning Routing Intersatellite Network Tool
The Scheduling Planning Routing Intersatellite Network Tool (SPRINT) software system plans and schedules the operations (observations, inter-satellite crosslink communications, and ground communications) of Earth observation (EO) constellations of hundreds of resource-constrained small satellites to enable global, near real-time science. Historically, most CubeSats have flown radios only for direct-to-ground downlink of data; as a result, data availability is delayed by as long as it takes for the capturing satellite to pass over a ground station, typically hours. Current Planning and Scheduling (P&S) systems for constellations cannot handle data routing through a large, dynamic network topology, and all planning is handled on the ground without .the ability to autonomously prioritize important observations, or respond to unexpected changes in communication window or bandwidth. SPRINT directly handles both data routing for low latency bulk observation data downlink and replanning onboard to deal with dynamic priorities and fault response, maximizing the utility of downlinked data.
Coordinating space telescope operations in an integrated planning and scheduling architecture
The Heuristic Scheduling Testbed System (HSTS), a software architecture for integrated planning and scheduling, is discussed. The architecture has been applied to the problem of generating observation schedules for the Hubble Space Telescope. This problem is representative of the class of problems that can be addressed: their complexity lies in the interaction of resource allocation and auxiliary task expansion. The architecture deals with this interaction by viewing planning and scheduling as two complementary aspects of the more general process of constructing behaviors of a dynamical system. The principal components of the software architecture are described, indicating how to model the structure and dynamics of a system, how to represent schedules at multiple levels of abstraction in the temporal database, and how the problem solving machinery operates. A scheduler for the detailed management of Hubble Space Telescope operations that has been developed within HSTS is described. Experimental performance results are given that indicate the utility and practicality of the approach.
Standardized development of computer software. Part 1: Methods
This work is a two-volume set on standards for modern software engineering methodology. This volume presents a tutorial and practical guide to the efficient development of reliable computer software, a unified and coordinated discipline for design, coding, testing, documentation, and project organization and management. The aim of the monograph is to provide formal disciplines for increasing the probability of securing software that is characterized by high degrees of initial correctness, readability, and maintainability, and to promote practices which aid in the consistent and orderly development of a total software system within schedule and budgetary constraints. These disciplines are set forth as a set of rules to be applied during software development to drastically reduce the time traditionally spent in debugging, to increase documentation quality, to foster understandability among those who must come in contact with it, and to facilitate operations and alterations of the program as requirements on the program environment change.
Spacecraft-Initiated Scheduling of Commercial Communications Services
We propose a software framework enabling a spacecraft in Earth orbit to schedule its own access to space communications services via ground stations and relay satellites. All operations are automated, without a human in the loop, allowing for highly responsive service to meet time-varying needs. We describe a modular software architecture allowing the framework to interface with the scheduling systems of several providers - both government and commercial. Specifically, we present the results of an experiment with Amazon Web Services (AWS) Ground Station, an operational commercial service provider. Proposed software executed scheduling of a ground station antenna with minimal lead time (less than 20 minutes before the start of a pass). During the contact AWS cloud infrastructure was used to demodulate, process, and distribute data products from an orbiting satellite. We believe this work demonstrates the framework's ability to interface with additional providers and potential to integrate more complex decision-making in the future to schedule optimal contacts.
Use of Dynamic Models and Operational Architecture to Solve Complex Navy Challenges
The United States Navy established 8 Maritime Operations Centers (MOC) to enhance the command and control of forces at the operational level of warfare. Each MOC is a headquarters manned by qualified joint operational-level staffs, and enabled by globally interoperable C41 systems. To assess and refine MOC staffing, equipment, and schedules, a dynamic software model was developed. The model leverages pre-existing operational process architecture, joint military task lists that define activities and their precedence relations, as well as Navy documents that specify manning and roles per activity. The software model serves as a "computational wind-tunnel" in which to test a MOC on a mission, and to refine its structure, staffing, processes, and schedules. More generally, the model supports resource allocation decisions concerning Doctrine, Organization, Training, Material, Leadership, Personnel and Facilities (DOTMLPF) at MOCs around the world. A rapid prototype effort efficiently produced this software in less than five months, using an integrated process team consisting of MOC military and civilian staff, modeling experts, and software developers. The work reported here was conducted for Commander, United States Fleet Forces Command in Norfolk, Virginia, code N5-0LW (Operational Level of War) that facilitates the identification, consolidation, and prioritization of MOC capabilities requirements, and implementation and delivery of MOC solutions.
Considerations for the Next Revision of NASA's Space Telecommunications Radio System Architecture
Development of NASA's Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for National Aeronautics and Space Administration (NASA) space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module - which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions.
Considerations for the Next Revision of STRS
Development of NASAs Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for NASA space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and have provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions
cFE/CFS (Core Flight Executive/Core Flight System)
This viewgraph presentation describes in detail the requirements and goals of the Core Flight Executive (cFE) and the Core Flight System (CFS). The Core Flight Software System is a mission independent, platform-independent, Flight Software (FSW) environment integrating a reusable core flight executive (cFE). The CFS goals include: 1) Reduce time to deploy high quality flight software; 2) Reduce project schedule and cost uncertainty; 3) Directly facilitate formalized software reuse; 4) Enable collaboration across organizations; 5) Simplify sustaining engineering (AKA. FSW maintenance); 6) Scale from small instruments to System of Systems; 7) Platform for advanced concepts and prototyping; and 7) Common standards and tools across the branch and NASA wide.