Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission 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 289 records · Page 16
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Development of algorithms for understanding the temporal and spatial variability of the earth's radiation balance

A brief description is given of how temporal and spatial variability in the earth's radiative behavior influences the goals of satellite radiation monitoring systems and how some previous systems have addressed the existing problems. Then, results of some simulations of radiation budget monitoring missions are presented. These studies led to the design of the Earth Radiation Budget Experiment (ERBE). A description is given of the temporal and spatial averaging algorithms developed for the ERBE data analysis. These algorithms are intended primarily to produce monthly averages of the net radiant exitance on regional, zonal, and global scales and to provide insight into the regional diurnal variability of radiative parameters such as albedo and long-wave radiant exitance. The algorithms are applied to scanner and nonscanner data for up to three satellites. Modeling of dialy shortwave albedo and radiant exitance with satellite samling that is insufficient to fully account for changing meteorology is discussed in detail. Studies performed during the ERBE mission and software design are reviewed. These studies provide quantitative estimates of the effects of temporally sparse and biased sampling on inferred diurnal and regional radiative parameters. Other topics covered include long-wave diurnal modeling, extraction of a regional monthly net clear-sky radiation budget, the statistical significance of observed diurnal variability, quality control of the analysis, and proposals for validating the results of ERBE time and space averaging.

Brooks, D. R.↗
NASA NTRS1986

Sequencing Voyager II for the Uranus encounter

The process of developing the programmed sequence of events necessary for the Voyager 2 spacecraft to return desired data from its Uranus encounter is discussed. The major steps in the sequence process are reviewed, and the elements of the Mission Sequence Software are described. The design phase and the implementation phase of the sequence process are discussed, and the Computer Command Subsystem architecture is examined in detail. The software's role in constructing the sequences and converting them into onboard programs is elucidated, and the problems unique to the Uranus encounter sequences are considered.

Morris, R. B.↗
NASA NTRS1988

An intelligent interface for satellite operations: Your Orbit Determination Assistant (YODA)

An intelligent interface is often characterized by the ability to adapt evaluation criteria as the environment and user goals change. Some factors that impact these adaptations are redefinition of task goals and, hence, user requirements; time criticality; and system status. To implement adaptations affected by these factors, a new set of capabilities must be incorporated into the human-computer interface design. These capabilities include: (1) dynamic update and removal of control states based on user inputs, (2) generation and removal of logical dependencies as change occurs, (3) uniform and smooth interfacing to numerous processes, databases, and expert systems, and (4) unobtrusive on-line assistance to users of concepts were applied and incorporated into a human-computer interface using artificial intelligence techniques to create a prototype expert system, Your Orbit Determination Assistant (YODA). YODA is a smart interface that supports, in real teime, orbit analysts who must determine the location of a satellite during the station acquisition phase of a mission. Also described is the integration of four knowledge sources required to support the orbit determination assistant: orbital mechanics, spacecraft specifications, characteristics of the mission support software, and orbit analyst experience. This initial effort is continuing with expansion of YODA's capabilities, including evaluation of results of the orbit determination task.

Schur, Anne↗
NASA NTRS1991

Data systems and computer science: Software Engineering Program

An external review of the Integrated Technology Plan for the Civil Space Program is presented. This review is specifically concerned with the Software Engineering Program. The goals of the Software Engineering Program are as follows: (1) improve NASA's ability to manage development, operation, and maintenance of complex software systems; (2) decrease NASA's cost and risk in engineering complex software systems; and (3) provide technology to assure safety and reliability of software in mission critical applications.

Zygielbaum, Arthur I.↗
NASA NTRS1994

Ground Station support for small scientific satellites

In order to keep the cost of a complete small satellite program low, it is necessary to minimize the cost of the ground station operations and support. This is required not only for the operations and support per se, but also in the development of ground station hardware and the mission associated software. Recent experiences at the Rutherford Appleton Laboratory (RAL) on two international projects, IRAS and AMPTE, have shown that the low cost objectives of operations using smaller national facilities can be achieved. This paper describes the facilities at RAL, and the methods by which low cost support are provided by considering the differing implications of hardware/software system modularity, reliability, and small numbers of dedicated and highly skilled operations staff.

Holdaway, R.↗
NASA NTRS1996

A space demonstration of the next generation TT and C standards

An initiative to develop an integrated set of space data communication protocols, which will complement and expand upon the current Consultative Committee for Space Data Systems (CCSDS) telemetry and telecommand standards, is reported on. The aim is to provide a comprehensive set of spacecraft control and monitoring data handling services. The space communications protocol standards (SCPS) initiative will provide a set of spacecraft telemetry, telecommand and control (TT and C) standards that will serve a wide range of civilian and military space missions. A software flight test and demonstration of the capabilities of the SCPS protocols was performed using the in orbit space technology research vehicle and compared to laboratory simulations. The results from this test will contribute to the continued SCPS protocol development program.

Shave, N. P.↗
NASA NTRS1998

Incorporating Parallel Computing into the Goddard Earth Observing System Data Assimilation System (GEOS DAS)

Atmospheric data assimilation is a method of combining actual observations with model forecasts to produce a more accurate description of the earth system than the observations or forecast alone can provide. The output of data assimilation, sometimes called the analysis, are regular, gridded datasets of observed and unobserved variables. Analysis plays a key role in numerical weather prediction and is becoming increasingly important for climate research. These applications, and the need for timely validation of scientific enhancements to the data assimilation system pose computational demands that are best met by distributed parallel software. The mission of the NASA Data Assimilation Office (DAO) is to provide datasets for climate research and to support NASA satellite and aircraft missions. The system used to create these datasets is the Goddard Earth Observing System Data Assimilation System (GEOS DAS). The core components of the the GEOS DAS are: the GEOS General Circulation Model (GCM), the Physical-space Statistical Analysis System (PSAS), the Observer, the on-line Quality Control (QC) system, the Coupler (which feeds analysis increments back to the GCM), and an I/O package for processing the large amounts of data the system produces (which will be described in another presentation in this session). The discussion will center on the following issues: the computational complexity for the whole GEOS DAS, assessment of the performance of the individual elements of GEOS DAS, and parallelization strategy for some of the components of the system.

Larson, Jay W.↗
NASA NTRS1997

The Generalized Support Software (GSS) Domain Engineering Process: An Object-Oriented Implementation and Reuse Success at Goddard Space Flight Center

The Flight Dynamics Division (FDD) of NASA's Goddard Space Flight Center (GSFC) recently embarked on a far-reaching revision of its process for developing and maintaining satellite support software. The new process relies on an object-oriented software development method supported by a domain specific library of generalized components. This Generalized Support Software (GSS) Domain Engineering Process is currently in use at the NASA GSFC Software Engineering Laboratory (SEL). The key facets of the GSS process are (1) an architecture for rapid deployment of FDD applications, (2) a reuse asset library for FDD classes, and (3) a paradigm shift from developing software to configuring software for mission support. This paper describes the GSS architecture and process, results of fielding the first applications, lessons learned, and future directions

Condon, Steven↗
NASA NTRS1997

Using Common Graphics Paradigms Implemented in a Java Applet to Represent Complex Scheduling Requirements

The experiments planned for the International Space Station promise to be complex, lengthy and diverse. The scarcity of the space station resources will cause significant competition for resources between experiments. The scheduling job facing the Space Station mission planning software requires a concise and comprehensive description of the experiments' requirements (to ensure a valid schedule) and a good description of the experiments' flexibility (to effectively utilize available resources). In addition, the continuous operation of the station, the wide geographic dispersion of station users, and the budgetary pressure to reduce operations manpower make a low-cost solution mandatory. A graphical representation of the scheduling requirements for station payloads implemented via an Internet-based application promises to be an elegant solution that addresses all of these issues. The graphical representation of experiment requirements permits a station user to describe his experiment by defining "activities" and "sequences of activities". Activities define the resource requirements (with alternatives) and other quantitative constraints of tasks to be performed. Activities definitions use an "outline" graphics paradigm. Sequences define the time relationships between activities. Sequences may also define time relationships with activities of other payloads or space station systems. Sequences of activities are described by a "network" graphics paradigm. The bulk of this paper will describe the graphical approach to representing requirements and provide examples that show the ease and clarity with which complex requirements can be represented. A Java applet, to run in a web browser, is being developed to support the graphical representation of payload scheduling requirements. Implementing the entry and editing of requirements via the web solves the problems introduced by the geographic dispersion of users. Reducing manpower is accomplished by developing a concise representation which eliminates the misunderstanding possible with verbose representations and which captures the complete requirements and flexibility of the experiments.

Jaap, John↗
NASA NTRS1998

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗
NASA NTRS1995

Astronomy Aid

As a Jet Propulsion Laboratory astronomer, John D. Callahan developed a computer program called Multimission Interactive Planner (MIP) to help astronomers analyze scientific and optical data collected on the Voyager's Grand Tour. The commercial version of the program called XonVu is published by XonTech, Inc. Callahan has since developed two more advanced programs based on MIP technology, Grand Tour and Jovian Traveler, which simulate Voyager and Giotto missions. The software allows astronomers and space novices to view the objects seen by the spacecraft, manipulating perspective, distance and field of vision.

Source record↗
NASA NTRS2002

The Console in A Briefcase: An Approach to Remote Space Operations

The CIAB (Console in a Briefcase) is conceived as an ISS (International Space Station) Payload Operations remote console that would run via an Internet connection, consisting of components (primarily a laptop PC) that fit into a briefcase, and intended for use from home in an 'on call' scenario. The primary purpose of the CIAB project is to verify that the technology and tools exist to support remote-access payload operations for the International Space Station (ISS) and to build, test, and demonstrate a prototype system. The project can potentially provide cost savings and increased morale to the space operations community by reducing demands on staff. Also, the CIAB project provides a vehicle for examining innovative concepts pertaining to Mission Planning software tools that have potential benefits beyond just the immediate needs of remote access. To date we have implemented and tested the basic capability. Current research is focused on reducing bandwidth demands via the adoption of innovative software solutions. Research into current Internet connectivity and bandwidth is also being pursued.

Heaton, Andy F.↗
NASA NTRS2002

Shield Optimization in Simple Geometry for the Gateway Concept

The great cost of added radiation shielding is a potential limiting factor in many deep space missions. For this enabling technology, we are developing tools for optimized shield design over multi-segmented missions involving multiple work and living areas in the transport and duty phase of various space missions. The total shield mass over all pieces of equipment and habitats is optimized subject to career dose and dose rate constraints. Preliminary studies of deep space missions indicate that for long duration space missions, improved shield materials will be required. The details of this new method and its impact on space missions and other technologies will be discussed. This study will provide a vital tool for evaluating Gateway designs in their usage context. Providing protection against the hazards of space radiation is one of the challenges to the Gateway infrastructure designs. We will use the mission optimization software to scope the impact of Gateway operations on human exposures and the effectiveness of alternate shielding materials on Gateway infrastructure designs. This study will provide a guide to the effectiveness of multifunctional materials in preparation to more detailed geometry studies in progress.

Tripathi, R. K.↗
NASA NTRS1996

Asynchronous Message Passing in the JPL Flight System Testbed

The flight mission simulation software in the Jet Propulsion Laboratory's Flight System Testbed (FST) is a heterogeneous, distributed system that is built on an interprocess communication model of asynchronous message passing rather than remote procedure calls (RPCs). The reasoning behind this design decision is discussed; the mechanism used to implement it (.

message passing RPC interprocess communication dis↗