Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Execution”

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 1,441 records · Page 80

JAVA PathFinder

JPF is an explicit state software model checker for Java bytecode. Today, JPF is a swiss army knife for all sort of runtime based verification purposes. This basically means JPF is a Java virtual machine that executes your program not just once (like a normal VM), but theoretically in all possible ways, checking for property violations like deadlocks or unhandled exceptions along all potential execution paths. If it finds an error, JPF reports the whole execution that leads to it. Unlike a normal debugger, JPF keeps track of every step how it got to the defect.

Mehhtz, Peter↗

Master Software Requirements Specification

A basic function of a computational grid such as the NASA Information Power Grid (IPG) is to allow users to execute applications on remote computer systems. The Globus Resource Allocation Manager (GRAM) provides this functionality in the IPG and many other grids at this time. While the functionality provided by GRAM clients is adequate, GRAM does not support useful features such as staging several sets of files, running more than one executable in a single job submission, and maintaining historical information about execution operations. This specification is intended to provide the environmental and software functional requirements for the IPG Job Manager V2.0 being developed by AMTI for NASA.

Hu, Chaumin↗

Automated Derivation of Complex System Constraints from User Requirements

International Space Station (ISS) payload developers submit their payload science requirements for the development of on-board execution timelines. The ISS systems required to execute the payload science operations must be represented as constraints for the execution timeline. Payload developers use a software application, User Requirements Collection (URC), to submit their requirements by selecting a simplified representation of ISS system constraints. To fully represent the complex ISS systems, the constraints require a level of detail that is beyond the insight of the payload developer. To provide the complex representation of the ISS system constraints, HOSC operations personnel, specifically the Payload Activity Requirements Coordinators (PARC), manually translate the payload developers simplified constraints into detailed ISS system constraints used for scheduling the payload activities in the Consolidated Planning System (CPS). This paper describes the implementation for a software application, User Requirements Integration (URI), developed to automate the manual ISS constraint translation process.

Muery, Kim↗

Integrated Planning for Telepresence with Time Delays

Teleoperation of remote robotic systems over time delays in the range of 2-10 seconds poses a unique set of challenges. In the context of a supervisory control system for the JSC Robonaut humanoid robot, we have developed an 'intelligent assistant' that integrates an Artificial Intelligence planner (JSHOP2) with execution monitoring of the state of both the human supervisor and the remote robot. The assistant reasons simultaneously about the world state on both sides of the time delay, which represents a novel application of this technology. The purpose of the assistant is to provide advice to the human supervisor about current and future activities, derived from a sequence of high-level goals to be achieved. To do this, the assistant must simultaneously monitor and react to various data sources, including actions taken by the supervisor who is issuing commands to the robot (e.g. with a data glove), actions taken by the robot, and the environment of the robot, both as currently perceived over the time delay, along with the current sequence of goals. We have developed a 'leader/follower' software architecture to handle the dual time-shifted streams of execution feedback. In this paper we describe the integrated planner and its executive, and how it operates in normal and anomaly situations.

remote robotic systems↗

Advanced Technologies for Future Spacecraft Cockpits and Space-based Control Centers

The National Aeronautics and Space Administration (NASA) is embarking on a new era of Space Exploration, aimed at sending crewed spacecraft beyond Low Earth Orbit (LEO), in medium and long duration missions to the Lunar surface, Mars and beyond. The challenges of such missions are significant and will require new technologies and paradigms in vehicle design and mission operations. Current roles and responsibilities of spacecraft systems, crew and the flight control team, for example, may not be sustainable when real-time support is not assured due to distance-induced communication lags, radio blackouts, equipment failures, or other unexpected factors. Therefore, technologies and applications that enable greater Systems and Mission Management capabilities on-board the space-based system will be necessary to reduce the dependency on real-time critical Earth-based support. The focus of this paper is in such technologies that will be required to bring advance Systems and Mission Management capabilities to space-based environments where the crew will be required to manage both the systems performance and mission execution without dependence on the ground. We refer to this concept as autonomy. Environments that require high levels of autonomy include the cockpits of future spacecraft such as the Mars Exploration Vehicle, and space-based control centers such as a Lunar Base Command and Control Center. Furthermore, this paper will evaluate the requirements, available technology, and roadmap to enable full operational implementation of onboard System Health Management, Mission Planning/re-planning, Autonomous Task/Command Execution, and Human Computer Interface applications. The technology topics covered by the paper include enabling technology to perform Intelligent Caution and Warning, where the systems provides directly actionable data for human understanding and response to failures, task automation applications that automate nominal and Off-nominal task execution based on human input or integrated health state-derived conditions. Shifting from Systems to Mission Management functions, we discuss the role of automated planning applications (tactical planning) on-board, which receive data from the other cockpit automation systems and evaluate the mission plan against the dynamic systems and mission states and events, to provide the crew with capabilities that enable them to understand, change, and manage the timeline of their mission. Lastly, we discuss the role of advanced human interface technologies that organize and provide the system md mission information to the crew in ways that maximize their situational awareness and ability to provide oversight and control of aLl the automated data and functions.

Garcia-Galan, Carlos↗

NASA CEV On-Orbit GN&C Analysis

The Orion spacecraft orbit GN&C system will be required to perform both ISS servicing missions and Lunar sortie and outpost crew transportation. While certain aspects of these two missions are complementary, the two missions are also distinct in many ways. Common between the missions is a Low Earth Orbit (LEO) rendezvous, one with the ISS And the other with the LSAM/EDS stack prior to trans-lunar insertion. The lunar missions will additionally require Orion to perform orbit maintenance in LLO, perform contingency lunar orbit operations including RPOD with the LSAM, perform the TEI maneuver sequence, and execute the trans-Earth cruise. The NASA-led team developed a reference configuration orbit GN&C system capable of executing all of these activities with the same navigation sensor suite and control effectors while fully meeting the requirements being developed for System Requirements Review in advance of prime contractor selection. This paper will present an overview of the analyses performed to support system trade studies, demonstrate the feasibility of the NASA reference configuration, and validate the Orion system requirements. These analyses include linear covariance techniques, 3-DOF Monte Carlo simulations, 6-DOF Monte Carlo simulations, and analytical evaluations of GN&C systems performed by the NASA-led Orion team to characterize the sensitivities of Orion s various missions and assess the unique challenges of each. The first part of this paper will describe the trade studies that were performed in order to characterize the RPOD system performance for both the ISS and the lunar missions including development of an RPOD operations concept, RPOD trajectories, contingency scenarios, docking mechanism and associated contact conditions, post-contact thrust issues, relative navigation sensors, relative navigation sensor target infrastructure. The paper will also discuss concepts for both manually-piloted and automatically executed scenarios, as well as the remotely-piloted contingency scenario in LLO. The second part of the paper will discuss the analyses performed for lunar and cislunar GN&C performance including the accuracy of the post-insertion lunar orbit, the ability of Orion to hit a particular Earth return entry corridor, attitude control solutions for long-duration surface operations, and autonomous navigation in support of TEI without ground tracking.

DSouza, Chris↗

Adapting Covariance Propagation to Account for the Presence of Modeled and Unmodeled Maneuvers

This paper explores techniques that can be used to adapt the standard linearized propagation of an orbital covariance matrix to the case where there is a maneuver and an associated execution uncertainty. A Monte Carlo technique is used to construct a final orbital covariance matrix for a 'propagate-burn-propagate' process that takes into account initial state uncertainty and execution uncertainties in the maneuver magnitude. This final orbital covariance matrix is regarded as 'truth' and comparisons between it and three methods using modified linearized covariance propagation are made. The first method accounts for the maneuver by modeling its nominal effect within the state transition matrix but excludes the execution uncertainty by omitting a process noise matrix from the computation. In the second method, the maneuver is not modeled but the uncertainty in its magnitude is accounted for by the inclusion of a process noise matrix. In the third method, which is essentially a hybrid of the first two, the nominal portion of the maneuver is included via the state transition matrix while a process noise matrix is used to account for the magnitude uncertainty. Since this method also correctly accounts for the presence of the maneuver in the nominal orbit, it is the best method for applications involving the computation of times of closest approach and the corresponding probability of collision, Pc. However, applications for the two other methods exist and are briefly discussed. Despite the fact that the process model ('propagate-burn-propagate') that was studied was very simple - point-mass gravitational effects due to the Earth combined with an impulsive delta-V in the velocity direction for the maneuver - generalizations to more complex scenarios, including high fidelity force models, finite duration maneuvers, and maneuver pointing errors, are straightforward and are discussed in the conclusion.

Schiff, Conrad↗

Anomaly Recovery and the Mars Exploration Rovers

The premise of the design of operations for the Mars Exploration Rovers (MER) is that the vehicles will drive each day. As a result, they will encounter some aspect of the terrain environment that cannot be anticipated or otherwise accommodated by the sequences linked onboard that day. The operations team then must correct the problem by planning then commanding the execution of a different drive the next day. Often other aspects of the operation on the surface of Mars: environmental changes, component degradation, errors in sequence design or execution, etc., lead to anomalies which must be addressed before normal operations can resume. The operational design that makes it possible to recover from a driving error each day also reduces the time needed to recover from anomalies. As an example of the efficiency achieved, less than 5% (about 30 sols out of 700 sols of operations) of the time on the surface has been devoted to recovery from anomalies for each vehicle. In this paper the major anomalies experienced by the MER rovers will be recounted and the streamlined approaches to addressing these problems described. The operational flexibility developed for these missions is also a function of the system design that anticipated a number of likely faults and conditions arising from uncertainty in sequence execution and environmental change. This design will be described as well as the considerations in operation that motivated this design. These considerations will likely be present in any future surface mission.

rovers↗

Adapting Covariance Propagation to Account for the Presence of Modeled and Unmodeled Maneuvers

This paper explores techniques that can be used to adapt the standard linearized propagation of an orbital covariance matrix to the case where there is a maneuver and an associated execution uncertainty. A Monte Carlo technique is used to construct a final orbital covariance matrix for a 'prop-burn-prop' process that takes into account initial state uncertainty and execution uncertainties in the maneuver magnitude. This final orbital covariance matrix is regarded as 'truth' and comparisons are made with three methods using modified linearized covariance propagation. The first method accounts for the maneuver by modeling its nominal effect within the state transition matrix but excludes the execution uncertainty by omitting a process noise matrix from the computation. The second method does not model the maneuver but includes a process noise matrix to account for the uncertainty in its magnitude. The third method, which is essentially a hybrid of the first two, includes the nominal portion of the maneuver via the state transition matrix and uses a process noise matrix to account for the magnitude uncertainty. The first method is unable to produce the final orbit covariance except in the case of zero maneuver uncertainty. The second method yields good accuracy for the final covariance matrix but fails to model the final orbital state accurately. Agreement between the simulated covariance data produced by this method and the Monte Carlo truth data fell within 0.5-2.5 percent over a range of maneuver sizes that span two orders of magnitude (0.1-20 m/s). The third method, which yields a combination of good accuracy in the computation of the final covariance matrix and correct accounting for the presence of the maneuver in the nominal orbit, is the best method for applications involving the computation of times of closest approach and the corresponding probability of collision, PC. However, applications for the two other methods exist and are briefly discussed. Although the process model ("prop-burn-prop") that was studied is very simple - point-mass gravitational effects due to the Earth combined with an impulsive delta-V in the velocity direction for the maneuver - generalizations to more complex scenarios, including high fidelity force models, finite duration maneuvers, and maneuver pointing errors, are straightforward and are discussed in the conclusion.

Schiff, Conrad↗

Model Checking Abstract PLEXIL Programs with SMART

We describe a method to automatically generate discrete-state models of abstract Plan Execution Interchange Language (PLEXIL) programs that can be analyzed using model checking tools. Starting from a high-level description of a PLEXIL program or a family of programs with common characteristics, the generator lays the framework that models the principles of program execution. The concrete parts of the program are not automatically generated, but require the modeler to introduce them by hand. As a case study, we generate models to verify properties of the PLEXIL macro constructs that are introduced as shorthand notation. After an exhaustive analysis, we conclude that the macro definitions obey the intended semantics and behave as expected, but contingently on a few specific requirements on the timing semantics of micro-steps in the concrete executive implementation.

Siminiceanu, Radu I.↗

Spitzer Space Telescope Sequencing Operations Software, Strategies, and Lessons Learned

The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.

missions operations↗

MGS and Odyssey - Relay Satellites for the MER Mission

Both Mars Global Surveyor (MGS) and Mars Odyssey are currently in low altitude, nearly circular and highly inclined orbits about Mars. Thus, they are available and compatible to serve as relay satellites for the Mars Exploration Rover (MER) mission. Consequently, the MER project developed requirements for MGS to be overhead, at a specific time with a 30 second tolerance, during the atmospheric entry, descent and landing (EDL) phase of both MER vehicles. The result, after execution of a single orbit synchronization maneuver (OSM) on 10/03/03, 92.4 days or 1130 orbits before Spirit's EDL, was that MGS was over Spirit 8 seconds past the required time. This maneuver, with a delta-velocity of 0.534 m/s, caused the orbital period to change by 3.34 s and resulted in a time-phasing change of 62 min 19 s in order to achieve the EDL overflight. Based on the navigation and execution of an OSM on 01/04/04, MGS was overhead for the Opportunity EDL on 01/25/04,3.5 seconds after the required epoch. Requirements also existed for the Odyssey over-flight of the MER rovers after landing and various equipment deployments had been completed. Thus, these requirements were that Odyssey should rise no earlier than specified times with respect to each of the landing sites. The Odyssey over-flights of both Spirit and Opportunity on sol 1 were equally successful. This paper will present the navigation plan, trajectory propagation accuracy and maneuver execution for the successful MGS and Odyssey over-flights of both the MER rovers.

Mars Global Surveyor (MGS)↗

RTSJ Memory Areas and Their Affects on the Performance of a Flight-Like Attitude Control System

The two most important factors in improving performance in any software system, but especially a real-time, embedded system, are knowing which components are the low performers and knowing what can be done to improve their performance. The word performance with respect to a real-time, embedded system does not necessarily mean fast execution, which is the common definition when discussing non real-time systems. It also includes meeting all of the specified execution dead-lines and executing at the correct time without sacrificing non real-time performance. Using a Java prototype of an existing control system used on Deep Space 1[1], the effects from adding memory areas are measured and evaluated with respect to improving performance.

Real-time Specification for Java2 (RTSJ)↗

Method for resource control in parallel environments using program organization and run-time support

A system and method for dynamic scheduling and allocation of resources to parallel applications during the course of their execution. By establishing well-defined interactions between an executing job and the parallel system, the system and method support dynamic reconfiguration of processor partitions, dynamic distribution and redistribution of data, communication among cooperating applications, and various other monitoring actions. The interactions occur only at specific points in the execution of the program where the aforementioned operations can be performed efficiently.

Ekanadham, Kattamuri↗

Method for resource control in parallel environments using program organization and run-time support

A system and method for dynamic scheduling and allocation of resources to parallel applications during the course of their execution. By establishing well-defined interactions between an executing job and the parallel system, the system and method support dynamic reconfiguration of processor partitions, dynamic distribution and redistribution of data, communication among cooperating applications, and various other monitoring actions. The interactions occur only at specific points in the execution of the program where the aforementioned operations can be performed efficiently.

Ekanadham, Kattamuri↗

Method for distributed object communications based on dynamically acquired and assembled software components

A method for acquiring and assembling software components at execution time into a client program, where the components may be acquired from remote networked servers is disclosed. The acquired components are assembled according to knowledge represented within one or more acquired mediating components. A mediating component implements knowledge of an object model. A mediating component uses its implemented object model knowledge, acquired component class information and polymorphism to assemble components into an interacting program at execution time. The interactions or abstract relationships between components in the object model may be implemented by the mediating component as direct invocations or indirect events or software bus exchanges. The acquired components may establish communications with remote servers. The acquired components may also present a user interface representing data to be exchanged with the remote servers. The mediating components may be assembled into layers, allowing arbitrarily complex programs to be constructed at execution time.

Sundermier, Amy↗

Impacts of Center of Mass Shifts on Messenger Spacecraft Operations

The MESSENGER (MErcury Surface, Space ENvironment, GEochemistry, and Ranging) has successfully completed its first three years of flight operations following launch on August 3, 2004. As part of NASA s Discovery Program, MESSENGER will observe Mercury during flybys in 2008 and 2009, as well as from orbit beginning in March 2011. This paper discusses the impact that center of mass (CM) location changes have had on many mission activities, particularly angular momentum management and maneuver execution. Momentum trends were altered significantly following the first deep-space maneuver, and these changes were related to a change in the CM. The CM location also impacts maneuver execution, and uncertainties in its location led to the significant direction errors experienced at trajectory correction maneuver 11. Because of the spacecraft sensitivity to CM location, efforts to estimate its position are important to momentum and maneuver prediction. This paper summarizes efforts to estimate the CM from flight data, as well as the operational strategy to handle CM uncertainties and their impact on momentum trends and maneuver execution accuracy.

O'Shaughnessy, D. J.↗

Mars Reconnaissance Orbiter Wrapper Script

The MRO OLVM wrapper script software allows Mars Reconnaissance Orbiter (MRO) sequence and spacecraft engineers to rapidly simulate a spacecraft command product through a tool that simulates the onboard sequence management software (OLVM). This script parses sequence files to determine the appropriate time boundaries for the sequence, and constructs the script file to be executed by OLVM to span the entirety of the designated sequence. It then constructs script files to be executed by OLVM, constructs the appropriate file directories, populates these directories with needed input files, initiates OLVM to simulate the actual command product that will be sent to the spacecraft, and captures the results of the simulation run to an external file for later review. Additionally, the tool allows a user to manually construct the script, if desired, and then execute the script with a simple command line.

Gladden, Roy↗