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.
Long-term and short-term objectives for the development of a network operating system for the Space Station are stated. The short-term objective is to develop a prototype network operating system for a 100 megabit/second fiber optic data bus. The long-term objective is to establish guidelines for writing a detailed specification for a Space Station network operating system. Major milestones are noted. Information is given in outline form.
The Fault Tolerance Expert System for Tracking and Data Relay Satellite System (TDRSS) Applications (FIESTA) is a fault detection and fault diagnosis expert system being developed as a decision aid to support operations in the Network Control Center (NCC) for NASA's Space Network. The operational objectives which influenced FIESTA development are presented and an overview of the architecture used to achieve these goals are provided. The approach to the knowledge engineering effort and the methodology employed are also presented and illustrated with examples drawn from the FIESTA domain.
The networking requirements that the Earth Observing System (EOS) program has levied on NASA and the national and international operational networking communities is addressed. The objectives of the EOS program are listed and include the development and operation of an observing system to acquire essential, global earth science data on a long-term, sustained basis and in a manner which maximizes the scientific utility of the data and simplifies data analysis. Network design issues are also discussed, including protocol selection, the Transport Control Protocol/Internet Protocol suite, the Open Systems Interconnect network suite, and the internet evolution. Open and closed network issues are also discussed. A number of networks now in place are assessed including NASNet, and ESNet. These offer possible options and/or solutions to be considered by the NASA Headquarters EOS Data and Information Systems Program.
As part of the unattended operations objective of the Deep Space Network deep space stations, this filament controller serves as a step between manual operation of the station and complete computer control. Formerly, the operator was required to devote five to fifteen minutes of his time just to properly warm up the filaments on the klystrons of the high power transmitters. The filament controller reduces the operator's duty to a one-step command and is future-compatible with various forms of computer control.
Recent progress in distributed object technology has enabled software applications to be developed and deployed easily such that objects or components can work together across the boundaries of the network, different operating systems, and different languages. A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that co-operates with other objects in a plug-and-play fashion via a well-defined interface. The Common Object Request Broker Architecture (CORBA), a middleware standard defined by the Object Management Group (OMG), uses the Interface Definition Language (IDL) to specify such an interface for transparent communication between distributed objects. Since IDL can be mapped to any programming language, such as C++, Java, Smalltalk, etc., existing applications can be integrated into a new application and hence the tasks of code re-writing and software maintenance can be reduced. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with CORBA objects can increase the codes reusability. For example, scientists could link their scientific applications to vintage Fortran programs such as Partial Differential Equation(PDE) solvers in a plug-and-play fashion. Unfortunately, CORBA IDL to Fortran mapping has not been proposed and there seems to be no direct method of generating CORBA objects from Fortran without having to resort to manually writing C/C++ wrappers. In this paper, we present an efficient methodology to integrate Fortran legacy programs into a distributed object framework. Issues and strategies regarding the conversion and decomposition of Fortran codes into CORBA objects are discussed. The following diagram shows the conversion and decomposition mechanism we proposed. Our goal is to keep the Fortran codes unmodified. The conversion- aided tool takes the Fortran application program as input and helps programmers generate C/C++ header file and IDL file for wrapping the Fortran code. Programmers need to determine by themselves how to decompose the legacy application into several reusable components based on the cohesion and coupling factors among the functions and subroutines. However, programming effort still can be greatly reduced because function headings and types have been converted to C++ and IDL styles. Most Fortran applications use the COMMON block to facilitate the transfer of large amount of variables among several functions. The COMMON block plays the similar role of global variables used in C. In the CORBA-compliant programming environment, global variables can not be used to pass values between objects. One approach to dealing with this problem is to put the COMMON variables into the parameter list. We do not adopt this approach because it requires modification of the Fortran source code which violates our design consideration. Our approach is to extract the COMMON blocks and convert them into a structure-typed attribute in C++. Through attributes, each component can initialize the variables and return the computation result back to the client. We have tested successfully the proposed conversion methodology based on the f2c converter. Since f2c only translates Fortran to C, we still needed to edit the converted code to meet the C++ and IDL syntax. For example, C++/IDL requires a tag in the structure type, while C does not. In this paper, we identify the necessary changes to the f2c converter in order to directly generate the C++ header and the IDL file. Our future work is to add GUI interface to ease the decomposition task by simply dragging and dropping icons.
The NASA Advanced Communications Technology Satellite (ACTS) will use a network of about 20 earth stations to operate as a Mode 1 network. This network will support two ACTS program objectives: to verify the technical performance of ACTS Mode 1 operation in GEO and to demonstrate the types and quality of services that can be provided by an ACTS Mode 1 communications system. The terrestrial interface design is a critical element in assuring that these network earth stations will meet the objectives. In this paper, the applicable terrestrial interface design requirements, the resulting interface specifications, and the associated terrestrial input/output hardware are discussed. A functional block diagram of a network earth station is shown.
The Mark IV-A consolidate deep space and high elliptical Earth orbiter (HEEO) missions tracking and implements centralized control and monitoring at the deep space communications complexes (DSCC). One of the objectives of the network design is to reduce maintenance and operations (M&O) costs. To determine if the system design meets this objective an M&O staffing model for Goldstone was developed which was used to estimate the staffing levels required to support the Mark IV-A configuration. The study was performed for the Goldstone complex and the program office translated these estimates for the overseas complexes to derive the network estimates.
The objective of this paper is to compare the operational and performance cost factors for an Optical Deep Space Network (OSDN).
The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios and a flight computer for supporting in-space communication research. New technologies being studied using the SCaN Testbed include advanced networking, coding, and modulation protocols designed to support the transition of NASAs mission systems from primarily point to point data links and preplanned routes towards adaptive, autonomous internetworked operations needed to meet future mission objectives. Networking protocols implemented on the SCaN Testbed include the Advanced Orbiting Systems (AOS) link-layer protocol, Consultative Committee for Space Data Systems (CCSDS) Encapsulation Packets, Internet Protocol (IP), Space Link Extension (SLE), CCSDS File Delivery Protocol (CFDP), and Delay-Tolerant Networking (DTN) protocols including the Bundle Protocol (BP) and Licklider Transmission Protocol (LTP). The SCaN Testbed end-to-end system provides three S-band data links and one Ka-band data link to exchange space and ground data through NASAs Tracking Data Relay Satellite System or a direct-to-ground link to ground stations. The multiple data links and nodes provide several upgradable elements on both the space and ground systems. This paper will provide a general description of the testbeds system design and capabilities, discuss in detail the design and lessons learned in the implementation of the network protocols, and describe future plans for continuing research to meet the communication needs for evolving global space systems.
The NASA Communications (Nascom) Division of the Mission Operations and Data Systems Directorate is to undertake a major initiative to develop the Nascom II (NII) network to achieve its long-range service objectives for operational data transport to support the Space Station Freedom Program, the Earth Observing System, and other projects. NII is the Nascom ground communications network being developed to accommodate the operational traffic of the mid-1990s and beyond. The authors describe various baseline protocol architectures based on current and evolving technologies. They address the internetworking issues suggested for reliable transfer of data over heterogeneous segments. They also describe the NII architecture, topology, system components, and services. A comparative evaluation of the current and evolving technologies was made, and suggestions for further study are described. It is shown that the direction of the NII configuration and the subsystem component design will clearly depend on the advances made in the area of broadband integrated services.
Approved as a Wallops control center backup system, the Wallops Ship Surveillance Software is a day-of-launch risk analysis tool for spaceport activities. The system calculates impact probabilities and displays ship locations relative to boundary lines. It enables rapid analysis of possible flight paths to preclude the need to cancel launches and allow execution of launches in a timely manner. Its design is based on low-cost, large-customer- base elements including personal computers, the Windows operating system, C/C++ object-oriented software, and network interfaces. In conformance with the NASA software safety standard, the system is designed to ensure that it does not falsely report a safe-for-launch condition. To improve the current ship surveillance method, the system is designed to prevent delay of launch under a safe-for-launch condition. A single workstation is designated the controller of the official ship information and the official risk analysis. Copies of this information are shared with other networked workstations. The program design is divided into five subsystems areas: 1. Communication Link -- threads that control the networking of workstations; 2. Contact List -- a thread that controls a list of protected item (ocean vessel) information; 3. Hazard List -- threads that control a list of hazardous item (debris) information and associated risk calculation information; 4. Display -- threads that control operator inputs and screen display outputs; and 5. Archive -- a thread that controls archive file read and write access. Currently, most of the hazard list thread and parts of other threads are being reused as part of a new ship surveillance system, under the SureTrak project.
Improved method of adjoint-operator learning reduces amount of computation and associated computational memory needed to make electronic neural network learn temporally varying pattern (e.g., to recognize moving object in image) in real time. Method extension of method described in "Adjoint-Operator Learning for a Neural Network" (NPO-18352).
Our objective is to provide a framework of automated tools and techniques for reducing operational and maintenance costs in the NASA's Deep Space Network (DSN).
The fundamental objective is to determine the information available in ground-based millimeter-wave measurements of stratospheric constituent profiles, to identify the optimum method of retrieving this profile information, and to characterize the errors in the final result. A secondary objective is to produce retrieval software for operational use with Network for the Detection of Stratospheric Change (NDSC) measurements of O3, H2O, ClO, and perhaps N2O. Tests were performed on existing ozone retrieval programs in support of ongoing NDSC field measurements. The results show that if random spectral errors and retrieval bias errors are considered, accuracy of the retrieved profile is about 5 percent from 20-50 km, and about 10 percent from 50-60 km.
This Final Report for the PSAW/MicroSWIS Program is provided in compliance with contract number NAS3-01118. This report documents the overall progress of the program and presents project objectives, work carried out, and results obtained. Program Conceptual Design Package stated the following objectives: To develop a sensor/transceiver network that can support networking operations within spacecraft with sufficient bandwidth so that (1) flight control data, (2) avionics data, (3) payload/experiment data, and (4) prognostic health monitoring sensory information can flow to appropriate locations at frequencies that contain the maximum amount of information content but require minimum interconnect and power: a very high speed, low power, programmable modulation, spread-spectrum radio sensor/transceiver.
The functioning of the Deep Space Network Operations Scheduling, Jet Propulsion Laboratory, CA is reviewed. The primary objectives of the Operations Scheduling are: to schedule the worldwide global allocation of ground communications, tracking facilities, and equipment; and to provide deep space telecommunications for command, tracking, telemetry, and control in support of flight mission operations and tests. Elements of the earth set are Deep Space Stations (DSS) which provide the telecommunications link between the earth and spacecraft; NASA Communications Network; Network Data Processing Area; Network Operations Control Area which provides operational direction to the DSS; Mission Control and Computing systems; and Mission Support areas which provide flight control of the spacecraft. Elements of the space set include mission priorities and requirements which determine the spacecraft queue for allocating network resources. Scheduling is discussed in terms of long-range (3 years), mid-range (8 weeks), and short-range (2 weeks).
This paper presents an overview of the Jet Propulsion Laboratory's (JPL) plan for developing a multi-mission facility called the Space Flight Operations Center (SFOC). The SFOC development is a five-year project with the objective of developing and adapting up-to-date computing, networking and data management technology to meet the future data processing and data management requirements for JPL's flight project mission operations. Presented are the project background, basic goals and objectives, design concept and project implementation approach.
Introduction: Scientific exploration is one of the three pillars of NASA’s Moon2Mars architecture, with crew surface extra vehicular activities (EVA) serving a critical enabling function. Development of surface EVA operational planning and execution, specifically integrating science and flight control teams (FCT), is currently being explored through analog scenarios. This integration, exercised, for example, through the Joint EVA and Hu-man Surface Mobility Test Team (JETT), allows for science input on EVA activities in near real-time through a Science Evaluation Room (SER), or Arte-mis science backroom, which integrates with the broader FCT through the Science Officer. The SER works within the FCT to support dynamic EVA planning in response to changes in operational constraints as well as science opportunities and re-prioritization, increasing the mission science return and accelerating the accomplishment of the Moon2Mars science objectives. The SER works within the FCT to provide recommendations to traverse execution in near real-time. One challenge is the requirement to deliver SER inputs to the FCT on operationally relevant timelines. Failure to do so may result in suboptimal execution of science exploration EVAs or even loss of key science objectives. To close this gap, we present a network optimization tool to allow the SER to provide rapid input to the FCT in response to changes in operational constraints or science opportunities. Inputs are predicated on approved science objectives, and clear rationale must be provided to the FCT for any requested change. Accordingly, this tool incorporates the Science Traceability Matrix (STM), SER prioritization scheme, and station characterization and action planning with operational constraints such as duration, traverse speed, and distance to maximize science objectives based on SER priorities, consistent with FCT operational requirements. Method: As a proof of concept, we used an existing linear programing software package used to simulate optimal routes through cellular metabolism. We built a Demonstrative Model with three STM objectives and four stations on a region of the Moon. The objectives were given an arbitrary prioritization and mapped to the stations through four possible crew actions. (Figs. 1 and 2). This station to STM mapping is consistent with the method used by the JETT5 Science Team to develop analog surface EVA science planning. We used a grid system with the landing site at the origin and the four stations placed across the positive x,y quadrant. Actions were assigned to each station and the accomplishment of those actions resulted in a numerical “reward” based on the ability of that action to achieve science objectives. The aggregate reward from each individual STM objective contributes to a global score (Science Yield), weighted by its priority. Operational constraints included a requirement to start and end at the landing site, 5 minutes each for initial station characterization and “clean up,” and variable total EVA time, traverse rate (fixed to 0.5 meters per second in our example), and time to perform each action (10, 5, 7, and 15 min for actions 1, 2, 3, and 4, respectively). Additional constraints and variables will be added in the future (e.g., sample mass, number of stations, traverse route constraints, illumination). Optimization. We converted the connections (arcs) between these stations (nodes) into a mixed integer linear programming optimization problem (arcs = constraints, nodes = variables) with the objective to maximize Science Yield. For any action, the Science Yield is equal to the relevance of that action to an STM objective [3, 2, and 1 point(s) for High, Med., and Low relevance, respectively], multiplied by the STM Objective Priority [3, 2, and 1 point(s) for High, Med., and Low priority, respectively]. This resulted in a model that computes the optimal station and action combination to maximize the Science Yield. These weightings can be adjusted by the SER as desired. Results: We explored three test cases for the Demonstrative Model. First, we set the maximum EVA duration to 120 minutes and computed the optimal route (Fig. 3A). The model suggested per-forming Actions 1 and 2 at Station P01, followed by Actions 1 and 2 at Station P02, and finally Actions 1 and 3 at Station P04 before returning to the Landing Site. Second, we adjusted the STM Objective Priori-ty order and computed the new optimal route (Fig. 3B). Under this situation, the model suggested per-forming all Actions at Station P02 followed by all Actions at Station P03. The previous test cases were relevant to SER planning activities. Next, we explored providing mid-EVA replanning input to the FCT. Scenario: While executing the Route in Fig. 3A the crew finishes at Station P01 and FCT decides that the EVA needs to finish in 45 minutes back at the Landing Site. FCT asks SER to recommend changes to the plan to accommodate this operation-al change. Using the model and incorporating these new constraints (start at Station P01, max. time of 45 min), the model suggested performing Actions 2 and 4 at Station P03 (Fig. 4), requiring 41 minutes to complete and return to the Landing Site. Interestingly, Station 3 was not part of the original route. Using the model, we determined the EVA would need 66 minutes, instead of 45, in order for the original Station P04 to yield a larger Science Yield than Station P03. The parametrization and simulation was per-formed in less than a minute, demonstrating the operational relevance of the approach. Future Efforts: The results from the Demonstrative Model suggest this tool can accelerate SER decision making on operationally relevant timelines. Use in analog activities, such as JETT5 or follow-ons, which have over a dozen stations for a crew to explore and over a dozen actions per station, will provide needed validation of the utility of this tool for planning EVAs, replanning mid-EVA, or planning follow-on EVAs based on previous results. Further integration with FCT execution monitoring tools may provide additional efficiency gains, al-lowing rapid and iterative exploration of operation-al and science decision space by the FCT and SER.