SEARCH · Search NASA

Results for “Planning 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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

NASA NTRS1991

Using C to build a satellite scheduling expert system: Examples from the Explorer platform planning system

Recently, many expert systems were developed in a LISP environment and then ported to the real world C environment before the final system is delivered. This situation may require that the entire system be completely rewritten in C and may actually result in a system which is put together as quickly as possible with little regard for maintainability and further evolution. With the introduction of high performance UNIX and X-windows based workstations, a great deal of the advantages of developing a first system in the LISP environment have become questionable. A C-based AI development effort is described which is based on a software tools approach with emphasis on reusability and maintainability of code. The discussion starts with simple examples of how list processing can easily be implemented in C and then proceeds to the implementations of frames and objects which use dynamic memory allocation. The implementation of procedures which use depth first search, constraint propagation, context switching and a blackboard-like simulation environment are described. Techniques for managing the complexity of C-based AI software are noted, especially the object-oriented techniques of data encapsulation and incremental development. Finally, all these concepts are put together by describing the components of planning software called the Planning And Resource Reasoning (PARR) shell. This shell was successfully utilized for scheduling services of the Tracking and Data Relay Satellite System for the Earth Radiation Budget Satellite since May 1987 and will be used for operations scheduling of the Explorer Platform in November 1991.

Mclean, David R.↗

NASA NTRS1987

Expert system verification concerns in an operations environment

The Space Shuttle community is currently developing a number of knowledge-based tools, primarily expert systems, to support Space Shuttle operations. It is proposed that anticipating and responding to the requirements of the operations environment will contribute to a rapid and smooth transition of expert systems from development to operations, and that the requirements for verification are critical to this transition. The paper identifies the requirements of expert systems to be used for flight planning and support and compares them to those of existing procedural software used for flight planning and support. It then explores software engineering concepts and methodology that can be used to satisfy these requirements, to aid the transition from development to operations and to support the operations environment during the lifetime of expert systems. Many of these are similar to those used for procedural hardware.

Goodwin, Mary Ann↗

NASA NTRS1989

Shuttle relative navigation of a tethered satellite mission with current on board software

A Shuttle mission planned in 1991 will test the feasibility of tethers in space. This mission, a joint effort between Italy and the United States, will connect a satellite (built by the Italians) to the Shuttle with a 20 km long tether. This mission poses unique navigation problems. The flight software on the Shuttle was never designed to account for the low level acceleration that is generated by the gravity gradient. IMUs on the Shuttle was never designed to account for the low level acceleration that is generated by the gravity gradient. Inertial Maneuvering Units on the shuttle will sense the acceleration of the tether but it turns out that incorporating the continuous accelerometer noise also generates large error growth. Relative navigation is another important issue since the majority of the mission will be conducted while the satellite is out of the visual range of the crew. Some kind of feedback on the motion of the satellite will be desirable. Feedback of the satellite motion can be generated by using the rendezvous radar. To process the radar measurements, the flight software uses a 13 state Kalman Filter, but unfortunately with the filter currently tuned as it is, valid measurements tend to be ignored. This is due to the constraint of the tether on the satellite, which is an unmodeled force. Analysis shows that with proper tuning, relative navigation is possible.

Lee, Kevin A.↗

NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

NASA NTRS1990

JPL's Real-Time Weather Processor project (RWP) metrics and observations at system completion

As an integral part of the overall upgraded National Airspace System (NAS), the objective of the Real-Time Weather Processor (RWP) project is to improve the quality of weather information and the timeliness of its dissemination to system users. To accomplish this, an RWP will be installed in each of the Center Weather Service Units (CWSUs), located in 21 of the 23 Air Route Traffic Control Centers (ARTCCs). The RWP System is a prototype system. It is planned that the software will be GFE and that production hardware will be acquired via industry competitive procurement. The ARTCC is a facility established to provide air traffic control service to aircraft operating on Instrument Flight Rules (IFR) flight plans within controlled airspace, principally during the en route phase of the flight. Covered here are requirement metrics, Software Problem Failure Reports (SPFRs), and Ada portability metrics and observations.

Loesh, Robert E.↗

NASA NTRS1990

Resource Allocation Planning Helper (RALPH): Lessons learned

The current task of Resource Allocation Process includes the planning and apportionment of JPL's Ground Data System composed of the Deep Space Network and Mission Control and Computing Center facilities. The addition of the data driven, rule based planning system, RALPH, has expanded the planning horizon from 8 weeks to 10 years and has resulted in large labor savings. Use of the system has also resulted in important improvements in science return through enhanced resource utilization. In addition, RALPH has been instrumental in supporting rapid turn around for an increased volume of special what if studies. The status of RALPH is briefly reviewed and important lessons learned from the creation of an highly functional design team are focused on through an evolutionary design and implementation period in which an AI shell was selected, prototyped, and ultimately abandoned, and through the fundamental changes to the very process that spawned the tool kit. Principal topics include proper integration of software tools within the planning environment, transition from prototype to delivered to delivered software, changes in the planning methodology as a result of evolving software capabilities and creation of the ability to develop and process generic requirements to allow planning flexibility.

Durham, Ralph↗

NASA NTRS1980

Software cost/resource modeling

The Putnam method for planning the time/work effort component of software development is evaluated. This software costing model, based on Norden-Rayleigh product life cycle concepts, was applied to four development projects. The time/effort tradeoff leading to savings attainable when development time on a project is extended by a few months is demonstrated. The software equation which relates the principal parameters of development time, total effort, system size, and the development environment is presented.

Golden, J. R.↗

NASA NTRS2019

Overview of the PLEXIL Plan Execution Technology and its Applications in Autonomous Piloting Projects at NASA

Automated planning is a key Artificial Intelligence technology enabling Unmanned Aerial Systems (UAS) and the eminent reality of Urban Air Mobility (UAM). It produces plans, which formalize procedures often performed by humans. Plans differ from other kinds of computer programs in their ability to react and interact with a dynamically changing environment. Aviation plans must encode the procedural knowledge, reasoning capability, and capacity for multi-tasking held by competent human pilots. Correct execution of these plans (performed by software called an executive) in the dynamic airspace environment is vital to the success of each automated flight, and the safety of the vehicle and all things in its path. In the early 2000s NASA developed a plan representation language and executive called PLEXIL (Plan Execution Interchange Language) that has successfully been applied in several NASA aviation and UAS projects. Autonomy Operating System (AOS), Cockpit Hierarchical Automated Planning and Execution (CHAP-E), and ICAROUS are all projects that have used PLEXIL to help encode and automatically execute flight procedures, some normally performed by human pilots. AOS also automates a subset of pilot/Air Traffic Control communication towards enabling UAS entry into the National Airspace. PLEXIL has been open-source software since 2008 and has seen usage in a wide range of prototypical autonomy applications in academia, government, and industry. In this presentation, we describe PLEXIL and highlight its significant accomplishments in the aviation domain.

Dalal, Michael↗

NASA NTRS2005

NASA Tech Briefs, September 2005

Topivs include: Diamond-Coated Carbon Nanotubes for Efficient Field Emission; Improved Anode Coatings for Direct Methanol Fuel Cells; Advanced Ablative Insulators and Methods of Making Them; PETIs as High-Temperature Resin-Transfer-Molding Materials; Stable Polyimides for Terrestrial and Space Uses; Low-Density, Aerogel-Filled Thermal-Insulation Tiles; High-Performance Polymers Having Low Melt Viscosities; Nonflammable, Hydrophobic Aerogel Composites for Insulation; Front-Side Microstrip Line Feeding a Raised Antenna Patch; Medium-Frequency Pseudonoise Georadar; Facilitating Navigation Through Large Archives; Program for Weibull Analysis of Fatigue Data; Comprehensive Micromechanics-Analysis Code - Version 4.0; Component-Based Visualization System; Software for Engineering Simulations of a Spacecraft; LabVIEW Interface for PCI-SpaceWire Interface Card; Path Following with Slip Compensation for a Mars Rover; International Space Station Electric Power System Performance Code-SPACE; Software for Automation of Real-Time Agents, Version 2; Software for Optimizing Plans Involving Interdependent Goals; Computing Gravitational Fields of Finite-Sized Bodies; Custom Sky-Image Mosaics from NASA's Information Power Grid; ANTLR Tree Grammar Generator and Extensions; Generic Kalman Filter Software; Alignment Stage for a Cryogenic Dilatometer; Rugged Iris Mechanism; Treatments To Produce Stabilized Aluminum Mirrors for Cryogenic Uses; Making AlNx Tunnel Barriers Using a Low-Energy Nitrogen-Ion Beam; Making Wide-IF SIS Mixers with Suspended Metal-Beam Leads; Sol-Gel Glass Holographic Light-Shaping Diffusers; Automated Counting of Particles To Quantify Cleanliness; Phase Correction for GPS Antenna with Nonunique Phase Center; Compact Infrasonic Windscreen; Broadband External-Cavity Diode Laser; High-Efficiency Solar Cells Using Photonic-Bandgap Materials; Generating Solid Models from Topographical Data; Computationally Lightweight Air-Traffic-Control Simulation; Spool Valve for Switching Air Flows Between Two Beds; Partial Model of Insulator/ Insulator Contact Charging; Asymmetric Electrostatic Radiation Shielding for Spacecraft; and Reusable Hybrid Propellant Modules for Outer-Space Transport.

Source record↗

NASA NTRS2004

Software for Analyzing Laminar-to-Turbulent Flow Transitions

Software assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures. Examples of such activities are the following: code inspections, unit tests, design reviews, performance analyses, construction of traceability matrices, etc. In practice, software development projects have only limited resources (e.g., schedule, budget, and availability of personnel) to cover the entire development effort, of which assurance is but a part. Projects must therefore select judiciously from among the possible assurance activities. At its heart, this can be viewed as an optimization problem; namely, to determine the allocation of limited resources (time, money, and personnel) to minimize risk or, alternatively, to minimize the resources needed to reduce risk to an acceptable level. The end result of the work reported here is a means to optimize quality-assurance processes used in developing software. This is achieved by combining two prior programs in an innovative manner

Chang, Chau-Lyan↗

NASA NTRS2004

Software for Optimizing Quality Assurance of Other Software

Feather, Martin↗

NASA NTRS2000

Putting ROSE to Work: A Proposed Application of a Request-Oriented Scheduling Engine for Space Station Operations

Scheduling engines are found at the core of software systems that plan and schedule activities and resources. A Request-Oriented Scheduling Engine (ROSE) is one that processes a single request (adding a task to a timeline) and then waits for another request. For the International Space Station, a robust ROSE-based system would support multiple, simultaneous users, each formulating requests (defining scheduling requirements), submitting these requests via the internet to a single scheduling engine operating on a single timeline, and immediately viewing the resulting timeline. ROSE is significantly different from the engine currently used to schedule Space Station operations. The current engine supports essentially one person at a time, with a pre-defined set of requirements from many payloads, working in either a "batch" scheduling mode or an interactive/manual scheduling mode. A planning and scheduling process that takes advantage of the features of ROSE could produce greater customer satisfaction at reduced cost and reduced flow time. This paper describes a possible ROSE-based scheduling process and identifies the additional software component required to support it. Resulting changes to the management and control of the process are also discussed.

Jaap, John↗

NASA NTRS1995

Automated Planning Of Spacecraft Telecommunications

Computer program known as SWIfT (Software for What-If Telecommunications) is user-friendly, modular, portable, window-based software tool. Accelerates and automates planning of antenna usage for spacecraft telecommunication systems and enables predictions of performances of such systems.

Veregge, John R.↗

NASA NTRS1988

OEXP Analysis Tools Workshop

This publication summarizes the software needs and available analysis tools presented at the OEXP Analysis Tools Workshop held at the NASA Langley Research Center, Hampton, Virginia on June 21 to 22, 1988. The objective of the workshop was to identify available spacecraft system (and subsystem) analysis and engineering design tools, and mission planning and analysis software that could be used for various NASA Office of Exploration (code Z) studies, specifically lunar and Mars missions.

Garrett, L. Bernard↗

NASA NTRS2012

VML 3.0 Reactive Sequencing Objects and Matrix Math Operations for Attitude Profiling

VML (Virtual Machine Language) has been used as the sequencing flight software on over a dozen JPL deep-space missions, most recently flying on GRAIL and JUNO. In conjunction with the NASA SBIR entitled "Reactive Rendezvous and Docking Sequencer", VML version 3.0 has been enhanced to include object-oriented element organization, built-in queuing operations, and sophisticated matrix / vector operations. These improvements allow VML scripts to easily perform much of the work that formerly would have required a great deal of expensive flight software development to realize. Autonomous turning and tracking makes considerable use of new VML features. Profiles generated by flight software are managed using object-oriented VML data constructs executed in discrete time by the VML flight software. VML vector and matrix operations provide the ability to calculate and supply quaternions to the attitude controller flight software which produces torque requests. Using VML-based attitude planning components eliminates flight software development effort, and reduces corresponding costs. In addition, the direct management of the quaternions allows turning and tracking to be tied in with sophisticated high-level VML state machines. These state machines provide autonomous management of spacecraft operations during critical tasks like a hypothetic Mars sample return rendezvous and docking. State machines created for autonomous science observations can also use this sort of attitude planning system, allowing heightened autonomy levels to reduce operations costs. VML state machines cannot be considered merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. The state machine approach enabled by VML 3.0 is progressing toward flight capability with a wide array of applicable mission activities.

VML (Virtual Machine Language)↗

NASA NTRS1987

A report on NASA software engineering and Ada training requirements

NASA's software engineering and Ada skill base are assessed and information that may result in new models for software engineering, Ada training plans, and curricula are provided. A quantitative assessment which reflects the requirements for software engineering and Ada training across NASA is provided. A recommended implementation plan including a suggested curriculum with associated duration per course and suggested means of delivery is also provided. The distinction between education and training is made. Although it was directed to focus on NASA's need for the latter, the key relationships to software engineering education are also identified. A rationale and strategy for implementing a life cycle education and training program are detailed in support of improved software engineering practices and the transition to Ada.

Legrand, Sue↗

NASA NTRS2017

Increasing Crew Autonomy for Long Duration Exploration Missions: Self-Scheduling

Over the last three years, we have been investigating the operational concept of crew self-scheduling as a method of increasing crew autonomy for future exploration missions. Through Playbook, a planning and scheduling software tool, we have incrementally increased the ability for Earth analog mission crews to modify their schedules. Playbook allows the crew to add new activities from scratch, add new activities or groups of activities through a Task List, and reschedule or reassign flexible activities. The crew is also able to identify if plan modifications create violations, i.e., plan constraints not being met. This paper summarizes our observations with qualitative evidence from four NASA Extreme Environment Mission Operations (NEEMO) analog missions that supported self-scheduling as a feasible operational concept.

crew autonomy↗