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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 649 records · Page 36

All sources NASA NTRS DOE OSTI

DOE OSTI2024

Control And Optimization Modular Modeling Application For Nuclear Deployment

The purpose of the COMMAND code is to provide a flexible, scalable tool for use in developing, integrating, and testing the technologies necessary for achieving autonomous operations of advanced nuclear reactors. The code enables users to efficiently implement custom simulations and experiments by combining key methods from different software modules. These modules are focused on: modeling and simulation tools, such as nuclear simulation tools used for high-fidelity modeling (e.g., Reactor Excursion and Leak Analysis Program [RELAP5-3D] and Monte Carlo N-Particle [MCNP]); machine learning and optimization tools (e.g., anomaly detection and data-driven modeling techniques); advanced control in its digital, high-performance, and supervisory control forms (e.g., proportional integral derivative (PID) control and model predictive control (MPC); and integration with hardware through industrial communication protocols. To ensure flexibility and scalability, COMMAND was designed to be both modular—the software “pieces” all inherit from generic building blocks and can be combined and connected to create complicated simulations—and high performing—designed for parallel processing, enabling simulations and experiments to take advantage of multi-core computers, servers, and nodes. The code is written in the Python programming language due to the language's popularity, active community, and open-source and cross-platform nature. Maintaining consistency with other simulation tools used within the nuclear energy community, users implement simulations and experiments through text input files, which define components, parameters, connections, etc., through lines of text. Given that COMMAND is written in Python, these input files are native Python scripts, and so use the standard Python structure and formatting. This also enables users to take advantage of Python's extensive package library to develop custom capabilities for their specific use cases.

Faber, Jacob [Idaho National Laboratory (INL), Ida↗

NASA NTRS2014

Remote Software Application and Display Development

The era of the shuttle program has come to an end, but only to give rise to newer and more exciting projects. Now is the time of the Orion spacecraft, a work of art designed to exceed all previous endeavors of man. NASA is exiting the time of exploration and is entering a new period, a period of pioneering. With this new mission, many of NASAs organizations must undergo a great deal of change and development to support the Orion missions. The Spaceport Command and Control System (SCCS) is the new system that will provide NASA the ability to launch rockets into orbit and thus control Orion and other spacecraft as the goal of populating Mars becomes ever increasingly tangible. Since the previous control system, Launch Processing System (LPS), was primarily designed to launch the shuttles, SCCS was needed as Kennedy Space Center (KSC) reorganized to a multiuser spaceport for commercial flights, providing a more versatile control over rockets. Within SCCS, is the Launch Control System (LCS), which is the remote software behind the command and monitoring of flight and ground system hardware. This internship at KSC has involved two main components in LCS, including Remote Software Application and Display development. The display environment provides a graphical user interface for an operator to view and see if any cautions are raised, while the remote applications are the backbone that communicate with hardware, and then relay the data back to the displays. These elements go hand in hand as they provide monitoring and control over hardware and software alike from the safety of the Launch Control Center. The remote software applications are written in Application Control Language (ACL), which must undergo unit testing to ensure data integrity. This paper describes both the implementation and writing of unit tests in ACL code for remote software applications, as well as the building of remote displays to be used in the Launch Control Center (LCC).

ACL↗

DOE OSTI2014

Metabolomic data streaming for biology-dependent data acquisition

During the last 10 years, metabolomics has emerged as a powerful technology to interrogate cellular biochemistry at the global level. Although much of the success has been driven by advances in mass spectrometry, developments in bioinformatic resources for data processing have been equally important. Additionally, the widely used metabolomic software XCMS, in particular, has undergone substantial improvements since its first introduction in 2005 (ref. 1). In addition to improved algorithms for peak picking, retention time alignment and data visualization, XCMS has transitioned from a command-line interface requiring expertise with the R programming language, to a web-based platform with a graphical user interface2. This web-based platform, which we call XCMS Online, enables thousands of users to upload their metabolomic data and perform cloud-based processing.

59 BASIC BIOLOGICAL SCIENCES↗

DOE OSTI2018

Simulation INsight and Analysis

Sina is a tool set for modern scientific data management that provides flexible, light-weight support of non-bulk data capture for retention in and queries against SQL and noSQL data stores. HPC simulations traditionally maintain their data in files. Extracting data of interest for subsequent analysis then requires the time-consuming process of traversing directories and scraping data from files in a variety of formats. Sina facilitates capturing relevant data during execution or post-processing of simulation runs for retention in and queries from a modern data store. The tools are sufficiently general to allow for the inclusion of new fields as scientists learn more about their data. Libraries, currently in C++ and Python, and a command line interface (CLI) are provided. Sina's flexibility starts with a general schema, in JSON, for the collection of non-bulk simulation data. JSON provides a flexible, human-readable representation of the data that of interest. Sina currently has a C++ library for simulations to write data to and read from a schema-compliant file for subsequent ingestion into one of the supported data stores. However, applications are free to write their data directly into a schema-compliant file. Python packages provide data ingestion, management, query, and export capabilities. A command line interface (CLI) provides simplified access to these features. A common application programming interface (API) is used to maintain and query data in any of the supported data stores, which are currently limited to SQL and Apache Cassandra (a column store). Tutorials, demonstrations, and examples illustrate aspects of the process using scripts and Jupyter notebooks.

Pauli, EstebanT↗

NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗

DOE OSTI2026

rustpix

rustpix is a high-performance, open-source Rust library with first-class Python bindings (via PyO3) for processing pixel-detector data in neutron imaging. It targets time-stamping detectors such as Timepix3 (TPX3) at ORNL's Spallation Neutron Source (VENUS beamline), where each detected neutron deposits charge across a cluster of pixels within a very high-rate event stream (96M+ hits/sec). rustpix parses TPX3 event data in parallel using memory-mapped I/O, offers four interchangeable clustering algorithms (ABS adjacency-based search, DBSCAN, graph/union-find connected components, and a parallel grid method), and extracts weighted, super-resolved centroids to produce neutron-event lists. A streaming architecture lets it process files larger than available memory. rustpix is distributed as a pip-installable Python package (with NumPy integration), Rust crates, a command-line tool, and an interactive GUI; it writes HDF5, Apache Arrow, and CSV; and it is designed to extend to TPX4 and other detector types. Released as open-source under the MIT License.

Zhang, Chen [Oak Ridge National Laboratory (ORNL),↗

NASA NTRS1971

ALSEP data management.

Nine million measurements a day are transmitted from each functional ALSEP on the moon and continuously collected on earth for use in long-term scientific analysis. Periodically, this massive flow of intricate data is examined on a real-time basis to evaluate ALSEP performance and to study the need for new commands to any of the ALSEP systems. A worldwide complex of facilities and personnel has the challenging task of efficient and timely data processing and dissemination. This paper describes facility characteristics and support activities and details certain constraints imposed on ALSEP hardware design by data handling requirements. The highlights of the first two years of lunar data management are reviewed.

Murtaugh, C. R.↗

NASA NTRS1977

Navigating the Viking landers

On July 20, 1976, Viking Lander 1 became the first unmanned spacecraft to land and operate successfully on the planet Mars. This was followed by a second successful landing on September 3, 1976. This paper gives a detailed description of the autonomous on-board navigation process to perform the guidance, control, and entry navigation functions. Also, the functions performed on the ground to generate and validate the guidance commands sent to the spacecraft prior to descent are described. In-flight measures of navigation system performance are compared against a-priori error estimates to show that the descents were completely nominal in all respects. The final landing errors were 25 km and 10 km for Missions 1 and 2, respectively.

Euler, E. A.↗

NASA NTRS1981

Developing experiment instrument packages

Ground-Support Equipment (GSE) system supports development, calibration, and testing of experiment packages. It is also used for "quick look" processing and in-progress data analysis. User interacts with incoming telemetry data, performs computations, and controls execution of procedures using versatile Experiment Command Interactive Language (ECIL). Program is implemented many ways with minimal modification. It is written in MARCO II and FORTRAN for DEC PDP-11/34 using the RSX-11M operating system.

Herreid, R.↗

NASA NTRS1983

Laboratory system for demonstrating spacecraft processing of multispectral image data

The various elements of the Information Adaptive System (IAS) program are discussed along with the design features, approaches, and algorithms employed within the system. This program was initiated by NASA in order to develop an adaptable data processing system which will accommodate high speed multispectral image data in the real-time spacecraft environment. The development of this system is examined, including the test and support equipment required to evaluate and demonstrate the operational performance of the system in terms of the applicability of the design to high speed onboard processing. In addition to a high throughput rate capability, this system will be flexible, programmable, and capable of adapting its operation to external commands and characteristics of the data stream.

Meredith, B. D.↗

NASA NTRS1993

A MOS for all seasons

From a systems perspective, this paper examines the challenges of a single system to support multiple JPL space exploration missions and the need for unitary responsibility for the system. The focus is a Mission Operations System (MOS), which is effectively a mission management organization with direct authority over data system operations, command sequencing, flight operations control, data management, trajectory determination, telemetry and data acquisition, and spacecraft analysis. Stratagems for training and the approach to processes, procedures, and interfaces to facilitate the transition from the present situation to a truly multimission operational environment are developed. The outcome is a paradigm for a MOS that is achievable, that can effectively support multiple projects, and that can take advantage of technological changes without perturbing the entire system.

Bryant, Larry↗

NASA NTRS1988

STS-26/Discovery Preparations for Launch

This NASA Kennedy Space Center two-part video release is comprised of footage covering STS-26 launch preparations from the arrival of the Tracking and Data Relay Satellite (TDRS) at the Orbiter Processing Facility (OPF) to the lift and mate of the external tanks. The STS-26 flight crew include: Frederick H. (Rick) Hauck, mission commander; Richard O. Covey, pilot; John M. (Mike) Lounge, mission specialist; David C. Hilmers, mission specialist; and George D. (Pinky) Nelson, mission specialist. The primary payload of STS-26 is the TDRS while the secondary payloads include the Physical Vapor Transport of Organic Solids (PVTOS); Protein Crystal Growth (PCG); Infrared Communications Flight Experiment (IRCFE); Aggregation of Red Blood Cells (ARC); Isoelectric Focusing Experiment (IFE); Mesoscale Lightning Experiment (MLE); Phase Partitioning Experiment (PPE); Earth-Limb Radiance Experiment (ELRAD); Automated Directional Solidification Furnace (ADSF) and two Shuttle Student Involvement Program (SSIP) experiments. Launch preparation footage includes flight crew arrival at KSC, rollout of Discovery to Pad B, OV-103 Discovery power-up, main engine unpacking and installation, solid rocket boosters' arrival prep and stacking, and aft skirt to aft segment mating.

Source record↗

NASA NTRS2010

Monitoring system and methods for a distributed and recoverable digital control system

A monitoring system and methods are provided for a distributed and recoverable digital control system. The monitoring system generally comprises two independent monitoring planes within the control system. The first monitoring plane is internal to the computing units in the control system, and the second monitoring plane is external to the computing units. The internal first monitoring plane includes two in-line monitors. The first internal monitor is a self-checking, lock-step-processing monitor with integrated rapid recovery capability. The second internal monitor includes one or more reasonableness monitors, which compare actual effector position with commanded effector position. The external second monitor plane includes two monitors. The first external monitor includes a pre-recovery computing monitor, and the second external monitor includes a post recovery computing monitor. Various methods for implementing the monitoring functions are also disclosed.

Stange, Kent↗

NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗

NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗

NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗

DOE OSTI2023

Simulink Model of a New Energy EVG-005 5kW Hydropower Turbine

Simulink model for a New Energy 5kW hydropower turbine. ADCP data ("ds_streamwise_7_13.nc") and DC voltage, DC current, and rotor rotation observed from the New Energy EVG-005 Current Energy Converter (CEC) ("electrical_7_13_10ohms.nc") were collected at the Tanana River Test Site (TRTS) near Nenana Alaska. - Data was collected on July 13th, 2023 with a constant 10 ohms resistance applied with a DC load bank. - Simulink model is meant to resemble the electrical setup at the TRTS. - Model is initialized by running the "NewEnergy_2023_10hz.m" Matlab script. Then the Simulink model ("New_Energy_Model_PMSM.slx") can be run. - Results are processed with the "NewEnergy_2023_processing.m" Matlab code. The Matlab results are also saved in the "New_Energy_7_13_model_validation_results.mat" Matlab file. This can be directly loaded into the Matlab Workspace using the "Load()" command. - The timetable variables "electrical_model_downsampled" is the model results and the "electrical_limited" is the experimental data from the TRTS.

16 TIDAL AND WAVE POWER↗

NASA NTRS2019

The MERiT Onboard the CeREs: A Novel Instrument to Study Energetic Particles in the Earth's Radiation Belts

The Miniaturized Electron pRoton Telescope, MERiT, is a low‐mass, low‐power, compact instrument using an innovative combination of particle detectors, sensor electronics, and onboard processing. MERiT is flying on the Compact Radiation belt Explorer, CeREs, a 3U CubeSat launched into a low earth orbit of 500‐km altitude and inclination of 85° on 16 December 2018. The primary and secondary science goals of CeREs are to investigate electron microbursts and to study solar particles. MERiT comprises a stack of solid state detectors (SSD) behind space facing avalanche photo diodes (APDs) surrounded by W‐Al shielding to reduce side‐penetrating particle background. The APD‐SSD combination enables measurement of electrons from 5 to 200 keV and 1 to 8 MeV; protons from 200–400 keV and 7–100 MeV in differential channels with energy resolution ΔE/E≈30% for both electrons and protons. MERiT measures microbursts with a high time resolution ranging from 4 to 16 ms and solar particles with a cadence of 1 s. MERiT energy channels and cadences are software configurable via algorithms and lookup tables residing on a field‐programmable gate array. The lookup tables can be changed via ground commands. MERiT geometry factor is 31 sq.cm‐sr and optimized to measure microbursts with the instrument viewing the local zenith in orbit. MERiT enables investigation of dynamical processes of radiation belt electron energization and loss, solar electron and proton transport, and their access to the Earth's polar caps. We describe the MERiT sensor design, calibration, operational modes, data products, and science goals.

Kanekal, S. G.↗