SEARCH · Engineering Papers
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.
Software modules associated with various flight control functions for the space shuttle orbiter are described. Data flow, interface requirements, initialization requirements and module sequencing requirements are considered. Block diagrams and tables are included.
The engineering analyses and evaluation studies conducted for the Software Requirements Analysis are discussed. Included are the development of the study data base, synthesis of implementation approaches for software required by both mandatory onboard computer services and command/control functions, and identification and implementation of software for ground processing activities.
Power system planning software remains fragmented across organizational boundaries, with specialized tools for capacity expansion, production cost modeling, power flow, and dynamic analysis operating on incompatible data models and assumptions. This article argues that the fragmentation is not merely a technical problem but a predictable consequence of Conway's law: software architectures mirror the departmental structures within which they are developed. Regulatory milestones like Federal Energy Regulatory Commission (FERC) Order 888 formalized these divisions, but the roots trace back to the distinct engineering disciplines-mechanical, chemical, and electrical-that staffed generation and transmission planning departments in vertically integrated utilities. As the industry moves toward integrated system planning (ISP) that coordinates generation, transmission, and distribution investment decisions, the software ecosystem must evolve accordingly. We identify five categories of software requirements to enable this transition: coherent data inputs decoupled from individual applications, unified and extensible data schemas, modular component representations that support multiple abstraction levels, lifecycle management of planning datasets, and well-defined application programming interface (API) contracts that separate data exchange from algorithmic control. We examine how these requirements interact with three common workflow patterns-serial gate clearing, sequential multiapplication, and convergence oriented-and discuss the interface design principles each demands. We then outline a vision for platform-based planning architectures where specialized analytical services compose through standardized interfaces and where artificial intelligence (AI)/machine learning (ML) tools augment decision support within a disciplined software infrastructure. The practices proposed here offer a path from today's siloed tool collections toward collaborative planning ecosystems capable of handling the complexity of modern power system transformation.
Candidate designs and their software implementation are presented for the Orbital Maneuvering System (OMS) Failure Detection and Identification (FDI) algorithms in the Redundance Management (RM) module of the Space Shuttle Guidance, Navigation, and Control (GN&C) software. The OMS engine FDI algorithm monitors OMS engine thrust performance, and the OMS actuator FDI algorithm monitors OMS gimbal actuator performance. The software functional requirements of the algorithms are described along with the objective of each algorithm. A list of the assumptions which have governed its design, input/output requirements, a functional description of the algorithm (including a functional block diagram), and input interface requirements are given. The HAL (the language of the space shuttle flight computer) software formulation of the algorithms is considered including structured flowcharts of the procedures, estimates of flight computer core storage and CPU time, and processing requirements. A glossary of the symbols used to define the software requirements and formulations is included.
Navigation software design requirements are presented for the orbital flight test phase of space shuttle. Computer loads for the entire onorbit-2 operation are documented.
Hardware and software requirements for propulsion flight analysis computers
The software requirements for the study of contextual classifiers and imperfections in the labels are presented. In particular, the requirements are described for updating the posteriori probability of the picture element under consideration using information from its local neighborhood, designing the Fisher classifier, and other required routines. Only the necessary equations are given for the development of software.
An investigation of software costs related to space shuttle upper stage operations with emphasis on the additional costs attributable to space servicing was conducted. The questions and problem areas include the following: (1) the key parameters involved with software costs; (2) historical data for extrapolation of future costs; (3) elements of the basic software development effort that are applicable to servicing functions; (4) effect of multiple servicing on complexity of the operation; and (5) are recurring software costs significant. The results address these questions and provide a foundation for estimating software costs based on the costs of similar programs and a series of empirical factors.
The desirability and feasibility of computer-augmented support for the pre-implementation activities occurring during the development of flight control software was investigated. The specific topics to be investigated were the capabilities to be included in a pre-implementation support system for flight control software system development, and the specification of a preliminary design for such a system. Further, the pre-implementation support system was to be characterized and specified under the constraints that it: (1) support both description and assessment of flight control software requirements definitions and design specification; (2) account for known software description and assessment techniques; (3) be compatible with existing and planned NASA flight control software development support system; and (4) does not impose, but may encourage, specific development technologies. An overview of the results is given.
A computer program has been developed for designing and analyzing the performance of solar array/battery power systems for the U.S. Coast Guard Navigational Aids. This program is called the Design Synthesis/Performance Analysis (DSPA) Computer Program. The basic function of the Design Synthesis portion of the DSPA program is to evaluate functional and economic criteria to provide specifications for viable solar array/battery power systems. The basic function of the Performance Analysis portion of the DSPA program is to simulate the operation of solar array/battery power systems under specific loads and environmental conditions. This document establishes the software requirements for the DSPA computer program, discusses the processing that occurs within the program, and defines the necessary interfaces for operation.
Of the six or seven phases of the software engineering life cycle, requirements analysis tends to be the least understood and the least formalized. Correspondingly, a scarcity of useful software tools exist which aid in the development of user and system requirements. It is proposed that requirements analysis should culminate in a set of documents similar to those that usually accompany a delivered Software product. The design of a software tool, the Document Structure Editor, which facilitates the development of such documentation.
The current baseline method and software implementation of the space shuttle reaction control subsystem failure detection and identification (RCS FDI) system is presented. This algorithm is recommended for conclusion in the redundancy management (RM) module of the space shuttle guidance, navigation, and control system. Supporting software is presented, and recommended for inclusion in the system management (SM) and display and control (D&C) systems. RCS FDI uses data from sensors in the jets, in the manifold isolation valves, and in the RCS fuel and oxidizer storage tanks. A list of jet failures and fuel imbalance warnings is generated for use by the jet selection algorithm of the on-orbit and entry flight control systems, and to inform the crew and ground controllers of RCS failure status. Manifold isolation valve close commands are generated in the event of failed on or leaking jets to prevent loss of large quantities of RCS fuel.
The functional data processing requirements are described for the Crop Assessment Subsystem of the Large Area Crop Inventory Experiment. These requirements are used as a guide for software development and implementation.
The primary objective of this study was to develop an integrated approach for the development, implementation, and utilization of all software that is required to efficiently and cost-effectively support advanced technology laboratory flight and ground operations. It was recognized that certain aspects of the operations would be mandatory computerized services; computerization of other aspects would be optional. Thus, the analyses encompassed not only alternate computer utilization and implementations but trade studies of the programmatic effects of non-computerized versus computerized approaches to the operations. A general overview of the study is presented.
At NASA Goddard, the role of the command management system (CMS) is to transform general requests for spacecraft opeerations into detailed operational plans to be uplinked to the spacecraft. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Presently, it takes one to three years, with meetings once or twice a week, to determine functional requirements for CMS software design. As an alternative approach to the present technique of developing CMS software functional requirements, an expert system prototype was developed to aid in this function. Specifically, the knowledge base was formulated through interactions with domain experts, and was then linked to an existing expert system application generator called 'Knowledge Engineering System (Version 1.3).' Knowledge base development focused on four major steps: (1) develop the problem-oriented attribute hierachy; (2) determine the knowledge management approach; (3) encode the knowledge base; and (4) validate, test, certify, and evaluate the knowledge base and the expert system prototype as a whole. Backcasting was accomplished for validating and testing the expert system prototype. Knowledge refinement, evaluation, and implementation procedures of the expert system prototype were then transacted.
The shuttle GN&C software functions for horizontal flight operations are defined. Software functional requirements are grouped into two categories: first horizontal flight requirements and full mission horizontal flight requirements. The document privides the intial step in the shuttle GN&C software design process. It also serves as a management tool to identify analyses which are required to define requirements.
The development of an expert system prototype for determining software functional requirements for NASA Goddard's Command Management System (CMS) is described. The role of the CMS is to transform general requests into specific spacecraft commands with command execution conditions. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Subjects covered include: the problem environment of determining CMS software functional requirements; the expert system approach for handling CMS requirements development; validation and evaluation procedures for the expert system.