Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “command process”

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 865 records · Page 48

Concurrent Image Processing Executive (CIPE). Volume 3: User's guide

CIPE (the Concurrent Image Processing Executive) is both an executive which organizes the parameter inputs for hypercube applications and an environment which provides temporary data workspace and simple real-time function definition facilities for image analysis. CIPE provides two types of user interface. The Command Line Interface (CLI) provides a simple command-driven environment allowing interactive function definition and evaluation of algebraic expressions. The menu interface employs a hierarchical screen-oriented menu system where the user is led through a menu tree to any specific application and then given a formatted panel screen for parameter entry. How to initialize the system through the setup function, how to read data into CIPE symbols, how to manipulate and display data through the use of executive functions, and how to run an application in either user interface mode, are described.

Lee, Meemong↗

Development Unit Configuration and Current Status of the MIP/MTERC Experiment

The Mars In-Situ Propellant Production (ISPP) Precursor (MIP) experiment package is planned for inclusion on the Mars 2001 Lander. This experiment package consists of five experiments whose purpose is to demonstrate the performance of various ISPP processes in-situ on Mars. The demonstrated ability to produce propellant for Mars Return Vehicles (MRV) is considered to be a necessary precursor to any future manned mission to Mars. The Mars Thermal Environment/Radiator Characterization (MTERC) experiment is part of the MIP package and is intended to determine the Mars night sky temperature as well as to characterize the performance degradation of radiators caused by environmental exposure on Mars over time. Radiators are needed as part of the ISPP process to remove heat from the Mars Atmosphere Acquisition and Compression (MAAC) CO2 sorption compressor. MTERC will provide the data needed to optimize the design of radiators for ISPP and other processes. A MTERC Development Unit (DU) has been fabricated and tested at JPL. The MTERC DU consists of 1) a radiator subassembly, 2) a motor/cover subassembly, 3) a differential temperature control circuit and motor control electronics circuit board, and 4) a command and data handling electronics circuit board. This paper will describe the operational theory and the configuration of the MTERC DU and will discuss the current status of the MTERC experiment development including some selected results of performance testing that has been completed prior to the ISRU III meeting.

Juanero, K. J.↗

Development Unit Configuration and Current Status of the MIP/MTERC Experiment

The Mars In-Situ Propellant Production (ISPP) Precursor (MIP) experiment package is planned for inclusion on the Mars 2001 Lander. This experiment package consists of five experiments whose purpose is to demonstrate the performance of various ISPP processes in-situ on Mars. The demonstrated ability to produce propellant for Mars Return Vehicles (MRV) is considered to be a necessary precursor to any future manned mission to Mars. The Mars Thermal Environment/Radiator Characterization (MTERC) experiment is part of the MIP package and is intended to determine the Mars night sky temperature as well as to characterize the performance degradation of radiators caused by environmental exposure on Mars over time. Radiators are needed as part of the ISPP process to remove heat from the Mars Atmosphere Acquisition and Compression (MAAC) C02 sorption compressor. MTERC will provide the data needed to optimize the design of radiators for ISPP and other processes. A MTERC Development Unit (DU) has been fabricated and tested at JPL. The MTERC DU consists of: (1) a radiator subassembly, (2) a motor/cover subassembly, (3) a differential temperature control circuit and motor control electronics circuit board, and (4) a command and data handling electronics circuit board. This paper will describe the operational theory and the configuration of the MTERC DU and will discuss the current status of the MTERC experiment development including some selected results of performance testing that has been completed prior to the ISRU III meeting.

Juanero, K. J.↗

An Overview of the Process for Pre-Launch Checkout and Transition Activities in Support of the International Space Station (ISS) Payload Operations Integration Center

The objective of this paper is to provide future ISS scientists and/or engineers with an overview of the coordination process for the preparation and implementation of the pre-launch checkout and transition activities as observed from the Marshall Control Flight Center (MSFC) Payload Operations Integration Center perspective. This includes 4 major phases: (1) Verification and validation of the new command and telemetry databases that are needed for new payload experiments and new onboard formats; (2) Integration testing of the new ground control software and hardware; (3) Final internal and external pre-launch checkouts with cadre and experiment teams; (4) Performance of the actual synchronized transition between MSFC, Johnson Space Center (JSC), and ISS onboard configuration to new onboard software, ground software, and databases.

Digesu, Sam↗

Validation of Alternatives to Aliphatic Isocyanate Polyurethanes

The National Aeronautics and Space Administration (NASA) Headquarters chartered the Acquisition Pollution Prevention (AP2) Office to coordinate agency activities affecting pollution prevention issues identified during system and component acquisition and sustainment processes. The primary objective of this effort is to demonstrate and validate alternatives to aliphatic isocyanate polyurethane coatings. Successful completion of this project will result in one or more isocyanate-free coating systems qualified for use at Air Force Space Command (AFSPC) and NASA centers participating in this study. The objective of this project is to qualify the candidates under the specifications for the standard system. This project will compare coating performance of the proposed alternatives to existing coating systems or standards.

Curran, Jerome↗

Key Differences in Operating a Rover on the Moon vs. Mars

The command and control model for spacecraft operations, as well as the distribution of tasks between ground assets and in space assets, whether with a crew or solely robotic, is fundamentally constrained by the round trip light time between the space asset and the control facility (presumably on Earth, though not required). For an asset on Mars, the round trip light time varies, from roughly fourteen minutes to up to forty minutes. For a Lunar asset the round-trip light time is measured in only a few seconds, but current communications systems may more than double the latency with system overhead. For a Lunar Asset the total command latency may range from six seconds to more than forty, depending on communications overhead and data rates. Further, these variables are not always predictable, thus complicating operations. There are several differentiating factors for Lunar vs. Mars operations, Round trip light time/Atmosphere/Lighting and ShadowsTerrain type and knowledge/Round trip light time has implications for the distribution of tasks between ground and in space assets. Even at Lunar Distances, the combination of round trip light time plus communications systems overhead does not enable joy stick driving of a rover. The best that can be done, if driving from Earth, is near real time command and control. By 2030, driving from in space may be possible. Productivity on Mars requires either long operational sequences of commands, as is done for current rovers such as Curiosity, significant autonomous capability or, as may be possible by 2030, command and control support from space. Another implication of the long round trip light time from Earth to Mars, is that flight software functions must be resident on the in space asset. On the Moon, there is considerably more flexibility, enabling processing functions, to be resident on Earth or in space. This provides the opportunity to take advantage of the considerable processing power available on the ground, but may be constrained by data rates. On the Moon, for practical operational purposes, there is no atmosphere. Hence there is no scattering of light in the shadows. This has implications for image interpretation and driving near the poles. The Moon has permanently shadowed regions (PSR), unique terrain with unknown surface properties. With no scattering of light in shadows, driving on the Moon, particularly at the poles, where we have strong evidence of water, may prove to be hazardous and complex, requiring non-optical sensors, such as LIDAR.

Trimble, Jay↗

Apparatus to control the total energy flux into the top ingot surface during vacuum arc remelting processes

A Vacuum Arc Remelting controller apparatus wherein process control is accomplished primarily through control of pool power. Pool power being defined as the total energy flux into a top ingot surface of the VAR ingot. The controller apparatus of the present invention comprises a controller computer that transmits commands to the host furnace through an ethernet connection.

42 ENGINEERING↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗

Compact Autonomous Hemispheric Vision System

Solar System Exploration camera implementations to date have involved either single cameras with wide field-of-view (FOV) and consequently coarser spatial resolution, cameras on a movable mast, or single cameras necessitating rotation of the host vehicle to afford visibility outside a relatively narrow FOV. These cameras require detailed commanding from the ground or separate onboard computers to operate properly, and are incapable of making decisions based on image content that control pointing and downlink strategy. For color, a filter wheel having selectable positions was often added, which added moving parts, size, mass, power, and reduced reliability. A system was developed based on a general-purpose miniature visible-light camera using advanced CMOS (complementary metal oxide semiconductor) imager technology. The baseline camera has a 92 FOV and six cameras are arranged in an angled-up carousel fashion, with FOV overlaps such that the system has a 360 FOV (azimuth). A seventh camera, also with a FOV of 92 , is installed normal to the plane of the other 6 cameras giving the system a > 90 FOV in elevation and completing the hemispheric vision system. A central unit houses the common electronics box (CEB) controlling the system (power conversion, data processing, memory, and control software). Stereo is achieved by adding a second system on a baseline, and color is achieved by stacking two more systems (for a total of three, each system equipped with its own filter.) Two connectors on the bottom of the CEB provide a connection to a carrier (rover, spacecraft, balloon, etc.) for telemetry, commands, and power. This system has no moving parts. The system's onboard software (SW) supports autonomous operations such as pattern recognition and tracking.

Pingree, Paula J.↗

Creating a Simulation Platform for Research and Development of Advanced Control Methods

Advanced nuclear reactors are essential to meet the changing energy requirements throughout both the United States and the rest of world. In addition to other features, they are designed to enable deployment in remote locations and operate in a fully (or near-fully) autonomous manner, which will require a new control paradigm. To realize autonomously operating reactors, the U.S. Department of Energy’s Nuclear Energy Enabling Technologies Advanced Sensors and Instrumentation (NEET ASI) program conducts research and development into the enabling technologies and methods needed, including digital twins, machine learning, and risk modeling, in addition to various types of control methods. These technologies and methods are the key foundations needed to achieve fully autonomous systems. To develop and evaluate the technologies and methods necessary for achieving autonomous operations, it is critical to identify a software tool capable of integrating all the required elements. In surveying the available solutions, no software platforms were identified that could accomplish what was needed without introducing drawbacks. This challenge was the motivation for the current effort: to develop a software platform that can seamlessly integrate autonomouscontrol-enabling technologies and methods, allowing for accelerated research and development and transfer of ideas. The resulting platform, known as the Control and Optimization Modular Modeling Application for Nuclear Deployment (COMMAND), is Python-based, and leverages open-source tools to provide flexibility and facilitate building upon prior research. It is designed to enable advanced reactor developers to deploy and test advanced control technologies and methods coupled with their own models, solutions, and hardware. Given the substantial undertaking of developing such a platform, the current effort focused on laying down scalable, flexible software foundations and infrastructure, then demonstrating the platform via a use case. These foundations included developing generic modules, which contain the base variable and system blocks (the information and functional building blocks, respectively, that can be used to design a simulation) and the data handling and storage blocks needed to exchange information between the various blocks; as well as enablingtechnology-specific modules. This platform was evaluated via a use case, which was to simulate and control a process for the Microreactor Automated Control System (MACS) test bed. While MACS is not currently directly coupled to any specific microreactor physics, it was initially developed in concert with the Microreactor Applications Research Validation and Evaluation (MARVEL) microreactor, and so the MARVEL physics are used here. As part of this use case, several enabling-technology-specific blocks within COMMAND were integrated, including a proportional integral derivative (PID) control block, a Reactor Excursion and Leak Analysis Program (RELAP5-3D) block, and an anomaly detection block. The COMMAND software platform was successfully demonstrated to achieve the scalability and flexibility objectives of this effort and will be leveraged by the program’s research efforts to advance state of the art control methodologies towards autonomous operations of advanced reactors. As new use cases are created and implemented, it is anticipated that COMMAND will continue to grow and evolve to meet new requirements.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Data and scripts associated with the manuscript evaluating the hydrologic responses of the Pacific Northwest watersheds to wildfires (v2)

This data package is associated with the publication “Evaluating Post-fire Watershed Response to Varying Burn Severity and Precipitation Regimes Using Fully-distributed and Integrated Hydrologic Models” submitted to Journal of Hydrology (Li et al. 2025). In this study, we employed the Advanced Terrestrial Simulator (ATS), an integrated watershed model that couples surface flow, subsurface flow, and canopy biophysical processes, to investigate post-fire hydrologic responses in a few selected watersheds with varying burn severity.The data package contains the required input data (meteorological forcing, Leaf Area Index, wildfire burn severities, etc.) to run the model, configuration files, the Jupyter notebooks in Python to pre-process and post-process data, the figures in the manuscript, and the modeling output files. The variables include watershed-averaged evapotranspiration, watershed-averaged surface/subsurface/canopy water content, and river discharge at watershed outlet.The data package contains a file-level metadata that lists and describes all the files contained in the data package (ATS_flmd.csv), a data dictionary file that defines columns headers across all csv files contained in the data package (ATS_dd.csv), a data package level readme file (the current file), and four zipped folders.The ‘data’ folder provides data needed to run the model in .h5, .i2s, .xyz, .shp, and .exo formats. The sub-folders are for each data types. The ‘model’ folder provides input files (.xml format) and essential model outputs. Each sub-folder provides the files from each simulated watershed. The ‘notebooks’ folder provides the Jupyter notebooks (.ipynb format) for pre- and post- processing model files, and for producing the figures in the manuscript. The ‘figures’ folder provides the figures associated with manuscript in .pdf and .png formats.The ‘model’ folder and the ‘data’ folder have been split into 5GB-large pieces using the Linux command ‘split -b 5120m model.zip model.zip.’ and ‘split -b 5120m data.zip data.zip.’, respectively. They can be merged back using the Linux command ‘cat model.zip.* > model.zip’ and ‘cat data.zip.* > data.zip’, respectively.

54 ENVIRONMENTAL SCIENCES↗

Radio astronomy Explorer-B in-flight mission control system development effort

A description is given of the development for the Mission Analysis Evaluation and Space Trajectory Operations (MAESTRO) program to be used for the in-flight decision making process during the translunar and lunar orbit adjustment phases of the flight of the Radio Astronomy Explorer-B. THe program serves two functions: performance and evaluation of preflight mission analysis, and in-flight support for the midcourse and lunar insertion command decisions that must be made by the flight director. The topics discussed include: analysis of program and midcourse guidance capabilities; methods for on-line control; printed displays of the MAESTRO program; and in-flight operational logistics and testing.

Lutsky, D. A.↗

Replacing the CCSDS Telecommand Protocol with the Next Generation Uplink (NGU)

The current CCSDS Telecommand (TC) Recommendations 1-3 have essentially been in use since the early 1960s. The purpose of this paper is to propose a successor protocol to TC. The current CCSDS recommendations can only accommodate telecommand rates up to approximately 1 mbit/s. However today's spacecraft are storehouses for software including software for Field Programmable Gate Arrays (FPGA) which are rapidly replacing unique hardware systems. Changes to flight software occasionally require uplinks to deliver very large volumes of data. In the opposite direction, high rate downlink missions that use acknowledged CCSDS File Delivery Protocol (CFDP)4 will increase the uplink data rate requirements. It is calculated that a 5 mbits/s downlink could saturate a 4 kbits/s uplink with CFDP downlink responses: negative acknowledgements (NAKs), FINISHs, End-of-File (EOF), Acknowledgements (ACKs). Moreover, it is anticipated that uplink rates of 10 to 20 mbits/s will be required to support manned missions. The current TC recommendations cannot meet these new demands. Specifically, they are very tightly coupled to the Bose-Chaudhuri-Hocquenghem (BCH) code in Ref. 2. This protocol requires that an uncorrectable BCH codeword delimit the TC frame and terminate the randomization process. This method greatly limits telecom performance since only the BCH code can support the protocol. More modern techniques such as the CCSDS Low Density Parity Check (LDPC)5 codes can provide a minimum performance gain of up to 6 times higher command data rates as long as sufficient power is available in the data. This paper will describe the proposed protocol format, trade-offs, and advantages offered, along with a discussion of how reliable communications takes place at higher nominal rates.

Consultative Committee for Space Data Systems (CCS↗

Creative Analytics of Mission Ops Event Messages

Historically, tremendous effort has been put into processing and displaying mission health and safety telemetry data; and relatively little attention has been paid to extracting information from missions time-tagged event log messages. Todays missions may log tens of thousands of messages per day and the numbers are expected to dramatically increase as satellite fleets and constellations are launched, as security monitoring continues to evolve, and as the overall complexity of ground system operations increases. The logs may contain information about orbital events, scheduled and actual observations, device status and anomalies, when operators were logged on, when commands were resent, when there were data drop outs or system failures, and much much more. When dealing with distributed space missions or operational fleets, it becomes even more important to systematically analyze this data. Several advanced information systems technologies make it appropriate to now develop analytic capabilities which can increase mission situational awareness, reduce mission risk, enable better event-driven automation and cross-mission collaborations, and lead to improved operations strategies: Industry Standard for Log Messages. The Object Management Group (OMG) Space Domain Task Force (SDTF) standards organization is in the process of creating a formal standard for industry for event log messages. The format is based on work at NASA GSFC. Open System Architectures. The DoD, NASA, and others are moving towards common open system architectures for mission ground data systems based on work at NASA GSFC with the full support of the commercial product industry and major integration contractors. Text Analytics. A specific area of data analytics which applies statistical, linguistic, and structural techniques to extract and classify information from textual sources. This presentation describes work now underway at NASA to increase situational awareness through the collection of non-telemetry mission operations information into a common log format and then providing display and analytics tools to provide in-depth assessment of the log contents. The work includes: Common interface formats for acquiring time-tagged text messages Conversion of common files for schedules, orbital events, and stored commands to the common log format Innovative displays to depict thousands of messages on a single display Structured English text queries against the log message data store, extensible to a more mature natural language query capability Goal of speech-to-text and text-to-speech additions to create a personal mission operations assistant to aid on-console operations. A wide variety of planned uses identified by the mission operations teams will be discussed.

events↗

Applications of artificial intelligence to space station and automated software techniques: High level robot command language

The objective is to develop a system that will allow a person not necessarily skilled in the art of programming robots to quickly and naturally create the necessary data and commands to enable a robot to perform a desired task. The system will use a menu driven graphical user interface. This interface will allow the user to input data to select objects to be moved. There will be an imbedded expert system to process the knowledge about objects and the robot to determine how they are to be moved. There will be automatic path planning to avoid obstacles in the work space and to create a near optimum path. The system will contain the software to generate the required robot instructions.

Mckee, James W.↗

Small gain robustness issues in the p-integrator repetitive controller

The basic theory of the digital p-integrator controller is utilized to modify the command to a stable analog feedback control system in order to produce zero tracking error of a repetitive command. Mapping of continuous time poles and zeros to the images in the discrete time domain is performed. It is shown that for a pole excess of one, with p odd, the p-integrator learning controller will often produce a stable learning process, even for relatively large sample times. For a pole excess of two, a stable learning process can often be achieved for any p as long as the sample time is kept sufficiently short. Therefore, when the pole excess is zero and one utilizes the proper p-integrator controller with p odd, stable performance is often produced, even for relatively large sample times.

Longman, Richard W.↗

The SAMPEX Data Processing Unit

The paper discusses salient features of the SAMPEX Data Processing Unit (DPU), the primary function of which is to collect sensor data to create telemetry packets for transmission to the solid-state recorder located within the Small Explorer Data System. Particular attention is given to the sensor interface electronics, the space command interface, the spacecraft telemetry interface, and the memory mapper of the DPU system; the task scheduling concept; and system reconfiguring. A block diagram of the DPU system is included.

Mabry, D. J.↗